False bans are bugs, not bad luck

Every anti-cheat team eventually gets the same message: "I didn't cheat, I was just playing." Sometimes it is a cheater trying their luck. Sometimes it is true. The second case is the one that matters, because a single wrong ban does damage that ten correct ones cannot undo: the player leaves, their friends hear about it, and your staff start doubting every detection that follows.

We treat a confirmed false ban the same way we treat a crash: as a bug with a root cause that has to be found and removed.

Why "just raise the threshold" does not work

The tempting fix for a false positive is to make the rule stricter: allow a bit more speed, a few more shots per second, a slightly longer distance. It makes the report go away. It also makes the detection blind to every cheater who stays just under the new limit, and the next legitimate edge case (a faster car, a modded weapon, a laggy player) will cross it again anyway.

A threshold only works if the signal behind it is sound. If the signal itself can be produced by normal play, no number is safe.

Find the unsound signal

When a ban report comes in, we start from the evidence, not the rule:

1. Watch the recording. Every automatic TruffAC ban stores a screen capture of the moments around the detection. Most disputes are settled here in under a minute.
2. Read the detail fields. Each detection logs what it measured: positions, timings, the weapon, the vehicle, the resource that triggered an event. We compare those numbers with what the recording shows.
3. Ask what else produces this signal. A teleport check that fires during a scripted taxi ride, a damage check that fires when a server script heals players, a "spawned weapon" check that fires for a job that hands out weapons. In each case the measurement was correct; the assumption behind it was not.
4. Remove the assumption. The fix is to stop treating that signal as proof (for example, by ignoring position changes the server itself caused), not to make the number bigger.

Evidence first, ban second

Some signals are strong enough to act on alone: an injected executor's fingerprint, a resource that does not exist on your server sending events. Others are only suspicious, and should add to a case for a human to review rather than ban by themselves. Splitting detections into "proof" and "suspicion" is the single change that removed most false bans for the servers we work with.

A detection should be able to explain itself. If you cannot say in one sentence why this could only happen with a cheat, it should not ban on its own.

What server owners can do

• Review the recording before you deny an appeal. It takes seconds and it is the strongest argument either way.
• Send us disputed cases with the detection details. A report with the ban ID and a short description lets us reproduce the problem.
• Tell us about scripts that move, heal or arm players from the server side. They are the most common source of misleading signals.

Catching cheaters is the job. Not banning the people who were just playing is what makes the job worth anything.