mirror of
https://github.com/tbamud/tbamud.git
synced 2025-09-22 05:50:48 +02:00
convert docs files to utf-8
This commit is contained in:
Thomas Arp
parent
558e71eed8
commit
ba7dc7bf6f
9 changed files with 131 additions and 131 deletions
|
|
@ -1,7 +1,7 @@
|
|||
Updated: Apr 2007
|
||||
tbaMUD README
|
||||
-------------
|
||||
All requests for help or bugs should be reported to: builderacademy.net 9091.
|
||||
All requests for help or bugs should be reported to: tbamud.com 9091.
|
||||
|
||||
Information about CircleMUD can be found at the CircleMUD Home Page and FTP:
|
||||
http://www.circlemud.org
|
||||
|
|
|
|||
30
doc/act.txt
30
doc/act.txt
|
|
@ -24,7 +24,7 @@ Contents
|
|||
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 –
|
||||
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.
|
||||
|
|
@ -38,17 +38,17 @@ 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
|
||||
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”.
|
||||
entire output from any characters that cannot see the “performing character”.
|
||||
|
||||
ch: The “performing character”. This is the character that the output string
|
||||
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.
|
||||
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.
|
||||
|
|
@ -73,7 +73,7 @@ The next parameter vict_objcan be a number of things ranging from a game object
|
|||
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
|
||||
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.
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ 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.
|
||||
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.
|
||||
|
||||
|
|
@ -105,20 +105,20 @@ 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
|
||||
$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 “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 “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 “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 Name or “something” for obj, depending on visibility.
|
||||
$O Like $o, for vict_obj.*
|
||||
$p Short description or “something” for 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 “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
|
||||
|
|
@ -129,7 +129,7 @@ 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 ‘$’.
|
||||
$$ Print the character ‘$’.
|
||||
|
||||
NOTE*: vict_obj must be a pointer of type struct char_data *.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,8 +9,8 @@ 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
|
||||
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.
|
||||
|
|
@ -21,17 +21,17 @@ All files in which you wish to use color must have the line:
|
|||
|
||||
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,
|
||||
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 "
|
||||
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
|
||||
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
|
||||
|
|
@ -51,21 +51,21 @@ 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.
|
||||
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
|
||||
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
|
||||
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 consistency 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)
|
||||
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.
|
||||
‘complete’ (C_CMP) will be seen only by people with color set to complete.
|
||||
|
||||
To illustrate the above, an example is in order:
|
||||
|
||||
|
|
@ -76,29 +76,29 @@ ACMD(do_showcolor)
|
|||
{
|
||||
char buf[300];
|
||||
|
||||
sprintf(buf, "Don’t you just love %scolor%s, %scolor%s, " "%sCOLOR%s!\n\r",
|
||||
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)
|
||||
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)
|
||||
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)
|
||||
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)
|
||||
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:
|
||||
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));
|
||||
|
||||
|
|
@ -110,14 +110,14 @@ 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.
|
||||
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.
|
||||
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
|
||||
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
|
||||
strings (one colored and one not), and test each player’s color level
|
||||
individually (see do_gen_comin act.comm.c for an example).
|
||||
|
|
|
|||
|
|
@ -4,14 +4,14 @@ 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
|
||||
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!”
|
||||
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
|
||||
|
|
@ -31,11 +31,11 @@ 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.
|
||||
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
|
||||
|
|
@ -47,17 +47,17 @@ through the two-step learning cycle many times to master it.
|
|||
|
||||
man gives you online manual pages.
|
||||
|
||||
grep stands for “global regular expression print;” searches for strings in text
|
||||
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
|
||||
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”
|
||||
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
|
||||
|
|
@ -70,21 +70,21 @@ 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.
|
||||
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”
|
||||
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
|
||||
“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
|
||||
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
|
||||
|
|
@ -95,20 +95,20 @@ 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
|
||||
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, ...)”).
|
||||
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
|
||||
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
|
||||
|
|
@ -117,9 +117,9 @@ 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?”
|
||||
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
|
||||
|
||||
|
|
@ -127,20 +127,20 @@ 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
|
||||
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
|
||||
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
|
||||
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”.
|
||||
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
|
||||
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,
|
||||
|
|
@ -343,12 +343,12 @@ new tools.
|
|||
|
||||
7 Profiling
|
||||
|
||||
Another useful technique is “profiling,” to find out where your program is
|
||||
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:
|
||||
1. Remove all the .o files and the “circle” executable:
|
||||
make clean
|
||||
|
||||
2. Edit your Makefile, and change the PROFILE=line:
|
||||
|
|
@ -359,25 +359,25 @@ 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
|
||||
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
|
||||
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”.
|
||||
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”
|
||||
Kernighan and Plaugher, “The Elements of Programming Style”
|
||||
Kernighan and Ritchie, “The C Programming Language”
|
||||
Brooks, “The Mythical Man Month”
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ 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:
|
||||
The main ‘tbaMUD/’ directory has the following subdirectories and files:
|
||||
|
||||
autorun - Shell script to run the MUD (./autorun &).
|
||||
FAQ - Frequently Aske Questions with answers.
|
||||
|
|
@ -16,7 +16,7 @@ lib/ - MUD data.
|
|||
log/ - System logs.
|
||||
src/ - Source code.
|
||||
|
||||
The bin/directory contains only binaries: ‘circle’ (the main MUD) and its
|
||||
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
|
||||
|
|
@ -51,12 +51,12 @@ 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.
|
||||
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.
|
||||
typos - Typos reported by players with the ’typo’ command.
|
||||
xnames - Text file of invalid names.
|
||||
|
||||
The lib/plrobjs/ contains the following files and directories:
|
||||
|
|
@ -80,18 +80,18 @@ zzz/
|
|||
The lib/text/ directory contains the following files:
|
||||
|
||||
background - Background story (for option 3 from main menu).
|
||||
credits - Text for ’credits’ command.
|
||||
credits - Text for ’credits’ command.
|
||||
greetings - Greeting message.
|
||||
handbook - Text for Immortal Handbook (’handbook’ command).
|
||||
immlist - Text for ’immlist’ command.
|
||||
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.
|
||||
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.
|
||||
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:
|
||||
|
||||
|
|
@ -103,8 +103,8 @@ 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
|
||||
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.
|
||||
|
||||
|
|
@ -128,6 +128,6 @@ 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
|
||||
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.
|
||||
utils.txt for more information on how to use tbaMUD’s utilities.
|
||||
|
|
|
|||
|
|
@ -9,16 +9,16 @@ 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
|
||||
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
|
||||
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
|
||||
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
|
||||
|
|
@ -26,7 +26,7 @@ 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
|
||||
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).
|
||||
|
||||
|
|
@ -36,11 +36,11 @@ 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
|
||||
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’
|
||||
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
|
||||
|
|
@ -58,12 +58,12 @@ 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.
|
||||
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
|
||||
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
|
||||
|
|
@ -71,20 +71,20 @@ 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
|
||||
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”,
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
|
|
@ -107,7 +107,7 @@ 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”.
|
||||
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
|
||||
|
|
@ -122,22 +122,22 @@ you use gcc.
|
|||
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
|
||||
“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”),
|
||||
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
|
||||
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
|
||||
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
|
||||
|
|
@ -147,7 +147,7 @@ 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
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ communication channels
|
|||
totally ignores all commands from that player until they are 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!
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -110,12 +110,12 @@ 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
|
||||
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
|
||||
editing manually you should by put a ‘#’ in the first column on the line. Aedit
|
||||
does this automatically.
|
||||
|
||||
Examples:
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ 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
|
||||
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.
|
||||
|
||||
|
|
@ -61,7 +61,7 @@ the second, and so forth.
|
|||
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
|
||||
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.
|
||||
|
||||
|
|
@ -141,8 +141,8 @@ The command line syntax for autowiz is 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>
|
||||
<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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue