CSQC player movement prediction

[Urre]

[Spike]

prediction works thusly:

client frame start:
if player ent updated:
read what the server's entity state is
save origin, velocity, input frame somewhere
before drawing:
reset pmove variables back to the last known state
for each input frame (serverframe <= frame < clientframe):
read input frame (angles/movement/jump)
update origin+velocity running your prediction code
add view offset, step smoothing, and optionally error correction
update view origin to predicted move and angles to final angles
note: as an optimisation, you could only reset when the ent is updated.

server:
the server changes for prediction are not finalised - there's no direct support in fte.
if you wish to add your own prediction, you'd have to undo any changes done between playerprethink and playerpostthink, and presumably run it at the start of playerpostthink - but this isn't 100% in the case where input frames were initially dropped (using two+ input packets in one client packet). There'd be some qc callback function and some special globals identical to csqc names for consistancy and code sharing.

the engine provides a builtin which runs the engine's standard movement for you, based on the contents of globals.

http://fteqw.svn.sourceforge.net/viewvc ... iew=markup
UpdateLocalMovement updates vieworg and input_angles


Predicting other players is harder and my test mod doesn't attempt it, although it could be done quakeworld-style by just extending the most recent input packet from that client a little.

[Urre]

Been reading it a bit, trying to wrap my head around the concept, and it's slowly coming to me.

Yeah, it'd be pretty nice with a QC override for the physics code, and not just SV_PlayerMovement which is in DP, as it only handles input and isn't really physics related. As it is now you need to hack it in various ways.

But how is error correction optional? I can imagine errors occurring quite often, and what happens if you don't correct those? Won't that mean your client is out of sync for the rest of the game?

Also, I'm confused about where a bunch of the variables are set, are they set by the engine?

EDIT:

Hm, it seems they're all set by that code. Problem is, to me it looks just like it simply reads server fields and assigns them, what sort of prediction is that? I see the physics builtin alright, but if the fields are read from the server as soon as there's an update... Or wait, are those only used as the previously known positions, and then the builtin assigns the new values in this case? In that case, what happens if I don't do error correction?

[r00k]

Hmm, interesting, would it be feasible to have prediction code within the server's QuakeC for netquake servers? This way players even using Zquake for example can /nqconnect to a netquake server and still feel like they are on a qw server. Which could merge a whole bunch of players into one lump group

[Urre]

r00k: short answer, no. We're talking about CSQC here. And a lot of QW physics are quite different to NQ, so I doubt QW players would deliberately play on NQ servers, even if they get prediction.

[Spike]

the globals defined in that file are not considered special by the engine and will never be set/read by it.

getinputstate sets input_*
runstandardplayerphysics reads input_* pmove_* movevar_* and sets pmove_*
*commandframe globals are automatically updated each time a new input frame is generated/acknowledged.

if you have any concerns about a specific variable, you'll have to name it.

error correction is a misnomer. the actual correction happens due to resetting the state to the last-known-good state. assuming the client+server match, the number of errors are increadibly low, and when you do get them, it'll snap back to what it should be. if you get continuous errors (or rather, something blocking the way) then its still smooth enough that few people will notice. The only time when its actually that noticable is when you're standing on a moving platform. Moving platforms can be predicted for the most part too.
if you predict forwards fully on receipt of a new known-good state, reset and predict after, then compare before and after, you know how much you were off by. you then offset the new by the wrong and reduce the wrongness over time, covering the error smoothly.
The greater issue is step prediction, and my csqctest code fails at that. It just can't take two steps at once.
step smoothing is much more important than error smoothing if you want it smooth.

r00k: authentic netquake physics cannot be predicted reliably, which is the whole issue with SV_PlayerMovement. If you're willing to raise the tic rate a little, then you can implement close enough NQ physics in a csqc-supporting qw engine. qw physics were written with high tic rates in mind (mostly anyway).
then you can have nq/qw clients using identical physics, but you'd have to implement the physics purely in qc, as the engine defaults to its own standard physics behaviour for the given protocol.