@nex said in Why would you have left FAF?:
@blodir Isn't the input lag something that's deliberate (and not related to the sim)?
Because you need the input lag, to compensate for potential network lag.
That's why the game has a standard input lag of X ms, so people that have X ping to each other can still play together without stuttering.
That is because the engine expects input from every player on every tick, so if you have a higher ping than the input lag, the game micro freezes till all inputs arrive.
Changing the simulation tick rate shouldn't matter, but you'd need to rewrite how the engine works to be able to solve this lag problem. You'd need to introduce some kind of rollback code, that when there is no input from a player continues the simulation, but once the input for an earlier frame arrives, you'd need to roll back to that state and recompute up to the current tick (that's how most fighting games work), but that's a pretty heavy workload for a complex simulation like supcom (that doesn't even manage to run in real time sometimes).As far as I understand springRTS, it handles it by having a server-client architecture, with the server as the single source of truth, so when someone lags behind they'll just get updated to the state of the server.
Tick n:
- collect pooled inputs during the time between tick n-1 and now and send to other players. Mark these inputs as destined for tick n+1
- run simulation with inputs destined for tick n (if inputs for tick n have not been received from all players, then pause)
So with 500ms sim tick length if you enter input (eg. give a move command to a unit) 10ms into tick n-1, then the input will be sent at 500ms, and executed at 1000ms. That is a 990ms input delay, which is tied to the sim tick rate.