Reading a detection

How to turn a log entry into the exact config change that stops it happening again.

Every detection Raven files carries an Additional Info panel, and that panel is the whole point of the log. It names the setting that fired and the value that caused it, which together tell you the one line of config to change. Reading it is the difference between guessing at thresholds and fixing the actual cause.

The fields and what each one is for

Not every detection stamps every field. Config Option is always there. The rest appear when they are relevant to the check that fired.

Field	What it is	What to do with it
`Config Option`	The detection that fired. Every detection stamps it.	This is the name in the config, so it is the path to the setting: Detections.<category>.<Config Option>.
`Type`	Which sub-check inside the detection fired.	Maps to Types.<Type>. Turning that one off leaves the rest of the detection running.
`Method`	The specific technique the check recognised.	Narrows a report further. Usually read rather than configured.
`Rule`	Which numbered spam rule fired, with Trigger, Threshold and Time Window beside it.	Maps to Rules.<Rule>.Threshold and Rules.<Rule>.TimeWindow.
`Entity Script`	The resource that created the entity.	The name to put in WhitelistResources. This is the field that fixes a spawn or spam false positive.
`Event Name / Event Resource`	The event that was blocked and where it came from.	The name to put in WhitelistEvents, or the resource for WhitelistResources.
`Entity Model / Model`	The model involved, as a name or a hash.	The value for WhitelistModels, which accepts either form.
`Weapon Name / Weapon Hash`	The weapon involved.	The value for WhitelistWeapons, which accepts either form.
`Value / Maximum`	What was measured and the ceiling it crossed.	Tells you whether the ceiling is wrong for your server or the player really was out of range.
`Old / New`	A property before and after the change Raven objected to.	Read this before assuming a cheat. A legitimate script changing a vehicle looks identical here.

From a log entry to a config path

Config Option is the detection name exactly as it appears in the config, and the Detections Reference tells you which of the seven categories it sits in. Put those together and you have the path.

example

Config Option:  EntitiesSpamProtection
Entity Type:    objects
Rule:           1
Entity Script:  ox_inventory

becomes

Detections.Entities.EntitiesSpamProtection.WhitelistResources += "ox_inventory"

Note which lever that example reaches for. Rule 1 tells you the object counter fired, and you could raise Rules.1.Threshold to make it stop. But Entity Script says the entities came from your inventory resource, so the correct fix is to trust that resource and leave the threshold protecting everyone else.

Working through one

Read Config Option first

It names the detection. If you do not recognise it, look it up in the Detections Reference, which gives you the category and therefore the full config path.

Look for a cause you can name

Entity Script, Event Resource, Model, Weapon Name. If one of these points at something of yours, that is your fix, and it is a whitelist entry rather than a threshold change.

Then read Type

If the detection has sub-checks and only one of them is wrong for your server, turning off that single Types entry keeps the rest of the detection working.

Check the evidence before you decide

If a screenshot or recording is attached, open it. For anything in the manual review list on the Review a false ban page, the evidence decides the case, not the detection name.

Make the change on the dashboard

Protection Rules for toggles, actions and thresholds; the detection's own card for its whitelists. Editing config.json in your resources folder does nothing.

When an event handler goes quiet instead of banning

Event protection does not act the first time something looks wrong. For the first minute after the protection comes online it does nothing at all, and after that the first couple of occurrences are absorbed silently: the event simply does not run, with no log and no action. Only past that does it file a detection.

So the first symptom of an event false positive is usually a script that has quietly stopped working, not a ban. If a resource broke and there is nothing in the log yet, check whether its events are being blocked before you look anywhere else.