A Guide to BattlEye Filters

ebay

OpenDayZ Guru!
A Guide to BattlEye Filters
I noticed a severe lack of information on BattlEye across Arma and DayZ modding communities. This guide will give an overview of BE filters, BEServer.cfg and automatic banning with BE.

What they are:
BE filters are an optional feature of BattlEye Anti-Cheat for Arma games. They provide some additional protection that is customizable by mod makers and server admins. Currently Bastian ($able) is the sole developer of BE for Arma. However, other Bohemia devs like Dwarden contribute ideas for him to implement. Dwarden also made the original filters for DayZ mod a few years ago.

Mod developers usually provide filters with their server files. Below are links to current filters for popular DayZ mods:
Infistar also maintains filters for compatibility with his antihack. Place the .txt files in your dedicated server config directory\BattlEye\ folder. If you are using a managed host this will usually be accessible through FTP.

How they work:
BE searches all scripts running on the client (scripts.txt) and specific command parameters (other filters) for the keywords provided in the filter .txt files. If a match is found it can take one of the following actions:

1 = Log to .log file only
2 = Log to console only
3 = Log to both
4 = Kick with no log
5 = Kick and log to .log file only
6 = Kick and log to console only
7 = Kick and log to both

Console refers to the window which opens when running the Arma server.exe. The console always shows all connects, disconnects and kicks. Its output is saved in a .txt file in the config directory if logFile option is set in server.cfg. It is also visible when connected over Rcon.

Logging to .log is recommended because it creates separate .log files in the \BattlEye\ folder for each restriction type. This makes it much easier to review than one large console log file with all types mixed together.

Logging to console is only useful if a live stream of BE logs is needed over Rcon. Beware it increases server resource usage, especially when streaming frequently written to logs. It also tends to flood Rcon and make connect, disconnect and kick messages difficult to read. For this reason logging to console is not advised unless your filters are configured to log very little. It should also be noted logging to both console and .log with logFile set in server.cfg is writing the same data to disk in two different files.

Adding keywords:
On a new line add the number followed by a single space and a keyword:
5 keyword

If a keyword contains spaces it must be enclosed in double quotes:
5 "key word"

If a keyword contains double quotes " they must be preceded by a \ like so:
5 "key \"word\""

If a keyword contains regex metacharacters ({}[]()^$.|*+? and \) they must also be preceded by a \ like so:
5 "key \(word\)"

Note: The one exception to this rule is scripts.txt. Currently it is the only filter that does not support regex. It will be added later according to Bastian. This means the only characters that need to be preceded with a \ in scripts.txt are ", \ and line breaks for now.

Use keywords that catch multiple strings when possible. For example, say in createVehicle.txt you want to kick for spawning humvees. Instead of adding a keyword for each class name like this:
5 HMMWV_DES_EP1
5 HMMWV_M1035_DES_EP1
5 HMMWV_Ambulance_DES_EP1
...


It is more efficient to use a single keyword that covers all humvees:
5 HMMWV_

To catch everything use empty double quotes for the keyword "" or leave it blank:
5 ""

Adding exceptions (fixing unwanted kicks):
On the same line add a single space after the keyword. Then add either != or ! with the exception:
5 keyword !keywordException

Exceptions follow the same rules as keywords. If an exception contains spaces it must be enclosed in double quotes:
5 keyword !"keyword exception"

If an exception contains double quotes " they must be preceded by a \ like so:
5 "key word" !"key word \"exception\""

If an exception contains regex metacharacters ({}[]()^$.|*+? and \) they must also be preceded by a \ like so:
5 keyword !"keyword \(exception\)"

Note: Again this regex rule does not apply to scripts.txt.


The two options for exceptions are:
  • != The parameter must exactly match the exception. In scripts.txt the entire statement the keyword is found in must exactly match the exception.
  • ! The parameter must contain the exception. In scripts.txt the statement the keyword is found in must contain the exception.

For example, if this is our createvehicle.txt filter:
5 "HMMWV_" !"HMMWV_Ambulance"

The code example below will not kick because the type parameter contains HMMWV_Ambulance which is an exception:
createVehicle ["HMMWV_Ambulance_DES_EP1",getPosATL player,[],10,"NONE"];

The code example below will kick because the parameter does not contain HMMWV_Ambulance:
createVehicle ["HMMWV_DES_EP1",getPosATL player,[],10,"NONE"];

If we change our filter to use != like so:
5 "HMMWV_" !="HMMWV_Ambulance"

Now both of the above code examples will kick because the parameters are not exact matches to HMMWV_Ambulance. The below code example will not kick because it is an exact match:
createVehicle ["HMMWV_Ambulance",getPosATL player,[],10,"NONE"];

Exceptions work differently in scripts.txt as noted above. For example, if this is our filter in scripts.txt:
5 keyword !=keywordException

The code example below will kick because the exception is not an exact match to the statement:
systemChat "keywordException";

To fix we need to change the filter to include the entire statement as an exception:
5 keyword !="systemChat \"keywordException\";"

Now the above code example will not kick.

Note: Statements can span multiple lines. For example:
Code:
if (2 > 1) then
{
    systemChat "keywordException"
};
There is no semicolon ; on the end of the systemChat line, so the above code still kicks. Line breaks can be escaped with \n:
5 keyword !="if (2 > 1) then\n{\nsystemChat \"keywordException\"\n};"

The filter could also be changed to use ! instead of != so the statement the keyword is found in must only contain the exception:
5 keyword !keywordException
Now both of the above code examples will not kick.

In general exceptions should be written with != when ever possible. Using ! allows much more through the filter. There are some exceptions to this, such as the createvehicle.txt HMMWV_Ambulance example above. In that case it is more efficient to use a single ! exception to allow multiple class names, rather than multiple != exceptions. Many more fancy things can be done in filters that support regex. To learn more about regex check this out.

Note: BE filters are not case sensitive, but they are sensitive to single spaces and line breaks. Tabs are automatically stripped out in scripts.txt.

Below is a walk through of each filter file in this format:
filename.txt:
  • [Filters] Which command(s) parameter(s) are searched for keywords
  • [Kick] Suggested keywords to kick and log (5)
  • [Log] Optional keywords to log (1). Opting to log extra keywords may provide more information for identifying cheaters and monitoring server activity. The trade off is larger logs to review, extra resource usage from searching for more keywords and more writes to disk.
  • [Logs] Additional info the log file shows
  • [Abuse] How the command(s) can be abused by cheaters (if no other prevention is in place)
 
Last edited:
======================================
Note:
I am not suggesting creating filter files from scratch. You should start with the files the developers have provided for your mod or antihack, since they have already done the hard work of creating and testing them. From there you may want to customize them further using this guide, but it is by no means necessary. [Kick] and [Log] are generalized suggestions for all of Arma. They may not be appropriate or feasible for your particular mod.
======================================



addbackpackcargo.txt:
  • [Filters] addBackpack[Cargo][Global] pack name parameter.
  • [Kick] for all backpack classes that are unobtainable in your mod.
  • [Log] all or just rare backpacks.
  • [Abuse] addBackpack can be used to spawn backpacks.
addmagazinecargo.txt:
  • [Filters] addMagazine[Cargo][Global] magazine name parameter.
  • [Kick] for all magazine classes that are unobtainable in your mod.
  • [Log] all or just rare magazines.
  • [Abuse] addMagazine can be used to spawn magazines and items.
addweaponcargo.txt:
  • [Filters] addWeapon[Cargo][Global] weapon name parameter.
  • [Kick] for all weapon classes that are unobtainable in your mod.
  • [Log] all or just rare weapons.
  • [Abuse] addWeapon can be used to spawn weapons and toolbelt items.
Note: When players take items from storage (crates, bodies, weapon holders, vehicle cargo, etc.) add[Backpack/Magazine/Weapon]CargoGlobal run automatically on their client and will show in these logs. These filters only apply to items added to global objects by the client. Adding gear to local objects with the local commands will not trigger them. However, your player is a global object. Taking items from a local object or adding them to your player will trigger them.

attachto.txt:
  • [Filters] attachTo object class name parameter. Only applies to global objects, local objects will not trigger it.
  • [Kick] for all global objects which are not possible for the client to attachTo in your mod.
  • [Log] all except the most common uses.
  • [Logs] the object, target object and offset.
  • [Abuse] attachTo can be used to attach objects and players together for various purposes, including teleporting.
Note: R3F and BTC scripts use attachTo on vehicles and other objects. DayZ mods use attachTo when dragging injured players, placing tents and buildables (epoch) and shooting crossbows.

createvehicle.txt:
  • [Filters] createVehicle and createUnit type parameter. Applies to global objects, local objects will not trigger it.
  • [Kick] for all global objects which are not possible for the client to create in your mod.
  • [Log] all except the most common uses.
  • [Logs] the object class name and position.
  • [Abuse] createVehicle can be used to create buildings, vehicles, ammo boxes, bombs and other objects.
Note: Arma creates animals automatically on the client if environment is enabled. A few explosions are also created automatically on the client when vehicles are destroyed such as SmallSecondary, HelicopterExploBig and HelicopterExploSmall.

deletevehicle.txt:
  • [Filters] deleteVehicle object parameter. Only applies to global objects, local objects will not trigger it.
  • [Kick] for all global objects which are not possible for the client to delete in your mod.
  • [Log] all except the most common uses.
  • [Abuse] deleteVehicle can be used to delete objects such as vehicles, AI units and buildings.
Note: In DayZ mods the client deletes zombies when they are the last one to leave an area. They also delete safes and some other buildables while removing them (Epoch).

mpeventhandler.txt:
  • [Filters] addMPEventHandler command parameter.
  • [Kick] for all except the exact command strings your mod needs to add on the client.
  • [Abuse] addMPEventHandler can be used to add event handlers to remote players and objects. The code is then executed on the remote machines when the event handlers are triggered.
publicvariable.txt:
  • [Filters] publicVariable[Server] variable names.
  • [Kick] for all variable names except the exact ones your mod needs to broadcast from the client.
  • [Log] all or just the broadcasts you wish to keep a record of.
  • [Logs] show the variable name and broadcast value.
  • [Abuse] publicVariable can be used to broadcast variables to the server and all connected clients. Overwriting existing global variable values is possible (though this is preventable in Arma 3 with compileFinal).
Note: MPF or the Arma 3 equivalent BIS_fnc_MP use the variable names remExField, remExFP and BIS_fnc_MP_packet respectively. Antihack scripts like infistar broadcast public variables from the client to log activity and announce detections to admins. Most mods also broadcast some public variable from the client to announce player logins (dayz, altis life).

publicvariableval.txt:
  • [Filters] the value assigned to the variable being broadcast with publicVariable[Server].
  • [Kick] How you configure this filter depends on how (or if) you use public variables on the client, but the goal is to restrict what can be sent to the server and other clients. Kicking for commands and critical variable and function names can be useful to prevent sending code which will later be compiled and executed.
  • [Logs] are included in publicvariable.log in the same format as publicvariable.txt. Since they both show the same information, logging everything in publicvariable.txt will make logging in this file unnecessary.
  • [Abuse] publicVariable can be used to send code and other values to the server and all connected clients. The value may later be used or even compiled and executed on the remote machines.
Note: This will also apply to the parameters passed to call RE (MPF) or BIS_fnc_MP since they are assigned to a public variable. Be careful of what keywords you kick for if your mod broadcasts public variables with wildcard values (like player names or text input boxes). The user could enter anything.

remotecontrol.txt:
  • [Filters] remoteControl use.
  • [Kick] for all unless your mod needs this command.
remoteexec.txt:
  • [Filters] setVehicleInit statements when processInitCommands runs, the init fields of newly created units and both the condition and statement parameters of setWayPointStatements.
  • [Kick] for all except the exact strings you need to use in the init fields of units created on the client. If using setWayPointStatements command you will need to add the same exceptions from waypointcondition.txt and waypointstatement.txt mentioned below.
  • [Abuse] vehicle inits can be used to remotely execute code on the server and all connected clients.
Note: Logic units usually have code predefined in their init in cfgVehicles. This filter is tied to waypointcondition.txt and waypointstatement.txt. Use of setWayPointStatements command requires !="true" and !="" to be added as exceptions in this file. Any other exceptions from those two files will also need to be added to this one.
 
Last edited:
scripts.txt:
  • [Filters] all scripts running on the client.
  • [Logs] the statement that included the keyword and a few lines in the script surrounding it. This can be useful because it reveals more content from cheat scripts. That information can then be used to add to anticheat.
Note: Currently scripts.txt is the only filter that does not support regex. This means the only characters that need to be preceded with a \ in scripts.txt are double quotes " and \ itself (when used literally).

This is the most intensive of the filters because it searches all scripts running on the client instead of just specific command parameters. For this reason it is recommended to limit the number of keywords in this file. Using commands is usually more inclusive than specific statements, strings or variable names. Like publicvariableval.txt, be careful of what keywords you kick for if your mod uses variables with wildcard values (such as player names or text input boxes). The user could enter anything.

Scripts running on the client can include both the mission and server addon scripts. Scripts from Arma game addons and BIS functions also run automatically on the client during mission load and when certain actions are performed. This means only searching the mission and server pbo for occurrences of a keyword is not good enough. You will need to test your scripts.txt thoroughly to ensure all legitimate exceptions are included.

selectplayer.txt:
  • [Filters] selectPlayer unit class name parameter.
  • [Kick] for all unit class names except those that are selectable in your mod.
  • [Log] everything
  • [Logs] the class name of the unit being selected and its position.
  • [Abuse] selectPlayer can be used to change into animal or other normally unobtainable skins, and control players.
Note: When picking a slot in the lobby the client is using selectPlayer on the type of unit that occupies that slot in mission.sqm. In DayZ mods selectPlayer is also used when changing clothes.

setdamage.txt:
  • [Filters] setDamage number parameter. Only applies to global objects, local objects will not trigger it.
  • [Kick] for all except the values your mod needs to use from the client onto global objects.
  • [Log] everything
  • [Logs] the number value and the class name of the object being damaged.
  • [Abuse] setDamage .9+ can be used to destroy objects and kill players. setDamage 0 can be used to repair vehicles.
Note: Ideally your scripts will be written so no exceptions are needed. Exceptions need to be written with six digits after the decimal point due to Arma's number format. Epoch uses setDamage in several places including attacking as player zombie, repairing vehicles and chopping down trees.

setpos.txt:
  • [Filters] setPos[ASL/ATL] object classname parameter. Applies to global objects, local objects will not trigger it.
  • [Kick] for all except global objects your mod allows the client to use setPos on.
  • [Log] everything
  • [Logs] the object class name and new position.
  • [Abuse] setPos can be used to teleport players and objects.
Note: Placing height adjusted buildings, units and objects in the editor may automatically put setPos commands in their init field in mission.sqm. The init field runs on all clients, so it is advisable to instead use setPos commands outside of the init field and on the server only. R3F and BTC scripts also use setPos on vehicles and objects.

setvariable.txt:
  • [Filters] setVariable variable name parameter. Only applies to public setVariable (i.e. third parameter must be true), local setVariable will not trigger it.
  • [Kick] for all variable names except the exact ones your mod uses for public setVariable from the client.
  • [Log] all or just the variables you wish to keep a record of, depending on how frequently public setVariable is used from the client.
  • [Logs] the variable name, stored value and class name of the object it is being set on.
  • [Abuse] setVariable can be used to change values of variables set on players and objects such as humanity (dayz), money (wastedland, altis life), etc.
setvariableval.txt:
  • [Filters] the value being stored on an object with setVariable. Only applies to public setVariable (i.e. third parameter must be true), local setVariable will not trigger it.
  • [Kick] How you configure this filter depends on how (or if) you use public setVariable on the client, but the goal is to restrict what can be sent to the server and other clients. Kicking for commands and critical variable and function names can be useful to prevent sending code which will later be compiled and executed.
  • [Logs] are included in setvariable.log in the same format as setvariable.txt. Since they both show the same information, logging everything in setvariable.txt will make logging in this file unnecessary.
  • [Abuse] public setVariable can be used to store code and other values on remote objects. The value may later be used or even compiled and executed on the remote machines.
Note: Like publicvariableval.txt and scripts.txt, be careful of what keywords you kick for if your mod uses public setVariable with wildcard values (such as player names or text input boxes). The user could enter anything.

teamswitch.txt:
  • [Filters] teamSwitch use.
  • [Kick] for all unless your mod needs this command.
waypointcondition.txt:
  • [Filters] setWayPointStatements condition parameter.
  • [Kick] for all unless your mod needs this command. If it is needed kick for all except the exact condition strings your mod uses.
  • [Logs] the [condition, statement] array and the group the waypoint belongs to.
Note: As soon as a waypoint finishes Arma automatically runs setWaypointStatements again with a condition of "true". This means if you use this command at all you will always need to add !="true" as an exception in this file.

waypointstatement.txt:
  • [Filters] setWayPointStatements statement parameter.
  • [Kick] for all unless your mod needs this command. If it is needed kick for all except the exact statement strings your mod uses.
  • [Logs] the [condition, statement] array and the group the waypoint belongs to.
  • [Abuse] setWayPointStatements statement parameter can be used to remotely execute code on the server and all connected clients.
Note: As soon as a waypoint finishes Arma automatically runs setWaypointStatements again with an empty string "" as the statement. This means if you use this command at all you will always need to add !="" as an exception in this file.
 
Last edited:
BEServer.cfg:
This file can be found in the \BattlEye\ folder. While the server is running it is automatically renamed to BEServer_active_xxxx.cfg for security. It must contain at least the server MaxPing and RConPassword. It can also contain some extra settings. Here is an example file:
Code:
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

The format is:
Max[Command]PerInterval [max number of uses in] [time in seconds]
In the example if setDamage is used 30 times or more in 1 second or less it will kick for setDamage count restriction.

The value used for max number of uses per second will vary widely depending on the mod. The above values are a loose example for DayZ mods. To get the best values you will need to experiment with each command starting with the strictest (lowest) limit possible and increasing it until no legitimate kicks are caused. This will require a lot of testing because only certain actions or events may trigger a kick. The time can also be raised to make the limit even stricter.

MaxSetPosPerInterval
  • [Limits] setPos[ASL/ATL] use on global objects.
  • [Abuse] setPos can be spammed to quickly teleport all players (50+) or objects (300+) on a server.
Note: Keep in mind the note under setPos above about height adjusted global buildings. When loading in they can run setPos hundreds of times on the client in under a second (depending on the number of buildings). To avoid this buildings should be spawned and positioned on the server machine only.

MaxSetDamagePerInterval
  • [Limits] setDamage use on global objects.
  • [Abuse] setDamage can be spammed many times to quickly kill all players (50+), destroy all vehicles (300+) or objects and buildings (thousands) on a server.
MaxAddBackpackCargoPerInterval
  • [Limits] addBackpack[Cargo][Global] use.
  • [Abuse] addBackpack can be spammed to quickly spawn many backpacks.
MaxAddMagazineCargoPerInterval
  • [Limits] addMagazine[Cargo][Global] use.
  • [Abuse] addMagazine can be spammed to quickly spawn many magazines and items.
Note: When players take items from large storage units like ammo boxes, safes and vehicle cargo addMagazine runs automatically on their client many times per second.

MaxAddWeaponCargoPerInterval
  • [Limits] addWeapon[Cargo][Global] use.
  • [Abuse] addWeapon can be spammed to quickly spawn many weapons.
Note: When players take weapons from large storage units like ammo boxes, safes and vehicle cargo addWeapon runs automatically on their client many times per second.

MaxDeleteVehiclePerInterval
  • [Limits] deleteVehicle use on global objects.
  • [Abuse] deleteVehicle can be spammed to quickly delete all vehicles (300+) or objects (thousands) on a server.
Note: If running server cleanup scripts from the client you will be deleting hundreds of objects including bodies, weapon holders, wrecks, flies, etc. from the client. Normally the cleanup runs on the server only in DayZ mods.

MaxCreateVehiclePerInterval
  • [Limits] global createVehicle, createUnit and createAgent.
  • [Abuse] createVehicle can be spammed to mass spawn objects on a server.
bans.txt:
This is the ban list. You can add to this automatically via Rcon tools. To manually add a ban you will first need the player's GUID and IP. You can get this from the console .txt logFile in the server config directory or Rcon. Every time a player joins the server an entry is made in the console like this:
Code:
12:06:56 BattlEye Server: Player #3 Hunter (88.111.22.333:2304) connected
12:06:56 Player Hunter connecting.
12:06:57 BattlEye Server: Player #3 Hunter - GUID: 5c7d9d6ec60869824ae5f1e6cadd1111 (unverified)
12:06:58 BattlEye Server: Player #3 Hunter - Legacy GUID: ef68da39ea1bb994aba33caa16552222

Note: use the GUID not Legacy GUID when banning. New GUID is more inclusive because it is tied to the steam account and registry key. Legacy GUID is only tied to registry key. Do not include the port number (last four digits after colon) when IP banning.

Scroll to the bottom of bans.txt and add a new line like this (for IP):
88.111.22.333 -1 (Hunter - spawningGear)

Then scroll up a little to where you see the GUID bans start and add another new line like this:
5c7d9d6ec60869824ae5f1e6cadd1111 -1 (Hunter - spawningGear)

The format is:
GUIDorIP time (Reason)

Save the file. Go to your Rcon program like DaRT and hit the reload bans button. This refreshes the banlist and takes effect immediately without need for server restart.

To remove a ban just delete the GUID line and IP line corresponding to the player you want to unban. Save the file and reload bans over Rcon. Banning both GUID and IP make it harder for a player to rejoin. Including the player name in the reason field makes it easy to unban later.

Automatic banning:
Kicking for BE restrictions is of limited use, because a cheater can rejoin. Sadly, filters do not have a built in autoban option. For this you need to use a third party tool. One of the easiest is BEC ScriptBan Plugin. If BEC is already installed on your dedicated server simply create a new folder inside the \Bec\ folder called \Plugins\. Place the downloaded \ScriptBan\ folder in the \Plugins\ directory. If you are using a managed host plugins will probably not be an option.

Configuration can be done by editing the reason.py file in a text editor. Here is an example file for reference:
http://pastebin.com/SJMKM2KZ

In the top field enter the name of your BEC config file:
SERVERS = ["Config.cfg"]

Below fill out each restriction type with the restriction numbers to ban for, reason and time. For example:
Code:
waypointstatement_reason    = {
   "0" : ["WPS0 - appeal at myWebsite.com", 0]
}

This will ban anyone kicked for waypointstatement restriction #0 with a ban reason of "WPS0 - appeal at myWebsite.com" and a time of 0 hours (indefinite). Their GUID will be added to bans.txt in the \BattlEye\ folder.

With a comment at the top of a filter like:
//new
5 ""

The restriction # that corresponds to 5 "" will be 0, even though the line number shows 2 in your text editor. This is because BE begins counting restriction numbers at 0 on the first line that is not a comment. So when looking at a filter in your text editor subtract 2 from the current line number to get the restriction number (assuming there is only one comment and it is on the first line). For simplicity avoid using comments in your filters.

Be particularly careful of banning scripts.txt, publicvariableval.txt and setvariableval.txt restrictions for the reasons mentioned in their notes above. It is possible for cheaters to remotely execute code on other clients in Arma. The exploits that allow this are much fewer now than in the past, and BIS is working to fix them. Despite these potentials for false bans, automatic banning is still strongly recommended for increased security.

Rotating logs:
Rotating BE, console, server RPT, hiveExt and other logs makes finding specific restarts by date and time easy. It also keeps logs small and readable, so you can quickly find what you are looking for. Here is an example log rotate script to run on server restart. The only changes you need to make are on the first two lines:
http://pastebin.com/iqDgL5Dv
Code:
set arma2srvpath=C:
set srvname=cfgdayz

Change C: to your server config directory path (leave off the last \). Change cfgdayz to the name of your config folder. In the above example the server config directory is C:\cfgdayz. If you have changed the name of the server.exe from the default replace all occurrences of arma2oaserver with the new server.exe name. For Arma 3 use this instead:
http://pastebin.com/06WkdDXB

Final note:
BE filters do provide an extra level of protection. Since Arma is such an open engine it needs every bit of protection it can get. It takes a little work to add exceptions for custom scripts, but other than that they require minimal configuration to use.

It is never advised to use no filters or even worse disable BE :eek:. At a bare minimum there is no reason not to have mpeventhandler, remotecontrol, remoteexec, teamswitch, waypointcondition and statement .txt files configured to prevent blatant remote execution. Also at a bare minimum these security settings:
https://community.bistudio.com/wiki/server.cfg#Server_Security
 
Last edited:
My battleye does not have scripts.txt. I cannot find it anywhere to download. Where can I find it? I want to put this in my battleye folder.
 
Back
Top