And Putty, the user can change its behaviour in many ways, to alter the fingerprint it shows a server. Including changing the answerback string from PuTTY to something else. Any procedure which tried to identify what client a player was using, would have to take this and other possibilities into account.

While it is not the common case, there are options which a server might want enabled in a client, yet it is unable to know whether it needs to tell the player to manually enable them or whether it can just go ahead and enable them remotely. A recent thread on unicode and mushclient is related to this, a mushclient player would most likely need to enable the option, whereas a Putty player could just have it remotely enabled with no switch in attention span.

Now, this is not the common case, but what I wonder is what possibilities this might open up if client identification is a known technique that is achievable. I tend to use the telnet client at hand, which is Windows Telnet. And Putty when I have to use something else. But as a server developer, I think there is too much that is unknown in the world of dealing with clients and I see possibilities for making these things known and improving the status quo.

Wrench tossing inc.

I'll put two questions to you. How do you feel about only installing your ASCII map after all of your areas are finalized and quality tested? Second question. How do you feel about only giving mapper to immortals? It can be a good tool for visualizing. Especially if you aren't the immortal working on the zone and you want to see it laid out.

One option is adding a row with client side TTYPE support (yes/no) to: http://en.wikipedia.org/wiki/Comparison_... next create a TTYPE article, and add to it a table with clients and the TTYPE(s) they report. That should at least put the information for an implementation out there.

At that point, it would come down to somebody else having to put in the wrench time to write the code. It's not a feature I care about or think adds a lot of value to the kind of game I would want to run or play. If another coder felt like adding it (post-QA, so to speak) I wouldn't object, but it's not a project I would dedicate what time I have, especially since there are always a hundred other things to work on.

As for visualization, I guess the best counter-argument I can come up with is "Meh". I've built a half dozen or so areas for MUDs before and I've never found it difficult to form a mental picture in my head even before I do the work. Builders should be mapping their areas on paper or digitally anyway. Toss in OLC such that you can walk around and I again chalk it up to a feature I just don't personally see as very useful.

I realize I probably sound like the grumpy old guy who refuses to buy a cell phone or ditch the rabbit ears antenna on his old ass TV, but the luxury of MUDs and the Internet is that I can do mine my way and just maybe a handful of people will come by and agreed with my taste.

I've been trying to google this sort of information, but being able to find a good reference to it on wikipedia is a great heads-up on it. However, given what I read about the nightmares people go through with wikipedia, I do not think I will spend any time trying to get my edits in there.

Can't blame you. I added a TTYPE row over here: http://www.mudpedia.org/wiki/Comparison_...

I guess it needs a row for clients that can use and negotiate character mode as well, though tt++ is the only one that I know of.

Is there a formal description of what one needs to do to enter character mode? The following seems to suggest that the server sending WILL ECHO is not enough. But it would be nice to have a clear description somewhere.

Mushclient is marked as supporting ECHO in that table, but does not support character mode.

Server needs to send IAC WILL SGA and IAC WILL ECHO (in other words, server offers to suppress go ahead (assumed enabled by default) and handle local echoing for the client), client needs to send IAC DO SGA and IAC DO ECHO - after that client side character mode is assumed to be enabled.

I think zMud has a character mode switch, but I don't think it enables it upon negotiation.

I'm always interested in collecting statistics, although I'm a bit wary of adding telnet negotiation to do it automatically, as a few of my players use pretty basic tel.... No reason why it couldn't be added as an optional command, though.

Having my server send a WILL or DO MXP to GMud did result in a junk character, but '
Having my server send a WILL or DO MXP to GMud did result in a junk character, but '[' rather than the 'Z' you note in your linked post. Now GMud does not respond to other basic options like WILL ECHO, DO NAWS and DO TTYPE, but it also does not display junk characters for these options.

The approach this suggests to me, is that if a client responds to negotiation attempts for basic options, then it might be assumed that the more problematic ones could then be attempted. And if a client does not respond to negotiation at all, then it is guaranteed to be a basic telnet client and further negotiation of otherwise problematic ones should not be taken.

Does this sound workable? Do you know the names of other basic telnet clients I can test this out on, if need be?

Edit: I should add if it matters, the version of GMud I found and used was 1.9b.

The windows telnet client of XP an later disables local echo when it receives any kind of telnet negotiation. I wouldn't worry about it as telnet is disabled as of Vista.

Barm's similar comment says something related, that you cannot reenable it. These are good things to know, regardless of the indirect way that Windows Telnet has to be accessed.

You can't, though it's possible to detect windows telnet and handle the echoing server side.

I do worry about it though - I have players who use windows telnet to play from school, and they're not able to install other clients or connect through FMud, so they've no other options.

If there's no way to negotiate without killing echo then one possibility might be to bind the mud to a second port, and only negotiate on clients that connect to the main port number.

Another possibility might be to negotiate after the player has connected, and add a config option for switching it off (they'd then have to open a new client to reconnect). But they'd probably end up leaving the option off, meaning I'd never get to see what client they used at home.

A third option could be to prompt the user every time they connect, although I dislike adding things like that, and it rather undermines the point of having automatic negotiation.

Perhaps the second and third options could be combined though - at the login screen where the user is given a list of options (create, load, who) there could be another command for switching off negotiation. Then when they create or load their character the negotiation could be performed, unless they'd previously chosen to switch it off.

Or the fourth, detect windows telnet and echo the input back to the user as they type.

I'd rather avoid character mode.

Another problem with Windows telnet client is that after cycling through terminal types one cannot get out of VTNT terminal. The RFC states the last TTYPE should be listed twice before cycling back to first TTYPE. It doesn't. Same or similar problems with SimpleMU.

Actually, I get out of it every time I use it, and my server enumerates all terminal types on client connection for all clients that connect.

When I read the RFC several days ago, my understanding of it was that some clients may not cycle and will list the last terminal type repeatedly, and some will cycle. But that the heuristic was that you should on seeing the same terminal type twice (assuming you have seen more than one different one) restart the terminal type negotiation process. This is what I do, and by doing so, I return successfully back to the first terminal type for any client that connects including Windows Telnet.