Terminal Emulation

  • aldie
  • aldie's Avatar Topic Author
  • Offline
  • Junior Member
More
08 Mar 2019 01:09 #1 by aldie
Terminal Emulation was created by aldie
Hi,

I think I found some issue with the negotiation of the terminal type using the telnet protocol.
AFAIK (checked with the RFC), mud sends IAC DO TERMINAL-TYPE (i can negotiate on that) and asks
to a terminal type: IAC SB TERMINAL-TYPE SEND IAC SE
or: ff fd 18 ff fa 18 01 ff f0

The client (see attached pcap files for the portal app or putty; here, 1st example putty) answers
with IAC SB TERMINAL-TYPE IS ... IAC SE

In case of putty: ff fa 18 00 58 54 45 52 4d ff f0 Or: type is XTERM


Mudportal - however - always sends two, different types. A second, unsolicited reply is attached:

ff fa 18 00 6d 75 64 70 6f 72 74 61 6c 2e 63 6f ....mudp ortal.co
6d ff f0 ff fb 18 ff fa 18 00 58 54 45 52 4d 2d m....... ..XTERM-
32 35 36 63 6f 6c 6f 72 ff f0 256color

This is not good, esp. as some clients to negotiate and change the terminal
emulation each time when the mud asks for a new type (by IAC SB TERMINAL-TYPE SEND IAC SE)
and the client switches to and returns the name of the next terminal emulation.

I do not think the portal app does this, but if it were the case, when the mud says:
Hey, type=mudportal.com is it, continue to use it.. well then the client just flips over to xterm-256col

Talking about xterm. xterm is a full superset of vt100, including even mouse control and window title setup.
Neither this nor any of the real vt100 features like cursor control, graphical line chars, larger/double
sized characters are supported. I think a basic type with colour codes, like ansi, would be a more
realistic reply than xterm.

File Attachment:

File Name: termnegpcap.zip
File Size:2 KB


Best regards.
Attachments:

Please Log in or Create an account to join the conversation.

  • aldie
  • aldie's Avatar Topic Author
  • Offline
  • Junior Member
More
08 Mar 2019 01:24 #2 by aldie
Replied by aldie on topic Terminal Emulation
Hi,

and another issue: Setting colours and text effects with ANSI colour escape
sequences is supported. For example, you can do
ESC[32;44m for green text on black.

Alas, setting for and background colour in two commands like
ESC[32mESC[44m does not work. Or more precisely, the second
command resets the color setting of the first one. Just as if
a 0 (reset) parameter were included.. but it is not.

Funnily enough, combining with a bright attribute from a seperate ESC[ sequence
works.

Of course, supporting some more of the standard ANSI attributes like italics
underline reverse ((slow)blink? well this one is rare) would be rocking.

I had to disable all BG colour settings to get a readable screen display with the
portal app.

Best regards.

Please Log in or Create an account to join the conversation.

More
09 Mar 2019 17:39 - 09 Mar 2019 17:40 #3 by plamzi
Replied by plamzi on topic Terminal Emulation
Hi,

I've not been able to identify a place where the client sends an unsolicited TTYPE.

The relevant lines of code are found in the telnet proxy, lines 482-499: github.com/plamzi/MUDPortal-Web-App/blob...ter/proxy/wsproxy.js

Here's what TTYPE negotiation looks like when using KaVir's protocol snippet on a Circle MUD:

Sat Mar 9 11:34:22 :: ProtocolNegotiate entered, client is Unknown
Sat Mar 9 11:34:22 :: TTYPE ENTER with ttype string mudportal.com
Sat Mar 9 11:34:22 :: Looking for 256color support in mudportal.com
Sat Mar 9 11:34:22 :: REQUEST NEXT TTYPE
Sat Mar 9 11:34:22 :: CON_TTYPE wait is 4
Sat Mar 9 11:34:22 :: TTYPE ENTER with ttype string XTERM-256color
Sat Mar 9 11:34:22 :: Looking for 256color support in XTERM-256color
Sat Mar 9 11:34:22 :: Detected 256color support
Sat Mar 9 11:34:22 :: REQUEST NEXT TTYPE
Sat Mar 9 11:34:22 :: TTYPE ENTER with ttype string MTTS 141
Sat Mar 9 11:34:22 :: Looking for 256color support in MTTS 141
Sat Mar 9 11:34:22 :: REQUEST NEXT TTYPE
Sat Mar 9 11:34:22 :: ATCP: Received: var 'client', value 'mudportal.com'
Sat Mar 9 11:34:22 :: nanny: y
Sat Mar 9 11:34:22 :: ATCP: Received: var 'client_version', value '1.0'
Sat Mar 9 11:34:22 :: ATCP: Received: var 'client_ip', value '::ffff:XX.XX.XX.XX'
Sat Mar 9 11:34:22 :: sent MSDP: ▒▒ESERVER_IDBedlam▒▒

Of course, the Mudportal is lying about XTERM vt100, but that seems to be the only way that some games will identify it as being able to support 256 colors (that's the part of the ttype string we care about). End of the day, games using vt100 will find out pretty quickly that they're not playable on this client.
Last edit: 09 Mar 2019 17:40 by plamzi.

Please Log in or Create an account to join the conversation.

More
09 Mar 2019 17:42 #4 by plamzi
Replied by plamzi on topic Terminal Emulation
Colors are handled here: github.com/plamzi/MUDPortal-Web-App/blob.../modules/Colorize.js

If you make fixes or expand support, I'd be happy to merge your changes.

Please Log in or Create an account to join the conversation.

  • aldie
  • aldie's Avatar Topic Author
  • Offline
  • Junior Member
More
11 May 2019 13:46 #5 by aldie
Replied by aldie on topic Terminal Emulation
Hi, attached is the TTYPE patch/diff I promised for clarification. For me it works well. I'd also suggest to add 'ansi' to the proposed terminal types.
vt100 does not know about colours also a bunch of vt100 goodies are missing and probably are impossible to implement in a browser anyway.
xterm-256color is FAR to specific.. MTTS is also pretty uncommon. (none of the clients I used supports it).

I think supporting ANSI will help many muds to interact, but I may be wrong.

I understand this might cause interop issues with your mud. Ok, I'd expect ttype negot to fail in your mud with other terminal clients then as well, but if you use only the portal that might be fine.

For our mud both things don't matter!! I added a specific mudportal terminal profile and I managed to ignore the unsolicity ttype response during the negotiation phase already.

As you referred to your mud code base, some info from me: Our mud is based on an Amylaar LPmud driver originating from Oct 1994.
I added the telnet negotations for TTYPE and NAWS and also MXP in July 2007 after reading bunchs of specs und experiments with countless clients (mud and generic) and OS types. I think it needed about 1-2 years to implement from the first ideas. There are few (since the code is very complex and badly documented) changes in the game driver accompanied with several in game extensions in LPC.

The major efforts were to add it into the mudlib behind the scenes s.t. all the existing code base and areas are automatically enhanced with context-based MXP menus. I dunno, from others I heard it is a pretty decent & complete implementation. Anyway, I was a bit disappointed when I learned the mudclients implemented only parts of mxp and also tended to be a bit buggy.

Regards,
Aldie

Please Log in or Create an account to join the conversation.

  • aldie
  • aldie's Avatar Topic Author
  • Offline
  • Junior Member
More
11 May 2019 14:15 #6 by aldie
Replied by aldie on topic Terminal Emulation
A bit more on colors. I started working on it, and I made it first recognize all Ansi Sequences (at least those we use). I learned there is
quite a mixture of deprecated tags (<u>) or unused parts (variable flip) in it. Using the attached reference from a 'real' xterm emulation (yes,
it DOES blink (currently off in the screen shot) , from old portal screen it now went to the new screen . I also modified the color values, background light cyan being just white (frost color) just didn't do it. I also attach the screen shot.

I'll continue to work on it, and share when I'm done. However, two questions:
  • Would you accept 'real' blinking text? Replacing with italics is fairly common, but I think I can make it blink with limited effort.
  • Apart from that, the real issue is, that ansi code has no open/closing tag semantics. Things like underline on/off, color changes and reset to default are all intermixed and must be combinable. That means, I need a status somewhere holding THE current terminal state. I'm thinking about statics in colorize (easy) or attributes in the ScrollView object. I need to analyze the code a bit more to understand how to do it right.

    Is it actually possible that there is more than one ScrollView instance in a browser session? If so, I'd have to add a bit more effort.

Finally a comment, I find the xterm variable and multicolor semantics a bit odd. once xterm 256 colors are used, you cannot get back to simple colors. of course, the fact that colorize currently has no global effects mitigates this issue.. I'm not going to change this though as we are not going to use these colours in our mud.

Regards,
Aldie
Attachments:

Please Log in or Create an account to join the conversation.

  • aldie
  • aldie's Avatar Topic Author
  • Offline
  • Junior Member
More
11 May 2019 17:33 #7 by aldie
Replied by aldie on topic Terminal Emulation
I think I'm beyond that point with local vars per Colorize object. I'm too much in a rush to send screen shots right now... I had to reorganize a bit.. Funny approach to reorder and unify the interpretation of colorcodes. I understand the optimization idea behind it, but it does not interact when there is a state in the terminal... I start getting a working ansi emulation. I#d still like to have a comment on real blink vs italics.

Please Log in or Create an account to join the conversation.

  • aldie
  • aldie's Avatar Topic Author
  • Offline
  • Junior Member
More
14 May 2019 16:47 - 14 May 2019 16:50 #8 by aldie
Replied by aldie on topic Terminal Emulation
Just as a quick report where I am standing... this is not meant as a final submission, though I think I made some substantial progress as the attached screen shots show. I had to reorganize the whole logic of colorize.js. Somehow I think it used an xml style of thinking, where each terminal sequence can be replace with an html tag which all need to be closed in an orderly and reverse fashion. I added a real blink and to me it looks awesome. Also, background colours when used for text graphics should fill the whole cell.
I'm unsure if I also do that for reverse (it is in the screenshots, but I also had it different). I understand there was a large linespacing, probably for increased readability, however it looked very odd with the background colours. So I reduced it a tiny bit.. kind of a compromise.. we'll see how it looks with
line graphics chars... if I decide to add them.
Apart from the issues with mixing colour codes in random orders, colorize could not deal with ESC sequences when split over consecutive calls (you see this as artefacts like [44m in the printout; I think using a buffer I found a cool yet simple solution.). There are still issues with randomly added </SPAN><SPAN> tags into the text that return to default colours where it is not expected. I think they come from ScrollView.js, but are also used during scrolling and first tests did not seem to deal with the issues.
I also did not thoroughly test all features (if that's at all possible). Again, this is just an update where I stand. I'm about to go in vacation next week, and my gf might hit me if I code something during vacation.. so I may not send an update for a while.

Also, after I fixed the issue in Socket.js, I can also use your telnet proxy, if I really want to. However, there are still some legal issues with that and I'm not sure if thats feasable and what legal disclaimers I need to add with that. I spent some more time to get a working node.js, even tried 5 year old sources or binary packages, but I just miss too many requirements on the game server.

Here are some before / after screenshots of "graphically challenging" parts of our mud(more are attached):


Regards,
Aldie.
Last edit: 14 May 2019 16:50 by aldie. Reason: Attachments garbled during upload.

Please Log in or Create an account to join the conversation.

  • aldie
  • aldie's Avatar Topic Author
  • Offline
  • Junior Member
More
09 Jul 2019 20:57 #9 by aldie
Replied by aldie on topic Terminal Emulation
Fellow Mud Admin,

If you come across this message, because there are massive compatibility issues of the portal with your mud, garbled colors.

Maybe also mxp not working.. but that's a second thing.

Maybe my code will help you. Get an Admin/Coder account. Go to Forum>Portal App>Tutorials>Getting Started and follow the instructions to customize your own mud. However, do not use Bedlam-init.js as the source of your copy, use Aldebaran-init.js instead.

Change/add/remove any customization, background between the

// ADD YOUR PERSONAL MUD STYLE BELOW HERE

and

// LEAVE THE REST UNTOUCHED TO GET BETTER ANSI COLOURS AND MXP SUPPORT

comments.

Even when you did all right, Plamzi has to set you up as an 'official admin' for the mud for your module to load for all players (will work as long as you are logged in to the portal though). If you wonder, in Keywords give a comma-sep list of hosts/ports like: fqdn1:port1,fqdn2:port2

But, apparently only one alias fqdn can be used by all players to load the custom file.

Maybe my changes will help to support your mud.

Enjoy.

Please Log in or Create an account to join the conversation.