$chan(<chan>).mode shows the modes as well as the key (when +k is set), only $chan(<chan>).key should show it.

Should it? How do you figure that?

The key isn't a mode, it's a mode parameter, mirc doesn't return the parameter of the +f mode, it also makes sense that if you have a propriety for the key, you don't need the key there

You could say the same about +l then, but $chan().mode returns that too. As far as +f goes, I don't know exactly what that is on whatever network you're using it, but if the mode is correctly defined in the CHANMODES token of raw 005 and $chan().mode doesn't return it/its parameter then that is the bug IMO.

Indeed, there's a limit propriety, +l shouldn't show that too.
And yes, the network correctly give +f in the raw 005

AFAIK $chan().mode just stores the value of raw 324 when you join a channel, so it would be dependent on whether the server provides +f (or any other mode+parameter) in that raw response. IIRC +f is something to do with flood control or something(?) in which case I think it's only made known to users once they're opped in the channel. If so I assume the network sends a new 324 upon the user being opped. Maybe mIRC doesn't update $chan().mode in that instance? I dunno, that's all supposition, maybe you can confirm if I'm along the right lines of what +f does and how it behaves.

thats correct, +l shouldn't be shown as well. your argument about +f is incorrect:





Additionally, a linked channel, /MODE #1stChan +L #2ndChan is also not shown in $chan($chan).mode like expected, one can see that as a bug since there is no way to access that without implementing your own raw event.

And that's the initial 324 provided upon joining that channel? Also, could you paste the CHANMODES token from raw 005 for that connection.

+l : 1651
+k : lol
+L : #test
+f : [2c#C1,2j#i1,2k#K1,3n#N1]:1

Really, only +k and +l are affected while they do have their own propriety..

And just to be clear here, that raw 324 is the one provided when you join the channel, or after you're opped?

I don't see that the existence of the .key/.limit properties precludes them from being present in .mode. I'm not aware of anything in the helpfile that suggests that should be the case, or anything at all that says that the two are connected in any way. Generally if you want to know the channel modes you'd want to know them all, not have to make some additional /if's for limit and key to add them in manually. .limit and .key are simply convenience methods to get that information without a scripter having to know how to properly parse modes to connect them with their proper parameters. Like I said before, if there is a bug here it seems to me it's the fact that mIRC is failing to return all appropriate modes that it knows about.

PS. Does that +f mode's parameter have a space in it? Dear God, whoever wrote that IRCd needs to be shot in the groin.

No space, and I regard it as a great feature of Unreal. Needs getting used to though...

There is only one notice, once you join the channel.I don't understand, the quote show how it is used, /mode # +f param, not sure what you mean with "a space in it" since parameter are space seperated.
Horstl helped

The help file talks about mode, not mode and their parameters, but I can see how this could be taken as "it returns the whole thing".
You might be right about what the problem really is though.
Either .mode returns the mode so +k and +l parameter shouldn't be there, or it returns mode and their parameter, and in this case +L and +f parameters should be shown.

Another related problem, there's no way to get the parameter of +L without a raw event