diff --git a/changelog b/changelog
index fa54bd2..2185ee4 100644
--- a/changelog
+++ b/changelog
@@ -1,10 +1,16 @@
TbaMUD is currently being developed by The Builder Academy. If you need any
-help, find any bugs, or have ideas for improvement please stop by TBA.
-Rumble
-The Builder Academy
-builderacademy.net 9091
+help, find any bugs, or have ideas for improvement please stop by TBA at
+telnet://tbamud.com:9091 or email rumble@tbamud.com --Rumble
tbaMUD 3.55
+[Jan 17 2008] - Rumble
+ Updated files for 3.55 release.
+ Updated documentation in the /doc directory.
+[Jan 16 2008] - Rumble
+ New content management system (drupal) at http://tbamud.com. Forums, blogs, etc. (thanks Mordecai)
+ Converted all of /doc pdf's back to text files. PDF versions will be on http://tbamud.com
+ Updated tell m-w command due to html changes. (thanks Welcor)
+ Renamed lib/text/help/screen and iscreen files to help and ihelp.
[Jan 06 2008] - Rumble
Removed break in oedit_disp_val1_menu ITEM_NOTE that caused a delay. (thanks Rhade)
Fixed tlist when specifying a range. (thanks Rhade)
@@ -27,6 +33,7 @@ tbaMUD 3.55
[Dec 15 2007] - Rumble
Showvnums shows [T#] for a single attached trig or [TRIGS] for multiple attached trigs (except for rooms since there is plenty of room to list all attached trigs).
Fixed bug where showvnums would not show if attached. (thanks Sryth)
+
tbaMUD 3.54
[Nov 12 2007] - Rumble
Updated users command to fix GET_INVIS_LEV bug.
@@ -467,32 +474,4 @@ Version 3.53 release: July, 2007
Version 3.52 release: April, 2007
Version 3.51 release: February, 2007
Version 3.5 release: December, 2006
-Version 3.1 (yes, no beta pl): November 18, 2002
-Version 3.00 beta pl22 release: October 4, 2002
-Version 3.00 beta pl21 release: April 15, 2002
-Version 3.00 beta pl20 release: January 15, 2002
-Version 3.00 beta pl19 release: August 14, 2001
-Version 3.00 beta pl18 release: March 18, 2001
-Version 3.00 beta pl17 release: January 23, 2000
-Version 3.00 beta pl16 release: August 30, 1999
-Version 3.00 beta pl15 release: March 16, 1999
-Version 3.00 beta pl14 release: July 3, 1998
-Version 3.00 beta pl13a release: June 4, 1998
-Version 3.00 beta pl13 release: June 1, 1998
-Version 3.00 beta pl12 release: October 29, 1997
-Version 3.00 beta pl11 release: April 14, 1996
-Version 3.00 beta pl10 release: March 11, 1996
-Version 3.00 beta pl9 release: February 6, 1996
-Version 3.00 beta pl8 release: May 23, 1995
-Version 3.00 beta pl7 release: March 9, 1995
-Version 3.00 beta pl6 release: March 6, 1995
-Version 3.00 beta pl5 release: February 23, 1995
-Version 3.00 beta pl4 release: September 28, 1994
-Version 3.00 beta pl1-3, internal releases for beta-testers.
-Version 3.00 alpha: Ran on net for testing. Code not released.
-Version 2.20 release: November 17, 1993
-Version 2.11 release: September 19, 1993
-Version 2.10 release: September 1, 1993
-Version 2.02 release: Late August 1993
-Version 2.01 release: Early August 1993
-Version 2.00 release: July 16, 1993 (Initial public release)
+See releases.txt
diff --git a/FAQ b/doc/FAQ
similarity index 100%
rename from FAQ
rename to doc/FAQ
diff --git a/doc/FAQ.pdf b/doc/FAQ.pdf
deleted file mode 100644
index cdf10b5..0000000
Binary files a/doc/FAQ.pdf and /dev/null differ
diff --git a/doc/FAQ.txt b/doc/FAQ.txt
new file mode 100644
index 0000000..e8b7948
--- /dev/null
+++ b/doc/FAQ.txt
@@ -0,0 +1,857 @@
+If you have any additions, corrections, ideas, or bug reports please stop by the
+Builder Academy at telnet://tbamud.com:9091 or email rumble@tbamud.com -- Rumble
+
+ Frequently Asked Questions (FAQ) for tbaMUD with Answers
+
+This file is intended to cover common questions related to tbaMUD. Any
+contributions and corrections are more than welcome. It is currently
+maintained by Rumble of the Builder Academy. Please stop by the Builder
+Academy if you have any corrections or additions: tbamud.com 9091
+This FAQ was originally written by Ryan Watkins (VampLestat) and later
+maintained by Alex Flectcher (Furry).
+
+Other great resources are online at: http://tbamud.com
+______________________________________________________________________
+
+Table of Contents
+
+1. Introduction
+ 1.1 I've never played a MUD before. What should I do?
+ 1.2 I'm new to C and/or coding. What do I do?
+ 1.3 I want to build my own MUD. Where do I start?
+ 1.4 What is tbaMUD?
+ 1.5 What is the history of tbaMUD?
+ 1.6 Where is the original tbaMUD so I can check it out?
+ 1.7 Will the tbaMUD creators visit my mud?
+ 1.8 What is UNIX?
+
+2. Resources
+ 2.1 Where do I find the source code for tbaMUD?
+ 2.2 Where do I find areas, etc. for tbaMUD?
+ 2.3 I have questions about tbaMUD. Where should I go?
+ 2.4 To what platforms has tbaMUD been ported?
+ 2.5 How can I submit code or areas for use with tbaMUD?
+ 2.6 How do I use a patch file and how can I make one?
+
+3. Compiling tbaMUD
+ 3.1 Why do I get many syntax errors with Sun's ``cc'' compiler?
+ 3.2 Why do I get all sorts of errors with ``crypt'' functions and header files?
+ 3.3 When I try to compile, why do I get a lot of undefined symbols
+ referenced in comm.o for functions like socket, accept, and bind?
+ 3.4 Every time I try to compile tbaMUD (or any other piece of software)
+ under Linux, it gives me errors and says it cannot find include header
+ files in the linux/ and asm/ directories. What can I do?
+ 3.5 I'm getting compilation errors from a header file, and I didn't even
+ change it?
+ 3.6 I'm trying to compile the MUD on Windows and am having problems,
+ what can I do?
+ 3.7 How can I do a ``grep'' on Windows?
+ 3.8 While compiling the MUD, why do I get errors like ``foo.c:1231:
+ Undefined symbol `_whereamI' referenced from text segment''
+ 3.9 What is a parse error and how do I fix it?
+ 3.10 I have this piece of code that calls bcopy(), bzero(), and bcmp()
+ and it won't compile, so what can I do?
+ 3.11 My compiler doesn't have ``strdup()'', what can I do?
+ 3.12 I am having trouble with my ``makefile'', what could be the problem?
+ 3.13 How can I handle directories in C?
+
+4. Running tbaMUD
+ 4.1 I typed ``autorun'' but then my terminal just froze.
+ 4.2 I typed ``bin/circle'' and got lots of boot messages, but then it
+ said ``Entering game loop'' and froze.
+ 4.3 Okay, I think the MUD is running but why don't I get a login prompt?
+ 4.4 How come I get this error when running my MUD: ``Error reading board:
+ No such file or directory''
+ 4.5 I just got this SIGPIPE, what is it and what Can I Do About It?
+ 4.6 When I run tbaMUD under Linux, it tells me ``gethostbyaddr:
+ connection refused'' when the MUD boots, and then dies. Why?
+ 4.7 When I run tbaMUD under Windows, it tells me ``Winsock error
+ #10047'' when the MUD boots, and then dies. Why?
+ 4.8 When I run tbaMUD under Windows, players can't rent---their
+ equipment is just dropped on the ground, syslogs don't work, so what
+ is the problem?
+ 4.9 When someone logs on to my Windows MUD, the console screen gives:
+ ``gethostbyaddr: No such file or directory''
+ 4.10 My MUD crashed and my connection got closed. What can I do?
+ 4.11 Ok, so how do I use ``gdb''?
+ 4.12 How can I hunt bugs more effectively?
+ 4.13 I just added n levels to my MUD (from the stock 34). How do I set
+ my imps up to level n without a pfile wipe?
+ 4.14 I decided to wipe my pfile away anyway. What steps should I take to
+ do this?
+ 4.15 I want to expand the ability to pk in my MUD, allowing ASSASSINS
+ that'll be able to PK without getting flagged. How can I do this?
+ 4.16 Why does it say ``Connection closed by foreign host.'' and not
+ display the ``Byebye!'' message I'm trying to send before cutting
+ someone off?
+ 4.17 How do I get the tbaMUD to autoload when the Linux server is
+ restarted?
+ 4.18 My server shuts down my MUD everytime I logoff. How do I keep the
+ MUD running when I logoff?
+
+5. tbaMUD Questions
+ 5.1 Why does tbaMUD use BUF switches all through the code, what's
+ happening here?
+ 5.2 How do I add a new class? How do I add more levels? etc?
+
+______________________________________________________________________
+
+1. Introduction
+
+1.1. I've never played a MUD before. What should I do?
+
+Don't try to use your own copy of tbaMUD! There are two levels of MUD users:
+players and administrators. Administrators do what you're trying to do now --
+get a copy of a MUD's source code, compile it, and run it. Players use MUDs
+that are being administered by someone else. If you try to actually run a MUD
+before you've ever played one, you'll get very confused indeed! Your best bet
+for now is to play someone else's MUD first. There are a large number of
+excellent MUDs out there already, some of which are based on tbaMUD code. Check
+out other tbaMUD's at: http://www.tbamud.com/forum?c=showthread&ThreadID=86
+
+1.2. I'm new to C and/or coding. What do I do?
+
+First, a MUD is not a learning project. It has tens of thousands of lines to
+it, many of which are obscure and unclear to even moderately skilled
+programmers. Those little, ``Hello, world,'' programs are for learning,
+maybe little math tests, etc. A MUD is a pretty ambitous project to start
+with. That's like trying to run before you can walk, and while there's more
+difficult things than a MUD to start with, there's a ton of easier things you
+should start with. Second, if you are persistent, get a good C reference book
+and read the code, try to comprehend what everything is doing (to some small
+extent). You should probably avoid comm.c as it is home to the socket
+functions which general C books don't cover and are usually explained in other
+books on network programming. Then try small projects, something similar to
+what already exists. This way, you can get away with a cut-and-paste job and
+changing some of the code. Adding a simple version of races isn't all that
+difficult, just examine the class code in class.c and the CON_QCLASS block in
+interpreter.c, cut, paste, and modify. Also look at structs.h, for "#define
+CLASS_" You'll begin understanding more and more of the code as you copy and
+change it, eventually you'll be able to write a whole function by yourself.
+Spend time learning, going with haste will hurt you more than it will help you.
+Many patches and tutorials are available at: http://tbamud.com (such as adding
+races, classes, liquids, skills, spells, etc.
+
+1.3. I want to build my own MUD. Where do I start?
+
+Many common questions arise from new MUD admins. It is a good idea to pay
+attention to them and take their answers to heart. These include things
+like the following:
+
+I don't have any coding experience with MUDs, but do have a lot of ideas for
+my own. I have played many MUDs for a LONG time, though.
+
+Read the FAQ. MUD Experience doesn't help a huge amount. Code experience
+does.
+
+I am interested in having a level system of 1-50 mortal and 51-60 imms. I
+am also interested in adding races and classes. How can I accomplish these
+things?
+
+By checking out the content at http://www.tbamud.com.
+
+1.4. What is tbaMUD?
+
+TbaMUD is a DikuMUD derivitave, developed by Jeremy Elson as CircleMUD from
+Gamma v0.0 of DikuMUD created by Hans Henrik Staerfeldt, Katja Nyboe, Tom
+Madsen, Michael Seifert and Sebastian Hammer at DIKU (Computer Science
+Instutute at Copenhagen University). Note that CircleMUD is a Diku
+derivative, so its users must follow the DIKU license agreement---most
+notably it cannot be used to make money in ANY way, the original developers'
+names must be in the login screen and that the credits command always presents
+the same information, etc.
+
+tbaMUD's vision is to provide the MUDding community a stable and functional
+codebase that includes an in-depth World and help files that makes it ready
+to be molded into a custom MUD by its coders and builders. We also provide
+multiple resources to allow for feedback, contribution, and the sharing of
+ideas within the MUDding community to ensure constant development and
+improvements.
+
+TbaMUD is highly developed from the programming side, but highly UNdeveloped
+on the game-playing side. So, if you're looking for a huge MUD with billions
+of spells, skills, classes, and races, tbaMUD will disappoint you. TbaMUD still
+has only the 4 original Diku classes, the original spells, and the original
+skills. On the other hand, if you're looking for a highly stable, developed,
+organized, and well documented "blank slate" MUD on which you can put your OWN
+ideas for spells, skills, and classes, then tbaMUD is what what you are looking
+for.
+
+1.5. What is the history of tbaMUD?
+
+TBA stands for The Builder Academy.
+
+TBA was created in 2000 on Cruel World which was being run by Zemial and Welcor.
+I began combining my own experience with the work of others into an extensive
+tutorial zone, help files, and examples. Welcor and I ended up separating TBA
+from Cruel World to further enhance our training of new builders. Welcor has
+taken over the development of Trigedit and has contributed extensively to what
+has now evolved into the tbaMUD release.
+
+After offering several times to take over CircleMUD development TBA released
+CircleMUD 3.5 and later changed the codebase name to tbaMUD. TBA now has many
+purposes including: Developing trigedit, OLC, the tbaMUD codebase, and all the
+zones.
+
+TbaMUD's vision is to provide the MUDding community a stable and functional
+codebase that includes an in-depth World and help files that makes it ready
+to be molded into a custom MUD by its coders and builders. We also provide
+multiple resources to allow for feedback, contribution, and the sharing of
+ideas within the MUDding community to ensure constant development and
+improvements.
+
+TbaMUD is highly developed from the programming side, but highly UNdeveloped
+on the game-playing side. So, if you're looking for a huge MUD with billions
+of spells, skills, classes, and races, tbaMUD will disappoint you. TbaMUD still
+has only the 4 original Diku classes, the original spells, and the original
+skills. On the other hand, if you're looking for a highly stable, developed,
+organized, and well documented "blank slate" MUD on which you can put your OWN
+ideas for spells, skills, and classes, then tbaMUD is what what you are looking
+for.
+
+See release.txt for a release history.
+
+For builders TBA is a low stress, no deadline, training environment. Where
+anyone with motivation can work at their own pace to learn as much or as
+little as they wish. Numerous people are available to answer questions and
+give advice. 1000's of builders served and counting.
+
+1.6. Where is the original tbaMUD so I can check it out?
+
+The Builder Academy
+tbamud.com 9091
+
+1.7 Will the tbaMUD creators visit my mud?
+
+While there is a possibility that one (or more) of the tbaMUD creators will
+drop by your MUD for a visit, to play, or to simply look around, there is a
+slim chance that they will identify themselves. We don't want free wizzes
+or favors for our work here. In fact, we will state categorically that if
+anyone comes on your MUD claiming to be associated with us, they aren't.
+
+1.8. What is UNIX?
+
+UNIX is not an operating system of itself, it's a type (flavour, if you
+will) of operating systems. Many different kinds of UNIXes exist. Some of
+them are free, some of them are not. How to tell if you have a UNIX
+operating system? Well, UNIXes have the `ps' command, tend to have a `%' or
+`#' prompt, give you a home directory, `who' will show who else is on the
+system, etc. Many UNIX systems (such as Linux) strive to be POSIX
+compatible, so you'll probably see POSIX mentioned, too. POSIX is, roughly,
+the standards which UNIX operating systems go by. It says what makes an
+operating system part of the UNIX family and so forth. Some UNIX operating
+systems are not 100% POSIX compatible, actually, most aren't. The following
+are types of UNIX (but not all the existing flavours): Linux, FreeBSD, BSD,
+BSDi, Solaris. There are others. UNIX operating systems are command-based
+and Microsoft does not make a variant.
+
+2. Resources
+
+2.1. Where do I find the source code for tbaMUD?
+
+TbaMUD's complete source code and areas are available for download at:
+http://tbamud.com
+
+2.2. Where do I find areas, etc. for tbaMUD?
+
+All donated areas have been added to the latest version of tbaMUD. If you
+wish to donate some of your own work stop by the Builder Academy.
+
+2.3. I have questions about tbaMUD. Where should I go?
+
+Stop by The Builder Academy at tbamud.com 9091 or the website at:
+http://tbamud.com
+
+If you have general questions about the MUD such as how to get it running,
+how to add new spells, how to add new skills, etc., the first place you
+should look is the documentation. `coding.txt' will have information about
+how to add new spells, skills, commands, etc. `building.txt' has information
+about the World file formats and how to read the files, etc. There are many
+other documents in the doc directory with useful information, read them all.
+
+If you still have questions after reading the doucmentation, check out:
+
+http://tbaMUD.com/
+http://cwg.lazuras.org/modules.php?name=Forums
+http://groups.yahoo.com/group/circle-newbies/
+http://post.queensu.ca/cgi-bin/listserv/wa?SUBED1=circle&A=1
+http://groups.yahoo.com/group/dg_scripts/
+
+2.4. To what platforms has tbaMUD been ported?
+
+TbaMUD is very portable because it uses the GNU autoconf system, meaning you
+only need to type ``configure'' to have it automatically determine various
+features of your system and configure the code accordingly. TbaMUD compiles
+without changes under most BSD and SVR4 systems, including SunOS, Solaris,
+Ultrix, IRIX, AIX, Linux, BSD/OS, HP/UX, and others.
+
+TbaMUD has also been ported to various non-UNIX platforms. You can now
+compile it under OS/2 2.x and 3.x with the OS/2 port of gcc, Windows using
+Microsoft Visual C++ version 4.0 or 5.0, Cygwin, Borland (now Inprise) C++,
+Watcom v.11, Cygnus GNU-WIN32, LCC, Macintosh with CodeWarrior, Amiga, and
+Acorn RiscOS.
+
+2.5. How can I submit code or areas for use with tbaMUD?
+
+Stop by the Builder Academy. tbamud.com 9091 or visit http://tbamud.com
+
+2.6. How do I use a patch file and how can I make one?
+
+Patch files are created and used via the ``diff'' and ``patch'' utilities,
+respectively. These are the various parameters to use with diff (all work in
+general on unix based systems, but check out the help entries to be certain.
+
+diff -uN [original_src_directory] [altered_src_directory] > Patch
+
+-u is the unified output. ie. it tells diff to output the text what is
+called ``patch'' style. On some systems, you will have to use -c but it
+generates much larger and harder to follow patches.
+
+-N Tells diff to treat files that are in one directory and not there in the
+other as being empty in the one they are not there. It allows entire files
+to be included into the patch.
+
+-r recursive, add r to the uN above if you want it to recursively add in
+any subdirectories. (be careful with this one)
+
+-p Tells diff to indicate what function is being ``patched'' in each
+section. This may not be supported by all versions of ``diff.''
+
+If you download a patch file and would like to add it to your code, first
+make sure to read any instructions that the patch author might have written.
+The command used to add the patch may vary depending on how the patch was
+created. This should be given in the first line of the patch or in the
+instructions. Normally, if using GNU patch with a unified diff, the command
+should be:
+
+ patch -u < [patchfile]
+
+If the patch was created with a SYSV patcher (i.e. not a unified diff), the
+patch should be added with:
+
+ patch -c < [patchfile]
+
+Of course, if the instructions state otherwise, ignore any instructions
+given here and follow the instructions given with the patchfile instead.
+
+Finally, in modern patches, there are three characters of interest to note:
+
+o ! :: The line changes between new and old.
+o + :: This line is added to the old to make the new.
+o - :: This line is removed from the old to make the new.
+o The rest of the lines are just there to give you an idea of where
+ to change.
+
+3. Compiling tbaMUD
+
+3.1. Why do I get many syntax errors with Sun's ``cc'' compiler?
+
+Because tbaMUD is written in ANSI C, and Sun's standard cc compiler isn't
+capable of compiling ANSI C code. You can try acc, Sun's ANSI C compiler,
+but it costs extra money to get it from Sun so your sysadmin may not have
+installed it. Most don't. The best solution is to get the GCC compiler
+from the GNU FTP site (ftp://ftp.gnu.org/pub/gnu) and install it, if you
+have enough time and space.
+
+3.2. Why do I get all sorts of errors with ``crypt'' functions and
+ header files?
+
+TbaMUD normally uses the UNIX crypt() function to enrypt players' passwords.
+Because of export restrictions imposed by the U.S., some systems do not have
+the crypt() function. ``configure'' will usually be able to figure out
+whether or not your system has crypt(), but if it guesses incorrectly and
+you see problems with the crypt() function or headers, you can manually
+disable password encryption by going into the sysdep.h source file and
+uncommenting the line that reads:
+
+ #define NOCRYPT
+
+Be warned, however, that doing this causes the MUD to store players'
+passwords in plaintext rather than as encrypted strings. Also, if you move
+from a system which has crypt to one that doesn't, players won't be able to
+log in with their old passwords!
+
+3.3. When I try to compile, why do I get a lot of undefined symbols
+ referenced in comm.o for functions like socket, accept, and bind?
+
+SVR4 systems require the socket and nsl libraries for network programs. You
+shouldn't see this error any more with version 3.0 because ``configure''
+should automatically use those libraries for you; however, if you still have
+problems, try adding ``-lsocket -lnsl'' to the line in the Makefile that
+links all the object files together into the 'circle' binary.
+
+If you're using V2.20 and you have this error, the best thing to do is
+simply to use V3.0 instead. If you insist on using 2.20, go into the
+Makefile and search for the comment next to ``SVR4''.
+
+3.4. Every time I try to compile tbaMUD (or any other piece of software)
+ under Linux, it gives me errors and says it cannot find include header
+ files in the linux/ and asm/ directories. What can I do?
+
+Under Linux, you cannot compile any program unless you install the kernel
+source code because the kernel source includes the ANSI C header files. You
+need the files in /usr/include/linux, which are distributed separately from
+the rest of /usr/include.
+
+The easiest way to do this if you're using the Slackware Linux distribution
+is simply to install the 'K' series of disks which is the kernel source.
+
+Otherwise, you'll have to set up your include files manually. The easiest
+way to get these is to download kernel source from:
+
+http://www.kernel.org/mirrors/
+
+Get the kernel source that matches the kernel you're running (type `uname
+-a' to find your kernel version). Then unpack the kernel into the usr/src
+/directory. It's about 13 megabytes compressed and 54 megabytes
+uncompressed (For the 2.2.9 kernel).
+
+Read the README file that comes with the kernel, and make the symbolic links
+you need for /usr/include/asm and /usr/include/linux.
+
+Now compile the MUD. This will take care of most of the errors. You may
+have to do `make config' and `make dep' in /usr/src/linux as well, in order
+to make linux/config.h and other files that get generated by these steps.
+
+You can remove the whole kernel source tree except for include/ at
+this point and get most of your 48.5 megs back.
+
+(Thanks to Michael Chastain for providing this answer.)
+
+3.5. I'm getting compilation errors from a header file, and I didn't even
+ change it?
+
+Okay, if you really didn't change ``structs.h'' then the error isn't in
+``structs.h''. I think I've seen 2 cases where this has happened, the
+first, is that the header file you included right before the header file
+messing has an error in it. I can't really say much beyond that, but look
+for a missing semicolon, are any other errors you can find.
+
+If you include files out of order, it can mess things up. For example, B.h
+has stuff in it that is defined in A.h, and if you include B.h before A.h,
+you can get errors, your best bet here is to mess with the order of the
+headers, making sure you put ``conf.h'' and ``sysdep.h'' at the top,
+followed by ``structs.h'', ``utils.h'', etc. Any file specific headers
+should be the last one included just for coding style.
+
+3.6. I'm trying to compile the mud on Windows and am having problems,
+ what can I do?
+
+The first thing to do is to make sure you are compiling a recent version of
+the source code. Patch Level 11 and onwards all support Windows winsock
+sockets now. Second, you should ensure that you have carefully read the
+README.WIN file for instructions on what to include. Next, ensure that you
+are using a C compiler that supports long filenames (for example, MSVC 4.0
+does, MSVC 1.0 does not). If you happen to be trying to patch something
+into your code, you should use patch for DOS
+(ftp://204.119.24.14/pub/patch/patch12.zip). This does not support long
+filenames (but can be used with short filenames).
+
+3.7. How can I do a ``grep'' on Windows?
+
+1. Select ``start menu''->``find''->``files or folders''
+2. Enter the files/dirs to search in.
+3. Select ``Advanced''
+4. In the ``Containing Text'' input box, type in the text you want.
+5. Double click on a match to bring up the file that matched.
+ Even better is to use MSVC's find command (if you have it).
+
+3.8. While compiling the mud, why do I get errors like ``foo.c:1231:
+ Undefined symbol `_whereamI' referenced from text segment''
+
+You forgot to include a source file into the make. Go edit your Makefile
+and make sure all the necessary *.c files are in there, in particular,
+whichever C file defines the function that the compiler is complaining is
+undefined. If all else fails, try deleting all the *.o files and
+recompiling from scratch.
+
+3.9. What is a parse error and how do I fix it?
+
+A parsing error is often a missing or extra semicolon, parenthesis, or
+bracket ({).
+
+If the parse error is before a semicolon at the end of a line of code, it is
+something on that line.
+
+If it is at the beginning of a line within a function, it is usually a
+missing semicolon on the previous line.
+
+If it is at the beginning of a function, count your brackets (especially the
+{} ones) in the previous function.
+
+I can't think of any other parse errors. These are the ones I commonly see.
+With a bit of practice, they are very easy to locate and fix. For a more
+detailed explanation, check out the C Language FAQ.
+
+3.10. I have this piece of code that calls bcopy(), bzero(), and bcmp() and
+ it won't compile, so what can I do?
+
+All three of these functions are fairly standard on BSD systems. However,
+they are not considered to be very portable, and thus should be redefined.
+For example, the equivalents for SYSV are:
+
+#define bcopy(from,to,len) memmove(to,from,len)
+#define bzero(mem,len) memset(mem,0,len)
+#define bcmp(a,b,len) memcmp(a,b,len)
+
+3.11. My compiler doesn't have ``strdup()'', what can I do?
+
+Use tbaMUD's built-in str_dup() function instead.
+
+3.12. I am having trouble with my ``makefile'', what could be the problem?
+
+If you used cut and paste to insert items into your makefile, it is likely
+that you accidentally put spaces at the beginning of lines where tabs are
+needed. This is how the makefile must be constructed:
+
+foo.o: foo.c conf.h sysdep.h structs.h utils.h interpreter.h \
+ handler.h db.h
+{TAB}$(CC) -c $(CFLAGS)
+
+To add these lines properly, you can use gcc to assist you with the
+following shell script (from Daniel Koepke):
+
+#!/bin/sh
+gcc -MM $1 >> Makefile
+echo "{TAB}\$(CC) -c \$(CFLAGS) $1" >> Makefile
+
+To use this script, replace {TAB} with a tab, and then run the script
+like: add_file foo.c
+
+3.13. How can I handle directories in C?
+
+Note that this seems only to be valid for UNIX OSes. Handling of
+directories is accomplished through the dirent.h and sys/types.h files. The
+function opendir() returns a ``DIR*'' pointer (it's like but not the same as
+the ``FILE *'' pointer) when you pass it the name of a directory to open or
+NULL if it can't open the dir. After the directory has been opened, you can
+step through the files or search for particular files, etc. using readdir(),
+seekdir(), and scandir(). When you reach the end of the directory list, you
+can either go back to the start with rewinddir() or close the directory with
+closedir(). The following code (which has not been tested) should open a
+directory and go through it one by one and prints the filenames:
+
+ struct dirent * ffile;
+ DIR * my_dir;
+
+ if (!(my_dir = opendir("foo")))
+ return;
+
+ while (1) {
+ if (!(dirent = readdir(my_dir)))
+ break;
+ printf("%s\n", dirent->d_name);
+ }
+
+ closedir(my_dir);
+
+The dirent structure contains only two useful elements, the file's name
+(d_name) and the files length (d_reclen).
+
+Thanks to Daniel Koepke for the above.
+
+4. Running tbaMUD
+
+4.1. I typed ``autorun'' but then my terminal just froze.
+
+autorun is a script which automatically runs, logs, and reboots the game for
+long-term runs. You should run autorun in the background by typing
+``./autorun &'' -- the MUD will start running in the background and you'll
+get the normal UNIX prompt back immediately (see section 4.3). The game will
+then run unattended until you explicitly shut it down.
+
+On some systems, you may need to prepend ``nohup'' to the autorun command
+since some systems will kill off any processes left running when you leave
+the shell.
+
+4.2. I typed ``bin/circle'' and got lots of boot messages, but then it said
+ ``Entering game loop'' and froze.
+
+It is not frozen, it is just waiting for people to connect. You have to run
+the MUD in the background by typing ``autorun &'' and then use telnet to
+connect to the game (see next section).
+
+4.3. Okay, I think the MUD is running but why don't I get a login prompt?
+
+In order to play the MUD, you must connect to it using the telnet command,
+i.e. ``telnet localhost 4000''.
+
+4.4. How come I get this error when running my mud: ``Error reading board:
+ No such file or directory''
+
+This is not a bad thing, all it means is that you have some boards on the
+mud and that it can't find the file for them. Since it can't find the file,
+the mud will just create the file on the fly and use that, so the next time
+something is posted to the board, the files will exist. However, if you did
+have files for the boards and you are suddenly getting this error, it means
+that the board files have been deleted or something similar.
+
+4.5. I just got this SIGPIPE, what is it and what Can I Do About It?
+
+Often it appears that other people send your system SIGPIPEs when their
+connection is closed, in fact, it is not the person sending the SIGPIPE, it
+is your system. The SIGPIPE is generated when your program attempts to
+write to descriptor which has no one listening to it. This occurs if the
+character is sent a message by the mud after connecting, but before the
+socket is flagged with an exception or reads 0 bytes. By default, tbaMUD
+ignores these SIGPIPEs, with the line my_signal(SIGPIPE, SIG_IGN) in
+signal_setup(). Where most people see the problems with SIGPIPE is while
+debugging with GDB. By default, GDB responds to a SIGPIPE by stoping the
+program, printing that a SIGPIPE was received, and passing it to the
+program. You can change the action taken by GDB by using the `handle'
+command. To stop the program from stoping at SIGPIPE, you would give GDB the
+command `handle SIGPIPE nostop'
+
+4.6. When I run tbaMUD under Linux, it tells me ``gethostbyaddr: con-
+ nection refused'' when the MUD boots, and then dies. Why?
+
+You need to make sure you have Networking and TCP/IP support compiled into
+your Linux kernel, even if you aren't actually connected to the Internet.
+The easiest way to do this if you're using Slackware is to install one of
+Slackware's precompiled networking kernels. Also, make sure to install
+Slackware's `N' series of disks which contains other networking support
+files.
+
+If Slackware's precompiled kernel isn't available you'll have to compile the
+kernel yourself. First make sure the kernel source is installed in
+/usr/src/linux (see section 3.1.4) and follow the instructions in
+/usr/src/linux/README. When you do `make config' it will ask you a series of
+questions about which kernel features you want; make sure to answer ``Y'' to
+``Networking support'' and ``TCP/IP support''.
+
+4.7. When I run tbaMUD under Windows, it tells me ``Winsock error
+ #10047'' when the MUD boots, and then dies. Why?
+
+You need to configure TCP/IP networking from the Network Control Panel, even
+if you are not connected to the Internet. From the Network Control Panel,
+select ``Add Protocol'', and under the vendor ``Microsoft'', choose
+``TCP/IP''. It may ask you to insert the Windows CDROM in order to copy
+the drivers onto your hard drive.
+
+4.8. When I run tbaMUD under Windows, players can't rent---their
+ equipment is just dropped on the ground, syslogs don't work, so what
+ is the problem?
+
+The reason that objects aren't saved when your players quit is that certain
+unzip programs are buggy and don't completely recreate the MUD's directory
+structure (in particular, it doesn't create directories which have no files
+in them.) This is fixed in Circle 3.0 patchlevel 12 and above. Before
+patchlevel 12, you can fix it simply by manually creating the needed
+directories:
+
+ CD \tbamud
+ cd lib\plrobjs
+ mkdir A-E
+ mkdir F-J
+ mkdir K-O
+ mkdir P-T
+ mkdir U-Z
+ mkdir ZZZ
+
+Object saving should then work. The syslogs are a different story; no data
+is written to the system logs because the code currently is configured
+simply to write all errors to the standard error file descriptor (stderr),
+and Windows doesn't seem to let you redirect stderr to a file the same way
+UNIX does. pl12 allows you to direct logs to a specific file instead.
+
+4.9. When someone logs on to my Windows MUD, the console screen
+gives: ``gethostbyaddr: No such file or directory''
+
+This means the MUD can't resolve the IP address of the connecting player's
+source site innto a hostname. You probably don't have DNS correctly
+configured in the Windows Network Control Panel menu (under configuration of
+the TCP protocol). Make sure you have the IP address of your ISP's DNS
+server listed.
+
+4.10. My MUD crashed and my connection got closed. What can I do?
+
+Just because your connection got closed from the MUD (for example, if you
+get too much information sent to you and the telnet session gets closed),
+this doesn't always mean that the game itself crashed. Before reporting
+something as a crash bug, make sure that the game itself crashed, and above
+all, try to duplicate the circumstances before reporting it as a crash bug.
+You can also try using gdb to find out why the MUD is crashing if it gives
+you a core dump.
+
+4.11. Ok, so how do I use ``gdb''?
+4.12. How can I hunt bugs more effectively?
+
+See debugginge.txt
+
+4.13. I just added n levels to my MUD (from the stock 34). How do I set my
+ imps up to level n without a pfile wipe?
+
+This should no longer be a problem with the do_cheat function in act.wizard.c
+but the only ID with access by default is IDNUM 1.
+
+4.14. I decided to wipe my pfile away anyway. What steps should I take to
+ do this?
+
+tbaMUD has ASCII pfiles so all you have to do is delete the index and all
+pfiles in the /lib/plrfiles/ directory.
+
+You should also remove files in plrobjs, plralias, and plrvars, unless you want
+the recreated characters to come back with their same equipment, aliases, and
+trigger variables.
+
+4.15. I want to expand the ability to pk in my MUD, allowing ASSASSINS
+ that'll be able to PK without getting flagged. How can I do this?
+
+With tbaMUD simply enter Cedit (configuration editor) and select Game Play
+Options. Then enable Player Killing.
+
+4.16. Why does it say ``Connection closed by foreign host.'' and not
+ display the ``Byebye!'' message I'm trying to send before cutting
+ someone off?
+
+This usually happens if you are doing something like this:
+
+ send_to_char(ch, "Bye bye. Come back soon, ya hear?");
+ close_socket(ch->desc);
+
+The close_socket immediately dispatches/closes the connection, while
+send_to_char puts the message on the output queue to be dispatched next
+game_loop cycle. Therefore, the socket is gone. On some systems (ie old
+linux), this can even cause a infinite loop attempting to write to a closed
+socket. The proper way of doing this and other ``Byebye'' messages is to set
+the CON state of the player to CLOSE, like this:
+
+ send_to_char(ch, "Bye bye. Come back soon, ya hear?");
+ STATE(ch->desc) = CON_CLOSED;
+
+This will then cycle to the next game_loop, dispatch the output queues
+(therefore sending the byebye message) and then close the socket. Further
+note, in some bizarre cases, this only seems to send about 40 characters and
+no escape codes. Sending more than 40 characters or escape codes (like the
+clear screen sequence) will crash the process reporting a problem similar to
+writing to a closed socket.
+
+4.17. How do I get the tbaMUD to autoload when the Linux server is
+ restarted?
+
+In /etc/rc.d/rc.local find where things like sendmail and (maybe) gpm
+are started. Add something like:
+
+cd /home/mudlogin/tbamud/
+su mudlogin -c ./autorun &
+cd
+
+Of course, change the "mudlogin" to whatever the name of the account is that
+normally has control of the MUD, and change the path in the first cd to
+whereever the MUD is run from.
+
+For more info: man su
+
+4.18. My server shuts down my MUD everytime I logoff. How do I keep the MUD
+ running when I logoff?
+
+Instead of typing "autorun &" to start the autorun script (which starts and
+keeps the MUD running), type "nohup autorun &". Running the autorun via
+nohup will keep the script and the MUD running when you logoff of the
+server. For more information type "man nohup" at the prompt on your server.
+
+5. tbaMUD 3.X
+
+5.1. Why does tbaMUD use BUF switches all through the code, what's
+ happening here?
+
+From Jeremy:
+
+This code is the new output buffering system that I wrote for Circle in the
+early (non-released) beta versions of 3.0. The old Diku code for queueing
+output (which stayed with Circle until version 2.20) was memory- and
+time-inefficient in many cases (and, in my opinion, was inefficient for the
+normal behavior of most MUDs).
+
+First, I should explain what output queueing is and why it is necessary. On
+each pass through the game_loop(), the MUD performs a number of steps: check
+to see if there are any new players connecting, kick out people with bad
+links, read input over the network for all players, then process the input
+for each player that has sent a complete line over the net. The processing
+step is usually where output is generated because it is where MUD commands
+are processed (e.g., ``kill'' might generate output of ``Kill who?'') When
+output is generated, it is not immediately sent out to the player, but
+instead queued for output in a buffer. After all players' commands are
+processed (and each command generates the appropriate output for various
+players), the next step of the game_loop() is to send all the queued output
+out over the network.
+
+The new output system that tba now uses allocates a small, fixed size
+buffer (1024 bytes) for each descriptor in which output can be queued. When
+output is generated (via such functions as send_to_char(), act(), etc.), it
+is written to the fixed size buffer until the buffer fills. When the buffer
+fills, we switch over to a larger (12K) buffer instead. A ``buffer
+switch'', therefore, is when the 1024-byte fixed buffer overflows.
+
+When a large (12K) buffer is needed, it is taken from a pool of 12K buffers
+that already been created. It is used for the duration of that pass through
+the game_loop() and then returned to the pool immediately afterwards, when
+the output is sent to the descriptor. If a large buffer is needed but none
+are in the pool, one is created (thereby increasing the size of the pool);
+the ``buf_largecount'' variable records the current pool size.
+
+If a player has already gone from their small to large buffer, and so much
+output is generated that it fills even the large buffer, the descriptor is
+changed to the overflow state, meaning that all future output for the
+duration of the current pass through the game loop is discarded. This is a
+buffer overflow, and the only state in which output is lost.
+
+Now that I've described how the system works, I'll describe the rationale.
+The main purpose for the two-tiered buffer system is to save memory and
+reduce CPU usage. From a memory standpoint: Allocating a fixed 12K buffer
+for each socket is a simple scheme (and very easy to code), but on a large
+MUD, 100 12K buffers can add up to a lot of wasted memory. (1.2 megs of
+memory used for buffering on a 100-player MUD may not seem like very much,
+but keep in mind that one of tba's big selling points several years ago,
+when memory was expensive, was that it had a very small memory footprint (3
+or 4 megs total!) And from a CPU standpoint: the original Diku used a
+dynamically allocated buffer scheme to queue output, which unfortunately
+meant that for each player, on each pass through the game loop, dozens of
+tiny buffers (often one for every line of output, depending on the code to
+execute the command) were allocated with malloc(), individually written to
+the system using individual calls to write(), and then free()'d. My system
+saves hundreds or thousands of calls per second to malloc() and free(), and
+reduces the number of system calls *drastically* (to at most one per player
+per pass through the game loop).
+
+The trick is to choose the size of the small and large buffers correctly in
+order to find the optimal behavior. I consider ``optimal'' to mean that 90%
+of the time, most players stay within the limits of their small buffer (for
+example, when wandering through town or mindlessly killing some monster
+while watching damage messages go by). Hopefully, a large buffer switch is
+only necessary when a player executes a special command that generates an
+unusually large amount of output, such as ``who'', ``read board'', or
+``where sword''. This critically depends on the fact that not everyone will
+be executing such a special large-output command at the same instant.
+
+For example, imagine you have 10 players on your MUD. They are all
+wandering around town, and every once in a while one of them types ``who'',
+or reads the board, meaning that they are seeing more than 1024 bytes of
+output at a time. On such a MUD, I would hope that there would only be a
+single 12K buffer allocated which gets passed around among all the 10
+players as needed. Now, all players think they can queue up to 12K of
+output per command without getting truncated even though only one 12K buffer
+actually exists -- they are all sharing it.
+
+But - there's a problem with this. There are certain cases when many
+players have to see a lot of output at the same instant (i.e. on the same
+pass through the game_loop()), all of them will need a large buffer at the
+same time and the pool will get very big. For example, if an evil god types
+``force all who''; or if the MUD lags for several seconds, then suddenly
+gets unlagged causing many commands to be processed at the same moment; or
+if 20 people are all trying to kill the same MOB and are all seeing 20
+damage messages (more than 1024 bytes) on the same pass through the
+game_loop().
+
+Unfortunately, the current patchlevel of tba has no way to destroy large
+buffers so such cases are pathological and cause wasted memory.
+Unfortunately since I don't run a MUD I can't actually tell how often this
+happens on a real MUD. (If there are any IMPs out there who run large MUDs
+(say, >= 30-50 players on regularly), and you've read this far, please send
+me the output of ``show stats'' after your MUD has been played for at least
+several hours.)
+
+5.2 How do I add a new class? How do I add more levels? etc?
+
+Many common questions about basic additions are answered here:
+http://tbamud.com
\ No newline at end of file
diff --git a/README b/doc/README
similarity index 100%
rename from README
rename to doc/README
diff --git a/doc/README.CYGWIN b/doc/README.CYGWIN
index ff9916f..d4d80f6 100644
--- a/doc/README.CYGWIN
+++ b/doc/README.CYGWIN
@@ -1,38 +1,71 @@
-Updated: Apr 2007
+If you have any additions, corrections, ideas, or bug reports please stop by the
+Builder Academy at telnet://tbamud.com:9091 or email rumble@tbamud.com -- Rumble
+
Compiling tbaMUD
under Microsoft Windows using CygWin
+Originally by: Jeremy Elson, David Goldstein, Tony Robbins, and George Greer.
tbaMUD compiles under Cygwin without needing any special modifications.
-This free pseudo-Unix environment for Windows includes the "bash" shell, "gcc"
-family of compilers, and a full set of programs and libraries for Windows users
-to compile and run programs from source code intended for Unix. It can be
-downloaded from: http://cygwin.com/
+This free pseudo-Unix environment for Windows includes the "bash" shell, gcc,
+and a full set of programs and libraries for Windows users to compile and run
+programs from source code intended for Unix. It can be downloaded from:
+http://cygwin.com/
Compiling tbaMUD under Cygwin is basically the same as it would be under
another form of Unix:
1) Download from: http://cygwin.com/setup.exe
Select open.
- Install from Internet
- Select "just me" "dos"
- Choose a mirror site.
- Leave selected package as default.
- Select the following from devel: autoconf, gcc, make, and patchutils
- Click Next.
- Install, follow prompts.
+ Install from Internet.
+ Choose a root directory, I use C:\
+ Select "just me" "Unix / binary"
+ Select a local package directory, I use C:\WINDOWS\Temp
+ Leave Direct Connection selected.
+ Choose a download site.
+ You can either click the "circular arrow" next to All to install the whole
+ thing (it lags a bit, wait for it) or leave default and add the necessary
+ packages yourself by expanding devel and adding: autoconf, gcc, make, and
+ patchutils (choose the first one of each). The all option requires
+ broadband and at least an hour to download. It will automatically install
+ once complete, just follow the prompts.
-2) Download and uncompress the latest version of tbaMUD:
- http://cwg.lazuras.org/modules.php?name=Downloads&d_op=viewdownload&cid=16
- Join the forums as they will be a great resource for any problems that you
- encounter. Once you download and uncompress tbaMUD (I use winRAR) read
- through the /doc directory.
+2) Download the latest version of tbaMUD from http://tbamud.com
+ Create an account on tbamud.com as it will be a great resource for any
+ problems that you encounter. Once you download and uncompress tbaMUD (I use
+ winRAR) read through the /doc directory.
3) Start the Cygwin "bash" shell by double clicking the Cygwin Icon. This will
open a telnet looking window that mimics a *nix server where you can run the
MUD. Go to the directory where you extracted tbaMUD by using the "cd" change
directory command and "dir" directory listing to find the correct files. For
- example "C:\tbaMUD". "cd c:/tbaMUD" "dir" in the listed files you should see
- one called configure. DO NOT go into the SRC directory yet.
+ example "C:\tbaMUD". "cd c:/tbaMUD" then "dir" to list the files. You should
+ see one called configure. DO NOT go into the SRC directory yet.
+
+4) Run the configure script by typing "./configure". This will automatically
+ detect what programs and library functions are available, and create the
+ files "Makefile" and "conf.h" based on the results.
+
+ If you get complaints from bash that it will not run the configure script
+ either because it cannot find it or because it claims the file is not
+ an executable, you can also try "sh configure", "sh ./configure",
+ "bash configure" and "bash ./configure" until one of them works.
+
+5) NOW change to the /tbaMUD/src directory "cd src", and type "make", and watch
+ tbaMUD and the additional utilities included in the tbaMUD distribution
+ automatically being compiled and placed in /tbaMUD/bin.
+
+6) Go back to /tbaMUD, and run the MUD either directly by typing "bin/circle",
+ or by using the "./autorun &" script. The & makes it run in the background.
+
+7) Start a telnet program. Open a connection to your own machine "localhost"
+ on port 4000. You should see the MUD's login screen welcoming you. The
+ first person to login will be promoted to IMP.
+
+If you have problems, read this document again. Most questions are answered in
+the documentation or at http://tbamud.com. If you are still having problems
+feel free to stop by The Builder Academy for assistance.
+
+It really can not be stressed enough: READ EVERYTHING.
OPTIONAL: Make the following change to src/Makefile.in to make copyover work:
@@ -49,41 +82,7 @@ OPTIONAL: Make the following change to src/Makefile.in to make copyover work:
clean:
The above is a "patch" file. All you need to do is add the two lines with
- the +'s to your file Makefile.in. If you are still confused check out these
- links on how to patch: http://www.circlemud.org/cdp/wtfaq/handpatch.html
+ the +'s to your file Makefile.in (but delete the +'s). If you are still
+ confused check out these links on how to patch:
+ http://www.circlemud.org/cdp/wtfaq/handpatch.html
http://cwg.lazuras.org/modules.php?name=Forums&file=viewtopic&t=757
-
-4) Run the configure script by typing "./configure". This will automatically
- detect what programs and library functions are available, and create the
- files "Makefile" and "conf.h" based on the results.
-
- If you get complaints from bash that it will not run the configure script
- either because it cannot find it or because it claims the file is not
- an executable, you can also try "sh configure", "sh ./configure",
- "bash configure" and "bash ./configure" until one of them works.
-
-5) NOW change to the /tbaMUD/src directory "cd src", and type "make", and watch
- tbaMUD and the additional utilities included in the tbaMUD distribution
- automatically being compiled and placed in /tbaMUD/bin.
-
-6) Go back to /tbaMUD, and run the MUD either directly by typing
- "bin/tbaMUD", or by using the "./autorun &" script.
-
-7) Start a telnet program. Open a connection to your own machine "localhost"
- on port 4000. You should see the MUD's login screen welcoming you. The
- first person to login will be promoted to IMP.
-
-If you have problems, read this document again. Most of the questions received
-in email or which are posted to USENET newsgroups are answered in this file, or
-in other documents included in the tbaMUD distribution. If you are still
-having problems and you're *sure* that your question is not answered in this
-document or in one of the others files in the /tbaMUD/doc directory, try
-reading the forums at http://cwg.lazuras.org/ or stop by TBA for assistance.
-
-It really can not be stressed enough: READ EVERYTHING.
-
-Authors: Jeremy Elson, David Goldstein, Tony Robbins, and George Greer.
-
-Rumble
-The Builder Academy
-builderacademy.net 9091
diff --git a/doc/act.pdf b/doc/act.pdf
deleted file mode 100644
index dbf2b80..0000000
Binary files a/doc/act.pdf and /dev/null differ
diff --git a/doc/act.txt b/doc/act.txt
new file mode 100644
index 0000000..00d187f
--- /dev/null
+++ b/doc/act.txt
@@ -0,0 +1,184 @@
+If you have any additions, corrections, ideas, or bug reports please stop by the
+Builder Academy at telnet://tbamud.com:9091 or email rumble@tbamud.com -- Rumble
+
+The act() Function
+Originally by Alex Fletcher. Based on text from the DikuMud authors
+
+This document is intended to give an overview of the act()function and give a
+summary of the various flags and the associated descriptive control characters.
+The act() function is one of the primary functions for sending a message from
+the game to a character or number of characters in a room.
+
+Contents
+
+1 The act()Function
+
+1.1 Overview
+1.2 The Function
+1.3 TheParameters
+1.4 Control Characters
+1.5 Examples
+
+1 The act()Function
+
+1.1 Overview
+The act() function is used to process and send strings of text to characters
+in a room. It can be used to send the same basic string to a number of
+characters filling in certain segments – designated by control characters –
+in different ways, dependant on what each character can see and who each
+character is. Once the text string passed to the function has been parsed, it
+is capitalized and a newline is added to its tail.
+
+1.2 The Function
+The act()function is found in the comm.c source file and is described as:
+
+void act(const char *str, int hide_invisible, struct char_data *ch,
+struct obj_data *obj, const void *vict_obj, int type)
+
+These pieces are used as follows:
+
+str: This is the basic string, a null terminated character array, including
+control characters (see section 1.4 on ‘Control Characters’), to be sent to
+characters designated by the targets.
+
+hide_invisible: A TRUE or FALSE value indicating whether or not to hide the
+entire output from any characters that cannot see the “performing character”.
+
+ch: The “performing character”. This is the character that the output string
+is associated with. The character is used to determine the room for the output
+of the action in question.
+
+obj: An object (an actual item – obj_data) used in the course of the action.
+
+vict_obj: This can be either a character involved in the action, another
+object, or even a predefined string of text.
+
+type: One of TO_VICT, TO_CHAR, TO_NOTVICT, or TO_ROOM. This indicates who it
+is to be targeted at.
+
+1.3 The Parameters
+Of the various parameters passed to the act() function, the str is the most
+important, as it is the basis for the actual final output. If this parameter
+is a null-pointer or points to a null-character, then the function returns
+immediately. The next important parameter is the ch parameter. This, as
+mentioned, points to the central character associated with the output string
+and action.
+
+obj is an object of type struct obj_data *that is passed to the function. If
+there is no object to pass to the function, then a NULL or 0 should be passed
+in this location.
+
+The next parameter vict_objcan be a number of things ranging from a game object
+(strcut obj_data *), through to a character (struct char_data *), and even a
+null terminated character array (char *).
+
+Do note, however, that obj and vict_obj are both ignored if there is no control
+character reference (see section 1.4 ‘Control Characters’) to them and the type
+is set to TO_ROOM or TO_CHAR. In these cases, NULL should be supplied as the
+input to the function.
+
+The hide_invisible flag dictates whether or not the action output should be
+hidden from characters that cannot see ch. If the flag is set to TRUE
+(non-zero), then this is the case.
+
+The type determines who the output is to be sent to. There are four options for
+this (all defined in comm.h) described below:
+
+TO_ROOM: This sends the output to everybody in the room, except ch.
+
+TO_VICT: This option sends the output to the character pointed to by vict_obj.
+In this case, vict_obj must point at a character rather than an object.
+
+TO_NOTVICT: In another case where vict_obj must point to a character. This
+sends the output to everybody in the room except ch and vict_obj.
+
+TO_CHAR: Finally, this option sends the output to the ch.
+
+TO_SLEEP: This is a special option that must be combined with one of the above
+options. It tells act() that the output is to be sent even to characters that
+are sleeping. It is combined with a bitwise ‘or’. i.e. TO_VICT | TO_SLEEP.
+
+When the string has been parsed, it is capitalized and a newline is added.
+
+1.4 Control Characters
+In a manner similar to the printf() family of functions, act() uses control
+characters. However, instead of using the % symbol, act() uses the $ character
+to indicate control characters.
+
+$n Write name, short description, or “someone”, for ch, depending on whether
+ch is a PC, a NPC, or an invisible PC/NPC.
+$N Like $n, except insert the text for vict_obj.*
+$m “him,” “her,” or “it,” depending on the gender of ch.
+$M Like $m, for vict_obj.*
+$s “his,” “her,”or “it,” depending on the gender of ch.
+$S Like $s, for vict_obj.*
+$e “he,” “she,” “it,” depending on the gender of ch.
+$E Like $e, for vict_obj.*
+$o Name or “something” for obj, depending on visibility.
+$O Like $o, for vict_obj.*
+$p Short description or “something” for obj.
+$P Like $p for vict_obj.*
+$a “an” or“a”, depending on the first character of obj’s name.
+$A Like $a, for vict_obj.*
+$T Prints the string pointed to by vict_obj.*
+$F Processes the string pointed to by vict_obj with the fname() function prior
+to printing.*
+$u Processes the buffer and uppercases the first letter of the previous word
+(the word immediately prior to the control code). If there is no previous word,
+no action is taken.
+$U Processes the buffer and uppercases the first letter of the following word
+(the word immediately after to the control code). If there is no following
+word, no action is taken.
+$$ Print the character ‘$’.
+
+NOTE*: vict_obj must be a pointer of type struct char_data *.
+
+1.5 Examples
+In all of the following examples, ch points to male character Ras, vict always
+points to the female character Anna. obj1 is a small sword, and obj2 is a small
+sack.
+
+act("$n smiles happily.", TRUE, ch, NULL, NULL, TO_ROOM);
+This is sent to the room that Ras is currently in, and the string that they see
+if they can see him is:
+Ras smiles happily.
+If a character cannot see Ras, then they will not see the action at all.
+
+act("You kiss $M.", FALSE, ch, NULL, vict, TO_CHAR);
+In this action, Ras is kissing Anna, and Ras will see:
+You kiss her.
+
+act("$n gives $p to $N.", TRUE, ch, obj1, vict, TO_NOTVICT);
+The output from this string is sent to everyone in the room except for Ras and
+Anna. Of course, if they cannot see Ras, then they will not see any output at
+all. The string that each character in the room will see is:
+Ras gives a small sword to Anna.
+If a character cannot see Anna, then someone will be used in place of her name,
+and if they cannot see the small sword, then something will be used in its
+place.
+
+act("$n gives you $p.", FALSE, ch, obj1, vict, TO_VICT);
+Similar to the prior example, this is the output for Anna. She will see this
+even if she cannot see Ras, and the output that she will get is:
+Ras gives you a small sword.
+Just as per the last example, if she cannot see Ras, someone will be used in
+place of his name, and if she cannot see the sword, then something will be
+used in its place.
+
+act("$n puts $p in $s $O.", TRUE, ch, obj1, obj2, TO_ROOM);
+This action uses two objects rather than two characters, and is displayed to
+the entire room (with the exception of Ras of course). If the character can
+see Ras, they will see:
+Ras puts a small sword in his small sack.
+Otherwise, they will see nothing. Again, as per the prior two examples,
+something will be used in place of any objects that the viewing character
+cannot see.
+
+act("The $F opens quietly.", FALSE, ch, NULL, EXIT(ch, door)->keyword, TO_ROOM);
+If the keywords for the door were gate wooden, then this would send the output
+string of:
+The gate opens quietly.
+to all of the characters in the room with the exception of Ras.
+
+In addition to these examples, a multitude of other examples can be found
+scattered throughout the tbaMUD source code.
\ No newline at end of file
diff --git a/doc/admin.pdf b/doc/admin.pdf
deleted file mode 100644
index 280831c..0000000
Binary files a/doc/admin.pdf and /dev/null differ
diff --git a/doc/admin.txt b/doc/admin.txt
new file mode 100644
index 0000000..d4b9ab1
--- /dev/null
+++ b/doc/admin.txt
@@ -0,0 +1,592 @@
+If you have any additions, corrections, ideas, or bug reports please stop by the
+Builder Academy at telnet://tbamud.com:9091 or email rumble@tbamud.com -- Rumble
+
+The tbaMUD Administrator’s Manual
+Originally by Jeremy Elson
+
+This document describes how to configure tbaMUD and how to compile it for the
+first time. It also discusses how to run the server including documentation of
+command-line options, a description of system logs and how to use them, and a
+description of daily and long-term maintenance required by the MUD. The
+intended audience is implementors new to tbaMUD or MUD administration in
+general.
+
+More information about tbaMUD, can be found at http://tbamud.com.
+
+Contents
+
+1 Welcome to tbaMUD!
+
+1.1 Background and Introduction
+1.2 Are you a Player or an Administrator?
+1.3 So, you’re sure you want to run your own MUD?
+1.4 Giving Credit Where Credit is Due
+
+2 Getting Started
+2.1 Section Requirements
+2.2 Downloading and Unpacking the Source
+2.3 Configuring tbaMUD
+2.4 Compiling tbaMUD
+
+3 Running tbaMUD
+3.1 Execution and autorun
+3.2 Command-Line Options
+3.3 Creating an Implementor Character
+
+4 Customizing tbaMUD
+4.1 CEDIT and config.c
+4.2 TEDIT and Text Files
+4.3 World Files
+
+5 System Logs
+5.1 Player Information
+5.2 Usage Information
+5.3 Errors
+
+6 MUD Maintenance
+6.1 Technical Maintenance
+6.2 Diplomatic Maintenance
+
+7 Final Thoughts
+
+1 Welcome to tbaMUD!
+
+1.1 Background and Introduction
+tbaMUD is a derivative of DikuMud, the Multi-User Dungeon developed at DIKU,
+the Department of Computer Science at the University of Copenhagen. The original
+circleMUD, version 1.0, was run by Jeremy Elson at the Johns Hopkins
+University’s Department of Computer Science with moderate popularity from
+January until September of 1992. The version 1.0 code, which was never released
+to the public, was archived and remained inactive for several months after the
+death of the original CircleMUD. In the summer of 1993, it was taken out of
+storage and cleaned up with the intention of making it a public code base that
+anyone could freely download and use to start a MUD. Version 2.0, the first
+publically available version, was released in June of 1993. CircleMUD was
+maintained as a public code base until 2002 with the final release of CircleMUD
+3.1. After development stagnated for 3 years The Builder Academy offered to
+take over development. After a 4th year of no continued development The Builder
+Academy released circleMUD 3.5 in 2006. Soon after Jeremy Elson requested we
+change the codebase name. Even though we still follow the CircleMUD vision we
+agreed and the codebase is now known as tbaMUD. The Builder Academy is open to
+anyone willing to learn how to build or start their own MUD.
+
+Thousands of carefully spent hours have gone into the development of this
+codebase, but it is not a finished product – it is only a beginning. It has
+only a small number of spells and skills, and only the 4 original DikuMud
+classes. From a gamer’s point of view, it pales in comparison to other MUDs
+which have dozens of spells spread over a dozen classes, and a rich palette of
+skills. Yet from a programmer’s point of view, tbaMUD is very highly developed.
+While the look and feel of the original DikuMud has been maintained, most of
+the underlying code and many of the structures have been optimized, reworked,
+or completely redesigned to be efficient, compact, and easily changeable and
+extensible. Dozens of features which have become standard in the MUDding
+world over the past few years, although they were not part of the original
+DikuMud release, were added to tbaMUD as well.
+
+The result is that tbaMUD is a launching pad for your own MUD ideas. Our hope
+in releasing it is that it will free potential MUD implementors from having to worry about dealing with bug-ridden code or wasting time reinventing the wheel
+by re-coding standard MUD features, allowing them to devote more effort towards
+creatively shaping tbaMUD into their own unique vision of how a MUD should look
+and feel. The reason why tbaMUD has so few specialized spells, skills, classes,
+and races is to encourage implementors just like you to create your own
+unique system instead of just another stock MUD that everyone has seen before.
+
+So, it is with this message that we inflict our code on the world: don’t just
+put another generic MUD on the Net – give us something new and exciting, and
+have as much fun as possible in the process!
+
+1.2 Are you a Player or an Administrator?
+If you’ve never played a MUD before, jumping right in and trying to run one of
+your own will probably just get you hopelessly confused. Instead of trying to
+compile and run the tbaMUD package yourself (which is presumably what you’re
+trying to do if you’re reading this document), you should play someone else’s
+copy of tbaMUD first to become familiar with the codebase.
+
+1.3 So, you’re sure you want to run your own MUD?
+If you’re already an old hand at playing MUDs and you’ve decided you want to
+start one of your own, here is our advice: sleep on it, try several other MUDs
+first. Work your way up to an admin position and see what running a MUD is
+really about. It is not all fun and games. You actually have to deal with
+people, you have to babysit the players, and be constantly nagged about things
+you need to do or change. Running a MUD is extremely time consuming if you do
+it well, if you are not going to do it well then don't bother. Just playing
+MUDs is masochistic enough, isn’t it? Or are you trying to shave that extra
+point off your GPA, jump down that one last notch on your next job evaluation,
+or get rid of that pesky Significant Other for good? If you think silly
+distractions like having friends and seeing daylight are preventing you from
+realizing your full potential in the MUD world, being a MUD Administrator is
+the job for you.
+
+Don’t get me wrong: running a production MUD can be great fun. It can also be
+overburdened by politics and plagued by spiteful players devoted to making your
+life difficult, and otherwise be a highly frustrating endeavour. That’s why I
+started The Builder Academy and develop the tbaMUD codebase. The enjoyment of
+MUDding without the pesky players!
+
+1.4 Giving Credit Where Credit is Due
+If I haven’t scared you away yet, and you’re still sure you want to use tbaMUD,
+please stop for a moment and look at the license in the file license.txt. It
+outlines the terms under which you must use tbaMUD.
+
+The license is simple. It boils down to the message, “Don’t rip off other
+people’s work.” Unfortunately, this simple message ended up becoming somewhat
+long-winded because I am trying to prevent people from abusing DikuMud in the
+future as they have in the past.
+
+Also, out of courtesy if nothing else, please keep the credits file intact. You
+can add your own credits on top of the existing file, but I’d appreciate it if
+you would not simply remove it and all references to the word “Circle”
+everywhere in the MUD. How would you feel if someone took your code and then
+took credit for it?
+
+USE OF THIS SOFTWARE IN ANY CAPACITY IMPLIES THAT YOU HAVE READ, UNDERSTOOD,
+AND AGREED TO ABIDE BY THE TERMS AND CONDITIONS SET DOWN BY THE LICENSE.
+
+2 Getting Started
+
+2.1 Section Requirements
+tbaMUD was originally written as UNIX software and will automatically configure
+itself (using GNU autoconf) and compile under most versions of UNIX, both BSD
+and System V derivatives, including Mac OS X. With minor adjustments
+(documented below), the same source should compile under Microsoft Windows, IBM
+OS/2, and the Amiga. Users have also reported getting tbaMUD to compile and run
+under MkLinux, the port of Linux to the Power Macintosh. tbaMUD will not work under DOS, Windows 3.x, Windows for Workgroups 3.x, or Mac System.
+Specifically, the following variants of UNIX have been tested and are known to
+work with tbaMUD:
+
+SunOS 4.1.4
+Solaris 2.3 and above
+Irix 5.2, 6.2
+AIX 3.2
+Ultrix 4.x
+HP-UX 9.x
+Linux 1.x, 2.x
+BSD/OS 2.1
+Mac OS X (10.0 and above)
+
+If your system is not listed, don’t despair; because of the autoconf program,
+tbaMUD will compile under most versions of UNIX on its own. A large effort was
+made to make tbaMUD more portable by converting many of its system calls over
+to POSIX compliance. Converting tbaMUD to POSIX vastly helps portability on
+modern operating systems, most of which are POSIX-compliant. Unfortunately,
+on some older systems that are not (such as NextSTEP 2.x), it may be more
+difficult to compile than it was to compile earlier versions of the code.
+(POSIX stands for Portable Operating System Interface for UNIX and is an effort
+to standardize the way UNIX programs talk to the operating system. For more
+information, see Stevens’ excellent book, Advanced Programming in the UNIX
+Environment.)
+
+For a small, private MUD, or a MUD used only for testing and development, about
+20 MB of disk space and 32 MB of memory should be sufficient. For large, public
+MUDs with a large player base, 30 to 50MB of disk space and at least 50 MB of
+memory are recommended. Free memory is much more important than CPU speed;
+tbaMUD uses virtually no CPU time.
+
+Historically, tbaMUD has always been developed under different variants of UNIX.
+The original CircleMUD was run on a DECstation 3100 running Ultrix 4.0, which
+remained Circle’s development platform until v2.0. Starting with v2.0, Circle
+was developed under various versions of Linux and Solaris over the years
+ranging from Linux 0.99.11 through the current Linux 2.2.x and including
+Solaris x86 5.6.
+
+2.2 Downloading and Unpacking the Source
+The first step in setting up tbaMUD is to make sure you have the most recent
+version of the source. You can always find the most recent version of the
+source at tbaMUD’s official website http://tbamud.com.
+
+Next, unpack the archive. If you have the .tar.gz version, unpack it using gzip
+(GNU unzip) and the tar archiver. If you don’t already have them, both of these
+utilities can be downloaded from the GNU FTP site .
+To unpack the archive on a UNIX system, type:
+
+gzip -dc tbaMUD-xxx.tar.gz | tar xvf
+
+If you downloaded the .zip version, make sure to use an UNZIP program capable
+of handling long filenames and which preserves the original directory structure
+of the archive.
+
+For the next few sections, please note that the Cygnus Tools (Cygwin) are
+available for the Windows platform, which allow users to use Unix tools on that
+operating system.
+
+2.3 Configuring tbaMUD
+Note: This section applies only to UNIX users. If you’re using Windows, OS/2, or
+the Amiga, read README.WIN, README.OS2 or README.AMIGA instead.
+
+tbaMUD must be configured using the configure program which attempts to guess
+correct values for various system-dependent variables used during compilation.
+It uses those values to create Makefiles and a header file called conf.h.
+
+From tbaMUD’s root directory, simply type
+
+./configure
+
+If you’re using csh, it may not execute “configure” properly, giving you an
+error message like “Permission denied”. If this occurs, try “sh ./configure”
+instead.
+
+configure can take several minutes to run if you’re using a slow computer. It
+will print out various status messages while it works, telling you what
+characteristics of your computer it has found. It should create two Makefiles
+(src/Makefile and src/util/Makefile) and one header file (src/conf.h).
+
+You should only need to run configure once – right after you unpack tbaMUD from
+its archive. You will probably compile the source dozens of times as you add
+new features, but configure only needs to be run before the first time you
+compile. Please note that there is one exception to this rule: if you move your
+MUD to a different computer, you must run configure again before you can
+recompile the source code. To rerun configure after moving the source, make
+sure to delete the file called config.cache and then run configure again.
+
+2.4 Compiling tbaMUD
+Note: This section applies only to UNIX or Cygwin users. If you’re using
+windows, OS/2, or the Amiga, read README.WIN, README.OS2, or README.AMIGA instead.
+
+The src directory contains the source code for the main MUD server; src/util has
+the source for a dozen or so MUD maintenance utilities. There are two Makefiles,
+one in each source directory, but all compiling is normally performed from the
+src directory only. To compile the only tbaMUD server itself, type “make”.
+Use “make utils” to compile the utilities, or “make all” to compile both the
+server and the utilities. It is also possible to compile individual
+utilities from the src/util directory: from src/util, type “make
+[utility-name]”. All compiled binaries go to the bin directory.
+
+The stock (unmodified) tbaMUD code should compile with no warnings or errors.
+
+Despite my best efforts there’s a chance that you’ll have problems compiling
+tbaMUD if you’re using some version of UNIX that I’ve never seen before. It’s
+impossible to give general advice on how to port software, except to say that
+you should ask a friend who knows a lot about both UNIX and C to help you.
+Also, if you have problems, you should definitely look at the tbaMUD FAQ
+(Frequently Asked Questions list with Answers), which you’ll find in tbaMUD’s
+/doc directory.
+
+If you do port tbaMUD to some other platform successfully, please share your
+hard work with others by sending a description of what you had to do to get
+tbaMUD to compile on your system to rumble@tbamud.com. Be sure to include the
+specific name of your operating system and hardware. Full details on porting to
+a new system can be found in Porting.txt.
+
+The Makefile directs all compiled programs to the /bin directory. Although not
+recommended, you may want to put tbaMUD’s /bin directory in your $PATH. The
+reason that this is not recommended is that most of the resources are
+referenced using relative paths, and thus require that you run the programs
+from the base tbaMUD directory.
+
+3 Running tbaMUD
+Note: This section applies only to UNIX or Cygwin users. If you’re using
+Windows, OS/2, or the Amiga, read README.WIN, README.OS2, or EADME.AMIGA
+instead.
+
+3.1 Execution and autorun
+1. type ’autorun &’
+2. Wait a few moments for the server to boot.
+3. type: telnet localhost 4000
+tbaMUD should always be run from tbaMUD’s “root” directory, not the /bin
+directory. You can run it manually by typing bin/circle (useful for testing and
+debugging). For running the game “for real,” it is better to use the autorun
+shell script provided in tbaMUD’s root directory.
+
+Autorun lets tbaMUD run itself for long periods of time. It continuously runs
+the game as well as removing old system logs, moving newer system logs to the
+log directory, and saving certain log entries to permanent files.
+
+Autorun can be controlled by creating files with certain names. You can use the
+’touch’ command to create a file, and, of course, the ’rm’ command to remove a
+file. If a file called ’.fastboot’ exists, the tbaMUD will reboot immediately
+if it crashes or is shut down instead of waiting 40 seconds as it normally does.
+A file called ’.killscript’ will cause the script to terminate itself; i.e. if
+you want to bring the game down. If you want to temporarily prevent the MUD
+from rebooting, create a file called “pause”; the script will go into a wait
+loop until ’pause’ is removed.
+
+Although you can create these files manually, the shutdown command from within
+the MUD has several options which will create these files for you. See the
+shutdown help entry for more information.
+
+3.2 Command-Line Options
+tbaMUD recognizes a number of command-line options. You can use them by actually
+specifying them on the command-line when running tbaMUD manually or, by adding
+them to the FLAGS variable in your autorun script to use the options
+automatically every time you run the MUD with autorun.
+
+The syntax is:
+circle [-m] [-q] [-r] [-s] [-d ] [-p]
+
+-m Mini-Mud Mode. Mini-mud will be one of your most powerful debugging tools; it
+causes tbaMUD to boot with an abridged world, cutting the boot time down to a
+few seconds. It is useful for testing features which are not world-related (i.e,
+new commands or spells). tbaMUD uses split world files (in the lib/world
+hierarchy); each directory (i.e. wld, obj, mob, shp, trg, and zon) has a file
+called "index" which specifies which files should be loaded at boot-time. The
+file "index.mini" specifies which parts of the world should be loaded with the
+-m option.
+
+-q Quick Boot. Prevents checking of timed out object files. Every time tbaMUD
+boots, it checks every object file to see if it has timed out; if so, it is
+deleted. This is done primarily to save disk space. If time is more important
+to you than space, use the -q option. -q is automatically activated when you
+use -m.
+
+-r Restricted Game. Allows you to decide at run-time whether or not the game
+will allow new characters to be created. Using -r is equivalent to typing
+"wizlock 1."
+
+-s Special Routines Disabled. Allows you to suppress the assigning and calling
+of all mobile, object, and world special procedures. Historically used as a
+debugging tool in conjunction with the -d option (see below), but now obsolete
+because tbaMUD checks to make sure entities exist before attempting to assign a
+special procedure to them.
+
+-d Data Directory. Useful as a debugging and development tool, if you want to
+keep one or more sets of game data in addition to the standard set, and choose
+which set is to be used at runtime. For example, you may wish to make a copy of
+the entire world in a separate directory, so that you can test additions to the
+world files without subjecting players to unnecessary hazards. The default data
+directory is ’lib.’ Any core dumps (may they never happen to you!) will take
+place in the selected data directory.
+
+-p Port Selection. Allows you to choose on which port the game is to listen
+for connections. The default port is 4000, which is historically the port used
+by most DikuMuds. You can change the default in CEDIT and the PORT= line of the
+autorun script. (The PORT= line of config.c is ignored if it is set in CEDIT.)
+The port specified on the command line or by the autorun script will take
+precedence over the port specified in CEDIT or config.c.
+
+3.3 Creating an Implementor Character
+The first character to log in to the MUD will be made the maximum (Implementor)
+level. If you log in and aren’t made an implementor, then the playerfile
+probably is not empty – take the MUD down, delete the index at
+tbamud\lib\plrfiles, and start the MUD again. You should fix your stats using
+the RESTORE command when you first create the character (i.e. type "RESTORE
+".
+
+Once you are logged in as an implementor, type WIZHELP for a list of privileged
+commands. In-depth helpfiles exist for all commands.
+
+To create additional wizard characters, log them in normally as level 1. Then,
+advance them using your implementor character, using the ADVANCE command.
+
+4 Customizing tbaMUD
+Once you get over the initial euphoria of having your own MUD compile and run
+successfully for the first time, you should be aware of some of the files which
+control how tbaMUD looks and feels so that you can configure it for your
+personal taste.
+
+4.1 CEDIT and config.c
+The first thing you should do is test out the online configuration editor;
+CEDIT. Go through all of the menus and setup your MUD as you desire. This will
+cover loadrooms, messages, PK, PT, etc. CEDIT replaces the required manual
+editing of config.c, make, and reboot. But you should be familiar with both.
+CEDIT info is saved and takes precedence over settings in config.c
+
+4.2 TEDIT and Text Files
+The lib/text directory contains all of the text files read by players. All of
+these files can be edited online by using the text editor TEDIT. The most
+visible file is “motd”, (Message Of The Day), which is the message that mortals
+see (though not necessarily read!) when they log in. Similarly, the “imotd”
+(Immortal MOTD) is seen by immortals when they log in. Other interesting
+files are “news” (for the NEWS command), “help” (for the HELP command with no
+arguments), and others.
+
+One file is particularly important: “policy”. Despite what anyone tells you,
+and your best efforts to the contrary, your MUD will have political problems.
+If anyone tells you that you can run a MUD without politics, they’re wrong. If
+you tell your players that you’re going to run a revolutionary MUD that doesn’t
+have any politics, you’re lying. Every MUD has political problems sooner or
+later. Unfortunately, this usually occurs “sooner”. There are various ways to
+make political problems easier to handle, but the best way is to decide on some
+ground rules from the very beginning, and then set those decisions down in
+writing. That’s what the “policy” file is for. You probably know what kind of
+political problems MUDs have (you are not trying to run a MUD without ever
+having played one, are you!?) – stuff like playerkilling, thieving, kill
+stealing, client use, multiplaying, reimbursements, etc. Decide on your
+policies early and make sure your characters know what those policies are.
+
+It is also important to write down a set of rules dictating what immortals are
+allowed to do and not allowed to do. That’s what the “handbook” (Immortal
+handbook) is for. Immortals will always try to bend you as far as they can, so
+it’s important for you to decide on answers to questions before those questions
+come up. Can immortals assist players? What about giving a single ’cure light’
+for a player about to die? Can immortals kill mobiles for their own enjoyment?
+Can they kill players for the same reason? Are they allowed to make policy?
+Break policy? Moderate disputes? Turn over each others’ decisions?
+
+4.3 World Files
+The root of the area hierarchy is lib/world/. lib/world/ has 6 subdirectories:
+wld, mob, obj, shp, trg, and zon, which is where the world, mobile, object,
+shop, trigger, and zone files go, respectively.
+
+Each directory has a set of world files in it with the appropriate extension
+(i.e. the obj subdir will have a bunch of files ending with “.obj”, such as
+30.obj, 31.obj, etc.) plus two special files called “index” and “index.mini”.
+“index” is a list of which world files are to be loaded by tbaMUD. New zones
+can be added in game with the "zedit new" command. “index.mini” controls which
+(smaller) set of world files should be loaded in the debugging mode (Mini-Mud
+Mode, explained below.)
+
+5 System Logs
+tbaMUD writes a wide variety of information to standard output and standard
+error. If you’re using the autorun script, the boot messages are put into a
+file called “syslog”. During tbaMUD’s boot sequence, the system log keeps a
+record of everything the MUD is doing to initialize itself; this can be useful
+to determine what the problem is if the MUD dies while it is booting. Once the
+game is up and running, the syslog contains player information, recording when
+players connect, disconnect, rent, unrent, quit, die, hit death traps, etc. The
+game also records status information about itself, falling generally into two
+categories: usage information and errors.
+
+5.1 Player Information
+The player information recorded by tbaMUD’s system logs will serve you very well
+as your players start to make wild claims about strange bugs resulting in them
+losing equipment or points. Many mudders prey on the insecurities of a new mud
+administrator who is terrified that his or her MUD is riddled with bugs and
+will do anything to satisfy grumpy players – don’t let yourself fall into that
+trap! tbaMUD is bound to contain bugs, but most of the core systems have been
+well tested, so you should take claims such as “I magically lost all my stuff!”
+with a grain of salt and check your system logs.
+
+If a player ever asks you for reimbursement of equipment, money, gold,
+experience points (XP), or whatever, your gut reaction should always be to
+check the logs first.
+
+As a sidebar, let me point out that the value of system logs is twofold: 1)
+they actually provide you with valuable information, and 2) they make your
+players paranoid. When I first started mudding and I heard about this
+mysterious “system log”, it made me incredibly paranoid. Now that I’ve done a
+good deal of MUD administration, I’ve seen the same paranoia in many other
+players.
+
+That paranoia is a very good thing. The system logs become an abstract and
+shapeless but omnipresent force on the MUD. Players hear about “the System Log”
+and then get paranoid that everything they do is being recorded, so they tend
+to behave, lest the evil System Log betray their wrongdoings to the Gods.
+
+For this reason, when you go to check your logs, it’s a good idea to say something like “Hold on... let me go check the system logs, OK?” because it
+reinforces the syslog’s presence in the collective psyche of your players.
+
+Back to the point. When someone claims that they’ve been wronged by the evil
+system, always check the logs. The logs give you power to say things like “What
+do you mean your items disappeared in rent? It says right here in the logs
+‘Rasmussen has quit the game.’ You did not rent at all, you just quit!”
+
+To diffuse disputes such as, “The game dumped my stuff, but I had enough
+money!!” or “I logged in and my stuff was gone, there must be a bug!!”, two
+types of log entries are written. First, every time a character rents, the log
+records the character’s per diem rent rate as well as the total amount of money
+on hand and in the bank. Second, the log records makes a record of all
+characters’ equipment dumped due to insufficient funds.
+
+Remember, rent is specified as a daily rate but is amortized on a per-second
+basis! In other words, if you rent at the rate of 100 coins per day and come
+back 36 hours later, you’ll be charged 150 coins. Or you can be nice and leave
+rent disabled.
+
+The autorunscript saves 6 levels of raw system logs. In addition, it greps the
+logs for certain pieces of extra-juicy information to save indefinitely.
+
+The system logs are your friends. Love them.
+
+5.2 Usage Information
+Every 5 minutes, the game counts how many people are playing and records that
+information in the system log. Optionally, if you define RUSAGE in comm.c, it
+will also record system resource information such as CPU time and memory used.
+The usage information currently logged by tbaMUD is, as you can see, somewhat
+sparse; local MUD admins are encouraged to add to this code as is appropriate
+for their particular site.
+
+Usage information isn’t critical, but it is interesting to look at the usage
+patterns to determine when your peak playing hours are. If you’re good at using
+‘cut’ and other Unix utilities, you can even dazzle your friends by graphing
+your MUD’s system usage.
+
+Note: friends not included with the tbaMUD distribution.
+
+5.3 Errors
+Just as your first gut instinct should be to look at the logs if a player starts
+begging you for something, your first gut instinct in the event of a crash or
+unexpected shutdown should also be to look at the system logs.
+
+A Unix utility called ‘tail’ is used to look at the last few lines of a text
+file; it is very useful for looking at the last entries in the system log to
+see the last thing that happened before the shutdown. This can be done in game
+with the "file" command by using the "file crash" option. Often, tbaMUD will
+report an error in the logs just before it crashes. This method is particularly
+useful if the MUD crashes during its boot sequence, because the logging during
+boot is intensive.
+
+If tbaMUD shuts down unexpectedly and there is no core dump in the /lib
+directory, the game probably detected an internal error and killed itself. Such
+shutdowns are always preceded by entries in the system log describing the error.
+
+If there is no error message at the end of the log, then there probably IS a
+core dump, so you can use ‘gdb’ to examine the core dump and determine the
+reason for the crash. The file hacker.txt, generously provided by Furey of MERC
+Industries, offers useful insight into the art and science of debugging – you’d
+be well advised to give it a look-see.
+
+tbaMUD sometimes encounters a serious but non-fatal error; in this case, the
+error will be written to the system log with the prefix SYSERR, but the MUD
+will not shut itself down. You should always be aware of any SYSERRs which occur
+– they are often useful for foreseeing imminent danger or averting problems
+before they become critical. If a SYSERR does occur, try to determine if a
+change you’ve made recently has caused it. Ignoring SYSERRs is like ignoring
+compiler warnings: you can be tempted to ignore them because the game keeps
+going even if they exist, but you can easily get yourself into trouble by not
+listening. The autorun script saves all SYSERRs to the file log/errors.
+
+6 MUD Maintenance
+6.1 Technical Maintenance
+Once you get the MUD up and running, you will surely want to modify it – adding
+new areas, new features, new code, and new ideas, however these topics are
+beyond the scope of this document. See coding.txt, building.txt, and other
+documents in the /doc directory and online at http://tbamud.com. This section
+focuses on some of the simple maintenance that’ll be necessary to keep your MUD
+running smoothly. Make sure not to get so caught up in being a God that you
+forgot you’re also supposed to be acting as a software engineer!
+
+First, you should look at the log/errors file regularly to make sure there are
+no recurring problems, particularly problems that may have been caused by code
+you’ve added. If the MUD crashes, it will usually generate what is called a
+“core dump” – a big file called “core.#” in your lib directory, created by the
+operating system to record the state the game was in the moment before it
+crashed. You should look at the core dump using a debugger such as “gdb” to
+determine why the MUD crashed. See the file “hacker.txt” for more information
+about debugging.
+
+6.2 Diplomatic Maintenance
+Okay, so now you have your wonderful tbaMUD up and running smoothly and all is
+right with the world. Right? Wrong.
+
+Well, technically, right. tbaMUD requires very little day-to-day attention in
+order to keep the program itself running smoothly. But the MUD itself is just a
+series of instructions running on a computer, processing data. Never lose sight
+of the fact that there will be dozens, hundreds, or maybe even thousands of
+people connecting to your MUD – and they are not programs. They are people!
+
+From the technical side, there are relatively few things you have to do to keep
+the game running. But you cannot just dump a MUD on the Internet and then ignore
+it! Spend time on your MUD. Try to keep up with the boards, and make an effort
+to respond to the complaints. Take a look at the ‘bug’, ‘typo’, and ‘idea’ files
+from time to time – and respond to some of the ideas using Mudmail. Try to
+respond to Mudmail you receive from players in a timely manner. Make sure that
+your ‘news’, ‘policy’ and other text files are up-to date and suit the political
+climate on your MUD.
+
+If you cannot or just do not want to deal with the player politics, make sure
+that you choose someone who can and will, and make them responsible for dealing
+with it. If no one does it, your MUD will stagnate and die.
+
+7 Final Thoughts
+Try to remember that running a MUD should be fun. It can sometimes be easy to
+lose sight of the ultimate goal of personal enjoyment that MUDs are supposed to
+provide, particularly when MUDs start to get crushed under the weight of their
+own politics or the egos of the administrators. If you find that your MUD is
+more of a source of frustration than enjoyment, don’t be afraid to close it.
+
+Good luck with your MUD! Always feel free to email or stop by The Builder
+Academy and let us know what you think of the MUD, and the interesting things
+you’ve done with it. We cannot promise a timely response, but we love hearing
+from people who are using our code.
+
+For further information and updates check out http://tbamud.com.
\ No newline at end of file
diff --git a/doc/building.pdf b/doc/building.pdf
deleted file mode 100644
index 4f22972..0000000
Binary files a/doc/building.pdf and /dev/null differ
diff --git a/doc/building.txt b/doc/building.txt
new file mode 100644
index 0000000..8b19742
--- /dev/null
+++ b/doc/building.txt
@@ -0,0 +1,1903 @@
+If you have any additions, corrections, ideas, or bug reports please stop by the
+Builder Academy at telnet://tbamud.com:9091 or email rumble@tbamud.com -- Rumble
+
+The tbaMUD Builder’s Manual
+Originall by Jeremy Elson
+
+This document describes how to create tbaMUD areas, and specifies the file
+formats for worlds, monsters, objects, shops, triggers, and zones, as well as
+providing examples of each. All information necessary to build worlds can be
+found in this document.
+
+The intended audience is world builders interested in creating new worlds,
+implementors who need to decode existing world files, and coders extending the
+current world specification. Thanks to Jeff Fink (Teker) for documenting the
+shop format (as well as for submitting the shop code itself!), and Alex Fletcher
+(Furry) for writing parts of the Introduction.
+
+More information about tbaMUD can be found at the http://tbamud.com
+
+Contents
+
+1 Introduction
+
+1.1 Your Job as a Tiny World Architect
+1.2 Game Balance
+1.3 Making Your Areas Interesting
+1.4 Using World-Building Programs
+
+2 The Mechanics of World Building
+2.1 Overview of the MUD World
+2.2 Learning By Example
+2.3 tbaMUD World Files
+2.4 Using Bitvectors
+2.5 Adding New Areas to the MUD
+
+3 World (Room) Files
+3.1 The Format of a Room
+3.2 The Direction Field
+3.3 Room Extra Descriptions
+3.4 World File Example
+
+4 Mobile (Monster) Files
+4.1 The Format of a Mobile
+4.2 Type S Mobiles
+4.3 Type S Mobile Example
+4.4 Type E Mobiles
+4.5 Type E Mobile Example
+4.6 E-Spec Keywords Valid in tbaMUD
+
+5 Object Files
+5.1 The Format of an Object
+5.2 Object Value Definitions
+5.3 Object Extra Descriptions
+5.4 Object Affect Fields
+5.5 Object File Example
+
+6 Zone Files
+6.1 The Format of a Zone File
+6.2 Zone Commands
+6.3 Zone File Example
+
+7 Shop Files
+7.1 tbaMUD v3 Shop Format
+7.2 Item Name Lists for v3 Shops
+7.3 The DikuMud Gamma and tbaMUD 2.20 Shop Format
+
+8 Trigger Files
+8.1 The Format of a Trigger File
+8.2 Trigger File Example
+
+A Spell Numbers
+B Item Values for Drink Containers
+
+1 Introduction
+
+This file explains the in-depth details of how to modify the World files manually.
+Thanks to our robust on-line creation system this is rarely, if ever, necessary.
+But, there are many good building tips and tricks throughout that need to be
+saved. So read on and be thankful that you no longer have to build by writing
+in these special formats in a text editor. Rejoice for we have menu driven
+OLC in game to make building so much easier.
+
+1.1 Your Job as a Tinyworld Architect
+As a Tinyworld Architect or Builder, your job is to create the virtual world in
+which players can roam around, solve puzzles, find treasures, and gain
+experience. A Builder creates the rooms, objects, and monsters with which
+players will interact, defining their textual descriptions, stats, abilities,
+and other special properties. A Builder should not be confused with the MUD’s
+Coder, whose job it is to modify the C code that makes the tbaMUD server
+actually run. A Builder does not need to be a programmer, and building is not
+programming; building is done via online creation in game, which this document
+describes in detail.
+
+There is a standard world included with the tbaMUD distribution which is
+intended to serve as a stepping stone and a basic guide to demonstrate what
+kind of worlds you can build for your MUD. To only use the standard tbaMUD
+world, without adding any original work, is to guarantee your MUD will be
+boring and largely ignored. MUDs are judged in many ways, but one of the most
+important is the number and quality of areas available. The areas are what
+tend to make a MUD original. For example, one MUD could be based upon a magic
+rich world and the code and areas would reflect this, while another could
+revolve around cities and thieves. Each of these MUDs would have its areas
+designed in such a way to flesh out this theme. In essence, building an area
+is like writing a book. It needs to have a plot, needs to be descriptive, and
+needs to be populated with memorable people and places.
+
+Writing an area requires inspiration and imagination before all else. Ideas for
+areas often come from literature; for example, an area that traces Alice’s
+adventures through Wonderland or Dante’s trip through the Inferno. Areas
+usually start out on paper long before they reach a computer; a general map of
+the region can help to solidify the idea and a specific map of each individual
+room is absolutely required so that the rooms can be linked together in a way
+that makes sense geographically. Taking notes on ideas for which monsters
+should be encountered in the area, their descriptions, and in what location
+the monsters should appear can also help when planning an area.
+
+1.2 Game Balance
+Game Balance is a term that brings a different thing to mind for every person
+that hears it. What is most important about game balance is to keep in mind for
+whom each area is designed – for example, high level players, newbies, or small
+groups. The objects and monsters found in the area should match the level,
+abilities, and needs of the players expected to use the area. Most players do
+not like to be given vast treasure with no difficulty in getting it, but on the
+other hand, nobody likes to fight the most difficult monster on the MUD and get
+nothing for doing it. The job of the chief builder of a MUD and the authors of
+the individual areas is to find a happy medium between these two extremes. The
+process of finding that medium on your MUD is what makes MUDs original.
+
+The main factor that affects game balance is the areas that make up the MUD.
+Because of this, each area should be checked against the others to ensure that
+one area is not impossibly hard or absurdly easy or rewarding relative to the
+rest of the world. Each area that comes with the MUD or is added later should
+be checked by one or more implementors or builders, and the characteristics
+of the monsters and objects should be changed to suit to the balance of the
+MUD. Each new area that becomes part of the world should not be added until it
+has been similarly balanced to the implementors’ satisfaction. Understandably,
+builders want their zones to be popular, but they sometimes attempt to achieve
+this goal by purposefully making their zone unbalanced, adding powerful weapons
+or armor with no harmful side-effects or monsters that are easy to kill yet
+give massive numbers of experience points. Such zones are destined both to
+become very popular and invariably to bring about the death of your MUD’s game
+balance.
+
+An area’s balance should be an integral part of the design process, not
+something to be tacked on as an afterthought. Too often, an area will be
+designed with outrageously good weapons and armor which throws off the balance
+of the game. Naturally, after such zone is added, players complain bitterly if
+it is ever removed or toned down. Also, because the rent system saves hitrolls,
+damrolls, and ac-apply’s, veteran players will be able to hold on to their old,
+spectacular equipment unless it is explicitly taken from them, even after the
+area has been changed. This does nothing but generate bad feelings on all
+sides. Therefore, the wise implementor will always carefully check a zone for
+balance before it is added to the production MUD. It is generally not a good
+idea to “let the players balance the area” by unleashing an unbalanced area on
+them and watching to see where the hordes of players go.
+
+1.3 Making Your Areas Interesting
+An interesting area will always attract more players than a bland one. There
+are many ways to make an area interesting. Try to be as descriptive as
+possible; don’t hold back on writing extra descriptions. Players are so
+accustomed to not having richly described areas that finding an extra
+description can often be a real treat. Also, one oft forgotten thing to
+describe are the door exits. Describing all of these can give a feel of
+standing out in a field and looking off to the north and seeing something like:
+
+The fields stretch off towards the large hills on the horizon. Far to the north
+you see what appears to be a plume of smoke.
+
+With door descriptions like these, an area will feel more fleshed out to the
+player. Many players (both experienced and first timers) read the descriptions
+carefully the first time they walk through an area, and having many extra
+descriptions helps them fill out their idea of what things actually look like.
+
+One thing that should never be done is to have generic room descriptions like
+“You stand in a big room. It is very dark.” Descriptions like these detract in
+general from the rest of the world, and if they are found room after room can
+bore a player to tears. Such a description could be changed to:
+
+You stand in a room of very large size. Shadows cower along the walls and
+almost seem to be moving as you look around yourself. The floor is made of
+heavy stones which are very dark in color. The ceiling is quite some distance
+above you, but you can still make out objects hanging from it, ruining the
+smoothness that is characteristic of the rest of the room.
+
+Another way to make an area interesting is to create some sort of plot line for
+it, or a coherent theme, rather than a collection of haphazardly related rooms.
+The plot can be complex like infiltrating a castle to garner the war plans of
+the evil Lord Zygol, simple like ridding the caves of goblins, or anything in
+between. Often the plot in an area can be advanced by some fairly simple
+puzzles or descriptions. With the addition of triggers, involved puzzles
+and quest can be readily created. Not all monsters have to be designed to be
+killed, nor does every shopkeeper have to buy or sell something – they could
+just be created so that they refuse to trade with any player characters. The
+players will then wonder why the shopkeeper exists. Perhaps giving him a jewel
+will make him more friendly. In this way, an area can be made infinitely more
+exciting by using triggers. Perhaps random teleporters throughout the area,
+perhaps some interactive monsters that respond to questions from players.
+
+All in all, the best way to make an area interesting is to use variety,
+intelligence, and imagination in building. Try to imagine what it would be
+like for you to walk through and what you might try looking at or doing, and
+then try to incorporate that into your area. Show your area to others and take
+their advice. By taking all of this extra effort in creating your area, you
+will be rewarded by leaving a lasting memory of your area in the minds of many
+players.
+
+1.4 Using World-Building Programs
+In the old days, the only tool that was used to write a MUD area was a simple
+text editor. However, in the course of time, various people have written
+programs to help builders create worlds without having to understand the
+complex details of the world file format. These World building programs have
+since become outdated and are no longer developed. For todays builders we have
+a fully integrated menu based on-line creation system (aka OLC) to make
+building as hassle free as possible.
+
+2 The Mechanics of World Building
+
+2.1 Overview of the MUD World
+tbaMUD’s world is divided into distinct sections called zones. Each zone
+typically consists of a single, modular, geographically coherent region of the
+MUD’s virtual world with a consistent storyline. Each zone can define its own
+physical space (the world), monsters (usually called mobiles), objects (such as
+armor, weapons and treasures), triggers (what we use to create interaction
+with players) and shops, in which a mobile in a particular room can buy and
+sell objects to players.
+
+A single zone typically contains up to than 100 rooms, 100 monster definitions
+and 100 object definitions, but a large region can be subdivided into several
+zones at the author’s discretion. For example, the City of Midgaard is divided
+into two zones, one for the main city and one for the southern residential area.
+In addition to this, with the new zone system describing top and bottom rooms
+of a zone, zones can contain very few rooms and indeed can overlap with other
+zones if desired. A zone can also use mobiles and objects defined by another
+zone, but this practice is discouraged because it makes zones less modular,
+meaning that it becomes more difficult to add or remove one zone without
+affecting another zone.
+
+Each room, mobile and object within a zone is given a unique number called a
+Virtual Number or Vnum. The Vnums for the rooms, mobiles and objects are
+independent, so there can be both a room number 3001 and an object number
+3001. When defining and referencing parts of a zone, the zone author always
+refers to each entity by its Vnum and never by name. Vnums are normally not
+seen by players. Each zone itself also has a Vnum. A common convention is to
+number the zone with the Vnums of its component rooms, divided by 100. For
+example, Midgaard is zone 30, consisting of rooms 3000 to 3099. Mobile and
+object numbering follows the same convention.
+
+The author of the zone can define aspects of each room such as the terrain type,
+special properties like whether the room has its own light source or is a death
+trap, and other parameters. A very important aspect of each room is the
+position of other rooms in relation to it; for example, from room 3014, one can
+go north to reach room 3005, east to room 3015, etc. Great care should be given
+to making the room links logical and consistent. A player who moves east and
+then immediately west should find herself back in the same room in which she
+started.
+
+Each mobile is given characteristics such as number of hit points, bare hand
+damage capability, strength, and special skills and abilities. Objects have
+parameters such as weight, value, and magical properties. The author can also
+choose how these three pieces of the world are combined to form the initial
+state of the zone: for example, the number of each mobile that exist and in
+which rooms they stand, the equipment that each mobile uses, objects which
+might be on the floor, and the doors which may be initially locked or unlocked.
+
+When the tbaMUD server runs the zone, it sets each zone to its initial state as
+defined by the author, and then makes the zone “come alive” by randomly making
+mobiles wander through the zone and, if desired, attack players. While the
+players are using the zone (killing the mobiles and picking up equipment) the
+server periodically resets the zone to its initial state (a zone reset) to
+prepare the zone for the next group of players.
+
+2.2 Learning By Example
+Thanks to the new online creation system the only time you need to worry about
+the format of World files is when you are converting non-compatible zones into
+a tbaMUD or the other way around. Older versions of CircleMUD and other
+codebases use a different format so to add these zones you will have to
+understand and modify them to work. The following section is for coders who
+need to change the actual World files. Builders will not need to do this.
+
+The formats of the world files are sufficiently complex that it is probably not
+possible to gain a complete understanding of them merely by reading this
+documentation. This document is designed to be a reference manual and therefore
+may not serve as a particularly good tutorial. While there are examples
+provided at the end of each section, they are only meant to be representative
+and are not comprehensive examples of all possible ways to use the features
+that will be described. The most effective way is to learn by example: examine
+some of the areas that come with tbaMUD and try to figure out the meanings of
+the numbers in different rooms, objects, mobiles, and zone files, using this
+manual as a guide. Once you’re proficient at reading world files, you’ll find
+that creating them is a much easier task.
+
+2.3 tbaMUD World Files
+Each tbaMUD zone is defined by six types of files: world files, mobile files,
+object files, shop files, trigger files, and zone files. World files (*.wld)
+define the actual rooms and the links from one room to another. Mobiles (*.mob)
+are the monsters which inhabit the MUD. Objects (*.obj) are the weapons, armor,
+treasure, and other objects manipulated by players and monsters. Shop files
+(*.shp) define the MUD’s shopkeepers, controlling what they buy, sell, and say.
+Trigger files (*.trg) allow interaction between players and rooms, mobs, or
+objects. Finally, Zone files (*.zon) bring all the previous elements together
+to define the initial state of the zone, describing how monsters should be
+equipped, where monsters should be placed, where objects on the ground should
+be, which doors should be locked, etc. These five types of files are
+collectively referred to as the world files.
+
+tbaMUD uses split world files to make the world easier to manipulate. Instead
+of all the rooms being lumped together in a single, cumbersome file, the rooms
+are split into many different files, one file for each area of the world. All
+six types of files are split in a similar manner. tbaMUD has one directory for
+the room files (lib/world/wld/), one directory for the object files
+(lib/world/obj/), and so forth.
+
+tbaMUD doesn’t care how the world files are split or what the names of the
+files are, but certain conventions have developed to make management of the
+world easier. Each file typically contains information for only a single zone
+and the filename is typically the zone number, with an extension indicating
+one of the 6 file types. For example, the file 30.wld contains rooms 3000 to
+3099 of zone 30; 42.mob contains mobiles 4200 to 4299 of zone 42, etc.
+
+Also in each of these directories is a file called “index” that tells the
+server which files from that directory should be loaded when the server boots
+and a file called “index.mini” which (minimal) set of files should be loaded
+when the server is booted with the -m option.
+
+Every world file used by tbaMUD (including the index files) must be terminated
+by the dollar sign ($) to tell the server that the file has ended. Without the
+dollar sign, the server will not boot properly.
+
+2.4 Using Bitvectors
+When learning about the formats of tbaMUD world files, you’ll frequently see
+references to bitvectors. A bitvector is a group of flags which each can be
+either on or off. Bitvectors and their flags are used in many ways within
+tbaMUD, such as to define the personality of mobiles, the characteristics of
+rooms, etc. Understanding how to use bitvectors is essential if you need to
+modify a tbaMUD world.
+
+At every point where this document says a bitvector is required, it will be
+accompanied by a table describing the flags which you can use with that
+bitvector. The table will look something like this:
+
+1 a DIRTY The room is dirty.
+2 b STINKY The room stinks.
+4 c MUSHY The floor of the room feels mushy.
+8 d SWAMPY The room resembles a swamp.
+
+Note there are four columns in the table. The first column contains the numeric
+value of the flag. The second contains the alphabetic representation of the
+flag. The third is the name of the flag, and the fourth is a description of
+what the flag does.
+
+There are two ways you can construct a bitvector with the table above: the
+numeric method and the alphabetic method. The numeric method is to select all
+flags you’d like to activate, take the numbers of those flags as listed in the
+first column of the table, and add them all up. The resulting sum will be the
+bitvector. The alphabetic method is much easier: just write down all the
+letters of the flags you’d like to use with no spaces in between. For both
+numeric and alphabetic bitvectors, use “0” to indicate a bitvector where none
+of the flags are set.
+
+For example, imagine you want to create a room that is dirty, mushy, and
+resembles a swamp, but does not stink. Using the numeric method, you’d look up
+the numbers of those three flags (1 for dirty, 4 for mushy, and 8 for swampy),
+and add them up to get 13. Using the alphabetic method, the bitvector would
+simply be “acd”. Bitvectors are case-sensitive; “acd” is very different from
+“Acd” and “ACD”.
+
+At every point where the tbaMUD format requires a bitvector, you can write
+either a numeric bitvector or an alphabetic bitvector. They are completely
+interchangeable. However, be forewarned that if you use alphabetic bitvectors,
+your area will not be compatible with MUDs based on the original DikuMud.
+Alphabetic bitvectors are a tbaMUD enhancement and may not be supported by
+MUDs based on Gamma Diku.
+
+In some bitvector tables, you will see values whose descriptions say “Reserved
+for internal use” or “Do not use”. You should never set those flag values in
+your world files.
+
+2.5 Adding New Areas to the MUD
+The following only applies when you manually add a World. The "zedit new"
+command creates all the necessary files and index entries automatically. I
+recommend even if you are adding in another area you first "zedit new" and
+then copy your new files over the existing ones. This saves you from having
+to add 6 entries into the index files.
+
+There are three steps required to add an area to the MUD:
+1. Copy the files into the proper directories.
+2. Adding the new filenames to the appropriate index files.
+3. And running the MUD to make sure the new area is formatted correctly.
+
+All world-related files go in the directory lib/world/. In this example, we
+will imagine that your new area is zone number 57 (which should consist of
+rooms, objects and mobiles numbered 5700-5799). Your zone probably has 6
+files: 57.wld, 57.mob, 57.obj, 57.shp, 57.trg, and 57.zon. The first step is
+to copy each of these files into their appropriate subdirectory: 57.wld
+should be copied to the directory lib/world/wld/; 57.mob should be copied to
+the directory lib/world/mob/, and so forth.
+
+The next step is to add the name of the newly copied world files to the index
+file contained in each of the world subdirectories. Note you will need to
+change 6 index files: one for each of the world files that you copied in the
+previous step. Adding the filenames to the index files tells tbaMUD that the
+files should be loaded; they will not be loaded simply by virtue of being in
+the correct directory. First, edit the file lib/world/wld/index; you should
+see a list of the current world (room) files. Add a single line that says
+57.wld in the correct numeric order. Next, add a similar line in the other
+index files: add 57.mob to lib/world/mob/index; etc. At the same time, if the
+area is to be a central core area for the game, it should also be added to the
+index.mini file.
+
+Now you can try to boot the MUD with the new world. Run tbaMUD via "bin/circle"
+and look for any SYSERR messages. If you receive no errors congratulations.
+Otherwise, check the tbaMUD SYSERR List for more information on how to
+correct the formatting errors. also, see the tbaMUD Administrator’s Guide for
+more information on how to run tbaMUD.
+
+3 World (Room) Files
+
+3.1 The Format of a Room
+The format of a room is:
+
+#
+~
+
+~
+
+{zero or more direction fields and/or extra descriptions}
+S
+
+There can be between 0 and 6 direction fields in the standard tbaMUD code.
+There should not be more than one direction field for a particular direction.
+For more information on adding directions to the standard “neswud”, see the
+Coding tbaMUD document. No Extra Descriptions are required but an unlimited
+number are allowed. Each room is terminated with the literal letter S.
+
+Virtual Number This number is critical; it is the identity of the room within
+the game. All other files will use this number to refer to this room. From
+within the game, this number can be used with “goto” to go to this room. The
+virtual numbers must appear in increasing order in the world file.
+
+Room Name This string is the room’s title, which is displayed before the room
+description when players look at the room, or displayed alone if players are
+using “brief.” Room Description The description of the room seen when they type
+“look,” or when they enter the room with brief mode off.
+
+Zone Number This number is obsolete and no longer used. Historically it
+contained the zone number of the current room but it is currently ignored for
+everything except debugging messages. It is maintained as part of the format
+for backwards compatibility.
+
+Room Bitvector A bitvector (see section 2.4 on ‘Using Bitvectors’), with the
+following values:
+
+1) DARK - The room is dark, players need a light source, or infravision.
+2) DEATH - Players die on entry. All dropped items will be junked.
+3) NO_MOB - Mobs will not enter this room. This can be used to define the
+ zone where any mob can wander. For example, lower level mobs
+ can be set so that only they can wander on the first level of
+ a dungeon by making the stairwells NO_MOB. A NO_MOB room will
+ also prevent pets and charmed mobs from following players.
+4) INDOORS - Weather messages will not be sent to room, always lighted.
+ Call lightning will not work.
+5) PEACEFUL - No violence will work here. Use sparingly.
+6) SOUNDPROOF - Tell, gossip, shout, holler will not be heard here. This flag
+ should be used sparingly also, it is very annoying IMHO.
+7) NO_TRACK - Track will never find a path through this room.
+8) NO_MAGIC - No magic will work here.
+9) TUNNEL - Only one person allowed at one time.
+10) PRIVATE - Only room for 2 players/mobs i.e. a tunnel or small space.
+11) GODROOM - Only allows GODS of level 33 or above to goto.
+12) HOUSE - DO NOT USE. Room is a house. \ automatically
+13) HCRSH - DO NOT USE. House needs saving. > set by
+14) ATRIUM - DO NOT USE. The door to a house. / hcontrol
+15) OLC - DO NOT USE. Is room modifiable.
+16) * - DO NOT USE. Breadth-first search mark used by track and hunt.
+
+Sector Type A single number (not a bitvector) defining the type of terrain in
+the room. Note that this value is not the number of movement points needed but
+just a number to identify the sector type (the movement loss is controlled by
+the array movement_loss[] in the file constants.c). The Sector Type can be one
+of the following:
+
+ This defines movement point, light, and boat requirements.
+The following terrains may be selected (only one):
+
+ Movement Points
+0 INSIDE Indoors (no light required) 1
+1 CITY The streets of a city. 1
+2 FIELD An open field. 2
+3 FOREST A dense forest. 3
+4 HILLS Low foothills. 4
+5 MOUNTAIN Steep mountain regions. 6
+6 WATER_SWIM Water (swimmable). 4
+7 WATER_NOSWIM Unswimmable water. Boat required. 1
+8 FLYING Wheee! Requires AFF_FLYING. 1
+9 UNDERWATER Underwater requires AFF_SCUBA. 5
+
+Direction Fields and Extra Descriptions This section defines the room’s exits,
+if any, as well as any extra descriptions such as signs or strange objects that
+might be in the room. This section can be empty if the room has no exits and no
+extra descriptions. Otherwise, it can have any number of D (Direction Field)
+and E (Extra Description) sections, in any order. After all exits and extra
+descriptions have been listed, the end of the room is signaled with the letter
+S. The Direction Fields and Extra Descriptions are described in more detail in
+the following sections.
+
+3.2 The Direction Field
+The general format of a direction field is:
+
+D
+
+~
+~
+
+
+Direction Number The compass direction that this Direction Field describes. It
+must be one of the following numbers:
+
+0 North
+1 East
+2 South
+3 West
+4 Up
+5 Down
+
+General Description The description shown to the player when she types “look
+”. This should not be confused with the room description itself.
+Unlike the room description which is automatically viewed when a player walks
+into a room, the General Description of an exit is only seen when a player
+looks in the direction of the exit (e.g., “look north”). Exit descriptions
+take priority over extra descriptions. So if you creat a extra description for
+north the player will see the exit description only when they "look north."
+
+Keyword List A list of acceptable terms that can be used to manipulate the door
+with commands such as “open,” “close,” “lock,” “unlock,” etc. The list should
+be separated by spaces, such as: door oak big~
+
+Door Flag Can take one of three values (0, 1 or 2):
+
+0 An unrestricted exit that has no door, or a special door cannot be opened or
+closed with the “open” and “close” commands. The latter is useful for secret
+doors, trap doors, or other doors that are opened and closed by something other
+than the normal commands, like a trigger assigned to the room or an object in
+the room.
+
+1 Normal doors that can be opened, closed, locked, unlocked, and picked.
+
+2 Pickproof doors: if locked, can be opened only with the key.
+
+The initial state of all doors is open, but doors can be opened, closed, and
+locked automatically when zones reset; see Section zone file documentation for
+details.
+
+Key Number The virtual number of the key required to lock and unlock the door
+in the direction given. A value of -1 means that there is no keyhole; i.e., no
+key will open this door. If the Door Flag for this door is 0, the Key Number
+is ignored.
+
+Room Linked The virtual number of the room to which this exit leads. If this
+number is -1 (NOWHERE), the exit will not actually lead anywhere; useful if
+you’d like the exit to show up on “exits,” or if you’d like to add a description
+for “look ” without actually adding an exit in that direction.
+
+3.3 Room Extra Descriptions
+Extra descriptions are used to make rooms more interesting, and make them more
+interactive. Extra descriptions are accessed by players when they type “look at
+”, where is any word you choose. For example, you might write a
+room description which includes the tantalizing sentence, “The wall looks
+strange here.” Using extra descriptions, players could then see additional
+detail by typing “look at wall.” There can be an unlimited number of Extra
+Descriptions in each room.
+
+The format of an extra description is simple:
+
+E
+~
+
+~
+
+Keyword List A space-separated list of keywords which will access the
+description in this E section.
+
+Description Text The text that will be displayed when a player types “look
+,” where is one of the keywords specified in the Keyword
+List of this Esection.
+
+3.4 World File Example
+Here is a sample entry from a tbaMUD world file:
+
+#18629
+The Red Room~
+It takes you a moment to realize that the red glow here is
+coming from a round portal on the floor. It looks almost as
+if someone had painted a picture of a dirt running through a
+field on the floor of this room. Oddly enough, it is so
+realistic you can feel the wind in the field coming out of the
+picture.
+~
+186 ad 0
+D0
+You see a big room up there.
+~
+~
+0 -1 18620
+D1
+You see a small room.
+~
+oak door~
+1 18000 18630
+E
+portal floor~
+It looks as if you could go down into it... but you can’t be
+sure of where you will end up, or if you can get back.
+~
+S
+
+This room is virtual number 18629, called “The Red Room”. It is dark and
+indoors, with an “INDOORS” sector type. It has an exit north and east. The
+north exit leads to room 18620; if a player types “look north” it will say “You
+see a big room up there.” The exit east is a normal, pickable door that leads
+to room 18630 and which takes key number 18000. There is one extra description
+for “portal” and “floor”.
+
+4 Mobile (Monster) Files
+
+4.1 The Format of a Mobile
+The format of a mobile is:
+
+#
+~
+~
+
+~
+
+~
+
+{type-specific information; see below for details}
+
+Virtual Number This number is critical; it is the identity of the mobile within
+the game. It is the number that will be used to reference the mobile from zone
+files and is the number used to “load” mobiles from within the game. The
+virtual numbers must appear in increasing order in the mob file.
+
+Keywords The list of keywords, separated by spaces, that can be used by
+players to identify the mobile. The mobile can only be identified using the
+keywords in this list; it cannot be identified by a word that appears only in
+its name. Great care should be taken to ensure that the spellings of names and
+keywords match. Fill words such as “the,” “a,” and “an” should not appear in
+the Keywords List.
+
+Short Description The description of the mobile used by the MUD when the mobile
+takes some action. For example, a short description of “The Beastly Fido” would
+result in messages such as “The Beastly Fido leaves south.” and “The Beastly
+Fido hits you hard.” The Short Description should never end with a punctuation
+mark because it will be inserted into the middle of sentences such as those
+above.
+
+Long Description The description displayed when a mobile is in its default
+position; for example, “The Beastly Fido is here, searching through garbage for
+food.” When the mobile is in a position other than its default position, such
+as sleeping or incapacitated, the short description is used instead; for
+example, “The Beastly Fido is lying here, incapacitated.” Unlike the Short
+Description, the Long Description should end with appropriate punctuation.
+
+Detailed Description The description displayed for a mobile when a player looks
+at the mobile by typing “look at .”
+
+Mob flags bitvector (see section 2.4 on ‘Using Bitvectors’). With the 128 bit
+expansion you actually have 4 separate bitvectors, i.e. <0 0 0 0> only the
+first bitvector is used and the other three are for future expansion.
+
+L) NPC Flags : ISNPC
+1) SPEC This flag must be set on mobiles which have special procedures
+ written in C. In addition to setting this bit, the specproc
+ must be assigned in spec_assign.c, and the specproc itself must
+ be written. Instead of using this use scripts. DO NOT SET.
+2) SENTINEL Mob will not leave the room.
+3) SCAVENGER The mob should pick up valuables it finds on the ground. More
+ expensive items will be taken first.
+4) ISNPC Default is on, do not change. HELP ISNPC.
+5) AWARE Set for mobs which cannot be backstabbed.
+6) AGGR Mob will hit all players in the room it can see. See also the
+ WIMPY bit.
+7) STAY_ZONE Mob will not leave its zone. All mobs should have this flag or
+ the SENTINEL flag. This keeps AGGRESSIVE mobs from wandering
+ into a newbie zone.
+8) WIMPY Mob will flee when being attacked if it has less than 20% of
+ its hit points. If the WIMPY bit is set in conjunction with
+ any of the forms of the AGGRESSIVE bit, the mob will only
+ attack mobs that are unconscious (sleeping or incapacitated).
+9) AGGR_EVIL Mob will attack players that are evil-aligned.
+10) AGGR_GOOD Mob will attack players that are good-aligned.
+11) AGGR_NEU Mob will attack players that are neutrally aligned.
+12) MEMORY Mob will remember players that initiate attacks on it, and will
+ attack that player if it ever runs into him again.
+13) HELPER The mob will attack any player it sees in the room that is
+ fighting with a mobile in the room. Useful for groups of
+ mobiles that travel together; i.e. three snakes in a pit, to
+ force players to fight all three simultaneously instead of
+ picking off one at a time.
+14) NOCHARM Mob cannot be charmed.
+15) NOSUMMON Mob cannot be summoned.
+16) NOSLEEP Sleep spell cannot be cast on mob.
+17) NOBASH Large mobs such as trees that cannot be bashed.
+18) NOBLIND Mob cannot be blinded.
+
+Affection Flags Bitvector A bitvector (see section 2.4 on ‘Using Bitvectors’)
+which is also 4 bitvectors <0 0 0 0> with only the first being used with the
+following values:
+
+M) AFF Flags : NOBITS
+1) BLIND Mob is blind.
+2) INVIS Mob is invisible.
+3) DET-ALIGN NOT USED.
+4) DET-INVIS Mob can see invisible characters and objects.
+5) DET-MAGIC Mob is sensitive to magical presence.
+6) SENSE-LIFE Mob can sense hidden life.
+7) WATWALK Mob can traverse unswimmable water sectors.
+8) SANCT Mob is protected by sanctuary (takes half damage).
+ Adds text ...it glows with a bright light! to l-desc.
+9) GROUP Reserved for internal use. Do not set.
+10) CURSE Mob is cursed.
+11) INFRA Mob can see in dark.
+12) POISON Reserved for internal use. Do not set.
+13) PROT-EVIL Mob is protected from evil characters.
+14) PROT-GOOD Mob is protected from good characters.
+15) SLEEP Reserved for internal use. Do not set.
+16) NO_TRACK Mob cannot be tracked.
+17) UNUSED Unused (room for future expansion).
+18) UNUSED Unused (room for future expansion).
+19) SNEAK Mob can move quietly without room being informed.
+20) HIDE Mob is hidden; can only be seen with sense life.
+21) UNUSED Unused (room for future expansion).
+22) CHARM Reserved for internal use. Do not set.
+
+Alignment A number from -1000 to 1000 representing the mob’s initial alignment.
+
+-1000.....-350 Evil
+ -349......349 Neutral
+ 350.....1000 Good
+
+Type Flag This flag is a single letter which indicates what type of mobile is
+currently being defined, and controls what information tbaMUD expects to find
+next (i.e., in the file from the current point to the end of the current
+mobile).
+
+Standard tbaMUD supports two types of mobiles: S (for Simple), and E (for Enhanced).
+
+4.2 Type S Mobiles
+For type S mobs, the type-specific information should be in the following format:
+
+ S
+
+
+
+
+Level The level of the monster, from 1 to 34.
+
+THAC0 “To Hit Armor Class 0” – a measure of the ability of the monster to
+penetrate armor and cause damage, ranging from 0 to 20. Lower numbers mean the
+monster is more likely to penetrate armor. The formal definition of THAC0 is
+the minimum roll required on a 20-sided die required to hit an opponent of
+equivalent Armor Class 0.
+
+Armor Class The ability of the monster to avoid damage. Range is from -10 to
+10, with lower values indicating better armor. Roughly, the scale is:
+
+AC 100 Naked person
+AC 0 Very heavily armored person (full plate mail)
+AC -100 Armored Battle Tank (hopefully impossible for players)
+
+Note on THAC0 and Armor Class (AC): When an attacker is trying to hit a victim,
+the attacker’s THAC0 and the victim’s AC, plus a random roll of the dice,
+determines whether or not the attacker can hit the victim. (If a hit occurs, a
+different formula determines how much damage is done.) An attacker with a low
+THAC0 is theoretically just as likely to hit a victim with a low AC as an
+attacker with a high THAC0 is to hit a victim with a high AC. Lower attacker
+THAC0’s and higher victim AC’s favor the attacker; higher attacker THAC0’s and
+lower victim AC’s favor the victim.
+
+Max Hit Points The maximum number of hit points the mobile is given, which must
+be given in the form “xdy+z” where x, y, and z are integers. For example,
+4d6+10 would mean sum 4 rolls of a 6 sided die and add 10 to the result. Each
+individual instance of a mob will have the same max number of hit points from
+the time it is loaded into the game right up to the time it dies; the dice will
+only be rolled once when a particular instance of the mob is created. In other
+words, a particular copy of a mob will always have the same number of max hit
+points during its life, but different copies of the same mob may have different
+numbers of max hit points.
+
+Note that all three numbers, the “d” and the “+” must always appear, even if
+some of the numbers are 0. For example, if you want every copy of a mob to
+always have exactly 100 hit points, write 0d0+100.
+
+Bare Hand Damage (BHD) The amount of damage the mob can do per round when not
+armed with a weapon. Also specified as “xdy+z” and subject to the same
+formatting rules as Max Hit Points. However, unlike Max Hit Points, the dice
+are rolled once per round of violence;
+
+the BHD of a mob will vary from round to round, within the limits you set. For
+BHD, xdy specifies the dice rolls and z is the strength bonus added both to
+BHD and weapon-inflicted damage. For example, a monster with a BHD of 1d4+10
+will do between 11 and 14 hitpoints each round without a weapon. If the monster
+picks up and wields a tiny stick which gives 1d2 damage, then the monster will
+do 1d2 + 10 points of damage per round with the stick.
+
+Gold The number of gold coins the mobile is initially loaded with.
+
+Experience The number of experience points the mobile is initially loaded with.
+
+Load Position The position the mobile is in when loaded into the game, which
+should be one of the following numbers:
+
+ 0) Dead - Reserved for internal use. Do not set.
+ 1) Mortally wounded - Reserved for internal use. Do not set.
+ 2) Incapacitated - Reserved for internal use. Do not set.
+ 3) Stunned - Reserved for internal use. Do not set.
+ 4) Sleeping - The monster is sleeping.
+ 5) Resting - The monster is resting.
+ 6) Sitting - The monster is sitting.
+ 7) Fighting - Reserved for internal use. Do not set.
+ 8) Standing - The monster is standing (DEFAULT).
+
+Default Position The position to which monsters will return after a fight,
+which should be one of the same numbers as given above for Load Position. In
+addition, the Default Position defines when the mob’s long description is
+displayed (see “Long Description” above).
+
+Sex One of the following:
+
+0 Neutral (it/its)
+1 Male (he/his)
+2 Female (she/her)
+
+4.3 Type S Mobile Example
+#3062
+fido dog~
+the beastly fido~
+A beastly fido is mucking through the garbage looking for food here.
+~
+ The fido is a small dog that has a foul smell and pieces of rotted meat
+hanging around his teeth.
+~
+65738 0 0 0 65536 0 0 0 -200 S
+1 20 9 0d0+10 1d2+0
+10 100
+8 8 1
+
+This is mobile vnum 3062. The Fido has mob and affect flags set and has an
+initial alignment of -200. After the S flag we see that the Fido is level 1,
+has a THAC0 of 20, an Armor Class of 9, 0d0+10 hit points (10 hitpoints), and
+will do 1d2 hit points of bare hand damage per round. The Fido has 10 gold
+and 100 experience points, has a load position and default position of
+STANDING, and is male.
+
+4.4 Type E Mobiles
+Type E mobiles are specific to tbaMUD and are designed to provide an easy way
+for MUD implementors to extend the mobile format to fit their own needs. A type
+E mobile is an extension of type S mobiles; a type E mobile is a type S mobile
+with extra data at the end. After the last line normally found in type S mobs
+(the one ending with the mob’s sex), type E mobiles end with a section called
+the Enhanced section. This section consists of zero or more enhanced mobile
+specifications (or E-specs), one per line. Each E-spec consists of a keyword
+followed by a colon (“:”) and a value. The valid keywords are listed below. The
+literal letter Emust then come after all E-specs to signal the end of the mob.
+
+The format of an E mobile is as follows:
+
+ E
+
+
+
+{E-spec list}
+E
+
+4.5 Type E Mobile Example
+Let’s say that you wanted to create an enhanced Fido like the one in the
+previous example, but one that has a bare-hand attack type of 4 so that the
+Fido bites players instead of hitting them. Let’s say you also wanted to give
+this Fido the a strength of 18. You might write:
+
+#3062
+fido dog~
+the beastly fido~
+A beastly fido is mucking through the garbage looking for food here.
+~
+ The fido is a small dog that has a foul smell and pieces of rotted meat
+hanging around his teeth.
+~
+65738 0 0 0 65536 0 0 0 -200 E
+1 20 9 0d0+10 1d2+0
+10 100
+8 8 1
+BareHandAttack: 4
+Str: 18
+E
+T 3010
+
+In the above example, the two E-specs used were BareHandAttack and Str. Any
+number of the E-specs can be used in an Enhanced section and they may appear in
+any order. The format is simple: the E-spec keyword, followed by a colon,
+followed by a value. Note that unlike type S mobiles, type E mobiles require
+a terminator at the end of the record (the letter E). The T stands for a
+trigger followed by the attached trigger number. This is the same format for
+rooms and objects also.
+
+4.6 E-Spec Keywords Valid in tbaMUD
+The only keywords supported are BareHandAttack, Str, StrAdd, Int, Wis, Dex,
+Con, and Cha. However, the E-Specs have been designed such that new ones are
+quite easy to add.
+
+BareHandAttack This controls the description of violence given during battles,
+in messages such as “The Beastly fido bites you very hard.” BareHandAttack
+should be one of the following numbers:
+
+ 0) hit 6) crush 11) pierce
+ 1) sting 7) pound 12) blast
+ 2) whip 8) claw 13) punch
+ 3) slash 9) maul 14) stab
+ 4) bite 10) thrash 15) impale
+ 5) bludgeon
+
+Messages given when attackers miss or kill their victims are taken from the
+file lib/misc/messages. The attack type number for weapons is 300 plus the
+number listed in the table above, so to modify the message given to players
+when they are mauled, attack type number 309 in lib/misc/messages should be
+changed. Note that adding new attack types requires code changes and cannot be
+accomplished simply by adding new messages to lib/misc/messages (see the tbaMUD
+Coding Manual for more information).
+
+Str, Int, Wis, Dex, Con, Cha The mobile’s Strength, Intelligence, Wisdom,
+Dexterity, Constitution and Charisma, respectively. These values should be
+between 3 and 18, but can be between 1 and 25 (which is the default statistic
+maximum).
+
+StrAdd The mobile’s strength addition, which can range from 1 to 99.
+
+5 Object Files
+
+5.1 The Format of an Object
+#
+~
+~
+~
+~
+
+
+
+{Zero or more Extra Descriptions and/or Affect Fields}
+
+There can be an unlimited number of Extra Descriptions and up to 3 Affect
+Fields.
+
+Virtual Number This number is critical; it is the identity of the object
+within the game. It is the number that will be used to reference the object
+from zone files and is the number used to “load” objects from within the game.
+The virtual numbers must appear in increasing order in the object file.
+
+Keywords The list of keywords, separated by spaces, that can be used by players
+to identify the object. The object can only be identified using the keywords
+that appear in this list; it cannot be identified by a word that appears only
+in its name. Great care should be taken to ensure that the spellings of names
+and keywords match. Fill words such as “the,” “a,” and “an” should not appear
+in the keywords List.
+
+Short Description The description of the object used by the MUD when the object
+is used. For example, a short description of “a long, green stick” would result
+in messages such as “The Beastly Fido picks up the long, green stick.” The
+Short Description should never end with a punctuation mark because it will be
+inserted into the middle of sentences.
+
+Long Description The description displayed when the object is seen lying on the
+ground, for example, “A furled umbrella is lying here.” Unlike the Short
+Description, the Long Description should end with appropriate punctuation.
+
+Action Description Action Descriptions are primarily used for magical objects
+(staves, wands, scrolls, and potions) to specify what message displayed to the
+room when the magical item is used. The Action Description should be given in
+the act format specified in act.txt. If no Action Description is present, a
+default message will be used:
+
+Staves: Rasmussen taps