== = = Mortal Realms = = = = = = ==== ======= = = = = ========/== = = = === ========/==== ==== === = = === ===== = === = ===== ==== -. .- === = = === = = = == == == == / ==== == = === = = = === = == ======= === === = = ==== ===== = == == ====== = = == == -- == ==== == == ==== = === ===== == ======== ========= ====== ==== = === =======__--\ / --__ ===== ======= = == =_-\ \ /--__==== = = \ \ \ __-- \ --__ / / / \ \ \ _ - \ / --___ / / / \ //__-/ / \ |\ / . __ / /// \\\ \ -' . . . .. . . // . . . \ . . . . . ... . . . . . . . / . .. .. . . .. . \ . .. . . . . --. ... . . .. . . .. . . .|. . . . . . . .|. . .. ...... . . .. . . .. MrMud ver 1.2 ============================================== Hello future MrMud area creator! We (Chaos and me, Order) have put together this collection of documents as both references and instructions to building areas. Below is a list of the documents in the order which we recommend reading, along with a brief description of each. diku_bld.txt : the official handbook for creating DikuMUD areas as created by the Curious Area Workshop, it is included in the MrMud Area Package because it does a decent job of describing all of the basics of area building. This document has been modified to the MrMud configuration. mob_prog.txt : the instruction document that describes how to implement mob programs. This does NOT describe how to make special programs in C for mobiles, but details the functions and triggers used in programming mobiles from the area file. This is the only method of support that can be given to creators for making mobiles do special functions. mrmud.txt : the latest set of values used by MrMud. Updates to this document set will be contained in this file and the following file. spells.txt : the list of spells and the numbers necessary for specifying the spells in creating scrolls, wands, staffs, and pills. daycare.are : an example area, with an example mob_prog Have fun creating! Order, the God of Reason ============================================== Several utilities are included on in a different .tar file: mapmaker: Helps create the ROOMS sections map: Generates a map out of a .are file areacheck: Checks your .are syntax to exact MrMud v1.2 specs. draw: Creates pictures for displaying mobiles and objects. DOS only. Also various builder utilities may be located to help create areas, and can be found on various sites. These are generally not 100% compatible with MrMud, to the extent that they do not support all the features of MrMud. Use of these programs, such as dikued, may require some fixing to build your area, but these are generally minimal fixes. When selecting non-MrMud utilities, be sure to select Merc before Diku, or their derivatives. No other mud formats (lpmud, etc.) are compatible with MrMud. ============================================== FILE: "diku_bld.txt" The Builder's Handbook (version 1.0) By Builder_5 (of the Curious Area Workshop) (Modified by Chaos on 8/31/94) TABLE OF CONTENTS 1. Overview 2. Terminology 3. Basics 4. The #AREA, #HELPS, and #ROOMS section 5. The #MOBILES section 6. The #OBJECTS section 7. The #SHOPS section 8. The #RESETS section 9. Putting it all together 10. Credits 1. Overview This document is meant to be a basic tutorial to building areas for MrMud muds. Readers of this Handbook should have at least have some experience with MrMud's, and will understand the basic MrMud concepts of armor, levels, and the et cetera. Nowadays, many mud-admins express the wish to have an entirely unique world. Unfortunately, building is time consuming and requires no mean amount of skill, with the added 'bonus' of being hard to learn; the standard mud-docs that get bandied about are somewhat vague on certain subjects, and were originally intended as a reference guide rather than a learning document. I hope to make this Handbook a 'cookbook' of sorts -- an explanation of the how's and what's of building a MrMud based area for the non-coding inclined. This document is a tutorial for building in the standard MrMud release 1.2 . Most (95% or so) muds have changed or added to the information, but still follow the basic format. Reading this document should prepare you for most MrMuds you will encounter out on the net. The Curious Area Workshops highly recommends that every builder understand the nuts and bolts of building, even if they have access to one of the mud-area editors available out there. Being able to build with an editor is nice, but the knowledge of how the nuts and bolts of building actually works is extremely valuble when things go wrong. We cannot emphasize this enough, but we will attempt to refrain from preaching it in the rest of this document. 2. Terminology Here are some common terms used in builing, and this handbook: Desc: Short for 'description'. Db: Database. The files that make up the 'world' of a MrMud. Flag: A bit-vector that tells the mud that a particular monster, object, or room has a certain quality. (i.e. 'Dark', 'Magic', 'Aggressive') See FLAGS in section 3 -- Basics. Mob: Mobile. A monster. Ob/Obj: Object. Tilde: This is a tilde: ~ . It signifies the end of a line or a field in some of the database files. Vnum: An object, monster, or room's unique identification number. Stands for 'Virtual Number'. Zone: Used synonimously with 'area'. 3. Basics For all examples, the area under creation will be known as 'Handbook' or 'example area'. It is assumed that the builder has access to some standard type of text editor and knows how to use it. ** FILES For each area, one file must be created for inclusion into the dikumud's db: Handbook.are This file includes the various sections of: #AREA #MOBILES #OBJECTS #ROOMS #RESETS #SHOPS #HELPS ** FLAGS Simply put, a flag tells the mud that there is something 'special' about a mob, room, or object. In the sections below, lists of flags will be given with a number, a bitvector, next to it. For example, here is the list of room flags that will appear below in the #ROOMS section: ROOM_DARK 1 ROOM_NO_MOB 4 /* wandering mobiles can't enter the room */ ROOM_INDOORS 8 ROOM_PRIVATE 512 /* only two people at a time */ ROOM_SAFE 1024 /* can't do aggressive commands */ ROOM_SOLITARY 2048 /* only one person at a time */ ROOM_PET_SHOP 4096 /* place to buy pets */ ROOM_NO_RECALL 8192 ROOM_BLOCK 32768 /* room blocked from entrance */ ROOM_MORGUE 131072 /* shop in this room sells PC corpses */ (various other ROOM_ flags are described below) Now, for example, you are building a room. Deciding that this room is a small section of tunnel, you would choose the flags 'Dark' (1), and 'Indoors' (8). These numbers are the important part. When the mud looks at the .wld file, it looks for _one_ number in a certain particular spot for each room's flags. Therefore, to give one room _two_ flags, you ADD the bitvectors together and place that number in the flags spot of that room's data. Thus for this example, Indoors + Dark = 9. Another simple format can be each number separated by a '|' symbol. The '|' symbol is an logic 'or' symbol. Indoors + Dark = 1|8 The final format is to use the names of the flags in replace of the numbers. This system is MUCH easier to read, but may not be compatible with some of the mud-editors. Indoors + Dark = ROOM_INDOORS|ROOM_DARK How does this work, though? The bitvectors are in binary...the number you arrived at when you added can only be reached by one combination of adding those numbers together (you're not allowed to use a flag or number more than once). Thus, if your number was 522, you would know that it was 'Private' (the highest number that will go into 522) 'Indoors' (522-512=10. Indoors (8) is the next highest number that will go into that), and 'Death' (10-8=2, 2-2=0 -- no more flags). It should be obvious that the list is not complete. The blank spots are flags the are not used but exist for backward compatiblity. PLEASE do not use any of these. The game may use some of them for temporary values, and their use may jeopardize the system. ** Zone Number Each area must have its own unique number. Usually, the imp of your particular mud will assign this to you. This number is used as part of all your area's virtual numbers. (see below). The system that nearly all MrMud administrators like is the QQ format. This system places the symbols 'QQ' in replace of any zone number. The administrators will later assign a number in replace of the QQs. ** Virtual Numbers Every Mob, Obj, Room, and Shop must have its own Virtual Number for the mud to identify it with. Each number must be unique among its own type. For example, If I made the Sword of Cheezy Destruction, I may decide to make it item number 2200 of my zone. The first two digits are the zone number (above) of my area, the second two identify which item it is in that area. These first two numbers will be assigned by the system administrators. The first two numbers should be replaced by 'QQ'. Therefore the format you would write for the item number is QQ00. However, I can have a mobile with number 2200 as well. A room #2200 too. The number must be unique among all others of its type (rooms, obj's, mobs), but does not need to be unique in regards to other types of db's. MrMud systems do not allow using any object or mobile that does not solely exist in the zone of the creator, so all referenced objects or mobiles should start with the QQs. If your area has more than 100 rooms then continue using the 'QQ' method, but change the value to 'QR' for rooms 100-199, and 'QS' for rooms 200-299, etc... ** Strings A string the the actual data of the text sent to the player, such as a mobile's name, or a room description. Strings can range in size from zero length to the MAX_STRING_LENGTH. MrMud systems are 20,000 bytes allowed per string in a description, and 2,000 for names and short descriptions. All strings end in the tilde '~' symbol. Placing a return after the text, but before the tilde will display the return to the player. Putting extra returns in front of any text will be parsed out unless the '.' character is used. If the first character is a '.' then it is removed from the displayed text. Custom color may be added to certain strings. Room descriptions, mobiles descriptions, object descriptions, and extra descriptions may all have custom color. Adding color is as simple as adding a pair of matching brackets, with three digits between them. The three numbers are the parameters of the color change request. Format: '{abc}' with a, b, c being parameters. Parameter 'a': VT102 code. 0 - Dim 1 - Bold 3 - Restore color to text default regardless of the b/c parameters 4 - Reverse 5 - Underline 7 - Flashing (All VT102 systems support Dim, Bold, Restore, and Reverse) Parameter 'b': Foreground color Parameter 'c': Background color 0 - Black 1 - Red 2 - Green 3 - Yellow 4 - Blue 5 - Purple 6 - Cyan 7 - White Example: The small {130}dog{300} sits by the {440}cat.~ This example starts with normal colors. 'dog' is bold, yellow on black. The 'cat.' is reversed blue on black, which ends up being blue background, with black text. 4.1 The #AREA section The #AREA section has very few lines but sets up the entire file. The first line of the .are file must contain the statment: #AREA {<level range>} <creator name> <area name>~ example: #AREA {50 95} Desmond Mount Kolvir~ or #AREA {40 60} Presto The Isle of Mist~ ** Level Range This is a very arbitrary set of numbers that the creator must decide on. This field must contain exactly 5 characters between the brackets. ** Creator Name This field contains the creator name. There must be one space after the close bracket, and exactly seven characters, followed by a space. ** Area Name This field should be less than 15-20 letters. Anything larger will be terminated. Follow this with a '~' or tilde. *** Flags There are two other lines you may put after the #AREA line. These lines are actually area wide flags. #NODEBUG Use this flag if you have rooms that are non-standard. Usually this flag is not necessary. A non-standard room is one where when you leave room A north to room B. Then you leave room B south. While trying to get to A, you actually end up at room C. #AUTHORS <author character name list>~ This allows online area code changes for the specified authors. This only works for test games, and is not allowed in a REAL_GAME. #NOTELEPORT This does not allow a player to teleport or rift into the area. #RESTRICT <low level> <high level> This will restrict players from entering a room in the area based on the level range specified. The player's level must be within the values given. #TEMPERATURE <winter low> <summer low> <daily change> <wetness scale> This is the daily temperature scale in Fahrenheit. The winter and summer lows are for night temperature, with the daily adding to it. To reverse the seasons, simply switch out winter and summer temps. The 'Wetness Scale' is a number from 0 to 10. 0 is a desert. 10 is a tropical rain forest. 5 is the default value. Leaving this optional parameter off uses defualt settings for weather. 4.2 The #HELPS section This section allows the addition of new help listings. Entire help menus may be created. Begin this section with: #HELPS End this section with: 0 $~ *** Help Archetype <level> <name list>~ <text of help and special menu pointers> ~ example: 5 SWORD CUTLASS~ . The sword is a very strong weapon But you may find stronger ones. (A) Information on Knives (B) Information on Spoons (-) Back {a}knife {b}spoon {-}cuttlery ~ ** Level This is the level the player must be to be able to read this help. Use -1 if you wish everyone to read it. ** Name List This field is a list of keywords that will reference the help text. These may be odd encoded numbers for menu use only, or simple ones that the player may enter help on directly. This field should be in all capital letters. ** Body The body has several special encoded features. The first is that all initial spaces and returns are removed unless the body start with a '.' ** Menus The menu stucture shown above has two sections. The first section, where the options are surrounded by '(' and ')' is the display section. The display section is shown with the rest of the body text. The actual decoded menu section is a line that starts with '{'. Once a menu option is trapped, the following letter is the option that the user must pick, followed by '}'. The following letters are what the menu item will reference in the help system. These menu items may point to any other item in the help db. Please use only lower case letters for the menu system, since this feature is case sensitive, and most people select menus by lower case. 4.3 The #ROOMS section The #ROOMS section contains all the information necessary for the mud to make all the rooms of your area, link the exits together, and all the other little things concerned with the 'where's' of an area. The file simply consists of all the rooms in sequential order by their virtual number. Here is a sample room for this section's example: This section in the .are file will always start first with this line: #ROOMS This section in the .are file will always end with with this line: #0 *** ROOM ARCHETYPE (the <'s and >'s are used to offset values, and should be ignored) #QQvnum Room Title~ Room's Description ~ QQ <room flag> <sector type> D<direction number> exit description field ~ door keyword list~ <door type> <key vnum> QQ<exit-to-room vnum> <more exits here, if needed> E extra description keyword list~ extra description ~ S ---example follows this line--- #QQ00 The First Room~ You are standing in the first room of this area. Many rooms are sure to follow, soon to be chock-filled with adventure, danger, romance, and Giant Green Photosynthetic Death Gerbils from Morovia. There is a sign hanging from the east wall here, and a large steel grate bars the way to the north. ~ QQ 8 0 D0 You spot the Second Room to the north, behind a large steel grate. ~ grate steel~ 1 QQ00 QQ01 E sign~ The sign says: WELCOME TO THE FIRST ROOM! ~ S ---example precedes this line--- Now to explain what each part means, line by line: #QQ00 The virtual number of this room. Totally unique; no other room in the db will have this number after the adminstrators assign a value for the QQ. The First Room~ Short description: the 'title' of the room. This is typically not more than 5-6 words long. Note the tilde marking the end of this field. You are standing... ~ The long description of the room. This is what a player sees if he or she types 'look' in that room. What is in this section is up to your own, personal taste. More about the various description types can be found below. Note that a tilde follows on a line by itself. This is important, so that the mobs and obj in the room won't be jumbled all into one line. QQ 8 0 The first number is the zone number of this room; what zone should the mud consider this room to be in for game purposes. Please see 'zone numbers' in section 3 of this handbook. The second number is the room flag value. Please see 'flags' in section 3 of this handbook, and Room Flags below. The Third number is sector type. Please see 'sector types' below. D0 An exit to direction 0. The section on 'Exits' below will shed more light on this subject. You spot the Second Room ... Direction description; what a player would see if he/she typed 'look north'. Note the tilde on its own line afterwards. grate steel~ What words can be used to manipulate the door. These two words can be used in conjunction with open, close, pick, and look commands, etc. 1 QQ00 QQ01 The first number is the door value, 1 being open/close/pick/lock and unlockable. This and the other numbers will be explained more fully under 'Exits' below. The second number is the key number...the virtual number of the object that can be used to lock or unlock this door. The third number is the vnum of what room this exit leads to. E Tells the mud there is an extra description coming. sign~ The words that can be used to look at the extra description. (i.e. 'look sign') Note the tilde ending the field. The sign says:... The text of the extra description. Again, note the placement of the tilde on its own line. S End-of-Room character. Now, for more explanations... *** DESCRIPTIONS Descriptions are fairly self explanatory. However, the placement of tilde's are very important. *Short Desc's: The short desc is placed at the top of the room description, and can often be seen even if the player is in 'brief' mode. Simply put, this is the title of the room. Short Desc's should be kept to one line minimum...the shorter the better, in fact -- it should just be the shortest possible description of this room: 'A Dark Tunnel' 'The Bakery' 'Ms. Celande's Office'. A Short desc follows this format: Title of Room~ *Long Desc's: The long desc is the full description of the room, which a player will typically see when entering or by typing 'look'. When creating a long desc, please keep in mind to keep each line under 80 characters, and put the ending tilde on a line by itself. This section should be multi-line and complete. Clues to the Extra Desc's should be included in the room description, if not elsewhere. *Extra Desc's: An extra desc (of which there can be many for each room), is something else specific to look at, not normally seen just by typing look, or entering the room. An extra desc is started by an E (a seperate E for each extra desc in the room), followed by the keywords that can be used to look at this description on the next line, each separated by a space, followed by a tilde. Then, the description itself, followed by a tilde on its own line: E keywords~ You spot the keywords. They look important! ~ *** ROOM FLAGS Please consult the section on flags in section 3 for how bitvectors are added and used. Briefly, add each flag's corresponding values that you want for a particular room to find your room flag number. A zero signifies no flags. ROOM_DARK 1 ROOM_NO_MOB 4 /* wandering mobiles can't enter the room */ ROOM_INDOORS 8 ROOM_PRIVATE 512 /* only two people at a time */ ROOM_SAFE 1024 /* can't do aggressive commands */ ROOM_SOLITARY 2048 /* only one person at a time */ ROOM_PET_SHOP 4096 /* place to buy pets */ ROOM_NO_RECALL 8192 ROOM_BLOCK 32768 /* room blocked from entrance */ ROOM_MORGUE 131072 /* shop in this room sells PC corpses */ /* The following 2 groups are combinations of bits, so do not select a room for several classes of alignments */ ROOM_ALTAR_N 1572864 /* able to DEATH set for neutral players */ ROOM_ALTAR_C 524288 /* able to DEATH set for chaos followers */ ROOM_ALTAR_O 1048576 /* able to DEATH set fororder followers */ ROOM_ALLOW_ILL 2097152 /* The following rescrict all but 1 class */ ROOM_ALLOW_ELE 4194304 /* you may use ONLY one of these */ ROOM_ALLOW_ROG 6291456 /* Generally used to make practice halls */ ROOM_ALLOW_RAN 8388608 ROOM_ALLOW_NEC 10485760 ROOM_ALLOW_MON 12582912 ROOM_ALLOW_ASN 14680064 Ask your implementor about other flags that may be on your particular mud. These are complete for MrMud v1.2. *** SECTOR TYPES The 'sector type' of a room controls how many movement points it costs to enter that room. This is not a flag type item: choose one, and use the value... SECT_INSIDE 0 SECT_CITY 1 SECT_FIELD 2 SECT_FOREST 3 SECT_HILLS 4 SECT_MOUNTAIN 5 SECT_WATER_SWIM 6 SECT_WATER_NOSWIM 7 (Requires a boat) SECT_UNUSED 8 SECT_AIR 9 (Requires fly spell) SECT_DESERT 10 SECT_LAVA 11 (Causes some damage to stay in room) SECT_INN 12 (Heals the player while not on the game) SECT_ETHEREAL 13 (Requires Ethereal Travel spell) SECT_ASTRAL 14 (Requires Astral Projection spell) SECT_UNDERWATER 15 (Requires Breath water spell) *** EXITS Exits use the letter D and a number, compass, rather than the letter abbreviations that most mudders are used to for compass directions. Hence: (north) 0 4 (up) | / (west) 3-+-1 (east) + | / 2 5 (down) (south) DIR_NORTH 0 DIR_EAST 1 DIR_SOUTH 2 DIR_WEST 3 DIR_UP 4 DIR_DOWN 5 Thus, an exit D4 is an upward direction, while D2 would be to the south. Each exit starts with its own direction field, and contains a exit description and door keyword list (both of which can be left blank with a tilde), and a fourth line containing a door type, key number, and exit-to-room number. Rooms without exits need no direction fields and the etc...this section may be safely ignored. The exit description is used for when a player types look <direction>. This should in most cases be a vague description of what the next room might be, and is followed by a tilde on a line by itself. Each exit starts with its own direction field, and contains a door keyword list and The next field is the door keyword list, used for manipulative door actions, such as open, close, pick, etc. These words are separated by a space, and are followed by a tilde on the same line. The door type can be the following values: 0 /* Standard hallway without door */ EX_ISDOOR 1 EX_CLOSED 2 EX_LOCKED 4 /* Does not necessarily require a key */ EX_HIDDEN 8 /* cannot be seen w/o detect hid */ EX_PICKPROOF 32 /* only greater pick will open door */ The key number is simply the vnum of the key that can open the door. A door without a keyhole is represented by a -1 or 0 in this spot. The exit-to-room number is the vnum of the room where the exit leads to. Use the QQ system here. If the room connects to an outside room leave a ZZZZ here, with an extra description of where the room should connect. Please try to make as few outside connections as possible. Please note that adding a description for the door itself is usually done under the 'extra descriptions' part of the room db. *** Falls - For Air and Cliffs Rooms that characters may fall from have a section designated with the letter 'F'. This is followed by the room that they fall into, and the distance of the fall. F <room to fall into> <slope of cliff> <distance of fall in feet> This modifier for a room takes into play the skill of CLIMB and flying. The only special case is where the sector type is SECT_AIR. This special case will check to see if the character is flying, or immediately damage them. All other sector types are considered cliffs, and will check both dexterity and the climb skill. Flying does not affect any aspect of the non-air types of sectors, with the assumption that buffeting air would negative the effect of flying. The Rogue class has the climb ability that greatly increases the chance of safety for players in a cliff modified room. The only other modifier is dexterity. The longer a player stays on a cliff, the higher the likelyhood that they will fall. The slope of a cliff is defined as 0 for a slight incline, to 10 for a vertical cliff face. This number is ignored for SECT_AIR. When a player falls, two things happen. They are damaged by the amount defined by an equation based on how many feet the fall was. And they are transfered to the room pointed to by the "room to fall into" field. An area creator can use this to make a dangerous section for players to cross, such as a path up a mountain. This gives them a chance to fall back down the path. The SECT_AIR is quite dangerous, in that losing fly causes an instant fall. A trick that can be used to simulate a rocky terrain is to have a fall of a few feet, and make the fall room point to itself. *** TIPS and OBSERVATIONS *Map out the rooms on paper first. Be grandiose. As you build, it will usually get smaller anyways! *When making a DT (deathtrap -- a room with a death flag) make exits back to the rooms that lead to it...so people in those rooms can hear the scream. Likewise, it's usually not good to make a death room dark. It is also possible to create a room with no exits, and flagged as NO_RECALL. This will force the player to suicide. *For a working door, the rooms on each side must have matching doors and doorflags. Also the #RESETS section must have the associated close door commands. 5. The #MOBILES section The #MOBILES section contains everything the mud needs to know about the mobs, except for where they are and what they're holding. Each mob in the file is in sequential vnum order. Mobiles may also contain some form of mob_prog. These programs make the mobile appear more life-like, and can be used to set up puzzles or quests. Mob_progs should be used as often as possible. Mob_progs are described later in this text. This section in the .are file will always start first with this line: #MOBILES This section in the .are file will always end with with this line: #0 *** ARCHETYPE MOB (simple) #vnum Name list~ Short description~ Long description ~ Mob description ~ <action flags> <affection flags> <alignment> S <level> <body parts> <attack parts> <hitpoints> <damage> <gold> <race> <loading position> <default position> <gender> Here's a sample mob: ---example follows this line--- #QQ00 mob example~ the Example Mob~ An example mob stands here, completely clueless. ~ The example mob looks indistinct, as if it hasn't been completely fleshed out yet. ~ 131072|194|65536 8 100 S 1 4 16|8 1d6+2 1d4+0 10 2 7 7 0 ---example precedes this line--- The following is the same example with the ascii version of the flags. ---example follows this line--- #QQ00 mob example~ the Example Mob~ An example mob stands here, completely clueless. ~ The example mob looks indistinct, as if it hasn't been completely fleshed out yet. ~ ACT_RACE|ACT_WIMPY|ACT_STAY_AREA|ACT_SCAVENGER|ACT_BODY AFF_DETECT_INVIS 100 S 1 BODY_EYE BODY_TORSO|BODY_HIP 1d6+2 1d4+0 10 RACE_ELF POS_STANDING POS_STANDING SEX_NEUTRAL ---example precedes this line--- Now, to explain, line-by-line: #QQ00 The vnum of the mob. Read the section on Virtual Numbers in part 3 of this document for more information. mob example~ The namelist of this mob: what words can be used to interact with this mob. For instance, 'kill mob' or 'kill example' would both be valid for this mob. Note the tilde following the field. the Example Mob~ The short desc of the mob. Used in messages such as, "You poke the Example Mob." or "the Example Mob pounds you!" Note the tilde following the description. An example mob stands... ~ The long desc of the mob. Used as part of a room description when a player enters or looks in a room. Note the tilde on its own line after the description. The example mobs looks... ~ This is the description of the mob; what a player sees when typing 'look' at the mob. 194 8 100 S The first number is the ACTION flag of the mob, which tell the mud how the mob should act. The second number is the AFFECTION flag, which tells the mud about any special abilities the mob might have. Both these flag values work as per the section 'FLAGS' in part three of this handbook. See 'ACTION & AFFECTION FLAGS' below for more on both of these. The third number is the alignment of the mob, ranging from 1000 (good) to -1000 (evil). The 'S' stands for simple mob. This feature is not used in MrMud, and is left there as a placeholder. Always use an 'S' here. This feature is used for backward compatibility. 1 20 10 1d6+2 1d4+0 Field one is the mob's level. The second field is the body parts that can fall off when the mobile is killed. The third field is the body parts that attack. Field four is the mobs hit points. There is more on Hitpoints and damage below in the aptly named 'HITPOINTS and DAMAGE'. The fifth field is how much damage a mob does with its bare hands. 10 2 The first number is how much gold pieces this mob is carrying. The second field was used for exp on DIKU and Merc games, we ignore exp in files, and allow this field to define the race of the mobile if the action flags include ACT_RACE. 7 7 0 The first and second number are the mob's loading and default position, respectively. There is a section below: 'POSITIONS' that will explain more. The final number is the mob's gender; 0 is neuter, 1 is male, and 2 is female. *** DESCRIPTIONS Descriptions are done much the same way as those in the section in 'Rooms', earlier in this handbook. The reader is encouraged to go back and reread that section if necessary. However, the placement of tilde's is still very important. *Short Desc: the tilde must follow right after the description, on the same line. *Long Desc & Mob Desc: The tilde must follow on a line by itself. *** ACTION & AFFECTION FLAGS Action flags tell the mud how a mob behaves, and affection flags control the 'special qualities of a mob. These flags are added together in the way detailed in 'FLAGS', in part 3 of this handbook. Remeber that the flags can be referenced as the flag name itself. Below is a listing of flags for each type, with descriptions of what each does: Action Flags ------------------------ ACT_IS_NPC 1 /* Auto set for mobs*/ ACT_SENTINEL 2 /* Stays in one room*/ ACT_SCAVENGER 4 /* Picks up objects*/ ACT_AGGRESSIVE 32 /* Attacks PC's*/ ACT_STAY_AREA 64 /* Won't leave area*/ ACT_WIMPY 128 /* Flees when hurt*/ ACT_TRAIN 512 /* Can train PC's*/ ACT_PRACTICE 1024 /* Can practice PC's*/ ACT_WEAK 2048 /* Cannot carry anything*/ ACT_SMART 4096 /* Can say, normal can't*/ ACT_ONE_FIGHT 8192 /* Disapears after fight*/ ACT_NO_ORDER 16384 /* Cannot be ordered */ ACT_BODY 65536 /* Allows body parts to function. Should always be selected */ ACT_RACE 131072 /* Allows race to be defined and not random */ ACT_UNDEAD 262144 /* Does not create corpse on death for TURN spell */ Affection Flags ----------------------- AFF_INVISIBLE 2 The mobile is invisible. AFF_DETECT_INVIS 8 The mobile can see invisible players. AFF_SANCTUARY 128 The mobile is affected by the spell sanctuary. AFF_FAERIE_FIRE 256 The mobile is affected by the spell faeire fire. AFF_INFRARED 512 The mobile can see in the dark. AFF_UNDERSTAND 2048 The mobile can understand anyone. AFF_SNEAK 32768 The mobile is sneaking, players to not see it move. AFF_HIDE 65536 The mobile is hiding. AFF_FLYING 524288 The mobile is flying always. AFF_PASS_DOOR 1048576 The mobile can walk through locked doors. AFF_STEALTH 2097152 The mobile can hide and sneak continually. AFF_CLEAR 4194304 The mobile can walk through thick vegetation. AFF_HUNT 8388608 The mobile chases fleeing characters, if possible. AFF_TONGUES 16777216 Allows the mobiles to speak all languages. AFF_ETHEREAL 33554432 Makes the mobile absolutely invisible to system (Very good for mob_prog mobiles that shouldn't be seen or killed. Ex: allows doors to shut by themselves.) * Note: Please remember not to use any combination of values that will select a bit outside of those shown. Although combining valid bits are allowed. *** Simple/Complex The 'S' at the end of the affects field is a placeholder that is ignored by MrMud. It should always be an 'S'. Originally it was to select Simple or Complex mobiles in Diku muds. It is here to support backward compatibility. *** BODY PARTS This field was used by Thac0 on Merc and Diku muds, but is ignored on MrMud. Therefore it can be used by a different value. But you must give a flag to tell MrMud that this is a valid field. This flag is ACT_BODY, and should obviously go in the Action Flags field. If the ACT_BODY flag is not set, then body parts will be ignored. It is required that body parts be used on ALL mobiles, so this flag should always be set. Body parts are the parts that can be chopped off when the mobile dies. They will not show up elsewhere except in attack parts. Body parts might give a slightly different version than attack parts, as in BODY_MOUTH, which is a jaw bone in body parts, and a bite in attack parts. Any combination of body parts may be used, and it does not necessarily have to match the attack parts. Only one is selected when the body part is chopped off with a 25% chance that the body part will even fall off. It is not suggested to select two arms, as this will cause an error, only one is required. BODY_HEAD 1 BODY_MOUTH 2 BODY_EYE 4 BODY_TORSO 8 BODY_HIP 16 BODY_LEG 32 BODY_ARM 64 BODY_WING 128 BODY_TAIL 256 BODY_TENTICLE 512 BODY_HORN 1024 BODY_CLAW 2048 BODY_HAND 4096 BODY_FOOT 8192 *** ATTACK PARTS This field was originally AC on Diku and Merc muds. This field is normally ignored on MrMud, but with the ACT_BODY flag selected, the field becomes the attack parts of the mobile. Attack parts is how the mobile attacks. The different kinds of attacks from various body parts do not affect damage, as it only changes what is printed when the attack takes place. This feature is required, but is there to give the mobiles the correct forms of bare-hand attacks. Attack parts use the same field values as that of the body parts. Mobiles with weapons will always override the different kinds of body attacks. Note: AC, or Armor Class is computed by the game itself, and is dependant on the level of the mobile. If the mobile is should normally be wearing armor, the armor will add 2/3 of it's normal AC bonus. If the mobile is not weaing armor, and is normally supposed to be wearing armor, then the AC of the mobile is 1/3 of the value of the armor less than the normal AC for a mobile of the same level. *** HITPOINTS and DAMAGE The functions of hitpoints and damage are arrayed randomly by the mud, as a function of imaginary dice and bonuses. These always follow the form xdy+z, where x is the imaginary amount of dice, y is how many sides these dice have, and z is a constant being added to the final total. For example, our example mob had hitpoints of 1d6+2: a random number between 1 and 6, then add 2, for a range of 3-8. Another mob might have 10d10+150 for a range of 160-250. Damage is calculated the same way. These fields must follow the form xdy+z, even if z equals 0! For instance, our example mob does 1d4+0 damage with its bare hands... Leaving any of these fields blank will cause errors for the load procedure. One more important thing to know about damage: this is the mob's damage with its fists/claws/what-have-you. If the mobile is wielding a weapon, the mobile will do it's basic damage plus one-half of the damage of the weapon wielded. Standards and Measures These are the suggested strengths of mobs, as given in the original diku documentation... Level Hp. Damage Notes ----------------------------------------------------- 0 1-10 1d4+0 1 11-22 1d5+0 2 23-35 1d6+0 3 36-47 1d7+0 4 48-60 1d8+0 5 61-72 2d4+0 6 73-85 1d8+1 7 86-97 2d4+1 8 98-110 2d5+1 9 111-122 2d5+1 10 123-135 2d6+1 11 136-147 2d6+1 12 148-160 2d7+1 13 161-172 2d7+1 14 173-185 2d8+1 15 186-197 2d8+2 16 198-210 2d8+2 17 211-222 3d6+2 18 223-235 3d6+2 19 236-247 3d6+3 The following is a scaled chart of the stats of different high level mobiles. Please use this as a guide for creating mobiles. These are the default levels for higher level mobiles: Level Ave HP Ave Dam 15 250 20 20 350 22 25 475 24 30 600 27 35 680 30 40 790 33 45 900 37 50 1300 41 55 1650 45 60 2000 50 65 2800 55 70 3500 60 75 4200 66 80 5000 72 85 6200 78 90 7800 85 95 10000 92 These numbers are flexible. *** GOLD This is simply the amount of gold that the mobile is carrying when it is loaded. All mobiles can carry some amount of gold. *** RACE This field was previously used for exp for the mobile, but MrMud calculates exp based on the level of the mobile. This leaves the field open for more important things: Race. The creator must define the ACT_RACE bit in the action flags, and then use one of the RACE_ types in this field. This will fix the mobile as to what language it speaks and understands. It will also allow mobprogs to be used based on race. You must pick a race which is one of the basic eight, even if the mobile should be something outside of those defined. Just pick the closest one. *** POSITION A mob always has two position numbers: its loading position, and its default position. A mob will be loaded into its loading position initially, and after fighting, will return to its default position. Note that these do not have to be the same, but usually are. The valid positions are: POS_SLEEPING 4 POS_RESTING 5 POS_FIGHTING 6 POS_STANDING 7 There are a few more positions than these, but are not used except during fighting, which the mud takes care of automatically. *** GENDER This is the sex of the mobile, and has only three possible values: SEX_NEUTRAL 0 SEX_MALE 1 SEX_FEMALE 2 *** TIPS and OBSERVATIONS *Mobs wander around by default. Remember to include the 'Sentinel' Action flag for stationary mobs! *'Angry' mobs can be simulated by loading them sitting and agressive, with a default position of standing. After being attacked, they will wander around instead of sitting back down! Other interesting things can be done with the position values as well... 6. The #OBJECTS section An object is any item in the game, be it unmovable rock, the fountain in market square, or that nice sword Everyman the Barbarian has. Everything the mud needs to know about objects can be found in the #OBJECTS section, except for where they actually are. This section in the .are file will always start first with this line: #OBJECTS This section in the .are file will always end with with this line: #0 *** OBJECT ARCHETYPE #QQvnum namelist~ short desc~ long desc ~ description ~ <object type> <object flag> <wear flag> <object value0> <object value1> <object value2> <object value3> <weight> <value> <level> E keywords~ Extra desc ~ A <apply type> <apply amount> Here is an example object, followed by a line-by-line breakdown: ---example follows this line--- #QQ00 sword example~ an example sword~ An example sword lies on the ground, examping. ~ It looks very shiny and polished, as if someone is taking care to try to make a good example. ~ 5 64|16384 8193 0 3 1 10 5 1000 10 E example~ This is a rather boring example. ~ A 1 1 ---example precedes this line--- The following is the same object using the ascii flags system: ---example follows this line--- #QQ00 sword example~ an example sword~ An example sword lies on the ground, examping. ~ It looks very shiny and polished, as if someone is taking care to try to make a good example. ~ ITEM_TYPE_WEAPON ITEM_FLAG_MAGIC|ITEM_FLAG_LEVEL ITEM_WEAR_WIELD|ITEM_WEAR_WIELD 0 3 1 10 5 1000 10 E example~ This is a rather boring example. ~ A APPLY_STR 1 C whack~ FLAG_CLASS_RANGER|FLAG_CLASS_MONK ---example precedes this line--- Note: In the file, and amount of spaces or returns can separate different fields, so the extra return and spacing in the above example is valid. *** Field by Field Breakdown The following is a list of each of the fields of the Object format. *** Vnum #QQ00 This is identical to the method of the mobile vnum. This number may be the same as a room or mobile, but no other object may have this number. See the section on virtual numbers in Part 3 of this Handbook. *** Name list sword example~ The words can be used to manipulate the object. In this case, either of the words 'sword' or 'example' can be used in conjunction with a wield, drop, take, etc. This field requires a '~' or tilde at the end of the line. For use with mob_progs and obj_progs all names are appended with a special name starting with 'I' and followed by the vnum of the object. This is used to specifically point to a particular key, if the player has several keys. ex: item vnum is 9775, added keyword is 'I9775' *** Short description an example sword~ This is seen when the object is the target of a command: 'You wield an example sword.' 'You give an example sword to...'. This field requires a '~' or tilde at the end of the line. *** Long description An example sword lies on the ground, examping. ~ This is what a player sees if the object is lying in a room by itself. This field requires a '~' or tilde on it's own line. *** Description It looks very shiny and polished, as if someone is taking care to try to make a good example. ~ In MrMud, this field is used as the default "look" at the item, for example, if you did "look sword" while holding this item. Diku used this field for an action, and Merc ignored it. This field requires a '~' or tilde on it's own line. *** Object Type 5 This number is what type of object this is...a weapon. See 'OBJECT TYPES' below. *** OBJECT TYPES ITEM_TYPE_LIGHT 1 ITEM_TYPE_SCROLL 2 ITEM_TYPE_WAND 3 ITEM_TYPE_STAFF 4 ITEM_TYPE_WEAPON 5 ITEM_TYPE_TREASURE 8 ITEM_TYPE_ARMOR 9 ITEM_TYPE_POTION 10 ITEM_TYPE_FURNITURE 12 ITEM_TYPE_TRASH 13 ITEM_TYPE_CONTAINER 15 ITEM_TYPE_DRINK_CON 17 ITEM_TYPE_KEY 18 ITEM_TYPE_FOOD 19 ITEM_TYPE_MONEY 20 ITEM_TYPE_BOAT 22 ITEM_TYPE_FOUNTAIN 25 ITEM_TYPE_PILL 26 ITEM_TYPE_AMMO 30 *** Object Flags 64|16384 This determines what is affecting the object. Also note the ITEM_FLAG_LEVEL is required on MrMud. This is a flag that lets the field of the level work. If this flag is not set, the level field is ignored, and item level might be calculated incorrect. *** OBJECT FLAGS ITEM_FLAG_GLOW 1 ITEM_FLAG_HUM 2 ITEM_FLAG_DARK 4 ITEM_FLAG_LOCK 8 ITEM_FLAG_EVIL 16 ITEM_FLAG_INVIS 32 ITEM_FLAG_MAGIC 64 /* Cannot be enchanted, also set if any affects exist */ ITEM_FLAG_NODROP 128 ITEM_FLAG_ANTI_GOOD 512 ITEM_FLAG_ANTI_EVIL 1024 ITEM_FLAG_ANTI_NEUTRAL 2048 ITEM_FLAG_NOREMOVE 4096 ITEM_FLAG_INVENTORY 8192 /* This item will not be removed from player on death. This item will dissappear if the mobile is killed with it */ ITEM_FLAG_LEVEL 16384 /* Absolutely required on MrMud */ ITEM_FLAG_AUTO_ENGRAVE 65536 /* This item is engraved to first to get */ *** Wear Flags 8193 This flag tells the mud where the item can be worn on a player or mob. An object may be flagged to be worn is several places, such as a band that can go around the wrist and the waist. *** WEAR FLAGS ITEM_WEAR_TAKE 1 /* Required for the player to get object */ ITEM_WEAR_FINGER 2 ITEM_WEAR_NECK 4 ITEM_WEAR_BODY 8 ITEM_WEAR_HEAD 16 ITEM_WEAR_LEGS 32 ITEM_WEAR_FEET 64 ITEM_WEAR_HANDS 128 ITEM_WEAR_ARMS 256 ITEM_WEAR_SHIELD 512 ITEM_WEAR_ABOUT 1024 ITEM_WEAR_WAIST 2048 ITEM_WEAR_WRIST 4096 ITEM_WEAR_WIELD 8192 ITEM_WEAR_HOLD 16384 *** Object Values 0 3 1 10 These are the object's values. What each number means is completely dependant on what Type of object it is. *** OBJECT VALUES The four numbers consisting of the 'item values' are different for each type of item. Below the meanings of these numbers are broken down by each type. Zeroes refer to fields not used, while letters are explained for each section... (please note this is basically lifted verbatim from the dikudocs. Credits to the original author(s), and no disrespect intended.) ITEM_LIGHT (1) Value[0]: Not Used Value[1]: Not Used Value[2]: Number of hours the light can be used for. Zero hours means that the light has gone out. A negative number will create an eternal light source. Eternal lights should not be plentiful or easily obtained. Value[3]: Not Used ITEM_SCROLL (2) Value[0]: Level of the spell on the scroll. Value[1]: Which spell (see list in spells.txt) Value[2]: Which spell Value[3]: Which spell The values(1-3) are three (or less) different spells, mixed 'on' the scroll. Unused spells should be set to -1. ITEM_WAND (3) Value[0]: Level of spell in wand. Value[1]: Max Charges (1..X) Value[2]: Charges Left Value[3]: Which spell in wand (see list in spells.txt) ITEM_STAFF (4) Value[0]: Level of spell in staff. Value[1]: Max Charges (1..X) Value[2]: Charges Left Value[3]: Which spell in staff (see list in spells.txt) ITEM_WEAPON (5) Value[0]: Type of ammo shot by the weapon (0 if not a range weapon) Value[1]: Number of dice to roll for damage (keep this number low) Value[2]: Size of dice to roll for damage Value[3]: The weapon type. Type is one of: NAME NUMBER CATEGORY Message type ------------------------------------------------------------------------- WEAPON_SLICE 1 : Slice Slice/Slices WEAPON_STAB 2 : Stab Stab/Stabs (backstabbed, throw) WEAPON_SLASH 3 : Slash Slash/Slashes WEAPON_WHIP 4 : Whip Whip/Whips WEAPON_CLAW 5 : Claw Claw/Claws WEAPON_BLAST 6 : Blast Blast/Blasts WEAPON_POUND 7 : Pound Pound/Pounds (throw) WEAPON_CRUSH 8 : Crush Crush/Crushes (throw) WEAPON_GREP 9 : Grep Grep/Greps WEAPON_BITE 10 : Bite Bite/Bites WEAPON_PIERCE 11 : Pierce Pierce/Pierces (backstabbed, throw) To make a ranged weapon, you must also create ammo for it. A ranged weapon is defined by including the vnum of the ammo in Value[0] of the weapon. If a '0' is used here, it is not a shooting weapon. ITEM_TREASURE (8) Value[0]: - Value[1]: - Value[2]: - Value[3]: - ITEM_ARMOR (9) Value[0]: The effective AC. >0 enhances the armour class. <0 reduces the the armour class (cursed armour for example). Value[1]: - Value[2]: - Value[3]: - ITEM_POTION (10) Value[0]: Level of the spell in the potion. Value[1]: Which spell (Listed in spells.txt) Value[2]: Which spell Value[3]: Which spell The values(1-3) are three (or less) different spells, mixed in the potion. Unused spells should be set to -1. Eg. Value 0 : 30 (Level) Value 1 : 27 (Harm) Value 2 : 17 (Curse) Value 3 : -1 (no-spell) BTW: Don't drink this - It's bad for your health! ITEM_FURNITURE (12) Value[0]: - Value[1]: - Value[2]: - Value[3]: - ITEM_TRASH (13) Value[0]: - Value[1]: - Value[2]: - Value[3]: - ITEM_CONTAINER (15) Value[0]: Maximum weight the container can contain. Value[1]: Container flags: CONT_CLOSEABLE 1 CONT_PICKPROOF 2 CONT_CLOSED 4 CONT_LOCKED 8 Value[2]: The item-number of the object which can open the object. -1 means no lockability. Value[3]: - (always 0) ITEM_DRINKCON (17) Value[0]: Maximum drink-units the drink-container can contain. Value[1]: Number of drink-units that are left in the container. Value[2]: The type of liquid in the drink-container, one of: Drunkness Fullness Thirst LIQ_WATER 0 0 0 10 LIQ_BEER 1 3 2 5 LIQ_WINE 2 5 2 5 LIQ_ALE 3 2 2 5 LIQ_DARKALE 4 1 2 5 LIQ_WHISKY 5 6 1 4 LIQ_LEMONADE 6 0 1 8 LIQ_FIREBRT 7 10 0 0 LIQ_LOCALSPC 8 3 3 3 LIQ_SLIME 9 0 4 -8 LIQ_MILK 10 0 3 6 LIQ_TEA 11 0 1 6 LIQ_COFFE 12 0 1 6 LIQ_BLOOD 13 0 2 -1 LIQ_SALTWATER 14 0 1 -2 LIQ_COKE 15 0 1 5 The above values for drunkness/fullness/thirst are used per four "units" drunk. The values are expressed in HOURS! Example: Dragon empties a bottle (say 7 units) of saltwater. His Drunkness is not changed (7*0) His Fullness increases by (7*1) hours His Thirst increases by (7*-2) hours, thus making him More thirsty. The hours above are numbers between 0 and 24. 24 hours is maximum for drunkness/fullness/thirst. When hours are zero for any drunkness/fullness/thirst the person will be sober, hungry, or thirsty respectively. Value[3]: if this value is non-zero, then the drink is poisoned. NOT_POISONED 0 POISONED 1 ITEM_KEY (18) Value[0]: The key-type. This value must match the lock-type the door that the key can open (if the vnum of the key doesn't match the lock-type that is). Value[1]: - Value[2]: - Value[3]: - ITEM_FOOD (19) Value[0]: The number of hours, that this food will fill the stomach Value[1]: - Value[2]: - Value[3]: If this value is non-zero, the food is poisoned. NOT_POISONED 0 POISONED 1 ITEM_MONEY (20) Value[0]: The number of gold coins "in the pile of coins". Value[1]: - Value[2]: - Value[3]: - ITEM_BOAT (22) Value[0]: - Value[1]: - Value[2]: - Value[3]: - ITEM_FOUNTAIN (22) Value[0]: - Value[1]: - Value[2]: - Value[3]: - ITEM_PILL (22) Value[0]: Level of the spell in the potion. Value[1]: Which spell (Listed in spells.txt) Value[2]: Which spell Value[3]: Which spell ITEM_AMMO (22) Value[0]: Ammunition type (matches Value[0] of weapon that will shoot it) Value[1]: Damage (amount of damage caused by the ammo when it hits) Value[2]: Speed (4/second, keep numbers high (20 for fast arrows)) Value[3]: Effective range (it's possible to shoot it farther than the number given here, but at reduced damage. Please note that ranges greater than 5 are sensless because no one can see further than 5 rooms away) To create a ranged weapon with ammo, the weapon must also be created. This is done by adding the vnum of the ammo to Value[0] of the weapon. *** Object Weight 5 The weight of the object. *** Value 1000 The value of the object, in gold coins. *** Level 10 This is the level of the object. It is only valid if the ITEM_FLAG_LEVEL flag is valid. MrMud requires this field to be used. Level is calculated by the game otherwise, to support backward compatibily. *** Extra Descriptions E sword example~ This is a rather boring example. ~ This is an extra description, and behaves EXACTLY like the extra descriptions of rooms. The reader is referred to Part 4 of this Handbook for more information. *** Affects A 1 1 These are 'applies' of the weapon...the 'A' signifying that an apply is forthcoming. The second digit is the type of apply, and the third how much the apply is worth (either positive or negative). *** APPLIES An item apply is a particular effect the item has upon the holder/wielder/wearer's statistics. There can be a maximum of TWO applies on an item, each requiring their own 'A' flag to let the mud know that there is more than one apply. Thus, a sword that added one to a character's strength, and -10 to his hitpoints would be: A APPLY_STR 1 A APPLY_HIT -10 The first value is the type of apply, the second the value. Below is a list of the different types of applies, and their values. APPLY_NONE 0 APPLY_STR 1 APPLY_DEX 2 APPLY_INT 3 APPLY_WIS 4 APPLY_CON 5 APPLY_SEX 6 APPLY_MANA 12 APPLY_HIT 13 APPLY_MOVE 14 APPLY_AC 17 APPLY_HITROLL 18 APPLY_DAMROLL 19 APPLY_SAVING_BREATH 23 APPLY_SAVING_SPELL 24 *** Combat Usages C whack~ FLAG_CLASS_RANGER|FLAG_CLASS_MONK This is a system to change the default statement made when a weapon hits an opponent. It also allows you to specifically define which classes can use the weapon, even if that class cannot normally wield the type of weapon defined by weapon type. The creator should use the weapon type field (value 3) to set up weapons for backstabbing, shooting, throwing, etc. All npc's can wield the item if any class is defined. Class selection method will default to the normal method if no classes are selected (Put a '0' in the field). The weapon defined in the example will 'whack' the opponent, and can be wielded by rangers and monks. A weapon in the hands of a monk will disable their bonus for barehand. ** List of flags of classes FLAG_CLASS_ILLUSIONIST 1 FLAG_CLASS_ELEMENTALIST 2 FLAG_CLASS_ROGUE 4 FLAG_CLASS_RANGER 8 FLAG_CLASS_NECROMANCER 16 FLAG_CLASS_MONK 32 FLAG_CLASS_ASSASSIN 64 (Please note that FLAG_CLASS_ values are not the same as CLASS_ values) *** SPELL ID#'s Below is a chart (lifted from the original dikudocs, mostly) that gives the id# and usage of each spell... ID# POTION SCROLL WAND STAFF ARMOR 1 Y Y Y N TELEPORT 2 Y Y Y Y BLESS 3 Y Y Y N BLINDNESS 4 Y Y Y Y BURNING_HANDS 5 N N N N CALL_LIGHTNING 6 Y Y N Y CHARM_PERSON 7 N Y N Y CHILL_TOUCH 8 N N N N CLONE 9 Y Y Y N COLOUR_SPRAY 10 N Y Y N CONTROL_WEATHER 11 N N N N CREATE_FOOD 12 N Y N N CREATE_WATER 13 N N N N CURE_BLIND 14 Y N N Y CURE_CRITIC 15 Y N N Y CURE_LIGHT 16 Y N N Y CURSE 17 Y Y N Y DETECT_EVIL 18 Y N N Y DETECT_INVISIBLE 19 Y N N Y DETECT_MAGIC 20 Y N N Y DETECT_POISON 21 Y Y N N DISPEL_EVIL 22 Y Y Y Y EARTHQUAKE 23 N Y N Y ENCHANT_WEAPON 24 N Y N N ENERGY_DRAIN 25 Y Y Y Y FIREBALL 26 N Y Y N HARM 27 Y N N Y HEAL 28 Y N N Y INVISIBLE 29 Y Y Y Y LIGHTNING_BOLT 30 N Y Y N LOCATE_OBJECT 31 N N N N MAGIC_MISSILE 32 N Y Y N POISON 33 Y N N Y PROTECT_FROM_EVIL 34 Y Y Y Y REMOVE_CURSE 35 Y Y N Y SANCTUARY 36 Y Y N Y SHOCKING_GRASP 37 N N N N SLEEP 38 Y Y Y Y STRENGTH 39 Y Y N Y SUMMON 40 N N N N VENTRILOQUATE 41 N N N N WORD_OF_RECALL 42 Y Y Y Y REMOVE_POISON 43 Y N N Y SENCE_LIFE 44 Y N N Y IDENTIFY 53 N Y N N HASTE 613 ENHANCED REST 614 ENHANCED HEAL 615 ENHANCED REVIVE 616 ANIMATE DEAD 617 BANISH 618 ENHANCE OBJECT 619 MAGE SHIELD 620 DISPEL UNDEAD 621 DISPEL GOOD 622 REMOVE FEAR 623 FEAST 624 RESTORE 625 TREMOR 626 ENERGY SHIFT 627 INDUCTION 628 ILLUSION 629 MIRROR IMAGE 630 HALLUCINATE 631 STABILITY 632 ETHEREAL TRAVEL 633 ASTRAL PROJECTION 634 BREATH WATER 635 *** Object Programs Object programs are based on intercepting user commands, and substituting new ones with actions outside of normal game operation. Several programs may be included on each object. These programs, used in combination with mob_progs can lead to very complex systems of commands. Object programs can also trigger off of basic time increments, and damaging others, or getting damaged. They cannot trigger off of things that the player sees, or text on the screen. Trigger off things seen on the screen is limited to mob_progs, and will not be included in object programs, due to operational speed problems. Object programs start with a 'P' similar to object extra descriptions. Following the 'P' is a number describing the index value of the program, for branching operations to reference. An object will usually have a group of small 'programs' or execution units that do individual commands. There is always a 'Trigger' that will start the program, and a 'response' that does some form of action. The trigger need not be related to the response. This also means that the response does not know why it was triggered, and responses cannot be based on them. Ex: An object may not give back the same amount of hit points to the player if a damaged trigger was used, but it may give back some fixed amount, because it knows that the player was hit. In programs with the same index, execution of a command will start with the first one that gets triggered regardless of the index number. But the system will then flow through to any subsequent program with the same index number. This will allow the programs to do several routines on one trigger. ** IMPORTANT: Each program set must have a unique index number. Object programs basically follow the format of trigger followed by response. Each type of obj_prog trigger has a special format: Normal command intercept: P <reference number> TRIG_COMMAND <percentage> <game command> {responses} Percentage is the chance that the command will be intercepted. Game command is the command you wish to intercept. Unknown command intercept: P <reference number> TRIG_UNKNOWN <percentage> <unknown command> {responses} Unknown command is either a social command, or something new that would not be a normal command, such as "home" or "spit". Void trigger: P <reference number> TRIG_VOID {responses} This is generally used as the end effect of a branching response. Tick trigger: P <reference number> TRIG_TICK <percentage> {responses} This is triggered once every 4 seconds of real time. It can be used to make the player do things they did not intend to do. Or occasionally modify stats, or any other time based reaction. Hit trigger: P <reference number> TRIG_HIT <percentage> {responses} This trigger is called every time the player with the object is hit. This can be used to make objects that heal the player every time they are hit, or objects that scream whenever they are damaged. Damage trigger: P <reference number> TRIG_DAMAGE <percentage> {responses} This is called every time a player damages another character, either a mobile, or player. It can be used to create objects that say something or any other response to the damage given. ** RESPONSES Each type of obj_prog response has a special format. The only time a tilde is required is after a string is used. Commands such as OPROG_APPLY should not have a tilde after them. Screen Echo to user: {trigger} OPROG_ECHO <text to user> ~ These lines are given to the user only. Be sure to include the tilde. User command with multi-line, and no arguments: {trigger} OPROG_GOD_COMMAND <user command>&<user command>&< etc...> ~ These commands are given at the trust level of 99. This means that the user is able to perform god commands for the duration of the object program. Several commands may be used, and separated by the '&' symbol. The '$' symbol will be interpereted as the name of the player. This name is capitalized for use in communication. This can be very useful for setting quest bits on the player. Spaces may be required before and after the '$' symbol. Again do not forget the tilde. ** These commands can EASILY affect the entire game!!! Use with EXTREME caution. Here is a list of several of the commands that might be used: PURGE - Erases everything in the room. OLOAD <object num> - Loads a new object. MLOAD <mob num> - Loads a new mobile. GOTO <room num> - Transfers the character to that room. TRANSFER <name> <room num>- Transfers a mobile to the room. RECHO <text> - Echos the text to the room. EAT <object> - Eats (destroys) an object. SAVE - Will save the player. Also any of the mob_prog special commands may be used in the same format that they are listed in that section. (ex. 'MPGOTO 2755' ) Try to use only mob_prog commands where both exist, as the mob_prog ones do not display anything to the player, while the normal god commands will tell them what they are doing. It should be noticed that objects can use quest bits to their fullest by allowing objects to read and write both the object's and the player's quest bits. Example: OPROG_COMMAND mpmset $ long A small turtle named $. ~ This would set the description that others see when entering the room the player is in, very similar to the skill disguise. To reset the string to normal game operation, set the string to 'NULL'. User command with one command, and arguments: {trigger} OPROG_GOD_ARGUMENT <user command>~ This command allows the use of one command, but the inclusion of an argument. This allows special commands like GOTO to let the user pick a destination. It makes sure that the user cannot put any multi-line commands so they will be limited to the one command given. This is used to give the player the full advantage of the god command. Use this with the most EXTREME caution. And in most cases, only under permission of the game administrators. Character Apply Stats: {trigger} OPROG_APPLY <apply> <amount> This command is executed to change one of several stats of the player that has the current object. These will only affect the current stats, and never the maximum, as most other object affects to. It is allowed to make the amount either positive or negative. Apply types: OAPPLY_HIT - Applies to current hit points. OAPPLY_MOVE - Applies to current movement points. OAPPLY_MANA - Applies to current mana points. OAPPLY_ALIGNMENT - Applies to current alignment. Destroy the item with the program: {trigger} OPROG_JUNK This command will destoy the item that is executing the program. This is a much safer method that sacrifice, eating, or purging. If has object response: {trigger} OPROG_IF_HAS_OBJECT <object vnum> <true dest.> <false dest.> This command will branch successfully if the player has the object in either inventory or equipment, but not in a container. If check: {trigger} OPROG_IF <check variable> <symbol> <compare value> <true dest.> <false dest.> The IF check allows branching to other obj_progs. Check Variable: OIF_WEAR_LOC - wear location. (-1 if not worn) OIF_USER_CLASS - user class. OIF_USER_POSITION - user position. OIF_USER_GOLD - user gold. OIF_USER_ROOM_NUM - user room number. OIF_RANDOM_PERCENT - random percent. OIF_USER_WHICH_GOD - user follows which god. OIF_USER_ALIGNMENT - user alignment. OIF_USER_LEVEL - user level. OIF_USER_RACE - user race. OIF_USER_PERCENT_MOVE - user move percent. OIF_USER_PERCENT_HITPT - user hitpoints percent. OIF_USER_PERCENT_MANA - user mana percent. OIF_USER_AREA - The first room number of user's area. OIF_MCLASS_ILLUSIONIST - The amount of Ill levels. OIF_MCLASS_ELEMENTALIST- The amount of Ele levels. OIF_MCLASS_ROGUE - The amount of Rog levels. OIF_MCLASS_RANGER - The amount of Ran levels. OIF_MCLASS_NECROMANCER - The amount of Nec levels. OIF_MCLASS_ASSASSIN - The amount of Asn levels. OIF_MCLASS_MONK - The amount of Mon levels. OIF_TIME_OF_DAY - The hour of day in game time. OIF_WEATHER - The condition of the weather. ( 0=Clear, 1=Cloudy, 2=Raining, 3=Storm) OIF_ARMYSTATUS - Returns whether the player is in the Army. ( 0=Never Joined, 1=In Army, 2=Retired ) OIF_USER_SECTOR - The sector type the user is in. Symbol: '<' - Less than. '>' - Greater than. '=' - Equal to. '!' - Not equal to. Compare value is a number that the check variable is compared against. True destination is the obj_prog index (the one listed after the 'P') that the branch will continue when the if check is true. False destination is the obj_prog index that is executed when the if check is false. If the destination number is not found, then the branch will not be successful, and the program will stop. This can be used for branches that are not necessary to the operation of the program. Set quest bits on object: {trigger} OPROG_QUEST_SET <offset> <bits> <value> This is a method of setting the value on the quest bits of an object. The offset is the starting bit number of the grouped quest numbers. The bits are the amount of bits involved with the defined value. The value is the desired value of the set. Add value to quest bits on object: {trigger} OPROG_QUEST_ADD <offset> <bits> <value> This is a method of adding a value to the quest bits of an object. The offset is the starting bit number of the grouped quest numbers. The bits are the amount of bits involved with the defined value. The value is the desired increment being added to the quest bits. The number inside the defined bit range will never overflow to higher bits, or go below zero. The value may be negative to subtract. This can be used to make items that have limited lifespan. Quest bit if check both player and object: {trigger} OPROG_PLAYER_QUEST_IF <offset> <bits> <symbol> <compare value> <true dest.> <false dest.> {trigger} OPROG_OBJECT_QUEST_IF <offset> <bits> <symbol> <compare value> <true dest.> <false dest.> The quest if check allows branching to other obj_progs. The offset is the starting bit number of the grouped quest numbers. The bits are the amount of bits involved with the defined value. Symbol: '<' - Less than. '>' - Greater than. '=' - Equal to. '!' - Not equal to. Compare value is a number that the check variable is compared against. True destination is the program index (the one listed after the 'P') that the branch will continue when the if check is true. False destination is the obj_prog index that is executed when the if check is false. If the destination number is not found, then the branch will not be successful, and the program will stop. This can be used for branches that are not necessary to the operation of the program. It is not necessary to add a 'return' after compare, everything can be placed on one line. ** Example Programs: P 2 TRIG_COMMAND 45 say OPROG_ECHO You are occasionally tongue tied. ~ P 3 TRIG_UNKNOWN 100 home OPROG_IF OIF_WEAR_LOC ! WEAR_NONE 4 0 ~ P 4 TRIG_VOID OPROG_GOD_COMMAND goto 9755&say I'm home! ~ P 5 TRIG_UNKNOWN 100 goto OPROG_GOD_ARGUMENT goto~ Explanation: The first section of the program is a simple command trigger to screen echo. 45% of the time that the user tries to use the 'say' command, it will not be functional, and the user will see the response that he is tongue tied. The rest of the program checks when the user types the unknown command 'home'. If that is typed, then the If Check checks for the wear location of the object. If the wear location is not WEAR_NONE (if the item is worn), then the command continues with program 4. If the item is not worn, then the program will stop execution. The next program has a void trigger, and can only be reached by the previous branch statement. The user is forced to 'goto', a god command, the location of 9755, which is in the city of Chakkor. Then the user is forced to say 'I'm home!'. The final program allows the player to use the god command GOTO at any time the exact same method that a god would. Obviously this is a bit much power for a normal player, and is suggested only to allow demi-gods with these commands. Notes on obj_progs: It can easily be seen that there is a very large amount of room for improvement on object_programs of this type. This system has been set up because obj_programs are searched MANY more times than mob_progs, and require a significantly longer amount of CPU time to process than mob_progs. Therefore a tokenized method was developed instead of the interpreted system of the mob_progs. Essentially the format in the .are file is the same that the database system saves all the information. Using this tokenized system is at least 4 times faster for the CPU than an interpreted based system. More complex object programs can be realized by asking the MrMud implementors to add new types of triggers and responses. This system is relatively new, and has not been fully tested for CPU usage, but early tests show that the response time is such that 50 people having 20 items with complex programs each, should not noticeably degrade system performance. For the sake of safety, both the commands of 'save' and 'quit' are removed from those allowed in obj_prog responses. Be very careful with using the god commands, as they can permanently change the statistics of players, rooms, and just about anything in the game. ** Important: Do not create a situation where the object with the program is deleted, unless the program terminates with the command that deletes it. Otherwise the entire game will crash. It is allowable to delete the item as a final command. The JUNK command will always automatically terminate object programs, regardless if the object program continues. QUEST BITS: This is generally a very complex system to initially understand, therefore The following is a detailed description of how quest bits work. Quest bits are used in 3 places. Each player has a set of quest bits for each area, so that a player may be on several quests, and each area has it's own set, without worrying about other areas. Each mobile has one set of quest bits. Each item has one set of quest bits. It should generally be considered that you should not allow modifications of quest bits by an something from one area to another. As each set of quest bits are defined completely by the area creator. Quest bits are used to allow the area creator the ability to define their own set of variables that are constant for that individual, object, or mobile. This means that once the value is set, it is saved throughout the game, and allows various states, or steps in a quest to be marked. The definition of a quest is the ability of the game to know how far a player has gotten in an area regardless if they come back to the game several days later. Each set of quest bits is really a set of user definable 32 bits, or one long-integer. Some knowledge of binary numbers helps in decifering this system completely, but is not necessary. The offset is always the starting point of where the defined value is. The amount of bits defines the totaly range of the values used. With basic binary system, the amount of bits define an exponential range: 1 bit - 2 values 2 - 4 3 - 8 4 - 16 5 - 32 6 - 64 7 - 128 8 - 256 Ex. Say a creator wants to have 4 states on an object. The first being the initial state, the second when a player hits a mobile, the third when the player goes to sleep, and the fourth when he wakes up. The area creator wants an object that poisons the player when he attacks a mobile, and damages them when the player wakes up. The player is even informed that when he wakes up next, he will be hurting very bad. Since there are only 4 states, only 2 bits are required. And the offset is defined by what other bits are used for other things. Maybe the first 5 bits are used as a count-down every 4 seconds after the player wakes up and when it reaches 0, the player is finally damaged. This means that the object will delay a total of 128 seconds of real time before it does the damage. This means that the 4 states must have an offset of 5 since the first five bits are used for a timer. The final check will see if the state is at state 3 (really the fourth state, since numbers start at zero) and the timer is at zero. This is when the player is hurt, and the item is junked. Here is a picture of what was just explained: 30 28 26 24 22 20 18 16 14 12 10 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ("X" indicates an unused bit) \_/ \_______/ | | 2 bits for 4 states, starting @ bit 5 and 2 bits long' | 5 bits for the timer, starting @ bit 0 and is 5 bits long' As can be seen, there is a lot that can be done with quest bits. Given that it may be confusing as to their use at first, quest bits allow the objects, mobiles, and players to do things that are otherwise impossible, because the game does not normally record what a player is doing, and where they have been. Each reset normally sets the game in a default condition for everyone, but with quest bits, the game can be different for everyone, depending on what they have previously done. This may allow a mobile to get to know a player, or an object to find a master. *** DISPLAY This is a system to display a near full screen color bitmap of an object or mobile. In both cases the section works similar to an object's affects, in that the bitmap definition section is started with a letter, followed by the actual information. Displayable bitmaps start with a 'D' in both objects and mobiles. In objects, they may be place anywhere after the initial format information. On mobiles, they must be placed immediately after the normal numbers, but before any mob_progs. Bitmaps are defined in the area file by numbers 0 to 7 in a 78 by 40 arrangement. The numbers on each pixel is the color defined. In the utilities file there is a DOS utility that allows the generation of one bitmap at a time. The system must have ANSI.SYS loaded when using DRAW. The creator will generate each bitmap in a separate file that can be immediately inserted into the area file. The DRAW program saves it's bitmaps in the same format that the area files read them. There is also a more advanced drawing program called mobdraw. This program utilizes a mouse, and draws in graphics mode, hence does not require the ansi.sys to be loaded. It should be very obvious that these bitmaps are very blocky, but it can also be assured that all terminal programs running ANSI color can display them. *** TIPS and OBSERVATIONS *Items with applies to stats over +3 should be very rare on most muds, and hard to get. *A lot of small items make an area more interesting than a few incredibly powerful items, for the most part. This is very subjective, however. Items that are too powerful may be changed by the game administrators, which usually annoys the administrator more. %^) *Remember to put take wear-flags on almost everything. It's easier to put a take wear-flag on everything, and take off the ones you don't need (like fountains and such). *don't feel limited to items players consider 'useful', such as weapons and armor. A giant (untakeable) monolith, and other strange and odd items can add a lot of atmosphere to an area. *The ITEM_FLAG_INVENTORY has very special purposes and should not be used for normal items. All basic shops items that are flagged as inventory. An object that is flagged as inventory will follow the player, even in death. A mobile that is killed with an object that has an inventory type item will automatically delete the item. This is useful for creating objects that the player desires, but cannot get. An object with this flag can be given to the player by a mobile with mob_progs, or picked up off the ground. 7. The #SHOPS section The #SHOPS section tells the mud each shop the kind of items it deals in. It also tells the profit margins, and the hours open. Usually all the numbers are on one line. ** Shop Archetype <Mob vnum> <type 1> <type 2> <type 3> <type 4> <type 5> <%sell> <%buy> <hour open> <hour close> ** Mob Vnum This is the mobile that works in the shop. ** Type These five values are the ITEM_TYPE numbers that the shop deals in. The shop will only buy or sell these types of items. Leaving a '0' in any of the slots will allow the shop to deal in less than five types of items, but a shop may never deal in more than five. ** %Sell This is the percent of the normal value of an object when the shopkeeper sells it to a player. Usually around 100. This number is limited by the system. ** %Buy This is the percent of the normal value of an object when the shopkeeper buys it from a player. Usually around 80. This number is also limited by the system. It was possible to create areas in Merc and Diku where things could be bought for less that what you could sell it for. This makes for free gold. ** Hour Open This field is a number from 0 to 23 that is the hour that the shop opens. ** Hour Close This field is a number from 0 to 23 that is the hour that the shop opens. *Note: Comments may be added after the Hour Closed following a ';'. The comments can only be as long as the screen length. *Note: Shops on MrMud can be browsed through during off hours, but nothing can be bought there. All shops are considered safe rooms at all times, even in off hours. 8. The #RESETS section The #RESETS section tells the mud where everything goes, from the goblin in the pit to what the knight is wielding and putting the fountain in the square. This section is simple a list of commands. The zone commands tell the mud exactly how to reset a zone, from mobs to objects, to closing doors. Each command is given its own line, one after the other, until the end of the file. Comments can be added for clarity's sake (like this: /* big guy with sword */). Areas reset based on the average of all the levels of the mobiles in the area. Low level areas take about 10 minutes to reset, and high level areas take about 45 minutes. This number is fixed and continuous regardless of how many players are in the area. *Standard Fields: <if-flag> An if flag tells the mud to look at the previous command. If the if-flag is 0, the mud will try to execute the command regardless of the previous command. If the if-flag is any other than a zero (one is most commonly used), then that particular command will only execute if the command immediately preceding it did as well. This is useful for objects loaded onto mobs; you don't want to load a shield on a guard that didn't get loaded, for example. There are several other uses as well, that should become apparent as you build... <max #> This is the maximum number of whatever this is can exist in the mud. If on a mob command, this will prevent excess mobs being loaded into an area. On an object command, this limits how many of this object are available in the game. For items not limited, it is common to put a very high number in this slot... from 100 to 1000. ** List of all Commands M <if-flag> <mob vnum> <max #> <room vnum> O <if-flag> <object vnum> <max #> <room vnum> G <if-flag> <object vnum> <max #> E <if-flag> <object vnum> <max #> <equipment position> P <if-flag> <loaded object vnum> <max #> <container vnum> D <if-flag> <room vnum> <exit #> <doorstate> R <if-flag> <room vnum> <last exit to randomize> *The 'M' Command The 'M' reset command loads a mobiles to a certain place in the mud. The format is: M <if-flag> <mob vnum> <max #> <room vnum> *The 'O' Command The 'O' reset command loads an object into a room. This is mostly used for unowned or immovable objects (like a stick on the ground or a fountain). O <if-flag> <object vnum> <max #> <room vnum> To make a unique item the <max #> should be 1. Generally this means that the object will not load if any others exist in the game. There is a basic 20% chance that the object will load anyways when the area resets. *The 'G' Command The 'G' reset command loads an object and gives it to a mobile loaded in the command immediately previous. Note that this is different from the 'E' command below, in that the 'E'command loads an object and makes the mob equip it. A 'G' command object stays in the mob's inventory. G <if-flag> <object vnum> <max #> To make a unique item the <max #> should be 1. Generally this means that the object will not load if any others exist in the game. There is a basic 20% chance that the object will load anyways when the mobile resets. A mobile will reset after it is killed on the next area reset. *The 'E' Command The 'E' reset command loads an object and makes the mob loaded in the command immediately previous to this one equip it. E <if-flag> <object vnum> <max #> <equipment position> Where equipment position is _one_ of the following: 0 Light 1 Right Finger 2 Left Finger 3 Neck (first slot) 4 Neck (second slot) 5 Body 6 Head 7 Legs 8 Feet 9 Hands 10 Arms 11 Shield 12 About Body 13 Waist 14 Right Wrist 15 Left Wrist 16 Wield 17 Hold To make a unique item the <max #> should be 1. Generally this means that the object will not load if any others exist in the game. There is a basic 20% chance that the object will load anyways when the mobile resets. A mobile will reset after it is killed on the next area reset. *The 'P' Command The 'P' command loads an object, and places it into another object (container-type) that was previously loaded. P <if-flag> <loaded object vnum> <max #> <container vnum> *The 'D' Command The 'D' command can open, close, or close and lock a door. D <if-flag> <room vnum> <exit #> <doorstate> Where exit # is the _number_ equivalent of the exit as so: (north) 0 4 (up) | / (west) 3-+-1 (east) + | / 2 5 (down) (south) And Door state is: 0 Open 1 Closed 2 Closed and Locked. *The 'R' Command The 'R' command randomizes the specified exits in a room. R <if-flag> <room vnum> <last exit to randomize> Where <last exit to randomize> is the number equivalent of the first exit in the room to not randomize. For example: R 0 6495 3 would randomize the north(0), east(1), and south(2) doors of the room with the vnum 6495. Swapping only those three exits. ***TIPS and OBSERVATIONS *Remember, a functioning door is a door from both sides, and needs to be closed from both sides. Thus, 2 door commands for each door. *The 'P' command gets confused if you try to load multiple objects into multiple containers IF the containers are all the same object. The solution is to copy the container over into the #OBJECTS section with a different vnum however many different containers you need. 9. Putting it all together. This section is simply composed of building tips for novice builders. This is very subjective, and based on the experiences of the builders at the Curious Area Workshop. Not all these techniques may be of use to your average builder. *Absolutely, positively use the AREACHECK utility. The areacheck utility comes with the utilites section of documents that goes along with this document. The areacheck will normally allow the area to start right up unless you have doors specified wrong, or have problems with obj_progs or mob_progs. Areacheck does a VERY good job of checking syntax, such as numbers that are off or spacing that is wrong. It also checks the syntax or spelling of all the text versions of flags. *Learn to build without an area editor first. -Its a lot easier to troubleshoot when you understand what exactly goes on with all those numbers in those files... This is very important because most area editors are designed for Merc or Diku areas. They are actually fine for making a framework for the area, but realize that MANY differences crop up in creating MrMud areas. And the creator must then use a text editor to finish out the area. *Do it on paper first. Do it big. -Areas always seem to shrink while you're building it, from a cross of aggravation and editing. Having a map to work from helps a LOT when doing exits, and provides a visual impetus to getting all those tedious bits done. *Do the #ROOMS section first. -The #ROOMS section almost always takes the longest. Once past that long fight, the #MOBILES and the rest will come easier. *Save Mobile programs and Object programs till the very end. It is simpler to create obj_progs and mob_progs when all the mobiles and objects are in place, and the rooms are finished. *Your #RESETS file will always be wrong on the first try. -Get used to it. *For random mob distribution, use this method: -(this was contributed by Locke of CthulhuMUD) Make a room, with exits to all the places that you would like mobs to come out of, in all 6 directions. Load all mobs to be randomly distributed in this room, and they'll choose and walk out themselves! (if they're not sentinel). For a big area, several of these 'mob chutes' can be connected for a bubble-sort effect. *An area will take twice as long as you think it will to build. -a certain boredom sets in sometimes. just set it aside for awhile if this happens; its better to build when you want to then turn out something uninspired. If you plan on using obj_progs or mob_progs then the area will take four times as long as you expect. If you plan on using quest bits, then count of it taking much longer than you expect, with several errors. This does not mean that you should not add mob_progs. Mob_progs should be manditory for every mobile, but they do take a bit of puzzling thought to work out correctly. Object programs are even more confusing, but add an extra dimension to the game. *Be fair with the items: -Good items should be hard to get. Lousy items should require much less effort. Give the most powerful items actually _to_ a mob; theives and mages can often steal stuff on the ground without even bothering with the mob. Always remember that items and objects can easily get out of scale, and all areas can and probably will be modified by the implementors of a MrMud system. This is to be expected, so don't get too put out. Contributions to this section are welcome, and will be added with proper credits. 10. Credits Special Thanks to Tarkin of NaVieMUD and MJPrime of AlbertMUD for invaluble help in writing this Handbook. Extra Special Thanks to all the Players of NaVie (128.213.5.14 4001), for all the help during the Buggies & Bounties competitions. Builder_5 11/11/93 ftp.cs.odu.edu \pub\caw Modifications for MrMud v1.2 written on (incredibly) 11/11/94 David Bills (Chaos on Mortal Realms - hydrogen.ee.utulsa.edu 4321) Doug Michael (Order on Mortal Realms - hydrogen.ee.utulsa.edu 4321) ============================================== FILE: "mob_prog.txt" === MOBprograms MOBprograms are a way to make your mobiles more interesting. This basic version has enough to get things going, and should be quite readable and understandable and more to the point, extendable. The remainder of this document describes MOBprograms and gives a couple trivial examples. Table of Contents: The Basic Idea MOBprogram Syntax Associating MOBprograms With A Mobile Trigger Types Variables Control Flow Syntax Operators If_Checks In Control Flow MOBcommands Of Interest Regarding CPU Slowdown Miscellaneous Information Credits -----------------------------The Basic Idea--------------------------------- Ever wonder why most muds either seem dead or overcrowded? The answer is probably partially due to the fact that the mobiles never do anything but wait to be slaughtered. Unless someone has gone to great lengths and added many special procedures, most mobiles have no idea you are in the room with them and rarely listen to what you say. The typical Midgaard mayor wanders happily along even when the populace pokes him, waves his City Key about, unlocks his gates, or frenchs his secretary, etc. So a way to give the mobiles a bit more spirit would be neat. Enter the MOBprograms. The backbone of the MOBprograms shall be called triggers from this point on. Essentially, they are procedure calls placed in sneaky places in the mud code which provide the context for what is going on around the mobile. So, if something happens in the mobile's room and a trigger is activated, then a list of commands is sent to the interpreter in the mobile's name, thus making her/it/him do an appropriate something. Since knowing the appropriate response for every mobile to every possible trigger is not easy, this command list shouldnt be a rigid script, but needs to be somehow unique for the mobile and the situation. However, in order to know the situation, a mobile needs to know more about the trigger than that it just happened. So, we have to include some sort of variables as well to set the context appropriately. As most implementors know, most area creators are not versed in coding, but usually have great ideas. Therefore, whatever system is used needs to be quite simple. This is not to demean creators in anyway. Simply, it is useless to have a powerful system, if the only person able to write anything is someone who finds C coding in general to be exciting and non frustrating. If that is going to be the case, then stick to the special procedures, since there is no bound to what a complex special procedure can accomplish. Yet, from experience working on several muds, most admins and implementors prefer not to be writing one shot spec_procs to satisfy the needs of their creators. Thus, the basic idea: let mobiles react to a myriad of mud events/situations by having them perform a list of commands which can be tailored to the moment through a simple and unintimidating scheme usable by any creator. ----------------------------MOBprogram Syntax-------------------------------- The simplest way to describe any syntax is by example, so here goes. First, define the notation: anything contained in braces {} is required, anything in brackets [] is optional, anything in quotes "" is a case insensitive literal, NL refers to a required new-line. The meanings of the labels used will be described following the syntax diagram. ">" {trigger_type} " " {argument_list} "~" NL {program_command_1} NL {program_command_2} NL {program_command_3} NL . . . {program_command_N} NL "~" NL -- Explainations A TRIGGER_TYPE is one of the available triggers. A PROGRAM_COMMAND can be any legal mud command, or a control flow command. The ARGUMENT_LIST depends upon the trigger, but it is always parsed into the system as a character string. This is an example of ONE MOBProgram block for a mob. -------------------Associating MOBprograms With A Mobile-------------------- There is only one way for the mud to associate the program with the mobile. The result is a link list of mob_programs which are attached to the mobile_prototype. This is done at boot time, and so only one copy is kept, regardless of how many instances of the mobile are running about. In the #MOBILES section of your area files, at the end of the mobile's block (i.e. on the line following the typical position/default position/sex line), append any number of MOBprograms blocks (using the syntax above) followed by a line starting with one '|' (pipe). Example provided: Example.are -----------------------------Trigger Types---------------------------------- Triggers are fairly easy to add, but this basic list should hold for most needs. Their names, argument list syntaxes, and translation into more articulate english are given below: Syntax: act_prog [p] <ARGUMENT> The argument is a list of keywords separated by spaces. If the first word is the character 'p' by itself then the rest of the word list is considered to be a phrase. The trigger is activated whenver a keyword (or the phrase) is contained in the act() message. Both the phrase and keywords are case insensitive. NOTE: Most general trigger. Applies to almost every event which happens in the mud. Anytime the function act() is called with a message to be delivered TO_CHAR,TO_VICT,TO_ROOM,etc. the act can be triggered. Basically this will trigger on almost everything you'll ever want (and some things you wont as well) For example: MOBprogram: >act_prog p pokes you in the ribs.~ This trigger will only be activated if a mobile receives a message in which the above five words are found in the exact order and spacing given. Note that the period is needed because the words must be found on their own. This eliminates confusion when the keyword is 'hi' and a message with the word 'this' is being checked. Syntax: speech_prog <ARGUMENT> The argument is the same as for an act_prog. This works best when only one word is used as the argument, as several can cause the mob_prog to trigger several times in a row. ex: >speech_prog the dog~ The previous example is faulty, because it would trigger twice if the player said the words 'the' and 'dog' in the same sentence. correct ex: >speech_prog dog~ NOTE: This is only triggered when the keyword is contained in a message which has been said by a PC in the same room as the mob. The PC restriction is not necessary, but makes infinite loops between two talking mobiles impossible. It also makes it impossible for two NPC's to stand and discuss the weather however. NOTE: A ">speech_prog ~" will trigger on any speech. Syntax: rand_prog <NUMBER> The argument is a number betweeen 1 and 100 inclusive. NOTE: This trigger is checked at each PULSE_MOBILE and if the argument is greater than a percentage roll the trigger is activated. This will happen even if there is no PC in the room with the mob, but there must be players in the same area. It is useful to give mobiles a bit of a personality. For instance a janitor who stops to spit tobacco, or complain about the hours, or wonder why there are no woman janitors on muds, or a fido which barks or growls or pees on the curb is much more alive than one which just sits there scavenging. Syntax: fight_prog <NUMBER> The argument is a percentage like in rand_prog. NOTE: Useful for giving mobiles combat attitude. It is checked every PULSE_VIOLENCE when the mobile is fighting. Can be used to cast spells, curse at the opponent, or whatever. Only the first successful one will be processed to save time. Also, this means that the mobile wont get lucky and 1. curse, cast a fireball and 2. spit on the player, cast another fireball in the same pulse. Syntax: hitprcnt_prog <NUMBER> The argument is a percentage. NOTE: Is activated at each PULSE_VIOLENCE when the mobile is fighting. It checks to see if the hitpoints of the mobile are below the given percentage. Multiple hitprcnt_progs should be listed in increasing order of percent since a 40% will always be activated before a 20% and, only the first successful hitprcnt trigger is performed. Syntax: greet_prog <NUMBER> Again a percentage argument. NOTE: Whenever someone enters the room with the mobile, and the mobile saw the person enter, this is checked. Good for shopkeepers who want to welcome customers, or for pseudo-aggressive mobiles which need to discriminate on who they attack. Syntax: all_greet_prog <NUMBER> Again a percentage argument. NOTE: Like greet_prog, but it can be triggered even if the mobile didnt see the arrival (i.e. sneak, invis, etc). Most useful for faking teleport rooms (if your mobiles can transfer) or for impassable guardians. **NOTE: neither greet_prog is activated if the mobile is fighting.** Syntax: entry_prog <NUMBER> Again a percentage argument. NOTE: The opposite of a greet_prog. Whenver the mobile itself enters a new room, this can be triggered. Useful for looking around, or waving or other things that real PCs do when they arrive at a crowded room. Only the first successful one of these is done so the mobile doesnt look stupid by repeating commands resulting from multiple MOBprograms. Syntax: give_prog <ARGUMENT> This command should always be used with the 'I' format for item vnums. example: A scroll of recall is vnum 9775, so use 'I9775' for the argument. NOTE: This is triggered whenever something is given to the mobile. Best used for quests. Syntax: bribe_prog <NUMBER> The argument is any positive integer number. NOTE: This trigger is activated whenever money is given to the mobile. If the amount given exceeds the number, then process the commands. Note again, that an argument of '1' would act as a default response. If money is given to a mobile with this trigger type, instead of the cash being added to mob->gold, the mobile is instead given a pile of coins in the proper amount. In this way, the mobile can drop the coins or refer to the object by "amount" (short description:"%d gold coins") This surely has some drawbacks, but it lets the mobile do something with the bribe (NOTE: dropping it and getting it turns it into cash) This can be done sneakily if a NPC-only "at" command exists. Syntax: death_prog <NUMBER> The argument is a percent once again. NOTE: When the mobile dies, if the random percentage is less than the argument the mobile performs the MOBprogram commands rather than the usual death_cry sequence. This is done before the corpse is made, so the commands can be considered the mobiles last gasp. It could perhaps destroy the items it was holding, or create some, or cast a spell on the killer and the room, or even goto a new location and die there (with a text message, the corpse would seem to vanish) The position of the mobile is set to STANDING, and so it can do all the normal commands, without worrying about being DEAD. However, even if the mobile restores itself to full hitpoints, it will still die. This is not a way to immortal mobiles. However, the last thing this mobile does could be to goto some vacant room, load a fresh version of itself, drop all its items, force the new mobile to get all the items and wear them, send the new mobile back to the character who killed it and force the new mobile to attack that character. Along with a text message which said the mobile restored itself, this might be a convincing effect. (Note that your kitten could turn into a dragon this way too). Of course this assumes that some NPC commands have been implemented. Syntax: range_prog There is no argument to range_prog. NOTE: The range_prog is triggered if the mobile is shot by a range weapon. The program can then check the shotfrom($i) ifcheck to see which direction the shot came from. Note that the first successful bribe_prog, give_prog, hitprcnt_prog, death_prog, fight_prog, rand_prog and entry_prog is the only one which is executed. All the successful greet(_all)_progs, speech_progs, and act_progs will be done. This is the best arrangement we found for handling situations where you imported several MOBprogram files for a mobile. If you are going to write lots of little files and piece them together to create the effect you want, it is advisible to not mix things together all that much, otherwise you have to pay close attention to the order in which the programs are added to the link list. Also, no MOBprograms will be successful when the mobile is charmed (since it has no self violition, it should act like it has none) to protect mobiles which are given special powers from being implemented by a player. One bug we had in early testing was a player who charmed a mobile and then used its aggressive greet_prog to attack other players. ------------------------------Variables------------------------------------ To make things come alive, variables are needed. These are represented in the MOBprograms by using a dollar sign convention as in the socials. When the mud command is processed, these variables are expanded into the values shown below. Usually, it is best to use the short descriptions of mobiles and the names of players when speaking them, but if you are performing an action to someone almost always you want the name. The title field for players is an extra that probably wont often be used. Without further hesitation... the variables: $i the first of the names of the mobile itself. $I the short description of the mobile itself. $n the name of whomever caused the trigger to happen. $N the name and title of whomever caused the trigger to happen. $t the name of a secondary character target (i.e A smiles at B) $T the short description, or name and title of target (NPC vs PC) $r the name of a random char in the room with the mobile (never == $i) $R the short description, or name and title of the random char $j he,she,it based on sex of $i. $e he,she,it based on sex of $n. $E he,she,it based on sex of $t. $J he,she,it based on sex of $r. $k him,her,it based on sex of $i. $m him,her,it based on sex of $n. $M him,her,it based on sex of $t. $K him,her,it based on sex of $r. $l his,hers,its based on sex of $i. $s his,hers,its based on sex of $n. $S his,hers,its based on sex of $t. $L his,hers,its based on sex of $r. $o the first of the names of the primary object (i.e A drops B) $O the short description of the primary object $p the first of the names of the secondary object (i.e A puts B in C) $P the short description of the secondary object $c the first of the names of the third object (carry object) $C the short description of the thrid object (carry object) $a a,an based on first character of $o $A a,an based on first character of $p $1..$9 Corresponding word in the trigger phrase. $5 when the triggering string is "Hey, give me a boot" would be "boot" Also, in if_checks, the accepted variables are the basic ones (i,n,t,r,o,p). If a variable is referenced that doesnt exist, then the value is simply left blank. (i.e referring to $o when the trigger is: A kisses B) The only problem with the variables is that the secondary object and the secondary target are passed by act() in the same location. This means that if you reference $t in an A puts B in C situation, the result will probably be a happy mud crash or some weird side effect, espescially if $t is used in an if_check (i.e. if isnpc($t) in the above situation) The basic fix for this is to change everyone who calls the act() procedure to specify a secondary object and a secondary character. But that is a fairly comprehensive trivial twiddle, so we left it the way it is so that, you arent forced to make all those twiddles to use the MOBprograms. ---------------------------Control Flow Syntax------------------------------ In place of any legal mud command in a MOBprogram, one can substitute a flow of control command. Here is the syntax for a flow of control command. "if" " " {if_check_1} "(" {argument} ")" [ {operator} {value} ] NL [ "or" " " {if_check_2} "(" {argument} ")" [ {operator} {value} ] NL ] . . . [ "or" " " {if_check_N} "(" {argument} ")" [ {operator} {value} ] NL ] [ {program_command_1} NL ] [ {program_command_2} NL ] . . . [ "break" NL ] . . . [ {program_command_N} NL ] [ "else" NL ] [ {program_command_1} NL ] [ {program_command_2} NL ] . . . [ "break" NL ] . . . [ {program_command_N} NL ] "endif" NL Basically, it is: an 'if' line, followed by zero or more 'or' lines, followed by zero or more legal mud commands, which may contain a 'break' line, possibly followed by an 'else' line , followed by zero or more legal mud commands, which may contain a 'break' line, followed by an 'endif' line. The only new syntax labels are all in the IF line: --Explainations An IF_CHECK is a string which describes under what context to compare things. The ARGUMENT is the reference point from which the LHS of an expression comes. The OPERATOR indicates how the LHS and RHS are going to be compared. The VALUE is the RHS of the expression to be compared by the operator. The BREAK command bails out of the entire MOBprogram regardless of the level if nesting. If that looks confusing, skip to the end of the document and review the Example. Hopefully that should clear things, otherwise you'll probably have to give us a mail since examples are the best way we know to explain syntax. --------------------------------Operators----------------------------------- Most of the basic numeric operators are legal and perform the same function as in C. The string operators are a bit more confusing. There are negative versions of some of the operators. These are not strictly needed, since the if/else construct of Control Flow commands can handle either case. Numeric Operators: == != > < >= <= & | String Operators: == != / !/ For strings, == and != check for exact match between the two strings and the other two, / and !/ check to see if the second string is contained in the first one. This is so things like: if name($n) / guard will respond true to "cityguard" "guard" "guardian" etc. Using == on a name implies that you are matching the complete name "cityguard guard" or whatever. The string operators are case SENSITIVE. ------------------------If_Checks In Control Flow--------------------------- The provided list of if_checks and their arguments are below. They should all be fairly obvious in what they do, but some of the more obtuse deserve a slight explanation. Any '==' operator can be replaced with any of the available ones described above. The argument ($*) refers to any of the variables which make sense for that if_check (i.e. for an if_check which is referencing a person the only valid variables would be $i, $n, $t or $r) A value type of string is a sequence of characters. It does not need to be included in quotes or anything like that (i.e. name($n)== orc large brown) rand (num) Is random percentage less than or equal to num isnpc ($*) Is $* an NPC ispc ($*) Is $* a PC isgood ($*) Does $* have a good alignment isfight ($*) Is $* fighting isimmort ($*) Is the level of $* greater than max_mortal ischarmed ($*) Is $* affected by charm isfollow ($*) Is $* a follower with their master in the room isaffected($*) & integer Is ($*->affected_by & integer) true (person only) hitprcnt ($*) == percent Is the hit/max_hit of $* equal to percent inroom ($*) == integer Is the room of $* equal to integer (person only) sex ($*) == integer Is the sex of $* equal to integer position ($*) == integer Is the position of $* equal to integer level ($*) == integer Is the level of $* equal to integer class ($*) == integer Is the class of $* equal to integer goldamt ($*) == integer Does $* have a gold total equal to integer objtype ($*) == integer Is the type of $* equal to integer (armor,boat,etc) objval# ($*) == integer Is $*->value[#] equal to integer (# from 0-3) number ($*) == integer Is the vnum of $* equal to integer name ($*) == string Is the name of $* equal to string race ($*) == integer # Is the race of $* equal to integer armystatus($*) == integer Army: 0=Not in Army, 1=In Army, 2= Retired time () == integer # Is the time of day in the game equal to integer shotfrom ($i) == string # Is the name of the direction a shot came from hasobj (name) # True if the mobile has an object named "name" allows you to access the $c and $C variables hasobjnum (vNum) # True if the mobile has object of specified vNum allows you to access the $c and $C variables actorhasobjnum (vNum) # Actor has object with vNum=vNum? sets $c & $C whichgod ($*) == integer # Is the number of the specified mobile/char's leading god (0=None, 1=Order, 2=Chaos, 3=Demise, 4=Police ) quest (B,N,$*) == integer # The value of the bitfield that starts at bit B (0..31) and is N bits wide for $* (mobile) objquest(B,N,$*)== integer # The value of the bitfield that starts at bit B (0..31) and is N bits wide for $* (object) pcsinarea () == integer # The number of PC's in the area of mobile pcsinarea (room#) == integer # The number of PC's in the area of room # "#" marks ifchecks exclusive to MrMud ------------------------MOBCommands Of Interest----------------------------- These are fairly basic things, most of them are wiz commands which have been changed to allow for mobiles to perform the commands. If you have the problem of immortals abusing these powers on your mud either ditch the immortals, or add a check in all of them to only let NPC's with null descriptors do the commands. (However, you lose a little debugging help that way). MrMud has provided a little security feature against this but it is by no means comprehensive. Please check yourself if you are concerned. *** Important: Since many items have the same name for keywords, it is highly suggested that the creator use the I#### system for such things as give_prog. This uses the object number with an 'I'. This method allows exact procedures of handling objects in mob_progs. This system is added to all item keywords, so it is not necessary to add them to each item keyword list. Here are the basic MOBcommands that we found to be enticing: Syntax: MPSTAT <mobile> Shows the MOBprograms which are set on the mob of the given name or vnum and some basic stats for the mobile Syntax: MPASOUND <text_string> Prints the text string to the rooms around the mobile in the same manner as a death cry. This is really useful for powerful aggressives and is also nice for wandering minstrels or mobiles like that in concept. Syntax: MPJUNK <object> Destroys the object refered to in the mobiles inven. It prints no message to the world and you can do things like junk all.bread or junk all. This is nice for having janitor mobiles clean out their inventory if they are carrying too much (have a MOBprogram trigger on the 'full inventory') Syntax: MPECHO <text_string> MPECHOAT <victim> <text_string> MPECHOAROUND <victim> <text_string> Prints the text message to the room of the mobile. The three options let you tailor the message to goto victims or to do things sneaky like having a merchant do: mpat guard mpechoat guard rescue_please This coupled with a guard act_prog trigger on rescue_please to mpgoto $n and mpecho $I has arrived. It is an affective way of quickly bringing guards to the scene of an attack. Syntax: MPMLOAD <mobile vnum> MPOLOAD <object vnum> Loads the obj/mobile into the inven/room of the mobile. Even if the item is non-takable, the mobile will receive it in the inventory. This lets a mobile distribute a quest item or load a key or something. Please use this under EXTREME caution. In most cases the game administrator will not allow these cases, unless a special effect is required. It is very easy to overdue it, by continually loading objects and items. Syntax: MPKILL <victim> Lets a mobile kill a player without having to murder and be fifth level. Lots of MOBprograms end up with mpkill $n commands floating around. It works on both mobiles and players. Syntax: MPPURGE [argument] Destroys the argument from the room of the mobile. Without an argument the result is the cleansing of all NPC's and items from the room with the exception of the mobile itself. However, mppurge $i will indeed purge the mobile, but it MUST be the last command the mobile tries to do, otherwise the mud cant reference the acting mobile trying to do the commands and bad things happen. Syntax: MPQUIET < 'ON', 'OFF'> This command stops ALL forms out output data from reaching anyone. This command can be only used inside of mob_progs, and should not be used in obj_progs at any time (it will not work regardless). Simply issue 'mpquiet on' to make all commands quiet. The mob_prog will always reset it to 'off' regardless is the programmer calls the 'off'. This command could be used to simulate a snake biting, when it is actually casting 'poison'. Simply mpecho the bite, then turn MPQUIET ON and do the casting. Syntax: MPGOTO <dest> Moves the mobile to the room or mobile or object requested. It makes no message of its departure or of its entrance, so these must be supplied with mpecho commands if they are desired. Syntax: MPAT <dest> <command> Perfoms the command at the designated location. Very useful for doing magic slight of hand tricks that leave players dumbfounded.. such as metamorphing mobiles, or guard summoning, or corpse vanishing. Syntax: MPTRANSFER [<victim>, 'all', 'pcs'] [dest] Sends the victim to the destination or to the room of the mobile as a default. if the victim is "all" then all the characters in the room of the mobile are transfered to the destination. Good for starting quests or things like that. There is no message given to the player that it has been transfered and the player doesnt do a look at the new room unless the mob forces them to. Immortals cannot be tranfered. The mobile MUST be in the same room as the character being transfered before the transfer will take place. Please note that the use of "all" includes mobiles except one issuing the command. Use "pcs" to transfer all players and pets. Syntax: MPFORCE <victim> <command> Forces the victim to do the designated command. The victim is not told that they are forced, they just do the command so usually some mpecho message is nice. You can force players to remove belongings and give them to you, etc. The player sees the normal command messages (such as removing the item and giving it away in the above example) Again, if the victim is "all" then everyone in the mobiles room does the command. This cannot be used on immortals. Syntax: MPMSET <mobile> <field> <value> MPMSET <mobile> <string> <value> Enables the mob_prog to change mobiles on the fly. Parameters: <mobile> is the name of the mobile to change <field> is one of: str int wis dex con sex class level practice align thirst drunk full exp gold hp mana move quest randquest <string> is one of: name short long description title spec <value> is whatever is appropriate for the specified string/field 'quest' has three <values>: firstBit numBits newValue 'randquest' has two <values>: firstBit numBits it assigns a random value to the specified quest bit range There is a special case with strings, using the value "NULL" will reset the string to it's original value. EXAMPLE: mpmset $n quest 0 4 1 would take the bitfield starting at bit 0 and that is 4 bits long and set it to the value 1. (each mobile has 32 bits) Special note: To make a diguise for a player, change the string of LONG to what you want to disguise the player as. To return the player to it's normal state, use the value of NULL. ex: mpmset $n long There is a small boy here. (disguise the player as a small boy) mpmset $n long null (returns the player to normal) Syntax: MPOSET <object> <field> <value> MPOSET <object> <string> <value> Enables the mob_prog to change objects on the fly. Parameters: <object> is the name of the object to change <field> is one of: value0 value1 value2 value3 extra setextra clrextra wear level weight cost timer quest <string> is one of: name short long ed <value> is whatever is appropriate for the specified string/field 'setextra' and 'clrextra' set or clear extra flag bits and 'extra' sets the extra flag bits to the specified value 'quest' has three <values>: firstBit numBits newValue 'randquest' has two <values>: firstBit numBits it assigns a random value to the specified quest bit range There is a special case with strings, using the value "NULL" will reset the string to it's original value. EXAMPLE: mposet $n quest 0 4 1 would take the bitfield starting at bit 0 and that is 4 bits long and set it to the value 1. (each object has 32 bits) Syntax: MPMADD <victim> <field> <value> Enables you to add to or subtract from the values of the following stats of a mobile or player character. Parameters are: <victim> is the name of the mobile/player to modify <field> is one of: str int wis dex con sex class level exp practice align gold hp mana move thirst drunk full quest <value> is whatever is appropriate for the specified field 'quest' has three <values>: firstBit numBits addValue EXAMPLE: mpmadd $n quest 0 4 1 would take the bitfield starting at bit 0 and that is 4 bits long and add 1 to it. (each mobile has 32 bits) Syntax: MPOADD <object> <field> <value> Enables you to add to or subtract from the values of the following stats of an object. Parameters are: <object> is the name of the object to modify <field> is one of: value0 value1 value2 value3 level weight cost timer <value> is whatever is appropriate for the specified field 'quest' has three <values>: firstBit numBits addValue EXAMPLE: mpoadd $n quest 0 4 -1 would take the bitfield starting at bit 0 and that is 4 bits long and subtract 1 from it. (each item has 32 bits) Syntax: MPGORAND <firstroom> <lastroom> <offset> <skipsize> say, you have a 4x4 area from room #6400 to #6415 arranged like: 6400 6401 6402 6403 6404 6405 6406 6407 6408 6409 6410 6411 6412 6413 6414 6415 then "mpgorand 6400 6415 0 4" would put the mobile in one of the the following rooms: 6400 6404 6408 6412 then "mpgorand 6400 6415 3 4" would put the mobile in one of the the following rooms: 6403 6407 6411 6415 ============================================== New commands devoted to mobile programs: These commands can be used by gods or mobiles only. Many of these commands alter the structure of the world, so please use only where required. MAZE <X size> <Y size> <Z size> <Character Name> This command takes an area that already exists, and redefines the exits into a random pattern. This can be used to create mazes that change during game play. This command is very slow, so use with caution. The maze that is created has absolutely no connections to the rest of the world, so the use of "connect", "door" and "key" may be required to link the area to the rest of the game. <? size> defines the dimensions of the maze. <Character Name> defines what the seed number will be. Seed number is a value that determines how the maze will be generated. The use of the same seed on a maze with the same dimensions will always generate the same maze. Therefore individuals will always see the same maze, but it will be different between individuals. example: maze 3 2 4 Bilbo Creates a maze that has 24 rooms, with a seed based on Bilbo. NOTE: The name is a good place for '$n' of the mob_progs. CONNECT <door number> <destination room number> [both] This command creates a hallway in one direction from the current room to the room described in the destination. <door number> defines which door the exit is generated at. (Use 0 to 5) <destination room number> defines the number of the room connecting to. Use a destination number of "-1" to create a wall, and disconnect a room. [both] is an optional parameter that creates a bi-directional hallway. Without this option, the hallway created it totaly one-way. example: connect 1 9709 both Creates a hallway from the current room, east to the Chaos temple. Usage: An interesting use for this command is to temporarily create a door that did not previously exist, and force a party through it, then use the connect command again to remove the newly created eixt. DOOR <door number> <door type> [<door name>] This command places a door between two connected rooms. These rooms need not be connected through the "connect" command. If you are using the "connect" command, be sure to connect both sides, since the "connect" command only works in one direction. The door command only works if both exits on the two rooms are going in opposite directions, to the other room, which is a standard hallway. <door number> defines which door the exit is generated at. (Use 0 to 5) <door type> is the door flag: 0 - open hallway. 1 - open, not locked door. 2 - closed, but not locked door. 4 - closed, and locked door. (key does NOT exist upon creation) 8 - closed, locked, and hidden door. (key does not exist) <door name> this a the text name of the door. If the name is not specified, the the name defaults to "door". example: door 1 4 gate Creates a gate at the hallway to the east that is locked and shut. KEY <door number> <key name> This command creates a key for the locked door in the specified direction. This command does not required that the door be created using the "door" command. The key is encoded with the number of the room it was generated at, so DO NOT use this command more than once in the same room, because effectively, this will create two of the same keys. This key also changes the door's number that describes which key fits it, so DO NOT use this command on a door that already has a key, as it will invalidate the previous key, if the previous key has a different number compared to the room number. <door number> defines which door the exit is generated at. (Use 0 to 5) <key name> must be used to give the text name of the key. example: key 1 brown Creates a key for the door to the east, and names the key to "the brown key". RESCALE <mobile vnum> <character name> <percentage> This command changes the level of all of a particular type of mobile to some level based on a player in the game. The mobile need not be in the same room as the character. <mobile vnum> Defines which mobiles are modified. This only modifies the surface characteristics, and any new mobiles created use the normal stats. <character name> The name of the character that the mobile will be scaled against. The Character name must be a valid player currently in the game, and other mobiles do not qualify. <percentage> Defines how strong the mobile is in relation to the character being considered. Note: This command is best used when the mobile is level 95th, and rescaled down to the level of the character. Note: The best use of this command is during a mob_prog and utilizing the '$n' for the name of the character. PURGE [area] This command is a modified form of PURGE, called by "purge area". When used it scans every room in an entire area, and purges it of items, and mobiles. This command is VERY slow, so use with caution. --------------------------Regarding CPU Slowdown------------------------------- We have no real idea how slow this makes a mud. However, you will find that if you are judicious with your use of MOBprograms, you can either do little damage, or even reduce the effort on your server! This means that mobile polling (including the rand_progs) need only be checked when players are around. This reduces computation of random_stuff a little, but it is still a polling method, and subject to a basic inefficiency there. However, aside from the rand_progs, the only additional slowdowns will be when the mobile is responding to the situation, and you would get that from a special procedure as well (although MOBprograms are surely not as efficient as compiled C code). MrMud systems can track the average speed for various functions. Mobile programs rank as one of the top 3 functions, and eat up about 30% of the total cpu usage for the entire game. Although this is a general game-wide value, it gives an idea of the complexity of the mob_prog system. -------------------------Miscellaneous Information----------------------------- There is really no limit to the number of MOBprograms a given mobile can have. However, the length of a single command block is limited by the value of MAX_STRING_LENGTH. In my version it was around 22k, so that is probably about 500 lines. The indentation spaces shown in the example above are NOT required, but do make it easier to read (and debug), but they do take up some space. The MOBprogram stuff runs totally without anything in the mob_commands.c file, but letting mobiles be a bit more godlike has allowed us to do what we consider to be wonderful things. The replicant and polymorphing mobiles described above as well as some nifty mob helping mob interactions are an example. It IS possible to accidentally make mobiles which can trigger in loops. As mentioned in the example at the end of this document, the result is usually a mud crash or major CPU dent. We dont know any way to prevent this from happening, other than careful coding and a restriction of mobile travel from zones of one creator to another (another good reason to not have charmed mobiles do anything). Tracking down the culprit mobile is not always easy. The only thing we have found which always works, is to add a log statement into the MOBprogram driver and fill some disk space until it becomes apparent what commands are repetitively issued. Also, most infinite loops are flukes where the situation just happens to be right and usually it never happens again. Another common problem is mobiles that load other mobiles for various reasons. This may seem innoculous, until the loaded mobile decides to load another mobile. It has been seen that some areas, over the course of time can develope thousands of mobiles, which slow down the cpu drastically, not to mention the drain on system resources, such as RAM. Be very careful that you know the exact situation before mpmloading another mobile. The list of variables and triggers and if_checks will grow continuously as our creators demand the ability to do certain things. If you have a request or if you have a new one, we don't mind hearing about them, and if you find bugs, we shall gladly attempt to squash them for you. As additions or fixes are made, the code will occasionally be redistributed. However, if you want a current version, please feel free to ask. When the code is redistributed, a file containing the change history from the original release will be provided (when possible) to allow you to patch in the changes with low grief. Note about testing: All area creators are required to test their area thoroughly before it is included in the working game. This is usually done on a test game, where the implementors of the working game run the test game on a part-time basis. Special note should be taken on all mob_progs, and obj_progs. It is absolutely required that all cases of a program must be tested, even if it is a simple failure to break. It is much better to find program bugs in the test game then in the working game. ----------------------------------Credits----------------------------------- The reason this code was written was to enhance the playing experience at ThePrincedom (a Merc 2.0 based world scheduled to open in October 1993) The original idea for this type of MOBprogram came from playing on: WORLDS of CARNAGE, a dikumud implemented by Robbie Roberts and Aaron Buhr. Aaron (known as Dimwit Flathead the First) was the original author from what I have been told, and I hope he will not be totally offended and angered by my coding and sharing a mimicked version with the world. This version is probably not as good as the original and I do feel remorse for publishing the idea. However, since Carnage has been down for months without a word of information regarding its return, I am glad to let one of the best features live on in future generations of MUDs. There are no objections to this code being shared, since, aside from a nuclear destruction of all the Temples of Midgaard (excepting the original one!!), bland mobiles are the greatest bane of Dikumuds today. It would be nice to get a message saying you are using the code just for our references. We shant answer questions from anyone until told where they are using the code. *grin* Since this code is not copyrighted, you of course dont have to do anything we say, but it would be nice of you to put the mobprog help screen into your database. and have mobinfo show up somewhere on a more visable help screen (possibly tagged onto the bottom of credits as a see also...) I acknowledge all the work done by the original Diku authors as well as those at Merc Industries and appreciate their willingness to share code. Also, quick thanks to Wraith for doing a little beta-installation testing. N'Atas-Ha June, 1993 murph@ri.cmu.edu In addition to this DOC file credit section, I'd like to add a thank you to Yaz, Mahatma, Zelda, and the rest of the Marble Mud crew for extensively testing MOBProgram 2.1 for me. You may see MOBPrograms in action as well as their own "flavor" of mud at marble.bu.edu 4000. Kahn Oct 28th, 1993 MERC Industries {+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+} Just a tasteless gloating statement by Chaos: A major advancement to the operation of mob_progs was introduced October of 1995. This major advancement is the tokenizing of mob_progs. The original code was a simple system that parsed the code for the $n stuff and shoved the result into the interp routine. This is the same interp routine that players use to decipher commands. The interp routine is relatively slow, and the mob_prog parser is quite slow itself. The basis of the tokenizer is that a mob_prog will not change, once the mud itself has started up, so why parse and interperet it with every execution of a mob_prog? The basic system parses and interperets the mob_progs at boot time. During the execution of a mob_prog, the entire program is made up of pointers to tokens, or blocks of binary (not ascii) data. Execution time is improved significantly. As a fringe benefit, the wiz command mpstat that normally displays the mob_prog's input, now displays the mob_prog's output. This means that the command shows what the mud understands from the mob_prog given to it. Which is excellent for debugging. Also the TIMEMODE command in active mode will give a trace output of the mob_progs while they execute, including the mob_prog line numbers. Future efforts may give these commands to the players on the testing game. ===================CUT HERE FOR QUICK REFERENCE SHEET======================== MOBprogram quick reference (# indicates exclusive to MrMud) * TRIGGERS______argument and what must happen to activate trigger____________ act_prog WORDLIST or P WORD_PHRASE to match from act() to mobile bribe_prog INTEGER amount of miminum gold amount given to mobile entry_prog PERCENT chance to check when mobile moves to a new room give_prog FULL OBJECT NAME or ALL to match when obj given to mobile greet_prog PERCENT chance to check if visable char enters mobile's room all_greet_prog PERCENT chance to check when any char enters mobile's room fight_prog PERCENT chance to check at fight_pulse if mobile is fighting hitprcnt_prog PERCENT lower than mobiles hit/max_hit if mobile is fighting death_prog PERCENT chance to check after mobile has been slain rand_prog PERCENT chance to check whenever a PC is in the mobiles zone speech_prog WORDLIST or P WORD_PHRASE to match in dialogue to mobile range_prog # NOARG triggered when mobile shot * VARIABLES______mobile_actor_victim_random_____object___2nd-Obj__3rd-Obj____ name $i $n $t $r $o $p # $c shrt_desc/title $I $N $T $R $O $P # $C he/she/it $j $e $E $J -- -- -- him/her/it $l $m $M $L -- -- $D = exitName his/hers/its $k $s $S $K -- -- $d = exitNum a/an -- -- -- -- $a $A '$'symbol=$$ * IFCHECK_____argument?_____meaning__________________________________________ rand(num) Is a random percentage less than or equal to num isnpc($*) or ispc($*) Is $* an NPC or PC? isgood($*) Does $* have a good alignment isfight($*) Is $* fighting isimmort($*) Is the level of $* greater than max_mortal ischarmed($*) Is $* affected by charm isfollow($*) Is $* a follower with their master in the room validexit() Is there a valid exit in the room? (sets $d/$D) isaffected($*) & integer Is ($*->affected_by & integer) true (person only) hitprcnt($*) == percent Is the hit/max_hit of $* equal to percent inroom($*) == integer Is the room of $* equal to integer (person only) sex($*) == integer Is the sex of $* equal to integer position($*) == integer Is the position of $* equal to integer level($*) == integer Is the level of $* equal to integer class($*) == integer Is the class of $* equal to integer goldamt($*) == integer Does $* have a gold total equal to integer objtype($*) == integer Is the type of $* equal to integer (armor,boat..) objval#($*) == integer Is $*->value[#] equal to integer (# from 0-3) number($*) == integer Is the vnum of $* equal to integer name($*) == string Is the name of $* equal to string time() == integer # Is the mud's time of day equal to integer race($*) == integer # Is the race of $* equal to integer shotfrom($i) == string # Is the name of the direction a shot came from hasobj(name) # mobile has an object named "name"? $c & $C set hasobjnum(vNum) # mobile has object of specified vNum? $c & $C set actorhasobjnum(vNum) # actor has object of specified vNum? $c & $C set whichgod($*) == integer # which god leads player? 0=none,1=Order,2=Chaos quest(B,N,$*) == integer # value of bitfield from bit B for N bits (mob) objquest(B,N,$*)== integer# value of bitfield from bit B for N bits (obj) * MobCOMMAND____argument-list___________MobCOMMAND______argument-list________ MPSTAT <mobile> MPASOUND <text_string> MPJUNK <object> MPECHO <text_string> MPMLOAD <mobile> MPECHOAT <victim> <text_string> MPOLOAD <object> <level> MPECHOAROUND <victim> <text_string> MPKILL <victim> MPPURGE [argument] MPGOTO <dest> MPAT <dest> <command> MPTRANSFER <dest> [location] MPFORCE <victim> <command> MPMSET # <mobile> <flag/string> MPOSET # <object> <flag/string> MPMADD # <victim> <flag> <val> MPOADD # <object> <flag> <val> MPGORAND # <frm> <lrm> <ofs> <skp> ======================END OF QUICK REFERENCE SHEET=========================== ++++++++++++++++++++++++++++++++EXAMPLE++++++++++++++++++++++++++++++++++++++ Referenced from above in the Control Flow section >act_prog p pokes you in the~ if isnpc($n) chuckle poke $n else if level($n) <= 5 or isgood($n) tell $n I would rather you didnt poke me. else if level($n)>15 scream say Ya know $n. I hate being poked!!! kill $n break endif slap $n shout MOMMY!!! $N is poking me. endif endif ~ Ok.. time to translate.. the trigger will only happen when the mobile gets the message "... pokes you in the ..." If the offender (recall the $n and $N refer to the char who did the poking...) is an NPC, then the mobile merely chuckles and pokes back. If the offender was a PC then good and low level characters get a warning, high level chars get attacked, and midlevel chars get slapped and whined at. Note that two of these mobiles could easily get into an infinite poke war which slows down (or frequently crashes) the mud just a bit :( Be very careful about things like that if you can. (i.e dont respond to a poke with a poke, and try not to let heavily programmed robot mobiles wander around together. More on that is given above.) Also, it is clear that the 'order' command could get confused with the 'or' control flow. However, this is only the case when 'order' is abbreviated to its two letter form, and placed immediately following an 'if' line. Thus, if you want to be that malicious in trying to break the MOBprogram code, noone is going to stand in your way (However, the result of this would be a bug message and a bail out from the ifcheck so things dont really break) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The following are extra examples of mob_progs. These are the running code for the area Gateway to Avernus. Use these as references for creating mob_progs. #QQ19 iron golem chair~ The Iron Golem~ There is a chair here with the distinct outline of a large man. ~ The Iron Golem, formerly a chair, is large and menacing. His steps echo in the room. He has a complete look of indifference in his eyes. ~ 1|2|4096 32|8 0 S 65 0 -9 2d800+6000 2d5+50 0 450000 6 6 1 >speech_prog margoyle~ mpgoto QQ54 mpecho $n arrives from the infinite plains. mptrans $n tell $n You may pass. mpgoto QQ53 mpecho $n is taken from the infinite plains. ~ >rand_prog 20~ say Hello mortal. I know how to leave the plains. ~ >rand_prog 20~ say Ask me to tell you about the stones. ~ >speech_prog stones~ say The stones can move, when they have life. say But the question is how do they get life? ~ >speech_prog life~ say Life can be endowed by the simplest of powers. say Even the homonculous can tell you that. mpecho The homonculous grins widely. ~ >speech_prog plains~ say The plains are infinite. ~ >speech_prog homonculous~ say The homonculous was also created by my master, say along with the other creatures, that exist behind say a set of gates. If you know who my fellow stone say creatures are, I will take you out of the plains. ~ | #QQ20 efreeti~ The Efreeti~ There is a large Efreeti here laughing deeply at you. ~ The efreeti stands over twelve feet tall. Although man-like in appearance, he has two small horns sprouting out of his head. He has flames licking his body. ~ 1|2|4|32|4096 8|32 -100 S 62 0 -8 2d400+2000 2d25+25 80000 310000 8 8 1 >fight_prog 99~ if rand(15) cast "energy" $n else if rand(15) cast "lightening" $n endif endif ~ | #QQ12 belial devil arch~ Belial the Arch Devil~ Belial is twiddling with the ring on his finger and grinning evilly. ~ With an angry glare, Belial judges you. He looks like an ebony man with small horns poking out from the top of his head. He says something to you that you don't understand. ~ 1|2|4|32|4096 8|32|512|262144|16777216|2097152 -1000 S 95 0 -10 1d1+9000 4d18+50 60000 600000 6 6 1 >fight_prog 99~ if rand(17) mpecho A black hole opens in space to admit a small devil. mpmload QQ01 else if rand(13) mpecho A black hole opens in space to admit a devil. mpmload QQ02 else if rand(11) mpecho A black hole opens in space to admit a large devil. mpmload QQ11 else if rand(9) mpecho A black hole opens in space to admit a huge devil. mpmload QQ13 else endif endif endif endif if rand(15) say You will die mortal! else endif if rand(20) cast "earth" else endif if rand(15) cast "acid" $r else endif if rand(15) cast "lightening" $r else endif if rand(15) cast "heal" $i else endif ~ >rand_prog 50~ get all remove all wear all drop all sac all ~ | #QQ13 barbed devil~ The Barbed Devil~ There is a rather large Barbed Devil here. ~ The Barbed Devil is toying with the small flame that is erupting from his hands. ~ 1|4|32|4096 8|32 -1000 S 70 0 -7 2d200+2100 2d25+35 30000 200000 8 8 0 >fight_prog 99~ if rand(15) cast "fire breath" $n else if rand(10) mpecho The Barbed Devil cries out for help from Belial. mpecho A large opening in space appears, and a devil steps out. mpmload QQ11 else kick endif endif ~ >rand_prog 30~ cast "stone skin" $i ~ | ============================================== FILE: "mrmud.txt" These are extractions from MrMud, the program. So they are accurate for the time they were extracted from the program. MAX_CLASS 7 MAX_RACE 8 MAX_LEVEL 99 PULSE_PER_SECOND 4 PULSE_VIOLENCE ( 4 * PULSE_PER_SECOND) PULSE_MOBILE ( 4 * PULSE_PER_SECOND) /* * ACT bits for mobs. * Used in #MOBILES. */ ACT_IS_NPC 1 /* Auto set for mobs*/ ACT_SENTINEL 2 /* Stays in one room*/ ACT_SCAVENGER 4 /* Picks up objects*/ ACT_AGGRESSIVE 32 /* Attacks PC's*/ ACT_STAY_AREA 64 /* Won't leave area*/ ACT_WIMPY 128 /* Flees when hurt*/ ACT_PET 256 /* Auto set for pets*/ ACT_TRAIN 512 /* Can train PC's*/ ACT_PRACTICE 1024 /* Can practice PC's*/ ACT_WEAK 2048 /* Cannot carry anything*/ ACT_SMART 4096 /* Can say, normal can't*/ ACT_ONE_FIGHT 8192 /* Disapears after fight*/ ACT_NO_ORDER 16384 /* Cannot be ordered */ ACT_BODY 65536 /* uses body parts (Highly suggested) */ ACT_RACE 131072 /* Allows race to be defined (Highly suggested) */ ACT_UNDEAD 262144 /* Does not create corpse on death for TURN spell */ /* * Bits for 'affected_by'. * Used in #MOBILES. */ AFF_BLIND 1 AFF_INVISIBLE 2 AFF_DETECT_INVIS 8 AFF_SANCTUARY 128 AFF_FAERIE_FIRE 256 AFF_INFRARED 512 AFF_UNDERSTAND 2048 AFF_PROTECT 8192 AFF_SNEAK 32768 AFF_HIDE 65536 AFF_SLEEP 131072 AFF_FLYING 524288 AFF_PASS_DOOR 1048576 AFF_STEALTH 2097152 AFF_CLEAR 4194304 AFF_HUNT 8388608 AFF_TONGUES 16777216 AFF_ETHEREAL 33554432 Makes the mobile absolutely invisible to system /* * Sex. * Used in #MOBILES. */ SEX_NEUTRAL 0 SEX_MALE 1 SEX_FEMALE 2 /* * Item types. * Used in #OBJECTS. */ ITEM_TYPE_LIGHT 1 /* to light rooms...can't be invis */ ITEM_TYPE_SCROLL 2 /* recitable magic (w/ target) */ ITEM_TYPE_WAND 3 /* zapable magic (w/ target) */ ITEM_TYPE_STAFF 4 /* brandishable magic (all in room) */ ITEM_TYPE_WEAPON 5 /* weapons, of course */ ITEM_TYPE_TREASURE 8 /* things of value? */ ITEM_TYPE_ARMOR 9 /* armor, what else? */ ITEM_TYPE_POTION 10 /* quaffable magic (on self) */ ITEM_TYPE_FURNITURE 12 /* signs, statues, etc. */ ITEM_TYPE_TRASH 13 /* valueless items */ ITEM_TYPE_CONTAINER 15 /* backpacks, bags, etc. */ ITEM_TYPE_DRINK_CON 17 /* bottles, skins, etc. */ ITEM_TYPE_KEY 18 /* to unlock doors and containers */ ITEM_TYPE_FOOD 19 /* edible nourishment */ ITEM_TYPE_MONEY 20 /* piles of gold */ ITEM_TYPE_BOAT 22 /* lets you move across water */ ITEM_TYPE_FOUNTAIN 25 /* place to drink */ ITEM_TYPE_PILL 26 /* edible magic (on self) */ ITEM_TYPE_AMMO 30 /* ammunition (arrows, bolts, etc.) /* * Extra flags. * Used in #OBJECTS. */ ITEM_FLAG_GLOW 1 ITEM_FLAG_HUM 2 ITEM_FLAG_DARK 4 ITEM_FLAG_LOCK 8 ITEM_FLAG_EVIL 16 ITEM_FLAG_INVIS 32 ITEM_FLAG_MAGIC 64 ITEM_FLAG_NODROP 128 ITEM_FLAG_BLESS 256 ITEM_FLAG_ANTI_GOOD 512 ITEM_FLAG_ANTI_EVIL 1024 ITEM_FLAG_ANTI_NEUTRAL 2048 ITEM_FLAG_NOREMOVE 4096 /* "cursed" items */ ITEM_FLAG_INVENTORY 8192 /* This item will not be removed from player on death. This item will dissappear if the mobile is killed with it */ ITEM_FLAG_LEVEL 16384 /* set to make RENTAL COST==LEVEL */ ITEM_FLAG_AUTO_ENGRAVE 65536 /* Engraved to first to get item */ NOTE: if the ITEM_FLAG_LEVEL flag of an object is set then the RENTAL COST field of that object is interpreted as being that objects level and not its rent value (because MrMud doesn't have rent). /* * Wear flags. * Used in #OBJECTS. */ ITEM_WEAR_TAKE 1 ITEM_WEAR_FINGER 2 ITEM_WEAR_NECK 4 ITEM_WEAR_BODY 8 ITEM_WEAR_HEAD 16 ITEM_WEAR_LEGS 32 ITEM_WEAR_FEET 64 ITEM_WEAR_HANDS 128 ITEM_WEAR_ARMS 256 ITEM_WEAR_SHIELD 512 ITEM_WEAR_ABOUT 1024 ITEM_WEAR_WAIST 2048 ITEM_WEAR_WRIST 4096 ITEM_WEAR_WIELD 8192 ITEM_WEAR_HOLD 16384 /* * Apply types (for affects). * Used in #OBJECTS. */ APPLY_NONE 0 APPLY_STR 1 APPLY_DEX 2 APPLY_INT 3 APPLY_WIS 4 APPLY_CON 5 APPLY_SEX 6 APPLY_MANA 12 APPLY_HIT 13 APPLY_MOVE 14 APPLY_GOLD 15 /* not used */ APPLY_AC 17 APPLY_HITROLL 18 APPLY_DAMROLL 19 APPLY_SAVING_BREATH 23 APPLY_SAVING_SPELL 24 /* * Values for containers (value[1]). * Used in #OBJECTS. */ CONT_CLOSEABLE 1 CONT_PICKPROOF 2 CONT_CLOSED 4 CONT_LOCKED 8 /* * Room flags. * Used in #ROOMS. */ ROOM_DARK 1 ROOM_NO_MOB 4 /* wandering mobiles can't enter the room */ ROOM_INDOORS 8 ROOM_PRIVATE 512 /* only two people at a time */ ROOM_SAFE 1024 /* can't do aggressive commands */ ROOM_SOLITARY 2048 /* only one person at a time */ ROOM_PET_SHOP 4096 /* place to buy pets */ ROOM_NO_RECALL 8192 ROOM_BLOCK 32768 /* room blocked from entrance */ ROOM_NO_SAVE 65536 /* you can't save in this room also means no quitting in this room */ ROOM_MORGUE 131072 /* shop in this room sells PC corpses */ /* The following 2 groups are combinations of bits, so do not select a room for several classes of alignments */ ROOM_ALTAR_N 1572864 /* able to DEATH set for neutral players */ ROOM_ALTAR_C 524288 /* able to DEATH set for chaos followers */ ROOM_ALTAR_O 1048576 /* able to DEATH set fororder followers */ ROOM_ALLOW_ILL 2097152 /* The following rescrict all but 1 class */ ROOM_ALLOW_ELE 4194304 /* you may use ONLY one of these */ ROOM_ALLOW_ROG 6291456 /* Generally used to make practice halls */ ROOM_ALLOW_RAN 8388608 ROOM_ALLOW_NEC 10485760 ROOM_ALLOW_MON 12582912 ROOM_ALLOW_ASN 14680064 /* * Directions. * Used in #ROOMS. */ DIR_NORTH 0 DIR_EAST 1 DIR_SOUTH 2 DIR_WEST 3 DIR_UP 4 DIR_DOWN 5 /* * Exit flags. * Used in #ROOMS. */ EX_ISDOOR 1 EX_CLOSED 2 EX_LOCKED 4 EX_HIDDEN 8 /* cannot be seen w/o detect hid */ EX_PICKPROOF 32 /* * Sector types. * Used in #ROOMS. */ SECT_INSIDE 0 SECT_CITY 1 SECT_FIELD 2 SECT_FOREST 3 SECT_HILLS 4 SECT_MOUNTAIN 5 SECT_WATER_SWIM 6 SECT_WATER_NOSWIM 7 SECT_UNUSED 8 SECT_AIR 9 SECT_DESERT 10 SECT_LAVA 11 /* Hurts the player every second or so */ SECT_INN 12 /* Heals the player while not on the game */ SECT_ETHEREAL 13 (Requires Ethereal Travel spell) SECT_ASTRAL 14 (Requires Astral Projection spell) SECT_UNDERWATER 15 (Requires Breath water spell) /* * Equpiment wear locations. * Used in #RESETS. */ WEAR_NONE -1 WEAR_LIGHT 0 WEAR_FINGER_L 1 WEAR_FINGER_R 2 WEAR_NECK_1 3 WEAR_NECK_2 4 WEAR_BODY 5 WEAR_HEAD 6 WEAR_LEGS 7 WEAR_FEET 8 WEAR_HANDS 9 WEAR_ARMS 10 WEAR_SHIELD 11 WEAR_ABOUT 12 WEAR_WAIST 13 WEAR_WRIST_L 14 WEAR_WRIST_R 15 WEAR_WIELD 16 WEAR_HOLD 17 MAX_WEAR 18 /* * Conditions. */ COND_DRUNK 0 COND_FULL 1 COND_THIRST 2 /* * Positions. */ POS_DEAD 0 POS_MORTAL 1 POS_INCAP 2 POS_STUNNED 3 POS_SLEEPING 4 POS_RESTING 5 POS_FIGHTING 6 POS_STANDING 7 /* * Player class defines */ CLASS_ILLUSIONIST 0 CLASS_ELEMENTALIST 1 CLASS_ROGUE 2 CLASS_RANGER 3 CLASS_NECROMANCER 4 CLASS_MONK 5 CLASS_ASSASSIN 6 /* Player Races */ RACE_HUMAN 0 RACE_HALFING 1 RACE_ELF 2 RACE_DROW 3 RACE_DWARF 4 RACE_GNOME 5 RACE_ORC 6 RACE_OGRE 7 ============================================================================ /* * the values for items (value[0]..value[3]) */ ITEM_LIGHT (1) Value[0]: Not Used Value[1]: Not Used Value[2]: Number of hours the light can be used for. Zero hours means that the light has gone out. A negative number will create an eternal light source. Eternal lights should not be plentiful or easily obtained. Value[3]: Not Used ITEM_SCROLL (2) Value[0]: Level of the spell on the scroll. Value[1]: Which spell (see list in spells.txt) Value[2]: Which spell Value[3]: Which spell The values(1-3) are three (or less) different spells, mixed 'on' the scroll. Unused spells should be set to -1. ITEM_WAND (3) Value[0]: Level of spell in wand. Value[1]: Max Charges (1..X) Value[2]: Charges Left Value[3]: Which spell in wand (see list in spells.txt) ITEM_STAFF (4) Value[0]: Level of spell in staff. Value[1]: Max Charges (1..X) Value[2]: Charges Left Value[3]: Which spell in staff (see list in spells.txt) ITEM_WEAPON (5) Value[0]: Type of ammo shot by the weapon (0 if not a range weapon) Value[1]: Number of dice to roll for damage (keep this number low) Value[2]: Size of dice to roll for damage Value[3]: The weapon type. Type is one of: NAME NUMBER CATEGORY Message type ------------------------------------------------------------------------- WEAPON_SLICE 1 : Slice Slice/Slices WEAPON_STAB 2 : Stab Stab/Stabs (can be backstabbed with) WEAPON_SLASH 3 : Slash Slash/Slashes WEAPON_WHIP 4 : Whip Whip/Whips WEAPON_CLAW 5 : Claw Claw/Claws WEAPON_BLAST 6 : Blast Blast/Blasts WEAPON_POUND 7 : Pound Pound/Pounds WEAPON_CRUSH 8 : Crush Crush/Crushes WEAPON_GREP 9 : Grep Grep/Greps WEAPON_BITE 10 : Bite Bite/Bites WEAPON_PIERCE 11 : Pierce Pierce/Pierces (can be backstabbed with) ITEM_TREASURE (8) Value[0]: - Value[1]: - Value[2]: - Value[3]: - ITEM_ARMOR (9) Value[0]: The effective AC. >0 enhances the armour class. <0 reduces the the armour class (cursed armour for example). Value[1]: - Value[2]: - Value[3]: - ITEM_POTION (10) Value[0]: Level of the spell in the potion. Value[1]: Which spell (Listed in spells.txt) Value[2]: Which spell Value[3]: Which spell The values(1-3) are three (or less) different spells, mixed in the potion. Unused spells should be set to -1. Eg. Value 0 : 30 (Level) Value 1 : 27 (Harm) Value 2 : 17 (Curse) Value 3 : -1 (no-spell) BTW: Don't drink this - It's bad for your health! ITEM_FURNITURE (12) Value[0]: - Value[1]: - Value[2]: - Value[3]: - ITEM_TRASH (13) Value[0]: - Value[1]: - Value[2]: - Value[3]: - ITEM_CONTAINER (15) Value[0]: Maximum weight the container can contain. Value[1]: Container flags: CLOSEABLE 1 PICKPROOF 2 CLOSED 4 LOCKED 8 Value[2]: The item-number of the object which can open the object. -1 means no lockability. Value[3]: - (always 0) ITEM_DRINKCON (17) Value[0]: Maximum drink-units the drink-container can contain. Value[1]: Number of drink-units that are left in the container. Value[2]: The type of liquid in the drink-container, one of: Type nr. Effect Drunkness Fullness Thirst LIQ_WATER 0 0 1 10 LIQ_BEER 1 3 2 5 LIQ_WINE 2 5 2 5 LIQ_ALE 3 2 2 5 LIQ_DARKALE 4 1 2 5 LIQ_WHISKY 5 6 1 4 LIQ_LEMONADE 6 0 1 8 LIQ_FIREBRT 7 10 0 0 LIQ_LOCALSPC 8 3 3 3 LIQ_SLIME 9 0 4 -8 LIQ_MILK 10 0 3 6 LIQ_TEA 11 0 1 6 LIQ_COFFE 12 0 1 6 LIQ_BLOOD 13 0 2 -1 LIQ_SALTWATER 14 0 1 -2 LIQ_COKE 15 0 1 5 The above values for drunkness/fullness/thirst are used per four "units" drunk. The values are expressed in HOURS! Example: Dragon empties a bottle (say 7 units) of saltwater. His Drunkness is not changed ((7/4)*0) His Fullness increases by ((7/4)*1) hours His Thirst increases by ((7/4)*-2) hours, thus making him More thirsty. The hours above are numbers between 0 and 24. 24 hours is maximum for drunkness/fullness/thirst. When hours are zero for any drunkness/fullness/thirst the person will be sober, hungry, or thirsty respectively. Value[3]: if this value is non-zero, then the drink is poisoned. ITEM_KEY (18) Value[0]: The key-type. This value must match the lock-type the door that the key can open (if the vnum of the key doesn't match the lock-type that is). Value[1]: - Value[2]: - Value[3]: - ITEM_FOOD (19) Value[0]: The number of hours, that this food will fill the stomach Value[1]: - Value[2]: - Value[3]: If this value is non-zero, the food is poisoned. ITEM_MONEY (20) Value[0]: The number of gold coins "in the pile of coins". Value[1]: - Value[2]: - Value[3]: - ITEM_BOAT (22) Value[0]: - Value[1]: - Value[2]: - Value[3]: - ITEM_FOUNTAIN (22) Value[0]: - Value[1]: - Value[2]: - Value[3]: - ITEM_PILL (22) Value[0]: Level of the spell in the potion. Value[1]: Which spell (Listed in spells.txt) Value[2]: Which spell Value[3]: Which spell ITEM_AMMO (22) Value[0]: Ammunition type (matches Value[0] of weapon that will shoot it) Value[1]: Damage (amount of damage caused by the ammo when it hits) Value[2]: Speed (4/second, keep numbers high (20 for fast arrows)) Value[3]: Effective range (it's possible to shoot it farther than the number given here, but at reduced damage. Please note that ranges greater than 5 are sensless because no one can see further than 5 rooms away) ============================================================================ Percentwise Coverage of Armour and allowed AC range Location Protects Range -------- -------- ----- Body 30% [1..10] Head 20% [1..10] Legs 20% [1..10] Feet 10% [1..10] Arms 10% [1..10] Hands 10% [1..10] Shield 10% [1..10] Magic 10% [1..10] -------------------------------------------- PRICE GUIDELINES AC BODY LEGS HEAD ARMS FEET ARMOUR ---- ---- ---- ---- ---- ---- ------ +1 100 50 50 25 25 Cloth (Heavy) +2 200 100 100 50 50 Soft Leather +3 500 150 150 75 75 Studded Leather +4 1,000 500 500 250 250 Scale Mail +5 2,500 1,250 1,250 625 625 Chain Mail +6 7,000 3,500 3,500 1,750 1,750 Bronze Plate Mail +7 18,000 9,000 9,000 4,500 4,500 Plate Mail +8 35,000 17,500 17,500 8,750 8,750 Field Plate Mail +9 50,000 25,000 25,000 12,500 12,500 Full Plate +10 75,000 37,500 37,500 18,750 18,750 Anti Bomb ShieldPlate *Hands and shields should be regarded as arms. -------------------------------------------- IMPORTANT NOTICE Rare items may only exist in minimal quantities! Especially you should limit the occurence of magical protection, since it is easy to carry. ============================================================================ Weapons & Carrying capacity --------------------------- The weight of a weapon determines the strength needed to wield the weapon, these values should be used: STR Max. Weapon Weight Carrying capacity --- ------------------ ----------------- 0 0 0 1 1 3 2 2 3 3 3 10 4 4 25 5 5 55 6 6 80 7 7 90 8 8 100 9 9 100 10 10 115 11 11 115 12 12 140 13 13 140 14 14 170 15 15 170 16 16 195 17 18 220 18 20 255 No weapon may ever exceed 30 pounds in weight. Backstabbing is only possible with piercing weapons. No weapon may ever exceed 30 pounds in weight. No shop-produced weapon may exceed 2d8 in total damage or weigh more than 20 pounds. PRIMARY BUYABLE WEAPONS <PBW>: Name Damage Type Cost Weight --------------- ----- ---- ---- ------ Dagger 1d4 P 10 1 Small sword 1d6 P 60 3 Long sword 1d8 S 600 8 Wooden Club 1d3 B 12 3 War hammer 1d5 B 50 6 =========================================================================== FILE: "spells.txt" Spell numbers (slots) for magical objects. SPELL_ARMOR 1 'armor' SPELL_TELEPORT 2 'teleport' SPELL_BLESS 3 'bless' SPELL_BLINDNESS 4 'blindness' SPELL_BURNING_HANDS 5 'burning hands' SPELL_CALL_LIGHTNING 6 'call lightning' SPELL_CHARM_PERSON 7 'charm person' SPELL_CHILL_TOUCH 8 'chill touch' SPELL_COLOUR_SPRAY 10 'colour spray' SPELL_CONTROL_WEATHER 11 'control weather' SPELL_CREATE_FOOD 12 'create food' SPELL_CREATE_WATER 13 'create water' SPELL_CURE_BLINDNESS 14 'cure blindness' SPELL_CURE_CRITICAL 15 'cure critical' SPELL_CURE_LIGHT 16 'cure light' SPELL_CURSE 17 'curse' SPELL_DETECT_EVIL 18 'detect evil' SPELL_DETECT_INVIS 19 'detect invis' SPELL_DETECT_MAGIC 20 'detect magic' SPELL_DETECT_POISON 21 'detect poison' SPELL_DISPEL_EVIL 22 'dispel evil' SPELL_EARTHQUAKE 23 'earthquake' SPELL_ENCHANT_WEAPON 24 'enchant weapon' SPELL_ENERGY_DRAIN 25 'energy drain' SPELL_FIREBALL 26 'fireball' SPELL_HARM 27 'harm' SPELL_HEAL 28 'heal' SPELL_INVIS 29 'invis' SPELL_LIGHTNING_BOLT 30 'lightning bolt' SPELL_LOCATE_OBJECT 31 'locate object' SPELL_MAGIC_MISSILE 32 'magic missile' SPELL_POISON 33 'poison' SPELL_PROTECTION 34 'protection' SPELL_REMOVE_CURSE 35 'remove curse' SPELL_SANCTUARY 36 'sanctuary' SPELL_SHOCKING_GRASP 37 'shocking grasp' SPELL_SLEEP 38 'sleep' SPELL_GIANT_STRENGTH 39 'giant strength' SPELL_VENTRILOQUATE 41 'ventriloquate' SPELL_WORD_OF_RECALL 42 'word of recall' SPELL_CURE_POISON 43 'cure poison' SPELL_DETECT_HIDDEN 44 'detect hidden' SPELL_IDENTIFY 53 'identify' SPELL_FLY 56 'fly' SPELL_CONTINUAL_LIGHT 57 'continual light' SPELL_KNOW_ALIGNMENT 58 'know alignment' SPELL_DISPEL_MAGIC 59 'dispel magic' SPELL_CURE_SERIOUS 61 'cure serious' SPELL_CAUSE_LIGHT 62 'cause light' SPELL_CAUSE_CRITICAL 63 'cause critical' SPELL_CAUSE_SERIOUS 64 'cause serious' SPELL_FLAMESTRIKE 65 'flamestrike' SPELL_STONE_SKIN 66 'stone skin' SPELL_SHIELD 67 'shield' SPELL_WEAKEN 68 'weaken' SPELL_MASS_INVIS 69 'mass invis' SPELL_ACID_BLAST 70 'acid blast' SPELL_FAERIE_FIRE 72 'faerie fire' SPELL_FAERIE_FOG 73 'faerie fog' SPELL_PASS_DOOR 74 'pass door' SPELL_SUMMON 76 'summon' SPELL_INFRAVISION 77 'infravision' SPELL_CREATE_SPRING 80 'create spring' SPELL_REFRESH 81 'refresh' SPELL_CHANGE_SEX 82 'change sex' SPELL_GATE 83 'gate' SPELL_ACID_BREATH 200 'acid breath' SPELL_FIRE_BREATH 201 'fire breath' SPELL_FROST_BREATH 202 'frost breath' SPELL_GAS_BREATH 203 'gas breath' SPELL_LIGHTNING_BREATH 204 'lightning breath' SPELL_GENERAL_PURPOSE 501 'general purpose' SPELL_HIGH_EXPLOSIVE 502 'high explosive' SPELL_BLOCK_AREA 601 'block area' SPELL_WRITE_SPELL 602 'write spell' SPELL_HOMONCULOUS 603 'homonculous' SPELL_DEMON 604 'demon' SPELL_SHADOW 605 'shadow' SPELL_SHADE 606 'shade' SPELL_PHANTASM 607 'phantasm' SPELL_RIFT 608 'rift' SPELL_RIP 609 'rip' SPELL_TONGUES 610 'tongues' SPELL_UNDERSTAND 611 'understand' SPELL_OBJECT_INVIS 612 'object invis' SPELL_HASTE 613 'haste' HASTE 613 ENHANCED HEAL 615 ENHANCED REVIVE 616 ANIMATE DEAD 617 BANISH 618 ENHANCE OBJECT 619 MAGE SHIELD 620 DISPEL UNDEAD 621 DISPEL GOOD 622 REMOVE FEAR 623 FEAST 624 RESTORE 625 TREMOR 626 ENERGY SHIFT 627 INDUCTION 628 ILLUSION 629 MIRROR IMAGE 630 HALLUCINATE 631 STABILITY 632 ETHEREAL TRAVEL 633 ASTRAL PROJECTION 634 BREATH WATER 635 *** Object Programs ============================================== FILE: "daycare.are" Using the 'QQ' system ============================================== #AREA { 1 5} Sandman Dwarven Day Care~ #MOBILES #QQ00 youth dwarven dwarf~ the dwarven youth~ A young dwarf plays with a toy axe. ~ This is a young but not totally harmless creature. ~ 68 0 -5 S 3 17 69 1d4+30 1d6+3 50 400 6 8 1 >rand_prog 40~ wear all ~ >rand_prog 25~ mpemote swings his toy axe, almost hitting you! ~ >rand_prog 15~ mpemote says "I may be short, but I'm a mean one!" ~ | #QQ01 teddy bear~ a teddy bear~ A cute and fuzzy teddy bear stands here. ~ This is a tiny little bear with a heart on his chest. ~ 68 0 500 S 1 19 90 1d10+10 1d4+1 75 75 8 8 1 #QQ02 doll raggedy anne~ a raggedy anne doll~ A raggedy anne doll is sitting here. ~ You see a small little cute rag doll. ~ 68 0 300 S 2 18 79 2d5+19 1d5+2 250 200 6 8 1 #QQ03 soldier toy~ a toy soldier~ A toy soldier is standing here. ~ The toy is looking for target practice. ~ 68 0 -300 S 3 18 59 3d5+26 2d3+3 400 300 8 8 1 #QQ04 bear ugly~ the ugly bear~ An ugly stuffed bear stands here. ~ This is obviously a reject from the factory. He snarls and growls at you. ~ 68 0 -400 S 3 17 69 3d4+25 1d4+4 100 300 8 8 1 #QQ05 doll old~ an old doll~ An abused and old doll is here. ~ This doll has been hugged and played with until there is almost nothing left. ~ 68 0 -2 S 1 20 90 1d10+1 1d4+2 50 50 8 8 0 #QQ06 nanny~ the nanny~ An old wrinkled nanny stands here, looking over the little ones. ~ You see an old dwarven lady who has been hunched over with age. However, it appears that there is still some fight left in her. ~ 64 0 10 S 5 16 60 4d4+50 1d8+5 750 750 8 8 2 #QQ07 guard~ the armed guard~ An armed guard stands here looking lost. ~ This is a big mean bully who is tired of being lost in this maze. You suddenly think that you had better flee. ~ 70 8 -800 S 8 9 29 3d10+100 3d5+2 2000 2000 8 8 1 #QQ08 brat spoiled~ the spoiled brat~ A spoiled brat is crying here. ~ You see a little tyke who has always gotten what he wanted. You have the biggest urge to put him out of his misery. ~ 70 0 -400 S 1 18 90 2d4+15 2d2+1 2000 50 8 8 1 #0 #OBJECTS #QQ00 axe toy~ a toy axe~ An axe made of plastic lies here.~ ~ 5 0 8193 0 1 6 3 15 600 200 #QQ01 ring pink ice~ a pink ice ring~ A pink ice ring draws your eye.~ ~ 9 0 3 1 0 0 0 8 7000 2500 A 1 1 A 13 6 #QQ21 robe linen~ a linen robe~ A linen robe is crumpled into a ball here.~ ~ 9 0 1025 1 0 0 0 5 4000 2000 A 4 1 A 12 5 #QQ44 meat steak~ a juicy steak~ A juicy steak sits on a plate here.~ ~ 19 0 1 15 0 0 0 5 15 2 #QQ45 steak rotten~ a rotten steak~ A dry steak lies on the floor.~ ~ 19 0 1 4 0 0 1 5 14 1 #QQ46 potion amber~ an amber potion~ An amber potion sits in a corner.~ ~ 10 0 1 30 16 1 0 1 1500 500 #QQ47 gun toy~ a toy gun~ A toy gun with a sharp bayonet lies here.~ ~ 5 0 8193 0 2 3 7 5 1700 1000 #0 #ROOMS #QQ01 The Dwarven Drop Off~ This is where the dwarven mommies and daddies come to drop off their annoying little brats. You have the urge to leave. There is a sign here. ~ QQ 12 0 DDIR_SOUTH You see a large room full of noisy brats. ~ ~ 1 -1 QQ02 DDIR_NORTH ~ ~ 0 -1 6500 E sign~ This is an area for newbies, so have fun. -- Sandman ~ S #QQ02 Day Care Center~ You are in the north-east corner of the main part of the center. Toys and toddlers are all over the room. There is a kitchen to the east. ~ QQ 8 0 D0 You see the drop off. ~ ~ 0 -1 QQ01 D3 You see a large room full of noisy brats. ~ ~ 0 -1 QQ03 D2 You see a large room full of noisy brats. ~ ~ 0 -1 QQ04 D1 You see an extremely messy kitchen. ~ ~ 0 -1 QQ26 S #QQ03 Day Care Center~ You are in the north-west corner of the main part of the center. Toys and toddlers are all over the room. There is a bathroom to the west. ~ QQ 8 0 D1 You see a large room full of noisy brats. ~ ~ 0 -1 QQ02 D2 You see a large room full of noisy brats. ~ ~ 0 -1 QQ05 D3 You see a messy bathroom. ~ ~ 0 -1 QQ06 S #QQ04 Day Care Center~ You are in the south-east corner of the main part of the center. Toys and toddlers are all over the room. There is a playground to the east. ~ QQ 8 0 D0 You see a large room full of noisy brats. ~ ~ 0 -1 QQ02 D1 You see the playground. ~ ~ 0 -1 QQ10 D3 You see a large room full of noisy brats. ~ ~ 0 -1 QQ05 S #QQ05 Day Care Center~ You are in the south-west corner of the main part of the center. Toys and toddlers are all over the room. There is a staircase to the west. ~ QQ 8 0 D0 You see a large room full of noisy brats. ~ ~ 0 -1 QQ03 D1 You see a large room full of noisy brats. ~ ~ 0 -1 QQ04 D3 You see a staircase leading down. ~ ~ 0 -1 QQ07 S #QQ06 The Messy Bathroom~ You hold your nose as you realize you have made the worst mistake of your life. The air is rancid and the walls are stained. ~ QQ 8 0 D1 You see a large room full of noisy brats. ~ ~ 0 -1 QQ03 S #QQ07 The Staircase~ You stand on top of a staircase leading down, and wonder what mystery could lie down under. Beware! ~ QQ 8 0 D1 You see a large room full of noisy brats. ~ ~ 0 -1 QQ05 D5 You see the entrance to something. ~ ~ 0 -1 QQ12 S #QQ08 The Playground~ You are in the north-west corner of the playground. ~ QQ 0 2 D1 You see the playground. ~ ~ 0 -1 QQ09 D2 You see the playground. ~ ~ 0 -1 QQ10 S #QQ09 The Playground~ You are in the north-east corner of the playground. ~ QQ 0 2 D2 You see the playground. ~ ~ 0 -1 QQ11 D3 You see the playground. ~ ~ 0 -1 QQ08 S #QQ10 The Playground~ You are in the south-west corner of the playground. ~ QQ 0 2 D0 You see the playground. ~ ~ 0 -1 QQ08 D1 You see the playground. ~ ~ 0 -1 QQ11 D3 You see a large room full of noisy brats. ~ ~ 0 -1 QQ04 S #QQ11 The Playground~ You are in the south-east corner of the playground. ~ QQ 0 2 D0 You see the playground. ~ ~ 0 -1 QQ09 D3 You see the playground. ~ ~ 0 -1 QQ10 S #QQ12 Entrance to the Mini-Maze~ You stand in the entrance to a small, but confusing maze. You really hope that you don't get lost. ~ QQ 13 2 D1 ~ ~ 0 -1 QQ13 D4 You see some stairs. ~ ~ 0 -1 QQ07 S #QQ13 Mini-Maze~ You are in a small passage that looks just like every other one. ~ QQ 9 2 D3 ~ ~ 0 -1 QQ12 D2 ~ ~ 0 -1 QQ15 D1 ~ ~ 0 -1 QQ14 S #QQ14 Mini-Maze~ You are in a small passage that looks just like every other one. ~ QQ 9 2 D2 ~ ~ 0 -1 QQ16 D3 ~ ~ 0 -1 QQ13 S #QQ15 Mini-Maze~ You are in a small passage that looks just like every other one. ~ QQ 9 2 D0 ~ ~ 0 -1 QQ13 D1 ~ ~ 0 -1 QQ16 S #QQ16 Mini-Maze~ You are in a small passage that looks just like every other one. ~ QQ 9 2 D3 ~ ~ 0 -1 QQ15 D0 ~ ~ 0 -1 QQ14 D2 ~ ~ 0 -1 QQ24 S #QQ24 End of the Mini-Maze~ You stand at the end of your journey. There is a big sign here and you had better read it! ~ QQ 9 2 D0 ~ ~ 0 -1 QQ16 D2 ~ ~ 0 -1 QQ31 E sign~ If you are not level 6 or above, then don't go south!!!! It is a dangerous area, but congrats for getting this far - Sandman ~ S #QQ26 Messy Kitchen~ You stand in the kitchen and eating area of the day care center. Pots and pans are everywhere, while the toddlers continue to create chaos. ~ QQ 8 0 D3 You see a large room full of noisy brats. ~ ~ 0 -1 QQ02 S #QQ31 The End?~ You have reached the final lair. It is dominated by a huge five headed dragon (actually an overgrown brat with a Halloween mask). ~ QQ 9 2 D0 ~ ~ 0 -1 QQ24 S #0 #RESETS R 0 QQ13 4 R 0 QQ14 4 R 0 QQ15 4 R 0 QQ16 4 * M 0 QQ07 1 QQ24 M 0 QQ08 1 QQ31 M 0 QQ00 3 QQ02 E 1 QQ00 10 16 M 0 QQ01 2 QQ02 M 0 QQ02 2 QQ02 M 0 QQ06 2 QQ02 G 1 QQ46 20 G 1 QQ44 20 E 1 QQ21 20 12 * M 0 QQ00 3 QQ03 E 1 QQ00 10 16 * M 0 QQ00 3 QQ04 E 1 QQ00 10 16 M 0 QQ02 2 QQ04 M 0 QQ06 2 QQ04 G 1 QQ46 20 M 0 QQ05 2 QQ04 * M 0 QQ00 3 QQ05 E 1 QQ00 10 16 M 0 QQ02 2 QQ05 G 1 QQ45 20 M 0 QQ05 2 QQ05 E 1 QQ01 20 1 * M 0 QQ00 2 QQ08 M 0 QQ03 3 QQ08 E 1 QQ47 10 16 * M 0 QQ00 2 QQ09 M 0 QQ04 3 QQ09 M 0 QQ03 3 QQ09 E 1 QQ47 10 16 M 0 QQ03 3 QQ09 E 1 QQ47 10 16 * M 0 QQ00 2 QQ10 M 0 QQ04 3 QQ10 M 0 QQ03 3 QQ10 E 1 QQ47 10 16 M 0 QQ05 2 QQ10 * M 0 QQ04 3 QQ11 M 0 QQ03 3 QQ11 E 1 QQ47 10 16 M 0 QQ03 3 QQ11 E 1 QQ47 10 16 * M 0 QQ05 3 QQ06 M 0 QQ01 3 QQ06 S #SPECIALS M QQ00 spec_thief M QQ01 spec_thief M QQ02 spec_thief M QQ03 spec_thief M QQ04 spec_thief M QQ05 spec_thief M QQ06 spec_cast_cleric M QQ08 spec_thief S #$ ------------------------------------------------------------------------------ Area Creation Quick Reference Guide for Mortal Realms Presto 2/9/95 =============================================================================== #AREA {?? ??} Creator Area Name~ (creator's name should not exceed 7 letters) #NODEBUG (optional, allows weird door connections) #NOTELEPORT (optional, does not permit teleporting into area) #RESTRICT {lo hi} (optional, only players in the range low-high may enter) #HELPS <level of help> <keywords (all capitals)>~ <help text (multiple lines)> ~ 0 $~ #MOBILES #<virtual number of mobile> <mobile keywords>~ <mobile short name>~ <mobile long name> ~ <mobile description (multiple lines)> ~ <action flags> <affection flags> <alignment value> S <level> <body part> <attack part> <hit points (?d?+?)> <damage (?d?+?)> <gold> <race, if ACT_RACE set, else 0> <loaded position> <default position> <sex> * D (Displayable picture) \ Extra Values (unnecessary) * > (mob_progs) / #0 #OBJECTS #<v-number of object> <object keywords>~ <object short name>~ <object long name>~ <object description> ~ <item type> <item flags> <item wear locations> <4 values, dependant on item type> <weight> <value> <level> * E (stands for EXTRA DESCRIPTION) \ * <extra keywords>~ \ * <extra description (multiple lines)> \ * ~ \ * A (stands for APPLIES) Extra Values (unnecessary) * <apply type> <apply amount> / * C (stands for COMBAT USAGES) / * <attack type>~ / * <classes that may use object> / * D (stands for displayable picture) / #0 #ROOMS #<v-number of room> <room name>~ <room description (multiple lines)> ~ <area number> <room flags> <sector type> D<direction of door> <look description> (what you see when you look that direction) ~ <door name>~ <door type> <v-num of key that opens door> <v-num of connected room> * E (stands for EXTRA DESCRIPTION) \ * <extra keywords>~ \Extra Values (unnecessary) * <extra description (multiple lines)> / * ~ / S (denotes end of room) #0 #RESETS M <if-flag> <mob v-num> <max-num> <room v-num> (load mobile in room) G <if-flag> <object v-num> <max-num> (give object to mob) E <if-flag> <object v-num> <max-num> <wear-location> (equip object on mob) O <if-flag> <object v-num> <max-num> <room v-num> (load object in room) P <if-flag> <object v-num> <max-num> <container v-num> (put object in object) R <if-flag> <room v-num> <last exit to randomize> (randomize exits) S #SHOPS <shopkeeper v-num> <5 item_types to buy> <buy %> <sell %> <open> <close> 0 #$ =============================================================================== Mobile Values: ------------------------------------------------------------------------------- Action flags: ACT_IS_NPC 1 /* Auto set for mobs*/ ACT_SENTINEL 2 /* Stays in one room*/ ACT_SCAVENGER 4 /* Picks up objects*/ ACT_AGGRESSIVE 32 /* Attacks PC's*/ ACT_STAY_AREA 64 /* Won't leave area*/ ACT_WIMPY 128 /* Flees when hurt*/ ACT_PET 256 /* Auto set for pets*/ ACT_TRAIN 512 /* Can train PC's*/ ACT_PRACTICE 1024 /* Can practice PC's*/ ACT_WEAK 2048 /* Cannot carry anything*/ ACT_SMART 4096 /* Can talk, normal mobs can't*/ ACT_ONE_FIGHT 8192 /* Disappears after fight*/ ACT_NO_ORDER 16384 /* Cannot be ordered */ ACT_BODY 65536 /* Uses body parts */ ACT_RACE 131072 /* Allows race to be defined */ Affection Flags: AFF_BLIND 1 AFF_INVISIBLE 2 AFF_DETECT_EVIL 4 AFF_DETECT_INVIS 8 AFF_DETECT_MAGIC 16 AFF_DETECT_HIDDEN 32 AFF_SANCTUARY 128 AFF_FAERIE_FIRE 256 AFF_INFRARED 512 AFF_CURSE 1024 AFF_UNDERSTAND 2048 AFF_POISON 4096 AFF_PROTECT 8192 AFF_SNEAK 32768 AFF_HIDE 65536 AFF_SLEEP 131072 AFF_CHARM 262144 AFF_FLYING 524288 AFF_PASS_DOOR 1048576 AFF_STEALTH 2097152 AFF_CLEAR 4194304 AFF_HUNT 8388608 AFF_TONGUES 16777216 AFF_ETHEREAL 33554432 /* Makes the mobile absolutely invisible to system */ Alignment value: Good: 1000 to 350 Neutral: 350 to -350 Evil: -350 to -1000 Average Hit Points and Damage based on level: Level Ave HP Ave Dam 1 20 2 2 30 3 3 40 4 4 50 5 5 60 7 10 150 15 15 250 20 20 350 22 25 475 24 30 600 27 35 680 30 40 790 33 45 900 37 50 1300 41 55 1650 45 60 2000 50 65 2800 55 70 3500 60 75 4200 66 80 5000 72 85 6200 78 90 7800 85 95 10000 92 Body and Attack parts: (Attack parts are used in combat) To use these, set ACT_BODY (Body parts may be sliced off in death) BODY_HEAD 1 BODY_MOUTH 2 BODY_EYE 4 BODY_TORSO 8 BODY_HIP 16 BODY_LEG 32 BODY_ARM 64 BODY_WING 128 BODY_TAIL 256 BODY_TENTICLE 512 BODY_HORN 1024 BODY_CLAW 2048 BODY_HAND 4096 BODY_FOOT 8192 Gold Pieces: The number of gold pieces the mobile has on him. May be stolen or collected upon the death of the creature. Race: RACE_HUMAN 0 RACE_HALFLING 1 RACE_ELF 2 RACE_DROW 3 RACE_DWARF 4 RACE_GNOME 5 RACE_ORC 6 RACE_OGRE 7 Mobile position: POS_DEAD 0 /* Don't Use */ POS_MORTAL 1 /* Don't Use */ POS_INCAP S_MORTAL 1 /* Don't Use */ POS_IN