<html>
<head>
<title>Mud Administrator Information</title>
<link rel="stylesheet" type="text/css" href="doc.css"
title="Documentation Standard Style">
</head>
<body bgcolor="#ffffff">
<table class="main" width="600" border="0">
<tr><td>
<div align="right">
DalekenMUD 1.12 documentation.
<br>Updated 7 June 2000.
<br>Based on original Envy 2.2 documentation.
</div>
</td></tr>
<tr><th class="heading">
<h1>Mud Administrator Information</h1>
</th></tr>
<tr><td>
<p>This file contains information that once existed in area.txt. It does not
contain any information on dealing with players and immortals, most
information on that would be subject to gross prejudice, refer to links,
newsgroups for information that may or may not be pertinent.</p>
</td></tr>
<tr><th class="heading">
<h2>Booting and Testing Areas</h2>
</th></tr>
<tr><td>
<p>When the Daleken server starts, it reads a file named
<code>AREA.LST</code> in the current directory. This file contains a list of
all the area files to read in. To add or delete areas, simply edit
<code>AREA.LST</code>.</p>
<p>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).</p>
<p>You can test areas by running Daleken in a different directory with a
different <code>AREA.LST</code> 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: <code>../bin/daleken</code>, for example.</p>
<p>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.</p>
<p>The server also reports semantic errors, such as references to non-existent
mobiles, objects, or rooms.</p>
<p>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. Envy takes only a few
seconds to load, however, so it's quite practical to use the whole server as
a syntax checker. This shouldn't be necessary if you use the server's
builtin building tools to create areas, this way you don't even have to learn
the file format!</p>
</td></tr>
<tr><th class="heading">
<h2>Compressing the Area Files</h2>
</th></tr>
<tr><td>
<p>It is possible to run Daleken with a single combined, compressed area file.
I would not suggest this if you intend to use any of the features of
Daleken's online building, this is made impossible by the following
procedure, and anyhow, disk space is cheap, you lose any benefits fo space
saving when it takes quadruple the time to load.</p>
<p>Here's how to do this on a Unix system:
<ol>
<li>In <code>AREA.LST</code>, remove the last line (the <code>$</code> line).</li>
<li>Execute the command:
<blockquote><code>
cat `cat AREA.LST` | gzip -9 > all_area.gz
</code></blockquote></li>
<li>Edit <code>AREA.LST</code> again. Insert a <code>-</code> at the
beginning of every line. Do not put any spaces between the
<code>-</code> and the file name. Put the last <code>$</code> line back
at the end of the file.</li>
<li>Edit 'startup'. Change the line:
<blockquote><code>
../src/envy 4000 >&! $logfile
</code></blockquote>
to:
<blockquote><code>
gzcat all_area.gz | ../src/envy 4000 >&! $logfile
</code></blockquote></li>
<li>Test the changes so far. Daleken should start up normally, although it
may take a few seconds longer to gzcat everything.</li>
Now you can remove all the original *.are files.</p>
<p>Notice that all of the compression and decompression takes place outside of the
server. Thus, you can substitute any archiving program of your choice, as
long as it can write its output to standard output (look for bzip2, it
compresses like crazy).</p>
<p>You can recover the original areas simply by running 'uncompress all_area.Z'
and dissecting them out of all_area.</p>
<p>From the server's point of view, when an area file name starts with
<code>-</code>, it simply reads standard input for the area, terminating at
<code>@END</code> as usual (but without closing standard input). Diagnostic
messages are given with the full name (e.g. <code>-arachnos.are</code>), but
the line number will be reported as zero.</p>
<p>You can freely mix areas from standard input with ordinary area files.
Thus, you could compress all the standard zones into a file such as
envy_area.gz, prefixing them with <code>-</code> in <code>AREA.LST</code>.
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.</p>
<p>The server will take a little longer to load with compressed area files,
because gzcat 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.</p>
</td></tr>
<tr><th class="heading">
<h2>Memory Usage</h2>
</th></tr>
<tr><td>
<p>In order to simplify the code, the DalekenMud server has a fixed maximum
size on strings in the area database. This size is defined at the beginning
of <code>ssm.c</code>. As distributed, this size is:
<blockquote><code>
#define MAX_CHUNKS 27
</code></blockquote></p>
<p>This size is about 6% (100k) larger than needed for the areas we
distribute. Thus, you can add about 2 more areas without touching the server
at all. The server will tell you when the string table overflows, and you
can simply increase the maximum limit and recompile. Any memory overflow is
handled by SSM and will not adversely affect the game, although it does slow
the game down marginally.</p>
<p>The immortal <code>memory</code> command will show you memory usage from
within the game. Memory overflow will be noted using the <code>memory</code>
command.</p>
<p>There is no other limit on area sizes or memory usage.</p>
<p>We decided to use a fixed size because it simplifies our job. It also allows
significant performance improvements: compare our load time and memory usage
versus other Diku muds with the same quantity of areas.</p>
</td></tr>
</table>
</body>
</html>
