   movement problems
  i thought about a problem i am going to have.up until now i've sent the position of a player to the server(which sent it to other players) but let's be honest, i cant release my game with this way,it'll be laggy and unsmooth.so i thought of the obvious method, send direction+position every time players starts moving,stops,changes direction,and every x seconds after player started moving.the thing is,with and without fps independant movement i am going to get results that will be diffrent on two clients.lets say client A and B are connected to the server, client A has 60 fps and client B has 10.client A starts moving,so i send the velocity + position to the server which sends to client B. now client B has to update the position of client's A, but since client B has much lower fps,the client A player that appears on client b will make a shorter distance than what realy was done.this is atleast for fps independant movement, with it i am also going to have problems.what would be the best way to sync the position of a moving player?   
  I think you're after time based stepping.  From an animation standpoint, you'd be using the time delta between cycles.  From a networking one, you'd be making movements based on the packet times received (previous and most recent ones). EPIC does this (see FAQ), or you can simply make your steps based on a network synchronized clock (and it doesn't have to be extremely accurate, just able to sequence events properly), and deal with your own interpolation.   ;  i dont think you understand.even if i send fps from client A to server to client B, i am still going to have problems that client B might see client A moving faster or slower than what that is realy going on because client B has a diffrent fps than client A   ;Quote:Original post by Brueven if i send fps from client A to server to client B, i am still going to have problems that client B might see client A moving faster or slower than what that is realy going on because client B has a diffrent fps than client A1) Lock the framerate (don't draw any frames until all clients received same update), only realistically works on LAN2) Use framerate-independent updates