Forward motion after level change

[Ronin4862]

Sometimes when transitioning levels (loading points) the forward motion is preserved even if I'm not pressing the "w" button. It has nothing to do with rebuilding node graphs. I checked.

[SamVanheer]

Any momentum you have while going through a level change will be retained. Are you referring to that, or are you experiencing some kind of acceleration?

Keep in mind that the game simulates a couple frames worth of physics when entering a level, it may still be working off of keyboard and mouse states as they were when you initiated the level change.

[Ronin4862]

Any momentum you have while going through a level change will be retained. Are you referring to that, or are you experiencing some kind of acceleration? Yes. Uniform motion. Like someone keeps pressing on the "w" button.

[SamVanheer]

Can you record a video so i can see exactly what happens?

[Ronin4862]

I'm afraid that's going to be a little tricky as it is random. What I can tell you is exactly what I did. I started a new game. Performed the experiment. Entered the room where the first headcrab is teleported in from the ceiling when you don't have the crowbar yet. There it happened. I was running and jumping when I entered that loading point and I continued to move forward even if I was not pressing the "w" button. Even pressing the backward button "s" did not stop this. I momentarily took a step back but I was "pushed" forward again until I hit the wall in front of me. After another second I regained complete control of movement. Hope it helps... Does it have anything to do with running, jumping and turning in mid-air?

[SamVanheer]

Are you sure you're not just being affected by a func_friction? The water on the floor in that room has it and will cause you to keep sliding for a bit.

[Ronin4862]

I don't think so... It also happened when running and jumping through the corridors that lead to the elevator that brings you to the "Office complex" map.

[SamVanheer]

If you can figure out how to reproduce it i'll look into it.

[Ronin4862]

Ofcourse. Leave this issue open for a week. If I don't return with a video you can close it.

[SamVanheer]

Were you using cheats when you encountered this issue?

[Ronin4862]

No. sv_cheats is 0. I was trying a speed run and I was running and jumping like crazy through the maps.

[Ronin4862]

It happened again in map c2a3 after passing through the loading point behind me (see picture). I could literally go back and forth through this loading point without touching the keyboard and the forward motion persisted. Even after going back through the loading point to the starting place shown in the picture.
I tried to record it but Alt+Tab-ing to start the video recording software stopped this behavior. Unfortunately it happened only once... I closed the game, deleted the node graph folder, reloaded the quick save but only got the small audio-video stutter due to rebuilding of the node graph so I can confirm it's not related. It appears that once it happens in a particular spot it will not repeat there ever again... Very frustrating... Besides the .nod and .nrp files what else is being created while progressing through the campaign? The answer might lie there...

[SamVanheer]

All of the maps you've mentioned have func_friction entities in them so i'm guessing it's somehow changing your friction.

Are you testing this with official HL Updated dlls or are you running your own build? Are you making any sort of modifications, using any console commands or custom binds that could be interfering in any way? What about server plugins?

[Ronin4862]

All of the maps you've mentioned have func_friction entities in them so i'm guessing it's somehow changing your friction.

Then why it happens only ONCE? According to what you say it should be repeatable.

Are you testing this with official HL Updated dlls or are you running your own build? Are you making any sort of modifications, using any console commands or custom binds that could be interfering in any way? What about server plugins?

I normally modify the code you provide to allow breakables to stay longer. But it doesn't matter. It also happens with your latest beta untouched and no exotic console commands or anything else.

My feeling is that it has something to do with "caching to disk" similar to the node graph I mentioned. Once you pass that spot and it happens it will never repeat. All I can say is try the two areas I mentioned. Run and jump and turn in mid-air like you would do in a speed run... Even If I can catch this in a video it wouldn't help you much. You would see me moving in a straight line like I'm continuosly pressing the "w" button...

[SamVanheer]

I'm unable to reproduce this myself.

Rename your HL updated mod directory and install it completely fresh, then try it again. If it does happen, try resetting config.cfg. Steam saves it to the cloud so you'll have to make sure it doesn't overwrite it with the original file.

This way we'll be sure there is nothing interfering in any way.

If it does still happen, add some logging code in the player movement code (pmove->Con_Printf) to see if the friction value is different.

If that's set to 1 the entire time then you should add logging code to PM_Friction to see if anything is going wrong there.

You'll have to debug it yourself because i can't figure this out without being able to reproduce it.

[Ronin4862]

I forgot to mention when you try this do it with a clean reinstall. Ok...you beat me to it. So you're telling me you never experienced this? I clearly remember happening with the vanilla HL way before you started this project.

[SamVanheer]

I've never experienced this as far as i can remember and nobody's ever mentioned this before.

Do you have a controller or other input device other than mouse and keyboard connected to your PC?

That's a possible source of errant movement inputs.

Otherwise you'll have to find a way to reproduce it reliably or debug it yourself.

[Ronin4862]

Can this be related? Running at >60fps I mean. https://github.com/SamVanheer/halflife-updated/issues/165

[SamVanheer]

I doubt it, but you can check it easily using fps_max 60 and fps_override 1.

Make sure to disable VSync with gl_vsync 0.

There's nothing more i can do. You'll have to either find a way to reliably reproduce the issue or track down the cause yourself.

I'd suggest putting in console print calls logging the various variables that can apply movement to the player and then tracing through the code to see where it's coming from. You should be able to narrow it down that way.

[speedvoltage]

Sometimes when transitioning levels (loading points) the forward motion is preserved even if I'm not pressing the "w" button. It has nothing to do with rebuilding node graphs. I checked.

The issue you're referring to is not specifically caused by change levels, but they are the most reliable way to reproduce that kind of issue since the game is essentially "paused" when loading. You can also have that problem whenever Half-Life has a hitch and freezes for a moment, regardless of the duration of said freeze. When the game resumes properly, it retains your last input active, even if you're not holding the key for it. The forward motion is the most common input key used, that's why that's usually the one to be stuck active until you press your forward key again, but it can happen with any other input, like firing your weapon, which can be stuck firing until you press the +attack key again.

The problem is that this issue is completely inconsistent and can't be easily reproduced. This type of bug, to my knowledge, doesn't happen extremely often, though, under normal gameplay circumstances, but if you're speedrunning, it's possible to run into that kind of bug more often.

[Ronin4862]

Yeah...this bug bas been there since forever. I was kinda surprised Sam didn't ran into it though...

[speedvoltage]

Could you list your system specs as a FYI? This type of bug is already rare and inconsistent, but it becomes rarer the higher your system performances are, only happening whenever the game freezes for a second before resuming.

[Ronin4862]

I never get freezes except at loading points (by design) or, if I play after a clean install, when the node graph is rebuilt. If the .nod and .nrp files are in place then only at loading points. The system is old but HL runs smooth as butter. CPU Intel Core i7 6700k 4.8GHz GPU GTX 980TI 2x4GB DDR4 3333MHz Samsung NVME SSD gen.3 Monitor Sony GDM-FW900 Mouse Razer Viper Mini Signature 8000Hz Windows 10 I play at 2328x1455 80Hz (it's a CRT monitor) with RivaTuner ScanlineSync which is basicaly vsync off with one tear line out of view so I get both the tear-free image benefits of vsync on and the ultra low input lag of vsync off. Hope this helps...

[SamVanheer]

It sounds like the engine is missing key release events so the key states aren't updated correctly.

The behavior of key input is described here: https://github.com/SamVanheer/halflife-updated/blob/38fff996b0e9841b8540e295758287bf12999b88/cl_dll/input.cpp#L64-L83

The engine tells the client when a key is pressed or released and the client updates the state accordingly. But if the game is frozen for long enough then Windows might stop sending input events to the game resulting in key releases being missed.

Unfortunately this isn't something that can be fixed in the SDK because the engine is responsible for most of this.

When you press a key the command bound to it is handled by the engine, for instance forward movement is the command +forward. The engine maps the key to the command and executes the command handler: https://github.com/SamVanheer/halflife-updated/blob/38fff996b0e9841b8540e295758287bf12999b88/cl_dll/input.cpp#L392-L396

The handler updates the key state.

A possible fix would be to have the engine check key states and manually executing commands to fix this issue but that would require the engine to know if the game is frozen.

Unfortunately this engine is too primitive to do long-running work like node graph generation while keeping the game active so freezes can happen.

All you can do is avoid doing anything that could cause a freeze. The node graph only needs to be generated after you've installed a new version of the beta so you shouldn't be encountering this issue that often.

I plan to remove the node graph removal behavior from the installer and instead bundle the graphs so it should stop happening altogether. But if there is anything else causing freezes then you should try to figure out what that is. It might be possible to fix other cases but i can't say that without knowing what the cause is.

[SamVanheer]

Node graphs will now be packaged with the installation so you shouldn't experience freezing while it's busy generating them anymore starting with the next release.