Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ Bug reports
➜ RUSSIAN CHAR \xFF
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| CooL
(2 posts) Bio
|
| Date
| Sat 26 Apr 2003 04:43 PM (UTC) |
| Message
| 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. | | Top |
|
| Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
| Date
| Reply #1 on Sat 26 Apr 2003 06:03 PM (UTC) Amended on Sat 26 Apr 2003 06:05 PM (UTC) by Shadowfyr
|
| Message
| 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 | | Top |
|
| Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
| Date
| Reply #2 on Sat 26 Apr 2003 09:06 PM (UTC) |
| Message
| 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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
| Date
| Reply #3 on Sat 26 Apr 2003 09:07 PM (UTC) |
| Message
| | 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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| CooL
(2 posts) Bio
|
| Date
| Reply #4 on Sun 27 Apr 2003 09:56 AM (UTC) |
| Message
| 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.
| | Top |
|
| Posted by
| Orange
United Kingdom (25 posts) Bio
|
| Date
| Reply #5 on Sun 27 Apr 2003 12:15 PM (UTC) |
| Message
| 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."
| | Top |
|
| Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
| Date
| Reply #6 on Sun 27 Apr 2003 08:45 PM (UTC) |
| Message
| 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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Orange
United Kingdom (25 posts) Bio
|
| Date
| Reply #7 on Sun 27 Apr 2003 08:57 PM (UTC) |
| Message
| 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.) | | Top |
|
| Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
| Date
| Reply #8 on Sun 27 Apr 2003 09:14 PM (UTC) |
| Message
| | OK, I'll make it happen regardless. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
| Date
| Reply #9 on Tue 29 Apr 2003 12:34 AM (UTC) |
| Message
|
Quote:
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.
There was a bug in MXP parsing, where entities inside atomic elements were not expanded. Assuming you fix the syntax, " not &#quot; it will work in 3.41.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
24,314 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top