area_current/castle/
area_current/gahld/
clans/
player/
player/c/
	      ==
	     = =             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