Bunnyhop is still detecting false positives. I don't know how you can state that 0.1 or even 0.5 percent is a false positive, seems like a lot of people who sometimes can hit some nice hops while scrolling still get banned.

Bhop detection always comes down to probability/statistics. The figure I give is accurate, unless proven otherwise. I've gone over it several times elsewhere, repeating myself gets tiring.

One thing you have to keep in mind is this: Not everyone who Bhops with scroll or Macros get logged/banned. Logically, because of this, there will be people in that statistic that never show up in the ban logs. And you have to account for that.

Now, I don't know if the video shows you getting banned, or if this is your server and someone is complaining about their ban. So I'll address both:

If you are the server owner:

There is a reason why Bhop bans are set to 1 month by default. It's to account for those who are just unlucky.

Secondly, Bhop is not that big of a deal. Just because someone is cheating and using Bhop, doesn't mean they are doing much else.

I don't recommend setting Bhop bans to be permanent. However some server owners would rather not risk it, that's why it's possible to set the ban length from 1 month to perma.

The thing that catches cheaters the fastest is Bhop and Anti-Duck-Delay detections.

At the end of the day, you're going to have to make a choice here:

You can choose to be rather safe than sorry (Default 1 month ban).
Or you can choose that banning a few innocent people isn't worth it (Bhop detections disabled).
Set Bhop bans to be permanent and not care.

I recommend nr 2... Most server owners disagree with me and go with nr 3, and so the default settings are a middle ground (a compromise) . I fact, I don't recommend perma banning at all, as cheaters can change... Case and point: Me. I used to cheat, but no longer do... Second chances are a good thing. But again, most server owners disagree and don't trust people.

If you are the one who got banned:

Talk to the server owners if you feel your ban is invalid. I can't help you. ):

Another thing I sadly have to bring up, is that I've seen cheaters lie. There are a lot of closet cheaters, and they will happily lie when they are called out/banned. And trusting people when they say they are innocent is... The least fun part. The only person who can know for sure, is the one who got banned... Thus, I can't know for sure if a single individual is honest or not, and nor can anyone else.

P.S. Sorry if my reply isn't good enough or coherent, I've been drinking and am hungover. Sorry if my reply is thus rambly.

I'm closing this issue, as no further replies have been made.

And considering you haven't gotten unbanned from the server, it seems like this issue was raised as a complaint over your ban, rather than an actual problem. And as I replied above, I can't help you, complain to the server owners, not me.

You can link them to my reply (Link: https://github.com/J-Tanzanite/Little-Anti-Cheat/issues/47#issuecomment-718086232) where I say:

"There is a reason why bhop ban lengths default to 1 month (It's to account for those who are just unlucky)"
"I don't recommend setting Bhop bans to be permanent."

This is a server community issue, not a Lilac issue.

@J-Tanzanite making people able to chose after how many bhops in a row they ban could be a good idea. I personally use 15. It is still possible but so hard that it will more likely never happen. See these statistics:

bhops in a row | % chance to get it (doesn't take into account human mistakes and lack of skill/prediction)\ 10 | 0.0977% (~0.1%, not accurate enough, knowing that people try to bhop multiple times)\ 11 | 0.0488%\ 12 | 0.0244%\ 13 | 0.0122%\ 14 | 0.0061%\ 15 | 0.0031% (more accurate, still not perfect but 32 times more accurate than 10bhops)\ 16 | 0.0015% (64x times more accurate)\ 17 | 0.0008% (128x times more accurate: really accurate detection)\ 18 | 0.0004% (256x times, if you see a legit player banned, he is a god)

Thing is, you need to get the most accuracy while still being efficient, but 10 is clearly too low. What we must understand is that we will never be able to have 100% accurate bans for bhop, but the second method is A LOT safer than this one.

Afaik too playerinfo_jumps[] is incremented every time +jump is pressed. Thing is, if the user lets his space bar pressed, it will count like a lot of jumps. Idk if this is intended.

The "simplistic" method is less safe than the "advanced" one. To make the advanced one safer, change playerinfo_jumps[client] > 15 to playerinfo_jumps[client] > 8. Average +jump inputs when bhopping is 2-5 on 64 ticks. You shouldn't ban when 2*maxbhops is possible, aka it should be less than 10. I tested it with an injection type cheat and it detects perfectly.

Also you can up the max advanced bhop amount to 6 to prevent false positives. Anyways nobody bhops with space bar only, it's just so hard.

Line 1878: https://github.com/J-Tanzanite/Little-Anti-Cheat/blob/master/scripting/lilac.sp#L1878 has a redundant check

@rlevet Hey, letting you know that I will respond to this later, as today I am very busy (more than usual). I'll probably respond later today or tomorrow (hopefully).

Letting you know because I try to respond to questions, issues, pull requests etc as fast as possible, but today and tomorrow is hectic (Life is like that sometimes). Just letting you know I've seen your post and aren't ignoring you or am unaware that you've posted - because it sucks when you post something and get no response (Hate when that happens to me).

Ok, I got some time rn... I wanna preface by saying that... Due to the current situation (and my life being hectic atm), my answer may be a little rambly and I may misspeak a few times. Sorry about that, I still hope my answer makes sense. Thanks for your patience.

I'm not against the idea of adding an option so you can set your own BHOP limit, I would probably make it so you can't set it lower than the current limit, for obvious reasons.

"Thing is, you need to get the most accuracy while still being efficient, but 10 is clearly too low". I would have to disagree with this, since I arrived at this limit after 1 to 2 years of owning a server myself (several actually). Most cheaters who bhop stop short of 15, however a lot of them hit 10 bhops in a row. But there would still be plenty that don't hit even 10, but 10 was a fine compromise between accuracy and efficiency.

"What we must understand is that we will never be able to have 100% accurate bans for bhop". It makes me happy to hear someone else say this. :) Because a lot of people don't understand that Bhop detection is a matter of statistics and probability and not a perfect line in the sand.

"but the second method is A LOT safer than this one". I am assuming you are referring to the advanced bhop detection method here, being a lot safer than the simplistic one... Not quite. It's more efficient, catches cheaters faster and earlier, and a lot more cheaters who wouldn't ever do 10 bhops in a row - but it's not safer... I'll get to that bit.

"Afaik too playerinfo_jumps[] is incremented every time +jump is pressed. Thing is, if the user lets his space bar pressed, it will count like a lot of jumps. Idk if this is intended." This is intentional, and it's for a very specific reason. Cheats press +jump for exactly 1 tick, whereas a human rarely do so, in fact, like you later state, humans will tend to hold down +jump for a few ticks. This means that cheats will very often do 5 +jump ticks and 5 perfect bhops in a row, leading to a ban, whereas a human... Doesn't (or at least, it's very rare).

"To make the advanced one safer, change playerinfo_jumps[client] > 15 to playerinfo_jumps[client] > 8" ... "You shouldn't ban when 2*maxbhops is possible, aka it should be less than 10". Sadly, no. The reason why the max jumps is set to 15 and not 10, or even lower, is because of how cheats bypass SMAC's Bhop detection. See, SMAC won't test for Bhop if you press your jump key while you're in the air. So a lot of cheats will press +jump once they are in the air in addition to once they hit the ground. You can see this here: https://www.youtube.com/watch?v=uTkezrmNwzY

Some cheats seem to have this hardcoded into them. This is why you'll often see cheats that do 10 +jumps and 5 perfect bhops in a row. 1 +jump tick when they touch the ground, and 1 +jump tick while in the air to bypass SMAC. But to add to this, a lot of cheaters seem to also press their jump key while they are in the air manually. This would cause their +jump count to be above 10 while doing 5 perfect bhops in a row, so the +5 is a buffer to catch those cases as well. So no, setting it to 8 would make a lot of cheats which bypass SMAC's bhop check also bypass Lilac's bhop check.

As for the redundant check - I think you've misread the source a little. Don't worry, that part of the code is... Very counter intuitive... In fact, it's very ugly and can be very confusing. See, if the check inside the "if"s run, then it will "return"... Which means "don't ban". So in the case of simplistic mode:

if (bhops < 10)
    return; // We haven't done 10 bhops in a row, don't ban.

And in the advanced mode:

if (bhops < 5)
    return; // We haven't done 5 bhops in a row, don't ban.

// This "else if" only gets tested if the player
//  in question has 5 or more perfect bhops in a row.
// This is important to keep in mind!
else if (bhops < 10 && jumps > 15)
     return; // Don't ban.
/*
 * So if our bhop counter is less than 10 (say 5)
 *  and our ticks pressing +jump is larger than 15,
 *  then we don't ban.
 *
 * This means that if our jump counter is less than 15,
 *  and we've done 5 perfect bhops in a row
 *  (remember "if" statement above).
 * Then the "else if" statement is basically this:
 */
else if (1 && 0)
    return; // Don't ban.
/*
 * So we are NOT returning, we are not aborting the ban...
 * The code for banning will run.
 *
 * However, lets say we did 10 perfect bhops in a row,
 *  and our jump counter is 20.
 * That equates to this:
 */
else if (0 && 1)
    return; // Don't ban.
/*
 * So the only time the "else if" actually runs (And aborts the ban)
 *  is when we have done less than 10 bhops in a row,
 *  and we are spamming +jump.
 *
 * This means that our advanced bhop mode will always ban on the 10th
 *  consecutive perfect bhop
 *
 * So summarize, the advanced mode bans when:
 *  5 perfect bhops have been made
 *      and less than 15 +jump ticks have been made.
 *      (No spam).
 *  10 perfect bhops have been made.
 *
 * So it kinda reverts to the "simplistic mode" if the advanced check fails.
 */

This is why I think: "but the second method is A LOT safer than this one" is inaccurate. Because I think you're making the assumption it will only ever ban on the 5th bhop if +jump is less than 15, which isn't the case, it "reverts" to the simplistic method, just so bypassing Lilac's bhop check isn't the same way you'd bypass SMAC's bhop check... Just with more +jump spam.

To be perfectly clear here... This is not on you, that code is hard to read. It's like trying to make sense of this sentence: "You aren't sure you do not want to not reject no cakes being never delivered?". ... You can do it, but it's a mess.

One important thing to keep in mind is this, Bhop bans only last 1 month by default, because bhop detection comes down to statistics and probability. So if you are falsely banned, it's not permanent... ... Some servers sadly perma ban for Bhop, and there isn't much I can do there.

Lastly, I wanna say this. In an ideal world, I would set the limit to be 20... Or higher even. But as you saw in that video - it takes AGES before anything gets detected. ... Plus, In an ideal world - people wouldn't cheat in the first place.

Something that is worth considering however, is adding a ConVar so you can set your own limit, I quite like that idea of yours :)

Also, a bit shameless advertisement here... I am working on version 1.7.0, it's in the "restructured" branch, it has some new detection methods, better backtrack patch, source code reorganizement so it's easier to read and work with and some new exploit fixes. If it gets tested enough, it will move into the "development" branch and then finally get released.

Ty for your answer

Indeed my retarded brain thought (playerinfo_bhop[client] < bhop_max[BHOP_ADVANCED]) and (playerinfo_bhop[client] < bhop_max[BHOP_SIMPLISTIC] were the same check when they clearly aren't

Also I didn't know about this bypass, ty for learning it to me. I personally did a private version with some more checks to catch people trying to bypass these methods, but yea clearly it's a pain to figure out good methods and balance, and anyways autobhops are not that much of a pain. If they decide to bypass every check, they'll just finish rage quitting because it's not fun

Anyways i'm not a rly good dev so I trust you

But there would still be plenty that don't hit even 10, but 10 was a fine compromise between accuracy and efficiency.

On the first week of testing, 4 players got caught, including 2 legit trusted players. After I added my own version, one of my mods triggered it as well so, that really depends of your server type, skill and people's luck

That's why detection method based on X bhops in a row are bad. Ideal detection method are statistics one, which will deduct a % rate of bhops in a row and compare it to 'normal' numbers. If the player is getting 8-10 bhops in a row per map, and overall 2 times 10 bhops in a row a day, he's probably not legit.

Good luck with your new methods, and ty for taking some of your precious time for me 👍

I really felt a need to respond quickly here, because...

"Indeed my retarded brain"... You made a sensible assumption, the fact that it was wrong isn't on you at all! When you write code, you're supposed to write clear and concise code, and in a pattern that is easy to follow - not doing so will always lead to confusion and bugs. In this case, my check there basically broke every rule I've ever set out for myself... And it's... ... People who code well or are sane will not do what I did there, at all! So if anything, your assumption means that you're sane and not a bad programmer. That HAD to be said - it's not on you.

I should have changed that part long ago, but once you've written code and it works and is reliable - messing with it may lead to unintended bugs, and so I just... Never wanted to fix it. Breaking stuff for server owners is the last thing I wish to do, so it's just stayed that way for a long time, sadly.

"so, that really depends of your server type, skill and people's luck" very much so. It also depends on the actual game as well... TF2 and CS:GO are not the same, not only culture wise, but also play-style. Which is why in the Aimbot detector, there is a specific check to ignore pyro's flamethrower.

"That's why detection method based on X bhops in a row are bad. Ideal detection method are statistics one, which will deduct a % rate of bhops in a row and compare it to 'normal' numbers. If the player is getting 8-10 bhops in a row per map, and overall 2 times 10 bhops in a row a day, he's probably not legit." This entire paragraph is correct, I wouldn't say "x bhops in a row" are bad, but compared to frequency of bhops done over time, it is indeed worse, because the latter takes more information over time into consideration.

"and ty for taking some of your precious time for me" Not a problem at all, it's important to answer people when they ask questions or wish to discuss something :)

J-Tanzanite / Little-Anti-Cheat

Bhop ban complaint #47

If you are the server owner:

If you are the one who got banned: