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.
Guide de décision rapide
| Point de départ | Premier framework à évaluer | Raison de vérifier |
|---|---|---|
| Serveur ESX existant | ESX Legacy | Préserve les données, événements, exportations et connaissances des ressources spécifiques à ESX lorsque les exigences actuelles sont toujours satisfaites. |
| Serveur QBCore existant | QBCore | Évite la conversion à moins qu'un autre framework ne résolve une exigence documentée qui la justifie. |
| Nouvelle construction orientée QB | QBCore ou Qbox | Comparez les deux recettes officielles, les ressources sélectionnées, le modèle API et la compatibilité exacte avec les tiers. |
| Équipe QBCore envisageant Qbox | Qbox avec audit de pont | Le pont QB aide de nombreuses ressources, mais les exceptions documentées nécessitent toujours des vérifications au niveau des ressources. |
| Aucune exigence de framework de jeu de rôle | Ressources Standalone | Standalone décrit un modèle de dépendance ; confirmez si un framework complet est réellement inutile. |
Ce que fait un framework FiveM
Cfx.re décrit les frameworks comme des fondations qui facilitent la création de ressources de serveur. Un framework de jeu de rôle établit généralement des modèles partagés pour les données des joueurs et des personnages, les emplois, les objets, l'argent, les commandes, les permissions et la communication entre les ressources. Les fonctionnalités exactes visibles par les joueurs dépendent de la recette complète et des ressources installées, et non seulement du nom du framework principal.
Cette distinction empêche une comparaison trompeuse. Les systèmes d'inventaire, de logement, de téléphone, bancaires ou de véhicules peuvent être des ressources distinctes et peuvent être remplacés. Une coche à côté d'un nom de framework ne prouve pas quelle implémentation, version ou intégration un serveur de production exécutera.
ESX Legacy
ESX Legacy est un framework de jeu de rôle open-source dont le cœur actuel est publié par l'organisation officielle ESX. Le tutoriel officiel pour les nouveaux serveurs utilise le modèle txAdmin de ESX Legacy. L'installation manuelle documente oxmysql, spawnmanager, l'importation de base de données, les ressources de base et complémentaires, les exclusions et l'ordre de démarrage.
ESX est la première option à évaluer lorsqu'un serveur existant possède déjà des données de joueur, des ressources et des procédures d'équipe spécifiques à ESX. Il s'agit d'une observation du risque de migration, et non d'une revendication de part de marché. Pour une nouvelle construction, inspectez la recette actuelle et vérifiez que chaque produit requis prend en charge la version ESX exacte, l'inventaire, la bibliothèque de base de données, les exportations et les événements.
QBCore
La ressource officielle qb-core de QBCore expose un Core Object regroupant des fonctions, des données de joueurs, des données partagées, la configuration et des commandes. Les définitions partagées comprennent les métiers, les gangs, les objets et les véhicules. L’installation officielle pour Windows utilise la recette QBCore Framework proposée parmi les recettes populaires de txAdmin. Cette recette déploie une base de données et un ensemble de ressources, et pas seulement le dossier du cœur.
QBCore peut convenir à un projet nouveau ou existant dans l’écosystème QB lorsque ses API documentées et ses ressources compatibles répondent aux besoins du serveur. N’en déduisez pas que chaque ressource portant l’étiquette QBCore prend en charge toutes les versions du cœur ou tous les inventaires de remplacement. Notez les exports requis, les dépendances, le SQL et l’ordre de démarrage pour la configuration exacte.
Qbox
L'introduction officielle de Qbox indique que Qbox a commencé en 2022 à partir de QBCore et possède maintenant ses propres API et ressources de base. Qbox maintient un pont de compatibilité QB pour de nombreuses ressources QBCore correctement écrites. Sa documentation nomme également des exceptions, y compris les ressources qui dépendent d'un accès direct à la base de données, de fichiers de base internes ou d'un comportement non pris en charge.
L’installation officielle de Qbox utilise la recette QBox proposée dans les recettes populaires de txAdmin. Pour une migration depuis QBCore, le guide de conversion couvre les différences de configuration, les grades numériques des métiers et des gangs, la conversion de l’inventaire et de la base de données, ainsi que le remplacement progressif des API. Choisir Qbox nécessite donc une décision réfléchie et un audit de compatibilité ; ce n’est pas un simple réglage qui permet à tous les scripts QBCore de fonctionner sans modification.
Dimensions de comparaison que vous pouvez vérifier
| Dimension | Question | Preuve |
|---|---|---|
| Chemin d'installation | Existe-t-il une recette officielle actuelle et une documentation complète ? | Documentation officielle et dépôt de recettes à la date de révision. |
| Ressources requises | Quelles bases de données, bibliothèques, inventaires et ressources de support sont sélectionnées ? | Fichiers de recettes, manifestes et déclarations de dépendances. |
| Compatibilité API | Quelles exportations, événements, objets et champs de données les scripts requis appellent-ils ? | Source des ressources, manifestes et documentation officielle API. |
| Modèle de données | Quels identifiants, grades, comptes et relations doivent être préservés ? | Inventaire du schéma et mappage de migration testé. |
| Opérations | L'équipe peut-elle mettre à jour, diagnostiquer et restaurer la pile ? | Procédures opérationnelles, sauvegardes et exercice de restauration en préproduction. |
| Performances | Comment la pile exacte se comporte-t-elle sous des actions représentatives ? | Profileur, resmon et journaux de base de données issus de tests contrôlés répétés. |
Liste de contrôle des décisions
- Listez les fonctionnalités de joueur requises. Nommez les exigences exactes en matière d'emplois, d'économie, d'inventaire, de logement, de téléphone, de véhicule, d'administration et d'intégration.
- Inventaire des dépendances existantes. Enregistrez les versions du framework, les manifestes, les tables de base de données, les exportations, les événements et les modifications personnalisées du noyau.
- Établissez la correspondance des ressources prises en charge. Pour chaque ressource requise, confirmez le framework et la version qu'elle prend réellement en charge, y compris les ponts et les systèmes de remplacement.
- Vérifiez les connaissances de l'équipe. Incluez les API, les langages, le modèle de base de données et les outils opérationnels que les mainteneurs peuvent diagnostiquer.
- Estimez la migration à partir des preuves. Comptez les domaines de données réels et les intégrations ; n'utilisez pas de tableau générique d'heures ou de coûts.
- Construisez une pile de test représentative. Utilisez la recette officielle, les ressources sélectionnées et une copie nettoyée de données réalistes.
- Définissez l'acceptation et le retour en arrière. Décidez ce qui doit fonctionner et comment restaurer les fichiers et la base de données cohérents précédents.
La migration affecte l'ensemble du modèle de serveur
Changer de framework peut impliquer des identités, des personnages, de l'argent, des emplois, des gangs, des inventaires, des véhicules, des garages, des logements, des téléphones, des services bancaires, des comptes sociaux, des autorisations et des événements personnalisés. Les relations de données sont importantes : créer un nouvel identifiant de personnage sans mapper tous les enregistrements associés peut orpheliner des actifs ou des autorisations.
N'exécutez pas un extrait de conversion SQL générique sur la production. Commencez par un inventaire de schémas et de ressources, concevez une conversion idempotente sur une copie de test, validez les nombres d'enregistrements et les relations, et répétez le retour en arrière. Les scripts spécifiques au framework peuvent nécessiter un pont officiel, un mode multi-framework documenté ou des modifications de code. Les scripts ESX ne sont pas automatiquement portables vers QBCore ou Qbox, et le pont Qbox QB n'est pas universel.
Comment évaluer votre propre pile
Si les performances influencent le choix, comparez des builds contrôlés plutôt que de répéter un classement. Utilisez le même hôte ou un matériel équivalent isolé, un artefact FXServer, une version de base de données, un volume de données et des actions de joueur représentatives. Gardez l'ensemble de ressources fonctionnellement comparable et indiquez chaque différence intentionnelle.
- Effectuez la même phase de chauffe pour chaque serveur et mesurez son comportement au repos.
- Répétez les mêmes actions de chargement de personnage, d'inventaire, de travail, de véhicule et d'économie.
- Recueillez des preuves du profileur FiveM ou de resmon, ainsi que des requêtes lentes de la base de données et des métriques système.
- Exécutez plusieurs échantillons et signalez les distributions ou les plages, pas un seul meilleur chiffre.
- Examinez les erreurs, l’exactitude des données et le comportement lors des reconnexions en plus des temps mesurés.
- Conservez la configuration et les journaux bruts afin qu'un autre examinateur puisse reproduire la conclusion.
Un benchmark d'un seul cœur avec des ressources différentes n'isole pas le framework. Un résultat d'un serveur vide synthétique ne prouve pas la capacité de production. Ne publiez que les conclusions étayées par la configuration enregistrée et les preuves brutes.
Recommandation pratique
- Choisissez ESX lorsque les ressources, les données et les connaissances de l'équipe actuelles de ESX satisfont le mieux aux exigences et que la migration n'a aucun avantage prouvé.
- Choisissez QBCore lorsque la recette officielle de QB et l'écosystème documenté conviennent à une nouvelle construction ou à un serveur QB existant.
- Choisissez Qbox lorsque l'équipe souhaite délibérément la recette et les API actuelles de Qbox et peut effectuer un audit de pont QB ou de migration.
Ouvrez les guides de framework dédiés pour l'installation officielle actuelle et la limite de compatibilité. Ensuite, faites correspondre les ressources commerciales à la pile exacte choisie plutôt que de traiter une étiquette de catégorie large comme preuve finale.
Guides de framework détaillés
Consultez ensuite les instructions d’installation et les limites de compatibilité propres à ESX Legacy, à QBCore ou à la configuration Qbox et Ox.
Documentation de référence
Cfx.re — frameworks · Source : docs.qbox.re · Source : qbcore-fivem/qb-core · Source : esx-framework/esx_core