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. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
