OX / Qbox Anticheat Setup: Dependencies and Acceptance Checks

Distinguish Qbox from ox_core and ox_inventory; verify dependencies and data boundaries.

OX can refer to different components: ox_lib is a library, oxmysql a driver, ox_inventory an inventory and ox_core a separate core. Qbox uses qbx_core. Do not start them all because their names are familiar.

What to verify in this installation

• For Qbox verify actual qbx_core, ox_lib and oxmysql dependencies.
• Use qbox in AC; assess a pure ox_core setup separately.
• Test the running ox_inventory API and legitimate weapons.
• Bridge supports suitable Qbox layouts, not arbitrary ox_core schemas.

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
ensure ox_lib
ensure qbx_core
ensure ox_inventory
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.

Do not copy the Qbox example into a pure OX server

The start example below is for Qbox. Do not add qbx_core to a working ox_core server just to match it; it is not advice to run alternative cores together. Set ts.Framework.framework to qbox for Qbox. For pure ox_core, preserve its dependencies and test general AC integration using standalone.

Inventory and database bridge have separate compatibility

Weapon ownership can use a running ox_inventory API. That does not make the bridge understand ox_core characters. Qbox bridge reads supported players/citizenid and player_vehicles layouts, using qbx_core for online operations.

Qbox and inventory acceptance test

After inventory/core updates, verify character loading and legitimate equipment again.

1. Check one actual core and the correct resolved AC mode.
2. Move, equip and remove a test weapon; a normal operation need not create a detection log.
3. Test character selection, police loadouts, vehicle delivery and emote props.
4. Use scoped AllowWeapon for non-inventory arena weapons and MarkTeleport for movement.
5. The Qbox bridge is on by default: compare one character/vehicle read with the game. Online balance editing is also on for admin and owner panel users; do not use it before reads are verified.

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 upDocumentação Ver preços

Perguntas frequentes

Relacionado: QBCore · ESX · Standalone · vRP · All Framework Guides · Detecção de RedEngine