in the test I just did, the client moved for 5468.7882ms while the server only moved for 5438.1314ms[/quote]
Why are you measuring milliseconds? You should be measuring number of steps.
Also, the inputs (on and off) should be time stamped with step numbers when they take effect. That way, they will run exactly the same number of steps on client and server.
Network input handling
Author
What do you mean steps? Actual character animation steps? Or "press W, move forward 1 foot" steps? The character movement as it's set up right now simply applies a velocity to the player for the duration the key is held. The character isn't moved in discreet amounts. Should it be?
well, I guess it was mentioned earlier that it is a good idea to do the simulation/game state updates with a fixed time step.
What you are doing right now is probably something like this (written as a pure function):
newState = update( oldState, inputs, deltaTime)
whereas with a fixed time step you would only have
newState = fixedUpdate( oldState, inputs)
and the duration of the update is kind of hard coded.
edit: if you do the fixed update, you only need the same set of inputs every time you do the update, for two simulations to be consistent. And since this is a discrete system time is represented by an integer counting the number of updates.
What you are doing right now is probably something like this (written as a pure function):
newState = update( oldState, inputs, deltaTime)
whereas with a fixed time step you would only have
newState = fixedUpdate( oldState, inputs)
and the duration of the update is kind of hard coded.
edit: if you do the fixed update, you only need the same set of inputs every time you do the update, for two simulations to be consistent. And since this is a discrete system time is represented by an integer counting the number of updates.
Author
Well I've done as much as I can think of to get it to a proper fixed timestep and the issue hasn't been fixed at all. All of the updating, both on the client and the server, is now run from an event that fires from the physics engine whenever it runs a timestep. The physics internally accumulates the time and runs timesteps at fixed intervals. I still haven't added the time stamping of input states, but I don't think that that would fix this issue, since I'm running both locally, it's not like there's any lag involved.
I still haven't added the time stamping of input states, but I don't think that that would fix this issue, since I'm running both locally, it's not like there's any lag involved.[/quote]
You should add the timestamping, and assert that it is correct. When it isn't, you can then start debugging why.
Are you polling the input at the same tick rate as the server, or applying it for the same duration as a poll tick interval?
Author
Yes, everything is run at the same tick rate and, at a minimum, applied for the duration of a tick
Do I interpret that correctly in that things can be applied for more than a round number of ticks? e.g. is 1.03 ticks possible?
Author
As it is right now, they shouldn't be able to, assuming I haven't screwed up somewhere. It should all be applied for a whole number of ticks. Should it not be like that?
You can go either way, depending on the resolution of your physics integrator, but applying consistent whole numbers of ticks is generally safest if your simulation rate is high enough that this doesn't cause jittery interactions.
If you are applying, say, 3 ticks on the client and 4 on the server, you've found your bug. If both agree that an action is applied for 3 ticks but the actual number of milliseconds applied differs, you have a bug in your timestep fixation code.
If you are applying, say, 3 ticks on the client and 4 on the server, you've found your bug. If both agree that an action is applied for 3 ticks but the actual number of milliseconds applied differs, you have a bug in your timestep fixation code.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
