I'll give this PR a test over the coming weeks and report back.

Gave this one a round of testing. The improvement is noticeable - you can feel there is less reconciliation overall especially when it comes to observing the positions of other players.

Logging the rollback loops you can visually see they half as there is less need to go back to correct for late input arrival.

There may an issue with the "is_fresh" flag in rollback_tick when input_delay is active. I am noticing that things that rely on it are playing up occasionally.

You can see in the screenshot from my last comment, on the left they aren't as common as on the right.

Searching across logs there are definitely instances where a tick is never fresh, this doesn't seem to happen on the server.

Thanks for checking @albertok! As discussed on Discord, I think for now we can have both display offset and input delay, so we'll have to figure out this issue. Also wondering whether display_offset is affected by this as well.

My discrepancy with is_fresh turns out happens because the server can beat the clients at their own inputs if the latency isnt high enough. ( 2 ticks over localhost )

Basically the client was skipping running rollback_tick because the server had already processed and sent it a saved snapshot.

If I dialled up the latency this stopped happening.

@albertok added docs about this phenomenon both in the GDScript docs and the site, so hopefully people don't run into the same issues! Will return to the question of is_fresh in a separate PR.