# CHANGES

CHANGES:
toolbar toggle changed for you and me. I'm a power user.  If you can find it, you can use it. *giggle*


CHANGES:
added file_small  (DOH!)  Don't ignore the warnings!!!


CHANGES:
deleted 0 default value in table roommain for set_outdoors


CHANGES:
scrapped file_small, as save names are shortened to 8 letters, and capitalized. *boggle*  Lousy 16 bit applications.


CHANGES:
door direction changed to automatically include room/ at the beginning, so all you need to type is the file name.  This works like exits now.


CHANGES:
added clear pulldown set_outdoors button on roommain small and large


CHANGES:
changed default value for set_light in table roommain to null, instead of 1, for baseroomstuffs.


CHANGES:
a return was added before "rm filename" because I was accidentally appending the new text into the old file because of a lack of a return on the end of the copy string.


CHANGES:
added the ability to edit a project group


CHANGES:
fudged with the add_item wizard some more.  It looks like it is fixed.  I dunno.  Maybe.


CHANGES:
destination for doors changed to an actual record number for sister room support.


CHANGES:
after 3 hours of frustration, here's the summary: sister doors supported in c_door, thecode, dswitch, and dirchange; roomdoor large and small changed to to/from; openforms updated to give all associated doors; doorhelp updated.  Brain fried.


CHANGES:
added "list items" to the add_item screen.  This allows you to see what items are in other rooms (particularly useful if you have your baseroom in the database).


CHANGES:
door code revisited.  Now you can have a west exit in a room with the name of "yardwest".  Doh!


CHANGES:
imported monster tables.  added switch for wandering and zmonster.


CHANGES:
added non-killables. Doh!  Who wants them anyway?


CHANGES:
changed the flag for the monster screen and the default inherit


# DOORATTR

QUESTION:
filename of the room to which door leads

REQUIREDSYNTAX:
Do not include .c, quotes. Just the filename.

NOTES:
In the room table of this database, you will have to provide another destination room.  It can be the same, but will allow the same door to be used in more than one room.  This field is included solely in case you want to generate just the door code without the room code.


DOCFILE:
/doc/room/door/D_LINKED:
DOOR PROPERTY
  D_LINKED - Two-way door (0 is one-way, 1 is two-way)

DESCRIPTION
  The D_LINKED property determines if the door is linked to the door which is
  "coming back the other way". If the door is linked, then when the door is
  opened, the door on the other side will also become opened. If a door is not
  linked, then any changes in the door (ie. smashed, unlocked) will not be 
  reflected in the room on the other side of the door.

  When a linked door is created, a corresponding door will be created in the
  room which the door leads to, with the same properties.

  The default is 1 (linked), and should only be changed if you are writing a
  one-way door.

SEE PROPERTIES
  D_LINK_EXCEPTION, D_LINKED_ROOM

SEE FUNCTIONS:
  door_linked_room, send_door_property


QUESTION:
Message when player knocks on the door - THIS ROOM

EXAMPLE:
# &0 on the door with your fist.@thud thuds


QUESTION:
Message when player knocks on the door - OTHER ROOM

EXAMPLE:
Someone pounds on the door from the other side.


QUESTION:
Array of properties which are not linked.

DOCFILE:
>1. What D_LINK_EXCEPT for and how do I use it?

When a property of one side of the door is change, this change is reflected in the door coming back the other way. By setting the property D_LINK_EXCEPT it is possible to make some properites completely isolated in the different rooms.

For example, you could create a door which has a D_LONG which changes on one
side, but by setting D_LINK_EXCEPT to ([D_LONG]), when the doors long description is changed in one side, it won't automatically be changed in the other side.  I think there is an example of it's use in /w/toshina/lib/door/doc/examples/


QUESTION:
Notify fail for going through a closed door.

DOCFILE:
/doc/room/door/D_NO_GO:
DOOR PROPERTY
  D_NO_GO  - String written when player can not go through a closed door 

DESCRIPTION
  This is the string written to a player when they attempt to move in the
  direction of a visible closed (including locked) door. It should be a message 
  explaining why it is not possible to go in that direction.  The default 
  is "The door is closed."

EXAMPLE
  "The strange wavering wall of light blocks your progress to the north."

SEE PROPERTIES
  D_NO_PEER

SEE FUNCTIONS
  use_door


DOCFILE:
/doc/room/door/D_NAME:
DOOR PROPERTY
  D_NAME - Name of door

DESCRIPTION
  The name of the door is used to identify the door in various messages 
  as well as in the extra look (See D_EXTRA_LOOK). It is also used to 
  calculate the alias list for the door (See D_ALIAS). This property is 
  best described by examples:

    "wooden door"
    "hidden trapdoor"
    "shimmering portal"

    (The default is simply "door")

  Do not include the direction to which the door is leading as this will be
  added automatically where needed. 

SEE PROPERTIES
  D_EXTRA_LOOK, D_ALIAS

SEE ALSO
  id_door, describe_door


QUESTION:
Long description of the door (eg. "It is a big door.")

DOCFILE:
/doc/room/door/D_LONG:
DOOR PROPERTY
  D_LONG - Long description of the door     

DESCRIPTION
  This is the string that will be given to the player when they look at the 
  door. Be careful about including information about the state of the door 
  (open, closed, locked) unless it is kept up to date with the actual state of 
  the door.

SEE PROPERTIES
  D_LOCK_LONG, D_EXTRA_LOOK, D_NAME, D_ALIAS

SEE FUNCTIONS
  look_door


QUESTION:
Long that appends to the room description

REQUIREDSYNTAX:
Should fit in this sentence, which is added to the long room description:  "There is <extra look 1>, <extra look 2> and <extra look 3>."

NOTES:
Needs a leading space " ".
Must include a direction or the pc will not know where the door is.  See the calculation notes if the man D_EXTRA_LOOK.

DOCFILE:
>2. D_EXTRA_LOOK requires a leading space, is this intentional, though not readily obvious?

I have a vauge memory of this making something more efficient somewhere.
I think it reduced the number of string additions which were to be done.
Perhaps this should be fixed in the doc.

/doc/room/door/D_EXTRA_LOOK:
DOOR PROPERTY
  D_EXTRA_LOOK - String to add to rooms long description

DESCRIPTION
  This is a string which is used to create the description of visible doors
  for the player. eg. "a sturdy door leading south"

  This description is displayed when the player types "look at doors" and is 
  appended to the long description of the room. The string returned should fit 
  in a sentence like:

  "There is <extra look 1>, <extra look 2> and <extra look 3>."

  Each of the <extra look>s will be the extra look for a door.

  The string should describe the state (see D_STATE) of the door, unless you 
  have a special reason for doing otherwise. For this reason, you should
  probably calculate this property, rather than setting it. (See function 
  query_door_property) and the example below.

EXAMPLE

  mixed query_door_property(string door, int property)
  {
    /* We want to change what is returned for the extra look for the */
    /* east door, which goes into a hut.                             */
    if (door == "east" && property == D_EXTRA_LOOK)
    {
      /* This is the property we want to calculate */
      return ::query_door_property("east", D_EXTRA_LOOK) + " into the hut";
      /* It will now add " into the hut" to the        */
      /* extra look of the door, giving something      */
      /* like: "wooden door leading east into the hut" */
    }
    /* We do not want to do anything with this property/door, so */
    /* let the usual function handle it.                         */
    return ::query_door_property(door, property); 
  }

SEE PROPERTIES
  D_NAME, D_STATE

SEE FUNCTIONS
  door_status, describe_doors, query_doors, query_door_property, long


QUESTION:
Array of aliases ({"wooden door", "west door", "west"})

NOTES:
Format like the add_items. Do not include ({, just quotes.

DEFAULTSTR:
Default uses the name parsed out. You only need this if you use something strange like portal or something.

DOCFILE:
/doc/room/door/D_ALIAS:
DOOR PROPERTY
  D_ALIAS - Array of aliases

DESCRIPTION 
  A door, like other things in the game should respond to a number of different
  aliases. By default, doors respond to a set of aliases based on the name 
  (see D_NAME) and direction of the door. For example, for a stone door which
  leads north will have the following aliases by default:

    "door", "stone door", "stone"

  In addition, the id_door() function will handle the word "north", "northern"
  or "n" before any of the alises, or as the only word.

  If the word "the" is at the start of the string to be matched, it will be
  removed by id_door(), so you do not need to worry about including aliases
  such as "the stone door".

  These default aliases are suitable for normal doors which are named 
  "something door", however, if you have a special door with a name such as
  "shimmering green portal" you should set the alias list to:

    ({ "portal", "green portal", "shimmering portal" })

  If you set any door property you override the defaults meaning that in this 
  example, the portal will not have "door" as an alias.
  
SEE PROPERTIES
  D_NAME, D_EXTRA_LOOK

SEE FUNCTIONS
  id_door


QUESTION:
Initial state of door (OPEN, CLOSED, etc)

REQUIREDSYNTAX:
SMASHED, OPEN, CLOSED, LOCKED
All caps. These are constants.

DOCFILE:
/doc/room/door/D_TYPE:
DOOR PROPERTY
  D_TYPE - Initial state of door

DESCRIPTION
  This property defines the inital state of the door. When the door is created
  or reset, the property D_STATE will be set to equal D_TYPE.  Valid values for 
  this property are:

  SMASHED  Door is smashed open. Can not be closed.
  OPEN     Door is open, players can walk through it, close it, etc.
  CLOSED   Door is closed, but not locked.
  LOCKED   Door is closed and locked.

  The default value is CLOSED.

EXAMPLE

#include <door.h>
void create()
{
  ::create();
  create_door("e", ([D_DEST: "/w/wiz/area/room1.c", D_TYPE: LOCKED ]));
}

SEE PROPERTIES
  D_STATE, D_TYPE_AUTO, D_TYPE_HIDDEN

SEE FUNCTIONS
  create_door, reset_door


REQUIREDSYNTAX:
SMASHED, OPEN, CLOSED, LOCKED
Must be in caps.  These are constants.

DOCFILE:
/doc/room/door/D_STATE:
DOOR PROPERTY
  D_STATE - Position door is in (Open, Closed, Locked, Smashed)

DESCRIPTION
  This property indicates the current position of the door. Valid values are:
    SMASHED
    OPEN 
    CLOSED (but not locked)
    LOCKED  

  When a door is created or reset, then D_STATE will be set to D_TYPE. If a 
  door is hidden or not is handled by the property D_HIDDEN.
  
SEE PROPERTIES
  D_TYPE, D_HIDDEN, D_TYPE_HIDDEN

SEE FUNCTIONS
  smash_door, lock_door, unlock_door, open_door, close_door, search


DOCFILE:
Er. I still don't know how to set this message off.
>2. What D_IS_OPEN for and how do I use it?

This is the notify fail string for a door that is already open.


QUESTION:
Notify fail for opening a door already open.


QUESTION:
Notify fail for player too weak to open door

DOCFILE:
/doc/room/door/D_OPEN_WEAK:
DOOR PROPERTY
  D_OPEN_WEAK - Notify fail for too weak to open a door

DESCRIPTION
  This is the failure message given to a player when they are too weak to
  open a door. When opening a door, the players strength is compared to the
  value of the property D_OPEN_STR, if it is not greater then this message is
  given and the door can not be opened.

SEE PROPERTIES
  D_OPEN_MES
  D_CLOSE_STR
  D_OPEN_STR
  D_CLOSE_WEAK

SEE FUNCTIONS
  open_door, check_str


QUESTION:
Minimum strength player needs to open door

DOCFILE:
/doc/room/door/D_OPEN_STR:
DOOR PROPERTY
  D_OPEN_STR - Minimum strength to open door

DESCRIPTION
  This is the minimum strength required to open a door.  The player must have
  more strength than the value of this property to be able to open the door.
  If they do not have enough strength, then the door message D_OPEN_WEAK will
  be given to the player.

SEE PROPERTIES
  D_OPEN_WEAK, D_CLOSE_STR

SEE FUNCTIONS
  check_str


QUESTION:
Message given as door is opened - THIS ROOM


QUESTION:
Message given as door is opened - OTHER ROOM


EXAMPLE:
You see that the door is already closed.

DEFAULTSTR:
You can not close the door because it is already closed.

DOCFILE:
/doc/room/door/D_ALREADY_CLOSED:
DOOR PROPERTY
  D_ALREADY_CLOSED - Fail message given when trying to close a closed door

DESCRIPTION
  This is the string given when a player attempts to close a closed (or locked)
  door. 
  The default is: "You can not close the door because it is already closed."

SEE PROPERTIES
  D_AUTO_CLOSE_MES, D_CLOSE_MES, D_IS_CLOSED

SEE FUNCTION
  close_door


QUESTION:
Notify fail for player too weak to close door

EXAMPLE:
You are not nearly strong enough to open this door.

DOCFILE:
/doc/room/door/D_CLOSE_WEAK:
DOOR PROPERTY
  D_CLOSE_WEAK - Notify fail for too weak to close a door

DESCRIPTION:
  This is the failure message given to a player when they are too weak to
  close a door. This will happen if the players strength is less than or 
  equal to the the value of the property D_CLOSE_STR. This is checked in
  function check_str().

SEE PROPERTIES
  D_CLOSE_MES, D_CLOSE_STR, D_OPEN_STR, D_OPEN_WEAK

SEE FUNCTIONS
  close_door, check_str


QUESTION:
Minimum strength player needs to close door

DOCFILE:
/doc/room/door/D_CLOSE_STR:
DOOR PROPERTY
  D_CLOSE_STR - Minimum strength to close the door

DESCRIPTION
  This property is the minimum strength needed to close the door.  The default 
  is 0, which means that anyone can close the door.

  If the player does not have enough strength to close the door, then the door 
  message D_CLOSE_WEAK is given.

SEE PROPERTIES
  D_CLOSE_WEAK, D_OPEN_STR, D_CLOSE_MES

SEE FUNCTIONS
  close_door


QUESTION:
Message given as door is closed - THIS ROOM


QUESTION:
Message given as door is closed - OTHER ROOM


DOCFILE:
/doc/room/door/D_LOCK_LONG:
DOOR PROPERTY
  D_LOCK_LONG - Long desc of the doors lock

DESCRIPTION:
  This string is given to players when they look at the lock on the door.

SEE PROPERTIES
  D_TYPE, D_STATE, D_ALREADY_LOCKED, D_ALREADY_UNLOCKED, D_IS_LOCKED, 
  D_LOCK_MES, D_LOCK_QUAL, D_NO_LOCK, D_UNLOCK_MES

SEE FUNCTIONS
  look_door, unlock_door, lock_door, id_door_lock


QUESTION:
Your special code for a key (eg. 'pinestreet_gold')

DOCFILE:
/doc/room/door/D_KEY:
DOOR_PROPERTY
  D_KEY - Code for key             

DESCRIPTION
  This string property indicates which key fits the lock in the door. It is a 
  string which should be unique so that only your key will fit the door. To 
  make sure that the string is unqiue, you should put your name, or your domain
  name in the start of the string. For example, "testwiz_red_key" is a good
  key code.  When you create a key, you will have to set the same string in the 
  key.

  You can use the special constant KEY_BOLT for this property, which means that
  there is a lock which does not require a key, but that can just be bolted and
  unbolted.

  The default is 0, which means there is no lock.

SEE PROPERTIES
  D_ALREADY_LOCKED, D_ALREADY_UNLOCKED, D_IS_LOCKED, D_LOCK_LONG, D_LOCK_MES,
  D_LOCK_QUAL, D_NO_LOCK, D_UNLOCK_MES, D_TYPE, D_STATE

SEE FUNCTIONS
  unlock_door, lock_door


DEFAULTSTR:
You can not lock the door because it is already locked.

DOCFILE:
/doc/room/door/D_ALREADY_LOCKED:
DOOR PROPERTY
  D_ALREADY_LOCKED - Fail message for locking an already locked door

DESCRIPTION
  This is the string given to the player when they attempt to lock an
  already locked door. 
  The default is: "You can not lock the door because it is already locked."

SEE PROPERTIES
  D_ALREADY_UNLOCKED, D_IS_LOCKED, D_LOCK_MES, D_KEY, D_NO_LOCK, D_UNLOCK_MES

SEE FUNCTIONS
  lock_door


QUESTION:
Notify fail for door is already unlocked


DOCFILE:
/doc/room/door/D_TRAP:
DOOR PROPERTY
  D_TRAP - Function to call for trap

DESCRIPTION
  This string is the function which will be called when a player sets off a 
  trap in the door, due to a bungled lockpicking attempt.

  The default value is "trap", unless you have a good reason not to call your 
  function trap() then do not change this property. If everyone calls their
  function the default "trap" it will be easier to read other peoples code.

SEE PROPERTIES
  D_LOCK_QUAL, D_KEY
  
SEE FUNCTIONS
  lockpick_door


QUESTION:
Lock quality; 0 = easy to pick, 10 = hard to pick.

DOCFILE:
/doc/room/door/D_LOCK_QUAL:
DOOR PROPERTY
  D_LOCK_QUAL - Lock quality

DESCRIPTION
  This property determines how difficult the lock is to unlock using
  either a spell or a lockpick. A lock quality of -1 will mean that
  the lock is unpickable. Players will be given the door message
  D_IS_UNPICKABLE when they attempt to lockpick it.

SEE PROPERTIES
  D_LOCK_LONG, D_QUALITY

SEE FUNCTIONS
  lockpick_door


QUESTION:
Message when door is locked - OTHER ROOM


QUESTION:
Message when door is unlocked - THIS ROOM


QUESTION:
Message when door is unlocked - OTHER ROOM


QUESTION:
Notify fail for trying to open an automatic door

EXAMPLE:
You have just tried to open an automatic door.

NOTES:
Also kicks in when you try to unlock it.

DOCFILE:
>1. D_IS_AUTO is triggered when you try to unlock or open an automatic door. You've just tried to open an automatic door.

Yes, this is a bit of a tricky point which I do not think is
very well resolved at the moment. The problem here is that the
D_IS_AUTO message can be given for a number of different reasons.
I've been toying with solutions to this, I think that I will allow
$V or some symbol to mean "verb attempted by player". Currently the
only way to really code this properly is to check query_verb() and
return an appropriate string. This is not a good solution however.


QUESTION:
This door will automatically open and close?

REQUIREDSYNTAX:
Integer
0 - not automatic, 1 - automatic

DOCFILE:
/doc/room/door/D_TYPE_AUTO:
DOOR PROPERTY
  D_TYPE_AUTO - Door that opens automatically when player moves that direction.

DESCRIPTION
If this property is 1, then when the door is in a closed state, it will open 
automatically for players as they try and walk through the door.  

The default is 0, not automatic.

SEE PROPERTIES
  D_TYPE, D_TYPE_HIDDEN, D_IS_AUTO

SEE FUNCTIONS
  use_door


QUESTION:
Message given as door automatically opens - THIS ROOM


QUESTION:
Message given as door automatically opens - OTHER ROOM


QUESTION:
Message given as door automatically closes - THIS ROOM


QUESTION:
Message given as door automatically closes - OTHER ROOM


NOTES:
This feature does not seem to be working.

DOCFILE:
>4. D_IS_ALREADY_SMASHED Notify fail for door is already smashed.  This doesn't seem to exist yet.  Or have I screwed something up?

Hmm, this is D_ALREADY_SMASHED. Could by a problem in the documentation.
The true list of door defines is in /sys/door.h.


QUESTION:
Message that no damage was done - THIS ROOM


QUESTION:
Message that no damage was done - OTHER ROOM


QUESTION:
Message that damage was done - THIS ROOM


QUESTION:
Message that damage was done - OTHER ROOM


REQUIREDSYNTAX:
integer
0=cannot be smashed; 1=can be smashed


QUESTION:
Message if attempt to smash the door - THIS ROOM


QUESTION:
Message if attempt to smash the door - OTHER ROOM


QUESTION:
Message when one tries to kick the door - THIS ROOM


QUESTION:
Message when one tries to kick the door - OTHER ROOM


DEFAULTSTR:
4 * D_QUALITY.  D_QUALITY defaults to 10, so this defaults to 40.

DOCFILE:
/doc/room/door/D_HITS:
DOOR PROPERTY
  D_HITS - Hit points of door

DESCRIPTION
  This property is the number of hitpoints that the door has. Doors have hit-
  points similar to players. The door will start with a number of hitpoints, as
  players kick or smash the door, they will be reduced. When zero is reached
  the door will be smashed.

  When the door is reset, the hit-points are set back to the default value.

  The default for this property is based on the quality of the door. When a 
  door is reset or created, the D_HITS property is set to 4 times the quality 
  of the door. The default value for the quality is 10, (see D_QUALITY), so 
  the default for this property is 40.

SEE PROPERTIES
  D_QUALITY

SEE FUNCTIONS
  smash_door


QUESTION:
Door quality; 0 = easy to smash, 20 = hard to smash

DOCFILE:
/doc/room/door/D_QUALITY:
DOOR PROPERTY
  D_QUALITY - Quality of door, which determines how hard to smash it is

DESCRIPTION
  The quality of the door indicates how tough it will be to smash. When the
  door is created, or reset, it will have 4 * D_QUALITY hit points. The
  higher the quality of the door, the harder it is to cause damage to it.
  The power of the players assult on the door must be greater than or equal to
  the quality of the door. Power is calculated as:

  Power = (Strength * Weight)

  This is then modified depending on if the player is kicking or smashing the
  door. The default quality for a door is D_DEF_QUALITY, which is defined as 
  10. 

SEE PROPERTIES
  D_ALREADY_SMASHED, D_IS_SMASHABLE, D_IS_SMASHED, D_IS_UNSMASHABLE, 
  D_SMASH_MES, D_HITS

SEE FUNCTIONS
  smash_door, reset_door


QUESTION:
How well-hidden the door is; 0 = easy to 100 = hard

DOCFILE:
/doc/room/door/D_HIDE:
DOOR PROPERTY
  D_HIDE - How well hidden the door is

DESCRIPTION
  This property indicates how difficult the door is to find.  This is based on 
  the players searching ability. If the value of D_HIDE is less than their 
  searching ability, they will find the door. Players searching ability 
  normally varies from 0 to 100.

SEE PROPERTIES
  D_TYPE_HIDDEN, D_HIDDEN, D_HIDE_MES, D_FIND_MES

SEE FUNCTIONS
  search


DOCFILE:
/doc/room/door/D_TYPE_HIDDEN:
DOOR PROPERTY
  D_TYPE_HIDDEN - Initally hidden, hidden on reset

DESCRIPTION
  This property determines if a door will be hidden when initially created, and
  when it is reset. Hidden doors are found by players when they search. Before 
  being found players can not interact with hidden doors at all.  When a door 
  is reset or created, D_HIDEN will be set to D_TYPE_HIDDEN.

  Valid values are 0 for visible, and 1 for hidden. The default is 0.


SEE PROPERTIES
  D_HIDE, D_HIDE_MES, D_FIND_MES, D_TYPE

SEE FUNCTIONS
  reset, reset_door, search, id_door


DEFAULTSTR:
same as D_TYPE_HIDDEN, whose default is 0

DOCFILE:
/doc/room/door/D_HIDDEN:
DOOR PROPERTY
  D_HIDDEN - Currently hidden from players (0 - visible, 1 - hidden)

DESCRIPTION
  If the door is currently hidden, this property will equal 1. If the door is
  not currently hidden, this door will equal 0. The function id_door(), which 
  is supplied for the purposes of parsing player commands does not include 
  hidden doors. (ie. it will act as though hidden doors are not there when 
  working out which door the player is talking about.)

  The default is D_TYPE_HIDDEN (which in turn has a default of 0). When a door 
  is created or reset, D_HIDDEN will be set back to D_TYPE_HIDDEN. This 

EXAMPLE 1
  This is how to determine if the door to the east is hidden.

  if (query_door_property("east", D_HIDDEN))
  {
    /* It is hidden */
  }

EXAMPLE 2
  This is how to get a list of all the visible doors.

  string *visible_doors;
  visible_doors = enum_doors(D_HIDDEN, 0);

SEE PROPERTIES
  D_TYPE_HIDDEN, D_FIND_MES, D_HIDE, D_HIDE_MES

SEE FUNCTIONS
  search, reset_door, reset


QUESTION:
Message that the door is becoming hidden - THIS ROOM


QUESTION:
Message that the door is becoming hidden - OTHER ROOM


QUESTION:
Message when the door is found - THIS ROOM

EXAMPLE:
# &0 a hidden door in the floor.@find finds
##door_opened
# &0 a concealed passage to the north.@discover discovers

NOTES:
Code generator does not yet create the function for you.  Live with it.

DOCFILE:
/doc/room/door/D_FIND_MES:
DOOR PROPERTY
  D_FIND_MES - Message given when door is found

DESCRIPTION
  This property defines the messages that are given when a player finds a 
  hidden door.

EXAMPLES
  "You find a hidden door in the floor."
  "# &0 a concealed passage to the north.@discover discovers"
  "##door_opened" // Cause a function to be called.

SEE ALSO
  D_HIDE, D_HIDE_MES, D_TYPE_HIDDEN, communication

SEE FUNCTIONS
  search


QUESTION:
Message when the door is found - OTHER ROOM


QUESTION:
Notify fail for cannot peer through closed door

DOCFILE:
/doc/room/door/D_NO_PEER:
DOOR PROPERTY
  D_NO_PEER - Can not peer through closed door notify fail

DESCRIPTION
  This is the string given to a player when the attempt to peer in the
  direction of a closed or locked visible door. 
  The default is "The door is closed."

SEE PROPERTIES
 D_NO_GO

SEE FUNCTIONS
 peer


QUESTION:
This door can be peered through (eg: a force field)

REQUIREDSYNTAX:
1 - can peer through while closed. Sets off peering messages. 0 - can't.


QUESTION:
Message given as player peers through the door - THIS ROOM

DOCFILE:
>3. Peering through an open door does not set off D_PEER_MES.  Is this the way it is supposed to be?

Yes, you can use stop_peer() if you want to give a message, D_PEER_MES
is for peering through closed (and locked) doors.


QUESTION:
Message given as player peers through the door - OTHER ROOM


DOCFILE:
A NOTE FROM JERUSULUM:

What changed from the old version?  Doh!  Quite a bit, but it sort of works the same only without all the extra steps.  I am getting lazy in my old age.

Sister door code is now supported.  What's that mean?  Well, you only have to create the door once, going from room1 east to room2, and code is automatically included in room2 for going west to room1.  This was added to allow extra looks to reverse themselves automatically, as well as any other feature you want to add the direction to (such as description).  The door will be available from either room's main screen.  (Thanks, Buxley!)

It is doubtful that at the time of this release, I will have tested every single door combination, so if you come across an error or problem, let me know immediately.

In no way, shape, or form is this intended to allow sloppy programming and get you out of creating a base door in your base room.  Get a grip.  The basedoor doc is included here for your amusement and edification.

IMPORTANT:
You must include <door.h> in any room that uses a door in this format.  (But you know this, because my generator is not meant as a substitute for real programming.)

  Add a group of attributes button - *cackle* Ok, so you want a lock, but don't want to have to figure out all those darn commands.  Use this button to automatically add all records associated with Locks, Keys, Traps.  Then just fill in the records you want, and delete those that you don't want.  Very simple.  It's my favorite toy.

  The help button.  This screen.

  The close button.  Duh.

COMMENTS:
Periodically through here you will see something in the form of:
>#. question
answer
These are questions I asked Toshina and her responses. :)

FYI - The doors are currently listed in the reverse order to which they appear in the room code.

>5. When there are several doors in the room, perhaps these could be listed in the traditional order of exits in the long description of the room?

Yes, not a bad idea. Mudlib will be revisiting the area of room exits again
soon, because I think we can make some efficiency gains here.

>3. What's the most efficient way to get two messages into D_KNOCK_MES for this room:

   write("You knock on the door." and say(this_player()->query_name() + " knocks on the door.")? And so on, for all those other locations where that occurs?
Well, this type of property for doors uses message(). If you look at 'man communication', then you will see the string format that is to be used.

The default for this property is:
  ({"# &0 at the door.@knock knocks", "Someone knocks at the door.")}

Note that due to a limit in the communication package we use, (ie, message()) the second element of the array, which is sent to the room on the other side of the door is just a simple string, and so you can't use # and &0 and the other message stuff. This hasn't really proved a problem so far, but is a limitation I'd like to lift.


DOCFILE:
/doc/room/door/basedoor:
Baseroom Doors
---------------
The purpose of this file is to describe how to write a baseroom in which 
includes a base door. Since this is achieved using the function 
default_door_property, this is the tutorial for that function.  You should 
already know how to create a door, and what a baseroom is. Baserooms are 
briefly explained here anyway.  A baseroom is a room in which you put code 
which is common to your whole area. The rooms in the area inherit the 
baseroom, and then further customise it. That way you do not need to 
explicitly code some common features into every room. 

A basedoor will contain the common features across most doors in your area.  
For example, your dwarven caverns may have doors which are made of stone, 
and are unsmashable. Also, doors which go either "up" or "down" are not
stone, but "trap doors".  Coding a basedoor does not limit what sort of 
doors you have. If you want a smashable wooden door, you can still do that.

Default Properties
------------------
When you create a door, you do not need to set all the properties. What 
happens to the properties that you do not set? They use the defaults. Where
does it get the defaults from? When the value of a door property is queried
and it has not been explicitly set in the room, it is found by calling the
function door_default_property.  Here is the prototype for this function:

mixed door_default_property(string door, int mixed);

Now, if you put this function in your baseroom, it will get called whenever
the code for doors needs to know the value of a property that has not been
explicitly set. You can override this function to create your own set of
defaults. For properties which you are happy with the inbuilt default, call
the function as defined in room, using the :: syntax. Here is a commented
example.

Example:
--------

/* Door.h is required for the property constants, and some value */
/* constants.  Always include this when using doors.             */
#include <door.h>
inherit "room/room";

mixed door_default_property(string door, int property)
{
  /* Determine if this is a property */
  /* that we want to set an area     */
  /* default for.                    */

  switch(property)
  {
    case D_NAME:
      if (door == "up" || door = "u" || door = "d" || door = "down")
      {
        /* The default name for up and down doors is "trap door" */
        return "trap door";
      }
      /* the default for other doors is "stone door" */
      return "stone door";
    case D_TYPE_SMASHABLE:
      /* By default, doors are not smashable */
      return 0;

    /* Set some more properties here if you want by adding more cases */

  }

  /* If we reach this point, it is not one of the properties for   */ 
  /* which we want to set a default for, call the function that we */
  /* have overridden. You must do this for properties for which    */
  /* you do not give your own default.                             */

  return ::door_default_property(door, property);
}

The first argument (the door) is passed in specifically so that you can
call query_door_property() in this function. This is useful for messages
where you might want to query the name of the door, or the state of the
door. However, be careful that you do not get stuck in a loop by having
one properties which queries another property which queries the first
property, etc.


DOCFILE:
/doc/room/door/D_NAME.old:
DOOR PROPERTY
  D_NAME - Name of door

DESCRIPTION
  The name of the door will be used to identify the door in various messages,
  as well as the extra look (See D_EXTRA_LOOK). It also is used to calculat the
  alias list for the door (See D_ALIAS). This property is best described by
  examples:

    "wooden door"
    "hidden trapdoor"
    "shimmering portal"

  Do not include the direction in which the door is leading, as this will be
  added automatically where needed. 

  The default is simply "door".

SEE ALSO
  D_EXTRA_LOOK, D_ALIAS

SEE FUNCTIONS
  id_door, describe_doors


DOCFILE:
/doc/room/door/door_intro:
Introduction to Doors
---------------------
Doors are special exits which may be opened and closed, locked trapped and 
so on. While the word 'door' is used throughout, by customising a door, it 
may become a magical portal, or a hidden crack in the rock face of a cliff. 
The aim of this file is to present a few examples so that you will be able 
to read the help on the properties, and then create doors of your own.

Example 1: Simple door
----------------------
Ok, so you just want to make a simple door, and get on with your area. This 
example door shows all that is required to put the simplest possible door 
into your room. At the top of your file, put a bit in like this:

#include <door.h> 

Then, add a line like this in your create() function:

  create_door("east", ([D_DEST:"/w/testwiz/area/hall"]) );

This will create a door to the east. When the player goes through the door, 
they will be in "/w/testwiz/area/hall". What is going on here will be explained 
in more detail below. 

Referring to doors
------------------
Every function which involves doors has to know which door is being refered 
to. Doors are always refered to based on the direction in which they go. This
means that it is not possible to have two doors going in the same direction in
one room.

What is a property?
-------------------
A property is a feature of a door which may be set and queried. Most 
properties have sensible defaults, so you do not need to set them yourself.  
For example, there is a property which is the name of the door, one which 
describes its current position (closed, open). There are man pages for the 
individual properties, and they are listed in 'man door_properties'.

In the above example, D_DEST is the property which determines to which room 
the door leads. The value of this property is "/w/testwiz/area/hall".

When creating a door, you may specify the properties which you wish to give 
specific values to. Some of the most commonly used properties 
are listed below. 

These will help with understanding example two below.

D_NAME    The name of the door for use in descriptions.
D_DEST    The filename of the room on the other side of the door.
D_TYPE    The inital state (position) of the door. (eg. is it opened?)
D_LONG    The long description of the door.
D_KEY     A code indicating which key opens the door.
D_HITS    The number of hit-points the door currently has.

door.h
------
All the properties are constants which are defined in door.h. This means that 
you must include door.h in any room which uses a property.

Example 2: Door with a few properties
-------------------------------------
This example of a door in which a few properties are set. The door leads 
the west and is wooden. It is of type SMASHED, which means that the door will 
initially be smashed. The long description has been set to provide a clue to 
the players when they examine the door.

void create()
{
  ::create();

  /* Some stuff */
  create_door("west", 
    ([ D_NAME : "wooden door",
       D_DEST : "/w/testwiz/area/horsering",
       D_TYPE : SMASHED,
       D_LONG : "The smashed wooden door hangs in two pieces.  "
         "You notice hoof shaped imprints in it."
    ]));
  /* Some more stuff */
}

Style
-----
A quick note on style at this point. It will be most readable if you place one 
property on each line when creating a door, as above. It makes it easy to look 
down the left hand column for a property, and quickly see it's value to the 
right. The string didn't fit on one line, so I split it.

Conclusion
----------
Doors are refered to using the direction in which they lead.  When creating a 
door, you can choose which properties of the door you wish to customise. You 
can customise any number of properties. To find out more about creating doors,
check out the door_properties file for a list of properties.


DOCFILE:
/doc/room/door/door_properties:
DOOR PROPERTIES

This file contains a summary of all the door properties. A door property is a
feature of a door that can be set or queried. "Message" properties contain an
array of two strings. The first string is given in the current room, then 
second (optional) string is sent to the room on the far side of the door.

ROOM LINKING
  D_DEST               filename of the room to which door leads
  D_LINKED             It's a two way door (Links two rooms)
  D_KNOCK_MES          Message when player knocks on the door  
  D_LINK_EXCEPT        Array of properties which are not linked.
  D_NO_GO              Notify fail for going through a closed door.

LONG, LOOK, NAME
  D_NAME               Name of door (eg. "wooden door")
  D_LONG               Long description of the door (eg. "It is a big door.")
  D_EXTRA_LOOK         Long that appends to the room description
  D_ALIAS              Array of aliases ({"wooden door", "west door", "west"})
  D_TYPE               Initial state of door (OPEN, CLOSED, etc)
  D_STATE              Current state of door (See: D_TYPE)

OPEN
  D_IS_OPEN            Notify fail for trying to open door 
  D_ALREADY_OPEN       Notify fail for door already open
  D_OPEN_WEAK          Notify fail for player too weak to open door
  D_OPEN_STR           Minimum strength player needs to open door 
  D_OPEN_MES           Message given as door is opened

CLOSE
  D_IS_CLOSED          Notify fail for trying to close door        
  D_ALREADY_CLOSED     Notify fail for already closed 
  D_CLOSE_WEAK         Notify fail for player too weak to close door
  D_CLOSE_STR          Minimum strength player needs to close door
  D_CLOSE_MES          Message given as door is closed

LOCKS, KEYS and TRAPS
  D_LOCK_LONG          Long description of the door's lock
  D_KEY                Your special code for a key (eg. 'pinestreet_gold')
  D_IS_LOCKED          Notify fail for locked door
  D_IS_UNPICKABLE      Notify fail for unpickable lock
  D_NO_LOCK            Notify fail for no lock
  D_ALREADY_LOCKED     Notify fail for door is already locked
  D_ALREADY_UNLOCKED   Notify fail for door is already unlocked
  D_TRAP               Function to call for a trap    
  D_LOCK_QUAL          Lock quality; 0 = easy to pick, 10 = hard to pick.
  D_LOCK_MES           Message when door is locked
  D_UNLOCK_MES         Message when door is unlocked

AUTOMATIC (SWINGING OR MAGICAL) DOORS
  D_IS_AUTO            Notify fail for automatic door
  D_TYPE_AUTO          This door will automatically open and close
  D_AUTO_OPEN_MES      Message given as door automatically opens
  D_AUTO_CLOSE_MES     Message given as door automatically closes

SMASH
  D_IS_SMASHED         Notify fail for smashed door
  D_IS_UNSMASHABLE     Notify fail for unsmashable door
  D_IS_ALREADY_SMASHED Notify fail for door is already smashed
  D_NO_DAMAGE_MES      Message that no damage was done
  D_DAMAGE_MES         Message that damage was done
  D_IS_SMASHABLE       0=cannot be smashed; 1=can be smashed
  D_TRY_SMASH_MES      Message if attempt to smash the door
  D_TRY_KICK_MES       Message when one tries to kick the door
  D_SMASH_MES          Message as door is broken
  D_HITS               Hit points of door
  D_QUALITY            Door quality; 0 = easy to smash, 20 = hard to smash

HIDE/FIND
  D_HIDE               How well-hidden the door is; 0 = easy to 100 = hard
  D_TYPE_HIDDEN        Initially hidden
  D_HIDDEN             Currently hidden
  D_HIDE_MES           Message that the door is becoming hidden
  D_FIND_MES           Message when the door is found

PEER
  D_NO_PEER            Notify fail for cannot peer through closed door
  D_TYPE_PEER          This door can be peered through (eg: a force field)
  D_PEER_MES           Message given as player peers through the door


DOCFILE:
/doc/room/communication:
The communication package consists of four functions :

void message(string mess)
void concat(string str1,str2)
void tell_others(string mess)
void tell_env(object *player, string mess)

This file is primarily used in room.c.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

message() :

The message-function is used to report the result of a player's actions to
himself and the other people in the room, he occupies. He will hear one
version, and they will hear another. In order to construct the two versions,
the string [mess] must be constructed carefully :

The string [mess] consists primarily of two parts :

    1) The format of the message.
    2) The verbs used in the message.

The first part of [mess] can again be composed of the following :

    1) Pronomen-identifier 1 : '#' (for 'you' 'he' 'she' or <name>)
    2) Pronomen-identifier 2 : '$' (for 'your' 'his' 'her' or <name>'s)
    3) Pronomen-identifier 3 : '%' (for 'you' 'him' 'her' or <name>)
    4) Pronomen-identifier 4 : '^' (for 'yourself' 'himself' 'herself')
    5) Pronomen-identifier 5 : '*' (for 'yours' 'his' 'hers')
    6) Verb-identifier      : '&<number>'
    7) Any normal text or spaces.

Let assume you want to tell the dwarf Thirak, that he kicks a frog, but the
frog bites him back. The first part of the [mess]-string should look
something like this :

    "# &0 the frog, but the frog bites %."

To supply the verbs for that statement, the second half of the
[mess]-string should look like this :

    "kick kicks"

To assemble the two parts we use '@'. This gives us :

    "# &0 the frog, but the frog bites %.@kick kicks"

If [message()] receives such a string it will tell Thirak :

    "You kick the frog, but the frog bites you."

Other people will hear :

    "Thirak kicks the frog, but the frog bites him."

More than one verb might occur in the message :

    "# &0 lift the stone, but # &1 got enough strength." +
    "@try tries haven't hasn't"

will result in Thirak hearing :

    "You try to lift the stone, but you haven't got enough strength.",

and others hearing :

    "Thirak tries to lift the stone, but he hasn't got enough strength."

Notice, that at second occurrence of the '#' "he" was used instead of
"Thirak". The same goes for type 2 and 3 of pronomen-identifiers.
First time they are used, a pronomen derived from the players name
will be used, and afterwards not.

NOTICE : Pronomen or verb-identifiers must be separated from other text by
white spaces.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

concat() :
The concat-function concationates (wauw) two strings taking into account the
first strings characteristics :

    1) If the first string is empty or ends in a '.', the second string is
       capitalized.
    2) A white-space ' ' is inserted between the strings, except in the case
       where the second string starts with a ','.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-


tell_others() :
This function will deliver the message to any objects contained in the
players environment (but the player himself), on the condition that there
is sufficient light there.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

tell_env(player,what) :

This function will tell 'what' to any objects contained in the environment
of 'player' (but 'player' himself).

You can also give an array of objects as an argument, so every object con-
tained in the array will be left out.
For example:
tell_env(({this_player(),object1,object2}),"...\n");

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Written for Deeper Trouble Mud by Raistlin (tjh@iesd.auc.dk)


# EMOTIONS

CAUSEDBY:
smiles at you
comforts you
stares deep into your eyes


CAUSEDBY:
hugs you
ruffles your hair playfully
cuddles you
tickles you playfully
sweeps you across the dance floor
gently runs his finger down your cheek
shakes your hand
thanks you
fondles you
holds you tightly
snuggles up to you
pats you on the head


CAUSEDBY:
pokes you
nudges you
taps you
pinches you


CAUSEDBY:
insults himself
sings about his tiny genitals
sings about her tiny genitals
sings about its tiny genitals
sings about what a boofhead he is
sings about what a boofhead she is
sings about what a boofheed it is
tries to knee you, without much effect
snarls at you. Aren't you scared?
wrings his own neck
wrings her own neck
wrings its own neck


CAUSEDBY:
disagrees.
shakes his head
shakes her head
shakes its head


CAUSEDBY:
looks very confused
looks at you very curiously
looks very curious
gazes at you with wide innocent eyes
peers at you quizzically
looks puzzled at you
looks puzzled
tries to look thoughtful but fails
frowns


CAUSEDBY:
glares at you
rolls his eyes at you
rolls her eyes at you
rolls its eyes at you
wants you to fuck off


CAUSEDBY:
cheers you enthusiastically
whistles appreciatively at you


CAUSEDBY:
arrives
bows gracefully
bows before you
curtseys gracefully


CAUSEDBY:
smiles happily
chortles in glee
gives a round of applause
cheers enthusiastically


CAUSEDBY:
kicks you
slaps you
bites you!
knee below your belt!
punches you!
spanks you!
tackles you!
You fall to the ground in a very unflattering way.
fingers around your neck and squeezes


CAUSEDBY:
calls you a
calls you the
sings about what a boofhead you are
sings about your tiny genitals
ignores you
tongue out at you
wants you to fuck off
mocks you outrageously
sneers at you
taunts you
spits on you
pukes all over you


CAUSEDBY:
kisses you
squeezes you fondly
gives you a deep and passionate kiss
whispers to you sweet words
licks you
nibbles on your ear


CAUSEDBY:
looks grossed out
doubles over and pukes
pukes all over you


CAUSEDBY:
fumes
groans loudly
growls
grumbles
grunts
snarls angrily
's face turns purple and steam starts to boil out of
steams in silence
mumbles to
snorts


CAUSEDBY:
is bored
absolutely HATES to interrupt
snores loudly
foot impatiently
yawns


CAUSEDBY:
bellows with pain
howls at you
howls in agony
starts moaning
exclaims, 'Ouch!'


CAUSEDBY:
complains about the miserable state of things to you
hums a depressing tune
burst into tears
cries on your shoulder
sniffs
sobs inconsolably
pouts
sulks in a corner


CAUSEDBY:
cowers in a corner
cringes in terror
panics and looks for a place to hide
ducks out of the way.
recoil in horror
shivers from the cold
shudders
trembles and quivers like a bowlful of jelly
whimpers pitifully


CAUSEDBY:
tries in vain to confuse you
grins evilly
grins mischievously
drools, trailing tendrils of spit in
winks suggestively.
points at you
snaps his fingers


CAUSEDBY:
rolls his eyes and faints
rolls her eyes and faints
rolls its eyes and faints
gasps in astonishment
panics and looks for a place to hide
screams loudly
in disbelief
his tongue and pants
's face colour slowly darkens as
tears a lump of hair off the scalp in despair


CAUSEDBY:
grins evilly at you
growls at you
grins mischievously at you
snarls angrily at you.


CAUSEDBY:
ducks out of the way of you
cowers from you
recoils from you in fear


CAUSEDBY:
eyelashes seductively.
eyelashes at you seductively


CAUSEDBY:
burps rudely
lets off a real rip-roarer
drops his trousers
unzips his pants and shows you his pride
drops her trousers
unzips her pants and shows you her pride
drops its trousers
unzips its trousers and shows you its pride
pisses all over you
spits on the ground


CAUSEDBY:
goes 'Beep! Beep!'
wobbles his ears
rolls over and does
grimaces
wrinkles his nose
makes ruffling sounds
pokes his tongue out.
pokes her tongue out.
pokes its tongue out.


CAUSEDBY:
beeps you on the nose
screams 'DUH!' at you
grimaces at you
sniffs you
picks your nose


CAUSEDBY:
hops around
purrs contentedly
wiggles
yodels a merry tune


CAUSEDBY:
acks
duhs
apologises for using your oxygen
examines his knee


CAUSEDBY:
bounces around
head back and cackles with glee
flips head over heels


CAUSEDBY:
shadow boxes
flexes his huge muscles
flexes her huge muscles
flexes its huge muscles
pats himself on the back
struts proudly


CAUSEDBY:
ponders the situation
scratches his head
scratches her head
scratches its head
thinks carefully


CAUSEDBY:
kneels down and lets
falls to the ground and grovels in front of you
grovels before you
kneels before you
falls on his knees and shows how much he worships you
falls on his knees and shows how much she worships you
falls on his knees and shows how much it worships you


CAUSEDBY:
coughs noisily
smirks
raises an eyebrow
chuckles politely
sneers
boggles at the concept
boggles at you


# OPTIONS

OPTIONNOTE:
Default Save Directory.  Include the final "\".  For example: "c:\temp\" is acceptable (No quotes, of course!).


OPTIONNOTE:
"small" or "large".  Use large if you have a higher screen resolution.


OPTIONNOTE:
"yes" or "no".  If yes, rm filename.c, ed filename.c, i, ., x, and upd will be added to the code generation for rooms and monsters.


OPTIONNOTE:
"on" or "off".  If on, messages giving hints and instruction will pop up as you use the program.


OPTIONNOTE:
Do not include the word inherit or the quotes.


OPTIONNOTE:
"yes" or "no".  If yes, #include "../def.h" will be added to your code.


OPTIONNOTE:
"on" or "off".  If on, the attach data function will show each table as it attaches.


# OUTDOOR

OUTDOORDESC:
Indoors, can hear weather effects on the roof etc.


# ZMONSTER

ZMONSTER:
> more /w/piper/open/zmonster.doc

/****************************** ZMONSTER ***********************************/
 
Zmonster is a configurable inheritable that provides several advanced
features specifically aimed at making monsters somewhat intelligent and,
consequently, more deadly.  Your monster merely needs to
 
  inherit "/w/piper/inheritables/zmonster";
 
to have access to the zmonster features.  Please note that the zmonster
already inherits "obj/monster" and that you should NOT do so.
 
 
/* Following **************************************************************/
 
The zmonster possesses the capability to hunt down players who have
attacked it and is the one feature that defaults to ENABLED.  To set this
feature, use the lfuns:
 
  void set_move_allowed(int allowed);
  void set_panic_file(string file_name);
 
The set_move_allowed() function sets the maximum number of "moves" that
the zmonster will make as it chases the player to <allowed>.
 
The zmonster will chase the player through any standard exit or door, but
only if those exits are created with the add_exit() or add_door() functions.
Furthermore, the zmonster will not use the following type of exits:
   * the mages' dimension door, or
   * locked doors, or
   * hidden doors.
 
If the monster chases a player and either kills that player or fails to
find the player, the monster will retrace its steps and return to its
original room.  To disable the following feature, set <allowed> to 0.
 
<allowed> defaults to 2.
 
The set_panic_file() function creates a log file named <file_name> to log
any errors that occur due to monster movement, primarily when the monster
gets hopelessly  lost (for some reason) and is unable to return home.  This
is a rarity, but the log file keeps track and may aid in determining if
there is a non-standard exit
which is crippling the zmonster's following of
a player.
 
<file_name> defaults to a directory that you won't have write access to.
 
Not setting <file_name> should have little or no consequence; it is more for
debugging purposes than anything else and will not affect the actual use of
the zmonster.
 
EXAMPLE:
  set_move_allowed(4);
  set_panic_file("/w/traenil/log/panic");
 
 
/* Looting ****************************************************************/
 
Once it has killed its foe, the zmonster can be set to loot the corpse.
Plus, not only will it confiscate the equipment and money, it will evaluate
its new found loot and equip (or re-equip) itself with the "best" equipment.
To set this feature, use the lfuns:
 
  void set_grab_delay(int delay);
  void set_wield_grabbed(int boolean);
  void set_wear_grabbed(int boolean);
 
The function set_grab_delay() sets <delay> which is the length of time
between when a player dies and when the monster decides to loot the corpse.
If <delay> is 0, the monster will not loot the corpse.
 
The function set_wield_grabbed() sets the <boolean> flag to determine if the
monster will evaluate the weapons in its inventory and select the most
powerful after looting the corpse. Setting <boolean> to 1 enables this
feature, 0 disables.
 
The function set_wear_grabbed() sets the <boolean> flag to determine if the
monster will evaluate the armours in its inventory and select the most
protective after looting the corpse.  Setting <boolean> to 1 enables this
feature, 0 disables.
 
set_wield_grabbed() and set_wear_grabbed() are exclusive of each other, so
the monster can have either, neither, or both set to 1 or 0.
 
NOTE:
For the wield/wear functions, an intelligence check will be performed.
Please see the "Intelligence" section below for additional details.
 
For wearing armour, the zmonster evaluates its armours based on the gold
VALUE of the armours and then attempts to cover as much of its body as
possible.  It is possible then that the zmonster will mix-and-match its
armours in a non-optimal fashion (especially if the value of the armour
is not commensurate with its protective capabilities).  Tough.  Any other
algorithm required too much calculation.
 
For wielding weapons, the zmonster will compare weapon class.  However,
since many monster's weapon class is determined without actually
incorporating its wielded weapon this feature may or may not work
100% correctly.
 
<delay> defaults to 0.
weapon <boolean> defaults to 0.
armour <boolean> defaults to 0.
 
EXAMPLES:
  set_grab_delay(2);
  set_wield_grabbed(1);
  set_wear_grabbed(1);
 
 
/* Eating/Drinking ********************************************************/
 
The zmonster enables monsters to eat food and drink alcohol or potions to
aid in its healing.  To enable this feature, use the following lfuns:
 
  void set_alc_percent(int value);
  void set_pot_percent(int value);
  void set_food_percent(int value);
 
In each function, <value> is the percentage of the monster's maximum hit
points below which the monster will attempt to deal with the appropriate
healing object to improve it's condition.
 
The zmonster will go through its immediate inventory first, but will also
search through any containers it may hold (e.g. if you want your monster
to have potions but want to keep the potions away from the pilfering hands
of the rogues).
 
NOTE:
These functions MUST be called AFTER you set the hitpoints in the monster.
Calling them before the set_hp() will have bizarre and unpredictable
effects.
 
Also be aware that the zmonster has no way of determining whether that
nice looking potion in it's pack is really going to help it or not, but
will just go ahead and drink it anyway.
 
alcohol <value> defaults to 0 (disabled).
potion <value> defaults to 0 (disabled).
food <value> defaults to 0 (disabled).
 
EXAMPLES:
  set_alc_percent(80);
  set_pot_percent(33);
  set_food_percent(90);
 
 
/* Intelligence ***********************************************************/
 
Several features of the zmonster need to know the "intelligence" of the
monster.  Rather than simply use query_int(), there is a separate
intelligence factor to handle special cases.  For example, a blacksmith
may not be "intelligent" according to the high int value mages, but when
it comes to weapon and armour evaluation the blacksmith may be very
knowledgable.  To set the monsters weapon, armour and/or combat
intelligence, use the lfun:
 
  void set_smart(int val);
 
  <value> can be anywhere between 0 and 20, where 20 will always perform
action.  Obviously, the higher the smart <val> the higher chance that
the zmonster will attempt to wear/grab items.  Be aware that setting this
to 0 will disable the wear/grab functions even if you have those functions
activated.
 
<val> defaults to the intelligence of the monster.
 
 
EXAMPLE:
  set_smart(11);
 
 
/* Opponent selection *****************************************************/
 
The zmonster also incorporates all of the features of the ymonster.  A
special thanks to Bytre for his ymonster code.  This feature can be used
with the lfuns:
 
  void set_ymonster_capabilities(int boolean);
  void set_dying_level(int val);
 
The function set_ymonster_capabilities() sets the <boolean> flag.  If set
to 1, the zmonster will attack the opponent with the lowest armour class.
 
The function set_dying_level() sets <val> to be a threshold value of hit
points.  If an opponent falls below <val> the zmonster will switch to
that opponent in an attempt to finish that opponent off quickly.
 
<boolean> defaults to 0 (disabled).
<val> defaults to 0 (but does not apply unless boolean == 1).
 
EXAMPLES:
  set_ymonster_capabilities(1);
  set_dying_level(30); /* attack any player with less than 30 hit points */
 
 
/* Mindkill, Cloudkill, Snares ********************************************/
 
* Disbelieve mindkillers:
 
If you want the zmonster to be intelligent enough to recognize that it is
being attacked by the mindkiller spell, use this lfun:
 
  void set_disbelieve(int val);
 
where <val> is the percentage chance each heart_beat that the zmonster
will attempt to disbelieve the mindkill.  Please note that the zmonster
will ATTEMPT to disbelieve; it must still pass the appropriate disbelief
checks inherent to the mindkiller spell (see Dawg's code for more
specific information).
 
<val> defaults to 0 (disabled).
 
 
* Evade harmful objects:
 
If you want the zmonster to evade cloudkills (a popular method of killing
the older version of the zmonster among mages), use the lfun:
 
  void set_evade_harmful(int boolean);
 
where the <boolean> flag turns the feature on or off.  If boolean is set
to 1, the monster will leave the room filled with the cloud of poison gas.
The monster will periodically return to the room to see if the cloud has
gone away.
 
NOTE:
The monster will NOT leave the room if (1) it is currently attacking
something, or (2) you do not have movement enabled.  So, be a good little
wizard and make sure that movement is enabled before using this feature.
 
<boolean> defaults to 0 (disabled).
 
 
* Escape from snares:
If you want the zmonster to break out of ranger snares, use the lfun:
 
  void set_break_snare(int boolean);
 
where the <boolean> flag turns the feature on or off.  If boolean is set
to 1 and the monster happens to get caught in a snare, the zmonster will
break the snare and continue the chase.
 
EXAMPLES:
  set_disbelieve(45);
  set_evade_harmfull(1);
  set_break_snare(1);
 
 
Code last modified 9/19/96 - Piper
Documentation last modified 9/20/96 - Traenil
 
 
/***************
 * Function list
 
void set_move_allowed(int allowed); /* number of moves allowed */
void set_panic_file(string file_name); /* log file */
 
void set_ymonster_capabilities(int boolean); /* ymonster? */
void set_dying_level(int val);  /* attack player with hps < val */
 
void set_smart(int val);  /* relativeness smartness */
 
void set_alc_percent(int value); /* hps<(max_hps*value) --> drink alcohol */
void set_pot_percent(int value); /* hps<(max_hps*value) --> drink potion */
void set_food_percent(int value); /* hps<(max_hps*value) --> eat food */
 
void set_grab_delay(int delay); /* delay before looting corpse */
void set_wield_grabbed(int boolean); /* wield new weapons? */
void set_wear_grabbed(int boolean); /* wear new armour? */
 
void set_break_snare(int boolean); /* break snare if trapped? */
void set_evade_harmfull(int boolean);  /* avoid cloudkill? */
void set_disbelieve(int val); /* % chance to disbelieve mindkill */
 
******************/


