mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 3 1 2 3
#37169 19/07/03 04:37 PM
Joined: Mar 2003
Posts: 10
M
MDTyKe Offline OP
Pikka bird
OP Offline
Pikka bird
M
Joined: Mar 2003
Posts: 10
Im not sure if this is a true bug or not, but on conference room servers, lets say my nick is "Matt", if I /mode #channel +yu MATT Matt, then it will change the case of my nick in that channel, even though my nick hasn't actually changed. It appears +y isn't actually an in-use mode on Conference Room servers, so I'm wondering if this is an actual bug on mIRC that is doing something it shouldn't :-P

Can anyone confirm this on other IRC Networks? Thanks a lot :-)

Matt

#37170 19/07/03 04:43 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
It would seem to me that if that really does exist, it is a problem with CR, not mIRC.

#37171 19/07/03 05:02 PM
Joined: Mar 2003
Posts: 10
M
MDTyKe Offline OP
Pikka bird
OP Offline
Pikka bird
M
Joined: Mar 2003
Posts: 10
I don't thinjk som, as it doesn't do it in other IRC Clients.. tried a few - Matt

#37172 19/07/03 05:07 PM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
/hs cmode

[03:06:11] -qld-chat.bigpond.com- r - Registered, R - n/a, s - Secret, t - Topic, u - Channel User, v - Voice, w - n/a, y - n/a, z - Encrypt Only

It's not a bug in mIRC or a problem with CR. The mode simply doesn't exist at channel level.

Also +u is a level of host status on CR which allows /cs invite and channel memo access. You cannot /mode #Room +u with it, it is given automatically.

#37173 19/07/03 05:16 PM
Joined: Mar 2003
Posts: 10
M
MDTyKe Offline OP
Pikka bird
OP Offline
Pikka bird
M
Joined: Mar 2003
Posts: 10
Im aware of that, but Im saying that when you DO use it, with +u or +v in mIRC, it changes the case of the nick.. ie: /mode #channel +yu MATT Matt (MATT being the new nick).. try it

Matt

#37174 19/07/03 05:27 PM
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Do a /debug @debug and look at the MODE line returned by the server. Paste those lines for us. It sounds like a bug with how mIRC interprets MODE responses (if the server changes your nick on you, mIRC follows suit), and with CR sending a back a response with your lowercase nick.

So it's likely a bug with both CR and mIRC. mIRC's end of it seems reasonable though, it's only handling the data given to it. Other clients seem to ignore when the server lies about your nick, making mIRC a slightly more gullible client (I TRUSTED YOU!).

- Raccoon


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
#37175 19/07/03 05:28 PM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
It does too. I wouldn't be too concerned though. It's undocumented and therefore is as good as not there. CR is a bit like mIRC - alot of things get put in and not added to the mIRC.hlp. HelpServ is much the same in that respect.

#37176 19/07/03 05:30 PM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
It is NOT a bug.

#37177 19/07/03 05:33 PM
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Where is your paste.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
#37178 19/07/03 05:40 PM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
My event looked the same as his but nonetheless if a mantufacturer indicates that something is not available then it can't be classed as a bug.

#37179 19/07/03 05:46 PM
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Actually. Commands that are unimplimented must not cause conflicts to the client. A simple "Command Not Implimented" response the proper response, and nothing else.

Care to paste what appears in /debug?

- Raccoon


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
#37180 19/07/03 06:02 PM
Joined: Mar 2003
Posts: 10
M
MDTyKe Offline OP
Pikka bird
OP Offline
Pikka bird
M
Joined: Mar 2003
Posts: 10
<- :Jeff!PkmnRed1.1@=vYae-rdazodbtspxvi3i-y-87.albyny.adelphia.net PRIVMSG #MediaDriven :do you have a shitlist
<- :ThUgAnOmIcS!ThUgOnOmIc@=WA076-31-659-21.wit.cvx.blueyonder.co.uk PRIVMSG #Matt :im a thug is distress!
-> irc.MediaDriven.com MODE #Services +yu TIEKS Tieks
<- :Matt!Matter@irc.mediadriven.ops MODE #Services +yu TIEKS Tieks
<- :RoughKnight!QuietOne..@=lcSwitxf-SDE-seq827374.sympatico.ca PRIVMSG #NoHacks :Bee

#37181 19/07/03 06:14 PM
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
And mIRC changes the nick TIEKS to appear as Tieks in the nicklist? That's kind of interesting.

I'd say it's more of mIRC's fault then in this case. I can't imagine why it would be updating the nicklist based off a MODE parameter. I thought it was changing the MODE target nick (<- :Matt!Matter@irc.mediadriven.ops) to lowercase.

This could be a fun exploit though. People come in with their nick ALLCAPS and an op can lower it for them.

"+y -- Allows a channel op to modify the CaSe of a user's nick as it appears in the channel. (mIRC Only)." grin


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
#37182 19/07/03 06:16 PM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
There is no conflict. What function in mIRC (or any client) ceases to operate, or is otherwise hindered due to this issue? Sure, the case of the nickname changes, but only to the case nominated by the user.

#37183 19/07/03 06:19 PM
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
This could potentially cause problems in scripts which handle Nicknames in a case sensitive manner. If suddenly a nick changes without an On NICK event firing, it could screw with any number of scripts expecting a nick that is no longer there.

I'm not saying it's a serious issue, or that the user should be using the +y flag that is not implimented... but the server *could* handle it a little better if it wanted to, and mIRC *could* ignore it a little better as other clients do.

- Raccoon


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
#37184 19/07/03 06:23 PM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
Ahhh well, worse things can happen ay. At least we have established that it's not the fault of any IRCd.

#37185 19/07/03 06:38 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
I'm not to familiar with CR, but it does look like a problem with CR to me. The problem seems to be +y, although unimplemented, accepts a parameter. So when he does /mode #chan +yu BLAH blah, CR says 'ok BLAH goes with +y, blah goes with +u', however +y doesn't say (as per CHANMODES=) "I take a parameter" so mIRC doesn't know that. Therefore when it gets a +yu BLAH blah, it says "+y no param, +u has param BLAH, and then there is an extra param of blah so just ignore that". Therefore mIRC gets confused with the case. If you just did /mode #chan +u BLAH I assume it doesn't change the case? Therefore it would certainly seem that the problem lies in the fact that +y is not correctly listed in CHANMODES=.

#37186 20/07/03 09:56 AM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
I did some further research on this, the problem is with mIRC. Not only is mIRC the only programme affected by this (as far as I have sought to find out) but the case change is only seen by the users of mIRC that are in the affected room and also only in the room that the mode change had taken place, which is understandable since it's a room mode we are talking about, none-the-less the problem doesn't occur in the java applet or in Pirch. That said, and like with any problem, the issue has to come down to what is most commonly affected, an IRCd or a client. In this case one client is affected and by an undocumented issue, therefore the client (in this case mIRC) is at fault.

#37187 20/07/03 04:39 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
I 100% disagree with you, and your own argument proves you wrong. +y is undocumented. For all you know it's exact purpose is to allow the client to change the case in the nick list. You have no way of knowing it is a problem with mIRC. As I said +Y takes a parameter, +y does not tell mIRC it takes a parameter. Why isn't pirch affected? because pirch doesn't even know what CHANMODES= is!

#37188 20/07/03 04:50 PM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
+y is undocumented.

Yep, yep, I already said that...

For all you know it's exact purpose is to allow the client to change the case in the nick list.

Why the hell would a resource be put in an IRCd to do that when the user can do it at client level? Support for certain raw commands (for /svs* functions) was removed from CR in V1.8.7.1 (I believe) simply to trim down on stuff that isn't required therefore there is a perception, at least, that when the current version was written, efficiency was considered to a great degree. You are betting on hypothetics as per usual.

Why isn't pirch affected? because pirch doesn't even know what CHANMODES= is!

Correct, but neither does mIRC in this case because +y isn't included. :tongue:

CHANMODES=bouv,k,lOMN,cdejimnpqrstzALU

If you'd bother to read the CR manual you'd realise that modes such as w and y are reserved for future use.

Page 1 of 3 1 2 3

Link Copied to Clipboard