I tested 293b4c0 (input/debugger which contains this branch) with 200ms delay.

I found there is a weird jittering bug, present even if I disable input prediction. This means either the code changes to allow for input prediction cause it, or the marble movement logic is bugged. See 0:20 and 0:27 below (disabled input prediction and disabled input broadcast)

As for the input prediction itself, the above bug is present in the below 2 tests as well, where I enabled input prediction. I tried one with input broadcasting enabled, another with input broadcasting disabled.

The below is with input broadcasting enabled. At 0:25 there is a weird jitter. Also at 0:38 there is a teleport of sorts.

The below is with input broadcasting disabled. At 0:17 and 0:29 there is a weird teleport of sorts.

The above timestamp highlights are for the local client who has authority over his inputs. The other clients and the host, have artifacts. If these artifacts aren't fully related to a bug of the current implementation, and are related to user configurations, I would suggest some sort of input decay strength for properties or max input prediction ticks for the entire rollbacksynchronizer, so corrections won't be so noticeable. Like having input prediction for max 2 ticks in the marble example. Because otherwise, disabling input prediction leads to smoother visuals, as seen in the first video, and that shouldn't be a thing

@TheYellowArchitect I've added code for skipping prediction - basically to let the RollbackSynchronizer know that the node can't predict state based on the current input. This should improve things by a lot.

I'm also inclined to merge the current version - I'm pretty sure the glitching is a bug with the example movement code. From my own testing, I see that after a while peers disagree on velocity, which desyncs turn rate.

Let me know if you have any further findings with this new version!

It's visibly better!! 🚀
(All videos below have 200ms delay)

That said, the marble movement logic is definitely bugged - or Godot's default physics. I managed to make the marble completely stuck and immovable at a slope (once I noticed that, I started recording the below)

There is also another probably marble movement-related bug (so, unrelated to input prediction):

Also, in current implementation there is a bug I have to report: The local player jittered/teleport on a straight line:

I don't know if the above video is related to marble movement code, because it doesn't jitter other players, but the local client who has input authority. But this input prediction is basically for non-local players so its weird to see such a bug

I can't find any other bugs. I am happy to see such improvement honestly, given the marble is an edge-case for input prediction. Marble movement logic can be fixed in the future, but if you are certain the above bugs are unrelated to input prediction, freely merge 🚀

Thanks for testing @TheYellowArchitect! I'll merge this carefully 😄

I'm not very happy with the marble code, but didn't have any better example at the moment. So I think there's a good chance that the desyncs are mostly stemming from that. Though there's still chance that the input prediction code is not fully stable.

Will release this as an experimental feature so I can get some real-world data ( and potentially bug reports 😄 )