@ox_lib/init.lua no encontrado y errores de ox_lib: cómo solucionar

Un script que usa ox_lib falla al cargar en tu consola y el mensaje menciona @ox_lib/init.lua, o falla con:

No such export <name> in resource ox_lib

u ox_lib en sí nunca se inicia. Todos estos provienen de las mismas pocas causas: la descarga incorrecta, el nombre de carpeta incorrecto, el orden de inicio incorrecto, o una línea faltante en el manifest. Aquí está la solución para cada uno.

#Qué es ox_lib

ox_lib es una biblioteca compartida que muchos scripts usan: callbacks, notificaciones, menús, barras de progreso, localizaciones. Un script se suscribe con una línea en su manifest:

shared_script '@ox_lib/init.lua'

El prefijo @ox_lib/ le dice a FiveM que lea el archivo desde el recurso llamado ox_lib, no desde la carpeta del script. Así que ox_lib debe existir, tener exactamente ese nombre, e iniciarso.

#1. Descarga el lanzamiento, no el zip de origen

Esta es la causa que golpea a la mayoría de la gente. En GitHub, el botón verde Code te da un zip de la fuente. ox_lib tiene una interfaz web (menús, barras de progreso) que se construye a partir de archivos de origen. El zip de origen no contiene los archivos construidos, así que ox_lib falla al cargar su UI o registra un mensaje sobre la UI no siendo construida.

En su lugar:

1. Abre el repositorio ox_lib en GitHub, luego Releases.
2. En el último lanzamiento, descarga el archivo nombrado ox_lib.zip bajo Assets.
3. Descomprimelo. La carpeta dentro debe ser ox_lib y fxmanifest.lua debe estar directamente en ella.

resources/[standalone]/ox_lib/fxmanifest.lua

Si tienes una carpeta de origen llamada ox_lib-main, elimínala e instala el lanzamiento en su lugar. Véase también Could not find dependency para problemas de nombres de carpeta.

#2. Inicia ox_lib antes que los scripts

En server.cfg, ox_lib debe venir antes que cualquier recurso que lo importe:

ensure oxmysql
ensure ox_lib
ensure es_extended   # or qb-core / qbx_core

ensure my_script

Si my_script se asegura por encima de ox_lib, puede cargarse primero y fallar. Moverlo hacia abajo es la solución. Véase the right ensure order in server.cfg.

Añade la dependencia en el manifest del script también, para que FiveM la verifique:

dependency 'ox_lib'

#3. Añade el shared script y lua54

Los scripts que usan funciones lib. necesitan dos líneas en fxmanifest.lua. Sin la importación, lib es nil en el script, y obtienes errores como attempt to index a nil value (global 'lib'):

fx_version 'cerulean'
game 'gta5'

lua54 'yes'

shared_script '@ox_lib/init.lua'

client_scripts { 'client/*.lua' }
server_scripts { 'server/*.lua' }

El orden importa: shared_script '@ox_lib/init.lua' debe estar listado para que se cargue antes que los archivos de script que llaman a lib. Ponlo por encima de client_scripts y server_scripts.

#4. No such export in resource ox_lib

No such export <name> in resource ox_lib

Esto significa que el script llama a una exportación de ox_lib que no existe en tu servidor. Hay dos causas:

• Un ox_lib antiguo. El script fue escrito para una versión más nueva. Actualiza al último lanzamiento de compilación.
• ox_lib falló al iniciarse, así que ninguna de sus exportaciones existe. Mira la consola donde se inicia ox_lib. Si imprimió un error allí, soluciona eso primero.

Verifica que ox_lib se inicia limpiamente: ejecuta ensure ox_lib en la consola del servidor y lee qué imprime. Un inicio saludable no imprime error ni línea de falla.

#5. Verifica el artefacto del servidor

ox_lib necesita una compilación de servidor de FiveM razonablemente actual. Si ox_lib se rehúsa a iniciarse y el mensaje menciona la versión del servidor, actualiza tus artefactos. Los pasos están en updating FiveM server artifacts.

#6. El script en sí no es el culpable

Si ox_lib está instalado e iniciado, pero un script sigue rompiéndose, confirma que:

• La carpeta del script se nombra como dice la línea de ensure.
• No copiaste ox_lib en la carpeta del script. Debe haber un recurso ox_lib, en el nivel superior de resources (o en una carpeta de corchetes).
• No existe segunda copia de ox_lib en otra carpeta de categoría. Dos carpetas con el mismo nombre de recurso causan comportamiento impredecible.

Consejo: cuando actualices ox_lib, elimina la carpeta antigua primero en lugar de descomprimir sobre ella. Los archivos antiguos dejados atrás pueden mezclarse con los nuevos.

#Lista de verificación