Guides

Immortals with open-source tools

This guide outlines the technical and procedural implementation of an Immortal hierarchy for a MUD. It focuses on command access control, accountability logging, and the progression from helper to implementor to ensure server stability and community trust.

4-6 hours for initial setup and policy documentation5 steps
Immortals with open-source tools hero illustration
1

Define Command Level Mapping

Modify the command table in your source (e.g., interpreter.c or commands.py) to assign minimum trust levels to every staff command. Ensure that game-breaking commands like 'shutdown', 'set', and 'advance' are restricted to the highest tier (Implementor), while utility commands like 'goto' or 'stat' are available to mid-level staff.

interpreter.c
struct command_info cmd_info[] = {
  { "set",      POS_DEAD,    LVL_IMPL,  0 },
  { "stat",     POS_DEAD,    LVL_BUILDER, 0 },
  { "wizinvis", POS_DEAD,    LVL_HELPER, 0 },
  { "peace",    POS_DEAD,    LVL_ADMIN, 0 },
  { "\n", 0, 0, 0 } 
};

⚠ Common Pitfalls

  • •Assigning 'force' commands to low-level staff, allowing them to make players drop items or delete themselves.
  • •Hardcoding levels instead of using defined constants like LVL_IMMORT.
2

Implement Mandatory Immortal Logging

Every command issued by an Immortal must be logged to a separate 'wizlog' file. This log must include the timestamp, the immortal's name, the command used, and the full argument string. This is the primary tool for auditing staff behavior and resolving player complaints.

logger.py
def log_immortal_action(actor, command, args):
    with open("logs/immortal.log", "a") as f:
        f.write(f"[{datetime.now()}] {actor.name}: {command} {args}\n")

# Call this in the command interpreter for all players > LVL_MORTAL

⚠ Common Pitfalls

  • •Logging only the command but not the arguments, making it impossible to see what values were changed.
  • •Storing logs in a world-readable directory.
3

Configure Staff Sandbox VNUM Ranges

Prevent junior builders from accidentally overwriting established zones by assigning strict VNUM (Virtual Number) ranges in the zone header files. New builders should be restricted to a 'Sandbox' range (e.g., 90000-91000) where they can practice room and mob creation without affecting the live game world.

⚠ Common Pitfalls

  • •Failing to lock zone files, allowing two builders to edit the same VNUM simultaneously.
  • •Granting 'load' permissions to builders in live zones.
4

Establish WIZINVIS and Staff Alt Protocols

Implement a 'WIZINVIS' (Wizard Invisibility) command that hides staff from the 'who' list and 'look' command. Establish a strict policy that staff must be WIZINVIS when performing administrative duties. Furthermore, create a 'staff-alt' flag in the player database to track mortal characters owned by staff members to prevent resource funneling.

schema_update.sql
ALTER TABLE players ADD COLUMN staff_owner_id INT DEFAULT NULL;
-- Link mortal alts to the immortal's primary account ID for auditing.

⚠ Common Pitfalls

  • •Allowing staff to use administrative commands (like 'stat') while logged into their mortal alt characters.
  • •Neglecting to hide immortal entry/exit messages in rooms.
5

Deploy an Immortal-Only Communication Channel

Create a dedicated 'imm-talk' or 'wiznet' channel. This channel should automatically broadcast system alerts, such as new player logins, player deaths, and potential security triggers (e.g., rapid gold gain or multiple failed password attempts).

comm.c
void wiznet(char *string, struct char_data *ch, int type) {
  for (d = descriptor_list; d; d = d->next) {
    if (STATE(d) == CON_PLAYING && GET_LEVEL(d->character) >= LVL_IMMORT) {
      send_to_char(d->character, "[WIZNET]: %s\r\n", string);
    }
  }
}

⚠ Common Pitfalls

  • •Leaking sensitive player information (like passwords or IP addresses) over the wiznet channel.
  • •Failing to allow staff to toggle the channel off, leading to 'scroll-blindness' during events.

What you built

An effective Immortal system balances power with accountability. By hard-coding command restrictions, automating logs, and siloing builder activities, you create a professional environment that minimizes staff burnout and eliminates the appearance of favoritism.