Nessuna esportazione X in risorsa Y: come risolverla in FiveM

La console mostra questo, spesso in un ciclo:

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

Il tuo script ha chiamato exports['my_inventory']:GetItemCount(). In quel momento, my_inventory non aveva un'esportazione con quel nome. Il messaggio nomina entrambe le parti, quindi la soluzione è una di un piccolo numero di cause. Questa guida copre il caso generico. Se l'esportazione è getSharedObject da es_extended, leggi invece No such export getSharedObject in resource es_extended, che ha le cause specifiche di ESX.

#1. La risorsa non è avviata

Un'esportazione esiste solo mentre la sua risorsa è in esecuzione. Controlla la console all'avvio:

• La risorsa è elencata in server.cfg con ensure o start?
• Si è avviata senza errori, o ha stampato Couldn't start resource o Failed to load script?
• È arrestata in txAdmin? Controlla la pagina Risorse.

Una risorsa che non si è avviata, ad esempio a causa di un errore di sintassi Lua o una dipendenza mancante, non ha esportazioni. Risolvi prima il suo errore. Vedi Couldn't start resource e could not find dependency. Un errore di sintassi in particolare è coperto in Lua syntax error: unexpected symbol near.

#2. Il nome della risorsa è sbagliato

exports['my_inventory'] usa il nome della cartella della risorsa, non il titolo dello script. Se la cartella è stata rinominata, ogni script che la chiama per il nome vecchio fallisce.

Situazioni tipiche:

• Hai rinominato my_inventory-master o my_inventory-main in qualcosa di più breve e hai continuato a chiamare il nome vecchio.
• Il nome usa un trattino in un posto e un sottolineatura nell'altro: my-inventory e my_inventory sono risorse diverse.
• La capitalizzazione differisce: corrisponde esattamente alla cartella.
• La risorsa si trova in una cartella con parentesi quadre come [qb]. Le parentesi sono solo una categoria: non fanno parte del nome, quindi usa my_inventory, non [qb]/my_inventory.

Alcune risorse ne sostituiscono un'altra con provide 'other_name' nel loro fxmanifest, in modo che gli script che chiedono il nome vecchio continuino a funzionare. Se hai sostituito una risorsa con una compatibile e il nome vecchio fallisce, controlla se la nuova lo fornisce, e che hai rimosso la vecchia cartella in modo che le due non si scontrino.

#3. L'esportazione è dall'altro lato

Le esportazioni sono per lato. Un'esportazione registrata in uno script client può essere chiamata solo da un altro script client, e una registrata sul server solo da uno script server.

-- 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')

Per controllare, guarda nei file del fornitore: la riga exports(...) è in client/ o server/, o in un file elencato sotto shared_scripts, che si esegue su entrambi i lati. Se l'esportazione è solo server, chiamala da uno script server, e ottieni i dati al client con un evento o un callback, vedi server callbacks.

#4. L'esportazione è stata rinominata o rimossa

Le risorse cambiano tra le versioni. Un'esportazione chiamata GetItemCount in una versione più vecchia potrebbe essere getItemCount o Search in una più nuova, e i nomi Lua sono sensibili alle maiuscole. Se l'errore è apparso dopo un aggiornamento di una delle risorse:

1. Apri il fxmanifest.lua, README o la documentazione del fornitore e cerca l'elenco di esportazioni corrente.
2. Cerca la cartella della risorsa per exports( e per il nome che chiami.
3. Aggiorna la tua chiamata, o aggiorna l'altra risorsa alla versione per cui lo script è stato scritto.

Ricorda che esiste anche l'inverso: uno script aggiornato per chiamare un'esportazione nuova, mentre il fornitore esegue ancora una versione vecchia senza di essa.

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

Su Windows, usa la casella di ricerca del tuo editor.

#5. Ordine di avvio e dipendenze

Se la risorsa esiste e ha l'esportazione, ma la chiamata avviene prima che sia pronta, ottieni lo stesso errore. Le risorse si avviano nell'ordine di server.cfg:

ensure oxmysql
ensure ox_lib
ensure my_inventory

ensure my_script

Metti il fornitore sopra lo script che lo usa. Per una soluzione permanente, dichiara il collegamento nel fxmanifest.lua del chiamante:

dependency 'my_inventory'

Allora FiveM avvia my_inventory per primo, e si rifiuta di avviare lo script senza di esso. Maggiori informazioni sull'ordinamento in ordine delle risorse in server.cfg.

Due trappole correlate:

• L'esportazione è registrata tardi. exports('Name', fn) si esegue quando la riga è raggiunta. Se il file errori al di sopra di essa, o la registra dopo un lungo Wait, i chiamanti che si eseguono nel frattempo falliscono. Registra le esportazioni vicino all'inizio del file.
• Una chiamata al momento del caricamento. Una chiamata di primo livello come local count = exports['my_inventory']:GetItemCount('water') si esegue nel momento in cui il tuo file carica. Spostalo in un evento o un thread, o assicurati che la dipendenza sia già in esecuzione.

Puoi anche proteggere un'integrazione opzionale con pcall e con un controllo che la risorsa sia in esecuzione:

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

GetResourceState restituisce 'started', 'stopped', 'missing' o altri stati, in modo che tu possa anche registrare quale caso sia. Per uno sguardo più profondo a come funzionano le esportazioni, leggi FiveM exports in Lua.

#6. Riavvio di una risorsa, non dell'altra

Il riavvio di un fornitore mentre il server è in esecuzione non sempre ricollega gli script che contengono i suoi oggetti. Dopo che hai riavviato o aggiornato un fornitore, riavvia gli script che lo chiamano, o riavvia il server.

#Checklist