=== 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>
}#0

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>
{ E <keyword:string> <description:string> }
{ A <apply-type:number> <apply-value:number> }
} #0

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> }
{ E <keywords:string> <description:string> }
S } #0

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

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

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

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.

To add a new special function:

(1) Add a DECLARE_SPEC_FUN line to the top of 'special.c'.

(2) Add a line for translating the ascii name of the function into a function pointer to the function 'spec_lookup' in 'special.c'.

(3) Write the spec-fun and add it to 'special.c'. Note that Merc special functions take a single parameter, rather than the three parameters of Diku. If you have an Ansi C compiler, you're protected against accidental mismatches.

(4) Assign the spec-fun by writing an appropriate line into the #SPECIALS section in an area file. Any number of mobs may have the same spec-fun.

=== The #$ section

The syntax of this section is:

#$

This section marks the end of an area file. If you concatenate several area files into one, remember to delete the terminating '#$' from all but the last file. Conversely, if you split area files, remember to terminate each new file with a '#$'.

=== Meaning of Value Numbers by Item Type

In the values below, 'sn' is a spell, indexed by slot number. A zero or negative sn means 'no spell'.

01 ITEM_LIGHT value[0] unused value[1] unused value[2] hours of light available, 0 is dead, -1 is infinite value[3] unused

02 ITEM_SCROLL value[0] level value[1] sn 1 value[2] sn 2 value[3] sn 3

03 ITEM_WAND value[0] level value[1] max charges value[2] current charges value[3] sn

04 ITEM_STAFF value[0] level value[1] max charges value[2] current charges value[3] sn

08 ITEM_TREASURE value[0] unused value[1] unused value[2] unused value[3] unused

09 ITEM_ARMOR value[0] unused value[1] unused value[2] unused value[3] unused

10 ITEM_POTION value[0] level value[1] sn 1 value[2] sn 2 value[3] sn 3

12 ITEM_FURNITURE value[0] unused value[1] unused value[2] unused value[3] unused

13 ITEM_TRASH value[0] unused value[1] unused value[2] unused value[3] unused

15 ITEM_CONTAINER value[0] weight capacity value[1] flags: 1 closeable, 2 pickproof, 4 closed, 8 locked value[2] key vnum value[3] unused

17 ITEM_DRINK_CON value[0] capacity value[1] current quantity value[2] liquid number (see 'liq_table' in const.c) value[3] if non-zero, drink is poisoned

18 ITEM_KEY value[0] unused value[1] unused value[2] unused value[3] unused

19 ITEM_FOOD value[0] hours of food value value[1] unused value[2] unused value[3] if non-zero, food is poisoned

20 ITEM_MONEY value[0] value in gold pieces value[1] unused value[2] unused value[3] unused

22 ITEM_BOAT value[0] unused value[1] unused value[2] unused value[3] unused

23 ITEM_CORPSE_NPC value[0] unused value[1] unused value[2] unused value[3] unused

24 ITEM_CORPSE_PC value[0] unused value[1] unused value[2] unused value[3] unused

25 ITEM_FOUNTAIN value[0] unused value[1] unused value[2] unused value[3] unused

26 ITEM_PILL value[0] level value[1] sn 1 value[2] sn 2 value[3] sn 3

=== Slot Numbers

These slot numbers are used in magical objects to indicate spells. Save files do not use slot numbers; they use names instead. Spells having slot "0" require a server code change for valid slot assignment before they can be used.

=== MobPrograms

See MProg Docs
See MProg Examples

#MOBPROGS
#{Vnum}
{program_command_1} NL
{program_command_2} NL
{program_command_3} NL
. . . {program_command_N} NL "~" NL . . .
#0