| MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | SYNOPSIS |
| 2 | void init() |
| 3 | |
| 4 | DESCRIPTION |
| 5 | The H_MOVE_OBJECT0/1 implement the details of moving objects. |
| 6 | In older drivers, init() was called to handle the adding of |
| 7 | actions, and a lot of hook implementations still follow this |
| 8 | tradition. |
| 9 | |
| 10 | The main purpose of this function is to publish the commands |
| 11 | an object implements to other, living objects. Traditionally, |
| 12 | whenever a living object enters the vicinity of another |
| 13 | object, init() is called in the latter and this_player() will |
| 14 | point to the former object. This happens mutually should both |
| 15 | objects happen to be living. |
| 16 | |
| 17 | Or more formally: |
| 18 | |
| 19 | If the object O that moves is marked as living then first |
| 20 | call init() of the destination object D with this_player() |
| 21 | set to O. |
| 22 | |
| 23 | Then apply the two following rules for each object C |
| 24 | inside D: |
| 25 | |
| 26 | If C is marked as living then call O->init() with |
| 27 | this_player() set to C. |
| 28 | |
| 29 | If O is marked as living then call C->init() with |
| 30 | this_player() set to O. |
| 31 | |
| 32 | Finally, if D is marked as living then call O->init(), |
| 33 | with this_player() set to D. |
| 34 | |
| 35 | Starting with 3.2.1, the actual move handling became part of the |
| 36 | object library, so a given installation may implement any other scheme |
| 37 | of calling init(). |
| 38 | |
| 39 | One caveat: commands defined in the player object for the player |
| 40 | himself should not be defined in init(), as these commands would be |
| 41 | added to _other_ players whenever they happen to be nearby. Instead |
| 42 | use a separate function ("add_player_commands()" or so) which |
| 43 | is called during the creation of the player. |
| 44 | |
| 45 | EXAMPLE |
| 46 | (This example assumes a traditional implementation of the |
| 47 | movement handling) |
| 48 | |
| 49 | Lets say we have a object structure of living (l1 and l2) and |
| 50 | non living objects (n1 and n2) as the following: |
| 51 | |
| 52 | l1 |
| 53 | n1 |
| 54 | l2 |
| 55 | n2 |
| 56 | |
| 57 | If we now move another living object l3 into l1, the call |
| 58 | suequence of the init() functions looks like this: |
| 59 | |
| 60 | l1->init() first init() of the destination will be called |
| 61 | n1->init() now iterate throw the inventory of the destination |
| 62 | l3->init() |
| 63 | l2->init() |
| 64 | n2->init() |
| 65 | l3->init() and finally call init() of the object that has |
| 66 | been moved |
| 67 | |
| 68 | SEE ALSO |
| 69 | add_action(E), set_environment(E), environment(E), move_object(E), |
| 70 | hooks(C) |