Forums Bug Reports Wrong nickname, and other BNC-related problems.

I couldn't help but notice that sometimes when you reattach to a bnc, mIRC assumes that your nickname is whatever your default is, even if the attached bnc really has a different nickname. This causes everything from $me to /nick to fail, and can be confusing.

Khaled, could you make mIRC snag $me on raw 001? If not, there has to be some similar way of making sure it knows the right nickname.

I would consider this more of a BNC bug, but since psyBNC has this problem and most BNC are copying psy now, it might be good to fix it. I had to add a similar routine to an IRC bot I am writing.

Also, some bnc including psyBNC give you status messages via PRIVMSG with a nickname like -psyBNC which is invalid on an ircd. apparently the prefixed hyphen in "-psyBNC" causes things like /clear not to work. Dunno what can be done about that one.

Hi!

Well, as you said, it could be considered as a BNC bug, since a nickname change with these bouncers are not following the IRC protocol (numerical RAW insteand of NICK command).
mIRC (and any decent IRC client) overrides your default nickname when receiving a NICK line from the server.
RAW numerics really depends on the server you're on, so 001 could be an additionnal whois line for some servers, a nickname change for a bouncer, etc...
No IRC client can trust or be sure of what kind of data a RAW will reply (there are some standards, but most can be modified).

Try contacting psyBNC authors and tell them to follow the IRC protocol :P

Woah.. while I conceded that it's not so much mIRC's fault, it is the only client I know of that has this problem. As for using raw 001 or not, I think you are being a bit smug in writing it off as a possible solution. There are many generally unused numerics for things like "extra whois" lines, as you put it, and I have never seen raw 001 used for anything but a "Welcome to IRC" message verifying that your signon was successful.

I think this problem has merit and should be taken a little more seriously than to just blame psyBNC or the numerous other BNC programs that work absolutely fine with BX and other popular clients.

Update: I see you edited your post after my reply, so allow me to clear up another thing. When you initially connect to an IRC server, you send USER and NICK. mIRC just assumes that unless it gets an error like "nickname in use" that whatever it sent in the NICK command will be your nickname.
Most clients (contradictory to your suggestion) verify that what they sent in the NICK command is actually their nickname (with raw 001). The reason for this, aside from the bounce problems, is that some servers replace invalid characters that you put in your nick with an underscore ("_") instead of just saying invalid nickname.

mIRC uses the nickname specified in the incoming 001 numeric as your active nickname.

mIRC has been in development a long time, and it integrates quite closely with server behaviour, far more than most IRC clients, so if a BNC is modifying server messages in some way, and making assumptions about what an IRC client needs, then yes, that will definitely affect the way the IRC client behaves.

What version of psyBNC are you having problems with? mIRC does use numeric 1 to find its nickname, the issue (it would seem) is with psyBNC sending a 'stored' version of the numeric and failing to send an updated nick change if the nick of the bouncer is not the nick the psybnc 'wants'. See here.

The raw 001 sent by psyBNC supplies the nickname of the active irc session between the bnc and the server, so it is not a matter of it misleading mIRC with an improper raw event. I took the liberty of logging in and connecting manually through a telnet-type client to verify this a couple of different ways.

For the time being I will trust your judgement, but I will continue to investigate the issue and I'll report back if I come to any further conclusion. For the record, this is not just an issue with psyBNC, and as I said before I don't experience it with other clients. I am not placing any blame on you Khaled (because you are right about it assuming what the client should receive), I am merely trying to work out a communication problem between 2 great pieces of software.