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
base: master
Are you sure you want to change the base?
Conversation
Great implementation, now we'll just wait and see what happens. <: |
I'd love to see this merged! |
I support this ! |
Complete support from me. |
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. |
This has to be merged. |
I support this. |
I support this as well. |
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. |
Supporting! |
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?!! |
Supporting this too. Valve needs to merge this ASAP. |
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. |
Rebased and updated to better match the HLSDK code structure. |
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).