Faux positifs : pourquoi votre anticheat accuse vos joueurs honnêtes
Un voyage rapide pris pour une téléportation, une diligence pour un speedhack : les faux positifs d’anticheat classiques sur RedM, et comment les retirer.
Un anticheat ne meurt presque jamais parce qu’il ne détecte rien. Il meurt le jour où votre staff cesse d’ouvrir le salon d’alertes. À partir de ce jour, la détection tourne toujours, les alertes s’empilent toujours, et plus personne ne les lit, parce que les six dernières étaient des joueurs honnêtes. Après cela, un vrai tricheur traverse le bruit sans que personne ne le remarque. Ce sont les faux positifs d’anticheat, et ils sont le premier sujet à regarder.
Ce que fait votre serveur chaque jour et qui ressemble exactement à de la triche
Aucun de ces cas n’est théorique. Ce sont les cinq principales causes d’alertes absurdes sur un serveur roleplay RedM, dans l’ordre où elles apparaissent :
Le voyage rapide. Votre script déplace un joueur de Valentine à Saint Denis en une image. Pour un détecteur qui divise une distance par un temps, c’est une téléportation parfaite, mieux exécutée en fait que celle d’un mod menu.
Les diligences et les trains. Un joueur assis dans un chariot se déplace à la vitesse du chariot. Selon la façon dont il y est attaché,
GetEntitySpeedpeut renvoyer une valeur proche de zéro alors que ses coordonnées avancent à travers la carte. Un cheval au galop tombe déjà à lui seul dans la plage que vous auriez choisie comme plafond pour un homme à pied : le seuil naïf est faux avant même que le train d’Annesburg ne parte.La chute de cheval. Le joueur est projeté, le personnage passe en ragdoll, et pendant quelques images il traverse le décor : la collision n’est pas encore chargée, les coordonnées passent sous le sol. Un détecteur de noclip qui demande « est-il sous la géométrie ? » l’accuse à chaque descente de selle.
Votre framework qui réanime quelqu’un. Votre framework active un drapeau d’invincibilité pendant l’état à terre et le ramassage, exactement comme le ferait un mod menu. Idem au spawn, en cinématique, en zone sûre. Le godmode le plus fréquemment détecté sur un serveur roleplay, c’est le vôtre.
Vos propres outils d’admin. Un modérateur en noclip, un ped créé pour un événement RP, une téléportation vers un joueur : même capacité, même trace, même signal. Un anticheat qui ne sait pas d’où vient un appel accuse d’abord votre propre équipe.
Ce que ces cinq cas ont en commun : le détecteur lit un état et en déduit une intention. Il voit « invincible » et écrit « godmode ». Il voit une distance et écrit « téléportation ». Or cet état est produit indifféremment par un tricheur et par votre serveur qui fait son travail. Tant que vous n’avez pas la cause, vous n’avez rien.
En pratique, un plafond de vitesse utilisable n’est pas un nombre unique : il dépend du porteur que le serveur a reconnu (à pied, à cheval, en chariot, sur rails), et il est relevé de pendant la fenêtre qui suit un déplacement scripté. Les valeurs exactes restent en interne : un tricheur qui les connaît se règle juste en dessous.
Non publié/Les seuils de détection ne sont jamais publiés : une valeur connue est une valeur sous laquelle un cheat se règle.
Ce que coûte vraiment un faux positif
On le compte d’habitude en temps de staff perdu. C’est la partie bon marché. Le vrai coût est ailleurs : un joueur puni à tort raconte l’histoire, et il a raison de la raconter. Votre communauté apprend que l’anticheat se trompe, et dès le prochain ban, le bon, celui qui s’appuie sur des preuves, il vous faudra défendre l’outil avant de pouvoir défendre la décision. Un anticheat qui a menti une fois ne prouve plus rien ensuite.
- semaine 1
- l’écrasante majorité des alertes étaient des faux positifs
- causes
- déplacement scripté + monture/chariot
- facteur aggravant
- le même événement compté deux fois
- sanctions automatiques
- aucune : livré en mode observation
Deux causes, et presque toutes les alertes du panel. Aucun de ces joueurs n’avait triché, et aucun n’a été puni, parce que rien n’était relié à une sanction. C’est la seule raison pour laquelle l’épisode peut être raconté : il a coûté du temps de lecture et rien d’autre.
La discipline qui les supprime
- 1
Mesurer avant d’accuser. Le taux de faux positifs se compte par famille de détection et rapporté au trafic (événements pour mille battements de présence), jamais comme un nombre brut d’alertes à l’écran. Une famille qui explose se voit tout de suite ; un total global ne dit rien.
- 2
Corroborer, c’est-à-dire exiger l’effet et non l’état. « Il a le drapeau d’invincibilité » ne prouve rien. « Nous lui avons tiré dessus, les impacts sont confirmés côté serveur, et il n’a perdu aucun point de vie » prouve quelque chose. La preuve doit porter sur une conséquence observable, pas sur la valeur d’une variable.
- 3
Apprendre les propres scripts du serveur. La liste des événements légitimes de votre serveur ne se devine pas : elle se déduit de vos ressources. Un anticheat qui découvre au démarrage quels événements votre propre code déclenche cesse d’accuser votre voyage rapide dès le premier jour.
- 4
Livrer en mode observation. Aucune sanction automatique tant que le taux de faux positifs par famille n’est pas connu. Les premiers jours servent à mesurer, pas à punir.
- 5
Corriger la cause, ne jamais couper la détection. C’est le point où les deux métiers se séparent.
Ce dernier point mérite qu’on s’arrête, parce que c’est là que tout le monde cède. Une famille de détection est bruyante ? On la coupe. Le silence revient, l’équipe est soulagée, et la porte est désormais ouverte pour de bon : plus personne ne surveille cette capacité, y compris quand un tricheur l’utilise. La bonne réponse est chirurgicale : autoriser cet événement précis parce qu’il vient de votre script de diligence, relever ce plafond pour un joueur attaché à un chariot, ignorer cette invincibilité parce qu’elle est posée pendant un ramassage. La détection reste active partout ailleurs.
Avec une réserve, et elle compte : autoriser un événement revient à distribuer une capacité qui peut être redéclenchée. Un tricheur qui apprend le nom d’un événement exempté peut l’appeler lui aussi. C’est pourquoi une exemption reste ici un clic humain : la machine propose la correction, elle ne l’applique jamais seule.
Le mécanisme tourne une fois par nuit : il relit les alertes classées comme fausses, remonte à la cause, et prépare la correction la plus étroite possible, par exemple une fenêtre de tolérance de après le déplacement. Deux leviers, deux règles. Relever un plafond s’applique tout seul, mais seulement dans des bornes strictes : vingt échantillons minimum, venant d’au moins trois joueurs distincts, quinze pour cent de marge au-dessus du p99 observé, jamais au-delà de trois fois la valeur d’origine, cinq modifications par jour, et cela expire au bout de trente jours. Autoriser un nom d’événement n’est jamais automatique, quelles que soient les preuves : ce nom est livré à chaque client, c’est donc une capacité qu’un cheat peut redéclencher à volonté. Là, un humain clique, ou personne.
Non publié/Les seuils de détection ne sont jamais publiés : une valeur connue est une valeur sous laquelle un cheat se règle.
La question à poser avant d’acheter
Pas « combien de cheats détectez-vous ». Tout le monde répond à cela par une liste. Demandez plutôt : comment mesurez-vous vos faux positifs, et que se passe-t-il quand une détection se trompe sur mon serveur ? Si la réponse est « nous désactivons le module », c’est un interrupteur, pas un anticheat. Si la réponse est « nous remontons à la cause, nous proposons la correction, vous l’approuvez », il y a quelqu’un derrière le produit.
Le panel de démo montre à quoi ressemble une alerte qu’on a instruite plutôt que criée, et les tarifs sont publics. Notre anticheat RedM est construit autour de cette règle d’abord, et du nombre de détections ensuite. Pour comprendre pourquoi l’observation d’état produit structurellement ce bruit, lisez comment fonctionne un anticheat RedM.