10 Jun, 2011, Scandum wrote in the 21st comment:
Votes: 0
quixadhal said:
If it's so "near impossible" to get termcap to work properly, how is that that it's used to handle shell logins on pretty much EVERY unix or unix-like system out there? If sshd can figure out a workable terminal type solution, there's no reason any given MUD server can't do the same.

The first problem would be that there will be no entries for zmud, mushclient, tintin++, etc. The second problem will be that pretty much all terminal emulators report xterm because of the first problem. The reason the unix system works is because all terminals emulate VT100 to a good enough degree for most applications to work. As such it's best to use the most commonly used VT100 sequences, and use other methods to get more detailed information about terminal capabilities, like MTTS.
11 Jun, 2011, quixadhal wrote in the 22nd comment:
Votes: 0
ProjectMoon said:
SSH is using a tty library directly though. Telnet doesn't really have that kind of direct control over the screen.


Not correct. What do you think an SSH connection is? It's not magical, it's just a raw tcp/ip socket (just like text MUD's use) with encryption and key exchange layered on top. TELNET is exactly the same thing, but it uses a different set of control sequences. A great many MUD's don't actually use TELNET at all, they simply accept socket connections and read and write text. As it happens, the TELNET protocol allows this, as the control mechanisms use characters that aren't found commonly in plain text.

Again, we used to connect to our login shells using TELNET before SSH even existed. It worked just fine, you had the full capabilities of whatever terminal you were sitting at if it was recognized by the termcap system. If it wasn't, you could either try to find a "close enough" match and set your TERM variable to it, or you could write (or find) a termcap entry for your terminal and have your sysadmin install it.

Scandum said:
The first problem would be that there will be no entries for zmud, mushclient, tintin++, etc. The second problem will be that pretty much all terminal emulators report xterm because of the first problem. The reason the unix system works is because all terminals emulate VT100 to a good enough degree for most applications to work. As such it's best to use the most commonly used VT100 sequences, and use other methods to get more detailed information about terminal capabilities, like MTTS.


You really need to learn your history before trying to use it to support your warez.

First of all, the unix system worked just fine BEFORE the vt100 existed. I know that concept must hurt your brain, but there it is. The notion that "all terminals emulate vt100" is just plain wrong. You want to use vt100 because it's what you're comfortable with, and because you have a vested interest in inventing your own limited version of termcap as MTTS, rather than spend the time and energy it would take to use termcap itself.

Secondly, if there are no entries for zmud, musclient, tintin++… maybe you should MAKE THEM? The entire point of the termcap system is that it was designed to be extensible, so when a new terminal appeared on the market, sysadmins could go edit a couple of files and EVERY application on their system would properly and fully support it, not matter how different it was from any other terminal. I suspect if someone were to make proper files for these clients and submit them to the various folks who maintain such things, at least some linux/bsd distributions would include them. Even if they didn't, you could easily make them available for download with a README telling people how to install them to their system.

I also don't think you actually understand that TTYPE returns multiple values. Many terminal emulators will return "xterm" on the FIRST TTYPE negotiation, because that's one of the most popular. If you bother to repeat your query (as the TELNET spec says you should), it may well also return vt100, ansi, and whatever it actually is in subsequent runs. That's not the right way for them to do things (they should return the exact match first, and then other things they support later), but… what can you do? I'll tell you one thing you should NOT do…. you should NOT base your server design around broken clients. Design for how it's supposed to work, and then adapt to how it's being abused, not the other way around.

If you guys want to fiddle around with raw vt100 sequences and rolling your own protocol, by all means… I can't stop you. I think you're wasting a LOT of energy and making a second-rate product by doing so, since a better solution already exists and is being used RIGHT NOW by every unix machine that allows remote connections to shells (via SSH, TELNET, RSH, or several other transports).
11 Jun, 2011, Runter wrote in the 23rd comment:
Votes: 0
Quote
If you guys want to fiddle around with raw vt100 sequences and rolling your own protocol, by all means… I can't stop you. I think you're wasting a LOT of energy and making a second-rate product by doing so, since a better solution already exists and is being used RIGHT NOW by every unix machine that allows remote connections to shells (via SSH, TELNET, RSH, or several other transports).


I coulda swore they were using MSDP.
11 Jun, 2011, donky wrote in the 24th comment:
Votes: 0
quixadhal said:
If you guys want to fiddle around with raw vt100 sequences and rolling your own protocol, by all means… I can't stop you. I think you're wasting a LOT of energy and making a second-rate product by doing so, since a better solution already exists and is being used RIGHT NOW by every unix machine that allows remote connections to shells (via SSH, TELNET, RSH, or several other transports).
What are Windows machines supposed to do?
11 Jun, 2011, Tyche wrote in the 25th comment:
Votes: 0
Those daemons spawn processes for each connection. I don't know of any support libraries that would not have to be extensively rewritten to work with a multiple connection per process model that many muds use.
11 Jun, 2011, Scandum wrote in the 26th comment:
Votes: 0
quixadhal said:
First of all, the unix system worked just fine BEFORE the vt100 existed. I know that concept must hurt your brain, but there it is. The notion that "all terminals emulate vt100" is just plain wrong. You want to use vt100 because it's what you're comfortable with, and because you have a vested interest in inventing your own limited version of termcap as MTTS, rather than spend the time and energy it would take to use termcap itself.

MTTS is more capable than termcap for the reasons I've previously cited. Anyone with a little bit of common sense will understand this.

quixadhal said:
Secondly, if there are no entries for zmud, musclient, tintin++… maybe you should MAKE THEM?

I suggest you show us how easy this is by getting an entry for your favorite client submitted and added to a significant portion of the *nix distros.

quixadhal said:
I also don't think you actually understand that TTYPE returns multiple values. Many terminal emulators will return "xterm" on the FIRST TTYPE negotiation, because that's one of the most popular. If you bother to repeat your query (as the TELNET spec says you should), it may well also return vt100, ansi, and whatever it actually is in subsequent runs.

Only Windows telnet cycles through terminal types, which doesn't exactly help your argument.

quixadhal said:
If you guys want to fiddle around with raw vt100 sequences and rolling your own protocol, by all means… I can't stop you. I think you're wasting a LOT of energy and making a second-rate product by doing so, since a better solution already exists and is being used RIGHT NOW by every unix machine that allows remote connections to shells (via SSH, TELNET, RSH, or several other transports).

Are we allowed to fiddle around with raw vt100 color sequences without implementing termcap first?
11 Jun, 2011, quixadhal wrote in the 27th comment:
Votes: 0
donky said:
quixadhal said:
If you guys want to fiddle around with raw vt100 sequences and rolling your own protocol, by all means… I can't stop you. I think you're wasting a LOT of energy and making a second-rate product by doing so, since a better solution already exists and is being used RIGHT NOW by every unix machine that allows remote connections to shells (via SSH, TELNET, RSH, or several other transports).
What are Windows machines supposed to do?


What do windows machines do now? Even if windows doesn't provide a native termcap layer, people seem to insist on using cygwin, and I'm pretty sure it does.

Scandum said:
MTTS is more capable than termcap for the reasons I've previously cited. Anyone with a little bit of common sense will understand this.

Can you drive with those blinders on, or do you have to take the bus everywhere? Your POTM (Protocol Of The Month) is a nice addition to termcap, in that it can describe things that have nothing to do with the terminal itself, but claiming it's more capable is just ignorant.

If it really WERE more capable, then you wouldn't need to tell people to just hard-code vt100 sequences and assume they'll work. MTTS would tell you what the right sequence is for CURSOR_RIGHT or whatever, no?

Scandum said:
quixadhal said:
Secondly, if there are no entries for zmud, musclient, tintin++… maybe you should MAKE THEM?

I suggest you show us how easy this is by getting an entry for your favorite client submitted and added to a significant portion of the *nix distros.

Ever heard of the screen program? It has termcap entries on most systems, and that wasn't the case 15 years ago. Perhaps you should consider asking people to do things, rather than laying down the law and expecting others to jump on board?

Scandum said:
quixadhal said:
I also don't think you actually understand that TTYPE returns multiple values. Many terminal emulators will return "xterm" on the FIRST TTYPE negotiation, because that's one of the most popular. If you bother to repeat your query (as the TELNET spec says you should), it may well also return vt100, ansi, and whatever it actually is in subsequent runs.

Only Windows telnet cycles through terminal types, which doesn't exactly help your argument.

So you've gone out of your way to try each of the thousands of different terminals AND terminal emulators out there and can say, with confidence, that ONLY Windows telnet follows that part of the TELNET specification correctly? Really?
11 Jun, 2011, quixadhal wrote in the 28th comment:
Votes: 0
Tyche said:
Those daemons spawn processes for each connection. I don't know of any support libraries that would not have to be extensively rewritten to work with a multiple connection per process model that many muds use.


Now that is a reasonable point. I ran into that issue with the curses library. However, while it's probably not feasable to ensure all the support libraries can work in MUD code, it's not impossible for MUD code to be rewritten to spawn a new process for each connection, provided all it's doing is I/O. Most modern chat systems use multi-threading instead of multiplexing because it scales more easily. I/O is one of the few places MUD's can actually get away with multi-threading (or multiple processes using named pipes).
11 Jun, 2011, Scandum wrote in the 29th comment:
Votes: 0
quixadhal said:
Can you drive with those blinders on, or do you have to take the bus everywhere?

Do you have to act like a douchebag?

quixadhal said:
Ever heard of the screen program? It has termcap entries on most systems, and that wasn't the case 15 years ago. Perhaps you should consider asking people to do things, rather than laying down the law and expecting others to jump on board?

Like I've said before, screen, xterm, and rxvt is about what most systems support, and screen isn't even an end user terminal emulator.

quixadhal said:
Perhaps you should consider asking people to do things, rather than laying down the law and expecting others to jump on board?

Opposed to expecting others to jump on board to lay down the law?

Scandum said:
So you've gone out of your way to try each of the thousands of different terminals AND terminal emulators out there and can say, with confidence, that ONLY Windows telnet follows that part of the TELNET specification correctly? Really?

So now there are a thousand different terminals requiring termcap entries? Do keep proving my point.
11 Jun, 2011, quixadhal wrote in the 30th comment:
Votes: 0
I'm not suggesting taking the time to invent something out of thin air that would let arbitrary terminals share a common API so they all work when you tell them to move the cursor to position x,y. That would be a LOT of work. However, other people have already done it, and I'm arguing that maybe it ought to be used, rather than just assuming the world is filled with nails so you can swing your vt100 hammer.

If you ALSO want to use your MSDP/MTTS protocols to describe features that termcap wasn't designed to deal with, like sound, the ability to spawn new windows, a mouse interface… great! That's a good idea! But *trying* get the right terminal sequences is also a good idea. If you can't do it, then it's up to you if you want to risk assuming vt100 will work (and botching the screen), or saying "Sorry, your terminal can't do that.".
12 Jun, 2011, Scandum wrote in the 31st comment:
Votes: 0
I've never heard of VT100 displaying problems for VT terminal emulators during the 10 years I ran Emud. Lola works around a packet fragmentation related VT100 problem which I doubt termcap allows checking for. In addition the MTTS spec provides a link to a set of VT100 codes I know to work universally.

The only advantage of termcap would be that the approach could work for a fairly large amount of mud clients, though stuff like 256 color couldn't be checked for consistently as most clients don't report their version.

As it is I'm going to give MTTS a whirl and see if it gets adopted. It's ridiculously easy to implement, all that's needed is sending 3 TTYPE SEND requests at once and sscanf the returned terminal types for MTTS %d.
12 Jun, 2011, Tyche wrote in the 32nd comment:
Votes: 0
quixadhal said:
Tyche said:
Those daemons spawn processes for each connection. I don't know of any support libraries that would not have to be extensively rewritten to work with a multiple connection per process model that many muds use.


Now that is a reasonable point. I ran into that issue with the curses library. However, while it's probably not feasable to ensure all the support libraries can work in MUD code, it's not impossible for MUD code to be rewritten to spawn a new process for each connection, provided all it's doing is I/O. Most modern chat systems use multi-threading instead of multiplexing because it scales more easily. I/O is one of the few places MUD's can actually get away with multi-threading (or multiple processes using named pipes).


Yes those are the options. Well there's three..
1) Rewrite curses, termcap, or whatever you nedd so it doesn't have global state.
2) Write a mud that communicates via user processes (like VaxMud, Monster, original AberMud).
3) Write your own custom system. (i.e. mudcurses)

In any case, one will have the problem that most of the mud clients poorly support vt-xxx, xterm…. and many of the users of those clients would balk at using a real terminal program.

I should add…
4) Write your own custom protocol. ;-)
20 Jun, 2011, Kaz wrote in the 33rd comment:
Votes: 0
ProjectMoon said:
Hmm. Does enabling SGA and Echo give you enough control over the screen to make sort of a curses-like UI?


Apologies for the delayed answer. I'm just back off a holiday. Anyway, the answer is kinda-yes. But you end up choosing between terminal clients and features. For the project I'm working on, the clients I use and test with are PuTTY, TeraTerm, xterm (on Ubuntu Linux, since I can VirtualBox it), and Tintin++.

06 Jan, 2013, Telgar wrote in the 34th comment:
Votes: 0
Jumping into this fun thread. Having just implemented MTTS support, I now believe it isn't really a great idea to send the MTTS options last. This requires looping through all terminal types by the server, then in addition, it requires looping back through the types again to select the terminal type actually requested by the server. You may have to loop back through the types again for terminals which get progressively dumber at each terminal type switch. This could be fixed by sending the MTTS settings first; no sane terminal program will accept them (and it should pose no parsing problem for proper clients, it is legal for terminal types to contains spaces, as the ttype is closed by the IAC SE command).

So properly implementing MTTS doesn't make things easier; in fact it makes it more work rather than just accepting the first terminal type during negotiation that the server supports. I'm not fond of it, but the server code will eventually have to parse terminfo entries. We're doing some pretty fancy stuff for OLC support here, including full on text windows and arrow key entry, and also want to support some more exotic clients running on Android and iPhone.

While I'm pretty sure (okay, 99%) sure that I could get away with sending Ansi escape sequences for text output, I'm not sure at all that I will be getting standard VT-100 up / down / back sequences from arrow keys from those environments.

Unfortunately, the dumb C API for terminfo requires you to either fork multiple I/O processes, use fuggly lowlevel terminfo manipulations to global state, or parse the info file directly. Fortunately, the server here is written in Javascript, which is really good at parsing crap like that into objects and really good at not buffer overflowing during the process.
06 Jan, 2013, Telgar wrote in the 35th comment:
Votes: 0
quixadhal said:
I'm not suggesting taking the time to invent something out of thin air that would let arbitrary terminals share a common API so they all work when you tell them to move the cursor to position x,y. That would be a LOT of work. However, other people have already done it, and I'm arguing that maybe it ought to be used, rather than just assuming the world is filled with nails so you can swing your vt100 hammer.

If you ALSO want to use your MSDP/MTTS protocols to describe features that termcap wasn't designed to deal with, like sound, the ability to spawn new windows, a mouse interface… great! That's a good idea! But *trying* get the right terminal sequences is also a good idea. If you can't do it, then it's up to you if you want to risk assuming vt100 will work (and botching the screen), or saying "Sorry, your terminal can't do that.".


Ugh. Actually I am trying to use terminfo to do the reverse, to map key sequences for arrows, tab, etc. into internal symbols. I can dig up the terminfo capabilities and import them to my MUD no problem. However, the terminfo key sequences don't correspond to the key codes being sent!!! All my xterms (multiple clients, multiple OSes) send ESC

Ugh. Actually I am trying to use terminfo to do the reverse, to map key sequences for arrows, tab, etc. into internal symbols. I can dig up the terminfo capabilities and import them to my MUD no problem. However, the terminfo key sequences don't correspond to the key codes being sent!!! All my xterms (multiple clients, multiple OSes) send ESC[A for "up" keypresses, yet the terminfo for xterms lists kccu1 as "\EOA". This unfortunately means I need to check for multiple escape codes in the input parsing, and I don't really see a clean way to do this for multiple terminal types. Maybe quixadhal has advice here?
06 Jan, 2013, Scandum wrote in the 36th comment:
Votes: 0
Telgar said:
Jumping into this fun thread. Having just implemented MTTS support, I now believe it isn't really a great idea to send the MTTS options last. This requires looping through all terminal types by the server, then in addition, it requires looping back through the types again to select the terminal type actually requested by the server. You may have to loop back through the types again for terminals which get progressively dumber at each terminal type switch. This could be fixed by sending the MTTS settings first; no sane terminal program will accept them (and it should pose no parsing problem for proper clients, it is legal for terminal types to contains spaces, as the ttype is closed by the IAC SE command).

I think the only client that uses TTYPE to select the terminal types is Windows Telnet. One of its modes is somewhat screwy, and I'm not exactly sure how many requests you need to send to select this mode.

So for all intense and purposes I think it's safe to ignore cycling as nobody uses Windows Telnet, except for the occasional troll.

What I did for my server is to send 3 TTYPE requests at once. I store the first response as the client name, and the routine keeps an eye out for an MTTS response.

It's not an option to send MTTS first as many server will only request TTYPE once and expect the client name.

Telgar said:
While I'm pretty sure (okay, 99%) sure that I could get away with sending Ansi escape sequences for text output, I'm not sure at all that I will be getting standard VT-100 up / down / back sequences from arrow keys from those environments.

Pretty much everything uses the Linux VT100 standard for updating the terminal, which is more or less what xterm supports.

The arrow keys are pretty liable as well using the \e
Pretty much everything uses the Linux VT100 standard for updating the terminal, which is more or less what xterm supports.

The arrow keys are pretty liable as well using the \e[ or \eO prefix. There's no need to use the termcap library as everything is trying to be xterm compatible nowadays, and if it's not there's no guessing what the terminal supports.

Subsequently most modern terminals report themselves as xterm, and try to be compatible enough to work with most software.
06 Jan, 2013, KaVir wrote in the 37th comment:
Votes: 0
Scandum said:
So for all intense and purposes I think it's safe to ignore cycling as nobody uses Windows Telnet, except for the occasional troll.

A few of my active players use Windows Telnet while playing from work or school, as it's their only option. I used donky's approach for identifying Windows Telnet prior to negotiation, but if you can't be bothered to do that there's also the workaround I used in my protocol snippet: if the first terminal type is "ANSI", don't cycle.

Scandum said:
It's not an option to send MTTS first as many server will only request TTYPE once and expect the client name.

Exactly, I'd estimate that only around 10-15% of those that detect TTYPE actually cycle through them.

But you need to cycle anyway if you want to detect xterm-256-color. While you can also get that information from MTTS, I think only TinTin++ supports it - if someone is using BlowTorch, for example, you need to check the second TTYPE for a "256-color" postfix.
06 Jan, 2013, quixadhal wrote in the 38th comment:
Votes: 0
Telgar said:
quixadhal said:
I'm not suggesting taking the time to invent something out of thin air that would let arbitrary terminals share a common API so they all work when you tell them to move the cursor to position x,y. That would be a LOT of work. However, other people have already done it, and I'm arguing that maybe it ought to be used, rather than just assuming the world is filled with nails so you can swing your vt100 hammer.

If you ALSO want to use your MSDP/MTTS protocols to describe features that termcap wasn't designed to deal with, like sound, the ability to spawn new windows, a mouse interface… great! That's a good idea! But *trying* get the right terminal sequences is also a good idea. If you can't do it, then it's up to you if you want to risk assuming vt100 will work (and botching the screen), or saying "Sorry, your terminal can't do that.".


Ugh. Actually I am trying to use terminfo to do the reverse, to map key sequences for arrows, tab, etc. into internal symbols. I can dig up the terminfo capabilities and import them to my MUD no problem. However, the terminfo key sequences don't correspond to the key codes being sent!!! All my xterms (multiple clients, multiple OSes) send ESC

Ugh. Actually I am trying to use terminfo to do the reverse, to map key sequences for arrows, tab, etc. into internal symbols. I can dig up the terminfo capabilities and import them to my MUD no problem. However, the terminfo key sequences don't correspond to the key codes being sent!!! All my xterms (multiple clients, multiple OSes) send ESC[A for "up" keypresses, yet the terminfo for xterms lists kccu1 as "\EOA". This unfortunately means I need to check for multiple escape codes in the input parsing, and I don't really see a clean way to do this for multiple terminal types. Maybe quixadhal has advice here?[/quote]

\EOA is the usual sequence for up-arrow when the keypad is in "application mode", if I remember right.
http://www.braun-home.net/michael/info/m...

Because vt100 compatible terminals have that concept of a "normal" and "application" mode, you either have to set the terminal to the mode you want to use, or find the termcap/terminfo sequences for both modes. Curses does this for you, but.. you can't always use curses :(
06 Jan, 2013, Scandum wrote in the 39th comment:
Votes: 0
KaVir said:
Scandum said:
So for all intense and purposes I think it's safe to ignore cycling as nobody uses Windows Telnet, except for the occasional troll.

A few of my active players use Windows Telnet while playing from work or school, as it's their only option. I used donky's approach for identifying Windows Telnet prior to negotiation, but if you can't be bothered to do that there's also the workaround I used in my protocol snippet: if the first terminal type is "ANSI", don't cycle.

I think 3 TTYPE requests are fine, it's 4 causing trouble. I'm not 100% certain of this.

I think it's bad practice to lag 99% of your players to enable local echo for Windows Telnet. They can do so by pressing ctrl-] and typing 'set localecho'. Alternative detect Windows Telnet using NEW ENVIRON as done in MTH (http://www.mudbytes.net/index.php?a=file...) and handling echoing remotely.
06 Jan, 2013, quixadhal wrote in the 40th comment:
Votes: 0
Enabling local echo lags 99% of your players???

Are you running your mud on a Commodore 64? Or is your connection TCP/IP over carrier pigeon?
20.0/75