Forums Bug Reports little bug with mode parsing

after such servermode:

[11:12:09] * irc.cln.ru sets mode: +aovo jul jul jul JM

JM is not shown as operator, i.e. doesn't have @ prefix.

[08:32:06] * irc.server.com sets mode: +aovo Collective Collective Collective Someone

Can't reproduce this

I'd understand if you need to reproduce something in case of such post: "server makes me op, but I'm not show as op in mirc".

But now you've got exact mode "+aovo Collective Collective Collective Someone". Why can't you just pass it as parameter to mode parsing function or somewhat in the source?

Anyway, I understand that such mode is rear and there is no special need in fixing it. I've posted it just for info.

one more example
[16:04:46] * irc.cln.ru sets mode: +aoaooao _pavlik_ _pavlik_ s1lver s1lver Rockeep Nightingale Nightingale

pavlik and s1lver become ops,
Rockeep and Nightingale not

+a isn't a normal channel mode. So in order for mIRC to understand that it accepts a nickname as a parameter, the server needs to tell it. This must be done by the 005 numeric, which shows up on connect in your status window as a line ending with "are supported by this server". If you can find that line, I'll look for the +a mode and see if I can reproduce the bug and/or fix the 005 line (there's unfortunately no feature for changing the information you get from the 005 numeric so, uh, you'd have to ask the people running the network to change it).

Or I guess you could tell me what network it is and I'll find it.

I have confirmed, though, with no 005 numeric, mIRC reads the +a as a mode accepting no parameters and doesn't op "Someone". The default behaviour as stated in the help is to use PREFIX=(ohv)@%+ so this is exactly what it should do unless the server tells it otherwise. mIRC does process the mode correctly if it gets a value of PREFIX=(aohv).@%+ (I'm not sure what the prefix for mode +a should be, but it accepts the .). So this is probably a case of the server not giving mIRC the necessary information.

Many thanks for detailed reply. I've found prefix is set to "(ov)@+". I've contact one of administrators and he has told that it would be fixed with the newer version of ircd. Sorry, I wasn't familiar with 005 numeric.

Now I see that is not a bug in mirc. Therefore, sorry for bothering you.

IMHO, because the server isn't providing a prefix for the +a flag (as there is no prefix, +a just means protected and cannot be deopped or kicked), mIRC should treat the flag transparently and give them +o's @ prefix instead.

This is how I remember mIRC handling it when I was +ao Raccoon Raccoon'd on such a server a couple years ago.. I don't know if this behavior has changed though.

So, I'd say Khaled should look into this as being a bug.

- Raccoon

I'm pretty sure that's not the problem. The problem is that mIRC doesn't know that the 'a' mode takes a parameter. Presumably the mode isn't being set correctly in the CHANMODES token. BTW the a mode can and does have a prefix on many networks, usually a period.

Hmm, then it must be a different +a, because I know a non-opped user could also be +a. They wouldn't have op powers, though no op could ban or kick them the same.

I guess there's a point where mIRC simply can't keep up with all the diversity.

mIRC would work just fine if it were told what to do with mode +a. The 005 numeric can set it as a channel mode requiring a nickname/address as a parameter or as a prefix like +o.

mIRC does not store the prefixes, but gets them from the server when you connect.

As a simple explanation as to how mIRC gets this information, irc.x-tab.org (running UnrealIRCd for those who wanna know) sends the information as this:

(from RAW 005) PREFIX=(qaohv)~&@%+

Meaning that:
q (channel founder) would be displayed as ~Stealth`Warrior
a (protected) would be displayed as &Stealth`Warrior
o (op) would be displayed as @Stealth`Warrior
h (half-op) would be displayed as %Stealth`Warrior
-and-
v (voice) would be displayed as +Stealth`Warrior