[crossfire] map2 & animations

[Mark Wedel]

Tchize wrote:
> Mark Wedel a écrit :
> quick comment on one point. I agree on principle but about 3:
> 
> The principle of leaving this case server side is ok, but maybe another
> suggestion is
> send it has a phased animation which doesn't repeat. Of course you can
> get a gap between server state and client state. I think it's not a real
> problem if we consider the 'phase' of an animation not based on
> current_face but based on time (like the animation is at phase 2,53 sec
> after startup), this is coherent with the idea to send the speed of an
> animation in terms time between changes. (like animation has 0.80 sec
> between changes). You could then resync any gap that may happen between
> client and server by 'replacing' anim by a picture when anim has ended.

  True - any of the problems I mention can be overcome with enough work.  The 
question starts to come in is it really worth the work and complexity.  If we 
get a case where we are saving 30 bytes/second but at the cost of a couple 
hundred lines of code in the server and client, is it worth it?

  My personal thought is no.  Some of this goes back to the idea of code testing 
and cleanliness - one thing that helps out in all regards is less code (fewer 
test cases, less lines of code where something could go wrong, etc).

  So there is some balance between all these considerations.  And at some point, 
it could be considered more valuable to work on some other piece of code rather 
that has more important and perfect some other piece of code.

  Now for the non repeating animations, my thought it would transpire like this:
  S->C: there is a burnout at 5,5, and it doesn't repeat.  It is at phase 2.
  Client:  On its own, it goes and does the animations.  When it gets to the 
last phase and time to move to the next, it just stops, continuing to draw the 
last phase as a static image.
  S->C: there is no longer a burnout image/animation at 5,5 - delete it
  Client: goes and deletes it.

  So in this case, if the timing isn't perfect, not a terrible thing - the map 
will continue to show the puff of smoke.  If we are only off a couple ticks, 
probably not very noticable.

> 
> The point on 'server stops for 1 seconds' is a false problem, as the
> server after the 1 sec map loading freeze, will give lots of ticks at a
> time to the animated object.

  I'm actually not sure that is the case.

  If there is a network hiccup, that is certainly the case - the server has done 
all the work and sent the data, and you get it in a burst.

  I'd have to look, but I don't think there is any catchup mechanism for when 
the server does something costly.  So in the case of a 1 second map load, that 
is basically 8 ticks.

  I'd say that not catching up is the right thing here.  Otherwise, you could 
get the situation where you are fighting some monster, some costly map load 
happens, and the monster gets 8 ticks of action in the blink of an eye - too 
fast for a player to react with things like healing, running away, etc.

> 
> btw, it would be a good thing to store the phase as a float in maps too.
> Currently, if you desync lots of background on  a map and the map get
> cached, at reload, all items do change phase at the same time (because
> it's current face which drive anim state at maploading)

  Fair point, but perhaps less and issue.

  As I think about this, having the client handle some animations in fact 
greatly frees up the server.

  Think in the case of ocean animations.  Right now, every so many ticks, the 
server goes and processes all those ocean objects - changing the animation, and 
then calling update_position to change the map view approriately.

  If these animations are moved to the client, these objects can now become 
static on the server - the server tells the client to animate them, but the 
server doesn't have to do anything more like animate them itself.

  Some rework would be needed, as right now, objects are only animated if the 
object has speed (thus, held goblin will stop being animated).  There would 
probably need to be some flag to denote that yes, animate this object, even 
though it has no speed.  but FLAG_CLIENT_ANIMATE_SYNCHRONIZE could perhaps infer 
that, but perhaps another flag is still needed - I could see other terrain which 
you want animated with FLAG_CLIENT_ANIMATE_RANDOMIZE.