FiveM Framework Guides: Stack, Integration and Acceptance Tests

Compare actual resource names and supported data for QBCore, ESX, Standalone, vRP and OX/Qbox. Installation time depends on your custom resources and tests.

Setup and data compatibility

How to choose your actual setup

qb-core → qb; es_extended → esx; qbx_core → qbox. General standalone mode for custom standalone/vRP. ox_inventory is not a core; assess pure ox_core separately. With auto, verify the resolved mode in console.

A profile does not write your event rules

Discovering an event or detecting a framework does not validate your price, amount, location and permission rules. Custom shop, job, reward and inventory actions need their own server checks. A normal item transfer need not produce a detection log. Test data reads, unauthorized-request rejection and actual detection conditions separately.

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

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

Perguntas frequentes

Sign upRecursos do Anticheat FiveM