Manual:Zone Manual The Room Section

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 (Link to ch-03) first. This chapter will deal with all the fields of rooms what they are and how to use them but with out 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 (Link to rmfields) shows a full listing of all the room fields and their types as defined in (Link to ch-03).

Room fields and types listing

Field	Type	Field	Type
symbolic name	Symbol	manipulate	Integer
names	Stringlist	alignment	Integer
title	String	flags	Integer
descr	String	weight	Integer
outside_descr	String	capacity	Integer
extra	Structure	light	Integer
minv	Integer	exit	Structure
key	string	movement	Integer
spell	Integer	end	Symbol
dilbegin or dilcopy	Function pointer

As you can see there is 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 (Link to rmfielddescr) 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 (Link to ch-03), 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.

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 weather 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 thrown room"
names {"thrown room","thrown"}

descr

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

outside_descr

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.

movement

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.

Sector movement values

Symbol	Name	Endurance Cost
SECT_INSIDE	inside	1
SECT_CITY	city	1
SECT_FIELD	field	2
SECT_FOREST	forest	3
SECT_HILLS	hills	4
SECT_MOUNTAIN	mountain	6
SECT_DESERT	desert	8
SECT_SWAMP	swamp	8
SECT_WATER_SWIM	water-swim	4
SECT_WATER_SAIL	water-sail	50
SECT_UNDER_WATER	under-water	8
SECT_SNOW	snow	8
SECT_SLUSH	slush	6
SECT_ICE	ice	10

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.

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. Extras can also be used to create special room flags.

Room unit flag affects

Flag	Description
UNIT_FL_PRIVATE	When 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_INVISIBLE	Makes unit invisible
UNIT_FL_NO_BURY	Makes a hard floor so items can't be buried.
UNIT_FL_BURIED	Makes unit buried when loaded
UNIT_FL_NO_TELEPORT	makes unit so no one can teleport to it
UNIT_FL_NO_MOB	Makes it so no mobile will enter the unit
UNIT_FL_NO_WEATHER	keeps weather and natural light out of unit
UNIT_FL_INDOORS	Makes unit inside and doesn't affect weather
UNIT_FL_TRANS	Makes unit transparent
UNIT_FL_NO_SAVE	Makes it so you can't save with unit
UNIT_FL_SACRED	Makes unit a double gain unit
UNIT_FL_MAGIC	Marks a unit to be magic

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"}
"Its 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 lets 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.

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:

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

exit <directions>

Is the direction the exit leads, ie. 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, post pend the name with @<zone name>

 to myotherroom
 to hisotherroom@hiszone</nowiki>

open <info flags>

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

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 clocked 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();

EX_PICK_PROOF

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

EX_HIDDEN

If this bit is set, the exit is hidden until the mobile 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</nowiki>

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 can search for.

 keyword {"wooden door","door"}
 keyword {"hidden door","door","hatch","floor"}</nowiki>

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.

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

key

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.

manipulate

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.

alignment

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.

weight

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.

capacity

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.

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.

Light defines

Define	Light Value	Affect
ALWAYS_LIGHT	1	Room is always light no matter time of day
IN_ALWAYS_DARK
When an inside room is always dark - both inside and outside
OUT_DARK_NON_NOON
Always a dark room, except when it is high noon
OUT_ALWAYS_DARK
Always 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 your 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.

link

spell

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;

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. In this function it 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 (Link to rmdilfunc). Then we put some to work so you can see how to use them in (Link to rmcomplex)

Previous: Unit Building Blocks

Next: Building your first room