Raphaël Quinet wrote: > On Thu, 21 Aug 2008 08:26:35 +0200, Andreas Kirschbaum <[EMAIL PROTECTED]> > 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. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
