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 on 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 following table shows a full listing of all the room fields and their types.

Room Fields and Types

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.

Description of Room Fields

Symbolic Name

The rules of the symbols has been explained in the chapter on 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 commands to easily goto the room in question.

Title

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.

Names

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"}

Description (descr)

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

Outside Description (outside_descr)

This field is what is shown to a character 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.

Movement

The movement field defines the endurance cost to a character when moving through this room. Currently all movement fields are constants and are defined in vme.h. The following is the movement sector types and their values:

The movement is simply defined by placing the ‘movement’ keyword first followed by the type of sector you desire. For example:

movement SECT_FOREST
movement SECT_HILLS

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

Graphical Map Coordinates (gmap)

The gmap field sets coordinates for positioning the room on a graphical map display.

gmap(x, y)

If not specified, both default to -1 (unset). These coordinates are accessible in DIL via the .mapx and .mapy fields.

Example:

gmap(100, 50)

Flags

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:

Extra

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, NPCs, 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.

Special Extras

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 an added integer list after the namelist. All extras can have these but only extras being used with DIL functions really need them.

The $get Extra

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 is easier to describe in an example:

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

extra {"$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.

Exits

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:

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

Exit Components

<direction>

The direction the exit leads, i.e. one of north, south, east, west, northeast, southeast, southwest, northwest, up, down.

to <destination>

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:

• EX_OPEN_CLOSE - Set this if you can open and close this exit, be it a door, gate or otherwise.
• EX_CLOSED - Set this if you want the exit to be closed at boot time.
• EX_LOCKED - Set this if you want the exit to be locked at boot time.

Note: 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().

• EX_PICKPROOF - Using this flag renders the ‘pick’ skill and ‘unlock’ spell unusable on the lock of this exit.
• EX_HIDDEN - If this bit is set, the exit is hidden until the player has successfully searched for it using the ‘search’ command. Use with the difficulty field to set search difficulty.
• EX_CLIMB - Indicates the exit requires climbing (uses climbing skill).
• EX_FALL_THIS_WAY - Used with EX_CLIMB to mark the direction characters fall when they fail a climb check. Characters continue falling through rooms with this flag until reaching one without it.

difficulty <value>

Sets the skill difficulty for picking locks or searching for hidden exits (0-250). Higher values make it harder to pick or find. If not specified, defaults to 25.

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

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

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

Minv

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

Key, Manipulate, Alignment, Weight, Capacity

These fields are not used normally on a room. They exist because they are part of the base object all unit pointers (rooms, objects, and NPCs) are derived from. They can be used for anything you desire.

Light

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 time of day nothing is needed to be put in the light field - the compiler will default to ‘0’. 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.

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:

// To set always light with macro
ALWAYS_LIGHT

// To set always light without macro
light 1

DIL Functions (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, NPCs, and objects more than special.

There are 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 DILs 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. For example, using the death room function:

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

This says to copy the DIL from zone function with the arguments: PULSE_SEC*60 ticks (60 seconds), damage 25 hit points, and act as shown. Pretty simple!

Building Your First Room

Now you are ready! With all you have learned about room fields you know everything you need to build your first room. I personally like dragons and I like space so I have chosen to make a dragon station. We will first do a simple room and build on to it in the next sections. In this section we will walk you through creating a basic room and why we choose what we do where we do.

When making rooms you create the zone source file first as shown in the Zone Source File chapter. If you only have rooms you do not need the %reset, %objects, and %mobiles. For the examples in this chapter we will use the zone we created in that chapter and add the %room tag where we will put all the rooms. At the end of the chapter we will have the entire zone so you can see it all together.

The first part of all rooms is the symbolic name. It is good to always pick a name that will match the title so you can use the administrator command goto to easily get to the room. The reason is when you use the command wstat it will only show you a list of the rooms by symbolic name. For example if you type wstat zone dragon room you will get the following:

List of rooms in zone Dragon:
chamber portal office

If you didn’t make it clear what the rooms were by the symbolic name it might look like this:

List of rooms in zone Dragon:
st_rm1 st_rm2 st_rm3

While this might be great when you first start, imagine trying to remember what all one hundred rooms are.

The first room we will create will be a simple chamber with nothing special. We can build on to it later if we need to.

chamber
end

Pretty easy so far. Now let’s add some life to it. The room needs a title and a description. The title should be a one line description of a room as if you were walking someone around your house and telling them what each room was, like this is ‘My house’s big bathroom’ or maybe this is ‘The computer room’.

The description should be something you would tell an interior decorator you were talking to on the phone and asking for advice. He would want to know everything about the room you can see like furniture, the shape, size and windows.

chamber
title "The middle chamber of the station"
descr
"This chamber seems to have the entire station rotating around it.
Small human size ornate chairs with dragon designs scrawled on the
arms and back are arranged in a triangle like setting with one large
chair at the front.  This must be where all station meetings are held.
large pictures cover the walls depicting dragons in all kinds of
situations.  Small passages lead off to the west and the east."
end

It is a matter of taste if you want the descriptions of the exits in your description or not but I like them so I put them. Now if you gave this description to the interior designer, they might ask you what is on the pictures or maybe even what exactly do the chairs look like, so we better take care of that by adding some extras to our room.

extra {"chairs","chair"}
"The chairs are made of some metal you don't recognize and every inch
is covered with some kind of dragon."

extra {"dragon picture","picture"}
"Thousands of dragons dot the skies of this rather life like picture.
In the center you see something move.  It looks to be a little green dragon."

extra {"green dragon","dragon","green"}
"An intelligent looking dragon is sitting perched on a large chair
watching you."

Normally we could put a movement type for the amount of endurance lost when a person is moving through the area but we will leave it blank and go with the default which is SECT_CITY since with the fake gravity that is the closest we could come with the sector types available. The last thing we need to finish our room is the two exits leading to the other rooms.

west to portal descr "You see a small room.";

east to office descr "You see what looks to be an office.";

That’s it - that is all there is to making a room. In the next couple of sections we are going to add some more rooms with more advanced features and give some debugging hints for compiling your rooms but if you understand everything so far you’re going to have no problem. Let’s take a look at our entire finished first room:

chamber
title "The middle chamber of the station"
descr
"This chamber seems to have the entire station rotating around it.
Small human size ornate chairs with dragon designs scrawled on the
arms and back are arranged in a triangle like setting with one large
chair at the front.  This must be where all station meetings are held.
large pictures cover the walls depicting dragons in all kinds of
situations.  Small passages lead off to the west and the east."

extra {"chairs","chair"}
"The chairs are made of some metal you don't recognize and every inch
is covered with some kind of dragon."

extra {"dragon picture","picture"}
"Thousands of dragons dot the skies of this rather life like picture.
In the center you see something move.  It looks to be a little green dragon."

extra {"green dragon","dragon","green"}
"An intelligent looking dragon is sitting perched on a large chair
watching you."

west to portal descr "You see a small room.";

east to office descr "You see what looks to be an office.";
end

Compiling and Debugging Your First Room

It is time we put the zone header information together with your first zone and compile it into a format the VME server can use. This is done by using the VMC compiler. Depending on if you are doing this on your own Linux server or if you are building for a VME already set up you will have to use the compiler access method they have defined. No matter if you are compiling by email, ftp, or at the command line with VMC the error messages will all be the same. Since I have no idea how your particular set up is designed I will explain the errors that the compiler will return and you will have to ask your system administrator how to access the compiler. The rest of this section is written assuming you have your own VME running on your own Linux box using the VMC at the command line.

When you are working on your first zone it is always a good idea to start with one or two rooms and compile them instead of writing all the rooms and then trying to compile. The reason is the more rooms you have the more confused you can make the compiler if you have a lot of errors and you may not be able to figure out where your first mistake was easily. In our case we only have our first room and the header information for the zone so let’s put it together now and try and compile it.

#include composed.h>
%zone dragonst
lifespan 20
reset RESET_ANYHOw
creators {"whistler"}

notes
"This is the dragon station I shortened it to dragonst for ease in
loading.  If you have any questions email me at admin@example.com"

help
"Not sure what could help you now.  You are stuck on one of the
weirdest space stations you have ever seen and you smell burning
sulfur."

%rooms

chamber
title "The middle chamber of the station
descr
"This chamber seems to have the entire station rotating around it.
Small human size ornate chairs with dragon designs scrawled on the
arms and back are arranged in a triangle like setting with one large
chair at the front.  This must be where all station meetings are held.
Large pictures cover the walls depicting dragons in all kinds of
situations.  Small passages lead off to the west and the east."

extra {"chairs","chair"}
"The chairs are made of some metal you don't recognize and every inch is
covered with some kind of dragon."

extra {"dragon picture","picture"}
"Thousands of dragons dot the skies of this rather life like picture.
In the center you see something move.  It looks to be a little green dragon."

extra {"green dragon","dragon","green"}
"An intelligent looking dragon is sitting perched on a large chair
watching you."

west to portal descr "You see a small room.";

east to office descr "You see what looks to be an office.";
end

%end

We added the %room tag to our zone header, stuck our room in and now it’s ready to be compiled and put into the VME server for you to be able to look at it in the game. If you downloaded our example zones for this document you can compile this zone along with us and fix the errors as we do for practice. The filename is debug_rm.zon. Just so you know the errors in this zone are intentional so please don’t write me an email telling me there are errors in it.

The command to compile the zone is VMC debug_rm.zon. Here is what we get when we first try and compile the zone:

VMC 3.0 for Muspelheim
Compiling 'debug_rm.zon'
<debug_rm.zon> @ 2: Bad include argument
<debug_rm.zon> @ 49: EOF in string
Fatal error compiling in preprocessor stage in file 'debug_rm.zon'.

Don’t worry if this looks scary, it really is much easier to read than it looks like. The first thing you need to realize about compiling is always fix one error and compile again because it might fix two or three errors after with one fix. The reason is once a compiler hits something it doesn’t understand it gets confused with the rest of the file. It is sort of like if you thought the word ‘water’ meant ‘fire’ and you tried to read a book it would get confusing really fast. So you have to correct the definition of ‘water’ to understand the rest of the book.

Let’s take the first error with this in mind. The first error shows up on line three of the error file it says:

<debug_rm.zon> @ 2: Bad include argument

This line is not really cryptic - reading it in a more English form would sound like: In file ‘debug_rm.zon’ you have an error at line 2, the argument to the include statement is not correct. Not all errors will be this clear but the compiler does its best to get you close to the error. Now if you look at line two in debug_rm.zon, you will find we forgot to put in the ‘<’ symbol. If you fix the line to look like:

#include <composed.h>

Then recompile you will have fixed your first error and get a whole new set to play with. The following is the errors we got after fixing line two:

VMC 3.0 for Muspelheim
Compiling 'debug_rm.zon'
<debug_rm.zon> @ 49: EOF in string
v: debug_rm.zon: 5: syntax error
   Token: 'RESET_ANYHOw'
v: debug_rm.zon: 22: syntax error
   Token: 'This'
v: debug_rm.zon: 27: syntax error
   Token: 'and'
v: debug_rm.zon: 27: syntax error
   Token: '.'
Grave errors in file 'debug_rm.zon'.

Now this looks to be a much more interesting error file than the previous one. Remember we mentioned you should always fix the first error first so the compiler doesn’t get confused. In this error file the first line is not the first error we need to fix. We have to do some logical reasoning here. The first error the compiler came across was the one on line 5 that shows up around line 4 of the error file. The lines before it are letting you know somewhere else in the file there is a missing quote. If we clean up the first error however we might be able to find this missing quote much easier.

So let’s start by looking at line 5 which is saying the compiler doesn’t understand what the token ‘RESET_ANYHOw’ is. This makes sense - the token should be ‘RESET_ANYHOW’ and the compiler is case sensitive. So all we need to do to fix this one is capitalize the ‘w’ and the error should be cleared up. Let’s try that and recompile and see what the errors look like. With that line fixed the following is the errors we get:

VMC 3.0 for Muspelheim
Compiling 'debug_rm.zon'
<debug_rm.zon> @ 49: EOF in string
v: debug_rm.zon: 22: syntax error
   Token: 'This'
v: debug_rm.zon: 27: syntax error
   Token: 'and'
v: debug_rm.zon: 27: syntax error
   Token: '.'
Grave errors in file 'debug_rm.zon'.

Again we must figure out which error message we should deal with first. As before we need to deal with the lowest number error. The error we need to fix first then is the one on line ‘22’. If you go to line ‘22’ you will notice the line looks fine. When you run into an error like this where the error is not exactly on the line, scroll up to the field before the one in question and you should find the problem. In this case we forgot a ‘“’ on the ‘title’ line and confused the compiler because it thought the ending quote was the one after the ‘descr’ field. Therefore the compiler didn’t understand the ‘This’ as a field. This is one of the harder errors to find but once you get used to it will come naturally and the compiler does try to get you close. Now if we add the ‘”’ we are missing and recompile the following is the output we get:

VMC 3.0 for Muspelheim
Compiling 'debug_rm.zon'
VMC Done.

Notice there are no errors and it says ‘VMC done’, this means you have now successfully compiled the zone. I want you to look at the last error file and the fact that we only changed a quote to go from it to no errors. This is why you always deal with one error at a time. Sometimes fixing one error can fix a lot of the weird errors that make no sense. In fact I have seen one quote cause as much as 50 errors so if you jump around trying to fix errors that look like they make sense you may end up making more work for yourself.

Now that you have a compiled zone you should check and make sure all the files are there. When you compile a zone you will end up with three extra files. The files will have the same filename as your zone with a new extension - in this case you should have the following:

debug_rm.data
debug_rm.err
debug_rm.reset
debug_rm.zon

If you have all of these you are all set to go. If not then there is something seriously wrong and you may want to write the VME staff for help. To get your new zone in the mud all that is needed is to make sure your zone is in the zonelist in the VME etc directory and copy these files into your zone directory. Then reboot the mud. You should be able to log on your builder character and goto your zone by typing goto chamber@dragonst.

There you go - you have now compiled your first zone. It’s not much to look at but with what you already know you could make a full zone of very basic rooms. The next few sections will teach you some of the more interesting things you can do when making your rooms.

DIL Functions for Rooms

The DIL language is the language a builder can use to make his own special functions on rooms, NPCs, objects, PCs, and much more. This manual is for basic zone writing and therefore will not go into how to write your own DIL functions. The VME however is released with many functions for you as an Administrator and your builders to use to make special rooms, NPCs, and objects. The following is a list of all room functions released with the VME server.

Death Room

This function is a simple function that allows you to create a room to do damage to a player. The death_room can kill them slowly like a fire cave would or it can kill them quickly as if you stuck them in a microwave - it is all up to how you set the arguments. It also lets you set the acts the players see so this function can be used on any number of death style rooms. There is no need to understand how the function works, just how to use it. The following is the function’s header:

// In function.zon
dilbegin death_room(tick: integer, damage: integer, act_s: string);

As with any function all you have to do is ‘dilcopy’ the function onto your room with the correct zone name and arguments and it will do the rest. In this DIL you have three arguments to pass. The first is the ‘tick’ or time which in this DIL is broken down into ‘ticks’ which are 4 ticks per second. Thus if you wanted to get something to do damage every minute you would put ‘60*4’ in that spot. The next is the amount of damage you want done per your time. If for example you want ‘60’ hit points damage done each round you just put ‘60’ as that argument. Finally is the act shown to the character as a string in quotes. So a finished death room on your room would look like this:

dilcopy death_room@function(PULSE_SEC*60, 60,
"Flames shoot up from the floor burning your butt.");

Climb

The climb system uses exit flags to require players to use the climb command instead of normal movement.

To create a climbable exit:

1. Set the EX_CLIMB flag on the exit
2. Optionally add a $climb_<direction> extra to configure fall damage

When a player tries to walk normally through an EX_CLIMB exit, they are prompted to use the climb command instead. The climb command performs a skill check using SKI_CLIMB against ABIL_DEX. On failure, the player falls and takes damage.

Example:

up to hawk_nest descr "A rope dangles down from the crow's nest."
   keyword {"rope", "up"} open {EX_CLIMB};

extra {"$climb_up"} {10}
""

The integer value in the extra sets fall damage per 10 points of skill check failure. If no $climb_ extra is present, fall damage defaults to 5.

Chained Falls:

To make players fall through multiple rooms (like down a cliff face), set EX_FALL_THIS_WAY on exits. When a player fails a climb, they continue falling through each room that has this flag until reaching a room without it.

// cliff_top - climbable exit, fall continues down on failure
up to cliff_top open {EX_CLIMB};
down to cliff_mid open {EX_FALL_THIS_WAY};

// cliff_mid - falling continues through here
down to cliff_bottom open {EX_FALL_THIS_WAY};

// cliff_bottom - no EX_FALL_THIS_WAY, so falling stops here
down to cliff_base open;

In this example, a player who fails the climb at the top will tumble through cliff_mid and land at cliff_bottom, taking accumulated damage.

Force Move

This function allows you to move a player or NPC from a room to another room without having the player or NPC type or do anything.

The following is the definition of the force move DIL:

dilbegin force_move(tick: integer, strings: string, random: integer);

The ‘tick’ parameter is how fast you want the force move to be triggered. The ‘tick’ is in 1/4 second increments so to get a one second wait you would place a four. The second parameter is a single string containing the room and act separated by “!”: the part before “!” is the symbolic name of the room you are forcing the character to, and the part after “!” is the act shown to the player or NPC when moved. The final parameter is either a one or a zero. The one stands for true and it would make the timer trigger randomly fifty percent of the time, while a zero would make it not random.

The following is what the force move would look like if you wanted it to trigger every 30 seconds and give acts of a river:

dilcopy force_move@function(PULSE_SEC*30, "river2@riverzon!You float down the river.", 0);

Safe Room

This function creates a safe room where combat is not allowed. The following is the definition and an example of how to use it:

// Safe room DIL definition
dilbegin safe_room();

// Example use of Safe room
dilcopy safe_room@function();

A More Complex Set of Rooms

In the last section you learned to make basic rooms. In this section we will build on what you already know to allow you to make much more fancy rooms. In this section we will give a much better view of the exits and what can be done with them including doors, hidden doors and rooms inside other rooms. We will also show some examples of the room DIL functions being used that were described in the previous section. Finally we will pull it all together in a completed zone for you to compile and play with.

Exits with Doors

When we first defined exits we included the ‘keyword’ and ‘open’ fields on a door. In this section we will give an example of two rooms linked together with a door. There is no new information you have not already encountered so we will start with an example:

hallway
title "Module tunnel"
descr "The hallway is about 50 meters long and around 100 meters from
side to side and top to bottom...."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

west to chamber descr
"The hallway opens up into a chamber.";

east to office descr
"You see what looks to be an office."
keyword {"air lock door","air lock","door"}
open {EX_OPEN_CLOSE, EX_CLOSED};

end

office
title "The station office"
descr
"Large paintings fill the walls of this part of the station...."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

west to hallway descr
"You see what looks to be a hallway."
keyword {"air lock door","air lock","door"}
open {EX_OPEN_CLOSE, EX_CLOSED};
end

One important thing you should notice is, whatever you put as a keyword, along with the direction, is what a person must use to open the door. To make sure the door closes at reset time you will have to add the doors reset to the ‘%reset’ section. The door resets will be explained in the Reset Section chapter. Notice also in this example we have a direction both in the room you are going to and the room you came from. This means you need a ‘west’ direction for every ‘east’ direction leading to it. If you do not put both you will end up with a one way direction.

Locked Exits

Now that you have making a door down, you may find that it is not safe to leave your doors unlocked. Well the VME is ready for you. You have already seen the ‘keyword’ and ‘open’ sections and what you can set in them. Now let’s use the ‘EX_LOCKED’ field with them and the ‘difficulty’ field to set how hard the lock is to pick.

The difficulty field sets the skill difficulty (0-250) for picking the lock. If not specified, it defaults to 25. Higher values make the lock harder to pick.

Now let’s add the difficulty and the locked flag to the exits and create the room:

hallway
title "Module tunnel"
descr "The hallway is about 50 meters long and around 100 meters from
side to side and top to bottom...."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

west to chamber descr
"The hallway opens up into a chamber.";

east to office descr
"You see what looks to be an office."
keyword {"air lock door","air lock","door"}
key nokey
difficulty 50
open {EX_OPEN_CLOSE, EX_CLOSED, EX_LOCKED};

end

office
title "The station office"
descr
"Large paintings fill the walls of this part of the station...."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

west to hallway descr
"You see what looks to be a hallway."
keyword {"air lock door","air lock","door"}
key nokey
difficulty 50
open {EX_OPEN_CLOSE, EX_CLOSED, EX_LOCKED};
end

The only thing you may be wondering about in this example is the ‘key’ field. I have picked ‘nokey’ as my value of the key. There is no key in this zone so all this does is create a key hole. If you leave the ‘key’ field out totally the only way you can open the lock is by a magical spell. It is also important that you read about resets of door locks in the Reset Section chapter.

Hidden Exits

Locking the doors may not be enough. In fact sometimes you may not want to lock the door but you might want to hide it. You can do both or either by using the EX_HIDDEN flag and the difficulty field on the exit.

The difficulty field (0-250) sets how hard it is to find the hidden exit with the ‘search’ command. Higher values make it harder to find. If not specified, it defaults to 25.

Now let’s put it all together and link two rooms together with a hidden door:

office
title "The station office"
descr
"Large paintings fill the walls of this part of the station..."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

west to hallway descr
"You see what looks to be a hallway."
keyword {"air lock door","air lock","door"}
open {EX_OPEN_CLOSE, EX_CLOSED};

south to portal_room descr
"You see what looks to be a portal room."
keyword {"air lock door","air lock","staff","door"}
key nokey
difficulty 50
open {EX_OPEN_CLOSE, EX_CLOSED, EX_LOCKED, EX_HIDDEN};

end

portal_room
title "Green field room"
descr
"Like the other rooms on the station this one is large enough for
dragons to comfortably fit in.  The strange thing about this room though
is it is totally empty except for a green field right in the center.
there is a door that leads to another room to the north."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

north to office descr
"You see what looks to be an office."
keyword {"air lock door","air lock","door"}
key nokey
difficulty 50
open {EX_OPEN_CLOSE, EX_CLOSED, EX_LOCKED};

end

Rooms Inside of Rooms

Now that you have normal exits down it’s time to take a look at something a bit different. Let’s say you wanted to put a barrel in a room that is also a room that has exits to other rooms. Or maybe in my case I want to put a transporter pad in the room that is also a room so you can exit back into the room you came from. In the case of the teleporter I could use an object but as you will find it is much easier to deal with a room for this than an object.

To put a room in a room it is much different than using the normal exit fields. The only thing needed is the ‘in’ keyword and the room you are linking the current room into. There is no need for a semi-colon. The following is what the line would look like:

in <room that room is in>

Not too hard. The following are two rooms, one in the other:

portal_room
title "Green field room"
descr
"Like the other rooms on the station this one is large enough for
dragons to comfortably fit in.  The strange thing about this room though
is it is totally empty except for a green field right in the center.
there is a door that leads to another room to the north."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

extra {"green field","field"}
"The field looks to be a green fog shifting and churning as you watch.
if you are nuts you could probably enter it."

north to office descr
"You see what looks to be an office."
keyword {"air lock door","air lock","door"}
key nokey
open {EX_OPEN_CLOSE, EX_CLOSED,EX_LOCKED};

//A link to the portal is also here
end

room_port
names {"green field", "field"}
title "Green field"
descr
"Green Mist swirls about you."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

in portal_room
end

Note: After adding a room in a room you should note the room in the description or put an ‘outside_descr’ on the room inside it. In our example we have chosen to add the description into the room instead of using the ‘outside_descr’. Also doors and locks work the same way as before - you can even hide this exit.

A Room Using Force Move

Sometimes you will want to help players along their path. This could be for a river that flows strongly enough to force a player’s raft downstream or maybe for a room of quick sand that sucks the player into another room. In these situations we need to use the force move DIL, explained in the previous section. Here we have built two rooms linked only by a forced move:

portal_room
title "Green field room"
descr
"Like the other rooms on the station this one is large enough for
dragons to comfortably fit in.  The strange thing about this room though
is it is totally empty except for a green field right in the center.
there is a door that leads to another room to the north."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

extra {"green field","field"}
"The field looks to be a green fog shifting and churning as you watch.
if you are nuts you could probably enter it."

north to office descr
"You see what looks to be an office."
keyword {"air lock door","air lock","door"}
key nokey
open {EX_OPEN_CLOSE, EX_CLOSED,EX_LOCKED};

//A link to the portal is also here

end

ship_port
names {"green field", "field"}
title "Green field"
descr
"Green Mist swirls about you."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

in ship

dilcopy force_move@function(
//Time in ticks (PULSE_SEC*seconds), minimum 12 ticks (3 sec)
PULSE_SEC*4,
//room and act
"portal_room@dragonst!You feel your body dissolving for lack of a better
description.&nYou appear on the deck of a ship.",
//True or False for randomizing or not
FALSE);

end

A Death Room

As a final touch to our example zone, I want to create a room that will kill a player instantly. I will use the DIL function death_room and the room would simply look as follows:

deathspace
title "Open space"
descr
"You see the ship and the station far off in the distance and you are
in Space!"

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

dilcopy death_room@function (
//Time in ticks (PULSE_SEC*seconds), minimum 12 ticks (3 sec)
PULSE_SEC*4,
//damage
400,
//act for the damage.
"You realize too late that was the trash disposal transporter and you
feel your lungs explode.");

end

Putting the Rooms Together

Using all you have learned so far and putting it all together into one zone, you end up with a very interesting space station with some secret rooms and traps. The full zone all together looks like this:

#include <composed.h>
%zone dragonst
lifespan 20
reset RESET_ANYHOW
creators {"whistler"}

notes
"This is the dragon station I shortened it to dragonst for ease in
loading.  If you have any questions email me at admin@example.com"

help
"Not sure what could help you now.  You are stuck on one of the
weirdest space stations you have ever seen and you smell burning
sulfur."

%rooms

chamber
title "The middle chamber of the station"
descr
"This chamber seems to have the entire station rotating around it.  It is
unbelievably large the ceiling seems to be a good 200 meters high and
the room is perfectly cubic.  Small human size ornate chairs with dragon
designs scrawled on the arms and back are arranged in a triangle like
setting with one large chair at the front.  This must be where all
station meetings are held. Large pictures cover the walls depicting
dragons in all kinds of situations.  Large passages lead off to the west
and the east."

extra {"chairs","chair"}
"The chairs are made of some metal you don't recognize and every inch
is covered with some kind of dragon."

extra {"dragon picture","picture"}
"Thousands of dragons dot the skies of this rather life like picture.
In the center you see something move.  It looks to be a little green dragon."

extra {"green dragon","dragon","green"}
"An intelligent looking dragon is sitting perched on a large chair
watching you."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

west to disposal_room descr
"You see a small room.";

east to hallway descr
"You see what looks to be a hallway.";

end

hallway
title "Module tunnel"
descr "The hallway is about 50 meters long and around 100 meters from
side to side and top to bottom.  The hallway seems to be dust free.  The
walls and the floors seem to be made out of the same sterile
metal-plastic that all space agencies uses.  There are large plate glass
windows that open up into space.  The hallway is filled with a dim light
that seems to come from everywhere yet no where all at once.  You notice
a glimmer of bright light coming from the windows.  To the east you see
an air lock and to the west the hallway opens up into a larger room."

extra {"windows","window"}
"Your eyes are drawn to a large ship lit up with running lights sitting
about 1 kilometer from the station."

extra {"floor","walls","wall"}
"Well what can be said it looks to be in perfect condition.  What else
would you want to know?"

extra {"large ship" ,"ship"}
"The ship looks really big and is shaped like a dragon.  The scales
sparkle and seem to be multiple colors."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

west to chamber descr
"The hallway opens up into a chamber.";

east to office descr
"You see what looks to be an office."
keyword {"air lock door","air lock","door"}
open {EX_OPEN_CLOSE, EX_CLOSED};

end

office
title "The station office"
descr
"Large paintings fill the walls of this part of the station.  The room
is as large as the other rooms big enough for dragons to lounge while
still having a desk in one corner small enough for a humanoid.  The
floor along the north wall is lined with some kind of fabric and seems
very soft to walk on, it may be some kind of dragon lounge judging by
how large an area it covers.  There is a passage to the west."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

extra {"paintings","painting"}
"The paintings are of many dragons and riders in all kinds of tasks from
combat to look out.  All the figures seem to be staring at a staff
being held by a depiction of a wizard on the south wall."

extra {"wizard","staff"}
"The wizard has his hand stretched out and it seems there is a place
you can almost grab the staff. Maybe if you searched the staff you would
find it."

extra {"desk"}
"It's a desk alright but there doesn't seem to be any drawers and it
seems totally empty."

extra {"fabric"}
"Wussshhhhh you bound across the comfortable floor wasn't that fun."

west to hallway descr
"You see what looks to be a hallway."
keyword {"air lock door","air lock","door"}
open {EX_OPEN_CLOSE, EX_CLOSED};

south to portal_room descr
"You see what looks to be a portal room."
keyword {"air lock door","air lock","staff","door"}
key nokey
difficulty 50
open {EX_OPEN_CLOSE, EX_CLOSED, EX_LOCKED, EX_HIDDEN};

end

portal_room
title "Green field room"
descr
"Like the other rooms on the station this one is large enough for
dragons to comfortably fit in.  The strange thing about this room though
is it is totally empty except for a green field right in the center.
there is a door that leads to another room to the north."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

extra {"green field","field"}
"The field looks to be a green fog shifting and churning as you watch.
if you are nuts you could probably enter it."

north to office descr
"You see what looks to be an office."
keyword {"air lock door","air lock","door"}
key nokey
difficulty 50
open {EX_OPEN_CLOSE, EX_CLOSED, EX_LOCKED};

//A link to the portal is also here from room_port
end

ship_port
names {"green field", "field"}
title "Green field"
descr
"Green Mist swirls about you."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

in ship

dilcopy force_move@function(
//Time in ticks (PULSE_SEC*seconds), minimum 12 ticks (3 sec)
PULSE_SEC*4,
//room and act
"portal_room@dragonst!You feel your body dissolving for lack of a better
description.&nYou appear on the deck of a ship.",
//True or False for randomizing or not
FALSE);

end

room_port
names {"green field", "field"}
title "Green field"
descr
"Green Mist swirls about you."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

in portal_room

dilcopy force_move@function(
//Time in ticks (PULSE_SEC*seconds), minimum 12 ticks (3 sec)
PULSE_SEC*4,
//room and act
"ship@dragonst!You feel your body dissolving for lack of a better
description.&nYou appear on the deck of a ship.",
//True or False for randomizing or not
FALSE);

end

disposal_room
title "Red field room"
descr
"Like the other rooms on the station this one is large enough for
dragons to comfortably fit in.  The strange thing about this room though
is it is totally empty except for a red field right in the center.
there is a door that leads to another room to the east."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

extra {"red field","field"}
"The field looks to be a red fog shifting and churning as you watch.
if you are nuts you could probably enter it."

east to chamber descr
"You see the main chamber.";

//A link to the portal is also here from dis_port
end

dis_port
names {"red field","field"}
title "Red field"
descr
"Red Mist swirls about you."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

dilcopy force_move@function(
//Time in ticks (PULSE_SEC*seconds), minimum 12 ticks (3 sec)
PULSE_SEC*4,
//room to force move to and act
"deathspace@dragonst!You feel your body dissolving for lack of a better
description.",
//true or false random move or not
0);

in disposal_room

end

ship
title "War dragon"
descr
"Blue light softly glows from con duets that line the walls of this ship.
The floors beside the east and west wall have what looks to be soft
fabric covering.  The south wall has small controls that seem to be made
for humanoids with two small chairs that look to be pilot seats.  View
portals are about 50 meters up the side of the ship on the west and east
wall and some kind of electronic screen covers the south wall.  The ship
seems to be a one room ship but there is a green field by the north
wall."

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

extra {"view port"}
"Sorry you're not 50 meters tall maybe it is made for a dragon?"

extra {"view screen","screen"}
"It seems to be the pilots view screen but you can't seem to see a way
to turn it on."

extra {"controls","control"}
"The controls are in some weird language and you're afraid if you start
pushing buttons you might rocket in to the station or worse slam into
a planet."

extra {"soft fabric","fabric"}
"It looks to be a dragon lounge area."

//A link to the portal is also here from ship_port
end

deathspace
title "Open space"
descr
"You see the ship and the station far off in the distance and you are
in Space!"

movement SECT_INSIDE
ALWAYS_LIGHT
flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

dilcopy death_room@function (
//Time in ticks (PULSE_SEC*seconds), minimum 12 ticks (3 sec)
PULSE_SEC*4,
//damage
400,
//act for the damage.
"You realize too late that was the trash disposal transporter and you
feel your lungs explode.");

end

%end

Suggested Room Exercises

1. Create a door between the Disposal room and the main chamber of the station. Make the new door pick-proof and magic-proof.

2. Create another hallway to the south of the main chamber that leads to a ship attached by an airlock. You will need a door before the hallway and before the ship so no one gets sucked out in space. You will need two more rooms for this - one for the hallway and one for the ship.

3. Using the Dragon station zone as a guide, create your own zone with eight rooms. Don’t worry too much about descriptions and extras. Link all eight of the rooms to each of the other rooms. This means each room should have seven exits. If you were to map this it would look like a cube marked with ‘X’ on the sides.

4. Make a 3 room cliff that uses the climb DIL function to climb from the bottom to top.