ldmud-3.3.719/
ldmud-3.3.719/doc/
ldmud-3.3.719/doc/efun.de/
ldmud-3.3.719/doc/efun/
ldmud-3.3.719/doc/man/
ldmud-3.3.719/doc/other/
ldmud-3.3.719/mud/
ldmud-3.3.719/mud/heaven7/
ldmud-3.3.719/mud/lp-245/
ldmud-3.3.719/mud/lp-245/banish/
ldmud-3.3.719/mud/lp-245/doc/
ldmud-3.3.719/mud/lp-245/doc/examples/
ldmud-3.3.719/mud/lp-245/doc/sefun/
ldmud-3.3.719/mud/lp-245/log/
ldmud-3.3.719/mud/lp-245/obj/Go/
ldmud-3.3.719/mud/lp-245/players/lars/
ldmud-3.3.719/mud/lp-245/room/death/
ldmud-3.3.719/mud/lp-245/room/maze1/
ldmud-3.3.719/mud/lp-245/room/sub/
ldmud-3.3.719/mud/lp-245/secure/
ldmud-3.3.719/mud/sticklib/
ldmud-3.3.719/mud/sticklib/src/
ldmud-3.3.719/mudlib/deprecated/
ldmud-3.3.719/mudlib/uni-crasher/
ldmud-3.3.719/pkg/
ldmud-3.3.719/pkg/debugger/
ldmud-3.3.719/pkg/diff/
ldmud-3.3.719/pkg/misc/
ldmud-3.3.719/src/
ldmud-3.3.719/src/autoconf/
ldmud-3.3.719/src/ptmalloc/
ldmud-3.3.719/src/util/
ldmud-3.3.719/src/util/erq/
ldmud-3.3.719/src/util/indent/hosts/next/
ldmud-3.3.719/src/util/xerq/
ldmud-3.3.719/src/util/xerq/lpc/
ldmud-3.3.719/src/util/xerq/lpc/www/
ldmud-3.3.719/test/generic/
ldmud-3.3.719/test/inc/
ldmud-3.3.719/test/t-0000398/
ldmud-3.3.719/test/t-0000548/
ldmud-3.3.719/test/t-030925/
ldmud-3.3.719/test/t-040413/
ldmud-3.3.719/test/t-041124/
ldmud-3.3.719/test/t-language/
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)