256 colours

[ideysus]

I asked this on intermud but I figure it may be worthwhile asking here too. Does anybody have xterm 256 colours set up? We have coded it but ended up making up our own pinkfish codes and obviously it isn't a great idea to have incompatible codes

If nobody else has any naming systems, I'm probably going to copy Qwer@Archipelago (http://users.ecs.soton.ac.uk/dgc/xterm-256color.png).

Their system is basically colours %^xRGB%^ (where each colour is 0 to 5) and %^GREY0%^ through to %^GREY23%^. B_ is prefixed for background.

I could dig up our terminal daemon if anybody is interested.

[quixadhal]

Funny you should ask that.... I have an ansi daemon for Gurbalib on DGD that supports XTERM 256 mode as well as 24-bit true-colour (partially).  Only drawback (and the reason it won't show up in Gurba anytime soon) is it's a bit of a cpu hog.

I used "XTERM:XX" where XX is a 2-digit hex number and "XTERMBACK:XX" for background colours.  It also supports "RGB:RRGGBB", and RGBBACK.  In either case, if you are in a lower mode, it remaps the colours down so they come out as the closest plain ANSI code match if you're in 16-colour mode instead.

Let me know if you're interested, I can send you the main files and you can pick them apart for useful tidbits if you like.

[ideysus]

Wow, I wasn't even aware of a 24 bit colour terminal. I am tending towards Qwer's system since its closer to what we have and its more terse. We try to degrade gracefully too (so, nearest ansi colour).

I should also note that we added an UNDERLINE. I'm not sure how much point there is adding other codes, they don't seem to be too widely supported.

I guess trying to standardise Pinkfish codes is missing the boat a little :-)

[wodan]

mxp does support the full 16 million colours, which is used on Discworld with

%^#RRGGBB%^ and %^B_#RRGGBB%^

The only other colour set we report is ansi, and we do convert the mxp colours for those as well.

Maybe I should move some of that in the driver.

btw zmp can do 24 bit colours as well, but you need to name your colours before using them which doesn't fit in the pinkfish colour scheme at all.

[quixadhal]

Here's what we did on Gurba... we extended Pinkfish codes to allow symbolic names, which in turn allows builders to not need to agree on which colour room titles need to be, while allowing them to hard-code it if there's a reason for it.  Thus, you use "%^ROOM_NAME%^", and all normal rooms get the same colour title, which for us happens to map to "%^GREEN%^", which will in turn be mapped to the appropriate output tokens (Nothing, ESC[32m, ESC[38;5;2m, or whatever the closest grey value is).

I don't have a full 24-bit terminal, and only put partial support for HTML output as an idea... it isn't quite useable though, as Pinkfish codes don't require a reset for every code... while HTMP span tags do.

A few screenshots....

Usage	XTERM 256	Greyscale	ANSI	Plain Text

ALSO, the usual method of doing explode() on '%' tokens is broken -- which you can demonstrate to yourself by trying to do "%^RED%^GREEN%^RESET%^" and seeing an empty string of escape codes, rather than the word "GREEN" in red, as intended.  I used parse_string() in DGD to match things surrounded by pairs of Pinkfish delimiters and do it right, even if it breaks lazy people who expect "%^RED%^BOLD%^" to work (It should be "%^RED%^%^BOLD%^").

It should also be noted that only about half this code is in the official Gurbalib, as the rgb conversion stuff is a bit CPU heavy, and I don't know if Aidil is willing to break lazy people's bad habits the way I am.

YMMV.

[wodan]

ALSO, the usual method of doing explode() on '%' tokens is broken -- which you can demonstrate to yourself by trying to do "%^RED%^GREEN%^RESET%^" and seeing an empty string of escape codes, rather than the word "GREEN" in red, as intended.  I used parse_string() in DGD to match things surrounded by pairs of Pinkfish delimiters and do it right, even if it breaks lazy people who expect "%^RED%^BOLD%^" to work (It should be "%^RED%^%^BOLD%^").

Well, that's your opinion, in reality the original (and current) terminal_colour efun doesn't agree with you, it gives you the empty string, and %^RED%^BOLD%^ should give you bold red text. I think this is even needed if you want the %%^^ sequence to work for displaying %^, it would mess up your in/out of colour tag accounting.

[quixadhal]

Well, that's your opinion, in reality the original (and current) terminal_colour efun doesn't agree with you, it gives you the empty string, and %^RED%^BOLD%^ should give you bold red text. I think this is even needed if you want the %%^^ sequence to work for displaying %^, it would mess up your in/out of colour tag accounting.

I accept that the LP community has grown as accustomed to this as the Diku community has to using "\n\r" for line endings, because "That's how it's always been done."  I happen to think they are both equally wrong, even if there is no official RFC for Pinkfish codes.

My reasoning is simply that this system appears to use %^...%^ as a tag pair which encapsulates the desired function.  In my prior example, how does one go about making the word "GREEN" show up in red, under the current system -- without adding spaces, or illegal tags to force processing to stop?  "%^RED%^BOLD%^GREEN%^RESET%^" won't do it.

My method may also be broken though... I haven't tried using %%^^ as an escaped version of the delimiter.  If my mud testbed survived our power outage, I'll see what happens.

[wodan]

There is indeed no way to display GREEN in a different colour than text connected to it, usually you'll want a space on at least one side though, so that's not really a problem.

[hamlet]

Although you could always include a non-printing character as well.

%^RED%^GREEN^G%^RESET%^

for instance.

[Nulvect]

Well, that's your opinion, in reality the original (and current) terminal_colour efun doesn't agree with you, it gives you the empty string, and %^RED%^BOLD%^ should give you bold red text. I think this is even needed if you want the %%^^ sequence to work for displaying %^, it would mess up your in/out of colour tag accounting.

I accept that the LP community has grown as accustomed to this as the Diku community has to using "\n\r" for line endings, because "That's how it's always been done."  I happen to think they are both equally wrong, even if there is no official RFC for Pinkfish codes.

My reasoning is simply that this system appears to use %^...%^ as a tag pair which encapsulates the desired function.  In my prior example, how does one go about making the word "GREEN" show up in red, under the current system -- without adding spaces, or illegal tags to force processing to stop?  "%^RED%^BOLD%^GREEN%^RESET%^" won't do it.

My method may also be broken though... I haven't tried using %%^^ as an escaped version of the delimiter.  If my mud testbed survived our power outage, I'll see what happens.

I agree 100% with Quixadhal on this. If all you ever need to do is remove color codes then doing %^BOLD%^RED%^ will work, but if you need to actually parse them in any way it needs to be more strictly defined. I discovered this when writing a map function for my mud - I needed to know what colors were active at certain points in the room description string so I could break it up and start each new line with the correct colors. Aside from that, it just feels like laziness to even allow such a loose format - especially if it has known display problems like being unable to output any string equal to a color code string.

[chaos]

This is why I've always ignored Pinkfish color and used my own format, {{color}text}.  Has its own issues, but being unable to produce the word green in red isn't one of them.  (Nor is the inability to embed a colorized string inside another colorized string without everything crapping out.)

[wodan]

It doesn't really matter if you agree or not, you're over a decade late!

btw you could still do %^RED%^GRE%^EN%^RESET%^

to get GREEN in red if you really need it somewhere.

[quixadhal]

It doesn't really matter if you agree or not, you're over a decade late!

btw you could still do %^RED%^GRE%^EN%^RESET%^

to get GREEN in red if you really need it somewhere.

The problem I have with THAT, is that it doesn't allow you to catch invalid code sequences (IE: typos).

I'd rather have my builders see "You want to pick the juicy %^RRD%^APPLE!", and realize they made a typo than have it show up as "juicy RRDAPPLE!", where the error isn't obvious... especially if the colour codes were added by some other part of the system (IE: maybe someone wants to have all extra description keyword matches in the main description stand out).

I realize that the "standard" is already in place, although I would suggest that refusing to update a standard to address known flaws is dooming it to a slow death as people make up their own and stop using it.  Another aspect of this is that fact that half the people I've interacted with about this don't know WHY %^ORANGE%^ isn't orange... it's a relic from the days of actual EGA cards doing ANSI terminal emulation, where non-bold yellow was a muddy orange shade, and "bold yellow" was actually yellow.  Yet, skip ahead 10 years, and nobody will ever use the "ORANGE" code, because it isn't orange.

It's a pity, really, because the idea behind these codes is good, and the delimiters chosen make it both flexible and unlikely to happen accidentally.  Is there an actual write up of the Pinkfish system's definition anywhere?  I've used them for years, but never knew about %%^^ being an escape sequence, and after you mentioned it last time, I couldn't find a document about it.  I'll probably not follow it 100%, for the reasons I've listed above, but I'd like to get as close as I can anyways!

EDIT: It's not so much for GREEN, as it is not having to worry if a given symbol is going to screw up.  I've extended the system to use symbolic names so that builders can define things be coloured according to purpose, rather than the exact colour they think it should be.  %^EXIT%^ would be perfectly valid, and would be remapped to %^CYAN%^, and then the subsequent escape sequence for their terminal and mode.  Lacking that stricter definition means there's no way to know if a given sequence might break later... I might be fine with "The %^RED%^STOP%^RESET%^ sign!" today, but if someone later makes a "STOP" symbolic name, it will break.

[Raudhrskal]

... and most of these problems could be avoided if the original spec would go paired and use %^ ^% ...

I have to say, Chaos' {{red}content{{blue}text}still red} is very cool. Yes, it requires a complex backend. BUT, it's safe, can be safely expanded, and has four characters of overhead, just like %^%^. It just needs (and probably has) an escape sequence for the opening brace. {{{ ?

There's another problem: Intermud. You don't send ANSI escapes, you send PF codes that are expanded by receiving mud. So, any kind of extended PF codes and alternative markup has to be converted into the old safe group of eight colors * bold * B_ by mud's i3 client.

[wodan]

I'm not going to change anything for backwards compatibility reasons, however connecting the %^ sequences to just one colour code is backwards compatible in nearly all cases (only not when the text matches a color code), so I don't see any problem with promoting pf codes 2.0 where that's an actual requirement , patches for a driver compile option that would do that are welcome!