[CF-Devel] map bug

[Mark Wedel]

the seer wrote:
>
     
     
     >
     
     
     >
     
      Actually I was suggesting that we just have the client treat certain
     
     >
     
      archetypes as if they are on layers.  Then rather than having to calculate
     
     >
     
      every single image on the stack, you just use the map images for the bottom
     
     >
     
      images, as suggested by the architecture ( i thought that was what the
     
     >
     
      archetypes were for), and then code other objects on top as needed.  The
     
     >
     
      code is all client side, so no more bandwith is needed.  The images can tell
     
     >
     
      it all it needs to know.  If this won't work, then I guess I just don't know
     
     >
     
      enough about the project.
     
     
 archetypes are just a fancy name for the master objects that all objects used
in play are based off of.

 The client itself has no idea of archetypes.

 In the actual map display (where the monsters are), the only information the
client gets is the image numbers to draw.  The server does all calculation of
what can and can not be seen, as well as what appears on each space.

 Now the look and inventory windows are different, in that the client gets more
information.  But I don't remember seeing any issues with those.

 But back to the map.  There are really two issues:

1) Cost of computing multiple/all layers on a space to spend in terms of server
cpu usage.
2) Cost in bandwidth to send say 4  (or whatever) number of images per space. 
Not that when I say images, I only mean image numbers (which are a little less
than two bytes), and not the actual image information.

 #1 can probably get deal with by being smarter on the server on how we update
what things look like (calculate as needed), but unless you are going to send
all the images, you need to somehow decide what images you are going to send. 
Because you get the case of say ground, dragon tranport, a sword, a shield, and
then a monster on top.

 You always want the ground, as without it things start to look really bad
(unless something else on top has no transparancy).  And you want the top object
(monster in this case).  But those intermediate objects get trickier.
Without some extra clues, how do you determine if you should send the dragon
transport instead of the shield for example.  But choosing the two bottom images
+ the top two doesn't work.  Substitute a bow for the dragon transport - in that
case, you really want the monster, shield, sword, and then the ground (presuming
we are doing 4 stacking layers here).

 This gets trickier because some object, like monsters and fireballs, should
pretty much always be on top, yet other objects like stores and dragon
transports should always be on the bottom.

 Right now, there is a visibility flag, but that determines where things show up
in terms of stacking (so high visibility goes on top, so it is usually drawn,
but this is not really the right behaviour for floors).

 the right thing would probably be add a 'layer' field, which is used for actual
stacking of objects - if the editor is redone, this could also be useful to see
various layers - so for example, things like magic ears and other hidden objects
would have a layer below the floor, and in the map editor you could select that
layer and see all that stuff easily.

 Visibility then becomes something that is used solely to determine what is
actually seen.  Floors would be a special case, and always sent, but beyond
that, visibility would probably roughly correspond to the size of an object, so
if you say had plate armor (high vis.) and a dagger (lower vis.) on the same
space, from afar you would see the plate armor, even if the dagger is currently
above it.

 But that could get confusing, and would also require a lot of tweaking on the
visibility to get it correct.

 For now, I'll look at the simple 3 layer approach which is mostly in place - 

If we have two floors, they will be the bottom two object drawn, and the top
object on the space will be the third one.

 If we have one floor, we will draw that, plus the top object, plus the object
below that (if not the floor).  This should fix the dragon transport issue, and
otherwise make things look better.

 Unfortunately, this consumes more bandwidth (extra image to send down the
line), and in same cases may be completely useless because the object on top
completely obscurs the object beneath it (like say a dragon on top of a
dagger).  But there is no feasible way to handle that, other than not send those
intermediate objects at all (there is no one to know for example, that the
dragon completely obscures the dagger while an orc does not)