Raven AnticheatRavenAnticheat
The Raven JournalAugust 20, 2025 · 7 min

ESX · QBCore · Setup

Setting up anticheat for ESX vs QBCore: what's actually different

Framework-specific configuration matters more than vendors admit. ESX, QBCore, vRP, and QBox each have their own gotchas.

Every FiveM anticheat vendor claims framework-agnostic support. The reality is messier. ESX, QBCore, vRP, and QBox each have their own conventions, and the config that runs clean on one will throw false positives on another. Here is what actually changes between them, and what you need to set.

The shared setup, before framework specifics

Whichever framework you run, the anticheat resource drops into the same place. Add the resource folder under resources/, then add it to your server.cfg:

server.cfg
# Start your anticheat early so it loads before framework resources
ensure rac
ensure es_extended    # or qb-core, qbx_core, vrp, etc.
ensure ...your other resources

Order matters. If the anticheat starts after framework events are registered, the first few seconds of every player connect window go unprotected. Most modern FiveM anticheats handle this with auto-detection on startup. If you are wiring one up by hand, this is the single most important line in the file.

ESX gotchas

Server events with global handlers

ESX broadcasts a lot of events through esx:* handlers. Plenty of community scripts hook into esx:onPlayerJoined or esx:setJob, so the same event gets fired by dozens of different resources. Aggressive event-rate detection can read a busy login window as an attack.

The fix is simple. Most anticheats let you whitelist specific event names out of rate-limit detection. On ESX, whitelist esx:onPlayerJoined and the other known framework broadcast events. Do not whitelist economy events like esx:giveMoney. Those are exactly the ones you want watched.

Inventory event calls

Older ESX inventory implementations like esx_inventory and esx_inventoryhud fire client-side TriggerServerEvent calls for moves and drops. The newer ox_inventory does this server-side and is much safer. If you are still on a legacy ESX inventory, expect heavier inventory event traffic in the anticheat logs and be ready to triage the false positives that come with it.

QBCore gotchas

Player metadata events

QBCore leans hard on QBCore:Server:UpdatePlayer and QBCore:Player:SetPlayerData to keep state in sync. Both fire often during normal play. Some anticheats treat high-frequency state updates as suspicious by default, so you may need to raise the threshold or whitelist these two by name.

The QBCore:GetObject export

QBCore exposes QBCore:GetObject as a client-side export that hands back an object with player data and methods. Cheats sometimes call it to read player state for visualization. If your anticheat scans for client-side calls to framework exports, expect false positives from legitimate UI scripts that call the same export. Most of them are HUDs and admin tools.

vRP and QBox gotchas

vRP uses a proxy-based event model, which makes whitelisting by event name harder. Most modern anticheats handle the vRP event pattern out of the box. If you run a heavily customized vRP setup, plan to spend an afternoon tuning per-event thresholds.

QBox is the successor to QBCore and shares most of its event surface, but the resource manifest format and a few event names differ. Anticheats that auto-detect the framework on startup usually identify QBox correctly. The ones that key off resource names alone can misread it as QBCore and apply slightly wrong defaults.

The settings to always check

Whichever framework you run, audit these config values before you go live:

  • Event rate limits. The default may be tuned for one specific framework. Run a different one and you will need to raise or lower the threshold based on what you observe.
  • Whitelisted event names. Add framework broadcast events here. Never economy or inventory events.
  • Trust score recovery rate. Defaults assume average playtime. If your sessions run long or short, the trust score curve may need adjusting.
  • Position-delta thresholds. Vehicle-heavy servers, especially racing or PvP, produce higher legitimate position deltas. Default thresholds are tuned for RP and can false-positive on speed.
  • Resource exception list. Some custom resources like admin menus and debug tools trigger detections. Add them to the exception list with admin-only grants, not server-wide ones.

Auto-detection vs manual config

The strongest anticheats auto-detect ESX, QBCore, vRP, QBox, and Standalone on startup and apply framework-aware defaults. Raven Anticheat does this from the resource manifest scan. Some others read framework exports at runtime. If your AC makes you pick a framework by hand in a config file, you are doing work the product should be doing for you, and you are also likely to misconfigure it the next time you upgrade frameworks.

The practical takeaway: pick an AC that auto-detects, run observation mode for 24 hours, audit the noise that falls out, tune the few framework-specific thresholds, and only then enable enforcement. Skip any of those steps and you will spend the next two weeks living in your appeals channel.

Keep reading03