Elevators crushing player/monsters about vkquake HOT 23 CLOSED

Time ideally should be integer fixed point, but I never got around to changing this everywhere.

from vkquake.

Added commit 58f5bbe from @andrei-drexler , thank you very much !
The infamous Peril Elevator is now fixed.

I'm keeping both host_phys_max_ticrate and #define MAX_PHYSICS_FREQ (71.9990) as extra seatbelts.

from vkquake.

Thanks for copying the issue here!
Since then I have tried to look around the code myself but since it's my first foray into a real game engine I don't think I stand much chance of fixing this myself. But hey, at least I'm learning :)

My hunch was that it was some kind of float precision issue around the SV_PushMove method but I've not yet looked up how I can even debug that. And comparing the code with QSS and Ironwail now I'm not so sure that's the cause of the issue

from vkquake.

Might be related. Noticed something similar in rm_resurgence (re:Mobilize 1.2), when taking the lift up from level 0 to level 1 in the trident building, Lift will reverse the direction shortly before reaching the destination. However, the player suffer no damage. You need to jump shortly before this happens or disable renderer/network isolation host_maxftp <= 72

Lift has 2 more levels, and they do work fine though. Can't reproduce with ironwail.

from vkquake.

@j4reporting I've tested it and indeed it is the same issue.
I have located the culprit line of code, it's in the calculation of host_frametime in _Host_Frame (in host.c)

I don't get what vkquake is trying to do here but when I replace that line:
host_frametime = sv.active ? (listening ? q_min (accumtime, 0.017) : host_netinterval) : accumtime;
with (the calculation from Ironwail and QSS)
host_frametime = q_max(accumtime, host_netinterval);
It fixes the issue with elevators. Not sure what doing this breaks though...

from vkquake.

Thanks @Placo for this find. Alas there has been some significant host.c changes in vkQuake which make it diverge from both QS and QSS from which it picks up some change or other.

For instance, that particular line you picked points on a change by @temx: d56b859

I'll test your suggestion and try to understand what this commit does..

Another thing I wanted to test, is adding a CVAR to always force the physics to tun at the fixed rate = 72 Hz, i.e. which effect is the same as host_maxfps N where N is either > 72 or 0 (infinite), i.e. forcing host_netinterval= 1/ 72.f whatever the fps.

The question is rather : is there any desavantage at runing the physics at a fixed rate, irrespective of the host_fps ?

from vkquake.

Another thing I wanted to test, is adding a CVAR to always force the physics to tun at the fixed rate = 72 Hz, i.e. which effect is the same as host_maxfps N where N is either > 72 or 0 (infinite), i.e. forcing host_netinterval= 1/ 72.f whatever the fps.

The question is rather : is there any desavantage at runing the physics at a fixed rate, irrespective of the host_fps ?

Nevermind, it breaks things 1 side, while fixing the other...

About the given examples:

for example I've had it occur on the elevator in the start map of Quake Brutalist Jam 2 (a very fast elevator down)

• I've got that case, if i run host_maxfps 0 while my usual host_maxfps 58 is OK...

Peril : the long, slow, elevator down at start.

• I've got that case, if i keephost_maxfps 58 while host_maxfps 0 mostly fix it...

@Placo So 2 exact opposite cases I'll test vs. your suggestion when I understand what it does.

from vkquake.

Another thing I wanted to test, is adding a CVAR to always force the physics to tun at the fixed rate = 72 Hz, i.e. which effect is the same as host_maxfps N where N is either > 72 or 0 (infinite), i.e. forcing host_netinterval= 1/ 72.f whatever the fps.

Pushed a commit for a new CVAR host_phys_cst_ticrate [0 - 72] to have this as an experiment, default = 0 unchanged behaviour.

from vkquake.

Another thing I wanted to test, is adding a CVAR to always force the physics to tun at the fixed rate = 72 Hz, i.e. which effect is the same as host_maxfps N where N is either > 72 or 0 (infinite), i.e. forcing host_netinterval= 1/ 72.f whatever the fps.

Pushed a commit for a new CVAR host_phys_cst_ticrate [0 - 72] to have this as an experiment, default = 0 unchanged behaviour.

won't this break physics when host_maxfps <> host_phys_cst_ticrate?
host_maxftp {1-72] does this already. The engine moves/rolls forward physics each frame by its frametime i.e ~16ms for 60Hz.

you can try vanilla quake or QS what happens with higher values for host_maxfps. QS will print only a warning that things will break but does not have implemented the renderer/network isolation that keeps the physics at save frametimes.

from vkquake.

just noticed: the elevator arrives on level 1 in rm_resurgence in a coop game ( one player connected ),

from vkquake.

host_maxftp {1-72] does this already. The engine moves/rolls forward physics each frame by its frametime i.e ~16ms for 60Hz.

Yeah you are right, a better name would have been host_phys_max_ticrate . The only usefulness is to experiement something like a slow physics update like 35Hz (like Doom , why not) with for instance unlimited fps.

Not very usefull indeed, at the end I'll probably revert this.

Not tested @Placo patch yet.

from vkquake.

Not tested @Placo patch yet.

reverting the remaining bits of d2c34b3 in host.c , already partly reverted with 25cebeb , brings this closer to QSS and ironwail again. lift in rm_resurgence is not bugged, and lift in peril works with vsync enabled like in ironwail.

there is at least one other commit, that might depend on this reworked version, though ( dedicated server ).

CVAR to switch between different codepaths? kiddin'

from vkquake.

CVAR to switch between different codepaths? kiddin'

Hey thanks for testing for that roolback. But all those modifications were done in good faith to improve things I suppose, so I would rather try to understand and reproduce the problem on the current to actually fix it, before considering reverting.

Now do not hesitate to publish that change on a branch or through a PR of yours so we can experiment (and critisize:)

The problematic part of this investigation it is that the interlocking of farmerate, simulation time, and real time elapse in general : it means the moment you execute that in a debugger or worse, stops using a breakpoint, the beahaviour is modified.

Now for testing if we stub Sys_DoubleTime () to control Time (Whoa...) increments, that would ease the debugging : stop and run time arbitrarily.

Another thing to test for fun : always make Sys_DoubleTime () increment by an integer of of a minimal quantum value of 1 ms (for instance) to see what happens. I feel like having a discrete time source would make the computations less prone to float roundings along the way.

from vkquake.

FYI I've reverted my previous experiments from master, and push an experimental branch for us to sandbox : https://github.com/Novum/vkQuake/tree/issue_700_experiments

From Master:

• Added CVAR host_simu_time_quantums_per_sec : the time driving Host_Frame(time) is quantumized by amounts of host_simu_time_quantums_per_sec. 0 means 'realtime' as before.

from vkquake.

Right @j4reporting I'm lacking time (ah!) to really tickle all this, so I'll gladly take your PR, if you have any.
This will deserve a new 1.31.1 release as well.

from vkquake.

I've continued some experiments around Host_Frame(time) including somewhat close to andrei-drexler/ironwail#312 but nothing works right, the bench being the blighted Peril elevator down, working OK with QSS. (it was developped with it)

Alas bringing QSS changes graviting around Host_Frame() or SV_Physics() brought nothing of value or so it seems.

from vkquake.

maybe someone with more insight could comment what's happening here?

The liff in rm_resurgence ( re:Mobilize mod version 1.2b ) will work with slight less precision for host_netinterval.
The culprit seems to be the door in the elevator shaft blocking access to the basement from floor 0. The door will open when player gains access to the basement through another entrance.

this is also reproducible with QS, QSS and Ironwail with command host_framerate.

override host_frametime with command host_framerate ( default = 0 )

setpos  2662 -2601 -1767   0  0  0     ( teleports you to the basement of the buildung )

host_framerate 0.013888     => lift reverts on the way up      floor  B-> 0        
host_framerate 0.0138888    => lift reverts on the way down    floor  1-> 0  and floor 0 -> B
host_framerate 0.01388888   => lift reverts on the way up      floor  B-> 0  and floor 0 -> 1   
host_framerate 0.013889     => no issues    => 0.01388    with some safety margins 

so something like host_netinterval = floor ( 100000.0 / 72 ) / 100000; in Max_Fps_f() prevents the platform from reverting its direction.

vkQuake's timings are simply too accurate, because with host_maxfps 72 values for host_framerate are ~ 0.013888 and the lift will also bug out with renderer/network isolation disabled.

Why does the platform revert its direction? Is it just a combination of the speed of the platform and the retracted door? Are we already trigering the physics bugs that renderer / network isolation is supposed to prevent?

from vkquake.

Thanks @j4reporting for your investigation !

I've committed the small change above, according to your findings. With this:

• rm_resurgence ( re:Mobilize mod version 1.2b ) in the use case above is now OK with host_maxfps > 72
• Quake Brutalist Jam 2 Start map elevator is also OK with host_maxfps > 72, no longer hurts the player wihile ascending/descending.

Peril Elevator is of course beyond saving :)

from vkquake.

I didn't knew that QBJ2 was also bugged.

For peril ( at least the first elevator ) you would need to bring back the host_phys_cst_ticrate cvar and set it to 50 ot 51 ( again with less precision in case of 51).

you can reproduce this also in QSS again with host_framerate

host_framerate 0.0196078        bugged 51 FPS
host_framerate 0.01960          ok
host_framerate 0.02             50 FPS

Or bring back the old less frame rate consistent physics suggested by @Placo and make it available by a new CVAR (no archive).
Not sure if you really want to go there...

QSS and ironwail (vsync enabled) works only because host_frametime = accumtime and it seems most of the time accumtime is in the range of 0.02 - 0.019

from vkquake.

For peril ( at least the first elevator ) you would need to bring back the host_phys_cst_ticrate cvar and set it to 50 ot 51 ( again with less precision in case of 51).

Ah yes, I've noticed this before. Fine, I've brought back host_phys_max_ticrate (no archive, default = 0 = disabled) for those edge cases :)

Anyway, I've noticed that the Mjölnir elevator at MJ4M3 start no longer hurt the player when host_maxfps > 72 with commit debcaca.

from vkquake.

I have the impression that MAX_PHYSICS_FREQ (71.9990) is a bonus overall. Need to test more, but with this tweak the player's movement feels more responsive. With MAX_PHYSICS_FREQ(72) there seems to be some kind of delay/lag sometimes. Hard to describe. I hope I'm not just imagining it.

from vkquake.

I think we can close this now. Thanks @j4reporting @andrei-drexler (and others) for the help !

from vkquake.

Hello, sorry for reopening this issue but the fix only works on vertical pushers.
Peril's "blimp" map is still bugged because monsters are standing on flying platforms that are moving up/down and to the sides and are crushed by them (not the big ship/first wave of enemies) but some waves later in the level.
Another good test is the start of Peril's "mountain" level. The cable cars used to crush the player, now it's fixed unless you stand against a wall (the cable car's movement is not just up but also to one side), Also now the health kit and ammo in the cable car clip though it near the start and fall to the ground.

I'm not sure trying to wiggle each edicts standing on a pusher into position with each increment of its movement would be a good solution though...

from vkquake.