ESX Anticheat-Einrichtung: Abhängigkeiten und Akzeptanztests

Charakter-, Konto-, Inventar-, Spawn- und Jobabläufe auf es_extended prüfen.

Legacy und alte Forks können unterschiedliche Tabellen oder APIs haben. Der Name allein garantiert keine vollständigen Wirtschaftsfunktionen.

Prüfpunkte dieser Installation

• es_extended läuft; ts.Framework.framework ist esx.
• identifier, source und Charakterauswahl separat prüfen.
• Kontoschema unterstützen; unbekannte Daten sind kein Nullsaldo.
• Krankenhaus, Polizei, Garage und Skriptwaffen testen.

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 es_extended
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.

Konten und ESX-Schema

Bridge erwartet identifier, accounts und job in users sowie owned_vehicles. Bargeld entspricht ESX money, Bank bank. Eigene Konten/JSON können verweigert werden; das beweist keinen leeren Kontostand. Kontostandsbearbeitung für Online-Charaktere ist standardmäßig aktiv, nur für Panelnutzer mit Rolle admin oder owner; erst nach geprüften Lesedaten bearbeiten. Sie setzt den Gesamtbetrag und addiert nicht; passt der erwartete Stand nicht (stale_balance), ändert sich nichts. Alte Zeilen tosun_db_bridge_enabled und tosun_db_bridge_money_write werden ignoriert, solange der manuelle Modus aus ist; abschalten mit 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.

ESX-Akzeptanztest

Bei ox_inventory ESX-Adapter und Abhängigkeiten erhalten. Waffenbesitz benötigt hasWeapon oder gültige Inventarantwort; API-Ausfall beweist kein fehlendes Waffenitem.

1. Echten identifier und Online-Testspieler prüfen.
2. Ein Cash-/Bank-/Jobergebnis mit Spiel vergleichen.
3. Waffe, Ablegen, Polizei und Charakterwechsel testen.
4. Wiederbelebung und Haus-/Garagenteleports prüfen, gegebenenfalls MarkTeleport integrieren.
5. Eigene Shops/Belohnungen prüfen Preis, Rechte, Menge und Wiederholungen im Servercode.

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: QBCore · Standalone · vRP · OX/Qbox · Alle Framework-Leitfäden · RedEngine-Erkennung