Right. Well, for me only the prediction was the option. I mean, I couldn't figure out how to do it otherwise.

My physics is very simple. All vehicles are just boxes, I purposely keep physics as simple as possible, which gives me very good deterministic results.
I could only get it to work using prediction. In my game vehicles will be colliding with each other quite often. I don't see how I could handle it any other way. If I didn't predict remote vehicles, local player would see the remote clients from the past, which for the vehicles could be like a few meters behind and if I locally wanted to collide with the remote client, I would be colliding with his version from the past, which gave me really, really bad results. Especially for that guy I've hit. He was sure to be far ahead of me and safe, while on my screen I hit him, and then what? I tried with lag compensation on the server side like I do for shooting, but this was the most horrible experience ever. You could be pushed around by the vehicle you see behind you.

Stumbled across this and it was a really informative discussion, thanks! Thought I’d share this for future readers like myself.

I tested rocket league with pings above 200ms and it does happen for them too. The only difference is that they hide it even better than me somehow.

They do this by “by decaying a player’s input over time based on how old that input is. For example, the first frame you’re predicting a remote player you apply 100% of their movement input, the second frame two-thirds, the third frame one-third, and by the fourth frame you don’t consider the remote player’s movement input at all. The intuition here is that undershooting motion and then catching up when remote input is received tends to look a lot better than overshooting and then rubber-banding backwards.”

This is from the April 2023 SnapNet article on predict-rollback part 2. Hope it’s helpful!