|
|
Joined: Sep 2006
Posts: 12
Pikka bird
|
OP
Pikka bird
Joined: Sep 2006
Posts: 12 |
Noticed this "problem" recently upgrading from 6.02 -> 6.2 (I know big jump, no clue when it was changed)
If you join a channel and are auto-op'd BEFORE receiving raw 324/329 mIRC will request a mode #channel again... resulting in a double raw from the server for both numerics...
Speaking to an IRCop on dalnet thinking it was a desync problem on their end resulted in me finding the problem originating from mIRC... (I was told it may be because some networks hide channel keys and/or limits, but when op'd it re-requests the information... but this only seems to happen when you are lagged.)
To duplicate, join a channel with 20-30+ users and /who on join to lag yourself, if you are op'd before /who results, mIRC requests mode results a second time.
-Rappy
|
|
|
|
|
Joined: Dec 2002
Posts: 1,541
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 1,541 |
I never noticed this and have been on channels arond 30 - 40 usersd. When I was opped, I'd /who # on join to make sure people were opped, to update my lists of ops, etc and never had that problem (that I noticed - that's an important thing, I never NOTICED it)
Those who fail history are doomed to repeat it
|
|
|
|
|
Joined: Dec 2002
Posts: 5,420
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 5,420 |
That sounds about right, mIRC sends a mode when you first join a channel, which returns the channel mode when you are not an op (and will not contain the hidden channel key). When you are opped, mIRC resends the mode so that it can get the mode when you are an op, which will contain the channel key.
For servers that do not hide the channel key, mIRC checks before sending the second mode to see if it already has the key, and if it does, it does not resend the mode. Of course if there is server lag and mIRC has not received the reply from the first mode, there's no way for it to know what the first mode will contain, so it resends the second mode.
|
|
|
|
|
Joined: Sep 2006
Posts: 12
Pikka bird
|
|
OP
Pikka bird
Joined: Sep 2006
Posts: 12 |
Can this be changed so that it waits for a raw 324/329 before resending the mode #channel on op? If the server hides the key for +k channels, I assume mIRC does not resend mode #channel if the channel is -k. Either way mIRC should receive a raw 324/329 when requesting a mode #channel, so this should be an easy check? IE wait for the raw return before re-requesting mode #channel upon op, when you get it, if the channel is +k, re-request the mode to get the key... On a final note... Dalnet doesn't hide the channel key to non-ops, so maybe the second mode could be 'disabled' altogether on dalnet networks? And as for landonsandor... I /who # on join too, and that's how I noticed this... but either way, sometimes it's not the /who that does it, often times it's a join lag from joining several channels at once on a connect to a server...
[09:19pm] <- :routed!hmm@dialup-4.235.153.142.Dial1.Orlando1.Level3.net JOIN :#xxxxxxxxxx
[09:19pm] -> swiftco.wa.us.dal.net MODE #xxxxxxxxxx
[09:19pm] <- :swiftco.wa.us.dal.net 332 routed #xxxxxxxxxx :"You're a high priced lawyer, if I give you $500, will you answer two questions for me?" "ABSOLUTELY! What's the second question?"
[09:19pm] <- :swiftco.wa.us.dal.net 333 routed #xxxxxxxxxx CreQ 1160608090
[09:19pm] <- :swiftco.wa.us.dal.net 353 routed @ #xxxxxxxxxx :routed @evulish @bugz m0dule @CreQ @proxie @malady WD_40 @plastick @Unimatrix0 fearphage WD-Laptop @NiMH @Pack_Man @myndzi @ComputerEyes @im_a_robot
[09:19pm] <- :swiftco.wa.us.dal.net 366 routed #xxxxxxxxxx :End of /NAMES list.
[09:19pm] <- :ChanServ!service@dal.net MODE #xxxxxxxxxx +o routed
[09:19pm] -> swiftco.wa.us.dal.net MODE #xxxxxxxxxx
[09:19pm] <- :swiftco.wa.us.dal.net PONG swiftco.wa.us.dal.net :FLOODCHECK
[09:19pm] -> swiftco.wa.us.dal.net PING :FLOODCHECK
[09:19pm] <- :swiftco.wa.us.dal.net 324 routed #xxxxxxxxxx +stn
[09:19pm] <- :swiftco.wa.us.dal.net 329 routed #xxxxxxxxxx 1071697501
[09:19pm] <- :swiftco.wa.us.dal.net 324 routed #xxxxxxxxxx +stn
[09:19pm] <- :swiftco.wa.us.dal.net 329 routed #xxxxxxxxxx 1071697501
[09:19pm] <- :swiftco.wa.us.dal.net PONG swiftco.wa.us.dal.net :FLOODCHECK
[09:19pm] -> swiftco.wa.us.dal.net WHO #xxxxxxxxxx
-Rappy (routed)
|
|
|
|
|
Joined: Dec 2002
Posts: 5,420
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 5,420 |
Even if mIRC waits for the first mode to return, it still won't know if it has the full mode list, since the mode was issued while you were not an op, and just checking for a +k key value may not be enough, eg. some networks might hide multiple mode keys from you when you are not an op.
In order for mIRC to avoid sending a second mode, it would need to know whether the server hides keys or not. One solution would be to add a new 005 numeric token, such as OPMODE=N, where 0 means modes are not hidden, and 1 means modes are hidden.
|
|
|
|
|
Joined: Oct 2005
Posts: 1,741
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2005
Posts: 1,741 |
The OPMODE could show which modes are hidden from non-ops.. OPMODE=0 <- no hidden modes, OPMODE=klwej <- modes klwej are hidden.
-genius_at_work
|
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
Certain modes might be hidden at different user levels, so... SHOWMODE=v:k,h:abc,o:d.
Just on the offchance an IRCd coder reads the thread and implements, figure we might aswell make it properly futureproof.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
|
