Command Dispatch
Command Dispatch
When you type a command or an object runs one from the queue, the server must decide what to do with it. This decision follows a strict priority order. Understanding this order explains why some commands take priority over others and how $-commands are found.
The Dispatch Chain
The server processes each command through the following steps, in order. The first match wins—once a step matches, later steps are not tried.
1. Prefix Commands
The first character is checked against a set of single-character shortcuts:
| Prefix | Command |
|---|---|
" | say |
: | pose |
; | pose/nospace |
\ | @emit |
# | force puppet (e.g., #1234 command) |
& | set attribute (e.g., &FOO me=bar) |
TinyMUX also recognizes the Unicode left double quotation mark (U+201C) as equivalent to ", so clients that auto-correct quotes don’t break the say command.
2. Talk Mode
If the player has TALKMODE enabled and the input came from the keyboard (not from a queued command), the server routes unrecognized input to the say command. Lines beginning with . bypass talk mode and proceed to normal matching.
3. Comsystem
The input is checked against the player’s channel aliases. If the player has aliased a channel as pub, typing pub Hello everyone sends a message to that channel.
4. Home
The literal command home is matched. If the player has a valid home location, they are sent there.
5. Exit Matching
The command is matched against exit names in the player’s current room, including:
- Exits directly in the room
- Exits in the room’s parent object
- Exits in the zone master object’s parent room
If multiple exits match, one is chosen randomly from those whose locks the player passes. If the player passes no locks, one is chosen randomly and the failure messages are shown.
6. Built-in Commands
The first word of the command is looked up in the server’s internal command table. This is a hash table lookup, so it is fast. If found, the rest of the line is parsed into arguments (splitting on = and / for switches), evaluation is performed on the arguments, and the command is executed.
Command switches (like /silent or /quiet) are parsed at this stage. The server verifies that each switch is valid for the matched command.
7. $-Commands
If no built-in command matched, the evaluated command string is tested against user-defined $-commands on attributes. The search order is:
- The executor itself
- Objects in the executor’s location (the room’s contents)
- The location (the room itself)
- Objects in the executor’s inventory
- The zone master object of the executor’s location
- The zone master object of the executor
- Objects in the master room (#0)
- The master room itself
All matching $-commands are executed. Unlike exits, where only one match is used, every matching $-command fires. This means if two objects in the room both have $+who:@pemit %#=..., both will run.
The NO_COMMAND flag on an object excludes it from $-command matching, which is a useful optimization for objects that have many attributes but no commands.
8. Huh?
If nothing matched at any step, the server returns the “Huh?” message (configurable). The HUH_COMMAND hook, if defined, can intercept this for custom handling.
Evaluation Timing
A critical design point: built-in commands receive their arguments before evaluation and perform evaluation themselves (or not, depending on the command). But $-commands are matched against the already-evaluated command string.
This means:
think [name(me)] -- 'think' gets '[name(me)]', evaluates it
$+greet *:... -- matched against the evaluated output
Commands like @wait, @switch, and @trigger deliberately do not evaluate their arguments, deferring evaluation to when the queued command runs. This is a security feature.
Command Hooks
TinyMUX supports hooks that run before, after, or instead of built-in commands:
- before - runs before the built-in command
- after - runs after the built-in command
- ignore - replaces the built-in command entirely
- permit - gate that must pass for the command to execute
- afail - runs if the permit hook fails
Hooks are set with @hook and are a powerful tool for customizing server behavior without modifying source code.
Related Topics: Command Evaluation, $-Commands, Arbitrary Commands, Expression Evaluation.