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 (http://forum.valhallalegends.com/phpbbs/index.php?board=17;action=display;threadid=2571;start=15).
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 from: DaRk-FeAnOr on September 04, 2003, 01:28 AM
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.
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 from: Hitmen on September 05, 2003, 07:08 PM
That's what the entire thread was about...........
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 from: UserLoser on September 05, 2003, 07:59 PM
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.
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.
Public Type USER_LIST_ENTRY
UserName As String
BnetFlags As Long
End Type
Public ChannelUsers() As USER_LIST_ENTRY
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 from: Kp on September 06, 2003, 02:38 PM
... 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.
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 from: Camel on September 06, 2003, 05:19 PM
Quote from: Kp on September 06, 2003, 02:38 PM
... 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.
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.
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 from: Camel on September 07, 2003, 02:03 AM
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.
If I'm understanding this correctly, this is where a priority queue comes in :)
Quote from: Skywing on September 06, 2003, 07:55 PM
Quote from: Camel on September 06, 2003, 05:19 PM
Quote from: Kp on September 06, 2003, 02:38 PM
... 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.
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.
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.
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...