BlazeBans/Punishing players
The punish GUI
A three-step menu that walks staff through a punishment. It is the same code path as the commands, so anything issued through it obeys the same hierarchy, duration limits, and scope rules.
Opening it
/punishgui <player>
/punishgui <player> [type] [template]The optional arguments skip ahead. /punishgui Steve ban opens on the ban reasons, and /punishgui Steve ban General-Cheating opens on the confirmation screen for that template.
Requires blazebans.command.punishgui and blazebans.command.punish. Players only, since there is no menu to show console.
The three steps
Type. Ban, mute, warn, or kick. Only the types you hold the matching command permission for are shown, so a helper without blazebans.command.ban never sees the ban option.
Reason. Your templates for that type, each showing its duration, stored reason, and whether proof is required. Two controls sit alongside them:
- Search. Opens a text prompt and filters templates by ID and reason. Useful once you have more than a couple of screens of them.
- Punish via IP. Toggles a ban or mute to target the player's address instead, which is the menu equivalent of
/ipban. It needsblazebans.ip, and it does not appear for warns or kicks.
Confirm. A summary of the player, duration, reason, proof requirement, and attached proof URL, with confirm and cancel. Nothing is written until confirm is clicked.
Every step has a back button, and closing the menu at any point cancels without writing anything.
Proof
If the selected template sets proof-required: true and proof requirements are enabled in settings.yml, a prompt appears before the confirmation step. Submitting an empty or malformed URL is refused with a message explaining the format.
On Minecraft 1.21.6 and newer this is a native dialog. On older servers and older clients, staff are prompted in chat and can type cancel to back out. Both paths end up in the same place.
Staff with blazebans.proof.bypass skip the prompt.
Why use it
Three reasons, in order of how often they matter:
- New staff. Someone trusted enough to moderate is not always someone who will remember flag syntax during an incident.
- Consistency. The menu only offers templates, so every punishment issued through it uses a reason you approved.
- Fewer mistakes. A confirmation screen naming the player and the duration catches the wrong-name punishment before it happens rather than after.
Experienced staff will use the commands. Both write the same records, so a team can use either.
Styling it
Everything in the menu is configured under menus.punishgui in menus.yml: the title, the size of each step, the item used for each punishment type, the reason item layout, the toggle and search buttons, and the confirmation summary.
menus:
punishgui:
inventory:
type-size: 27
reason-size: 45
confirm-size: 27
type-items:
ban:
material: "MACE"
name: "<color:{color_negative}>Ban</color>"
lore:
- "<gray>Choose the ban reason.</gray>"Sizes must be multiples of nine. Names and lore use MiniMessage. The reason item takes {template_id}, {duration}, {reason}, and {proof_required}; the confirmation summary adds {victim_name} and {proof_url}.
Full detail in Menus.
/blazebans profile <player> opens a player's record as a menu, with a route into the punish GUI from there. That is usually the better starting point: look at what someone has already done, then act. See Profiles.

