The Directory Structure

File Types

The Nightmare Object Library makes use of the following kinds of files:

Configuration files Extensions: .cfg (sometimes no extension)

These are special files used by Nightmare objects to configure certain mud systems. One example is "/secure/cfg/groups.cfg" which the master object ("/secure/daemon/master") uses to determine who is in which group.

Object Persistence Files Extensions: .o (sometimes no extension)

These files store state information about LPC objects. They are used by the mud to preserve an object across time. For example, the persistence files in "/secure/save/players" save information about player objects across logins.

LPC Source Files Extensions: .c, .C, and .h

These files provide the LPC code that makes up the objects on the mud. Mud objects are named based on their file name minus the .c or .C extension. Note that .C extensions, for LPC->C support, are not currently supported by the Nightmare Object Library.

Because object names are based on the file names from which they came (with the exception of virtual objects), security is based on an object's name, and thus security is intimately tied to the directory structure of the mudlib.

The Two Directory Trees

Nightmare uses two directory trees which basically mirror each other:

• The /secure directory structure
• The / (root) directory structure

The /secure directory structure contains files which are secure configuration files, object persistence files, and LPC source code files for high security systems. A high security system is either an LPC object which needs access to secure files or files which should be protected from modification except for by the most trusted objects. Nightmare defines a trusted object as one having SECURE group membership. See the security documentation for more details on the Nightmare security system.

The root directory structure exists for objects that have lesser security requirements. The actual security for a given directory in the root directory tree can vary from the lowest security protection level ("/realms") to a moderately high security protection level ("/lib"). The objects created from the root directory structure generally have minimal priveledges.

Inside the Trees

Each tree has subdirectories under them which mirror each other. Each tree, for example, has the following subdirectories:

cfg/

Configuration files

cmds/

The LPC source files for simple commands

daemon/

The LPC source files for special shared mud objects

include/

The LPC source files for global header files

lib/

The LPC source files for mudlib inheritables

obj/

The LPC source files object instances in common use by all areas

save/

Object persistence files

tmp/

Miscellaneous temporary storage

verbs/

The LPC source files for the parser system verb objects

Other Directories

Each tree has a few directories which are not mirrored in the other tree. The reason for this is simply that the nature of that directory's contents imply security or lack thereof. For example, a secure "/realms" (creator home directories) makes no sense. Similarly, insecure simul efun files make no sense. Below is a brief description of each of these oddball directories.

Secure Directories

/secure/sefun/

The LPC source files for the simul efun object

Root Directories

/doc/

Textual documentation for the mud and the mudlib

/domains/

The configuration files, documentation, object persistence files, and LPC source files for domains owned by the mud. This is distinguished from "/realms" which is made up of files owned by individual creators.

/log/

Output from various logging systems in the mudlib

/news/

Various news displayed to different types of users based on membership in given groups.

/realms/

See the "/domains" descrption

/shadows/

The LPC source files for approved shadow objects

/www/

The HTML documents for the mud's HTTP daemon