Exports FiveM en Lua : exports('name', fn) et 'No such export'

Un script appelle un autre et la console répond :

No such export getCount in resource my_inventory

Cet article montre comment les exports sont définis et appelés en Lua, les deux façons de les déclarer, et les raisons habituelles pour lesquelles cette erreur apparaît.

#Définir un export

Un export laisse une ressource offrir une fonction aux autres. La façon simple est la fonction exports à l'intérieur d'un script :

-- my_inventory/server/main.lua
local function getCount(source, item)
    -- ...
    return 5
end

exports('getCount', getCount)

Vous pouvez aussi passer la fonction en ligne :

exports('getCount', function(source, item)
    return 5
end)

C'est tout. Il n'y a rien à ajouter à fxmanifest.lua, et l'export existe du côté où le script s'exécute : mettez-le dans un script serveur et c'est un export serveur, mettez-le dans un script client et c'est un export client.

#Le style du manifeste

Les ressources plus anciennes déclarent les exports dans fxmanifest.lua et définissent une fonction globale simple avec le même nom :

-- fxmanifest.lua
fx_version 'cerulean'
game 'gta5'

server_exports { 'getCount' }
exports { 'getOwnedCount' }

-- server script
function getCount(source, item)
    return 5
end

• exports { … } répertorie les exports client.
• server_exports { … } répertorie les exports serveur.

Cela fonctionne toujours, et beaucoup de ressources ESX et QBCore l'utilisent. Les deux styles ne se heurtent pas, donc une ressource peut les mélanger. Pour le nouveau code, exports('name', fn) est plus simple car la fonction et l'export vivent ensemble, et vous ne pouvez pas oublier une ligne dans le manifeste. N'oubliez pas que fxmanifest.lua est le nom du manifeste actuel : voir fxmanifest vs __resource.lua.

#Appeler un export

De n'importe quelle autre ressource du même côté :

local count = exports['my_inventory']:getCount(source, 'water')

Les versions point et deux-points sont la même chose, tant que le nom est un identificateur Lua valide :

local count = exports.my_inventory:getCount(source, 'water')

Utilisez la forme entre crochets quand le nom de la ressource a un tiret, tel que exports['qb-core']:GetCoreObject(). L'appel est synchrone : il retourne la valeur de la fonction, et il peut attendre si la fonction attend.

Astuce : les arguments et les valeurs de retour voyagent entre les ressources, donc les tables sont copiées. Changer une table que vous avez obtenue d'un export ne change pas les données propres de l'autre ressource. Les fonctions à l'intérieur d'une table retournée fonctionnent toujours, car elles rappellent le propriétaire.

#Pourquoi vous obtenez « No such export »

No such export getCount in resource my_inventory

Vérifiez ceux-ci, dans cet ordre :

1. La ressource n'est pas démarrée. Ouvrez la console et exécutez ensure my_inventory. S'il ne démarre pas, corrigez d'abord cela.
2. Il a démarré après l'appelant. L'export n'existe que quand le propriétaire a chargé ses scripts. Voir ordre de démarrage dans server.cfg et mettez le propriétaire au-dessus des scripts qui l'utilisent.
3. Le nom est mal orthographié. Les noms d'export sont sensibles à la casse : getCount et GetCount sont différents.
4. Mauvais côté. Un script serveur ne peut pas appeler un export client, et inversement. L'erreur ressemble à la même.
5. L'export est déclaré mais la fonction manque. Avec le style du manifeste, server_exports { 'getCount' } a besoin d'une fonction globale appelée getCount sur le serveur. Une fonction locale ne compte pas.
6. Le propriétaire a échoué ou a été arrêté. S'il s'est écrasé sur une erreur de script, ou vous l'avez arrêté, ses exports s'en vont jusqu'à ce qu'il s'exécute à nouveau. Lisez sa sortie de démarrage dans la console.

Pour les versions réelles de cette erreur, voir No such export GetSharedObject in resource es_extended et QBCore is nil: GetCoreObject.

#Rendre l'ordre certain avec des dépendances

Ne comptez pas seulement sur l'ordre des lignes ensure. Déclarez la dépendance dans le manifeste du script qui appelle l'export :

dependency 'my_inventory'

FiveM démarre alors my_inventory en premier, et refuse de démarrer votre ressource si elle manque, avec un message plus clair (could not find dependency).

#Gérer une ressource manquante gracieusement

Si une autre ressource est optionnelle, vérifiez son état avant de l'appeler :

if GetResourceState('my_inventory') == 'started' then
    local count = exports.my_inventory:getCount(source, 'water')
end

GetResourceState retourne une chaîne telle que started, stopped, starting ou missing. C'est la façon propre de soutenir une intégration optionnelle sans erreur de console.

#Appeler vos propres exports

Une ressource peut aussi appeler ses propres exports, avec son propre nom : exports['my_inventory']:getCount(...). Pour une fonction qui est utilisée seulement à l'intérieur de la ressource, une fonction locale normale est plus rapide et plus simple. Les exports sont pour la frontière entre les ressources.

#Un mot sur la performance

Chaque appel traverse entre deux ressources, donc c'est plus lent qu'un appel de fonction normal. N'appelez pas un export dans une boucle serrée par frame si vous pouvez lire la valeur une fois et la garder. Appeler l'un quelques fois par seconde est correct.

#Liste de vérification