Astral Realms Documentation Help

Commands

Both modules register a /dungeon-family command, but they are different command trees with different aliases, on different servers. Neither is a superset of the other.

Command

Module

Server

Permission

/donjons

Bridge

Lobby (portal-group or anywhere the bridge runs)

—

/donjons create <blueprint>

Bridge

Lobby

dungeons.create

/dungeon reload

Paper

Dungeon server

dungeons.command + dungeons.reload

/dungeon simulate <blueprint> [count]

Paper

Dungeon server

dungeons.command + dungeons.simulate

/spawn

Paper

Dungeon server

—

/donjons (bridge)

Aliases: /donjons, /dj, /donjon. Player-only.

/donjons

Opens the menu named by inventory-menu in the bridge config.yml (dungeons-inventory by default) — the dungeon inventory and preset screen. If the menu fails to compute or open, the player gets the unexpected-error message and the failure is logged with the menu id.

No permission node: any player may open their own dungeon inventory.

/donjons create <blueprint>

Permission dungeons.create. Requests an instance for <blueprint> directly, bypassing the portal.

Unlike walking into a portal, this only checks that the player is in a party (no-party otherwise) — there is no key check, no requirements evaluation, no leader check and no party-size check. It is the staff/testing entry point; the portal is the player-facing one. See Portals & Keys for what the portal path enforces on top.

On completion the player gets creation-success (with %blueprint_name%) or creation-failure; on success TeleportationService sends the leader and every party member to the responding dungeon server.

/dungeon (dungeon server)

Aliases: /dungeon, /dungeons. The whole class requires dungeons.command. Player-only.

There is no create subcommand here — instances are only ever created through the dungeons.servers RPC exchange, never locally.

/dungeon reload

Permission dungeons.reload. Re-reads config.yml, messages.yml, and fully re-scans rooms/ and blueprints/. Reports success or the exception message in chat, and logs the stack trace on failure. Running instances are unaffected — see Reload.

/dungeon simulate <blueprint> [count]

Permission dungeons.simulate. Generates count layouts (default 100, max 5000) for a blueprint — topology only: no world is created and no schematic is pasted — and reports how many rooms each run produced plus a global budget-utilisation summary. Generation runs off the main thread.

count outside 1..5000 is rejected. Runs are enumerated individually only when count <= 50; larger batches get the summary alone.

The reported budget bounds NORMAL-room growth only. Every layout also carries the START room, the END (boss) room, and however many CAP rooms are needed to seal open doorways, so the total room count almost always exceeds the budget — the summary reports budget utilisation (NORMAL / budget) and total rooms separately. Use it to tune generation.min-rooms/max-rooms/branchiness/rooms.weights without building anything. See Generating a layout.

/spawn (dungeon server)

No permission node, player-only. Sends the player to the spawn-group server group through TeleportationService — the escape hatch out of a dungeon server. Nothing else happens: the player's instance is torn down by the normal quit path (PlayerConnectionListener unregisters them, tears down their guidance stream and flushes their run data), and an instance whose last alive participant leaves ends with NO_ALIVE_PARTICIPANTS.

Tab completion & argument resolution

Both modules register a DungeonBlueprint context resolver, so a <blueprint> argument is resolved to the model object before the command body runs; an unknown id fails with Dungeon blueprint not found: <id> and the body never executes. They resolve against different blueprint sets.

Completion

Module

Source

@dungeonBlueprints

Bridge

ServerService#availableBlueprints() — blueprint ids advertised by any dungeon server that still has a free instance slot — intersected with the bridge blueprints that actually exist locally. A dungeon with no bridge blueprint, or with no server currently able to host it, does not complete.

@dungeons

Paper

Every dungeon blueprint loaded from this server's own blueprints/ folder.

Because the bridge completion is driven by the heartbeat cache (30s writes, 1-minute refresh), a dungeon server that has just come up or just filled up can take up to a minute to appear or disappear from completion. The id still works if typed manually — the availability check happens again at portal/create time.

Permission summary

Node

Grants

dungeons.create

/donjons create on the bridge.

dungeons.command

Access to the /dungeon tree on the dungeon server (required in addition to each subcommand's own node).

dungeons.reload

/dungeon reload.

dungeons.simulate

/dungeon simulate.

/donjons (bare) and /spawn are unrestricted.

Last modified: 25 September 2026