Anope IRC Services

Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1]   Go Down

Author Topic: Spammy-modes suggestion  (Read 2187 times)

0 Members and 1 Guest are viewing this topic.

Josh Johnson

  • Anope User
  • Offline Offline
  • Posts: 7
Spammy-modes suggestion
« on: March 31, 2009, 01:37:09 AM »

[Note, I'm a little behind on SVN. If this has been updated, just delete this. :O]
A while ago I saw a topic regarding spammy ChanServ->Clear->Bans/Excepts/Invites commands, and I had an idea on how to fix it.

*Some* modes could be delayed by a half a second (or so - allow admin to define how long this is?) to allow Anope to process extra mode-changes BEFORE sending them to the network to be changed. When the half-second is up, Anope would compile all the modes in the queue for the channel, and have them set all at once. Something like Eggdrop's mode-stacking, I guess you could say. :)

In this way, if !op !deop/etc commands are queued, Anope would set +o-o Blah Blah2 if Blah typed !op at the same time Blah2 typed !deop.

An alternative would be to purge the mode-stack when the program asks. Let me clarify:
Anope goes through the loop (Is it a loop? I haven't actually looked at the source. :\) to unset all the bans on a /cs clear bans command. Instead of pushing a -b to the server for each ban, it'd queue it up in the mode-stack, same as before. Instead of waiting for a half second, it wouldn't do anything until the command to push the mode stack to the channel. (Ex, put right after the loop?)
(When I say command, I mean literal program command, not /cs pushmodes or something random.)

With this way, you could have Anope stack the modes for every command, but only for designated commands. Anope devs would have to stick the command in the source code wherever it should use the stack. Would be better on resource, methinks, but wouldn't quite work for the first scenario where Blah uses !op and Blah2 uses !deop at the same time.

For both options, there's the problem of running over the maxmodes limit, which is easily fixed with the protocol module, methinks, or in a 005 numric parse. (Or some other like means.). Another maxmodes fix would be a hardcoded six (6) modes per mode command.

There may be a better way, but I think both, if not at least one, of these would be great additions in some way or other, be it hard coded, or using an option. :p chanserv { modestack = 1 }

Unrelated and off-topic, this would be good bases for !op nick1 nick2 nickN.
Logged

Naram Qashat

  • Team
  • *
  • Offline Offline
  • Gender: Male
  • Posts: 192
    • CBX's Sprite Animations
Re: Spammy-modes suggestion
« Reply #1 on: March 31, 2009, 04:50:36 PM »

There hasn't been any work done to accomplish this, however, this is a good plan for something to do in the future of 1.9.x.  I personally don't like seeing Anope do eleventy billion lines of mode changes when it could compact them to a few lines, if done right.
Logged
Pages: [1]   Go Up