orden de ensure en server.cfg: el orden correcto de inicio de recursos para FiveM

La mitad de tus scripts lanzan errores nil al inicio, pero funcionan cuando los reinicies manualmente. Ese patrón generalmente significa que los recursos comienzan en el orden incorrecto. Esta guía te da un orden que funciona para ESX, QBCore y QBox, y explica ensure vs start, carpetas con brackets y duplicados.

#Por qué el orden importa

Los recursos se inician en el orden de las líneas en server.cfg. Un script que lee el framework cuando carga obtiene nil si el framework aún no ha comenzado. Lo mismo aplica a la capa de base de datos y a librerías como ox_lib. Lo resuelves poniendo las capas base arriba:

1. La base de datos: oxmysql
2. La librería: ox_lib
3. El framework: es_extended, qb-core o qbx_core
4. El inventory
5. Todo lo demás

#Un orden que funciona

Para QBCore:

ensure oxmysql
ensure ox_lib
ensure qb-core
ensure ox_inventory
ensure [qb]

ensure [standalone]
ensure [mic]

Para QBox:

ensure oxmysql
ensure ox_lib
ensure qbx_core
ensure ox_inventory
ensure [qbx]
ensure [standalone]

Para ESX:

ensure oxmysql
ensure ox_lib
ensure es_extended
ensure ox_inventory
ensure [esx]
ensure [standalone]

Ajusta los nombres de categoría a tus propias carpetas. Si usas qb-inventory u otro inventory en lugar de ox_inventory, pon ese en la misma posición, justo después del framework (o antes, si su documentación propia lo dice).

Consejo: mantén los recursos que aseguras por nombre (oxmysql, ox_lib, el framework, el inventory) en carpetas que no también asegures como un bracket. De lo contrario se aseguran dos veces, mira Duplicados más abajo. Muchas configuraciones ponen los core en una carpeta [core] que nunca se asegura en su totalidad.

Consejo: tu receta de txAdmin puede haber escrito su propio orden. Mantén lo que funciona y solo añade tus scripts debajo de las capas base, en lugar de reescribir el archivo.

#ensure vs start

start my_script
ensure my_script

• start inicia un recurso si está parado.
• ensure lo inicia si está parado, y lo reinicia si ya está en ejecución.

En un arranque normal, nada está en ejecución, así que se comportan igual. La diferencia se nota cuando los ejecutas en la consola en vivo: ensure my_script es el que quieres para recargar un script que acabas de editar. En server.cfg, usa ensure en todas partes para que solo tengas que recordar una palabra. Para lo contrario, stop my_script lo detiene, y refresh hace que el servidor vuelva a escanear la carpeta resources para nuevos o cambiados manifests.

#Carpetas con brackets como categorías

Una carpeta cuyo nombre está entre corchetes no es un recurso. Es una categoría, y FiveM busca dentro de ella:

resources/
  [core]/
    ox_lib/
    oxmysql/
    qb-core/
  [qb]/
    qb-garages/
  [standalone]/
    my_other_script/
  [mic]/
    my_script/

ensure [qb] inicia cada recurso dentro de [qb]. Eso mantiene server.cfg corto, y es cómo la mayoría de paquetes de framework se envían. Dos cosas que saber:

• El orden dentro de una carpeta con brackets no es algo en lo que confiar. Si qb-garages necesita qb-core, asegura qb-core en su propia línea arriba de ensure [qb], o declara dependency 'qb-core' en el manifest. El core no debe esperar a la suerte.
• Un recurso no puede estar anidado dentro de otro recurso. Los brackets son solo para agrupar. Si pones una carpeta de script dentro de la carpeta de otro script, FiveM no la encontrará. Mira No se pudo iniciar el recurso.

Un recurso dentro de una carpeta con brackets aún se encuentra por su propio nombre, así que ensure ox_lib funciona aunque la carpeta sea [core]/ox_lib.

#Dependencias en el manifest

Las líneas de orden en server.cfg son una herramienta. Una línea dependency en el manifest de un script es la otra, y es más confiable:

dependency 'ox_lib'
dependency 'oxmysql'

FiveM entonces comprueba que esos recursos existen y los inicia primero. Si uno falta, obtienes un mensaje claro en lugar de un error nil: No se pudo encontrar la dependencia X para el recurso Y. Usa ambas: un buen orden en el archivo, y dependencias en los manifests que controlas.

#Duplicados

Dos cosas van mal con los duplicados:

• El mismo ensure dos veces. Asegurar un recurso dos veces en server.cfg lo inicia, y luego lo reinicia justo después. Desperdicia tiempo de arranque y puede provocar escrituras duplicadas en la base de datos o eventos al iniciar. Elimina la segunda línea. Comprueba que una carpeta con brackets no ya incluya un recurso que también asegures por nombre.
• Dos carpetas con el mismo nombre de recurso. Si tienes resources/[old]/my_script y resources/[mic]/my_script, solo uno se usa, y cuál no es algo que puedas controlar. Elimina o renombra uno, y siempre elimina la versión anterior de un script antes de instalar una nueva.

Cuando una corrección que hiciste parece no tener efecto, comprueba que no editaste la copia que no está en ejecución.

#Encuentra el culpable cuando el orden es incorrecto

Inicia el servidor, luego lee la consola desde arriba. El primer recurso que imprime un error es la causa, y todo después puede ser efecto secundario. Ejemplos típicos:

• oxmysql imprime un error de base de datos: nada que use SQL funcionará.
• ox_lib falla: cada script con @ox_lib/init.lua se rompe (fix de ox_lib).
• El framework falla: cada script que le pide un objeto de jugador obtiene nil.

Arregla la primera falla y reinicia.

#Lista de comprobación