QBCore Anticheat-Einrichtung: Abhängigkeiten und Akzeptanztests

Abhängigkeiten, Charakter- und Waffenverhalten, Paneldaten und Freigabe auf qb-core prüfen.

Ein laufender Core bestätigt nicht dieselbe API jedes Bank-/Inventarskripts. Bestehende Umgebung erhalten und Integration prüfen.

Prüfpunkte dieser Installation

• qb-core gestartet; AC-Wert qb oder geprüftes auto.
• citizenid von temporärem source unterscheiden.
• Inventarwaffen und Arenawaffen getrennt prüfen.
• Eigene Geld-/Item-Events prüfen Rechte, Menge und Kontext auf dem Server.

Installation und Freigabe

1. Konto über Sign up erstellen, E-Mail bestätigen und Zahlung des passenden kostenpflichtigen Tarifs prüfen.
2. Richtigen Server wählen, Ressource/Einstellungen/Spieldatenbank sichern und dessen Paket laden.
3. Nach tosun-ac entpacken; Lizenz nur in server.cfg mit set speichern.
4. Bestehende Abhängigkeiten erhalten, passendes AC-Framework-Feld setzen und während Wartung starten.
5. Akzeptanztests mit Testcharakter durchführen; Version, Datum und Ergebnisse notieren.

Beispiel für server.cfg

set tosun_ac_license "YOUR_SERVER_LICENSE"

ensure oxmysql
ensure qb-core
ensure tosun-ac

Das Ergebnis beurteilen

• Startmeldungen zeigen installierte Version und tatsächliches Framework.
• Legitime Abläufe erzeugen keine unerwartete Strafe oder dauerhafte Ausnahme.
• Paneldaten gehören zum richtigen Server und Charakter; Grenzen sind benannt.
• Leistungs- und Fehlalarmprüfung nutzen typische Spielsituationen.

QBCore-Wert und Datenumfang

Vorhandenes ts.Framework.framework in configs/anticheat_config.lua auf qb setzen, übrige Tabelle erhalten. Mit ox_inventory funktionierende Abhängigkeiten und Kompatibilität erhalten. Waffenprüfung bevorzugt aktives ox_inventory; ein API-Ausfall beweist keinen fehlenden Waffenbesitz.

Charakter und Wirtschaft prüfen

Bridge liest unterstützte Felder/Indizes aus players per citizenid und player_vehicles. Kein vollständiges Bank- oder Stash-Spiegelbild. Verbindung und Kontostandsbearbeitung sind standardmäßig aktiv, ohne eigene server.cfg-Zeile; alte Zeilen tosun_db_bridge_enabled und tosun_db_bridge_money_write werden ignoriert, solange der manuelle Modus aus ist. Nur Panelnutzer mit Rolle admin oder owner setzen den Stand, nur bei Online-Charakter und passendem erwartetem Stand; zuerst Lesedaten prüfen. Für diesen Server abschalten: Disable connection auf der Karte Tosun Connect (Server → gewünschter Server). Erweitert: Mit set tosun_db_bridge_manual "1" in server.cfg werden diese beiden Zeilen wieder aus server.cfg gelesen, und jede bleibt aus, wenn sie nicht "1" ist; die manual-Zeile allein schaltet Verbindung und Kontostandsbearbeitung ab, manual "1" plus enabled "1" lässt das Lesen an und die Bearbeitung aus.

1. Testcharakter mit bekanntem Job, Bargeld, Bank und Fahrzeug verbinden.
2. Bridge ist standardmäßig aktiv: einen Charakter im Panel lesen und mit Spiel vergleichen.
3. Charakter wechseln, erneut lesen und alte Kennung/source ausschließen.
4. Häuser, Garagen, Polizei und Arenawaffen ohne Inventar testen.
5. Eigene Belohnung muss freie Clientmengen und fremde Spieler ausschließen.

Eine wiederherstellbare Installation vorbereiten

Notieren Sie vor einer Änderung die Artifact-Version sowie Framework- und Inventar-Ressourcen. Laden Sie das Paket für den in Servers ausgewählten Server herunter. Ein fremdes Paket oder eine andere Lizenz kann die falsche Installation verbinden. Prüfen Sie das bezahlte Abonnement und Ihre Verwaltungsberechtigung. Halten Sie die ZIP-Datei privat.

1. Sichern Sie das aktuelle Verzeichnis tosun-ac, die bearbeitbaren Einstellungen und die Spieldatenbank. Prüfen Sie vor dem Austausch den Zugriff auf die Sicherung.
2. Entpacken Sie separat. fxmanifest.lua muss direkt unter tosun-ac liegen, nicht in einem zweiten verschachtelten Verzeichnis.
3. Vergleichen Sie Ihre Änderungen mit den neuen Standardwerten. Übernehmen Sie gezielte Anpassungen; ersetzen Sie die neue Konfiguration nicht vollständig durch die alte.

Teleport unmittelbar vorher melden

Spieler, serverseitiges Ziel, Berechtigung und aktive Tätigkeit prüfen. MarkTeleport direkt vor dem Versetzen aufrufen. src und destination stammen aus dem bestehenden geprüften Serverablauf, nicht frei wählbaren Clientdaten. Das Fragment ist kein fertiges Netzwerk-Event.

Keine Vertrauensliste nötig. Kurzzeitige Lockerung für Bewegung und zugehörige Sichtbarkeit/Godmode/Kamera; Waffen, Geld, Eventmissbrauch und Injection bleiben geprüft. Bei den Standardeinstellungen gelten für Ressourcen außerhalb der Vertrauensliste: maximal 15 Sekunden je Aufruf und 180 Sekunden je Spieler in zehn Minuten. Verlängerungen verbrauchen Budget; nicht jeden Tick erneut aufrufen.

-- Innerhalb eines bereits geprüften Serverablaufs:
local ok = exports["tosun-ac"]:MarkTeleport(src, 8000, "house_enter")
if ok then
    SetEntityCoords(GetPlayerPed(src), destination.x, destination.y, destination.z)
end

Vergleichbare Ausgangsmessung

Profilieren Sie vor Änderungen eine typische Sitzung. Notieren Sie Spielerzahl, Artifact, Ressourcenversionen und Aktivitäten. Ruhiges Rollenspiel, volle Garagen und Gefechte unterscheiden sich. Vergleichen Sie nach einer einzelnen Änderung denselben Ablauf. CPU-Zeit, Hitches und Abfragen sind aussagekräftiger als feste FPS-Versprechen.

Die Befehle zeichnen eine begrenzte Probe auf. Nach Abschluss öffnen und die verursachende Ressource und den Thread prüfen. Nicht jeden Hitch der AC zuordnen. Geänderten Wert und Vorher/Nachher privat notieren; kurze Proben decken nicht jede Spitzenlast ab.

profiler record 500
profiler status
profiler view

tosunac_doctor

Strafen mit Kontext bewerten

Kontextabhängige Prüfungen erst beobachten und normales Spielen testen. Ein Logsignal ist kein pauschaler Bannauftrag. Charakterwahl, Wiederbelebung, Teleports, Polizeiausrüstung und Skriptwaffen prüfen. Gezielte Integration statt dauerhafter Gesamtausnahme.

tosunac_doctor zeigt riskante effektive Werte, verändert nichts. Warnungen zu harten Strafen, ausgeschalteten Sicherungen, Debug und Fail-open prüfen. Panelwerte können lokale Defaults überschreiben; aktive Werte beurteilen.

Ausnahmen oder mildere Aktionen können Beschwerden verbergen, ohne Ursachen zu lösen. Temporäre Ausnahmen mit Datum und betroffenem Skript notieren. Nach geprüfter Integration Ausnahme entfernen und denselben Spielablauf samt Logs vergleichen.

• Ein Wert pro Änderung; Grund, Prüfer und vorherigen Wert notieren.
• Wiederholte Signale mit legitimen Aktionen und Zeiten abgleichen.
• Nach Strafen-, Core- oder Inventaränderung erneut testen.
• Bei neuen Fehlalarmen zurücksetzen und Ursache vor erneutem Verschärfen beheben.

Updates, Wiederherstellung und Support

Nach Änderungen an Core, Inventar, Jobs oder AC die betroffenen Tests wiederholen. Schema, Strafe und Version nicht zusammen ändern. Bei neuem Fehler gesicherte Ressource und Werte in Wartung zurücksetzen; Datenverlust vor Datenbankwiederherstellung prüfen. Support benötigt Versionen von Artifact/Core/Inventar/AC, Ressourcenname, Schritte, Zeit und erste bereinigte Fehlermeldung. Spielerkennungen, Lizenzen, Passwörter und Tokens nicht öffentlich teilen.

Weitere Installationsdetails

Installationsdokumentation · Datenbank-Bridge · Server-Exports

Sign upDokumentation Preise ansehen

Häufige Fragen

Verwandt: ESX · Standalone · vRP · OX/Qbox · Alle Framework-Leitfäden · RedEngine-Erkennung