Andreas/tbamud
1
0
Fork 0
mirror of https://github.com/tbamud/tbamud.git synced 2026-01-25 10:26:09 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Updated World and files for 3.55 release. --Rumble

Browse source
This commit is contained in:
Rumble 2008-01-16 23:19:50 +00:00
parent 453cbdaf0b
commit af18bd91b6
98 changed files with 7739 additions and 4409 deletions
Download patch file Download diff file Expand all files Collapse all files

1131
doc/FAQ Normal file
View file

File diff suppressed because it is too large Load diff

BIN
doc/FAQ.pdf
View file

Binary file not shown.

857
doc/FAQ.txt Normal file
View file

@ -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

115
doc/README Normal file
View file

@ -0,0 +1,115 @@
Updated: Apr 2007
tbaMUD README
-------------
All requests for help or bugs should be reported to: builderacademy.net 9091.
Information about CircleMUD can be found at the CircleMUD Home Page and FTP:
http://www.circlemud.org
ftp://ftp.circlemud.org
Both of these sites are outdated and no longer maintained. The latest
information and downloads can be found at the CWG forums and download
section:
http://cwg.lazuras.org/modules.php?name=Forums
Downloading tbaMUD
---------------------
You can find the current version of tbaMUD at the following URL:
http://cwg.lazuras.org/modules.php?name=Downloads
Compiling
-------------------
tbaMUD compiles under a large number of operating systems; instructions
for compiling on each platform is can be found in the file doc/README.<system>
Many of these instructions are outdated, please feel free to update them.
AMIGA - If you are using an Amiga running AmigaDOS. (If you're running
NetBSD or Linux on an Amiga, use README.UNIX instead.)
ARC - If you are using an Acorn running RiscOS.
BORLAND - For those using Borland under Windows.
CYGWIN - If you are using Cygwin shell in Windows.
MSVC# - If you are using MSVC.
OS2 - If you are using OS/2 Warp Connect v3.0 or OS/2 v2.x.
UNIX - If you have any type UNIX system, including Linux, MkLinux, Ultrix,
HP/UX, Solaris, SunOS, IRIX, FreeBSD, OpenBSD, NetBSD, BSDi,
Macintosh OS X, etc.
VMS - If you happen to be on OpenVMS.
WATCOM - If using WATCOM under Windows.
WIN - If you are using Windows.
If you are interested in porting tbaMUD to a new platform, see the file
doc/porting.txt for some tips.
For a small, private MUD, or a MUD used only for testing and development,
about 10 megs of disk space and 16 megs of memory should be sufficient.
For large, public MUDs with a large player base, 30 megs to 50 megs of
disk space and at least 32 megs of memory are recommended. Free memory
is much more important than CPU speed; CircleMUD uses virtually no CPU
time.
Other Documentation
-------------------
If this information isn't enough to get you running, there's a lot more
information available. All documentation (other than this file) is in
the "doc" directory. Most of the files in the /doc directory are old and
have not been updated in years, but they still contain a lot of pertinent
information.
"The CircleMUD Administrator's Guide" (admin.pdf)
A good place to start after reading this README file, admin.txt gives
an overall description of how Circle works, how to get it to compile and
run for the first time, information about customizing and configuration
options and command-line arguments, and tips on maintenance and day-to-day
MUD administration.
"The CircleMUD Builder's Manual" (building.pdf)
For the builders in your group, this documents the world-file format
and describes how to create new rooms, objects, and monsters. Also, it
describes how to add new areas to the MUD and gives some tips about game
balance and world-file debugging.
"The CircleMUD Coder's Manual" (coding.pdf)
For the coders in your group, a technical reference describing some of
the more basic coding tasks such as how to add new commands, spells,
skills, socials, and classes. Note that it assumes the reader already has
an excellent knowledge of C; the manual is not a C tutorial.
"The CircleMUD SYSERR List" (syserr.txt)
A list of SYSERR messages and a description of what can cause each problem
and how to solve it. An excellent guide for troubleshooting and area debugging.
Getting Help
------------
If you have strange problems -- and you can't figure out the answer by reading
the documentation -- fear not, there are many other resources available.
http://cwg.lazuras.org/
http://groups.yahoo.com/group/circle-newbies/
http://post.queensu.ca/cgi-bin/listserv/wa?SUBED1=circle&A=1
No matter how you choose to get help, make sure to always include the
following information:
-- The exact version you are using (i.e., "tbaMUD 3.51", etc.).
-- The EXACT text of any error messages, compiler errors, link errors, or any
other errors you're getting.
-- The exact type of hardware, operating system name and version, and
compiler you're using.
-- A description of ANY changes you've made, no matter how small, that might
have contributed to the error.
-- If you are having trouble getting Circle running for the very first time,
also be sure to include the output of 'configure' and the file
'config.log'.
You may also stop by the Builder Academy at anytime. builderacademy.net 9091
--Rumble

111
doc/README.CYGWIN
View file

@ -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

BIN
doc/act.pdf
View file

Binary file not shown.

184
doc/act.txt Normal file
View file

@ -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.

BIN
doc/admin.pdf
View file

Binary file not shown.

592
doc/admin.txt Normal file
View file

@ -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 <ftp://ftp.gnu.org/pub/gnu/>.
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 <path>] [-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
<your-name>".
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.

BIN
doc/building.pdf
View file

Binary file not shown.

1903
doc/building.txt Normal file
View file

File diff suppressed because it is too large Load diff

BIN
doc/coding.pdf
View file

Binary file not shown.

1678
doc/coding.txt Normal file
View file

File diff suppressed because it is too large Load diff

BIN
doc/color.pdf
View file

Binary file not shown.

123
doc/color.txt Normal file
View file

@ -0,0 +1,123 @@
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
Using Color In tbaMUD
Originally by Jeremy Elson
This document is a description of how to write C code which displays messages
to players in color in the tbaMUD game engine. Its intended audience is for
Coders of tbaMUD.
tbaMUD allows you to create colorful messages by using ANSI control sequences.
Each player may select what “level” of color he/she desires from the four
levels “off,” “brief,” “normal,” and “complete.” Each player can select his/her
color level by using the TOGGLE COLOR command from within the MUD; you as the
programmer must decide which messages will be colored for each of the color
levels.
All files in which you wish to use color must have the line:
#include "screen.h"
This should be put in after all other includes in the beginning of the file.
There are 8 colors available – “normal,” red, green, yellow, blue, magenta,
cyan and white. They are accessible by sending control sequences as part of
another string, for example:
sprintf(buf, "If you’re %shappy%s and you know it clap "
"%d of your hands.\n\r", x, y, num_of_hands);
send_to_char(ch, buf);
In this example, x and y are the “on” and “off” sequences for the color you
want. There are 2 main series of color macros available for you to use (don’t
actually use “x” and “y,” of course!): the K series and the CC series. The CC
(Conditional Color) series is recommended for most general use.
The name of the actual sequence starts with the name of its series, plus a
3-letter color code, as follows:
Normal: NRM
Red: RED
Yellow: YEL
Green: GRN
Blue: BLU
Magenta: MAG
Cyan: CYN
White: WHT
For example, white in the K series is KWHT; blue in the CC series is
CCBLU() (arguments defined below).
The K series requires no arguments, and is simply a macro to the ANSI color
code. Therefore, if you use a K-series color code, the color will ALWAYS be
sent, even if the person you’re sending it to has color off. This can very bad.
Some people who do not have ANSI-compatible terminals will see garbage
characters instead of colors. If the terminal correctly ignores ANSI color
codes, then nothing will show up on their screen at all. The K series is mainly
used to print colors to a string if the player’s color level will later be
tested manually (for an example, see do_gen_com in act.comm.c).
The recommended series is the CC series (i.e. CCNRM(), CCRED(), etc.) The CC
series macros require two arguments – a pointer to the character to whom the
string is being sent, and the minimum color level the player must be set to in
order to see the color. Color sent as 'brief' (formerly known as sparse it was
changed for consistancy with the syslog command) (C_SPR) will be seen by people
with color set to sparse, normal, or complete; color sent as ‘normal’ (C_NRM)
will be seen only by people with color set to normal or complete; color sent as
‘complete’ (C_CMP) will be seen only by people with color set to complete.
To illustrate the above, an example is in order:
#include "screen.h"
/* include screen.h in all files that you use color in */
ACMD(do_showcolor)
{
char buf[300];
sprintf(buf, "Don’t you just love %scolor%s, %scolor%s, " "%sCOLOR%s!\n\r",
CCBLU(ch, C_CMP), CCNRM(ch, C_CMP), CCYEL(ch, C_NRM), CCNRM(ch, C_NRM),
CCRED(ch, C_SPR), CCNRM(ch, C_SPR));
send_to_char(ch, buf);
}
What does this do? For people with color set to Complete, it prints:
Don’t you just love color, color, COLOR! (blue) (yellow) (red)
People who have color set to Normal will see:
Don’t you just love color, color, COLOR! (yellow) (red)
People who have color set to Sparse will see:
Don’t you just love color, color, COLOR! (red)
People who have color set to Off will see:
Don’t you just love color, color, COLOR! (no color, as you’d expect)
There are several common pitfalls with using the CC series of color macros:
Do not confuse CCNRM with C_NRM. CCNRM() is a macro to turn the color back to
normal; C_NRMis a color level of “normal.” Always make sure that every pair of
“on” and “off” codes are at the same color level. For example:
WRONG: sprintf(buf, "%sCOLOR%s\n\r", CCBLU(ch, C_NRM), CCNRM(ch, C_CMP));
This is wrong because if someone has their color level set to Normal, the CCBLU
code will be sent but the CCNRM command will not, causing all subsequent output
to be blue.
WRONG: sprintf(buf, "%sCOLOR%s\n\r", CCBLU(ch, C_CMP), CCNRM(ch, C_NRM));
The above statement is also wrong, although not as bad. In this case, someone
with color set to Normal will (correctly) not get the CCBLU code, but will then
unnecessarily get the CCNRM code. Never send a color code if you don’t have to.
The codes are several bytes long, and cause a noticeable pause at 2400 baud.
This should go without saying, but don’t ever send color at the C_OFF level.
Special precautions must be taken when sending a colored string to a large
group of people. You can’t use the color level of “ch” (the person sending the
string) – each person receiving the string must get a string appropriately
colored for his/her level. In such cases, it is usually best to set up two
strings (one colored and one not), and test each player’s color level
individually (see do_gen_comin act.comm.c for an example).

335
doc/debugging.txt Normal file
View file

@ -0,0 +1,335 @@
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 Art of Debugging
Originally by Michael Chastain and Sammy
The following documentation is excerpted from Merc 2.0’s hacker.txt file. It
was written by Furey of MERC Industries and is included here with his
permission. We have packaged it with tbaMUD (changed in a couple of places,
such as specific filenames) because it offers good advice and insight into the
art and science of software engineering. More information about tbaMUD,
can be found at the tbaMUD home page http://tbamud.com.
1 “I’m running a Mud so I can learn C programming!”
Yeah, right. The purpose of this document is to record some of our knowledge,
experience and philosophy. No matter what your level, we hope that this
document will help you become a better software engineer. Remember that
engineering is work, and no document will substitute for your own thinking,
learning and experimentation.
2 How to Learn in the First Place
Play with something.
Read the documentation on it.
Play with it some more.
Read documentation again.
Play with it some more.
Read documentation again.
Play with it some more.
Read documentation again.
Get the idea?
The idea is that your mind can accept only so much “new data” in a single
session. Playing with something doesn’t introduce very much new data, but it
does transform data in your head from the “new” category to the “familiar”
category. Reading documentation doesn’t make anything “familiar,” but it
refills your “new” hopper.
Most people, if they even read documentation in the first place, never return
to it. They come to a certain minimum level of proficiency and then never
learn any more. But modern operating systems, languages, networks, and even
applications simply cannot be learned in a single session. You have to work
through the two-step learning cycle many times to master it.
3 Basic Unix Tools
man gives you online manual pages.
grep stands for “global regular expression print;” searches for strings in text
files.
vi, emacs, jove use whatever editor floats your boat, but learn the hell out
of it; you should know every command in your editor.
ctags mags “tags” for your editor which allows you to go to functions by name
in any source file.
>, >>, <, | input and output redirection at the command line; get someone to
show you, or dig it out of “man csh”
These are the basic day-in day-out development tools. Developing without
knowing how to use all of these well is like driving a car without knowing
how to change gears.
4 Debugging: Theory
Debugging is a science. You formulate a hypothesis, make predictions based on
the hypothesis, run the program and provide it experimental input, observe its
behavior, and confirm or refute the hypothesis.
A good hypothesis is one which makes surprising predictions which then come
true; predictions that other hypotheses don’t make.
The first step in debugging is not to write bugs in the first place. This
sounds obvious, but sadly, is all too often ignored.
If you build a program, and you get any errors or any warnings, you should fix
them before continuing. C was designed so that many buggy ways of writing code
are legal, but will draw warnings from a suitably smart compiler (such as “gcc”
with the -Wall flag enabled). It takes only minutes to check your warnings and
to fix the code that generates them, but it takes hours to find bugs otherwise.
“Desk checking” (proof reading) is almost a lost art these days. Too bad. You
should desk check your code before even compiling it, and desk-check it again
periodically to keep it fresh in mind and find new errors. If you have someone
in your group whose only job it is to desk-check other people’s code, that
person will find and fix more bugs than everyone else combined.
One can desk-check several hundred lines of code per hour. A top-flight
software engineer will write, roughly, 99% accurate code on the first pass,
which still means one bug per hundred lines. And you are not top flight. So...
you will find several bugs per hour by desk checking. This is a very rapid bug
fixing technique. Compare that to all the hours you spend screwing around with
broken programs trying to find one bug at a time.
The next technique beyond desk-checking is the time-honored technique of
inserting “print” statements into the code, and then watching the logged
values. Within tbaMUD code, you can call printf(), fprintf(), or log()to dump
interesting values at interesting times. Where and when to dump these values
is an art, which you will learn only with practice.
If you don’t already know how to redirect output in your operating system, now
is the time to learn. On Unix, type the command “man csh”, and read the part
about the “>” operator. You should also learn the difference between “standard
output” (for example, output from “printf”) and “standard error” (for example,
output from “fprintf(stderr, ...)”).
Ultimately, you cannot fix a program unless you understand how it is operating
in the first place. Powerful debugging tools will help you collect data, but
they can’t interpret it, and they can’t fix the underlying problems. Only you
can do that.
When you find a bug... your first impulse will be to change the code, kill the
manifestation of the bug, and declare it fixed. Not so fast! The bug you
observe is often just the symptom of a deeper bug. You should keep pursuing the
bug, all the way down. You should grok the bug and cherish it in fullness
before causing its discorporation.
Also, when finding a bug, ask yourself two questions: “What design and
programming habits led to the introduction of the bug in the first place?” And:
“What habits would systematically prevent the introduction of bugs like this?”
5 Debugging: Tools
When a Unix process accesses an invalid memory location, or (more rarely)
executes an illegal instruction, or (even more rarely) something else goes
wrong, the Unix operating system takes control. The process is incapable of
further execution and must be killed. Before killing the process, however, the
operating system does something for you: it opens a file named “core” and
writes the entire data space of the process into it.
Thus, “dumping core” is not a cause of problems, or even an effect of problems.
It’s something the operating system does to help you find fatal problems which
have rendered your process unable to continue.
One reads a “core” file with a debugger. The two most popular debuggers on Unix
are adb and gdb, although occasionally one finds dbx. Typically one starts a
debugger like this: “gdb bin/circle” or “gdb bin/circle lib/core”.
The first thing, and often the only thing, you need to do inside the debugger
is take a stack trace. In adb, the command for this is “$c”. In gdb, the
command is “backtrace”. In dbx, the command is “where”. The stack trace will
tell you what function your program was in when it crashed, and what functions
were calling it. The debugger will also list the arguments to these functions.
Interpreting these arguments, and using more advanced debugger features,
requires a fair amount of knowledge about assembly language programming.
6 Using GDB
GDB has some online help, though it is not the best. It does at least give
a summary of commands and what they're supposed to do. What follows is
Sammy's short intro to gdb with some bughunting notes following it:
tbaMUD allows multiple core files to be created. Be sure to delete them when
you are done. If you've got a core file, go to your lib directory and type:
> dir
You should see the core files listed, something like:
core.#
To use the core file type:
> gdb ../bin/circle core.#
If you want to hunt bugs in real time (causing bugs to find the cause as
opposed to checking a core to see why the MUD crashed earlier) use:
> gdb bin/circle
If you're working with a core, gdb should show you where the crash occurred.
If you get an actual line that failed, you've got it made. If not, the
included message should help. If you're working in real time, now's the
time to crash the MUD so you can see what gdb catches.
When you've got the crash info, you can type ``where'' to see which function
called the crash function, which function called that one, and so on all the
way up to ``main()''.
I should explain about ``context'' You may type ``print ch'' which you
would expect to show you the ch variable, but if you're in a function that
doesn't get a ch passed to it (real_mobile, etc), you can't see ch because
it's not in that context. To change contexts (the function levels you saw
with where) type ``up'' to go up. You start at the bottom, but once you go
up, and up, and up, you can always go back ``down''. You may be able to go
up a couple functions to see a function with ch in it, if finding out who
caused the crash is useful (it normally isn't).
The ``print'' command is probably the single most useful command, and lets
you print any variable, and arithmetic expressions (makes a nice calculator
if you know C math). Any of the following are valid and sometimes useful:
print ch (fast way to see if ch is a valid pointer, 0 if it's not)
print *ch (prints the contents of ch, rather than the pointer address)
print ch->player.name (same as GET_NAME(ch))
print world[ch->in_room].number (vnum of the room the char is in)
etc..
Note that you can't use macros (all those handy psuedo functions like GET_NAME
and GET_MAX_HIT), so you'll have to look up the full structure path of
variables you need.
Type ``list'' to see the source before and after the line you're currently
looking at. There are other list options but I'm unfamiliar with them.
There are only a couple of commands to use in gdb, though with some patience
they can be very powerful. The only commands I've ever used are:
run well, duh.
print [variable] also duh, though it does more than you might think
list shows you the source code in context
break [function] set a breakpoint at a function
clear [function] remove a breakpoint
step execute one line of code
cont continue running after a break or ctrl-c
I've run into nasty problems quite a few times. The cause is often a memory
problem, usually with pointers, pointers to nonexistent memory. If you free
a structure, or a string or something, the pointer isn't always set to NULL,
so you may have code that checks for a NULL pointer that thinks the pointer
is ok since it's not NULL. You should make sure you always set pointers to
NULL after freeing them.
Ok, now for the hard part. If you know where the problem is, you should be
able to duplicate it with a specific sequence of actions. That makes things
much easier. What you'll have to do is pick a function to ``break'' at.
The ideal place to break is immediately before the crash. For example, if
the crash occurred when you tried to save a mob with medit, you might be
able to ``break mobs_to_file''. Try that one first.
When you `medit save', the MUD will hang. GDB will either give you segfault
info, or it will be stopped at the beginning of mobs_to_file. If it
segfaulted, pick an earlier function, like copy_mobile, or even do_medit.
When you hit a breakpoint, print the variables that are passed to the
function to make sure they look ok. Note that printing the contents of
pointers is possible with a little playing around. For example, if you
print ch, you get a hex number that shows you the memory location where ch
is at. It's a little helpful, but try print *ch and you'll notice that it
prints the contents of the ch structure, which is usually more useful.
print ch->player will give you the name of the person who entered the
command you're looking at, and some other info. If you get a no ch in this
context it is because the ch variable wasn't passed to the function you're
currently looking at.
Ok, so now you're ready to start stepping. When GDB hit your breakpoint, it
showed you the first line of executable code in your function, which will
sometimes be in your variable declarations if you initialized any variables
(ex: int i = 0). As you're stepping through lines of code, you'll see one
line at a time. Note that the line you see hasn't been run yet. It's
actually the _next_ line to be executed. So if the line is a = b + c;,
printing a will show you what a was before this line, not the sum of b and
c. If you have an idea of where the crash is occurring, you can keep
stepping till you get to that part of the code (tip: pressing return will
repeat the last GDB command, so you can type step once, then keep pressing
return to step quickly). If you have no idea where the problem is, the
quick and dirty way to find your crash is to keep pressing return rapidly
(don't hold the eturn key or you'll probably miss it). When you get the seg
fault, you can't step any more, so it should be obvious when that happens.
Now that you've found the exact line where you get the crash, you should
start the MUD over and step more slowly this time. What I've found that
works really well to save time is to create a dummy function. This one will
work just fine:
void dummy(void){}
Put that somewhere in the file you're working on. Then, right before the
crash, put a call to dummy in the code (ex: dummy();). Then set your
breakpoint at dummy, and when you hit the breakpoint, step once to get back
to the crashing code.
Now you're in total control. You should be looking at the exact line that
gave you the crash last time. Print *every* variable on this line. Chances
are one of them will be a pointer to an unaccessable memory location. For
example, printing ch->player.name may give you an error. If it does, work
your way back and print ch->player to make sure that one's valid, and if it
isn't, try printing ch.
Somewhere in there you're going to have an invalid pointer. Once you know
which one it is, it's up to you to figure out why it's invalid. You may have
to move dummy() up higher in the code and step slowly, checking your pointer
all the way to see where it changes from valid to invalid. You may just
need to NULL a free'd pointer, or you may have to add a check for a NULL
pointer, or you may have screwed up a loop. I've done all that and more :)
Well, that's it in a nutshell. There's a lot more to GDB that I haven't
even begun to learn, but if you get comfortable with print and stepping you
can fix just about any bug. I spent hours on the above procedure trying to
get my ascii object and mail saving working right, but it could have taken
weeks without gdb. The only other suggestion I have is to check out the
online gdb help. It's not very helpful for learning, but you can see what
commands are available and play around with them to see if you can find any
new tools.
7 Profiling
Another useful technique is “profiling,” to find out where your program is
spending most of its time. This can help you to make a program more efficient.
Here is how to profile a program:
1. Remove all the .o files and the “circle” executable:
make clean
2. Edit your Makefile, and change the PROFILE=line:
PROFILE = -p
3. Remake circle:
make
4. Run circle as usual. Shutdown the game with the shutdown command when you
have run long enough to get a good profiling base under normal usage
conditions. If you crash the game, or kill the process externally, you won’t
get profiling information.
5. Run the profcommand:
prof bin/circle > prof.out
6. Read prof.out. Run “man prof” to understand the format of the output. For
advanced profiling, you can use “PROFILE = -pg” in step 2, and use the “gprof”
command in step 5. The “gprof” form of profiling gives you a report which lists
exactly how many times any function calls any other function. This information
is valuable for debugging as well as performance analysis.
Availability of “prof” and “gprof” varies from system to system. Almost every
Unix system has “prof”. Only some systems have “gprof”.
7 Books for Serious Programmers
Out of all the thousands of books out there, three stand out:
Kernighan and Plaugher, “The Elements of Programming Style”
Kernighan and Ritchie, “The C Programming Language”
Brooks, “The Mythical Man Month”

BIN
doc/files.pdf
View file

Binary file not shown.

133
doc/files.txt Normal file
View file

@ -0,0 +1,133 @@
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
tbaMUD File Manifest
The main ‘tbaMUD/’ directory has the following subdirectories and files:
autorun - Shell script to run the MUD (./autorun &).
FAQ - Frequently Aske Questions with answers.
README - Information for the new tbaMUDder.
changelog - A log of changes that can be added to and viewed in game.
syslog - The current system log. Also viewed in game with the file command.
bin/ - Directory of all the compiled programs (binaries).
doc/ - Documentation.
lib/ - MUD data.
log/ - System logs.
src/ - Source code.
The bin/directory contains only binaries: ‘circle’ (the main MUD) and its
utilities, which are described in utils.txt.
The doc/ directory has its own README file, describing the contents of each
of the documentation files.
etc/ - Files maintained by the game which you should not touch while the
game is running.
house/ - Crash-save files for player houses.
misc/ - Miscellaneous database files such as fight messages, invalid names,
and socials.
plrfiles/ - ASCII files which combined the player, alias, and variable files.
plrobjs/ - The hierarchy containing player object files (i.e. crash files,
rent files, cryo-rent files, etc.) and utility scripts.
text/ - Files meant to be directly read by players such as MOTD (message of
the day), help files, and the immortal handbook. You can change
these files while the game is running, and then have the mud reload
them using the reload command.
world/ - The hierarchy of the world files (mobiles, objects, shops, rooms,
triggers, and zones).
The lib/etc/ directory contains the following files (the MUD actively
maintains these files while it is running; they should not be modified
unless the game is down):
badsites - List of banned sites.
Board.<name> - Binary files with the contents of the bulletin boards.
config - Configuration file you can modify via CEDIT.
hcontrol - Binary file with the state of the house control system.
last - File storing information for the last command. Delete occasionally.
plrmail - Binary file containing player mail.
time - Where the MUD time is saved.
The lib/misc/ directory contains the following files:
bugs - Bugs reported by players with the ’bug’ command.
ideas - Ideas from players from ’idea’ command.
messages - Spell and skill damage messages.
socials - Text file with text of the socials.
socials.new - New format of socials you can edit via AEDIT.
typos - Typos reported by players with the ’typo’ command.
xnames - Text file of invalid names.
The lib/plrobjs/ contains the following files and directories:
a-e \
f-j \
k-o \ Subdirectories where player objects files are stored.
p-t /
u-z /
zzz/
The lib/plrfiles/ combined player, alias, and variable files in ASCII format.
a-e \
f-j \
k-o \ Subdirectories where player data is stored.
p-t /
u-z /
zzz/
The lib/text/ directory contains the following files:
background - Background story (for option 3 from main menu).
credits - Text for ’credits’ command.
greetings - Greeting message.
handbook - Text for Immortal Handbook (’handbook’ command).
immlist - Text for ’immlist’ command.
imotd - Immortal MOTD --seen by immortals on login.
info - Text for ’info’ command.
motd - MOTD --seen by mortals on login.
news - Text for ’news’ command.
policies - Text for ’policy’ command.
wizlist - Text for ’wizlist’ command.
/help/screen - Text for ’help’ command as a mortal with no arguments.
/help/iscreen - Text for ’help’ command an an immortal with no arguments.
The lib/world/directory contains the following subdirectories:
mob - Contains *.mob files (mobile files)
obj - Contains *.obj files (object files)
shp - Contains *.shp files (shop files)
trg - Contains *.trg files (trigger files)
wld - Contains *.wld files (world files)
zon - Contains *.zon files (zone files)
Each of the 6 subdirectories in the lib/world/ directory also contains two
additional files – one called ‘index’, which specifies which files in that
directory should be loaded when the MUD boots, and ‘index.mini’, which
specifies which files should be loaded if the MUD is booted with the -m
(mini-mud) option.
The log/ directory contains several files of the form syslog.n, where n is a
small number. These are the most recent tbaMUD syslogs. In addition, it
contains the following more permanent system logs:
badpws - Records of bad password attempts.
delete - Players who have self-deleted.
dts - Players who have hit death traps.
errors - MUD system errors ("SYSERR" messages).
godcmds - All logged god commands.
help - All help queries that are not found.
levels - Records of all levels gained by all players.
newplayers - Records of the creation of new players.
olc - OLC log messages.
rentgone - Players who have lost their items in rent.
restarts - List of times at which the MUD rebooted.
rip - Player deaths.
trigger - Trigedit log messages.
usage - Mud system usage (player load & memory usage info).
The src/ directory contains all of the C and header files for the MUD, along
with a Makefile. The src/util/ directory contains source for tbaMUD’s utility
programs. See admin.txt for more information on how to compile the MUD. See
utils.txt for more information on how to use tbaMUD’s utilities.

BIN
doc/hacker.pdf
View file

Binary file not shown.

BIN
doc/license.pdf
View file

Binary file not shown.

2
doc/license.txt
View file

@ -237,3 +237,5 @@ If you make any major improvements on DikuMud we would be happy to
hear from you. As you will naturally honor the above rules, you will receive
new updates and improvements made to the game.
If you have any additions or corrections please stop by the Builder Academy at
telnet://tbamud.com:9091 or email: rumble@tbamud.com -- Rumble

BIN
doc/porting.pdf
View file

Binary file not shown.

153
doc/porting.txt Normal file
View file

@ -0,0 +1,153 @@
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
Porting tbaMUD to New Platforms
Originally by Jeremy Elson
tbaMUD is a very portable program by design, but is not guaranteed to run on
every platform that exists. This document is for experienced programmers
trying to make tbaMUD work on their platform.
tbaMUD should work on most UNIX platforms without any modifications; simply run
the “configure” script and it should automatically detect what type of system
you have and anything that may be strange about it. These findings are all
stored in a header file called conf.h which is created in the src directory
from a template called conf.h.in. A Makefile is also created from the template
Makefile.in.
Non-UNIX platforms are a problem. Some can’t run tbaMUD at all. However, any
multitasking OS that has an ANSI C compiler, and supports non-blocking I/O and
socket-based TCP/IP networking, should theoretically be able to run tbaMUD; for
example, OS/2, AmigaOS, Mac OS (Classic versions; Mac OS X supports tbaMUD’s
configure script from the command line), and all versions of Windows.
The port can be very easy or very difficult, depending mainly on whether or nor
your OS supports the Berkeley socket API.
The general steps for porting tbaMUD to a non-UNIX platform are listed below. A
number of tips for porting can be found after the porting steps. Note that we
have already ported tba to Windows, so if you’re confused as to how to perform
some of these steps, you can look at what we have done as an example (see the
files README.CYGWIN).
Note that you should not try to do this unless you are an experienced C
programmer and have a solid, working knowledge of the system to which you are
trying to port the code.
Porting the Code
Step 1. Create a “conf.h” file for your system. Copy the template “conf.h.in”
to “conf.h”, and then define or undefine each item as directed by the comments
and based on the characteristics of your system. To write the conf.h file,
you’ll need to know which header files are included with your system, the
return type of signals, whether or not your compiler supports the ‘const’
keyword, and whether or not you have various functions such as crypt()and
random(). Also, you can ignore the HAVE_LIBxxx and HAVE_xxx_PROTO constants at
the end of conf.h.in; they are not used in the code (they are part of UNIX
autoconf).
Step 2. Create a Makefile. Again, copy the template Makefile.in and make any
changes which may be appropriate for your system. Make sure to remove the @xxx@
variables such as @LIBS@, @CC@, @NETLIB@, etc., and replace them with the
appropriate values if necessary.
Step 3. Make the appropriate patches to the code so that the TCP/IP reads and
writes and signal handling are compatible with your system. This is the hardest
part of porting tbaMUD. All of the changes you will need to make will probably
be in the source file comm.c.
Step 4. Test your changes! Make sure that multiple people can log in
simultaneously and that they can all type commands at the same time. No player
should ever have a “frozen” screen just because another is waiting at a prompt.
Leave the MUD up for at least 24 hours, preferably with people playing it, to
make sure that your changes are stable. Make sure that automatic events such as
zone resets, point regeneration, and corpse decomposition are being timed
correctly (a tick should be about 75 seconds). Try resetting all the zones
repeatedly by typing “zr *” many times. Play the MUD and make sure that the
basic commands (killing mobs as a mortal, casting spells, etc.) work correctly.
Step 5. If you are satisfied that your changes work correctly, you are
encouraged to submit them to be included as part of the tbaMUD distribution so
that future releases of tbaMUD will support your platform. This prevents you
from re-porting the code every time a new version is released and allows other
people who use your platform to enjoy tbaMUD as well. To submit your changes
you must make a patch file using the GNU ‘diff’ program. diff will create a
patch file which can be later used with the ‘patch’ utility to incorporate
your changes into the stock tbaMUD distribution. For example, if you have a
copy of tbaMUD in the “stock-tba” directory, and your changes are in “my-tba”,
you can create a patch file like this:
diff -u --new-file --recursive stock-tba/src my-tba/src > patch
This will create a file called ‘patch’ with your patches. You should then try
to use the ‘patch’ program (the inverse of ‘diff’) on a copy of tbaMUD to make
sure that tbaMUD is correctly changed to incorporate your patches. This step is
very important: if you don’t create these patches correctly, your work will be
useless because no one will be able to figure out what you did! Make sure to
read the documentation to ‘diff’ and ‘patch’ if you don’t understand how to use
them. If your patches work, CELEBRATE!!
Step 6. Write a README file for your operating system that describes everything
that has to be done by another user of your operating system to get tbaMUD to
compile from scratch. You should include a section on required hardware,
software, compilers, libraries, etc. Also include detailed, step-by-step
instructions on how to compile and run everything. You can look at the other
README files in the distribution (README.CYGWIN, README.OS2, etc.) for examples
of what your README file should include.
Step 7. You are done! Congratulations! Mail your conf.h, Makefile, patches, and
README file to Rumble at <rumble@tbamud.com> so that they can be included in
future releases of tbaMUD. Please share your work so that other users can
benefit too.
3 Porting Tips
3.1 Making your own CIRCLE_system constant
Each system to which tba is already ported has a CIRCLE_xx constant associated
with it: CIRCLE_UNIX for plain vanilla UNIX tbaMUD, CIRCLE_WINDOWS for MS
Windows, CIRCLE_OS2 for IBM OS/2, and CIRCLE_AMIGA for the Amiga. You must use
a similar constant for your system. At the top of your conf.h, make sure to
comment out “#define CIRCLE_UNIX” and add “#define CIRCLE_YOUR_SYSTEM”.
3.2 ANSI C and GCC
As long as your system has an ANSI C compiler, all of the code (except for
comm.c) should compile with no major complaints. However, tbaMUD was written
using gcc, and some compilers are nitpicky about things that gcc does not care
about (and the other way around). Therefore, you are highly encouraged to use
gcc if at all possible. gcc has been ported to a very large number of
platforms, possibly including yours, and your port will be made much easier if
you use gcc.
3.3 Non-Blocking I/O
Make absolutely sure to use non-blocking I/O; i.e. make sure to enable the
option so that the read() system call will immediately return with an error if
there is no data available. If you do not use non-blocking I/O, read() will
“block,” meaning it will wait infinitely for one particular player to type
something even if other players are trying to enter commands. If your system
does not implement non-blocking I/O correctly, try using the
POSIX_NONBLOCK_BROKEN constant in sysdep.h.
3.4 Timing
tbaMUD needs a fairly precise (on the order of 5 or 10 ms) timer in order to
correctly schedule events such as zone resets, point regeneration (“ticks”),
corpse decomposition, and other automatic tasks. If your system supports the
select() system call with sufficient precision, the default timing code should
work correctly. If not, you’ll have to find out which system calls your system
supports for determining how much time has passed and replace the select()
timing method.
3.5 Signals and Signal Handlers
A note about signals: Most systems don’t support the concept of signals in the
same way that UNIX does. Since signals are not a critical part of how tbaMUD
works anyway (they are only used for updating the wizlist and some other
trivial things), all signal handling is turned off by default when compiling
under any non-UNIX platform (i.e. the Windows and Amiga ports do not use
signals at all.) Simply make sure that CIRCLE_UNIX is not defined in your
conf.h file and all signal code will be ignored automatically.
4 Final Note
IMPORTANT: Remember to keep any changes you make surrounded by #ifdef
statements (i.e. “#ifdef CIRCLE_WINDOWS ... #endif”). If you make absolutely
sure to mark all of your changes with #ifdef statements, then your patches
(once you get them to work) will be suitable for incorporation into the
tbaMUD distribution, meaning that tbaMUD will officially support your platform.

BIN
doc/release.pdf
View file

Binary file not shown.

148
doc/releases.txt Normal file
View file

@ -0,0 +1,148 @@
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
CircleMUD Release History
Originally by Jeremy Elson
Abstract
This document lists the release history of CircleMUD and at the end is the post
to rec.games.mud.diku which originally anounced CircleMUD as a publically
available MUD source code.
Release history:
Version 3.54 release: December, 2007
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)
The CircleMUD ‘press release’ is included below, in case you haven’t seen it
and want to.
Wake the kids and find the dog, because it’s the FTP release of
CIRCLEMUD 2.0
That’s right --CircleMUD 2.0 is done and is now available for anonymous FTP
at ftp.cs.jhu.edu!
CircleMUD 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, races, and areas, Circle will probably disappoint
you severely. Circle still has only the 4 original Diku classes, the original
spells, the original skills, and about a dozen areas.
On the other hand, if you’re looking for a highly stable, well-developed,
well-organized "blank slate" MUD on which you can put your OWN ideas for
spells, skills, classes, and areas, then Circle might be just what you’re
looking for.
Just take a gander at some of Circle’s nifty features:
--In-memory mobile and object prototypes and string sharing for
decreased memory usage and blazingly fast zone resets
--All large realloc()s have been removed and replaced by boot-time
record counting and a single malloc() for superior memory efficiency
--Split world/obj/mob/zon/shp files for easy addition of areas; plus,
all the world files are still in the original Diku format for
compatibility with existing areas
--Boot-time and run-time error checking of most data files with
diagnostic messages a lot more helpful than "segmentation fault"!
--Player mail system and bank
--Rewritten board system: boards are now stable, robust, more
intelligent, and easily expandable --adding a new board is
as easy as adding another line to an array
--ANSI color codes with a fully documented programmers’ interface
--On-line system logs
--Optional automatically regenerating wizlist --a final end
to new immortals constantly asking you when they’ll be added
to the immlist!
--"config.c" file allows you to change aspects of the game such
as playerkilling/playerthieving legality, max number of objects
rentable, and nameserver usage --WITHOUT recompiling the
entire MUD!
--All text (help, mortal/immort MOTDs, etc.) is rebootable at
run-time with the "reboot" command
--All players are given a unique serial number --no more messy,
time consuming str_cmp()s when you’re trying to identify people!
--Fully integrated and robust rent/crash system --allows normal
renting, cryo-renting, crash protection, and forced rent
(at an increased price) after an hour of idling
--All the standard wizard stuff you’re used to: level-sensitive
invisibility, settable poofin/poofouts, wizline
--Advanced ’set’ command which allows you to set dozens of aspects
of players --even if they aren’t logged in! "Stat" also allows
you to stat people who aren’t logged in!
--Intelligent ’autorun’ script handles different types of reboots,
organizing your system logs, and more!
--Circle comes with more than a dozen utilities, all fully
documented, to make maintenance a snap!
--And much, much more!
Unfortunately, the original Circle had more than its fair share of Bad People
when it was alive, but it DID lead to an impressive list of security and
"asshole control" features:
--3 types of sitebanning available: ’all’ to refuse all connections,
’new’ to refuse new players, or ’select’ to refuse new players and
all registered players who don’t have a SITEOK flag.
--’wizlock’ allows you to close the game to all new players or all
players below a certain level.
--Handy ’mute’ command squelches a player off of all public
communication channels
--Handy ’freeze’ command freezes a player in his tracks: the MUD
totally ignores all commands from that player until he’s thawed.
--Even handier DELETE flag allows you to delete players on the fly.
--’set’ command (mentioned above) allows you to freeze/unfreeze/
delete/siteok/un-siteok players --even if they aren’t logged in!
--Bad password attempts are written to the system log and saved;
if someone tries to hack your account, you see "4 LOGIN FAILURES
SINCE LAST SUCCESSFUL LOGIN" next time you log on.
--Passwords don’t echo to the screen; allows 3 bad PW attempts
before disconnecting you.
--Players aren’t allowed to choose their character’s name as their
password --you’d be surprised how many do!
--"xnames" text file specifies a list of invalid name substrings
to prevent creation of characters with overly profane names.
Listen to all the rave reviews of CircleMUD 2.0!
"How long ago was that deadline you set for yourself?" --My Friend
"NO ONE should be denied the power of computation." --My Professor
"Multi-user WHAT?" --My Mom
Give it a try --what do you have to lose other than your GPA/job, friends,
and life?
Good luck, and happy Mudding,
Jeremy Elson aka Ras
Circle and tbaMUD’s complete source code and areas are available at
http://www.tbamud.com.

BIN
doc/socials.pdf
View file

Binary file not shown.

168
doc/socials.txt Normal file
View file

@ -0,0 +1,168 @@
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
A social is the easiest command to add to the game thanks to the social editor;
aedit. Socials serve as a means of expression among players, and have no effect
on gameplay itself (unless you make a trigger to fire off a social). Socials
can be used locally or globally with gemote.
HELP AEDIT
Syntax: aedit <social>
Aedit is an online action (social) editor that allows you to create socials
on the fly. Anyone can add new socials just ask a level 33 or above to set your
OLC to 999 and explain how it works. Use astat to see examples.
Here is the much coveted list of $ codes applicable to socials: There are six
different dollar-sign codes which can be inserted into the messages. Each is a
dollar-sign followed by a letter. If the letter is lowercase, the player using
the social is referenced. If the letter is capital, the target character is
referenced. The letter N inserts the character's name, an E inserts a subject
pronoun (he, she, it), an S inserts a possessive pronoun (his, hers, its), and
an M inserts an object pronoun (him, her, it).
$e he/she/it person doing social
$E he/she target of social
$m him/her person doing social
$M him/her target of social
$n char name person doing social (your name)
$N char name target of social (other persons name)
$s his/her/its person doing social
$S his/her target of social
$t body part of victim
$p object
See also: ASTAT, SOCIALS, AUTOSAVE
This is all you really need to know to make socials. Now if you want to edit
the socials file directly or understand the format in depth keep reading.
The file is formatted as follows:
<command> <command sort name> <hide flag> <min pos of vict> <min pos of char>
<min level>
<messg to character if no argument>
<messg to others if no argument>
<messg to char if victim not found>
<messg to char if vict is char>
<messg to others if vict is char>
<messg to char if victim found>
<messg to others if victim found>
<messg to victim>
<messg to char if body part found>
<messg to others if body part found>
<messg to victim if body part found>
<messg to char if object found>
<messagee to others if object found>
All socials are 14 lines followed by a blank line. After the blank line is
either the beginning of the next social or a dollar sign which marks the end of
the file. The first line of any social has six elements: the command name, the
abbreviated version of the command, the "hide-flag", the minimum position of the
victim, the min pos of the char (below), and the minimum level. that any victim
must be. The hide-flag is a Boolean value. If it is 0, the social is visible to
anyone in the room. If it is 1, the social is only visible to the character who
uses it and the character who is the "victim". Most such socials are only usable
on characters who are awake, meaning that they are either resting or more alert,
and so the minimum position value we will use is 5.
Positions:
Dead 0 = POS_DEAD
Mortally Wounded 1 = POS_MORTALLYW
Incapacitated 2 = POS_INCAP
Stunned 3 = POS_STUNNED
Sleeping 4 = POS_SLEEPING
Resting 5 = POS_RESTING
Sitting 6 = POS_SITTING
Fighting 7 = POS_FIGHTING
Standing 8 = POS_STANDING
The next 13 message lines contain the statements that will be shown to various
characters in certain conditions. The first line is the message sent to the
player who uses a social when the social has no argument. The second line
contains the message sent to others in the room when the social has no argument.
The third message is sent to the player using the social when the player names
a target, and that target is present in the room. The fourth message is sent to
others in the room under the same circumstances. The fifth message is sent to
the target character. The sixth message is sent to the player who uses the
social when the player supplies a target, and that target is not available. The
seventh message is sent to the player who uses the social when they player
supplies his or herself as a target. The eighth message is sent to others in
the room under the same circumstances. The remaining follow the same theme but
for body parts and objects. A pound sign in any message line means that there
is no message.
Keep in mind that "messages", "socials", and the world files are not part of
the source code, but rather are strictly data files. They are read by the game
at runtime and throughout the course of the game. Changes made to them do not
require recompiling the executable, they only need for the game to stop running
and be restarted. You can change information in these files at any time. In the
tbaMUD codebase the socials appear in alphabetical order in the file, but they
can appear in any order and can be rearranged if necessary. The socials file is
located in the lib/misc/ directory. Socials are all handled through the
generalized command do_action where the $ codes listed above are parsed.
Each social must contain the first two messages (if the social ignores
arguments), or all thirteen messages (if the social takes an argument). Each
message must be contained in one line. The command-name indicates which social
is being specified. The command sort name is the shortest part of the command a
player must type for it to match. The hide-flag can be either 0 or 1; if 1, the
social is hidden from OTHERS if they cannot see the character performing the
social. The action is not hidden from the VICTIM, even if s/he cannot see the
character performing the social, although in such cases the character’s name
will, of course, be replaced with “someone”. The min positions should be set to
dictate the minimum position a player must be in to target the victim and
perform the social. Min level allows you to further customize who can use what
socials.Where it makes sense to do so, text fields may be left empty. If
editing manually you should by put a ‘#’ in the first column on the line. Aedit
does this automatically.
Examples:
A social only requires 2 message lines. This is the simplest form of a social.
~ack ack 0 0 0 0
ACK!
$n goes ACK!!
#
#
#
#
#
#
#
#
#
#
#
~lick lick 0 5 0 0
You lick your lips and smile.
$n licks $s lips and smiles.
You lick $M.
$n licks $N.
$n licks you.
Lick away, nobody's here with that name.
You lick yourself.
$n licks $mself -- YUCK.
You lick $S $t.
$n licks $N's $t.
$n licks your $t.
You lick $p.
$n licks $p.
~comfort com 0 5 5 0
Do you feel uncomfortable?
#
You comfort $M.
$n comforts $N.
$n comforts you.
Comfort who?
You make a vain attempt to comfort yourself.
#
#
#
#
You comfort $p.
$n comforts $p.

48
doc/syserr.txt
View file

@ -1,11 +1,10 @@
There are many common errors that can be created by changing things in the
code or having builders try inappropriate things. Here are a few, this is list
will be continually developed, if you have any additions or corrections please
stop by the Builder Academy: builderacademy.net 9091
code or having builders try inappropriate things. Here are a few, this list
will be continually developed. If you have any additions or corrections please
stop by the Builder Academy at telnet://tbamud.com:9091 or email:
rumble@tbamud.com -- Rumble
--Rumble
1. Errant Rooms (show error)
1. Errant Rooms (show error command)
2. SYSERR: Object # (oedit-s-desc) doesn't have drink type as last alias.
3. SYSERR: Mob # both Aggressive and Aggressive_to_Alignment.
4. SYSERR: Object # (oedit-s-desc) has out of range level #.
@ -14,24 +13,27 @@ stop by the Builder Academy: builderacademy.net 9091
6. SYSERR: Object # (oedit-s-desc) uses 'UNDEFINED' spell #.
7. SYSERR: Object # (oedit-s-desc) contains (5) more than maximum (3).
8. Char is already equipped: (medit-s-desc), (oedit-s-desc)
9. SYSERR: Attempt to assign spec to non-existant mob #
1: Errant Rooms
------------
1: [ 1233] Rumble's Room
12: (Nowhere) [ 8868] House of Elders Chamber in Silverwood City (south)
The most common are exits to 0 (the void). This happens when a builder
The most common are exits to Nowhere. This happens when a builder
modifies a room exit but does not include an exit room vnum. These errant
rooms are listed by the command 'show error' The fix is simple, remove the
exit by purge exit in redit exit menu or by using 'dig <direction> -1'
exit by purge exit in redit exit menu or by using 'dig <direction> -1' A few
builders actually create exits to nowhere just so they can set the exit
descriptions. So only delete if there is no exit description.
2: SYSERR: Object # (oedit-s-desc) doesn't have drink type as last alias.
Another common error is caused by how shop code handles drink containers
poorly. In order for shops to display a jug as a jug of <drink type> they
poorly. In order for shops to display a jug as "a jug of <drink type>" they
must have the drink type as the last alias. It is good practice to put the
drink type as the first and last word of an objects namelist (older verions
of CircleMUD expect it first).
of CircleMUD expect it first and once the object is empty it removes one of
the drink aliases).
i.e. a shot of whisky should have the namelist: whisky shot whisky
a cup of slime mold juice namelist should be: juice cup slime juice
@ -44,21 +46,21 @@ to all.
4: SYSERR: Object # (oedit-s-desc) has out of range level #.
A simple one. Limit spell levels to the levels available, on TBA that would
be 1-34.
A simple one. Limit spell levels to the levels available, on tbaMUD that
would be 1-34.
5: SYSERR: Object # (oedit-s-desc) has negative weight (-2147483644).
SYSERR: Object # (oedit-s-desc) has out of range level #2147483647.
These are really annoying. This happens when you use numbers larger than
necessary. This will actually crash many older versions of CircleMUD. Just do
not do it. Use realistic numbers.
These are really annoying. This happens on older versions of CircleMUD when
you use numbers larger than necessary. This will actually crash many older
versions of CircleMUD. Just do not do it. Use realistic numbers.
6: SYSERR: Object # (oedit-s-desc) uses 'UNDEFINED' spell #.
There is no spell zero. Either select a spell or put -1 for none.
7: SYSERR: Object # (oedit-s-desc) contains (5) more than maximum (3).
7: SYSERR: Object # (oedit-s-desc) contains (#) more than maximum (#).
When making a drink container you will set how much it initially contains
on creation and the max it can hold if a player were to fill it. Common sense
@ -72,3 +74,13 @@ the initial amount.
a single location. HELP ZEDIT-EQUIP for all the possible object equipping
locations. All you have to do to fix this is pick a different equip location
that is not used.
9: SYSERR: Attempt to assign spec to non-existant mob #
To get rid of this "grep # spec_assign.c" and remove this assignment.
10: No associated object exists when attempting to create a board [vnum #].
You need to delete this board from lib/etc/boards/ and modify boards.c and
boards.h. Again "grep #" *.[ch] to search for this vnum in all of your .c and
.h files to remove the reference.

BIN
doc/utils.pdf
View file

Binary file not shown.

148
doc/utils.txt Normal file
View file

@ -0,0 +1,148 @@
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
tbaMUD Utility Programs
Originally by Alex Fletcher
This document gives a brief summary of the various utility programs that come
with the tbaMUD distribution. The summaries include the description of the
utility, how it is called, and any caveats to watch out for when using them.
Contents
1 Conversion Utilities
1.1 shopconv
1.2 split
1.3 wld2html
1.4 webster
2 Maintenance Utilities
2.1 asciipasswd
2.2 sign
3 Informational Utilities
3.1 listrent
4 Internal Utilities
4.1 autowiz
1 Conversion Utilities
These utilities are generally one-time use utilities. Some are for converting
older CircleMUD data files to the versions used in CircleMUD v3, while others
are used to convert currently existing files into different formats.
Overall, these utilities have been created in an attempt to make the tbaMUD
administrator’s life a bit easier, and to give the administrator some ideas of
further and more grandiose utilities to create. Some are no longer applicable
but are retained as examples.
Please note that these utilities are not as rigorously tested as the rest of
the tbaMUD server, and you should be certain to backup your data before using
these utilities on it. Also note that the code layout and design for these
utilities is not as tight and as thought out as the rest of the source code
distributed with tbaMUD.
1.1 shopconv
The format of shops changed between CircleMUD 2.20 and CircleMUD v3. To make
the transition easier, Jeff Fink submitted a shop conversion utility, shopconv.
Similar to the player file converter, this should only be run against any file
once. It is best to run this immediately before the initial v2.20 to v3
changeover. The command line syntax for shopconvis as follows:
shopconv <file1> [<file2> .. <filen>]
where <file1>
is the first file to convert, <file2>
the second, and so forth.
1.2 split
The split utility is designed to split large world files into smaller, zone
sized files that are easier to manage and maintain. The utility reads its input
from the standard input and writes the output to files with names specified
within the larger world file. This is done by inserting ‘=filename’ into the
world file at the appropriate points, where filename is the name of the file
for the following section.
The command line syntax for splitis as follows:
split < [filename]
where [filename] is the file to redirect into the utility. The syntax above
indicates how to do this on platforms that support command line redirection.
1.3 wld2html
This utility began its life as a small toy written by Jeremy Elson to put a
CircleMUD world file on the world wide web. It converts the world file into a
series of HTML files, one per room, all named according to the virtual number
of the room, and linked via their exits.
The command line syntax for wld2htmlis as follows:
wld2html <wldfile>
where <wldfile>
is the world file to be turned into web pages.
2 Maintenance Utilities
2.1 asciipasswd
This utility generates hashed passwords for ASCII player files.
2.2 sign
This utility allows you to display some static text on a port when anyone
connects to it. This is useful when the mud server is moving, changing ports,
or is down for maintenance.
The command line syntax for signis as follows:
sign <port> <filename | -(for stdin)>
where <port>
is the tcp port to put the information on. This is usually the same as the mud
server port (when the server is not running), which defaults to 4000. The
<filename> is an ASCII file to display on the port when a connection is made
to it. If -is specified as a filename, the utility will wait for you to enter
the text to be displayed and will take in all text until ended by an EOF marker
(ctrl-D on Unix based systems).
3 Informational Utilities
3.1 listrent
This utility allows you to view player rent files offline. It displays the type
of rent; Rent, Crash, Cryo, or lost link (TimedOut). It also displays the
object vnum and first keyword.
The command line syntax for listrentis as follows:
listrent <objfile1> [<objfile2> .. <objfilen>]
where <objfile1>
is the first object file to view, <objfile2> the second, and so forth.
This utility must be recompiled if you make any changes to the rent file
structure.
4 Internal Utilities
4.1 autowiz
This utility is called from within the tbaMUD server and manages the self
updating Wizlist and Immlist. At this point, it only works on Unix-based
systems, but a solution for all other systems is being designed. If you wish
to change the text in the headers of the Wizlist or the Immlist, this is
the utility to edit.
The command line syntax for autowizis as follows:
autowiz <wizlev> <wizlistfile> <immlev> <immlistfile> [pid to signal]
where <wizlev> is equal to whatever LVL_GOD is set to in your tbaMUD server,
<wizlistfile> is the filename for the file containing the game’s Wizlist.
<immlev> should be set to your game’s LVL_IMMORT, while <immlistfile>
is the name of the Immlist file.
This utility must be recompiled if you make any changes to the player file structure.