Admin Toolset with a plethora of features, focused on making in-game admins more efficient and accurate at their jobs. Includes a cross-server ban enforcer more reliable and complete than others available, and a WebAdmin for out-of-game control will be released shortly. 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, banning, moving, etc..
• Admin and setting sync between servers. All changes to admin access or plugin settings can be automatically synced between 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. Notification system and quick handling features for all admin calls and player reports. Reports can be referenced by number for instant action.
• Admin Assistants. You can choose to give a small perk to players who consistently provide you with accurate player reports. Documentation linked below.
• 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.
• Yell/Say Pre-Recording. Usable along side plugins such as "server rules on request". Use numbers to reference predefined messages. Avoid typing long reasons or messages.
• External Controller API. AdKats can be controlled from outside the game, through systems like AdKats WebAdmin (under development). Once done you will be able to issue any admin command, manage bans, change plugin settings, track admin activities, and much more from a webpage without being in-game.
• Internal Implementation of TeamSwap. Movement options for both your admins and playerbase if desired. Greatly improved over the default version. Documentation linked below.
• AdKats Ban Enforcer. AdKats can enforce bans across all of your servers. This system has been built to be more complete and reliable than others available, including metabans (permabans through metabans are only enforced for 28 days). This system will be further enhanced with the release of AdKats WebAdmin. Documentation linked below.
• Editable In-Game Commands. All command text can be edited to suit your needs.
• Performance. All actions, messaging, database communications, and command parsing take place on their own threads, minimizing performance impacts.
• Full Logging. All admin activity is trackable via the database, so holding your admins accountable for their actions is quick and painless. And after WebAdmin is released nobody but your highest admins will need direct procon access.

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

Download the latest version here: Version 0.3.0.3

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

1. Confirm Dependencies. Make sure all requirements in the Dependencies section below are met.
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 triggers)
3. Add plugin file to procon. Add the plugin file to procon as you would any other.
4. Enter database connection info. All database connection info 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!

Version 1.1.0.0+ of this plugin is required. AdKats will only run if this plugin is (1) using the same database AdKats uses, and (2) running on every BF3 Server you plan to install AdKats on. Running it along-side AdKats on each layer will ensure these conditions are met.

BF3 Chat, GUID, Stats and Mapstats Logger

An online 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 as well. 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.

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.

IRO Punishments: When a player is punished, and has already been punished in the past 5 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.

The Enforcer works properly with all existing auto-admins, and any bans added manually through procon will be imported by the system. However, this system requires AdKats WebAdmin for ban management, it's options are too complicated for procon's interface to house properly. Use of the ban enforcer is optional because of this dependency, and is disabled by default. You can use Ban Enforcer without WebAdmin but you will need to modify the database ban list directly, which will have a learning curve.

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 without webadmin. Disabling ban enforcer will repopulate procon's ban list with the imported bans, but you will lose any additional information ban enforcer was able to gather about the banned players.

To all who will be using the ban enforcer before WebAdmin is released, you can use the below query to get more meaningful information out of the ban list. Once you find the ban ID you want using this query you can modify it in adkats_banlist using that ID. To remove a ban change ban_status to "Disabled" (caps important), and to modify duration change ban_endTime to when you want it to end (remember database timezone might be different from yours).

SELECT
adkats_banlist.ban_id,
tbl_playerdata.SoldierName AS player_name,
adkats_records.record_message AS ban_reason,
adkats_banlist.ban_status,
adkats_banlist.ban_startTime,
adkats_banlist.ban_endTime,
adkats_banlist.ban_enforceName,
adkats_banlist.ban_enforceGUID,
adkats_banlist.ban_enforceIP
FROM
adkats_banlist
INNER JOIN
tbl_playerdata
ON
tbl_playerdata.PlayerID = adkats_banlist.player_id
INNER JOIN
adkats_records
ON
adkats_records.record_id = adkats_banlist.latest_record_id
ORDER BY
ban_startTime
DESC;

Reasoning behind creation for those interested: We had tried many other ban management systems and they all appeared to have some significant downfalls. I will not point fingers at any specific plugins other than metabans as most of the problems with those could be solved by active upkeep and improvement, but unfortunately in some cases the original developers have stopped supporting the plugin. For metabans specifically however they only enforce permabans for 28 days, and if we want to keep unwanted players off our servers by whatever means possible that is simply unacceptable.

On a lighter note though, developing this allows for some nice features not previously available. I can bypass procon's ban list completely, this way no data is lost on how/why/who created the ban or on who its 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, then the report is 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. This cleans up what admins end up seeing for reports (useful if they get reports and calls whether in-game or not).

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 is 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 then join the server, and that status will remain for the duration they are in the server (e.g. If they lose status mid-round, it won't cut them off until the next time they join 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 message they are kicked from the server. 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.

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 call 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 (Access levels 0-4) 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 are elevated to access level 5 for that round (this elevation is not persisted in the database, and will only apply to the current server). 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. 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.

This plugin has been multi-threaded for performance in the latest version and still needs a lot of testing in this area. The speed of commands depends on how much database interaction needs to happen for each. Preliminary thread testing shows small commands like kill which require 2 or fewer database round-trips run around 150ms to completion. Large commands like punish which can sometimes require 8 database round-trips to complete can run 500ms+ under heavy load. Use "Debug Soldier Name" to get the speed of commands on your server, any command that soldier enters will tell them the total time it took to complete.

Access lists are automatically synced between layers every 5 minutes, so there is no need to go through every layer to change access settings. This can be changed directly in database as well, and will be synced to all running plugins.

All settings for each plugin instance are stored in the database by server ID. Enter an existing server ID in the setting sync 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 pushed to the database.

You can edit the text for each command to suit your needs in plugin settings.
Commands can be accessed with '@', '!', '/!', '/@', or just '/'. Usage of all commands is logged in the database.

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.

Players need to be at or above certain access levels to perform commands. Players on the access list can have their powers disabled (without removing them from the access list) by lowering their access level. Players can be added to or removed from the access list using the "Add Access" and "Remove Access" setting fields. The access level of a player can be changed once they are on the access list, in addition to their email address. All players are defaulted to level 6 in the system, and have no special access, level 0 is a full admin.

If you have an external system (such as a web-based tool with access to bf3 server information), then there are two ways to interact with AdKats externally.

The BF3 server ip and port are shown in AdKats settings.
http://[procon_server_ip]:[server_port]/[bf3_server_ip]:[bf3_server_port]/plugins/AdKats/?[Parameters]

Required Parameters:
command_type=[Command from list Below]
target_name=[Full or Partial Player Name]
record_message=[reason for action]
access_key=[Your Access Key from AdKats Settings]
Optional Parameters:
source_name=[Name of admin sending this command. This system has access level 0 (full admin) regardless of this entry.]
record_durationMinutes=[Used for Temp-Bans, duration of time in minutes]

Example of Command:
http://293.182.39.230:27360/173.199.91.187:25210/plugins/AdKats/?command_type=TempBan&source_name=ColonsEnemy&
target_name=ColColonCleaner&record_message=Testing&record_durationMinutes=60&access_key=MyPassword

SECURITY NOTE: As some will notice this works through GET commands, which are insecure, if you issue commands and someone outside gets the command URL you entered they will have full access to issue commands on your instance of this plugin. It is only insecure if you use this method though, as internally the key is randomized. I am working on securing this system, as it is ultimately better than option 2.

Valid 'command_type's that can be acted on include the following:

• '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 Access' - Add a player to the access list by entering their exact IGN here.
  
• 'Remove Access' - Remove a player already on the access list by typing their exact IGN here.
  
• *PlayerName* - Players in the current database access list are appended here with their access level.

• 'Minimum Required Reason Length' - The minimum length a reason must be for commands that require a reason to execute.

• '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'.
• 'IRO Punishment Overrides Low Pop' - When punishing players, if a player gets an IRO punish (described above), it will ignore whether server is in low population or not.

• 'Email and RSS handling coming soon.'

• 'Require Whitelist for Access' - Whether the 'moveme' command will require whitelisting. Admins are always allowed to use it. Default False.
• '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 a perk for their help.
• 'Minimum Confirmed Reports Per Week' - How many confirmed reports the player must have in the past week to be 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.

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

By default, banning is by GUID only, this is sufficient in most cases. If not using AdKats Ban Enforcer, bans are always done by EA GUID.

• '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"
• 'Use Ban Enforcer' - Whether to use the internal AdKats Ban Enforcer. Details Noted Above.
• '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.)

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

• 'Debug level' - Indicates how much debug-output is printed to the plugin-console. 0 turns off debug messages (just shows important warnings/exceptions), 6 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.