[crossfire] Magic map colors and related changes necessary for client and server

[Mark Wedel]

Rick Tanner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> After testing on my part and discussion on IRC, it was discovered that
> one can add addition colors to server/common/images.c (around line 100)
> and then recompile to allow more colors for the magic map spell
> (assuming archetypes are also updated with this new color in their
> magicmap field -- formerly, color_fg).
> 
> (Note: make sure to add a comma after the color "kahki" like this "kahki", )
> 
> However, the current X11 and GTKv1 and GTKv2 can/will crash if any new
> colors are added.  So, some undetermined change(s?) needs to be made
> with the clients to support 13 (or more) colors.  The JXclient does not
> crash; it displays, in this case, purple as dark_gray.
> 
> With this in mind, I went through the archetypes and replaced purple
> with black.  This was r9762.

  Yes - this is because color information for magicmap is sent to the client as 
that value on the server.  The current colors for magicmap correspond to the 
colors for the messages (NDI_....)

  Almost certainly what is happening is the client is getting a color value that 
it assumes is valid, and is looking up values beyond what are in fact valid. 
The Java client is more intelligent and does bound checking or the like.

  The right solution for the client in these cases is that if it does get a 
value out of bounds, it should just use a default.

  If more colors are desired, that is more work to do, as the NDI type values 
would need to get extended.  IMO, those NDI values will eventually go away (the 
messages have been changed to send the type of message, and the client can then 
look up how that type of message should be displayed).  I'm still tempted for 
magic map to just send more data so fill in fog of war or other details on the 
map - in that case, the magicmap values would completely go away.