vRP / vRPex Anticheat Setup: Dependencies and Acceptance Checks

General AC setup, actual resource names, permission checks and custom economy validation for vRP forks.

vRP, vRPex and custom forks can differ in folders, Proxy/Tunnel interfaces and schema. This guide covers general AC integration, not an automatic complete vRP economy adapter.

What to verify in this installation

• Identify real vRP core and database driver names.
• Prepare AC’s own oxmysql dependency without randomly replacing the existing driver.
• Use a valid standalone AC mode where there is no specific adapter.
• Validate user_id, temporary source and character/permission context in your server code.

Installation and activation order

1. Create your account with Sign up, verify email and check payment for the appropriate paid plan.
2. Select the correct server in Servers, back up resource/settings/game database and download that server’s package.
3. Extract into tosun-ac and keep the license only in server.cfg using set.
4. Preserve existing dependency order, set the suitable AC framework field and start during maintenance.
5. Complete the acceptance checks with a test character; record version, date and results.

Starting server.cfg example

set tosun_ac_license "YOUR_SERVER_LICENSE"

ensure oxmysql
# Keep your existing vRP core and driver start lines here.
ensure tosun-ac

How to assess the result

• Startup identifies the installed version and actual framework.
• Legitimate workflows create neither unexpected punishment nor a lasting exemption.
• Panel data belongs to the correct server and character; unsupported capabilities are identified separately.
• Performance and false-positive review use representative gameplay.

Start with the actual resource name

Preserve the working vRP dependency lines where the example has a comment. Do not add ensure vrp if your folder has another name. Use explicit standalone for general protection. An auto-detected vrp label does not prove that a complete vRP economy or inventory adapter exists. Assess the existing vRP driver separately from AC’s oxmysql requirement.

vRP permission and custom-operation test

Having a Proxy/Tunnel call does not authorize rewards or staff actions. Your resource validates persistent user_id against current source, group/job permission and server-owned operation state.

1. Test spawn, hospital and garage with a controlled player.
2. Notify legitimate teleports briefly with MarkTeleport.
3. For a non-inventory script weapon use AllowWeapon from a validated trusted resource.
4. Check in staging that an unauthorized group member cannot run the sensitive event.
5. Your transaction code must prevent duplicate rewards from repeated or simultaneous calls.

Prepare a recoverable installation

Before changing a working server, record its artifact, framework and inventory resource names. Download the package for the exact server selected in Servers; another server’s package or license can connect the wrong installation. Confirm the paid subscription and that your account can manage this server. Keep the ZIP private rather than uploading it to a public file host.

1. Back up the current tosun-ac directory, editable configuration and game database. Check that the backup can be accessed before replacing anything.
2. Extract the new package into a separate directory. Check that fxmanifest.lua sits directly inside tosun-ac, not inside a second nested tosun-ac directory.
3. Compare editable settings with the new defaults. Carry over intentional changes and integrations; do not replace the whole new configuration with an old copy.

Notify a legitimate teleport at the correct point

Validate the player, server-owned destination, permission and active activity before the movement. Call MarkTeleport immediately before changing position, as in the integration fragment below. src and destination must come from your existing validated server workflow, not arbitrary client parameters. This fragment is not a standalone network event.

MarkTeleport needs no trust list. It briefly relaxes movement and related visibility/godmode/camera checks, while weapon, money, event-abuse and injection checks remain active. With default settings, an untrusted call is limited to 15 seconds and the player has a 180-second budget over ten minutes. Repeated extensions consume that budget. Do not call it every tick to keep a player exempt.

-- Within an already validated server workflow:
local ok = exports["tosun-ac"]:MarkTeleport(src, 8000, "house_enter")
if ok then
    SetEntityCoords(GetPlayerPed(src), destination.x, destination.y, destination.z)
end

Measure a repeatable baseline

Take a server profile during a representative session before changing settings. Note the player count, artifact, resource versions and activity: quiet roleplay, crowded garages and combat can produce very different work. Compare the same kind of session after one change. Server CPU time, hitch warnings and query behavior are more useful than a promise of a fixed FPS gain.

The commands below record a bounded sample and show its status. Wait for recording to finish before opening the profile. Inspect the resource and thread responsible for a spike instead of assuming every hitch comes from the anti-cheat. Save a private before/after note with the exact changed setting. A short recording cannot predict every peak-hour workload.

profiler record 500
profiler status
profiler view

tosunac_doctor

Tune punishment from context and evidence

Keep context-sensitive checks at their suitable observation settings until ordinary gameplay has been tested. A log entry is a signal to investigate, not an instruction to ban every matching player. Verify character selection, revive, teleports, police equipment and scripted weapons. Add a specific server integration rather than a broad permanent exemption.

The config doctor runs after settings are applied and can be run with tosunac_doctor. It reports risky effective values but never changes them. Review warnings about aggressive punishment, disabled safeguards, debug and fail-open behavior. Panel values may override a local default; diagnose the effective configuration, not only the file on disk.

An exemption or relaxed action can reduce visible complaints without solving the actual cause. Keep a dated list of temporary exceptions and the scripts that need repair. Remove an exception after the integration is verified, then repeat the accepted gameplay scenario and compare its logs with the earlier run.

• Change one setting and record why, who reviewed it and the previous value.
• Compare repeated detections with legitimate script actions and timestamps.
• Retest relevant gameplay after increasing a punishment or changing a framework/inventory resource.
• Restore the previous value if a new false positive appears, then fix the cause before tightening again.

Updates, recovery and a useful support record

Repeat the relevant acceptance tests when core, inventory, job scripts or AC change. Do not change schema, punishment and resource version together. If the new change caused a failure, restore the saved resource and settings in maintenance; assess data loss before any database restore. For support, provide artifact/core/inventory/AC versions, resource name, reproduction steps, time and the first sanitized error. Keep player identifiers, licenses, passwords and tokens out of public reports.

Related installation details

Installation documentation · Database bridge · Server export guide

Sign upالتوثيق عرض الأسعار

الأسئلة الشائعة

ذات صلة: QBCore · ESX · Standalone · OX/Qbox · All Framework Guides · كشف RedEngine