15 Mar, 2011, Scandum wrote in the 101st comment:

Votes: 0

KaVir said:

I thought the font was a property? Or is that just WinTin++? Or do you mean there's an "unknown" default which could be overwritten by explicitly configuring a font?

TinTin++ doesn't do terminal handling, which is the main reason tt++ doesn't support MXP. There's also no way to know if the font has been installed. Guess I could create a standard for terminals to communicate to the shell and try to get it adopted by terminal developers.

KaVir said:

Well some clients are adding native support for MSDP, and personally I think that'll make it easier to use - my psuedo-ATCP implementation (i.e., MSDP treated as if it were a custom ATCP package) has proven far easier to use than my MSDP plugin, simply because Mudlet automatically stores the variables and raises an event.

TinTin++ raises MSDP events and makes it very easy to store the variables. TinTin++ won't listen for specific variables and automatically respond to them however.

KaVir said:

However the CONFIGURABLE_VARIABLES take it beyond "nice to have". As far as I'm aware, MSDP is the only protocol that explicitly describes a mechanism for the client to indicate XTerm 256 color support - and one client developer has already expressed an interest in using it precisely for that purpose. There are other CONFIGURABLE_VARIABLES that are also useful - UTF-8 for example, for reasons I've outlined here. Or CLIENT_VERSION, as the only other way I know to reliably obtain that information is through MXP, which many clients don't or won't support.

I'd rather set up a terminal type standard to handle this, I'll work some stuff out tomorrow and create a topic for it. The advantage is that it'd be cleaner and much easier to implement.

KaVir said:

But the UTF-8 thing is a separate issue. The only reason I mention it here is because of the CONFIGURABLE_VARIABLES - which in my opinion should be handled natively by the client. If the server can identify that the client supports UTF-8, then it can automatically display nicer maps, use line draw characters, etc. The user shouldn't need to write a script for that, any more than they should have to write a script to indicate VT100 or ANSI colour support (those are also CONFIGURABLE_VARIABLES). Nor should the user have to explicitly write a script to report their CLIENT_VERSION.

Would it matter as much to have the client version if you had all the other information?

KaVir said:

It actually reports just "xterm" on the second request. But in combination with the "TinTin++" from the first request I can at least now identify WinTin++. It aint pretty, but it works.

Are you using version 2.00.6 (released 4 days ago) or an older version? When TinTin++ reports xterm (not necessarily means it's WinTin++) it's fairly safe to assume it has 256 color support, unless the build is older than 10 years.

16 Mar, 2011, KaVir wrote in the 102nd comment:

Votes: 0

Scandum said:

I'd rather set up a terminal type standard to handle this, I'll work some stuff out tomorrow and create a topic for it. The advantage is that it'd be cleaner and much easier to implement.

Well the MSDP solution is already implemented in my snippet as per the specification, and there are already a couple of client developers considering using it for activating certain options. But if you'd rather TinTin++ did it through some other protocol, and it's relatively straightforward to add, then I don't mind including it in my snippet as well.

Scandum said:

Would it matter as much to have the client version if you had all the other information?

No, I'd track it on the stats page but that's all.

Scandum said:

I downloaded the latest version but didn't install it properly, and didn't realise I already had an old copy of WinTin++ - so I was actually using 2.00.2. I've properly updated to 2.00.6 now and it does indeed report "xterm-256color".

But should I check for "xterm-256color", or for anything starting with "xterm", when assuming 256 colour support?

16 Mar, 2011, Scandum wrote in the 103rd comment:

Votes: 0

xterm added 256 colors in 1999, so it should be safe to assume anything reporting as such to support it.

I'll hi-jackack http://en.wikipedia.org/wiki/List_of_ter..., turn it into a Comparison of Terminal Emulators article, and let the Wiki crowd fill in the blanks.

16 Mar, 2011, David Haley wrote in the 104th comment:

Votes: 0

Scandum said:

xterm added 256 colors in 1999, so it should be safe to assume anything reporting as such to support it.

I've seen a few terminals that claim to be xterm but do not support 256 colors, or at least not the same way other terminals do. I've also seen terminals that make a distinction between xterm and xterm-color. So unfortunately, I don't think you can make the above assumption. :sigh:

16 Mar, 2011, KaVir wrote in the 105th comment:

Votes: 0

Scandum said:

xterm added 256 colors in 1999, so it should be safe to assume anything reporting as such to support it.

Only one of my players uses a client that identifies itself as XTERM-COLOR, and when I asked him to test the extended colours they didn't display properly - orange showed up as flashing red (the same as zMUD and old versions of CMUD).

If the client reports itself as "TinTin++" on the first query, and the second query starts with "xterm", then I automatically enable 256 colours. But anything that sends "xterm" on the first query will just use ANSI colours by default.

Random Picks

Crimson Gate

The Burning Eye

Rafermand