Datenbank und Bridge

Unterstützte Abfragen#

Die Verbindung ist für jeden Server standardmäßig an und braucht keine Zeile in server.cfg. Zum Abschalten für einen Server diesen im Bereich Server öffnen und auf der Karte Tosun Connect „Disable connection“ wählen; dieselbe Karte schaltet sie wieder ein. Mit set tosun_db_bridge_manual "1" in server.cfg werden tosun_db_bridge_enabled und tosun_db_bridge_money_write wie bisher aus server.cfg gelesen; jeder Wert bleibt aus, solange er nicht "1" ist. Ist der alte Vollspiegel absichtlich aktiviert (ts.panelMirror.enabled = true in configs/anticheat_config.lua), bleibt die Bridge automatisch aus, damit dieser Spiegel weiterläuft. Unterstützte QBCore-/ESX-Strukturen liefern ausgewählte Spieler-, Inventar-, Fahrzeug- und Protokolldaten. Eigene Tabellen können nicht unterstützt sein.

Begrenzte Abfragen und Kontostandsänderungen#

Im Leerlauf erfolgt etwa alle 10 Sekunden eine HTTPS-Abfrage ohne Spiel-Datenbankabfrage. Pro Seite höchstens 25 Ergebnisse, ein Auftrag gleichzeitig. Das Ändern von Kontoständen (Bargeld- oder Banksumme eines Online-Charakters im Panel setzen) ist standardmäßig an. Nutzen können es Panel-Benutzer mit der Rolle Admin oder Owner (Wirtschaftsrecht). Der Charakter muss online sein und der erwartete aktuelle Kontostand muss stimmen, sonst kommt stale_balance zurück und nichts ändert sich. Vor dem Senden zeigt das Panel eine Zusammenfassung zur Bestätigung, und jede Anfrage wird im Audit-Log gespeichert. Die Summe wird gesetzt, nicht addiert. Ein unklares Ergebnis wird nie automatisch wiederholt; zuerst den Kontostand im Spiel prüfen. Um Abfragen und Kontostandsänderungen für einen Server zu stoppen: „Disable connection“ auf der Karte Tosun Connect. Nur Kontostandsänderungen abschalten und Abfragen behalten: manueller Modus mit set tosun_db_bridge_manual "1" und set tosun_db_bridge_enabled "1", ohne set tosun_db_bridge_money_write "1".

Über den bestehenden Spielserver verbinden#

Die Bridge nutzt die vorhandene oxmysql-Verbindung. Das Panel übergibt unterstützte Aufträge per HTTPS; der Spielserver führt sie lokal aus und liefert ausgewählte Ergebnisse. Sie müssen weder das MySQL-Passwort im Panel speichern noch MySQL öffentlich erreichbar machen.

1. Die Verbindung ist für jeden Server standardmäßig aktiv; ab tosun-ac 9.6.14 müssen Sie sie nicht einschalten. Zum Abschalten für einen Server: Server → den Server → Karte Tosun Connect → „Disable connection“. Ist der alte Vollspiegel bewusst mit ts.panelMirror.enabled = true in configs/anticheat_config.lua aktiviert, bleibt die Bridge automatisch aus, damit der alte Spiegel weiter funktioniert.
2. Ab tosun-ac 9.6.14 ist für die Verbindung keine server.cfg-Zeile nötig; nur die Zeile set tosun_ac_license mit der richtigen Lizenz bleibt. Ältere Zeilen tosun_db_bridge_enabled und tosun_db_bridge_money_write werden dann ignoriert und können gelöscht werden; ein Server mit älterem Paket braucht sie, bis das neue Paket installiert ist. Das Ändern von Kontoständen online ist ebenfalls standardmäßig aktiv und auf Panelnutzer mit der Rolle admin oder owner beschränkt.
3. Ausgehendes HTTPS zu admin.tosundev.com erlauben, Status in der Serverkonsole prüfen und eine kleine Spielerliste anfordern.

# In der Serverkonsole ausführen:
tosunac_db_status

Community-Website nur mit der Lizenz#

Ihre Community-Website liest Spieldaten über dieselbe Tosun-Connect-Verbindung. Wenn für den Server im Panel keine Spieldatenbank-Einstellungen eingetragen sind, braucht die Website keinen MySQL-Benutzer, kein GRANT und keinen offenen Port 3306: Die Seiten Spieler, Banns, Anticheat-Erkennungen und Logs laden ihre Daten beim Öffnen vom Spielserver.

In diesem Modus kann die Website nicht suchen, filtern, entbannen, Banns hinzufügen oder Geld und Inventare bearbeiten. Um einen Bann aufzuheben, verwenden Sie im Spiel /ts unban <banID> oder in der Serverkonsole ts unban <banID>. Jede Seite ist eine neue Anfrage und wird in etwa 10 Sekunden beantwortet; ist der Spielserver offline oder die Verbindung auf der Tosun-Connect-Karte ausgeschaltet, zeigt die Seite das an statt einer leeren Liste.

Namen, Jobs, Kontostände, Inventare und Fahrzeugmodelle benötigen tosun-ac 9.6.17 oder neuer auf dem Spielserver. Mit älteren Paketen liefern manche MySQL/MariaDB-Server nur die Charakter-ID.

Eine direkte Verbindung zur Spieldatenbank ist optional. Richten Sie sie nur ein, wenn Sie auf der Website suchen und bearbeiten möchten: Legen Sie einen Datenbankbenutzer an, der sich nur von der IP-Adresse des Tosun-Panelservers verbinden kann (der Support bestätigt sie), geben Sie ihm SELECT, INSERT, UPDATE und DELETE auf die Spieldatenbank, öffnen Sie Port 3306 nur für diese Adresse und tragen Sie die Daten unter Server in den Datenbankeinstellungen des Servers ein (Direct MySQL · Advanced). Das Panel speichert sie nur nach einem erfolgreichen Verbindungstest. Ohne diese Angaben bleibt die Einrichtung nur mit Lizenz in Gebrauch.

• Spieler: 25 Charaktere pro Seite mit Charakter-ID, Name und Job. Das Team sieht außerdem Bargeld und Bank.
• Das Team (ab Moderator) kann einen Charakter anklicken, um Online-Status, Kontostände und Inventar zu sehen, und die Fahrzeuge dieses Charakters laden.
• Banns und Anticheat-Erkennungen: 25 Einträge pro Seite, nur lesend. Erkennungen erscheinen von alt nach neu, Banns in der Reihenfolge der Bann-ID.
• Die Dashboard-Summen für Spieler, Banns und Erkennungen zeigen „—“: Die Verbindung hat keine Zählfunktion, daher wird keine Zahl geschätzt.

Verfügbare Daten und Grenzen#

Lesbar sind Spielerlisten, einzelne Charakterdetails, deren Fahrzeuge, Bans und Erkennungslogs. QBCore/Qbox verwenden üblicherweise players und player_vehicles; ESX users und owned_vehicles. Spalten und Indizes müssen unterstützt sein. Eine ready-Verbindung bestätigt nicht die Lesbarkeit jeder eigenen Tabelle.

Inventare enthalten ausgewählte Felder, eine begrenzte gespeicherte Datenmenge und höchstens 100 besuchte Einträge. Beliebige Metadaten, Stashes und eigene Tabellen werden nicht vollständig gespiegelt. Ein gekürztes Inventar ist unvollständig; fehlende Einträge beweisen keinen fehlenden Besitz. Für vollständige Prüfungen die Inventarwerkzeuge des Spiels verwenden.

Status und Last beurteilen#

Im Leerlauf fragt die Bridge ungefähr alle zehn Sekunden das Panel ab, ohne die Spieldatenbank zu lesen. Es läuft jeweils ein Auftrag. Listen enthalten maximal 25 Ergebnisse pro Cursor-Seite. Zur nächsten Seite gehen statt ständig dieselbe Liste neu laden. Angeforderte Schema-Metadaten werden fünf Minuten zwischengespeichert.

• oxmysql_unavailable: Startreihenfolge und Verbindung prüfen.
• unsupported_framework / schema_unavailable: Framework, Tabellen und Spalten prüfen.
• unsupported_index: erforderlichen Schlüssel durch den Datenbankverantwortlichen prüfen lassen; Indizes nicht ungeprüft im laufenden Betrieb ergänzen.
• request_expired / veralteter Status: Verbindung und Auftragsalter vor einer weiteren Leseanfrage prüfen.

• Frameworks
• Leistung messen

Geldänderungen bewusst ausführen#

Das Ändern von Kontoständen online ist standardmäßig aktiv. Panelnutzer mit der Rolle admin oder owner (Wirtschaftsrecht) können Bargeld- oder Bankbetrag eines unterstützten Online-Charakters setzen, nachdem das Panel eine Bestätigungsübersicht gezeigt hat. Der Vorgang setzt einen absoluten Betrag, statt bei Wiederholungen Geld hinzuzufügen. Der erwartete bisherige Kontostand wird geprüft; stimmt er nicht, kommt stale_balance und nichts wird geändert. Jede Anfrage wird im Audit-Log protokolliert.

Offline-SQL ist kein Ersatzweg. Unklare Vorgänge bleiben zur Vermeidung automatischer Wiederholungen gespeichert. Geben Sie reinen Prüfern nicht die Rolle admin oder owner. Um Geldänderungen für einen Server zu stoppen, nutzen Sie „Disable connection“ auf seiner Tosun-Connect-Karte (das stoppt auch Lesezugriffe) oder den manuellen Modus mit set tosun_db_bridge_manual "1": Dann werden tosun_db_bridge_enabled und tosun_db_bridge_money_write aus der server.cfg gelesen und bleiben jeweils aus, solange sie nicht auf "1" stehen.

1. Aktuellen Charakter und Kontostand lesen, Zielbetrag prüfen, einmal ausführen.
2. Bei stale_balance erneut lesen und entscheiden: der Spieler könnte inzwischen Geld ausgegeben haben.
3. Bei unknown_outcome stoppen und Live-Kontostand sowie Protokolle prüfen; nicht vor Klärung erneut schreiben.

• API und Zugangsdaten

Gespeicherte Listen von Live-Charakterdetails unterscheiden#

Spielerlisten lesen gespeicherte Charakterzeilen; sie sind kein fortlaufender Live-Feed. Ein Charakterdetail kann gespeicherte Kontostände durch verfügbare Online-Werte des Frameworks ersetzen und aktuelle ox_inventory-Gegenstände dieses Spielers lesen. Wählen Sie die dauerhafte character_id, keine gemerkte Sitzungsnummer. Beachten Sie im Panel nicht verfügbare Kontostände und die Warnung zum unvollständigen Inventar, bevor Sie Nullwerte oder Vollständigkeit annehmen. Entwickler können die entsprechenden Flags balance_available und inventory_truncated prüfen. Fehlende Felder oder Teilinventare beweisen keinen Verlust. Fahrzeugergebnisse zeigen ausgewählte gespeicherte Felder; sie beweisen nicht, dass ein Fahrzeug gerade gespawnt ist oder zu einer aktiven Garagensitzung gehört.

1. Vergleichen Sie ein bekanntes Charakterdetail zu einem notierten Zeitpunkt mit dem Spiel, einschließlich Online-Status und Konto.
2. Prüfen Sie bei Abweichungen zuerst Identität, Listen- oder Detailabfrage sowie Verfügbarkeitsmarkierungen.
3. Fordern Sie nach Wiederverbindung oder Charakterwechsel ein neues Detail an, statt das vorherige Ergebnis weiterzuverwenden.

Untersuchungen paginieren statt Datenbanken abzurufen#

Pro Server erlaubt die Panelwarteschlange höchstens drei offene oder übernommene Aufträge und zwölf neue Anfragen pro Minute. Ein Auftrag gilt 120 Sekunden; Ergebnisse sind vorübergehend und ab fünf Minuten nach Ablauf des Auftrags zur Bereinigung geeignet, ohne garantierten Löschzeitpunkt. Das dient gezielter Verwaltung statt automatischer Vollerfassung. Nutzen Sie die Seitennavigation des Panels; Entwickler verwenden has_more und next_cursor nur für dieselbe Operation und denselben Charakter. Eine leere Folgeseite ist kein Abfragefehler. Eindeutige Schlüssel und Fahrzeugbesitzerindizes werden geprüft; ungeeignete Strukturen können sicher abgelehnt werden. Benennen Sie keine Produktivspalten um und ergänzen Sie keinen Index allein zur Fehlerunterdrückung, ohne Anwendung und Abfrageplan zu prüfen.

1. Lesen Sie jeweils eine Panelseite. Eigene Integrationen speichern Cursor und Operation zusammen und folgen nur bei has_more.
2. Warten Sie bei queue_full oder rate_limited auf offene Aufträge, statt Ansichten wiederholt zu öffnen.
3. Lassen Sie unsupported_index zuerst auf einer Kopie untersuchen; Metadaten können fünf Minuten zwischengespeichert bleiben.

Zugriff pausieren, ohne unsichere Vorgänge zu löschen#

Für reine Einsicht erhalten Mitarbeiter nur nötige Leserechte; Kontostände können nur die Rollen admin und owner ändern. Zum Stoppen öffnen Sie Server → den Server → Karte Tosun Connect und wählen „Disable connection“; damit enden alle Lesezugriffe und Geldänderungen für diesen Server, und dieselbe Karte schaltet die Verbindung wieder ein. Für Lesezugriff ohne Geldänderungen gibt es den manuellen Modus: Tragen Sie set tosun_db_bridge_manual "1" und set tosun_db_bridge_enabled "1" in die server.cfg ein und lassen Sie tosun_db_bridge_money_write weg oder auf "0". Im manuellen Modus werden beide Werte aus der server.cfg gelesen und bleiben jeweils aus, solange sie nicht auf "1" stehen; ohne set tosun_db_bridge_enabled "1" stoppt der manuelle Modus also auch die Lesezugriffe. Das Panel markiert offene und übernommene Aufträge fehlgeschlagen; übernommene Geldaufträge erhalten unknown_outcome, da eine Wirkung bereits eingetreten sein kann. Das spielseitige Vorgangsregister ist deshalb kein wegwerfbarer Cache. KVP-Daten für einen erneuten Versuch zu löschen kann die Belege gegen Wiederholung entfernen. Prüfen Sie auch Zugriff auf erfasste Spielerdaten: Die Bridge schützt keine öffentlich geteilten Screenshots oder Supportprotokolle.

1. Lassen Sie vor geplantem Abschalten Lesungen fertig werden und prüfen Sie unsichere Geldresultate mit Live-Kontostand und Auditdaten.
2. Kontrollieren Sie anschließend Panelstatus und tosunac_db_status; behandeln Sie neue Warteschlangenlesungen nicht als erfolgreich.
3. Beginnen Sie nach dem Wiedereinschalten auf der Karte mit einer Lesung; ändern Sie keine Kontostände, bis Rechte, Fähigkeiten und unsichere Vorgänge geprüft sind.

# Server console / Sunucu konsolu:
tosunac_db_status

Schemakompatibilität ohne Änderung von Spielerdaten prüfen#

Prüfen Sie bei schema_unavailable oder unsupported_index zuerst, ob die tatsächlich vom Spiel verwendete Datenbank ausgewählt ist. Das folgende Beispiel liest ausschließlich Spaltennamen und Datentypen; Guthaben, Inventare und Fahrzeuge bleiben unverändert. Dies ist kein notwendiger Installationsschritt. Ein berechtigter Datenbankadministrator kann die Abfrage bei der Fehlersuche in seinem vorhandenen privaten Datenbankwerkzeug ausführen. Senden Sie keinen SQL-Text an die Panel-Brücke; sie akzeptiert nur festgelegte Vorgänge.

Spielerabfragen unter QBCore/Qbox benötigen citizenid, money, job und charinfo in players; ESX benötigt identifier, accounts und job in users. Eine vorhandene Tabelle genügt nicht. Der Charakterschlüssel muss einen unterstützten Typ sowie einen eindeutigen Index über eine vollständige einzelne Spalte besitzen.

Fahrzeugabfragen prüfen außerdem die passende Indexstruktur für Besitzer und Fahrzeugschlüssel. Dadurch werden aufwendige Abfragen nicht erzwungen. Benennen Sie eine Tabelle eines individuellen Garagenscripts nicht einfach um; lassen Sie zunächst die Entwickler von Framework und Garage die Kompatibilität prüfen.

• Notieren Sie Fehlercode, Framework-Version und betroffenen Lesevorgang.
• Vergleichen Sie Spalten und Indizes; senden Sie keine Spielerzeilen an den Support.
• Bewerten Sie Änderungen zuerst in einer Testkopie. Der Schemacache der Brücke erkennt eine neue Struktur möglicherweise nicht sofort.

SELECT TABLE_NAME, COLUMN_NAME, COLUMN_TYPE
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME IN ('players', 'users', 'player_vehicles', 'owned_vehicles')
ORDER BY TABLE_NAME, ORDINAL_POSITION
LIMIT 128;

Der Charakter erscheint, die Fahrzeugliste bleibt leer#

Ein Charakter aus der Spielerliste lässt sich öffnen, seine Fahrzeugliste ist jedoch leer. Unterscheiden Sie zuerst ein erfolgreich abgeschlossenes Ergebnis von einem fehlgeschlagenen Auftrag. Eine erfolgreiche leere Liste bedeutet, dass diese Abfrage keine passenden Datensätze geliefert hat. Sie beweist nicht, dass der Spieler in keinem System ein Fahrzeug besitzt. query_failed, schema_unavailable und unsupported_index sind keine leeren Listen.

Prüfen Sie die Auswahl anhand derselben dauerhaften character_id. Eine nach dem erneuten Verbinden wechselnde Sitzungsnummer ersetzt den Charakterschlüssel nicht. QBCore/Qbox verwendet player_vehicles.citizenid als Besitzer; ESX verwendet owned_vehicles.owner. Eine individuelle Garage mit anderer Tabelle oder anderem Besitzerformat wird von der Standardbrücke nicht automatisch entdeckt.

Auch ein falsch ausgewählter Charakter eines Kontos mit mehreren Charakteren kann diese Anzeige erklären. Lassen Sie den berechtigten Garagenadministrator den Spiel-Datensatz eines bekannten Fahrzeugs prüfen. Guthabenänderungen über die Brücke, das Neuerstellen von Fahrzeugen oder das Leeren der Quelltabelle sind zur Diagnose unnötig.

• Notieren Sie Server-ID, maskierte Charakterreferenz, Zeitpunkt und Auftragsstatus.
• Laden Sie weitere Seiten nur im selben Charakterkontext; übertragen Sie keinen Cursor auf einen anderen Charakter.
• Melden Sie dem Support ein erfolgreich leeres Ergebnis oder den genauen Fehlercode; entfernen Sie persönliche Spielerdaten.

Zahlen, Text und nicht verfügbare Felder unterscheiden#

Die Brücke zeigt keine unveränderte Datenbankzeile; unterstützte Felder werden auf bestimmte Typen und Längen normalisiert. Charaktergeld wird aus JSON-Zahlen gelesen. Beispielsweise unterscheiden sich 1200 und "1200" als gespeicherte Typen. Wandelt ein eigenes Script Geld in Text um, kann die Balance als nicht verfügbar erscheinen. Ein nicht verfügbarer Betrag wird im Panel als — angezeigt; das bedeutet keinen Nullsaldo. Beim Inventar werden Name, Bezeichnung, Anzahl, Slot und Qualität ausgewählt; beliebige Metadaten, Stash-Inhalte oder Geschäftskonten gehören nicht dazu.

Ausgewählte Fahrzeugwerte wie Kraftstoff, Motor und Zustand können als Text zurückkommen; das Format allein erlaubt keinen Zahlenvergleich. Die char/varchar-Schemalänge unterstützter Charakterschlüssel ist höchstens 96; der übertragene Textschlüssel ist zusätzlich auf 96 Bytes begrenzt, was bei Mehrbytezeichen abweicht; int, bigint und mediumint werden ebenfalls unterstützt. Eigene Binärschlüssel sind nicht automatisch Standard. Lange Texte und Inventar können gekürzt werden; fehlende Ausgabe bedeutet keine Löschung. Lassen Sie das tatsächliche Quellformat vor der Diagnose bestätigen. Bewerten Sie nötige Typumwandlungen anhand des Datenvertrags des Spiels in einer Testumgebung, statt Produktionsdaten nur für eine gefüllte Anzeige zu verändern.

Eine Geldänderung mit einem konkreten Beispiel abnehmen#

Für eine autorisierte und bestätigte Korrektur soll das Bargeld eines Online-Charakters beispielsweise von 1200 auf 1250 steigen. Der endgültige Zielbetrag ist 1250; die Eingabe 50 setzt den Bestand auf fünfzig statt fünfzig hinzuzufügen. Prüfen Sie Bargeld- oder Bankkonto und vergleichen Sie die dauerhafte Charakteridentität mit aktuellen Live-Details. Die Bestätigung nennt Charakter, Konto und Wechsel vom aktuellen zum neuen Gesamtbetrag. Der Betrag ist ein nicht negativer ganzzahliger Endwert; eigene Währungen und Geschäftsguthaben sind kein Ersatz für dieses Verfahren.

Der Warteschlangeneintrag schließt die Abnahme nicht ab. Prüfen Sie beim abgeschlossenen Ergebnis denselben Charakter und dasselbe Konto mit before=1200 und after=1250. Lesen Sie anschließend den aktuellen Charakterzustand normal aus. Zwischenzeitliche Ausgaben können ihn verändern; ein abgeschlossenes Ergebnis rechtfertigt keine automatische Wiederholung. Bei stale_balance ist die überholte Annahme, bei unknown_outcome die unbestätigte Wirkung zu untersuchen. Notieren Sie Auftragsreferenz, Uhrzeit und bereinigtes Ergebnis. Bei Unsicherheit keinen neuen Schreibauftrag senden, bevor tatsächlicher Bestand und Korrekturabsicht neu bewertet sind.

Eine Antwortfrist bricht SQL nicht ab#

Die Standard-Wartezeit auf eine SQL-Antwort beträgt 5.000 ms. query_timeout beendet das Warten des Panels; die eigentliche Abfrage kann weiterlaufen. Die SQL-Kapazität bleibt bis zum ersten echten Callback belegt, und eine weitere Abfrage liefert query_busy. Eine verspätete Antwort ändert die vorherige Ansicht nicht. Kommt kein Callback, gibt die Frist die Kapazität nicht automatisch frei. Der Serveradministrator sollte Verbindung und Datenbank prüfen; ein Neustart der Resource beweist nicht, dass SQL abgebrochen wurde.

Nur der Serverbesitzer kann bei Bedarf die folgende set-Zeile in server.cfg ergänzen. Der Wert wird auf 1.000–10.000 ms begrenzt; eine ungültige oder unendliche Zahl ergibt 5.000 ms. Diese Einstellung beschleunigt SQL nicht und wiederholt Abfragen nicht automatisch.

Die Online-Bearbeitung von Kontoständen ist für Panelbenutzer mit der Rolle Admin oder Owner (Wirtschaftsberechtigung) standardmäßig aktiv; im manuellen Modus (set tosun_db_bridge_manual "1") bleibt sie aus, solange tosun_db_bridge_money_write nicht "1" ist. Sie erfordert einen unterstützten Online-Charakter und eine Bestätigung im Panel. Der Vorgang ersetzt nur den Bargeld- oder Bankbetrag nach Prüfung des erwarteten aktuellen Kontostands; er weicht nie auf Offline-SQL-Schreibvorgänge aus. unknown_outcome oder eine unklare Verbindung wird nie automatisch wiederholt. Prüfen Sie vor einem weiteren Schreibvorgang den Live-Kontostand und die Audit-Einträge; löschen Sie keine KVP-Einträge unsicherer Vorgänge, um eine Wiederholung zu erzwingen.

set tosun_db_bridge_query_timeout_ms "5000"

Eine SQL-Datei in die richtige Datenbank importieren#

Der neue Download enthält tosun-ac/INSTALL.sql als einzigen SQL-Import. Keine zweite alte Kopie desselben Schemas importieren. Ziel ist die FiveM/oxmysql-Spieldatenbank, nicht die Konten- oder Theme-Datenbank der gemieteten Website. Fehlende alte Spalten werden vor Standardwerten ergänzt; Sperren und eigene Einstellungen bleiben erhalten.

1. Spieldatenbank sichern und ihren Namen mit oxmysql vergleichen.
2. Nur INSTALL.sql in HeidiSQL/phpMyAdmin importieren oder die Zieldatenbank ausdrücklich im mysql-Befehl nennen.
3. tosunac_db_check prüft eine Abfrage, tosunac_db_status den Brückenstatus. Die Brücke ist standardmäßig aktiv und braucht keine server.cfg-Zeile. enabled=false ist korrekt im manuellen Modus (set tosun_db_bridge_manual "1") ohne tosun_db_bridge_enabled "1" oder wenn der alte vollständige Mirror (ts.panelMirror.enabled = true in configs/anticheat_config.lua) bewusst aktiviert ist; eine Lizenz ersetzt keine Datenbankverbindung.
4. Panel-Verbindung (Tosun Connect) und Bearbeitung des Online-Kontostands sind standardmäßig aktiv. tosun_db_bridge_enabled und tosun_db_bridge_money_write nicht in server.cfg eintragen; alte Zeilen werden ab Paket 9.6.14 ignoriert und können gelöscht werden (ältere Pakete brauchen sie weiterhin, bis das aktuelle Paket installiert ist). Kontostände setzen nur Panel-Nutzer mit der Rolle admin oder owner: Der Charakter muss online sein, der erwartete Kontostand muss stimmen (sonst stale_balance, nichts ändert sich), das Panel zeigt vor dem Senden eine Zusammenfassung zur Bestätigung, jede Anfrage steht im Audit-Log, ein unklares Ergebnis wird nie automatisch wiederholt; zuerst den Kontostand im Spiel prüfen. Gesetzt wird der Gesamtbetrag, nichts wird addiert. Die ganze Verbindung für einen Server abschalten (das stoppt alle Lesezugriffe des Panels und alle Kontostandsänderungen): Panel → Server → Server wählen → Karte Tosun Connect → Disable connection; über dieselbe Karte lässt sie sich wieder einschalten. Passwort nur auf dem Spielserver speichern.

mysql -u YOUR_DB_USER -p YOUR_GAME_DATABASE < tosun-ac/INSTALL.sql

# txAdmin console:
tosunac_db_check
tosunac_db_status