server.cfg, OneSync y el orden de ensure

El server.cfg es el guion de arranque de tu servidor: un archivo de texto que FXServer lee de arriba abajo cada vez que enciendes. En él configuras la red, le pones nombre al servidor, activas la sincronización, defines los permisos y, sobre todo, decides QUÉ recursos cargar y EN QUÉ ORDEN. Si algo va mal al arrancar, el 90% de las veces la causa está aquí.

Un server.cfg de ejemplo, comentado

# --- Red: por dónde escucha el servidor ---
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# --- Presentación ---
sv_hostname "Crxative-M | ESX | Roleplay ES"
sv_maxclients 48              # nº máximo de jugadores (>32 exige OneSync)
sv_projectName "Crxative-M"
sv_projectDesc "Servidor de rol en español"

# --- Sincronizacion server-authoritative ---
set onesync on
sv_endpointprivacy true       # no expone las IP de los jugadores

# --- Recursos base (el ORDEN importa, ver mas abajo) ---
ensure oxmysql
ensure ox_lib
ensure es_extended
ensure mi_recurso

# --- Secretos (fuera del repositorio) ---
exec secrets.cfg

Directivas clave que debes conocer

• endpoint_add_tcp / endpoint_add_udp "0.0.0.0:30120": el puerto por el que escucha el servidor. 0.0.0.0 significa «todas las interfaces de red». 30120 es el puerto estándar de FiveM.
• sv_maxclients: jugadores máximos simultáneos. Más de 32 OBLIGA a tener OneSync activado.
• sv_hostname: el nombre que aparece en la lista de servidores (admite colores con ^1, ^2…).
• sv_licenseKey "...": tu clave de cprx.fivem.net (keymaster). Es personal e intransferible: NUNCA la compartas ni la subas a Git.
• set onesync on: activa la sincronización moderna con autoridad en el servidor.
• sv_endpointprivacy true: oculta las direcciones IP de los jugadores conectados.
• exec otro.cfg: ejecuta otro archivo de configuración como si estuviera escrito aquí (ideal para separar secretos).

ensure, start, stop y restart

Para cargar recursos tienes varios comandos, pero en el server.cfg casi siempre querrás ensure. La diferencia: start solo arranca el recurso si está parado (y falla feo si ya estaba). ensure es más listo: si el recurso no está, lo inicia; si ya estaba corriendo, lo reinicia. Es idempotente, así que es seguro tenerlo en el cfg y volver a ejecutarlo.

ensure  oxmysql      # inicia o reinicia (lo que uses casi siempre)
start   oxmysql      # solo inicia si esta parado
stop    oxmysql      # detiene el recurso
restart oxmysql      # lo detiene y lo vuelve a iniciar

ensure [mi_categoria]  # con corchetes: arranca un GRUPO de recursos
                       # (una carpeta que agrupa varios recursos)

El orden de ensure (esto es lo crítico)

FXServer carga los recursos en el MISMO orden en que aparecen en el server.cfg. Y muchos recursos dependen de otros: necesitan que su «base» ya esté cargada para funcionar. Si arrancas un recurso de ESX antes que es_extended, ese recurso pedirá el objeto ESX y recibirá nil, porque todavía no existe. Resultado: el clásico error attempt to index a nil value (global 'ESX').

# ORDEN CORRECTO: primero las dependencias, luego quien las usa

ensure oxmysql        # 1. base de datos (la necesita todo lo demas)
ensure ox_lib         # 2. libreria base (UI, callbacks, utilidades)
ensure es_extended    # 3. el framework (ESX) o qb-core

# 4. AHORA si: recursos que dependen de los anteriores
ensure esx_menu_default
ensure esx_jobs
ensure mi_recurso_de_trabajos

• oxmysql primero: cualquier recurso que toque la base de datos lo necesita disponible desde el arranque.
• ox_lib después: muchísimos recursos modernos usan su sistema de callbacks, menús y notificaciones.
• es_extended (ESX) o qb-core: el framework que expone el objeto principal del que cuelgan los trabajos, el dinero, el inventario…
• Tus recursos al final: los que llaman a exports['es_extended'] o a ox_lib deben ir SIEMPRE por debajo de ellos.

OneSync: qué es y por qué activarlo

OneSync es el sistema de sincronización moderno de FiveM. La idea clave es server-authoritative: la autoridad de lo que ocurre en el mundo (entidades, posiciones, vehículos, NPCs) la tiene el servidor, no cada cliente. Eso permite más jugadores, entidades creadas desde el lado servidor y muchísima menos trampa, porque el cliente deja de ser «la fuente de la verdad».

• Permite superar los 32 jugadores (set onesync on llega hasta 128; con onesync_population y el modo Infinity, mucho más).
• Habilita entidades server-side: puedes crear vehículos y objetos desde server.lua que todos los jugadores ven de forma coherente.
• Reduce el desync y cierra la puerta a muchos cheats, porque el estado se valida en el servidor.
• Recuerda: sv_maxclients > 32 NO funcionará sin OneSync activado.

Permisos ACE: quién puede hacer qué

Los permisos en FiveM se gestionan con ACE (Access Control Entries). Funciona con dos piezas: add_principal asigna a un jugador (por su identifier) a un grupo, y add_ace concede a un grupo (o jugador) permiso sobre un «objeto» de comando. Así defines quién es administrador y qué comandos puede usar.

# Damos a un identifier el grupo group.admin
add_principal identifier.fivem:1234567 group.admin
# (tambien sirven identifier.steam:..., identifier.license:..., identifier.discord:...)

# El grupo admin puede usar todos los comandos
add_ace group.admin command allow

# Permiso concreto: solo el grupo admin puede usar /revive
add_ace group.admin command.revive allow

Secretos: nunca subas tu licencia a Git

La sv_licenseKey, las contraseñas de la base de datos o cualquier token sensible no deben vivir en el server.cfg que subes a tu repositorio. La práctica estándar es sacarlos a un secrets.cfg aparte (incluido en .gitignore) y cargarlo con exec.

# secrets.cfg  (este archivo va en .gitignore, NUNCA al repositorio)
sv_licenseKey "tu_clave_de_keymaster_aqui"
set mysql_connection_string "mysql://user:password@localhost/crxative?charset=utf8mb4"
set discord_webhook "https://discord.com/api/webhooks/..."

# Y en server.cfg, al final:
#   exec secrets.cfg