MuteBefehl Wiki

Prefix System

Ranks, chat format, nametag colors and tablist appearance.

The prefix system controls how players appear in chat, on the tablist and above their head. All three use the same prefix, so the look stays consistent everywhere.

What it does

  • Maps players to ranks based on permission nodes (muteessentials.rank.<key>).
  • Applies a configurable chat format with placeholders.
  • Sets the nametag color above the player's head.
  • Mirrors the prefix into the tablist entry.

Configuration

PrefixSystem:
  Enabled: true
  ChatFormat: "%PREFIX%%PLAYER%%SUFFIX%&8: &f%MESSAGE%"
  Ranks:
    owner:
      permission: "muteessentials.rank.owner"
      prefix: "&c&lOWNER &8» &c"
      suffix: ""
      priority: 1000
    default:
      permission: ""
      prefix: "&7&lPLAYER &8» &7"
      suffix: ""
      priority: 100
KeyDescription
ChatFormatChat layout. %PREFIX%, %PLAYER%, %SUFFIX%, %MESSAGE% are replaced.
permissionThe node that assigns the rank. Leave empty for the default rank.
prefixShown before the player name. The last color code in the prefix determines the name color.
priorityHigher priorities win when a player holds multiple rank permissions.

Default rank colors map 1:1 to Minecraft dye colors, so a 16-wool picker in the AdminGUI matches the chat appearance.

Ranks and permissions

A rank in MuteEssentials is a cosmetic identity (chat prefix, nametag color, tablist entry). It is not, by itself, a set of gameplay permissions. It is worth understanding how a player ends up with a rank, and how to make a rank actually grant access.

How a player gets a rank

There are two ways, and they work together:

  1. Automatic (permission-based). MuteEssentials picks the rank whose permission node the player holds. If a player has muteessentials.rank.admin from any source (most commonly a LuckPerms group), they are shown as admin with no further action. When a player holds several rank permissions, the highest priority wins.
  2. Manual override. /rank set <player> <rank> and the AdminGUI force a specific rank. This does two things: it stores a display override for that player, and it grants the rank's permission node through LuckPerms (lp user <player> permission set <node>). The AdminGUI first removes the other ranks' nodes, so switching ranks is exclusive. /rank remove clears the override and unsets the node again.

What the rank permission actually does

The muteessentials.rank.<key> node is only a marker. On its own it changes nothing except which prefix is displayed. It grants gameplay access only if you attach permissions to that node yourself (for example via LuckPerms inheritance). This is why setting a rank appears to "only change the name" - that is expected.

Making a rank grant real access

If you want assigning a rank to also give the player real permissions, let LuckPerms be the source of truth and tie the two together. Two common setups:

  • Group carries the marker (recommended). Create a LuckPerms group per rank (e.g. admin) and give that group the muteessentials.rank.admin node. Now lp user <player> parent add admin grants all the group's permissions and makes MuteEssentials display the admin rank automatically. Here you manage players through LuckPerms and MuteEssentials just follows.
  • Rank drives the group. Set a rank's permission to the LuckPerms membership node, e.g. permission: "group.admin". Then /rank set <player> admin runs lp user <player> permission set group.admin, which in LuckPerms is exactly group membership - the player gets the group's permissions, the prefix shows, and the GUI's exclusive switching cleanly moves them between groups.

Either way the rule of thumb is: LuckPerms controls access, MuteEssentials controls appearance, and the shared muteessentials.rank.<key> node is what keeps them in sync.

On this page