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
diff --git a/doc/props/P_NOGET b/doc/props/P_NOGET
index 17a6248..a6e88a6 100644
--- a/doc/props/P_NOGET
+++ b/doc/props/P_NOGET
@@ -6,7 +6,7 @@
 NAME
 ====
 
-   P_NOGET                         "noget"
+   P_NOGET                           "noget"
 
 
 DEFINIERT IN
@@ -18,13 +18,20 @@
 BESCHREIBUNG
 ============
 
-   Ist diese Property in einem Objekt gesetzt, so kann ein Lebewesen
-   das Objekt nicht nehmen.
-   Als Standardmeldung kommt in diesem Fall beispielsweise:
-     Du kannst <Objektname> nicht nehmen.
-     Du kannst <Objektname> so nirgendwo reinstecken.
-   Man kann auch eine alternative Meldung angeben, wobei selbstaendig
-   auf einen korrekten Zeilenumbruch zu achten ist.
+   Ist diese Property in einem Objekt auf 1 oder einen String gesetzt,
+   so kann ein Lebewesen das Objekt nicht nehmen.
+
+   Ist die Property auf 1 gesetzt, wird eine Standardmeldung
+   ausgegeben, beim Nehmen:
+
+      Du kannst <Objektname> nicht nehmen.
+
+   oder wenn man es in einen Behaelter zu stecken versucht:
+
+      Du kannst <Objektname> so nirgendwo reinstecken.
+
+   Man kann auch eine eigene Meldung angeben, wobei vom Programmierer
+   selbst auf einen korrekten Zeilenumbruch zu achten ist.
 
 
 BEISPIELE
@@ -32,7 +39,9 @@
 
    Ein Objekt, welches fest im Raum verankert ist, kann natuerlich
    nicht entfernt werden, z.B. ein angebundenes Seil:
-     SetProp(P_NOGET,"Das Seil ist fest am Baum verknotet!\n");
+
+      SetProp(P_NOGET,"Das Seil ist fest am Baum verknotet!\n");
+
    In einem Kommando zum Losknoten koennte man die Property dann
    loeschen, um ein Wegnehmen zu ermoeglichen.
 
@@ -40,10 +49,15 @@
 SIEHE AUCH
 ==========
 
-   Aehnliches: P_NODROP, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG,
-               P_TOO_MANY_MSG, P_NOINSERT_MSG, P_NOLEAVE_MSG
-   Erfolg:     P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
-               P_WEAR_MSG, P_WIELD_MSG
-   Sonstiges:  replace_personal(E), /std/living/put_and_get.c
+   Aehnliches:
+      P_NODROP, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
+      P_NOINSERT_MSG, P_NOLEAVE_MSG
 
-Last modified: Thu Jun 14 22:26:29 2001 by Patryn
+   Erfolg:
+      P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG, P_WEAR_MSG,
+      P_WIELD_MSG
+
+   Sonstiges:
+      replace_personal(E), /std/living/put_and_get.c
+
+Last modified: 2019-May-06
diff --git a/doc/sphinx/lfun/AddCmd.rst b/doc/sphinx/lfun/AddCmd.rst
index ba298eb..001778f 100644
--- a/doc/sphinx/lfun/AddCmd.rst
+++ b/doc/sphinx/lfun/AddCmd.rst
@@ -1,25 +1,19 @@
 AddCmd()
 ========
 
-AddCmd(L)
----------
-::
-
 FUNKTION
 --------
-::
 
     varargs void AddCmd(mixed cmd, mixed func, [mixed flag, [mixed id]]);
 
 DEFINIERT IN
 ------------
-::
+
 
     /std/thing/commands.c
 
 ARGUMENTE
 ---------
-::
 
     cmd
        Verben, auf die reagiert werden soll
@@ -41,14 +35,14 @@
 
 BESCHREIBUNG
 ------------
-::
 
     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
+
+    * 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
+    * innerhalb der Funktionen koennen Fehlermeldungen fuer den totalen
       Misserfolg des Kommandos mit notify_fail gesetzt werden
       (anstatt "Wie bitte?")
 
@@ -57,140 +51,153 @@
     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.
+    
+    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.
+    Nur wenn in richtiger Reihenfolge aus JEDER der durch & getrennten
+    Synonymgruppen ein Wort im Spielerkommando enthalten ist, wird
+    die zugehoerige Funktion ausgefuehrt.
 
-      Trenner sind: | fuer Alternativen
-                    & fuer Konjunktionen
+    Trenner sind: | fuer Alternativen
+                  & fuer Konjunktionen
 
-      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.
+.. code-block:: pike
 
-      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.
+    
+    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.
+    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.
 
-      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!)
+    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!)
 
-      Beispielfehlermeldungen fuer obige Regel:
-        "Womit willst Du schnitzen?|Was willst Du schnitzen?|"
-        "Wohinein willst Du das schnitzen?"
+    Beispielfehlermeldungen fuer obige Regel:
+      "Womit willst Du schnitzen?|Was willst Du schnitzen?|"
+      "Wohinein willst Du das schnitzen?"
 
-      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)
+    Es koennen in den Fehlermeldungen folgende Platzhalter benutzt
+    werden:
 
-      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!
+    * @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
+    * 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
+    * 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 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):
+----------------------------------
+
+.. code-block:: pike
+
     // 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
+      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
@@ -225,9 +232,9 @@
            "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)
diff --git a/doc/sphinx/lfun/DefendOther.rst b/doc/sphinx/lfun/DefendOther.rst
index 855d2b8..e18c9c7 100644
--- a/doc/sphinx/lfun/DefendOther.rst
+++ b/doc/sphinx/lfun/DefendOther.rst
@@ -5,7 +5,8 @@
 --------
 ::
 
-	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/sphinx/props/P_NOGET.rst b/doc/sphinx/props/P_NOGET.rst
index 9e231fd..9031fbd 100644
--- a/doc/sphinx/props/P_NOGET.rst
+++ b/doc/sphinx/props/P_NOGET.rst
@@ -3,48 +3,62 @@
 
 NAME
 ----
-::
 
-	P_NOGET				"noget"
+  P_NOGET                           "noget"
+
 
 DEFINIERT IN
 ------------
-::
 
-	/sys/thing/moving.h
+  /sys/thing/moving.h
+
 
 BESCHREIBUNG
 ------------
-::
 
-	Ist diese Property in einem Objekt gesetzt, so kann ein Lebewesen
-	das Objekt nicht nehmen.
-	Als Standardmeldung kommt in diesem Fall beispielsweise:
-	  Du kannst <Objektname> nicht nehmen.
-	  Du kannst <Objektname> so nirgendwo reinstecken.
-	Man kann auch eine alternative Meldung angeben, wobei selbstaendig
-	auf einen korrekten Zeilenumbruch zu achten ist.
+  Ist diese Property in einem Objekt auf 1 oder einen String gesetzt,
+  so kann ein Lebewesen das Objekt nicht nehmen.
+
+  Ist die Property auf 1 gesetzt, wird eine Standardmeldung ausgegeben, 
+  beim Nehmen:
+
+    Du kannst <Objektname> nicht nehmen.
+
+  oder wenn man es in einen Behaelter zu stecken versucht:
+  
+    Du kannst <Objektname> so nirgendwo reinstecken.
+
+  Man kann auch eine eigene Meldung angeben, wobei vom Programmierer
+  selbst auf einen korrekten Zeilenumbruch zu achten ist.
+
 
 BEISPIELE
 ---------
-::
 
-	Ein Objekt, welches fest im Raum verankert ist, kann natuerlich
-	nicht entfernt werden, z.B. ein angebundenes Seil:
-	  SetProp(P_NOGET,"Das Seil ist fest am Baum verknotet!\n");
-	In einem Kommando zum Losknoten koennte man die Property dann
-	loeschen, um ein Wegnehmen zu ermoeglichen.
+  Ein Objekt, welches fest im Raum verankert ist, kann natuerlich nicht
+  entfernt werden, z.B. ein angebundenes Seil: ::
+  
+    SetProp(P_NOGET,"Das Seil ist fest am Baum verknotet!\n");
+
+  In einem Kommando zum Losknoten koennte man die Property dann loeschen,
+  um ein Wegnehmen zu ermoeglichen.
+
 
 SIEHE AUCH
 ----------
-::
 
-     Aehnliches: P_NODROP, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG,
-                 P_TOO_MANY_MSG, P_NOINSERT_MSG, P_NOLEAVE_MSG 
-     Erfolg:     P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
-                 P_WEAR_MSG, P_WIELD_MSG
-     Sonstiges:  replace_personal(E), /std/living/put_and_get.c
+    Aehnliches: 
+       :doc:`../props/P_NODROP`, :doc:`../props/P_TOO_HEAVY_MSG`, 
+       :doc:`../props/P_ENV_TOO_HEAVY_MSG`, :doc:`../props/P_TOO_MANY_MSG`, 
+       :doc:`../props/P_NOINSERT_MSG`, :doc:`../props/P_NOLEAVE_MSG`
 
+    Erfolg:
+       :doc:`../props/P_PICK_MSG`, :doc:`../props/P_DROP_MSG`, 
+       :doc:`../props/P_GIVE_MSG`, :doc:`../props/P_PUT_MSG`,
+       :doc:`../props/P_WEAR_MSG`, :doc:`../props/P_WIELD_MSG`
+    
+    Sonstiges:
+       replace_personal(E), /std/living/put_and_get.c
 
-Last modified: Thu Jun 14 22:26:29 2001 by Patryn
+Last modified: 2019-May-06
 
diff --git a/doc/wiz.index b/doc/wiz.index
index bf37c11..8a68b6f 100644
--- a/doc/wiz.index
+++ b/doc/wiz.index
@@ -13,6 +13,4 @@
 
 * Erstellung neuer Repositories in Gerrit
 
-* Hinweise fuer Erzmagier / Admins
-
 * Homemud
diff --git a/doc/wiz/homemud b/doc/wiz/homemud
index 6db6148..cd23d87 100644
--- a/doc/wiz/homemud
+++ b/doc/wiz/homemud
@@ -30,7 +30,7 @@
 
    2. Lade die aktuelle Mudlib von
       https://mg.mud.de/gerrit/gitweb?p =mudlib-public.git herunter,
-      entweder durch einen Klick auf "snapchot" oder mittels git
+      entweder durch einen Klick auf "snapshot" oder mittels git
       clonen. Dabei kann sich git an unserem selbsterstellten SSL-
       Zertifikat stoeren, wenn Du Dich darum nicht kuemmern willst,
       nutze die Option "-c http.sslVerify=false".
@@ -59,62 +59,55 @@
    Optional kannst Du noch den Namen des Mudgottes von Jof auf etwas
    anderes aendern, das geht wie folgt:
 
-   code-block:
-
-      mv save/j/jof.o save/t/thomas.o
-      mv secure/save/j/jof.o secure/save/t/thomas.o
-      # (beachte den Namen des Unterverzeichnisses, es ist der erste Buchstabe
-      # Deines Namens. )
-      sed -i 's/jof/thomas/' secure/save/t/thomas.o
-      mkdir -p players/thomas
-      mv players/jof/workroom.c players/thomas/workroom.c
+     mv save/j/jof.o save/t/thomas.o
+     mv secure/save/j/jof.o secure/save/t/thomas.o
+     # (beachte den Namen des Unterverzeichnisses, es ist der erste Buchstabe
+     # Deines Namens. )
+     sed -i 's/jof/thomas/' secure/save/t/thomas.o
+     mkdir -p players/thomas
+     mv players/jof/workroom.c players/thomas/workroom.c
 
    Nachdem Login muss man nun noch den Workroom anpassen:
 
-   code-block:
-
-      clone /obj/tools/MGtool
-      xcall $me->SetProp(P_START_HOME, "/players/thomas/workroom");
-      save
+   clone /obj/tools/MGtool
+   xcall $me->SetProp(P_START_HOME, "/players/thomas/workroom");
+   save
 
 
 Beispielinstallation
 ====================
 
-   code-block:
+   cd <mudhome>
+   git clone https://github.com/ldmud/ldmud.git
+   cd ldmud.git/src
+   ./autogen.sh
+   settings/morgengrauen
+   make all && make install-all
+   cd <mudhome>
+   # hier wurde der bin/ Ordner nicht angepasst, wir verschieben noch die
+   # Binary
+   mv bin.install/ldmud bin/ldmud
+   tar xvzf <mudlib-snapshot.tgz>
+   # Alternative
+   git clone https://mg.mud.de/gerrit/mudlib-public mudlib
+   cd <mudhome>
+   cd <mudlib>
+   mv save/j/jof.o save/t/thomas.o
+   mv secure/save/j/jof.o secure/save/t/thomas.o
+   # (beachte den Namen des Unterverzeichnisses, es ist der erste Buchstabe
+   # Deines Namens. )
+   sed -i 's/jof/thomas/' secure/save/t/thomas.o
+   mkdir -p players/thomas
+   mv players/jof/workroom.c players/thomas/workroom.c
+   bin/ldmud
+   # oder
+   bin/ldmud -m <alternative path to mudlib> <alternative port>
 
-      cd <mudhome>
-      git clone https://github.com/ldmud/ldmud.git
-      cd ldmud-3.5/src
-      ./autogen.sh
-      settings/morgengrauen
-      make all && make install-all
-      cd <mudhome>
-      # hier wurde der bin/ Ordner nicht angepasst, wir verschieben noch die
-      # Binary
-      mv bin.install/ldmud bin/ldmud
-      tar xvzf <mudlib-snapshot.tgz>
-      git clone https://mg.mud.de/gerrit/mudlib-public
-      cd <mudhome>
-      cd <mudlib>
-      mv save/j/jof.o save/t/thomas.o
-      mv secure/save/j/jof.o secure/save/t/thomas.o
-      # (beachte den Namen des Unterverzeichnisses, es ist der erste Buchstabe
-      # Deines Namens. )
-      sed -i 's/jof/thomas/' secure/save/t/thomas.o
-      mkdir -p players/thomas
-      mv players/jof/workroom.c players/thomas/workroom.c
-      bin/ldmud
-      # oder
-      bin/ldmud -m <alternative path to mudlib> <alternative port>
+Nachdem Login muss man nun noch den Workroom anpassen:
 
-   Nachdem Login muss man nun noch den Workroom anpassen:
-
-   code-block:
-
-      clone /obj/tools/MGtool
-      xcall $me->SetProp(P_START_HOME, "/players/thomas/workroom");
-      save
+   clone /obj/tools/MGtool
+   xcall $me->SetProp(P_START_HOME, "/players/thomas/workroom");
+   save
 
 Letzte Aenderung: 2018-12-09 von Deaddy (auf Basis von Zesstras engl.
 Anleitung)