Admin Toolset with a plethora of features, basically the default "In-Game Admin" with 1500+ hours of enhancements and features added. AdKats focuses on making in-game admins more efficient and accurate at their jobs, with flexibility for almost any setup. Includes a cross-server ban enforcer more reliable and complete than others available, and the AdKats WebAdmin for out-of-game control has been released. Designed for groups with high-traffic servers and many admins, but will function just as well for small servers.

• Basic Action Commands. Standard commands for player killing, kicking, punishing, banning, unbanning, moving, etc...Over 30 available in-game commands. Commands can be accessed from almost anywhere: In-game, Procon's chat window, database, HTTP server, other plugins, etc, etc...
• Editable Ranks and Roles. Custom ranks and roles can be created for users, with each role given access to only the commands you want them to access. Default guest role is given to all players, and can be edited to your desired specs. All roles and powers are automatically synced between servers, so you only need to change user information once. Soldiers assigned to users will also keep their powers even if they change their in-game names.
• Admin and setting sync between servers. All changes to plugin settings are stored in the database, and can be automatically synced between your Procon layers.
• Infraction Tracking System. Punish/Forgive players for infractions against your server. Everything is tracked, so the more infractions they commit, the worse their punishment gets. Made so all players are treated equally. Heavily customizable.
• Quick Player Report and Admin Call Handling, with email support. Notification system and quick handling features for all admin calls and player reports. Reports can be referenced by number for instant action.
• Orchestration and Server List Management. Server reserved slots, server spectator slots, and autobalancer whitelising through MULTIBalancer can all be automatically done through the AdKats user list.
• Admin Assistants. You can choose to give a small perk to players who consistently provide you with accurate player reports. Documentation linked below.
• BF3/BF4 "Hacker-Checker" with Whitelist. BF3Stats and BF4Stats are internally used to pull player information, and can be enabled for hacker-checking with a couple clicks. Please read documentation before enabling.
• Email Notification System. Email addresses can be added to every user, and once enabled they will be sent emails for player reports and admin calls. I am currently working on adding command parsing on reply to emails, and possibly text message command support in the future.
• Fuzzy Player Name Completion. Fully completes partial or misspelled player names. I've been consistently able to find almost any player with 3-4 characters from their name.
• Player Muting. Players can be muted if necessary.
• Player Joining. Player's squads can be joined via command, and locked squads can be unlocked for admin entry.
• Yell/Say Pre-Recording. Use numbers to reference predefined messages. Avoid typing long reasons or messages. e.g. @kill player 3
• Server rule printing. Just like "Server rules on request" except multiple prefixes can be used for rule commands at the same time, and requests for rules are logged.
• External Controller API. AdKats can be controlled from outside the game through systems like AdKats WebAdmin, and soon through other plugins like Insane Limits.
• Internal Implementation of TeamSwap. Queued move system for servers that are consistently full, players can be queued to move to full teams once a slot opens. Greatly improved over the default version. Documentation linked below.
• AdKats Ban Enforcer. AdKats can enforce bans across all of your servers, and can enforce on all metrics at the same time. The internal system has been built to be more complete and reliable than others available, including metabans, and is further enhanced by using AdKats WebAdmin. It will automatically import all Procon bans from all your servers and consolidate them. It will also import any existing bans from the BF3 Ban Manager plugin's tables. Full documentation linked below.
• Editable In-Game Commands. All command text, logging options, and enable options can be edited to suit your needs.
• Full Logging. All admin activity is trackable via the database per your custom settings for every command; So holding your admins accountable for their actions is quick and painless. And, if you are using AdKats WebAdmin nobody but your highest admins will need direct Procon access.
• Performance. All actions, messaging, database communications, and command parsing take place on their own threads, minimizing performance impacts.

If you find any bugs, please submit them HERE and they will be fixed ASAP.

Download the latest version here: Version 4.0.0.0

AdKats was inspired by the gaming community A Different Kind (ADK). Visit http://www.adkgamers.com/ to say thanks!

1. Install XpKiller's Stat logger plugin. Make sure stat logger is installed and running! Do NOT attempt to install AdKats until that plugin is running without issue.
2. Set up the database. Run the contents of this sql script on your database (You can copy/paste the entire page as its shown): https://raw.github.com/ColColonCleaner/AdKats/master/adkats.sql
   (I would run this automatically if I could, but i'm limited until Procon updates their MySQL connector to allow delimiters)
3. Add plugin file to Procon. Add the plugin file to Procon as you would any other, in either the plugins/BF3 or plugins/BF4 folder depending on which game your layer is running on.
4. Enter database credentials. All database connection information must be entered in the settings tab before AdKats can run.
5. Enable AdKats. AdKats will confirm all dependencies and show confirmation in the console. If it gives your server an ID then all is well.
6. Disable the default "In-Game Admin". Disable any other plugins that use commands like kill, kick, etc. The commands would be run by both, causing unwanted functionality. Enjoy AdKats!

If you have any problems installing AdKats please let me know on the MyRCON forums, or here as an issue and I'll respond promptly.

A MySQL database accessible from your Procon layer is required. AdKats checks the database for needed tables on connect.

Getting a Database: Usually the hosting company for your layers can provide you a database, and using that is advisable as the latency between Procon and the DB will be the lowest possible. Or even better if you're hosting layers on a VPS just create a local database by downloading the appropriate installer from MySQL's website. We use our webserver for database hosting and that works great. Be cautious of free database options and services, those paths usually have restrictions on database size and are hosted on unreliable servers, which can lead to many problems down the road.

Version 1.1.0.1+ of the BF3 version, or any universal version is required. AdKats will only run if one of these plugins is (1) using the same database AdKats uses, and (2) running on every battlefield Server you plan to install AdKats on. Running it along-side AdKats on each Procon layer will ensure these conditions are met.

The latest universal version of XpKiller's Stat Logger can be downloaded from here: Procon Chat, GUID, Stats and Mapstats Logger

Infraction Tracking commands take the load off admins remembering which players have broken server rules, and how many times. These commands have been dubbed "punish" and "forgive". Each time a player is punished a log is made in the database; The more punishes they get, the more severe the action gets. Available punishments include: kill, kick, temp-ban 60 minutes, temp-ban 1 day, temp-ban 1 week, temp-ban 2 weeks, temp-ban 1 month, and permaban. The order and severity of punishments can be configured to your needs.

Detailed Stuff: After a player is punished, their total points are calculated using this very basic formula: (Punishment Points - Forgiveness Points) = Total Points Then an action is decided using Total Points from the punishment hierarchy. Punishments should get harsher as the player gets more points. A player cannot be punished more than once every 20 seconds; this prevents multiple admins from accidentally punishing a player multiple times for the same infraction.

When a player is punished, and has already been punished in the past 10 minutes, the new punish counts for 2 points instead of 1 since the player is immediately breaking server rules again. A punish worth 2 points is called an "IRO" punish by the plugin, standing for Immediate Repeat Offence. "[IRO]" will be appended to the punish reason when this type of punish is activated.

The punishment hierarchy is configurable to suit your needs, but the default is below.

Players may also be 'forgiven', which will reduce their Total Points value by 1 each time, this is useful if you have a website where players can apologize for their actions in-game. Players can be forgiven into negative total point values which is why a 'less than 1' clause is needed.

You can run multiple servers with this plugin on the same database; A different ID is automatically assigned to each server. If you want punishments to increase on this server when infractions are committed on others set "Combine Server Punishments" to true. Rule breaking on another server won't cause increase in punishments on the current server if "Combine Server Punishments" is false. This is available since many groups run different rule sets on each server they own, so players breaking rules on one server may not know rules on another, so they get a clean slate.

Suggestions: When deciding to use this system, 'punish' should be the only command used for player rule-breaking. Other commands like kill, or kick are not counted in the system since sometimes players ask to be killed, admins kill/kick themselves, or players get kicked for AFKing. Kill and kick should only be used for server management. Direct tban and ban are of course still available for hacking/glitching situations, but that is the ONLY time they should be used.

AdKats can now enforce bans accross all of your servers within seconds of the ban being issued. The Ban Enforcer will import and consolidate all bans from every Procon instance you run. Bans can be made by name, GUID, IP, any combination, or all at once. The default ban is by EA GUID only, this default can be edited but is not recommended. Banned players are told how long their ban will last, and when a banned player attempts to re-join they are told the remaining time on their ban. Using ban enforcer also gives access to the @unban in-game command.

The Enforcer works properly with all existing auto-admins, and any bans added manually through Procon will be automatically imported by the system. A mini-ban-management section is added to the plugin settings when you enable this, however, for full ban management it requires AdKats WebAdmin. Ban enforcer's options are simply too much for the plugin setting interface to house properly. Use of the ban enforcer is optional because of this slight dependency, and is disabled by default.

Ban Enforcer can be enabled with the "Use Ban Enforcer" setting. On enable it will import all bans from your ban list then clear it. Once you enable enforcer you will be unable to manage any bans from Procon's banlist tab. Disabling ban enforcer will repopulate Procon's banlist with the imported bans, but you will lose any additional information ban enforcer was able to gather about the banned players.

Reasoning behind creation, for those interested: We had tried many other ban management systems and they all appeared to have some significant downfalls. Developing this allowed for some nice features not previously available. I can bypass Procon's banlist completely, this way no data is lost on how/why/who created the ban or on who it's targeted. I can enforce bans by any parameter combination (Name, GUID, IP), not just one at a time. Players can now be told how much time is left on their ban dynamically, every time they attempt to join. And tracking of bans added through in-game commands or autoadmins on any server is a cakewalk now, so clan leaders don't need to go great lengths to look things up. Several other reasons as well, but overall it was a fantastic move, and thankfully we had the devs available to make it. .

When a player puts in a proper @report or @admin all in-game admins are notified. All reports are logged in the database with full player names for reporter/target, and the full reason for reporting. All uses of @report and @admin with this plugin require players to enter a reason, and will tell them if they haven't entered one. It will not send the report to admins unless reports are complete, which cleans up what admins end up seeing for reports.

All reports and calls are issued a random three digit ID which expires either at the end of each round, or when it is used. These ID's can be used in any other action command, simply use that ID instead of a player-name and reason (e.g. waffleman73 baserapes, another player reports them and gets report ID 582, admins just use @punish 582 instead of @punish waffleman73 baserape). Confirmation of command with @yes is required before a report ID is acted on. Players are thanked for reporting when an admin uses their report ID.

When email usage is enabled, all users with access to player interaction commands will get an email containing the report information.

When a player sends a report, then an admin uses that report by ID, it is considered a "good" report. When a player has X good reports in the past week a small bonus can be given; Access to TeamSwap. When a player gets access it simply tells them "For your consistent player reporting you now have access to TeamSwap. Type @moveme to swap between teams as often as you want." They do not know they are considered an admin assistant, only that they have access to that. Whether a player is an admin assistant is calculated when they join the server, and that status will remain for the duration they are in the server. They need to keep that report count up to keep access.

When an admin assistant sends a report, to the admins that report is prefixed with [AA] to note it as a (most likely) reliable report. Whether admin assistants get the TeamSwap perk can be disabled, but the prefixes admins see will remain.

Players can be muted using the mute command. Muting lasts until the end of the round. Players who talk in chat after being muted will be killed each time they talk (up through X chat messages). On the (X+1)th chat message they are kicked from the server. A player coming back during the same round is kicked again on their first chat message. No action other than kill or kick is used by this system. There will be no way to un-mute players, there was a reason they were muted, and they can talk again next round. Admins cannot mute other admins.

Players can be joined using the join command. Joining either works off of player name or report ID. Issuing the command will place you in the targeted player's squad if there is room available. The command is available to all players, but for the general public will only operate for the same team. If user has TeamSwap or higher access, this will work across teams. If user has admin access, the target squad will be unlocked for their entry. NOTE: For cross-team joining, TeamSwap queues are not used, so if there is no room on the target team you will need to retry the command once room is available.

A list of editable pre-defined messages can be added in settings, then admins can use the message ID instead of typing the whole message in. Example: "@say 2" will send the second pre-defined message.

Use @whatis [preMessageID] to find out what a particular ID links to before using it in commands.

Anywhere a reason or message is needed, a preMessage ID can be used instead.
Example: 4th preMessage is "Baserape. Do not shoot uncap."
"@punish muffinman 4" will punish them for the above reason. Even more useful is using report IDs with this, for example someone reports muffinman for "baseraping asshat" and gets report ID 283. You don't want "baseraping asshat" to be the actual reason entered, so you can just do "@punish 283 4", and he will get the proper punish message.

TeamSwap is NOT an autobalancer (look up other plugins for that functionality), it is for manual player moving only.

TeamSwap is a server-smart player moving system which offers two major benefits over the default system. Normally when trying to move a player to a full team the command just fails at the server level, now the player is dropped on a queue until a slot opens on that side. They can keep playing on their side until that slot opens, since when it does they are immediately slain and moved over to fill it. Secondly it allows whitelisted (non-admin) players the ability to move themselves between teams as often as they want (within a ticket count window). This is currently not an available option in default battlefield aside from Procon commands since the game limits players to one switch per gaming session. Whitelisted players can type '@moveme' and TeamSwap will queue them. This is meant to be available to players outside the admin list, usually by paid usage to your community or to clan members only. Admins can also use '@moveme', and in their case it bypasses the ticket window restriction.

Auto-Whitelisting: X players per round can be auto whitelisted for TeamSwap. This means at the start of each round X random players have the TeamSwap command added to their list of allowed commands for that round. This elevation is not persisted in the database, and will only apply to the current server and round. It is used to make players want full access, so they might buy access, or join your community to get it. The setting is "Auto-Whitelist Count", under TeamSwap settings. This can be disabled by setting auto-whitelist count to 0.

All commands which might lead to actions against players are required to have a reason entered, and will cancel if no reason is given. Players (even the most atrocious in some cases) should know what they were acted on for, and it's also a good way to hold admins accountable for their actions. The minimum number of characters for reasons is editable in plugin settings. The editable setting only applies to admin commands, and the default value is 5 characters. Reports and Admin calls are hardcoded to 1 character minimum reason lengths.

Plugin settings are automatically synced to layers every 5 minutes from their particular server IDs. All settings for each plugin instance are stored in the database by server ID. Enter an existing server ID in the setting import field and all settings from that instance will be imported to this instance. All settings on the current instance will be overwritten by the synced settings. Whenever a setting is changed, that change is persisted to the database.

Ever since we started running servers we never banned off of "cheat-o-meter" results, since there were too many false positives, so we built our own. This code has been dormant in AdKats for several months now, only activating on =ADK= servers while we tested it. We are releasing the fully tested BF3 and BF4 versions now.

The hacker-checker uses BF3Stats.com and BF4Stats.com for player stats, and is able to catch both aimbots and damage mods. To avoid false positives, only weapons that fire bullets (no crossbow, 320, etc), and deal less than 50% damage per shot are included in the calculations. This removes all equipment, sniper rifles, shotguns, and heavy-hitting pistols like the magnum/rex from calculations. For the remaining weapons there are two checks each one goes through, customizable to your desired trigger levels.

Damage per shot for all known weapons is held on the AdKats repository, and is downloaded when the plugin enables. The damage per shot each player gets with that weapon is calculated from BF3Stats/BF4Stats. The threshold you set for this check is the percentage above normal required to trigger the ban. We have ours set at 50% above normal damage (just 50 in the setting). e.g. A weapon is dealing at least 150% of the damage it normally should. (A 25 DPS assault rifle is dealing 37.5+ DPS) Every ban on trigger level 50 on our servers has been examined personally, and this check has never triggered a false positive. 50 kills with the weapon in question are required to trigger a ban using this check.

For this check only automatic weapons from specific categories are used in the calculation. This includes Sub Machine Guns, Assault Rifles, Carbines, and Machine Guns. Handguns, snipers, equipment, etc are not included since their HSK values can vary drastically. This limit is simple, if the headshot/kill percentage for any valid weapon is greater than your trigger level, the ban is issued. HS/K percentage for even the top competitive players caps at 38%, so we set our value much higher than that. We started with 70% HS/K, and no false positives were found with that value, but lower as desired. The minimum we allowed during testing was 50%. 100 kills with the weapon in question are required to trigger this check.

The heaviest hacked weapon (the one farthest above normal) is the one displayed in the ban reason using the following formats:
Damage Mod Bans:
Hacking/Cheating DPS Automatic Ban [WEAPONNAME-DPS-KILLS-HEADSHOTS]
Aimbot Bans:
Hacking/Cheating HSK Automatic Ban [WEAPONNAME-HSK-KILLS-HEADSHOTS]

Damage mod bans take priority over aimbot bans. If you want to whitelist a player from a server, enter their player name, guid, or IP in the whitelist array for each server. We will add database support for whitelisting in a later version. If a player is not found on BF3Stats or BF4Stats, AdKats will keep checking for stats every couple minutes while they are in the server, stopping if they leave.

You can edit the text for each command to suit your needs in plugin settings.

Commands can be accessed with '@', '!', '/!', '/@', or just '/'.

Any action command given with no parameters (e.g. '@kill') will target the speaker. If admins want to kill, kick, or even ban themselves, simply type the command without any parameters. Any action command when given a player name (other than moving players) will require a reason.

On first enable you will need to add a user, you can have as many users as you want. When a user is added you need to assign them a role. The default role is "Default Guest" and the allowed commands for that role are shown to you in the role section. The default guest role cannot be deleted, but can be edited to your heart's content. You can add more roles by typing a new role name in the "add role" field. All roles that are added default to allow all commands, so you will need to edit the allowed commands for new roles. When you change a user's role and they are currently in-game they will be told that their role has changed, and what it was changed to.

Once a user is added you need to assign their soldiers. Users can have multiple soldiers, so if your admins have multiple accounts you can assign all of those soldiers under their user. All soldiers added need to be in your database before they can be added to a user. This system tracks user's soldiers, so if they change their soldier names they will still have powers without needing to contact admins about the change. Type their soldier's name in the "new soldier" field to add them. It will error out if it cannot find the soldier in the database. To add soldiers to the database quickly, have them join any server you are running this version of AdKats on and their information will be immediately added.

The user list is sorted by role ID, then by user name. Any item that says "Delete?" you need to type the word delete in the line and hit enter.

If you have an external system (such as a web-based tool with access to bf3 server information), then there is currently one way to interact with AdKats externally (A second coming soon if possible).

Have your external system add a row to the record table with a new record to be acted on. All information is needed in the row just like the ones sent from AdKats to the database. Review the ones already in your database before attempting this, and ask ColColonCleaner any questions you may have. The only exception is you need to make the 'adkats_read' column for that row = "N", this way AdKats will act on that record. Every 5-10 seconds the plugin checks for new input in the table, and will act on them if found.

• 'Auto-Enable/Keep-Alive' - When this is enabled, AdKats will auto-recover from shutdowns and auto-restart if disabled.

• 'Server ID (Display)' - ID of this server. Automatically set via the database.
• 'Server IP (Display)' - IP address and port of this server. Automatically set via Procon.
  
• 'Setting Import' - Enter an existing server ID here and all settings from that instance will be imported here. All settings on this instance will be overwritten.
  

• 'MySQL Hostname' - Hostname of the MySQL server AdKats should connect to.
• 'MySQL Port' - Port of the MySQL server AdKats should connect to, most of the time it's 3306.
• 'MySQL Database' - Database name AdKats should use for storage. Creation script given in database section.
• 'MySQL Username' - Username of the MySQL server AdKats should connect to.
• 'MySQL Password' - Password of the MySQL server AdKats should connect to.

• 'Add User' - Add a user to the user list by entering their unique username here.
  
• *User Email* - Current stored email of the listed user.
  
• *User Role* - Current role of the listed user.
  
• *Delete User?* - Type delete in this line to delete the listed user.
  
• *Add Soldier?* - Type a logged soldier name in this line to connect it to the listed user. Unique soldiers cannot be connected to more than one user at a time.
  
• *Delete Soldier?* - Type delete in this line to remove the listed soldier connection from the user.
  

• 'Add Role' - Type a new role name in this line to add a new role. Role names must be unique.

Listed below "Add Role" are all the command assignments for each role. Change Allow/Deny for each command for the different user roles to control their access. Type delete in the "delete?" line to delete the user role. When a user role is deleted, all users on that role are changed to the Default Guest role.

• 'Minimum Required Reason Length' - The minimum length a reason must be for commands that require a reason to execute. This only applies to admin commands.
• 'Allow Commands from Admin Say' - When this is enabled, all admins with procon access have unrestricted access to all enabled commands through procon's chat tab. When issuing commands through procon's chat tab, the commands must be prefixed with a / for them to work.

• *Active* - Globally disable or enable the given command.
• *Logging* - Set whether usage of this command is logged. All commands log by default except roundwhitelist.
• *Text* - Globally change the in-game text for this command. Command text must be unique.

• 'Punishment Hierarchy' - List of punishments in order from lightest to most severe. Index in list is the action taken at that number of points.
• 'Combine Server Punishments' - Whether to make punishes from all servers on this database affect players on this server. Default is false.
• 'Only Kill Players when Server in low population' - When server population is below 'Low Server Pop Value', only kill players, so server does not empty. Player points will be incremented normally.
• 'Low Server Pop Value' - Number of players at which the server is deemed 'Low Population'.
• 'Use IRO Punishment' - Whether the IRO punishment described in the infraction tracking docs will be used.
• 'IRO Timeout Minutes' - Number of minutes after a punish that IRO status expires for the next punish.
• 'IRO Punishment Overrides Low Pop' - When punishing players, if a player gets an IRO punish, it will ignore whether server is in low population or not.

• 'Send Emails.' - Whether sending emails will be enabled. By default the adkatsbattlefield gmail account will be used to send emails. When this is true, all reports and admin calls will be send to the supplied email addresses on users and the extra email list.
• 'Use SSL?' - Whether SSL will be used in connection to given SMTP server.
• 'SMTP-Server address.' - Address of the SMTP server.
• 'SMTP-Server port.' - Port to use for the SMTP server.
• 'Sender address.' - The email address used to send all emails.
• 'SMTP-Server username.' - The username used to authenticate into the SMTP server.
• 'SMTP-Server password.' - The password used to authenticate into the SMTP server.
• 'Custom HTML Addition.' - Custom HTML to add to the end of each email. String replacements include. %player_id%, $player_name%, %player_guid%, %player_pbguid%, and %player_ip%.
• 'Extra Recipient Email Addresses.' - List of all extra email addresses beside user email addresses that you would like to blast.

• 'Auto-Whitelist Count' At the start of each round, X random players will be whitelisted for TeamSwap during that round. At the end of the round they lose their whitelisting. Use to get players interested in permanent whitelisting.
• 'Ticket Window High' - When either team is above this ticket count, nobody (except admins) will be able to use TeamSwap.
• 'Ticket Window Low' - When either team is below this ticket count, nobody (except admins) will be able to use TeamSwap.

• 'Enable Admin Assistant Perk' - Whether admin assistants will get the TeamSwap perk for their help.
• 'Minimum Confirmed Reports Per Month' - How many confirmed reports the player must have in the past month to be considered an admin assistant.

• 'On-Player-Muted Message' - The message given to players when they are muted by an admin.
• 'On-Player-Killed Message' - The message given to players when they are killed for talking in chat after muting.
• 'On-Player-Kicked Message' - The message given to players when they are kicked for talking more than X times in chat after muting.
• '# Chances to give player before kicking' - The number of chances players get to talk after being muted before they are kicked. After testing, 5 appears to be the perfect number, but change as desired.

• 'Display Admin Name in Kick and Ban Announcement' When players are kicked or banned from the server, the whole server is told. This changes whether the message includes the kicking or banning admin name, instead of just "admin".
• 'Yell display time seconds' - The integer time in seconds that yell messages will be displayed.
• 'Pre-Message List' - List of messages for use in pre-say and pre-yell commands.
• 'Require Use of Pre-Messages' - Whether using pre-messages in commands is required instead of custom messages.

• 'Use Additional Ban Message' - Whether to have an additional message append on each ban.
• 'Additional Ban Message' - Additional ban message to append on each ban. e.g. "Dispute at www.yourclansite.com"
• 'Procon Ban Admin Name' - Admin name that will be used for bans filed via procon.

• 'Use Ban Enforcer' - Whether to use the internal AdKats Ban Enforcer.
• 'Enforce New Bans by NAME' - Whether to use a player's name to ban them. (Insecure, players can change their names)
• 'Enforce New Bans by GUID' - Whether to use a player's EA GUID to ban them. (Secure, players cannot change their GUIDs)
• 'Enforce New Bans by IP' - Whether to use a player's IP Address to ban them. (Somewhat secure, experienced players can change their IP, and IP bans can hit multiple players.)

• 'NAME Ban Count' - How many NAME bans are currently being enforced by AdKats Ban Enforcer.
• 'GUID Ban Count' - How many EA GUID bans are currently being enforced by AdKats Ban Enforcer.
• 'IP Ban Count' - How many IP bans are currently being enforced by AdKats Ban Enforcer.
• 'Ban Search' - Enter a full or partial player name here and AdKats will display all ACTIVE matching bans.

• 'External Access Key' - The access key required to use any HTTP commands, can be changed to whatever is desired, but the default is a random 64Bit hashcode generated when the plugin first runs.
• 'Fetch Actions from Database' - Whether to use the database as a source for new commands.

• 'Server VOIP Address' - String that will be sent to players using the VOIP command.

• 'Feed MULTIBalancer Whitelist' - When enabled, MULTIBalancer's whitelist will include all AdKats user's soldiers with access to player interaction commands.
• 'Feed Server Reserved Slots' - When enabled, the servers reserved slots will include all AdKats user's soldiers.
• 'Feed Server Spectator List' - When enabled, the servers spectator list will include all AdKats user's soldiers.
• 'Feed Stat Logger Settings' - When enabled, stat logger is fed settings appropriate for AdKats, including correct database time offset, instant chat logging, etc. This is experimental.

• 'Round Timer: Enable' - When enabled, rounds will be limited to X minutes.
• 'Round Timer: Round Duration Minutes' - Number of minutes that the round will last before the current winning team wins (Will only work correctly in conquest at the moment).

• 'HackerChecker: Enable' - Whether the internal BF3Stats hacker-checker is enabled.
• 'HackerChecker: Whitelist' - The list of player names, GUIDs, and IPs, that will not be checked by the hacker-checker.
• 'HackerChecker: DPS Checker: Enable' - Whether the Damage Mod portion of the hacker-checker is enabled.
• 'HackerChecker: DPS Checker: Trigger Level' - The percentage over normal weapon damage that will cause a ban. 50 kills minimum to trigger. After 3 months of testing, 50 is the best value, and has not issued a single false positive in that time.
• 'HackerChecker: DPS Checker: Ban Message' - Message prefix to use when banning for damage mod.
• 'HackerChecker: HSK Checker: Enable' - Whether the Aimbot portion of the hacker-checker is enabled.
• 'HackerChecker: HSK Checker: Trigger Level' - The headshot/kill ratio for automatic weapons that will trigger a ban. 100 kills minimum to trigger. After 3 months of testing, we suggest setting between 50 and 70 depending on the severity you want to enforce. You will get some false positives down near 50 but will catch many more aimbotters, setting near 70 will not result in any false positives but also wont catch as many aimbotters.
• 'HackerChecker: HSK Checker: Ban Message' - Message prefix to use when banning for aimbot.

• 'Rule Print Delay' - Delay in seconds after the command is issued that commands start being sent to the player.
• 'Rule Print Interval' - Number of seconds between each rule being sent to the player.
• 'Server Rule List' - List of rules for the server. Raw messages can be used here, or alternatively pre-message IDs.

• 'Debug level' - Indicates how much debug-output is printed to the plugin-console. 0 turns off debug messages (just shows important warnings/exceptions/success), 7 documents nearly every step. Don't edit unless you really want to be spammed with console logs, it will also slow down the plugin when turned up.
• 'Debug Soldier Name' - When this soldier issues commands in your server, the time for any command to complete is told in-game. Duration is from the time you entered the message, until all aspects of the command have been completed.
• 'Command Entry' - Enter commands here just like in game, mainly for debug purposes. Don't let more than one person use this at any time.