Come leggere un FiveM SCRIPT ERROR: file, riga e stack trace

Un errore tipico nella console:

SCRIPT ERROR: @my_script/server/main.lua:42: attempt to index a nil value (local 'xPlayer')
> handler (@my_script/server/main.lua:42)
> ref (citizen:/scripting/lua/scheduler.lua:...)

Sembra rumore, ma ogni parte ha un significato, e di solito ti dice esattamente dove guardare. Questa guida mostra come leggerlo, dove trovarlo, e cosa fare quando non è abbastanza.

#La prima riga: cosa, dove e perché

SCRIPT ERROR: @my_script/server/main.lua:42: attempt to index a nil value (local 'xPlayer')

• SCRIPT ERROR: marca un errore Lua in uno script. Lo script continua a girare dopo, ma il codice che è fallito si è fermato in quella riga.
• @my_script/server/main.lua è il nome della risorsa (my_script) e il percorso del file dentro la cartella della risorsa.
• :42 è il numero di riga in quel file.
• Il resto è il messaggio: attempt to index a nil value (local 'xPlayer'). Lua lo legge così: in riga 42 hai provato a usare qualcosa dentro xPlayer, ma xPlayer è nil.

Apri il file, vai a quella riga, e guarda le variabili che quella riga usa. Nella maggior parte dei casi la risposta è già lì. I messaggi comuni hanno le loro guide: tentativo di chiamare un valore nil e tentativo di confrontare nil.

#Lo stack trace: come il codice è arrivato lì

Le linee che iniziano con > sono lo stack trace. Elenca le funzioni che stavano girando, da quella fallita fino a quella che l'ha avviata:

> handler (@my_script/server/main.lua:42)
> ref (citizen:/scripting/lua/scheduler.lua:...)

La prima riga dopo l'errore è lo stesso posto dell'errore. Le linee sotto mostrano chi ha chiamato quella funzione. Quando l'errore è dentro una libreria o un'altra risorsa, una riga dal tuo script più giù nell'elenco è spesso la vera causa, perché il tuo script ha passato un valore sbagliato in esso.

Le linee che iniziano con citizen:/scripting/lua/... (per esempio citizen:/scripting/lua/scheduler.lua) appartengono a FiveM stesso. Sono parte della macchinaria che esegue i tuoi eventi e thread. Puoi ignorarle: l'errore non è mai risolto lì, e mostrano solo che un thread o un evento stava girando.

#Client o server: dove guardare

Un errore di script appare sul lato dove gira il codice:

• Script client (client_scripts, file in una cartella client): premi F8 nel gioco per aprire la console client. Se non vedi niente, scorri su, poiché gli errori possono scorrere velocemente.
• Script server (server_scripts, file in una cartella server): leggi la console del server. In txAdmin, quella è la pagina Live Console. Su un server avviato da un terminale, è quella finestra del terminale.
• Script condivisi girano su entrambi i lati, quindi l'errore può apparire su entrambi.

Suggerimento: se un menu o un'azione non fa nulla e F8 è vuoto, controlla la console del server. Il codice fallito potrebbe essere dal lato server.

#Quale riga guardare

1. Leggi il messaggio per primo: dice che tipo di problema è (nil, un tipo sbagliato, un export mancante).
2. Apri il file e riga dalla prima riga. Controlla ogni variabile su di essa.
3. Se il file appartiene a una libreria (ox_lib, il framework), scendi nello stack trace fino a raggiungere una riga dello script che stai correggendo.
4. Controlla se l'errore appare una volta o costantemente. Un errore costante in un loop allaga la console. Correggi quello per primo, poiché nasconde altri messaggi.

Gli errori con il testo No such export o could not find dependency sono diversi. Riguardano le risorse, non le righe di codice. Vedi could not find dependency.

#Quando la riga non è abbastanza: aggiungi print

Se la riga usa molte variabili e non sai quale è nil, stampale appena prima:

print('xPlayer:', xPlayer)
print('source:', source, type(source))
print('data:', json.encode(data))

Esegui il codice di nuovo e leggi la console. Alcuni suggerimenti per stampe utili:

• Stampa il tipo così come il valore: type(value) mostra nil, number, string, table o function.
• Usa json.encode(table) per vedere l'interno di una tabella. Un semplice print(table) mostra solo un indirizzo di memoria.
• Metti un'etichetta breve davanti, così puoi trovare la riga in una console affollata.
• Stampa all'inizio di una funzione, per confermare che gira affatto.

Rimuovi le stampe una volta che il problema è risolto, poiché costano performance nei loop affollati.

#Dove un errore non appare

• Script bloccati nascondono il loro codice. L'errore ti dà un nome di file, ma il file è criptato e non puoi leggere la riga. Contatta l'autore con il testo dell'errore completo.
• Errori NUI (il menu stesso, scritto in HTML e JavaScript) non appaiono in F8 come SCRIPT ERROR. Apri gli strumenti di sviluppo NUI per leggerli: il comando nui_devtools nella console F8 li apre in una scheda del browser.
• Errori nei primi secondi: quando avvii il server, gli errori dalle risorse che non riescono a carico possono passare velocemente. Cerca nella console o scorri su, o riavvia solo quella risorsa e guarda.

#Cosa inviare quando chiedi aiuto

Copia l'errore completo, lo stack trace incluso, come testo, e dì se viene da F8 o dalla console del server. Aggiungi la riga di codice a cui punta e il framework che usi. Una schermata di una sola riga ritagliata non è abbastanza per chiunque ti aiuti.

#Checklist