Integrations

AdminControl works with other plugins when they are installed. Nothing has to be turned on: an integration starts with the server when its plugin is there, and AdminControl runs as before when it is not.

Placeholders for other plugins

With PlaceholderAPI installed, scoreboards, tab lists, holograms and chat plugins can show AdminControl's data. On Folia and on Minecraft 26.x it needs PlaceholderAPI 2.12.3 or newer.

• Player values (the first seven) need an online player. Without one, for example in a hologram that shows the same text to everyone, they are empty. Right after a player joins the mute values stay empty until AdminControl has read the mute: placeholders are for showing, not for deciding whether a player may talk.
• Off by default: mute_reason, punishments and open_reports are empty until you set placeholders.sensitive: true in config.yml (then /ac reload). Whoever the showing plugin shows them to can read them: a public scoreboard shows everyone the number of open reports, and a plugin that fills in placeholders in what players type (chat, signs, item names), together with the ParseOther expansion, lets a player read another player's mute reason.
• Vanish: players hidden by SuperVanish, PremiumVanish or EssentialsX (the vanished mark) count in neither staff_online nor the players online of this server, so a scoreboard does not give a hidden moderator away. Players in vanish on other servers of the network are counted there.
• Freshness: mutes are read at once. Warnings, punishments and reports are refreshed every 30 seconds, and a player's own counts as soon as they get or lose a punishment, on any server of the network. Network figures follow the panel's server list.
• Unknown names stay as written, so a typo shows up in game.

Examples:

Warnings: %admincontrol_warnings%

With a plugin that shows a line only when a placeholder equals a value (a condition), compare %admincontrol_muted% with true to show "You are muted" only to muted players.

Prefixes and groups in the panel

With Vault and a permission or chat plugin behind it, the panel shows each player's prefix and primary group:

• the prefix before the name in the player list, the list of players online and the live chat;
• the prefix and the group in the player's profile.

Without Vault, AdminControl reads them straight from LuckPerms. Prefixes are read when a player joins and every minute after, and shown as plain text: colour codes are left out. The last known prefix and group stay with the player, so the panel shows them while the player is offline too. In a network each server reads its own players.

Geyser and Floodgate

Bedrock players who join through Geyser and Floodgate get a UUID that starts with 00000000-0000-0000-. AdminControl recognises them by it, also on servers without Floodgate, on the proxy and for players brought in by an import:

• Badge and filter: a "Bedrock" badge next to the name in the player list, the profile and the live chat, and a "Bedrock" filter in the player list.
• Heads: the panel shows a Bedrock player's skin from GeyserMC's API (bedrock.geysermc-skins, on by default; see Privacy).
• Linked accounts: when a player links their Bedrock account with a Java account in Floodgate, a Paper server with Floodgate records the link when they log in. In a network, install Floodgate on the Paper servers too, not only on the proxy: AdminControl reads links on the Paper servers. From then on a ban, a kick or a mute of either account applies to both, on every server; the proxy keeps both accounts out of a ban. Lifting it frees both: /unban and /unmute of either account lift the other's ban or mute too. The player list's "Banned" and "Muted" filters and badges count the linked account's. Warnings, history, notes and sessions stay with each account. The profile shows the linked account, with a link to its profile when it has played here, to those who may see players' IP addresses (players.view_ip): it names the player's Xbox account.
• Unlinking the accounts in Floodgate (or linking the Bedrock account with another Java account) ends the shared punishments once the player logs in again: each account then keeps only its own. Punish both accounts when a player must stay out on either.
• When a link reaches the database only after the player's login was checked (a slow database), the ban and the mute are checked again as soon as they join.

Geyser without Floodgate (offline mode) gives Bedrock players ordinary offline UUIDs: they are not recognised as Bedrock.

EssentialsX

With EssentialsX installed, AdminControl is the one place punishments come from.

• Its punishment commands run as AdminControl's (essentials.take-over-commands: true, on by default): /ban, /tempban, /banip, /tempbanip, /unban, /kick, /mute and /silence of Essentials, also as /essentials:ban or Essentials' own aliases like /eban, typed by a player, in the console, over RCON or in the panel's console, run the AdminControl command with the same arguments, with AdminControl's permissions and role limits (command blocks keep Essentials'). Essentials does not get them. /mute <player> toggles as in Essentials: a player muted now (also through a linked Bedrock account) is unmuted; /mute <player> <time> [reason] mutes for that time. A command without a reason gets "No reason given". Times are AdminControl's (10m, 2h, 7d, 4w, written together like 1d12h); one AdminControl does not know (1mo) gets the command's usage and no punishment. /banip and /unbanip with an IP address, other Essentials commands (/jail, /kickall) and the server's ban list (/minecraft:ban) stay with Essentials. Set it to false to leave the commands to Essentials.

• Mutes in both directions, AdminControl first: a mute of AdminControl (here, from the network or through a linked account) is set in Essentials too, with the same end, for players on this server, so Essentials' own /msg, /mail and /me stop as well; lifting it lifts it there. When a player joins, Essentials is set to match. A mute given in Essentials (its /mute with the take-over off, or another plugin through it) becomes an AdminControl punishment, seen in the panel and the network, decided in the background:

  • given by a player: with that player's panel account's role and its limits, as if they muted in the panel (their name is the actor). A role that may not mute, a mute longer than its limit, or a target on the staff is refused. A player without a panel account: the mute is kept in Essentials only, on this server, and AdminControl does not record it (a join leaves it; lifting it in Essentials ends it);
  • given without a player (the console, another plugin): as the console, by "EssentialsX (who gave it)". Staff with a panel account (or their linked account) cannot be muted this way.

  The one who muted is told how it ended. Lifting a mute in Essentials lifts it here only when it came from Essentials; a mute of AdminControl stays and the one who tried is told to lift it in AdminControl.

• When Essentials' API fails (an Essentials update AdminControl does not know yet), the part it hit stops until a restart and the server log says which: the mute sync, or nickname, AFK and jail. The punishment commands are still taken (by their names, not asking Essentials), so a moderator's /ban never falls back to Essentials' own. The essentials status disappears from /ac version.

• Nickname, AFK and jail: the player list, the profile and the live chat show a player's Essentials nickname; the list and the profile show "AFK" (while online, also on another server of the network) and "Jail" with the jail's name and end. Search finds players by nickname too. A nickname is shown as plain text (no colors). AFK is written when it changes, a few seconds later.

DiscordSRV

With DiscordSRV installed:

• Notifications on its channels: in Settings → Integrations each group (punishments, server state, reports) goes off, to the webhook, or to a DiscordSRV channel: a channel name from DiscordSRV's config (the panel suggests them) or a channel ID. A channel ID must be a channel of DiscordSRV's Discord server (its main guild): one of another server the bot is in gets nothing, and the server log says so. Long texts are cut to Discord's limits. "Test" sends one test message; it can be used once in 10 seconds per panel account. The messages are the same as through the webhook, sent by DiscordSRV's bot. "Send notifications to Discord" turns all groups on or off. The server where a punishment or report happens sends it, so in a network give every server DiscordSRV, or use the webhook; a server without DiscordSRV shows that in the settings.
• Linked Discord accounts: the profile shows the Discord account a player linked in DiscordSRV, to those who may see players' IP addresses (players.view_ip).
• The chat: a muted player's message does not go to Discord. A message on a linked channel from a Discord user whose linked Minecraft account (or its linked Bedrock account) is muted or banned does not go into the game; DiscordSRV's bot tells them why in a private message, at most once in 5 minutes (the reason is shown as plain text). A player on this server is checked from AdminControl's mute cache; others from the database, remembered for 30 seconds. When the database does not answer within 2 seconds such a message is held. Users without a linked account are not checked, so a punished player could write from an unlinked Discord account: set DiscordChatChannelRequireLinkedAccount: true in DiscordSRV's config.yml so only linked accounts reach the game, and add discord to punishments.mute-blocked-commands in AdminControl's config.yml so a muted player cannot unlink it in the game (/discord unlink) to get around the check.
• When DiscordSRV's API fails, the part it hit stops until a restart and the server log says which: the notifications, the chat check or the linked accounts. A notification that could not be sent (the bot's permissions in the channel) is only warned about. The discordsrv status disappears from /ac version. Even with the chat check's lookup broken, a muted or banned player stays out of the chat from Discord: the linked accounts AdminControl saved answer instead.

CoreProtect

With CoreProtect 24.1 or newer (its API version 12) installed and its API on (api-enabled: true in its config.yml), on one server or on several servers of a network. In a network each server needs its own CoreProtect database: when the servers share one MySQL database, give each a different table-prefix in CoreProtect's config.yml. Otherwise every server reads (and lists) the same entries, and a rollback on one server also replays what was logged on another in its world of the same name.

• The CoreProtect tab in a player's profile (players.view): what the player did, newest first: blocks broken and placed, chests (what they put in or took out), interactions, kills, items, inventory, joins and leaves, name changes, chat, commands and signs, with the time, the server, the world and the place. Chat and commands need chat.view as well, the same as AdminControl's chat log; private messages (the commands of chat.private-commands and chat.reply-commands) also need chat.private. The passwords and codes of login commands (/login, /register, /changepassword, /ac link and the like) are masked as *** on the server that reads them. Filters: the period (1 hour, 24 hours, 7 days or 30 days, at most 30 days), the kind and the server; 50 entries at a time, "Show more" for the next. Entries already rolled back are marked. The player's former names are listed above. The tab is not there while no server has CoreProtect.
• Rolling back and restoring a player's changes (players.rollback): in the tab, "Roll back changes" or "Restore changes", a period within the role's limit (Team → Roles, "Longest rollback"; the Admin role has 7 days, Moderator and Helper do not have the permission), what (everything as CoreProtect rolls it back: blocks, chests, items and entities; blocks only; chests and items only) and the servers. "Check" counts the changes on each server first (up to 100 000); the button then rolls back or restores them. Staff with a panel account of an equal or higher role cannot be rolled back, as with punishments. One rollback or restore of a player runs at a time. The list under the entries shows each one's state on every server, and the audit log records who did it and how it ended on each server.
• Bans that roll back: the ban dialog has "Roll back their changes" (none by default; with players.rollback); a ban template can have its own window. In game: /ac ban <player> -r 24h <reason> (after the time of /ac tempban), also through EssentialsX's /ban when its commands are taken over. A window over the role's limit refuses the whole ban: nothing is saved. When such a ban is lifted, the dialog (and /ac unban <player> -restore) can restore what was rolled back. CoreProtect counts back from now, so the restore covers the time since the ban plus the rollback's window: a restore restores only what is marked as rolled back, but in that wider window it also restores changes someone else rolled back meanwhile.
• In a network each server reads its own CoreProtect: the panel asks every server with CoreProtect and puts the entries together; a server that does not answer within 10 seconds is named above the list and asked again with "Show more". A rollback for a server that is off waits up to a day and runs when the server starts; after a day it ends as "did not start within a day". A server without CoreProtect still shows and rolls back the others'.
• Notifications: a rollback or restore that ended on every server goes to Discord with the punishments' group (webhook or DiscordSRV channel).
• When CoreProtect's API fails (an update AdminControl does not know yet), the part it hit stops until a restart and the server log says which: reading the entries (the server then shows as not answering), or rolling back (the coreprotect status disappears from /ac version and the server leaves the network's list for rollbacks).
• A window set in a ban template is applied when it can be: a staff member without players.rollback, a window over their limit, a rollback of the player still running or no CoreProtect bans without rolling back, and the audit log says why. A window chosen in the ban dialog or with -r refuses the ban instead.
• A server that was off runs its part of a rollback over the time since the order plus the window, so it covers the same changes; restoring at unban is limited by the window of the rollback it undoes, not by the time since the ban. An older CoreProtect is not used at all, and the log says that 24.1 or newer is needed.
• A rollback undoes only what CoreProtect recorded. CoreProtect writes its entries a moment after they happen, and after a restart it may hold them back for a while (until the previous run's lock on its database runs out): changes made just before a server stops, or right after it starts again, can be missing from CoreProtect itself, and then a rollback finds fewer changes or none.

Integration status

/ac version lists the integrations active on this server, for example Integrations: luckperms, placeholderapi, vault. In a network, the panel's list of servers on the dashboard shows them for every server.

PlaceholderAPI in announcements and the LuckPerms group sync are described in Features.