Category hub
Compare police, mechanic, drug, civilian, and economy systems in the main jobs hub before you commit to a single resource.
Open job scriptsStarke Job- und Roleplay-Setups hängen nie nur an einem Script. Über die folgenden Hubs vergleichst du installierbare Produkte, Bundles und den passenden Framework-Fit vor dem Kauf.
Category hub
Compare police, mechanic, drug, civilian, and economy systems in the main jobs hub before you commit to a single resource.
Open job scriptsFramework hub
Move into the QBCore landing page to compare verified scripts, framework fit, and install-ready products built for modern FiveM servers.
Open QBCore hubPremium catalog
Move from research into the main shop to compare real products, framework labels, screenshots, and production-ready quality signals.
Open premium shopFahrzeug-Skripte tragen zur Hälfte des Rollenspielerlebnisses bei – Spawning, Individualisierung, Treibstoff, Schlüssel, Garagen. Wenn irgendein Teil ausfällt, merkt es jeder Spieler. Dieser Leitfaden führt durch die 12 häufigsten Fahrzeugskript-Fehler bei ESX, QBCore und QBox mit Diagnoseschritten und funktionierenden Codebeispielen.
Wirtschaftsskripte sind das finanzielle Rückgrat jedes Rollenspiel-Servers. Wenn das Geld bricht, zahlen Jobs nicht mehr aus, Geschäfte verkaufen nichts mehr und Spieler verlieren innerhalb von Minuten das Vertrauen. Dieser Leitfaden behandelt die 12 kritischsten Wirtschaftsfehler auf ESX, QBCore und QBox – Duplikations-Exploits, Bankfehler, Ladenpreise und Inflationsmanagement – mit Diagnoseschritten und funktionierendem Code.
Wohnungsskripte gehören zu den komplexesten Ressourcen auf einem FiveM-Server – Innenräume, Möbel, Schlüssel, Lagerung, Mitbewohner und Immobilienwirtschaft in einem System. Dieser Leitfaden führt durch die 12 häufigsten Wohnungsfehler auf ESX, QBCore und QBox mit Diagnoseschritten und funktionierendem Code.
Drogen-Skripte kombinieren Inventarsysteme, Verarbeitungsschleifen, NPC-Interaktionen, Polizeialarm und Wirtschaftsintegration – mehr bewegliche Teile bedeuten mehr Fehlerquellen. Dieser Leitfaden behandelt die 12 häufigsten Fehler in ESX, QBCore und QBox mit Diagnoseschritten und funktionierendem Code.

Drogen-Skripte gehören zu den komplexesten Ressourcen auf jedem FiveM-Server — und wenn sie kaputtgehen, breiten sich die Folgen durch jedes System aus, mit dem deine Spieler interagieren. Verarbeitungsschleifen, Grow-House-Timer, NPC-Drogenhändler, Polizei-Dispatch-Integration, Cooldown-Systeme, Skill-Bäume, Crafting-Tische, Gebietskontrolle — eine Drogen-Ökonomie berührt mehr Subsysteme als jede andere Mod-Kategorie. Jede Ebene kann unabhängig ausfallen, und die Fehler sehen aus Spielersicht oft identisch aus: Es passiert nichts. Sie drücken E am Verarbeitungstisch und nichts erscheint. Sie gehen zum Dealer und kein Menü öffnet sich. Sie überprüfen ihre Einnahmen nach einem Neustart und das Geld ist weg.
Was Drogen-Skripte einzigartig schwierig zu debuggen macht, ist die Kettenreaktion, wenn eine Komponente ausfällt. Ein Item, das nicht in shared/items.lua registriert ist, bedeutet, dass das Verarbeitungs-Event nie feuert, was bedeutet, dass der Crafting-Tisch keine Ausgabe produziert, was bedeutet, dass der Dealer nichts zu verkaufen hat, was bedeutet, dass die gesamte Wirtschaft zusammenbricht — und der Spieler sieht nur das letzte Glied dieser Kette. Die Server-Konsole zeigt vielleicht einen einzelnen Fehler, der drei Ressourcen tief vergraben ist, oder schlimmer, sie zeigt gar nichts, weil das Event ohne Error-Handler stillschweigend abbricht. Wenn du das sichtbare Symptom behebst, ohne die Kette bis zur Ursache zurückzuverfolgen, wirst du denselben Bug an fünf verschiedenen Orten jagen, bevor du verstehst, was tatsächlich kaputtgegangen ist.
Bevor du eine einzige Config-Datei anfasst, verstehe den Datenfluss. In jedem großen Framework — ESX, QBCore, QBox — folgt ein Drogen-Skript derselben Pipeline: Ressource sammeln → zum Verarbeitungsort transportieren → zu Produkt verarbeiten → zum Dealer transportieren → für Geld verkaufen. Bei jedem Schritt liest das Skript ein Item aus dem Inventar des Spielers, prüft eine Datenbanktabelle auf Status (Wachstumsstadium, Cooldown-Timer, Skill-Level), feuert ein Server-Event, wartet auf einen Callback und schreibt das Ergebnis zurück. Wenn du weißt, welches Glied dieser Pipeline ausfällt, ist der Fix normalerweise eine Zeile. Wenn nicht, verbringst du Stunden damit, Config-Werte zu ändern, die nie das Problem waren.
Dieser Leitfaden behandelt die 12 häufigsten Drogen-Skript-Fehler in ESX, QBCore und QBox. Jeder Abschnitt identifiziert die tatsächliche Ursache — keine allgemeinen Ratschläge — und enthält funktionierenden Diagnosecode, um das Problem zu verifizieren, bevor du etwas anfasst. Verwende diese Diagnosen, um die fehlerhafte Komponente zu isolieren, und wende dann den framework-spezifischen Fix an, der zu deinem Setup passt.

Ordne das Symptom der wahrscheinlichsten Ursache zu, bevor du in die einzelnen Abschnitte eintauchst. Die folgende Tabelle ordnet jeden Fehler seiner wahrscheinlichen Wurzel und dem einzigen Diagnose-Check zu, der ihn bestätigt — führe diese in Reihenfolge aus, um keine Zeit mit Konfigurationsänderungen zu verschwenden, die nichts reparieren.
| Symptom | Wahrscheinlichste Ursache | Erster Prüfschritt |
|---|---|---|
| Verarbeitungsstation zeigt keine Aufforderung | Item nicht in Shared Items oder Zone nicht registriert | Item-Namen im Verarbeitungs-Trigger ausgeben; gegen shared/items.lua Schlüssel für Schlüssel vergleichen |
| Drogengeld verschwindet nach Neustart | Geld in Speicher geschrieben ohne DB-Persistenz | Server-Konsole auf SQL ERROR nach Verkaufs-Event prüfen; verifizieren, dass players-Tabelle aktualisierte money-Spalte hat |
| Dealer-NPC fehlt am Verkaufsort | Ungültiges Ped-Modell oder Koordinaten innerhalb von Geometrie | Zu Koordinaten teleportieren und a_m_y_business_01 spawnen — wenn beides nicht funktioniert, sind die Koordinaten das Problem |
| Grow-House-Pflanzen setzen bei jedem Neustart zurück | Pflanzenstatus im Speicher gespeichert, nicht in Datenbank | grow_houses-Tabelle abfragen; wenn Zeilen existieren, aber Stadien zurücksetzen, liest die Startlogik aus dem Speicher |
| Bildschirmeffekte werden beim Konsum nicht angewendet | Client-Event blockiert oder von anderem Skript gelöscht | print("EFFECTS FIRING") im Client-Konsum-Handler hinzufügen; wenn es printed, aber kein Effekt erscheint, löscht ein HUD-Skript die Bildschirmeffekte |
| Crafting-Tisch verbraucht Zutaten, keine Ausgabe | Ausgabe-Item nicht registriert oder Zutatenname-Inkonsistenz | Item-Namen direkt aus shared/items.lua kopieren — nicht neu tippen — und verifizieren, dass der Ausgabe-Item-Key existiert |
| Polizei-Dispatch feuert nie | Dispatch-Ressource läuft nicht oder Export-Name falsch | print(exports['cd_dispatch']:AlertMessage) in Server-Konsole ausführen; wenn nil, ist die Dispatch-Ressource nicht gestartet |
| Gewichts-Overrides zerstören Inventar | Doppelte Gewichtsdefinitionen in Skript-Config und Shared Items | Alle lokalen Gewichts-Overrides aus der Drogen-Skript-Config entfernen; Gewichte einmal in den Shared Items des Frameworks definieren |
| Erster Wegpunkt einer Drogenroute schlägt sofort fehl | Nil-Koordinaten durch fehlenden Config-Eintrag | Jede Wegpunkt-Koordinate ausgeben; nil-Werte werden stillschweigend zu (0, 0, 0), was unterirdisch ist |
| Skill-EP sammeln sich nie an | Initiale drug_skills-Zeile nie eingefügt oder DB-Schreibvorgang schlägt still fehl | SELECT * FROM drug_skills WHERE identifier = 'char1:abc123' — wenn leer, ist der Spieler beigetreten, bevor die Ressource vollständig gestartet war |
Der häufigste Fehler, den Server-Betreiber beim Debuggen von Drogen-Skripten machen, ist, mit .cfg-Dateien zu beginnen. Wenn ein Drogen-Skript in die Datenbank schreibt, ist die Datenbank deine einzige Quelle der Wahrheit — sie sagt dir, ob das Skript jemals lief, was es geschrieben hat und ob der Schreibvorgang erfolgreich war. Bevor du eine einzige Zeile änderst:
Prüfe, ob die Tabellen existieren. Führe SHOW TABLES LIKE '%drug%' oder %grow% in deiner Datenbank aus. Wenn die erwarteten Tabellen nicht existieren, hat die Ressource nie ihre SQL-Migration ausgeführt. Starte die Ressource neu und beobachte die Konsole auf Migrationsfehler.
Prüfe auf aktuelle Zeilen. SELECT * FROM drug_sales ORDER BY created_at DESC LIMIT 10. Eine leere Tabelle bedeutet, dass das Verkaufs-Event nie feuert. Zeilen mit Zeitstempeln von gestern, aber nichts von heute, bedeuten, dass kürzlich etwas kaputtgegangen ist — prüfe, was sich geändert hat.
Prüfe auf Fehlermuster. SELECT identifier, COUNT(*) as failures FROM drug_log WHERE success = 0 GROUP BY identifier ORDER BY failures DESC. Dies identifiziert, ob das Problem alle Spieler oder nur eine bestimmte Untergruppe betrifft.
Prüfe auf Null-Spalten. SELECT * FROM drug_skills WHERE xp IS NULL. Eine Null-XP-Spalte bedeutet, dass der initiale Insert lief, aber die Update-Abfrage nie ausgeführt wurde — meist ein Spaltennamen-Inkonsistenz in der SQL-Abfrage des Skripts.
Datenbankdiagnosen dauern fünf Minuten und sagen dir mehr als eine Stunde Raten bei Config-Werten.
Jede Drogenoperation beginnt mit einem Item im Inventar des Spielers. Wenn dieses Item nicht in der Shared-Items-Registrierung deines Frameworks ist, weiß das Framework nicht, dass es existiert — das Verarbeitungs-Event kann nicht feuern, weil es nichts aus dem Inventar zu entfernen gibt. Die Diagnosekette:
print("Processing item: " .. itemName) am Anfang des Verarbeitungs-Event-Handlers hinzu.shared/items.lua und suche nach diesem String. Groß-/Kleinschreibung ist wichtig. Unterstriche sind wichtig. cocaine_brick und Cocaine_Brick sind unterschiedliche Items.server.cfg. Die Drogen-Ressource muss nach deiner Inventar-Ressource starten. Wenn start qb-inventory nach start qb-drugs kommt, initialisiert sich das Drogen-Skript, bevor die Items registriert sind, und die Events scheitern stillschweigend.ox_inventory/data/items.lua mit einem weight-Feld registriert sein. Ein fehlendes Gewichtsfeld wirft keinen Fehler — es setzt das Gewicht stillschweigend auf 0, was dazu führen kann, dass das Inventarsystem das Item ablehnt, wenn das Drogen-Skript versucht, es hinzuzufügen.Koordinaten sind nach Items der zweithäufigste Fehlerpunkt. Drogen-Skripte definieren Verarbeitungszonen, Dealer-Positionen, Grow-House-Interieurs und Routen-Wegpunkte als Vektor-Koordinaten — und jede einzelne davon, die falsch ist, unterbricht die Kette.
Teleportiere zu jeder Koordinate mit vMenu oder dem Resource Monitor. Wenn du durch die Map fällst, ist die Z-Koordinate falsch. Wenn du in eine Wand clippst, sind die X/Y-Koordinaten daneben. Wenn du auf einem Dach landest, aber der Verarbeitungstisch auf dem Boden ist, wurde die Koordinate von zwei verschiedenen Orten genommen.
Teste Zonen isoliert. ox_target- und qb-target-Zonen können ohne Fehler nicht registriert werden, wenn der Radius zu klein ist, der Debug-Modus aus ist oder die Zone sich mit der Zone einer anderen Ressource überschneidet. Erhöhe den Zonenradius vorübergehend auf 5,0 zum Testen. Wenn die Interaktionsaufforderung bei 5,0 erscheint, aber nicht beim Standard von 1,5, ist das Zonenzentrum leicht gegenüber dem Prop verschoben.
Prüfe auf MLO-Konflikte. Wenn du kürzlich ein MLO (Map-Mod) installiert oder aktualisiert hast, können sich Interior-Koordinaten verschoben haben. Der Laborequipment-Prop hat sich bewegt, aber die Interaktionszone blieb an der alten Koordinate. Verwende den Resource Monitor, um deine aktuelle Position anzuzeigen, stelle dich direkt vor den Prop und vergleiche mit der Zonen-Config.
Drogen-Skripte kommunizieren über FiveMs Event-System. Eine Verarbeitungsaktion triggert ein Server-Event, das Server-Event liest die Datenbank und ein Callback triggert ein Client-Event, um das Ergebnis anzuzeigen. Wenn irgendein Event in dieser Kette fehlschlägt, bricht die Kette stillschweigend ab.
Prüfe, ob der Event-Name existiert. Durchsuche deine Drogen-Ressource nach RegisterNetEvent("drugs:process") oder Äquivalent. Wenn das Event registriert ist, aber der auslösende Code TriggerEvent (Client-zu-Client) anstelle von TriggerServerEvent (Client-zu-Server) verwendet, empfängt der Server es nie.
Prüfe den Event-Handler auf frühe Ausstiege. Suche nach if not xPlayer then return end-Mustern am Anfang von Event-Handlern. Wenn das Spieler-Objekt nil ist — häufig nach Wiederverbindung — beendet sich das Event stillschweigend ohne Logging.
Füge temporäre Debug-Prints in jeder Phase hinzu. Im Verarbeitungs-Server-Event füge hinzu:
print("[DRUG DEBUG] Processing started for " .. src)
print("[DRUG DEBUG] Input item: " .. inputItem .. ", count: " .. count)
print("[DRUG DEBUG] Output item: " .. outputItem)
Beobachte die Server-Konsole während eines Verarbeitungsversuchs. Wenn du den ersten Print siehst, aber nicht den zweiten, hat das Event Müll-Parameter erhalten. Wenn du alle drei siehst, aber kein Ausgabe-Item erscheint, schlägt die AddItem-Funktion oder ihr Äquivalent fehl.
ESX-Server betreiben typischerweise esx_drugs oder eine benutzerdefinierte Drogen-Ressource, die auf ESX Legacy oder ESX 1.2+ aufbaut. Die Integrationspunkte, die du prüfen musst:
Inventar-Integration. ESX verwendet xPlayer.getInventoryItem() und xPlayer.addInventoryItem(). Wenn dein Drogen-Skript diese aufruft, aber die Methoden nil sind, ist der ESX-Export noch nicht initialisiert — die Drogen-Ressource startete vor es_extended. Korrigiere die Ladereihenfolge in server.cfg:
ensure es_extended
ensure mysql-async # wenn ESX Legacy verwendet wird
ensure oxmysql # wenn ESX 1.2+ verwendet wird
ensure ox_inventory # oder qb-inventory bei Cross-Framework
ensure esx_drugs # muss NACH dem Inventar kommen
Status-Effekte. ESX verwendet esx_status für Drogeneffekte wie Rüstungs-Boost, Gesundheitsschaden oder Geschwindigkeitsmodifikation. Wenn Drogeneffekte nicht angewendet werden, prüfe, ob dein Drogen-Skript die korrekte Status-API verwendet. Legacy ESX ruft xPlayer.setStatus() auf; ESX 1.2+ ruft exports['esx_status']:set() auf. Der falsche Aufruf erzeugt keinen Fehler — der Status ändert sich einfach nicht.
Geld-Persistenz. Bei ESX Legacy aktualisiert xPlayer.addMoney() den In-Memory-Wert, schreibt aber NICHT in die Datenbank, es sei denn, es folgt MySQL.Async.execute('UPDATE users SET money = @money WHERE identifier = @identifier', ...). Viele ältere Drogen-Skripte lassen diese Folgeabfrage weg, wodurch Geld beim Neustart verschwindet. Bei ESX 1.2+ mit oxmysql schreibt addMoney() automatisch — aber nur, wenn oxmysql läuft. Prüfe txAdmin oder deine Server-Konsole, um zu bestätigen, dass der MySQL-Treiber vorhanden ist.
QBCore-Server verwenden häufig qb-drugs, qb-processing, qb-drugsales oder qb-weed aus dem Standard-QBCore-Ressourcenpaket. Das QBCore-Integrationsmuster unterscheidet sich von ESX in drei entscheidenden Punkten:
Spieler-Funktionsnamen. QBCore verwendet Player.Functions.AddItem() und Player.Functions.RemoveItem() — beachte das große F und die .Functions-Eigenschaft. Wenn dein Drogen-Skript xPlayer.addInventoryItem() aufruft, ist das die ESX-API und gibt auf QBCore nil zurück. Das Skript muss das Framework erkennen und die korrekte API verwenden, oder du betreibst eine Cross-Framework-Ressource mit eigener Bridge.
Shared-Items-Format. QBCores shared/items.lua stellt Items als Tabellenschlüssel innerhalb von QBShared.Items bereit. Jedes Item benötigt die Felder name, label, weight, type, unique, useable, shouldClose und description. Das useable-Feld ist besonders wichtig: Wenn useable = false, feuert das Konsum-Event nicht, wenn der Spieler das Item aus dem Inventar verwendet. Setze useable = true für jedes Drogen-Item, das Spieler konsumieren sollen.
Callback-System. QBCore verwendet QBCore.Functions.CreateCallback / QBCore.Functions.TriggerCallback für Datenbankabfragen. Wenn ein Drogen-Verarbeitungs-Event einen Callback verwendet, der nie zurückkehrt — weil die Datenbankabfrage innerhalb des Callbacks fehlgeschlagen ist — hängt der Client unbegrenzt wartend. Füge einen Timeout-Fallback zu jedem callback-basierten Datenbankaufruf hinzu:
QBCore.Functions.TriggerCallback('qb-drugs:server:getProcessingCooldown', function(result)
if result then
-- verarbeiten
else
print("[DRUGS] Callback returned nil — allowing processing as fallback")
-- Verarbeitung erlauben oder Fehler dem Spieler anzeigen
end
end, source)
Geld-API. Player.Functions.AddMoney('cash', amount) schreibt automatisch über QBCores eingebaute MySQL-Middleware in die players-Tabelle. Wenn Drogengeld verschwindet, prüfe, ob die money-Spalte in der players-Tabelle den Datentyp akzeptiert, den du schreibst. QBCore speichert Geld als JSON ({"cash": 5000, "bank": 12000}) — wenn dein Drogen-Skript eine einfache Ganzzahl schreibt, lehnt der JSON-Parser sie ab und das Update schlägt stillschweigend fehl.
QBox (der QBCore-Nachfolger) verwendet ox_inventory nativ und nicht QBCores Inventar-Bridge. Dies ändert den Fehlerbehebungsablauf erheblich:
Keine Shared-Items-Datei zum Prüfen. ox_inventory registriert Items in ox_inventory/data/items.lua über die Items-Tabelle. Der Item-Key ist derselbe String, den Skripte beim Aufruf von exports.ox_inventory:AddItem() verwenden. Wenn ein Drogen-Skript exports['ox_inventory']:AddItem(source, 'cocaine_brick', 1) aufruft, aber cocaine_brick nicht in items.lua ist, gibt der Export false zurück, ohne einen Fehler zu loggen. Umschließe jeden AddItem/RemoveItem-Aufruf mit einer Prüfung:
local added = exports.ox_inventory:AddItem(source, 'cocaine_brick', 1)
if not added then
print("[DRUGS ERROR] Failed to add cocaine_brick to player " .. source .. " — item likely not registered")
end
Native ox_target-Integration. QBoxs Drogen-Skripte verwenden typischerweise ox_target direkt, anstatt es zu wrappen. Verarbeitungszonen werden als exports.ox_target:addBoxZone() oder exports.ox_target:addSphereZone() definiert. Wenn die Zone nicht erscheint, prüfe, ob ox_target gestartet ist und ob die Zonendefinition debug = true während des Testens enthält. Eine Debug-aktivierte Zone zeichnet ein farbiges Drahtgitter — wenn du es nicht siehst, ist die Zonenregistrierung stillschweigend fehlgeschlagen.
Gewichts- und Stack-Behandlung. ox_inventory handhabt Gewicht nativ über die Item-Definition. Wenn ein Drogen-Item weight = 100 in items.lua hat, aber dein Drogen-Skript einen weight-Parameter an AddItem übergibt, ignoriert ox_inventory den Parameter und verwendet das registrierte Gewicht. Dies kann Verwirrung stiften, wenn Spieler melden, dass sie erwartete Mengen nicht tragen können — das Item-Gewicht in items.lua ist immer die Quelle der Wahrheit.
Die Ursache Nummer eins für Drogen-Skript-Fehler in allen Frameworks. Der Item-Name in deiner Drogen-Skript-Config, der Item-Name in deiner Shared-Items-Datei und der Item-Name, den das Verarbeitungs-Event erwartet, müssen byte-für-byte identisch sein. cocaine_brick ist nicht cocaine-brick. weed_leaf ist nicht weed_leafs. Ein Bindestrich statt eines Unterstrichs, ein fehlendes „s" oder ein Großbuchstabe an der falschen Stelle bedeutet, dass die Item-Suche nil zurückgibt und die Operation fehlschlägt.
Fix: Tippe Item-Namen niemals von Hand. Öffne deine shared/items.lua oder ox_inventory/data/items.lua, kopiere den exakten Item-Key und füge ihn in deine Drogen-Skript-Config ein. Mache dies für jedes Item in der Verarbeitungskette — Eingabe-Items, Zwischenprodukte und Endprodukte.
Drogen-Skripte hängen von deinem Framework, deinem Inventarsystem, deinem Target-System und oft deinem Dispatch-System ab. Wenn die Drogen-Ressource vor einer ihrer Abhängigkeiten startet, existieren die Exporte und Events, die sie benötigt, noch nicht. FiveM wirft keinen Fehler für undefinierte Exporte, die in Event-Handlern verwendet werden — sie geben einfach nil oder false zurück, wenn sie aufgerufen werden, und das Drogen-Skript scheitert stillschweigend.
Die korrekte Reihenfolge in server.cfg oder txAdmin:
ensure mysql-async # oder oxmysql
ensure es_extended # oder qb-core
ensure esx_status # wenn ESX Health/Drug-Effects verwendet werden
ensure ox_inventory # oder qb-inventory
ensure ox_target # oder qb-target
ensure cd_dispatch # oder deine Dispatch-Ressource
ensure your_drug_resource # muss LETZTES in der Kette sein
Einige Frameworks — insbesondere QBCore mit Berechtigungssystemen — erfordern, dass Spieler spezifische Berechtigungen haben, um Drogen-Events auszulösen. Ein Spieler ohne die qb-drugs:process-Berechtigung kann zum Verarbeitungstisch gehen, die Interaktionsaufforderung sehen, erhält aber „Keine Berechtigung" oder gar nichts, wenn er E drückt. Prüfe:
QBCore.Functions.HasPermission verwendet, entspricht die Spieler-ID dem erwarteten Format (license: vs steam: vs char:)?Verarbeitungszonen, Dealer-Positionen und Grow-House-Interieurs werden als Vektoren in der Drogen-Skript-Config definiert. Eine einzige verschobene Dezimalstelle — vector3(123.45, -678.90, 21.3) statt vector3(123.45, -678.90, 21.03) — platziert die Zone in einem anderen Raum, einer anderen Etage oder innerhalb einer Wand. Drei Prüfungen:
vMenu oder die Koordinatenanzeige in deinem Resource Monitor und kopiere die Werte exakt.42.5 oder -12.75. Ein fehlendes Vorzeichen oder eine gerundete Dezimalstelle platziert die Zone auf der falschen Etage.vector4(x, y, z, heading) für Dealer-NPCs. Eine falsche Ausrichtung bedeutet, dass der NPC in die falsche Richtung schaut und der Spieler nicht aus dem erwarteten Winkel interagieren kann.Bevor du ein Drogen-Skript auf deinem Live-Server bereitstellst, teste jedes Glied der Kette auf einem lokalen oder Staging-Server mit derselben Framework-Version, Inventar-Version und demselben Datenbankschema. Die Test-Checkliste:
weight = 1 und type = "item". Gib dir 10 davon per Admin-Befehl.Die meisten Drogen-Skript-Fehler sind Config-Fehler, die abgefangen werden könnten, bevor die Ressource überhaupt startet. Ein einfacher Validierungsansatz:
Item-Validierung. Schreibe ein kleines Startup-Skript in deiner Drogen-Ressource, das jeden Item-Namen in der Verarbeitungs-Config durchläuft und prüft, ob er in der Shared-Items-Registrierung existiert. Wenn nicht, gib eine Warnung in der Konsole aus und verweigere die Registrierung von Verarbeitungszonen, die dieses Item verwenden.
Koordinatenvalidierung. Filtere nil-Koordinaten in Zonendefinitionen heraus. Wenn eine Verarbeitungszonen-Config coords = vector3(nil, nil, nil) hat, ersetze dies durch eine sichere Fallback-Koordinate (0, 0, 70) und logge einen lauten Fehler — erstelle nicht stillschweigend eine Zone bei (0, 0, 0).
Datenbankvalidierung. Führe beim Ressourcenstart SELECT 1 FROM drug_sales LIMIT 1 aus, um zu bestätigen, dass die Datenbankverbindung aktiv ist und die Tabelle existiert. Wenn die Abfrage fehlschlägt, logge den Fehler und deaktiviere die Drogenwirtschaft, bis das Datenbankproblem behoben ist — besser kein Drogensystem als eines, das stillschweigend keine Daten speichert.
Wirtschafts-Monitoring. Beobachte Anomalien in der Drogenwirtschaft über die Zeit. Wenn der durchschnittliche Verkaufspreis pro Spieler über Nacht um 50 % sinkt, hat eine Config-Änderung die Preislogik zerstört. Wenn das gesamte verdiente Drogengeld pro Tag auf null fällt, hat das Verkaufs-Event vollständig aufgehört zu feuern. Diese Metriken fangen Probleme ab, bevor Spielerbeschwerden eingehen.
Wenn die Konfigurationsprüfungen bestehen, Drogen-Features aber immer noch nicht funktionieren, liegt das Problem im Code. Hier sind die spezifischen Lua-Debugging-Muster, die den tatsächlichen Fehler aufdecken:
Gib die Source an jedem Event-Eintrittspunkt aus. Server-seitige Drogen-Events erhalten einen source-Parameter, der den Spieler repräsentiert, der die Aktion ausgelöst hat. Wenn source nil oder 0 ist, wurde das Event vom Server selbst oder einem externen Skript ausgelöst — nicht durch eine Spieleraktion — und der Rest des Handlers wird fehlschlagen:
RegisterNetEvent('drugs:process', function(itemName)
local src = source
print("[DRUGS] Process event from source: " .. tostring(src) .. " | item: " .. tostring(itemName))
if not src or src == 0 then
print("[DRUGS WARN] Event triggered without valid source — aborting")
return
end
-- rest of handler
end)
Prüfe die Abfrage des Spieler-Objekts. Sowohl ESX- als auch QBCore-Events rufen das Spieler-Objekt mit getPlayerFromId(source) oder QBCore.Functions.GetPlayer(source) ab. Wenn der Spieler zwischen dem Auslösen des Events und der Ausführung des Handlers die Verbindung getrennt hat, gibt dies nil zurück:
local Player = QBCore.Functions.GetPlayer(src)
if not Player then
print("[DRUGS WARN] Player object is nil for source " .. src .. " — likely disconnected")
return
end
Verifiziere Datenbank-Abfrageergebnisse. Eine SELECT-Abfrage, die keine Zeilen zurückgibt, ist der häufigste stille Fehler:
local result = MySQL.query.await('SELECT cooldown FROM drug_cooldowns WHERE identifier = ?', {identifier})
if not result or #result == 0 then
print("[DRUGS] No cooldown record for " .. identifier .. " — treating as first use")
-- initiale Zeile einfügen oder Verarbeitung erlauben
else
print("[DRUGS] Cooldown value: " .. tostring(result[1].cooldown))
end
Mit systematischen Diagnosen auf jeder Ebene — Items, Koordinaten, Events, Datenbank — kannst du den exakten Fehlerpunkt in unter zehn Minuten isolieren. Die Fehlermeldung, die du brauchst, ist fast immer in der Server-Konsole sichtbar, wenn du weißt, wo du suchen musst.
Die Drogenverarbeitung schlägt fehl, wenn das eingegebene Item nicht in der Shared-Items-Liste deines Frameworks registriert ist, die Koordinaten der Verarbeitungszone falsch sind oder eine erforderliche Abhängigkeit (ox_inventory, qb-inventory) nicht läuft. Gib den Item-Namen aus dem Inventory-Trigger aus und vergleiche ihn buchstabenweise mit dem Schlüssel in den Shared Items. Teleportiere zu den Koordinaten der Verarbeitungszone, um zu prüfen, ob sie zugänglich sind. Überprüfe in F8 auf Fehler bei der Zonenregistrierung von qb-target oder ox_target.
Wenn Drogeneinnahmen nach einem Neustart verschwinden, schreibt das Verkaufsereignis das Geld in den In-Memory-Kontostand des Spielers, ohne eine Datenbank-Persistenz auszulösen. Die Lösung hängt von deinem Framework ab: Bei ESX rufst du xPlayer.addMoney gefolgt von einem MySQL.update auf; bei QBCore verwendest du Player.Functions.AddMoney, das automatisch in die players-Tabelle schreibt. Überprüfe die Server-Konsole nach SQL-Fehlern nach einem Verkaufsereignis – ein stillschweigend fehlgeschlagener INSERT ist die häufigste Ursache.
Defekte Verkaufsorte bedeuten meist, dass der NPC nicht erscheint, die Interaktionszone nicht registriert wird oder das Verkaufsereignis ausgelöst wird, der NPC die Transaktion aber ablehnt. Teste das NPC-Spawn unabhängig mit einem gewöhnlichen Ped-Modell an denselben Koordinaten. Wenn der NPC erscheint, aber keine Interaktionsaufforderung anzeigt, ist der Zonenradius zu klein oder ein anderes Skript hat sie gelöscht. Wenn die Zone funktioniert, der Verkauf aber fehlschlägt, wirft das Verkaufsereignis einen serverseitigen Fehler – überprüfe die Server-Konsole.
Launch faster
Bundles shorten the path from planning to launch by grouping the highest-leverage scripts into a cleaner commercial starting point.
| Laborequipment-Prop sichtbar, aber nicht interagierbar | Zonen-Koordinate vom Prop-Standort nach MLO-Update abgewichen | Prop-Weltkoordinaten ausgeben und mit Zonen-Config vergleichen; Abweichung > 0,5 Einheiten erfordert Aktualisierung der Zonenkoordinaten |
| Drogen-Verkaufsmenü öffnet sich, aber Transaktion schlägt fehl | Server-seitiges Event wirft stillen Fehler | Verbose-Logging in der Drogen-Ressourcen-Config aktivieren und Server-Konsole während eines Verkaufsversuchs beobachten |
Grow-Houses benötigen einen persistenten Zustand: Pflanzenstadium, Wasserstand und Wachstumszeitstempel müssen Server-Neustarts überleben. Wenn Pflanzen bei jedem Neustart zurückgesetzt werden, speichert das Skript den Grow-Status im Arbeitsspeicher statt in der Datenbank. Überprüfe, ob die Tabelle grow_houses in deiner Datenbank existiert und nach dem Pflanzen Zeilen enthält. Wenn Zeilen vorhanden sind, die Stufen aber zurückgesetzt werden, liest das Wachstums-Tick-Ereignis beim Serverstart aus dem Speicher statt aus der DB – überprüfe den Initialisierungscode der Ressource.
Drogenkonsum-Effekte verwenden clientseitige GTA-Natives wie SetTimecycleModifier und SetPedMotionBlur. Wenn sie nicht ausgelöst werden, füge einen print innerhalb des clientseitigen Konsum-Ereignisses ein, um zu bestätigen, dass das Ereignis empfangen wird. Wenn der print erscheint, aber kein visueller Effekt auftritt, löscht ein anderes Skript in einer Schleife die Bildschirmeffekte – HUD-Skripte und Statussysteme sind die häufigsten Übeltäter. Deaktiviere vorübergehend andere Skripte, um die Ursache einzugrenzen.
Crafting-Fehler entstehen durch Item-Namen-Diskrepanzen zwischen der Crafting-Rezept-Konfiguration und der Item-Registrierung deines Inventarsystems. Der Item-Key muss exakt übereinstimmen – einschließlich Groß-/Kleinschreibung und Unterstrichen. Kopiere Item-Namen direkt aus deiner Shared-Items-Datei, anstatt sie zu tippen. Wenn die Namen übereinstimmen, das Craften aber fehlschlägt, fehlt dem Spieler möglicherweise die erforderliche Zutat im Inventar, oder das Ausgabe-Item ist überhaupt nicht registriert.
Die Polizei-Dispatch-Integration ruft einen Export einer Dispatch-Ressource auf. Wenn kein Alarm ausgelöst wird, läuft die Dispatch-Ressource nicht, der Export-Name passt nicht zu deinem installierten Dispatch-Skript, oder die Drogen-Ressource wird in server.cfg vor dem Dispatch gestartet. Überprüfe, welche Dispatch-Ressource du installiert hast, und verifiziere, dass der Export-Name übereinstimmt. Häufige Exports: exports['cd_dispatch']:AlertMessage, exports['ps-dispatch']:DrugSale, exports['qs-dispatch']:DrugActivity.
Gewichtskonflikte treten auf, wenn das Gewicht des Drogen-Items in deinem Inventarsystem von dem abweicht, was die Drogen-Skript-Konfiguration angibt. Manche Skripte deklarieren das Item-Gewicht lokal, andere verwenden das registrierte Gewicht des Inventars – wenn beide existieren, können sie sich widersprechen. Definiere Item-Gewichte einmal in der Shared-Items-Datei deines Frameworks und entferne alle lokalen Gewichts-Überschreibungen aus der Drogen-Skript-Konfiguration. Lade die Inventar-Ressource neu, nachdem du Gewichte geändert hast.
Fehler beim NPC-Händler haben drei Ursachen: ungültiges Ped-Modell, Koordinaten innerhalb von Geometrie oder ein Ressourcen-Ladereihenfolge-Problem. Teste mit a_m_y_business_01 an denselben Koordinaten – wenn der erscheint, ist dein Modell-Name falsch oder das Modell wird nicht gestreamt. Wenn das auch fehlschlägt, sind die Koordinaten schlecht: unterirdisch, in einer Wand oder in einem nicht geladenen Interior. Verifiziere die Koordinaten im Spiel mit der Positionsanzeige des Ressourcen-Monitors.
Routenbasierte Drogenmissionen verketten Wegpunkte mit Distanzprüfungen. Wenn eine Route an einem bestimmten Wegpunkt abbricht, füge einen print innerhalb des Checkpoint-Handlers ein, um zu identifizieren, welcher Index fehlschlägt. Die häufigste Ursache ist ein zu enger Distanzschwellenwert – unter 2,0 Einheiten bedeutet, dass ein normal laufender Spieler den Trigger verpasst. Überprüfe auch, dass Wegpunktkoordinaten nicht nil sind: Ein fehlender Konfigurationseintrag erzeugt stillschweigend (0, 0, 0) als Ziel, was unterirdisch ist.
Drogen-Skill-EP müssen nach jeder qualifizierenden Aktion in die Datenbank geschrieben werden. Wenn EP sich nicht ansammelt, feuert das serverseitige EP-Ereignis nicht oder der Datenbank-Schreibvorgang schlägt stillschweigend fehl. Frage die drug_skills-Tabelle direkt ab: SELECT * FROM drug_skills WHERE identifier = 'char1:abc123'. Wenn die Zeile vollständig fehlt, wurde der initiale INSERT nie ausgeführt – meist, weil der Spieler dem Server beigetreten ist, bevor die Drogen-Ressource vollständig gestartet war. Führe den INSERT manuell aus oder starte die Ressource neu.
Laborequipment-Interaktionen verwenden ox_target- oder qb-target-Zonen, die an Prop-Koordinaten gebunden sind. Wenn die Zone existiert, aber nichts passiert, wenn man sich nähert, ist die Weltposition des Props von den registrierten Zonenkoordinaten abgewichen – häufig nach MLO-Updates. Gib die aktuellen Koordinaten des Props aus und vergleiche sie mit der Zonenkonfiguration. Wenn sie um mehr als 0,5 Einheiten abweichen, aktualisiere die Zonenkoordinaten. Überprüfe auch, ob sich der Name des Interaktionsereignisses nach einem Skript-Update geändert hat.