Gesammelte Doku-Update unbekannter Herkunft
Mal wieder ein Sammel-Commit von Dingen, die niemand
committet hat.
Change-Id: I6564091f0f3c0a708247c85973bfcf5c0e23f1da
diff --git a/doc/lfun/AddCmd b/doc/lfun/AddCmd
index 088da28..ae02194 100644
--- a/doc/lfun/AddCmd
+++ b/doc/lfun/AddCmd
@@ -3,14 +3,11 @@
********
-AddCmd(L)
-=========
-
-
FUNKTION
========
- varargs void AddCmd(mixed cmd, mixed func, [mixed flag, [mixed id]]);
+ varargs void AddCmd(mixed cmd, mixed func, [mixed flag, [mixed
+ id]]);
DEFINIERT IN
@@ -28,14 +25,17 @@
ODER
Regel mit Triggerverb und noetigen Keywords/Synonymen
+
func
Funktionsname im selben Objekt oder Closure (Funktionspointer)
+
flag (optional)
Unscharfe Ausfuehrung == 1
ODER
Fehlermeldungen bei Nutzung von Regeln
+
id (optional)
eine ID, ueber die das Kommando eindeutig wieder geloescht
werden kann
@@ -46,199 +46,213 @@
Wenn ein Spieler im Einflussbereich des Objektes das Verb benutzt,
wird die entsprechende Funktion im Objekt aufgerufen:
- - die Verben sollten Imperative sein
- - die Funktion muss 1 fuer ERFOLG (und FPs!) und 0 sonst zurueckgeben
- (sonst werden evtl. weitere Funktionen mit diesem Kommandoverb gerufen)
- - innerhalb der Funktionen koennen Fehlermeldungen fuer den totalen
- Misserfolg des Kommandos mit notify_fail gesetzt werden
+
+ * die Verben sollten Imperative sein
+
+ * die Funktion muss 1 fuer ERFOLG (und FPs!) und 0 sonst
+ zurueckgeben (sonst werden evtl. weitere Funktionen mit diesem
+ Kommandoverb gerufen)
+
+ * innerhalb der Funktionen koennen Fehlermeldungen fuer den
+ totalen Misserfolg des Kommandos mit notify_fail gesetzt werden
(anstatt "Wie bitte?")
- AddCmd ist ein dynamischer Ersatz fuer add_action - im Gegensatz
- zu add_action koennen auch ohne erneuten Aufruf der init() neue
+ AddCmd ist ein dynamischer Ersatz fuer add_action - im Gegensatz zu
+ add_action koennen auch ohne erneuten Aufruf der init() neue
Kommandos hinzugefuegt werden.
AddCmd kann das Leben einfacher machen mit:
+
### REGELN: ###
- Bei komplexen Syntaxen kann ein String angegeben werden, der die
- _notwendigen_ (nicht die erlaubten!) Schluesselworte und deren
- zulaessige Synonyme beschreibt. Damit kann man sich einen grossen
- Teil eigener Auswertung ersparen.
- Nur wenn in richtiger Reihenfolge aus JEDER der durch & getrennten
- Synonymgruppen ein Wort im Spielerkommando enthalten ist, wird
- die zugehoerige Funktion ausgefuehrt.
+ Bei komplexen Syntaxen kann ein String angegeben werden, der die
+ _notwendigen_ (nicht die erlaubten!) Schluesselworte und deren
+ zulaessige Synonyme beschreibt. Damit kann man sich einen grossen
+ Teil eigener Auswertung ersparen.
- Trenner sind: | fuer Alternativen
- & fuer Konjunktionen
+ Nur wenn in richtiger Reihenfolge aus JEDER der durch & getrennten
+ Synonymgruppen ein Wort im Spielerkommando enthalten ist, wird die
+ zugehoerige Funktion ausgefuehrt.
- Beispiel:
- "ritz|ritze|schnitz|schnitze&mit&messer|schnitzmesser&"
- "herz|herzchen&rinde|baumrinde"
- wuerde z.B. durch
- "ritz mit dem Messer ein Herz in die Rinde des Baumes"
- "schnitz mit Messer Herzchen Baumrinde"
- "schnitz mit meinem Messer Herzchen in die harte Baumrinde"
- erfuellt werden.
+ Trenner sind: | fuer Alternativen
+ & fuer Konjunktionen
- Spezialregelteile sind:
- - @PRESENT: entspricht einem Objekt in Inv oder Env des Spielers
- - @ID: entspricht der ID des kommandobesitzenden Objektes
- (wo die Kommandomethode definiert ist, ist noch unwichtig)
- - @PUT_GET_DROP, @PUT_GET_TAKE, @PUT_GET_NONE:
- entsprechend den Filteroptionen fuer find_obs()
- ACHTUNG: Zusaetzliche Ziffern in Verbindung mit den @-Spezialregeln
- sind schlecht. @-Regeln versuchen gierig, Objekte exakt im
- Inventory zu matchen ("objekt 3" anstatt "objekt") und miss-
- interpretieren daher zB die 4 in "stopf objekt 3 in loch 4" als
- Teil des Objekt-ID-Strings.
- Interna: 3 Substrings fuer @PRESENT/@ID ("gruener kristall 2")
- 5 fuer @PUT... ("kristall 2 in beutel 3")
+ Beispiel:
+ "ritz|ritze|schnitz|schnitze&mit&messer|schnitzmesser&"
+ "herz|herzchen&rinde|baumrinde"
+ wuerde z.B. durch
+ "ritz mit dem Messer ein Herz in die Rinde des Baumes"
+ "schnitz mit Messer Herzchen Baumrinde"
+ "schnitz mit meinem Messer Herzchen in die harte Baumrinde"
+ erfuellt werden.
+
+
+ Spezialregelteile sind:
+
+ * @PRESENT: entspricht einem Objekt in Inv oder Env des Spielers
+ * @ID: entspricht der ID des kommandobesitzenden Objektes
+ (wo die Kommandomethode definiert ist, ist noch unwichtig)
+ * @PUT_GET_DROP, @PUT_GET_TAKE, @PUT_GET_NONE:
+ entsprechend den Filteroptionen fuer find_obs()
+ ACHTUNG: Zusaetzliche Ziffern in Verbindung mit den @-Spezialregeln
+ sind schlecht. @-Regeln versuchen gierig, Objekte exakt im
+ Inventory zu matchen ("objekt 3" anstatt "objekt") und miss-
+ interpretieren daher zB die 4 in "stopf objekt 3 in loch 4" als
+ Teil des Objekt-ID-Strings.
+ Interna: 3 Substrings fuer @PRESENT/@ID ("gruener kristall 2")
+ 5 fuer @PUT... ("kristall 2 in beutel 3")
### FEHLERMELDUNGEN (bei Anwendung von Regeln): ###
- Als dritter Parameter koennen auch Fehlermeldungen fuer jeweils
- fehlende Synonymgruppen (ausser der ersten - den Kommandoverben)
- angegeben werden. Sie werden in derselben Reihenfolge (!) wie die
- Synonymgruppen angegeben.
- Mit nicht von Spielern erfuellbaren Regeln und ^-Fehlermeldungen
- kann man auch ohne Ausfuehrung einer Funktion Texte an Spieler
- und Umgebung ausgeben. Siehe dazu AddCmd_bsp.
+ Als dritter Parameter koennen auch Fehlermeldungen fuer jeweils
+ fehlende Synonymgruppen (ausser der ersten - den Kommandoverben)
+ angegeben werden. Sie werden in derselben Reihenfolge (!) wie die
+ Synonymgruppen angegeben.
- Trenner sind: | zum Trennen der einzelnen Fehlermeldungen
- ^ um
- - die Auswertung (ab dieser Fehlermeldung!) mit
- "return 1;" zu beenden und
- - eine write^say-Meldung zu trennen und
- - (fuer funktionslose AddCmd auch FPs zu vergeben!)
+ Mit nicht von Spielern erfuellbaren Regeln und ^-Fehlermeldungen
+ kann man auch ohne Ausfuehrung einer Funktion Texte an Spieler
+ und Umgebung ausgeben. Siehe dazu AddCmd_bsp.
- Beispielfehlermeldungen fuer obige Regel:
- "Womit willst Du schnitzen?|Was willst Du schnitzen?|"
- "Wohinein willst Du das schnitzen?"
+ Trenner sind: | zum Trennen der einzelnen Fehlermeldungen
+ ^ um
+ - die Auswertung (ab dieser Fehlermeldung!) mit
+ "return 1;" zu beenden und
+ - eine write^say-Meldung zu trennen und
+ - (fuer funktionslose AddCmd auch FPs zu vergeben!)
- Es koennen in den Fehlermeldungen folgende Platzhalter benutzt
- werden:
- - @verb (ersetzt durch query_verb() ohne beendendes 'e')
- - @VERB (ersetzt durch capitalize(query_verb()) ohne beendendes 'e')
- - @WERx, @WESSENx, @WEMx, @WENx: siehe alles aus replace_personal()
- - @WE..1 ist immer der aktive Spieler
- - alle folgenden sind die matchenden Parameter der Spielereingabe
- - (x-1)<=Fehlermeldung (da x=1 Spieler und
- (x-1)>Fehlermeldungsobjekt nicht existent)
+ Beispielfehlermeldungen fuer obige Regel:
+ "Womit willst Du schnitzen?|Was willst Du schnitzen?|"
+ "Wohinein willst Du das schnitzen?"
- Ausfuehrungsbeispiel:
- AddCmd("ritz|ritze|schnitz|schnitze&mit&messer|schnitzmesser&"
- "herz|herzchen&rinde|baumrinde",#'fun,
- "Willst Du mit etwas @verben?|Womit willst du @verben?|"
- "Was willst du mit dem @WEM3 @verben?|"
- "Wohinein willst Du das @WEN4 schnitzen?");
- 1. "ritze" == "Willst Du mit etwas ritzen?"
- 2. "schnitz mit" == "Womit willst du schnitzen?"
- 3. "ritz mit messer" == "Was willst du mit dem messer ritzen?"
- 4. "ritze mit dem messer ein herz" ==
- "Wohinein willst Du das herz schnitzen?"
- 5. "ritze mit dem messer ein herzchen in die baumrinde"
- == Erfolg!
+ Es koennen in den Fehlermeldungen folgende Platzhalter benutzt
+ werden:
+
+ * @verb (ersetzt durch query_verb() ohne beendendes 'e')
+ * @VERB (ersetzt durch capitalize(query_verb()) ohne beendendes 'e')
+ * @WERx, @WESSENx, @WEMx, @WENx: siehe alles aus replace_personal()
+ * @WE..1 ist immer der aktive Spieler
+ * alle folgenden sind die matchenden Parameter der Spielereingabe
+ * (x-1)<=Fehlermeldung (da x=1 Spieler und
+ (x-1)>Fehlermeldungsobjekt nicht existent)
+
+ Ausfuehrungsbeispiel:
+ AddCmd("ritz|ritze|schnitz|schnitze&mit&messer|schnitzmesser&"
+ "herz|herzchen&rinde|baumrinde",#'fun,
+ "Willst Du mit etwas @verben?|Womit willst du @verben?|"
+ "Was willst du mit dem @WEM3 @verben?|"
+ "Wohinein willst Du das @WEN4 schnitzen?");
+ 1. "ritze" == "Willst Du mit etwas ritzen?"
+ 2. "schnitz mit" == "Womit willst du schnitzen?"
+ 3. "ritz mit messer" == "Was willst du mit dem messer ritzen?"
+ 4. "ritze mit dem messer ein herz" ==
+ "Wohinein willst Du das herz schnitzen?"
+ 5. "ritze mit dem messer ein herzchen in die baumrinde"
+ == Erfolg!
### UNSCHARFER AUSFUEHRUNG: ###
- Bei unscharfer Ausfuehrung wird die zugehoerige Methode auch dann
- ausgefuehrt, wenn das verwendete Verb ein Superstring ist und
- bisher noch nicht behandelt wurde.
- Dieses Verhalten sollte nur beim generellen Abfangen von
- Befehlsgruppen benutzt werden und ist ansonsten veraltet. Es
- entsprich add_action("fun","kommando",1).
+
+ Bei unscharfer Ausfuehrung wird die zugehoerige Methode auch dann
+ ausgefuehrt, wenn das verwendete Verb ein Superstring ist und
+ bisher noch nicht behandelt wurde.
+ Dieses Verhalten sollte nur beim generellen Abfangen von
+ Befehlsgruppen benutzt werden und ist ansonsten veraltet. Es
+ entsprich add_action("fun","kommando",1).
- Beispiel:
- 1. AddCmd("klett","fun",1);
- 2. AddCmd("kletter|klettere&hoch",#'fun2,"Wohin klettern?");
+ Beispiel:
+ 1. AddCmd("klett","fun",1);
+ 2. AddCmd("kletter|klettere&hoch",#'fun2,"Wohin klettern?");
- a) "klett"
- b) "kletter"
- c) "klettere hoch"
+ a) "klett"
+ b) "kletter"
+ c) "klettere hoch"
- Ausgefuehrte Funktion bei: 1a, 1b, 1c; 2c
- (1 wuerde also immer ausgefuehrt)
- Fehlermeldung bei: 2b ("Wohin klettern?")
+ Ausgefuehrte Funktion bei: 1a, 1b, 1c; 2c
+ (1 wuerde also immer ausgefuehrt)
+ Fehlermeldung bei: 2b ("Wohin klettern?")
BEMERKUNGEN
===========
- - Methoden der put_and_get (nimm/nehme) sollten so nicht versucht
+ * Methoden der put_and_get (nimm/nehme) sollten so nicht versucht
werden zu ueberschreiben - dazu sind invis Container da
- - benutzt man fuer <function> eine Closure, kann man die Fkt. auch
- protected oder private deklarieren _und_ sie kann in einem
+
+ * benutzt man fuer <function> eine Closure, kann man die Fkt.
+ auch protected oder private deklarieren _und_ sie kann in einem
anderen Objekt sein
- - bei Regeln wird an die ggf. gerufene Methode als zweiter Parameter
- ein Array der erfuellenden Eingabeteile uebergeben:
- "steck&@PRESENT&in&loch" bei Erfuellung -> ({<Objekt>,"in","loch})
- - bei Nutzung von @PUT_GET_XXX koennen die Parameter wiederum
- Arrays sein ("jede Hose" -> mehrere gueltige Objekte)
- - juengere AddCmd ueberschreiben aeltere, bzw. werden vor diesen
+
+ * bei Regeln wird an die ggf. gerufene Methode als zweiter
+ Parameter ein Array der erfuellenden Eingabeteile uebergeben:
+ "steck&@PRESENT&in&loch" bei Erfuellung ->
+ ({<Objekt>,"in","loch})
+
+ ** bei Nutzung von @PUT_GET_XXX koennen die Parameter wiederum
+ Arrays sein ("jede Hose" -> mehrere gueltige Objekte)
+
+ * juengere AddCmd ueberschreiben aeltere, bzw. werden vor diesen
ausgewertet
- - @PUT_GET_XXX kosten sehr viel Auswertungszeit
+
+ * @PUT_GET_XXX kosten sehr viel Auswertungszeit
+
BEISPIELE (SIEHE AUCH ADDCMD_BSP):
+==================================
+
// SIMPEL: ganz simpel, beinahe wie add_action
- AddCmd("befiehl","action_befehlen"); ... int action_befehlen(string
- str) {
-
- if(!str || !strlen(str))
- // Fehlermeldung, falls gar keine Funktion 1 dafuer
- zurueckgibt notify_fail("Was willst du befehlen?!n");
-
- else {
- write("Du befiehlst ""+str+"", und alle folgen!n");
- say(TP->Name(WER)+" befiehlt ""+str+"", und du folgst!n");
- return 1; // ERFOLG - Abbruch der Kommandoauswertung
-
- } return 0; // MISSERFOLG - Fehlermeldung oben gesetzt
-
+ AddCmd("befiehl","action_befehlen");
+ ...
+ int action_befehlen(string str) {
+ if(!str || !strlen(str))
+ // Fehlermeldung, falls gar keine Funktion 1 dafuer zurueckgibt
+ notify_fail("Was willst du befehlen?!\n");
+ else {
+ write("Du befiehlst \""+str+"\", und alle folgen!\n");
+ say(TP->Name(WER)+" befiehlt \""+str+"\", und du folgst!\n");
+ return 1; // ERFOLG - Abbruch der Kommandoauswertung
+ }
+ return 0; // MISSERFOLG - Fehlermeldung oben gesetzt
}
// SIMPEL .. weitere Beispiele
AddCmd(({"kletter","klettere"}),"action_klettern" );
AddCmd(({"renn","renne"}),#'action_rennen);
- // REGELN: eine komplexere Regel AddCmd("loesch|loesche|ersticke&f
- euer|brand|flammen&decke|wolldecke",
-
- "action_loeschen", "Was willst du loeschen?|Womit willst du
- loeschen?");
+ // REGELN: eine komplexere Regel
+ AddCmd("loesch|loesche|ersticke&feuer|brand|flammen&decke|wolldecke",
+ "action_loeschen",
+ "Was willst du loeschen?|Womit willst du loeschen?");
// REGELN: mit Platzhaltern im Fehlerstring
AddCmd("spring|springe|huepf|huepfe&von|vom&baum|ast|eiche",
+ #'action_huepfe,
+ "Willst du von etwas @verben?|Von wo willst du @verben?");
- #'action_huepfe, "Willst du von etwas @verben?|Von wo willst du
- @verben?");
+ // SCHLECHT: eine unscharfe Regel - sie sollten eine Ausnahme sein (!)
+ AddCmd("kletter","fun_klettern",1);
- // SCHLECHT: eine unscharfe Regel - sie sollten eine Ausnahme sein
- (!) AddCmd("kletter","fun_klettern",1);
-
- // FALSCH: sehr schlecht, kein Imperativ verwendet // ausserdem
- sollte man fuer solche Syntaxen AddReadDetail benutzen
+ // FALSCH: sehr schlecht, kein Imperativ verwendet
+ // ausserdem sollte man fuer solche Syntaxen AddReadDetail benutzen
AddCmd("lese","eval_lesen");
- // SIMPLE REGEL OHNE METHODE // mit Regeln kann man auch
- Aktivitaeten im Raum erlauben, ohne eine // Funktion aufrufen zu
- muessen: die letzte Regel ist fuer Spieler // unmoeglich zu
- erfuellen, die dazugehoerige Fehlermeldung wird mit // dem ^
- (write-Flag) versehen und entsprechend an den Spieler // (und den
- Raum (hinter dem ^)) ausgegeben
- AddCmd("spring|springe&herunter|runter&nbimpossible",0,
-
- "Wohin oder wovon willst Du springen?|" "Du springst vom Baum
- und kommst hart auf.^" "@WER1 springt vom Baum und kommt hart
- auf.");
+ // SIMPLE REGEL OHNE METHODE
+ // mit Regeln kann man auch Aktivitaeten im Raum erlauben, ohne eine
+ // Funktion aufrufen zu muessen: die letzte Regel ist fuer Spieler
+ // unmoeglich zu erfuellen, die dazugehoerige Fehlermeldung wird mit
+ // dem ^ (write-Flag) versehen und entsprechend an den Spieler
+ // (und den Raum (hinter dem ^)) ausgegeben
+ AddCmd("spring|springe&herunter|runter&\n\bimpossible",0,
+ "Wohin oder wovon willst Du springen?|"
+ "Du springst vom Baum und kommst hart auf.^"
+ "@WER1 springt vom Baum und kommt hart auf.");
SIEHE AUCH
==========
- AddCmd_bsp, RemoveCmd(L), init(E)
- Fehlermeldungen: notify_fail(E), _notify_fail(E)
- Argumentstring: query_verb(E), _unparsed_args(L)
- Sonstiges: replace_personal(E), enable_commands(E)
- Alternativen: AddAction(L), add_action(E)
+ AddCmd_bsp, RemoveCmd(L), init(E) Fehlermeldungen: notify_fail(E),
+ _notify_fail(E) Argumentstring: query_verb(E), _unparsed_args(L)
+ Sonstiges: replace_personal(E), enable_commands(E) Alternativen:
+ AddAction(L), add_action(E)
30. Aug 2013 Gloinson
diff --git a/doc/lfun/DefendOther b/doc/lfun/DefendOther
index f0386f2..0d36fc2 100644
--- a/doc/lfun/DefendOther
+++ b/doc/lfun/DefendOther
@@ -6,7 +6,8 @@
FUNKTION
========
- mixed DefendOther(int dam,mixed dam_type,mixed spell,object enemy);
+ public <int|string*|mapping>* DefendOther(int dam, string|string* dam_type,
+ int|mapping spell, object enemy)
DEFINIERT IN
diff --git a/doc/lfun/clean_up b/doc/lfun/clean_up
index 7c124fb..c1bf14e 100644
--- a/doc/lfun/clean_up
+++ b/doc/lfun/clean_up
@@ -12,56 +12,97 @@
DEFINIERT IN
============
- /std/room.c
- man kann die Funktion jedoch auch in beliebigen Objekten selbst
- definieren.
+ * /std/room.c
+
+ * man kann die Funktion jedoch auch in beliebigen Objekten selbst
+ definieren.
ARGUMENTE
=========
ref
- + 0 bei gecloneten Objekten
- + 1 bei einfachen geladenen Objekten
- + >1 bei Objekten, die geerbt wurden oder als Blueprint dienen
- + <0, wenn clean_up() von aussen aufgerufen wurde (das muss man
- selbst beachten!)
+ Ein Referenzzaehler (s.u.)
BESCHREIBUNG
============
- Wenn ein Objekt seit langer Zeit nicht mehr benutzt wurde, kann es sich
- hier selbst zerstoeren. Das sollte das Objekt allerdings nur tun, wenn
- ref kleiner oder gleich 1 ist.
+ Wenn ein Objekt seit langer Zeit nicht mehr benutzt wurde (d.h. es
+ wurde keine lfun *von aussen* in ihm gerufen), ruft der Driver
+ diese Funktion auf. Es kann es sich hier selbst zerstoeren, um
+ Speicher freizugeben (und ggf. spaeter mit aktuellem Sourcecode neu
+ erzeugt werden, was auch eine Art einfacher Updatemechanismus ist).
+
+ Der Referenzzaehler <ref> gibt an, wie oft das Objekt als Vorlage
+ fuer Clones oder erbende Programme dient. Folgende Faelle sind
+ damit unterscheidbar:
+
+ ref==0:
+ Das Objekt ist ein Clone (oder eine Blueprint mit ersetztem
+ Programm)
+
+ ref==1:
+ Das Objekt ist eine Blueprint (kein Clone), von welcher zur
+ Zeit keine Clones oder erbenden Programme existieren.
+
+ ref > 1:
+ Das Objekt dient als Vorlage / Blueprint fuer Clones oder
+ erbende Programme.
+
+ Das Objekt im clean_up zu zerstoeren, ist in der Regel ist daher
+ nur sinnvoll, wenn ref kleiner oder gleich 1 ist.
+
+ Sollte man einem Objekt ein clean_up geben, was als Clone im Umlauf
+ ist und dieses im Falle von ref==0 zerstoeren, bedeutet dies
+ letztendlich, dass sich ungenutzte Clones aufraeumen.
+
+ In einem Spezialfall kann ref auch < 0 sein: wenn clean_up *nicht*
+ vom Driver gerufen wird, sondern (manuell) von irgendwo aus der
+ Mudlib, ist die *Konvention*, einen Wert < 0 zu uebergeben.
+
+ Standardmaessig definieren nur Raeume clean_up(). Hierbei gilt die
+ Besonderheit, dass Raeume sich erst beim *zweiten* Aufruf von
+ clean_up() wegraeumen, wenn in ihnen Objekte liegen, die der Raum
+ *nicht* selbst mittels AddItem() erzeugt hat. D.h. laesst jemand
+ etwas im Raum rumliegen, erhoeht sich effektiv die Cleanup-Zeit auf
+ das doppelte. Und hat irgendjemand sich auf einen Hook des Raums
+ registriert, raeumt der Raum sich nicht im clean_up() auf.
+
+ Soll ein Raum sich niemals per clean_up() selber aufraeumen, kann
+ die Property P_NEVER_CLEAN gesetzt werden. Aber bitte seid hiermit
+ *sehr sparsam* und benutzt das nur in Raeumen, die es wirklich
+ benoetigen. Fast alle Raeume kommen super klar, wenn sie bei Bedarf
+ neu erzeugt werden.
RUeCKGABEWERT
=============
Der Rueckgabewert hat nur dann eine Bedeutung, wenn sich das Objekt
- nicht selbst zerstoert hat. Wird 0 zurueckgegeben, so wird clean_up()
- erst dann wieder aufgerufen, nachdem das Objekt aus- und wieder
- eingeswappt wurde.
+ nicht selbst zerstoert hat.
- Ein Rueckgabewert ungleich 0 zeigt an, dass das Objekt sich
- wahrscheinlich in der naechsten clean_up()-Runde zerstoeren kann, wenn
- in der Zwischenzeit zB. noch einmal reset() aufgerufen wurde.
+ Wird 0 zurueckgegeben, so wird clean_up() *nicht erneut* gerufen.
+ Ein Rueckgabewert ungleich 0 zeigt hingegen an, dass das Objekt
+ sich moeglicherweise beim naechsten Aufruf von clean_up()
+ zerstoeren koennte, d.h. der Driver wird es nach Ablauf der
+ Cleanup-Zeit erneut versuchen.
BEMERKUNGEN
===========
- Standardmaessig definieren nur Raeume clean_up().
-
- Die Zeiten zwischen zwei Aufrufen von clean_up() betragen momentan
- einen Tag (86400 Sekunden).
+ Die Cleanup-Zeit, die ein Objekt nicht benutzt werden darf, bevor
+ clean_up() aufgerufen wird, betraegt momentan 18h (64800 Sekunden).
SIEHE AUCH
==========
- reset(), P_NEVER_CLEAN
- memory
+ lfuns:
+ reset()
-21. Maerz 2004 Gloinson
+ Properties:
+ P_NEVER_CLEAN
+
+18.02.2019, Zesstra
diff --git a/doc/lfun/command_me b/doc/lfun/command_me
index ced4b2b..00100f4 100644
--- a/doc/lfun/command_me
+++ b/doc/lfun/command_me
@@ -38,13 +38,14 @@
AddCmd definierten Kommandos) koennen auch durch command()(E)
von aussen ausgeloest werden.
-BEMERKUNGEN:
- * beruecksichtigt Aliase, d.h. wenn man Aliase eines Spielers
- ignorieren will, muss man ein \ (fuer ein im Eingabestring) vor
- den Befehl stellen
- * fuer objektinterne Kommandos funktioniert also auch
- command()(E)
+BEMERKUNGEN
+===========
+
+ - beruecksichtigt Aliase, d.h. wenn man Aliase eines Spielers
+ ignorieren will, muss man ein \\ (fuer ein \ im Eingabestring)
+ vor den Befehl stellen
+ - fuer objektinterne Kommandos funktioniert also auch command()(E)
BEISPIEL
diff --git a/doc/lfun/die b/doc/lfun/die
index a76a1aa..b8ee872 100644
--- a/doc/lfun/die
+++ b/doc/lfun/die
@@ -18,25 +18,26 @@
ARGUMENTE
=========
- int poisondeath
- Dieses Flag sollte bei einem Gifttod (P_POISON) gesetzt sein.
- int extern
- Intern.
+ poisondeath
+ Dieses Flag sollte bei einem Gifttod (P_POISON) gesetzt sein.
+
+ extern
+ Ex- oder interner Aufruf.
BESCHREIBUNG
============
- Das Lebewesen stirbt, meist automatisch von do_damage() ausgeloest, wenn
- 0 HP unterschritten werden. In diesem Fall wird der Kampf beendet, Gift,
- Alkohol, Trink- und Esswerte, Blindheit, Taubheit u.s.w. auf Null
- gesetzt oder geloescht.
+ Das Lebewesen stirbt, meist automatisch von do_damage() ausgeloest,
+ wenn 0 HP unterschritten werden. In diesem Fall wird der Kampf
+ beendet, Gift, Alkohol, Trink- und Esswerte, Blindheit, Taubheit
+ u.s.w. auf Null gesetzt oder geloescht.
- Es wird automatisch eine Leiche (siehe auch P_CORPSE, P_NOCORPSE) nebst
- Todesmeldungen (siehe auch P_DIE_MSG) erzeugt, und fuer Spieler werden
- Killstupse vergeben, sofern notwendig.
+ Es wird automatisch eine Leiche (siehe auch P_CORPSE, P_NOCORPSE)
+ nebst Todesmeldungen (siehe auch P_DIE_MSG) erzeugt, und fuer
+ Spieler werden Killstupse vergeben, sofern notwendig.
- Ueber den Hook P_TMP_DIE_HOOK kann man jedoch auf den Automatismus
+ Ueber den Hook H_HOOK_DIE kann man jedoch auf den Automatismus
Einfluss nehmen, z.B. koennte ein temporaerer Todesbann-Zauber das
Sterben fuer kurze Zeit verhindern.
@@ -50,18 +51,40 @@
BEMERKUNGEN
===========
- Diese Funktion sollte nur selten direkt verwendet werden. Meist ist der
- uebliche Weg ueber Defend() -> do_damage() -> die() die logisch bessere
- und balancetechnisch guenstigere Loesung.
+ Diese Funktion sollte nur selten direkt verwendet werden. Meist ist
+ der uebliche Weg ueber Defend() -> do_damage() -> die() die logisch
+ bessere und balancetechnisch guenstigere Loesung.
+
+ Diese Funktion sollte nur ueberschrieben werden, wenn tatsaechlich
+ einfluss auf das Sterben genommen werden soll. Wird nur ein Item
+ hinzugefuegt, ist es sinnvoller second_life() zu verwenden.
+
+ Wird die() ueberschrieben, sollte man nicht nur das Argument extern
+ uebergeben, sondern mit extern_call() verodern (siehe Beispiel),
+ weil das geerbte die() den externen Aufruf nicht mehr erkennen
+ kann.
+
+
+BEISPIEL
+========
+
+ public varargs void die(int poisondeath, int extern)
+ {
+ // Dieser NPC soll nicht an Gift sterben.
+ if(poisondeath) return;
+
+ // Das geerbte die() aufrufen, dabei die Argumente uebergeben und ggf.
+ // extern setzen.
+ ::die(poisondeath, extern||extern_call());
+ }
SIEHE AUCH
==========
- Todesursachen: Defend(L), do_damage(L), P_POISON
- Verwandt: P_TMP_DIE_HOOK, P_DEADS
- Todesmeldungen: P_KILL_NAME, P_KILL_MSG, P_MURDER_MSG, P_DIE_MSG
- P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
- Sonstiges: P_CORPSE, P_NOCORPSE, /std/corpse.c
+ Defend(), do_damage(), second_life(), P_POISON, P_DEADS,
+ P_KILL_NAME, P_KILL_MSG, P_MURDER_MSG, P_DIE_MSG, P_ZAP_MSG,
+ P_ENEMY_DEATH_SEQUENCE, P_CORPSE, P_NOCORPSE, extern_call,
+ /std/corpse, /std/hooks
-Last modified: Mon May 14 16:20:34 2001 by Patryn
+Letzte Aenderung: 17.03.2019, Bugfix
diff --git a/doc/lfun/second_life b/doc/lfun/second_life
index 1c3fc8b..d40c63e 100644
--- a/doc/lfun/second_life
+++ b/doc/lfun/second_life
@@ -19,29 +19,31 @@
=========
obj
- Leiche des Lebewesens.
+ Leiche des Lebewesens (sofern es eine hat)
BESCHREIBUNG
============
Diese Funktion wird im die() des Lebewesens aufgerufen, wenn sicher
- ist, dass es stirbt. Ueblicherweise ist diese Funktion nur im Spieler
- definiert und regelt EP-Verlust und dergleichen. Ein Shadow wuerde
- diese Funktion ueberlagern, um zu verhindern, dass ein Spieler stirbt.
+ ist, dass es stirbt. Die Funktion bestimmt dabei, ob ein Lebewesen
+ nach dem Tod zerstoert (NPC) oder nur zum Geist wird (Spieler).
+
+ Ueblicherweise ist diese Funktion nur im Spieler definiert und
+ regelt EP-Verlust und dergleichen. Sie wird aber auch in NPCs
+ gerufen und man kann dort z.B. Items clonen oder entsorgen.
+
+ NPC *muessen* 0 zurueckgeben, Spieler geben immer 1 zurueck.
RUeCKGABEWERT
=============
- 1, wenn das Lebewesen nicht stirbt, sonst 0
+ 0
+ wenn das Objekt nach dem Tod zerstoert wird (NPC)
-
-BEMERKUNG
-=========
-
- Bei NPCs sollte man direkt die() ueberschreiben, wenn man nicht
- moechte, dass sie sterben.
+ 1
+ wenn das Objekt im Tod nicht zerstoert wird (Spieler)
SIEHE AUCH
@@ -49,4 +51,4 @@
die()
-Last modified: 2015-Jan-19, Arathorn
+Last modified: 17.03.2019, Zesstra