RCL wrote: > There was no problem with synchronizing object positions/states, as > there was only one piece of code that actually did the calculations... > all the "clients" (including local one, which shared CPU with server > part) just received the stream of object positions for a given frame > and interpolated between two frames to match their own FPS rate.
This is what should be done in wormux, too > I guess the biggest difference between the above scheme and one > implemented in Wormux, is that Wormux server communicates not the > object states, but the "actions", that are used to drive the client > code the same way as usual keyboard input would. And those, sometimes, expand on the clients differently. > But the actions seem to be able to come at any time and there's no > notion of "server frame" in the Wormux code (e.g. a complete set of > object states for a given time on server), so if some "rogue" or > buggy/outdated client interprets some particular action differently, > there's no way for the server to fix object position for him, or to > even know about that, right? I think you managed to point out what I always thought to be a weak pointin wormux' net code: clients shouldn't be allowed to make calculations independently. There can be several things that can go wrong with that: parallel universes (one player sees A dead, another sees A alive), errors in FP implementation of one processor can cause desyncs, etc. In the worst case, the client that is the current active one should be the one dictating and distributing all the information about the changes, while the others will just update the views accordingly. Since we don't have a real-time game, there is no problem with the fact that the active payer is ahead of the others. -- Regards, EddyP ============================================= "Imagination is more important than knowledge" A.Einstein _______________________________________________ Wormux-dev mailing list Wormux-dev@gna.org https://mail.gna.org/listinfo/wormux-dev
