No such export getSharedObject in resource es_extended: la solución

El error completo suele tener esta pinta, en la consola del servidor o en F8:

SCRIPT ERROR: @my_script/server/main.lua:1: No such export getSharedObject in resource es_extended

El código está bien. exports['es_extended']:getSharedObject() es exactamente como ESX Legacy reparte su objeto. El problema es cuándo se ejecuta: en ese momento, es_extended no está ahí para responder.

#1. es_extended arranca después de tu script

Es la causa nueve de cada diez veces. FiveM arranca los recursos en el orden de tu server.cfg, y un script que pide ESX en su primera línea necesita que es_extended ya esté funcionando.

Un orden seguro para un servidor ESX:

# database and libraries first
ensure oxmysql
ensure ox_lib

# the framework
ensure es_extended
ensure [esx]

# everything else after
ensure [scripts]
ensure my_script

Ojo con las categorías de carpetas como [scripts]: ensure [scripts] arranca todo lo que hay dentro, así que si esa línea va antes de ensure es_extended, todos los scripts que contiene arrancan demasiado pronto.

También puedes hacer que el propio script espere a ESX declarando la dependencia en su fxmanifest.lua:

dependency 'es_extended'

Así FiveM arrancará primero es_extended, o se negará a arrancar el script si falta.

#2. es_extended no consiguió arrancar

Si es_extended peta al arrancar, sus exports nunca llegan a existir. Sube en la consola del servidor hasta el principio y busca líneas rojas de es_extended antes del error de tu script. Los culpables habituales:

• La base de datos. oxmysql no puede conectarse (una contraseña incorrecta, una base de datos que no existe, MySQL sin arrancar). Revisa mysql_connection_string en tu server.cfg:

set mysql_connection_string "mysql://user:password@localhost/es_extended?charset=utf8mb4"

• Una dependencia que falta. Las versiones recientes de ESX Legacy necesitan que oxmysql y ox_lib arranquen antes que ellas.
• Tablas que faltan. Una instalación nueva sin el SQL de ESX importado peta en la primera consulta.

Arregla ese primer error y el error del export desaparece con él.

#3. La carpeta no se llama es_extended

El export vive en un recurso que se llama exactamente es_extended. Esto lo rompe:

• la carpeta se ha renombrado (es_extended-legacy, es_extended_main…);
• hay dos copias de es_extended en carpetas distintas, y arranca la que no es;
• en un host Linux, el nombre tiene mayúsculas distintas (ES_Extended): Linux distingue entre mayúsculas y minúsculas, Windows no.

Busca en tu carpeta resources archivos fxmanifest.lua dentro de carpetas llamadas es_extended y deja exactamente una.

#4. Reiniciaste es_extended con el servidor en marcha

restart es_extended desde la consola parece inofensivo, pero todos los scripts que ya cogieron el objeto ESX se quedan con el antiguo, y cualquiera que llame al export durante el reinicio recibe este error. Después de tocar es_extended, reinicia el servidor entero, o al menos reinicia los scripts de ESX después de él.

#5. El servidor ni siquiera es ESX

Si tu servidor usa QBCore o QBox, no hay es_extended, y un script solo para ESX falla exactamente así. Busca en la config del script una opción de framework, o usa una versión hecha para tu framework. El equivalente de este error en QBCore lo tienes en attempt to index a nil value (global 'QBCore').

#Comprobarlo en diez segundos

En la consola del servidor:

ensure es_extended

Si es_extended arranca limpio y el error sigue, es el orden de arranque. Si muestra errores, arréglalos primero. Después:

restart my_script

Si ahora el script arranca sin el error, mueve su ensure por debajo de es_extended en server.cfg para que también funcione después de reiniciar el servidor.

#Resumen