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. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
