blob: cf330af8e04ec010f8b69ac7fbbf331ffe98b405 [file] [log] [blame]
Zesstra18626972017-01-31 10:38:27 +01001NotifyPlayerDeath()
2===================
3
4FUNKTION
5--------
Zesstra18626972017-01-31 10:38:27 +01006
7 void NotifyPlayerDeath(object victim,object killer,int lost_exp);
8
9DEFINIERT IN
10------------
Zesstra18626972017-01-31 10:38:27 +010011
12 /std/player/life.c
13
14ARGUMENTE
15---------
Zesstra18626972017-01-31 10:38:27 +010016
17 victim
18 Getoeteter Spieler.
19 killer
20 Objekt, welches den Spieler getoetet hat.
21 lost_exp
22 Erfahrungspunkte, die der Spieler durch den Tod verloren hat.
23
24BESCHREIBUNG
25------------
Zesstra18626972017-01-31 10:38:27 +010026
27 Diese Funktion wird aus dem Spielerobjekt heraus immer dann
28 aufgerufen, wenn der Spieler stirbt und zwar:
Zesstra8bf98802020-04-04 16:18:47 +020029
30 1. im Gegner, der den Spieler getoetet hat,
31 2. im Environment des getoeteten Spielers,
32 3. in der Gilde des Spielers,
33 4. in allen Objekten in diesem Environment und
34 5. in allen Objekten (auch innerhalb Containern) im Spieler.
35
Zesstra18626972017-01-31 10:38:27 +010036 Der Gegner wird hierbei nur einmal informiert, also bei letzteren
37 Faellen herausgefiltert, falls noetig!
38 Hauptaufgabe dieser Funktion ist es somit, auf Tode von Spielern zu
39 reagieren oder selbige einfach nur mitzuloggen.
40
41 Zu dem Zeitpunkt des Aufrufs dieser Funktion ist der Spieler noch _nicht_
42 Geist und noch _nicht_ im Todesraum - dies wird im Anschluss an den Aufruf
43 der NotifyPlayerDeath() durchgefuehrt.
44
Zesstra8bf98802020-04-04 16:18:47 +020045 Wenn ein Spieler an Gift stirbt, gibt es kein Killerobjekt - in dem Fall
46 ist <killer> 0. (P_KILLER im Opfer ist in diesem Fall "gift".)
Zesstra18626972017-01-31 10:38:27 +010047
Zesstra18626972017-01-31 10:38:27 +010048 Aufgerufen wird die Funktion aus '/std/player/life.c' mittels catch() und
49 werden mit limited() auf max. 150k (Gegner, Environment, Gilde) bzw. 80k
50 (alle anderen Objekte) Ticks beschraenkt.
51 Fehler in dieser Funktion haben somit keine negativen Auswirkungen
52 auf das Sterben des Spielers.
53
54RUeCKGABEWERT
55-------------
Zesstra18626972017-01-31 10:38:27 +010056
57 keiner
58
59BEISPIELE
60---------
Zesstra18626972017-01-31 10:38:27 +010061
62 Folgendes Beispiel demonstriert beispielsweise, wie man Tode von
63 Spielern mitloggen kann (das Beispiel ist hierbei auf den am
64 haeufigsten auftretenden Fall bezogen, dass nur das toetende Objekt
65 den Tod protokollieren soll):
66
Zesstra8bf98802020-04-04 16:18:47 +020067 .. code-block:: pike
68
Zesstra18626972017-01-31 10:38:27 +010069 void NotifyPlayerDeath(object dead, object killer, int lost_exp)
70 {
71 if ( intp(lost_exp) && objectp(dead) && objectp(killer) &&
72 killer==this_object() )
73 write_file( "/log/patryn/dead", sprintf(
74 "%s - %s von %s getoetet. XP: -%d", ctime(), getuid(dead),
75 killer->name(WEM), lost_exp) );
76 }
77
78 Bitte beachten: write_file() schreibt ohne Groessenbegrenzung in das
79 Logfile. Da dies auf Dauer bzw. in Gebieten mit hoher Log-Aktivitaet
80 zu Logfiles von enormer Groesse fuehren kann, ist die Verwendung
81 von write_file() nicht empfehlenswert. Ausnahmen koennen natuerlich
82 mit dem zustaendigen Regionsmagier abgesprochen werden, z.B. fuer
83 begrenzte Anwendung etwa bei sehr starken, selten besiegten Gegnern.
84
85 Weiterhin ist es empfehlenswert, das toetende Objekt (killer) nicht
86 im NotifyPlayerDeath() zu zestoeren, sondern etwas zeitversetzt,
87 damit nicht etwa im nachfolgenden NotifyPlayerDeath() eines anderen
88 Objektes (s.o. Reihenfolge) killer==0 ist.
89
90SIEHE AUCH
91----------
Zesstra18626972017-01-31 10:38:27 +010092
Zesstra8bf98802020-04-04 16:18:47 +020093 :doc:`Defend`, :doc:`do_damage`,
94 :doc:`../efun/catch`, :doc:`../efun/write_file`, :doc:`../sefun/log_file`
95 :doc:`../props/P_LAST_DEATH_PROPS`
Zesstra18626972017-01-31 10:38:27 +010096
Zesstra8bf98802020-04-04 16:18:47 +02009704.04.2020, Zesstra
Zesstra18626972017-01-31 10:38:27 +010098