Builder:Zone
From Wormhole Sci-Fi MUD Homepage
The .zon file tells the mud where everything goes, from the goblin in the pit to what the knight is wielding and putting the fountain in the square. It also controls how and when the area is reset.
Contents |
Header
There are two main parts to every .zon file: the header information, and a list of commands to be followed out by the mud. Here is a header of a zone file for an example, followed by a line by line explanation:
#22 Example Area~ 2299 20 2 Artoo
Please note the example above is only the header of the file. The examples of Zone commands will follow this explanation of the header...
- #22
This is the zone number of the area. The mud doesn't actually care what number goes here, but Q does!
- Example Area~
The name of the area.
- 2299 20 2 Artoo
The first number is the 'top' or 'last' number of the zone -- the vnum of the final room of the area. The second number is the number of ticks between resets of the area. 20-30 is usually a good number. The third number controls how the zone is reset: a 0 is no-reset, a 1 is reset whenever there are no players are in the area, and a 2 is reset when the reset time has elapsed, no matter who or what is inside. Anything after this is interpreted as bing the author's name, and is seen when an immortal types SHOW ZONES.
Zone Commands
The zone commands tell the mud exactly how to reset a zone, from mobs to objects, to closing doors. Each command is given its own line, one after the other, until the end of the file. Comments can be added for clarity's sake (like this: big guy with sword).
Standard Fields
- <if-flag>
An if flag tells the mud to look at the previous command. If the if-flag is 0, the mud will try to execute the command regardless of the previous command. If the if-flag is any other than a zero (one is most commonly used), then that particular command will only execute if the command immediately preceding it did as well.
This is useful for objects loaded onto mobs; you don't want to load a shield on a guard that didn't get loaded, for example. There are several other uses as well, that should become apparent as you build...
- <max #>
This is the maximum number of whatever this is can exist in the mud. If on a mob command, this will prevent excess mobs being loaded into an area. On an object command, this limits how many of this object are available in the game. For items not limited, it is common to put a very high number in this slot...from 100 to 1000.
The 'M' Command
The 'M' zone command loads a mobiles to a certain place in the mud.
The format is:
M <if-flag> <mob vnum> <max #> <room vnum> <percentage chance of placement>
The 'O' Command
The 'O 'zone command loads an object into a room. This is mostly used for unowned or immovable objects (like a stick on the ground or a fountain).
O <if-flag> <object vnum> <max #> <room vnum> <percentage chance of placement>
The 'G' Command
The 'G' zone command loads an object and gives it to a mobile loaded in the command immediately previous. Note that this is different from the 'E' command below, in that the 'E' command loads an object and makes the mob equip it. A 'G' command object stays in the mob's inventory.
G <if-flag> <object vnum> <max #> <percentage chance of placement>
The 'E' Command
The 'E' zone command loads an object and makes the mob loaded in the command immediately previous to this one equip it.
E <if-flag> <object vnum> <max #><equipment position> <percentage chance of placement>
Where equipment position is one of the following:
- 0 -- Light
- 1 -- Right Finger
- 2 -- Left Finger
- 3 -- Neck (first slot)
- 4 -- Neck (second slot)
- 5 -- Body
- 6 -- Head
- 7 -- Legs
- 8 -- Feet
- 9 -- Hands
- 10 -- Arms
- 11 -- Shield
- 12 -- About Body
- 13 -- Waist
- 14 -- Right Wrist
- 15 -- Left Wrist
- 16 -- Wield
- 17 -- Hold
- 18 -- Worn as a badge
- 19 -- Mounted on (use for vehicle type items)
There'll be some additions here soon, so ask Q to keep you up to date :)
The 'P' Command
The 'P' command loads an object, and places it into another object (container-type) that was previously loaded.
P <if-flag> <loaded object vnum> <max #> <container vnum> <percentage chance of placement>
The 'D' Command
The 'D' command can open, close, or close and lock a door.
D <if-flag> <room vnum> <exit #> <doorstate>
Where exit # is the number equivalent of the exit as so:
- 0 -- north
- 1 -- east
- 2 -- south
- 3 -- west
- 4 -- up
- 5 -- down
And Door state is:
- 0 -- Open
- 1 -- Closed
- 2 -- Closed and Locked
The 'X' Command
The 'X' Command is used to remove an object from a room.
X <if bit> <room virtual number> <vnum of object to zap> everything after this ignored
Use remove to 'freshen up' the contents of a container. For example, to put the keycard on the corpse in the Tessier building back each time the zone repops. If you don't remove the container before you replace it, you can't put anything inside it, since 'P' commands must follow IMMEDIATELY after the 'O', 'G' or 'E' command that loads a container.
Players don't see anything to suggest that the target has been removed. It's instantaneous and impossible to detect... assuming the object's removal is followed by a reload, and the max# in game permits it to load.
The 'W' Command
The 'W' Command is used to place starships. It works somewhat like the one to load mobiles, in that it's possible to load several ships with the same vnum into a room. This means that you have to think carefully about the max # that you'll allow in the game, of course! For this reason, you should never use a 'W' command to load somebody else's ship into your zone.
The 'W' command is not supported by OLC, but as of 10/9/2006, changing a .zon file via OLC no longer wipes out any ship loading instructions in that file. Phew!
W <if-flag> <starship vnum> <max #> <room vnum> <percentage chance>
Note: Ships load in a 'landed' condition if the room where you load them has a 'port' flag. They load 'in-flight' in other rooms. Landed ships require a TAKEOFF instruction from the player or mobile flying the ship before they can move. (Although it isn't actually a starport, the room where the jawa sandcrawler appears is set as 'port' because a flying sandcrawler would be bizarre.)
Zone Archetype
#<zone #> name of area~ <last room in area> <reset time> <reset type> <Author's name> <zone commands, each on a separate line> S $~
Tips and Observations
- To be certain that a zone can be navigated, you might open all doors at the top of the file, then lock them the line after the key is loaded with an if the key was loaded, then lock the door. Making the 'max # allowed in game' for key loads higher than one is another useful trick, since keys held by a mobile don't rot when the zone repops. A scavenger might have picked up the key and spirited it away.
- Remember, a functioning door is a door from both sides, and needs to be closed from both sides. Thus, 2 door commands for each door.
- Use the remove command (X) just before you load a container if you want to freshen things up. For example, to put some treasure back in a chest. Otherwise, unless the container can be taken away or junked, the contents are effectively 'reboot equipment'.
- There is actually no such thing as 'reboot equipment'; it's a player myth... but there are items with a very low max # in game. If those same items exist in a donation room, a house or a player's inventory, they might stop the item from being loaded - until the next reboot.
- The 'P' command gets confused if you try to load multiple objects into multiple containers IF the containers are all the same object. The solution is to copy the container over into the .obj file with a different vnum however many different containers you need.
- Comment your zone files as much as possible. Doing this makes it much easier to debug your zone file if there happens to be an error in it. See the appendicies for examples. Use a * character to show comments It's not necessary, but helps readability.
- Set the zone repop interval to something different. Too many wormhole zones have a repop interval of 30, which means they all refresh at once. That's boring for players who have cleaned out everything, and could theoretically cause a burst of lag every 30 ticks.
