No such export X in resource Y : comment le corriger dans FiveM

La console affiche ceci, souvent en boucle :

SCRIPT ERROR: @my_script/server/main.lua:14: No such export GetItemCount in resource my_inventory

Votre script a appelé exports['my_inventory']:GetItemCount(). À ce moment-là, my_inventory n'avait pas d'export avec ce nom. Le message nomme les deux parties, donc la correction est l'une d'un petit nombre de causes. Ce guide couvre le cas générique. Si l'export est getSharedObject de es_extended, lisez No such export getSharedObject in resource es_extended à la place, qui contient les causes spécifiques à ESX.

#1. La ressource n'est pas démarrée

Une export n'existe que lorsque sa ressource est en cours d'exécution. Vérifiez la console au démarrage :

• La ressource est-elle listée dans server.cfg avec ensure ou start ?
• A-t-elle démarré sans erreur, ou a-t-elle imprimé Couldn't start resource ou Failed to load script ?
• Est-elle arrêtée dans txAdmin ? Vérifiez la page Ressources.

Une ressource qui n'a pas pu démarrer, par exemple à cause d'une erreur de syntaxe Lua ou d'une dépendance manquante, n'a pas d'exports. Corriger d'abord sa propre erreur. Voir Couldn't start resource et could not find dependency. Une erreur de syntaxe en particulier est couverte dans Lua syntax error: unexpected symbol near.

#2. Le nom de ressource est incorrect

exports['my_inventory'] utilise le nom du dossier de la ressource, pas le titre du script. Si le dossier a été renommé, chaque script qui l'appelle par l'ancien nom échoue.

Situations typiques :

• Vous avez renommé my_inventory-master ou my_inventory-main en quelque chose de plus court et vous avez continué à appeler l'ancien nom.
• Le nom utilise un trait d'union dans un endroit et un trait de soulignement dans un autre : my-inventory et my_inventory sont des ressources différentes.
• La capitalisation diffère : correspondre au dossier exactement.
• La ressource se trouve dans un dossier avec des crochets tels que [qb]. Les crochets sont seulement une catégorie : ils ne font pas partie du nom, utilisez donc my_inventory, pas [qb]/my_inventory.

Certaines ressources remplacent une autre avec provide 'other_name' dans leur fxmanifest, afin que les scripts demandant l'ancien nom fonctionnent toujours. Si vous avez remplacé une ressource par une ressource compatible et l'ancien nom échoue, vérifiez si la nouvelle le fournit, et que vous avez supprimé l'ancien dossier pour que les deux ne se heurtent pas.

#3. L'export est de l'autre côté

Les exports sont par côté. Une export enregistrée dans un script client ne peut être appelée que depuis un autre script client, et une enregistrée sur le serveur uniquement depuis un script serveur.

-- my_inventory/server/main.lua
exports('GetItemCount', function(source, item)
    return 0
end)

-- my_script/client/main.lua
-- fails: GetItemCount exists on the server only
local count = exports['my_inventory']:GetItemCount('water')

Pour vérifier, regardez dans les fichiers du fournisseur : la ligne exports(...) est dans client/ ou server/, ou dans un fichier listé sous shared_scripts, qui s'exécute sur les deux côtés. Si l'export est serveur uniquement, appelez-le depuis un script serveur, et obtenez les données au client avec un événement ou un rappel, voir server callbacks.

#4. L'export a été renommé ou supprimé

Les ressources changent entre les versions. Une export appelée GetItemCount dans une version plus ancienne peut être getItemCount ou Search dans une version plus récente, et les noms Lua sont sensibles à la casse. Si l'erreur est apparue après une mise à jour de l'une ou l'autre ressource :

1. Ouvrez le fxmanifest.lua, README ou la documentation du fournisseur et cherchez la liste des exports actuels.
2. Recherchez dans le dossier de la ressource exports( et le nom que vous appelez.
3. Mettez à jour votre appel, ou mettez à jour l'autre ressource vers la version pour laquelle le script a été écrit.

N'oubliez pas que l'inverse existe aussi : un script mis à jour pour appeler une nouvelle export, tandis que le fournisseur exécute toujours une ancienne version sans elle.

grep -rn "exports(" resources/[mic]/my_inventory

Sous Windows, utilisez la boîte de recherche de votre éditeur à la place.

#5. Ordre de démarrage et dépendances

Si la ressource existe et a l'export, mais que l'appel se produit avant qu'elle ne soit prête, vous obtenez la même erreur. Les ressources commencent dans l'ordre de server.cfg :

ensure oxmysql
ensure ox_lib
ensure my_inventory

ensure my_script

Mettez le fournisseur au-dessus du script qui l'utilise. Pour une correction permanente, indiquez le lien dans le fxmanifest.lua de l'appelant :

dependency 'my_inventory'

Ensuite, FiveM démarre my_inventory en premier, et refuse de démarrer le script sans elle. Plus sur l'ordre dans server.cfg resource order.

Deux pièges connexes :

• L'export est enregistré tard. exports('Name', fn) s'exécute lorsque la ligne est atteinte. Si le fichier erreur au-dessus, ou l'enregistre après une longue Wait, les appelants qui s'exécutent entre-temps échouent. Enregistrez les exports près du haut du fichier.
• Un appel au moment du chargement. Un appel au niveau supérieur tel que local count = exports['my_inventory']:GetItemCount('water') s'exécute au moment où votre fichier se charge. Déplacez-le dans un événement ou un thread, ou assurez-vous que la dépendance s'exécute déjà.

Vous pouvez également protéger une intégration optionnelle avec pcall et avec une vérification que la ressource s'exécute :

if GetResourceState('my_inventory') == 'started' then
    local ok, count = pcall(function()
        return exports['my_inventory']:GetItemCount('water')
    end)
end

GetResourceState retourne 'started', 'stopped', 'missing' ou d'autres états, afin que vous puissiez aussi enregistrer quel cas il s'agit. Pour un regard plus approfondie sur le fonctionnement des exports, lisez FiveM exports in Lua.

#6. Redémarré une ressource, pas l'autre

Redémarrer un fournisseur pendant l'exécution du serveur ne re-connecte pas toujours les scripts qui contiennent ses objets. Après que vous redémarriez ou mettez à jour un fournisseur, redémarrez les scripts qui l'appellent, ou redémarrez le serveur.

#Liste de contrôle