False positives: why your anticheat is accusing your honest players
Fast travel read as a teleport, a stagecoach as a speedhack: the classic RedM false positives, and how to remove them without switching detection off.
An anticheat almost never dies because it detects nothing. It dies the day your staff stops opening the alert channel. From that day the detection still runs, the alerts still pile up, and nobody reads them any more, because the last six were honest players. After that, a real cheater walks through the noise and nobody notices.
What your server does every day that looks exactly like cheating
None of these cases are theoretical. They are the five leading causes of absurd alerts on a RedM roleplay server, in the order they show up:
Fast travel. Your script moves a player from Valentine to Saint Denis in one frame. To a detector that divides a distance by a time, that is a perfect teleport - better executed than a mod menu one, in fact.
Stagecoaches and trains. A player sitting in a wagon moves at the wagon's speed. Depending on how he is attached,
GetEntitySpeedcan return close to zero while his coordinates advance across the map. A galloping horse alone already lands in the range you would have picked as the ceiling for a man on foot: the naive threshold is wrong before the Annesburg train even leaves.Falling off a horse. The player is thrown, the character ragdolls, and for a few frames he goes through the scenery: collision not streamed in yet, coordinates below the ground. A noclip detector that asks "is he under the geometry?" accuses him at every dismount.
Your framework reviving someone. Your framework sets an invincibility flag during the downed state and the pickup, exactly the way a mod menu would. Same at spawn, in cutscenes, in safe zones. The god mode most frequently detected on a roleplay server is yours.
Your own admin tools. A moderator noclipping, a ped spawned for an RP event, a teleport to a player: same capability, same trace, same signal. An anticheat that does not know where a call came from accuses your own team first.
What these five have in common: the detector reads a state and infers an intent. It sees "invincible" and writes "god mode". It sees a distance and writes "teleport". But that state is produced indifferently by a cheater and by your server doing its job. Until you have the cause, you have nothing.
In practice a usable speed ceiling is not a single number: it depends on the carrier the server recognised (on foot, mounted, in a wagon, on rails), and it is raised by during the window that follows a scripted relocation. The exact values stay in-house - a cheater who knows them tunes himself just below.
Withheld/Detection thresholds are never published: a value that is known is a value a cheat is tuned just underneath.
What a false positive really costs
It is usually counted in wasted staff time. That is the cheap part. The real cost is elsewhere: a player punished by mistake tells the story, and he is right to tell it. Your community learns that the anticheat gets it wrong, and from the next ban onwards - the good one, the one backed by evidence - you will have to defend the tool before you can defend the decision. An anticheat that lied once proves nothing afterwards.
- week 1
- the overwhelming majority of alerts were false positives
- causes
- scripted relocation + mount/wagon
- aggravating factor
- the same event counted twice
- automatic sanctions
- none - shipped in observation mode
Two causes, and nearly every alert on the panel. None of those players had cheated, and none of them was punished, because nothing was wired to a sanction. That is the only reason the episode can be told at all: it cost reading time and nothing else.
The discipline that removes them
- 1
Measure before you accuse. The false positive rate is counted per detection family and against traffic - events per thousand presence heartbeats - never as a raw number of alerts on screen. A family that blows up is visible immediately; a global total says nothing.
- 2
Corroborate, meaning require the effect and not the state. "He has the invincibility flag" proves nothing. "We shot him, the impacts are confirmed server-side, and he did not lose a single point of health" proves something. The evidence has to be about an observable consequence, not the value of a variable.
- 3
Learn the server's own scripts. The list of legitimate events on your server cannot be guessed: it is derived from your resources. An anticheat that discovers at boot which events your own code triggers stops accusing your fast travel on day one.
- 4
Ship in observation mode. No automatic sanction until the false positive rate per family is known. The first days are for measuring, not for punishing.
- 5
Fix the cause, never switch the detection off. This is the point where the two trades part company.
That last point deserves a stop, because it is where everyone gives in. A detection family is noisy? Turn it off. Silence returns, the team is relieved, and the door is now open for good: nobody watches that capability any more, including when a cheater uses it. The right answer is surgical - allow this specific event because it comes from your stagecoach script, raise this ceiling for a player attached to a wagon, ignore this invincibility because it is set during a pickup. Detection stays on everywhere else.
With one reservation, and it matters: allowing an event means handing out a capability that can be triggered again. A cheater who learns the name of an exempted event can call it too. That is why an exemption here stays a human click: the machine proposes the correction, it never applies it alone.
The mechanism runs once a night: it re-reads the alerts that were closed as wrong, traces them back to the cause, and prepares the narrowest possible correction - a grace window of after the relocation, for instance. Two levers, two rules. Raising a ceiling applies on its own, but only inside hard bounds: twenty samples minimum, from at least three distinct players, fifteen percent of headroom over the observed p99, never beyond three times the stock value, five changes a day, and it expires after thirty days. Authorizing an event name is never automatic, whatever the evidence says: that name ships to every client, so it is a capability a cheat can re-trigger at will. There, a human clicks, or nobody does.
Withheld/Detection thresholds are never published: a value that is known is a value a cheat is tuned just underneath.
The question to ask before you buy
Not "how many cheats do you detect". Everyone answers that with a list. Ask instead: how do you measure your false positives, and what happens when a detection gets it wrong on my server? If the answer is "we disable the module", that is a switch, not an anticheat. If the answer is "we trace it back to the cause, we propose the correction, you approve it", there is somebody behind the product.
The demo panel shows what an alert looks like when it has been investigated rather than shouted, and the pricing is public. Our RedM anticheat is built around that rule first and the detection count second. For why state observation structurally produces this noise, read how a RedM anticheat works.