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.

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.

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:

descr
"This small room houses the computer power of the 
VME development team.
All four walls are lined with various pieces of computer equipment old 
pizza
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:

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

extra {"soda cans", "cans", "soda", "can"}
"These cans are all Canadian blue.  Maybe the Valhalla team hates 
American
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 
have
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"}
"5"

extra {"$playerkill"}
"0"

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 
{<infoflags>}]
[key <keyname>] [keyword {<keywords>}] descr 
<description> ; 

	General 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.

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
ALWAYS_LIGHT

//To set Always light with out macro
light 1

You can decide which is easiest for you.

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;

code
{

if (tick < 12) tick := 12;

heartbeat := tick;

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

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

while (TRUE)
{
wait (SFB_TICK, TRUE);

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

    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);
    else
        act ("&[hit_me]You bleed from your wounds.",
            A_ALWAYS, u, null, null, TO_CHAR);

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

}

}

dilend

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