Server Event Protections

What this detection catches, what it ships blocked and whitelisted, how to read a hit, and how to whitelist one event or a whole resource.

Server Event Protections refuses events a player should not fire. This page covers the two detections behind it, the order the lists are checked in, and how to clear a false positive without opening a hole.

What ships

There are two detections, one per side. The server-side one is on in the box and the client-side twin is off. Both carry the same three lists, and both whitelists behave the same way on either side. BlockedEvents is the one that does not, which is covered under How a name is matched below.

Setting	Ships	What it is for
`AiServerEventsProtection.Enable`	on	The server-side protection, over the net events of every resource Raven is installed in.
`AiServerEventsProtection.Action`	`ban`	What a hit does.
`AiServerEventsProtection.BlockedEvents`	`[helpCode]`	Names that are always refused.
`AiServerEventsProtection.WhitelistEvents`	`[3 entries]`	Names that are always allowed. Ships with chat:init, Queue:playerActivated and hardcap:playerActivated.
`AiServerEventsProtection.WhitelistResources`	`[]`	Resources whose events are not protected at all. This is what step 2 below means by trusting a whole resource.
`AiClientEventsProtection.Enable`	off	The client-side twin, over events a resource registers on the client.
`AiClientEventsProtection.Action`	`ban`	What a hit does.
`AiClientEventsProtection.BlockedEvents`	`[]`	Empty in the box.
`AiClientEventsProtection.WhitelistEvents`	`[ox_lib:cache:coords]`	One entry, because ox_lib fires it from the client often enough that it would otherwise be the first thing you saw.
`AiClientEventsProtection.WhitelistResources`	`[]`	Empty in the box.

Read out of the resource config.json. Edit them from Protection Rules, not from the file.

The anticheat never flags its own events. You will not see those names in the panel and you do not need to add them.

How a name is matched

The server-side order

Every event that reaches a protected resource is checked against the lists in this order. The first line that matches is the answer, so a name on both lists is blocked rather than allowed.

Order	Test	Outcome
1	`BlockedEvents`	Refused and a hit is filed.
2	`WhitelistResources`	The whole resource is unprotected. Every event it registers runs untouched.
3	`WhitelistEvents`	That one event name runs untouched, in every resource.
4	Everything else	Protected. Events a player should not fire are refused.

Patterns in a list entry

Both lists match the trimmed name exactly, with one exception: an entry that contains a Lua pattern character is treated as a pattern. If an entry holds any of ^ $ % * + ? [ ( it is matched as a Lua pattern against the event name rather than compared to it, and a pattern match is a substring search, so ^qb%- matches every event name starting qb-. Plain names have none of those characters and keep behaving as exact matches.

text

myscript:giveItem      exact name only
^myscript:            every name that starts with myscript:
:buy%-                every name containing :buy-

Where the client-side twin differs

On the client side a name on BlockedEvents is not refused. It resolves to the same verdict as a name on no list at all, which is protected. The one thing the entry buys you is that it is tested before either whitelist, so a blocked name stays protected even in a resource you put on WhitelistResources.

What happens to a protected event

A protected event that comes from a legitimate trigger runs. One that does not is refused, which is why the first symptom of a blocked event is often a script going quiet.

Reading a hit

The reason on a server-side hit is always Server event manipulation detected, and the client-side twin writes Client event manipulation detected. What tells them apart is the fields under it.

Field	Side	What it holds
`Config Option`	Both	AiServerEventsProtection or AiClientEventsProtection.
`Event Name`	Both	The event that was refused. This is the string you whitelist.
`Event Resource`	Both	The resource the event was registered in. This is the name you whitelist when you trust the whole script.
`Source`	Both	Where the trigger came from, when known.
`Trigger Data`	Both	The arguments the event was fired with, trimmed, and only when there were any.
`Step`	Both	Which check failed, from the table below. A server-side Blocked Event row carries no step, and a client-side row that arrived without one reads Unknown.
`Invoke Resource`	Client	The resource that fired the event, on an Invoker Not Running row only.
`Invoke Resource State`	Client	What that resource was when the event arrived, so missing or stopped.
`Type`	Server	Blocked Event, and only on a hit from the BlockedEvents list, which has no step.

Step names

Missing Security is the common case. Invoker Not Running has its own meaning below. Any other step is a rarer way of failing the same check.

Step	What it means
`Missing Security`	The usual result when a protected event is refused.
`Invoker Not Running`	Client side only: the resource that fired the event is stopped or missing.
Any other step	The event failed the check in another way. Treat it like Missing Security.

Fixing a false positive

Work from the two fields that name things you can act on: Event Name and Event Resource. Whitelisting the event is the narrow fix and whitelisting the resource is the wide one, so reach for the narrow one first and only widen when the same resource keeps producing different events.

Open the hit and read both names

Find the row in the activity log and read Event Name and Event Resource off it. Reading a detection shows where those sit on the row.

Decide how wide the fix has to be

One event from a script you trust goes in WhitelistEvents. A trusted script that cheaters cannot reach and that keeps producing different event names goes in WhitelistResources, which drops the protection for every event it registers.

Add it in Protection Rules

Open Protection Rules, find AiServerEventsProtection, add the entry and save. The configuration is pushed to a connected server immediately. Editing the file in your resources folder does nothing.

An exact name stops that one event being flagged for as long as the name stays the same. If the script later renames it, the whitelist entry goes stale and the detection fires again, so a hit on a resource you already whitelisted an event for usually means the event name moved rather than that the whitelist failed.

When an event cannot be seen here at all

The protection only covers resources Raven is installed in. Two things put an event out of reach, and both look identical from the panel: nothing is ever logged for them.

Out of reach	Why
`ResourcesInstallation.WhitelistResources`	A resource on that list is never modified by the installer (from 1.9.3 Raven is also removed from it), so none of its events is protected. If a resource seems invisible to this detection, check that list first. On 1.9.2 and older the list is AutoInstallation.IgnoreResources.
Engine events	FiveM’s own events are not covered.

Main Settings has the Resources Installation card (Auto-Installation before 1.9.3), and What Raven ships with lists every setting on both of these detections next to the value it ships.