Tosun AC features: scope, integration and performance

Evaluate features by the data they use and how they should be enabled, not only by a detection count. This guide explains framework compatibility, resource cost and safe operational checks.

Choose modules by their job

Server authority and client signals use different evidence. Do not assign the same confidence to server-visible movement/damage and screen or texture signals. In 9.6.3, the weapon damage disable setting is respected and framework API failures are not punished as missing weapon ownership. Repeated hits on one target are handled through its latest hit time instead of an unbounded same-target list.

• Movement and combat: test normal revival, transport and equipment workflows.
• Weapon/inventory: report legitimate arena weapons without inventory items through a short trusted AllowWeapon call.
• Entity and resource checks: compare ordinary emote/phone props and resource changes with the logs.
• Evidence: use screenshots or live watch when account rights and the installed workflow support them; every detection is not guaranteed an automatic image.
• Database bridge: supported reads are on by default and can be turned off on the server’s Tosun Connect card; balance edits need the admin or owner role, an online character and confirmation. Every custom table or inventory edit is not supported.

Identify the framework and inventory separately

Record the resource that actually owns your player state: qb-core for QBCore, qbx_core for Qbox or es_extended for ESX. Then identify the inventory resource and any modifications to its API. A familiar framework name does not prove that every third-party banking or inventory script is compatible. Keep your working dependency order and avoid running different cores together as a troubleshooting shortcut.

Edit the framework field already present in the package. Use qb for QBCore and qbox for Qbox; these are configuration values, not folder names. auto is available for automatic detection. Check the resolved framework in startup output and GetStatus from trusted server code. The database bridge separately detects running supported core resources, so its status may reveal a dependency not yet started.

-- Edit the existing framework field, not the whole table.
ts.Framework.framework = "qb"
-- Other supported values: "esx", "qbox", "auto", "standalone"

Check character data without assuming full compatibility

For bridge reads, QBCore/Qbox characters use citizenid and ESX characters use identifier. Online server IDs are temporary and are not substitutes for persistent character identifiers. Player and vehicle reads require supported columns and indexes. A customized schema can be rejected rather than scanned without a limit.

1. Use a test character with known cash, bank balance, job and one vehicle. Read its details and compare with the game.
2. If ox_inventory is running, compare a small online inventory result with the actual character. Respect truncation and do not expect stash contents or arbitrary metadata.
3. If a framework API fails, diagnose its startup or version; the weapon ownership check treats an unavailable API as unknown, not proof that the player has no weapon.

Test the workflows your players actually use

Framework detection cannot infer the permission, location, price or reward rules of every custom event. Your resource must validate those rules server-side. Do not assume that selecting a profile makes an insecure money or item event safe. Validate the player’s own server source and the active job or session before calling an AC integration.

Standalone and vRP servers can use suitable general AC checks, but the current database bridge does not promise their custom character or economy schemas. Explain unsupported features to staff instead of substituting unrelated SQL tables. Recheck integrations after core, inventory or job-script updates.

Record the exact core and inventory versions used in each test. After a core restart, reconnect the test character before judging an online API result. Avoid changing a database schema and an AC punishment together: separating those changes makes it possible to identify the cause and restore a working configuration.

• Character switch, respawn and hospital revive do not leave a persistent exemption behind.
• House, garage and jail teleports notify MarkTeleport immediately before the move.
• Arena weapons granted outside the inventory use a short AllowWeapon call from a trusted server resource.
• Police actions, staff tools, shops and legitimate large rewards are tested against logs before stronger punishment is chosen.

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

常见问题

相关: 什么是 FiveM 反作弊？ · 文档 · 查看价格