FAQ Index

Is this FAQ really necessary? (Back to Top)

Normally, no. If you just follow the instructions included in the Dead Souls packages, you'll be fine 90% of the time. However, a non-trivial number of folks have run into difficult circumstances. For those folks, this document is meant to illuminate how the install process works, why some things are as they are, and suggest some solutions to the more common obstacles.

Where do I get Dead Souls? (Back to Top)

You should only ever download from the site listed below. Some other sites tend to mirror these or copy data, then fail to update their data regularly. The following will always have the most recent versions.

Download the stable version from the following:


Download the latest alpha version here:


The alpha version often has lots of neat new stuff. Some of the new stuff is still not 100% production quality. If new features that are still under development are upsetting to you, you may be better off using the "stable" version instead.


Where are the separate UNIX and Windows versions? (Back to Top)

Starting in Dead Souls 2.0r22 the two separate versions have been merged into one distribution download file. Now it doesn't matter whether you want to use Dead Souls on Windows or UNIX, there's just one file to download, and it contains everything you need for both operating systems.

This merge accomplishes the following:

Where do I get patches? (Back to Top)

Patches are deprecated in favor of liveupgrade. For exceptional situations, however, or for very old muds that still need them, they are here:

Should I apply the available patches during an install? (Back to Top)

No. Patches are for already-installed Dead Souls muds. A new Dead Souls install does not need and must not use patches. If you're upgrading from one Dead Souls version to another, please read the upgrade section further down in this document.

How do I install Dead Souls in Windows? (Back to Top)

NOTE: If you are using Windows, USE THESE INSTRUCTIONS. There is no benefit in trying to download Cygwin and modify the UNIX source code and trying to get it to compile in Windows, unless you know exactly what you're doing. Yes, people have tried to do this and complained.

First make sure you are running Windows NT 4, Windows 2000 or above, Then:

  1. unzip the distribution file
  2. move and rename it so that it is c:\ds, and that the folders c:\ds\win32 and c:\ds\lib are where the binary and library files are, respectively.
  3. run c:\ds\runmud.bat
  4. if you lack a favorite telnet client, open a command line window by clicking on Start->Run... and entering: cmd
  5. connect to your Windows computer by telnetting to port 6666. If you are using the command window, type: telnet localhost 6666
  6. Enter the name you want your admin to have, and answer the questions provided. Make sure you are the first person to log in, because that first person is automatically made admin.
  7. When you finish entering the admin's info, the mud will automatically reboot.
  8. log in as your admin character.
  9. change your mud's name with the admintool command. Navigate to the "driver" menu (as of this writing, it's option 4, and then the "change the MUD's name" option (as of this writing, it's option r). Enter the name desired, allow the mud to shut down.
  10. log in again after the mud reboots.
  11. Start reading the guide and the handbook and the manual.


Migrating from Windows to UNIX fails horribly (Back to Top)

The main problem you're likely running into is that Windows and UNIX handle text files differently. In particular, object persistence files (.o files) saved under Windows may have additional characters that the UNIX driver won't tolerate.  The  UNIX command "dos2unix" might help...or it might not. You might need to use the .o files from the default distribution (sadly losing whatever was in your old ones).

It may also be that your Windows driver is much older than the driver for the UNIX version you're migrating to. It might be a good idea to hunt down the source code for the specific lib release you're using (for example, 2.1.1) and compile that for your driver.

The short and sad answer is that such a migration can go wrong in so many ways that it's beyond the scope of help this document, or I as maintainer, can provide.


Hold up, these Windows instructions aren't working (Back to Top)

There are a few common reasons for this.

How do I install Dead Souls in a Linux/UNIX box? (Back to Top)

I'm having trouble getting Dead Souls for UNIX to work (Back to Top)

          Then edit lib/secure/cfg/mudos.cfg to point to the correct bin and lib directories.

Why does compiling the driver for Dead Souls throw so many warnings? (Back to Top)

Beats me. This is one of those complaints I don't really know how to respond to. At the end of the compile, you'll have a driver that works. It's been tested on GCC 2, 3, and 4. It's worked for Fedora Linux, SuSE Linux, and various other versions of UNIX and UNIX-clone environments. It works. Ignore the compile schmutz.

Why is there a windows-format mudos.cfg in /secure/cfg? I'm running unix. (Back to Top)

This is a symptom of my obsession to have the Windows lib and the unix lib be absolutely identical. During a fresh install, this file is overwritten with a unix version, if you follow the install instructions.

How do I enable database support? (Back to Top)

I don't know. I don't understand databases at all, so it's pointless for me to try to get that driver functionality working. If you develop a procedure for it, please share it with me and I will document it so others can benefit from your leetness. I might suggest that it's probably easier to do this using LPC sockets in the lib, rather than trying to do it using driver-level support. If you don't know what that means, you'll need to play around with Dead Souls for a while, get the hang of it, and then revisit the question.

How do I upgrade from one version of Dead Souls to another? (Back to Top)

Patches used to be provided, but this was a cumbersome and tedious process. There is now a liveupgrade command for painless upgrading.

The upgrade for both Windows and UNIX is the same. Basically a Dead Souls liveupgrade is a pretty unsophisticated system. It just copies over new files over old files.

Obviously, this kind of updating is intended for muds that do not do extensive lib system rewrites. For example, if your mud creation has been limited to individual home directories and the domains/ directories, then an upgrade should be mostly painless.

On the other hand, if you've done extensive customizing of the player object, simulated efun subsystem, daemons, and so forth, then you may run into problems after an update. The typical update patch does include some changes to the player object, for example, so the indiscriminate overwriting of the previous information with the updated files means that your work basically disappears.

For this reason it is critical always to perform a full backup of all your mud files before implementing a patch upgrade. Carefully follow the instructions included in the liveupgrade command to ensure optimal effect. Because these instructions are not expected to be static, the details will not be included in this document. Read the /doc/RELEASE_NOTES file to know what has changed between releases and to determine whether an upgrade is worth the risk. Please note that RELEASE_NOTES contains an overview of major changes. It does not document every difference between versions.


How do I compile a 64 bit driver?

Assuming you are using a 64-bit AMD processor and running a 64-bit OS on it, you can enable the compilation of a 64-bit driver by editing fluffos*/build.FluffOS and changing:

ENABLE_M64=0

to

ENABLE_M64=1

Then re-do the compile with:

make distclean
./configure
make install

If this fails, you are probably either not running a 64-bit AMD processor, or not running a 64-bit OS on it.

When I log out after starting the mud, problems happen. (Back to Top)

If you're running a modern UNIX, you have two main options for running the mud in a "backgrounded" way that survives your logout.

nohup

The first is the nohup command. This is a sort of legacy command from modem days, but it does the job of keeping processes running even if there's no terminal attached. To use nohup in this way, your commands might be something like this:

cd /usr/games/ds/bin
nohup ./driver ./mudos.cfg  1>/dev/null 2>/dev/null &

The /dev/null redirects output to a null device. If you don't do this, nohup will save all stdout/stderr output to a file, and this may fill up diskspace more quickly than you expect, so make sure to use the /dev/null redirecton to avoid this problem.

If your startmud script has been correctly edited (it's important that it have the correct MUDHOME directory specified, in this case, "/usr/games/ds"),  then the command lines might be:

cd /usr/games/bin
nohup ./startmud 1>/dev/null 2>/dev/null &

The advantage to using the startmud script is that if you shutdown the mud from inside the game, it will automatically restart. The disadvantage is that you need to log into the shell and kill the script if you want to actually shut down the mud and keep it down. A potential risk when using startmud is that if you have not edited it correctly, or if there is a problem with the mud, you may have the script fire off a continuous loop of trying to restart the mud. Not only is this ugly to look at and inconvenient until fixed, it may also anger the person who runs the computer you're doing this on, as it may chew up resources. So, if you use the startmud script, *make sure it works* before running it in background mode with nohup.

In at least one case, using nohup this was did not work for someone. I never received a clear explanation of why this was, but for them, the following technique worked.

screen

This command ought to be default in any UNIX anywhere, but alas, it sometimes is not. If it's not available on your system, you can try to download the source from here: ftp://ftp.gnu.org/gnu/screen/

What this program does is let you run console applications in a virtual terminal, so that you can detach from the terminal, work on something else, then reattach to resume the program already in progress. Rather than pausing it, screen just runs whatever it is in a sort of backgrounded way. Way cool. In the following example, I refer to the "Ctrl" key like this: <Ctrl> . When you need to press That key and another key in combination, the notation I use looks like this: <Ctrl>-a, which means "hold down the 'Ctrl' key, and then press the 'A' key".

To run Dead Souls in a screen session, it might look like this:

cd /usr/games/ds
screen -S deadsouls
./startmud
<Ctrl>-a
d

You may wonder what that 'd' is doing all by itself there. What <Ctrl>-a does is tell your screen session to pay attention to the next key you press, because that is a screen action it needs to take. In this case, the key is 'd', which means "detach". When in a screen session, if you type <Ctrl>-a then d, you drop out of the screen session and resume whatever terminal you were in before you invoked screen. Your application will be happily chugging along in the virtual console you left behind. To reconnect to the screen session you detached from, the command would look like this:

screen -r deadsouls

The full grooviness of the screen command is beyond the scope of this FAQ. For more info on it, at the UNIX shell type: man screen

Microsoft Windows

If you're running Windows, then you'll need to figure out how to make Dead Souls run as a service. One way is to download and use these scripts contributed by Saquivor @ Eternal Souls.
Another is to mess around with your windows services and do it manually. Unfortunately, I am not a Windows server person, so you'll need to search Google for the appropriate docs.


I put the mud in a Linux startup script, but it won't start when I reboot!

An apparent peculiarity of Fedora is that if the command line specified in your start script
doesn't redirect stderr and stdout to /dev/null, the program fails to run. Also, if you don't
properly background it, you may end up hanging the computer and preventing anything
else from running.


Therefore, in your start script, your command line should have redirection and backgrounding.
It might look something like this:

 /mud/ds/bin/startmud > /dev/null 2>&1 &

Other recent Linux distributions may have the same quirk.


Ok, it's running. Now what? (Back to Top)

Log in and read the following:

The End (Back to Top)

Return to Dead Souls Homepage

Last Updated December 2007