ValveSoftware
Implement a CVar for toggling the bunnyhop cap.
Implement a serverside CVar mp_bhopcap which controls the presence of the bunnyhop cap and defaults to 1 (bunnyhop cap enabled) so that no existing server setups have anything changed on update. If set to 0, the bunnyhop cap will be disabled. In singleplayer the bunnyhop cap is always disabled because it has no use there and in no way affects the casual gamers.
Right now many server admins who chose to remove the bunnyhop cap have to do it through the use of specialized server plugins which isn't an optimal solution since the clients get the "Bunnyhop cap lag" (the clientside prediction always assumes that the cap is present and reacts accordingly) which is very annoying to say the least.
In this pull request the value of mp_bhopcap is sent to clients so the clientside prediction can take the presence or absence of the bunnyhop cap into account.
We started a petition to gather support for this feature to be implemented (or this pull request accepted).
This really should have been done when 1.1.08 was first released some 13 years ago. It was a mockery to all the communities and every game ran on goldsouce that wasn't CS, like a slap in the face.
Furthermore, the way the cap was designed, setting speed over 170% to 110.5%, has no bearing towards gameplay outside of CS, if even there. This lead to a plague via the bhop.dll hack which would prevent your client from jumping until just under 170%. Really it should deduct a portion of your speed down when jumping over 170% like fortress forever implemented designing towards desirable gameplay, not brickwall set you back to 110.5%.
I fully support this.
Valve reworking on Half-Life is a dream guys... There is many High Priority bug more important than this that are waiting since 2013. So thinking that they will implement a feature is a bit a dream. Sadly.
Come on whats up with this?! it is already done just get it in to the main code and make it DISABLED by default whats wrong?!!
It would be better if you replace CVAR_GET_FLOAT with a pointer to the mp_bhopcap variable, since using the CVAR_GET_FLOAT function that is called every frame may adversely affect performance.
Sorry for bumping this PR, but since this topic has been discussed by gamers and speedrunners for years and shawns recently has been started updating it, I couldn't just ignore it.
@shawns-valve, could you please look into this PR and push these changes to all GoldSrc games if possible? I think this will be not a trouble since these changes are server controlled and the default cvar value will be in favor of the limit.
I'll note some features in other game series:
- In Counter-Strike, in pm_shared code,
pmove->fuser2is used as stamina (https://jwchong.com/posts/counter-strike-stamina/), so for bunnyhop cvar it is necessary that it always remains reset or the logic associated with it is not used in code. - In Counter Strike: Condition Zero Deleted Scenes, in pm_shared code, a static variable is used in the
PM_Jumpcode, which is turned on when the player jumped and turned off when he finally landed. It is needed to reset all the player's speed after the jump. The logic associated with it should be not used if bunnyhop cvar enabled.
@YaLTeR, maybe it is worth adding server-side autobhop cvar to this pull request as well? Changes for this should be made in PM_Jump and CBasePlayer::Jump functions (the cvar should of course be disabled by default):
https://github.com/ValveSoftware/halflife/blob/b1b5cf5892918535619b2937bb927e46cb097ba1/pm_shared/pm_shared.c#L2554-L2555 https://github.com/ValveSoftware/halflife/blob/b1b5cf5892918535619b2937bb927e46cb097ba1/dlls/player.cpp#L1709-L1711
Modern versions of Counter-Strike (those on the Source engine) have the sv_enablebunnyhopping and sv_autobunnyhopping cvars for these purposes and they are disabled by default, so I don't see anything wrong with GoldSrc games having this cvars too.
