Admin Toolset with a plethora of features, over 50 available in-game commands, and many customization options. 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 with advanced enforcement features, metabans support, and the AdKats WebAdmin for external 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 50 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.
• Player reputation tracking. System based on issued commands from/against players, forming a reputation of the server. Documentation below.
• 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. Automatic PBSS are triggered on reported players.
• 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. When fully used this can turn your regular playerbase into a human autoadmin. Trusted players based on admin interaction can fill the gaps normal autoadmins cannot, utilizing the report system, and keeping your server under control even when admins are offline.
• 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.
• Player Locking. Players can be locked from admin commands for a specific timeout, the main purpose is if a certain admin is handling them (checking stats for cheat detection, records, etc.) they shouldn't be interrupted by another admin acting on the player.
• Player Assist. Player's want to play with their friends, but you don't want to imbalance the teams? The assist command lets all players join the weak team together to help them out and squad up without hurting the server.
• Yell/Say Pre-Recording. Use numbers to reference predefined messages. Avoid typing long reasons or messages. e.g. @kill player 3
• Server Rule Management. Server rules can be listed, requests for rules logged, rules targeted at players, and rules can be distributed between servers automatically.
• External Controller API. AdKats can be controlled from outside the game through systems like AdKats WebAdmin, and through other plugins like insane limits. For example, you can issue AdKats punish commands from insane limits or proconrulz and have them be logged like any other admin command.
• 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. System can automatically interface with metabans, automatically import all Procon bans from all your servers and consolidate them, and will import any existing bans from the BF3 Ban Manager plugin's tables. Full documentation below.
• Metabans Support. When using ban enforcer, all bans can be optionally submitted to metabans, and removed when a player is unbanned.
• Editable In-Game Commands. All command text, logging options, and enable options can be edited to suit your needs.
• Full Logging. One of the main reasons AdKats was made in the first place. 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.
• Setting Lock. All settings in AdKats can be locked with a password. This means even admins with access to plugin settings can be blocked from changes using the password.
• 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.

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

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

1. Install XpKiller's Stat logger plugin. Download and install the latest universal version of XpKiller's Procon Chat, GUID, Stats and Mapstats Logger. Make sure stat logger is installed and running! Do NOT attempt to install AdKats until that plugin is running without issue.
2. GO BACK TO STEP 1 AND INSTALL STAT LOGGER. Not after, not when you try to enable AdKats and it fails, go back and install stat logger and make sure it is running! Current and future functions will be completely broken for you if you do not do this.
3. Set up the database. Run the contents of this sql script on your database. It must be run on the same database that Stat Logger is running on. (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)
4. Download AdKats Source. Download the latest stable version of AdKats from here: Version 5.0.0.5
5. Add plugin file to Procon. Add the plugin file (AdKats.cs) 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.
6. Enter database credentials. All database connection information must be entered in the settings tab before AdKats can run.
7. Enable AdKats. AdKats will confirm all dependencies and show confirmation in the console. If it gives your server an ID then all is well. Enjoy AdKats!

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

• Trouble running the setup SQL script. If this happens it is most likely your database provider has restricted your access to create either triggers, stored procedures, or both. These elements are required for AdKats to properly function, and thus it cannot be run without them. Please talk with your database provider and gain access to creation of stored procedures and triggers.
• "Stat logger tables missing" on first run after setting up the plugin. Confirm you have run the stat logger plugin on the same layer and it is functioning without error. If it is, try rebooting your layer.
• Suggest more for this list if you run across them.

On first enable you will need to add a user before you can access certain in-game commands. 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. If you add a user with the same name as their soldier(s), their soldier(s) will be added automatically. 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 name 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 after installing stat logger for the first time, 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.

All commands, their usage, who used them, who they were targeted on, why, when they were used, and where from, are all logged in the database. Player's name changes and IP changes are also logged and the records connected to their player ID. Soon IP bans will work off of previous IP as well as current IP.

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 temp ban and ban are of course still available for hacking/glitching situations, but that is the ONLY time they should be used.

Player reputation system is now public. Each command is given a source and target reputation, and based on how players interact in the server they can either gain or lose reputation. Values for target and source rep are global for all instances of AdKats. Reputation is capped between -1000 and 1000, and is available for check using the player info command.

AdKats can enforce bans across all of your servers. 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 and future-ban commands.

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. Other online admins are informed when an admin acts on a report by ID, either with action, deny, or accept.

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

Automatic Punkbuster screenshots are triggered on reported players.

This system has been completely revamped in 4.1.0.0, and several hidden features have now been released to the public. We utilized the full system on our no explosives server with great success, mainly catching things autoadmin cannot. Basically this system automatically tracks who the trusted players in your servers are, and who are reliable sources of reports.

The system makes use of the report IDs assigned to each round report. When a player sends a report, and an admin uses the report by ID, the report is logged as confirmed. Once you enable Admin Assistants, AA status is given once the player has X confirmed reports in the past month or 75+ total confirmed reports. A player with AA status is informed of their status on first spawn in the server after joining. If you enable the admin assistant perk, players with AA status are given access to the teamswap and online-admins commands for the duration they maintain AA status. These command perks are basically incentives to report rule-breakers. Whether a player has AA status is calculated when they join the server, and that status will remain for the duration they are in the server. When an admin assistant sends a report, to the admins their name is prefixed with [AA] to note it as a (most likely) reliable report. Likewise if an admin assistant is the target of a report, their name is prefixed with a clan-tag-like code. (e.g. Report [512]: [AA]ColColonCleaner reported [AA]SomeOtherAA for using explosives).

The advanced functionality of this system is now released to the public as testing is complete. This subsection uses your AAs as a collective human autoadmin.

Players with AA status can conditionally have their reports acted on by the internal autoadmin.
A list of trigger words or phrases of any length can be defined in AdKats settings.
If an AA report reason contains any of those trigger words or phrases then autoadmin will act on their report with a
punish on the target player, using the reason they entered.
This was originally intended for cases when admins are offline and unable to answer reports, but has now been added
for all cases.
If admins are offline, and the report matches criteria, autoadmin will punish the target player after 5 seconds.
If admins are online, a 45 second window is given for the admin to act on the report before automatic handling
fires.
Admins can use any action command just like normal (e.g. @kill ID, @punish ID, etc...), but can also use the new
@accept or @deny commands.
@accept will confirm the report but take no action against the target player.
@deny is used for bad or invalid reports, and will hurt the reporter's AA status.<br/><br/>

Exceptions and Security Measures:
Automatic handling will not be taken if the target of a report is an admin or another AA, a real admin must act on
the report.
Automatic action will also not be taken if the target player has already been acted on in some way in the past 60
seconds.

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.

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.

Special player list table "adkats_specialplayers" has been added. In this table, players can be added to any desired group accepted by AdKats. Valid groups are currently slot_reserved, slot_spectator, whitelist_multibalancer, blacklist_dispersion, and whitelist_hackerchecker. Players can be added by ID, or by identifier (name, guid, or IP), and can be assigned a game and server to apply them to. If you use player IDs then you wont need to update player names if they change their names, the player names will automatically update when they join the server; This is especially good to use when whitelisting for the hacker-checker. Leave fields blank to indicate wildcard, for example leaving the server column blank for player will mean it applies to all servers of their game. If you specify the server, the group you have them assigned to will only apply for that one server. Each special player list entry now has an effective and expiration date, stored in UTC time.

Orchestration table "adkats_orchestration" has been added. All entries in this table are polled every 5 minutes and sent to the appropriate plugins. Add entries to that table with a given server ID, plugin name, plugin setting name, and setting value. AdKats will send those settings to the target plugin every 5 minutes.

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, M320, Knife, 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.

Info posts:
https://forum.myrcon.com/showthread.php?6045-AdKats-Advanced-In-Game-Admin-and-Ban-Enforcer-4-0-0-0&p=90700&viewfull=1#post90700
https://forum.myrcon.com/showthread.php?6045-AdKats-Advanced-In-Game-Admin-and-Ban-Enforcer-4-0-0-0&p=92106&viewfull=1#post92106

Damage per shot for all known weapons is held on the AdKats repository, and is downloaded when the plugin enables. If a weapon damage is not found in that repository, the weapon damage from BFXStats API is used instead. Those values are not always correct, so inform ColColonCleaner about any new weapons or missing entries. 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.

Be careful with this one, this is where a lot of legit competitive players reside. This check should only be used to request video gameplay of players to prove their play, then whitelist the player. For this check all weapons aside from melee weapons and equipment are included. This includes Sub Machine Guns, Assault Rifles, Carbines, Machine Guns, Handguns, and Sniper Rifles. This check uses weapon time and total kills, rather simple, just kills/total minutes. If that value is greater than your trigger level the ban is issued. After some research and testing the value used on our servers is the default, 4.5. 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:
DPS Automatic Ban [WEAPONNAME-DPS-KILLS-HEADSHOTS]
Aimbot Bans:
HSK Automatic Ban [WEAPONNAME-HSK-KILLS-HEADSHOTS]
KPM Bans:
KPM Automatic Ban [WEAPONNAME-KPM-KILLS-HEADSHOTS]

DPS bans take priority over HSK bans, and HSK over KPM. If you want to whitelist a player from a server, enter their player ID, name, guid, or IP in the adkats_specialplayers table using the group "whitelist_hackerchecker". 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.

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.

Two available MatchCommands have been added, one for issuing commands through AdKats, and the second for fetching admin lists. These can be called by other plugins to integrate their functionality with AdKats and its database.

• caller_identity String with ID unique to the plugin sending the request. No whitespace or special characters. e.g. "InsaneLimits"
• response_requested true
• response_class Class/plugin where the callback will be sent.
• response_method Method within the target plugin that will accept the response
• user_subset "admin", "elevated", or "all". Admin meaning they have access to player interaction commands, elevated meaning they do not. Returns all soldiers in that subset.
• user_role Returns all soldiers belonging to users in a specific role.

• caller_identity AdKats
• response_requested false
• response_type FetchAuthorizedSoldiers
• response_value List of soldiers that matched the given parameters. CPluginVariable.EncodeStringArray used to compact into one field. CPluginVariable.DecodeStringArray can be used to parse the field back into an array.

• caller_identity String with ID unique to the plugin sending the request. No whitespace or special characters. e.g. "InsaneLimits"
• response_requested true/false. Whether the caller would like a response with the outcome of the command.
• response_class Only if response_requested is true. Class/plugin where the callback will be sent.
• response_method Only if response_requested is true. Method within the target plugin that will accept the response.
• command_type Command key that references the desired command. Examples: player_kill, player_ban_perm, admin_say.
• command_numeric Used for commands like player_ban_temp that require a numerical input. Currently player_ban_temp is the only command that requires a command numeric, and will throw errors if a numerica is not provided. In all other cases this field is optional.
• source_name Name of the source you would like database logged. For example an admin name, plugin name, or a custom name like AutoAdmin.
• target_name The exact name of the target you would like to issue the command against, usually a player name. For commands like admin_nuke which don't accept a player name, special syntax is used, documentation of such is provided in the readme.
• target_guid Only required when binding to onJoin, onLeave, or other events where the player may not be loaded into AdKats' live player list yet. If the player cannot be found in the live player list by target_name then this guid is used to fetch their information from the database and perform the command.
• record_message The message or reason that should be used with the command. e.g. Baserape. Message can be up to 500 characters.

• caller_identity AdKats
• response_requested false
• response_type IssueCommand
• response_value List of all messages sent for the command, comparable to what an admin would see in-game. CPluginVariable.EncodeStringArray used to compact into one field. CPluginVariable.DecodeStringArray can be used to parse the field back into an array. If the command succeeds withouth issue there should (generally) only be one message.

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.

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

• 'Lock Settings - Create Password' - Lock settings with a new created password > 5 characters.
• 'Lock Settings' - Lock settings with the existing settings password.
• 'Unlock Settings' - Unlock settings with the existing settings password.
• '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.
  
• '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.
  
• 'Low Population Value' - Number of players at which the server is deemed 'Low Population'.

• '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 Expiration* - Date that the user will revert to Default Guest role.
• *User Notes* - Any notes that are logged for the 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. You cannot delete 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.
• 'Minimum Report Handle Seconds' - The minimum number of seconds before a report can be acted on by admins using report ID.
• 'Maximum Temp-Ban Duration Minutes' - The maximum number of minutes that a temp-ban can be issued for.
• '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.
• 'External plugin player commands' - List of commands (with prefixes) that general players can access. Currently used for the help command.
• 'External plugin admin commands' - List of commands (with prefixes) that admins can access. Currently used for the help command.

• *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.
• '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.

• '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 Assistants' - Whether admin assistant statuses can be assigned to players.
• 'Minimum Confirmed Reports Per Month' - How many confirmed reports the player must have in the past month to be considered an admin assistant.
• 'Enable Admin Assistant Perk' - Whether admin assistants will get the TeamSwap perk for their help.
• 'Use AA Report Auto Handler' - Whether the internal auto-handling system for admin assistant reports is enabled.
• 'Auto-Report-Handler Strings' - List of trigger words/phrases that the auto-handler will act on. One per line.

• '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.
• 'Ignore commands for mute enforcement' - Whether to ignore commands when enforcing mute status on a player.

• '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".
• 'Inform players of reports against them' - Whether to inform targeted players when someone reports them.
• 'Player Inform Exclusion Strings' - List of words or phrases that will cancel informing reported players. For example, use if you don't want players to know if someone reports them with "hack", or "cheat" in the message.
• '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 first spawn message' - Whether to use the first spawn message for players.
• 'First spawn message text' - Message to send players when they first spawn in the server. Uses tell.

• '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.)
• 'Use Metabans?' - Whether to use metabans functionality when banning/unbanning in ban enforcer.
• 'Metabans Username' - Username for authentication to your metabans account.
• 'Metabans API Key' - API Key for your metabans account.

• '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.

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

• 'Feed MULTIBalancer Whitelist' - When enabled, the adkats_specialplayers table (group: whitelist_multibalancer) is used to feed MULTIBalancer's player whitelist.
• 'Automatic MULTIBalancer Whitelist for Admins' - When enabled, all admins in your User List will be given whitelist from balance in MULTIBalancer.
• 'Feed MULTIBalancer Even Dispersion List' - When enabled, the adkats_specialplayers table (group: blacklist_dispersion) is used to feed MULTIBalancer's even dispersion list.
• 'Feed Server Reserved Slots' - When enabled, the servers reserved slots will include all AdKats user's soldiers.
• 'Automatic Reserved Slot for User Cache' - When enabled, all users in your User List will be given a reserved slot.
• 'Feed Server Spectator List' - When enabled, the servers spectator list will include all AdKats user's soldiers.
• 'Automatic Spectator Slot for User Cache' - When enabled, all users in your User List will be given a spectator slot.
• 'Feed Stat Logger Settings' - When enabled, stat logger is fed settings appropriate for AdKats, including correct database time offset, instant chat logging, etc.

  The following settings are sent to stat logger when using the "Feed Stat Logger Settings" orchestration option:

  • "Servertime Offset" (TIME OFFSET CONVERSION TO UTC TIME)
  • "Enable Chatlogging?" "Yes"
  • "Instant Logging of Chat Messages?" "Yes"
  • "Enable Statslogging?" "Yes"
  • "Enable Weaponstats?" "Yes"
  • "Enable KDR correction?" "Yes"
  • "MapStats ON?" "Yes"
  • "Session ON?" "Yes"
  • "Save Sessiondata to DB?" "Yes"
  • "Log playerdata only (no playerstats)?" "No"
  "Enable Live Scoreboard in DB" is forced on at all times.

• '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: 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 high KPM.
• 'HackerChecker: KPM Checker: Enable' - Whether the KPM portion of the hacker-checker is enabled.
• 'HackerChecker: KPM Checker: Trigger Level' - Kills-per-minute with any included weapon that will trigger the ban.
• 'HackerChecker: KPM Checker: Ban Message' - Message prefix to use when banning for high KPM.

• '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.
• 'Server Rule Numbers' - Whether to include the rule numbers at the beginning of each line during rule printing.

• 'AFK System Enable' - Whether to enable the AFK management system.
• 'AFK Ignore Chat' - Events are used to cancel AFK timeout for players. When this is enabled, players just sitting in the spawn screen chatting will be kicked. They must play in order to stay in the server..
• 'AFK Auto-Kick Enable' - Whether to automatically kick using the trigger time. When disabled, the afk command must be used for kicking afk players.
• 'AFK Trigger Minutes' - The number of minutes a player can do nothing before being considered AFK.
• 'AFK Minimum Players' - Minimum number of players that must be in the server before the system will kick AFK players.
• 'AFK Ignore User List' - Whether to ignore all users on the user list.
• 'AFK Ignore Roles' - Visible when not ignoring all users on the user list. List the role keys that will be ignored.

• '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.