Elevators in Opposing Force

[qazwsxedc16]

When going down certain elevators in opposing force, you will get stuck, requiring you to load save and jump right before the elevator reaches the bottom. This also occurs when sliding down the pipe at the start of pit worms nest. Reading old forum posts, it points to this being an issue with OpenGL and people saying that using DirectX bypasses the issue. That's not possible anymore.

[sinisterseed]

I don't think that's the cause of this, and it also doesn't seem to be specific to OP4 either.

I've had this happening to me in mods way more times than I can count, such as Visitors, and more recently Autonomy Lost, and that's both pre and post-25th Anniversary. It seems to be framerate related more than anything. If the framerate is too high, it's possible to sometimes get stuck on elevators while descending/ascending. It is especially frustrating if a follower NPC is involved, as they'll get stuck, too.

A lot of framerate related issues have been fixed throughout the years in the engine, but this is one of the more important ones that remains unfixed even after decades. The only way I could ever work around this issue, was to temporarily enable VSync until the problematic sequence is done and gone, as, curiously, capping the framerate alone doesn't fix the problem...

OP4 does also have some unique framerate related issues. Most notably, ropes lose their physics if the framerate exceeds... I think it was ~70fps or so. Most curiously, mods like Field Intensity managed to fix this problem, somehow, but it remains unfixed in the base game.

[0Ky]

I can confirm the player in Opposing Force can get stuck on elevators even with 100 FPS, the same issue occurred jumping on a headcrab.

Exe build: 19:06:31 Oct 7 2024 (10210)

headcrab_stuck.mp4

elevator_bug.mp4

^{* Unmute the video to hear audio feedback from the bug.}

I came across these bugs organically while playing the game, without deliberately trying to look for bugs.

Edit: The same issue occurs on HL as well, this issue is not specific to Opposing Force:

headcrab_bug_hl.mp4

[sinisterseed]

Edit: The same issue occurs on HL as well, this issue is not specific to Opposing Force:

Yes, as I mentioned in my other comment, it's an engine issue, it happens in a variety of mods as well regardless of what they use as base. I'm unsure of what the framerate limit for the elevators is, though, may as well be 60? The only way I could work around this bug was by enabling VSync, but I'm not entirely sure what the framerate limit itself needs to be.

I'm bringing that up because the framerate cap alone doesn't fix it from my experience. That being said, OP4 does have some unique issues as well, like the aforementioned ropes. They also break above ~70-72fps, but this time, the framerate cap alone fixes them.

Even more peculiar is that this one might not be an engine bug, I noticed in the changelog for the latest version of Field Intensity that they somehow managed to fix it in their mod. No idea how they achieved the result, however, but it's very interesting to see that mods could do that.

[0Ky]

I'm unsure of what the framerate limit for the elevators is, though, may as well be 60? The only way I could work around this bug was by enabling VSync, but I'm not entirely sure what the framerate limit itself needs to be.

Once stuck on the elevators with 100 fps in Opposing Force, reducing fps_max doesn't unstuck the player. However, if the player has below fps_max 58 you're unable to get stuck in the first place, the value could vary for different elevators.

OP4 does have some unique issues as well, like the aforementioned ropes. They also break above ~70-72fps, but this time, the framerate cap alone fixes them.

I found the ropes break exactly at fps_override 1;fps_max 143.

Even more peculiar is that this one might not be an engine bug, I noticed in the changelog for the latest version of Field Intensity that they somehow managed to fix it in their mod. No idea how they achieved the result, however, but it's very interesting to see that mods could do that.

That's because the rope implementation isn't part of the engine itself, it's where the server-side game logic resides (gearbox/dlls/rope.cpp). The rope simulation, physics integration and force application all live in the mod code, the behavior is completely controlled by the mod, not the engine. The fix can be found in the halflife-unified-sdk by @SamVanheer.

[sinisterseed]

Replying to #3942 (comment)

That's some very useful insight, much appreciated.

I could swear the framerate cap for the ropes was lower, though, I recall revisiting OP4 a few years ago and getting stuck for a while at a section with electrified ropes, which only fixed themselves when I capped the framerate somewhere between 70-80fps. Perhaps it's only been a while and I'm forgetting the exact values.

As for the elevators, no, my point there was not getting "unstuck", but rather avoiding it in the first place. That's quite a low frame rate to avoid getting stuck on them, a bit below 60, of all things. It's awesome that a lot of physics related issues were fixed throughout the years, but this one remains and it's quite visibly very impactful (if it has not perhaps even worsened, as I have never encountered the bug below 100fps in the base titles?).

Field Intensity, that's quite a fascinating point, I wasn't aware of the fact that they were server-side implementations there, but that at least allowed the mod to avoid the issue that the vanilla OP4 ropes had in the first place, wow.

[Diegoparedeshd1]

I have always played with the default value that comes with Opposing Force and Blue Shift which is 72 fps and I have never had problems with the elevators.

[Diegoparedeshd1]

Half-Life 1 base was initially limited to 72 fps by default on Steam and won version, but then in the 2010-2011 Steampipe update I think they changed it to 100 fps by default.

[sinisterseed]

Half-Life 1 base was initially limited to 72 fps by default on Steam and won version, but then in the 2010-2011 Steampipe update I think they changed it to 100 fps by default.

2013*, to be precise, that's when SteamPipe hit. 2010 was back when HL2 and a few other Source games were moved to the Orange Box engine branch (and remained quite broken for a good while as a result, lol).

Nonetheless, I think you're right. When SteamPipe came, it also modernized the renderer a bit, which made the game run worse on slow computers, thus resulting in Valve making a toggle for a lower quality mode (which was eventually removed with the 25th Anniversary update), as well as removing D3D, which was reportedly too old, unmaintained, and it was also very easy to make cheats for it.

Anyway, coming back to this, I think this issue worsened over time. Years ago I remember playing the HL1 series on different branches at ~100-300fps and never had an issue getting stuck on elevators and enemies in the base games (though OP4 ropes losing their physics at high framerate was always a thing), but I did have it happen to me in a few mods, such as Visitors, or Point of View (and most recently, post-25th Anniversary, in Autonomy Lost).

So I suspect there might have been a regression at some point, but when exactly and how, I cannot tell.

[Diegoparedeshd1]

Replying to #3942 (comment)

Yes, I remember playing it when it came out on Steam in 2004 and the game was limited to 72 fps by default in addition to having forced vsync by default, but then when the Steampipe update came out they changed the limit for Half Life 1 to 100fps in addition to the option to activate and deactivate vsync, but referring to the topic of this post, for some reason the game was initially limited to 72fps, I suppose it was because they knew that the game did not like high fps

[sinisterseed]

Yes, I remember playing it when it came out on Steam in 2004 and the game was limited to 72 fps by default in addition to having forced vsync by default, but then when the Steampipe update came out they changed the limit for Half Life 1 to 100fps in addition to the option to activate and deactivate vsync, but referring to the topic of this post, for some reason the game was initially limited to 72fps, I suppose it was because they knew that the game did not like high fps

VSync was forced? I'm not sure that's accurate. I distinctly remember the game always tearing pre-2013 at high framerate, so I'd be surprised if that was true at one point. I've also played through the WON version once or twice.

Regarding the FPS cap to 72, I had to double-check something, but it seems to confirm my suspicion. It was set to 72 originally because it was likely a carry-over from the Quake engine, which, as we know, GoldSrc is a fork of. In the Quake engine, physics start breaking if the framerate exceeds 72. This was never fixed in the original engine (I'm not counting the new remaster), but various source ports, notably vkQuake, achieved this by decoupling the rendering from networking -> Novum/vkQuake@ffc9adf

Why has GoldSrc not done this yet, is a mystery to me. That being said, I was able to track down when exactly the cap was raised from 72 to 100 on HL1's Update News page on Steam. It was shortly after the SteamPipe conversion where a series of updates came through, fixing a plethora of issues that got introduced, where "fps_max" returned after seemingly disappearing (?), but raised to 100, while "developer" was replaced by "fps_override".

It wasn't the brightest idea considering that some notable bugs still linger regarding high framerate. So this job remains unfinished in GoldSrc, even after two decades. Here's the update, it landed on February 15th 2013, in the Beta branch for HL1 and CS 1.6 -> https://steamcommunity.com/app/70/eventcomments/1631915072540171842?snr=1_2108_9__2107

Throughout the years, various improvements and fixes have been made, such as those for NPC turning speed and more recently pushable objects, but it's still not enough (maybe because they're also fixing symptoms, and not the root cause?). I also noticed this PR recently -> #3668

Even then, as demonstrated, the bug might still occur, but its rate of frequency has been drastically reduced and the player no longer simply gets stuck in place, it's more like bumping now - at 900fps no less, that's all the frames you'll ever need!

I hope that PR and the elevators eventually get merged/fixed sooner rather than later, they're two important issues that have no business staying like this after such a painfully long time. And the same goes for the ropes in OP4, especially now that a working fix has been found, and is being used by various mods.

I get it that GoldSrc is not the main focus for Valve anymore, but come on, especially if contributors have conjured up the fixes for you, and they've been tested against regressions. And the less said about the improvements brought to HL1 in the 25th Anniversary update still missing from BS and OP4 to this day, the better.

Those games have historically lagged behind HL1 and received noticeably less attention and care - for instance, I still remember the days when Blue Shift had HL1's ORANGE HUD. And the crosshairs never were fixed, they're orange to this day, instead of blue...

Edit: Addendum regarding VSync: "gl_vsync", at least, was definitely a later addition to the engine. I did a bit of research and stumbled upon people trying to enable VSync in what seems to be a WON version of the game. The CVAR is simply missing: https://www.reddit.com/r/vintagecomputing/comments/rwm9z0/can_someone_help_me_the_console_in_half_life_isnt/

It came later with engine updates, but can't pinpoint the release. We'd need a complete changelog of all updates ever released to track its introduction, the oldest update I can find, dates back to early 2013 when HL1 came to Linux and macOS, while D3D was removed.

[Diegoparedeshd1]

Replying to #3942 (comment)

But I played the first versions of Steam and the Won version too, and the game was limited to 60fps, that is, 60hz, and the only way to get up to 72fps was to disable vsync from the graphics control panel.

[sinisterseed]

Replying to #3942 (comment)

But I played the first versions of Steam and the Won version too, and the game was limited to 60fps, that is, 60hz, and the only way to get up to 72fps was to disable vsync from the graphics control panel.

I see. If that is the case, then perhaps, at first, it was forced on an engine level, there are plenty of older games that used this method and having to force disable it in the driver's control panel to get rid of it. And even nowadays some games still do it, and disabling VSync sometimes breaks them in different ways.

This would not deny my findings from above, and it would explain why there was no CVAR, if VSync was always on. But as I said, I'm just skeptical of that, because I've played those games for half of my life, and at no point have I had a tear-free experience, which should have been the case if VSync was enabled, but be that as it may.

[rbar1um43]

Try setting clockwindow 0. It fixes elevator bug.

[0Ky]

@rbar1um43 Tried and it didn't help. fps_max 100;fps_override 0;clockwindow 0 still stuck.