vRP / vRPex Anticheat-Einrichtung: Abhängigkeiten und Akzeptanztests

Allgemeine AC, reale Ressourcennamen, Rechte und eigene Wirtschaft bei vRP prüfen.

vRP-Forks unterscheiden sich in Ordnern, Proxy/Tunnel und Schema. Allgemeine Integration, kein vollständiger automatischer Wirtschaftsadapter.

Prüfpunkte dieser Installation

• Core- und Treibernamen bestimmen.
• AC-oxmysql vorbereiten, alten Treiber nicht beliebig ersetzen.
• Gültigen standalone-Modus ohne Spezialadapter verwenden.
• user_id, source und Rechte im eigenen Servercode prüfen.

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
# Bestehende Startzeilen für vRP-Core und Treiber hier erhalten.
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.

Tatsächlichen Ressourcennamen verwenden

Funktionierende vRP-Startzeilen beim Kommentar erhalten. Bei anderem Ordner nicht einfach ensure vrp hinzufügen. Für allgemeine Prüfungen ausdrücklich standalone verwenden. Ein automatisch erkanntes vrp beweist keinen vollständigen Wirtschafts- oder Inventaradapter. vRP-Treiber und AC-oxmysql getrennt beurteilen.

Rechte und Vorgänge prüfen

Proxy/Tunnel allein erlaubt keine Belohnung oder Teamaktion. Eigene Ressource prüft user_id gegen source, Gruppe/Job und Servervorgang.

1. Spawn, Krankenhaus und Garage mit Testspieler prüfen.
2. Legitime Teleports kurz mit MarkTeleport melden.
3. Skriptwaffen mit trusted AllowWeapon behandeln.
4. Unberechtigte Gruppenmitglieder dürfen sensible Events nicht ausführen.
5. Eigener Vorgang verhindert doppelte Belohnung bei wiederholten/parallelen Aufrufen.

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