Comment lire une FiveM SCRIPT ERROR : fichier, ligne et pile d'appels

Une erreur typique dans la 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:...)

Cela semble du bruit, mais chaque partie a un sens, et cela vous dit généralement exactement où regarder. Ce guide montre comment le lire, où le trouver, et quoi faire quand c'est insuffisant.

#La première ligne : quoi, où et pourquoi

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

• SCRIPT ERROR: marque une erreur Lua dans un script. Le script continue de s'exécuter après, mais le code qui a échoué s'est arrêté à cette ligne.
• @my_script/server/main.lua est le nom de la ressource (my_script) et le chemin du fichier à l'intérieur du dossier de la ressource.
• :42 est le numéro de ligne dans ce fichier.
• Le reste est le message : attempt to index a nil value (local 'xPlayer'). Lua le lit comme ceci : à la ligne 42, vous avez essayé d'utiliser quelque chose à l'intérieur de xPlayer, mais xPlayer est nil.

Ouvrez le fichier, allez à cette ligne, et regardez les variables que cette ligne utilise. Dans la plupart des cas, la réponse est déjà là. Les messages courants ont leurs propres guides : tentative d'appeler une valeur nil et tentative de comparer nil.

#La pile d'appels : comment le code y est arrivé

Les lignes commençant par > sont la pile d'appels. Elle liste les fonctions qui s'exécutaient, de celle qui a échoué à celle qui l'a lancée :

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

La première ligne après l'erreur est le même endroit que l'erreur. Les lignes en dessous montrent qui a appelé cette fonction. Quand l'erreur est à l'intérieur d'une bibliothèque ou d'une autre ressource, une ligne de votre propre script plus bas dans la liste est souvent la vraie cause, parce que votre script a transmis une mauvaise valeur.

Les lignes qui commencent par citizen:/scripting/lua/... (par exemple citizen:/scripting/lua/scheduler.lua) appartiennent à FiveM lui-même. Elles font partie de la machinerie qui exécute vos événements et vos threads. Vous pouvez les ignorer : l'erreur n'est jamais corrigée là, et elles ne montrent que qu'un thread ou un événement s'exécutait.

#Client ou serveur : où regarder

Une erreur de script apparaît du côté où le code s'exécute :

• Scripts client (client_scripts, fichiers dans un dossier client) : appuyez sur F8 dans le jeu pour ouvrir la console client. Si vous ne voyez rien, faites défiler vers le haut, car les erreurs peuvent disparaître rapidement.
• Scripts serveur (server_scripts, fichiers dans un dossier server) : lisez la console du serveur. Dans txAdmin, c'est la page Live Console. Sur un serveur démarré à partir d'un terminal, c'est cette fenêtre de terminal.
• Scripts partagés s'exécutent des deux côtés, donc l'erreur peut apparaître dans l'un ou l'autre endroit.

Conseil : si un menu ou une action ne fait rien et que F8 est vide, vérifiez la console du serveur. Le code qui a échoué peut être du côté serveur.

#Quelle ligne regarder

1. Lisez d'abord le message : il dit quel type de problème c'est (nil, un mauvais type, une export manquante).
2. Ouvrez le fichier et la ligne de la première ligne. Vérifiez chaque variable sur elle.
3. Si le fichier appartient à une bibliothèque (ox_lib, le framework), descendez la pile d'appels jusqu'à ce que vous atteignez une ligne du script que vous corrigez.
4. Vérifiez si l'erreur apparaît une fois ou constamment. Une erreur constante dans une boucle inonde la console. Corrigez celle-ci d'abord, car elle cache d'autres messages.

Les erreurs avec le texte No such export ou could not find dependency sont différentes. Elles concernent les ressources, pas les lignes de code. Consultez could not find dependency.

#Quand la ligne n'est pas suffisante : ajouter des prints

Si la ligne utilise plusieurs variables et vous ne savez pas laquelle est nil, imprimez-les juste avant :

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

Exécutez à nouveau le code et lisez la console. Quelques conseils pour des prints utiles :

• Imprimez le type ainsi que la valeur : type(value) affiche nil, number, string, table ou function.
• Utilisez json.encode(table) pour voir l'intérieur d'une table. Un simple print(table) n'affiche qu'une adresse mémoire.
• Mettez une courte étiquette devant, donc vous pouvez trouver la ligne dans une console occupée.
• Imprimez au début d'une fonction, pour confirmer qu'elle s'exécute du tout.

Supprimez les prints une fois le problème corrigé, car ils coûtent en performance dans les boucles occupées.

#Où une erreur n'apparaît pas

• Scripts entérinés cachent leur code. L'erreur vous donne un nom de fichier, mais le fichier est chiffré et vous ne pouvez pas lire la ligne. Contactez l'auteur avec le texte d'erreur complet.
• Les erreurs NUI (le menu lui-même, écrit en HTML et JavaScript) ne s'affichent pas en F8 comme SCRIPT ERROR. Ouvrez les outils de développement NUI pour les lire : la commande nui_devtools dans la console F8 les ouvre dans un onglet de navigateur.
• Les erreurs dans les premières secondes : quand vous démarrez le serveur, les erreurs des ressources qui ne parviennent pas à charger peuvent passer rapidement. Recherchez la console ou faites défiler vers le haut, ou redémarrez seulement celle-ci et regardez.

#Quoi envoyer quand vous demandez de l'aide

Copiez l'erreur complète, la pile d'appels incluse, en tant que texte, et dites si elle provient de F8 ou de la console du serveur. Ajoutez la ligne de code à laquelle elle pointe et le framework que vous utilisez. Une capture d'écran d'une ligne recadrée n'est pas suffisante pour que quelqu'un vous aide.

#Liste de contrôle