Forums Bug Reports freenode +q (quiet) triggers "on owner"

It appears that the "on OWNER" event triggers when a +q entry is added to the channel list on FreeNode. However, on FreeNode +q means "quiet", which is more like a ban. I believe that mIRC should be checking against the 005 PREFIX= token to see if +q is actually a channel-member prefix, and not trigger "on OWNER" (etc) if it's not.

As a sidenote, it probably wouldn't hurt if "on OWNER/DEOWNER" and "isowner" were added to the help file. I don't know how widely used the owner feature is across IRC networks, but people do ask about it every once in a while, and it looks like it's only in versions.txt right now.

Edit: credit where credit is due, this bug report is an (indirect) result of an observation by KindOne.

I think these events/operator are not widely used because a lot (most?) of unrealircd server chose not to provide a prefix for +q, meaning you can't properly track this mode, isowner/$nick(,q) fail on these servers although the mode is set, that's probably the reason it didn't make it to the help file

Well, you're probably right about that being the reason. However, I don't think mIRC's behavior or documentation should be dictated by broken servers, as that's rather unfair for people on networks that do behave sanely. In fact, the latter group appears to include three of the top-10 IRC networks right now (Rizon, ChLame, LinkBr) (I didn't look very carefully so correct me if I'm wrong). I see the issue though; perhaps mIRC could test the server software name against "unreal" or something like that, to retain its current behavior there? I believe it's doing similar things for other cases already?

I'm not against the addition of those to the help file, I was just trying to find a rational reason as to why it's not there already.

Don't get me wrong, what you reported is indeed a bug, it just need to be fixed. I'm not saying those unrealircd server provide a broken 005 raw, they just don't provide a prefix for the mode, mIRC works as good as it can for unrealircd. There is no need to change the current behavior, just a need to fix this bug.

Hehe I don't think we're in disagreement at all, but your point about unrealircd does change things a little. The problem is that if freenode's ircd and unrealircd both report +q as being a regular channel list mode and not a prefix, then mIRC will have a hard time distinguishing between the two cases. This would be fine, since unrealircd is the one using the notion of ownership in a nonstandard way [*] and there is no matching "on QUIET" for freenode either (etc), except that my suggested fix of using the 005 PREFIX would break "on OWNER" on unrealircd, which is presumably not going to make its users happier either. If this is indeed limited to unrealircd, then doing an ircd name check on unrealircd could preserve the current behavior on those servers, while still fixing the bug in general, but it does make the fix a little bit more complicated.

[*] although historically it might not have been nonstandard at the time it was added to unrealircd, since the owner prefix is apparently an IRCX concept which gradually made it into regular IRC servers? I'm not sure, but either way, the prefix version of ownership seems to be the common one now..

My recommentation about the ON "OP,DEOP,VOICE,DEVOICE,HELP,DEHELP,OWNER,DEOWNER" events is to remove them, because the ON RAWMODE is already doing the job like them, having 2 events that is doing the same job for me is very unuseless, and Wims is right there are events that missing from the help file, as i had in the past suggested something about them but we did not get any final answer: https://forums.mirc.com/ubbthreads.php/topics/250558

Removing features that are heavily relied upon by existing scripts? ..are you new here?

Yes i am here and i say my opinion to remove them whats the point to have 2 events to do the same job??

Do you have 2 same cars into your garage?

These events have been a part of the scripting language since 1995. They cannot be removed or changed as this would break all existing scripts that use them.

I haven't had a chance to look into this yet but if it looks like an ircd name check is the only way to solve it, I can add that.

Cool! Thank you.

Even if we ignore the legacy aspect, the main strength of mIRC's scripting language has always been that it lets people achieve many simple things with ease. For basic and common scripting problems such as thanking someone for opping you on a channel, "on OP" provides an easy solution, whereas "on RAWMODE" poses an insurmountable parsing challenge for a beginner. As a result, both events are valuable even if one is strictly speaking a superset of the other.

So yes, I have both a hatchback and a five-ton truck in my virtual garage. One is for getting around town, and the other is for doing heavy lifting for the few occasions where that is needed.

If you want to keep your position, you should be aware that "on PARSELINE" now covers a superset of "on RAWMODE" (and most other events), too.

Just a quick note here on PARSELINE shouldn't be used as a superset to events. Its meant for the altering of a connection's input/output streams for purposes of supporting non-irc standardized messages

But it can be. I think to Sat's point, being able to do something in multiple ways does not mean that any of the alternate ways should be removed. If that were the case, mIRC would just need to expose all named events through raw * and be done with ever providing other IRC events.

There are MANY languages where "there is more than one way to do it". mIRC is one of them, but it's not the only one.