25 Aug, 2010, Rudha wrote in the 21st comment:
Votes: 0
Scandum said:
The way my 256 color snippet works 256 color tags can be translated into either 256 color codes or 16 color codes. So all a player would need is some config option to switch between 1 color, 16 colors, and 256 colors.

Automatic detection would be nice. One idea I have is for clients to report a special MUD TTYPE, so TinTin++ for example would send TINTIN++, followed by XTERM (if that was the terminal emulator used), followed by MTTS 1734012. MTTS would stand for Mud TTYPE Standard, and the number would be a bitvector, and the MUDs could check the bitvector for 256 color support.

Biggest downside is that MUDs would have to cycle through the terminal types, biggest advantage is that it's fairly easy to add for clients.


If more MUD and clients supported MSDP, you could just enable/disable the 256 colour based on the clients response to a challenge for XTERM 256 COLOR. This is probably what I'll do regardless - autodetect and enable it if you're using TinTin++ with our scripts or one of your own - or alternatively, enable it manually by a configuration option if you know your client supports it. I may be able to do some autodetection from the TERMTYPE TELOPT - I haven't yet researched if this gives us something meaningful enough to be able to autodetect colour support.

Quix's suggestion, which is a different implementation of David's suggestion earlier, is a good one: on the imput end have something like {blue} or something, and then it translates it according to a table for 256 XTERM or 16 ANSI as appropriate. Or just strip it entirely if the user has colour disabled.

Maya/Rudha
25 Aug, 2010, KaVir wrote in the 22nd comment:
Votes: 0
Scandum said:
So all a player would need is some config option to switch between 1 color, 16 colors, and 256 colors.

…and 16777216 colours. Might as well include that in the same config option.

Scandum said:
Automatic detection would be nice.

It would, but I think it's too late in the day to get sweeping support, so you're probably still going to need the config option. You could have a fifth config value though - "autodetect" - and make it the default for the colour config option. That way people with older clients wouldn't be blocked outright from using more colours.

Rudha said:
If more MUD and clients supported MSDP, you could just enable/disable the 256 colour based on the clients response to a challenge for XTERM 256 COLOR.

I don't know of any clients that natively support MSDP - Zugg has stated outright that he won't add it to CMUD, zMUD is no longer maintained, Mudlet only supports 102 and ATCP/2, etc…even TinTin++ requires a script. And if players have to add your custom script anyway, you could just have it automatically send a subnegotiation sequence to toggle the appropriate option on the mud.
25 Aug, 2010, Rudha wrote in the 23rd comment:
Votes: 0
Yeah, its a bit of wishful thinking, that if, but if I'm going to write a script to more of less fully implement MSDP on both ends I may as well use what's already there instead of reinventing the wheel.

Does ATCP/2 even have anything to that end? I don't remember anything of that regards, but I haven't delved too deep into the arcane 'standard' packages.

Maya/Rudha

[edit]: It would be nice for TinTin++ to at least have a dummy MSDP support available out of the box that you could turn on/off with some sort of #CONFIG switch. It wouldn't be hard to just go IAC SB MSDP \x01 LIST \x02 VARIABLES IAC SE (or whatever the appropriate subnegotiation is, thats just offhand) and then populate variables in memory from that, if they've enabled it with say, #CONFIG MSDP ON or something. I realise its a little late at this point for that kind of thing, but it would be nice.
25 Aug, 2010, David Haley wrote in the 24th comment:
Votes: 0
Quote
Zugg has stated outright that he won't add it to CMUD

Did he say why, by any chance?
25 Aug, 2010, KaVir wrote in the 25th comment:
Votes: 0
Rudha said:
It would be nice for TinTin++ to at least have a dummy MSDP support available out of the box that you could turn on/off with some sort of #CONFIG switch.

The idea has already been discussed and rejected.

My information about CMUD came from Lasher, who said "I did ask Zugg about implementing MSDP, it was a very definite "no"".
25 Aug, 2010, Rudha wrote in the 26th comment:
Votes: 0
Ehh, I could implement it myself, TT++ being open source and all, the real question is the more important one, and that's: is it worth it? I'm … hesitantly bordering on no, upon further reflection. It would make things easier for people playing with MSDP, but that's .. not very many people at all, and the real thing is that the people who -are- playing with it know enough of what they're doing that it probably wouldn't need that anyways.

Still - it would be nice :P

Anyways - I actually, really like this idea of tagging the more I think of it. It occurs to me I could also translate those tags to MXP where the socket is using it as well if I wanted to. I think Im definitely going to implement something like that.

Maya/Rudha
25 Aug, 2010, David Haley wrote in the 27th comment:
Votes: 0
Yes; in fact, having semantic categories is more powerful than merely colors. You can send that information along to the client, if you wish, with some form of markup, so that the client can decide if it wants to do anything else.

For instance, you have the string:
<mob>There is a goblin here.</mob>
which, after getting color code translation, will get sent as:
<green>There is a goblin here.</green>
but you could also send it as:
<green><mob>There is a goblin here.</mob></green>
so that clients know that not only is that text green, but it represents a mob – and the client could then choose to stuff it into some separate window (or whatever).

Of course, this assumes that everybody knows how to exchange this semantic information using some kind of protocol, but the point is that if you have server-side category (i.e., semantic) information, you have much richer data that you can send to clients capable of using it. If all you have are color codes, you lose that ability (or at least only have it on a much coarser level).
25 Aug, 2010, Rudha wrote in the 28th comment:
Votes: 0
It's easy enough to determine if the user has enabled MXP and if so send it in MXP markup. I'm not really aware if there's related markup, unless we're counting extended ASCII, which is to MXP what oranges are termites. Which is to say its not really related at all.

Maya/Rudha
25 Aug, 2010, David Haley wrote in the 29th comment:
Votes: 0
You could use any number of protocols here (MSDP, MXP, ATCP/2, 102, 100, plain-text markup, …); the point was just that having category data available in your text can be about more than colors.
25 Aug, 2010, Rudha wrote in the 30th comment:
Votes: 0
When I said I wasn't aware of a similar markup, it was meant more as in to say "I don't think this has really been done before, except maybe MXP" Sorry if I was unclear.

Maya/Rudha
25 Aug, 2010, Scandum wrote in the 31st comment:
Votes: 0
I assume other clients will implement MSDP once enough MUDs implement it.

Keep in mind you can't use MSDP or ATCP for color tags alone, you'd have to include the text as well, so that could look somewhat like: $markup = { $color = blue $text = You've got the blues. }

Regarding 256 color detection, as TinTin++ is a console client the terminal emulator needs to support 256 colors for it to work. On the first TTYPE request tt++ will respond with TINTIN++, and on the second request it'll report its terminal type. XTERM is pretty much guaranteed to have 256 color support unless someone runs a version older than 10 years. I don't know of an up to date list of which terminals support 256 color or not, RXVT added 256 color support recently, and I'm quite sure other terminals will follow suit.

I'll probably finish the MTTS specification sometime and start a RFC as it'll be useful to detect passive protocols like 256 colors, 16 colors, VT100, MSSP, MSDP, xterm mouse support, and a couple of others.
26 Aug, 2010, Rudha wrote in the 32nd comment:
Votes: 0
Scandum said:
On the first TTYPE request tt++ will respond with TINTIN++, and on the second request it'll report its terminal type.


So I have to negotiate TERMINAL_TYPE twice to get the meaningful response in that case. That's good to know.

Maya/Rudha
20.0/32