QBCore Anticheat Setup: Dependencies and Acceptance Checks

Verify dependencies, character and weapon behavior, panel data and launch checks on a qb-core server.

A running QBCore does not prove that every banking or inventory script implements the same API. Preserve the working stack and verify its AC integration.

What to verify in this installation

• qb-core is started; AC framework is qb or verified auto.
• Persistent citizenid is distinct from the temporary online source.
• Test owned inventory weapons and non-inventory arena weapons separately.
• Custom money/item events validate permission, amount and activity server-side.

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 qb-core
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.

Choose the QBCore setting and data boundary

Edit the existing ts.Framework.framework field in configs/anticheat_config.lua to qb, preserving the rest of the table. With ox_inventory, retain your working dependencies and compatibility layer. The weapon check prefers a running ox_inventory; an unavailable custom inventory API does not prove that the player lacks the weapon.

Player and economy acceptance test

The bridge reads supported fields/indexes in players by citizenid and vehicles in player_vehicles. It does not mirror every banking table or stash. The connection and online balance editing are on by default; you add no server.cfg line for them. Old tosun_db_bridge_enabled and tosun_db_bridge_money_write lines are ignored unless manual mode is on. Only panel users with the admin or owner role can set a balance, only while the character is online and the expected balance matches; verify reads first. To stop reads and edits for this server, use Disable connection on the Tosun Connect card (Servers → the server). Advanced: with set tosun_db_bridge_manual "1" in server.cfg, those two lines are read from server.cfg again and each stays off unless set to "1"; the manual line alone turns off both the connection and balance editing, while manual "1" plus enabled "1" keeps reads on and balance editing off.

1. Connect a test character with known job, cash, bank and vehicle.
2. The connection is on by default: read one character in the panel and compare identity and values with the game.
3. Switch characters and read again; check that old character/source is not used.
4. Test housing, garage, police equipment and arena weapons granted without inventory.
5. Verify in your custom reward code that the client cannot choose arbitrary amount or another player.

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文档 查看价格

常见问题

相关: ESX · Standalone · vRP · OX/Qbox · All Framework Guides · RedEngine 检测