mauvais argument #1 à 'X' (nombre attendu, got nil) : correction FiveM Lua

Quelque part dans votre console, un script s'arrête avec ceci :

SCRIPT ERROR: @my_script/client/main.lua:57: bad argument #1 to 'floor' (number expected, got nil)

Une fonction a été appelée avec un argument qu'elle ne peut pas utiliser, et l'argument est presque toujours nil. Le message vous dit quelle fonction, quel argument et quel type elle voulait. Ce guide montre comment le lire et les sources habituelles du nil.

#Comment lire le message

bad argument #1 to 'X' (number expected, got nil)

• X est le nom de la fonction qui s'est plainte.
• #1 est la position de l'argument : #1 est le premier, #2 le second.
• number expected est le type dont la fonction a besoin. Il peut aussi dire string, table ou boolean.
• got nil est ce qu'elle a réellement reçu. Il peut aussi être got table, got string ou got no value.

Ouvrez la ligne de l'erreur et recherchez la fonction nommée dans le message. Ensuite, regardez l'argument dans cette position et demandez-vous d'où il vient.

local price = Config.Prices[item]
local rounded = math.floor(price)   -- bad argument #1 to 'floor' (number expected, got nil)

Ici Config.Prices[item] est nil, car item n'est pas une clé de la table. L'erreur est sur la ligne math.floor, mais la faute est dans les données.

#table expected, got nil

Le même message avec une table apparaît avec les fonctions table :

bad argument #1 to 'insert' (table expected, got nil)

local list
table.insert(list, 'a')     -- list was never created

Créez la table avant de l'utiliser :

local list = {}
table.insert(list, 'a')

Pour une table qui vit dans une structure partagée, créez-la quand elle manque :

players[source] = players[source] or {}
table.insert(players[source], item)

#Bouclage sur nil : pairs et ipairs

En Lua 5.3 et 5.4, que FiveM utilise, bouclage sur nil échoue avec un message qui nomme la boucle au lieu de pairs :

bad argument #1 to 'for iterator' (table expected, got nil)

for _, job in pairs(Config.Jobs) do   -- Config.Jobs is nil

Vérifiez où la table est définie : une faute de frappe dans le nom, le fichier config pas chargé par le manifest, ou les données qui ne sont pas encore arrivées. Un court garde évite le crash pendant que vous trouvez la vraie cause :

for _, job in pairs(Config.Jobs or {}) do

Utilisez-le comme filet de sécurité, pas comme correctif. Si Config.Jobs devrait exister, une boucle vide cache seulement le bug. Le message connexe table index is nil couvre les clés manquantes dans les tables config imbriquées.

#Natives qui reçoivent nil

De nombreux natives ont besoin d'un nombre, comme une poignée d'entité. Une poignée qui est nil ou 0 signifie généralement que l'entité n'existe pas (encore).

local vehicle = GetVehiclePedIsIn(ped, false)
local plate = GetVehicleNumberPlateText(vehicle)   -- vehicle is 0 when the ped is on foot

Sources communes :

• L'entité n'a pas été chargée. Un véhicule générée par le serveur n'est pas disponible à votre client pendant un moment. Sur le client, attendez jusqu'à ce qu'il existe :

local vehicle = NetToVeh(netId)
local timeout = 0
while not DoesEntityExist(vehicle) and timeout < 100 do
    Wait(50)
    vehicle = NetToVeh(netId)
    timeout = timeout + 1
end

• Une fonction n'a rien retourné. GetPlayerPed(-1), GetClosestVehicle et similaire peut retourner 0 quand rien ne correspond. Vérifiez la valeur avant de l'utiliser.
• Un vecteur faux. Un native qui veut trois nombres, x, y, z, n'accepte pas une table entière. Passez coords.x, coords.y, coords.z, ou utilisez un vector3 où le native en prend un.
• Une clé manquante dans la config. Config.Spawn.x est nil quand Config.Spawn est écrit avec [1], [2], [3].

Le texte exact dépend du native, et certains natives ne lèvent pas d'erreur du tout mais ne font rien. C'est pourquoi ajouter une garde vaut le coup :

if vehicle ~= 0 and DoesEntityExist(vehicle) then
    SetVehicleEngineOn(vehicle, true, true, false)
end

#tostring, tonumber et string.format

Les fonctions de conversion sont une autre source de nil :

• tonumber('abc') retourne nil, pas une erreur, de sorte que le crash vient plus tard quand vous utilisez le résultat.
• tostring(value) retourne toujours une chaîne, même pour nil (cela donne 'nil'), donc c'est sûr à utiliser quand vous construisez un texte.
• string.format('%d', value) échoue quand value est nil : bad argument #2 to 'format' (number expected, got nil).

Quand un nombre vient d'un joueur ou d'une commande, vérifiez-le :

RegisterCommand('pay', function(source, args)
    local amount = tonumber(args[1])
    if not amount then
        return print('Usage: /pay [amount]')
    end
    print(('Paying %d'):format(amount))
end)

Notez que args[1] est nil quand le joueur a tapé /pay seul, et tonumber(nil) retourne nil, donc la vérification ci-dessus couvre les deux cas.

#Trouvez le nil

Quand la source n'est pas évidente, imprimez les valeurs juste avant la ligne défaillante :

print('item', item, type(item))
print('price', Config.Prices[item], type(Config.Prices[item]))

Ensuite, tracez le nil jusqu'à où il devrait avoir été défini. Supprimez les impressions quand vous avez terminé.

#Liste de contrôle

Si l'erreur concerne quelque chose d'autre que nil au lieu d'un mauvais argument, lisez tentative de comparer nil et tentative d'appel d'une valeur nil.