mxp 'default' colours

How can I change the default mxp colours? I.e. as far as I understand it, the MUD sends tags with certain colour names and the client renders them to colours. So, e.g. if the client gets a 'red' tag, how could I change the colour for 'red'?

Umm.. You don't. The reason being that Red = #FF0000 as a standard. If you could redefine what the standard colors actually mean, then they wouldn't be a standard. MXP is not really so much a mud feature as a transplanting of HTML into a mud envorinment. If an HTML tag 'looks' like a particular color in all browsers, this is a good thing, same with muds imho. If I specifically use say, "The house is the color of <color="PapayaWhip">papayawhip</color>.", I expect it to not be green when the client displays it. The same is true of the pure colors like red.

Now, I will admit that some muds just beg to have you change the bloody colors. They still only use the basic Ansi colors, just with MXP tags, and they employ them in a way that seems to want to bore straight into your brains and make you go blind. Either ROM or Smaug (I can't remember which at the moment) try to do this by avoiding the common and reasonable light grey, instead opting to make the largest blocks of text in the game bright yellow by default. I am still trying to figure out if there is a setting for that or you have to manually edit every damn room. lol

In any case, there isn't any built in way to change the settings of a color name to be something else and for real applications of MXP, not just the 'lets underline mob names...' BS most use it for, the guys designing with it wouldn't want them to be changable anyway. It would ruin whatever information he tried to convey by using a specific color.

I'm glad you asked that, because I argued long and hard in the zMUD forums (where MXP was developed) that there should be provision for MXP colours to be "palette" colours (like ANSI colours), however I lost that argument.

I suggested that it would be preferable for MXP to send "style" information (like, this is a room, this is an inventory), rather than "use colour #AB123C" because not everyone might like that colour. However it was deemed that MXP would be used to send actual colour information, and hence it isn't really practical to change it.

Sure, standard colours like red could be detected, but what if it was #FF0001 - one bit away from straight red?

What you can do is check "ignore colour changes" in the MXP configuration box. Then it will not use MXP colours. Then you might use triggers to colour the lines as best you can.

I'm doing that atm, but it's a more than imperfect solution. :-) It would be great if MUSHclient could do some magic about that problem (not I mean you should go against the protocol specifications, but maybe have an option to 'render' mxp colour information differently, e.g. if you get sent colour value A, the client will translate that to value B).

E.g. #abee11 will be translated to #a00000. That way, after a line ends the colouring won't end, but rather the strings inside the tag will be coloured completely with what colour the user wants to use.

I hadn't really thought of trying to map colours from MXP to something else, because there are potentially 256 * 256 * 256 colours (16,777,216 RGB colours).

However a MUD probably would not use all of those, and in fact in all likelihood only use 20 or so, so it might be possible to have a mapping table, where MUSHclient maps colour A to colour B, and if not found, leaves it alone.

This would probably handle 99% of cases.

I've added that as suggestion #528.

Version 3.54 now allows you to specify, in scripting, mappings from the unwanted colour to a replacement colour. See the script function MapColour.

eg.

MapColour (ColourNameToRGB ("red"), ColourNameToRGB ("green"))

MapColour (ColourNameToRGB ("darkslateblue"), ColourNameToRGB ("mediumslateblue"))

You can do that for as many colours as you want, within reason (ie. I wouldn't try to do thousands of them).

The "Text Attributes" dialog box has been enhanced to tell you the colour of the current text that you have selected, to make it easier to work out the "from" colour.

It does sound fairly odd to be sending color directly. It puts the burden of customization on the server and not the client.

Now, some servers can still allow complete customization of color, and send colors in the MXP. This would be, for the client, the same desirable behavior. It just means that the server has to store everybody's color preferences, which does seem less desirable (for the server) than sending style names and letting the player sort it out.

An interesting effect you can get, is to change the background colour (normally black) as a visual highlight if you are getting injured. For instance, you could make a trigger that does something like this:



You could change the colours to gradually become more red as your HP get lower. The test above for the oldcolour not equal to the newcolour is to reduce flicker.

If the colour changes (ie. your HP pass some threshold) then it changes the background colour (ie. the colour for black) and forces a screen redraw with Redraw.

This is quite effective. :)

For some reason the text attribute marking doesn't work when I'm marking text without a line break (I think).

I can reproduce this sometimes - for most of the times I'm clicking on the Display menu though the Text Attributes entry is greyed out.

P.S. Thanks for this feature, very much appreciated!

It is grayed out if you don't have text selected. The attributes are of the first character of the selected text. Can you confirm it happens to you, if you have something selected?

Actually.. Sending the color directly has much greater control when using ASCII graphics. In a client that actually has full MXP support you could use a 1 point font, the block characters in the original DOS font, or some similar character, and literally paint a picture with fine color gradients. You could almost do that anyway with the color names, except Mushclient only supports the 'baseline' colors for those names, while the full set under Unix actually includes about 663 or so, which includes lighter and darker versions of the same colors. If you limit colors to only 'known' names, then you limit what you can actually do with them. For a purely scrolling client like this one, it is pretty irrelevant, but one with text positioning and full color could even animate fade in and fade out effects of a ascii graphic.

Of course no one actually uses MXP that way that I have seen, but....

MUSHclient supports all possible colours in the format "#7FFFD4". See this:


http://www.gammon.com.au/mushclient/mxpcolours.htm


I'm not sure what list you are referring to as the "Unix" list. If you give me a reference to that list I'll look at including it.

Sure, ASCII graphics are an application of using direct color, but a) we were talking about very different things :-) and b) as you said, nobody does that anyway. Of course it's useful to be able to send direct color, but most of the time it seems much smarter to be sending style information, not just brute color. As I said, sending brute color puts the burden of customization on the client, and then they can't split apart two things that are red into two different colors, whereas with styles you could easily do so.

Umm. Not what I meant Nick. I mean that the HTML colors are a subset of something found on a lot of Linux systems. Its like colors.txt or something. Instead of merely having Tan as a color name, you have in there:

Tan
Tan0
Tan1
Tan2
Tan3
etc.

With Tan itself being the same as like Tan5 or something. The color names are essentially the same, but lighter or darker, depending on the number designation. Mushclient only supports the 'baseline', because it has the standard HTML values in it, which are a subset of what I can only assume was the original list from way back when they where first defined. I have/had a complete list someplace, but not sure if it is still on this comp or I moved it to a CD to clear up space. It wasn't easy to find online, though finding it on a Linux install may be possible. Also, the POVRay raytracer has an 'almost' complete version in the colors.inc file that comes with it. I think it is missing a few though and the format is in <R, G, B>, instead of hex. I think they copied the original colors.txt file from Unix and used it as a template for colors.inc and later for the colors in browsers. It would explain why all of them have the same questionable idea about what Brown is supposed to look like. ;)

Err, who cares about the text-values (except in extraordinarily specific applications, where this is not one of them), when one can specify things fully with RGB anyway?

I got the sense that part of the idea of having MXP be able to use styles would imply using color names, not the RGB, since it is easier to remap predefined colors like that by name that worry about trying to remap FF0001, FF0004, FF0006, etc., just to make sure you cover all the bases. I may have misread that. But yes, for general use, the full color info is better.

Edit: Nvm. I think I get what he meant. Something like:

<defstyle name="Bigred" color="red" Bold Size="24">
<style Bigred>Blah!</style>

Instead of the much more messy HTML like way of doing it.

Actually, I think that 'style' information is more like sending color "room", and letting the client sort out what color "room" is e.g. green, white, whatever.

Yes, although I was thinking of not sending colours at all. A colour is how you represent things, so I was thinking of sending what the "thing" is, eg.


<inventory>
... your inventory here ...
</inventory>


Now your client might be configured to show the inventory in green, indented 4 spaces, or maybe in a separate window. It can do that, providing it knows it is getting an inventory.

> It is grayed out if you don't have text selected. The
> attributes are of the first character of the selected text. > Can you confirm it happens to you, if you have something
> selected?

Yes, I can. I just tried a few times and the text is marked but the Text Attributes field is greyed out.

Ah, well, the problem with the idea of having the 'inventory' be a client side entity is that it assumes every entity you want to use will be consistent across all muds that employ it. You end up limiting your options. My concept would have the mud declare the entities that contain the styles, then the client could provide, as part of what gets saved back to its character file, a list of styles from that world and their mappings. A seperate edit screen could then allow the player to examine the styles and alter them to match what they want, before saving the changes to their character file. All that would be needed would be an option in the editor for "Use my settings for this style.", to prevent the muds initial attempt to set the style from overiding yours.

Not that it matters, since you are not likely to go and add such support when it isn't in the standard MXP implimentation anyway. But sometimes you really have to look at things from a 'how customizable is this really?' angle. ;)

It is all moot, as it isn't in the spec, but this is how I would envisage it:

• The MUD defines "types" of data (inventory, spell lists, room descs, training info, objects on the ground etc.)
  
• When displaying a "type" it brackets it with the appropriate tags, as I suggested above.
  
• It could also send down suggested handling for a type, in case you don't configure it. eg.
  
  Inventory = brown, indented 4 spaces
  
• However if you play a particular MUD a lot you could look at the custom types (eg. inventory) which would appear in a list (as the client had already seen them) and then override the behaviour, eg.
  
  Inventory = blue, separate window
  

So, basically we both have the same identical idea, I just used a 'style' tag plus the name of the style, instead of relying on the assumption that it wouldn't interfer with other tags which might inadvertantly duplicate the names used for the style.