mIRC Homepage
Posted By: westor $chan($chan).mode bug - 25/06/14 01:00 PM
Hello,

I have an problem when i using $chan($chan).mode does not dipslay the correct results, does not display the +l and +k that these 2 channel modes are the standar of any IRCD, also i have try the /remote off and same problem.
Posted By: Loki12583 Re: $chan($chan).mode bug - 25/06/14 01:54 PM
I'm guessing since these two modes are handled by the limit and key properties that this is on purpose.
Posted By: westor Re: $chan($chan).mode bug - 25/06/14 02:33 PM
Does not display the +l and +k into the $chan($chan).mode i don't mean the parameters for the parameters i use the prop .key and .limit but how can i check if the +l is set into the channel, that brakes my script since i use 7.34
Posted By: Loki12583 Re: $chan($chan).mode bug - 25/06/14 03:15 PM
If $chan(#).limit > 0 then +l is set to that value.
Posted By: westor Re: $chan($chan).mode bug - 25/06/14 03:19 PM
Yes that is not way, but the correct it should be to display on the $chan($chan).mode , also what about the +f (flood protection mode)? that this mode does not have any prop..
Posted By: Loki12583 Re: $chan($chan).mode bug - 25/06/14 03:25 PM
https://forums.mirc.com/ubbthreads.php/topics/230589/chan_mode
Posted By: westor Re: $chan($chan).mode bug - 25/06/14 03:28 PM
I've already read this post and i have not seen something to solve my problem.
Posted By: westor Re: $chan($chan).mode bug - 25/06/14 03:48 PM
Well, After a big test, we find a solution for the $chan($chan).mode and i think this MUST exist in the mIRC core code because users does not know this way.

/mode #channel
//echo MODES: $chan(#channel).mode
This will display the results 100% correct.

-

//echo MODES: $chan(#channel).mode
This will NOT display the results 100% correct.

NOTE: So the issue in this identifier is to find an way (with /mode #channel i think) to take the correct results and then return it correct to the identifier, otherwise the problem will exist and on the future versions.

- Thanks!
Posted By: Khaled Re: $chan($chan).mode bug - 25/06/14 05:48 PM
This looks okay to me. The $chan() identifier returns the information that the server has provided in the MODE event. If the MODE event does not include this information, mIRC will not know it. Some servers provide this information when you join the channel whether you are an op or not. Other servers do not provide this information if you are not an op. Depending on the type of server you are using, you may need to issue a MODE to retrieve this information after you are made an op in order to update $chan().
Posted By: westor Re: $chan($chan).mode bug - 25/06/14 06:47 PM
Originally Posted By: Khaled
This looks okay to me. The $chan() identifier returns the information that the server has provided in the MODE event. If the MODE event does not include this information, mIRC will not know it. Some servers provide this information when you join the channel whether you are an op or not. Other servers do not provide this information if you are not an op. Depending on the type of server you are using, you may need to issue a MODE to retrieve this information after you are made an op in order to update $chan().


I have try it and with /remote off and the problem still exist but there is an issue on this identifier i don't know why or how.. the only now solution is to use /mode before the $chan(#).mode identifier.
Posted By: Loki12583 Re: $chan($chan).mode bug - 25/06/14 07:36 PM
Okay, one thing I do notice is that if +l and +k are set when you're in the channel they're not added to the mode. Other modes do get added though, and removing -l and -k from the room (after joining a room with +lk already set) does remove them from the identifier.
Posted By: Khaled Re: $chan($chan).mode bug - 25/06/14 08:17 PM
This is not related to /remote on or off. mIRC will automatically fill $chan() values whenever it sees a MODE event, regardless of whether /remote is on or off. For an explanation of why this happens, please see my earlier post.
Posted By: Khaled Re: $chan($chan).mode bug - 25/06/14 08:20 PM
The $chan() identifier depends on the server to send a MODE event with the +l and +k values. This is the only way that $chan() is filled. If you use /debug on to monitor the MODE event that the server sends, is it sending all of the values?
Posted By: Loki12583 Re: $chan($chan).mode bug - 25/06/14 08:34 PM
The server sends all modes when joining, and individual modes as they are changed. It's clear that mIRC receives the modes because .limit and .key are filled properly, they just aren't in .mode.

Code:
[16:31:27] * Now talking in #a
[16:31:41] <Membear> Mode: +npstlk 3 a
[16:31:48] * Memnoch sets mode: -lk a
[16:31:55] <Membear> Mode: +npst
[16:32:09] * Memnoch sets mode: +lk 3 a
[16:32:14] <Membear> Mode: +npst

Code:
-> irc.us JOIN #a a
<- :Membear!Memnoch@IP JOIN :#a
-> irc.us MODE #a
<- :irc.us 353 Membear @ #a :@Memnoch!memnoch@IP Membear!Memnoch@IP 
<- :irc.us 366 Membear #a :End of /NAMES list.
<- :irc.us 324 Membear #a +klnpst a 3
<- :irc.us 329 Membear #a 1403704175
-> irc.us PRIVMSG #a :Mode: +npstlk 3 a
<- :Memnoch!memnoch@IP MODE #a -lk a
-> irc.us PRIVMSG #a :Mode: +npst
<- :Memnoch!memnoch@IP MODE #a +lk 3 a
-> irc.us PRIVMSG #a :Mode: +npst

Code:
<- :irc.us 005 Membear AWAYLEN=201 CASEMAPPING=rfc1459 CHANMODES=IYbe,k,Ljl,CKMORScimnprstuz CHANTYPES=# CHARSET=ascii ELIST=MU EXCEPTS=e EXTBAN=,CORScz FNC INVEX=I KICKLEN=256 MAP MAXBANS=60 :are supported by this server
<- :irc.us 005 Membear MAXCHANNELS=20 MAXPARA=32 MAXTARGETS=20 MODES=20 NAMESX NETWORK=irc.us NICKLEN=33 PREFIX=(qaohv)~&@%+ SECURELIST SSL=0.0.0.0:6697 STARTTLS STATUSMSG=~&@%+ TOPICLEN=308 :are supported by this server
<- :irc.us 005 Membear UHNAMES VBANLIST WALLCHOPS WALLVOICES :are supported by this server

Posted By: Khaled Re: $chan($chan).mode bug - 25/06/14 09:25 PM
Thanks I was able to reproduce the issue. This is not related to different types of servers sending/not sending modes, as I thought in my earlier post. It is due to item 9 in v7.33 where the mode routine was changed to allow non-alphanumeric characters as modes due to some networks using them. This issue should be fixed for the next version.
© mIRC Discussion Forums