/
mudd/docs/html/
mudd/world/
******************************************************************************
* Locke's   __ -based on merc v2.2-____        NIM Server Software           *
* ___ ___  (__)__    __ __   __ ___| G| v4.0   Version 4.0 GOLD EDITION      *
* |  /   \  __|  \__/  |  | |  |     O|        documentation release         *
* |       ||  |        |  \_|  | ()  L|        Hallow's Eve 1999             *
* |    |  ||  |  |__|  |       |     D|                                      *
* |____|__|___|__|  |__|\___/__|______|        http://www.nimud.org/nimud    *
*   n a m e l e s s i n c a r n a t e          dedicated to chris cool       *
******************************************************************************

Setting up a new NiMUD Server
-----------------------------

Setting up a *CUSTOM* Nimud server is as easy as these five steps:



Step one:    Read this file and all other docs
------------------------------------------------------------------------------

Now, I know no one does any of this.  That's fine and dandy, but I am trying
to avoid any foolish questions that could be easily answered by reading
the docs!  RTFM is not a new term, people, but it does stand in defiance
of the human ability to avoid documentation.

The files included are real important!  They tell you how to do the most
common, basic things to get you started on your way to NIMUD administration.



Step two:    Unpack and place your NIM Server files
------------------------------------------------------------------------------

NIM Server files have a very specific directory structure.

Root                      contains the all important readme.1st file
 |
  ->   src                contains all source files (.c, .h & makefiles)
 |      |
 |       ->  game         contains necessary data files for the msdos version
 |
  ->   docs               these files (documentation!!)
 |
  ->   area               area files for unix versions
 |
  ->   player             player files for unix versions, required guest chars
 |
  ->   log                log files for unix versions

Make sure to unpack the .ZIP or .TAR file with the original pathnames,
which include the correct pathnames for each file.  You can move the
files to another root directory, but the paths need to remain inclusive.



Step three:  Test your NiMUD before modification
------------------------------------------------------------------------------

Once you've got your nimud files unpacked from their .ZIP format, or .TAR'd
version if you're that savvy, then you can begin the process of the first
build -- this is the most important build because it determines if NiMUD
will easily work on your machine.

NiMUD has only been tested by me on the following machines:

 * 386 or greater Intel-compatible Processor running
   DJ Delorie's GNU C Compiler on MSDOS

 * Unix/Linux machines that have new versions of gcc or cc
   (specifically, RedHat Linux, Solaris, Andrew Unix and older Linux boxes)

NiMUD may work on the following machines, using guidelines for compiling
version 2.0c/2.2b of Merc/DIKU Mud software:

   Macintosh
   Ultrix
   FreeBSD
   AIX

Choose your makefile carefully -- it makes or breaks the process quite
easily.  There are five default makefiles that come with this software.

Those are:  (in /src/ dir)

   makefile          -  standard makefile for dos and unix systems
   makefile.dos      -  specifically for DJGPP compiling on MSDOS
   makefile.isles    -  specifically for use on RedHat Linux, but may work
                        on other unix machines
   makefile.grok     -  grokmud's makefile for unix/linux
   makefile.nim      -  specifically for compiling nimud on unix systems

The best makefiles are the first three, the other two only work on certain
systems.  Try makefile.isles first for unix, and makefile.dos for ms-dos.

If you are able to build the .o files and compile an executable or a.out
file, run the software!  If it compiles, most likely the program will
run with little problems.

The startup files are for unix boxes that want to keep the service running
from reboot to reboot.

Those are:  (in /src/ dir)

   startup           -  startup script that works for the Isles (redhat)
   startup.save      -  original nimud startup script from v1.6 with
                        file names changed



Step four:   Build or code!
------------------------------------------------------------------------------

You are not given any areas with these later versions of NiMUD.  This means
you are forced to create your own!  This can be a lengthy process.  If you
are interested in compiling and using this code locally, you can build
areas and submit them to theisles@nimud.org -- we will post the area files
on our web site, and credit you as the author.  We can even link your own
home page through!

The area files are in a text format and can be manually modified if you
need to make changes (such as changes that cause the mud to crash on boot).

If you are starting a brand new mud, immediately read liscense.doc

If you've already done this, then you should be prepared to acquire
help or do the work of building yourself.  There are many resources
available for the proliferation of mud administration -- if you need
help you will be able to find it.  NiMUD-specific information is included
in this documentation, and in the online help provided while exploring
the mud.

Included in the documentation directory is a directory called /doc/html
This is the "Penultimate Builder's Guide to the Isles" and includes the
most recent immortal reference information you will need to get started.

Development of the code can commence under the liscensing agreement found
in liscense.doc



Step five:   Debug!
------------------------------------------------------------------------------

There are many bugs inherent in developing MUD software.  NiMUD is not a
bug free package and contains many features that are only partially
implemented, or are somewhat buggy.

It also contains many features that are NOT buggy and are WELL implemented.

The code is fairly well commented and, I hope, clear to read and digest.

In many cases I have taken the time to develop code that is asthetically
consistent and contains important comments.  I am sure there are some
other comments remaining from the heyday of my mudding career -- the
days when I would drink so much Iced-Tea and sit up all night coding
the hell out of the software, age 14.

Please think twice before asking a question -- the answer may be right
in front of you, but if there is a problem, mail us at theisles@nimud.org


         -Locke
          theisles@nimud.org