How to Deal with Some Common Installation Problems


If you're not using Bundled Phantasmal, then most of the problems in
here are because you didn't follow the instructions in INSTALL
correctly -- or you didn't follow them at all.  Have you followed the
instructions in INSTALL, and followed them carefully and correctly?



Q: I try to run DGD, but I get things that look like this:

     Error within runtime_error:
     Compilation within compilation
     Compilation within compilation
     Config error: initialization failed

A: You probably haven't copied the Kernel Library into the kernel
directory of Phantasmal.  Make sure that's done and try again.  For
specifics, check the README in the kernel directory.  Also, you have
to do all the stuff described in the INSTALL document before anything
works.  You did already, right?



Q: I try to run DGD, but I get things that look like this:

     /kernel/sys/driver.c, 1: cannot include "kernel/kernel.h"
     /kernel/sys/driver.c, 2: cannot include "kernel/objreg.h"
     /kernel/sys/driver.c, 3: cannot include "kernel/rsrc.h"
     /kernel/sys/driver.c, 4: cannot include "kernel/access.h"
     /kernel/sys/driver.c, 5: cannot include "kernel/user.h"
     /kernel/sys/driver.c, 6: cannot include "kernel/tls.h"
     Error within runtime_error:
     Compilation within compilation
     Compilation within compilation
     Config error: initialization failed

A: You copied the Kernel Library into the right place, but forgot to
put its headers into the include/kernel directory.  Make sure that's
done correctly and try again.



Q: I run DGD and things look good except that there's no game.  What gives?

A: This is a MUD server.  You'll need to connect to it with a telnet
client on an appropriate port.  Are you already familiar with the
process?  If not, you may find you're more comfortable trying out
CircleMUD or another fully developed MUD.  Phantasmal is definitely
intended for the experienced crowd, and so are all other existing DGD
mudlibs.  We're working on it...



Q: I run DGD and it gives me error messages about the version I'm using.
   What do I do?

A: It may say that this version of Phantasmal is not tested with DGD
beyond version 1.2.blah.  If so, then you've got a slightly old
Phantasmal or Felix has gotten ahead of me with his constant
improvement of DGD.  You could use the DGD version that Phantasmal
recommends -- look at /usr/System/initd.c for the version check.  Or
if things keep working you can just ignore the error message, or
remove it from /usr/System/initd.c.  Or you could see if there's a
newer version of Phantasmal, which should be happier with newer
versions of DGD.

If it gives you a startup error that your version of DGD just isn't
good enough for it then you're going to need to upgrade to a later
version of DGD, a recent experimental one.  Check out
"http://phantasmal.sourceforge.net/DGD" and click on a link called
something like "Downloading, Compiling and Configuring DGD".  It'll
tell you how to install an experimental version of DGD.



Q: I upgrade from one version of DGD (or even just the Kernel Library)
to the next one and everybody except admin stops being a wizard!  What
gives?

A: The Kernel Library stores its listing of who gets wizard privileges
in the file "kernel/data/access.data".  If you delete this then
everybody loses all their privileges.  One way to deal with it is to
manually reinstate everybody (call the %grant command for all of them
again).  Another is to grab the file from your old copy of DGD and
restore it.

If you copy the kernel Library stuff to where it should be rather than
symbolically linking it, and you copy the new Kernel Library *over*
the old version, you won't get this problem (unless you overwrite the
old access.data with the new one, and then you're *really* hosed
unless you have a backup).  That approach comes with its own set of
problems, including potential incompatibilities between future
versions of DGD.  Hey, it could happen.



Q: I run DGD and on startup or shutdown I get a Fatal Error that
says "out of sectors".  How come?

A: To run Phantasmal, you must have a phantasmal.dgd file somewhere.
Usually it's in the mudlib directory.  In it, if you look hard, you'll
find there's a swap_size parameter, probably set to 1024 by default.
Try increasing this number.  Now see if you still get the Fatal Error.

There's a way to detect this problem *before* it bites you.  Type
%status at the command line of your MUD as an admin.  In the upper
left of the text display, under "Swap device", you'll see a "sectors"
entry.  The "sectors" entry shows you how many sectors your MUD uses
and how many it *can* use.  You can also check out memory usage and
number of objects.  The numbers tell you how close you are to
exceeding your allowed usage of various resources.  You may also find
that as you come close to the limit in them, it takes more ticks to do
things.  If this happens then you may run out of ticks before you run
out of other resources (like sectors).  When the numbers get too close
together (if you're using 2015 sectors out of 2048, for instance),
you'll want to increase the upper limit in the phantasmal.dgd file.

This stuff all works the same for any MUD based on the Kernel Library,
so the DGD mailing list is a good place to ask about what the numbers
mean and how you can play with them.



Q: I'm running DGD and when I try to do a %datadump or a shutdown, I
   run out of ticks, so it doesn't finish.  It can't even shut down!

A: Please see the previous question.


Q: I'm using the CVS version of DGD on Windows I get the following
error during startup:

$ ./dgd mud.dgd
Jun 16 10:52:30 ** DGD 1.2.47
Jun 16 10:52:30 ** Initializing...
Can't parse UNQ data passed to unq_dtd:load!
Config error: initialization failed

The system log has the following errors:

/usr/System/sys/errord(unset) ||| Sun Jun 16 10:52:33 2002 / 0.03 [6]
--> Runtime error: Rule 2: bad token [caught]
[...]
/usr/common/obj/basic_unq_parser(unset) ||| Sun Jun 16 10:52:33 2002 / 0.03 [6]
--> Error parsing block: ~DTD{
~channel{name,level}
~name{string}
~level{int}
}
[...]
--> Runtime error: Can't parse UNQ data passed to unq_dtd:load!

A: This could mean that you're using the native Win32 version of CVS
rather than the Cygwin version of CVS.  It appears to convert line
endings to Win32-style or otherwise cause problems for reasons that
aren't entirely clear.  Use a Unix workstation rather than Windows.
Or use the Cygwin version of CVS.  Or convert all your line endings
after checkout from carriage returns to carriage-return/linefeed
pairs.  The last solution may not work if you're doing SourceForge
development for Phantasmal -- it's vitally important that you never
check in anything to SourceForge Phantasmal that has Win32 line endings.



Q: When I start DGD, Phantasmal seems to start fine, but when I telnet
   in I can't log on!

A: There is a bug in DGD versions before 1.2.57 which causes
Phantasmal to hang for a while on start up.  Please upgrade to DGD
version 1.2.57 or higher.  Or just wait awhile every time you start
Phantasmal up again.




Q: I can log into Phantasmal by telnetting to localhost on the correct
port, but if I try from another machine it won't let me!

A: Your machine almost certainly has a firewall.  Any recent version
of Linux, for instance, comes with this automatically.  Even Windows
does once you've got WinXP Service Pack 2 or the equivalent working.
You'll need to edit the configuration files for your firewall to let
you log into whatever port Phantasmal is running on.  You can find
Phantasmal's port numbers in phantasmal.dgd, but you'll need to check
the documentation for your firewall or Operating System to figure out
how to change the firewall.



Q: People on my local network can log into Phantasmal, but people far
away can't!

A: Your network administrator almost certainly runs a firewall.
Whatever port you're using for Phantasmal isn't being allowed through,
which isn't surprising.  Firewalls are often used on school or
workplace networks specifically to stop unauthorized,
possibly-insecure servers like MUDs from working.  If you're setting
up Phantasmal for some authorized purpose then talk to your network
administrator about letting requests through on the appropriate port.
If you're *not* running it with appropriate permission, you'll need to
either figure out how to defeat the firewall, or hang your head in
shame.

Or you could run your MUD on a machine that's not at your school or
place of work.  Getting some kind of broadband at home would work, as
would using a professional MUD hosting or colocation service.  Any of
those will probably cost money, though.