[crossfire] map2 & animations

[Tchize]

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.

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.

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)

>
>3) Animations in which phase is important (or temporary). Example here would be 
>things like gates/spikes.  In this case, the client really needs to know what 
>phase the gate is in when it shows up - it can't lockstep it or randomize it. 
>In addition, timing here is important - if the server spends a second loading a 
>map, the client has to be aware that those gates haven't done anything for a 
>second.  This isn't that hard to solve by adding something like a 'S-C> 
>hearbeat' protocol command which the server sends each tick it processes.
>
>  But here, we still get a timing case - suppose those gates move at speed 0.2. 
>  Just telling the client that it is on phase 2 really isn't enough - the gate 
>could go to phase 3 the next tick, or to that phase 5 ticks from now.  So to 
>handle this, not only do we need to send the phase, but also how soon until the 
>next phase.
>
>  My personal thought is this:
>Add new flag(s) which says how to handle animations.  My personal thought is 
>leaving case #3 as a server side is probably the easiest (server side being that 
>we don't send animation to clients, just send face for the space like we do 
>now).  This doesn't get us as much of a bandwidth savings as possible, but does 
>keep things simpler - at some level, its a balance of how much complication do 
>we add to save some bandwidth.
>
>  
>