Forums Bug Reports Channel Limit display bug (when used with +f)

If chanmode +f is set, the channel limit takes the first number of +f x:x and shows up as the channel limit.

So if you set /mode #chan +f 5:10 and then /mode #chan +l 15, mirc will show the channel limit as 5 when you rejoin that channel.

Here is the information provided by the IRCD Software:

--- TOPICLEN=307 KICKLEN=255 MAXTARGETS=20 AWAYLEN=200 CHANMODES=Iqageb,k,LfJjl,SzrRMOTNQVCKGcpsmnti FNC NETWORK=StaticBox MAXPARA=32 EXCEPTS=e INVEX=I OVERRIDE REMOVE SILENCE=999 :are supported by this server

i dont see why it should ignore the +f, it is published in the 005 numeric.

If you need any more information let me know.

We use the InspIRCD software

I'm not seeing anything wrong on my side. I tested this on an UnrealIRCd server and it's showing the modes correctly. This may be a problem with the way the IRCd outputs the channel's modes when you join. It may be showing something like "+ntrfl 5 [3t:5]". Which then I believe mIRC would be parsing the modes correctly, as the f is the first mode with an parameter it will use that "5" since it's the correspondes with the +f.

This seems it may be an IRCd issue. Could you please /debug @debug in mIRC, then when you /join a channel could you copy the line that shows the channel modes. should hopefully appear something like
":server: <raw> <Your-Nick> <CHannel> +<modes>".


Hopefully I'm not incorrect and hopefully you can understand what I'm trying to say. =x

-zach

i am not using Unrealircd :P, so the +f modes are not the same

<- :hades.staticbox.net 324 test #arcadia +CTfjlnt 12:6 20:10 30

Well after toying around on the server you showed, I've noticed that it outputs the the +f as "<lines>:<seconds>" where as others (UnrealIRCd) ouputs "[<lines>t]:<seconds>".
I also noticed that UnrealIRCd outputs in the order of +lf, where as the InspIRCd outputs +fl. Thought the parameters correspondes correctly with each mode on each IRcd, I doubt the order makes a difference when mIRC parses it.

Either way, mIRC is using the incorrectly parsing the mode of the channels when received.

I can verify this. mIRC is ignoring the +f mode's presence in CHANMODES= as being one that has a variable, and isn't skipping it when it comes before the +l.