Utilisation simultanée d'ESX et de QBCore : pourquoi ce n'est pas faisable

Réponse directe : N’exécutez pas ESX et QBCore comme deux cœurs faisant autorité pour les mêmes joueurs. Les deux peuvent techniquement démarrer comme ressources FiveM, mais ils modélisent différemment l'identité, les métiers, l'argent, l'inventaire, les callbacks et les événements. Sans un pont conçu à cet effet et une source de vérité déclarée, l'état dupliqué devient dangereux et difficile à récupérer.

Pourquoi deux cœurs entrent en conflit

Domaine	Risque avec deux autorités	Contrôle requis
Identité	Un joueur peut recevoir des enregistrements ESX et QBCore non liés.	Une identité canonique et un mappage explicite.
Argent et métiers	Les mises à jour peuvent diverger ou être appliquées deux fois.	Un seul système responsable des écritures et des règles de conversion testées.
Inventaire	Les éléments, les métadonnées et la sémantique de stockage diffèrent.	Une seule autorité d'inventaire ; des adaptateurs à la frontière.
Événements et rappels	Des actions de jeu similaires peuvent déclencher des gestionnaires de framework non liés.	Des adaptateurs vérifiés avec des espaces de noms distincts plutôt qu’une réplication globale.
Dépendances	Une ressource peut détecter le mauvais cœur ou utiliser une API non prise en charge.	Tests de dépendance et d'ordre de démarrage exacts.

Ce qui est réalisable

Un serveur peut exécuter un adaptateur de compatibilité pour une ressource spécifique lorsque l'adaptateur a un contrat étroit et qu'un framework reste faisant autorité. Qbox, par exemple, documente un pont QB et ses limites. C'est différent de l'exécution de deux économies et modèles de joueurs complets côte à côte.

Liste de contrôle des décisions

1. Nommez le cœur faisant autorité pour l'identité, les métiers, l'argent et l'inventaire.
2. Listez les ressources héritées précises qui bloquent la migration.
3. Privilégiez le remplacement ou le portage de chaque ressource ; utilisez un pont uniquement si son contrat est documenté et testable.
4. Testez les appels non autorisés, les reconnexions, les redémarrages et les défaillances partielles des dépendances.
5. Si les deux cœurs doivent écrire dans le même domaine, arrêtez-vous et revoyez la conception avant la mise en production.

Portée et limites

Il n'y a pas de réponse universelle pour chaque fork ou adaptateur personnalisé. Un pont soigneusement conçu peut traduire une surface API limitée, mais il doit préciser les responsabilités sur les données, le comportement en cas d'échec et les règles de persistance. N'interprétez pas “compatible QB” comme une preuve de compatibilité QBCore complète sur un autre framework.

Sources primaires

• Cfx.re : Frameworks
• ESX : dépôt officiel esx_core
• QBCore : dépôt officiel qb-core
• Qbox : documentation officielle

• Qbox FAQ : limites de compatibilité QBCore
• Convars du pont qbx_core de Qbox