A Guide to BattlEye Filters

What Are BattlEye Filters?

BE filters are an optional feature of BattlEye Anti-Cheat for Arma games that provide customisable, server-side protection against common exploits. Mod developers usually ship filter files with their server releases — place the .txt files in your dedicated server config directory under .\BattlEye\.

The eraser1/BE_AEG ↗ tool can automatically generate scripts.txt exception lines by reading your scripts.log — useful when you need to whitelist new entries quickly. More community security tools and preconfigured BEC setups are on our Community Repos page.

⚠️

Don't start from scratch. Always begin with the filter files your mod team provides — they have already tested them against their own scripts. Use this guide to customise or troubleshoot those filters, not replace them.

How They Work

BE searches all scripts running on the client (scripts.txt) and specific command parameters (all other filter files) for the keywords you define. When a match is found, it takes the configured action:

Code	Action
1	Log to `.log` file only
2	Log to console only
3	Log to both
4	Kick — no log
5	Kick + log to `.log` file (recommended)
6	Kick + log to console
7	Kick + log to both

💡

Use action 5 for kicks. It creates separate .log files per restriction type in the \BattlEye\ folder, making review far easier than one huge console log. Console logging (6/7) is only useful if you need a live stream over RCon — it increases server resource usage and floods connect/disconnect messages.

Syntax — Adding Keywords

Add one rule per line: the action code, a space, then the keyword.

5 keyword
5 "key word"         // spaces → use double quotes
5 "key \"word\""     // literal " → escape with \
5 "key \(word\)"     // regex metacharacters → escape with \
                     // ( ) { } [ ] ^ $ . | * + ? and \ all need escaping

⚠️

scripts.txt does not support regex. The only characters that need escaping there are " and \ itself. All other filter files support full regex.

Use broad prefixes that cover many variants rather than listing every classname:

// Inefficient — one rule per classname:
5 HMMWV_DES_EP1
5 HMMWV_M1035_DES_EP1
5 HMMWV_Ambulance_DES_EP1

// Efficient — one rule covers all humvees:
5 HMMWV_

To catch everything (empty allow-list), use empty double quotes:

5 ""

Syntax — Adding Exceptions

Append exceptions on the same line after the keyword, separated by a space. Two operators are available:

Operator	Rule	Best for
`!`	Parameter must contain the exception string	Allowing a family of variants with one exception (e.g. all `HMMWV_Ambulance*`)
`!=`	Parameter must exactly equal the exception string	Tight allow-lists — use this whenever possible

5 keyword !exception          // contains
5 keyword !=exception         // exact match
5 "key word" !"keyword ex"    // spaces → quote the exception
5 "key word" !"key \"ex\""    // quotes → escape with \

Example with ! (contains):

// createvehicle.txt
5 "HMMWV_" !"HMMWV_Ambulance"

// ✓ Not kicked — parameter contains "HMMWV_Ambulance":
createVehicle ["HMMWV_Ambulance_DES_EP1", getPosATL player, [], 10, "NONE"];

// ✗ Kicked — parameter does not contain "HMMWV_Ambulance":
createVehicle ["HMMWV_DES_EP1", getPosATL player, [], 10, "NONE"];

Same filter with != (exact match) — only bare HMMWV_Ambulance passes:

5 "HMMWV_" !="HMMWV_Ambulance"

// ✗ Kicked — full classname is not an exact match:
createVehicle ["HMMWV_Ambulance_DES_EP1", getPosATL player, [], 10, "NONE"];

// ✓ Not kicked — exact match:
createVehicle ["HMMWV_Ambulance", getPosATL player, [], 10, "NONE"];

⚠️

scripts.txt exceptions match the entire statement, not a single parameter. The statement can span multiple lines — use \n for line breaks and \" for inner quotes:

5 keyword !="if (2 > 1) then\n{\n    systemChat \"keywordException\"\n};"

Prefer != (exact match) over ! wherever possible to minimise what passes through.

💡

Filters are not case-sensitive, but are sensitive to spaces and line breaks. Tabs are automatically stripped from scripts.txt.

Filter File Reference

Each .txt file watches a specific command or set of commands. Click any row to expand its details. Kick entries suggest action 5; Log entries suggest action 1.

addbackpackcargo.txt ▼

Filters: addBackpack[Cargo][Global] pack name parameter
Kick: All backpack classes unobtainable in your mod
Log: All, or just rare backpacks
Abuse: addBackpack can be used to spawn backpacks on demand

When players take gear from containers (crates, bodies, vehicle cargo), add[Backpack/Magazine/Weapon]CargoGlobal runs automatically on their client — these will appear in the logs. The filter only applies to items added to global objects from the client; local objects do not trigger it.

addmagazinecargo.txt ▼

Filters: addMagazine[Cargo][Global] magazine name parameter
Kick: All magazine/item classes unobtainable in your mod
Log: All, or just rare items
Abuse: addMagazine can be used to spawn magazines and items

Same global/local behaviour as addbackpackcargo.txt — taking items from large containers (ammo boxes, safes, vehicle cargo) triggers this filter automatically and can generate many hits per second.

addweaponcargo.txt ▼

Filters: addWeapon[Cargo][Global] weapon name parameter
Kick: All weapon and toolbelt classes unobtainable in your mod
Log: All, or just rare weapons
Abuse: addWeapon can be used to spawn weapons and toolbelt items

Same global/local and large-container behaviour applies as the other cargo filters above.

attachto.txt ▼

Filters: attachTo object classname parameter — global objects only; local will not trigger it
Kick: All global objects your mod cannot legitimately attachTo from the client
Log: All, except the most common uses
Logs show: Object, target object, and offset
Abuse: Can chain players and objects together for teleporting or griefing

R3F and BTC scripts use attachTo on vehicles. DayZ mods use it for dragging injured players, placing tents, and Epoch buildables — add exceptions for these as needed.

createvehicle.txt ▼

Filters: createVehicle and createUnit type parameter — global objects only
Kick: All global objects the client cannot legitimately create in your mod
Log: All, except the most common uses
Logs show: Object classname and position
Abuse: Can spawn buildings, vehicles, ammo boxes, bombs, and other objects

Arma creates animals automatically on the client when environment AI is enabled. Some explosion effects (SmallSecondary, HelicopterExploBig, HelicopterExploSmall) are also created client-side on vehicle destruction — add exceptions for these.

deletevehicle.txt ▼

Filters: deleteVehicle object parameter — global objects only
Kick: All global objects the client cannot legitimately delete in your mod
Log: All, except the most common uses
Abuse: Can delete vehicles, AI units, and buildings globally

In DayZ mods the client deletes zombies when leaving an area. Epoch clients also delete safes and certain buildables on removal — add exceptions for these.

mpeventhandler.txt ▼

Filters: addMPEventHandler command parameters
Kick: All except the exact command strings your mod legitimately adds on the client
Abuse: Can add event handlers to remote players/objects; the code then executes on remote machines when events fire

publicvariable.txt ▼

Filters: publicVariable[Server] variable names
Kick: All variable names except those your mod broadcasts from the client
Log: All variable broadcasts you want on record
Logs show: Variable name and broadcast value
Abuse: Can broadcast arbitrary variables to the server and all clients; can overwrite existing global values

MPF (remExField, remExFP) and the Arma 3 equivalent BIS_fnc_MP_packet use public variables. Antihack scripts like Infistar also broadcast variables. Most mods broadcast at least one variable from the client on player login.

publicvariableval.txt ▼

Filters: The value assigned to the variable being broadcast via publicVariable[Server]
Kick: Commands and critical variable/function names that could later be compiled and executed
Abuse: Can send arbitrary code to the server/clients for later execution

Logs are written to publicvariable.log alongside publicvariable.txt entries — logging everything there makes separate logging here redundant. This filter also applies to values passed via call RE or BIS_fnc_MP. Be careful: if your mod uses public variables with wildcard values (player names, text input), a cheater could craft input that triggers a keyword.

remotecontrol.txt ▼

Filters: remoteControl use
Kick: Everything, unless your mod legitimately needs this command

remoteexec.txt ▼

Filters: setVehicleInit statements (via processInitCommands); init fields of newly created units; setWaypointStatements condition & statement parameters
Kick: All except the exact strings your mod uses in client-created unit init fields
Abuse: Vehicle inits can remotely execute code on the server and all connected clients

This file is tied to waypointcondition.txt and waypointstatement.txt — exceptions needed in those files must also be added here. Logic units often have predefined init code in cfgVehicles; add exceptions as needed.

scripts.txt ▼

Filters: All scripts running on the client
Log: The statement containing the keyword plus surrounding lines — useful for identifying cheat scripts

This is the most resource-intensive filter — it searches every script running on the client, not just specific command parameters. Keep the keyword count low and favour broad command names over specific strings or variable names. No regex support — only " and \ need escaping. Scripts from all sources run on the client (mission PBO, server addon scripts, Arma game functions) — test thoroughly to ensure all legitimate exceptions are covered before deploying.

selectplayer.txt ▼

Filters: selectPlayer unit classname parameter
Kick: All unit classes except those selectable in your mod
Log: Everything
Logs show: Unit classname and position
Abuse: Can assume animal or other unobtainable skins, or take control of other players

In the lobby, the client calls selectPlayer on whichever unit type occupies the chosen slot in mission.sqm. In DayZ mods it's also called when changing clothing.

setdamage.txt ▼

Filters: setDamage number parameter — global objects only
Kick: All values except what your mod legitimately applies to global objects from the client
Log: Everything
Logs show: Damage value and object classname
Abuse: setDamage 0.9+ destroys vehicles or kills players; setDamage 0 repairs everything

Exceptions must be written with six decimal places due to Arma's number format (e.g. !=0.100000). Epoch uses setDamage for player-zombie attacks, vehicle repairs, and chopping trees — add exceptions for each.

setpos.txt ▼

Filters: setPos[ASL/ATL] object classname parameter — global objects only
Kick: All global objects your mod doesn't need the client to move
Log: Everything
Logs show: Object classname and new position
Abuse: Can mass-teleport 50+ players or move 300+ objects near-instantly

Height-adjusted buildings placed in the editor may auto-generate setPos calls in their init field, which runs on all clients. Move those calls server-side to avoid false kicks. R3F and BTC scripts also use setPos on vehicles.

setvariable.txt ▼

Filters: setVariable variable name — only public setVariable (third parameter true); local calls do not trigger it
Kick: All variable names except those your mod uses for public setVariable from the client
Log: Variables you want on record
Logs show: Variable name, stored value, and object classname
Abuse: Can change critical networked variables on players/objects (humanity, money, inventory data, etc.)

setvariableval.txt ▼

Filters: The value being stored via public setVariable
Kick: Commands and critical function names that could be compiled and executed later
Abuse: Can store executable code on remote objects for later use

Logs are written to setvariable.log alongside setvariable.txt entries, making separate logging redundant. Same wildcard-value caution as publicvariableval.txt applies.

teamswitch.txt ▼

Filters: teamSwitch use
Kick: Everything, unless your mod legitimately needs this command

waypointcondition.txt ▼

Filters: setWaypointStatements condition parameter
Kick: Everything unless needed; if used, kick for all except the exact condition strings your mod requires
Logs show: [condition, statement] array and waypoint group

When a waypoint completes, Arma automatically calls setWaypointStatements again with condition "true". If you use this command at all, always add !="true" as an exception here and in remoteexec.txt.

waypointstatement.txt ▼

Filters: setWaypointStatements statement parameter
Kick: Everything unless needed; if used, kick for all except the exact statement strings your mod requires
Logs show: [condition, statement] array and waypoint group
Abuse: Statement can remotely execute code on the server and all connected clients

When a waypoint completes, Arma resets the statement to "". If you use this command at all, always add !="" as an exception here and in remoteexec.txt.

BEServer.cfg — Rate Limits

Found in your \BattlEye\ folder. While the server is running it is automatically renamed to BEServer_active_xxxx.cfg for security. It must contain at least RConPassword and MaxPing. The Max[Command]PerInterval lines kick players who exceed a command rate threshold — useful for catching scripted cheating that relies on spamming commands.

RConPassword ChangeMe
MaxPing 300
MaxAddBackpackCargoPerInterval   20  1
MaxAddMagazineCargoPerInterval  400  1
MaxAddWeaponCargoPerInterval     75  1
MaxCreateVehiclePerInterval     150  1
MaxDeleteVehiclePerInterval     100  1
MaxSetDamagePerInterval           3  1
MaxSetPosPerInterval             10  1

Format: Max[Command]PerInterval [max uses] [seconds]. Start strict (low values) and increase until no legitimate kicks occur — some actions only trigger under specific game conditions, so test each scenario carefully.

Setting	Limits	Abuse potential
`MaxSetPosPerInterval`	`setPos[ASL/ATL]` on global objects	Teleport 50+ players or move 300+ objects near-instantly
`MaxSetDamagePerInterval`	`setDamage` on global objects	Kill all players, destroy all vehicles or buildings
`MaxAddBackpackCargoPerInterval`	`addBackpack[Cargo][Global]`	Mass-spawn backpacks
`MaxAddMagazineCargoPerInterval`	`addMagazine[Cargo][Global]`	Mass-spawn items; also triggers when looting large containers
`MaxAddWeaponCargoPerInterval`	`addWeapon[Cargo][Global]`	Mass-spawn weapons; also triggers when looting large containers
`MaxDeleteVehiclePerInterval`	`deleteVehicle` on global objects	Delete all vehicles or buildings; triggers on client-side cleanup scripts
`MaxCreateVehiclePerInterval`	Global `createVehicle`, `createUnit`, `createAgent`	Mass-spawn objects to crash or grief the server

⚠️

Height-adjusted buildings spawned from the client can call setPos hundreds of times in under a second. Always spawn and position global buildings on the server machine only to avoid false kicks from MaxSetPosPerInterval.

bans.txt — Manual Banning

Every player connection is logged to the server console with their GUID and IP. Find these in the console log file (set via logFile in server.cfg) or via an RCon tool like DaRT.

12:06:56 BattlEye Server: Player #3 Hunter (88.111.22.333:2304) connected
12:06:57 BattlEye Server: Player #3 Hunter - GUID: 5c7d9d6ec60869824ae5f1e6cadd1111 (unverified)
12:06:58 BattlEye Server: Player #3 Hunter - Legacy GUID: ef68da39ea1bb994aba33caa16552222

⚠️

Use the GUID — not the Legacy GUID. The new GUID is tied to both the Steam account and registry key, making it harder to evade. Do not include the port when banning by IP (drop :2304).

Format: GUIDorIP time (Reason) — time -1 = permanent; a positive number = hours. Add IP bans near the top of the file, GUID bans with the other GUIDs:

88.111.22.333 -1 (Hunter - spawningGear)
5c7d9d6ec60869824ae5f1e6cadd1111 -1 (Hunter - spawningGear)

Save the file then reload bans in your RCon tool — no server restart needed. To unban, delete both lines, save, and reload.

💡

Include the player's name in the reason field — it makes searching and unbanning much easier later. Banning both GUID and IP together makes it harder for a player to rejoin immediately.

Automatic Banning

Kicks are of limited use if a cheater can simply rejoin. BE filters have no built-in autoban — you need a third-party tool. The easiest option is the BEC ScriptBan Plugin, part of BattlEye Extended Controls. A preconfigured BEC setup for DayZ Epoch is on our Community Repos page.

The plugin reads kick restriction numbers from your filter files and automatically adds the player's GUID to bans.txt. Configure each restriction type in reason.py:

SERVERS = ["Config.cfg"]

waypointstatement_reason = {
    "0" : ["WPS0 - appeal at myWebsite.com", 0]
}
// Bans for waypointstatement restriction #0; ban time 0 = indefinite

⚠️

Restriction numbers start at 0 on the first non-comment line. If your filter has one comment at the top, subtract 2 from the text-editor line number to get the restriction number. To keep counting simple, avoid using comments inside filter files.

🔴

Be very careful auto-banning for scripts.txt, publicvariableval.txt, and setvariableval.txt. Cheaters can remotely execute code on other clients — an innocent player can trigger a restriction they have no control over and receive an automatic ban. Despite this risk, auto-banning is still strongly recommended for most other restriction types.

⚠ Minimum Recommended Configuration

At bare minimum, configure these filter files to block the most dangerous remote execution vectors. There is no reason not to have these — they require very little customisation:

mpeventhandler.txt
remotecontrol.txt
remoteexec.txt
teamswitch.txt
waypointcondition.txt
waypointstatement.txt

Also apply the security settings in your server.cfg — see the Bohemia Wiki: server.cfg Security ↗. Never run without BattlEye enabled.

💡

The eraser1/BE_AEG ↗ tool auto-generates scripts.txt exceptions by reading your scripts.log — useful for quickly building a valid exception list. Note: may not work reliably with BigEgg's Antihack & Admin Tools, as those scripts use randomised variable names that change every restart. More community security tools and a preconfigured BEC setup (BattlEye Extended Controls) are on the Community Repos page.

Guide originally written by eBayShopper and posted on OpenDayZ.net ↗. Adapted and reformatted for DZE Tools.