Il n’existe 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 requises de votre serveur, aux données existantes et aux compétences de votre équipe. Si vous exploitez déjà une pile spécifique à un framework stable, 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 à vérifier |
|---|---|---|
| Serveur ESX existant | ESX Legacy | Préserve les données, événements, exports et connaissances des ressources spécifiques à ESX lorsque les exigences actuelles sont toujours satisfaites. |
| Serveur QBCore existant | QBCore | Évite la conversion sauf si un autre framework résout 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 d’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 des exceptions documentées nécessitent encore des vérifications au niveau des ressources. |
| Aucune exigence de framework de roleplay | Ressources autonomes | Autonome 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 construction de ressources serveur. Un framework de roleplay é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 ressources. Les fonctionnalités exactes visibles par les joueurs dépendent de la recette complète et des ressources installées, pas seulement du nom du framework principal.
Cette distinction évite une comparaison trompeuse. L’inventaire, le logement, les téléphones, les systèmes bancaires ou de véhicules peuvent être des ressources séparées 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 roleplay open source dont le noyau actuel est publié par l’organisation officielle ESX. Le tutoriel officiel pour nouveau serveur utilise le modèle txAdmin ESX Legacy. La documentation d’installation manuelle mentionne oxmysql, spawnmanager, l’importation de base de données, le noyau et les ressources additionnelles, 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 joueurs, des ressources et des procédures d’équipe spécifiques à ESX. Il s’agit d’une observation sur le risque de migration, pas d’une affirmation de part de marché. Pour une nouvelle construction, inspectez la recette actuelle et vérifiez que chaque produit requis prend en charge la version exacte d’ESX, l’inventaire, la bibliothèque de base de données, les exports et les événements.
QBCore
Officiel de QBCore QB-Noyau expose un objet Core avec des fonctions, des données de joueur, des données partagées, une configuration et des commandes. Les définitions partagées incluent les emplois, les gangs, les objets et les véhicules. L’installation officielle Windows utilise la recette populaire du framework QBCore dans txAdmin, et la recette déploie une base de données et un ensemble de ressources plus large plutôt que seulement le dossier core.
QBCore est un candidat pour une nouvelle construction ou une construction existante de l’écosystème QB lorsque ses API documentées et ses ressources compatibles couvrent les exigences du serveur. Ne déduisez pas que chaque ressource portant une étiquette QBCore prend en charge toutes les versions du core ou l’inventaire de remplacement. Enregistrez les exports, dépendances, SQL et ordre de démarrage requis pour la pile exacte.
Qbox
L’introduction officielle de Qbox indique que Qbox a commencé en 2022 à partir de QBCore et possède désormais ses propres API et ressources core. 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 core internes ou d’un comportement non pris en charge.
L’installation officielle de Qbox utilise une recette populaire QBox dans txAdmin. Pour une migration depuis QBCore, le guide de conversion couvre les différences de configuration, les grades numériques des emplois et des gangs, l’inventaire et la conversion de base de données, et le remplacement incrémental des API. Qbox est donc un choix de framework délibéré avec un audit de compatibilité, pas simplement un interrupteur qui fait fonctionner chaque script QBCore 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 examinée. |
| Ressources requises | Quelle base de données, bibliothèque, inventaire et ressources de support sont sélectionnés ? | Fichiers de recette, manifestes et déclarations de dépendances. |
| Compatibilité API | Quels exports, événements, objets et champs de données les scripts requis appellent-ils ? | Source de la ressource, manifestes et documentation officielle de l’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 ? | Runbooks, sauvegardes et un exercice de récupération par étapes. |
| Performance | 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 décision
- Listez les fonctionnalités requises pour les joueurs. 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. Enregistrer les versions des frameworks, les manifestes, les tables de base de données, les exports, les événements et les modifications personnalisées du noyau.
- Cartographier le support des ressources. Pour chaque ressource requise, confirmer le framework et la version qu’elle supporte réellement, y compris les bridges et les systèmes de remplacement.
- Vérifier les connaissances de l’équipe. Inclure 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 et les intégrations réels ; ne pas utiliser un tableau générique d’heures ou de coûts.
- Construire une pile de test représentative. Utiliser la recette officielle, les ressources sélectionnées et une copie nettoyée de données réalistes.
- Définir l’acceptation et le retour en arrière. Décider 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 les identités, les personnages, l’argent, les emplois, les gangs, l’inventaire, les véhicules, les garages, le logement, les téléphones, les opérations bancaires, les comptes de société, les permissions et les é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 permissions.
N'exécutez pas un extrait SQL générique de conversion sur la production. Commencez par un schéma et un inventaire des ressources, concevez une conversion idempotente sur une copie de test, validez les comptes d'enregistrements et les relations, et répétez le rollback. Les scripts spécifiques à un 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 QB de Qbox n'est pas universel.
Comment benchmarker votre propre stack
Si la performance influence 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é, l’artefact FXServer, la version de la base de données, le volume de données et les actions représentatives des joueurs. Gardez l’ensemble des ressources fonctionnellement comparable et indiquez chaque différence intentionnelle.
- Préchauffer chaque serveur de manière cohérente et capturer le comportement inactif.
- Répéter les mêmes actions de chargement de personnage, d’inventaire, d’emploi, de véhicule et d’économie.
- Collecter les preuves du profiler FiveM ou de resmon ainsi que les requêtes lentes de la base de données et les métriques système.
- Exécuter plusieurs échantillons et rapporter les distributions ou les plages, pas un seul meilleur nombre.
- Inspecter les erreurs, l’exactitude des données et le comportement de reconnexion en parallèle du timing.
- Conserver la configuration et les journaux bruts afin qu’un autre évaluateur puisse reproduire la conclusion.
Un benchmark d’un seul cœur avec différentes ressources n’isole pas le framework. Un résultat provenant d’un serveur vide synthétique ne prouve pas la capacité de production. Publiez uniquement les conclusions étayées par la configuration enregistrée et les preuves brutes.
Recommandation pratique
- Choisir ESX lorsque les ressources ESX actuelles, les données et les connaissances de l’équipe répondent au mieux aux exigences et que la migration n’a aucun avantage prouvé.
- Choisir QBCore lorsque la recette officielle QB et l’écosystème documenté correspondent à une nouvelle construction ou à un serveur QB existant.
- Choisir Qbox lorsque l’équipe souhaite délibérément utiliser la recette et les API actuelles de Qbox et peut réaliser un audit de pont ou de migration QB.
Ouvrez les guides dédiés au framework pour l’installation officielle actuelle et la limite de compatibilité. Associez ensuite les ressources commerciales à la pile exacte choisie plutôt que de traiter une catégorie large comme preuve finale.
Guides détaillés du framework
Continuer avec l’installation exacte et la limite de compatibilité pour ESX Legacy, QBCore ou la pile Qbox et Ox.
