ordine del server.cfg: l'ordine corretto di avvio delle risorse per FiveM

Metà dei tuoi script lanciano errori nil all'avvio, ma funzionano quando li riavvii a mano. Quel pattern di solito significa che le risorse si avviano nell'ordine sbagliato. Questa guida ti dà un ordine che funziona per ESX, QBCore e QBox, e spiega ensure vs start, cartelle bracket e duplicati.

#Perché l'ordine importa

Le risorse si avviano nell'ordine delle righe in server.cfg. Uno script che legge il framework quando carica ottiene nil se il framework non è ancora stato avviato. Lo stesso vale per lo strato del database e per le librerie come ox_lib. Lo risolvi mettendo gli strati di base in alto:

1. Il database: oxmysql
2. La libreria: ox_lib
3. Il framework: es_extended, qb-core o qbx_core
4. L'inventory
5. Tutto il resto

#Un ordine che funziona

Per QBCore:

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

ensure [standalone]
ensure [mic]

Per QBox:

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

Per ESX:

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

Regola i nomi delle categorie alle tue cartelle. Se usi qb-inventory o un altro inventory al posto di ox_inventory, metti quello nella stessa posizione, subito dopo il framework (o prima di esso, se la sua documentazione lo dice).

Suggerimento: mantieni le risorse che assicuri per nome (oxmysql, ox_lib, il framework, l'inventory) in cartelle che non assicuri anche come bracket. Altrimenti vengono assicurate due volte, vedi Duplicati sotto. Molti setup le mettono in una cartella [core] che non viene mai assicurata nel complesso.

Suggerimento: la tua ricetta txAdmin potrebbe aver scritto il suo ordine. Mantieni quello che funziona e aggiungi solo i tuoi script sotto gli strati base, invece di riscrivere il file.

#ensure vs start

start my_script
ensure my_script

• start avvia una risorsa se è ferma.
• ensure l'avvia se è ferma, e la riavvia se è già in esecuzione.

A un avvio normale, nulla è in esecuzione, quindi si comportano allo stesso modo. La differenza appare quando le esegui nella console live: ensure my_script è quello che vuoi per ricaricare uno script che hai appena modificato. In server.cfg, usa ensure ovunque in modo da ricordare una sola parola. Per l'altra direzione, stop my_script lo ferma, e refresh fa sì che il server riesamini la cartella resources per manifesti nuovi o modificati.

#Cartelle bracket come categorie

Una cartella il cui nome è tra parentesi quadre non è una risorsa. È una categoria, e FiveM guarda dentro:

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

ensure [qb] avvia ogni risorsa dentro [qb]. Ciò mantiene server.cfg corto, ed è come viene fornito la maggior parte dei framework pack. Due cose da sapere:

• L'ordine all'interno di una cartella bracket non è qualcosa su cui fare affidamento. Se qb-garages ha bisogno di qb-core, assicura qb-core su una propria riga sopra ensure [qb], o dichiara dependency 'qb-core' nel manifest. Il core non deve aspettare la fortuna.
• Una risorsa non può essere nidificata all'interno di un'altra risorsa. Le bracket sono solo per il raggruppamento. Se metti una cartella di script dentro la cartella di un altro script, FiveM non la troverà. Vedi Couldn't start resource.

Una risorsa all'interno di una cartella bracket è comunque trovata dal suo nome, quindi ensure ox_lib funziona anche se la cartella è [core]/ox_lib.

#Dipendenze nel manifest

Le righe di ordine in server.cfg sono uno strumento. Una riga dependency nel manifest di uno script è l'altro, ed è più affidabile:

dependency 'ox_lib'
dependency 'oxmysql'

FiveM poi controlla che quelle risorse esistono e le avvia per primo. Se una manca, ottieni un messaggio chiaro invece di un errore nil: Could not find dependency X for resource Y. Usa entrambi: un buon ordine nel file e dipendenze nei manifest che controlli.

#Duplicati

Due cose vanno male con i duplicati:

• Lo stesso ensure due volte. Assicurare una risorsa due volte in server.cfg l'avvia e poi la riavvia subito. Spreca il tempo di avvio e può scatenare duplicate scritture del database o eventi all'inizio. Rimuovi la seconda riga. Controlla che una cartella bracket non includa già una risorsa che assicuri anche per nome.
• Due cartelle con lo stesso nome di risorsa. Se hai resources/[old]/my_script e resources/[mic]/my_script, solo una viene usata, e quale non è qualcosa che controlli. Elimina o rinomina una, e elimina sempre la versione vecchia di uno script prima di installarne una nuova.

Quando una correzione che hai fatto sembra non avere alcun effetto, controlla di non aver modificato la copia che non è in esecuzione.

#Trova il colpevole quando l'ordine è sbagliato

Avvia il server, poi leggi la console dall'inizio. La prima risorsa che stampa un errore è la causa, e tutto dopo di essa può essere una conseguenza. Esempi tipici:

• oxmysql stampa un errore di database: nulla che usi SQL funzionerà.
• ox_lib fallisce: ogni script con @ox_lib/init.lua si interrompe (ox_lib fix).
• Il framework fallisce: ogni script che chiede un oggetto giocatore ottiene nil.

Correggi il primo fallimento e riavvia.

#Checklist