Thanks for clarifying the physics execution question.
I see. You pretty much want smoothTimeState to do what valve does with Entity Interpolation.
They seem to have a fixed distance though ... somehow when I read that entry it doesn't remind me of "InterpolationTest".
I am trying for quite some while now but still am not able to precisely point to the source of the jitter. Hope someone finds it. (Like what constant can you change to increase/descraese the jitter)
I propose to have the local player also play in the past. Contrary to how valve does it. If you do that, slowing or speeding up client time should not have any effects.
If the client sends his localGameTime or client.snapshot.id acompaning his input the server knows exactly when, in "GameTime" these inputs where made.
The server then can still be authoritative. See in the valve article "Lag Compensation":
The lag compensation system keeps a history of all recent player positions for one second. [snip]
Then the server moves all other players - only players - back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players revert to their original positions.
Client physics are comparable to Input prediction
Huge example inside
Player 1, 44ms to the server. He flies at constant speed.
Player 2, 166ms to the server. He has brought his ship on collision course with Player 1.
Player 3, 10ms to the server. Just watches.
Player 4, 355ms to the server. Just watches.
RealTime = 5.5
server at Tick 110. 20 ticks/s. serverGameTime = 5.5
player 1 at Tick 108 + 6ms = clientGameTime = 5.406
player 2 at Tick 105 + 34ms = clientGameTime = 5.284
Player 3 at Tick 108 + 40ms = clientGameTime = 5.44
RealTime = 6.0 (No one has done anything collision happens at this real time)
server at Tick 120 = serverGameTime= 6.0
player 1 at Tick 118 + 6ms = clientGameTime = 5.906 (Player will see collision happen in 94ms)
player 2 at Tick 115 + 34ms = clientGameTime = 5.784 (Player will see collision happen in 216ms)
Player 3 at Tick 118 + 40ms = clientGameTime = 5.94 (Player will see collision happen in 60ms)
RealTime = 6.017 (Player 2 changes course)
Client starts to change position. At the same time he sends his inputs to the server with tickId=116
server at Tick 120 + 17ms = serverGameTime= 6.017
player 1 at Tick 118 + 23ms = clientGameTime = 5.923 (Player will see collision happen in 77ms)
player 2 at Tick 116 + 0ms = clientGameTime = 5.801 (Player will see what happens in 199ms)
Player 3 at Tick 119 + 7ms = clientGameTime = 5.957 (Player will see collision happen in 43ms)
Player 4 at Tick 112 + 12ms = clientGameTime = 5.612 (Player will see collision happen in 388ms)
RealTime = 6.094
server at Tick 121 + 44ms = serverGameTime= 6.094
player 1 at Tick 120 + 0ms = clientGameTime = 6.0 (Player1 will see himself collide with Player 2)
player 2 at Tick 117 + 28ms = clientGameTime = 5.878 (Player will see collision happen in 122ms)
Player 3 at Tick 120 + 34ms = clientGameTime = 6.034 (Player saw the collision happen 34ms ago)
Player 4 at Tick 113 + 39ms = clientGameTime = 5.689 (Player will see collision happen in 311ms)
RealTime = 6.138 (Server receives input data from Player 2 with tickId=116 )
It will check if its plausibility, declare older ticks as invalid and calclulate new valid tick
RealTime = 6.151
Server sends out new valid Tick. TickID= 123
RealTime = 6.216
server at Tick 124 + 16ms = serverGameTime= 6.216
player 1 at Tick 122 + 22ms = clientGameTime = 6.122 (Player saw the collision happen 122ms ago)
player 2 at Tick 120 + 0ms = clientGameTime = 6.0 (Player2 will see himself pass Player 1)
Player 3 at Tick 123 + 6ms = clientGameTime = 6.156 (Player saw the collission un-happen 6ms ago)
Player 4 at Tick 116 + 11ms = clientGameTime = 5.811 (Player will see collision happen in 189ms)
Player 1 will receive corrective update 101ms after he saw the collision.
Player 2 will receive affirming update 101ms after he passed Player1.
Player 3 will receive corrective update 101ms after he saw the collision.
Player 4 will receive corrective update 105ms after he saw the collision.
tick.gameTime = timeStart + tickNr * tickInterval
serverTime = realTime - timeStart
clientGameTime = realTime - delayToServer - tickInterval
serverTick = serverGameTime / tickInterval
playerTick = floor(clientGameTime / tickInterval)
playerOver = clientGameTime - ( timeStart + playerTick * tickInterval )
The server is still authoritative though. It doesn't just take what the client is giving him but checks its outcome.
When some player changes something in the past and the server deemed that input as plausible it declares all ticks it sent out between receiving the input update and the tickID of the input update as invalid. The next tick it will send out will have valid information again. To calculate it uses the last valid tick and the dt between it and the new valid tick.
The delay for people to see the change should not be any different from any other method.
Ok ok the drawbacks are obvious.
Weirdly enough. I have created a netcode concept that results in the same amount of "lag effect". Not matter what the ping is. (See the example) ... kind of fascinating.
The "clientGameTime=realTime; clientRenderTime=realTime - delayToServer - tickInterval" method like planed by Flavien might have drawbacks too. I think one of them is that you can shoot targets that are at a past time relative to you. This is why you can't hold formation when renderTime changes. The further you lag out. The bigger the time distance to the targets in the past.
Oh I get it now ... so the server gets the "shot fired" from a player. It then sets all other players back to when the shot was fired and checks if it hits. If it does it applies effects and calculates everything back to realTime.
Still I have the feeling that every type of networking has its quirks. We are just used to them.
Anyway I concede. TIME TRAVEL IS WEEIIIIRDDDD
My stutter fix still works though! Just set back client physics to the way it was (using elapsed) and it will function as intended.
This post was all about usual network stuff and how it effects actual position. Not changing time.
I think ... I hope I have said everything I wanted to say. All the best.
Thanks for discussing this. Please don't refrain from including everyone in the discussion because of my .... persistence ... over enthusiasm ... eh whatever.
I don't want to force anyone to do anything.
I'm just an idealist.