VORP anticheat: protecting a VORP Core server without breaking it

VORP Core is one of the most widely used roleplay frameworks on RedM, and it shapes everything a cheater goes after: characters, money, gold, jobs, inventories. A generic anticheat sees a RedM server. A VORP anticheat has to see a VORP server: who is still in the character creator, which money change came from a legitimate payday, which item moved between two accounts owned by the same person. This article covers what that means in practice, and how Baobab AC runs on VORP Core.

#What a VORP anticheat has to understand

Most of what cheaters do on RedM is engine-level: godmode, teleport, noclip, aimbot, spawned entities. None of that depends on the framework, and a good anticheat reads it from the game itself. The framework matters for four things, and they are exactly where generic tools either go blind or start accusing honest players.

• Characters. A player in the VORP character creator is legitimately invincible while he picks a face and a name. An anticheat that does not know the character is not loaded yet reads that as godmode.

• Money and gold. A payday, a shop sale or a job reward changes a balance. So does a cheat calling an unprotected server event. Telling them apart means knowing where VORP records the change.

• Jobs and groups. A job or group that changes without any script asking for it is one of the fastest ways to an admin menu or a sheriff's armoury.

• Inventories. Duplicated items and money moved to a second account rarely look like cheating on the frame they happen. They show up in the economy, days later.

#How Baobab AC runs on a VORP Core server

Baobab AC is framework-agnostic: every detection except the economy one reads the game rather than framework events, so the full in-game catalogue runs on any server. VORP, RSG, QBR and RedEM:RP are recognised at boot for the economy and character checks, and you can force the choice with the ac_framework convar if auto-detection guesses wrong. VORP Core is our reference framework: it is the one our support targets first, and the one where the economy checks see the most.

Money and jobs, as VORP records them

On VORP, Baobab AC follows money and job changes as the framework records them, including through VORP's current character API rather than only its older events. That matters: an anticheat that only listens to deprecated events sees every legitimate payday as an unexplained gain, and either floods you with alerts or gets switched off. Cores built on the QBCore model (RSG, QBR, RedEM:RP) do not emit those change events, so on them the same checks run by periodic comparison instead. Both work; on VORP the picture is simply more immediate.

The character creator is not godmode

This one came from a customer. A player who spent several minutes in the VORP character creator ended up flagged for godmode, because the old rule gave every new player a fixed grace period and a first character takes longer than a reconnection. Making the window longer would have weakened protection for everyone at every login. Instead, the grace now ends on a fact: the server asks VORP whether a character is loaded. A client cannot lie about that, and for a normal player who picks a character in ten seconds, protection starts sooner than before.

Items and money moved between alts

Baobab AC can flag items or money passed between two accounts tied to the same Discord identity: a direct give, a shared container, or a drop picked up by the other account. Inventory resources differ from server to server, so this collector stays inactive until it is pointed at your inventory's own events from the panel. It never guesses, and it never crashes because an event is missing. The bigger picture of ban evasion is in RedM HWID bans.

The economy, audited after the fact

On the Pro and Network plans, Economy Forensics reads your game database in read-only mode and cross-checks it with the playtime only the anticheat knows: money supply over time, wealth outliers, mule networks, item dupes, impossible stacks. VORP and RedEM schemas are recognised as they ship. If you added a currency or renamed a table, you map your schema once in the panel instead of getting a partial audit forever. Every result is a lead for a human to review, never an automatic sanction. How dupes happen, and what to do the day you find one, is covered in RedM money dupes.

#Installing a VORP anticheat: the server.cfg part

You do not edit any Lua file. The resource goes into your resources folder as a folder named exactly baobab, and two things matter in server.cfg: your API key and the load order. Baobab AC must start right after your framework core, which on VORP means after oxmysql and VORP Core.

# Baobab AC credentials (from the panel)
set ac_api_key "YOUR_API_KEY"

# Optional: force the framework instead of auto-detecting it
# set ac_framework "vorp"

# Load order
ensure oxmysql
ensure vorp_core
ensure baobab

# Everything else after
ensure your_other_resources

Staff testing things in noclip will trip detections. Anyone in the group.admin or group.moderator ACE groups is exempt automatically, and you can exempt individual players from the panel without touching the file. Module settings changed in the panel reach the running server in about three seconds; only server.cfg changes need a restart. The full walkthrough is in the installation guide.

#VORP false positives worth knowing

Every VORP server runs scripts that do things a naive anticheat finds suspicious. The usual ones:

• Fast travel and stagecoaches read as teleport or speed by tools that only measure distance over time.

• Admin tools (noclip, spectate, teleport to player) used by staff who are not exempt.

• Scripted scenery that spawns props in bursts around players: camps, stalls, crates.

• The character creator, covered above.

Baobab AC ships in observe: a doubtful detection is a line to review, not a kick. When you close one as a false positive, a nightly pass traces it to its cause and narrows the correction instead of switching the rule off. The method is in false positives.

#What a VORP anticheat cannot fix

A server event that pays whatever the client asks. Many VORP money exploits are not cheats in the engine sense: a script registers an event that adds money or items, and trusts the amount the client sends. An anticheat can flag the gain and the caller; it cannot make that handler safe. The fix is in the script, and securing RedM server events shows how.

An outdated core or inventory. Known bugs in old framework or inventory versions get fixed upstream. Keep VORP and your inventory up to date; no anticheat replaces that.

#VORP anticheat checklist

1. 1

   Engine-level detections that do not depend on VORP at all, so a framework update never leaves you unprotected.

2. 2

   Money and job changes read the way VORP records them today, not only through deprecated events.

3. 3

   A character creator that never produces a godmode alert.

4. 4

   Staff exemptions through the ACE groups you already use.

5. 5

   An economy audit that understands your schema, and treats results as leads rather than bans.

6. 6

   A posture that starts in observe, so your first week is calibration, not apologies.

The full detection list is on the features page, the demo panel needs no account, and the pricing is public. If you are still comparing tools, start with what the best RedM anticheat has to get right.