Node Syntax & Wildcard Rules

Permission nodes follow strict naming rules. Understanding wildcard expansion is essential for setting up roles correctly — a single wildcard node can grant dozens of capabilities at once.

Basic Syntax Rules

• Nodes are lowercase only — permission.node.player.chat.Global is not valid
• Segments are separated by dots (.) — no spaces, hyphens, or slashes
• The first two segments are always permission.node
• The wildcard character is * and must appear as the last segment only
• Integers and datapack IDs can appear as segments where documented (e.g. booster.1, storage.3)

Wildcard Expansion

A wildcard node (*) matches every node that shares the same prefix. For example:

Role Inheritance Wildcards

Role inheritance wildcards (global.roles.*, guild.roles.*, alliance.roles.*) are a special case — they do not expand to permission nodes directly. Instead, they tell the system to copy the entire node set of the referenced role into the current role at evaluation time.

-- Moderator role definition (example):
global.roles.member.*          ← copy all Member nodes
permission.node.moderator.*    ← then add all Moderator-specific nodes

Bracket Syntax (Chat Scoping)

Some nodes use bracket notation to scope a permission to a specific role context. This appears in guild and alliance chat nodes:

permission.node.guild.text.chat.message.["guild.roles.officer"]

The value inside the brackets is the role wildcard whose members can see or post in that chat channel. Replace the value to change which role the channel is scoped to.

Integer Placeholders

Some nodes use {integer} as a placeholder for a specific slot, tier, or level number. Replace {integer} with the actual number when assigning the node:

permission.node.guild.admin.manage.base.type.booster.{integer}
-- becomes, for tier 2:
permission.node.guild.admin.manage.base.type.booster.2

Common Mistakes