[crossfire] map redo: more layers.

[Mark Wedel]

tchize wrote:

>>
     
       The trickier part in all this is how to condense it down for the 3 objects for 
     
     >>
     
     old protocol.  May idea would be to basically set up a table which says order of 
     
     >>
     
     objects you are looking at.  The order would always be the same, but it may be 
     
     >>
     
     something like:
     
     >
     
     
     >
     
     
     >
     
      why adapt old protocol, keep it's old behaviour (floor + 2 topmost objects)
     
     
  I'd have to look, but I think the old display logic has a more complicated 
logic than that (eg, things like monsters have pretty high importance in the 
display order).

  The old system basically had 3 layers:
1: Floor
2: Most important object, typically determined by visiblity value or other critier.
3: top object.

  The problem with just taking the floor + 2 top objects is a couple spells now 
obscure all monsters beneath it, which may not be a good thing.  I suppose that 
can be used as a first pass to see how things look, and if it breaks a lot of 
stuff, work on refining i.


>
     
      may i suggest static  things like buildings/floor be sent once and for all to client
     
     
  Static things in general will only be sent once - the new system should make 
that more consistent - one problem with the old system is things can 'jump' 
layers depending on other objects.

  But if you mean send all static data for the map once, that creates a few 
problems:
1) Imposes even more lag when hopping maps, as a potentially very large burst of 
information needs to be sent.
2) potentially gives away map information (I'm ignoring the issue that most all 
maps are available for download - one could envision a server running private maps).
3) Gets trickier for the outdoor world maps

  IF you mean we only send that building once, then we need to track somehow we 
don't need to sent it again (I imagine the case you're talking about here is 
player steps to side so portion of map is no longer visible, then steps back 
that direction so it is again).  I suppose we can track that player has seen 
that space before.

  However, in both cases, I think the bandwidth savings by doing this are 
relative trivial - granted, a player stepping back and forth constantly will 
cause a row to be redrawn, but if players want to abuse stuff, they can hop back 
and forth between maps.


>
     
      Also, think about integrating ground animations in protocol (i mean, do not send
     
     >
     
      sea each time it change, better tell client there is an animated object on that layer)
     
     
  This is reasonable, but I think we need to establish 'constant' animations. 
What that means is that this is the animation sequence and this is the speed and 
will always be the speed (which for things like water is true).

  Then, we could send that animation info once, and then when we get such an 
animation, just send the fact is is constant animation XYZ.

  If we have to send animation speed/phase for such objects, this is less a 
gain.  And if we try to do it for monsters, I think it adds a lot of 
complication for what once again may not be a lot of gain.