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

[Andreas Kirschbaum]

Mark Wedel wrote:
> 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.

This is exactly what is happening: all of x11/gtk/gtk-v2 either allocate
an array having 13 elements or allocate 16 elements but do not
initialize more than 13 elements. The access is a color index 0..15
(without bounds checking). Jxclient allocates a 16 element array, fills
the undefined entries with dark gray as a default, then uses an index
0..15 for access.


> 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.

I vote for this solution -- do not "improve" the existing magicmap color
table but send actual face information in magicmap responses.