Wie man einen FiveM SCRIPT ERROR liest: Datei, Zeile und Stack Trace

Ein typischer Fehler in der Konsole:

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:...)

Es sieht wie Lärm aus, aber jeder Teil hat eine Bedeutung, und es sagt dir normalerweise genau, wo du schauen musst. Dieser Leitfaden zeigt, wie man ihn liest, wo man ihn findet, und was man tut, wenn es nicht ausreicht.

#Die erste Zeile: was, wo und warum

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

• SCRIPT ERROR: markiert einen Lua-Fehler in einem Script. Das Script läuft nach diesem weiter, aber der Code, der fehlgeschlagen ist, stoppt an dieser Zeile.
• @my_script/server/main.lua ist der Ressourcenname (my_script) und der Pfad der Datei im Ressourcenordner.
• :42 ist die Zeilennummer in dieser Datei.
• Der Rest ist die Nachricht: attempt to index a nil value (local 'xPlayer'). Lua liest sie so: auf Zeile 42 hast du versucht, etwas in xPlayer zu verwenden, aber xPlayer ist nil.

Öffne die Datei, gehe zu dieser Zeile, und schaue auf die Variablen, die diese Zeile verwendet. In den meisten Fällen ist die Antwort bereits dort. Häufige Meldungen haben ihre eigenen Anleitungen: attempt to call a nil value und attempt to compare nil.

#Der Stack Trace: wie der Code dort angekommen ist

Die Zeilen, die mit > beginnen, sind der Stack Trace. Es listet die Funktionen auf, die liefen, von der fehlgeschlagenen bis zu der, die sie startete:

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

Die erste Zeile nach dem Fehler ist der gleiche Ort wie der Fehler. Zeilen darunter zeigen, wer diese Funktion aufgerufen hat. Wenn der Fehler in einer Bibliothek oder einer anderen Ressource ist, ist eine Zeile von deinem eigenen Script, die weiter unten in der Liste ist, oft die eigentliche Ursache, weil dein Script einen falschen Wert hineinübergeben hat.

Zeilen, die mit citizen:/scripting/lua/... beginnen (zum Beispiel citizen:/scripting/lua/scheduler.lua) gehören zu FiveM selbst. Sie sind Teil der Maschinerie, die deine Events und Threads läuft. Du kannst sie ignorieren: Der Fehler wird dort nie behoben, und sie zeigen nur, dass ein Thread oder ein Event lief.

#Client oder Server: wo man schaut

Ein Script-Fehler erscheint auf der Seite, wo der Code läuft:

• Client-Scripts (client_scripts, Dateien in einem client Ordner): drücke F8 im Spiel, um die Client-Konsole zu öffnen. Wenn du nichts siehst, scrolle hoch, da Fehler schnell wegscollen können.
• Server-Scripts (server_scripts, Dateien in einem server Ordner): Lese die Server-Konsole. In txAdmin ist das die Live Console Seite. Auf einem Server, der von einem Terminal gestartet wurde, ist es dieses Terminal-Fenster.
• Shared-Scripts laufen auf beiden Seiten, also kann der Fehler auf beiden Orten erscheinen.

Tipp: Wenn ein Menü oder eine Aktion nichts tut und F8 ist leer, überprüfe die Server-Konsole. Der fehlgeschlagene Code kann auf der Server-Seite sein.

#Welche Zeile man schaut

1. Lese die Nachricht zuerst: Sie sagt, welche Art von Problem es ist (nil, ein falscher Typ, ein fehlender Export).
2. Öffne die Datei und Zeile aus der ersten Zeile. Überprüfe jede Variable auf ihr.
3. Wenn die Datei einer Bibliothek gehört (ox_lib, das Framework), gehe im Stack Trace herunter, bis du eine Zeile des Scripts erreichst, das du fixst.
4. Überprüfe, ob der Fehler einmal oder ständig erscheint. Ein konstanter Fehler in einer Schleife flutet die Konsole. Behebe diesen zuerst, da er andere Meldungen verbirgt.

Fehler mit dem Text No such export oder could not find dependency sind anders. Sie handeln von Ressourcen, nicht von Codezeilen. Siehe could not find dependency.

#Wenn die Zeile nicht ausreicht: Füge Prints ein

Wenn die Zeile mehrere Variablen verwendet und du nicht weißt, welche nil ist, drucke sie gerade davor:

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

Führe den Code erneut aus und lese die Konsole. Einige Tipps für nützliche Prints:

• Drucke den Typ sowie den Wert: type(value) zeigt nil, number, string, table oder function.
• Verwende json.encode(table), um das Innere einer Tabelle zu sehen. Ein einfaches print(table) zeigt nur eine Speicheradresse.
• Lege ein kurzes Label davor, damit du die Zeile in einer beschäftigten Konsole findest.
• Drucke am Anfang einer Funktion, um zu bestätigen, dass sie überhaupt läuft.

Entferne die Prints, wenn das Problem behoben ist, da sie Leistung in beschäftigten Schleifen kosten.

#Wo ein Fehler nicht erscheint

• Escrowed Scripts verstecken ihren Code. Der Fehler gibt dir einen Dateinamen, aber die Datei ist verschlüsselt und du kannst die Zeile nicht lesen. Kontaktiere den Autor mit dem vollständigen Fehlertext.
• NUI-Fehler (das Menü selbst, geschrieben in HTML und JavaScript) zeigen sich nicht in F8 als SCRIPT ERROR. Öffne die NUI Developer-Tools, um sie zu lesen: Der nui_devtools Befehl in der F8-Konsole öffnet sie in einem Browser-Tab.
• Fehler in den ersten Sekunden: Wenn du den Server startest, können Fehler von Ressourcen, die nicht geladen werden, schnell vorbeigehen. Suche die Konsole oder scrolle hoch, oder starte nur eine Ressource neu und beobachte.

#Was man sendet, wenn man um Hilfe bittet

Kopiere den kompletten Fehler, der Stack Trace inbegriffen, als Text, und sage, ob er von F8 oder der Server-Konsole kommt. Füge die Codezeile hinzu, auf die er zeigt, und das Framework, das du verwendest. Ein Screenshot einer abgeschnittenen Zeile ist nicht genug, damit jemand dir hilft.

#Checkliste