diff --git a/doc/building.txt b/doc/building.txt index 8b19742..4ac649a 100644 --- a/doc/building.txt +++ b/doc/building.txt @@ -1,7 +1,7 @@ If you have any additions, corrections, ideas, or bug reports please stop by the Builder Academy at telnet://tbamud.com:9091 or email rumble@tbamud.com -- Rumble -The tbaMUD Builder’s Manual +The tbaMUD Builder’s Manual Originall by Jeremy Elson This document describes how to create tbaMUD areas, and specifies the file @@ -85,7 +85,7 @@ As a Tinyworld Architect or Builder, your job is to create the virtual world in which players can roam around, solve puzzles, find treasures, and gain experience. A Builder creates the rooms, objects, and monsters with which players will interact, defining their textual descriptions, stats, abilities, -and other special properties. A Builder should not be confused with the MUD’s +and other special properties. A Builder should not be confused with the MUD’s Coder, whose job it is to modify the C code that makes the tbaMUD server actually run. A Builder does not need to be a programmer, and building is not programming; building is done via online creation in game, which this document @@ -105,8 +105,8 @@ is like writing a book. It needs to have a plot, needs to be descriptive, and needs to be populated with memorable people and places. Writing an area requires inspiration and imagination before all else. Ideas for -areas often come from literature; for example, an area that traces Alice’s -adventures through Wonderland or Dante’s trip through the Inferno. Areas +areas often come from literature; for example, an area that traces Alice’s +adventures through Wonderland or Dante’s trip through the Inferno. Areas usually start out on paper long before they reach a computer; a general map of the region can help to solidify the idea and a specific map of each individual room is absolutely required so that the rooms can be linked together in a way @@ -117,7 +117,7 @@ the monsters should appear can also help when planning an area. 1.2 Game Balance Game Balance is a term that brings a different thing to mind for every person that hears it. What is most important about game balance is to keep in mind for -whom each area is designed – for example, high level players, newbies, or small +whom each area is designed – for example, high level players, newbies, or small groups. The objects and monsters found in the area should match the level, abilities, and needs of the players expected to use the area. Most players do not like to be given vast treasure with no difficulty in getting it, but on the @@ -133,31 +133,31 @@ rest of the world. Each area that comes with the MUD or is added later should be checked by one or more implementors or builders, and the characteristics of the monsters and objects should be changed to suit to the balance of the MUD. Each new area that becomes part of the world should not be added until it -has been similarly balanced to the implementors’ satisfaction. Understandably, +has been similarly balanced to the implementors’ satisfaction. Understandably, builders want their zones to be popular, but they sometimes attempt to achieve this goal by purposefully making their zone unbalanced, adding powerful weapons or armor with no harmful side-effects or monsters that are easy to kill yet give massive numbers of experience points. Such zones are destined both to -become very popular and invariably to bring about the death of your MUD’s game +become very popular and invariably to bring about the death of your MUD’s game balance. -An area’s balance should be an integral part of the design process, not +An area’s balance should be an integral part of the design process, not something to be tacked on as an afterthought. Too often, an area will be designed with outrageously good weapons and armor which throws off the balance of the game. Naturally, after such zone is added, players complain bitterly if it is ever removed or toned down. Also, because the rent system saves hitrolls, -damrolls, and ac-apply’s, veteran players will be able to hold on to their old, +damrolls, and ac-apply’s, veteran players will be able to hold on to their old, spectacular equipment unless it is explicitly taken from them, even after the area has been changed. This does nothing but generate bad feelings on all sides. Therefore, the wise implementor will always carefully check a zone for balance before it is added to the production MUD. It is generally not a good -idea to “let the players balance the area” by unleashing an unbalanced area on +idea to “let the players balance the area” by unleashing an unbalanced area on them and watching to see where the hordes of players go. 1.3 Making Your Areas Interesting An interesting area will always attract more players than a bland one. There are many ways to make an area interesting. Try to be as descriptive as -possible; don’t hold back on writing extra descriptions. Players are so +possible; don’t hold back on writing extra descriptions. Players are so accustomed to not having richly described areas that finding an extra description can often be a real treat. Also, one oft forgotten thing to describe are the door exits. Describing all of these can give a feel of @@ -172,7 +172,7 @@ carefully the first time they walk through an area, and having many extra descriptions helps them fill out their idea of what things actually look like. One thing that should never be done is to have generic room descriptions like -“You stand in a big room. It is very dark.” Descriptions like these detract in +“You stand in a big room. It is very dark.” Descriptions like these detract in general from the rest of the world, and if they are found room after room can bore a player to tears. Such a description could be changed to: @@ -189,7 +189,7 @@ the evil Lord Zygol, simple like ridding the caves of goblins, or anything in between. Often the plot in an area can be advanced by some fairly simple puzzles or descriptions. With the addition of triggers, involved puzzles and quest can be readily created. Not all monsters have to be designed to be -killed, nor does every shopkeeper have to buy or sell something – they could +killed, nor does every shopkeeper have to buy or sell something – they could just be created so that they refuse to trade with any player characters. The players will then wonder why the shopkeeper exists. Perhaps giving him a jewel will make him more friendly. In this way, an area can be made infinitely more @@ -216,9 +216,9 @@ building as hassle free as possible. 2 The Mechanics of World Building 2.1 Overview of the MUD World -tbaMUD’s world is divided into distinct sections called zones. Each zone +tbaMUD’s world is divided into distinct sections called zones. Each zone typically consists of a single, modular, geographically coherent region of the -MUD’s virtual world with a consistent storyline. Each zone can define its own +MUD’s virtual world with a consistent storyline. Each zone can define its own physical space (the world), monsters (usually called mobiles), objects (such as armor, weapons and treasures), triggers (what we use to create interaction with players) and shops, in which a mobile in a particular room can buy and @@ -226,7 +226,7 @@ sell objects to players. A single zone typically contains up to than 100 rooms, 100 monster definitions and 100 object definitions, but a large region can be subdivided into several -zones at the author’s discretion. For example, the City of Midgaard is divided +zones at the author’s discretion. For example, the City of Midgaard is divided into two zones, one for the main city and one for the southern residential area. In addition to this, with the new zone system describing top and bottom rooms of a zone, zones can contain very few rooms and indeed can overlap with other @@ -263,7 +263,7 @@ which rooms they stand, the equipment that each mobile uses, objects which might be on the floor, and the doors which may be initially locked or unlocked. When the tbaMUD server runs the zone, it sets each zone to its initial state as -defined by the author, and then makes the zone “come alive” by randomly making +defined by the author, and then makes the zone “come alive” by randomly making mobiles wander through the zone and, if desired, attack players. While the players are using the zone (killing the mobiles and picking up equipment) the server periodically resets the zone to its initial state (a zone reset) to @@ -286,7 +286,7 @@ and are not comprehensive examples of all possible ways to use the features that will be described. The most effective way is to learn by example: examine some of the areas that come with tbaMUD and try to figure out the meanings of the numbers in different rooms, objects, mobiles, and zone files, using this -manual as a guide. Once you’re proficient at reading world files, you’ll find +manual as a guide. Once you’re proficient at reading world files, you’ll find that creating them is a much easier task. 2.3 tbaMUD World Files @@ -295,7 +295,7 @@ object files, shop files, trigger files, and zone files. World files (*.wld) define the actual rooms and the links from one room to another. Mobiles (*.mob) are the monsters which inhabit the MUD. Objects (*.obj) are the weapons, armor, treasure, and other objects manipulated by players and monsters. Shop files -(*.shp) define the MUD’s shopkeepers, controlling what they buy, sell, and say. +(*.shp) define the MUD’s shopkeepers, controlling what they buy, sell, and say. Trigger files (*.trg) allow interaction between players and rooms, mobs, or objects. Finally, Zone files (*.zon) bring all the previous elements together to define the initial state of the zone, describing how monsters should be @@ -310,16 +310,16 @@ six types of files are split in a similar manner. tbaMUD has one directory for the room files (lib/world/wld/), one directory for the object files (lib/world/obj/), and so forth. -tbaMUD doesn’t care how the world files are split or what the names of the +tbaMUD doesn’t care how the world files are split or what the names of the files are, but certain conventions have developed to make management of the world easier. Each file typically contains information for only a single zone and the filename is typically the zone number, with an extension indicating one of the 6 file types. For example, the file 30.wld contains rooms 3000 to 3099 of zone 30; 42.mob contains mobiles 4200 to 4299 of zone 42, etc. -Also in each of these directories is a file called “index” that tells the +Also in each of these directories is a file called “index” that tells the server which files from that directory should be loaded when the server boots -and a file called “index.mini” which (minimal) set of files should be loaded +and a file called “index.mini” which (minimal) set of files should be loaded when the server is booted with the -m option. Every world file used by tbaMUD (including the index files) must be terminated @@ -327,7 +327,7 @@ by the dollar sign ($) to tell the server that the file has ended. Without the dollar sign, the server will not boot properly. 2.4 Using Bitvectors -When learning about the formats of tbaMUD world files, you’ll frequently see +When learning about the formats of tbaMUD world files, you’ll frequently see references to bitvectors. A bitvector is a group of flags which each can be either on or off. Bitvectors and their flags are used in many ways within tbaMUD, such as to define the personality of mobiles, the characteristics of @@ -350,19 +350,19 @@ what the flag does. There are two ways you can construct a bitvector with the table above: the numeric method and the alphabetic method. The numeric method is to select all -flags you’d like to activate, take the numbers of those flags as listed in the +flags you’d like to activate, take the numbers of those flags as listed in the first column of the table, and add them all up. The resulting sum will be the bitvector. The alphabetic method is much easier: just write down all the -letters of the flags you’d like to use with no spaces in between. For both -numeric and alphabetic bitvectors, use “0” to indicate a bitvector where none +letters of the flags you’d like to use with no spaces in between. For both +numeric and alphabetic bitvectors, use “0” to indicate a bitvector where none of the flags are set. For example, imagine you want to create a room that is dirty, mushy, and -resembles a swamp, but does not stink. Using the numeric method, you’d look up +resembles a swamp, but does not stink. Using the numeric method, you’d look up the numbers of those three flags (1 for dirty, 4 for mushy, and 8 for swampy), and add them up to get 13. Using the alphabetic method, the bitvector would -simply be “acd”. Bitvectors are case-sensitive; “acd” is very different from -“Acd” and “ACD”. +simply be “acd”. Bitvectors are case-sensitive; “acd” is very different from +“Acd” and “ACD”. At every point where the tbaMUD format requires a bitvector, you can write either a numeric bitvector or an alphabetic bitvector. They are completely @@ -371,8 +371,8 @@ your area will not be compatible with MUDs based on the original DikuMud. Alphabetic bitvectors are a tbaMUD enhancement and may not be supported by MUDs based on Gamma Diku. -In some bitvector tables, you will see values whose descriptions say “Reserved -for internal use” or “Do not use”. You should never set those flag values in +In some bitvector tables, you will see values whose descriptions say “Reserved +for internal use” or “Do not use”. You should never set those flag values in your world files. 2.5 Adding New Areas to the MUD @@ -410,7 +410,7 @@ index.mini file. Now you can try to boot the MUD with the new world. Run tbaMUD via "bin/circle" and look for any SYSERR messages. If you receive no errors congratulations. Otherwise, check the tbaMUD SYSERR List for more information on how to -correct the formatting errors. also, see the tbaMUD Administrator’s Guide for +correct the formatting errors. also, see the tbaMUD Administrator’s Guide for more information on how to run tbaMUD. 3 World (Room) Files @@ -428,26 +428,26 @@ S There can be between 0 and 6 direction fields in the standard tbaMUD code. There should not be more than one direction field for a particular direction. -For more information on adding directions to the standard “neswud”, see the +For more information on adding directions to the standard “neswud”, see the Coding tbaMUD document. No Extra Descriptions are required but an unlimited number are allowed. Each room is terminated with the literal letter S. Virtual Number This number is critical; it is the identity of the room within the game. All other files will use this number to refer to this room. From -within the game, this number can be used with “goto” to go to this room. The +within the game, this number can be used with “goto” to go to this room. The virtual numbers must appear in increasing order in the world file. -Room Name This string is the room’s title, which is displayed before the room +Room Name This string is the room’s title, which is displayed before the room description when players look at the room, or displayed alone if players are -using “brief.” Room Description The description of the room seen when they type -“look,” or when they enter the room with brief mode off. +using “brief.” Room Description The description of the room seen when they type +“look,” or when they enter the room with brief mode off. Zone Number This number is obsolete and no longer used. Historically it contained the zone number of the current room but it is currently ignored for everything except debugging messages. It is maintained as part of the format for backwards compatibility. -Room Bitvector A bitvector (see section 2.4 on ‘Using Bitvectors’), with the +Room Bitvector A bitvector (see section 2.4 on ‘Using Bitvectors’), with the following values: 1) DARK - The room is dark, players need a light source, or infravision. @@ -494,7 +494,7 @@ The following terrains may be selected (only one): 8 FLYING Wheee! Requires AFF_FLYING. 1 9 UNDERWATER Underwater requires AFF_SCUBA. 5 -Direction Fields and Extra Descriptions This section defines the room’s exits, +Direction Fields and Extra Descriptions This section defines the room’s exits, if any, as well as any extra descriptions such as signs or strange objects that might be in the room. This section can be empty if the room has no exits and no extra descriptions. Otherwise, it can have any number of D (Direction Field) @@ -522,22 +522,22 @@ must be one of the following numbers: 4 Up 5 Down -General Description The description shown to the player when she types “look -”. This should not be confused with the room description itself. +General Description The description shown to the player when she types “look +”. This should not be confused with the room description itself. Unlike the room description which is automatically viewed when a player walks into a room, the General Description of an exit is only seen when a player -looks in the direction of the exit (e.g., “look north”). Exit descriptions -take priority over extra descriptions. So if you creat a extra description for +looks in the direction of the exit (e.g., “look north”). Exit descriptions +take priority over extra descriptions. So if you create a extra description for north the player will see the exit description only when they "look north." Keyword List A list of acceptable terms that can be used to manipulate the door -with commands such as “open,” “close,” “lock,” “unlock,” etc. The list should +with commands such as “open,” “close,” “lock,” “unlock,” etc. The list should be separated by spaces, such as: door oak big~ Door Flag Can take one of three values (0, 1 or 2): 0 An unrestricted exit that has no door, or a special door cannot be opened or -closed with the “open” and “close” commands. The latter is useful for secret +closed with the “open” and “close” commands. The latter is useful for secret doors, trap doors, or other doors that are opened and closed by something other than the normal commands, like a trigger assigned to the room or an object in the room. @@ -557,16 +557,16 @@ is ignored. Room Linked The virtual number of the room to which this exit leads. If this number is -1 (NOWHERE), the exit will not actually lead anywhere; useful if -you’d like the exit to show up on “exits,” or if you’d like to add a description -for “look ” without actually adding an exit in that direction. +you’d like the exit to show up on “exits,” or if you’d like to add a description +for “look ” without actually adding an exit in that direction. 3.3 Room Extra Descriptions Extra descriptions are used to make rooms more interesting, and make them more -interactive. Extra descriptions are accessed by players when they type “look at -”, where is any word you choose. For example, you might write a -room description which includes the tantalizing sentence, “The wall looks -strange here.” Using extra descriptions, players could then see additional -detail by typing “look at wall.” There can be an unlimited number of Extra +interactive. Extra descriptions are accessed by players when they type “look at +”, where is any word you choose. For example, you might write a +room description which includes the tantalizing sentence, “The wall looks +strange here.” Using extra descriptions, players could then see additional +detail by typing “look at wall.” There can be an unlimited number of Extra Descriptions in each room. The format of an extra description is simple: @@ -579,8 +579,8 @@ E Keyword List A space-separated list of keywords which will access the description in this E section. -Description Text The text that will be displayed when a player types “look -,” where is one of the keywords specified in the Keyword +Description Text The text that will be displayed when a player types “look +,” where is one of the keywords specified in the Keyword List of this Esection. 3.4 World File Example @@ -608,17 +608,17 @@ oak door~ 1 18000 18630 E portal floor~ -It looks as if you could go down into it... but you can’t be +It looks as if you could go down into it... but you can’t be sure of where you will end up, or if you can get back. ~ S -This room is virtual number 18629, called “The Red Room”. It is dark and -indoors, with an “INDOORS” sector type. It has an exit north and east. The -north exit leads to room 18620; if a player types “look north” it will say “You -see a big room up there.” The exit east is a normal, pickable door that leads +This room is virtual number 18629, called “The Red Room”. It is dark and +indoors, with an “INDOORS” sector type. It has an exit north and east. The +north exit leads to room 18620; if a player types “look north” it will say “You +see a big room up there.” The exit east is a normal, pickable door that leads to room 18630 and which takes key number 18000. There is one extra description -for “portal” and “floor”. +for “portal” and “floor”. 4 Mobile (Monster) Files @@ -637,34 +637,34 @@ The format of a mobile is: Virtual Number This number is critical; it is the identity of the mobile within the game. It is the number that will be used to reference the mobile from zone -files and is the number used to “load” mobiles from within the game. The +files and is the number used to “load” mobiles from within the game. The virtual numbers must appear in increasing order in the mob file. Keywords The list of keywords, separated by spaces, that can be used by players to identify the mobile. The mobile can only be identified using the keywords in this list; it cannot be identified by a word that appears only in its name. Great care should be taken to ensure that the spellings of names and -keywords match. Fill words such as “the,” “a,” and “an” should not appear in +keywords match. Fill words such as “the,” “a,” and “an” should not appear in the Keywords List. Short Description The description of the mobile used by the MUD when the mobile -takes some action. For example, a short description of “The Beastly Fido” would -result in messages such as “The Beastly Fido leaves south.” and “The Beastly -Fido hits you hard.” The Short Description should never end with a punctuation +takes some action. For example, a short description of “The Beastly Fido” would +result in messages such as “The Beastly Fido leaves south.” and “The Beastly +Fido hits you hard.” The Short Description should never end with a punctuation mark because it will be inserted into the middle of sentences such as those above. Long Description The description displayed when a mobile is in its default -position; for example, “The Beastly Fido is here, searching through garbage for -food.” When the mobile is in a position other than its default position, such +position; for example, “The Beastly Fido is here, searching through garbage for +food.” When the mobile is in a position other than its default position, such as sleeping or incapacitated, the short description is used instead; for -example, “The Beastly Fido is lying here, incapacitated.” Unlike the Short +example, “The Beastly Fido is lying here, incapacitated.” Unlike the Short Description, the Long Description should end with appropriate punctuation. Detailed Description The description displayed for a mobile when a player looks -at the mobile by typing “look at .” +at the mobile by typing “look at .” -Mob flags bitvector (see section 2.4 on ‘Using Bitvectors’). With the 128 bit +Mob flags bitvector (see section 2.4 on ‘Using Bitvectors’). With the 128 bit expansion you actually have 4 separate bitvectors, i.e. <0 0 0 0> only the first bitvector is used and the other three are for future expansion. @@ -703,7 +703,7 @@ L) NPC Flags : ISNPC 17) NOBASH Large mobs such as trees that cannot be bashed. 18) NOBLIND Mob cannot be blinded. -Affection Flags Bitvector A bitvector (see section 2.4 on ‘Using Bitvectors’) +Affection Flags Bitvector A bitvector (see section 2.4 on ‘Using Bitvectors’) which is also 4 bitvectors <0 0 0 0> with only the first being used with the following values: @@ -732,7 +732,7 @@ M) AFF Flags : NOBITS 21) UNUSED Unused (room for future expansion). 22) CHARM Reserved for internal use. Do not set. -Alignment A number from -1000 to 1000 representing the mob’s initial alignment. +Alignment A number from -1000 to 1000 representing the mob’s initial alignment. -1000.....-350 Evil -349......349 Neutral @@ -755,7 +755,7 @@ For type S mobs, the type-specific information should be in the following format Level The level of the monster, from 1 to 34. -THAC0 “To Hit Armor Class 0” – a measure of the ability of the monster to +THAC0 “To Hit Armor Class 0” – a measure of the ability of the monster to penetrate armor and cause damage, ranging from 0 to 20. Lower numbers mean the monster is more likely to penetrate armor. The formal definition of THAC0 is the minimum roll required on a 20-sided die required to hit an opponent of @@ -769,16 +769,16 @@ AC 0 Very heavily armored person (full plate mail) AC -100 Armored Battle Tank (hopefully impossible for players) Note on THAC0 and Armor Class (AC): When an attacker is trying to hit a victim, -the attacker’s THAC0 and the victim’s AC, plus a random roll of the dice, +the attacker’s THAC0 and the victim’s AC, plus a random roll of the dice, determines whether or not the attacker can hit the victim. (If a hit occurs, a different formula determines how much damage is done.) An attacker with a low THAC0 is theoretically just as likely to hit a victim with a low AC as an attacker with a high THAC0 is to hit a victim with a high AC. Lower attacker -THAC0’s and higher victim AC’s favor the attacker; higher attacker THAC0’s and -lower victim AC’s favor the victim. +THAC0’s and higher victim AC’s favor the attacker; higher attacker THAC0’s and +lower victim AC’s favor the victim. Max Hit Points The maximum number of hit points the mobile is given, which must -be given in the form “xdy+z” where x, y, and z are integers. For example, +be given in the form “xdy+z” where x, y, and z are integers. For example, 4d6+10 would mean sum 4 rolls of a 6 sided die and add 10 to the result. Each individual instance of a mob will have the same max number of hit points from the time it is loaded into the game right up to the time it dies; the dice will @@ -787,12 +787,12 @@ words, a particular copy of a mob will always have the same number of max hit points during its life, but different copies of the same mob may have different numbers of max hit points. -Note that all three numbers, the “d” and the “+” must always appear, even if +Note that all three numbers, the “d” and the “+” must always appear, even if some of the numbers are 0. For example, if you want every copy of a mob to always have exactly 100 hit points, write 0d0+100. Bare Hand Damage (BHD) The amount of damage the mob can do per round when not -armed with a weapon. Also specified as “xdy+z” and subject to the same +armed with a weapon. Also specified as “xdy+z” and subject to the same formatting rules as Max Hit Points. However, unlike Max Hit Points, the dice are rolled once per round of violence; @@ -822,8 +822,8 @@ should be one of the following numbers: Default Position The position to which monsters will return after a fight, which should be one of the same numbers as given above for Load Position. In -addition, the Default Position defines when the mob’s long description is -displayed (see “Long Description” above). +addition, the Default Position defines when the mob’s long description is +displayed (see “Long Description” above). Sex One of the following: @@ -857,10 +857,10 @@ Type E mobiles are specific to tbaMUD and are designed to provide an easy way for MUD implementors to extend the mobile format to fit their own needs. A type E mobile is an extension of type S mobiles; a type E mobile is a type S mobile with extra data at the end. After the last line normally found in type S mobs -(the one ending with the mob’s sex), type E mobiles end with a section called +(the one ending with the mob’s sex), type E mobiles end with a section called the Enhanced section. This section consists of zero or more enhanced mobile specifications (or E-specs), one per line. Each E-spec consists of a keyword -followed by a colon (“:”) and a value. The valid keywords are listed below. The +followed by a colon (“:”) and a value. The valid keywords are listed below. The literal letter Emust then come after all E-specs to signal the end of the mob. The format of an E mobile is as follows: @@ -873,9 +873,9 @@ The format of an E mobile is as follows: E 4.5 Type E Mobile Example -Let’s say that you wanted to create an enhanced Fido like the one in the +Let’s say that you wanted to create an enhanced Fido like the one in the previous example, but one that has a bare-hand attack type of 4 so that the -Fido bites players instead of hitting them. Let’s say you also wanted to give +Fido bites players instead of hitting them. Let’s say you also wanted to give this Fido the a strength of 18. You might write: #3062 @@ -909,7 +909,7 @@ Con, and Cha. However, the E-Specs have been designed such that new ones are quite easy to add. BareHandAttack This controls the description of violence given during battles, -in messages such as “The Beastly fido bites you very hard.” BareHandAttack +in messages such as “The Beastly fido bites you very hard.” BareHandAttack should be one of the following numbers: 0) hit 6) crush 11) pierce @@ -927,12 +927,12 @@ changed. Note that adding new attack types requires code changes and cannot be accomplished simply by adding new messages to lib/misc/messages (see the tbaMUD Coding Manual for more information). -Str, Int, Wis, Dex, Con, Cha The mobile’s Strength, Intelligence, Wisdom, +Str, Int, Wis, Dex, Con, Cha The mobile’s Strength, Intelligence, Wisdom, Dexterity, Constitution and Charisma, respectively. These values should be between 3 and 18, but can be between 1 and 25 (which is the default statistic maximum). -StrAdd The mobile’s strength addition, which can range from 1 to 99. +StrAdd The mobile’s strength addition, which can range from 1 to 99. 5 Object Files @@ -952,24 +952,24 @@ Fields. Virtual Number This number is critical; it is the identity of the object within the game. It is the number that will be used to reference the object -from zone files and is the number used to “load” objects from within the game. +from zone files and is the number used to “load” objects from within the game. The virtual numbers must appear in increasing order in the object file. Keywords The list of keywords, separated by spaces, that can be used by players to identify the object. The object can only be identified using the keywords that appear in this list; it cannot be identified by a word that appears only in its name. Great care should be taken to ensure that the spellings of names -and keywords match. Fill words such as “the,” “a,” and “an” should not appear +and keywords match. Fill words such as “the,” “a,” and “an” should not appear in the keywords List. Short Description The description of the object used by the MUD when the object -is used. For example, a short description of “a long, green stick” would result -in messages such as “The Beastly Fido picks up the long, green stick.” The +is used. For example, a short description of “a long, green stick” would result +in messages such as “The Beastly Fido picks up the long, green stick.” The Short Description should never end with a punctuation mark because it will be inserted into the middle of sentences. Long Description The description displayed when the object is seen lying on the -ground, for example, “A furled umbrella is lying here.” Unlike the Short +ground, for example, “A furled umbrella is lying here.” Unlike the Short Description, the Long Description should end with appropriate punctuation. Action Description Action Descriptions are primarily used for magical objects @@ -1019,9 +1019,9 @@ the following numbers: 22 BOAT Item is a boat; allows you to traverse water (noswim). 23 FOUNTAIN Item is a fountain. Set Values to -1 to make it unlimited. -Extra (Effects) Bitvector A bitvector (see section 2.4 on ‘Using Bitvectors’), -to define the “special effects” of the object. Flags that are marked as -“cosmetic” merely add an interesting message to the object when it is examined, +Extra (Effects) Bitvector A bitvector (see section 2.4 on ‘Using Bitvectors’), +to define the “special effects” of the object. Flags that are marked as +“cosmetic” merely add an interesting message to the object when it is examined, but has no substantive effect otherwise. The flags have the following values: 1) GLOW Item is glowing (cosmetic). @@ -1042,7 +1042,7 @@ but has no substantive effect otherwise. The flags have the following values: 16) ANTI_WARRIOR Item cannot be used by the Warrior class. 17) NOSELL Shopkeepers will not buy or sell the item. -Wear Bitvector A bitvector (see section 2.4 on ‘Using Bitvectors’) with +Wear Bitvector A bitvector (see section 2.4 on ‘Using Bitvectors’) with the following values: 1) TAKE Item can be taken (picked up off the ground) (DEFAULT). @@ -1062,12 +1062,12 @@ the following values: 15) HOLD Item can be held (the "hold" command). Note that the TAKE bit controls whether or not an item can be picked up using -the “get” command, whereas the HOLD bit controls if the object can be worn -using the “hold” command. +the “get” command, whereas the HOLD bit controls if the object can be worn +using the “hold” command. Value 0, Value 1, Value 2, Value 3 These values are very central. They define -the object’s abilities based on the Type Flag. See the subsection “Object Value -Definitions” below for a detailed description of the four Value fields. +the object’s abilities based on the Type Flag. See the subsection “Object Value +Definitions” below for a detailed description of the four Value fields. Weight The weight of the object. The weight controls how many strength points a character must have to take the object, and is used to calculate when bags and @@ -1078,11 +1078,11 @@ Cost The value of the object in gold coins; used by shopkeepers. Rent Per Day The cost per day to rent the object in the Reception. 5.2 Object Value Definitions -The meaning of an object’s four values (value 0 through value 3) vary depending +The meaning of an object’s four values (value 0 through value 3) vary depending on the Type Flag of the object. -In the table below, “unused” means that the server ignores the value; it can -be set to any number (but 0 is always a safe bet). “unimplemented” indicates a +In the table below, “unused” means that the server ignores the value; it can +be set to any number (but 0 is always a safe bet). “unimplemented” indicates a Type Flag currently not recognized by the server. An index of spell numbers for use with magical objects can be found in the @@ -1096,19 +1096,19 @@ value 2: Capacity of light in hours. value 3: unused SCROLL: (Type Flag 2) -value 0: Level at which scroll’s spells are cast. +value 0: Level at which scroll’s spells are cast. value 1: Spell number 1 value 2: Spell number 2 value 3: Spell number 3 WAND: (Type Flag 3) -value 0: Level at which wand’s spell is cast +value 0: Level at which wand’s spell is cast value 1: Charge capacity of wand (>= 1) value 2: Current number of charges remaining value 3: Spell number STAFF: (Type Flag 4) -value 0: Level at which staff’s spell is cast +value 0: Level at which staff’s spell is cast value 1: Charge capacity of staff (>= 1) value 2: Current number of charges remaining value 3: Spell number @@ -1142,7 +1142,7 @@ the AC; values <0 damage the AC (cursed armor, for example). value 1-3: unused POTION: (Type Flag 10) -value 0: Level at which the potion’s spells are cast. +value 0: Level at which the potion’s spells are cast. value 1: Spell number 1 value 2: Spell number 2 value 3: Spell number 3 @@ -1163,7 +1163,7 @@ CONTAINER: (Type Flag 15) value 0: Capacity (max containable weight) of container value 1: Container flag bitvector (MUST be a numeric bitvector) 1 CLOSEABLE Container can be closed and locked. -2 PICKPROOF Lock on container can’t be picked. +2 PICKPROOF Lock on container can’t be picked. 4 CLOSED Container is closed when loaded. 8 LOCKED Container is locked when loaded. value 2: The vnum of the key object that opens this container. -1 if it has @@ -1209,8 +1209,8 @@ E Keyword List A space-separated list of keywords which will access the description in this E section. -Description Text The text that will be displayed when a player types “look -,” where is one of the keywords specified in the Keyword +Description Text The text that will be displayed when a player types “look +,” where is one of the keywords specified in the Keyword List of this E section. 5.4 Object Affect Fields @@ -1306,7 +1306,7 @@ S Lines starting with *are considered comments and ignored. Zone commands themselves may also be followed by a comment which does not need to be delimited by a single *. Please note that the initial lines of a zone file -may not have comments on them at all. The zone’s commands must then be +may not have comments on them at all. The zone’s commands must then be terminated by the literal letter S. Virtual Number An arbitrary number used to identify the zone. Zone numbers are @@ -1325,7 +1325,7 @@ to Top Room of that zone. Lifespan The number of real-time minutes between zone resets for this zone. When the age of the zone (measured in minutes since the last time that zone -has been reset) reaches the zone’s lifespan, the zone is queued for reset. The +has been reset) reaches the zone’s lifespan, the zone is queued for reset. The zone is then reset when it reaches the front of the queue, and the conditions of the Reset Mode (see below) are satisfied. @@ -1337,7 +1337,7 @@ effectively ignored. 1 Reset the zone only after it reaches its Lifespan and after the zone becomes deserted, i.e. as soon as there are no players located within the zone (checked -once every minute). This can make a zone more “fair” because it will keep the +once every minute). This can make a zone more “fair” because it will keep the hard mobs from reappearing in the zone until everyone leaves, but on a busy MUD it can prevent a zone from ever being reset since the zone may never stay empty for more than one minute. @@ -1348,16 +1348,16 @@ is in it. This is the most commonly used Reset Mode. 6.2 Zone Commands Each command consists of a letter, identifying the command-type, followed by three or four arguments. The first argument, common to all the commands, is -called the “if-flag.” If the if-flag for a command is 1, that command is only +called the “if-flag.” If the if-flag for a command is 1, that command is only executed if the command immediately before it was executed as well. If the if-flag is 0, the command is always executed. If-flags are useful for things -like equipping mobiles. You don’t want to try to equip a mobile that has not +like equipping mobiles. You don’t want to try to equip a mobile that has not been loaded. -Commands that load mobiles and objects also include a “max existing” argument. +Commands that load mobiles and objects also include a “max existing” argument. This specifies the maximum number of copies of the mobile or object that are allowed to exist in the entire world at once. If the number currently existing -is greater than or equal to the “max existing” limit, the command is not +is greater than or equal to the “max existing” limit, the command is not executed. The valid zone-reset commands are M, O, G, E, P, D, and R. @@ -1375,14 +1375,14 @@ be placed. The object will be loaded and left lying on the ground. G: give object to mobile Format: G Obj vnum is the vnum of the obj to be given. The object will be loaded and placed in the inventory of the last -mobile loaded with an “M” command. This command will usually be used with an +mobile loaded with an “M” command. This command will usually be used with an if-flag of 1, since attempting to give an object to a non-existing mobile will result in an error. E: equip mobile with object Format: E Obj vnum is the vnum of the obj to be equipped. The object will be loaded and added to the -equipment list of the last mobile loaded with an “M” command. Equipment +equipment list of the last mobile loaded with an “M” command. Equipment Position should be one of the following: You are using: Trigedit positions @@ -1475,7 +1475,7 @@ S 7 Shop Files tbaMUD now has a new shop file format. Since the old format is still supported, -both formats will be documented. If you’d like to convert shop files in the old +both formats will be documented. If you’d like to convert shop files in the old format to that of the new format, compile and run the utility shopconv. Version 3 shops must have a special marker (described below) to tell the server that the file is in the new format. @@ -1493,8 +1493,8 @@ tbaMUD Shop File~ $~ -Version 3 shop files start with the literal line “tbaMUD v3.0 Shop File˜”, -followed by any number of shop definitions, and terminated by $˜. The format +Version 3 shop files start with the literal line “tbaMUD v3.0 Shop File˜”, +followed by any number of shop definitions, and terminated by $˜. The format of a shop definition is: #~ @@ -1517,8 +1517,8 @@ of a shop definition is: ~ ~ ~ -~ -~ +~ +~ ~ ~ @@ -1544,23 +1544,24 @@ Item Vnum 1...Item Vnum n An arbitrarily long list of the virtual numbers of objects that the shop produces (i.e., items which will always be available, no matter how many are bought). The list must be terminated with -1. -Profit When Selling The price of an object when a shopkeeper sells it is the object’s value times Profit When Selling. This is a floating point value. It -should be >= 1.0. +Profit When Selling The price of an object when a shopkeeper sells it is the +object’s value times Profit When Selling. This is a floating point value. +It should be >= 1.0. Profit When Buying The amount of money a shopkeeper will offer when buying an -object is the object’s value times Profit When Buying. This is a floating point +object is the object’s value times Profit When Buying. This is a floating point value. It should be <= 1.0. Buy Types and Buy Namelists These lines control what types of items that the shop will buy. There can be an arbitrarily long list of buy types terminated by --1. The first argument, called “Buy Type” is the Type Flag of items the shop -will buy (see “Type Flag” under “Format of an Object” in this document). +-1. The first argument, called “Buy Type” is the Type Flag of items the shop +will buy (see “Type Flag” under “Format of an Object” in this document). Numerical and English forms are both valid (5 or WEAPON, 9 or ARMOR, etc.). The second (optional) argument is called a Buy Namelist and allows you to provide optional keywords to define specific keywords that must be present on the objects for the shopkeeper to buy or sell it. For further details on these -expressions, see the section “Item Name Lists” below. +expressions, see the section “Item Name Lists” below. Message when item to buy does not exist The message given to a player if he tries to buy an item that the shopkeeper does not have in his inventory. @@ -1572,23 +1573,23 @@ Message when shop does not buy offered item The message given to a player if he tries to sell an item that the shopkeeper does not want to buy (controlled by the Buy Types and Buy Namelists.) -Message when shop can’t afford item The message given to a player if he tries +Message when shop can’t afford item The message given to a player if he tries to sell an item to a shop, but the shopkeeper does not have enough money to buy it. -Message when player can’t afford item The message given to a player if he -tries to buy an item from a shop but doesn’t have enough money. +Message when player can’t afford item The message given to a player if he +tries to buy an item from a shop but doesn’t have enough money. Message when successfully buying an item The message given to a player when he successfully buys an item from a shop. The expression %d can be used in place -of the cost of the item (e.g., That’ll cost you %d coins, thanks for your +of the cost of the item (e.g., That’ll cost you %d coins, thanks for your business! Message when successfully selling an item The message given to a player when he successfully sells an item to a shop. The expression %d can be used in place of the cost of the item as above. -Temper When player can’t afford an item, the shopkeeper tells them they can’t +Temper When player can’t afford an item, the shopkeeper tells them they can’t afford the item and then can perform an additional action (-1, 0, or 1): -1 No action other than the message. @@ -1598,7 +1599,7 @@ afford the item and then can perform an additional action (-1, 0, or 1): Further actions can be added by your local coder (e.g., attacking a player, stealing his money, etc.) -Shop Bitvector A bitvector (see section 2.4 on ‘Using Bitvectors’) with the +Shop Bitvector A bitvector (see section 2.4 on ‘Using Bitvectors’) with the following values: 1 a WILL_START_FIGHT Players can try to kill shopkeeper. 2 b WILL_BANK_MONEY Shopkeeper will put money over 15000 coins in the bank. @@ -1609,7 +1610,7 @@ monty-haul campaigns. Shop Keeper Mobile Number Virtual number of the shopkeeper mobile. -With Who Bitvector A bitvector (see section 2.4 on ‘Using Bitvectors’) used to +With Who Bitvector A bitvector (see section 2.4 on ‘Using Bitvectors’) used to designate certain alignments or classes that the shop will not trade with, with the following values: @@ -1622,7 +1623,7 @@ E) No Trade With : NOBITS 7) Warrior Shop Room 1...Shop Room n The virtual numbers the mobile must be in for the -shop to be effective. (So transferred shopkeepers can’t sell in the desert). +shop to be effective. (So transferred shopkeepers can’t sell in the desert). The list can be arbitrarily long but must be terminated by a -1. Times when open The times (in MUD-hours) between which the shop is open. Two @@ -1636,7 +1637,7 @@ always open, these four values should be 7.2 Item Name Lists for v3 Shops Name lists are formed by boolean expressions. The following operators are -available: ’,^=Not *,&=And +,|=Or +available: ’,^=Not *,&=And +,|=Or The precedence is Parenthesis, Not, And, Or. Take the following line for an example: @@ -1648,21 +1649,21 @@ This shop will buy the following items of type WEAPON: 1. sword long magic 2. short magic (the first & is done before the first |) 3. warhammer magic -4. ˆgolden bow magic +4. ˆgolden bow magic -Note that the ˆ in front of golden affects ONLY golden, and nothing else in the +Note that the ˆ in front of golden affects ONLY golden, and nothing else in the listing. Basically, the above expression could be written in English as: [(sword and long) or short or warhammer or (not golden and bow)] and magic -If you want the shop to only buy “short magic” only if they were also swords, +If you want the shop to only buy “short magic” only if they were also swords, you could change the expression to: WEAPON [sword & (long|short) | warhammer | ^golden & bow] ^-Changes--^ & magic -You can also include object extra flags (listed in the section “Format of an -Object” above). The previous example used “magic” as a keyword that had to be +You can also include object extra flags (listed in the section “Format of an +Object” above). The previous example used “magic” as a keyword that had to be on the object. If we wanted to make it so that the MAGIC flag had to be set on -the item, we would change “magic” to “MAGIC”. Similar changes could be made to -add other flags such as “HUM” or “GLOW”. It should be noted that these +the item, we would change “magic” to “MAGIC”. Similar changes could be made to +add other flags such as “HUM” or “GLOW”. It should be noted that these expressions are case sensitive and that all keywords should appear in lower-case, while the flag names should be in all caps. @@ -1680,7 +1681,7 @@ num4 num5 Virtual numbers of the objects that the shop produces. --1’s should be inserted in unused slots. +-1’s should be inserted in unused slots. Profit when selling @@ -1704,8 +1705,8 @@ Flags of objects that the shopkeeper will buy). Message When Item to buy is non existing~ Message When item trying to sell is non existing~ Message When wrong item-type sold~ -Message when shop can’t afford item~ -Message when player can’t afford item~ +Message when shop can’t afford item~ +Message when player can’t afford item~ Message when buying an item~ Price is represented by %d. @@ -1715,8 +1716,8 @@ Price is represented by %d. Temper -When player can’t afford an item, the shopkeeper tells -them they can’t afford the item and then: +When player can’t afford an item, the shopkeeper tells +them they can’t afford the item and then: 0 -The shopkeeper pukes on the player. 1 -The shopkeeper smokes his joint. @@ -1724,7 +1725,7 @@ other -No action besides message above. Shop Bitvector -A bitvector (see section ‘Using Bitvectors’) with the following values: +A bitvector (see section ‘Using Bitvectors’) with the following values: 1 a WILL_START_FIGHT Players can to try to kill this shopkeeper. 2 b WILL_BANK_MONEY Shopkeeper will put money over 15000 coins in the bank. @@ -1735,20 +1736,20 @@ non monty-haul campaigns. Shop Keeper Mobile Number Virtual number of the shopkeeper mobile. With Who Bitvector -A bitvector (see section ‘Using Bitvectors’) used to designate certain +A bitvector (see section ‘Using Bitvectors’) used to designate certain alignments or classes that the shop will not trade with, with the following values: -1 a NOGOOD Keeper won’t trade with positively-aligned players. -2 b NOEVIL Keeper won’t trade with evilly-aligned players. -4 c NONEUTRAL Keeper won’t trade with neutrally-aligned players. -8 d NOMAGIC_USER Keeper won’t trade with the Mage class. -16 e NOCLERIC Keeper won’t trade with the Cleric class. -32 f NOTHIEF Keeper won’t trade with the Thief class. -64 g NOWARRIOR Keeper won’t trade with the Warrior class. +1 a NOGOOD Keeper won’t trade with positively-aligned players. +2 b NOEVIL Keeper won’t trade with evilly-aligned players. +4 c NONEUTRAL Keeper won’t trade with neutrally-aligned players. +8 d NOMAGIC_USER Keeper won’t trade with the Mage class. +16 e NOCLERIC Keeper won’t trade with the Cleric class. +32 f NOTHIEF Keeper won’t trade with the Thief class. +64 g NOWARRIOR Keeper won’t trade with the Warrior class. Shop Room Number The virtual number the mobile must be in for the shop to be effective. (So -trans’ed shopkeepers can’t sell in the desert). +trans’ed shopkeepers can’t sell in the desert). Time when open start 1 Time when open end 1 @@ -1900,4 +1901,4 @@ His Fullness increases by ((7/4)*1) hours His Thirst increases by ((7/4)*-2) hours, thus making him more thirsty. A player's drunkenness, fullness, and thirst can range from 0 to 24. 24 is the maximum; 0 means the person is completely sober, hungry, -or thirsty respectively. For immortals, these values are typically -1. \ No newline at end of file +or thirsty respectively. For immortals, these values are typically -1.