28 Jun, 2011, Rarva.Riendf wrote in the 41st comment:
Votes: 0
Quote
Sorry I must have confused you with someone else.
Rarva: "(I worked as a coder professionally for 9 years…Stock ROM code made me cry at how it was badly designed)"

Why don't you ask that chap to code this trivial function for you?

It is not because something is trivial that it is not annoying to code (especially string manipulation in C). And I did not asked anybody to code for me, I asked if anybody already coded it and wanting to share it.
But it seems like some people prefer to be smartass than to share code…
17 Aug, 2012, KaVir wrote in the 42nd comment:
Votes: 0
I've been updating my protocol snippet for another release, and one of the things I'd like to do is offer a better range of default colours - but I'm still trying to decide which ones to use. So far (mostly based on ideas from this thread) it's looking like:



Thoughts welcome.
17 Aug, 2012, Lyanic wrote in the 43rd comment:
Votes: 0
KaVir said:
I've been updating my protocol snippet for another release, and one of the things I'd like to do is offer a better range of default colours - but I'm still trying to decide which ones to use. So far (mostly based on ideas from this thread) it's looking like:



Thoughts welcome.

I don't feel like re-reading the thread for context, but those defaults are for downscaling to support clients without xterm-256? If not, what for? Also: no white or grey/black?
17 Aug, 2012, KaVir wrote in the 44th comment:
Votes: 0
Lyanic said:
I don't feel like re-reading the thread for context, but those defaults are for downscaling to support clients without xterm-256? If not, what for? Also: no white or grey/black?

The latest version of my snippet supports the option for Lopes-style colour, so you can have ^r (or @r, or &r, etc) for red, ^b (etc) for blue, and so on. But as the snippet supports extended colour, I'd like to offer more default colours than just the basic ANSI ones.

Of course you can still use RGB values, but I've noticed most people seem to ignore them and stick with the defaults. So I'm trying to offer some additional distinct colours that can be utilised as two-character codes.

Thus while you can still use ^b for blue, ^r for red, ^g for green, etc, you'd also be able to use ^v for violet, ^t for tan, ^o for orange, and so on.

I'm not removing any functionality, this feature is entirely optional, but I'm hoping it'll encourage mud owners to make use of additional colours by making it a natural progression from the basic ANSI colours.

The only difficulty is deciding which colours to provide as defaults. Not so fussed about the grey shades, although perhaps they might be useful too.
18 Aug, 2012, Lyanic wrote in the 45th comment:
Votes: 0
KaVir said:
Lyanic said:
I don't feel like re-reading the thread for context, but those defaults are for downscaling to support clients without xterm-256? If not, what for? Also: no white or grey/black?

The latest version of my snippet supports the option for Lopes-style colour, so you can have ^r (or @r, or &r, etc) for red, ^b (etc) for blue, and so on. But as the snippet supports extended colour, I'd like to offer more default colours than just the basic ANSI ones.

Of course you can still use RGB values, but I've noticed most people seem to ignore them and stick with the defaults. So I'm trying to offer some additional distinct colours that can be utilised as two-character codes.

Thus while you can still use ^b for blue, ^r for red, ^g for green, etc, you'd also be able to use ^v for violet, ^t for tan, ^o for orange, and so on.

I'm not removing any functionality, this feature is entirely optional, but I'm hoping it'll encourage mud owners to make use of additional colours by making it a natural progression from the basic ANSI colours.

The only difficulty is deciding which colours to provide as defaults. Not so fussed about the grey shades, although perhaps they might be useful too.

Ah, got it. If you remember, Arynth did the xterm-256 implementation that 7th Plane uses (along with the MSDP implementation) in parallel to the work you were doing on your snippet. We later went back and stripped out the other elements from your snippet (NAWS, MXP, MSP, etc) and borrowed a few ideas for tweaking our initial MSDP and xterm-256 implementations. The way our color codes are setup is that each of the 256 is named, and thus can be referenced by name instead of RGB value, but the names are of the form: red1, red2, …, pink1, pink2, …, grey1, grey2, …, etc. They can be a bit unwieldy to type and to remember which number is which color, so I wrote an admin utility that loops through them all and displays all the color names (displayed in the respective color code) in a table, ordered by RGB value left to right, top to bottom. Still, it might be nice to have shorter, unique names for some of my favorites…

I've also thought about MXP-ifying my table output so I can click the color I want and have the color code for it go to the cursor position of the input bar in my client (as opposed to being entered). Do you know if that's possible?
18 Aug, 2012, Runter wrote in the 46th comment:
Votes: 0
I prefer exposing these names: http://en.wikipedia.org/wiki/X11_color_n...

It's not all of the possible colors, but I find it to be a consistent standard for meaningful color names. It doesn't mean you couldn't continue naming colors like red1, red2, etc, but have a parallel naming convention.
18 Aug, 2012, Alathon wrote in the 47th comment:
Votes: 0
KaVir said:
I've been updating my protocol snippet for another release, and one of the things I'd like to do is offer a better range of default colours - but I'm still trying to decide which ones to use. So far (mostly based on ideas from this thread) it's looking like:

Thoughts welcome.


I think those are solid values. I'm not really able to match them up against the table there though.

I've basically done the same for JABB, where I've added support for (But not any specific colors yet) 256-color mode, where it also binds the extended colors to
a 'base' color for clients that don't support or want to turn off xterm-256. I'm not entirely convinced that allowing RGB values is desirable IMO; I think theres a lot of
value in a consistent color palette, whether that be the one you offer players in say/etc, or builders in descriptions of things.
18 Aug, 2012, KaVir wrote in the 48th comment:
Votes: 0
Lyanic said:
I've also thought about MXP-ifying my table output so I can click the color I want and have the color code for it go to the cursor position of the input bar in my client (as opposed to being entered). Do you know if that's possible?

You mean you click on an MXP link and instead of sending the response, it copies the text to your input window? I thought that was possible, but looking through the spec again I can't see it. Maybe I'm confusing it with something else.

Runter said:
I prefer exposing these names: http://en.wikipedia.org/wiki/X11_color_n...

You can already use those with MXP, but I'm trying to keep this as close as possible to the "normal" colour system most muds use. It's a familiarity thing.

Alathon said:
I think those are solid values. I'm not really able to match them up against the table there though.

That table is listing the actual escape code numbers for each colour. Mine is an RGB value (each digit in the range 0-5).

Alathon said:
I've basically done the same for JABB, where I've added support for (But not any specific colors yet) 256-color mode, where it also binds the extended colors to a 'base' color for clients that don't support or want to turn off xterm-256.

Yeah mine supports the 16-colour fallback option for other clients as well.

Alathon said:
I'm not entirely convinced that allowing RGB values is desirable IMO; I think theres a lot of value in a consistent color palette, whether that be the one you offer players in say/etc, or builders in descriptions of things.

I already offer both, but most people seem to stick with the default-style colour codes, and the previous version of my snippet only used light/dark orange from the extended colours. I thought mud owners would extend it themselves, but nobody seems to have done so, they just seem to use what's already defined.
18 Aug, 2012, Runter wrote in the 49th comment:
Votes: 0
Quote
You can already use those with MXP, but I'm trying to keep this as close as possible to the "normal" colour system most muds use. It's a familiarity thing.


You can keep the "familiar" settings while adding those definitions. MXP isn't well supported, there's no reason all players shouldn't have access to a sensible color scheme. Well, at least, I don't think familiarity is a good excuse. Considering the two systems don't compete at all.
18 Aug, 2012, Lyanic wrote in the 50th comment:
Votes: 0
KaVir said:
You mean you click on an MXP link and instead of sending the response, it copies the text to your input window? I thought that was possible, but looking through the spec again I can't see it. Maybe I'm confusing it with something else.

Yes, that is exactly what I mean. I can't seem to find a way to do it, either.

Runter said:
It doesn't mean you couldn't continue naming colors like red1, red2, etc, but have a parallel naming convention.

Right. I wouldn't dream of removing functionality. I already have up to 4 ways of addressing some colors. They're all just aliases (except the actual escape codes, though I don't think I actually use that method in practice ANYWHERE).
18 Aug, 2012, Vatiken wrote in the 51st comment:
Votes: 0
Quote
<SEND> to command line
To send text to the client's command line instead of sending it directly to the MUD, use the PROMPT argument in the <SEND> tag.
Example: <SEND "tell Zugg " PROMPT>Zugg</SEND>
will put the text "tell Zugg " (without the quotes) into the command line when the "Zugg" link is clicked.

It's probably the most under-rated functionality associated with MXP, as it is incredibly handy for designing a point and click OLC. However, as far as I know it's only supported by zMUD, cMUD?, and Mushclient. I've inquired to the Mudlet guys but I didn't get any support for it.

With regards to the colour code functionality of KaVir's protocol snippet, I included within tbaMUD the additions of:
a: Azure
p: Pink
+: Bold
-: Blinking
_: Underline
=: Reverse
1,2,3: MUD Primary Colours

I was going to add brown as well, but being that B, R, O, W, N are already associated with other colours, I just bypassed it to avoid confusion. I figured that the snippet was clear and simple enough that people could make the associations they liked without me dictating it.
18 Aug, 2012, quixadhal wrote in the 52nd comment:
Votes: 0
In my own xterm256 system, I define each color in terms of the 24-bit RGB value it would be (as defined by X11's config file, or by what the xterm developers used), and wrap that into the proper escape sequence for the terminal type selected. If you're using a terminal with lower color resolution, I use a formula to find the closest color match in the more limited palette. Since there aren't that many X11 color names, it's not hard to pre-generate the table and avoid doing any calculation at runtime (for named colors).

Because the xterm256 palette has 24 shades of grey (and 232 color values), it works out rather nicely that if you use "greyscale" as a terminal type, you can remap the full 24-bit color palette to a reasonable greyscale palette, which I imagine is useful for folks who are color blind, or who feel like playing a DBZ mud. *grin*

In my case, I'm using the Pinkfish style of tokens, which are easy to extend… so %^GhostWhite%^ (defined as 248,248,255) would downscale to \033In my own xterm256 system, I define each color in terms of the 24-bit RGB value it would be (as defined by X11's config file, or by what the xterm developers used), and wrap that into the proper escape sequence for the terminal type selected. If you're using a terminal with lower color resolution, I use a formula to find the closest color match in the more limited palette. Since there aren't that many X11 color names, it's not hard to pre-generate the table and avoid doing any calculation at runtime (for named colors).

Because the xterm256 palette has 24 shades of grey (and 232 color values), it works out rather nicely that if you use "greyscale" as a terminal type, you can remap the full 24-bit color palette to a reasonable greyscale palette, which I imagine is useful for folks who are color blind, or who feel like playing a DBZ mud. *grin*

In my case, I'm using the Pinkfish style of tokens, which are easy to extend… so %^GhostWhite%^ (defined as 248,248,255) would downscale to \033[1;37m in plain ANSI, \033[38;5;15m in XTERM256, \033[38;5;255m in Greyscale xterm256, ~W in IMC2, or %^BOLD%^%^WHITE%^ in "traditional" Pinkfish for I3. I assume MXP would be <COLOR FORE="#f8f8ff">?

When I worked on Smaug's color code, years ago, I added support for tokens like &[color-name], which is still there in the code. So, that might be a reasonable way to add extended names for Lopes and whatever other two-character systems are still popular out there.

My actual intent (in both cases) was to allow symbolic names for the builders, like %^ROOM_DESC%^, which would then get mapped through user-prefs or a default to an actual color %^GREY%^, and then finally mapped to the escape sequences for your actual terminal.
18 Dec, 2012, Hades_Kane wrote in the 53rd comment:
Votes: 0
So I ran through the thread and didn't see one….

But does anyhow have a color chart compatible with KaVir's version of the 256 colors? I have someone asking for one and have been searching.
18 Dec, 2012, Ssolvarain wrote in the 54th comment:
Votes: 0
Yeah, gimme my color codes!
18 Dec, 2012, Kober wrote in the 55th comment:
Votes: 0
A command like this should work.
void do_colorlist(CHAR DATA *ch, char argument)
{
int k, r, g, b;
char buf[MAX_STRING_LENGTH], colour[MAX_STRING_LENGTH];

send_to_char("Colours\r\n————————–\r\n", ch);
k = 0;
for (r = 0; r < 6; r++)
{
for (g = 0; g < 6; g++)
{
for (b = 0; b < 6; b++)
{
sprintf(colour, "F%d%d%d", r, g, b);
snprintf(buf, MAX_STRING_LENGTH, "%s%s%s", ColourRGB(ch->desc, colour), colour, ++k % 6 == 0 ? "\tn\r\n" : " ");
page_to_char(buf, ch);
}
}
}
return;
}
18 Dec, 2012, Scandum wrote in the 56th comment:
Votes: 0
Lyanic said:
Also: no white or grey/black?

My color snippet defines 'e' for ebony (black) and 's' for silver (grey). The other letter codes are the same as KaVir's. The main difference is that I use A to F for RGB colors opposed to 0 to 5.

http://www.mudbytes.net/file-2596
18 Dec, 2012, Hades_Kane wrote in the 57th comment:
Votes: 0
Kober said:
A command like this should work.


Works great, thanks a ton!
18 Dec, 2012, Ssolvarain wrote in the 58th comment:
Votes: 0
Hades_Kane said:
Kober said:
A command like this should work.


Works great, thanks a ton!


Yeah, what he said :3
10 Feb, 2013, Telgar wrote in the 59th comment:
Votes: 0
I just added support for this, but I found it a lot easier to address the down-conversion with a simple multi-dimensional array rather than a flat array. Sample Javascript code

// Many thanks to Igor van den Hoven for the following excellent map,
// which has been converted back into text strings and encoded as a
// multi-dimensional Javascript array.
const rgb_map = [
[
[ "BLACK", "BLUE", "BLUE", "BLUE", "BRBLUE", "BRBLUE" ],
[ "GREEN", "CYAN", "CYAN", "BLUE", "BRBLUE", "BRBLUE" ],
[ "GREEN", "CYAN", "CYAN", "CYAN", "BRBLUE", "BRBLUE" ],
[ "GREEN", "GREEN", "CYAN", "CYAN", "CYAN", "BRCYAN" ],
[ "BRGREEN", "BRGREEN", "BRGREEN", "CYAN", "BRCYAN", "BRCYAN" ],
[ "BRGREEN", "BRGREEN", "BRGREEN", "BRCYAN", "BRCYAN", "BRCYAN" ]
],
[
[ "RED", "MAGENTA", "MAGENTA", "BLUE", "BRBLUE", "BRBLUE" ],
[ "YELLOW", "GRAY", "BLUE", "BLUE", "BRBLUE", "BRBLUE" ],
[ "YELLOW", "GREEN", "CYAN", "CYAN", "BRBLUE", "BRBLUE" ],
[ "GREEN", "GREEN", "CYAN", "CYAN", "CYAN", "BRCYAN" ],
[ "BRGREEN", "BRGREEN", "BRGREEN", "CYAN", "BRCYAN", "BRCYAN" ],
[ "BRGREEN", "BRGREEN", "BRGREEN", "BRCYAN", "BRCYAN", "BRCYAN" ]
],
[
[ "RED", "MAGENTA", "MAGENTA", "MAGENTA", "BRBLUE", "BRBLUE" ],
[ "YELLOW", "RED", "MAGENTA", "MAGENTA", "BRBLUE", "BRBLUE" ],
[ "YELLOW", "YELLOW", "WHITE", "BLUE", "BRBLUE", "BRBLUE" ],
[ "YELLOW", "YELLOW", "GREEN", "CYAN", "CYAN", "BRBLUE" ],
[ "BRGREEN", "BRGREEN", "BRGREEN", "CYAN", "BRCYAN", "BRCYAN" ],
[ "BRGREEN", "BRGREEN", "BRGREEN", "BRGREEN", "BRCYAN", "BRCYAN" ]
],
[
[ "RED", "RED", "MAGENTA", "MAGENTA", "MAGENTA", "BRMAGENTA" ],
[ "RED", "RED", "MAGENTA", "MAGENTA", "MAGENTA", "BRMAGENTA" ],
[ "YELLOW", "YELLOW", "RED", "MAGENTA", "MAGENTA", "BRBLUE" ],
[ "YELLOW", "YELLOW", "YELLOW", "WHITE", "BRBLUE", "BRBLUE" ],
[ "YELLOW", "YELLOW", "YELLOW", "BRGREEN", "BRCYAN", "BRCYAN" ],
[ "BRYELLOW", "BRYELLOW", "BRGREEN", "BRGREEN", "BRCYAN", "BRCYAN" ]
],
[
[ "BRRED", "BRRED", "BRRED", "MAGENTA", "BRMAGENTA", "BRMAGENTA" ],
[ "BRRED", "BRRED", "BRRED", "MAGENTA", "BRMAGENTA", "BRMAGENTA" ],
[ "BRRED", "BRRED", "BRRED", "MAGENTA", "BRMAGENTA", "BRMAGENTA" ],
[ "YELLOW", "YELLOW", "YELLOW", "BRRED", "BRMAGENTA", "BRMAGENTA" ],
[ "BRYELLOW", "BRYELLOW", "BRYELLOW", "BRYELLOW", "BRWHITE", "BRWHITE" ],
[ "BRYELLOW", "BRYELLOW", "BRYELLOW", "BRYELLOW", "BRWHITE", "BRWHITE" ]
],
[
[ "BRRED", "BRRED", "BRRED", "BRMAGENTA", "BRMAGENTA", "BRMAGENTA" ],
[ "BRRED", "BRRED", "BRRED", "BRMAGENTA", "BRMAGENTA", "BRMAGENTA" ],
[ "BRRED", "BRRED", "BRRED", "BRRED", "BRMAGENTA", "BRMAGENTA" ],
[ "BRYELLOW", "BRYELLOW", "BRRED", "BRRED", "BRMAGENTA", "BRMAGENTA" ],
[ "BRYELLOW", "BRYELLOW", "BRYELLOW", "BRYELLOW", "BRWHITE", "BRWHITE" ],
[ "BRYELLOW", "BRYELLOW", "BRYELLOW", "BRYELLOW", "BRWHITE", "BRWHITE" ]
]
];

const greyscale = [
"GRAY", "GRAY", "GRAY", "GRAY", "GRAY", "GRAY",
"GRAY", "GRAY", "GRAY", "GRAY", "GRAY", "GRAY",
"WHITE", "WHITE", "WHITE", "WHITE", "WHITE", "WHITE",
"BRWHITE", "BRWHITE", "BRWHITE", "BRWHITE", "BRWHITE", "BRWHITE"
];


[Edit: lol, the above was backwards].
40.0/59