BlazeBans/Automatic enforcement

Mute enforcement

A mute that only blocks public chat is not a mute. This is the setting that closes the private-message route around it.

What a mute blocks

Public chat, always. Muted players see the mute-denied message with their reason.

Commands, when command blocking is on. That is the part that needs configuring.

Blocking commands

In settings.yml:

yaml
muted-commands:
  enabled: true
  bypass-permission: "blazebans.mute.commands.bypass"
  alert-staff: true
  discord-webhook: true
  blocked:
    - "msg"
    - "pm"
    - "tell"
    - "whisper"
    - "w"
    - "r"
    - "reply"
    - "me"
    - "shout"
    - "broadcast"
    - "mail"
    - "partychat"
    - "guildchat"
    - "minecraft:msg"
    - "minecraft:tell"
    - "minecraft:w"
    - "minecraft:me"
    - "essentials:msg"
    - "essentials:tell"
    - "essentials:w"
    - "essentials:reply"
    - "essentials:me"

On by default, with a list covering vanilla and EssentialsX.

KeyEffect
enabledMaster switch for command blocking
bypass-permissionNode that lets someone run blocked commands while muted
alert-staffNotify staff when a muted player tries one
discord-webhookPost the attempt to Discord, if that event is enabled
blockedThe commands to block

Adding your own

The default list covers what ships with a vanilla or EssentialsX server. Anything else on your server that carries text between players needs adding by hand.

Common gaps:

yaml
muted-commands:
  blocked:
    - "party"
    - "p"
    - "guild"
    - "g"
    - "faction"
    - "f"
    - "town"
    - "nation"
    - "helpop"
    - "report"
    - "nick"
    - "book"

Two rules for building the list:

Include the namespaced form. Minecraft lets players run /minecraft:msg and /essentials:msg directly. Blocking msg alone does not cover those, which is why the defaults list both.

Include every alias. If your chat plugin registers /party, /p, and /pc, all three need listing. BlazeBans matches on what was typed.

Audit this properly once. Log in on a test account, mute yourself, and try every command you can think of that puts text in front of another player.

Staff alerts

With alert-staff: true, anyone holding blazebans.staff.notify sees an alert when a muted player tries a blocked command, showing the command they attempted.

yaml
punishments:
  alert-staff-muted-chat: true

That one covers chat rather than commands: staff see the message a muted player tried to send. The text is hoverable so it does not sit in staff chat by default.

Both are useful during an incident. A muted player still trying to reach people is a sign the mute is not enough.

Bypassing

blazebans.mute.commands.bypass lets someone run blocked commands while muted. The node name is configurable through bypass-permission if you already have a scheme.

Grant it to staff. A muted moderator is rare, but a moderator blocked from /helpop during their own appeal is a bad afternoon.

There is also blazebans.bypass.mute, which prevents someone being muted at all.

Discord

With discord-webhook: true here and events.muted-command: true in discord.yml, attempts post to your staff channel. Chat attempts use events.muted-chat.

That gives you a record outside the game of someone repeatedly trying to talk through a mute, which is useful evidence when the mute becomes a ban. See Discord webhooks.

Voice chat

A normal mute does not block voice by default. If you run Simple Voice Chat, the voice chat addon can extend regular mutes to voice:

yaml
enforcement:
  auto-voice-mute-regular-mutes: true

Without that, a muted player can still talk. It just is not in chat.

Letting plugins override

The BlazeBansMutedCommandEvent fires before a command is blocked. Cancelling it tells BlazeBans to allow that attempt, which is how you exempt something conditionally rather than by permission:

java
@EventHandler
public void onMutedCommand(BlazeBansMutedCommandEvent event) {
    if (event.command().toLowerCase(Locale.ROOT).startsWith("/appeal")) {
        event.setCancelled(true);
    }
}

See Enforcement and exemptions.