mIRC Homepage

on exempt REQUIREMENT + on chanmode suggestion

Posted By: s00p

on exempt REQUIREMENT + on chanmode suggestion - 15/04/10 10:46 AM

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.
Posted By: Wims

Re: on exempt REQUIREMENT + on chanmode suggestion - 15/04/10 11:51 AM

Why did you fill a bug report ?
On mode is for channel mode, that's why there's on ban on op etc (things related to users).
+e isn't in the RFC, that's why there's no event (like the +q/+a)
That's also why there's on rawmode, let you trigger anything you want.
Posted By: Collective

Re: on exempt REQUIREMENT + on chanmode suggestion - 15/04/10 11:53 AM

There already exists the on RAWMODE event and $mode identifier. Perhaps the latter should be extended to work for all mode chars which take a parameter.

Until then you can use starbucks_mafia's solution.
Posted By: s00p

Re: on exempt REQUIREMENT + on chanmode suggestion - 15/04/10 12:15 PM

Originally Posted By: Wims
Why did you fill a bug report ?

I consider it inconvenient that I can't easily access exempts, and I figured this might be something that was missed. As you'll find by carefully reading this post, exempts are part of the standard.

Originally Posted By: Wims
On mode is for channel mode, that's why there's on ban on op etc (things related to users).

Thanks, I did quite obviously acknowledge that. You seem to be inadequate at reading. I suggest improving your comprehension skills.

Originally Posted By: Wims
+e isn't in the RFC, that's why there's no event (like the +q/+a)

Neither is RAW 004 , according to RFC1459 (the old standard). However, mIRC still implements $chanmodes, $chantypes, etc. I suppose it depends which RFC you read, huh? Here's a quote from the RFC 2811 (part of the standard for IRC as modified in 2000): "e - set/remove an exception mask to override a ban mask;" Perhaps you didn't know there's an update to RFC1459? Or your comprehension skills need improvement... (edit: fyi, +q and +a are channel modes according to RFC2811, but they don't do what you believe they do... 004 is standard as described in RFC2812)

Originally Posted By: Wims
That's also why there's on rawmode, let you trigger anything you want.

I'm well aware of that, however it doesn't quite provide the functionality that I suggested. Read over my original post carefully if you wish to know more, because I do believe I provided an adequate explanation.

Originally Posted By: Collective
There already exists the on RAWMODE event and $mode. Perhaps the latter should be extended to work for all mode chars which take a parameter.

I'm well aware of that, however it doesn't quite provide the functionality that I suggested. Read over my original post carefully if you wish to know more, because I do believe I provided an adequate explanation.

Originally Posted By: Collective
Until then you can use starbucks_mafia's solution.

I appreciate your suggestion. However after reading over his solution briefly, I won't be using it. I'll post my solution once I'm done, so you can see and hopefully understand why. I would suggest reconsidering the language that you use to infer your suggestions in the future.

Thankyou, guys.
Posted By: Collective

Re: on exempt REQUIREMENT + on chanmode suggestion - 15/04/10 12:55 PM

Originally Posted By: s00p
I'm well aware of that. Read over my original post carefully if you wish to know more, because I do believe I provided an adequate explanation.

Somehow I doubt you were aware of on RAWMODE before it was mentioned here, as it would certainly have warranted a mention given that you started your post bemoaning the lack of "the ability to catch chanmode +e/-e events", which on RAWMODE provides (however awkwardly).

As for your 'popping' suggestion, it seems to be a solution in search of a problem. Are there actually any IRC servers currently employing modes that take multiple, space-delimited parameters? I've never seen one. Of course, even if such modes are in use on RAWMODE allows scripters to parse the entire mode line, so your suggestion seems to provide little extra benefit. As an aside, both on RAWMODE and $mode would have been relevant here, and again you mentioned neither.

Quote:
I would suggest reconsidering the language that you use to infer your suggestions in the future.

I have reconsidered my use of language and find it most pleasing. Your misuse of "infer", however, risks angering the Language Gods greatly.

How is your mIRC replacement progressing, by the way?
Posted By: n00py

Re: on exempt REQUIREMENT + on chanmode suggestion - 15/04/10 01:29 PM

Firstly, to whoever banned me, I would greatly appreciate an explanation. My responses have been as curteous as possible without completely cramming it down their heads that they haven't read my original post accurately.

Secondly, if you had read my original post carefully, you might have noticed that on RAWMODE doesn't provide the functionality that I've suggested. Why should I have to use on RAWMODE to parse chanmodes, any more than I should have to use on RAWMODE to parse something that on USERMODE should?

Thirdly, there may not be any IRC servers that currently employ modes that take multiple, space-delimetered parameters, however there is +a, which as the standard dictates, is mode "anonymous" for a channel (and requires an argument). Many popular non-compliant IRCds use +a as a form of "more powerful +o", or kick-protection, which both require an argument.
Any other modes that you can think of that are standard, but not treated in a compliant fashion by popular IRCds? Use your head.

My "mIRC alternative" is coming along slowly, as study at college has taken top priority. How is your "standing in the way of progress" progressing, by the way?
Posted By: Collective

Re: on exempt REQUIREMENT + on chanmode suggestion - 15/04/10 01:39 PM

Originally Posted By: s00p
Secondly, if you had read my original post carefully, you might have noticed that on RAWMODE doesn't provide the functionality that I've suggested. Why should I have to use on RAWMODE to parse chanmodes, any more than I should have to use on RAWMODE to parse something that on USERMODE should?

Thirdly, there may not be any IRC servers that currently employ modes that take multiple, space-delimetered parameters, however there is +a, which as the standard dictates, is mode "anonymous" for a channel (and requires an argument). Many popular non-compliant IRCds use +a as a form of "more powerful +o", or kick-protection, which both require an argument.
Any other modes that you can think of that are standard, but not treated in a compliant fashion by popular IRCds? Use your head.

There's no need to be so defensive. I already addressed this in my original reply when I suggested that $mode could be extended to handle all modes that take parameters, so either you didn't read my post, or you still don't know what $mode is.

That, in addition to there being no existing modes that take multiple parameters, means there's absolutely no reason to implement a new, parameter-popping event mechanism. Which renders your suggestion pointless. Oh, perhaps that's why you're being so defensive?
© 2022 mIRC Discussion Forums