server.cfg ensure order : le bon ordre de démarrage des ressources pour FiveM

La moitié de vos scripts lancent des erreurs nil au démarrage, mais ils fonctionnent quand vous les redémarrez à la main. Ce schéma signifie généralement que les ressources démarrent dans le mauvais ordre. Ce guide vous donne un ordre qui fonctionne pour ESX, QBCore et QBox, et explique ensure vs start, les dossiers entre crochets et les doublons.

#Pourquoi l'ordre compte

Les ressources démarrent dans l'ordre des lignes du server.cfg. Un script qui lit le framework au chargement obtient nil si le framework n'a pas encore démarré. Il en va de même pour la couche base de données et pour les bibliothèques comme ox_lib. Vous le résolvez en mettant les couches de base en haut :

1. La base de données : oxmysql
2. La bibliothèque : ox_lib
3. Le framework : es_extended, qb-core ou qbx_core
4. L'inventory
5. Tout le reste

#Un ordre qui fonctionne

Pour QBCore :

ensure oxmysql
ensure ox_lib
ensure qb-core
ensure ox_inventory
ensure [qb]

ensure [standalone]
ensure [mic]

Pour QBox :

ensure oxmysql
ensure ox_lib
ensure qbx_core
ensure ox_inventory
ensure [qbx]
ensure [standalone]

Pour ESX :

ensure oxmysql
ensure ox_lib
ensure es_extended
ensure ox_inventory
ensure [esx]
ensure [standalone]

Ajustez les noms de catégories à vos propres dossiers. Si vous utilisez qb-inventory ou un autre inventory à la place de ox_inventory, mettez celui-ci à la même position, juste après le framework (ou avant, si sa propre documentation le dit).

Conseil : conservez les ressources que vous assurez par nom (oxmysql, ox_lib, le framework, l'inventory) dans des dossiers que vous n'assurez pas non plus entre crochets. Sinon, elles sont assurées deux fois, voir Doublons ci-dessous. De nombreuses configurations les mettent dans un dossier [core] qui n'est jamais assuré dans son ensemble.

Conseil : votre recette txAdmin a peut-être écrit son propre ordre. Gardez ce qui fonctionne et ajoutez uniquement vos scripts sous les couches de base, plutôt que de réécrire le fichier.

#ensure vs start

start my_script
ensure my_script

• start démarre une ressource si elle est arrêtée.
• ensure la démarre si elle est arrêtée, et la redémarre si elle est déjà en cours d'exécution.

Au démarrage normal, rien ne s'exécute, donc elles se comportent de la même façon. La différence apparaît quand vous les exécutez dans la console en direct : ensure my_script est celui que vous voulez pour recharger un script que vous venez de modifier. Dans server.cfg, utilisez ensure partout pour ne mémoriser qu'un seul mot. Dans l'autre direction, stop my_script l'arrête, et refresh fait en sorte que le serveur rescanne le dossier resources pour les nouveaux manifestes ou modifiés.

#Dossiers entre crochets comme catégories

Un dossier dont le nom est entre crochets n'est pas une ressource. C'est une catégorie, et FiveM regarde à l'intérieur :

resources/
  [core]/
    ox_lib/
    oxmysql/
    qb-core/
  [qb]/
    qb-garages/
  [standalone]/
    my_other_script/
  [mic]/
    my_script/

ensure [qb] démarre chaque ressource à l'intérieur de [qb]. Cela garde server.cfg court, et c'est ainsi que la plupart des packs framework sont livrés. Deux choses à savoir :

• L'ordre à l'intérieur d'un dossier entre crochets n'est pas quelque chose sur lequel vous fier. Si qb-garages a besoin de qb-core, assurez qb-core sur sa propre ligne au-dessus de ensure [qb], ou déclarez dependency 'qb-core' dans le manifeste. Le core ne doit pas dépendre de la chance.
• Une ressource ne peut pas être imbriquée à l'intérieur d'une autre ressource. Les crochets sont uniquement pour le groupement. Si vous mettez un dossier de script à l'intérieur d'un dossier de script, FiveM ne le trouvera pas. Voir Couldn't start resource.

Une ressource à l'intérieur d'un dossier entre crochets se trouve toujours par son propre nom, donc ensure ox_lib fonctionne même si le dossier est [core]/ox_lib.

#Dépendances dans le manifeste

L'ordre des lignes dans server.cfg est un outil. Une ligne dependency dans le manifeste d'un script est l'autre, et elle est plus fiable :

dependency 'ox_lib'
dependency 'oxmysql'

FiveM vérifie ensuite que ces ressources existent et les démarre en premier. Si l'une manque, vous obtenez un message clair au lieu d'une erreur nil : Could not find dependency X for resource Y. Utilisez les deux : un bon ordre dans le fichier, et des dépendances dans les manifestes que vous contrôlez.

#Doublons

Deux choses se produisent avec les doublons :

• Le même ensure deux fois. Assurer une ressource deux fois dans server.cfg la démarre, puis la redémarre immédiatement. Cela gaspille du temps de démarrage et peut déclencher des écritures de base de données en double ou des événements au démarrage. Supprimez la deuxième ligne. Vérifiez qu'un dossier entre crochets n'inclut pas déjà une ressource que vous assurez également par nom.
• Deux dossiers avec le même nom de ressource. Si vous avez resources/[old]/my_script et resources/[mic]/my_script, un seul est utilisé, et lequel est quelque chose que vous ne contrôlez pas. Supprimez ou renommez l'un, et supprimez toujours l'ancienne version d'un script avant d'en installer une nouvelle.

Quand une correction que vous avez apportée semble n'avoir aucun effet, vérifiez que vous n'avez pas modifié la copie qui ne fonctionne pas.

#Trouvez le coupable quand l'ordre est mauvais

Démarrez le serveur, puis lisez la console depuis le haut. La première ressource qui imprime une erreur en est la cause, et tout ce qui suit peut être des retombées. Exemples typiques :

• oxmysql imprime une erreur de base de données : rien qui utilise SQL ne fonctionnera.
• ox_lib échoue : chaque script avec @ox_lib/init.lua casse (ox_lib fix).
• Le framework échoue : chaque script qui lui demande un objet joueur obtient nil.

Corrigez le premier échec et redémarrez.

#Liste de contrôle