bad argument #1 to 'X' (number expected, got nil): FiveM Lua Behebung

Irgendwo in deiner Konsole stoppt ein Skript mit:

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

Eine Funktion wurde mit einem Argument aufgerufen, das sie nicht verwenden kann, und das Argument ist fast immer nil. Die Meldung sagt dir, welche Funktion, welches Argument und welchen Typ es wollte. Dieser Leitfaden zeigt dir, wie man es liest und die üblichen Quellen des nil.

#Wie man die Meldung liest

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

• X ist der Name der Funktion, die sich beschwerte.
• #1 ist die Position des Arguments: #1 ist der erste, #2 der zweite.
• number expected ist der Typ, den die Funktion braucht. Es kann auch string, table oder boolean sagen.
• got nil ist das, was es tatsächlich erhielt. Es kann auch got table, got string oder got no value sein.

Öffne die Zeile aus dem Fehler und schaue die Funktion an, die in der Meldung benannt ist. Schaue dann auf das Argument an dieser Position und frag dich, woher es kommt.

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

Hier ist Config.Prices[item] nil, weil item kein Schlüssel der Tabelle ist. Der Fehler ist auf der math.floor-Zeile, aber der Fehler ist in den Daten.

#Tabelle erwartet, nil erhalten

Die gleiche Meldung mit einer Tabelle erscheint mit table-Funktionen:

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

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

Erstelle die Tabelle, bevor du sie verwendest:

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

Für eine Tabelle, die in einer gemeinsamen Struktur lebt, erstelle sie, wenn sie fehlt:

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

#Schleifen über nil: pairs und ipairs

In Lua 5.3 und 5.4, das FiveM verwendet, schlägt das Schleifen über nil mit einer Meldung fehl, die die Schleife benennt anstelle von pairs:

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

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

Überprüfe, wo die Tabelle definiert wird: ein Tippfehler im Namen, die Config-Datei nicht vom Manifest geladen, oder Daten, die noch nicht angekommen sind. Eine kurze Bewachung vermeidet den Crash, während du die echte Ursache findest:

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

Verwende es als Sicherheitsnetz, nicht als Behebung. Wenn Config.Jobs existieren sollte, hides eine leere Schleife nur den Bug. Die verwandte Meldung table index is nil behandelt fehlende Schlüssel in verschachtelten Config-Tabellen.

#Natives, die nil erhalten

Viele Natives brauchen eine Zahl, wie ein Entity-Handle. Ein Handle, das nil oder 0 ist, bedeutet normalerweise, dass die Entität noch nicht existiert (noch).

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

Häufige Quellen:

• Die Entität ist nicht geladen. Ein Fahrzeug, das von dem Server gespawnt wird, ist für einen Moment für deinen Client nicht verfügbar. Auf dem Client, warte bis es existiert:

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

• Eine Funktion gab nichts zurück. GetPlayerPed(-1), GetClosestVehicle und ähnliche können 0 zurückgeben, wenn nichts passt. Überprüfe den Wert, bevor du ihn verwendest.
• Ein falscher Vektor. Ein Native, das drei Zahlen will, x, y, z, akzeptiert keine ganze Tabelle. Übergib coords.x, coords.y, coords.z, oder verwende ein vector3, wo das Native einen nimmt.
• Ein fehlender Schlüssel in der Config. Config.Spawn.x ist nil, wenn Config.Spawn mit [1], [2], [3] geschrieben wird.

Der genaue Text hängt vom Native ab, und einige Natives erheben überhaupt keinen Fehler, aber tun nichts. Deshalb lohnt sich eine Bewachung:

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

#tostring, tonumber und string.format

Konvertierungsfunktionen sind eine weitere Quelle des nil:

• tonumber('abc') gibt nil zurück, nicht einen Fehler, daher kommt der Crash später, wenn du das Ergebnis verwendest.
• tostring(value) gibt immer einen String zurück, auch für nil (es gibt 'nil'), daher ist es sicher zu verwenden, wenn du einen Text buildest.
• string.format('%d', value) schlägt fehl, wenn value nil ist: bad argument #2 to 'format' (number expected, got nil).

Wenn eine Zahl von einem Spieler oder von einem Befehl kommt, überprüfe sie:

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)

Beachte args[1] ist nil, wenn der Spieler /pay allein tippte, und tonumber(nil) gibt nil zurück, daher deckt die Überprüfung oben beide Fälle ab.

#Finde das nil

Wenn die Quelle nicht offensichtlich ist, drucke die Werte direkt vor der fehlgeschlagenen Zeile:

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

Dann verfolge das nil zurück bis dort, wo es hätte gesetzt werden sollen. Entferne die Prints, wenn du fertig bist.

#Checkliste

Wenn der Fehler von etwas ist, das nil ist anstelle eines schlechten Arguments, lies attempt to compare nil und attempt to call a nil value.