convert docs files to utf-8

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

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

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 
+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
+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 
+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 
+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 
+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 
+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: 
+“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
+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 
+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). 

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 
+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 
+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” 
+does transform data in your head from the “new” category to the “familiar” 
-category. Reading documentation doesn’t make anything “familiar,” but it 
+category. Reading documentation doesn’t make anything “familiar,” but it 
-refills your “new” hopper. 
+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 
+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 
+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 
+about the “>” operator. You should also learn the difference between “standard 
-output” (for example, output from “printf”) and “standard error” (for example, 
+output” (for example, output from “printf”) and “standard error” (for example, 
-output from “fprintf(stderr, ...)”). 
+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 
+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:
+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?” 
+“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.
+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 
+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 
+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 
+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 
+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” 
+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
+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
+Availability of “prof” and “gprof” varies from system to system. Almost every
-Unix system has “prof”. Only some systems have “gprof”. 
+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 Plaugher, “The Elements of Programming Style” 
-Kernighan and Ritchie, “The C Programming Language” 
+Kernighan and Ritchie, “The C Programming Language” 
-Brooks, “The Mythical Man Month” 
+Brooks, “The Mythical Man Month” 

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.
+bugs - Bugs reported by players with the ’bug’ command.
-ideas - Ideas from players from ’idea’ 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).
+handbook - Text for Immortal Handbook (’handbook’ command).
-immlist - Text for ’immlist’ 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.
+news - Text for ’news’ command.
-policies - Text for ’policy’ command.
+policies - Text for ’policy’ command.
-wizlist - Text for ’wizlist’ command.
+wizlist - Text for ’wizlist’ command.
-/help/screen - Text for ’help’ command as a mortal with no arguments.
+/help/screen - Text for ’help’ command as a mortal with no arguments.
-/help/iscreen - Text for ’help’ command an an immortal 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 
+additional files – one called ‘index’, which specifies which files in that 
-directory should be loaded when the MUD boots, and ‘index.mini’, which 
+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. 

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” 
+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
+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 
+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’ 
+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 
+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 
+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 
+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
+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. 

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. 

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 
+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 
+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:

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 <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. 
+<wizlistfile> is the filename for the file containing the game’s Wizlist. 
-<immlev> should be set to your game’s LVL_IMMORT, while <immlistfile> 
+<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.