[crossfire] Bug [ 1735459 ] Ground view missing face updates

[Mark Wedel]

  I looked at this bug a little.

  At some level, it is very easy to fix - if player is on a space, and anything 
(including face) on that space change, we just send all the contents of that 
space again to the player.

  That works fine, but is also somewhat bandwidth inefficient - if there are 30 
items on that space, it has to send all 30, because as of now, stacking order is 
important.  We should probably fix things so that stacking order isn't 
important, but there are still lots of things that assume will operate in the 
order the player sees (like apply below).

  A bad case example here is standing on a pile of treasure with say some rubies 
in it.  Rubies are animated, so that entire pile would have to get sent again.

  Now a simple answer could be we don't really care about bandwidth, and I can 
put in my fix.  I'm not sure if that is really the right answer.

  A better solution is to see if there is a player on the space of the changed 
item, and if so, just send an update item command for the changed face.  That 
could still waste some bandwidth (we send that update, but then the player moves 
off that same tick, so never really sees that change).  But updating just the 
face for a single object doesn't use much bandwidth.  The problem here is that 
more extensive changes are needed to be able to quickly find out if there is a 
player on the space, since traversing all the objects each time a face changes 
looking for a player would be pretty costly.  Since normally, only 1 player can 
be on a space, putting a pointer in the mapspace to point to the player would be 
a fast way to do that.

  But going further, the client has some level of animation support - for 
whatever reason, the code to animate the ground was never put in.  I just wrote 
that, and it works for some cases - namely, those animations we let the client 
do (continuous animations like fountains, dragon transports, or rubies).  But it 
doesn't handle the cases for things like handles (not really an animation, but a 
change of state), or gates (animate once, then stop).

  I'm thinking that the correct answer is a mix of the last two:  If it is an 
animation the client can handle, server sends nothing.  If it is a change of 
face that the client can't handle, then servers send an updateitem for a new 
face.  And a *player pointer to maplook to make easy lookups to the player 
should be relatively straightforward.

  But thought I'd send this out to see if anyone else has clever ideas on a fix.