Réglages du framework

QBCore et ESX#

Seuls certains schémas et champs indexés sont pris en charge. Colonnes absentes ou identifiants personnalisés peuvent bloquer une requête. Une réponse vide ou non compatible ne signifie pas que la base est vide.

Fonctions personnalisées#

Testez personnages, métiers, téléportations et garages sur un serveur de test. Validez les droits côté serveur et accordez uniquement des exceptions ciblées depuis du code fiable.

Distinguer framework et inventaire#

Identifiez la ressource d’état joueur : qb-core, qbx_core ou es_extended. Examinez séparément inventaire et adaptations API. Un nom connu ne garantit pas tous les scripts bancaires ou d’inventaire externes. Conservez les dépendances ; ne lancez pas des cores concurrents pour dépanner.

Modifiez le champ existant : qb pour QBCore, qbox pour Qbox ; ce sont des valeurs, pas des dossiers. auto permet la détection. Vérifiez le mode dans les messages et GetStatus côté serveur. Le pont détecte séparément les cores actifs et peut signaler un démarrage manquant.

-- Modifier le champ existant, pas toute la table.
ts.Framework.framework = "qb"
-- Autres valeurs prises en charge : "esx", "qbox", "auto", "standalone"

Vérifier les données du personnage#

Les lectures utilisent citizenid avec QBCore/Qbox et identifier avec ESX. L’ID serveur temporaire ne remplace pas l’identifiant personnage. Colonnes et index compatibles sont nécessaires ; une structure personnalisée peut être refusée.

1. Comparez un personnage test dont espèces, banque, métier et véhicule sont connus.
2. Avec ox_inventory, comparez un petit inventaire en ligne. Respectez les troncatures ; pas de stashes ni métadonnées arbitraires.
3. En cas d’erreur API, vérifiez lancement et version. Une API indisponible signifie possession inconnue, pas arme absente prouvée.

• Pont de base de données (Tosun Connect)

Tester les parcours réels#

La détection ne connaît pas les droits, positions, prix ou récompenses de chaque événement personnalisé. Votre script doit les vérifier côté serveur. Un profil ne sécurise pas automatiquement un événement argent/item vulnérable. Validez source et session avant intégration.

Standalone/vRP peuvent utiliser des contrôles généraux adaptés ; le pont ne promet pas leurs schémas personnalisés. Expliquez les limites plutôt que substituer des tables étrangères. Recontrôlez après mises à jour core, inventaire ou métiers.

Notez versions core et inventaire. Après redémarrage core, reconnectez le personnage avant de juger l’API en ligne. Ne changez pas schéma et sanction ensemble : séparer permet diagnostic et restauration.

• Changement de personnage et réanimation ne laissent pas d’exemption permanente.
• Maison, garage et prison appellent MarkTeleport juste avant le déplacement.
• Armes d’arène sans inventaire utilisent un AllowWeapon court depuis un script serveur de confiance.
• Testez police, outils, boutiques et grosses récompenses contre les logs avant des sanctions plus fortes.

• Exports et confiance
• Sécurité officielle des événements

Interpréter noms de configuration et cores détectés#

La configuration AC et le connecteur emploient parfois des noms différents : QBCore utilise qb dans les réglages, tandis que le pont indique qbcore. Qbox utilise qbox et la ressource qbx_core active. Lisez ces noms dans leur contexte au lieu de les adapter à un dossier. L’installation automatique peut reconnaître vrp ou ox_core et sélectionner un nom ; cela ne crée pas d’adaptateur compatible de personnages ou d’économie pour le pont. Avec un core non pris en charge, choisir explicitement standalone pour la protection générale évite de considérer un nom détecté comme une intégration complète.

1. Vérifiez configs/anticheat_config.lua et le core réellement démarré ; conservez un choix volontaire et l’ordre des dépendances.
2. Si les capacités du panneau diffèrent, examinez cores actifs et état du pont avant de renommer un réglage au hasard.
3. Ne démarrez pas qb-core, qbx_core et es_extended ensemble uniquement pour changer l’étiquette de statut.

Construire les tests selon les rôles réels#

Testez séparément joueurs ordinaires, police ou autres métiers et personnel. Les membres du personnel peuvent être exemptés ; vérifiez aussi avec un personnage normal. Couvrez connexion, sélection, mort et réanimation, maisons, garages, armes d’inventaire et véritables récompenses des métiers. Notez destination, objet ou solde attendu et trace observée. Testez annulation et réussite des menus et activités. Un démarrage sans erreur ne prouve pas qu’un inventaire modifié, un script bancaire ou une sélection de personnages utilise les API attendues.

1. Répétez la même petite série avant et après une mise à jour du core ou inventaire, un composant à la fois.
2. Pour un échec, notez versions, ressource appelante et rôle du joueur ; protégez les données identifiantes.
3. Reconnectez après redémarrage ou changement de personnage et vérifiez la fin des exemptions temporaires, pas seulement le parcours du personnel.

Attribuer les responsabilités des scripts personnalisés#

Séparez réglages de détection et règles détenues par vos scripts de jeu. AC ne connaît pas destinataires autorisés de virements personnalisés, plafonds de récompense ou propriétaires de maisons. Ces ressources vérifient joueur, droits et état serveur avant de modifier argent, objets ou position. Les vérifications d’armes utilisent les API compatibles ; une API indisponible signifie inconnu, pas une arme créée illégitimement. Si les lectures échouent à cause des colonnes ou index, examinez la compatibilité indépendamment des sanctions. Ne sanctionnez pas les joueurs pour une erreur d’intégration et ne remplacez pas un adaptateur absent par une exemption générale.

1. Désignez un responsable de l’adaptateur framework ou inventaire et un propriétaire de chaque action personnalisée.
2. Reproduisez une action autorisée et un refus de permission avec les validations du script concerné.
3. Séparez protection AC générale et pont de base de données du panneau (Tosun Connect) ; les tables personnalisées demandent une intégration examinée.

Séparer inventaire des armes et détail du personnage#

Framework et inventaire peuvent différer : QBCore gère personnages et argent, ox_inventory les objets. Le contrôle d’armes privilégie ox_inventory actif, sinon les API compatibles QBCore/Qbox ou ESX. Le détail du panneau est une autre opération. Un objet visible ne confirme pas même source, heure et format pour tous les contrôles. Changer un nom ne synchronise pas les armureries personnalisées.

Loadout ESX et quantité d’inventaire par objets diffèrent. nil, erreur ou données inattendues ne prouvent pas absence. Vérifiez la méthode et notez attribution, action normale, fournisseur et résultat. Une intégration AllowWeapon examinée peut couvrir des armes légitimes serveur hors inventaire dans la portée nécessaire. C’est un contrôle de compatibilité, pas la promesse de résoudre chaque défaut de détection.

Considérer la migration au-delà des noms de tables#

Passer entre QBCore et ESX ne change pas seulement une étiquette. Le pont utilise players/citizenid en QBCore, users/identifier en ESX. Ancienne session ou nom affiché ne désigne pas le personnage migré. Argent, véhicules, inventaire et règles peuvent varier. Ne renommez pas la production pour des requêtes. Le transfert relève du plan du serveur ; AC n’est pas un convertisseur de données manquantes.

Choisissez un personnage et véhicule connus dans un test séparé. Notez core, identité persistante, cash/bank et présence en ligne avant une petite lecture. Une erreur de schéma ou index ne prouve pas perte. Faites examiner la compatibilité. La modification des soldes depuis le panneau est active par défaut ; ne l’utilisez pas avant validation. Pour la bloquer, utilisez le mode manuel : set tosun_db_bridge_manual "1" et set tosun_db_bridge_enabled "1" dans server.cfg, sans tosun_db_bridge_money_write. Retestez sélection et inventaire normal. Validez les bonnes données du bon personnage, pas seulement le démarrage.