ESX, QBCore, QBox : installer un framework FiveM

Pourquoi un framework, et pas des scripts isolés

Un script RP a besoin de savoir qui est le joueur, ce qu'il possède, combien il a d'argent et quel métier il exerce. Sans socle commun, chaque script réinventerait ces notions et aucun ne parlerait aux autres.

Un framework est ce socle : un modèle de données en base, une API côté serveur et client, et des conventions que les auteurs de scripts suivent. C'est pour cette raison que le choix du framework détermine le catalogue de scripts qui vous sera accessible — bien plus que l'inverse.

ESX, QBCore, QBox, ox_core : le choix réel

ESX Legacy est le plus ancien et le plus répandu, en particulier dans la communauté francophone. Son catalogue de scripts est le plus large, et c'est le choix sûr quand votre serveur s'appuie sur des ressources achetées ou existantes.

QBCore est plus récent, avec une base de code plus propre et une communauté très active côté anglophone. QBox est un fork de QBCore qui pousse plus loin la modernisation. ox_core, de la même équipe que oxmysql et ox_inventory, est le plus exigeant et le plus cohérent techniquement, avec le catalogue le plus étroit.

La question à se poser n'est pas « lequel est le meilleur » mais « sur quoi mes ressources sont-elles écrites ». Un serveur qui démarre avec un pack de scripts ESX n'a aucune raison de choisir QBCore, et réciproquement.

Les prérequis

Une base de données MySQL ou MariaDB, d'abord : les deux frameworks y stockent les joueurs, l'inventaire et l'économie. Sur nos offres FiveM, elle est fournie et se gère depuis NexusPanel.

Ensuite oxmysql, la couche d'accès que les deux frameworks utilisent aujourd'hui. Et enfin l'import du schéma SQL fourni par le framework : sans lui, le serveur démarre mais aucune connexion de joueur n'aboutit.

La chaîne de connexion se déclare dans server.cfg. Elle doit pointer sur l'hôte, l'utilisateur et la base que le panel vous a donnés, pas sur un `localhost` recopié d'un tutoriel.

set mysql_connection_string "mysql://utilisateur:motdepasse@hote/base?charset=utf8mb4"

ensure oxmysql
ensure es_extended
ensure esx_menu_default

L'ordre de démarrage compte

FXServer démarre les ressources dans l'ordre où elles sont déclarées. Une ressource qui appelle le framework avant que le framework ne soit prêt échoue — souvent en silence, parfois en cascade.

L'ordre à respecter est toujours le même : la couche base de données, puis le framework, puis ses modules, puis vos ressources. Quand un script se comporte comme s'il était absent alors qu'il est bien là, c'est la première chose à vérifier.

Le piège de version

Un script écrit pour ESX 1.1 ne fonctionne pas tel quel sur ESX Legacy : les noms d'exports ont changé. C'est de loin la première cause d'un serveur qui démarre mais dont rien ne marche.

Avant d'acheter ou d'installer une ressource, vérifiez la version de framework qu'elle déclare. Et quand vous suivez un tutoriel, regardez sa date : le paysage ESX a changé deux fois depuis 2020.