Permission Reference

Overview

Every uxmEssentials permission lives under the root uxmessentials.*. The plugin ships with defaults that make a fresh install playable the moment it starts, so you only grant permissions to change the defaults, never to switch the plugin on.

Two rules cover almost everything:

• Self-service verbs default to true. Read-only and own-account commands — /home, /balance, /msg, /afk, /list, /warp, /kit, /vault, /help, /lang, and their relatives — are available to everyone out of the box.
• Staff verbs default to op. Mutations, moderation, and anything that acts on another player — /tp, /eco give, /ban, /vanish, the item/world verbs, hologram and NPC admin — require operator status or an explicit grant.

A handful of marker and exempt nodes default to false (they opt a player out of something rather than granting an action). Those are called out where they appear.

To override a default for a group, configure the node in your permission plugin. uxmEssentials does not own group state.

How nodes are organised

Permissions split along four axes:

A staff member usually holds the relevant admin node and the matching bypass node, so they keep operating through a gate — a cooldown, a warmup, a cost, a quota — that would otherwise reject them.

Teleport

The teleport context owns all movement orchestration and the shared cooldown/warmup machinery; homes, warps, and playerwarps delegate execution here, so their gates layer on top.

Homes

All home actions live under the single /home command; the no-arg call opens the slot grid and the rest are subcommands, each gated by its own node.

Warps

Single root /warp; create/move/delete/lock and the editor are subcommands.

Per-warp gates are data-driven in warps.conf: a warp with permission: true requires the family node uxmessentials.warp.use.<warp> (<warp> is the warp id, lower-cased); a warp with a cost charges through the economy provider.

Player Warps

Player-owned warps are keyed by (owner, name) — two players may each keep a base. The base nodes are self-service: holding one lets a player run the verb, while whether they may run it on a particular warp is decided by the owner/co-owner/manager role matrix inside the module. See Player Warps.

The five bypasses (uxmessentials.pwarp.bypass.ban, .password, .whitelist, .safety, .cost) each default op and are listed under Bypass Nodes. The per-player cap is the tier uxmessentials.pwarp.limit.<n>, optionally scoped per world.

Economy

Balances are DB-backed and routed through the shared EconomyProvider port; eco-admin mutations are always audit-logged.

/bank, /deposit, /withdraw, /loan, /wallet, /exchange, /sellall, and the extra /eco subcommands carry their own nodes but are only active when the matching feature flag is on in economy.conf. Per-currency gating uses the tier node uxmessentials.economy.currency.<id> — see Numbered and Tiered Nodes.

Ranks

Rankup, prestige and the ladder panel. The plugin tracks each player's rank with a DB-backed pointer of its own; a rank's rankup actions may set a permission-plugin group, run any command, or nothing at all. The ladder (ranks, order, cost, requirements, actions) is data-driven in modules/ranks/ranks.conf.

A rank's cost is charged through the economy provider, and a placeholder requirement uses an operator-chosen %placeholder% comparison — neither is a plugin-declared node.

Kits

Per-kit gating is data-driven: a kit with permission: true requires uxmessentials.kit.<id>.

Vaults

DB-persisted, player-owned item storage. Vault count and per-vault size are numbered quota tiers.

Trade

Player-to-player trading through a shared, both-confirm window. /trade is the whole surface; the accept/deny answers and the (optional) cross-server escrow all ride on the one node.

The item blacklist, request distance, cooldown, staked currencies, audit, and cross-server escrow are config-driven in modules/trade/config.conf, not permission nodes.

Player State

Toggleable flags and apply-once effects. Every [player] target form additionally requires uxmessentials.playerstate.others. These default to op because they are powerful self/other buffs — loosen the specific ones a donor rank should get.

Messaging

Private messages and persistent mail only (not public chat). Delivery is ignore-aware and respects a moderation mute.

Communication

Connection-message policies, the rotating announcer, and info pages. Operator-authored bodies are config content; the nodes gate the commands.

Moderation

Every action is audit-logged and permission-gated. A mute blocks outbound messaging; a jail blocks /home and /tpa.

Ban and mute durations can be capped per rank with the numbered families uxmessentials.moderation.ban.maxduration.<seconds> and .mute.maxduration.<seconds> — see Numbered and Tiered Nodes.

Staff

STAFF-MODE ONLY — a loadout swap and a gadget hotbar. It issues no sanctions of its own; the FREEZE and COMPASS gadgets orchestrate the moderation and teleport use cases. The /staff text roster and the uxmessentials.staff.member marker live under Presence.

Vanish

PremiumVanish-class invisibility with layered see/use levels. Its own vanish module — the single authority every other context reads for vanish state. See the Vanish guide for the level rules.

The optional layered families uxmessentials.vanish.use.level<N> (vanish at use level N) and uxmessentials.vanish.see.level<N> (see up to level N) tier the see/use model — a viewer sees a vanished player only when their see level is at least the target's use level. Plain .use / .see are level 1; see Numbered and Tiered Nodes.

Presence

Worlds

Multi-world management. Nodes use the uxmessentials.world.* prefix (the plural /worlds command; playerstate's singular /world info verb also reads uxmessentials.world.use).

Per-world entry uses uxmessentials.world.<name>.enter (a world with access restrictions). Bypass nodes are listed under Bypass Nodes.

Item & World

The item/world toolbox carries roughly 65 verbs, each with its own node; the full per-command list lives on the Items, Blocks & World command page. They default op, except the read-only inspection verbs (/itemdb, /iteminfo, /recipe) which are self-service. Two nodes are worth calling out here — the held-item editor, and the in-inventory shulker editor, which has no command of its own.

/give, /enchant and /spawnmob also layer a per-type opt-out family — uxmessentials.itemworld.give.<material>, .enchant.<enchant>, .spawnmob.<mob> — see Numbered and Tiered Nodes. The module's reload tier is uxmessentials.module.itemworld.

Holograms

Named, world-placed native-Display holograms. The whole /hologram surface is gated as one operator tool.

A hologram gated with visibility <name> PERMISSION <node> uses an operator-chosen node (any node your permission plugin manages) — it is not a plugin-declared node and has no fixed entry.

NPC

Server-wide packet fake-player/entity NPCs. The /npc command is an operator surface gated as a whole.

Menus

The operator surface over the built-in menu engine.

Vote

Scoreboard, Tablist & Nametags

The tablist and nametags modules register no commands — both are packet/config-driven.

Discord Linking

The /link redemption itself runs in the optional Discord bridge jar; the in-game commands work whether or not the bridge is installed.

Sitting & Poses

The optional numbered node uxmessentials.poses.cooldown.<seconds> sets an anti-spam wait between starting poses (an open value space, like kit.cooldown.<seconds> — see Numbered and Tiered Nodes). See the Sitting & Poses guide for how each pose works.

Survival

Opt-in gameplay mechanics, each an independently toggleable sub-feature. A mechanic carries a use node uxmessentials.survival.<mechanic> (whether it acts for the player), and the seven with a personal /command toggle also carry uxmessentials.survival.<mechanic>.toggle (whether the player may switch it, from the command or the /survival panel). All are self-service (default: true) — the module itself ships off, and once an operator turns it on the mechanics act for everyone and a player opts out.

Fast leaf decay, the anvil unlocker, one-player sleep and head drops are world-side effects with no permission node — they're governed only by their config blocks. See the Survival Mechanics guide for what each mechanic does.

Security

Account security — an optional second factor a player enrols themselves, join verification, op-command protection, and a same-IP alt / ClientID guard. Not a login system: there's no password or first-join gate, and on an offline-mode server it waits for your login plugin rather than replacing it. The two self-service nodes ship true; the staff reads and the bypass default to op. See the Account Security guide for the flows.

Command Control

Command whitelist / blacklist gating, tab-completion filtering, plugin-hide, and the namespace-bypass block — the PlHidePro / CommandWhitelist feature set. It ships enabled but inert (a blacklist with empty lists, plugin-hide off), so both nodes default to op and gate nobody until you name commands. See the Command Control guide.

Villagers

Villager trade management — trades that never lock out, a restock timer, a staff trade editor, click-to-trade, a villager saver, pickup, follow, and leashing. The module ships disabled, so all six action nodes default to op and grant nothing until you turn the module on and then the matching feature with it. The four trade-availability switches (infinite trading, restock, instant restock, disable trades) take no permission — they're config-only. See the Villagers guide.

Inventory Rollback

Inventory snapshot and restore — the plugin freezes a player's inventory on death and (by config) on logout, keeps a bounded history of those snapshots in the database (never PDC, so they survive a world rollback), and lets staff browse and restore them from a GUI. The module ships disabled; turn it on and it captures on death and logout straight away. A restore acts on a live inventory, so the target must be online. See the Inventory Rollback guide.

Regions

WorldGuard region management — a menu over an installed WorldGuard to browse regions, define cuboids, cycle their state flags, and edit their member/owner rosters. WorldGuard is a soft-dependency: with it absent the module is inert and every command answers "WorldGuard not installed" (WorldEdit is a further optional soft-depend, used only for selection-based /regions create). Region management is staff work, so all five action nodes default to op. See the Regions guide.

Server Tweaks

A grab-bag of silent server-side infrastructure tweaks — a custom F3 brand, a console-log filter, an unsigned-chat option, and a SignedVelocity backend companion. The module is config-only: it registers no commands, so it has no action permission nodes. Every tweak defaults off and is switched entirely from modules/servertweaks/config.conf. See the Server Tweaks guide. The module's reload tier is uxmessentials.module.servertweaks.

Shared kernel

The kernel owns no feature commands, but carries two cross-cutting self-service verbs.

Numbered and Tiered Nodes

Some limits are values, not yes/no flags: how many homes a player may own, how long their teleport cooldown is. Instead of hard-coding these per group, uxmEssentials encodes the value in the node and reads the best-matching one the player holds, falling back to a config default.

How they resolve

Every value-bearing node passes through the shared Permissions port and a single QuotaNodeReducer, so the semantics are identical across contexts:

• Quota families (home.limit, vault.amount, vault.size, pwarp.limit, *.maxduration) reduce to the maximum — more is better, the most generous node wins.
• Cooldown / warmup families (*.cooldown, *.warmup) reduce to the minimum — less is better; 0 means "no wait".
• -1 is the unlimited sentinel for quota families (a home.limit.-1 means no quota at all). It is never used for cooldown/warmup families, where 0 is "no wait".
• A player with no numbered node and no meta falls back to the per-context config default — never to "unlimited".

A numbered node may carry an optional <world> segment between the family and the value, so a quota or cooldown can differ per destination world:

uxmessentials.home.limit.creative.20
uxmessentials.tp.warmup.nether.0
uxmessentials.warp.cooldown.<world>.<seconds>

The unscoped form applies everywhere; the world-scoped form applies only when that world is the one being resolved against. Matching scoped and unscoped nodes are simply folded into the same reducer.

Because the value spaces (<n>, <seconds>, <rows>, and so on) are open, these nodes are not enumerated in paper-plugin.yml; operators grant the specific instances they need.

Bypass Nodes

Bypass nodes let a trusted player cut through a gate — a cooldown, warmup, cost, lock, or restriction — that would normally reject them. They all default to op, except the two vault/marker exempt nodes noted below.

Module Gates and Admin Roots

uxmessentials.module.<id> — per-module reload tier

Every bounded context is a first-class feature module. Each owns a node tier uxmessentials.module.<id> (default op) — not the feature's runtime permission, but the per-module administrative gate: who may inspect and hot-reload that one module via /uxmess reload <id> without holding the blanket uxmessentials.admin.reload. <id> is the module id used everywhere else (config path modules.<id>, the reload command, the tier node):

teleport   worlds     homes       economy    warps      kits
playerstate messaging presence    moderation itemworld  vaults
communication holograms playerwarps scoreboard tablist  nametags
vote       discordlink staff       npc        custommenus
poses      survival    ranks       trade      vanish
security   commandcontrol villagers   invrollback
regions    servertweaks

/uxmess reload <module> accepts either uxmessentials.admin.reload (blanket) or the matching uxmessentials.module.<id> (delegated), so you can hand a junior staffer reload rights over one module without the keys to the whole plugin.

/uxmess admin tree

Management-GUI nodes

The management hub gathers each module's management GUI behind one menu. Each module registers its entry under uxmessentials.<module>.gui (for example uxmessentials.holograms.gui, uxmessentials.npc.gui, uxmessentials.economy.admin). Each defaults to op, the hub shows a viewer only the entries whose node they hold, and a module's own /<module> GUI entry point opens directly for a holder of the same node — so you can delegate one module's panel without granting the rest.

/lp group donor permission set uxmessentials.home.limit.10 true
/lp group donor permission set uxmessentials.fly.use true
/lp group donor permission set uxmessentials.tp.warmup.bypass true

/lp group default permission set uxmessentials.itemworld.spawnmob.wither false

/lp group donor meta set home-limit 10

Next Steps

• Command Overview — how commands are registered, aliased, renamed, and disabled
• LuckPerms Integration — meta-based quotas and group resolution
• Developer API — integrate with uxmEssentials at runtime