[crossfire] map redo: more layers.

[Mark Wedel]

tchize wrote:
>
     
      Le Mercredi 7 Septembre 2005 07:49, Mark Wedel a écrit :
     
     >
     
     
     >>
     
     David Delbecq wrote:
     
     >>
     
     
     >>>
     
     Le Mardi 6 Septembre 2005 09:38, Mark Wedel a écrit :
     
     >>
     
     
     >>>
     
     You don't get it, i meant, use the old code for that :) It's working so why change it. 
     
     >>>
     
     Your problem is to get old client to receive old style message. Aswar is easy, call 
     
     >>>
     
     old functions :)
     
     >>
     
     
     >>
     
       Yes, but right now if you look at MapSpace function, it has definitions for 
     
     >>
     
     what is on the different layers, and is coded for those 3 layers.
     
     >>
     
     
     >>
     
       If we go to 10 layers, I don't want to have to have something like:
     
     >>
     
     
     >>
     
     struct MapSpace {
     
     >>
     
          object	*old_faces[OLD_MAP_LAYERS]
     
     >>
     
          object	*faces[MAP_LAYERS]
     
     >>
     
     }
     
     >
     
     
     >
     
     
     >
     
      Yes, you are right, i forgot layers were stored in maps and not in player socket (is
     
     >
     
      it really efficient to store it in map btw?)
     
     
  It is probably more efficient (cpu wise) to only calculate what the spaces 
look like in one place.

  With the new layer system, I think the cpu cost of storing what the layers 
look like will be relatively trivial - we already need to traverse the spaces on 
the object to determine if the block site, block passage, etc.  While doing 
that, storing some of them away is easy.

  But really, whether it is more efficient to do it on the map or per player 
would perhaps depend on map usage.

  Certainly for maps where only 1 player on the map, could be some gain in 
storing in purely on the player side.

  However, maps where there is more than 1 player, figuring it out in one place 
is certainly more efficient.

  That said, the other reason to have some fallback method is that I could 
forsee  players on more bandwidth (or cpu) limited situations saying 'I really 
don't want all 10 layers - I only want 5'.  So if we have a fallback method for 
sending them 5, then having a method for sending just 3 isn't that much harder 
to do.