csqc: player viewable body out of sync with player origin

[something]

hey all

ok so continuing from http://forums.inside3d.com/viewtopic.php?t=2750

but a bit more appropriate for being here.

i have a first person viewable body, and it works.

but when i tried to move it over to csqc. with the hope of eventually doing some twisting at the waist.

the update of origin is horribly delayed. and somewhat jittery.

that is. once it becomes a shared ent. it seems to only update the origin every 2 or 3 frames. and whats worse is that it seems to have a delay. so the body is no longer in sync with the player until the player stops moving.

so my question is whether there are any bottle necks which could be causing this?

is my body ent being moved late because csqc is processed post frame or something?

[mankrip]

I've never used CSQC, but this sounds like you're updating the viewable model's position in PlayerPreThink.

PlayerPreThink is run before the physics, so it will always be outdated. Update any physics variables like position and angles in PlayerPostThink instead.

[Spike]

'shared' ents are logically sent over the network at the same time as regular ents, at least if they're sent at all - you need to mark some field (Version(legacy, add 1), or SendFlags(set a bit, any bit)) if you want it to be resent.

'shared' ents are not interpolated for you. The engine doesn't know how. They will thus use whatever origin you set for them. Graphical framerate isn't the same as network framerate, so yes, they'll periodically move to the new location, freeze for a little and end up behind, then move a bit further. If you turned the actual player entity into a shared ent, then you now have to specify the view position every frame, which will also stutter in the same way.
If you're using a player in this way, then you should probably be using prediction code instead of interpolation code, however, DP doesn't fully support that, though I'm not sure exactly how much it doesn't support still.

LH, can you *please* add support for deltaed ents now? (#371, DeltaListen) At least if you've not already done so.

[something]

im not running it through prethink..

it sounds exactly as spike describes..

small steps for me..

[Spike]

make a note of the time when you received the last update, and the time before that.

Monsters are easy to interpolate, they have a fixed step rate. Unless they're freefalling in which case they'll never step but rather will tumble based on gravity/velocity.
Projectiles shouldn't be predicted, you should mark the start time and velocity, and project them forwards clientside. Grenades are trickier as you need to bounce them correctly.
The local player can be predicted (supposedly). The only interpolation is correcting for errors or steps, where the client caches a delta to be reduced over time.
Other players... yeah, good luck with those. They'll all move in random directions each frame and nasty stuff like that. Using velocities and error correction is probably enough here, to be honest.

[Sajt]

Monsters are easy to interpolate, they have a fixed step rate...

void() ogre_run2 =[ $run2, ogre_run3 ] {ai_run(12);};
void() ogre_run3 =[ $run3, ogre_run4 ] {ai_run(8);};
void() ogre_run4 =[ $run4, ogre_run5 ] {ai_run(22);};
void() ogre_run5 =[ $run5, ogre_run6 ] {ai_run(16);};
void() ogre_run6 =[ $run6, ogre_run7 ] {ai_run(4);};
void() ogre_run7 =[ $run7, ogre_run8 ] {ai_run(13);};
void() ogre_run8 =[ $run8, ogre_run1 ] {ai_run(24);};