Logo ACStudioACSTUDIOFIVEM DEVELOPMENT
cdt_admin / DOCUMENTATION

Framework Qbox / ESX

cdt_admin détecte automatiquement qbx_core ou es_extended parmi les ressources démarrées. Aucun choix de framework n'est requis. Un seul des deux cores doit fonctionner ; le script refuse une installation ambiguë ou sans framework.

Ordre de démarrage

Sous ESX Legacy 1.15.2 :

ensure oxmysql
ensure ox_lib
ensure es_extended
# Démarrer ensuite les ressources utilisées : inventaire, médical, target, etc.
ensure cdt_admin

Sous Qbox, conserver le démarrage de qbx_core avant cdt_admin. La bibliothèque Qbox est chargée uniquement lorsqu'il est détecté. Redémarrer cdt_admin après un changement de framework. Le bridge ne migre pas une base Qbox vers ESX.

Fonctionnement

  • server/framework.lua centralise joueurs, métadonnées, comptes, métiers, grades et spawn de véhicules.
  • server/framework_events.lua traduit les événements des cores vers les événements internes de CDT.
  • client/framework.lua maintient les données client et le cycle connexion / changement de personnage.
  • Les requêtes de noms utilisent une relation en lecture normalisant users sous ESX et players sous Qbox. Aucune vue SQL ni table ESX supplémentaire n'est créée.
  • Les champs internes citizenid contiennent l'identifiant ESX complet, préfixe multichar compris. Les tables CDT continuent de conserver ces chaînes. Les identifiants numériques représentent toujours les IDs serveur.
  • cash correspond au compte ESX money, bank à bank. Les autres comptes configurés, notamment black_money, sont exposés avec leur nom réel.
  • Les grades CDT restent indépendants des groupes administratifs ESX. Attribution console : cdt_admin_setgrade <ID serveur ou identifiant personnage> <grade> ; récupération owner : ACE cdt_admin.owner.
  • Les grades CDT sont conservés dans users.metadata.cdt_admin. La sauvegarde ciblée préserve les autres métadonnées et fonctionne aussi hors ligne.
  • Les changements d'argent et de métier ESX sont réservés aux personnages connectés. Les personnages hors ligne restent consultables et peuvent recevoir un grade ou une sanction ; une opération économique hors ligne est refusée.
  • Les définitions de grades métier ESX sont enregistrées dans job_grades, puis ESX et les métiers des joueurs connectés sont actualisés. La suppression du dernier grade ou d'un grade attribué est refusée.

Intégrations

L'inventaire natif ESX est sélectionné automatiquement lorsqu'aucun inventaire tiers compatible n'est sélectionné et que Config.CustomInventory est désactivé. Lecture et don/retrait sont disponibles dans le panneau inventaire CDT. L'action d'inspection ouvre ce panneau pour les fournisseurs sans confirmation fiable des transferts natifs, y compris ESX et AK47. Pour les images, configurer cdt_admin:inventoryImages si nécessaire.

Avec un inventaire tiers, les bridges existants restent utilisés ; sa compatibilité dépend des API de la version installée. Avec Config.CustomInventory actif, CDT ne substitue pas l'inventaire natif au fournisseur absent.

esx_ambulancejob est reconnu par le bridge médical : dispatch des événements de réanimation et soins, lecture de l'état isDead. Les autres fournisseurs médicaux conservent leurs adaptateurs. Le succès de ces actions indique l'envoi de la commande au système médical, sans confirmer la fin de son animation.

Le remplissage faim/soif ESX utilise esx_status avec l'échelle standard de 1 000 000. Un système personnalisé doit être adapté. Le stress dépend du HUD installé.

Les garages et véhicules possédés dépendent du script de garage installé. Le garage officiel esx_garage dispose d'un raccordement spécifique ; les variantes commerciales utilisent les contrats et adaptateurs décrits dans docs/04-integrations/GARAGE_BRIDGE.md. Les gangs, les droits boss/société spécifiques et les comptes société ESX nécessitent leurs propres adaptateurs. Un gang ne devient jamais un groupe administratif ESX.

Les fournisseurs d'inventaire, garage et ambulance sont sélectionnés indépendamment du framework. La météo utilise exclusivement le moteur interne CDT ; les ressources météo externes doivent être arrêtées. Consulter docs/04-integrations/INVENTORY_BRIDGE.md, docs/04-integrations/GARAGE_BRIDGE.md, docs/04-integrations/MEDICAL_BRIDGE.md et docs/04-integrations/WEATHER_BRIDGE.md pour les API, les options de sélection et les fonctions nécessitant un adaptateur. Plusieurs fournisseurs actifs exigent une sélection explicite. Les bridges ne substituent pas un export ou un schéma de base supposé à une API absente.

Vérifications

Les commandes ci-dessous concernent le dépôt de développement. Les tests ne sont pas inclus dans le ZIP de livraison.

lua tests/framework-esx.lua vérifie le démarrage ESX sans Qbox, la détection, les identifiants multichar, les comptes, les grades, les permissions, le SQL normalisé, l'inventaire natif et le nettoyage des caches au changement de personnage.

lua tests/framework-client.lua vérifie les données et événements client pour ESX et Qbox. lua tests/framework-events.lua vérifie la traduction des événements Qbox. node tests/run-lua.cjs exécute toute la suite Lua.

Les tests utilisent des environnements simulés ; ils ne remplacent pas une validation sur un serveur ESX avec sa base et ses ressources réelles.

← Tous les guides