BlazeBans/Integrations

LuckPerms

BlazeBans reads LuckPerms group membership directly. That lets staff hierarchy and exemptions follow the groups you already maintain, rather than duplicating your rank structure as permission nodes.

LuckPerms is a soft dependency. Everything works without it; two features are just more convenient with it.

Staff hierarchy from groups

yaml

staff-hierarchy:
  group-weights:
    helper: 10
    moderator: 50
    admin: 100
    owner: 1000

BlazeBans reads each player's primary and inherited groups and uses their highest matching weight. A staff member can punish someone only when their weight is at or above the target's.

No extra permission is needed. Group names are matched case-insensitively, and a player in no listed group has weight 0.

Because inheritance is followed, a rank that inherits from moderator picks up weight 50 automatically. Promote someone in LuckPerms and their BlazeBans authority follows.

Without LuckPerms, grant blazebans.weight.<number> per rank instead. Both work, and the highest value found wins.

Group exemptions

yaml

exempt:
  luckperms-groups:
    - "admin"
    - "owner"

Members of these groups cannot be punished by any player, regardless of weight. Console bypasses it.

Leave the list empty if you want senior staff to be able to act on a compromised admin account. Full detail in Hierarchy and exemptions.

Managing permissions

Everything else is ordinary permission management. A moderator group:

txt

# Run these in game or from console:
# /lp group moderator permission set blazebans.command.ban true
# /lp group moderator permission set blazebans.command.mute true
# /lp group moderator permission set blazebans.command.warn true
# /lp group moderator permission set blazebans.command.kick true
# /lp group moderator permission set blazebans.command.history true
# /lp group moderator permission set blazebans.staff.notify true
# /lp group moderator permission set blazebans.duration.moderator true

Or with a wildcard, if your setup uses them:

txt

# /lp group moderator permission set blazebans.command.* true

Be careful with wildcards. blazebans.* includes blazebans.admin, which bypasses scope checks, hierarchy, and group exemptions. Grant that node deliberately, never as part of a pattern.

Suggested permission sets per rank are in Permission reference.

Contexts

LuckPerms contexts work normally, so per-server or per-world permissions apply to BlazeBans nodes like any other.

That is one way to build a network where a moderator can punish on the survival server but not on the hub, without touching BlazeBans configuration:

txt

# /lp group moderator permission set blazebans.command.ban true server=survival

Combine it with scope permissions for the same effect at the punishment level rather than the command level.

Checking what someone has

txt

# /lp user <player> permission check blazebans.command.ban
# /lp user <player> info

info shows their primary group and inheritance, which is what BlazeBans reads for weight. If a hierarchy check is behaving unexpectedly, that is the first thing to look at: an inherited blazebans.weight.* node from a parent group is the usual explanation.

Without LuckPerms

Every feature still works. You lose the group integration, so:

Grant blazebans.weight.<number> per rank instead of using group-weights.
Use exempt.players instead of exempt.luckperms-groups.

Any permission plugin that implements Bukkit's permission API will handle the nodes. The group reading specifically is LuckPerms only.