[CSS] Banning legit bhoppers about little-anti-cheat

[J-Tanzanite]

I've had this discussion several times now, and it's tiring repeating myself. :(

Bhop detection always comes down to probability and statistics, it's not a perfect "line in the sand" you can draw... Because that's impossible. There is no perfect solution.
Not only do you have to choose what is reasonable and what isn't, but there's also a tradeoff between accuracy and speed.

If you make it super accurate (very few false positives), you end up making it slow, which means very, very few cheaters actually get banned.
Or you can make it fast, but less accurate.
In addition to this, you then also have to consider how cheats try to bypass Bhop detections, which makes things even more "fun".
I chose the latter after a year or two of analyzing players who would bhop, cheaters and legits.
Bhop bans default to 1 month for a reason (to account for those who are unlucky).

The only way you could make it "not broken" and never have false positives would be to nerf it so badly, it never bans anyone, not even cheaters.
Again, this comes down to probability and statistics, you have to draw the line somewhere, and no matter where you put it, it's never going to be perfect... Never.

I recommend giving this entire discussion a read, as it goes more into details, and it in general gives you a better idea as to what's going on: #47

---

There are some more positive news however, version 1.7.0 is being worked on.
And because someone asked for more customizability when it comes to Bhop - it's coming... Eventually (Might have to delay that to version 1.8.0 - we'll see).
The default settings will remain default, because it's the most effective with very few issues for most servers (Again, repeating this, Bhop bans are 1 month by default to account for those unlucky).

And Macro detection is being added, which would solve some of the problems, but not all... Again, it comes down to probability and statistics, it's impossible to have it be perfect.

---

As for the current version (1.6.1), there are two things you can do to mitigate the problem (It doesn't solve it, but makes it more accurate):

1. Set the ConVar lilac_bhopto 1 instead of 2, which makes it worse at detecting cheaters, but fewer false positives.
2. Disable bhop checks.

The second one may seem like an admission that there is a problem, but not really. Because again, it comes down to probability and statistics, there is no perfect solution when it comes to Bhop detection.
If you wish to never have false positives, then you can't even run VAC.

But Bhop is the only detection type that is extremely tied to probability, disabling it would makes false positives a lot more rare... But at the cost that most cheaters get banned for Bhop before anything else, and sometimes, that's the only thing that gets them banned.

Again, I do plan to add a third option, if not more, which would allow for more customizable options.

[azalty]

1. Set the ConVar `lilac_bhop`to 1 instead of 2, which makes it worse at detecting cheaters, but fewer false positives.

We already discussed about this but the first method is actually the less accurate one and the second method that checks +jump inputs is safer, so no, according to me, changing this parameter won't change that much.

The default settings will remain default, because it's the most effective with very few issues for most servers

False, depending on the gamemode you play. I have a jailbreak/ba_jail server and these false positives happened 2-3 times a week. Ofc there were accurate detections but one of my trusted mod triggered it as well as some trusted players. You can always argue that we cannot trust 100%, but after repeatedly trying to do multiple bhops for 10 mins and succeeding (resulting to a ban) and doing that in one go is different

Anyways i'll stop here because it's true, there's no perfect way and the best way would be to see over time if the person can kinda consistently hit a huge amount of bhops.
Best thing to do imo is to disable bhops detections until you can raise the values, or find another way.

I don't like banning innocent people. I feel like every ban should be 100% trusted, and that doesn't apply to bhop detections (except the 2nd method which is 99,9% precise)

I'm working on a statistics/predictive anti cheat for bhop. I never tried 'advanced' bhop anticheats like https://forums.alliedmods.net/showthread.php?p=2582325 but i'll always recommend to be sure that false positives are under 1 in 500/1000 before banning. Else, just enable logging and see if the same person consistently triggers the AC

[J-Tanzanite]

@rlevet We did talk about this earlier, and as I pointed out, the second method isn't safer than the first, as it only takes into account +jump ticks when checking if it should ban for 5 bhops - but it will always ban on the 10th bhop, regardless of how many +jump ticks you've done.

Thus, it's faster than the other method, but not safer.

---

However, I do have to admit I got some things wrong.

The default settings will remain default, because it's the most effective with very few issues for most servers.

This was based on my experience as a server owner for TF2, and having talked and worked with other community servers... But... That's... Kinda irrelevant.

As you've pointed out several times now, the way you beat incredibly small odds - is to roll the dice several times... And this is something I'm aware off, and I've said that phrase to other people regarding other issues, but it didn't quite occur to me that this also logically applies to bhop as well... Which is... Quite a small brain moment!
That's one BIG mistake to make.

My experience - and the experience of others - only really takes into account how most players play, not how most bhopers play - there is a HUGE difference between those two things.
Which was my second mistake.

My third mistake is this: I've been willing to change a lot about this Anti-Cheat, the backtrack patch for one has developed massively since the initial release version of 0.7.0... My unwillingness to update the Bhop detection is... Frankly... Stupid of me, and up until this point, I've been nothing but an ass about it.
I'm sorry. :(

---

So here's what's going to happen.

I'm going to re-do the entire Bhop detection system, I was thinking of delaying this until version 1.8.0, but no... That kind of delay isn't warranted or justifiable.

Another thing is that I've allowed community servers to change the Bhop ban length to permanent, even tho I strongly argue against it due to how Bhop detection comes down to probability...
It doesn't matter if I strongly discourage it and have the default ban length be 1 month, I shouldn't let people change the length to be permanent (with ease) when I know Bhop detection can't be perfect... Especially since a lot of people may see that someone got banned for Bhop, and assume it was due to cheat because of the ban length.

Obviously, due to the open source nature of this project, people can always just change the source code to always perma ban, but I think I should change Lilac to have a maximum ban length for Bhop to be a few months, prob 3-6 tops.

Breaking compatibility.

This is something I've always tried to avoid, at all costs.
One thing that's VERY important to me is that you should NEVER... NEVER break a program for a user unless you have to.
It doesn't matter if you got it wrong the first time, legacy support is important.

If server owners can't update their software without worrying about something breaking, then they simply aren't ever going to update. Which leads to a lot of issues.
Server owners must be able to trust that when the plugin updates, everything is still going to work, and the only things that change are new features, bug fixes, cleanup, speed and reliability.

If you've ever read my sourcecode, you might have noticed this anomaly: https://github.com/J-Tanzanite/Little-Anti-Cheat/blob/master/scripting/lilac.sp#L386
When I first released this AC, only I had ever used it, and because of that, I wasn't aware that configs for plugins should be in the cfg/sourcemod folder, and so I placed the config in the cfg folder instead...
People pointed this out to me, but I didn't wanna update the location, as server owners who currently relied upon their pre-existing config, would hate to update and suddenly have their AC behave in a way they didn't configure it to.

Thus the solution was simple: Only use the new proper config location if the old config doesn't exist.

However in this case, I have to change how Bhop detections work, and thus, kinda break pre-existing configurations for Bhop.
But this is a necessary change.

I would like to take this conversation over to the "discussions" page, which was recently added.
As it's more fit for purpose.

We can continue the conversation here: #57

[lunatixxx]

In your next update in my opinion you should disable bhop detection when infected is in "ghost" mode (left 4 dead 2), because as a ghost you have a lot more speed (and even more on high tickrate servers) and it is probably more easy to do bhops and to trigger a false detection. Just a guess i'm not expert.

That code will work ?

if (IsValidClient(client) && IsValidClient(entity) 
   && GetEntProp(client, Prop_Send, "m_isGhost") == 1)
 {
	return Plugin_Handled; 
     }

if (icvar[CVAR_BHOP] && !cvar_bhop_value) {
	if ((buttons & IN_JUMP))
		playerinfo_jumps[client]++;

	int flags = GetEntityFlags(client);
	if ((buttons & IN_JUMP) && !(lbuttons[client] & IN_JUMP)) {
		if ((flags & FL_ONGROUND)) {
			lilac_detected_bhop(client);

			playerinfo_bhop[client]++;
		}
	}
	else if ((flags & FL_ONGROUND)) {
		playerinfo_bhop[client] = 0;
		playerinfo_jumps[client] = 0;
	}
}

[azalty]

That could do the trick, but idk if there's only a bhop check in the Button Press event, so best thing would be to incorporate it in the (icvar[CVAR_BHOP] && !cvar_bhop_value) check by adding a gamemode check+ (GetEntProp(client, Prop_Send, "m_isGhost") == 1)

@lunatixxx you should just create a new issue saying that and tanzanite will review it, it may not be a reason to entierly disable to check but maybe just make it less sensitive.

[J-Tanzanite]

Closing this, as Bhop is reworked in version 1.7.0, which will soon release.
For now, if you're having issues with Bhop detections from version 1.6.x - disable it with "lilac_bhop 0"