A strike is a recorded warning — behaviour suspicious enough to log, but not conclusive enough to ban on its own. Enough of them in one session bans the player automatically. See Strikes for the mechanics.
The table
| Column | Meaning |
|---|---|
| Strike ID | Its unique reference |
| Player | Who received it |
| Reason | Which detection fired |
| Severity | Low, medium or high |
| Date | When |
| Status | Unresolved, or resolved |
Filter by severity to cut straight to what matters. Search matches names, reasons and Strike IDs.
Reading a strike
Open one and you get the detail the detection recorded — the speed measured, the distance covered, the model spawned. That’s the part that tells you whether it was real.
A “Vehicle Boost” strike citing 400 km/h in a hatchback is a cheat. One citing a speed slightly over the limit for a supercar is probably your detection being a little tight. Adjust it on Configuration.
Resolving
Marking a strike resolved means you’ve looked at it and decided it needs no action. It stays on the player’s record, but drops out of your unresolved count.
Resolving does not undo anything — it doesn’t lower risk score or reverse a ban. It’s a bookkeeping tool so your queue reflects what still needs attention.
Admins can resolve strikes in-game with the resolveStrikes permission.
Patterns worth noticing
One player, many strikes across sessions. The session counter resets each disconnect, so someone can accumulate strikes indefinitely without ever hitting a ban. Sort by player and look at the totals — this is what risk score is for.
Many players, one detection. That’s a mis-tuned detection, not an outbreak. Loosen the threshold.
A burst of high-severity strikes. Usually a cheat menu that your detections catch but don’t outright ban. Worth reporting on Discord.
Stopping false positives
If a detection keeps striking someone it shouldn’t, whitelist that player against that detection rather than turning it off for everyone — see Whitelisting.