Cursor movement commands not supported

[Laps]

I'm playing a MUD which displays some sweet ANSI art upon connection. When using Mudlet (using a brand new, empty Mudlet profile, with only default settings and preferences), the art all mashed up to the left, as if Mudlet is somehow ignoring the whitespace between characters. When using Telnet via Terminal (I'm on a Macbook), the art looks great. Screenshots below.

Question: Is there some Mudlet setting I need to change to get this to behavior properly?

TELNET SCREENSHOTS:

-

-

-



MUDLET SCREENSHOTS:

-

-

-

[Vadi]

Try enabling utf8 in the main window encoding settings.

[Laps]

Try enabling utf8 in the main window encoding settings.

This didn't work - in fact it looks worse I also tried with all the other encodings, and no dice. In case you want to debug, the address is mud.durismud.com port 443

[SlySven]

Does you Mudlet have a CP437 encoding listed in the Server Encodings control - about 5 days we merged in some more codecs (that I wrote ) specifically to help for MUDs like this one - however I see that that is not in the current 4.6.2 release which was over a month ago and 4.7.0 was written up as an April Fool's joke with no actual software release at the time. Using the current development branch code I get the characters correctly decoded:

However you can see that the spacing is shot to hell - OTOH in the debug output I see that there are a lot of messages of the form:

Code: Select all

TBuffer::translateToPlainText(...) INFO - Unhandled sequence of form CSI...C received, Mudlet will ignore it.

I will have to check but I suspect that there are cursor movement commands in the text stream...

Ah yeah! Checking Wikipedia ANSI escape codes reveals those are CUF (Cursor Forward Commands) - which is quite naughty of them as the MUD Game Server is assuming that the NVT (Network Virtual Terminal) on the other end of the Network connection is capable of VT1000 commands - which Mudlet - as a GUI client - is NOT! Indeed, looking through the debug output I see that it does not attempt to identify the client's TTYPE.

Anyhow I have managed to bodge a fix together that converts the code to a corresponding number of spaces and then things look more promising:

I will see if I can polish this up and get it into the version after the one that is being put together - so you might see the fix in a month or so...

[SlySven]

Okay there are testing versions available for this enhancement: PR3680 - they are:

• Linux
• MacOs
• Windows

Just uncompress the archive file and then you can run them in place...

[Laps]

Does you Mudlet have a CP437 encoding listed in the Server Encodings control

No, the closest I see are CP850 and CP866. I'm using Mudlet 4.5.1-de on Macbook with macOS High Sierra.

Anyhow I have managed to bodge a fix together that converts the code to a corresponding number of spaces and then things look more promising...

I will see if I can polish this up and get it into the version after the one that is being put together - so you might see the fix in a month or so...

Wow, you are awesome! Also your screen shot looks so much better than even telnet, thank you!

Edit: oh somehow I missed your last message - I'll let you know how testing it goes! Thanks again!

[SlySven]

You were lucky that I had just done those codecs for Medieva - and that I had left code in place to moan about ANSI ESC control codes that Mudlet cannot make use of!

I checked the MUD you are trying to play out and I noticed that they haven't done anything to detail what a Client needs to set to connect to their Server - if you get a chance in Game it might be worth asking them why they put out ANSI codes that they shouldn't do without checking that the terminal on the other end can handle them. Admittedly Mudlet does not (yet!) support negotiation about the character encoding to use but strictly speaking a computer making a Telnet connection can only assume that the host on the other end can understand ASCII and should not use anything else without checking with the computer/human on the other end what is okay to use. It may be that the character encoding (like the use of VT100 control codes to move the cursor) is something that the player can change once they have connected - but the fact that there is no information about this on their website is a bit naughty...

[Vadi]

Nice. So whitespace is not ignored, the game isn't sending whitespace to begin with.

[Laps]

You were lucky that I had just done those codecs for Medieva - and that I had left code in place to moan about ANSI ESC control codes that Mudlet cannot make use of!

I checked the MUD you are trying to play out and I noticed that they haven't done anything to detail what a Client needs to set to connect to their Server - if you get a chance in Game it might be worth asking them why they put out ANSI codes that they shouldn't do without checking that the terminal on the other end can handle them. Admittedly Mudlet does not (yet!) support negotiation about the character encoding to use but strictly speaking a computer making a Telnet connection can only assume that the host on the other end can understand ASCII and should not use anything else without checking with the computer/human on the other end what is okay to use. It may be that the character encoding (like the use of VT100 control codes to move the cursor) is something that the player can change once they have connected - but the fact that there is no information about this on their website is a bit naughty...

I'll consider myself lucky indeed! Thank you so much for taking the time - I tested the 4.6.2 version you shared on Macbook and it's perfect

As for your comments on Duris's behavior - I'll be sure to share this thread with the imms. Thanks again, especially for the detailed explanation.

[SlySven]

If they want to detect a Mudlet client on the other end of the connection the safest method is to use the TTYPE Telnet (sub-option 24) - Mudlet will respond with a string beginning (and it should be tested case-insensitively to comply with RFC1091) "Mudlet"...

... although, reading that has made me realise that we are using characters in that string that are NOT value for it (like '.' and a space)!