Zones

Topics

Zones allow delegated administration of areas and groups of objects without granting full wizard privileges. They provide group ownership, localized commands, and shared exits across sets of rooms. Every object in TinyMUX has a zone field that defaults to NOTHING.

Zone Master Objects (ZMOs)

A Zone Master Object is an ordinary THING that defines a zone. Other objects are assigned to the zone with @chzone. Anyone who can pass the ZMO’s Enter lock (@elock) gains control over all objects in that zone, effectively granting wizard-level power within the zone’s scope.

Because the Enter lock governs zone control, it must be set carefully. A ZMO with no Enter lock set will deny zone control to everyone (the server requires the lock attribute to exist before testing it).

@create Zone Master - Market District
@elock Zone Master - Market District=Builder1 Builder2

A wizard then assigns objects and players to the zone:

@chzone Market Stall=#123
@chzone Builder1=#123

Zone Master Rooms (ZMRs) / Parent Rooms

When a room is used as a zone object, it becomes a Zone Master Room, also called a parent room. ZMRs provide two features that ZMOs do not:

Shared exits: Exits created inside the ZMR are available from every room zoned to it. This is useful for common directional exits across a large area.
Local global commands: Objects placed inside the ZMR have their $-commands available to anyone in a room zoned to that ZMR.

Only rooms may be zoned to other rooms. Players and things cannot be @chzone’d to a room.

ZMRs are slower to evaluate than ZMOs because the server must search the room’s contents for command matches. For zones that do not need shared exits, a ZMO is preferred.

How @chzone Works

@chzone <object>=<zone object>
@chzone <object>=none

Assigning a zone strips privileged flags (WIZARD, ROYALTY, INHERIT, STAFF, and others listed in stripped_flags) and wipes powers from non-player objects. This prevents smuggling elevated privileges into a zone.

Permission rules:

Any player may reset the zone of an object they own to NOTHING.
A player may set the zone of their own object to a zone object they own.
Only wizards may @chzone an object to a zone object owned by someone else.
Only wizards may @chzone players (except a player may zone themselves to an object they own).
Changing a player’s zone does not retroactively change zones on objects that player already owns.

Zone-Based Command Matching

When a player types a command, TinyMUX searches for $-command matches in this order:

The player object and its parents.
Objects in the player’s inventory.
Objects in the player’s location and the location’s parents.
Zone of the player’s location – if the location’s zone is a room (ZMR), its exits are checked and then $-commands on objects inside it are searched. If the location’s zone is a thing (ZMO), its $-command attributes are matched directly.
The player’s personal zone – if it differs from the location’s zone and no match was found yet, $-commands on the player’s own ZMO are tried.
The master room.

This order means zone commands take priority over global commands in the master room but yield to commands on the player, their inventory, and their location.

Zone-Based Exit Matching

When a player’s location is zoned to a room (ZMR), exits in the ZMR act as if they exist in every room zoned to it. If a local exit and a ZMR exit share the same name, the local exit takes priority.

Zone Locks and Control

Zone control is determined by the Enter lock on the ZMO. The function check_zone_handler in the server tests whether a player passes the Enter lock of the zone object associated with the target. If the zone object has no @elock attribute set at all, control is denied—this is a safety measure so that a newly created ZMO does not accidentally grant control to everyone.

Zone Recursion and Nesting

Zones can be nested: a ZMO can itself be zoned to another ZMO. When determining zone control, the server walks up the chain of zone references, checking the Enter lock at each level. This traversal is bounded by the zone_recursion_limit configuration option (default: 20) to prevent infinite loops. If an object’s zone points to itself, the recursion stops.

Nesting is useful for hierarchical administration. For example, a city zone can contain district sub-zones, each with their own local administrators, while a city-wide administrator passes the Enter lock on the top-level ZMO.

Practical Examples

Collaborative Building Area

Create a ZMO and grant control to a building team:

@create Haunted Forest ZMO
@elock Haunted Forest ZMO=Alice|Bob|Carol

A wizard assigns all rooms and objects in the forest to this zone. Now Alice, Bob, and Carol can modify any object in the zone without owning it.

Faction System with Local Commands

Create a ZMO with faction-specific commands:

@create Thieves Guild ZMO
&CMD_STEAL Thieves Guild ZMO=$steal *:@pemit %#=You attempt to steal from %0.
@elock Thieves Guild ZMO=FactionLeader

Any player or room zoned to this ZMO gains access to the steal command. The faction leader can modify all objects in the zone.

Shared Exits Across an Area

Create a ZMR for a dungeon where every room should have a “flee” exit:

@dig Zone Master Room for Dungeon
@open flee=Safe Room

Zone each dungeon room to the ZMR. The “flee” exit is now available in every zoned room without duplicating it.

Function	Description
`zone(<object>)`	Returns the dbref of the object’s zone.
`zfun(<attr>, <args>)`	Evaluates an attribute on the executor’s ZMO with arguments. Accepts `<obj>/<attr>` to use another object’s zone.
`zchildren(<object>)`	Returns all objects (players, rooms, things, exits) in the zone.
`zrooms(<object>)`	Returns rooms in the zone (equivalent to `inzone()`).
`zthings(<object>)`	Returns things in the zone.
`zwho(<object>)`	Returns players in the zone.
`zexits(<object>)`	Returns exits in the zone.
`inzone(<object>)`	Returns rooms in the zone (equivalent to `zrooms()`).

The z*() family of functions require the executor to own or control the zone object, or to hold wizard or royalty privileges.