This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

IAC and cyrillic alphabet

Posted by Erendir on Sun 06 Apr 2008 03:11 PM — 17 posts, 74,331 views.

Erendir Germany #0
My future request is to add IAC-options: send single or double IAC and receive single or double IAC.

This would very improve usability of MUSHClient with cyrillic MUDs (because of problems with small 'я'-letter, which ASCII-code is 255)
A solution, used by many MUDs, is that client send double (or single) IAC, and receive double.
Nick Gammon Australia Forum Administrator #1
MUSHclient already does that, by default. If it receives two FF characters in a row, it displays a single one (ÿ), and if you send a FF character it sends two of them to the MUD.
Erendir Germany #2
But some of the servers wont to hear from client only a single IAC

And on mud.khakassia.ru:9000 i have following problem: if i choose [1] - Win1251 codepage, all is ok -- server sends instead of IAC the big letter 'Я', and converts clients double IAC to that letter, and MXP works. But if I'm trying to use [4] - Win1251(IAC) codepage with support of small 'я', i.e. IAC as letter, MXP fails.

Is there also any possibility to shut off support of telnet commands like IAC+byte in MUSHClient?..
Nick Gammon Australia Forum Administrator #3
OK, just to clarify what is being talked about here. See this page:

http://en.wikipedia.org/wiki/Windows-1251

The original poster (Erendir) wants to correctly process the Russian character я which in Unicode is hex 044F. However s/he is using the Windows code page 1251, which maps that character (я) to hex FF which is the IAC character.

Now under default processing the IAC character introduces telnet sequences and is not simply displayed on the screen. MUDs should send IAC/IAC (that is hex FF FF) by translating FF to FF FF in order for the character to be displayed correctly.
Nick Gammon Australia Forum Administrator #4
Quote:

Is there also any possibility to shut off support of telnet commands like IAC+byte in MUSHClient?..


I can help you with incoming IAC characters. If I understand correctly, you want them to be displayed "as is" and not processed as telnet sequences?

See this plugin below:


<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>

<muclient>
<plugin
   name="Double_Incoming_IAC"
   author="Nick Gammon"
   id="aed1431f362db67b6d9d81ce"
   language="Lua"
   purpose="Converts incoming IAC to IAC/IAC"
   date_written="2008-04-11 09:00:00"
   requires="3.82"
   version="1.0"
   >

</plugin>

<!--  Script  -->

<script>
function OnPluginPacketReceived (s)
  return (string.gsub (s, "\255", "\255\255"))
end -- function OnPluginPacketReceived
</script>

</muclient>


Save from between the lines as disk file Double_Incoming_IAC.xml, and use File -> Plugins to install that file as a plugin.

What that will do is take incoming IAC characters and double them (so IAC becomes IAC IAC), which means MUSHclient will then treat them as a single IAC and display them.
Nick Gammon Australia Forum Administrator #5
If you also want to undo what MUSHclient does to outgoing IAC characters, you could install this plugin below:


<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>

<muclient>
<plugin
   name="Halve_Outgoing_IAC"
   author="Nick Gammon"
   id="fe9cb248003f84ceeee1f3aa"
   language="Lua"
   purpose="Converts outgoing IAC/IAC to IAC"
   date_written="2008-04-11 09:10:00"
   requires="3.82"
   version="1.0"
   >

</plugin>

<!--  Script  -->

<script>
function OnPluginSend (s)
  Send ((string.gsub (s, "\255\255", "\255")))
  return false
end -- function OnPluginSend 
</script>

</muclient>


Save as file Halve_Outgoing_IAC.xml and install as a plugin.

What this does is look for outgoing IAC/IAC sequences and replace them by a single IAC.

[EDIT] - 4th June 2008. I have been reviewing how MUSHclient handles outgoing text, and the suggested plugin above won't work.

See: http://www.gammon.com.au/forum/?id=6572

The call to OnPluginSend is too early, MUSHclient doubles the IAC to be IAC/IAC at the very last moment.

Version 4.27 adds a new script option that lets you disable this behaviour. 


SetOption ("do_not_translate_iac_to_iac_iac", 1)


However I really do not recommend using it, unless the MUD you are sending to simply never uses IAC characters for telnet negotiation.
Amended on Wed 04 Jun 2008 06:14 AM by Nick Gammon
Erendir Germany #6
i thought that is possible with plugins, but i don't knew it's sooo simple :))

:/ MXP still wont work...
Nick Gammon Australia Forum Administrator #7
I what way does it not work? It doesn't activate? Or it activates but works strangely?

If you use that first plugin MXP won't activate automatically because it uses a telnet sequences IAC-something to tell the client to switch to using MXP.

You could try going into the MXP/Pueblo configuration tab and select "Use MXP/Pueblo: Yes - always". That will always try to interpret things as MXP. You may also need to tell the MUD to activate MXP, even without the telnet negotiation.

You realize, I suppose, that you are really trying to solve a problem at the client end that should be dealt with at the server end? Why not just contact the server admins and get them to handle the IAC problem correctly? That is, if someone uses IAC in chat, convert it to two IACs going out. And if it receives 2 IACs coming in, it does not attempt to interpret that as a telnet sequence, but just treats it as a single IAC.
Erendir Germany #8
Damn't, 2nd try:

No IAC-plugins enabled.

The server offers few codepages:
Quote:
[1] - Win1251 [2] - KOI8 [3] - Alt(CP866)
[4] - Win1251(IAC) [5] - Mac [6] - Translit


If you choose 1, server don't send IAC at all - excluding first one, the <IAC><WILL><MXP> sequence (and later 2 IACs in the telnet sequence). MXP works ok.

If you choose 4, server send double IAC (so i must use IACIAC->IAC plugin).
But MXP wont work:
it fails at Unterminated MXP quote: !ELEMENT Get "<send href='&#1074;&#1079;&#1103; (unknown)
last letter before (unknkown) is IAC.

By choosing 4 with enabled IACIAC->IAC plugin, MXP debugwindow shows no information at all: only I 10007: ( 393) MXP turned on.
But in mud output there are lot of symbols, starting with characters with codes ff fa 56 ff f0 (should be some telnet sequence i think), followd by meaningless string. (No MXP tags are to see)
Amended on Fri 25 Apr 2008 04:01 PM by Erendir
Nick Gammon Australia Forum Administrator #9
Quote:

if i choose [1] - Win1251 codepage, all is ok -- server sends instead of IAC the big letter '&#1071;', and converts clients double IAC to that letter, and MXP works.


Well why not use [1] then? It sounds like it is converting IAC to &#1071; (the Russian backwards R) which is what you want, isn't it? You said "all is OK" and "MXP works".
Amended on Fri 25 Apr 2008 09:51 PM by Nick Gammon
Nick Gammon Australia Forum Administrator #10
Ah I see the problem. MUSHclient doesn't recognise &#1071; as an MXP entity, because internally incoming data is stored as 8 bits, and 1071 is more than 255, which is the most that you can fit into 8 bits.

Maybe this will help? Using option [1] - you only need to solve the problem of converting &#1071; to IAC (or is it &#1103;)? Anyway, this plugin below attempts to pre-convert some entities, as per the table:


<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>

<muclient>
<plugin
   name="ConvertEntities"
   author="Nick Gammon"
   id="e9036aacdd4b6c3760d18c21"
   language="Lua"
   purpose="Converts some MXP entities"
   date_written="2008-04-26 08:30:00"
   requires="3.82"
   version="1.0"
   >

</plugin>

<!--  Script  -->
<script>
<![CDATA[

entities = { 
  ["&#1103;"] = "\255\255",  -- lower-case backwards R
  ["&#1071;"] = "\223",   -- upper-case backwards R
  ["&#1079;"] = "\231",   -- add others as required

  }

function OnPluginPacketReceived (s)
  return (string.gsub (s, "%&#%d+;", entities ))
end -- function OnPluginPacketReceived
]]>
</script>

</muclient>


Now whatever is in the table "entities" gets converted back to a single byte, which with the appropriate code page, should display properly. See how that goes. I converted &#1103; to IAC IAC because then MUSHclient converts that back to a single IAC.

[EDIT] - amended because I got the codes wrong.
Amended on Sat 26 Apr 2008 09:26 PM by Nick Gammon
Erendir Germany #11
By choosing [1] thE tExt from MUD would bE like this sEntEncE -- small 'e's (or IACs in my case) became big, and big 'E's stay big. Ok, substitude all 'E' by 'e' is a little bit better, than to see all these annoying 'E', but... I would like to solve this problem in other way :)

Quote:
!ELEMENT Get "<send href='&#1074;&#1079;&#1103; (unknown)

the entities &#1074;&#1079;&#1103; are there only 'cause of pasting in this forum, server sends a 8-bit symbols only, and MXP-debug window displays them in correct way. So &#1103; must be stored as IAC, #255.
Nick Gammon Australia Forum Administrator #12
I see I got it backwards. Well I was describing the general idea. I changed the above plugin so that &#1103; (which is the lower-case backwards R) is hex 044F in Unicode, which maps to 255 (IAC) in the Windows-1251 code page.

So if you use the last plugin, as amended now, it should look OK.

I fixed the earlier post to show the correct codes.
Amended on Sat 26 Apr 2008 09:28 PM by Nick Gammon
Erendir Germany #13
with that enw plugin there are no changes either I have them on nor off.

Here debug packets:

...[6z<!-- Set u   0a 0d 1b 5b 36 7a 3c 21 2d 2d 20 53 65 74 20 75
p MXP elements -   70 20 4d 58 50 20 65 6c 65 6d 65 6e 74 73 20 2d
-><!ELEMENT Ex '   2d 3e 3c 21 45 4c 45 4d 45 4e 54 20 45 78 20 27
<send>' FLAG=Roo   3c 73 65 6e 64 3e 27 20 46 4c 41 47 3d 52 6f 6f
mExit><!ELEMENT    6d 45 78 69 74 3e 3c 21 45 4c 45 4d 45 4e 54 20
rdesc '<p>' FLAG   72 64 65 73 63 20 27 3c 70 3e 27 20 46 4c 41 47
=RoomDesc><!ELEM   3d 52 6f 6f 6d 44 65 73 63 3e 3c 21 45 4c 45 4d
ENT Get "<send h   45 4e 54 20 47 65 74 20 22 3c 73 65 6e 64 20 68
ref='&#1074;&#1079;&#1103;&#1103;&#1090;&#1100; &#39   72 65 66 3d 27 e2 e7 ff ff f2 fc 20 26 23 33 39

hmm, not good. The last line is:

   72 65 66 3d 27 e2 e7 ff ff f2 fc 20 26 23 33 39

Quote:

ref='zz<IAC><IAC>zz &#39

where z are some letters.

MXP:
Quote:

Unterminated MXP quote: !ELEMENT Get "<send href='zz<IAC> (unknown)

so server sends double IAC, as should be, but MXP-interpreter treats the 2nd one as special MXP-sequence (or telnet?) or somethink like this.
Amended on Mon 28 Apr 2008 10:52 PM by Nick Gammon
Nick Gammon Australia Forum Administrator #14
Ah, the debug packet information was very helpful.

I confirm there is a bug in MUSHclient 4.23 and earlier versions, where IAC/IAC inside an MXP entity or element definition would cause this problem.

This will be corrected in version 4.24, which is being uploaded and will be announced shortly.
Nick Gammon Australia Forum Administrator #15
Try version 4.24 now:

http://www.gammon.com.au/files/mushclient/mushclient424.exe
Erendir Germany #16
oh, great, now it works very well :)

thank you for the best mud-client :))