Add back an old bhop method
azalty opened this issue · comments
Please add back the bhop method which consists of checking if the bhop was made with only one jump input which lasts for one tick.
Count in how many frames the space input is sent, and if it's only sent once, for one tick, and on the exact good frame, add 1 to a counter.
Failing any of these conditions resets the counter to 0.
When the counter reaches 5, you ban them.
This method is 100% accurate and can't be replicated unless you have a 20 tick/s server. The higher the tickrate is, the more accurate this method will get, but I can assure you it can't be done on 64 ticks, even when purposely trying to trigger the method, unless you do +1000 sweaty attempts.
This method can only be triggered by injected cheats since most macros have a slight input delay of some sort and spam keys instead of timing them perfectly.
Yes, this method can easily be bypassed, but we can counter the bypass by allowing an extra jump input that lasts 1 tick in the air. It can also be bypassed, but trust me, it catches a lot of cheaters with an extremely high accuracy.
I personally run this method on a custom plugin of mine and it has never failed me (a verification for the delay between two bhops is needed though because when the roof is really near your head, bhopping with 1 tick jump inputs is really easy).
Yeah this is basically the old detection method that was called "advanced".
Ban on 5th bhop if jump ticks is less or equal to 15 (5 for bhops, 5 for SMAC bypass in cheats and 5 as buffer as some cheats act up).
The air-time check would actually be neat, and I think it should have been in Lilac from the start.
Currently, the old BHOP method (1 & 2 in lilac_bhop) has been reserved (and won't be used again in the future).
But we could just update the current presets to reflect this.
So here's the changes I'll make:
- Update the HIGH preset (the aggressive method that bans early) to this.
- Add an air-time check to avoid jump spamming when ceiling is low or player is stuck (but tick based, as floats get precision errors after the server runs for a long time).
- Fix a logging issue.
The reason why I'll make this change to the HIGH preset and not the others is that the HIGH preset is meant to deal with cheaters faster, but have a higher change of false positives.
Although this method is highly unlikely to get false positives, it's still the best place to put it.
I might also re-evaluate the other presets while at it.
Yeah, I noticed long ago that BHOP detections don't always log?
And looking at my code, I see the error I made.
If you ban on the first detection (max BHOPS in preset), then it won't log, as it doesn't log until the second detection.
I'll fix this issue as well.
I'll add these things to the developmental version tomorrow or so.
Thanks for the suggestion :)
(I guess I'll add that Azalty and I spoke privately about this manner before I replied here, if anyone is wondering; just working out the details).
Ok, so in my local version, I fixed the logging bug (I think, can't test atm).
And I added the air-time check (Which I also, can't test atm).
And I updated the default presets to these (I am not sure about these new values, so they are still subject to change):
- 4 = Low (Low chance of false positive, slow to ban).
- 5 = Medium (Default value).
- 6 = High (Bans earlier, higher chance of false positive).
So, to explain these values:
- Min = Minimum consecutive perfect Bhops to trigger a single detection.
- Ticks = +jump ticks allowed per min-bhop detection (-1 means disabled).
- Max = Maximum consecutive perfect bhops before instant banning (-1 means disabled, does not care for ticks value).
- Air = Minimum airtime in ticks for bhops to count (affects both min and max bhops. Airtime less than this resets bhop counter).
- Total = Amount of min-bhops before banning.
Although the air-time is displayed and stored in ticks internally, you change it through seconds (0.5 or 0.3 (default)).
Feedback about these proposed changed are very much welcome :)
Development branch now has the new code changes.
Closing this, as the development branch now has the old method added back.
If issues arise or an error is made, don't hesitate to reopen this issue :)