- @zemit <zone>=<message>
Emits a message to all rooms in <zone>. You must have control in that zone in order to use this command. Because it is computationally expensive, it costs 100 pennies.
Emits a message to all rooms in <zone>. You must have control in that zone in order to use this command. Because it is computationally expensive, it costs 100 pennies.
These attributes set the message shown to a player who enters a room in a new zone (@zenter), the message shown to others in the room in the new zone when the player enters (@ozenter), and the action triggered by the entry (@azenter).
Entry into a new zone is said to occur when a player goes from a room not in the zone to a room in the zone. "Room" in this context means the player's absolute room (outermost container), so entering and leaving unzoned objects within a zoned room doesn't trigger these.
Zone entry is assumed to occur before room entry, so these are triggered before the room's @[oa]enter.
These attributes set the message shown to a player who leaves a room in a zone (@zleave), the message shown to others in the room in the old zone when the player leaves (@ozleave), and the action triggered by the leave-taking (@azleave).
Leaving a zone is said to occur when a player goes from a room in the zone to a room not in the zone. "Room" in this context means the player's absolute room (outermost container), so entering and leaving unzoned objects within a zoned room doesn't trigger these.
Zone leaving is assumed to occur after room leaving, so these are triggered after the room's @[oa]leave.
Flag: Z_TEL (things, rooms)
The Z_TEL flag, when set on a zoned room or on the ZMO of a room, prevents objects in the room from being @teleported out of the zone - that is, objects can only be @teleported to a room which is zoned to the same ZMO. Setting this flag on the ZMO affects all rooms zoned to it. Like NO_TEL, the "home" command will still work. This flag is intended for use in puzzle rooms and IC areas.
See also:
Sends a message to everything zoned to <zone>, as per @zemit. Costs apply.
nszemit() is a wizard-only variation that works like @nszemit.
This is essentially identical to UFUN(), but the attribute corresponding to the user function name is read from the ZMO of the object instead of from the object itself. In order to read the attribute from the ZMO, one of the following criteria must be met:
1. The object is set WIZARD or ROYALTY. 2. The object controls the ZMO. 3. The object's owner owns the attribute on the ZMO. 4. The ZMO is set VISUAL. 5. The attribute being checked is set VISUAL.
See 'help UFUN()' for more details on user-defined functions.
This returns a list of the dbref numbers for all current-connected, non-hidden players within a location belonging to the specified zone. It's exactly the same as zwho() used by a mortal, and is suitable for use on privileged global objects who need an unprivileged zwho-list. The viewer must either have see_all privileges or pass the zone lock of the zone to use the function.
See also:
Zone master rooms are a subset of zones. If a room is used as a zone master, it is a zone master room (ZMR). ZMRs are like local "master" rooms. Exits in the ZMR are global to that zone, and $commands on objects in the ZMR are global to that zone ($commands on the ZMR itself, like $commands on the master room, are ignored). If a ZMR is a player's personal zone, objects in the ZMR are checked for commands that the player can use anywhere (but exits are not checked unless the player is in a zoned room).
Zone master rooms are only defined if globals are used. Zone master rooms are best used for very large zones which have a lot of global exits, or for zones with restricted commands that can go on a separate use-locked object from general ones.
See also:
SHARED PLAYERS
Shared players are player objects which are used to mediate shared control of objects. A shared player is an object of type PLAYER which has the SHARED flag set. They are created like ordinary players, and can connect, build, etc. The only difference is that objects owned by a shared player are controlled by anything that passes the @lock/zone of the shared player.
Anyone who passes the @lock/zone of the shared player can @chown objects to it. This, however, does not refund the original creator's money or quota, as does normal.
Shared players used to be known as Zone Masters. The term was changed to emphasize the fact that they are not related to zone master objects, which are used to affect search order for user-defined commands.
Continued in HELP SHARED PLAYERS2
Returns the object's 'zone'. This is the dbref of the master object which defines the zone. If the second argument is specified, the function tries to change the zone on the object before reporting it.
See also:
Zones are areas of the MUSH that can have the same user-defined commands without having to @parent every object in the zone or make the commands mush-wide globals.
The default zone is NOTHING. Any building done by a player defaults to belonging to the same zone that the player belongs to. Every zone is defined by a Zone Master Object (ZMO). The ZMO is an ordinary MUSH object owned by some player. A wizard may change the zone of an object or player to a ZMO.
If the ZMO is a room, it is called a "zone master room." Most of the statements about ZMOs also apply to zone master rooms; for details, see the help topic ZONE MASTER ROOMS.
See "help ZONES2" for more.
$commands on a ZMO are treated as global within that zone. The game attempts to match $commands for the ZMO of the player's location, as well as $commands for the player's own zone.
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. If you want players to be able to use special commands for a culture they belong to, the $commands should go on the ZMO, and the players @chzoned to it so they can use the commands anywhere.
See also:
This returns a list of the dbref numbers for all currently-connected players within a location belonging to the specified zone. When mortals use this function, the dbref numbers of DARK wizards or hidden royalty do NOT appear on the dbref list. The viewer must either have see_all privileges or pass the zone lock of the zone to use the function.
If <viewer> is given by a privileged user, zwho() returns a dbref list using <viewer>'s privileges.
See also:
Generated at Mon Jul 2 00:35:04 2007