Corriger « attempt to index a nil value » dans les scripts FiveM (ESX, QBCore, xPlayer)

Cette erreur Lua signifie qu'un script a utilisé comme une table quelque chose qui n'existe pas. L'élément entre parenthèses, comme global 'ESX' ou local 'xPlayer', indique ce qui manque, et chacun a sa propre correction.

Par l'équipe Nodewave · Mis à jour le 8 novembre 2026

Lisez d'abord l'erreur

La console du serveur et la console F8 affichent l'erreur ainsi :

SCRIPT ERROR: @my_script/server/main.lua:12: attempt to index a nil value (global 'ESX')

Le nom de la ressource, le fichier et le numéro de ligne viennent en premier : vous savez donc exactement où regarder. Les mots entre parenthèses indiquent ce qui est nil :

Corriger global 'ESX'

1. Démarrez ESX en premier. Dans server.cfg, placez ensure es_extended au-dessus de tous les scripts qui l'utilisent, et cherchez dans la console les erreurs d'es_extended lui-même, qui a besoin de sa connexion à la base de données pour démarrer.
2. Importez ESX dans le script. Ajoutez cette ligne au fxmanifest.lua du script :

shared_script '@es_extended/imports.lua'

Ou définissez l'objet en Lua, près du haut du fichier :

ESX = exports["es_extended"]:getSharedObject()

Les anciens scripts utilisent TriggerEvent('esx:getSharedObject', ...). Cet événement n'existe plus dans l'ESX actuel : remplacez-le par l'export ci-dessus.

Corriger global 'QBCore'

Définissez l'objet en haut de chaque fichier Lua qui l'utilise :

local QBCore = exports['qb-core']:GetCoreObject()

Un local d'un fichier n'est pas visible dans un autre : un script qui marche dans client/main.lua peut donc échouer dans client/events.lua. Démarrez qb-core avant le script dans server.cfg. Qbox inclut une couche de compatibilité pour la plupart des scripts QBCore, mais vérifiez que le script la prend en charge.

Corriger local 'xPlayer'

ESX.GetPlayerFromId(source) et QBCore.Functions.GetPlayer(source) renvoient nil quand le joueur n'est pas encore chargé, est parti, ou que l'ID est faux. Vérifiez toujours le résultat avant de l'utiliser :

local xPlayer = ESX.GetPlayerFromId(source)
if not xPlayer then return end

Raisons courantes de l'absence du joueur :

• source vaut 0 quand une commande est lancée depuis la console du serveur : il n'y a donc pas de joueur.
• source peut changer après un Wait. Copiez-le d'abord avec local src = source et utilisez ensuite src.
• L'événement s'est produit pendant que le joueur se connectait encore. Attendez l'événement « joueur chargé » du framework : esx:playerLoaded dans ESX et QBCore:Server:PlayerLoaded dans QBCore.
• Le joueur est hors ligne. Cherchez-le plutôt par identifiant dans la base de données.

Corriger un champ manquant

Si une table existe mais qu'une clé est nil, les données correspondantes n'ont pas été chargées. Vérifiez que le fichier de configuration est listé dans fxmanifest.lua avant les fichiers qui l'utilisent, que le nom est écrit pareil partout, et que la version du script correspond à celle de votre framework. Les frameworks renomment des fonctions d'une version à l'autre, et les scripts écrits pour une version plus ancienne cessent de marcher.

Vérifiez les bases

• Lisez la première erreur de la console. Les erreurs suivantes sont souvent la conséquence de la première.
• Vérifiez le réglage de framework propre au script, s'il en a un, dans son fichier de configuration.
• Après avoir modifié un script, exécutez restart resource_name dans la console et surveillez les nouvelles erreurs.

Toujours bloqué ?

Demandez à l'auteur du script, en indiquant le texte complet de l'erreur, le fichier et la ligne, votre framework et sa version, ainsi que l'ordre de démarrage de server.cfg.