diff --git a/doc/README b/doc/README index d9a9f15..50ffb3f 100644 --- a/doc/README +++ b/doc/README @@ -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 diff --git a/doc/act.txt b/doc/act.txt index 3bc99fa..991d8c4 100644 --- a/doc/act.txt +++ b/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 *. diff --git a/doc/color.txt b/doc/color.txt index 377cb85..226231a 100644 --- a/doc/color.txt +++ b/doc/color.txt @@ -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). diff --git a/doc/debugging.txt b/doc/debugging.txt index 37a444a..c4ca478 100644 --- a/doc/debugging.txt +++ b/doc/debugging.txt @@ -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” diff --git a/doc/files.txt b/doc/files.txt index 5b4b2f2..a300f7f 100644 --- a/doc/files.txt +++ b/doc/files.txt @@ -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. diff --git a/doc/porting.txt b/doc/porting.txt index 9ec3885..97c7824 100644 --- a/doc/porting.txt +++ b/doc/porting.txt @@ -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. diff --git a/doc/releases.txt b/doc/releases.txt index a6f0756..37e2df5 100755 --- a/doc/releases.txt +++ b/doc/releases.txt @@ -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. diff --git a/doc/socials.txt b/doc/socials.txt index ad4a780..0d72a5e 100644 --- a/doc/socials.txt +++ b/doc/socials.txt @@ -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: diff --git a/doc/utils.txt b/doc/utils.txt index 79c8bfc..bc3915d 100644 --- a/doc/utils.txt +++ b/doc/utils.txt @@ -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 [pid to signal] where is equal to whatever LVL_GOD is set to in your tbaMUD server, - is the filename for the file containing the game’s Wizlist. - should be set to your game’s LVL_IMMORT, while + is the filename for the file containing the game’s Wizlist. + should be set to your game’s LVL_IMMORT, while is the name of the Immlist file. This utility must be recompiled if you make any changes to the player file structure.