|
Joined: Dec 2008
Posts: 1,515
Hoopy frood
|
OP
Hoopy frood
Joined: Dec 2008
Posts: 1,515 |
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.
|
|
|
|
Joined: Jan 2004
Posts: 1,358
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 1,358 |
I'm guessing since these two modes are handled by the limit and key properties that this is on purpose.
|
|
|
|
Joined: Dec 2008
Posts: 1,515
Hoopy frood
|
OP
Hoopy frood
Joined: Dec 2008
Posts: 1,515 |
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
|
|
|
|
Joined: Jan 2004
Posts: 1,358
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 1,358 |
If $chan(#).limit > 0 then +l is set to that value.
|
|
|
|
Joined: Dec 2008
Posts: 1,515
Hoopy frood
|
OP
Hoopy frood
Joined: Dec 2008
Posts: 1,515 |
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..
|
|
|
|
Joined: Jan 2004
Posts: 1,358
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 1,358 |
|
|
|
|
Joined: Dec 2008
Posts: 1,515
Hoopy frood
|
OP
Hoopy frood
Joined: Dec 2008
Posts: 1,515 |
I've already read this post and i have not seen something to solve my problem.
|
|
|
|
Joined: Dec 2008
Posts: 1,515
Hoopy frood
|
OP
Hoopy frood
Joined: Dec 2008
Posts: 1,515 |
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!
|
|
|
|
Joined: Dec 2002
Posts: 5,420
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,420 |
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().
|
|
|
|
Joined: Dec 2008
Posts: 1,515
Hoopy frood
|
OP
Hoopy frood
Joined: Dec 2008
Posts: 1,515 |
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.
|
|
|
|
Joined: Jan 2004
Posts: 1,358
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 1,358 |
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.
|
|
|
|
Joined: Dec 2002
Posts: 5,420
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,420 |
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.
|
|
|
|
Joined: Dec 2002
Posts: 5,420
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,420 |
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?
|
|
|
|
Joined: Jan 2004
Posts: 1,358
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 1,358 |
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. [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 -> 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 <- :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
|
|
|
|
Joined: Dec 2002
Posts: 5,420
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,420 |
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.
|
|
|
|
|