I have used MS Chat for the last few years for professional chat. I'd always miss whispers, so am trying MIRC for the first time and am really pleased. There is no way I'd miss a whisper now!
But... When I receive a lot of messages that are more than one sentence and include numbers, I get a lot of garbled messages with little boxes in them. I'm assuming this has to do with ASCII encoding or MS 1252(?) encoding from MS Chat user/server to my MIRC software? I've monkeyed with the UTF-8 checkbox, but how else could I try to fix this so that what they type, I receive and see?
Thank you!!
I'm not positive of this, and I don't have MS Chat in order to try to verify, but I believe the problem is the MS Chat uses UTF-16, not UTF-8, and mIRC isn't (currently) compatable with UTF-16.
For your MS Chat(ting) you may have no choice but to use MS Chat.
Appreciate the reply, but it can't be that, MS Chat 2.5(cchat.exe) has been around for many years (1998) and surely MIRC users have experienced something of this sort before.
Maybe it's a font thing? Will try a switch to System font and see if that does the trick.
Seems mIRC doesn't like to receive hard returns? instead of bouncing the text to the next line, it just separates text by rn. Any way to fix this??
MS Chat used a lot of special formatting in its messages that no other IRC client understands. There's no setting in mIRC that will fix this, it would have to be scripted.
/r/n separate IRC protocol messages and hence cannot be sent as part of a message, not even by MS Chat. mIRC handles them just fine.
Well, it seems to be a larger issue than MS Chat. Any multi-line text with a hard return to the next line of text causes problems.
i.e., the following is sent:
test
test
When sending using mIRC, it results in Two new messages; each line it's own message:
[timestamp]<username>test
[timestamp]<username>test
Or is that what you're referring to, where mIRC parses the /r/n into a new message line. So that the test above will always result in two messages as opposed to what I see resulting from MS Chat sent messages:
[timestamp]<username>test/r/ntest
If so, how can I script mIRC to parse the /r/n message from MS Caht properly, or has someone already done so?
MS Chat is the one that's bastardized the IRC protocol and ruined it's implementation of it.
IRC is a line-by-line chat protocol. You cannot put any newlines or carriage returns in it.
If you want an MS Chat compatability script, it's going to strip out the MS Chat uniqueness, and make it more flat IRC.
I've never seen or heard of anyone trying to make mIRC more like 'MS Chat'.
Don't care to be anything like MS Chat. But I do want the ability to send/receive multi-line text in one message, as it's vital to what we're doing for my job.
Guess I'll just suck it up and live with the /r/n symbols amongst the text, or deal with MS Chat antiquities.
What I was trying to point out is that there's no way the characters you're seeing are \r\n. Those characters cannot be sent intact as messages with the IRC protocol.
To demonstrate this simply type: //msg #channel Hello! $crlf JOIN #test123. Other users in #channel will only see "Hello!", and you'll join #test123. This is how IRC works, regardless of which client you use.
Seriously, when the below is copied from, let's say notepad and entered in MS Chat:
Line 1 report: Blah Blah Blah
Line 2 report: Blew Blew Blew
In mIRC I get this:
Line 1 report: Blah Blah BlahrnLine 2 report: Blew Blew Blew
That doesn't mean that MSChat is actually using \r\n, it will be using substitute characters.
The substitute "characters" are likely the character strings "/r" "/n"
I would propose typing "/home/r/needle" in mIRC and seeing how MS chat interprets that.. if it turns it into newlines, thats horribly funny and sad at the same time.
Heh, that'd be funny :P
If it is, then there is at least hope for someone to do something to make it's horrible multi-line messages sorta display in mIRC properly..
Nothing happens on either chat when that's entered. Message doesn't get sent.