mirror of
https://github.com/ldmud/ldmud
synced 2026-08-12 14:26:05 -04:00
3f18bab3da
Beyond typo fixes, most of these are just adding/removing spaces and rewrapping as necessary.
70 lines
2.5 KiB
Text
70 lines
2.5 KiB
Text
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
|
|
sequence of the init() functions looks like this:
|
|
|
|
l1->init() first init() of the destination will be called
|
|
n1->init() now iterate through 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)
|