No such export X in resource Y: como corrigir no FiveM

O console mostra isto, frequentemente em um loop:

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

Seu script chamou exports['my_inventory']:GetItemCount(). Naquele momento, my_inventory não tinha uma exportação com esse nome. A mensagem nomeia ambas as partes, então a correção é uma de um pequeno número de causas. Este guia cobre o caso genérico. Se a exportação for getSharedObject de es_extended, leia No such export getSharedObject in resource es_extended em vez disso, que tem as causas específicas do ESX.

#1. O recurso não foi iniciado

Uma exportação só existe enquanto seu recurso está em execução. Verifique o console na inicialização:

• O recurso está listado em server.cfg com ensure ou start?
• Ele começou sem erros, ou imprimiu Couldn't start resource ou Failed to load script?
• Está parado no txAdmin? Verifique a página Recursos.

Um recurso que falhou em iniciar, por exemplo por causa de um erro de sintaxe Lua ou uma dependência ausente, não tem exportações. Corrija primeiro seu próprio erro. Veja Couldn't start resource e could not find dependency. Um erro de sintaxe em particular é coberto em Lua syntax error: unexpected symbol near.

#2. O nome do recurso está errado

exports['my_inventory'] usa o nome da pasta do recurso, não o título do script. Se a pasta foi renomeada, todos os scripts que a chamam pelo nome antigo falham.

Situações típicas:

• Você renomeou my_inventory-master ou my_inventory-main para algo mais curto e continuou chamando o nome antigo.
• O nome usa um hífen em um lugar e um sublinhado em outro: my-inventory e my_inventory são recursos diferentes.
• A capitalização difere: corresponda exatamente à pasta.
• O recurso fica em uma pasta com colchetes como [qb]. Os colchetes são apenas uma categoria: eles não fazem parte do nome, então use my_inventory, não [qb]/my_inventory.

Alguns recursos substituem outro com provide 'other_name' em seu fxmanifest, para que scripts pedindo o nome antigo ainda funcionem. Se você substituiu um recurso com um compatível e o nome antigo falha, verifique se o novo o fornece, e que você removeu a pasta antiga para que os dois não se choquem.

#3. A exportação está do outro lado

As exportações são por lado. Uma exportação registrada em um script do cliente só pode ser chamada de outro script do cliente, e uma registrada no servidor apenas de um script do servidor.

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

Para verificar, procure nos arquivos do provedor: a linha exports(...) está em client/ ou server/, ou em um arquivo listado em shared_scripts, que roda em ambos os lados. Se a exportação for apenas do servidor, chame-a de um script do servidor, e obtenha os dados para o cliente com um evento ou um retorno de chamada, veja server callbacks.

#4. A exportação foi renomeada ou removida

Os recursos mudam entre versões. Uma exportação chamada GetItemCount em uma versão mais antiga pode ser getItemCount ou Search em uma mais nova, e os nomes Lua são sensíveis a maiúsculas. Se o erro apareceu após uma atualização de qualquer recurso:

1. Abra o fxmanifest.lua, README ou documentação do provedor e procure pela lista de exportações atual.
2. Procure a pasta do recurso por exports( e pelo nome que você chama.
3. Atualize sua chamada, ou atualize o outro recurso para a versão para a qual o script foi escrito.

Lembre-se de que o inverso também existe: um script atualizado para chamar uma exportação nova, enquanto o provedor ainda executa uma versão antiga sem ela.

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

No Windows, use a caixa de pesquisa do seu editor.

#5. Ordem de inicialização e dependências

Se o recurso existe e tem a exportação, mas a chamada acontece antes de estar pronto, você recebe o mesmo erro. Os recursos começam na ordem de server.cfg:

ensure oxmysql
ensure ox_lib
ensure my_inventory

ensure my_script

Coloque o provedor acima do script que o usa. Para uma correção permanente, declare o link no fxmanifest.lua do chamador:

dependency 'my_inventory'

Então FiveM inicia my_inventory primeiro, e se recusa a iniciar o script sem ele. Mais sobre ordenação em ordem de recursos em server.cfg.

Duas armadilhas relacionadas:

• A exportação é registrada tarde. exports('Name', fn) roda quando a linha é alcançada. Se o arquivo errar acima dela, ou registrar após um Wait longo, os chamadores que rodam no meio falham. Registre exportações perto do topo do arquivo.
• Uma chamada no tempo de carregamento. Uma chamada de nível superior como local count = exports['my_inventory']:GetItemCount('water') roda no momento em que seu arquivo carrega. Mova-a para um evento ou uma thread, ou certifique-se de que a dependência já está em execução.

Você também pode proteger uma integração opcional com pcall e com uma verificação de que o recurso está em execução:

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

GetResourceState retorna 'started', 'stopped', 'missing' ou outros estados, então você também pode registrar qual caso é. Para uma análise mais profunda de como as exportações funcionam, leia FiveM exports in Lua.

#6. Reiniciado um recurso, não o outro

Reiniciar um provedor enquanto o servidor roda nem sempre reconecta os scripts que mantêm seus objetos. Depois que você reinicia ou atualiza um provedor, reinicie os scripts que o chamam, ou reinicie o servidor.

#Lista de verificação