MUSH / MUX with open-source tools
This guide outlines the technical implementation of a Global Command Object (GCO) on MUSH/MUX servers. A GCO centralizes custom softcode commands (e.g., +who, +help, +sheet) so they are accessible to all players regardless of their location in the game world, without cluttering the player object's own attributes.
Establish a Secure Master Room
Create a dedicated room to house your global objects. This room should be inaccessible to players to prevent accidental interaction or 'examine' attempts that could leak sensitive code logic.
@create Master Control Room
@lock Master Control Room==me
@set Master Control Room=SAFE⚠ Common Pitfalls
- •Leaving the room unlinked or without a lock, allowing players to find it via 'teleport' or 'home' commands.
- •Using a low DBref number that might be overwritten during database imports.
Initialize the Global Command Object
Create the physical object that will hold your $-commands. This object acts as the container for your softcode functions.
@create Global Parent Object
@moveto Global Parent Object=#<Master_Room_DBref>
@set Global Parent Object=SAFE
@set Global Parent Object=INHERIT⚠ Common Pitfalls
- •Forgetting the INHERIT flag, which prevents the object from executing commands with the permissions of its owner (Wizard).
- •Neglecting the SAFE flag, making the object vulnerable to accidental '@destroy' commands.
Define Engine-Specific Master Room Configuration
You must tell the MUSH engine which room contains the global commands. This usually requires editing the server configuration file or setting a specific attribute on object #0 (The Base Room).
# For PennMUSH (in pennmush.conf):
master_room #<DBref>
# For TinyMUX/RhostMUSH (via command line):
@config/set master_room=#<DBref>⚠ Common Pitfalls
- •Setting the master_room to a player's DBref instead of a room DBref.
- •Failing to restart or '@readconf' the server after editing physical config files.
Implement a Standard Global Command
Add a $-command to the Global Parent Object. The syntax '$+command:*' tells the engine to trigger the code when a player types the matching string.
&CMD_WHO Global Parent Object=$+who: @pemit %#=[center( Current Players ,78,=)]%r[iter(lwho(),name(##),, %b)]%r[repeat(=,78)]⚠ Common Pitfalls
- •Missing the colon (:) between the command trigger and the action code.
- •Using attribute names that conflict with built-in engine commands (e.g., naming an attribute 'WHO' instead of 'CMD_WHO').
Set Permissions and Visual Flags
Ensure the object is set to 'VISUAL' so that non-privileged players can trigger the $-commands, and verify the 'HALT' status is clear.
@set Global Parent Object=VISUAL
@halt Global Parent Object⚠ Common Pitfalls
- •If the object is not VISUAL, players may receive a 'Permission Denied' error when trying to use custom commands.
- •If the object was created by a non-Wizard and then @chowned, it might still have restrictive flags inherited from the previous owner.
Verify Global Propagation
Move a test player (non-Wizard) to a completely different area of the map and attempt to use the '+who' command. This confirms the master_room logic is correctly scanning the Global Parent Object.
⚠ Common Pitfalls
- •Testing only with a Wizard character; Wizards often bypass permission checks, masking configuration errors.
- •Assuming global commands work in 'dark' rooms or rooms with 'no_command' flags without explicit testing.
What you built
The Global Command Object is now the backbone of your MUSH's custom UI. By centralizing commands here, you can update game-wide systems in one location. Ensure you regularly back up the attributes on this object using '@decompile' to prevent loss of custom softcode during server migrations.
.