The following code isn't triggered when I set a +e in mIRC 6.35.

Code:
on @1:MODE:#: {
  echo -a -- $1-
}


I understand that the documentation isn't supposed to be triggered for "user mode changes such as ops, bans, etc" (quoted from the help docs, I gather +e falls under the "etc")... While there are "on BAN" and "on UNBAN" events, there appears to be no "on EXEMPT" and "on UNEXEMPT" events. I suggest adding them. This suggestion would add the ability to catch chanmode +e/-e events.

I would also like to see an "on CHANMODE" just in case other IRCds choose to implement lists that are odd. This event would be triggered for any channel mode change, regardless of whether it has an argument. For example, a script to store variable names that correspond to each mode and increase them easily as they are triggered:

Code:
on 1:CHANMODE:#:*: {
  hinc -m $hget(chanmodes,$chan) $1
  if ($1 == +k) {
    ; tell mIRC there are 2 arguments that it should pop off the $2- list for successive calls. This would be non-standard behaviour, but the ability to support this behaviour would surely be a great improvement
    return 2
  }
}

alias count_modechanges {
  echo -a Mode $1 has been $iif($getSign($1) == -,unset,set) $hget(chanmodes,$getSign($1) $+ $getMode($1)) times.
}


One might even suggest that $getSign and $getMode might be ideal (and appropriately renamed) as hardcoded functions. In the case that multiple modes are set with one command, mIRC would trigger the event once per mode in a left-to-right order, providing the mode (including sign) as $1, and arguments from the mode command in list form as $2-. A return value could be provided to mIRC to indicate how many arguments to pop off of this list for the successive invocations of this event. In the case that a return value isn't provided, mIRC should use the information provided by the ISUPPORT CHANMODE message (which has a default value if not provided) to determine whether to pop an argument off of the list. This suggestion would allow for an unbelievable amount of flexibility required when connecting to a non-compliant (IRCX) IRCd. It would also allow further abstraction when hooking more than one type of chanmode.

Last edited by s00p; 15/04/10 11:54 AM.