No such export X in resource Y: cómo solucionarlo en FiveM

La consola muestra esto, a menudo en un bucle:

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

Tu script llamó a exports['my_inventory']:GetItemCount(). En ese momento, my_inventory no tenía una exportación con ese nombre. El mensaje nombra ambas partes, así que la solución es una de un pequeño número de causas. Esta guía cubre el caso genérico. Si la exportación es getSharedObject de es_extended, lee No such export getSharedObject in resource es_extended en su lugar, que tiene las causas específicas de ESX.

#1. El recurso no se ha iniciado

Una exportación solo existe mientras su recurso se está ejecutando. Verifica la consola al inicio:

• ¿Está el recurso listado en server.cfg con ensure o start?
• ¿Se inició sin errores, o imprimió Couldn't start resource o Failed to load script?
• ¿Está detenido en txAdmin? Comprueba la página de Recursos.

Un recurso que no se pudo iniciar, por ejemplo debido a un error de sintaxis de Lua o una dependencia faltante, no tiene exportaciones. Soluciona su propio error primero. Véase Couldn't start resource y could not find dependency. Un error de sintaxis en particular está cubierto en Lua syntax error: unexpected symbol near.

#2. El nombre del recurso es incorrecto

exports['my_inventory'] usa el nombre de la carpeta del recurso, no el título del script. Si la carpeta fue renombrada, cada script que la llama por el nombre antiguo falla.

Situaciones típicas:

• Renombraste my_inventory-master o my_inventory-main a algo más corto y seguiste llamando al nombre antiguo.
• El nombre usa un guion en un lugar y un guion bajo en otro: my-inventory y my_inventory son recursos diferentes.
• La capitalización difiere: coincide exactamente con la carpeta.
• El recurso se encuentra en una carpeta con corchetes como [qb]. Los corchetes son solo una categoría: no son parte del nombre, así que usa my_inventory, no [qb]/my_inventory.

Algunos recursos reemplazan otro con provide 'other_name' en su fxmanifest, para que los scripts que solicitan el nombre antiguo sigan funcionando. Si reemplazaste un recurso con uno compatible y el nombre antiguo falla, comprueba si el nuevo lo proporciona, y que eliminaste la carpeta antigua para que las dos no choquen.

#3. La exportación está en el otro lado

Las exportaciones son por lado. Una exportación registrada en un script de cliente solo puede ser llamada desde otro script de cliente, y una registrada en el servidor solo desde un script de 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, mira en los archivos del proveedor: la línea exports(...) está en client/ o server/, o en un archivo listado bajo shared_scripts, que se ejecuta en ambos lados. Si la exportación es solo de servidor, llámala desde un script de servidor, y obtén los datos al cliente con un evento o devolución de llamada, véase server callbacks.

#4. La exportación fue renombrada o eliminada

Los recursos cambian entre versiones. Una exportación llamada GetItemCount en una versión anterior puede ser getItemCount o Search en una más nueva, y los nombres de Lua distinguen mayúsculas de minúsculas. Si el error apareció después de una actualización de cualquiera de los recursos:

1. Abre el fxmanifest.lua, README o documentación del proveedor y busca la lista de exportaciones actual.
2. Busca en la carpeta del recurso exports( y el nombre que llamas.
3. Actualiza tu llamada, o actualiza el otro recurso a la versión para la que fue escrito el script.

Recuerda que lo inverso también existe: un script actualizado para llamar a una nueva exportación, mientras que el proveedor aún ejecuta una versión antigua sin ella.

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

En Windows, usa el cuadro de búsqueda de tu editor en su lugar.

#5. Orden de inicio y dependencias

Si el recurso existe y tiene la exportación, pero la llamada ocurre antes de que esté lista, obtienes el mismo error. Los recursos se inician en el orden de server.cfg:

ensure oxmysql
ensure ox_lib
ensure my_inventory

ensure my_script

Pon el proveedor por encima del script que lo usa. Para una solución permanente, establece el vínculo en el fxmanifest.lua de quien llama:

dependency 'my_inventory'

Luego FiveM inicia my_inventory primero, y se rehúsa a iniciar el script sin ella. Más sobre ordenamiento en server.cfg resource order.

Dos trampas relacionadas:

• La exportación se registra tarde. exports('Name', fn) se ejecuta cuando se alcanza la línea. Si el archivo genera un error por encima de ella, o la registra después de un largo Wait, los que llaman que se ejecutan mientras tanto fallan. Registra las exportaciones cerca de la parte superior del archivo.
• Una llamada en tiempo de carga. Una llamada de nivel superior como local count = exports['my_inventory']:GetItemCount('water') se ejecuta en el momento en que se carga tu archivo. Muévela a un evento o un hilo, o asegúrate de que la dependencia ya se está ejecutando.

También puedes proteger una integración opcional con pcall y con una verificación de que el recurso se está ejecutando:

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

GetResourceState devuelve 'started', 'stopped', 'missing' u otros estados, así que también puedes registrar cuál es el caso. Para una mirada más profunda de cómo funcionan las exportaciones, lee FiveM exports in Lua.

#6. Reiniciaste un recurso, no el otro

Reiniciar un proveedor mientras el servidor se ejecuta no siempre reconecta los scripts que contienen sus objetos. Después de reiniciar o actualizar un proveedor, reinicia los scripts que lo llaman, o reinicia el servidor.

#Lista de verificación