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

[Mark Wedel]

Raphaël Quinet wrote:
> On Thu, 21 Aug 2008 08:26:35 +0200, Andreas Kirschbaum <akirschbaum at users.sourceforge.net> wrote:
>> Mark Wedel wrote:
>>> [...]  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.
> 
> Yes!  If there was a way to vote for this (other than by coding it,
> which requires time), then I would vote with both hands.  Sending actual
> map data would feel more natural and would make magic maps much more
> useful.  This would also get rid of ugly widgets in the clients.
> 
> FYI, that's exactly what Nethack does.  When you invoke that spell in
> Nethack, you get a full view of all static objects in the map.  Magic
> mapping doesn't display monsters or other living objects (unless this has
> changed since I last played it) but it shows all walls and tunnels, as if
> you had already been there.

  Note that in crossfire, at some level this could be simple, at some level it 
could be hard, depending on desired results.

  The simple case is we use the existing map2 command to send the data, but we 
just extend the amount of data.  The limitation is that the coordinates in map2 
are limited from 0 to 63, with the player located anywhere from about 21 to 27 
IIRC.  It would probably be odd to provide non centered map data, so what this 
really means it that the size of the magic map is limited to about 40x40.

  That is probably fine - unless zoom out or scrolling of the map window is 
added (maybe that exists in the jxclient - not sure), that is still going to be 
much larger than any viewable area, which right now is 25x25.  I often thought 
it wouldn't be that hard to add a zoom out feature to the map which reduces its 
scale by 50% or something (the opengl one makes that easier, as it does scaling 
in real time - the SDL and pixmap code would be more complicated, as it would 
likely need to draw onto a temporary buffer with the images it is using, then 
scale that down by 50% or something)

  I'm pretty sure that the C client will properly handle coordinates outside its 
viewable area, but not 100%.

  For the server, probably some hybrid of what it does now is needed - basically:
1) Still use the find viewable spaces function of existing magic map (in this 
way, things like hidden mechanisms are not revealed)
2) Use that information instead of the normal LOS code to determine which spaces 
are visible to send to client.
3) Send that data to the client.  It is probably worth adding a bit or something 
in the data sent to note this is magic map data.  Another reason for that is 
this could be used to note this space has transitory data, and thus we don't 
update the servers idea of what data it sent to the client.  In this way, on the 
next tick, there server doesn't have to send a bunch of data say 'clear this 
space as it isn't visible', since the only reason it was visible was because of 
magic map.

On the client, really few changes:
For all data received, just update the spaces as we do now.  The use of that 
magic map bit set above is for any spaces we do update, we do not want to clear 
the fog status - we still want them to be shown as fog spaces (or maybe a 
different type - magic map space or something, but unless drawn differently, 
probably no gain there).  The main point is you probably don't want them to 
flash as normally visible spaces for a tick and then flash into fog spaces.