Français
Réponse directe : la migration d'ESX vers QBCore est une réécriture contrôlée et une migration de données, pas un simple changement de framework. Créez un serveur de staging QBCore propre, inventoriez chaque dépendance ESX, définissez une correspondance de données explicite champ par champ, portez les ressources sur les API actuelles, répétez la procédure de rollback et ne basculez qu'une fois les vérifications référentielles et de gameplay réussies.
Choisissez Qbox pour un nouveau serveur lorsque vous souhaitez son stack moderne intégré à OX et que vous êtes prêt à suivre ses conventions. Gardez QBCore lorsque votre serveur stable dépend de ressources spécifiques à QBCore et qu'une migration n'a pas d'avantage clair. Qbox fournit un pont de compatibilité pour la plupart des scripts QBCore correctement écrits, mais la compatibilité n'est pas universelle.
Qbox est un framework de jeu de rôle pour FiveM qui a commencé comme un fork de QBCore et fournit maintenant ses propres API et ressources de base. Il maintient un pont de compatibilité pour de nombreuses ressources QBCore correctement écrites, mais l'accès direct à la base de données, l'accès aux fichiers internes et les comportements non pris en charge sont des exceptions documentées. Utilisez la recette officielle Qbox txAdmin pour une nouvelle installation et auditez chaque ressource avant une migration.
Déplacez une ressource de mysql-async vers oxmysql en modifiant sa configuration de pilote et en examinant les paramètres, la valeur de retour et la gestion des erreurs de chaque requête. Une migration de pilote ne nécessite pas de réécrire votre schéma de base de données et ne garantit pas un gameplay plus rapide.
Un adaptateur de framework donne à votre ressource une petite interface tout en gardant les détails ESX, QBCore et Qbox au même endroit. Commencez par une opération en lecture seule, vérifiez-la sur chaque framework pris en charge, et n'ajoutez des opérations d'argent ou d'inventaire que lorsque leur comportement en cas d'échec est défini.
Convertissez une ressource FiveM en mappant son framework, son inventaire et ses dépendances de base de données, puis en testant un flux de jeu à la fois. Renommer les événements ESX en événements QBCore n'est pas une conversion complète. Une migration de personnage à l'échelle du serveur est un projet distinct.
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.
ESX Legacy est un framework de jeu de rôle open source pour FiveM. Pour un nouveau serveur, utilisez le modèle officiel ESX Legacy dans txAdmin ou suivez toute la documentation d’installation officielle. Installer uniquement le dossier es_extended ne constitue pas une installation complète du serveur : l’ensemble pris en charge comprend des opérations sur la base de données, des ressources nécessaires et une configuration ordonnée du démarrage.
QBCore est un framework de jeu de rôle open source pour FiveM. Sa ressource qb-core expose des données de joueur partagées, des fonctions du framework, des commandes et des définitions utilisables par les autres ressources QB. Pour un nouveau serveur, utilisez la recette txAdmin officielle de QBCore plutôt que de considérer le dossier qb-core comme une installation complète.
Il n'y a pas de gagnant universel officiel entre ESX, QBCore et Qbox. Choisissez le framework dont la recette actuelle, les API et les ressources compatibles correspondent aux fonctionnalités de serveur requises, aux données existantes et aux compétences de votre équipe. Si vous utilisez déjà une pile stable spécifique à un framework, rester dans cet écosystème est généralement la première option à évaluer car la migration touche plus que le dossier principal.
