ZONES

The following are in alphabetical order and cross-referenced to help explain how a concept in one was carried to the next.

Zones in TinyMUSH 2.2.5

Zones are built on top of @parent. To create a zone, a parent object is set ZONE. It is not possible to have a zone parent and a non-zone parent. There is only one parent.

$-command matching is done on the player's zone and also on the zone of the player's location. The contents of the zone parent is also searched for $-commands.

Zones in TinyMUSH 3.1

TinyMUSH 3.1 merged TinyMUSH 2.2.5 style and TinyMUX 1.6 zoning style which left some overlap and seams.

Zones in TM3 implement the ZMO and PARENT ROOM forms of zoning, but also includes a hybrid mechanism that is also called a local master room. In this case, this local master 'room' isn't actually a room. It's ZMO that has been set ZONE. If the local_master_rooms configuration option is enabled, and the ZMO is set ZONE, the ZMO's contents are also searched for $-commands. In this situation, the player does not need to be located in a zoned room, they are themselves zoned to the ZMO.

Zones in TinyMUX 1.6

Zones in TinyMUX 1.6 are signified with @chzone. This is a @parent-like reference, but it is separate from the object's @parent. Any object can have both zone and a @parent. The default zone is NOTHING. Any building done by a player default to belonging to the same zone the player belong to.

TinyMUX offers two kinds of zoning: Zone Master Object (ZMO) and PARENT ROOM.

ZMO

A ZMO is an ordinary THING object owned by some player. Other objects join this zone by having a wizard @chzone-ing them to the ZMO. Anyone who can pass the Enter @lock of the ZMO has control over all objects in that zone. Notice that it is not necessary join the zone in order to have control over all the objects in it. For this reason, one must be extremely careful with the Enter @locks of ZMOs! It allows a forms of shared ownership. Likewise, $-commands placed on the ZMO are matched whenever something in the zone executes a command. The contents of the ZMO are ignored and can be anything.

PARENT ROOM

A PARENT ROOM uses some of the same plumbing as a ZMO, but the concept is very different. In this case, a set of rooms are @chzoned to a single room. Players and things cannot be @chzone to rooms. TinyMUX calls this parent room a local master room, and indeed, it is something like a mini-master room in that the exits in the parent room are available in all the other rooms, and objects in the mini-master parent room are searched for commands like objects in a master room. A player only need to be located in one of these rooms to have access to the commands in the local master room.

See the help topic PARENT ROOMS, or the topic parent rooms.

Zones in TinyMUX 2.x

Zones in TinyMUX 2.x are the same as what appear in TinyMUX 1.6.

Zones in RhostMUSH

Zones in RhostMUSH are handled quite differently from TinyMUX and TinyMUSH style. In Rhost, a zone is defined by a ZONEMASTER object, which can be an object of either ROOM or THING type. The ZONEMASTER object has special locks that allow control of the zone, granting Wizard-like powers to those that pass its ZoneWizLock, and allowing anyone to add objects that pass its ZoneToLock.

The ZONEMASTER object itself can be manipulated only by its owner and those that pass its TwinkLock. $command matching is done on the ZONEMASTER object for objects and players zoned to it, but any parent(s) to the ZONEMASTER is not searched for $commands. The contents of the ZONEMASTER is also not searched for $commands, unless the ZONECONTENTS flag is also set on the ZONEMASTER.

RhostMUSH's @zone command is used differently as well; objects and rooms are added and deleted using the @zone/add, @zone/del and @zone/purge commands.

Recommended use of zones

Some suggested uses of zones:

1. If you are working on a building project with several people, it may be useful to create a zone object and @elock it to all of you, and ask a wizard to @chzone the players involved to the zone object. That way, all of the players working on the project will be able to modify the building.
2. On a similar thread, if several players are working on a project involving only a few objects, it may be simpler to create a zone object and @chzone those few objects to the ZMO instead of resetting the zones of the players. Note that a player does not have to belong to a zone in order to change objects in that zone; all is merely required to pass the ZMO's enter lock.
3. If local wizards are desired, a zone object may be created and enter locked to the local wizard. Players building within that zone should be @chzone'd to that ZMO. The local wizard will then be able to control anything within that domain.
4. If you want restricted global commands defined over only a small area, you can define that area to be part of a zone, and place the desired $commands upon the ZMO.