[BUG]: 25th anniversary update trigger_push entities are overpowered (scales with server FPS)

[Nomad7]

👉👈 Contact Details (optional)

n0m4d84 on discord

🤔 What happened?

The 25th anniversary update introduced/expanded this issue: ValveSoftware/halflife#3780

If the server is running at 500 FPS, the 'speed' value of any trigger_push entities in the map is multiplied by 500, resulting in hugely overpowered push entities. With fluctuating server FPS it isn't really practical to edit the speed value (by modifying the entity or running a plugin).

Is it possible for ReHLDS to essentially undo the change mentioned in this comment: ValveSoftware/halflife#3780 (comment) ?
Or somehow dynamically prevent the push strength from being multiplied?

Apologies if this is a bad ticket, feel free to scold me appropriately :)
Happy to approach this issue a more appropriate way, just point me in the right direction - so many maps are unplayable due to broken push entities unless servers run old versions :(

⚠️ Meta-information

Post-25th anniversary versions all appear to be affected by this issue

📄 Relevant log output

[di57inct]

rehlds is not meant to run with 25th hlds anyway. use steam_legacy hlds.

[Nomad7]

We are currently using old server versions because of this specific issue with push entities, but I thought support for current (post-25th) HLDS versions was planned / in progress - maybe I misunderstood the purpose of these tickets and the 25th-edition-support branch?
#999
#1106
https://github.com/rehlds/ReHLDS/tree/bugfix/25th-edition-support

[anzz1]

The 25th-edition-support branch is made wrong, I tried to explain to @stamepicmorg in the comments in #1106 why he is going all wrong about the HL25 support, but he doesn't understand and wasn't having any of it and marked my remarks as "off-topic". I don't know why he has edit rights to the project he clearly does not understand the fundamentals of, doing things that don't make any sense.

It's not correct way to proceed to create some from of frankenstein hybrid of the new and old branches.
Both the ReHLDS and its supporting projects like ReGameDLL_CS are reverse-engineered from the old engine the legacy branch.
And the binary is supposed to be matching to the original as you can see all the changes and fixes are #ifdef'd in a REHLDS_FIXES and REHLDS_OPT_PEDANTIC defines.

If you want to make anniversary version of ReHLDS that should be in its own branch and reverse-engineered from the anniversary engine not the legacy one. It seems that many people are missing this which in my opinion should be obvious, but refer to other decompilation / reverse-engineering projects to understand the problem.

In other words, you can't use this legacy decompilation and shoehorn some anniversary features into it, it will just make a mess. To make it properly, lot of things changed between the legacy and the anniversary engine, there would need to be a new decompilation from the anniversary edition to properly support it.

[hun1er]

@anzz1 What exactly do you mean by "mixing" legacy and anniversary code?
The HLDS stack consists of swds + GameDLL + HLTV and it's all decompiled and not mixed with anything.

The practical problem with "HL25 support" isn't adding anniversary engine features to ReHLDS. The real requirement is Steamworks compatibility: newer HLDS/Steam updates require the newer Steamworks/steamclient interaction.

So the only thing that needs to be done is updating Steamworks to a current version.
This was already implemented long ago in a separate branch, it’s just not merged.

[anzz1]

Yes, the current ReHLDS stack is decompiled from the legacy versions of all those.
Bunch of stuff changed in the engine (swds+gamedll) between the legacy and the anniversary engine, and a new decompilation is necessary for the anniversary version.
Meanwhile the legacy version works just fine, but if you want the new features a new decompilation is needed, instead of shoehorning some features randomly from the new engine.
This is why I said to refer to other decompilation projects since there is clearly a fundamental misunderstanding of how decompilations work.
That steamworks_v160 branch has nothing to do with the anniversary engine, except that the anniversary engine has a newer Steamworks API version. The Steamworks API is not the engine.

Or should I clarify further, the way steam content distribution has worked since Steamworks was introduced in 2008, is that a certain engine version is tied to a certain Steamworks API version, which in case of the legacy branch, and the 6153/8684 engine which ReHLDS' engine, is 1.60.88.17 which is this steam_api.dll and libsteam_api.so right here.

This is not only true for HLDS and Half-Life btw, but all steam games that use Steamworks which is pretty much all of them.
The headers and the library files are provided in the Steamworks SDK and then your application is compiled against that specific version of the API, you are not meant to "support" several API versions from one build of the application nor are you to change the steam_api.dll/libsteam_api.so to anything else than the one you compiled (and subsequently shipped) it with.

So while steamworks is not the engine, and you shouldn't be shoehorning new engine features from a engine that is yet to be decompiled, you also shouldn't be shoehorning "support" for a different steamworks version a different API that it never meant to ship with. A build is tied to a certain api library version, and a certain version alone, and again this shouldn't be anything new because this is how libraries have always worked. Sure there are some exception with system libraries esp in linux where there is a backwards-compatible versioning system but that is not the norm, the norm is that you compile against a certain library version, and that is the library you use. The fact that historically bad programmers caused "DLL hell" style things because they didn't understand how things are supposed to be done, didn't follow this and caused conflicts, doesn't meant that was supposed to happen.
At best you will cause confusion to the users and at worst you cause bugs and crashes when someone uses a mismatching API version, so the correct route is to support the one version that is supported by the engine, and tell the users to use that specific version.
In fact if there is to be an anniversary decompilation, that should then support the newer API version which shipped with the anniversary one and only that, because again you are supposed to use a specific version of the API.

And actually I think that the server not working and you getting the "procedure entry point SteamApps not found" error when trying to run rehlds with the anniversary branch steam_api.dll is a good, albeit accidental, feature, and not a bug. Because as far as I know, there isn't any mechanism to prevent accidentally using an older engine with a newer gamedll except the differing steam api version, which is a bad thing because as pointed out, lots of things changed between legacy and anniversary, and the versions mismatching would result in the engine and gamedll disagreeing in many fundamental things like entity limits, precache limits, packet sizes, etc. and who knows what else because we don't even know the total extent of all the changed things until the new branch has been fully decompiled and studied. Mixing versions would lead to crashes and all sorts of undefined behaviour.

So not including, "supporting" the new SteamApps interface to this old engine is the correct way to go, as is not including the steam_api libraries that can be found as reference in the public folder to the release, as this prevents the user from doing the error of downloading the anniversary branch and applying this legacy engine over it. The way it currently is, is correct, the user will receive the "entry point error" and then realize he should have downloaded the legacy branch instead to apply ReHLDS over.

Luckily the legacy branch works fine, and the new anniversary clients are backwards-compatible to servers running on the legacy engine and gamedlls. It is however, not the case the other way around.

I've tried to be as exhaustive as possible to make it as clear as possible so there wouldn't be any questions, but feel free to ask if something is still not clear.

TL;DR; Just use the steam_legacy branch for ReHLDS, it is fully compatible with both anniversary and legacy clients. The anniversary support cannot be shoehorned in, and a new full decompilation is necessary to create an anniversary version of ReHLDS.