Framework settings

QBCore and ESX#

The bridge reads only supported schemas and indexed fields. Missing columns, unsupported inventories or custom identifiers may cause a request to be refused. An empty or unsupported response does not mean the database is empty.

Custom server workflows#

Test character selection, jobs, teleports, garages and staff tools on a staging server. Keep privileged state and permission checks on the server. Apply narrowly scoped exemptions from trusted server code only after validating the activity.

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.

• Database bridge (Tosun Connect)

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.

• Exports and trust
• Official event security

Resolve configuration names and detected core names#

The AC configuration and the database connector describe the same setup using different labels: the QBCore configuration value is qb, while bridge health reports qbcore. Qbox uses qbox and the running qbx_core resource. Read those labels in their own context rather than rewriting them to match a folder. Automatic setup can also recognise vrp or ox_core and set a corresponding label, but this does not create a supported character or economy adapter for the database bridge. For general protection on an unsupported core, an explicit standalone configuration avoids interpreting a detected name as a promise of full integration.

1. Check configs/anticheat_config.lua and the actually running core; retain one deliberate framework choice and the existing dependency order.
2. If the panel reports a different capability set, inspect running core resources and bridge health instead of blindly renaming the AC setting.
3. Do not start qb-core, qbx_core or es_extended together merely to obtain another status label.

Build an acceptance matrix around real roles#

Use separate test cases for ordinary players, police or other job roles, and staff. Staff can have legitimate AC exemptions, so perform the core gameplay checks with an ordinary character too. Cover joining, character selection, death and revive, housing travel, garages, inventory weapons and the server’s actual job rewards. For each action, note expected destination, item or account result and the observed log. Exercise cancellation as well as successful completion for menus and scripted activities. A clean resource start does not establish that a modified inventory, banking script or character selector follows the APIs the integration expects.

1. Run the same small set before and after a core or inventory update, changing one component at a time.
2. For a failure, record core and inventory versions, calling resource and player role; keep identifying data private.
3. After restart or character switch, reconnect and verify that any temporary relief ends rather than testing only the exempt staff path.

Assign custom-script responsibilities explicitly#

Separate detection configuration from the rules owned by your game scripts. The AC cannot know a custom bank transfer’s allowed recipient, a job’s reward ceiling or who owns a particular house. Those resources must verify the player, permission and server-owned state before changing money, items or position. Inventory weapon checks use supported APIs; an unavailable API is an unknown result, not proof of weapon spawning. If character reads fail because columns or indexes differ, investigate schema compatibility separately from enforcement. Do not punish players for an integration error or substitute a broad whitelist for a missing adapter.

1. Assign one maintainer to the framework or inventory adapter and another clear owner to each custom action.
2. Reproduce one normal authorised action and one rejected permission path using the game script’s own validation.
3. Keep general AC operation and the panel database bridge (Tosun Connect) separate; unsupported custom tables require reviewed integration work.

Read weapon inventory and character detail separately#

Framework and inventory provider can differ on the same server. QBCore may manage characters and money while ox_inventory supplies items. Weapon ownership inspection prioritizes a running ox_inventory, otherwise using supported QBCore/Qbox or ESX APIs where available. Panel character detail is a separate bridge operation. Seeing an item in one view does not prove every weapon check reads the same source at the same time and format. Preserve this distinction for custom armoury and job resources; changing a framework label does not synchronize their data sources.

An ESX loadout weapon and an item-based inventory count are different concepts. An API returning nil, an error or unexpected data is not evidence of absence. Verify the supported method and record the grant time, ordinary player action, inventory provider and corresponding result. Reviewed AllowWeapon integration can cover legitimately server-granted inventory-free weapons within the required scope. These are compatibility checks, not a claim that every possible detection defect has been resolved.

Treat a core migration as more than a table rename#

Moving between QBCore and ESX is not merely changing a label. The current bridge uses players/citizenid for the QBCore family and users/identifier for ESX. A previous session number or displayed name does not identify the migrated character. Money fields, vehicle ownership, inventory and custom rules can differ. Do not rename production tables simply to make panel queries pass. Data migration belongs to the game server’s own plan; AC installation is not a general conversion tool for missing data.

In a separate test environment, select one known character and vehicle record. Note core label, persistent character identity, cash/bank account and online state before a small read. A schema or index error does not establish data loss; let the maintainer assess compatibility. Panel balance editing is on by default; do not use it until the migration is accepted. To block it technically, use manual mode: set tosun_db_bridge_manual "1" and set tosun_db_bridge_enabled "1" in server.cfg, without tosun_db_bridge_money_write. Retest character selection and normal inventory operations, accepting the result only when correct data belongs to the correct character, rather than when the resource starts.