Ok Heres another problem, I need to make the bot ban Operators too ... which have "[" name "]" and i was wondering how would i remove this from a message...

I've already got down that UCase(Message) is needed mostlikely... but i don't know how to remove "[" "]" from the start and end of names ...

Use Mid$(String, Start, [Length]) -- read my reply here.

The problem is how to tell if it is an operator or just some guy with [] around his name with caps. There would probably be more use to banning the person with the []s around his name, because there is a very small likelyhood that channel ops will be joining your channel.

yeah feanor i figured that but, if a w3 is ops ... @Lordaeron] will be displayed (West), so that one would be banned...

[quote author=DaRk-FeAnOr link=board=17;threadid=2576;start=0#msg20110 date=1062656926]
The problem is how to tell if it is an operator or just some guy with [] around his name with caps. There would probably be more use to banning the person with the []s around his name, because there is a very small likelyhood that channel ops will be joining your channel.
[/quote]

There's no extremely effective way to do this without using a /whois, and in that case you're better off just sending two bans and letting one fail as it will require less work and fewer packets.

True, well thanks guys, i figured out SweepBan :)
Works perfect

What are you going to do if someone has a name like [USERLOSER], and they're not really an operator? ;D

That's what the entire thread was about...........

[quote author=Hitmen link=board=17;threadid=2576;start=0#msg20273 date=1062806901]
That's what the entire thread was about...........
[/quote]

No, he asked how to avoid the [ and ] in a username, which would usually mean that the user is an operator when doing /who <channel>. Which that wouldn't be the best way to ban all the users in a channel, which I stated in my reply.

[quote author=UserLoser link=board=17;threadid=2576;start=0#msg20280 date=1062809963]
No, he asked how to avoid the [ and ] in a username, which would usually mean that the user is an operator when doing /who <channel>. Which that wouldn't be the best way to ban all the users in a channel, which I stated in my reply.
[/quote]

Yes but Camel explained above about that situation and suggested a fix.

oh well, i don't tend to read long posts that don't intrest me or matter to me at all

and yet you reply to them?

The standard should be to remember a user's flags.

When it comes time to ban, check the flags. Don't waste your time trying to ban someone who is unbannable, such as an operator.

However you keep track of users, an array or whatever, should keep track of flags as well.

[code]
Public Type USER_LIST_ENTRY
UserName As String
BnetFlags As Long
End Type
Public ChannelUsers() As USER_LIST_ENTRY
[/code]

Dozens of ways to do it, that's just a suggestion. Doing a "/who" should never be necessary if you have been tracking users adequately.

... they want to ban all users who are in a channel other than the one in which the bot presently resides. Why such a waste of queue space is desired is beyond me, however.

[quote author=Kp link=board=17;threadid=2576;start=0#msg20369 date=1062877117]
... they want to ban all users who are in a channel other than the one in which the bot presently resides. Why such a waste of queue space is desired is beyond me, however.
[/quote]

This is what I said when I was asked to include a sweepban feature in my bot. Naturally, I refused. However, due to popular demand, I added a very simple scriptable version that was disabled by default (note how all of the code is commented out).

Apparantly 'sweepban' is effective against flooders and spammers. I don't see how this is effective at all as bans go by cd key and not IP, but many users have figgured out that a simple alteration of the code to make it 'sweepsquelch' is very effective.

All of this to me is just fluff. The way I deal with flooders is to check if someone triggers too many concurrent 0x0F packets in a short enough time to be considered a flooder. If a flood is detected, the bot goes into lockdown mode for 60 seconds. Lockdown mode will ban any unrecognized user upon joining the channel.

[quote author=Camel link=board=17;threadid=2576;start=0#msg20385 date=1062886777]
[quote author=Kp link=board=17;threadid=2576;start=0#msg20369 date=1062877117]
... they want to ban all users who are in a channel other than the one in which the bot presently resides. Why such a waste of queue space is desired is beyond me, however.
[/quote]

This is what I said when I was asked to include a sweepban feature in my bot. Naturally, I refused. However, due to popular demand, I added a very simple scriptable version that was disabled by default (note how all of the code is commented out).

Apparantly 'sweepban' is effective against flooders and spammers. I don't see how this is effective at all as bans go by cd key and not IP, but many users have figgured out that a simple alteration of the code to make it 'sweepsquelch' is very effective.

All of this to me is just fluff. The way I deal with flooders is to check if someone triggers too many concurrent 0x0F packets in a short enough time to be considered a flooder. If a flood is detected, the bot goes into lockdown mode for 60 seconds. Lockdown mode will ban any unrecognized user upon joining the channel.
[/quote]
Something to consider:
So, the way for somebody to remove an operator running your bot program is to first, come in the channel and spam, and then do joinfloods?

Be careful when implementing this kind of automated security defense, lest it become a vulnerability in it's own right.

The bot flushes its queue as soon as it gets a 'That user is not logged on.' message. Because the bot stays in lockdown mode for 60 seconds, it is free to immediately ban the next floodbot.

I'm not sure if this is a solution to your proposal as I was somewhat unclear on what you were saying; reply again if it isn't. :)

[quote author=Camel link=board=17;threadid=2576;start=15#msg20447 date=1062918209]
The bot flushes its queue as soon as it gets a 'That user is not logged on.' message. Because the bot stays in lockdown mode for 60 seconds, it is free to immediately ban the next floodbot.[/quote]

If I'm understanding this correctly, this is where a priority queue comes in :)

[quote author=Skywing link=board=17;threadid=2576;start=15#msg20403 date=1062896146]
[quote author=Camel link=board=17;threadid=2576;start=0#msg20385 date=1062886777]
[quote author=Kp link=board=17;threadid=2576;start=0#msg20369 date=1062877117]
... they want to ban all users who are in a channel other than the one in which the bot presently resides. Why such a waste of queue space is desired is beyond me, however.
[/quote]

This is what I said when I was asked to include a sweepban feature in my bot. Naturally, I refused. However, due to popular demand, I added a very simple scriptable version that was disabled by default (note how all of the code is commented out).

Apparantly 'sweepban' is effective against flooders and spammers. I don't see how this is effective at all as bans go by cd key and not IP, but many users have figgured out that a simple alteration of the code to make it 'sweepsquelch' is very effective.

All of this to me is just fluff. The way I deal with flooders is to check if someone triggers too many concurrent 0x0F packets in a short enough time to be considered a flooder. If a flood is detected, the bot goes into lockdown mode for 60 seconds. Lockdown mode will ban any unrecognized user upon joining the channel.
[/quote]
Something to consider:
So, the way for somebody to remove an operator running your bot program is to first, come in the channel and spam, and then do joinfloods?

Be careful when implementing this kind of automated security defense, lest it become a vulnerability in it's own right.
[/quote]

Ive also added "Sweeptype" cmd to my bot, it can either auto-add the users to a database for later use, or squelch/ban users... It seems to work all good...