So debuggst du einen FiveM-Server Schritt für Schritt

Debugge ein FiveM-Problem, indem du ein Symptom reproduzierst, den ersten relevanten Fehler findest und eine Ursache auf einem Testserver änderst. Halte die zuletzt funktionierenden Dateien und die passende Datenbank bereit, bevor du die Produktion anfasst.

Wähle die richtigen Beweismittel

Ein clientseitiger Absturz oder UI-Fehler erfordert die F8-Ausgabe des betroffenen Spielers und die Reproduktionsschritte. Ein Serverprozess-Exit erfordert FXServer/Host-Logs und jede Absturzreferenz. Ein langsamer Beitritt erfordert Zeitmessungen nach Phasen; niedrige FPS erfordern clientseitige Frame-Zeit-Beweise. Mehrere Spieler, die gleichzeitig laggen, erfordern möglicherweise Server- und Netzwerk-Messungen.

Notiere UTC-Zeit, betroffene Spieler, Ort, Aktion, Artefakt, Framework-/Ressourcenversionen und aktuelle Änderungen. Schwärze Anmeldeinformationen und persönliche Identifikatoren aus geteilten Logs.

Lies den ersten Fehler

Verwende deine tatsächliche Startumgebung: txAdmin-Konsole und deren konfigurierte Logs, ein Dienstjournal oder umgeleitete Prozessausgabe. Es gibt keinen universellen server-data/server.log-Pfad für jede Installation.

Lies den ersten Fehler, der die Ressource betrifft, einschließlich Datei, Zeile und Stack-Trace. Spätere fehlende Exports können Folgen einer früheren fehlgeschlagenen Abhängigkeit sein. Bei einem nil-Wert überprüfe den Produzenten des Werts und den Rückgabepfad, anstatt blind einen Standardwert einzufügen.

Sicher reproduzieren

1. Erstelle eine isolierte Kopie mit repräsentativer Konfiguration und Testdaten. Bestätige, dass der Fehler dort immer noch auftritt.
2. Überprüfe Abhängigkeiten, genaue Ordnernamen und Startreihenfolge, bevor du die Logik bearbeitest. Auf einem case-sensitiven Host ist die Groß-/Kleinschreibung von Dateipfaden wichtig.
3. Reduziere die Reproduktion auf den kleinsten betroffenen Ressourcensatz, während die erforderlichen Abhängigkeiten erhalten bleiben. Deaktiviere einen Verdächtigen nach dem anderen.
4. Wende eine gezielte Korrektur an, wiederhole die ursprüngliche Aktion und teste den relevanten Fehlerpfad mit einem nicht privilegierten Spieler.
5. Verbinde dich erneut, starte die Ressource neu und führe einen vollständigen Server-Neustart durch. Behalte die Korrektur nur bei, wenn Persistenz und Berechtigungen korrekt bleiben.

Verwende Diagnosen für ihren eigentlichen Zweck

Das Server-Befehlsreferenz dokumentiert refresh, ensure und restart. Diese Befehle können den Zustand laufender Ressourcen beeinflussen; verwende sie auf Staging oder in einem abgestimmten Wartungsfenster.

se_debug true aktiviert die ACL-/Sicherheitsprotokollierung, nicht einen allgemeinen Skript-Debug-Modus. Schalte es mit se_debug false nach der Berechtigungsuntersuchung aus. Ein benutzerdefiniertes set debug_mode true hat keine Auswirkung, es sei denn, eine Ressource liest diese Convar explizit.

Nutze Profiler für die Skriptausführung. Resmon ist clientseitig und meldet weder die Datenbankabfragezeit noch die gesamten GPU-Kosten.

Eskaliere mit einem nützlichen Bericht

Füge erwartetes versus tatsächliches Verhalten, genaue Reproduktionsschritte, den ersten vollständigen Fehler, relevante Versionen und was sich geändert hat, hinzu. Stelle einen kleinen Konfigurationsausschnitt ohne Geheimnisse bereit. Halte irrelevante Ressourcendumps und Spielerdaten privat.

Wenn sich das Produktionsproblem verschlimmert, stelle die zuletzt akzeptierte Ressource/Konfiguration wieder her. Stelle eine Datenbank nur bei Bedarf und nach Berücksichtigung neuerer Spielerfortschritte wieder her.