Démarrage rapide

Configuration#

Inscrivez-vous avec Sign up, vérifiez votre adresse e-mail et choisissez une offre payante. Après paiement, ajoutez un serveur puis téléchargez son paquet avec les droits de gestion.

Préparer le compte et le service#

Vérifiez votre e-mail puis, dans Facturation, le forfait payant, la période et les limites de serveurs et de sites. Le retour du prestataire ou le dépôt d’un justificatif ne suffit pas à confirmer l’activation.

Utilisez un compte autorisé à gérer les serveurs. Attribuez des droits adaptés aux membres au lieu de partager un mot de passe administrateur. Sauvegardez les ressources, paramètres modifiables et base du jeu avant installation.

Relier le bon serveur#

Le paquet et la licence correspondent à l’enregistrement sélectionné. Ne mélangez pas les fichiers et clés de plusieurs serveurs.

1. Vérifiez le nom et téléchargez le paquet associé.
2. Suivez l’ordre d’installation. Conservez la licence uniquement dans server.cfg côté serveur avec set, jamais dans les fichiers client ou partagés.
3. Démarrez pendant une maintenance prévue, examinez la première erreur de console puis la connexion du bon serveur dans le panneau.
4. Le pont de données est actif par défaut ; hormis la licence, aucune ligne server.cfg n’est nécessaire. Si vous n’en voulez pas, coupez-le avec « Disable connection » sur la carte Tosun Connect du serveur ; testez d’abord une petite lecture.

• Installation
• Pont de base de données

Vérifier les résultats dans le jeu#

Testez sélection du personnage, apparition, réanimation, garages, équipement policier et téléportations du personnel avant de renforcer les sanctions. Comparez les détections au contexte réel et modifiez un paramètre à la fois.

Connexion AC, requête du pont, préparation du site et HTTPS ont des résultats distincts. Contrôlez chaque service nécessaire. Pour un paiement incertain, consultez la facture avant de recommencer.

Un nouveau téléchargement ne révoque pas une licence divulguée. Organisez son remplacement et l’arrêt des anciennes copies. Pour l’assistance, préparez version, identifiant serveur/site, heure et erreur sans secrets.

• Paramètres et performances

Préparer un petit plan de validation#

Avant d’inviter toute la communauté, notez ce que la première session doit démontrer. Prévoyez un joueur ordinaire, un compte de l’équipe, une première connexion et une reconnexion. Utilisez votre framework réel et les ressources habituelles : une console silencieuse ne démontre pas la compatibilité d’un hôpital ou d’un garage.

Pour chaque scénario, consignez l’action, le résultat attendu et le résultat observé. Le personnage doit charger, l’équipement normal rester utilisable et une action autorisée du personnel aboutir. Si une détection apparaît, conservez son heure avec le contexte de jeu et examinez-la avant de renforcer les mesures.

Choisissez une période couvrant les activités importantes du serveur. Après modification du réglage pertinent, répétez le scénario concerné en laissant les autres valeurs inchangées. Ces vérifications donnent une validation concrète à l’équipe, sans garantir la compatibilité de chaque ressource ni de toutes les mises à jour futures.

Séparer l’installation nécessaire des services facultatifs#

Établissez une courte carte des dépendances de votre installation. Le compte payant, le paquet du serveur choisi, sa licence côté serveur et le démarrage correct de la ressource constituent le parcours initial. La connexion de données du panneau (Tosun Connect) est déjà active par défaut et ne demande aucune ligne server.cfg supplémentaire ; vérifiez-la simplement par une petite lecture. Vous pouvez la couper sur la carte Tosun Connect du serveur. Notifications Discord, launcher et site loué ajoutent des processus distincts. Activez-les une fois la connexion principale comprise.

Si l’anticheat se connecte alors que le site est encore en préparation, continuez les vérifications de jeu et suivez le site séparément. Si une lecture du pont échoue, examinez le framework pris en charge et les autorisations du pont. Remplacer une licence fonctionnelle à répétition ne répare pas un schéma incompatible.

Ajoutez une seule intégration facultative à la fois et notez responsable et méthode de vérification. Vous pourrez repérer la première étape défaillante et revenir à un fonctionnement connu sans abandonner le travail terminé. Listez les options volontairement désactivées pour qu’un autre administrateur ne les prenne pas pour des pannes.

Transmettre un état d’exploitation reproductible#

Avant un changement d’administrateur, préparez un document court avec identifiant du serveur, version, framework, ordre de démarrage et emplacement des réglages modifiables. Liez la documentation pertinente et précisez les intégrations facultatives vérifiées. Conservez licences et identifiants privés dans votre stockage sécurisé, en dehors de ce document.

Incluez période de maintenance, réglages changés et anciennes valeurs fonctionnelles. Nommez les responsables de la facturation, des accès aux intégrations et des signalements de joueurs. Décrivez la restauration de vos fichiers de ressources et configuration sauvegardés, puis les observations à vérifier immédiatement.

Si des ressources, le framework ou l’hébergement changent ensuite, réutilisez les mêmes scénarios. Comparez les nouveaux résultats au document précédent plutôt qu’à votre mémoire. Cela facilite l’examen des mises à jour et fournit au support un historique utile sans transmettre une archive de données de joueurs sans rapport.

Relier quatre identités dans un dossier de configuration#

Notez ID du serveur sélectionné, Build ID de l’historique, version de fxmanifest.lua et dossier prévu. Ils identifient enregistrement, paquet distribué, logiciel et installation sur la machine. Un nouveau ZIP peut rester sur le bureau tandis que le serveur démarre encore un ancien dossier. Un téléchargement réussi ne confirme pas une mise à jour active. Gardez la licence hors de ce dossier de suivi.

Après extraction, suivez l’arborescence jusqu’à fxmanifest.lua pour trouver la racine réelle. Reliez sortie de démarrage et heure du test. Si les noms diffèrent entre panneau et machine, comparez les identités plutôt que leur ressemblance. Avec plusieurs machines, désignez la copie active. Ces références et l’heure permettent au support de distinguer mauvais paquet, mauvais serveur et fichiers obsolètes sans secrets ou archive étrangère au problème.

Orienter chaque symptôme vers le bon sujet#

Décrivez le résultat attendu en une phrase. Si connexion possible mais téléchargement impossible, examinez Facturation et droits serveur ; se connecter ne prouve pas le droit de télécharger. Sans démarrage, consultez fichiers et dépendances dans Installation. Après démarrage avec refus de licence, examinez liaison licence/Build ID. Si le jeu fonctionne mais les lectures échouent, commencez par MySQL, état du travail et framework.

Conservez la portée du symptôme. Un solde différent nécessite identité et type de lecture, pas modification de toute protection. Pour blocages mesurés, utilisez Configuration et performances ; pour scripts légitimes refusés, Exports et intégration. Ne répétez ni paiement ni écriture incertaine comme test. Appliquez l’étape pertinente et vérifiez la même observation pour localiser la première panne en gardant le travail confirmé.

Tosun AC 9.6.12#

Le manifeste de démarrage Render est corrigé. Un seul INSTALL.sql répare les anciennes colonnes manquantes. Le pont utilise la licence résolue sur le serveur. Les autorisations sont actualisées régulièrement et les derniers réglages restent en attente. Les ressources inchangées réutilisent les analyses. Le téléchargement inclut les guides hors ligne en neuf langues et l’installation séparée du bot Discord.

Nouveautés de la version 9.6.19#

L’anticheat répare ses tables admin_logs et ac_detections au démarrage en ajoutant seulement les colonnes manquantes ; les tables partagées avec d’autres scripts ne sont pas touchées par défaut. Le limiteur d’événements enregistre désormais les joueurs qui dépassent la limite d’un événement listé (server_event_spam, LOG par défaut ; vérifiez vos limites puis passez à KICK ; une valeur enregistrée dans le panel est prioritaire). Les autres scripts serveur ne peuvent plus déclencher les événements internes de l’anticheat s’ils ne figurent pas dans la liste des ressources de confiance (set tosun_ac_local_event_guard "audit" se contente de signaler pendant vos ajustements). La quarantaine automatique des backdoors fonctionne lorsqu’elle est activée, les alertes de nouveaux journaux parviennent aux téléphones de l’équipe et au menu en jeu, et un résumé de santé de l’installation (tosunac_health) indique quoi corriger après le démarrage. Un démarrage tardif du framework n’arrête plus le module serveur.

Nouveautés de la version 9.6.18#

Les joueurs dont le client anticheat ne fonctionne pas ou ne répond plus sont désormais expulsés (jamais bannis), membres de l’équipe compris. L’exemption de l’équipe est plus étroite : seuls les membres déclarés explicitement (fichier admins, autorisation du panel, permission tosun.exempt ou session txAdmin vérifiée) sont exemptés ; ceux qui n’ont qu’une permission large ou une entrée ip: sont contrôlés comme des joueurs, les sanctions automatiques sont limitées à une expulsion, et les détections sur un membre exempté sont envoyées au nouveau webhook StaffAlerts. Le noclip, la caméra libre et le mode spectateur du menu en jeu et de txAdmin reçoivent une autorisation de mode administrateur vérifiée par le serveur. Une nouvelle protection de mouvement contrôle les positions côté serveur ; elle démarre en mode observation (shadow) et n’expulse personne tant que vous ne réglez pas ts.serverMovement.guard.mode = "enforce". Lisez RELEASE-9.6.18.md avant l’installation : ajoutez le webhook StaffAlerts et vérifiez qui est exempté.

Nouveautés de la version 9.6.3#

Une erreur de l’API du framework ne prouve plus l’absence d’une arme. checkDamage=false fonctionne et un redémarrage de l’inventaire efface les anciens résultats. AllowWeapon exige une ressource approuvée. L’anti-aimbot conserve le dernier impact par cible; les seuils et actions restent identiques.

Quoi de neuf dans 9.6.6 ?#

Un problème de performance qui pouvait faire saccader le serveur pendant les gros combats est corrigé. La vérification admin (ts.AdminStatus) lançait deux requêtes de base de données synchrones à chaque appel pour les joueurs non staff, et tout le thread du serveur attend pendant ce temps. La vérification d’exemption de sanction l’appelle à chaque explosion et à chaque dégât, donc les gros combats pouvaient provoquer du lag, et un joueur pouvait créer la même charge exprès en demandant une vérification admin chaque seconde. Un résultat « non staff » venant de la base est maintenant conservé 30 s par joueur. Les vérifications ACE, txAdmin et admins.lua ne sont pas mises en cache et s’appliquent immédiatement ; une nouvelle autorisation du panel est reconnue sous 30 s.

Quoi de neuf dans 9.6.5 ?#

Pour les captures d’écran demandées depuis le panel, l’adresse renvoyée par le joueur observé est désormais vérifiée. Un tricheur observé pouvait auparavant renvoyer n’importe quelle adresse au lieu d’une capture : une image propre hébergée ailleurs, un pixel de suivi ou un lien vers un autre site. Seules les adresses data:image du mode base64 et les chemins sous /images/ du panel sont maintenant acceptés, et l’hôte d’une adresse complète est toujours remplacé par le panel qui a reçu l’envoi. Les autres adresses sont ignorées, la demande est marquée en échec et la console du serveur affiche un avertissement.

Quoi de neuf dans 9.6.3 et 9.6.4 ?#

9.6.3 : ts.weaponInventory.checkDamage = false désactive désormais vraiment le contrôle des dégâts. Si l’API d’inventaire ne répond pas, l’arme est considérée comme inconnue, pas comme manquante. AllowWeapon exige maintenant une ressource serveur de confiance : ajoutez votre script d’arène/paintball à la liste existante tosun_ac_trusted_resources (en gardant les autres noms). Le balayage anti-aimbot utilise désormais une mémoire et un travail bornés ; les seuils sont inchangés. 9.6.4 : une capture d’écran Shield n’est acceptée que si le serveur l’a demandée (sous 60 s, une seule fois). Une vidéo de ban n’est acceptée que d’un joueur réellement expulsé ou banni dans les 2 dernières minutes ; auparavant, n’importe quel joueur pouvait créer une fausse entrée « BAN » dans le panel et une notification de ban Discord.

Quoi de neuf dans 9.6.2 ?#

Deux cas où la protection physique des véhicules (ts.vehicleGuard, kick par défaut) pouvait expulser un joueur innocent sont corrigés. Une explosion soulevant plusieurs véhicules d’un même joueur comptait un avertissement par véhicule, et le propriétaire pouvait être expulsé même si quelqu’un d’autre avait lancé la bombe. Désormais, un joueur reçoit au plus un avertissement par passe d’échantillonnage, et les véhicules à moins de 30 m d’une explosion des 4 dernières secondes ne sont pas évalués. Seules les explosions qu’aucun autre contrôle n’a annulées comptent : un tricheur ne peut pas cacher un lancer derrière une explosion bloquée.

Quoi de neuf dans 9.6.1 ?#

Le canal de logs client est renforcé. N’importe quel joueur pouvait écrire des logs avec n’importe quel tag et statut : fausses lignes « [BAN] ... » dans le panel, notifications téléphone à tous les admins avec le statut « Detection », et une requête panel par ligne. Les joueurs ordinaires ne peuvent plus utiliser que les tags client propres à l’anticheat ; le serveur fixe le statut et chaque joueur est limité à 12 lignes par minute. Les autres tags (menu admin) exigent des droits staff. Le miroir de logs du panel est désormais envoyé en une seule requête groupée toutes les 3 s, pour que les notifications de ban et de détection ne se heurtent plus à la limite de débit du panel aux moments chargés. La journalisation dans la base du jeu est inchangée.

Quoi de neuf dans 9.6.0 ?#

Le contrôle arme/inventaire examine désormais aussi les dégâts infligés, pas seulement l’arme en main. Les menus de triche peuvent tirer avec une arme sans la tenir (magic bullet, taser des joueurs). Si l’arme d’un événement de dégâts n’est pas dans l’inventaire de l’attaquant, elle passe par la même chaîne de journalisation et de sanction (journal seulement par défaut). Il faut 2 événements en 60 s. Les armes de jet, les 60 premières secondes après la connexion, les inventaires non chargés, les armes additionnelles et de véhicule, et les armes autorisées via AllowWeapon sont ignorés. Désactivez avec ts.weaponInventory.checkDamage = false.

Quoi de neuf dans 9.5.9 ?#

Les détections sont en pause tant qu’un joueur est mort, à terre ou en dernier souffle, pour que les animations de réanimation ne créent pas de faux positifs. Une triche pouvait garder cet état indéfiniment en déclenchant localement l’événement de mort d’un framework ou en maintenant la santé entre 101 et 110. Un joueur à terre ne peut ni courir, ni sprinter, ni conduire un véhicule en mouvement. Après 20 s d’une de ces actions, l’indicateur « à terre » obsolète est effacé et une santé basse ne met plus les détections en pause. Les joueurs réellement à terre ne sont pas concernés.

Quoi de neuf dans 9.5.7 et 9.5.8 ?#

Chaque contrôle côté client pouvant sanctionner a été audité, et chaque constat est passé par trois vérifications indépendantes. Fermé pour les tricheurs : un verrou qui rendait muettes toutes les détections client de la session avec un seul événement local ; des exemptions modifiables par le client qui avalaient les détections en silence (désormais journalisées) ; SetSpawned qui désactivait les contrôles pour de bon ; un renouvellement de clé qui aveuglait les détections signées ; et une fenêtre de confirmation qui ne se complétait jamais. Corrigé pour les joueurs innocents : bans permanents en descendant une pente à vélo, expulsions en faisant le plein avec un jerrican, bans godmode après 1 PV de dégâts environnementaux, bans aimbot pour un policier visant un suspect en fuite, voitures garées comptées comme des apparitions, bans godmode véhicule dans les voitures d’essai, analyses de menus correspondant à la commande exec de FiveM et aux noms de textures du jeu, le fait de se tenir sur un pont de bateau ou un plateau de camion, et les scripts de panne moteur qui expulsaient les conducteurs.

Quoi de neuf dans 9.5.6 ?#

Les pièges côté client construits sur des noms d’événements de menus de triche ne touchent plus les vraies ressources. Sur un serveur utilisant le menu de police SEM_InteractionMenu, un joueur emprisonné recevait l’événement propre à ce menu et était expulsé comme tricheur. Si le préfixe d’un nom d’événement correspond à une ressource en cours d’exécution, l’événement est considéré comme légitime et n’est jamais sanctionné. Les types d’explosion liés à une arme (railgun, mine de proximité, bombe artisanale, raygun) suivent désormais la liste noire des armes : si vous avez retiré l’arme de la liste noire, par exemple pour un script de braquage, son explosion est aussi autorisée.

Quoi de neuf dans 9.5.5 ?#

Un ban aux champs vides ne bloque plus des joueurs sans rapport. Le contrôle de connexion cherchait les identifiants manquants comme des valeurs vides : après un ban via le panel d’un joueur sans Steam ni Discord, toute personne se connectant sans Steam ni Discord pouvait être refusée avec la carte de ce ban. Les identifiants sont désormais validés selon leur format, et les valeurs vides ou de substitution ne correspondent jamais. Les bans hors ligne sont désormais réellement enregistrés. Sous MySQL 8, les colonnes des bans temporaires ne pouvaient pas être ajoutées, ce qui laissait entrer les joueurs bannis ; la migration et le SQL d’installation fonctionnent désormais sur les deux moteurs. L’analyse du contournement de ban n’utilise que les bans actifs et ne considère plus par défaut une IP partagée (opérateur, résidence, café) comme un lien.

Quoi de neuf dans 9.5.4 ?#

Un bug du module anti-aimbot permettait aux tricheurs d’échapper aux sanctions. Les entrées de journal et les sanctions partageaient une attente de 4 secondes : les signaux répétés toutes les 2 secondes ou plus souvent (magic bullet à chaque tir, triggerbot déclenchant un strike par seconde) n’étaient jamais sanctionnés. Un seul tir de fusil à pompe dans une foule ne compte plus comme magic bullet : le seuil est de 4 cibles et le signal doit se répéter. Le contrôle serveur des dégâts d’arme excessifs ignore les percussions, écrasements, explosions et chutes, et un événement isolé est seulement journalisé. Les valeurs par défaut du panel ont été comparées à celles de la config. Les nouveaux serveurs reçoivent des réglages OCR, combat, rate guard et burst plus sûrs. Sans réglages du panel, le watchdog expulse, le native guard journalise et le contrôle d’endurance infinie est désactivé par défaut.

Quoi de neuf dans 9.5.3 ?#

Le threat intel ne transforme plus les détections LOG et les problèmes de connexion en expulsion à la connexion. Le score envoyé au panel comptait chaque détection (y compris celles qui ne font que journaliser), les heartbeats manqués et une valeur que le client du joueur peut écrire lui-même. Le score enregistré ne baissait jamais, si bien qu’un joueur innocent pouvait être expulsé à chaque connexion. Seules comptent désormais les détections réellement appliquées (kick ou ban) sur ce serveur au cours des 10 dernières minutes, et l’action par défaut à la connexion est la simple journalisation. Sur les installations sans réglages du panel, le contrôle d’objets en masse journalise désormais par défaut au lieu de bannir. Le docteur de config et le panel avertissent si le fail-open est désactivé (une panne du panel expulserait alors tout le monde) et en cas d’expulsion à la connexion.

Quoi de neuf dans 9.5.2 ?#

Shield AI ne supprime plus les entités légitimes. Sur un serveur OneSync, les objets et les peds des joueurs n’ont pas de type de population. Avec les anciens réglages, chaque objet réseau créé par un joueur était annulé (props d’emote et de téléphone, cônes, meubles), tout comme chaque véhicule et PNJ d’un script absent d’une courte liste. Une entité créée par une ressource qui tourne sur le serveur est désormais autorisée. Seule une entité de script qu’aucune ressource n’a créée est annulée. L’apparition est toujours annulée ; le kick ou le ban n’intervient que si l’infraction se répète 3 fois en 60 s. L’ancien comportement reste disponible en liste blanche stricte optionnelle. Le contrôle des objets sur liste noire, qui ne tournait plus depuis 9.3.0, fonctionne à nouveau. Les explosions silencieuses sans dégâts (pétarades d’échappement) ne comptent plus pour la sanction.

Quoi de neuf dans 9.5.1 ?#

Deux autres sources de faux bannissement ont été fermées. Le contrôle d’overlay basé sur le curseur pouvait bannir définitivement un joueur qui déplaçait la souris dans un menu de distributeur, de magasin ou de téléphone ouvert avec E, tout en ramenant le curseur dans le coin ; il ne s’exécute plus quand un menu a le focus, ne surveille plus E ni Échap et ne fait que journaliser par défaut. Une seule explosion silencieuse ou invisible entraînait un bannissement définitif, alors que les scripts de pompiers, de pots d’échappement et de thermite en créent aussi. L’explosion est toujours annulée ; la sanction exige désormais 5 répétitions en 60 s et vaut kick par défaut.

Quoi de neuf dans 9.5.0 ?#

Docteur de configuration : une fois les paramètres du panel et de la base appliqués, l’anticheat lit les valeurs réelles et liste celles qui présentent un risque de faux bannissement ou de sécurité. Il avertit par exemple quand la sanction OCR ou de téléportation est réglée sur ban, qu’une protection est désactivée ou que Debug est actif. Il s’exécute seul environ 90 s après le démarrage et écrit un résumé dans les journaux du panel ; lancez tosunac_doctor dans la console du serveur à tout moment. Il ne modifie aucun paramètre. Dans le panel, les valeurs des détails de détection, de joueur et de bannissement sont désormais échappées : un motif envoyé par un client de jeu ne peut pas exécuter de code dans le navigateur d’un admin, et les données intégrées aux pages ne peuvent pas sortir de leur contexte. La cloche de notifications fonctionne de nouveau.

Quoi de neuf dans 9.4.0 ?#

Nouveau contrôle arme et inventaire : le serveur lit l’arme que le joueur tient en main et la cherche dans l’inventaire (ox_inventory, QBCore/Qbox ou ESX). Une arme sans objet correspondant a été générée et elle est détectée même si elle n’est pas sur la liste noire. Par défaut, il ne fait que journaliser, exige 3 échantillons consécutifs et ignore les 60 premières secondes après la connexion ainsi que les joueurs dont le personnage n’est pas chargé. Observez le panel pendant quelques jours, puis passez-le en kick ou en ban dans la section autorité serveur des paramètres de l’anticheat. Les scripts qui donnent des armes sans objet d’inventaire doivent appeler AllowWeapon. Un second enregistrement de getConfig a aussi été fermé, et la page API affiche désormais la clé comme en-tête plutôt que dans l’URL.

Quoi de neuf dans 9.3.1 ?#

La suite de l’analyse du point de vue des joueurs innocents. Les gilets pare-balles et les kits de premiers soins n’expulsent plus les joueurs ; un pic de santé ou d’armure demande désormais 3 répétitions en 60 s. Vider un SMG, le feu et les explosions ne comptent plus comme de l’aimbot, et le contrôle de portée ne concerne que les armes à courte portée. Parcourir une concession, être mis à terre deux fois, une voiture en feu qui explose après votre départ et les tirs de sniper ne provoquent plus de sanction. L’équipement de police et de braquage (gaz BZ, pistolet de détresse, appareil de piratage) a été retiré de la liste noire d’armes par défaut. Les signatures Shield utilisent le même texte canonique des deux côtés, et la perte d’une seule remise de clé n’expulse plus le joueur par expiration.

Quoi de neuf dans 9.3.0 ?#

Une version consacrée à la sécurité et aux faux bannissements. Dans les versions précédentes, la clé API du panel pouvait atteindre les clients des joueurs lors de l’enregistrement des paramètres dans le panel ; le panel ne l’envoie plus et 9.3.0 filtre chaque paramètre envoyé aux clients. Après la mise à jour, générez une nouvelle clé API AC dans les paramètres du site, enregistrez-la puis envoyez-la à l’AC. Les événements serveur qui permettaient à un joueur de s’exempter lui-même n’assouplissent plus que brièvement les contrôles de mouvement et de visibilité. Une téléportation isolée (sélection du personnage, hôpital, maison, rappel par un admin) crée désormais une entrée de journal au lieu d’un bannissement ; une vitesse impossible continue (vol en noclip) est sanctionnée. Le contrôle de l’argent, les filtres de chat et de nom, l’OCR, la protection des véhicules et 27 détections client sans correspondance ont été corrigés pour ne plus provoquer de faux bannissements. Les exports sensibles n’acceptent que les ressources de confiance ; ajoutez un script de confiance avec tosun_ac_trusted_resources dans server.cfg. Les détails figurent dans RELEASE-9.3.0.md et INTEGRATION.md dans le paquet.

Nouveautés 9.2.0#

Le menu d’administration en jeu a été repensé. Il s’ouvre désormais comme un panneau au bord de l’écran pour que le jeu reste visible ; le bouton d’ancrage le déplace de l’autre côté. Ctrl K trouve n’importe quel joueur ou action, les joueurs détectés pendant la session sont listés en premier, et expulser, bannir, avertir et donner une arme ouvrent un petit formulaire qui nomme la cible. Tuer, débannir, supprimer à proximité et toute action à l’échelle du serveur demandent une seconde pression. Les noms de joueurs ne peuvent plus injecter de script dans le menu, et les réglages allowEsp, allowFreecam et allowDelete du menu d’administration sont désormais appliqués.

Nouveautés 9.1.0#

Une nouvelle protection côté serveur lit l’état du joueur que OneSync réplique vers le serveur : super saut, invincibilité, invisibilité, noclip avec collision désactivée, multiplicateurs de dégâts et de défense des armes, armes sur liste noire tenues en main et caméra éloignée du joueur (spectate/freecam). Ces contrôles continuent de fonctionner même si un cheat arrête l’anti-cheat côté client. Les contrôles fiables expulsent par défaut ; ceux qui dépendent du contexte se contentent de journaliser jusqu’à ce que vous les renforciez dans la section v25 des réglages de l’anti-cheat. Les contrôles non pris en charge par votre build serveur sont désactivés automatiquement et listés dans la console du serveur.

Nouveautés 9.0.3#

Validation et limites de fréquence des événements serveur ; lecture de données à la demande ; jetons de téléversement temporaires sans droits de gestion du panel. Aucun anticheat ni protection de paquet ne garantit de bloquer toutes les attaques.