lpmoo-1.2/etc/
lpmoo-1.2/mudlib/
lpmoo-1.2/mudlib/etc/
lpmoo-1.2/mudlib/include/
lpmoo-1.2/mudlib/include/moo/
lpmoo-1.2/mudlib/lpc/
lpmoo-1.2/mudlib/std/auto/
lpmoo-1.2/mudlib/std/bfuns/
Troubleshooting
===============

Problem: Bootstrapping fails with an "Array too large" error
--------

  - If you're running under an AIX system, verify that the following lines
    exist in the GENERIC_SYSV section (NOT the MINIX_68K section) of
    dgd/src/host.h:

    # define UCHAR(c)  ((char) (c))                   /* unsigned character */
    # define SCHAR(c)  ((((char) (c)) - 128) ^ -128)  /* signed character */

    These are needed for AIX, where characters are by default unsigned.

  - If you're not running AIX, please send me email describing your system
    configuration.

Problem: The server won't accept any network connections
--------

  - If you've enabled the `mport_listening' option in moo.cf, the server
    will NOT automatically open and listen on any network ports. Your
    database is expected to do this itself via the listen() builtin,
    typically from the #0:server_started verb.

    To use the mport_listening feature, first disable it and start the
    server. Connect and modify #0:server_started as described in the
    documentation for the listen() function. Shutdown, re-enable
    mport_listening, and restart.

Problem: Bootstrapping fails with a "String index out of range" error
--------

  - Your database might be missing newline characters, perhaps with
    carriage returns marking the ends of lines instead. Try this:

        tr '\015' '\012' < your.db > new.db

    Now try bootstrapping with new.db; if this still fails, you probably
    have some very obtuse end-of-line characters, and further coercion
    may be necessary.

  - Don't give the command: make bootstrap db=etc/moo.db; you should NOT
    copy your database to etc/moo.db. Instead, give the path to your
    existing database (elsewhere) and it will be linked automatically.

Problem: Running LPMOO reports "Fatal error: cannot inherit /std/auto"
--------

  - This can happen if an error occurs during compilation of DGD.
    Restarting the compilation might have left an empty file in
    dgd/src/lpc. Remove the empty file and recompile, or simply:

        cd dgd/src/lpc
        make clean
        cd ..
        make install

Problem: LPMOO dies and etc/dgd.log says "Fatal error: too small dynamic_chunk"
--------

  - You have a structure in your database which requires a large amount
    of memory to swap in. Increase the value of the `dynamic_chunk'
    option in etc/dgd.cf by increments of 524288 (0.5MB) and restart.

Problem: LPMOO reports an internal error
--------

  - If the error is "Array index out of range", it probably means the
    MOO value stack is too small. Try increasing the `stack_size' option
    in the moo.cf file and restarting.

  - Any other error is almost certainly a problem with the simulation,
    and I'd appreciate hearing about it.

Problem: The system response time is slow
--------

  - You can increase response time by reducing the number of objects being
    swapped out every second. The `swap_fragment' option in the etc/dgd.cf
    configuration file specifies what fraction of all objects to swap out.
    For example, a value of 32 means that 1/32 of all objects are swapped
    out every second.

    By making this value larger, you decrease the number of objects forced
    to be swapped out each second, and therefore increase normal response
    time. Good values to try would be 64 or 128. Note, however, that fewer
    objects swapped out means the process will use more memory.

Problem: LPMOO uses too much memory
--------

  - You can change DGD to be more aggressive at swapping out unused objects
    to disk, thereby reducing the overall process size. The `swap_fragment'
    option in the etc/dgd.cf configuration file specifies what fraction of
    all objects to swap out each second. For example, a value of 32 means
    that 1/32 of all objects are swapped out every second.

    By making this value smaller, you force more objects to be swapped out
    each second. Note, however, that the more time DGD spends swapping
    objects out to disk (and later back in), the slower its perceived
    response time will be.

Problem: DGD reports a fatal error
--------

  - You might not have the `mudlib' directory correctly set in the dgd.cf
    file. The pathname must be absolute.

  - Possibly you have run out of disk space. Besides room for two state
    dump files (one as a backup), you also need room for the swap file.

  - Another possibility is that an option in the dgd.cf file needs to be
    tweaked. Depending on the problem, you may need to increase the
    swap_size, static_chunk, or dynamic_chunk sizes. If you have a large
    number of objects or verbs, you may need to increase the `objects'
    table size value.

There are certainly other problems that could occur; please let me know of any
you encounter so I can add them to this list.

Robert Leslie
rob@ccs.neu.edu