RUSSIAN CHAR \xFF

Hi.

I am by the creator russian mud, in your client there is a small disadvantage - namely it at a sending off 'xFF' used in the Russian coding does not double it, that is sends '\xFF' instead of 'xFF xFF' and at reception(trick) dynamic given in falling out menus at usage MXP there is no replacement UniCode on the character.

ps Sory for my english.

I assume he CooL means the ÿ character, since that seems to be what appears in position FF on most of these fonts, just to clear that up. If MXP supports unicode, then you would get the unicode Character /xFFFF, which 'every' font seems to have defined as <not a character>. Not even Webdings has it. I am not entirely sure what CooL is trying to do here frankly or specifically what character he is looking for. I do know that Mushclient does not currently have support for Unicode, not even on the Info bar, where using it with Lucida Console would have been easier than switching fonts mid-line in the Gauge sub.

In general, from Lucida Console:

00FF = ÿ
01FF = ?
04FF = <not defined> (in the cyrillic set)
xxFF = All the rest <not defined>

Edit: Hmm. Seems that the forum lets you 'enter' unicode, but then strips them later... 01FF should be a slashed 0 with a emphasis mark over it. :p

I think what he means is that a while back I changed it so that incoming 0xFF 0xFF was (IAC IAC) was converted to 0XFF so that you could see that character (and not have it interpreted as an ANSI negotiations sequence).

Thus, it would make sense to do the same thing when *sending* 0xFF to the MUD.

Plus, I am now worried what would happen in the chat system, which uses 0xFF to delimit messages in the MudMaster protocol, if you entered 0xFF inside your message. Crash it, I expect.

Problem in is those, that I try to transmit instead of the "ÿ" character
which in windows to the coding in Russian has in view of the character 255
(xFF)
The majority of clients double this character, and the little bit updated
code of the server understands that to it not the special character namely
character of the language has come.

In MXP instead of the indicated character I send &#quot; that is unicode for
normal mapping of the character, instead of the character, necessary to me,
MUSH maps " &#quot; " though at a sending off of templates it is
successfully substituted on the necessary character.

sory for my english.

And it doesn't just make sense, it's implicitly required by RFC 854, and explictly in RFC 1123. To quote from the latter, paragraph 3.2.6.

"Since options may appear at any point in the data stream, a Telnet escape character (known as IAC, with the value 255) to be sent as data MUST be doubled."

I have added an option to double it, as I thought some older MUDs might not expect telnet negotiation incoming. Note that Cool says the "updated code" in his server expects it.

However I could make it the standard behaviour if everyone thinks it won't be a big worry.

I have also changed the Chat system to substitute "y" for "ÿ" otherwise chat packets would end prematurely, when using the MudMaster protocol.

Well, consider the case of a dumb mud server that doesn't know anything about IACs.

With output conversion off but input conversion on, if I type 'say [255]' then this will be echoed to me as "You say [255]", which will get displayed as "You say " - might even eat the newline. If IAC IAC got sent out the mud would just repeat it back, making it display right.

The only case to fear is dumb mud servers which have a mixture of smart and dumb clients connected to them - but there's no way to be compatible with all of them, so why break the smart ones by default?

(The majority of mud clients get IAC IAC right now, at least since I started my crusade. Most of the ones that don't are unmaintained.)

OK, I'll make it happen regardless.

There was a bug in MXP parsing, where entities inside atomic elements were not expanded. Assuming you fix the syntax, &quot; not &#quot; it will work in 3.41.