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)