What your server can run

Two things decide whether a feature runs on your server: which of our jars you installed, and whether the server holds the Ragnarok Key. Most "why is this missing" questions are one of those two, and this page is how you tell which.

1. One key: the Ragnarok Key

There is exactly one key, the Ragnarok Key (mod id dmz_ragnarok_key). It is a server-side mod that holds the private feature set, and it runs on our own servers. The older keys (Shurui's Key, Popo's Key, Wolf's Key and the Kinetic Key) and their tiers are gone: there is no middle tier any more, a feature is either public or it needs the Ragnarok Key.

• Without the key a server runs the public set below, in full.
• With the key it runs everything.
• There is no singleplayer or LAN exemption: singleplayer runs the public set like any other server without the key.
• Private things are simply absent without the key (menus, rows, items, keybinds and commands are hidden, never greyed out). Players' clients learn what the server offers when they join, so nothing is decided client side.
• A jar that only carries the key's mod id unlocks nothing: the key counts only when it really installs its features.

2. What every server gets

Everything in this list works on any server running the mods, key or no key:

• Space, in full: travel, hazards, planets, planet claims, Planet Buster and the Apophis event, plus the space pod, nimbus and time machine chips.
• Hoverbikes and the senzu bean system (beans, the senzu bag, the farm).
• Patreon perks: supporter crowns in chat and the Patreon wardrobe cosmetics, which follow the supporter's active Patreon tier and lapse with it.
• Form cosmetics.
• Dungeons, raids and tournaments public content: the advanced spawner (disguises and its BOSS tier included), every raid type except rifts, and every tournament format.
• The corrupted cycle (scatter, event and the shadow dragon bosses), the only way to unlock the public shadow dragon race. Without the key the bosses use built-in defaults: they spawn at random spots with the stats of DMZ's Buu saga Majin Buu and the shadow dragon moves.
• Character slots.
• Wishes: the added dragon ball sets (Black Star, Super, Cerulean) and their shenron, including the Super Shenron power wish (100,000,000 TP plus a quarter of each current stat, up to three times per character slot).
• The SDU content editors (races, forms, sagas, wishes, NPCs), the combat layer (dash, melee clash, going through terrain at speed), mini clones, saibaman seeds (seed to pet), katchin tools, runes and WorldEdit selection tools.

  The Ragnarok Key adds the private set on top: among others the economy and everything under it, guilds, ranks, chat, tab list, permissions, protection and the rest of the server management tools, instanced dungeon floors, rifts, Z-Souls, TP and stat gems, TP boosts, prestige, god roles, the ocarina, the SSJ5 and Namekian rituals, Z orbs, racing, the event engine and disguise.

3. Staff tooling (written for a moderator)

The Staff module needs the Ragnarok Key (it does not exist on a server without it). Files under shuruisutilities/src/main/java/net/shurui/shuruisutilities/staff/ and .../commands/.

Roles and the roster

Ten roles, in two bands (StaffRole.java):

• Shift roles (clock in to hold their group): admin, head-mod, head-builder, mod,

  builder, trial-mod, helper. While off duty they have a normal player's powers and nameplate.

• Oversight roles (never clock in, group always active, never swept): owner, server-manager,

  head-admin.

  Each role name IS a permission group of the same name that already exists on the server. Clocking in adds that group; clocking out removes it. The enum owns no permissions of its own.

• Reviewers (may write and approve/deny tasks, and see other people's shift records): admin and

  every oversight role. (canReview is true for admin/head-admin/server-manager/owner.)

• Auto-removable (the 7-day inactivity sweep may strip them without asking): admin, head-mod,

  head-builder, mod, builder, trial-mod, helper. head-mod and head-builder are flagged for a human decision instead of auto-removed (they are shift roles but not auto-removable).

The clock and shifts

• /clockin - go on duty; grants your role's permission group and staff tag. (CommandClock.In)
• /clockout - go off duty; banks the shift time. (CommandClock.Out)
• Logging out ends your shift automatically. A player swept off the roster for inactivity cannot

  /clockin to recover their group.

/staff (the roster, clock and task board in one command)

/staff status (your own record), /staff clockin, /staff clockout, /staff list (roster; reviewers/admins only), /staff status <player> (reviewers only), /staff add <player> <role> and /staff remove <player> (needs su.staff.admin), plus the task board below. From the console only list, add, remove work.

The task board

• /staff tasks - tasks visible to your role
• /staff accept <id> - take one (must be clocked in; you hold one at a time)
• /staff drop <id> - put it back
• /staff complete <id> - mark done, notifies reviewers
• /staff review - list completions awaiting review (reviewers)
• /staff approve <id> / /staff deny <id> <reason> (reviewers)
• /staff addtask <roles|any> <title | description> and /staff deltask <id> (reviewers)

Permission nodes (Staff)

ModuleStaff.java:36-45:

• su.staff - parent description node
• su.staff.clock (default NONE) - clock in and out; held by the staff groups
• su.staff.admin (default OP) - add/remove roster entries
• su.staff.review (default OP) - write tasks and review completions

Jail

• /jail <player> [jail] [time] [reason...] - confine. No jail name uses the default jail; no time

  means indefinite until /unjail. Times read as 30m, 2h, 1d; a bare number is minutes. /jail <player> <time> [reason] skips the jail name. (CommandJail, default OP)

• /setjail <name> - create a jail point at your location.
• /unjail <player> - release.
• A player with the jail-exempt permission cannot be jailed. Shard-aware: if the jail sits in a

  dimension no reachable server hosts, nobody is jailed and the sentence is not recorded.

Vanish

• /vanish - toggle yourself invisible (default OP). /vanish <player> needs su.commands.vanish.others.
• Vanished staff see each other; ordinary players see nothing. A toggle sends a fake vanilla

  leave/join to ordinary players so a mid-session disappearance is not unexplained. Survives restart and travels across shards. Nodes: su.commands.vanish, su.commands.vanish.others (CommandVanish.java:60,62).

Moderation commands (all in commands/player/, commands/world/, chat/command/)

Bans: /tempban, /unban. Chat mutes: /mute, /tempmute, /unmute. Player control: /freeze, /god, /heal, /kill, /smite, /burn, /fly, /speed, /gamemode, /potion, /inventorysee, /doas, /seen, /locate, /playtime. Staff comms: /staffchat, /adminchat, /socialspy. World: /butcher, /clearitems, /remove, /time, /weather, /updateblocks. Most default to OP. (Exact per-command nodes live in each CommandX.java; not all were read for this chapter.)

The audit trail

audit/AuditLog.java and audit/AuditEvents.java. Every audit line is prefixed [audit] so grep '\[audit\]' on the server log returns the whole trail across all five source trees. It is deliberately NOT key gated (diagnostics, not a feature): a server that cannot answer "who took this" cannot be moderated at any tier. It logs narrowly and on purpose: portable-storage (Sophisticated Backpacks) opens, and one player right-clicking another (the worn-backpack theft vector, throttled to one line per pair per 10s). It is a log grep, not an in-game command.

The permission group tree

Groups are DATA (the permission store / permissions.json), not hardcoded, and must never be hand-written (see the memory note "never hand-write permissions.json"). Manage them with:

• /perm ... (CommandPermissions, alias perm, default OP) - the full permission/group editor
• /promote <player> <group> (CommandPromote, default OP) - move a player into a group
• /permgui - the in-game permission GUI
• /area (CommandZone, alias area) - zone/region permission scoping

  The canonical staff groups are the ten StaffRole names above (owner, server-manager, head-admin, admin, head-mod, head-builder, mod, builder, trial-mod, helper). The live production hierarchy (donor inheritance, priority-vs-inheritance, the orphan legend group) is server data captured in the memory note "Live permission group tree", not in this source tree, so it is out of scope to enumerate from code here.

4. What decides what runs

A feature runs when its jar is installed and, if it is private, the Ragnarok Key is present. The old operator switchboard (config/dmz_ragnarok/modules.cfg) is no longer read; an existing file stays on disk untouched.

• Jars. The suite ships as one jar with everything, or as a core jar plus the Dungeons, Raids, Tournaments and Space module jars. Install one layout or the other, never both. A module you did not install simply is not there.
• The key. It never adds content of its own and loads beside whichever layout you run. Removing it hides the private features again; the public set keeps working.
• Removing a module from an existing world would silently lose that module's blocks and entities, so the server refuses to start and names the jar to install instead.

Worked example: the advanced spawner's BOSS tier

The spawner lives in the Dungeons module and its BOSS tier is public. On any server with Dungeons installed (on its own or inside the all-in-one jar), boss spawns fire, key or no key. Without Dungeons installed there is no spawner at all.