-
Notifications
You must be signed in to change notification settings - Fork 3
Administration
When the Envy 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 Envy 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/envy', 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. Envy takes only a few seconds to load, however, so it's quite practical to use the whole server as a syntax checker.
It is possible to run Envy 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/envy 4000 >&! $logfile
to:
zcat all_area.Z | ../src/envy 4000 >&! $logfile
(5) Test the changes so far. Envy 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 Envy 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 Envy standard zones into a file such as envy_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.
In order to simplify the code, the EnvyMud server has a fixed maximum size on strings in the area database. This size is defined at the beginning of 'db.c' 'db.c' with a '#define' statement. As distributed, this size is:
#define MAX_STRING 1600000
This size is about 10% larger than needed for the areas we distribute. Thus, you can add about 4 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. The immortal 'memory' command will show you memory usage from within the game.
There is no other limit on area sizes or memory usage.
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.