The Room Section

The previous chapter gave you the basic building blocks that will be used all through creating rooms, NPCs, and objects. If you jumped straight to this chapter without reading about the general building blocks you might want to return to the chapter called Unit Building Blocks first. This chapter will deal with all the fields of rooms what they are and how to use them; but, without the previous chapter you may get lost.

In order to get started building rooms you should first be aware of the room fields you can use. The Table 1 shows a full listing of all the room fields and their types as defined in the chapter called Unit Building Blocks.

Table 1. Room fields and types listing

FieldType FieldType
symbolic nameSymbol manipulateInteger
dilbegin or dilcopyFunction pointer  

As you can see there are not a whole lot of fields you have to learn in order to make a room. In fact, as you will see shortly, some of these fields are not even used on rooms. In the Section called Description of Room Fields we will expand your knowledge from just knowing what the field types are to how to set them as well.

Description of Room Fields

symbolic name

The rules of the symbols has been explained in the chapter called Unit Building Blocks, if you didn't read them yet you may want to review. The important thing to realize with the room symbol is it is always good practice to give the room a symbol resembling the title so administrators and builders can use the goto and the wstat to easily goto the room in question.


The room title field should start with a capital and depending on your preference the compiler will not complain if you add punctuation at the end. The following are good examples of a room title.

title "The Post Office"
title "The deep dark jungle floor:"
title "The Dragon Station control room"

It is really up to you whether you want to use punctuation or not, it is more administrator personal opinion than anything.


The names field on the rooms are not that important and only should be used if the builder wishes the room to be accessed by the players by a teleport command. If the room has no names no one will be able to teleport to it. On some muds there will be no teleport spell, so the only use for this field will be for DIL functions the administrator creates. If a builder wants the room to be accessible by teleport then the names should match the title since that is what the player will try to teleport to. A few good examples of names on a room would look as follows.

title "The Post Office"
Names {"post office","office"}

title "the throne room"
names {"throne room","throne"}


The description field is what the player sees when walking into the room or when looking with no arguments.


This field is what is shown to a char if the room is loaded inside another room. For example if you had a room linked inside another room and called a barrel this would be the description that lets the character know it is a barrel. An example would be like:

outside_descr "a big old barrel is laying here on its side."

This allows a builder to make a room that looks like an object inside another room.


The movement field defines the endurance cost to a character when moving through this room. In the future these fields will be adjustable by the use of a define file. Currently all movement fields are constants and are defined in the vme.h The following is the movement sector types and their values.

Table 2. Sector movement values

SymbolNameEndurance Cost
The movement is simply defined by placing the 'movement' keyword first followed by the type of sector you desire. For example a few movement fields would look as follows:

movement SECT_FOREST
movement SECT_HILLS


Only one movement is needed for a room if you put more than one the last one added will be the one used.


This field on a room is used to set special attributes in order to make the room private or no-teleportable and many others. The following is the list of possible already defined flags. Extras can also be used to create special room flags.

Table 3. Room unit flag affects

UNIT_FL_PRIVATEWhen this flag is set on a room it marks it as a private room. Commands that honor the private flag will not let more than 2 players into this room. Commands like goto and direction commands are a few commands that do honor this flag.
UNIT_FL_INVISIBLEMakes unit invisible
UNIT_FL_NO_BURYMakes a hard floor so items can't be buried.
UNIT_FL_BURIEDMakes unit buried when loaded
UNIT_FL_NO_TELEPORTmakes unit so no one can teleport to it
UNIT_FL_NO_MOBMakes it so no mobile will enter the unit
UNIT_FL_NO_WEATHERkeeps weather and natural light out of unit
UNIT_FL_INDOORSMakes unit inside and doesn't affect weather
UNIT_FL_TRANSMakes unit transparent
UNIT_FL_NO_SAVEMakes it so you can't save with unit
UNIT_FL_SACREDMakes unit a double gain unit
UNIT_FL_MAGICMarks a unit to be magic


Extras are the work horse of the VME. Extras are used in everything from DIL to just normal extra descriptions on rooms. The first job for an extra was to hold extra description information on a room. For example, if you had a computer room and you described it might look something like this:

"This small room houses the computer power of the 
VME development team.
All four walls are lined with various pieces of computer equipment old 
boxes and plenty of empty soda cans."

The problem is as a player if you saw this description you might want to know what kind of pizza we eat or maybe you would want to see what kind of soda we drink. Or heaven forbid you might want to know what kinds of computer equipment is scattered about the room. In the VME servers we do this by adding extra descriptions to the room. In this case the builder of the zone may do something like this:

"This small room houses the computer power of the 
VME development team.
All four walls are lined with various pieces of computer equipment old 
boxes and plenty of empty soda cans."

extra {"soda cans", "cans", "soda", "can"}
"These cans are all Canadian blue.  Maybe the Valhalla team hates 
beer.  Strange all of them look to have strange indentations."

extra {"strange indentations", "strange indentation","indentation"}
"They are human bite marks.  Is this what happens when code doesn't 
work right?"

extra {"pizza boxes","pizza","boxes","box"}
"Dominos could make a fortune from all these boxes and probably already 
from the VME team.  You notice all the boxes are 
empty at least they finish what
they start."

extra {"computer pieces","computer parts", "equipment","hardware", 
"pieces", "parts"}
"I bet you thought you would see what we have running.  Yeah right, you 
might come
over and rob us if we told you that.  All you see is an old XT."

extra {"xt"}
"It's a hunk of junk really!"

There is a lot to notice in the previous examples. First we will start with extras when defined on rooms, NPC, and objects must be in length order for the names. There are a few reasons for this but let's just say the most important reason is we wanted it this way. If you don't put them in order the VMC will give you a fatal error and will not compile your zone.

The next thing you should notice is we have used an extra to describe something in another extra. We actually did this twice once for the beer cans and once for the computer parts. That way you can actually give quest information but make the person really have to explore your rooms' descriptions to find it.

The previous example is what we consider normal extras in a room. There are also extras that hold information for DIL functions. These special extras can have extra fields and they can be hidden to the players eyes. Here are some examples of special extras.

extra {"$rockcount"}

extra {"$playerkill"}

extra {"$coke","$milk","$water"}{1,5,10}
"Drinks and amounts"

These extras all have the '$' sign appended to the front of the names in order to tell the look command the player shouldn't be able to look at the extra. If you have not already seen DIL coding you may not understand why you would want extras players can't see. The DIL language can manipulate these extras by reading and writing them in order to change the way a command or another function works. For example, the last DIL could be used for a shopkeeper to tell how many of each type of drink he has. Notice the drink extra also has something you haven't seen yet, an added integer list after the namelist. All extras can have these but only extras being used with DIL functions really need them.

Some of these special functions are supported already in the code and the ones that affect the rooms are as follows. In the following $1n is the activator and $2n is the unit in question.

There is only one special extra already supported for rooms and that would be the '$get'. As we have previously mentioned the extras that start with a dollar sign are not seen by the players. This one however is shown to the player when the person types get on the other names in the extras list. This easier to describe in an example than in words so the following would be a good example.:

extra {"$get", "statues", "statue"}
"You attempt to pick up a statue but quickly discover your feeble
attempts will never work."

{"$get", "red roses", "roses"}
"You bend down to pick a rose, but then decide to leave the beautiful
flower to itself."

With this one special extra we have made it so you don't need to make millions of items so the person can act upon them. You can just make the acts as if the items were in the room.


Every room has ten possible exits; North, East, South, West, Northeast, Southeast, Southwest, Northwest, Up and Down. To enable mobile use of these commands, you must specify these exits as outlined below:

exit <direction> [to <destination>] [open 
[key <keyname>] [keyword {<keywords>}] descr 
<description> ; 

exit <directions>

Is the direction the exit leads, i.e. one of north, south .. up, down.

to <destinations>

The symbolic reference to the room, you want this exit to lead to. If you reference a room within another zone, append the name with @<zone name>

  to myotherroom

  to hisotherroom@hiszone

open <info flags>

These flags describe the state of the door. The following is the list of possible door flags.


Set this if you can open and close this exit, be it a door, gate or otherwise.


Set this if you want the exit to be closed at boot time.


Set this if you want the exit to be locked at boot time.


An interesting aspect is, if you do not specify a key, you can only unlock this door with the 'pick' skill, 'unlock' spell or from DIL with UnSet();


Using this flag renders the 'pick' skill and 'unlock' spell unusable on the lock of this exit.


If this bit is set, the exit is hidden until the player has successfully searched for it, using the 'search'-command.

key <keyname>

The symbolic name of a key object used for unlocking this exit.

key mykey@myzone

keyword { <stringlist> }

This stringlist holds all the names of the exit, you specify to manipulate the exit. If the exit is hidden exit, these are the keywords the mobile or player can search for.

keyword {"wooden door","door"}

keyword {"hidden door","door","hatch","floor"}

descr <description>

This string is the description of what you see if you look in the direction of the exit.


Every exit statement needs to be terminated with a semi-colon.

NoteGeneral notes

Even though you do not need an exit in all directions, you can use it to place descriptions of the direction.

      exit north descr "An insurmountable mountain blocks your way.";


This field is rarely used on rooms. It could however be used to make a room invisible inside another room. Or it could be used to store numbered values on a room. The reason this field is on a room is it is part of the base object which all objects are derived from. If the room is going to be inside another room and you don't want it visible the following would make it invisible to all players below the level of 20.

minv 20


This field is not used normally on a room. It is a string that can be used for anything you desire. The reason it exists on rooms is it is a part of the base object all unitptrs (unit pointers like, rooms, objects, and NPCs) are derived from.


This field is not used normally on a room. It is an integer that can be used for anything you desire. The reason it exists on rooms is it is a part of the base object all unitptrs are derived from.


This field is not used normally on a room. It is an integer that can be used for anything you desire. The reason it exists on rooms is it is a part of the base object all unitptrs are derived from.


This field is not used normally on a room. It is an integer that can be used for anything you desire. The reason it exists on rooms is it is a part of the base object all unitptrs are derived from.


This field is not used normally on a room. It is an integer that can be used for anything you desire. The reason it exists on rooms is it is a part of the base object all unitptrs are derived from.


This field sets the light on a room. Normally this is not done directly, instead it is set using macros defined in wmacros.h.

Table 4. Light defines

DefineLight ValueAffect
ALWAYS_LIGHT1Room is always light no matter time of day
IN_ALWAYS_DARK -1When an inside room is always dark - both inside and outside
OUT_DARK_NON_NOON -1Always a dark room, except when it is high noon
OUT_ALWAYS_DARK -2Always a Dark room, no matter the time of day

To set natural light that changes depending on the type of day nothing is needed to be put in the light field the compiler will default to '0'. If you for some reason want to set the light to default lighting you can do so but you don't need to. You will also notice there are two macros that set the light to the exact same value. This is for compatibility with older code base and if you wish to combine these two macros or only use one it would not change the way the mud works.

This is probably one of the simplest fields you will have to deal with in the rooms. In order to set it all that is needed is to place the macro or the light and value on a line in the room and you're all done.

//To Set always light with macro

//To set Always light with out macro
light 1

You can decide which is easiest for you.



dilbegin or dilcopy

The DIL functions are what give VME servers the edge over all other muds. We will only give some examples here and leave it up to the DIL manual to teach you how to create your own functions that will make your rooms, NPC, and objects more than special.

There are only currently three room functions that come standard with a VME in the function.zon. There are much more in the zones released with the VME but you will have to hunt for those. The three that come standard are Safe room, Death room, and forced move. The safe room makes it impossible for players to kill each other, the death room is a function that lets you make things like rock slides and quick sand, and the forced move lets you make an easy river.

Since these are just DIL's written by builders for the Valhalla mud all you have to do is use the dilcopy keyword in the room with the function name you want to use and the arguments the function requires. The following is what you would find in the function.zon for death room.

/* Death room DIL
*tick is in 4th's of seconds
* Damage is damage done per tick
*act_s is string shown to damaged player.
dilbegin death_room(tick: integer, damage: integer, act_s: string);

var ext: extraptr;
    u  : unitptr;
    i  : integer;


if (tick < 12) tick := 12;

heartbeat := tick;

if (damage < 0)
    damage := -damage;

if ("$death room for mobs" in self.extra)
    i := UNIT_ST_PC;

while (TRUE)
wait (SFB_TICK, TRUE);

foreach (i, u)
    if (u.level >= IMMORTAL_LEVEL)

    if (("$no death room" in u.extra) and (u.type == UNIT_ST_NPC))
        continue; // Don't allow pcs to get this flag

    if (act_s != "")
        act ("&[hit_me]"+act_s, A_ALWAYS, u, null, null, TO_CHAR);
        act ("&[hit_me]You bleed from your wounds.",
            A_ALWAYS, u, null, null, TO_CHAR);

    u.hp := u.hp - damage;
    position_update (u);




If this DIL function scares you don't worry you don't have to understand or adjust it you just have to use it. This function requires a time, damage, and act. So you could use this in a room definition like this:

dilcopy death@function (60,25,"Flames shoot from the floor burning
your rear.");

This says to copy the DIL from zone function with the arguments 60 seconds, damage 25% and act as shown. Pretty simple eh?

All released DIL room functions are described in the Section called DIL functions for rooms. Then we put some to work so you can see how to use them in the Section called A more complex set of rooms