Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement a CVar for toggling the bunnyhop cap. #1601

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

YaLTeR
Copy link

@YaLTeR YaLTeR commented Mar 8, 2015

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).

@treetoon
Copy link

treetoon commented Mar 8, 2015

Great implementation, now we'll just wait and see what happens.

<:

@seritools
Copy link

I'd love to see this merged!

@HARDSTYLEBG
Copy link

I support this !

@sndrec
Copy link

sndrec commented Mar 8, 2015

Complete support from me.

@SpiderWaffle
Copy link

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.

@kriswema
Copy link

This has to be merged.

@Margen67
Copy link

I support this.

@arianon
Copy link

arianon commented Mar 10, 2015

I support this as well.

@Freeman-AM
Copy link

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.

@PJC-UK
Copy link

PJC-UK commented Mar 10, 2015

Supporting!

@HARDSTYLEBG
Copy link

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?!!

@darealshinji
Copy link

Supporting this too. Valve needs to merge this ASAP.

nekonomicon added a commit to nekonomicon/hlsdk-xash3d that referenced this pull request Jul 5, 2017
dlls/player.h Outdated Show resolved Hide resolved
@2010kohtep
Copy link

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.

@YaLTeR
Copy link
Author

YaLTeR commented Aug 4, 2020

Rebased and updated to better match the HLSDK code structure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet