30 Oct, 2013, dbna2 wrote in the 1st comment:
Votes: 0
I was wondering if anyone had a good helpfile for the xterm colors… Or maybe a website to show the right color codes?
30 Oct, 2013, KaVir wrote in the 2nd comment:
Votes: 0
Which snippet? Does it not include documentation about using the xterm colours?
30 Oct, 2013, dbna2 wrote in the 3rd comment:
Votes: 0
yes but it doesn't include a helpfile, or a list of the color codes
30 Oct, 2013, Nathan wrote in the 4th comment:
Votes: 0
30 Oct, 2013, Hades_Kane wrote in the 5th comment:
Votes: 0
dbna2 said:
yes but it doesn't include a helpfile, or a list of the color codes


In order for us to properly help you, the name of or a link to the snippet in question would help a lot.
30 Oct, 2013, plamzi wrote in the 6th comment:
Votes: 0
dbna2 said:
yes but it doesn't include a helpfile, or a list of the color codes


Look at the comments inside protocol.h, and experiment. This snippet is very well-documented by enthusiast standards, but some figuring out is always going to be in order:

/* Function: ColourRGB
*
* Returns a colour as an escape code, based on the RGB value provided. The
* string must be four characters, where the first is either 'f' for foreground
* or 'b' for background (case insensitive), and the other three characters are
* numeric digits in the range 0 to 5, representing red, green and blue.
*
* For example "F500" returns a red foreground, "B530" an orange background,
* and so on. An invalid colour will clear whatever you've set previously.
*
* If the user doesn't support XTerm 256 colours, this function will return the
* best-fit ANSI colour instead.
*
* If you wish to embed colours in strings, use ProtocolOutput().
*/
const char *ColourRGB( descriptor_t *apDescriptor, const char *apRGB );
30 Oct, 2013, KaVir wrote in the 7th comment:
Votes: 0
If he's talking about my snippet, there's also a README.TXT which includes the following:

/******************************************************************************
How do I use extended colour?
******************************************************************************/

The special character used to indicate the start of a colour sequence is '\t'
(i.e., a tab, or ASCII character 9). This makes it easy to include in help
files (as you can literally press the tab key) as well as strings (where you
can use "\t" instead). However players can't send tabs (on most muds at
least), so this stops them from sending colour codes to each other.

The predefined colours are:

n: no colour (switches colour off)

r: dark red R: light red
g: dark green G: light green
b: dark blue B: light blue
y: dark yellow Y: light yellow
m: dark magenta M: light magenta
c: dark cyan C: light cyan
w: dark white W: light white

a: dark azure A: light azure
j: dark jade J: light jade
l: dark lime L: light lime
o: dark orange O: light orange
p: dark pink P: light pink
t: dark tan T: light tan
v: dark violet V: light violet

So for example "This is \tOorange\tn." will colour the word "orange". You can
add more colours by updating the switch statement in ProtocolOutput(), and if
you're using your own colour code, it can use extended colours in the same way.

It's also possible to explicitly specify an RGB value, by including a four
character colour sequence within square brackets, eg:

This is a \t[F010]very dark green foreground\tn.

Or:

This is a \t[B210]dark brown background\tn.

The first character is either 'F' for foreground or 'B' for background. The
next three characters are the RGB (red/green/blue) values, each of which must
be a digit in the range 0 (very dark) to 5 (very light).

Finally, it's also possible to retrieve the colour code directly by calling the
ColourRGB() function. This uses a static buffer, so make sure you copy the
result after each call, don't do a sprintf() with multiple ColourRGB() calls.

Note that sending extended colours to a terminal that doesn't support them can
have some very strange results. The snippet therefore automatically downgrades
to the best-fit ANSI colour for users that don't support extended colours.

Because there is no official way to detect support for extended colours, the
snippet tries to work it out indirectly, erring on the side of caution. If the
b256Support variable in the protocol structure is set to "eSOMETIMES", that
means some versions of this client are known to support extended colour - you
will need to ask the user, and then set eMSDP_XTERM_256_COLORS to 1 (or they
can do this themselves through MSDP/ATCP).

/******************************************************************************
My players can't send tab characters, how can they use colour?
******************************************************************************/

If you wish to let your players use colour codes, uncomment COLOUR_CHAR in
protocol.h. This will allow people to use ^r for dark red, ^B for light blue,
and so on, using the same predefined colours as described above. You can also
change COLOUR_CHAR to a different character if you prefer.

Colours can be disabled with "\t-" and enabled with "\t+", so (for example) if
you don't want players to add colour to their chats, add "\t-" to the front of
their message. This needs to be done each time a string is sent. If you want
colours disabled by default, set COLOUR_ON_BY_DEFAULT (in protocol.h) to false.

Should you wish to let players use the extended colour codes as well, uncomment
EXTENDED_COLOUR. This will allow people to send codes like ^[F135] or ^[B332].

You may also uncomment DISPLAY_INVALID_COLOUR_CODES if you wish invalid codes
to be displayed rather than hidden.
0.0/7