Elevators (and ramps) that are inside a trigger_fog or other trigger that does a stuffcmd every frame defeats the movement smoothing.

I debugged it a bit and cl.onground was getting set to false after each stuffcmd, which disabled the smoothing, but I didn't track down how cl.onground is linked to the stuffcmd-ing. Quakespasm-Spike's new protocol avoids this, but I'm not sure what change is responsible. Do you know what's going on, Spike?

test cases:

jittery:

temp1 0 # enable the stuffcmds inside trigger_fog
map ad_swampy.bsp
notarget
setpos -67 1368 840
noclip


smooth:

temp1 2048 #this disables the stuffcmds inside trigger_fog
map ad_swampy.bsp
notarget
setpos -67 1368 840
noclip


you need to walk off the plat and step back on. Look at the floor (plat surface) to see the jittering. You might have to ride the elevator a few times to see it jitter, but the "smooth" case is always smooth. 

Ok, did a bit more debugging (quakespasm / protocol 666), and it seems the client gets a net message with just svc_stufftext, and no svc_clientdata. onground gets set to false on every received network message unless there is svc_clientdata in it, so that is how the stuffcmd causes the stairstep smoothing to be reset. Not sure about the bigger picture like why does PF_stuffcmd result in a standalone net message without a svc_clientdata?

I guess the best solution assuming qc changes would be to use fitzquake's built in fog interpolation over time, which would avoid spamming the network with fog changes. 

svc_clientdata is normally present in every single _unreliable_ packet (the exception being nop packets).
Unlike Quakeworld, in NQ all reliable data (like stuffcmds) is sent in separate packets. hence why you're getting a packet that contains only a stuffcmd. This is true even for DPP7 and QSS.

There really is nothing specific to stuffcmd here. there are many other ways to trigger small reliables without svc_clientdatas.


FTE/QSS's network protocol considers the onground flag to be part of entity state, and doesn't even use svc_clientdata any more.
I don't recall any particular reason why you can't just do similar, and set/clear it only on reception of svc_clientdata (and CL_ClearState). I probably ought to do just that in QSS. Flagging the player as offground can affect things like bobbing, but its better to make sure any such unwanted effects are disabled by map changes, pause, or whatever, instead of potentially breaking on random reliables. 

i changed it to 160 and it's smooth as butter now.

completely unrelated, my save file somehow got corrupted in the most bizarre way i have ever seen. all the detail prop models have been shuffled. lit candles are now shell boxes, unlit candles are fire, and fire is a health kit. the zombie knights are invisible except for their swords which attack you without any sort of animation, and the shadow axe is duplicated and doesn't disappear when picked up. everything goes back to normal when you change level or restart.

would be super impressed if someone could explain how this might have happened. have a look at it yourself if you're curious, there's even more weird shit like the fire that gets abducted into the ceiling immediately.

https://drive.google.com/open?id=1jFNJH3Z84DfK56GrWRFpNpm1sqHBJWQx 

Quake stores all the models in an edict list on map load (or was it game start, whatever). If you load a saved game in a different mod or different version, the edict list could be different amd thus the referenced model for each object is off from where it should be in the list. 

Thanks! That explains everything. set/clearing cl.onground only on reception of svc_clientdata sounds like a reasonable change.