[MUD-Dev] Attracting players

[Scatter]

Laurel Fan <lf25+ at andrew.cmu.edu> wrote
>Matthew Mihaly at best.com wrote:
>> Hmm, I wasn't aware it was possible for a server to determine if a
>> player's client can decode colour. How is this done?

I do it through telnet protocol since that's the method to
connect to my mud. Telnet protocol supports a number of 
sub-option negotiations, one of which is terminal type
(RFC 1091 I think).

Basically, the server requests terminal type negotiation and
the client responds with its primary terminal emulation - e.g.
"VT100" - if the server is not happy with that, it asks again
and the client reponds with another type that it supports -
e.g. "VT220" and so forth. Eventually either the server gets
the option it wants "ansi" usually, where colour is concerned,
or it receives the same option twice from the client. When the
latter occurs it means the client has run out of options. If
the server continues to ask, the client will start its list again,
allowing the server to pick a "second best" choice from the list.

I know far more than I ever wanted to about this because MudOS
always blindly accepts the first terminal type offered, so in
order to actively negotiate ansi for our colour login screen
I had to hand-crank the process. My login sequence tries to negotiate
"ansi" and if that fails, tries for "vt100" and if that fails it
will use the clients primary emulation.

>If there is a way to this automatically, someone's probably going 
>to write a client that doesn't support it.  You could ask them 
>before the login screen (obviously, the question is not in color), 
>like some diku derivative codebase (smaug? circle?) does.

Yes, there are cases where the client doesn't support the
telnet negotiation. For example GMud is a common mud client
that doesn't do terminal type negotiation at all. In this case
my login process waits for a specified period (a 5 second delay)
and if no answering negotiation has occurred, it defaults to
a specified type.

Theoretically we should default to "dumb" (i.e. straight
7-bit ASCII) when negotiation fails completely. After all
you don't know whether the client can understand the escape
codes, so in theory you shouldn't send them. However, I
default to "ansi" when no negotiation occurs for the
following reasons:

1) I've never encountered a true telnet client that won't
   do terminal type negotiation. Hell, even the braindead telnet
   that ships with Win95 will negotiate correctly. In my experience
   it is exclusively mud clients that don't tend to support 
   negotiation.

2) Many mud clients that don't support terminal type negotiation
   do support ansi colour.

Hence the reasoning goes that if no negotiation occurs, the
client is almost certainly a mud client rather than a telnet
program, and is therefore likely to support ansi colour.

The login screen is colour only if:
  - the server successfully negotiated "ansi"
  - the client didn't negotiate so the server defaulted to "ansi"

All other circumstances get a plain text login screen.

So far this scheme seems to work fine and keep everyone happy.
The only problem encountered is with ZMud, this client seems
to be broken and always negotiates "vt100" even when specifically
set to "ansi" - this means ZMud users always get plain text even
though the client supports ansi colour. Those of our users who
use ZMud get around it using an option to turn off telnet
protocol, which makes the server default to ansi.

--
Scatter ///\oo/\\\



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev