AREA

Tank the Life Bringer at Dawn of Demise

(tdod.org 4000)

Most builders won't have access to these commands, but it's important for all builders to know the parameters needed to complete an area before it is installed.

You should be ready to supply the following information when your area is to be installed:

The name of the Area (Example: The Castle of Rasputin)

The suggested soft level range (Example: 20 - 40)

A suggested unique filename (Example: rasputin.are)

A resetmsg [70 char limit] (Example: Maniacal laughter echoes through the ancient castle.)

Your reset frquency (Newbie areas should reset faster than Avatar areas.)

We will use two commands in area setup:

ASTAT

ASET

ASTAT

Syntax: astat (area stats for the area you are in)

Syntax: astat <filename of area> (area stats for specified area)

Astat displays the vital stats of an area, including the following

Name: title of the area

Filename: filename of the area

Prototype: If the area is prototype or under construction, will be 'yes'

Max_players: max # of players in the area as of last reboot

IllegalPks: number of illegal pkills in the area since last reboot

Gold looted: total amount of gold looted from the area since last reboot

Area Economy: current pool of gold for the area (not including player gold)

Mdeaths: number of players mobs killed in the area since last reboot

Mkills: number of mobs killed in the area since last reboot

Pdeaths/Pkills: number of players killed by players in area since reboot

Author: name of the area's author

Number Players: current number of players in the area

Area flags: area-wide flags (such as nopkill)

Low/hi_room: first/last room vnum of the area

Low/hi_obj first/last object vnum of the area

Low/hi_mob first/last mob vnum of the area

Soft range: level range recommended for the area

Hard range: level range enforced for area (outside range cannot enter)

Resetmsg: current reset message for the area at repop

Reset frequency: frequency at which the area resets

ASET

Syntax: aset <filename of area> <field> <value>

Aset is used to set the following fields for an individual area:

Author, name, filename, lo_room, hi_room, lo_obj, hi_obj, lo_mob, hi_mob, low_economy, max_economy, softrange, hardrange, resetmsg, resetfrq, and flags.

Area Field Values

AUTHOR

Syntax: aset <filename of area> author <name/s of builder/s>

This sets the name of the builder or builders and will appear when a player types "areas"

NAME

Syntax: aset <filename of area> name <name of area>

This sets te name of the area as ir will appear when a player types "areas".

FILENAME

Syntax: aset <filename of area> filename

Sets the name of the area file. (ie: somearea.are)

LO_ROOM and HI_ROOM

Syntax: aset <filename of area> lo_room <lowest room vnum>

Syntax: aset <filename of area> hi_room <highest room vnum>

Sets the lowest and highest room vnums used by the area.

LO_OBJ and HI_OBJ

Syntax: aset <filename of area> lo_obj <lowest object vnum>

Syntax: aset <filename of area> hi_obj <highest object vnum>

Sets the lowest and highest object vnums used by the area.

LO_MOB and HI_MOB

Syntax: aset <filename of area> lo_mob <lowest mob vnum>

Syntax: aset <filename of area> hi_mob <highest mob vnum>

Sets the lowest and highest mobile vnums used by the area.

LOW_ECONOMY and MAX_ECONOMY

Syntax: aset <filename of area> low_economy <amount>

Syntax: aset <filename of area> max_economy <amount>

Sets the minimum and maximum amounts of gold an area will start with at reboot. Mobs will not repop with more gold than what they were originally created with, but if the area economy runs low they will begin to repop with less until the economy is replenished (as they all share the same gold pool).

LO_SOFT and HI_SOFT

Syntax: aset <filename of area> lo_soft <lowest level>

Syntax: aset <filename of area> hi_soft <highest level>

Sets the level range the area is intended for.

LO_HARD and HI_HARD

Syntax: aset <filename of area> lo_hard <lowest level>

Syntax: aset <filename of area> hi_hard <highest level>

Sets the enforced level range of the area. Players whose level is outside the range cannot enter the area.

RESETMSG

Syntax: aset <filename of area> resetmsg <reset message>

Sets the reset message players in the area see when the area resets. This message is limited to 70 characters.

[Default is "You hear some squeaking noises"]

RESETFRQ

Syntax: aset <filename of area> resetfrq <number of minutes>

Sets the number of minutes between area resets between area resets. [Default is 20]

FLAGS

Syntax: aset <filename of area> flags <flag>

Nopkill-no pkiller vs. Pkiller in this area

Freekill- Any player can kill any player (pkill or not) in this area with no consequences?

Noteleport- players cannot teleport, mistwalk, astralwalk, or spiral into or out of this area.

Text Editing Smaug 1.4 Area Files

An area is one piece of the world. Each area is defined in a separate file. All of our area files have the extension '.are', but you can call your area files anything you want.

All of our areas may be freely distributed, as long as the internal notices (such as those on plaques, signs, graffiti, or tombstones) are kept. If you write new areas, and would like to contribute them back to DoD, just e-mail to one of the addresses above. As you can see from typing 'areas' in the game, we credit the original authors whenever we can find them.

Sections of an Area

An area file contains the following sections:

#AREA

#VERSION

#AUTHOR

#RANGES

#RESETMSG

#FLAGS

#ECONOMY

#CLIMATE

#HELPS

#MOBILES

#OBJECTS

#ROOMS

#RESETS

#SHOPS

#REPAIRS

#SPECIALS

An area is a collection of sections starting with #AREA until the next #AREA.

All of our area files (except 'help.are') contain just one #AREA section, which is at the top of the file.

Data Types

All of the data in an area file (even the section headers) consists of a series of values. Each value has a specific type. The server parses the file by reading in data values one at a time according to the types it expects.

Blank characters (spaces, tabs, new lines, carriage returns) at the beginning of a data value are always ignored (this includes strings). Thus, you can format the area files whatever way suits your taste and your needs.

The individual types are: 'letter', 'word', 'string', 'number', and 'to_eol'.

A 'letter' is a single non-blank character.

A 'word' is a sequence of non-blank characters terminated by a blank.

A 'string' is a seqence of non-tilde characters terminated by a tilde. A tilde is this character: '~'. Thus, strings may contain blanks, and may be multiple lines long. There is no limit on the length of an individual string; however, all strings go into a common memory pool whose size is fixed when the server is compiled.

The components need not be powers of 2. This feature is extremely useful for defining bit vectors, such as the ACT_* and AFF_* bits for mobiles, but is not restricted to bit vectors: any number may use the '|' construction.

A 'to_eol' is all the characters from the current position to the end of the current input line. It is used for parsing comments at the ends of lines.

In the syntax description below, <value:type> indicates a value to be read of the indicated type. A backslash '\' indicates that the file format itself has only one line, but several lines are used in this description to fit within 80 columns.

Braces '{}' are used to enclose elements. They are NOT literal parts of the file format, but a way of indicating that the enclosed elements may be repeated zero or more times. Braces at the same level of indentation indicate that the parallel elements may be present in any order.

All other characters in the syntax description are literal characters.

Mobiles, objects, and rooms are identified by vnum (virtual number). Vnums do not have to be in increasing order.

Typically an area uses the same range of vnum's for mobile vnum's, object vnum's, and room vnum's, starting with a multiple of 100. This facilitates adding the area into an existing set of areas.

=== The #AREA section

The syntax of this section is:

#AREA <area-name:string>

The 'area-name' can be any string. The 'areas' command provides a list of

areas, so it's worth while to follow the standard Merc format for this string:

#AREA { 5 35} Merc Prototype for New Area~

The first two numbers are recommended level range. The name is the name of the

original author of the area. The last phrase is the name of the area.

=== The #HELPS section

The syntax of this section is:

#HELPS

{

<level:number> <keywords:string>

<help-text:string>

}

0 $~

The 'level' number is the minimum character level needed to read this section.

This allows for immortal-only help text.

The 'keywords' are a set of keywords for this help text.

The 'help-text' is the help text itself.

Normally when a player uses 'help', both the keywords and the help-text are

shown. If the 'level' is negative, however, the keywords are suppressed. This

allows the help file mechanism to be used for certain other commands, such as

the initial 'greetings' text.

If a 'help-text' begins with a leading '.', the leading '.' is stripped off.

This provides for an escape mechanism from the usual leading-blank stripping of

strings, so that picturesque greeting screens may be used.

=== The #MOBILES section

The syntax of this section is:

#MOBILES

{

#<vnum:number>

<keywords:string>

<short-description:string>

<long-description:string>

<description:string>

<act-flags:number> <affected-flags:number> <alignment:number> S

<level:number> <hitroll:number> <armor:number> \

<hitnodice:number> d <hitsizedice:number> + <hitplus:number> \

<damnodice:number> d <damsizedice:number> + <damroll:number>

<gold:number> <exp:number>

<position:number> <position:number> <sex:number>

}

The 'vnum' is the virtual number of the mobile.

The 'keywords' are words which can be used in commands to identify the mobile.

The 'short-description' is the description used by the 'act' function and other

functions to identify the mobile.

The 'long-description' is the description used when a character walks in the

room and the mobile is visible.

The 'description' is the longest description. It is used when a character

explicitly looks at the mobile.

The 'act-flags' define how the mobile acts, and the 'affected-flags' define

more attributes of the mobile.

The 'alignment' of the mobile ranges from -1000 to +1000. Keep in mind that

certain spells ('protection' and 'dispel evil') give characters fighting evil

monsters an advantage, and that experience earned is influenced by alignment.

The literal letter 'S' must be present after the alignment. In the original

Diku mob format, 'S' stands for simple. Merc supports only simple mobs, so the

'S' is redundant. It is retained not only for compatibility with the Diku

format, but also because it helps the server report errors more accurately.

The 'level' is typically a number from 1 to 35, although there is no upper

limit.

The 'hitroll', 'armor', 'hitnodice, 'hitsizedice', 'hitplus', 'damnodice',

'damsizedice', 'damroll', 'gold', 'exp', 'position', and 'position' fields are

present for compatibility with original Diku mud, but their values are ignored.

Merc generates these values internally based on the level of the mobile.

The 'sex' value may be 0 for neutral, 1 for male, and 2 for female.

=== The #OBJECTS section

The syntax of this section is:

#OBJECTS

{

#<vnum:number>

<keywords:string>

<short-description:string>

<long-description:string>

<action-description:string>

<item-type:number> <extra-flags:number> <wear-flags:number>

<value-0:number> <value-1:number> <value-2:number> <value-3:number>

<weight:number> <cost:number> <cost-per-day:number>

{

<keyword:string>

<description:string>

}

{

<apply-type:number> <apply-value:number>

}

The 'vnum' is the virtual number of the object.

The 'keywords' are words which can be used in commands to identify the object.

The 'short-description' is the description used by the 'act' function and other

functions to identify the object. The first character of the short-description

should be lower case, because this description is used in the middle of

sentences.

The 'long-description' is the description used when a character walks in the

room and the object is visible.

The 'action-description' is not used.

The 'item-type' is the type of the item (weapon, armor, potion, et cetera).

The 'extra-flags' describe more attributes of the object. The 'wear-flags'

describe whether the item can be picked up, and if so, what bodily locations

can wear it.

The interpretation of the four 'value' numbers depends upon the type of the

object. Interpretations are given below.

The 'weight' of the object is just that.

'Cost' and 'cost-per-day' are ignored. 'Cost' is generated internally based on

the level of the object. Because Merc has no rent, 'cost-per-day' is

completely ignored.

The optional 'E' sections and 'A' sections come after the main data.

An 'E' section ('extra description') contains a keyword-list and a string

associated with those keywords. This description string is used when a

character looks at a word on the keyword list.

An 'A' section ('apply') contains an apply-type and an apply-value. When a

character uses this object as equipment (holds, wields, or wears it), then

the value of 'apply-value' is added to the character attribute identified by

'apply-type'. Not all 'apply-types' are implemented; you have to read the

function 'affect_modify' in handler.c to see exactly which ones are.

An object may have an unlimited number of 'E' and 'A' sections.

=== The #ROOMS section

The syntax of this section is:

#ROOMS

{

#<vnum:number>

<name:string>

<description:string>

<area:number> <room-flags:number> <sector-type:number>

{

D <door:number>

<description:string>

<keywords:string>

<locks:number> <key:number> <to_room:number>

}

{

<keywords:string>

<description:string>

}

The 'vnum' is the virtual number of the room.

The 'name' is the name of the room.

The 'description' is the long multi-line description of the room.

The 'area' is obsolete and unused. Rooms belong to whatever area was most

recently defined with #AREA.

The 'room-flags' describe more attributes of the room.

The 'sector-type' identifies the type of terrain. This affects movement cost

through the room. Certain sector types (air and boat) require special

capabilities to enter.

Unlike mobiles and objects, rooms don't have any keywords associated with them.

One may not manipulate a room in the same way one manipulates a mobile or

object.

The optional 'D' sections and 'E' sections come after the main data. A 'D'

section contains a 'door' in the range from 0 to 5:

0 north

1 east

2 south

3 west

4 up

5 down

A 'D' command also contains a 'description' for that direction, and 'keywords'

for manipulating the door. 'Doors' include not just real door, but any kind of

exit from the room. The 'locks' value is 0 for an unhindered exit, 1 for a

door, and 2 for a pick-proof door. The 'key' value is the vnum of an object

which locks and unlocks the door. Lastly, 'to_room' is the vnum of the room to

which this door leads.

You must specify two 'D' sections, one for each side of the door. If you

specify just one then you'll get a one-way exit.

An 'E' section (extended description) contains a 'keywords' string and a

'description' string. As you might guess, looking at one of the words in

'keywords' yields the 'description' string.

The 'S' at the end marks the end of the room. It is not optional.

=== The #RESETS section

The syntax of this section is:

#RESETS

{

* <comment:to_eol>

}

{

M <:number> <mob-vnum:number> <limit:number> <room-vnum:number> \

<comment:to_eol>

}

{

O <:number> <obj-vnum:number> <:number> <room-vnum:number> \

<comment:to_eol>

}

{

P <:number> <obj-vnum:number> <:number> <obj-vnum:number> \

<comment:to_eol>

}

{

G <:number> <obj-vnum:number> <:number> \

<comment:to_eol>

}

{

E <:number> <obj-vnum:number> <:number> <wear_loc:number> \

<comment:to_eol>

}

{

D <:number> <room-vnum:number> <door:number> <state:number> \

<comment:to_eol>

}

{

R <:number> <room-vnum:number> <last-door:number> \

<comment:to_eol>

}

To reset an area, the server executes each command in the list of reset

commands once. Each area is reset once when the server loads, and again

periodically as it ages. An area is reset if it is at least 3 area-minutes old

and is empty of players, or if it is 15 area-minutes old. At the 14

area-minute mark, each (awake) player in the area is warned of the impending

reset. These values are coded into the function 'reset_area' in 'db.c'.

An 'area-minute' varies between 30 and 90 seconds of real time, with an

average of 60 seconds. The variation defeats area timekeepers.

The 'resets' section contains a series of single lines. The backslashes and

line splitting above are for readability; they are not part of the file format.

Because of the end-of-line comments, this section is not as free-format as

other sections.

The reset commands are:

* comment

M read a mobile

O read an object

P put object in object

G give object to mobile

E equip object to mobile

D set state of door

R randomize room exits

S stop (end of list)

The '*' lines contain comments. The 'S' line is the last line of the section.

Every other command contains four numbers (three for the 'G' command). The

first number is ignored. The next three (or two) numbers are interpreted as

follows:

For the 'M' command, the second number is the vnum of a mobile to load. The

third number is the limit of how many of this mobile may be present in the

world. The fourth number is the vnum of the room where the mobile is loaded.

For the 'O', 'P', 'G', and 'E' commands, the second number is the vnum of an

object to load. The third number is ignored.

For the 'O' command, the fourth number is the vnum of the room where the object

is loaded. The object is not loaded if the target room already contains any

objects with this vnum. The object is also not loaded if any players are

present in the area.

For the 'P' command, the fourth number is the vnum of a container object where

the object will be loaded. The actual container used is the most recently

loaded object with the right vnum; for best results, there should be only one

such container in the world. The object is not loaded if no container object

exists, or if someone is carrying it, or if it already contains one of the

to-be-loaded object.

For the 'G' command, there is no fourth number. If the most recent 'M' command

succeeded (e.g. the mobile limit wasn't exceeded), the object is given to that

mobile. If the most recent 'M' command failed (due to hitting mobile limit),

then the object is not loaded.

For the 'E' command, the fourth number is an equipment location. If the most

recent 'M' command succeeded, that mobile is equipped with the object. If the

most recent 'M' command failed, then the object is not loaded.

All objects have a level limit, which is computed by inheritance from the most

recently read 'M' command (whether it succeeded or not) in 'area_update' in

'db.c'. As distributed, an object's level equals the mobile level minus 2,

clipped to the range 0 to 35.

For the 'D' command, the second number is the vnum of a room. The third number

is a door number from 0 to 5. The fourth number indicates how to set the door:

0 for open and unlocked; 1 for closed and unlocked; 2 for closed and locked.

Room exits must be coherent: if room 1 has an exit to room 2, and room 2 has an

exit in the reverse direction, that exit must go back to room 1. This doesn't

prevent one-way exits; room 2 doesn't HAVE to have an exit in the reverse

direction.

For the 'R' command, the second number is the vnum of a room. The third number

is a door number. When this command, the doors from 0 to the indicated door

number are shuffled. The room will still have the same exits leading to the

same other rooms as before, but the directions will be different. Thus, a door

number of 4 makes a two-dimensional maze room; a door number of 6 makes a

three-dimensional maze room.

Use of both the 'D' and 'R' commands on the same room will yield unpredicatable

results.

Any line (except an 'S' line) may have a comment at the end.

=== The #SHOPS section

The syntax of this section is:

#SHOPS

{

<keeper:number> \

<trade-0:number> <trade-1:number> <trade-2:number> \

<trade-3:number> <trade-4:number> \

<profit-buy:number> <profit-sell:number> \

<open-hour:number> <close-hour:number> \

<comment:to_eol>

}

Like the #RESETS section, the #SHOPS section has one command per line.

The 'keeper' is the vnum of the mobile who is the shopkeeper. All mobiles

with that vnum will be shopkeepers.

The 'trade-0' through 'trade-5' numbers are item types which the shopkeeper

will buy. Unused slots should have a '0' in them; for instance, a shopkeeper

who doesn't buy anything would have five zeroes.

The 'profit-buy' number is a markup for players buying the item, in percentage

points. 100 is nominal price; 150 is 50% markup, and so on. The 'profit-sell'

number is a markdown for players selling the item, in percentage points.

100 is nominal price; 75 is a 25% markdown, and so on. The buying markup

should be at least 100, and the selling markdown should be at most 100.

The 'open-hour' and 'close-hour' numbers define the hours when the shopkeeper

will do business. For a 24-hour shop, these numbers would be 0 and 23.

Everything beyond 'close-hour' to the end of the line is taken to be a comment.

Note that there is no room number for a shop. Just load the shopkeeper mobile

into the room of your choice, and make it a sentinel. Or, for a roving

shopkeeper, just make it non-sentinel.

The objects a shopkeeper sells are exactly those loaded by 'G' reset commands

for that shopkeeper. These items replenish automatically. If a player sells

an object to a shopkeeper, the shopkeeper will keep it for resale if he, she,

or it doesn't already have an identical object. These items do not replenish.

=== The #SPECIALS section

The syntax of this section is:

#SPECIALS

{

* <comment_to_eol>

}

{

M <mob-vnum:number> <spec-fun:word> <comment:to_eol>

}

Like the #RESETS section, the #SPECIALS section has one command per line.

This section defines special functions (spec-fun's) for mobiles. A spec-fun

is a C function which gives additional behavior to all mobiles with a given

vnum, such as the peripatetic mayor or the beholder casting spells in combat.

See 'special.c' for a list of available spec-fun's.

The 'M' command assigns 'spec-fun' to all mobiles of with virtual number

'mob-vnum'. All spec-fun's are assigned by name. An 'M' line may have a

comment at the end.

Every three seconds, the server function 'mobile_update' examines every mobile

in the game. If the mobile has an associated spec-fun, then 'mobile_update'

calls that spec-fun with a single parameter, the 'ch' pointer for that mob.

The spec-fun returns TRUE if the mobile did something, or FALSE if it did not.

If the spec-fun returns TRUE, then further activity by that mobile is

suppressed.

CREDITS

I really thank Herne the Hunter for the original help files that I used to create my own help.

Special thanks to Tank, the original author of this document.

All samples and tips have been provided by myself, and other members of the mudding community. If you have any samples or tips you would like to contribute, please send them to minex@tdod.org .

If you would like credit please state the name you want credited, a link to a webpage , email, a mud where you build, and/or its telnet address. You may use any combination you desire. Samples and tips without this information will be listed as anonymous.