SMAUG Release 1.4
Monday June 12, 1995
Thoric thoric@realms.game.org
=== Overview of Areas
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.
Because each area is defined in one file, it is easy to incorporate new areas
into SMAUG, or to send SMAUG areas to others for use.
=== Sections of an Area
An area file contains the following sections:
#AREA
#HELPS
#MOBILES
#OBJECTS
#ROOMS
#RESETS
#SHOPS
#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.
The file 'proto.are' contains a prototype for developing new area files.
Each of the sections contains its own format. For #MOBILES, #OBJECTS, #ROOMS,
and #RESETS, this format is upward compatible with the original Diku formats
for tinyworld.mob, tinyworld.obj, tinyworld.wld, and tinyworld.zon,
respectively. The #HELPS, #SHOPS, and #SPECIALS sections have new formats.
=== 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.
A 'number' is a decimal number with an optional leading '-' or '+'. The '|'
character may be used in any number: '1|64|1048576' has the value 1048641. The
individual values separated by '|' are added together, so '5|6' is 11, not 7.
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.
The file 'mud.h' lists the meanings of most of the flags and values. The
section useful to area builders is set off by big comments; you can't miss it.
The file 'const.c' contains the spell list with slot numbers, and the file
'special.c' contains the list of special procedures.
Mobiles, objects, and rooms are identified by vnum (virtual number). The range
of vnum's is 1 to 32767. Vnum's must be unique (for that particular kind of
vnum). 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 SMAUG format for this string:
#AREA { 5 35} SMAUG 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 or C
<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>
--- These lines only for C type mobs
<str int wis dex con cha lck:number>
<sav1 sav2 sav3 sav4 sav5:number>
<race class height weight speaks speaking numattacks:number>
<hitroll damroll xflas res imm sus attacks defenses: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. SMAUG supports simple mobs, as well
special complex mobs ('C').
The 'level' is typically a number from 1 to 100, although there is no upper
limit.
The 'hitroll', 'armor', 'hitnodice, 'hitsizedice', 'hitplus', 'damnodice',
'damsizedice', 'damroll' fields are used, but will be auto-generated if they
are set to zero ( 0d0+0 ). This is to remain in compatibility with original
Merc mud areas.
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>
<value0 value1 value2 value3 value4 value5: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 SMAUG 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 room-flags sector-type:number> (optional: teledelay televnum)
{
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.
The 'teledelay' specifies an optional delay to teleport everyone out of the
room and into the room specified by 'televnum'.
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
6 northeast
7 northwest
8 southeast
9 southwest
10 somewhere
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>
}
{
H <:number> <obj-vnum:number> <: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>
}
{
T <flags> <types> <charges> <vnum: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 70 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
T trap an object or room/door
H hide an object
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.
For the 'T' command, the first number is a the combination of all flags
wanted on the trap. The second number is the type of trap, the third number
is the number of charges, and the fourth number is the VNUM of either the
OBJECT the trap is on, or the ROOM the trap is in, (for room and door traps).
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 SMAUG 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
05 ITEM_WEAPON
value[0] condition
value[1] number dice v1 and v2 are optional and will be
value[2] size dice autogenerated if set to 0
value[3] weapon type:
01 slice
02 stab
03 slash
04 whip
05 claw
06 blast
07 pound
08 crush
09 grep???
10 bite
11 pierce
12 suction
08 ITEM_TREASURE
value[0] (treasure type)
value[1] (condition)
value[2] unused
value[3] unused
09 ITEM_ARMOR
value[0] AC adjust/current condition
value[1] Original AC
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] durability
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] (condition)
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
44 ITEM_TRAP
value[0] charges
value[1] type
value[2] level
value[3] flags
=== Slot Numbers
These slot numbers are used in magical objects to indicate spells. Save files
do not use slot numbers; they use names instead.
0 NULL
70 acid blast
1 armor
90 astral walk
3 bless
4 blindness
5 burning hands
6 call lightning
63 cause critical
62 cause light
64 cause serious
82 change sex
7 charm person
8 chill touch
10 colour spray
57 continual light
11 control weather
85 create fire
12 create food
80 create spring
13 create water
14 cure blindness
15 cure critical
16 cure light
43 cure poison
61 cure serious
17 curse
18 detect evil
44 detect hidden
19 detect invis
20 detect magic
21 detect poison
86 detect trap
22 dispel evil
59 dispel magic
23 earthquake
24 enchant weapon
25 energy drain
72 faerie fire
73 faerie fog
26 fireball
88 fireshield
65 flamestrike
56 fly
83 gate
39 giant strength
27 harm
28 heal
53 identify
77 infravision
29 invis
58 know alignment
30 lightning bolt
31 locate object
32 magic missile
69 mass invis
74 pass door
33 poison
34 protection
81 refresh
35 remove curse
87 remove trap
36 sanctuary
91 scry
67 shield
37 shocking grasp
89 shockshield
38 sleep
66 stone skin
40 summon
2 teleport
41 ventriloquate
68 weaken
42 word of recall
200 acid breath
201 fire breath
202 frost breath
203 gas breath
204 lightning breath
=== Booting and Testing Areas
When the SMAUG server starts, it reads a file named 'area.lst' in the current
directory. This file contains a list of all the area files to read in. To add
or delete areas, simply edit area.lst.
The server reads all of the area files into memory once at load time and then
closes them. Thus you can edit area files while the server is running.
Changes will take effect the next time the server boots. Because the server is
completely memory-based, zone resets are fast, too. (And paradoxically, moving
to a memory-based system allowed certain memory optimizations to be made,
cutting memory usage by 50% from Merc 1.0).
You can test areas by running SMAUG in a different directory with a different
'area.lst' file with new areas dropped into it. Setting up an appropriate
directory structure is an exercise for the student. (You DID say you're
running a mud because you wanted to learn more about system administration,
right?) Hint: you can run a program in another directory just by invoking its
full name: '../src/mud', for example.
The server reports syntax errors, including the area file name and a line
number. Take the line number with a grain of salt; some kinds of errors cause
the server to run on for quite a few lines before ultimately detecting the
error.
The server also reports semantic errors, such as references to non-existent
mobiles, objects, or rooms.
Error recovery is simply not possible without far more sophisticated input
parsing than we're willing to write. (Hey, feel free to write your own.)
Thus the server exits after reporting any error. SMAUG takes only a few seconds
to load, however, so it's quite practical to use the whole server as a syntax
checker.
=== Compressing the Area Files
It is possible to run SMAUG with a single combined, compressed area file.
Here's how to do this on a Unix system:
(1) In 'area.lst', remove the last line (the '$' line).
(2) Execute the command:
cat `cat area.lst` | compress > all_area.Z
(3) Edit 'area.lst' again. Insert a '-' at the beginning of every line.
Do not put any spaces between the '-' and the file name. Put the last
'$' line back at the end of the file.
(4) Edit 'startup'. Change the line:
../src/mud $port >&! $logfile
to:
zcat all_area.Z | ../src/mud $port >&! $logfile
(5) Test the changes so far. SMAUG should start up normally, although it
may take a few seconds longer to zcat everything.
Now you can remove all the original *.are files.
Notice that all of the compression and decompression takes place outside of the
SMAUG server. Thus, you can substitute any archiving program of your choice, as
long as it can write its output to standard output.
You can recover the original areas simply by running 'uncompress all_area.Z'
and dissecting them out of all_area.
From the server's point of view, when an area file name starts with '-', it
simply reads standard input for the area, terminating at '#$' as usual (but
without closing standard input). Diagnostic messages are given with the full
name (e.g. '-arachnos.are'), but the line number will be reported as zero.
You can freely mix areas from standard input with ordinary area files. Thus,
you could compress all the SMAUG standard zones into a file such as smaug_area.Z,
prefixing them with '-' in 'area.lst'. Then you could add your own areas
anywhere in the file (beginning, middle, end, wherever your areas need to go),
and omit the '-' on the lines for your areas.
The server will take a little longer to load with compressed area files,
because 'zcat' needs time to run. This is offset by a reduction in time spent
opening disk files. After loading, the server has all of the area database in
memory and never rereads the files. Thus, there is zero performance impact
on server operation after loading.