| … | |
… | |
| 18 | player BIRTH event, nothing much will happen with respect to the built-in |
18 | player BIRTH event, nothing much will happen with respect to the built-in |
| 19 | processing, but if you override from within a player TELL event, the tell |
19 | processing, but if you override from within a player TELL event, the tell |
| 20 | will be ignored (presumably your plug-in took care of it). |
20 | will be ignored (presumably your plug-in took care of it). |
| 21 | |
21 | |
| 22 | |
22 | |
| 23 | =head2 OBJECT EVENTS |
23 | =head2 ATTACHABLE EVENTS |
| 24 | |
24 | |
| 25 | Object events always relate to a specific object, which is always the |
25 | No time to document this, screw me. |
| 26 | first argument. Not all events get generated for every object, some are |
|
|
| 27 | specific to an object type. |
|
|
| 28 | |
26 | |
| 29 | =head3 instantiate (object init-args...) |
27 | =head3 instantiate (object init-args...) |
| 30 | |
28 | |
| 31 | An archetype was instantiated into an object. This event occurs when |
29 | An object was instantiated. |
| 32 | a map is loaded for the first time, or when the object was created |
30 | |
|
|
31 | For objects, this event occurs when a map is loaded for the first time |
|
|
32 | when it was instantiated from an archetype, or when the object was created |
| 33 | dynamically. The arguments are as specified in the C<attach> attribute of |
33 | dynamically. The arguments are as specified in the C<attach> attribute of |
| 34 | the object or archetype. |
34 | the object or archetype. |
| 35 | |
35 | |
| 36 | This is useful to initialise any per-object state you might need. |
36 | This is useful to initialise any per-object state you might need. |
| 37 | |
37 | |
| … | |
… | |
| 42 | server was reloaded. This event will only be generated if the object has |
42 | server was reloaded. This event will only be generated if the object has |
| 43 | attachments. |
43 | attachments. |
| 44 | |
44 | |
| 45 | =head3 clone (object destination) |
45 | =head3 clone (object destination) |
| 46 | |
46 | |
| 47 | An object with _attached extension_ is cloned, that is, a copy was |
47 | An object with _attached plugin_ is cloned, that is, a copy was made. The |
| 48 | made. The copy automatically has all attachments the original object |
48 | copy automatically has all attachments the original object had. The perl |
| 49 | had. The perl variables get copied in a shallow way (references are shared |
49 | variables get copied in a shallow way (references are shared between |
| 50 | between instances). If this is not the behaviour you need, you have to |
50 | instances). If this is not the behaviour you need, you have to adjust the |
| 51 | adjust the B<destination> object as you see fit. |
51 | B<destination> object as you see fit. |
|
|
52 | |
|
|
53 | =head3 destroy (object -- ) |
|
|
54 | |
|
|
55 | Invoked when the crossfire object gets destroyed, and only when the object |
|
|
56 | has a handler for this event. This event can occur many times, as its |
|
|
57 | called when the in-memory object is destroyed, not when the object itself |
|
|
58 | dies. |
|
|
59 | |
|
|
60 | |
|
|
61 | =head2 OBJECT EVENTS |
|
|
62 | |
|
|
63 | Object events always relate to a specific object, which is always the |
|
|
64 | first argument. Not all events get generated for every object, some are |
|
|
65 | specific to an object type. |
| 52 | |
66 | |
| 53 | =head3 add_bonus (item creator difficulty max_magic flags) |
67 | =head3 add_bonus (item creator difficulty max_magic flags) |
| 54 | |
68 | |
| 55 | A basic item has been created (e.g. for shops, monsters drops etc.) |
69 | A basic item has been created (e.g. for shops, monsters drops etc.) |
| 56 | that needs bonus values applied. The B<creator> object is a template |
70 | that needs bonus values applied. The B<creator> object is a template |
| … | |
… | |
| 62 | treasure generation continues as it would without this hook. |
76 | treasure generation continues as it would without this hook. |
| 63 | |
77 | |
| 64 | In general, if flags != 0 or creator != 0 you should just return and leave |
78 | In general, if flags != 0 or creator != 0 you should just return and leave |
| 65 | item generation to the standard code. |
79 | item generation to the standard code. |
| 66 | |
80 | |
| 67 | =head3 destroy (object) |
81 | =head3 remove (object -- ) |
| 68 | |
82 | |
| 69 | Invoked when the crossfire object gets destroyed, and only when the object |
83 | Invoked before the object is removed from its environment. |
| 70 | has a handler for this event. This event can occur many times, as its |
|
|
| 71 | called when the in-memory object is destroyed, not when the object itself |
|
|
| 72 | dies. |
|
|
| 73 | |
84 | |
|
|
85 | =head3 insert (object -- ) |
|
|
86 | |
|
|
87 | Called after the object was inserted into a container or map. |
|
|
88 | |
| 74 | =head3 tick (object) |
89 | =head3 tick (object -- ) |
| 75 | |
90 | |
| 76 | Invoked whenever the object "ticks", i.e. has positive B<speed_left>. Only |
91 | Invoked whenever the object "ticks", i.e. has positive B<speed_left>. Only |
| 77 | during ticks should an objetc process any movement or other events. |
92 | during ticks should an objetc process any movement or other events. |
| 78 | |
93 | |
| 79 | =head3 kill (object hitter -- ) |
94 | =head3 kill (object hitter -- ) |
| … | |
… | |
| 210 | |
225 | |
| 211 | =head2 PLAYER EVENTS |
226 | =head2 PLAYER EVENTS |
| 212 | |
227 | |
| 213 | Player events always have a player object as first argument. |
228 | Player events always have a player object as first argument. |
| 214 | |
229 | |
| 215 | =head3 reattach (player) |
|
|
| 216 | |
|
|
| 217 | Invoked whenever attachments/plug-ins need to get reattached to the player |
|
|
| 218 | object. This usually happens when the player gets loaded from disk, or |
|
|
| 219 | when the server is reloaded. |
|
|
| 220 | |
|
|
| 221 | =head3 birth (player) |
230 | =head3 birth (player) |
| 222 | |
231 | |
| 223 | Invoked as very first thing after creating a player. |
232 | Invoked as very first thing after creating a player. |
| 224 | |
233 | |
| 225 | =head3 quit (player) |
234 | =head3 quit (player) |
| … | |
… | |
| 293 | |
302 | |
| 294 | =head3 instantiate (map) |
303 | =head3 instantiate (map) |
| 295 | |
304 | |
| 296 | Original B<map> has been loaded (e.g. on first use, or after a map |
305 | Original B<map> has been loaded (e.g. on first use, or after a map |
| 297 | reset). |
306 | reset). |
| 298 | |
|
|
| 299 | =head3 reattach (map) |
|
|
| 300 | |
|
|
| 301 | Invoked whenever attachments/plug-ins need to get reattached to the |
|
|
| 302 | B<map>. This usually happens when the map was loaded from disk, or when the |
|
|
| 303 | server was reloaded. |
|
|
| 304 | |
|
|
| 305 | =head3 destroy (map) |
|
|
| 306 | |
|
|
| 307 | Invoked when the map object gets destroyed, and only when the map object |
|
|
| 308 | has a handler for this event. This event can occur many times, as its |
|
|
| 309 | called when the in-memory object is destroyed, not when the object itself |
|
|
| 310 | dies. |
|
|
| 311 | |
307 | |
| 312 | =head3 swapin (map) |
308 | =head3 swapin (map) |
| 313 | |
309 | |
| 314 | Invoked when a previously swapped-out temporary B<map> has been loaded again. |
310 | Invoked when a previously swapped-out temporary B<map> has been loaded again. |
| 315 | |
311 | |
| … | |
… | |
| 334 | =head3 leave (map player -- ) |
330 | =head3 leave (map player -- ) |
| 335 | |
331 | |
| 336 | Invoked whenever a player tries to leave the B<map>. Overriding means the |
332 | Invoked whenever a player tries to leave the B<map>. Overriding means the |
| 337 | player won't be able to leave. |
333 | player won't be able to leave. |
| 338 | |
334 | |
| 339 | =head3 trigger (map connection state) |
335 | =head3 trigger (map connection state -- ) |
| 340 | |
336 | |
| 341 | Invoked whenever something activates a B<connection> on the B<map>. If B<state> |
337 | Invoked whenever something activates a B<connection> on the B<map>. If B<state> |
| 342 | is true the connection was 'state' and if false it is 'released'. |
338 | is true the connection was 'state' and if false it is 'released'. |
| 343 | |
339 | |
| 344 | |
340 | |
| … | |
… | |
| 346 | |
342 | |
| 347 | These events are very similar to player events, but they are might be |
343 | These events are very similar to player events, but they are might be |
| 348 | handled asynchronously as soon as the command reaches the server, even when |
344 | handled asynchronously as soon as the command reaches the server, even when |
| 349 | the player hasn't logged in yet (meaning there is no player yet). |
345 | the player hasn't logged in yet (meaning there is no player yet). |
| 350 | |
346 | |
|
|
347 | =head3 connect (client -- ) |
|
|
348 | |
|
|
349 | Called as soon as a new connection to the server is established. Should |
|
|
350 | not be overriden. |
|
|
351 | |
|
|
352 | =head3 addme (client -- ) |
|
|
353 | |
|
|
354 | The client sent an addme, thus ending the initial handshaking. If overriden, the server |
|
|
355 | will not send any response. |
|
|
356 | |
|
|
357 | =head3 reply (client replystring -- ) |
|
|
358 | |
|
|
359 | Called when the client submits a reply in the ST_CUSTOM state. Usually |
|
|
360 | handled internally by language plugins. |
|
|
361 | |
| 351 | =head3 exticmd (client string) |
362 | =head3 exticmd (client string -- ) |
| 352 | |
363 | |
| 353 | Like C<extcmd>, but can be called before a player has logged in. |
364 | Like C<extcmd>, but can be called before a player has logged in. |
| 354 | |
365 | |
| 355 | Programmable plug-ins usually handle this event internally. |
366 | Programmable plug-ins usually handle this event internally. |
| 356 | |
367 | |
