Valid XHTML 1.0!

ZeusThe Dirt Game System

A manual for the aspiring world builder

Copyright (C)1993 The Free Software Foundation, Inc 675 Mass Ave, Cambridge, MA 02139, USA

written by Valentin Popescu (

additions/changes/modifications by Vitastjern (

This document is for the Dirt 3.0 game system, modified for Northern Lights.

A zone as used within this document, is a text file written in a special format (a language, if you will). It contains definitions for objects, mobiles, and/or rooms used in the game.

This is intended mostly as a reference manual. Don't be afraid to experiment, and always work on backups.



"...and in the beginning there was nothing."

What exactly is a zone?

A zone, as we said before, is nothing more than a text file. All you need to create one is an editor that writes plain text files, a little spare time, and a lot of imagination.

Assuming you have finished your zone, the following steps should be taken to create your zone:

  1. add a '.zone' ending to your zone's filename. For example, if you created a new zone called 'askani', rename it to ''.

  2. copy your zone to the ../data/ZONE directory

  3. edit the ../data/ZONE/files and add your new zone's ( name there. Each line in the file is one entry. The first word on a line is the zone name as it will be seen in the game, the second one is the file name ( If you simply put in without worrying about the first name, the game will simply name the zone "askani".

  4. rebuild the world. At this point you will be notified of any errors in the file. Major errors will be reported immediately. Minor errors will be placed in a file in the data dir, called mkdata.log. Correct those errors and rebuild the world.

Tips for creating and maintaining your zone

When creating your zone, it is helpful to divide it in three parts, namely objects, mobiles, and locations. When the world is build, a special program will scan the zone file, and look for the following keywords:

      %continent    %mobiles    %objects   %locations

The %continent keyword is unique to Northern Lights and is used to specify which continent the zone belongs to. I will speak more about the %continent keyword in the Setting continents section.

Northern Lights has several keywords that are used for catch purposes. They are called %quest_info, %world_catches, %zone_catches and %globalcode and are used to write specific functions and catches to use inside the zone. This should only be used by coders, so unless you have been told to do so, don't use this keyword. For more information on catches, see The Catch Function System.
Two other keywords used solely for catches are %zone_catches and %world_catches.

What the keywords do, is to tell the program what type of data is following. For example, the outline of a zone file may look like this:

%continent: [the continent the zone belongs to]


[definitions for your mobiles]


[definitions for your objects]


[definitions for your locations (rooms)]

Note: The order of the above fields is important, since the C preprocessor that translates the data to machine readable form will else fail. Sections may however be omitted, but never placed in a different order than stated in the section below.
The accepted order for the sections appears in the zone file is:

    1)  %continent
    2)  %quest_info
    3)  %world_catches
    4)  %zone_catches
    5)  %mobiles
    6)  %objects
    7)  %locations
    8)  %globalcode

Also, you must add the following two lines at the very beginning of a zone file:

#include "undef.h" 
#include "cflags.h" 

They must start at the very begining of the line. They read the definitions of the flags you will be learning about in subsequent pages, and also prevent some headaches you may have later with cpp interaction.

Advanced features

The preprocessor

Remember, zones are run through the C preprocessor when the world is rebuilt. Therefore, you can use C preprocessor features, such as comments using the /* and */ delimiters, macros, etc. If you don't exactly know what that means, don't worry about it.

Just remember; to put a comment inside a zone file, enclose it between /* and */'s. For example:

                     /* this is a comment */

This will have absolutely no effect on the zone. Nothing after a /* will be processed until a */ is found.

If you use #defines, try to use capital letters for your macro name. This is a convention, and also a way to prevent headaches when one of your macro names appears inside a description.

The random function

The random function has been introduced to make it easier to create a certain amount of randomness in the zone. At (almost) every place that you can use an integer for objects and mobiles, you can use the random function instead.

	random(low, high)

Random takes a low value and a high value and creates a randomised value between these.


Damage	= random(7, 12);
The damage will lie between 7 and 12 and change randomly each reset.

Note that if you use negative numbers (for instance on the Counter field for objects), remember that the low value should always be first.

Creating Mobiles

"...or things that go bump in the night."

What is a mobile?

A mobile (or NPC, or whatever you want to call it) is whatever moves on the game and doesn't appear in the 'who' listing.

To start off, remember to preface your mobile data with the %mobiles keyword. This has to be done at least once in the file.

See the Zones section for more info on this.

A typical mobile can be defined by the following fields. Note that many of these are not required.


Name            = dragon
Pname           = "The Baby Dragon"
Location        = limbo@limbo
SFlags          { Female }
MFlags          { NegFireball NoCorpse }
PFlags          { NoAlias }
Strength        = 110
Damage          = 8
Armor           = 2
Aggression      = 0
Speed           = 2
Description     = "
A baby dragon is romping around you, occassionally giving you loving little
nibbles and burning hot slobbery kisses.
Examine         = "It looks expectantly at you and squeaks '&+YMommie?&*'"
End             = dragon

Some explanations are in order here.

Notice the fields Name and End. They are the most important fields in the description. The Name field gives the mobile a name, and also signals that what follows should be assigned to that mobile, until the End field is encountered. The Name and End field should equal the same thing.

The Pname field is the name which will be seen by players. It may be more than one word, but in that case enclose it in quotes. If the Name field is the same as the name you wish the players to see, you don't have to use this field.
Note: The Pname field has a maximum length of 32 characters, including spaces.

Location is the room in which the mobile starts off. This is a text string, which will be explained better in the section describing location definitions.

The Strength is the mobile's strength. An averagely strong mobile will be ca 120 strength, whereas a tough one would be around 300. Default is 10.

The Damage is how much damage a mobile does on a successful hit. Of course, that is altered based on a number of factors, but think of it as the base damage the mobile will usually do. Default is set to 5.

The Armor field acts as invisible armor. A mobile with an armor field of 10 will be like wearing a shield of 10AC. You can use this for mobiles that in their description are described as wearing armor. Default value for armor is 0.

Speed is how fast the mobile moves around. If you want your mobile not to move around at all, set this to 0. The default is 5, this means that unless you specificically set it to 0, your mobile will walk around.

Aggresion is what is the probability that mobile will attack a mortal in the room, on every turn. A turn only takes a few seconds. Mobiles have by default a 0 aggression.

Description is what you see when you enter the room that mobile is in.

Examine is what you see when you examine the mobile.

The remaining fields, SFlags, MFlags, and PFlags are a collection of flag fields. Note that you should not use the = sign on those fields, but rather enclose the needed flags in curly brackets, { and }'s.

The SFlags

The only two sflags you should think about using are the Female and the NoArms sflags. The rest should not be used in a zone file. If you want your mobile to be a male humanoid, just leave this field out altogether.

If you don't know what this means, you are too young...

This mobile/player have no arms, and thus no hands. They will be unable to pick anything up and you can't give them anything. This flag is useful for non-humanoid mobiles.

The PFlags

The PFlags you may use here are:

This mobile may not be exorcised from the game (cannot be kicked off) except by the very highest powers.

This mobile cannot be zapped except by the very highest powers.

You cannot use aggresive magic spells on this mobile.

Lower powers cannot summon this mobile.

This mobile cannot be attacked.

You can't steal from this mobile.

This mobile cannot be aliased.

Or of course, you can leave this field out altogether.

The MFlags

This is the main set of flags for a mobile. You can think of these as MobileFlags.

This mobile may use fireballs during fights.

This mobile may use missile spells during fights.

This mobile may use shock spells during fights.

This mobile may use frost spells during fights.

This mobile might curse you during fights.

This mobile will get stronger if you use the frost spell against it.

This mobile will get stronger if you use the fireball spell against it.

This mobile will get stronger if you use the missile spell against it.

This mobile will get stronger if you use the shock spell against it.

This mobile will not attack you if you are carrying a source of light. Think of the yeti in the blizzard pass.

This mobile may steal stuff you are carrying.

This mobile may steal stuff you are wearing.

This mobile may steal the weapon you are wielding.

This mobile may pit stuff it picks up. See PickStuff.

You may lose your current level if you fight this mobile. This is a more serious version of the DrainScr flag.

You may lose points if you attack this mobile. Think of the Wraith near Shazareth.

You might become paralyzed if you attack this mobile. A mobile with the Immobilize flag will keep you paralyzed a while longer than a Paralyze mobile.

The flags BarNorth, BarSouth, BarWest, BarEast, BarDown, and BarUp will make the mobile hold back mortals trying to go that direction. Think of the figure in the library.

This mobile will quit the game if it is given a food item.

This mobile will attempt to blind you if you attack it.

This mobile will attempt to deafen you if you attack it.

This mobile will attempt to mute you if you attack it.

This mobile will attempt to cripple you if you attack it.

This mobile will not let you pick up stuff in the same room as it is.

Same as NoGrab, but the mobile will also get nasty and attack you if you try to pick up something.

This mobile will pick up stuff it finds while wandering around. It will also wield the best weapon it can find and wear all armor it picks up.

This mobile will leave no corpse if killed.

This mobile will not attack if you are carrying a holy item, such as the cross for instance. Think of the Wraith.

This mobile will taunt you during fights.

This mobile will only move around in OnWater or InWater locations. (Mobiles without this flag will never venture into OnWater or InWater locations.)

This mobile might inject poison if it succeeds to bite you.

Creating Objects

"A rose by any other name..."

What is an object?

An object on mud can be many things. It can be as simple as a banana, or as complex as an invisible mist blocking an exit. This chapter will deal with basic objects. Refer to the "doors" chapter for an analysis of linked objects, such as doors.

A standard object may contain the following fields:

Name            = white_robe 
PName           = robe
AltName         = white
State           = 1 
MaxState        = 1 
Armor           = 10
Damage          = 0
BValue          = 30 
Size            = 5 
Weight          = 4 
Counter         = 0
UnlockText      = "txt1"
OpenText        = "txt2"
CloseText       = "txt3"
LockText        = "txt4"
Location        = IN_ROOM:armory@arcadia 
Desc[0]         = "
A white robe lies in a crumpled heap."
Oflags          { Wearable Armor GetFlips }
Wflags		{ Torso }
Wlayer		= 3
Desc[1]         = " 
A white robe lies folded on the table."
Examine         = " 
It is a white robe with a red rose sewn on it."
End             = white_robe

There are a few other fields that have not been included above, for example the Linked and Key fields. (Note that the Key field can be used for any lockable object, not only doors.) These fields will be discussed in the doors chapter. Also many of these fields are not required.

Once again, the field defined by Name is the object's label. At the end of the description, note the End field, which has the same value as Name.

The AltName field is an alternative name for the object. It may help mortals to pick up the object. For example, a branch may be alternatively called a stick, or a knife may be called a dagger.

The Pname field is how players will refer to the object, although AltName will still be valid. This will be the primary name. If the name defined in Name is the one you wish mortals to use, you need not bother with this field.

Armor is the armor class of the object, if it is wearable. It must have the oflags Wearable and Armor set, for this field to have any effect.

Damage is the damage a weapon may make. It must have the Weapon oflag set for this to have any effect.

BValue is the base value of the object. The actual value is adjusted according to the number of players on the game (the more players, the higher the value.)

Size is used to compute how much space the object will take up in an container, and in the case it is a container, how many objects that can fit in it.

Weight is currently unimplemented.

The Counter entry is mainly used to code special cases. It is also used to as a counter for how long a lit object will burn. Set the counter to about -250 for a good sized torch, and about -125 for a candle. The object will burn until the counter reaches 0, when it will crumble to ashes.

MaxState and State are special flags. Each object has a state asociated with it. Maxstate specifies the maximum state, whereas State specifies the initial state. According to the state of the object, a different description may be seen. For example, if the state of the object is 0, the test defined as Desc[0] will be seen upon entering the room. If state is 1, then Desc[1].. etc.
Note: The maximum value for State and MaxState is 3. Some Oflags will affect the states. These flags will affect the states:
Openable, Lockable, PushToggle, Pushable, Extinguish, Lightable and GetFlips.

The state field isn't just used to show different descriptions. It is also used in some very important aspects for special types of objects to govern how they are used. The table will attempt to explain the different meanings of the states for these objects.

State table for doors, containers, lightsources and getflips
Doors Containers Lightsources GetFlips
0 Open Open Lit After object is taken
1 Closed Closed Unlit Before object is taken
2 Locked Locked Unused Unused
3 Unused Unused Unused Unused

The FoodHeal, FoodMsg, FoodMessage and FoodRoomMessage fields are not listed in the example above, but are explained at the Food Oflag.

The UnlockText, OpenText, CloseText and LockText are used if you wish to specify a special message when you open/close/unlock/lock an object or a door. There is no need to specify all these strings. Any string you don't specify will default to the value NULL and result in a standard message. If the OpenText value is not NULL, while the CloseText value is NULL, but the object does not have the oflag Openable, then players will be able to open the object, but it will not be able to be closed again. The same may be applied to the oflag Lockable. Put generally, setting values other than NULL to the text values will override the flags. This will allow the creation of objects that can be open/closed/locked/unlocked only once.

An example on the usage of LockText

Name      = gate
Pname     = "gate"
Altname   = "padlock"
Location  = IN_ROOM:Somewhere
Oflags    { Openable NoGet }
State     = 1
MaxState  = 2
Linked    = gate2
Desc[0]   = "An iron gate sits here wide open."
Desc[1]   = "
A closed iron gate has a open padlock waiting to be locked"
Desc[2]   = "
The gate is locked tight by an old looking padlock."
LockText  = "You close the gate and snap the padlock closed."
End       = gate

Name      = gate2
Pname     = "gate"
Altname   = "padlock"
Location  = IN_ROOM:Somewhere_else
Oflags    { Openable NoGet }
State     = 1
MaxState  = 2
Linked    = gate
Desc[0]   = "An iron gate sits here wide open."
Desc[1]   = "
A closed iron gate has a open padlock waiting to be locked"
Desc[2]   = "
The gate is locked tight by an old looking padlock."
LockText  = "You close the gate and snap the padlock closed."
End       = gate2

The gate can be opened and closed as much as the players like, once it has been locked though, thats it, locked till the next reset, or a wizard+ opens it of course. If the filed Key = key@church to each of the gates then only someone with the key from the church would be able to lock the gate... It would still remain locked after that though.

The Desc[x] fields are the object descriptions upon entering a room. The current description will be chosen according to the current state of the object. See the previous paragraph, and also the GetFlips and PushToggle flags. Also refer to the appendix, the section on entering string fields. Sometimes it is desirable that the objects have no description. That is fine, just leave the field out. Or you may specify just one field. Or three. The maximum number of states is four, ranging from 0 to 3.

The location, or carryflag, of an object is a bit more complex than it appears. An object can be in one of six states: carried by someone, worn by someone, wielded by someone, both wielded and worn by someone, in a container, or in a room. The way you can specify this is by the use of six different flags. Example:

Location        = CARRIED_BY:puff 
Location        = IN_ROOM:forest 
Location        = WORN_BY:seamas
Location        = WIELDED_BY:cosimo
Location        = BOTH_BY:asmodeus
Location        = IN_CONTAINER:sack

In first example, an object is carried by mobile Puff. In second example, the object is simply in the room labelled "forest". In the third example, it is carried by the mobile Seamas. The fourth example is for a weapon, wielded by the mobile Cosimo. The fifth example is an object that is both wielded and worn by the mobile Asmodeus. In the last example, the object is in the sack.

The Oflags field is a collection of object flags, enclosed in curly brackets, {'s and }'s. Note there is no = sign on this field.

Object Flags and their meanings

The following object flags are acceptable:

This oflag really means 'invisible to mortals'. Indeed, mortals will not be able to see it, nor do anything with it.

This object cannot be taken using the "take" or "get" commands. It should be use for objects that should not be taken, like doors furniture, etc.

Closely related to the NoGet flag, but will allow immortals to handle it as a usual object. No practical use outside the home rooms.

This object can be opened and closed. Note that opening an object toggle its state. The opened state is state 0, and Desc[0] should reflect this. Desc[1] reflects on the object's closed state. The OpenText and CloseText fields can be specified to give the object an customized text for the open and close commands.
Note: Objects can become once-openable/closeable through the use of OpenText/CloseText and no Openable oflag.

This object can be locked and unlocked. Note that it should also be openable. A locked object requires a key to be opened. The locked state is state 2, Desc[2] should reflect this. The LockText and UnlockText fields can be specified to give the object an customized text for the lock and unlock commands. Use the Key field if you wish to make the object openable by one key only.
Note: Objects can become once-lockable/unlockable through the use of LockText/UnlockText and no Lockable oflag.

This object is pushable. The state will change from a state larger than 0 to 0 (once) when it is pushed. It is usually preferrable to have the original state as 1.

This object will toggle the state back and forth between 0 and 1 when pushed. The original state can be larger than 1 if needed.

This object is edible, and will improve stamina (hitpoints) when eaten.

If the Food flag is set on an object, the following extra constructs are available to the zone writer.

FoodHeal is the amount the food will heal a player (mortal only) when the food is eaten. Negative values are allowed, these will harm the player. The value is affected by the blessed and cursed flags, increasing/decreasing this value by 1/3 respectively.

FoodValue = 18

If blessed when eaten this food item will heal 24, if cursed it will heal 12.
Note: the default value for FoodHeal is 12 and you do not need to set a FoodHeal value for 'ordinary' food.

FoodMsg and FoodMessage are aliases for each other. This allows you to specify the string that is sent to the player when eating this object.
The default for this is the default message sent when eating anything. The default message may vary if food is blessed or cursed.

FoodRoomMsg allows you to change the message sent to the room the player is in.
If the string contains a %s it will be replaced with the players name. (Visibility is automatically handled.) You are not allowed to have more than one %s.


FoodHeal = 6
FoodMsg  = "This tart was delicious, but not very filling."
FoodRoomMsg = "%s greedily devours a dainty tart."

This object is armor. The Armor field will be considered during fights. The object must also be set wearable.

This object can be worn by a player. That doesn't mean it is armor. See also the Wflags which define where on the body the object is worn.

Only applicable for wearable objects. This flag makes the WearAll command ignore the object when attempting to wear every wearable item in the inventories. Use this flag if you have created a catch on Wear for your item and don't wish that catch to be bypassed by the WearAll command.

The object can be lit, to provide light. The state will change to 0 when the object is lit.

The object can be extinguished. The object will attempt to change its state to 1 when extinguished.

The object can be used to unlock doors.

This flag will cause the status of the object to be set to 0, when a successful get/take is performed. The reason is as follows.

At times, you may have to have a room, with a table, and on the table a pen described as "A pen is on the table." However, if someone takes the pen, and then drops it in a room with no table, the description will still read "A pen is on the table." Getflips to the rescue!

By setting GetFlips on, and State to 1, you can set Desc[1] to the original description. When someone takes the object, it will be toggled to state 0, so if he drops it again, Desc[0] will be seen.

Or in other words:

           MaxState = 1
	   State    = 1 
	   Oflags   { GetFlips } 
	   Desc[0]  = "A pen has been dropped here." 
	   Desc[1]  = "A pen is on the table." 

The object is providing light. This does not imply it is extinguishable, or re-lightable, nor does it imply that it will change state. Hower, it does imply that the object can be used to light other objects. Lit objects can be extinguished under water.
An object with the Lit and Extinguish flags will burn out after a while if the Counter has a negative value. A branch should have a counter value of approximately -200 to -250, while a branch would have -300 to -350 or so. Candles have slightly lower values.

The object provides light, but can't be used to light other objects. Glowing objects aren't extinguished under water and can't be extinguished by ordinary means. Glowing objects can't be combined with Lit, Extinguish and/or Lightable object flags.

The object is a container. You can put stuff in it, and take stuff out. The amount of objects that can be put in the container is depending of its size.
If the container has the Openable and Locable flags, state 0 refers to open, state 1 to closed and state 2 to locked, precicely as with doors.

The object is a weapon. The Weapon field will be taken in consideration during fights.

This flag is meant for wizard-weapons. Mortals will recieve next to no damage when using this weapon if they are past the newbie stage. The object must have the Weapon flag set.

The object is a boat. It will allow mortals to travel over OnWater rooms.

The meaning of this flag is a bit obscure, and left to the interpretation of the programmer. For example, if the flags Boat and Broken are set, the boat would sink at sea.

This object cannot be located using the where/locate spells.

This object cannot be summoned.
If a player has a active nosummon object and attempts to use a teleport item, the summon is cancelled.

This object will make you drunk if you drink/eat it. It must have the Food flag set.

The object will keep mobiles with FearHoly flag from attacking.

This object is cursed. (Will have some bad affects.)

This object is blessed. Some of the objects effects might be improved.

Just a flag to show players that the object might have some interesting properties.

This flag is used in combination with the Food flag. It causes LoveSickness.

This object is a plural object. (I.E. rations, etc.)

This object is a bottomless pit (think of the pit in the Temple). Any room where the object is in (on the ground) will experience the same drop and jump behaviour as the start locations, unless it's changed through catches on the room or on the object. Objects with this oflag will have the on_pit_drop and on_pit_jump catches triggered on them when someone drops something in the pit, or jumps in the room (ie jumps into the pit). See the documentation for those catches for more information.

This object may be used as currency. Coins, notes, etc.

This object will not be picked up with the get all command.

This object refuses to be dropped.

Wear Flags and how to use them

The Wflags field is a collection of flags for wearable objects. They are used to specify the position on the body something should be worn. The Wlayer field is used in combination with the Wflags. The wear flags are enclosed in curly brackets, {'s and }'s. There is no = sign on this field.

There is no requirement that wear flags should be specified, but there will be no restrictions applied if they aren't. As well as the position, a layer may be specified with Wlayer, though each position has it's default layer. This default layer will be correct for most things.

The layer specifies if things are worn over or under other things. Higher layers are worn over objects with a lower layer. The minimum layer is 0.
Note: If you are using several wear flags for an item and the layers have different default layers, you must specify a Wlayer entry or the wrong layer might be used.

Below is a list of all the current flags, their default layers and what sort of items should sit in that position at that layer. Hopefully it will give you some idea of what layer would be best if it is needed to set layers on other things.

[Flagname, default layer]
Description of useage. (NA in the default layer means that a layer isn't used.)

[NoExclude, NA]
The NoExclude flag is not a position, but a special flag to tell the mud that the wear restrictions, should NOT be applied to this object. It is mainly for insignificant things such as jewellery, that should not affect the wearing of anything else.

[Shield, NA]
Shield is a special position set aside exclusively for shields. All shields should have this flag and this flag alone.

[Torso, 2]
This by default is where `Armor' is worn, though armor may also cover other parts of the body. Shirts maybe worn here at layer 1, and possibly other things at a higher layer. Though there is a seperate position for cloaks etc.

[LeftHand, 1]
[RightHand, 1]
Gloves or gauntlets in general go here. It maybe that an item is a single glove, and would thus be either right or left handed. Likewise gloves may come as a pair, and both flags would be set.

[Arms, 2]
It is possible to break armor up into chest plate, arm and leg plates, though most current suits include all 3.

[Legs, 2]
Same as arms.

[Feet, 1]
This was meant for shoes, thus socks would be at layer 0. At present there was no splitting of feet into left and right because the game thus far has shown no signs that it would be needed. Shoes seem to be very rare.

[Wrists, 0]
The default layer was meant for a bracelet, which in general should probably not effect anything else. It matters not which wrist you attach a bracelet too, thus there is only one wrist position. However it has been coded to allow 2 objects at layer 0 in this position.

[Neck, 1]
Necklaces, pendants, amulets and such things. Unless it's important just set noexclude for jewellery.

[Face, 2]
This position was meant to cover the various masks in the game at it's default layer.

[Finger, NA]
This is exclusively for rings. You may wear at most 2 rings and layer is ignored in this case.

[Ears, 0]
Meant for earrings at it's default layer.

[Waist, 1]
The default layer should cover belts of various kinds. The sporran has been given this flag, but a noexclude flag to prevent it stopping someone wearing armored belts.

[Back, 2]
In general this is for objects such as capes, cloaks etc. Backpacks, would probably get layer 3.

[Eyes, 1]
The position meant for glasses of various kinds. The layer 0 has been left for something like a contact lens.

[Head, 1]
The default layers of 1 is for helmets, and other various kinds of hats. For crowns, set the layer to 2, as you could then wear the crown over a hat.

Attributes - another type of Oflags

The Attributes field is a collection of flags for magical objects. The point with this type of flag is to enable us to move away from having hardcoded magic. The Attribute flags are "secret", as in that they don't show up for wizards. For a flag to take effect the item must be in the top level of the inventory. This means that they have no effect if they are in an container. Also, if the object is wearable it needs to be worn for the effect to take place, likewise if it is wieldable it needs to be wielded.

This item will allow a armor_mod catch to be added, where armor bonuses can be calculated.

This item will speed up the healing rate to its maximum level. It is not additive with other items that increase the healing rate.

This item will speed up the healing rate. It is not additive with other items that increase the healing rate. If the player has an MinorHeal item and an MajorHeal item the healing rate will be that of the MajorHeal item.

Reduces the healrate. It is not additive with other items that reduce the healing rate. This rate is modified if you have a heal item.

Reduces the healrate even more than SlowHeal. It is not additive with other items that reduce the healing rate. If a player has both SlowHeal and VerySlowHeal items in the inventory, the healrate will be the VerySlowHeal rate. This rate is modified if you have a heal item.

Instead of healing you will lose strength. This is modified by heal items.

Allows players without the Emote pflag to use the EMOTE command everywhere.

Increases the chance to succeed with a spell. SpellBonus is additive.

Increases the chance of you succeeding with hitting your enemy in a fight.

Protects you from getting cursed.

Enables breathing where there is no air.

Protects you from being summoned.

Protects you from being affected by the shock spell.

Protects you from being affected by the frost spell.

Protects you from being affected by the missile spell.

Protects you from being affected by the fireball spell.

Enables the casting of the WizardEye spell. The object needs a Counter value greater than 0 to work (the counter field contains the number of charges).

Prevents you both from casting and from being affected by the cure spell.

Protects you from being blinded by the blind spell.

Protects you from being deafened by the deafen spell.

Protects you from being muted by the mute spell.

Protects you from being crippled by the cripple spell.

Stops the detect spell from working, both on itself and any other object the mortal might be carrying.

Stops the ignite spell from working, both on itself and on any other object the mortal wishes to ignite.

Stops the where spell from working, both for the player trying to locate things and for others trying to locate the player.

Stops the force spell from working, both on the player and by the player.

Increase the chance of successfully casting the where spell.

Gives full boost to the where spell.

Object brings luck in fights, etc (eg, horseshoe).

Object will make player fall slower, as to prevent them from dying when taking a high fall (eg wings, umbrella, etc).

Creating Rooms

"Where no man has gone before!"

What is a room?

A room is what you find yourself in every time you move on a mud. It is composed of four main parts:

  1. Room number and exits
  2. Room flags
  3. Room title
  4. Room description

Room entries may look as follows:


waitingroom n:bedroom e:outside w:hallway; 
lflags {} 
The Waiting Room^ 
 You stand  inside  a small room. Nothing fancy here, just
ladies in waiting. Maybe you should leave? 

outside n:forest2 e:forest1 s:forest@arcadia w:waitingroom; 
lflags {Outdoors NoSummon} 
In the garden^ 
 You stand in a beautiful garden.  

You just saw how two rooms are defined. For each room, the very first field is the label of the room. In the case of the first room it is labelled "waitingroom", and in the case of the second one, "outside". You may use any name you wish here, but you may not have two different rooms with the same label inside the same zone. This will never be seen by players, it is just for programmers.

The next fields on the same line are exits. e:outside simply means that there should be an exit leading to the room labelled "outside" in the current zone. Valid exits are n, e, s, w, u, d. To make it easier for the programmer, please keep them in the order mentioned above.

When making an exit to another room, you may want to make sure that room has an exit leading back to this original room, else the player will get stuck there without an exit.

Direct your attention now to the second room, exit leading south. It states s:forest@arcadia.

What this means is that the exit to the south will lead to the room labelled forest, but in a different zone, namely arcadia.

There is a special kind of exits, which depend on objects. That is the case with doors. However, refer to the section on doors for a detailed explanation of handling those.

To finish up this very first line of a room definition, the trailing semicolon (;) must be included. It signals the end of that particular field.

The second line is a set of lflags. If you don't want any special lflags for this room, you must still specify that line, but put nothing in between the curly brackets. The various flags are described at the end of this chapter.

The third field is the title of the room. Notice the trailing ^ sign. That sign must exist there, to mark the end of the title. It will not be printed to players.

The remaining lines of the room are the room description itself. As with the title, end it with a ^ on an empty line. It is standard practice that room descriptions start with a 4-letter indentation, but that is up to you.

Lflags and their meaning

Valid lflags are as follows:

This is a very special room, which mortals dread very much. Any mortals entering this room will die. They will not lose points, but their inventory will be trapped here, and they will be kicked off the game.

Mortals can't see in here unless they have brought some light.

People cannot be summoned away from this room.

People cannot be summoned to this room.

Players cannot quit from this room.

Players may not be snooped in this room. Not needed if the room also has the Private flag.

Mobiles will not enter this room. This flag is useful to stop mobiles from wandering in or out certain places.

Mortals may not cast magic from inside this room.

There will be no fighting permitted inside this room. This is a safe haven for mortals.

This room is soundproof. Tells, shouts, etc., will not be heard inside the room.

This room is only big enough for one person. You will not be able to enter it if there is already a person inside.

Anyone is allowed to use the Emote command here.

This room is only big enough for two persons. A third player trying to enter the room will be told the room is full. Snoop is disabled for private rooms.

This room is on-water. A boat will be required for mortals.

This room is under water. Mortals will need some magic object to survive here.

This room works like the Underwater rooms, but it isn't as wet...

This room is outdoors. Weather messages will be seen and time of day and night will show. Do not combine this flag with TempExtreme or Seasons.

There will be daytime changes in this room. Hot during the day, cold during the night. A fitting flag for a desert. Do not combine this flag with Outdoors or Seasons.

This room is subject to day/night messages, and the effects thereof. Do not combine this flag with Outdoors or TempExtreme.

It is too dangerous to fall asleep in this room.

Mortals will actually lose strength if sitting around in this room. The speed they lose strength with is slightly slower than the speed they regenerate. If you wish the strength to actually go down combine NegRegen with the NoRegen flag.

Mortals will not regain any strength while in this room.

This room is a very cold room. If it is outdoors, any rain will turn to snow.

This room is a very hot room. Mortals will need protection.

This room is a part of a maze. Players with the Goto pflag will not see the full names of the exits.

This is basically a flag used for wizardly home rooms if you wish to be sure that nobody will be able to enter the room invisibly. Note: Setting this flag will not affect anyone that was already invisible in there.

This location is meant solely for new players (lvl 0, 1 and 2) and will not allow other mortals to enter.

Players cannot follow someone into this location. You have to enter it by your own device.

The GOTO and TIPTOE commands can't be used to enter or leave this room.

Prevents random teleports (eg, the party balloons) into the room.

Prevents the use of the EXITS command, and disables AUTOEXITS for the particular room.

Prohibits players from setting their start room to that room.

Increases the regeneration speed in that room.

Unless you are protected, the lava will kill you.

Creating Doors

"Break on through to the other side..." - The Doors

What's so special about doors?

Well, nothing is special about doors, except that you need two of them. First, let's consider two rooms, labeled 'outside' and 'inside'.

outside s:^outside_door; 
lflags {Outdoors} 
    You are outside.  

inside n:^inside_door; 
lflags {} 
    You are inside.  

Notice how the two room exits, s: and n: respectivelly, point to something starting with a ^ sign? That marks an object. What this means, is that the room exit depends on the state of the object named there.

Let's now define the two objects, inside_door and outside_door:

Name    	= inside_door 
PName   	= door 
Linked  	= outside_door 
State   	= 1 
MaxState	= 2
Key     	= key@church
Location	= IN_ROOM:inside 
Oflags  	{ Openable NoGet Lockable } 
Desc[0] 	= "The door is open." 
Desc[1] 	= "The door is closed." 
Desc[2] 	= "The door is locked." 
End     	= inside_door 

Name    	= outside_door 
PName   	= door 
Linked  	= inside_door 
State   	= 1 
MaxState	= 2
Key     	= key@church
Location	= IN_ROOM:outside 
Oflags  	{ Openable NoGet Lockable } 
Desc[0] 	= "The door is open." 
Desc[1] 	= "The door is closed." 
Desc[2] 	= "The door is locked." 
End     	= outside_door 

This is all it takes to make a door. Note the Linked fields on the object descriptions. They point to each others. So, in theory, what happens is that if someone tries to go through an exit that points to an object, the game will check the status of the object. If the object is status 0, it will check the Linked field, and allow the player to move into the room where the Linked object is.

Note that you do NOT have to always specify a Key field. As a matter of fact, most of the time, you should not specify this field at all. When the key field is empty, any key will be able to lock and unlock this door.

So, to recap. To make a door, you must do the following:

  1. Create two objects, one for each side of the door. The objects must have a Linked field. On the Linked field, put each other's name. Note that the Openable/Lockable flags depend on your applications. For some applications, you may not need those flags. NoGet flag is highly desirable, tho! If you wish the door to be unlocked/locked with a special key (it does not need to have the "key" oflag), add a Key field to the doors. You can also decide to have special texts for when the doors gets opened/closed/locked/unlocked. This is explained in the Creating Objects section.

  2. Edit the description of the room you are leaving from and set the respective exit to ^object_name, where object_name is the label of the first object you created. Then edit the descriptions of the destination room, and put an exit back to the first room, pointing to the other object.

Some Important Notes

"Mind your step!"

Referencing one zone from another

You may reference any object contained in one zone, from another zone, using the @sign. For example, you would like to refer to the object stick in room blizzard, you would specify it as stick@blizzard. Some examples:

Location        = forest@arcadia 
Location        = CARRIED_BY:dragon@cave 


Setting continents

Northern Lights has included a unique feature to determine on what continent a zone is located. This is the fourth keyword besides %mobiles, %objects and %locations that the special zone generating program will scan for. Currently there are three legal values for the %continent entry:

         Void         Barbarian         Empire

Void represents locations that doesn't explicitly belong to any of the two continents and is used for, for instance, the wizard home zone, limbo, navigare and so on. It is also possible to specify a different continent for a single room.

Example zone, belonging to the Empire, but with one location in the Barbarian continent:

#include "undef.h"
#include "cflags.h"

%continent: Empire


[definitions for mobiles]


[definitions for objects]


[long list of locations]

Continent Barbarian
lflags{Peaceful NoMobiles}
Floating on a Raft^
   You are lying on your back on a raft, which is silently buoyed by
gentle waves lapping against its sides.
A couple seagulls are following your progress with the usual curiosity
of gulls and their presence indicate that there is land close by.
Take notice of the Continent Barbarian line. This part of the location is not needed unless you wish to specify a location that belongs to another continent than the one set for the zone in the %continent entry.

The %continent entry is defaulted to the Barbarian continent. This means that if you don't have an %continent entry in your zone, it will be assumed to belong to the Barbarian continent.

Entering text strings

Certain fields accept variable length strings. However, you must first acquaint yourself with the legal (and illegal) ways to type in a string.

Legal ways:

Field1  = "This is legal." 

Field2  = " 
This is also perfectly legal." 

Field3  = " 
And this too. There is no problem with typing in a few lines
of description. Just make sure you don't forget the ending

Illegal ways:

Field1 = 
"This is not legal. The beginning quote must be on the same
field as the equal sign."

left right home zone advice mail

Last edited January 15, 2005.