BlazeBans/Automatic enforcement

Lockdown

Two switches for incidents. Server lockdown closes the door. Chat lockdown freezes conversation without kicking anyone.

Server lockdown

minecraft
/blazebans lockdown enable
/blazebans lockdown disable
/blazebans lockdown status

Needs blazebans.command.lockdown.

Enabling it blocks new connections and immediately disconnects online players who do not have access. The command reports how many were disconnected.

Access means blazebans.bypass.lockdown or blazebans.admin. Everyone else sees the lockdown-denied screen and cannot rejoin until it is lifted.

Confirmation

Enabling lockdown asks for confirmation first, since it disconnects people. In game that is a dialog with the consequence spelled out. From console, or where a dialog cannot be shown, you get a command to run instead:

minecraft
/blazebans lockdown enable confirm

That is deliberate friction. A mistyped lockdown on a busy server empties it in a second.

Surviving a restart

yaml
lockdown:
  persist-through-restarts: true

On by default. The state is saved, so a server that restarts during an incident comes back locked rather than open.

Turn it off if you would rather a restart always clears it. /blazebans lockdown status reports both the current state and whether persistence is on, so you can tell which behaviour you are getting.

When to use it

  • An exploit is being used and you need to stop the bleeding while you patch it.
  • A bot wave is joining faster than you can ban.
  • Maintenance where a whitelist would be slower to set up than a lockdown.

Grant blazebans.bypass.lockdown to your whole staff team ahead of time. Discovering during an incident that only the owner can get in is a bad way to find out.

Chat lockdown

minecraft
/blazebans chatlockdown enable
/blazebans chatlockdown disable
/blazebans chatlockdown status

Needs blazebans.command.chatlockdown.

Blocks chat for everyone without blazebans.bypass.chatlockdown. Nobody is disconnected and nobody is punished. Blocked players see the chat-lockdown-denied message.

No confirmation is required, because nothing is lost by turning it on and back off.

yaml
chat-lockdown:
  persist-through-restarts: true

Same behaviour as server lockdown persistence.

When to use it

  • An argument is escalating faster than staff can mute individuals.
  • Someone is being harassed and you want it to stop now, then sort out who did what.
  • A raid is flooding chat.
  • You need everyone to read one announcement.

This is the one you will reach for more often. It is reversible, it punishes nobody, and it buys the thirty seconds you need to work out what is actually happening.

Which to use

SituationUse
Chat is out of controlChat lockdown
One player is the problemA mute
An exploit is being usedServer lockdown
Bot waveServer lockdown
You need everyone to read somethingChat lockdown
MaintenanceServer lockdown

Server lockdown is the heavier tool. Reach for chat lockdown first unless the problem is people being on the server at all.

On a network

State is per install. Lockdown on the Velocity proxy stops people reaching any backend, which is usually what you want. Lockdown on one backend stops people joining that server while the rest of the network stays open.

For a network-wide close, use the proxy. For one broken world, use that backend.

Placeholders

Both states are readable through PlaceholderAPI:

txt
%blazebans_lockdown%
%blazebans_chat_lockdown%

Useful on a scoreboard or in a tab list so staff can see the state without running a command. See PlaceholderAPI.

Permissions

NodeGrants
blazebans.command.lockdownRunning the lockdown command
blazebans.bypass.lockdownJoining while locked down
blazebans.command.chatlockdownRunning the chat lockdown command
blazebans.bypass.chatlockdownTalking while chat is locked

The two bypass nodes default to op, so operators keep access without being granted anything.