16 Mar, 2011, Scandum wrote in the 1st comment:
Votes: 0
I created an extension to the TTYPE telnet standard that is available here:

http://tintin.sourceforge.net/mtts/

Suggestions for additional terminal capabilities that should be listed and general feedback would be appreciated.


I also created a Wikipedia page that will hopefully result in a better collection of information about generic terminal types. If anyone is interested in updating it with particular knowledge of a terminal emulator that'd be appreciated. I didn't spend too much time on it and there are some obvious errors in it, the page is here:

http://en.wikipedia.org/wiki/Comparison_...
17 Mar, 2011, Cratylus wrote in the 2nd comment:
Votes: 0
I hope you meet your protocol/standards quota. i didn't realize the deadline was so soon.

-Crat
17 Mar, 2011, KaVir wrote in the 3rd comment:
Votes: 0
Please, no bitvectors - we can afford a few extra bytes during negotiation.

To be honest I think it would be easier to keep it fully compatible with RFC1091.

How about something like this:

A client that successfully negotiates any mud-specific protocol (MSP, MCCP, MXP, MSDP, ATCP, etc) is classified as a mud client.

The first TTYPE query is treated as the client name. If the client is also classified as a mud client, it may be queried multiple times as described in RFC1091.

If a mud client reports a terminal-type that begins with "xterm", it can be assumed that 256 colours are supported.
17 Mar, 2011, Scandum wrote in the 4th comment:
Votes: 0
What's the problem with using a bitvector? I find them rather convenient. There's a limit of 64 fields, but in the RFC there's a limit of 40 characters for the TTYPE value.


It's possible to stay fully compatible with RFC1091, though that would mean the client can't send any TTYPE updates.
17 Mar, 2011, KaVir wrote in the 5th comment:
Votes: 0
Scandum said:
What's the problem with using a bitvector?

It's not human readable, and it's harder to extend. What if Mudlet decided to use value 64 for extended ASCII, while MUSHclient simultaneously decided to use that same value for UTF-16, and both overlooked the fact that TinTin++ had already started using it a week earlier for a custom mud font? Worse still, because each new option is extending the specification rather than simply using it, you could end up with multiple conflicting specifications floating around the net.

On the other hand, sending the data as plain text avoids conflicts in all but the most extreme of cases. If Mudlet sends "EXTENDED-ASCII" and MUSHclient sends "UTF-16", it's human-readable (you don't need to rely on the specification to understand what it means) and the clients don't need to worry about treading on each other's toes. Now you could reasonably argue that Mudlet's extended ASCII isn't necessarily the same as that of another client, but at least you know what the value represents.

Scandum said:
It's possible to stay fully compatible with RFC1091, though that would mean the client can't send any TTYPE updates.

I can live with that. If they want to do clever stuff, they should use MSDP.
18 Mar, 2011, quixadhal wrote in the 6th comment:
Votes: 0
So, now you're re-inventing termcap?
18 Mar, 2011, KaVir wrote in the 7th comment:
Votes: 0
quixadhal said:
So, now you're re-inventing termcap?

My counter-proposal is fully compatible with RFC1091, it just makes some additional assumptions if the client negotiates a mud-specific protocol. Personally I'd rather stick with MSDP, and my snippet certainly supports clients that favour that option. Another client developer I've spoken to has already expressed a preference for using MSDP rather than cyclic TTYPE, and to be honest I think that's easier to implement at both ends.

However Scandum does not wish to add native MSDP support to TinTin++/WinTin++, and other client developers may feel the same - so if my snippet is going to autodetect XTerm 256 color for those clients, it will need to support cyclic TTYPE as well.
18 Mar, 2011, Scandum wrote in the 8th comment:
Votes: 0
I don't think other mud clients would randomly start using random bits. I could assign the first 24 bits to be official, and bit 25 to 32 as unofficial "do as you please" bits. That'll take care of that problem.

As most existing MUDs would save the data as a bitvector and the data isn't going to be written to file I'd hate to use a plain text format and make implementation even more difficult.

Using MSDP is definitely a good alternative, just that I don't want to use MSDP for out of the box functionalit. Scripting configurations in MSDP will be fairly easy, while writing a custom TTYPE handler will be more difficult.
18 Mar, 2011, David Haley wrote in the 9th comment:
Votes: 0
Scandum said:
I could assign the first 24 bits to be official, and bit 25 to 32 as unofficial "do as you please" bits. That'll take care of that problem.

For the first 24/32 bits, at least…
20 Mar, 2011, Scandum wrote in the 10th comment:
Votes: 0
Most protocols are self negotiating so I doubt there'll ever be a need to go beyond 32 bits. The termcap comment is kind of 'out there' as well.

I think I'll make MTTS more compatible with the last TTYPE rfc as there are a few muds that try to cycle.

Hard to decide on the human readability issue with the current feedback.
20 Mar, 2011, David Haley wrote in the 11th comment:
Votes: 0
It's not human-readability per se… it's extensibility. Using fixed numbers in this day is just a little silly. That said, I don't really get what the point of this protocol is.
20 Mar, 2011, Kayle wrote in the 12th comment:
Votes: 0
To make yet another protocol people won't bother using.
20 Mar, 2011, kiasyn wrote in the 13th comment:
Votes: 0
Kayle said:
To make yet another protocol people won't bother using.


people use MSSP and MSDP.
20 Mar, 2011, Tijer wrote in the 14th comment:
Votes: 0
more will use it when KaVir finishes the MERC snippet hes working on… (MSDP/MSSP that is)
20 Mar, 2011, David Haley wrote in the 15th comment:
Votes: 0
Those didn't involve terminal applications over which we (as a community) have extremely little control.
21 Mar, 2011, KaVir wrote in the 16th comment:
Votes: 0
I decided just to leave it as it is in my snippet, except apply the TinTin++/WinTin++ solution to all clients - they're queried twice, if the two responses are different and the second begins with the text "xterm", then the 256 colours are automatically enabled.

It's not generic and it's not extendable, but it retroactively covers WinTin++ without including that funny "XTERM-COLOR" client one of my players uses (the one that doesn't actually support XTerm 256 color), and it means there is an alternative for other clients that don't want to natively support MSDP.

However as my snippet is still primarily an MSDP snippet, I don't think it makes sense for me to invest too much time and effort into coming up with a non-MSDP workaround, particularly when this is something that MSDP already handles extremely well - it's not just something I made up for the snippet, it's actually explicitly covered in the specification.

Whatever solution is used, most client developers will probably ignore it, but my snippet can already (indirectly) identify 256 colour support in most major clients, so this is really just for future clients or clients I wasn't able to cover. The Atlantis developer has expressed a preference for using MSDP rather than changing TTYPE, and the BlowTorch developer is still weighing up his options, but the important thing is that clients have some way of indicating support - and they do. In fact, they have two different ways.
21 Mar, 2011, Runter wrote in the 17th comment:
Votes: 0
We should take this to mud standards for immediate consideration and not act upon it until there's unanimous consent. :rolleyes:
21 Mar, 2011, KaVir wrote in the 18th comment:
Votes: 0
MudStandards is gone.

Besides which, nobody on there was interested in MSDP anyway.
22 Mar, 2011, quixadhal wrote in the 19th comment:
Votes: 0
It's not "out there" at all. termcap has been used by your login shell for what, 40 years now? It does the job of EXACTLY describing the capabilities of the terminal, along with the sequences needed to make use of them. This isn't just grabbing the TTYPE name and then hard coding sequences like just about every MUD does now.

IE: Why do you need to describe a terminal type standard when there's ALREADY a well established protocol for doing that? You grab TTYPE and then you use the termcap library to see what that terminal can do.

Maybe instead of coming up with yet another redundant protocol, you should instead add proper and full termcap support to your MUD server? Showing others (by example) how to do that would be far more useful than another protocol, IMHO.
22 Mar, 2011, Scandum wrote in the 20th comment:
Votes: 0
quixadhal said:
It's not "out there" at all. termcap has been used by your login shell for what, 40 years now? It does the job of EXACTLY describing the capabilities of the terminal, along with the sequences needed to make use of them. This isn't just grabbing the TTYPE name and then hard coding sequences like just about every MUD does now.

So termcap will tell me if "MUSHCLIENT" supports VT100, "KILDCLIENT" supports UTF-8, and if "ZMUD" supports 256 colors?

KaVir said:
I decided just to leave it as it is in my snippet, except apply the TinTin++/WinTin++ solution to all clients - they're queried twice, if the two responses are different and the second begins with the text "xterm", then the 256 colours are automatically enabled.

I'd hate to have mud clients report themselves as xterm just to get 256 colors to work, while not supporting VT100. As far as I know there isn't a universal terminal type that only indicates 256 color support, but it seems to be a bit of a standard that appending "256color" should do the trick. In the wild you'll see xterm-256color, screen-256color, and rxvt-256color. Would it make sense to add 256COLOR in addition to DUMB, ANSI, VT100, and XTERM?

KaVir said:
Whatever solution is used, most client developers will probably ignore it, but my snippet can already (indirectly) identify 256 colour support in most major clients, so this is really just for future clients or clients I wasn't able to cover. The Atlantis developer has expressed a preference for using MSDP rather than changing TTYPE, and the BlowTorch developer is still weighing up his options, but the important thing is that clients have some way of indicating support - and they do. In fact, they have two different ways.

MSDP is a good alternative.
0.0/65