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

It would seem to me that if that really does exist, it is a problem with CR, not mIRC.

I don't thinjk som, as it doesn't do it in other IRC Clients.. tried a few - Matt

/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.

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

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

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.

It is NOT a bug.

Where is your paste.

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.

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

<- :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

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)."

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.

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

Ahhh well, worse things can happen ay. At least we have established that it's not the fault of any IRCd.

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=.

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.

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!

+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.

And is there a RESERVEDMODES=yw in CR, and does mIRC understand it? The answer is no. How is mIRC to know it should do nothing with those modes? It doesn't. Why is that mIRC's fault? It isn't. And why didn't I read the CR manual? Because as far as I know there is no freely downloadable version, and there is no way in hell I'm going to pay so that I can read it.

Because as far as I know there is no freely downloadable version, and there is no way in hell I'm going to pay so that I can read it.

It costs $0 and 0c. http://irc.bigpond.com/manual/

And is there a RESERVEDMODES=yw in CR

ConferenceRoom 2.0.2f-SEC abcdefghijkmnopqrstwxyzABCLIMORX abcdeijklmnopqrstuvzACJLMNORU
SMARTHELP WALLCHOPS TUNL WHISPER KNOCK PROP LANG FIELD SM TUNL CHANTYPES=# PREFIX=(ovu)@+- NICKLEN=30 MODES=12 SILENCE=10
CHANMODES=bouv,k,lOMN,cdejimnpqrstzAJLRU WATCH=256 KICKLEN=64 MAXBANS=75 MAXCHANNELS=12 SSL FLG=wEsekpv,5

Where?

I said "is there" not "there is"

It's still irrelevant anyway - if, as you say, mIRC doesn't understand RESERVEDMODES then it's pointless having it there purely for this exercise. The fact still remains that there is no valid explanation as to why someone would expect performance from a mode that has no documented function and is indeed marked N/A in the HelpServ reference. So why is +y even being used and who really cares what it does? It's been there for, like 6 - 7 years and this is the first time it's ever raised a mention.

This isnt the only server or IRCd to do it. Global servers also do this where if you do /mode #someroom +o NaKI, it will change the case of it.

hehe, Well that is perfect evidence that it is mIRC that is at fault but don't tell codemastr, he thinks that just because it doesn't happen on Unreal means that it's the fault of other IRCd's.

If this mode is not meant to be used, it should be removed or at least made Oper-only. And yes, i think it's IRCd's fault, too.

So two IRCd's made my two seperate organisations are responsible for a foul-up in one programme? That makes no sense at all. Especially since the modes used on each IRCd are different. Think before speaking.

Wow you mean two IRCds have the same bug? Thats unheard of! Oh wait, no it isn't, it happens with almost every bug ever found in IRCds.

Well common sense dictates that one associates the problem with the common cause, that being mIRC's adverse response to the case change on mode change. If the problem is happening on two entirely different brands of IRCd then Khaled should build some resistance into mIRC to prevent the case change happening. Lets not forget here that +o is an op/deop mode, not a case change mode, that said you barely had a valid arguement with +yu in the case of CR. In the case of whatever other IRCd affects mIRC this way, you have absolutely no valid argument at all.

While I am on the subject, I tried this issue in X Chat, Klient, Bersirc and kVirc. I even telnetted for what it was worth (even though there's no nicklist in DOS I was still able to see the full raw event). No other chat client that I know of is affected by this - only mIRC. The bug is therefore in mIRC.

Give me a server where I can test it and I assure you I can find other clients that are affected.

hehe It's funny how when I prove something beyond reasonable doubt that I am being milked for information. Try Webmaster's own network. As for the other IRCd, I don't know what network the other poster here was talking about, though I have the nouse to just simply believe him.

For the record I don't dispute that there may be other clients that react the way mIRC does. I'm just saying that those that I tested didn't do it for me. Either way, I am satisfied that mIRC is at fault here. In closing, it would be interesting to know if you'd be so vocal on this issue if Unreal did the same thing.

I tried webmaster's network, however they require a registered nick to create a channel, and to register a nick requires me to give my email, and thats not gonna happen. Anyway, I don't see what Unreal has to do with this. When unreal has a problem, I don't deny that it exists I say "thanks for finding that, I'll go and try to fix it" as I am currently doing on a couple of bugs that have been reported. Maybe you're too used to the MS theory of bugs, where they believe it is better to deny the bugs exist rather than actually fix them, however not everyone believes such things.

There are certain things not specifically mentioned in RFC1459 that are defacto standards, one of these is validation. For example, if you type /mode #chan +b blah*. Thats totally legal, however every server I've ever seen will translate this to blah*!*@*. Does this mean a server that doesn't do this is breaking a standard? No, but it does mean it isn't going along with a "generally accepted standard." The same holds true for things like +o/+v. If I send "+v BLAH" and the user's nickname is "blah" it is generally accepted that the server will translate the "+v BLAH" to "+v blah". Again, it's not necessarily required, however if everyone except 1-2 servers do it that way, well then imho it is the fault of the server, not of the client.

Maybe you're too used to the MS theory of bugs, where they believe it is better to deny the bugs exist rather than actually fix them

If you mean the Micro$oft that fixes more bugs and more quickly than any other software vendor known to modern man then perhaps you are right.

As for testing your urban myth that the case bug is the fault of an IRCd rather than mIRC, I cannot help there much because I only know of two networks that use CR (as I don't hop around as much as I used to) they being Bigpond (which doesn't currently allow user-created channels) and Webnet, where people who try to prove a point for the sake of trying to be right when they are wrong are too lazy to register nicknames. As for the second IRCd which affects mIRC this way, I do not know where that is. One thing is for sure, as I have stated, mIRC seems to object to being force-fed a changed case for inappropriately used modes therefore there is a bug in mIRC, as the original poster suggested.

You mean like the WinXP SP1 causes performance slowdowns bug that effects tens of thousands of users yet Microsoft refuses to admit the problem even exists?

In any case I'm not arguing with you anymore, you're argument now revolves around the statement "I'm right because I say I'm right" so there is no point in arguing this further. When I try and offer reasons why it isn't mIRC's fault, you just ignore that and go back to "it only effects mIRC, therefore mIRC is broken". Did it ever occur to you perhaps mIRC is the only one that behaves correctly and that all other clients could be wrong?

Your argument would be valid if you call an obvious bug a correct operation.

Guess what, i tried it with Bahamut, ircu, Unreal, Ultimate, Hybrid and tons of different IRCds. None of them is affected by this - only CR and "Global" (whatever it is). The bug is therefore in those two IRCds.

Maybe instead of saying "it only happens with mIRC" you should say "it only happens with CR"...?

Maybe instead of saying "it only happens with mIRC" you should say "it only happens with CR"...?

Because it doesn't only happen with CR.

Well I've got about 150 different IRCds on my machine, I've never heard of one called "Global". The only one close I know of is called GlobalIRC-d (Gircd for short) which is a Mac-only IRCd. To my knowledge, this IRCd hasn't been developed since 1999 and it is known to be one of the buggiest IRCds in existence.

What's that got to do with me? I didn't mention an IRCd called Global or anything else. Why don't you go back to the beginning and read again from the start.

Don't even remember what you said? "Because it doesn't only happen with CR." My point is, yes, it is only CR, because as far as I know, no "Global" IRCd exists, that means it is only CR.

Where does it say the name of any other IRCd in that sentence?

The name of the other IRCd that was mentioned in this thread WAS MENTIONED BY SOMEONE ELSE. It just happens that I believe what they are saying. If you don't then it's a matter for you, I couldn't care less.

Global does exist... It is an IRCd made in perl and it is called globalstage... This IRCd can be found at irc.scifi.com 6666, 6667, and 6668.



globalstage in my opinion is a very crapy IRCd...

You and codemastr need to get acquainted.

ok maybe im mistaken but +y isnt even in the chanmodes= in CR so if its not there tellin mirc it is ...... then how can u say this ismircs fualt? i mean thats like me asking u to make me a sandwich and when u bring me tunafish sandwich im upset cause u didnt bring me bologna

expecting something to operate properly when u dont tell it how to or with what info is impossible to expect ..... in my opinion CR is at fualt .... and since CR costs an ungodly amount of money id say they should start making [censored] that works correctly with mirc ... as it is by far the most popular irc client made. why doesnt hybrid or unreal ircds have this problem like cr is? probably because even tho they are free ware ... they actually work properly with mirc ... ironic isnt it? u never wanna shed bad light to the sacred CR but in this case your wrong .. admit and be a man about a mistake of cr .. it is not like u wrong the mistake. why take it so damn personal

You haven't read the whole thread either. If you did you'd see that there is more than one IRCd involved, more than one mode type involved and more than one user reporting issues where only ONE SINGLE chat programme (mIRC) is affected. I hardly think CR costs much anyway, I helped build two rack servers about 6 weeks ago and each one has about $50,000 worth of software on board with on-going licence fees approaching the million mark over the life of the software (including upgrades).

At anyrate this discussion isn't freeware v's commercial software. Both CR and mIRC have to be paid for as far as I remember. I don't know about Global IRCd though.

yes i did read the entire thread of this OTHER ircd affected ....... but CR was the source of the main complaint in this thread ..... not this OTHER ircd your trying to bring into the discussion. remeber a wise man once said 2 wrongs dont make a right. having 2 ircds that are afected doesnt make it a bug when in all reality there are probably 20 who arent. Mirc is not the cause of this bug ... its piss poor coding on the part of CR and the other mentioned ircd. And im not turing it into a freeware vs commercial software debate. Im pointing out CR costs an ungodly amount of money and yet all these other freeware ircds work and dont have this issue. Defend CR all u want but this whole thread doesnt convince me of any great feature in it. certainly not a bug worth paying for

From Webmaster support:

Without extensive testing I couldn't really tell you. However, that seems
like a mIRC issue and not a server one.

Now... Lets get one thing straight, I did not bring up the issue regarding the Global IRCd, someone else did, if you did read the thread correctly then you'd know this. Other thing is that Khaled was here yesterday and may have read this thread and I am yet to see him comment on it. Blaming servers for something that only hapens to mIRC just doesn't wash, and I don't care who the maker of the server is.

sure believe someone who hasnt even looked into it enough ..... hold on im gonna report my bug in windows to microsoft and im possitive they are gonna tell me at first its not thier error its mine ...... then later they will release a fix on it. believe what u want its obvious no one can convince u of anything u dont wanna see plain as day. the bug is infact in CR for having an undocumented mode yet not bothering to publish it in chanmodes= thats the whole bottom line end of story. mirc doesnt know what to do with the mode when its not in that list of supported modes. ive pasted u your own text which proves thats not even there. you cant see all im doing is showing u exactly why its not mircs fualt because uve got this sacred hardon for CR. again im sorry i even bothered to try to show u the error isnt infact mircs its CR.

So you are saying that if you created something which some other person believed there was a bug with, they shouldn't believe your "story" in relation to what was at fault? Well, in the absence of any more qualified information, I am taking their advice. Your belief that software can make people sexually aroused just shows your immaturity and shows that you have only posted to stir. This will never sink into your head but the mode is undocumented because chat programmes are not meant to be affected by its existence. You'll never be able to get away from the fact that only mIRC is affected. And it is affected by more that one IRCd.

sexually aroused??? wtf are u talking about? give me some of them drugs uve been takin. seriously tho your not even seeing what im saying at all. If I made a program and without testing it thouroughly someone told me they found a bug and i told that person i didnt think it was my programs fualt ur gonna take my word for it? if your going to then your a fool

you cant see all im doing is showing u exactly why its not mircs fualt because uve got this sacred hardon for CR

I believe you said that. Apart from that there is nothing in your posts not already mentioned by codemastr, so your posts were worthless and contribute nothing. At least, in my case, I consulted the maker of one of the IRCd's that cause this glitch in mIRC instead of just hurling insults. Don't get me wrong, I'm not offended by your silly remark, it would be nice to have a discussion on something without those who can't be bothered resorting to these childish and un-necessary (and stereotypically teenaged) insults.

I'll add to this. My first experience on IRC was EFnet, when the Australian node got hacked/smurfed, basically destroyed, I changed to another network, which was owned by the same company that owned the Efnet node I used. I am an oper on that network and it is perfectly reasonable, in my view, for opers to have a personal favourite IRCd. If it happens that someone doesn't agree with me though, I respect that. The world would be boring if we all liked the same things.