Admin Commands & Tools

Comprehensive reference covering admin command sets, interface design patterns, and permission systems across major MUD codebases.

1. Admin/Immortal Command Reference

1.1 Player Management Commands

These commands let admins move through the world, move players, observe activity, and directly interact with the game state.

Movement & Teleportation

Player Transport

Remote Execution

Body Control

Observation & Stealth

1.2 Punishment Commands

Commands for disciplining players, restricting access, and enforcing rules.

Communication Restrictions

Access Restrictions

Other Punishments

1.3 World Management Commands

Commands for manipulating the game world — loading, creating, resetting, and restoring.

1.4 Information Commands

Commands for inspecting the state of the game, players, objects, and connections.

1.5 Building Commands (OLC — Online Creation)

OLC (Online Creation) systems let builders edit areas in real-time while logged in, replacing the old workflow of editing text files and rebooting. The most widely adopted OLC originated from NiMUD (1994) and was ported across the Diku family.

ROM/Merc OLC (Ivan Toledo’s OLC 1.1+)

All OLC commands enter a modal editor — you type a command, then use subcommands to modify fields. done exits.

OLC item value reference (for oedit v0-v4):

SMAUG OLC

SMAUG’s OLC is similar in structure but adds extra commands:

Additional SMAUG admin commands for content configuration:

Evennia Building Commands

Evennia takes a fundamentally different approach — no modal editors, no vnums. Everything is a Python object with a database reference (#dbref). Building commands are standalone rather than entering an editor mode.

1.6 Cross-Codebase Command Comparison

2. Admin Interface Design

2.1 Wiz Commands vs Player Commands

In traditional MUDs, admin commands and player commands exist in the same text interface but are gated by level. The separation is purely logical, not visual:

• Same input line: Admins type commands into the same prompt as players. There’s no separate admin console.
• Level gating: Each command has a minimum level. The wizhelp command shows only commands available at your current level.
• Same parser: The command interpreter checks your level against the command table before executing.

In Merc/ROM, the command table in interp.c defines each command with a minimum level:

{ "goto",     do_goto,     POS_DEAD, L_HER, LOG_NORMAL, 1 },
{ "transfer", do_transfer, POS_DEAD, L_APP, LOG_ALWAYS, 1 },

In CircleMUD, commands in interpreter.c use level constants:

{ "advance", "advance", POS_DEAD, do_advance, LVL_IMPL, 0 },
{ "at",      "at",      POS_DEAD, do_at,      LVL_IMMORT, 0 },
{ "ban",     "ban",     POS_DEAD, do_ban,     LVL_GRGOD, 0 },

Evennia’s approach is different: commands are Python classes organized into command sets. Admin commands live in evennia.commands.default.admin and building commands in evennia.commands.default.building. Each command class declares its own lock:

class CmdBoot(MuxCommand):
    key = "boot"
    locks = "cmd:perm(boot) or perm(Admin)"

2.2 Admin-Only Channels

Every major codebase provides dedicated communication channels that only immortals can see.

Merc/ROM: immtalk (shortcut :)

The core immortal chat channel. All immortals level 36+ can hear and speak on it.

: Hey, anyone seen suspicious activity from Trogdor?
[Gandalf]: Hey, anyone seen suspicious activity from Trogdor?

ROM: wiznet (shortcut ;)

ROM’s wiznet is more than a chat channel — it’s an information service that broadcasts game events to immortals. You can toggle categories:

wiznet                      — show current wiznet status
wiznet on                   — enable wiznet
wiznet off                  — disable wiznet
wiznet <message>            — send a message on wiznet
; <message>                 — shortcut

Wiznet event categories (toggleable per-immortal):

Each immortal customizes their wiznet to see only relevant events:

wiznet +deaths +logins -ticks

CircleMUD: wiznet (shortcut ;)

CircleMUD’s wiznet operates similarly:

; [@|+|-|#] [text]

• ; message — send to all immortals
• ; @ — toggle wiznet on/off
• ; + / ; - — toggle specific categories

The nowiz command also toggles wiznet visibility.

SMAUG: immtalk

SMAUG uses immtalk like Merc, plus adds specialized channels at higher levels. The wartalk channel exists for deity+ discussions.

Evennia: Channel System

Evennia handles admin channels through its general channel infrastructure:

channel/create staffchat;staff = Staff-only discussion channel

Channels are controlled via three lock types:

• listen: who can subscribe and see messages
• send: who can post
• control: who can manage the channel (boot users, set bans)

Default system channels:

• MudInfo: Server announcements (restarts, errors)
• ConnectInfo: Player connection/disconnection notifications (optional)

Custom admin channels are created with appropriate locks:

lock staffchat = listen:perm(Admin);send:perm(Admin);control:perm(Developer)

2.3 Snooping — Watching Player I/O

Snooping lets an admin see everything a player sees and types in real-time.

Technical implementation (Merc/ROM/CircleMUD):

• Everything sent to the snooped player’s output buffer is also sent to the snooper, prefixed with %
• Everything the snooped player types is also shown to the snooper
• Only one snoop target at a time per admin
• Higher-level immortals can snoop lower-level ones; you cannot snoop someone of equal or higher level
• Snooping is typically logged (ROM’s wiznet reports it under the snoops flag)

Ethical frameworks vary by MUD:

• Restrictive model: Some MUDs implement a snoopable flag that players control. Default is off. Admins can override but must file a report justifying why.
• Open model: Admins can snoop freely but are expected to treat observed private communications (tells, etc.) as confidential.
• Policy model: Most MUDs state snoop should only be used “for disciplinary purposes” when cheating or illegal behavior is suspected. Admins who abuse snoop face demotion.

Evennia: No built-in snoop command. Can be implemented as a custom command that intercepts the msg() method on the target, forwarding output to the snooper. The lock system provides the access control framework.

2.4 Player Monitoring and Statistics

Beyond snooping, admins have several passive monitoring tools:

2.5 How Evennia Handles Admin Interfaces — The Django Admin Panel

Evennia is unique among MUD engines in providing a web-based admin interface alongside the traditional in-game commands.

Access: http://localhost:4001/admin (default), or the “Admin” link in the web client header.

Capabilities:

• Browse, search, create, edit, and delete all database objects (rooms, characters, exits, scripts, accounts)
• View and modify Attributes and Tags on any object
• Manage account permissions and staff status
• Link accounts to characters (especially important in MULTISESSION_MODE 0/1)
• View connection history and session data
• Create rooms, exits, and set descriptions through form fields

Access control:

• Requires Staff status flag on the Account
• Only Superusers can grant staff status
• The Django admin permission system is separate from in-game permissions (Builder, Admin, Developer)

Relationship to in-game commands: Almost everything possible through the web admin can also be done with in-game commands. The web admin is an alternative interface, not a replacement. It’s particularly useful for:

• Bulk operations (editing many objects at once)
• Non-technical staff who prefer GUIs
• Remote administration without a MUD client
• Debugging (direct database inspection)

Backend code lives in evennia/web/admin/ with admin classes like ObjectAdmin, AccountAdmin, etc. The admin site configuration is in evennia/web/utils/adminsite.py.

2.6 How Modern Engines Separate Admin from Player UIs

The general trend: modern engines provide both in-game and out-of-game admin interfaces, while traditional codebases rely entirely on the in-game command line.

3. Trust Levels and Permission Systems

3.1 Merc/ROM Trust System

ROM (and its ancestor Merc) uses a numeric level system where immortal levels start above the mortal maximum and each level unlocks additional commands.

Merc level structure (stock):

ROM additions (levels 52-60):

The trust command: ROM’s most elegant admin tool. It lets you grant a player command access at a specific level without changing their actual level. A level 52 Angel given trust 57 can use God-level commands without gaining God-level combat stats or being listed as a God. Trust of 0 resets to natural level.

3.2 SMAUG Level Hierarchy

SMAUG extends the Merc hierarchy to 65 levels with a much more granular immortal tier:

Each level gates specific commands. The first immortal is created by editing a player file directly (changing the Level field to 65) or using the included “Admin” pfile (password: admin).

SMAUG also adds per-command level gating: admins can restrict which immortal levels can use which commands, and the bestowarea command grants building rights to specific areas without granting broader powers.

3.3 CircleMUD Privilege Levels

CircleMUD uses four immortal tiers defined as constants in structs.h:

Key design principles:

• The first character to log in to a fresh MUD is automatically made LVL_IMPL
• All other immortals are created via advance from the implementor
• The level constants can be adjusted by modifying structs.h and recompiling, allowing MUDs to add more granular tiers
• Commands are gated by setting the minimum level in the cmd_info[] array in interpreter.c
• Auto-generated wizlist and immlist files are maintained by the autowiz utility

CircleMUD’s set command is particularly powerful — it can modify almost any player attribute:

set <player> level 31          — change level
set <player> gold 10000        — set gold
set <player> str 18            — set strength
set <player> title the Mighty  — set title
set file <player> ...          — modify offline players

3.4 Evennia’s Permission and Lock System

Evennia replaces numeric levels with a string-based permission hierarchy combined with a flexible lock system. This is the most modern and granular approach among the engines covered here.

Permission Hierarchy

Six default levels (from lowest to highest):

Hierarchy is automatic: having Admin permission automatically passes any lock checking for Builder, Helper, or Player.

Assignment:

perm/account Tommy = Builder     — grant Builder permission
perm/account/del Tommy = Builder — revoke it
perm *Tommy = Builder            — asterisk syntax for accounts

The perm command is Developer-level and cannot be used to escalate beyond your own level.

The Lock System

Locks are the real power of Evennia’s access control. Every entity (objects, commands, scripts, accounts, channels) can have locks that define who can interact with it and how.

Lock string syntax:

access_type: [NOT] lockfunc1([args]) [AND|OR] [NOT] lockfunc2([args])

Multiple access types are separated by semicolons:

delete:id(34); edit:all(); get:not attr(very_weak) or perm(Admin)

Common access types:

Built-in lock functions:

In code:

# Checking access
if not obj.access(caller, 'delete'):
    caller.msg("You can't delete that.")

# Setting locks
obj.locks.add("get:attr_gt(strength, 50)")
obj.locks.add("control:id(34); examine:perm(Builders)")

# Arbitrary lock checks
if not caller.locks.check_lockstring(caller, "dummy:perm(Admin)"):
    caller.msg("Admin access required.")

Quelling

The quell command lets staff temporarily drop to their character’s permission level, useful for testing what players experience. Superusers can use this to test whether locks are working correctly.

Per-Command Access Control

Every Evennia command class defines its own lock:

class CmdBan(MuxCommand):
    key = "ban"
    locks = "cmd:perm(ban) or perm(Developer)"
    help_category = "Admin"

This means access control is per-command rather than per-level, and custom permissions can be created for fine-grained control:

# A custom command only for guild leaders
class CmdGuildPromote(MuxCommand):
    key = "guildpromote"
    locks = "cmd:tag(guild_leader, roles)"

3.5 Builder vs Admin vs Implementor — Access Patterns

The distinction between builder, admin, and implementor access is consistent across codebases despite different implementation details:

Key distinction in ROM/Merc: The trust command allows precise access control without level promotion. A builder trusted to level 39 can use God commands without being a God. This is more flexible than CircleMUD’s rigid four-tier system but less granular than Evennia’s per-command locks.

Key distinction in Evennia: The Superuser flag bypasses all locks entirely. This is separate from the Developer permission. Superusers can’t properly test locks because they always pass — hence the quell command.

Sources

• CircleMUD Wizard Commands (wizhelp.txt)
• CircleMUD Administrator’s Manual
• Merc MUD help.are (command reference)
• ROM 2.4 QuickMUD help (rom.are)
• ROM 2.4 OLC help (olc.hlp)
• SMAUG Documentation (SMAUGDOC.txt)
• SMAUG Level Hierarchy (forum)
• SMAUG GitHub Repository
• SmaugMuds Forum — First Immortal
• Evennia — Permissions
• Evennia — Locks
• Evennia — Channels
• Evennia — Web Admin
• Evennia — Admin Commands API
• Evennia — Building Commands API
• Evennia — Building Quickstart
• DikuMUD Wiki — Wizarding 101
• MUD Wiki — Online Creation
• SWmud Snooping Rules
• LIMA Mudlib Privacy Docs
• CircleMUD Adding Levels WTFAQ