Category hub
Compare police, mechanic, drug, civilian, and economy systems in the main jobs hub before you commit to a single resource.
Open job scripts
Wirtschafts-Skripte verbinden jedes wichtige System auf deinem Server — Jobs zahlen Geld aus, Shops nehmen Geld ein, Banken speichern Geld, Geldautomaten überweisen Geld und Regierungssysteme besteuern es. Wenn die Wirtschaft zusammenbricht, friert die gesamte Server-Wirtschaft innerhalb von Minuten ein. Spieler können keine Gegenstände kaufen, Angestellte erhalten keine Gehaltsschecks, Unternehmen können nicht operieren und der soziale Vertrag, der das Rollenspiel immersiv macht, kollabiert. Die Wirtschaft ist zudem das Ziel Nr. 1 für Exploits, daher ist die Fehlerbehebung gleichermaßen Bug-Jagd und Sicherheitsarbeit.
Warum fallen Wirtschafts-Skripte so oft aus? Vier Hauptursachen machen die überwiegende Mehrheit der Ausfälle aus. Erstens: Datenbank-Transaktionsfehler — wenn eine Geldoperation in die Datenbank schreibt, aber die Abfrage ein Timeout hat, mit einer anderen gleichzeitigen Schreiboperation kollidiert oder das Schema nicht dem entspricht, was das Skript erwartet. Zweitens: Framework-Geld-Event-Konflikte — ESX, QBCore und QBox handhaben Geld-Events unterschiedlich, und wenn mehrere Resources versuchen, dasselbe Konto gleichzeitig über verschiedene APIs zu ändern, erzeugen Race Conditions doppelte Transaktionen oder stillschweigend verworfene Updates. Drittens: Negativsalden-Randfälle — die meisten Wirtschafts-Skripte werden nur auf dem Erfolgspfad mit positiven Salden getestet, aber eine einzige Transaktion, die ein Konto unter Null drückt, kann kaskadierende Ausfälle in Abrechnungs-, Überweisungs- und Gehaltssystemen verursachen. Viertens: Missmanagement von Gesellschaftskonten — gemeinsame Konten für Unternehmen, Gangs und Regierungsabteilungen sind auf Berechtigungssysteme angewiesen, die oft stillschweigend versagen, wenn Mitglieder hinzugefügt, entfernt oder befördert werden.
Die Auswirkungen sind unmittelbar und messbar. Ein defektes Geldautomatensystem bedeutet, dass Spieler nicht auf ihre Bankguthaben zugreifen können, was bedeutet, dass sie keine Fahrzeuge oder Immobilien kaufen können, was bedeutet, dass die gesamte Rollenspiel-Schleife zum Stillstand kommt. Ein Geldvermehrungs-Exploit kann die Server-Wirtschaft innerhalb von Stunden um Millionen aufblähen und monatelange ausgewogene Progression zerstören. Ein Ausfall des Gehaltssystems bedeutet, dass Spieler das Vertrauen in die Stabilität des Servers verlieren und zur Konkurrenz wechseln. Wirtschaftsprobleme sind nicht nur technische Bugs — sie sind Spielerbindungsprobleme.
Dieser Leitfaden behandelt die zwölf Wirtschaftsfehler, die wir am häufigsten auf ESX-, QBCore- und QBox-Servern sehen. Jeder Abschnitt zeigt, wie du die Ursache diagnostizierst, die Lösung, die das Problem in den meisten Fällen behebt, und die Sicherheitsfalle, die selbst erfahrene Admins erwischt.
Schnelldiagnose-Tabelle
Bevor du in die einzelnen Probleme eintauchst, ordne das beobachtete Symptom der wahrscheinlichsten Ursache zu.
| Symptom | Wahrscheinlichste Ursache | Erster Prüfschritt |
|---|---|---|
| Geld verschwindet nach Neustart | Transaktion nicht committed oder asynchrone Speicher-Race-Condition | Prüfen, ob Speicher-Event vor Abschluss des Server-Shutdowns ausgelöst wird |
| Saldo zeigt negative Zahlen | Fehlende Saldo-Untergrenzen-Prüfung | if balance < 0 then balance = 0 end-Absicherung in Geld-Handlern hinzufügen |
| Banküberweisungen laufen in Timeout | Datenbank-Sperrkonflikt oder Schema-Konflikt | SHOW PROCESSLIST um blockierende Abfragen zu finden; Spaltentypen prüfen |
| Gesellschaftskonten nicht zugänglich | Fehlender Mitgliedseintrag oder falsche Berechtigungsstufe | SELECT * FROM society_members WHERE identifier = ? |
| Geldautomat zeigt keine Interaktionsaufforderung | Prop-Hash-Konflikt mit benutzerdefinierten Map-Props | GetEntityModel(entity) für jeden Geldautomaten auf der Map ausgeben |
| Artikel kosten 0 $ in Shops | Konfigurationsdatei-Parsefehler oder Laufzeit-Überschreibung | Serverkonsole auf Lua/JS-Parsefehler beim Resource-Start prüfen |
| Rechnungen kommen nie an | Ziel-Identifier-Auflösung schlägt fehl | Citizenid/License-Suche statt Namensabgleich verwenden |
| Schwarzgeld wird nicht umgewandelt | Kontotyp nicht im Framework registriert | black_money in ESX addon_accounts oder QBCore Shared Config prüfen |
| Gehaltsschecks werden nicht verarbeitet | Server-seitiger Timer gestoppt oder Intervall auf null | Debug-Print in der Gehalts-Timer-Schleife hinzufügen |
| Steuern werden nicht erhoben | Einkommensquelle umgeht den Steuer-Handler | Jeden addMoney-Aufruf durchsuchen; bestätigen, dass jeder über die Steuerfunktion läuft |
| Markt-Skript stürzt beim Laden ab | NaN oder Infinity durch fehlerhafte Preisberechnung | isnan()- und isfinite()-Absicherungen zu jeder Preisaktualisierung hinzufügen |
| Gesamtgeldmenge wächst zu schnell | Mehr Zuflüsse als Abflüsse | Wöchentliches SUM(balance) über alle Geldtabellen; Verbrauchskosten hinzufügen |
Diagnoseablauf: Systematische Wirtschafts-Fehlerbehebung
Wenn du Unregelmäßigkeiten in der Wirtschaft bemerkst — ein Spieler meldet fehlendes Geld, ein Transaktionsprotokoll voller Fehler oder ein plötzlicher Anstieg der Gesamtgeldmenge — folge diesem strukturierten Diagnoseablauf, bevor du Code änderst. Direkt zu einer Lösung zu springen, ohne die Ursache zu verstehen, riskiert neue Bugs zu erzeugen, die schwerer zurückzuverfolgen sind.
Schritt 1: Spielergeld in der Datenbank prüfen. Frage die relevanten Geldtabellen direkt ab — für ESX ist das users.accounts (als JSON) oder addon_account_data; für QBCore ist es die players-Tabelle mit der money-JSON-Spalte; für QBox ist es die accounts-Tabelle in ox_core. Vergleiche den Datenbankwert mit dem, was der Spieler im Spiel sieht. Wenn die Werte nicht übereinstimmen, kann der Synchronisationsmechanismus (ein Client-Event, ein State-Bag-Update oder ein Callback) den korrekten Wert nicht an die UI weitergeben. Dies ist der zuverlässigste Indikator dafür, wo der Fehler aufgetreten ist.
Schritt 2: Überprüfen, ob Geld-Events ausgelöst werden. Jedes Framework verwendet benannte Events für Geldoperationen. In ESX müssen esx:addAccountMoney und esx:removeAccountMoney serverseitig ausgelöst werden und einen Datenbank-Schreibvorgang auslösen. In QBCore verarbeiten qb-banking:server:AddMoney oder ähnliche Events Transaktionen. Füge einen temporären Debug-Print am Anfang jedes Event-Handlers hinzu, führe eine Testtransaktion durch und beobachte die Serverkonsole. Wenn der Handler nie ausgelöst wird, ist der Event-Name falsch, das Resource ist nicht gestartet oder der Export/Trigger ist falsch konfiguriert. Wenn er ausgelöst wird, aber die Datenbank nicht aktualisiert wird, schlägt die Abfrage selbst fehl — überprüfe die Abfrageargumente, Spaltennamen und die Transaktionsisolationsstufe.
Schritt 3: Hinzufüge- und Entfernungsoperationen isoliert testen. Verwende den serverseitigen Export deines Frameworks — exports['es_extended']:getSharedObject().AddMoney() für ESX, exports['qb-core']:GetPlayer().Functions.AddMoney() für QBCore oder exports.ox_inventory:AddItem() für QBox — von einem Testbefehl aus. Füge genau 1 Einheit Währung hinzu, überprüfe, ob sie sowohl in der In-Game-UI als auch in der Datenbank erscheint, entferne sie dann und überprüfe, ob sie verschwindet. Dieser Rauchtest erkennt defekte Exporte, falsch konfigurierte Event-Ketten und Berechtigungsprobleme in unter einer Minute.
Schritt 4: Gesellschafts- und gemeinsame Konten prüfen. Gesellschaftskonten (Polizeibudget, Gang-Kasse, Geschäftskonten) werden getrennt von persönlichen Konten gespeichert und verwenden eine andere Zugriffskontrolle. In ESX befindet sich Gesellschaftsgeld in addon_account_data, verschlüsselt nach society_<jobname>. In QBCore verwenden Gang- und Job-Konten das Kontosystem der Management-Resource. Frage diese Tabellen direkt ab und überprüfe, ob die Salden mit dem übereinstimmen, was Mitglieder in ihren Management-Menüs sehen. Berechtigungsdiskrepanzen — ein Mitglied, das den Saldo sehen, aber nicht abheben kann — deuten darauf hin, dass die Zugriffsebene in der Mitgliedertabelle nicht mit dem übereinstimmt, was das Skript erwartet.
Schritt 5: Banksystem-Integration prüfen. Die meisten Server verwenden ein Drittanbieter-Banking-Skript (qb-banking, ps-banking, okokBanking oder ein benutzerdefiniertes), das das Geldsystem des Frameworks umschließt. Diese Skripte pflegen oft ihre eigenen Kontotabellen oder cachen Salden im Speicher. Wenn der interne Zustand des Banking-Skripts von der Datenbank des Frameworks abweicht, scheinen Transaktionen erfolgreich zu sein, aber Gelder werden nie tatsächlich überwiesen. Starte das Banking-Resource neu und achte auf Initialisierungsfehler — eine fehlende Tabelle, eine fehlgeschlagene Migration oder ein Schema-Versionskonflikt erscheint in den ersten Zeilen der Konsolenausgabe.
Schritt 6: Geldautomaten- und Interaktions-Skripte validieren. Geldautomaten, Shop-Blipe und Bankschalter sind alle auf Target- oder Marker-Systeme (qb-target, ox_target, bt-target) angewiesen, um die Nähe des Spielers zu erkennen und Interaktionsoptionen anzubieten. Der Interaktions-Trigger hängt vom Abgleich von Entity-Modell-Hashes oder koordinatenbasierten Zonendefinitionen ab. Wenn Spieler an einem Geldautomaten stehen und keine Aufforderung sehen, ist der Modell-Hash des Geldautomaten-Prope nicht in der erlaubten Liste des Banking-Skripts, das Target-System ist nicht geladen oder eine konkurrierende Resource konsumiert das Interaktions-Event, bevor das Banking-Skript es empfängt.
Framework-spezifische Wirtschaftsmechaniken
Zu verstehen, wie jedes Framework Geld auf architektonischer Ebene handhabt, verhindert die meisten Fehlkonfigurationen, bevor sie zu Produktionsvorfällen werden.
ESX-Wirtschaftsarchitektur
ESX (es_extended) hat das FiveM-Wirtschaftsmodell entwickelt und bleibt das am weitesten verbreitete Framework. Geld fließt in ESX durch drei Schichten: das Kern-Geldsystem in es_extended, das Kontosystem in esx_addonaccount und das Gesellschaftssystem in esx_society.
Das Kern-Geldsystem speichert Bargeld- und Banksalden als JSON in der users-Tabelle unter einer accounts-Spalte — typischerweise {"money": 5000, "bank": 25000, "black_money": 0}. Jede Geldoperation ruft xPlayer.setAccountMoney() auf, das den speicherinternen Wert aktualisiert und einen Datenbank-Speichervorgang auslöst. Die kritische Schwäche hierbei ist, dass der Speichervorgang asynchron ist — wenn der Server zwischen dem speicherinternen Update und dem Datenbank-Schreibvorgang abstürzt oder neu startet, geht die Transaktion verloren.
esx_addonaccount erweitert das Geldsystem um benannte Konten — black_money, society_police, society_ambulance und benutzerdefinierte Konten wie crypto oder dirty_cash. Jedes Konto erhält eine eigene Zeile in der addon_account_data-Tabelle, verschlüsselt nach Kontoname und Besitzer-Identifier. Geldoperationen auf diesen Konten verwenden exports['esx_addonaccount']:addAccountMoney() und erfordern, dass der Kontoname in addon_accounts existiert — eine fehlende Kontoregistrierung ist die häufigste Ursache für „attempt to index a nil value"-Fehler in ESX-Wirtschafts-Skripten.
esx_society baut auf Addon-Konten auf, um gemeinsame Organisationsfonds zu erstellen. Wenn ein Spieler als Polizist eingestellt wird, erhält er einen society_police-Eintrag in addon_account_data und eine entsprechende Zeile in der society_moneywash- oder äquivalenten Job-Management-Tabelle. Auszahlungsberechtigungen werden durch die Job-Stufe gesteuert — ein Rekrut hat normalerweise keinen Zugriff, ein Officer kann einzahlen und der Chief kann abheben. Der häufigste Gesellschafts-Bug ist die stufenbasierte Berechtigungsabweichung: Wenn ein Serverbetreiber Job-Stufen anpasst, ohne die Stufen-zu-Berechtigung-Zuordnung des Gesellschafts-Skripts zu aktualisieren.
Transaktionsablauf in ESX: Spieleraktion → Client-Event → Server-Event-Handler → xPlayer.getAccount() → account.addMoney() / account.removeMoney() → MySQL.Async.execute() → Client-Callback mit neuem Saldo. Jede Unterbrechung in dieser Kette — ein Event-Namenskonflikt, ein nil-Konto, ein Datenbank-Abfrage-Timeout — verwirft die Transaktion stillschweigend, ohne den Spieler zu benachrichtigen.
QBCore-Wirtschaftsarchitektur
QBCore trennt Geld in benannte Typen, die in qb-core/shared/main.lua unter QBShared.Money definiert sind: typischerweise cash, bank, crypto und gelegentlich bloodmoney oder benutzerdefinierte Währungen. Im Gegensatz zu ESXs JSON-Blob-Ansatz speichert QBCore jeden Geldtyp als separate Spalte in der players-Tabelle — money.cash, money.bank, money.crypto — was Datenbankabfragen unkomplizierter macht, aber Schema-Zerbrechlichkeit einführt, wenn neue Geldtypen hinzugefügt werden.
Geldoperationen verwenden Player.Functions.AddMoney(type, amount) und Player.Functions.RemoveMoney(type, amount). Der type-Parameter muss exakt mit einem Schlüssel in QBShared.Money übereinstimmen; ein Tippfehler wie Player.Functions.AddMoney('cach', 500) schlägt stillschweigend fehl, weil der Typ nicht existiert. Das Framework löst qb-core:server:UpdatePlayer nach jeder Geldänderung aus, das die neuen Werte an alle Resources sendet, die auf Spielerdaten-Updates hören.
Banking in QBCore wird von externen Resources gehandhabt — qb-banking, ps-banking, okokBanking oder Renewed-Banking — weil QBCore selbst keine integrierte Banking-UI oder Transaktionssystem hat. Jedes Banking-Skript pflegt seine eigenen bank_accounts-, bank_transactions- und bank_members-Tabellen, die das Kern-Geldsystem spiegeln und erweitern. Diese Entkopplung ist die Quelle der häufigsten Wirtschafts-Bugs von QBCore: Wenn die Tabellen des Banking-Skripts nicht mehr mit der players.money-Spalte des Kerns synchron sind, scheinen Überweisungen in der Banking-UI abgeschlossen zu sein, aber der tatsächliche Saldo ändert sich nie.
Gemeinsame Konten in QBCore verwenden das Gesellschafts- oder Gang-Kontosystem des Banking-Skripts. qb-management erstellt Job-Konten, auf die mehrere Spieler basierend auf ihrem Job und ihrer Stufe zugreifen können. qb-gangs erstellt Gang-Konten mit Zugriffskontrolle auf Mitgliederebene. Beide verwenden dieselbe zugrunde liegende Tabellenstruktur — eine Kontentabelle mit einer JSON-members-Spalte, die Identifier und ihre Zugriffsebenen auflistet — was bedeutet, dass ein einziger fehlerhafter JSON-Eintrag eine gesamte Organisation von ihren Geldern aussperren kann.
QBox-Wirtschaftsarchitektur
QBox (auf ox_core aufgebaut) verfolgt einen grundlegend anderen Ansatz: Konten sind erstklassige Datenbankentitäten, die in der accounts-Tabelle mit Spalten für id, owner (eine Charakter-ID), type (persönlich oder gemeinsam), balance und label gespeichert werden. Anders als bei ESX und QBCore, wo Geldtypen bei der Framework-Konfiguration festgelegt werden, werden QBox-Konten dynamisch erstellt — jedes Skript kann einen neuen Kontotyp zur Laufzeit mit exports.ox_core:CreateAccount() erstellen.
Geldoperationen verwenden die Konto-API von ox_core: exports.ox_core:AddMoney(accountId, amount) und exports.ox_core:RemoveMoney(accountId, amount). Die API arbeitet mit Konto-IDs, nicht mit Spieler-Identifiern oder Charakternamen, was das „Welches Identifier-Format?"-Problem eliminiert, das ESX und QBCore plagt. Transaktionen sind standardmäßig in Datenbanktransaktionen (BEGIN...COMMIT) verpackt, was die Teil-Schreibfehler verhindert, die in anderen Frameworks Phantomgeld verursachen.
ox_banking bietet die Banking-Oberfläche auf Basis von ox_core-Konten. Es unterstützt persönliche Konten, gemeinsame Konten für Organisationen und automatische Transaktionsprotokollierung. Der entscheidende architektonische Unterschied besteht darin, dass ox_banking keine separaten Saldotabellen pflegt — es liest direkt aus der accounts-Tabelle von ox_core, sodass es nie eine Synchronisationsdiskrepanz zwischen der Banking-UI und dem tatsächlichen Saldo gibt. Der Zugriff auf gemeinsame Konten verwendet die account_access-Tabelle mit granularen Berechtigungsstufen pro Mitglied.
Schwarzgeld und benutzerdefinierte Währungen in QBox sind einfach zusätzliche Konten mit bestimmten Labels — black_money, crypto, organization_funds — alle in derselben accounts-Tabelle mit denselben Transaktionsgarantien gespeichert. Diese Einheitlichkeit macht das Wirtschafts-Debugging erheblich einfacher: SELECT * FROM accounts liefert das vollständige Finanzbild jedes Spielers und jeder Organisation auf dem Server in einer einzigen Abfrage.
Häufige Wirtschaftsprobleme und ihre Ursachen
Geld wird nach Neustart nicht gespeichert. Der häufigste und schädlichste Wirtschafts-Bug. Ursache: Das Speicher-Event (MySQL.Async, oxmysql-Abfrage oder Datenbank-Trigger) wird asynchron ausgelöst und der Serverprozess wird beendet, bevor der Schreibvorgang abgeschlossen ist. ESX-Server, die essentialmode oder alte MySQL-Wrapper verwenden, sind besonders anfällig, weil der asynchrone Callback während des onResourceStop-Events nicht abgewartet wird. Lösung: Implementiere einen synchronen Speichervorgang beim Server-Stopp mit PerformHttpRequest und einem blockierenden Callback oder wechsle zu oxmysql, das await-fähige Abfragen in Stop-Handlern unterstützt. Füge ein SHUTDOWN DELAY 30 zu deiner server.cfg hinzu, um allen Resources Zeit zu geben, ihre Speicherwarteschlangen zu leeren.
Negative Salden. Fast jedes Wirtschafts-Skript geht davon aus, dass Salden nie unter Null fallen können, aber die Transaktionsreihenfolge kann negative Werte erzeugen: Eine Geldentfernungs-Operation wird ausgelöst, bevor eine ausstehende Geldhinzufügungs-Operation aufgelöst wird, oder ein Gesellschaftskonto erlaubt eine Auszahlung, die den Saldo vorübergehend überschreitet, bevor die nächste Einzahlung eintrifft. Lösung: Füge Saldo-Untergrenzen-Prüfungen in jedem Geldentfernungs-Handler hinzu (if currentBalance - amount < 0 then return error end) und mache sie server-autoritativ — vertraue niemals dem Client, zu melden, ob er sich etwas leisten kann.
Gesellschaftskonten fehlen. Das Gesellschaftskonto existiert in der Datenbank, der Spieler hat den korrekten Job und die korrekte Stufe, aber das Management-Menü zeigt 0 $ oder verweigert den Zugriff vollständig. Drei Ursachen in der Reihenfolge der Häufigkeit: (1) Der Gesellschaftskontoname stimmt nicht zwischen der Framework-Konfiguration, dem Job-Skript und dem Management-Skript überein — ein einziger Tippfehler wie society_police vs. society_police_department zerstört die gesamte Kette; (2) das Identifier-Format des Spielers hat sich nach einer Framework-Migration geändert (Steam HEX vs. License vs. Citizenid), sodass bestehende Gesellschaftsmitglieder-Zeilen nicht übereinstimmen; (3) das Management-Skript prüft auf einen Berechtigungsschlüssel, der während einer Job-Stufen-Umstrukturierung entfernt wurde.
Banküberweisungen schlagen stillschweigend fehl. Das Überweisungs-Event wird ausgelöst, die UI zeigt „Überweisung abgeschlossen", aber der Empfänger erhält das Geld nie. Dies passiert, wenn die Überweisungsfunktion vom Sender abbucht, aber die Hinzufüge-zum-Empfänger-Abfrage fehlschlägt — wodurch Geld entsteht, das das Konto des Senders verlässt, aber nie irgendwo ankommt. Lösung: Umschließe alle Überweisungen in einer Datenbanktransaktion (START TRANSACTION → Sender belasten → Empfänger gutschreiben → COMMIT; bei jedem Fehler ROLLBACK). Wenn der Datenbank-Wrapper deines Frameworks keine Transaktionen unterstützt, implementiere einen zweiphasigen Ansatz: zuerst abbuchen, die Abbuchung verifizieren, dann gutschreiben und alle verwaisten Abbuchungen zur manuellen Überprüfung protokollieren.
Geldautomat funktioniert nicht. Über den in der FAQ erwähnten Prop-Hash-Konflikt hinaus scheitern Geldautomaten, weil: das Banking-Skript während eines Resource-Neustartzyklus entladen wurde und seine Target-Zonen nicht neu registriert hat; eine konkurrierende Map-Resource die Standard-Geldautomaten-Prope durch benutzerdefinierte Modelle ersetzt hat; oder die Interaktionsdistanz zu klein eingestellt ist (häufig auf Servern, die sie reduziert haben, um versehentliche Geldautomaten-Trigger in überfüllten Bereichen zu verhindern). Lösung: Verwende koordinatenbasierte Geldautomaten-Zonen anstelle von entitätsbasierter Erkennung, setze die Interaktionsdistanz auf mindestens 2,5 Meter und implementiere einen Fallback-Befehl (/atm), der die Banking-Oberfläche von überall aus öffnet.
Gehaltsschecks werden nicht verarbeitet. Der Gehalts-Timer ist der fragilste Teil jedes Wirtschaftssystems. Ein einziger unbehandelter Fehler innerhalb der Timer-Schleife — ein nil-Spielerobjekt, wenn jemand mitten im Zyklus die Verbindung trennt, ein Datenbank-Timeout während einer Massenzahlung oder eine Division-durch-Null bei der Berechnung von Stundensätzen — beendet den gesamten Timer stillschweigend. Lösung: Umschließe den Körper der Gehaltsschleife in pcall (Lua) oder try/catch (JS), verarbeite Spieler einzeln statt in Bulk und füge einen Watchdog-Timer hinzu, der die Gehaltsschleife neu startet, wenn er für zwei aufeinanderfolgende Zyklen keine Zahlungen erkennt.
Schwarzgeldsysteme. Schwarzgeldkonten erfordern eine explizite Registrierung in allen drei Frameworks, aber Skripte, die Schwarzgeld generieren (Drogenverkäufe, Raubauszahlungen, illegales Crafting), gehen oft davon aus, dass das Konto bereits existiert. Wenn dies nicht der Fall ist, verschwindet das Geld stillschweigend im Nichts — Spieler schließen die illegale Aktivität ab, erhalten aber nichts. Lösung: Füge Kontoexistenzprüfungen in jedem Geldhinzufüge-Handler hinzu und erstelle das Konto bei Bedarf, anstatt sich darauf zu verlassen, dass Server-Startskripte jeden möglichen Kontotyp vorregistrieren.
Prävention und Überwachung
Wirtschaftsfehler zu verhindern ist billiger, als sie zu beheben, nachdem Spieler sie bemerkt haben. Implementiere diese fünf Sicherheitsmaßnahmen und du wirst die meisten Probleme abfangen, bevor sie das Gameplay beeinträchtigen.
Führe wöchentliche Wirtschafts-Audit-Abfragen durch. Ein einfaches SUM(balance) über alle Geldtabellen (persönliche Konten, Gesellschaftskonten, Addon-Konten) zeigt dir die Gesamtgeldmenge auf deinem Server. Verfolge diese Zahl Woche für Woche — ein Sprung von mehr als 10 % deutet entweder auf einen Duplikations-Bug oder eine neue Einkommensquelle hin, die nicht durch Geldsenken ausgeglichen wird. Frage separat nach negativen Salden (SELECT COUNT(*) FROM accounts WHERE balance < 0) — jedes Nicht-Null-Ergebnis bedeutet, dass ein Randfall einen Spieler getroffen hat.
Aktiviere Transaktionsprotokollierung für jede Geldoperation. Jedes Hinzufügen, Entfernen und Überweisen sollte eine Zeile in eine money_transactions-Tabelle mit Zeitstempel, Quell-Identifier, Ziel-Identifier, Betrag, Kontotyp und dem Namen des aufrufenden Resources schreiben. Dieses Protokoll ist unschätzbar wertvoll, um den Ursprung von doppeltem Geld zu verfolgen, Spielerberichte über fehlende Gelder zu beweisen oder zu widerlegen und Skripte zu identifizieren, die ohne Autorisierung Geld generieren. Implementiere eine automatische Bereinigung von Protokolleinträgen, die älter als 90 Tage sind, um zu verhindern, dass die Tabelle die Abfrageleistung beeinträchtigt.
Setze aggressive Backup-Frequenz für Finanztabellen. Deine users-, accounts-, addon_account_data-, bank_transactions- und society_members-Tabellen sollten mindestens alle 6 Stunden gesichert werden, nicht nur täglich. Ein einziges Wirtschaftskorruptionsereignis kann monatelange ausgewogene Progression in Minuten zerstören, und ein 24 Stunden altes Backup bedeutet den Verlust eines ganzen Tages Spielerfortschritt. Verwende mysqldump mit dem --single-transaction-Flag für InnoDB-Tabellen, um konsistente Snapshots ohne Sperrung zu erhalten.
Teste Wirtschaftsänderungen in der Staging-Umgebung vor der Produktion. Jede Wirtschafts-Skript-Änderung — eine neue Job-Auszahlung, ein geänderter Steuersatz, ein hinzugefügter Geldtyp — sollte auf einem Staging-Server für mindestens einen vollständigen Zahlungszyklus laufen, bevor sie die Produktion erreicht. Überprüfe, dass Salden zwischen Datenbank und In-Game-UI übereinstimmen, dass alle Geld-Events ausgelöst werden und ihre Datenbank-Schreibvorgänge abschließen und dass sich die Gesamtgeldmenge nicht unerwartet verändert hat. Eine Staging-Umgebung mit 5–10 Testkonten ist billiger als 200 Spieler, die defekte Gehaltsschecks melden.
Überwache Saldo-Anomalien in Echtzeit. Füge eine serverseitige Prüfung hinzu, die bei jeder Geldhinzufüge-Operation ausgelöst wird: Wenn der neue Saldo mehr als das 10-fache des vorherigen Saldos beträgt, protokolliere eine Warnung mit dem vollständigen Kontext (Quelle, Betrag, vorheriger Saldo, aufrufendes Resource). Dies erkennt Geldvermehrungs-Exploits innerhalb von Sekunden nach der Aktivierung, anstatt Stunden später, wenn ein Admin bemerkt, dass die Wirtschaft aufgebläht ist. Für Gesellschaftskonten markiere jede Auszahlung, die 50 % des Kontosaldos überschreitet — dies erkennt kompromittierte Mitgliederkonten, die Gang- oder Geschäftsfonds leeren, bevor der Schaden katastrophal ist.
![Italian Pizzeria - Vespucci Pizza [FiveM MLO]](/_next/image?url=https%3A%2F%2Fcdn.fivemx.com%2Ffree-mods%2Fitalian-pizzeria-vespucci-pizza-fivem-mlo%2Fimages%2F2026%2F05%2F5965691a-f4ef-474e-be0e-517c36be86ef-italian-pizzeria-vespucci-pizza-fivem-mlo-featured.webp&w=2048&q=75)
