Installation Anticheat QBCore : Dépendances et Tests

Vérifiez dépendances, personnages, armes, données du panel et lancement sur qb-core.

Un core actif ne garantit pas la même API à chaque banque/inventaire. Conservez votre pile et vérifiez l’intégration.

Points à vérifier

• qb-core actif ; qb ou auto vérifié.
• Distinguer citizenid de source temporaire.
• Tester armes inventaire et arène séparément.
• Événements propres vérifient droits, montant et activité côté serveur.

Ordre d’installation et d’activation

1. Créez le compte avec Sign up, vérifiez l’e-mail et le paiement du forfait payant adapté.
2. Choisissez le serveur, sauvegardez ressource/réglages/base du jeu et téléchargez son paquet.
3. Décompressez dans tosun-ac ; licence uniquement dans server.cfg avec set.
4. Conservez les dépendances, réglez le champ framework AC et démarrez en maintenance.
5. Testez avec un personnage dédié ; notez version, date et résultats.

Exemple initial de server.cfg

set tosun_ac_license "YOUR_SERVER_LICENSE"

ensure oxmysql
ensure qb-core
ensure tosun-ac

Évaluer le résultat

• Démarrage indique version et framework réels.
• Parcours légitimes ne causent ni sanction inattendue ni exemption permanente.
• Données correspondent au bon serveur/personnage ; limites explicites.
• Performances et faux positifs sont évalués sur un jeu représentatif.

Réglage QBCore et périmètre

Modifiez ts.Framework.framework existant en qb dans configs/anticheat_config.lua, sans remplacer la table. Avec ox_inventory, conservez dépendances et compatibilité. La vérification privilégie ox_inventory actif ; une erreur API ne prouve pas l’absence de possession.

Test personnage et économie

Le pont lit champs/index compatibles de players par citizenid et player_vehicles. Il ne copie pas toutes les banques ou stashes. Connexion et modification du solde en ligne sont actives par défaut, sans ligne server.cfg dédiée ; les anciennes lignes tosun_db_bridge_enabled et tosun_db_bridge_money_write sont ignorées tant que le mode manuel est désactivé. Seuls les utilisateurs du panel avec le rôle admin ou owner fixent le solde, personnage connecté et solde attendu identique ; vérifiez d’abord les lectures. Pour arrêter sur ce serveur : Disable connection sur la carte Tosun Connect (Serveurs → le serveur). Avancé : avec set tosun_db_bridge_manual "1" dans server.cfg, ces deux lignes sont de nouveau lues dans server.cfg et chacune reste désactivée si elle ne vaut pas "1" ; la ligne manual seule coupe la connexion et la modification du solde, et manual "1" plus enabled "1" garde les lectures et bloque la modification du solde.

1. Connectez un personnage dont métier, espèces, banque et véhicule sont connus.
2. Le pont est actif par défaut : lisez un personnage dans le panel et comparez au jeu.
3. Changez personnage, relisez et vérifiez que l’ancienne identité/source n’est pas utilisée.
4. Testez maisons, garages, police et armes d’arène sans inventaire.
5. Vérifiez que la récompense refuse montant arbitraire ou autre joueur choisi par client.

Préparer une installation récupérable

Notez la version de l’artifact et les noms des ressources du framework et de l’inventaire. Téléchargez le paquet du serveur sélectionné dans Servers : une autre licence peut relier la mauvaise installation. Vérifiez l’abonnement payant et votre droit de gestion. Gardez le ZIP privé.

1. Sauvegardez tosun-ac, les réglages modifiables et la base du jeu. Vérifiez l’accès à la sauvegarde avant tout remplacement.
2. Décompressez dans un dossier séparé. fxmanifest.lua doit se trouver directement dans tosun-ac, sans second dossier imbriqué.
3. Comparez vos réglages aux nouvelles valeurs par défaut. Reportez les modifications voulues et les intégrations ; ne remplacez pas toute la nouvelle configuration par l’ancienne.

Signaler juste avant le téléport

Validez joueur, destination serveur, droit et activité. Appelez MarkTeleport immédiatement avant le déplacement. src et destination viennent du flux serveur validé, pas de paramètres libres du client. Ce fragment n’est pas un événement réseau complet.

Aucune liste requise. Assouplit brièvement mouvement et visibilité/godmode/caméra associés ; armes, argent, abus d’événements et injection restent actifs. Avec les réglages par défaut, pour les ressources hors liste de confiance : 15 secondes par appel, 180 par joueur sur dix minutes. Les extensions consomment le budget ; pas d’appel chaque tick.

-- Dans un flux serveur déjà validé :
local ok = exports["tosun-ac"]:MarkTeleport(src, 8000, "house_enter")
if ok then
    SetEntityCoords(GetPlayerPed(src), destination.x, destination.y, destination.z)
end

Mesurer une référence reproductible

Profilez une session représentative avant les changements. Notez joueurs, artifact, versions et activité. Roleplay calme, garages pleins et combats diffèrent. Après un seul réglage, comparez le même scénario. CPU, hitches et requêtes valent mieux qu’un gain FPS promis.

Les commandes enregistrent un échantillon borné. Attendez la fin et identifiez ressource et thread responsables du pic. Tous les hitches ne viennent pas de l’AC. Gardez valeurs et comparaison privées ; une courte mesure ne couvre pas tous les pics.

profiler record 500
profiler status
profiler view

tosunac_doctor

Choisir les sanctions selon le contexte

Observez les contrôles contextuels et testez le jeu normal. Un log n’ordonne pas de bannir tout joueur concerné. Vérifiez personnage, réanimation, téléports, police et armes scriptées. Préférez une intégration ciblée à une exemption permanente.

tosunac_doctor rapporte les valeurs actives risquées sans les modifier. Examinez sanctions fortes, protections coupées, debug et fail-open. Le panel peut remplacer les valeurs locales ; vérifiez les valeurs effectives.

Une exemption peut masquer les plaintes sans résoudre leur cause. Listez exceptions temporaires, dates et scripts. Après vérification, retirez l’exception et répétez le parcours en comparant les logs.

• Modifier un réglage et noter motif, relecteur et ancienne valeur.
• Comparer répétitions aux actions légitimes et horaires.
• Retester après changement de sanction, core ou inventaire.
• En cas de faux positif nouveau, restaurer et résoudre la cause avant de durcir.

Mises à jour, restauration et support

Retestez après changement de core, inventaire, métiers ou AC. Ne modifiez pas schéma, sanction et version ensemble. Si le changement échoue, restaurez ressource et réglages en maintenance ; évaluez la perte de données avant restauration de base. Fournissez versions artifact/core/inventaire/AC, ressource, étapes, heure et première erreur expurgée au support. Aucun identifiant joueur, licence, mot de passe ou token public.

Détails associés

Documentation d’installation · Pont de base de données · Exports serveur

Sign upDocumentation Voir les tarifs

Questions fréquentes

En relation: ESX · Standalone · vRP · OX/Qbox · Guides framework · Détection de RedEngine