GooberMan wrote:Part one is the easy part - I override some player settings (disable inputs, change speed, etc).
Part two is the part that desynchronises - the cars are separate things that inherit the velocity of the player. If ever their positions don't match well enough, I clamp them (which results in a visible judder with the car). This generally happens whenever the player collides with something. It should also happen with any kind of lag-dependent prediction model (such as dead reckoning, which I guess is what they use in Zandronum - I haven't looked at the code but it's what Carmack used in Quake).
The sprite-based non-exitable nature of the kart game though means I can just ditch part two. The plan is to have it easily selectable for modders, but I haven't gotten that far. Need to get the basics and the infrastructure right first.
Zandro is definitely not Quake based. It's a network method stream that random functions put data into (Quakes being a frame based delta encoded stream, if I recall correctly).
For incorporating it into zdoom, either method is complicated. The script that controls the player movement isn't running when the prediction is, and the prediction cannot assume anything about the player movement, other then what it already knows. I could make it so that an individual script is called each prediction cycle that allows for additional control, but what would be tricky (without some thinking) is adding something else to that cycle (that gets properly reset in the end).
No matter what happens I'll need to make a system that handles it, however.
(even though said mod is a long way from completion)
