/* SCRAPBOOK - Written by Ethereal Cashimor */
/* 181094: Started writing */
/* 191094: Added set order */
/* 201094: Whisky's suggestions implanted */

<clean_up><cleanup><clean up><reset><no_clean_up><property><room><door>
1. CLEAN_UP and it's problems

The lpMUD driver on which the Holy Mission runs has a feature called
'clean_up'. This means that the function 'clean_up' is called in each object
if it hasn't been referenced for a long time. This means that if an object
contains the function clean_up(), this will be called sometimes. 

If you have an object that you think is useless if it hasn't been references 
for some time, you might want to add your own clean_up() function. 
NOTE: Because of the fact that clean up is already in room, this is usually
      not necessary. But it might be useful to know how it works.
Such a function should typically destroy all objects which are in itself, and
then destruct itself. Of course, some checks would be welcome here, to avoid
important objects being destroyed. A sample clean_up() function is written
in /room/clean_up.c. It is important to know that clean_up() returns 1 if
the clean_up should not take place, and 0 if the clean_up was executed.

More important to know is that there actually IS a clean_up function in the
general room (/room/room.c) which is used everywhere in the MUD. So any
object in the MUD might acidentally be cleaned up by a room. This means that
for important objects (and rooms) it's good to know how to prevent 
accidental destruction.

For rooms this is simple, just add the property "no_clean_up" to the property
list. This can be done by putting:

property=({"no_clean_up"});

in the reset() function of your room. It's even possible to use the
replace_program() efun afterwards, if the rest of the room code allows this.
NOTE: Both Whisky and I dislike the replace_program() efun, but for different
      reasons. It's known to save space, but since the inherit files on this
      MUD lack several important constructs, you usually need additional
      functions and variables to make things interesting. So a room that
      can use replace_program() is a room not worth programming, because it's
      boring.
For all other objects it's less simple, since these don't have properties.
This lack of a useful feature might be compensated for in the future, but
at this time this problem is circumvented by adding the function 
no_clean_up() to the object. This function should return 1 if there should
be no clean up. Example:

no_clean_up() {
  return 1;
}

It is important to be sure that your object should be protected against clean
up, since the clean_up causes less memory usage, less crashes and a longer
uptime of the MUD. But of course, things like castle entrances should be
protected. Note that the /obj/door.c is protected normally already, so there
is no need to build special code in that.
<end>

<set order><set_name><monster><name><id><find_living><lower case><set_level>
2. Order of setting variables in monsters

There are various bugs that all are results from a wrong order of setting
of variables in monsters (and other objects). These bugs result in strange
settings of certain variables (not as intended) requiring rewriting of
functions like id(), which would normally not be necessary, and failure of
functions like find_living().

The reason why setting order is important, is because some set_ functions
do other set_s, thereby changing their settings. This was done to make sure
all important variables are set using a few simple calls, but it has the
drawback that there should be a certain order in which set_ calls should be
made.

The most important aspect of a monster (and an object) is the name. The name
is set using the well known function set_name(). This should always be the
FIRST set in an object, and may NOT be changed afterwards. If you need to
change the name, you're changing something so fundamental that you might as
well create a new object and destruct the old one. The name should be lower
case only: no capitals may be used, because this could confuse the driver
and make some functions unavailable. set_name calls set_short(), set_long()
and set_race() (the last only in case of monsters, of course).

For monsters, the next function to call would be the level, using
set_level(). set_level() does all kinds of modifications, making the
monster alive and such. It also sets HP and SP, and all statistics.
set_short() calls set_long(), so the set_long() should always come after
set_short(), and if the short is changed, the long should be changed as well.

There are probably more of these dependencies everywhere, be aware of them.
<end>
