Why not? Because it makes writing scripts 5000000x easier? Imagine this (Javaish):
import mirc.floodkicker;

class NickFloodKicker extends FloodKicker implements OnNick {
   public NickFloodKicker(%channel) {
      ;Set this to monitor on %channel
      ;Set a flood as 5 in 60 seconds

   public OnNickChange(%oldnick, %newnick) {
      ;On nick change, increase the flood count
      if (%oldnick ison $this->%channel) {
         ;Increase the number of actions for this user
         ;Change the name of the counter, so that it is now called %newnick so it can still be monitored

/new $NickFloodLimit(#test)

And that would be all you'd have to write to make a nick flood kicker. The FloodLimit class, which would either be internal, or written by someone else for reusability, would handle everything else, the testing if it 5 in 60 seconds, resetting the counter, kicking the user, etc. All you have to do is tell it to monitor the channel, and to increase the number of recorded actions by that user. You are going to tell me that doing it like that is not useful? Imagine how many other dozens of taks would be simplified. Another example would be an MP3 player, all the basic stuff, playlists, play/pause/etc. would be in an MP3 class, then when you create an MP3 player, you just have to add to the prebuilt playlist and create a GUI. It would simplify virtually EVERY script task I can think of. Think of the current nick flood scripts, are you going to tell me you could, using mIRC's current scripting system, create a nick flood kicker as easily as I just did?

Last edited by codemastr; 27/08/03 08:04 PM.