22 Mar, 2011, KaVir wrote in the 21st comment:
Votes: 0
kiasyn said:
Kayle said:
To make yet another protocol people won't bother using.

people use MSSP and MSDP.


In fact MSSP is even supported by SmaugFUSS - the very project Kayle claims to lead in his signature. Yet a couple of days later we see yet another similar comment:

quixadhal said:
Maybe instead of coming up with yet another redundant protocol,


This is precisely the sort of willfully ignorant hostility that killed MudStandards.

MSSP and MSDP are far from redundant. They're also both gaining in popularity - particularly MSSP, since snippets were made available for it. Once I release my snippet, it will make MSDP just as readily available to anyone who wants it, which by extension will make it considerably easier to design custom interfaces through scripts and plugins.

I've encountered aggressive opposition to this idea elsewhere, from both mud owners and players, who appear to feel threatened by the mere suggestion of graphics. But that's not the sort of ludditism I expect to encounter here.

Scandum said:
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.

Well anything that starts with "xterm" will be covered, so "xterm-256color" would work as well. And I agree it's far from ideal, but it's necessary for detecting support in older versions of WinTin++, so I figured I might as well leave it open as a fallback/workaround for other clients that don't want to add MSDP.

But detecting such support is one of the selling points of MSDP, and I could envision some clients in the future actually adding MSDP just for this sort of thing.
22 Mar, 2011, quixadhal wrote in the 22nd comment:
Votes: 0
Scandum said:
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?


termcap is designed to be extendable. If MUSHCLIENT is a vt100 or an xterm compatible client, that's what it should report via TTYPE. If it has MORE capabilities, perhaps the author of said client should produce a termcap entry which details exactly what it supports and distribute that so mud admins can have it installed into their OS termcap library, just like any other new terminal type. Doing so would even give you the added benefit of being able to use MUSHCLIENT to log into a shell and have it behave normally.

Now, your client may have non-terminal capabilities which termcap/terminfo isn't suited for. THOSE can be handled nicely via MSDP, but that's a higher level of data anyways.
22 Mar, 2011, Ssolvarain wrote in the 23rd comment:
Votes: 0
KaVir said:
They're also both gaining in popularity - particularly MSSP, since snippets were made available for it.



Helpfile from an older ROM mud I've played:
Quote
MCCP is a protocol that allows compression of data between the server and users.


Using MCCP rewards you with a small exp and aqp bonus.

The "compress" command toggles MCCP for your connection. Some clients natively
support MCCP (e.g. zMUD, MUSHClient, TinTin++), whereas others (e.g. GMUD, JMC)
do
not, however this can be solved by use of a proxy such as MCClient (available on

the mud.lu downloads section.

If you do not have MCCP support, attempting to enable compression will result in

"garbage characters" being displayed. Simply disable compression again with the
"compress" command to resume normal, though without MCCP and the bonuses, servic
e.


Just coming out of nowhere with a supporting example :)
22 Mar, 2011, Kayle wrote in the 24th comment:
Votes: 0
kiasyn said:
Kayle said:
To make yet another protocol people won't bother using.


people use MSSP and MSDP.


MSSP only became used in SmaugFUSS, after the plain-text version was introduced. Until that point, it had been largely ignored by project members.
I only started paying attention to MSDP after KaVir got involved. Until then, I ignored it, kind of like I ignore most of the crap that comes out of Scandum's mouth.
22 Mar, 2011, Ssolvarain wrote in the 25th comment:
Votes: 0
Sorry. I read bad today -.-
22 Mar, 2011, Runter wrote in the 26th comment:
Votes: 0
It's pretty interesting that a game gives an in game bonus for using mccp. Someone should give a bonus for rolling classes whose combat abilities are more efficient for the server. To incentivize making the right decisions. :rolleyes:
23 Mar, 2011, David Haley wrote in the 27th comment:
Votes: 0
Runter said:
It's pretty interesting that a game gives an in game bonus for using mccp. Someone should give a bonus for rolling classes whose combat abilities are more efficient for the server. To incentivize making the right decisions. :rolleyes:

That could almost be considered license-violating behavior! By accepting an in-game incentive, you are reducing bandwidth costs for the server administrator, thereby helping them save money!

1) Use MCCP
2) !?!?
3) PROFIT
23 Mar, 2011, Kayle wrote in the 28th comment:
Votes: 0
David Haley said:
Runter said:
It's pretty interesting that a game gives an in game bonus for using mccp. Someone should give a bonus for rolling classes whose combat abilities are more efficient for the server. To incentivize making the right decisions. :rolleyes:

That could almost be considered license-violating behavior! By accepting an in-game incentive, you are reducing bandwidth costs for the server administrator, thereby helping them save money!

1) Use MCCP
2) !?!?
3) PROFIT

Lol.
23 Mar, 2011, KaVir wrote in the 29th comment:
Votes: 0
KaVir said:
Well anything that starts with "xterm" will be covered, so "xterm-256color" would work as well.

Last night I changed my snippet to use cyclic TTYPE, and it now checks specifically for "xterm-256color". I think this is cleaner, even though it no longer detects support in older versions of WinTin++. It does work for the latest WinTin++ however, and will work for the next version of BlowTorch as well.
23 Mar, 2011, Scandum wrote in the 30th comment:
Votes: 0
It'd be better to have non xterm terminals report 256COLOR or ANSI-256COLOR and servers accepting anything with a 256color suffix.

The whole TTYPE thing is messy enough without clients reporting nonsense, unless BlowTorch is an actual xterm emulator.
23 Mar, 2011, KaVir wrote in the 31st comment:
Votes: 0
Scandum said:
It'd be better to have non xterm terminals report 256COLOR or ANSI-256COLOR and servers accepting anything with a 256color suffix.

Well the question is, does "xterm-256color" actually indicate an xterm terminal, or does it just indicate a terminal that supports the "xterm 256 colors" protocol?

I mean, the protocol itself is called "xterm 256 colors" because it was first added by xterm, but it's since been added to other terminal emulators as well.
24 Mar, 2011, Scandum wrote in the 32nd comment:
Votes: 0
KaVir said:
Well the question is, does "xterm-256color" actually indicate an xterm terminal, or does it just indicate a terminal that supports the "xterm 256 colors" protocol

As there's rxvt-256color, konsole-256color, and screen-256color it's pretty obvious that it indicates the terminal is an xterm (emulating) terminal.

It's an option to report "ANSI-256COLOR" as that's guaranteed to be caught by a generic parser, or in a more ideal situation, "ANSI" followed by "MTTS 9".
24 Mar, 2011, quixadhal wrote in the 33rd comment:
Votes: 0
xterm-256color (along with xterm+256color) are terminal types, described in the system termcap or terminfo library. If I remember correctly, they also refer back to the xterm entry, and thus inherit all of that terminal's capabilities as well. So, as far as the OS is concerned, if you say your terminal type is xterm-256color, you are also saying things like "No pad character (NP)", and that the sequence to make the cursor invisible is "\Exterm-256color (along with xterm+256color) are terminal types, described in the system termcap or terminfo library. If I remember correctly, they also refer back to the xterm entry, and thus inherit all of that terminal's capabilities as well. So, as far as the OS is concerned, if you say your terminal type is xterm-256color, you are also saying things like "No pad character (NP)", and that the sequence to make the cursor invisible is "\E[?25l" (vi).

If your emulator/client claims to be xterm-256color, it should support all the functions listed below or expect things to break when the other end sends such sequences. If you code your server to use the termcap/terminfo libraries to get whatever sequences it expects to use, you can actually make things work properly without having to hardcode and pray, or without having to do a lengthly exchange via MSDP to get details that are already known by TTYPE.

As I said before though, MSDP would be great to address non-terminal issues, such as sound support, hyperlinks, etc. Perhaps a set of MSDP keys could be defined to accomplish such things, and that would effectively be your new protocol – without having to make a whole new protocol.

[code]
quixadhal@brezhnev:/usr/share/terminfo/x$ infocmp -CrfT xterm+256color
# Reconstructed via infocmp from file: /usr/share/terminfo/x/xterm+256color
xterm+256color|xterm 256-color feature:\
:cc:\
:Co#256:pa#32767:\
:..AB=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m:\
:..AF=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m:\
:..Ic=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\:\
:Sb@:Sf@:
[/code]

and the parent:

[code]
quixadhal@brezhnev:/usr/share/terminfo/x$ infocmp -CrfT xterm
# Reconstructed via infocmp from file: /lib/terminfo/x/xterm
xterm|X11 terminal emulator:\
:5i:NP:am:bs:km:mi:ms:ut:xn:\
:Co#8:co#80:it#8:li#24:pa#64:\
:#2=\E[1;2H:#3=\E[2;2~:#4=\E[1;2D:%c=\E[6;2~:%e=\E[5;2~:\
:%i=\E[1;2C:*4=\E[3;2~:*7=\E[1;2F:@7=\EOF:@8=\EOM:\
:AB=\E[4%dm:AF=\E[3%dm:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:\
:DO=\E[%dB:F1=\E[23~:F2=\E[24~:F3=\E[1;2P:F4=\E[1;2Q:\
:F5=\E[1;2R:F6=\E[1;2S:F7=\E[15;2~:F8=\E[17;2~:\
:F9=\E[18;2~:FA=\E[19;2~:FB=\E[20;2~:FC=\E[21;2~:\
:FD=\E[23;2~:FE=\E[24;2~:FF=\E[1;5P:FG=\E[1;5Q:\
:FH=\E[1;5R:FI=\E[1;5S:FJ=\E[15;5~:FK=\E[17;5~:\
:FL=\E[18;5~:FM=\E[19;5~:FN=\E[20;5~:FO=\E[21;5~:\
:FP=\E[23;5~:FQ=\E[24;5~:FR=\E[1;6P:FS=\E[1;6Q:\
:FT=\E[1;6R:FU=\E[1;6S:FV=\E[15;6~:FW=\E[17;6~:\
:FX=\E[18;6~:FY=\E[19;6~:FZ=\E[20;6~:Fa=\E[21;6~:\
:Fb=\E[23;6~:Fc=\E[24;6~:Fd=\E[1;3P:Fe=\E[1;3Q:\
:Ff=\E[1;3R:Fg=\E[1;3S:Fh=\E[15;3~:Fi=\E[17;3~:\
:Fj=\E[18;3~:Fk=\E[19;3~:Fl=\E[20;3~:Fm=\E[21;3~:\
:Fn=\E[23;3~:Fo=\E[24;3~:Fp=\E[1;4P:Fq=\E[1;4Q:\
:Fr=\E[1;4R:IC=\E[%d@:K2=\EOE:Km=\E[M:LE=\E[%dD:RA=\E[?7l:\
:RI=\E[%dC:SA=\E[?7h:SF=\E[%dS:SR=\E[%dT:\
:..Sb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m:\
:..Sf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m:\
:UP=\E[%dA:\
:ac=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~:\
:ae=\E(B:al=\E[L:as=\E(0:bl=^G:bt=\E[Z:cb=\E[1K:cd=\E[J:\
:ce=\E[K:ch=\E[%i%dG:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:\
:cs=\E[%i%d;%dr:ct=\E[3g:cv=\E[%i%dd:dc=\E[P:dl=\E[M:\
:do=^J:ec=\E[%dX:ei=\E[4l:ho=\E[H:im=\E[4h:\
:is=\E[!p\E[?3;4l\E[4l\E>:k1=\EOP:k2=\EOQ:k3=\EOR:\
:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:\
:k9=\E[20~:k;=\E[21~:kB=\E[Z:kD=\E[3~:kF=\E[1;2B:kI=\E[2~:\
:kN=\E[6~:kP=\E[5~:kR=\E[1;2A:kb=\177:kd=\EOB:\
:ke=\E[?1l\E>:kh=\EOH:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:\
:ku=\EOA:le=^H:mb=\E[5m:md=\E[1m:me=\E[0m:mk=\E[8m:ml=\El:\
:mr=\E[7m:mu=\Em:nd=\E[C:op=\E[39;49m:pf=\E[4i:po=\E[5i:\
:ps=\E[i:r1=\Ec:r2=\E[!p\E[?3;4l\E[4l\E>:rc=\E8:\
:..sa=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m:\
:sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ta=^I:\
:te=\E[?1049l:ti=\E[?1049h:u6=\E[%i%d;%dR:u7=\E[6n:\
:u8=\E[?1;2c:u9=\E[c:ue=\E[24m:up=\E[A:us=\E[4m:\
:vb=\E[?5h\E[?5l:ve=\E[?12l\E[?25h:vi=\E[?25l:\
:vs=\E[?12;25h:
[/code]
24 Mar, 2011, KaVir wrote in the 34th comment:
Votes: 0
Okay, I'll change the snippet to look for a "256color" suffix.
25 Mar, 2011, Scandum wrote in the 35th comment:
Votes: 0
I've updated the specification. It no longer allows for client side updates and suggests resetting the client's cycling state after receiving the same terminal type twice.

What I plan to do next is describe mouse tracking and the OSC color palette on mudpedia, add MTTS support to the MTH (mud telopt handler) snippet. Adding MTTS support to TinTin++ will be complicated, I'll either have to figure out how to extract the data from termcap/terminfo, or create my own database.
04 Apr, 2011, Scandum wrote in the 36th comment:
Votes: 0
I've been thinking about adding a SCREEN READER flag to indicate the client is using a screen reader. This would be mirrored by a SCREEN_READER configurable variable for MSDP.

There's currently no standardized way to automatically detect a screen reader that I know of.
16 Jun, 2014, SlySven wrote in the 37th comment:
Votes: 0
Sorry to Necro :ghostface: this but I've been looking through RFC1091 and the Official Terminal Type Names and I spotted some details that might mess up your work Scandum. Specifically:
In the Official Terminal Type Names it is said:
A terminal names may be up to 40 characters taken from the set of uppercase letters, digits, and the two punctuation characters hyphen and slash. It must start with a letter, and end with a letter or digit.

In the original RCF it is said:
The terminal type information is an NVT ASCII string. Within this string, upper and lower case are considered equivalent. The complete list of valid terminal type names can be found in the latest "Assigned Numbers".

So that suggests TINTIN++ is an invalid response because of the '+'s (perhaps use TINTIN-PLUS-PLUS) and your protocol as described here can't use a space between MTTS and the bit vector (perhaps you should use MTTS-137 instead).

The reason for my poking around in this area is that I was doing something to Mudlet so that the various places that return its version number all look to the same source rather than having it hard coded into each of them. As one of those places was a fixed string that Mudlet would return in response to a Terminal Type Telnet Sub-Negotiation I got to think about this. From my, possibly flawed understanding of RFC1091, I was looking to cycle through the most specific terminal type description of the client to the least, such as the following list:
  • {client name}-{client version}-{client build} i.e. "MUDLET-3-0-1-RC2-SLYSVEN-MUDLETDEV-PROPO" (only for a "development" or "non-release" version with a really long build name that gets truncated)
  • {client name}-{client version} i.e. "MUDLET-3-0-1" (for either a release version {major 3, minor 0, revision 1} or a development one related to it with its build designation cut off)
  • {client name} i.e. "MUDLET" (generic name for any version of client)
  • XTERM-256 (if it is appropriate, may not be)
  • XTERM (again may not be appropriate)
  • ANSI (pretty much a lowest common denominator!)

  • Note that XTERM and ANSI are explicitly listed as official type names, and that "The type 'UNKNOWN' should be used if the type of the terminal is unknown or unlikely to be recognised by the other party" - i.e. the last value that should be sent twice to signal the end of the list being reached according to RFC1091. Of course:
    Quote
    When the server (the receiver of the TERMINAL-TYPE IS) receives the same response two consecutive times, this indicates the end of the list of available types. Similarly, the client should indicate it has sent all available names by repeating the last one sent. If an additional request is received, this indicates that the server (the sender of the IS) wishes to return to the top of the list of available types (probably to select the least of N evils).
    So after the second request for that last type both parties are to understand a return to the start of the list on receipt by the client of a further request, so the reset at the end of the cycle is mandatory if the cycling is supported and not optional as the MTTS specification seems to suggest?

    Now I may be bolting the stable door long after the horse is over the horizon but to remain faithful to the Official specification for the TTYPE sub-option surely the MTTS result ought to be the FIRST value that is presented on request - also the value that is last read by the Server is the mode that the Client MUST ADOPT so as one reads past XTERM-256 to XTERM the Client must DISABLE 256-colors! In practice I suspect no existing Client responds this way and carries on the same whatever gets reported back. In addition RFC1091 also notes that the terminal type sub-negotiation is an asymmetric one:
    Quote
    Note that this specification is deliberately asymmetric. It is assumed that server operating systems and applications in general cannot change terminal types at arbitrary points in a session. Thus, the client may only send a new type (and potentially change emulation modes) when the server requests that it do so.
    So how does the Client indicate to the Server that the user has just enabled their screen reader? Is it valid to then send IAC WONT TTYPE, wait for a server IAC DONT TTYPE then send a IAC WILL TTYPE and wait for a server IAC DO TTYPE to start again?

    Of course I may have got the wrong end of the stick but if I haven't? :redface:
    16 Jun, 2014, Scandum wrote in the 38th comment:
    Votes: 0
    Most clients and servers ignore the TTYPE standard, rightfully so because it's highly impractical.

    No real point in discussing specific behavior as programmers will do whatever they please.
    16 Jun, 2014, SlySven wrote in the 39th comment:
    Votes: 0
    The esteemed Scandum said:
    No real point in discussing specific behavior as programmers will do whatever they please.

    Maybe so, but if I can make the Client I'm coding for get it right I'd like to do so - just so long as I understand what is right!
    16 Jun, 2014, quixadhal wrote in the 40th comment:
    Votes: 0
    Scandum said:
    Most clients and servers ignore the TTYPE standard, rightfully so because it's highly impractical.

    No real point in discussing specific behavior as programmers will do whatever they please.


    Yeah, since there are some people who just blow through stop signs at intersections, it's stupid for anyone to bother stopping.
    20.0/65