Added public files
Roughly added all public files. Probably missed some, though.
diff --git a/doc/applied/__INIT b/doc/applied/__INIT
new file mode 100644
index 0000000..dc56f6c
--- /dev/null
+++ b/doc/applied/__INIT
@@ -0,0 +1,12 @@
+SYNOPSIS
+ __INIT
+
+DESCRIPTION
+ This function is constructed automagically by the parser at
+ compiler, if the parser was compiled with #define
+ INITIALISATION__INIT. This function is not intended to be
+ defined by the lpc objects, and never to be called from lpc
+ objects. This man page is here just for completeness.
+
+SEE ALSO
+ initialisation(LPC)
diff --git a/doc/applied/add_weight b/doc/applied/add_weight
new file mode 100644
index 0000000..5f8912f
--- /dev/null
+++ b/doc/applied/add_weight
@@ -0,0 +1,24 @@
+DEPRECATED
+SYNOPSIS
+ int add_weight(int w)
+
+DESCRIPTION
+ In compat mode, this function is used by the efun transfer().
+
+ An object that can contain other objects and is not a room
+ must define this function. It is called with the extra weight
+ of the object that is moved into it. If this is ok, then it
+ has to increment the local weight count, and return true.
+ Otherwise, return false, and the new object can not be entered
+ into this object.
+
+ The function is also called with the negative weight in the
+ object that the moving leaves.
+
+ Note that no set_weight() is required by the parser.
+
+HISTORY
+ Deprecated in LDMud 3.3 as transfer() has been deprecated.
+
+SEE ALSO
+ transfer(E), query_weight(A), prevent_insert(A)
diff --git a/doc/applied/applied b/doc/applied/applied
new file mode 100644
index 0000000..b7f63b9
--- /dev/null
+++ b/doc/applied/applied
@@ -0,0 +1,12 @@
+NAME
+ applied
+
+DESCRIPTION
+ This directory contains descriptions for the lfuns used by
+ Amylaar's version of the LPC parser.
+
+ These are functions that are applied by the parser to the LPC
+ objects on various occasions.
+
+SEE ALSO
+ efun(E), master(M), concepts(C), lpc(LPC), driver(D)
diff --git a/doc/applied/can_put_and_get b/doc/applied/can_put_and_get
new file mode 100644
index 0000000..5479832
--- /dev/null
+++ b/doc/applied/can_put_and_get
@@ -0,0 +1,20 @@
+DEPRECATED
+SYNOPSIS
+ int can_put_and_get()
+
+DESCRIPTION
+ In compat mode, this function is used by the efun transfer().
+
+ Define this function in objects that are neither living nor
+ rooms if you want to make it possible to put something into
+ current object.
+
+ Return true if ok, otherwise 0. That means that default is
+ that it is not possible to put something into an object.
+
+HISTORY
+ Deprecated in LDMud 3.3 as transfer() has been deprecated.
+
+SEE ALSO
+ transfer(E), prevent_insert(A)
+
diff --git a/doc/applied/catch_msg b/doc/applied/catch_msg
new file mode 100644
index 0000000..d244af4
--- /dev/null
+++ b/doc/applied/catch_msg
@@ -0,0 +1,19 @@
+SYNOPSIS
+ void catch_msg(mixed *|struct|mapping|object msg, object obj)
+
+DESCRIPTION
+ When say(), tell_room() or tell_object() are used with an
+ non-string as message, the value will be passed to catch_msg()
+ in all living objects that can hear it, instead of writing to
+ the user resp. sending to catch_tell(). This can be used to
+ implement communication protocols between livings. The second
+ argument denotes the object that has sent the message.
+
+HISTORY
+ LDMud 3.2.11 added tell_object() to the efuns calling this
+ lfun for symmetry reasons.
+ LDMud 3.3.686 added the use of a mapping/struct/object as message
+ value.
+
+SEE ALSO
+ say(E), tell_room(E), catch_tell(A)
diff --git a/doc/applied/catch_tell b/doc/applied/catch_tell
new file mode 100644
index 0000000..942a81a
--- /dev/null
+++ b/doc/applied/catch_tell
@@ -0,0 +1,22 @@
+SYNOPSIS
+ void catch_tell(string)
+
+DESCRIPTION
+ When a message is sent to an non-interactive object, via say(),
+ tell_object, tell_room() or write(), it will get to the function
+ catch_tell(string). The idea is to enable communications between
+ NPCs and from a user to an NPC.
+
+ Messages sent to an interactive object are also passed to that
+ object's catch_tell() lfun, _if it has one_. If the receiver
+ (or one of its shadows) doesn't have that lfun, the text is sent
+ to the socket directly. Only messages sent by an interactive
+ object to itself inside a catch_tell always written to the socket
+ immediately.
+
+ This allows to filter and process text before it is written
+ to a player.
+
+SEE ALSO
+ enable_commands(E), say(E), tell_object(E), tell_room(E),
+ write(E), snoop(E), catch_msg(A)
diff --git a/doc/applied/clean_up b/doc/applied/clean_up
new file mode 100644
index 0000000..47dfa73
--- /dev/null
+++ b/doc/applied/clean_up
@@ -0,0 +1,51 @@
+SYNOPSIS
+ int <lfun> (int refcount)
+ int <closure>(int ref, object ob)
+
+DESCRIPTION
+ The hook H_CLEAN_UP defines a lfun or a closure used to clean
+ up an object. In older drivers this was hardwired to the lfun
+ clean_up().
+
+ The function is applied by the driver when an object hasn't been
+ used for a long time, to give it a possibility to
+ self-destruct. The refcount <ref> passed as argument will be 0 for
+ clone objects, 1 for a simple loaded object, and greater when
+ the object is cloned or inherited by some existing object. It
+ is recommended not to self_destruct the object when the
+ reference count is greater than one.
+
+ By convention, a refcount < 0 is used if some other object
+ asks the called object to clean_up.
+
+ If the function is a closure, the second argument <ob> is the
+ object to clean up.
+
+ If the hook specifies a non-existing lfun, or if the call
+ returns 0, no further attempt to clean up this object will be done.
+
+ Returning a non-zero value is only recommended when the reason
+ why the object can't self-destruct is likely to vanish without
+ the object being touched, that is, when no local function is
+ called in it, (and in compat mode also when the object is not
+ being moved around).
+
+ A typical mud configuration defines the time to wait for
+ clean_up() so long that you can assert reset() has been
+ called since the object has been touched last time.
+
+EXAMPLES
+ A clone of /std/drink defines clean_up() to self-destruct if
+ it is empty, not carried a living being and not touched for
+ a long time.
+
+ A room that inherits /std/room defines clean_up() to
+ self-destruct if it is neither inherited nor used as a
+ blueprint, is empty and was not entered for a long time.
+
+HISTORY
+ Before 3.2.1, the function was hardwired to the lfun clean_up().
+
+SEE ALSO
+ reset(A), heart_beat(A), call_out(E), destruct(E), remove(A),
+ hooks(C)
diff --git a/doc/applied/create b/doc/applied/create
new file mode 100644
index 0000000..1056e13
--- /dev/null
+++ b/doc/applied/create
@@ -0,0 +1,29 @@
+SYNOPSIS
+ void create()
+
+DESCRIPTION
+ The H_CREATE_SUPER/_OB/_CLONE hooks define the function or closure
+ to be called when the driver creates a new object. In older
+ drivers this was hardwired to the lfun create(), and a lot of
+ hook implementations still follow this tradition.
+
+ This function will be called only once on creation of the
+ object (this is when the object will be loaded or cloned).
+ Inside this function all major initialization can be done. The
+ current user and the previous object are defined but the
+ object has no environment.
+
+EXAMPLE
+ object cloner;
+ void create() {
+ cloner=this_player();
+ }
+
+ Initialize the global variable to hold the one who
+ created/cloned the object.
+
+ For 3.2.1, the mudlib may be programmed to call other lfuns
+ than create() on an objects creation.
+
+SEE ALSO
+ reset(A), init(A), __INIT(A), initialisation(LPC), hooks(C), native(C)
diff --git a/doc/applied/drop b/doc/applied/drop
new file mode 100644
index 0000000..14f2bb1
--- /dev/null
+++ b/doc/applied/drop
@@ -0,0 +1,25 @@
+DEPRECATED
+SYNOPSIS
+ int drop(void)
+ int drop(int silently)
+
+DESCRIPTION
+ In compat mode this lfun is used by the efun transfer().
+
+ It is called to check if an object wants to be moved out of
+ the inventory of a living object. drop() should return 1 to
+ prevent dropping. This is the opposite of the get() function.
+ That is because if drop() is not defined, it will always be
+ possible to drop an object.
+
+ If the object self-destructs when drop() is called, be sure to
+ return 1, as the destructed item surely not can be dropped.
+
+ Most compat mode LPC libraries to define one argument for
+ drop. If silently is true, no messages should be written.
+
+HISTORY
+ Deprecated in LDMud 3.3 as transfer() has been deprecated.
+
+SEE ALSO
+ transfer(E)
diff --git a/doc/applied/exit b/doc/applied/exit
new file mode 100644
index 0000000..575fdd3
--- /dev/null
+++ b/doc/applied/exit
@@ -0,0 +1,21 @@
+SYNOPSIS
+ void exit(object ob)
+
+DESCRIPTION
+ This function was used in compat mode drivers in context
+ with moving objects. Nowadays objects are moved by means
+ of the H_MOVE_OBJECT0/1 hooks, and use of this lfun is
+ up to the mudlib.
+
+ This function was called in the old environment everytime a
+ living object ob leaves it.
+
+ The function this_player() will return a random value, don't
+ use it at this point.
+
+ WARNING: Using this function is EXTREMELY dangerous. A single
+ bug, and you are forever (i.e. until the next reboot occurs)
+ caught in the room.
+
+SEE ALSO
+ init(A)
diff --git a/doc/applied/get b/doc/applied/get
new file mode 100644
index 0000000..655a1b0
--- /dev/null
+++ b/doc/applied/get
@@ -0,0 +1,18 @@
+DEPRECATED
+SYNOPSIS
+ int get()
+
+DESRIPTION
+ In compat mode, this function is used by the efun transfer().
+
+ If an object wants control over when it is possible to pick it
+ up, i.e. moved into a living object, then it must define
+ get(), and return 1 if ok to pick up.
+
+ id() has been called before this to identify the object.
+
+HISTORY
+ Deprecated in LDMud 3.3 as transfer() has been deprecated.
+
+SEE ALSO
+ transfer(E), drop(A)
diff --git a/doc/applied/heart_beat b/doc/applied/heart_beat
new file mode 100644
index 0000000..9876b03
--- /dev/null
+++ b/doc/applied/heart_beat
@@ -0,0 +1,47 @@
+SYNOPSIS
+ void heart_beat()
+
+DESCRIPTION
+ This function will be called automatically every
+ __HEART_BEAT_INTERVAL__ seconds. The driver will call the function
+ directly in the object, even if the function is being shadowed.
+
+ The start and stop of heart beat is controlled by the efun
+ set_heart_beat(). Be careful not to have objects with heart
+ beat running all the time, as it uses a lot of driver
+ resources. If there is an error in the heart beat routine, the
+ heart beat will be turned off for this object and the
+ master function heart_beat_error() is called. If the call
+ to the master function returns a non-zero value, the heart beat
+ will be turned back on again.
+
+ The function this_player() will return this object, but only if
+ it is living. Otherwise, this_player() will return 0.
+
+ The function will be called only if there is at least one interactive
+ user in the game.
+
+ Note that error messages will be given to the current user
+ which will be the object itself or nobody.
+
+EXAMPLE
+ object owner;
+ void create() {
+ ...
+ owner=this_player();
+ set_heart_beat(1);
+ }
+ void heart_beat() {
+ tell_object(owner, "Your heart goes: BUM BUM\n");
+ }
+
+ We have to use tell_object() because write goes to the current
+ user and this can only be the object itself or nobody.
+
+HISTORY
+ LDMud 3.3.687 made the interval time configurable at driver compile
+ time (used to be 2 seconds fixed).
+
+SEE ALSO
+ set_heart_beat(E), call_out(E), enable_commands(E),
+ heart_beat_error(M)
diff --git a/doc/applied/id b/doc/applied/id
new file mode 100644
index 0000000..bdb1fb2
--- /dev/null
+++ b/doc/applied/id
@@ -0,0 +1,17 @@
+SYNOPSIS
+ varargs int id(string str, int lvl);
+
+DESCRIPTION
+ Let the object identify itself. If str matches an id of the
+ current object then return a none zero value.
+
+ This lfun is applied for the efun present().
+
+EXAMPLE
+ int id(string str) {
+ return "sword" == str || "sword of fire" == str;
+ }
+
+SEE ALSO
+ present(E)
+ id(L)
diff --git a/doc/applied/init b/doc/applied/init
new file mode 100644
index 0000000..17675da
--- /dev/null
+++ b/doc/applied/init
@@ -0,0 +1,70 @@
+SYNOPSIS
+ void init()
+
+DESCRIPTION
+ The H_MOVE_OBJECT0/1 implement the details of moving objects.
+ In older drivers, init() was called to handle the adding of
+ actions, and a lot of hook implementations still follow this
+ tradition.
+
+ The main purpose of this function is to publish the commands
+ an object implements to other, living objects. Traditionally,
+ whenever a living object enters the vicinity of another
+ object, init() is called in the latter and this_player() will
+ point to the former object. This happens mutually should both
+ objects happen to be living.
+
+ Or more formally:
+
+ If the object O that moves is marked as living then first
+ call init() of the destination object D with this_player()
+ set to O.
+
+ Then apply the two following rules for each object C
+ inside D:
+
+ If C is marked as living then call O->init() with
+ this_player() set to C.
+
+ If O is marked as living then call C->init() with
+ this_player() set to O.
+
+ Finally, if D is marked as living then call O->init(),
+ with this_player() set to D.
+
+ Starting with 3.2.1, the actual move handling became part of the
+ object library, so a given installation may implement any other scheme
+ of calling init().
+
+ One caveat: commands defined in the player object for the player
+ himself should not be defined in init(), as these commands would be
+ added to _other_ players whenever they happen to be nearby. Instead
+ use a separate function ("add_player_commands()" or so) which
+ is called during the creation of the player.
+
+EXAMPLE
+ (This example assumes a traditional implementation of the
+ movement handling)
+
+ Lets say we have a object structure of living (l1 and l2) and
+ non living objects (n1 and n2) as the following:
+
+ l1
+ n1
+ l2
+ n2
+
+ If we now move another living object l3 into l1, the call
+ suequence of the init() functions looks like this:
+
+ l1->init() first init() of the destination will be called
+ n1->init() now iterate throw the inventory of the destination
+ l3->init()
+ l2->init()
+ n2->init()
+ l3->init() and finally call init() of the object that has
+ been moved
+
+SEE ALSO
+ add_action(E), set_environment(E), environment(E), move_object(E),
+ hooks(C)
diff --git a/doc/applied/logon b/doc/applied/logon
new file mode 100644
index 0000000..97f0373
--- /dev/null
+++ b/doc/applied/logon
@@ -0,0 +1,28 @@
+SYNOPSIS
+ int logon (void)
+ int logon (int flag)
+
+DESCRIPTION
+ When the driver created a new connection (either by accepting
+ it or by creating it with net_connect()) and bound it to an
+ object, it then calls logon() in that object.
+
+ The method should return 0 on failure, and everything else on
+ success.
+
+ If the driver attempted to create a connection in the
+ background and failed, it will call logon(-1) in the intended
+ object to inform the mudlib about the failure.
+
+ If the master attempted a secure connection in connect(E) and
+ did not set an explicit TLS callback, the call to logon() won't
+ happen until the TLS handshake is complete. If the master set
+ a TLS callback, that will be executed in place of logon().
+
+HISTORY
+ LDMud 3.2.10 added the extended meaning for net_connect().
+ LDMud 3.2.13/3.3.713 streamlined the handling of secure connections
+ during logon.
+
+SEE ALSO
+ connect(M), net_connect(E), exec(E), tls_init_connection(E)
diff --git a/doc/applied/modify_command b/doc/applied/modify_command
new file mode 100644
index 0000000..4a4b2ef
--- /dev/null
+++ b/doc/applied/modify_command
@@ -0,0 +1,27 @@
+SYNOPSIS
+ int|string <name>(string cmd)
+
+DESCRIPTION
+ After set_modify_command(mob) was called for an interactive
+ object iob, all commands for that user will be passed to
+ mob-><name>(), and the return will then be checked for
+ actions. The actual name of the lfun to call is specified
+ by the H_MODIFY_COMMAND_FNAME hook - traditionally it's
+ 'modify_command'.
+
+ If the result is a string, it is the new command to execute
+ instead of the given one. Note that it is not possible to
+ make several commands from one this way!
+ If the result is a non-zero number, the given command is to
+ be ignored. In case of the closure/lfun setting this may
+ mean that the closure/lfun already executed it.
+ If the result is 0, the originally given command is to be
+ used.
+
+HISTORY
+ In 3.2.1@109 the name of the lfun to call must be specified
+ using the H_MODIFY_COMMAND_FNAME driver hook.
+
+
+SEE ALSO
+ set_modify_command(E), hooks(C)
diff --git a/doc/applied/parse_command_adjectiv_id_list b/doc/applied/parse_command_adjectiv_id_list
new file mode 100644
index 0000000..7745de9
--- /dev/null
+++ b/doc/applied/parse_command_adjectiv_id_list
@@ -0,0 +1,15 @@
+SYNOPSIS
+ string *parse_command_adjectiv_id_list(void)
+
+DESCRIPTION
+ Return all adjectives associated with this object.
+
+ Used by parse_command().
+
+EXAMPLE
+ string * parse_command_adjectiv_id_list() {
+ return ({ "iffish" });
+ }
+
+SEE ALSO
+ parse_command(E)
diff --git a/doc/applied/parse_command_id_list b/doc/applied/parse_command_id_list
new file mode 100644
index 0000000..4c8fc73
--- /dev/null
+++ b/doc/applied/parse_command_id_list
@@ -0,0 +1,10 @@
+SYNOPSIS
+ string *parse_command_id_list(void)
+
+DESCRIPTION
+ Return the normal singular names of this object.
+
+ Used by parse_command().
+
+SEE ALSO
+ parse_command(E), parse_command_pural_id_list(A)
diff --git a/doc/applied/parse_command_plural_id_list b/doc/applied/parse_command_plural_id_list
new file mode 100644
index 0000000..ee8d564
--- /dev/null
+++ b/doc/applied/parse_command_plural_id_list
@@ -0,0 +1,13 @@
+SYNOPSIS
+ string *parse_command_plural_id_list(void)
+
+DESCRIPTION
+ Return the plural names of this object.
+
+ If this function doesn't exist, the parser tries to pluralize
+ the names returned by parse_command_id_list().
+
+ Used by parse_command().
+
+SEE ALSO
+ parse_command(E), parse_command_id_list(A)
diff --git a/doc/applied/prevent_insert b/doc/applied/prevent_insert
new file mode 100644
index 0000000..a154ad9
--- /dev/null
+++ b/doc/applied/prevent_insert
@@ -0,0 +1,19 @@
+DEPRECATED
+SYNOPSIS
+ int prevent_insert()
+
+DESCRIPTION
+ In compat mode, this function is used by the efun transfer().
+
+ Define this function in objects that are neither living nor
+ rooms if you want to prevent to put something into current
+ object.
+
+ Return true if ok, otherwise 0. That means that default is
+ that it is not possible to put something into an object.
+
+HISTORY
+ Deprecated in LDMud 3.3 as transfer() has been deprecated.
+
+SEE ALSO
+ transfer(E), can_put_and_get(A)
diff --git a/doc/applied/query_weight b/doc/applied/query_weight
new file mode 100644
index 0000000..7d30b85
--- /dev/null
+++ b/doc/applied/query_weight
@@ -0,0 +1,13 @@
+DEPRECATED
+SYNOPSIS
+ int query_weight(void)
+
+DESCRIPTION
+ In compat mode this lfun is used by the efun transfer().
+ Not that no set_weight() is required by the parser.
+
+HISTORY
+ Deprecated in LDMud 3.3 as transfer() has been deprecated.
+
+SEE ALSO
+ transfer(E), add_weight(A)
diff --git a/doc/applied/remove b/doc/applied/remove
new file mode 100644
index 0000000..bb732b2
--- /dev/null
+++ b/doc/applied/remove
@@ -0,0 +1,21 @@
+SYNOPSIS
+ int remove(void)
+
+DESCRIPTION
+ remove() does some housekeeping to ensure consistency and then
+ destructs the current object.
+
+ This lfun is not applied by the parser, but by other objects
+ to tell the current object to self-destruct. remove() should
+ be supplied by the base classes of the library. Return 1 if
+ actually self-destructed, 0 otherwise.
+
+ An alternative way to ensure the housekeeping on destruction
+ is through the use of the master apply prepare_destruct().
+
+NOTE
+ Your actual mudlib may name this lfun differently, "remove()" is
+ just the traditional name.
+
+SEE ALSO
+ destruct(E), prepare_destruct(M)
diff --git a/doc/applied/reset b/doc/applied/reset
new file mode 100644
index 0000000..db08bec
--- /dev/null
+++ b/doc/applied/reset
@@ -0,0 +1,37 @@
+SYNOPSIS
+ void reset(int arg) /* compat mode */
+ void reset(void) /* native mode */
+
+DESCRIPTION
+ The H_RESET hook defines the function or closure to be called
+ when the driver needs to reset an object. In older drivers
+ this was hardwired to the lfun reset(), and a lot of hook
+ implementations still follow this tradition.
+
+ In compat mode, reset() was called with arg 0 after the object
+ was compiled, and with arg != 0 every once in a while. In
+ native mode, create() is called after compiling, and reset()
+ is called without arguments every once in a while.
+
+ So, if the argument is zero, the parser is running in compat
+ mode, and reset() may call your create() code. If create() is
+ called, you're on the new version and reset() is not called
+ for object creation. You may call reset() from create() and
+ vice versa, but make sure they do not call each other
+ recursive on either type of driver.
+
+ reset() will be called only in objects that have been used
+ since the last call to reset(), i.e. a function in them was
+ called (other than reset() or clean_up()), or it was moved
+ around.
+
+ This function can be used to reset the state of the object or
+ do some checks or what ever. The game wouldn't be fun if no
+ challenges remained.
+
+ For 3.2.1, the mudlib can be programmed to call an other lfun
+ than reset() to reset an object.
+
+SEE ALSO
+ clean_up(A), heart_beat(A), call_out(E), create(A), __INIT(A),
+ reset(H), hooks(C), initialisation(M), native(C)