Zur Anleitung

Dokumentation 9.6.24

Framework-Einstellungen

Vor Integrationen das verwendete Framework und Inventar prüfen.

QBCore und ESX#

Die Bridge unterstützt nur bestimmte Schemas und indexierte Felder. Fehlende Spalten oder eigene IDs können Abfragen verhindern. Eine leere oder nicht unterstützte Antwort bedeutet nicht, dass die Datenbank leer ist.

Eigene Abläufe#

Charakterwahl, Jobs, Teleports und Garagen auf einem Testserver prüfen. Berechtigungen auf dem Server validieren. Eng begrenzte Ausnahmen nur durch vertrauenswürdigen Server-Code gewähren.

Framework und Inventar getrennt bestimmen#

Ermitteln Sie die Ressource für den Spielerzustand: qb-core, qbx_core oder es_extended. Prüfen Sie danach Inventar und API-Anpassungen. Ein Frameworkname garantiert keine Kompatibilität aller Bank-/Inventarskripte. Abhängigkeitsreihenfolge beibehalten und keine konkurrierenden Cores als Fehlerbehebung starten.

Das vorhandene Framework-Feld bearbeiten: qb für QBCore, qbox für Qbox; das sind Einstellungswerte, keine Ordnernamen. auto bietet Erkennung. Aufgelösten Modus in Startmeldungen und GetStatus aus Servercode prüfen. Die Bridge erkennt laufende Core-Ressourcen separat und kann fehlende Starts melden.

-- Vorhandenes Feld bearbeiten, nicht die ganze Tabelle.
ts.Framework.framework = "qb"
-- Weitere unterstützte Werte: "esx", "qbox", "auto", "standalone"

Charakterdaten gezielt prüfen#

Bridge-Lesezugriffe verwenden citizenid bei QBCore/Qbox und identifier bei ESX. Temporäre Server-IDs ersetzen keine Charakterkennung. Unterstützte Spalten und Indizes sind nötig; eigene Schemas können abgelehnt werden.

  1. Testcharakter mit bekanntem Bargeld, Bankbetrag, Job und Fahrzeug mit dem Panel vergleichen.
  2. Bei ox_inventory ein kleines Online-Inventar vergleichen. Kürzungen beachten; keine Stashes oder beliebigen Metadaten erwarten.
  3. Bei API-Fehlern Start und Version prüfen. Unverfügbare APIs bedeuten unbekannten Waffenbesitz, nicht bewiesenen fehlenden Besitz.

Echte Spielabläufe testen#

Frameworkerkennung kennt nicht jede eigene Berechtigung, Position, Preis- oder Belohnungsregel. Eigene Skripte müssen diese serverseitig prüfen. Ein Profil macht unsichere Geld-/Item-Events nicht automatisch sicher. Spielerquelle und aktive Serversitzung vor dem AC-Aufruf prüfen.

Standalone/vRP können geeignete allgemeine Prüfungen nutzen; die Bridge unterstützt ihre eigenen Charakter- und Wirtschaftsschemas nicht pauschal. Grenzen erklären statt fremde Tabellen einzusetzen. Nach Core-, Inventar- oder Jobupdates erneut prüfen.

Core- und Inventarversion je Test notieren. Nach Core-Neustart Testcharakter neu verbinden, bevor Online-API-Ergebnisse bewertet werden. Schema und AC-Strafe nicht zugleich ändern; getrennte Änderungen erlauben Ursachenprüfung und Rückkehr.

  • Charakterwechsel und Wiederbelebung hinterlassen keine dauerhafte Ausnahme.
  • Haus-, Garage- und Gefängnisteleports rufen MarkTeleport unmittelbar vorher auf.
  • Arenawaffen ohne Inventareintrag erhalten kurz AllowWeapon aus vertrauenswürdigem Servercode.
  • Polizei, Teamwerkzeuge, Shops und große legitime Belohnungen vor strengeren Strafen anhand von Logs testen.

Konfigurationsnamen und erkannte Core-Namen einordnen#

AC-Konfiguration und Datenbankconnector nutzen teilweise unterschiedliche Bezeichnungen: QBCore wird als qb konfiguriert, im Bridge-Status jedoch als qbcore gemeldet. Qbox nutzt qbox und die laufende Resource qbx_core. Lesen Sie Bezeichnungen im jeweiligen Zusammenhang, statt sie an Ordnernamen anzupassen. Automatische Einrichtung kann vrp oder ox_core erkennen und entsprechende Namen setzen; dadurch entsteht kein unterstützter Charakter- oder Wirtschaftsadapter für die Datenbankbridge. Bei einem nicht unterstützten Core vermeidet die ausdrückliche Einstellung standalone für allgemeinen Schutz, einen erkannten Namen als vollständige Integration zu verstehen.

  1. Prüfen Sie configs/anticheat_config.lua und den tatsächlich laufenden Core; behalten Sie eine bewusste Wahl und die Abhängigkeitsreihenfolge.
  2. Prüfen Sie bei abweichenden Panelfähigkeiten laufende Core-Resources und Bridge-Zustand, statt AC-Einstellungen blind umzubenennen.
  3. Starten Sie nicht qb-core, qbx_core und es_extended gemeinsam, nur um eine andere Statusbezeichnung zu erhalten.

Abnahmetests nach tatsächlichen Rollen aufbauen#

Testen Sie normale Spieler, Polizei oder andere Berufe und Mitarbeiter getrennt. Mitarbeiter können legitime Ausnahmen haben; prüfen Sie grundlegende Abläufe auch mit einem normalen Charakter. Berücksichtigen Sie Beitritt, Charakterauswahl, Tod und Wiederbelebung, Häuser, Garagen, Inventarwaffen und tatsächliche Berufsbelohnungen. Notieren Sie erwarteten Ort, Gegenstand oder Kontoeffekt sowie beobachtete Protokolle. Testen Sie bei Menüs und Aktivitäten sowohl Abschluss als auch Abbruch. Ein sauberer Start beweist nicht, dass ein angepasstes Inventar, Bankskript oder eine Charakterauswahl die erwarteten APIs verwendet.

  1. Wiederholen Sie dieselben kleinen Tests vor und nach Core- oder Inventarupdates; ändern Sie jeweils nur eine Komponente.
  2. Notieren Sie bei Fehlern Core- und Inventarversion, aufrufende Resource und Spielerrolle; halten Sie Identitätsdaten privat.
  3. Verbinden Sie nach Neustart oder Charakterwechsel neu und prüfen Sie das Ende temporärer Ausnahmen, nicht nur Mitarbeiterabläufe.

Verantwortung für angepasste Skripte festlegen#

Trennen Sie Erkennungseinstellungen von den Regeln Ihrer Spielskripte. Das AC kennt weder zulässige Empfänger eigener Banktransfers noch Belohnungsgrenzen oder Hausbesitzer. Die verantwortlichen Resources müssen Spieler, Rechte und serverseitigen Zustand vor Geld-, Gegenstands- oder Positionsänderungen prüfen. Inventarwaffenprüfungen verwenden unterstützte APIs; eine fehlende API bedeutet unbekannt, nicht nachgewiesenes Spawnen. Scheitern Charakterabfragen an Spalten oder Indizes, untersuchen Sie Kompatibilität getrennt von Sanktionen. Bestrafen Sie keine Spieler für Integrationsfehler und ersetzen Sie fehlende Adapter nicht durch breite Ausnahmen.

  1. Benennen Sie einen Verantwortlichen für Framework- oder Inventaradapter und klare Betreuer für eigene Aktionen.
  2. Reproduzieren Sie eine erlaubte Aktion und einen abgelehnten Berechtigungsweg mit der Validierung des Spielskripts.
  3. Trennen Sie allgemeinen AC-Betrieb von der Panel-Datenbankbrücke (Tosun Connect); eigene Tabellen brauchen geprüfte Integrationsarbeit.

Waffeninventar und Charakterdetails getrennt lesen#

Framework und Inventaranbieter können verschieden sein: QBCore verwaltet Charaktere und Geld, ox_inventory die Gegenstände. Waffenbesitzprüfung bevorzugt laufendes ox_inventory, andernfalls unterstützte QBCore/Qbox- oder ESX-APIs. Charakterdetails im Panel stammen aus einer getrennten Bridge-Operation. Ein sichtbarer Gegenstand beweist nicht dieselbe Quelle, Zeit und Form jeder Waffenprüfung. Ein anderer Framework-Name synchronisiert angepasste Waffenlager nicht.

ESX-Loadout und Item-Inventaranzahl sind unterschiedliche Konzepte. nil, Fehler oder unerwartete API-Daten beweisen keine Abwesenheit. Prüfen Sie die unterstützte Methode und notieren Sie Ausgabezeit, normale Spieleraktion, Inventaranbieter und Ergebnis. Eine geprüfte AllowWeapon-Integration kann legitime serverseitige Waffen außerhalb des Inventars im nötigen Umfang abdecken. Das ist eine Kompatibilitätsprüfung, keine Zusage, dass alle Erkennungsfehler behoben sind.

Core-Wechsel über Tabellenumbenennung hinaus planen#

Ein Wechsel zwischen QBCore und ESX ist mehr als ein Name. Die Bridge verwendet players/citizenid für QBCore und users/identifier für ESX. Alte Sitzungsnummer oder Anzeigename identifizieren keinen migrierten Charakter. Geld, Fahrzeugbesitz, Inventar und eigene Regeln können abweichen. Benennen Sie keine Produktionstabellen nur für Panelabfragen um. Die Datenmigration gehört zum Spielserverplan; AC ist kein allgemeines Konvertierungswerkzeug.

Wählen Sie im getrennten Testsystem einen bekannten Charakter und Fahrzeugdatensatz. Erfassen Sie Core, dauerhafte Identität, cash/bank und Onlinestatus vor einer kleinen Abfrage. Schema- oder Indexfehler beweisen keinen Datenverlust. Lassen Sie Kompatibilität vom Betreuer prüfen. Kontostandsänderungen im Panel sind standardmäßig aktiv; nutzen Sie sie bis zur Abnahme nicht. Technisch sperren Sie sie im manuellen Modus: set tosun_db_bridge_manual "1" und set tosun_db_bridge_enabled "1" in server.cfg, ohne tosun_db_bridge_money_write. Testen Sie Charakterauswahl und normale Inventaraktionen erneut. Akzeptieren Sie richtige Daten beim richtigen Charakter statt nur einen gestarteten Resource.