FiveM Fahrzeug-Skripte Fehlerbehebung FAQ: 12 häufige Probleme gelöst

Fahrzeug-Skripte bestimmen die Hälfte des Roleplay-Erlebnisses auf einem FiveM-Server. Spawning, Individualisierung, Treibstoff, Schlüssel, Garagen — wenn nur ein einziges Teil ausfällt, bemerkt es jeder Spieler innerhalb der ersten fünf Minuten einer Session.

Dieser Leitfaden behandelt die zwölf Fahrzeug-Skript-Fehler, die wir am häufigsten auf ESX-, QBCore- und QBox-Installationen sehen. Jeder Abschnitt zeigt, wie du die Ursache diagnostizierst, die Lösung, die das Problem in den meisten Fällen behebt, und den Sonderfall, der selbst erfahrene Admins erwischt.

Warum Fahrzeug-Skripte kaputtgehen

FiveM-Fahrzeugskripte sitzen an der Schnittstelle von drei komplexen Systemen: GTA Vs natives Fahrzeugmodell-System, die Resource-Streaming-Pipeline des Servers und das Framework, das Persistenz und Spielerzustand verwaltet. Wenn etwas kaputtgeht, ist es selten eine einzelne offensichtliche Ursache — häufiger ist es eine Kaskade kleiner Fehlkonfigurationen, die einzeln harmlos wären, aber zusammen verhindern, dass das Fahrzeug korrekt geladen, gespawnt oder gespeichert wird.

Streaming-Limits sind der stille Killer. FiveM setzt ein Streaming-Speicherbudget durch, das aus den Engine-Beschränkungen von GTA V abgeleitet ist, und jedes Addon-Fahrzeug verbraucht einen Teil dieses Budgets durch seine .yft-Modelldateien, .ytd-Texturarchive und optional .ycd-Animationsdictionaries sowie .yvr-Vehicle-Recording-Dateien. Ein einzelnes Addon-Fahrzeug mit 4K-Lackierungen und einem hochdetaillierten Interieur kann 8-15 MB verbrauchen. Auf einem Server mit 40 Spielern, die jeweils ein eigenes Addon-Auto fahren, erreicht die Engine ihre Streaming-Obergrenze und Modelle laden stillschweigend nicht — der Spieler läuft auf einen unsichtbaren Collider zu, der fährt, aber nicht gerendert wird.

Modellkonflikte treten auf, wenn zwei Ressourcen denselben Fahrzeugmodellnamen in vehicles.meta registrieren. Die Ressource, die zuletzt startet, gewinnt die Registrierung, aber die Handling-Daten, Lackierungen und Tuning-Indizes der überschriebenen Ressource verweisen immer noch auf das nun ersetzte Modell. Das Ergebnis ist ein Auto, das mit dem Handling von Fahrzeug A und der Karosserie von Fahrzeug B spawnt, oder ein Tuning-Menü, das Upgrade-Optionen anzeigt, die das Modell tatsächlich nicht unterstützt.

Meta-Datei-Registrierungsfehler machen etwa die Hälfte aller Fahrzeugfehler aus, die wir diagnostizieren. Jede Addon-Fahrzeugressource benötigt mindestens drei data_file-Deklarationen in fxmanifest.lua: VEHICLE_METADATA_FILE, die auf vehicles.meta zeigt, CARCOLS_FILE, die auf carvariations.meta zeigt, und HANDLING_FILE, die auf handling.meta zeigt. Wenn du eine davon vergisst, auf den falschen Dateipfad verweist oder sie in der falschen Reihenfolge deklarierst, lädt GTA das Fahrzeug mit Standard-Handling, ohne Lackierungen oder gar nicht. Die Reihenfolge der data_file-Deklarationen ist wichtig, weil GTA sie sequenziell verarbeitet — eine Handling-Datei, die spät geladen wird, kann eine früher geladene stillschweigend überschreiben.

Kategorie-Inkonsistenzen zwischen der Fahrzeugressource und dem Shop-System des Frameworks sind der verwirrendste Fehlermodus für neue Admins. ESX-Fahrzeugshops erwarten Fahrzeuge, die in Config.DealerVehicles oder der vehicle_categories-Datenbanktabelle registriert sind. QBCore verwendet eine gemeinsame vehicles.lua-Config mit einem shop-Feld. QBox verwendet ox_inventory/data/vehicles.lua mit einem völlig anderen Schema. Ein Custom-Fahrzeug spawnt problemlos über /car modelName, erscheint aber nie in einer Shop-UI, weil seine Kategorie nicht in der Shop-Konfiguration des Frameworks registriert ist — das Modell lädt einwandfrei, das Framework weiß nur nicht, dass es es verkaufen soll.

Schnelldiagnose-Tabelle

Bevor du in die einzelnen Probleme eintauchst, ordne das beobachtete Symptom der wahrscheinlichsten Ursache zu.

Symptom	Wahrscheinlichste Ursache	Erster Prüfschritt
Fahrzeug spawnt über keine Methode	Fehlende oder beschädigte Modelldateien	stream/-Ordner enthält .yft und .ytd
Fahrzeug spawnt unsichtbar, aber fahrbar	Fehlende .ytd-Texturdatei	stream/ auf modelname.ytd und modelname_hi.yft prüfen
Fahrzeug spawnt, aber Handling fühlt sich falsch an	Handling-Datei nicht geladen oder überschrieben	fxmanifest.lua data_file-Einträge — Reihenfolge ist entscheidend
Fahrzeug über /car verfügbar, aber nicht im Shop	Framework-Shop-Konfigurationsinkonsistenz	vehicles.lua (QBCore) oder Config.DealerVehicles (ESX)
Schlüsselsystem erkennt gekauftes Fahrzeug nicht	Event feuert nach dem Kauf nicht	Server-Konsole auf TriggerServerEvent-Aufrufe prüfen
Tankanzeige bleibt bei 100 % oder 0 %	Treibstoffskript erkennt Motorzustand nicht	GetVehicleCurrentRpm gibt nicht-null zurück, wenn der Motor läuft
Garage speichert Fahrzeug, holt es aber nicht zurück	Datenbankschema-Inkonsistenz	DESCRIBE der player_vehicles-Tabelle
Fahrzeug spawnt mit Schaden, den es vorher nicht hatte	Garage speichert Karosserie-/Motorzustand nicht	GetVehicleBodyHealth- und GetVehicleEngineHealth-Speicheraufrufe
Leistungsmods werden nicht angewendet	Modell unterstützt diese Mod-Kategorie nicht	GetNumVehicleMods(vehicle, modType) gibt Anzahl zurück
Lackierungen auswählbar, erscheinen aber nicht	Textur fehlt in .ytd oder Namensinkonsistenz in carvariations.meta	Lackierungsnamen in beiden Dateien vergleichen, Groß-/Kleinschreibung beachten
Fahrzeugverriegelung lässt sich nicht umschalten	Besitzerprüfung des Schlüsselskripts schlägt fehl	Debug-Print im Tastenkombinations-Handler einfügen, um zu bestätigen, dass er feuert

Der systematische Diagnose-Workflow

Bevor du anfängst, einzelne Config-Dateien zu bearbeiten, arbeite eine strukturierte Checkliste durch, die das Problem auf eine einzelne Komponente eingrenzt. Dieser Prozess dauert fünf Minuten und spart Stunden an zufälligem Ausprobieren.

Schritt 1 — Server-Konsole. Öffne die Server-Konsole, indem du im Spiel F8 drückst oder dein Server-Terminal aufrufst. Filtere Zeilen, die den Ressourcennamen enthalten, der mit dem fehlerhaften Fahrzeug verbunden ist. Achte besonders auf:

• Can't find resource vehicles.meta — der Pfad in fxmanifest.lua zeigt auf eine Datei, die nicht existiert. Überprüfe die Ordnerstruktur: Befindet sich data/vehicles.meta tatsächlich an diesem Pfad relativ zum Ressourcen-Root?
• SCRIPT ERROR: @vehicleshop/server.lua:42: attempt to index a nil value — ein Config-Tabellenschlüssel ist nil, meist weil der Fahrzeugeintrag einen Feldnamen verwendet, den das Skript nicht erkennt. Vergleiche die Feldnamen deines Fahrzeugeintrags mit den erwarteten Schlüsseln des Skripts.
• Warning: resource [customcars] restarted too many times — die Ressource hat einen Laufzeitfehler, der sie beim Laden abstürzen lässt, und FiveMs Auto-Restart greift, bis das Restart-Limit erschöpft ist. Öffne die Ressource in einem Code-Editor und prüfe auf Lua-Syntaxfehler.
• Error parsing vehicles.meta — das XML ist fehlerhaft. Ein fehlendes schließendes Tag oder ein nicht-maskiertes Kaufmanns-Und in einem Fahrzeug-Anzeigenamen zerstört den gesamten Meta-Datei-Parser. Validiere mit einem beliebigen XML-Linter.

Schritt 2 — Resource Monitor. Gib in der Server-Konsole resmon 1 ein, um den clientseitigen Resource Monitor zu öffnen. Finde die Fahrzeugressource in der Liste und überprüfe ihren Status. Ein grüner Status ohne ausgelöste Events bedeutet, dass die Ressource sauber geladen wurde, aber kein Skript sie aufruft — das Problem liegt in einer anderen Ressource. Ein roter Status mit Restart-Schleifen bedeutet, dass die Ressource beim Laden abstürzt. Ein orangefarbener Status mit hoher CPU-Auslastung, aber ohne sichtbare Ausgabe, deutet oft auf eine Endlosschleife in einem Client-Skript hin.

Schritt 3 — Überprüfe die fxmanifest.lua. Diese fünf Zeilen umfassende Prüfung findet mehr Probleme als jeder andere einzelne Schritt:

fx_version 'cerulean'
game 'gta5'

files {
    'data/vehicles.meta',
    'data/carvariations.meta',
    'data/handling.meta',
}

data_file 'VEHICLE_METADATA_FILE' 'data/vehicles.meta'
data_file 'CARCOLS_FILE' 'data/carvariations.meta'
data_file 'HANDLING_FILE' 'data/handling.meta'

Jede Addon-Fahrzeugressource muss jede Meta-Datei in der files-Tabelle deklarieren und über die entsprechende data_file-Direktive registrieren. Der Direktiventyp muss exakt übereinstimmen: VEHICLE_METADATA_FILE nicht VEHICLE_META_FILE, CARCOLS_FILE nicht CARVARIATIONS_FILE. Der Dateipfad ist relativ zum Ressourcen-Root-Ordner. Eine falsch geschriebene oder fehlende Direktive ist die mit Abstand häufigste Ursache.

Schritt 4 — Die Variable isolieren. Stoppe jede fahrzeugbezogene Ressource außer der, die fehlschlägt. Verwende ensure customcars (nicht start), um deine Zielressource sauber zu laden, nachdem alles andere heruntergefahren ist. Spawne das Fahrzeug per Chat-Befehl — /car modelName mit vMenu oder Lambda Menu funktioniert unabhängig von der Shop-Konfiguration. Wenn das Fahrzeug funktioniert, während alles andere gestoppt ist, überschreibt eine konfligierende Ressource deine Handling-Daten oder Modellregistrierung. Aktiviere Ressourcen nacheinander (ensure resourceName), teste das Fahrzeug nach jeder, bis der Fehler wieder auftritt. Die zuletzt aktivierte Ressource ist der Konflikt.

Schritt 5 — Server-Client-Event-Fluss prüfen. Viele Fehler, die wie Fahrzeug-Bugs aussehen, sind tatsächlich Event-Kommunikationsfehler. Ein Fahrzeug-Shop-Skript ruft TriggerServerEvent('esx_vehicleshop:buyVehicle') auf, aber das Schlüsselskript lauscht auf esx_vehicleshop:server:buyVehicle. Die Event-Namen stimmen nicht überein, also feuert der Callback nie und der Schlüssel wird nie zugewiesen. Füge eine print()- oder Citizen.Trace()-Anweisung am Anfang jedes Event-Handlers in der Kette ein und beobachte die Server-Konsole, um zu sehen, welches Glied das Event fallen lässt.

Framework-spezifisches Fahrzeug-Debugging

Unterschiedliche Frameworks scheitern auf unterschiedliche Weise, weil sie Fahrzeugpersistenz, Shops und Besitzverhältnisse über inkompatible Architekturen handhaben. Zu wissen, welche Datenbanktabellen und Config-Dateien dein Framework verwendet, ist der Unterschied zwischen einem Fünf-Minuten-Fix und einer fünfstündigen Irrfahrt.

ESX Legacy und ESX 1.x

ESX-Fahrzeugshops (esx_vehicleshop) speichern Händler-Fahrzeugdefinitionen in Config.DealerVehicles innerhalb von esx_vehicleshop/config.lua. Jeder Eintrag verknüpft einen Modellnamen mit einem Preis. Das Server-Skript liest diese Tabelle beim Start und befüllt die Shop-UI.

Fahrzeug erscheint nicht im Shop. ESX gleicht das model-Feld case-sensitiv gegen GetDisplayNameFromVehicleModel() ab. Wenn dein vehicles.meta <modelName>asbo</modelName> deklariert und deine Shop-Config {model = 'ASBO', price = 25000} enthält, erscheint das Modell nicht, weil GTA den Anzeigenamen anders normalisiert als deine Groß-/Kleinschreibung. Teste immer mit GetDisplayNameFromVehicleModel(GetHashKey('asbo')) in einem clientseitigen Print, um zu sehen, was ESX tatsächlich erhält.

Fahrzeug spawnt ohne Kennzeichen. esx_vehicleshop ruft einen Server-Callback auf, der owned_vehicles abfragt, um ein eindeutiges Kennzeichen zu generieren. Wenn die owned_vehicles-Tabelle nicht existiert oder einen anderen Spaltennamen verwendet als das Skript erwartet (ältere ESX-Versionen verwendeten plate, neuere verwenden manchmal plate als String, aber die Migration hat den Spaltentyp geändert), gibt die Abfrage nil zurück und das Fahrzeug spawnt mit einem leeren Kennzeichen — was das Schlüsselsystem daran hindert, das Fahrzeug jemals einem Besitzer zuzuordnen.

-- Kennzeichen-Spalten-Probleme diagnostizieren
SELECT plate, owner, state FROM owned_vehicles WHERE owner = 'char1:abc123' LIMIT 3;

Garage holt Fahrzeuge nicht zurück. ESX-Garagen-Skripte filtern nach einer Status-Spalte. Ältere ESX-Datenbank-Schemata verwendeten state mit Werten wie 'stored' oder 'impounded'. Neuere Schemata verwenden manchmal eine boolesche stored-Spalte. Wenn das Skript WHERE stored = 1 abfragt, deine Tabelle aber state = 'stored' hat, gibt die Abfrage null Zeilen zurück und die Garage erscheint leer, obwohl die Fahrzeuge in der Datenbank existieren.

QBCore

QBCore zentralisiert Fahrzeugdefinitionen in qb-core/shared/vehicles.lua — einer Lua-Tabelle, die jedes auf dem Server verfügbare Fahrzeug enthält. Jeder Eintrag benötigt die Felder brand, model, price, category und shop.

Fahrzeug spawnt unsichtbar. Der häufigste QBCore-Fahrzeugfehler. qb-vehicleshop übergibt den Modell-Hash von vehicles.lua an CreateVehicle. Wenn der Eintrag des model-Feldes nicht exakt mit modelName in der vehicles.meta der Fahrzeugressource übereinstimmt, gibt die Hash-Funktion null zurück und GTA greift auf eine Standard-Entität zurück — oft eine unsichtbare Fußgänger-Kollisionsbox. Kopiere den Modellnamen immer per Copy-Paste von vehicles.meta nach vehicles.lua, um Tippfehler zu vermeiden.

Falsche Kategorie oder keine Kategorie im Shop. QBCore-Shops filtern Fahrzeuge nach dem category-Feld in vehicles.lua gegen das categories-Array des Shops in qb-vehicleshop/config.lua. Wenn du category = 'custom' in vehicles.lua setzt, aber vergisst, 'custom' zur Liste der erlaubten Kategorien des Shops hinzuzufügen, ist das Fahrzeug für Spieler, die die Shop-UI durchstöbern, völlig unsichtbar — spawnt aber problemlos über Admin-Befehle.

-- qb-vehicleshop/config.lua
Config.Shops = {
    ['pdm'] = {
        label = 'Premium Deluxe Motorsport',
        categories = {'sports', 'compacts', 'muscle', 'custom'}, -- 'custom' muss hier stehen
        blip = vector3(-33.0, -1102.0, 26.0),
    }
}

Schlüssel werden nach dem Kauf nicht zugewiesen. qb-vehiclekeys lauscht auf ein bestimmtes Server-Event vom Fahrzeug-Shop-Skript — typischerweise qb-vehicleshop:server:buyVehicle. Wenn du ein Drittanbieter-Fahrzeug-Shop (wie okokVehicleshop oder carmodern-vehicleshop) verwendest, das einen anderen Event-Namen feuert, erhält das Schlüsselskript nie die Kaufbenachrichtigung und der Spieler verlässt den Händler mit einem nicht zugewiesenen Auto.

QBox (ox_core)

QBox verwendet ox_inventory zur Shop-Verwaltung und ein völlig anderes Datenbankschema als ESX und QBCore.

Fahrzeug erscheint nicht im Shop. QBox-Fahrzeugdefinitionen befinden sich in ox_inventory/data/vehicles.lua, nicht in der Fahrzeugressource selbst und nicht in einer Framework-weiten Config. Jeder Eintrag verknüpft model (den exakten modelName aus vehicles.meta) mit name, brand, price und category. Fehlende Einträge hier bedeuten, dass das Fahrzeug in keinem Shop erscheinen kann, unabhängig vom Ressourcenstatus.

Shop-Registrierung. QBox-Shops werden in ox_inventory/data/shops.lua mit einem categories-Array definiert. Das Hinzufügen einer benutzerdefinierten Fahrzeugkategorie erfordert das Aktualisieren beider Dateien: Füge den Fahrzeugeintrag zu vehicles.lua hinzu und füge dann den category-String dieses Fahrzeugs zum categories-Array jedes Shops hinzu, der es verkaufen soll. Das Überspringen des shops.lua-Updates ist der häufigste QBox-Fahrzeug-Shop-Fehler.

Datenbankschema-Unterschiede. QBox speichert Fahrzeuge in einer Tabelle namens vehicles (nicht player_vehicles oder owned_vehicles). Das Spaltenlayout umfasst plate, model, garage, props, owner und stored — aber die props-Spalte speichert JSON-serialisierte Fahrzeug-Mod-Daten, was ein anderes Format ist als die kommagetrennten Mod-Werte von ESX. Für ESX geschriebene Garagen-Skripte scheitern stillschweigend am QBox-Schema, weil die Spaltennamen und Datenformate nicht übereinstimmen.

-- QBox-Fahrzeug-Schema-Prüfung
SELECT column_name, data_type FROM information_schema.columns 
WHERE table_name = 'vehicles' ORDER BY ordinal_position;

Fahrzeug-Skript-Fehler verhindern

Die meisten Fahrzeugfehler sind mit einer Staging-Umgebung und etwas Disziplin beim Konfigurationsmanagement vermeidbar.

Betreibe einen Staging-Server. Richte eine lokale oder separate FiveM-Instanz mit denselben Ressourcen, demselben Datenbankschema und derselben Framework-Version wie die Produktion ein. txAdmin macht dies trivial — führe txAdmin deploy auf einem Ersatzrechner oder einer VM aus, klone deine Server-Konfiguration und du hast eine identische Testumgebung. Jede neue Fahrzeugressource wird zuerst auf Staging getestet: spawnen, fahren, im Mod-Shop anpassen, in einer Garage parken, abholen und prüfen, dass alle angehängten Skripte (Treibstoff, Schlüssel, Schaden, Tacho) korrekt funktionieren. Die 10 Minuten für Staging-Tests verhindern stundenlange Spielerbeschwerden und Serverabstürze in der Produktion.

Halte ein bekannt-gutes Konfigurations-Backup bereit. Bevor du eine Fahrzeugressource hinzufügst oder änderst, committe deinen resources/-Ordner in die Versionskontrolle oder erstelle ein datiertes Backup. Wenn eine neue Ergänzung Dinge kaputtmacht, diff-gegen die aktuelle Konfiguration mit dem bekannt-guten Zustand. Ein dreizeiliges diff gegen server.cfg oder vehicles.lua findet die brechende Änderung in Sekunden statt der Stunden, die es dauert, jeden Config-Eintrag manuell zu vergleichen.

Überwache Addon-Fahrzeug-Limits. GTA V hat ein Streaming-Speicherbudget von etwa 256 MB für Fahrzeugmodelle und Texturen. Die .yft- und .ytd-Dateien jedes Addon-Fahrzeugs verbrauchen einen Teil dieses Budgets. Verwende den clientseitigen Resource Monitor (resmon 1 in der F8-Konsole), um die Streaming-Speichernutzung auf einem Staging-Server mit der maximal erwarteten Spielerzahl zu prüfen. Wenn du das Budget überschreitest, werden die zuletzt gestreamten Fahrzeuge unsichtbar oder laden gar nicht. Die Lösung ist entweder das Reduzieren von Texturauflösungen, das Entfernen ungenutzter Lackierungen oder das Verteilen von Fahrzeugen auf priorisierte Ressourcengruppen, die bei Bedarf gestreamt werden.

Validiere Meta-Dateien vor Server-Neustarts. Ein einfaches Lua-Skript, das als Teil deines Ressourcen-Deployments ausgeführt wird, kann alle drei Meta-Dateien parsen und Querverweise überprüfen:

• handlingName in handling.meta muss mit handlingId in vehicles.meta übereinstimmen
• Jedes <Item> in carvariations.meta muss einen entsprechenden modelName in vehicles.meta haben
• Jeder <modelName> in vehicles.meta muss über alle aktiven Fahrzeugressourcen hinweg eindeutig sein

Die Automatisierung dieser Prüfungen fängt XML-Referenzfehler ab, bevor sie die Spieler erreichen.

Teste zuerst mit Standard-Ressourcen. Wenn ein Fahrzeug-Skript kaputtgeht, entferne vorübergehend alle benutzerdefinierten Ressourcen außer der Fahrzeugressource selbst und dem Framework-Kern. Spawne das Fahrzeug und teste die fehlerhafte Funktion. Wenn es in der Minimalkonfiguration funktioniert, liegt der Fehler in einer Interaktion zwischen Ressourcen — nicht in der Fahrzeugdefinition selbst. Dies grenzt die Debugging-Oberfläche von potenziell hunderten Skripten auf eine handhabbare Teilmenge ein.

Wichtige Debugging-Tools und -Befehle

Mehrere eingebaute und von der Community gepflegte Tools machen das Fahrzeug-Debugging deutlich schneller als das Jagen von Fehlermeldungen durch Logdateien.

vMenu ist das zuverlässigste Fahrzeug-Spawn-Tool für die Diagnose. Der Befehl /car modelName spawnt jedes registrierte Fahrzeugmodell, unabhängig von Shop-Konfiguration, Datenbankzustand oder Framework-Version. Wenn ein Fahrzeug über vMenu spawnt, aber nicht über einen Fahrzeug-Shop, ist die Shop-Konfiguration das Problem. Wenn es auch über vMenu nicht spawnt, ist die Ressource selbst kaputt. Dieser einzelne Test eliminiert die Hälfte der möglichen Ursachen in Sekunden.

Lambda Menu (/lambda) bietet einen Fahrzeug-Debug-Tab, der den Modell-Hash des aktuell fokussierten Fahrzeugs, den Anzeigenamen, das Textur-Set, die Lackierungsanzahl und die Verfügbarkeit von Tuning-Mods anzeigt. Bei der Diagnose unsichtbarer Modelle wechsle zum Fahrzeug-Debug-Tab und prüfe, ob der Modell-Hash null ist (Modell nicht geladen) oder gültig, aber das Rendering fehlschlägt (fehlende Texturen). Die Lackierungsanzahl bestätigt, ob carvariations.meta korrekt angewendet wird.

Wichtige Konsolen-Variablen steuern das Streaming- und Debug-Verhalten:

• set sv_enforcegamebuild 2802 — stellt sicher, dass alle Clients auf demselben Game-Build sind, um Modell-Inkompatibilitäten zwischen verschiedenen GTA-V-Versionen zu verhindern.
• set sv_scriptHookAllowed 1 — erlaubt Debug-Skripte und Script Hooks auf dem Server, nützlich für erweiterte Diagnose-Tools.
• set onesync_enableInfinity 0 — deaktiviert OneSync-Entity-Limit-Schutz (nur auf Staging), um zu testen, ob ein Streaming-Limit unsichtbare Fahrzeuge verursacht.

Chat-Befehle für schnelle In-Game-Diagnose:

• /car [model] — vMenu-Spawn-Shortcut, der meistgenutzte Debug-Befehl
• /dv oder /deletevehicle — entfernt das Fahrzeug unter deinem Fadenkreuz
• /fix — repariert das Fahrzeug und gibt Motor-/Karosserie-Gesundheitswerte in der Konsole aus
• /tpm — teleportiert deinen Ped auf den Fahrersitz des nächstgelegenen Fahrzeugs
• /givekey [plate] — stellt einen Fahrzeugschlüssel für deinen Charakter aus (skriptabhängig)
• resmon 1 — öffnet den clientseitigen Resource Monitor, um Streaming-Speicher und Skript-CPU-Auslastung zu prüfen

Datenbank-Verifikationsabfragen. Für Garagen- und Schlüsselsystem-Fehler führe diese direkt auf deiner Datenbank aus:

-- ESX/QBCore: Gespeicherte Fahrzeuge eines Spielers prüfen
SELECT plate, vehicle, garage, stored FROM player_vehicles 
WHERE citizenid = 'ABC12345' ORDER BY plate;

-- Schema gegen das prüfen, was das Garagen-Skript INSERTed
DESCRIBE player_vehicles;

-- Verwaiste Fahrzeuge finden, die ohne Garagennamen gespeichert sind
SELECT plate, vehicle FROM player_vehicles 
WHERE garage IS NULL OR garage = '';

-- QBox: Fahrzeugspeicher prüfen
SELECT plate, model, garage, stored, props FROM vehicles 
WHERE owner = 'char1:abc123';

Zusammenfassung

Fahrzeug-Skript-Debugging besteht weniger aus dem Auswendiglernen einzelner Fixes als vielmehr aus dem Verständnis des Datenflusses durch die Architektur deines Servers. Das Muster ist immer dasselbe: Eine Ressource streamt die Modelldateien → das Framework registriert das Modell in seiner Shop-Konfiguration → das Shop-Skript spawnt die Entität und feuert ein Besitz-Event → sekundäre Skripte hängen Verhaltensweisen wie Schlüssel, Treibstoffverfolgung und Schadenspersistenz an → das Garagen-Skript schreibt den Entitätszustand in die Datenbank.

Ein Bruch an irgendeinem Glied dieser Kette erzeugt einen für den Spieler sichtbaren Fehler. Autos, die nicht spawnen, deuten auf den Modell-Stream-Schritt hin. Autos, die spawnen, aber nicht in Shops erscheinen, deuten auf den Framework-Registrierungsschritt hin. Autos, die in Shops erscheinen, aber nicht verriegelt werden können, deuten auf den Event-Bindungsschritt hin. Autos, die in Garagen gespeichert, aber mit falschen Schadenswerten abgeholt werden, deuten auf den Datenbank-Persistenzschritt hin.

Folge den Daten vom Modell zur Datenbank. Der Fehler tritt beim ersten Schritt auf, an dem die Daten nicht durchkommen.