Items fall out of world about joequake HOT 5 CLOSED

Thanks for your findings. I tried to dig out why that line changed from host_frametime = 0.1 to host_frametime += 0.1 but didn't find anything. In fact, after measurements on 100m (simply straight walk to the exit) it is indeed 1 frame faster, since the server time doesn't start off from that extra frametime. At least this does not make every demo invalid, just having 1 unnecessary frame at the start.

from joequake.

I've done some investigation, and I think I've found the problem. (tl;dr: the frame time for the initial SV_Physics calls should be fixed to 0.1.)

In SpawnServer, both the vore and the SSG are loaded and their respective functions are called (monster_shalrath and weapon_supershotgun). When monster_shalrath is called, walkmonster_start is set as the vore's think function to be triggered randomly between 0.1 and 0.2 seconds in the future. When weapon_supershotgun is called it calls StartItem which sets PlaceItem to be called 0.2 seconds in the future.

The vore's think function (walkmonster_start) calls monster_teleport, which sets the vore to be non-solid (since it is teleported in and has to wait to be spawned).

The SSG's think function (PlaceItem) calls the builtin droptofloor. droptofloor does a downwards trace to in order to place the object on the floor. The function fails if the object starts in a solid which results in the SSG being removed.

The bug occurs when the SSG's think function is called before the vore's since in this scenario the vore is still solid and so the SSG (whose bbox intersects with the vore's) is removed.

I put some debug statements in SV_RunThink to work out which frames the think functions are called on. Here's the result:

ent_num=28 thinktime=1.2000000477 sv.time=1.0000000000 sv_frametime=0.1138890000 (sv.time + sv_frametime)=1.1138890000    not running think
ent_num=204 thinktime=1.1420270205 sv.time=1.0000000000 sv_frametime=0.1138890000 (sv.time + sv_frametime)=1.1138890000   not running think
ent_num=28 thinktime=1.2000000477 sv.time=1.1138890000 sv_frametime=0.1138890000 (sv.time + sv_frametime)=1.2277780000    running think
ent_num=204 thinktime=1.1420270205 sv.time=1.1138890000 sv_frametime=0.1138890000 (sv.time + sv_frametime)=1.2277780000   running think

entity 28 is the SSG, and entity 204 is the vore. The two frames are the SV_Physics calls in SV_SpawnServer. The equivalent code in QuakeSpasm fixes the frame time for these steps to 0.1. Making this change appears to fix the bug:

ent_num=28 thinktime=1.2000000477 sv.time=1.0000000000 sv_frametime=0.1000000000 (sv.time + sv_frametime)=1.1000000000   not running think
ent_num=204 thinktime=1.1893674135 sv.time=1.0000000000 sv_frametime=0.1000000000 (sv.time + sv_frametime)=1.1000000000  not running think
ent_num=28 thinktime=1.2000000477 sv.time=1.1000000000 sv_frametime=0.1000000000 (sv.time + sv_frametime)=1.2000000000   not running think
ent_num=204 thinktime=1.1893674135 sv.time=1.1000000000 sv_frametime=0.1000000000 (sv.time + sv_frametime)=1.2000000000  running think
ent_num=28 thinktime=1.2000000477 sv.time=1.2000000000 sv_frametime=0.2000000000 (sv.time + sv_frametime)=1.4000000000   running think

With a fixed frame time of 0.1, the SSG droptofloor always happens on the 3rd frame, and the vore hiding happens on the 2nd frame, avoiding the bug. This appears to be the same as OG quake, as well as QuakeSpasm, so seems like the right thing to do, but I'm not sure if it'll have any interactions with the cl_independentphysics logic. What do you think @j0zzz ?

from joequake.

Thinking about it some more, this extra time added at the start means that the first frame where the player has control is pushed back by 2 * physframetime, which would add the same amount on to any finish times

from joequake.

Fixed in commit 2fb0eb7

from joequake.

Also seen in sm222_mh where a vore spawns on top of the gold key, stopping it from appearing.

from joequake.