No such export getSharedObject in resource es_extended : le correctif

L'erreur complète ressemble généralement à ceci, dans la console du serveur ou dans F8 :

SCRIPT ERROR: @my_script/server/main.lua:1: No such export getSharedObject in resource es_extended

Le code est correct. exports['es_extended']:getSharedObject() est exactement la manière dont ESX Legacy distribue son objet. Le problème, c'est quand il s'exécute : à ce moment-là, es_extended n'est pas là pour répondre.

#1. es_extended démarre après votre script

C'est la cause neuf fois sur dix. FiveM démarre les ressources dans l'ordre de votre server.cfg, et un script qui demande ESX dans sa première ligne doit es_extended être déjà en cours d'exécution.

Une commande sécurisée pour un serveur ESX :

# database and libraries first
ensure oxmysql
ensure ox_lib

# the framework
ensure es_extended
ensure [esx]

# everything else after
ensure [scripts]
ensure my_script

Faites attention aux catégories de dossiers comme [scripts] : ensure [scripts] démarre tout ce qu'il contient, donc si cette ligne arrive avant ensure es_extended, chaque script qu'il contient démarre trop tôt.

Vous pouvez également faire attendre le script lui-même ESX, en déclarant la dépendance dans son fxmanifest.lua :

dependency 'es_extended'

FiveM démarrera alors es_extended en premier, ou refusera de démarrer le script s'il est manquant.

#2. es_extended n'a pas pu démarrer

Si es_extended plante au démarrage, ses exports n'existent jamais. Faites défiler la console du serveur vers le haut et recherchez les lignes rouges de es_extended avant l'erreur de votre script. Les coupables habituels :

• La base de données. oxmysql ne peut pas se connecter (un mot de passe erroné, une base de données qui n'existe pas, MySQL ne fonctionne pas). Vérifiez mysql_connection_string dans votre server.cfg :

set mysql_connection_string "mysql://user:password@localhost/es_extended?charset=utf8mb4"

• Une dépendance manquante. Les builds ESX Legacy récentes nécessitent oxmysql et ox_lib démarrées avant elles.
• Tables manquantes. Une nouvelle installation sans les ESX SQL importés plante à la première requête.

Corrigez cette première erreur et l'erreur d'exportation disparaîtra avec elle.

#3. Le dossier ne s'appelle pas es_extended

L'export réside dans une ressource nommée exactement es_extended. Ceux-ci le brisent :

• le dossier a été renommé (es_extended-legacy, es_extended_main…);
• il y a deux copies de es_extended dans des dossiers différents, et la mauvaise démarre ;
• sur un hôte Linux, le nom a des majuscules différentes (ES_Extended) : Linux est sensible à la casse, Windows ne l'est pas.

Recherchez dans votre dossier resources des fichiers fxmanifest.lua dans des dossiers appelés es_extended et conservez-en exactement un.

#4. Vous avez redémarré es_extended alors que le serveur était en cours d'exécution

restart es_extended de la console semble inoffensif, mais chaque script qui a déjà pris l'objet ESX conserve l'ancien, et tout ce qui appelle l'exportation lors du redémarrage obtient cette erreur. Après avoir touché es_extended, redémarrez l'ensemble du serveur, ou au moins redémarrez les scripts ESX après.

#5. Le serveur n'est pas ESX du tout

Si votre serveur exécute QBCore ou QBox, il n'y a pas de es_extended et un script uniquement ESX échoue exactement comme ceci. Recherchez dans la configuration du script une option de framework ou utilisez une version conçue pour votre framework. L'équivalent QBCore de cette erreur est abordé dans la tentative d'indexation d'une valeur nil (globale 'QBCore').

#Vérification dans dix secondes

Dans la console du serveur :

ensure es_extended

Si es_extended démarre proprement et que l'erreur persiste, il s'agit de l'ordre de démarrage. S'il imprime des erreurs, corrigez-les d'abord. Puis :

restart my_script

Si le script démarre maintenant sans erreur, déplacez son ensure en dessous de es_extended dans server.cfg pour qu'il fonctionne également après un redémarrage.

#Résumé