Movement stutters

[mikota]

Movement in game has been sluggish/laggy/teleporty for me, both on Linux and Windows, both on FreeCS and FreeHL. I've been using the latest binaries from fte's website, didn't build from source.

stuttery.movement.mp4

Cvars/commands that have had an impact on making the movement more smooth (way less of these hitches/stutters):

• cl_yieldcpu 0
• cl_threadedphysics 1

Cvars/commands that I've tried but have had no impact:

• upping the cl_netfps
• cl_nopred 1
• pr_no_playerphysics 1

One thing that is interesting and might or might not be related is the output of sv_showpredloss 1. Setting that cvar spams this in the console:

yes: ignoring 13 msecs (anti speed cheat)

Around 3 or 4 times a second.

[eukara]

The engine doesn't handle prediction, the game-logic does. So the prediction related cvars not working is to be expected.

This is a bit of a long shot, but can you see if this older version of FTEQW from September 2021 has the same issue? (linux 64-bit glx binary)

fte-sep-2021.zip

[mikota]

Thank you. I couldn't find any the old FTE binaries online and was planning on building them to test. Unfortunately, with this version I get this while trying to open a listen server:

--------- Initializing Client World ----------
Client world initialized.
--------- Initializing Nodes Subsystem ----------
loading existing nodes for de_nuke
Nodes subsystem initialized.

../../../src/gs-entbase/shared/ambient_generic.qc:380: ambient_generic::ReceiveEntity
    isnew: 1
    flChanged: 1.67772e+07
    sample: 
../../../src/gs-entbase/shared/ambient_generic.qc:439: ambient_generic_ReadEntity
../../../src/client/entities.qc:94: Entity_EntityUpdate
../../../src/client/entry.qc:533: CSQC_Ent_Update

CSQC_Abort: 
Builtin 0:soundnameforindex not implemented.
CSQC is not compatible.
Shutting down csqc
Host_EndGame: csqc error

--------- Shutting Client Game ----------

This one is there as well, higher up in the console:

Spawning entities
...245 entities spawned (1 inhibited)

../../../src/shared/NSMonster.qc:210: NSMonster::FramegroupForAct
    actName: 3
    frameGroup: 0
    actName: 0
    self.modelindex: 246
../../../src/shared/NSMonster.qc:442: NSMonster::GetWalkSpeed
../../../src/shared/NSMonster.qc:728: NSMonster::AnimationUpdate
../../../src/shared/NSMonster.qc:862: NSMonster::Physics

SV_Error: 
Builtin 0:frameforaction not implemented.
Mod is not compatible.
Server ended```

[eukara]

I was able to test it on a map like boot_camp on HLDM. That one should not cause a crash due to missing builtins afaik.

[mikota]

Yes! The old binary doesn't have any of the movement stutters on boot_camp. Just to make sure, I loaded the same map in the latest FTE build and the stutters are back. So it indeed is the new(er? est?) FTE that's causing them.

[eukara]

Yeah. As stated on Matrix - sometime last year, Spoike went over the input code to enable for VR specific extensions and fixes. Ever since then, we've been experiencing timing issues and hiccups that are incredibly difficult to reproduce and track down. Sometimes I experience them - sometime I don't. It's a finnicky thing.

I've reported it to him in private before (but it gets lost among the other TODOs for the project because not everyone experiences it), but perhaps this issue will get the ball rolling on figuring out a proper fix.

[eukara]

I've talked to Spoike about this last night, and this is what's most likely causing it:
Since the VR inputs precision changes, it trips an anti-cheat measure (seen by sv_showpredloss 1) that is causing some movement packets to be discarded. Every time that trips with an anti-cheat warning, a movement packet has been discarded. He was aware of that being a problem right now with the VR extensions.

We're seemingly running ahead of the servers time (not ever meant to happen). If the client runs too slow or too fast, the server is supposed to attempt to correct it. Tweaking sys_clocktype can help on certain setups too (although it may cause issues on Win9x systems with longer uptime). Note that the gettimeofday setting may not deal with high frame rate (somewhere above 250 fps) well either.

Some CPUs and versions of Windows may cause CPUs to desync, which messes with clocks/timings in general.
Which explains why some people experience this more often than others, and some may not notice it at all.

I'll be on top of this and see if we can mitigate or work around these timing issues soon. Playing with the named cvars (or other time/precision related ones) might help for the time being

[VinnyVicious]

Is there a way to disable VR extensions?

[eukara]

_pext_vrinputs or something to that effect would disable the protocol extensions. but the anti-cheating measure will still get tripped.