Feature Request: TERMTYPE

Post Reply
User avatar
bozimmerman
Posts: 11
Joined: Tue Jul 09, 2013 1:40 am
Location: Round Rock, TX
Contact:

Feature Request: TERMTYPE

Post by bozimmerman »

Not sure this is the right place, but I would like to request that a future version of mudlet respond to the Telnet TERMTYPE sub-negotiation request. "mudlet" would be a suitable response, imho. But, anything, really, is fine so long as it's unique.

This would allow server developers, such as myself, to code special exceptions for some of mudlets unique implementations.

Thanks,
Bo Zimmerman

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Feature Request: TERMTYPE

Post by Vadi »

Hi!

Mudlet already responds to TERMTYPE. Could you make sure you're testing with the latest 3.9 version?

We're aware of CoffeeMUD having issues parsing output provided by Mudlet (https://github.com/Mudlet/Mudlet/issues/1630), is that what you're looking after?

User avatar
bozimmerman
Posts: 11
Joined: Tue Jul 09, 2013 1:40 am
Location: Round Rock, TX
Contact:

Re: Feature Request: TERMTYPE

Post by bozimmerman »

Hi.. Yes, I did try the latest version. I can probably work around anything else if I can just know that mudlet is connecting.

Here is a summary of the telnet negotiation going on. You can see that the subnegotiation is sent.... twice, in fact. However, it doesn't appear that a response is ever received. Perhaps you can see an error where my old tired eyes cannot?

20180521.1855.48 debug Worker0#5 OUTPUT: '255 250 24 1 255 240 '
20180521.1855.48 debug Worker0#5 Sent: Will TERMTYPE
20180521.1855.48 debug Worker0#5 Sent sub-option: TERMTYPE
20180521.1855.48 debug Worker0#5 OUTPUT: '255 251 86 '
20180521.1855.48 debug Worker0#5 Sent: Will COMPRESS2
20180521.1855.48 debug Worker0#5 OUTPUT: '255 251 91 '
20180521.1855.48 debug Worker0#5 Sent: Will MXP
20180521.1855.48 debug Worker0#5 OUTPUT: '255 251 201 '
20180521.1855.48 debug Worker0#5 Sent: Will GMCP
20180521.1855.48 debug Worker0#5 OUTPUT: '255 251 90 '
20180521.1855.48 debug Worker0#5 Sent: Will MSP
20180521.1855.48 debug Worker0#5 OUTPUT: '255 251 69 '
20180521.1855.48 debug Worker0#5 Sent: Will MSDP
20180521.1855.48 debug Worker0#5 OUTPUT: '255 251 31 '
20180521.1855.48 debug Worker0#5 Sent: Will NAWS
20180521.1855.48 info Worker0#6 BINPUT: : '255 253 24 '
20180521.1855.48 debug Worker0#2 Got DO TERMTYPE
20180521.1855.48 debug Worker0#2 Sent sub-option: TERMTYPE
20180521.1855.48 debug Worker0#2 OUTPUT: '255 250 24 1 255 240 '
20180521.1855.48 info Worker0#6 BINPUT: : '255 253 86 '
20180521.1855.48 debug Worker0#2 Got DO COMPRESS2
20180521.1855.48 debug Worker0#2 Got DO MXP
20180521.1855.48 info Worker0#7 BINPUT: : '255 254 90'
20180521.1855.48 debug Worker0#2 Got DONT MSP
20180521.1855.48 debug Worker0#2 OUTPUT: '255 252 90 '
20180521.1855.48 debug Worker0#2 Sent: Won't MSP
20180521.1855.48 debug Worker0#2 Got DONT MSDP
20180521.1855.48 debug Worker0#2 OUTPUT: '255 252 69 '
20180521.1855.48 debug Worker0#2 Sent: Won't MSDP
20180521.1855.48 info Worker0#7 BINPUT: : '255 253 31 '
20180521.1855.48 debug Worker0#2 Got DO NAWS
20180521.1855.48 info Worker0#7 BINPUT: : '255 254 69'
20180521.1855.48 debug Worker0#2 Got DONT MSDP
20180521.1855.48 info Worker0#4 BINPUT: : '255 254 90 '
20180521.1855.49 debug Worker0#7 Sent sub-option: COMPRESS2
20180521.1855.49 debug Worker0#7 OUTPUT: '255 250 86 255 240 '
20180521.1855.49 debug Worker0#7 MCCP compression started

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Feature Request: TERMTYPE

Post by SlySven »

It returns a constant "Mudlet m.n.p" where m is major version number (3), n is minor (9), and patch (0) at the moment for release builds plus an additional string that will be "-dev" for current development versions but can be tweaked individually if necessary for special purposes. Technically the TTYPE string is NOT case-sensitive, and should be no more than 40 characters drawn from a subset of ASCII that only includes LETTERS, NUMBERS, or the '/' or '-' characters, it must start with a letter and end with a letter or a number; so, apart from the space and the period characters we are almost in compliance with RFC1091 which specifies this Telnet Sub-option (24) and RFC1010 which specifies the characters for the text.

In the medium term I would like to extend it to support Scandum's Mud Terminal Type Standard but until he and I can come to some agreement about how to handle the client renegotiating a change in the things that it reports - say like they have switched to using the UTF-8 encoding or switched-on or off a screen reader; I am not going to go ahead with that. :twisted:

Oh, I think I can see one problem - you are sending a WILL TTYPE - that says that you, the Server, will send your Terminal Type if Mudlet requests it (with a DO TYPE); that is, to use a technical term arse-about-face:lol: - you need to send a DO TTYPE (i.e. a request for the other party do something) so that the recipient, i.e. Mudlet can respond WILL TTYPE (ok, I will do something)...

User avatar
bozimmerman
Posts: 11
Joined: Tue Jul 09, 2013 1:40 am
Location: Round Rock, TX
Contact:

Re: Feature Request: TERMTYPE

Post by bozimmerman »

That did the trick, thanks!

Turns out this was likely a cut and paste error that has gone unnoticed for 15 years because Mudlet was the first client to care about the difference.

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Feature Request: TERMTYPE

Post by SlySven »

That is probably applicable to a couple of the other options as well - I do not think Mudlet wants to Negotiate About Window Size on the CoffeeMUD server but it is perfectly happy to tell the Server how big its (main) window is! I think MSDP (or is it MSP) is another one as Mudlet is not interested in playing tunes on the server either - technically I think MXP needs to be agreed in both directions as it is bi-directional but since I really do not grok it (does anyone other than Zugg?) I can't really say - I agree with you when you say we do not properly support at least what I think is version 1.0 of that because we do not support the <support> tag but I cannot see it getting fixed quickly. This is simply because I do not know if anyone currently plugging in Mudlet code contributions can risk delving into the area of the codebase where the MXP decoding takes place.

Here be dragons is one term that comes to my mind when I contemplate that part of our cTelnet C++ class...

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Feature Request: TERMTYPE

Post by Vadi »

@bozimmerman how did you go with this? Anything else we can help you out with?

Post Reply