diff --git a/doc/sphinx/lfun/AddAction.rst b/doc/sphinx/lfun/AddAction.rst
new file mode 100644
index 0000000..6791d4e
--- /dev/null
+++ b/doc/sphinx/lfun/AddAction.rst
@@ -0,0 +1,104 @@
+AddAction()
+===========
+
+AddAction(L)
+------------
+::
+
+FUNKTION
+--------
+::
+
+     varargs void AddAction(mixed fun, mixed cmd, int flag, int lvl);
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/command.c
+
+ARGUMENTE
+---------
+::
+
+     fun	zu rufende Methode im Spieler oder eine Closure
+     cmd	ausloesendes Kommandoverb
+     flag	unscharf ausfuehren
+     lvl	ab welchem (Magierlevel) funktioniert das Kommando
+
+BESCHREIBUNG
+------------
+::
+
+     Dem Spieler wird ein neues Kommando definiert. Dieses kann eine Methode
+     in ihm sein, so wie bei allen Spielerkommandos ueblich, kann aber auch
+     eine Closure (Lfun-Closure oder Lambda) enthalten.
+
+     Mittels "flag" kann man die Kommandoerkennung unscharf halten, d.h. wie
+     bei AddCmd(L) und add_action(E) wird ein 'cmd' bei 'flag = 1' auch
+     schon von Praefix-Strings (hier ohne Leerzeichen) getriggert:
+     AddAction([...], "muh", 1, 0) wird zB auch von 'muhtens' oder 'muh4'
+     ausgeloest.
+
+     Mit "lvl" begrenzt man die Ausfuehrbarkeit. Spieler haben ein
+     Magierlevel von 0, Seher von 1.
+
+     Das Kommando wird in P_LOCALCMDS eingetragen. Diese Property wird
+     nicht gespeichert! Effektiv kann man mit AddAction() ein kommando-
+     gebendes Objekt im Spieler einsparen.
+
+BEMERKUNGEN
+-----------
+::
+
+     - es gibt _noch_ kein RemoveAction! Per Hand in P_LOCALCMDS editieren
+       kann zu ernsten Fehlern fuehren.
+     - echte Spielerkommandos kann man damit _nicht_ ueberschreiben,
+       ein AddAction(...,"sag",1,0); funktioniert nicht
+     - ein generelles AddAction(...,"",1,0); geht nicht
+
+BEISPIELE
+---------
+::
+
+     ...
+     this_player()->AddAction(symbol_function("zeige_mysterium",
+                                              find_object(".../mystzeiger")),
+			      "knorfula",0,0);
+     write(break_string("Wann immer du jetzt das Kommando \"knorfula\" "
+			"eingibst, werden dir Mysterien enthuellt!",78));
+     ...
+
+     // im Objekt "knorfula" ...
+     int zeige_mysterium(string str) {
+       string myst;
+       myst=environment(TP)->QueryMysterium(str);
+       if(myst) {
+         write("Du hast ein Mysterium entdeckt!\n");
+	 write(break_string(myst,78));
+	 say(break_string(
+		TP->Name(WER)+" scheint nach kurzer Konzentration etwas "
+		"entdeckt zu haben!",78));
+       } else {
+         write(break_string(
+		"Leider entdeckst du trotz deiner magischen Faehigkeit "
+		"kein Mysterium in deiner Umgebung.",78));
+	 say(break_string(
+		TP->Name(WER)+" konzentriert sich sichtbar, sieht dann "
+		"jedoch etwas enttaeuscht aus.",78));
+       }
+       return 1;
+     }
+
+SIEHE AUCH
+----------
+::
+
+			P_LOCALCMDS
+     Fehlermeldungen:	notify_fail(E), _notify_fail(E)
+     Argumentstring:	query_verb(E), _unparsed_args(L)
+     Sonstiges:		replace_personal(E), enable_commands(E)
+     Alternativen:	AddCmd(L), add_action(E)
+
+24. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/AddAdjective.rst b/doc/sphinx/lfun/AddAdjective.rst
new file mode 100644
index 0000000..50eb0ad
--- /dev/null
+++ b/doc/sphinx/lfun/AddAdjective.rst
@@ -0,0 +1,63 @@
+AddAdjective()
+==============
+
+FUNKTION
+--------
+::
+
+     void AddAdjective(string|string* adj);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     adj
+          String oder Array von String mit den Adjektiven.
+
+BESCHREIBUNG
+------------
+::
+
+     Zusaetzlich zu den mit AddId() vergebenen Bezeichnern laesst sich mit
+     der Vergabe von Adjektiven die Ansprechbarkeit eines Objektes erhoehen.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Adjektive werden nicht dekliniert, man muss also fuer jeden
+     sinnvollen Fall ein Adjektiv uebergeben.
+
+BEISPIELE
+---------
+::
+
+       AddId( ({ "zettel", "blatt" }) );
+       AddAdjective( ({ "kleinen", "kleines" }) );
+
+     Das Objekt reagiert jetzt auf "zettel", "kleinen zettel", "blatt",
+     "kleines blatt" sowie auf die (sprachlich nicht ganz so korrekten)
+     Konstruktionen "kleines zettel", "kleinen blatt", "kleines kleinen
+     zettel", ...
+
+SIEHE AUCH
+----------
+::
+
+     AddId(), RemoveAdjective() id(), present(), /std/thing/description.c
+
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddAmount.rst b/doc/sphinx/lfun/AddAmount.rst
new file mode 100644
index 0000000..08c038b
--- /dev/null
+++ b/doc/sphinx/lfun/AddAmount.rst
@@ -0,0 +1,45 @@
+AddAmount()
+===========
+
+FUNKTION
+--------
+::
+
+     void AddAmount(int menge);
+
+DEFINIERT IN
+------------
+::
+
+     /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+     menge
+          Die Menge, die der Unit hinzugefuegt werden soll (kann auch
+          negativ sein).
+
+BESCHREIBUNG
+------------
+::
+
+     menge wird zur aktuellen Menge hinzugezaehlt. Sollte das Ergebnis 0
+     werden, wird die Unit in absehbarer Zeit zerstoert.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+SIEHE AUCH
+----------
+::
+
+     /std/unit.c
+
+
+Last modified: Wed May 8 10:15:50 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/AddClass.rst b/doc/sphinx/lfun/AddClass.rst
new file mode 100644
index 0000000..4c3ef61
--- /dev/null
+++ b/doc/sphinx/lfun/AddClass.rst
@@ -0,0 +1,48 @@
+AddClass()
+==========
+
+FUNKTION
+--------
+::
+
+     void AddClass(string|string* class);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     string/string* class	- String oder Stringarray der Klasse(n)
+
+BESCHREIBUNG
+------------
+::
+
+     Dem Objekt werden weitere Klassifizierungen hinzugefuegt.
+
+     Die allgemein verfuegbaren Klassen sind unter /sys/class.h definiert.
+
+BEMERKUNGEN
+-----------
+::
+
+     Vor dem 7. Nov 2012 pruefte is_class_member() auch die P_IDS. Damit war
+     zB ein AddId("daemon") gleichbedeutend einem AddClass(CL_DEMON).
+
+     Bitte prueft eure Objekte (NPCs, Krankheiten, Gifte, ...) auf korrekte
+     Klassifizierung.
+
+SIEHE AUCH
+----------
+::
+
+     RemoveClass(), is_class_member()
+     P_CLASS
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddCmd.rst b/doc/sphinx/lfun/AddCmd.rst
new file mode 100644
index 0000000..ba298eb
--- /dev/null
+++ b/doc/sphinx/lfun/AddCmd.rst
@@ -0,0 +1,239 @@
+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
+
+       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
+
+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
+      (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
+    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.
+
+      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.
+
+      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.
+
+      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?"
+
+      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).
+
+
+      Beispiel:
+        1. AddCmd("klett","fun",1);
+        2. AddCmd("kletter|klettere&hoch",#'fun2,"Wohin klettern?");
+
+        a) "klett"
+        b) "kletter"
+        c) "klettere hoch"
+
+        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
+      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
+      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
+      ausgewertet
+    - @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
+    }
+
+    // SIMPEL .. weitere Beispiele
+    AddCmd(({"kletter","klettere"}),"action_klettern" );
+    AddCmd(({"renn","renne"}),#'action_rennen);
+
+    // 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?");
+
+    // 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
+    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&\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)
+
+30. Aug 2013 Gloinson
+
diff --git a/doc/sphinx/lfun/AddCmd_bsp.rst b/doc/sphinx/lfun/AddCmd_bsp.rst
new file mode 100644
index 0000000..d0665d3
--- /dev/null
+++ b/doc/sphinx/lfun/AddCmd_bsp.rst
@@ -0,0 +1,336 @@
+AddCmd_bsp()
+============
+
+ADDCMD() - BEISPIELE
+--------------------
+::
+
+FUNKTION
+--------
+::
+
+    varargs void AddCmd(mixed cmd, mixed func, mixed flag);
+
+BEMERKUNGEN
+-----------
+::
+
+    Die hier aufgefuehrten Komplexbeispiele sind zum Verstaendnis gedacht,
+    daher fuehren sie oft Alternativen auf. Die letzte Variante ist dann
+    jeweils diejenige, welche am leichtesten das Problem loesen koennte.
+    Falls die einem zu komplex ist, hilft vielleicht die vorletzte.
+
+BEISPIELE
+---------
+::
+
+    // 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
+    }
+
+    // SIMPEL .. weitere Beispiele
+    AddCmd(({"kletter","klettere"}),"action_klettern" );
+    AddCmd(({"renn","renne"}),#'action_rennen);
+
+    // 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?");
+
+    // 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
+    AddCmd("lese","eval_lesen");
+
+    // SIMPLE REGEL
+    static int action_jump(string str);        // Prototype (wegen closure)
+    ...
+    AddCmd("spring|springe|huepf|huepfe&von&baum|ast",#'action_jump,
+           "Willst Du von etwas @verben?|Wovon willst Du @verben?");
+    ...
+    static int action_jump(string str) {
+      write(break_string("Du springst vom Baum und kommst hart auf!",78));
+      this_player()->move((XXXROOM+"boden"), M_GO, 0,
+                          "springt unelegant vom Baum","faellt vom Baum");
+      this_player()->Defend(random(100),({DT_BLUDGEON}),([SP_RECURSIVE:1]),
+                            this_object());
+      return 1;
+    }
+
+    // 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.");
+
+## Komplexbeispiel: Regeln mit Fehlermeldungen ##
+ ## Variante 1, OHNE REGELN ##
+    // bei Nichtverwendung von Regeln muss man Parameter selbst auswerten
+    AddCmd(({"bohr","bohre"}),#'action_bohren);
+    ...
+    private int action_bohren(string str) {
+      string *tmp;
+      notify_fail("Wo willst (etwas) Du bohren?\n");
+      if(!str) return 0;       // Tja, keine Argumente ...
+      tmp=explode(str," ");    // nach " " in Argument-Array aufspalten
+      if((i=member(tmp,"loch"))>=0) { // aha, ab jetzt uebernehmen wir :)
+       if((j=member(tmp[(i+1)..],"in"))<0 &&
+          (j=member(tmp[(i+1)..],"durch"))<0)
+         write("Willst Du das Loch in etwas bohren?\n");
+        else if((i=member(tmp[(j+1)..],"boden"))<0 &&
+                (i=member(tmp[(j+1)..],"erde"))<0)
+         write("In/Durch was willst du das Loch bohren?\n");
+        else {
+         write("Du bohrst ein Loch in den Boden.\n");
+         say(this_player()->Name(WER)+" bohrt ein Loch in den Boden.\n");
+        }
+        return 1;      // "bohre loch" war so eindeutig, dass nur diese
+                       // Methode gemeint sein konnte, also brechen wir die
+                       // weitere Auswertung auf jeden Fall ab (und geben
+                       // eine write-Fehlermeldung)
+      } // end if(..."loch")
+      return 0;        // "bohre" allein muss nicht diese Methode meinen,
+                       // also nur obige notify_fail()-Meldung, falls
+                       // sich nach dieser Methode gar keine sonst
+                       // angesprochen fuehlt
+    } // end fun
+
+ ## Variante 1a, OHNE REGELN ##
+    // prinzipiell koennte die Methode action_bohren auch so
+    // aussehen, ist aber nicht ganz so flexibel:
+    private int action_bohren(string str) {
+     string tmp;
+     if(!str || (sprintf(str,"loch in erde%s",tmp)!=1 &&
+                 sprintf(str,"loch durch erde%s",tmp)!=1 &&
+                 sprintf(str,"loch in boden%s",tmp)!=1 &&
+                 sprintf(str,"loch durch boden%s",tmp)!=1))
+      notify_fail("Willst Du in irgendwas ein Loch bohren?\n");
+     else {
+      ...
+      return 1;
+     }
+     return 0;
+    }
+
+ ## Variante 2, MIT REGEL ##
+    // das gleiche in etwa mal als einfache Regel
+    AddCmd("bohr|bohre&loch&in|durch&erde|boden",#'action_bohren,
+           "Was willst du (wohin) bohren?|"
+           "Willst du das Loch in etwas bohren?|"
+           "Wohin willst du das Loch bohren?");
+    ...
+    private int action_bohren(string str, mixed *param) {
+     write("Du bohrst ein Loch in den Boden.\n");
+     say(this_player()->Name(WER)+" bohrt ein Loch in den Boden.\n");
+     ...
+     return 1;
+    }
+
+ ## Variante 3, MIT REGEL UND FEHLERMELDUNG ##
+    // und nun mit Fehlermeldungen mit Ersetzungen, so dass wir mehr
+    // auf die Eingaben des Spielers eingehen
+    AddCmd("bohr|bohre&loch&in|durch&erde|boden",#'action_bohren,
+           "Was willst du (wohin) @verben?|"
+           "Willst du das Loch in etwas @verben?|"
+           "@WER3 was willst du das Loch @verben?");
+    ...
+    private int action_bohren(string str, mixed *param) ...
+
+ ## Variante 4, MIT REGEL, FEHLERMELDUNG UND RETURN 1 ##
+    // in Variante 1 kam sinnvollerweise sehr frueh der Abbruch mit
+    // "return 1;" und die Ausgabe von write-Fehlermeldungen,
+    // das koennen wir auch
+    AddCmd("bohr|bohre&loch&in|durch&erde|boden",#'action_bohren,
+           "Was willst du (wohin) @verben?|"
+           "Willst du das Loch in etwas @verben?^|"
+           "@WER3 was willst du das Loch @verben?^");
+    ...
+    private int action_bohren(string str, mixed *param) ...
+
+ ## Variante 5, MIT REGEL, FEHLERMELDUNG, RETURN 1, OHNE FUN ##
+    // und falls in action_bohren() nichts ausser Ausgaben passiert, koennen
+    // wir uns die auch ganz sparen indem wir eine nichterfuellbare Regel
+    // samt Fehlermeldung bauen
+    AddCmd("bohr|bohre&loch&in|durch&erde|boden&\nimpossible",0,
+           "Was willst du (wohin) @verben?|"
+           "Willst du das Loch in etwas @verben?^|"
+           "@WER3 was willst du das Loch @verben?^|"
+           "Du @verbst ein Loch @WER3 den Boden.^@WER1 @verbt "
+           "ein Loch @WER3 den Boden.");
+
+   --- Ende Komplexbeispiel Regeln mit Fehlermeldungen ---
+
+## Komplexbeispiel: Spezialregeln @PRESENT und @ID ##
+ ## Variante 1, OHNE REGELN ##
+    // oft agieren Kommandos auf Objekten im Raum, diese muessen dabei per
+    // present() identifiziert werden:
+    // Beispiel ist ein Geldautomat (den man besser mit einem Container
+    // mit PreventInsert() basteln sollte)
+    AddCmd(({"stopf","stopfe"}),#'action_stopf);
+    ...
+    private int action_stopf(string str) {
+     string tmp,tmp2;
+     object o;
+
+     if(str && (sprintf("%s in automat%s",tmp,tmp2)==2 ||
+                sprintf("%s in geldautomat%s",tmp,tmp2)==2 ||
+                sprintf("%s in bankomat%s",tmp,tmp2)==2) {
+      o=present(tmp,this_player());
+      if(o) {
+       if(o->QueryProp(...)) {
+        write(break_string(
+         "Du stopfst "+o->name(WEN,1)+" in den Automaten.",78));
+        say(...);
+       } else {
+        write(break_string(
+         "Du versuchst "+o->name(WEN,1)+" in den Automaten zu stopfen, "
+         "aber "+o->QueryPronoun(WER)+" passt nicht hinein.",78));
+        say(...);
+       }
+      } else {
+       write("Was willst du in den Automaten stopfen?\n");
+       say(....);
+      }
+      return 1;
+     }
+     notify_fail("Was willst du wohin stecken?\n");
+     return 0;
+    }
+
+ ## Variante 2, MIT REGEL ##
+    // einerseits koennen wir das Finden von Objekten in Inv und Env
+    // integrieren und uns andererseits das Aufzaehlen aller IDs des
+    // Automaten ersparen
+    AddCmd("steck|stecke&@PRESENT&in&@ID",#'action_stopf,
+           "Was willst du wohin stopfen?|"
+           "Willst du @WEN2 in etwas stopfen?|"
+           "Wohinein willst du @WEN2 stopfen?");
+    ...
+    // dabei werden wie immer die gefunden Matches als Parameterarray
+    // uebergeben ... und die @PRESENT und @ID als Objekte!
+    private int action_stopf(string str, mixed *param) {
+     if(param[0]->QueryProp(...)) {
+      write(break_string(
+       "Du stopfst "+param[0]->name(WEN,1)+" in den Automaten.",78));
+      say(...);
+     } else {
+      write(break_string(
+       "Du versuchst "+param[0]->name(WEN,1)+" in den Automaten zu "
+       "stopfen, aber "+param[0]->QueryPronoun(WER)+" passt nicht "
+       "hinein.",78));
+      say(...);
+     }
+     return 1;
+    }
+
+   --- Ende Komplexbeispiel Spezialregeln @PRESENT und @ID  ---
+
+## Komplexbeispiel: gleiches Verb, mehrere Regeln ##
+ // Das Problem mehrerer Regeln fuer ein Kommandoverb besteht darin, dass
+ // letztlich nur eine der Fehlermeldungen zum Tragen kommt - welche
+ // genau ist etwas vage.
+ // Dabei kann man sich auf eines verlassen: juengere AddCmd werden
+ // zuerst ausgewertet. Wenn sich das aendert, tretet euren EM.
+
+ ## Problem 1: Mehrere Regeln weil mehrere Zwecke ##
+    ## Variante 1 - GLEICHLAUTENDE FEHLERMELDUNG
+    // fuer alles wird eine identische Fehlermeldung gesetzt, das ist
+    // natuerlich nicht sehr flexibel oder schoen
+    AddCmd("kriech|krieche&hoch|hinauf|hinaus|heraus|raus",#'result_kriech,
+           "Wohin willst Du kriechen?");
+    AddCmd("kriech|krieche&nach&oben",#'result_kriech,
+           "Wohin willst Du kriechen??|Wohin willst Du kriechen?");
+    AddCmd("kriech|krieche&aus&loch|grube|falle",#'result_kriech);
+           "Wohin willst Du kriechen?|Wohin willst Du kriechen?");
+
+    // oder man versucht eine bessere Regel zu schaffen, was hier durch
+    // die Moeglichkeit von zwei oder drei Parameter unmoeglich ist
+
+    ## Variante 2 - EIGENE AUSWERTUNG
+    // es bietet sich also eigene Weiterauswertung an, was durch die
+    // Uebergabe der getriggerten Verben erleichtert wird:
+    AddCmd("kriech|krieche&hoch|hinauf|hinaus|heraus|raus|aus|nach",
+           #'result_kriech,
+           "Wohin willst Du kriechen?");
+    ...
+    static int result_kriech(string str, mixed *extra) {
+      if(member(extra,"aus")>=0 &&
+         !sizeof(({str}),"*.\\<(hoehle|grube|falle)\\>.*"))
+       notify_fail("Woraus willst Du kriechen?\n");
+      else if(member(extra,"nach")>=0 && strstr(str,"oben")<0)
+       notify_fail("In welche Richtung willst Du kriechen?\n");
+      else if(this_player()->QueryAttribute(A_DEX)>10 ||
+              member(holding_root,this_player())) {
+        write("Du kriechst mit Muehe heraus.\n");
+        this_player()->move((XXXROOM+"draussen"), M_GO, 0,
+                            "kriecht mit Muehe aus der Grube",
+                            "kriecht aus einer Grube");
+        return 1;
+      } else
+        write("Du bist zu ungeschickt, halt Dich irgendwo fest.\n");
+        return 1;
+      }
+      return 0;
+    }
+    // (ob sich der Aufwand fuer diese Beispielsyntax lohnt ist fraglich)
+
+ ## Problem 2: mehrere Regeln, weil optionale Parameter ##
+    // Manchmal will man optionale Parameter erlauben, die aber eine
+    // Wirkung zeigen sollen:
+    AddCmd("schlag|schlage&@ID&hart",#'action_schlag_hart,
+           "Was oder wen willst du @verben?|"
+           "Wie willst du @WEN2 schlagen?");
+    AddCmd("schlag|schlage&@ID",#'action_schlag,
+           "Was oder wen willst du @verben?");
+
+    // Da juengere AddCmd aelteren vorgehen, wird die komplexere Regel samt
+    // ihrer Fehlermeldung nie ausgewertet, da ein "schlag ball hart" auch
+    // die zweite Regel triggert.
+
+    // anders herum:
+    AddCmd("schlag|schlage&@ID",#'action_schlag,
+           "Was oder wen willst du @verben?");
+    AddCmd("schlag|schlage&@ID&hart",#'action_schlag_hart,
+           "Was oder wen willst du @verben?|"
+           "Wie willst du @WEN2 schlagen?");
+
+    // Jetzt wird die komplexere Regel zuerst ueberprueft und triggert
+    // auch die richtige Funktion.
+    // Leider kommt die Fehlermeldung nie zum Tragen, denn was durch Regel 2
+    // durchfaellt, triggert entweder Regel 1 oder faellt auch durch Regel 1
+    // durch und ueberschreibt dabei die Meldung.
+
+    AddCmd("schlag|schlage&@ID",#'action_schlag,
+           "Was oder wen willst du wie @verben?");
+    AddCmd("schlag|schlage&@ID&hart",#'action_schlag_hart);
+
+    // Fast perfekt. Besser wird es nicht.
+
+
+    --- Ende Komplexbeispiel mehrere Regeln ---
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/AddDefender.rst b/doc/sphinx/lfun/AddDefender.rst
new file mode 100644
index 0000000..ae5b28b
--- /dev/null
+++ b/doc/sphinx/lfun/AddDefender.rst
@@ -0,0 +1,51 @@
+AddDefender()
+=============
+
+FUNKTION
+--------
+::
+
+	void AddDefender(object friend);
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+	friend
+	  Objekt (normal Lebewesen), welches zukuenftig ueber Angriffe
+	  informiert werden soll oder diese sogar abwehrt.
+
+BESCHREIBUNG
+------------
+::
+
+	Ein Lebewesen, welches angegriffen wird, kann andere Objekte ueber
+	einen solchen Angriff per InformDefend() informieren oder ihnen
+	sogar die Moeglichkeit geben, per DefendOther() direkt in den
+	laufenden Angriff einzugreifen (Schaeden abwehren oder umwandeln).
+	Im Normalfall handelt es sich hierbei um andere Lebewesen, welche
+	als Verteidiger des angegriffenen Lebewesens auftreten: Daher der
+	Name der Funktion.
+	Die Objekte sind in Form eines Arrays in der Property P_DEFENDERS
+	abgespeichert und koennen dort abgerufen werden. Natuerlich kann
+	man weitere Objekte direkt dort eintragen, jedoch sollte man die
+	hierfuer bereitgestellte Funktionen AddDefender() verwenden.
+	Zum Loeschen von Eintraegen im Array steht ebenfalls eine Funktion
+	bereit: RemoveDefender().
+
+SIEHE AUCH
+----------
+::
+
+	RemoveDefender(), InformDefend(), DefendOther(),
+	P_DEFENDERS, /std/living/combat.c
+
+
+Last modified: Thu Jul 29 18:48:45 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/AddDetail.rst b/doc/sphinx/lfun/AddDetail.rst
new file mode 100644
index 0000000..69db5da
--- /dev/null
+++ b/doc/sphinx/lfun/AddDetail.rst
@@ -0,0 +1,110 @@
+AddDetail()
+===========
+
+FUNKTION
+--------
+::
+
+    void AddDetail(string|string* keys,
+                   string|string*|mapping|closure desc);
+
+DEFINIERT IN
+------------
+::
+
+    /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+    keys
+      String oder Array von Strings mit den Namen der Details.
+    desc
+      String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+
+BESCHREIBUNG
+------------
+::
+
+    Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
+    bei der Untersuchung aussehen, haengt im wesentlichen vom Typ der
+    Beschreibung <desc> ab:
+      <desc> ist ein String.
+        Beim Untersuchen wird dieser String zurueckgegeben.
+      <desc> ist ein String-Array.
+        Beim Untersuchen wird zufaellig einer der Strings zurueckgegeben.
+      <desc> ist ein Mapping.
+        Das Mapping muss folgenden Aufbau haben:
+          ([0:        "Defaulttext",
+            "rasse1": "r1text", ...]).
+
+        Falls fuer die Rasse des das Detail untersuchenden Spielers ein
+        Eintrag im Mapping existiert, wird der entsprechende Text
+        zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
+        rassenabhaengige Details moeglich. Siehe auch die Beispiele.
+      <desc> ist eine Closure.
+        In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
+        zurueckgegeben. Die Closure bekommt dabei den Namen des Details
+        als Parameter uebergeben.
+
+    Fuer Details koennen Forscherpunkte eingetragen werden.
+
+BEISPIELE
+---------
+::
+
+    Ein schlichtes Detail:
+
+      AddDetail(({"sofa","couch"}), "Eine kleine Couch.\n");
+
+    Laengere Details sollten hierbei nicht per Hand umgebrochen werden,
+    sondern man kann hierzu die Funktion break_string() nutzen:
+
+      AddDetail("detail", break_string(
+        "Du wolltest es ja nicht anders, jetzt musst Du Dir dieses "
+        "fuerchterlich lange Detail durchlesen!!!", 78));
+
+    Noetige Zeilenumbrueche bei Zeilenlaengen groesser 77 werden so
+    automatisch generiert.
+    Ein rassenabhaengiges Detail:
+
+      AddDetail(({"bett","bettchen"}),
+        ([0      :"Eine kleines Bett.\n", // Der Defaulttext
+          "zwerg":                        // Die Rasse klein schreiben
+                "Das Bett laedt geradezu zu einem Nickerchen ein.\n"]));
+
+    Und nun ein Detail mit Closure (diese Version ersetzt das Verhalten
+     von AddSpecialDetail).
+
+      int hebel_betaetigt;
+      ...
+      string hebel(string str); // Funktion bekannt machen (Prototyping)
+      ...
+      AddDetail(({"hebel","schalter"}), #'hebel);
+      ...
+      string hebel(string key) {
+        if(hebel_betaetigt)
+          return "Der "+capitalize(key)+" steht auf EIN.\n";
+        else
+          return "Der "+capitalize(key)+" steht auf AUS.\n";
+      }
+
+    Man erhaelt verschiedene Ergebnisse beim Untersuchen, je nachdem
+    ob das Flag hebel_betaetigt gesetzt ist oder nicht.
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddReadDetail(), AddSmells(), AddSounds(),
+               AddTouchDetail()
+    Loeschen:  RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+               RemoveSounds(), RemoveTouchDetail()
+    Daten:     P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS,
+               P_TOUCH_DETAILS, P_SPECIAL_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+    Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddDrink.rst b/doc/sphinx/lfun/AddDrink.rst
new file mode 100644
index 0000000..7ced4bb
--- /dev/null
+++ b/doc/sphinx/lfun/AddDrink.rst
@@ -0,0 +1,19 @@
+AddDrink()
+==========
+
+BEMERKUNGEN
+-----------
+::
+
+        Die Funktion AddDrink() sollte NICHT MEHR BENUTZT werden.
+        Bitte AddToMenu() verwenden.
+
+SIEHE AUCH
+----------
+::
+
+	AddToMenu(), RemoveFromMenu()
+
+
+Last modified: Fri Mar 03 13:23:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/lfun/AddExit.rst b/doc/sphinx/lfun/AddExit.rst
new file mode 100644
index 0000000..6c619fd
--- /dev/null
+++ b/doc/sphinx/lfun/AddExit.rst
@@ -0,0 +1,114 @@
+AddExit()
+=========
+
+FUNKTION
+--------
+::
+
+     void AddExit(string|string* cmd, closure|string dest);
+
+DEFINIERT IN
+------------
+::
+
+     /std/room/exits
+
+ARGUMENTE
+---------
+::
+
+     string/string* cmd
+          die Richtung(en), in die der Ausgang fuehrt
+     string/closure dest
+          das Ziel des Ausgangs mit Text/Closure
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird ein Ausgang in die Richtung(en) cmd eingefuegt. Die Art des
+     Ausgangs haengt ab von dest:
+
+     - ein String:
+       - mit einem Dateinamen:
+         Der Ausgang fuehrt in den Raum, den der Dateiname bezeichnet.
+       - der Form "<msg>#dateiname"
+         Der Ausgang fuehrt in den Raum, den der Dateiname bezeichnet,
+         bei der Benutzung wird jedoch statt "<name> geht nach <richtung>"
+         "<name> geht nach <msg>" ausgegeben.
+     - eine Closure:
+       Die Closure wird bei Nutzung des Ausgangs aufgerufen. Das entspricht
+       eine SpecialExit - in der gerufenen Funktion muss man den Spieler
+       selbst in den Zielraum bewegen.
+       Gegebenenfalls kann das durch AddCmd() ersetzt werden.
+
+BEMERKUNGEN
+-----------
+::
+
+     Man kann fuer den Dateinamen des Zielraumes auch einen relativen Pfad
+     angeben. Die Auswertung erfolgt nach folgendem Schema:
+     - "./<dateiname>"
+       Es wird ein Zielraum relativ zum gleichen Verzeichnis wie dieser
+       Raum angesprochen.
+     - "../<dateiname>"
+       Es wird ein Zielraum relativ zur Verzeichnisebene ueber der
+       dieses Raumes angesprochen (analog mit mehrerern "../..")
+
+     Mittels P_HIDE_EXITS kann man Ausgaenge verstecken.
+
+     Bei der Benutzung eines Ausgangs wird der Hook H_HOOK_EXIT_USE
+     ausgeloest.
+
+BEISPIELE
+---------
+::
+
+     ### normale Ausgaenge ###
+     // Beim Kommando "sueden" kommt: "<name> geht nach Sueden."
+     AddExit("sueden", "/gilden/abenteurer");
+
+     // Beim Kommando "sueden" kommt: "<name> geht in die Gilde."
+     AddExit("sueden", "in die Gilde#/gilden/abenteurer");
+
+     ### Ausgaenge mit relativen Pfaden ###
+     // Der Name des Raumes sei "/d/inseln/wargon/hafen1"
+     // Dieser Ausgang geht nach "/d/inseln/wargon/kneipe":
+     AddExit("norden", "./kneipe" );
+
+     // Und dieser nach "/d/inseln/anthea/anlege":
+     AddExit("sueden", "../anthea/anlege" );
+
+     ### dynamische Ausgaenge ###
+     // ein Ausgang soll nur von Froeschen benutzbar sein:
+
+     static int lochfkt(string dir);		// Prototyp
+     ...
+     AddExit("loch", #'lochfkt);
+     // auch identisch zu:
+     // AddSpecialExit("loch", #'lochfkt); [eine Closure] oder
+     // AddSpecialExit("loch", "lochfkt"); [ein Funktionsname]
+
+     static int lochfkt(string dir) {
+       if (!(this_player()->QueryProp(P_FROG))) {
+         // Kein Frosch => passt nicht!
+         notify_fail("Du bist zu gross!\n");
+         return 0;
+       }
+       // Meldungen werden im move() gleich mitgegeben
+       return this_player()->move("/room/loch", M_GO, 0,
+                    "huepft ins Loch", "huepft herein");
+     }
+
+SIEHE AUCH
+----------
+::
+
+     AddSpecialExit(), GetExits(),
+     RemoveExit(), RemoveSpecialExit(),
+     GuardExit(),
+     H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
+     ausgaenge
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/AddExp.rst b/doc/sphinx/lfun/AddExp.rst
new file mode 100644
index 0000000..eb836ca
--- /dev/null
+++ b/doc/sphinx/lfun/AddExp.rst
@@ -0,0 +1,56 @@
+AddExp()
+========
+
+FUNKTION
+--------
+::
+
+     int AddExp(int e)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+     int e - Anzahl der hinzuzufuegenden (abzuziehenden) XP
+
+BESCHREIBUNG
+------------
+::
+
+     Dem Living werden e XP auf seine bisherigen P_XP addiert.
+
+     Falls es sich um einen Spieler mit P_KILLS>0 handelt und
+     e positiv ist, bekommt der Spieler keine XP gutgeschrieben.
+
+     P_LAST_XP wird aktualisiert.
+
+BEMERKUNG
+---------
+::
+
+     - positive und negative Werte sind moeglich
+     - P_XP wird nicht <0 gesetzt.
+
+RUECKGABEWERT
+-------------
+::
+
+     int - neuer XP-Wert
+
+SIEHE AUCH
+----------
+::
+
+     Funktionen:  do_damage(), DistributeExp()
+     Properties:  P_XP, P_LAST_XP
+     Sonstiges:   P_NO_XP, P_NO_SCORE
+                  create_default_npc()
+
+14.Feb 2007 Gloinson
+
diff --git a/doc/sphinx/lfun/AddExtraLook.rst b/doc/sphinx/lfun/AddExtraLook.rst
new file mode 100644
index 0000000..30b255a
--- /dev/null
+++ b/doc/sphinx/lfun/AddExtraLook.rst
@@ -0,0 +1,131 @@
+AddExtraLook()
+==============
+
+AddExtraLook()
+varargs int AddExtraLook(string look, [int duration, string key,
+                         string lookende, object ob]);
+--------------------------------------------------------------------------------------------------------------------------------------
+::
+
+DEFINIERT IN
+------------
+::
+
+   /std/living/description.c
+
+BESCHREIBUNG
+------------
+::
+
+   Der Extralook erscheint in der Langbeschreibung des Lebewesens.
+   Eintraege koennen mit dieser Funktion hinzugefuegt werden. Dies ist der
+   bevorzugte Weg, wenn ansonsten extra ein Objekt im Spielerinventar abgelegt
+   werden muesste.
+
+   
+
+   Alle Parameter bis auf <look> sind optional.
+
+ARGUMENTE
+---------
+::
+
+  - string look:
+    String, der in der Langbeschreibung des Lebewesens zusaetzlich ausgegeben
+    wird.
+    Kann auch ein Funktionsname sein, wenn <ob> angegeben wird (s.u.).
+  - int duration:
+    > 0: Wie lang bleibt der Extralook gueltig (in Sekunden)? Anschliessend 
+         wird er automatisch geloescht.
+    0:   Dieser Eintrag bleibt unbegrenzt gueltig.
+    < 0: Dieser Eintrag bleibt bis zum Ende/Reboot bestehen.
+  - string key:
+    Schluesselwort, unter dem der Eintrag registriert wird und mit dem man ihn
+    auch mittels RemoveExtraLook() entfernen kann. Sollte natuerlich
+    moeglichst eindeutig sein. ;-) Wenn <key> nicht angeben wird, wird der 
+    Objektname (object_name()) benutzt.
+  - string lookende:
+    String, der an das Lebewesen (nur bei Spielern) ausgegeben wird, wenn der
+    eingetragene Extralook abgelaufen ist.
+    Kann auch ein Funktionsname sein, wenn <ob> angegeben wird.
+  - object ob:
+    Wenn hier ein Objekt angegeben wird, werden <look> und <lookende> als
+    Funktonsnamen aufgefasst. Diese Funktionen werden in <ob> aufgerufen, wenn
+    der Extralook des Lebewesen angezeigt wird bzw. der eingetragene Extralook
+    abgelaufen ist. Diese Funktionen bekommen das jeweilige Lebenwesen als
+    Objekt uebergeben. Sie muessen einen String zurueckliefern, der ausgegeben
+    wird. Dieser String wird direkt so ausgeben, also selber fuer Zeilenumbruch
+    etc. sorgen!
+    WICHTIG: Das Objekt sollte nach Moeglichkeit eine Blueprint sein, da das
+    ganze nix mehr ausgibt, sobald der Clone zerstoert wird, falls hier 
+    einer angeben wird. Wenn ihr keine BP uebergebt: Wisst, was ihr tut. ;-)
+
+RUECKGABEWERTE
+--------------
+::
+
+  > 0, falls der Eintrag erfolgreich registriert wurde.
+  < 0 sonst.
+    -1: <key> war nicht gueltig und es konnte keiner ermittelt werden.
+    -2: <look> war kein gueltiger String.
+    -3: <duration> war kein Integer.
+    -4: unter <key> gibt es schon einen Eintrag.
+
+BEMERKUNGEN
+-----------
+::
+
+  Die Strings <look> und <lookende> werden vor Ausgabe durch
+  replace_personal() geschickt, daher ist die Verwendung von @WER1, @WESSEN1
+  usw. moeglich (s. replace_personal). Dies gilt aber _nicht_ fuer den Fall,
+  dass die entsprechenden Funktionen in <ob> gerufen werden, dann muessen die
+  Funktionen selber umbrechen, etc.
+  Nach replace_personal() werden die Strings noch von break_string() auf 78
+  Zeilen umgebrochen, allerdings bleiben dabei vorhandene Umbrueche erhalten.
+  Die Meldung von <lookende> bzw. der Funktionsaufruf erfolgt, wenn der
+  Extralook der Lebewesen das erste Mal nach Ablauf der Gueltigkeit aufgerufen
+  wird.
+
+BEISPIELE
+---------
+::
+
+  # einfacher Eintrag, "fuer die Ewigkeit"
+  living->AddExtraLook("@WER1 hat den Drachengott der SSP besiegt.");
+
+  # Eintrag der nach 1h automatisch weg ist.
+  living->AddExtraLook("@WER1 ist ganz mit Marmelade bedeckt.", 3600);
+
+  
+
+  # Eintrag mit bestimmten Schluessel, damit man ihn wieder entfernen kann.
+  living->AddExtraLook("@WER1 ist ganz mit Marmelade bedeckt.", 3600,
+                       "humni_marmeladen_look");
+
+  
+
+  # Mit "Ende"-Meldung, aber kein eigener Schluessel.
+  living->AddExtraLook("@WER1 ist patschnass.", 1200, 0,
+                       "Du bist endlich wieder trocken. Puuh.");
+
+  
+
+  # Mit Objekt, was den Extralook dynamisch erzeugt
+  living->AddExtraLook("get_my_special_extralook", 3600, 0, 0, this_object());
+    In diesem Fall muss this_object() natuerlich die Funktion
+    "get_my_special_extralook()" definieren, die einen String zurueckgibt.
+
+  # Mit Objekt, was den Extralook und die Endemeldung dynamisch erzeugt
+  living->AddExtraLook("get_my_special_extralook", 3600, 0,
+                       "extralookende", this_object());
+
+SIEHE AUCH
+----------
+::
+
+   RemoveExtraLook(),
+   replace_personal(), break_string()
+   P_INTERNAL_EXTRA_LOOK
+
+14.05.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/AddFixedObject.rst b/doc/sphinx/lfun/AddFixedObject.rst
new file mode 100644
index 0000000..c61c2f7
--- /dev/null
+++ b/doc/sphinx/lfun/AddFixedObject.rst
@@ -0,0 +1,81 @@
+AddFixedObject()
+================
+
+FUNKTION
+--------
+::
+
+        varargs void AddFixedObject(string str, int val, mixed ids);
+
+DEFINIERT IN
+------------
+::
+
+        /std/room/shop.c
+
+ARGUMENTE
+---------
+::
+
+        str
+          Der absolute Filename eines Objekts, das in quasi beliebiger Menge
+          vom betreffenden Laden verkauft werden soll.
+        val
+          Sofern angegeben der angenommene Wert des Objekts. Falls val nicht
+          angegeben oder 0 ist, wird der Wert aus dem angegebenen Objekt
+          selbst ermittelt.
+          Der Verkaufspreis ist 3 * Wert des Objekts.
+        ids
+          String oder Stringarray mit der ID oder den IDs, ueber die man das
+          Objekt im Laden ansprechen kann. Falls nicht angegeben, wird die
+          ID-Liste aus der blueprint des Objekts ausgelesen.
+
+BESCHREIBUNG
+------------
+::
+
+        Mit dieser Funktion kann man einem Laden mitteilen, dass ein Objekt
+        in ihm in unbegrenzter Anzahl verkauft werden soll.
+        WICHTIG: Das zu verkaufende Objekt sollte dies insofern unterstuetzen, 
+        dass die Blueprint die notwendigen Informationen
+        (P_SHORT, P_IDS, P_VALUE, P_LONG, P_NAME) beinhaltet. Dies bedeutet im
+        einfachsten Fall, dass im create() auf
+          if (!clonep()) return;
+        verzichtet wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+        keiner
+
+        
+
+BEISPIELE
+---------
+::
+
+        AddFixedObject("/obj/fackel", 5000, "fackel");
+          Der Laden verkauft Fackeln zum Preis von 3*5000 Goldmuenzen und man
+          kann die Fackel (ausser ueber die Inventarnummer) nur mittels der
+          id "fackel" kaufen.
+
+          
+
+        AddFixedObject("/obj/fackel");
+          Der Laden verkauft Fackeln zum dreifachen Wert dessen, was im Objekt
+          /obj/fackel.c angegeben ist (derzeit sind das 5 Muenzen) und laesst
+          alle IDs zu, die in /obj/fackel.c angegeben sind. Derzeit ist das
+          auch nur "fackel".
+
+SIEHE AUCH
+----------
+::
+
+	RemoveFixedObject(), SetStorageRoom(), /std/store.c
+
+        
+
+----------------------------------------------------------------------------
+Letzte Aenderung: Sat Nov  9 12:59:25 2002 durch Bambi
+
diff --git a/doc/sphinx/lfun/AddFood.rst b/doc/sphinx/lfun/AddFood.rst
new file mode 100644
index 0000000..30bea9d
--- /dev/null
+++ b/doc/sphinx/lfun/AddFood.rst
@@ -0,0 +1,19 @@
+AddFood()
+=========
+
+BEMERKUNGEN
+-----------
+::
+
+        Die Funktion AddFood() sollte NICHT MEHR BENUTZT werden.
+        Bitte AddToMenu() verwenden.
+
+SIEHE AUCH
+----------
+::
+
+        AddToMenu(), RemoveFromMenu()
+
+
+Last modified: Fri Mar 03 13:23:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/lfun/AddFuel.rst b/doc/sphinx/lfun/AddFuel.rst
new file mode 100644
index 0000000..a4af00b
--- /dev/null
+++ b/doc/sphinx/lfun/AddFuel.rst
@@ -0,0 +1,52 @@
+AddFuel()
+=========
+
+FUNKTION
+--------
+::
+
+     void AddFuel(int fuel);
+
+DEFINIERT IN
+------------
+::
+
+     /std/lightsource.c
+
+ARGUMENTE
+---------
+::
+
+     fuel
+          Die zusaetzliche Brenndauer in Sekunden.
+
+BESCHREIBUNG
+------------
+::
+
+     Die Brenndauer der Lichtquelle wird um fuel Sekunden verlaengert.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Es werden keine Checks durchgefuehrt! Wenn man seine Lichtquelle
+     nachfuellbar gestalten will, sollte die Nachfuellfunktion vor dem
+     AddFuel()-Aufruf nachsehen, wie voll die Lichtquelle noch ist, und fuel
+     entsprechend begrenzen.
+
+SIEHE AUCH
+----------
+::
+
+     /std/lightsource.c
+
+
+Last modified: Wed May 8 10:16:39 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/AddFun.rst b/doc/sphinx/lfun/AddFun.rst
new file mode 100644
index 0000000..4e3856a
--- /dev/null
+++ b/doc/sphinx/lfun/AddFun.rst
@@ -0,0 +1,86 @@
+AddFun()
+========
+
+FUNKTION
+--------
+::
+
+     void AddFun(string fun, int next);
+
+DEFINIERT IN
+------------
+::
+
+     /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+     fun
+          Name der Funktion.
+     next
+          Zeit bis zur naechsten Fahrplanstation.
+
+BESCHREIBUNG
+------------
+::
+
+     Dem Fahrplan wird der Aufruf der Funktion fun, die im Transporter
+     definiert sein muss, hinzugefuegt. Nach Aufruf der Funktion vergehen
+     next Sekunden, bis die naechste Station angefahren wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEISPIELE
+---------
+::
+
+     Wenn ein zufaellig ausgewaehlter Passagier eines Schiffes unterwegs
+     seekrank werden soll, koennte man das wie folgt realisieren:
+
+     create()
+     {
+       ...
+
+       AddFun("seekrank", 5);
+       ...
+     }
+
+     seekrank()
+     {
+       object *passagiere, opfer;
+
+       // soll nicht immer passieren
+       if (random(5))
+         return;
+
+       // Opfer auswaehlen
+       passagiere = QueryPassengers();
+       if (sizeof(passagiere))
+         opfer = passagiere[random(sizeof(passagiere))];
+
+       // Und viel Spass...
+       tell_object(opfer,
+         "Du wirst seekrank! Schnell stuerzt Du zur Reling um  Dich zu\n"
+        +"uebergeben.\n");
+       tell_room(this_object(),
+         sprintf("%s ueberkommt die Seekrankheit!\n%s stuerzt an die Reling, "
+                +"um sich zu uebergeben.\n",
+                 capitalize(opfer->name(WEN)),
+                 capitalize(opfer->QueryPronoun(WER))), ({ opfer }) );
+     }
+
+SIEHE AUCH
+----------
+::
+
+     AddRoute(), AddMsg(), /std/transport.c
+
+
+Last modified: Wed May 8 10:16:46 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/AddId.rst b/doc/sphinx/lfun/AddId.rst
new file mode 100644
index 0000000..f132960
--- /dev/null
+++ b/doc/sphinx/lfun/AddId.rst
@@ -0,0 +1,74 @@
+AddId()
+=======
+
+FUNKTION
+--------
+::
+
+     void AddId(string|string* ids);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     ids
+          String oder Array von Strings mit den Bezeichnungen, mit denen
+          sich sich das Objekt ansprechen lassen soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Jedes Objekt sollte sich auf die eine oder andere Weise ansprechen
+     lassen. Zu diesem Zweck kann man dem Objekt mit dieser Funktion
+     Bezeichner uebergeben.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Jedes Objekt sollte man zumindest mit seiner Kurzbeschreibung
+     ansprechen koennen! Fuer Abfragen von Questobjeken o.ae. sollte man
+     zusaetzlich IDs verwenden, die Sonderzeichen wie "\n" oder "\t"
+     enthalten, damit sichergestellt ist, dass der Spieler auch wirklich die
+     richtigen Objekte dabeihat.
+
+BEISPIELE
+---------
+::
+
+     AddId( "buch" );
+     AddId( "buechlein" );
+
+     Das Objekt laesst sich jetzt als "buch" und als "buechlein" ansprechen.
+
+     AddId( ({ "buch", "buechlein" }) );
+
+     Diese Zeile bewirkt das gleiche wie die obigen zwei Zeilen.
+
+     AddId( ({ "puzzle", "\nquest_puzzle" }) );
+
+     Der Spieler kann das Objekt als "puzzle" ansprechen, questrelevante
+     Objekte koennen mit der ID "\nquest_puzzle" nach ihm suchen.
+
+SIEHE AUCH
+----------
+::
+
+     AddAdjective(), RemoveId(), id(), present(), /std/thing/description.c
+
+     -----------------------------------------------------------------------
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddInfo.rst b/doc/sphinx/lfun/AddInfo.rst
new file mode 100644
index 0000000..2a7928a
--- /dev/null
+++ b/doc/sphinx/lfun/AddInfo.rst
@@ -0,0 +1,243 @@
+AddInfo()
+=========
+
+FUNKTION
+--------
+::
+
+     varargs void AddInfo( frage, meldung
+			   [, indent [, [silent [, casebased] ] ] );
+
+DEFINIERT IN
+------------
+::
+
+     /std/npc/info.c
+
+ARGUMENTE
+---------
+::
+
+     string/string* frage
+	Schluesseltext(e) auf die Informationen gegeben werden sollen.
+     string/closure meldung
+	Information, die gegeben werden soll/Closure
+     string indent
+	Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
+     int/string silent
+	Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
+     string/closure casebased
+	Closure mit Returnwert string oder int.
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn ein Spieler ein NPC mittels "frage <monstername> nach <frage>" nach
+     einer Information mit dem Schluessel 'frage' fragt, so wird die
+     entsprechende 'meldung' ausgegeben (oder die Closure in 'meldung'
+     gerufen und der zurueckgegebene Text ausgegeben). Der Meldung wird
+     der Name des Monsters vorangestellt.
+
+     Frage:
+      Schluessel muessen kleingeschrieben sein, koennen aber Leerzeichen
+      enthalten.
+
+     Meldung:
+      Wenn kein 'indent' angegeben ist, muss man die Meldung selbst
+      umbrechen.
+
+     Indent:
+      Wird ein 'indent' angegeben so wird jeder Zeile hinter dem
+      Monsternamen noch das 'indent' vorangesetzt. Zusaetzlich wird
+      'meldung' auf jeden Fall sauber umgebrochen.
+      Ein typisches indent ist "sagt: ".
+
+     Silent:
+      Bei 'silent'==1 erfolgt keine Textausgabe der Antwortmeldung im Raum,
+      ist 'silent' ein String, so wird jener an alle anderen Spieler ausser
+      dem Fragesteller im Raum ausgegeben.
+
+     Casebased:
+      Die als Closure angegebene Methode entscheidet, ob oder wie der NPC 
+      auf diese Frage antworten soll:
+      - return 0:	normale Antwort mit "meldung"
+      - return 1:	keine Antwort/Antwort mit DEFAULT_NOINFO
+      - return string:	Antwort mit string unter Beruecksichtigung eines
+			indent
+
+     Die Strings von 'silent' und 'meldung' werden geparsed.
+     Dabei koennen die @...-Tags von replace_personal() verwendet werden,
+     Objekt 1 ist this_player(). Ersetzte String am Satzanfang werden
+     automatisch gross geschrieben.
+     AddInfo() konvertiert die alten Schluesselworte @WER, @WESSEN, @WEM,
+     @WEN zu denen von replace_personal().
+
+     Mittels der in <npc.h> definierten Frage DEFAULT_INFO kann eine
+     Meldung gesetzt werden, die gegeben werden soll, wenn der Spieler
+     etwas fragt, auf das keine Antwort vorgegeben ist (das loest
+     SetProp(P_DEFAULT_INFO, <text>) ab).
+
+BEISPIELE
+---------
+::
+
+     ### eine Standardantwort setzen ###
+     AddInfo(DEFAULT_INFO, "starrt Dir boese in die Augen.\n");
+     // identisch zu
+     SetProp(P_DEFAULT_INFO, "starrt Dir boese in die Augen.\n");
+
+     ### einfache Beispiele, auch mit casebased ###
+     AddInfo(({"knete","kohle"}),
+	     "sagt: ich habe so etwas nicht.\n");
+     AddInfo("geld",
+	     "Ich habe zwar kein Geld, aber ... blablabla ...",
+	     "sagt: " );
+     AddInfo("muenzen",
+	     "fluestert: Du willst Geld?\n",
+	     0,
+	     "fluestert @WEM etwas zu.\n");
+
+     // "frage monster nach geld": alle im Raum hoeren
+     //  Das Monster sagt: Ich habe zwar kein Geld, aber ...
+     //  Das Monster sagt: ... blablabla ...
+
+     // "frage monster nach muenzen":
+     // - der Fragensteller hoert:
+     //   "Das Monster fluestert: Du willst Geld?"
+     // - alle andere hoeren:
+     //   "Das Monster fluestert <Fragenstellernamen> etwas zu."
+
+     ### dynamisch ###
+     // ein Prototyp, damit wir die Methode bekannt machen
+     static string query_kekse();
+     ...
+     AddInfo(({"keks","kekse"}),
+	     #'query_kekse,		// ein Verweis auf die Funktion
+	     "sagt: ");
+     ...
+     static string query_kekse() {
+      if(present("keks"))
+       return("Ich hab noch welche. Aetsch!");
+      return("Menno. Keine mehr da!");
+     }
+
+     // "frage monster nach keks":
+     // - wenn es noch Kekse hat, hoeren alle:
+     //   "Das Monster sagt: Ich hab noch welche. Aetsch!
+     // - sonst:
+     //   "Das Monster sagt: "Menno. Keine mehr da!
+
+     ### dynamischer ###
+     // ein Prototyp, damit wir die Methode bekannt machen
+     static string query_kekse();
+     static mixed case_fighting();
+     ...
+     AddInfo(({"keks","kekse"}),
+	     #'query_kekse,"		// ein Verweis auf die Funktion
+	     sagt: ",
+	     0,				// nicht silent :)
+	     #'case_fighting);		// noch ein Funktionsverweis
+     ...
+     static string query_kekse() {
+      if(present("keks"))
+       return("Ich hab noch welche. Aetsch!");
+      return("Menno. Keine mehr da!");
+     }
+
+     static mixed case_fighting() {
+      if(InFight())
+       return("Keine Zeit fuer Kekse. Muss kaempfen.");
+      return 0;
+     }
+
+     // "frage monster nach keks":
+     // - wenn es kaempft, hoeren alle:
+     //   "Das Monster sagt: Keine Zeit fuer Kekse. Muss kaempfen.
+     // - sonst, wenn es noch Kekse hat, hoeren alle:
+     //   "Das Monster sagt: Ich hab noch welche. Aetsch!
+     // - sonst:
+     //   "Das Monster sagt: "Menno. Keine mehr da!
+
+
+     ### dynamisch und komplex ###
+     // ein Prototyp, damit wir die Methode bekannt machen
+     static string question_gold();
+     ...
+
+     // "gold" wird eine Closure auf die Methode question_gold()
+     // zugewiesen, ausserdem soll es still bleiben (wir informieren
+     // den Restraum selbst)
+     AddInfo("gold",#'question_gold,"murmelt: ",1);
+     ...
+
+     // los gehts, wir generieren unsere Antwort selbst
+     static string question_gold() {
+      int money;
+      string *y, objstr;
+      object o;
+      // wieviel Kohle hat der Spieler
+      money=this_player()->QueryMoney();
+      y=allocate(0);
+      // und jetzt suchen wir die Dinge aus Gold
+      o=first_inventory(this_player());
+      while(o) {
+       if(o->QueryMaterial(MAT_GOLD)>0 &&
+          strstr(object_name(o),"/obj/money"))
+        y+=({o->name(WER,1)});
+       o=next_inventory(o);
+      }
+
+      // das geht an alle anderen im Raum, silent bietet sich hier
+      // nicht an, weil es mehrere Moeglichkeiten gibt
+      say(break_string(
+       Name(WER,1)+" murmelt "+
+       this_player()->name(WEM,1)+
+       " etwas zu"+
+       ((money || sizeof(y))?
+        " und glotzt "+
+        this_player()->QueryPronoun(WEN)+" gierig an.":
+        "."),78),({this_player()}));
+
+      // und hier die Antwort an den Spieler selbst, mit vielen
+      // Verzweigungen fuer dessen Besitztum
+      return("Ich hab kein Gold bei mir."+
+          ((money || sizeof(y))?
+           " Aber du "+
+           (money?"hast ja jede Menge Kohle bei dir, so etwa "+money+
+            " Muenzen."+
+            (sizeof(y)?
+             " Ausserdem "+
+             ((sizeof(y)==1)?"ist":"sind")+
+             " auch noch "+CountUp(y)+" aus Gold.":
+             ""):
+            (sizeof(y)?" Aber was du so bei dir hast: "+
+             CountUp(y)+
+             (sizeof(y)==1?" ist":" sind")+
+             " aus Gold.":"")):
+           ""));
+     }
+
+     // "frage monster nach gold"
+     // - der Fragesteller hoert zB:
+     //   Das Monster murmelt: Ich hab kein Gold bei mir. Aber du hast ja
+     //   Das Monster murmelt: jede Menge Kohle bei dir, so etwas <number>
+     //   Das Monster murmelt: Muenzen. Ausserdem ist/sind noch <object1>
+     //   Das Monster murmelt: und <object2> aus Gold."
+     // - die Umstehenden hoeren:
+     //   "Das Monster murmelt @WEM etwas zu."
+     //   oder
+     //   "Das Monster murmelt @WEM etwas zu und glotzt ihn/sie gierig an."
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt:  AddSpecialInfo(L), RemoveInfo(L)
+     Props:     P_PRE_INFO, P_DEFAULT_INFO
+     Files:     /std/npc/info.c
+     Loggen:    P_LOG_INFO
+     Interna:   GetInfoArr, do_frage
+
+7.Apr 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/AddItem.rst b/doc/sphinx/lfun/AddItem.rst
new file mode 100644
index 0000000..8f15949
--- /dev/null
+++ b/doc/sphinx/lfun/AddItem.rst
@@ -0,0 +1,185 @@
+AddItem()
+=========
+
+FUNKTION
+--------
+::
+
+	varargs object AddItem(mixed filename,int refresh,mixed props);
+
+DEFINIERT IN
+------------
+::
+
+	/std/room/items.c
+	/std/npc/items.c
+
+ARGUMENTE
+---------
+::
+
+	filename
+	  String mit dem Namen des zu erzeugenden Objektes oder Array von
+	  Strings mit den Namen der zu erzeugenden Objekte. Bei einem Array
+	  wird ein Name zufaellig ausgewaehlt.
+	refresh
+	  Wann und wie soll das Objekt erneuert werden:
+	  - REFRESH_NONE      - Kein Refresh bis zum Neuladen des Raums
+                        - oder NPCs.
+	  - REFRESH_DESTRUCT  - Refresh bei Reset, wenn Item zerstoert
+	                        wurde.
+	  - REFRESH_REMOVE    - Refresh bei Reset, wenn Item entfernt wurde.
+	  - REFRESH_ALWAYS    - Neuer Clone bei jedem Reset.
+	  - REFRESH_MOVE_HOME - Objekt wird bei Reset automatisch
+	                        zurueckgeholt, wenn es wegbewegt wurde.
+	                        (nur in Raeumen!)
+	  Bei NPC's gilt zusaetzlich:
+	  - CLONE_WEAR       - Item Anziehen, wenn es eine Ruestung ist.
+	  - CLONE_WIELD      - Item zuecken, wenn es eine Waffe ist.
+	  - CLONE_NO_CHECK   - Zuecken oder Anziehen ohne Ueberpruefungen.
+	props (optional)
+	  Mapping mit denen in einem geclonten Objekt zu setzenden
+	  Properties oder 1 fuer die Erzeugung einer Blueprint.
+
+RUeCKGABEWERT
+-------------
+::
+
+	Innerhalb von Raeumen wird das erzeugte Objekt zurueckgeliefert. Bei
+	NPC's klappt dies leider nicht, da dort die Objekte nicht sofort
+	erzeugt werden, sondern erst, nachdem der NPC an seinen
+	Bestimmungsort transferiert wurde. Daher wird bei NPC immer 0 
+	zurueckgegeben.
+
+BESCHREIBUNG
+------------
+::
+
+	Abhaengig von <filename> und <props> wird ein Objekt erzeugt und in
+	den Raum bzw. NPC bewegt. Dabei gibt es folgende Moeglichkeiten:
+	- <filename> ist ein Dateiname.
+	  Es wird ein Clone dieser Datei erstellt oder (wenn <props>=1 ist)
+	  deren Blueprint verwendet.
+	- <filename> ist ein Array von Dateinamen.
+	  Es wird eine Datei zufaellig aus dem Array ausgewaehlt und von
+	  dieser Datei ein Clone erstellt oder (wenn <props>=1 ist) deren
+	  Blueprint verwendet.
+	Uebergibt man fuer <props> ein Mapping mit dem Aufbau
+	  ([prop_name:prop_wert,...]),
+	so werden diese Properties im erzeugten Objekt gesetzt.
+	Der Parameter <refresh> gibt an, was waehrend eines Resets im Raum
+	bzw. in NPC's oder was beim Erzeugen von NPC's geschehen soll:
+	In <rooms.h> sind dazu folgende Moeglichkeiten definiert:
+	- REFRESH_NONE
+            Das Objekt wird niemals erneuert; falls es zerstoert wurde, wird
+	    es erst dann wieder erzeugt, wenn der Raum erneut geladen bzw.
+	    der NPC neu erzeugt wird. Man beachte, dass nicht jeder NPC
+	    wirklich refreshende Objekte benoetigt, REFRESH_NONE spart
+	    hierbei sowohl Rechenzeit als auch Speicher!
+	- REFRESH_DESTRUCT
+	    Das Objekt wird nur dann erneuert, wenn es in der Zwischenzeit
+	    zerstoert wurde (bei NPC's ist das zum Beispiel der Fall, wenn
+	    sie getoetet wurden).
+	    REFRESH_NONE & REFRESH_DESTRUCT + Blueprint-Objekt bedeutet bei
+	    NPC's ein Unique-Objekt, es wird also nicht beim Neuerzeugen des
+	    NPC's zurueckgesetzt.
+	- REFRESH_REMOVE
+	    Das Objekt wird erneuert, wenn es sich nicht mehr im Raum bzw.
+	    im NPC befindet. Das kein sein, weil es zerstoert wurde, aber
+	    auch zum Beispiel in folgenden Faellen:
+	    * weil es jemand mitgenommen hat
+	       (in Raeumen bei Gegenstaenden)
+	    * weil es fortgegangen ist
+	       (in Raeumen bei NPC's, die herumlaufen)
+	    * weil es weggeworfen wurde
+	       (in NPC's bei Gegenstaenden)
+	- REFRESH_ALWAYS
+	    Das Objekt wird immer erneuert. Von dieser Refreshmethode sollte
+	    man allerdings Abstand nehmen, da sich sonst mit der Zeit
+	    gewaltige Mengen von Objekten ansammeln koennen!
+	- REFRESH_MOVE_HOME
+	    Das Objekt wird in einen Raum zurueckbewegt, sofern es noch
+	    existiert, jedoch nicht mehr in dem Raum ist. Sinnvoll ist dies
+	    eigentlich nur fuer Lebewesen, funktioniert aber auch bei
+	    beliebigen Objekten. Hauptsaechlich geht es hierbei darum,
+	    herumlaufende NPCs oder bei erzwungenen Bewegungen nicht von
+	    P_GUARD zurueckgehaltene NPCs wieder an einen definierten
+	    Ausgangsort zurueckzubringen.
+	Hat man in Raeumen als <filename> ein Array von Dateinamen
+	uebergeben, so wird beim Reset jedesmal aufs Neue ein zufaelliges
+	Objekt aus der Liste ausgewaehlt (nicht in NPC's).
+	In NPC's gilt der Grundsatz der Vermeidung von ueberfluessigen
+	Objekten im MUD. Neu erzeugt werden Objekte beim Erzeugen eines
+	NPC's oder bei einem Reset im selbigen. Anstatt die Objekte gleich
+	neu zu erschaffen, wird erst geschaut, ob sich identische Objekte
+	schon im Raum befinden. Ist dies der Fall, so nimmt der NPC sie auf,
+	ruft jedoch vorher nochmals create() in ihnen auf!
+	  (noetig wegen moeglicher Veraenderungen an den Objekten)
+	Was dann passiert, haengt von weiteren Angaben in <refresh> ab.
+	Folgende weitere Moeglichkeiten sind in <npc.h> definiert:
+        - CLONE_WEAR
+	  Ist das hinzugefuegte Item eine Ruestung, so wird sie nach
+	  Aufnahme oder Neuerzeugung angezogen.
+        - CLONE_WIELD
+	  Ist das hinzugefuegte Item eine Waffe, so wird sie nach Aufnahme
+	  oder Neuerzeugung gezueckt.
+        - CLONE_NO_CHECK
+	  Hiermit verhindert man eine Ueberpruefung, ob eine Ruestung
+	  angezogen oder eine Waffe gezueckt werden kann. Es ist jedoch
+	  Vorsicht geboten: So kann es ohne weiteres passieren, dass ein NPC
+	  mehrere Ruestungen gleichen Typs angezogen oder mehrere Waffen
+	  gezueckt hat.
+	Benutzt man Blueprints (<props>=1) mit REFRESH_REMOVE oder
+	REFRESH_ALWAYS, so kann es zu ungewollten Ueberraschungen kommen, da
+	die Blueprint dann unabhaengig von ihrem momentanen Aufenthaltsort
+	wieder in den Raum bzw. NPC bewegt wird, von dem sie erzeugt wurde!
+
+BEMERKUNGEN
+-----------
+::
+
+	Wenn man Blueprints benutzt, sollte man daran denken, dass sich von
+	dieser dann keine Clones mehr erstellen lassen!
+	RemoveItem() zum Entfernen von Items ist nur fuer Raeume definiert!
+
+	Die Option CLONE_NEW ist veraltet. Die Objekte werden nun immer
+	neu erzeugt. Die Option darf noch angegeben werden, hat aber keine
+	Bedeutung mehr.
+
+BEISPIELE
+---------
+::
+
+	// Ein Wuerfel, der sich nach Entfernen erneuert:
+	  AddItem("/obj/misc/wuerfel",REFRESH_REMOVE);
+	// Ein etwas veraenderter Wuerfel:
+	  AddItem("/obj/misc/wuerfel",
+	          REFRESH_REMOVE,
+	          ([P_SHORT :"Ein schwerer Wuerfel",
+	            P_WEIGHT:100]));
+	// Eine Blueprint, die nur einmal im MUD existiert. Wenn sie
+	// zerstoert wurde, wird sie bei Reset neu erzeugt:
+	  AddItem("/mon/angsthase",REFRESH_DESTRUCT,1);
+	// Eine Blueprint, die nur einmal im MUD existiert. Wenn sie aus dem
+	// Raum entfernt wurde, wird sie bei Reset zurueckgeholt:
+	  AddItem("/mon/angsthase",REFRESH_MOVE_HOME,1);
+	// Ein zufaelliges Objekt:
+	  AddItem(({"/obj/misc/lolli",
+	            "/obj/misc/bonbon",
+	            "/obj/misc/bier"}),REFRESH_REMOVE);
+	// Eine Ruestung, die auch angezogen wird (nur in NPC's):
+	  AddItem("/ruestung/sommerkleid",REFRESH_REMOVE|CLONE_WEAR);
+	// Eine Unique-Waffe, die auch gezueckt wird (nur in NPC's):
+	  AddItem("/waffe/zapper",REFRESH_DESTRUCT|CLONE_WIELD,1);
+
+SIEHE AUCH
+----------
+::
+
+	RemoveItem(), replace_program(), create(), P_GUARD,
+	/std/room/items.c, /std/npc/items.c,
+	/sys/rooms.h, /sys/npc.h
+
+
+Last modified: Thu Nov 23 13:43:30 CET 2006 by Rumata
+
diff --git a/doc/sphinx/lfun/AddKnownPotion.rst b/doc/sphinx/lfun/AddKnownPotion.rst
new file mode 100644
index 0000000..50479bb
--- /dev/null
+++ b/doc/sphinx/lfun/AddKnownPotion.rst
@@ -0,0 +1,45 @@
+AddKnownPotion()
+================
+
+FUNKTION
+--------
+::
+
+     int AddKnownPotion(int nr)
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/potion.c
+
+ARGUMENTE
+---------
+::
+
+     int nr       Nummer eines ZTs
+
+BESCHREIBUNG
+------------
+::
+
+     Addiert einen ZT als bekannt in einem Spieler. Nur vom Orakel rufbar.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1  Erfolg
+     -1 fehlende Berechtigung
+     -2 Nummer bereits eingetragen
+
+SIEHE AUCH
+----------
+::
+
+     Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
+     Verwandt:  FindPotion(), RemoveKnownPotion(), InList()
+     Props:     P_POTIONROOMS, P_KNOWN_POTIONROOMS
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/lfun/AddMaterial.rst b/doc/sphinx/lfun/AddMaterial.rst
new file mode 100644
index 0000000..211c51d
--- /dev/null
+++ b/doc/sphinx/lfun/AddMaterial.rst
@@ -0,0 +1,100 @@
+AddMaterial()
+=============
+
+FUNKTION
+--------
+::
+
+     private static varargs void AddMaterial(string mat, int gender,
+                                             mixed names, mixed groups,
+                                             mixed dif) {
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/materialdb.c (MATERIALDB)
+
+ARGUMENTE
+---------
+::
+
+     string mat
+       Materialstring, definiert in <thing/material.h>
+
+     int gender
+       Geschlecht des einzutragenden Materials
+
+     mixed names
+       Name des Materials:
+       - "<Nominativ>" oder (meist nur Nom. und Gen. noetig)
+       - ({"<Nominativ>","<Genitiv>","<Dativ>","<Akkusativ>"})
+
+     mixed groups
+       Eingruppierung des Materials:
+       - MATGROUP_XXX oder ({MATGROUP_XXX,...})
+       - ([MAT_GROUP_XXX:xx,MATGROUP_YYY:yy,...])
+
+     mixed dif
+       Schwierigkeiten bei der Erkennbarkeit:
+       - int x oder ({MINMAT,x1,MATPOS1,x2,MATPOS2 ...})
+       - xn: Erkennbarkeitsschwierigkeit (100=100%) -100..100
+       - MINMAT: Erkennung zumindest als _dieses_ Material
+                 moeglich
+       - MATPOSn: moegliches Material, erkennbar, wenn
+                  Erkennbarkeitfaehigkeit>=xn
+                  -> das letzte MATPOS muss natuerlich
+                     string mat entsprechen
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird in die Materialiendatenbank eine neues Material aufgenommen,
+     die Stringkonstante dafuer wird vorher in <thing/material.h> fest-
+     gelegt. Falls der Genitiv nicht Nominativ+"s" entspricht (z.B. "Seide"),
+     sollte dieser explizit angegeben werden.
+     Nach Neuladen der Datenbank ist dieses Material auch per MaterialName(),
+     'erkennbar' (siehe mixed dif, siehe Beispiel) bzw. seinen einzelnen
+     Gruppen zuordnbar.
+
+BEISPIELE
+---------
+::
+
+     AddMaterial(MAT_NITROGLYCERINE,NEUTER,"Nitroglycerin",
+                 ({MATGROUP_EXPLOSIVE,MATGROUP_FLUID}),
+                 ({MAT_OIL,25,MAT_MISC_EXPLOSIVE,50,MAT_NITROGLYCERINE}));
+
+     Damit wird das Material Nytroglycerin aufgenommen, ein explosiver
+     (damit entflammbarer) sowie fluessiger Stoff. Liegt die Erkennungs-
+     faehigkeit (MaterialName()) unter 25, wird es nur als Oel erkannt,
+     liegt sie unter 50, wird es zumindest als explosives Material erkannt,
+     liegt sie ueber 49, so wird es korrekt erkannt (wie schade :) ).
+
+BEMERKUNGEN
+-----------
+::
+
+     Wird in der create() der Datenbank aufgerufen. Zu beachten:
+     - vor Eintrag eines _neuen_ Materials die Datenbank durchsuchen!
+     - bei den Materialiengruppen die automatischen Abhaengigkeiten in
+       AddMaterial() durchsehen!
+     - bitte Datenbank neu laden
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Methoden:    QueryMaterial(), QueryMaterialGroup(), MaterialList(),
+     Listen:	  AllMaterials(), AllGroups(), Dump()
+		  materialliste, materialgruppen
+     Master:	  ConvMaterialList(), MaterialGroup(),
+		  GroupName(), MaterialName(),
+		  GetGroupMembers(), GetMatMembership()
+     Sonstiges:	  P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/AddMiniQuest.rst b/doc/sphinx/lfun/AddMiniQuest.rst
new file mode 100644
index 0000000..7e4e851
--- /dev/null
+++ b/doc/sphinx/lfun/AddMiniQuest.rst
@@ -0,0 +1,71 @@
+AddMiniQuest()
+==============
+
+FUNKTION
+--------
+::
+
+    int AddMiniQuest(int stupse, string questgeber, string desc, int active,
+                     string titel, string erledigt, mapping voraussetzungen,
+                     string region, string *erlaubte)
+
+DEFINIERT IN
+------------
+::
+
+    /secure/questmaster
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion traegt eine neue Miniquest im Questmaster ein.
+
+ARGUMENTE
+---------
+::
+
+    stupse (>0)  - Anzahl Stufenpunkte, die fuer die MQ gutgeschrieben werden
+    questgeber   - Ladename des Objekts, das GiveMiniQuest() aufruft
+    desc         - Aufgabenbeschreibung der Miniquest
+    active (0/1) - ist die Miniquest aktiv, d.h. spielbar, oder nicht?
+    titel        - Titel der Miniquest, darf weder "in", noch "im" enthalten,
+                   weil dann der Eintrag in der Fraternitas-Bibliothek nicht
+                   gelesen werden kann.
+    erledigt     - Beschreibung der Miniquest, nachdem man sie erledigt hat
+                   Der Text kann in der Bibliothek der kleinen und grossen
+                   Heldentaten in der Fraternitas eingesehen werden.
+    voraussetzungen - Mapping im Format von P_RESTRICTIONS (s. dort), um
+                   die Voraussetzungen festzulegen, die ein Spieler 
+                   erfuellen muss, um die MQ ueberhaupt spielen zu koennen
+                   Wird fuer die regionsbezogenen Informationspunkte/-NPCs
+                   ausgewertet. 0 oder ([]) eintragen, wenn keine 
+                   Voraussetzungen bestehen.
+    region       - Zuordnung der Miniquest zu einer Region; wird fuer der
+                   Bibliothek der Fraternitas verwendet, um die MQs der
+                   einzelnen Regionen herauszufiltern.
+    erlaubte     - Array mit Ladenamen von Objekten, die berechtigt sind,
+                   die Daten der MQ abzufragen, um Spielern einen Hinweis
+                   darauf zu geben, die sie noch nicht bestanden haben.
+
+RUECKGABEWERTE
+--------------
+::
+
+     1: Hat geklappt
+    -1: Parameterformat stimmt nicht (questgeber kein String oder Leerstring,
+        voraussetzungen kein Mapping, region oder titel keine Strings, 
+        erlaubte kein Array)
+    -2: weniger als 1 Stufenpunkt einzutragen versucht
+    -3: Das Array in "erlaubte" ist leer, oder zum angegebenen Questgeber
+        wurde keine Datei gefunden.
+    -4: Der angegebene Questgeber vergibt schon eine andere Miniquest
+
+SIEHE AUCH
+----------
+::
+
+    GiveMiniQuest(L), HasMiniQuest(L)
+    P_RESTRICTIONS
+    /secure/questmaster.c
+
diff --git a/doc/sphinx/lfun/AddMoney.rst b/doc/sphinx/lfun/AddMoney.rst
new file mode 100644
index 0000000..e2d4139
--- /dev/null
+++ b/doc/sphinx/lfun/AddMoney.rst
@@ -0,0 +1,92 @@
+AddMoney()
+==========
+
+AddMoney(L)
+-----------
+::
+
+FUNKTION
+--------
+::
+
+     public int AddMoney(int amount);
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/moneyhandler.c
+     /std/living/moneyhandler.c
+     /std/player/moneyhandler.c
+
+ARGUMENTE
+---------
+::
+
+     int amount
+         Die zufuehrende oder abziehende Geldmenge
+
+BESCHREIBUNG
+------------
+::
+
+     Dem Spieler wird die in <amount> festgelegte Geldmenge abgezogen oder
+     zugefuehrt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Technisch gesehen wird Geld mit entsprechendem <amount> erzeugt
+     ("/items/money.c") und mittels "move" in den Spieler bewegt.  Das Ergebnis
+     dieses "move"-Aufrufes wird hier uebergeben, z.B. 1 fuer OK.
+     Die moeglichen Fehler-Konstanten sind in /sys/moving.h definiert, siehe
+     auch Dokumentation zu "move".
+
+BEMERKUNGEN
+-----------
+::
+
+     <amount> kann sowohl positiv als auch negativ sein. Welche Auswirkungen
+     beide Faelle haben, sollte klar sein. Doch sollte bei einem negativen
+     <amount> vorher mittels QueryMoney() abgefragt werden, ob der Spieler
+     auch ueber ausreichend Geld verfuegt.
+     Wird dem Spieler Geld abgezogen, ist darauf zu achten, dieses in der
+     Zentralbank einzuzahlen (s.a.:PayIn() ). 
+     Verschafft man dem Spieler Geld aus dem Nichts, muss es vorher bei der
+     Zentralbank abgebucht (WithDraw()) werden.
+
+     Achtung: Kann der Spieler die in <amount> angebene Geldmenge nicht
+	      tragen, werden ihm keine Muenzen in sein Inventar bewegt.  Die
+	      Fehlermeldung erkennt man an dem Rueckgabewert ME_TOO_HEAVY.
+
+     Im Gegensatz zu Spielern haben alle anderen Objekte (Raeume, NPC, etc.)
+     standardmaessig keinen Moneyhandler. In diesem Fall muss in Lebewesen
+     "/std/living/moneyhandler"
+     und in nicht-Lebewesen
+     "/std/container/moneyhandler"
+     geerbt werden.
+
+BEISPIELE
+---------
+::
+
+     // gib ihm Geld
+     this_player()->AddMoney(50);
+
+     // nimm ihm Geld
+     if(this_player()->AddMoney(-50)==1)
+      write("Der Ork beklaut dich!\n");
+
+SIEHE AUCH
+----------
+::
+
+     Geldhandling:	QueryMoney(L)
+     Zentralbank:	PayIn(L), WithDraw(L)
+     Sonstiges:		move(L),
+			/items/money.c, /sys/moving.h, /sys/money.h, /sys/bank.h
+			/std/container/moneyhandler.c
+
+18.02.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/AddMsg.rst b/doc/sphinx/lfun/AddMsg.rst
new file mode 100644
index 0000000..7b2393f
--- /dev/null
+++ b/doc/sphinx/lfun/AddMsg.rst
@@ -0,0 +1,63 @@
+AddMsg()
+========
+
+FUNKTION
+--------
+::
+
+     void AddMsg(string msg, int next);
+
+DEFINIERT IN
+------------
+::
+
+     /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+     msg
+          Die auszugebende Meldung.
+     next
+          Zeit bis zur naechsten Fahrplanstation.
+
+BESCHREIBUNG
+------------
+::
+
+     Dem Fahrplan wird die Ausgabe einer Meldung an den Transporter
+     hinzugefuegt. Diese Meldung koennte zum Beispiel das Nahen der
+     naechsten Haltestelle ankuendigen o.ae. Nach Ausgabe der Meldung
+     vergehen next Sekunden, bis die naechste Station angefahren wird.
+
+     Um das Umbrechen der Meldung (normalerweise auf 78 Zeichen pro Zeile)
+     muss sich der Aufrufer selber kuemmern.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEISPIELE
+---------
+::
+
+     AddMsg("In der Ferne taucht eine kleine Inseln auf.\n", 10);
+     AddMsg("Das Schiff steuert einen kleinen Steg an.\n");
+     AddRoute(...);
+
+     Nach der Ankuendigung der Insel vergehen 10 Sekunden, bis die naechste
+     Meldung ausgegeben wird. Da bei der zweiten Meldung keine Zeit
+     angegeben war, legt das Schiff direkt nach der Ausgabe der Meldung an.
+
+SIEHE AUCH
+----------
+::
+
+     AddRoute(), AddFun(), /std/transport.c
+
+
+25.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddPlant.rst b/doc/sphinx/lfun/AddPlant.rst
new file mode 100644
index 0000000..6b4cb4c
--- /dev/null
+++ b/doc/sphinx/lfun/AddPlant.rst
@@ -0,0 +1,85 @@
+AddPlant()
+==========
+
+FUNKTION
+--------
+::
+
+        varargs int AddPlant(string filename, [string|string* npcId]) 
+
+DEFINIERT IN
+------------
+::
+
+        /std/room/kraeuter.c
+
+ARGUMENTE
+---------
+::
+
+        filename
+          Der Filename des Krauts das hier gefunden werden soll.
+        npcId
+          Die ID eines NPCs oder die IDs einer Liste von NPCs, der/die das 
+          Kraut bewachen soll/en. Befindet sich ein NPC mit einer dieser IDs
+          im Raum, kann das Kraut nicht gepflueckt werden. Dieses Argument 
+          ist optional!
+
+RUeCKGABEWERT
+-------------
+::
+
+        -1 wenn das Objekt nicht geclont werden konnte
+        >=0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+        Mit Hilfe dieser Funktion koennen Kraeuter fuer den mudweiten
+        Kraeuterskill recht einfach eingebaut werden. Alles was man
+        noch machen muss, ist den Namen der Pflanze in einem Detail oder
+        der Langbeschreibung zu erwaehnen.
+        Mit dem Befehl "showplant" in /obj/tools/planttool kann man sich 
+        bequem anzeigen lassen, was es alles an Kraeutern gibt, die man 
+        nehmen kann.
+
+BEMERKUNGEN
+-----------
+::
+
+        Damit die Kraeuter von den Spielern zum Brauen von Traenken benutzt
+        werden koennen, muss der Raum erst in einem Master eingetragen werden.
+        Derzeit schickt ihr dazu am besten eine kurze Mail an einen Erzmagier,
+        gerne nimmt Humni die derzeit entgegen.
+        Die Kraeuter wurden von der Balance bereits alle im vorhinein
+        abgenommen. Lediglich die Einhaltung der Kategorien ist zu beachten.
+        Sind Kraeuter nicht im Master konfiguriert (wie z.B. im Homemud), sind
+        alle erzeugten Kraeuter nur "Testkraeuter" mit nur der ID "kraut".
+
+BEISPIELE
+---------
+::
+
+        #include <items/kraeuter/kraeuterliste.h>
+        inherit "/std/room/kraeuter";
+        inherit "/std/room";
+
+        
+
+        void create()
+        {
+          ::create();
+          SetProp(P_INT_LONG, "Du siehst eine Wiese voller Feldklee.\n");
+          AddPlant(FELDKLEE);
+        }
+
+SIEHE AUCH
+----------
+::
+
+        AddItem();
+
+
+18.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddPluralId.rst b/doc/sphinx/lfun/AddPluralId.rst
new file mode 100644
index 0000000..36bfc9d
--- /dev/null
+++ b/doc/sphinx/lfun/AddPluralId.rst
@@ -0,0 +1,50 @@
+AddPluralId()
+=============
+
+FUNKTION
+--------
+::
+
+     void AddPluralId(mixed id);
+
+DEFINIERT IN
+------------
+::
+
+     /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+     id
+          Identfikationsstring oder Array von Strings
+
+BESCHREIBUNG
+------------
+::
+
+     Es werden ein oder mehrere Bezeichner hinzugefuegt, mit denen sich 
+     mehrere Einheiten der Menge ansprechen lassen.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEISPIELE
+---------
+::
+
+     siehe /items/money.c
+
+SIEHE AUCH
+----------
+::
+
+     AddSingularId(), RemovePluralId(), AddId(), id(), /std/unit.c
+
+
+Last modified: Mon Jul 14 11:30:00 1997 by Silvana
+
diff --git a/doc/sphinx/lfun/AddPursuer.rst b/doc/sphinx/lfun/AddPursuer.rst
new file mode 100644
index 0000000..e54f1a9
--- /dev/null
+++ b/doc/sphinx/lfun/AddPursuer.rst
@@ -0,0 +1,52 @@
+AddPursuer()
+============
+
+FUNKTION
+--------
+::
+
+  void AddPursuer(object pursuer)
+
+ARGUMENTE
+---------
+::
+
+  pursuer: Objekt, das demjenigen folgen soll, in dem AddPursuer
+           aufgerufen wurde.
+
+FUNKTION
+--------
+::
+
+  Durch den Aufruf von AddPursuer in einem Objekt, welches living() ist,
+  wird das Object, welches als Argument uebergeben wurde in die Liste
+  der Verfolger eingetragen. Alle Objekte, die in der Verfolgerliste stehen
+  werden bei Bewegungen des Verfolgten in dasselbe Environment bewegt.
+
+RUECKGABEWERT
+-------------
+::
+
+  keiner
+
+BEMERKUNG
+---------
+::
+
+  Im Verfolger wird PreventFollow mit dem Zielobjekt, in das der Verfolgte 
+  bewegt wird, aufgerufen. Dadurch kann der raeumliche Bereich, in dem 
+  verfolgt wird, eingeschraenkt werden.
+
+BEISPIELE
+---------
+::
+
+  find_player("jof")->AddPursuer(find_player("kirk"))
+  Danach wird Jof von Kirk verfolgt.
+
+SIEHE AUCH
+----------
+::
+
+  "RemovePursuer", "PreventFollow"
+
diff --git a/doc/sphinx/lfun/AddReadDetail.rst b/doc/sphinx/lfun/AddReadDetail.rst
new file mode 100644
index 0000000..af20c6e
--- /dev/null
+++ b/doc/sphinx/lfun/AddReadDetail.rst
@@ -0,0 +1,102 @@
+AddReadDetail()
+===============
+
+FUNKTION
+--------
+::
+
+    void AddReadDetail(string|string*keys,
+                       string|string*|mapping|closure desc);
+
+DEFINIERT IN
+------------
+::
+
+    /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+    keys
+      String oder Array von Strings mit den Namen der Details.
+    desc
+      String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+
+BESCHREIBUNG
+------------
+::
+
+    Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
+    beim Lesen ausgegeben werden, haengt im wesentlichen vom Typ der
+    Beschreibung <desc> ab:
+      <desc> ist ein String.
+       Beim Lesen wird dieser String zurueckgegeben.
+      <desc> ist ein String-Array.
+       Beim Lesen wird zufaellig einer der Strings zurueckgegeben.
+      <desc> ist ein Mapping.
+        Das Mapping muss folgenden Aufbau haben:
+          ([0:        "Defaulttext",
+            "rasse1": "r1text", ...]).
+
+        Falls fuer die Rasse des das Detail untersuchenden Spielers ein
+        Eintrag im Mapping existiert, wird der entsprechende Text
+        zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
+        rassenabhaengige Texte moeglich.
+      <desc> ist eine Closure.
+        In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
+        zurueckgegeben. Die Closure bekommt dabei den Namen des Details
+        als Parameter uebergeben.
+
+    Fuer lesbare Details koennen Forscherpunkte eingetragen werden.
+
+    Will man ein lesbares Detail an einem Objekt haben, welches der Spieler
+    mit "lies <id>" (<id> ist eine ID des Objekts) bekommt, muss man ein
+    Detail SENSE_DEFAULT hinzufuegen.
+    (Ein Detail "<id>" hinzuzufuegen, hat einen ganz anderes Effekt! Dieses
+     wuerde vom Spieler mit "lies <id> an <id>" gelesen werden und ist
+     meistens nicht das, was gewuenscht wird.)
+
+BEMERKUNGEN
+-----------
+::
+
+    (1) Auf die 'desc' wird kein process_string() mehr angewendet.
+        Bitte stattdessen lfun closures bzw. 'inline closures'
+        verwenden.
+
+    (2) Im Gegensatz zum Verhalten von AddTouchDetail(), AddSmells() und
+        AddSounds() wirkt ein SENSE_DEFAULT-Detail in einem Raum nicht.
+        Ein einfaches "lies" bleibt dann ohne Rueckgabewert.
+
+BEISPIELE
+---------
+::
+
+    AddReadDetail( ({ "schild" }),
+      "BETRETEN STRENGSTENS VERBOTEN!\n" );
+
+    AddReadDetail("inschrift",
+                  ([0: "Dort steht: Ein Ring sie zu binden. ....\n",
+                    "elf": "Alles in dir straeubt sich, DAS DA zu lesen.\n"]));
+
+    AddReadDetail("regeln",
+      function string() {
+        this_player()->More("/etc/WIZRULES", 1);
+        return "";
+      });
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddDetail(), AddSmells(), AddSounds(),
+               AddTouchDetail()
+    Loeschen:  RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+               RemoveSounds(), RemoveTouchDetail()
+    Daten:     P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+    Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddResistanceModifier.rst b/doc/sphinx/lfun/AddResistanceModifier.rst
new file mode 100644
index 0000000..dfc205b
--- /dev/null
+++ b/doc/sphinx/lfun/AddResistanceModifier.rst
@@ -0,0 +1,75 @@
+AddResistanceModifier()
+=======================
+
+FUNKTION
+--------
+::
+
+     varargs int AddResistanceModifier(mapping mod, string add)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+     mapping mod:
+      Mapping mit Schadensarten und ihrem Resistenzmodifikator (der im Bereich
+      von -1.0 bis +x liegen kann), z.B. ([DT_FIRE:-1.0]) (Totalresistenz).
+     string add:
+      Ein Identifikator fuer _diesen_ Eintrag des setzenden Objektes.
+
+BESCHREIBUNG
+------------
+::
+
+     Es werden Resistenzen in dem Objekt gesetzt, die solange bestehen, wie
+     das setzende Objekt existiert, oder nicht RemoveResistanceModifier
+     (mit eventuellem Schluessel add) aufgerufen wird. Zusaetzliche Resistenzen
+     werden eingerechnet.
+
+BEMERKUNGEN
+-----------
+::
+
+     Fuer Ruestungen kann und sollte man P_RESISTANCE_STRENGTHS verwenden.
+
+BEISPIELE
+---------
+::
+
+     // Oel mit vervierfachtem Feuerschaden
+     int add_action() {
+      ...
+      write(break_string("Du schuettest das Oel ueber "+
+			 npc->name(WEN)+".",78));
+      ...
+      npc->AddResistanceModifier(([DT_FIRE:3.0]), "oel");
+      SetProp(P_INVIS,1);
+      SetProp(P_EXTRA_LOOK, "Ueberall tropft Oel herunter.\n");
+      move(npc,M_NOCHECK);
+      ...
+     }
+
+RUeCKGABEWERT
+-------------
+::
+
+     1 fuer Erfolg
+
+SIEHE AUCH
+----------
+::
+
+     Modifikatoren:	RemoveResistanceModifier(), P_RESISTANCE_MODIFIER
+     simple Resistenz:	P_RESISTANCE, P_VULNERABILITY
+     Hauptmapping:	P_RESISTANCE_STRENGTHS
+     Berechnung:	CheckResistance(), UpdateResistanceStrengths()
+     anderes:		balance, /std/armour/combat.c, /std/living/combat.c
+
+29.Apr 2002, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/AddRoomCmd.rst b/doc/sphinx/lfun/AddRoomCmd.rst
new file mode 100644
index 0000000..c7b5de3
--- /dev/null
+++ b/doc/sphinx/lfun/AddRoomCmd.rst
@@ -0,0 +1,25 @@
+AddRoomCmd()
+============
+
+SYNTAX
+------
+::
+
+	AddRoomCmd( string kommando, string funktion );
+	AddRoomCmd( string *kommandos, string funktion );
+
+FUNKTION
+--------
+::
+
+	
+
+	Diese Funktion ist veraltet. Sie wird vollstaendig durch
+	die Funktion AddCmd ersetzt.
+
+SIEHE AUCH
+----------
+::
+
+	"AddCmd"
+
diff --git a/doc/sphinx/lfun/AddRoomMessage.rst b/doc/sphinx/lfun/AddRoomMessage.rst
new file mode 100644
index 0000000..150a9cd
--- /dev/null
+++ b/doc/sphinx/lfun/AddRoomMessage.rst
@@ -0,0 +1,103 @@
+AddRoomMessage()
+================
+
+FUNKTION
+--------
+::
+
+     void AddRoomMessage(string *msg, int time, mixed *func);
+
+DEFINIERT IN
+------------
+::
+
+     /std/room/description.c
+
+ARGUMENTE
+---------
+::
+
+     msg
+          Array von Strings mit den Meldungen.
+     time
+          Der Abstand zwischen zwei Meldungen in Sekunden.
+     func (optional)
+          String oder Array von Strings mit Funktionsnamen
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Funktion legt man fest, dass in bestimmten Zeitabstaenden
+     Meldungen an den Raum geschickt werden sollen.
+
+     Es wird alle time Sekunden zufaellig eine der in msg angegebenen
+     Meldungen ausgegeben. Hat man auch noch func angegeben, so wird
+     zusaetzlich diese Funktion (bei einem Array: eine zufaellig ausgesuchte
+     Funktion) im Raum aufgerufen. Als Parameter bekommt die Funktion die
+     Nummer der ausgegebenen Meldung.
+
+     Bevor man allerdings jeden Raum mit AddRoomMessage() pflastert, sollte
+     man folgendes bedenken:
+        o Viele Meldungen in vielen Raeumen tendieren dazu, den Spielern auf
+          die Nerven zu gehen!
+        o Da das Timing ueber einen call_out() gesteuert wird, ist das Ganze
+          aus Sicht des GameDrivers auch noch relativ teuer!
+     Fazit: weniger ist mehr!
+
+BEMERKUNGEN
+-----------
+::
+
+     * Falls time < 15 Sekunden ist, wird auf 15 Sekunden aufgerundet.
+     * der Praefix Add... taeuscht hier. Ein Aufruf von AddRoomMessage()
+       ueberschreibt alle vorherigen Werte
+     * THIS_PLAYER() NICHT VERWENDEN!
+     In Funktionen, die durch AddRoomMessage() ausgeloest werden, darf
+     this_player() nicht verwendet werden. AddRoomMessage ist call_out-
+     gesteuert und speichert somit das this_player(). Damit ist this_player()
+     immer der Spieler, der den Raum geladen, also den Raum als erster
+     betreten hat. 
+     Spieler also bitte selbst ueber filter(all_inventory(this_object()),
+                                            #'interactive) suchen.
+
+BEISPIELE
+---------
+::
+
+     Es soll alle halbe Minute eine Meldung ausgegeben werden. Falls es
+     unter den Fuessen knackt, soll man zudem mit 30%-iger
+     Wahrscheinlichkeit zusammenzucken:
+
+     inherit "/std/room";
+
+     void create() {
+       ::create();
+       AddRoomMessage( ({ "In der Ferne schreit ein Kaeuzchen.\n",
+                          "Es raschelt im Gebuesch.\n",
+                          "Etwas knackt unter Deinen Fuessen.\n" }),
+                        30, ({"sound", "sound_more_rnd"}) );
+       ...
+     }
+
+     void sound(int msg) {
+       if (msg == 2)         // Es hat geknackt...
+         if (random(10) < 3) // Schreck lass nach! ;-)
+           tell_room(this_object(), "Erschrocken faehrst Du zusammen!\n" );
+     }
+
+     // Extra-Beispiel: wir setzen die Wartedauer (Parameter tim) neu
+     void sound_more_rnd() {
+       sound(0);   // die Message-Nummer ist hier unwichtig
+       SetProp(P_MSG_PROB, 25+random(20));  // neue Wartedauer
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt: tell_room(), ReceiveMsg()
+     Props:    P_ROOM_MSG, P_FUNC_MSG, P_MSG_PROB
+
+2.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/lfun/AddRoute.rst b/doc/sphinx/lfun/AddRoute.rst
new file mode 100644
index 0000000..69b7c3a
--- /dev/null
+++ b/doc/sphinx/lfun/AddRoute.rst
@@ -0,0 +1,116 @@
+AddRoute()
+==========
+
+FUNKTION
+--------
+::
+
+    public varargs void AddRoute(string room, int stay, int next, 
+        string harbour_desc, mixed dest_ids, string deststr)
+
+DEFINIERT IN
+------------
+::
+
+    /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+    string room
+        Filename der Haltestelle (des Ziels)
+    int stay
+        Aufenthaltszeit an der Haltestelle.
+    int next
+        Fahrtzeit von dort bis zum naechsten Fahrplanpunkt
+    string harbour_desc
+        Name der Haltestelle (fuer QueryArrived)
+    mixed dest_ids
+        kleingeschriebene IDs der Haltestelle
+    string destrstr
+        Unbenutzt / Undefiniert.
+
+BESCHREIBUNG
+------------
+::
+
+    Dem Fahrplan des Transporters wird eine neue Haltestelle hinzugefuegt.
+
+    Bei Erreichen der Haltestelle wird der Transporter in den Raum 'room'
+    bewegt und sichtbar gemacht. Nun kann man ihn fuer 'stay' Sekunden
+    betreten oder verlassen, bevor er ablegt (unsichtbar gemacht wird).
+    Nach 'next' Sekunden wird dann der naechste Punkt des Fahrplans
+    ausgefuehrt.
+
+     
+
+    'harbour_desc' ist ein String, den QueryArrived() zurueckgibt, wenn sich
+    der Transporter an einer Haltestelle befindet. In der Regel ist das ein
+    String, der die Haltestelle naeher beschreibt.
+
+    
+
+    'dest_ids' ist ein Array von Strings, die als ID-Code fuer diese 
+    Haltstelle dienen. Das wird zB bei der Ermittlung einer Haltestelle bei 
+    "reise nach" benutzt. Wenn 'dest_ids' nicht gesetzt ist, und auch 
+    P_HARBOUR des Zielhafens nicht korrekt gesetzt ist, werden 
+    grossgeschriebene Begriffe aus 'harbour_desc' verwendet.
+
+BEISPIELE
+---------
+::
+
+    #1 Hier ein Auszug aus /d/inseln/schiffe/jolle.c:
+
+      AddRoute("/d/ebene/room/PortVain/po_haf2", 40,
+               10, "Hafen von Port Vain");
+
+    Die Jolle wird also beim Anlegen in den Port Vainer Hafen bewegt und
+    laesst sich dort 40 Sekunden lang betreten oder verlassen.
+    QueryArrived() liefert waehrend dieser Zeit den String "Hafen von Port
+    Vain" zurueck. Nach den 40 Sekunden legt die Jolle ab, und nach
+    weiteren 10 Sekunden wird die naechste Station in ihrem Fahrplan
+    angefahren.
+
+    #2 Die Galeere nach Orkhausen:
+      AddRoute(INSEL("steg"), 30, 20, "Verlorene Land ( Orkhausen )" );
+      - haelt 30 Sekunden
+      - reist 20 Sekunden
+      - reist nach INSEL("steg"), bekannt als "Verlorene Land ( Orkhausen )"
+      - da keine 'dest_ids' angegeben sind, waere eine so definierte 
+        Haltstelle nur mit den IDs ansprechbar, die in P_HARBOURS im Zielraum
+        angegeben sind.
+
+    Wenn man nun erreichen wollte, dass das Ziel auch mit dem Kuerzel "vland"
+    ansprechbar ist, kann man zum einen explizite 'dest_ids' eintragen:
+      AddRoute(INSEL("steg"), 30, 20, "Verlorene Land ( Orkhausen )",
+               ({"verlorenes", "land", "orkhausen", "vland"}));
+    Dies laesst sich im Zielhafen aber auch durch Eintragen des Kuerzels
+    "vland" in P_HARBOUR erreichen. Dies hat den Vorteil, dass dieser Hafen
+    dann von allen Transportern, die dort anlegen, unter demselben Namen
+    erreicht werden kann.
+
+    
+
+HINWEISE
+--------
+::
+
+    Dadurch, dass die Eintraege aus P_HARBOUR und 'dest_ids' gleichberechtigt
+    fuer "reise nach <ziel>" verwendet werden koennen, ist es moeglich,
+    dass die Reiseziele auf einem Schiff unter zusaetzlichen Bezeichnungen 
+    bekannt sind, als an Land (zum Beispiel koennte eine fernwestliche
+    Besatzung die Ziele anders nennen).
+
+SIEHE AUCH
+----------
+::
+
+Funktionen  AddMsg(L), AddFun(L), /std/transport.c
+Properties  P_HARBOUR, P_NO_TRAVELING, P_TRAVEL_INFO
+
+2015-Jan-18, Arathorn.
+-------------------------------------------------------------------------------------------------------------------------------
+::
+
diff --git a/doc/sphinx/lfun/AddSingularId.rst b/doc/sphinx/lfun/AddSingularId.rst
new file mode 100644
index 0000000..274c8c3
--- /dev/null
+++ b/doc/sphinx/lfun/AddSingularId.rst
@@ -0,0 +1,50 @@
+AddSingularId()
+===============
+
+FUNKTION
+--------
+::
+
+     void AddSingularId(mixed id);
+
+DEFINIERT IN
+------------
+::
+
+     /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+     id
+          Identifikationsstring oder Array von Strings
+
+BESCHREIBUNG
+------------
+::
+
+     Es werden ein oder mehrere Bezeichner hinzugefuegt, mit denen sich eine
+     einzelne Einheit ansprechen laesst.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEISPIELE
+---------
+::
+
+     siehe /items/money.c
+
+SIEHE AUCH
+----------
+::
+
+     AddPluralId(), RemoveSingularId(), AddId(), id(), /std/unit.c
+
+
+Last modified: Mon Jul 14 11:31:00 1997 by Silvana
+
diff --git a/doc/sphinx/lfun/AddSmells.rst b/doc/sphinx/lfun/AddSmells.rst
new file mode 100644
index 0000000..091d7d9
--- /dev/null
+++ b/doc/sphinx/lfun/AddSmells.rst
@@ -0,0 +1,92 @@
+AddSmells()
+===========
+
+FUNKTION
+--------
+::
+
+    void AddSmells(string|string* keys, string|string*|mapping|closure desc);
+
+DEFINIERT IN
+------------
+::
+
+    /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+    keys
+      String oder Array von Strings mit den Namen der Details.
+    desc
+      String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion entspricht dem AddDetail() fuer Standarddetails, nur
+    koennen hiermit Gerueche realisiert werden:
+    Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
+    bei der Untersuchung aussehen, haengt im wesentlichen vom Typ der
+    Beschreibung <desc> ab:
+      <desc> ist ein String.
+        Beim Untersuchen wird dieser String zurueckgegeben.
+      <desc> ist ein String-Array.
+        Beim Untersuchen wird zufaellig einer der Strings zurueckgegeben.
+      <desc> ist ein Mapping.
+        Das Mapping muss folgenden Aufbau haben:
+          ([0:        "Defaulttext",
+            "rasse1": "r1text", ...]).
+
+        Falls fuer die Rasse des das Detail untersuchenden Spielers ein
+        Eintrag im Mapping existiert, wird der entsprechende Text
+        zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
+        rassenabhaengige Details moeglich. Siehe auch die Beispiele.
+      <desc> ist eine Closure.
+        In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
+        zurueckgegeben. Die Closure bekommt dabei den Namen des Details
+        als Parameter uebergeben.
+
+    Fuer Geruchsdetails koennen Forscherpunkte eingetragen werden.
+
+    Gerueche koennen allgemein einen Raum oder Objekt zugeordnet werden:
+    dafuer muss man als <key> SENSE_DEFAULT uebergeben.
+
+    
+
+    Spielerkommandos: "riech", "rieche", "schnupper", "schnuppere"
+
+BEISPIELE
+---------
+::
+
+    Ein kleines Beispiel fuer rassenabhaengige Gerueche mit Closures:
+      string strafe(string key);
+      ...
+      AddSmells(SENSE_DEFAULT,
+        "Der Geruch von Knoblauch ist ueberwaeltigend!\n");
+      AddSmells(({"knoblauch","geruch"}),
+                ([0:        "Puhh, das stinkt!\n",
+                  "vampir": #'strafe]));
+      ...
+      string strafe(string key) {
+        this_player()->reduce_hit_points(100);
+        return "Der Knoblauch schmerzt dich furchtbar!\n";
+      }
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddDetail(), AddReadDetail(), AddSounds(),
+               AddTouchDetail()
+    Loeschen:  RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+               RemoveSounds(), RemoveTouchDetail()
+    Daten:     P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+    Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddSounds.rst b/doc/sphinx/lfun/AddSounds.rst
new file mode 100644
index 0000000..df83b42
--- /dev/null
+++ b/doc/sphinx/lfun/AddSounds.rst
@@ -0,0 +1,82 @@
+AddSounds()
+===========
+
+FUNKTION
+--------
+::
+
+    void AddSounds(string|string* keys, string|string*|mapping|closure desc);
+
+DEFINIERT IN
+------------
+::
+
+    /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+    keys
+      String oder Array von Strings mit den Namen der Details.
+    desc
+      String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion entspricht dem AddDetail() fuer Standarddetails, nur
+    koennen hiermit Geraeusche realisiert werden:
+    Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
+    bei der Untersuchung aussehen, haengt im wesentlichen vom Typ der
+    Beschreibung <desc> ab:
+      <desc> ist ein String.
+        Beim Untersuchen wird dieser String zurueckgegeben.
+      <desc> ist ein String-Array.
+        Beim Untersuchen wird zufaellig einer der Strings zurueckgegeben.
+      <desc> ist ein Mapping.
+        Das Mapping muss folgenden Aufbau haben:
+          ([0:        "Defaulttext",
+           "rasse1": "r1text", ...]).
+
+        Falls fuer die Rasse des das Detail untersuchenden Spielers ein
+        Eintrag im Mapping existiert, wird der entsprechende Text
+        zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
+        rassenabhaengige Details moeglich. Siehe auch die Beispiele.
+      <desc> ist eine Closure.
+        In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
+        zurueckgegeben. Die Closure bekommt dabei den Namen des Details
+        als Parameter uebergeben.
+
+    Fuer Geraeuschdetails koennen Forscherpunkte eingetragen werden.
+
+    Gerauesche koennen allgemein einen Raum oder Objekt zugeordnet werden:
+    dafuer muss man als <key> SENSE_DEFAULT uebergeben.
+
+    Spielerkommandos: "lausche", "lausch", "hoer", "hoere"
+
+BEISPIELE
+---------
+::
+
+    Ein kleines Beispiel fuer rassenabhaengige Gerauesche
+      AddSounds(SENSE_DEFAULT, "Die Zwergenmusik uebertoent alles!\n");
+      AddSounds(({"zwergenmusik","musik"}),
+                ([0      : "Seltsamer Krach!\n",
+                  "zwerg": "Das klingt einfach fantastisch!\n"]));
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddDetail(), AddReadDetail(), AddSmells(),
+               AddTouchDetail()
+    Loeschen:  RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+               RemoveSounds(), RemoveTouchDetail()
+    Daten:     P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+    Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddSpecialDetail.rst b/doc/sphinx/lfun/AddSpecialDetail.rst
new file mode 100644
index 0000000..24f8f64
--- /dev/null
+++ b/doc/sphinx/lfun/AddSpecialDetail.rst
@@ -0,0 +1,87 @@
+AddSpecialDetail()
+==================
+
+VERALTET AddSpecialDetail()
+---------------------------
+::
+
+FUNKTION
+--------
+::
+
+    void AddSpecialDetail(string|string* keys, string func);
+
+DEFINIERT IN
+------------
+::
+
+    /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+    keys
+      String oder Array von Strings mit den Namen der Details.
+    func
+      String mit dem Namen der Funktion, die zur Auswertung aufgerufen
+      wird.
+
+BESCHREIBUNG
+------------
+::
+
+    Es wird ein Detail hinzugefuegt, dessen Inhalt nicht von vornherein
+    feststeht, sondern von aeusseren Bedingungen abhaengt. Zu diesem
+    Zweck wird immer, wenn dieses Detail untersucht wird, die Funktion
+    func aufgerufen, um den aktuellen Zustand des Details zu bestimmen.
+    Der Funktion wird als Parameter das Schluesselwort uebergeben, mit
+    dem das Detail untersucht wurde.
+
+    VERALTET: Bitte AddDetail mit Closure benutzen.
+
+BEISPIELE
+---------
+::
+
+    Ein zustandsabhaengiges Detail:
+
+      int hebel_betaetigt;
+      string hebel(string key);
+      ...
+      // ALT: AddSpecialDetail( ({ "hebel", "schalter" }), "hebel" );
+      AddDetail(({ "hebel", "schalter" }), #'hebel );
+      ...
+      string hebel(string key)
+      { if(hebel_betaetigt)
+          return "Der "+capitalize(key)+" steht auf EIN.\n";
+        else
+          return "Der "+capitalize(key)+" steht auf AUS.\n";
+      }
+
+    Man erhaelt verschiedene Ergebnisse beim Untersuchen, je nachdem
+    ob das Flag hebel_betaetigt gesetzt ist oder nicht.
+
+BEMERKUNG
+---------
+::
+
+    Intern werden Details und SpecialDetails im selben Mapping
+    verwaltet.
+    Man kann statt dieser Funktion deshalb auch AddDetail mit Closures
+    nutzen.
+
+SIEHE AUCH
+----------
+::
+
+    Setzen :   AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+               AddTouchDetail()
+    Loeschen:  RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+               RemoveSounds(), RemoveTouchDetail()
+    Daten:     P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+    Veraltet:  RemoveSpecialDetail(), P_READ_MSG
+    Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddSpecialExit.rst b/doc/sphinx/lfun/AddSpecialExit.rst
new file mode 100644
index 0000000..4a367f9
--- /dev/null
+++ b/doc/sphinx/lfun/AddSpecialExit.rst
@@ -0,0 +1,82 @@
+AddSpecialExit()
+================
+
+FUNKTION
+--------
+::
+
+     void AddSpecialExit(string|string* cmd, string|closure func);
+
+DEFINIERT IN
+------------
+::
+
+     /std/room/exits
+
+ARGUMENTE
+---------
+::
+
+     string/string* cmd
+          die Richtung(en), in die der Ausgang fuehrt
+     string/closure func
+          der Name der aufzurufenden Funktion/Closure
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird ein Ausgang in die Richtung(en) cmd eingefuegt. Wird der
+     Ausgang benutzt, so wird die Closure bzw. Funktion func ausgefuehrt.
+
+     AddSpecialExit(cmd, "func") entspricht:
+     - AddExit(keys, #'func)
+
+BEMERKUNGEN
+-----------
+::
+
+     In func muss man den Spieler selbst in den Zielraum bewegen. Im
+     Erfolgsfall sollte man einen Wert >0 zurueckgeben, im Fehlerfall einen
+     Wert <=0.
+
+     func bekommt als Parameter einen String mit der gewaehlten
+     Bewegungsrichtung uebergeben.
+
+BEISPIELE
+---------
+::
+
+     // ein Ausgang soll nur von Froeschen benutzbar sein:
+
+     AddSpecialExit("loch", "lochfkt");
+     // der gleiche Aufruf, nur anders:
+     // static int lochfkt(string dir);		// Prototyp
+     // ...
+     // AddSpecialExit("loch", #'lochfkt);
+     // auch identisch zu:
+     // AddExit("loch", #'lochfkt);
+
+     static int lochfkt(string dir) {
+       if (!(this_player()->QueryProp(P_FROG))) {
+         // Kein Frosch => passt nicht!
+         notify_fail("Du bist zu gross!\n");
+         return 0;
+       }
+       // Meldungen werden im move() gleich mitgegeben
+       return this_player()->move("/room/loch", M_GO, 0,
+                    "huepft ins Loch", "huepft herein");
+     }
+
+SIEHE AUCH
+----------
+::
+
+     AddExit(), GetExits(),
+     RemoveExit(), RemoveSpecialExit(),
+     GuardExit(),
+     H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
+     ausgaenge
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/AddSpecialInfo.rst b/doc/sphinx/lfun/AddSpecialInfo.rst
new file mode 100644
index 0000000..558b2d2
--- /dev/null
+++ b/doc/sphinx/lfun/AddSpecialInfo.rst
@@ -0,0 +1,88 @@
+AddSpecialInfo()
+================
+
+FUNKTION
+--------
+::
+
+     varargs void AddSpecialInfo( frage, meldung
+			   [, indent [, [silent [, casebased] ] ] );
+
+ARGUMENTE
+---------
+::
+
+     string/string* frage
+	Schluesseltext(e) auf die Informationen gegeben werden sollen.
+     string/closure function
+	Methodenname im NPC/Closure
+     string indent
+	Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
+     int/string silent
+	Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
+     string/closure casebased
+	Funktionsname oder Closure mit Returnwert string oder int.
+
+DEFINIERT IN
+------------
+::
+
+     /std/npc/info.c
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn ein Spieler ein NPC mittels "frage <monstername> nach <frage>" nach
+     einer Information mit dem Schluessel frage fragt, so wird die Methode
+     "function" gerufen. Die Rueckgabe wird als Meldung ausgegeben.
+
+     Fuer die Beschreibung der weiteren Parameter siehe man AddInfo(L).
+
+     AddSpecialInfo(keys, "function", ...) entspricht:
+     - AddInfo(keys, #'function, ...) 
+
+BEMERKUNGEN
+-----------
+::
+
+     Da AddSpecialInfo() und AddInfo() auf die gleichen Daten zugreifen,
+     kann man Informationen, die mit AddSpecialInfo() gesetzt wurden, auch
+     mit RemoveInfo() entfernen. Es gibt kein RemoveSpecialInfo().
+
+BEISPIELE
+---------
+::
+
+     // Das folgende Beispiel ist auch unter man AddInfo(L) zu finden.
+     ### dynamisch ###
+     AddSpecialInfo(({"keks","kekse"}),
+		    "query_kekse",	// der Methodenname
+		    "sagt: ");
+     // ist uebrigens das gleiche wie:
+     // static string query_kekse();
+     // ...
+     // AddInfo(({"keks","kekse"}),
+     //		#'query_kekse,		// ein Verweis auf die Methode
+     //		"sagt: ");
+     ...
+     static string query_kekse() {
+      if(present("keks"))
+       return("Ich hab noch welche. Aetsch!");
+      return("Menno. Keine mehr da!");
+     }
+
+     // "frage monster nach keks":
+     // - wenn es noch Kekse hat, hoeren alle:
+     //   "Das Monster sagt: Ich hab noch welche. Aetsch!
+     // - sonst:
+     //   "Das Monster sagt: "Menno. Keine mehr da!
+
+SIEHE AUCH
+----------
+::
+
+     AddInfo(L), RemoveInfo(L)
+
+7.Apr 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/AddSpell.rst b/doc/sphinx/lfun/AddSpell.rst
new file mode 100644
index 0000000..602292f
--- /dev/null
+++ b/doc/sphinx/lfun/AddSpell.rst
@@ -0,0 +1,173 @@
+AddSpell()
+==========
+
+FUNKTION
+--------
+::
+
+    varargs int AddSpell(int rate, int damage, string TextForEnemy,
+                         string TextForOthers, string|string* dam_type,
+                         string|closure func, int|mapping spellarg)
+
+DEFINIERT IN
+------------
+::
+
+    /std/npc/combat.c
+
+ARGUMENTE
+---------
+::
+
+    rate          - Relative Haeufigkeit der Anwendung (*),
+                    muss >= 0 sein
+    damage        - Der Schadenswert fuer Defend(),
+                    muss > 0 sein
+    TextForEnemy  - Text, den der Feind erhalten soll
+    TextForOthers - Text, den andere im Raum erhalten sollen
+    dam_type      - Schadenstyp(en) fuer Defend(),
+                    (Default: ({DT_MAGIC}) )
+    func          - Funktionsname oder Closure, die nach Anwendung
+                    aufgerufen werden soll
+                    (Optional, bekommt als Argumente object enemy, 
+                    int real_damage, string* dam_type)
+    spellarg      - Spell-Argument fuer Defend(), Default ist "1"
+
+BESCHREIBUNG
+------------
+::
+
+    Ermoeglicht einfache Angriffs-Zaubersprueche fuer NPCs. Das Ausfuehren von
+    Spells verursacht bei dem NPC keine KP-Kosten.
+
+    Mit P_SPELLRATE wird die generelle Wahrscheinlichkeit der Ausfuehrung
+    solcher Spells im Heartbeat angegeben, mit 'rate' kann man die relative
+    Wahrscheinlichkeit der Spells untereinander steuern.
+
+    (*) Relative Haeufigkeit heisst, dass sich alle 'rate' der Spells
+    aufaddieren und ein einzelnes 'rate' dann in Relation zur Gesamtsumme
+    steht. D.h. drei Spells mit 80, 10, 10 (Summe 100) haben die selben
+    Aufruf-Wahrscheinlichkeiten wie drei Spells mit 120, 15, 15 oder drei
+    Spells mit 160, 20, 20.
+
+    Ein Spell wird immer in folgender Reihenfolge abgearbeitet:
+     1. Die Texte werden an die Beteiligten ausgegeben.
+     2. Es wird ggf. SpellDefend gerufen (wenn kein SP_PHYSICAL_ATTACK).
+        Abbruch bei Schutz.
+     3. Im Opfer wird Defend() mit den angegebenen Werten aufgerufen.
+        Abbruch bei Tod/Zerstoerung des Opfers.
+     4. Eine Funktion, so definiert, wird ausgefuehrt.
+
+BEMERKUNGEN
+-----------
+::
+
+    TextForOthers wird vor der Ausgabe der Meldung durch replace_personal()
+    geschickt, d.h. es koennen Platzhalter wie @WER1, @WEMQP1 und aehnliche
+    verwendet werden (siehe auch die Manpage von replace_personal()).
+    Da Ersetzungen nur fuer das Gegnerobjekt beruecksichtigt werden, koennen
+    nur Platzhalter mit Endziffer 1 verwendet werden. Die Ersetzungen werden
+    so gesteuert, dass die eingefuegten Namen nach Satzanfaengen automatisch
+    gross geschrieben werden.
+    Frueher wurden statt replace_personal() die Platzhalter @WER, @WESSEN, 
+    @WEM, @WEN verwendet. Diese funktionieren weiterhin, sollten aber nicht 
+    mehr in neuem Code benutzt werden.
+
+    In der von AddSpell gerufenen Methode "func" koennen speziellere
+    Sachen mit dem aktuellen Feind angestellt werden koennen. Die Methode
+    muss im selben Objekt definiert sein, sofern der Funktionsname und
+    keine Closure uebergeben wird.
+
+    Will man einen physischen Angriff ausloesen, MUSS <spellarg> ein Mapping
+    mit ([SP_PHYSICAL_ATTACK: 1]) sein. Bei Uebergeben einer 0 oder Weglassen
+    des Werts wird an Defend das Default '1' (da es Spells sind) uebergeben.
+
+    Wenn damage<=0 oder rate<0 oder keine Meldungen uebergeben werden, wird
+    der Spell NICHT eingetragen, sondern die Funktion bricht mit Rueckgabe
+    von 0 ab.
+
+BEISPIELE
+---------
+::
+
+    // #1 Einfacher NPC mit drei Spells, Gesamtrate = 100, also sind die
+    //    Raten direkt als Prozent Aufrufwahrscheinlichkeit lesbar.
+    AddSpell(80, 400,
+             "Der Hexer greift Dich mit einem kleinen Feuerball an.\n",
+             "Der Hexer greift @WEN mit einem kleinen Feuerball an.\n",
+             ({DT_FIRE, DT_MAGIC}));
+    AddSpell(10, 800,
+             "Der Hexer greift Dich mit einem riesigen Feuerball an.\n",
+             "Der Hexer greift @WEN mit einem riesigen Feuerball an.\n",
+             ({DT_FIRE, DT_MAGIC}));
+    AddSpell(8, 100,
+             "Der Hexer piekst Dir in die Augen!",
+             "Der Hexer piekst @WEM in die Augen!", ({DT_PIERCE}),
+             "augen_stechen");
+    AddSpell(2, 5, (string)0, (string)0, (string*)0, "salto_mortalis");
+
+    (Kleiner Feuerball mit 80% Wahrscheinlichkeit, riesiger mit 10%,
+     "augen_stechen" mit 8%, "salto_mortalis" mit 2%)
+
+    // Die Funktion "augen_stechen" kann dann so aussehen:
+    void augen_stechen(object enemy, int damage, mixed dam_types ) {
+      if (damage>10 && !enemy->QueryProp(P_BLIND)) {
+        enemy->SetProp(P_BLIND, 1);
+        if(enemy->QueryProp(P_BLIND))
+          tell_object(enemy, "Du bist nun blind!\n");
+      }
+    }
+
+    // Zur Funktion "salto_mortalis" gibt es keine Meldungen, dennoch
+    // wird Defend mit: enemy->Defend(5, ({DT_MAGIC}), 1, this_object())
+    // gerufen!
+    void salto_mortalis(object enemy, int damage, mixed dam_types ) {
+      // dem geneigten Leser ueberlassen, den Gegner zu toeten
+    }
+
+    // #2 Physische Angriffe: die Ruestungen sollen beruecksichtigt werden!
+    //    SP_PHYSICAL_ATTACK muss in einem Mapping auf 1 gesetzt werden,
+    //    damit Ruestungen physisch wirken (ansonsten werden nur ihre
+    //    DefendFuncs() ausgewertet). Es muss auch eine physische Schadensart
+    //    enthalten sein!
+    //    SpellDefend() wird bei diesem Flag nicht mehr am Gegner gerufen.
+    AddSpell(100, 200+random(200),
+      "Die kleine Ratte beisst Dich!\n",
+      "@WER wird von einer kleinen Ratte gebissen!\n",
+      ({DT_PIERCE, DT_POISON}), (string)0,
+      ([SP_PHYSICAL_ATTACK:1]));
+
+    // #3 Selektive physische Angriffe (siehe auch man Defend_bsp):
+    //    Will man erreichen, dass einige Ruestungen wirken, andere aber
+    //    nicht oder nur teilweise, kann man das ueber die Spellparameter
+    //    ausfuehrlich steuern:
+
+    // erstmal fuer alle Ruestungsarten einen Schutz von 0% einstellen:
+    mapping armours = map_indices(VALID_ARMOUR_CLASS, #'!);
+    armours[AT_TROUSERS] = 120;  // 120% Schutz durch Hosen
+    armours[AT_BOOT] = 30;       //  30% Schutz durch Stiefel
+
+    AddSpell(20,200+random(200),
+      "Die kleine Ratte beisst Dir blitzschnell in die Wade!\n",
+      "@WER wird von einer kleinen Ratte in die Wade gebissen!\n",
+      ({DT_PIERCE, DT_POISON}), (string)0,
+      ([SP_PHYSICAL_ATTACK:1, SP_NO_ACTIVE_DEFENSE:1,
+        SP_REDUCE_ARMOUR: armours]));
+
+    // SP_NO_ACTIVE_DEFENSE = 1 schaltet aktive Abwehr (Karate/Klerus) ab
+    // SP_REDUCE_ARMOUR enthaelt eine Liste von Ruestungstypen mit ihren
+    // neuen Wirkungsgraden in Prozent. Nicht enthaltene Ruestungen haben
+    // weiterhin 100% Schutzwirkung.
+
+SIEHE AUCH
+----------
+::
+
+     Sonstiges:  SpellAttack, SpellDefend, Defend, QueryDefend, SelectEnemy
+                 replace_personal
+     Properties: P_DISABLE_ATTACK, P_SPELLRATE, P_AGGRESSIVE
+     Abwehr:     Defend, Defend_bsp, SpellDefend
+     Methoden:   modifiers
+
+Zuletzt geaendert: 20.11.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/AddToMenu.rst b/doc/sphinx/lfun/AddToMenu.rst
new file mode 100644
index 0000000..29824f6
--- /dev/null
+++ b/doc/sphinx/lfun/AddToMenu.rst
@@ -0,0 +1,281 @@
+AddToMenu()
+===========
+
+FUNKTION
+--------
+::
+
+        varargs string AddToMenu(string  menuetext,
+                                 mixed   ids,
+                                 mapping minfo,
+                                 mixed   rate,
+                                 mixed   msg,
+                                 mixed   refresh,
+                                 mixed   delay,
+                                 mixed   d_msg);
+
+DEFINIERT IN
+------------
+::
+
+        /std/pub.c
+
+ARGUMENTE
+---------
+::
+
+        Die Erlaeuterung der Parameter beschraenkt sich im Folgenden
+        zunaechst auf die Grundfunktionalitaet bei Verwendung fester
+        Werte. Die Moeglichkeiten zur Realisierung dynamischen Verhaltens
+        sind in den Fussnoten zu den einzelnen Parametern beschrieben.
+
+        menuetext
+          Der Text steht als kurze Beschreibung im Menue.
+        ids
+          String oder Array von Strings, mit denen sich die Speise bzw. das
+          Getraenk beim Bestellen ansprechen laesst.
+        minfo
+          Mapping mit Eintraegen fuer:
+          P_HP      LP-Heilung in Punkten [*]
+          P_SP      KP-Heilung in Punkten [*]
+          P_FOOD    Saettigungswirkung der Speise [*]
+          P_DRINK   Saettigungswirkung des Getraenks [*]
+          P_ALCOHOL Alkoholgehalt des Getraenks [*]
+          P_VALUE   Preis der Speise bzw. des Getraenks [*]
+        rate [*]
+          Heilrate in Punkten pro HeartBeat.
+        msg [**]
+          Meldung beim Essen:
+          Array mit 2 Strings: (1) fuer Empfaenger, (2) fuer Andere.
+          Verfuegbare Platzhalter sind weiter unten im Abschnitt "Beispiel"
+          dokumentiert.
+        refresh
+          Mapping mit Eintraegen fuer:
+            PR_USER (Kontingent fuer einzelnen Spieler) [*]
+            PR_ALL  (Zusatzkontingent fuer alle) [*]
+          Alternativ: 0 fuer unbegrenzte Verfuegbarkeit
+          Einem Key muessen dabei zwei Werte zugeordnet werden:
+          Der Erste gibt die Hoehe des Kontingents an, der Zweite legt
+          fest, alle wieviel reset()s das Kontingent wieder aufgefuellt
+          wird.
+          Verwendung des Mappings erfordert Inkludieren von pub.h.
+        delay [*]
+          Zahl der Sekunden, um die verzoegert die Heilung eintritt,
+          z.B. weil das Essen erst zubereitet werden muss.
+        d_msg [**]
+          Meldung beim Bestellen, falls die Heilung verzoegert wird
+          Array mit 2 Strings: (1) fuer Empfaenger, (2) fuer Andere.
+
+          
+
+        [*] Dieser Parameter kann statt eines festen Zahlenwerts mit 
+            folgenden Werten gefuellt werden:
+
+            1) Mapping <racemodifier> der Form:
+                   ([ 0 : <standardwert> ,
+                    <rasse_1> : <wert_1>, 
+                    ... , 
+                    <rasse_n> : <wert_n> ]).
+               Die Eintraege in diesem Mapping werden gegen die Rasse des
+               bestellenden Spielers geprueft und entsprechend die 
+               zugehoerigen Werte verwendet.
+            2) string <func>: Aufruf erfolgt mittels 
+                 call_other(this_object(), func, empfaenger);
+               gerufen (aber: siehe Hinweise).
+            3) closure <func>: Aufruf erfolgt mittels
+                 funcall(func, empfaenger);
+            4) Array der Form  ({string <obj>, string <func>}) oder
+                               ({object <obj>, string <func>})
+               Aufruf erfolgt mittels
+                 call_other(obj, func, empfaenger);
+               (aber: siehe Hinweise). <obj> ist folglich als Objektpointer 
+               oder dessen object_name() anzugeben. <func> wird mittels 
+               function_exists() auf Existenz ueberprueft.
+
+               HINWEISE: im Falle von Lieferverzoegerung ("delay") und
+               Preis (P_VALUE) wird bei allen Funktionsaufrufen NICHT der 
+               Empfaenger, sondern der Zahler uebergeben.
+               Im Falle der Kontingent-Liste ("refresh") kann nur die
+               verfuegbare Menge modifiziert werden, nicht die Zeit
+               bis zum Wieder-Auffuellen.
+
+        [**] Zur Erzeugung variabler Meldungen koennen folgende Werte
+             eingetragen werden:
+
+             1) closure <func>: Aufruf erfolgt mittels 
+                  funcall(func, zahler, empfaenger, ident, minfo);
+             2) string <func>: Aufruf erfolgt mittels
+                  call_other(this_object(), func, zahler, empfaenger, 
+                             ident, minfo);
+             <func> bekommt Zahler und Empfaenger als Objektpointer,
+             ident als String und minfo als Mapping mit den 
+             jeweiligen Heilwerten uebergeben. minfo entspricht hierbei
+             den Daten, die als dritter Parameter an AddToMenu()
+             uebergeben wurden.
+             HINWEIS: wenn in das minfo-Mapping keine int-Festwerte 
+             eingetragen wurden, werden diese gemaess den Regeln unter [*]
+             geprueft; Funktionen/Closures werden ggf. ausgewertet und 
+             deren Rueckgabewerte an die Funktion <func> uebergeben.
+             WICHTIG: Die Rueckgabewerte der Funktion werden nicht 
+             ausgewertet. Jeder, der anstatt einer Meldung einen 
+             Funktionsaufruf programmiert, muss fuer die Ausgabe der
+             Meldungen selbst sorgen.
+
+                   
+
+BESCHREIBUNG
+------------
+::
+
+        Mit dieser Funktion werden Speisen oder Getraenke in die Karte
+        von Kneipen und Restaurants eingefuegt.
+
+RUECKGABEWERT
+-------------
+::
+
+        Rueckgabewert ist ein String "menuentry%d", wobei %d eine Nummer
+        ist, die darueber Auskunft gibt, den wievielten Eintrag in die
+        interne Karte der Kneipe diese Speise bzw. dieses Getraenk
+        darstellt. Im Prinzip handelt es sich bei dem String um einen Key
+        fuer ein Mapping, in dem die Speisen bzw. Getraenke gespeichert
+        sind.
+
+BEMERKUNGEN
+-----------
+::
+
+        Die aelteren Funktionen 'AddDrink' bzw. 'AddFood' werden zwar mithilfe
+        dieser maechtigeren Funktion aus Gruenden der Abwaertskompatibilitaet
+        simuliert, sollen aber nicht mehr eingesetzt werden.
+
+        
+
+        Die alten Platzhalter && etc. (s.u.) werden weiterhin unterstuetzt,
+        sollten aber fuer bessere Wartbarkeit nicht mehr verwendet werden.
+
+        
+
+        Fuer das Testen der Kneipe gibt es in jeder Kneipe den Befehl
+        'pubinit'. Hiermit lassen sich die Speisen und Getraenke durch-
+        checken. Steht in der Ausgabe bei einem Getraenk/Essen ein FAIL,
+        so wird die entsprechende Speise (oder Getraenk) NICHT an Spieler
+        verkauft. Ausnahmen fuer Speisen/Getraenke mit hoeheren maximalen
+        Werten sind durch Balance-EM zu genehmigen.
+
+BEISPIEL
+--------
+::
+
+        include <pub.h>
+
+        create()
+        {
+        AddToMenu("'Opa's Drachenkeule'",({"drachenkeule","keule"}),
+        ([P_HP:63,P_SP:63,P_FOOD:9,P_VALUE:528]), 5,
+        ({"Du isst die Keule mit einem schlechten Gewissen.",
+          "@WER1 isst die Keule mit einem schlechten Gewissen."}),
+        ([ PR_USER : 4; 1 , PR_ALL : 20; 3 ]), 9,
+        ({"Der unsichtbare Kneipier schneidet einem Rentner ein grosses "
+          "Stueck aus dessen Keule und bereitet sie Dir zu. Komisch, muss "
+          "wohl ein Tippfehler auf der Karte gewesen sein.",
+          "Der unsichtbare Kneipier schneidet einem hilflosen Opa ein "
+          "Stueck aus dessen Keule und braet diese fuer @WEN1."}) );
+        }
+
+        1) Name der Speise (des Getraenks) auf der Karte (bei menue).
+
+           AddToMenu("'Opa's Drachenkeule'",     
+
+        2) ids mit denen sich bestellen laesst (z.B. "kaufe keule").
+
+           ({"drachen","drachenkeule","keule"}),
+
+        3) Heilung fuer LP und KP, Saettigung (P_FOOD oder P_DRINK,
+           P_ALCOHOL nach Belieben setzen), Preis (P_VALUE). 
+           HP und SP muessen nicht gleich sein. Speisen und Getraenke,
+           die nur eines von beiden heilen, sind auch moeglich.
+
+           ([P_HP:63,P_SP:63,P_FOOD:9,P_VALUE:528]),
+
+        4) Heilung pro Heartbeat (in diesem Beispiel je 5 KP/LP).
+
+    
+
+           5,
+
+        5) Meldungen fuer Spieler und Umstehende die bei Genuss ausgege-
+           ben werden (also NICHT der Bestell-Text).
+
+           ({"Du isst die Keule mit einem schlechten Gewissen.",
+             "@WER1 isst die Keule mit einem schlechten Gewissen."}),
+
+           Die Ausgabe-Strings werden vor der Ausgabe mit dem Empfaenger
+           als Objekt an replace_personal() uebergeben. Fuer die
+           moeglichen Platzhalter siehe dort.
+
+          
+
+        6) Die Speise ist in ihrer Anzahl begrenzt. Fuer jeden Spieler
+           sind 4 Keulen pro reset() da. Ausserdem gibt es noch einen
+           "Notvorrat" von 20 Keulen, der alle 3 reset()s aufgefuellt
+           wird. Aus diesem (so noch vorhanden) werden die Spieler
+           versorgt, wenn ihr "persoenlicher Vorrat" aufgebraucht ist.
+
+           ([ PR_USER : 4; 1 , PR_ALL : 20; 3 ]),
+
+           
+
+           HINWEIS: bei Benutzung des Mappings muss <pub.h> inkludiert 
+           werden!
+
+           
+
+           Wenn man keine reset-abhaengigen Speisen haben moechte, traegt
+           man hier eine 0 ein.
+
+        7) Die Zahl ist die Wartezeit in Sekunden, die der Wirt z.B. fuer
+           die Zubereitung und Auslieferung an den Spieler braucht.
+
+           9,
+
+         
+
+        8) Letztendlich die Meldungen an Spieler und Umstehende, die bei Be-
+           stellung (hier 'kaufe keule') ausgegeben werden.
+
+           ({"Der unsichtbare Kneipier schneidet einem Rentner ein grosses "
+           "Stueck aus dessen Keule und bereitet sie Dir zu. Komisch, muss "
+           "wohl ein Tippfehler auf der Karte gewesen sein.",
+           "Der unsichtbare Kneipier schneidet einem hilflosen Opa ein "
+           "Stueck aus dessen Keule und braet diese fuer @WEN1."}));
+
+LISTE DER ALTEN PLATZHALTER (DEPRECATED):
+           &&  - pl->name(WER,2)
+           &1& - pl->name(WER,2)
+           &2& - pl->name(WESSEN,2)
+           &3& - pl->name(WEM,2)
+           &4& - pl->name(WEN,2)
+           &1# - capitalize(pl->name(WER,2))
+           &2# - capitalize(pl->name(WESSEN,2))
+           &3# - capitalize(pl->name(WEM,2))
+           &4# - capitalize(pl->name(WEN,2))
+           &!  - pl->QueryPronoun(WER)
+           &5& - pl->QueryPronoun(WE);
+           &6& - pl->QueryPronoun(WESSEN)
+           &7& - pl->QueryPronoun(WEM)
+           &8& - pl->QueryPronoun(WEN)
+           &5# - capitalize(pl->QueryPronoun(WER))
+           &6# - capitalize(pl->QueryPronoun(WESSEN))
+           &7# - capitalize(pl->QueryPronoun(WEM))
+           &8# - capitalize(pl->QueryPronoun(WEN))
+
+SIEHE AUCH
+----------
+::
+
+        AddFood(), AddDrink(), /sys/pub.h
+        RemoveFromMenu(), replace_personal()
+
+Last modified: Sam, 01. Okt 2011, 23:40 by Arathorn
+
diff --git a/doc/sphinx/lfun/AddTouchDetail.rst b/doc/sphinx/lfun/AddTouchDetail.rst
new file mode 100644
index 0000000..ca81e2b
--- /dev/null
+++ b/doc/sphinx/lfun/AddTouchDetail.rst
@@ -0,0 +1,90 @@
+AddTouchDetail()
+================
+
+FUNKTION
+--------
+::
+
+    void AddTouchDetail(string|string* keys,
+                        string|string*|mapping|closure desc);
+
+DEFINIERT IN
+------------
+::
+
+    /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+    keys
+     String oder Array von Strings mit den Namen der Details.
+    desc
+     String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion entspricht dem AddDetail() fuer Standarddetails, nur
+    koennen hiermit (ab)tastbare bzw. fuehlbare Details realisiert werden:
+    Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
+    beim (Ab)Tasten aussehen, haengt im wesentlichen vom Typ der
+    Beschreibung <desc> ab:
+     <desc> ist ein String.
+       Beim Untersuchen wird dieser String zurueckgegeben.
+      <desc> ist ein String-Array.
+        Beim Untersuchen wird zufaellig einer der Strings zurueckgegeben.
+     <desc> ist ein Mapping.
+       Das Mapping muss folgenden Aufbau haben:
+         ([0:        "Defaulttext",
+           "rasse1": "r1text", ...]).
+
+       Falls fuer die Rasse des das Detail untersuchenden Spielers ein
+       Eintrag im Mapping existiert, wird der entsprechende Text
+       zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
+       rassenabhaengige Details moeglich. Siehe auch die Beispiele.
+     <desc> ist eine Closure.
+       In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
+       zurueckgegeben. Die Closure bekommt dabei den Namen des Details
+       als Parameter uebergeben.
+
+    Fuer fuehlbare Details koennen Forscherpunkte eingetragen werden.
+
+    Fuehlbare Details koennen allgemein einen Raum oder Objekt zugeordnet
+    werden: dafuer muss man als <key> SENSE_DEFAULT uebergeben.
+
+    Spielerkommandos: "taste"
+
+BEISPIELE
+---------
+::
+
+    Ein kleines Beispiel fuer rassenabhaengige, fuehlbare Details mit Closures:
+      string strafe(string key);
+      ...
+      AddTouchDetail(SENSE_DEFAULT, "Du fuehlst einige Knollen\n");
+      AddTouchDetail(({"knollen"}),
+                     ([0:       "Sie fuehlen sich an wie Knoblauchknollen. "
+                                "Riech doch mal daran.\n",
+                       "vampir": #'strafe]));
+
+      string strafe(string key) {
+        this_player()->reduce_hit_points(100);
+        return "Au! Das waren ja Knoblauchknollen!\n";
+      }
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddDetail(), AddReadDetail(), AddSmells(), AddSounds()
+    Loeschen:  RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+               RemoveSounds(), RemoveTouchDetail()
+    Daten:     P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+    Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AllGroups.rst b/doc/sphinx/lfun/AllGroups.rst
new file mode 100644
index 0000000..bd4f50f
--- /dev/null
+++ b/doc/sphinx/lfun/AllGroups.rst
@@ -0,0 +1,36 @@
+AllGroups()
+===========
+
+FUNKTION
+--------
+::
+
+     string *AllGroups()
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/materialdb.c (MATERIALDB)
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt ein Array aller existenten Materialgruppen zurueck (ihre
+     Definitionsform wie in <thing/material.h> aufgelistet).
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Listen:	  AllMaterials(), Dump()
+		  materialliste, materialgruppen
+     Master:	  AddMaterial(), ConvMaterialList(), MaterialGroup(),
+		  GroupName(), MaterialName(),
+		  GetGroupMembers(), GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/AllMaterials.rst b/doc/sphinx/lfun/AllMaterials.rst
new file mode 100644
index 0000000..1d8142a
--- /dev/null
+++ b/doc/sphinx/lfun/AllMaterials.rst
@@ -0,0 +1,36 @@
+AllMaterials()
+==============
+
+FUNKTION
+--------
+::
+
+     string *AllMaterials()
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/materialdb.c (MATERIALDB)
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt ein Array aller existenten Materialien zurueck (ihre Definitions-
+     form wie in <thing/material.h> aufgelistet).
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Listen:	  AllGroups(), Dump()
+		  materialliste, materialgruppen
+     Master:	  AddMaterial(), ConvMaterialList(), MaterialGroup(),
+		  GroupName(), MaterialName(),
+		  GetGroupMembers(), GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/AssocMember.rst b/doc/sphinx/lfun/AssocMember.rst
new file mode 100644
index 0000000..601587c
--- /dev/null
+++ b/doc/sphinx/lfun/AssocMember.rst
@@ -0,0 +1,75 @@
+AssocMember()
+=============
+
+FUNKTION
+--------
+::
+
+        int AssocMember(object npc)
+
+DEFINIERT IN
+------------
+::
+
+        /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+        Der zuzuordnende NPC.
+
+BESCHREIBUNG
+------------
+::
+
+        Ordnet einen NPC einem Spieler zu. Dieser ist dann
+        immer im Team des Spielers, moeglichst in der gleichen Reihe.
+
+RUECKGABEWERT
+-------------
+::
+
+        1, falls Zuordnung erfolgreich, sonst 0.
+
+BEISPIEL
+--------
+::
+
+        void fun(object pl)
+        {
+          if ( pl && pl->AssocMember(this_object()) )
+            tell_object(pl,break_string(
+              "Ich kaempfe nun auf Deiner Seite!\n",78,"Ein Feuerteufel "
+              "teilt Dir mit:");
+         ...
+        }
+
+BEMERKUNGEN
+-----------
+::
+
+        1. Kann nur von Gilden, Spellbooks, vom Objekt selber und vom
+           zuzuordnenden NPC aufgerufen werden.
+        2. Einem NPC, der selber einem Spieler zugeordnet ist, kann kein
+           NPC zugeordnet werden.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_TEAM_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 04.10.2011, Zesstra
+
diff --git a/doc/sphinx/lfun/Attack.rst b/doc/sphinx/lfun/Attack.rst
new file mode 100644
index 0000000..9281478
--- /dev/null
+++ b/doc/sphinx/lfun/Attack.rst
@@ -0,0 +1,42 @@
+Attack()
+========
+
+FUNKTION
+--------
+::
+
+	void Attack(object enemy)
+
+ARGUMENTE
+---------
+::
+
+	enemy: Der Feind.
+
+BESCHREIBUNG
+------------
+::
+
+	Der Feind wird der Staerke der Waffe (bzw. der Haende) entsprechend
+	stark angegriffen.
+
+RUECKGABEWERT
+-------------
+::
+
+	Keiner.
+
+BEMERKUNG
+---------
+::
+
+	Diese Funktion gibt die Angriffsmeldung aus.
+	Falls mit blossen Haenden angegriffen wird, ist die Staerke
+	(2*Staerke_der_Haende + 10*A_STR)/3
+
+SIEHE AUCH
+----------
+::
+
+	"Defend", "QueryDamage"
+
diff --git a/doc/sphinx/lfun/BecomesNetAlive.rst b/doc/sphinx/lfun/BecomesNetAlive.rst
new file mode 100644
index 0000000..a2f0c37
--- /dev/null
+++ b/doc/sphinx/lfun/BecomesNetAlive.rst
@@ -0,0 +1,68 @@
+BecomesNetAlive()
+=================
+
+FUNKTION
+--------
+::
+
+    void BecomesNetAlive(object pl);
+
+GERUFEN VON
+-----------
+::
+
+    /std/player/base.c
+
+ARGUMENTE
+---------
+::
+
+    pl
+      Spieler, der Verbindung zum MUD wiedererlangt.
+
+BESCHREIBUNG
+------------
+::
+
+    Spieler, welche die Verbindung zum MUD freiwillig
+    (z.B. per 'schlafe ein') oder unfreiwillig verlieren, gehen in den
+    Netztotenstatus ueber. Sie verbleiben noch eine definierte Zeit in
+    der zuletzt betretenen Umgebung und werden schliesslich automatisch
+    in den Netztotenraum ueberfuehrt.
+    Wird die Verbindung wieder aufgebaut, so wird der Spielercharakter
+    wieder zum Leben erweckt und gegebenenfalls zuvor aus dem
+    Netztotenraum zurueck zu seiner letzten Umgebung teleportiert.
+    Um nun einen Ueberblick darueber zu erhalten, wann ein Spieler die
+    Verbindung zum MUD wiederherstellt, gibt es die Funktion
+    BecomesNetAlive(). Sie wird automatisch in der Umgebung des
+    Spielers, in allen Objekten in der Umgebung des Spielers
+    (nicht rekursiv) und in allen Objekten im Spieler (rekursiv)
+    aufgerufen. Uebergeben wird hierbei das Spielerobjekt.
+
+    Es gibt auch noch die Funktion BecomesNetDead(), mit der man
+    auf aehnliche Weise einschlafende Spieler registrieren kann.
+
+BEISPIELE
+---------
+::
+
+    In einem NPC waere folgendes denkbar:
+
+    
+
+    void BecomesNetAlive(object pl) {
+      tell_room(environment(),break_string(
+        "Guten Morgen "+pl->name(WER)+", auch schon ausgeschlafen?!", 77,
+        Name(WER)+" sagt grinsend: "));
+    }
+    Steht der NPC in einem Raum, wo ein Spieler aufwacht, so wird der
+    Spieler gebuehrend begruesst.
+
+SIEHE AUCH
+----------
+::
+
+    BecomesNetDead(), PlayerQuit(), /std/player/base.c, /room/netztot.c
+
+24. Aug 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/BecomesNetDead.rst b/doc/sphinx/lfun/BecomesNetDead.rst
new file mode 100644
index 0000000..4cd9042
--- /dev/null
+++ b/doc/sphinx/lfun/BecomesNetDead.rst
@@ -0,0 +1,67 @@
+BecomesNetDead()
+================
+
+FUNKTION
+--------
+::
+
+    void BecomesNetDead(object pl);
+
+GERUFEN VON
+-----------
+::
+
+    /std/player/base.c
+
+ARGUMENTE
+---------
+::
+
+    object pl
+      Spieler, der Verbindung zum MUD verliert.
+
+BESCHREIBUNG
+------------
+::
+
+    Spieler, welche die Verbindung zum MUD freiwillig
+    (z.B. per 'schlafe ein') oder unfreiwillig verlieren, gehen in den
+    Netztotenstatus ueber. Sie verbleiben noch eine definierte Zeit in
+    der zuletzt betretenen Umgebung und werden schliesslich automatisch
+    in den Netztotenraum ueberfuehrt.
+    Um nun einen Ueberblick darueber zu erhalten, wann ein Spieler die
+    Verbindung zum MUD verliert, gibt es die Funktion BecomesNetDead().
+    Sie wird automatisch in der Umgebung des Spielers, in allen Objekten
+    in der Umgebung des Spielers (nicht rekursiv) und in allen Objekten
+    im Spieler (rekursiv) aufgerufen. Uebergeben wird hierbei das
+    Spielerobjekt.
+
+    Es gibt auch noch die Funktion BecomesNetAlive(), mit der man
+    auf aehnliche Weise erwachende Spieler registrieren kann.
+
+BEISPIELE
+---------
+::
+
+    Es gibt Gebiete, in denen netztote Spieler unerwuenscht sind.
+    Folgendermassen kann man sich ihrer wirkungsvoll entledigen:
+
+    
+
+    void BecomesNetDead(object pl) {
+      pl->move("eingangsraum zu gebiet", M_TPORT|M_NOCHECK);
+    }
+    Man schickt diese Spieler wieder zum Eingang des Gebietes.
+    Da der letzte Aufenthaltsort eines Spielers, der in den
+    Netztotenstatus uebergeht, erst nach Aufruf der Funktion
+    BecomesNetDead() abgespeichert wird, wacht der Spieler dann an dem
+    Ort auf, wo man Ihn innerhalb dieser Funktion hinteleportiert hat.
+
+SIEHE AUCH
+----------
+::
+
+    BecomesNetAlive(), PlayerQuit(), /std/player/base.c, /room/netztot.c
+
+24. Aug 2011, Gloinson
+
diff --git a/doc/sphinx/lfun/CannotSee.rst b/doc/sphinx/lfun/CannotSee.rst
new file mode 100644
index 0000000..b9fe25b
--- /dev/null
+++ b/doc/sphinx/lfun/CannotSee.rst
@@ -0,0 +1,50 @@
+CannotSee()
+===========
+
+FUNKTION
+--------
+::
+
+     varargs int CannotSee(int silent);
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/light.c
+
+ARGUMENTE
+---------
+::
+
+     silent - Soll an das Lebewesen direkt automatisch eine Meldung
+              ausgegeben werden wenn es nichts sehen kann?
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion prueft ob das Lebewesen etwas sehen kann, oder nicht.
+     Hierbei wird sowohl das Lichtlevel mit saemtlichen Modifikatoren,
+     als auch Nachtsicht und die Property P_BLIND beruecksichtigt. Da
+     diese Funktion bei zukuenftigen Mudlibaenderungen immer aktualisiert
+     werden duerfte, sollte man sie nach Moeglichkeit benutzen und die
+     Abfragen nicht selbst implementieren.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn der Spieler etwas sehen kann
+     1, wenn der Spieler nichts sehen kann: Blindheit
+     2, wenn der Spieler nichts sehen kann: zu wenig Licht/keine Nachtsicht
+
+SIEHE AUCH
+----------
+::
+
+     P_BLIND, P_LIGHT_MODIFIER, P_PLAYER_LIGHT
+
+
+Last modified: Mon Jan 17 18:22:27 2000 by Padreic
+
diff --git a/doc/sphinx/lfun/ChangeMiniQuest.rst b/doc/sphinx/lfun/ChangeMiniQuest.rst
new file mode 100644
index 0000000..cf43274
--- /dev/null
+++ b/doc/sphinx/lfun/ChangeMiniQuest.rst
@@ -0,0 +1,72 @@
+ChangeMiniQuest()
+=================
+
+FUNKTION
+--------
+::
+
+    int ChangeMiniQuest(mixed questgeber, int parameter, mixed newvalue)
+
+DEFINIERT IN
+------------
+::
+
+    /secure/questmaster
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion aendert einen Parameter einer Miniquest im Questmaster,
+    schreibt fuer diese Aktion einen Log-Eintrag und erstellt das Miniquest-
+    Dumpfile neu.
+
+ARGUMENTE
+---------
+::
+
+    questgeber - Ladename des Objekts (string), das die Miniquest vergibt, 
+                 oderdie Indexnummer (int) der Miniquest in der MQ-Liste
+    parameter  - Angabe des zu aendernen Parameters (Position des Values
+                 im Miniquests-Mapping):
+                 0 : Miniquest-Stufenpunkte, mind. 1
+                 2 : Aufgabenbeschreibung der Miniquest (string)
+                 3 : Sichtbarkeit der Miniquest (0/1), default ist 1
+                 4 : aktiv/inaktiv (1/0)
+                 5 : Titel der Miniquest
+                 6 : "geschafft"-Beschreibung nach Abschluss der MQ
+                 7 : Voraussetzungen, Mapping im Format von P_RESTRICTIONS
+                 8 : zugeordnete Region, String wie z.B."polar", "gebirge"
+                 9 : erlaubte Abfrageobjekte, Array von Ladenamen, z.B.
+                     ({"/d/region/magier/npc/infonpc"}), es koennen mehrere 
+                     Objekte eingetragen sein
+    newvalue   - neuer Wert fuer den angegebenen Parameter
+
+RUECKGABEWERTE
+--------------
+::
+
+     1: hat geklappt
+     0: Zugriff verweigert
+    -2: ungueltiger Datentyp eines der Argumente, bei Parameter 9 wird
+        ein uebergebenes Array zusaetzlich auf Leerstrings und Elemente
+        geprueft, die keine Strings sind. Wenn das Array ausschliesslich
+        aus solchen Elementen besteht, wird ebenfalls -2 zurueckgegeben.
+
+BEMERKUNGEN
+-----------
+::
+
+    Das Flag "active" laesst sich bequemer ueber die Questmaster-Funktion
+    SwitchMiniQuestActive() umschalten.
+    Der Miniquest-Titel darf kein "in" oder "im" enthalten, weil dann die
+    Eintraege in der Fraternitas-Bibliothek nicht gelesen werden
+    koennen.
+
+SIEHE AUCH
+----------
+::
+
+   AddMiniQuest(L)
+   P_RESTRICTIONS
+
diff --git a/doc/sphinx/lfun/ChangeReputation.rst b/doc/sphinx/lfun/ChangeReputation.rst
new file mode 100644
index 0000000..362c33d
--- /dev/null
+++ b/doc/sphinx/lfun/ChangeReputation.rst
@@ -0,0 +1,72 @@
+ChangeReputation()
+==================
+
+FUNKTION
+--------
+::
+
+     public varargs int ChangeReputation(string repid, int value, int silent)
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/reputation.c
+
+ARGUMENTE
+---------
+::
+
+     repid
+       Jede neue Reputationsgruppe muss anfangs mit einer eindeutigen ID von 
+       einem EM in den Reputationsmaster eingetragen werden. Danach kann man 
+       ueber die eindeutige ID <repid> auf sie zugreifen.
+     value
+       Der Wert, um den die Reputation geaendert werden soll. Positive Werte 
+       erhoehen die Reputation, negative verschlechtern sie.
+     silent
+       Ein optionales Flag. Falls gesetzt, wird keine Standardmeldung ueber 
+       die Reputationsaenderung an den Spieler ausgegeben. Man koennte dann 
+       eigene Meldungen ausgeben.
+
+BESCHREIBUNG
+------------
+::
+
+     Vor der Aenderung wird ein Check auf die UID des ausfuehrenden Objektes
+     ausgefuehrt, "fremde" Reputationen darf man somit nicht veraendern.
+     Man kann aber selbstverstaendlich in begruendeten Faellen mit dem
+     zustaendigen Magier/Regionsmagier sprechen, ob man ebenfalls Zugriff
+     erhaelt. Eingetragen wird dies schlussendlich durch einen EM.
+
+RUeCKGABEWERT
+-------------
+::
+
+     REP_RET_SUCCESS    Reputation wurde veraender.
+     REP_RET_SUCCESSCUT Reputation wurde auf Min / Max veraendert
+     REP_RET_WRONGARGS  Falsche Argumente fuer ChangeRep()
+     REP_RET_INVALIDUID Unzulaessige UID / keine Zugriffsrechte
+     REP_RET_ALREADYMAX Reputation bereits Max / Min
+     REP_RET_INACTIVE   Reputation momentan inaktiv
+     REP_RET_INVALIDREP Reputation nicht vorhanden
+
+BEISPIELE
+---------
+::
+
+     s. reputation
+
+SIEHE AUCH
+----------
+::
+
+     reputation
+     GetReputation(), GetReputations()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+06.04.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/CheckFindRestrictions.rst b/doc/sphinx/lfun/CheckFindRestrictions.rst
new file mode 100644
index 0000000..2932eed
--- /dev/null
+++ b/doc/sphinx/lfun/CheckFindRestrictions.rst
@@ -0,0 +1,47 @@
+CheckFindRestrictions()
+=======================
+
+FUNKTION
+--------
+::
+
+    varargs int CheckFindRestrictions(object ob, mixed restr, closure qp)
+
+ 
+
+DEFINIERT IN
+------------
+::
+
+    /std/room/shop.c
+
+ 
+
+ARGUMENTE
+---------
+::
+
+    ob     - Objekt
+    restr  - zusaetzliches Argument
+    qp     - symbol_function("QueryProp",ob)
+
+BESCHREIBUNG
+------------
+::
+
+    Funktion, die FindBestWeapon / FindBestArmours einschraenkt.
+    Wird in Wert ungleich 0 zurueckgeliefert, so wird das Objekt
+    nicht genommen.
+
+RUECKGABEWERT
+-------------
+::
+
+    Normalerweise 0
+
+SIEHE AUCH
+----------
+::
+
+    FindBestWeapon(), FindBestArmours()
+
diff --git a/doc/sphinx/lfun/CheckLightType.rst b/doc/sphinx/lfun/CheckLightType.rst
new file mode 100644
index 0000000..eed5317
--- /dev/null
+++ b/doc/sphinx/lfun/CheckLightType.rst
@@ -0,0 +1,110 @@
+CheckLightType()
+================
+
+FUNKTION
+--------
+::
+
+	varargs int CheckLightType(int lighttype, int mode);
+
+DEFINIERT IN
+------------
+::
+
+	/std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+	lighttype
+	  Auf diesen Lichttyp wird getestet.
+	mode
+	  Die Methode, nach der der Lichttyp ueberprueft wird.
+
+BESCHREIBUNG
+------------
+::
+
+        Die Funktion prueft, ob der uebergebene lighttype mit dem in
+        P_LIGHT_TYPE definierten Lichttyp uebereinstimmt. 
+
+        Dabei kann in verschiedenen Modi getestet werden:
+
+        LT_CHECK_ANY
+          Es wird geprueft, ob mindestens einer der in lighttype ueber
+          gebenen Lichttypen im Objekt vorhanden ist. Dies ist das
+          Standardverhalten (default) der Funktion.
+
+        LT_CHECK_ALL     
+          Es wird geprueft, ob alle in lighttype definierten Lichttypen
+          vorhanden sind. Es koennen aber auch mehr Lichttypen definiert
+          sein.
+
+        LT_CHECK_MATCH   
+          Es wird geprueft, ob genau die in lighttype definierten Licht-
+          tyen definiert sind, sind mehr oder weniger vorhanden, gibt die
+          Funktion 0 zurueck.
+
+        LT_CHECK_NONE    
+          Es wird geprueft, ob keiner der uebergebenen Lichttypen vorhanden
+          sind. Ob sonst noch andere Lichttypen vorhanden sind, ist dabei 
+          egal.
+
+RUeCKGABEWERT
+-------------
+::
+
+	0 wenn die geprueften Bedingungen nicht korrekt sind, sonst 
+        ein Wert ungleich 0.
+
+BEISPIELE
+---------
+::
+
+        In einem Raum scheint die Sonne, ausserdem gibt es dort ein Lager-
+        feuer und ein Objekt mit magischem Gluehen (meine Phantasie streikt
+        grad):
+
+        raum->SetProp( P_LIGHT_TYPE, LT_SUN|LT_OPEN_FIRE|LT_GLOWING );
+
+        Es soll getestet werden, ob an in dem Raum Tageslicht herrscht:
+
+        raum->CheckLightType(LT_DAYLIGHT, LT_CHECK_ANY);
+        raum->CheckLightType(LT_DAYLIGHT); // gleichwertig
+
+        Die Funktion ergibt wahr, da LT_DAYLIGHT unter anderem LT_SUN ent-
+        haelt (vgl man P_LIGHT_TYPES).
+
+        Es soll getestet werden, dass weder Mond noch Sterne im Raum sind:
+
+        raum->CheckLightType(LT_MOON|LT_STARS, LT_CHECK_NONE);
+
+        Die Funktion ergibt wahr, da die beiden nicht gesetzt sind.
+
+        Es soll geprueft werden, ob Mond und Sterne im Raum leuchten:
+
+        raum->CheckLightType(LT_MOON|LT_STARS, LT_CHECK_ALL);
+
+        Die Funktion ergibt falsch, da keins der beiden Lichter vorhanden
+        ist. Sie ergaebe aber auch falsch, wenn einer der beiden Typen
+        vorhanden waer. Nur wenn beide vorhanden sind, gibt LT_CHECK_ALL
+        wahr.
+
+BEMERKUNG
+---------
+::
+
+        Lighttypes haben nichts mit dem Lichtsystem zu tun. Sie dienen 
+        nur der Beschreibung der Lichtverhaeltnisse an/in einem Objekt.
+        Objekte mit verschiedenen Lichtverhaeltnissen beeinflussen sich
+        gegenseitig nicht.
+
+SIEHE AUCH
+----------
+::
+
+        /std/thing/description.c, /std/thing/lighttypes.h, P_LIGHT_TYPE
+
+Last modified: Fri Jun 11 20:47:33 2004 by Vanion
+
diff --git a/doc/sphinx/lfun/CheckResistance.rst b/doc/sphinx/lfun/CheckResistance.rst
new file mode 100644
index 0000000..7254068
--- /dev/null
+++ b/doc/sphinx/lfun/CheckResistance.rst
@@ -0,0 +1,37 @@
+CheckResistance()
+=================
+
+FUNKTION
+--------
+::
+
+	CheckRessistance(string* dam_type_list)
+
+ARGUMENTE
+---------
+::
+
+	dam_type_list: Liste der Schadensarten, die geprueft werden
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Funktion ueberprueft, gegen welche der angegebenen
+	Schadensarten das Lebewesen resistent oder verletzlich ist und
+	gibt einen Faktor zurueck, der mit dem Schaden multipliziert wird.
+	Dieser Faktor betraegt normalerweise 1, bei bei jeder Resistenz
+	wird er halbiert und bei jeder Verletzlichkeit verdoppelt.
+
+RUECKGABEWERT
+-------------
+::
+
+	Ein Faktor, der mit dem Schaden multipliziert wird, vom Typ "float".
+
+SIEHE AUCH
+----------
+::
+
+	"Defend"
+
diff --git a/doc/sphinx/lfun/CheckSensitiveAttack.rst b/doc/sphinx/lfun/CheckSensitiveAttack.rst
new file mode 100644
index 0000000..7c971d3
--- /dev/null
+++ b/doc/sphinx/lfun/CheckSensitiveAttack.rst
@@ -0,0 +1,54 @@
+CheckSensitiveAttack()
+======================
+
+FUNKTION
+--------
+::
+
+     void CheckSensitiveAttack(int dam, string *dam_type, mixed spell,
+			       object enemy)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/inventory.c
+
+ARGUMENTE
+---------
+::
+
+     dam	- an Defend uebergebener Schaden
+     dam_type	- Schadenstyp(en)
+     spell	- spell, int oder mapping
+     enemy	- Feindesobjekt
+
+BESCHREIBUNG
+------------
+::
+
+     Wird von Defend() aufgerufen und prueft die Listen in
+     P_SENSITIVE_ATTACK durch.
+     Wenn die Schluessel und Threshold-Werte stimmen, wird
+     trigger_sensitive_attack(enemy,key,dam,spell,options)
+     im Objekt gerufen.
+
+BEMERKUNGEN
+-----------
+::
+
+     Objekte mit P_SENSITIVE mit Schluessel SENSITIVE_ATTACK bitte vorsichtig
+     verwenden, da rechenintensiv.
+
+SIEHE AUCH
+----------
+::
+
+     P_SENSITIVE
+     InsertSensitiveObject, RemoveSensitiveObject
+     insert_sensitive_inv_trigger, insert_sensitive_inv
+     P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY,
+     P_SENSITIVE_INVENTORY_TRIGGER
+
+28.Jan.2001, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/CheckSpellFatigue.rst b/doc/sphinx/lfun/CheckSpellFatigue.rst
new file mode 100644
index 0000000..26a9f6c
--- /dev/null
+++ b/doc/sphinx/lfun/CheckSpellFatigue.rst
@@ -0,0 +1,86 @@
+CheckSpellFatigue()
+===================
+
+FUNKTION
+--------
+::
+
+    public varargs int CheckSpellFatigue(string key)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skills.c
+    /std/player/skills.c
+    /sys/living/skills.h
+
+ARGUMENTE
+---------
+::
+
+    string key  : Eindeutiger Name des Spruches, einer Gruppe von Spruechen
+                  oder 0 fuer die globale Spruchermuedung.
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion dient zum Pruefen von individuellen Spruchermuedungen
+    (Spellfatigue, Spruchsperren).
+    Hiermit lassen sich unabhaengige Ermuedungen/Sperren fuer einzelne
+    Sprueche oder Gruppen von Spruechen gestalten.
+
+    Wird <key> nicht angegeben oder ist 0, wird die globale Spruchsperre
+    geprueft (identisch zu der Property P_NEXT_SPELL_TIME), anderenfalls 
+    die unter <key> gespeicherte Spruchermuedung.
+    Prueft man einen Eintrag ohne Angabe von <key> ist das Ergebnis dieser
+    Funktion identisch zur Abfrage von P_NEXT_SPELL_TIME.
+
+RUeCKGABEWERT
+-------------
+::
+
+    0    Spruchermuedung existiert nicht oder ist abgelaufen.
+
+    >0   Spruchermuedung ist noch nicht abgelaufen, Rueckgabewert ist die
+         Zeit, bei der dieser Eintrag ablaeuft. Der Spruch darf _nicht_
+         ausgefuehrt werden.
+
+BEISPIELE
+---------
+::
+
+    Ein Spell gehoert zu einer Gruppe von Spells mit dem Namen 'extrasuess'.
+    Er darf nur ausgefuehrt werden, wenn seit 5s kein anderer Spruch aus der
+    Gruppe ausgefuehrt wurde.
+    if (ob->CheckSpellFatigue("extrasuess") {
+      // alte Sperre noch nicht abgelaufen.
+      tell_object(ob, "Deine unendliche Schokotorte ist noch nicht wieder "
+        "nachgewachsen.\n");
+      return ... ;
+    }
+
+BEMERKUNGEN
+-----------
+::
+
+    Die genauen Zeitdauern koennen von Spielern beeinflusst werden, sie
+    unterliegen der jeweiligen Einstellung von 'spruchermuedung', d.h. koennen
+    auf volle 2s aufgerundet werden.
+    Auch wenn diese Funktion zum Verwalten von beliebigen Zeitsperren genutzt
+    werden koennen, beschraenkt euch bitte auf Spruchermuedungen und benutzt
+    ansonsten check_and_update_timed_key(). Falls ihr diesbzgl. weitere/andere
+    Wuensche habt, sprecht den/die Mudlib-EM an.
+
+SIEHE AUCH
+----------
+::
+
+    SetSpellFatigue(L), DeleteSpellFatigue(L)
+    P_NEXT_SPELL_TIME
+    spruchermuedung
+
+
+27.03.2010, Zesstra
+
diff --git a/doc/sphinx/lfun/ClearRingBuffer.rst b/doc/sphinx/lfun/ClearRingBuffer.rst
new file mode 100644
index 0000000..e7beddc
--- /dev/null
+++ b/doc/sphinx/lfun/ClearRingBuffer.rst
@@ -0,0 +1,58 @@
+ClearRingBuffer()
+=================
+
+FUNKTION
+--------
+::
+
+    protected struct std_ringbuffer ClearRingBuffer(struct std_ringbuffer b);
+
+DEFINIERT IN
+------------
+::
+
+    /std/util/ringbuffer.c
+    /sys/util/ringbuffer.h
+
+ARGUMENTE
+---------
+::
+
+    b - der zu loeschende Ringpuffer
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion loescht alle Daten aus dem Puffer <b> und re-initialisiert
+    ihn.
+
+    
+
+RUeCKGABEWERT
+-------------
+::
+
+    Der geloeschte Puffer <b> wird wieder zurueckgegeben.
+
+BEISPIELE
+---------
+::
+
+    // Ringpuffer anlegen:
+    struct std_ringbuffer buffer=CreateRingBuffer(10, MODE_FIFO);
+    // mit irgendwelchen Daten fuellen...
+    // ...
+    // Puffer loeschen
+    buffer = ClearRingBuffer(buffer);
+    // oder:
+    ClearRingBuffer(buffer);
+
+SIEHE AUCH
+----------
+::
+
+    CreateRingBuffer(), RingBufferGet(), ResizeRingBuffer()
+
+23.05.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/Configure.rst b/doc/sphinx/lfun/Configure.rst
new file mode 100644
index 0000000..6d0758b
--- /dev/null
+++ b/doc/sphinx/lfun/Configure.rst
@@ -0,0 +1,104 @@
+Configure()
+===========
+
+Configure()
+
+  public mixed Configure(mixed data)
+-------------------------------------------------
+::
+
+DEFINIERT IN
+------------
+::
+
+   Beliebigen Objekten
+
+ARGUMENTE
+---------
+::
+
+   <data>
+     0 fuer Datenabfrage
+     beliebige Daten, die ein Configure(0) vorher lieferte
+
+BESCHREIBUNG
+------------
+::
+
+   Viele Objekte werden fuer bestimmte Spieler konfiguriert und so
+   personalisiert. Sie enthalten zusaetzlich zu den Daten, welche waehrend des
+   create() gesetzt wurden, noch weitere spieler-individuelle Daten.
+   Damit diese Objekte im Bedarfsfall neu erstellt werden koennen, sollte ein
+   geeignetes Configure() definfiert werden, um diese Daten abzurufen und in
+   einem neuen Clone (oder neugeladener Blueprint) wieder zu setzen.
+
+   
+
+   Existiert Configure() im Objekt, MUSS dieses bei einem Aufruf mit
+   <data>==0 (d.h. Configure(0)) alle individuellen Daten zurueckliefern,
+   die noetig sind, um den aktuellen Zustand des Objektes spaeter
+   wiederherzustellen.
+   Das Objekt darf nach dem Zurueckgeben dieser Daten diese NICHT mehr
+   veraendern, d.h. es muss ggf. eine Kopie erstellt werden (copy, deep_copy)
+
+   Genau diese Daten werden in einem neu geclonten Objekt durch den Aufruf
+   von Configure(data) wieder gesetzt. Das Configure MUSS genau die Daten, die
+   es im alten Objekt zurueckliefert, wieder akzeptieren.
+
+RUeCKGABEWERT
+-------------
+::
+
+   Wenn <data>==0:
+     Alle individuellen Daten in einer beliebigen Form. Ein Mapping bietet
+     sich jedoch an.
+     Nicht erlaubt sind: Objekte und Closures.
+
+   Wenn <data>!=0:
+     1, wenn die Daten zur Konfiguration akzeptiert wurden.
+     0, sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+   Configure() ist nicht verpflichtet, erneut Daten zu akzeptieren, wenn es
+   bereits einmal mit gueltigen Daten aufgerufen wurde.
+   Das Zurueckschreiben der Daten kann auch nach Ablauf laengerer Zeit
+   und/oder in einer anderen Uptime erfolgen.
+
+BEISPIELE
+---------
+::
+
+   Ein Objekt, welches ein anderes Objekt sicher ersetzt, d.h. die
+   individuelle Konfiguration bleibt erhalten:
+   mixed data;
+   if (call_resolved(data,ob,"Configure",0) == 1) {
+     string obname = load_name(ob);
+     ob->remove();
+     ob = clone_object(obname);
+     if (data) {
+       if (ob->Configure(data) == 1) {
+         printf("Instanz von %s erfolgreich ersetzt, neues Objekt: %O\n",
+             obname,ob);
+       }
+       else {
+         raise_error(sprintf("Configure() in %O akzeptierte Daten nicht!\n",
+             ob));
+       }
+     }
+   }
+   else {
+     printf(break_string(
+         "Das Objekt %O definiert keine Funktion Configure(). Es kann "
+         "nicht sicher ersetzt werden, da unbekannt ist, ob es individuelle "
+         "Daten enthaelt.",78));
+   }
+
+LETZTE AeNDERUNG
+----------------
+::
+
+26.09.2011, Zesstra
+
diff --git a/doc/sphinx/lfun/ConvMaterialList.rst b/doc/sphinx/lfun/ConvMaterialList.rst
new file mode 100644
index 0000000..0ca9b1a
--- /dev/null
+++ b/doc/sphinx/lfun/ConvMaterialList.rst
@@ -0,0 +1,65 @@
+ConvMaterialList()
+==================
+
+FUNKTION
+--------
+::
+
+     varargs string ConvMaterialList(mixed mats, int casus, mixed idinf)
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/materialdb.c (MATERIALDB)
+
+ARGUMENTE
+---------
+::
+
+     mixed mats:  - das zu erkennende Material:
+                    - ein Mapping, ein String oder ein Stringarray
+                      ([MAT_A:y,MAT_B:x,..]) oder MAT_A oder ({MAT_A,MAT_B,..})
+     int casus:   - der Fall: 0..3 -> <language.h>: WAS, WESSEN, WEM, WEN
+     mixed idinf  - Dinge, welche die Faehigkeiten des Erkennens beeinflussen
+		    (siehe "man MaterialList")
+
+BESCHREIBUNG
+------------
+::
+
+     Man uebergibt ConvMaterialList() eine Liste von Materialien, die die
+     Funktion unter Verwendung von MaterialName() in ihre Bestandteile
+     aufsplittet und mit "und" und "," verknuepft zurueckgibt.
+
+RUECKGABEWERT
+-------------
+::
+
+     string - Materialien, durch Komma und "und" getrennt oder
+              "unbekanntes Material"
+
+BEMERKUNGEN
+-----------
+::
+
+     Wird von /std/thing/description::MaterialList() gerufen.
+     Bitte an Objekten auch MaterialList() verwenden.
+     Ruft direkt MaterialName() auf.
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Methoden:    QueryMaterial(), QueryMaterialGroup(), MaterialList(),
+     Listen:	  AllMaterials(), AllGroups(), Dump()
+		  materialliste, materialgruppen
+     Master:	  AddMaterial(), MaterialGroup(),
+		  GroupName(), MaterialName(),
+		  GetGroupMembers(), GetMatMembership()
+     Sonstiges:	  P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/CreateRingBuffer.rst b/doc/sphinx/lfun/CreateRingBuffer.rst
new file mode 100644
index 0000000..e59fe62
--- /dev/null
+++ b/doc/sphinx/lfun/CreateRingBuffer.rst
@@ -0,0 +1,70 @@
+CreateRingBuffer()
+==================
+
+FUNKTION
+--------
+::
+
+    protected struct std_ringbuffer CreateRingBuffer(int size, int newmode);
+
+DEFINIERT IN
+------------
+::
+
+    /std/util/ringbuffer.c
+    /sys/util/ringbuffer.h
+
+ARGUMENTE
+---------
+::
+
+    size    - Groesse des neuen Ringpuffers (int)
+    newmode - Ausgabemodus beim Abrufen des Puffers (int):
+              MODE_FIFO: First-in-First-Out
+              MODE_LIFO: Last-in-First-Out
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion erstellt einen neuen, leeren Ringpuffer der Groesse <size>
+    und liefert ihn zurueck. Die Daten des Puffers werden spaeter gemaess
+    <newmode> so gespeichert, dass bei der Ausgabe des Puffers mittels
+    RingBufferGet() die entweder die neuesten Daten zuerst (MODE_LIFO) oder
+    die aeltesten Daten zuerst (MODE_FIFO) geliefert werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+    Der neue Ringpuffer. Dieser wird in einer Struct std_ringbuffer
+    gespeichert. Er ist in einer Variable 'mixed' oder in einer mittels
+    'struct std_ringbuffer' angelegten Variable speicherbar.
+
+BEMERKUNGEN
+-----------
+::
+
+    Der gelieferte Ringpuffer sollte nicht per Hand verarbeitet oder
+    genaendert werden, sondern nur ueber die Verwaltungsfunktionen aus
+    /std/util/ringbuffer.c.
+
+BEISPIELE
+---------
+::
+
+    // Variable anlegen:
+    struct std_ringbuffer buffer;
+    // _oder_: mixed buffer;
+    // neuen Puffer mit max. 50 Elementen anlegen, der bei der Abfrage die
+    // aeltesten Daten zuerst zurueckliefert:
+    buffer = CreateRingBuffer(50, MODE_FIFO);
+
+SIEHE AUCH
+----------
+::
+
+    RingBufferPut(), RingBufferGet(), ResizeRingBuffer()
+
+23.05.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/CustomizeObject.rst b/doc/sphinx/lfun/CustomizeObject.rst
new file mode 100644
index 0000000..f6e0665
--- /dev/null
+++ b/doc/sphinx/lfun/CustomizeObject.rst
@@ -0,0 +1,84 @@
+CustomizeObject()
+=================
+
+FUNKTION
+--------
+::
+
+   string CustomizeObject();
+
+DEFINIERT IN
+------------
+::
+
+   /std/virtual/v_compiler.c
+
+ARGUMENTE
+---------
+::
+
+   keine
+
+RUeCKGABEWERT
+-------------
+::
+
+   Den Objektnamen, den das zuletzt erzeugte Objekt (welches gerade die
+   Funktion aufruft) spaeter vom Driver bekommen wird.
+
+BESCHREIBUNG
+------------
+::
+
+   Diese Funktion ist aus dem Grunde da, da zum Zeitpunkt des Clonens des
+   VC-Objektes (P_STD_OBJECT) dieses Objekt ja noch nicht weiss Wer
+   oder Was es spaeter mal sein wird.
+   Deshalb kann dieses VC-Objekt im create() (und nur da!) die Funktion
+   CustomizeObject() in dem virtual_compiler aufrufen, welches das Objekt
+   geclont hat und bekommt von diesem den Objektnamen zureck, welches es
+   spaeter mal bekommen wird.
+   Da das VC-Objekt vom VC geclont wurde, ist previous_object() im create()
+   des VC-Objektes der VC, in dem man CustomizeObject() ruft.
+
+BEMERKUNGEN
+-----------
+::
+
+   Das CustomizeObject() im Standard-VC gibt nur den zukuenftigen Objektnamen
+   zurueck und macht sonst nix.
+
+BEISPIELE
+---------
+::
+
+   create() eines VC-Objektes:
+
+   
+
+   protected void create() {
+     ...
+
+     
+
+     // wer bin ich denn eigentlich?
+     string myname = previous_object()->CustomizeObject();
+     switch(myname) {
+       // Kram konfigurier, ja nach myname... 
+     }
+
+     
+
+     ...
+   }
+
+SIEHE AUCH
+----------
+::
+
+     virtual_compiler
+     CustomizeObject(), Validate(), NoParaObjects(), 
+     P_COMPILER_PATH, P_PARA
+     /std/virtual/v_compiler.c
+
+21.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/Damage.rst b/doc/sphinx/lfun/Damage.rst
new file mode 100644
index 0000000..345a888
--- /dev/null
+++ b/doc/sphinx/lfun/Damage.rst
@@ -0,0 +1,57 @@
+Damage()
+========
+
+FUNKTION
+--------
+::
+
+     int Damage(int dam);
+
+DEFINIERT IN
+------------
+::
+
+     /std/armour/combat.c und
+     /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+     dam  Der Wert, mit dem die Waffe/Ruestung beschaedig werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     P_WC bzw. P_AC wird um dam reduziert und P_DAMAGED wird um
+     dam erhoeht.
+     Bei dam>0 wird das Objekt beschaedigt, bei dam<0 repariert.
+     Dabei werden sowohl die Obergrenzen (s. /sys/combat.h) wie auch
+     die Untergrenzen (Waffen:30, Ruestungen: 0) fuer P_WC und P_AC
+     beachtet. Es kann auch nicht mehr repariert werden, als vorher
+     beschaedigt wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Der Wert der Beschaedigung, die tatsaechlich vorgenommen wurde.
+
+BEMERKUNGEN
+-----------
+::
+
+     Ist das Objekt in Benutzung, setzt die Funktion Damage automatisch
+     die Properties P_TOTAL_WC bzw. P_TOTAL_AC in dem benutzenden Spieler
+     auf die richtigen Werte.
+
+SIEHE AUCH
+----------
+::
+
+     /std/armour/combat.c, /std/weapon/combat.c
+
+
+Last modified: Thu May 22 10:13:23 1997 by Paracelsus
+
diff --git a/doc/sphinx/lfun/DeAssocMember.rst b/doc/sphinx/lfun/DeAssocMember.rst
new file mode 100644
index 0000000..b43ed68
--- /dev/null
+++ b/doc/sphinx/lfun/DeAssocMember.rst
@@ -0,0 +1,72 @@
+DeAssocMember()
+===============
+
+FUNKTION
+--------
+::
+
+        int DeAssocMember(object npc)
+
+DEFINIERT IN
+------------
+::
+
+        /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+        Der NPC, der nicht mehr zugeordnet sein soll.
+
+BESCHREIBUNG
+------------
+::
+
+        Hebt die Zuordnung eines NPCs zu einem Spieler auf.
+
+RUECKGABEWERT
+-------------
+::
+
+        1, falls Aufhebung erfolgreich, sonst 0.
+
+BEISPIEL
+--------
+::
+
+        void fun(object pl)
+        {
+         if ( pl && pl->DeAssocMember(this_object()) )
+          tell_object(pl,break_string(
+              "Ich kaempfe nun nicht mehr auf Deiner Seite!\n",78,
+              "Ein Feuerteufel teilt Dir mit:");
+         ...
+        }
+
+BEMERKUNGEN
+-----------
+::
+
+        Kann nur von Gilden, Spellbooks, vom Objekt selber und vom
+        zugeordneten NPC aufgerufen werden.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      AssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/DeclAdj.rst b/doc/sphinx/lfun/DeclAdj.rst
new file mode 100644
index 0000000..5c250ae
--- /dev/null
+++ b/doc/sphinx/lfun/DeclAdj.rst
@@ -0,0 +1,69 @@
+DeclAdj()
+=========
+
+FUNKTION
+--------
+::
+
+     varargs string DeclAdj( string adj, int casus, int demon);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+     adj
+          Das zu deklinierende Adjektiv.
+
+     casus
+          Der Fall, in den es dekliniert werden soll.
+
+     demon
+          Bezieht sich das Adjektiv auf einen bestimmten oder einen
+          unbestimmten Gegenstand?
+
+BESCHREIBUNG
+------------
+::
+
+     Dekliniert das uebergebene Adjektiv in den angegebenen Fall. Ist demon
+     ungleich Null, so wird das Adjektiv so behandelt, als wuerde es sich
+     auf einen bestimmten Gegenstand beziehen, ansonsten bezieht es sich auf
+     einen unbestimmten Gegenstand.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Das deklinierte Adjektiv. Es wird zusaetzlich noch ein Leerzeichen
+     hinten angefuegt!
+
+BEISPIELE
+---------
+::
+
+     Zunaechst ein bestimmtes Adjektiv:
+
+     printf("Der %sBall.\n", ball->DeclAdj("gruen", WER, 1);
+
+     Nun ein unbestimmtes Adjektiv:
+
+     printf("Ein %sBall.\n", ball->DeclAdj("gruen", WER, 0);
+
+     Da DeclAdj() "gruene " bzw. "gruener " zurueckgibt, darf zwischen dem
+     "%s" und dem "Ball" kein Leerzeichen stehen!
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/language.c
+
+
+Last modified: Wed May 8 10:18:05 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/Defend.rst b/doc/sphinx/lfun/Defend.rst
new file mode 100644
index 0000000..71f76d6
--- /dev/null
+++ b/doc/sphinx/lfun/Defend.rst
@@ -0,0 +1,174 @@
+Defend()
+========
+
+FUNKTION
+--------
+::
+
+     public int Defend(int dam, string|string* dam_type, int|mapping spell, 
+                        object enemy)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/combat
+
+ARGUMENTE
+---------
+::
+
+     int dam                  initiale Staerke des Angriffs (10 dam ~ 1 HP)
+     string* dam_type         Art(en) des Schadens, der angerichtet werden
+                              soll
+                              Muss ein Array von Schadenstypen sein,
+                              alte Objekte uebergeben hier manchmal strings.
+     int/mapping spell        - 0 fuer normale Angriffe (keine Zauber)
+                              - 1 fuer Zauber (Standardruestungen ignorieren)
+                              - mapping fuer mehr Informationen
+                              Heute bitte nach Moeglichkeit ein Mapping
+                              uebergeben.
+     object enemy             der Feind/Schadenverursacher
+
+BESCHREIBUNG
+------------
+::
+
+     1. Generell
+     Wenn das Lebewesen angegriffen wird, wird geprueft, wie stark die
+     Ruestungen und koerpereigenen Abwehrkraefte sind und die Staerke des
+     Schadens dementsprechend vermindert.
+     Ggf. wird der Schaden zugefuegt und der Feind in  die Liste der Feinde
+     aufgenommen. Der Schaden betraegt:
+      (dam-Summe(Ruestungsstaerken)-random(P_BODY+A_DEX))*CheckResistance/10
+     aber nicht unter 0.
+
+     2. Der Parameter 'spell'
+     Ist 'spell' 0, dann gilt der Angriff als normale physische Attacke
+     Uebergibt man als 'spell'-Parameter ein Mapping, so gibt es dafuer
+     diverse Flags, die das Ergebnis manipulieren (in new_skills.h
+     enthalten). Nichtangabe eines Flags gilt als 0.
+
+     - SP_PHYSICAL_ATTACK ---------- 0/1
+                1, wenn Ruestungen wirken sollen, 0 sonst
+                -> entspricht !spell, wenn dieses Int ist
+     - SP_NO_ENEMY ----------------- 0/1
+                1, falls der Angriff nicht toedlich ist, es also keinen echten
+                Gegner gibt
+                -> es wird dann reduce_hit_points() gerufen statt do_damage()
+     - SP_NO_ACTIVE_DEFENSE -------- 0/1
+                1, falls aktive Abwehren (wie zurueckschlagende Amulette,
+                Karateabwehren oder Ausweichmanoever) unterbleiben sollen
+                -> zB bei Kratzen durch Dornen oder Fall aus grosser Hoehe
+                   ist aktive Abwehr oder Ausweichen unlogisch
+     - SP_RECURSIVE ---------------- 0/1
+                1, falls der Spell aus einem Defend gerufen wurde (oder einer
+                DefendFunc)
+                -> verhindert Rekursionsprobleme
+     - SP_NAME --------------------- string
+                Name des Spells
+     - SP_REDUCE_ARMOUR ------------ Mapping: keys AT_X/P_BODY, values int>=0
+                Die Schutzwirkung durch P_AC/Magie einer Ruestung wird
+                typabhaengig reduziert. Aufbau eines Mappings im Beispiel:
+                ([AT_BOOTS: 0,  // Stiefel schuetzen gar nicht
+                  P_BODY:  50,  // Koerper zu 50%
+                  AT_BELT: 600  // Guertel zu 600%
+                ])
+                -> alle 'fehlenden' Eintraege wirken normal
+     - SP_SHOW_DAMAGE -------------- 0/1 oder Array von Arrays
+                0, fuer keine Treffermeldung, 1 sonst
+                In einem Array koennen Ersatz-Treffermeldungen definiert
+                werden. Format ist:
+                ({
+                 ({ int lphit1, string mess_me,
+                                string mess_en,
+                                string mess_room }),
+                 ({ lphit2, mess_me, mess_en, mess_room }),
+                 ...
+                 ({ lphitn, mess_me, mess_en, mess_room }),
+                })
+                wobei lphit1<lphit2<...<lphitn sein muss, d.h. das Array-
+                Array aufsteigend sortiert.
+
+                Ist ein Treffer x LP hart, werden die Meldungen des lphit-
+                Arrays ausgegeben, dessen Wert am naehesten unter dem Schaden
+                liegt.
+
+                In den Meldungen mess_me (an den Getroffenen), mess_en (an
+                den Feind), mess_room (an die restlichen Umstehenden) koennen
+                Ersatzstrings wie folgt verwendet werden:
+                @WER1/@WESSEN1/@WEM1/@WEN1 - name(casus) des Getroffenen (TO)
+                @WER2/@WESSEN2/@WEM2/@WEN2 - name(casus) des Feindes (enemy)
+     - EINFO_DEFEND ------------ Mapping
+                Dieses Mapping liefert erweiterte Informationen zu dem
+                bisherigen Ablauf des aktiven Attacks.
+                Die verfuegbaren Informationen sind in der Manpage zu
+                DefendInfo festgehalten.
+
+     3. Reihenfolgen in Defend
+     - das Living wird angegriffen, wenn
+       - P_NO_ATTACK != 0
+       - 'enemy' existiert und kein netztoter Spieler ist
+     - P_DEFENDERS werden durchgegangen (und eventuell benachrichtigt)
+     - P_TMP_ATTACK_HOOK wird abgefragt
+     - die Ruestungen werden vom Schaden gegebenenfalls abgezogen
+     - magischer Ausweichskill beruecksichtigt
+     - sensitive Objekte werden ggf. benachrichtigt
+     - InternalModifyDefend wird gerufen
+     - Koerperabwehr abgezogen
+     - der Schaden an do_damage()/reduce_hit_points() uebergeben
+     - Flucht ueberpruefen mit CheckWimpyAndFlee()
+
+BEMERKUNGEN
+-----------
+::
+
+     Ruestungen wirken konventionell nur, wenn mindestens ein Schadensanteil
+     mechanisch ist und es kein Spell oder ein Spell mit SP_PHYSICAL_ATTACK
+     auf 1 ist.
+
+     Defend() beruecksichtigt magische Verteidigungen, die der Spieler bei
+     sich hat, sollte also aus Fairness gegenueber den Objekten anderer
+     Magier immer dem direkten reduce_hit_points() oder do_damage()
+     vorgezogen werden. Mittels der Flags in 'spell' kann man sehr viel
+     aendern.
+
+RUECKGABEWERT
+-------------
+::
+
+     Hoehe des tatsaechlichen Schadens. Dies kann mehr sein als die
+     Lebenspunkte des Lebewesens.
+
+BEISPIELE (SIEHE AUCH Defend_bsp):
+     // ein simpler Angriff:
+     enem->Defend(100, ({DT_BLUDGEON}), 0, this_object());
+
+     // ein magischer Angriff (ohne Treffermeldung):
+     enem->Defend(100, ({DT_BLUDGEON, DT_FIRE}), 1, this_object());
+
+     // ein magischer Angriff mit Treffermeldung:
+     enem->Defend(100, ({DT_BLUDGEON, DT_FIRE}), ([SP_SHOW_DAMAGE:1]),
+                         this_object());
+
+SIEHE AUCH
+----------
+::
+
+     Angriff:   Attack(L), P_NO_ATTACK, InsertEnemy(L)
+     Schaden:   P_ENABLE_IN_ATTACK_OUT, P_LAST_MOVE,
+                do_damage(L), reduce_hit_points(L)
+     Schutz:    P_DEFENDERS, InformDefend(L), DefendOther(L)
+                P_ARMOURS, P_AC, P_DEFEND_FUNC, QueryDefend(L)
+                P_BODY, A_DEX
+     Daten:     P_LAST_COMBAT_TIME
+                P_LAST_DAMTYPES, P_LAST_DAMTIME, P_LAST_DAMAGE
+                P_DAMAGE_MSG
+     Resistenz: P_RESISTANCE_STRENGTHS, CheckResistance(L)
+     Sonstiges: CheckSensitiveAttack(L)
+                InternalModifyDefend(L)
+                UseSkill(L),
+                DefendInfo
+
+15.09.2010, Zesstra
+
diff --git a/doc/sphinx/lfun/DefendFunc.rst b/doc/sphinx/lfun/DefendFunc.rst
new file mode 100644
index 0000000..790505a
--- /dev/null
+++ b/doc/sphinx/lfun/DefendFunc.rst
@@ -0,0 +1,108 @@
+DefendFunc()
+============
+
+DefendFunc(L)
+-------------
+::
+
+FUNKTION
+--------
+::
+
+     int DefendFunc(string|string *dtyp, int|mappingspell, object enemy);
+
+DEFINIERT IN
+------------
+::
+
+     eigenen Objekten; fuer /std/armour/combat.c
+
+ARGUMENTE
+---------
+::
+
+     dtyp
+          Schadenstypen der Angriffsart.
+          Sollte heute ein string* sein.
+     spell
+          0 bei veralteten konventionellen Angriffen im Regelfall jedoch
+          ein Mapping mit weiteren Infos.
+          Bei einem konventionellen Angriff ist spell[SP_PHYSICAL_ATTACK] gleich
+          1.
+     enemy
+          Der angreifende Gegner
+
+BESCHREIBUNG
+------------
+::
+
+     Anhand der uebergebenen Parameter kann hier ein Ruestungsbonus (oder
+     auch ein Ruestungsmalus) errechnet werden, der zu dem normalen
+     Ruestungswert (abhaengig von der Angriffsart) hinzuaddiert wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Der Ruestungsbonus, der zur Ruestungsklasse addiert werden soll.
+
+BEMERKUNGEN
+-----------
+::
+
+     Auch wenn man eine DefendFunc() benutzt, darf der Rueckgabewert
+     zusammen mit der P_AC insgesamt nur in sehr seltenen, wohldurch-
+     dachten Ausnahmefaellen die maximal zulaessige P_AC fuer diesen
+     Ruestungstyp ueberschreiten. In solchen Ausnahmefaellen duerfen
+     die DefendFuncs nicht konstant wirken.
+
+     Bei aktivem Zurueckschlagen IMMER auf Flags wie SP_RECURSIVE und
+     SP_NO_ACTIVE_DEFENSE pruefen und ggf. abbrechen.
+
+BEISPIELE
+---------
+::
+
+     Eine Ruestung, die bei Angriffen mit Feuer ihre volle Staerke entfaltet
+     und bei Angriffen durch Geister geschwaecht wird:
+
+     void create()
+     {
+       ::create();
+
+       SetProp(P_ARMOUR_TYPE, AT_ARMOUR);
+       SetProp(P_AC, 20);
+       ...
+       // Die DefendFunc() ist in der Ruestung selbst definiert
+       SetProp(P_DEFEND_FUNC, this_object());
+     }
+
+     int DefendFunc(string *dtyp, mixed spell, object enemy)
+     {
+       int prot;
+
+       // Zuerst fragen wir den Angriff durch Feuer ab:
+       if (member(dtyp, DT_FIRE) >= 0)  // Feuer gehoert zu den Schadenstypen
+         prot = 5 + random(10); // Das ergibt maximal 14. Zusammen mit P_AC
+                                // kommt man also maximal auf 14+20 = 34,
+                                // liegt also unter der fuer AT_ARMOUR
+                                // geltenden Obergrenze
+
+       // Und jetzt der Geistertest
+       if (enemy->QueryProp(P_RACE) == "Geist" ||
+           enemy->is_class_member(CL_GHOST))
+         prot -= random(10);
+
+       // Der Rueckgabewert wird auf den aus P_AC errechneten Wert draufgeschlagen
+       return prot;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     P_DEFEND_FUNC, QueryDefend(), /std/armour/combat.c
+
+
+Last modified: 18.Jul 2006 Muadib
+
diff --git a/doc/sphinx/lfun/DefendInfo.rst b/doc/sphinx/lfun/DefendInfo.rst
new file mode 100644
index 0000000..5067cac
--- /dev/null
+++ b/doc/sphinx/lfun/DefendInfo.rst
@@ -0,0 +1,218 @@
+DefendInfo()
+============
+
+FUNKTION
+--------
+::
+
+DEFINIERT IN
+------------
+::
+
+     /sys/combat.h
+
+ARGUMENTE
+---------
+::
+
+BESCHREIBUNG
+------------
+::
+
+     Die DefendInformationen werden im Runde eines Attack/Defend Vorgangs 
+     in Attack initial angelegt und dem Defend ueber den Parameter spell
+     uebergeben. Ist dieser Parameter ein Mapping, so sind die 
+     DefendInformationen ueber den Key EINFO_DEFEND zu erhalten.
+     Die Informationen liegen in Form eines Mappings vor.
+     Vor Zugriff sollte immer auf die Existenz dieses Keys in dem Mapping
+     geprueft werden, da nicht alle Informationen immer existieren.
+     Die Keys sind in combat.h definiert und sind folgende:
+
+     
+
+    ORIGINAL_AINFO - Mapping 
+        Hier ist eine Kopie des originalen ainfo-mappings des Attacks 
+        vorhanden mit folgenden Eintraegen:
+        Immer vorhandene Eintraege:
+          SI_ENEMY              der angegriffene Gegner
+
+        
+
+        Angriff mit gezueckter Waffe:
+          P_WEAPON              das Waffenobjekt selbst
+          P_WEAPON_TYPE         P_WEAPON_TYPE der Waffe
+          P_WC                  P_WC der Waffe
+          P_NR_HANDS            P_NR_HANDS der Waffe
+          SI_SKILLDAMAGE_TYPE   P_DAM_TYPE der Waffe
+          SI_SKILLDAMAGE        waffe->QueryDamage(enemy)
+             bei vorhandenem Zweihandskill SK_TWOHANDED wird nur der durch 
+             den Skill modifizierte Schadenswert uebernommen
+          SI_SKILLDAMAGE_MSG    "mit "+waffe->name(WEM,0)
+          SI_SKILLDAMAGE_MSG2   "mit "+waffe->name(WEM,1)
+          SI_SPELL              0
+
+        Angriff mit blossen Haenden:
+          P_WEAPON_TYPE         WT_HANDS
+          P_WC                  P_HANDS[1]
+          SI_SKILLDAMAGE        Schadenswert, aus P_HANDS[1] und A_STR 
+                                berechnet
+          SI_SKILLDAMAGE_TYPE   P_HANDS[2]
+          SI_SKILLDAMAGE_MSG
+          SI_SKILLDAMAGE_MSG2   beides P_HANDS[0]
+          SI_SPELL              0
+
+          
+
+        Angriff mit einem Spell (SK_MAGIC_ATTACK):
+          SI_SKILLDAMAGE        Schadenswert des Spells
+          SI_SKILLDAMAGE_TYPE   Schadenstypen des Spells
+          SI_SKILLDAMAGE_MSG    Schadensmeldung des Spells, wenn vorhanden,
+                                sonst "mit magischen Faehigkeiten"
+          SI_SKILLDAMAGE_MSG2   entsprechende Meldung des Spells, wenn 
+                                gesetzt, ansonsten identisch mit 
+                                SI_SKILLDAMAGE_MSG
+          P_WEAPON_TYPE         P_WEAPON_TYPE des Spells, wenn vorhanden,
+                                sonst WT_MAGIC
+          SI_SPELL              SI_SPELL des Spells
+
+          
+
+        Hinweise:
+        - Alle Eintraege in diesem Mapping koennen bereits durch
+          InternalModifyAttack() veraendert worden sein.
+        - Die Daten werden mittels deep_copy(ainfo) eingetragen.
+        - Daten in den Eintraegen SI_SKILLDAMAGE* und SI_SPELL koennen bei
+          physikalischen Angriffen durch die Skills FIGHT(P_WEAPON_TYPE) oder
+          SK_FIGHT oder durch einen P_TMP_ATTACK_MOD bzw. Hook vom Typ 
+          H_HOOK_ATTACK_MOD modifiziert worden sein.
+
+        
+
+    ORIGINAL_DAM - int
+        Der Originalschaden aus dem Attack
+
+    ORIGINAL_DAM_TYPE - string/string* 
+        Der Originaldamagetyp aus dem Attack
+
+    CURRENT_DAM - int
+        Der momentane Schaden, nach schon erfolgten Modifikationen
+
+  
+
+    CURRENT_DAM_TYPE - string/string*
+        Der momentane Damagetyp, nach schon erfolgten Modifikationen
+
+  
+
+    ENEMY_INSERTED - int
+        0 oder 1 je nachdem ob der Angreifer schon in der enemy-list
+        vorhanden war oder nicht
+
+  
+
+    RFR_REDUCE - int 
+        0 oder reduzierter Schaden durch RFR Modifikation
+
+  
+
+    PRESENT_DEFENDERS - Array 
+        Liste der durch InformDefend informierten Defender als Objekt.
+        Ein Defender wird immer NACH InformDefend
+        dazugefuegt
+
+  
+
+    DEFENDING_DEFENDER - Array ({})
+        Hat ein durch InformDefend ein Defender verteidigt, so wird
+        fuer diesen Defender ein Eintrag in diesem Array vorgenommen,
+        welcher folgende Struktur besitzt.
+                ({
+                        DEF_DEFENDER - Object
+                          Der Verteidiger, welcher VOR
+                          DefendOther eingefuegt wird
+                        DEF_DAM - int
+                          Der veraenderte Schaden, welcher NACH 
+                          DefendOther eingefuegt wird
+                        DEF_DAMTYPE string/string*  
+                          Die veraenderte Schadensart, welche 
+                          NACH DefendOther eingefuegt wird
+                        DEF_SPELL - Mapping   
+                          Das Mapping des veraenderten Spells, welches
+                          als Kopie NACH DefendOther eingefuegt wird
+                })
+
+  
+
+    DEFEND_HOOK - Int/Array 
+        DI_NOHOOK, wenn kein Hook da war, DI_HOOKINTERRUPT, wenn der
+        Hook das Defend unterbricht, DI_HOOK, wenn ein Hook vorhanden 
+        ist, dieser das Defend aber unveraendert laesst.
+        Veraendert ein Hook das Defend, so ist hier ein Array zu finden
+        mit den veraenderten Parametern in der Struktur:
+                ({
+                        HOOK_DAM - int
+                           Der veraenderte Schaden
+                        HOOK_DAMTYPE - string/string*   
+                           Die veraenderte Schadensart
+                        HOOK_SPELL - Mapping 
+                           Das Mapping des veraenderten Spells als Kopie
+                })
+
+  
+
+    DEFEND_ARMOURS - Mapping (2 Werte pro Key)
+        Liste der beruecksichtigten Ruestungen. Fuer jede Ruestung
+        wird ein Eintrag vorgenommen, mit dem Objekt der jeweiligen
+        Ruestung als Key. Hierbei werden die Ruestungen erst eingetragen,
+        wenn ihr jeweiliges QueryDefend() aufgerufen wird, d.h. es sind nicht
+        von Anfang an alle getragenen Ruestung drin. Jeder Eintrag im Mapping
+        besitzt die folgenden 2 Werte:
+                DEF_ARMOUR_DAM - int 
+                    Der Schaden NACH QueryDefend (vorher 0)
+                DEF_ARMOUR_PROT - int
+                    Verteidigungswert der Ruestung VOR DefendFunc
+        Bsp: Ich will wissen, wie gut 'ruestung' schuetzte:
+             spell[EINFO_DEFEND][DEFEND_ARMOURS][ruestung,DEF_ARMOUR_PROT]
+
+    DEFEND_GUILD - Array 
+        Eine Liste mit der Modifikation der Gilde mit der Struktur
+                ({
+                        GUILD_DAM - int
+                          Der veraenderte Schaden
+                        GUILD_DAMTYPE - string/string*
+                          Die veraenderte Schadensart
+                })
+
+  
+
+    DEFEND_RESI - int
+        Schaden nach CheckResistance
+
+  
+
+    DEFEND_BODY - int
+        Schaden nach Beruecksichtigung des Bodies (nur
+        physikalisch)
+
+  
+
+    DEFEND_LOSTLP - int
+        Tatsaechlich abgezogene LP
+
+  
+
+    DEFEND_CUR_ARMOUR_PROT - int
+        Schutz der Ruestung vor Call der
+        DefendFunc. Ist nur in der DefendFunc definiert. Kann auch aus
+        DEFEND_ARMOURS entnommen werden
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     Attack, Defend
+
+18.Jul 2006 Muadib
+
diff --git a/doc/sphinx/lfun/DefendOther.rst b/doc/sphinx/lfun/DefendOther.rst
new file mode 100644
index 0000000..855d2b8
--- /dev/null
+++ b/doc/sphinx/lfun/DefendOther.rst
@@ -0,0 +1,108 @@
+DefendOther()
+=============
+
+FUNKTION
+--------
+::
+
+	mixed DefendOther(int dam,mixed dam_type,mixed spell,object enemy);
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+	dam
+	  Der Schaden, der voraussichtlich beim zu verteidigenden Lebewesen
+	  verursacht werden soll.
+	dam_type
+	  Der Schadenstyp (oder die Schadenstypen), der beim zu
+	  verteidigenden Lebewesen verursacht werden sollen.
+	spell
+	  Wenn das zu verteidigende Lebewesen mit Spells angegriffen wurde,
+	  so koennte man hier mehr Infos entnehmen.
+	enemy
+	  Der Feind, der ein zu verteidigendes Lebewesen angegriffen hat.
+
+RUeCKGABEWERT
+-------------
+::
+
+	Array mit den Eintraegen der gegebenenfalls veraenderten
+	uebergebenen Parameter: 
+            (1) dam      [Typ int], 
+            (2) dam_type [Typ string*], 
+            (3) spell    [Typ mapping].
+
+BESCHREIBUNG
+------------
+::
+
+	Es ist moeglich, dass Objekte Angriffe auf Lebewesen abwehren oder
+	umwandeln, sofern diese Objekte bei dem angegriffenen Lebewesen
+	mittels AddDefender() angemeldet wurden und sich der selben Umgebung
+	befinden.
+	Zumeist wird es sich bei den Objekten natuerlich ebenfalls um
+	andere Lebewesen handeln, die das Lebewesen, bei dem sie angemeldet
+	sind, verteidigen sollen.
+	Bei einem Angriff auf das Lebewesen koennen alle Objekte per Aufruf
+	von DefendOther() in einen Angriff eingreifen, wobei die
+	Schadensstaerke, der Schadenstyp (die Schadenstypen),
+	Zusatzinformationen fuer Angriffsspells und der Angreifer als
+	Parameter uebergeben werden.
+	Desweiteren ist zu beachten, dass bei als physikalisch markierten
+	Angriffen in einem Team nur Verteidiger aus der ersten Reihe
+	beruecksichtigt werden und dass bei einem Angriff zufaellig aus
+	allen moeglichen Verteidigern ausgewaehlt wird.
+	Standardmaessig ist diese Funktion in Lebewesen bereits definiert,
+	wobei der Skill SK_DEFEND_OTHER, sofern vorhanden, aufgerufen wird.
+
+BEISPIEL
+--------
+::
+
+	Sehr beliebt sind in Gilden NPCs, die den Beschwoerer begleiten und
+	verteidigen, z.B. beschworene Daemonen:
+	  inherit "std/npc";
+	  include <properties.h>
+	  object owner;
+	  void create()
+	  { ::create();
+	    SetProp(P_NAME,"Daemon");
+	    ...
+	  }
+	// nach Clonen des Daemons folgende Funktion mit Beschwoerer als
+	// Parameter aufrufen
+	  Identify(object caster)
+	  { if(!objectp(caster))
+	      call_out(#'remove,0);
+	    owner=caster;
+	    owner->AddDefender(this_object());
+	  }
+	// der Daemon wehrt jeden Angriff mit Feuer voll ab, man muss zuerst
+	// den Verteidiger umbringen, um den Beschwoerer toeten zu koennen
+	  mixed DefendOther(int dam,mixed dam_type,mixed spell,object enemy)
+	  { if(sizeof(dam_type)&&member_array(DT_FIRE,dam_type)!=-1)
+	      dam=0;
+	    return({dam,dam_type,spell});
+	  }
+	Soll der Daemon sich auch in ein Team einordnen, in welchem sich der
+	Beschwoerer eventuell befindet, so ist zusaetzlich AssocMember() in
+	diesem Beschwoerer aufzurufen, wobei der Daemon als Parameter
+	uebergeben wird.
+
+SIEHE AUCH
+----------
+::
+
+	AddDefender(), RemoveDefender(), InformDefend(), Kill(), IsEnemy(),
+	P_DEFENDERS, /std/living/combat.c, /sys/new_skills.h
+
+
+Last modified: Fri Feb 25 14:45:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/lfun/Defend_bsp.rst b/doc/sphinx/lfun/Defend_bsp.rst
new file mode 100644
index 0000000..29e710a
--- /dev/null
+++ b/doc/sphinx/lfun/Defend_bsp.rst
@@ -0,0 +1,155 @@
+Defend_bsp()
+============
+
+Defend() - BEISPIELE
+--------------------
+::
+
+FUNKTION
+--------
+::
+
+     varargs int Defend(int dam, mixed dam_type, mixed spell, object enemy)
+
+BEMERKUNGEN
+-----------
+::
+
+     Die hier aufgefuehrten Komplexbeispiele sind zum Verstaendnis gedacht.
+
+BEISPIELE
+---------
+::
+
+  1) Ein ordinaerer Biss ins Bein.
+     this_player()->Defend(random(500),
+                           ({DT_PIERCE, DT_RIP}),
+                           0,
+                           this_object());
+
+  2) Ein Biss ins Bein, mit der Hose als 200%ige Ruestung und Rest mit 100%.
+     this_player()->Defend(random(500),
+                           ({DT_PIERCE, DT_RIP}),
+                           ([SP_PHYSICAL_ATTACK: 1,
+                             SP_REDUCE_ARMOUR:   ([AT_TROUSERS: 200])
+                           ]),
+                           this_object());
+
+  3) Der Biss, wenn ein Tier in die Hose gekrochen ist und dieser ohne
+     Treffermeldung und physischen Ruestungsschutz durchgeht.
+     this_player()->Defend(random(500),
+                           ({DT_PIERCE, DT_RIP}),
+                           ([SP_PHYSICAL_ATTACK: 0]),
+                           this_object());
+
+  4) Spell-Parameter
+     // Beispiel fuer einen Spell, der nur vom Helm normal und von einem
+     // Amulett mit 115% aufgehalten wird, alle anderen (angebenenen)
+     // Ruestungen haben 0% Schutzwirkung.
+     // Mit Ausgabe eigener Meldungen: beginnend mit -1, da der verursachte
+     // Schadenswert minimal 0 wird (fuers Ersetzen: Feind: @WEx2,
+     // Spieler: WEx1); maximal wird er (Empfindlichkeiten jetzt mal aussen
+     // vor) 49 (499/10 = 49), nicht 499!!!
+     this_player()->Defend(
+       random(500),
+       ({DT_PIERCE, DT_AIR}),
+       ([SP_PHYSICAL_ATTACK: 1, // wegen DT_PIERCE
+         SP_REDUCE_ARMOUR:   ([AT_ARMOUR:   0,
+                               AT_HELMET: 100,
+                               AT_RING:     0,
+                               AT_GLOVE:    0,
+                               AT_CLOAK:    0,
+                               AT_BOOT:     0,
+                               AT_TROUSERS: 0,
+                               AT_SHIELD:   0,
+                               AT_AMULET: 115,
+                               AT_MISC:     0,
+                               AT_BELT:     0,
+                               AT_QUIVER:   0])
+         SP_SHOW_DAMAGE:
+               ({({-1,"@WER2 schrammt Dich mit einem durchbohrenden Blick.",
+                      "Du schrammst @WEN1 mit einem durchbohrenden Blick.",
+                      "@WER2 schrammt @WEN1 mit einem durchbohrenden Blick."
+                 }),
+                 ({5,"Der durchbohrende Blick von @WEM2 trifft Dich.",
+                     "Dein durchbohrender Blick trifft @WEN1.",
+                     "Der durchbohrende Blick von @WEM2 trifft @WEN1."
+                 }),
+                 ({20,"@WESSEN2 stechender Blick durchbohrt Dich.",
+                      "Dein stechender Blick durchbohrt @WEN1.",
+                      "@WESSEN2 stechender Blick durchbohrt @WEN1."
+               })})
+       ]),
+       this_object());
+
+     // Etwas geschickter geht das Ganze, wenn wir einfach aus der Mudlib
+     // alle existierenden Ruestungen in ein Mapping packen und diese
+     // nullen (damit sind wir auch gegen neue Ruestungstypen sicher):
+     mapping amap = map_indices(VALID_ARMOUR_CLASS,#'!);
+     amap[AT_HELMET]=100;
+     amap[AT_AMULET]=115;
+
+     this_player()->Defend(random(500),
+                           ({DT_PIERCE, DT_AIR}),
+                           ([SP_PHYSICAL_ATTACK: 1,
+                             SP_REDUCE_ARMOUR: amap,
+                             SP_SHOW_DAMAGE: ({ ... (siehe oben)
+
+  5) Der Biss von weiter oben mit Meldung.
+     // Eine Meldung, die nur ausgegeben wird, wenn der Biss auch mindestens
+     // einen LP abzieht.
+     this_player()->Defend(random(500),
+                           ({DT_PIERCE, DT_RIP}),
+                           ([SP_PHYSICAL_ATTACK: 1,
+                             SP_REDUCE_ARMOUR:   ([AT_TROUSERS: 200]),
+                             SP_SHOW_DAMAGE: ({
+                               ({1,"@WER2 beisst Dich ins Bein!",
+                                   "Du beisst @WEN1 ins Bein!",
+                                   "@WER2 beisst @WEN1 ins Bein!"
+                                })           })
+                           ]),
+                           this_object());
+
+  6) DefendFunc() und Defend() in einem Objekt
+     6a)
+     // eine Luftangriffe reflektierende Ruestung:
+     int DefendFunc(string *dtyp, mixed spell, object enemy) {
+       if(member(dtyp, DT_AIR)>=0 && !spell[SP_RECURSIVE])
+         enemy->Defend(random(200),
+                       ({DT_AIR}),
+                       ([SP_RECURSIVE: 1,
+                         SP_SHOW_DAMAGE:
+                         ({"Ein Luftwirbel erfasst auch Dich.",
+                           "Deine Ruestung wirbelt @WEN1 herum.",
+                           "@WESSEN2 Ruestung wirbelt @WEN1 herum."
+                          })
+                       ]),
+                       QueryProp(P_WORN));
+
+       return 0; // -> In diesem Fall gibts keinen Ruestungsbonus!
+     }
+
+     6b)
+     // Eine NUR REINE Luftangriffe reflektierende Ruestung:
+     int DefendFunc(string *dtyp, mixed spell, object enemy) {
+       if(!sizeof(dtyp-({DT_AIR})) && !spell[SP_RECURSIVE])
+         ...
+
+SIEHE AUCH
+----------
+::
+
+     Angriff:   Attack(L), P_NO_ATTACK, InsertEnemy(L)
+     Schaden:   P_ENABLE_IN_ATTACK_OUT, P_LAST_MOVE, do_damage(L),
+                reduce_hit_points(L), reduce_spell_points(L)
+     Schutz:    P_DEFENDERS, InformDefend(L), DefendOther(L),
+                P_ARMOURS, P_AC, P_DEFEND_FUNC, QueryDefend(L),
+                P_BODY, A_DEX, Defend(L)
+     Daten:     P_LAST_COMBAT_TIME, P_LAST_XP, P_LAST_DAMAGE,
+                P_LAST_DAMTYPES, P_LAST_DAMTIME
+     Resistenz: P_RESISTANCE_STRENGTHS, CheckResistance(L)
+     Sonstiges: CheckSensitiveAttack(L), UseSkill(L),
+                InternalModifyDefend(L)
+
+25. Mai 2011 Gabylon
+
diff --git a/doc/sphinx/lfun/DeleteSpellFatigue.rst b/doc/sphinx/lfun/DeleteSpellFatigue.rst
new file mode 100644
index 0000000..6320ab6
--- /dev/null
+++ b/doc/sphinx/lfun/DeleteSpellFatigue.rst
@@ -0,0 +1,56 @@
+DeleteSpellFatigue()
+====================
+
+FUNKTION
+--------
+::
+
+    public void DeleteSpellFatigue(string key)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skills.c
+    /std/player/skills.c
+    /sys/living/skills.h
+
+ARGUMENTE
+---------
+::
+
+    string key  : Eindeutiger Name des Spruches, einer Gruppe von Spruechen
+                  oder 0 fuer die globale Spruchermuedung.
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion dient zum Loeschen von individuellen Spruchermuedungen
+    (Spellfatigue, Spruchsperren).
+
+    Ist <key> 0, wird die globale Spruchsperre geloescht (identisch zu der
+    Property P_NEXT_SPELL_TIME), anderenfalls die unter <key> gespeicherte
+    Spruchermuedung.
+    Loescht man einen Eintrag 0 ist das Ergebnis dieser Funktion identisch zum
+    Loeschen/Nullen von P_NEXT_SPELL_TIME.
+
+BEMERKUNGEN
+-----------
+::
+
+    Spruchsperren (insb. fremde) duerfen nicht ohne weiteres geloescht oder
+    geaendert werden. Dieses bedarf grundsaetzlich der Genehmigung durch die
+    Gildenbalance!
+
+SIEHE AUCH
+----------
+::
+
+    SetSpellFatigue(L), CheckSpellFatigue(L)
+    P_NEXT_SPELL_TIME
+    spruchermuedung
+
+
+27.03.2010, Zesstra
+
diff --git a/doc/sphinx/lfun/DeleteTimedAttrModifier.rst b/doc/sphinx/lfun/DeleteTimedAttrModifier.rst
new file mode 100644
index 0000000..d7e1ff6
--- /dev/null
+++ b/doc/sphinx/lfun/DeleteTimedAttrModifier.rst
@@ -0,0 +1,55 @@
+DeleteTimedAttrModifier()
+=========================
+
+FUNKTION
+--------
+::
+
+     int DeleteTimedAttrModifier(string key)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+     key	-	aus P_TIMED_ATTR_MOD zu loeschender Eintrag
+
+BESCHREIBUNG
+------------
+::
+
+     Der zu key gehoerende Eintrag in P_TIMED_ATTR_MOD wird geloescht und
+     update_max_sp_and_hp ausgefuehrt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     TATTR_INVALID_ARGS      -     Im Falle eines fehlenden key-Arguments 
+     TATTR_NO_SUCH_MODIFIER  -     Falls der Modifier mit diesem Key nicht
+                                   existiert
+     TATTR_OK                -     Im Erfolgsfall
+
+     
+
+     Die Rueckgabewerte sind in /sys/living/attributes.h definiert.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+	QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+	SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+	SetTimedAttrModifier(), QueryTimedAttrModifier(), 
+	P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+	P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/DiscoverDoor.rst b/doc/sphinx/lfun/DiscoverDoor.rst
new file mode 100644
index 0000000..2deb1a1
--- /dev/null
+++ b/doc/sphinx/lfun/DiscoverDoor.rst
@@ -0,0 +1,54 @@
+DiscoverDoor()
+==============
+
+FUNKTION
+--------
+::
+
+    varargs int DiscoverDoor(string dname)
+
+ARGUMENTE
+---------
+::
+
+    dname: Name des Raumes, in dem der Seher das Sehertor kennenlernen soll.
+           Default: Die Umgebung des Sehers.
+
+BESCHREIBUNG
+------------
+::
+
+    Nachdem diese Funktion aufgerufen wurde, kann der Seher (this_player())
+    das Tor in dem angegebenen Raum immer verwenden.
+
+RUECKGABEWERT
+-------------
+::
+
+    1, falls der Seher ein NEUES Tor kennengelernt hat
+    0, falls er das Tor schon kannte oder kein Seher war
+
+BEMERKUNGEN
+-----------
+::
+
+    Von einem Sehertor wird diese Funktion automatisch beim Betreten des
+    umgebenden Raumes aufgerufen, falls P_SEERDOOR_DISCOVER gesetzt ist. Wenn
+    ein Tor auf diese Art nicht entdeckt werden soll, so darf
+    P_SEERDOOR_DISCOVER nicht gesetzt sein und muss DiscoverDoor() separat,
+    z.B. von einem Questobjekt, aufgerufen werden.
+    Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
+
+BEISPIELE
+---------
+::
+
+    write("Der Zauberer sagt: Im Nichts wirst Du ein weiteres Tor finden!\n");
+    "/d/seher/portale/sehertormaster"->DiscoverDoor("/room/void");
+
+SIEHE AUCH
+----------
+::
+
+    DoorIsKnown, ShowDoors, Teleport, GetDoorsMapping
+
diff --git a/doc/sphinx/lfun/DistributeExp.rst b/doc/sphinx/lfun/DistributeExp.rst
new file mode 100644
index 0000000..dd6696c
--- /dev/null
+++ b/doc/sphinx/lfun/DistributeExp.rst
@@ -0,0 +1,42 @@
+DistributeExp()
+===============
+
+FUNKTION
+--------
+::
+
+     private void DistributeExp(object enemy, int exp_to_give)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+     object enemy     - toetender Feind
+     int exp_to_give  - zu verteilende XP (== P_XP/100)
+
+BESCHREIBUNG
+------------
+::
+
+     Das sterbende Wesen verteilt seine XP an seine Feinde.
+
+     Dabei bekommt jeder Gegner seinen Anteil (abhaengig von 50% von seinem
+     gemachten Schaden) und einen Teamanteil (die anderen 50% ueber das
+     gesamte Team addiert und durch die Teamanzahl geteilt).
+
+SIEHE AUCH
+----------
+::
+
+     Funktionen:  AddExp()
+     Properties:  P_XP
+     Sonstiges:   teamkampf
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/DoDecay.rst b/doc/sphinx/lfun/DoDecay.rst
new file mode 100644
index 0000000..e600daf
--- /dev/null
+++ b/doc/sphinx/lfun/DoDecay.rst
@@ -0,0 +1,69 @@
+DoDecay()
+=========
+
+FUNKTION
+--------
+::
+
+      public  int    DoDecay(int silent) 
+
+DEFINIERT IN
+------------
+::
+
+      /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+     silent (int)
+       Falls != 0, erfolgt beim Zerfall keine Meldung, d.h. doDecayMessaage()
+       wird nicht gerufen.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Die Funktion gibt die nach dem Zerfall noch uebrig gebliebene Menge
+     zurueck (int).
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird in Clones von Unitobjekten aus der Blueprint gerufen,
+     wenn ein Zerfallsintervall abgelaufen ist (natuerlich nur, wenn in der BP
+     der Zerfall konfiguriert ist).
+     Die Funktion prueft normalerweise via P_UNIT_DECAY_FLAGS, ob der Zerfall
+     stattfinden soll, bestimmt aus P_UNIT_DECAY_QUOTA die zu zerfallende
+     Menge, ruft DoDecayMessage() und reduziert P_AMOUNT.
+
+     
+
+     Sie kann auch von Hand gerufen werden, um einen Zerfall auszuloesen, auch
+     wenn mir gerade nicht einfaellt, in welchen Situationen das sinnvoll
+     waere (vielleicht als Spruchmisserfolg. *g*)
+
+BEMERKUNGEN
+-----------
+::
+
+     Wenn man einen anderen Zerfallsmechanismus haben, will muss man diese
+     Funktion wohl ueberschreiben. In fast allen Faellen sollte dies jedoch
+     unnoetig sein. Hat jemand das Verlangen, diese Funktion zu
+     ueberschreiben, ist vielleicht vorher eine Diskussion mit dem Mudlib-EM
+     angebracht.
+
+SIEHE AUCH
+----------
+::
+
+     unit
+     P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_QUOTA,
+     P_UNIT_DECAY_MIN
+     DoDecayMessage()
+     /std/unit.c
+
+14.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/DoDecayMessage.rst b/doc/sphinx/lfun/DoDecayMessage.rst
new file mode 100644
index 0000000..c21080d
--- /dev/null
+++ b/doc/sphinx/lfun/DoDecayMessage.rst
@@ -0,0 +1,56 @@
+DoDecayMessage()
+================
+
+FUNKTION
+--------
+::
+
+      protected void DoDecayMessage(int oldamount, int zerfall);
+
+      
+
+DEFINIERT IN
+------------
+::
+
+      /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+     oldamount (int)
+        Menge vor dem Zerfall
+     zerfall (int)
+        jetzt zerfallende Menge
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird von DoDecay() gerufen und gibt die Standardmeldungen
+     beim Zerfall von Unitobjekten aus.
+     Hierbei ist an der Unit noch alles unveraendert, wenn diese Funktion
+     gerufen wird, die Reduktion von P_AMOUNT erfolgt direkt im Anschluss.
+     Die Funktion wird nicht gerufen, wenn DoDecay() mit silent!=0 gerufen
+     wird.
+
+BEMERKUNGEN
+-----------
+::
+
+     Will man nicht die Standardzerfallsmeldungen (wovon ich meist ausgehe),
+     kann man diese Funktion ueberschreiben und eigene Meldungen erzeugen.
+
+SIEHE AUCH
+----------
+::
+
+     unit
+     P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_QUOTA,
+     P_UNIT_DECAY_MIN
+     DoDecay()
+     /std/unit.c
+
+14.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/DoUnwear.rst b/doc/sphinx/lfun/DoUnwear.rst
new file mode 100644
index 0000000..f4807bf
--- /dev/null
+++ b/doc/sphinx/lfun/DoUnwear.rst
@@ -0,0 +1,56 @@
+DoUnwear()
+==========
+
+FUNKTION
+--------
+::
+
+     varargs int DoUnwear(int silent, int all);
+
+DEFINIERT IN
+------------
+::
+
+     /std/clothing/wear.c
+
+ARGUMENTE
+---------
+::
+
+     silent
+          Falls ungleich 0, so werden keine Meldungen ausgegeben.
+          Falls (silent&M_NOCHECK) werden auch verfluchte Ruestungen
+          ausgezogen
+     all
+          Ungleich 0, wenn DoUnwear() aus einem "ziehe alles aus" heraus
+          aufgerufen wurde.
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird versucht, die Ruestung auszuziehen. Dabei werden eine eventuell
+     vorhandene RemoveFunc() und Flueche mit beruecksichtigt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn die Ruestung gar nicht getragen war, ansonsten 1.
+
+BEMERKUNGEN
+-----------
+::
+
+     Auch wenn eine 1 zurueckgegeben wird, muss das nicht heissen, dass die
+     Ruestung erfolgreich ausgezogen wurde!
+
+SIEHE AUCH
+----------
+::
+
+     DoWear(), RemoveFunc(), InformUnwear(), /std/armour/combat.c
+
+
+Last modified: Sun Jun 27 22:22:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/DoUnwield.rst b/doc/sphinx/lfun/DoUnwield.rst
new file mode 100644
index 0000000..f733e48
--- /dev/null
+++ b/doc/sphinx/lfun/DoUnwield.rst
@@ -0,0 +1,55 @@
+DoUnwield()
+===========
+
+FUNKTION
+--------
+::
+
+     varargs int DoUnwield(int silent);
+
+DEFINIERT IN
+------------
+::
+
+     /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+     silent
+          Ungleich 0, wenn die Waffe ohne Meldungen weggesteckt werden soll.
+          Wenn silent&M_NOCHECK wird die Waffe auch weggesteckt wenn sie
+          verflucht ist und UnwieldFunc() wird nicht ausgewertet.
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird versucht, die Waffe wegzustecken.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn die Waffe gar nicht gezueckt war, ansonsten 1.
+
+BEMERKUNGEN
+-----------
+::
+
+     Anhand des Rueckgabewertes laesst sich nicht ersehen, ob die Waffe sich
+     wegstecken liess oder nicht!
+
+     Wenn die Waffe verflucht ist oder (falls definiert) UnwieldFunc() 0
+     zurueckgibt, laesst sie sich nicht wegstecken.
+
+SIEHE AUCH
+----------
+::
+
+     UnwieldFunc(), InformUnwield(), /std/weapon.c
+
+
+Letzte Aenderung: 18.11.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/DoWear.rst b/doc/sphinx/lfun/DoWear.rst
new file mode 100644
index 0000000..715f416
--- /dev/null
+++ b/doc/sphinx/lfun/DoWear.rst
@@ -0,0 +1,65 @@
+DoWear()
+========
+
+FUNKTION
+--------
+::
+
+     varargs int DoWear(int silent, int all);
+
+DEFINIERT IN
+------------
+::
+
+     /std/armour/combat.c
+
+ARGUMENTE
+---------
+::
+
+     silent
+          Falls ungleich 0, so werden keine Meldungen ausgegeben.
+     all
+          Ungleich 0, wenn DoWear() aus einem "ziehe alles an" heraus
+          aufgerufen wurde.
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird versucht, die Ruestung anzuziehen. Dabei wird eine eventuell
+     vorhandene WearFunc() mit beruecksichtigt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn man die Ruestung gar nicht bei sich hat oder sie schon an hat,
+     ansonsten 1.
+
+BEMERKUNGEN
+-----------
+::
+
+     Auch wenn eine 1 zurueckgegeben wird, muss das nicht heissen, dass die
+     Ruestung erfolgreich angezogen wurde!
+
+     Gruende fuer ein Fehlschlagen des Anziehens koennen sein:
+        o Man hat die Ruestung nicht bei sich.
+        o Man hat die Ruestung schon an.
+        o Man hat schon eine Ruestung des gleichen Typs an.
+        o Der Typ der Ruestung oder die Ruestungsklasse ist illegal.
+        o Falls definiert: WearFunc() gab 0 zurueck.
+        o Falls es sich um einen Schild handelt: Man hat keine Hand mehr
+          frei.
+
+SIEHE AUCH
+----------
+::
+
+     DoUnwear(), WearFunc(), InformWear(), P_EQUIP_TIME, 
+     /std/armour/combat.c, P_UNWEAR_MSG, P_WEAR_MSG
+
+
+Last modified: Sun Jun 27 22:22:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/DoWield.rst b/doc/sphinx/lfun/DoWield.rst
new file mode 100644
index 0000000..5334a5b
--- /dev/null
+++ b/doc/sphinx/lfun/DoWield.rst
@@ -0,0 +1,64 @@
+DoWield()
+=========
+
+FUNKTION
+--------
+::
+
+     varargs int DoWield(int silent);
+
+DEFINIERT IN
+------------
+::
+
+     /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+     silent
+          Ungleich 0, wenn die Waffe ohne Meldungen gezueckt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird versucht, die Waffe zu zuecken. Hat man schon eine Waffe
+     gezueckt, so wird versucht, diese wegzustecken. Klappt das nicht, kann
+     die Waffe nicht gezueckt werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn man die Waffe gar nicht bei sich traegt, ansonsten 1.
+
+BEMERKUNGEN
+-----------
+::
+
+     Anhand des Rueckgabewertes laesst sich nicht entscheiden, ob die Waffe
+     sich erfolgreich zuecken liess!
+
+     Gruende, warum sich eine Waffe nicht zuecken lassen kann, sind
+     folgende:
+        o Man traegt sie nicht bei sich (oder sie steckt in einem Beutel
+          o.ae.).
+        o Man hat sie schon gezueckt.
+        o Falls definiert: WieldFunc() gibt 0 zurueck.
+        o Man ist nicht geschickt genug (das haengt von der Waffenklasse
+          ab).
+        o Eine schon gezueckte Waffe laesst sich nicht wegstecken.
+        o Die Waffenklasse ist hoeher als erlaubt.
+        o Man hat nicht genug Haende frei.
+
+SIEHE AUCH
+----------
+::
+
+     WieldFunc(), InformWield(), P_EQUIP_TIME, /std/weapon.c
+
+
+Last modified: Wed Apr 08 10:25:00 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/DoorIsKnown.rst b/doc/sphinx/lfun/DoorIsKnown.rst
new file mode 100644
index 0000000..29a396c
--- /dev/null
+++ b/doc/sphinx/lfun/DoorIsKnown.rst
@@ -0,0 +1,46 @@
+DoorIsKnown()
+=============
+
+FUNKTION
+--------
+::
+
+	int DoorIsKnown()
+
+ARGUMENTE
+---------
+::
+
+	Keine.
+
+BESCHREIBUNG
+------------
+::
+
+	Testet, ob der Seher (this_player()) das Tor in seiner momentanen
+	Umgebung schon kennt.
+
+RUECKGABEWERT
+-------------
+::
+
+	Die Nummer des Tores.
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
+
+BEISPIELE
+---------
+::
+
+    /d/seher/portale/sehertormaster->DoorIsKnown()
+
+SIEHE AUCH
+----------
+::
+
+    DiscoverDoor, ShowDoors, Teleport, GetDoorsMapping
+
diff --git a/doc/sphinx/lfun/Dump.rst b/doc/sphinx/lfun/Dump.rst
new file mode 100644
index 0000000..23f79fe
--- /dev/null
+++ b/doc/sphinx/lfun/Dump.rst
@@ -0,0 +1,38 @@
+Dump()
+======
+
+FUNKTION
+--------
+::
+
+     void Dump()
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/materialdb.c (MATERIALDB)
+
+BESCHREIBUNG
+------------
+::
+
+     Schreibt alle Materialien samt ihren Gruppen und alle Gruppen mit
+     dazugehoerenden Materialien in DUMPFILE (/p/daemon/save/MATERIALS)
+     Wird in create() der Materialiendatenbank automatisch aufgerufen.
+     Das Dumpfile ist zum Recherchieren der Materialien gedacht.
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Listen:	  AllMaterials(), AllGroups()
+		  materialliste, materialgruppen
+     Master:	  AddMaterial(), ConvMaterialList(), MaterialGroup(),
+		  GroupName(), MaterialName(),
+		  GetGroupMembers(), GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/EnemyPresent.rst b/doc/sphinx/lfun/EnemyPresent.rst
new file mode 100644
index 0000000..b027698
--- /dev/null
+++ b/doc/sphinx/lfun/EnemyPresent.rst
@@ -0,0 +1,34 @@
+EnemyPresent()
+==============
+
+FUNKTION
+--------
+::
+
+     public mixed EnemyPresent()
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/combat.c
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt aus der Feindesliste den ersten anwesenden, lebenden und 
+     angreifbaren aktuellen Gegner im Raum zurueck.
+     Damit ist die Funktion identisch zu InFight().
+
+     Will man alle Gegner, auf die diese Kriterien zutreffen, sollte man
+     PresentEnemies() verwenden.
+
+SIEHE AUCH
+----------
+::
+
+     PresentEnemies(), Infight()
+
+22.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/Enter.rst b/doc/sphinx/lfun/Enter.rst
new file mode 100644
index 0000000..dd58b38
--- /dev/null
+++ b/doc/sphinx/lfun/Enter.rst
@@ -0,0 +1,65 @@
+Enter()
+=======
+
+FUNKTION
+--------
+::
+
+     int Enter();
+
+DEFINIERT IN
+------------
+::
+
+     /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn sich der Spieler noch nicht auf dem Transporter befindet, und der
+     Transporter momentan an einer Haltestelle liegt, betritt der Spieler
+     den Transporter.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Null, wenn der Spieler den Transporter nicht betreten konnte, sonst
+     ungleich Null.
+
+BEMERKUNGEN
+-----------
+::
+
+     Es werden keine Tests durchgefuehrt, ob der Transporter ueberhaupt
+     angesprochen wurde! Das muss man selber machen.
+
+BEISPIELE
+---------
+::
+
+     int myEnter(string str)
+     {
+       if (str && id(str))
+         return Enter();
+
+       notify_fail("Was willst Du betreten?\n");
+       return 0;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Leave(), /std/transport.c
+
+
+Last modified: Wed May 8 10:18:42 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/EvalArmour.rst b/doc/sphinx/lfun/EvalArmour.rst
new file mode 100644
index 0000000..4f146de
--- /dev/null
+++ b/doc/sphinx/lfun/EvalArmour.rst
@@ -0,0 +1,48 @@
+EvalArmour()
+============
+
+FUNKTION
+--------
+::
+
+    int EvalArmour(object ob, closure qp)
+
+ 
+
+DEFINIERT IN
+------------
+::
+
+    /std/room/shop.c
+
+ 
+
+ARGUMENTE
+---------
+::
+
+    ob - Eine Ruestung.
+    qp - symbol_function("QueryProp",ob)
+
+BESCHREIBUNG
+------------
+::
+
+    Bewertet die Ruestung.
+
+ 
+
+RUECKGABEWERT
+-------------
+::
+
+    Max(P_AC,P_EFFECTIVE_AC);
+
+ 
+
+SIEHE AUCH
+----------
+::
+
+    FindBestArmour()
+
diff --git a/doc/sphinx/lfun/EvalWeapon.rst b/doc/sphinx/lfun/EvalWeapon.rst
new file mode 100644
index 0000000..d009aaf
--- /dev/null
+++ b/doc/sphinx/lfun/EvalWeapon.rst
@@ -0,0 +1,48 @@
+EvalWeapon()
+============
+
+FUNKTION
+--------
+::
+
+    int EvalWeapon(object ob, closure qp)
+
+ 
+
+DEFINIERT IN
+------------
+::
+
+    /std/room/shop.c
+
+ 
+
+ARGUMENTE
+---------
+::
+
+    ob - Eine Waffe.
+    qp - symbol_function("QueryProp",ob)
+
+BESCHREIBUNG
+------------
+::
+
+    Bewertet die Waffe.
+
+ 
+
+RUECKGABEWERT
+-------------
+::
+
+    Max(P_WC,P_EFFECTIVE_WC);
+
+ 
+
+SIEHE AUCH
+----------
+::
+
+    FindBestWeapon()
+
diff --git a/doc/sphinx/lfun/ExtraAttack.rst b/doc/sphinx/lfun/ExtraAttack.rst
new file mode 100644
index 0000000..29b6350
--- /dev/null
+++ b/doc/sphinx/lfun/ExtraAttack.rst
@@ -0,0 +1,50 @@
+ExtraAttack()
+=============
+
+FUNKTION
+--------
+::
+
+	varargs public void ExtraAttack(object enemy, int ignore_previous);
+
+ARGUMENTE
+---------
+::
+
+	enemy: Der Feind.
+	ignore_previous: Ein Flag
+
+BESCHREIBUNG
+------------
+::
+
+	Der Feind wird der Staerke der Waffe (bzw. der Haende) entsprechend
+	stark angegriffen. Hierbei wird Attack() aufgerufen.
+	Ist ignore_previous ungleich 0, dann wird die Erstschlagsperre von
+	Attack ignoriert. Dieser Angriff ist also auch dann moeglich, wenn
+	das Lebewesen eigentlich keinen Schlag mehr in dieser Runde ausfuehren
+	duerfte.
+
+RUECKGABEWERT
+-------------
+::
+
+	Keiner.
+
+BEMERKUNG
+---------
+::
+
+	Der Einsatz dieser Funktion ist genehmigungspflichtig.
+	Weitere Hinweise siehe "man Attack".
+
+SIEHE AUCH
+----------
+::
+
+	"Attack"
+	/std/living/combat.c
+
+
+Last modified: Sun Nov 21 12:32:20 2004 by Bambi
+
diff --git a/doc/sphinx/lfun/FilterArmours.rst b/doc/sphinx/lfun/FilterArmours.rst
new file mode 100644
index 0000000..b83edf5
--- /dev/null
+++ b/doc/sphinx/lfun/FilterArmours.rst
@@ -0,0 +1,99 @@
+FilterArmours()
+===============
+
+FUNKTION
+--------
+::
+
+     public object *FilterArmours(closure filterfun, varargs mixed* extra)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+     closure filterfun
+       Die Closure, die entscheiden soll, ob eine Ruestung im Ergebnisarray
+       enthalten sein soll.
+
+     
+
+     mixed extra
+       Beliebig viele Extra-Argumente, die <filterfun> uebergeben werden.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion ruft <filterfunc> fuer jede getragene Ruestung des
+     Lebewesen mit der jeweiligen Ruestung als Argument auf und liefert ein
+     Array mit allen Ruestungen zurueck, fuer die <filterfun> einen Wert != 0
+     zurueckliefert.
+     Die <extra> Argumente werden als zusaetzliche Parameter an <filterfun>
+     uebergeben und duerfen keine Referenzen sein.
+
+     
+
+     Diese Variante ist zu bevorzugen, wenn man Ruestungen nach bestimmten
+     Kriterien durchsuchen will und QueryArmourByType() nicht ausreichend sein
+     sollte.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Ein Array von Objekten mit allen passenden Ruestungen.
+
+BEISPIELE
+---------
+::
+
+     1) Ich moechte gerne alle Ruestungen haben, die beschaedigt sind:
+     private int _is_damaged(object ruestung) {
+         return ruestung->QueryProp(P_DAMAGE);
+     }
+     ...
+     object *damaged_armours = PL->FilterArmours(#'_is_damaged);
+
+     2) Ich moechte alle Ruestungen, die groesser als 50cm sind.
+     private int _armour_is_bigger(object ruestung, int size) {
+       return ruestung->QueryProp(P_SIZE) > size;
+     }
+     ...
+     object *big_armours = PL->FilterArmours(#'_amour_is_bigger, 50); 
+
+     3) alle Ruestungen mit einer speziellen ID.
+     private int _has_id(object ruestung, string idstr) {
+       return ruestung->id(idstr);
+     }
+     object *has_id = PL->FilterArmours(#'_has_id, "\ntolleruestung");
+
+     4) alle Ruestungen mit einer speziellen ID, die groesser als 50cm sind.
+     private int _has_id(object ruestung, string idstr, int size) {
+       return ruestung->id(idstr) && ruestung->QueryProp(P_SIZE) > size;
+     }
+     object *has_id = PL->FilterArmours(#'_has_id, "\ntolleruestung", 50);
+
+     5) ueberhaupt alle getragene Ruestung
+     object *rue = PL->FilterArmours(#'objectp)
+
+SIEHE AUCH
+----------
+::
+
+     Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour(), 
+     UnwearClothing()
+     P_CLOTHING, P_ARMOURS
+     FilterClothing(), QueryArmourByType()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/FilterClothing.rst b/doc/sphinx/lfun/FilterClothing.rst
new file mode 100644
index 0000000..268608e
--- /dev/null
+++ b/doc/sphinx/lfun/FilterClothing.rst
@@ -0,0 +1,80 @@
+FilterClothing()
+================
+
+FUNKTION
+--------
+::
+
+     public object *FilterClothing(closure filterfun, varargs mixed* extra)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+     closure filterfun
+       Die Closure, die entscheiden soll, ob eine Kleidung im Ergebnisarray
+       enthalten sein soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion ruft <filterfunc> fuer jede getragene Kleidung des
+     Lebewesen mit der jeweiligen Kleidung als Argument auf und liefert ein
+     Array mit aller Kleidung zurueck, fuer die <filterfun> einen Wert != 0
+     zurueckliefert.
+     Die <extra> Argumente werden als zusaetzliche Parameter an <filterfun>
+     uebergeben und duerfen keine Referenzen sein.
+
+     
+
+     Diese Variante ist zu bevorzugen, wenn man die getrage Kleidung nach
+     bestimmten Kriterien durchsuchen will. 
+
+RUeCKGABEWERT
+-------------
+::
+
+     Ein Array von Objekten mit allen passenden Kleidung.
+
+BEISPIELE
+---------
+::
+
+     1) Ich moechte alle Kleidung, die groesser als 50cm ist.
+     private int _armour_is_bigger(object clothing, int size) {
+       return clothing->QueryProp(P_SIZE) > size;
+     }
+     ...
+     object *big_armours = PL->FilterClothing(#'_amour_is_bigger, 50); 
+
+     2) alle Kleidung mit einer speziellen ID.
+     private int _has_id(object clothing, string idstr) {
+       return clothing->id(idstr);
+     }
+     object *has_id = PL->FilterClothing(#'_has_id, "\ntollekleidung");
+
+     3) ueberhaupt alle getragene Kleidung
+     object *clothing = PL->FilterClothing(#'objectp)
+
+SIEHE AUCH
+----------
+::
+
+     Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour(), 
+     UnwearClothing()
+     P_CLOTHING, P_ARMOURS
+     FilterArmours(), QueryArmourByType()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/FindBestArmours.rst b/doc/sphinx/lfun/FindBestArmours.rst
new file mode 100644
index 0000000..adb2b5b
--- /dev/null
+++ b/doc/sphinx/lfun/FindBestArmours.rst
@@ -0,0 +1,74 @@
+FindBestArmours()
+=================
+
+FUNKTION
+--------
+::
+
+    varargs object *FindBestArmours(mixed type, int maxmon, int maxw,
+                                    mapping minac, mixed restr)
+
+ 
+
+DEFINIERT IN
+------------
+::
+
+    /std/room/shop.c
+
+ 
+
+ARGUMENTE
+---------
+::
+
+    type   - gewuenschter Ruestungstyp / Ruestungstypen
+    maxmon - Geld das ausgegeben werden darf
+    maxw   - Maximales Gewicht
+    minac  - minimale gewuenschte Ruestungsklasse pro Typ
+    restr  - zusaetzliches Argument fuer CheckFindRestrictions()
+
+BESCHREIBUNG
+------------
+::
+
+    Sucht die besten Ruestungen, die der Laden verkaufen kann.
+
+ 
+
+RUECKGABEWERT
+-------------
+::
+
+    Die besten Ruestungen
+
+ 
+
+BEMERKUNG
+---------
+::
+
+    Die Qualitaet der Ruestung wird mit EvalArmour() bestimmt.
+    Haben zwei Ruestungen die gleiche Qualitaet,
+    wird die preiswertere genommen.
+
+ 
+
+BEISPIEL
+--------
+::
+
+    FindBestArmours(AT_ARMOUR,5000)
+    Bestes Ruestung unter 5000 Muenzen.
+
+    FindBestArmours(({AT_ARMOUR,AT_CLOAK,AT_BOOT}),10000,([AT_ARMOUR:20]))
+    Finded beste Ruestung, Umhang und Schuhe, die der Laden fuer
+    insgesamt 10000 Muenzen verkaufen kann, wobei die Ruestung mindestens
+    AC 20 haben muss.
+
+SIEHE AUCH
+----------
+::
+
+    FindBestWeapon(), CheckFindRestrictions(), EvalArmour()
+
diff --git a/doc/sphinx/lfun/FindBestWeapon.rst b/doc/sphinx/lfun/FindBestWeapon.rst
new file mode 100644
index 0000000..ed8adcb
--- /dev/null
+++ b/doc/sphinx/lfun/FindBestWeapon.rst
@@ -0,0 +1,69 @@
+FindBestWeapon()
+================
+
+FUNKTION
+--------
+::
+
+    varargs object FindBestWeapon(mixed type, int maxmon, int maxw, int hands,
+                                  int minwc, mixed restr)
+
+ 
+
+DEFINIERT IN
+------------
+::
+
+    /std/room/shop.c
+
+ 
+
+ARGUMENTE
+---------
+::
+
+    type   - gewuenschter Waffentyp / Waffentypen
+    maxmon - Geld das ausgegeben werden darf
+    maxw   - Maximales Gewicht
+    hands  - Anzahl Haende, die die Waffe belegen darf
+    minwc  - minimale gewuenschte Waffenklasse
+    restr  - zusaetzliches Argument fuer CheckFindRestrictions()
+
+BESCHREIBUNG
+------------
+::
+
+    Sucht die beste Waffe, die der Laden verkaufen kann.
+
+ 
+
+RUECKGABEWERT
+-------------
+::
+
+    Die beste Waffe :-)
+
+ 
+
+BEMERKUNG
+---------
+::
+
+    Die Qualitaet der Waffe wird mit EvalWeapon() bestimmt.
+    Haben zwei Waffen die gleiche Qualitaet, wird die preiswertere genommen.
+
+ 
+
+BEISPIEL
+--------
+::
+
+    FindBestWeapon(WT_SWORD,5000,1)
+    Bestes einhaendiges Schwert unter 5000 Muenzen.
+
+SIEHE AUCH
+----------
+::
+
+    FindBestArmours(), CheckFindRestrictions(), EvalWeapon()
+
diff --git a/doc/sphinx/lfun/FindDistantEnemyVictim.rst b/doc/sphinx/lfun/FindDistantEnemyVictim.rst
new file mode 100644
index 0000000..ef0dc66
--- /dev/null
+++ b/doc/sphinx/lfun/FindDistantEnemyVictim.rst
@@ -0,0 +1,57 @@
+FindDistantEnemyVictim()
+========================
+
+FUNKTION
+--------
+::
+
+	object FindDistantEnemyVictim(string wen, object pl, string msg,
+	                              int dist, int dy)
+
+DEFINIERT IN
+------------
+::
+
+	/std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+	wen  - id des gewuenschten Gegners, falls nicht angegeben:
+               SelectEnemy(FindDistantGroup(pl,-1,dist,dy,10000)
+	pl   - Caster.
+	msg  - Nachricht falls Gegner nicht anwesend ist.
+	dist - Entfernung
+	dy   - 2*erlaubte Abweichung von der Entfernung, default 100
+
+BESCHREIBUNG
+------------
+::
+
+	Findet einen Gegner in Entfernung dist-dy/2 bis dist+dy/2
+	z.B. fuer einen Angriffsspruch.
+
+	
+
+RUECKGABEWERT
+-------------
+::
+
+	Der Auserwaehlte :-)
+
+BEMERKUNGEN
+-----------
+::
+
+	1. Der Gegner wird auf jeden Fall angegriffen.
+	2. dist wird mit SA_RANGE modifiziert,
+	   dy wird mit SA_EXTENSION modifiziert.
+	3. Die Entfernung ist relativ zum Spieler.
+
+SIEHE AUCH
+----------
+::
+
+	teams, FindEnemyVictim, FindNearEnemyVictim, FindFarEnemyVictim
+
diff --git a/doc/sphinx/lfun/FindDistantGroup.rst b/doc/sphinx/lfun/FindDistantGroup.rst
new file mode 100644
index 0000000..95e65b0
--- /dev/null
+++ b/doc/sphinx/lfun/FindDistantGroup.rst
@@ -0,0 +1,53 @@
+FindDistantGroup()
+==================
+
+FUNKTION
+--------
+::
+
+	varargs object *FindDistantGroup(object pl, int who,
+                                         int dist, int dy, int dx)
+
+DEFINIERT IN
+------------
+::
+
+	/std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+	pl   - Caster
+	who  - 1=Freunde, -1=Gegner, 0=beide
+	dist - Entfernung
+	dy   - Tiefe      (default 100)
+	dx   - Breite     (default 100*MAX_TEAM_ROWLEN)
+
+BESCHREIBUNG
+------------
+::
+
+	Ermittelt Lebewesen, die sich in Entfernung <dist> in einem Bereich
+	der Breite <dx> und Tiefe <dy> befinden.
+
+RUECKGABEWERT
+-------------
+::
+
+	Array mit den gefundenen Lebewesen.
+
+BEMERKUNGEN
+-----------
+::
+
+	Genauere Hinweise unter "FindDistantGroups".
+	Wer sowohl Freunde wie auch Feinde in getrennten Arrays braucht,
+	sollte FindDistantGroups statt FindDistantGroup verwenden.
+
+SIEHE AUCH
+----------
+::
+
+	teams, FindDistantGroups
+
diff --git a/doc/sphinx/lfun/FindDistantGroups.rst b/doc/sphinx/lfun/FindDistantGroups.rst
new file mode 100644
index 0000000..eb81f35
--- /dev/null
+++ b/doc/sphinx/lfun/FindDistantGroups.rst
@@ -0,0 +1,85 @@
+FindDistantGroups()
+===================
+
+FUNKTION
+--------
+::
+
+	varargs mixed FindDistantGroups(object pl, int dist, int dy, int dx)
+
+DEFINIERT IN
+------------
+::
+
+	/std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+	pl   - Caster
+	dist - Entfernung
+	dy   - Tiefe      (default 100)
+	dx   - Breite     (default 100*MAX_TEAM_ROWLEN)
+
+BESCHREIBUNG
+------------
+::
+
+	Ermitteld feindliche (bei Spielern NPCs, bei NPCs Spieler) und
+	freundliche (bei Spielern Spieler, bei NPCs NPCs) Lebewesen,
+	die sich in Entfernung <dist> in einem Bereich der Breite <dx>
+	und Tiefe <dy> befinden.
+
+RUECKGABEWERT
+-------------
+::
+
+	Array mit zwei Arrays als Inhalt:
+	({ feindliche Lebewesen, freundliche Lebewesen })
+
+BEMERKUNGEN
+-----------
+::
+
+	Die Entfernungsangaben sind als cm. zu verstehen.
+	Jedes Lebewesen belegt 50cm x 50cm mit Abstand 50cm
+	zum naechsten Lebewesen in jeder Richtung.
+	Die Breitenangabe wirkt sich nur in der Anzahl der
+	Lebewesen aus, die zufaellig pro Reihe ausgewaehlt werden.
+	Die Skillattribute SA_RANGE und SA_EXTENSION werden beruecksichtigt.
+
+BEISPIEL
+--------
+::
+
+	dist=200, dy=200, dx=200, ein Punkt = 50cm x 50cm
+	   . . . . . . . . . . . . .
+	3. . . . . . . G . . . . . .
+	   . . . . . . . . . . . . .
+	2. . . . . . G . G . . . . .dist+dy/2-+
+	   . . . . . . . . . . . . .          |  
+	1. . . . . G . G . G . . . .     dist +-+ (Gegner G)
+	---.-.-.-.-.-.-.-.-.-.-.-.-.          | |
+	1. . . . . F . F . F . . . .dist-dy/2-+ | (Freunde F)
+	   . . . . . . . . . . . . .            |
+	2. . . . . . F . S . . . . .------------+ (Reihe des Spielers S)
+	   . . . . . . . . . . . . .
+	3. . . . . . . F . . . . . .
+	   . . . . . . . . . . . . .
+	Abgedeckter Bereich:           100cm  bis  300cm
+                Reihe 3:  375cm..425cm         375>300 -> nicht erwischt
+                Reihe 2:  275cm..325cm         275<300 -> erwischt
+	Gegner  Reihe 1:  175cm..225cm 100<175,225<300 -> erwischt
+	Freunde Reihe 1:   75cm..125cm 100<125         -> erwischt
+	        Reihe 2:  -25cm...25cm 100> 25         -> nicht erwischt
+                Reihe 3: -125cm..-75cm 100>-75         -> nicht erwischt
+	Ergebnis: ({({G,G,G,G}),({F,F})})
+	(Maximal 2 Lebewesen pro Reihe bei Breite 200).
+
+SIEHE AUCH
+----------
+::
+
+	teams, FindDistantGroup
+
diff --git a/doc/sphinx/lfun/FindEnemyVictim.rst b/doc/sphinx/lfun/FindEnemyVictim.rst
new file mode 100644
index 0000000..8dad745
--- /dev/null
+++ b/doc/sphinx/lfun/FindEnemyVictim.rst
@@ -0,0 +1,49 @@
+FindEnemyVictim()
+=================
+
+FUNKTION
+--------
+::
+
+	object FindEnemyVictim(string wen, object pl, string msg)
+
+DEFINIERT IN
+------------
+::
+
+	/std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+	wen - id des gewuenschten Gegners, falls nicht angegeben SelectEnemy.
+	pl  - Caster.
+	msg - Nachricht falls Gegner nicht anwesend ist.
+
+BESCHREIBUNG
+------------
+::
+
+	Findet einen Gegner, z.B. fuer einen Angriffsspruch.
+
+	
+
+RUECKGABEWERT
+-------------
+::
+
+	Der Auserwaehlte :-)
+
+BEMERKUNGEN
+-----------
+::
+
+	Der Gegner wird auf jeden Fall angegriffen.
+
+SIEHE AUCH
+----------
+::
+
+	FindLivingVictim
+
diff --git a/doc/sphinx/lfun/FindFarEnemyVictim.rst b/doc/sphinx/lfun/FindFarEnemyVictim.rst
new file mode 100644
index 0000000..782aa22
--- /dev/null
+++ b/doc/sphinx/lfun/FindFarEnemyVictim.rst
@@ -0,0 +1,55 @@
+FindFarEnemyVictim()
+====================
+
+FUNKTION
+--------
+::
+
+	object FindFarEnemyVictim(string wen, object pl, string msg,
+	                          int min, int max)
+
+DEFINIERT IN
+------------
+::
+
+	/std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+	wen - id des gewuenschten Gegners, SelectFarEnemy falls n/a.
+	pl  - Caster.
+	msg - Nachricht falls Gegner nicht anwesend ist.
+	min - minimale Kampfreihe
+	max - maximale Kampfreihe
+
+BESCHREIBUNG
+------------
+::
+
+	Findet einen Gegner aus Kampfreihe <min> bis <max>
+	z.B. fuer einen Angriffsspruch.
+
+	
+
+RUECKGABEWERT
+-------------
+::
+
+	Der Auserwaehlte :-)
+
+BEMERKUNGEN
+-----------
+::
+
+	1. Der Gegner wird auf jeden Fall angegriffen.
+	2. Die Reihenangaben werden NICHT mit Skillattributen modifiziert.
+	3. Die Angabe der Reihe ist absolut.
+
+SIEHE AUCH
+----------
+::
+
+	teams, FindEnemyVictim, FindNearEnemyVictim, FindDistantEnemyVictim
+
diff --git a/doc/sphinx/lfun/FindGroup.rst b/doc/sphinx/lfun/FindGroup.rst
new file mode 100644
index 0000000..d4ad65d
--- /dev/null
+++ b/doc/sphinx/lfun/FindGroup.rst
@@ -0,0 +1,99 @@
+FindGroup()
+===========
+
+FUNKTION
+--------
+::
+
+    object*FindGroup(object pl,int who);
+
+DEFINIERT IN
+------------
+::
+
+    /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+    pl
+      Lebewesen, von welchem die Freunde oder Feinde in der Umgebung
+      gefunden werden sollen.
+    who
+      Flag, welches anzeigt, ob Freunde oder Feinde gefunden werden
+      sollen (Konstanten definiert in '/sys/new_skills.h'):
+        FG_ENEMIES - (Wert -1) Feinde sollen gefunden werden
+        FG_FRIENDS - (Wert  1) Freunde sollen gefunden werden
+        FG_ALL     - (Wert  0) alle Lebewesen sollen gefunden werden
+
+RUeCKGABEWERT
+-------------
+::
+
+    Array mit gefundenen Lebewesen
+
+BESCHREIBUNG
+------------
+::
+
+    Bei Spells, die sich auf mehrere Gegner auswirken oder bei denen man
+    per Hand ein Opfer auswaehlen moechte, laesst sich mittels der
+    Funktion FindGroup() eine Liste von Lebewesen ermitteln, welche in
+    der Umgebung von <pl> zu finden sind.
+    Je nachdem, was man denn genau vorhat, kann man sich von der
+    Funktion freundlich oder feindlich gesinnte Lebewesen heraussuchen
+    lassen.
+    Will man die freundlich gesinnten Lebewesen ermitteln, so uebergibt
+    man in <who> die Konstante FG_FRIENDS, bei feindlich gesinnten die
+    Konstante FG_ENEMIES, und wenn man alle Lebewesen bekommen moechte
+    schliesslich FG_ALL.
+    Bei der Auswahl gelten folgende Regeln:
+      (1) Lebewesen, mit denen <pl> im Kampf ist, sind grundsaetzlich
+          feindlich gesinnt.
+      (2) Teammitglieder von <pl> sind grundsaetzlich freundlich
+          gesinnt.
+      (3) Spieler sind gegenueber Spielern freundlich gesinnt, NPCs
+          gegenueber NPCs. NPCs kann man hierbei mit Hilfe der Property
+          P_FRIEND den Spielern zuordnen.
+      (4) Daraus folgt natuerlich, dass Spieler und NPCs grundsaetzlich
+          eine feindliche Einstellung gegenueber haben, sofern die NPCs
+          nicht die Property P_FRIEND gesetzt haben
+           (was standardmaessig natuerlich nicht der Fall ist).
+      (5) Netztote werden nicht erkannt.
+      (6) Magier werden nicht erkannt, wenn sie unsichtbar sind.
+      (7) Ein Magier wird als feindlich gesinnt nur dann erkannt, wenn
+          <pl> mit ihm im Kampf ist.
+      (6) Sucht man feindlich gesinnte Lebewesen, so werden die, welche
+          eine von den Properties P_NO_ATTACK oder P_NO_GLOBAL_ATTACK
+          gesetzt haben, nicht erkannt.
+    Die Property P_FRIEND sollte man in NPCs setzen, die dem Spieler
+    hilfreich beiseite stehen, z.B. vom Spieler beschworene HilfsNPCs.
+
+BEISPIELE
+---------
+::
+
+    Wenn man einen Feuerball nach jemandem wirft, so trifft dieser unter
+    Umstaenden auch andere, wenn er gross genug ist. Man nimmt hierbei
+    an, dass sich die freundlich gesinnten Lebewesen des Gegners auch
+    naeher bei ihm befinden als die feindlich gesinnten:
+      victim->Defend(500,DT_FIRE,([SP_SHOW_DAMAGE:1]),caster);
+      victimList=FindGroup(victim,FG_FRIENDS);
+      map_objects(victimList,
+                      "Defend",
+                      100,
+                      DT_FIRE,
+                      ([SP_SHOW_DAMAGE:1]),
+                      caster);
+    Hiermit trifft man also auch die Freunde von <victim>.
+
+SIEHE AUCH
+----------
+::
+
+    FindGroupN(), FindGroupP(), P_FRIEND, P_NO_GLOBAL_ATTACK
+
+
+Last modified: Mon Jan 28 21:45:00 2002 by Tiamak
+
diff --git a/doc/sphinx/lfun/FindGroupN.rst b/doc/sphinx/lfun/FindGroupN.rst
new file mode 100644
index 0000000..ec436fb
--- /dev/null
+++ b/doc/sphinx/lfun/FindGroupN.rst
@@ -0,0 +1,68 @@
+FindGroupN()
+============
+
+FUNKTION
+--------
+::
+
+	object*FindGroupN(object pl,int who,int n);
+
+DEFINIERT IN
+------------
+::
+
+	/std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+	pl
+	  Lebewesen, von welchem die Freunde oder Feinde in der Umgebung
+	  gefunden werden sollen.
+	who
+	  Flag, welches anzeigt, ob Freunde oder Feinde gefunden werden
+	  sollen (Konstanten definiert in '/sys/new_skills.h'):
+	    FG_ENEMIES - (Wert -1) Feinde sollen gefunden werden
+	    FG_FRIENDS - (Wert  1) Freunde sollen gefunden werden
+	    FG_ALL     - (Wert  0) alle Lebewesen sollen gefunden werden
+	n
+	  Anzahl der Lebewesen, die zurueckgegeben werden sollen.
+	  Hierbei geht vorher noch das Skillattribute SA_EXTENSION ein!
+	  Es wird mindestens 1 Lebewesen zurueckgeliefert (sofern gefunden).
+
+RUeCKGABEWERT
+-------------
+::
+
+	Array mit gefundenen Lebewesen
+
+BESCHREIBUNG
+------------
+::
+
+	Ausgesucht werden die Lebewesen genauso wie bei FindGroup(), nur
+	dass zum Schluss die Anzahl noch begrenzt wird.
+
+BEISPIELE
+---------
+::
+
+	Man moechte maximal 5 Feinde finden, die man gleichzeitig mit einem
+	Spell belegen kann:
+	  enemyList=FindGroupN(caster,FG_ENEMIES,5);
+	Dies gilt jedoch nur bei SA_EXTENSION==100, sonst wird
+	dementsprechend mehr oder weniger zurueckgegeben.
+	 (also bei SA_EXTENSION==200 doppelt so viele -> 10 Lebewesen)
+	Das Skillattribute SA_EXTENSION kann auch durch SA_QUALITY
+	veraendert worden sein; das sollte beachtet werden.
+
+SIEHE AUCH
+----------
+::
+
+	FindGroup(), FindGroupP(), P_FRIEND, P_NO_GLOBAL_ATTACK
+
+
+Last modified: Mon Jan 25 15:04:31 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/FindGroupP.rst b/doc/sphinx/lfun/FindGroupP.rst
new file mode 100644
index 0000000..6545e01
--- /dev/null
+++ b/doc/sphinx/lfun/FindGroupP.rst
@@ -0,0 +1,69 @@
+FindGroupP()
+============
+
+FUNKTION
+--------
+::
+
+	object*FindGroupP(object pl,int who,int pr);
+
+DEFINIERT IN
+------------
+::
+
+	/std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+	pl
+	  Lebewesen, von welchem die Freunde oder Feinde in der Umgebung
+	  gefunden werden sollen.
+	who
+	  Flag, welches anzeigt, ob Freunde oder Feinde gefunden werden
+	  sollen (Konstanten definiert in '/sys/new_skills.h'):
+	    FG_ENEMIES - (Wert -1) Feinde sollen gefunden werden
+	    FG_FRIENDS - (Wert  1) Freunde sollen gefunden werden
+	    FG_ALL     - (Wert  0) alle Lebewesen sollen gefunden werden
+	pr
+	  Wahrscheinlichkeit, mit der ein Lebewesen ausgesucht werden soll.
+	  Hierbei geht vorher noch das Skillattribute SA_EXTENSION ein!
+
+RUeCKGABEWERT
+-------------
+::
+
+	Array mit gefundenen Lebewesen
+
+BESCHREIBUNG
+------------
+::
+
+	Ausgesucht werden die Lebewesen genauso wie bei FindGroup(), nur
+	dass zum Schluss die einzelnen Lebewesen per Zufall ausgewaehlt
+	werden. Es ist also nicht gesichert, dass ueberhaupt ein Lebewesen
+	zurueckgeliefert wird, trotzdem welche gefunden wurden.
+
+BEISPIELE
+---------
+::
+
+	Man moechte im Schnitt 50% der Feinde finden, die man gleichzeitig
+	mit einem Spell belegt:
+	  enemyList=FindGroupP(caster,FG_ENEMIES,50);
+	Dies gilt jedoch nur bei SA_EXTENSION==100, sonst wird mit
+	dementsprechend mehr oder weniger Wahrscheinlichkeit zurueckgegeben.
+	 (also bei SA_EXTENSION==200 doppelt so viele -> 100%, also alle)
+	Das Skillattribute SA_EXTENSION kann auch durch SA_QUALITY
+	veraendert worden sein; das sollte beachtet werden.
+
+SIEHE AUCH
+----------
+::
+
+	FindGroup(), FindGroupP(), P_FRIEND, P_NO_GLOBAL_ATTACK
+
+
+Last modified: Mon Jan 25 15:04:31 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/FindNearEnemyVictim.rst b/doc/sphinx/lfun/FindNearEnemyVictim.rst
new file mode 100644
index 0000000..3af915e
--- /dev/null
+++ b/doc/sphinx/lfun/FindNearEnemyVictim.rst
@@ -0,0 +1,50 @@
+FindNearEnemyVictim()
+=====================
+
+FUNKTION
+--------
+::
+
+	object FindNearEnemyVictim(string wen, object pl, string msg)
+
+DEFINIERT IN
+------------
+::
+
+	/std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+	wen - id des gewuenschten Gegners, SelectNearEnemy falls n/a.
+	pl  - Caster.
+	msg - Nachricht falls Gegner nicht anwesend ist.
+
+BESCHREIBUNG
+------------
+::
+
+	Findet einen im Nahkampf erreichbaren Gegner,
+	z.B. fuer einen Angriffsspruch.
+
+	
+
+RUECKGABEWERT
+-------------
+::
+
+	Der Auserwaehlte :-)
+
+BEMERKUNGEN
+-----------
+::
+
+	Der Gegner wird auf jeden Fall angegriffen.
+
+SIEHE AUCH
+----------
+::
+
+	teams, FindEnemyVictim, FindFarEnemyVictim, FindDistantEnemyVictim
+
diff --git a/doc/sphinx/lfun/FindPotion.rst b/doc/sphinx/lfun/FindPotion.rst
new file mode 100644
index 0000000..834485f
--- /dev/null
+++ b/doc/sphinx/lfun/FindPotion.rst
@@ -0,0 +1,74 @@
+FindPotion()
+============
+
+FUNKTION
+--------
+::
+
+     varargs int FindPotion(string s);
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/potion.c
+
+ARGUMENTE
+---------
+::
+
+     string s
+       Ausgabetext. Wenn 0/Leerstring, wird Default verwendet.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion gibt einem aufrufenden Spieler eventuell diesen ZT.
+
+     
+
+     Das aufrufende Spielerobjekt muss dafuer:
+     * diesen ZT im Potionmaster in seiner Liste eingetragen haben
+     * diesen ZT in der Liste der bekannten Traenke haben (durch
+       Orakel also fuer ihn auch freigeschaltet)
+     * darf keine Playerkills haben (P_KILLS)
+     * darf nicht im Editiermodus sein
+     * darf kein Geist sein (Ausnahme: Geisterschloss)
+
+     Wenn alle Kriterien erfolgreich erfuellt sind, wird 's' oder 
+     "Du findest einen Zaubertrank, den Du sofort trinkst." ausgegeben
+     und dem Spieler ggf die Wahl der Attribute gegeben.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0 bei Nichtvergabe, 1 bei erfolgreicher Vergabe.
+
+BEISPIELE
+---------
+::
+
+     string detail_papiere() {
+       if (this_player()->FindPotion(
+         break_string("Beim Rumwuehlen in den Papieren entdeckst Du einen "
+                      "kleinen Zaubertrank, den Du sofort trinkst.", 78)))
+         return "";  
+         // Es muss ein String zurueckgegeben werden, da man sonst
+         // die Fehlermeldung "Sowas siehst du hier nicht." bekommt
+       else
+         return "Die Papiere sind alle unbeschriftet.\n";
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
+     Verwandt:  AddKnownPotion(), RemoveKnownPotion(), InList()
+     Props:     P_POTIONROOMS, P_KNOWN_POTIONROOMS
+     Befehl:    traenke (fuer Magier zum Einschalten des Findens von ZTs)
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/lfun/FindRangedTarget.rst b/doc/sphinx/lfun/FindRangedTarget.rst
new file mode 100644
index 0000000..93c9178
--- /dev/null
+++ b/doc/sphinx/lfun/FindRangedTarget.rst
@@ -0,0 +1,63 @@
+FindRangedTarget()
+==================
+
+FUNKTION
+--------
+::
+
+    static string FindRangedTarget(string str, mapping shoot)
+
+DEFINIERT IN
+------------
+::
+
+    /std/ranged_weapon.c
+
+ARGUMENTE
+---------
+::
+
+    string str    - Schusssyntax
+    mapping shoot - Schussdaten
+
+BESCHREIBUNG
+------------
+::
+
+    Erhaelt von /std/ranged_weapon::cmd_shoot() die Schussdaten und eine
+    eventuell bereits modifizierte Syntax und versucht einen passenden Gegner
+    im Raum oder im Gebiet (P_SHOOTING_AREA) zu finden.
+    Dieser wird in SI_ENEMY im Mapping 'shoot' eingetragen und ein Wert != 0
+    zurueckgegeben.
+
+RUECKGABEWERT
+-------------
+::
+
+    0     bei Fehlschlag
+    != 0  bei gueltigem SI_ENEMY in 'shoot'
+
+BEMERKUNGEN
+-----------
+::
+
+    'shoot' enthaelt normalerweise folgende Eintraege:
+    * Key P_WEAPON:       die Schusswaffe
+    * Key P_WEAPON_TYPE:  P_AMMUNITION, also die Munitions-ID
+    * Key P_STRETCH_TIME: P_STRETCH_TIME der Waffe
+    * Key P_WC:           P_SHOOTING_WC der Waffe
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
+    Methoden:  shoot_dam(L), cmd_shoot(L)
+    Gebiet:    P_RANGE, P_SHOOTING_AREA, P_TARGET_AREA
+    Team:      PresentPosition(L)
+    Suche:     present, SelectFarEnemy(L)
+    Syntax:    _unparsed_args(L)
+    Sonstiges: fernwaffen
+
+28.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/lfun/Flee.rst b/doc/sphinx/lfun/Flee.rst
new file mode 100644
index 0000000..a0ab6f7
--- /dev/null
+++ b/doc/sphinx/lfun/Flee.rst
@@ -0,0 +1,92 @@
+Flee()
+======
+
+FUNKTION
+--------
+::
+
+        public varargs void Flee( object oldenv, int force )
+
+DEFINIERT IN
+------------
+::
+
+        /sys/living/combat.h
+        /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+        oldenv
+          Ein Raum oder 0.
+          Wird ein Raum angegeben, dann muss sich der Fluechtende in diesem
+          Raum befinden, damit er versucht, zu fluechten, es sei denn, das
+          optionale Flag "force" ist gesetzt.
+        force
+          1, wenn der spieler unabhaengig von seiner Vorsicht fluechten soll.
+          0 sonst.
+
+BESCHREIBUNG
+------------
+::
+
+        Flee() wird im heart_beat() oder von CheckWimpyAndFlee() aufgerufen,
+        um den Spieler fluechten zu lassen. Man kann die Funktion im Spieler
+        auch "von Hand" aufrufen, beispielsweise in einem Spell. Man sollte
+        dann force auf 1 setzen, damit der Spieler unabhaengig von seiner
+        Vorsicht fluechtet.
+        Hierbei kann die Flucht dazu fuehren, dass man die Teamreihe wechselt,
+        aber auch, dass man den Raum verlaesst.
+
+        
+
+RUeCKGABEWERT
+-------------
+::
+
+        keiner
+
+BEMERKUNGEN
+-----------
+::
+
+BEISPIELE
+---------
+::
+
+        this_player()->Flee(0, 1);
+        // Der Spieler soll fluechten, egal, ob seine Lebenspunkte geringer
+        // als seine Vorsicht sind und unabhaengig von seiner Position.
+
+        
+
+        this_player()->Flee( find_object("/gilden/abenteurer") );
+        // Der Spieler soll fluechten, wenn er sich in der Abenteurergilde
+        // befindet (oder wenn diese nicht existiert)
+
+        
+
+        this_player()->Flee( "/gilden/abenteurer" );
+        // Der Spieler wird nicht fluechten, da der Vergleich von Dateiname
+        // und dem Raum 0 ergibt.
+
+        this_player()->Flee( find_object("/gilden/abenteurer"), 1);
+        // Der Spieler soll auf jeden Fall fluechten, egal ob er sich in der
+        // Abenteurergilde befindet oder nicht. Grund: Gesetztes force-Flag.
+
+        
+
+        
+
+        
+
+SIEHE AUCH
+----------
+::
+
+        CheckWimpyAndFlee(), Defend(), heart_beat(), 
+
+
+Last modified: Wed Nov 12 14:44:42 2003 by Bambi
+
diff --git a/doc/sphinx/lfun/FreeHands.rst b/doc/sphinx/lfun/FreeHands.rst
new file mode 100644
index 0000000..6c6e088
--- /dev/null
+++ b/doc/sphinx/lfun/FreeHands.rst
@@ -0,0 +1,60 @@
+FreeHands()
+===========
+
+FUNKTION
+--------
+::
+
+     public varargs int FreeHands(object ob)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+     ob - das Objekt, dessen Handnutzung vorbei ist
+        - kann 0 sein, dann wird PO benutzt
+
+RUECKGABEWERT
+-------------
+::
+
+     0, wenn kein Objekt uebergeben wurde oder kein PO existiert
+     1, sonst
+
+BESCHREIBUNG
+------------
+::
+
+     Befreit die Haende eines Livings von ein bestimmten Objekt.
+     Es werden _alle_ Haende wieder freigegeben.
+
+BEISPIELE
+---------
+::
+
+     > halte seil fest
+     ...
+     this_player()->UseHands(this_object(),2);
+     ...
+
+     > lasse seil los
+     ...
+     this_player()->FreeHands(this_object());
+     ...
+
+SIEHE AUCH
+----------
+::
+
+     P_HANDS, P_HANDS_USED_BY
+     P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
+     UseHands
+
+1.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/GetAquarium.rst b/doc/sphinx/lfun/GetAquarium.rst
new file mode 100644
index 0000000..bd4e13d
--- /dev/null
+++ b/doc/sphinx/lfun/GetAquarium.rst
@@ -0,0 +1,60 @@
+GetAquarium()
+=============
+
+FUNKTION
+--------
+::
+
+     varargs public string* GetAquarium(object angel)
+
+ARGUMENTE
+---------
+::
+
+     Das optionale Argument <angel> ist die Angel selbst.
+
+BESCHREIBUNG
+------------
+::
+
+     Die Funktion wird beim Angeln in Raeumen gerufen, wenn diese als 
+     Gewaessertyp W_USER gesetzt haben (siehe Manpage zu P_WATER).
+     Aus der zurueckgegebenen Liste der Pfade wird einer zufaellig aus-
+     gewaehlt und das Objekt geclont. 
+
+RUECKGABEWERT
+-------------
+::
+
+     String-Array mit Pfadnamen zu den in diesem Raum fangbaren Fischen.
+
+BEMERKUNG
+---------
+::
+
+     Man kann die Fangchancen durch Mehrfachnennung einzelner Eintraege 
+     modifizieren. Es muss sich bei den Eintraegen um lad- und clonebare
+     Objekte handeln.
+     Fuer selbstprogrammierte Fische ist das Basisobjekt 
+     /std/items/fishing/fish zu verwenden. Einige vorgefertigte Fische 
+     finden sich darueber hinaus in /items/fishing/aquarium/
+
+BEISPIEL
+--------
+::
+
+     varargs string* GetAquarium(object angel) {
+       return ({"/d/dschungel/rikus/q4e/obj/stichling",
+                "/d/dschungel/rikus/q4e/obj/karpfen",
+                "/p/seher/partymonster/obj/fisch"});
+     }
+
+SIEHE AUCH
+----------
+::
+
+    Properties: P_WATER, P_FISH
+
+
+zuletzt geaendert: 2014-Sep-02, Arathorn
+
diff --git a/doc/sphinx/lfun/GetDetail.rst b/doc/sphinx/lfun/GetDetail.rst
new file mode 100644
index 0000000..2f75779
--- /dev/null
+++ b/doc/sphinx/lfun/GetDetail.rst
@@ -0,0 +1,90 @@
+GetDetail()
+===========
+
+FUNKTION
+--------
+::
+
+    varargs string GetDetail(string key, string race, int sense)
+
+DEFINIERT IN
+------------
+::
+
+    /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+    key
+      Das zu ermittelnde Detail.
+    race
+      Rasse des ermittelnden Objektes (falls es ein Lebewesen ist).
+    sense
+      Die Art des zu untersuchenden Details:
+        Untersuchen, Riechen, Hoeren, Tasten.
+
+BESCHREIBUNG
+------------
+::
+
+    Die Beschreibung des gewuenschten Details wird ermittelt. Dabei
+    werden rassenspezifische Details beruecksichtigt. Es gibt hierbei
+    verschiedene Detailarten, deren Typ man in <sense> angibt:
+      SENSE_VIEW    - Fuer Defaultdetails zum Untersuchen.
+      SENSE_SMELL   - Fuer Details, die man riechen kann.
+      SENSE_SOUND   - Fuer Details, die man hoeren kann.
+      SENSE_TOUCH   - Fuer Details, die man abtasten kann.
+      SENSE_READ    - Fuer Details, die man lesen kann.
+
+    Dabei ist 0 == SENSE_VIEW.
+
+RUeCKGABEWERT
+-------------
+::
+
+    Die Beschreibung des Details oder 0, wenn es dieses Detail nicht
+    gibt.
+
+BEISPIEL
+--------
+::
+
+    Im folgenden wird ein kleines Testdetail generiert:
+      AddDetail("test","Das ist ein Test!\n");
+    Im folgenden wird das Detail entfernt, wenn es existiert. Dies ist
+    eigentlich nicht noetig, da RemoveDetail() damit zurechtkommt, aber
+    eventuell sind ja noch weitere Aktionen noetig.
+      if(GetDetail("test"))
+      { RemoveDetail("test");
+        ...
+      }
+    Ein Geruch kann man folgendermassen erzeugen:
+      AddSmells("gold",
+        ([0      :"Gold kann man nicht riechen!\n",
+          "zwerg":"Deine trainierte Nase riecht es muehelos!\n"]));
+    Die Abfrage des Details gestaltet sich recht einfach:
+      GetDetail("gold","zwerg",SENSE_SMELL);
+    Die Funktion liefert das Detail fuer den Zwerg.
+      GetDetail("gold",0,SENSE_SMELL);
+    Die Funktion liefert das Detail fuer die restlichen Rassen.
+      GetDetail("gold",0,SENSE_SOUND);
+    Ein Sounddetail mit dem Namen "gold" existiert nicht, die Funktion
+    liefert 0 zurueck.
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+               AddTouchDetail()
+    Loeschen:  RemoveReadDetail(), RemoveSmells(), RemoveDetail(),
+               RemoveSounds(), RemoveTouchDetail()
+    Daten:     P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS,
+               P_TOUCH_DETAILS, P_SPECIAL_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+    Sonstiges: break_string()
+
+27. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/lfun/GetDoorsMapping.rst b/doc/sphinx/lfun/GetDoorsMapping.rst
new file mode 100644
index 0000000..2a6d920
--- /dev/null
+++ b/doc/sphinx/lfun/GetDoorsMapping.rst
@@ -0,0 +1,46 @@
+GetDoorsMapping()
+=================
+
+FUNKTION
+--------
+::
+
+    mapping GetDoorsMapping()
+
+BESCHREIBUNG
+------------
+::
+
+    Mit dieser Funktion erhaelt man das Mapping der vorhandenen
+    Seherportale.
+
+    
+
+    Die Struktur ist von der Form: 
+	([ Pfad: Portalnummer; Portalbeschreibung, ])
+    Es wird eine Kopie dieses Mappings geliefert.
+
+RUECKGABEWERT
+-------------
+::
+
+    Das Sehertormapping
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
+
+BEISPIELE
+---------
+::
+
+    "/d/seher/portale/sehertormaster"->GetDoorsMapping();
+
+SIEHE AUCH
+----------
+::
+
+    DoorIsKnown, ShowDoors, Teleport, DiscoverDoor
+
diff --git a/doc/sphinx/lfun/GetEnemies.rst b/doc/sphinx/lfun/GetEnemies.rst
new file mode 100644
index 0000000..fbd9f6b
--- /dev/null
+++ b/doc/sphinx/lfun/GetEnemies.rst
@@ -0,0 +1,54 @@
+GetEnemies()
+============
+
+FUNKTION
+--------
+::
+
+	mapping GetEnemies();
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+	keine
+
+RUeCKGABEWERT
+-------------
+::
+
+	Mapping mit bekannten Gegnern als Schluessel und Zeiten als
+	Eintraegen.
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Funktion liefert das interne Mapping zurueck, in dem alle
+	Gegner abgespeichert sind. Diese Gegner stellen die Schluessel in
+	dem Mapping dar. Als Eintraege sind die Zeiten vermerkt, nach
+	welcher Zeit ein Gegner automatisch wieder vergessen werden soll.
+	Mehr Informationen dazu sind in der Dokumentation zur aehnlich
+	gearteten Funktion QueryEnemies() zu finden, die jedoch zwei Arrays
+	getrennte zurueckliefert.
+	Achtung: Es wird keine Kopie des Mappings erstellt. Saemtliche
+	Veraenderungen in dem Mapping wirken sich unmittelbar auf die
+	interne Gegnerliste aus. Die Funktion sollte deshalb nicht genutzt
+	werden. Gegner ein- und austragen sollte man nur mittels
+	InsertEnemy() und StopHuntFor().
+
+SIEHE AUCH
+----------
+::
+
+	QueryEnemies(), SetEnemies(), InsertEnemy(), StopHuntFor()
+
+
+Last modified: Wed May 26 16:47:51 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/GetExits.rst b/doc/sphinx/lfun/GetExits.rst
new file mode 100644
index 0000000..583283d
--- /dev/null
+++ b/doc/sphinx/lfun/GetExits.rst
@@ -0,0 +1,46 @@
+GetExits()
+==========
+
+FUNKTION
+--------
+::
+
+     varargs string GetExits(object viewer);
+
+DEFINIERT IN
+------------
+::
+
+     /std/room/exits
+
+ARGUMENTE
+---------
+::
+
+     viewer
+          Derjenige, der sich die Ausgaenge anschaut.
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird eine Liste der fuer viewer sichtbaren Ausgaenge erstellt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     String mit der Liste der sichtbaren Ausgaenge.
+
+SIEHE AUCH
+----------
+::
+
+     AddExit(), AddSpecialExit(), GetExits(),
+     RemoveExit(), RemoveSpecialExit(),
+     GuardExit(),
+     H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
+     ausgaenge
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/GetFValue.rst b/doc/sphinx/lfun/GetFValue.rst
new file mode 100644
index 0000000..cc872d0
--- /dev/null
+++ b/doc/sphinx/lfun/GetFValue.rst
@@ -0,0 +1,47 @@
+GetFValue()
+===========
+
+FUNKTION
+--------
+::
+
+	varargs int GetFValue(string vname, mapping map, object pl) 
+
+ARGUMENTE
+---------
+::
+
+	vname	: name des parameters aus dem spellmapping
+	map   	: spellmapping
+	pl 	: caster
+
+BESCHREIBUNG
+------------
+::
+
+	Berechnet den Wert und den Factor des Parameters in spellmapping.
+
+RUECKGABEWERT
+-------------
+::
+
+	Berechneter Wert*Factor aus dem Spellmapping.
+
+BEMERKUNGEN
+-----------
+::
+
+	Ruft GetValue(vname,map,pl)*GetFactor(vname,map,pl)/100 auf.
+
+BEISPIEL
+--------
+::
+
+	xxx=GetFValue(SI_SKILLDAMAGE,sinfo,caster);
+
+Siehe auch:
+
+	"GetValue", "GetFactor", "GetOffset", "GetValueO", "GetFValueO"
+
+	Ausfuehrliches Beispiel siehe "GetFValueO".
+
diff --git a/doc/sphinx/lfun/GetFValueO.rst b/doc/sphinx/lfun/GetFValueO.rst
new file mode 100644
index 0000000..a2553a9
--- /dev/null
+++ b/doc/sphinx/lfun/GetFValueO.rst
@@ -0,0 +1,85 @@
+GetFValueO()
+============
+
+FUNKTION
+--------
+::
+
+	varargs int GetFValueO(string vname, mapping map, object pl) 
+
+ARGUMENTE
+---------
+::
+
+	vname	: name des parameters aus dem spellmapping
+	map   	: spellmapping
+	pl 	: caster
+
+BESCHREIBUNG
+------------
+::
+
+	'Berechnet' den Wert, den Factor und den Offset des Parameters 
+	in spellmapping.
+
+RUECKGABEWERT
+-------------
+::
+
+	Berechneter (Wert*Factor)/100+Offset aus dem Spellmapping.
+
+BEMERKUNGEN
+-----------
+::
+
+	Ruft (GetValue(vname,map,pl)*GetFactor(vname,map,pl))/100+
+	GetOffset(vname,map,pl) auf.
+
+BEISPIEL
+--------
+::
+
+	AddSpell("egal",10,
+	([
+	OFFSET(SI_COST):([SM_RACE:(["Zwerg":4]) ]),
+	FACTOR(SI_COST):([SM_RACE:(["Mensch":90]) ]),
+	SI_SKILLDAMAGE:100,
+	OFFSET(SI_SKILLDAMAGE):25,
+	SI_SKILLDAMAGE_TYPE:DT_EXAMPLE,
+	FACTOR(SI_SKILLDAMAGE):([SM_RACE:(["Zwerg":80,"Elf":120]) ]) 
+	]));
+
+	So, was sollen uns diese Zeilen sagen?
+
+	Es wird ein Spruch Names 'egal' ins Spellbook eingetragen. Er kostet
+	regulaer 10 MP. Fuer Zwerge allerdings wird ein Offset von 4 MP 
+	aufgeschlagen. Ausserdem machen Zwerge nur 80% Schaden, Elfen 
+	hingegen 120%. Der Grundschaden betraegt 100 Schadenspunkte, der 
+	Offset des Schadens nochmal 25. Menschen bezahlen fuer diesen 
+	Spruch nur 90% der Kosten.
+
+	Nun die Rechenbeispiele:
+
+	Fuer die Kosten:
+		Value	ValueO	FValue	FValueO
+	Mensch	   10	    10	     9	      9
+	Elf   	   10	    10	    10       10
+	Hobbit	   10	    10	    10	     10
+	Zwerg	   10	    14	    10	     14
+
+	Fuer den Schaden:
+			Value	ValueO	FValue	FValueO
+	Mensch		100	125	100	125
+	Elf  		100	125	120	150
+	Hobbit		100	125	100	125
+	Zwerg		100	125	 80	100
+
+	An diesem Beispiel sieht man deutlich, wie man mit ein paar 
+	Offsets und Faktoren die Wirkung eines Spruches deutlich 
+	veraendern kann. Es sollte bei eigenen Berechnungen immer 
+	GetFValueO benutzt werden.
+
+Siehe auch:
+
+	"GetValue", "GetFactor", "GetOffset", "GetFValue", "GetValueO"
+
diff --git a/doc/sphinx/lfun/GetFactor.rst b/doc/sphinx/lfun/GetFactor.rst
new file mode 100644
index 0000000..80fef53
--- /dev/null
+++ b/doc/sphinx/lfun/GetFactor.rst
@@ -0,0 +1,48 @@
+GetFactor()
+===========
+
+FUNKTION
+--------
+::
+
+	varargs int GetFactor(string vname, mapping map, object pl) 
+
+ARGUMENTE
+---------
+::
+
+	vname	: name des parameters aus dem spellmapping
+	map   	: spellmapping
+	pl 	: caster
+
+BESCHREIBUNG
+------------
+::
+
+	'Berechnet' den Factor des Parameters in spellmapping.
+
+RUECKGABEWERT
+-------------
+::
+
+	Berechneter Factor aus dem Spellmapping.
+
+BEMERKUNGEN
+-----------
+::
+
+	Beschraekung auf 10-1000. Werte groesser oder kleiner als diese
+	werden 'abgeschnitten'.
+
+BEISPIEL
+--------
+::
+
+	xxx=GetFactor(SI_SKILLDAMAGE,sinfo,caster);
+
+Siehe auch:
+
+	"GetValue", "GetOffset", "GetFValue", "GetValueO", "GetFValueO"
+
+	Ausfuehrliches Beispiel siehe "GetFValueO".
+
diff --git a/doc/sphinx/lfun/GetGroupMembers.rst b/doc/sphinx/lfun/GetGroupMembers.rst
new file mode 100644
index 0000000..f5ebfcc
--- /dev/null
+++ b/doc/sphinx/lfun/GetGroupMembers.rst
@@ -0,0 +1,60 @@
+GetGroupMembers()
+=================
+
+FUNKTION
+--------
+::
+
+     string *GetGroupMembers(string grp)
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/materialdb.c (MATERIALDB)
+
+ARGUMENTE
+---------
+::
+
+     string grp - Gruppenname
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt alle dieser Gruppe zugehoerigen Materialien zurueck. Dazu gut, sich
+     einen Ueberblick ueber die aktuelle Liste zu verschaffen.
+
+RUECKGABEWERT
+-------------
+::
+
+     Array von Strings mit Materialien oder ({})
+
+BEISPIELE
+---------
+::
+
+     // wir wollen irgend ein Metall haben, nennen dies aber beim Namen
+     int ind;
+     string* likeit;
+     likeit=MATERIALDB->GetGroupMembers(MATGROUP_METAL);
+     ind=random(sizeof(likeit));
+     ...
+     write("Der Schmied sagt: Mir fehlt noch "+
+	   MATERIALDB->MaterialName(likeit[ind], WER, 100)+".\n");
+     ...
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Master:	  AddMaterial(), ConvMaterialList(), MaterialGroup(),
+		  GroupName(), MaterialName(),
+		  GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/GetInfoArr.rst b/doc/sphinx/lfun/GetInfoArr.rst
new file mode 100644
index 0000000..dd21cb6
--- /dev/null
+++ b/doc/sphinx/lfun/GetInfoArr.rst
@@ -0,0 +1,55 @@
+GetInfoArr()
+============
+
+FUNKTION
+--------
+::
+
+     static mixed *GetInfoArr(string str)
+
+DEFINIERT IN
+------------
+::
+
+     /std/npc/info.c
+
+ARGUMENTE
+---------
+::
+
+     string str	 - Schluesselwort der Frage
+
+BESCHREIBUNG
+------------
+::
+
+     Sucht nach einem Schluesselwort in den abgelegten Antworten
+     und gibt die Informationen oder einen 0er-Array zurueck.
+
+BEMERKUNGEN
+-----------
+::
+
+     Ueberschreibbar :)
+
+RUECKGABEWERT
+-------------
+::
+
+     Siehe Parameter von AddInfo:
+
+     Array mit:
+     ({ <Infostring> (0 fuer keine Antwort),
+        <Indent-String> (Default: 0),
+        <Silent> (Default: 0),
+        <Casebased> (Default: 0)
+     })
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt: AddInfo, do_frage
+
+31.Mar 2007 Gloinson
+
diff --git a/doc/sphinx/lfun/GetMatMembership.rst b/doc/sphinx/lfun/GetMatMembership.rst
new file mode 100644
index 0000000..8fe36a7
--- /dev/null
+++ b/doc/sphinx/lfun/GetMatMembership.rst
@@ -0,0 +1,79 @@
+GetMatMembership()
+==================
+
+FUNKTION
+--------
+::
+
+     string *GetMatMembership(string mat)
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/materialdb.c (MATERIALDB)
+
+ARGUMENTE
+---------
+::
+
+     string mat - ein Material
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt alle Gruppen, denen das Material angehoert zurueck. Geeignet, um
+     die Eigenschaften eines Materials zu ueberpruefen.
+
+RUECKGABEWERT
+-------------
+::
+
+     Array von Strings mit Materialiengruppen oder ({})
+
+BEISPIELE
+---------
+::
+
+     // ein weiser Schmied:
+     int i;
+     string *mat, mname, mgroup;
+     mat=m_indices(ob->QueryProp(P_MATERIAL));
+     i=sizeof(mat);
+
+     write("Der Schmied sagt: "+ob->Name(WER)+" besteht aus ...\n");
+     while(i--) {
+      // den Namen erkennen/aussprechen:
+      // Materialien werden allgemein etwas besser erkannt (zu 5%), aber
+      // alles aus Metall wird zu +100% besser erkannt ...
+      mname=MATERIALDB->MaterialName(mat[i], WER,
+	     ({5, ([MATRGROUP_METAL, 100])}));
+
+      // und nur Metalle analysieren ...
+      if(MATERIALDB->MaterialGroup(([mat[i]:100]),MATGROUP_METAL)>=100) {
+       int j;
+       string *mgr;
+       mgr=MATERIALDB->GetMatMembership(mat[i]);
+       j=sizeof(mgr);
+       mgroup=" gehoert zu ";
+       while(j--) {
+        mgroup+=MATERIALDB->GroupName(mgr[j]);
+        if(j>0) mgroup+=", ";
+       }
+      } else mgroup=" kenne ich nicht";
+      printf("%-12.12s: %s\n",mname, mgroup);
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Master:	  AddMaterial(), ConvMaterialList(), MaterialGroup(),
+		  GroupName(), MaterialName(),
+		  GetGroupMembers()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/GetOffset.rst b/doc/sphinx/lfun/GetOffset.rst
new file mode 100644
index 0000000..2aa2b70
--- /dev/null
+++ b/doc/sphinx/lfun/GetOffset.rst
@@ -0,0 +1,49 @@
+GetOffset()
+===========
+
+FUNKTION
+--------
+::
+
+	varargs int GetOffset(string vname, mapping map, object pl) 
+
+ARGUMENTE
+---------
+::
+
+	vname	: name des parameters aus dem spellmapping
+	map   	: spellmapping
+	pl 	: caster
+
+BESCHREIBUNG
+------------
+::
+
+	'Berechnet' den Offset des Parameters in spellmapping.
+
+RUECKGABEWERT
+-------------
+::
+
+	Berechneter Offset aus dem Spellmapping.
+
+BEMERKUNGEN
+-----------
+::
+
+	Beschraekung auf -10000 bis +10000. Werte groesser oder kleiner 
+	als diese werden 'abgeschnitten'. Mehr als 100% Bonus oder Malus
+	gibts nicht ;-).
+
+BEISPIEL
+--------
+::
+
+	xxx=GetOffset(SI_SKILLDAMAGE,sinfo,caster);
+
+Siehe auch:
+
+	"GetValue", "GetFactor", "GetFValue", "GetValueO", "GetFValueO"
+
+	Ausfuehrliches Beispiel siehe "GetFValueO".
+
diff --git a/doc/sphinx/lfun/GetOwner.rst b/doc/sphinx/lfun/GetOwner.rst
new file mode 100644
index 0000000..2d8bd73
--- /dev/null
+++ b/doc/sphinx/lfun/GetOwner.rst
@@ -0,0 +1,38 @@
+GetOwner()
+==========
+
+GetOwner(L)
+-----------
+::
+
+FUNKTION
+--------
+::
+
+     string GetOwner();
+
+BESCHREIBUNG
+------------
+::
+
+     Wird vom Hoerrohr gerufen:
+      /d/inseln/shakedbeer/shakyisland/obj/hoerrohr.c
+     und kann einen Besitzer der Dateien zurueckgeben, der vom Besitzer
+     der Pfade in denen die Datei liegt abweicht.
+
+BEISPIELE
+---------
+::
+
+     string GetOwner() {
+      return "Tiamak";
+     }
+
+SIEHE AUCH
+----------
+::
+
+     P_INFO
+
+11. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/GetPhiolenInfos.rst b/doc/sphinx/lfun/GetPhiolenInfos.rst
new file mode 100644
index 0000000..488431d
--- /dev/null
+++ b/doc/sphinx/lfun/GetPhiolenInfos.rst
@@ -0,0 +1,124 @@
+GetPhiolenInfos()
+=================
+
+GetPhiolenInfos(L)
+------------------
+::
+
+FUNKTION
+--------
+::
+
+     mixed *GetPhiolenInfos();
+
+BESCHREIBUNG
+------------
+::
+
+     Wird von der Phiole aufgerufen:
+     /d/inseln/miril/sternquest/obj/phiole.c
+     Der Raum muss /p/service/miril/phiole.h includen.     
+     Mit der Phiole kann ein Spieler durch Tueren schauen. Bei Tueren, die
+     vom Doormaster (/obj/doormaster.c) verwaltet werden, klappt dies auto-
+     matisch. Moechte man das verbieten, so muss die Funktion 
+     GetPhiolenInfos() im entsprechenden Raum definiert sein.
+     Befinden sich Tueren im Raum, die nicht vom Doormaster verwaltet werden,
+     aber bei denen die Phiole funktionieren soll, so kann dies ebenfalls
+     mittels GetPhiolenInfos() geschehen.
+
+     
+
+     Funktion der Phiole:
+     Sie projiziert ein Bild dessen, was hinter der Tuer liegt auf die Tuer.
+     Steht die Tuer offen, so sieht der Spieler nur eine Wand, denn es wird
+     gezeigt, was hinter dieser Tuer ist.
+
+     
+
+     Ist die Tuer jedoch ge- oder verschlossen, so sieht er auf der Tuer
+     die Langbeschreibung des Raumes, der hinter der Tuer liegt, sowie das
+     Inventar dieses Raumes. 
+
+     Aufbau der Funktion:
+     mixed *GetPhiolenInfos() {
+       return ({
+                ([
+                  PHIOLE_DEST:     string,       
+                  PHIOLE_IDS:      *string,             
+                  PHIOLE_GENDER:   int,           
+                  PHIOLE_STATUS:   int,     (optional)
+                  PHIOLE_LONG:     string,  (optional)
+                  PHIOLE_VERBOTEN: int      (optional)
+                ]),
+                ([
+                  ... Naechste Tuer
+                ])
+              });
+     }
+
+     
+
+     PHIOLE_DEST      Dateiname des Zielraums
+     PHIOLE_IDS	      Array der Strings, mit denen sich die Tuer 
+                      ansprechen laesst
+     PHIOLE_GENDER    Geschlecht der Tuer
+     PHIOLE_STATUS    aktueller Status der Tuer:
+                      0 geschlossen/verschlossen, 1 offen
+                      Bei Tueren, die mit NewDoor erzeugt wurden
+                      nicht setzen
+     PHIOLE_LONG      Beschreibung des Zielraums (z.B. bei einer 
+                      Faketuer)
+     PHIOLE_VERBOTEN  0 erlaubt, 1 verboten
+
+BEISPIEL
+--------
+::
+
+     Ein Raum enthaelt eine Holztuer und ein Portal. Erstere ist mittels 
+     NewDoor(...) gebaut, soll aber nicht zu durchschauen sein, letztere ist 
+     selbstgestrickt. Die erste fuehrt in den Workroom von Jof, die zweite
+     ist nur ein Fake und immer geschlossen. Bei vom Doormaster erzeugten 
+     Tueren sollte PHIOLE_STATUS nicht gesetzt werden, da dies automatisch
+     abgefragt wird.
+
+     
+
+     #include "/p/service/miril/phiole.h"
+     ...
+     mixed *GetPhiolenInfos(){
+       return ({
+                ([
+                  PHIOLE_DEST:"/players/jof/workroom",
+                  PHIOLE_IDS:({"holztuer"}),           
+                  PHIOLE_GENDER:FEMALE,                    
+                  PHIOLE_VERBOTEN:1          
+                ]),
+                ([
+                  PHIOLE_DEST:0,
+                  PHIOLE_IDS:({"portal"}),           
+                  PHIOLE_GENDER:NEUTER, 
+                  PHIOLE_STATUS:0,
+                  PHIOLE_LONG:"Du stehst in einer riesigen Schatzkammer und "
+                              "kannst Dein Glueck kaum fassen. Nun brauchst "
+                              "Du nur noch zuzugreifen und bist der reichste "
+                              "Bewohner des MorgenGrauen.",
+                  PHIOLE_VERBOTEN:0
+                ])
+              });
+      }
+      Mittels PHIOLE_LONG laesst sich auch bei erlaubten und verbotenen Tueren 
+      einstellen, was der Spieler statt der normalen Raumbeschreibung und den 
+      im Raum befindlichen Objekten sehen soll. Das koennte z.B. sinnvoll 
+      sein, falls der Spieler zwar die Raumbeschreibung, aber nicht den fiesen 
+      Drachen sehen soll, der sich ebenfalls im Raum befindet.
+
+      
+
+SIEHE AUCH
+----------
+::
+
+      NewDoor(), QueryDoorStatus(), SetDoorStatus(), QueryAllDoors()
+
+Letzte Aenderung: Sam, 14. Jan 2006, 12:21, Miril
+
diff --git a/doc/sphinx/lfun/GetReputation.rst b/doc/sphinx/lfun/GetReputation.rst
new file mode 100644
index 0000000..0d3e3a9
--- /dev/null
+++ b/doc/sphinx/lfun/GetReputation.rst
@@ -0,0 +1,53 @@
+GetReputation()
+===============
+
+FUNKTION
+--------
+::
+
+     public int GetReputation(string repid)
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/reputation.c
+
+ARGUMENTE
+---------
+::
+
+     repid
+       Eindeutige ID der angefragten Reputation.
+
+BESCHREIBUNG
+------------
+::
+
+     Liefert den aktuellen Wert der angegebenen Reputation <repid> zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Zahlenwert, Integer.
+
+BEISPIELE
+---------
+::
+
+     s. reputation
+
+SIEHE AUCH
+----------
+::
+
+     reputation
+     ChangeReputation(), GetReputations()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+06.04.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/GetReputations.rst b/doc/sphinx/lfun/GetReputations.rst
new file mode 100644
index 0000000..f3bc764
--- /dev/null
+++ b/doc/sphinx/lfun/GetReputations.rst
@@ -0,0 +1,47 @@
+GetReputations()
+================
+
+FUNKTION
+--------
+::
+
+     public mapping GetReputations()
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/reputation.c
+
+BESCHREIBUNG
+------------
+::
+
+     Liefert ein Mapping aller im Spieler gespeicherten Reputationen und ihrer
+     Werte zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Mapping ([(string)repid: (int)wert])
+
+BEISPIELE
+---------
+::
+
+     s. repuation
+
+SIEHE AUCH
+----------
+::
+
+     reputation
+     GetReputation(), GetReputations()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+06.04.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/GetValue.rst b/doc/sphinx/lfun/GetValue.rst
new file mode 100644
index 0000000..8acb009
--- /dev/null
+++ b/doc/sphinx/lfun/GetValue.rst
@@ -0,0 +1,48 @@
+GetValue()
+==========
+
+FUNKTION
+--------
+::
+
+	varargs int GetValue(string vname, mapping map, object pl) 
+
+ARGUMENTE
+---------
+::
+
+	vname	: name des parameters aus dem spellmapping
+	map   	: spellmapping
+	pl 	: caster
+
+BESCHREIBUNG
+------------
+::
+
+	'Berechnet' den Wert des uebergebenen Parameters aus dem 
+	Spellmapping.
+
+RUECKGABEWERT
+-------------
+::
+
+	Berechneter Wert aus dem Spellmapping.
+
+BEMERKUNGEN
+-----------
+::
+
+	
+
+BEISPIEL
+--------
+::
+
+	xxx=GetValue(SI_SKILLDAMAGE,sinfo,caster);
+
+Siehe auch:
+
+	"GetFactor", "GetOffset", "GetFValue", "GetValueO", "GetFValueO"
+
+	Ausfuehrliches Beispiel siehe "GetFValueO".
+
diff --git a/doc/sphinx/lfun/GetValueO.rst b/doc/sphinx/lfun/GetValueO.rst
new file mode 100644
index 0000000..3b75f8d
--- /dev/null
+++ b/doc/sphinx/lfun/GetValueO.rst
@@ -0,0 +1,47 @@
+GetValueO()
+===========
+
+FUNKTION
+--------
+::
+
+	varargs int GetValueO(string vname, mapping map, object pl) 
+
+ARGUMENTE
+---------
+::
+
+	vname	: name des parameters aus dem spellmapping
+	map   	: spellmapping
+	pl 	: caster
+
+BESCHREIBUNG
+------------
+::
+
+	Berechnet den Wert und den Offset des Parameters in spellmapping.
+
+RUECKGABEWERT
+-------------
+::
+
+	Berechneter Wert+Offset aus dem Spellmapping.
+
+BEMERKUNGEN
+-----------
+::
+
+	Ruft GetValue(vname,map,pl)+GetOffset(vname,map,pl) auf.
+
+BEISPIEL
+--------
+::
+
+	xxx=GetValueO(SI_SKILLDAMAGE,sinfo,caster);
+
+Siehe auch:
+
+	"GetValue", "GetFactor", "GetOffset", "GetFValue", "GetFValueO"
+
+	Ausfuehrliches Beispiel siehe "GetFValueO".
+
diff --git a/doc/sphinx/lfun/Gildenproperties.rst b/doc/sphinx/lfun/Gildenproperties.rst
new file mode 100644
index 0000000..5b658e0
--- /dev/null
+++ b/doc/sphinx/lfun/Gildenproperties.rst
@@ -0,0 +1,136 @@
+Gildenproperties()
+==================
+
+Name			Beschreibung
+
+P_GUILD_SKILLS		Property fuer Skills in der Gilde
+P_GUILD_RESTRICTIONS 	Restriktionen fuer den Eintritt in die Gilde
+P_GUILD_DEFAULT_SPELLBOOK  
+P_GUILD_MALE_TITLES 	Maennliche Gildentitel
+P_GUILD_FEMALE_TITLES	Weibliche Gildentitel
+P_GUILD_LEVELS		Gildenstufen
+P_SB_SPELLS 		Property fuer Spells in Spellbook
+P_GLOBAL_SKILLPROPS	Properties der Gilde UND des Spellbooks
+
+Properties des Spielers
+P_GUILD			String mit dem Namen der Gilde
+P_GUILD_LEVEL		Gildenstufe
+P_GUILD_TITLE		Gildentitel
+P_GUILD_RATING		Rating in der Gilde
+P_NEWSKILLS		mapping mit Skills und Spells
+P_NEXT_SPELL_TIME	Zeit bis der naechste Spell gesprochen werden kann
+P_TMP_ATTACK_HOOK	Angriffs-Ersatzfunktion
+P_TMP_ATTACK_MOD	Angriffs-Modifizierung
+P_TMP_DEFEND_HOOK	Abwehr-Ersatzfunktion
+P_TMP_DIE_HOOK		"Die"-Ersatzfunktion
+P_TMP_MOVE_HOOK		Bewegungs-Ersatzfunktion
+P_DEFENDERS		Verteidiger
+P_PREPARED_SPELL	Vorbereiteter Spell
+P_DEFAULT_GUILD		Standardgilde
+P_MAGIC_RESISTANCE_OFFSET Offset fuer Magie-Resistenzen
+
+Standard-Skills
+SK_FIGHT		Kampfskill(global)
+SK_SWORDFIGHTING	Schwertkampf
+SK_WEAPONLESS		Waffenloser Kampf
+SK_TWOHANDED       	Zweihandkampf
+SK_CASTING         	Zauber-Skill
+SK_MAGIC_ATTACK    	Magischer Angriff
+SK_MAGIC_DEFENSE   	Magische Abwehr
+SK_NIGHTVISION     	Nachtsicht
+SK_BOOZE           	Sauf-Skill
+SK_INFORM_DEFEND   	
+SK_DEFEND_OTHER		
+SK_CARRY		Trage-Skill
+SK_SPELL_DEFEND		Spruch-Abwehr
+
+Skill-Attribute
+P_SKILL_ATTRIBUTES	Property fuer Skill-Attribute
+P_SKILL_ATTRIBUTE_OFFSETS   Property fuer Offsets der Skill-Attribute
+SA_QUALITY		Allgemeine Qualitaet
+SA_DAMAGE		Schaden
+SA_SPEED		Geschwindigkeit
+SA_DURATION		Dauer
+SA_EXTENSION		Ausdehnung
+SA_RANGE		Reichweit
+SA_ENEMY_SAVE identisch zu SA_SPELL_PENETRATION (OBSOLET!)
+SA_SPELL_PENETRATION Chance des _Casters_, einen Spell durch ein
+                      P_NOMAGIC durchzukriegen.
+
+Skill-Info
+FACTOR(x)		Faktor
+OFFSET(x)		Offset
+SI_SKILLFUNC		Funktion, die aufgerufen wird
+SI_CLOSURE		Intern (Geschwindigkeitsoptimierung)
+SI_SPELLBOOK		Spellbook, in dem der Spell steht
+SI_SPELLCOST		Kosten des Spells
+SI_TIME_MSG		Die Meldung wird anstelle von "Du bist noch zu 
+			erschoepft von Deinem letzten Spruch." ausgegeben.
+SI_SP_LOW_MSG		Die Meldung wird anstelle von "Du hast zu wenig 
+			Zauberpunkte fuer diesen Spruch." ausgegeben.
+SI_NOMAGIC		Prozentwert, mit dem P_NOMAGIC mgangen werden kann
+SI_SPELLFATIGUE		Erschoepfung - Zeit, in der keine weiteren Spells
+			aufgerufen werden koennen
+SI_SKILLLEARN		Lerngeschwindigkeit in 0.01% pro A_INT/2
+SI_SKILLABILITY		Faehigkeit, diesen Spruch zu benutzen
+SI_SKILLARG		Argumente, die uebergeben wurden
+SI_SKILLRESTR_USE	Beschraenkungen beim Gebrauch
+SI_SKILLRESTR_LEARN	Beschraenkungen beim Lernen
+SI_SKILLINFO		Kurzer Informationstext
+SI_SKILLINFO_LONG	Langer Informationstext
+SI_SKILLDAMAGE		Schaden
+SI_SKILLDAMAGE_TYPE	Art des Schadens
+SI_SKILLDAMAGE_MSG	Meldung die anstelle einer Waffe kommen soll
+SI_SKILLDAMAGE_MSG2	dito fuer den Text fuer andere im Raum
+SI_SPELL		Spell, mit dem angegriffen wurde
+SI_INHERIT		Skill, von dem etwas uebernommen werden soll
+SI_DIFFICULTY		Wert, der die Obergrenze der Faehigkeit abgrenzt
+SI_LASTLIGHT		Fuer Nachtsicht Wann hat der Spieler zum letzten 
+			mal Licht gesehen.
+SI_SKILLHEAL		Heilung
+SI_USR			selbst definierte Infos
+SI_GUILD		Gilde, falls Auswahl aus mehreren moeglich
+SI_ENEMY		Feind bei Kampfspruechen
+SI_FRIEND		Der zu verteidigende Freund bei DefendOther 
+			und InformDefend
+SI_MAGIC_TYPE		Von was fuer einer Art ist die Magie (s.u.)
+SI_PREPARE_TIME		Zeit die zur Vorbereitung benoetigt wird.
+SI_ATTACK_BUSY_MSG	Meldung, wenn der Spieler zu beschaeftigt ist
+SI_NO_ATTACK_BUSY	Wenn der Spell nicht als Taetigkeit zaehlen/gezaehlt 
+			werden soll, kann man hier 
+			NO_ATTACK_BUSY[_SET|_QUERY] setzen
+SP_NAME			Name des Spells, falls Mapping
+SP_SHOW_DAMAGE		Treffermeldung soll gezeigt werden.
+SP_REDUCE_ARMOUR	AC soll Typabhaengig reduziert werden.
+SP_PHYSICAL_ATTACK	Koerperlicher Angriff
+SP_RECURSIVE		Rekursionen
+
+Skill-Restrictions
+SR_FUN			Funktion, die weitere Einschraenkungen prueft
+SR_EXCLUDE_RACE		Ausgeschlossene Rassen
+SR_INCLUDE_RACE		Eingeschlossene Rassen
+SR_GOOD			Align < 
+SR_BAD			Align >
+SR_FREE_HANDS		Benoetigte freie Haende
+SR_SEER			Muss Seher sein
+SR_MIN_SIZE		Mindestgroesse
+SR_MAX_SIZE		Maximalgroesse
+SM_RACE			Rassenspezifische Besonderheiten
+
+Magie-Arten
+MT_ANGRIFF      	Angriff
+MT_SCHUTZ       	Schutz
+MT_ILLUSION     	Illusion
+MT_BEHERRSCHUNG 	Beherrschung
+MT_HELLSICHT    	Hellsicht
+MT_VERWANDLUNG  	Verwandlung
+MT_BESCHWOERUNG 	Beschwoerung
+MT_BEWEGUNG     	Bewegung
+MT_SAKRAL       	'Goettliches'
+MT_HEILUNG      	Heilung
+MT_CREATION     	Erschaffung
+MT_PSYCHO       	Psycho-Kram
+MT_MISC         	Sonstiges
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+::
+
diff --git a/doc/sphinx/lfun/GiveMiniQuest.rst b/doc/sphinx/lfun/GiveMiniQuest.rst
new file mode 100644
index 0000000..65f920a
--- /dev/null
+++ b/doc/sphinx/lfun/GiveMiniQuest.rst
@@ -0,0 +1,71 @@
+GiveMiniQuest()
+===============
+
+FUNKTION
+--------
+::
+
+        int GiveMiniQuest(object winner)
+
+DEFINIERT IN
+------------
+::
+
+        /secure/questmaster
+
+ARGUMENTE
+---------
+::
+
+	winner
+	  Spielerobjekt, das die Quest bestanden hat.
+
+RUeCKGABEWERT
+-------------
+::
+
+        (Die Defines fuer den Rueckgabewert finden sich in 
+         /secure/questmaster.h)
+         1 : Hat geklappt                           (OK)
+        -1 : Spieler hat die Quest bereits geloest  (MQ_ALREADY_SET)
+        -2 : Ungueltiger Questname                  (MQ_KEY_INVALID)
+        -3 : Unbefugter Zugriff                     (MQ_ILLEGAL_OBJ)
+        -4 : Quest zur Zeit inaktiv                 (MQ_IS_INACTIVE)
+        -5 : Gaeste loesen keine Quests             (MQ_GUEST)
+
+BESCHREIBUNG
+------------
+::
+
+	Mit dieser Funktion wird nach dem erfolgreichen Loesen einer 
+        MiniQuest die Quest im Spieler eingetragen. Dabei muss der
+        Aufruf in dem Objekt erfolgen, welches im Questmaster 
+        eingetragen ist. Als Argument muss das Spielerobjekt 
+	angegeben werden, welches die Quest bestanden hat.
+
+        
+
+BEISPIEL
+--------
+::
+
+	QM->GiveMiniQuest(this_player());
+
+SIEHE AUCH
+----------
+::
+
+        HasMiniQuest
+        /secure/questmaster.h, /secure/questmaster.c
+
+HINWEIS
+-------
+::
+
+        Die Informationen fuer den EM fuer Quests sollten diesem
+        beim Eintragen der Miniquest in den Questmaster per Mail
+        zugeschickt werden. Siehe dazu die Hilfe zu AddMiniQuest.
+
+
+Zuletzt geaendert: Don, 30. Jan 2014, 22:14:12 von Ark.
+
diff --git a/doc/sphinx/lfun/GiveQuest.rst b/doc/sphinx/lfun/GiveQuest.rst
new file mode 100644
index 0000000..b6986dd
--- /dev/null
+++ b/doc/sphinx/lfun/GiveQuest.rst
@@ -0,0 +1,87 @@
+GiveQuest()
+===========
+
+FUNKTION
+--------
+::
+
+        varargs int GiveQuest(string questname, string message)
+
+DEFINIERT IN
+------------
+::
+
+        /std/player/quests.c
+
+ARGUMENTE
+---------
+::
+
+        questname
+          Questname, wie er im Questmaster eingetragen wurde.
+        message 
+          Optionale Meldung, die auf dem Abenteuer-Kanal statt der 
+          Standardmeldung gesendet wird.
+          Dabei wird @@name@@ durch den Spielernamen ersetzt.
+
+RUeCKGABEWERT
+-------------
+::
+
+        (Die Defines fuer den Rueckgabewert finden sich in 
+         /secure/questmaster.h)
+         1 : Hat geklappt                           (OK)
+        -1 : Spieler hat die Quest bereits geloest  (GQ_ALREADY_SET)
+        -2 : Ungueltiger Questname                  (GQ_KEY_INVALID)
+        -3 : Unbefugter Zugriff                     (GQ_ILLEGAL_OBJ)
+        -4 : Quest zur Zeit inaktiv                 (GQ_IS_INACTIVE)
+
+BESCHREIBUNG
+------------
+::
+
+        Mit dieser Funktion wird nach dem erfolgreichen Loesen einer 
+        Quest die Quest im Spieler eingetragen. Dabei muss der Aufruf 
+        in dem Objekt erfolgen, welches im Questmaster eingetragen ist.
+        Zusaetzlich wird der Zeitpunkt eingetragen, an dem die Quest
+        bestanden wurde.
+
+        
+
+        Wer sich da nicht sicher ist, kann mit dem Questtool 
+        (/obj/tools/questtool) nachsehen. 
+
+        Nachdem eine Quest als geloest markiert wurde, ist dies in einem 
+        Logfile fuer die Quest im Verzeichnis /log/quest einzutragen. Dazu
+        wird write_file verwendet.
+
+BEISPIEL
+--------
+::
+
+        int quest;
+
+        quest = this_player()->GiveQuest("Zacharias Eispalast");
+
+        if (quest == 1)
+        {
+          write("Du fuehlst, wie Deine Erfahrung ansteigt.\n");
+          write_file("/log/quest/eispalast", 
+                     dtime(time())+"   Aufgabe geloest von "
+                     +this_player()->name()+"\n");
+        } 
+        else if (quest != -1)
+          write( "Die Weltenmaschine will Dir Deine Arbeit "
+                 +"nicht anerkennen.\n"
+                 +"Frage einen Erzmagier um Hilfe.\n" );
+
+SIEHE AUCH
+----------
+::
+
+        /secure/questmaster.h, /obj/tools/questtool
+        QueryQuest(), write_file(), ModifyQuestTime()
+
+
+Zuletzt geaendert: Son, 27. Apr 2014, Arathorn
+
diff --git a/doc/sphinx/lfun/GroupName.rst b/doc/sphinx/lfun/GroupName.rst
new file mode 100644
index 0000000..f50d900
--- /dev/null
+++ b/doc/sphinx/lfun/GroupName.rst
@@ -0,0 +1,87 @@
+GroupName()
+===========
+
+FUNKTION
+--------
+::
+
+     string GroupName(string grp)
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/materialdb.c (MATERIALDB)
+
+ARGUMENTE
+---------
+::
+
+     string grp - ein Gruppenname
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt die Langbeschreibung des Gruppennamens zurueck.
+
+RUECKGABEWERT
+-------------
+::
+
+     Die Gruppenbeschreibung oder "Unbekanntes"
+
+BEISPIELE
+---------
+::
+
+     // simpel
+     tmp=m_indices(ob->QueryProp(P_MATERIAL));
+     write("Dieses Objekt gehoert u.a. zur Gruppe "+
+           MATERIALDB->GroupName(MATERIALDB->GetMatMembership(tmp[0])[0])+
+           ".\n");
+     // gibt die erste Gruppenzugehoerigkeit des erste Materials in
+     // P_MATERIAL zurueck (bei MATGROUP_METAL z.B. "... zur Gruppe Metalle.")
+
+     // ein weiser Schmied:
+     int i;
+     string *mat, mname, mgroup;
+     mat=m_indices(ob->QueryProp(P_MATERIAL));
+     i=sizeof(mat);
+
+     write("Der Schmied sagt: "+ob->Name(WER)+" besteht aus ...\n");
+     while(i--) {
+      // den Namen erkennen/aussprechen:
+      // Materialien werden allgemein ganz schlecht erkannt (zu 5%), aber
+      // alles aus Metall wird zu +100% gut erkannt ...
+      mname=MATERIALDB->MaterialName(mat[i], WER,
+	     ({5, ([MATERIAL_SYMMETRIC_RECOGNIZABILITY:
+			({MATGROUP_METAL, 100})])}));
+
+      // und nur Metalle analysieren ...
+      if(MATERIALDB->MaterialGroup(([mat[i]:100]),MATGROUP_METAL)>=100) {
+       int j;
+       string *mgr;
+       mgr=MATERIALDB->GetMatMembership(mat[i]);
+       j=sizeof(mgr);
+       mgroup=" gehoert zu ";
+       while(j--) {
+        mgroup+=MATERIALDB->GroupName(mgr[j]);
+        if(j>0) mgroup+=", ";
+       }
+      } else mgroup=" kenne ich nicht";
+      printf("%-12.12s: %s\n",mname, mgroup);
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Master:	  AddMaterial(), ConvMaterialList(), MaterialGroup(),
+		  MaterialName(),
+		  GetGroupMembers(), GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/GuardExit.rst b/doc/sphinx/lfun/GuardExit.rst
new file mode 100644
index 0000000..aa5a1df
--- /dev/null
+++ b/doc/sphinx/lfun/GuardExit.rst
@@ -0,0 +1,112 @@
+GuardExit()
+===========
+
+FUNKTION
+--------
+::
+
+     protected <int|<string|closure>* >* GuardExit(object room, int hookid,
+                                                   <string|closure>* hdata);
+
+DEFINIERT IN
+------------
+::
+
+     /std/npc/moving.c
+
+ARGUMENTE
+---------
+::
+
+     room
+          Der den Hook ausloesende Raum (environment())
+     hookid
+          Die ID des Hooks (H_HOOK_EXIT_USE)
+     hdata
+          Ein Array mit 3 Elementen:
+          ({
+              verb - Das Kommandoverb/Ausgangsname (string)
+              dest - Zielraum (string) oder closure (special exits)
+              msg  - Bewegungsrichtung (string) oder 0
+          })
+
+BESCHREIBUNG
+------------
+::
+
+     Ist diese Funktion in einem NPC definiert, traegt sich der NPC bei jeder
+     Bewegung automatisch als Konsument von H_HOOK_EXIT_USE ein und diese
+     Funktion wird immer gerufen, wenn ein Lebewesen im gleichen Environment
+     wie der NPC versucht, einen Ausgang zu benutzen.
+     Der NPC kann dann die Bewegung abbrechen (und so den Ausgang
+     blockieren), Ziel oder Bewegungsmeldung aendern oder keine Veraenderung
+     vornehmen.
+     Die Konstanten fuer Hookid und Hookstatus (s. Rueckgabewert) sind in
+     <hook.h> definiert.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Array mit zwei Elementen:
+     ({
+         H_NO_MOD / H_ALTERED / H_CANCELLED,
+         hdata
+     })
+     hdata ist ggf. das geaenderte Array, welches die Funktion uebergeben
+     wird. Weitere Details s. auch /doc/std/hooks
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Anzahl an Konsumenten eines Hooks ist begrenzt. Es ist daher
+     moeglich, dass die Registrierung nicht klappt, wenn zuviele (>5) Waechter
+     im Raum sind. Will man darauf reagieren, muesste man die Registrierung
+     pruefen.
+     Ein NPC, welcher GuardExit() definiert, aber im aktuellen Environment
+     keine Wache halten will, koennte sich selber de-registrieren.
+
+BEISPIELE
+---------
+::
+
+     <int|<string|closure>* >* GuardExit(object room, int hookid,
+                                         <string|closure>* hdata)
+     {
+       // Nur in Gefaengnisraeumen Wache halten
+       if (strstr(object_name(environment()), "/room/jail")==0)
+       {
+         // Hier gehts nicht raus. ;-)
+         if (hdata[0] == "raus") {
+             tell_object(this_player(), ...);
+             return ({H_CANCELLED, hdata});
+         }
+         // Special exits ersetzen wir durch einen eigenen
+         else if (closurep(hdata[1])) {
+           hdata[1] = #'my_special_exit;
+           return ({H_ALTERED, hdata});
+         }
+         // alle anderen Ausgaenge in die persoenliche Zelle
+         else {
+           tell_object(this_player(), ...);
+           hdata[1] = "/room/jail_"+getuid(this_player());
+           hdata[2] = "Sueden";
+           return ({H_ALTERED, hdata});
+         }
+      }
+      // in allen anderen Raeumen nicht eingreifen
+      return ({H_NO_MOD, hdata});
+    }
+
+SIEHE AUCH
+----------
+::
+
+     AddExit, AddSpecialExit, RemoveExit
+     HRegisterToHook, HRegisterModifier, HUnregisterFromHook
+     /doc/std/hooks
+
+20.02.2016, Zesstra
+22.05.2016, Mupfel (Beispiel korrigiert)
+
diff --git a/doc/sphinx/lfun/Halt.rst b/doc/sphinx/lfun/Halt.rst
new file mode 100644
index 0000000..d54a534
--- /dev/null
+++ b/doc/sphinx/lfun/Halt.rst
@@ -0,0 +1,53 @@
+Halt()
+======
+
+FUNKTION
+--------
+::
+
+     void Halt();
+
+DEFINIERT IN
+------------
+::
+
+     /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Die Fahrt des Transporters wird abgebrochen. Sie muss explizit mit
+     Start() wieder aufgenommen werden!
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Es gibt keine einfache Moeglichkeit, die Fahrt eines Transporters an
+     der Stelle wieder aufzunehmen, an der sie unterbrochen wurde. Man
+     muesste die aktuelle Position mit QueryPosition() ermitteln, mit Hilfe
+     der AddXXX()-Aufrufe in eine Positionsnummer umwandlen und diese an
+     Start() uebergeben.
+
+SIEHE AUCH
+----------
+::
+
+     Start(), /std/transport.c
+
+
+Last modified: Wed May 8 10:19:23 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/HasMiniQuest.rst b/doc/sphinx/lfun/HasMiniQuest.rst
new file mode 100644
index 0000000..6885348
--- /dev/null
+++ b/doc/sphinx/lfun/HasMiniQuest.rst
@@ -0,0 +1,62 @@
+HasMiniQuest()
+==============
+
+FUNKTION
+--------
+::
+
+        int HasMiniQuest(mixed pl, mixed name)
+
+DEFINIERT IN
+------------
+::
+
+        /secure/questmaster
+
+ARGUMENTE
+---------
+::
+
+        pl
+          Name des Spielers oder das Spielerobjekt
+        name
+          Filename des Objekts oder das Objekt selbst, welches die Miniquest
+          im Spieler eintragen darf, oder die Nummer (int) der Miniquest
+
+RUeCKGABEWERT
+-------------
+::
+
+         1 : Der Spieler hat die MiniQuest
+         0 : Der Spieler hat die MiniQuest noch nicht
+        -2 : angegebene Miniquest existiert nicht
+        -3 : falsche Datentypen fuer pl oder name uebergeben
+
+BESCHREIBUNG
+------------
+::
+
+        Mit dieser Funktion kann getestet werden, ob ein Spieler eine 
+        MiniQuest bereits geloest hat. Dabei ist entweder der Filename des 
+        Objektes anzugeben, das die Quest im Spieler eintragen darf oder
+        das Objekt selbst.
+
+        
+
+BEISPIEL
+--------
+::
+
+        if( QM->HasMiniQuest(getuid(this_player()), this_object())!=1 )
+          write("Du bist noch nicht reif genug.\n");
+
+SIEHE AUCH
+----------
+::
+
+        GiveMiniQuest(L)
+        /secure/questmaster.h, /secure/questmaster.c
+
+
+Zuletzt geaendert: 2014-Feb-03, Arathorn.
+
diff --git a/doc/sphinx/lfun/HitFunc.rst b/doc/sphinx/lfun/HitFunc.rst
new file mode 100644
index 0000000..cf90ff0
--- /dev/null
+++ b/doc/sphinx/lfun/HitFunc.rst
@@ -0,0 +1,94 @@
+HitFunc()
+=========
+
+FUNKTION
+--------
+::
+
+     int HitFunc(object enemy);
+
+DEFINIERT IN
+------------
+::
+
+     eigenen Objekten, fuer /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+     enemy
+          Der Gegner, gegen den die Waffe eingesetzt wird.
+
+BESCHREIBUNG
+------------
+::
+
+     Die Waffe kann anhand des Gegners enemy entscheiden, ob ein
+     Schadensbonus oder auch ein Schadensmalus wirksam wird. Dieser Bonus
+     wird zu dem normalen Schaden der Waffe hinzuaddiert.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Der Schadensbonus bzw. der Abschlag.
+
+BEMERKUNGEN
+-----------
+::
+
+     Wenn durch den Bonus die Genehmigungsgrenzen der Balance
+     ueberschritten werden koennen, muss man seinen Regionsmagier und
+     die Objekt-Balance konsultieren!
+
+     Werte der HitFunc sollten immer ueber ein random() zurueckgegeben 
+     werden!
+
+     Diese Funktion sollte die Waffe nicht zerstoeren! Falls ihr im Kampf eine
+     Waffe (ggf. in Abhaengigkeit vom Gegner) zerstoeren wollt, nutzt dazu
+     bitte TakeFlaw(). 
+
+BEISPIELE
+---------
+::
+
+     Eine Waffe, die gegen Orks besonders gut wirkt:
+
+     inherit "std/weapon";
+
+     #include <properties.h>
+     #include <combat.h>
+     #include <class.h>
+
+     create(){
+       if(!clonep(this_object())) {
+           set_next_reset(-1);
+           return;
+       }
+       ::create();
+       /* 
+       zig SetProp's, um die Waffe zu konfigurieren
+       HitFunc() ist in der Waffe selbst definiert 
+       */
+       SetProp(P_HIT_FUNC, this_object());
+     }
+
+     int HitFunc(object enemy)
+     {
+       /* laesst sich der Gegner als Ork ansprechen? */
+       if (enemy->is_class_member(CL_ORC))
+         return random(10+random(50)); /* Ja => Schaden erhoehen */
+
+       return 0;   /* ansonsten keinen zusaetzlichen Schaden anrichten */
+     }
+
+SIEHE AUCH
+----------
+::
+
+     QueryDefend(), /std/weapon.c
+     TakeFlaw()
+
+11.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/Identify.rst b/doc/sphinx/lfun/Identify.rst
new file mode 100644
index 0000000..1a886dd
--- /dev/null
+++ b/doc/sphinx/lfun/Identify.rst
@@ -0,0 +1,44 @@
+Identify()
+==========
+
+FUNKTION
+--------
+::
+
+     void Identify(object ob);
+
+DEFINIERT IN
+------------
+::
+
+     /std/corpse.c
+
+ARGUMENTE
+---------
+::
+
+     ob
+          Das kuerzlich nach langem, hartem Kampf verstorbene Objekt.
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Funktion werden Lang- und Kurzbeschreibung der Leiche gesetzt
+     sowie die Verwesung in Gang gesetzt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+SIEHE AUCH
+----------
+::
+
+     /std/corpse.c
+
+
+Last modified: Wed May 8 10:19:57 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/InFight.rst b/doc/sphinx/lfun/InFight.rst
new file mode 100644
index 0000000..e8020fa
--- /dev/null
+++ b/doc/sphinx/lfun/InFight.rst
@@ -0,0 +1,52 @@
+InFight()
+=========
+
+FUNKTION
+--------
+::
+
+        mixed InFight()
+
+ARGUMENTE
+---------
+::
+
+        keine
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion wurde dazu geschrieben, um herauszufinden,
+        ob sich ein PC/NPC direkt im Kampf befindet. Dazu wird
+        das Array mit den Namen der Feinden des PC/NPCs durch die
+        Funktion environment gefiltert und so festgestellt, ob
+        die Umgebung der beiden Feinde gleich ist.
+
+RUECKGABEWERT: 
+        Als Rueckgabewert enthaelt man entweder 0, wenn das Objekt
+        im Moment keine Feinde hat bzw. die nicht im selben Raum
+        sind, oder aber das Feindobjekt, das als erstes im Array
+        steht und anwesend ist.
+
+BEISPIEL
+--------
+::
+
+        Selbsterklaerend ;)
+
+BEMERKUNG
+---------
+::
+
+        InFight() gibt lediglich das Ergebnis von EnemyPresent() zurueck.
+
+SIEHE AUCH
+----------
+::
+
+        EnemyPresent(), PresentEnemies()
+        /std/living/combat.c
+
+22.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/InList.rst b/doc/sphinx/lfun/InList.rst
new file mode 100644
index 0000000..d6a3a3c
--- /dev/null
+++ b/doc/sphinx/lfun/InList.rst
@@ -0,0 +1,48 @@
+InList()
+========
+
+FUNKTION
+--------
+::
+
+     int InList(object room, int *potionlist, int *knownlist)
+
+DEFINIERT IN
+------------
+::
+
+     /secure/potionmaster.c
+
+ARGUMENTE
+---------
+::
+
+     Implizit: previous_object() - Spielerobjekt, das ZT bekommen soll
+     object room                 - Objekt, welches ZT vergeben will
+     int* potionlist             - Liste der ZTs des Spielers
+     int* knownlist              - Liste der bekannten ZTs des Spielers
+
+BESCHREIBUNG
+------------
+::
+
+     Prueft, ob 'room' einen ZT vergeben darf und gibt zurueck, ob die
+     Nummer dieses ZTs in der 'knownlist' enthalten ist.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0  Kein aktiver ZT oder nicht in Liste enthalten.
+     1  Aktiver ZT und in Liste.
+
+SIEHE AUCH
+----------
+::
+
+     Sonstiges: zaubertraenke, /room/orakel.c
+     Verwandt:  FindPotion(), RemoveKnownPotion(), AddKnownPotion()
+     Props:     P_POTIONROOMS, P_KNOWN_POTIONROOMS
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/lfun/InformAlcoholEffect.rst b/doc/sphinx/lfun/InformAlcoholEffect.rst
new file mode 100644
index 0000000..dbeedc0
--- /dev/null
+++ b/doc/sphinx/lfun/InformAlcoholEffect.rst
@@ -0,0 +1,68 @@
+InformAlcoholEffect()
+=====================
+
+FUNKTION
+--------
+::
+
+	void InformAlcoholEffect(object pl, int msgid, int area)
+
+DEFINIERT IN
+------------
+::
+
+     eigenen Objekten; fuer /std/living/life.c
+
+ 
+
+ARGUMENTE
+---------
+::
+
+	pl
+          Das Lebewesen, das alkoholisiert ist.
+        msgid
+          Flag fuer die Meldung, die ausgegeben wird.
+        area
+          Aufruf erfolgt in Gilde (0) oder im Environment (1).
+
+BESCHREIBUNG
+------------
+::
+
+        Wenn ein Lebewesen alkoholisiert ist, werden in unregelmaessigen
+        Abstaenden Meldungen an die Umgebung und ans Lebewesen ausgegeben.
+        Gleichzeitig wird die Funktion InformAlcoholEffect in der Gilde
+        und im Environment des Lebewesens aufgerufen.
+
+        
+
+        Es gibt vier verschiedene Meldungen (definiert in /sys/health.h):
+        ALC_EFFECT_HICK      (0) : "<Hick>! Oh, Tschuldigung.\n"
+        ALC_EFFECT_RUELPS    (1) : "Du ruelpst.\n"
+        ALC_EFFECT_LOOKDRUNK (2) : "Du fuehlst Dich benommen.\n"
+        ALC_EFFECT_STUMBLE   (3) : "Du stolperst.\n"
+
+        
+
+        Wird die Funktion in einem Gildenraum implementiert, so kann man
+        anhand des 3. Parameters unterscheiden, ob die Gilde als Gilde
+        oder als Raum gemeint ist (die Funktion wird je einmal aufgerufen):
+        ALC_EFFECT_AREA_GUILD (0) : der Aufruf betrifft die Gilde,
+        ALC_EFFECT_AREA_ENV   (1) : der Aufruf betrifft die Umgebung.
+
+RUeCKGABEWERT
+-------------
+::
+
+	keiner
+
+SIEHE AUCH
+----------
+::
+
+        P_ALCOHOL, /sys/health.h
+
+
+Last modified: Thu May 23 23:08:00 2002 by Mupfel
+
diff --git a/doc/sphinx/lfun/InformDefend.rst b/doc/sphinx/lfun/InformDefend.rst
new file mode 100644
index 0000000..fbc0b12
--- /dev/null
+++ b/doc/sphinx/lfun/InformDefend.rst
@@ -0,0 +1,82 @@
+InformDefend()
+==============
+
+FUNKTION
+--------
+::
+
+	void InformDefend(object enemy);
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+	enemy
+	  Der Feind, der ein zu verteidigendes Lebewesen angegriffen hat.
+
+BESCHREIBUNG
+------------
+::
+
+	Es ist moeglich, dass Objekte ueber Angriffe auf Lebewesen
+	informiert werden, sofern diese Objekte bei dem angegriffenen
+	Lebewesen mittels AddDefender() angemeldet wurden und sich der
+	selben Umgebung befinden.
+	Zumeist wird es sich bei den Objekten natuerlich ebenfalls um
+	andere Lebewesen handeln, die das Lebewesen, bei dem sie angemeldet
+	sind, verteidigen sollen.
+	Bei einem Angriff auf das Lebewesen werden alle Objekte per Aufruf
+	von InformDefend() darueber informiert, wobei der Angreifer als
+	Parameter uebergeben wird.
+	Standardmaessig ist diese Funktion in Lebewesen bereits definiert,
+	wobei der Skill SK_INFORM_DEFEND, sofern vorhanden, aufgerufen wird.
+
+BEISPIEL
+--------
+::
+
+	Sehr beliebt sind in Gilden NPCs, die den Beschwoerer begleiten und
+	verteidigen, z.B. beschworene Daemonen:
+	  inherit "std/npc";
+	  include <properties.h>
+	  object owner;
+	  void create()
+	  { ::create();
+	    SetProp(P_NAME,"Daemon");
+	    ...
+	  }
+	// nach Clonen des Daemons folgende Funktion mit Beschwoerer als
+	// Parameter aufrufen
+	  Identify(object caster)
+	  { if(!objectp(caster))
+	      call_out(#'remove,0);
+	    owner=caster;
+	    owner->AddDefender(this_object());
+	  }
+	// folgende Funktion wird automatisch aufgerufen, wenn der
+	// Beschwoerer angegriffen wird
+	  void InformDefend(object enemy)
+	  { if(!IsEnemy(enemy)&&enemy!=owner)
+	      Kill(enemy);
+	  }
+	Soll der Daemon sich auch in ein Team einordnen, in welchem sich der
+	Beschwoerer eventuell befindet, so ist zusaetzlich AssocMember() in
+	diesem Beschwoerer aufzurufen, wobei der Daemon als Parameter
+	uebergeben wird.
+
+SIEHE AUCH
+----------
+::
+
+	AddDefender(), RemoveDefender(), DefendOther(), Kill(), IsEnemy(),
+	P_DEFENDERS, /std/living/combat.c, /sys/new_skills.h
+
+
+Last modified: Thu Jul 29 18:48:45 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/InformRowChange.rst b/doc/sphinx/lfun/InformRowChange.rst
new file mode 100644
index 0000000..a642c58
--- /dev/null
+++ b/doc/sphinx/lfun/InformRowChange.rst
@@ -0,0 +1,45 @@
+InformRowChange()
+=================
+
+FUNKTION
+--------
+::
+
+	varargs void InformRowChange(int from, int to, object caster);
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+	from   - Reihe, in die der Spieler vorher war.
+	to     - Reihe in der der Spieler jetzt ist.
+	caster - Der Spieler, falls die Funktion in der Gilde aufgerufen wird.
+
+        
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Funktion wird im Spieler und in seiner Gilde aufgerufen,
+	falls sich die aktuelle Kampfreihe in der Teamaufstellung
+	aendert.
+
+RUECKGABEWERT
+-------------
+::
+
+	Keiner.
+
+SIEHE AUCH
+----------
+::
+
+	teams
+
diff --git a/doc/sphinx/lfun/InformUnwear.rst b/doc/sphinx/lfun/InformUnwear.rst
new file mode 100644
index 0000000..350014a
--- /dev/null
+++ b/doc/sphinx/lfun/InformUnwear.rst
@@ -0,0 +1,49 @@
+InformUnwear()
+==============
+
+FUNKTION
+--------
+::
+
+	protected void InformUnwear(object pl, int silent, int all)
+
+DEFINIERT IN
+------------
+::
+
+        /std/clothing/wear.c
+
+ARGUMENTE
+---------
+::
+
+	pl
+          Das Lebewesen, das die Ruestung ausgezogen hat.
+        silent
+          Flag, ob Meldungen unterdruckt werden sollen.
+        all
+          Flag, ob die Ruestung mit "ziehe alles aus"/
+          "ziehe alle ruestungen aus" ausgezogen wurde.
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion wird aufgerufen, wenn die Ruestung erfolgreich
+        ausgezogen wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+	keiner
+
+SIEHE AUCH
+----------
+::
+
+        InformUnwield(), InformWield(), InformWear()
+
+
+06.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/InformUnwield.rst b/doc/sphinx/lfun/InformUnwield.rst
new file mode 100644
index 0000000..0640e4f
--- /dev/null
+++ b/doc/sphinx/lfun/InformUnwield.rst
@@ -0,0 +1,46 @@
+InformUnwield()
+===============
+
+FUNKTION
+--------
+::
+
+	protected void InformUnwield(object pl, int silent)
+
+DEFINIERT IN
+------------
+::
+
+	/std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+	pl
+          Das Lebewesen, das die Waffe gezueckt hatte.
+        silent
+          Flag, ob Meldungen unterdruckt werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion wird aufgerufen, wenn die Waffe erfolgreich
+        weggesteckt wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+	keiner
+
+SIEHE AUCH
+----------
+::
+
+        InformWield(), InformWear(), InformUnwear()
+
+
+06.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/InformWear.rst b/doc/sphinx/lfun/InformWear.rst
new file mode 100644
index 0000000..dcef6bc
--- /dev/null
+++ b/doc/sphinx/lfun/InformWear.rst
@@ -0,0 +1,49 @@
+InformWear()
+============
+
+FUNKTION
+--------
+::
+
+	protected void InformWear(object pl, int silent, int all)
+
+DEFINIERT IN
+------------
+::
+
+        /std/clothing/wear.c
+
+ARGUMENTE
+---------
+::
+
+	pl
+          Das Lebewesen, das die Ruestung angezogen hat.
+        silent
+          Flag, ob Meldungen unterdruckt werden sollen.
+        all
+          Flag, ob die Ruestung mit "trage alles"/"trage alle ruestungen"
+          angezogen wurde.
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion wird aufgerufen, wenn die Ruestung erfolgreich
+        angezogen wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+	keiner
+
+SIEHE AUCH
+----------
+::
+
+        InformUnwield(), InformWield(), InformUnwear()
+
+
+06.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/InformWield.rst b/doc/sphinx/lfun/InformWield.rst
new file mode 100644
index 0000000..f9a5c21
--- /dev/null
+++ b/doc/sphinx/lfun/InformWield.rst
@@ -0,0 +1,46 @@
+InformWield()
+=============
+
+FUNKTION
+--------
+::
+
+	protected void InformWield(object pl, int silent)
+
+DEFINIERT IN
+------------
+::
+
+	/std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+	pl
+          Das Lebewesen, das die Waffe gezueckt hat.
+        silent
+          Flag, ob Meldungen unterdruckt werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion wird aufgerufen, wenn die Waffe erfolgreich
+        gezueckt wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+	keiner
+
+SIEHE AUCH
+----------
+::
+
+        InformUnwield(), InformWear(), InformUnwear()
+
+
+06.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/InsertEnemy.rst b/doc/sphinx/lfun/InsertEnemy.rst
new file mode 100644
index 0000000..5ceb153
--- /dev/null
+++ b/doc/sphinx/lfun/InsertEnemy.rst
@@ -0,0 +1,63 @@
+InsertEnemy()
+=============
+
+gefunden : lfun/InsertEnemy
+
+FUNKTION
+--------
+::
+
+        int InsertEnemy(object enemy)
+
+        
+
+DEFINIERT IN
+------------
+::
+
+        /std/living/combat.c
+
+        
+
+ARGUMENTE
+---------
+::
+
+        enemy: Das Lebewesen, das angegriffen werden soll.
+
+        
+
+BESCHREIBUNG
+------------
+::
+
+        Nach Aufruf der Funktion wird das Wesen in die Liste der Feinde
+        aufgenommen.
+        In jedem heart_beat() wird dann ein anwesender Feind
+        angegriffen.
+
+        
+
+RUECKGABEWERT
+-------------
+::
+
+        0, falls der Feind nicht existiert, kein Lebewesen ist, ein Geist ist, 
+           oder im Gegner P_NO_ATTACK gesetzt ist, oder schon angegegriffen 
+           wurde
+        1  sonst
+
+        
+
+SIEHE AUCH
+----------
+::
+
+        Kill, IsEnemy, StopHuntFor, P_NO_ATTACK
+
+LETZTE AENDERUNG
+----------------
+::
+
+26.08.2010, Zesstra
+
diff --git a/doc/sphinx/lfun/InsertEnemyTeam.rst b/doc/sphinx/lfun/InsertEnemyTeam.rst
new file mode 100644
index 0000000..c738b69
--- /dev/null
+++ b/doc/sphinx/lfun/InsertEnemyTeam.rst
@@ -0,0 +1,67 @@
+InsertEnemyTeam()
+=================
+
+FUNKTION
+--------
+::
+
+        varargs void InsertEnemyTeam(mixed ens, int rek)
+
+DEFINIERT IN
+------------
+::
+
+        /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+        ens     object Feind oder object *Feinde
+        rek     Wurde von InsertEnemyTeam aufgerufen
+
+BESCHREIBUNG
+------------
+::
+
+        Alle Teammitglieder des Feindes bzw. die angegebenen Feinde (aber
+        nicht deren Teammitglieder) werden zu Feinden
+         a) des Spielers und aller Teammitglieder, falls rek==0
+         b) des Spielers, falls rek!=0
+
+RUECKGABEWERT
+-------------
+::
+
+        keiner
+
+BEMERKUNGEN
+-----------
+::
+
+        1. Nur wenn Gegner und Teammitglied im gleichen Raum stehen (aber
+           nicht notwendigerweise im gleichen Raum wie der Spieler) werden
+           sie zu Feinden.
+        2. Falls Teammitglied und Gegner beides Spieler sind, werden sie
+           nicht zu Feinden gemacht.
+        3. Ist der Gegner im eigenen Team, so wird nichts gemacht.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      AssocMember, DeAssocMember, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/InsertSensitiveObject.rst b/doc/sphinx/lfun/InsertSensitiveObject.rst
new file mode 100644
index 0000000..e8f06f0
--- /dev/null
+++ b/doc/sphinx/lfun/InsertSensitiveObject.rst
@@ -0,0 +1,68 @@
+InsertSensitiveObject()
+=======================
+
+FUNKTION
+--------
+::
+
+     void InsertSensitiveObject(object ob, mixed *arg)
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/inventory.c
+     generalizes /std/living/inventory.c
+
+BESCHREIBUNG
+------------
+::
+
+     Fuegt "ob" in die Benachrichtigungslisten des Containers ein.
+     Wird von thing/moving.c im Ziel-Environment gerufen, wenn
+     P_SENSITIVE gesetzt ist.
+
+BEMERKUNGEN
+-----------
+::
+
+     Setzt man P_SENSITIVE nicht als Default sondern situationsabhaengig,
+     dann muss man auch InsertSensitiveObject() im Environment
+     auch selbst rufen!
+
+BEISPIEL
+--------
+::
+
+     // Fackel (inheriting lightsource)
+     // wenn angezuendet, aendert es die Eigenschaften und wird zum
+     // aktiven Objekt - das muss man dem environment() mitteilen
+     static int light(string str) {
+      int i;
+      i=::light(str);
+      if(i && QueryProp(P_LIGHT)>0) {
+       SetProp(P_SENSITIVE,
+        ({({SENSITIVE_INVENTORY_TRIGGER,DT_FIRE,120})}));
+       if(environment())
+        environment()->InsertSensitiveObject(this_object(),
+					     QueryProp(P_SENSITIVE));
+      }
+      return i;
+     }
+
+     - falls ein empfindliches Objekt im environment() ist, dann wird
+       in diesem nun eventuell (Treshold) trigger_sensitive_inv()
+       gerufen
+
+SIEHE AUCH
+----------
+::
+
+     P_SENSITIVE
+     RemoveSensitiveObject
+     insert_sensitive_inv_trigger, insert_sensitive_inv
+     P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY, P_SENSITIVE_INVENTORY_TRIGGER
+     CheckSensitiveAttack
+
+25.Apr.2001, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/InternalModifyAttack.rst b/doc/sphinx/lfun/InternalModifyAttack.rst
new file mode 100644
index 0000000..88f93bc
--- /dev/null
+++ b/doc/sphinx/lfun/InternalModifyAttack.rst
@@ -0,0 +1,58 @@
+InternalModifyAttack()
+======================
+
+InternalModifyAttack(L)
+-----------------------
+::
+
+FUNKTION
+--------
+::
+
+     protected void InternalModifyAttack(mapping ainfo)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/combat
+
+ARGUMENTE
+---------
+::
+
+     mapping ainfo		Werte aus der Attack
+
+BESCHREIBUNG
+------------
+::
+
+     Dient dazu noch Aenderungen am Verhalten der Attack() vornehmen zu
+     koennen. Die Parameter werden alle per Referenz uebergeben, Aenderungen
+     wirken also direkt in der Attack()!
+     Einfach ueberschreiben (aber ::InternalModifyAttack(&ainfo) nicht
+     vergessen!
+
+     Aufbau von 'ainfo':
+     ([ SI_ENEMY :            object Angreifer,			(-> Defend)
+        SI_SPELL :           0/1/array Spellparameter,		(-> Defend)
+        P_WEAPON :           - oder Waffe,
+        SI_SKILLDAMAGE_MSG:  string Angriffsmeldungsende an Raum,
+        SI_SKILLDAMAGE_MSG2: string Angriffsmeldungsende an Kaempfende,
+        SI_SKILLDAMAGE:      int Schaden in Zehntel HP (Skills schon drin)
+								(-> Defend),
+        SI_SKILLDAMAGE_TYPE: string/string* Schadenstypen,	(-> Defend)
+        P_WEAPON_TYPE:       string Waffentyp (combat.h),
+        P_WC:		     - oder int WC der Waffe/Hand,
+        P_NR_HANDS:	     - oder int Hands der Waffe/Hand,
+     ]);
+
+SIEHE AUCH
+----------
+::
+
+     InternalModifyDefend(L)
+     Attack(L)
+
+28.03.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/InternalModifyDefend.rst b/doc/sphinx/lfun/InternalModifyDefend.rst
new file mode 100644
index 0000000..c270006
--- /dev/null
+++ b/doc/sphinx/lfun/InternalModifyDefend.rst
@@ -0,0 +1,50 @@
+InternalModifyDefend()
+======================
+
+InternalModifyDefend(L)
+-----------------------
+::
+
+FUNKTION
+--------
+::
+
+     protected void InternalModifyDefend(int dam, mixed dt, mixed spell,
+				      object enemy)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/combat
+
+ARGUMENTE
+---------
+::
+
+     int dam             Staerke des abzuwehrenden Angriffs (in HP/10)
+     string/string* dt   Art(en) des Schadens, der angerichtet werden soll
+     int/mapping spell   0 fuer normale Angriffe (keine Zauber)
+                         1 fuer Zauber (Standardruestungen ignorieren)
+                         mapping fuer mehr Informationen
+     object enemy        der Feind/Schadenverursacher
+
+BESCHREIBUNG
+------------
+::
+
+     Dient dazu noch Aenderungen am Verhalten der Defend() vornehmen zu
+     koennen. Die Parameter werden alle per Referenz uebergeben, Aenderungen
+     wirken also direkt in der Defend()!
+     Einfach ueberschreiben, aber ::InternalModifyDefend(&..., &....) nicht
+     vergessen!
+
+SIEHE AUCH
+----------
+::
+
+     InternalModifyAttack(L)
+     Defend(L)
+
+28.03.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/IsArmour.rst b/doc/sphinx/lfun/IsArmour.rst
new file mode 100644
index 0000000..5cb003d
--- /dev/null
+++ b/doc/sphinx/lfun/IsArmour.rst
@@ -0,0 +1,55 @@
+IsArmour()
+==========
+
+FUNKTION
+--------
+::
+
+    status IsArmour()
+
+DEFINIERT IN
+------------
+::
+
+    /std/armour/wear.c
+
+RUeCKGABEWERT
+-------------
+::
+
+    1 wenn ein Ruestung
+    0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt 1 zurueck, wenn entsprechende Klasse irgendwo geerbt wurden, es
+    also eine Ruestung ist.
+
+BEMERKUNGEN
+-----------
+::
+
+    Entsprechende Basisklasse ueberschreibt und gibt fuer IsClothing()
+    explizit 0 zurueck.
+
+BEISPIEL
+--------
+::
+
+    // enthaelt im Gegensatz zu P_ARMOURS auch nichtgetragenen Kram
+    // im Inventory L1
+    object *allarmours =
+      filter_objects(all_inventory(this_player()), "IsArmour")
+
+SIEHE AUCH
+----------
+::
+
+    Aehnlich: living, interactive
+    Aehnlich: IsBottle, IsClothing, IsPlayerCorpse, IsRoom, IsUnit
+    Props:    P_ARMOURS
+
+3. Sep 2016, Gloinson
+
diff --git a/doc/sphinx/lfun/IsBottle.rst b/doc/sphinx/lfun/IsBottle.rst
new file mode 100644
index 0000000..a1c1b1d
--- /dev/null
+++ b/doc/sphinx/lfun/IsBottle.rst
@@ -0,0 +1,42 @@
+IsBottle()
+==========
+
+IsPlayerCorpse
+--------------
+::
+
+FUNKTION
+--------
+::
+
+    int IsBottle()
+
+DEFINIERT IN
+------------
+::
+
+    /std/items/flasche.c
+
+RUeCKGABEWERT
+-------------
+::
+
+    1 wenn Flasche
+    0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt 1 zurueck, wenn das eine Flasche mit ordentlichem Flaschenverhalten
+    ist.
+
+SIEHE AUCH
+----------
+::
+
+    Aehnlich: living, interactive
+    Aehnlich: IsArmour, IsClothing, IsPlayerCorpse, IsRoom, IsUnit
+
+3. Sep 2016, Gloinson
+
diff --git a/doc/sphinx/lfun/IsClothing.rst b/doc/sphinx/lfun/IsClothing.rst
new file mode 100644
index 0000000..b8108df
--- /dev/null
+++ b/doc/sphinx/lfun/IsClothing.rst
@@ -0,0 +1,49 @@
+IsClothing()
+============
+
+FUNKTION
+--------
+::
+
+    status IsClothing()
+
+DEFINIERT IN
+------------
+::
+
+    /std/clothing.c
+    /std/clothing_container.c
+
+RUeCKGABEWERT
+-------------
+::
+
+    1 wenn ein Kleidungsstueck
+    0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt 1 zurueck, wenn entsprechende Klassen irgendwo geerbt wurden, es
+    also ein Kleidungsstueck (oder ein Kleidungsstueck mit Taschen) ist.
+
+BEISPIEL
+--------
+::
+
+    // enthaelt im Gegensatz zu P_CLOTHING auch nichtgetragenen Kram
+    // im Inventory L1
+    object *allcloth =
+      filter_objects(all_inventory(this_player()), "IsClothing")
+
+SIEHE AUCH
+----------
+::
+
+    Aehnlich: living, interactive
+    Aehnlich: IsArmour, IsBottle, IsPlayerCorpse, IsRoom, IsUnit
+    Props:    P_CLOTHING
+
+3. Sep 2016, Gloinson
+
diff --git a/doc/sphinx/lfun/IsEnemy.rst b/doc/sphinx/lfun/IsEnemy.rst
new file mode 100644
index 0000000..5bd7957
--- /dev/null
+++ b/doc/sphinx/lfun/IsEnemy.rst
@@ -0,0 +1,51 @@
+IsEnemy()
+=========
+
+FUNKTION
+--------
+::
+
+	int IsEnemy(object wer);
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+	wer
+	  Das Objekt, welches darauf ueberprueft werden soll, ob es
+	  derzeit als Gegner bekannt ist.
+
+RUeCKGABEWERT
+-------------
+::
+
+	Flag: 1 bei Feindschaft, 0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+	Mit dieser Funktion kann man ueberpruefen, ob das Objekt <wer>, also
+	im Normalfall ein Lebewesen, derzeit als Gegner erkannt wird. Nach
+	einer gewissen Zeit laeuft die Feindschaft automatisch aus, sodass
+	man sich nicht darauf verlassen, dass ein Gegner auch zukuenftig als
+	solchiger erkannt wird. (Diese Zeit betraegt normal 300 Sekunden.)
+	Solch eine Feindschaft kann im uebrigen auch einseitig sein! Mehr
+	dazu findet man in der Dokumentation zu StopHuntFor(), einer
+	Funktion, die Frieden zwischen Gegnern stiften soll.
+
+SIEHE AUCH
+----------
+::
+
+	SelectEnemy(), QueryEnemies(), StopHuntFor()
+
+
+Last modified: Wed May 26 16:47:51 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/IsEqual.rst b/doc/sphinx/lfun/IsEqual.rst
new file mode 100644
index 0000000..8d12ce3
--- /dev/null
+++ b/doc/sphinx/lfun/IsEqual.rst
@@ -0,0 +1,58 @@
+IsEqual()
+=========
+
+FUNKTION
+--------
+::
+
+    int IsEqual(object ob)
+
+DEFINIERT IN
+------------
+::
+
+    /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+    ob      Das Objekt das geprueft werden soll.
+
+BESCHREIBUNG:                                                               
+    Diese Funktion prueft ob zwei Objekte vom gleichen Typ sind, also ob
+    z.B. ob und this_object() beides Muenzen sind oder beides Edelsteine.
+    Bei einem Ergebnis != 0 fasst unit.c diese zwei Objekte automatisch
+    zusammen, wenn ob->IsEqual(this_object()) auch einen Wert != 0 ergibt.
+    Hierbei wird das IsEqual() von beiden beteiligten Objekten gerufen und sie
+    muessen uebereinstimmen, dass sie eigentlich das gleiche Objekt sind.
+    Selbstverstaendlich ist diese Funktion nur im Falle von Unitobjekten
+    sinnvoll.
+
+RUeCKGABEWERT
+-------------
+::
+
+    0 - this_object() ist nicht vom selben Typ wie ob
+    1 - this_object() ist vom gleichen Typ wie ob
+
+BEISPIELE
+---------
+::
+
+    o Ein Unitobjekt das verschiedene Beschreibungen haben kann...
+
+       int IsEqual(object ob)
+       {
+          if (!(int)::IsEqual(ob)) return 0;
+          return (QueryProp(P_SHORT)==ob->QueryProp(P_SHORT));
+       }
+
+SIEHE AUCH
+----------
+::
+
+    /std/unit.c
+
+25.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/IsPlayerCorpse.rst b/doc/sphinx/lfun/IsPlayerCorpse.rst
new file mode 100644
index 0000000..d0fcf19
--- /dev/null
+++ b/doc/sphinx/lfun/IsPlayerCorpse.rst
@@ -0,0 +1,38 @@
+IsPlayerCorpse()
+================
+
+FUNKTION
+--------
+::
+
+    public int IsPlayerCorpse()
+
+DEFINIERT IN
+------------
+::
+
+    /std/corpse.c
+
+RUeCKGABEWERT
+-------------
+::
+
+    1 wenn Spielerleiche
+    0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt 1 zurueck, wenn diese Leiche eine Spielerleiche ist. Es kann auch
+    eine "normale" NPC-Leiche sein.
+
+SIEHE AUCH
+----------
+::
+
+    Aehnlich: living, interactive
+    Aehnlich: IsArmour, IsBottle, IsClothing, IsRoom, IsUnit
+
+3. Sep 2016, Gloinson
+
diff --git a/doc/sphinx/lfun/IsRoom.rst b/doc/sphinx/lfun/IsRoom.rst
new file mode 100644
index 0000000..3d61120
--- /dev/null
+++ b/doc/sphinx/lfun/IsRoom.rst
@@ -0,0 +1,38 @@
+IsRoom()
+========
+
+FUNKTION
+--------
+::
+
+    status IsRoom()
+
+DEFINIERT IN
+------------
+::
+
+    /std/room.c
+
+RUeCKGABEWERT
+-------------
+::
+
+    1 wenn ein Raum
+    0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt 1 zurueck, wenn /std/room.c irgendwo geerbt wurde, es also ein
+    Raum ist.
+
+SIEHE AUCH
+----------
+::
+
+    Aehnlich: living, interactive
+    Aehnlich: IsArmour, IsBottle, IsClothing, IsPlayerCorpse, IsUnit
+
+3. Sep 2016, Gloinson
+
diff --git a/doc/sphinx/lfun/IsTeamLeader.rst b/doc/sphinx/lfun/IsTeamLeader.rst
new file mode 100644
index 0000000..0035a16
--- /dev/null
+++ b/doc/sphinx/lfun/IsTeamLeader.rst
@@ -0,0 +1,69 @@
+IsTeamLeader()
+==============
+
+FUNKTION
+--------
+::
+
+        object IsTeamLeader()
+
+DEFINIERT IN
+------------
+::
+
+        /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+        keine
+
+BESCHREIBUNG
+------------
+::
+
+        Testet, ob der Spieler ein Teamleiter ist.
+
+RUECKGABEWERT
+-------------
+::
+
+        Falls der Spieler Teamleiter ist, wird das Teamobjekt zurueckgegeben,
+        sonst 0.
+
+BEISPIEL
+--------
+::
+
+        string leader_test(object pl)
+        {
+         ...
+
+         if ( objectp(pl->IsTeamLeader()) )
+          return "Als Leiter eines Teams hast Du grosse Verantwortung zu "
+            "tragen!";
+         else
+          return "Wenn Du mal Leiter eines Teams sein moechtes, solltest "
+            "Du Dir vorher der Verantwortung bewusst werden!";
+        }
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: TeamMembers
+        Kampf:      AssocMember, DeAssocMember, InsertEnemyTeam,
+                    SelectNearEnemy, SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/IsTeamMove.rst b/doc/sphinx/lfun/IsTeamMove.rst
new file mode 100644
index 0000000..70ed97f
--- /dev/null
+++ b/doc/sphinx/lfun/IsTeamMove.rst
@@ -0,0 +1,61 @@
+IsTeamMove()
+============
+
+FUNKTION
+--------
+::
+
+        object IsTeamMove()
+
+DEFINIERT IN
+------------
+::
+
+        /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+        keine
+
+BESCHREIBUNG
+------------
+::
+
+        Testet, ob momentan die Angriffsbewegung ausgefuehrt wird.
+
+RUECKGABEWERT
+-------------
+::
+
+        Falls die Angriffsbewegung gerade ausgefuehrt wird, wird das
+        Teamobjekt zurueckgegeben, sonst 0.
+
+BEMERKUNGEN
+-----------
+::
+
+        Wird intern benoetigt, damit der Begruessungsschlag verzoegert
+        werden kann, bis alle Teammitglieder ihre Angriffsbewegung
+        ausgefuehrt haben.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      AssocMember, DeAssocMember, InsertEnemyTeam,
+                    SelectNearEnemy, SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/IsUnit.rst b/doc/sphinx/lfun/IsUnit.rst
new file mode 100644
index 0000000..1dc26ea
--- /dev/null
+++ b/doc/sphinx/lfun/IsUnit.rst
@@ -0,0 +1,43 @@
+IsUnit()
+========
+
+FUNKTION
+--------
+::
+
+     int IsUnit();
+
+DEFINIERT IN
+------------
+::
+
+     /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion liefert immer 1 zurueck und zeigt damit an, dass es sich
+     bei diesem Objekt um ein Mengenobjekt handelt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1 bei allen Objekten, die /std/unit.c erben, ansonsten 0.
+
+SIEHE AUCH
+----------
+::
+
+     /std/unit.c
+
+
+Last modified: Wed May 8 10:20:19 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/Kill.rst b/doc/sphinx/lfun/Kill.rst
new file mode 100644
index 0000000..ba5ae9e
--- /dev/null
+++ b/doc/sphinx/lfun/Kill.rst
@@ -0,0 +1,43 @@
+Kill()
+======
+
+FUNKTION
+--------
+::
+
+	int Kill(object enemy)
+
+ARGUMENTE
+---------
+::
+
+	enemy: Der boese, boese Feind.
+
+BESCHREIBUNG
+------------
+::
+
+	Nach Aufruf der Funktion wird der Feind in jedem
+	heart_beat() attackiert.
+
+RUECKGABEWERT
+-------------
+::
+
+	0,  Falls der Feind nicht existiert
+  -1, falls der Feind ein Geist ist
+  -2, falls der Feind P_NO_ATTACK gesetzt hat
+  -3, falls der Angreifer selber P_NO_ATTACK gesetzt hat
+  -4, falls der Feind bereits angegriffen wurde
+	1   falls der Feind erfolgreich als Find registriert wurde.
+
+BEMERKUNGEN
+-----------
+::
+
+SIEHE AUCH
+----------
+::
+
+	InsertEnemy
+
diff --git a/doc/sphinx/lfun/LearnSkill.rst b/doc/sphinx/lfun/LearnSkill.rst
new file mode 100644
index 0000000..89694a9
--- /dev/null
+++ b/doc/sphinx/lfun/LearnSkill.rst
@@ -0,0 +1,53 @@
+LearnSkill()
+============
+
+FUNKTION
+--------
+::
+
+    public varargs void LearnSkill(string sname, int add, int diff)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skills.c
+
+ARGUMENTE
+---------
+::
+
+    string sname     der zu lernende Skill
+    string add       Anzahl zu lernender Skillpunkte
+    int diff         Schwierigkeit
+
+BESCHREIBUNG
+------------
+::
+
+    Die Methode laesst einen interaktiven (eingeloggten) Spieler den
+    Skill 'sname' um 'add' Punkte lernen.
+
+    Dabei wird sichergestellt, dass 'add' den Wert MAX_SKILLEARN nicht
+    ueberschreitet, der Skill nicht verschwindet und fuer uebergeordnete
+    Skills (SI_INHERIT) dieser uebergeordnete Skill auch einen Lerneffekt
+    erfaehrt.
+
+    Wird zB von Learn (spellbook) und SpellSuccess (spellbook) gerufen.
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  ModifySkill, LimitAbility
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkill, QuerySkillAbility
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung
+    * Properties:   P_NEWSKILLS
+    Spellbook:      Learn, SpellSuccess
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/Leave.rst b/doc/sphinx/lfun/Leave.rst
new file mode 100644
index 0000000..e196f57
--- /dev/null
+++ b/doc/sphinx/lfun/Leave.rst
@@ -0,0 +1,65 @@
+Leave()
+=======
+
+FUNKTION
+--------
+::
+
+     int Leave();
+
+DEFINIERT IN
+------------
+::
+
+     /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn sich der Spieler auf einem Transporter befindet, und dieser sich
+     momentan an einer Haltestelle liegt, verlaesst der Spieler den
+     Transporter.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Null, wenn der Spieler den Transporter nicht verlassen konnte, sonst
+     ungleich Null.
+
+BEMERKUNGEN
+-----------
+::
+
+     Es werden keine Tests durchgefuehrt, ob der Transporter ueberhaupt
+     angesprochen wurde! Das muss man selber machen.
+
+BEISPIELE
+---------
+::
+
+     int myLeave(string str)
+     {
+       if (str && id(str))
+         return Leave();
+
+       notify_fail("Was willst Du verlassen?\n");
+       return 0;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Enter(), /std/transport.c
+
+
+Last modified: Wed May 8 10:20:30 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/LimitAbility.rst b/doc/sphinx/lfun/LimitAbility.rst
new file mode 100644
index 0000000..b061295
--- /dev/null
+++ b/doc/sphinx/lfun/LimitAbility.rst
@@ -0,0 +1,67 @@
+LimitAbility()
+==============
+
+FUNKTION
+--------
+::
+
+    protected varargs mixed LimitAbility(mixed sinfo, int diff)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skills.c
+
+ARGUMENTE
+---------
+::
+
+    mixed sinfo      Skill-Informationen
+    int diff         Schwierigkeit
+
+BESCHREIBUNG
+------------
+::
+
+    Setzt ein Maximum an Skillfertigkeit basierend auf der Schwierigkeit
+    und dem P_LEVEL des Spielers.
+
+    
+
+    Folgend eine Kopie (!) der Tabelle aus /std/living/skills:
+    diff|lvl 1:|   3:|   7:| 10:| 13:| 16:| 19:| 22:| 25:| 28:| 31:| 34:|
+    ----+------+-----+-----+----+----+----+----+----+----+----+----+----+
+     -50|   83%|  84%|  86%| 87%| 89%| 90%| 92%| 93%| 95%| 96%| 98%| 99%|
+     -10|   69%|  72%|  74%| 77%| 80%| 82%| 85%| 88%| 91%| 93%| 96%| 99%|
+       0|   66%|  69%|  72%| 75%| 78%| 81%| 84%| 87%| 90%| 93%| 96%| 99%|
+      10|   62%|  65%|  69%| 72%| 75%| 79%| 82%| 85%| 89%| 92%| 95%| 98%|
+      20|   59%|  62%|  66%| 70%| 73%| 77%| 80%| 84%| 88%| 91%| 95%| 98%|
+      30|   55%|  59%|  63%| 67%| 71%| 75%| 79%| 83%| 87%| 90%| 94%| 98%|
+      40|   52%|  56%|  60%| 65%| 69%| 73%| 77%| 81%| 86%| 90%| 94%| 98%|
+      50|   49%|  53%|  58%| 62%| 67%| 71%| 76%| 80%| 85%| 89%| 94%| 98%|
+     100|   32%|  38%|  44%| 50%| 56%| 62%| 68%| 74%| 80%| 86%| 92%| 98%|
+     150|   15%|  22%|  30%| 37%| 45%| 52%| 60%| 67%| 75%| 82%| 90%| 97%|
+     200|   -2%|   7%|  16%| 25%| 34%| 43%| 52%| 61%| 70%| 79%| 88%| 97%|
+     250|  -19%|  -8%|   2%| 12%| 23%| 33%| 44%| 54%| 65%| 75%| 86%| 96%|
+     300|  -36%| -24%| -12%|  0%| 12%| 24%| 36%| 48%| 60%| 72%| 84%| 96%|
+     400|  -70%| -55%| -40%|-25%|-10%|  5%| 20%| 35%| 50%| 65%| 80%| 95%|
+     500| -104%| -86%| -68%|-50%|-32%|-14%|  4%| 22%| 40%| 58%| 76%| 94%|
+     600| -138%|-117%| -96%|-75%|-54%|-33%|-12%|  9%| 30%| 51%| 72%| 93%|
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkill, QuerySkillAbility
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung
+    * Properties:   P_NEWSKILLS
+    Spellbook:      Learn, SpellSuccess
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/MaterialGroup.rst b/doc/sphinx/lfun/MaterialGroup.rst
new file mode 100644
index 0000000..482281e
--- /dev/null
+++ b/doc/sphinx/lfun/MaterialGroup.rst
@@ -0,0 +1,64 @@
+MaterialGroup()
+===============
+
+FUNKTION
+--------
+::
+
+     int MaterialGroup(mapping mats, string grp)
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/materialdb.c (MATERIALDB)
+
+ARGUMENTE
+---------
+::
+
+     mapping mats - Materialienmapping
+     string grp   - Materialiengruppe
+
+BESCHREIBUNG
+------------
+::
+
+     Die Materialien im Mapping werden auf Zugehoerigkeit zu der Gruppe
+     untersucht und der Gesamtanteil dieser Materialiengruppe am Mapping
+     in Prozent zurueckgegeben (wenn das Mapping sich auf 100% aufaddiert).
+
+RUECKGABEWERT
+-------------
+::
+
+     int - prozentualer Anteil der Materialiengruppe -100 ... 100 %
+
+BEISPIELE
+---------
+::
+
+     if(MATERIALDB->MaterialGroup(
+		([MAT_MISC_STONE:40,MAT_AMETHYST:50,MAT_MISC_METAL:10]),
+		MATGROUP_JEWEL)>50)
+      write("Oh ja, darin sind sehr viele Edelsteine!\n");
+
+BEMERKUNGEN
+-----------
+::
+
+     Wird von /std/thing/description::QueryMaterialGroup() gerufen.
+     Bitte an Objekten auch QueryMaterialGroup() verwenden.
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Master:	  AddMaterial(), ConvMaterialList()
+		  GroupName(), MaterialName(),
+		  GetGroupMembers(), GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/MaterialList.rst b/doc/sphinx/lfun/MaterialList.rst
new file mode 100644
index 0000000..141eaad
--- /dev/null
+++ b/doc/sphinx/lfun/MaterialList.rst
@@ -0,0 +1,96 @@
+MaterialList()
+==============
+
+MaterialList(L)
+---------------
+::
+
+FUNKTION
+--------
+::
+
+     varargs string MaterialList(int casus, mixed idinf)
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     int casus	 - der Fall, in dem die Materialien dekliniert werden sollen
+     mixed idinf - Dinge, welche die Faehigkeiten des Erkennens beeinflussen:
+		   Einzelne Werte:
+                   * x: allgemeine Erkennung -100 ... 100
+                   * who: der Spieler - P_MATERIAL_KNOWLEDGE wird abgefragt
+                   * fun: wird evaluiert
+                   * what, kann folgendes enthalten:
+                     - Eintrag fuer Materialien ([MAT_XXX:-100...100])
+                     - Eintrag fuer Materialiengruppen (dito)
+                     - ([MATERIAL_SYMMETRIC_RECOGNIZABILITY: mixed mg])
+                       * mg ein Array:
+                         ({MATGROUP_X1,int z1, MATGROUP_X2, int z2, ...})
+                         wobei bei Zugehoerigkeit von string mat zu Gruppe
+                         z<n> auf die Faehigkeit addiert, andernfalls davon
+                         subtrahiert wird
+		   Array mit obigen Werten:
+                   - alle Parameter des Arrays sind optional und additiv
+                   - ({int x, object who, mapping what, closure fun})
+
+BESCHREIBUNG
+------------
+::
+
+     Listet die Materialien auf, aus denen ein Objekt besteht.
+     Dabei haengt die Genauigkeit der Materialerkennung von idinf ab. D.h.
+     je nach den Faehigkeiten/der angegebenen Faehigkeit wird zB Wolfram
+     als "Wolfram" oder nur als "Metall" erkannt.
+
+     Wenn ein Spieler etwas identifiziert, sollte auch TP uebergeben werden,
+     bei NPCs koennte das anders aussehen.
+
+RUECKGABEWERT
+-------------
+::
+
+     String mit Liste der Materialien.
+
+BEMERKUNGEN
+-----------
+::
+
+     - es werden nur die Materialien angegeben, nicht die Menge.
+     - ruft ConvMaterialList() an der MATERIALDB
+
+BEISPIELE
+---------
+::
+
+     // simpel
+     write("Der Gegenstand besteht aus"+ob->MaterialList(WEM,TP)+".\n")
+     // -> "Der Gegenstand besteht aus Gold, Silber und Rubin.\n"
+
+     // komplexer
+     ob->SetProp(P_MATERIAL, ([P_NITROGLYCERINE:90,P_GUNPOWDER:10]));
+     write("Das enthaelt "+ob->MaterialList(WER,TP)+".\n");
+     // -> "Das enthaelt Schwarzpulver und Nitroglycerin."
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Methoden:    QueryMaterial(), QueryMaterialGroup()
+     Listen:	  AllMaterials(), AllGroups(), Dump()
+		  materialliste, materialgruppen
+     Master:	  AddMaterial(), ConvMaterialList(), MaterialGroup(),
+		  GroupName(), MaterialName(),
+		  GetGroupMembers(), GetMatMembership()
+     Sonstiges:	  P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/MaterialName.rst b/doc/sphinx/lfun/MaterialName.rst
new file mode 100644
index 0000000..fb30eb4
--- /dev/null
+++ b/doc/sphinx/lfun/MaterialName.rst
@@ -0,0 +1,96 @@
+MaterialName()
+==============
+
+FUNKTION
+--------
+::
+
+     varargs string MaterialName(string mat, int casus, mixed idinf)
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/materialdb.c (MATERIALDB)
+
+ARGUMENTE
+---------
+::
+
+     string mat	 - das zu erkennende Material
+     int casus	 - der Fall
+     mixed idinf - Dinge, welche die Faehigkeiten des Erkennens beeinflussen
+		   (siehe "man MaterialList")
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion sucht unter Beruecksichtigung der Erkennungsbe-
+     schraenkungen des Materials und Faehigkeiten des Spielers den
+     Klarnamen des Materials heraus und gibt den zurueck.
+
+RUECKGABEWERT
+-------------
+::
+
+     string: Materialname oder genereller Name.
+
+BEISPIELE
+---------
+::
+
+     // der hier mag alle existierenden Juwelen, auch wenn welche ergaenzt
+     // werden sollten
+     // Parameter: 1. ein Juwel, 2. Casus, 3. 100% Erkennung - ob er sie
+     // beim Empfang dann auch zu 100% erkennt, steht hier nicht!
+     string* likeit;
+     likeit=MATERIALDB->GetGroupMembers(MATGROUP_JEWEL);
+     ...
+     write("Der Alte sagt: Ich mag "+
+	   MATERIALDB->MaterialName(likeit[random(sizeof(likeit))], WEN, 100)+
+	   ".\n");
+     ...
+
+     // ein weiser schmied:
+     int i;
+     string *mat, mname, mgroup;
+     mat=m_indices(ob->queryprop(p_material));
+     i=sizeof(mat);
+
+     write("der schmied sagt: "+ob->name(wer)+" besteht aus ...\n");
+     while(i--) {
+      // den namen erkennen/aussprechen:
+      // materialien werden allgemein ganz schlecht erkannt (zu 5%), aber
+      // alles aus metall wird zu +100% gut erkannt ...
+      mname=materialdb->materialname(mat[i], wer,
+	     ({5, ([material_symmetric_recognizability:
+			({matgroup_metal, 100})])}));
+
+      // und nur metalle analysieren ...
+      if(materialdb->materialgroup(([mat[i]:100]),matgroup_metal)>=100) {
+       int j;
+       string *mgr;
+       mgr=materialdb->getmatmembership(mat[i]);
+       j=sizeof(mgr);
+       mgroup=" gehoert zu ";
+       while(j--) {
+        mgroup+=materialdb->groupname(mgr[j]);
+        if(j>0) mgroup+=", ";
+       }
+      } else mgroup=" kenne ich nicht";
+      printf("%-12.12s: %s\n",mname, mgroup);
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Master:	  AddMaterial(), ConvMaterialList(), MaterialGroup(),
+		  GroupName()
+		  GetGroupMembers(), GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/MayAddObject.rst b/doc/sphinx/lfun/MayAddObject.rst
new file mode 100644
index 0000000..f9b6e9f
--- /dev/null
+++ b/doc/sphinx/lfun/MayAddObject.rst
@@ -0,0 +1,56 @@
+MayAddObject()
+==============
+
+FUNKTION
+--------
+::
+
+     int MayAddObject(object ob);
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+     ob - Das Object bei dem geprueft werden soll, ob es noch in den
+          Container passt.
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn ein Objekt in einen Container bewegt wird, prueft move() ueber
+     diese Funktion, ob das Objekt ueberhaupt noch in den Behaelter hinein
+     passt. Dazu uebergibt move() das Objekt das in den Container bewegt
+     werden soll. (In Raeumen ist diese Funktionen ueberschrieben und
+     liefert immer True zurueck.)
+
+RUeCKGABEWERT
+-------------
+::
+
+     1 - wenn das Objekt noch vom Container aufgenommen werden kann.
+     0 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+     invis-Objekte passen immer in den Container hinein!
+     move() ruft diese Funktion nicht auf, wenn in den Flags M_NOCHECK
+     gesetzt war!
+
+SIEHE AUCH
+----------
+::
+
+     MayAddWeight(), PreventInsert(), move(), /std/container/restrictions.c
+
+
+Last modified: 23.09.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/MayAddWeight.rst b/doc/sphinx/lfun/MayAddWeight.rst
new file mode 100644
index 0000000..d4d6f3c
--- /dev/null
+++ b/doc/sphinx/lfun/MayAddWeight.rst
@@ -0,0 +1,73 @@
+MayAddWeight()
+==============
+
+FUNKTION
+--------
+::
+
+     int MayAddWeight(int gewicht);
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+     gewicht
+          Das zu pruefende Gewicht.
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn ein Objekt ein einen Behaelter bewegt wird, prueft move() ueber
+     diese Funktion, ob das Objekt ueberhaupt noch in den Behaelter hinein
+     passt. Dazu uebergibt move() dieser Funktion das Gewicht des zu
+     bewegenden Objektes.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn der Behaelter noch ein gewicht Gramm wiegendes Objekt aufnehmen
+     kann, -1 im anderen Fall.
+
+BEMERKUNGEN
+-----------
+::
+
+     move() ruft diese Funktion nicht auf, wenn in den Flags M_NOCHECK
+     gesetzt war!
+
+BEISPIELE
+---------
+::
+
+     Die entsprechende Abfrage in /std/thing/moving.c sieht etwa
+     folgendermassen aus:
+
+     int weight;
+
+     ...
+     weight = QueryProp(P_TOTAL_WEIGHT);   // Behaelter? Ja => Gesamtgewicht
+     if (!weight)
+       weight = QueryProp(P_WEIGHT);       // Nein: einfaches Gewicht
+
+     if (ziel->MayAddWeight(weight) == -1) // Passt es noch rein?
+       return ME_TOO_HEAVY;                // Nein, entspr. Fehler zurueckgeben
+
+     ...
+
+SIEHE AUCH
+----------
+::
+
+     MayAddObject(), PreventInsert(), move(), /std/container/restrictions.c
+
+
+Last modified: 23.09.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/Message.rst b/doc/sphinx/lfun/Message.rst
new file mode 100644
index 0000000..5bfeffe
--- /dev/null
+++ b/doc/sphinx/lfun/Message.rst
@@ -0,0 +1,40 @@
+Message()
+=========
+
+FUNKTION
+--------
+::
+
+        varargs int Message(string str, int flag)
+
+ARGUMENTE
+---------
+::
+
+        str: Den zu uebermittelnden Text.
+	flag: Beschreibt die Art der Meldung naeher, siehe
+	      /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+        Einem Spieler wird der Text str uebermittelt.
+
+RUECKGABEWERT
+-------------
+::
+
+        1 bei erfolgreicher Uebermittlung
+        0 wenn der Kobold aktiv war
+       <0 wenn Spieler oder verwendetes Verb ignoriert
+          werden
+
+SIEHE AUCH
+----------
+::
+
+     P_IGNORE, TestIgnore()
+
+12. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/ModifyQuestTime.rst b/doc/sphinx/lfun/ModifyQuestTime.rst
new file mode 100644
index 0000000..de4b652
--- /dev/null
+++ b/doc/sphinx/lfun/ModifyQuestTime.rst
@@ -0,0 +1,67 @@
+ModifyQuestTime()
+=================
+
+FUNKTION
+--------
+::
+
+        int ModifyQuestTime(string questname, int zeit)
+
+DEFINIERT IN
+------------
+::
+
+        /std/player/quests.c
+
+ARGUMENTE
+---------
+::
+
+        questname
+          Questname, wie er im Questmaster eingetragen wurde.
+        zeit
+          Zeitpunkt, zu dem die Quest geloest wurde
+
+RUeCKGABEWERT
+-------------
+::
+
+         1 : Questzeitpunkt erfolgreich nachgetragen
+        -1 : keine Zugriffsrechte (nur EM+ und der Tagebuchmaster erlaubt)
+        -2 : Questliste im Spielerobjekt ist unerwartet kein Mapping
+        -3 : Spieler hat diese Quest noch nicht bestanden
+        -4 : kein gueltiger Zeitpunkt uebergeben (kein Integer, Wert < -1
+             oder Wert > time()).
+
+BESCHREIBUNG
+------------
+::
+
+        Mit dieser Funktion kann der Zeitpunkt nachgetragen werden, zu
+        dem ein Spieler eine bestimmte Quest bereits geloest hat. 
+        Als Questname wird dazu der Name angegeben, der im Questmaster 
+        eingetragen ist. Der Zeitpunkt ist als Integer-Wert im ueblichen
+        time()-Format anzugeben. Uebergibt man -1 als <zeit>, dann wird
+        der Tagebuchmaster erneut versuchen, das Logfile einzulesen, 
+        wenn der Spieler das naechste mal sein Abenteuertagebuch liest.
+
+HINWEIS
+-------
+::
+
+        Die Funktion mktime() ist nuetzlich, wenn der Zeitpunkt des 
+        Bestehens einer Quest manuell rekonstruiert werden muss, der
+        Zeitpunkt aber nur als Datums-/Zeitangabe in Textform vorliegt 
+        (etwa aus einem Logfile oder aus der Quest-Feedbackmail).
+
+SIEHE AUCH
+----------
+::
+
+        /secure/questmaster.h, /obj/tools/questtool
+        GiveQuest(L)
+        mktime(E), dtime(SE)
+
+
+Zuletzt geaendert: Mon, 27. Jan. 2015, Arathorn
+
diff --git a/doc/sphinx/lfun/ModifySkill.rst b/doc/sphinx/lfun/ModifySkill.rst
new file mode 100644
index 0000000..fa716fe
--- /dev/null
+++ b/doc/sphinx/lfun/ModifySkill.rst
@@ -0,0 +1,98 @@
+ModifySkill()
+=============
+
+FUNKTION
+--------
+::
+
+    public varargs void ModifySkill(string sname, mixed val,
+                                    int diff, string gilde)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skills.c
+
+ARGUMENTE
+---------
+::
+
+    string sname     der zu aendernde Skill
+    mixed val        Aenderungswert: int fuer SI_SKILLABILITY, sonst mapping
+    int diff         Schwierigkeit (optional: default ist existierendes diff)
+    string gilde     Gilde (optional: default ist eigene Gilde)
+
+BESCHREIBUNG
+------------
+::
+
+    Mit der Methode kann man die Werte eines Skills/Spells veraendern. Dabei
+    wird ein Skill immer in ein Mapping umgewandelt (Skills/Spells koennen
+    auch einfach nur ihren Skillwert enthalten, diese ist aequivalent zu
+    einem Mapping mit ([SI_SKILLABILITY:<Skillwert>]).
+
+    Ist 'val' ein int, wird dieses als SI_SKILLABILITY gesetzt. Falls der
+    Skill nur ein int war, wird ein 'diff'!=0 als SI_DIFFICULTY gesetzt.
+
+    Ist 'val' ein Mapping, wird dieses zum Skillmapping addiert.
+
+    
+
+    Etwaige SI_SKILLABILITY-Aenderungen laufen danach noch durch LimitAbility.
+
+BEISPIELE
+---------
+::
+
+    // #1a: Lerne einen Spell/Skill (einer Gilde)
+    caster->ModifySkill("feuerball", MAX_ABILITY, 100, "abenteurer")
+    // #1b: ... oder ...
+    caster->ModifySkill("feuerball", ([SI_SKILLABILITY: MAX_ABILITY]), 100,
+                        "abenteurer")
+    // #1c: ... oder fuer einen Abenteurer ...
+    caster->ModifySkill("feuerball", ([SI_SKILLABILITY: MAX_ABILITY]), 100);
+
+    
+
+    // #2: Setze eine Skill-Funktion fuer einen Kampfskill des Klerus
+    this_player()->ModifySkill(FIGHT(WT_CLUB),
+                               ([SI_SKILLFUNC: "Keulenkampf",
+                                 SI_DIFFICULTY: 100]),
+                               100, "klerus");
+
+    // #3: Speichere im Skill (also Spieler) eine Option fuer diesen Skill
+    // Vorteil: dieser Eintrag wird dem Spell immer uebergeben
+    caster->ModifySkill("blitz", (["klerus_spell_option": 2]));
+
+    (Code in /doc/beispiele/testobjekte/modifyskillspell_test)
+    // #4: Lerne einen unabhaengigen Spell: ACHTUNG
+    // dieser Spell funktioniert nur solange, wie die Closure existiert,
+    // SI_SKILLABILITY und Spell bleiben jedoch im Spieler gespeichert (!)
+    this_player()->ModifySkill("fnrx",
+      ([SI_CLOSURE:
+          function int (object caster, string skill, mapping sinf) {
+            caster->LearnSkill("fnrx", 1);
+            tell_object(caster, "Peng! Dein Skillwert steigt auf "+
+                                caster->QuerySkillAbility("fnrx")+".\n");
+            return ERFOLG;
+          },
+        SI_SKILLABILITY: 8432]),
+      100,
+      "ANY");
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, LimitAbility
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkill, QuerySkillAbility
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung
+    * Properties:   P_NEWSKILLS
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/ModifySkillAttribute.rst b/doc/sphinx/lfun/ModifySkillAttribute.rst
new file mode 100644
index 0000000..9c4131f
--- /dev/null
+++ b/doc/sphinx/lfun/ModifySkillAttribute.rst
@@ -0,0 +1,135 @@
+ModifySkillAttribute()
+======================
+
+FUNKTION
+--------
+::
+
+    public int ModifySkillAttribute(string atrname, mixed value, 
+                                    int duration)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skill_attributes.c
+
+ARGUMENTE
+---------
+::
+
+    <atrname>   string
+                Name des zu veraendernden Attributes
+                (Definiert in /sys/living/skill_attributes.h)
+
+    <value>     int oder closure
+                Wert des Modifikators
+                oder
+                eine Closure, welche bei Abfrage des betreffenden SAs
+                abgefragt um den Modifikator zu bestimmen.
+
+    <duration>  int
+                Dauer in Sekunden
+
+BESCHREIBUNG
+------------
+::
+
+    Aendert temporaer, d.h. fuer eine bestimmte Zeit, ein Skill-Attribut
+    eines Lebewesen, indem ein Modifikator hinzugefuegt wird.
+
+    
+
+    Der Standardwert eines SA wird von P_SKILL_ATTRIBUTE_OFFSETS festgelegt
+    oder ist 100, wenn besagte Property leer ist.
+    Alle Modifikatoren (negativ wie positiv) werden addiert und bilden
+    zusammen mit dem Standardwert eine Gesamtsumme.
+    Bei allen SAs ausser SA_QUALITY wird diese Gesamtsumme noch mit
+    SA_QUALITY (welches sich damit auf alle anderen Skill-Attribute
+    auswirkt) multipliziert und das Ergebnis stellt den Endwert des SA dar.
+    (Beispiel s.u.)
+
+    Der Wert eines Modifikators muss zwischen -1000 und 1000 liegen. Der
+    Gesamtwert eines SA kann 10 nicht unter- und 1000 nicht ueberschreiten.
+
+    Falle <value> eine Closure ist, wird diese Closure jedesmal
+    ausgefuehrt, wenn das entsprechende SA abgefragt wird. Der
+    Rueckgabewert dieser Closure stellt dann den Wert des Modifikators
+    dar. Auch dieser muss zwischen -1000 und 1000 liegen. Gibt die
+    Closure keinen int zurueck, wird der Modifikator geloescht.
+
+    Gueltige Skill-Attribute sind momentan:
+    * SA_QUALITY:    Allgemeine Qualitaet: wirkt sich auf alle anderen
+                     Attribute auch aus (multplikativ auf Basis 100)
+    * SA_DAMAGE:     Schaden, den das Lebewesen macht
+    * SA_SPEED:      Geschwindigkeit des Lebewesens (zB Angriffe/Runde)
+    * SA_DURATION:   Spell-/Skilldauer
+    * SA_ENEMY_SAVE: identisch zu SA_SPELL_PENETRATION (OBSOLET!)
+    * SA_SPELL_PENETRATION: Chance des _Casters_, einen Spell durch ein
+                            P_NOMAGIC durchzukriegen.
+    * SA_RANGE:      Reichweite des Lebewesens (eher unbenutzt)
+    * SA_EXTENSION:  "Ausdehnung" bei Gruppen-/Flaechenspells: FindGroupN/P
+
+RUECKGABEWERT
+-------------
+::
+
+    SA_MOD_OK              wenn der Modifikator gesetzt wurde
+    SA_TOO_MANY_MODS       wenn die max. Anzahl an Mods schon erreicht ist.
+    SA_MOD_TOO_SMALL       wenn der Modifikator zu klein ist 
+    SA_MOD_TOO_BIG         wenn der Modifikator zu gross ist
+    SA_MOD_INVALID_ATTR    wenn das gewuenschte SA gar nicht existiert
+    SA_MOD_INVALID_OBJECT  wenn das setzende Objekt ungueltig ist
+    SA_MOD_INVALID_VALUE   wenn der Modifikator ungueltig ist
+    Wenn man nur wissen will, ob die Operation erfolgreich war, empfiehlt
+    es sich, auf == SA_MOD_OK zu pruefen.
+
+BEMERKUNGEN
+-----------
+::
+
+    Nachdem ein Objekt, welches Modifikatoren setzte, zerstoert wurde,
+    werden die Modifikatoren spaetestens ungueltig, sobald in dem
+    manipulierten Lebewesen erneut ModifySkillAttribute() gerufen wird!
+    Bei Closures ist der Mod sofort weg.
+
+BEISPIELE
+---------
+::
+
+    // sei PL ein Spieler, den mein NPC schwaechen will:
+    PL->ModifySkillAttribute(SA_QUALITY, -75, 13);
+    // Fuer 13s wird SA_QUALITY um 75 reduziert. Dies wirkt sich auf alle
+    // anderen SAs aus! (s. drittes Beispiel)
+
+    // sei PL ein Lebewesen, welchem ich fuer 11s 2 Schlaege pro Kampfrunde
+    // zusaetzlich geben moechte:
+    PL->ModifySkillAttribute(SA_SPEED, 200, 11);
+    // wenn keine weiteres Modifikatoren wirken, hat PL jetzt 3 Schlaege
+    // pro Kampfrunde (Basiswert 100 + 200 == 300 => 3).
+
+    Angenommen, ein Lebewesen hat einen Basiswert von 130 auf SA_SPEED und
+    100 auf SA_QUALITY (P_SKILL_ATTRIBUTE_OFFSETS) und nun 3 Modifikatoren
+    gesetzt: SA_SPEED +100, SA_SPEED -30 und SA_QUALITY von -10:
+    Zunaechst wird SA_QUALITY bestimmt: 100 - 10 = 90  => 0.9
+    Anschliessend wird SA_SPEED bestimmt: 130 + 100 - 30 = 200 => 2
+    Nun wird SA_SPEED noch mit SA_QUALITY multipliziert: 2 * 0.9 = 1.8
+    Das Lebewesen hat nun also im Endeffekt 1.8 Schlaege pro Kampfrunde.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkill
+    * Modifikation: QuerySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung, skill_info_liste
+    * Properties:   P_NEWSKILLS
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/More.rst b/doc/sphinx/lfun/More.rst
new file mode 100644
index 0000000..c5019dc
--- /dev/null
+++ b/doc/sphinx/lfun/More.rst
@@ -0,0 +1,79 @@
+More()
+======
+
+FUNKTION
+--------
+::
+
+     varargs public void More(string txt, int file,
+                              mixed ctrl, mixed *ctrlargs, int flags);
+
+DEFINIERT IN
+------------
+::
+
+     /std/util/pager.c
+
+ARGUMENTE
+---------
+::
+
+     txt  - entweder ein Text der ausgegeben werden soll, oder ein filename.
+     file - das flag file gibt an, ob es sich bei <txt> um einen text oder
+            einen Filenamen handelt. Bei einem Filenamen wird der Inhalt
+            dieses Files eingelesen und ausgegeben.
+     ctrl - Eine closure, die aufgerufen wird, falls kein <txt> angegeben
+            wurde.
+     ctrlargs - ctrlargs wird als Parameter an ctrl uebergeben.
+     flags - flags wird mit den im Spieler definierten P_MORE_FLAGS
+             kombiniert.
+
+BESCHREIBUNG
+------------
+::
+
+     More() dient der Ausgabe von Texten an Spieler. Mit Hilfe eines
+     PL->More(txt) oder PL->More(txt, 1) ist es sehr einfach laengere Texte
+     an Spieler auszugeben. Bei der Ausgabe werden die persoenlichen
+     Einstellungen des Spielern (wie z.b. Zeilen pro Bildschirmseite)
+     automatisch beruecksichtigt und der Text dadurch ggf. zerstueckelt
+     und in mehreren Schritten nacheinander angezeigt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Beim einlesen des Files sind die Leserechte des Spieler in dem More()
+     aufgerufen wird von Bedeutung und nicht die Rechte des Objektes das
+     More() aufruft. Spielerobjekte haben im MorgenGrauen jedoch nur sehr
+     eingeschraenkte Leserechte! Ausgegeben werden koennen nur files
+     aus /p/*, /gilden/* und /d/* die _keinen_ code enthalten. Als Code
+     wird hierbei jedes File betrachtet das als vorletztes Zeichen einen .
+     hat (also .c, .h, .o usw.).
+     Will man aus irgendwelchen Gruenden ein File (z.b. aus /players/)
+     ausgeben, so sollte man stattdessen folgendes verwenden:
+     this_player()->More(read_file(filename))
+
+BEISPIELE
+---------
+::
+
+     // Ausgabe eines normalen textes...
+     this_player()->More("Einfach nur mal so ein Test...\n");
+
+     // Ausgabe eines kompletten files
+     this_player()->More("/etc/WIZRULES", 1);
+
+SIEHE AUCH
+----------
+::
+
+----------------------------------------------------------------------------
+Last modified: Mon Feb 22 15:09:18 1999 by Padreic
+
diff --git a/doc/sphinx/lfun/NPC_Killed_by.rst b/doc/sphinx/lfun/NPC_Killed_by.rst
new file mode 100644
index 0000000..eb0ee42
--- /dev/null
+++ b/doc/sphinx/lfun/NPC_Killed_by.rst
@@ -0,0 +1,36 @@
+NPC_Killed_by()
+===============
+
+FUNKTION
+--------
+::
+
+	void NPC_Killed_By(object pl)
+
+	
+
+ARGUMENTE
+---------
+::
+
+	Spieler, der einen NPC gekillt hat.
+
+	
+
+BESCHREIBUNG
+------------
+::
+
+	Wird in der Gilde des Spielers aufgerufen,
+	wenn dieser einen NPC gekillt hat.
+
+	
+
+RUECKGABEWERT
+-------------
+::
+
+	Keiner
+
+	
+
diff --git a/doc/sphinx/lfun/NewDoor.rst b/doc/sphinx/lfun/NewDoor.rst
new file mode 100644
index 0000000..22cc177
--- /dev/null
+++ b/doc/sphinx/lfun/NewDoor.rst
@@ -0,0 +1,255 @@
+NewDoor()
+=========
+
+FUNKTION
+--------
+::
+
+     varargs int NewDoor(string|string* cmds, string dest, string|string* ids,
+                         mapping|<int|string|string*>* props);
+
+DEFINIERT IN
+------------
+::
+
+     /std/room/doors.c
+
+ARGUMENTE
+---------
+::
+
+     cmds (string|string*)
+          String oder Array von Strings mit den Befehlen, mit denen man
+          durch die Tuer geht (in der Regel Richtungen wie "norden").
+     dest (string)
+          Pfad des Zielraumes, OHNE ".c", sonst wird eine zweiseitige Tuer
+          (wie sie ueblich ist) nicht als solche erkannt.
+     ids (string|string*)
+          String oder Array von Strings mit den Bezeichnern der Tuer. Kann
+          auch 0 sein; in diesem Fall laesst sich die Tuer nur als "tuer"
+          ansprechen.
+     props (mapping|<int|string|string*>*)
+          Die Eigenschaften der Tuer (s.u.).
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird eine neue Tuer geschaffen. Die Tuer laesst sich, wenn sie
+     geoeffnet ist, mit den in <cmds> angegebenen Befehlen durchschreiten.
+     Man gelangt dann in den Raum <dest>.
+
+     Die Kommandos werden bei geoeffneter Tuer in die Liste der sichtbaren
+     Ausgaenge eingefuegt.
+
+     In <props> lassen sich Aussehen und Eigenschaften der Tuer festlegen.
+     Historisch ist es ein Array mit Paaren von Schluesseln und Werten, d.h.
+     es kommt immer erst ein Element, welches die Eigenschaft bezeichnet und
+     dann ein Element mit dem Wert dieser Eigenschaft.
+     Moderner ist es, ein Mapping mit den entsprechenden Schluesseln und
+     Werten zu uebergeben. Dies ist auch dringend empfohlen.
+
+     In <doorroom.h> sind dazu folgende Eigenschaften definiert:
+     D_FLAGS
+          DOOR_OPEN
+               Die Tuer ist beim Erzeugen geoeffnet.
+          DOOR_CLOSED
+               Die Tuer ist beim Erzeugen geschlossen.
+          DOOR_NEEDKEY
+               Man benoetigt einen Schluessel zum Oeffnen der Tuer.
+          DOOR_CLOSEKEY
+               Man benoetigt einen Schluessel zum Schliessen der Tuer.
+          DOOR_RESET_CL
+               Die Tuer schliesst sich beim Reset.
+          DOOR_RESET_OP
+               Die Tuer oeffnet sich beim Reset.
+
+     D_LONG
+          Die Langbeschreibung der Tuer. 
+          Hier kann ein Mapping eingetragen werden, das als Keys den Tuer-
+          Status hat und die zugehoerige Langbeschreibung dazu. Beispiel:
+          ([ D_STATUS_CLOSED : "Die Tuer ist geschlossen.\n",
+             D_STATUS_OPEN   : "Die Tuer ist offen.\n" ])
+
+          
+
+          Default: "Eine Tuer.\n"
+
+     D_SHORT
+          Die Kurzbeschreibung der Tuer. Ein "%s" wird durch "geoeffnet"
+          bzw. "geschlossen" ersetzt.
+
+          Es werden die Kurzbeschreibungen aller im Raum vorhandenen Tueren
+          aneinandergehaengt (es wird jeweils ein Leerzeichen eingeschoben),
+          das Ganze mit break_string() umgebrochen und an P_INT_LONG
+          angehaengt.
+
+          Default: "Eine %se Tuer."
+
+     D_NAME
+          Der Name der Tuer. Dieser Name wird beim Oeffnen und Schliessen
+          der Tuer sowie bei Fehlermeldungen ausgegeben. Man kann wie bei
+          P_NAME einen String oder ein Array von Strings angeben.
+
+          Default: "Tuer"
+
+     D_GENDER
+          Das Geschlecht der Tuer.
+
+          Default: FEMALE
+
+     D_MSGS
+          String oder Array von drei Strings. Diese Strings werden beim
+          Durchschreiten der Tuer an move() als dir bzw. dir, textout und
+          textin uebergeben.
+
+     D_FUNC
+          String mit dem Namen einer Funktion, die im Startraum vor dem
+          Durchschreiten der Tuer aufgerufen werden soll. Diese Funktion
+          kann das Durchschreiten jedoch nicht verhindern!
+
+     D_FUNC2
+          String mit dem Namen einer Funktion, die im Zielraum nach dem
+          Durchschreiten der Tuer aufgerufen werden soll.
+
+     D_TESTFUNC
+          Falls auf den Namen einer Funktion gesetzt, wird diese Funktion
+          vor dem Durchschreiten im Startraum aufgerufen. Wenn sie einen
+          Wert != 0 zurueckliefert, wird die Tuer NICHT durchschritten. 
+
+     D_RESET_MSG
+          Meldung, die beim Reset der Tuer ausgegeben wird.
+
+     D_OPEN_WITH_MOVE
+          Tuer oeffnet automatisch bei Eingabe des Befehls zum 
+          Hindurchgehen.
+
+          
+
+RUECKGABEWERT
+-------------
+::
+
+     1, wenn die Tuer ordungsgemaess eingebaut werden konnte, sonst 0.
+
+BEMERKUNGEN
+-----------
+::
+
+     Zwei Tuerseiten gelten als verschiedene Seiten einer Tuer, wenn als
+     Ziel in Raum A Raum B und in Raum B Raum A angegeben ist. Der Zustand
+     wird abgefragt, wenn der Raum betreten wird (init), wenn die Tuer
+     geoeffnet/geschlossen wird, P_INT_LONG oder P_EXITS abgefragt wird
+     und beim Reset.
+
+     Es sind auch Tueren moeglich, die nur auf einer Seite existieren, oder
+     auch solche, die auf beiden Seiten verschieden aussehen oder gar auf
+     einer Seite nur mit einem Schluessel zu oeffnen sind, auf der anderen
+     jedoch kein Schluessel noetig ist.
+
+     Wer aus irgendeinem Grund den Zustand einer Tuer selber abfragen oder
+     veraendern will, kann dafuer in /obj/doormaster die Funktionen
+     QueryDoorStatus(ziel) bzw. SetDoorStatus(ziel,status) aufrufen.
+
+     *** ACHTUNG ***
+     Es gibt eine Questbelohnung (Phiole aus der Sternenlicht-Quest von
+     Miril), mit der man durch Tueren hindurchschauen kann. Derzeit ist das
+     per default fuer alle Tueren erlaubt. Wenn man das nicht moechte,
+     oder andere Texte ausgeben, als die Phiole normalerweise erzeugt,
+     dann kann man dies durch Nutzung bestimmter Funktionen bzw. Flags
+     erreichen. Zur Dokumentation siehe Manpage zu GetPhiolenInfos().
+
+BEISPIELE
+---------
+::
+
+  ** Dies ist eine gewoehnliche Tuer ohne Besonderheiten und ohne
+     Extra-Beschreibung:
+
+     NewDoor("sueden","/players/rochus/room/test1");
+
+  ** Ein Portal:
+
+     NewDoor("norden","/players/rochus/room/test2",
+             "portal",
+             ([ D_NAME:   "Portal",
+                D_GENDER: NEUTER,
+                D_SHORT:  "Im Norden siehst Du ein %ses Portal.",
+                D_LONG:   "Das Portal ist einfach nur gigantisch.\n",
+              ]) );
+
+     Alternativ mit props in alter Arraynotation:
+     NewDoor("norden","/players/rochus/room/test2",
+             "portal",
+             ({ D_NAME,   "Portal",
+                D_GENDER, NEUTER,
+                D_SHORT,  "Im Norden siehst Du ein %ses Portal.",
+                D_LONG,   "Das Portal ist einfach nur gigantisch.\n"
+              }) );
+
+     
+
+  ** Tueren mit Bewegungsmeldung:
+
+     NewDoor("norden","/room/see2",
+             ({ D_MSGS,  ({"nach Norden","schwimmt",
+                           "kommt hereingeschwommen"}) }) );
+
+  ** Eine Tuer mit Testfunktion:
+
+     NewDoor("osten","/mein/zielraum",
+             ({ D_TESTFUNC, "blocker_da" }) );
+
+     Die Funktion blocker_da:
+
+     int blocker_da()      // KEINE protected-Funktion! Sie wird sonst NICHT
+     {                     // aufgerufen und ausgewertet!
+       if ( present("mein_fieses_mo\nster",this_object()) )
+        {
+         write("Ein fieses Monster stellt sich Dir in den Weg.\n");
+         return 1;
+        }
+       return 0;           // optional
+     }
+
+  ** Nun noch eine Tuer mit einigen Extras:
+
+     NewDoor("nordwesten","/rooms/kammer",
+             ({"tuer","holztuer"}),
+             ({
+               D_FLAGS,  (DOOR_CLOSED|DOOR_RESET_CL),
+               D_MSGS,   ({"nach Nordwesten","geht",
+                         "kommt durch eine Tuer herein"}),
+               D_SHORT,  "Im Nordwesten siehst Du eine %se Holztuer.",
+               D_LONG,   "Sie trennt den Laden vom dahinterliegenden Raum.\n",
+               D_NAME,   "Holztuer",
+               D_FUNC,   "view",
+               D_FUNC2,  "look_up"
+             }) );
+
+     Im Startraum:
+
+     void view()
+     {
+       write("Der Angestellte wirft Dir einen missbilligenden Blick zu, "
+             "laesst Dich aber passieren.\n");
+     }
+
+     Im Zielraum:
+
+     void look_up()
+     {
+       write("Ein alter Mann schaut kurz zu Dir auf und vertieft sich dann "
+             "wieder in seine Akten.\n");
+     }
+
+SIEHE AUCH
+----------
+::
+
+    QueryDoorKey(), QueryDoorStatus(), SetDoorStatus(),
+    /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+
+
+08.02.2015, Arathorn
+
diff --git a/doc/sphinx/lfun/NoParaObjects.rst b/doc/sphinx/lfun/NoParaObjects.rst
new file mode 100644
index 0000000..3b5a1ba
--- /dev/null
+++ b/doc/sphinx/lfun/NoParaObjects.rst
@@ -0,0 +1,47 @@
+NoParaObjects()
+===============
+
+********************** VERALTETE LFUN ****************************
+NoParaObjects()
+
+FUNKTION
+--------
+::
+
+	int NoParaObjects()
+
+DEFINIERT IN
+------------
+::
+
+	/std/virtual/v_compiler.c
+
+RUeCKGABEWERT
+-------------
+::
+
+    1, wenn der VC keine Parawelt-Objekte erzeugt,
+    0, wenn er es doch tut.
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion ist veraltet. QueryValidObject() ist genereller und
+    einfacher zu handhaben. Bitte in Zukunft P_PARA im VC setzen, siehe hierzu
+    die Manpage von QueryValidObject().
+
+    Die Funktion gibt an, ob ein Virtual Compiler auch Parawelt-Objekte
+    erzeugen kann.
+    Wichtig: Entweder dieser Funktion im VC definieren, wenn der VC keine
+    Para-Objekte erzeugen wird oder P_PARA passend setzen!
+
+SIEHE AUCH
+----------
+::
+
+	virtual_compiler, P_PARA, QueryValidObject
+
+
+04.03.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/NotifyDestruct.rst b/doc/sphinx/lfun/NotifyDestruct.rst
new file mode 100644
index 0000000..851c3c8
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyDestruct.rst
@@ -0,0 +1,67 @@
+NotifyDestruct()
+================
+
+FUNKTION
+--------
+::
+
+     public int|string NotifyRemove(object zerstoerer);
+
+ARGUMENTE
+---------
+::
+
+     zerstoerer
+          Das Objekt, welches destruct() auf dieses Objekt anwendet.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird vom Master der Mudlib in jedem Objekt gerufen,
+     welches zerstoert wird, um Objekten eine letzte Chance zu geben, sich
+     aufzuraeumen.
+     Wenn ihr diese Funktion selber definiert, achtet bittet darauf, dass sie
+     in keinem Fall Fehler ausloesen sollte, d.h. testet entsprechend
+     gruendlich.
+     Wenn ihr aus /std/ erbt und diese Funktion ueberschreibt,, _muesst_ ihr
+     die geerbte NotifyDestruct() aufrufen, da sonst das Lichtsystem nicht
+     aktualisiert wird.
+
+     Privilegierte Objekte (z.B. Root-Objekte, spezielle Ausnahmen wie der
+     Netztotenraum, Armageddon) koennen die Zerstoerung in letzter Sekunde
+     verhindern, indem sie hier einen Wert != 0 zurueckliefern. Wird ein
+     string zurueckgeliefert, wird dieser die Fehlermeldung des
+     prepare_destruct() im Master sein.
+     Bei nicht-privilegierten Objekten (also fast alle) ist an dieser Stelle
+     _kein_ Abbruch der Zerstoerung moeglich!
+
+RUeCKGABEWERT
+-------------
+::
+
+     Der Rueckgabewert muss ein string oder ein int sein. Allerdings wird der
+     Master den Rueckgabewert nur fuer privilegierte Objekte auswerten.
+
+BEMERKUNGEN
+-----------
+::
+
+     Wie gesagt, bitte keine Fehler ausloesen (auch wenn der Master
+     grundsaetzlich damit klar kommt). Speziell ist ein raise_error() zur
+     Verhinderung eines destructs nutzlos.
+     Bitte macht in dieser Funkion nur das, was _unbedingt_ notwendig ist.
+     Wenn jemand ein destruct() anwendet statt ein remove() zu rufen, hat das
+     in der Regel einen Grund (z.B. um buggende remove() zu umgehen). Insb.
+     ist ein save_object() in remove() und NotifyDestruct() vollstaendig
+     ueberfluessig.
+
+SIEHE AUCH
+----------
+::
+
+    NotifyLeave(), NotifyInsert(), NotifyRemove()
+
+
+Last modified: 25.02.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/NotifyInsert.rst b/doc/sphinx/lfun/NotifyInsert.rst
new file mode 100644
index 0000000..ee01336
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyInsert.rst
@@ -0,0 +1,48 @@
+NotifyInsert()
+==============
+
+FUNKTION
+--------
+::
+
+     void NotifyInsert(object ob, object oldenv);
+
+ARGUMENTE
+---------
+::
+
+     ob
+          Das Objekt, das in den Behaelter eingefuegt wurde.
+     oldenv
+          Das Objekt, aus dem <ob> kam.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird im Behaelter aufgerufen, nachdem ein Objekt in
+     besagten Behaelter hinein bewegt wurde. 
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Funktion wird nur im Falle unbelebter Objekte gerufen. Fuer 
+     Lebewesen s. bitte. init().
+
+SIEHE AUCH
+----------
+::
+
+    NotifyLeave(), PreventInsert(), PreventLeave(), move(), NotifyRemove()
+    exit(), init(), NotifyMove(), PreventMove()
+
+
+Last modified: 21.05.2012, Zesstra
+
diff --git a/doc/sphinx/lfun/NotifyLeave.rst b/doc/sphinx/lfun/NotifyLeave.rst
new file mode 100644
index 0000000..47c63bf
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyLeave.rst
@@ -0,0 +1,48 @@
+NotifyLeave()
+=============
+
+FUNKTION
+--------
+::
+
+     void NotifyLeave(object ob, object dest);
+
+ARGUMENTE
+---------
+::
+
+     ob
+          Das Objekt, das aus dem Behaelter entfernt wurde.
+     dest
+          Das Objekt, in das <ob> bewegt wurde.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird im Behaelter aufgerufen, nachdem ein Objekt aus
+     besagten Behaelter entfernt wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Funktion wird nur im Falle unbelebter Objekte gerufen. Fuer
+     Lebewesen s. bitte. exit().
+
+SIEHE AUCH
+----------
+::
+
+    NotifyRemove(), NotifyInsert(), PreventInsert(), PreventLeave(), move(),
+    exit(), init(), NotifyMove(), PreventMove()
+
+
+Last modified: 21.05.2012, Zesstra
+
diff --git a/doc/sphinx/lfun/NotifyMove.rst b/doc/sphinx/lfun/NotifyMove.rst
new file mode 100644
index 0000000..c4cef69
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyMove.rst
@@ -0,0 +1,84 @@
+NotifyMove()
+============
+
+FUNKTION
+--------
+::
+
+     protected void NotifyMove(object dest, object oldenv, int method);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/moving.c
+     /std/living/moving.c
+     /std/player/moving.c
+
+ARGUMENTE
+---------
+::
+
+     dest
+          Das Ziel des Moves bzw. das jetzt aktuelle Environment
+     oldenv
+          Das alte Environment des Objekts
+     method
+          Die Move-Methode(n), mit der/denen bewegt wurde.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird vom move() im Objekt gerufen, sobald die Bewegung im
+     wesentlichen abgeschlossen ist. Sie soll einerseits das Objekt ueber eine
+     stattgefundene Bewegung informieren, aber auch einige Dinge erledigen,
+     die bei der Bewegung stattfinden muessen (bei Livings z.B. das Team
+     nachholen).
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Funktion kann ueberschrieben werden, damit das Objekt Bewegungen
+     mitgekommt, ohne das move() selber zu ueberschreiben oder einen Move-Hook
+     zu setzen. Dabei aber bitte unbedingt beachten:
+     Das geerbte NotifyMove() _MUSS IN JEDEM FALL_ mit aufgerufen werden!
+     Solltet ihr das vergessen, werden eure Objekte buggen. ;-)
+     Die Funktion darf nur objektintern verwendet werden. Beim Ueberschreiben
+     das 'protected' nicht vergessen!
+
+BEISPIELE
+---------
+::
+
+     Eine Bombe, die in Seherhaustruhen explodiert:
+
+     protected void NotifyMove(object dest, object oldenv, int method) {
+         ::NotifyMove(dest, oldenv, method); // WICHTIG!
+         if (objectp(dest) &&
+             load_name(dest) == "/d/seher/haeuser/truhe") {
+             if (find_call_out("explodiere")==-1)
+                 call_out("explodiere",900);
+         }
+         else
+             remove_call_out("explodiere");
+     }
+
+SIEHE AUCH
+----------
+::
+
+     PreventLeave(), NotifyInsert(), NotifyLeave(), MayAddObject(),
+     PreventInsertLiving(), PreventLeaveLiving(), NotifyMove(),
+     PreventMove(), MayAddWeight(), move(), /std/container/restrictions.c
+
+
+Last modified: 04.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/NotifyPlayerDeath.rst b/doc/sphinx/lfun/NotifyPlayerDeath.rst
new file mode 100644
index 0000000..7fe7cfa
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyPlayerDeath.rst
@@ -0,0 +1,99 @@
+NotifyPlayerDeath()
+===================
+
+FUNKTION
+--------
+::
+
+  void NotifyPlayerDeath(object victim,object killer,int lost_exp);
+
+DEFINIERT IN
+------------
+::
+
+  /std/player/life.c
+
+ARGUMENTE
+---------
+::
+
+  victim
+    Getoeteter Spieler.
+  killer
+    Objekt, welches den Spieler getoetet hat.
+  lost_exp
+    Erfahrungspunkte, die der Spieler durch den Tod verloren hat.
+
+BESCHREIBUNG
+------------
+::
+
+  Diese Funktion wird aus dem Spielerobjekt heraus immer dann
+  aufgerufen, wenn der Spieler stirbt und zwar:
+    1) im Gegner, der den Spieler getoetet hat,
+    2) im Environment des getoeteten Spielers,
+    3) in der Gilde des Spielers,
+    4) in allen Objekten in diesem Environment und
+    5) in allen Objekten (auch innerhalb Containern) im Spieler.
+  Der Gegner wird hierbei nur einmal informiert, also bei letzteren
+  Faellen herausgefiltert, falls noetig!
+  Hauptaufgabe dieser Funktion ist es somit, auf Tode von Spielern zu
+  reagieren oder selbige einfach nur mitzuloggen.
+
+  Zu dem Zeitpunkt des Aufrufs dieser Funktion ist der Spieler noch _nicht_
+  Geist und noch _nicht_ im Todesraum - dies wird im Anschluss an den Aufruf
+  der NotifyPlayerDeath() durchgefuehrt.
+
+  
+
+  Aufgerufen wird die Funktion aus '/std/player/life.c' mittels catch() und
+  werden mit limited() auf max. 150k (Gegner, Environment, Gilde) bzw. 80k 
+  (alle anderen Objekte) Ticks beschraenkt.
+  Fehler in dieser Funktion haben somit keine negativen Auswirkungen
+  auf das Sterben des Spielers.
+
+RUeCKGABEWERT
+-------------
+::
+
+  keiner
+
+BEISPIELE
+---------
+::
+
+  Folgendes Beispiel demonstriert beispielsweise, wie man Tode von
+  Spielern mitloggen kann (das Beispiel ist hierbei auf den am
+  haeufigsten auftretenden Fall bezogen, dass nur das toetende Objekt
+  den Tod protokollieren soll):
+
+    void NotifyPlayerDeath(object dead, object killer, int lost_exp) 
+    { 
+      if ( intp(lost_exp) && objectp(dead) && objectp(killer) && 
+           killer==this_object() )
+        write_file( "/log/patryn/dead", sprintf(
+          "%s - %s von %s getoetet. XP: -%d", ctime(), getuid(dead),
+           killer->name(WEM), lost_exp) );
+    }
+
+  Bitte beachten: write_file() schreibt ohne Groessenbegrenzung in das
+  Logfile. Da dies auf Dauer bzw. in Gebieten mit hoher Log-Aktivitaet
+  zu Logfiles von enormer Groesse fuehren kann, ist die Verwendung
+  von write_file() nicht empfehlenswert. Ausnahmen koennen natuerlich
+  mit dem zustaendigen Regionsmagier abgesprochen werden, z.B. fuer
+  begrenzte Anwendung etwa bei sehr starken, selten besiegten Gegnern.
+
+  Weiterhin ist es empfehlenswert, das toetende Objekt (killer) nicht
+  im NotifyPlayerDeath() zu zestoeren, sondern etwas zeitversetzt,
+  damit nicht etwa im nachfolgenden NotifyPlayerDeath() eines anderen
+  Objektes (s.o. Reihenfolge) killer==0 ist.
+
+SIEHE AUCH
+----------
+::
+
+  Defend(), do_damage(), NotifyHpChange(), catch(), write_file(), log_file()
+  P_LAST_DEATH_PROPS
+
+24.03.2012, Zesstra
+
diff --git a/doc/sphinx/lfun/NotifyRemove.rst b/doc/sphinx/lfun/NotifyRemove.rst
new file mode 100644
index 0000000..1c11263
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyRemove.rst
@@ -0,0 +1,46 @@
+NotifyRemove()
+==============
+
+FUNKTION
+--------
+::
+
+     void NotifyRemove(object ob);
+
+ARGUMENTE
+---------
+::
+
+     ob
+          Das Objekt, das aus dem Behaelter entfernt wurde.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird im Behaelter aufgerufen, wenn ein Objekt im
+     besagten Behaelter zerstoert wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Wird nicht gerufen, wenn ein Spielerobjekt zerstoert wird.
+
+SIEHE AUCH
+----------
+::
+
+    NotifyLeave(), NotifyInsert(), PreventInsert(), PreventLeave(), move(),
+    NotifyMove(), PreventMove(),
+    BecomesNetDead()
+
+
+Last modified: 04.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/NotifyTimedAttrModExpired.rst b/doc/sphinx/lfun/NotifyTimedAttrModExpired.rst
new file mode 100644
index 0000000..5a63fbd
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyTimedAttrModExpired.rst
@@ -0,0 +1,38 @@
+NotifyTimedAttrModExpired()
+===========================
+
+FUNKTION
+--------
+::
+
+     void NotifyTimedAttrModExpired(string key)
+
+DEFINIERT IN
+------------
+::
+
+     Push-Methode in notify-Objekten.
+
+ARGUMENTE
+---------
+::
+
+     string key		- der geloeschte Modifier
+
+BESCHREIBUNG
+------------
+::
+
+     Wird aus dem Lebewesen aus aufgerufen, in dem der entsprechenden
+     Modifier soeben ungueltig geworden ist.     
+
+SIEHE AUCH
+----------
+::
+
+     Properties: P_ATTRIBUTES, P_TIMED_ATTR_MOD
+     Methoden:	 SetTimedAttrModifier(L), DeleteTimedAttrModifier(L),
+		 QueryTimedAttrModifier(L)
+
+27. Juli 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/NotifyXMAttrModLimitViolation.rst b/doc/sphinx/lfun/NotifyXMAttrModLimitViolation.rst
new file mode 100644
index 0000000..bd25aa3
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyXMAttrModLimitViolation.rst
@@ -0,0 +1,37 @@
+NotifyXMAttrModLimitViolation()
+===============================
+
+FUNKTION
+--------
+::
+
+      void NotifyXMAttrModLimitViolation()
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/restrictions.c
+
+BESCHREIBUNG
+------------
+::
+
+     Wird gerufen wenn die Summe der in P_X_ATTR_MOD oder P_X_ATTR_MOD
+     angegebenen Modifikatoren die Summe aller Modifikatoren im Spieler 
+     ueber den zugelassenen Grenzwert hebt und somit nicht mehr in die
+     Berechnung eingeht.
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+     SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+     P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
+     P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+13.Jun.2004, Muadib
+
diff --git a/doc/sphinx/lfun/Pacify.rst b/doc/sphinx/lfun/Pacify.rst
new file mode 100644
index 0000000..8a68c42
--- /dev/null
+++ b/doc/sphinx/lfun/Pacify.rst
@@ -0,0 +1,148 @@
+Pacify()
+========
+
+FUNKTION
+--------
+::
+
+	public int Pacify(object caster)
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Funktion versucht, ein Lebewesen zu befrieden.
+  Will eine Gilde ein Lebewesen befrieden, muss sie hierfuer diese Funktion
+  in dem Lebewesen aufrufen.
+
+  Ein immer befriedbarer NPC kann durch das Setzen von P_ACCEPT_PEACE in einem
+  Lebewesen realisiert werden.
+
+	Standardmaessig funktioniert die Funktion wie folgt:
+  * Kommt der Versuch vom Spellcaster selbst, ist er immer erfolgreich.
+  * Kommt der Versuch von einem Teamkollegen, ist er immer erfolgreich.
+  * Hat das Lebewesen keine Gegner, ist der Versuch immer erfolglos.
+  In diesen Faellen erfolgt auch keine Erhoehung des Befriedezaehlers.
+
+  
+
+  In anderen Faellen wird die in P_PEACE_HISTORY fuer die Gilde des Casters
+  abgelegte Zahl erfolgreicher Befriedungen (ANZ), die Intelligenz des
+  Casters (INT_CASTER) und die Intelligenz des Lebenwesens selber (INT_ME)
+  ermittelt.
+  Anschliessend wird eine Wahrscheinlichkeit w ausgerechnet:
+
+  
+
+    w = (INT_CASTER + 10 - ANZ*4) / (INT_ME + 10)
+
+  
+
+  Hierbei gibt w die Chance auf eine erfolgreiche Befriedung an. Mittels einer
+  Zufallszahl wird bestimmt, ob der aktuelle Versuch erfolgreich ist. Falls
+  ja, wird der Zaehler fuer die Gilde des Casters in P_PEACE_HISTORY erhoeht.
+
+  Je oefter ein Lebewesen als von einer Gilde schon befriedet wurde, desto
+  unwahrscheinlicher, dass es erneut darauf 'hereinfaellt'.
+
+BEMERKUNGEN
+-----------
+::
+
+  *	Die Funktion kann auch ueberschrieben werden, um ein vom Magier
+    gewuenschtes Verhalten zu realisieren. Ein komplettes Abhaengen von
+    Befriedungen sollte dabei aber die Ausnahme sein!
+  * Diese Funktion verwaltet auch das P_PEACE_HISTORY, speziell die Reduktion
+    der Erfolgszaehler. Ueberschreibt man sie ohne das geerbte Pacify()
+    zu nutzen, wird P_PEACE_HISTORY nicht mehr verwaltet.
+
+RUECKGABEWERTE
+--------------
+::
+
+    1 - das Lebewesen wurde erfolgreich befriedet..
+    0 - der Befriedeversuch ist gescheitert.
+
+    
+
+BEISPIELE
+---------
+::
+
+    Angenommen, der Caster hat eine Intelligenz von 22. Die folgende Tabelle
+    gibt dann die Wahrscheinlichkeiten fuer eine erfolgreiche Befriedung an:
+    (in Abhaengigkeit von eigener Intelligenz und vergangener erfolgreicher
+     Versuche)
+ INT_ME  Erfolgswahrscheinlichkeiten je nach Anzahl erfolgreicher Versuche
+              1       2       3       4       5       6       7       8
+      0     280     240     200     160     120      80      40       0
+      2  233,33     200  166,67  133,33     100   66,67   33,33       0
+      4     200  171,43  142,86  114,29   85,71   57,14   28,57       0
+      6     175     150     125     100      75      50      25       0
+      8  155,56  133,33  111,11   88,89   66,67   44,44   22,22       0
+     10     140     120     100      80      60      40      20       0
+     12  127,27  109,09   90,91   72,73   54,55   36,36   18,18       0
+     14  116,67     100   83,33   66,67      50   33,33   16,67       0
+     16  107,69   92,31   76,92   61,54   46,15   30,77   15,38       0
+     18     100   85,71   71,43   57,14   42,86   28,57   14,29       0
+     20   93,33      80   66,67   53,33      40   26,67   13,33       0
+     22    87,5      75    62,5      50    37,5      25    12,5       0
+     24   82,35   70,59   58,82   47,06   35,29   23,53   11,76       0
+     26   77,78   66,67   55,56   44,44   33,33   22,22   11,11       0
+     28   73,68   63,16   52,63   42,11   31,58   21,05   10,53       0
+     30      70      60      50      40      30      20      10       0
+     32   66,67   57,14   47,62    38,1   28,57   19,05    9,52       0
+     34   63,64   54,55   45,45   36,36   27,27   18,18    9,09       0
+     35   62,22   53,33   44,44   35,56   26,67   17,78    8,89       0
+     36   60,87   52,17   43,48   34,78   26,09   17,39     8,7       0
+     38   58,33      50   41,67   33,33      25   16,67    8,33       0
+     40      56      48      40      32      24      16       8       0
+     42   53,85   46,15   38,46   30,77   23,08   15,38    7,69       0
+     44   51,85   44,44   37,04   29,63   22,22   14,81    7,41       0
+     46      50   42,86   35,71   28,57   21,43   14,29    7,14       0
+     48   48,28   41,38   34,48   27,59   20,69   13,79     6,9       0
+     50   46,67      40   33,33   26,67      20   13,33    6,67       0
+     52   45,16   38,71   32,26   25,81   19,35    12,9    6,45       0
+     54   43,75    37,5   31,25      25   18,75    12,5    6,25       0
+     56   42,42   36,36    30,3   24,24   18,18   12,12    6,06       0
+     58   41,18   35,29   29,41   23,53   17,65   11,76    5,88       0
+     60      40   34,29   28,57   22,86   17,14   11,43    5,71       0
+     62   38,89   33,33   27,78   22,22   16,67   11,11    5,56       0
+     64   37,84   32,43   27,03   21,62   16,22   10,81    5,41       0
+     66   36,84   31,58   26,32   21,05   15,79   10,53    5,26       0
+     68    35,9   30,77   25,64   20,51   15,38   10,26    5,13       0
+     70      35      30      25      20      15      10       5       0
+     72   34,15   29,27   24,39   19,51   14,63    9,76    4,88       0
+     74   33,33   28,57   23,81   19,05   14,29    9,52    4,76       0
+     76   32,56   27,91   23,26    18,6   13,95     9,3    4,65       0
+     78   31,82   27,27   22,73   18,18   13,64    9,09    4,55       0
+     80   31,11   26,67   22,22   17,78   13,33    8,89    4,44       0
+     82   30,43   26,09   21,74   17,39   13,04     8,7    4,35       0
+     84   29,79   25,53   21,28   17,02   12,77    8,51    4,26       0
+     86   29,17      25   20,83   16,67    12,5    8,33    4,17       0
+     88   28,57   24,49   20,41   16,33   12,24    8,16    4,08       0
+     90      28      24      20      16      12       8       4       0
+     92   27,45   23,53   19,61   15,69   11,76    7,84    3,92       0
+     94   26,92   23,08   19,23   15,38   11,54    7,69    3,85       0
+     96   26,42   22,64   18,87   15,09   11,32    7,55    3,77       0
+     98   25,93   22,22   18,52   14,81   11,11    7,41     3,7       0
+    100   25,45   21,82   18,18   14,55   10,91    7,27    3,64       0
+
+SIEHE AUCH
+----------
+::
+
+        P_ACCEPT_PEACE, P_PEACE_HISTORY
+
+LETZTE AENDERUNG
+----------------
+::
+
+07.06.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/PayIn.rst b/doc/sphinx/lfun/PayIn.rst
new file mode 100644
index 0000000..5345462
--- /dev/null
+++ b/doc/sphinx/lfun/PayIn.rst
@@ -0,0 +1,73 @@
+PayIn()
+=======
+
+FUNKTION
+--------
+::
+
+     varargs void PayIn(int amount, int percent);
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/zentralbank.c
+
+ARGUMENTE
+---------
+::
+
+     int amount	-	einzuzahlender Betrag
+     int percent -	Bewertungsprozentsatz
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird Brutto amount Geld in die Bank eingezahlt. Der Prozentsatz legt
+     fest, wieviel tatsaechlich gutgeschrieben wird:
+     Gutschrift = amount*percent/100
+
+     Wird percent nicht angegeben, dann wird der derzeitige Bankbewertungs-
+     massstab fuer Geld angenommen.
+
+BEISPIELE
+---------
+::
+
+     #include <bank.h>
+     ...
+     AddCmd("spende",#'action_spende,
+	    "Was willst du spenden?");
+     ...
+     int action_spende(string str, extra *o) {
+      int i;
+      if(sscanf("%d muenze",i)==1 && i>0)
+       if(this_player()->QueryMoney(i) && this_player()->AddMoney(-i)) {
+        write("Du spendest "+i+" Muenzen.\n");
+	say(this_player()->Name(WER)+" spendet "+i+" Muenzen.\n");
+	ZENTRALBANK->PayIn(i);
+
+	
+
+       } else
+        write("Soviel hast du nicht dabei!\n");
+      ...
+
+BEMERKUNGEN
+-----------
+::
+
+     Unsere Zentralbank ist korrupt, vor allem dadurch, dass in Laeden und
+     an anderen Stellen Geld erzeugt wird.
+
+SIEHE AUCH
+----------
+::
+
+     Geldhandling:	AddMoney(L), QueryMoney(L)
+     Zentralbank:	WithDraw(L), _query_current_money(L)
+     Sonstiges:		/items/money.c, /sys/bank.h
+
+27. Apr 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/PlayerQuit.rst b/doc/sphinx/lfun/PlayerQuit.rst
new file mode 100644
index 0000000..dcc6049
--- /dev/null
+++ b/doc/sphinx/lfun/PlayerQuit.rst
@@ -0,0 +1,39 @@
+PlayerQuit()
+============
+
+FUNKTION
+--------
+::
+
+    void PlayerQuit(object pl);
+
+GERUFEN VON
+-----------
+::
+
+    /std/player/base.c
+
+ARGUMENTE
+---------
+::
+
+    object pl
+      Spieler, der Verbindung beendet
+
+BESCHREIBUNG
+------------
+::
+
+    Wird im environment() gerufen, wenn der Spieler das MUD mit "ende"
+    verlaesst.
+
+SIEHE AUCH
+----------
+::
+
+    BecomesNetAlive(), BecomesNetDead()
+
+    
+
+24. Aug 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/PresentEnemies.rst b/doc/sphinx/lfun/PresentEnemies.rst
new file mode 100644
index 0000000..a774a12
--- /dev/null
+++ b/doc/sphinx/lfun/PresentEnemies.rst
@@ -0,0 +1,96 @@
+PresentEnemies()
+================
+
+FUNKTION
+--------
+::
+
+	object *PresentEnemies();
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+	keine
+
+RUeCKGABEWERT
+-------------
+::
+
+	anwesende Feinde
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Funktion liefert genau die Feinde zurueck, die sich derzeit im
+	selben Raum befinden. Die Feinde unterliegen hierbei noch gewissen
+	Einschraenkungen:
+	  (1) Sie duerfen als NPC nicht gestorben sein, das heisst, sie
+	      muessen als Objekt noch existieren.
+	  (2) Sie duerfen als Spieler nicht gestorben sein, das heisst, sie
+	      duerfen keine Geister sein (Property P_GHOST nicht gesetzt).
+	  (3) Sie muessen angreifbar sein, das heisst, die Property
+	      P_NO_ATTACK darf nicht gesetzt sein.
+	Wird eine dieser Bedingungen verletzt, so wird der Gegner aus der
+	internen Gegnerliste entfernt. Zusaetzlich gilt:
+	  Netztote werden nur als Gegner erkannt, wenn keine anderen Gegner
+	  zur Verfuegung stehen.
+
+BEISPIEL
+--------
+::
+
+	Im Folgenden erblinden alle Gegner im Raum:
+	  string blindThemAll()
+	  { ob*livList;
+	    if(!livList=PresentEnemies())
+	      return break_string(
+	 "Mist...keiner da, der blind werden moechte.",77,
+	 Name(WER)+" grummelt: ");
+	    for(i=sizeof(livList);i--;)
+	    { if(livList[i]->QueryProp(P_BLIND))
+	      { tell_object(this_object(),break_string(
+	 livList[i]->Name(WER)+" ist schon blind.",77));
+	        continue;
+	      }
+	      tell_object(this_object(),break_string(
+	 "Du kratzt "+livList[i]->name(WEM)+" die Augen aus.",77));
+	      tell_object(livList[i],break_string(
+	 Name(WER)+" kratzt Dir die Augen aus!",77));
+	      tell_room(environment(this_object()),break_string(
+	 Name(WER)+" kratzt "+livList[i]->name(WEM)
+	+" die Augen aus.",77),({this_object(),livList[i]}));
+	      livList[i]->SetProp(P_BLIND,1);
+	    }
+	    return"";
+	  }
+	Aufgerufen wird das ganze am Besten in einem Chat:
+	  void create()
+	  { ::create();
+	    ...
+	    SetProp(P_CHAT_CHANCE,10);
+	    SetChats(20,({break_string(
+	 "Nicht angreifen, sonst wirst Du noch blind!",77,
+	 Name(WER)+" bruellt: "),
+	                  "@@blindThemAll@@"}));
+	  }
+	Natuerlich sind auch noch mehr Funktionen und Meldungen als Chats
+	moeglich: Die zwei im Beispiel sind im Normalfall etwas wenig.
+
+SIEHE AUCH
+----------
+::
+
+	SelectEnemy(), QueryEnemies(), IsEnemy(), P_GHOST, P_NO_ATTACK,
+	SetChats, P_CHAT_CHANCE
+
+
+Last modified: Thu May 27 15:01:48 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/PresentEnemyRows.rst b/doc/sphinx/lfun/PresentEnemyRows.rst
new file mode 100644
index 0000000..7bd4ddb
--- /dev/null
+++ b/doc/sphinx/lfun/PresentEnemyRows.rst
@@ -0,0 +1,61 @@
+PresentEnemyRows()
+==================
+
+FUNKTION
+--------
+::
+
+        varargs mixed *PresentEnemyRows(object *here)
+
+DEFINIERT IN
+------------
+::
+
+        /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+        Rueckgabewert von PresentEnemies kann uebergeben werden.
+
+BESCHREIBUNG
+------------
+::
+
+        Ergibt die feindlichen Reihen.
+
+RUECKGABEWERT
+-------------
+::
+
+        Ein Array, bestehend aus MAX_TEAMROWS Arrays mit den Objekten
+        der anwesenden Feinde.
+
+BEMERKUNGEN
+-----------
+::
+
+        Jede Reihe ist Summe der entsprechenden Reihen der
+        anwesenden Teams.
+        Feinde, die in keinem Team sind, stehen im ersten Array.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      AssocMember, DeAssocMember, InsertEnemyTeam,
+                    SelectNearEnemy, SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentTeamPosition,
+                    SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/PresentPosition.rst b/doc/sphinx/lfun/PresentPosition.rst
new file mode 100644
index 0000000..1a30f3c
--- /dev/null
+++ b/doc/sphinx/lfun/PresentPosition.rst
@@ -0,0 +1,59 @@
+PresentPosition()
+=================
+
+FUNKTION
+--------
+::
+
+        varargs int PresentPosition(mixed pmap)
+
+DEFINIERT IN
+------------
+::
+
+        /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+        Rueckgabewert von PresentTeamRows() oder PresentTeamPositions()
+        kann uebergeben werden.
+
+BESCHREIBUNG
+------------
+::
+
+        Ergibt die Nummer der Reihe, in der der Spieler gerade steht.
+
+RUECKGABEWERT
+-------------
+::
+
+        Reihennummer im Bereich von 1 bis TEAM_MAXROWS.
+
+BEMERKUNGEN
+-----------
+::
+
+        Ist ein Spieler in keinem Team, so steht er automatisch in Reihe 1.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      AssocMember, DeAssocMember, InsertEnemyTeam,
+                    SelectNearEnemy, SelectFarEnemy
+        Positionen: PresentRows, PresentEnemyRows, PresentTeamPosition,
+                    SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/PresentRows.rst b/doc/sphinx/lfun/PresentRows.rst
new file mode 100644
index 0000000..e6d3f5e
--- /dev/null
+++ b/doc/sphinx/lfun/PresentRows.rst
@@ -0,0 +1,111 @@
+PresentRows()
+=============
+
+FUNKTION
+--------
+::
+
+    mixed *PresentRows(object env);
+
+DEFINIERT IN
+------------
+::
+
+    TEAM_OBJECT (s. <living/team.h>)
+
+ARGUMENTE
+---------
+::
+
+    object env
+        Das Environment des gewuenschten Objektes.
+
+BESCHREIBUNG
+------------
+::
+
+    Mit dieser Funktion bekommt man die aktuellen Teamreihen, die im Argument
+    env anwesend sind, des Teams zurueckgegeben. Ist env kein Objekt, so
+    wird environment(this_player()) als solches angenommen.
+
+RUECKGABEWERT
+-------------
+::
+
+    Es wird ein mixed-Array zurueckgegeben, dabei sind die einzelnen Reihen
+    selbst wiederum Arrays mit den Spielerobjekten.
+
+BEISPIEL
+--------
+::
+
+    Ein NPC im Kampf laesst eine Feuerwalze auf ein Team los, welche aber nur
+    Spieler in der ersten und zweiten Teamreihe Schaden zufuegen soll.
+
+    void Attack( object enemy )
+    {
+     ...
+
+     object team = enemy->QueryProp(P_TEAM);
+
+     if ( objectp(team) )
+      {
+       mixed teamrows = team->PresentRows(enemy);
+
+//  Inhalt von "teamrows" zu diesem Zeitpunkt:
+
+//  ({ ({[/dwarf:hauweg]}),({}),({[/elf:spitzohr]}),({}),({}),({}) })
+
+//  In der Umgebung von Zwerg Hauweg steht also noch Elf Spitzohr, und zwar
+//  in der dritten Teamreihe (der hat Glueck gehabt).
+//  Wenn dem Team noch mehr Spieler angehoeren, befinden sie sich gerade
+//  nicht in der Umgebung (sprich im selben Raum) wie Hauweg.
+
+       foreach ( i : 2 )
+        {
+         foreach ( object pl : teamrows[i] )
+          {
+           tell_object(pl,"Der Feuerteufel laesst eine Feuerwalze auf Dich "
+               "und Dein Team los.\n");
+
+           pl->Defend(200+random(200),({DT_FIRE}),([SP_SHOW_DAMAGE:1]),TO);
+          }
+        }
+      }
+     else
+      {
+       tell_object(enemy,"Der Feuerteufel laesst eine Feuerwalze auf Dich "
+           "los.\n");
+
+       enemy->Defend(200+random(200),({DT_FIRE}),([SP_SHOW_DAMAGE:1]),TO);
+      }
+
+     ...
+    }
+
+BEMERKUNG
+---------
+::
+
+    Man beachte, dass das erste Argument (also Argument 0) die erste
+    Teamreihe ist.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      AssocMember, DeAssocMember, InsertEnemyTeam,
+                    SelectNearEnemy, SelectFarEnemy
+        Positionen: PresentPosition, PresentEnemyRows, PresentTeamPosition,
+                    SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/PresentTeamPositions.rst b/doc/sphinx/lfun/PresentTeamPositions.rst
new file mode 100644
index 0000000..7a35a90
--- /dev/null
+++ b/doc/sphinx/lfun/PresentTeamPositions.rst
@@ -0,0 +1,61 @@
+PresentTeamPositions()
+======================
+
+FUNKTION
+--------
+::
+
+        varargs mapping PresentTeamPositions(mixed pmap)
+
+DEFINIERT IN
+------------
+::
+
+        /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+        Rueckgabewert von PresentTeamRows() kann uebergeben werden.
+
+BESCHREIBUNG
+------------
+::
+
+        Ermittelt die Reihennummern aller anwesender Teammitglieder.
+
+RUECKGABEWERT
+-------------
+::
+
+        Ein Mapping mit den Reihennummern (von 1 bis MAX_TEAMROWS)
+        der anwesenden Teammitglieder.
+
+BEMERKUNGEN
+-----------
+::
+
+        Kann auch zur Konvertierung anderer Kampfreihen-Arrays in
+        ein Positions-Mapping verwendet werden.
+        Ist der Spieler in keinem Team, so steht er in Reihe 1.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      AssocMember, DeAssocMember, InsertEnemyTeam,
+                    SelectNearEnemy, SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/PresentTeamRows.rst b/doc/sphinx/lfun/PresentTeamRows.rst
new file mode 100644
index 0000000..3356cb6
--- /dev/null
+++ b/doc/sphinx/lfun/PresentTeamRows.rst
@@ -0,0 +1,47 @@
+PresentTeamRows()
+=================
+
+FUNKTION
+--------
+::
+
+	mixed *PresentTeamRows()
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+	keine
+
+BESCHREIBUNG
+------------
+::
+
+	Ergibt die Reihen mit den anwesenden Teammitgliedern.
+
+RUECKGABEWERT
+-------------
+::
+
+	Ein Array bestehend aus MAX_TEAMROWS Arrays mit den Objekten
+        der anwesenden Teammitglieder.
+
+BEMERKUNGEN
+-----------
+::
+
+	Wenn der Spieler in keinem Team ist, enthaelt das erste Array
+	nur den Spieler und die anderen Arrays sind leer.
+
+SIEHE AUCH
+----------
+::
+
+	teams
+
diff --git a/doc/sphinx/lfun/PreventFollow.rst b/doc/sphinx/lfun/PreventFollow.rst
new file mode 100644
index 0000000..1cca2ff
--- /dev/null
+++ b/doc/sphinx/lfun/PreventFollow.rst
@@ -0,0 +1,72 @@
+PreventFollow()
+===============
+
+FUNKTION
+--------
+::
+
+  int PreventFollow(object dest)
+
+ARGUMENTE
+---------
+::
+
+  dest: Zielobjekt, in das der Verfolgte bewegt werden soll.
+
+FUNKTION
+--------
+::
+
+  In jedem Verfolger, der mit AddPursuer in die Liste der Verfolger 
+  eingetragen wurde, wird vor dem Bewegen in das Zielobjekt die Funktion
+  PreventFollow mit dem Zielobjekt als Argument aufgerufen.
+
+RUECKGABEWERT
+-------------
+::
+
+  0: Verfolger darf in das Zielobjekt folgen
+  1: Verfolger darf in dieses Zielobjekt nicht folgen
+     (Verfolgung bleibt weiterhin aktiv)
+  2: Verfolger darf in dieses Zielobjekt nicht folgen
+     (Verfolgung wird abgebrochen und Verfolger aus der Verfolgerliste
+      ausgetragen)
+
+BEMERKUNG
+---------
+::
+
+  Durch PreventFollow kann der raeumliche Bereich, in dem verfolgt werden
+  darf, eingeschraenkt werden.
+
+BEISPIELE
+---------
+::
+
+  Man moechte, dass ein NPC auf einer Insel nicht mit dem Spieler in das
+  Boot steigt, um mit dem Spieler zusammen von der Insel herunterzukommen.
+
+  #define PATH(x) ("/d/.../.../mein/pfad/+(x)")                           
+
+  ...                                          
+
+  int PreventFollow(object boot)                                           
+   {
+    if ( object_name(boot)[0..strlen(PATH("boot"))-1] == PATH("boot") )
+     return 1;
+   }                                                                         
+
+  Diese Funktions-Definition ist sehr flexibel, denn sie erlaubt sowohl
+  spaetere Pfadanpassung als auch mehrere Boote.
+  Da ueber die Funktion strlen() nur bis zum letzten Buchstaben des    
+  angegebenen Strings getestet wird, wird also gleichzeitig auch auf          
+  boot[1], boot[2] usw. getestet.
+
+SIEHE AUCH
+----------
+::
+
+  "AddPursuer", "RemovePursuer"
+
+Last modified: Tue Jun 10 13:59:30 2003 by Gabylon
+
diff --git a/doc/sphinx/lfun/PreventInsert.rst b/doc/sphinx/lfun/PreventInsert.rst
new file mode 100644
index 0000000..2e42639
--- /dev/null
+++ b/doc/sphinx/lfun/PreventInsert.rst
@@ -0,0 +1,72 @@
+PreventInsert()
+===============
+
+FUNKTION
+--------
+::
+
+     int PreventInsert(object ob);
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+     ob
+          Das Objekt, das in den Behaelter eingefuegt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Funktion kann ein Behaelter pruefen, ob er das Objekt ob
+     aufnehmen moechte oder nicht.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn das Objekt aufgenommen werden kann; ein Wert groesser als 0
+     zeigt an, dass das Objekt nicht aufgenommen werden soll.
+
+BEMERKUNGEN
+-----------
+::
+
+     Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventInsert() zwar
+     aufgerufen, das Objekt wird jedoch auf jeden Fall in den Behaelter
+     bewegt, unabhaengig vom Rueckgabewert!
+
+BEISPIELE
+---------
+::
+
+     Um zu verhindern, dass man Geld in einen Behaelter stecken kann, sollte
+     man wie folgt vorgehen:
+
+     varargs int PreventInsert(object ob)
+     {
+       // Wenn es Geld ist, erheben wir sofort Einspruch
+       if (ob->id("geld"))
+         return 1;
+       // Ansonsten koennte ein ererbtes Objekt noch Einspruch erheben!
+       else
+         return ::PreventInsert(ob);
+     }
+
+SIEHE AUCH
+----------
+::
+
+     PreventLeave(), NotifyInsert(), NotifyLeave(), MayAddObject(),
+     PreventInsertLiving(), PreventLeaveLiving(), NotifyMove(),
+     PreventMove(), MayAddWeight(), move(), /std/container/restrictions.c
+
+
+Last modified: Sat Dec 18 02:00:00 1999 by Tiamak
+
diff --git a/doc/sphinx/lfun/PreventInsertLiving.rst b/doc/sphinx/lfun/PreventInsertLiving.rst
new file mode 100644
index 0000000..f8d62ec
--- /dev/null
+++ b/doc/sphinx/lfun/PreventInsertLiving.rst
@@ -0,0 +1,57 @@
+PreventInsertLiving()
+=====================
+
+FUNKTION
+--------
+::
+
+     int PreventInsertLiving(object ob);
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+     ob
+          Das Living, das in den Behaelter eingefuegt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Funktion kann ein Behaelter pruefen, ob er das Living ob
+     aufnehmen moechte oder nicht.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn das Living aufgenommen werden kann; ein Wert groesser als 0
+     zeigt an, dass das Living nicht aufgenommen werden soll.
+
+BEMERKUNGEN
+-----------
+::
+
+     Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventInsertLiving() 
+     zwar aufgerufen, das Living wird jedoch auf jeden Fall in den Behaelter
+     bewegt, unabhaengig vom Rueckgabewert!
+
+SIEHE AUCH
+----------
+::
+
+     PreventLeaveLiving(), /std/container/restrictions.c,
+     PreventMove(), PreventInsert(), PreventLeave(),
+     NotifyMove(), NotifyInsert(), NotifyLeave(), NotifyRemove(),
+     move(), init(), exit(),
+     InitAttack(), ExitAttack()
+
+
+Last modified: 04.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/PreventLeave.rst b/doc/sphinx/lfun/PreventLeave.rst
new file mode 100644
index 0000000..e29d213
--- /dev/null
+++ b/doc/sphinx/lfun/PreventLeave.rst
@@ -0,0 +1,58 @@
+PreventLeave()
+==============
+
+FUNKTION
+--------
+::
+
+     int PreventLeave(object ob, mixed dest);
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+     ob
+          Das Objekt, das aus dem Behaelter genommen werden soll.
+     dest 
+          Das Ziel in das das Objekt ob bewegt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Funktion kann ein Behaelter pruefen, ob er das Objekt ob
+     sich bewegen lassen moechte oder nicht.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn das Objekt bewegt werden kann; ein Wert groesser als 0
+     zeigt an, dass das Objekt nicht bewegt werden soll.
+
+BEMERKUNGEN
+-----------
+::
+
+     Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventLeave() zwar
+     aufgerufen, das Objekt wird jedoch auf jeden Fall aus dem Behaelter
+     bewegt, unabhaengig vom Rueckgabewert!
+
+SIEHE AUCH
+----------
+::
+
+     PreventInsert(), NotifyInsert(), NotifyLeave(),
+     MayAddWeight(), move(), /std/container/restrictions.c
+     PreventLeaveLiving(), PreventInsertLiving(), PreventMove(),
+     NotifyMove(), MayAddObject(), NotifyRemove()
+
+
+Last modified: 04.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/PreventLeaveLiving.rst b/doc/sphinx/lfun/PreventLeaveLiving.rst
new file mode 100644
index 0000000..8616cc2
--- /dev/null
+++ b/doc/sphinx/lfun/PreventLeaveLiving.rst
@@ -0,0 +1,58 @@
+PreventLeaveLiving()
+====================
+
+FUNKTION
+--------
+::
+
+     int PreventLeaveLiving(object ob, mixed dest);
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+     ob
+          Das Living, das aus dem Behaelter genommen werden soll.
+     dest 
+          Das Ziel in das das Living ob bewegt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Funktion kann ein Behaelter pruefen, ob er das Living ob
+     sich bewegen lassen moechte oder nicht.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn das Living bewegt werden kann; ein Wert groesser als 0
+     zeigt an, dass das Living nicht bewegt werden soll.
+
+BEMERKUNGEN
+-----------
+::
+
+     Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventLeave() zwar
+     aufgerufen, das Living wird jedoch auf jeden Fall aus dem Behaelter
+     bewegt, unabhaengig vom Rueckgabewert!
+
+SIEHE AUCH
+----------
+::
+
+     PreventInsertLiving(), /std/container/restrictions.c
+     PreventMove(), PreventLeave(), PreventInsert(),
+     NotifyMove(), NotifyLeave(), NotifyInsert(), NotifyRemove(),
+     move(), exit(), init(),
+     InitAttack, ExitAttack()
+
+Last modified: 04.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/PreventMove.rst b/doc/sphinx/lfun/PreventMove.rst
new file mode 100644
index 0000000..a8a7a5a
--- /dev/null
+++ b/doc/sphinx/lfun/PreventMove.rst
@@ -0,0 +1,110 @@
+PreventMove()
+=============
+
+PreventInsert()
+---------------
+::
+
+FUNKTION
+--------
+::
+
+     protected int PreventMove(object dest, object oldenv, int method);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/moving.c
+     /std/living/moving.c
+     /std/player/moving.c
+
+ARGUMENTE
+---------
+::
+
+     dest
+          Das Ziel des Moves
+     oldenv
+          Das (Noch-)Environment des Objekts
+     method
+          Die Move-Methode(n), mit der/denen bewegt werden soll
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Funktion prueft ein Objekt, ob es von 'oldenv' nach 'dest'
+     bewegt werden mag. Dabei wird 'method' beruecksichtigt (z.B. schaltet
+     M_NOCHECK die meisten Pruefungen ab).
+     Bei Gegenstaenden wird z.B. P_NODROP, P_NOGET, das Gewicht, ob das Ziel
+     das Objekt aufnehmen will (MayAddWeight(), PreventInsert) oder auch
+     PreventLeave() geprueft.
+     Bei Lebewesen wird z.B. P_NO_TPORT in 'dest' und 'oldenv' und
+     PreventLeaveLiving/PreventInsertLiving() ausgewertet.
+     Bei Spielern wird auch noch getestet, ob method M_GO oder M_TPORT
+     enthaelt und ob das Ziel nur von Testspielern betreten werden kann.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn das Objekt bewegt werden darf.
+     Wenn es nicht bewegt werden darf, sind als Rueckgabewerte die in
+     /sys/moving.h definierten Move-Fehlerwerte zulaessig (s. move()). Sollte
+     hier ein ungueltiger Fehlerwert zurueckgegeben werden, wird das move()
+     ebenfalls abgebrochen und ME_DONT_WANT_TO_BE_MOVED zurueckgeben.
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Funktion kann ueberschrieben, um feinere Kontrolle ueber die
+     Bewegungen des Objekt zu haben. Dabei aber bitte einige Dinge beachten:
+     1. Denkt daran, ggf. M_NOCHECK zu beruecksichtigen und und eure
+     Pruefungen nur zu machen, wenn es nicht in method vorkommt.
+     2. GANZ WICHTIG: Wenn ihr mit euren Pruefungen fertig sein und das Objekt
+     bewegt werden duerfte, die geerbten Pruefungen noch testen, also _IMMER_
+     das geerbte PreventMove() noch aufrufen und dessen Wert
+     zurueckgeben/beruecksichtigen, da sonst Pruefungen des Gewichts etc. 
+     nicht funktionieren oder bei Lebewesen die Prevent*() im Environment 
+     nicht gerufen werden!
+     3. Die Funktion ist nur objektintern zu verwenden, Call-Other von aussen
+     sind nicht moeglich, beim Ueberschreiben 'protected' nicht vergessen.
+     4. Nochmal: Geerbtes PreventMove() _NICHT VERGESSEN_!
+
+BEISPIELE
+---------
+::
+
+     Ein Objekt, was nur im Sternenlicht aufgenommen werden kann (warum
+     auch immer):
+
+     protected int PreventMove(object dest, object oldenv, int method) {
+       if ( (method & M_NOCHECK) ) {
+           // wenn mit M_NOCHECK bewegt, ist das Sternenlicht egal, nur
+           // geerbtes PreventMove() beruecksichten:
+           return ::PreventMove(dest, oldenv, method);
+       }
+       else if ( method & M_GET) {
+           // wenn es aufgenommen werden soll: nach Sternenlicht im Raum
+           // gucken:
+           if (objectp(dest) && 
+               (dest->QueryProp(P_LIGHT_TYPE) != LT_STARS))
+               return ME_CANT_BE_TAKEN;
+       }
+       // Fall-through:
+       return ::PreventMove(dest, oldenv, method);
+     }
+
+SIEHE AUCH
+----------
+::
+
+     PreventLeave(), NotifyInsert(), NotifyLeave(), MayAddObject(),
+     PreventInsertLiving(), PreventLeaveLiving(), NotifyMove(),
+     PreventMove(), MayAddWeight(), move(), /std/container/restrictions.c
+
+
+Last modified: 04.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/Query.rst b/doc/sphinx/lfun/Query.rst
new file mode 100644
index 0000000..0a27959
--- /dev/null
+++ b/doc/sphinx/lfun/Query.rst
@@ -0,0 +1,108 @@
+Query()
+=======
+
+FUNKTION
+--------
+::
+
+     public varargs mixed Query(string name, int Type);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/properties.c
+
+ARGUMENTE
+---------
+::
+
+     string name - Property, deren Wert(e) ausgelesen werden
+     int type  - Art der gewuenschten Information.
+
+BESCHREIBUNG
+------------
+::
+
+     Der Wert einer der inneren Eigenschaften der Property 'name' wird
+     zurueckgegeben.  'Type' ist dabei einer der in /sys/thing/properties.h
+     und folgend aufgelisteten F_XXX-Werte:
+
+     F_VALUE (==0, Default)
+         Unter Umgehung einer eventuell vorhandenen Abfragemethode oder
+         _query_'name'() wird der Datenwert der Property 'name'
+         zurueckgegeben.
+     F_MODE
+          Die internen Flags der Property werden zurueckgegeben.Dies koennen
+          (logisch mit & verknuepft) sein:
+          SAVE  - Property soll bei save_object() gespeichert werden
+          PROTECTED - Objekt selbst/EM/Root kann Property manipulieren
+          SECURED  - wie PROTECTED, das Flag kann aber nicht
+                     zurueckgesetzt werden (immer SECURED)
+          NOSETMETHOD - niemand kann Property manipulieren
+                        (auch kein F_SET_METHOD oder _set_'name'())
+     F_SET_METHOD
+          Ein eventuell fuer die Property eingetragene F_SET_METHOD wird
+          zurueckgegeben.
+          (_set_'name'()-Methoden werden so nicht aufgefuehrt!)
+     F_QUERY_METHOD
+          Ein eventuell fuer die Property eingetragene F_QUERY_METHOD wird
+          zurueckgegeben.
+          (_query_'name'()-Methoden werden so nicht aufgefuehrt!)
+
+RUeCKGABEWERT
+-------------
+::
+
+     Die gewuenschte Eigenschaft, abhaengig von 'Type'.
+
+BEMERKUNGEN
+-----------
+::
+
+     - Query() sollte nicht zum regulaeren Auslesen des Inhalt einer
+       Property verwendet werden, da sowohl F_QUERY_METHOD als auch
+       libinterne _query_'name'()-Methoden umgangen werden und das Ergebnis
+       fuer so veraenderte Propertys undefiniert ist
+     - _set_'name'() und _query_'name'() sind alte Propertymethoden und
+       sollten nicht in normalen Objekten benutzt werden ->
+       F_SET_METHOD/F_QUERY_METHOD (ggf. mit PROTECTED) nutzen
+     - F_SET/F_QUERY_METHODs koennen 'protected' (empfohlen) oder 'static'
+       sein. _set_/_query_ duerfen momentan _nicht_ 'protected' sein, fuer
+       diese geht nur 'static' (in diesem Fall empfohlen).
+
+BEISPIELE
+---------
+::
+
+     // Auslesen des Wertes unter Umgehung einer Abfragemethode
+     Query(P_XYZ, F_VALUE);
+
+     // Auslesen der Flags erfaehrt man mit:
+     Query(P_XYZ, F_MODE);
+
+     // sauberes Programmieren, wir wollen eine F_QUERY_METHOD setzen,
+     // pruefen vorher auf Existenz:
+     if(this_player()->Query(P_FROG, F_QUERY_METHOD) {
+      write(break_string(
+       "Ich kann dich nicht weiter vor Froschsein schuetzen!",
+       "Der Magier winkt ab: ", 78));
+      say(break_string(
+       "Ich kann dich nicht weiter vor Froschsein schuetzen!",
+       "Der Magier sagt zu "+this_player()->name(WEM)+": ", 78));
+     } else {
+      this_player()->Set(P_FROG, #'query_protect_frog, F_QUERY_METHOD);
+      ...
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: SetProp(L), QueryProp(L), Set(L)
+     Generell:  SetProperties(L), QueryProperties(L)
+     Konzept:  properties, /std/thing/properties.c
+     Sonstiges:  P_AUTOLOADOBJ
+
+28.03.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/QueryAllDoors.rst b/doc/sphinx/lfun/QueryAllDoors.rst
new file mode 100644
index 0000000..9980ad0
--- /dev/null
+++ b/doc/sphinx/lfun/QueryAllDoors.rst
@@ -0,0 +1,53 @@
+QueryAllDoors()
+===============
+
+FUNKTION
+--------
+::
+
+     mapping QueryAllDoors();
+
+DEFINIERT IN
+------------
+::
+
+     /obj/doormaster.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Es werden die Zustaende ALLER Tueren im MorgenGrauen ermittelt.
+
+RUECKGABEWERT
+-------------
+::
+
+     Ein Mapping mit den Zustaenden aller Tueren im MorgenGrauen. Als
+     Schluessel dienen die Dateinamen der Start- und Zielraeume in
+     lexikographischer (alphabetischer) Reihenfolge, getrennt durch ":",
+     der Wert des Keys ist der aktuelle Zustand dieser Tuer, z.B.:
+
+    ([ "/d/inseln/schiffe/jolle:/d/inseln/schiffe/jolle/masch" : -1,
+       ...
+     ]);
+
+     Es gibt also eine Tuer zwischen Jolle und Maschinenraum, die
+     momenten geschlossen ist (-1 = D_STATUS_CLOSED).
+
+SIEHE AUCH
+----------
+::
+
+    NewDoor(), QueryDoorKey(), QueryDoorStatus(), SetDoorStatus(),
+    /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), P_DOOR_INFOS
+
+
+Letzte Aenderung: Don, 08.05.2014, Gabylon
+
diff --git a/doc/sphinx/lfun/QueryArmourByType.rst b/doc/sphinx/lfun/QueryArmourByType.rst
new file mode 100644
index 0000000..17e6967
--- /dev/null
+++ b/doc/sphinx/lfun/QueryArmourByType.rst
@@ -0,0 +1,91 @@
+QueryArmourByType()
+===================
+
+QyeryArmourByType()
+-------------------
+::
+
+FUNKTION
+--------
+::
+
+     mixed QueryArmourByType(string type)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+     string type
+        Typ der Ruestung aus /sys/combat.h, auf die getestet werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Abfrage, ob das Lebewesen eine Ruestung des angegebenen Typs traegt.
+
+     Zurueckgegeben wird je nach Tragestatus und <type>:
+     * 0, falls das Lebewesen die gesuchte Ruestungsart nicht traegt
+     * im Erfolgsfall das Ruestungsobjekt
+     * falls <type> AT_MISC ist:
+       * ({}), wenn es keine AT_MISC-Ruestung traegt
+       * ein Array von AT_MISC-Ruestungen
+     * falls <type> 0 ist: ein Mapping, das diese Informationen mit dem
+       Ruestungstypen als Schluessel enthaelt:
+       ([AT_MISC: ({[object], ...}),
+         AT_...: <object>,
+         ... ])
+
+BEMERKUNG
+---------
+::
+
+     Ist <type> AT_MISC, so wird auf jeden Fall ein Array zurueckgegeben!
+
+BEISPIELE
+---------
+::
+
+     Wir wollen wissen, ob this_player() Handschuhe traegt:
+
+     if (objectp(this_player()->QueryArmourByType(AT_GLOVE)))
+       ...
+
+
+     Wir bauen einen Tuersteher, der auf AT_MISC-Kleidung achtet:
+
+     if (sizeof(this_player()->QueryArmourByType(AT_MISC)) > 3) {
+       if(this_player()->ReceiveMsg(
+            "Du darfst nicht passieren, Du hast zuviele "
+            "unpassende Dinge an!",
+            MT_LISTEN|MSG_DONT_STORE, MA_TELL,
+            "Der Waechter teilt Dir mit: ")<MSG_DELIVERED && // taub?
+          this_player()->ReceiveMsg(
+            "Der Waechter haelt dich auf.", MT_LOOK)<MSG_DELIVERED) // blind?
+            this_player()->ReceiveMsg(
+              "Jemand haelt dich auf.", MT_FEEL); // nu aber!
+       // Aufhalten!
+     } else this_player()->ReceiveMsg(
+              "Du darfst passieren, viel Spass im Casino!",
+              MT_LISTEN|MSG_DONT_STORE, MA_TELL,
+              "Der Waechter teilt Dir mit: ");
+       // im Erfolgsfall ist es uns egal, wenn es der Spieler nicht
+       // liest: er wird dann eben "wortlos" durchgelassen
+
+SIEHE AUCH
+----------
+::
+
+     Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour(),
+     UnwearClothing(), FilterClothing(),
+     P_ARMOUR_TYPE, P_CLOTHING, P_ARMOURS,
+     /std/living/combat.c
+
+02.02.2016, Gloinson
+
diff --git a/doc/sphinx/lfun/QueryArrived.rst b/doc/sphinx/lfun/QueryArrived.rst
new file mode 100644
index 0000000..2ae07e9
--- /dev/null
+++ b/doc/sphinx/lfun/QueryArrived.rst
@@ -0,0 +1,46 @@
+QueryArrived()
+==============
+
+FUNKTION
+--------
+::
+
+     mixed QueryArrived();
+
+DEFINIERT IN
+------------
+::
+
+     /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion ermittelt, ob sich der Transporter momentan an einer
+     Haltestelle befindet (und bestiegen oder verlassen werden kann) oder ob
+     er unterwegs ist.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Null, wenn der Transporter unterwegs ist. Liegt der Transporter an
+     einer Haltestelle, so wird der mit AddRoute als name uebergebene String
+     zurueckgegeben.
+
+SIEHE AUCH
+----------
+::
+
+     AddRoute(), /std/transport.c
+
+
+Last modified: Wed May 8 10:21:47 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryArticle.rst b/doc/sphinx/lfun/QueryArticle.rst
new file mode 100644
index 0000000..4076520
--- /dev/null
+++ b/doc/sphinx/lfun/QueryArticle.rst
@@ -0,0 +1,118 @@
+QueryArticle()
+==============
+
+FUNKTION
+--------
+::
+
+     varargs string QueryArticle(int casus, int dem, int force);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+     casus
+          Der Fall, in dem der Artikel gewuenscht wird.
+          (Konstanten aus /sys/thing/language.h: WER, WEM, WESSEN, WEN.)
+
+     dem
+          Wird ein bestimmter oder ein unbestimmter Artikel verlangt?
+             + dem = 0: Unbestimmter Artikel!
+             + dem = 1: Bestimmter Artikel!
+             + dem = 2: Finde selbst heraus, welcher Artikel passt!
+
+     force
+          Falls ungleich Null, so wird auf jeden Fall ein Artikel
+          zurueckgegeben, trotz P_ARTICLE == 0.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion gibt einen zum Geschlecht des Objektes passenden Artikel
+     zurueck, der in den passenden Fall dekliniert wird.
+
+     Das Herausfinden des passenden Artikels bei 'dem' = 2 bezieht sich auf
+     Situationen, in denen mehrere gleichnamige Objekte im selben Environment
+     sind. Man 'nimmt' dann zB nicht "den Stamm" sondern "einen Stamm".
+
+     Ist P_ARTICLE = 0, so wird ein Leerstring zurueckgegeben, es sei denn,
+     man uebergibt in dem Argument 'force' einen Wert ungleich Null.
+
+BEMERKUNGEN
+-----------
+::
+
+     Achtung: bei gueltigem Artikel wird ein Leerzeichen angehaengt!
+
+     Name()/name() nutzen bereits QueryArticle(), wenn P_ARTICLE gesetzt
+     ist. Deshalb muss man sich "Eines Orks" nicht selbst aus dem
+     QueryArticle() und dem Namen zusammenbasteln, wenn mehrere Orks
+     im Raum herumstehen und man eine Nachricht wie:
+       "Du haust den Ork." und folgend
+       "[Des|Eines] Orks Nase schwillt an."
+     haben moechte:
+       "Du haust "+ork->name(WEN, 1)+". "
+       ork->Name(WESSEN, 2)+" Nase schwillt an."
+
+RUeCKGABEWERT
+-------------
+::
+
+     * gewuenschter Artikel als String plus Leerzeichen (!) ODER
+     * Leerstring
+
+BEISPIELE
+---------
+::
+
+     // "X haut Y auf die Nase. [Der|Die|Das] ist nicht beeindruckt."
+     // Man will:
+     // * auf jeden Fall einen Artikel, auch wenn kein P_ARTICLE gesetzt ist
+     // * nur den bestimmten Artikel
+     send_room(this_object(),
+       pl1->Name(WER)+" haut "+pl2->name(WEM)+" auf die Nase. "+
+       capitalize(pl2->QueryArticle(WER, 1, 1))+"ist nicht beeindruckt.",
+       MT_LOOK|MT_LISTEN, 0, 0, ({pl1, pl2}));
+
+     // "X gibt dir Y. [Er|Sie|Es] prueft [den|die|das] ..."
+     // Man will:
+     // * auf jeden Fall einen Artikel, auch wenn kein P_ARTICLE gesetzt ist
+     // * nur den bestimmten Artikel
+     send_room(this_object(),
+       pl1->Name(WER)+" gibt "+pl2->name(WEM)+" "+obj->name(WER)+". "+
+       capitalize(pl2->QueryPronoun(WER))+" prueft "+
+       ob->QueryArticle(WEN, 1, 1)+"...",
+       MT_LOOK|MT_LISTEN, 0, 0, ({pl1, pl2}));
+
+     // "Dir faellt X auf den Kopf. Du siehst [die|den|das|eine|einen|eines "
+     // "auf dem Boden liegen. [Sie|Er|Es] sieht blutig aus. Aua. Ist das "
+     // "von dir?"
+     // Man will:
+     // * auf jeden Fall einen Artikel, auch wenn kein P_ARTICLE gesetzt ist
+     // * bestimmte/unbestimmte Artikel, wenn bereits gleiche Gegenstaende
+     //   (zB Kokosnuesse) auf dem Boden liegen ...
+     ob->move(environment(), M_NOCHECK); // vorher machen!
+     pl->ReceiveMsg(
+       "Dir faellt "+ob->name(WER, 0)+" auf den Kopf. Du siehst "+
+       ob->QueryArticle(WEN, 2, 1)+" auf dem Boden liegen. "+
+       capitalize(ob->QueryPronoun(WER))+" sieht blutig ...
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  SuggestArticle(), query_c_article(), query_g_suffix()
+     Sonstiges: QueryOwn(), QueryDu(),
+                QueryPronoun(), QueryPossPronoun()
+                DeclAdj()
+                name()
+
+9. Jun 2016, Gloinson
+
diff --git a/doc/sphinx/lfun/QueryAttribute.rst b/doc/sphinx/lfun/QueryAttribute.rst
new file mode 100644
index 0000000..a5c0c72
--- /dev/null
+++ b/doc/sphinx/lfun/QueryAttribute.rst
@@ -0,0 +1,59 @@
+QueryAttribute()
+================
+
+FUNKTION
+--------
+::
+
+     int QueryAttribute(string attr)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+     attr       - interessierendes Gesamtattribut
+
+BESCHREIBUNG
+------------
+::
+
+     Das Attribut samt seiner Offsets (Modifier) wird zurueckgegeben.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Wert des Attributes, bei Spielern nicht groesser als 30.
+
+BEISPIELE
+---------
+::
+
+     if (this_player()->QueryAttribute(A_CON) > 20)
+       write("Du schaffst es den Berg hoch. Aber nur muehsam.\n");
+
+BENERKUNGEN
+-----------
+::
+
+     Wenn es um Attributabfragen geht, bitte diese Methode verwenden!
+
+SIEHE AUCH
+----------
+::
+
+	QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+	SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+	SetTimedAttrModifier(), QueryTimedAttrModifier(), 
+	DeleteTimedAttrModifier(),
+	P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+	P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/QueryAttributeOffset.rst b/doc/sphinx/lfun/QueryAttributeOffset.rst
new file mode 100644
index 0000000..55c6909
--- /dev/null
+++ b/doc/sphinx/lfun/QueryAttributeOffset.rst
@@ -0,0 +1,47 @@
+QueryAttributeOffset()
+======================
+
+FUNKTION
+--------
+::
+
+     int QueryAttributeOffset(string attr)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+     attr	-	gesuchter AttributOffset
+
+BESCHREIBUNG
+------------
+::
+
+     Die Offsets des Attributs (inklusive Modifier) werden zurueckgegeben.
+
+BEISPIELE
+---------
+::
+
+     if(this_player()->QueryAttributeOffset(A_STR)<0)
+      write("Du bist geschwaecht.\n");
+
+SIEHE AUCH
+----------
+::
+
+	QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+	SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+	SetTimedAttrModifier(), QueryTimedAttrModifier(), 
+	DeleteTimedAttrModifier(),
+	P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+	P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/QueryBuyFact.rst b/doc/sphinx/lfun/QueryBuyFact.rst
new file mode 100644
index 0000000..fc0fdb5
--- /dev/null
+++ b/doc/sphinx/lfun/QueryBuyFact.rst
@@ -0,0 +1,42 @@
+QueryBuyFact()
+==============
+
+FUNKTION
+--------
+::
+
+     int QueryBuyFact();
+
+DEFINIERT IN
+------------
+::
+
+     /std/laden.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt den mit SetBuyFact() gesetzten Faktor zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Der Einkaufspreismultiplikator.
+
+SIEHE AUCH
+----------
+::
+
+     SetBuyFact(), /std/laden.c
+
+
+Last modified: Wed May 8 10:21:57 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryBuyValue.rst b/doc/sphinx/lfun/QueryBuyValue.rst
new file mode 100644
index 0000000..815cf5e
--- /dev/null
+++ b/doc/sphinx/lfun/QueryBuyValue.rst
@@ -0,0 +1,62 @@
+QueryBuyValue()
+===============
+
+QueryBuyValue()
+
+Funktion
+    static varargs int QueryBuyValue(mixed ob, object client)
+
+Definiert in
+    /std/room/shop
+
+Argumente
+    ob 
+      Das zu kaufende Objekt (String oder object).
+      Im Normalfall handelt es sich um ein Objekt. Ausnahme sind 
+      Gegenstaende, die mit AddFixedObject() hinzugefuegt wurden.
+    client 
+      Der Kaeufer.
+
+Beschreibung
+    Ermittelt den Preis, den <client> fuer <ob> zu bezahlen hat.
+
+Rueckgabewert
+    Der Preis als Integer.
+
+Beispiel
+    Ein Haendler, der Spielern die ihm geholfen haben einen Rabatt von 10% 
+    gewaehrt
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+::
+
+    
+
+    object *helpers;
+    protected void create()
+    {
+      ::create();
+      helpers=({});
+      ...
+    }
+
+    
+
+    static varargs int QueryBuyValue(mixed ob, object client)
+    {
+      if(member(helpers,client)!=-1)
+      {
+        return ::QueryBuyValue(ob,client)*9/10;
+      }
+      return ::QueryBuyValue(ob,client);
+    }
+
+Siehe auch:
+    Funktionen:
+      AddFixedObject(), RemoveFixedObject(), SetStorageRoom(), 
+      QueryStorageRoom(), QueryBuyFact(), sell_obj(), buy_obj()
+    Properties:
+      P_KEEPER, P_MIN_STOCK, P_STORE_CONSUME
+
+
+Letzte Aenderung: 21.05.2014, Bugfix
+
diff --git a/doc/sphinx/lfun/QueryCoinsPerUnits.rst b/doc/sphinx/lfun/QueryCoinsPerUnits.rst
new file mode 100644
index 0000000..476f243
--- /dev/null
+++ b/doc/sphinx/lfun/QueryCoinsPerUnits.rst
@@ -0,0 +1,58 @@
+QueryCoinsPerUnits()
+====================
+
+QueryCoinsPerUnit()
+-------------------
+::
+
+FUNKTION
+--------
+::
+
+     int *QueryCoinsPerUnits();
+
+DEFINIERT IN
+------------
+::
+
+     /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Liefert das Wertverhaeltnis fuer die Einheiten zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Ein Array von zwei Zahlen. Die erste Zahl ist der Wert der in der
+     zweiten Zahl angegebenen Einheiten.
+
+BEISPIELE
+---------
+::
+
+     Steht im Unit-Objekt folgende Wertzuweisung:
+
+       SetCoinsPerUnits(7,2);
+
+     so liefert QueryCoinsPerUnits() als Ergebnis ({7, 2}).
+
+SIEHE AUCH
+----------
+::
+
+     SetCoinsPerUnits(), SetGramsPerUnits(), QueryGramsPerUnit(),
+     /std/unit.c
+
+
+Last modified: Wed May 8 10:22:02 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryDamage.rst b/doc/sphinx/lfun/QueryDamage.rst
new file mode 100644
index 0000000..4576d28
--- /dev/null
+++ b/doc/sphinx/lfun/QueryDamage.rst
@@ -0,0 +1,62 @@
+QueryDamage()
+=============
+
+FUNKTION
+--------
+::
+
+     int QueryDamage(object enemy);
+
+DEFINIERT IN
+------------
+::
+
+     /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+     enemy
+          Der Gegner, gegen den die Waffe eingesetzt wird.
+
+BESCHREIBUNG
+------------
+::
+
+     Dies ist die zentrale Funktion der Waffe. Sie wird in jeder Kampfrunde
+     von Attack() aus aufgerufen und gibt den Schaden zurueck, den der
+     Gegner abwehren muss.
+
+     In den Schaden gehen sowohl die Staerke der Waffe als auch die Staerke
+     des Traegers der Waffe ein.
+
+     Wurde eine HitFunc() angegeben, so wird diese mit den gleichen
+     Parametern wie QueryDamage() aufgerufen.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Die Staerke des Schlages fuer diese Kampfrunde. Sie ermittelt sich als
+     Zufallszahl zwischen 0 und einem Wert, der sich aus der Staerke der
+     Waffe und der Staerke ihres Traegers ergibt. Das Ergebnis des
+     HitFunc()-Aufrufs wird zu dieser Zahl hinzugezaehlt.
+
+BEMERKUNGEN
+-----------
+::
+
+     Auch wenn man eine HitFunc() verwendet, darf der Rueckgabewert
+     insgesamt nicht groesser als 200 werden. Im Zweifelsfall sollte 
+     man sich mit der zustaendigen Balance besprechen!
+
+SIEHE AUCH
+----------
+::
+
+     HitFunc(), Attack(), /std/weapon.c, grenzwerte
+
+
+Last modified: Fre Feb 16.02.01 12:58:00 von Tilly
+
diff --git a/doc/sphinx/lfun/QueryDefend.rst b/doc/sphinx/lfun/QueryDefend.rst
new file mode 100644
index 0000000..eba5246
--- /dev/null
+++ b/doc/sphinx/lfun/QueryDefend.rst
@@ -0,0 +1,68 @@
+QueryDefend()
+=============
+
+FUNKTION
+--------
+::
+
+     int QueryDefend(string|string* dtyp, int|mapping spell, object enemy);
+
+DEFINIERT IN
+------------
+::
+
+     /std/armour/combat.c
+
+ARGUMENTE
+---------
+::
+
+     dtyp  - Schadenstypen der Angriffsart
+     spell - 0       bei konventionellem Angriff,
+             != 0    bei Angriff mit einem nichtphysischen Spell,
+             mapping bei genaueren Angaben zur Wirkung
+     enemy - Der angreifende Gegner
+
+BESCHREIBUNG
+------------
+::
+
+     Dies ist die zentrale Funktion einer Ruestung. Sie wird in jeder
+     Kampfrunde aus /std/living/combat::Defend() fuer jede Ruestung aufgerufen,
+     die der Spieler angezogen hat.
+
+     Der Schutzwert von P_AC entfaltet seine Wirkung nur bei konventionellen
+     Angriffen:
+     * wenn 'spell' 0 ist (bei Aufruf aus der Defend heraus ausgeschlossen)
+     * wenn 'spell' ein Mapping mit dem Flag SP_PHYSICAL_ATTACK != 0 UND
+                    in 'dtyp' mindestens ein physischer Schaden enthalten ist
+
+RUeCKGABEWERT
+-------------
+::
+
+     Die Ruestungsstaerke in dieser Kampfrunde. Sie ermittelt sich als
+     Zufallszahl zwischen 0 und P_AC, zuzueglich des Ergebnisses des
+     DefendFunc()-Aufrufs.
+
+BEMERKUNGEN
+-----------
+::
+
+     Auch wenn man eine DefendFunc() benutzt, darf der Rueckgabewert
+     insgesamt nicht groesser werden als der fuer den Ruestungstyp
+     maximal zulaessige!
+
+SIEHE AUCH
+----------
+::
+
+     Ruestungen: P_ARMOUR_TYPE, P_NR_HANDS, P_ARMOURS, P_WORN
+     Schutz:     P_AC, Defend(), DefendFunc
+     Sonstiges:  P_EQUIP_TIME, P_LAST_USE, P_DAM_TYPE
+     Verwandt:   QueryArmourByType(L), P_WEAPON, FilterClothing(),
+                 FilterArmours()
+     Resistenz:  P_RESISTANCE_STRENGTHS, CheckResistance(L)
+
+28.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/lfun/QueryDisguise.rst b/doc/sphinx/lfun/QueryDisguise.rst
new file mode 100644
index 0000000..a251120
--- /dev/null
+++ b/doc/sphinx/lfun/QueryDisguise.rst
@@ -0,0 +1,52 @@
+QueryDisguise()
+===============
+
+FUNKTION
+--------
+::
+
+     mixed QueryDisguise();
+
+DEFINIERT IN
+------------
+::
+
+     ???
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Prueft, ob der Spieler durch einen Shadow (meistens der Tarnhelm) 
+     'manipuliert' ist.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn dies nicht der Fall ist, ansonsten die Beschreibung des Shadow
+     vom Typ string.
+
+BEMERKUNGEN
+-----------
+::
+
+     In Waffen / Ruestungen u.ae. die P_RESTRICTIONS gesetzt haben,
+     eruebrigt sich eine Abfrage auf QueryDisguise(), da dies bereits im
+     restriction_checker erledigt wird.
+
+SIEHE AUCH
+----------
+::
+
+     P_RESTRICTIONS, /std/restriction_checker.c
+
+
+Last modified: Mon Mar 26 14:48:20 2001 von Tilly
+
diff --git a/doc/sphinx/lfun/QueryDoorKey.rst b/doc/sphinx/lfun/QueryDoorKey.rst
new file mode 100644
index 0000000..355c898
--- /dev/null
+++ b/doc/sphinx/lfun/QueryDoorKey.rst
@@ -0,0 +1,72 @@
+QueryDoorKey()
+==============
+
+FUNKTION
+--------
+::
+
+     mixed QueryDoorKey();
+
+DEFINIERT IN
+------------
+::
+
+     versch. Schluesseln
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird in einem Schluessel aufgerufen, wenn man mit diesem
+     eine Tuer auf- oder abschliessen will. Anhand des Rueckgabewertes wird
+     entschieden, ob der Schluessel passt oder nicht.
+
+RUECKGABEWERT
+-------------
+::
+
+     String oder Array von Strings der Raumpfade, deren gemeinsame Tueren
+     sich mit diesem Schluessel auf- bzw. abschliessen lassen. Die Keys sind
+     dabei die Raumpfade, getrennt durch ein ":". Dabei muessen die Pfade
+     in lexikographischer (alphabetischer) Reihenfolge sortiert sein:
+
+     "<name_raum_1>:<name_raum_2>"
+
+BEISPIELE
+---------
+::
+
+     Ein Schluessel, mit dem sich eine einzige Tuer oeffnen laesst (falls es
+     jemals eine Tuer zwischen Karate- und Abenteurergilde geben sollte...):
+
+     string QueryDoorKey()
+     {
+       return "/gilden/abenteurer:/gilden/karate";
+     }
+
+     Ein Schluessel, der in mehreren Tueren passt:
+
+     string* QueryDoorKey()
+     {
+       return ({ "/gilden/abenteurer:/players/wargon/workroom",
+                 "/gilden/abenteurer:/gilden/karate",
+                 "/players/jof/workroom:/players/wargon/workroom"
+              });
+     }
+
+SIEHE AUCH
+----------
+::
+
+    NewDoor(), QueryDoorStatus(), SetDoorStatus(), P_DOOR_INFOS,
+    /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+
+
+Letzte Aenderung: Don, 08.05.2014, Gabylon
+
diff --git a/doc/sphinx/lfun/QueryDoorStatus.rst b/doc/sphinx/lfun/QueryDoorStatus.rst
new file mode 100644
index 0000000..58ac8dc
--- /dev/null
+++ b/doc/sphinx/lfun/QueryDoorStatus.rst
@@ -0,0 +1,49 @@
+QueryDoorStatus()
+=================
+
+FUNKTION
+--------
+::
+
+     int QueryDoorStatus(string dest);
+
+DEFINIERT IN
+------------
+::
+
+     /obj/doormaster.c
+
+ARGUMENTE
+---------
+::
+
+     <dest> = Zielraum der Tuer.
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird der Zustand der Tuer, die von diesem Raum nach <dest> fuehrt,
+     ermittelt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0 bei nicht vorhandene Tuer, ansonsten einer der folgenden Zustaende (aus
+       <doorroom.h>):
+
+       D_STATUS_LOCKED - Tuer abgeschlossen
+       D_STATUS_CLOSED - Tuer geschlossen
+       D_STATUS_OPEN   - Tuer geoeffnet
+
+SIEHE AUCH
+----------
+::
+
+    NewDoor(), QueryDoorKey(), SetDoorStatus(), P_DOOR_INFOS,
+    /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+
+
+Letzte Aenderung: Don, 08.05.2014, Gabylon
+
diff --git a/doc/sphinx/lfun/QueryDu.rst b/doc/sphinx/lfun/QueryDu.rst
new file mode 100644
index 0000000..f90a7cb
--- /dev/null
+++ b/doc/sphinx/lfun/QueryDu.rst
@@ -0,0 +1,61 @@
+QueryDu()
+=========
+
+FUNKTION
+--------
+::
+
+     varargs string QueryDu(int casus, int gender, int anzahl);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+     casus
+          Der Fall fuer die Anrede.
+
+     gender
+          Das Geschlecht des anzuredenden Objektes.
+
+     anzahl
+          Ist nur ein Objekt anzusprechen oder mehrere?
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion liefert die dem Anlass entsprechende Anrede fuer ein
+     Objekt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Ein String mit der Anrede.
+
+BEISPIELE
+---------
+::
+
+     printf("%s setzt %s auf den Boden.\n",
+           capitalize(QueryDu(WER, TP->QueryProp(P_GENDER), SINGULAR),
+           QueryDu(WEN, TP->QueryProp(P_GENDER), SINGULAR));
+
+     (In den meisten Faellen kann man hier auch direkt "Du" und "dich"
+     einsetzen.)
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/language.c
+     QueryPossPronoun(), QueryOwn(), QueryPronoun()
+
+Last modified: Wed May 8 10:22:27 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryEnemies.rst b/doc/sphinx/lfun/QueryEnemies.rst
new file mode 100644
index 0000000..2816935
--- /dev/null
+++ b/doc/sphinx/lfun/QueryEnemies.rst
@@ -0,0 +1,55 @@
+QueryEnemies()
+==============
+
+FUNKTION
+--------
+::
+
+	mixed QueryEnemies();
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+	keine
+
+RUeCKGABEWERT
+-------------
+::
+
+	Array mit Array aus bekannten Gegnern und Array aus Zeiten
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Funktion enthaelt ein Array, das zwei Elemente enthaelt, die
+	wiederum Arrays sind:
+	  1. Array: Die bekannten Gegner als Objektpointer.
+	  2. Array: Die zugeordneten Zeiten, wie lange ein Gegner noch als
+	            solcher bekannt sein soll.
+	Im Normalfall wird ein Gegner dann bekannt, wenn man gezielt
+	jemanden atackiert, oder wenn man einen Angriff abwehren muss.
+	Dann wird der Gegner intern abgespeichert, und es wird eine Zeit
+	gesetzt, die dann runtergezaehlt wird. Ist die Zeit auf 0, so wird
+	der Gegner wieder automatisch ausgetragen.
+	(Standardmaessig betraegt diese Zeit 600 Sekunden (300 Heartbeats).)
+	Man kann sich die Gegner auch in Form eines Mappings zurueckgeben
+	lassen. Dies erreicht man mittels der Funktion GetEnemies().
+
+SIEHE AUCH
+----------
+::
+
+	Kill(), Attack(), Defend(), do_my_heart_beat(), PresentEnemies(),
+	GetEnemies(), SelectEnemy(), QueryPreferedEnemy(), P_PREFERED_ENEMY
+
+
+29.12.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/QueryFlaw.rst b/doc/sphinx/lfun/QueryFlaw.rst
new file mode 100644
index 0000000..44db4bf
--- /dev/null
+++ b/doc/sphinx/lfun/QueryFlaw.rst
@@ -0,0 +1,64 @@
+QueryFlaw()
+===========
+
+FUNKTION
+--------
+::
+
+     mixed *QueryFlaw();
+
+DEFINIERT IN
+------------
+::
+
+     /std/armour/combat.c,
+     /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     QueryFlaw() liefert Informationen ueber den Grad der Abnutzung der
+     Waffe bzw. Ruestung. Der Zustand wird als Array mit der Zahl der
+     TakeFlaw()-Aufrufe und dem Datum des ersten TakeFlaw()-Aufrufs
+     zurueckgegeben.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Ein Array mit drei Elementen:
+       1. der aktuelle Zaehlerstand
+       2. Zeit der ersten Benutzung
+       3. die Zeit der ersten Benutzung als String
+
+BEISPIELE
+---------
+::
+
+     Den aktuellen Abnutzungsgrad einer Ruestung kann man sich wie folgt
+     anzeigen lassen:
+
+     mixed *flaw;
+
+     flaw = ruestung->QueryFlaw();
+
+     printf("Zaehlerstand: %d, erster Schlag: %s\n", flaw[0], flaw[2]);
+     // oder analog:
+     printf("Zaehlerstand: %d, erster Schlag: %s\n", flaw[0], dtime(flaw[1]));
+
+SIEHE AUCH
+----------
+::
+
+     TakeFlaw(), /std/armour/combat.c, /std/weapon/combat.c
+
+
+Last modified: Wed May 8 10:22:32 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryGenderString.rst b/doc/sphinx/lfun/QueryGenderString.rst
new file mode 100644
index 0000000..a3d1b5b
--- /dev/null
+++ b/doc/sphinx/lfun/QueryGenderString.rst
@@ -0,0 +1,43 @@
+QueryGenderString()
+===================
+
+FUNKTION
+--------
+::
+
+     string QueryGenderString();
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird ein String mit dem Geschlecht des Objektes zurueckgegeben
+     ("maennlich", "weiblich", "saechlich").
+
+RUeCKGABEWERT
+-------------
+::
+
+     Der String mit dem Geschlecht.
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/language.c
+
+
+Last modified: Wed May 8 10:23:00 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryGramsPerUnits.rst b/doc/sphinx/lfun/QueryGramsPerUnits.rst
new file mode 100644
index 0000000..81d36fd
--- /dev/null
+++ b/doc/sphinx/lfun/QueryGramsPerUnits.rst
@@ -0,0 +1,54 @@
+QueryGramsPerUnits()
+====================
+
+FUNKTION
+--------
+::
+
+     int *QueryGramsPerUnits();
+
+DEFINIERT IN
+------------
+::
+
+     /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Liefert das Gewichtsverhaeltnis fuer die Einheiten zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Ein Array von zwei Zahlen. Die erste Zahl ist das Gewicht der in der
+     zweiten Zahl angegebenen Einheiten.
+
+BEISPIELE
+---------
+::
+
+     Steht im Unit-Objekt folgende Gewichtszuweisung:
+
+       SetGramsPerUnits(4,1);
+
+     so liefert QueryGramsPerUnits() als Ergebnis ({4, 1}).
+
+SIEHE AUCH
+----------
+::
+
+     SetCoinsPerUnits(), QueryCoinsPerUnits() SetGramsPerUnits(),
+     /std/unit.c
+
+
+Last modified: Wed May 8 10:22:39 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryGroupedKeys.rst b/doc/sphinx/lfun/QueryGroupedKeys.rst
new file mode 100644
index 0000000..695a36b
--- /dev/null
+++ b/doc/sphinx/lfun/QueryGroupedKeys.rst
@@ -0,0 +1,45 @@
+QueryGroupedKeys()
+==================
+
+FUNKTION
+--------
+::
+
+    mixed *QueryGroupedKeys()
+
+DEFINIERT IN
+------------
+::
+
+    /secure/questmaster.c
+
+ARGUMENTE
+---------
+::
+
+    keine
+
+RUECKGABEWERT
+-------------
+::
+
+    Array mit Arrays mit den Schluesselwoertern der Quests
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion liefert ein Array mit mehreren Arrays zurueck, die
+    die Schluesselwoerter der Quests enthalten. Dabei enthaelt das 
+    erste Array die Schluesselwoerter der Quests der ersten Gruppe etc.
+    Das letzte Array enthaelt die Gruppe der optionalen Quests.
+
+SIEHE AUCH
+----------
+::
+
+    GiveQuest, QueryQuest, /secure/questmaster.h
+
+
+Zuletzt geaendert: Son, 19. Nov 2000, 13:22:15 von Zook.
+
diff --git a/doc/sphinx/lfun/QueryGuest.rst b/doc/sphinx/lfun/QueryGuest.rst
new file mode 100644
index 0000000..90810b2
--- /dev/null
+++ b/doc/sphinx/lfun/QueryGuest.rst
@@ -0,0 +1,54 @@
+QueryGuest()
+============
+
+FUNKTION
+--------
+::
+
+     int QueryGuest();
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/base
+
+BESCHREIBUNG
+------------
+::
+
+     Auf der uid basierende Hilfsfunktion, um Gaeste zu identifizieren.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn Spielerobjekt ein Gast ist; 0 sonst
+
+BEISPIELE
+---------
+::
+
+     if(this_interactive()->QueryGuest())
+     {
+       (this_interactive()->ReceiveMsg(
+          "Wir bedienen hier nur ordentliche Charaktere.",
+          MT_LISTEN, MA_SAY,
+          "Der Wirt sagt: ") != MSG_SENSE_BLOCK) ||
+       (this_interactive()->ReceiveMsg(
+          "Der Wirt gestikuliert dich hinaus.",
+          MT_LOOK, MA_LOOK) != MSG_SENSE_BLOCK) ||
+       (this_interactive()->ReceiveMsg(
+          "Irgendwer stupst dich an. Du sollst wohl gehen.",
+          MT_FEEL, MA_FEEL));
+       return 1;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     getuid()
+
+14. Mai 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/QueryHealInfo.rst b/doc/sphinx/lfun/QueryHealInfo.rst
new file mode 100644
index 0000000..1abfd71
--- /dev/null
+++ b/doc/sphinx/lfun/QueryHealInfo.rst
@@ -0,0 +1,46 @@
+QueryHealInfo()
+===============
+
+FUNKTION
+--------
+::
+
+     string QueryHealInfo();
+
+DEFINIERT IN
+------------
+::
+
+     /std/corpse.c,
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     QueryHealInfo() liefert einen Standardtext zurueck, der grob Auskunft 
+     darueber gibt, welche Auswirkungen das Essen einer Leiche haette. 
+     Diese Info kann z.B. von Gilden verwendet werden, die P_HEAL (s.dort)
+     einer Leiche nicht selbst auswerten wollen.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Ein nicht umbrochener String. Fuer Zeilenumbrueche kann derjenige,
+     der den Text ausliest, selbst sorgen.
+
+SIEHE AUCH
+----------
+::
+
+     /std/corpse.c, P_HEAL
+
+
+Last modified: 31.03.2008, Arathorn
+
diff --git a/doc/sphinx/lfun/QueryMaterial.rst b/doc/sphinx/lfun/QueryMaterial.rst
new file mode 100644
index 0000000..ef11821
--- /dev/null
+++ b/doc/sphinx/lfun/QueryMaterial.rst
@@ -0,0 +1,62 @@
+QueryMaterial()
+===============
+
+QueryMaterial(L)
+----------------
+::
+
+FUNKTION
+--------
+::
+
+     int QueryMaterial(string mat)
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     string mat -	Material, auf das getestet werden soll
+
+BESCHREIBUNG
+------------
+::
+
+     Testet, ob ein Gegenstand aus dem angegebenen Material besteht
+     und gibt dessen Anteil zurueck.
+     Die Rueckgabe ist im Wertebereich -100 (Antigruppen) bis +100 (%).
+
+RUECKGABEWERT
+-------------
+::
+
+     Anteil in Prozent.
+
+BEISPIELE
+---------
+::
+
+     if(ob->QueryMaterial(MAT_IVORY)<=0)
+       write("Daraus kannst Du keine Billiardkugeln schnitzen!\n");
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Methoden:    QueryMaterialGroup(), MaterialList(),
+     Listen:	  AllMaterials(), AllGroups(), Dump()
+		  materialliste, materialgruppen
+     Master:	  AddMaterial(), ConvMaterialList(), MaterialGroup(),
+		  GroupName(), MaterialName(),
+		  GetGroupMembers(), GetMatMembership()
+     Sonstiges:	  P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/QueryMaterialGroup.rst b/doc/sphinx/lfun/QueryMaterialGroup.rst
new file mode 100644
index 0000000..9e1c396
--- /dev/null
+++ b/doc/sphinx/lfun/QueryMaterialGroup.rst
@@ -0,0 +1,81 @@
+QueryMaterialGroup()
+====================
+
+QueryMaterialGroup(L)
+---------------------
+::
+
+FUNKTION
+--------
+::
+
+     int QueryMaterialGroup(string grp)
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     string grp		- Materialgruppe, auf die getestet werden soll
+
+BESCHREIBUNG
+------------
+::
+
+     Liefert eine Angabe, zu welchem Anteil das Objekt aus Materialien
+     dieser Gruppe besteht.
+     Die Rueckgabe ist im Wertebereich -100 (Antigruppen) bis +100 (%).
+
+RUECKGABEWERT
+-------------
+::
+
+     Anteil in Prozent.
+
+BEMERKUNGEN
+-----------
+::
+
+     Ruft MaterialGroup() an der MATERIALDB.
+
+BEISPIELE
+---------
+::
+
+     // kann man damit was anfangen?
+     if(ob->QueryMaterialGroup(MATGROUP_METAL)<50)
+       write("Der Schmied sagt: Daraus kann ich kein Schwert fertigen.\n");
+
+     // verbrennt das Ding?
+     if(ob->QueryMaterialGroup(MATGROUP_INFLAMMABLE)>50) {
+       write(ob->Name(WER)+" geht in Flammen auf.\n");
+       ob->remove();
+     }
+
+     // wie magnetisch ist es denn?
+     if(ob->QueryMaterialGroup(MATGROUP_MAGNETIC)>50)
+      write(break_string(
+       ob->Name(WER)+" flutscht Dir aus der Hand und bleibt am Magneten "
+		     "kleben!",78));
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Methoden:    QueryMaterial(), MaterialList(),
+     Listen:	  AllMaterials(), AllGroups(), Dump()
+		  materialliste, materialgruppen
+     Master:	  AddMaterial(), ConvMaterialList(), MaterialGroup(),
+		  GroupName(), MaterialName(),
+		  GetGroupMembers(), GetMatMembership()
+     Sonstiges:	  P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/QueryMaxQP.rst b/doc/sphinx/lfun/QueryMaxQP.rst
new file mode 100644
index 0000000..60b4ae7
--- /dev/null
+++ b/doc/sphinx/lfun/QueryMaxQP.rst
@@ -0,0 +1,46 @@
+QueryMaxQP()
+============
+
+FUNKTION
+--------
+::
+
+    int QueryMaxQP()
+
+DEFINIERT IN
+------------
+::
+
+    /secure/questmaster.c
+
+ARGUMENTE
+---------
+::
+
+    keine
+
+RUECKGABEWERT
+-------------
+::
+
+    Abenteuerpunkte der Pflichtquests
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion liefert die Abenteuerpunkte der als Pflichtquest
+    eingetragenen Abenteuer zurueck. Pflichtquest bedeutet entweder,
+    dass die Quest zwingend geloest werden muss oder dass sie zu
+    der 80%-Regel gehoert.
+
+SIEHE AUCH
+----------
+::
+
+    GiveQuest, QueryQuest, /secure/questmaster.h, QueryGroupedKeys,
+    QueryOptQP, QueryTotalQP
+
+
+Zuletzt geaendert: Sam, 25. Nov 2000, 14:04:28 von Zook.
+
diff --git a/doc/sphinx/lfun/QueryMoney.rst b/doc/sphinx/lfun/QueryMoney.rst
new file mode 100644
index 0000000..d38eed5
--- /dev/null
+++ b/doc/sphinx/lfun/QueryMoney.rst
@@ -0,0 +1,49 @@
+QueryMoney()
+============
+
+FUNKTION
+--------
+::
+
+     int QueryMoney()
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/moneyhandler.c
+
+BESCHREIBUNG
+------------
+::
+
+     Testet, ob ein Spieler, Objekt, Raum oder Npc ueber eine definierte 
+     Geldmenge verfuegt, oder nicht.
+
+RUECKGABEWERT
+-------------
+::
+
+     Geldmenge im Besitz des abgefragten Spielers
+
+BEISPIELE
+---------
+::
+
+     int i;
+     i=50+random(10);
+     if(!this_player()->QueryMoney())
+       write("Du besitzt keine Muenzen!\n");
+     if(this_player()->QueryMoney() < i)
+       write("Du besitzt nicht die erforderlichen "+i+" Muenzen.\n");
+
+SIEHE AUCH
+----------
+::
+
+     Geldhandling:	AddMoney(L)
+     Zentralbank:	PayIn(L), WithDraw(L), _query_current_money(L)
+     Sonstiges:		/items/money.c
+
+Last modified: Die,  1. Aug 2000, 16:39:06 by Tilly
+
diff --git a/doc/sphinx/lfun/QueryName.rst b/doc/sphinx/lfun/QueryName.rst
new file mode 100644
index 0000000..0926640
--- /dev/null
+++ b/doc/sphinx/lfun/QueryName.rst
@@ -0,0 +1,44 @@
+QueryName()
+===========
+
+FUNKTION
+--------
+::
+
+     mixed QueryName();
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     DIESE FUNKTION SOLLTE NICHT MEHR BENUTZT WERDEN!
+     Es wird der Inhalt der Property P_NAME zuueckgegeben; dies laesst sich
+     jedoch genau so gut mit QueryProp(P_NAME) bewerkstelligen!
+
+RUeCKGABEWERT
+-------------
+::
+
+     String oder Array von Strings mit dem Namen des Objektes.
+
+SIEHE AUCH
+----------
+::
+
+     QueryProp(), Name(), name(), /std/thing/description.c
+
+
+Last modified: Sat Aug  3 11:21:05 2002 by Vanion
+
diff --git a/doc/sphinx/lfun/QueryOpenMiniQuestsForPlayer.rst b/doc/sphinx/lfun/QueryOpenMiniQuestsForPlayer.rst
new file mode 100644
index 0000000..ab38833
--- /dev/null
+++ b/doc/sphinx/lfun/QueryOpenMiniQuestsForPlayer.rst
@@ -0,0 +1,81 @@
+QueryOpenMiniQuestsForPlayer()
+==============================
+
+FUNKTION
+--------
+::
+
+    mapping QueryOpenMiniQuestsForPlayer(object player)
+
+DEFINIERT IN
+------------
+::
+
+    /secure/questmaster
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion gibt die Liste der offenen Miniquests des Spielers als
+    Mapping zurueck.
+
+ARGUMENTE
+---------
+::
+
+    player - das interessierende Spielerobjekt
+
+RUECKGABEWERTE
+--------------
+::
+
+    Mapping mit der Liste der Miniquests, fuer die das abfragende Objekt
+    zustaendig ist, oder leeres Mapping, wenn der Spieler keine MQs mehr
+    offen hat.
+
+    Die Liste enthaelt die Miniquestnummer als Key. Diesem sind zwei Werte
+    zugeordnet: zum einen ein Miniquest-Aufgabentext, und zum anderen -
+    falls der Spieler eine der Vorbedingungen fuer die Miniquest nicht
+    erfuellt - ein Hinweistext, der Auskunft gibt, welche Bedingung noch
+    zu erfuellen ist ("Seherstatus fehlt"). Diese Hinweistexte entsprechen
+    denen aus check_restrictions() in /std/restriction_checker.c. Der 
+    jeweils andere Text wird auf 0 gesetzt.
+
+    Die Struktur des Mappings ist daher folgende:
+      ([ MQ-Nummer : <Aufgabenstellung> ; <Hinderungsgrund> ])
+
+    
+
+    Beispiel: ein Spieler hat die Miniquests 18 und 49 noch nicht geloest,
+    erfuellt aber nur fuer Miniquest 49 die Anforderungen. Miniquest 18
+    erfordert den Seherstatus. Dann saehe das Mapping so aus:
+      ([ 18 : 0                    ; "Dazu musst Du erst Seher werden.\n",
+         49 : "Aufgabentext_zu_49" ; 0 ])
+
+    Jedes abfragende Objekt muss daher dieses Mapping zunaecht geeignet
+    auf seinen Inhalt pruefen, um zu ermitteln, welche Meldung jeweils
+    auszugeben ist.
+
+BEMERKUNGEN
+-----------
+::
+
+    Das abfragende Objekt muss von einem Erzmagier oder Gott (z.B. dem
+    zustaendigen Quest-EM) im Questmaster als zugriffsberechtigt bei den-
+    jenigen Miniquests eingetragen sein, fuer die es die entsprechenden
+    Miniquest-Hinweise ausgeben darf. Diese Berechtigung ist mit dem 
+    Quest-EM abzustimmen. Anderen Objekten wird ein leeres Mapping zurueck-
+    gegeben.
+
+SIEHE AUCH
+----------
+::
+
+    AddMiniQuest(L), ChangeMiniQuest(L)
+    P_RESTRICTIONS
+    erzmagier
+
+
+Last modified: 6. Juni 2014, Arathorn.
+
diff --git a/doc/sphinx/lfun/QueryOwn.rst b/doc/sphinx/lfun/QueryOwn.rst
new file mode 100644
index 0000000..50e7bdf
--- /dev/null
+++ b/doc/sphinx/lfun/QueryOwn.rst
@@ -0,0 +1,54 @@
+QueryOwn()
+==========
+
+FUNKTION
+--------
+::
+
+     varargs string QueryOwn(int casus)
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+     casus
+          Der Fall fuer die Anrede.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion liefert das dem Anlass entsprechende Possessiv-
+     pronomen fuer den Spieler selber (Dein/Deine).
+
+RUeCKGABEWERT
+-------------
+::
+
+     Ein String mit dem Pronomen.
+
+BEISPIELE
+---------
+::
+
+     printf("%s %s loest sich auf.\n",
+           capitalize(obj->QueryOwn(WER)),obj->name(WER));
+
+     (In den meisten Faellen kann man hier auch direkt "Dein" oder "Deine"
+      einsetzen.)
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/language.c
+
+
+Last modified: Sun Aug 10 23:55:27 2003 by Mandragon
+
diff --git a/doc/sphinx/lfun/QueryPassengers.rst b/doc/sphinx/lfun/QueryPassengers.rst
new file mode 100644
index 0000000..e87fa45
--- /dev/null
+++ b/doc/sphinx/lfun/QueryPassengers.rst
@@ -0,0 +1,52 @@
+QueryPassengers()
+=================
+
+FUNKTION
+--------
+::
+
+     object *QueryPassengers();
+
+DEFINIERT IN
+------------
+::
+
+     /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion ermittelt die momentan auf dem Transporter befindlichen
+     Passagiere.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Array von Objekten mit den Passagieren.
+
+BEMERKUNGEN
+-----------
+::
+
+     Es werden nur die Passagiere zurueckgegeben, die sich in dem
+     eigentlichen Transporterobjekt befinden! Wenn der Transporter noch um
+     zusaetzliche Raeume vergroessert wird, werden unter Umstaenden nicht
+     alle Passagiere erfasst!
+
+SIEHE AUCH
+----------
+::
+
+     /std/transport.c
+
+
+Last modified: Wed May 8 10:22:48 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryPosition.rst b/doc/sphinx/lfun/QueryPosition.rst
new file mode 100644
index 0000000..2157299
--- /dev/null
+++ b/doc/sphinx/lfun/QueryPosition.rst
@@ -0,0 +1,49 @@
+QueryPosition()
+===============
+
+FUNKTION
+--------
+::
+
+     string *QueryPosition();
+
+DEFINIERT IN
+------------
+::
+
+     /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird ein Array von zwei Strings mit Kennzeichnern der letzten (oder
+     aktuellen) und der naechsten Station im Fahrplan zurueckgegeben.
+
+     Die Kennzeichner sind dabei die ersten Argumente der entsprechenden
+     AddXXX()-Aufrufen, also der Name der Haltestelle bei AddRoute, der Text
+     der Meldung bei AddMsg() und der Name der Funktion bei AddFun().
+
+RUeCKGABEWERT
+-------------
+::
+
+     Array mit zwei Strings. Der erste String gibt den Kennzeichner der
+     momentanen Fahrplanstation an, der zweite String den Kennzeichner der
+     naechsten Fahrplanstation.
+
+SIEHE AUCH
+----------
+::
+
+     AddRoute(), AddMsg(), AddFun(), /std/transport.c
+
+
+Last modified: Wed May 8 10:22:52 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryPossPronoun.rst b/doc/sphinx/lfun/QueryPossPronoun.rst
new file mode 100644
index 0000000..fba61ce
--- /dev/null
+++ b/doc/sphinx/lfun/QueryPossPronoun.rst
@@ -0,0 +1,74 @@
+QueryPossPronoun()
+==================
+
+FUNKTION
+--------
+::
+
+     varargs string QueryPossPronoun(mixed what, int casus, int anzahl);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+     what
+          Geschlecht des Objektes, das besessen wird, oder das Objekt
+          selbst.
+
+     casus
+          Der Fall, in dem das Objekt besessen wird.
+
+     anzahl
+          Handelt es sich um nur ein Objekt oder um mehrere?
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion gibt ein Possessivpronomen zurueck, das das
+     Besitzverhaeltnis eines Objektes zu diesem Objekt anzeigt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Das Possessivpronomen im entsprechenden Fall.
+
+BEMERKUNGEN
+-----------
+::
+
+     what und casus beziehen sich auf das Objekt, welches besessen wird, und
+     nicht auf den Besitzer!!!
+
+BEISPIELE
+---------
+::
+
+     Um eine korrekte Ausgabe beim Haendeklatschen zu erreichen, koennte man
+     zB. folgende Zeile verwenden:
+
+      printf("%s klatscht in %s Haende.\n",this_player()->name(WER),
+           this_player()->QueryPossPronoun(FEMALE, WEN, PLURAL));
+
+     FEMALE, da "die Hand" weiblich ist, WEN, da man im Akkusativ klatscht,
+     und PLURAL, da man dazu beide Haende braucht.
+
+     Ein beliebter Fehler ist es, als Fall WESSEN zu verwenden (in WESSEN
+     Haende klatscht man? => in seine).
+     Die richtige Frage waere aber: WEN klatscht man? (in die Haende)
+
+SIEHE AUCH
+----------
+::
+
+     QueryOwn(), QueryPronoun(), /std/thing/language.c
+
+Last modified: Wed Jan 11 13:13:35 CET 2006 by Rumata
+
diff --git a/doc/sphinx/lfun/QueryPrayRoom.rst b/doc/sphinx/lfun/QueryPrayRoom.rst
new file mode 100644
index 0000000..137335a
--- /dev/null
+++ b/doc/sphinx/lfun/QueryPrayRoom.rst
@@ -0,0 +1,51 @@
+QueryPrayRoom()
+===============
+
+FUNKTION
+--------
+::
+
+     public string QueryPrayRoom()
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/base.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+    Dies ist der Raum, in den der Spieler nach dem Ende der Todessequenz
+    bewegt wird, d.h. ein Raum, wo er beten kann, um einen neuen Koerper zu
+    erhalten.
+    Der Raum wird als String angegeben (kein Objekt).
+
+    Jede Rasse hat einen Default fuer diese Funktion, welcher mit
+    SetDefaultPrayRoom() gesetzt wird. Dieser Default kann mit der Property
+    P_PRAY_ROOM ueberlagert werden. Wird die Property auf 0 dgesetzt, wird
+    dieser Default aktiv.
+
+RUeCKGABEWERT
+-------------
+::
+
+    Der Objektname des Betraums (string)
+
+SIEHE AUCH
+----------
+::
+
+     P_PRAY_ROOM
+     SetDefaultPrayRoom
+
+
+21.05.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/QueryPreferedEnemy.rst b/doc/sphinx/lfun/QueryPreferedEnemy.rst
new file mode 100644
index 0000000..fbf956f
--- /dev/null
+++ b/doc/sphinx/lfun/QueryPreferedEnemy.rst
@@ -0,0 +1,57 @@
+QueryPreferedEnemy()
+====================
+
+FUNKTION
+--------
+::
+
+	object QueryPreferedEnemy();
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+	keine
+
+RUeCKGABEWERT
+-------------
+::
+
+	bevorzugter Gegner
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Funktion liefert unter folgenden Bedingungen zufaellig eines
+	der Lebewesen als bevorzugten Gegner zurueck, welche in der
+	Property P_PREFERED_ENEMY in einem Array eingetragen sind:
+	  (1) Der erste Eintrag des erwaehnten Propertyarrays enthaelt
+	      einen Wert zwischen 0 und 100, der die Wahrscheinlichkeit
+	      dafuer angibt, dass ein Lebewesen als Gegner bevorzugt werden
+	      soll. Es wird also nicht immer bevorzugt, wenn dort ein Wert
+	      kleiner 100 steht! In diesem Fall wird eine 0 zurueckgegeben.
+	  (2) Das per Zufall aus den Arrayelementen ab Element 2 gewaehlte
+	      Lebewesen muss auch wirklich existieren. Ist dies nicht der
+	      Fall, wird das nunmehr leere Element aus dem Array entfernt
+	      und eine 0 zurueckgeliefert.
+	  (3) Das Lebewesen muss derzeit auch wirklich Feind sein! Ist dies
+	      nicht der Fall, wird eine 0 zurueckgegeben.
+	Will man eine andere Bevorzugung von Gegnern erreichen,
+	ueberschreibt man am besten diese Funktion.
+
+SIEHE AUCH
+----------
+::
+
+	SelectEnemy(), IsEnemy(), P_PREFERED_ENEMY
+
+
+Last modified: Wed May 26 16:47:51 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/QueryPronoun.rst b/doc/sphinx/lfun/QueryPronoun.rst
new file mode 100644
index 0000000..2577d05
--- /dev/null
+++ b/doc/sphinx/lfun/QueryPronoun.rst
@@ -0,0 +1,54 @@
+QueryPronoun()
+==============
+
+FUNKTION
+--------
+::
+
+     string QueryPronoun(int casus);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+     casus
+          Der Fall, in dem das Personalpronomen verlangt wird.
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird ein Personalpronomen ("er", "sie", "es") im entsprechenden Fall
+     fuer dieses Objekt berechnet.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Das Pronomen im entsprechenden Fall.
+
+BEISPIELE
+---------
+::
+
+     printf("Du versucht, %s zu nehmen, aber %s ist zu schwer.\n",
+           ob->name(WEN), ob->QueryPronoun(WER));
+
+     Hier wird immer das richtige Pronomen verwendet, egal, welches
+     Geschlecht das Objekt ob hat.
+
+SIEHE AUCH
+----------
+::
+
+     SuggestArticle(), QueryPossPronoun(), /std/thing/language.c
+     QueryOwn()
+
+Last modified: Wed May 8 10:23:14 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryProp.rst b/doc/sphinx/lfun/QueryProp.rst
new file mode 100644
index 0000000..d55316b
--- /dev/null
+++ b/doc/sphinx/lfun/QueryProp.rst
@@ -0,0 +1,63 @@
+QueryProp()
+===========
+
+FUNKTION
+--------
+::
+
+     mixed QueryProp(string name);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/properties.c
+
+ARGUMENTE
+---------
+::
+
+     string name	- abzufragende Property
+
+BESCHREIBUNG
+------------
+::
+
+     Der Datenwert der Property 'name' wird zurueckgegeben.
+
+     Existiert eine F_QUERY_METHOD oder eine _query_'name'()-Methode fuer
+     diese Property, so wird diese aufgerufen und ihr 'Value' uebergeben.
+     Eine F_QUERY_METHOD hat dabei Vorrang vor _query_'name'(), d.h.
+     _query_'name'() wird nach erfolgreicher F_QUERY_METHOD nicht mehr
+     gerufen.
+
+     (Diese Methoden nutzen dann Set(), um auf den Datenwert der Property
+      'name' zurueckzugreifen. Teilweise werden aber auch interne Variablen
+      so oeffentlich gemacht und sind nicht in der ueber Set/Query
+      verfuegbaren Property 'name' abgelegt.)
+
+RUeCKGABEWERT
+-------------
+::
+
+     Der Datenwert der Property.
+     0, falls diese nicht existiert.
+
+BEISPIELE
+---------
+::
+
+     // wie hoch sind die aktuelle LP des Spielers?
+     hp = this_player()->QueryProp(P_HP);
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	SetProp(L), Set(L), Query(L)
+     Generell:		SetProperties(L), QueryProperties(L)
+     Konzept:		properties, /std/thing/properties.c
+     Sonstiges:		P_AUTOLOADOBJ
+
+15.Dez 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/QueryProperties.rst b/doc/sphinx/lfun/QueryProperties.rst
new file mode 100644
index 0000000..eb16392
--- /dev/null
+++ b/doc/sphinx/lfun/QueryProperties.rst
@@ -0,0 +1,54 @@
+QueryProperties()
+=================
+
+FUNKTION
+--------
+::
+
+     mapping QueryProperties()
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/properties.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion liefert ein Mapping mit allen fuer das Objekt
+     definierten Properties zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Ein Mapping mit den Properties. Das Mapping hat folgenden Aufbau:
+	([ name: wert; flags; set_method; query_method,
+	   name2: ... ]);
+
+BEMERKUNGEN
+-----------
+::
+
+     - diese Funktion wird von restore_object() und save_object()
+     - F_QUERY_METHODs und _query_'prop'()-Methoden haben keine Auswirkung
+       auf die Wertefelder!
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	SetProp(L), QueryProp(L), Set(L), Query(L)
+     Generell:		SetProperties(L) 
+     Konzept:		properties, /std/thing/properties.c
+
+1.Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/QueryQuest.rst b/doc/sphinx/lfun/QueryQuest.rst
new file mode 100644
index 0000000..6ebb184
--- /dev/null
+++ b/doc/sphinx/lfun/QueryQuest.rst
@@ -0,0 +1,54 @@
+QueryQuest()
+============
+
+FUNKTION
+--------
+::
+
+        int QueryQuest(string questname)
+
+DEFINIERT IN
+------------
+::
+
+        /std/player/quests.c
+
+ARGUMENTE
+---------
+::
+
+        questname
+          Questname, wie er im Questmaster eingetragen wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+        (Die Defines fuer den Rueckgabewert finden sich in 
+         /secure/questmaster.h)
+         1 : Spieler hat die Quest bereits geloest  (OK)
+         0 : Ungueltiger Questname oder der Spieler
+             hat die Quest noch nicht.              (QQ_KEY_INVALID)
+         2 : Gaeste koennen keine Quest loesen      (QQ_QUEST)
+
+BESCHREIBUNG
+------------
+::
+
+	Mit dieser Funktion kann getestet werden, ob ein Spieler eine 
+        bestimmte Quest bereits geloest hat. Als Questname wird dazu
+        der Name angegeben, der im Questmaster eingetragen wurde.
+
+        Wer sich da nicht sicher ist, kann mit dem Questtool 
+        (/obj/tools/questtool) nachsehen. 
+
+SIEHE AUCH
+----------
+::
+
+        /secure/questmaster.h, /obj/tools/questtool
+        GiveQuest
+
+
+Zuletzt geaendert: Mon, 17. Jul 2000, 12:16:41 von Zook.
+
diff --git a/doc/sphinx/lfun/QueryQuestTime.rst b/doc/sphinx/lfun/QueryQuestTime.rst
new file mode 100644
index 0000000..327c962
--- /dev/null
+++ b/doc/sphinx/lfun/QueryQuestTime.rst
@@ -0,0 +1,49 @@
+QueryQuestTime()
+================
+
+FUNKTION
+--------
+::
+
+        int QueryQuestTime(string questname)
+
+DEFINIERT IN
+------------
+::
+
+        /std/player/quests.c
+
+ARGUMENTE
+---------
+::
+
+        questname
+          Questname, wie er im Questmaster eingetragen wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+        Questzeitpunkt in Sekunden seit Epoch als positiver Integer-Wert
+         0 : Tagebuchmaster hat keine Daten in den Logfiles gefunden und
+             macht das auf diese Weise kenntlich
+        -1 : Questzeitpunkt unbekannt
+
+BESCHREIBUNG
+------------
+::
+
+        Mit dieser Funktion kann der Zeitpunkt abgefragt werden, zu
+        dem ein Spieler eine bestimmte Quest geloest hat. 
+        Als Questname wird dazu der Name angegeben, der im Questmaster 
+        eingetragen ist.
+
+SIEHE AUCH
+----------
+::
+
+        GiveQuest(L), QueryQuest(L), ModifyQuestTime(L)
+
+
+Zuletzt geaendert: 19. Dez. 2015, Arathorn
+
diff --git a/doc/sphinx/lfun/QueryRealAttribute.rst b/doc/sphinx/lfun/QueryRealAttribute.rst
new file mode 100644
index 0000000..5fb0e3b
--- /dev/null
+++ b/doc/sphinx/lfun/QueryRealAttribute.rst
@@ -0,0 +1,47 @@
+QueryRealAttribute()
+====================
+
+FUNKTION
+--------
+::
+
+     int QueryRealAttribute(string attr)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+     attr       -       das interessierende Attribut
+
+BESCHREIBUNG
+------------
+::
+
+     Das reale Attribut (ohne Offsets) wird zurueckgegeben.
+
+BEISPIELE
+---------
+::
+
+     if(this_player()->QueryRealAttribute(A_INT)>15)
+      write("Du bist auch so ganz schoen clever.\n");
+
+SIEHE AUCH
+----------
+::
+
+	QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+	SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+	SetTimedAttrModifier(), QueryTimedAttrModifier(), 
+	DeleteTimedAttrModifier(),
+	P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+	P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/QuerySellValue.rst b/doc/sphinx/lfun/QuerySellValue.rst
new file mode 100644
index 0000000..5f87d55
--- /dev/null
+++ b/doc/sphinx/lfun/QuerySellValue.rst
@@ -0,0 +1,55 @@
+QuerySellValue()
+================
+
+FUNKTION
+--------
+::
+
+      varargs int QuerySellValue(object ob, object client);
+
+DEFINIERT IN
+------------
+::
+
+      /std/trading_price.c
+
+BESCHREIBUNG
+------------
+::
+
+      Diese Funktion kann dazu genutzt werden, den Verkaufspreis in einem 
+      Laden global zu veraendern. Sofern dies zugunsten der Spieler geschieht,
+      muss dafuer die Zustimmung des zustaendigen Regionsmagiers und der
+      Balance eingeholt werden. Zudem sollte es nicht in jedem x-beliebigen 
+      Laden genutzt werden, sondern nur in recht abgelegenen Gebieten, in
+      die man nicht einfach skripten kann.
+
+      Ein Beispiel ist der Laden auf dem Kutter in Port Vain, der nur in
+      laengeren Intervallen mal zugaenglich ist.
+
+BEISPIEL
+--------
+::
+
+      Ein Laden zahlt 10% ueber dem normalen Verkaufspreis:
+
+      private int sell_factor = 110;
+
+      varargs int QuerySellValue(object ob, object client) {
+        // Es wird nicht naeher geprueft, ob <ob> ein gueltiger Objektpointer
+        // ist, da der Laden selbst sicherstellt, dass das so ist. Wenn 
+        // das doch einmal nicht der Fall sein sollte, liegt der Fehler
+        // woanders. Einen Bug auszuloesen ist dann sinnvoll.
+
+        // Basispreis ermitteln 
+        int preis = ::QuerySellValue(ob, client);
+        // und den Bonus aufschlagen.
+        preis = (sell_factor * preis)/100; 
+
+        // Nicht mehr auszahlen, als das Objekt an sich wert ist.
+        return min(preis, ob->QueryProp(P_VALUE));
+      }
+
+
+LETZTE AENDERUNG: 18-Jun-2015, Arathorn
+
diff --git a/doc/sphinx/lfun/QuerySkill.rst b/doc/sphinx/lfun/QuerySkill.rst
new file mode 100644
index 0000000..cf8ae88
--- /dev/null
+++ b/doc/sphinx/lfun/QuerySkill.rst
@@ -0,0 +1,58 @@
+QuerySkill()
+============
+
+FUNKTION
+--------
+::
+
+    public varargs mapping QuerySkill(string sname, string gilde)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skills.c
+
+    
+
+ARGUMENTE
+---------
+::
+
+    string sname    Name des abzufragenden Skill
+    string gilde    Name der Gilde, unter der der Skill gesucht werden soll
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion liefert das Skillmappings des Skills 'snme' im Lebewesen
+    zurueck. Diese enthaelt Eintraege, die in der Man-Page skill_info_liste
+    beschrieben sind.
+
+    Falls 'gilde' nicht angegeben wird, wird der Skill zuerst fuer die Gilde
+    P_GUILD des Lebewesens gesucht, ansonsten in den allgemeinen Skills
+    "ANY" (es wird NICHT in Gildenobjekt oder Spellbook etwas abgefragt).
+
+RUECKGABEWERT
+-------------
+::
+
+    Ein Mapping mit Skillinfos oder 0, falls der Skill nicht vorhanden ist.
+    Das Mapping ist eine Kopie.
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkillAbility
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung, skill_info_liste
+    * Properties:   P_NEWSKILLS
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/QuerySkillAbility.rst b/doc/sphinx/lfun/QuerySkillAbility.rst
new file mode 100644
index 0000000..4679f39
--- /dev/null
+++ b/doc/sphinx/lfun/QuerySkillAbility.rst
@@ -0,0 +1,49 @@
+QuerySkillAbility()
+===================
+
+FUNKTION
+--------
+::
+
+    public varargs int QuerySkillAbility(string sname, string gilde)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skills.c
+
+    
+
+ARGUMENTE
+---------
+::
+
+    string sname        Name des abzufragenden Skill
+    string gilde         Gilde, unter der der Skill gesucht werden soll
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion liefert einen Wert zurueck, der aussagt, wie gut das
+    Lebewesen den Skill 'sname' beherrscht (Key SI_SKILLABILITY im
+    Skillmapping).
+    Dieser Wert kann zwischen -MAX_ABILITY und MAX_ABILITY liegen,
+    normal ist 0 bis MAX_ABILITY (10000 - Skill perfektioniert).
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkill
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung, skill_info_liste
+    * Properties:   P_NEWSKILLS
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/QuerySkillAttribute.rst b/doc/sphinx/lfun/QuerySkillAttribute.rst
new file mode 100644
index 0000000..3916290
--- /dev/null
+++ b/doc/sphinx/lfun/QuerySkillAttribute.rst
@@ -0,0 +1,95 @@
+QuerySkillAttribute()
+=====================
+
+FUNKTION
+--------
+::
+
+    public int QuerySkillAttribute(string atrname)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skill_attributes.c
+
+    
+
+ARGUMENTE
+---------
+::
+
+    string atrname            Name des abzufragenden Attributs
+
+    
+
+BESCHREIBUNG
+------------
+::
+
+    Mit dieser Funktion kann man den Wert bestimmter Attribute
+    abfragen, dabei werden das abgefragte Attribut, Todesfolgen,
+    SA_QUALITY und Werte in P_SKILL_ATTRIBUTE_OFFSETS
+    beruecksichtigt.
+
+    
+
+    Momentane Skills siehe ModifySkillAttribute.
+
+RUECKGABEWERT
+-------------
+::
+
+    Der Wert des Attributs. Ist nichts bestimmtes gesetzt, wird
+    der Standardwert 100 zurueckgegeben.
+    Der Rueckgabewert liegt zwischen 10 bis 1000 (Prozent).
+
+    
+
+BEMERKUNG
+---------
+::
+
+    Die Funktion ist zwar als 'varargs' definiert, gibt man allerdings
+    keinen Attributnamen an, wird immer 100 zurueckgegeben.
+
+    
+
+BEISPIEL
+--------
+::
+
+    // ein Spieler kann ein Stueck Kaese stibitzen, wenn er schnell
+    // genug ist ... (15% ueber normal)
+    if(this_player()->QuerySkillAttribute(SA_SPEED)>=115) {
+      tell_object(this_player(),
+        "Du schnappst das Stueck Kaese aus der Falle.\n");
+      obj kaese = clone_object(...);
+      [...]
+    } else {
+      mapping amap=map_indices(VALID_ARMOUR_CLASS,#'!);
+      amap[AT_GLOVE]=100;
+      tell_object(this_player(),
+        "Du bist zu langsam und die Falle schnappt hungrig zu.\n");
+      this_player()->Defend(random(100),
+                           ({DT_PIERCE, DT_SQUEEZE}),
+                           ([SP_PHYSICAL_ATTACK: 1,
+                             SP_REDUCE_ARMOUR: amap,
+                             SP_SHOW_DAMAGE: 0]));
+    }
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkill, QuerySkillAbility
+    * Modifikation: ModifySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung, skill_info_liste
+    * Properties:   P_NEWSKILLS
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/QuerySkillAttributeModifier.rst b/doc/sphinx/lfun/QuerySkillAttributeModifier.rst
new file mode 100644
index 0000000..34615c3
--- /dev/null
+++ b/doc/sphinx/lfun/QuerySkillAttributeModifier.rst
@@ -0,0 +1,118 @@
+QuerySkillAttributeModifier()
+=============================
+
+FUNKTION
+--------
+::
+
+    public varargs mapping QuerySkillAttributeModifier(object caster, 
+                                                    string *atrnames)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skill_attributes.c
+
+ARGUMENTE
+---------
+::
+
+    <caster>    object
+                Objekt, welches die gesuchten Mods gesetzt hat
+
+    <atrnames>  string*
+                Array von Skill-Attributen, welche durchsucht werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion liefert alle Mods von <caster> auf den Skill-
+    Attributen <atrnames> in einem Mapping zurueck.
+    Wird <atrnames> nicht angegeben oder ist ein leeres Array, werden alle
+    Skill-Attribute nach Mods abgesucht.
+    Wird <caster> nicht angeben oder ist 0, so werden alle Mods der 
+    gewuenschten Skill-Attribute geliefert.
+    Dementsprechend bekommt man alle Mods aller Skill-Attribute, wenn keins
+    von beidem angegeben wird.
+
+RUECKGABEWERT
+-------------
+::
+
+    ([]), falls keine Modifikatoren gefunden wurden.
+    In anderen Faellen ist die Datenstruktur des Mappings wie folgt:
+    ([ atrname1: ([ <caster>: <value>; <duration> ]),
+       atrname2: ([ <caster>: <value>; <duration> ]) ])
+    Die Schluessel im Mapping sind die jeweiligen Skill-Attribute, die Werte
+    des Mappings sind erneut Mappings, welche als Schluessel die Objekte
+    haben, welche die Mods gesetzt haben. In diesem Mapping gehoeren zu jedem
+    Schluessel zwei Werte, den Wert des Modifikators und die Ablaufzeit.
+    <value> kann hierbei ein int oder eine closure sein, <duration> ist ein
+    int, <caster> ist ein Objekt.
+    Ggf. kann das innere Mapping natuerlich auch mehrere Modifikatoren
+    enthalten (also caster1, caster2, usw.).
+
+BEMERKUNGEN
+-----------
+::
+
+BEISPIELE
+---------
+::
+
+     Ein Objekt moechte seinen bestehenden Modifikator um 20 und die
+     Gueltigkeit um 13 erhoehen.
+     mapping res = ob->QuerySkillAttributeModifier(this_object(),
+                                                  ({SA_DAMAGE}) );
+     if (member(res, SA_DAMAGE) && member(res[SA_DAMAGE], this_object())) {
+          // alten Mod ueberschreiben und Werte dabei anheben.
+          ob->ModifySkillAttributeModifier(SA_DAMAGE,
+              res[SA_DAMAGE][this_object(),0] + 20,
+              res[SA_DAMAGE][this_object(),1] + 13 );
+     }
+     else
+          // neuen Mod setzen.
+          ob->ModifySkilAttributeModifier(SA_DAMAGE, 20, 13);
+
+      
+
+     Ein Objekt hat den Fluch der unpraezisen Schnelligkeit, welcher SA_DAMAGE
+     reduziert, sofern das Lebewesen einen positiven Modifikator auf SA_SPEED
+     hat:
+     mapping res = ob->QuerySkillAttributeModifier(0, ({SA_SPEED}) );
+     if (member(res, SA_SPEED) {
+         int val, int dur;
+         foreach(object caster, int v, int d: res[SA_SPEED]) {
+             // groessten Mod rausfinden, dabei keine closures
+             // beruecksichtigen.
+             if (intp(v) && v>val) {
+                 val=v;
+                 dur=d;
+             }
+         }
+         if (val > 0) {
+             // pos. Mod auf SA_SPEED gefunden, entsprechenden neg. Mod auf
+             // SA_DAMAGE setzen, der zum gleichen Zeitpunkt ungueltig wird
+             // wie der Mod auf SA_SPEED.
+             if (ob->ModifySkillAttribute(SA_DAMAGE, -val, dur) == SA_MOD_OK)
+                tell_object(ob, "tolle Fluchmeldung.");
+         }
+     }
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkill, QuerySkillAbility
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung, skill_info_liste
+    * Properties:   P_NEWSKILLS
+
+14.08.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/QuerySkillBonus.rst b/doc/sphinx/lfun/QuerySkillBonus.rst
new file mode 100644
index 0000000..ba19c40
--- /dev/null
+++ b/doc/sphinx/lfun/QuerySkillBonus.rst
@@ -0,0 +1,91 @@
+QuerySkillBonus()
+=================
+
+FUNKTION
+--------
+::
+
+     int QuerySkillBonus(object caster, object target, mapping sinfo)
+
+DEFINIERT IN
+------------
+::
+
+     beliebigen Objekten
+
+ARGUMENTE
+---------
+::
+
+     object caster
+          der Benutzer eines Skills/Spells (Lebewesen)
+     object target
+          das Ziel eines Skills/Spells (beliebiges Objekt oder 0)
+     mapping sinfo
+          das Skillinfomapping
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird von der Gilde des Casters im Environment und ggf.
+     auch im Ziel eines Skills/Spells gerufen.
+     Die Gilde uebergibt neben Caster und Ziel ein Mapping mit Skillinfos (s.
+     SI Konstanten aus new_skills.h fuer Details), welches alle wesentlichen
+     Informationen ueber den benutzten Skill/Spell enthaelt.
+
+     QuerySkillBonus() liefert einen Bonus (oder Malus) zurueck, den der
+     Aufrufer als Faktor in der Berechnung des Effekts des Skills
+     beruecksichtigen kann (aber nicht muss).
+     Der Bonus/Malus wird hierbei als ganzzahliger 0.01-Prozentwert aufgefasst
+     (10000 == 100% == keine Veraenderung, 1 == 0.01%).
+
+     Diese Funktion kann in beliebigen Objekten (re-)definiert werden. Im
+     Falle mobiler Objekte oder anhaltender Effekte ist jedoch eine
+     Balancegenehmigung erforderlich, sofern kampfrelevante Skills beeinflusst
+     werden.
+     Eine flaechendeckende Reduzierung von Skills/Gildenfaehigkeiten ist
+     explizit _nicht_ erwuenscht und soll auf einzelne Raeume und Objekte
+     beschraenkt sein.
+
+BEMERKUNGEN
+-----------
+::
+
+     Das Mapping <sinfo> kann in dieser Funktion geaendert werden. Dieses kann
+     allerdings sehr weitreichende Folgen haben, speziell bei mangelnden
+     Kenntnissen ueber Interna des Skillsystems. Daher bitte von Aenderungen
+     absehen bzw. vorher mit dem jeweiligen Gildenmagier und/oder der
+     Gildenbalance abklaeren.
+     Die Bedeutung der Werte in <sinfo> kann je nach Gilde variieren. Im
+     Zweifelsfall bitte bei den jeweiligen Gildenmagiern nachfragen. 
+     Die Gilde kann diese Funktion rufen, muss aber nicht. Ebenso kann sie das
+     Ergebnis beruecksichtigen, muss aber nicht.
+
+BEISPIELE
+---------
+::
+
+     In einem Raum sollen Heilzauber besonders effizient sein:
+     int QuerySkillBonus(object caster, object target, mapping sinfo) {
+        if (pointerp(sinfo[SI_MAGIC_TYPE])
+            && member(sinfo[SI_MAGIC_TYPE], MT_HEILUNG) > -1)
+        {
+            return 12000 + random(3000); // bonus von 120-150%
+        }
+        return 10000;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     gilden-doku
+     <new_skills.h>
+
+LETZTE AeNDERUNG
+----------------
+::
+
+19.08.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/QueryStorageRoom.rst b/doc/sphinx/lfun/QueryStorageRoom.rst
new file mode 100644
index 0000000..f0b9cf7
--- /dev/null
+++ b/doc/sphinx/lfun/QueryStorageRoom.rst
@@ -0,0 +1,27 @@
+QueryStorageRoom()
+==================
+
+QueryStorageRoom()
+
+Funktion
+    string QueryStorageRoom()
+
+Definiert in
+    /std/room/shop
+
+Rueckgabewert
+    Dateiname des Lagers, in dem die aufgekauften Gegenstaende aufbewahrt 
+    werden.
+
+Siehe auch
+    Funktionen
+      AddFixedObject(), RemoveFixedObject(), SetStorageRoom(), 
+      QueryBuyValue(), QueryBuyFact(), sell_obj(), buy_obj()
+    Properties
+      P_KEEPER, P_MIN_STOCK, P_STORE_CONSUME
+
+
+Letzte Aenderung 21.05.2014, Bugfix
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+::
+
diff --git a/doc/sphinx/lfun/QueryTimedAttrModifier.rst b/doc/sphinx/lfun/QueryTimedAttrModifier.rst
new file mode 100644
index 0000000..b3aa28f
--- /dev/null
+++ b/doc/sphinx/lfun/QueryTimedAttrModifier.rst
@@ -0,0 +1,69 @@
+QueryTimedAttrModifier()
+========================
+
+FUNKTION
+--------
+::
+
+     mapping QueryTimedAttrModifier(string key)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+     key	-	aus P_TIMED_ATTR_MOD abzufragender Eintrag
+
+BESCHREIBUNG
+------------
+::
+
+     Der zu key gehoerende Eintrag in P_TIMED_ATTR_MOD wird abgefragt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Ein leeres Mapping im Falle eines fehlerhaften key-Argumentes oder 
+     eines nicht existenten Keys.
+
+     
+
+     Ansonsten wird ein Mapping der Form
+
+     
+
+        ([
+           Key : ([ Mapping mit den Modifikatoren ]) ;
+                 Ablaufzeit ; Ablaufobjekt ; Nachrichtenempfaenger 
+        ])    
+
+     zurueckgegeben.Die Ablaufzeit ist hierbei die Zeit in Sekunden seit
+     dem 1. Jan 1970, 0.0:0 GMT, das Ablaufobjekt ist das Objekt an dessen
+     Existenz die Attributveraenderungen gebunden ist und der
+     Nachrichtenempfaenger ist dasjenigen Objekte welches im Falle 
+     durch den Aufruf von "NotifyTimedAttrModExpired" benachrichtigt 
+     wird sobald das Attribut abgelaufen ist. 
+     Der Funktion NotifyTimedAttrModExpired wird als Argument der key
+     der abgelaufenen Attributveraenderung uebergeben.
+     Das Mapping ist eine Kopie der Originaldatenstruktur zu diesem Key.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+	QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+	SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+	SetTimedAttrModifier(), DeleteTimedAttrModifier(),
+	P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+	P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/QueryTotalQP.rst b/doc/sphinx/lfun/QueryTotalQP.rst
new file mode 100644
index 0000000..1fe7e1d
--- /dev/null
+++ b/doc/sphinx/lfun/QueryTotalQP.rst
@@ -0,0 +1,44 @@
+QueryTotalQP()
+==============
+
+FUNKTION
+--------
+::
+
+    int QueryTotalQP()
+
+DEFINIERT IN
+------------
+::
+
+    /secure/questmaster.c
+
+ARGUMENTE
+---------
+::
+
+    keine
+
+RUECKGABEWERT
+-------------
+::
+
+    Abenteuerpunkte saemtlicher Quests
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion liefert die Abenteuerpunkte der saemtlicher aktivierter
+    Quests zurueck.
+
+SIEHE AUCH
+----------
+::
+
+    GiveQuest, QueryQuest, /secure/questmaster.h, QueryGroupedKeys,
+    QueryMaxQP, QueryOptQP
+
+
+Zuletzt geaendert: Sam, 25. Nov 2000, 14:04:28 von Zook.
+
diff --git a/doc/sphinx/lfun/QueryUser.rst b/doc/sphinx/lfun/QueryUser.rst
new file mode 100644
index 0000000..d4606c6
--- /dev/null
+++ b/doc/sphinx/lfun/QueryUser.rst
@@ -0,0 +1,79 @@
+QueryUser()
+===========
+
+FUNKTION
+--------
+::
+
+     public object QueryUser()
+
+DEFINIERT IN
+------------
+::
+
+     /std/npc/combat.c
+     /std/clothing/wear.c
+     /std/weapon/combat.c
+     alle Objekte, in denen es darueber hinaus noetig ist
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Liefert den aktuellen Nutzer (Lebewesen) eines Items oder NPCs.
+
+     
+
+     Diese Funktion wird z.B. von get_killing_player() benutzt, um
+     herauszufinden, zu welchem Spieler denn das Objekt gehoert, was den
+     toedlichen Schaden verursacht hat.
+
+     Im Falle eines NPCs ist dies standardmaessig der Spieler, bei dem der
+     NPC als Helfer-NPC eingetragen ist (s. RegisterHelperNPC).
+     Im Falle einer Ruestung ist es das Lebewesen, welches sie gerade traegt.
+     Im Falle einer Waffe ist es das Lebewesen, welches sie gerade gezueckt
+     hat.
+     Alle anderen Objekte enthalten keinen Default fuer diese Funktion.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Das nutzende Lebewesen, falls es ermittelt werden konnte, sonst 0.
+
+BEMERKUNGEN
+-----------
+::
+
+     Sollte in allen Objekten definiert werden, welche Lebewesen Schaden
+     zufuegen, ohne dass das verursachende Lebewesen dabei als Feind im
+     Defend() angeben wird.
+     Der gelieferte Nutzer muss explizit kein Spieler sein. Es waere z.B.
+     moeglich, dass von einem Spieler kontrollierter NPC einen Bumerang nutzt.
+
+BEISPIELE
+---------
+::
+
+     Ein von einem Spieler beschworenes Wesen wirft einen Bumerang nach einem
+     Feind.
+     Dann liefert QueryUser() im Bumerang den NPC als Nutzer und
+     QueryUser() im NPC wiederum den Spieler.
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     RegisterHelperNPC(), get_killer_player()
+     P_WORN, P_WIELDED
+
+12.11.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/QueryValidObject.rst b/doc/sphinx/lfun/QueryValidObject.rst
new file mode 100644
index 0000000..4e593a9
--- /dev/null
+++ b/doc/sphinx/lfun/QueryValidObject.rst
@@ -0,0 +1,69 @@
+QueryValidObject()
+==================
+
+FUNKTION
+--------
+::
+
+     public int QueryValidObject(string oname);
+
+DEFINIERT IN
+------------
+::
+
+     /std/virtual/v_compiler.c
+
+ARGUMENTE
+---------
+::
+
+     oname
+       Objektname, der geprueft werden soll (kompletter Pfad mit / am Anfang) 
+
+RUeCKGABEWERT
+-------------
+::
+
+     <=0 - falls VC nicht zustaendig ist.
+     >0 - falls der VC sich fuer das Objekt zustaendig erklaert.
+
+BESCHREIBUNG
+------------
+::
+
+     Ueber die Funktion laesst sich herausfinden, ob ein VC sich fuer das
+     gewuenschte Objekt zustaendig fuehlt. Dabei wird Validate(),
+     P_COMPILER_PATH, NoParaObjects() und P_PARA im VC ausgewertet:
+     1. Zuerst wird mit Validate() geprueft, ob der Filename (ohne Pfad) ok ist.
+     2. wird geguckt, ob das angefragte Objekt im richtigen Pfad liegt 
+        (P_COMPILER_PATH).
+     3. wenn das angefragte Objekt ein Para-Objekt ist:
+       a) wird NoParaObjects() geprueft, wenn das !=0 ist, sind gar keine Para-
+          Objekte erlaubt.
+       b) wird P_PARA _im VC_ abgefragt, dort kann man ein Array aller 
+          erlaubten Para-Dimensionen reinschreiben. Fuer alle anderen erklaert 
+          sich der VC fuer nicht zustaendig. Wenn P_PARA nicht gesetzt ist, 
+          sind alle erlaubt. Ein leeres Array ({}) wuerde einem 
+          NoParaObjects() {return 1;} entsprechen.
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Funktion wird vom move abgefragt. Bitte auf jeden Fall P_PARA oder
+     NoParaObjects() passend definieren, sonst buggts.
+
+     Wenn jemand mit dem oben beschrieben Standardverhalten nicht gluecklich
+     ist, kann man die Funktion passend ueberschreiben.
+
+SIEHE AUCH
+----------
+::
+
+     virtual_compiler
+     CustomizeObject(), Validate(), NoParaObjects(), 
+     P_COMPILER_PATH, P_PARA
+     /std/virtual/v_compiler.c
+
+21.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/ReceiveMsg.rst b/doc/sphinx/lfun/ReceiveMsg.rst
new file mode 100644
index 0000000..83941b1
--- /dev/null
+++ b/doc/sphinx/lfun/ReceiveMsg.rst
@@ -0,0 +1,281 @@
+ReceiveMsg()
+============
+
+ReceiveMsg()
+
+public varargs int ReceiveMsg(string msg, int msg_typ, string msg_action,
+                              string msg_prefix, mixed origin)
+------------------------------------------------------------------------------------------------------------------------------------------------------
+::
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/comm.c
+    /std/npc/comm.c
+    /std/player/comm.c
+    /std/room/items.c
+
+ARGUMENTE
+---------
+::
+
+    string msg
+      String mit der uebermittelten Nachricht. Muss nicht umgebrochen sein,
+      da ReceiveMsg() das ebenfalls erledigt.
+    int msg_typ
+      Nachrichtentyp(en) fuer Filterung und Flags fuer Behandlung/Umbruch.
+      Siehe unten fuer mit | kombinierbare Konstanten.
+    string msg_action (optional)
+      Ausloesende Aktion, wird auch fuer Ignorieren verwendet.
+      Default ist query_verb(). Siehe unten fuer alternative Konstanten.
+    string msg_prefix (optional)
+      String, welcher ggf. im break_string() als indent verwendet wird.
+      Default ist 0 (kein Indent)
+    mixed origin (<object>) (optional)
+      Das die Meldung ausloesende Objekt, wird fuer Ignorieren verwendet.
+      Default: previous_object()
+
+BESCHREIBUNG
+------------
+::
+
+    ReceiveMsg() wird benutzt, um einem Lebewesen eine Nachricht zu senden.
+    Dabei ruft es das sonst uebliche tell_object() fuer Spieler bzw.
+    catch_tell() im NPC auf.
+
+    Gerade fuer Nachrichten an Spieler bietet die Methode weitere Features,
+    die bisher sonst haendisch zu implementieren waren:
+    1) Pruefung auf Empfangbarkeit, je nach 'msg_typ', zB
+       MT_LOOK nur an Nichtblinde
+       MT_LISTEN nur an Nichttaube
+       MT_DEBUG nur an Magier/Testspieler
+    2) Pruefen auf Ignorieren von
+       - Aktion ('msg_action')
+         - mit 'msg_action' || query_verb()
+       - Urheber ('origin')
+         - fuer sendende Spieler mit origin->query_realname()
+         - fuer sendende NPCs mit origin->Name(RAW))
+    3) Speicherung in der tmhist (Typ MT_COMM)
+    4) Speicherung im Kobold (Typ MT_COMM + aktiver Kobold)
+    5) Umbrechen unter Beruecksichtigung von indent, 'msg_typ'-Flags
+       fuer Umbruch und P_PREPEND_BS
+
+    Raeume definieren standardmaessig ebenfalls ein ReceiveMsg(), welches in
+    jedem Objekt im Raum ReceiveMsg() mit den uebergebenen Argumenten aufruft.
+    In diesem Fall ist der Rueckgabe der kleinste von allen gerufenen
+    ReceiveMsg() zurueckgelieferte Wert.
+
+    
+
+RUeCKGABEWERT
+-------------
+::
+
+    > 0 fuer Erfolg, < 0 fuer Misserfolg, s.u.
+    MSG_DELIVERED    bei erfolgreicher Zustellung
+    MSG_BUFFERED     bei Zwischenspeicherung durch den Kobold
+
+    MSG_FAILED       nicht naeher spezifizierter Fehler bei Zustellung
+    MSG_IGNORED      Nachricht wurde ignoriert (Absender, origin)
+    MSG_VERB_IGN     Nachricht wurde ignoriert (Kommandoverb, msg_action)
+    MSG_MUD_IGN      Absendendes Mud wurde ignoriert.
+    MSG_SENSE_BLOCK  Passende Sinne des Empfaenger sind blockiert (z.B.
+                     blind, taub)
+    MSG_BUFFER_FULL  Kobold kann sich nichts mehr merken
+
+BEMERKUNGEN
+-----------
+::
+
+    Fuer saemtliche Alternativmeldungen im Falle einer nicht erfolgreich
+    zugestellten Nachricht ist der Aufrufer von ReceiveMsg() verantwortlich.
+
+    NPCs:
+    * ReceiveMsg() ruft zwecks Abwaertskompatibilitaet catch_tell() auf
+    * empfohlen ist, in NPCs nun ReceiveMsg() zu ueberschreiben.
+      * catch_tell() muss weiterhin fuer andere tell_object()
+        ueberschrieben  werden
+
+BEISPIELE
+---------
+::
+
+    #1.1 Nachricht an einen Spieler, zB in der Wueste
+    this_player()->ReceiveMsg("Die Sonne brennt dir auf den Kopf.",
+                              MT_FEEL|MT_LOOK);
+
+    #1.2 Nachricht an einen Spieler von einem NPC mit Indent
+    // bei aktivem Editor+Kobold landet dieser Text auch im Kobold
+    this_player()->ReceiveMsg("Du haust ja ganz schoen rein!",
+                              MT_COMM|MT_FAR|MSG_DONT_STORE,
+                              MA_TELL,
+                              "Arkshat teilt dir mit: ");
+
+    #1.3 Nachricht an einen Spieler mit Fallback-Kaskade
+    // Achtung, bei MT_COMM oder Ignorieren gibt es natuerlich auch
+    // Misserfolgs-Rueckgaben. Bei einem normalen Kommando wie diesem
+    // hier ist das unproblematisch und daher sinnvoll:
+    if(this_player()->ReceiveMsg(
+         "Du drueckst den Knopf und es oeffnet sich knirschend "
+         "ein kleines Fach in der Wand.", MT_LOOK) < MSG_DELIVERED &&
+       this_player()->ReceiveMsg(
+         "Du drueckst den Knopf und irgend etwas scheint sich "
+         "knirschend zu oeffnen. Das Geraeusch kam von der Wand.",
+         MT_LISTEN) < MSG_DELIVERED) // leider blind UND taub ... also:
+      this_player()->ReceiveMsg(
+        "Du drueckst den Knopf und irgend etwas scheint zu passieren, "
+        "aber leider siehst und hoerst du nichts.", MT_FEEL);
+
+
+    #2.1 Im NPC als Empfaenger auf ein TM reagieren
+    public varargs int ReceiveMsg(string msg, int msg_typ, string msg_action,
+                                  string msg_prefix, mixed origin) {
+      int ret = MSG_DELIVERED;  // Default
+
+      // eine OOC-Kommunikation?
+      if(msg_typ&MT_COMM) {
+        if(strstr(msg, "hilfe")>=0)
+          if(environment(origin)==environment()) {
+            origin->ReceiveMsg("Ich werd dir gleich helfen!",
+                               MT_COMM|MSG_DONT_STORE, MA_TELL,
+                               "Arkshat teilt dir mit: ");
+          } else {
+            origin->ReceiveMsg("Hilf dir selbst, dann hilft dir Gott!",
+                               MT_COMM|MT_FAR|MSG_DONT_STORE,
+                               MA_TELL,
+                               "Arkshat teilt dir mit: ");
+          }
+        else if(...)
+        [...]
+      } else if(msg_typ&MT_LISTEN && msg_action==MA_SAY) {
+        [...]
+      }
+
+      return ret;
+    }
+
+
+    #3.1 als Sender an viele, Variante mit eigenem filter
+    // Achtung: siehe 3.3. send_room() loest vieles.
+    // Living nickt nur seinen Nichtgegnern zu
+    object *all = filter(all_inventory(environment(this_player())),
+                         #'living) - ({this_player()});
+    all -= this_player()->PresentEnemies();
+    all->ReceiveMsg(this_player()->Name()+
+                    " nickt dir verstohlen zu und scheint bereit.",
+                    MT_LOOK, MA_EMOTE);
+
+    #3.2 als Sender an viele, Variante mit einzelnem Iterieren
+    // Achtung: siehe 3.3. send_room() loest vieles.
+    // Living trinkt etwas, jeder im Raum soll es sehen oder hoeren
+    object ob = first_inventory(environment(this_player()));
+    do {
+      if(living(ob) && ob!=this_player())
+        ob->ReceiveMsg(this_player()->Name()+" trinkt einen Schnaps aus.",
+                       MT_LOOK|MT_LISTEN,
+                       MA_DRINK);
+      ob = next_inventory(ob);
+    } while(ob);
+
+    #3.3 als Sender an viele, Variante mit send_room
+    // Living gruesst seine Freunde
+    // send_room() ruft ReceiveMsg mit allen entsprechenden Parametern
+    object *exclude = this_player()->PresentEnemies();
+    send_room(this_object(),
+              this_player()->Name()+" gruesst dich.",
+              MT_LOOK|MT_LISTEN,
+              MA_EMOTE,
+              0,
+              exclude);
+
+    #3.4 als Sender an viele mit send_room und ReceiveMsg()
+    // Living gruesst seine Freunde, seine Feinde sehen das
+    // send_room() ruft ReceiveMsg mit allen entsprechenden Parametern
+    object *exclude = this_player()->PresentEnemies();
+    send_room(this_object(),
+              this_player()->Name()+" gruesst dich.",
+              MT_LOOK|MT_LISTEN, MA_EMOTE, 0, exclude);
+    exclude->ReceiveMessage(
+      this_player()->Name()+" gruesst, aber nicht dich.",
+      MT_LOOK|MT_LISTEN, MA_EMOTE);
+
+KONSTANTEN FUER PARAMETER
+-------------------------
+::
+
+    Saemtlich in "/sys/living/comm.h". Hier nicht notwendigerweise
+    immer aktuell oder vollstaendig.
+
+    <msg_typ>
+      MT_UNKNOWN      unspez. Nachrichtentyp (nicht verwenden). Es wird
+                      versucht, aufgrund <msg_action> den Typ zu erraten.
+      MT_LOOK         alles, was man sieht
+      MT_LISTEN       alles, was man hoert
+      MT_FEEL         alles, was man fuehlt
+      MT_TASTE        alles, was man schmeckt
+      MT_SMELL        alles, was man riecht
+      MT_MAGIC        alle sonstigen (uebersinnlichen) Wahrnehmungen
+      MT_NOTIFICATION Statusmeldungen, Kommandobestaetigungen
+      MT_COMM         alle OOC-Kommunikation, d.h. nicht durch o.g. Sinne
+                      abgedeckt.
+      MT_FAR          alles, was aus der Ferne / einem anderen Raum kommt.
+                      muss mit min. einem anderen Typ kombiniert werden
+      MT_DEBUG        Debugmeldungen, sehen nur Magier im Magiermodus
+      MT_NEWS         Mails & MPA
+
+      MSG_DONT_BUFFER Nachricht darf nicht im Kobold gespeichert werden
+      MSG_DONT_STORE  Nachricht darf nicht in die Comm-History
+      MSG_DONT_WRAP   Nachricht nicht per break_string umbrechen
+      MSG_DONT_IGNORE Nachricht kann nicht ignoriert werden
+
+      MSG_BS_LEAVE_LFS    wie BS_LEAVE_MY_LFS fuer break_string()
+      MSG_BS_SINGLE_SPACE wie BS_SINGLE_SPACE fuer break_string()
+      MSG_BS_BLOCK        wie BS_BLOCK fuer break_string()
+      MSG_BS_NO_PARINDENT wie BS_NO_PARINDENT fuer break_string()
+      MSG_BS_INDENT_ONCE  wie BS_INDENT_ONCE fuer break_string()
+      MSG_BS_PREP_INDENT  wie BS_PREPEND_INDENT fuer break_string()
+
+    <msg_action> (optional)
+      MA_UNKNOWN     Unspez. Aktion. Es wird der Default query_verb()
+                     benutzt bzw. versucht, die Aktion zu erraten.
+      MA_PUT         Jemand legt etwas hin und gibt jemanden etwas
+      MA_TAKE        Jemand nimmt etwas
+      MA_MOVE_IN     Jemand betritt den Raum
+      MA_MOVE_OUT    Jemand verlaesst den Raum
+      MA_MOVE        Jemand bewegt sich 
+      MA_FIGHT       Jemand kaempft
+      MA_WIELD       Jemand zueckt eine Waffe
+      MA_UNWIELD     Jemand steckt eine Waffe weg
+      MA_WEAR        Jemand zieht etwas an
+      MA_UNWEAR      Jemand zieht etwas aus
+      MA_EAT         Jemand isst etwas
+      MA_DRINK       Jemand trinkt etwas
+      MA_SPELL       Jemand wirkt einen Spell
+      MA_LOOK        Jemand sieht etwas an, untersucht etwas
+      MA_LISTEN      Jemand horcht oder lauscht an etwas
+      MA_FEEL        Jemand betastet etwas
+      MA_SMELL       Jemand schnueffelt herum
+      MA_SENSE       Jemand macht eine uebersinnliche Wahrnehmung
+      MA_READ        Jemand liest etwas
+      MA_USE         Jemand benutzt etwas
+      MA_SAY         Jemand sagt etwas
+      MA_REMOVE      Etwas verschwindet
+      // MA_CHAT        Chatkrams (z.B. teile-mit, Teamkampfchat)
+      MA_CHANNEL     Ebenen
+      MA_EMOTE       (r)Emotes, Soulverben (remotes mit Typ MT_COMM|MT_FAR)
+      MA_SHOUT       Rufen (nicht: shout()!)
+      MA_SHOUT_SEFUN Rufen ueber shout(SE)
+
+SIEHE AUCH
+----------
+::
+
+    Verwandt: send_room(SE)
+    Lfuns:    TestIgnore(L)
+    Efuns:    tell_object(E), catch_tell(L), catch_msg(L)
+              query_verb(E), query_once_interactive(E), break_string(SE)
+
+13.03.2016, Zesstra
+
diff --git a/doc/sphinx/lfun/RegisterEvent.rst b/doc/sphinx/lfun/RegisterEvent.rst
new file mode 100644
index 0000000..c104127
--- /dev/null
+++ b/doc/sphinx/lfun/RegisterEvent.rst
@@ -0,0 +1,116 @@
+RegisterEvent()
+===============
+
+FUNKTION
+--------
+::
+
+     int RegisterEvent(string eid, string fun, object listener);
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/eventd.c
+
+DEKLARIERT IN
+-------------
+::
+
+     /sys/events.h
+
+ARGUMENTE
+---------
+::
+
+     string eid,
+       Die ID des Events, fuer den man sich registrieren will. Da dieser
+       String fuer alle Events jeweils eindeutig sein muss, empfiehlt es sich,
+       fuer eigene Events z.B. als Praefix den eigenen Magiernamen zu nehmen,
+       z.B. "zesstra_vulkanausbruch".
+       ACHTUNG: IDs, die mit '_evt_lib_' beginnen, sind AUSSCHLIESSLICH der
+       Mudlib vorbehalten!
+     string fun,
+       Name der Funktion, die im Objekt listener bei Auftreten des Events
+       gerufen werden soll.
+     object listener,
+       Das Objekt, das als Lauscher fuer diesen Event registriert werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Das Objekt 'listener' wird als Lauscher dieses Events registriert. Ab
+     diesem Moment wird immer dann, wenn ein Event mit der ID 'eid' ausgeloest
+     wird, in 'listener' die Funktion 'fun' aufgerufen (zeitverzoegert, meist
+     0-2s).
+
+     
+
+     Die Funktion wird dabei immer mit 3 Argumenten aufgerufen:
+     listener->fun(eid, triggerob, data);
+     Hierbei ist 'eid' die jeweilige Event-ID und 'triggerob' ist das Objekt,
+     welches den Event ausloeste. 
+     'data' kann jeder LPC-Datentyp sein und enthaelt die Daten, die das
+     triggernde Objekt an alle Listener uebermitteln will (damit sind Datentyp
+     und Inhalt komplett abhaengig vom Event!)
+
+     Existiert bisher noch kein Event mit der ID 'eid', wird implizit ein
+     neuer Event erstellt, der erstmal nur das sich gerade registrierende
+     Objekt als Lauscher hat.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1 fuer Erfolg, <=0 fuer Misserfolg.
+     1   - Erfolg, 'listener' wurde eingetragen.
+     -1  - falsche Argumente wurden uebergeben
+     -2  - nicht-oeffentlicher Event und 'listener' wurde nicht fuer diesen
+           Event freigegeben (momentan gibt es noch keine nicht-oeffentlichen
+           Events)
+     -3  - 'fun' in 'listener' ist nicht vorhanden oder nicht von aussen 
+           aufrufbar (protected, static, private).
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Wenn 'listener' bereits fuer den Event registriert wird, wird die alte
+     Registrierung ueberschrieben (als ggf. gilt dann der jetzt uebergebene
+     Funktionsname).
+     Die Funktion 'fun' sollte sparsam mit den Eval-Ticks umgehen. Momentan
+     ist die max. Menge an Ticks auf 30000 beschraenkt. Dies kann bei
+     Problemen auch jederzeit reduziert werden!
+     Der EVENTD merkt sich Event-Lauscher nicht ueber Reboots hinaus.
+     Sollte sich eine Blueprint anmelden, sich zerstoeren und neugeladen
+     werden, ist die neue Blueprint noch angemeldet, weil das neue Objekt
+     unter dem alten Namen wiedergefunden wird. Dies gilt _nicht_ fuer
+     Clones!
+
+BEISPIELE
+---------
+::
+
+     1. Ein Objekt moechte ueber Spielertode informiert werden:
+          EVENTD->RegisterEvent(EVT_LIB_PLAYER_DEATH, "spieler_ist_tot", 
+                                this_object());
+        Ab jetzt wird im Objekt jedes Mal, wenn ein Spieler stirbt, die 
+        Funktion "spieler_ist_tot" aufgerufen.
+
+     2. Ein Objekt will informiert werden, wenn der Event
+        "boing_zwergenkoenig_angriff" ausgeloest wird:
+           EVENTD->RegisterEvent("boing_zwergenkoenig_angriff","alarm",
+                                  this_object());
+
+SIEHE AUCH
+----------
+::
+
+     events, eventd, UnregisterEvent(), TriggerEvent()
+
+
+Last modified: 15.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/RegisterHelperNPC.rst b/doc/sphinx/lfun/RegisterHelperNPC.rst
new file mode 100644
index 0000000..f5f2e7a
--- /dev/null
+++ b/doc/sphinx/lfun/RegisterHelperNPC.rst
@@ -0,0 +1,114 @@
+RegisterHelperNPC()
+===================
+
+FUNKTION
+--------
+::
+
+     public int RegisterHelperNPC(object npc, int flags);
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/combat.c
+     /sys/living/combat.h
+
+ARGUMENTE
+---------
+::
+
+     object npc
+       Objekt des helfenden NPC, der angemeldet werden soll.
+
+     int flags
+       ver-oder-te Konstanten, die die Art des Helfer-NPC beschreiben (s.u.)
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Funktion wird ein einem Spieler helfender NPC im Spieler
+     angemeldet. Hierdurch kann spaeter herausgefunden werden, welche NPC
+     einem Spieler helfen und ggf. den von diesen verursachten Schaden im
+     Kampf dem Spieler zuzurechnen.
+
+     Die Flags sind eine der folgenden Konstanten oder eine beliebige durch
+     ver-oder-ung gebildete Kombination.
+
+     Momentan gibt es 2 Klassen von Helfer-NPC:
+     + GUILD_HELPER: der Helfer-NPC ist ein Gilden-NPC
+     + MISC_HELPER:  der Helfer-NPC ist irgendein NPC, der nicht zu einer Gilde
+                     gehoert.
+
+     Zusaetzlich zu den Klassen gibt es noch weitere Flags, die etwas ueber
+     den Helfer-NPC sagen:
+
+     + EXCLUSIVE_HELPER: dieser Helfer-NPC duldet keinen weiteren NPC der
+                         gleichen Klasse.
+     + ACTIVE_HELPER: ist dieses Flag gesetzt, ist der NPC mehr als nur reiner
+                      Schlagfaenger.
+
+     Wird EXCLUSIVE_HELPER gesetzt und es ist in der gleichen Klasse schon ein
+     NPC angemeldet, schlaegt die Registrierung fehl.
+     Ist in der gleichen Klasse bereits ein NPC mit EXCLUSIVE_HELPER
+     angemeldet, schlaegt die Registierung ebenfalls fehl, auch wenn der neue
+     NPC kein EXCLUSIVE_HELPER setzt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn die Registrierung erfolgreich war.
+     0 sonst. In diesem Fall darf der NPC dem Spieler NICHT helfen, weder
+       passiv (Schlagfaenger), noch aktiv.
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Funktion setzt bei der Erfolg die Property P_HELPER_NPC in <npc>
+     auf passende Werte.
+     Bitte auf gar keinen Fall die numerischen Werte der Konstanten fuer
+     <flags> nutzen, diese koennen sich jederzeit aendern.
+
+BEISPIELE
+---------
+::
+
+     1. Ein nicht-exklusiver Gilden-NPC, der dem Spieler folgt.
+     if (spieler->RegisterHelperNPC(this_object(), GUILD_HELPER) == 1) {
+       move(environment(spieler), M_GO);
+       spieler->AddPursuer(this_object());
+       // meldung ausgebene...
+     }
+
+     2a. Ein exklusiver Nicht-Gilden-NPC
+     if (spieler->RegisterHelperNPC(this_object(),
+                                    MISC_HELPER|EXCLUSIVE_HELPER) == 1) {
+       move(environment(spieler), M_GO);
+     }
+
+     2b. Ein nicht-exklusiver Nicht-Gilde-NPC, der nach 2a. kommt.
+     if (spieler->RegisterHelperNPC(this_object(), MISC_HELPER) == 1) {
+       // ... wenn der NPC aus 2a noch existiert, trifft dies hier nie zu.
+     }
+
+     3. Ein exklusiver NPC, der weitere Gilden- und sonstige NPC ausschliesst
+        (Solche Kombination bitte mit der Gilden-Balance abstimmen.)
+     if (spieler->RegisterHelperNPC(this_object(), 
+                            MISC_HELPER|GUILD_HELPER|EXCLUSIVE_HELPER) == 1) {
+       move(environment(spieler), M_GO);
+     }
+
+     4. Die Registrierung ohne Klasse schlaegt fehl, z.B.:
+       spieler->RegisterHelperNPC(this_object(), 0);
+       spieler->RegisterHelperNPC(this_object(), EXCLUSIVE_HELPER);
+
+SIEHE AUCH
+----------
+::
+
+    UnregisterHelperNPC()
+    P_HELPER_NPC
+
diff --git a/doc/sphinx/lfun/RegisterHelperObject.rst b/doc/sphinx/lfun/RegisterHelperObject.rst
new file mode 100644
index 0000000..2d0def4
--- /dev/null
+++ b/doc/sphinx/lfun/RegisterHelperObject.rst
@@ -0,0 +1,145 @@
+RegisterHelperObject()
+======================
+
+FUNKTION
+--------
+::
+
+     int RegisterHelperObject(object helper, int type, 
+                              string|closure callback);
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/helpers.c
+
+ARGUMENTE
+---------
+::
+
+     object helper
+       Das Objekt, das bei einem Lebewesen als Hilfsobjekt registriert 
+       werden soll. Das Objekt muss sich dazu nicht im Inventar des
+       Lebewesens befinden.
+     int type
+       Helfertyp, einer der in /sys/living/helpers.h definierten Typen:
+       - HELPER_TYPE_AERIAL fuer die Flug-/Segelunterstuetzung
+       - HELPER_TYPE_AQUATIC fuer Tauchunterstuetzung
+     string|closure callback
+        Closure oder Funktionsname als String; dies ist die Funktion, die im
+        Objekt helper gerufen wird, um abzufragen, ob es sich aktuell fuer
+        zustaendig erklaert oder nicht.
+
+BESCHREIBUNG
+------------
+::
+
+     Das Objekt "helper" wird als Hilfsobjekt fuer bestimmte Aktivitaeten wie
+     zum Beispiel Fliegen oder Tauchen registriert. 
+
+     
+
+     Die als Callback uebergebene Funktion wird bei der Abfrage der 
+     P_*_HELPERS-Properties (siehe unten) aufgerufen und deren 
+     Rueckgabewert in der Property vermerkt. 
+
+     
+
+     Der Rueckgabewert der Callback-Methode muss im Wertebereich 
+     0..10000 liegen, wobei ein Wert von 0 bedeutet, dass das Hilfsobjekt 
+     sich gerade nicht zustaendig fuehlt. Bei den Werten >0 ist es dem 
+     abfragenden Objekt ueberlassen, wie es diese Daten bewertet.
+
+     Die Funktion muss existieren und public sein, d.h. von aussen gerufen 
+     werden koennen.
+
+     
+
+     Die Funktion bekommt das Spielerobjekt und das abfragende Objekt als
+     Parameter uebergeben.
+
+HINWEIS
+-------
+::
+
+     Es ist ein Unterschied, ob sich ein Objekt via UnregisterHelperObject()
+     als Helfer austraegt, oder ob der Aufruf der Callback-Funktion eine
+     0 zurueckgibt. Im letzteren Fall ist das Objekt nach wie vor 
+     registriert und kann trotzdem vom abfragenden Objekt als 
+     funktionsfaehig angesehen werden.
+
+RUECKGABEWERTE
+--------------
+::
+
+      1  Objekt wurde erfolgreich registriert (HELPER_SUCCESS)
+     -1  angegebenes Hilfsobjekt existiert nicht (HELPER_NO_CALLBACK_OBJECT)
+     -2  angegebenes Hilfsobjekt ist bereits fuer diese Art der
+         Unterstuetzung registriert (HELPER_ALREADY_LISTED)
+
+BEISPIELE
+---------
+::
+
+     a) Eine luftgefuellte Blase will sich als Tauch-Helfer am Spieler
+     anmelden und ist zustaendig, solange sich noch Luft in ihr befindet:
+
+     int luft = 5; // globale Variable z.B. fuer Luftinhalt von 5 Atemzuegen
+
+     // Registrierung im Spielerobjekt
+     if ( TP->RegisterHelperObject(ME, HELPER_TYPE_AQUATIC,
+          "DivingCallback") == HELPER_SUCCESS ) {
+       tell_object(TP, "Du kannst jetzt mit Hilfe der Luftblase unter Wasser "
+         "atmen.\n");
+     }
+
+     // hier koennen natuerlich auch noch komplexere Dinge ablaufen, z.B.
+     // wenn ein Wert zurueckgegeben werden soll, der nicht nur 0 oder 1 ist.
+     public int DivingCallback(object player, object caller) {
+       return (environment(ME)==player && luft>0);
+     }
+
+     b) Ein Spieler befindet sich in einem Raum mit einem steilen Abhang, den
+     man hinunterspringen kann. Dies geht aber nur dann gefahrlos, wenn es
+     Hilfsobjekte gibt, die den (Segel)flug erlauben:
+
+     // cmd_springen() sei die Funktion, die bei der Eingabe des Befehls durch
+     // den Spieler aufgerufen wird.
+     static int cmd_springen(string str) {
+       [...]
+       // Property abfragen
+       mapping helpers = TP->QueryProp(P_AERIAL_HELPERS);
+       // Liste der Werte fuer die einzelnen Unterstuetzungsobjekte ermitteln
+       int *values = m_values(helpers,0);
+       // Spieler schonmal runterbewegen, die Folgen seines Handelns spuert
+       // er dann, wenn er unten angekommen ist.
+       TP->move(zielraum, M_GO|M_SILENT);
+       // "helpers" ist immer ein Mapping, das pruefen wir nicht extra.
+       // Wenn die Liste der Objekte noch mindestens ein Element enthaelt,
+       // nachdem alle unzustaendigen Hilfsobjekte (Rueckgabewert der
+       // Callback-Funktion == 0) rausgerechnet wurden, existiert mindestens
+       // ein geeignetes Hilfsobjekt.
+       if ( sizeof(values-({0})) ) {
+         tell_object(TP, "Sanft segelst Du den Hang hinab.\n");
+       }
+       else {
+         tell_object(TP, BS("Todesmutig springst Du den Hang hinab und "
+           "schlaegst hart unten auf. Du haettest vielleicht daran denken "
+           "sollen, Dir geeignete Hilfsmittel fuer so eine Aktion zu "
+           "besorgen.");
+         TP->Defend(800, ({DT_BLUDGEON}), ([SP_NO_ACTIVE_DEFENSE:1]), ME);
+       }
+       return 1;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Funktionen:  UnregisterHelperObject()
+     Properties:  P_HELPER_OBJECTS, P_AERIAL_HELPERS, P_AQUATIC_HELPERS
+     Sonstiges:   /sys/living/helpers.h
+
+05.02.2015 Arathorn
+
diff --git a/doc/sphinx/lfun/RemoveAdjective.rst b/doc/sphinx/lfun/RemoveAdjective.rst
new file mode 100644
index 0000000..28843be
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveAdjective.rst
@@ -0,0 +1,44 @@
+RemoveAdjective()
+=================
+
+FUNKTION
+--------
+::
+
+     void RemoveAdjective(string|string* adj);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     adj
+          String oder Array von String mit den Adjektiven.
+
+BESCHREIBUNG
+------------
+::
+
+     Falls einige der vorhandenen Adjektive nicht mehr verwendet werden
+     sollen, koennen sie mit dieser Funktion entfernt werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+SIEHE AUCH
+----------
+::
+
+     AddAdjective(), RemoveId(), /std/thing/description.c
+
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveClass.rst b/doc/sphinx/lfun/RemoveClass.rst
new file mode 100644
index 0000000..c6ad24d
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveClass.rst
@@ -0,0 +1,39 @@
+RemoveClass()
+=============
+
+FUNKTION
+--------
+::
+
+     void RemoveClass(string|string* class);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     string/string* class	- String oder Stringarray der Klasse(n)
+
+BESCHREIBUNG
+------------
+::
+
+     Dem Objekt werden einige der mit AddClass() gesetzten Klassen wieder 
+     entzogen.
+     Die allgemein verfuegbaren Klassen sind unter /sys/class.h definiert.
+
+SIEHE AUCH
+----------
+::
+
+     AddClass(), is_class_member()
+     P_CLASS
+
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveCmd.rst b/doc/sphinx/lfun/RemoveCmd.rst
new file mode 100644
index 0000000..ddb6c45
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveCmd.rst
@@ -0,0 +1,91 @@
+RemoveCmd()
+===========
+
+RemoveCmd(L)
+------------
+::
+
+FUNKTION
+--------
+::
+
+    varargs int RemoveCmd(mixed cmd, int norule, mixed id)
+
+DEFINIERT IN
+------------
+::
+
+    /std/thing/commands.c
+
+ARGUMENTE
+---------
+::
+
+    com
+         String oder Array von Strings mit den zu entfernenden Kommandos.
+    norule
+         Kommandos mit Regeln werden nicht entfernt (ausser bei cmd==0)
+    id
+         eine ID, mit der man ein vorher mit dieser ID gespeichertes
+         Kommando eindeutig lvschen kann
+
+BESCHREIBUNG
+------------
+::
+
+    Mit AddCmd() hinzugefuegte Kommandos koennen mit diesem Befehl wieder
+    abgemeldet werden. Die entfernten Kommandos sind direkt nach dem
+    RemoveCmd()-Aufruf nicht mehr ansprechbar.
+
+    Wird ein Regelstring angegeben, so wird die identische AddCmd-
+    Regel entfernt.
+
+BEMERKUNGEN
+-----------
+::
+
+    Uebergibt man fuer com eine 0, so werden alle definierten Kommandos
+    entfernt!
+
+RUECKGABEWERT
+-------------
+::
+
+    Anzahl der entfernten Kommandos.
+
+BEISPIELE
+---------
+::
+
+    (1) AddCmd("test");
+    (2) AddCmd("test|teste&mit&parameter");
+    (3) AddCmd(({"test"}),1);
+    (4) AddCmd("test",0,0,"XYZ");
+    (5) AddCmd("test&mit&parameter",0,0,"XYZ");
+
+    RemoveCmd(0);
+    - entfernt alle Kommandos
+    RemoveCmd("test",1);
+    - entfernt (1) und (3)
+    RemoveCmd("test");
+    - entfernt (1), (3) und einen Teil von (2),
+      es verbleibt "teste&mit&parameter"
+    RemoveCmd("test|teste&mit&parameter"
+    - entfernt (2)
+    RemoveCmd("test",0,"XYZ");
+    - entfernt (4) und (5)
+    RemoveCmd("test",1,"XYZ");
+    - entfernt (4), nicht (5)
+    RemoveCmd(0,0,"XYZ");
+    - entfernt (4) und (5)
+
+SIEHE AUCH
+----------
+::
+
+			AddCmd(L), AddCmd_bsp
+    Sonstiges:		replace_personal(E), enable_commands(E), init(E)
+    Alternativen:	AddAction(L), add_action(E)
+
+24.Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/RemoveDefender.rst b/doc/sphinx/lfun/RemoveDefender.rst
new file mode 100644
index 0000000..911e0c5
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveDefender.rst
@@ -0,0 +1,53 @@
+RemoveDefender()
+================
+
+FUNKTION
+--------
+::
+
+	void RemoveDefender(object friend);
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+	friend
+	  Objekt (normal Lebewesen), welches zukuenftig nicht mehr ueber
+	  Angriffe informiert werden soll und diese auch nicht mehr abwehrt.
+
+BESCHREIBUNG
+------------
+::
+
+	Ein Lebewesen, welches angegriffen wird, kann andere Objekte ueber
+	einen solchen Angriff per InformDefend() informieren oder ihnen
+	sogar die Moeglichkeit geben, per DefendOther() direkt in den
+	laufenden Angriff einzugreifen (Schaeden abwehren oder umwandeln).
+	Im Normalfall handelt es sich hierbei um andere Lebewesen, welche
+	als Verteidiger des angegriffenen Lebewesens auftreten: Daher der
+	Name der Funktion. Ausserdem besteht die Einschraenkung, dass diese
+	Objekte in der gleichen Umgebung sein muessen, wie das zu
+	verteidigende Lebewesen.
+	Die Objekte sind in Form eines Arrays in der Property P_DEFENDERS
+	abgespeichert und koennen dort abgerufen werden. Natuerlich kann
+	man alte Objekte direkt dort loeschen, jedoch sollte man die
+	hierfuer bereitgestellte Funktionen RemoveDefender() verwenden.
+	Zum Hinzufuegen von Eintraegen im Array steht ebenfalls eine
+	Funktion bereit: AddDefender().
+
+SIEHE AUCH
+----------
+::
+
+	AddDefender(), InformDefend(), DefendOther(),
+	P_DEFENDERS, /std/living/combat.c
+
+
+Last modified: Thu Jul 29 18:48:45 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/RemoveDetail.rst b/doc/sphinx/lfun/RemoveDetail.rst
new file mode 100644
index 0000000..889ac20
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveDetail.rst
@@ -0,0 +1,80 @@
+RemoveDetail()
+==============
+
+FUNKTION
+--------
+::
+
+    void RemoveDetail(mixed *keys);
+
+DEFINIERT IN
+------------
+::
+
+    /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+    keys
+      String oder Array von Strings mit den zu entfernenden Details.
+
+BESCHREIBUNG
+------------
+::
+
+    Entfernt die in <keys> angegebenen Details aus der Liste der
+    vorhandenen Details. Uebergibt man fuer <keys> eine 0, so werden
+    saemtliche Details entfernt!
+
+BEISPIEL
+--------
+::
+
+    Ein kleines Beispiel, bei dem eine Oeffnung erscheint und wieder
+    verschwindet, je nachdem, ob man eine Luke oeffnet oder schliesst.
+      int oeffneLuke(string str);
+      int schliesseLuke(string str);
+      ...
+      AddCmd("oeffne", #'oeffneLuke);
+      AddCmd("schliesse", #'schliesseLuke);
+      ...
+      int oeffneLuke(string str) {
+        if(str!="luke" || GetDetail("oeffnung"))
+          return 0;
+        AddDetail("oeffnung","Du siehst eine kleine Oeffnung.\n");
+        return 1;
+      }
+
+      int schliesseLuke(string str) {
+        if(str!="luke" || !GetDetail("oeffnung"))
+          return 0;
+        RemoveDetail("oeffnung"); // Detail wieder entfernen
+        return 1;
+      }
+
+BEMERKUNGEN
+-----------
+::
+
+    Da intern Details und SpecialDetails im gleichen Mapping verwaltet
+    werden, lassen sich mit dieser Funktion auch SpecialDetails
+    entfernen.
+    Die Funktion RemoveSpecialDetail() sollte also nicht genutzt werden!
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+               AddTouchDetail()
+    Loeschen:  RemoveReadDetail(), RemoveSmells(),
+               RemoveSounds(), RemoveTouchDetail()
+    Daten:     P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS,
+               P_TOUCH_DETAILS, P_SPECIAL_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+    Sonstiges: GetDetail(), break_string()
+
+8. Juli 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/RemoveExit.rst b/doc/sphinx/lfun/RemoveExit.rst
new file mode 100644
index 0000000..aa51cbc
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveExit.rst
@@ -0,0 +1,49 @@
+RemoveExit()
+============
+
+FUNKTION
+--------
+::
+
+     void RemoveExit(string|string* cmd);
+
+DEFINIERT IN
+------------
+::
+
+     /std/room/exits
+
+ARGUMENTE
+---------
+::
+
+     string/string* cmd
+          Richtung(en), die entfernt werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+     Die in cmd angegebenen Ausgaenge werden wieder entfernt.
+
+     Ist cmd = 0, so werden alle Ausgaenge entfernt.
+
+BEMERKUNGEN
+-----------
+::
+
+     Ausgaenge werden an der gleichen Stelle gespeichert:
+     - RemoveExit() greift auf die gleichen Daten wie RemoveSpecialExit()
+       zu, entfernt also auch spezielle Ausgaenge!
+
+SIEHE AUCH
+----------
+::
+
+     AddExit(), AddSpecialExit(), GetExits()
+     RemoveSpecialExit(),
+     H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
+     ausgaenge
+
+31.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveExtraLook.rst b/doc/sphinx/lfun/RemoveExtraLook.rst
new file mode 100644
index 0000000..28ffc6b
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveExtraLook.rst
@@ -0,0 +1,65 @@
+RemoveExtraLook()
+=================
+
+RemoveExtraLook()
+
+int RemoveExtraLook(string look);
+----------------------------------------------------
+::
+
+DEFINIERT IN
+------------
+::
+
+   /std/living/description.c
+
+BESCHREIBUNG
+------------
+::
+
+   Der Extralook erscheint in der Langbeschreibung des Lebewesens.
+   Eintraege koennen mit dieser Funktion (vorzeitig) wieder entfernt werden.
+
+ARGUMENTE
+---------
+::
+
+  - string look:
+    Schluesselwort, unter dem der Eintrag, den man entfernen moechte, von
+    AddExtraLook() registriert wurde.
+
+RUECKGABEWERTE
+--------------
+::
+
+  > 0, falls der Eintrag erfolgreich entfernt wurde.
+  < 0 sonst.
+    -1: keinen (gueltigen) <key> uebergeben.
+    -2: kein Eintrag fuer <key> gefunden.
+
+BEMERKUNGEN
+-----------
+::
+
+  Beim Entfernen mit dieser Funktion wird die "Endemeldung" des entfernten
+  Eintrages nicht ausgegeben.
+
+BEISPIELE
+---------
+::
+
+  # Extralook registrieren.
+  living->AddExtraLook("@WER1 wird von einer Horde Daemonen verfolgt.",
+                       "ennox_daemonenhordenverfolgerlook");
+  # Nun kann der Eintrag auch wieder entfernt werden:
+  living->RemoveExtraLook("ennox_daemonenhordenverfolgerlook");
+
+SIEHE AUCH
+----------
+::
+
+   AddExtraLook(),
+   P_INTERNAL_EXTRA_LOOK
+
+14.05.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveFixedObject.rst b/doc/sphinx/lfun/RemoveFixedObject.rst
new file mode 100644
index 0000000..586cd05
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveFixedObject.rst
@@ -0,0 +1,63 @@
+RemoveFixedObject()
+===================
+
+FUNKTION
+--------
+::
+
+	void RemoveFixedObject(string filename);
+
+DEFINIERT IN
+------------
+::
+
+	/std/laden.c
+
+ARGUMENTE
+---------
+::
+
+	str
+	  Dateiname des Objektes, welches nicht mehr dauerhaft im Laden sein
+	  soll.
+
+RUeCKGABEWERT
+-------------
+::
+
+        keiner
+
+BESCHREIBUNG
+------------
+::
+
+	Objekte, die mittels der Funktion AddFixedObject() im Laden
+	eingebunden werden, sind dort staendig verfuegbar. Um diesen Zustand
+	wieder aufzuheben, kann man sie mittels dieser Funktion wieder
+	entfernen. Eventuell im Lager befindliche Objekte dieser Art werden
+	hierbei nicht zerstoert und koennen durchaus noch gekauft werden,
+	bis sie alle sind. Danach gibt es sie dort nicht mehr!
+
+BEISPIELE
+---------
+::
+
+	Im allen Laeden gibt es schon ein Objekt, welches dort
+	standardmaessig erhaeltlich ist. Folgende Zeile sorgt dafuer:
+	  AddFixedObject("/obj/boerse",80,({"boerse","geldboerse"}));
+	Wenn man das in seinem Laden nicht wuenscht, kann man die Geldboerse
+	mittels folgender Zeile wieder aus dem Laden loeschen:
+	  RemoveFixedObject("/obj/boerse");
+	Es ist nicht moeglich, keine oder mehrere Objekte anzugeben, um auf
+	diese Weise alle bzw. mehrere Objekte als nicht mehr staendig
+	verfuegbar zu markieren.
+
+SIEHE AUCH
+----------
+::
+
+	AddFixedObject(), SetStorageRoom(), /std/store.c
+
+
+Last modified: Thu Jun 18 14:19:19 1998 by Patryn
+
diff --git a/doc/sphinx/lfun/RemoveFromMenu.rst b/doc/sphinx/lfun/RemoveFromMenu.rst
new file mode 100644
index 0000000..f692de9
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveFromMenu.rst
@@ -0,0 +1,57 @@
+RemoveFromMenu()
+================
+
+FUNKTION
+--------
+::
+
+     int RemoveFromMenu(mixed ids)
+
+DEFINIERT IN
+------------
+::
+
+     /std/pub.c
+
+ARGUMENTE
+---------
+::
+
+     ids - string oder string*
+	   String oder Array von Strings, mit denen sich die Speise bzw.
+           das Getraenk beim Bestellen ansprechen laesst.
+
+RUECKGABEWERT
+-------------
+::
+
+     int - Anzahl entfernter Einzelmenueeintraege
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Methode kann man id-basiert Speisen und Getraenke
+     wieder von der Karte entfernen (wenn zB nur saisonbasiert
+     bestimmte Dinge angeboten werden sollen).
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     - sich zwischen zwei Speisen ueberschneidende IDs fuehren zu
+       undefiniertem Verhalten!
+     - bei Benutzung von RemoveFromMenu sollte man in Delay-Speisen oder
+       -Getraenken auf die Nutzung vom ident-Parameter in den
+       Serviernachrichten verzichten (es sei, man weiss was man tut)
+
+SIEHE AUCH
+----------
+::
+
+     AddToMenu(), AddFood(), AddDrink(), /sys/pub.h
+
+15. Februar 2009 Gloinson
+
diff --git a/doc/sphinx/lfun/RemoveFunc.rst b/doc/sphinx/lfun/RemoveFunc.rst
new file mode 100644
index 0000000..4a00e99
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveFunc.rst
@@ -0,0 +1,114 @@
+RemoveFunc()
+============
+
+FUNKTION
+--------
+::
+
+     int RemoveFunc(object ruest, int info, object user);
+
+DEFINIERT IN
+------------
+::
+
+     eigenen Objekten (fuer /std/clothing/wear)
+
+ARGUMENTE
+---------
+::
+
+     ruest (object)
+          Die Ruestung/Kleidung, die ausgezogen werden soll.
+     info (int)
+          Bei (info&M_SILENT) wird keine Meldung ueber das Ausziehen
+          ausgegeben.
+          Bei (info&M_NOCHECK) wird die Kleidung ausgezogen, egal was diese
+          Funktion zurueckgibt. Dies tritt insbesondere dann auf, wenn der
+          Spieler, der die Ruestung traegt, stirbt und die Ruestung in
+          die Leiche bewegt wird.
+     user (object)
+          Das Lebewesen, welches die Ruestung/Kleidung gerade traegt und sie
+          ausziehen will.
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Funktion kann man pruefen, ob sich das Kleidungsstueck bzw.
+     Ruestung <ruest> von this_player() ausziehen laesst oder nicht.
+     Kann die Ruestung ausgezogen werden, so muss ein Wert ungleich 0
+     zurueckgegeben werden.
+
+     
+
+     Diese Funktion meldet nur einen _Wunsch_ an. Dieser kann ignoriert
+     werden (z.B. bei bestimmten Bewegungen, Tod des Spielers etc.).
+     Unabhaengig vom Wert dieser Funktion kann das Ausziehen noch Scheitern
+     oder Erzwungen werden.
+     Wenn ihr sicher sein wollt, dass der Spieler ein Objekt angezogen hat,
+     benutzt bitte InformUnwear().
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn sich die Ruestung nicht ausziehen laesst, ansonsten ungleich 0.
+
+BEMERKUNGEN
+-----------
+::
+
+     Verfluchte Ruestungen, die sich erst nach Entfernung des Fluches wieder
+     ausziehen lassen, sollte man besser mit P_CURSED realisieren (man spart
+     die RemoveFunc() ein).
+     Bitte nicht drauf verlassen, dass this_player() das ausziehende Lebewesen
+     ist.
+     Die Reihenfolge der Argumente ist etwas unschoen, aber leider wurde <user>
+     erheblich spaeter hinzugefuegt und es war unmoeglich, einige hundert
+     Objekte zu aendern.
+
+BEISPIELE
+---------
+::
+
+     Ein Umhang, den man nur mit guter Einstellung wieder ausziehen kann:
+
+     inherit "std/armour.c";
+
+     #include <properties.h>
+     #include <moving.h>
+
+     create()
+     {
+       ::create();
+
+       SetProp(P_ARMOUR_TYPE, AT_CLOAK);
+       /* zig weitere SetProp's, um den Umhang zu konfigurieren */
+
+       /* RemoveFunc() ist im Umhang selbst zu finden */
+       SetProp(P_REMOVE_FUNC, this_object());
+     }
+
+     int RemoveFunc(object me, int info, object user)
+     {
+       if (user->QueryProp(P_ALIGN) >= 0 || (info&M_NOCHECK))
+         return 1;   /* gute Charaktere koennen den Umhang ausziehen */
+
+       /* Ansonsten geben wir evtl. einen entsprechenden Hinweis aus: */
+       if (!(info&M_SILENT))
+           write( "Der Umhang wird von Deiner Bosheit so sehr "
+                 +"angezogen, dass Du ihn\nnicht mehr ausziehen kannst!\n");
+       return 0;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     P_WEAR_MSG, P_UNWEAR_MSG, P_WIELD_MSG, P_UNWIELD_MSG
+     DoUnwear(), DoWear(), InformWear(), InformUnwear()
+     /std/clothing/wear.c
+
+
+02.07.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveId.rst b/doc/sphinx/lfun/RemoveId.rst
new file mode 100644
index 0000000..0d45abc
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveId.rst
@@ -0,0 +1,45 @@
+RemoveId()
+==========
+
+FUNKTION
+--------
+::
+
+     void RemoveId(string|string* ids);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     ids
+          String oder Array von Strings mit den Bezeichnungen, die aus der
+          Liste der IDs des Objektes entfernt werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn ein Objekt sich nicht mehr mit gewissen Bezeichnern ansprechen
+     lassen soll, kann man diese mit dieser Funktion entfernen.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+SIEHE AUCH
+----------
+::
+
+     AddId(), RemoveAdjective(), /std/thing/description.c
+
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveInfo.rst b/doc/sphinx/lfun/RemoveInfo.rst
new file mode 100644
index 0000000..d550826
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveInfo.rst
@@ -0,0 +1,45 @@
+RemoveInfo()
+============
+
+FUNKTION
+--------
+::
+
+     void RemoveInfo(string key)
+
+DEFINIERT IN
+------------
+::
+
+     /std/npc/info.c
+
+ARGUMENTE
+---------
+::
+
+     key	zu loeschender Schluessel
+
+BESCHREIBUNG
+------------
+::
+
+     Loescht die Antwort zum entsprechenden Frageschluessel.
+
+BEISPIEL
+--------
+::
+
+     // erstellen und loeschen
+     AddInfo("gold","sagt: Ich habe keines.\n");
+     RemoveInfo("gold");
+
+SIEHE AUCH
+----------
+::
+
+     AddInfo(L), AddSpecialInfo(L)
+     P_PRE_INFO, P_DEFAULT_INFO
+     /std/npc/info.c
+
+17.Aug.2003 Gloinson
+
diff --git a/doc/sphinx/lfun/RemoveItem.rst b/doc/sphinx/lfun/RemoveItem.rst
new file mode 100644
index 0000000..808704a
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveItem.rst
@@ -0,0 +1,64 @@
+RemoveItem()
+============
+
+FUNKTION
+--------
+::
+
+	void RemoveItem(mixed file);
+
+DEFINIERT IN
+------------
+::
+
+	/std/room/items.c
+
+ARGUMENTE
+---------
+::
+
+	file
+	     String oder Array von Strings mit dem Namen des zu entfernenden
+	     Objekts.
+
+BESCHREIBUNG
+------------
+::
+
+	Das mit AddItem(file) dem Raum hinzugefuegte Objekt wird wieder aus
+	der Liste der Objekte entfernt.
+	Wurde bei AddItem() ein Array von Dateinamen uebergeben, so muss das
+	selbe Array auch bei RemoveItem() uebergeben werden!
+	Falls das Objekt, das durch den AddItem()-Aufruf erzeugt wurde, sich
+	noch im Raum befindet, wird es durch den RemoveItem()-Aufruf zerstoert.
+
+RUECKGABEWERT
+-------------
+::
+
+	keiner
+
+BEISPIELE
+---------
+::
+
+	Ein muellschluckerfreier Laden laesst sich wie folgt erzeugen:
+
+	inherit "/std/laden";
+	#include <properties.h>
+
+	create()
+	{
+	  ::create();  // Hier wird u.a. der Muellschlucker erzeugt
+
+	  RemoveItem("/obj/entsorg"); // und weg damit!
+
+	  SetProp(...);  // und die normale Beschreibung...
+	}
+
+SIEHE AUCH
+----------
+::
+
+	AddItem(), /std/room/items.c
+
diff --git a/doc/sphinx/lfun/RemoveKnownPotion.rst b/doc/sphinx/lfun/RemoveKnownPotion.rst
new file mode 100644
index 0000000..b94313b
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveKnownPotion.rst
@@ -0,0 +1,45 @@
+RemoveKnownPotion()
+===================
+
+FUNKTION
+--------
+::
+
+     int RemoveKnownPotion(int nr)
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/potion.c
+
+ARGUMENTE
+---------
+::
+
+     int nr       Nummer eines ZTs
+
+BESCHREIBUNG
+------------
+::
+
+     Entfernt einen bekannten ZT aus einen Spieler. Nur vom Orakel rufbar.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1  Erfolg
+     -1 fehlende Berechtigung
+     -2 Nummer nicht eingetragen
+
+SIEHE AUCH
+----------
+::
+
+     Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
+     Verwandt:  FindPotion(), AddKnownPotion(), InList()
+     Props:     P_POTIONROOMS, P_KNOWN_POTIONROOMS
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/lfun/RemovePluralId.rst b/doc/sphinx/lfun/RemovePluralId.rst
new file mode 100644
index 0000000..1916656
--- /dev/null
+++ b/doc/sphinx/lfun/RemovePluralId.rst
@@ -0,0 +1,50 @@
+RemovePluralId()
+================
+
+FUNKTION
+--------
+::
+
+     void RemovePluralId(mixed id);
+
+DEFINIERT IN
+------------
+::
+
+     /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+     id
+          Identfikationsstring oder Array von Strings
+
+BESCHREIBUNG
+------------
+::
+
+     Es werden ein oder mehrere Bezeichner entfernt, mit denen sich 
+     mehrere Einheiten der Menge ansprechen lassen.
+
+RUECKGABEWERT
+-------------
+::
+
+     keiner
+
+BEISPIELE
+---------
+::
+
+     siehe /items/money.c
+
+SIEHE AUCH
+----------
+::
+
+     RemoveSingularId(), AddPluralId(), AddId(), id(), /std/unit.c
+
+
+Last modified: Mon Jul 14 11:30:00 1997 by Silvana
+
diff --git a/doc/sphinx/lfun/RemovePursuer.rst b/doc/sphinx/lfun/RemovePursuer.rst
new file mode 100644
index 0000000..0eca43a
--- /dev/null
+++ b/doc/sphinx/lfun/RemovePursuer.rst
@@ -0,0 +1,53 @@
+RemovePursuer()
+===============
+
+RemoveRursuer()
+---------------
+::
+
+FUNKTION
+--------
+::
+
+  void RemovePursuer(object pursuer)
+
+ARGUMENTE
+---------
+::
+
+  pursuer: Objekt, das aus der Verfolgerliste des Objektes, in dem
+           RemovePursuer aufgerufen wurde, ausgetragen werden soll.
+
+FUNKTION
+--------
+::
+
+  Durch den Aufruf von RemovePursuer in einem Objekt, welches living() ist,
+  wird das Object, welches als Argument uebergeben wurde aus der Liste
+  der Verfolger ausgetragen.
+
+RUECKGABEWERT
+-------------
+::
+
+  keiner
+
+BEMERKUNG
+---------
+::
+
+  keine
+
+BEISPIELE
+---------
+::
+
+  find_player("jof")->RemovePursuer(find_player("kirk"))
+  Danach wird Jof nicht mehr von Kirk verfolgt.
+
+SIEHE AUCH
+----------
+::
+
+  "AddPursuer", "PreventFollow"
+
diff --git a/doc/sphinx/lfun/RemoveReadDetail.rst b/doc/sphinx/lfun/RemoveReadDetail.rst
new file mode 100644
index 0000000..6bbc4a7
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveReadDetail.rst
@@ -0,0 +1,50 @@
+RemoveReadDetail()
+==================
+
+FUNKTION
+--------
+::
+
+    void RemoveReadDetail(string|string* keys);
+
+DEFINIERT IN
+------------
+::
+
+    /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+    keys
+         String oder Array von Strings mit den zu entfernenden Details.
+
+BESCHREIBUNG
+------------
+::
+
+    Entfernt die in keys angegebenen Details aus der Liste der vorhandenen
+    lesbaren Details.
+
+BEMERKUNGEN
+-----------
+::
+
+    Uebergibt man fuer keys eine 0, so werden saemtliche lesbaren Details
+    entfernt!
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+               AddTouchDetail()
+    Loeschen:  RemoveDetail(), RemoveSmells(),
+               RemoveSounds(), RemoveTouchDetail()
+    Daten:     P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+    Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveResistanceModifier.rst b/doc/sphinx/lfun/RemoveResistanceModifier.rst
new file mode 100644
index 0000000..52c754d
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveResistanceModifier.rst
@@ -0,0 +1,57 @@
+RemoveResistanceModifier()
+==========================
+
+FUNKTION
+--------
+::
+
+     varargs void RemoveResistanceModifier(string add);
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+     string add:
+      Ein eventueller Identifikator fuer einen gesetzten Modifikator.
+
+BESCHREIBUNG
+------------
+::
+
+     Die von einem Objekt im Zielobjekt gesetzte Resistenz wird geloescht,
+     der Schluessel add wird dazu benutzt, eine bestimmte Resistenz zu
+     loeschen (so kann ein setzendes Objekt mehrere verschiedene Re-
+     sistenzen setzen und selektiv loeschen).
+
+BEISPIELE
+---------
+::
+
+     // unser Oel aus AddResistanceModifier() verbrennt endgueltig
+     varargs void trigger_sensitive_attack() {
+      ...
+      if(environment() && living(environment())) {
+       environment()->RemoveResistanceModifier("oel");
+       tell_object(environment(),"Das Oel verbrennt endgueltig.\n");
+      }
+      remove();
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Modifikatoren:	AddResistanceModifier, P_RESISTANCE_MODIFIER
+     simple Resistenz:	P_RESISTANCE, P_VULNERABILITY
+     Hauptmapping:	P_RESISTANCE_STRENGTHS
+     Berechnung:	CheckResistance(), UpdateResistanceStrengths()
+     anderes:		balance, /std/armour/combat.c, /std/living/combat.c
+
+29.Apr 2002, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/RemoveRoute.rst b/doc/sphinx/lfun/RemoveRoute.rst
new file mode 100644
index 0000000..5e06e2b
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveRoute.rst
@@ -0,0 +1,43 @@
+RemoveRoute()
+=============
+
+FUNKTION
+--------
+::
+
+     void RemoveRoute();
+
+DEFINIERT IN
+------------
+::
+
+     /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Der Transporter wird angehalten und der gesamte Fahrplan wird
+     geloescht. Damit lassen sich zum Beispiel variable Routen konstruieren.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+SIEHE AUCH
+----------
+::
+
+     AddRoute(), AddMsg(), AddFun(), /std/transport.c
+
+
+Last modified: Wed May 8 10:24:26 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/RemoveSensitiveObject.rst b/doc/sphinx/lfun/RemoveSensitiveObject.rst
new file mode 100644
index 0000000..f67224f
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveSensitiveObject.rst
@@ -0,0 +1,79 @@
+RemoveSensitiveObject()
+=======================
+
+FUNKTION
+--------
+::
+
+     void RemoveSensitiveObject(object ob)
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/inventory.c
+     generalizes /std/living/inventory.c
+
+ARGUMENTE
+---------
+::
+
+     ob - zu entfernendes Objekt
+
+BESCHREIBUNG
+------------
+::
+
+     Entfernt ob aus den Benachrichtigungslisten des Containers.
+     Wird von thing/moving.c im alten Environment gerufen, wenn
+     P_SENSITIVE gesetzt ist.
+     Ruft dazu RemoveSensitiveObjectFromList().
+
+BEMERKUNGEN
+-----------
+::
+
+     Setzt man P_SENSITIVE nicht als Default sondern situationsabhaengig,
+     dann muss man auch RemoveSensitiveObject im Environment
+     auch selbst rufen!
+
+BEISPIEL
+--------
+::
+
+     // Fackel (inheriting lightsource)
+     void create() {
+     ...
+       SetProp(P_SENSITIVE,
+        ({({SENSITIVE_INVENTORY_TRIGGER,DT_FIRE,120})}));
+     ...
+     }
+
+     // wenn die Fackel geloescht wird, verliert sie ihre aktive
+     // Eigenschaft und muss das dem environment() mitteilen
+     static int extinguish(string str) {
+      int i;
+      i=::extinguish(str);
+      if(i && QueryProp(P_LIGHT)<=0) {
+       SetProp(P_SENSITIVE,0);
+       if(environment())
+        environment()->RemoveSensitiveObject(this_object());
+      }
+      return i;
+     }
+
+     - empfindliche Objekte wie Eiszapfen koennen jetzt wieder gefahrlos
+       in das selbe environment() bewegt werden
+
+SIEHE AUCH
+----------
+::
+
+     P_SENSITIVE
+     InsertSensitiveObject
+     insert_sensitive_inv_trigger, insert_sensitive_inv
+     P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY, P_SENSITIVE_INVENTORY_TRIGGER
+     CheckSensitiveAttack
+
+25.Apr.2001, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/RemoveSingularId.rst b/doc/sphinx/lfun/RemoveSingularId.rst
new file mode 100644
index 0000000..fe146f2
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveSingularId.rst
@@ -0,0 +1,50 @@
+RemoveSingularId()
+==================
+
+FUNKTION
+--------
+::
+
+     void RemoveSingularId(mixed id);
+
+DEFINIERT IN
+------------
+::
+
+     /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+     id
+          Identifikationsstring oder Array von Strings
+
+BESCHREIBUNG
+------------
+::
+
+     Es werden ein oder mehrere Bezeichner entfernt, mit denen sich eine
+     einzelne Einheit ansprechen laesst.
+
+RUECKGABEWERT
+-------------
+::
+
+     keiner
+
+BEISPIELE
+---------
+::
+
+     siehe /items/money.c
+
+SIEHE AUCH
+----------
+::
+
+     AddSingularId(), RemovePluralId(), AddId(), id(), /std/unit.c
+
+
+Last modified: Mon Jul 14 11:31:00 1997 by Silvana
+
diff --git a/doc/sphinx/lfun/RemoveSkillAttributeModifier.rst b/doc/sphinx/lfun/RemoveSkillAttributeModifier.rst
new file mode 100644
index 0000000..c83c2a7
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveSkillAttributeModifier.rst
@@ -0,0 +1,85 @@
+RemoveSkillAttributeModifier()
+==============================
+
+FUNKTION
+--------
+::
+
+    public int RemoveSkillAttributeModifier(object caster, string atrname)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skill_attributes.c
+
+ARGUMENTE
+---------
+::
+
+    <atrname>   string
+                Name des Skill-Attributes, von dem der Modifikator geloescht
+                werden soll.
+                (Definiert in /sys/living/skill_attributes.h)
+
+    <caster>    object
+                Objekt, dessen Modifikator wieder entfernt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+    Entfernt den Modifikator, den Object <caster> gesetzt hat, wieder. Dies
+    ist nur notwendig, wenn der Effekt vor Ablauf der Gueltigkeit des
+    Modifikators aufgehoben werden soll.
+
+RUECKGABEWERT
+-------------
+::
+
+    SA_MOD_REMOVED         wenn der Modifikator geloescht wurde
+    SA_MOD_NOT_FOUND       wenn der Modifikator nicht gefunden wurde
+    Wenn man nur wissen will, ob die Operation erfolgreich war, empfiehlt es
+    sich, auf == SA_MOD_REMOVED zu pruefen.
+
+BEISPIELE
+---------
+::
+
+    // eine Waffe setzt im InformWield() einen Bonus auf SA_DAMAGE fuer 10min
+    protected void InformWield(object pl, int silent) {
+      if (objectp(pl)) {
+        if (pl->ModifySkillAttribute(SA_DAMAGE, 20, 600) == SA_MOD_OK)
+          // Erfolgsmeldung an Spieler
+        else
+          // Misserfolgsmeldung an Spieler.
+      }
+    }
+
+    // wenn der Spieler die Waffe vor Ablauf der 600s wegstecken will, muss
+    // der Bonus natuerlich auch wieder raus
+    protected void InformUnwield(object pl, int silent) {
+      if (objectp(pl))
+        pl->RemoveSkillAttributeModifier(this_object(), SA_DAMAGE);
+        // falls kein solcher Mod mehr gesetzt war, liefert RSAM()
+        // SA_MOD_NOT_FOUND zurueck. Auswertung des Rueckgabewertes ist
+        // vernachlaessigt.
+    }
+
+    
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkill, QuerySkillAbility
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    QuerySkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung, skill_info_liste
+    * Properties:   P_NEWSKILLS
+
+13.08.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveSmells.rst b/doc/sphinx/lfun/RemoveSmells.rst
new file mode 100644
index 0000000..1a50ebd
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveSmells.rst
@@ -0,0 +1,57 @@
+RemoveSmells()
+==============
+
+FUNKTION
+--------
+::
+
+    void RemoveSmells(string|string* keys);
+
+DEFINIERT IN
+------------
+::
+
+    /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+    keys
+      String oder Array von Strings mit den zu entfernenden Details.
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion entspricht dem RemoveDetail() fuer Standarddetails,
+    nur koennen hiermit Gerueche entfernt werden:
+    Entfernt die in <keys> angegebenen Details aus der Liste der
+    vorhandenen Details. Uebergibt man fuer <keys> eine 0, so werden
+    saemtliche Details entfernt!
+
+BEISPIEL
+--------
+::
+
+    Zuerst erzeugen wir ein kleines Detail, mit dem wir am Rauch riechen
+    koennen. Das Feuer brennt langsam ab und das Detail wird wieder
+    entfernt:
+
+      AddSmells("rauch",* H U S T *\n");
+      call_out(#'RemoveSmells, 100, "rauch");
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+               AddTouchDetail()
+    Loeschen:  RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+               RemoveSounds(), RemoveTouchDetail()
+    Daten:     P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+    Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveSounds.rst b/doc/sphinx/lfun/RemoveSounds.rst
new file mode 100644
index 0000000..4f1290d
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveSounds.rst
@@ -0,0 +1,66 @@
+RemoveSounds()
+==============
+
+FUNKTION
+--------
+::
+
+    void RemoveSounds(string|string* keys);
+
+DEFINIERT IN
+------------
+::
+
+    /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+    keys
+      String oder Array von Strings mit den zu entfernenden Details.
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion entspricht dem RemoveDetail() fuer Standarddetails,   
+    nur koennen hiermit Gerauesche entfernt werden:
+    Entfernt die in <keys> angegebenen Details aus der Liste der
+    vorhandenen Details. Uebergibt man fuer <keys> eine 0, so werden
+    saemtliche Details entfernt!
+
+BEISPIEL
+--------
+::
+
+    Wir lassen etwas Musik spielen und wenn wir den Plattenspieler
+    ausmachen, dann endet sie und man hoert auch nichts mehr:
+
+      int ausmachen(string str);
+      ...
+      AddSounds(({"musik","hip-hop"}) ,"Klingt nach Hip-Hop...\n");
+      AddCmd("mach|mache&plattenspieler&aus", #'ausmachen,
+             "Was willst du (aus)machen?|Willst du den ausmachen?^");
+      ...
+      int ausmachen(string str) {
+        if(!GetDetail("musik", 0, SENSE_SOUND)) // existiert Musikdetail ?
+          return("Der Plattenspieler laeuft doch gar nicht!\n", 1);
+        RemoveSounds(0);
+         return 1;
+      }
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+               AddTouchDetail()
+    Loeschen:  RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+               RemoveTouchDetail()
+    Daten:     P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+    Sonstiges: GetDetail(), break_string()
+
+8. Juli 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/RemoveSpecialDetail.rst b/doc/sphinx/lfun/RemoveSpecialDetail.rst
new file mode 100644
index 0000000..83bb25a
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveSpecialDetail.rst
@@ -0,0 +1,60 @@
+RemoveSpecialDetail()
+=====================
+
+VERALTET RemoveSpecialDetail()
+------------------------------
+::
+
+FUNKTION
+--------
+::
+
+    void RemoveSpecialDetail(string|string* keys);
+
+DEFINIERT IN
+------------
+::
+
+    /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+    keys
+      String oder Array von Strings mit den zu entfernenden Details.
+
+BESCHREIBUNG
+------------
+::
+
+    Entfernt die in keys angegebenen Details aus der Liste der
+    vorhandenen SpecialDetails.
+
+    VERALTET: Bitte RemoveDetail() benutzen.
+
+BEMERKUNGEN
+-----------
+::
+
+    Uebergibt man fuer keys eine 0, so werden saemtliche SpecialDetails
+    entfernt!
+    Da intern Details und SpecialDetails im gleichen Mapping verwaltet
+    werden, lassen sich mit dieser Funktion auch Details entfernen.
+    Man sollte diese Funktion deshalb nicht mehr verwenden, siehe
+    AddDetail mit Closures.
+
+SIEHE AUCH
+----------
+::
+
+    Setzen :   AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+               AddTouchDetail()
+    Loeschen:  RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+               RemoveSounds(), RemoveTouchDetail()
+    Daten:     P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+    Veraltet:  AddSpecialDetail(), P_READ_MSG
+    Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveSpecialExit.rst b/doc/sphinx/lfun/RemoveSpecialExit.rst
new file mode 100644
index 0000000..ba3bfbf
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveSpecialExit.rst
@@ -0,0 +1,49 @@
+RemoveSpecialExit()
+===================
+
+FUNKTION
+--------
+::
+
+     void RemoveSpecialExit(string|string* cmd);
+
+DEFINIERT IN
+------------
+::
+
+     /std/room/exits
+
+ARGUMENTE
+---------
+::
+
+     string/string* cmd
+          Richtung(en), die entfernt werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+     Die in cmd angegebenen Ausgaenge werden wieder entfernt.
+
+     Ist cmd = 0, so werden alle Ausgaenge entfernt.
+
+BEMERKUNGEN
+-----------
+::
+
+     Ausgaenge werden an der gleichen Stelle gespeichert:
+     - RemoveSpecialExit() greift auf die gleichen Daten wie RemoveExit()
+       zu, entfernt also auch normale Ausgaenge!
+
+SIEHE AUCH
+----------
+::
+
+     AddExit(), AddSpecialExit(), AddGuardedExit(), GetExits()
+     RemoveExit(),
+     P_EXITS, P_HIDE_EXITS, /std/room/exits.c
+     ausgaenge
+
+31.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveTouchDetail.rst b/doc/sphinx/lfun/RemoveTouchDetail.rst
new file mode 100644
index 0000000..104f8d2
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveTouchDetail.rst
@@ -0,0 +1,75 @@
+RemoveTouchDetail()
+===================
+
+FUNKTION
+--------
+::
+
+    void RemoveTouchDetail(string|string* keys);
+
+DEFINIERT IN
+------------
+::
+
+    /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+    keys
+      String oder Array von Strings mit den zu entfernenden Details.
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion entspricht dem RemoveDetail() fuer Standarddetails,
+    nur koennen hiermit (ab)tastbare Details entfernt werden:
+    Entfernt die in <keys> angegebenen Details aus der Liste der
+    vorhandenen Details. Uebergibt man fuer <keys> eine 0, so werden
+    saemtliche tastbaren/fuehlbaren Details entfernt!
+
+BEISPIEL
+--------
+::
+
+    Zuerst wird ein Detail "boden" erzeugt, das abgetastet werden kann.
+    Dieses kann durch Betaetigen eines Knopfes, aeh, entfernt werden.
+
+      int knopf();
+      void knopf2();
+
+      AddTouchDetail("boden", "Er ist aus Stein.\n");
+      AddCmd("drueck|druecke&knopf", #'knopf, "Was willst du druecken?");
+
+      void knopf() {
+        tell_room(this_object(), break_string(
+          this_player()->Name(WER)+" drueckt einen Knopf, der dabei satt "+
+          "klackt.", 78));
+
+        if(find_call_out(#'knopf2)<=0)
+          call_out(#'knopf2, 1);
+      }
+
+      
+
+      void knopf2() {
+        tell_room(this_object(), "Uhoh. Der Boden klappt weg. Du faellst.");
+        RemoveTouchDetails("boden");
+      }
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+               AddTouchDetail()
+    Loeschen:  RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+               RemoveSounds()
+    Daten:     P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+    Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/ResizeRingBuffer.rst b/doc/sphinx/lfun/ResizeRingBuffer.rst
new file mode 100644
index 0000000..e00d5ad
--- /dev/null
+++ b/doc/sphinx/lfun/ResizeRingBuffer.rst
@@ -0,0 +1,68 @@
+ResizeRingBuffer()
+==================
+
+FUNKTION
+--------
+::
+
+    protected struct std_ringbuffer buf RingBufferPut(
+                                                   struct std_ringbuffer buf, 
+                                                   int size);
+
+DEFINIERT IN
+------------
+::
+
+    /std/util/ringbuffer.c
+    /sys/util/ringbuffer.h
+
+    
+
+ARGUMENTE
+---------
+::
+
+    buf  - Ringpuffer, dessen Groesse geaendert werden soll
+    size - neue Groesse (int) 
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion erstellt einen neuen Ringpuffer der Groesse <size>, welcher
+    den gleichen Modus hat wie <buf> und die gleichen Daten enthaelt.
+    Ist der neue Puffer kleiner als <buf>, so kommt es hierbei zu
+    Datenverlust.
+    <buf> wird nicht veraendert. Ist die Groesse von <buf> gleich der
+    neuen gewuenschten Groesse, wird letztendlich der Ringpuffer kopiert. 
+    Je nach Groesse von <buf> und Wert von <size> kann dies eine teure
+    Angelegenheit sein.
+
+RUeCKGABEWERT
+-------------
+::
+
+    Der neue Ringpuffer mit Groesse <size>.
+
+BEISPIELE
+---------
+::
+
+    // Ringpuffer anlegen:
+    struct std_ringbuffer buffer = CreateRingBuffer(5, MODE_FIFO);
+    // 5 Werte reinschreiben:
+    foreach(int i: 5) RingBufferPut(buffer, i);
+    // Groesse aendern
+    buffer = ResizeRingBuffer(buffer, 10);
+    // Daten als Array ermitteln:
+    mixed array = RingBufferGet(buffer);
+    // array enthaelt: ({0,0,0,0,0,0,1,2,3,4})
+
+SIEHE AUCH
+----------
+::
+
+    RingBufferGet(), RingBufferPut(), CreateRingBuffer()
+
+23.05.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/RingBufferGet.rst b/doc/sphinx/lfun/RingBufferGet.rst
new file mode 100644
index 0000000..445e9f3
--- /dev/null
+++ b/doc/sphinx/lfun/RingBufferGet.rst
@@ -0,0 +1,63 @@
+RingBufferGet()
+===============
+
+FUNKTION
+--------
+::
+
+    protected mixed RingBufferGet(struct std_ringbuffer buf);
+
+DEFINIERT IN
+------------
+::
+
+    /std/util/ringbuffer.c
+    /sys/util/ringbuffer.h
+
+ARGUMENTE
+---------
+::
+
+    buf - Ringpuffer, welcher ausgeben werden soll
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion liefert die Daten des Ringpuffers in Form eines Arrays
+    zurueck, welches dann weiterverarbeitet werden kann.
+    Die Reihenfolge der Daten ist entsprechend des beim Anlegen des
+    Ringpuffers angebenen Modes:
+    MODE_FIFO: aelteste Daten zuerst
+    MODE_LIFO: neueste Daten zuerst
+
+BEMERKUNGEN
+-----------
+::
+
+    Aenderungen am Array beeinflussen die Daten des Ringpuffers nicht. Aber:
+    Hierbei werden die Daten nicht tief kopiert. D.h. enthaelt der Ringpuffer
+    Referenzen auf weitere Daten, zeigen der Ringpuffer und das hier
+    gelieferte Array auf die gleichen Daten.
+
+BEISPIELE
+---------
+::
+
+    // Ringpuffer anlegen:
+    struct std_ringbuffer buffer = CreateRingBuffer(10, MODE_FIFO);
+    // 15 Werte reinschreiben:
+    foreach(int i: 15) RingBufferPut(buffer, i);
+    // Werte abrufen:
+    mixed array=RingBufferGet(buffer);
+    // array enthaelt nun:
+    // ({5,6,7,8,9,10,11,12,13,14}) 
+
+SIEHE AUCH
+----------
+::
+
+    CreateRingBuffer(), RingBufferPut(), ResizeRingBuffer()
+
+23.05.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/RingBufferPut.rst b/doc/sphinx/lfun/RingBufferPut.rst
new file mode 100644
index 0000000..4d35ad6
--- /dev/null
+++ b/doc/sphinx/lfun/RingBufferPut.rst
@@ -0,0 +1,49 @@
+RingBufferPut()
+===============
+
+FUNKTION
+--------
+::
+
+    protected void RingBufferPut(struct std_ringbuffer buf, mixed val);
+
+DEFINIERT IN
+------------
+::
+
+    /std/util/ringbuffer.c
+    /sys/util/ringbuffer.h
+
+ARGUMENTE
+---------
+::
+
+    buf - Ringpuffer, in den <val> geschrieben werden soll
+    val - neues Datum
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion schreibt <val> in den Ringpuffer <buf>. Hierbei wird ggf.
+    das aelteste im Puffer existierende Datum ueberschrieben. <buf> muss eine
+    von CreateRingBuffer() oder ResizeRingBuffer() zurueckgelieferter
+    Ringpuffer sein.
+
+BEISPIELE
+---------
+::
+
+    // Ringpuffer anlegen:
+    struct std_ringbuffer buffer = CreateRingBuffer(10, MODE_FIFO);
+    // 15 Werte reinschreiben:
+    foreach(int i: 15) RingBufferPut(buffer, i);
+
+SIEHE AUCH
+----------
+::
+
+    RingBufferGet(), CreateRingBuffer(), ResizeRingBuffer()
+
+23.05.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/SearchPath.rst b/doc/sphinx/lfun/SearchPath.rst
new file mode 100644
index 0000000..34ce6c1
--- /dev/null
+++ b/doc/sphinx/lfun/SearchPath.rst
@@ -0,0 +1,109 @@
+SearchPath()
+============
+
+FUNKTION
+--------
+::
+
+     public int SearchPath(string from, string to, int para,
+                           closure callback)
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/pathd.c
+     <sys/path.d>
+
+ARGUMENTE
+---------
+::
+
+     from     - Der Startpunkt
+     to       - Der Endpunkt
+     para     - Die Parawelt in der gesucht wird (Normalwelt: 0)
+     callback - Closure, die am Ende der Pfadsuche gerufen wird
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion berechnet - sofern moeglich - den kuerzesten Pfad zwischen
+    <from> und <to> in der (Para-)Welt <para>.
+
+    
+
+    Die Pfadsuche wird anhand von Daten ueber von Spielern gelaufene Wege
+    durchgefuehrt. D.h. Gebiete, die von Spielern nicht (in letzter Zeit mal)
+    betreten werden, sind auch dem Pfaddaemon nicht bekannt. Auch kann es
+    Gebiete geben, wo zwar gebietsintern Pfade bekannt sind, aber keine Wege
+    in den Rest vom MG.
+
+    Da diese Suche im Allgemeinen SEHR aufwendig sein kann, wird sie meistens
+    nicht sofort fertig, sondern dauert eine Weile. Wenn sie fertig ist, wird
+    die Closure <callback> aufgerufen und ihr die Argumente <from>, <to>,
+    <parawelt>, <kosten>, <path> und <cmds> uebergeben. Die Bedeutung
+    dieser Argumente ist unten erklaert.
+
+    Eine Suche nach einem Pfad in einer Parawelt fuehrt durch Raeume der
+    gewuenschen Parawelt und durch Raeume der Normalwelt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1      - Suche wurde gestartet
+     2      - Pfad gefunden (und callback gerufen)
+    -1      - es laeuft schon ein Suchauftrage fuer die UID des anfragenden
+              Objektes
+    -2      - es laufen bereits zuviele Suchanfragen
+    -3      - <from> und/oder <to> sind nicht bekannt
+
+    
+
+    An <callback> uebergebene Argumente am Ende der Pfadsuche:
+        <from> - Startpunkt des Weges (string)
+        <to>   - Zielpunkt des Weges (string)
+        <para> - Parawelt des Weges (int)
+        <costs>- Kosten des Wege. (int) Je hoeher, desto
+                 laenger/unguenstiger. 0, wenn kein Pfad gefunden
+        <path> - Array mit Raumnamen, die durchlaufen werden (string*)
+                 0, wenn kein Pfad gefunden
+        <cmds> - Array mit Kommandos zum Ablaufen des Weges (string*)
+                 0, wenn kein Pfad gefunden
+
+BEMERKUNGEN
+-----------
+::
+
+   Es ist natuerlich nicht dazu gedacht, Spielern fertige Routen zwischen
+   Orten zu geben - bzw. nur in Ausnahmefaellen.
+   Pfadabfrgen werden geloggt.
+
+   Die Angabe <costs> sagt grob etwas ueber die Laenge und vor allem ueber die
+   "Qualitaet" des Pfades aus. Die steigt bei Paraweltwechseln, wenig
+   abgelaufenen Verbindungen zwischen Raeumen oder wenn eine Verbindung kein
+   normaler Ausgang ist.
+
+   Die Closure <callback> sollte nicht zuviele Ticks verbrauchen.
+
+BEISPIEL
+--------
+::
+
+   #include <pathd.h>
+   void suchergebnis(string from, string to, int para, int costs, string*
+        path, string* cmds) {
+        tell_object(find_player("zesstra"), sprintf(
+            "Ergebnis Pfadsuche von %s nach %s in Para %d fuer %d:\n %O\n %O\n",
+            from, to, para, costs, path, cmds));
+   };
+
+   ...
+   mixed res=PATHD->SearchPath("/gilden/abenteurer",
+                               "/d/ebene/dancer/lucky/room/pova_la3",
+                               0, #'suchergebnis);
+
+
+22.12.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/SelectEnemy.rst b/doc/sphinx/lfun/SelectEnemy.rst
new file mode 100644
index 0000000..1ce4167
--- /dev/null
+++ b/doc/sphinx/lfun/SelectEnemy.rst
@@ -0,0 +1,52 @@
+SelectEnemy()
+=============
+
+FUNKTION
+--------
+::
+
+	varargs object SelectEnemy(object*here);
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+	here
+	  Gegner, aus welchen ausgewaehlt werden soll (optional!)
+
+RUeCKGABEWERT
+-------------
+::
+
+	Ausgewaehlter Gegner, der angegriffen werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Funktion waehlt einen Gegner aus, der angegriffen werden soll.
+	Werden keine Gegner im Parameter <here> angegeben, so wird der
+	Rueckgabewert der Funktion PresentEnemies() verwandt, welche die
+	aktuell anwesenden Gegner im Raum liefert.
+	Sind keine Gegner anwesend, so wird 0 zurueckgeliefert.
+	Danach wird geschaut, ob Gegner bevorzugt ausgewaehlt werden sollen.
+	Dies geschieht mittels der Funktion QueryPreferedEnemy().
+	Auch dieser bevorzugte Gegner muss im selben Raum sein! Wenn nicht,
+	wird doch irgendein anderer Gegner ausgewaehlt und zurueckgegeben.
+
+SIEHE AUCH
+----------
+::
+
+	PresentEnemies(), QueryPreferedEnemy(), P_PREFERED_ENEMY,
+	InsertEnemy(), StopHuntFor()
+
+
+Last modified: Thu May 27 15:01:48 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/SelectFarEnemy.rst b/doc/sphinx/lfun/SelectFarEnemy.rst
new file mode 100644
index 0000000..9e2c5d9
--- /dev/null
+++ b/doc/sphinx/lfun/SelectFarEnemy.rst
@@ -0,0 +1,66 @@
+SelectFarEnemy()
+================
+
+FUNKTION
+--------
+::
+
+        varargs object SelectFarEnemy(object *here, int min, int max,
+                                      int forcefrom)
+
+DEFINIERT IN
+------------
+::
+
+        /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+        here       - Rueckgabewert von PresentEnemies()
+        min        - minimale Kampfreihe
+        max        - maximale Kampfreihe
+        forcefrom  - Gegner MUSS aus uebergebenem Array ausgewaehlt werden
+
+BESCHREIBUNG
+------------
+::
+
+        Waehlt einen Feind aus Reihe <min> bis <max> aus.
+
+RUECKGABEWERT
+-------------
+::
+
+        Der Auserwaehlte :-)
+
+BEMERKUNGEN
+-----------
+::
+
+        1. Wenn in den angegeben Reihen kein Feind ist oder <max> kleiner
+           als <min> ist, wird auch keiner zurueckgegeben.
+        2. Aus Effizienzgruenden sollte forcefrom nur benutzt werden, wenn
+           es wirklich noetig ist (s. hierzu auch SelectNearEnemy()).
+        3. 0 <= <min> <= <max> < MAX_TEAMROWS
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      AssocMember, DeAssocMember, InsertEnemyTeam,
+                    SelectNearEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/SelectNearEnemy.rst b/doc/sphinx/lfun/SelectNearEnemy.rst
new file mode 100644
index 0000000..32cab34
--- /dev/null
+++ b/doc/sphinx/lfun/SelectNearEnemy.rst
@@ -0,0 +1,70 @@
+SelectNearEnemy()
+=================
+
+FUNKTION
+--------
+::
+
+        varargs object SelectNearEnemy(object *here, int forcefrom)
+
+DEFINIERT IN
+------------
+::
+
+        /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+        here      - Rueckgabewert von PresentEnemies()
+        forcefrom - Gegner MUSS aus uebergebenem Array ausgewaehlt werden
+
+BESCHREIBUNG
+------------
+::
+
+        Waehlt einen im Nahkampf erreichbaren Feind aus
+
+RUECKGABEWERT
+-------------
+::
+
+        Der Auserwaehlte :-)
+
+BEMERKUNGEN
+-----------
+::
+
+        1. Falls der Spieler in einem Team ist und in einer hinteren Reihe
+           steht, wird kein Feind ausgewaehlt, es sei denn, der Spieler hat
+           einen Kampf mit einem Teammitglied angefangen.
+        2. Wenn ein bevorzugter Feind in einer der hinteren Reihen eines
+           Teams steht, wird solange das Team bevorzugt.
+        3. Auch Feinde in den hinteren Reihen koennen im Nahkampf erreichbar
+           sein, wenn die vorderen Reihen nicht genuegend Deckung bieten.
+        4. ACHTUNG: Der Auserwaehlte kommt nicht notwendigerweise aus dem
+           uebergebenen Array, wenn forcefrom=0 ist. Normalerweise ist dieses
+           Verhalten beabsichtigt, damit jemand, der sich in der Reihe vor
+           einen Gegner stellt, angegriffen wird, auch wenn er noch nicht
+           Feind ist.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      AssocMember, DeAssocMember, InsertEnemyTeam,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/Set.rst b/doc/sphinx/lfun/Set.rst
new file mode 100644
index 0000000..ffca76a
--- /dev/null
+++ b/doc/sphinx/lfun/Set.rst
@@ -0,0 +1,174 @@
+Set()
+=====
+
+FUNKTION
+--------
+::
+
+     public varargs mixed Set(string name, mixed Value, int Type, int extern);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/properties.c
+     /sys/thing/properties.h (Prototyp)
+
+ARGUMENTE
+---------
+::
+
+     name - Property, die manipuliert werden soll
+     Value - der zu setzende/aendernde Wert
+     Type - die Eigenschaft der Property, die manipuliert werden soll
+     extern - Interne Verwendung:
+    Wurde Set ueber SetProp von aussen gerufen.
+
+BESCHREIBUNG
+------------
+::
+
+     Eine der inneren Eigenschaften der Property 'name' wird veraendert.
+     'Type' ist dabei einer der in /sys/thing/properties.h definierten
+     F_XXX - Werte:
+
+     F_VALUE (==0, default)
+       Setzt den Inhalt der Property auf 'Value'. Aehnlich "SetProp",
+       umgeht jedoch eine etwaige F_SET_METHOD oder _set_'name'()-Methode.
+     F_MODE
+     F_MODE_AS
+     F_MODE_AD
+       Aendert eines der internen Flags der Property. F_MODE negiert den
+       vorherigen Wert vom Flag 'Value', F_MODE_AS setzt und F_MODE_AD
+       loescht ihn.
+       Verfuegbare interne Flags:
+
+         SAVE 
+
+           Property wird bei save_object() gespeichert
+
+         PROTECTED 
+
+           Flag setzbar durch:   beliebiges Objekt
+           Flag loeschbar durch: this_object(), ROOT, EM+
+           Inhalt der Property veraendern sowie Set- und Query-Methoden
+           setzen oder loeschen duerfen nur noch this_object(), ROOT, EM+
+           WARNUNG: Dieses Flag nicht leichtfertig bei Spielern setzen!
+
+         SECURED  
+
+           Flag setzbar durch:   this_object(), ROOT, EM+
+           Flag loeschbar durch: Niemanden!
+           Inhalt der Property veraendern sowie Set- und Query-Methoden
+           setzen oder loeschen duerfen nur noch this_object(), ROOT, EM+
+
+         NOSETMETHOD 
+
+           Property nicht mehr ueber SetProp() aenderbar
+           (damit entfallen auch SET_METHOD, _set_'name')
+     F_SET_METHOD
+       Aendert den Eintrag fuer eine SetMethod - eine Closure, die anstatt
+       des Setzens der Property beim Aufruf von SetProp mit 'Value'
+       aufgerufen wird.
+     F_QUERY_METHOD
+       Aendert den Eintrag fuer eine QueryMethod - eine Closure, die anstatt
+       des Lesens der Property beim Aufruf von QueryProp aufgerufen wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Das Ergebnis der Manipulation bzw. einer der definierten
+     Fehlercodes.
+
+BEMERKUNGEN
+-----------
+::
+
+     - Set() sollte nicht zum regulaeren Manipulieren des Inhalts einer
+       Property verwendet werden, da sowohl F_SET_METHOD als auch libinterne
+       _set_'name'()-Methoden umgangen werden und das Ergebnis fuer so
+       veraenderte Properties undefiniert ist.
+     - eine gesetzte F_SET/F_QUERY_METHOD hat bei SetProp/QueryProp Vorrang
+       vor einer _set/_query_method
+       -> _set/_query wird nach erfolgreichem Ruf von F_XXX_METHOD ignoriert
+     - F_SET/F_QUERY_METHOD sollte normalerweise Vorzug vor einer
+       _set_/_query_* gegeben werden.
+
+    SetMethods/QueryMethods:
+     - falls ihr Query/SetMethods an oeffentlichen Properties setzen
+       wollt, prueft bitte vorher, ob dort nicht schon eine (fremde) gesetzt
+       ist und brecht ggf. euer Set() ab, um nicht die Arbeit anderer
+       Mitmagier zu sabotieren (z.B. P_HANDS)
+     - Properties sollten mit Query- oder SetMethoden nur so lange wie
+       noetig belegt werden
+       -> manche Properties sollte man als Wert setzen, _auch wenn_ die
+          Spieler sie zuruecksetzen koennten (zB P_MSGIN/P_MSGOUT)
+     - auf keinen Fall den Wert speichern, ueberschreiben, rueckschreiben,
+       das fuehrt fast immer zu Problemen.
+     - Set/QueryMethoden sollten nicht als Trigger/Listener fuer ein
+       Ereignis (z.B. P_DIE_MSG fuer das Ereignis "Tod des Spielers")
+       missbraucht werden
+       -> es gibt sichere und saubere Moeglichkeiten (NotifyPlayerDeath),
+          und wenn nicht, wendet euch an den EM eures Vertrauens
+     - F_SET/F_QUERY_METHODs koennen 'protected' (empfohlen) oder 'static'
+       sein. _set_/_query_ duerfen momentan _nicht_ 'protected' sein, fuer
+       geht nur 'static' (in diesem Fall empfohlen).
+
+BEISPIELE
+---------
+::
+
+     ### Aendern von Eigenschaften einer Property ###
+     // Setzen des SAVE-Flags (bei save_object() mitzuspeichern)
+     Set(P_XYZ, SAVE, F_MODE_AS);
+
+     // Loeschen des SAVE-Flags
+     Set(P_XYZ, SAVE, F_MODE_AD);
+
+     
+
+     // Negieren des bisherigen SAVE-Flags
+     Set(P_XYZ, SAVE, F_MODE);
+     // Hinweis: das Setzen des Flags funktioniert mittels F_MODE nur dann,
+     // wenn sichergestellt ist, dass es vorher nicht gesetzt war. Die 
+     // sichere Variante ist daher, F_MODE_AS zu verwenden.
+
+     // Sperren des SetProp/SET_METHOD-Zugriffs:
+     Set(P_XYZ, NOSETMETHOD, F_MODE_AS);
+
+     // Vorlaeufiger Zugriffsschutz fuer eine Property:
+     Set(P_XYZ, PROTECTED, F_MODE_AS);
+
+     // Permanenter Zugriffsschutz fuer eine Property:
+     Set(P_XYZ, SECURED, F_MODE_AS);
+
+     ### Setzen einer SetMethod/QueryMethod ###
+     // Setzen einer internen SetMethod
+     mixed foo(mixed val);
+     ...
+     Set(P_XYZ, #'foo, F_SET_METHOD);
+     ...
+
+     // Setzen einer QueryMethod bei einem anderen Objekt
+     mixed bar();
+     ...
+     other->Set(P_XYZ, #'bar, F_QUERY_METHOD);
+     ...
+
+     // Der Vollstaendigkeit halber sei das Aendern einer Property unter
+     // Umgehung von Set-Methoden angegeben. Es ist aber aus o.g. Gruenden
+     // zu empfehlen, diese Variante nicht zu verwenden.
+     Set(P_XYZ, "bla", F_VALUE);
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: SetProp(L), QueryProp(L), Query(L)
+     Generell:  SetProperties(L), QueryProperties(L)
+     Konzept:  properties, /std/thing/properties.c
+     Sonstiges:  P_AUTOLOADOBJ
+
+06. Jan 2008 Arathorn
+
diff --git a/doc/sphinx/lfun/SetAttackChats.rst b/doc/sphinx/lfun/SetAttackChats.rst
new file mode 100644
index 0000000..dbfee76
--- /dev/null
+++ b/doc/sphinx/lfun/SetAttackChats.rst
@@ -0,0 +1,108 @@
+SetAttackChats()
+================
+
+FUNKTION
+--------
+::
+
+     void SetAttackChats(int chance, mixed strs);
+
+DEFINIERT IN
+------------
+::
+
+     /std/npc/chat.c
+
+ARGUMENTE
+---------
+::
+
+     chance
+          Prozentuale Wahrscheinlichkeit einer Ausgabe
+     strs
+          Stringarray mit den Monsterchats
+
+BESCHREIBUNG
+------------
+::
+
+     Der NPC gibt mit der Wahrscheinlichkeit 'chance' einen zufaellig
+     gewaehlten Text aus 'strs' von sich. Die Arrayelemente koennen 
+     auch Funktionen ("@@func@@") oder Closures enthalten, die dann
+     aufgerufen werden und deren Rueckgabewerte das Monster dann ausgibt.
+
+RUECKGABEWERT
+-------------
+::
+
+     keiner
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     AttackChats werden nur im Kampf ausgegeben. Ansonsten ist SetChats()
+     zu verwenden.
+
+     
+
+     'chance' wird in der Property P_ACHAT_CHANCE abgelegt. Um einen NPC
+     voruebergehend 'stillzulegen', kann man P_ACHAT_CHANCE auf 0 setzen.
+
+     
+
+     Man kann AttackChats nutzen, um Monsterspells zu realisieren. Besser
+     ist es aber, dafuer 'AddSpell' zu verwenden.
+
+     
+
+BEISPIELE
+---------
+::
+
+     SetAttackChats( 20,
+       ({ "Der Ork tritt Dir in den Hintern.\n",
+          "Der Ork bruellt: Lebend kommst Du hier nicht raus!\n",
+          "Der Ork blutet schon aus mehreren Wunden.\n",
+          "@@knirsch@@" }) );
+
+          
+
+     string knirsch()
+     {
+       object *ruestung, *tmp, helm;
+
+       
+
+       ruestung = this_player()->QueryProp(P_ARMOURS); // getragene Ruestung
+       tmp = filter_objects(ruestung, "id", AT_HELMET);
+       // Wenn der Spieler einen Helm traegt, enthaelt 'tmp' jetzt
+       // ein Array mit dem Helmobjekt als einzigem Element
+       if (sizeof(tmp)) helm = tmp[0];
+	 if (objectp(helm))
+	 {
+	   // AC nur dann senken, wenn sie nicht schon 0 ist.
+	   if (helm->QueryProp(P_AC)>0) {
+	     helm->Damage(1);
+	     return "Der Ork beschaedigt Deinen Helm!\n";
+	   }
+	   return "";
+	 }
+	 else
+	   return ""; // keine Meldung
+     }
+
+SIEHE AUCH
+----------
+::
+
+     P_ACHAT_CHANCE, SetChats(), /std/npc/chat.c, AddSpell()
+
+LETZTE AENDERUNG
+----------------
+::
+
+	Don, 27.12.2007, 16:35:00 von Arathorn
+
diff --git a/doc/sphinx/lfun/SetAttr.rst b/doc/sphinx/lfun/SetAttr.rst
new file mode 100644
index 0000000..7866e7c
--- /dev/null
+++ b/doc/sphinx/lfun/SetAttr.rst
@@ -0,0 +1,55 @@
+SetAttr()
+=========
+
+FUNKTION
+--------
+::
+
+     public int SetAttr(string attr, int val)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+     attr       - zu setzendes Attribut
+     val        - Wert
+
+BESCHREIBUNG
+------------
+::
+
+     Filtert den Wert durch _filterattr(). Dadurch werden STR, INT, CON, DEX
+     auf 20 begrenzt. Setzt dann das Attribut.
+     Offsets werden hier nicht beruecksichtigt, QueryAttribute() gibt also
+     val + etwaige Offsets/Modifier zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Tatsaechlich gesetzter Wert.
+
+BEMERKUNGEN
+-----------
+::
+
+     Wird von SetAttribute() und SetRealAttribute() aufgerufen.
+
+SIEHE AUCH
+----------
+::
+
+     QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+     SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+     TestAttributeLock(),
+     P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
+     P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/SetAttribute.rst b/doc/sphinx/lfun/SetAttribute.rst
new file mode 100644
index 0000000..bb52498
--- /dev/null
+++ b/doc/sphinx/lfun/SetAttribute.rst
@@ -0,0 +1,49 @@
+SetAttribute()
+==============
+
+FUNKTION
+--------
+::
+
+     int SetAttribute(string attr, int val)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+     attr       - zu setzendes Attribut
+     val        - Wert
+
+BESCHREIBUNG
+------------
+::
+
+     Nimm val als Gesamtwert des Attributes, d.h. zieht etwaige Offsets vor
+     Setzen ab. (QueryAttribute gibt dann also val zurueck)
+
+RUeCKGABEWERT
+-------------
+::
+
+     Den durch SetAttr gefilterten gesetzten Wert.
+     Bitte nicht auf Spieler anwenden!
+
+SIEHE AUCH
+----------
+::
+
+	QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+	SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+	SetTimedAttrModifier(), QueryTimedAttrModifier(), 
+	DeleteTimedAttrModifier(),
+	P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+	P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/SetBuyFact.rst b/doc/sphinx/lfun/SetBuyFact.rst
new file mode 100644
index 0000000..edf2d9e
--- /dev/null
+++ b/doc/sphinx/lfun/SetBuyFact.rst
@@ -0,0 +1,59 @@
+SetBuyFact()
+============
+
+FUNKTION
+--------
+::
+
+     void SetBuyFact(int fact);
+
+DEFINIERT IN
+------------
+::
+
+     /std/laden.c
+
+ARGUMENTE
+---------
+::
+
+     fact
+          Der Einkaufspreismultiplikator.
+
+BESCHREIBUNG
+------------
+::
+
+     Der Preis, der beim Kauf eines Objekts im Laden zu entrichten ist,
+     errechnet sich aus seinem Wert ( P_VALUE), multipliziert mit dem Faktor
+     fact. Dieser Preis ist konstant und nicht von der aktuellen Marktlage
+     abhaengig.
+
+     Der Defaultwert ist 3. Ein hoeherer Wert entspricht einem teuren Laden,
+     waehrend ein kleinerer Wert zu kleinen Preisen fuehrt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Normalerweise kommt man ohne diese Funktion aus: in teuren Laeden wird
+     nicht viel eingekauft (es sei denn, es liegen standardmaessig gute
+     Objekte im Speicher), einem Billigladen wird bald das Geld ausgehen mit
+     der Folge, dass der Ladenbesitzer nichts mehr ankaufen kann und sein
+     Lager gaehnend leer ist.
+
+SIEHE AUCH
+----------
+::
+
+     QueryBuyFact(), /std/laden.c
+
+
+Last modified: Wed May 8 10:24:52 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/SetChats.rst b/doc/sphinx/lfun/SetChats.rst
new file mode 100644
index 0000000..e14669c
--- /dev/null
+++ b/doc/sphinx/lfun/SetChats.rst
@@ -0,0 +1,95 @@
+SetChats()
+==========
+
+FUNKTION
+--------
+::
+
+	void SetChats(int chance,mixed strs);
+
+DEFINIERT IN
+------------
+::
+
+	/std/npc/chat.c
+
+ARGUMENTE
+---------
+::
+
+	chance
+	  Prozentuale Wahrscheinlichkeit einer Ausgabe
+	strs
+	  Stringarray mit den Monsterchats
+
+BESCHREIBUNG
+------------
+::
+
+	Der NPC gibt mit der Wahrscheinlichkeit <chance> pro Heartbeat einen
+	zufaellig gewaehlten Text aus dem Array <strs> von sich.
+	Die Arrayelemente koennen auch Closures oder
+	process_string()-Funktionen ("@@func@@") enthalten, die dann
+	aufgerufen werden und deren Rueckgabewerte das Monster dann ausgibt.
+	 (Fuer keine Ausgabe dann Leerstring "" zurueckgeben!)
+	In diesen Funktionen ist this_player() das Monster selbst!
+	Fuer Zeilenumbrueche ist immer selbst zu sorgen.
+
+RUECKGABEWERT
+-------------
+::
+
+	keiner
+
+BEISPIELE
+---------
+::
+
+	Ein einfaches Beispiel:
+	  // Prototype fuer Closure.
+	  static string info1();
+	  void create()
+	  { ...
+	    SetChats(20,
+	   ({"Der Ork sagt: Hau ab, bevor ich Dich fresse.\n",
+	     "Der Ork grinst Dich unverschaemt an.\n",
+	     "Der Ork wedelt mit seinem Saebel vor Deinem Gesicht herum.\n",
+	     "Der Ork droht Dir mit der Faust.\n",
+             #'info1,
+	     "@@info2@@"}));
+          }
+	  // Funktion als Closure. Prototype notwendig!
+	  static string info1()
+	  { if(QueryProp(P_HP)<QueryProp(P_ALIGN))
+	      return"Gleich werde ich von hier fliehen!\n";
+	    return"";
+	  }
+	  // Funktion als process_string().
+	  string info2()
+	  { return QueryProp(P_HP)==QueryProp(P_MAX_HP)?
+	 "Der Ork grinst: Mir geht es fantastisch!\n":
+	 "Der Ork seufzt: Mir ging es wirklich schon mal besser.\n";
+	  }
+
+BEMERKUNGEN
+-----------
+::
+
+	Im Kampf werden keine Chats ausgegeben. Es ist dann SetAttackChats()
+	zu verwenden.
+	Funktionen als process_string() sollte man nicht mehr verwenden.
+	<chance> wird in der Property P_CHAT_CHANCE abgelegt. Um einen NPC
+	voruebergehend 'stillzulegen', kann man P_CHAT_CHANCE auf 0 setzen.
+  Wenn kein Spieler anwesend ist, haben NPC in der Regel keinen Heartbeat,
+  weswegen dann auch die Chats ausgeschaltet sind.
+  Spieler koennen NPC 'stillen', d.h. Chats und AttackChats abschalten.
+
+SIEHE AUCH
+----------
+::
+
+	P_CHAT_CHANCE, SetAttackChats(), process_string()
+
+
+Last modified: Sat Jan 18 18:48:06 2003 by Patryn
+
diff --git a/doc/sphinx/lfun/SetCoinsPerUnits.rst b/doc/sphinx/lfun/SetCoinsPerUnits.rst
new file mode 100644
index 0000000..5930204
--- /dev/null
+++ b/doc/sphinx/lfun/SetCoinsPerUnits.rst
@@ -0,0 +1,64 @@
+SetCoinsPerUnits()
+==================
+
+FUNKTION
+--------
+::
+
+     void SetCoinsPerUnits(int coins, int units);
+
+DEFINIERT IN
+------------
+::
+
+     /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+     coins
+          Zahl der Muenzen
+     units
+          Zahl der Einheiten
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird festgelegt, wieviel eine bestimmte Menge der Einheiten kostet.
+     Eine einzelne Einheit kostet coins/units Muenzen.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Bei der Preisberechnung wird abgerundet. Hat man also ein Verhaeltnis
+     von einer Muenze pro zwei Einheiten, so ist der Preis einer einzelnen
+     Einheit 0!
+
+BEISPIELE
+---------
+::
+
+     Eine Einheit soll 3.5 Muenzen wert sein:
+
+     /* 7 Muenzen / 2 Einheiten = 3.5 Muenzen / Einheit */
+     SetCoinsPerUnits(7,2);
+
+SIEHE AUCH
+----------
+::
+
+     QueryCoinsPerUnits(), SetGramsPerUnits(), QueryGramsPerUnits(),
+     /std/unit.c
+
+
+Last modified: Wed May 8 10:24:57 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/SetDoorStatus.rst b/doc/sphinx/lfun/SetDoorStatus.rst
new file mode 100644
index 0000000..c5b9545
--- /dev/null
+++ b/doc/sphinx/lfun/SetDoorStatus.rst
@@ -0,0 +1,50 @@
+SetDoorStatus()
+===============
+
+FUNKTION
+--------
+::
+
+     void SetDoorStatus(string dest, int status);
+
+DEFINIERT IN
+------------
+::
+
+     /obj/doormaster.c
+
+ARGUMENTE
+---------
+::
+
+     <dest>   = Zielraum der Tuer.
+     <status> = Der neue Zustand der Tuer.
+
+BESCHREIBUNG
+------------
+::
+
+     Der Zustand der Tuer, die von diesem Raum nach <dest> fuehrt, wird auf
+     <status> geaendert. Hierbei muss <status> einer der drei folgenden Werte
+     aus <doorroom.h> sein:
+
+       D_STATUS_LOCKED - Tuer abgeschlossen
+       D_STATUS_CLOSED - Tuer geschlossen
+       D_STATUS_OPEN   - Tuer geoeffnet
+
+RUECKGABEWERT
+-------------
+::
+
+     keiner
+
+SIEHE AUCH
+----------
+::
+
+    NewDoor(), QueryDoorKey(), QueryDoorStatus(), P_DOOR_INFOS,
+    /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+
+
+Letzte Aenderung: Don, 08.05.2014, Gabylon
+
diff --git a/doc/sphinx/lfun/SetEnemies.rst b/doc/sphinx/lfun/SetEnemies.rst
new file mode 100644
index 0000000..685d08f
--- /dev/null
+++ b/doc/sphinx/lfun/SetEnemies.rst
@@ -0,0 +1,53 @@
+SetEnemies()
+============
+
+FUNKTION
+--------
+::
+
+     mapping SetEnemies(object *myenemies);
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+     myenemies
+	  Array: ({Gegnerarray, Zeitenarray})
+
+RUeCKGABEWERT
+-------------
+::
+
+     Internes Mapping mit bekannten Gegnern und Zeiten.
+
+BESCHREIBUNG
+------------
+::
+
+     Normalerweise fuegt man einzelne Gegner mittels InsertEnemy() ein und
+     loescht alte Feinde mittels StopHuntFor().
+
+     Um jedoch mit einem Schlag viele Veraenderungen vorzunehmen, kann man
+     die Funktion SetEnemies() nutzen.
+
+     Ihr uebergibt man ein Array mit einem Array mit den gewuenschten Gegnern
+     als und einem zweiten, gleichgrossen Array mit den Zeiten, wie lange
+     diese Gegner aktuell sein sollen, als Eintraege.
+
+     Die Funktion traegt diese Werte als Gegner mit entsprechender
+     Feindeszeit ein.
+
+SIEHE AUCH
+----------
+::
+
+     InsertEnemy(), StopHuntFor(), SelectEnemy(), PresentEnemies()
+
+10.Feb 2005 Gloinson
+
diff --git a/doc/sphinx/lfun/SetGramsPerUnits.rst b/doc/sphinx/lfun/SetGramsPerUnits.rst
new file mode 100644
index 0000000..10eac24
--- /dev/null
+++ b/doc/sphinx/lfun/SetGramsPerUnits.rst
@@ -0,0 +1,55 @@
+SetGramsPerUnits()
+==================
+
+FUNKTION
+--------
+::
+
+     void SetGramsPerUnits(int grams, int units);
+
+DEFINIERT IN
+------------
+::
+
+     /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+     grams
+          Gewicht in Gramm
+     units
+          Zahl der Einheiten
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird festgelegt, wieviel eine bestimmte Menge der Einheiten wiegt.
+     Eine einzelne Einheit wiegt grams/units Gramm.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEISPIELE
+---------
+::
+
+     Vier Einheiten sollen 3 Gramm wiegen:
+
+     SetGramsPerUnits(3,4);
+
+SIEHE AUCH
+----------
+::
+
+     SetCoinsPerUnits(), QueryCoinsPerUnits(), QueryGramsPerUnits(),
+     /std/unit.c
+
+
+Last modified: Wed May 8 10:25:09 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/SetProp.rst b/doc/sphinx/lfun/SetProp.rst
new file mode 100644
index 0000000..32883b3
--- /dev/null
+++ b/doc/sphinx/lfun/SetProp.rst
@@ -0,0 +1,70 @@
+SetProp()
+=========
+
+FUNKTION
+--------
+::
+
+     public mixed SetProp(string name, mixed Value);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/properties.c
+     /sys/thing/properties.h (Prototyp)
+
+ARGUMENTE
+---------
+::
+
+     name	- Property, deren Wert veraendert werden soll.
+     Value	- Wert, auf den der Inhalt der Property gesetzt werden soll
+
+BESCHREIBUNG
+------------
+::
+
+     Der Datenwert der Property 'name' wird auf den Wert 'Value' gesetzt.
+
+     Existiert eine F_SET_METHOD oder eine _set_'name'()-Methode fuer
+     diese Property, so wird diese aufgerufen und ihr 'Value' uebergeben.
+     Eine F_SET_METHOD hat dabei Vorrang vor _set_'name'(), d.h.
+     _set_'name'() wird nach erfolgreicher F_QUERY_METHOD nicht mehr
+     gerufen.
+
+     (Diese Methoden nutzen dann Set(), um den Datenwert der Property
+      'name' zu aendern. Teilweise werden aber auch interne Variablen so
+      oeffentlich gemacht und sind nicht in der ueber Set/Query verfuegbaren
+      Property 'name' abgelegt.)
+
+RUeCKGABEWERT
+-------------
+::
+
+     Der Wert, der nun in der Property gespeichert ist.
+     In der Regel ist das 'Value'. Wenn die Property ueber eine SET_METHOD
+     oder eine _set_'name'()-Funktion verfuegt und diese 'Value' aendert
+     (zum Beispiel, indem sie 'Value' an einen bestimmten erlaubten
+     Wertebereich anpasst), kann der Rueckgabewert jedoch auch veraendert
+     sein.
+
+     Wenn die Property nicht veraendert werden darf, wird -1 zurueckgegeben.
+
+BEISPIELE
+---------
+::
+
+     // geben wir dem Zwerg eine Kurzbeschreibung
+     SetProp(P_SHORT, "Ein kleiner Zwerg");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	QueryProp(L), Set(L), Query(L)
+     Generell:		SetProperties(L), QueryProperties(L)
+     Konzept:		properties, /std/thing/properties.c
+
+15.Dez 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/SetProperties.rst b/doc/sphinx/lfun/SetProperties.rst
new file mode 100644
index 0000000..3595aaf
--- /dev/null
+++ b/doc/sphinx/lfun/SetProperties.rst
@@ -0,0 +1,48 @@
+SetProperties()
+===============
+
+FUNKTION
+--------
+::
+
+     void SetProperties(mapping props);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/properties.c
+
+ARGUMENTE
+---------
+::
+
+     props	- Mapping mit den Daten fuer alle Properties
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion setzt angegebene Properties auf einen Schlag.
+     Mapping muss wie folgt aufgebaut sein:
+	([ name: wert; flags; set_method; query_method,
+	   name2: ... ]);
+
+BEMERKUNGEN
+-----------
+::
+
+     - diese Funktion wird von restore_object() verwendet, um nicht alle
+       restaurierten Properties einzeln setzen zu muessen.
+     - SECURED/PROTECTED/NOSETMETHOD Properties werden beruecksichtigt
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	SetProp(L), QueryProp(L), Set(L), Query(L)
+     Generell:		QueryProperties(L)
+     Konzept:		properties, /std/thing/properties.c
+
+1.Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/SetRealAttribute.rst b/doc/sphinx/lfun/SetRealAttribute.rst
new file mode 100644
index 0000000..849d697
--- /dev/null
+++ b/doc/sphinx/lfun/SetRealAttribute.rst
@@ -0,0 +1,55 @@
+SetRealAttribute()
+==================
+
+FUNKTION
+--------
+::
+
+     int SetRealAttribute(string attr, int val)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+     attr       - zu setzendes Attribut
+     val        - Wert
+
+BESCHREIBUNG
+------------
+::
+
+     Setzt den realen Wert des Attributes, d.h. das reine Attribut,
+     wenn moeglich. Lediglich eine Alias-Methode fuer SetAttr().
+     (QueryAttribute() gibt also val + etwaige Offsets/Modifier zurueck)
+
+RUeCKGABEWERT
+-------------
+::
+
+     Den gesetzten Wert.
+
+BEMERKUNGEN
+-----------
+::
+
+     Bitte nicht auf Spieler anwenden!
+
+SIEHE AUCH
+----------
+::
+
+	QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+	SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+	SetTimedAttrModifier(), QueryTimedAttrModifier(), 
+	DeleteTimedAttrModifier(),
+	P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+	P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/SetSpellFatigue.rst b/doc/sphinx/lfun/SetSpellFatigue.rst
new file mode 100644
index 0000000..16b5a6f
--- /dev/null
+++ b/doc/sphinx/lfun/SetSpellFatigue.rst
@@ -0,0 +1,100 @@
+SetSpellFatigue()
+=================
+
+FUNKTION
+--------
+::
+
+    public varargs int SetSpellFatigue(int duration, string key)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skills.c
+    /std/player/skills.c
+    /sys/living/skills.h
+
+ARGUMENTE
+---------
+::
+
+    int duration: Wie lang soll die Spruchermuedung andauern?
+    string key  : Eindeutiger Name des Spruches, einer Gruppe von Spruechen
+                  oder 0 fuer die globale Spruchermuedung.
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion dient zum Verwalten von individuellen Spruchermuedungen
+    (Spellfatigue, Spruchsperren).
+    Hiermit lassen sich unabhaengige Ermuedungen/Sperren fuer einzelne
+    Sprueche oder Gruppen von Spruechen gestalten.
+
+    <duration> ist die Zeit (in Sekunden), welche die Spruchermuedung
+    anhalten soll (nicht die Endzeit).
+
+    Wird <key> nicht angegeben oder ist 0, wird die globale Spruchsperre
+    gesetzt (identisch zu der Property P_NEXT_SPELL_TIME), anderenfalls die
+    unter <key> gespeicherte Spruchermuedung.
+    Setzt man einen Eintrag ohne Angabe von <key> bedeutet dies damit auch,
+    dass der Wert von P_NEXT_SPELL_TIME geaendert wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+    -1    Der Eintrag <key> ist noch nicht abgelaufen, es wurde _keine_
+          neue Spruchermuedung/-Sperre gespeichert.
+
+    >0    Eintrag wurde gespeichert, Rueckgabewert ist die Zeit, zu der die
+          Sperre ablaeuft.
+
+BEISPIELE
+---------
+::
+
+    Ein Spell gehoert zu einer Gruppe von Spells mit dem Namen 'extrasuess'.
+    Er darf nur ausgefuehrt werden, wenn seit 5s kein anderer Spruch aus der
+    Gruppe ausgefuehrt wurde.
+    if (CalculateSpellSuccess(...) > x) {
+      // Spellfatigue setzen (und Erfolg pruefen!)
+      if (ob->SetSpellFatigue(5, "extrasuess") > -1) {
+        tell_object(ob, "Du fuetterst " + enemy->Name(WEN) + " mit einem "
+          "Stueck suesser Schokotorte.\n");
+        ...
+      }
+      else {
+        // Sauerei! Zu ermuedet fuer diesen Spruch. Fehlermdeldung ...
+      }
+    }
+    Dieses setzt natuerlich voraus, dass alle anderen Sprueche der Gruppe
+    "extrasuess" den gleichen <key> pruefen und setzen.
+    (Will man vor CalculateSpellSuccess() wissen, ob der Spruch ueberhaupt
+     gewirkt werden duerfte, sollte man hierzu dann CheckSpellFatigue()
+     verwenden.)
+
+BEMERKUNGEN
+-----------
+::
+
+    Die genauen Zeitdauern koennen von Spielern beeinflusst werden, sie
+    unterliegen der jeweiligen Einstellung von 'spruchermuedung', d.h. koennen
+    auf volle 2s aufgerundet werden. (Dies ist nicht der Fall bei NPC.)
+    Auch wenn diese Funktion zum Verwalten von beliebigen Zeitsperren genutzt
+    werden koennen, beschraenkt euch bitte auf Spruchermuedungen und benutzt
+    ansonsten check_and_update_timed_key(). Falls ihr diesbzgl. weitere/andere
+    Wuensche habt, sprecht den/die Mudlib-EM an.
+
+SIEHE AUCH
+----------
+::
+
+    CheckSpellFatigue(L), DeleteSpellFatigue(L)
+    P_NEXT_SPELL_TIME
+    spruchermuedung
+
+
+27.03.2010, Zesstra
+
diff --git a/doc/sphinx/lfun/SetStorageRoom.rst b/doc/sphinx/lfun/SetStorageRoom.rst
new file mode 100644
index 0000000..fa1b2b0
--- /dev/null
+++ b/doc/sphinx/lfun/SetStorageRoom.rst
@@ -0,0 +1,109 @@
+SetStorageRoom()
+================
+
+FUNKTION
+--------
+::
+
+        void SetStorageRoom(string store);
+
+DEFINIERT IN
+------------
+::
+
+        /std/room/shop.c
+
+ARGUMENTE
+---------
+::
+
+        store
+          Dateiname des Lagers, in dem die aufgekauften Objekte aufbewahrt
+          werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+        keiner
+
+BESCHREIBUNG
+------------
+::
+
+        Mit dieser Funktion wird dem Laden bekannt gegeben, welches Objekt
+        als Lager fuer angekaufte Objekte dienen soll. Jeder Laden muss
+        explizit einen eigenen Lagerraum setzen, ansonsten wird ein 
+        Laufzeitfehler ausgeloest und der Laden ist nicht ladbar.
+
+        
+
+        Das Speicherobjekt sollte /std/store.c erben, da dort einige
+        Aufraeumfunktionen definiert sind. Entscheidend fuer selbige sind
+        die Properties P_MIN_STOCK und P_STORE_CONSUME.
+
+BEISPIELE
+---------
+::
+
+        Der Raum 'myladen.c' koennte etwa so aussehen:
+
+          
+
+          // myladen.c
+          inherit "/std/shop";
+          #include <properties.h>
+
+          
+
+          protected void create() {
+            ::create();
+            SetProp(...); // Beschreibung wie bei normalen Raeumen
+            SetStorageRoom("/d/beispiel/mystore");
+            AddFixedObject("/items/fackel");
+          }
+
+        In diesem Laden wird nun die Standardfackel als mengenmaessig 
+        unbegrenzter Artikel verkauft.
+
+        Der zugehoerige Lagerraum 'mystore.c' kann dann im einfachsten Fall
+        so aussehen:
+
+          
+
+          // mystore.c
+          inherit "/std/store";
+          #include <rooms.h>  // Fuer AddItem-Konstanten
+
+          
+
+          protected void create() {
+            ::create();
+            // KEINE weiteren Beschreibungen!
+            // 1. erbt der Speicher keine Beschreibungsmodule,
+            // 2. sollen da eh nur Sachen und keine Spieler rein!
+            AddItem("/items/schaufel", REFRESH_REMOVE);
+          }
+
+        
+
+        Der Laden verkauft nun auch Schaufeln, jedoch nur eine pro Reset.
+
+HINWEISE:        
+        Fuer standardmaessig verkaufte Waren beachte man den Unterschied 
+        zwischen den Funktionen AddItem() und AddFixedObject().
+        Die erstgenannte Funktion ist im Lager zu verwenden, letztere jedoch
+        im Laden.
+
+SIEHE AUCH
+----------
+::
+
+        Allgemeines:  laden
+        Funktionen:   AddItem(L), AddFixedObject(L), RemoveFixedObject(L) 
+        Basisobjekte: /std/store.c
+        Properties:   P_MIN_STOCK, P_STORE_CONSUME
+
+
+Last modified: 19-Jun-2015, Arathorn
+
diff --git a/doc/sphinx/lfun/SetTimedAttrModifier.rst b/doc/sphinx/lfun/SetTimedAttrModifier.rst
new file mode 100644
index 0000000..17b2d9f
--- /dev/null
+++ b/doc/sphinx/lfun/SetTimedAttrModifier.rst
@@ -0,0 +1,114 @@
+SetTimedAttrModifier()
+======================
+
+FUNKTION
+--------
+::
+
+     int SetTimedAttrModifier(string key, mapping modifier, 
+                              int outdated, object dependent, mixed notify) 
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+     key	-	in P_TIMED_ATTR_MOD vorzunehmender oder zu 
+                        aendernder Eintrag
+     modifier   -       Mapping mit den Attributveraenderungen
+     outdated   -       Zeitpunkt zu dem die Attributveraenderungen
+                        ablaufen sollen in Sekunden seit dem
+                        1. Jan 1970, 0.0:0 GMT oder 0
+     dependent  -       Objekt dessen Existenz eine Bedingung fuer die
+                        Attributveraenderung sein soll oder 0
+     notify     -       Objekt oder File das mittels 
+                        NotifyTimedAttrModExpired ueber
+                        den Attributablauf informiert werden soll
+
+BESCHREIBUNG
+------------
+::
+
+     Der zu key gehoerende Eintrag wird in P_TIMED_ATTR_MOD angelegt oder
+     modifiziert und update_max_sp_and_hp aufgerufen.
+     Es empfiehlt sich auf die Eindeutigkeit des string-Parameters key
+     besonderes Augenmerk zu legen.
+
+     Unter dem Key key wird in P_TIMED_ATTR_MOD ein Eintrag vorgenommen,
+     welcher die Attribute des Livings um die in modifier stehenden Offsets
+     veraendert.
+
+     Diese Veraenderung ist solange aktiv bis entweder die in outdated
+     stehende Zeit ueberschritten ist oder das in dependent uebergebene
+     Objekt nicht mehr existiert.
+     Sind beide Argumente 0 so laeuft die Attributveraenderung nicht ab
+     und kann durch DeleteTimedAttrModifier geloescht werden.
+     Laeuft die Attributveraenderung ab, so wird der in notify angegebene
+     Empfaenger mittels Aufruf NotifyTimedAttrModExpired davon 
+     benachrichtigt.
+     Der Funktion NotifyTimedAttrModExpired wird als Argument der key
+     der abgelaufenen Attributveraenderung uebergeben.
+
+BEISPIELE
+---------
+::
+
+     Ein NPC kann einen Spieler auf die folgende Weise solange die
+     Attribute um eins herabsetzen bis entweder eine Stunde verstrichen
+     ist oder der NPC nicht mehr existiert zum Beispiel weil er getoetet
+     wurde.
+
+       player->SetTimedAttrModifier( player->query_real_name(),
+                                     ([A_STR:-1,A_INT:-1,A_DEX:-1,A_CON:-1]),
+                                     time()+3600,
+                                     this_object(),
+                                     this_object()
+                                   );
+
+     Will der NPC nun noch darauf reagieren, dass die Attributmodifikation
+     durch Timeout abgelaufen ist, so koennte dies folgendermassen geschehen.
+
+       void NotifyTimedAttrModExpired(string str)
+       {
+           // Die Funktion wird aus dem Lebewesen gerufen, in welchem der Mod
+           // gerade abgelaufen ist. Also Meldungsausgabe an
+           // previous_object().
+           tell_object(previous_object()
+               ,"Da hast Du aber nochmal Glueck gehabt.\n");
+       }
+
+RUeCKGABEWERT
+-------------
+::
+
+     TATTR_INVALID_ARGS      -     Im Falle eines fehlenden key-Arguments,
+                                   eines fehlenden modifier-Arguments oder
+                                   eines bereits abgelaufenen
+                                   outdatet-Arguments
+     TATTR_OK                -     Im Erfolgsfall
+
+     Die Rueckgabewerte sind in /sys/living/attributes.h definiert.
+
+SIEHE AUCH
+----------
+::
+
+     Attribute:  QueryAttribute(), SetAttribute()
+                 SetRealAttribute(), QueryRealAttribute(),
+                 QueryAttributeOffset(),
+                 UpdateAttributes()
+     Methoden:   QueryTimedAttrModifier(), DeleteTimedAttrModifier()
+     Callback:   NotifyTimedAttrModExpired()
+     Properties: P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS
+		 P_X_ATTR_MOD, P_M_ATTR_MOD
+		 P_TIMED_ATTR_MOD
+     Sonstiges:  /std/living/attributes.c
+
+LETZTE Aenderung:
+15.02.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/ShowDoors.rst b/doc/sphinx/lfun/ShowDoors.rst
new file mode 100644
index 0000000..c674397
--- /dev/null
+++ b/doc/sphinx/lfun/ShowDoors.rst
@@ -0,0 +1,46 @@
+ShowDoors()
+===========
+
+FUNKTION
+--------
+::
+
+	void ShowDoors()
+
+ARGUMENTE
+---------
+::
+
+	Keine.
+
+BESCHREIBUNG
+------------
+::
+
+	Zeigt alle Sehertor an, die der Seher (this_player()) schon kennt.
+	Falls in seiner Umgebung ein Tor steht, so wird dieses eingeklammert.
+
+RUECKGABEWERT
+-------------
+::
+
+	Keiner.
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
+
+BEISPIELE
+---------
+::
+
+    /d/seher/portale/sehertormaster->ShowDoors()
+
+SIEHE AUCH
+----------
+::
+
+    DiscoverDoor, DoorIsKnown, Teleport, GetDoorsMapping
+
diff --git a/doc/sphinx/lfun/ShowPropList.rst b/doc/sphinx/lfun/ShowPropList.rst
new file mode 100644
index 0000000..40a1df3
--- /dev/null
+++ b/doc/sphinx/lfun/ShowPropList.rst
@@ -0,0 +1,75 @@
+ShowPropList()
+==============
+
+FUNKTION
+--------
+::
+
+     void ShowPropList(string *props);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/util.c
+
+ARGUMENTE
+---------
+::
+
+     props
+          Array von Strings mit den Namen der Properties, die ausgegeben
+          werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt die Inhalte der in props angegebenen Properties aus.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEISPIELE
+---------
+::
+
+     Sei test.c folgendes Programm:
+
+     inherit "std/thing";
+     inherit "std/thing/util";
+
+     create() {
+       ::create();
+
+       SetProp(P_SHORT, "Kurz");
+       SetProp(P_NAME, ({ "Name", "Namens", "Namen", "Namen" }));
+       SetProp("me", this_object() );
+     }
+
+     Mit xcall test->ShowPropList( ({ P_SHORT, P_NAME, "me" }) ); erhielte
+     man dann folgende Ausgabe:
+
+     *short: "Kurz"
+     *name: ({ "Name", "Namens", "Namen", "Namen" })
+     *me: OBJ(/players/wargon/test#12345)
+
+BEMERKUNGEN
+-----------
+::
+
+     Mit dem Befehl xprops des MGtools lassen sich uebrigens saemtliche
+     Properties eines Objekte auf einen Schlag ausgeben.
+
+SIEHE AUCH
+----------
+::
+
+     /std/ting/util.c
+
+
+Last modified: Wed May 8 10:25:26 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/SkillResTransfer.rst b/doc/sphinx/lfun/SkillResTransfer.rst
new file mode 100644
index 0000000..47dd28b
--- /dev/null
+++ b/doc/sphinx/lfun/SkillResTransfer.rst
@@ -0,0 +1,48 @@
+SkillResTransfer()
+==================
+
+FUNKTION
+--------
+::
+
+     protected void SkillResTransfer(mapping from_M, mapping to_M)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/skill_utils
+
+ARGUMENTE
+---------
+::
+
+     mapping from_M: Mapping mit zu kopierenden Werten
+     mapping to_M:   Zielmapping
+
+BESCHREIBUNG
+------------
+::
+
+     Interne Methode, die zB (!) waehrend der Ausfuehrung von Attack() durch
+     Skills oder P_TMP_ATTACK_MOD geaenderte Werte selektiert in das
+     Hauptangriffsmapping uebertraegt.
+
+     Derzeit werden folgende Werte kopiert:
+     SI_SKILLDAMAGE, SI_SKILLDAMAGE_MSG, SI_SKILLDAMAGE_MSG2,
+     SI_SKILLDAMAGE_TYPE, SI_SPELL
+
+BEMERKUNGEN
+-----------
+::
+
+     * wird an mehreren Stellen, nicht nur der living/combat verwendet
+
+SIEHE AUCH
+----------
+::
+
+     P_TMP_ATTACK_MOD, UseSkill (Waffenfaehigkeiten)
+
+18.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/lfun/SpellAttack.rst b/doc/sphinx/lfun/SpellAttack.rst
new file mode 100644
index 0000000..1a3fe70
--- /dev/null
+++ b/doc/sphinx/lfun/SpellAttack.rst
@@ -0,0 +1,97 @@
+SpellAttack()
+=============
+
+FUNKTION
+--------
+::
+
+        void SpellAttack(object enemy)
+
+ARGUMENTE
+---------
+::
+
+        enemy: Der Feind.
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion wird in jedem Heartbeat eines NPCs ausgefuehrt,
+        falls nicht P_DISABLE_ATTACK gesetzt ist (Paralyse).
+        Standardmaessig tut diese Funktion nichts, aber man kann sie
+        ueberschreiben, damit in jedem Heartbeat Angriffe mit Spells
+        ausgefuehrt werden.
+
+        Man sollte hierbei ein random() einbauen, damit der NPC nicht
+        in jedem Heartbeat auch wirklich einen Angriff ausfuehrt.
+        Ausserdem sollte man auch fuer eventuelle Ausgaben sorgen.
+
+RUECKGABEWERT
+-------------
+::
+
+        Keiner.
+
+BEMERKUNG
+---------
+::
+
+        Die AttackChats, die mittels SetAttackChats gesetzt werden
+        koennen, macht im Grunde nichts anderes, aber Chats sind halt
+        keine Angriffe. :-)
+
+BEISPIELE
+---------
+::
+
+        Im Grunde ist dieses simple Beispiel eine Nachbildung von
+        Attack-Chats und soll dementsprechend nur der Anschauung dienen.
+
+        void SpellAttack(object enemy) 
+        {
+          // mit 80% Wahrscheinlichkeit wird nichts gemacht.
+          switch(random(5))
+          {
+            case 0: 
+              write("Der Ork tritt Dir in den Hintern.\n");
+              return;
+            case 1: 
+              write("Der Ork bruellt: Lebend kommst Du hier nicht raus!\n");
+              return;
+            case 2:
+              write("Der Ork blutet schon aus mehreren Wunden.\n");
+              return;
+            case 3:
+              write(knirsch(enemy));
+              return;
+            default:
+              return;
+          }
+        }
+
+        string knirsch(object enemy)
+        {
+           if (objectp(enemy))
+             helm = enemy->QueryArmourByType(AT_HELMET);
+           if (objectp(helm))
+           {
+             helm->Damage(1);
+             return "Der Ork beschaedigt Deinen Helm!\n";
+           }
+           else
+             return ""; // keine Meldung
+        }
+
+SIEHE AUCH
+----------
+::
+
+        "Attack", "SetAttackChats", /std/npc/combat.c
+
+LETZTE AENDERUNG
+----------------
+::
+
+ Don, 27.02.2003, 12:50:00 von Hirudo
+
diff --git a/doc/sphinx/lfun/SpellDefend.rst b/doc/sphinx/lfun/SpellDefend.rst
new file mode 100644
index 0000000..8d2c140
--- /dev/null
+++ b/doc/sphinx/lfun/SpellDefend.rst
@@ -0,0 +1,71 @@
+SpellDefend()
+=============
+
+FUNKTION
+--------
+::
+
+     public int SpellDefend(object caster,mapping sinfo);
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+     object caster	- Gegner
+     mapping sinfo	- Zusatzinformationen zum Spell
+
+BESCHREIBUNG
+------------
+::
+
+     Ueber den Skill SK_SPELL_DEFEND mit den Aufrufparametern
+       SI_ENEMY    : <caster>
+     und
+       SI_SKILLARG : <sinfo>
+     wird eine Abwehrchance in 0.01%-Schritten fuer einen
+     Spell ermittelt, also 0% - 100% bzw. als Rueckgabewert
+     0 - 10000.
+
+     
+
+     Weiterhin wird automatisch P_MAGIC_RESISTANCE_OFFSET und der Skill
+     SK_SPELL_DEFEND beruecksichtigt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Die Abwehrchance in 0.01%-Schritten.
+
+     
+
+     Fuer Spieler wird dieser Rueckgabewert auf 3333 maximal, also 33,33%
+     Abwehrmoeglichkeit beschraenkt.
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Spellbooks muessen selbst auf die Auswertung dieser Funktion
+     achten! Dies geschieht nur im Falle von TryGlobalAttackSpell()
+     und bei Spells fuer NPCs mittels P_SPELLS automatisch!
+
+     Bitte bei NPCs nicht pauschal 100% / 10000 zurueckgeben. Danke.
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt:     P_MAGIC_RESISTANCE_OFFSET
+     Aehnlich:     P_NOMAGIC
+     Generell:     TryGlobalAttackSpell, /std/spellbook.c
+     Sonstiges:    UseSkill, SK_SPELL_DEFEND
+
+29.Dez 2007 Gloinson
+
diff --git a/doc/sphinx/lfun/SpellInform.rst b/doc/sphinx/lfun/SpellInform.rst
new file mode 100644
index 0000000..ac6afdf
--- /dev/null
+++ b/doc/sphinx/lfun/SpellInform.rst
@@ -0,0 +1,52 @@
+SpellInform()
+=============
+
+FUNKTION
+--------
+::
+
+        void SpellInform(caster,spell,sinfo);
+
+DEFINIERT IN
+------------
+::
+
+        selber zu definieren
+
+ARGUMENTE
+---------
+::
+
+        pl
+          Das Lebewesen, das erfolgreich gezaubert hat.
+        spell
+          Der Name des gezauberten Spells
+        sinfo
+          Das komplette Spellmapping des gezauberten Spells
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion wird vom Spellbuch einer Gilde in der Umgebung
+        (Environment) eines Lebewesens aufgerufen, wenn immer das Lebewesen
+        einen Spell _erfolgreich_ gezaubert hat.
+        Bemerkung: Bitte vermeiden, aufwaendige Sachen in der Funktion zu
+        machen, da sonst u.U. deswegen Gilden anfangen zu buggen. Falls es
+        sein muss, macht dann lieber einen call_out mit 2s Wartezeit.
+
+RUeCKGABEWERT
+-------------
+::
+
+        keiner
+
+SIEHE AUCH
+----------
+::
+
+        
+
+----------------------------------------------------------------------------
+16.04.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/Start.rst b/doc/sphinx/lfun/Start.rst
new file mode 100644
index 0000000..d041e15
--- /dev/null
+++ b/doc/sphinx/lfun/Start.rst
@@ -0,0 +1,45 @@
+Start()
+=======
+
+FUNKTION
+--------
+::
+
+     varargs void Start(int pos);
+
+DEFINIERT IN
+------------
+::
+
+     /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+     pos
+          Fahrplanstation, an der begonnen werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion schickt den Transporter auf die Strecke. Dabei beginnt
+     der Weg an der mit pos bezeichneten Stelle im Fahrplan. Default ist 0,
+     d.h. der Transporter beginnt seinen Weg an der ersten Fahrplanposition.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+SIEHE AUCH
+----------
+::
+
+     Halt(), /std/transport.c
+
+
+Last modified: Wed May 8 10:25:30 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/StopHuntFor.rst b/doc/sphinx/lfun/StopHuntFor.rst
new file mode 100644
index 0000000..eb6300b
--- /dev/null
+++ b/doc/sphinx/lfun/StopHuntFor.rst
@@ -0,0 +1,78 @@
+StopHuntFor()
+=============
+
+FUNKTION
+--------
+::
+
+  varargs int StopHuntFor(object arg,int silent);
+
+DEFINIERT IN
+------------
+::
+
+  /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+  arg
+    Der Gegner, welcher nicht mehr bekaempft werden soll.
+  silent
+    Flag, welches gesetzt anzeigt, dass die beiden Ex-Streithaehne
+    ueber das einseitige Friedensangebot nicht informiert werden
+    sollen.
+
+RUeCKGABEWERT
+-------------
+::
+
+  Flag: Bei 0 war der Gegner nicht auffindbar, bei 1 Erfolg.
+
+BESCHREIBUNG
+------------
+::
+
+  Mit dieser Funktion kann man ein Lebewesen <arg> als Gegner
+  austragen. Im Normalfall erhalten sowohl das aktuelle Objekt, als
+  auch der Gegner eine Information darueber. Dies kann jedoch mit dem
+  gesetzten Flag <silent> unterbunden werden.
+  Es ist auch moeglich, auf diese Meldung Einfluss zu nehmen, indem
+  man die Funktion StopHuntText() ueberschreibt, welche dafuer
+  verantwortlich ist.
+  Achtung: Um zwischen beiden Streithaehnen Frieden zu schliessen,
+  muss der eine Gegner jeweils bei dem anderen ausgetragen werden. Ein
+  einzelnes StopHuntFor() ist sozusagen nur ein einseitiges
+  Friedensangebot.
+
+BEMERKUNGEN
+-----------
+::
+
+  Soll ein Viech unter bestimmten Umstaenden nicht angreifbar sein, ist in
+  keinem Fall StopHuntFor() im Defend() zu verwenden, sondern P_NO_ATTACK.
+  Grund: Stoppt man unliebsame Kaempfe jeweils am Anfang vom Defend, kann ein
+  Gegner gefahrlos Angriffsspells ausfuehren (und ueben), ohne dass die Gefahr
+  besteht, dass der NPC zurueckschlaegt.
+
+BEISPIELE
+---------
+::
+
+  Man will aus irgendeinem Grund den Kampf zwischen sich und Gegner enemy
+  einstellen:
+  ...
+  StopHuntFor(enemy); // enemy nicht mehr bekaempfen
+  enemy->StopHuntFor(this_object()); // enemy soll mich nicht bekaempfen.
+  ...
+
+SIEHE AUCH
+----------
+::
+
+  StopHuntText(), SelectEnemy(), QueryEnemies(), IsEnemy()
+
+
+16.03.2008, Zesstra 
+
diff --git a/doc/sphinx/lfun/StopHuntText.rst b/doc/sphinx/lfun/StopHuntText.rst
new file mode 100644
index 0000000..400f960
--- /dev/null
+++ b/doc/sphinx/lfun/StopHuntText.rst
@@ -0,0 +1,78 @@
+StopHuntText()
+==============
+
+FUNKTION
+--------
+::
+
+	void StopHuntText(object arg);
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+	arg
+	  Der Gegner, welcher nicht mehr bekaempft wird.
+
+BESCHREIBUNG
+------------
+::
+
+	Mit der Funktion StopHuntFor() kann man ein Lebewesen als Gegner
+	austragen. Dabei erhalten sowohl der Gegner, als auch das Lebewesen,
+	welches (einseitig!) Frieden schliesst, jeweils eine Meldung, sofern
+	man dies nicht mittels eines Flags unterbindet.
+	Es ist nun moeglich, auf diese Meldung Einfluss zu nehmen, indem
+	man die Funktion StopHuntText() ueberschreibt, welche dafuer
+	verantwortlich ist.
+
+BEISPIEL
+--------
+::
+
+	Ein Lebewesen moechte einen Kampf sofort abbrechen, wenn es von
+	einem Frosch angegriffen wird:
+	  int Defend(int dam,mixed dam_type,mixed spell,object enemy)
+	  { if(enemy&&enemy->QueryProp(P_FROG))
+	    { if(StopHuntFor(enemy))
+              { // wenn Frosch angreifen will, der noch kein Gegner war
+                tell_object(arg,
+         this_object()->Name(WER)+" kaempft nicht mit Dir.\n"
+	+"Wahrscheinlich werden Froesche verschont.\n");
+	        tell_object(this_object(),
+	 "Der bloede Frosch wollte Dich doch tatsaechlich angreifen.\n");
+              }
+	      enemy->StopHuntFor(this_object(),1);
+              return 0;
+            }
+	    return::Defend(dam,dam_type,spell,enemy);
+	  }
+	  // wird nur aufgerufen, wenn der Gegner irgendwann Frosch wurde
+	  void StopHuntText(object arg)
+	  { tell_object(arg,
+	 this_object()->Name(WER)+" jagd Dich nicht mehr.\n"
+	+"Wahrscheinlich werden Froesche verschont.\n");
+	    tell_object(this_object(),
+	"Dein Gegner ist doch tatsaechlich ploetzlich Frosch geworden!\n");
+	  }
+	Warum braucht man nun das erste StopHuntFor(), wenn doch Gegner erst
+	in ::Defend() eingetragen werden, welches doch gar nicht ausgefuehrt
+	wird, wenn der Gegner ein Frosch ist? Man beachte hierbei, dass der
+	Gegner ja auch waehrend des Kampfes oder waehrend der Feindschaft
+	irgendwann Frosch werden koennte und dann schon Gegner war.
+
+SIEHE AUCH
+----------
+::
+
+	StopHuntFor(), SelectEnemy(), QueryEnemies(), IsEnemy()
+
+
+Last modified: Wed May 26 16:47:51 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/SuggestArticle.rst b/doc/sphinx/lfun/SuggestArticle.rst
new file mode 100644
index 0000000..fb72447
--- /dev/null
+++ b/doc/sphinx/lfun/SuggestArticle.rst
@@ -0,0 +1,58 @@
+SuggestArticle()
+================
+
+FUNKTION
+--------
+::
+
+     varargs int SuggestArticle(string name);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+     name
+          Der Name zur Entscheidungshilfe.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion versucht herauszufinden, ob der Artikel zu diesem Objekt
+     ein unbestimmter oder besser ein bestimmter Artikel sein sollte. Die
+     Vorgehensweise ist folgende: Gibt es in der Umgebung dieses Objektes
+     ein weiteres Objekt, das den Namen name besitzt, so wird ein
+     unbestimmter Artikel vorgeschlagen, ansonsten ein bestimmter.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn ein unbestimmter Artikel geeignet ist, ansonsten 1.
+
+BEMERKUNGEN
+-----------
+::
+
+     Der Vergleich erfolgt mittels der Property P_NAME. Um Erfolg zu haben,
+     sollte man diese Funktion daher in der Form
+
+     SuggestArticle(QueryProp(P_NAME))
+
+     aufrufen.
+
+SIEHE AUCH
+----------
+::
+
+     QueryArticle(), name(), /std/thing/language.c
+
+
+Last modified: Wed May 8 10:25:34 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/SwapRows.rst b/doc/sphinx/lfun/SwapRows.rst
new file mode 100644
index 0000000..93f27b4
--- /dev/null
+++ b/doc/sphinx/lfun/SwapRows.rst
@@ -0,0 +1,61 @@
+SwapRows()
+==========
+
+FUNKTION
+--------
+::
+
+    int SwapRows( object ob1, object ob2 )
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+    ob1, ob2 - Spieler, die die Reihen tauschen sollen.
+
+BESCHREIBUNG
+------------
+::
+
+    Die angegebenen Spieler tauschen die Reihen.
+
+RUECKGABEWERT
+-------------
+::
+
+    1 bei erfolgreichem Tausch, 0 sonst.
+
+BEMERKUNG
+---------
+::
+
+    Der Tausch wird nur durchgefuehrt, wenn die angegebenen Spieler auch
+    tatsaechlich im Team sind und damit kein NPC vor einen Spieler gestellt
+    wuerde.
+    Moechte man wissen, ob ein Spieler eine Reihe gewechselt hat, muss man
+    sich der Hilfe eines Hooks bedienen: H_HOOK_TEAMROWCHANGE
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_TEAM_LEADER, P_TEAM_ASSOC_MEMBERS,
+                    P_TEAM_NEWMEMBER
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      AssocMember, DeAssocMember, InsertEnemyTeam
+                    SelectNearEnemy, SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/TakeFlaw.rst b/doc/sphinx/lfun/TakeFlaw.rst
new file mode 100644
index 0000000..2ab1916
--- /dev/null
+++ b/doc/sphinx/lfun/TakeFlaw.rst
@@ -0,0 +1,101 @@
+TakeFlaw()
+==========
+
+FUNKTION
+--------
+::
+
+     varargs void TakeFlaw(object enemy); (Waffen)
+     varargs void TakeFlaw(mixed dam_types,mapping einfos) (Ruestungen)
+
+DEFINIERT IN
+------------
+::
+
+     /std/armour/combat.c,
+     /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird in Waffen und Ruestungen waehrend des Kampfes
+     aufgerufen. In einer Waffe erfolgt der Aufruf bei jedem Schlag mit
+     dieser Waffe, bei Ruestungen wird TakeFlaw() in einer zufaellig
+     ausgewaehlten getragenen Ruestung aufgerufen.
+     Waffen bekommen das Gegnerobjekt uebergeben, Ruestungen die erweiterten
+     DefendInfos (s. dort fuer Details). Aufgrund dieser Informationen kann
+     man den Schaden, den ein Gegenstand nimmt, flexibler gestalten (z.B. bei
+     einer Waffe in Abhaengigkeit von P_BODY des Gegners.)
+
+     Soweit man die Funktion nicht ueberlaedt, bewirkt sie nichts weiter als
+     das Erhoehen eines Zaehlers, der mit QueryFlaw() abgefragt werden kann.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Waffen-/ Ruestungsklasse wird nicht automatisch reduziert! Wenn
+     eine Waffe oder Ruestung sich abnutzen soll, muss man TakeFlaw()
+     ueberladen und dort entsprechend handeln, oder (fuer einfache
+     Faelle) die Property P_QUALITY setzen.
+
+BEISPIELE
+---------
+::
+
+     Eine Waffe, deren Waffenklasse alle 20 Schlaege um 1 abnimmt:
+
+     inherit "std/weapon";
+
+     #include <properties.h>
+     #include <combat.h>
+
+     create()
+     {
+       /* Das Uebliche... */
+     }
+
+     TakeFlaw()
+     {
+       int flaw;
+
+       /* erst mal den Zaehler erhoehen... */
+       ::TakeFlaw();
+
+       /* jetzt den aktuellen Zaehlerstand abfragen */
+       flaw = QueryFlaw()[0];
+
+       /* Abzug nur jeden 20. Schlag */
+       if (!(flaw % 20)) {
+         /* So, jetzt fuer den Schaden sorgen. Hierfuer benutzt */
+         /* man am sichersten die eingebaute Funktion Damage() */
+         Damage(1);
+       }
+     }
+
+     Dieses einfache Beispiel haette natuerlich auch ueber ein
+     SetProp(P_QUALITY,20); im create() realisiert werden koennen.
+
+SIEHE AUCH
+----------
+::
+
+     QueryFlaw(), Damage(), DefendInfo, P_QUIALITY, /std/armour/combat.c,
+     /std/weapon/combat.c
+
+
+Last modified: Thu May 22 10:30:10 1997 by Paracelsus
+
diff --git a/doc/sphinx/lfun/TeamFlee.rst b/doc/sphinx/lfun/TeamFlee.rst
new file mode 100644
index 0000000..4146462
--- /dev/null
+++ b/doc/sphinx/lfun/TeamFlee.rst
@@ -0,0 +1,61 @@
+TeamFlee()
+==========
+
+FUNKTION
+--------
+::
+
+        int TeamFlee()
+
+DEFINIERT IN
+------------
+::
+
+        /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+        keine
+
+BESCHREIBUNG
+------------
+::
+
+        Spieler wird zur Flucht in hintere Reihe veranlasst, falls er dies
+        eingestellt hat.
+
+RUECKGABEWERT
+-------------
+::
+
+        1, falls der Spieler in eine hintere Reihe fliehen wollte und nach
+        dem Versuch nicht mehr in der ersten Reihe steht, sonst 0.
+
+BEMERKUNGEN
+-----------
+::
+
+        Beim Teamleiter fuehrt der Fluchtversuch dazu, dass sein Team nicht
+        mehr folgt.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      AssocMember, DeAssocMember, InsertEnemyTeam,
+                    SelectNearEnemy, SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/TeamMembers.rst b/doc/sphinx/lfun/TeamMembers.rst
new file mode 100644
index 0000000..055604d
--- /dev/null
+++ b/doc/sphinx/lfun/TeamMembers.rst
@@ -0,0 +1,59 @@
+TeamMembers()
+=============
+
+FUNKTION
+--------
+::
+
+        object *TeamMembers()
+
+DEFINIERT IN
+------------
+::
+
+        /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+        keine
+
+BESCHREIBUNG
+------------
+::
+
+        Liefert Teammitglieder des Teams des Spielers.
+
+RUECKGABEWERT
+-------------
+::
+
+        Array mit ALLEN Teammitgliedern.
+
+BEMERKUNGEN
+-----------
+::
+
+        Falls der Spieler in keinem Team ist, enthaelt das Array nur den
+        Spieler.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader
+        Kampf:      AssocMember, DeAssocMember, InsertEnemyTeam,
+                    SelectNearEnemy, SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/TeamPrefix.rst b/doc/sphinx/lfun/TeamPrefix.rst
new file mode 100644
index 0000000..ab73ae9
--- /dev/null
+++ b/doc/sphinx/lfun/TeamPrefix.rst
@@ -0,0 +1,57 @@
+TeamPrefix()
+============
+
+FUNKTION
+--------
+::
+
+        string TeamPrefix()
+
+DEFINIERT IN
+------------
+::
+
+        /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+        keine
+
+BESCHREIBUNG
+------------
+::
+
+        Ergibt Team-Prefix eines Spielers.
+
+RUECKGABEWERT
+-------------
+::
+
+        "[Team Teamname] ", falls der Spieler in einem Team ist,
+        ""                  sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      AssocMember, DeAssocMember, InsertEnemyTeam,
+                    SelectNearEnemy, SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/Teleport.rst b/doc/sphinx/lfun/Teleport.rst
new file mode 100644
index 0000000..9c4cbf4
--- /dev/null
+++ b/doc/sphinx/lfun/Teleport.rst
@@ -0,0 +1,51 @@
+Teleport()
+==========
+
+FUNKTION
+--------
+::
+
+    int Teleport(string ziel)
+
+ARGUMENTE
+---------
+::
+
+    ziel: Nummer des Sehertors, zu dem teleportiert werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+    Teleportiert den Seher (this_player()) zu dem Tor mit der angegebenen
+    Nummer. Falls keine Nummer angegeben wird, wird mit ShowDoors() die
+    Liste der bekannten Tore angezeigt und auf die Eingabe einer Nummer
+    gewartet.
+
+RUECKGABEWERT
+-------------
+::
+
+    0, falls der Seher nicht neben einem Tor steht, dass er kennt.
+    1  sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+    Der Seher muss in einem Raum stehen, in dem sich ein Sehertor befindet,
+    dass er kennt. Der Seher muss auch das angegebene Ziel kennen.
+    Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
+
+BEISPIELE
+---------
+::
+
+    /d/seher/portale/sehertormaster->Teleport(1)
+
+SIEHE AUCH
+----------
+::
+
+    DiscoverDoor, DoorIsKnown, ShowDoors, GetDoorsMapping
+
diff --git a/doc/sphinx/lfun/TestIgnore.rst b/doc/sphinx/lfun/TestIgnore.rst
new file mode 100644
index 0000000..7c77dbb
--- /dev/null
+++ b/doc/sphinx/lfun/TestIgnore.rst
@@ -0,0 +1,88 @@
+TestIgnore()
+============
+
+FUNKTION
+--------
+::
+
+     public int TestIgnore(string|string* arg)
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/comm.c
+
+ARGUMENTE
+---------
+::
+
+     arg
+         String oder Array von Strings, die getestet werden sollen,
+         Format jeweils: [spieler].aktion[.qualifizierer]
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn arg nicht ignoriert wird
+     MSG_IGNORED, wenn (min. ein Element von) arg ignoriert wird
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird geprueft, ob der Spieler irgendeinen Eintrag auf seiner Liste
+     hat, der dazu fuehrt, dass <arg> ignoriert wird. Hierbei kommen je nach
+     den Angaben in <arg> folgende Regeln zum Tragen:
+     1) spieler
+        Wird der Spieler ignoriert?
+     2) .aktion
+        Ignoriert der Spieler .aktion, d.h. die Aktion komplett (OHNE
+        Qualifizierer)?
+     3) spieler.aktion
+        Ignoriert der Spieler spieler, .aktion oder spieler.aktion?
+     4) spieler.aktion.qualifizierer
+        Ignoriert der Spieler spieler, .aktion, spieler.aktion oder
+        spieler.aktion.qualifizierer?
+     5) .aktion.qualifizierer
+        Ignoriert der Spieler .aktion oder .aktion.qualifizierer?
+
+     Da TestIgnore() damit durchaus etwas aufwendiger sein kann, sollte
+     man dies nicht unnoetig oft aufrufen. (Braucht man das Ergebnis z.B.
+     kurz spaeter nochmal, koennte man das Ergebnis speichern.) Wird der
+     Qualifizierer nicht gebraucht, sollte man ihn weglassen.
+
+BEISPIEL
+--------
+::
+
+     if (!this_player()->TestIgnore("andy"))
+       tell_object(this_player(), "Andy teilt Dir mit: Hallo!\n");
+
+     // Beispiel fuer eine Ignore-Check fuer Aktion (kratzen) fuer einen
+     // Spieler (this_player()) an einem anderen Spieler (target)
+     if (!target->TestIgnore( ({getuid(this_player()) + ".kratze",
+                                   getuid(this_player()) + ".kratz"}) ))
+     {
+       tell_object(target, this_player()->Name()+" kratzt dich.\n");
+       tell_object(this_player(), "Du kratzt "+target->Name()+".\n");
+     }
+     else
+       tell_object(this_player(), target->Name()+" ignoriert dich.\n");
+
+     // allumfassender Ignorier-Check in einer Gilde (Klerus) auf
+     // eine Aktion (kurieren) fuer einen bestimmten Spieler (den caster)
+     // an einem zu kurierenden Spieler (target)
+     if (target->TestIgnore(getuid(caster)+".kuriere.klerus"))
+       tell_object(caster, break_string(
+         target->Name()+" ignoriert deinen Versuch.", 78));
+
+SIEHE AUCH
+----------
+::
+
+     P_IGNORE, AddIgnore, RemoveIgnore, TestIgnoreSimple, /std/player/comm.c
+
+26.04.2014 Zesstra
+
diff --git a/doc/sphinx/lfun/TestIgnoreSimple.rst b/doc/sphinx/lfun/TestIgnoreSimple.rst
new file mode 100644
index 0000000..2082c30
--- /dev/null
+++ b/doc/sphinx/lfun/TestIgnoreSimple.rst
@@ -0,0 +1,77 @@
+TestIgnoreSimple()
+==================
+
+FUNKTION
+--------
+::
+
+     public int TestIgnoreSimple(string *arg)
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/comm.c
+
+ARGUMENTE
+---------
+::
+
+     arg
+         Liste von Strings, die getestet werden sollen
+
+BESCHREIBUNG
+------------
+::
+
+     TestIgnoreSimple() prueft, ob der Spieler min. einen der uebergebenen
+     Eintraege auf seiner Ignoriereliste hat.
+     Falls man mehrere Eintraege pruefen muss/moechte, ist es schneller, alle
+     Eintraege in einem zu uebergeben anstatt fuer jeden einzeln 
+     TestIgnoreSimple() aufzurufen.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, falls es mindestens eine Uebereinstimmungen von arg und der
+     Ignoriere-Liste des Spielers gibt.
+     0, sonst.
+
+BEISPIEL
+--------
+::
+
+     if (!this_player()->TestIgnoreSimple(({"andy"})))
+       tell_object(this_player(), "Andy teilt Dir mit: Hallo!\n");
+
+     // Beispiel fuer eine Ignore-Check fuer Aktion (kratzen) fuer einen
+     // Spieler (this_player()) an einem anderen Spieler (target)
+     if (!target->TestIgnoreSimple(getuid(this_player()),
+                             getuid(this_player())+".kratz",
+                             getuid(this_player())+".kratze",
+                             ".kratz", ".kratze"}))) {
+       tell_object(target, this_player()->Name()+" kratzt dich.\n");
+       tell_object(this_player(), "Du kratzt "+target->Name()+".\n");
+     } else
+       tell_object(this_player(), target->Name()+" ignoriert dich.\n");
+
+     // allumfassender Ignorier-Check in einer Gilde (Klerus) auf
+     // eine Aktion (kurieren) fuer einen bestimmten Spieler (den caster)
+     // an einem zu kurierenden Spieler (target)
+     if (target->TestIgnoreSimple(({getuid(caster),
+                              getuid(caster)+".kuriere",
+                              getuid(caster)+".kuriere.klerus",
+                              ".kuriere",
+                              ".kuriere.klerus"})))
+       tell_object(caster, break_string(
+         target->Name()+" ignoriert deinen Versuch.", 78));
+
+SIEHE AUCH
+----------
+::
+
+     P_IGNORE, AddIgnore, RemoveIgnore, TestIgnore, /std/player/comm.c
+
+26.04.2014 Zesstra
+
diff --git a/doc/sphinx/lfun/TestLimitViolation.rst b/doc/sphinx/lfun/TestLimitViolation.rst
new file mode 100644
index 0000000..874dd83
--- /dev/null
+++ b/doc/sphinx/lfun/TestLimitViolation.rst
@@ -0,0 +1,41 @@
+TestLimitViolation()
+====================
+
+FUNKTION
+--------
+::
+
+      status TestLimitViolation(mapping check)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/attributes.c
+
+PARAMETER
+---------
+::
+
+     check	- Mapping mit Attributen: ([<attr>:<wert>])
+
+BESCHREIBUNG
+------------
+::
+
+     Prueft, ob die Summe der in check enthaltenen Modifikatoren die Summe
+     aller Modifikatoren im Spieler ueber den zugelassenen Grenzwert hebt.
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+     SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+     P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
+     P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+13.Jun.2004, Muadib
+
diff --git a/doc/sphinx/lfun/TriggerEvent.rst b/doc/sphinx/lfun/TriggerEvent.rst
new file mode 100644
index 0000000..2e8e09e
--- /dev/null
+++ b/doc/sphinx/lfun/TriggerEvent.rst
@@ -0,0 +1,88 @@
+TriggerEvent()
+==============
+
+FUNKTION
+--------
+::
+
+     varargs int TriggerEvent(string eid, mixed data);
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/eventd.c
+
+DEKLARIERT IN
+-------------
+::
+
+     /sys/events.h
+
+ARGUMENTE
+---------
+::
+
+     string eid,
+       Die ID des Events, der ausgeloest werden soll.
+       Da dieser String fuer alle Events jeweils eindeutig sein muss, 
+       empfiehlt es sich, fuer eigene Events z.B. als Praefix den eigenen 
+       Magiernamen zu nehmen, z.B. "zesstra_vulkanausbruch".
+       ACHTUNG: IDs, die mit 'evt_lib_' beginnen, sind AUSSCHLIESSLICH der
+       Mudlib vorbehalten!
+
+     mixed data,
+       Daten, die jeder Lauscher uebergeben bekommt. Kann ein beliebiger
+       Datentyp sein. Ggf. ein Mapping oder Array benutzen.
+
+BESCHREIBUNG
+------------
+::
+
+     Der Event mit der ID 'eid' wird ausgeloest. Mit kurzer Verzoegerung
+     (meist 0-2s) werden alle fuer 'eid' registrierten Lauscher durch Aufruf
+     einer Funktion in ihnen informiert:
+     listener->fun(eid, triggerob, data);
+     'triggerob' ist hierbei das Objekt, welche TriggerEvent() gerufen hat,
+     'data' das, was das triggernde Objekte als Daten weiterverteilen moechte.
+     Die einzelnen fun() in den lauschenden Objekten muessen wissen, was sie
+     mit 'data' anfangen sollen. ;-)
+
+RUeCKGABEWERT
+-------------
+::
+
+     1 fuer Erfolg, <=0 fuer Misserfolg.
+     1   - Erfolg, Event 'eid' wurde ausgeloest.
+     -1  - falsche Argumente wurden uebergeben
+     -2  - nicht-oeffentlicher Event und das triggernde Objekt wurde nicht
+           fuer diesen Event freigegeben (momentan gibt es noch keine
+           nicht-oeffentlichen Events)
+     -3  - Event 'eid' existiert nicht, d.h. es gibt keine Lauscher.
+     -4  - Es gibt zuviele nicht verarbeitete Events.
+
+BEMERKUNGEN
+-----------
+::
+
+BEISPIELE
+---------
+::
+
+     1. Ein Waechter wird angegriffen:
+        EVENTD->TriggerEvent("xand_holzfaellerlager_angriff", 
+                             (["angreifer": enemy,
+                               "ort": environment(this_object()) ]) );
+        Alle anderen angemeldeten Waechter der Lagers werden nun informiert
+        und koennen ihrerseits reagieren (dem ersten Waechter zuhilfe kommen
+        oder auch die Lagertore schliessen).
+
+SIEHE AUCH
+----------
+::
+
+     events, eventd, UnregisterEvent(), RegisterEvent()
+
+
+Last modified: 15.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/UnregisterEvent.rst b/doc/sphinx/lfun/UnregisterEvent.rst
new file mode 100644
index 0000000..d694d9d
--- /dev/null
+++ b/doc/sphinx/lfun/UnregisterEvent.rst
@@ -0,0 +1,82 @@
+UnregisterEvent()
+=================
+
+FUNKTION
+--------
+::
+
+     int UnregisterEvent(string eid, object listener);
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/eventd.c
+
+DEKLARIERT IN
+-------------
+::
+
+     /sys/events.h
+
+ARGUMENTE
+---------
+::
+
+     string eid,
+       Die ID des Events, vom dem man sich abmelden will.
+     object listener,
+       Das Objekt, das als Lauscher ausgetragen werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Das Objekt 'listener' wird als Lauscher dieses Events ausgetragen. Ab
+     diesem Moment wird es bei Events vom Typ 'eid' nicht mehr informiert.     
+
+     Hat der Event 'eid' im Anschluss keine Lauscher mehr, wird er implizit
+     geloescht.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1 fuer Erfolg, <=0 fuer Misserfolg.
+     1   - Erfolg, 'listener' wurde eingetragen.
+     -1  - falsche Argumente uebergeben
+     -2  - 'listener' ist nicht fuer 'eid' registriert.
+
+    
+
+BEMERKUNGEN
+-----------
+::
+
+     Wenn sich ein Objekt vor Zerstoerung nicht abmeldet, wird es ggf. beim
+     naechsten Auftreten von 'eid' automatisch ausgetragen.
+     Falls Blueprints nach Neuladen nicht automatisch angemeldet sein sollen,
+     sollten sie sich im remove() explizit abmelden.
+
+BEISPIELE
+---------
+::
+
+     1. Ein Objekt moechte nicht mehr ueber Spielertode informiert werden:
+          EVENTD->UnregisterEvent(EVT_LIB_PLAYER_DEATH, this_object());
+
+     2. Ein Objekt moechte sich bei Zerstoerung abmelden:
+       varargs int remove(int silent) {
+           ...
+           EVENTD->UnregisterEvent("zesstra_vulkanausbruch",this_object());
+       }
+
+SIEHE AUCH
+----------
+::
+
+     events, eventd, UnregisterEvent(), RegisterEvent()
+
+
+Last modified: 15.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/UnregisterHelperNPC.rst b/doc/sphinx/lfun/UnregisterHelperNPC.rst
new file mode 100644
index 0000000..08ec955
--- /dev/null
+++ b/doc/sphinx/lfun/UnregisterHelperNPC.rst
@@ -0,0 +1,72 @@
+UnregisterHelperNPC()
+=====================
+
+FUNKTION
+--------
+::
+
+     public int UnregisterHelperNPC(object npc);
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/combat.c
+
+ARGUMENTE
+---------
+::
+
+     object npc
+       Objekt des helfenden NPC, der abgemeldet werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Funktion wird ein einem Spieler helfender NPC im Spieler
+     wieder abgemeldet, wenn dieser dem Spieler ab jetzt nicht mehr hilft.
+
+     Wenn ein Helfer-NPC zerstoert wird, ist der Aufruf nicht noetig.
+     Bleibt das Objekt des NPC aber existent, bitte auf jeden Fall wieder
+     ordentlich abmelden, da ansonsten ggf. der Spieler unnoetig blockiert
+     wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn die Abmeldung erfolgreich war.
+     0 sonst, z.B. wenn der NPC gar nicht als Helfer registriert war.
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Funktion setzt bei der Erfolg die Property P_HELPER_NPC in <npc>
+     auf 0.
+
+BEISPIELE
+---------
+::
+
+     1. Ein NPC, der dem Spieler nicht mehr helfen will und normalerweisen im
+        Raum verbleiben soll:
+     tell_object(spieler, "Ich mag Dich nicht mehr, Du bist doof!\n");
+     if (spieler->UnregisterHelperNPC(this_object()) != 1) {
+       // das ist ja bloed...
+       remove(0);
+     }
+     else {
+       tell_room(environment(),
+           Name()+" dreht " +spieler->Name(WEM) + " schmollend den Ruecken "
+           "zu.\n");
+     }
+
+SIEHE AUCH
+----------
+::
+
+    UnregisterHelperNPC()
+    P_HELPER_NPC
+
diff --git a/doc/sphinx/lfun/UnregisterHelperObject.rst b/doc/sphinx/lfun/UnregisterHelperObject.rst
new file mode 100644
index 0000000..62ff671
--- /dev/null
+++ b/doc/sphinx/lfun/UnregisterHelperObject.rst
@@ -0,0 +1,71 @@
+UnregisterHelperObject()
+========================
+
+FUNKTION
+--------
+::
+
+     int UnregisterHelperObject(object helper, int type);
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/helpers.c
+
+ARGUMENTE
+---------
+::
+
+     object helper
+       Das Objekt, das als Hilfsobjekt deregistriert werden soll.
+     int type
+       Helfertyp, einer der in /sys/living/helpers.h definierten Typen:
+       - HELPER_TYPE_AERIAL fuer die Flug-/Segelunterstuetzung
+       - HELPER_TYPE_AQUATIC fuer Tauchunterstuetzung
+
+BESCHREIBUNG
+------------
+::
+
+     Das als Hilfsobjekt fuer bestimmte Aktivitaeten wie zum Beispiel Tauchen
+     oder Fliegen bei einem Lebewesen registrierte Objekt "helper" meldet
+     sich bei diesem ab.
+     Hinweis: fuer eine temporaer gueltige "Nicht-Zustaendigkeit" kaeme auch
+     in Frage, in dieser Zeit einfach "0" zurueckzugeben, statt sich
+     komplett abzumelden.
+
+RUECKGABEWERTE
+--------------
+::
+
+      1  Objekt wurde erfolgreich ausgetragen (HELPER_SUCCESS)
+     -1  angegebenes Hilfsobjekt existiert nicht (HELPER_NO_CALLBACK_OBJECT)
+     -3  angegebenes Hilfsobjekt war gar nicht angemeldet
+         (HELPER_NOTHING_TO_UNREGISTER)
+
+BEISPIEL
+--------
+::
+
+     Eine luftgefuellte Blase hatte sich als Tauch-Helfer am Spieler
+     angemeldet, ist jetzt aber verbraucht und meldet sich daher ab:
+
+     // Austragen im Spielerobjekt
+     void BlaseAustragen() {
+       [...]
+       if ( TP->UnregisterHelperObject(ME, HELPER_TYPE_AQUATIC)
+            == HELPER_SUCCESS )
+         remove();
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Funktionen:  RegisterHelperObject()
+     Properties:  P_HELPER_OBJECTS, P_AERIAL_HELPERS, P_AQUATIC_HELPERS
+     Sonstiges:   /sys/living/helpers.h
+
+19.02.2013 Arathorn
+
diff --git a/doc/sphinx/lfun/Unwear.rst b/doc/sphinx/lfun/Unwear.rst
new file mode 100644
index 0000000..f8e7f38
--- /dev/null
+++ b/doc/sphinx/lfun/Unwear.rst
@@ -0,0 +1,65 @@
+Unwear()
+========
+
+FUNKTION
+--------
+::
+
+     public int Unwear(object ob) 
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+     object ob
+       Die Ruestung oder Kleidung, die ausgezogen wird.
+
+BESCHREIBUNG
+------------
+::
+
+     Das Lebewesen, in dem diese Funktion gerufen wird, zieht die Ruestung
+     oder das Kleidungsstueck <ob> aus.
+     ABER: 'Ausziehen' bedeutet in diesem Kontext lediglich, dass die
+     Ruestung/Kleidung aus P_ARMOURS bzw. P_CLOTHING ausgetragen wird. Es
+     finden zur Zeit keine Pruefungen statt, ob das Lebewesen den Gegenstand
+     ueberhaupt ausziehen kann. Genausowenig werden Funktionen wie
+     InformUnwear()/RemoveFunc() gerufen oder etwaige Stat-Boni deaktiviert.
+
+     Die Funktion ist nur dazu gedacht, im Zuge des Ausziehens eines Objekts
+     von diesem im Lebewesen gerufen zu werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn das Ausziehen erfolgreich war.
+     0 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+     Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
+     besten auch dann nicht.
+
+SIEHE AUCH
+----------
+::
+
+     Wear(), WearArmour(), WearClothing(), UnwearArmour(), UnwearClothing()
+     P_CLOTHING, P_ARMOURS
+     FilterClothing(), FilterArmours()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/UnwearArmour.rst b/doc/sphinx/lfun/UnwearArmour.rst
new file mode 100644
index 0000000..7344469
--- /dev/null
+++ b/doc/sphinx/lfun/UnwearArmour.rst
@@ -0,0 +1,65 @@
+UnwearArmour()
+==============
+
+FUNKTION
+--------
+::
+
+     public int UnwearArmour(object ob) 
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+     object ob
+       Die Ruestung, die ausgezogen wird.
+
+BESCHREIBUNG
+------------
+::
+
+     Das Lebewesen, in dem diese Funktion gerufen wird, zieht die Ruestung
+     <ob> aus.
+     ABER: 'Ausziehen' bedeutet in diesem Kontext lediglich, dass die
+     Ruestung/Kleidung aus P_ARMOURS ausgetragen wird. Es finden zur Zeit
+     keine Pruefungen statt, ob das Lebewesen den Gegenstand ueberhaupt
+     ausziehen kann. Genausowenig werden Funktionen wie
+     InformUnwear()/RemoveFunc() gerufen oder etwaige Stat-Boni deaktiviert.
+
+     Die Funktion ist nur dazu gedacht, im Zuge des Ausziehens eines Objekts
+     von diesem im Lebewesen gerufen zu werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn das Ausziehen erfolgreich war.
+     0 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+     Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
+     besten auch dann nicht.
+
+SIEHE AUCH
+----------
+::
+
+     Wear(), WearArmour(), WearClothing(), Unwear(), UnwearClothing()
+     P_CLOTHING, P_ARMOURS
+     FilterClothing(), FilterArmours()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/UnwearClothing.rst b/doc/sphinx/lfun/UnwearClothing.rst
new file mode 100644
index 0000000..4f73636
--- /dev/null
+++ b/doc/sphinx/lfun/UnwearClothing.rst
@@ -0,0 +1,65 @@
+UnwearClothing()
+================
+
+FUNKTION
+--------
+::
+
+     public int UnwearClothing(object ob) 
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+     object ob
+       Das Kleidungsstuck, das ausgezogen wird.
+
+BESCHREIBUNG
+------------
+::
+
+     Das Lebewesen, in dem diese Funktion gerufen wird, zieht das
+     Kleidungsstueck <ob> aus.
+     ABER: 'Ausziehen' bedeutet in diesem Kontext lediglich, dass die
+     Ruestung/Kleidung aus P_CLOTHING ausgetragen wird. Es finden zur Zeit
+     keine Pruefungen statt, ob das Lebewesen den Gegenstand ueberhaupt
+     ausziehen kann. Genausowenig werden Funktionen wie
+     InformUnwear()/RemoveFunc() gerufen.
+
+     Die Funktion ist nur dazu gedacht, im Zuge des Ausziehens eines Objekts
+     von diesem im Lebewesen gerufen zu werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn das Ausziehen erfolgreich war.
+     0 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+     Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
+     besten auch dann nicht.
+
+SIEHE AUCH
+----------
+::
+
+     Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour()
+     P_CLOTHING, P_ARMOURS
+     FilterClothing(), FilterArmours()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/UnwieldFunc.rst b/doc/sphinx/lfun/UnwieldFunc.rst
new file mode 100644
index 0000000..55ed08f
--- /dev/null
+++ b/doc/sphinx/lfun/UnwieldFunc.rst
@@ -0,0 +1,75 @@
+UnwieldFunc()
+=============
+
+FUNKTION
+--------
+::
+
+     int UnwieldFunc(object weapon, int info, object user);
+
+DEFINIERT IN
+------------
+::
+
+     eigenen Objekten, fuer /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+     weapon (object)
+          Die Waffe, die weggesteckt werden soll.
+     info (int)
+          Bei (info&M_SILENT) wird keine Meldung ueber das Wegstecken
+          ausgegeben.
+          Bei (info&M_NOCHECK) wird die Waffe auch weggesteckt, wenn
+          sie verflucht ist. Die tritt insbesondere dann auf, wenn der
+          Spieler, der die Waffe benutzt, stirbt und die Waffe in
+          die Leiche bewegt wird.
+     user (object)
+          Das Lebewesen, welches die Waffe gerade gezueckt hat und sie nun
+          ausziehen will.
+
+BESCHREIBUNG
+------------
+::
+
+     Hier koennen zusaetzliche Abfragen vorgenommen werden, ob sich die
+     Waffe <weapon> wegstecken laesst oder nicht.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn sich die Waffe nicht wegstecken laesst, ansonsten ungleich 0.
+
+BEMERKUNGEN
+-----------
+::
+
+     Verfluchte Waffen, die sich erst nach Entfernung des Fluches wegstecken
+     lassen, sollte man besser mit P_CURSED realisieren.
+     Selbst wenn man einen Wert ungleich Null zurueckgibt, ist das noch
+     keine Garantie, dass sich die Waffe auch wirklich zuecken laesst! Der
+     Spieler koennte zum Beispiel noch eine Waffe gezueckt haben, die sich
+     nicht wegstecken laesst, etc.
+     Wenn ihr sicher sein wollt, dass der Spieler ein Objekt gezueckt hat,
+     benutzt bitte InformWear().
+     Bitte nicht drauf verlassen, dass this_player() das Lebewesen ist,
+     welches die Waffe gezueckt und wegstecken will.
+     Die Reihenfolge der Argumente ist etwas unschoen, aber leider wurde <user>
+     erheblich spaeter hinzugefuegt und es war unmoeglich, einige hundert
+     Objekte zu aendern.
+
+SIEHE AUCH
+----------
+::
+
+     P_WIELD_MSG, P_UNWIELD_MSG, P_WEAR_MSG, P_UNWEAR_MSG
+     DoWield(), DoUnwield(), InformWield(), InformUnwield(), 
+     UnwieldFunc, WieldFunc() 
+     /std/weapon/combat.c
+
+
+02.02.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/UpdateAttributes.rst b/doc/sphinx/lfun/UpdateAttributes.rst
new file mode 100644
index 0000000..51bbb60
--- /dev/null
+++ b/doc/sphinx/lfun/UpdateAttributes.rst
@@ -0,0 +1,52 @@
+UpdateAttributes()
+==================
+
+FUNKTION
+--------
+::
+
+     void UpdateAttributes()
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/attributes.c
+
+BESCHREIBUNG
+------------
+::
+
+     Rechnet damit alle Attributmodifier der im Inventory befindlichen 
+     (P_X_ATTR_MOD, P_X_HEALTH_MOD) und getragenen/gezueckten 
+     (P_M_HEALTH_MOD, P_M_ATTR_MOD) Objekte und aller Attributoffsets 
+     zusammen und speichert sie in einer intern fuer Attribute 
+     verwendete Variablen.
+     Berechnet darauf basierend HP und SP neu.
+
+     
+
+     Die Bedingungen fuer die ueber P_TIMED_ATTR_MOD gesetzten 
+     Attributveraenderungen werden im Heartbeat in der Funktion
+     attribute_hb ueberprueft.
+
+BEMERKUNGEN
+-----------
+::
+
+     Sollte nach Einbringen neuer Modifikatorobjekte am Living gerufen
+     werden.
+
+SIEHE AUCH
+----------
+::
+
+	QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+	SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+	SetTimedAttrModifier(), QueryTimedAttrModifier(), 
+	DeleteTimedAttrModifier(),
+	P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+	P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+09.05.2007 by Zesstra
+
diff --git a/doc/sphinx/lfun/UpdateResistanceStrengths.rst b/doc/sphinx/lfun/UpdateResistanceStrengths.rst
new file mode 100644
index 0000000..cb43c10
--- /dev/null
+++ b/doc/sphinx/lfun/UpdateResistanceStrengths.rst
@@ -0,0 +1,43 @@
+UpdateResistanceStrengths()
+===========================
+
+FUNKTION
+--------
+::
+
+     public void UpdateResistanceStrengths()
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/combat.c
+
+BESCHREIBUNG
+------------
+::
+
+     Die Funktion wird intern mehrmals (durch Defend, AddResistanceModifier
+     und RemoveResistanceModifier) aufgerufen. In ihr wird das Resistenz-
+     mapping zusammengerechnet und Eintraege geloescht, deren Eintraege
+     invalid sind oder deren setzende Objekte geloescht wurden.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+SIEHE AUCH
+----------
+::
+
+     Berechnung:	CheckResistance(), Defend()
+     Modifikatoren:	AddResistanceModifier, RemoveResistanceModifier(),
+			P_RESISTANCE_MODIFIER
+     simple Resistenz:	P_RESISTANCE, P_VULNERABILITY
+     Hauptmapping:	P_RESISTANCE_STRENGTHS
+     anderes:		balance, /std/armour/combat.c, /std/living/combat.c
+
+29.Apr 2002, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/UseHands.rst b/doc/sphinx/lfun/UseHands.rst
new file mode 100644
index 0000000..9485e83
--- /dev/null
+++ b/doc/sphinx/lfun/UseHands.rst
@@ -0,0 +1,61 @@
+UseHands()
+==========
+
+FUNKTION
+--------
+::
+
+     public varargs int UseHands(object ob, int num)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+     ob  - das Objekt, das die Haende belegen soll
+     num - die Anzahl der zu belegenden Haende    
+
+RUECKGABEWERT
+-------------
+::
+
+     1, fuer Erfolg
+     0, sonst     
+
+BESCHREIBUNG
+------------
+::
+
+     Belegt, wenn moeglich Haende eines Livings durch ein bestimmtes
+     Objekt. Wenn die Anzahl der freien Haende (P_MAX_HANDS-P_USED_HANDS)
+     kleiner ist als "num", dann schlaegt diese Belegung fehl.
+
+BEISPIELE
+---------
+::
+
+     > halte seil fest
+     ...
+     this_player()->UseHands(this_object(),2);
+     ...
+
+     > lasse seil los
+     ...
+     this_player()->FreeHands(this_object());
+     ...
+
+SIEHE AUCH
+----------
+::
+
+     P_HANDS, P_HANDS_USED_BY
+     P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
+     FreeHands
+
+1.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/UseSkill.rst b/doc/sphinx/lfun/UseSkill.rst
new file mode 100644
index 0000000..b994e67
--- /dev/null
+++ b/doc/sphinx/lfun/UseSkill.rst
@@ -0,0 +1,74 @@
+UseSkill()
+==========
+
+FUNKTION
+--------
+::
+
+    public varargs mixed UseSkill(string skill, mapping args)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skills.c
+
+ARGUMENTE
+---------
+::
+
+    string skill     Skill-Name
+    mapping args     Argumente (veraenderte Skillmapping-Informationen)
+
+BESCHREIBUNG
+------------
+::
+
+    Benutzt einen Skill. Dieser Skill sollte (als grossgeschriebener Skill)
+    im Living vorliegen und das Living darf kein Geist sein.
+
+    
+
+    Die Argumente 'args' werden temporaer auf das Skillmapping des Living
+    addiert (also nur fuer diesen Aufruf und SI_INHERIT gueltig).
+
+    
+
+    Eine ausfuehrbare Skill-Funktion zum Skill wird in folgender
+    Reihenfolge bestimmt:
+    - eine gesetzte SI_CLOSURE nutzen
+    - ein gesetztes SI_SKILLFUNC in der gesetzten Gilde nutzen
+    - im Living die Funktion "StdSkill_"+skill (zB Waffenskills) nutzen
+    - QuerySkillAbility() nutzen
+    Die so bestimmte Skill-Funktion wird dann als SI_CLOSURE im Spieler
+    gesetzt und ist bis zur Zerstoerung der entsprechenden Objekte gueltig.
+    Die Methode wird dann gerufen (der Skill also angewandt).
+
+    
+
+    Standardmaessig gibt ein UseSkill() also einfach den SI_SKILLABILITY-Wert
+    eines Skills zurueck, es sei denn, eine Funktion wurde fuer den Skill
+    an einer der oben genannten Stellen implementiert.
+
+    
+
+    Ein eventuell uebergeordneter Skill (SI_INHERIT) wird mit dem durch den
+    Aufruf der Skill-Funktion veraenderten Mapping mit UseSkill(skill, args)
+    ebenfalls noch ausgefuehrt, bevor das Resultat zurueckgegeben wird.
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:      UseSpell
+    * Abfragen:     QuerySkill, QuerySkillAbility
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung, skill_info_liste
+    * Properties:   P_NEWSKILLS
+    Spellbook:      Learn, SpellSuccess, Erfolg, Misserfolg
+
+4. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/UseSpell.rst b/doc/sphinx/lfun/UseSpell.rst
new file mode 100644
index 0000000..e9a3e9a
--- /dev/null
+++ b/doc/sphinx/lfun/UseSpell.rst
@@ -0,0 +1,105 @@
+UseSpell()
+==========
+
+FUNKTION
+--------
+::
+
+    public varargs int UseSpell(string str, string spell)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skills.c
+
+ARGUMENTE
+---------
+::
+
+    string str       Spell-Optionen
+    string spell     optionaler Spellname
+
+BESCHREIBUNG
+------------
+::
+
+    Benutzt einen Spell, dessen Spellname 'spell' ggf ueber query_verb()
+    ermittelt wird. Dieser Spell sollte (als kleingeschriebener
+    Skill/Spell) im Living vorliegen.
+
+    
+
+    Die Argumente 'str' werden als SI_SKILLARG temporaer in das
+    Skillmapping eingetragen (also nur fuer diesen Aufruf gueltig).
+
+    
+
+    Eine ausfuehrbare Spell-Funktion zum Spell wird in folgender
+    Reihenfolge bestimmt:
+    - eine gesetzte SI_CLOSURE nutzen
+    - "UseSpell" an einem gesetzten SI_SPELLBOOK nutzen
+    - "UseSpell" an der gesetzten P_GUILD nutzen
+      - [UseSpell der Gilde sucht iA ebenfalls nur den Spell am Spellbook]
+    - eine Closure mit Rueckgabewert 0 erstellen
+    Die so bestimmte Spell-Funktion wird dann als SI_CLOSURE im Spieler
+    gesetzt und ist bis zur Zerstoerung der entsprechenden Objekte gueltig.
+    Die Methode wird dann gerufen (der Spell also angewandt).
+
+    Standardmaessig gibt ein UseSpell() also 0 zurueck, es sei denn, eine
+    Funktion wurde fuer den Spell an einer der oben genannten Stellen
+    implementiert.
+
+    SI_INHERIT ist fuer Spells beim Aufruf wirkungslos (gilt aber bei
+    LearnSkill normal).
+
+    Ein Durchlauf von UseSpell durch den Spieler sieht in etwa so aus:
+      1) Die Methode wird als Empfaenger fuer Kommandos bekannt gemacht.
+         Das passiert mit der Anweisung
+         'add_action("UseSpell", "", 1);' in den Dateien player/base.c und
+         in living/npc.c.
+
+      2) /std/living/skills::UseSpell wird durch Kommando oder Heartbeat
+         gerufen.
+
+      
+
+      3) UseSpell() ermittelt eine SI_CLOSURE oder delegiert diesen Aufruf
+         an die gueltige Gilde/das Spellbook weiter.
+
+      
+
+      4) Eine gueltige Closure wird ausgefuehrt. UseSpell() uebergibt dabei
+         die Spell/Skill-Informationen und SI_SKILLARG.
+
+      
+
+      4.1.) Im Normalfall einer Gilde/Spellbook landet der Aufruf ueber
+            /std/gilden_ob::UseSpell() in /std/spellbook::UseSpell() und
+            dieses ruft eine Spellfunktion im Spellbook auf.
+            Die Spellfunktion arbeitet mit den Spell-Informationen und
+            gibt ein ERFOLG, MISSERFOLG oder 0 dafuer zurueck, ob das
+            Spellbook Lernen/Fehlermeldung oder nichts machen soll.
+            Dementsprechend werden P_SP, P_ATTACK_BUSY und
+            P_NEXT_SPELL_TIME im Spellbook geaendert.
+
+      5.) Der Aufruf der Closure kehrt zurueck und wird zurueckgegeben.
+          Damit ist der 0-Rueckgabewert der Spellfunktion im Spellbook
+          aequivalent einem nicht ausgefuehrten Kommando.
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:      UseSkill
+    * Abfragen:     QuerySkill, QuerySkillAbility
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung, skill_info_liste
+    * Properties:   P_NEWSKILLS
+    Spellbook:      UseSpell (spellbook), Learn, SpellSuccess
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/Validate.rst b/doc/sphinx/lfun/Validate.rst
new file mode 100644
index 0000000..479d1dc
--- /dev/null
+++ b/doc/sphinx/lfun/Validate.rst
@@ -0,0 +1,76 @@
+Validate()
+==========
+
+FUNKTION
+--------
+::
+
+   string Validate(string oname);
+
+DEFINIERT IN
+------------
+::
+
+   /std/virtual/v_compiler.c
+
+ARGUMENTE
+---------
+::
+
+   oname
+       Objektname, der geprueft werden soll 
+
+RUeCKGABEWERT
+-------------
+::
+
+   
+
+BESCHREIBUNG
+------------
+::
+
+   Diese Funktion hat die Aufgabe zu ueberpruefen ob ein Objekt welches
+   geladen werden soll, in dem VC  ueberhaupt erlaubt ist. Dieser 
+   Funktion wird nur der reine Filename uebergeben, ohne Pfad!
+   Diese Funktion macht im Standard-VC in /std/ nichts weiter, als
+   das '.c' am File Namen abzuschneiden.
+   Sollte der Dateiname gueltig sein liefert die Funktion als Rueckgabewert
+   den Filenamen ohne .c und sonst 0.
+
+BEMERKUNGEN
+-----------
+::
+
+   Am besten ruft man in seinem Validate() das ::Validate(), was einem die
+   Arbeit abnimmt, ein .c am Ende zu entfernen.
+
+BEISPIEL
+--------
+::
+
+   string Validate(string oname) {
+     string raum, spieler;
+     //.c abschneiden
+     oname=::Validate(oname);
+
+     
+
+     // folgt der Raum dem Muster "arena|name"? Wenn nein -> ungueltig,
+     // 0 zureckgeben, sonst den Filenamen.
+     if(sscanf(oname,"%s|%s",raum,spieler)<2 || raum!="arena")
+        return 0;
+     return oname;
+   }
+
+SIEHE AUCH
+----------
+::
+
+     virtual_compiler
+     CustomizeObject(), Validate(), NoParaObjects(), 
+     P_COMPILER_PATH, P_PARA
+     /std/virtual/v_compiler.c
+
+27.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/Wear.rst b/doc/sphinx/lfun/Wear.rst
new file mode 100644
index 0000000..2638548
--- /dev/null
+++ b/doc/sphinx/lfun/Wear.rst
@@ -0,0 +1,64 @@
+Wear()
+======
+
+FUNKTION
+--------
+::
+
+     public int Wear(object ob) 
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+     object ob
+       Die Ruestung oder Kleidung, die angezogen wird.
+
+BESCHREIBUNG
+------------
+::
+
+     Das Lebewesen, in dem diese Funktion gerufen wird, zieht die Ruestung
+     oder das Kleidungsstueck <ob> an.
+     ABER: 'Anziehen' bedeutet in diesem Kontext lediglich, dass die
+     Ruestung/Kleidung in P_ARMOURS bzw. P_CLOTHING eingetragen wird. Es
+     finden zur Zeit keine Pruefungen statt, ob das Lebewesen den Gegenstand
+     ueberhaupt anziehen kann. Genausowenig werden Funktionen wie InformWear()
+     gerufen oder etwaige Stat-Boni aktiviert.
+     Die Funktion ist nur dazu gedacht, im Zuge des Anziehens eines Objekts
+     von diesem im Lebewesen gerufen zu werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn das Anziehen erfolgreich war.
+     0 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+     Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
+     besten auch dann nicht.
+
+SIEHE AUCH
+----------
+::
+
+     WearArmour(), WearClothing(), Unwear(), UnwearArmour(), UnwearClothing()
+     P_CLOTHING, P_ARMOURS
+     FilterClothing(), FilterArmours()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/WearArmour.rst b/doc/sphinx/lfun/WearArmour.rst
new file mode 100644
index 0000000..0762aea
--- /dev/null
+++ b/doc/sphinx/lfun/WearArmour.rst
@@ -0,0 +1,64 @@
+WearArmour()
+============
+
+FUNKTION
+--------
+::
+
+     public int WearArmour(object ob) 
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+     object ob
+       Die Ruestung, die angezogen wird.
+
+BESCHREIBUNG
+------------
+::
+
+     Das Lebewesen, in dem diese Funktion gerufen wird, zieht die Ruestung
+     <ob> an.
+     ABER: 'Anziehen' bedeutet in diesem Kontext lediglich, dass die
+     Ruestung/Kleidung in P_ARMOURS eingetragen wird. Es finden zur Zeit keine
+     Pruefungen statt, ob das Lebewesen den Gegenstand ueberhaupt anziehen
+     kann. Genausowenig werden Funktionen wie InformWear() gerufen oder
+     etwaige Stat-Boni aktiviert.
+     Die Funktion ist nur dazu gedacht, im Zuge des Anziehens eines Objekts
+     von diesem im Lebewesen gerufen zu werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn das Anziehen erfolgreich war.
+     0 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+     Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
+     besten auch dann nicht.
+
+SIEHE AUCH
+----------
+::
+
+     Wear(), WearClothing(), Unwear(), UnwearArmour(), UnwearClothing()
+     P_CLOTHING, P_ARMOURS
+     FilterClothing(), FilterArmours()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/WearClothing.rst b/doc/sphinx/lfun/WearClothing.rst
new file mode 100644
index 0000000..7dc1b2b
--- /dev/null
+++ b/doc/sphinx/lfun/WearClothing.rst
@@ -0,0 +1,64 @@
+WearClothing()
+==============
+
+FUNKTION
+--------
+::
+
+     public int WearClothing(object ob) 
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+     object ob
+       Das Kleidungsstuck, das angezogen wird.
+
+BESCHREIBUNG
+------------
+::
+
+     Das Lebewesen, in dem diese Funktion gerufen wird, zieht das
+     Kleidungsstueck <ob> an.
+     ABER: 'Anziehen' bedeutet in diesem Kontext lediglich, dass die
+     Ruestung/Kleidung in P_CLOTHING eingetragen wird. Es finden zur Zeit
+     keine Pruefungen statt, ob das Lebewesen den Gegenstand ueberhaupt
+     anziehen kann. Genausowenig werden Funktionen wie InformWear() gerufen.
+
+     Die Funktion ist nur dazu gedacht, im Zuge des Anziehens eines Objekts
+     von diesem im Lebewesen gerufen zu werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn das Anziehen erfolgreich war.
+     0 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+     Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
+     besten auch dann nicht.
+
+SIEHE AUCH
+----------
+::
+
+     Wear(), WearArmour(), Unwear(), UnwearArmour(), UnwearClothing()
+     P_CLOTHING, P_ARMOURS
+     FilterClothing(), FilterArmours()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/WearFunc.rst b/doc/sphinx/lfun/WearFunc.rst
new file mode 100644
index 0000000..573fee6
--- /dev/null
+++ b/doc/sphinx/lfun/WearFunc.rst
@@ -0,0 +1,106 @@
+WearFunc()
+==========
+
+FUNKTION
+--------
+::
+
+     int WearFunc(object ruest, int silent, object user);
+
+DEFINIERT IN
+------------
+::
+
+     eigenen Objekten (fuer /std/clothing/wear)
+
+ARGUMENTE
+---------
+::
+
+     ruest (object)
+          Die Ruestung/Kleidung, die angezogen werden soll.
+     silent (int)
+          Ob dabei eine Meldung ausgegeben wird.
+     user (object)
+          Das Lebewesen, welches die Ruestung/Kleidung anziehen will.
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Funktion kann man pruefen, ob sich das Kleidungsstueck bzw.
+     Ruestung <ruest> von this_player() anziehen laesst oder nicht.
+     Kann die Ruestung angezogen werden, so muss ein Wert ungleich 0
+     zurueckgegeben werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn sich die Ruestung nicht anziehen laesst, ansonsten ungleich 0.
+
+BEMERKUNGEN
+-----------
+::
+
+     Bitte nicht darauf verlassen, dass der Spieler das Objekt auch wirklich
+     anzieht, wenn man hier 1 zurueckgibt.
+     Speziell bei Schilden kann das Anziehen trotz eines Rueckgabewertes 
+     != 0 immer noch schief gehen, wenn der Spieler keine Hand mehr frei hat.
+     Wenn ihr sicher sein wollt, dass der Spieler ein Objekt angezogen hat,
+     benutzt bitte InformWear().
+     Bitte nicht drauf verlassen, dass this_player() das ausziehende Lebewesen
+     ist.
+     Die Reihenfolge der Argumente ist etwas unschoen, aber leider wurde <user>
+     erheblich spaeter hinzugefuegt und es war unmoeglich, einige hundert
+     Objekte zu aendern.
+
+BEISPIELE
+---------
+::
+
+     Ein Helm, der nur von Elfen getragen werden kann:
+
+     inherit "std/armour.c";
+
+     #include <properties.h>
+
+     create()
+     {
+       ::create();
+
+       SetProp(P_ARMOUR_TYPE, AT_HELMET);
+       /* zig weitere SetProp's, um den Helm zu konfigurieren */
+
+       /* WearFunc() ist im Helm selbst zu finden */
+       SetProp(P_WEAR_FUNC, this_object());
+     }
+
+     int WearFunc(object me, int silent, object user)
+     {
+       if (user->QueryProp(P_RACE) == "Elf")
+         return 1;   /* Elfen duerfen den Helm tragen */
+
+       /* Die anderen Rassen sollten zumindest erfahren koennen, wieso
+          sie den Helm nicht tragen koennen... */
+       if (!silent)
+           write( "Der Helm rutscht Dir immer ueber Deine runden "
+                 +"Ohren.\n" );
+       return 0;
+     }
+
+     Gibt jetzt ein Nicht-Elf "trage helm" ein, so bekommt er die Meldung
+     "Der Helm rutscht Dir immer ueber Deine runden Ohren.", Elfen dagegen
+     passt das Teil wie angegossen.
+
+SIEHE AUCH
+----------
+::
+
+     P_WEAR_MSG, P_UNWEAR_MSG, P_WIELD_MSG, P_UNWIELD_MSG
+     DoWear(), DoUnwear(), InformUnwear(), InformWear()
+     /std/clothing/wear.c
+
+
+02.02.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/WieldFunc.rst b/doc/sphinx/lfun/WieldFunc.rst
new file mode 100644
index 0000000..f6e2a37
--- /dev/null
+++ b/doc/sphinx/lfun/WieldFunc.rst
@@ -0,0 +1,103 @@
+WieldFunc()
+===========
+
+FUNKTION
+--------
+::
+
+     int WieldFunc(object weapon, int silent, object user);
+
+DEFINIERT IN
+------------
+::
+
+     eigenen Objekten (fuer /std/weapon/combat)
+
+ARGUMENTE
+---------
+::
+
+     weapon (object)
+          Die Waffe, die gezueckt werden soll.
+     silent (int)
+          Ob dabei eine Meldung ausgegeben werden soll.
+     user (object)
+          Das Lebewesen, welches die Waffe zuecken will.
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Funktion kann man zusaetzliche Abfragen vornehmen, ob sich
+     die Waffe <weapon> von <user> zuecken laesst oder nicht.
+
+RUeCKGABEWERT
+-------------
+::
+
+     0, wenn die Waffe nicht gezueckt werden kann, sonst ungleich 0.
+
+BEMERKUNGEN
+-----------
+::
+
+     Selbst wenn man einen Wert ungleich Null zurueckgibt, ist das noch
+     keine Garantie, dass sich die Waffe auch wirklich zuecken laesst! Der
+     Spieler koennte zum Beispiel noch eine Waffe gezueckt haben, die sich
+     nicht wegstecken laesst, etc.
+     Wenn ihr sicher sein wollt, dass der Spieler ein Objekt gezueckt hat,
+     benutzt bitte InformWield().
+     Bitte nicht drauf verlassen, dass this_player() das Lebewesen ist,
+     welches die Waffe zuecke will.
+     Die Reihenfolge der Argumente ist etwas unschoen, aber leider wurde <user>
+     erheblich spaeter hinzugefuegt und es war unmoeglich, einige hundert
+     Objekte zu aendern.
+
+BEISPIELE
+---------
+::
+
+     Eine Waffe, die sich nicht von Zwergen zuecken laesst:
+
+     inherit "std/weapon";
+
+     #include <properties.h>
+     #include <combat.h>
+
+     create()
+     {
+       ::create();
+
+       ... /* zig SetProp's, um die Waffe zu konfigurieren */
+
+       /* WieldFunc() ist in der Waffe selbst zu finden */
+       SetProp(P_WIELD_FUNC, this_object());
+     }
+
+     int WieldFunc(object weapon, int silent, object user)
+     {
+       /* Nicht-Zwerge duerfen die Waffe zuecken */
+       if (user->QueryProp(P_RACE) != "Zwerg")
+         return 1;
+
+       /* Ansonsten sagen wir evtl., warum das Zuecken nicht klappt... */
+       if (!silent)
+         write( "Deine kleinen Haendchen koennen den Griff nicht "+
+                "umklammern.\n");
+
+       /* ...und brechen das Zuecken ab. */
+       return 0;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     P_WIELD_MSG, P_UNWIELD_MSG, P_WEAR_MSG, P_UNWEAR_MSG
+     DoWield(), DoUnwield(), InformUnwield(), InformWield() 
+     UnwieldFunc, WieldFunc 
+     /std/weapon/combat.c
+
+
+02.02.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/WithDraw.rst b/doc/sphinx/lfun/WithDraw.rst
new file mode 100644
index 0000000..c7aff00
--- /dev/null
+++ b/doc/sphinx/lfun/WithDraw.rst
@@ -0,0 +1,69 @@
+WithDraw()
+==========
+
+FUNKTION
+--------
+::
+
+     int WithDraw(int amount);
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/zentralbank.c
+
+ARGUMENTE
+---------
+::
+
+     int amount	- angeforderte Geldmenge
+
+BESCHREIBUNG
+------------
+::
+
+     Damit wird bei der Zentralbank eine bestimmte Menge Geld angefordert.
+     Der Rueckgabewert haengt vom Kassenstand der Zentralbank ab und ist
+     entweder amount oder amount/3.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Menge des bei der Zentralbank "abgehobenen" Geldes.
+
+BEISPIELE
+---------
+::
+
+     #include <bank.h>
+     ...
+     if(ZENTRALBANK->WithDraw(50000)<50000)
+      write(break_string(
+       "Leider koennen wir ihnen keinen vollen Zuschuss zu ihrem Hotelbau "
+       "geben!",
+       "Der Beamte sagt: ",78));
+      say(break_string(
+       "Leider koennen wir ihnen keinen vollen Zuschuss zu ihrem Hotelbau "
+       "geben!",
+       "Der Beamte sagt zu "+this_player()->name(WEM)+": ",78));
+      ...
+
+BEMERKUNGEN
+-----------
+::
+
+     Unsere Zentralbank ist korrupt, vor allem dadurch, dass in Laeden und
+     an anderen Stellen Geld erzeugt wird.
+
+SIEHE AUCH
+----------
+::
+
+     Geldhandling:	AddMoney(L), QueryMoney(L)
+     Zentralbank:	PayIn(L), _query_current_money(L)
+     Sonstiges:		/items/money.c, /sys/bank.h
+
+27. Apr 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/__INIT.rst b/doc/sphinx/lfun/__INIT.rst
new file mode 100644
index 0000000..5af9cd0
--- /dev/null
+++ b/doc/sphinx/lfun/__INIT.rst
@@ -0,0 +1,25 @@
+__INIT()
+========
+
+SYNOPSIS
+--------
+::
+
+	__INIT
+
+DESCRIPTION
+-----------
+::
+
+	This function is constructed automagically by the parser at
+	compiler, if the parser was compiled with #define
+	INITIALISATION__INIT. This function is not intended to be
+	defined by the lpc objects, and never to be called from lpc
+	objects. This man page is here just for completeness.
+
+SEE ALSO
+--------
+::
+
+	initialisation(LPC)
+
diff --git a/doc/sphinx/lfun/_query_current_money.rst b/doc/sphinx/lfun/_query_current_money.rst
new file mode 100644
index 0000000..bbdaebc
--- /dev/null
+++ b/doc/sphinx/lfun/_query_current_money.rst
@@ -0,0 +1,53 @@
+_query_current_money()
+======================
+
+FUNKTION
+--------
+::
+
+     int _query_current_money()
+
+DEFINIERT IN
+------------
+::
+
+     /p/daemon/zentralbank.c
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird zurueckgegeben, wieviel Geld die Zentralbank besitzt.
+
+BEISPIELE
+---------
+::
+
+     #include <bank.h>
+     ...
+     if(ZENTRALBANK->_query_current_money()<30000) {
+      write(break_string(
+       "Leider koennen wir ihren Bausparvertrag derzeit nicht einloesen.",
+       "Der Beamte sagt: ",78));
+      say(break_string(
+       "Leider koennen wir ihren Bausparvertrag derzeit nicht einloesen.",
+       "Der Beamte sagt zu "+this_player()->name(WEM)+": ",78));
+     }
+
+BEMERKUNGEN
+-----------
+::
+
+     Unsere Zentralbank ist korrupt, vor allem dadurch, dass in Laeden und
+     an anderen Stellen Geld erzeugt wird.
+
+SIEHE AUCH
+----------
+::
+
+     Geldhandling:	AddMoney(L), QueryMoney(L)
+     Zentralbank:	WithDraw(L), PayIn(L)
+     Sonstiges:		/items/money.c, /sys/bank.h
+
+27. Apr 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/_unparsed_args.rst b/doc/sphinx/lfun/_unparsed_args.rst
new file mode 100644
index 0000000..25f8d8b
--- /dev/null
+++ b/doc/sphinx/lfun/_unparsed_args.rst
@@ -0,0 +1,49 @@
+_unparsed_args()
+================
+
+FUNKTION
+--------
+::
+
+     varargs string _unparsed_args(int level)
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/command.c:
+
+ARGUMENTE
+---------
+::
+
+     level
+          Gibt an, wieviel des Textes "weggeparsed" werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt den Text des letzten Befehls des Spielers (ohne das Befehlswort
+     selbst) zurueck. "level" gibt dabei an, wieviel geparsed wird:
+     level = 0 : Gar kein Parsing.
+     level = 1 : Der Text wird in Kleinbuchstaben umgewandelt, doppelte
+                 Leerzeichen werden entfernt.
+     level = 2 : Semikoli, Kommata und Doppelpunkte werden in Leerzeichen
+		 umgewandelt, doppelte Leerzeichen und Artikel (der, die,
+		 das, ein,...) werden entfernt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Der geparste Text.
+
+SIEHE AUCH
+----------
+::
+
+     query_command(), query_verb(), modify_command()
+
+25.08.2016, Arathorn
+
diff --git a/doc/sphinx/lfun/access_rights.rst b/doc/sphinx/lfun/access_rights.rst
new file mode 100644
index 0000000..e1ccc42
--- /dev/null
+++ b/doc/sphinx/lfun/access_rights.rst
@@ -0,0 +1,98 @@
+access_rights()
+===============
+
+FUNKTION
+--------
+::
+
+    int access_rights(string euid, string file);
+
+DEFINIERT IN
+------------
+::
+
+    access_rights.c (muss man selber schreiben)
+
+PARAMETER
+---------
+::
+
+    euid
+        Die euid desjenigen, der auf das Verzeichnis schreiben will
+    file
+        Name der Datei, auf die zugegriffen werden soll
+
+BESCHREIBUNG
+------------
+::
+
+    access_rights() wird immer dann aufgerufen, wenn jemand, der nicht
+    sowieso schon schreibberechtigt ist, in die Datei/das Verzeichnis file
+    schreiben oder loeschen will.
+
+    Anhand von euid kann man dann entscheiden, ob der Schreibzugriff erlaubt
+    wird oder nicht.
+
+RUECKGABEWERT
+-------------
+::
+
+    0, wenn der Zugriff verweigert wird,
+    1, wenn der Zugriff erlaubt wird.
+
+BEISPIELE
+---------
+::
+
+    /* /d/inseln/wargon/access_rights.c */
+
+    int access_rights(string euid, string file)
+    {
+      string dir, rest;
+
+      // Catweazle darf auf alles zugreifen (*argl* ;^)
+      if (euid == "catweazle")
+        return 1;
+
+      // Rechte auf einzelne Verzeichnisse ermitteln:
+      if (sscanf(file, "%s/%s", dir, rest) != 2)
+        rest = file;
+
+      // Jof und Boing duerfen an Tarko Reub rumpfuschen:
+      if (dir == "tarko" && (euid == "jof" || euid == "boing"))
+        return 1;
+
+      // Anthea darf die Karten von Aurora und der Piratenhoehle bearbeiten:
+      if (dir == "MAPS" && 
+          member( ({"Aurora", "Piratenhoehle" }), rest) >= 0 && 
+          euid == "anthea")
+        return 1;
+
+      // alle anderen duerfen nicht!
+      return 0;
+    }
+
+BEMERKUNGEN
+-----------
+::
+
+    file ist immer relativ zu dem Verzeichnis, in dem das access_rights.c
+    liegt! Will also jemand auf /d/inseln/wargon/tarko/macros.h schreiben,
+    wird file "tarko/macros.h" uebergeben.
+
+    In Verzeichnissen von Magiern mit einem Level >= ELDER_LVL wird das
+    access_rights.c NICHT ausgewertet (da damit andere Magier zB. an
+    Erzmagierrechte gelangen koennten).
+
+    Es wird immer nur EIN access_rights.c ausgewertet, naemlich das in der
+    tiefsten Verzeichnisebene.
+
+    Man kann sowohl in seinen Regionsverzeichnissen als auch in seinen
+    Homeverzeichnissen access_rights.c-Dateien anlegen.
+
+    GANZ WICHTIG!!!
+    Fuer die Dateien, die evtl. von anderen angelegt werden, ist man immer
+    noch selbst verantwortlich! Wenn jemand also ein Gebiet bei Dir an-
+    schliesst, muss es erst von den verantwortlichen Regionsmagiern abgesegnet
+    sein!
+
diff --git a/doc/sphinx/lfun/buffer_hp.rst b/doc/sphinx/lfun/buffer_hp.rst
new file mode 100644
index 0000000..db0555c
--- /dev/null
+++ b/doc/sphinx/lfun/buffer_hp.rst
@@ -0,0 +1,106 @@
+buffer_hp()
+===========
+
+FUNKTION
+--------
+::
+
+    int buffer_hp( int val, int rate );
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+    val:  Gesamte Heilung.
+    rate: LP-Rate.
+
+        
+
+BESCHREIBUNG
+------------
+::
+
+    Erhoeht die LP eines Spielers automatisch insgesamt um den Wert "val".
+    Pro heart_beat() wird ihm dabei der Wert "rate" zugefuehrt.
+    Sollen neben P_HP noch weitere Props manipuliert werden - bspw. zur
+    P_FOOD - bietet sich die Funktion consume() an.
+
+RUECKGABEWERTE
+--------------
+::
+
+    Der getankte Wert pro heart_beat().
+
+BEMERKUNG
+---------
+::
+
+    Sollte von jeder tragbaren Heilung genutzt werden, welche den Spieler
+    darauf schliessen lassen kann, auf natuerlichem und nichtmagischem Weg
+    (Essen, Trinken) geheilt worden zu sein.
+
+BEISPIEL
+--------
+::
+
+    #define TP this_player()
+    ...
+
+    int heilung=1;
+    ...
+
+    create()
+    {
+     ::create();
+     SetProp(P_NAME,"Heilpflanze");
+     ...
+
+     AddCmd("iss","eat");
+    }
+
+    int eat(string str)
+    {
+      notify_fail("WAS willst Du essen?\n");
+      if ( !str || !id(str) )
+       return 0;
+      ...
+
+      if ( !TP->eat_food(25) )
+       return 1;
+
+      TP->buffer_hp(20,5);
+      TP->buffer_sp(80,10);
+      heilung--;
+      write(BS("Du fuehlst langsam, wie Deine Kraefte zurueckkehren."));
+
+      return 1;
+    }
+
+    reset()
+    {
+      heilung=1;
+      ::reset();
+    }
+
+    Es wird durch eat_food getestet, ob der Spieler noch genuegend essen kann.
+    Wenn ja, kriegt unser Held die 25 automatisch oben drauf und ausserdem
+    20 LP in 5-LP-Schritten und 80 KP in 10-LP-Schritten gutgeschrieben.
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  heal_self, restore_spell_points, restore_hit_points, 
+                buffer_sp
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Props:     P_SP, P_HP,
+     Konzepte:  heilung
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/buffer_sp.rst b/doc/sphinx/lfun/buffer_sp.rst
new file mode 100644
index 0000000..6eb83ac
--- /dev/null
+++ b/doc/sphinx/lfun/buffer_sp.rst
@@ -0,0 +1,65 @@
+buffer_sp()
+===========
+
+FUNKTION
+--------
+::
+
+    int buffer_sp( int val, int rate );
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+    val:  Gesamte Heilung.
+    rate: KP-Rate.
+
+        
+
+BESCHREIBUNG
+------------
+::
+
+    Erhoeht die KP eines Spielers automatisch insgesamt um den Wert "val".
+    Pro heart_beat() wird ihm dabei der Wert "rate" zugefuehrt.
+    Sollen neben P_SP noch weitere Props manipuliert werden - bspw. zur
+    P_FOOD - bietet sich die Funktion consume() an.
+
+RUECKGABEWERTE
+--------------
+::
+
+    Der getankte Wert pro heart_beat().
+
+BEMERKUNG
+---------
+::
+
+    Sollte von jeder tragbaren Heilung genutzt werden, welche den Spieler
+    darauf schliessen lassen kann, auf natuerlichem und nichtmagischem Weg
+    (Essen, Trinken) geheilt worden zu sein.
+
+BEISPIEL
+--------
+::
+
+    s. Bsp. zu "buffer_hp"
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  heal_self, restore_spell_points, restore_hit_points, 
+                buffer_hp
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Props:     P_SP, P_HP,
+     Konzepte:  heilung
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/buy_obj.rst b/doc/sphinx/lfun/buy_obj.rst
new file mode 100644
index 0000000..1aeab6c
--- /dev/null
+++ b/doc/sphinx/lfun/buy_obj.rst
@@ -0,0 +1,66 @@
+buy_obj()
+=========
+
+FUNKTION
+--------
+::
+
+	static string buy_obj(mixed ob, int short);
+
+DEFINIERT IN
+------------
+::
+
+	/std/shop.c
+
+ARGUMENTE
+---------
+::
+
+	ob - der Gegenstand bei dem geprueft werden soll, ob der Laden ihn
+	     an this_player() verkauft. Sollte es sich hierbei um ein
+	     FixedObject handeln, wird ein String uebergeben, ansonsten ein
+	     object.
+        short - Bisher noch nicht in Benutzung. Aber fuer die Zukunft
+             vorgesehn, falls man mehrere Objekte auf einmal kauft.
+             Ein auswerten ist keine Pflicht, waere aber praktisch, damit
+             der Scroll dabei nicht zu gross wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+        Ein String was der Haendler sagen soll wieso der Gegenstand nicht
+	verkauft wird. Der String wird dabei wie folgt umgebrochen:
+        break_string(str, 78, Name(WER, 1)+" sagt: ")
+
+BESCHREIBUNG
+------------
+::
+
+	Durch ueberschreiben dieser Funktion ist es moeglich bestimmte
+	Objekte (wie z.b. Questobjekte) nur an ausgewaehlte Spieler zu
+	verkaufen). Aber auch abfragen ob der Laden ueberhaupt mit
+	this_player() handelt, sind moeglich.
+
+BEISPIELE
+---------
+::
+
+	static string buy_obj(mixed ob, int short)
+	{
+	   if (PL->QueryProp(P_RACE)=="Zwerg")
+	      return "Ich verkaufe nichts an Zwerge!";
+	   return ::buy_obj(ob, short);
+	}
+
+SIEHE AUCH
+----------
+::
+
+	sell_obj(), AddFixedObject(), RemoveFixedObject(), SetStorageRoom(),
+        /std/shop.c
+
+
+Last modified: Thu Mar 4 15:26:13 1999 by Padreic
+
diff --git a/doc/sphinx/lfun/catch_msg.rst b/doc/sphinx/lfun/catch_msg.rst
new file mode 100644
index 0000000..481905b
--- /dev/null
+++ b/doc/sphinx/lfun/catch_msg.rst
@@ -0,0 +1,26 @@
+catch_msg()
+===========
+
+SYNOPSIS
+--------
+::
+
+    void catch_msg(mixed *arr, object obj)
+
+DESCRIPTION
+-----------
+::
+
+    When say(), tell_object()  or tell_room() are used with an array 
+    as message, the array will be passed to catch_message() in all living
+    objects that can hear it, instead of writing to the user resp.
+    sending to catch_tell(). This can be used to implement
+    communication protocols between livings. The second denotes
+    the object that has sent the message.
+
+SEE ALSO
+--------
+::
+
+ say(E), tell_room(E), tell_object(E), catch_tell(L)
+
diff --git a/doc/sphinx/lfun/catch_tell.rst b/doc/sphinx/lfun/catch_tell.rst
new file mode 100644
index 0000000..d5725bc
--- /dev/null
+++ b/doc/sphinx/lfun/catch_tell.rst
@@ -0,0 +1,36 @@
+catch_tell()
+============
+
+SYNOPSIS
+--------
+::
+
+	void catch_tell(string)
+
+DESCRIPTION
+-----------
+::
+
+	When a message is sent to a noninteractive player, via say(),
+	tell_object, tell_room(), printf() or write(), it will get to the
+	function catch_tell(string). This will enable communications between
+	NPCs and from a player to an NPC.
+
+	Also, if an interactive object is being shadowed and the
+	shadow has catch_tell() defined, it will receive all output
+	that would otherwise be written to the user.
+
+	If a message is sent by an interactive object, catch_tell() is
+	not called in that object, to prevent recursive calls. Thus
+	catch_tell() in interactive objects can be used to filter the
+	output that goes to the users.
+
+	The efun shout() sends to interactive objects only.
+
+SEE ALSO
+--------
+::
+
+	enable_commands(E), say(E), tell_object(E), tell_room(E),
+	write(E), catch_msg(L) 
+
diff --git a/doc/sphinx/lfun/check_and_update_timed_key.rst b/doc/sphinx/lfun/check_and_update_timed_key.rst
new file mode 100644
index 0000000..47f6bf0
--- /dev/null
+++ b/doc/sphinx/lfun/check_and_update_timed_key.rst
@@ -0,0 +1,117 @@
+check_and_update_timed_key()
+============================
+
+FUNKTION
+--------
+::
+
+       public int check_and_update_timed_key(int duration, string key)
+
+       
+
+DEFINIERT IN
+------------
+::
+
+       /std/living/life.c    
+
+ARGUMENTE
+---------
+::
+
+       int duration: In wieviel Sekunden wird <key> wieder freigebeben,
+                     (z.B. wann kann der Spieler an dieser Stelle eine neue 
+                     Heilung bekommen).
+       string key  : Eindeutiger Name, wird zusammen mit <duration>
+                     gespeichert.
+
+BESCHREIBUNG
+------------
+::
+
+       Diese Funktion hat die Aufgabe, Zeitsperren verschiedenster Art
+       einfach zu ermoeglichen (z.B. die Realisierung charakter-abhaengiger
+       Heilstellen u.ae.).
+
+       <key> muss eindeutig sein, am besten verwendet man den eigenen
+       Magiernamen (und ggf. nen Gebietsnamen) als Teil des Strings.
+
+       Die Funktion ist definiert in /std/living/life.c. Somit funktioniert
+       sie auch bei NPCs. Die Daten werden in P_TIMING_MAP gespeichert, sind
+       also gegen "ende" resistent. (werden allerdings nach Ablauf ggf.
+       'aufgeraeumt')
+
+       Das Mapping P_TIMING_MAP ist NICHT zur Abfrage und / oder Manipulation
+       'per Hand' vorgesehen.
+
+RUeCKGABEWERT
+-------------
+::
+
+       0    Irgendein Fehler im Aufruf, evtl. existiert die Funktion (noch)
+            nicht im jew. Objekt.
+
+      -1    Alles okay. Neuer Zeitpunkt wird automatisch gespeichert. In
+            diesem Fall darf der Spieler geheilt werden.
+
+      >0    Key noch gesperrt, in dem Fall darf also nicht geheilt werden. 
+            Der Rueckgabewert ist der Zeitpunkt, ab dem <key> wieder frei ist,
+            laesst sich daher dazu nutzen, um dem Spieler einen Anhaltspunkt
+            zu geben, wann er die Stelle wieder nutzen kann, etwa:
+
+            "Die Schale ist erst halb voll, Du musst noch etwas warten."
+
+BEISPIELE
+---------
+::
+
+       Eine Heilstelle soll jedem Spieler alle 5min zur Verfuegung stehen:
+
+       AddCmd(({"trink","trinke"}),"trink_cmd");
+
+       int trink_cmd(string str){
+         ...
+         ...
+         /*
+         Der key sollte natuerlich eine etwas eindeutigere Kennzeichnung
+         wie etwa "tilly_trinken" bekommen, auch wenn er durch einen
+         anderen (gleichnamigen) nicht ueberschrieben werden kann.
+
+         Trifft diese Abfrage hier zu, kann dem Spieler Heilung o.ae. zu-
+         gefuehrt werden. Die neue Zeit (duration) wird automatisch gesetzt.
+         */
+         if(this_player()->check_and_update_timed_key(300,"jof_trinken")==-1){
+           if(this_player()->drink_soft(2)){
+             this_player()->heal_self(50);
+             write("Du fuehlst Dich sichtlich erfrischt.\n");
+             return 1;
+            }
+           else{
+             write("Du hast schon zuviel getrunken.\n");
+             return 1;
+            }
+          }
+         else {
+           write("Du trinkst und denkst . o O (Hmm, nicht schlecht).\n");
+           return 1;
+          }
+         return 0;
+        }
+
+BEMERKUNGEN: 
+       Auch bei dieser Funktion ist darauf zu achten, dass Properties wie
+       P_FOOD, P_DRINK und P_ALCOHOL beruecksichtigt werden.
+       Heilstellen sind dem zustaendigen Magier fuer Heilungs-Balance zu 
+       melden. Wer dies momentan ist, kann dem Mailalias heilungs_balance
+       entnommen werden.
+
+SIEHE AUCH
+----------
+::
+
+       check_timed_key, eat_food, drink_alcohol, drink_soft, heal_self,
+       restore_spell_points, reduce_hit_point
+
+
+08.01.2012, Zesstra
+
diff --git a/doc/sphinx/lfun/check_restrictions.rst b/doc/sphinx/lfun/check_restrictions.rst
new file mode 100644
index 0000000..b764a5d
--- /dev/null
+++ b/doc/sphinx/lfun/check_restrictions.rst
@@ -0,0 +1,173 @@
+check_restrictions()
+====================
+
+FUNKTION
+--------
+::
+
+    string check_restrictions(object pl, mapping restr)
+
+DEFINIERT IN
+------------
+::
+
+    /std/restriction_checker.c
+
+ARGUMENTE
+---------
+::
+
+    object pl        geprueftes Lebewesen
+    mapping restr    Mapping mit Restriktionen, s.u.
+
+BESCHREIBUNG
+------------
+::
+
+    Die Methode wird verwendet, um Restriktionen (zum Beispiel fuer das
+    Casten eines Spells) zu pruefen. Sie wird von Spellbook und
+    Gildenobjekt direkt genutzt.
+
+    Ihr wird dabei ein Spielerobjekt sowie ein Mapping mit den jeweiligen
+    Restriktionen uebergeben. Die aktuell moeglichen Keys des Mappings sind
+    weiter unten gelistet.
+
+BEMERKUNGEN
+-----------
+::
+
+    Es wird bei der Rasse P_REAL_RACE geprueft. Der Tarnhelm funktioniert
+    also nicht.
+
+    Bei Erweiterungsvorschlaegen wendet euch bitte an einen EM oder
+    inheritet im Zweifelsfall nach Absprache.
+    NIEMALS solchen Code einfach KOPIEREN. Spaeter muss nur irgendwer
+    eurem alten Code hinterherraeumen.
+
+Aktuelle Liste der pruefbaren Parameter:
+    P_LEVEL
+      Mindeststufe, die das Lebewesen besitzen muss, um die Aktion
+      auszufuehren.
+    P_GUILD_LEVEL
+      Gildenlevel, das das Lebewesen mindestens erreicht haben muss, um die
+      Aktion auszufuehren.
+    SR_SEER
+      Ist gesetzt, wenn das Lebewesen Seher sein muss.
+      Auswertung nur fuer Interactives, NSC ignorieren das Flag.
+    P_XP
+      Mindestmenge an Erfahrungspunkten, die ein Lebewesen besitzen muss,
+      um die Aktion auszufuehren.
+    P_QP
+      Mindestmenge an Abenteuerpunkten, die das Lebewesen haben muss.
+    P_ALCOHOL
+      Menge an Alkohol, unter der der Alkoholspiegel des Lebewesen liegen
+      muss, um die Aktion noch ausfuehren zu koennen.
+    P_DRINK
+      Menge an Fluessigkeit, unter der der Fluessigkeitsspiegel des
+      Lebewesen liegen muss, um die Aktion noch ausfuehren zu koennen.
+    P_FOOD
+      Beinhaltet die Menge an Nahrung, unter der der Nahrungsspiegel des
+      Spielers liegen muss, um die Aktion noch ausfuehren zu koennen.
+    P_DEAF
+      Ist gesetzt, falls der Spieler nicht taub sein darf.
+    P_FROG
+      Ist gesetzt, falls der Spieler kein Frosch sein darf.
+    P_BLIND
+      Ist gesetzt, falls der Spieler nicht blind sein darf.
+      Achtung: das ist nicht gleichbedeutend mit dem Umstand, dass er evtl.
+      nichts mehr sehen kann. Auch andere Gruende (zum Beispiel Dunkelheit)
+      koennen bewirken, dass ein Spieler nichts mehr sieht.
+    A_INT, A_DEX, A_CON, A_STR
+      Jeweilige Mindesthoehe eines Attribut, um eine Aktion ausfuehren zu
+      koennen.
+    SR_BAD, SR_GOOD
+      Gibt an, wie [minimal] boese bzw. wie [maximal] gut ein Charakter sein
+      darf, um eine Aktion ausfuehren zu koennen.
+    SR_MIN_SIZE, SR_MAX_SIZE
+      Gibt die minimale, bzw. die maximale Groesse an, die ein Charakter
+      maximal haben darf, um eine Aktion ausfuehren zu koennen.
+    SR_FREE_HANDS
+      Gibt an, wieviele freie Haende ein Charakter fuer diese Aktion
+      besitzen muss.
+    SR_EXCLUDE_RACE
+      Mitglieder aller in dieser Liste aufgefuehrten Rassen koennen
+      diese Aktion nicht ausfuehren.
+    SR_INCLUDE_RACE
+      Mitglieder aller NICHT in dieser Liste aufgefuehrten Rassen koennen
+      diese Aktion nicht ausfuehren.
+    SM_RACE
+      Hier kann pro Rasse ein Mapping mit besonderen (nur) fuer diese Rasse
+      geltenden Einschraenkungen vorgenommen werden. Als Keys sind die
+      in dieser Manpage beschriebenen Keys erlaubt, wobei SM_RACE nicht
+      rekursiv ausgewertet wird.
+      Der Rassenname ist gross geschrieben und "*" steht fuer alle Rassen.
+    SR_EXCLUDE_GUILD
+    SR_INCLUDE_GUILD
+      Diese beiden Keys verhalten sich wie SR_*_RACE, nur dass hier Gilden
+      genannt werden.
+    SR_FUN
+      Hier kann eine Funktion in verschiedenen Formen zum Pruefen der
+      Restriktionen angegeben werden, siehe execute_anything().
+      Das kann nuetzlich sein, um andere Restriktionen zu pruefen,
+      wie das Bestehen von Miniquests oder andere Faehigkeiten/Flags.
+      Ist der Test nicht bestanden, gibt die Funktion einen String zurueck.
+    SR_PROP
+      Hier kann ein Mapping mit Properties und zugehoerigen Werten angegeben
+      werden, die jeweils auf Identitaet geprueft werden. Zusaetzlich sollte
+      eine Meldung angegeben werden, die als Fehlermeldung ausgegeben wird,
+      wenn der Spieler die Bedingung nicht erfuellt. Es sollte immer eine
+      passende Meldung fuer den Spieler eingebaut werden. Beispiel:
+      ([ SR_PROP: ([P_AUSGANG_ENTDECKT: 1; "Dein Schwert fluestert "
+          "veraergert: Ich werde Dir erst dann zu Diensten sein, wenn Du "
+          "Dich als wuerdig erwiesen hast!"]) ])
+      Aufgrund der Meldung wird empfohlen, SR_PROP nicht in Restriktionen
+      einzusetzen, die massenweise in Savefiles landen (z.B.
+      Spielersavefiles).
+    SR_QUEST
+      Hier kann ein String-Array mit den Namen (Keys) der Quest(s) angegeben
+      werden, die der Spieler bestanden haben muss, um die Aktion ausfuehren
+      zu koennen.
+    SQ_MINIQUEST
+      Hier kann entweder ein String-Array mit den Ladenamen der vergebenden
+      Objekte oder ein Int-Array mit den Index-Nummern (IDs) der
+      Miniquest(s) (empfohlen!) angegeben werden, die der Spieler bestanden
+      haben muss, um die Aktion ausfuehren zu koennen.
+
+BEISPIELE
+---------
+::
+
+    // #1 Levelbeschraenkung in der Abenteurergilde
+    AddSpell("feuerball",20,
+             ([SI_SKILLRESTR_LEARN:([P_LEVEL:15]), ...
+
+    // #2 Glaubenstest im Klerus
+    AddSpell("bete",
+             ([SI_SKILLRESTR_LEARN: ([P_GUILD_LEVEL : LVL_NOVIZE,
+                                      SR_FUN : #'glaubensTest ]), ...
+    // mit
+    static string glaubensTest(object pl) {
+      if (pl->QueryProp(K_STRENGTH) < 8000)
+        return ("Deine Glaubensstaerke laesst zu wuenschen uebrig!\n");
+      return 0;
+    }
+
+    // #3 SM_RACE-Modifikation der Restriktionen:
+    //    haertere Restriktionen fuer Zwerge
+    //    - hoeheres Level
+    //    - zusaetzlich A_STR pruefen
+    ([P_LEVEL:15,
+      A_INT:10,
+      SM_RACE: (["Zwerg": ([P_LEVEL:17, A_STR:20])])])
+    // ist identisch zu
+    ([SM_RACE: (["*":     ([P_LEVEL:15, A_INT:10]),
+                 "Zwerg": ([P_LEVEL:17, A_INT:10, A_STR:20])])])
+
+SIEHE AUCH
+----------
+::
+
+    execute_anything(L), AddSpell (Gilde), P_RESTRICTIONS
+
+03. Januar 2014, Arathorn
+
diff --git a/doc/sphinx/lfun/check_timed_key.rst b/doc/sphinx/lfun/check_timed_key.rst
new file mode 100644
index 0000000..9533cea
--- /dev/null
+++ b/doc/sphinx/lfun/check_timed_key.rst
@@ -0,0 +1,55 @@
+check_timed_key()
+=================
+
+FUNKTION
+--------
+::
+
+       public int check_timed_key(string key)
+
+       
+
+DEFINIERT IN
+------------
+::
+
+       /std/living/life.c    
+
+ARGUMENTE
+---------
+::
+
+       string key  : Eindeutiger Name
+
+BESCHREIBUNG
+------------
+::
+
+       Diese Funktion hat die Aufgabe, mittels check_and_update_timed_key()
+       gespeicherte Zeitsperren zu pruefen, aber dabei nicht zu veraendern.
+
+       Es MUSS bei der eigentlichen Aktion (z.B. Heilung des Spielers) der
+       Rueckgabewert von check_and_update_timed_key() beruecksichtigt werden,
+       sollte dieses nicht -1 geliefert haben, MUSS <key> als gesperrt
+       betrachtet werden, d.h. check_timed_key() hat nur informativen
+       Charakter.
+
+RUeCKGABEWERT
+-------------
+::
+
+       0    Die Zeitsperre <key> ist abgelaufen.
+
+       >0   <key> ist noch gesperrt.
+            Der Rueckgabewert ist der Zeitpunkt, ab dem <key> wieder frei ist,
+
+SIEHE AUCH
+----------
+::
+
+       check_and_update_timed_key, eat_food, drink_alcohol, drink_soft,
+       heal_self, restore_spell_points, reduce_hit_point
+
+
+08.01.2012, Zesstra
+
diff --git a/doc/sphinx/lfun/clean_up.rst b/doc/sphinx/lfun/clean_up.rst
new file mode 100644
index 0000000..26d1022
--- /dev/null
+++ b/doc/sphinx/lfun/clean_up.rst
@@ -0,0 +1,67 @@
+clean_up()
+==========
+
+FUNKTION
+--------
+::
+
+     int clean_up(int ref);
+
+DEFINIERT IN
+------------
+::
+
+     /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!)
+
+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.
+
+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.
+
+     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.
+
+BEMERKUNGEN
+-----------
+::
+
+     Standardmaessig definieren nur Raeume clean_up().
+
+     Die Zeiten zwischen zwei Aufrufen von clean_up() betragen momentan
+     einen Tag (86400 Sekunden).
+
+SIEHE AUCH
+----------
+::
+
+     reset(), P_NEVER_CLEAN
+     memory
+
+21. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/cmd_shoot.rst b/doc/sphinx/lfun/cmd_shoot.rst
new file mode 100644
index 0000000..a8b11d5
--- /dev/null
+++ b/doc/sphinx/lfun/cmd_shoot.rst
@@ -0,0 +1,54 @@
+cmd_shoot()
+===========
+
+FUNKTION
+--------
+::
+
+    static int cmd_shoot(string str)
+
+DEFINIERT IN
+------------
+::
+
+    /std/ranged_weapon.c
+
+ARGUMENTE
+---------
+::
+
+    string str    - Schusssyntax
+
+BESCHREIBUNG
+------------
+::
+
+    Kommandofunktion der Fernwaffe. Enthaelt die Vorbereitung und den Schuss.
+
+BEMERKUNGEN
+-----------
+::
+
+    Ist in der Fernwaffe mit AddCmd( ({"schiess", "schiesse"}), "cmd_shoot");
+    angebunden. Will man eine andere Syntax haben, kann man mit
+    AddCmd/RemoveCmd diese umsetzen.
+
+BEISPIELE
+---------
+::
+
+    RemoveCmd(({"schiess", "schiesse"})); // entferne Default-Kommando
+    AddCmd(({"schleuder", "schleudere"}), #'cmd_shoot);
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
+    Methoden:  shoot_dam(L), cmd_shoot(L)
+    Kommandos: AddCmd(L), RemoveCmd(L)
+    Syntax:    _unparsed_args(L)
+    Sonstiges: fernwaffen
+
+28.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/lfun/command_me.rst b/doc/sphinx/lfun/command_me.rst
new file mode 100644
index 0000000..df3eaf3
--- /dev/null
+++ b/doc/sphinx/lfun/command_me.rst
@@ -0,0 +1,110 @@
+command_me()
+============
+
+FUNKTION
+--------
+::
+
+    int command_me(string str)
+
+ARGUMENTE
+---------
+::
+
+    string str - auszufuehrendes Kommando
+
+DEFINIERT IN
+------------
+::
+
+    /std/npc.c, /std/player/command.c
+
+BESCHREIBUNG
+------------
+::
+
+    Fuehrt 'str' wie ein Kommando aus, welches direkt vom Living
+    abgegeben wurde.
+
+    Der Rueckgabewert ist >=1 fuer Erfolg und 0 fuer Misserfolg. 
+    Rueckgabewert ist im Erfolgsfall die Hoehe der EvalCost in Ticks. 
+
+    command_me() leitet den Befehl an command()(E) weiter und erlaubt
+    dadurch auch den Aufruf von sonst durch "static", "protected" oder
+    "private" vor externem Aufruf geschuetzten Kommando-Funktionen.
+
+    Kommandos mit oeffentlichen Kommandofunktionen (also damit alle mit
+    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)
+
+BEISPIEL
+--------
+::
+
+    (Code des Testraum ist in /doc/beispiele/testobjekte/command_me_testraum)
+    // #1: Testraum, zwinge Spieler bei "schleiche heran" zum Furzen
+    //     command_me() ist hier noetig, da das Furzen eine geschuetzte
+    //     Kommandofunktion hat
+    inherit "/std/room";
+
+    void create() {
+      ::create();
+      AddCmd("schleiche&heran|herum", "action_schleichen");
+    }
+
+    
+
+    void init() {
+      ::init();
+      add_action("action_kriechen", "kriech", 1);
+    }
+
+    static int action_schleichen(string str) {
+      string tmp = this_player()->QueryProp(P_RACE);
+      // ... 
+      if(tmp[<1]=='e') tmp=tmp[0..<2];
+      write(break_string("Du versuchst leise zu schleichen, dabei passiert "
+        "dir aber ein allzu "+
+        (tmp=="Mensch"?"menschliches":lower_case(tmp)+"isches")+
+        " Missgeschick. Verflucht!", 78));
+      this_player()->command_me("\\furze");
+      return 1;
+    }
+
+    
+
+    static int action_kriechen(string str) {
+      write(break_string("Deine Knie tun zu sehr weh dafuer.", 78));
+      tell_room(this_object(), break_string(this_player()->Name(WER)+
+        " knackt mit den Knien.", 78));
+      return 1;
+    }
+
+    
+
+    // #2 (in obigem Raum): zwinge Spieler in Raum zu obigem Kommando
+    //    Beide Kommandos gelingen, da Kommando mit AddCmd definiert.
+    find_player("naddl")->command_me("schleiche herum")
+    command("schleiche herum", find_player("naddl")); 
+
+    // #3 (in obigem Raum): zwinge Spieler in Raum zu obigem Kommando
+    find_player("naddl")->command_me("krieche")
+    //    Folgendes Kommando schlaegt fehl, da Kommandofunktion static ist.
+    command("krieche", find_player("naddl"));
+
+    
+
+SIEHE AUCH
+----------
+::
+
+     enable_commands(E), command(E)
+
+06 Sep 2012 Gloinson
+
diff --git a/doc/sphinx/lfun/consume.rst b/doc/sphinx/lfun/consume.rst
new file mode 100644
index 0000000..25ab213
--- /dev/null
+++ b/doc/sphinx/lfun/consume.rst
@@ -0,0 +1,115 @@
+consume()
+=========
+
+public varargs int consume(mapping cinfo, int testonly)
+
+FUNKTION
+--------
+::
+
+    public varargs int consume(mapping cinfo, int testonly);
+
+    Aenderung der Gesundheit eines Lebewesens durch etwas Konsumierbares.
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+    cinfo
+        Mapping mit Informationen ueber die Gesundheitsaenderung
+        Heilung.
+    testonly
+        Gibt an, ob nur die Bedingungen abgetestet werden sollen,
+        oder auch die Wirkung eintreten soll.
+
+RUECKGABEWERT
+-------------
+::
+
+    1 erfolgreich konsumiert
+    0 keine oder falsche Aenderungsdaten in cinfo (nicht benutzbar)
+   <0 Bedingung fuer konsumieren nicht erfuellt, Bitset aus:
+      HC_MAX_FOOD_REACHED    - Kann nichts mehr essen
+      HC_MAX_DRINK_REACHED   - Kann nichts mehr trinken
+      HC_MAX_ALCOHOL_REACHED - Kann nichts mehr saufen
+      HC_HOOK_CANCELLETION   - durch H_HOOK_CONSUME abgebrochen
+
+BESCHREIBUNG
+------------
+::
+
+    Die Funktion stellt eine Moeglichkeit zur Verfuegung, die Aenderung
+    der Gesundheit eines Lebewesens beim Konsumieren von irgendetwas (z.B in
+    einer Kneipe, durch eine Heilstellte oder tragbare Tanke, ...) zentral zu
+    erledigen. Sie vereint in sich die Pruefung auf Durchfuerbarkeit der
+    Aenderung und Anwendung der Aenderung.
+
+    Der erste Parameter gibt die Eigenschaften der Aenderung an, der zweite ob
+    ausschliesslich die Pruefung auf Anwendbarkeit erfolgen soll.
+
+    Das Mapping cinfo hat folgende Struktur:
+    a) Einfache Angabe der betroffenen Properties. In neuem Code bitte nicht
+       machen, dort ein Mapping wie unter b) beschrieben nutzen!
+
+    b) Strukturiert in Effekte und Bedingungen mit folgenden Schluesseln:
+      H_EFFECTS - Mapping der zu aendernden Properties mit dem Umfang der
+                  Aenderung, erlaubte Properties siehe H_ALLOWED_EFFECTS
+
+      H_CONDITIONS - Mapping der zu pruefenden Properties mit dem Umfang der
+                     Aenderung, erlaubte Properties siehe H_ALLOWED_CONDITIONS
+
+      H_DISTRIBUTION - Verteilung der Aenderung fuer P_SP, P_HP
+                       HD_INSTANT bzw. 0: instante Heilung
+                       1 - 50: angebene Zahl pro Heartbeat
+                       HD_STANDARD: 5 pro Heartbeat
+
+    Aenderungen koennen sowohl positiv als auch negativ sein.
+
+BEMERKUNGEN
+-----------
+::
+
+    Hierbei aber bitte beachten, dass Tanken/Entanken sowie Heilungen ggf. von
+    der (Heilungs-)Balance genehmigt werden muessen!
+
+BEISPIELE
+---------
+::
+
+    Heilung um 100 KP, 50 LP, aber nur wenn 30 P_FOOD gegessen werden kann:
+
+    consume( ([H_EFFECTS: ([P_HP:50, P_SP:100]),
+               H_CONDITIONS: ([P_FOOD:30]) ]) );
+
+    Heilung um 100 KP und Vergiftung um 2, wenn 15 Alkohol getrunken werden
+    koennen. Die SP werden zeitverzoegert mit 10 pro Heartbeat zugefuehrt.
+
+    consume(([H_EFFECTS: ([P_SP: 100, P_POISON: 2]),
+              H_CONDITIONS: ([P_ALCOHOL: 15]),
+              H_DISTRIBUTION: 10]) )
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  drink_alcohol, eat_food, drink_soft
+     Heilung:   heal_self, restore_spell_points, restore_hit_points, 
+                buffer_hp, buffer_sp
+     Timing:    check_and_update_timed_key
+     Enttanken: defuel_drink, defuel_food
+     Props:     P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    29.05.2015, Boing
+
diff --git a/doc/sphinx/lfun/create.rst b/doc/sphinx/lfun/create.rst
new file mode 100644
index 0000000..c89fa17
--- /dev/null
+++ b/doc/sphinx/lfun/create.rst
@@ -0,0 +1,104 @@
+create()
+========
+
+FUNKTION
+--------
+::
+
+     protected void create();
+     void create();
+
+DEFINIERT IN
+------------
+::
+
+     allen Standardobjekten
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird aufgerufen, wenn ein Objekt geladen oder geclont
+     wird.
+     In dieser Funktion wird das Objekt initialisiert und konfiguriert.
+     Waehrend des create() kann es einen this_player()/this_interactive()
+     geben, muss aber nicht!
+     Im create() hat das Objekt noch kein environment().
+     create() wird nur gerufen, wenn das Objekte geclont oder explizit geladen
+     wird. Wenn es aufgrund eines inherit in einem anderen Objekt vom Driver
+     geladen wird, wird das create() nicht ausgefuehrt (s. create_super()).
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Erbt man von anderen Objekten, so besteht die erste Aktion innerhalb
+     von create() normalerweise darin, in diesen Objekten create()
+     aufzurufen.
+     Die Funktion kann protected oder static sein (aber nicht private). Es
+     duerfte fuer die meisten Objekte sinnvoll sein, create() protected zu
+     deklarieren.
+
+     Um Speicher zu sparen, kann man bei Blueprints von der Konfigurierung
+     absehen (siehe Beispiel). Dies sollte man allerdings nicht bei Objekten
+     machen, von denen keine Clones erzeugt werden sollen (zB. bei Raeumen). 
+
+     Man sollte bei Abbruch des create() in BP unbedingt set_next_reset(-1);
+     rufen, da sonst die (nicht konfigurierte) BP resetten kann und dann
+     buggt.
+
+BEISPIELE
+---------
+::
+
+     Ein Gegenstand wuerde wie folgt konfiguriert:
+
+     inherit "std/thing";
+
+     #include <properties.h>
+
+     create()
+     {
+       // Wenn wir die Blueprint sind: NICHT konfigurieren!
+       // Bei normalen Raeumen oder Transportern sind diese beiden
+       // Zeilen wegzulassen!!!
+       if (!clonep(this_object())) {
+           set_next_reset(-1);    // wichtig, damit die BP nicht resettet.
+           return;
+       }
+
+       // Ansonsten die allgemeinen Eigenschaften von /std/thing
+       // konfigurieren...
+       ::create();
+
+       // ...und nun unsere speziellen Eigenschaften:
+       SetProp(P_NAME, "Muell");
+       SetProp(P_SHORT, "Muell");
+       SetProp(P_LONG, "Voellig unnuetzer Muell!\n");
+       SetProp(P_ARTICLE, 0);
+       SetProp(P_VALUE, 0);
+       SetProp(P_GENDER, MALE);
+     }
+
+SIEHE AUCH
+----------
+::
+
+     create(L), reset(L)
+     hook(C), create(H), create_ob(H), create_super(H, reset(H)
+     create(A), reset(A)
+
+22.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/create_default_npc.rst b/doc/sphinx/lfun/create_default_npc.rst
new file mode 100644
index 0000000..8507388
--- /dev/null
+++ b/doc/sphinx/lfun/create_default_npc.rst
@@ -0,0 +1,76 @@
+create_default_npc()
+====================
+
+FUNKTION
+--------
+::
+
+     varargs void create_default_npc( int level, int maxhp );
+
+BENUTZUNG
+---------
+::
+
+     inherit "std/npc";
+
+FUNKTION
+--------
+::
+
+     Setze die Daten eines Monsters auf einen gewissen Level.
+
+     Der Level sollte zwischen 1 und 20 liegen. Die Stats werden auf diesen
+     Level gesetzt und mehrere andere Werte, so dass das Monster von der
+     Staerke her einem Spieler gleichen Levels entspricht.
+
+     Wird der (optionale) Parameter maxhp weggelassen, wird dieser berechnet
+     nach:
+          maxhp = 42 + 8 * level
+
+     Die genauen Werte sind:
+          P_LEVEL : level
+          P_MAX_HP: maxhp
+          P_MAX_SP: maxhp
+          P_HANDS : 10 * level
+          P_BODY  : (20/3) * level
+          P_XP    : 50 * level * maxhp (== 5 * P_HANDS * max_hp)
+
+          A_STR, A_INT, A_DEX, A_CON : level
+
+BEMERKUNG
+---------
+::
+
+     Diese Funktion sollte nur im create() eines Monsters benutzt werden.
+     Oben beschriebene Werte, die vor dem Aufruf der Funktion gesetzt
+     wurden, werden durch die neuen Werte ersetzt.
+
+     Ab einem Aufruf mit Level 20 werden P_XP = 202000 gesetzt, also ein
+     Kill-Stup vergeben (siehe P_XP).
+
+BEISPIEL
+--------
+::
+
+     create_default_npc(17) ergibt:
+
+          P_LEVEL : 17
+          P_MAX_HP: 178
+          P_MAX_SP: 178
+          P_HANDS : 170
+          P_BODY  : 113
+          P_XP    : 151300
+
+          A_STR, A_INT, A_DEX, A_CON : 17
+
+SIEHE AUCH
+----------
+::
+
+     Funktionen:  AddExp(), GiveKillScore()
+     Properties:  P_XP
+                  P_LEVEL, P_MAX_HP, P_MAX_SP, P_HANDS, P_BODY
+     Sonstiges:   npcs
+
+14.Feb 2007 Gloinson
+
diff --git a/doc/sphinx/lfun/create_super.rst b/doc/sphinx/lfun/create_super.rst
new file mode 100644
index 0000000..79e3b9d
--- /dev/null
+++ b/doc/sphinx/lfun/create_super.rst
@@ -0,0 +1,77 @@
+create_super()
+==============
+
+FUNKTION
+--------
+::
+
+     protected void create_super();
+
+DEFINIERT IN
+------------
+::
+
+     allen Standardobjekten
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird immer dann aufgerufen, wenn ein Objekt implizit durch
+     ein 'inherit' in einem erbenden Objekte geladen wird.
+     Normalweise muss man dieses so geladene Objekte nicht konfigurieren, weil
+     nur das Programm dieses Objektes fuer die erbenden Objekte interessant
+     ist, nicht seine Daten.
+     Was hier aber z.B. sinnvoll ist, ist das Abschalten des Resets, denn ein
+     Objekt, was nur dazu dient, dass es von anderen geerbt wird, braucht
+     keinen Reset, auch wenn es ein reset() definiert (was in erbenden Objekte
+     benutzt wird).
+     Die create_super() in den Standardobjekten tun momentan genau dieses.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Wenn ihr von /std/ erbt, braucht ihr euch in aller Regel um diese
+     Funktion keine Gedanken machen.
+     Ihr koennt diese Funktion aber in Objekten selber definieren, die nur zum
+     Erben gedacht sind. Dies kann sinnvoll ein, wenn ihr nicht von /std/ erbt
+     und ein reset() im Objekt habt oder was machen wollt, was ueber das
+     Abschalten des Resets hinausgeht.
+
+BEISPIELE
+---------
+::
+
+     Gegeben sei folgende Vererbungskette:
+     /std/room -> /d/inseln/zesstra/stdraum -> /d/inseln/zesstra/raum
+
+     Wird nun 'raum' geladen und 'stdraum' ist noch nicht geladen, wird der
+     Driver implizit von selbst 'stdraum' laden (weil 'raum' das Programm von
+     'stdraum' braucht). Bei diesem Laden wird das create() in 'stdraum' nicht
+     ausgefuehrt, sondern stattdessen create_super().
+
+    
+
+SIEHE AUCH
+----------
+::
+
+     create(L), reset(L)
+     hook(C), create(H), create_ob(H), create_super(H, reset(H)
+     create(A), reset(A)
+
+22.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/defuel_drink.rst b/doc/sphinx/lfun/defuel_drink.rst
new file mode 100644
index 0000000..c094538
--- /dev/null
+++ b/doc/sphinx/lfun/defuel_drink.rst
@@ -0,0 +1,89 @@
+defuel_drink()
+==============
+
+FUNKTION
+--------
+::
+
+    int defuel_drink();
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+    Keine.
+
+        
+
+BESCHREIBUNG
+------------
+::
+
+    Enttankt den Spieler automatisch um einen gewissen Fluessigkeits-Wert,
+    sofern der Spieler ueber einer bestimmten Enttank-Grenze liegt und seit
+    seinem letzten Enttanken eine gewisse Zeit vergangen ist.
+    Alle diese Werte sind rassenabhaengig.
+    Ausserdem wird dem Spieler eine gewisse Menge Alkohol entzogen. Er wird
+    also mit jedem fluessigen Enttanken etwas nuechterner.
+
+    Es ist also NICHT moeglich, Einfluss auf die Menge des Enttankens
+    zu nehmen. Das ist hier so gewollt.
+
+    Hat der Spieler mindestens 
+    * P_DEFUEL_LIMIT_DRINK in P_DRINK
+    kann er alle
+    * P_DEFUEL_TIME_DRINK
+    um
+    * (x=P_DRINK*P_DEFUEL_AMOUNT_DRINK/2) + random(x)
+      (also um (50 bis 100 * P_DRINK) Prozent)
+    enttanken.
+
+RUECKGABEWERTE
+--------------
+::
+
+    DEFUEL_TOO_SOON: -2, wenn Enttankintervallzeiten zu kurz.
+    DEFUEL_TOO_LOW:  -1, wenn Enttankgrenze noch nicht erreicht.
+    NO_DEFUEL:        0, wenn Enttanken nicht noetig war (Spieler war leer)
+    >0, wenn Erfolg (enttankte Wert wird zurueckgegeben).
+
+    (Konstanten kommen aus /sys/defuel.h)
+
+BEMERKUNG
+---------
+::
+
+    Bitte defuel_drink() benutzen und nicht P_DRINK oder P_MAX_DRINK des
+    manipulieren!
+
+    Es gibt keine eigene Methode fuer die Verringerung von P_ALCOHOL.
+
+    Achtung: Nur Toiletten sollten diese Funktion im Spieler aufrufen!
+
+BEISPIEL
+--------
+::
+
+    s. Bsp. zu defuel_food()
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  defuel_food
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Heilung:   heal_self, restore_spell_points, restore_hit_points, 
+                buffer_hp, buffer_sp
+     Timing:    check_and_update_timed_key
+     Props:     P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/defuel_food.rst b/doc/sphinx/lfun/defuel_food.rst
new file mode 100644
index 0000000..a824946
--- /dev/null
+++ b/doc/sphinx/lfun/defuel_food.rst
@@ -0,0 +1,113 @@
+defuel_food()
+=============
+
+FUNKTION
+--------
+::
+
+    int defuel_food();
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+    Keine.
+
+BESCHREIBUNG
+------------
+::
+
+    Enttankt den Spieler automatisch um einen gewissen Essens-Wert,
+    sofern der Spieler ueber einer bestimmten Enttank-Grenze liegt und seit
+    seinem letzten Enttanken eine gewisse Zeit vergangen ist.
+    Alle diese Werte sind rassenabhaengig.
+
+    Es ist also NICHT moeglich, Einfluss auf die Menge des Enttankens
+    zu nehmen. Das ist hier so gewollt.
+
+    Hat der Spieler mindestens 
+    * P_DEFUEL_LIMIT_FOOD in P_FOOD
+    kann er alle
+    * P_DEFUEL_TIME_FOOD
+    um
+    * (x=P_DRINK*P_DEFUEL_AMOUNT_FOOD/2) + random(x)
+      (also um (50 bis 100 * P_FOOD) Prozent)
+    enttanken.
+
+RUECKGABEWERTE
+--------------
+::
+
+    DEFUEL_TOO_SOON: -2, wenn Enttankintervallzeiten zu kurz.
+    DEFUEL_TOO_LOW:  -1, wenn Enttankgrenze noch nicht erreicht.
+    NO_DEFUEL:        0, wenn Enttanken nicht noetig war (Spieler war leer)
+    >0, wenn Erfolg (enttankte Wert wird zurueckgegeben).
+
+    (Konstanten kommen aus /sys/defuel.h)
+
+BEMERKUNG
+---------
+::
+
+    Bitte defuel_food() benutzen und nicht P_FOOD oder P_MAX_FOOD des
+    Spielers manipulieren!
+
+    Achtung: Nur Toiletten sollten diese Funktion im Spieler aufrufen!
+
+BEISPIEL
+--------
+::
+
+    int action_enttanken() {
+      string msg;
+      int val = this_player()->defuel_food();
+
+      switch (val) {
+        case DEFUEL_TOO_SOON:
+          msg = "Du warst doch erst vor kurzem auf Toilette...";
+          break;
+        case DEFUEL_TOO_LOW:
+          msg = "Du versuchst Dich zu entleeren, aber irgendwie will "
+                "das nicht so recht klappen.";
+          break;
+        case NO_DEFUEL:
+          msg = "Du hast seit langem nichts gegessen, wie willst Du dann "
+                "was loswerden koennen?";
+          break;
+        default:
+          string qualifier;
+          int fuzzypercent = (90+random(20)) *
+                             val/this_player()->QueryProp(P_MAX_FOOD);
+          switch(fuzzypercent) {
+            case 0..50:  qualifier = "etwas"; break;
+            case 51..75: qualifier = "enorm"; break;
+            default:     qualifier = "unglaublich"; break;
+          }
+          msg = "Du entleerst Dich "+qualifier"+. Puh, das tat gut!";
+          break;
+      }
+      tell_object(this_player(), break_string(msg, 78));
+      return 1;
+    }
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  defuel_drink
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Heilung:   heal_self, restore_spell_points, restore_hit_points, 
+                buffer_hp, buffer_sp
+     Timing:    check_and_update_timed_key
+     Props:     P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/deregister_modifier.rst b/doc/sphinx/lfun/deregister_modifier.rst
new file mode 100644
index 0000000..48f994c
--- /dev/null
+++ b/doc/sphinx/lfun/deregister_modifier.rst
@@ -0,0 +1,42 @@
+deregister_modifier()
+=====================
+
+FUNKTION
+--------
+::
+
+     void deregister_modifier(object modifier)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/attributes.c
+
+PARAMETER
+---------
+::
+
+     modifier	- Objekt mit P_X_ATTR_MOD oder P_M_ATTR_MOD
+
+BESCHREIBUNG
+------------
+::
+
+     Meldet einen Modifier im Spieler ab. Wird durch RemoveSensitiveObject
+     beziehungsweise beim Ausziehen oder Wegstecken gerufen.
+     Muss nicht direkt gerufen werden. Bei Veraenderungen von Modifikatoren
+     sollte stattdessen UpdateAttributes gerufen werden.     
+
+SIEHE AUCH
+----------
+::
+
+     QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+     SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+     register_modifier(),P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, 
+     P_ATTRIBUTES_MODIFIER, P_X_ATTR_MOD, P_M_ATTR_MOD, 
+     /std/living/attributes.c
+
+13.Jun.2004, Muadib
+
diff --git a/doc/sphinx/lfun/die.rst b/doc/sphinx/lfun/die.rst
new file mode 100644
index 0000000..84feb1d
--- /dev/null
+++ b/doc/sphinx/lfun/die.rst
@@ -0,0 +1,68 @@
+die()
+=====
+
+FUNKTION
+--------
+::
+
+     public varargs void die(int poisondeath,int extern);
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+     int poisondeath
+	  Dieses Flag sollte bei einem Gifttod (P_POISON) gesetzt sein.
+     int extern
+	  Intern.
+
+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.
+
+     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
+     Einfluss nehmen, z.B. koennte ein temporaerer Todesbann-Zauber das
+     Sterben fuer kurze Zeit verhindern.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+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.
+
+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
+
+
+Last modified: Mon May 14 16:20:34 2001 by Patryn
+
diff --git a/doc/sphinx/lfun/doUnwearMessage.rst b/doc/sphinx/lfun/doUnwearMessage.rst
new file mode 100644
index 0000000..c587ab9
--- /dev/null
+++ b/doc/sphinx/lfun/doUnwearMessage.rst
@@ -0,0 +1,47 @@
+doUnwearMessage()
+=================
+
+FUNKTION
+--------
+::
+
+	void doUnwearMessage(object worn_by, int all);
+
+DEFINIERT IN
+------------
+::
+
+	/std/armour/combat.c
+
+ARGUMENTE
+---------
+::
+
+	worn_by
+          Das Lebewesen, dass die Ruestung bisher getragen hat
+        all
+          Wurde "ziehe alles aus"/"ziehe alle ruestungen aus" eingegeben,
+          so ist all gesetzt, ansonsten nicht.
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion gibt beim Ausziehen einer Ruestung die entspr.
+        Meldung an den Traeger und die Umgebung aus.
+
+RUeCKGABEWERT
+-------------
+::
+
+	keiner
+
+SIEHE AUCH
+----------
+::
+
+        doWearMessage(), doWieldMessage(), doUnwieldMessage()
+
+
+Last modified: Sat Jun 26 15:41:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/doUnwieldMessage.rst b/doc/sphinx/lfun/doUnwieldMessage.rst
new file mode 100644
index 0000000..b69d61b
--- /dev/null
+++ b/doc/sphinx/lfun/doUnwieldMessage.rst
@@ -0,0 +1,44 @@
+doUnwieldMessage()
+==================
+
+FUNKTION
+--------
+::
+
+	void doUnwieldMessage(object wielded_by);
+
+DEFINIERT IN
+------------
+::
+
+	/std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+	wielded_by
+          Das Lebewesen, dass die (Parier)Waffe bisher gezueckt hatte.
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion gibt beim Wegstecken einer Waffe die entspr.
+        Meldung an den Benutzer und die Umgebung aus.
+
+RUeCKGABEWERT
+-------------
+::
+
+	keiner
+
+SIEHE AUCH
+----------
+::
+
+        doWearMessage(), doUnwearMessage(), doWieldMessage()
+
+
+Last modified: Sat Jun 26 15:32:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/doWearMessage.rst b/doc/sphinx/lfun/doWearMessage.rst
new file mode 100644
index 0000000..904d50d
--- /dev/null
+++ b/doc/sphinx/lfun/doWearMessage.rst
@@ -0,0 +1,45 @@
+doWearMessage()
+===============
+
+FUNKTION
+--------
+::
+
+	varargs void doWearMessage(int all);
+
+DEFINIERT IN
+------------
+::
+
+	/std/armour/combat.c
+
+ARGUMENTE
+---------
+::
+
+	all
+          Wurde "trage alles"/"trage alle ruestungen" eingegeben, so
+          ist all gesetzt, ansonsten nicht.
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion gibt beim Anziehen einer Ruestung die entspr.
+        Meldung an den Traeger und die Umgebung aus.
+
+RUeCKGABEWERT
+-------------
+::
+
+	keiner
+
+SIEHE AUCH
+----------
+::
+
+        doUnwearMessage(), doWieldMessage(), doUnwieldMessage()
+
+
+Last modified: Sat Jun 26 15:30:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/doWieldMessage.rst b/doc/sphinx/lfun/doWieldMessage.rst
new file mode 100644
index 0000000..5040650
--- /dev/null
+++ b/doc/sphinx/lfun/doWieldMessage.rst
@@ -0,0 +1,43 @@
+doWieldMessage()
+================
+
+FUNKTION
+--------
+::
+
+	void doWieldMessage();
+
+DEFINIERT IN
+------------
+::
+
+	/std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+	keine
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion gibt beim Zuecken einer Waffe die entspr.
+        Meldung an den Benutzer und die Umgebung aus.
+
+RUeCKGABEWERT
+-------------
+::
+
+	keiner
+
+SIEHE AUCH
+----------
+::
+
+        doWearMessage(), doUnwearMessage(), doUnwieldMessage()
+
+
+Last modified: Sat Jun 26 15:33:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/do_damage.rst b/doc/sphinx/lfun/do_damage.rst
new file mode 100644
index 0000000..05bc2f5
--- /dev/null
+++ b/doc/sphinx/lfun/do_damage.rst
@@ -0,0 +1,70 @@
+do_damage()
+===========
+
+do_damage(L)
+
+FUNKTION
+--------
+::
+
+     int do_damage(int dam,mixed enemy);
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+     int dam
+	  Die abzuziehenden Lebenspunkte (HP).
+     object enemy
+	  Das Objekt, welches den Schaden zufuegt.
+
+BESCHREIBUNG
+------------
+::
+
+     Dem Lebewesen werden <dam> HP abgezogen. Falls weniger als 0 HP uebrig
+     bleiben, so stirbt es automatisch mittels die().
+     Ein Lebewesen, welches sich bewegt hat, trifft die ersten Kampfrunden
+     sehr viel schlechter, um Rein-Raus-Attacken zu verhindern. Dieses
+     Vorgehen kann man mittels P_ENABLE_IN_ATTACK_OUT deaktivieren.
+     Lebewesen, welche P_NO_ATTACK gesetzt haben, kann man mit dieser
+     Funktion nicht schaden.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Der tatsaechlich verursachte Schaden.
+
+BEMERKUNGEN
+-----------
+::
+
+     Beim Gegner <enemy>, falls vorhanden, werden XP und ALIGN entsprechend
+     angepasst, im Opfer wird der Gegner in P_KILLER vermerkt, der Kampf wird
+     beendet.
+     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, da Defend() magische
+     Verteidigungen, die der Spieler bei sich hat beruecksichtigt.
+     Es sollte also allein schon aus Fairness gegenueber den Objekten
+     anderer Magier Defend() immer dem direkten reduce_hit_points() oder
+     do_damage() vorgezogen werden. Mittels der Flags in 'spell' kann man
+     sehr viele Parameter beeinflussen.
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt:	Defend(L), reduce_hit_points(L), die(L)
+     Props:	P_NO_ATTACK, P_ENABLE_IN_ATTACK_OUT, P_KILLER
+		P_XP, P_ALIGN
+
+23.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/do_frage.rst b/doc/sphinx/lfun/do_frage.rst
new file mode 100644
index 0000000..99b2cc9
--- /dev/null
+++ b/doc/sphinx/lfun/do_frage.rst
@@ -0,0 +1,42 @@
+do_frage()
+==========
+
+FUNKTION
+--------
+::
+
+     int do_frage(string text)
+
+DEFINIERT IN
+------------
+::
+
+     /std/npc/info.c
+
+ARGUMENTE
+---------
+::
+
+     string str	 - Schluesselwort der Frage
+
+BESCHREIBUNG
+------------
+::
+
+     Bearbeitet ein Schluesselwort, das mit "frage <wen> nach " uebergeben
+     wurde. Gibt entsprechende Antworten formatiert aus.
+
+BEMERKUNGEN
+-----------
+::
+
+     Recht komplex, besser nicht ueberschreiben wenn man es nicht versteht.
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt:  GetInfoArr, AddInfo
+
+31.Mar 2007 Gloinson
+
diff --git a/doc/sphinx/lfun/do_unwear.rst b/doc/sphinx/lfun/do_unwear.rst
new file mode 100644
index 0000000..291b085
--- /dev/null
+++ b/doc/sphinx/lfun/do_unwear.rst
@@ -0,0 +1,57 @@
+do_unwear()
+===========
+
+FUNKTION
+--------
+::
+
+     varargs int do_unwear(string str, int silent);
+
+DEFINIERT IN
+------------
+::
+
+     /std/armour/combat.c
+
+ARGUMENTE
+---------
+::
+
+     str
+          String der normalerweise dem Parameter des "ziehe"-Kommandos
+          entspricht.
+
+     silent
+          1, wenn das Ausziehen ohne Meldungen durchgefuehrt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion stellt fest, ob die Ruestung sich durch str
+     identifizieren laesst und angezogen ist und ruft im Erfolgsfall
+     UnWear(silent) auf.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn alles gut ging, ansonsten 0.
+
+BEMERKUNGEN
+-----------
+::
+
+     Wenn man Ruestungen "von aussen" ausziehen will, sollte man direkt
+     UnWear() verwenden!
+
+SIEHE AUCH
+----------
+::
+
+     do_wear(), UnWear(), RemoveFunc(), InformUnwear(),
+     /std/armour/combat.c
+
+
+Last modified: Sun Jun 27 22:29:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/do_wear.rst b/doc/sphinx/lfun/do_wear.rst
new file mode 100644
index 0000000..32a1b3f
--- /dev/null
+++ b/doc/sphinx/lfun/do_wear.rst
@@ -0,0 +1,47 @@
+do_wear()
+=========
+
+FUNKTION
+--------
+::
+
+     varargs int do_wear(string str, int silent);
+
+DEFINIERT IN
+------------
+::
+
+     /std/armour/combat.c
+
+ARGUMENTE
+---------
+::
+
+     str
+          String, der normalerweise dem Parameter des
+          "ziehe/trage"-Kommandos entspricht.
+     silent
+          1, wenn das Anziehen ohne Meldungen durchgefuehrt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn sich die Ruestung mit "str" identifizieren laesst, wird versucht,
+     sie mittels DoWear() anzuziehen.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn sich die Ruestung anziehen liess, sonst 0.
+
+SIEHE AUCH
+----------
+::
+
+     do_unwear(), DoWear(), WearFunc(), InformWear(), /std/armour/combat.c
+
+
+Last modified: Sun Jun 27 22:31:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/drink_alcohol.rst b/doc/sphinx/lfun/drink_alcohol.rst
new file mode 100644
index 0000000..f468cd3
--- /dev/null
+++ b/doc/sphinx/lfun/drink_alcohol.rst
@@ -0,0 +1,112 @@
+drink_alcohol()
+===============
+
+FUNKTION
+--------
+::
+
+    public varargs int drink_alcohol(int strength, int testonly, string mytext)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+    strength: wird zur aktuellen Saettigung P_ALCOHOL dazu addiert
+    testonly: Ist das Flag gesetzt, wird dem Spieler kein ALCOHOL zugefuehrt.
+              Darf nur zum Testen der Heilstelle verwendet werden und muss
+              im normalen Betrieb auf '0' stehen!
+    mytext: Wer selber einen Text bei Misserfolg ausgeben lassen moechte,
+            darf sich hier was nettes ausdenken.
+            Achtung: Das unterdrueckt nicht die "Nuechtern"-Meldung, die bei
+            negativem strength auftreten kann, wenn P_ALCOHOL wieder 0 ist.
+
+BESCHREIBUNG
+------------
+::
+
+    Es wird geprueft, ob dem Spieler der angegebene Wert fuer 'strength'
+    auf seine aktuelle P_ALCOHOL addiert werden kann oder nicht. Falls
+    das moeglich ist und testonly = 0, wird P_ALCOHOL entsprechend
+    aktualisiert.
+
+    Sollen neben P_ALCOHOL noch weitere Props manipuliert werden - bspw. zur
+    Heilung eines Lebewesens - bietet sich die Funktion consume() an.
+
+RUECKGABEWERT
+-------------
+::
+
+    0 bei [potentiellem] Misserfolg (strength + P_ALCOHOL > P_MAX_ALCOHOL)
+    1 bei [potentiellem] Erfolg
+    * potentiell bezieht sich hier auf Nutzung mit 'testonly' != 0
+
+BEMERKUNG
+---------
+::
+
+    drink_alocohol() bitte anstatt eigener Manipulationen von P_ALCOHOL und
+    P_MAX_ALCOHOL verwenden.
+
+    Achtung: Immer erst VOR einer Heilung ausfuehren und bei Erfolg heilen.
+
+    Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
+    dafuer eingerichteten Funktion check_and_update_timed_key realisiert
+    werden.
+
+BEISPIEL
+--------
+::
+
+    int heilstelle() {
+      if(this_player()->drink_alcohol(10, 0,
+                                      "Du prustest in den Schnaps. "
+                                      "Der passt nicht mehr rein.\n")) {
+        // Platz fuer 10 "Alkohol" war noch, diese sind jetzt bereits addiert
+        // Nachricht an den Spieler:
+        tell_object(this_player(),
+                    break_string("Du trinkst den Schnaps aus.", 78));
+
+        // Nachricht an andere Livings im Raum
+        object ob = first_inventory(environment(this_player()));
+        do {
+          if(living(ob) && ob!=this_player())
+            ob->ReceiveMsg(this_player()->Name()+" trinkt einen Schnaps aus.",
+                           MT_LOOK|MT_LISTEN,
+                           MA_DRINK);
+          ob = next_inventory(ob);
+        } while(ob);
+
+        // Rassenabhaengige Heilung: Sofort oder in Schritten
+        // Tragbare Heilungen sollten auch eher buffer_hp/_sp benutzen.
+        if(this_player()->QueryProp(P_REAL_RACE)=="Schnapsdrossel")
+          this_player()->heal_self(30);
+        else {
+          this_player()->buffer_hp(30,5);
+          this_player()->buffer_sp(30,5);
+        }
+      }
+
+      return 1;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  consume, eat_food, drink_soft
+     Heilung:   heal_self, restore_spell_points, restore_hit_points, 
+                buffer_hp, buffer_sp
+     Timing:    check_and_update_timed_key
+     Enttanken: defuel_drink, defuel_food
+     Props:     P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/drink_soft.rst b/doc/sphinx/lfun/drink_soft.rst
new file mode 100644
index 0000000..58c7d57
--- /dev/null
+++ b/doc/sphinx/lfun/drink_soft.rst
@@ -0,0 +1,111 @@
+drink_soft()
+============
+
+FUNKTION
+--------
+::
+
+    public varargs int drink_soft(int strength, int testonly, string mytext)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+    strength: Wird zu dem augenblicklichen Saettigungsgrad (P_DRINK) addiert.
+    testonly: Ist das Flag gesetzt, wird dem Spieler kein DRINK zugefuehrt.
+              Darf nur zum Testen der Heilstelle verwendet werden und muss
+              im normalen Betrieb auf '0' stehen!
+    mytext: Wer selber einen Text bei Misserfolg ausgeben lassen moechte,
+            darf sich hier was nettes ausdenken.
+            Achtung: Das unterdrueckt nicht die "Durst"-Meldung, die bei
+            negativem strength auftritt, wenn P_DRINK wieder 0 ist.
+
+BESCHREIBUNG
+------------
+::
+
+    Es wird geprueft, ob dem Spieler der angebene Wert "strength" auf
+    aktuelle P_DRINK addiert werden kann oder nicht. Ist dies moeglich,
+    wird es gemacht, es sei denn das testonly != 0.
+
+    Sollen neben P_DRINK noch weitere Props manipuliert werden - bspw. zur
+    Heilung eines Lebewesens - bietet sich die Funktion consume() an.
+
+RUECKGABEWERT
+-------------
+::
+
+     0, wenn strength + P_DRINK > P_MAX_DRINK
+    >0, wenn Erfolg
+
+BEMERKUNG
+---------
+::
+
+    drink_soft() bitte anstatt eigener Manipulationen von P_DRINK und
+    P_MAX_DRINK verwenden.
+
+    Achtung: Immer erst VOR einer Heilung ausfuehren und bei Erfolg heilen.
+
+    Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
+    dafuer eingerichteten Funktion check_and_update_timed_key realisiert
+    werden.
+
+BEISPIEL
+--------
+::
+
+    int heilstelle() {
+      if(this_player()->drink_soft(10, 0, "Du blubberst nicht ueberzeugt "
+                                   "in der Limonade. Das ist zu viel.\n")) {
+        // Platz fuer 10 "Trinken" war noch, diese sind jetzt bereits addiert
+        // Nachricht an den Spieler:
+        tell_object(this_player(), break_string("Du nimmst einen grossen "
+                    "Schluck zuckersuesse Limonade.", 78));
+
+        // alle anderen im Raum bekommen es ggf auch mit:
+        // 1) filter(..., #'living) ergibt die Lebewesen im Raum
+        // 2) filter_objects(..., "ReceiveMsg") ruft ReceiveMsg an jedem
+        // 3) ReceiveMsg(...) bekommt die Folgeparameter
+        filter_objects(filter(all_inventory(environment(this_player())),
+                              #'living) - ({this_player()}),
+                       "ReceiveMsg",
+                       this_player()->Name()+
+                         " trinkt einen Schluck Limonade.",
+                       MT_LOOK|MT_LISTEN,
+                       MA_DRINK);
+
+        // Rassenabhaengige Heilung: Sofort oder in Schritten
+        // Tragbare Heilungen sollten auch eher buffer_hp/_sp benutzen.
+        if(this_player()->QueryProp(P_REAL_RACE)=="Saufziege")
+          this_player()->heal_self(30);
+        else {
+          this_player()->buffer_hp(30,5);
+          this_player()->buffer_sp(30,5);
+        }
+      }
+
+      return 1;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  consume, drink_alcohol, eat_food
+     Heilung:   heal_self, restore_spell_points, restore_hit_points, 
+                buffer_hp, buffer_sp
+     Timing:    check_and_update_timed_key
+     Enttanken: defuel_drink, defuel_food
+     Props:     P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/drop.rst b/doc/sphinx/lfun/drop.rst
new file mode 100644
index 0000000..36147c3
--- /dev/null
+++ b/doc/sphinx/lfun/drop.rst
@@ -0,0 +1,71 @@
+drop()
+======
+
+FUNKTION
+--------
+::
+
+    public varargs int drop(object o, mixed msg);
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+    object o
+        Das Objekt, das fallengelassen werden soll.
+    mixed msg
+        Eine optionale Meldung, die anstelle von P_DROP_MSG oder der
+        Standardmeldung verwendet wird, oder -1, um die Meldung zu
+        unterdruecken.
+
+BESCHREIBUNG
+------------
+::
+
+    Der Spieler oder NPC laesst das Objekt fallen. Gibt o->move() keinen
+    positiven Wert zurueck, beispielsweise weil das Objekt verflucht ist,
+    bekommt er eine entsprechende Fehlermeldung.
+
+RUECKGABEWERT
+-------------
+::
+
+    Wenn das Fallenlassen geklappt hat, 1, ansonsten 0.
+
+BEMERKUNG
+---------
+::
+
+    Diese Funktion ist dann sinnvoll, wenn man den Spieler ein Objekt
+    fallenlassen lassen und sich nicht selbst um die Fehlerbehandlung kuemmern
+    moechte - und da unzaehlige verschiedene Dinge schiefgehen koennen und
+    manche Objekte eigene Fehlermeldungen definieren, eigentlich immer.
+
+    Die Funktion prueft nicht, ob der Spieler/NPC das Objekt ueberhaupt hat,
+    das muss man ggf. selbst ermitteln.
+
+BEISPIEL
+--------
+::
+
+    if (this_player()->drop(obj, ({
+            "Du wirfst @WEN2 in den Saeureteich.\n",
+            "@WER1 wirft @WENU2 in den Saeureteich.\n" })))
+        obj->remove();
+
+SIEHE AUCH
+----------
+::
+
+    move(L), P_DROP_MSG, drop_objects(L), P_NOINSERT_MSG, P_NOLEAVE_MSG,
+    P_TOO_MANY_MSG, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NODROP
+
+
+Last modified: Thu Aug 28 22:20:37 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/drop_obj.rst b/doc/sphinx/lfun/drop_obj.rst
new file mode 100644
index 0000000..64b7274
--- /dev/null
+++ b/doc/sphinx/lfun/drop_obj.rst
@@ -0,0 +1,44 @@
+drop_obj()
+==========
+
+FUNKTION
+--------
+::
+
+    int drop_obj(object ob);
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+    ob  Das Objekt, das von dem Lebewesen, in dem diese Funktion aufgerufen
+        wird, fallengelassen werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+    Das Lebewesen, in dem diese Funktion aufgerufen werden soll, laesst
+    den angegebenen Gegenstand fallen, wenn dies moeglich ist.
+
+RUeCKGABEWERT
+-------------
+::
+
+    1, wenn das Objekt fallen gelassen wurde oder dies nicht moeglich war.
+    (in diesem Fall wird auch direkt eine Textausgabe ausgegeben)
+    0 sonst, in diesem Fall wird in notify_fail eine passende Ausgabe
+    plaziert.
+
+SIEHE AUCH
+----------
+::
+
+    find_obs(), give_obj(), pick_obj(), put_obj(), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/lfun/drop_objects.rst b/doc/sphinx/lfun/drop_objects.rst
new file mode 100644
index 0000000..824b9bd
--- /dev/null
+++ b/doc/sphinx/lfun/drop_objects.rst
@@ -0,0 +1,74 @@
+drop_objects()
+==============
+
+FUNKTION
+--------
+::
+
+    public varargs int drop_objects(string str, mixed msg);
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+    string str
+        Was fallengelassen werden soll.
+    mixed msg
+        Eine optionale Meldung, die anstelle von P_DROP_MSG oder der
+        Standardmeldung verwendet wird, oder -1, um die Meldung zu
+        unterdruecken.
+
+BESCHREIBUNG
+------------
+::
+
+    Der Spieler oder NPC laesst die in <str> benannten Sachen fallen.
+    Kann er ein Objekt nicht fallenlassen, bekommt er eine entsprechende
+    Fehlermeldung. Wenn keine Objekte auf <str> passen, wird per
+    _notify_fail() eine Meldung gesetzt, aber noch nicht ausgegeben.
+
+RUECKGABEWERT
+-------------
+::
+
+    Wenn <str> irgendwelche vorhandenen Sachen sind, 1, sonst 0.
+
+BEMERKUNG
+---------
+::
+
+    Wenn die Funktion 1 zurueckgibt, heisst das noch nicht, dass der Spieler
+    etwas fallengelassen hat! Er hat es nur versucht, d.h. auf jeden Fall eine
+    Meldung bekommen. Gibt die Funktion 0 zurueck, hat er noch keine bekommen.
+
+BEISPIEL
+--------
+::
+
+    private int cmd_opfern(string str)
+    {
+        notify_fail("WAS moechtest Du opfern?\n");
+
+        if (!this_player()->drop_objects(str, ({ "Du opferst @WEN2.",
+                                                 "@WER1 opfert @WENU2.\n" })))
+            return 0;
+
+        filter_objects(this_player()->moved_objects(), "remove");
+        return 1;
+    }
+
+SIEHE AUCH
+----------
+::
+
+    move(L), drop(L), P_DROP_MSG, find_objects(L), moved_objects(L)
+
+
+Last modified: Fri Jul 25 10:59:37 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/eat_food.rst b/doc/sphinx/lfun/eat_food.rst
new file mode 100644
index 0000000..1b967ef
--- /dev/null
+++ b/doc/sphinx/lfun/eat_food.rst
@@ -0,0 +1,114 @@
+eat_food()
+==========
+
+FUNKTION
+--------
+::
+
+    public varargs int eat_food(int food, int testonly, string mytext)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+    food: Wird zu dem augenblicklichen Saettigungsgrad (P_FOOD) addiert.
+    testonly: Ist das Flag gesetzt, wird dem Spieler kein FOOD zugefuehrt.
+              Darf nur zum Testen der Heilstelle verwendet werden und muss
+              im normalen Betrieb auf '0' stehen!
+    mytext: Wer selber einen Text bei Misserfolg ausgeben lassen moechte,
+            darf sich hier was nettes ausdenken.
+            Achtung: Das unterdrueckt nicht die "Hunger"-Meldung, die bei
+            negativem food auftreten kann, wenn P_FOOD wieder 0 ist.
+
+BESCHREIBUNG
+------------
+::
+
+    Es wird geprueft, ob dem Spieler der angebene Wert "strength" auf seine
+    aktuelle P_FOOD addiert werden kann oder nicht. Ist dies moeglich, wird
+    wird es gemacht, es sei denn das testonly != 0.
+
+    Sollen neben P_FOOD noch weitere Props manipuliert werden - bspw. zur
+    Heilung eines Lebewesens - bietet sich die Funktion consume() an.
+
+RUECKGABEWERT
+-------------
+::
+
+     0, wenn strength + P_FOOD > P_MAX_FOOD.
+    >0, wenn Erfolg.
+
+BEMERKUNG
+---------
+::
+
+    eat_food() bitte anstatt eigener Manipulationen von P_FOOD und
+    P_MAX_FOOD verwenden.
+
+    Achtung: Immer erst VOR einer Heilung ausfuehren und bei Erfolg heilen.
+
+    Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
+    dafuer eingerichteten Funktion check_and_update_timed_key realisiert
+    werden.
+
+BEISPIEL
+--------
+::
+
+    int heilstelle() {
+      // Wenn auf das P_FOOD des Spielers die angegebenen 10 nicht mehr addiert
+      // addiert werden koennen (weil sonst P_MAX_FOOD ueberschritten wird),
+      // wird die Fehlermeldung ausgegeben, dass der Spieler nichts mehr
+      // essen/trinken kann.
+      // Bei gesetztem 'mytext' wird 'mytext' an den Spieler ausgegeben.
+      // Ansonsten wird die Standardmeldung ausgegeben.
+      if (!this_player()->eat_food(10, 0, "Der Keks ist einfach "
+                                          "zuviel fuer Dich.\n") )
+        return 1;
+
+      // Spieler hatte noch ausreichend Spielraum bei P_FOOD. Die 10 sind 
+      // schon addiert worden. Jetzt Nachricht ausgeben:
+      tell_object(this_player(), break_string("Du knabberst ein bisschen an "
+                  "dem Keks herum und fuehlst Dich gleich viel besser.", 78));
+
+      // alle Lebewesen im Raum bekommen das auch mit
+      foreach(object ob:
+              (filter(all_inventory(environment(this_player())), #'living) -
+               ({this_player()})))
+        ob->ReceiveMsg(this_player()->Name()+" knuspert einen Keks weg.",
+                       MT_LOOK|MT_LISTEN,
+                       MA_EAT);
+
+      // Rassenabhaengige Heilung: Sofort oder in Schritten
+      // Tragbare Heilungen sollten auch eher buffer_hp/_sp benutzen.
+      if(this_player()->QueryProp(P_REAL_RACE)=="Kruemelmonster")
+        this_player()->heal_self(30);
+      else {
+        this_player()->buffer_hp(30,5);
+        this_player()->buffer_sp(30,5);
+      }
+
+      return 1;
+    }
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  consume, drink_alcohol, drink_soft
+     Heilung:   heal_self, restore_spell_points, restore_hit_points, 
+                buffer_hp, buffer_sp
+     Timing:    check_and_update_timed_key
+     Enttanken: defuel_drink, defuel_food
+     Props:     P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/execute_anything.rst b/doc/sphinx/lfun/execute_anything.rst
new file mode 100644
index 0000000..4703299
--- /dev/null
+++ b/doc/sphinx/lfun/execute_anything.rst
@@ -0,0 +1,64 @@
+execute_anything()
+==================
+
+FUNKTION
+--------
+::
+
+    protected mixed execute_anything(mixed fun, mixed args, ...)
+
+DEFINIERT IN
+------------
+::
+
+    /std/util/executer.c
+
+ARGUMENTE
+---------
+::
+
+    mixed fun        auszufuehrende Funktion/Array/Closure ... anything
+    mixed args       weitere Argumente, werden weiter uebergeben
+
+BESCHREIBUNG
+------------
+::
+
+    Fuehrt "alles" aus:
+
+    
+
+    'fun' kann sein:
+    - eine Closure
+      [funcall(fun, args, ...)]
+    - einen String als Funktion im Objekt
+      [call_other(this_object(), fun, args, ...)]
+    - ein Array mit Objekt/Objektnamen + Funktion als Aufruf der Funktion am
+      Objekt/Objektnamen:
+      [call_other(array[0], array[1], args...)]
+
+    Wird execute_anything() aus dem restriction_checker gerufen, wird als
+    erster Parameter immer das gepruefte Living uebergeben.
+
+BEMERKUNGEN
+-----------
+::
+
+    Es kann sich anbieten, die gerufene Funktion mit varargs-Argumenten zu
+    gestalten, damit ihr mehr Argumente uebergeben werden koennen als in der
+    Funktionsdefinition angegeben sind. 
+
+    Der Restriktionspruefer (/std/restriction_checker) versteht im Falle eines
+    Arrays mit Objekt/Objektnamen + Funktion auch ein Array mit mehr als 2
+    Elementen. Die weiteren Elemente werden dann zu weiteren Argumenten der
+    gerufenen Funktion. Hierbei wird <pl> ggf. aber als erstes Argument vor
+    alle anderen eingefuegt.
+
+SIEHE AUCH
+----------
+::
+
+    check_restrictions, varargs
+
+31.12.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/exit.rst b/doc/sphinx/lfun/exit.rst
new file mode 100644
index 0000000..c6cf08e
--- /dev/null
+++ b/doc/sphinx/lfun/exit.rst
@@ -0,0 +1,56 @@
+exit()
+======
+
+FUNKTION
+--------
+::
+
+  varargs void exit(object liv, object dest);
+
+DEFINIERT IN
+------------
+::
+
+  /std/room/description.c
+
+ARGUMENTE
+---------
+::
+
+  liv - (object) Das bewegte Lebewesen.
+  dest - (object) Das Environment, in welches bewegt wird.
+
+BESCHREIBUNG
+------------
+::
+
+  Diese Funktion wird immer dann aufgerufen, wenn ein Lebewesen den
+  Raum verlaesst. Standardmaessig werden hier ggf. die Raummeldungen
+  abgestellt, man kann aber auch eigene Checks einhaengen. In dem Fall MUSS
+  man aber das geerbte exit() auf jeden Fall aufrufen.
+
+RUeCKGABEWERT
+-------------
+::
+
+  keiner
+
+BEMERKUNG
+---------
+::
+
+  Man beachte, dass this_player() 0 sein kann, wenn z.B. ein netztoter Spieler
+  Spieler den Raum verlaesst.
+  Man beachte ausserdem, dass this_player() nicht unbedingt das bewegte Living
+  sein muss. Wenn z.B. jemand ein Lebewesen bewegt, ist TP der, der die
+  Bewegung durchfuehrt, nicht das Lebewesen.
+
+SIEHE AUCH
+----------
+::
+
+  init(), this_player(), previous_object(), caller_stack(),
+  NotfiyLeave(), NotifyRemove(), NotifyDestruct()
+
+Last modified: 25.02.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/find_obs.rst b/doc/sphinx/lfun/find_obs.rst
new file mode 100644
index 0000000..c0cc707
--- /dev/null
+++ b/doc/sphinx/lfun/find_obs.rst
@@ -0,0 +1,57 @@
+find_obs()
+==========
+
+FUNKTION
+--------
+::
+
+    object* find_obs(string str, int meth)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+    str     Der String der geparsed werden soll.
+    meth    Mit Hilfe dieses Parameters koennen bestimmte Bereichs-
+            eingrenzungen vorgenommen werden (definiert in moving.h):
+
+            PUT_GET_NONE - keinerlei Bereichseingrenzung.
+            PUT_GET_TAKE - es handelt sich um ein Nehmen von Gegenstaenden
+                           also wird das inventory ausgenommen.
+            PUT_GET_DROP - es handelt sich um das Entfernen von Gegenstaenden
+                           also wird das environment ausgenommen.           
+
+                                                                            
+
+BESCHREIBUNG                                                               
+---------------------------------------------------------------------------
+::
+
+                                                                            
+
+    Der String (str) muss folgendes Format haben damit Objekte gefunden
+    werden.
+
+    <gegenstand> [aus container] [in mir|im raum]
+
+    <gegenstand> kann hierbei sowohl eine Objekt-ID als auch ein
+    Gruppenbezeichner wie z.b. "alles" sein.
+
+RUeCKGABEWERT
+-------------
+::
+
+    Ein Array mit allen Objekten die sich angesprochen fuehlen, oder aber 0.
+
+SIEHE AUCH
+----------
+::
+
+    drop_obj(), give_obj(), pick_obj(), put_obj(), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/lfun/get_killing_player.rst b/doc/sphinx/lfun/get_killing_player.rst
new file mode 100644
index 0000000..e75f571
--- /dev/null
+++ b/doc/sphinx/lfun/get_killing_player.rst
@@ -0,0 +1,61 @@
+get_killing_player()
+====================
+
+FUNKTION
+--------
+::
+
+     protected object get_killing_player()
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Liefert im Tod (nach dem toetenden do_damage()) das Spielerobjekt, was
+     den Tod wohl zu verantworten hat, falls es ermittelt werden kann. Es
+     werden registrierte Helfer-NPC und einige schadenverursachende Objekte
+     beruecksichtigt. Hierbei wird QueryUser() in den Objekten abgefragt.
+
+     Es benoetigt ein gueltiges P_KILLER, d.h. falls das Lebewesen vergiftet
+     wurde oder das toetende Objekt aus sonstigen Gruenden nicht in P_KILLER
+     steht, funktioniert es nicht.
+     Auch gibt es bestimmt Objekte, die fuer Spieler toeten koennen, die die
+     diese Funktion nicht kennt.
+     (Dies gilt beides ebenso fuer /p/service/mupfel/getkill.c, ist also kein
+      Grund, jenes statt dieser Funktion zu nutzen.)
+
+RUeCKGABEWERT
+-------------
+::
+
+     Das Objekt des Spielers, falls es ermittelt werden konnte, sonst 0.
+
+BEMERKUNGEN
+-----------
+::
+
+    Der Name des Spieler ist mittel Name() ermittelbar. Will man die Info, 
+    womit ein Spieler den Kill ggf. gemacht hat, kann man P_KILLER
+    auswerten/nutzen.
+
+SIEHE AUCH
+----------
+::
+
+     QueryUser
+     P_KILLER
+
+11.11.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/gilde/AddSkill.rst b/doc/sphinx/lfun/gilde/AddSkill.rst
new file mode 100644
index 0000000..4e79df3
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/AddSkill.rst
@@ -0,0 +1,57 @@
+AddSkill()
+==========
+
+FUNKTION
+--------
+::
+
+    varargs int AddSkill(string sname, mapping ski)
+
+DEFINIERT IN
+------------
+::
+
+    /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+    string sname       Name des Skills
+    mapping ski        Skill-Mapping
+
+BESCHREIBUNG
+------------
+::
+
+    Fuegt den Skill zur Liste der in dieser Gilde lernbaren Skills
+    hinzu. Das Mapping enthaelt Informationen, die der Gildenraum
+    bzw. das Gildenobjekt zum Skill herausgeben und die das Lernen
+    des Skills beeinflussen.
+
+RUECKGABWERT
+------------
+::
+
+    1 fuer Erfolg
+
+BEISPIEL
+--------
+::
+
+    AddSkill( FIGHT(WT_CLUB), ([ OFFSET(SI_SKILLLEARN) : 1 ]) );
+
+SIEHE AUCH
+----------
+::
+
+    GObj Lernen:    LearnSkill, LearnSpell, InitialSkillAbility
+    * Anzeigen:     SkillListe
+    * Verwalten:    AddSpell (gilde), QuerySpell, QuerySkill
+    * Nutzen:       UseSpell (gilde)
+    * Properties:   P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+    Gildenfkt.:     GuildRating
+    * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/AddSpell.rst b/doc/sphinx/lfun/gilde/AddSpell.rst
new file mode 100644
index 0000000..c2daac9
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/AddSpell.rst
@@ -0,0 +1,74 @@
+AddSpell()
+==========
+
+FUNKTION
+--------
+::
+
+    varargs int AddSpell(string verb, mapping ski)
+
+DEFINIERT IN
+------------
+::
+
+    /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+    string verb        Name des Spells
+    mapping ski        Skill-Mapping
+
+BESCHREIBUNG
+------------
+::
+
+    Fuegt den Spell zur Liste der in dieser Gilde lernbaren Spells
+    hinzu. Das Mapping enthaelt Informationen, die der Gildenraum
+    bzw. das Gildenobjekt zum Spell herausgeben und die das Lernen
+    des Spells beeinflussen.
+
+RUECKGABWERT
+------------
+::
+
+    1 fuer Erfolg
+
+BEMERKUNGEN
+-----------
+::
+
+    Siehe das Verhalten von QuerySpell (gilde) zum Zusammenfuegen
+    der AddSpell-Informationen aus Gilde und Spellbook. Relevant
+    zB fuer Lernrestriktionen.
+
+BEISPIEL
+--------
+::
+
+    AddSpell("entfluche",
+      ([SI_SKILLRESTR_LEARN :
+        ([P_GUILD_LEVEL: LVL_WANDER,
+          SR_FUN:        #'glaubensTest]),
+        SI_DIFFICULTY: 100,
+        SI_SKILLINFO:  "Wanderprediger ab Stufe 7",
+        SI_SKILLINFO_LONG: break_string(
+          "Um jemanden von einem laestigen Sprachfluch zu befreien, "
+          "sollte man diese Anrufung benutzen [...]", 78),
+        SI_GOD:        LEMBOLD]));
+
+SIEHE AUCH
+----------
+::
+
+    GObj Lernen:    LearnSkill, LearnSpell, InitialSkillAbility
+    * Anzeigen:     SkillListe
+    * Verwalten:    AddSkill, QuerySpell, QuerySkill, QuerySkill
+    * Nutzen:       UseSpell (gilde)
+    * Properties:   P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+    Gildenfkt.:     GuildRating
+    * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/GuildRating.rst b/doc/sphinx/lfun/gilde/GuildRating.rst
new file mode 100644
index 0000000..1dbe8f6
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/GuildRating.rst
@@ -0,0 +1,47 @@
+GuildRating()
+=============
+
+FUNKTION
+--------
+::
+
+    int GuildRating(object pl)
+
+DEFINIERT IN
+------------
+::
+
+    /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+    object pl          Spieler, der geratet werden soll
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt das Guild-Rating des Spielers im Bereich 0-MAX_ABILITY zurueck
+    und schreibt sie in P_GUILD_RATING. Wichtig fuer Levelbestimmung!
+
+    
+
+    Normalerweise ist das der Mittelwert der Skill-Abilities aller Skills
+    und Spells, das Verhalten kann aber ueberschrieben werden.
+
+SIEHE AUCH
+----------
+::
+
+    GObj Lernen:    LearnSkill, LearnSpell, InitialSkillAbility
+    * Anzeigen:     SkillListe
+    * Verwalten:    AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+    * Nutzen:       UseSpell (gilde)
+    * Properties:   P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS, P_GUILD_RATING
+    Gildenfkt.:
+    * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+10. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/InitialSkillAbility.rst b/doc/sphinx/lfun/gilde/InitialSkillAbility.rst
new file mode 100644
index 0000000..a239ca5
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/InitialSkillAbility.rst
@@ -0,0 +1,52 @@
+InitialSkillAbility()
+=====================
+
+FUNKTION
+--------
+::
+
+    static int InitialSkillAbility(mapping ski, object pl)
+
+DEFINIERT IN
+------------
+::
+
+    /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+    mapping ski     Der zu lernende Skill
+    object  pl      Spieler
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt den initialen Ability-Wert fuer einen neu zu lernenden Skill (Spell)
+    zurueck. Die Standardformel benutzt nur Intelligenz und SI_SKILLLEARN und
+    kann in der Gilde ueberschrieben werden.
+
+BEMERKUNGEN
+-----------
+::
+
+    Der zurueckgegebene Wert wird noch in das Spieler-Skillsystem eingegeben
+    und daher kann der real gelernte Wert abweichen
+
+SIEHE AUCH
+----------
+::
+
+    Skills:         LimitAbility, ModifySkill
+    GObj Lernen:    LearnSkill, LearnSpell
+    * Anzeigen:     SkillListe
+    * Verwalten:    AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+    * Nutzen:       UseSpell (gilde)
+    * Properties:   P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+    Gildenfkt.:     GuildRating
+    * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/LearnSkill.rst b/doc/sphinx/lfun/gilde/LearnSkill.rst
new file mode 100644
index 0000000..cba0d5f
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/LearnSkill.rst
@@ -0,0 +1,59 @@
+LearnSkill()
+============
+
+FUNKTION
+--------
+::
+
+    int LearnSkill(string skill)
+
+DEFINIERT IN
+------------
+::
+
+    /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+    string skill     Der zu lernende Skill
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion ueberprueft den Spieler auf Gildenzugehoerigkeit
+    und ruft, falls kein 'skill' angegeben ist die SkillListe()
+    fuer Skills auf.
+
+    Falls ein Argument angegeben wird, wird bei dem Spieler dieser Skill
+    initialisiert, sofern er die notwendigen Anforderungen erfuellt hat.
+
+RUECKGABEWERT
+-------------
+::
+
+    0 bei Fehler, 1 bei Erfolg.
+
+BEMERKUNGEN
+-----------
+::
+
+    Fuer die Lebewesen-Skills gibt es eine gleichnamige Funktion.
+    Siehe dafuer LearnSkill.
+
+SIEHE AUCH
+----------
+::
+
+    GObj Lernen:    LearnSpell, InitialSkillAbility
+    * Anzeigen:     SkillListe
+    * Verwalten:    AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+    * Nutzen:       UseSpell (gilde)
+    * Properties:   P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+    Gildenfkt.:     GuildRating
+    * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/LearnSpell.rst b/doc/sphinx/lfun/gilde/LearnSpell.rst
new file mode 100644
index 0000000..f09f0cf
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/LearnSpell.rst
@@ -0,0 +1,53 @@
+LearnSpell()
+============
+
+FUNKTION
+--------
+::
+
+    varargs int LearnSpell(string spell, object pl)
+
+DEFINIERT IN
+------------
+::
+
+    /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+    string spell     Der zu lernende Spell
+    object pl        lernender Spieler, wenn 0, wird this_player() genommen
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion ueberprueft den Spieler auf Gildenzugehoerigkeit
+    und ruft, falls kein 'spell' angegeben ist die SkillListe()
+    fuer Spells auf.
+
+    Falls ein Argument angegeben wird, wird bei dem Spieler dieser Spell
+    initialisiert, sofern er die notwendigen Anforderungen erfuellt hat.
+
+RUECKGABEWERT
+-------------
+::
+
+    0 bei Fehler, 1 bei Erfolg.
+
+SIEHE AUCH
+----------
+::
+
+    GObj Lernen:    LearnSkill, InitialSkillAbility
+    * Anzeigen:     SkillListe
+    * Verwalten:    AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+    * Nutzen:       UseSpell (gilde)
+    * Properties:   P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+    Gildenfkt.:     GuildRating
+    * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/QuerySkill.rst b/doc/sphinx/lfun/gilde/QuerySkill.rst
new file mode 100644
index 0000000..d4be7c8
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/QuerySkill.rst
@@ -0,0 +1,54 @@
+QuerySkill()
+============
+
+FUNKTION
+--------
+::
+
+    mapping QuerySkill(string skill)
+
+DEFINIERT IN
+------------
+::
+
+    /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+    string skill       Name des Skills
+
+BESCHREIBUNG
+------------
+::
+
+    Liefert fuer diesen Skill die Gildeninformationen in einem
+    Mapping zurueck.
+
+BEISPIEL
+--------
+::
+
+    // /gilden/klerus->QuerySkill(FIGHT(WT_CLUB)) gibt zB zurueck:
+    ([SI_FUN:                "Fight_club",
+      OFFSET(SI_SKILLLEARN): 1
+      SI_SKILLRESTR_USE:     ([SR_FUN:#'gilden/klerus->spellTest()]),
+      OFFSET(SI_SKILLLEARN): #'gilden/klerus->learnOffset,
+      OFFSET(SI_SPELLCOST):  #'gilden/klerus->costOffset,
+      FACTOR(SI_SPELLCOST):  #'gilden/klerus->costFactor])
+
+SIEHE AUCH
+----------
+::
+
+    GObj Lernen:    LearnSkill, LearnSpell, InitialSkillAbility
+    * Anzeigen:     SkillListe
+    * Verwalten:    AddSkill, AddSpell, QuerySpell
+    * Nutzen:       UseSpell (gilde)
+    * Properties:   P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+    Gildenfkt.:     GuildRating
+    * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/QuerySpell.rst b/doc/sphinx/lfun/gilde/QuerySpell.rst
new file mode 100644
index 0000000..b460f03
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/QuerySpell.rst
@@ -0,0 +1,75 @@
+QuerySpell()
+============
+
+FUNKTION
+--------
+::
+
+    mapping QuerySpell(string spell)
+
+DEFINIERT IN
+------------
+::
+
+    /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+    string spell       Name des Spells
+
+BESCHREIBUNG
+------------
+::
+
+    Liefert fuer diesen Spell die Gilden- und Spellbookinformationen
+    zusammengefasst in ein Mapping zurueck.
+    Die Gildeninformationen haben dabei Vorrang (d.h. eine Lernrestriktion
+    im Spellbook wird benutzt, bei unterschiedlichen Werten fuer das gleiche
+    Attribut geht der Wert in der Gilde vor).
+
+BEISPIEL
+--------
+::
+
+    // /gilden/klerus->QuerySpell("entfluche") gibt zB zurueck:
+    ([SI_SPELLFATIGUE: 2,
+      SI_SP_LOW_MSG:   "Deine Konzentration reicht nicht aus, das Interesse "
+                       "der Goetter zu "wecken.\n",
+      SI_TIME_MSG:     "So schnell koennen sich die Goetter nicht wieder um "
+                       "Dich kuemmern!\n",
+      SI_SKILLLEARN:   5,
+      OFFSET(SI_SKILLLEARN):15
+      SI_SKILLRESTR_LEARN:
+      ([P_LEVEL:       7,
+        P_GUILD_LEVEL: LVL_WANDER,
+        SR_FUN:        #'gilden/klerus->glaubensTest]),
+      SI_DIFFICULTY:   100,
+      SI_SKILLINFO:    "Wanderprediger ab Stufe 7",
+      SI_SKILLINFO_LONG:
+        "Um jemanden von einem laestigen Sprachfluch zu befreien, "
+        "sollte man diese Anrufung benutzen [...]",
+      SP_NAME:         "entfluche",
+      SI_SKILLRESTR_USE: ([ SR_FREE_HANDS : 0 ]),
+      SI_MAGIC_TYPE:   ({MT_SAKRAL})
+      SI_GOD:          LEMBOLD,
+      SI_SKILLRESTR_USE:     ([SR_FUN:#'gilden/klerus->spellTest()]),
+      OFFSET(SI_SKILLLEARN): #'gilden/klerus->learnOffset,
+      OFFSET(SI_SPELLCOST):  #'gilden/klerus->costOffset,
+      FACTOR(SI_SPELLCOST):  #'gilden/klerus->costFactor])
+
+SIEHE AUCH
+----------
+::
+
+    GObj Lernen:    LearnSkill, LearnSpell, InitialSkillAbility
+    * Anzeigen:     SkillListe
+    * Verwalten:    AddSkill, AddSpell, QuerySkill
+    * Nutzen:       UseSpell (gilde)
+    * Properties:   P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+    Gildenfkt.:     GuildRating
+    * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/SkillListe.rst b/doc/sphinx/lfun/gilde/SkillListe.rst
new file mode 100644
index 0000000..6017650
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/SkillListe.rst
@@ -0,0 +1,49 @@
+SkillListe()
+============
+
+FUNKTION
+--------
+::
+
+    int SkillListe(int what)
+
+DEFINIERT IN
+------------
+::
+
+    /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+    int what        Rueckgabeoption:
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt eine Text mit Liste mit lernbaren Skills/Spells zurueck:
+
+    
+
+    Fuer 'what': 0 - alle; 1 - Spells; 2 - Skills.
+
+    
+
+    Zeigt Eintraege aus SI_SKILLINFO.
+
+SIEHE AUCH
+----------
+::
+
+    GObj Lernen:    LearnSkill, LearnSpell, InitialSkillAbility
+    * Verwalten:    AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+    * Nutzen:       UseSpell (gilde)
+    * Properties:   P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+    Gildenfkt.:     GuildRating
+    * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+    Skills:         skill_info_liste
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/UseSpell.rst b/doc/sphinx/lfun/gilde/UseSpell.rst
new file mode 100644
index 0000000..9cea450
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/UseSpell.rst
@@ -0,0 +1,53 @@
+UseSpell()
+==========
+
+FUNKTION
+--------
+::
+
+    varargs int UseSpell(object caster, string spell, mapping sinfo)
+
+DEFINIERT IN
+------------
+::
+
+    /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+    object caster      Spieler, der Spell nutzt
+    string spell       Spell-Name
+    mapping sinfo      Spell-Informationen
+
+BESCHREIBUNG
+------------
+::
+
+    Prueft, ob der Spell in der Gilde definiert ist und ruft ihn dann
+    ggf in aus dem Spell-Mapping gelesenen Gilden-SI_SPELLBOOK auf.
+
+    Wird von living/skills::UseSpell gerufen, wenn dieses die SI_CLOSURE,
+    also die Funktion eines Spells sucht, fuer den kein SI_SPELLBOOK
+    explizit angegeben wurde.
+
+RUECKGABWERT
+------------
+::
+
+    Rueckgabewert des Spells aus dem Spellbook oder 0.
+
+SIEHE AUCH
+----------
+::
+
+    GObj Lernen:    LearnSkill, LearnSpell, InitialSkillAbility
+    * Anzeigen:     SkillListe
+    * Verwalten:    AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+    * Properties:   P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+    Gildenfkt.:     GuildRating
+    * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/austreten.rst b/doc/sphinx/lfun/gilde/austreten.rst
new file mode 100644
index 0000000..6856558
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/austreten.rst
@@ -0,0 +1,52 @@
+austreten()
+===========
+
+FUNKTION
+--------
+::
+
+    varargs int austreten(int loss)
+
+ARGUMENTE
+---------
+::
+
+    int loss       Prozentsatz, um den sich die Gildenskills verschlechtern
+
+DEFINIERT IN
+------------
+::
+
+    /std/gilden_ob.c
+
+BESCHREIBUNG
+------------
+::
+
+    Austrittsfunktion der Gilde. Prueft die Restriktionen der Gilde und
+    laesst this_player() ggf austreten. Das Austreten aus der Standard-
+    gilde ist dabei nicht moeglich.
+
+    Der Gildenmaster loest ggf ein EVT_GUILD_CHANGE aus. Dabei werden
+    E_OBJECT, E_GUILDNAME, E_LAST_GUILDNAME entsprechend gesetzt.
+
+    Der Gildenmaster senkt auch die Skill/Spell-Faehigkeiten um 'loss' bzw.
+    normalerweise mindestens 20%.
+
+    Durch Ueberschreiben koennen hier zB Abschiedsmeldungen gesendet werden.
+
+SIEHE AUCH
+----------
+::
+
+    GObj Lernen:    LearnSkill, LearnSpell, InitialSkillAbility
+    * Anzeigen:     SkillListe
+    * Verwalten:    AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+    * Nutzen:       UseSpell (gilde)
+    * Properties:   P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+    Gildenfkt.:
+    * Ein/Austritt: beitreten, bei_oder_aus_treten
+    * Props dafuer: P_GUILD_RESTRICTIONS
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/bei_oder_aus_treten.rst b/doc/sphinx/lfun/gilde/bei_oder_aus_treten.rst
new file mode 100644
index 0000000..504884c
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/bei_oder_aus_treten.rst
@@ -0,0 +1,43 @@
+bei_oder_aus_treten()
+=====================
+
+FUNKTION
+--------
+::
+
+    int bei_oder_aus_treten(string str)
+
+ARGUMENTE
+---------
+::
+
+    string str       Spielerparameter
+
+DEFINIERT IN
+------------
+::
+
+    /std/gilden_ob.c
+
+BESCHREIBUNG
+------------
+::
+
+    Aus- oder Eintrittsfunktion, ruft beitreten() bzw. austreten() auf.
+    Wird im Std-Gildenraum per AddCmd zur Verfuegung gestellt.
+
+SIEHE AUCH
+----------
+::
+
+    GObj Lernen:    LearnSkill, LearnSpell, InitialSkillAbility
+    * Anzeigen:     SkillListe
+    * Verwalten:    AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+    * Nutzen:       UseSpell (gilde)
+    * Properties:   P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+    Gildenfkt.:
+    * Ein/Austritt: beitreten, austreten
+    * Props dafuer: P_GUILD_RESTRICTIONS
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/beitreten.rst b/doc/sphinx/lfun/gilde/beitreten.rst
new file mode 100644
index 0000000..fe269cb
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/beitreten.rst
@@ -0,0 +1,43 @@
+beitreten()
+===========
+
+FUNKTION
+--------
+::
+
+    int beitreten()
+
+DEFINIERT IN
+------------
+::
+
+    /std/gilden_ob.c
+
+BESCHREIBUNG
+------------
+::
+
+    Beitrittsfunktion der Gilde. Prueft die Gilde selbst im Gildenmaster,
+    dann die Restriktionen der Gilde und laesst this_player() ggf eintreten.
+
+    Der Gildenmaster loest ggf ein EVT_GUILD_CHANGE aus. Dabei werden
+    E_OBJECT, E_GUILDNAME, E_LAST_GUILDNAME entsprechend gesetzt.
+
+    Durch Ueberschreiben koennen hier zB Standard-Skills und Spells den
+    Spieler bei Eintritt gelehrt werden.
+
+SIEHE AUCH
+----------
+::
+
+    GObj Lernen:    LearnSkill, LearnSpell, InitialSkillAbility
+    * Anzeigen:     SkillListe
+    * Verwalten:    AddSpell (gilde), AddSkill, QuerySpell
+    * Nutzen:       UseSpell (gilde)
+    * Properties:   P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+    Gildenfkt.:
+    * Ein/Austritt: bei_oder_aus_treten, austreten
+    * Props dafuer: P_GUILD_RESTRICTIONS
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/give.rst b/doc/sphinx/lfun/give.rst
new file mode 100644
index 0000000..ef88c8a
--- /dev/null
+++ b/doc/sphinx/lfun/give.rst
@@ -0,0 +1,66 @@
+give()
+======
+
+FUNKTION
+--------
+::
+
+    public varargs int give(object o, object dest, mixed msg);
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+    object o
+        Das Objekt, das uebergeben werden soll.
+    object dest
+        Der Spieler oder NPC, der das Objekt bekommen soll.
+    mixed msg
+        Eine optionale Meldung, die anstelle von P_GIVE_MSG oder der
+        Standardmeldung verwendet wird, oder -1, um die Meldung zu
+        unterdruecken.
+
+BESCHREIBUNG
+------------
+::
+
+    Der Spieler oder NPC uebergibt dem Empfaenger das Objekt. Gibt o->move()
+    keinen positiven Wert zurueck, beispielsweise weil das Objekt verflucht
+    ist oder der Empfaenger es nicht mehr tragen kann, bekommt er eine
+    entsprechende Fehlermeldung.
+
+RUECKGABEWERT
+-------------
+::
+
+    Wenn die Uebergabe geklappt hat, 1, ansonsten 0.
+
+BEMERKUNG
+---------
+::
+
+    Diese Funktion ist dann sinnvoll, wenn man den Spieler ein Objekt
+    weitergeben lassen und sich nicht selbst um die Fehlerbehandlung kuemmern
+    moechte - und da unzaehlige verschiedene Dinge schiefgehen koennen und
+    manche Objekte eigene Fehlermeldungen definieren, eigentlich immer.
+
+    Die Funktion prueft nicht, ob der Spieler/NPC der Objekt ueberhaupt hat,
+    das muss man ggf. selbst ermitteln.
+
+SIEHE AUCH
+----------
+::
+
+    move(L), P_GIVE_MSG, give_objects(L), give_notify(L),
+    P_NOINSERT_MSG, P_NOLEAVE_MSG, P_TOO_MANY_MSG,
+    P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NODROP
+
+
+Last modified: Thu Aug 28 22:21:19 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/give_notify.rst b/doc/sphinx/lfun/give_notify.rst
new file mode 100644
index 0000000..2a56be3
--- /dev/null
+++ b/doc/sphinx/lfun/give_notify.rst
@@ -0,0 +1,87 @@
+give_notify()
+=============
+
+FUNKTION
+--------
+::
+
+     void give_notify(object obj);
+
+DEFINIERT IN
+------------
+::
+
+     /std/npc/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+     obj
+       an den NPC uebergebenes Objekt
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird automatisch immer dann aufgerufen, wenn ein
+     Lebewesen (welches kein Spielercharakter ist) ein Objekt uebergeben
+     bekommt. Dies muss jedoch ueber die Funktionalitaet von
+     put_and_get.c geschehen sein, innerhalb von move() wird die Funktion
+     nicht aufgerufen!
+
+BEISPIEL
+--------
+::
+
+     Oftmals will man in Quests erreichen, dass einem NPC ein bestimmtes
+     Item als Beweis der Erfuellung einer bestimmten Aufgabe ueberbracht
+     wird. Folgendermasse kann dies realisiert werden:
+     void create() {
+       ::create();
+       ...
+       SetProp(P_REJECT,({REJECT_GIVE,
+         Name(WER)+" sagt: Das brauche ich nicht!\n"}));
+       ...
+     }
+
+     void quest_ok(object obj) { ...
+       // Vernichtung des Questobjektes und Questtexte
+       // Questbelohnung und Questanerkennung
+     }
+
+     void give_notify(object obj) {
+       if(obj->id("\nquestitem")) // Questitem bekommen?
+         quest_ok(obj);
+       else
+         ::give_notify(obj);  // P_REJECT soll sonst greifen
+     }
+     Der Aufruf von ::give_notify() stellt sicher, dass ein Objekt
+     zurueckgegeben wird, sofern es nicht das gesuchte ist. Erreicht wird
+     dies ueber P_REJECT (siehe Bemerkungen).
+
+BEMERKUNGEN
+-----------
+::
+
+     Speziell in NPCs ist diese Funktion normalerweise dafuer
+     verantwortlich, dass mittels der Property P_REJECT die Annahme von
+     Objekten verweigert werden kann. Ueberschreibt man sie, so sollte
+     man gegebenenfalls darauf achten, dass diese Standardfunktion
+     ebenfalls aufgerufen wird.
+
+SIEHE AUCH
+----------
+::
+
+     P_REJECT, show_notify(), 
+     /std/npc/put_and_get.c, /std/living/put_and_get.c
+
+22. Oktober 2013, Arathorn.
+
diff --git a/doc/sphinx/lfun/give_obj.rst b/doc/sphinx/lfun/give_obj.rst
new file mode 100644
index 0000000..7c36461
--- /dev/null
+++ b/doc/sphinx/lfun/give_obj.rst
@@ -0,0 +1,43 @@
+give_obj()
+==========
+
+FUNKTION
+--------
+::
+
+    int give_obj(object ob, object where)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+    ob      Das Objekt, das abgegeben werden soll.
+    where   Das Lebewesen, dass das Objekt erhaelt.
+
+BESCHREIBUNG
+------------
+::
+
+    Das Lebewesen, in dem diese Funktion aufgerufen werden soll, gibt
+    den angegebenen Gegenstand (ob) an das angegebene Lebewesen (where).
+
+RUeCKGABEWERT
+-------------
+::
+
+    1, wenn das Objekt uebergeben wurde oder die Uebergabe nicht moeglich war.
+    (in diesem Fall wird auch direkt eine Textausgabe ausgegeben)
+    0 sonst, in diesem Fall wird in notify_fail eine passende Ausgabe plaziert.
+
+SIEHE AUCH
+----------
+::
+
+    pick_obj(), drop_obj(), put_obj(), find_obs(), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/lfun/heal_self.rst b/doc/sphinx/lfun/heal_self.rst
new file mode 100644
index 0000000..0c81a60
--- /dev/null
+++ b/doc/sphinx/lfun/heal_self.rst
@@ -0,0 +1,70 @@
+heal_self()
+===========
+
+FUNKTION
+--------
+::
+
+    void heal_self(int points);
+
+ARGUMENTE
+---------
+::
+
+    points: Die dem Lebewesen zukommende Heilung.
+
+BESCHREIBUNG
+------------
+::
+
+    Dem Lebewesen werden points Lebens- und Konzentrationspunkte 
+    gutgeschrieben und auf die aktuellen addiert. Es werden aber nicht
+    die maximalen Werte ueberschritten.
+
+RUECKGABEWERT
+-------------
+::
+
+    Keiner
+
+BEISPIELE
+---------
+::
+
+    
+
+    AddCmd("pflueck&beere","pfluecke_cmd","Was moechtest Du pfluecken?");
+
+    int pfluecke_cmd(string str){
+        write("Du pflueckst eine Beere, isst sie und fuehlst Dich gleich "
+             +"viel besser.\n");
+        this_player()->heal_self(30);
+        return 1;
+    }
+
+    Der Spieler bekommt hier pro Beere die er pflueckt und isst je 30 LP/KP
+    zu seinen momentanen.
+
+BEMERKUNGEN: 
+    heal_self wird gerne fuer Heilstellen in Gebieten genommen, in denen ein
+    Spieler diese Heilung auch wirklich braucht. Dennoch ist der Einsatz un-
+    bedingt mit der Heilungsbalance abzusprechen und darauf zu achten, dass
+    pro reset() nur eine bestimmte Anzahl an Heilungen ausgegeben werden.
+
+    Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
+    dafuer eingerichteten Funktion check_and_update_timed_key realisiert
+    werden.
+
+SIEHE AUCH
+----------
+::
+
+    Verwandt:   restore_spell_points, restore_hit_points, buffer_hp
+		buffer_sp, check_and_update_timed_key
+    Gegenparts: do_damage, reduce_hit_points, reduce_spell_points
+    Props:      P_HP, P_SP
+    Konzept:    heilung
+
+
+Last modified: 27.05.2007 by Ennox
+
diff --git a/doc/sphinx/lfun/heart_beat.rst b/doc/sphinx/lfun/heart_beat.rst
new file mode 100644
index 0000000..e440ae1
--- /dev/null
+++ b/doc/sphinx/lfun/heart_beat.rst
@@ -0,0 +1,58 @@
+heart_beat()
+============
+
+FUNKTION
+--------
+::
+
+     protected void heart_beat();
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/life.c
+     /std/living/combat.c
+     und anderen...
+     kann auch in beliebigen Objekten selbst definiert werden.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird alle zwei Sekunden vom GameDriver aufgerufen. Sie
+     regelt in der MG-MudLib das Heilen von Spielern und Monstern, den
+     Ablauf von Kampfrunden, die Verdauung etc.
+
+     Da heart_beat() ziemlich viele Ressourcen des GameDrivers verbraet,
+     sollte man Objekte mit heart_beat() nur so selten wie moeglich
+     benutzen! Und selbst dann sollte der heart_beat() nicht die ganze Zeit
+     ueber laufen, sondern sich so bald wie moeglich abschalten.
+
+     Das Ein- und Ausschalten des heart_beat()s erfolgt mit
+     set_heart_beat().
+
+BEMERKUNGEN
+-----------
+::
+
+     1. Teuer, teuer, teuer!
+     2. Soll euer Viech pro "echtem" Heartbeat mehrere Kampfrunden haben,
+        benutzt dafuer SA_SPEED und ruft auf gar keinen Fall mehrfach 
+        ::heart_beat() auf. Also _NICHT_
+        void heart_beat() {
+            ::heart_beat();
+            ::heart_beat(); }
+        sondern:
+        SetProp(P_SKILL_ATTRIBUTE_OFFSETS, ([SA_SPEED: 200]) );
+
+SIEHE AUCH
+----------
+::
+
+     Efuns:     set_heart_beat(), absolute_hb_count(), set_next_reset()
+     Fehler:    make_immortal(L)
+
+
+22.3.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/id.rst b/doc/sphinx/lfun/id.rst
new file mode 100644
index 0000000..539b0cd
--- /dev/null
+++ b/doc/sphinx/lfun/id.rst
@@ -0,0 +1,99 @@
+id()
+====
+
+FUNKTION
+--------
+::
+
+     varargs int id(string str, int lvl);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+     /std/player/base.c
+
+ARGUMENTE
+---------
+::
+
+     string str
+          String, auf den getestet werden soll.
+     int lvl
+          In /std/player/base.c benutzt. Wenn der Spieler unsichtbar ist
+          und lvl kleiner ist als sein Level, wird 0 zurueckgegeben.
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird geprueft, ob sich das Objekt mit str ansprechen laesst. Dazu
+     wird str mit dem Inhalt der Property P_IDS verglichen. Falls
+     P_ADJECTIVES gesetzt ist, werden auch alle Adjektivkombinationen mit
+     den Bezeichnern geprueft.
+
+     Besondere Bedeutung hat diese Funktion bei Mengenobjekten: Anhand von
+     str wird vermerkt, welche Menge des Objektes angesprochen wird. Es
+     werden dabei mehrere Faelle unterschieden:
+     o str ist einer der mit AddId() angegebener Bezeichner. In diesem
+       Fall ist die angesprochene Menge die Gesamtmenge.
+     o str ist einer der mit AddSingularId() angegebenen Bezeichner. Die
+       angesprochene Menge ist in diesem Fall 1.
+     o str ist einer der mit AddPluralId() angegebenen Bezeichner. Die
+       angesprochene Menge ist in diesem Fall . die Gesamtmenge.
+     o Hat str die Form "<n> <id>", wobei <n>=1 und <id> eine SingularId
+       oder 1 < <n> <= der Gesamtmenge und <id> eine PluralId, so ist die
+       angesprochene Menge = <n>.
+     Wie gesagt, gilt dies einzig und allein bei Mengenobjekten!
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn sich das Objekt von str angesprochen fuehlt, ansonsten 0.
+
+BEISPIELE
+---------
+::
+
+     Angenommen, ein Objekt habe folgende Bezeichner:
+
+     AddId( "murmel" );
+     AddAdjective( "runde" );
+
+     Dann liefern die angegebenen id()-Aufrufe folgende Ergebnisse:
+
+     id( "murmel" );         => 1
+     id( "runde murmel" );   => 1
+     id( "kleine murmel" );  => 0
+     id( "runder ball" );    => 0
+     id( "runde murmel 2" ); => 1, wenn dies die zweite Murmel in der
+                                   gleichen Umgebung ist, ansonsten 0
+
+     Bei einem Haufen von 100 Muenzen haette man zB.:
+
+     AddId( "geld" );
+     AddSingularId( "muenze" );
+     AddPluralId( "muenzen" );
+
+     Nach fuehlen sich nach den folgenden id()-Aufrufen folgende Anzahlen
+     angesprochen:
+
+     id( "geld" );       => 100 Muenzen
+     id( "muenze" );     => 1 Muenze
+     id( "muenzen" );    => 100 Muenzen
+     id( "1 muenze" );   => 1 Muenze
+     id( "42 muenzen" ); => 42 Muenzen
+
+     id() liefert in all diesen Faellen 1 zurueck.
+
+SIEHE AUCH
+----------
+::
+
+     AddId(), AddAdjective(), AddSingularId(), AddPluralId(), present(),
+     match_ids(), /std/thing/description.c, /std/unit.c
+
+6. Sep 2012 Gloinson
+
diff --git a/doc/sphinx/lfun/init.rst b/doc/sphinx/lfun/init.rst
new file mode 100644
index 0000000..a2855e5
--- /dev/null
+++ b/doc/sphinx/lfun/init.rst
@@ -0,0 +1,91 @@
+init()
+======
+
+FUNKTION
+--------
+::
+
+	void init();
+
+DEFINIERT IN
+------------
+::
+
+	/std/room/description.c
+
+ARGUMENTE
+---------
+::
+
+	keine
+
+BESCHREIBUNG
+------------
+::
+
+	init() wird immer dann aufgerufen, wenn ein lebendes Objekt in die
+	Naehe anderer Objekte bewegt wird oder ein nicht lebendiges Objekt
+	in die Naehe von Lebewesen gelangt. init() wird dabei in allen
+	Objekten aufgerufen, bei denen es notwendig ist.
+
+	Der Hauptzweck dieser Funktion besteht darin, den Objekten
+	untereinander ihre jeweiligen Befehle zugaenglich zu machen.
+	Waehrend dies in anderen MudLibs durch eine Reihe von
+	add_action()-Aufrufen im Rumpf von init() geschah, geschieht dies in
+	der MG-MudLib bei Objekten, die /std/thing/commands.c erben
+	 (das sind zB. alle Standardobjekte) quasi automatisch
+	 (dort werden die Befehle dann per AddCmd() im create() angemeldet,
+	  man spart sich die Implementierung von init() und dem Mud somit
+	  Speicher). Der andere Weg ist aber natuerlich immer noch moeglich.
+
+RUeCKGABEWERT
+-------------
+::
+
+	keiner
+
+BEMERKUNGEN
+-----------
+::
+
+	Der Ablauf der init()-Kette ist wie folgt:
+	o Ist das Objekt X, welches ins Zielobjekt D bewegt wurde, ein
+	  Lebewesen, so wird in D init() aufgerufen, wobei this_player() auf
+	  X gesetzt ist.
+	o Dann wird fuer jedes Objekt C in D folgendes ausgefuehrt:
+	  + Ist C ein Lebewesen, dann wird init() in X aufgerufen, wobei
+	    this_player() auf C gesetzt ist.
+	  + Ist X ein Lebewesen, dann wird init() in C aufgerufen, wobei
+	  this_player() auf X gesetzt ist.
+	o Schliesslich wird in dem Fall, dass D lebendig ist, in X init()
+	  aufgerufen, wobei this_player() auf D gesetzt ist.
+
+BEISPIELE
+---------
+::
+
+	D sei ein Raum, in dem sich das Lebewesen L1 sowie die Gegenstaende
+	N1 und N2 befinden.
+	Betritt ein Spieler X diesen Raum, so werden folgende init()s
+	aufgerufen:
+
+	  D->init();  // this_player() == X
+	  X->init();  // this_player() == L1
+	  L1->init(); // this_player() == X
+	  N1->init(); // this_player() == X
+	  N2->init(); // this_player() == X
+
+	Gelangt dagegen ein nichtlebendiges Objekt nach D, so sieht das Ganze
+	wie folgt aus:
+
+	  X->init();    // this_player() == L1
+
+SIEHE AUCH
+----------
+::
+
+	exit(), AddCmd(), add_action(),
+  NotifyInsert()
+
+Last modified: 04.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/insert_sensitive_inv.rst b/doc/sphinx/lfun/insert_sensitive_inv.rst
new file mode 100644
index 0000000..409e1f6
--- /dev/null
+++ b/doc/sphinx/lfun/insert_sensitive_inv.rst
@@ -0,0 +1,36 @@
+insert_sensitive_inv()
+======================
+
+FUNKTION
+--------
+::
+
+     void insert_sensitive_inv(object ob, string key,
+			       int threshold, mixed *opt)
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/inventory.c
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion sucht, ob beim Hinzufuegen eines sensitiven Objekts
+     schon ein Objekt da ist, dass dieses ausloest.
+
+SIEHE AUCH
+----------
+::
+
+     P_SENSITIVE
+     InsertSensitiveObject, RemoveSensitiveObject
+     insert_sensitive_inv_trigger
+     P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY,
+     P_SENSITIVE_INVENTORY_TRIGGER
+     CheckSensitiveAttack
+
+28.Jan.2001, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/insert_sensitive_inv_trigger.rst b/doc/sphinx/lfun/insert_sensitive_inv_trigger.rst
new file mode 100644
index 0000000..8025faf
--- /dev/null
+++ b/doc/sphinx/lfun/insert_sensitive_inv_trigger.rst
@@ -0,0 +1,36 @@
+insert_sensitive_inv_trigger()
+==============================
+
+FUNKTION
+--------
+::
+
+     void insert_sensitive_inv_trigger(object ob, string key,
+				       int threshold, mixed *opt)
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/inventory.c
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion sucht, ob ein sensitives Objekt im Inventory ist,
+     das durch dieses (soeben eingefuegte) Objekt ausgeloest wird.
+
+SIEHE AUCH
+----------
+::
+
+     P_SENSITIVE
+     InsertSensitiveObject, RemoveSensitiveObject
+     insert_sensitive_inv
+     P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY,
+     P_SENSITIVE_INVENTORY_TRIGGER
+     CheckSensitiveAttack
+
+28.Jan.2001, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/int_long.rst b/doc/sphinx/lfun/int_long.rst
new file mode 100644
index 0000000..aa285b1
--- /dev/null
+++ b/doc/sphinx/lfun/int_long.rst
@@ -0,0 +1,91 @@
+int_long()
+==========
+
+FUNKTION
+--------
+::
+
+     varargs string int_long(mixed viewer, mixed viewpoint, int flags)
+
+DEFINIERT IN
+------------
+::
+
+     /std/room/description.c
+
+ARGUMENTE
+---------
+::
+
+     mixed viewer	- der Betrachter des Raumes
+     mixed viewpoint	- 0/Objekt/Array der/die Ausgangspunkt(e) des
+			  Betrachtens (und damit nicht sichtbar!)
+     int flags		- Modifikatoren fuer die Anzeige
+			  (siehe "man make_invlist", wird mit 3 verUNDet!)
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird die Beschreibung des Rauminneren erstellt. Dabei wird die
+     Langbeschreibung des Raumes, die enthaltenen Objekte (exklusive
+     aller viewpoints (normalerweise nur der Betrachter)) und Ausgaenge,
+     wenn vom Viewer eingeschaltet dargestellt.
+     Falls der Raum innerhalb eines anderen Raumes liegt und selbst
+     transparent ist, wie zusaetzlich die Kurzbeschreibung des Aussen-
+     raumes angezeigt.
+
+     Ist Viewer ein Magier mit eingeschaltetem Magiermodus, so wird der
+     Beschreibung der Dateiname des Raumes vorangestellt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Die Langbeschreibung des Raumes von innen.
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Trennung von viewer und viewpoint hat durchaus ihren Sinn. So ist
+     es zum Beispiel moeglich, einen Raum "mit den Augen eines Anderen" zu
+     betrachten. Dabei saehe man sich selbst, wenn man im Raum waere.
+
+BEISPIELE
+---------
+::
+
+     // in diesem Raum sieht man keine Mitspieler im "schau" oder beim
+     // Betreten (vielleicht ist es zu neblig)
+     // dazu werden einfach alle Interactives zu den viewpoints addiert
+     string int_long(object viewer, mixed viewpoints, int flags) {
+      if(!pointerp(viewpoints)) viewpoints=({viewpoints});
+      return ::int_long(&viewer,
+			viewpoints+
+			filter(all_inventory(this_object()),
+				     #'interactive),
+			&flags);
+     }
+
+     string int_short(object viewer, mixed viewpoints) {
+      if(!pointerp(viewpoints)) viewpoints=({viewpoints});
+      return ::int_short(&viewer,
+			 viewpoints+
+			 filter(all_inventory(this_object()),
+				      #'interactive));
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	int_short()
+     Properties:	P_INT_LONG, P_SHORT
+			P_HIDE_EXITS, P_SHOW_EXITS
+			P_TRANSPARENT
+     Kommandokette:	make_invlist(), short()
+     Sonstiges:		P_REFERENCE_OBJECT, P_WANTS_TO_LEARN
+
+11. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/int_short.rst b/doc/sphinx/lfun/int_short.rst
new file mode 100644
index 0000000..dd874b9
--- /dev/null
+++ b/doc/sphinx/lfun/int_short.rst
@@ -0,0 +1,85 @@
+int_short()
+===========
+
+FUNKTION
+--------
+::
+
+     string int_short(mixed viewer, mixed viewpoint);
+
+DEFINIERT IN
+------------
+::
+
+     /std/room/description.c
+
+ARGUMENTE
+---------
+::
+
+     mixed viewer	- der Betrachter des Raumes
+     mixed viewpoint	- 0/Objekt/Array der/die Ausgangspunkt(e) des
+			  Betrachtens (und damit nicht sichtbar!)
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird eine kurze  Beschreibung des Rauminneren erstellt. Dabei wird
+     die Kurzbeschreibung des Raumes, die enthaltenen Objekte (exklusive
+     aller viewpoints (normalerweise nur der Betrachter)) und Ausgaenge,
+     wenn vom Viewer eingeschaltet dargestellt.
+
+     Ist Viewer ein Magier mit eingeschaltetem Magiermodus, so wird der
+     Beschreibung der Dateiname des Raumes vorangestellt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Die Kurzbeschreibung des Raumes von innen.
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Trennung von viewer und viewpoint hat durchaus ihren Sinn. So ist
+     es zum Beispiel moeglich, einen Raum "mit den Augen eines Anderen" zu
+     betrachten. Dabei saehe man sich selbst, wenn man im Raum waere.
+
+BEISPIELE
+---------
+::
+
+     // in diesem Raum sieht man keine Mitspieler im "schau" oder beim
+     // Betreten (vielleicht ist es zu neblig)
+     // dazu werden einfach alle Interactives zu den viewpoints addiert
+     string int_long(object viewer, mixed viewpoints, int flags) {
+      if(!pointerp(viewpoints)) viewpoints=({viewpoints});
+      return ::int_long(&viewer,
+			viewpoints+
+			filter(all_inventory(this_object()),
+				     #'interactive),
+			&flags);
+     }
+
+     string int_short(object viewer, mixed viewpoints) {
+      if(!pointerp(viewpoints)) viewpoints=({viewpoints});
+      return ::int_short(&viewer,
+			 viewpoints+
+			 filter(all_inventory(this_object()),
+				      #'interactive));
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	int_long()
+     Properties:	P_INT_SHORT, P_SHORT
+			P_HIDE_EXITS, P_SHOW_EXITS
+     Kommandokette:	make_invlist(), short()
+     Sonstiges:		P_REFERENCE_OBJECT, P_WANTS_TO_LEARN
+
+11. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/is_class_member.rst b/doc/sphinx/lfun/is_class_member.rst
new file mode 100644
index 0000000..b44cb66
--- /dev/null
+++ b/doc/sphinx/lfun/is_class_member.rst
@@ -0,0 +1,175 @@
+is_class_member()
+=================
+
+FUNKTION
+--------
+::
+
+     int is_class_member(string|string* class);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     string/string* class	- String oder Stringarray der Klasse(n)
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird getestet, ob das Objekt in eine der in class angegebenen
+     Klassen faellt. In diesen Test werden die folgenden Eigenschaften des
+     Objektes einbezogen:
+
+       1. Die Rasse des Objektes (bei Lebewesen),
+       2. die IDs des Objektes und
+       3. die explizit angegebenen Klassen des Objektes.
+       4. einigen impliziten Klassen, die sich aus den Klassen in 3 ergeben.
+
+     Die moeglichen Klassen sind in /sys/class.h definiert. Momentan stehen
+     folgende Klassen zur Verfuegung:
+
+     CL_AMMUNITION
+          Das Objekt eignet sich als Munition.
+     CL_ANIMAL
+          Das Objekt ist ein Tier.
+     CL_ARACHNID
+          Das Objekt in ein Spinnenwesen.
+     CL_BIGBANG
+          Dieses Objekt kann mehreren Lebewesen auf einmal Schaden zufuegen.
+     CL_BIRD
+          Ein Vogel.
+     CL_CRAWLING
+          Dieses Wesen bewegt sich kriechend.
+     CL_CURSE
+          Das Objekt ist ein Fluch (zB. ein Sprachfluch).
+     CL_DEMON
+          Bei dem Objekt handelt es sich um einen Daemon.
+     CL_DISEASE
+          Eine Krankheit.
+     CL_DRAGON
+          Ein Drache.
+     CL_DWARF
+          Fuer unsere kleinen Gaeste...
+     CL_ELF
+          Elfen aller Art.
+     CL_ELEMENTAL
+          Ein Elementar irgendeiner Art. Material setzen waere angebracht.
+     CL_EXPLOSIVE
+          Bei dem Objekt handelt es sich um einen Sprengstoff.
+     CL_FELINE
+          Felinen und andere katzenartigen Lebewesen.
+     CL_FISH
+          Fische - keine Meeressaeuger!
+     CL_FLYING
+          Dieses Wesen bewegt sich fliegend.
+     CL_FROG
+          Froesche - auch gefroschte Spieler.
+     CL_GHOST
+          Geister und geisterhafte Wesen.
+     CL_GHOUL
+          Ein Ghoul. Er faellt automatisch in die Klasse CL_UNDEAD.
+     CL_GIANT
+          Ein riesiges Lebewesen.
+     CL_GNOME
+          Ein Gnom.
+     CL_GOBLIN
+          Ein Goblin.
+     CL_HOBBIT
+          Ein Hobbit.
+     CL_HOBGOBLIN
+          Ein Hobgoblin. Er faellt automatisch auch in die Klasse CL_GOBLIN.
+     CL_HUMAN
+          Ein Mensch.
+     CL_INORGANIC
+          Anorganische Lebewesen wie Metallmonster
+     CL_INSECT
+          Insekten (Nicht mit Spinnen verwechseln)
+     CL_LIVING
+          Lebewesen im allgemeinen.
+     CL_MAMMAL
+          Saeugetiere.
+     CL_MAMMAL_LAND
+          Landsaeugetiere
+     CL_MAMMAL_WATER
+          Meeressaeuger.
+     CL_ORC
+          Ein Ork.
+     CL_PLANT
+          Pflanzen und pflanzenartige Monster.
+     CL_POISON
+          Das Objekt ist selbst ein Gift
+     CL_POISONOUS
+          Das Objekt kann einen Spieler/NPC vergiften.
+     CL_REPTILE
+          Reptilien.
+     CL_SHADOW
+          Schattenwesen.
+     CL_SKELETON
+          Ein Skelett. Es faellt automatisch in die Klasse CL_UNDEAD.
+     CL_SLIME
+          Fuer Einzeller und aehnliches Schleimgetier
+     CL_SNAKE
+          Schlangen.
+     CL_SWIMMING
+          Dieses Wesen bewegt sich schwimmend.
+     CL_TROLL
+          Ein Troll.
+     CL_UNDEAD
+          Ein untotes Lebewesen.
+     CL_WALKING
+          Dieses Wesen bewegt sich gehend.
+     CL_VAMPIRE
+          Ein Vampir. Er faellt automatisch in die Klasse CL_UNDEAD.
+     CL_ZOMBIE
+          Ein Zombie. Er faellt automatisch in die Klasse CL_UNDEAD.
+
+     Implizite Klassen:
+     Bei einigen Klassen wird im AddClass() automatisch eine oder mehrere
+     weiterer Klassen hinzugefuegt und im RemoveClass() die entsprechenden
+     impliziten Klassen auch automatisch entfernt.
+     Wuenscht man diese impliziten Klassen nicht, muss man nach dem AddClass()
+     diese mittels eines entsprechenden RemoveClass() entfernen.
+     Die impliziten Klassen einer Klasse lassen sich mit Hilfe der Funktion
+     QueryImplicitClasses() in CLASSDB herausfinden:
+       CLASSDB->QueryImplicitClasses(...)
+     Momentan sind dies:
+     CL_ZOMBIE:       CL_UNDEAD
+     CL_SKELETON:     CL_UNDEAD
+     CL_GHOUL:        CL_UNDEAD
+     CL_VAMPIRE:      CL_UNDEAD
+     CL_HOBGOBLIN:    CL_GOBLIN
+     CL_MAMMAL_LAND:  CL_MAMMAL, CL_ANIMAL
+     CL_MAMMAL_WATER: CL_MAMMAL, CL_ANIMAL
+     CL_SNAKE:        CL_REPTILE
+     CL_ARACHNID:     CL_ANIMAL
+     CL_BIRD:         CL_ANIMAL
+     CL_FISH:         CL_ANIMAL
+     CL_FROG:         CL_ANIMAL
+     CL_INSECT:       CL_ANIMAL
+     CL_MAMMAL:       CL_ANIMAL
+     CL_REPTILE:      CL_ANIMAL
+     CL_SNAKE:        CL_ANIMAL
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn das Objekt in eine der angegebenen Klassen faellt, ansonsten 0.
+
+SIEHE AUCH
+----------
+::
+
+     AddClass(), RemoveClass(), /std/thing/description.c
+     P_CLASS
+
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/lfun.rst b/doc/sphinx/lfun/lfun.rst
new file mode 100644
index 0000000..98bdeba
--- /dev/null
+++ b/doc/sphinx/lfun/lfun.rst
@@ -0,0 +1,25 @@
+lfun()
+======
+
+NAME
+----
+::
+
+	lfun()
+
+DESCRIPTION
+-----------
+::
+
+	This directory contains descriptions for the lfuns used by
+	Amylaar's version of the LPC parser.
+
+	These are functions that are applied by the parser to the LPC
+	objects on various occasions.
+
+SEE ALSO
+--------
+::
+
+	efun(E), master(M), concepts(C), lpc(LPC), driver(D)
+
diff --git a/doc/sphinx/lfun/locate_objects.rst b/doc/sphinx/lfun/locate_objects.rst
new file mode 100644
index 0000000..d9040b8
--- /dev/null
+++ b/doc/sphinx/lfun/locate_objects.rst
@@ -0,0 +1,80 @@
+locate_objects()
+================
+
+FUNKTION
+--------
+::
+
+     object *locate_objects(string desc, int info);
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+     desc
+          Die Umschreibung des gesuchten Objektes.
+
+     info
+          Ist ungleich 0, wenn diese Funktion von /std/living/put_and_get.c
+          aus aufgerufen wurde.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion erweitert die Funktionalitaet von present_objects()
+     insofern, als dass es moeglich ist, auch noch Behaelter innerhalb des
+     Behaelters zu durchsuchen. Das genaue Verhalten haengt von desc ab:
+
+     Ist desc von der Form "<id>", so wird das Ergebnis von
+     present_objects(desc) zurueckgegeben.
+
+     Ist desc von der Form "<gesucht> in <id>", so wird in allen Objekten,
+     die von present_objects("<id>") erfasst wurden,
+     locate_objects("<desc>") aufgerufen. Zurueckgegeben werden alle auf
+     diese Weise gefundenen Objekte.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Array von Objekten, die auf die oben geschilderte Art und Weise
+     ermittelt wurden. Konnte kein Objekt ermittelt werden, wird ein leeres
+     Array zurueckgegeben.
+
+BEMERKUNGEN
+-----------
+::
+
+     Theoretisch sollte es moeglich sein, ueber desc rekursiv mehrere
+     Behaelterebenen erfassen zu koennen (etwa mit "schwert in beutel in
+     beutel in wargon"). In der aktuellen Implementierung klappt das jedoch
+     nicht; nach dem ersten "in" ist Schluss!
+
+BEISPIELE
+---------
+::
+
+     Was steckt alles dem Beutel, den der Spieler bei sich traegt?
+
+     object *obs;
+     obs = this_player()->locate_objects("alles in beutel");
+
+     Traegt der Spieler keinen Beutel bei sich oder ist dieser leer, so wird
+     ein leeres Array zurueckgegeben.
+
+SIEHE AUCH
+----------
+::
+
+     present_objects(), /std/container/restrictions.c
+
+
+Last modified: Wed May 8 10:20:36 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/logon.rst b/doc/sphinx/lfun/logon.rst
new file mode 100644
index 0000000..f867428
--- /dev/null
+++ b/doc/sphinx/lfun/logon.rst
@@ -0,0 +1,26 @@
+logon()
+=======
+
+SYNOPSIS
+--------
+::
+
+	int logon(void)
+
+DESCRIPTION
+-----------
+::
+
+	When the parser accepts a new connection, it first calls
+	connect() in the master object and then applies logon() to
+	the object that is returned by the master. That will usually be
+	a special login object, that is expected to clone and get going
+	a user shell or player object.
+	Should return 0 on failure, everything else means success.
+
+SEE ALSO
+--------
+::
+
+	connect(M)
+
diff --git a/doc/sphinx/lfun/long.rst b/doc/sphinx/lfun/long.rst
new file mode 100644
index 0000000..22b5291
--- /dev/null
+++ b/doc/sphinx/lfun/long.rst
@@ -0,0 +1,55 @@
+long()
+======
+
+FUNKTION
+--------
+::
+
+     varargs string long(int mode);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     int mode		- Modifikatoren fuer die Anzeige, falls this_object()
+			  ein Container ist
+			  (siehe "man make_invlist")
+
+BESCHREIBUNG
+------------
+::
+
+     Der Inhalt der Property P_LONG wird ausgewertet und zurueckgegeben.
+     Falls das Objekt ein Container und transparent (offen) ist, wird
+     zudem make_invlist() auf den Inhalt zurueckgegeben.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Die Langbeschreibung des Objektes.
+
+BEMERKUNGEN
+-----------
+::
+
+     Durch Ueberladen von long() lassen sich noch weitere Eigenschaften des
+     Objektes anzeigen. Behaelter koennen zum Beispiel noch ihren Inhalt
+     anzeigen, Lebewesen ihren Gesundheitszustand, o.ae.
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	short()
+     Properties:	P_LONG, P_INVIS, P_TRANSPARENT
+     Sonstiges:		make_invlist()
+
+11. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/make_immortal.rst b/doc/sphinx/lfun/make_immortal.rst
new file mode 100644
index 0000000..97b225f
--- /dev/null
+++ b/doc/sphinx/lfun/make_immortal.rst
@@ -0,0 +1,44 @@
+make_immortal()
+===============
+
+FUNKTION
+--------
+::
+
+     void make_immortal();
+
+DEFINIERT IN
+------------
+::
+
+     /std/npc/combat.c
+
+BESCHREIBUNG
+------------
+::
+
+     Macht den NPC fuer 5 Minuten unangreifbar und heilt ihn.
+
+     Wird bei Fehlern im Herzschlag des NPCs gerufen um Bugnutzung
+     zu unterbinden.
+
+     Ausschrift:
+     "... versteckt sich hinter einem Fehler im Raum-Zeit-Gefuege und
+      entgeht so voruebergehend allen Angriffen."
+
+BEMERKUNGEN
+-----------
+::
+
+     Nicht missbrauchen.
+
+SIEHE AUCH
+----------
+::
+
+     Methoden:       heart_beat(), static _check_immortality()
+     Master:         heart_beat_error()
+     Properties:     "time_to_mortality"
+
+1.Juni 2007 Gloinson
+
diff --git a/doc/sphinx/lfun/make_invlist.rst b/doc/sphinx/lfun/make_invlist.rst
new file mode 100644
index 0000000..94dc5bd
--- /dev/null
+++ b/doc/sphinx/lfun/make_invlist.rst
@@ -0,0 +1,59 @@
+make_invlist()
+==============
+
+FUNKTION
+--------
+::
+
+     varargs mixed make_invlist(object viewer, mixed inv, int flags)
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/description.c
+
+ARGUMENTE
+---------
+::
+
+     object viewer	- das Objekt, welches sich den Inhalt ansieht (in
+			  der Regel this_player())
+     mixed inv		- ein Array von Objekten, die in die Liste
+			  aufgenommen werden sollen
+     int flags		- Folgende Werte koennen verODERt werden:
+			  1: das Inv nicht als String, sondern als ein
+			     Array zurueckgeben
+			  2: gleiche Objekte nicht zusammengefassen
+			  4: unterdrueckt die Ausgabe des Dateinamens hinter
+			     jedem trotz eingeschaltetem Magiermodus
+
+BESCHREIBUNG
+------------
+::
+
+     Die Kurzbeschreibungen der Objekte in inv werden zu einer Liste
+     zusammengefasst (eine Zeile pro Objekt). Unsichtbare Objekte tauchen in
+     dieser Liste nicht auf.
+
+     Ist viewer ein Magier mit eingeschaltetem Magiermodus, so wird hinter
+     die Kurzbeschreibungen noch der Dateiname des jeweiligen Objektes in
+     eckigen Klammern angegeben. Unsichtbare Objekte erscheinen in diesem
+     Fall als Filenamen.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Ein String oder ein Array, die das inv beschreiben.
+
+SIEHE AUCH
+----------
+::
+
+     Kommandokette:	short()
+     Properties:	P_SHORT, P_INVIS, P_WANTS_TO_LEARN
+     Sonstiges:		P_REFERENCE_OBJECT
+
+Last modified: Tue Oct 15 10:10:00 2002 by Rikus
+
diff --git a/doc/sphinx/lfun/master/AddWizardForUID.rst b/doc/sphinx/lfun/master/AddWizardForUID.rst
new file mode 100644
index 0000000..3e9f504
--- /dev/null
+++ b/doc/sphinx/lfun/master/AddWizardForUID.rst
@@ -0,0 +1,74 @@
+AddWizardForUID()
+=================
+
+FUNKTION
+--------
+::
+
+    string* AddWizardForUID(string uid, string wizard);
+
+DEFINIERT IN
+------------
+::
+
+    /secure/master/userinfo.c
+
+ARGUMENTE
+---------
+::
+
+    uid
+      Die UID, fuer die man einen (weiteren) verantwortlichen Magier
+      explizit eintragen moechte.
+    wizard
+      Der Magier, den man eintragen moechte.
+
+BESCHREIBUNG
+------------
+::
+
+    Die Funktion traegt einen Magier 'wizard' explizit als verantwortlichen
+    Magier fuer die UID 'uid' ein. Hierbei kann 'uid' sogar der Name eines
+		anderen Magiers sein, dessen UIDs 'wizard' sozusagen "adoptiert".
+
+		Berechtigt zum Eintragen von Magiern fuer bestimmte UIDs sind alle Magier,
+    die (implizit oder explizit) verantwortlich fuer die jeweilige UID sind.
+    Z.B. kann Zesstra ohne weiteres jemand weiteren als verantwortlich fuer
+    d.inseln.zesstra eintragen.
+
+RUeCKGABEWERT
+-------------
+::
+
+    Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID,
+    fuer die dier Magier jetzt explizit eingetragen ist.
+
+BEMERKUNGEN
+-----------
+::
+
+    Es ist nicht noetig, z.B. Zesstra als verantwortlich fuer d.inseln.zesstra
+    einzutragen, da sie ohnehin schon implizit dafuer zustaendig ist. Auch
+    fuer RMs bzw. GMs muss ihre Region bzw. Gilde nicht explizit eingetragen 
+    werden.
+
+BEISPIELE
+---------
+::
+
+    master()->AddWizardForUID("p.waterluh","zook");
+
+		
+
+		string *uids = master()->AddWizardForUID("jof","zook");
+    printf("Zook ist nun explizit zustaendig fuer: %s\n",CountUp(uids));
+
+SIEHE AUCH
+----------
+::
+
+    QueryWizardsForUID(), QueryUIDsForWizard,
+		RemoveWizardFromUID()
+
+20.02.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/master/QueryUIDAlias.rst b/doc/sphinx/lfun/master/QueryUIDAlias.rst
new file mode 100644
index 0000000..04a4057
--- /dev/null
+++ b/doc/sphinx/lfun/master/QueryUIDAlias.rst
@@ -0,0 +1,65 @@
+QueryUIDAlias()
+===============
+
+FUNKTION
+--------
+::
+
+    varargs string* QueryUIDsForWizard(string uidalias, int recursive);
+
+DEFINIERT IN
+------------
+::
+
+    /secure/master/userinfo.c
+
+ARGUMENTE
+---------
+::
+
+    uidalias
+      UID, die expandiert werden soll.
+    recursive (optional)
+      Gibt an, ob QueryUIDAlias() (indirekt) rekursiv aufgerufen wurde.
+      Sollte normalerweise nicht per Hand gesetzt werden.
+
+BESCHREIBUNG
+------------
+::
+
+    Die Funktion ermittelt aus einer "Alias-UID" die UID, fuer die sie steht.
+    Hierbei werden folgende UID-Aliase beruecksichtigt:
+    "region":    d.region.* + region + d.region
+    "gilde":     GUILD.gilde, GUILD.gildenspellbook, p.gilde
+    "p":         p.* (ohne p.service)
+    "p.service": p.service.*
+    "magierid":  QueryUIDsForWizard()
+
+    Das Ergebnis dieser Funktion wird laengere Zeit gecachet (bis zu 24h).
+
+RUeCKGABEWERT
+-------------
+::
+
+    Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID.
+    Sollte uidaliase keines der o.g. sein, wird ein ({uidalias}) geliefert.
+
+BEISPIELE
+---------
+::
+
+    string *uids = master()->QueryUIDAlias("schattenwelt");
+    // uids enthaelt nun:
+    // ({"d.anfaenger","anfaenger","d.anfaenger.ark","d.anfaenger.ennox",
+    //   "d.anfaenger.humni","d.anfaenger.kiria","d.anfaenger.konzepte",
+    //   "d.anfaenger.miril"})
+
+SIEHE AUCH
+----------
+::
+
+    QueryWizardsForUID(), 
+		AddWizardForUID(), RemoveWizardFromUID()
+
+16.12.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/master/QueryUIDsForWizard.rst b/doc/sphinx/lfun/master/QueryUIDsForWizard.rst
new file mode 100644
index 0000000..0055b97
--- /dev/null
+++ b/doc/sphinx/lfun/master/QueryUIDsForWizard.rst
@@ -0,0 +1,64 @@
+QueryUIDsForWizard()
+====================
+
+FUNKTION
+--------
+::
+
+    varargs string* QueryUIDsForWizard(string wizname, int recursive);
+
+DEFINIERT IN
+------------
+::
+
+    /secure/master/userinfo.c
+
+ARGUMENTE
+---------
+::
+
+    wizname
+      Der Magier, fuer den man die UIDs ermitteln will, fuer die er
+      zustaendig ist.
+    recursive (optional)
+      Gibt an, ob QueryUIDsForWizard() (indirekt) rekursiv aufgerufen wurde.
+      Sollte normalerweise nicht per Hand gesetzt werden.
+
+BESCHREIBUNG
+------------
+::
+
+    Die Funktion ermittelt die UIDs, fuer die dieser Magier zustaendig ist.
+    Dabei wird impliziert beruecksichtigt, wenn der Magier RM einer Region
+    oder Gildenmagier einer Gilde ist, ebenso wie Verzeichnisse in den
+    Regionen oder in /p/service.
+    Ausserdem wird nachgeschaut, fuer welche UIDs dieser Magier explizit
+    eingetragen worden ist.
+    Wenn z.B. Magier A auch fuer alle UIDs von Magier B zustaendig sein
+    sollte, liefert die Funktion auch die UIDs von B zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+    Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID.
+    Sollte fuer einen Namen keine UID ermittelbar sein, ist das Arrays leer.
+
+BEISPIELE
+---------
+::
+
+    string *uids = master()->QueryUIDsForWizard("ennox");
+    // uids enthaelt nun:
+    // ({"ennox","d.anfaenger.ennox","d.schattenwelt.ennox",
+    //   "p.service.ennox","GUILD.chaos","p.chaos"})
+
+SIEHE AUCH
+----------
+::
+
+    QueryWizardsForUID(), 
+		AddWizardForUID(), RemoveWizardFromUID()
+
+16.12.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/master/QueryWizardsForUID.rst b/doc/sphinx/lfun/master/QueryWizardsForUID.rst
new file mode 100644
index 0000000..4d8179d
--- /dev/null
+++ b/doc/sphinx/lfun/master/QueryWizardsForUID.rst
@@ -0,0 +1,71 @@
+QueryWizardsForUID()
+====================
+
+FUNKTION
+--------
+::
+
+    varargs string* QueryWizardsForUID(string uid, int recursive);
+
+DEFINIERT IN
+------------
+::
+
+    /secure/master/userinfo.c
+
+ARGUMENTE
+---------
+::
+
+    uid
+      Die UID, fuer die man die Magier ermitteln will, die fuer sie
+      zustaendig sind.
+    recursive (optional)
+      gibt an, ob das QueryWizardsForUID() (indirekt) aus einem 
+      QueryWizardsForUID() heraus gerufen wurde. Sollte nicht manuell gesetzt
+      werden.
+
+BESCHREIBUNG
+------------
+::
+
+    Die Funktion ermittelt die Magier, die fuer diese UID zustaendig sind.
+
+RUeCKGABEWERT
+-------------
+::
+
+    Zurueckgeliefert wird ein Array von Strings, jedes Element ist ein Magier.
+    Sollte fuer eine UID kein Magier ermittelbar sein, ist das Array leer.
+    Wenn z.B. fuer die UID der Magier "Atamur" gefunden wird, aber fuer alle 
+    UIDs von "Atamur" auch der Magier "Rumata" zustaendig sein sollte, wird 
+    "Rumata" ueber eine rekursive Suche gefunden.
+
+BEMERKUNGEN
+-----------
+::
+
+    Wenn die UID den Magier nicht implizit enthaelt (z.B. GUILD.gilde, im 
+    Gegensatz zu d.region.magier), findet diese Funktion nur Magier, fuer die 
+    seit Laden des Master bereits einmal get_userinfo() oder 
+    QueryUIDsForWizard() im Master gerufen wurde, was z.B. Einloggen passiert.
+    Magier, die lang nicht einloggten, werden also manchmal nicht gefunden,
+    was in der Regel nicht schlimm sein sollte, da sie ja ohnehin den
+    entsprechenden Code gerade nicht warten...
+
+BEISPIELE
+---------
+::
+
+    string *wiz = master()->QueryWizards("GUILD.klerus");
+    // wiz enthaelt nun: ({"morgoth","magdalena"})
+
+SIEHE AUCH
+----------
+::
+
+    QueryUIDsForWizard(), 
+		AddWizardForUID(), RemoveWizardFromUID()
+
+16.12.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/master/RemoveWizardFromUID.rst b/doc/sphinx/lfun/master/RemoveWizardFromUID.rst
new file mode 100644
index 0000000..406f3cf
--- /dev/null
+++ b/doc/sphinx/lfun/master/RemoveWizardFromUID.rst
@@ -0,0 +1,62 @@
+RemoveWizardFromUID()
+=====================
+
+FUNKTION
+--------
+::
+
+    string* RemoveWizardFromUID(string uid, string wizard);
+
+DEFINIERT IN
+------------
+::
+
+    /secure/master/userinfo.c
+
+ARGUMENTE
+---------
+::
+
+    uid
+      Die UID, fuer die man einen zustaendigen Magier austragen will.
+    wizard
+      Der Magier, den man austragen moechte.
+
+BESCHREIBUNG
+------------
+::
+
+    Die Funktion loescht die UID 'uid' aus der Liste der UIDs, fuer die
+    'wizard' explizit zustaendig ist.
+
+    Berechtigt zum Austragen von Magiern fuer bestimmte UIDs sind alle Magier,
+    die (implizit oder explizit) verantwortlich fuer die jeweilige UID sind.
+    Man kann sich auch selber austragen. ;-)
+
+RUeCKGABEWERT
+-------------
+::
+
+    Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID,
+    fuer die dier Magier jetzt explizit eingetragen ist.
+
+BEISPIELE
+---------
+::
+
+    master()->RemoveWizardFromUID("p.waterluh","zook");
+
+		
+
+    string *uids = master()->RemoveWizardFromUID("jof","zook");
+    printf("Zook ist nun explizit zustaendig fuer: %s\n",CountUp(uids));
+
+SIEHE AUCH
+----------
+::
+
+    QueryWizardsForUID(), QueryUIDsForWizard()
+		AddWizardForUID()
+
+20.02.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/match_ids.rst b/doc/sphinx/lfun/match_ids.rst
new file mode 100644
index 0000000..556233a
--- /dev/null
+++ b/doc/sphinx/lfun/match_ids.rst
@@ -0,0 +1,70 @@
+match_ids()
+===========
+
+FUNKTION
+--------
+::
+
+     int match_ids(string *list);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     *list	String-Array mit zu testenden IDs
+
+BESCHREIBUNG
+------------
+::
+
+     Die Liste der uebergebenen IDs wird mit den IDs des Objektes
+     UND-Verknuepft. Die Groesse des resultierenden Arrays wird
+     zurueckgegeben.
+     Diese Funktion erlaubt also das gleichzeitige Pruefen auf
+     mehrere IDs. Allerdings werden - im Gegensatz zu id() -
+     Adjektive und Ausdruecke der Art "<ID> <nummer>" nicht
+     beruecksichtigt.
+     Ebenso werden Spezialitaeten wie Unitobjekte und Objekte mit
+     ueberschriebenem id() nicht beruecksichtigt! Im Zweifelsfall ist daher
+     doch die Nutzung von id() zu empfehlen.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Anzahl der zutreffenden IDs.
+
+BEISPIELE
+---------
+::
+
+     Angenommen, ein Objekt habe folgende Bezeichner:
+
+     AddId( ({"murmel","kugel","glasmurmel","glaskugel"}) );
+     AddAdjective( "rund" );
+
+     Dann liefern die angegebenen match_ids()-Aufrufe folgende Ergebnisse:
+
+     match_ids( ({"murmel","stein"}) );         => 1
+     match_ids( ({"murmel","kugel"}) );         => 2
+     match_ids( ({"runde murmel"}) );           => 0
+     match_ids( ({"murmel 2"}) );               => 0, auch wenn dies die 
+                                               zweite Murmel in der
+                                               gleichen Umgebung ist
+
+SIEHE AUCH
+----------
+::
+
+     AddId(), AddAdjective(), AddSingularId(), AddPluralId(), present(),
+     id(), /std/thing/description.c, /std/unit.c
+
+
+Last modified: Sat Mar 15 21:40:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/lfun/move.rst b/doc/sphinx/lfun/move.rst
new file mode 100644
index 0000000..6f427d1
--- /dev/null
+++ b/doc/sphinx/lfun/move.rst
@@ -0,0 +1,241 @@
+move()
+======
+
+move()
+
+FUNKTION: 
+     Fuer unbelebte Gegenstaende (/std/thing):
+       varargs int move(object|string dest, int method);
+
+     Fuer Lebewesen (/std/living, /std/npc, usw.):
+       varargs int move(object|string dest, int method, string dir, 
+                        string textout, string textin);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/moving.c
+     /std/living/moving.c
+
+ARGUMENTE
+---------
+::
+
+     dest
+          Das Zielobjekt (entweder der Dateiname oder das Objekt selbst).
+
+     method
+          Die Art der Bewegung (eine der unten aufgefuehrten Arten; es
+          koennen auch mehrere zusammenge-ODER-t werden).
+
+     dir
+          Die Richtung, in die ein Lebewesen geht. Normalerweise ist das die
+          eingeschlagene Laufrichtung (zB. "nach Norden").
+
+     textout
+          Verlaesst ein Lebewesen einen Raum, so wird diese Meldung in den
+          Raum geschickt. Ist bei dir ein String angegeben, so wird dieser
+          noch an textout angehaengt. Der Name des Lebewesens wird der
+          Meldung in jedem Fall vorangestellt.
+
+     textin
+          Dieser Text wird im Zielraum ausgegeben, wenn ein Lebewesen ihn
+          betritt. Bei normaler Fortbewegung ist das "kommt an". Dem Text
+          wird noch der Name des Spielers vorangestellt.
+
+BESCHREIBUNG
+------------
+::
+
+     Es wird versucht, das Objekt in das Zielobjekt dest zu bewegen.
+     Abhaengig vom momentanen Aufenthaltsort und dem Zielobjekt ist die
+     Bewegungsmethode method zu waehlen.
+
+     In <moving.h> sind folgende Konstanten fuer die Art der Bewegung
+     definiert:
+     M_NOCHECK
+          Es werden keine Abfragen durchgefuehrt, ob das Objekt ueberhaupt
+          in das Zielobjekt hineinpasst (was zB. aus Gewichtsgruenden der
+          Fall sein koennte).
+
+     M_GO
+          Ein Lebewesen bewegt sich gehend von einem Raum in den naechsten.
+          Bei normalem Gehen wird diese Methode benutzt; man sollte sie auch
+          benutzen, wenn man Spieler ueber einen SpecialExit in einen
+          benachbarten Raum bewegt.
+
+     M_TPORT
+          Ein Lebewesen wird von einem Raum in einen anderen teleportiert.
+          Im Gegensatz zu M_GO kann ein Raum verhindern, dass man ihn
+          mittels M_TPORT verlaesst oder betritt.
+
+     M_NO_SHOW
+          Beim Bewegen von Lebewesen bekommen diese die Beschreibung des
+          Zielraumes nicht ausgegeben.
+
+     M_NO_ATTACK
+          Beim Bewegen von Lebewesen bekommen diese keinen
+          Begruessungsschlag, wenn ein Feind im Zielraum steht.
+
+     M_SILENT
+          Es werden beim Bewegen keine Meldungen ausgegeben. Dieser
+          Parameter wirkt sich nur auf das Bewegen von Lebenwesen aus.
+
+     M_GET
+          Das Objekt wird von einem unbelebten Objekt (zB. einem Raum, einer
+          Leiche, einem Beutel) in ein lebendes Objekt (Spieler oder NPC)
+          bewegt.
+
+     M_PUT
+          Das Objekt wird von einem lebenden Objekt in ein unbelebtes Objekt
+          bewegt.
+
+     M_GIVE
+          Das Objekt wird von einem Lebewesen an ein anderes Lebewesen
+          weitergereicht.
+
+     M_MOVE_ALL (Nur fuer Objekte, die /std/unit.c erben)
+          Es wird die gesamte Menge bewegt, nicht nur ein Teil.
+
+     Soll das Objekt auf jeden Fall und ohne jede Abfrage bewegt werden, so
+     reicht es, als method M_NOCHECK zu uebergeben.
+
+     Waffen und Ruestungen werden, soweit sie gezueckt bzw. angezogen sind,
+     beim Bewegen auf jeden Fall weggesteckt bzw. ausgezogen. Ist in method
+     M_SILENT enthalten, so geschieht dies ohne Meldungen.
+
+     Die erste Art des Funktionsaufrufs ist sowohl beim Bewegen von
+     Lebewesen als auch von unbelebten Objekten moeglich. Die zweite Art
+     laesst sich nur bei Lebewesen anwenden.
+
+ANMERKUNG
+---------
+::
+
+     Diese Funktion sollte nicht (mehr) ueberschrieben werden. Stattdessen
+     greift bitte auf PreventMove() und NotifyMove() zurueck. RMs sind
+     aufgerufen, Objekt mit ueberschriebenen move() nur noch dann
+     anzuschliessen, wenn der Zweck sonst nicht erreicht werden kann. Solltet
+     ihr move() ueberschreiben: Seid euch sehr genau im klaren, was move()
+     genau macht. ;-)
+
+     
+
+     Wenn Livings bewegt werden, sorgt move() automatisch in Abhaengigkeit
+     von P_PARA dafuer, dass das Lebewesen in der korrekten (Parallel-)Welt
+     landet.
+
+     Bei Gegenstaenden wird ebenfalls versucht, die richtige Zielwelt
+     auszuwaehlen (damit z.B. in der Parallelwelt geworfene Bumerangs auch nur
+     innerhalb der Parallelwelt fliegen). Um Rechenzeit zu sparen, wird das
+     allerdings nur versucht, wenn 'dest' ein Filename ist und kein Objekt.
+
+     Grund: bei Zielobjekten handelt es sich meist um Bewegungen in das Inv
+     oder Env eines Spielers - und die sind uninteressant. Raumwechsel dagegen
+     erfolgen fast immer unter Angabe eines Filenamens anstatt eines Objektes.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Alle Rueckgabewerte sind als symbolische Konstanten in <moving.h>
+     definiert. (MOVE_OK ist 1, alle anderen sind <0 und symbolisieren Fehler.
+     Traditionell erfolgt die Pruefung auf erfolgreiches Move mit == 1, in
+     Zukunft wird == MOVE_OK empfohlen.)
+
+     
+
+     MOVE_OK
+          Die Bewegung wurde erfolgreich abgeschlossen.
+
+     ME_PLAYER
+          Lebewesen lassen sich nicht ohne weiteres bewegen. Es muss
+          mindestens eine der Methoden M_NOCHECK, M_GO oder M_TPORT
+          angegeben werden.
+
+     ME_TOO_HEAVY
+          Das Zielobjekt kann dieses Objekt aus Gewichtsgruenden nicht mehr
+          aufnehmen.
+
+     ME_CANT_TPORT_IN
+          Das Zielobjekt verbietet das Teleportieren in sich hinein (nur bei
+          M_TPORT ohne M_NOCHECK).
+
+     ME_CANT_TPORT_OUT
+          Der Raum, in dem sich das Lebewesen befindet, verbietet das
+          Teleportieren aus sich hinaus (nur bei M_TPORT ohne M_NOCHECK).
+
+     ME_CANT_BE_DROPPED
+          Das Objekt kann nicht fallen gelassen werden (zB. weil P_NODROP
+          gesetzt ist).
+
+     ME_CANT_BE_TAKEN
+          Das Objekt kann nicht genommen werden (zB. weil P_NOGET gesetzt
+          ist).
+
+     ME_CANT_BE_INSERTED
+          Das Zielobjekt verhindert das Einfuegen aus bestimmten Gruenden.
+
+     ME_CANT_LEAVE_ENV
+          Der Container verhindert ein verlassen des Objektes
+
+     ME_TOO_HEAVY_FOR_ENV
+          Ein Objekt kann einen Behaelter nicht verlassen, da es dem 
+          Lebewesen sonst zu schwer wuerde.
+
+     TOO_MANY_OBJECTS
+          Das Zielobjekt kann soviele Objekte nicht mehr aufnehmen.
+
+     ME_NOT_ALLOWED
+          Raeume mit gesetzter Property P_NO_PLAYERS koennen nur von
+          Testspielern und Magiern betreten werden. Bei Spielern oder
+          Gildentesties gibt es diese Fehlermeldung.
+     ME_WAS_DESTRUCTED
+          Das Objekt hat sich entweder im Verlaufe der Bewegung selbst
+          zerstoert oder wurde zerstoert, sodass move() nicht erfolgreich
+          beendet werden konnte. (Bsp: sensitive Objekte)
+
+     ME_DONT_WANT_TO_BE_MOVED
+          Das Objekt moechte nicht bewegt werden.
+
+BEISPIELE
+---------
+::
+
+        o Ein Objekt "gibt sich" dem Spieler:
+
+          move(this_player(), M_GET);
+
+        o Ein Lebewesen wird in die Abenteurergilde teleportiert:
+
+          lv->move("/gilden/abenteurer", M_TPORT);
+
+        o Ein Spieler "wird in die Gilde gegangen":
+
+          this_player()->move("/gilden/abenteurer", M_GO, "in die Gilde");
+
+          Spieler, die mit ihm im gleichen Raum stehen, sehen folgende
+          Meldung:
+          "<name> geht in die Gilde."
+
+        o Ein Spieler schwimmt durchs Meer:
+
+          this_player()->move("meer_xy", M_GO, "nach Norden", "schwimmt",
+                              "schwimmt herein");
+
+          Spieler in seinem Startraum sehen "<name> schwimmt nach Norden.",
+          Spieler in seinem Zielraum sehen "<name> schwimmt herein."
+
+SIEHE AUCH
+----------
+::
+
+     move_object(), remove(), setmin, setmmin, setmout, setmmout, review,
+     PreventInsert(), PreventLeave(), PreventInsertLiving(),
+     PreventLeaveLiving(), PreventMove(), NotifyInsert(), NotifyLeave(),
+     NotifyMove(), NotifyRemove(), init(), exit(),
+     P_NO_PLAYERS, P_PARA, /std/thing/moving.c, /std/living/moving.c
+     -----------------------------------------------------------------------
+2015-Jan-19, Arathorn
+
diff --git a/doc/sphinx/lfun/moved_objects.rst b/doc/sphinx/lfun/moved_objects.rst
new file mode 100644
index 0000000..8a3f972
--- /dev/null
+++ b/doc/sphinx/lfun/moved_objects.rst
@@ -0,0 +1,53 @@
+moved_objects()
+===============
+
+FUNKTION
+--------
+::
+
+    public object *moved_objects(void);
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+    keine
+
+BESCHREIBUNG
+------------
+::
+
+    Mit dieser Funktion lassen sich die Objekte ermitteln, die das Lebewesen
+    beim letzten Aufruf von drop_objects(L) oder einer aehnlichen Funktion
+    bewegt hat.
+
+RUECKGABEWERT
+-------------
+::
+
+    Array mit den zuletzt bewegten Objekten, oder ein leeres Array, falls
+    keine Objekte auf die Beschreibung des letzten drop_objects() / 
+    pick_objects() / put_objects() / give_objects() passten.
+
+BEISPIELE
+---------
+::
+
+    siehe drop_objects() und give_objects()
+
+SIEHE AUCH
+----------
+::
+
+    drop_objects(L), give_objects(L), pick_objects(L), put_objects(L),
+    show_objects(L), NotifyMove(L)
+
+
+Last modified: Thu Aug 28 22:19:26 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/moved_where.rst b/doc/sphinx/lfun/moved_where.rst
new file mode 100644
index 0000000..1d3757f
--- /dev/null
+++ b/doc/sphinx/lfun/moved_where.rst
@@ -0,0 +1,51 @@
+moved_where()
+=============
+
+FUNKTION
+--------
+::
+
+    public object moved_where(void);
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+    keine
+
+BESCHREIBUNG
+------------
+::
+
+    Mit dieser Funktion laesst sich ermitteln, wohin das Lebewesen zuletzt
+    mittels put_objects(L) oder give_objects(L) etwas bewegt oder wem es mit
+    show_objects(L) etwas gezeigt hat.
+
+RUECKGABEWERT
+-------------
+::
+
+    Der Container oder das Lebewesen, wohin die Gegenstaende bewegt wurden.
+
+BEISPIEL
+--------
+::
+
+    siehe give_objects()
+
+SIEHE AUCH
+----------
+::
+
+    put_objects(L), give_objects(L), show_objects(L), NotifyInsert(L),
+    P_LAST_CONTENT_CHANGE
+
+
+Last modified: Thu Aug 28 22:16:15 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/muster.rst b/doc/sphinx/lfun/muster.rst
new file mode 100644
index 0000000..a847bcd
--- /dev/null
+++ b/doc/sphinx/lfun/muster.rst
@@ -0,0 +1,41 @@
+muster()
+========
+
+FUNKTION
+--------
+::
+
+	type muster(...)
+
+	
+
+ARGUMENTE
+---------
+::
+
+	
+
+BESCHREIBUNG
+------------
+::
+
+RUECKGABEWERT
+-------------
+::
+
+	
+
+BEMERKUNG
+---------
+::
+
+	
+
+BEISPIEL
+--------
+::
+
+SIEHE AUCH
+----------
+::
+
diff --git a/doc/sphinx/lfun/name.rst b/doc/sphinx/lfun/name.rst
new file mode 100644
index 0000000..ff349bc
--- /dev/null
+++ b/doc/sphinx/lfun/name.rst
@@ -0,0 +1,82 @@
+name()
+======
+
+name()|Name()
+
+FUNKTION
+--------
+::
+
+     varargs string name(int casus, int demon);
+     varargs string Name(int casus, int demon);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     casus
+          Der Fall, in dem der Name dekliniert werden soll.
+     demon
+          Gibt an, ob der Name mit bestimmtem oder unbestimmtem Artikel
+          versehen werden soll:
+             + demon = 0: Unbestimmter Artikel.
+             + demon = 1: Bestimmter Artikel.
+             + demon = 2: Finde selbst heraus, ob ein bestimmter oder ein
+               unbestimmter Artikel verwendet werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion ermittelt den Namen des Objektes im gewuenschten Fall
+     und mit dem angegebenen Artikel. Moegliche Werte fuer casus sind in
+     <thing/language.h> definiert. Weiterhin werden auch (falls angegeben)
+     die Namensadjektive dekliniert und in den Namen eingebaut.
+
+     Name() ist ein Alias fuer capitalize(name()), der Artikel wird also
+     gross geschrieben.
+
+RUeCKGABEWERT
+-------------
+::
+
+     String mit dem Namen des Objektes.
+
+BEMERKUNGEN
+-----------
+::
+
+     Falls P_ARTICLE gesetzt ist, werden weder Artikel noch Namensadjektive
+     in den Namen eingebaut.
+
+     Wenn man als casus RAW angibt, wird der Name im Nominativ ohne Artikel
+     und Namensadjektive zurueckgegeben.
+
+BEISPIELE
+---------
+::
+
+     Wenn das Objekt ein Ball mit P_NAME="Ball" und P_NAME_ADJ="klein" ist,
+     so liefern die folgenden Aufrufe die angegebenen Ergebnisse:
+
+     name(WER,0);    => "ein kleiner Ball"
+     name(WESSEN,1); => "des kleinen Balls"
+     name(RAW);      => "Ball"
+     name(WEM,2);    => "einem kleinen Ball" oder "dem kleinen Ball",
+                        abhaengig davon, wieviele Baelle gerade da sind.
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/description.c, Name()
+
+
+Letzte Aenderung: 29.07.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/notify_player_change.rst b/doc/sphinx/lfun/notify_player_change.rst
new file mode 100644
index 0000000..3e81053
--- /dev/null
+++ b/doc/sphinx/lfun/notify_player_change.rst
@@ -0,0 +1,84 @@
+notify_player_change()
+======================
+
+void notify_player_change(string/object who, int rein [, int invis])
+
+FUNKTION
+--------
+::
+
+    void /notify_player_change(object who, int rein)
+    void /std/player/base::notify_player_change(string who, int rein,
+                                                int invis)
+
+  
+
+GERUFEN VON
+-----------
+::
+
+    /std/player/base.c (d.h. alle Spielershells/-Objekte)
+
+ARGUMENTE
+---------
+::
+
+    string who
+      getuid() eines Spielers
+    object who
+      Spieler-Objekt
+    int rein
+      0 fuer das MUD verlassende, 1 fuer hereinkommende Spieler
+    int invis
+      1 fuer unsichtbare Spieler (Magier)
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion wird von Lebewesen fuer hereinkommende und das Spiel
+    verlassende Spieler an verschiedenen Stellen aufgerufen:
+
+    
+
+    * in anderen Spielern mit notify_player_change() mit drei Parametern
+      - dies dient fuer die "erwarte"-Funktionalitaet
+    * in der Gilde des Spielern mit zwei Parameter
+      - damit koennen Gilden notwendige Anpassungen vornehmen
+
+    Diese Funktionen werden auch gerufen, wenn Magier "invis -e" bzw.
+    "vis e" benutzen.
+
+BEISPIELE
+---------
+::
+
+    // in einer Gilde:
+    void notify_player_change(object pl, int rein) {
+      if (rein && objectp(pl)) {
+        // Checks, ob Spielerskills in Ordnung sind
+        mapping bete = pl->QuerySkill("bete");
+
+        
+
+        if (!mappingp(bete)) {
+          if (IS_LEARNER(pl) || pl->QueryProp(P_TESTPLAYER)) {
+            tell_object(pl, break_string(
+              "Du bist ein kaputter Test-Kleriker ...", 78,
+              "Arkshat teilt dir mit: "));
+            // notduerftige Reparaturen
+          } else
+            raise_error("Klerus: Kaputter oder gesetzer Kleriker!\n");
+        }
+      }
+    }
+
+SIEHE AUCH
+----------
+::
+
+    RegisterEvent mit (EVT_LIB_LOGIN, EVT_LIB_LOGOUT)
+    erwarte
+
+1. Sep 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/obsolete/AddHpHook.rst b/doc/sphinx/lfun/obsolete/AddHpHook.rst
new file mode 100644
index 0000000..d2f09ef
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/AddHpHook.rst
@@ -0,0 +1,52 @@
+AddHpHook()
+===========
+
+********************* OBSOLETE LFUN ***********************************
+* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die       *
+* Hooks (s. /doc/std/hooks).                                          *
+***********************************************************************
+AddHpHook()
+
+FUNKTION
+--------
+::
+
+     int AddHpHook(object ob)
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/life.c
+
+ARGUMENTE
+---------
+::
+
+     ob - das Objekt, das sich eintragen moechte.
+
+BESCHREIBUNG
+------------
+::
+
+     Traegt ein Objekt in P_HP_HOOKS ein, wenn es nicht schon darin steht.
+
+     Aendern sich beim Spieler dann HP oder KP (nicht durch Set()), wird
+     an allen eingetragenen Objekten NotifyHpChange() gerufen.
+
+RUECKGABEWERT
+-------------
+::
+
+     1, wenn Erfolg, 0 sonst
+
+SIEHE AUCH
+----------
+::
+
+     Gegenpart:	RemoveHpHook()
+     Props:	P_HP_HOOKS, P_HP
+     Verwandt:	reduce_hit_points(), do_damage(), buffer_hp()
+
+23.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/obsolete/AddInsertHook.rst b/doc/sphinx/lfun/obsolete/AddInsertHook.rst
new file mode 100644
index 0000000..143efc9
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/AddInsertHook.rst
@@ -0,0 +1,88 @@
+AddInsertHook()
+===============
+
+********************* OBSOLETE LFUN ***********************************
+* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die       *
+* Hooks (s. /doc/std/hooks).                                          *
+***********************************************************************
+AddInsertHook()
+
+FUNKTION
+--------
+::
+
+     void AddInsertHook(object ob);
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+     ob - Das Objekt, das informiert werden soll, wenn ein Objekt dem
+          Spielerinventar hinzugefuegt wurde.
+
+BESCHREIBUNG
+------------
+::
+
+     (Diese Funktionalitaet wurde ersetzt durch den allgemeinen Hook
+      H_HOOK_INSERT und ist nur noch aus Gruenden der Kompatibilitaet
+      vorhanden.)
+
+     Diese Funktion wird im Spielerobjekt aufgerufen, um das Objekt ob als
+     Hook-Listener anzumelden. Auf diese Weise eingetragene Listener
+     werden informiert, wenn ein Objekt ins Spielerinventar bewegt wurde.
+     Technisch wird die Bewegung ueber NotifyInsert() im Spielerobjekt
+     detektiert, und im Listener-Objekt wird die Funktion InsertNotify()
+     gerufen, die als Parameter das neu ins Spielerinventar bewegte Objekt
+     uebergeben bekommt.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEMERKUNGEN
+-----------
+::
+
+     Das Listener-Objekt muss sich ebenfalls im Spielerinventar befinden,
+     ansonsten wird der eingetragene Hook wieder geloescht.
+
+BEISPIEL
+--------
+::
+
+     
+
+     a) Objekt "ob" wird im Spieler als Listener angemeldet:
+        this_player()->AddInsertHook(ob);
+
+     b) Objekt "new" wird ins Spielerinventar bewegt, das Spielerobjekt
+        informiert "ob" darueber:
+        ob->InsertNotify(new);
+
+     c) Das Listener-Objekt "ob" reagiert darauf, z.B. indem es die Fackel
+        loescht, sofern sie vorher brannte:
+        void InsertNotify(object new) {
+          if ( objectp(new) && new->id("\nfackel") && 
+               new->QueryProp(P_LIGHTED) )
+            new->unlight();
+          return;
+        }
+
+SIEHE AUCH
+----------
+::
+
+    NotifyInsert(), RemoveInsertHook(), QueryInsertHooks()
+
+
+Last modified: 14.04.2010, Arathorn
+
diff --git a/doc/sphinx/lfun/obsolete/ModifySkillAttributeOld.rst b/doc/sphinx/lfun/obsolete/ModifySkillAttributeOld.rst
new file mode 100644
index 0000000..948a6d9
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/ModifySkillAttributeOld.rst
@@ -0,0 +1,119 @@
+ModifySkillAttributeOld()
+=========================
+
+FUNKTION
+--------
+::
+
+    varargs int ModifySkillAttributeOld(object caster, string atrname, 
+                                        int value, int duration, mixed fun)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/skill_attributes.c
+
+ARGUMENTE
+---------
+::
+
+    <caster>    IGNORIERT
+                frueher Objekt, das die Modifikation vornimmt, heute ist
+                dieses Argument ohne Bedeutung und wird ignoriert.
+
+    <atrname>   STRING
+                Name des zu veraendernden Attributes
+                (Definiert in /sys/living/skill_attributes.h)
+
+    <value>     INT
+                Neuer Wert des Attributs (Standard: 100)
+
+    <duration>  INT
+                Dauer in Sekunden
+
+    <fun>       NICHT MEHR UNTERSTUETZT - ModifySkillAttribute() nutzen!!
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion existiert nur aus Kompatibilitaetsgruenden. Bitte in neuen
+    Objekten NICHT mehr verwenden und in alten nach Moeglichkeit ausbauen!
+
+    Aendert ein Skill-Attribut eines Living.
+
+    
+
+    Fuer <value> ist folgendes zu beachten:
+    Frueher handelte es sich um einen multiplikativen Faktor. 100 hatte die
+    Bedeutung von 1 und veraenderte nichts. Heute sind die Modifikatoren
+    additiv. Diese Funktion macht eine einfache Umrechnung, indem sie vom hier
+    uebergeben Wert 100 abzieht. (In der Annahme, dass frueher meist eh nur 
+    ein Modifikator zur gleichen Zeit aktiv war.)
+    Gibt man hier also hier eine 100 an, wird ein Modifikator von 0 einge-
+    tragen, der nichts aendert, bei 200 wird ein Modifikator von 100 einge-
+    tragen, bei 50 einer von -50, welcher das Skillattribute folglich 
+    reduziert.
+
+    Es sind momentan max. 5 gleichzeitige Skillattribute-Modifikatoren pro SA
+    zulaessig.
+
+RUECKGABEWERT
+-------------
+::
+
+     0  wenn der Wert ungueltig ist oder aus sonstigem Grunde nicht gesetzt
+        werden konnte (fuer bessere Diagnostik -> ModifySkillAttribute()).
+    >0  wenn alles okay war
+
+BEMERKUNGEN
+-----------
+::
+
+    Frueher musste ein setzendes Objekt ein groesseres P_LEVEL haben als das
+    Objekt, welches einen vorherigen Modifikator gesetzt hat, um diesen zu
+    ueberschreiben. Dies ist inzwischen ohne Bedeutung.
+
+BEISPIELE
+---------
+::
+
+    Ein NPC:
+
+    void
+    create() {
+    .
+    .
+    .
+    AddSpell(1, 1,
+      "Der fuerchterliche NPC haut Dir auf den Kopf.\n",
+      "Der fuerchterliche NPC haut @WEN auf den Kopf.\n",
+      DT_MAGIC, "schwaechen");
+    .
+    .
+    }
+
+    schwaechen(object enemy, int damage, mixed *dam_type) {
+      int ergebnis;
+      ergebnis = enemy->ModifySkillAttributeOld(this_object(), SA_QUALITY, 50, 5);
+      if (ergebnis > 0)
+          tell_object(enenmy, "Du fuehlst Dich ganz schwach.\n");
+    }
+
+    
+
+    Der NPC schwaecht seinen Gegner erheblich! Alles wird fuer 5 Sekunden um
+    50, d.h. 0.5 Skillattribute reduziert (50 - 100 => -50 als Modifikator).
+
+SIEHE AUCH
+----------
+::
+
+    P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS,
+    ModifySkillAttribute, QuerySkillAttribute(),
+    RemoveSkillAttributeModifer(), QuerySkillAttributeModifier()
+
+
+07.08.2008 Zesstra
+
diff --git a/doc/sphinx/lfun/obsolete/NotifyGiveQuest.rst b/doc/sphinx/lfun/obsolete/NotifyGiveQuest.rst
new file mode 100644
index 0000000..64a1f9d
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/NotifyGiveQuest.rst
@@ -0,0 +1,74 @@
+NotifyGiveQuest()
+=================
+
+********************* OBSOLETE LFUN ***********************************
+* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die       *
+* Events (siehe "man events").                                        *
+***********************************************************************
+
+NotifyGiveQuest()
+
+FUNKTION
+--------
+::
+
+     void NotifyGiveQuest(object pl, string key);
+
+     
+
+DEFINIERT IN
+------------
+::
+
+     /std/gilden_ob.c
+
+     
+
+ARGUMENTE
+---------
+::
+
+     pl     Der Spieler, der eine Quest geloest hat.
+     key    Name der geloesten Quest.
+
+     
+
+BESCHREIBUNG
+------------
+::
+
+     Die Funktion wird in der Gilde des Spielers aufgerufen, wenn der 
+     Spieler eine gueltige Quest besteht - und zwar unabhaengig davon,
+     ob er sie bereits geloest hat, oder nicht.
+
+     
+
+RUECKGABEWERT
+-------------
+::
+
+     keiner
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Funktion ist dafuer gedacht, von Gildenprogrammierern ueberschrieben
+     zu werden, wenn beispielsweise bestimmte Quests als Aufstiegsbedingung
+     verlangt werden, diese aber in der entsprechenden Gilde geloest sein
+     muessen (z.B. Obergladiator als Level-5-Zauberer).
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     /std/gilden_ob.c
+     /std/player/quests.c
+
+
+Last modified: Fri Oct 4 10:17:00 1996 by Silvana
+
diff --git a/doc/sphinx/lfun/obsolete/NotifyHpChange.rst b/doc/sphinx/lfun/obsolete/NotifyHpChange.rst
new file mode 100644
index 0000000..21c4ca3
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/NotifyHpChange.rst
@@ -0,0 +1,72 @@
+NotifyHpChange()
+================
+
+********************* OBSOLETE LFUN ***********************************
+* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die       *
+* Hooks (s. /doc/std/hooks).                                          *
+***********************************************************************
+NotifyHpChange()
+
+FUNKTION
+--------
+::
+
+	void NotifyHpChange();
+
+DEFINIERT IN
+------------
+::
+
+	/std/player/life.c
+
+ARGUMENTE
+---------
+::
+
+	keine
+
+BESCHREIBUNG
+------------
+::
+
+	Wenn sich die Lebenspunkte eines Spielers aendern, so werden davon
+	auch andere Objekte unterrichtet, sofern diese mittels der Funktion
+	AddHpHook() bei eben diesem Spieler angemeldet wurden.
+	Fortan wird dann die Funktion NotifyHpChange() in diesen
+	angemeldeten Objekten aufgerufen, wenn sich die Property P_HP des
+	Spielers aendert. Es werden hierbei keine Argumente an
+	NotifyHpChange() uebergeben, die aktuellen Lebenspunkte kann man ja
+	auch ohne weiteres ueber die Property P_HP in Erfahrung bringen und
+	aeltere Werte muss man sich gesondert merken. Zu beachten ist, dass
+	die Property P_HP bei Aufruf der Funktion NotifyHpChange() bereits
+	den neuen Wert enthaelt.
+	Bei dem Spieler angemeldete Objekte, die von Lebenspunkteaenderungen
+	informiert werden sollen, werden automatisch aus der Liste entfernt,
+	wenn sie zerstoert wurden. Diese Liste ist in der Property
+	P_HP_HOOKS zu finden. Per Hand kann man sie auch explizit mittels
+	der Funktion RemoveHpHook() entfernen.
+	Stirbt ein Spieler, so wird die Funktion NotifyPlayerDeath()
+	aufgerufen und nicht NotifyHpChange()!
+
+RUeCKGABEWERT
+-------------
+::
+
+	keiner
+
+BEISPIELE
+---------
+::
+
+	ist in Arbeit
+
+SIEHE AUCH
+----------
+::
+
+	P_HP, P_HP_HOOKS, AddHpHook(), RemoveHpHook(),
+	Defend(), do_damage(), NotifyPlayerDeath()
+
+
+Last modified: Thu Nov 19 13:54:33 1998 by Patryn
+
diff --git a/doc/sphinx/lfun/obsolete/QueryEnemy.rst b/doc/sphinx/lfun/obsolete/QueryEnemy.rst
new file mode 100644
index 0000000..14c989a
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/QueryEnemy.rst
@@ -0,0 +1,50 @@
+QueryEnemy()
+============
+
+********************* OBSOLETE LFUN ***********************************
+
+FUNKTION
+--------
+::
+
+	object QueryEnemy();
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+	keine
+
+RUeCKGABEWERT
+-------------
+::
+
+	gefundener Gegner
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Funktion liefert zufaellig einen der anwesenden Gegner
+	zurueck, sofern keine Gegner bevorzugt ausgewaehlt werden.
+
+BEMERKUNGEN
+-----------
+::
+
+  Diese Lfun existiert nicht mehr. Bitte SelectEnemy() benutzen.
+
+SIEHE AUCH
+----------
+::
+
+	SelectEnemy(), QueryPreferedEnemy(), P_PREFERED_ENEMY
+
+07.02.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/obsolete/QueryInsertHooks.rst b/doc/sphinx/lfun/obsolete/QueryInsertHooks.rst
new file mode 100644
index 0000000..b488589
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/QueryInsertHooks.rst
@@ -0,0 +1,53 @@
+QueryInsertHooks()
+==================
+
+********************* OBSOLETE LFUN ***********************************
+* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die       *
+* Hooks (s. /doc/std/hooks).                                          *
+***********************************************************************
+QueryInsertHooks()
+
+FUNKTION
+--------
+::
+
+     object *QueryInsertHooks();
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     (Diese Funktionalitaet wurde ersetzt durch den allgemeinen Hook
+      H_HOOK_INSERT und ist nur noch aus Gruenden der Kompatibilitaet
+      vorhanden.)
+
+     Diese Funktion gibt die aktuell beim Spielerobjekt angemeldeten
+     Listener-Objekte zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Array aus Objektpointern oder leeres Array
+
+SIEHE AUCH
+----------
+::
+
+    NotifyInsert(), AddInsertHook(), RemoveInsertHook()
+
+
+Last modified: 14.04.2010, Arathorn
+
diff --git a/doc/sphinx/lfun/obsolete/QueryOptQP.rst b/doc/sphinx/lfun/obsolete/QueryOptQP.rst
new file mode 100644
index 0000000..50e8ca8
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/QueryOptQP.rst
@@ -0,0 +1,44 @@
+QueryOptQP()
+============
+
+FUNKTION
+--------
+::
+
+    int QueryOptQP()
+
+DEFINIERT IN
+------------
+::
+
+    /secure/questmaster.c
+
+ARGUMENTE
+---------
+::
+
+    keine
+
+RUECKGABEWERT
+-------------
+::
+
+    Abenteuerpunkte der optionalen Quests
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion liefert die Abenteuerpunkte der optionalen
+    Abenteuer zurueck. 
+
+SIEHE AUCH
+----------
+::
+
+    GiveQuest, QueryQuest, /secure/questmaster.h, QueryGroupedKeys,
+    QueryMaxQP, QueryTotalQP
+
+
+Zuletzt geaendert: Sam, 25. Nov 2000, 14:04:28 von Zook.
+
diff --git a/doc/sphinx/lfun/obsolete/RemoveHpHook.rst b/doc/sphinx/lfun/obsolete/RemoveHpHook.rst
new file mode 100644
index 0000000..0ce24fd
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/RemoveHpHook.rst
@@ -0,0 +1,48 @@
+RemoveHpHook()
+==============
+
+********************* OBSOLETE LFUN ***********************************
+* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die       *
+* Hooks (s. /doc/std/hooks).                                          *
+***********************************************************************
+RemoveHpHook()
+
+FUNKTION
+--------
+::
+
+     int RemoveHpHook(object ob)
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/life.c
+
+ARGUMENTE
+---------
+::
+
+     ob - das Objekt, das sich austragen moechte.
+
+BESCHREIBUNG
+------------
+::
+
+     Entfernt den Eintrag fuer dieses Objekt in P_HP_HOOKS.
+
+RUECKGABEWERT
+-------------
+::
+
+     1, wenn Erfolg, 0 sonst
+
+SIEHE AUCH
+----------
+::
+
+     Gegenpart:	AddHpHook()
+     Props:	P_HP_HOOKS, P_HP
+
+23.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/obsolete/RemoveInsertHook.rst b/doc/sphinx/lfun/obsolete/RemoveInsertHook.rst
new file mode 100644
index 0000000..682e5c5
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/RemoveInsertHook.rst
@@ -0,0 +1,53 @@
+RemoveInsertHook()
+==================
+
+********************* OBSOLETE LFUN ***********************************
+* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die       *
+* Hooks (s. /doc/std/hooks).                                          *
+***********************************************************************
+RemoveInsertHook()
+
+FUNKTION
+--------
+::
+
+     void RemoveInsertHook(object ob);
+
+DEFINIERT IN
+------------
+::
+
+     /std/player/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+     ob - Das Objekt, das als Listener aus der Liste ausgetragen werden soll
+
+BESCHREIBUNG
+------------
+::
+
+     (Diese Funktionalitaet wurde ersetzt durch den allgemeinen Hook
+      H_HOOK_INSERT und ist nur noch aus Gruenden der Kompatibilitaet
+      vorhanden.)
+
+     Diese Funktion wird im Spielerobjekt aufgerufen, um ein als Listener
+     eingetragenes Hook-Objekt ob wieder auszutragen.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+SIEHE AUCH
+----------
+::
+
+    NotifyInsert(), AddInsertHook(), QueryInsertHooks()
+
+
+Last modified: 14.04.2010, Arathorn
+
diff --git a/doc/sphinx/lfun/obsolete/TestAttributeLock.rst b/doc/sphinx/lfun/obsolete/TestAttributeLock.rst
new file mode 100644
index 0000000..7aa6123
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/TestAttributeLock.rst
@@ -0,0 +1,47 @@
+TestAttributeLock()
+===================
+
+********************* OBSOLETE LFUN ***********************************
+TestAttributeLock()
+
+FUNKTION
+--------
+::
+
+     string TestAttributeLock(mapping check)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/attributes.c
+
+PARAMETER
+---------
+::
+
+     check	- Mapping mit Attributen: ([<attr>:<wert>])
+
+BESCHREIBUNG
+------------
+::
+
+     Prueft, ob eines der im Mapping enthaltenen Attribute blockiert
+     ist (bereits durch einen anderen Modifier belegt wurde).
+
+     
+
+     Da Modifier nicht mehr direkt blockieren ist diese Funktion obsolet
+     und in Livings inzwischen nicht mehr existent.
+
+SIEHE AUCH
+----------
+::
+
+     QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+     SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+     P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
+     P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+11.05.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/obsolete/extra_look.rst b/doc/sphinx/lfun/obsolete/extra_look.rst
new file mode 100644
index 0000000..1e4db82
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/extra_look.rst
@@ -0,0 +1,32 @@
+extra_look()
+============
+
+********************* VERALTETE LFUN ******************************
+* Diese LFUN ist veraltet. Bitte benutzt sie NICHT mehr, sondern  *
+* stattdessden AddExtraLook().                                    *
+*******************************************************************
+
+extra_look()
+
+FUNKTION
+--------
+::
+
+    string extra_look();
+
+BESCHREIBUNG
+------------
+::
+
+    Kann in Objekt definiert sein. Wenn ein Living (std/living/description)
+    das Objekt enthaelt, wird zu dessen long() der zurueckgegebene String
+    hinzugefuegt.
+
+SIEHE AUCH
+----------
+::
+
+    AddExtraLook()
+
+25.Jan 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/obsolete/paramove.rst b/doc/sphinx/lfun/obsolete/paramove.rst
new file mode 100644
index 0000000..0d14d85
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/paramove.rst
@@ -0,0 +1,73 @@
+paramove()
+==========
+
+****************************************************************************
+************************* VERALTETE LFUN ***********************************
+************************* DO NOT USE!    ***********************************
+****************************************************************************
+paramove()
+
+FUNKTION
+--------
+::
+
+     int paramove();
+
+DEFINIERT IN
+------------
+::
+
+     /std/room/para.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Bewegt den Spieler ggf. in eine Paralleldimension.
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn der Spieler die Dimension gewechselt hat.
+
+BEISPIEL
+--------
+::
+
+     init(){
+       if(!paramove()) ::init();
+      }
+
+BEMERKUNGEN
+-----------
+::
+
+     DIESE FUNKTION NICHT MEHR BENUTZEN!
+
+     Diese Funktion sollte nur aus einem init() aufgerufen werden!
+
+     Fuer die Entscheidung, in welchem Raum ein Spieler in Abhaengigkeit 
+     von P_PARA landet, ist die Funktion move() zustaendig. Als Magier 
+     muss man sich darum nicht gesondert kuemmern. Das heisst aber auch, 
+     dass beim Anschluss eines Normalweltraumes automatisch alle in dem 
+     Verzeichnis mit gleichem Namen vorhandenen Parallelweltraeume mit 
+     angeschlossen werden.
+
+     Deswegen ist paramove() veraltet und sollte nicht mehr genutzt werden.
+
+SIEHE AUCH
+----------
+::
+
+     /std/room/para.c, P_PARA, P_NO_PLAYERS, move
+
+
+Last modified: 05.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/pick.rst b/doc/sphinx/lfun/pick.rst
new file mode 100644
index 0000000..85d576d
--- /dev/null
+++ b/doc/sphinx/lfun/pick.rst
@@ -0,0 +1,74 @@
+pick()
+======
+
+FUNKTION
+--------
+::
+
+    public varargs int pick(object o, mixed msg);
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+    object o
+        Das Objekt, das aufgehoben werden soll.
+    mixed msg
+        Eine optionale Meldung, die anstelle von P_PICK_MSG oder der
+        Standardmeldung verwendet wird, oder -1, um die Meldung zu
+        unterdruecken.
+
+BESCHREIBUNG
+------------
+::
+
+    Der Spieler oder NPC nimmt das Objekt auf. Gibt o->move() keinen positiven
+    Wert zurueck, beispielsweise weil das Objekt zu schwer ist oder nicht
+    genommen werden darf, bekommt er eine entsprechende Fehlermeldung.
+
+RUECKGABEWERT
+-------------
+::
+
+    Wenn das Aufnehmen geklappt hat, 1, ansonsten 0.
+
+BEMERKUNG
+---------
+::
+
+    Diese Funktion ist dann sinnvoll, wenn man den Spieler ein Objekt
+    aufnehmen lassen und sich nicht selbst um die Fehlerbehandlung kuemmern
+    moechte - und da unzaehlige verschiedene Dinge schiefgehen koennen und
+    manche Objekte eigene Fehlermeldungen definieren, eigentlich immer.
+
+    Die Funktion prueft nicht, ob sich das Objekt ueberhaupt in der Reichweite
+    des Spielers/NPC befindet, das muss man ggf. selbst ermitteln.
+
+BEISPIEL
+--------
+::
+
+    ob = clone_object(WEINGUMMI);
+
+    if (this_player()->pick(ob, ({ "Du nimmst @WENU2 aus dem Regal.",
+                                   "@WER1 nimmt @WENU2 aus dem Regal." })))
+        weingummi--;
+    else
+        ob->remove();
+
+SIEHE AUCH
+----------
+::
+
+    move(L), P_PICK_MSG, pick_objects(L), P_NOINSERT_MSG, P_NOLEAVE_MSG,
+    P_TOO_MANY_MSG, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NOGET
+
+
+Last modified: Thu Aug 28 22:21:41 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/pick_obj.rst b/doc/sphinx/lfun/pick_obj.rst
new file mode 100644
index 0000000..84aa6cf
--- /dev/null
+++ b/doc/sphinx/lfun/pick_obj.rst
@@ -0,0 +1,43 @@
+pick_obj()
+==========
+
+FUNKTION
+--------
+::
+
+    int pick_obj(object ob)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+    ob      Das Objekt, das genommen werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+    Das Lebewesen, in dem diese Funktion aufgerufen werden soll, hebt
+    den angegebenen Gegenstand (ob) auf, falls es ihm moeglich ist.
+
+RUeCKGABEWERT
+-------------
+::
+
+    1, wenn das Objekt genommen wurde oder dies nicht moeglich war. (in diesem
+    Fall wird auch direkt eine Textausgabe ausgegeben)
+    0 sonst, in diesem Fall wird in notify_fail eine passende Ausgabe
+    plaziert
+
+SIEHE AUCH
+----------
+::
+
+    drop_obj(), find_obs(), give_obj(), put_obj(), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/lfun/pick_objects.rst b/doc/sphinx/lfun/pick_objects.rst
new file mode 100644
index 0000000..77979df
--- /dev/null
+++ b/doc/sphinx/lfun/pick_objects.rst
@@ -0,0 +1,62 @@
+pick_objects()
+==============
+
+FUNKTION
+--------
+::
+
+    public varargs int pick_objects(string str, int flag, mixed msg);
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+    string str
+        Was aufgehoben werden soll.
+    int flag
+        Muss das Objekt irgendwo drinstecken (flag = 1), oder darf es einfach
+        so herumliegen (flag = 0)? Dieses Argument ist hauptsaechlich fuer das
+        Kommando "hole" gedacht, in der Regel braucht man es nicht anzugeben.
+    mixed msg
+        Eine optionale Meldung, die anstelle von P_PICK_MSG oder der
+        Standardmeldung verwendet wird, oder -1, um die Meldung zu
+        unterdruecken.
+
+BESCHREIBUNG
+------------
+::
+
+    Der Spieler oder NPC nimmt die in <str> benannten Sachen. Kann er ein
+    Objekt nicht nehmen, bekommt er eine entsprechende Fehlermeldung. Wenn
+    keine Objekte auf <str> passen, wird per _notify_fail() eine Meldung
+    gesetzt, aber noch nicht ausgegeben.
+
+RUECKGABEWERT
+-------------
+::
+
+    Wenn <str> irgendwelche vorhandenen Sachen sind, 1, sonst 0.
+
+BEMERKUNG
+---------
+::
+
+    Wenn die Funktion 1 zurueckgibt, heisst das noch nicht, dass der Spieler
+    etwas genommen hat! Er hat es nur versucht, d.h. auf jeden Fall eine
+    Meldung bekommen. Gibt die Funktion 0 zurueck, hat er noch keine bekommen.
+
+SIEHE AUCH
+----------
+::
+
+    move(L), pick(L), P_PICK_MSG, find_objects(L), moved_objects(L)
+
+
+Last modified: Fri Jul 25 10:58:43 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/present_objects.rst b/doc/sphinx/lfun/present_objects.rst
new file mode 100644
index 0000000..4375fe5
--- /dev/null
+++ b/doc/sphinx/lfun/present_objects.rst
@@ -0,0 +1,51 @@
+present_objects()
+=================
+
+FUNKTION
+--------
+::
+
+     object *present_objects(string desc);
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+     desc
+          Umschreibung des gesuchten Objektes oder "alles" oder "alle".
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion gibt die Objekte im Inneren des Behaelters zurueck, die
+     sich mit desc ansprechen lassen. In dem Fall, dass "alle(s)"
+     angefordert wird, sind das alle sichtbaren Objekte, ansonsten das erste
+     Objekt, das sich mit desc ansprechen laesst.
+     Objekte, die P_INVIS gesetzt haben, zaehlen als nicht ansprechbar, im
+     Gegensatz zu solchen Objekten, die keine P_SHORT haben.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Ein Array von Objekten mit den geforderten Eigenschaften.
+
+     Befindet sich kein Objekt im Behaelter, das sich durch desc ansprechen
+     laesst, so wird ein leeres Array zurueckgegeben.
+
+SIEHE AUCH
+----------
+::
+
+     locate_objects(), /std/container/restrictions.c
+
+
+03.03.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/put.rst b/doc/sphinx/lfun/put.rst
new file mode 100644
index 0000000..dee5817
--- /dev/null
+++ b/doc/sphinx/lfun/put.rst
@@ -0,0 +1,66 @@
+put()
+=====
+
+FUNKTION
+--------
+::
+
+    public varargs int put(object o, object dest, mixed msg);
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+    object o
+        Das Objekt, das irgendwo hingesteckt werden soll.
+    object dest
+        Der Behaelter, in den das Objekt gesteckt werden soll.
+    mixed msg
+        Eine optionale Meldung, die anstelle von P_PUT_MSG oder der
+        Standardmeldung verwendet wird, oder -1, um die Meldung zu
+        unterdruecken.
+
+BESCHREIBUNG
+------------
+::
+
+    Der Spieler oder NPC steckt das Objekt in einen Behaelter. Gibt o->move()
+    keinen positiven Wert zurueck, beispielsweise weil er das Objekt nicht
+    weggeben darf oder der Behaelter schon voll ist, bekommt er eine
+    entsprechende Fehlermeldung.
+
+RUECKGABEWERT
+-------------
+::
+
+    Wenn das Bewegen geklappt hat, 1, ansonsten 0.
+
+BEMERKUNG
+---------
+::
+
+    Diese Funktion ist dann sinnvoll, wenn man den Spieler ein Objekt irgendwo
+    hinstecken lassen und sich nicht selbst um die Fehlerbehandlung kuemmern
+    moechte - und da unzaehlige verschiedene Dinge schiefgehen koennen und
+    manche Objekte eigene Fehlermeldungen definieren, eigentlich immer.
+
+    Die Funktion prueft nicht, ob sich das Objekt und der Behaelter ueberhaupt
+    in der Reichweite des Spielers/NPC befinden, das muss man ggf. selbst
+    ermitteln.
+
+SIEHE AUCH
+----------
+::
+
+    move(L), P_PUT_MSG, put_objects(L), P_NOINSERT_MSG, P_NOLEAVE_MSG,
+    P_TOO_MANY_MSG, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NOGET, P_NODROP
+
+
+Last modified: Thu Aug 28 22:21:58 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/put_obj.rst b/doc/sphinx/lfun/put_obj.rst
new file mode 100644
index 0000000..9887173
--- /dev/null
+++ b/doc/sphinx/lfun/put_obj.rst
@@ -0,0 +1,46 @@
+put_obj()
+=========
+
+FUNKTION
+--------
+::
+
+    int put_obj(object ob, object where)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+    ob      Das Objekt, das irgendwo hineingelegt werden soll.
+    where   Das (tote) Objekt, in das etwas hineingelegt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+    Das Lebewesen, in dem diese Funktion aufgerufen werden soll, legt
+    den angegebenen Gegenstand (ob) in das angegebene Zielobjekt (where).
+    Dabei sollte es sich bei where um einen Container/Raum handeln.
+    Ist where ein Lebewesen, verwendet man besser give_obj().
+
+RUeCKGABEWERT
+-------------
+::
+
+    1, wenn das Objekt weggelegt wurde oder dies nicht moeglich war. (in diesem
+    Fall wird auch direkt eine Textausgabe ausgegeben)
+    0 sonst, in diesem Fall wird in notify_fail eine passende Ausgabe
+    plaziert
+
+SIEHE AUCH
+----------
+::
+
+    drop_obj(), find_obs(), give_obj(), pick_obj(), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/lfun/query_prevent_shadow.rst b/doc/sphinx/lfun/query_prevent_shadow.rst
new file mode 100644
index 0000000..ebeb46a
--- /dev/null
+++ b/doc/sphinx/lfun/query_prevent_shadow.rst
@@ -0,0 +1,54 @@
+query_prevent_shadow()
+======================
+
+query_prevent_shadow(L)
+
+FUNKTION
+--------
+::
+
+     varargs int query_prevent_shadow(object shadower)
+
+PARAMETER
+---------
+::
+
+     object shadower	- da Objekt, das eine Beschattung beantragt
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Methode kann in Objekten definiert werden, die nicht beschattet
+     werden wollen oder anhand des Objektes shadower entscheiden wollen ob
+     sie beschattet werden wollen.
+
+     Gibt die Funktion 0 zurueck, wird ein Shadow auf das Objekt erlaubt,
+     sonst schlaegt es fehl.
+
+BEISPIEL
+--------
+::
+
+     // generell keine Beschattung
+     int query_prevent_shadow(object who) {
+      return 1;
+     }
+
+     // Beschattung durch offizielle Objekte erlaubt
+     int query_prevent_shadow(object who) {
+      if(who && !strstr(object_name(who),"/std/player"))
+       return 0;
+      return 1;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Rechte:	     query_allow_shadow(M)
+     Generell:	     shadow(E), unshadow(E)
+     Informationen:  query_shadowing(E)
+
+20. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/query_real_name.rst b/doc/sphinx/lfun/query_real_name.rst
new file mode 100644
index 0000000..dbc5651
--- /dev/null
+++ b/doc/sphinx/lfun/query_real_name.rst
@@ -0,0 +1,26 @@
+query_real_name()
+=================
+
+SYNOPSIS
+--------
+::
+
+	string query_real_name(void)
+
+DESCRIPTION
+-----------
+::
+
+	The result of this_player()->query_real_name() is used as
+	default argument for the efun wizlist().
+
+	If LOG_SHOUT was #defined in the parser at compile time, the
+	efun shout will use query_real_name() to log the shouter's
+	name.
+
+SEE ALSO
+--------
+::
+
+	shout(E), wizlist(E)
+
diff --git a/doc/sphinx/lfun/query_weight_contents.rst b/doc/sphinx/lfun/query_weight_contents.rst
new file mode 100644
index 0000000..8446e1b
--- /dev/null
+++ b/doc/sphinx/lfun/query_weight_contents.rst
@@ -0,0 +1,37 @@
+query_weight_contents()
+=======================
+
+FUNKTION
+--------
+::
+
+     int query_weight_contents()
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt das Gewicht des Inhaltes des Behaelters zurueck (ohne
+     Beruecksichtigung von P_WEIGHT_PERCENT!)
+
+RUeCKGABEWERT
+-------------
+::
+
+     Das Gewicht des Behaelterinhaltes.
+
+
+Last modified: Wed May 8 10:23:32 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/reduce_hit_points.rst b/doc/sphinx/lfun/reduce_hit_points.rst
new file mode 100644
index 0000000..790b078
--- /dev/null
+++ b/doc/sphinx/lfun/reduce_hit_points.rst
@@ -0,0 +1,70 @@
+reduce_hit_points()
+===================
+
+FUNKTION
+--------
+::
+
+    int reduce_hit_points(int damage)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+    int damage	- der zugefuegte Schaden
+
+BESCHREIBUNG
+------------
+::
+
+    Dem Lebewesen werden damage Lebenspunkte abgezogen, aber der
+    Wert wird hinterher nicht kleiner als 1 sein und das Lebewesen
+    wird dadurch nicht sterben.
+
+RUECKGABEWERT
+-------------
+::
+
+    Die verbleibenden Lebenspunkte.
+
+BEISPIELE
+---------
+::
+
+    write("Ploetzlich schiesst eine scheussliche Kreatur aus der Pfuetze "+
+          "heraus und\nbeisst Dich ins Bein, sie verschwindet so schnell, "+
+          "wie sie gekommen ist.\n");
+    this_player()->reduce_hit_points(50);
+    (Auszug aus /players/boing/friedhof/room/cat1x9)
+
+BEMERKUNGEN
+-----------
+::
+
+    damage kann auch ein negativer Wert sein, dann werden dem Lebewesen
+    diese Lebenspunkte gutgeschrieben und auf die aktuellen Lebenspunkte
+    addiert. Da dies eine Form der Heilung ist, nur nach Ruecksprache mit
+    dem Regionsmagier verwenden.
+
+    Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
+    dafuer eingerichteten Funktion check_and_update_timed_key realisiert
+    werden.
+
+SIEHE AUCH
+----------
+::
+
+    Gegenpart:	restore_hit_points()
+    Verwandt:	do_damage(), Defend(), reduce_spell_points()
+    Props:	P_HP
+    Konzept:	heilung
+
+
+Last modified: Sat Dec 13 01:00:47 1999 by Tilly
+
diff --git a/doc/sphinx/lfun/reduce_spell_points.rst b/doc/sphinx/lfun/reduce_spell_points.rst
new file mode 100644
index 0000000..68c3f58
--- /dev/null
+++ b/doc/sphinx/lfun/reduce_spell_points.rst
@@ -0,0 +1,48 @@
+reduce_spell_points()
+=====================
+
+FUNKTION
+--------
+::
+
+    void reduce_spell_points(int points)
+
+DEFINIERT IN
+------------
+::
+
+    /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+    points: Anzahl der Konzentrationspunkte die abgezogen werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+    Dem Lebewesen werden points Konzentrationspunkte abgezogen. Falls
+    das Lebewesen weniger Konzentrationspunkte hat, als abgezogen werden
+    sollen, werden sie auf 0 gesetzt.
+
+BEISPIELE
+---------
+::
+
+    write("Das boese boese Monster schaut Dich grimmig an und labt sich an "
+         +"Deiner Konzentration.\n");
+    this_player()->reduce_spell_points(50);
+
+SIEHE AUCH
+----------
+::
+
+    Gegenpart:	restore_spell_points(L)
+    Verwandt:	reduce_hit_points(L), buffer_sp(L)
+    Props:	P_SP
+    Konzept:	heilung
+
+23.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/register_modifier.rst b/doc/sphinx/lfun/register_modifier.rst
new file mode 100644
index 0000000..9d95145
--- /dev/null
+++ b/doc/sphinx/lfun/register_modifier.rst
@@ -0,0 +1,42 @@
+register_modifier()
+===================
+
+FUNKTION
+--------
+::
+
+     void register_modifier(object modifier)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/attributes.c
+
+PARAMETER
+---------
+::
+
+     modifier	- Objekt mit P_X_ATTR_MOD oder P_M_ATTR_MOD
+
+BESCHREIBUNG
+------------
+::
+
+     Registriert einen Modifier im Spieler. Wird durch InsertSensitiveObject
+     beziehungsweise beim Anziehen oder Zuecken gerufen.
+     Muss nicht direkt gerufen werden. Bei Veraenderungen von Modifikatoren
+     sollte stattdessen UpdateAttributes gerufen werden.     
+
+SIEHE AUCH
+----------
+::
+
+     QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+     SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+     deregister_modifier(), P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, 
+     P_ATTRIBUTES_MODIFIER,P_X_ATTR_MOD, P_M_ATTR_MOD, 
+     /std/living/attributes.c
+
+13.Jun.2004, Muadib
+
diff --git a/doc/sphinx/lfun/remove.rst b/doc/sphinx/lfun/remove.rst
new file mode 100644
index 0000000..8d3e313
--- /dev/null
+++ b/doc/sphinx/lfun/remove.rst
@@ -0,0 +1,57 @@
+remove()
+========
+
+FUNKTION
+--------
+::
+
+     varargs int remove(int silent);
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/moving.c
+     /std/living/moving.c
+     /std/room/moving.c
+
+ARGUMENTE
+---------
+::
+
+     silent
+          Falls ungleich 0, so werden beim Zerstoeren keine Meldungen
+          ausgegeben.
+
+BESCHREIBUNG
+------------
+::
+
+     Beim Aufruf dieser Funktion entfernt sich das Objekt selbst. Durch
+     Ueberladen dieser Funktion kann man diesen Vorgang noch durch die
+     Ausgabe von Meldungen kommentieren, oder irgendwelche Daten
+     abspeichern, oder das Zerstoeren ganz verhindern (auf diesem Weg... Mit
+     destruct() kann das Objekt immer noch direkt zerstoert werden!)
+
+RUeCKGABEWERT
+-------------
+::
+
+     1, wenn sich das Objekt erfolgreich selbst zerstoert hat, sonst 0.
+
+BEMERKUNGEN
+-----------
+::
+
+     Nach einem erfolgreichen ::remove() gelten die selben Einschraenkungen
+     wie nach einem destruct()!
+
+SIEHE AUCH
+----------
+::
+
+     destruct()
+
+
+Last modified: Wed May 8 10:23:40 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/remove_multiple.rst b/doc/sphinx/lfun/remove_multiple.rst
new file mode 100644
index 0000000..e24b6ac
--- /dev/null
+++ b/doc/sphinx/lfun/remove_multiple.rst
@@ -0,0 +1,86 @@
+remove_multiple()
+=================
+
+FUNKTION
+--------
+::
+
+     public varargs int remove_multiple(int limit, mixed fun);
+
+DEFINIERT IN
+------------
+::
+
+     /std/container/items.c
+
+ARGUMENTE
+---------
+::
+
+     limit: Anzahl gleicher Objekte, die verbleiben sollen.
+     fun:   Funktionsname (string) oder Closure.
+
+BESCHREIBUNG
+------------
+::
+
+     Wird diese Funktion aufgerufen, werden alle gleichen Objekte
+     (standardmaessig definiert als gleicher Ladename, gleiche
+      Kurzbeschreibung und gleiche Langbeschreibung), deren Anzahl <limit>
+     ueberschreitet, entfernt.
+
+     
+
+     Ausnahmen: Lebewesen und per AddItem() hinzugefuegte Objekte.
+
+     Mit dem Argument <fun> lassen sich die Kriterien fuer die "Gleichheit"
+     aendern.
+     Ist <fun> ein Funktionsname, wird diese Funktion an allen in Frage
+     kommenenden Objekten im Container gerufen.
+     Ist <fun> eine Closure, werden sie fuer jedes in Frage kommende Objekt
+     einmal gerufen und ihr das Objekt uebergeben.
+     Als 'gleich' werden alle Objekte betrachtet, fuer die <fun> den gleichen
+     Wert zurueckliefert.
+     Objekte, fuer die <fun> 0 zurueckliefert, werden ignoriert.
+
+BEMERKUNGEN
+-----------
+::
+
+     1) Raeume rufen remove_multiple(3) standardmaessig im reset(), jedoch
+        nur, wenn kein Spieler anwesend ist und mehr als 10 Objekte im Raum
+        sind.
+     2) remove_multipe(0) entfernt alle entfernbaren Objekte (s. Ausnahmen).
+
+BEISPIELE
+---------
+::
+
+     Ein Container enthaelt 5 Fackeln. Im reset() ruft man nun
+     remove_multiple(3) auf. Anschliessend sind noch 3 Fackeln uebrig.
+
+     
+
+     Alle verbleibenden Objekte im Container sollen unterschiedliche Namen
+     haben:
+     remove_multiple(1, "name");
+
+     Ein Container soll nur ein Objekt behalten, welches groesser als 70 cm
+     ist:
+     int groessen_filter(object ob) {
+       if (ob->QueryProp(P_SIZE > 70)) return 1;
+       return 0; // damit das Objekt ignoriert wird.
+       // Alternativ koennte man statt 0 auch object_name(ob) zurueckliefern,
+       // dann sind diese Objekte alle unterschiedlich.
+     }
+     ...
+     remove_multiple(1, #'groessen_filter);
+
+SIEHE AUCH
+----------
+::
+
+     reset()
+
+31.01.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/reset.rst b/doc/sphinx/lfun/reset.rst
new file mode 100644
index 0000000..2c65656
--- /dev/null
+++ b/doc/sphinx/lfun/reset.rst
@@ -0,0 +1,106 @@
+reset()
+=======
+
+FUNKTION
+--------
+::
+
+     void reset();
+     protected void reset();
+
+BESCHREIBUNG
+------------
+::
+
+     reset() wird vom GameDriver in jedem Objekt aufgerufen, um dem Objekt
+     die Gelegenheit zu geben, sich wieder in einen definierten Zustand zu
+     versetzen: Raeume und Monster erzeugen per AddItem() eingefuegte und
+     zwischenzeitlich entfernte Objekte neu, Tueren schliessen sich ...
+
+     Solange das Objekt "benutzt" wird, wird reset() regelmaessig alle
+     45 Minuten (+/-15 Minuten) mit einer Aufloesung von 2s aufgerufen
+     (d.h. der Driver prueft und ruft nur alle 2 Sekunden reset() auf
+     allen Objekten).
+
+     Wird eine Objekt nicht mehr "benutzt", d.h. wird an einem Objekt nicht
+     von aussen (durch call_other etc.) _nach_ einem reset() eine Methode
+     bzw. LFun gerufen, so bekommt dieses Objekt keinen weiteren reset().
+
+     Ein Funktionsaufruf am Objekt schaltet den reset() wieder ein.
+     Bei einem Objekt in einem Container waere das zB das Benutzen des
+     Containers (Hineinlegen/Herausnehmen/Hineinsehen). Das kann
+     sehr lange dauern.
+
+     Die Abschaltung kann man verhindern, indem man im reset() per call_out()
+     eine Funktion im Objekt ruft. Dies aber bitte _nur_ machen, wenn das
+     Objekt _unbedingt_ auf einen staendigen Reset angewiesen ist, auch wenn
+     es nicht "benutzt" wird.
+
+     Aendern laesst sich die Zeit zwischen den Aufrufen von reset() mit
+     set_next_reset(). Die Aufloesung von 2s kann man nicht aendern.
+
+BEMERKUNGEN
+-----------
+::
+
+     - man kann reset() nutzen, um Ereignisse auszuloesen:
+       - es ist billiger als lange call_out()
+       - siehe Warnung bezueglich Abschalten des reset
+     - man kann reset() als protected oder static definieren, wenn man nicht
+       moechte, dass die Funktion von aussen gerufen werden kann. Dies
+       verhindert Einflussnahme von aussen, kann aber auch Debugmassnahmen
+       erschweren. Es ist aber dennoch fuer einige Objekte sinnvoll.
+     - der Driver ruft reset() unabhaengig von zusaetzlichen, "manuellen"
+       Rufen von reset()
+       - keine Rufe von reset() mit call_out() aus reset() (Callout-Ketten-
+         bildung droht), fuer solche Faelle ist set_next_reset(E) da!
+     - bei Blueprints sollte der reset() in der Regel abgeschaltet werden,
+       sofern er nicht auf wichtige Aufgaben in der BP zu tun hat:
+       protected void create() {
+         if(!clonep(ME)) {
+             set_next_reset(-1);
+             return;
+         }
+         ::create();
+         ...
+       }
+
+BEISPIELE
+---------
+::
+
+     // ein NPC, der bei jedem reset() schaut, ob um ihn herum bessere
+     // Ausruestung liegt als die, die er selbst gerade traegt:
+
+     ...
+     void reset() {
+       ::reset();
+
+       if(clonep(this_object()) && environment()) {
+         object o;
+         o=first_inventory(environment());
+         while(o) {
+             look_for_good_weapons_and_use_them_if_better(o);
+             o=next_inventory(o);
+         }
+       }
+     }
+
+     // ein reset fuer einen Gegenstand, der vielleicht in
+     // in einem Container landet und dann weiter einen reset
+     // bekommen muss/soll
+
+     void reset() {
+       // irgend ein Code hier
+       call_other(this_object(), "???"); // einfach nur was aufrufen
+     }
+
+SIEHE AUCH
+----------
+::
+
+     clean_up(), set_next_reset(E), query_next_reset(E)
+     memory
+
+letzte Aenderung: 2009-01-14 Rumata
+
diff --git a/doc/sphinx/lfun/restore_hit_points.rst b/doc/sphinx/lfun/restore_hit_points.rst
new file mode 100644
index 0000000..e7c2e70
--- /dev/null
+++ b/doc/sphinx/lfun/restore_hit_points.rst
@@ -0,0 +1,57 @@
+restore_hit_points()
+====================
+
+FUNKTION
+--------
+::
+
+    int restore_hit_points(int heal)
+
+ARGUMENTE
+---------
+::
+
+    int heal	- der zu heilende Betrag
+
+BESCHREIBUNG
+------------
+::
+
+    Dem Lebewesen werden heal Lebenspunkte aufgeschlagen. Die HP
+    steigen nicht ueber P_MAX_HP.
+
+RUECKGABEWERT
+-------------
+::
+
+    Die verbleibenden Lebenspunkte.
+
+BEISPIELE
+---------
+::
+
+    write("Ploetzlich schiesst eine scheussliche Kreatur aus der Pfuetze "+
+          "heraus und\nschleimt dich heilend voll, sie verschwindet so, "+
+          "wie sie gekommen ist.\n");
+    this_player()->restore_hit_points(50);
+
+BEMERKUNGEN
+-----------
+::
+
+    Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
+    dafuer eingerichteten Funktion check_and_update_timed_key realisiert
+    werden.
+    Ansonsten bitte buffer_hp() benutzen und die Konzeptseite lesen!
+
+SIEHE AUCH
+----------
+::
+
+    Gegenpart:	reduce_hit_points()
+    Verwandt:	buffer_hp(), heal_self(), restore_spell_points()
+    Props:	P_HP
+    Konzept:	heilung
+
+23.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/restore_spell_points.rst b/doc/sphinx/lfun/restore_spell_points.rst
new file mode 100644
index 0000000..2638568
--- /dev/null
+++ b/doc/sphinx/lfun/restore_spell_points.rst
@@ -0,0 +1,61 @@
+restore_spell_points()
+======================
+
+FUNKTION
+--------
+::
+
+    void restore_spell_points(int points)
+
+ARGUMENTE
+---------
+::
+
+    points: Anzahl der Konzentrationspunkte die gutgeschrieben werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+    Dem Lebewesen werden points Konzentrationspunkte gutgeschrieben. Falls
+    Punkte abgezogen werden sollen und das Lebewesen nicht ueber <points>
+    Konzentrationspunkte verfuegt, werden sie auf 0 gesetzt.
+
+RUECKGABEWERT
+-------------
+::
+
+    Keiner
+
+BEISPIELE
+---------
+::
+
+    write("Das boese boese Monster schaut Dich suess an und gibt dir mehr "
+         +"Konzentration.\n");
+    this_player()->restore_spell_points(50);
+
+BEMERKUNGEN
+-----------
+::
+
+    Da das Benutzen der Funktion eine Heilung bedeutet, sollte man bei
+    Verwendung auf jeden Fall Ruecksprache mit seinem RM nehmen, bzw
+    die Heilstelle bei der Heilungsbalance genehmigen lassen.
+
+    Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
+    dafuer eingerichteten Funktion check_and_update_timed_key realisiert
+    werden.
+    Ansonsten bitte buffer_sp() benutzen und die Konzeptseite lesen!
+
+SIEHE AUCH
+----------
+::
+
+    Gegenpart:	reduce_spell_points(L)
+    Verwandt:	buffer_sp(L), restore_hit_points(L)
+    Props:	P_SP
+    Konzept:	heilung
+
+23.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/save_me.rst b/doc/sphinx/lfun/save_me.rst
new file mode 100644
index 0000000..2fc4811
--- /dev/null
+++ b/doc/sphinx/lfun/save_me.rst
@@ -0,0 +1,41 @@
+save_me()
+=========
+
+save_me(L)
+
+FUNKTION
+--------
+::
+
+    void save_me(mixed value_items)
+
+DEFINIERT IN
+------------
+::
+
+    /std/player/base.c
+
+ARGUMENTE
+---------
+::
+
+    value_items
+       Ungleich 0, wenn Wert der Gegenstaende berechnet werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+    Speichert einen Spieler, seine Autoloader, bestimmt sein GuildRating
+    und berechnet/speichert auf Anforderung den Wert der getragenen
+    Gegenstaende.
+
+SIEHE AUCH
+----------
+::
+
+    Props:       P_CARRIED_VALUE, P_AUTOLOADOBJ, P_LAST_LOGOUT
+    Kommandos:   save, ende
+
+1.September 2008 Gloinson
+
diff --git a/doc/sphinx/lfun/second_life.rst b/doc/sphinx/lfun/second_life.rst
new file mode 100644
index 0000000..f0aef10
--- /dev/null
+++ b/doc/sphinx/lfun/second_life.rst
@@ -0,0 +1,53 @@
+second_life()
+=============
+
+FUNKTION
+--------
+::
+
+	varargs int second_life(object obj);
+
+DEFINIERT IN
+------------
+::
+
+	/std/player/life.c
+
+ARGUMENTE
+---------
+::
+
+	obj
+	  Leiche des Lebewesens.
+
+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.
+
+RUeCKGABEWERT
+-------------
+::
+
+        1, wenn das Lebewesen nicht stirbt, sonst 0
+
+BEMERKUNG
+---------
+::
+
+        Bei NPCs sollte man direkt die() ueberschreiben, wenn man nicht
+        moechte, dass sie sterben.
+
+SIEHE AUCH
+----------
+::
+
+        die()
+
+
+Last modified: 2015-Jan-19, Arathorn 
+
diff --git a/doc/sphinx/lfun/sell_obj.rst b/doc/sphinx/lfun/sell_obj.rst
new file mode 100644
index 0000000..f65998d
--- /dev/null
+++ b/doc/sphinx/lfun/sell_obj.rst
@@ -0,0 +1,60 @@
+sell_obj()
+==========
+
+sell_obj()
+
+Funktion:
+    static string sell_obj(object ob, int short)
+
+Definiert in:
+    /std/room/shop
+
+Argumente:
+    ob:
+      Das anzukaufende Objekt
+    short:
+      Gibt an, ob der Verkaeufer nur ein Objekt (0) oder mehrere (1) 
+      verkauft. (Verkaufe alles etc.)
+
+Beschreibung:
+    Ermittelt ob der Laden bereit ist, <ob> anzukaufen.
+
+Rueckgabewert:
+    Meldung die ausgegeben wird, wenn ein Objekt abgelehnt wird oder 0.
+
+Bemerkung:
+    Man sollte im normalfall _niemals_ einfach 0 zurueckgeben, sondern das 
+    geerbte sell_obj() aus /std/room/shop, damit beispielsweise P_NOBUY 
+    beachtet wird.
+
+Beispiel:
+    Ein Schmied, der nur Waffen ankauft:
+
+    
+
+    protected void create()
+    {
+      ...
+    }
+
+    
+
+    static string sell_obj(object ob, int short)
+    {
+      if(!ob->QueryProp(P_WEAPON_TYPE))
+      {
+        return "Ich bin nur an Waffen interessiert.";
+      }
+      return ::sell_obj(ob,short);
+    }
+
+Siehe auch:
+    Funktionen:
+      AddFixedObject(), RemoveFixedObject(), SetStorageRoom(), 
+      QueryStorageRoom(), QueryBuyValue(), QueryBuyFact(), buy_obj()
+    Properties:
+      P_KEEPER, P_MIN_STOCK, P_STORE_CONSUME
+
+
+Letzte Aenderung: 21.05.2014, Bugfix
+
diff --git a/doc/sphinx/lfun/set_object_next_reset.rst b/doc/sphinx/lfun/set_object_next_reset.rst
new file mode 100644
index 0000000..3d86b62
--- /dev/null
+++ b/doc/sphinx/lfun/set_object_next_reset.rst
@@ -0,0 +1,41 @@
+set_object_next_reset()
+=======================
+
+FUNKTION
+--------
+::
+
+	int set_object_next_reset(object ob, int zeit );
+
+DEFINIERT IN: /secure/debug.c
+
+ARGUMENTE
+---------
+::
+
+	ob: Das Objekt, dess Reset gesetzt werden soll.
+  zeit: Zeit bis zum naechsten Reset von ob.
+
+FUNKTION
+--------
+::
+
+  Die Funktion ruft letztendlich set_next_reset() in <ob> auf und setzt daher
+  dessen Resetzeit auf einen neuen Wert. Dies ist zu Debugzwecken gedacht.
+
+  Die Benutzung ist nur fuer EM+ moeglich.
+
+RUECKGABEWERT
+-------------
+::
+
+	Gibt den Rueckgabewert des set_next_reset()-Aufrufs in <ob> zurueck.
+
+SIEHE AUCH
+----------
+::
+
+	set_next_reset(E)
+
+10.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/shoot_dam.rst b/doc/sphinx/lfun/shoot_dam.rst
new file mode 100644
index 0000000..eb34c14
--- /dev/null
+++ b/doc/sphinx/lfun/shoot_dam.rst
@@ -0,0 +1,63 @@
+shoot_dam()
+===========
+
+FUNKTION
+--------
+::
+
+    static int shoot_dam(mapping shoot)
+
+DEFINIERT IN
+------------
+::
+
+    /std/ranged_weapon.c
+
+ARGUMENTE
+---------
+::
+
+    mapping shoot - Schussdaten
+
+BESCHREIBUNG
+------------
+::
+
+    Erhaelt von /std/ranged_weapon::cmd_shoot() die Schussdaten und berechnet
+    den Schaden der Waffe, basierend auf den P_SHOOTING_WC von Waffe und
+    Munition sowie der Geschicklichkeit des Schuetzen. HitFuncs der Munition
+    und Skills werden hier ebenfalls beruecksichtigt.
+
+RUECKGABEWERT
+-------------
+::
+
+    Schaden. Ebenfalls in 'shoot' unter SI_SKILLDAMAGE aktualisiert.
+
+BEMERKUNGEN
+-----------
+::
+
+    'shoot' enthaelt normalerweise folgende Eintraege:
+    * Key P_WEAPON:       die Schusswaffe
+    * Key P_WEAPON_TYPE:  P_AMMUNITION, also die Munitions-ID
+    * Key P_STRETCH_TIME: P_STRETCH_TIME der Waffe
+    * Key P_WC:           P_SHOOTING_WC der Waffe
+    * Key P_SHOOTING_WC:  P_SHOOTING_WC der Munition
+    * Key P_AMMUNITION:   Munitionsobjekt (eventuell Unit)
+    * Key SI_ENEMY:       gueltigen Gegner
+    * Key SI_SKILLDAMAGE_TYPE:  Schaden (aus P_DAM_TYPE der Munition)
+    * Key SI_SKILLDAMAGE_MSG/2: Munitionsname
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
+    Methoden:  FindRangedTarget(L), cmd_shoot(L)
+    Skills:    UseSkill(L), SkillResTransfer(L)
+    Attribute: QueryAttribute
+    Sonstiges: fernwaffen, HitFunc
+
+28.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/lfun/short.rst b/doc/sphinx/lfun/short.rst
new file mode 100644
index 0000000..1d1eda3
--- /dev/null
+++ b/doc/sphinx/lfun/short.rst
@@ -0,0 +1,54 @@
+short()
+=======
+
+FUNKTION
+--------
+::
+
+     public varargs string short();
+
+DEFINIERT IN
+------------
+::
+
+     /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+     keine
+
+BESCHREIBUNG
+------------
+::
+
+     Der Inhalt der Property P_SHORT wird ausgewertet, mit ".\n"
+     abgeschlossen und zurueckgegeben.
+
+RUeCKGABEWERT
+-------------
+::
+
+     Die Kurzbeschreibung als String oder 0, falls das Objekt unsichtbar
+     ist.
+
+BEMERKUNGEN
+-----------
+::
+
+     Durch Ueberladen von short() lassen sich noch weitere Eigenschaften des
+     Objektes zeigen. Fackeln zeigen zum Beispiel an, ob sie brennen,
+     Ruestungen, ob sie angezogen sind und Waffen, ob sie gezueckt sind.
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	long()
+     Properties:	P_SHORT, P_INVIS
+     Sonstiges:		make_invlist()
+
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/show_notify.rst b/doc/sphinx/lfun/show_notify.rst
new file mode 100644
index 0000000..92ec9a1
--- /dev/null
+++ b/doc/sphinx/lfun/show_notify.rst
@@ -0,0 +1,73 @@
+show_notify()
+=============
+
+give_notify()
+
+FUNKTION
+--------
+::
+
+     void show_notify(object obj)
+
+DEFINIERT IN
+------------
+::
+
+     /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+     obj - dem Lebewesen gezeigtes Objekt
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird automatisch immer dann aufgerufen, wenn einem
+     Lebewesen (welches kein Spielercharakter ist) ein Objekt gezeigt wird.
+     Dies funktioniert nur dann, wenn der Standardbefehl der Spielershell
+     verwendet wird ("zeige <name> <gegenstand>"). Selbstgebautes "zeige"
+     funktioniert nicht.
+
+BEISPIEL
+--------
+::
+
+     Oftmals will man in Quests erreichen, dass einem NPC ein bestimmtes
+     Item als Beweis der Erfuellung einer bestimmten Aufgabe vorgezeigt
+     wird. Folgendermassen kann dies realisiert werden:
+
+     void quest_ok(object obj) { ...
+       // z.B. Vernichtung des Questobjektes und Questtexte
+       // Questbelohnung und Questanerkennung, etc.
+     }
+
+     void show_notify(object obj) {
+       if(obj->id("\nquestitem")) // Ist das das geforderte Questobjekt?
+         quest_ok(obj);
+     }
+
+BEMERKUNGEN
+-----------
+::
+
+     Da es nur um das Vorzeigen von Gegenstaenden geht, die nicht den 
+     Besitzer wechseln, sind Mechanismen wie P_REJECT in diesem Fall 
+     nicht erforderlich.
+
+SIEHE AUCH
+----------
+::
+
+     give_notify(), /std/npc/put_and_get.c, /std/living/put_and_get.c
+
+22. Oktober 2013 Arathorn
+
diff --git a/doc/sphinx/lfun/spellbook/AddSpell.rst b/doc/sphinx/lfun/spellbook/AddSpell.rst
new file mode 100644
index 0000000..941f6db
--- /dev/null
+++ b/doc/sphinx/lfun/spellbook/AddSpell.rst
@@ -0,0 +1,78 @@
+AddSpell()
+==========
+
+FUNKTION
+--------
+::
+
+    varargs int AddSpell(string verb, int kosten, mixed ski) 
+
+DEFINIERT IN
+------------
+::
+
+    /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+    string verb     Name des Spells
+    int kosten      normale Kosten (Grundkosten)
+    mixed ski       Skillmapping mit allen Eintraegen zum Spell
+
+BESCHREIBUNG
+------------
+::
+
+    Addiert einen Eintrag fuer den Spell im Spellbook. Wenn dieser
+    Spell direkt vom Spieler (SI_SPELLBOOK) oder (normalerweise)
+    ueber ein Gildenobjekt aufgerufen wird, wird das Mapping auf
+    die Skillinformationen aus Spieler und Gilde addiert und
+    beeinflusst damit den Aufruf der letztlichen Spellfunktion.
+
+BEMERKUNGEN
+-----------
+::
+
+    Siehe das Verhalten von QuerySpell (gilde) zum Zusammenfuegen
+    der AddSpell-Informationen aus Gilde und Spellbook. Relevant
+    zB fuer Lernrestriktionen.
+
+BEISPIEL
+--------
+::
+
+    AddSpell("kampfschrei", 30,
+         ([SI_SKILLRESTR_LEARN:([P_LEVEL:13]),
+           SI_MAGIC_TYPE: ({MT_PSYCHO}),
+           SI_SPELL:      ([
+             SP_NAME: "Kampfschrei",
+             SP_SHOW_DAMAGE:
+               ({({ -1, "Dir geschieht jedoch nichts.",
+                   "@WEM1 geschieht jedoch nichts.",
+                   "@WEM1 geschieht jedoch nichts." }),
+                 ({  0, "Du kannst darueber aber nur lachen.",
+                   "@WER1 kann darueber aber nur lachen.",
+                   "@WER1 kann darueber aber nur lachen." }),
+                 ({ 10, "Dir droehnen die Ohren.",
+                   "@WEM1 droehnen die Ohren.",
+                   "@WEM1 droehnen die Ohren." })
+               })])
+         ]));
+
+SIEHE AUCH
+----------
+::
+
+    Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
+    * Verwalten:      QuerySpell
+    * Angriff:        TryAttackSpell, TryDefaultAttackSpell,
+                      TryGlobalAttackSpell
+    * Properties:     P_GLOBAL_SKILLPROPS, P_SB_SPELLS
+    Skills Lernen:    LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:        UseSpell, UseSkill
+    * sonstig:        spruchermuedung, skill_info_liste
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/spellbook/Erfolg.rst b/doc/sphinx/lfun/spellbook/Erfolg.rst
new file mode 100644
index 0000000..98deb90
--- /dev/null
+++ b/doc/sphinx/lfun/spellbook/Erfolg.rst
@@ -0,0 +1,46 @@
+Erfolg()
+========
+
+FUNKTION
+--------
+::
+
+    void Erfolg(object caster, string spell, mapping sinfo)
+
+DEFINIERT IN
+------------
+::
+
+    /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+    object caster    Spell sprechender Spieler
+    string spell     Spellname
+    mapping sinfo    Spell-Info-Mapping mit allen Informationen
+
+BESCHREIBUNG
+------------
+::
+
+    Wird bei Erfolg eines Spells gerufen. Ruft SpellInform() am
+    Environment.
+
+SIEHE AUCH
+----------
+::
+
+    Sonstiges:        SpellInform
+    Spellbook Lernen: Learn, SpellSuccess, Misserfolg
+    * Verwalten:      AddSpell, QuerySpell
+    * Angriff:        TryAttackSpell, TryDefaultAttackSpell,
+                      TryGlobalAttackSpell
+    * Properties:     P_GLOBAL_SKILLPROPS, P_SB_SPELLS
+    Skills Lernen:    LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:        UseSpell, UseSkill
+    * sonstig:        spruchermuedung, skill_info_liste
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/spellbook/Learn.rst b/doc/sphinx/lfun/spellbook/Learn.rst
new file mode 100644
index 0000000..19756a6
--- /dev/null
+++ b/doc/sphinx/lfun/spellbook/Learn.rst
@@ -0,0 +1,54 @@
+Learn()
+=======
+
+FUNKTION
+--------
+::
+
+    void Learn(object caster, string spell, mapping sinfo)
+
+DEFINIERT IN
+------------
+::
+
+    /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+    object caster   Derjenige, der den Spruch spricht.
+    string spell    Der gesprochene Spell
+    mapping sinfo   Mapping mit allen moeglichen Informationen zum Spell
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Funktion wird von der Funktion "Misserfolg" aus dem 
+    Spellbook aufgerufen. Hier lernt der Spieler den Spruch, der 
+    nicht geglueckt ist.
+
+BEMERKUNGEN
+-----------
+::
+
+    Kann auch ueberschrieben werden, wenn man komplexe Lern-Aenderungen
+    vornehmen will. Andere Attribute sind ueber SI_LEARN_ATTRIBUTE
+    setzbar.
+
+SIEHE AUCH
+----------
+::
+
+    Spellbook Lernen: SpellSuccess, Erfolg, Misserfolg
+    * Verwalten:      AddSpell, QuerySpell
+    * Angriff:        TryAttackSpell, TryDefaultAttackSpell,
+                      TryGlobalAttackSpell
+    * Properties:     P_GLOBAL_SKILLPROPS, P_SB_SPELLS
+    Skills Lernen:    LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:        UseSpell, UseSkill
+    * sonstig:        spruchermuedung, skill_info_liste
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/spellbook/Misserfolg.rst b/doc/sphinx/lfun/spellbook/Misserfolg.rst
new file mode 100644
index 0000000..8951868
--- /dev/null
+++ b/doc/sphinx/lfun/spellbook/Misserfolg.rst
@@ -0,0 +1,78 @@
+Misserfolg()
+============
+
+FUNKTION
+--------
+::
+
+    void Misserfolg(object caster, string spell, mapping sinfo) 
+
+DEFINIERT IN
+------------
+::
+
+    /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+    object caster    Spell sprechender Spieler
+    string spell     Spellname
+    mapping sinfo    Spell-Info-Mapping mit allen Informationen
+
+BESCHREIBUNG
+------------
+::
+
+    Wird bei Misserfolg eines Spells im Spellbook aufgerufen und
+    ruft die Lernfunktion Learn() nach einer Fehlermeldung.
+
+    
+
+    Kann ueberschrieben werden, um die Meldungen anzupassen.
+
+BEISPIEL
+--------
+::
+
+    // Misserfolge im Klerus mit angepassten Meldungen
+    void Misserfolg(object caster, string spell, mapping sinfo) {
+      switch(spell) {
+        case "begrabe":
+          tell_object(caster, BS(
+            "Du begraebst Deine Hoffnungen, dass Du diese Anrufung jemals "
+            "perfekt beherrschen wirst."));
+          tell_room(environment(caster),
+            caster->Name(WER)+" tritt die Leiche lustlos.\n", ({caster}));
+          break;
+        case "blitz":
+        [...]
+      }
+
+        
+
+      int old_abil = sinfo[SI_SKILLABILITY];
+      Learn(caster, spell, sinfo);
+      int new_abil = caster->QuerySkillAbility(spell);
+      if (old_abil < new_abil)
+        tell_object(caster, "Die Goetter schenken Dir eine Erleuchtung.\n");
+      else
+        tell_object(caster, "Leider lernst Du nicht aus Deinem Fehler.\n"); 
+    }
+
+SIEHE AUCH
+----------
+::
+
+    Spellbook Lernen: Learn, SpellSuccess, Erfolg
+    * Verwalten:      AddSpell, QuerySpell
+    * Angriff:        TryAttackSpell, TryDefaultAttackSpell,
+                      TryGlobalAttackSpell
+    * Properties:     P_GLOBAL_SKILLPROPS, P_SB_SPELLS
+    Skills Lernen:    LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:        UseSpell, UseSkill
+    * sonstig:        spruchermuedung, skill_info_liste
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/spellbook/QuerySpell.rst b/doc/sphinx/lfun/spellbook/QuerySpell.rst
new file mode 100644
index 0000000..23a72fb
--- /dev/null
+++ b/doc/sphinx/lfun/spellbook/QuerySpell.rst
@@ -0,0 +1,46 @@
+QuerySpell()
+============
+
+FUNKTION
+--------
+::
+
+    mapping QuerySpell(string spell)
+
+DEFINIERT IN
+------------
+::
+
+    /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+    string spell    Name des Spells
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt das Spellmapping aus P_SB_SPELLS fuer diesen Spell zurueck.
+
+    
+
+    Hier enthaelt QuerySpell nur die Spellbook-Informationen.
+
+SIEHE AUCH
+----------
+::
+
+    Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
+    * Verwalten:      AddSpell
+    * Angriff:        TryAttackSpell, TryDefaultAttackSpell,
+                      TryGlobalAttackSpell
+    * Properties:     P_GLOBAL_SKILLPROPS, P_SB_SPELLS
+    Skills Lernen:    LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:        UseSpell, UseSkill
+    * sonstig:        spruchermuedung, skill_info_liste
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/spellbook/SpellSuccess.rst b/doc/sphinx/lfun/spellbook/SpellSuccess.rst
new file mode 100644
index 0000000..2377b8b
--- /dev/null
+++ b/doc/sphinx/lfun/spellbook/SpellSuccess.rst
@@ -0,0 +1,52 @@
+SpellSuccess()
+==============
+
+FUNKTION
+--------
+::
+
+    int SpellSuccess(object caster, mapping sinfo)
+
+DEFINIERT IN
+------------
+::
+
+    /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+    object caster    Spell sprechender Spieler
+    mapping sinfo    Spell-Info-Mapping mit allen Informationen
+
+BESCHREIBUNG
+------------
+::
+
+    Berechnet den Erfolg der Anwendung eines Spells aus seiner
+    SI_SKILLABILITY und dem Skill SK_CASTING im Spieler. Laesst
+    den Spieler bei besonders gutem Gelingen SK_CASTING lernen.
+
+BEMERKUNGEN
+-----------
+::
+
+    SK_CASTING muss fuer die SK_CASTING-Boni beherrscht werden.
+    Das ist zB im Klerus ab bestimmtem Level der Fall.
+
+SIEHE AUCH
+----------
+::
+
+    Spellbook Lernen: Learn, Erfolg, Misserfolg
+    * Verwalten:      AddSpell, QuerySpell
+    * Angriff:        TryAttackSpell, TryDefaultAttackSpell,
+                      TryGlobalAttackSpell
+    * Properties:     P_GLOBAL_SKILLPROPS, P_SB_SPELLS
+    Skills Lernen:    LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:        UseSpell, UseSkill
+    * sonstig:        spruchermuedung, skill_info_liste
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/spellbook/TryAttackSpell.rst b/doc/sphinx/lfun/spellbook/TryAttackSpell.rst
new file mode 100644
index 0000000..d718803
--- /dev/null
+++ b/doc/sphinx/lfun/spellbook/TryAttackSpell.rst
@@ -0,0 +1,58 @@
+TryAttackSpell()
+================
+
+** gilden-doku
+ o TryAttackSpell(opfer,schaden,typen,is_spell,caster,info)
+   Versucht den Angriffs-Spruch auf den Gegner anzuwenden. Die
+   mittleren 4 Werte sind die, die auch bei Defend uebergeben werden.
+   Dabei wird die Abwehrfaehigkeit des Gegners gegen Magie und das
+   Skill-Attribut SA_DAMAGE automatisch beruecksichtigt. 
+
+FUNKTION
+--------
+::
+
+int TryAttackSpell(object victim, int damage, mixed dtypes,
+                   mixed is_spell, object caster, mapping sinfo)
+
+ARGUMENTE
+---------
+::
+
+        victim   : Das arme Opfer.
+        damage   : Der Schaden.
+        dtypes   : Die Schadensarten.
+	      is_spell : Ist es ein Spell? Werden noch Spezielle Parameter 
+	           uebergeben (als mapping) ?
+        caster   : Derjenige, der den Spruch spricht.
+        sinfo    : Mapping mit allen moeglichen Informationen zum Spell
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Funktion wird vom Spellbook aufgerufen, wenn der Spieler
+	einen Angriffsspell gemacht hat und damit Schaden anrichten will.
+
+RUECKGABEWERT
+-------------
+::
+
+	Der Wert, der vom Defend() des Gegners zurueckgeliefert wird.
+
+BEMERKUNGEN
+-----------
+::
+
+	Zu erst wird ueberprueft, ob das Ziel ueberhaupt angreifbar ist. Dies
+	verhindert das ueben von Spells an unangreifbaren NPCs.
+	Als naechstes wird die Faehigkeit, Spells abzuwehren ueberprueft.
+	Falls beide Abfragen ok sind, wird Defend aufgerufen.
+
+
+Siehe auch:
+
+TryDefaultAttackSpell (to be written)
+
+07.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/trigger_sensitive_attack.rst b/doc/sphinx/lfun/trigger_sensitive_attack.rst
new file mode 100644
index 0000000..2067246
--- /dev/null
+++ b/doc/sphinx/lfun/trigger_sensitive_attack.rst
@@ -0,0 +1,98 @@
+trigger_sensitive_attack()
+==========================
+
+FUNKTION
+--------
+::
+
+     varargs void trigger_sensitive_attack(object enemy, string key, int
+     dam, mixed spell, mixed *options);
+
+DEFINIERT IN
+------------
+::
+
+     eigenen sensitiven Objekten, wird aufgerufen von
+     /std/living/inventory.c
+
+ARGUMENTE
+---------
+::
+
+     enemy
+          Der Gegner, der die Aktion ausgeloest hat.
+     key
+          Der ausloesende Schadenstyp.
+     dam
+          Der angerichtete Schaden.
+     spell
+          Wie bei Defend().
+     options
+          Array mit den in P_SENSITIVE angegebenen Optionen fuer diese
+          Aktion.
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn der bei einem Angriff zugefuegte Schaden den in P_SENSITIVE
+     angegebenen Grenzwert uebersteigt sowie der als Schluessel angegebene
+     Schadenstyp in den Schaedenstypen des Angriffes vorkommt, wird diese
+     Funktion aufgerufen und kann entsprechend reagieren.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEISPIELE
+---------
+::
+
+     Eine Fackel, die sich bei Feuerattacken selbst entzuendet und bei
+     Wasserattacken verloescht, koennte man wie folgt implementieren:
+
+     inherit "/std/lightsource.c"
+
+     #include <properties.h>
+     #include <sensitive.h>
+     #include <combat.h>
+
+     create()
+     {
+       ::create();
+
+       SetProp(...); // die ueblichen Eigenschaften definieren
+
+       SetProp(P_SENSITIVE,
+           //  Ereignis          Key       Grenze (keine Optionen)
+         ({ ({ SENSITIVE_ATTACK, DT_FIRE,  100 }),
+            ({ SENSITIVE_ATTACK, DT_WATER, 100 }) }) );
+     }
+
+     varargs void
+     trigger_sensitive_attack(object enemy, string key,
+                              int dam, mixed spell)
+     {
+       // Es soll nicht verschwiegen werden, dass das Entzuenden und
+       // Loeschen einer Lichtquelle so leider nicht funktioniert...
+       if (key == DT_FIRE && !QueryProp(P_LIGHTED)) {
+         SetProp(P_LIGHTED, 1);
+         tell_object(environment(), "Die Fackel faengt Feuer.\n");
+       }
+       else if (key == DT_WATER && QueryProp(P_LIGHTED)) {
+         SetProp(P_LIGHTED, 0);
+         tell_object(environment(), "Die Fackel verlischt.\n");
+       }
+     }
+
+SIEHE AUCH
+----------
+::
+
+     trigger_sensitive_inv(), sensitive Objekte
+
+
+Last modified: Sun May 19 15:56:25 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/trigger_sensitive_inv.rst b/doc/sphinx/lfun/trigger_sensitive_inv.rst
new file mode 100644
index 0000000..9574c2d
--- /dev/null
+++ b/doc/sphinx/lfun/trigger_sensitive_inv.rst
@@ -0,0 +1,62 @@
+trigger_sensitive_inv()
+=======================
+
+FUNKTION
+--------
+::
+
+     varargs void trigger_sensitive_inv(object ob, string key, int wert,
+     mixed *optionen1, mixed *optionen2);
+
+DEFINIERT IN
+------------
+::
+
+     eigenen Objekten, wird aufgerufen von /std/container/inventory.c
+
+ARGUMENTE
+---------
+::
+
+     ob
+          Das ausloesende Objekt
+     key
+          Der Schluessel, der die Aktion ausloeste.
+     wert
+          Der Grenzwert des ausloesenden Objektes.
+     optionen1
+          Die Optionen des ausloesenden Objektes.
+     optionen2
+          Die Optionen des reagierenden Objektes.
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Funktion wird in Objekten des sensitiven Typs SENSITIVE_INVENTORY
+     aufgerufen, wenn sie in Kontakt mit Objekten des Typs
+     SENSITIVE_INVENTORY_TRIGGER treten, die den gleichen Schluessel
+     aufweisen und einen hoeheren Grenzwert haben.
+
+     Anhand der Parameter koennen dann die noetigen Aktionen ausgeloest
+     werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEISPIELE
+---------
+::
+
+SIEHE AUCH
+----------
+::
+
+     trigger_sensitive_attack(), sensitive Objekte
+
+
+Last modified: Wed May 8 10:26:10 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/wield_me.rst b/doc/sphinx/lfun/wield_me.rst
new file mode 100644
index 0000000..f9f3fea
--- /dev/null
+++ b/doc/sphinx/lfun/wield_me.rst
@@ -0,0 +1,18 @@
+wield_me()
+==========
+
+BEMERKUNGEN
+-----------
+::
+
+     wield_me wurde durch DoWield ersetzt.
+
+SIEHE AUCH
+----------
+::
+
+     DoWieldFunc(), /std/weapon.c
+
+
+Last modified: Wed Apr 08 10:25:00 2004 by Muadib
+
diff --git a/doc/sphinx/props/P_ABILITIES.rst b/doc/sphinx/props/P_ABILITIES.rst
new file mode 100644
index 0000000..d84b229
--- /dev/null
+++ b/doc/sphinx/props/P_ABILITIES.rst
@@ -0,0 +1,22 @@
+P_ABILITIES
+===========
+
+NAME
+----
+::
+
+    P_ABILITIES                   "abilities"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+     *** OBSOLET! ***
+     Siehe P_NEWSKILLS.
+
diff --git a/doc/sphinx/props/P_AC.rst b/doc/sphinx/props/P_AC.rst
new file mode 100644
index 0000000..77cdb40
--- /dev/null
+++ b/doc/sphinx/props/P_AC.rst
@@ -0,0 +1,45 @@
+P_AC
+====
+
+NAME
+----
+::
+
+     P_AC "ac"
+
+DEFINIERT IN
+------------
+::
+
+     <armour.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property beschreibt die Ruestungsklasse (engl: armour class),
+     also den Schutz, den die Ruestung dem Traeger verleiht. Je hoeher der
+     Wert (als Zahl), um so besser ist die Ruestung. Negative Werte bewirken
+     negativen Schutz, d.h. der Schaden wird vergroessert statt verringert.
+
+BEMERKUNGEN
+-----------
+::
+
+     Query- und Setmethoden auf P_AC sollten unbedingt vermieden werden. Sie
+     fuehren in der Regel zu massiven Inkonsistenzen im Mechanismus der
+     Ruestungsbeschaedigung und -reparatur.
+     Fuer jeden Ruestungstyp ist in <combat.h> eine Obergrenze definiert,
+     die man nicht ueberschreiten darf.
+     Ruestungen vom Typ AT_MISC haben immer AC 0 und werden mit keinen 
+     hoeheren Werten genemigt.
+
+SIEHE AUCH
+----------
+::
+
+     /std/armour.c, P_DAMAGED, Damage() P_TOTAL_AC
+
+
+02.10.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_ACCEPT_PEACE.rst b/doc/sphinx/props/P_ACCEPT_PEACE.rst
new file mode 100644
index 0000000..5b0c580
--- /dev/null
+++ b/doc/sphinx/props/P_ACCEPT_PEACE.rst
@@ -0,0 +1,37 @@
+P_ACCEPT_PEACE
+==============
+
+PROPERTY
+--------
+::
+
+     P_ACCEPT_PEACE                           "accept_peace"
+
+DEFINIERT IN 
+-------------
+::
+
+	/sys/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	Mittels setzen Dieser Prop lassen sich leicht NPCs bauen,
+	die von jedem zu befrieden sind. Wenn die Property == 1 ist,
+	ist der NPC immer wieder befriedbar, sonst fuehrt der NPC das
+	uebliche Verhalten aus.
+
+SIEHE AUCH
+----------
+::
+
+  QueryPacify(),
+  P_PEACE_HISTORY
+
+LETZTE AENDERUNG
+----------------
+::
+
+01.05.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_ACHATS.rst b/doc/sphinx/props/P_ACHATS.rst
new file mode 100644
index 0000000..cca00ee
--- /dev/null
+++ b/doc/sphinx/props/P_ACHATS.rst
@@ -0,0 +1,21 @@
+P_ACHATS
+========
+
+NAME
+----
+::
+
+    P_ACHATS                      "achats"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Chats, die das Monster im Kampf ausgibt.
+
diff --git a/doc/sphinx/props/P_ACHAT_CHANCE.rst b/doc/sphinx/props/P_ACHAT_CHANCE.rst
new file mode 100644
index 0000000..68054e6
--- /dev/null
+++ b/doc/sphinx/props/P_ACHAT_CHANCE.rst
@@ -0,0 +1,21 @@
+P_ACHAT_CHANCE
+==============
+
+NAME
+----
+::
+
+    P_ACHAT_CHANCE                "achat_chance"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wahrscheinlichkeit fuer die Attack-Chat-Ausgabe.
+
diff --git a/doc/sphinx/props/P_ACTUAL_NOTIFY_FAIL.rst b/doc/sphinx/props/P_ACTUAL_NOTIFY_FAIL.rst
new file mode 100644
index 0000000..a69d43d
--- /dev/null
+++ b/doc/sphinx/props/P_ACTUAL_NOTIFY_FAIL.rst
@@ -0,0 +1,50 @@
+P_ACTUAL_NOTIFY_FAIL
+====================
+
+********************** VERALTETE PROPERTY *********************************
+
+NAME
+----
+::
+
+     P_ACTUAL_NOTIFY_FAIL          "actual_notify_fail"          
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player.h
+
+ACHTUNG
+-------
+::
+
+     Diese Prop wird nicht mehr gesetzt (und auch nicht mehr abgefragt), da LD
+     eine efun hat, um das Objekt zu ermitteln, was als letztes ein
+     notify_fail() gesetzt hat, ein Speichern im Spieler also voellig
+     ueberfluessig ist.
+
+BESCHREIBUNG
+------------
+::
+
+     Ist im Spielerobjekt  gesetzt und enthaelt das Objekt, welches zuletzt
+     eine Fehlermeldung mit notify_fail()/_notify_fail() erfolgreich
+     waehrend des aktuellen Kommandos abgespeichert hat.
+
+BEMERKUNGEN
+-----------
+::
+
+     Dient dazu, bei _notify_fail() zu ueberpruefen, ob schon vorher eine
+     Fehlermeldung gesetzt wurde.
+
+SIEHE AUCH
+----------
+::
+
+     AddCmd(), add_action()
+     notify_fail(), _notify_fail()
+
+10.03.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_ADJECTIVES.rst b/doc/sphinx/props/P_ADJECTIVES.rst
new file mode 100644
index 0000000..9357c62
--- /dev/null
+++ b/doc/sphinx/props/P_ADJECTIVES.rst
@@ -0,0 +1,39 @@
+P_ADJECTIVES
+============
+
+NAME
+----
+::
+
+     P_ADJECTIVES "adjectives"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Hier steht ein Array von Strings, welche die Identifizierung des
+     Objektes ergaenzen. Die Verwaltung erfolgt ueber die Funktionen
+     AddAdjective() und RemoveAdjective().
+
+BEMERKUNGEN
+-----------
+::
+
+     Man sollte an dieser Property nicht "von Hand" herumfummeln, sondern
+     immer die zugehoerigen Funktionen benutzen!
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/description.c, AddAdjective(), RemoveAdjective()
+
+
+Last modified: Sun May 19 20:22:24 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_AERIAL_HELPERS.rst b/doc/sphinx/props/P_AERIAL_HELPERS.rst
new file mode 100644
index 0000000..df12a3b
--- /dev/null
+++ b/doc/sphinx/props/P_AERIAL_HELPERS.rst
@@ -0,0 +1,64 @@
+P_AERIAL_HELPERS
+================
+
+NAME
+----
+::
+
+     P_AERIAL_HELPERS "lib_p_aerial_helpers"
+
+DEFINIERT IN
+------------
+::
+
+     <living/helpers.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property kann in allen Lebewesen abgefragt werden, um die Objekte
+     zu ermitteln, die fuer die Unterstuetzung beim Fliegen/Segeln bei diesem 
+     Lebewesen registriert haben. Die Daten werden als Mapping der folgenden
+     Form zurueckgeliefert:
+     ([ Objekt : Rueckgabewert von dessen Callback-Methode ])
+     Eine Erlaeuterung dazu findet sich in der Dokumentation zu 
+     RegisterHelperObject().
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Property kann nur abgefragt werden.
+     Es ist erwuenscht, dass entsprechende, neu geschaffene Stellen jegliche 
+     Helfer akzeptieren, deren Callback-Methode >0 zurueckgibt.
+
+BEISPIEL
+--------
+::
+
+     Um zu ermitteln, ob der Spieler mindestens ein Objekt bei sich hat, das 
+     beim Fliegen hilft, sucht man alle Objekte aus dem Mapping heraus, die
+     einen Wert >0 eingetragen haben und prueft deren Anzahl:
+
+     mapping aerial = this_player()->QueryProp(P_AERIAL_HELPERS);
+     object* helpers = filter( aerial, function int (object h) {
+                         return (aerial[h]>0); });
+     if ( sizeof(helpers) ) {
+       tell_object(this_player(), "Du erhebst Dich mit Hilfe "+
+         helpers[0]->name(WESSEN,1)+" elegant in die Luefte.\n");
+     }
+     else {
+       tell_object(this_player(), "Du hast nichts zum Fliegen bei Dir.\n");
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Methoden:    RegisterHelperObject(L), UnregisterHelperObject(L)
+     Properties:  P_HELPER_OBJECTS, P_AQUATIC_HELPERS
+
+
+12.03.2016, Arathorn
+
diff --git a/doc/sphinx/props/P_AGE.rst b/doc/sphinx/props/P_AGE.rst
new file mode 100644
index 0000000..b75a773
--- /dev/null
+++ b/doc/sphinx/props/P_AGE.rst
@@ -0,0 +1,21 @@
+P_AGE
+=====
+
+NAME
+----
+::
+
+    P_AGE                         "age"                         
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Alter des Spielers in Heart-Beats (1 HB == 2 Sekunden)
+
diff --git a/doc/sphinx/props/P_AGGRESSIVE.rst b/doc/sphinx/props/P_AGGRESSIVE.rst
new file mode 100644
index 0000000..fc5ee1b
--- /dev/null
+++ b/doc/sphinx/props/P_AGGRESSIVE.rst
@@ -0,0 +1,55 @@
+P_AGGRESSIVE
+============
+
+NAME
+----
+::
+
+    P_AGGRESSIVE                  "aggressive"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+	Gesetzt, wenn das Wesen von sich aus Angriffe startet.
+
+	Ueblicherweise nimmt man als Wert 1, man kann jedoch auch
+	einen kleineren Wert nehmen wenn es nur mit einer bestimmten
+	Wahrscheinlichkeit automatisch angreifen soll.
+
+	Der Wert von Spieler und Monster wird addiert, um zu entscheiden,
+	ob ein Spieler angegriffen werden soll,	man kann P_AGGRESSIVE
+	also auch bei Spielern setzen, so dass sie von allen Monstern
+	angegriffen werden.
+
+	Bei Monstern (und NUR bei diesen) kann man hier auch ein Mapping
+	angeben, das als Keys Namen von Properties des Spielers enthaelt
+	und als Values Mappings, in denen steht welcher Wert bei welchen
+	Wert fuer die Property genommen werden soll (Beispiele folgen).
+	Mit Key 0 kann man einen Default-Wert (sowohl in inneren Mappings
+	wie auch im aeusseren Mapping) festlegen. Default-Werte werden
+	genommen, falls keine anderen gesetzt sind, also Vorsicht mit
+	0-Eintraegen (Tip: 0.0 ist in LPC ungleich 0).
+	Bei mehreren Properties werden alle gesetzten Werte gemittelt.
+
+BEISPIELE
+---------
+::
+
+	SetProp(P_AGGRESSIVE,([P_RACE:(["Zwerg":1, "Elf":0.0, 0:0.5])]))
+	Zwerge werden immer automatisch angegriffen, Elfen nie und
+	alle anderen mit 50% Wahrscheinlichkeit.
+	Man beachte, dass hier 0.0 genommen werden musste anstelle von 0,
+	weil sonst Elfen auch 50% Wahrscheinlichkeit bekommen haetten.
+
+	SetProp(P_AGGRESSIVE,([P_RACE:(["Zwerg":0.3]),
+	                       P_GUILD:(["Chaos":0.7])]))
+	Zwerge werden mit 30% Wahrscheinlichkeit angegriffen,
+	Chaoten mit 70% und Zwerg-Chaoten mit 50%.
+
diff --git a/doc/sphinx/props/P_ALCOHOL.rst b/doc/sphinx/props/P_ALCOHOL.rst
new file mode 100644
index 0000000..7c29af5
--- /dev/null
+++ b/doc/sphinx/props/P_ALCOHOL.rst
@@ -0,0 +1,37 @@
+P_ALCOHOL
+=========
+
+NAME
+----
+::
+
+     P_ALCOHOL			"alcohol"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     - Lebewesen
+       Numerischer Wert fuer den Grad der Betrunkenheit eines Lebewesens.
+       Der maximale Wert steht in P_MAX_ALCOHOL.
+
+     - Speisen/Kneipen
+       Numerischer Wert fuer den Grad, den eine Portion der Speise den
+       Konsumenten betrunken macht
+
+SIEHE AUCH
+----------
+::
+
+	P_MAX_ALCOHOL, P_ALCOHOL_DELAY, consume,
+	P_FOOD, P_DRINK, wiz/food, 
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_ALCOHOL_DELAY.rst b/doc/sphinx/props/P_ALCOHOL_DELAY.rst
new file mode 100644
index 0000000..d0626a5
--- /dev/null
+++ b/doc/sphinx/props/P_ALCOHOL_DELAY.rst
@@ -0,0 +1,23 @@
+P_ALCOHOL_DELAY
+===============
+
+NAME
+----
+::
+
+    P_ALCOHOL_DELAY                 "alcohol_delay"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der heart_beats, bis P_ALCOHOL um einen Punkt sinkt.
+     Aenderungen dieser Property in Spielern beduerfen der 
+     Genehmigung des EM fuer Balance.
+
diff --git a/doc/sphinx/props/P_ALC_FULL_MSG.rst b/doc/sphinx/props/P_ALC_FULL_MSG.rst
new file mode 100644
index 0000000..3d6e160
--- /dev/null
+++ b/doc/sphinx/props/P_ALC_FULL_MSG.rst
@@ -0,0 +1,50 @@
+P_ALC_FULL_MSG
+==============
+
+NAME
+----
+::
+
+     P_ALC_FULL_MSG                "std_food_alc_full_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn Alkohol konsumiert werden soll,
+     obwohl dieser nicht mehr Alkohol vertraegt.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "Soviel Alkohol vertraegst Du nicht mehr."
+
+SIEHE AUCH
+----------
+::
+
+     P_ALCOHOL, P_MAX_ALCOHOL, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_ALIGN.rst b/doc/sphinx/props/P_ALIGN.rst
new file mode 100644
index 0000000..fd944b2
--- /dev/null
+++ b/doc/sphinx/props/P_ALIGN.rst
@@ -0,0 +1,30 @@
+P_ALIGN
+=======
+
+NAME
+----
+::
+
+    P_ALIGN                       "align"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Numerischer Wert fuer Gut- oder Boesheit des Wesens.
+
+     Kann Werte von -1000 (Boese wie der Teufel hoechstpersoenlich)
+     bis +1000 (Jesus, bist Du's ?) annehmen.
+
+     Werte ausserhalb dieser Skala werden zwar teilweise verwendet,
+     das Setzen derselben sollte jedoch UNBEDINGT unterbleiben.
+
+
+Last modified: Sat Jul 12 17:00:00 by Mandragon
+
diff --git a/doc/sphinx/props/P_ALLOWED_SHADOW.rst b/doc/sphinx/props/P_ALLOWED_SHADOW.rst
new file mode 100644
index 0000000..d6578e4
--- /dev/null
+++ b/doc/sphinx/props/P_ALLOWED_SHADOW.rst
@@ -0,0 +1,38 @@
+P_ALLOWED_SHADOW
+================
+
+NAME
+----
+::
+
+    P_ALLOWED_SHADOW              "allowed_shadow"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Normalerweise koennen nur Shadows an Spieler gebunden werden, die in 
+     /std/player/shadows/ liegen. 
+
+     
+
+     Zu Testzwecken kann in dieser Property der Pfad eines Shadows eingetragen
+     werden. Damit wird die oben beschriebene Regel fuer diesen Spieler und 
+     diesen Shadow ausser Kraft gesetzt.
+
+BEMERKUNG: 
+
+     Der Spieler muss ein Testspieler sein. Ansonsten wird diese Property
+     ignoriert.
+
+     Die Property ist secured gesetzt. Das heisst, nur EM+ koennen
+     diese Property setzen und loeschen.
+
+Last modified: Sun Mar 21 00:27:46 2004 by Vanion
+
diff --git a/doc/sphinx/props/P_AMMUNITION.rst b/doc/sphinx/props/P_AMMUNITION.rst
new file mode 100644
index 0000000..f2a281d
--- /dev/null
+++ b/doc/sphinx/props/P_AMMUNITION.rst
@@ -0,0 +1,62 @@
+P_AMMUNITION
+============
+
+NAME
+----
+::
+
+    P_AMMUNITION     "munition"
+
+DEFINIERT IN
+------------
+::
+
+    <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die fuer eine Waffe gueltige Munition als String. Die
+    Munition muss diesen String als ID besitzen.
+
+    Fuer die Munitionsobjekte gilt:
+    * es kann ein Skill am Spieler definiert werden, dieser wirkt dann
+      zusaetzlich zum generellen SK_SHOOT-Skill.
+    * sie koennen eine HitFunc besitzten, die beim Schuss abgefragt wird
+
+BEMERKUNGEN
+-----------
+::
+
+    Bitte das #define MUN_MISC(x) benutzen. Munition sollte auch immer
+    in Deutsch und Plural angegeben werden, da P_AMMUNITION direkt
+    fuer Ausgaben an den Spieler ausgewertet wird.
+
+    Momentan sind vier Munitionsarten in der combat.h vordefiniert:
+    MUN_ARROW, MUN_STONE, MUN_BOLT, MUN_MISC
+
+BEISPIELE
+---------
+::
+
+    // fuer ein kleines Blasrohr im Blasrohr
+    SetProp(P_AMMUNITION, MUN_MISC("Erbsen"));
+
+    // Entsprechend in der Munition:
+    AddId(MUN_MISC("Erbsen"));
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_SHOOTING_WC, P_STRETCH_TIME
+    Methoden:  FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
+    Gebiet:    P_RANGE, P_SHOOTING_AREA, P_TARGET_AREA
+    Waffen:    P_WEAPON_TYPE, P_WC, P_EQUIP_TIME, P_NR_HANDS
+    Kampf:     Attack(L), Defend(L), P_DISABLE_ATTACK, P_ATTACK_BUSY
+    Team:      PresentPosition(L)
+    Sonstiges: fernwaffen
+
+29.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/props/P_AMOUNT.rst b/doc/sphinx/props/P_AMOUNT.rst
new file mode 100644
index 0000000..632880a
--- /dev/null
+++ b/doc/sphinx/props/P_AMOUNT.rst
@@ -0,0 +1,21 @@
+P_AMOUNT
+========
+
+NAME
+----
+::
+
+    P_AMOUNT                      "amount"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der Objekte, fuer die das Objekt steht.
+
diff --git a/doc/sphinx/props/P_AQUATIC_HELPERS.rst b/doc/sphinx/props/P_AQUATIC_HELPERS.rst
new file mode 100644
index 0000000..6055df9
--- /dev/null
+++ b/doc/sphinx/props/P_AQUATIC_HELPERS.rst
@@ -0,0 +1,65 @@
+P_AQUATIC_HELPERS
+=================
+
+NAME
+----
+::
+
+     P_AQUATIC_HELPERS "lib_p_aquatic_helpers"
+
+DEFINIERT IN
+------------
+::
+
+     <living/helpers.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property kann in allen Lebewesen abgefragt werden, um die Objekte
+     zu ermitteln, die fuer die Unterstuetzung beim Tauchen bei diesem 
+     Lebewesen registriert haben. Die Daten werden als Mapping der folgenden
+     Form zurueckgeliefert:
+     ([ Objekt : Rueckgabewert von dessen Callback-Methode ])
+     Eine Erlaeuterung dazu findet sich in der Dokumentation zu 
+     RegisterHelperObject().
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Property kann nur abgefragt werden.
+     Es ist erwuenscht, dass entsprechende, neu geschaffene Stellen jegliche 
+     Helfer akzeptieren, deren Callback-Methode >0 zurueckgibt.
+
+BEISPIEL
+--------
+::
+
+     Um zu ermitteln, ob der Spieler mindestens ein Objekt bei sich hat, das 
+     beim Tauchen hilft, sucht man alle Objekte aus dem Mapping heraus, die
+     einen Wert >0 eingetragen haben und prueft deren Anzahl:
+
+     mapping aquatic = this_player()->QueryProp(P_AQUATIC_HELPERS);
+     object* helpers = filter( aquatic, function int (object h) {
+                         return (aquatic[h]>0); });
+     if ( sizeof(helpers) ) {
+       tell_object(this_player(), "Du stuerzt Dich in die Fluten und "
+         "stellst ueberrascht fest, dass Du mit Hilfe "+
+         helpers[0]->name(WESSEN,1)+" sogar unter Wasser atmen kannst!\n");
+     }
+     else {
+       tell_object(this_player(), "Du hast nichts zum Tauchen bei Dir.\n");
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Methoden:    RegisterHelperObject(L), UnregisterHelperObject(L)
+     Properties:  P_HELPER_OBJECTS, P_AERIAL_HELPERS
+
+
+06.04.2016, Arathorn
+
diff --git a/doc/sphinx/props/P_ARMOURS.rst b/doc/sphinx/props/P_ARMOURS.rst
new file mode 100644
index 0000000..3268fda
--- /dev/null
+++ b/doc/sphinx/props/P_ARMOURS.rst
@@ -0,0 +1,41 @@
+P_ARMOURS
+=========
+
+NAME
+----
+::
+
+     P_ARMOURS                     "armours"
+
+DEFINIERT IN
+------------
+::
+
+     <living/combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Array mit den getragenen Schutzbekleidungen des Lebewesen.
+
+     Bitte nach Moeglichkeit davon absehen, diese Property zu beschreiben, da
+     es hierbei zu Inkonsistenzen kommen kann.
+
+     
+
+     Falls ihr die Ruestungen des Lebewesens, ggf. mit bestimten Kriterien,
+     ermitteln wollt, benutzt hierfuer bitte die Funktion FilterArmours()
+     statt selber ueber dieses Array zu laufen.
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt:		QueryArmourByType(L), P_WEAPON, FilterClothing(), 
+                  FilterArmours()
+     Ruestungen:	P_AC, P_ARMOUR_TYPE, P_NR_HANDS
+     Sonstiges:		P_EQUIP_TIME, P_LAST_USE
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_ARMOUR_TYPE.rst b/doc/sphinx/props/P_ARMOUR_TYPE.rst
new file mode 100644
index 0000000..71f1bfb
--- /dev/null
+++ b/doc/sphinx/props/P_ARMOUR_TYPE.rst
@@ -0,0 +1,63 @@
+P_ARMOUR_TYPE
+=============
+
+NAME
+----
+::
+
+     P_ARMOUR_TYPE "armour_type"
+
+DEFINIERT IN
+------------
+::
+
+     <armour.h>
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property wird der Typ einer Ruestung festgehalten. Man sollte
+     hier nur die in <combat.h> definierten Konstanten verwenden:
+
+        AT_AMULET     Amulett
+        AT_ARMOUR     Ruestung
+        AT_BELT       Guertel
+        AT_BOOT       Schuhe
+        AT_CLOAK      Umhang
+        AT_GLOVE      Handschuhe
+        AT_HELMET     Helm
+        AT_QUIVER     Koecher
+        AT_RING       Ring
+        AT_SHIELD     Schild
+        AT_TROUSERS   Hosen
+        AT_MISC       Sonstiges
+
+     Der Ruestungstyp AT_MISC ist schnoedem Tand und anderem nutzlosen
+     Kram vorbehalten. Auf keinen Fall darf eine AT_MISC-Ruestung ueber
+     eine AC > 0 verfuegen noch irgendwie kampfrelevante Bedeutung be-
+     sitzen. Ruestungen des Typs AT_MISC, die KEINE DefendFunc benoetigen,
+     muessen mittels /std/clothing als einfaches Kleidungsstueck realisiert
+     werden.
+
+BEMERKUNGEN
+-----------
+::
+
+     Die P_AC wird bei AT_MISC-Ruestungen gar nicht erst ausgewertet.
+     DefendFuncs werden zwar ausgewertet, aber bitte ueberlegt euch gut, ob
+     ihr sie braucht (Rechenzeit im Kampf ist kritisch!) und ob sie seitens 
+     der Balance in eurem Fall erlaubt sind.
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt:          QueryArmourByType(L), P_WEAPON
+     Ruestungen:        P_AC, P_NR_HANDS (Schilde)
+     Sonstiges:         P_EQUIP_TIME, P_LAST_USE
+     Code:              /std/armour.c, /std/clothing.c
+     Gildenergaenzung:  P_GLOVE_FINGERLESS
+
+27. Mai 2015, Arathorn
+
diff --git a/doc/sphinx/props/P_ARRIVEMSG.rst b/doc/sphinx/props/P_ARRIVEMSG.rst
new file mode 100644
index 0000000..73b3ac9
--- /dev/null
+++ b/doc/sphinx/props/P_ARRIVEMSG.rst
@@ -0,0 +1,21 @@
+P_ARRIVEMSG
+===========
+
+NAME
+----
+::
+
+    P_ARRIVEMSG                   "arrivemsg"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung, wenn der Transporter anlegt.
+
diff --git a/doc/sphinx/props/P_ARTICLE.rst b/doc/sphinx/props/P_ARTICLE.rst
new file mode 100644
index 0000000..363cd08
--- /dev/null
+++ b/doc/sphinx/props/P_ARTICLE.rst
@@ -0,0 +1,28 @@
+P_ARTICLE
+=========
+
+NAME
+----
+::
+
+    P_ARTICLE                     "article"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/language.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt an, ob in der Beschreibung ein Artikel ausgegeben werden soll
+     oder nicht.
+
+     Wenn ein Artikel angegeben werden soll, so wird 1 gesetzt, sonst 0.
+     Diese Property ist aus historischen Gruenden auf 1 voreingestellt
+     und intern invertiert. (d.h., beim Auslesen per Query kommt als 
+     Ergebnis genau das falsche heraus). Bitte beachtet das bei Set- bzw.
+     Query-Funktionen.
+
diff --git a/doc/sphinx/props/P_ATTACK_BUSY.rst b/doc/sphinx/props/P_ATTACK_BUSY.rst
new file mode 100644
index 0000000..3e15aef
--- /dev/null
+++ b/doc/sphinx/props/P_ATTACK_BUSY.rst
@@ -0,0 +1,69 @@
+P_ATTACK_BUSY
+=============
+
+NAME
+----
+::
+
+    P_ATTACK_BUSY                 "attack_busy"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    Ueber diese Property kann festgestellt werden, ob ein Spieler noch 
+    Spezialwaffen (zB Flammenkugel) einsetzen kann.
+
+    
+
+    Ist der Wert bei Abfrage ungleich 0, dann darf der Spieler in dieser
+    Runde keine Aktion mehr durchfuehren. Mit SetProp(P_ATTACK_BUSY, 1)
+    wird eine Aktion verbraucht.
+
+    Intern wird relativ fein gerechnet, ein SetProp(P_ATTACK_BUSY, x)
+    wird in das Abziehen von x*100 Punkten umgerechnet. Der Wert freier
+    Aktionen pro Runde berechnet sich wie folgt:
+
+    
+
+    Spieler: 100 + QuerySkillAttribute(SA_SPEED)
+    Seher:   Spieler + 200 + QueryProp(P_LEVEL)
+
+    Das Maximum liegt bei 500.
+    Damit betraegt die Anzahl der moeglichen Aktionen pro Runde: Wert/100,
+    also maximal 5 Aktionen pro Runde.
+
+    Zaubersprueche zaehlen im Normalfall auch als eine Aktion.
+
+BEMERKUNGEN
+-----------
+::
+
+    Benutzt man P_ATTACK_BUSY fuer eine sich nicht sofort verbrauchende
+    Sache, kann ein Seher dieses Objekt im Normalfall dreimal pro Runde
+    benutzen. Wenn ungewollt, muss das ueber einen Zeitmarker selbst
+    verhindert werden.
+
+    
+
+BEISPIELE
+---------
+::
+
+    (Code eines Objektes ist in
+     /doc/beispiele/testobjekte/attack_busy_sensitive_testobj.c)
+    // einfacher Test auf ATTACK_BUSY und anschliessendes Setzen
+    if (this_player()->QueryProp(P_ATTACK_BUSY)) {
+      write("Du hast dafuer momentan einfach nicht mehr die Puste.\n");
+      return 1;
+    }
+    this_player()->SetProp(P_ATTACK_BUSY, 1);
+
+7. Mar 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_ATTRIBUTES.rst b/doc/sphinx/props/P_ATTRIBUTES.rst
new file mode 100644
index 0000000..d3bbc0e
--- /dev/null
+++ b/doc/sphinx/props/P_ATTRIBUTES.rst
@@ -0,0 +1,80 @@
+P_ATTRIBUTES
+============
+
+NAME
+----
+::
+
+	P_ATTRIBUTES			"attributes"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt ein Mapping mit den Attributen des
+	Lebewesens. Die Schluessel kennzeichnen hierbei das jeweilige
+	Attribut. Die verschiedenen Standardattribute findet man in
+	/sys/living/attributes.h, welche derzeit folgende Moeglichkeiten
+	bieten:	- A_STR (Kraft)
+		- A_INT (Intelligenz)
+		- A_DEX (Geschick)
+		- A_CON (Konstitution)
+	Sie werden automatisch an verschiedenen Stellen in der MUDLib
+	ausgewertet, zum Beispiel bestimmt A_INT die maximal moeglichen
+	Konzentrationspunkte und A_CON die maximal moeglichen Lebenspunkte.
+
+BEMERKUNGEN
+-----------
+::
+
+        Keine echte Property, _query_attributes() und _set_attributes() sind 
+        in /std/living/attributes.c implementiert.
+
+	Es bietet sich an, zum Erfragen der Attributwerte die Funktion
+	QueryAttribute() zu nutzen, da es auch moegliche Offsets gibt,
+	so beispielsweise ueber die Properties P_ATTRIBUTES_OFFSETS bzw.
+	P_ATTRIBUTES_MODIFIER im Lebewesen selbst, oder auch ueber
+	P_X_ATTR_MOD bzw. P_M_ATTR_MOD in Objekten im Lebewesen.
+	Kurzfristige zeit- oder objektgebundene Attributveraenderungen
+	koennen ueber die Property P_TIMED_ATTR_MOD realisiert werden.
+
+	Es gibt auch zahlreiche andere Dienstfunktionen fuer diesen sehr
+	balancekritischen Bereich, siehe unten.
+
+BEISPIEL
+--------
+::
+
+	Ein moegliches Ergebnis fuer einen frischen Level 1 Spieler waere:
+	  QueryProp(P_ATTRIBUTES);
+	  Ergebnis: (["int":1,"con":1,"str":1,"dex":1])
+	Hinzu kommen eventuell moegliche Rassenboni, die mittels
+	P_ATTRIBUTE_OFFSETS realisiert werden, Zwerge sind beispielsweise
+	recht stark:
+	  QueryProp(P_ATTRIBUTES_OFFSETS);
+	  Ergebnis: (["int":1,"con":1,"str":1,"dex":3])
+	Jetzt bekaeme man (sofern keine weiteren Offsets realisiert sind)
+	mittels QueryAttribute() insgesamt:
+	  QueryAttribute(A_DEX);
+	  Ergebnis: 4
+
+SIEHE AUCH
+----------
+::
+
+	QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+	SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+	SetTimedAttrModifier(), QueryTimedAttrModifier(),
+	DeleteTimedAttrModifier(),
+	P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,P_TIMED_ATTR_MOD,
+	P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/props/P_ATTRIBUTES_MODIFIER.rst b/doc/sphinx/props/P_ATTRIBUTES_MODIFIER.rst
new file mode 100644
index 0000000..872de97
--- /dev/null
+++ b/doc/sphinx/props/P_ATTRIBUTES_MODIFIER.rst
@@ -0,0 +1,78 @@
+P_ATTRIBUTES_MODIFIER
+=====================
+
+NAME
+----
+::
+
+    P_ATTRIBUTES_MODIFIER         "attributes_modifier"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Property werden Attribut-Modifikatoren gespeichert, die
+    laengere Zeit wirksam sein sollen, tlw. auch ueber einen Reboot
+    hinweg.
+    Intern werden die Modifikatoren in einem Mapping der Form
+
+        ([ Setzer-Key : ([ A_xy : Wert, ... ]) , ... ])
+
+    gespeichert. Das Setzen folg hingegen in der Form
+
+        spieler->SetProp(P_ATTRIBUTES_MODIFIER, ([ A_xy : Wert, ... ]));
+    oder
+        spieler->SetProp(P_ATTRIBUTES_MODIFIER, ({ Setzer-Key, ([ ... ]) }));
+
+    Bei der ersten Variante wird hierbei der Filename des setzenden Objektes
+    als Setzer-Key genommen.
+    Es koennen also durchaus von mehreren Objekten Modifier gesetzt werden.
+    Bekannte Modifier sind:
+
+        #death      Attribut-Abzug durch Todesfolgen      (Mudlib)
+        #drain      Statabzug durch NPCs                  (Paracelsus)
+        #frosch     Staerken-Abzug bei Froeschen          (Mudlib)
+
+BEMERKUNGEN
+-----------
+::
+
+    Keine echte Property, _query_attributes_modifier() und
+    _set_attributes_modifier() sind in /std/living/attributes.c
+    implementiert
+    - SetProp/QueryProp nutzen!
+    - Wenn ein Modifier nicht mehr gebracht wird, nicht die Attributswerte auf
+      0 setzen, sondern den ganzen Eintrag! also:
+      SetProp(P_ATTRIBUTES_MODIFIER, ([]) );
+      oder: SetProp(P_ATTRIBUTES_MODIFIER, 0 ); 
+      aber nicht: SetProp(P_ATTRIBUTES_MODIFIER, ([A_STR:0]));
+
+BEISPIELE
+---------
+::
+
+    // ein Bonus ... 'ende'-fest (muss also per uid gesichert werden)
+    player->SetProp(P_ATTRIBUTES_MODIFIER,
+                    ({"g_klerus_segen", ([A_CON:5, A_INT:5])}));
+    ...
+    player->SetProp(P_ATTRIBUTES_MODIFIER, ({"g_klerus_segen", 0}));
+
+SIEHE AUCH
+----------
+::
+
+	QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+	SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+	SetTimedAttrModifier(), QueryTimedAttrModifier(),
+	DeleteTimedAttrModifier(),
+	P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+	P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/props/P_ATTRIBUTES_OFFSETS.rst b/doc/sphinx/props/P_ATTRIBUTES_OFFSETS.rst
new file mode 100644
index 0000000..a17993e
--- /dev/null
+++ b/doc/sphinx/props/P_ATTRIBUTES_OFFSETS.rst
@@ -0,0 +1,46 @@
+P_ATTRIBUTES_OFFSETS
+====================
+
+NAME
+----
+::
+
+	P_ATTRIBUTES_OFFSETS		"attributes_offsets"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt ein Mapping mit Offsets, die zu den
+	Attributen eine Lebewesens addiert werden. Diese koennen auch
+	negativ sein! Realisiert werden damit beispielsweise Rassenboni.
+	Es gibt noch weitere Moeglichkeiten, Attributoffsets anzugeben.
+	Fuer weiteres siehe P_ATTRIBUTES.
+
+BEMKERUNGEN
+-----------
+::
+
+        Keine echte Property, _query_attributes_offsets() und 
+        _set_attributes_offsets() sind in /std/living/attributes.c 
+        implementiert.
+
+SIEHE AUCH
+----------
+::
+
+	QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+	SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+	SetTimedAttrModifier(), QueryTimedAttrModifier(),
+	DeleteTimedAttrModifier(),
+	P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+	P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/props/P_AUTH_INFO.rst b/doc/sphinx/props/P_AUTH_INFO.rst
new file mode 100644
index 0000000..357fe6d
--- /dev/null
+++ b/doc/sphinx/props/P_AUTH_INFO.rst
@@ -0,0 +1,21 @@
+P_AUTH_INFO
+===========
+
+NAME
+----
+::
+
+    P_AUTH_INFO                   "auth_info"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Username des Spielers, wenn bei ihm ein AUTHD laeuft
+
diff --git a/doc/sphinx/props/P_AUTOLOAD.rst b/doc/sphinx/props/P_AUTOLOAD.rst
new file mode 100644
index 0000000..31372c1
--- /dev/null
+++ b/doc/sphinx/props/P_AUTOLOAD.rst
@@ -0,0 +1,31 @@
+P_AUTOLOAD
+==========
+
+NAME
+----
+::
+
+    P_AUTOLOAD                    "autoload"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mapping mit der Menge der Autoloadobjekte und den zugeh.
+     Properties.
+
+BEMERKUNGEN
+-----------
+::
+
+     Funktioniert momentan nicht. Die Methode wurde entfernt. Doku bleibt
+     hier bis der Fall geklaert ist. (Stand 27.Aug 2006)
+
+27.Aug 2006 Gloinson
+
diff --git a/doc/sphinx/props/P_AUTOLOADOBJ.rst b/doc/sphinx/props/P_AUTOLOADOBJ.rst
new file mode 100644
index 0000000..d4a0a00
--- /dev/null
+++ b/doc/sphinx/props/P_AUTOLOADOBJ.rst
@@ -0,0 +1,141 @@
+P_AUTOLOADOBJ
+=============
+
+NAME
+----
+::
+
+    P_AUTOLOADOBJ                 "autoloadobj"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Hiermit kann prinzipiell angegeben werden ob ein Objekt ueber das
+     Ausloggen eines Spielers (Reboot/ende) behalten werden soll.
+
+     Als Inhalt der Property koennen permanente Eigenschaften des Objektes
+     angegeben werden.
+     Beim Einloggen wird das Objekt neu erzeugt und P_AUTOLOADOBJ auf die
+     gespeicherten Werte gesetzt. Die Werte muessen allerdings selbst
+     verwaltet werden.
+
+     Bitte geht nicht davon aus, dass es waehrend des Setzens/Abfragens dieser
+     Prop einen this_player() oder ein this_interactive() geben muss.
+     Speziell ist this_interactive() nicht == /secure/login!
+     Ebenfalls muss das Objekt beim Setzen/Abfragen nicht in einem Spieler
+     sein.
+
+BEMERKUNGEN
+-----------
+::
+
+     Autoloadobjekte werden beim Ausloggen nicht fallengelassen!
+
+BEISPIELE
+---------
+::
+
+     ## Variante 1: simples Objekt, bleibt einfach nur erhalten,
+     ##             Variablen werden nicht gesichert ##
+     void create() {
+      ...
+      SetProp(P_AUTOLOADOBJ,1);
+      ...
+     }
+
+
+     ## Variante 2: Speicherung mehrerer Variablen ueber
+     ##             P_AUTOLOADOBJ (elegante Verwaltung)
+
+     // ein paar #defines fuer die Plaetze in der Speichervariablen
+     #define MY_AL_SHORT    0
+     #define MY_AL_ATTRM    1
+     #define MY_AL_OWNER    2
+     #define MY_AL_DESTRUCT 3
+
+     // die Variablen, die erhalten bleiben sollen
+     static object owner;
+     static int destruct_time;
+
+     // diese hier wird gerufen, wenn der Spieler gespeichert wird,
+     // wir packen also alle aktuellen Variablen in eine und geben die
+     // zum Speichern heraus ... wir nehmen hier ein Array (statt
+     // zB eines Mappings), weil das am wenigsten Platz braucht
+     static mixed* _query_autoloadobj() {
+      mixed *ret;
+      ret=allocate(4);
+      ret[MY_AL_SHORT] = QueryProp(P_SHORT);      // SHORT merken
+      ret[MY_AL_ATTRM] = QueryProp(P_M_ATTR_MOD); // einen Modifikator merken
+      ret[MY_AL_OWNER] = getuid(owner);           // ah, ein Besitzer!
+      ret[MY_AL_DESTRUCT]=destruct_time-time();   // und eine Lebensdauer!
+
+      return ret;
+
+      /*
+      // normalerweise wuerde man das einfach so schreiben:
+      return (({QueryProp(P_SHORT),
+                QueryProp(P_M_ATTR_MOD),
+                getuid(owner),
+                destruct_time-time()}));
+      */
+     }
+
+     // diese hier wird gerufen, wenn das Objekt neu im Spieler
+     // erzeugt wurde (Login), also packen wir das Speicherarray wieder
+     // aus und in alle entsprechenden Variablen
+     static mixed* _set_autoloadobj(mixed *new) {
+      // wenn das Format nicht mit dem oben uebereinstimmt ist was
+      // schiefgelaufen
+      if(pointerp(new) && !owner && sizeof(new)>4 &&
+         (owner=find_player(new[MY_AL_OWNER]))) {
+       // los, zuweisen!
+
+       SetProp(P_SHORT,      new[MY_AL_SHORT]);
+       SetProp(P_M_ATTR_MOD, new[MY_AL_ATTRM]);
+       destruct_time=        time()+new[MY_AL_DESTRUCT];
+
+       call_out(#'remove,new[3]);
+      } else call_out(#'remove,0);
+
+      return new;
+     }
+
+
+     ## Variante 3: und das gleiche mit Set/Querymethoden ##
+     // Prototypen fuer Set und Query-Methoden -> man Set
+     static mixed *my_query_autoloadobj();
+     static mixed *my_set_autoloadobj(mixed *new);
+
+     void create() {
+      // Binden der Methoden
+      Set(P_AUTOLOADOBJ, #'my_query_autoloadobj, F_QUERY_METHOD);
+      Set(P_AUTOLOADOBJ, #'my_set_autoloadobj, F_SET_METHOD);
+
+      // die werden nur von mir veraendert!
+      Set(P_AUTOLOADOBJ, PROTECTED, F_MODE_AS);
+      ...
+     }
+
+     static mixed *my_query_autoloadobj () {
+       // s.o.
+     }
+
+     static mixed *my_set_autoloadobj (mixed *new) {
+       // s.o.
+     }
+
+SIEHE AUCH
+----------
+::
+
+     P_AUTOLOAD, SetProp
+
+24.Aug.2006 Gloinson@MG
+
diff --git a/doc/sphinx/props/P_AVATAR_URI.rst b/doc/sphinx/props/P_AVATAR_URI.rst
new file mode 100644
index 0000000..3657d03
--- /dev/null
+++ b/doc/sphinx/props/P_AVATAR_URI.rst
@@ -0,0 +1,44 @@
+P_AVATAR_URI
+============
+
+NAME
+----
+::
+
+    P_AVATAR_URI                    "p_lib_avataruri"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Lebewesen speichern in der Prop P_AVATAR_URI eine URI (string), welche auf
+    ein Bild im Netz verweist, welches ein Client fuer dieses Lebewesen
+    anzeigen kann.
+    Spieler koennen diese Avatar-URI mit dem Befehl 'avatar' anzeigen,
+    aendern und loeschen.
+    Avatar-URIs anderer Spieler lassen sich mit 'finger -a' ausgeben.
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Property kann nur vom Spieler oder einem EM modifiziert werden.
+
+SIEHE AUCH
+----------
+::
+
+    avatar
+
+LETZTER AENDERUNG
+-----------------
+::
+
+    03.9.2011, Zesstra
+
diff --git a/doc/sphinx/props/P_AVERAGE_SIZE.rst b/doc/sphinx/props/P_AVERAGE_SIZE.rst
new file mode 100644
index 0000000..b63f8da
--- /dev/null
+++ b/doc/sphinx/props/P_AVERAGE_SIZE.rst
@@ -0,0 +1,21 @@
+P_AVERAGE_SIZE
+==============
+
+NAME
+----
+::
+
+    P_AVERAGE_SIZE                "average_size"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Durchschnittliche Groesse eines Wesens dieser Rasse (derzeit nur Player)
+
diff --git a/doc/sphinx/props/P_AVERAGE_WEIGHT.rst b/doc/sphinx/props/P_AVERAGE_WEIGHT.rst
new file mode 100644
index 0000000..fbcddeb
--- /dev/null
+++ b/doc/sphinx/props/P_AVERAGE_WEIGHT.rst
@@ -0,0 +1,21 @@
+P_AVERAGE_WEIGHT
+================
+
+NAME
+----
+::
+
+    P_AVERAGE_WEIGHT                "average_weight"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Durchschnittliche Gewicht eines Wesens dieser Rasse (derzeit nur Player)
+
diff --git a/doc/sphinx/props/P_AWAY.rst b/doc/sphinx/props/P_AWAY.rst
new file mode 100644
index 0000000..54ea447
--- /dev/null
+++ b/doc/sphinx/props/P_AWAY.rst
@@ -0,0 +1,21 @@
+P_AWAY
+======
+
+NAME
+----
+::
+
+    P_AWAY                        "away"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     String der ausgegeben wird, wenn man weg ist und eine Mitteilung bekommt.
+
diff --git a/doc/sphinx/props/P_BAD_MSG.rst b/doc/sphinx/props/P_BAD_MSG.rst
new file mode 100644
index 0000000..26f1104
--- /dev/null
+++ b/doc/sphinx/props/P_BAD_MSG.rst
@@ -0,0 +1,53 @@
+P_BAD_MSG
+=========
+
+NAME
+----
+::
+
+     P_BAD_MSG                     "std_food_bad_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung, wenn eine Speise gerade verdirbt.
+     Befindet sich die Speise in einem Spieler, geht die Meldung an genau
+     diesen, liegt die Speise im Raum, geht die Meldung an alle anwesenden
+     Spieler.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "@WER1 verdirbt."
+
+SIEHE AUCH
+----------
+::
+
+     P_LIFETIME, P_RESET_LIFETIME, P_NO_BAD,
+     wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_BLIND.rst b/doc/sphinx/props/P_BLIND.rst
new file mode 100644
index 0000000..2592794
--- /dev/null
+++ b/doc/sphinx/props/P_BLIND.rst
@@ -0,0 +1,57 @@
+P_BLIND
+=======
+
+NAME
+----
+::
+
+    P_BLIND                       "blind"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/viewcmd.h
+
+BESCHREIBUNG
+------------
+::
+
+    1, wenn der Spieler blind ist und nichts mehr sehen kann.
+
+    Wird von CannotSee() bei 'schau' und Betreten von Raeumen 
+    u.ae. ausgewertet.
+
+    P_BLIND kann auch auf einen String gesetzt werden, der 
+    dann statt des 'Du bist blind' ausgegeben wird.
+
+BEISPIELE
+---------
+::
+
+    this_player()->SetProp(P_BLIND,1);
+
+    this_player()->SetProp(P_BLIND,"Du hast Dir vorhin so schoen die "
+                                  +"Augen ausgekratzt ... deswegen "
+                                  +"siehst Du nun nichts mehr.\n");    
+
+BEMERKUNGEN
+-----------
+::
+
+    Um herauszufinden, ob ein Spieler etwas sehen kann oder nicht,
+    sollte man lieber if(this_player()->CannotSee() != 0) pruefen
+    statt if(this_player()->QueryProp(P_BLIND)).
+
+    Denn CannotSee() beruecksichtigt auch Nachtsicht (bzw. hier 
+    eine nicht aktivierte) und die Lichtmodifikatoren.
+
+SIEHE AUCH
+----------
+::
+
+    P_LIGHT_MODIFIER, P_PLAYER_LIGHT, CannotSee
+
+
+Letzte Aenderung: Sa 02.11.02, 00:30:00 Uhr, von Tilly
+
diff --git a/doc/sphinx/props/P_BODY.rst b/doc/sphinx/props/P_BODY.rst
new file mode 100644
index 0000000..5fbb13c
--- /dev/null
+++ b/doc/sphinx/props/P_BODY.rst
@@ -0,0 +1,22 @@
+P_BODY
+======
+
+NAME
+----
+::
+
+    P_BODY                        "body"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Numerischer Wert fuer die Abwehrstaerke des blanken Koerpers
+     des Wesens.
+
diff --git a/doc/sphinx/props/P_BRIEF.rst b/doc/sphinx/props/P_BRIEF.rst
new file mode 100644
index 0000000..d50f389
--- /dev/null
+++ b/doc/sphinx/props/P_BRIEF.rst
@@ -0,0 +1,21 @@
+P_BRIEF
+=======
+
+NAME
+----
+::
+
+    P_BRIEF                       "brief"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/viewcmd.h
+
+BESCHREIBUNG
+------------
+::
+
+     Ist gesetzt, wenn der Spieler nur die Kurzbeschreibung sehen will.
+
diff --git a/doc/sphinx/props/P_BUFFER.rst b/doc/sphinx/props/P_BUFFER.rst
new file mode 100644
index 0000000..dc67f66
--- /dev/null
+++ b/doc/sphinx/props/P_BUFFER.rst
@@ -0,0 +1,21 @@
+P_BUFFER
+========
+
+NAME
+----
+::
+
+    P_BUFFER                      "buffer"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+    Zeigt an, ob der Kobold des Spielers aktiv oder nicht aktiv ist.
+
diff --git a/doc/sphinx/props/P_BUY_ONLY_PLANTS.rst b/doc/sphinx/props/P_BUY_ONLY_PLANTS.rst
new file mode 100644
index 0000000..ec9eb9f
--- /dev/null
+++ b/doc/sphinx/props/P_BUY_ONLY_PLANTS.rst
@@ -0,0 +1,31 @@
+P_BUY_ONLY_PLANTS
+=================
+
+NAME
+----
+::
+
+    P_BUY_ONLY_PLANTS              "lib_p_buy_only_plants"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property kann auf 1 gesetzt werden, wenn ein Laden nur Kraeuter
+    ankaufen darf. Hierzu muss /std/room/kraeuterladen.c geerbt werden,
+    da nur dieses Objekt die Property beruecksichtigt.
+
+SIEHE AUCH
+----------
+::
+
+    /std/room/kraeuterladen.c
+
+Last modified: 02.04.2015 Arathorn 
+
diff --git a/doc/sphinx/props/P_CALLED_FROM_IP.rst b/doc/sphinx/props/P_CALLED_FROM_IP.rst
new file mode 100644
index 0000000..bc2d7f9
--- /dev/null
+++ b/doc/sphinx/props/P_CALLED_FROM_IP.rst
@@ -0,0 +1,21 @@
+P_CALLED_FROM_IP
+================
+
+NAME
+----
+::
+
+    P_CALLED_FROM_IP              "called_from_ip"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Letzte IP-Adr, von der aus sich der Spieler eingeloggt hat.
+
diff --git a/doc/sphinx/props/P_CAN_FLAGS.rst b/doc/sphinx/props/P_CAN_FLAGS.rst
new file mode 100644
index 0000000..1a89a92
--- /dev/null
+++ b/doc/sphinx/props/P_CAN_FLAGS.rst
@@ -0,0 +1,22 @@
+P_CAN_FLAGS
+===========
+
+NAME
+----
+::
+
+    P_CAN_FLAGS                   "can_flags"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/can.h
+
+BESCHREIBUNG
+------------
+::
+
+    Flags die bestimmte Befehle freischalten:
+    CAN_EMOTE, CAN_ECHO, CAN_REMOTE, CAN_PRESAY
+
diff --git a/doc/sphinx/props/P_CAP_NAME.rst b/doc/sphinx/props/P_CAP_NAME.rst
new file mode 100644
index 0000000..88277b6
--- /dev/null
+++ b/doc/sphinx/props/P_CAP_NAME.rst
@@ -0,0 +1,22 @@
+P_CAP_NAME
+==========
+
+NAME
+----
+::
+
+    P_CAP_NAME                    "cap_name"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Name des Spielers, der dekliniert und ausgegen wird.
+     NOT YET IMPLEMENTED.
+
diff --git a/doc/sphinx/props/P_CARRIED_VALUE.rst b/doc/sphinx/props/P_CARRIED_VALUE.rst
new file mode 100644
index 0000000..493d6ab
--- /dev/null
+++ b/doc/sphinx/props/P_CARRIED_VALUE.rst
@@ -0,0 +1,21 @@
+P_CARRIED_VALUE
+===============
+
+NAME
+----
+::
+
+    P_CARRIED_VALUE               "carried"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Entschaedigung, die der Spieler beim Einloggen erhaelt.
+
diff --git a/doc/sphinx/props/P_CHATS.rst b/doc/sphinx/props/P_CHATS.rst
new file mode 100644
index 0000000..4eb9f29
--- /dev/null
+++ b/doc/sphinx/props/P_CHATS.rst
@@ -0,0 +1,21 @@
+P_CHATS
+=======
+
+NAME
+----
+::
+
+    P_CHATS                       "chats"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Alist mit Strings, die das Monster zufaellig ausgibt.
+
diff --git a/doc/sphinx/props/P_CHAT_CHANCE.rst b/doc/sphinx/props/P_CHAT_CHANCE.rst
new file mode 100644
index 0000000..237abc5
--- /dev/null
+++ b/doc/sphinx/props/P_CHAT_CHANCE.rst
@@ -0,0 +1,21 @@
+P_CHAT_CHANCE
+=============
+
+NAME
+----
+::
+
+    P_CHAT_CHANCE                 "chat_chance"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wahrscheinlichkeit, mit der die Chats ausgegeben werden.
+
diff --git a/doc/sphinx/props/P_CLASS.rst b/doc/sphinx/props/P_CLASS.rst
new file mode 100644
index 0000000..c66f6d4
--- /dev/null
+++ b/doc/sphinx/props/P_CLASS.rst
@@ -0,0 +1,34 @@
+P_CLASS
+=======
+
+NAME
+----
+::
+
+     P_CLASS						"class"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Die Klassifizierung eines Objektes, soweit sie nicht schon ueber die 
+     Rasse oder die IDs des Objektes erfolgt ist. Zum Setzen dieser Property 
+     sollte man AddClass() benutzen, zur Klassenabfrage steht 
+     is_class_member() zur Verfuegung.
+     Die moeglichen Klassen findet man in /sys/class.h
+
+SIEHE AUCH
+----------
+::
+
+     AddClass(), RemoveClass(), is_class_member()
+
+
+Last modified: Sun May 19 20:30:09 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_CLOCKMSG.rst b/doc/sphinx/props/P_CLOCKMSG.rst
new file mode 100644
index 0000000..dabf444
--- /dev/null
+++ b/doc/sphinx/props/P_CLOCKMSG.rst
@@ -0,0 +1,21 @@
+P_CLOCKMSG
+==========
+
+NAME
+----
+::
+
+    P_CLOCKMSG                    "clockmsg"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Die Meldung wird zur vollen Stunde ausgegeben
+
diff --git a/doc/sphinx/props/P_CLONER.rst b/doc/sphinx/props/P_CLONER.rst
new file mode 100644
index 0000000..c45bcde
--- /dev/null
+++ b/doc/sphinx/props/P_CLONER.rst
@@ -0,0 +1,28 @@
+P_CLONER
+========
+
+NAME
+----
+::
+
+    P_CLONER                      "cloner"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Enthaelt einen String mit dem Namen desjenigen, der das Objekt gecloned 
+     hat.
+
+SIEHE AUCH
+----------
+::
+
+     P_CLONE_TIME
+
diff --git a/doc/sphinx/props/P_CLONE_MSG.rst b/doc/sphinx/props/P_CLONE_MSG.rst
new file mode 100644
index 0000000..991d2dd
--- /dev/null
+++ b/doc/sphinx/props/P_CLONE_MSG.rst
@@ -0,0 +1,21 @@
+P_CLONE_MSG
+===========
+
+NAME
+----
+::
+
+    P_CLONE_MSG                   "clone_msg"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung, die beim Clonen eines Obj ausgegegen wird (nur Magier)
+
diff --git a/doc/sphinx/props/P_CLONE_TIME.rst b/doc/sphinx/props/P_CLONE_TIME.rst
new file mode 100644
index 0000000..a0f613c
--- /dev/null
+++ b/doc/sphinx/props/P_CLONE_TIME.rst
@@ -0,0 +1,30 @@
+P_CLONE_TIME
+============
+
+NAME
+----
+::
+
+    P_CLONE_TIME                   "clone_time"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Enthaelt die Clone-Time eines Objektes.
+     Heutzutage obsolet, bitte stattdessen lieber die Efun object_time()
+     benutzen.
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt: object_time(E)
+     Aehnlich: program_time(E)
+
diff --git a/doc/sphinx/props/P_CLOTHING.rst b/doc/sphinx/props/P_CLOTHING.rst
new file mode 100644
index 0000000..fc3642e
--- /dev/null
+++ b/doc/sphinx/props/P_CLOTHING.rst
@@ -0,0 +1,44 @@
+P_CLOTHING
+==========
+
+P_CLOTHINGS
+-----------
+::
+
+NAME
+----
+::
+
+     P_CLOTHING                     "std:clothing"
+
+DEFINIERT IN
+------------
+::
+
+     <living/clothing.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Array mit der getragenen nicht-schuetzenden Kleidung des Lebewesen.
+
+     
+
+     Falls ihr die Kleidung des Lebewesens, ggf. mit bestimten Kriterien,
+     ermitteln wollt, benutzt hierfuer bitte die Funktion FilterClothing()
+     statt selber ueber dieses Array zu laufen.
+
+     Diese Property kann nur vom Lebewesen selber beschrieben werden.
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt:		QueryArmourByType(L), FilterClothing(), FilterArmours()
+                  Wear(), Unwear(), P_ARMOURS
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_CMSG.rst b/doc/sphinx/props/P_CMSG.rst
new file mode 100644
index 0000000..90a7819
--- /dev/null
+++ b/doc/sphinx/props/P_CMSG.rst
@@ -0,0 +1,21 @@
+P_CMSG
+======
+
+NAME
+----
+::
+
+    P_CMSG                        "clonemsg"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     *** OBSOLET! *** Siehe P_CLONE_MSG
+
diff --git a/doc/sphinx/props/P_CNT_STATUS.rst b/doc/sphinx/props/P_CNT_STATUS.rst
new file mode 100644
index 0000000..b988681
--- /dev/null
+++ b/doc/sphinx/props/P_CNT_STATUS.rst
@@ -0,0 +1,22 @@
+P_CNT_STATUS
+============
+
+NAME
+----
+::
+
+    P_CNT_STATUS                  "cnt_status"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container.h
+
+BESCHREIBUNG
+------------
+::
+
+     Status des Containers (offen, geschlossen, abgeschlossen)
+     siehe auch /sys/container.h
+
diff --git a/doc/sphinx/props/P_COMBATCMDS.rst b/doc/sphinx/props/P_COMBATCMDS.rst
new file mode 100644
index 0000000..075d8c4
--- /dev/null
+++ b/doc/sphinx/props/P_COMBATCMDS.rst
@@ -0,0 +1,44 @@
+P_COMBATCMDS
+============
+
+NAME
+----
+::
+
+    P_COMBATCMDS                  "combatcmds"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Fuer den Kampf gebrauchbare Befehle spezieller Objekte (damit auch
+     Monster sie automatisch richtig anwenden koennen)
+     Der Inhalt von P_COMBATCMDS ist ein Mapping, der Key ist das Kommando,
+     um den Gegenstand zu benutzen (also z.B. "wirf flammenkugel"), und der
+     Value ein weiteres Mapping mit Zusatzinfos (definiert in /sys/combat.h).
+     Folgende Keys sind definiert:
+     - C_MIN, C_AVG, C_MAX:
+       minimaler, mittlerer und maximaler Schaden, den das
+       Objekt macht. Alle Angaben in LEBENSPUNKTEN, d.h. Defend-Einheiten/10.
+       Bei einem Aufruf wie 'enemy->Defend(200+random(200), ...)' ist dann
+       C_MIN=20, C_AVG=30, C_MAX=40.
+     - C_DTYPES:
+       Array mit dem Schadenstyp oder den Schadenstypen. Beim Eisstab
+       wuerde der Eintrag dann 'C_DTYPES:({DT_COLD})' lauten.
+     - C_HEAL:
+       Sollte das Kampfobjekt ueber die Moeglichkeit verfuegen, den Anwender
+       irgendwie zu heilen, so wird hier die Heilung in LP/MP eingetragen.
+       Das funktioniert auch bei Objekten, die nur heilen, also sonst
+       nichts mit Kampf zu tun haben.
+       Im Lupinental z.B. gibt es Pfirsiche, die beim Essen 5LP heilen. Da
+       kann man dann 'SetProp(P_COMBATCMDS, (["iss pfirsich":([C_HEAL:5])]))'
+       eintragen.
+     Es sind auch mehrere Kommandos moeglich, z.B. bei Objekten, die sowohl
+     heilen als auch Kampfwirkung haben.
+
diff --git a/doc/sphinx/props/P_COMMANDS.rst b/doc/sphinx/props/P_COMMANDS.rst
new file mode 100644
index 0000000..bc0cb85
--- /dev/null
+++ b/doc/sphinx/props/P_COMMANDS.rst
@@ -0,0 +1,76 @@
+P_COMMANDS
+==========
+
+NAME
+----
+::
+
+     P_COMMANDS "commands"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/commands.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt ein Mapping mit den Befehlen, die dem Objekt
+     zugeordnet sind.
+
+     Sie sollte nicht von Hand manipuliert werden, sondern nur ueber die
+     Funktionen AddCmd() und RemoveCmd().
+
+     Das Mapping hat folgenden Aufbau:
+
+     ([ befehl : ({funktion1,...});
+                 ({flag1,...});
+                 ({regel1,...});
+                 ({id1, ...}),
+                 ({closure auf fun1, ...}),
+        ... ])
+
+     Die Eintraege entsprechen den Parametern des AddCmd()-Aufrufs, sind
+     aber in anderer Form. Als Beispiel:
+
+     AddCmd(verb,fun1,1);
+     AddCmd(verb+syn1a|syn1b&syn2a|syn2b|syn2c, fun2,
+            error1_notify|error2_notify^error2_write);
+     -->
+     ([verb:
+        ({fun1,fun2});                                        // funs
+        ({1,({error1_notify, error2_write^error2_say, 1})});  // flags
+        ({0,({({syn1a,syn1b}),({syn2a,syn2b,syn2c})})});      // rules
+        0;                                                    // IDs
+        ({closure auf fun1, closure auf fun2}) ])             // Cache
+
+     Funs:  ({<fun1> ,...
+              'fun' kann sein: Closure
+                               String: Methodenname - wird etwas geprueft
+                               Objekt: wenn keine Methode, this_object() fuer
+                                       intern, previous_object() fuer extern
+                               0 (erloschenes externes Objekt)
+     Rules: ({<Regelsatz fuer fun1>, ({<1. Synonymgruppe>,
+                                       <2. Synonymgruppe, ...}), ...})
+     Flags: ({<Flag fuer fun1>, ({<Fehlermeldung 1. Synonymgruppe>, ... ,
+                                  [, Index fuer write anstatt notify_fail]}),
+             ... })
+     IDs:   0 oder ({<ID fuer fun1>}) oder ({0, <ID fuer fun2>}) ...
+     Cache: ({<closure fuer fun1>, ...
+
+BEMERKUNGEN
+-----------
+::
+
+     Cache-Closures sind bei Export immer genullt
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/commands.c, AddCmd(), RemoveCmd()
+
+16. Dez 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_COMPILER_PATH.rst b/doc/sphinx/props/P_COMPILER_PATH.rst
new file mode 100644
index 0000000..1462e46
--- /dev/null
+++ b/doc/sphinx/props/P_COMPILER_PATH.rst
@@ -0,0 +1,40 @@
+P_COMPILER_PATH
+===============
+
+NAME
+----
+::
+
+    P_COMPILER_PATH               "compiler_path"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/v_compiler.h
+
+BESCHREIBUNG
+------------
+::
+
+    Directory in dem ein Virtual Compiler Objekte erzeugt.
+    Muss im virtual_compiler.c gesetzt werden.
+
+    Der VirtualCompiler muss nicht zwingend in diesem Verzeichnis
+    liegen, um zu funktionieren, sollte es aber, um die Zuordnung des VCs zu
+    "seinen" Objekten zu erleichern.
+
+BEISPIEL
+--------
+::
+
+    SetProp(P_COMPILER_PATH,"/d/region/magier/vc/");
+
+SIEHE AUCH
+----------
+::
+
+    P_STD_OBJECT, virtual_compiler
+
+Letzte Aenderung: 23.10.2007, von Zesstra
+
diff --git a/doc/sphinx/props/P_CONSUME_MSG.rst b/doc/sphinx/props/P_CONSUME_MSG.rst
new file mode 100644
index 0000000..a176e52
--- /dev/null
+++ b/doc/sphinx/props/P_CONSUME_MSG.rst
@@ -0,0 +1,50 @@
+P_CONSUME_MSG
+=============
+
+NAME
+----
+::
+
+     P_CONSUME_MSG                 "std_food_consume_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Raum exklusive Konsument, wenn eine Speise konsumiert
+     wird.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "@WER2 konsumiert @WEN1."
+
+SIEHE AUCH
+----------
+::
+
+     /std/food.c, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_CONTAINER.rst b/doc/sphinx/props/P_CONTAINER.rst
new file mode 100644
index 0000000..fa1d49d
--- /dev/null
+++ b/doc/sphinx/props/P_CONTAINER.rst
@@ -0,0 +1,21 @@
+P_CONTAINER
+===========
+
+NAME
+----
+::
+
+    P_CONTAINER                   "container"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_CONTENTS.rst b/doc/sphinx/props/P_CONTENTS.rst
new file mode 100644
index 0000000..7c579dc
--- /dev/null
+++ b/doc/sphinx/props/P_CONTENTS.rst
@@ -0,0 +1,21 @@
+P_CONTENTS
+==========
+
+NAME
+----
+::
+
+    P_CONTENTS                    "contents"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container.h
+
+BESCHREIBUNG
+------------
+::
+
+     *** OBSOLET! ***
+
diff --git a/doc/sphinx/props/P_CORPSE.rst b/doc/sphinx/props/P_CORPSE.rst
new file mode 100644
index 0000000..7cbbb89
--- /dev/null
+++ b/doc/sphinx/props/P_CORPSE.rst
@@ -0,0 +1,44 @@
+P_CORPSE
+========
+
+NAME
+----
+::
+
+    P_CORPSE		"corpse"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Hier kann man angeben, welche Art von Leiche beim Tod des NPCs
+    hinterlassen wird. Damit die Leiche auf dem Moerder-Kanal senden
+    kann, muss das Leichen-Objekt /std/corpse sein oder erben.
+
+BEISPIELE
+---------
+::
+
+    Die uebliche Standardleiche befindet sich unter "/std/corpse.c",
+    welches auch die Defaulteinstellung fuer diese Property darstellt:
+      SetProp(P_CORPSE,"/std/corpse");
+    Man koennte aber auch einen Zombie entstehen lassen:
+      SetProp(P_CORPSE,PATH("zombie"));
+    PATH kennzeichnet hierbei den Pfad, unter welchem "zombie.c" zu
+    finden ist.
+
+SIEHE AUCH
+----------
+::
+
+    P_NOCORPSE, P_ZAP_MSG, P_DIE_MSG, P_MURDER_MSG, P_KILL_MSG
+
+
+Last modified: Mon Apr 07 11:02:06 2003 by Mandragon
+
diff --git a/doc/sphinx/props/P_CURRENTDIR.rst b/doc/sphinx/props/P_CURRENTDIR.rst
new file mode 100644
index 0000000..3cf7421
--- /dev/null
+++ b/doc/sphinx/props/P_CURRENTDIR.rst
@@ -0,0 +1,28 @@
+P_CURRENTDIR
+============
+
+NAME
+----
+::
+
+    P_CURRENTDIR                  "currentdir"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/shells.h
+
+BESCHREIBUNG
+------------
+::
+
+    Momentanes Verzeichnis in dem der Magier ist.
+    (nur fuer Magier von Belang)
+
+Siehe auch:
+    P_CURRENTDIR
+
+Letzte Aenderung:
+    03.06.2015, Bugfix
+
diff --git a/doc/sphinx/props/P_CURSED.rst b/doc/sphinx/props/P_CURSED.rst
new file mode 100644
index 0000000..fb293f7
--- /dev/null
+++ b/doc/sphinx/props/P_CURSED.rst
@@ -0,0 +1,56 @@
+P_CURSED
+========
+
+NAME
+----
+::
+
+     P_CURSED "cursed"
+
+DEFINIERT IN
+------------
+::
+
+     <properties.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Ruestungen und Waffen, die sich, einmal angezogen bzw. gezueckt, nicht
+     wieder entfernen lassen sollen, kann man ueber diese Property
+     realisieren. Die Waffe oder Ruestung hat dann in der Regel negative
+     Auswirkungen auf den Traeger...
+
+     Setzt man diese Property auf eine Zahl ungleich 0, so bekommt man bei
+     dem Versuch, den verfluchten Gegenstand auszuziehen bzw. wegzustecken
+     eine Defaultmeldung.
+
+     Traegt man dagegen einen String ein, so wird dieser beim Versuch, den
+     Gegenstand loszuwerden, ausgegeben.
+
+BEMERKUNGEN
+-----------
+::
+
+     Der 'Fluch' wird erst wirksam, wenn das Opfer die Waffe zueckt bzw. die
+     Ruestung anzieht. Ist dies erst einmal geschehen, helfen nur noch
+     Zaubersprueche oder fluchbrechende Institutionen.
+
+     Moechte man, dass der Gegenstand entfluchbar ist, dann sollte er auch
+     ansprechbar sein (gueltige ID, nicht unsichtbar), da das durch derzeitige
+     Entfluchmoeglichkeiten vorausgesetzt wird.
+
+     Flueche koennen ein P_LEVEL 1-100 haben, welches die Schwierigkeit des
+     Enfluchens festlegt. Der Klerus behandelt das nicht linear.
+
+SIEHE AUCH
+----------
+::
+
+     Eigenschaften: P_LEVEL
+     Aehnlich:      AddClass (CL_CURSE)
+     Code:         /std/armour, /std/weapon, /gilden/files.klerus/prayermaster
+
+25. Aug 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_DAMAGED.rst b/doc/sphinx/props/P_DAMAGED.rst
new file mode 100644
index 0000000..b965dd6
--- /dev/null
+++ b/doc/sphinx/props/P_DAMAGED.rst
@@ -0,0 +1,42 @@
+P_DAMAGED
+=========
+
+NAME
+----
+::
+
+     P_DAMAGED "item_damaged"
+
+DEFINIERT IN
+------------
+::
+
+     <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Ruestungen und Waffen koennen im Eifer des Gefechts beschaedigt werden.
+     Der Grad der Beschaedigung sollte in dieser Property festgehalten
+     werden.
+
+     Bei Waffen ergibt sich die urspruengliche Waffenklasse aus der Summe
+     von aktueller Waffenklasse und dem Wert von P_DAMAGED:
+     altes P_WC = aktuelles P_WC + P_DAMAGED.
+
+     Analoges gilt fuer die Ruestungsklasse einer beschaedigten Ruestung:
+     altes P_AC = aktuelles P_AC + P_DAMAGED.
+
+     P_DAMAGED bitte niemals direkt setzen, sondern immer ueber
+     die Funktion Damage() manipulieren!
+
+SIEHE AUCH
+----------
+::
+
+     /std/armour.c, /std/weapon.c, TakeFlaw(), QueryFlaw(), Damage()
+
+
+02.10.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_DAMAGE_MSG.rst b/doc/sphinx/props/P_DAMAGE_MSG.rst
new file mode 100644
index 0000000..0a1834a
--- /dev/null
+++ b/doc/sphinx/props/P_DAMAGE_MSG.rst
@@ -0,0 +1,58 @@
+P_DAMAGE_MSG
+============
+
+NAME
+----
+::
+
+     P_DAMAGE_MSG      "std_p_dam_msg"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property lassen sich individuelle Treffer-/Schadensmeldungen
+     fuer dieses Lebewesen festlegen. Sie werden verwendet, falls bei
+     eingehendem Schaden der Aufrufer von Defend() Schadensmeldungen wuenscht
+     (d.h. SP_SHOW_DAMAGE != 0), jedoch keine eigenen Meldungen vorgibt.
+
+     Enthaelt diese Property kein Array, werden ggf. die Standardmeldungen
+     ausgegeben.
+
+     Datenstruktur der Property:
+       ({
+        ({ int lphit1, string mess_me,
+                       string mess_en,
+                       string mess_room }),
+        ({ lphit2, mess_me, mess_en, mess_room }),
+        ...
+        ({ lphitn, mess_me, mess_en, mess_room }),
+       })
+       wobei lphit1<lphit2<...<lphitn sein muss, d.h. das Array-
+       Array ist aufsteigend sortiert.
+
+     Ist ein Treffer x LP hart, werden die Meldungen des lphit-
+     Arrays ausgegeben, dessen Wert am naechsten unter dem Schaden
+     liegt.
+
+     In den Meldungen mess_me (an den Getroffenen), mess_en (an
+     den Feind), mess_room (an die restlichen Umstehenden) koennen
+     Ersatzstrings wie folgt verwendet werden:
+     @WER1/@WESSEN1/@WEM1/@WEN1 - name(casus) des Getroffenen (TO)
+     @WER2/@WESSEN2/@WEM2/@WEN2 - name(casus) des Feindes (enemy)
+
+SIEHE AUCH
+----------
+::
+
+     Defend()
+     /std/living/combat.c
+
+15.09.2010, Zesstra
+
diff --git a/doc/sphinx/props/P_DAM_DESC.rst b/doc/sphinx/props/P_DAM_DESC.rst
new file mode 100644
index 0000000..093e2f5
--- /dev/null
+++ b/doc/sphinx/props/P_DAM_DESC.rst
@@ -0,0 +1,57 @@
+P_DAM_DESC
+==========
+
+NAME
+----
+::
+
+     P_DAM_DESC "dam_desc"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property befindet sich ein String oder String-Array, durch 
+     den die Langbeschreibung einer Ruestung oder Waffe ergaenzt wird,
+     wenn diese Beschaedigt ist.
+
+BEMERKUNGEN
+-----------
+::
+
+     Wird ein String gesetzt, so wird dieser angezeigt, wenn die Waffe
+     mehr als die Haelfte beschaedigt ist. Bei einem Array wird der
+     Text entsprechend dem Grad der Beschaedigung ausgewaehlt; das Array
+     muss in der Reihenfolge zunehmender Beschaedigung sortiert sein.
+
+     
+
+     Bei Waffen ist P_DAM_DESC defaultmaessig auf DFLT_DAM_DESC gesetzt,
+     bei Ruestungen auf 0.
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_DAM_DESC,"ist beschaedigt");
+     SetProp(P_DAM_DESC,({
+         "ist etwas beschaedigt",
+         "ist beschaedigt",
+         "ist beschaedigt",
+         "ist sehr beschaedigt"}) );
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon/description.c
+
+
+Last modified: Mon Oct 14 15:29:00 1996 by Paracelsus
+
diff --git a/doc/sphinx/props/P_DAM_TYPE.rst b/doc/sphinx/props/P_DAM_TYPE.rst
new file mode 100644
index 0000000..3c634f3
--- /dev/null
+++ b/doc/sphinx/props/P_DAM_TYPE.rst
@@ -0,0 +1,36 @@
+P_DAM_TYPE
+==========
+
+NAME
+----
+::
+
+     P_DAM_TYPE "dam_type"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Was fuer eine Art von Schaden richtet die Waffe an? Hier kann man einen
+     String oder ein Array von Strings angeben, je nachdem, welche Effekte
+     die Waffe ausloesen kann. Man sollte hier nur die in <combat.h>
+     definierten Schadenstypen verwenden.
+
+     Fragt man diese Property ab, bekommt man uebrigens immer ein Array von
+     Strings zurueck.
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon.c
+
+
+Last modified: Sun May 19 15:23:43 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_DEADS.rst b/doc/sphinx/props/P_DEADS.rst
new file mode 100644
index 0000000..44075ae
--- /dev/null
+++ b/doc/sphinx/props/P_DEADS.rst
@@ -0,0 +1,22 @@
+P_DEADS
+=======
+
+NAME
+----
+::
+
+    P_DEADS                       "deads"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der Tode des Spielers seit Einfuehrung dieser Property (irgendwann
+     im Dezember 94)
+
diff --git a/doc/sphinx/props/P_DEAF.rst b/doc/sphinx/props/P_DEAF.rst
new file mode 100644
index 0000000..59128c5
--- /dev/null
+++ b/doc/sphinx/props/P_DEAF.rst
@@ -0,0 +1,23 @@
+P_DEAF
+======
+
+NAME
+----
+::
+
+    P_DEAF                        "deaf"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+     Der Spieler ist taub. Falls hier ein String steht, wird dieser bei
+     "teile ... mit" an den Mitteilenden ausgegeben, ansonsten kommt nur
+     "Soundso ist leider gerade taub.\n"
+
diff --git a/doc/sphinx/props/P_DEATH_MSG.rst b/doc/sphinx/props/P_DEATH_MSG.rst
new file mode 100644
index 0000000..82632e9
--- /dev/null
+++ b/doc/sphinx/props/P_DEATH_MSG.rst
@@ -0,0 +1,79 @@
+P_DEATH_MSG
+===========
+
+DEFINIERT IN
+------------
+::
+
+        /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+        In dieser Property kann man ein Array ablegen, das beim Tod eines
+        Spielers ausgewertet und der darin enthaltene String
+        anschliessend auf dem Todeskanal gesendet wird.
+        Der Array muss folgenden Aufbau haben:
+
+          SetProp( P_DEATH_MSG, ({ Text, Flag }) )
+
+          
+
+        Text: Der Text kann beliebig eingegeben werde. Allerdings darf 
+              er nicht mit einem '\n' abgeschlossen werden.
+
+        
+
+        Flag: Hier kann man drei Arten von Sendemethoden waehlen.
+              1. MSG_SAY      Normales Senden
+              2. MSG_GEMOTE   Genitiv-Emote
+              3. MSG_EMOTE    Emote
+
+BEISPIEL
+--------
+::
+
+        Der Spieler soll direkt nach seinem Tod eine Meldung auf dem 
+        Todeskanal senden.
+
+        
+
+        Nachricht auf dem Todes-Kanal:
+
+	
+
+        [Tod:Spieler] Ich will keine Beleidsbekundungen!
+
+        
+
+        void spieler_stirbt()
+	{
+         this_player()->SetProp( P_DEATH_MSG, ({ "Ich will keine "
+                                        "Beleidsbekundungen!", MSG_SAY}) );
+         this_player()->die();
+        }
+
+        
+
+        Nachricht auf dem Todes-Kanal:
+
+	
+
+        [Tod:Spieler liebt es zu sterben.]
+
+        
+
+        void spieler_stirbt()
+        {
+         this_player()->SetProp( P_DEATH_MSG, ({ "liebt es zu sterben.",
+                                                 MSG_EMOTE }) );
+         this_player()->die();
+        }
+
+SIEHE AUCH
+----------
+::
+
+        P_MURDER_MSG, P_FORCE_MURDER_MSG
+
diff --git a/doc/sphinx/props/P_DEATH_SPONSORED_BY.rst b/doc/sphinx/props/P_DEATH_SPONSORED_BY.rst
new file mode 100644
index 0000000..33e40b3
--- /dev/null
+++ b/doc/sphinx/props/P_DEATH_SPONSORED_BY.rst
@@ -0,0 +1,44 @@
+P_DEATH_SPONSORED_BY
+====================
+
+NAME
+----
+::
+
+    P_DEATH_SPONSORED_BY          "responsible_wizard_for_death"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property hat fuer den Spielverlauf keinerlei Bedeutung.
+    Doch gibt es Magier, die ihren Namen gern in /log/KILLS lesen.
+    Wird ein Spieler durch einen Npc getoetet, ist normalerweise der
+    Magier fuer den Tod verantwortlich, in dessen Verzeichnis sich 
+    das Monster befindet. 
+    Doch gibt es nun auch den Fall, dass sich das Monster in einem 
+    Verzeichnis /alle/mon/ befindet, oder der Spieler durch eine
+    Aktion im Raum oder an einem Objekt stirbt.
+
+    Ist in einem solchen Monster, Raum oder Objekt diese Property
+    gesetzt, wird der dort angebene String an das Log-File ueber-
+    geben.
+
+BEISPIEL
+--------
+::
+
+    SetProp(P_DEATH_SPONSORED_BY,"tilly");
+
+ 
+
+Last modified Don Feb 15 140100 2001 von Tilly
+----------------------------------------------
+::
+
diff --git a/doc/sphinx/props/P_DEFAULT_GUILD.rst b/doc/sphinx/props/P_DEFAULT_GUILD.rst
new file mode 100644
index 0000000..d0ad46a
--- /dev/null
+++ b/doc/sphinx/props/P_DEFAULT_GUILD.rst
@@ -0,0 +1,44 @@
+P_DEFAULT_GUILD
+===============
+
+NAME
+----
+::
+
+	P_DEFAULT_GUILD			"default_guild"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt den Namen der Gilde, welcher der Spieler
+	standardmaessig angehoert. Der Name wird hierbei in Form eines
+	kleingeschriebenen Strings angegeben. Ist P_GUILD gleich Null, so
+	wird bei der Abfrage selbiger Property hierfuer der Eintrag von
+	P_DEFAULT_GUILD eingesetzt.
+
+BEMERKUNGEN
+-----------
+::
+
+	Nach dem ersten Einloggen des Spielers wird ebenfalls dieser Eintrag
+	genutzt, um die Gildenzugehoerigkeit festzulegen. Dies kann dazu
+	genutzt werden, um eine rassenabhaengige Bestimmung der
+	Standardgilde zu gewaehrleisten
+	 (Felinen -> Katzenkrieger, andere Rassen -> Abenteurer).
+
+SIEHE AUCH
+----------
+::
+
+	P_GUILD, P_VISIBLE_GUILD
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_DEFAULT_NOTIFY_FAIL.rst b/doc/sphinx/props/P_DEFAULT_NOTIFY_FAIL.rst
new file mode 100644
index 0000000..d00f304
--- /dev/null
+++ b/doc/sphinx/props/P_DEFAULT_NOTIFY_FAIL.rst
@@ -0,0 +1,21 @@
+P_DEFAULT_NOTIFY_FAIL
+=====================
+
+NAME
+----
+::
+
+    P_DEFAULT_NOTIFY_FAIL         "default_notify_fail"         
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Welche Fehlermeldung kommt, wenn kein Objekt ein notify_fail macht?
+
diff --git a/doc/sphinx/props/P_DEFENDERS.rst b/doc/sphinx/props/P_DEFENDERS.rst
new file mode 100644
index 0000000..bc83fe5
--- /dev/null
+++ b/doc/sphinx/props/P_DEFENDERS.rst
@@ -0,0 +1,46 @@
+P_DEFENDERS
+===========
+
+NAME
+----
+::
+
+	P_DEFENDERS			"defenders"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property wird in Lebewesen gesetzt, welche zum Beispiel durch
+	andere Lebewesen verteidigt werden. Die Verteidiger muessen
+	natuerlich bekannt sein, damit sie per InformDefend() ueber Angriffe
+	informiert werden und per DefendOther() in den laufenden Angriff
+	eingreifen koennen (zum Beispiel Schaeden abwehren oder umwandeln).
+	Es muessen jedoch nicht unbedingt Lebewesen oder echte Verteidiger
+	sein, auch beliebige Objekte koennen ueber Angriffe informiert
+	werden und in diese eingreifen. Allerdings besteht die
+	Einschraenkung, dass diese Objekte in der gleichen Umgebung sein
+	muessen, wie das zu verteidigende Lebewesen oder im zu verteidigenden
+	Lebewesen selbst.
+	Die Objekte, welche dies betrifft, sind in Form eines Arrays in
+	der Property P_DEFENDERS abgelegt.
+	Gesetzt und geloescht werden sollten die Eintraege dieses Arrays
+	jedoch nur mittels der dafuer bereitgestellten Funktionen
+	AddDefender() und RemoveDefender().
+
+SIEHE AUCH
+----------
+::
+
+	AddDefender(), RemoveDefender(), InformDefend(), DefendOther(),
+	/std/living/combat.c
+
+
+Last modified: 21.09.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_DEFEND_FUNC.rst b/doc/sphinx/props/P_DEFEND_FUNC.rst
new file mode 100644
index 0000000..9e370c9
--- /dev/null
+++ b/doc/sphinx/props/P_DEFEND_FUNC.rst
@@ -0,0 +1,51 @@
+P_DEFEND_FUNC
+=============
+
+NAME
+----
+::
+
+     P_DEFEND_FUNC "defend_func"
+
+DEFINIERT IN
+------------
+::
+
+     <armour.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Falls ein Objekt eine DefendFunc() fuer die Ruestung definiert, so muss
+     dieses Objekt in dieser Property eingetragen sein.
+
+     Die Auswertung dieser Property erfolgt in QueryDefend().
+
+BEMERKUNGEN
+-----------
+::
+
+     1. Es funktioniert _nicht_ hier eine Closure reinzuschreiben.
+     2. Diese Prop laesst sich _nicht_ sinnvoll mit Set() setzen, also z.B.
+        keine Query-Methoden hier reinzuschreiben.
+     3. Definieren von _set_defend_func() oder Set-Methoden via Set()
+        funktioniert auch nicht, zumindest nicht mit dem gewuenschten
+        Ergebnis. ;-)
+     4. Bei Verwendung bitte Balance-Richtlinien beachten!
+
+BEISPIELE
+---------
+::
+
+     Siehe das Beispiel zu DefendFunc()
+
+SIEHE AUCH
+----------
+::
+
+     /std/armour.c, DefendFunc(), balance, grenzwerte
+
+
+Last modified: Sat May 18 15:26:17 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_DEFUEL_AMOUNT_DRINK.rst b/doc/sphinx/props/P_DEFUEL_AMOUNT_DRINK.rst
new file mode 100644
index 0000000..7e6db27
--- /dev/null
+++ b/doc/sphinx/props/P_DEFUEL_AMOUNT_DRINK.rst
@@ -0,0 +1,38 @@
+P_DEFUEL_AMOUNT_DRINK
+=====================
+
+NAME
+----
+::
+
+    P_DEFUEL_AMOUNT_DRINK                          "defuel_amount_drink"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/defuel.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die rassenabhaengige Enttankvorgabe fuer Trinken.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+                P_DEFUEL_LIMIT_FOOD, P_DEFUEL_LIMIT_DRINK,
+                P_DEFUEL_AMOUNT_FOOD
+     Methoden:  defuel_drink, defuel_food
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Weitere:   P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_DEFUEL_AMOUNT_FOOD.rst b/doc/sphinx/props/P_DEFUEL_AMOUNT_FOOD.rst
new file mode 100644
index 0000000..27ca45e
--- /dev/null
+++ b/doc/sphinx/props/P_DEFUEL_AMOUNT_FOOD.rst
@@ -0,0 +1,38 @@
+P_DEFUEL_AMOUNT_FOOD
+====================
+
+NAME
+----
+::
+
+    P_DEFUEL_AMOUNT_FOOD                          "defuel_amount_food"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/defuel.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die rassenabhaengige Enttankvorgabe fuer Essen.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+                P_DEFUEL_LIMIT_FOOD, P_DEFUEL_LIMIT_DRINK,
+                P_DEFUEL_AMOUNT_DRINK
+     Methoden:  defuel_drink, defuel_food
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Weitere:   P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_DEFUEL_LIMIT_DRINK.rst b/doc/sphinx/props/P_DEFUEL_LIMIT_DRINK.rst
new file mode 100644
index 0000000..e623554
--- /dev/null
+++ b/doc/sphinx/props/P_DEFUEL_LIMIT_DRINK.rst
@@ -0,0 +1,39 @@
+P_DEFUEL_LIMIT_DRINK
+====================
+
+NAME
+----
+::
+
+    P_DEFUEL_LIMIT_DRINK                          "defuel_limit_drink"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/defuel.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die rassenabhaengige minimale Menge an Trinken, ab dem ein
+    Enttankvorgang fuer den Spieler moeglich ist.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+                P_DEFUEL_LIMIT_FOOD,
+                P_DEFUEL_AMOUNT_FOOD, P_DEFUEL_AMOUNT_DRINK
+     Methoden:  defuel_drink, defuel_food
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Weitere:   P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_DEFUEL_LIMIT_FOOD.rst b/doc/sphinx/props/P_DEFUEL_LIMIT_FOOD.rst
new file mode 100644
index 0000000..ebe9dcd
--- /dev/null
+++ b/doc/sphinx/props/P_DEFUEL_LIMIT_FOOD.rst
@@ -0,0 +1,39 @@
+P_DEFUEL_LIMIT_FOOD
+===================
+
+NAME
+----
+::
+
+    P_DEFUEL_LIMIT_FOOD                          "defuel_limit_food"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/defuel.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die rassenabhaengige minimale Menge an Essen, ab dem ein
+    Enttankvorgang fuer den Spieler moeglich ist.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+                P_DEFUEL_LIMIT_DRINK,
+                P_DEFUEL_AMOUNT_FOOD, P_DEFUEL_AMOUNT_DRINK
+     Methoden:  defuel_drink, defuel_food
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Weitere:   P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_DEFUEL_TIME_DRINK.rst b/doc/sphinx/props/P_DEFUEL_TIME_DRINK.rst
new file mode 100644
index 0000000..236486a
--- /dev/null
+++ b/doc/sphinx/props/P_DEFUEL_TIME_DRINK.rst
@@ -0,0 +1,39 @@
+P_DEFUEL_TIME_DRINK
+===================
+
+NAME
+----
+::
+
+    P_DEFUEL_TIME_DRINK                          "defuel_time_drink"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/defuel.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die rassenabhaengige minimale Zeit zwischen einzelnen
+    Enttankvorgaengen fuer Trinken eines Spielers.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  P_DEFUEL_TIME_FOOD,
+                P_DEFUEL_LIMIT_FOOD, P_DEFUEL_LIMIT_DRINK,
+                P_DEFUEL_AMOUNT_FOOD, P_DEFUEL_AMOUNT_DRINK
+     Methoden:  defuel_drink, defuel_food
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Weitere:   P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_DEFUEL_TIME_FOOD.rst b/doc/sphinx/props/P_DEFUEL_TIME_FOOD.rst
new file mode 100644
index 0000000..b77673f
--- /dev/null
+++ b/doc/sphinx/props/P_DEFUEL_TIME_FOOD.rst
@@ -0,0 +1,39 @@
+P_DEFUEL_TIME_FOOD
+==================
+
+NAME
+----
+::
+
+    P_DEFUEL_TIME_FOOD                          "defuel_time_food"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/defuel.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die rassenabhaengige minimale Zeit zwischen einzelnen
+    Enttankvorgaengen fuer Essen eines Spielers.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  P_DEFUEL_TIME_DRINK,
+                P_DEFUEL_LIMIT_FOOD, P_DEFUEL_LIMIT_DRINK,
+                P_DEFUEL_AMOUNT_FOOD, P_DEFUEL_AMOUNT_DRINK
+     Methoden:  defuel_drink, defuel_food
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Weitere:   P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_DEPARTMSG.rst b/doc/sphinx/props/P_DEPARTMSG.rst
new file mode 100644
index 0000000..0913c76
--- /dev/null
+++ b/doc/sphinx/props/P_DEPARTMSG.rst
@@ -0,0 +1,21 @@
+P_DEPARTMSG
+===========
+
+NAME
+----
+::
+
+    P_DEPARTMSG                   "departmsg"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung, mit der ein Transporter ablegt.
+
diff --git a/doc/sphinx/props/P_DESCRIPTION.rst b/doc/sphinx/props/P_DESCRIPTION.rst
new file mode 100644
index 0000000..4066b81
--- /dev/null
+++ b/doc/sphinx/props/P_DESCRIPTION.rst
@@ -0,0 +1,21 @@
+P_DESCRIPTION
+=============
+
+NAME
+----
+::
+
+    P_DESCRIPTION                 "description"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Beschreibung des Spielers
+
diff --git a/doc/sphinx/props/P_DESTROY_BAD.rst b/doc/sphinx/props/P_DESTROY_BAD.rst
new file mode 100644
index 0000000..bc26127
--- /dev/null
+++ b/doc/sphinx/props/P_DESTROY_BAD.rst
@@ -0,0 +1,57 @@
+P_DESTROY_BAD
+=============
+
+NAME
+----
+::
+
+     P_DESTROY_BAD                 "std_food_destroy_bad"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Speichert den Wert fuer das Verhalten, wenn eine Speise verdirbt.
+     Dieses Verhalten wird in make_bad() umgesetzt.
+
+     
+
+     DESTROY_BAD   : Die Speise wird beim Verderben zerstoert
+                     bzw. der Behaelter wird geleert
+     DESTROY_NEVER : Die Speise wird beim Verderben nicht zerstoert
+     pos. Integer  : Anzahl der Sekunden, die zwischen Verderben
+                     und Zerstoeren der Speise liegen sollen
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Ist ein positiver Integer-Wert in dieser Property gespeichert, wird nach
+     Ausfuehren der Methode make_bad() nach Ablauf der angegebenen Sekunden
+     ein weiterer Reset ausgeloest, der make_destroy() aufruft.
+
+     
+
+DEFAULT
+-------
+::
+
+     Initial ist diese Property auf DESTROY_BAD gesetzt.
+
+SIEHE AUCH
+----------
+::
+
+     /std/food.c, wiz/food
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_DESTRUCT_MSG.rst b/doc/sphinx/props/P_DESTRUCT_MSG.rst
new file mode 100644
index 0000000..82257b3
--- /dev/null
+++ b/doc/sphinx/props/P_DESTRUCT_MSG.rst
@@ -0,0 +1,21 @@
+P_DESTRUCT_MSG
+==============
+
+NAME
+----
+::
+
+    P_DESTRUCT_MSG                "destruct_msg"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung, die beim Destructen Obj ausgegegen wird (nur Magier)
+
diff --git a/doc/sphinx/props/P_DETAILS.rst b/doc/sphinx/props/P_DETAILS.rst
new file mode 100644
index 0000000..50f42c9
--- /dev/null
+++ b/doc/sphinx/props/P_DETAILS.rst
@@ -0,0 +1,44 @@
+P_DETAILS
+=========
+
+NAME
+----
+::
+
+    P_DETAILS            "details"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property enthaelt ein Mapping, in der Details im Objekt
+    definiert werden und Beschreibungen, die ausgegeben werden, wenn man
+    sich diese Details anschaut.
+
+BEMERKUNGEN
+-----------
+::
+
+    Man kann diese Property nicht per SetProp() veraendern, sondern muss die
+    entsprechenden Funktionen nutzen.
+    AddSpecialDetail() und RemoveSpecialDetail() sollten nicht mehr
+    verwendet werden.
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddDetail()
+    Loeschen:  RemoveDetail()
+    Aehnlich:  P_SPECIAL_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail()
+    Sonstiges: GetDetail(), break_string()
+
+27. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_DIE_MSG.rst b/doc/sphinx/props/P_DIE_MSG.rst
new file mode 100644
index 0000000..6825d1d
--- /dev/null
+++ b/doc/sphinx/props/P_DIE_MSG.rst
@@ -0,0 +1,57 @@
+P_DIE_MSG
+=========
+
+NAME
+----
+::
+
+     P_DIE_MSG			"die_msg"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property uebergibt man einen String, der ausgegeben wird, wenn
+     das Lebewesen stirbt. Ist die Property nicht gesetzt, so wird als String
+     benutzt:
+	" faellt tot zu Boden.\n".
+
+     Der Name des Lebewesens wird dem String vor der Ausgabe vorangestellt.
+     Der Satzumbruch am Zeilenende und das Leerzeichen nach dem Namen des
+     Lebewesens muss man selbst angegeben. Es sollte allerdings beachtet
+     werden, dass ein Lebewesen, das durch Gift getoetet wird, eine spezielle
+     nicht zu beeinflussende Meldung erhaelt. Es wird dann als String
+     benutzt:
+	" wird von Gift hinweggerafft und kippt um.\n".
+
+BEISPIELE
+---------
+::
+
+     Bei einem mitkaempfenden Schatten waere es eher unlogisch, wenn nach
+     dessen 'Tod' eine Leiche zurueckbliebe. Eine logische Konsequenz waere
+     folgende Meldung:
+	SetProp(P_DIE_MSG," loest sich auf.\n");
+	SetProp(P_NOCORPSE,1);
+
+     Damit dann auch wirklich keine Leiche zurueckbleibt, wird zusaetzlich
+     die Property P_NOCORPSE gesetzt.
+
+SIEHE AUCH
+----------
+::
+
+     Tod:		die(L)
+     Todesmeldungen:	P_KILL_NAME, P_KILL_MSG, P_MURDER_MSG
+			P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
+     Sonstiges:		P_CORPSE, P_NOCORPSE, /std/corpse.c
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_DISABLE_ATTACK.rst b/doc/sphinx/props/P_DISABLE_ATTACK.rst
new file mode 100644
index 0000000..033963e
--- /dev/null
+++ b/doc/sphinx/props/P_DISABLE_ATTACK.rst
@@ -0,0 +1,64 @@
+P_DISABLE_ATTACK
+================
+
+NAME
+----
+::
+
+    P_DISABLE_ATTACK              "disable_attack"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Das Lebewesen kann nicht angreifen. Beim Setzen der Property ist es
+    wichtig, SetProp() zu benutzen und die Anzahl der Kampfrunden anzugeben,
+    die das Lebewesen paralysiert sein soll.
+
+    Ein negativer Wert ist nicht gueltig. Bei mehr als 30 Kampfrunden wird
+    die Paralyse auf 30 Kampfrunden gekappt.
+
+    Fuer jede Paralyse bekommt ein Living eine ebenso lange Schutzzeit nach
+    der Paralyse gewaehrt. Versucht man, vor Ablauf der Paralyse
+    P_DISABLE_ATTACK hoeher zu setzen (oder setzt man innerhalb der folgenden
+    Schutzzeit P_DISABLE_ATTACK auf > 0), wird DISABLE_TOO_EARLY von SetProp
+    zurueck gegeben.
+    Eine Reduktion von einem P_DISABLE_ATTACK ist moeglich, allerdings
+    reduziert dies _nicht_ eine einmal gesetzte Schutzzeit.
+
+    Einen Gegner,der nie paralysiert werden koennen soll, kann man einfach
+    per 
+
+    Set(P_DISABLE_ATTACK, function int () {return 0;}, F_SET_METHOD);
+
+    erstellen, da bei diesem der Wert von P_DISABLE_ATTACK nicht mehr mit
+    einem normalen SetProp()-Aufruf geaendert werden kann.
+
+BEISPIELE
+---------
+::
+
+    // Gegner 17 Runden lang paralysieren, ohne Ruecksicht auf fruehere P.
+    // (in diesem Moment ist das Living bis time() + 4 * 17 vor laengerer
+    //  oder erneuter Paralyse geschuetzt)
+    en->SetProp(P_DISABLE_ATTACK, 17);
+    // Der Gegner kann jetzt fuer 34 Kampfrunden nicht erneut paralysiert
+    // werden.
+    // Paralyse reduzieren auf 10 Kampfrunden
+    en->SetProp(P_DISABLE_ATTACK, 10);
+    // Die Schutzzeit ist immer noch bei 34 Kampfrunden, nicht bei 20.
+
+SIEHE AUCH
+----------
+::
+
+    P_NEXT_DISABLE_ATTACK
+
+19.08.2014, Zesstra
+
diff --git a/doc/sphinx/props/P_DISABLE_COMMANDS.rst b/doc/sphinx/props/P_DISABLE_COMMANDS.rst
new file mode 100644
index 0000000..a219298
--- /dev/null
+++ b/doc/sphinx/props/P_DISABLE_COMMANDS.rst
@@ -0,0 +1,100 @@
+P_DISABLE_COMMANDS
+==================
+
+NAME
+----
+::
+
+     P_DISABLE_COMMANDS             "p_lib_disablecommands"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player/command.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mit dieser Prop kann man verhindern, dass Kommandos eines Spielers
+    verarbeitet werden. Dies ist z.B. in Sequenzen nuetzlich, wo der Spieler
+    rein passiv konsumieren soll.
+    In diese Property muss ein Array mit 2 oder 3 Elementen geschrieben 
+    werden:
+       1) Endzeitpunkt in Sekunden seit 1.1.1970 (int)
+       2) Meldung (String oder Closure)
+       3) (optional) Array von trotzdem erlaubten Verben (string*)
+         (nur ausgewertet, wenn die Meldung ein String ist)
+
+    
+
+    Ist die Meldung ein String, wird dieser einfach bei jedem Kommando so wie
+    er ist an den Spieler ausgegeben und das Kommando abgebrochen.
+    Ist die Meldung eine Closure wird diese bei jedem Kommando aufgerufen und
+    das Kommando abgebrochen, wenn sie einen Rueckgabewert != 0 zurueckgibt.
+    In diesem Fall ist die gerufene Funktion dafuer verantwortlich, geeignete
+    Meldungen an den Spieler auszugeben!
+    Der Funktion wird der vom Spieler eingebene Befehl (string) als erstes
+    Argument uebergeben. Zu diesem Zeitpunkt wurde alle Aliase schon
+    ausgewertet. Die Funktion kann den Kommandogeber via this_player()
+    ermitteln.
+    Fuer weitere Informationen steht auch command_stack() zur Verfuegung,
+    allerdings ist dort die Alias-Ersetzung nicht beruecksichtigt.
+
+    Die Ausnahmeliste wird nur fuer simple Strings als Meldung ausgewertet,
+    wird eine Closure verwendet, kann diese besser selber die Ausnahmen
+    bestimmen.
+
+    
+
+    Fragt man diese Prop ab, erhaelt man ein Array mit 4 Elementen: setzendes
+    Objekt (object), Ablaufzeit (int), Meldung (String oder Closure) und
+    Liste von Ausnahmen (string*).
+
+BEMERKUNGEN
+-----------
+::
+
+    1. Die Prop wird fuer Magier mit eingeschaltetem P_WANTS_TO_LEARN
+       ignoriert.
+    2. Wenn das Objekt zerstoert wird, was die Prop gesetzt hat, wird der
+       Eintrag unwirksam.
+    3. Wenn diese Prop gesetzt und nicht abgelaufen ist, kann nur das gleiche
+       Objekt sie mit neuen Daten ueberschreiben. Alle anderen Objekte koennen
+       die Prop nur loeschen. Dies soll verhindern, dass Magier unabsichtlich
+       einfach anderer Leute Eintraege ueberschreiben. Dementsprechend: Lasst
+       die Finger davon, wenn die schon gesetzt ist. ;-)
+    4. Diese Prop darf _ausschliesslich_ mit SetProp() und QueryProp() benutzt
+       werden, Set() und Query() funktionieren _nicht_.
+    5. Es gibt einige Verben, die NIE blockiert werden. Zur Zeit sind dies
+       "mrufe", "mschau", "bug", "idee", "typo" und "detail".
+    6. Bitte nicht missbrauchen, speziell nicht dazu, die Kommandos von
+       Spieler zu ueberwachen/mitzuschreiben. Das Setzen dieser Prop wird 
+       geloggt.
+
+BEISPIEL
+--------
+::
+
+   In einem Raum startet eine Sequenz, in der der Spieler nichts machen soll:
+
+   if (!pl->QueryProp(P_DISABLE_COMMANDS))
+      pl->SetProp(P_DISABLE_COMMANDS,
+            ({ time() + 120, "Du bist tief in Deinem Traum gefangen!\n" }) );
+   else // ... Fehlerbehandlung, falls Prop schon gesetzt ...
+
+   
+
+   Soll die Prop aus irgendeinem Grund (vorzeitig) geloescht werden:
+   pl->SetProp(P_DISABLE_COMMANDS, 0);
+
+SIEHE AUCH
+----------
+::
+
+     command(), query_command(), command_stack(), modify_command(), 
+     this_player()
+
+01.12.2012, Zesstra
+
diff --git a/doc/sphinx/props/P_DISTRIBUTION.rst b/doc/sphinx/props/P_DISTRIBUTION.rst
new file mode 100644
index 0000000..07b0d99
--- /dev/null
+++ b/doc/sphinx/props/P_DISTRIBUTION.rst
@@ -0,0 +1,34 @@
+P_DISTRIBUTION
+==============
+
+NAME
+----
+::
+
+     P_DISTRIBUTION                "std_food_distribution"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/food.h
+
+BESCHREIBUNG
+------------
+::
+
+     Verteilung der Heilung ueber mehrere Heartbeats.
+     Dieser Wert wird im entry_info als H_DISTRIBUTION dem consume() im
+     Living uebergeben.
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     consume
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_DMSG.rst b/doc/sphinx/props/P_DMSG.rst
new file mode 100644
index 0000000..d276da5
--- /dev/null
+++ b/doc/sphinx/props/P_DMSG.rst
@@ -0,0 +1,21 @@
+P_DMSG
+======
+
+NAME
+----
+::
+
+    P_DMSG                        "destmsg"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     *** OBSOLET! *** Siehe P_DESTRUCT_MSG
+
diff --git a/doc/sphinx/props/P_DOMAIN.rst b/doc/sphinx/props/P_DOMAIN.rst
new file mode 100644
index 0000000..5050d06
--- /dev/null
+++ b/doc/sphinx/props/P_DOMAIN.rst
@@ -0,0 +1,51 @@
+P_DOMAIN
+========
+
+NAME
+----
+::
+
+    P_DOMAIN                                        "lib_p_domain"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt die Region, in der ein Raum liegt, sofern er
+     in /d/ liegt.
+
+     Falls ein Raum nicht in /d/ liegt, aber es eigentlich ein Gebiet ist,
+     welches eindeutig in einer Region zugeordnet ist, kann der Magier
+     hier gezielt einen anderen Wert setzen.
+
+     
+
+     Bitte keine Regionen faelschen!
+
+BEISPIEL
+--------
+::
+
+     In /d/inseln/zesstra/vulkanweg/room/r1 liefert
+     QueryProp(P_DOMAIN)
+     ein "Inseln" zurueck.
+
+     In einem Raum der Chaosgilde:
+     SetProp(P_DOMAIN, "Polar");
+     damit der Raum als Raum der Region Polar angezeigt wird.
+
+SIEHE AUCH
+----------
+::
+
+     gmcp
+
+
+23.02.2013, Zesstra
+
diff --git a/doc/sphinx/props/P_DOOR_INFOS.rst b/doc/sphinx/props/P_DOOR_INFOS.rst
new file mode 100644
index 0000000..20c9e0c
--- /dev/null
+++ b/doc/sphinx/props/P_DOOR_INFOS.rst
@@ -0,0 +1,59 @@
+P_DOOR_INFOS
+============
+
+NAME
+----
+::
+
+    P_DOOR_INFOS                  "door_infos"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/doorroom.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mapping mit Informationen ueber eine im Raum per NewDoor() definierte
+    Tuer. Diese Infos werden ueber /std/room/doors.c an den /obj/doormaster.c
+    weitergegeben und dem Raum, der die Tuer besitzt, als Property gesetzt.
+    Werden mehrere Tueren in einem Raum eingebunden, enthaelt das Mapping
+    entsprechend viele Eintraege.
+
+    Dieses Mapping dient zur internen Verwaltung der Tueren im
+    /obj/doormaster.c und sollte nicht per Hand veraendert werden!
+
+    Die Eintraege im Mapping haben folgende keys (definiert in
+    /sys/doorroom.h):
+
+    D_DEST : Zielraum (string)
+    D_CMDS : Befehl(e), um durch die Tuer zu gehen (string oder *string)
+    D_IDS  : IDs der Tuer (string oder *string)
+    D_FLAGS : Besondere Eigenschaften der Tuer (Tuer braucht Schluessel etc.)
+    D_LONG  : Langbeschreibung (string)
+    D_SHORT : Kurzbeschreibung (string)
+    D_NAME  : Name (string oder *string)
+    D_GENDER  : Geschlecht
+    D_FUNC    : Funktion, die VOR dem Durchschreiten der Tuer aufgerufen wird
+    D_MSGS    : Bewegungsmeldungen
+    D_FUNC2   : Funktion, die NACH dem Durchschreiten der Tuer aufgerufen wird
+    D_TESTFUNC  : Funktion die im Sartraum testet, ob die Tuer durchschritten
+                  werden darf
+    D_RESET_MSG : Meldungen beim Tuer-Reset
+    D_OPEN_WITH_MOVE : Falls gesetzt, wird die Tuer auch mit dem
+                       Bewegungsbefehl geoeffnet und durchschritten, falls
+                       Oeffnen erfolgreich
+
+SIEHE AUCH
+----------
+::
+
+    NewDoor(), QueryDoorKey(), QueryDoorStatus(), SetDoorStatus(),
+    /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+
+
+Letzte Aenderung: Don, 08.05.2014, Gabylon
+
diff --git a/doc/sphinx/props/P_DO_DESTRUCT.rst b/doc/sphinx/props/P_DO_DESTRUCT.rst
new file mode 100644
index 0000000..e6bc84f
--- /dev/null
+++ b/doc/sphinx/props/P_DO_DESTRUCT.rst
@@ -0,0 +1,36 @@
+P_DO_DESTRUCT
+=============
+
+NAME
+----
+::
+
+    P_DO_DESTRUCT                 "do_destruct"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Flag, ob sich die Lichtquelle am Ende der Leuchtzeit selbst
+     zerstoert. 
+
+SIEHE AUCH
+----------
+::
+
+     Basisklassen: /std/lightsource.c
+     Properties: P_FUEL, P_LIGHTDESC, P_LIGHT
+     Methoden: AddFuel(L)
+
+LETZTE AENDERUNG
+----------------
+::
+
+    22. Dez. 2015, Arathorn
+
diff --git a/doc/sphinx/props/P_DRINK.rst b/doc/sphinx/props/P_DRINK.rst
new file mode 100644
index 0000000..28bfb18
--- /dev/null
+++ b/doc/sphinx/props/P_DRINK.rst
@@ -0,0 +1,42 @@
+P_DRINK
+=======
+
+NAME
+----
+::
+
+     P_DRINK                       "drink"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     - Lebewesen
+       Numerischer Wert fuer den Saettigungsgrad eines Lebewesens mit
+       Getraenken. Der maximale Wert steht in P_MAX_DRINK.
+
+     - Speisen/Kneipen
+       Numerischer Wert fuer den Saettigungsgrad einer Portion eines
+       Getraenkes. Ist diese Property nicht gesetzt oder zusaetzlich
+       P_FOOD gesetzt, kann man diese Speise nicht trinken. Eine
+       funktionierende Speise _muss_ entweder P_FOOD oder P_DRINK
+       groesser 0 gesetzt haben.
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     P_MAX_DRINK, P_DRINK_DELAY, consume
+     P_FOOD, P_ALCOHOL, wiz/food
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_DRINK_DELAY.rst b/doc/sphinx/props/P_DRINK_DELAY.rst
new file mode 100644
index 0000000..199436c
--- /dev/null
+++ b/doc/sphinx/props/P_DRINK_DELAY.rst
@@ -0,0 +1,23 @@
+P_DRINK_DELAY
+=============
+
+NAME
+----
+::
+
+    P_DRINK_DELAY                 "drink_delay"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der heart_beats, bis P_DRINK um einen Punkt sinkt.
+     Aenderungen dieser Property in Spielern beduerfen der 
+     Genehmigung des EM fuer Balance.
+
diff --git a/doc/sphinx/props/P_DRINK_FULL_MSG.rst b/doc/sphinx/props/P_DRINK_FULL_MSG.rst
new file mode 100644
index 0000000..a30a49c
--- /dev/null
+++ b/doc/sphinx/props/P_DRINK_FULL_MSG.rst
@@ -0,0 +1,50 @@
+P_DRINK_FULL_MSG
+================
+
+NAME
+----
+::
+
+     P_DRINK_FULL_MSG              "std_food_drink_full_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn ein Getraenk getrunken werden soll,
+     obwohl dieser nichts mehr trinken kann.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "So viel kannst Du im Moment nicht trinken."
+
+SIEHE AUCH
+----------
+::
+
+     P_DRINK, P_MAX_DRINK, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_DROP_MSG.rst b/doc/sphinx/props/P_DROP_MSG.rst
new file mode 100644
index 0000000..7268555
--- /dev/null
+++ b/doc/sphinx/props/P_DROP_MSG.rst
@@ -0,0 +1,100 @@
+P_DROP_MSG
+==========
+
+NAME
+----
+::
+
+     P_DROP_MSG				"drop_message" 
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/put_and_get.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mit P_DROP_MSG kann man die Meldung, die man beim Ablegen eines
+     Objektes bekommt, modifizieren.
+
+     Folgende Werte sind moeglich:
+
+	
+
+     o 0
+       Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung. 
+
+	  
+
+     o NO_PNG_MSG       == -1
+       Es wird keinerlei Meldung ausgegeben
+
+	  
+
+     o Ein Array aus Strings 
+       Der erste String wird an den Spieler ausgegeben, der zweite 
+       (optionale) an den Raum. 
+
+	  
+
+       Die Strings werden durch die Funktion replace_personal() geparst.
+	Objekt1 - Spieler
+        Objekt2 - das Objekt, das fallengelassen wird
+
+	  
+
+       Wird der zweite String nicht angegeben, erfolgt keine Meldung an
+       den Raum.
+
+				
+
+BEISPIEL
+--------
+::
+
+     void create() {
+      ...
+      SetProp( P_SHORT, "Ugars Handaxt" );
+      SetProp( P_LONG, break_string(
+       "Dieses ist eine Kampfaxt, wie sie Orks normalerweise benutzen. "
+       "Da Du Zeit hast, sie Dir anzuschauen, ist der Besitzer wohl "
+       "bereits bei Lars.",78 ));
+
+	  
+
+      SetProp( P_NAME, "Axt" );
+      AddId( ({"handaxt","axt"}) );
+      SetProp( P_GENDER, FEMALE );
+
+	  
+
+      SetProp( P_DROP_MSG, ({
+       "Du schmeisst @WEN2 hin.",
+       "@WER1 schmeisst Dir @WENU2 vor die Fuesse.\n"}));
+      ...
+     }
+
+     Will Ugar seine Axt ablegen und gibt "lasse axt fallen" ein, werden 
+     folgende Meldungen ausgegeben:
+
+	
+
+     Ugar: "Du schmeisst die Axt hin."
+     Raum: "Ugar schmeisst Dir eine Axt vor die Fuesse."
+
+	
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_PICK_MSG, P_PUT_MSG, P_GIVE_MSG, P_WEAR_MSG, P_WIELD_MSG
+     Fehler:     P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
+                 P_NOINSERT_MSG, P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     Sonstiges:  replace_personal(E), drop_obj(L), /std/living/put_and_get.c
+
+14. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_EARMUFFS.rst b/doc/sphinx/props/P_EARMUFFS.rst
new file mode 100644
index 0000000..3ec9835
--- /dev/null
+++ b/doc/sphinx/props/P_EARMUFFS.rst
@@ -0,0 +1,22 @@
+P_EARMUFFS
+==========
+
+NAME
+----
+::
+
+    P_EARMUFFS                    "earmuffs"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Shouts von Spielern und Magiern mit Magierlevel < earmuffs werden
+     abgeblockt (Nur fuer Magier).
+
diff --git a/doc/sphinx/props/P_EATER_MSG.rst b/doc/sphinx/props/P_EATER_MSG.rst
new file mode 100644
index 0000000..75ccb2f
--- /dev/null
+++ b/doc/sphinx/props/P_EATER_MSG.rst
@@ -0,0 +1,49 @@
+P_EATER_MSG
+===========
+
+NAME
+----
+::
+
+     P_EATER_MSG                   "std_food_eater_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn eine Speise konsumiert wird.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "Du konsumierst @WEN1."
+
+SIEHE AUCH
+----------
+::
+
+     /std/food.c, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_EFFECTIVE_AC.rst b/doc/sphinx/props/P_EFFECTIVE_AC.rst
new file mode 100644
index 0000000..50fbeb1
--- /dev/null
+++ b/doc/sphinx/props/P_EFFECTIVE_AC.rst
@@ -0,0 +1,107 @@
+P_EFFECTIVE_AC
+==============
+
+NAME
+----
+::
+
+     P_EFFECTIVE_AC      "effective_ac"
+
+DEFINIERT IN
+------------
+::
+
+     <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property kommt sowohl in Ruestungen als auch in Waffen, die
+     schuetzen sollen, zum Einsatz.
+
+     In Ruestungen kann hier der Effektivwert der Ruestungsklasse vermerkt
+     werden, wenn diese noch durch eine DefendFunc() modifiziert wird
+     (soweit sich ein solcher Effektivwert angeben laesst).
+
+     In einigen Gilden koennen Waffen auch als Ruestung eingesetzt werden
+     (z.B. beim Parieren eines Angriffs). In dieser Property kann man die
+     Ruestungsklasse eintragen, die die Waffe bei solchen Aktionen aufweisen
+     soll. Dabei ist man an die ueblichen Beschraenkungen der
+     Ruestungsklasse gebunden! (s. /sys/combat.h)
+
+BERMERKUNGEN
+------------
+::
+
+     Das Kaempferspellbook verwendet fuer Paraden etc. P_EFFECTIVE_AC anstatt
+     P_AC, wenn verfuegbar.
+
+BEISPIELE
+---------
+::
+
+     * DefendFuncs: 
+       Der doppelte Mittelwert der DefendFunc wird zur Basis-AC dazuaddiert,
+       da sich der 'Schutzwert = random(Basis-AC) + absolut(DefendFunc-Wert)'
+       berechnet.
+
+     // #1 Eine Ruestung mit P_AC von 35 und randomisierter DefendFunc
+        SetProp(P_AC, 35);
+        SetProp(P_DEFEND_FUNC, this_object());
+
+        int DefendFunc(...) {
+          return random(20);                       // Mittelwert: 10
+        }
+        -> SetProp(P_EFFECTIVE_AC, 55);            // 35 + 2*10 = 55
+
+     // #2 Eine Ruestung mit P_AC von 35 und teilrandomisierter DefendFunc
+        SetProp(P_AC, 35);
+        SetProp(P_DEFEND_FUNC, this_object());
+
+        int DefendFunc(...) {
+          return 20 + random(10);                  // Mittelwert: 20 + 5
+        }
+        -> SetProp(P_EFFECTIVE_AC, 85);            // 35 + 2*(20+5) = 85
+
+     * Sonderfunktion im Kontext der Kaempfergilde:
+       Auch wenn der eigentliche AC-Wert durch keine DefendFunc oAe
+       modifiziert wird, sind abweichende Werte in P_EFFECTIVE_AC zB in der
+       Kaempfergilde fuer Paraden oder aehnliches sinnvoll. Maximalwert ist
+       dafuer der doppelte Wert des Basis-AC-Wertes.
+
+     // #3 Ein schon sehr gutes Schild, welches bei der Schildparade aber
+     //    noch besser schuetzen soll.
+        SetProp(P_ARMOUR_TYPE, AT_SHIELD);
+        SetProp(P_AC, 38);
+        SetProp(P_EFFECTIVE_AC, 55);
+
+     // #4 Ein sehr labbriges Schild schuetzt zwar gegen normale Schlaege,
+     //    ist zum Parieren aber irgendwie ungeeignet weil unkontrollierbar.
+        SetProp(P_ARMOUR_TYPE, AT_SHIELD);
+        SetProp(P_AC, 38);
+        SetProp(P_EFFECTIVE_AC, 20);
+
+     * Waffen:
+       P_EFFECTIVE_AC wird im Kaempferspellbook als Bonus dazugezaehlt! Daher
+       sollten gute Parierwaffen auch einen niedrigeren P_WC-Wert haben.
+       Reine Parierwaffen duerfen den maximalen AC-Wert von Schilden als
+       Maximum gesetzt haben - die Balance klaert ggf, ob das auch auf den
+       Gildenparierwert anwendbar ist.
+
+     // #5 Eine maessige Hellebarde/Axtwaffe mit Parierhaken.
+        SetProp(P_WEAPON_TYPE, WT_AXE);
+        SetProp(P_WC, 100);
+        SetProp(P_EFFECTIVE_AC, 25);
+
+SIEHE AUCH
+----------
+::
+
+     Waffen:     P_WC, P_TOTAL_WC, P_EFFECTIVE_WC, HitFunc()
+     Ruestungen: P_AC, P_TOTAL_AC, DefendFunc()
+     Files:      /std/weapon.c, /std/weapon/combat.c
+     Balance:    waffen, ruestungen, properties, kaempferboni
+
+6. Nov 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_EFFECTIVE_WC.rst b/doc/sphinx/props/P_EFFECTIVE_WC.rst
new file mode 100644
index 0000000..6064049
--- /dev/null
+++ b/doc/sphinx/props/P_EFFECTIVE_WC.rst
@@ -0,0 +1,112 @@
+P_EFFECTIVE_WC
+==============
+
+NAME
+----
+::
+
+     P_EFFECTIVE_WC     "effective_wc"
+
+DEFINIERT IN
+------------
+::
+
+     <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property kommt sowohl in Waffen als auch Ruestungen, die Schaden
+     machen sollen, zum Einsatz.
+
+     Falls die Staerke einer Waffe noch durch eine HitFunc() modifiziert
+     wird, sollte hier der Effektivwert der Waffenklasse vermerkt werden,
+     soweit er sich angeben laesst.
+     Diese Property dient vor allem dazu, eine Waffe mit HitFunc() korrekt
+     einzuschaetzen.
+
+     In einigen Gilden koennen Ruestungen auch als Waffen eingesetzt werden
+     (z.B. ein Paar Schuhe zum Treten). In dieser Property kann man die
+     Waffenklasse eintragen, die die Ruestung bei solchen Aktionen aufweisen
+     soll. Dabei ist man an die ueblichen Beschraenkungen der Waffenklasse
+     gebunden! (s. /sys/combat.h)
+     Der Ruestung kann man dann auch einen Schadenstyp mit auf den Weg
+     geben.
+
+BEMERKUNGEN
+-----------
+::
+
+     Das Kaempferspellbook verwendet bei Ruestungen P_AC, wenn
+     P_EFFECTIVE_WC nicht gesetzt ist.
+
+BEISPIELE
+---------
+::
+
+     * HitFuncs:
+       Der doppelte Mittelwert der HitFunc wird zur Basis-WC dazuaddiert,
+       da sich der 'Angriffswert = random(Basis-WC) + absolut(HitFunc-Wert)'
+       berechnet.
+
+     // #1 Waffe mit Basis-WC 120 und randomisierter HitFunc
+        SetProp(P_WC, 120);
+        SetProp(P_HIT_FUNC, this_object());
+
+       
+
+        int HitFunc(...) {
+          return random(30);                       // Mittelwert: 15
+        }
+        -> SetProp(P_EFFECTIVE_WC, 150);           // 120 + 2*15 = 150
+
+     
+
+     // #2 Waffe mit Basis-WC 120 und teilweise absoluter HitFunc
+        SetProp(P_WC, 120);
+        SetProp(P_HIT_FUNC, this_object());
+
+       
+
+        int HitFunc(...) {
+          return 30 + random(10);                  // Mittelwert: 30 + 5
+        }
+        -> SetProp(P_EFFECTIVE_WC, 190);           // 120 + 2*(30+5) = 190
+
+     * Ruestungen (zB Gildennutzung):
+       Der Maximalwert fuer die P_EFFECTIVE_WC bei Kaempfern ist der jeweils
+       doppelte maximale P_AC-Wert. Angabe eines Schadenstyps ist sinnvoll.
+
+     // #3 Ein paar Schuhe, mit maximalem Schlag-/Saeureschaden.
+        SetProp(P_ARMOUR_TYPE, AT_BOOT);
+        SetProp(P_AC, 2);
+        SetProp(P_DAM_TYPE, ({DT_BLUDGEON,DT_ACID}));
+        -> SetProp(P_EFFECTIVE_WC, 12);  // hoechstmoeglicher Wert bei
+                                         // Schuhen, da deren max. P_AC = 6
+     // aequivalent und zukunftssicher:
+        -> SetProp(P_EFFECTIVE_WC, 2 * VALID_ARMOUR_CLASS[AT_BOOT]);
+
+     // #4 Ein Schild mit spitzem Dorn. (Stichschaden beim Schildstoss.)
+        SetProp(P_ARMOUR_TYPE, AT_SHIELD);
+        SetProp(P_AC, 5);
+        SetProp(P_DAM_TYPE, ({DT_PIERCE}));
+        SetProp(P_EFFECTIVE_WC, 55);
+
+     // #5 Ein Gummischild ist schlecht fuer Angriffe. BOING!
+        SetProp(P_ARMOUR_TYPE, AT_SHIELD);
+        SetProp(P_AC, 30);
+        SetProp(P_DAM_TYPE, ({DT_BLUDGEON}));
+        SetProp(P_EFFECTIVE_WC, 10);
+
+SIEHE AUCH
+----------
+::
+
+     Waffen:     P_WC, P_TOTAL_WC, HitFunc()
+     Ruestungen: P_AC, P_TOTAL_AC, P_EFFECTIVE_AC, DefendFunc()
+     Files:      /std/weapon.c, /std/weapon/combat.c
+     Balance:    waffen, ruestungen, properties, kaempferboni
+
+6. Nov 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_EMPTY_MSG.rst b/doc/sphinx/props/P_EMPTY_MSG.rst
new file mode 100644
index 0000000..a7855f4
--- /dev/null
+++ b/doc/sphinx/props/P_EMPTY_MSG.rst
@@ -0,0 +1,50 @@
+P_EMPTY_MSG
+===========
+
+NAME
+----
+::
+
+     P_EMPTY_MSG                   "std_food_eater_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn versucht wird, eine aufgebrauchte Speise
+     (also einen leeren Behaelter) zu konsumieren.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise (also den leeren Behaelter)
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "@WER1 ist bereits leer."
+
+SIEHE AUCH
+----------
+::
+
+     /std/food.c, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_EMPTY_PROPS.rst b/doc/sphinx/props/P_EMPTY_PROPS.rst
new file mode 100644
index 0000000..43512b9
--- /dev/null
+++ b/doc/sphinx/props/P_EMPTY_PROPS.rst
@@ -0,0 +1,59 @@
+P_EMPTY_PROPS
+=============
+
+NAME
+----
+::
+
+     P_EMPTY_PROPS                 "std_food_empty_props"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Mapping mit Properties fuer den leeren Behaelter, der uebrig bleibt,wenn
+     eine Speise aufgebraucht ist. Alle enthaltenen Properties werden gesetzt,
+     wenn keine Portionen mehr vorhanden sind.
+     Bereits in diesen Properties eingetragene Werte werden ueberschrieben!
+     Wenn diese Property nicht gesetzt ist, wird die Speise zerstoert, wenn
+     alle Portionen aufgebraucht ist - es bleibt also kein Behaelter zurueck.
+     Achtung: Es werden keine closures in diesem Mapping unterstuetzt!
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Bei der Abfrage von P_VALUE und P_WEIGHT in der Speise, werden die dazu
+     in P_EMPTY_PROPS gespeicherten Werte verwendet, um das Gewicht/Wert des
+     leeren Behaelters zum Gesamtwert der Speise zu addieren.
+     Man kann alle Properties in dieses Mapping eintragen, die sich in der
+     Speise per SetProp setzen lassen. Zusaetzlich kann man Arrays in P_IDS
+     und P_ADJECTIVES speichern, die per Add-Methode in der Speise
+     hinzugefuegt werden, nachdem die im create() der Speise hinzugefuegten
+     Ids/Adjectives dort entfernt wurden.
+
+     
+
+BEISPIELE
+---------
+::
+
+     Beispiele zur Verwendung findet man unter /doc/beispiele/food
+
+SIEHE AUCH
+----------
+::
+
+     /std/food.c, wiz/food
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_ENABLE_IN_ATTACK_OUT.rst b/doc/sphinx/props/P_ENABLE_IN_ATTACK_OUT.rst
new file mode 100644
index 0000000..af59fb0
--- /dev/null
+++ b/doc/sphinx/props/P_ENABLE_IN_ATTACK_OUT.rst
@@ -0,0 +1,52 @@
+P_ENABLE_IN_ATTACK_OUT
+======================
+
+NAME
+----
+::
+
+	P_ENABLE_IN_ATTACK_OUT		"enable_in_attack_out"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	Normalerweise wird die bekannte Taktik Rein-Angriff-Raus
+	standardmaessig unterbunden, damit NPCs auch eine Chance haben, sich
+	zu verteidigen. Hierzu wird der Schaden innerhalb do_damage()
+	durch einen Wert geteilt, der sich aus der Verweildauer des
+	Angreifers im Raum ergibt (bis zu 3 Sekunden).
+	Da manche NPCs so konzeptioniert wurden, dass man sie nur mit der
+	erwaehnten Taktik toeten kann, kann man sie auch explizit erlauben
+	(manche NPCs verwenden auch eigene Methoden, diese Taktik zu
+	 verbieten, und sie waere dann doppelt abgefangen).
+	Hierzu setzt man einfach die Property P_ENABLE_IN_ATTACK_OUT im NPC.
+
+BEISPIEL
+--------
+::
+
+	Das folgende Beispiel erlaubt einfach mal die angesprochene Taktik:
+	  void create()
+	  { ...
+	    SetProp(P_ENABLE_IN_ATTACK_OUT,1);
+	    ...
+	  }
+	Jetzt kann man den NPC mit Rein-Angriff-Raus auch wirkungsvoll
+	bekaempfen.
+
+SIEHE AUCH
+----------
+::
+
+	do_damage(), P_LAST_MOVE, /std/living/life.c
+
+
+Last modified: Sat Jan 30 12:53:00 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_ENEMY_DAMAGE.rst b/doc/sphinx/props/P_ENEMY_DAMAGE.rst
new file mode 100644
index 0000000..6991f15
--- /dev/null
+++ b/doc/sphinx/props/P_ENEMY_DAMAGE.rst
@@ -0,0 +1,48 @@
+P_ENEMY_DAMAGE
+==============
+
+NAME
+----
+::
+
+     P_ENEMY_DAMAGE "enemy_damage"
+
+DEFINIERT IN
+------------
+::
+
+     <living/life.h>
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property ist vermerkt, welches Wesen diesem Wesen wieviel
+     Schaden zugefuegt hat.
+
+     Die Property enthaelt ein Mapping, das den Angreifern den
+     errechten Schaden zuordnet:
+     ([ <obname1>: <damage>; <owner>, ... ])
+
+       <obname1>: Name des Objekts, das den Schaden verursacht hat (string),
+                  z.B. "/magier:zesstra"
+       <damage> : Schadensmenge (int)
+       <owner>  : wenn das schadensverursachende Wesen ein NPC war/ist,
+                  welches P_HELPER_NPC gesetzt hatte und somit einem Spieler
+                  hilft, steht hier das Objekt des jeweiligen Spielers
+                  (object)
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Property laesst sich nur abfragen!
+
+SIEHE AUCH
+----------
+::
+
+     P_HELPER_NPC
+
+26.10.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_ENEMY_DEATH_SEQUENCE.rst b/doc/sphinx/props/P_ENEMY_DEATH_SEQUENCE.rst
new file mode 100644
index 0000000..82e888e
--- /dev/null
+++ b/doc/sphinx/props/P_ENEMY_DEATH_SEQUENCE.rst
@@ -0,0 +1,61 @@
+P_ENEMY_DEATH_SEQUENCE
+======================
+
+NAME
+----
+::
+
+     P_ENEMY_DEATH_SEQUENCE        "enemy_death_sequence"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Ueber diese Property kann Einfluss auf die Todessequenz eines getoeten
+     Spielers genommen werden. Sie muss im toetenden Objekt, d.h. dem
+     Objekt welches die()/do_damage()/Defend() im Spieler gerufen hat,
+     gesetzt sein.
+
+     Es gibt folgende gueltige Werte:
+     - string: Pfad zu einer eigenen Todessequenz im gueltigen Format
+     - mixed*  Eine Todessequenz im Format des Todesraumes:
+               ({<int gesamtlaenge>,
+                 ([<int index1>: <string umgebrochene Meldung1>,
+                   <int index2>: <string umgebrochene Meldung2>,
+                   ...])
+               })
+     - mapping In die Standard-Lars-Todessequenz einzufuegende Zeilen:
+               ([<int zeitindex>: <string umgebrochener Text>])
+
+BEISPIELE
+---------
+::
+
+     // Pfad zu einer eigenen DSQ
+     SetProp(P_ENEMY_DEATH_SEQUENCE,  ".../passende_dsq.txt");
+
+     // eigene DSQ im Todesraumformat:
+     SetProp(P_ENEMY_DEATH_SEQUENCE,
+             ({ 2, ([1: "DU LERNST AUS DEINEM FEHLER.\n"])}));
+
+     // Einfuegen einer Meldung (des NPCs) in die Standard-Todessequenz
+     SetProp(P_ENEMY_DEATH_SEQUENCE,
+             ([5: "Du hoerst "+name(WEN)+" hoehnisch kichern.\n"]));
+
+SIEHE AUCH
+----------
+::
+
+     Tod:            die(L)
+     Todesmeldungen: P_KILL_NAME, P_KILL_MSG, P_DIE_MSG, P_MURDER_MSG
+                     P_ZAP_MSG, P_NEXT_DEATH_SEQUENCE
+     Sonstiges:      P_CORPSE, P_NOCORPSE, /room/death/death_room.c
+
+10. Nov 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_ENTERCMDS.rst b/doc/sphinx/props/P_ENTERCMDS.rst
new file mode 100644
index 0000000..17f9de1
--- /dev/null
+++ b/doc/sphinx/props/P_ENTERCMDS.rst
@@ -0,0 +1,59 @@
+P_ENTERCMDS
+===========
+
+NAME
+----
+::
+
+    P_ENTERCMDS                   "leavecmds"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+    Ein Array mit Befehlen, die zum Betreten des Transporters fuehren. 
+
+BEISPIEL
+--------
+::
+
+    SetProp(P_ENTERCMDS,({ "betrete","betritt" }) );
+
+    Gibt der Spieler nun 'betrete xxx' ein, so sorgt /std/transport.c 
+    dafuer, das der Spieler auch auf oder in den Transporter bewegt 
+    wird. Vorausgesetzt natuerlich, er ist an einem Haltepunkt ange-
+    langt und es ist genuegend Platz dort.
+
+BEMERKUNGEN
+-----------
+::
+
+    Um /std/transport.c nicht aufzublaehen, werden weitere Argumente wie
+    etwa 'betrete das|die|den xxx' _nicht_ unterstuetzt!
+
+    Hier muss der verantwortliche Magier schon eine eigene Loesung finden
+    und in seinen Transporter schreiben.
+
+    Sollen Kommandos zum Betreten UND Verlassen eines Transporters ver-
+    wendet werden koennen, muessen diese in P_TRAVEL_CMDS gesetzt werden.
+
+SIEHE AUCH
+----------
+::
+
+    P_LEAVEFAIL, P_ENTERFAIL, P_LEAVECMDS, P_TRAVEL_CMDS, transporter,
+
+LETZTE AENDERUNG
+----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
+    
+
diff --git a/doc/sphinx/props/P_ENTERFAIL.rst b/doc/sphinx/props/P_ENTERFAIL.rst
new file mode 100644
index 0000000..538b528
--- /dev/null
+++ b/doc/sphinx/props/P_ENTERFAIL.rst
@@ -0,0 +1,48 @@
+P_ENTERFAIL
+===========
+
+NAME
+----
+::
+
+    P_ENTERFAIL                   "enterfail"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Spieler, wenn er einen vollen Transporter betreten 
+     will. Ist die Propertie ein Array, so wird das erste Element als
+     Meldung an den Spieler, das zweite als Meldung an die Mitspieler 
+     im Raum geschickt.
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_ENTERFAIL,"Dort ist wirklich kein Platz mehr fuer Dich");
+
+     
+
+     SetProp(P_ENTERFAIL, ({ "Dort ist wirklich kein Platz mehr fuer Dich",
+                             "versucht, auf die Kutsche zu klettern, wird "
+                            +"aber wieder heruntergeschickt" }) );
+
+SIEHE AUCH
+----------
+::
+
+     P_ENTERMSG, P_LEAVEFAIL, P_LEAVEMSG, transporter
+
+LETZTE AENDERUNG
+----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
diff --git a/doc/sphinx/props/P_ENTERMSG.rst b/doc/sphinx/props/P_ENTERMSG.rst
new file mode 100644
index 0000000..72e5ea4
--- /dev/null
+++ b/doc/sphinx/props/P_ENTERMSG.rst
@@ -0,0 +1,40 @@
+P_ENTERMSG
+==========
+
+NAME
+----
+::
+
+    P_ENTERMSG                    "entermsg"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+     Array mit zwei Meldungen, eine fuer den Raum, den der Spieler
+     verlaesst, und eine fuer den Transporter, in den er geht.
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_ENTERMSG, ({ "klettert in die Kutsche","klettert herein" }) );
+
+SIEHE AUCH
+----------
+::
+
+     P_ENTERFAIL, P_LEAVEFAIL, P_LEAVEMSG, transporter
+
+LETZTER AENDERUNG
+-----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
diff --git a/doc/sphinx/props/P_ENV_MSG.rst b/doc/sphinx/props/P_ENV_MSG.rst
new file mode 100644
index 0000000..ec38445
--- /dev/null
+++ b/doc/sphinx/props/P_ENV_MSG.rst
@@ -0,0 +1,52 @@
+P_ENV_MSG
+=========
+
+NAME
+----
+::
+
+     P_ENV_MSG                     "std_food_env_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn eine Speise konsumiert werden soll,
+     die nicht im eigenen Inventory liegt.
+     Wenn diese Property leer ist, kann man die Speise dann sogar
+     konsumieren!
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "Vielleicht solltest Du @WEN1 vorher nehmen."
+
+SIEHE AUCH
+----------
+::
+
+     wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_ENV_TOO_HEAVY_MSG.rst b/doc/sphinx/props/P_ENV_TOO_HEAVY_MSG.rst
new file mode 100644
index 0000000..619628c
--- /dev/null
+++ b/doc/sphinx/props/P_ENV_TOO_HEAVY_MSG.rst
@@ -0,0 +1,50 @@
+P_ENV_TOO_HEAVY_MSG
+===================
+
+NAME
+----
+::
+
+    P_ENV_TOO_HEAVY_MSG                      "env_too_heavy_msg"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn jemand
+     versucht, ein Objekt in einen Behaelter zu legen, und dieser dann fuer
+     sein Environment zu schwer wird.
+     Die Property ist im Behaelter zu setzen.
+     Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
+     so wird die Standardmeldung ausgegeben.
+     ("<Behaelter> wuerde dir dann zu schwer werden.")
+     Der String in der Property wird noch durch replace_personal()
+     verarbeitet, das zu bewegende Objekt wird als erstes, der Behaelter als
+     zweites Objekt angegeben. Danach wird der String auf 78 Zeichen
+     umgebrochen.
+     Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
+     ganz.
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_ENV_TOO_HEAVY_MSG, "Mit @WEM1 koenntest du den Rucksack nicht"
+                                  " mehr tragen.");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_TOO_HEAVY_MSG, P_TOO_MANY_MSG, P_NOINSERT_MSG,
+                 P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     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
+
diff --git a/doc/sphinx/props/P_EQUIP_TIME.rst b/doc/sphinx/props/P_EQUIP_TIME.rst
new file mode 100644
index 0000000..eca2965
--- /dev/null
+++ b/doc/sphinx/props/P_EQUIP_TIME.rst
@@ -0,0 +1,40 @@
+P_EQUIP_TIME
+============
+
+NAME
+----
+::
+
+      P_EQUIP_TIME			"equip_time"
+
+DEFINIERT IN
+------------
+::
+
+      /sys/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+      Innerhalb von Waffen und Ruestungen wird in dieser Property
+      registriert, wann diese zuletzt gezueckt bzw. angezogen wurden.
+      Innerhalb der Funktionen wield_me() in '/std/weapon/combat' bzw.
+      DoWear() in '/std/armour/combat' wird hierbei jeweils folgende Aktion
+      ausgefuehrt:
+	SetProp(P_EQUIP_TIME,time());
+
+SIEHE AUCH
+----------
+::
+
+      Verwandt:		P_LAST_USE
+      Waffen:		P_UNWIELD_TIME
+			DoWield()
+      Ruestungen:	DoWear()
+      Sonstiges:	time()
+			/std/weapon/combat.c, /std/armour/combat.c
+
+
+Last modified: Sun Jul 26 23:59:12 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_EVAL_FACTORS.rst b/doc/sphinx/props/P_EVAL_FACTORS.rst
new file mode 100644
index 0000000..7d390ed
--- /dev/null
+++ b/doc/sphinx/props/P_EVAL_FACTORS.rst
@@ -0,0 +1,21 @@
+P_EVAL_FACTORS
+==============
+
+NAME
+----
+::
+
+    P_EVAL_FACTORS                "inpc_eval_factors"           
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/eval.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_EVAL_OFFSETS.rst b/doc/sphinx/props/P_EVAL_OFFSETS.rst
new file mode 100644
index 0000000..ff6e604
--- /dev/null
+++ b/doc/sphinx/props/P_EVAL_OFFSETS.rst
@@ -0,0 +1,21 @@
+P_EVAL_OFFSETS
+==============
+
+NAME
+----
+::
+
+    P_EVAL_OFFSETS                "inpc_eval_offsets"           
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/eval.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_EXITS.rst b/doc/sphinx/props/P_EXITS.rst
new file mode 100644
index 0000000..574f33c
--- /dev/null
+++ b/doc/sphinx/props/P_EXITS.rst
@@ -0,0 +1,47 @@
+P_EXITS
+=======
+
+NAME
+----
+::
+
+    P_EXITS                       "exits"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mapping (der Breite 2) aller unmittelbar sichtbaren Ausgaenge mit
+    zugehoerigen Nachbarraeumen und der jeweiligen Bewegungsmeldung.
+
+BEMERKUNG
+---------
+::
+
+    Enthaelt auch SpecialExits, bei der Abfrage mit QueryProp() werden
+    diese jedoch ausgefiltert.
+
+    
+
+    Zugriff nur mit den dafuer vorgesehenen Funktionen, bitte nicht aendern.
+
+  
+
+SIEHE AUCH
+----------
+::
+
+     AddExit(), AddSpecialExit(), GetExits(),
+     RemoveExit(), RemoveSpecialExit(),
+     GuardExit(),
+     H_HOOK_EXIT_USE, P_SPECIAL_EXITS, P_HIDE_EXITS, /std/room/exits.c
+     ausgaenge
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/props/P_FAO.rst b/doc/sphinx/props/P_FAO.rst
new file mode 100644
index 0000000..3e692a0
--- /dev/null
+++ b/doc/sphinx/props/P_FAO.rst
@@ -0,0 +1,33 @@
+P_FAO
+=====
+
+NAME
+----
+::
+
+     P_FAO      "fraternitasdonoarchmagorum"
+
+DEFINIERT IN
+------------
+::
+
+     <player/fao.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Fraternitas-relevante Property.
+
+     Genaue Informationen unbekannt.
+     Schreibender Zugriff ist nur EMs oder dem FAOMASTER (s. Headerfile)
+     moeglich.
+
+SIEHE AUCH
+----------
+::
+
+     P_FAO_PORTALS
+
+1.September 2008 Gloinson
+
diff --git a/doc/sphinx/props/P_FAO_PORTALS.rst b/doc/sphinx/props/P_FAO_PORTALS.rst
new file mode 100644
index 0000000..a155488
--- /dev/null
+++ b/doc/sphinx/props/P_FAO_PORTALS.rst
@@ -0,0 +1,38 @@
+P_FAO_PORTALS
+=============
+
+NAME
+----
+::
+
+     P_FAO_PORTALS      "fraternitasdonoarchmagorumPORTALS"
+
+DEFINIERT IN
+------------
+::
+
+     <player/fao.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Fraternitas-relevante Property.
+
+     Enthaelt eine Array mit einer Liste der ueber die Fraternitas
+     gefundenen und benutzbaren Seher-Portale.
+
+     Genaue Informationen unbekannt.
+     Schreibender Zugriff ist nur EMs oder dem FAOMASTER (s. Headerfile) 
+     moeglich.
+
+SIEHE AUCH
+----------
+::
+
+     P_FAO_PORTALS, P_SEERDOORS
+
+     
+
+1.September 2008 Gloinson
+
diff --git a/doc/sphinx/props/P_FISH.rst b/doc/sphinx/props/P_FISH.rst
new file mode 100644
index 0000000..f91a4d8
--- /dev/null
+++ b/doc/sphinx/props/P_FISH.rst
@@ -0,0 +1,93 @@
+P_FISH
+======
+
+NAME
+----
+::
+
+    P_FISH                        "fish"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/fishing.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt Einstellungen zu allem, was mit Fischen zu tun hat. 
+    Kann in Fischen, Raeumen und Koedern gesetzt werden. Die verfuegbaren 
+    Optionen und Funktionsweisen sind in den nachfolgenden Abschnitten 
+    aufgefuehrt.
+
+    Fische:
+    *******
+    Die Property legt zusaetzliche Eigenschaften fest:
+
+      F_NOROTTEN
+        Fisch fault nicht; ggf. sollte hier auch gleich F_NOHEAL gesetzt 
+        werden, weil sonst eine unverderbliche tragbare Tanke erzeugt wuerde.
+      F_NOTHUNGRY
+        Fisch frisst Koeder nur, wenn er auch wirklich nachher an der Angel
+        haengt. Ist er zu schwer fuer die Angel und reisst ab, bleibt der
+        Koeder erhalten.
+      F_REPLACE
+        Fisch soll sich beim Entfernen von der Angel verwandeln. Hierzu ist
+        die Funktion ReplaceFish() im Fisch zu definieren, die sich um die
+        Verwandlung kuemmert (z.B. Monster clonen und Fisch zerstoeren; ein
+        Beispiel findet sich in /d/ebene/fraggle/angel2/obj/saegefisch.c).
+      F_NOHEAL
+        Fisch heilt nicht bei Verzehr
+
+    Raum (OPTIONAL):
+    ****************
+    Legt die Fischdichte des Gewaessers fest. Der eingestellte Wert wirkt 
+    sich auf die Wartezeit aus, die der Angler verbringen muss, bis ein 
+    Fisch anbeisst. Berechnung im Detail (alle Zahlenwerte in Sekunden):
+    - Basis-Wartezeit: delay = 80
+    - Die Werte von P_FISH von Raum und Koeder werden addiert:
+      summe = raum->QueryProp(P_FISH) + koeder->QueryProp(P_FISH)
+      -> positive Werte (Bonus) werden auf 60 begrenzt und mit Zufalls-
+         komponente von <delay> abgezogen:
+         delay -= random(summe)
+      -> negative Werte (Malus) werden auf -300 begrenzt und mit Zufalls-
+         komponente auf <delay> aufgeschlagen:
+         delay += random(-summe)
+
+    Zusaetzlich wird ein weiterer Malus auf die Wartezeit faellig, falls 
+    P_WATER in der Angel und/oder P_WATER im Koeder nicht zum aktuellen 
+    Gewaesser passen. Der Malus betraegt jeweils 60+random(60) Sekunden.
+
+    
+
+    Der Standardwert fuer P_FISH im Raum ist 0 und bedeutet 100 % Bestand.
+    Positive Werte erhoehen die Dichte, negative senken sie. Positive Werte 
+    sollten nicht >100 sein.
+
+    Sofern sich die Werte fuer P_FISH in den empfohlenen Grenzen bewegen,
+    koennen Abzuege fuer falsches Gewaesser ueblicherweise kaum durch
+    Boni auf Angel oder Koeder kompensiert werden. Ausserdem ist zu
+    bedenken, dass es keine Boni fuer richtige Gewaesserwahl gibt.
+
+ 
+
+    Koeder (OPTIONAL):
+    ******************
+    Ein Koeder kann mittels P_FISH die Fischdichte modifizieren, um hierueber
+    ein besseres Beissen der Fische zu simulieren (reduziert die Wartezeit
+    beim Angeln, siehe oben unter "Raum"). Wenn also der Raum einen Wert
+    von -100 gesetzt hat und der Koeder +100, entspricht die Fischdichte im 
+    Gewaesser wieder dem Normalwert.
+
+SIEHE AUCH
+----------
+::
+
+    Properties: P_WATER
+    Methoden:   GetAquarium(L)
+
+
+Zuletzt geaendert: 2014-Aug-21, Arathorn
+
diff --git a/doc/sphinx/props/P_FLAGS.rst b/doc/sphinx/props/P_FLAGS.rst
new file mode 100644
index 0000000..22a2fef
--- /dev/null
+++ b/doc/sphinx/props/P_FLAGS.rst
@@ -0,0 +1,21 @@
+P_FLAGS
+=======
+
+NAME
+----
+::
+
+    P_FLAGS                       "can_flags"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Flags des Spielers
+
diff --git a/doc/sphinx/props/P_FOLLOW_SILENT.rst b/doc/sphinx/props/P_FOLLOW_SILENT.rst
new file mode 100644
index 0000000..5424539
--- /dev/null
+++ b/doc/sphinx/props/P_FOLLOW_SILENT.rst
@@ -0,0 +1,22 @@
+P_FOLLOW_SILENT
+===============
+
+NAME
+----
+::
+
+    P_FOLLOW_SILENT               "follow_silent"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn diese Property 1 ist, wird der MOVE vom verfolge Silent ausge-
+     fuehrt.
+
diff --git a/doc/sphinx/props/P_FOOD.rst b/doc/sphinx/props/P_FOOD.rst
new file mode 100644
index 0000000..4acd9e6
--- /dev/null
+++ b/doc/sphinx/props/P_FOOD.rst
@@ -0,0 +1,39 @@
+P_FOOD
+======
+
+NAME
+----
+::
+
+     P_FOOD                        "food"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     - Lebewesen
+       Numerischer Wert fuer den Saettigungsgrad eines Lebewesens.
+       Der maximale Wert steht in P_MAX_FOOD.
+
+     - Speisen/Kneipen
+       Numerischer Wert fuer den Saettigungsgrad einer Portion einer
+       Speise. Ist diese Property nicht gesetzt, kann man diese
+       Speise nicht essen. Eine funktionierende Speise _muss_ entweder
+       P_FOOD oder P_DRINK groesser 0 gesetzt haben.
+
+SIEHE AUCH
+----------
+::
+
+     P_MAX_FOOD, P_FOOD_DELAY, consume,
+     P_DRINK, P_ALCOHOL, wiz/food
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_FOOD_DELAY.rst b/doc/sphinx/props/P_FOOD_DELAY.rst
new file mode 100644
index 0000000..e19f2e8
--- /dev/null
+++ b/doc/sphinx/props/P_FOOD_DELAY.rst
@@ -0,0 +1,23 @@
+P_FOOD_DELAY
+============
+
+NAME
+----
+::
+
+    P_FOOD_DELAY                 "food_delay"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der heart_beats, bis P_FOOD um einen Punkt sinkt.
+     Aenderungen dieser Property in Spielern beduerfen der 
+     Genehmigung des EM fuer Balance.
+
diff --git a/doc/sphinx/props/P_FOOD_FULL_MSG.rst b/doc/sphinx/props/P_FOOD_FULL_MSG.rst
new file mode 100644
index 0000000..9f74716
--- /dev/null
+++ b/doc/sphinx/props/P_FOOD_FULL_MSG.rst
@@ -0,0 +1,50 @@
+P_FOOD_FULL_MSG
+===============
+
+NAME
+----
+::
+
+     P_FOOD_FULL_MSG               "std_food_full_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn eine Speise gegessen werden soll,
+     obwohl dieser nichts mehr essen kann.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "Du bist zu satt, das schaffst Du nicht mehr."
+
+SIEHE AUCH
+----------
+::
+
+     P_FOOD, P_MAX_FOOD, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_FORCE_MURDER_MSG.rst b/doc/sphinx/props/P_FORCE_MURDER_MSG.rst
new file mode 100644
index 0000000..059b096
--- /dev/null
+++ b/doc/sphinx/props/P_FORCE_MURDER_MSG.rst
@@ -0,0 +1,58 @@
+P_FORCE_MURDER_MSG
+==================
+
+NAME
+----
+::
+
+	P_FORCE_MURDER_MSG		"force_murder_msg"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+	Ob der Tod eines NPCs auf dem Moerder-Kanal erscheint, haengt davon
+	ab, wie oft und welche Art von NPCs in der letzten Zeit getoetet
+	wurden. Zum Beispiel ist es eher selten, dass ein schwacher NPC auf
+	dem Kanal erscheint, wenn kuerzlich viele starke NPCs getoetet
+	wurden. Mittels der Property P_FORCE_MURDER_MSG kann man auf diese
+	Regelung Einfluss nehmen.
+	Ein Wert groesser Null erzwingt die Meldung auf dem Moerder-Kanal,
+	ein Wert kleiner Null unterdrueckt sie generell. Letzteres ist
+	insbesondere fuer allzuoft getoetete Monster sinnvoll, um den
+	Moerder-Kanal nicht uebermaessig zu belasten. Mit dem Erzwingen der
+	Meldungen sollte man somit vorsichtig sein: Weniger ist oftmals
+	besser als zu viel!
+	Die Defaulteinstellung von P_FORCE_MURDER_MSG ist natuerlich Null
+	und fuehrt zur bereits beschriebenen opferabhaengigen Meldung.
+
+BEISPIELE
+---------
+::
+
+	Ein grosser starker NPC, der getoetet wurde, sollte schon eine tolle
+	Meldung auf dem Moerder-Kanal erzeugen. In der Property
+	P_MURDER_MSG koennen hierzu alternative Texte zu den normal per
+	Zufall ausgewaehlten angegeben werden:
+	  SetProp(P_MURDER_MSG,
+                  "Nicht schlecht, aber das schafft eh nur einer!");
+	  SetProp(P_FORCE_MURDER_MSG,1);
+	Zwar ist es bei grossen NPCs hinreichend wahrscheinlich, dass es
+	infolge derer Staerke zur automatischen Ausgabe einer Moerdermeldung
+	kommt, aber mit der letzten Zeile wurde dies absolut sichergestellt.
+
+SIEHE AUCH
+----------
+::
+
+	P_MURDER_MSG, P_ZAP_MSG, P_KILL_MSG, P_DIE_MSG, P_CORPSE, P_NOCORPSE
+
+
+Last modified: Tue Nov 10 02:15:26 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_FREE_HANDS.rst b/doc/sphinx/props/P_FREE_HANDS.rst
new file mode 100644
index 0000000..b05f5ed
--- /dev/null
+++ b/doc/sphinx/props/P_FREE_HANDS.rst
@@ -0,0 +1,40 @@
+P_FREE_HANDS
+============
+
+NAME
+----
+::
+
+    P_FREE_HANDS                  "free_hands"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    Anzahl der freien Haende.
+    Effektiv nur ein die Differenz von P_MAX_HANDS und P_USED_HANDS.
+
+BEMERKUNGEN
+-----------
+::
+
+    Keine echte Property. Die Methode /std/living/combat::_query_free_hands
+    stellt die Daten zusammen. Nicht setzen!
+
+SIEHE AUCH
+----------
+::
+
+    P_HANDS, P_HANDS_USED_BY
+    P_MAX_HANDS, P_USED_HANDS
+    UseHands, FreeHands
+    /std/weapon.c, /std/spellbook.c
+
+1. Okt 2012, Gloinson
+
diff --git a/doc/sphinx/props/P_FRIEND.rst b/doc/sphinx/props/P_FRIEND.rst
new file mode 100644
index 0000000..479dcf9
--- /dev/null
+++ b/doc/sphinx/props/P_FRIEND.rst
@@ -0,0 +1,40 @@
+P_FRIEND
+========
+
+NAME
+----
+::
+
+	P_FRIEND			"friend"
+
+DEFINIERT IN
+------------
+::
+
+	<combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+	Setzt man diese Property in einem NPC auf einen Wert ungleich Null,
+	so wird der NPC bei Zauberspruechen, die auf bestimmte Gruppen
+	wirken, der Gruppe der Spieler und nicht der Gruppe der NPCs
+	zugeordnet. Ausserdem wird der NPC bei einem "toete alle" nicht mit
+	angegriffen.
+	Wurde der NPC einem Spieler per AssocMember() zugeordnet, so
+	befindet sich der NPC automatisch im jeweiligen Team des Spielers
+	 (moeglichst auch in der selben Kampfreihe), und die Property hat
+	dann automatisch das Spielerobjekt als Wert.
+	Da dieser Wert in diesem Fall natuerlich ungleich Null ist, wird der
+	NPC dann auch der Gruppe der Spieler zugeordnet.
+
+SIEHE AUCH
+----------
+::
+
+	FindGroup(), AssocMember(), P_TEAM_ASSOC_MEMBERS, /std/living/team.c
+
+
+Last modified: Tue Dec 29 17:02:55 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_FROG.rst b/doc/sphinx/props/P_FROG.rst
new file mode 100644
index 0000000..e639e8e
--- /dev/null
+++ b/doc/sphinx/props/P_FROG.rst
@@ -0,0 +1,21 @@
+P_FROG
+======
+
+NAME
+----
+::
+
+    P_FROG                        "frog"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gesetzt, wenn der Spieler ein Frosch ist.
+
diff --git a/doc/sphinx/props/P_FUEL.rst b/doc/sphinx/props/P_FUEL.rst
new file mode 100644
index 0000000..8cd22e7
--- /dev/null
+++ b/doc/sphinx/props/P_FUEL.rst
@@ -0,0 +1,48 @@
+P_FUEL
+======
+
+NAME
+----
+::
+
+    P_FUEL                        "fuel"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Numerischer Wert fuer die Zeitdauer, die die Lichtquelle noch
+     leuchten kann. Standardmaessig ist der Wert auf 20 gesetzt.
+
+     Setzt man die Property auf einen Wert, der groesser ist als der vorige
+     Maximalwert, wird dieser auf den neuen Wert erhoeht. Aendert man den
+     Brennstoffvorrat der Lichtquelle hingegen mittels AddFuel(), so wird
+     der Wert von P_FUEL ueber den Maximalwert hinaus erhoeht.
+
+HINWEIS
+-------
+::
+
+     Fuer Aenderungen an der Property kann auch die Funktion AddFuel()
+     verwendet werden. 
+
+SIEHE AUCH
+----------
+::
+
+     Basisklassen: /std/lightsource.c
+     Properties:   P_LIGHTDESC, P_DO_DESTRUCT, P_LIGHT
+     Methoden:     AddFuel(L)
+
+LETZTE AENDERUNG
+----------------
+::
+
+    22. Dez. 2015, Arathorn
+
diff --git a/doc/sphinx/props/P_FUNC_MSG.rst b/doc/sphinx/props/P_FUNC_MSG.rst
new file mode 100644
index 0000000..2acab57
--- /dev/null
+++ b/doc/sphinx/props/P_FUNC_MSG.rst
@@ -0,0 +1,40 @@
+P_FUNC_MSG
+==========
+
+NAME
+----
+::
+
+    P_FUNC_MSG                    "func_msg"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Liste mit Funktionen, die zufaellig im Raum aufgerufen werden.
+
+     Hier ist nur eine zur rufende lokale Methode als String oder eine
+     Sammlung davon als Stringarray gespeichert.
+
+ANMERKUNGEN
+-----------
+::
+
+     Bitte AddRoomMessage() zum Hinzufuegen/Ueberschreiben benutzen!
+
+SIEHE AUCH
+----------
+::
+
+     LFuns:    AddRoomMessage()
+     Verwandt: tell_room(), ReceiveMsg()
+     Props:    P_ROOM_MSG, P_MSG_PROB
+
+2.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_FW_ALWAYS_READABLE.rst b/doc/sphinx/props/P_FW_ALWAYS_READABLE.rst
new file mode 100644
index 0000000..5fa135a
--- /dev/null
+++ b/doc/sphinx/props/P_FW_ALWAYS_READABLE.rst
@@ -0,0 +1,21 @@
+P_FW_ALWAYS_READABLE
+====================
+
+NAME
+----
+::
+
+    P_FW_ALWAYS_READABLE          "fw_always_readable"          
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_FW_UNDERSTAND.rst b/doc/sphinx/props/P_FW_UNDERSTAND.rst
new file mode 100644
index 0000000..d2badf1
--- /dev/null
+++ b/doc/sphinx/props/P_FW_UNDERSTAND.rst
@@ -0,0 +1,21 @@
+P_FW_UNDERSTAND
+===============
+
+NAME
+----
+::
+
+    P_FW_UNDERSTAND               "fw_understand"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_GENDER.rst b/doc/sphinx/props/P_GENDER.rst
new file mode 100644
index 0000000..f1a9aaa
--- /dev/null
+++ b/doc/sphinx/props/P_GENDER.rst
@@ -0,0 +1,22 @@
+P_GENDER
+========
+
+NAME
+----
+::
+
+    P_GENDER                      "gender"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/language.h
+
+BESCHREIBUNG
+------------
+::
+
+     Grammatikalisches Geschlecht des Objektes:
+     (Definiert in language.h) MALE, FEMALE oder NEUTER
+
diff --git a/doc/sphinx/props/P_GHOST.rst b/doc/sphinx/props/P_GHOST.rst
new file mode 100644
index 0000000..1bc4544
--- /dev/null
+++ b/doc/sphinx/props/P_GHOST.rst
@@ -0,0 +1,21 @@
+P_GHOST
+=======
+
+NAME
+----
+::
+
+    P_GHOST                       "ghost"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gesetzt, wenn der Spieler tot ist.
+
diff --git a/doc/sphinx/props/P_GIVE_MSG.rst b/doc/sphinx/props/P_GIVE_MSG.rst
new file mode 100644
index 0000000..497800f
--- /dev/null
+++ b/doc/sphinx/props/P_GIVE_MSG.rst
@@ -0,0 +1,83 @@
+P_GIVE_MSG
+==========
+
+NAME
+----
+::
+
+     P_GIVE_MSG				"give_message"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/put_and_get.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mit P_GIVE_MSG kann man die Meldung, die man beim Uebergeben eines
+     Objektes bekommt, modifizieren.
+
+     Folgende Werte sind moeglich:
+
+     o 0
+       Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
+
+     o NO_PNG_MSG	== -1
+       Es wird keinerlei Meldung ausgegeben
+
+     o Ein Array aus Strings
+       Der erste String wird an den Spieler ausgegeben, der zweite
+       (optionale) an den Raum, der dritte (ebenfalls optionale) an den
+       Empfaenger.
+
+       Die Strings werden durch die Funktion replace_personal() geparst.
+	Objekt1 - Spieler
+        Objekt2 - das Objekt, das uebergeben wird
+	Objekt3 - Empfaenger
+
+       Wird der zweite String nicht angegeben, erfolgt keine Meldung an den
+       Raum. Beim Fehlen des dritten gibt es keine Meldung an den Empfaenger.
+
+BEISPIEL
+--------
+::
+
+     void create() {
+      ...
+      SetProp( P_SHORT, "Etwas Sand" );
+      SetProp( P_LONG, break_string(
+	"Ein wenig magischer Sand. Sehr feinkruemelig.",78 ));
+
+      SetProp( P_NAME, "Sand" );
+      AddId( ({"sand"}) );
+      SetProp( P_GENDER, MALE );
+
+      SetProp( P_GIVE_MSG, ({
+       "Du laesst @WEN2 in @WESSEN3 Haende rieseln.",
+       "@WER1 laesst @WENU2 in @WESSEN3 Haende rieseln.",
+       "@WER1 laesst @WENU2 in deine Haende rieseln."}));
+       ...
+      }
+
+     Das ganze fuehrt bei Ugars "gib sand an peter" zu folgenden
+     Meldungen:
+
+     Ugar: "Du laesst den Sand in Peters Haende rieseln."
+     Raum: "Ugar laesst Sand in Peters Haende rieseln."
+     Peter: "Ugar laesst Sand in deine Haende rieseln."
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_DROP_MSG, P_PUT_MSG, P_PICK_MSG, P_SHOW_MSG
+     Fehler:     P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
+                 P_NOINSERT_MSG, P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     Sonstiges:  replace_personal(E), give(L), give_objects(L),
+		 give_notify(L), /std/living/put_and_get.c
+
+14. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_GLOBAL_SKILLPROPS.rst b/doc/sphinx/props/P_GLOBAL_SKILLPROPS.rst
new file mode 100644
index 0000000..88f92c9
--- /dev/null
+++ b/doc/sphinx/props/P_GLOBAL_SKILLPROPS.rst
@@ -0,0 +1,46 @@
+P_GLOBAL_SKILLPROPS
+===================
+
+NAME
+----
+::
+
+    P_GLOBAL_SKILLPROPS        "sm_global"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Gilden- und Spellbookproperty enthaelt Eigenschaften, die
+    alle Spells eines Spellbooks bzw. alle Skills und Spells einer Gilde
+    haben sollen.
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_GLOBAL_SKILLPROPS,
+      ([SI_SKILLRESTR_USE:     ([SR_FUN: #'spellTest]),
+        OFFSET(SI_SKILLLEARN): #'learnOffset,
+        OFFSET(SI_SPELLCOST):  #'costOffset,
+        FACTOR(SI_SPELLCOST):  #'costFactor]));
+
+SIEHE AUCH
+----------
+::
+
+    GObj Verwalten:   LearnSkill, LearnSpell, InitialSkillAbility
+    * Properties:     P_GUILD_SKILLS
+    Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
+    * Verwalten:      AddSpell, QuerySpell
+    * Properties:     P_SB_SPELLS
+    Skills:           P_NEWSKILLS, spruchermuedung, skill_info_liste
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_GUARD.rst b/doc/sphinx/props/P_GUARD.rst
new file mode 100644
index 0000000..1564a69
--- /dev/null
+++ b/doc/sphinx/props/P_GUARD.rst
@@ -0,0 +1,70 @@
+P_GUARD
+=======
+
+NAME
+----
+::
+
+     P_GUARD				"guard"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/guard.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property gibt an, ob ein NPC aus einem Raum entfernt werden darf
+     oder nicht. Abgefragt werden muss dies von den Items oder Spells, die
+     den NPC zu einer Bewegung zwingen wollen. Es wird nicht automatisch
+     darauf geachtet!
+
+     Entscheidend hierbei ist ein in der Property enthaltene (ganzzahliger)
+     Zahlenwert zwischen 0 und 100, der hierbei den Grad der
+     'Bewachungsstaerke' eines NPCs angibt. Bei 0 laesst sich das Lebewesen
+     immer zu einer Bewegung ueberreden, bei 100 ueberhaupt nicht. Dazwischen
+     gibt es die Wahrscheinlichkeit dafuer an.
+
+BEMERKUNGEN
+-----------
+::
+
+     - alle von /std/npc abgeleiteten NPCs haben standardmaessig P_GUARD
+       auf 100 gesetzt, sind also nicht fortfuehrbar
+     - bei der Erzeugung von NPCs mit P_GUARD < 100 AddItem() mit dem
+       Parameter REFRESH_MOVE_HOME verwenden, damit sie bei einem Raumreset
+       gegebenenfalls an ihren Ausgangsort zurueckkehren. 
+     - gildenspezifische weitere Abfragen auf Level oAe bitte bei Gilden-
+       magiern erfragen
+
+BEISPIELE
+---------
+::
+
+     // ein Test
+     if(random(100)<=liv->QueryProp(P_GUARD))
+      cannotMoveNPC(); // NPC darf nicht bewegt werden!
+     else
+      moveNPC();       // NPC darf bewegt werden
+
+     // ein wegfuehrbarer NPC
+     void create() {
+      ::create();
+      ...
+      SetProp(P_GUARD,50);
+      ...
+     }
+     // mit 50% Wahrscheinlichkeit (pro Versuch) laesst sich der NPC nun
+     // fortfuehren
+
+SIEHE AUCH
+----------
+::
+
+     AddItem()
+
+13.April 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_GUILD.rst b/doc/sphinx/props/P_GUILD.rst
new file mode 100644
index 0000000..deb56f1
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD.rst
@@ -0,0 +1,40 @@
+P_GUILD
+=======
+
+NAME
+----
+::
+
+     P_GUILD				"guild"                       
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt den Namen der Gilde, welcher das Lebewesen
+     angehoert. Der Name der Gilde ist hierbei kleingeschrieben als String
+     definiert.
+
+BEMERKUNGEN
+-----------
+::
+
+     Bei Spielern ist der Wert dieser Property niemals Null, denn sie
+     gehoeren standardmaessig der in P_DEFAULT_GUILD stehenden Gilde an.
+     Ueber die gesetzte P_GUILD werden auch aktive Skills ermittelt.
+
+SIEHE AUCH
+----------
+::
+
+     P_DEFAULT_GUILD, P_VISIBLE_GUILD
+     P_GUILD_TITLE, P_SUBGUILD_TITLE
+
+26. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_GUILD_DEACTIVATE_SKILLS.rst b/doc/sphinx/props/P_GUILD_DEACTIVATE_SKILLS.rst
new file mode 100644
index 0000000..58b6d12
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_DEACTIVATE_SKILLS.rst
@@ -0,0 +1,52 @@
+P_GUILD_DEACTIVATE_SKILLS
+=========================
+
+PROPERTY
+--------
+::
+
+  P_GUILD_DEACTIVATE_SKILLS     "guild_deactivate_skills"
+
+DEFINIERT IN: 
+
+  new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+  Diese Property erlaubt es, Gildenmitgliedern die benutzung von ANY-
+  Skills zu untersagen. Dies sind einerseits die allgemeinen Waffenskills,
+  andererseits koennte das auch der entgifte-Spruch der Duesterwald -
+  Quest sein.
+
+  Wert dieser Property ist ein Mapping, das als Keys die einzelnen
+  Skills und als Wert 1 enthaelt, wenn ein Skill deaktiviert
+  werden soll und 0, falls nicht.
+
+  Diese Property wird nur bei einem Neuerzeugen des Spielers neu 
+  ausgelesen, da es sonst zuviel Rechenzeit kostet.
+
+BEISPIEL
+--------
+::
+
+  Jede Gilde, die keine Waffenskills benutzen soll (oder selbst welche hat)
+  enthaelt folgenden Befehl:
+
+    SetProp(P_GUILD_DEACTIVATE_SKILLS,
+    ([FIGHT(WT_SWORD):1,
+    FIGHT(WT_AXE):1,
+    FIGHT(WT_CLUB):1,
+    FIGHT(WT_SPEAR):1,
+    FIGHT(WT_KNIFE):1,
+    FIGHT(WT_WHIP):1]));
+
+    
+
+LETZTE AENDERUNG 
+
+2003-01-30, 1415, Humni
+------------------------------------------
+::
+
diff --git a/doc/sphinx/props/P_GUILD_DEFAULT_SPELLBOOK.rst b/doc/sphinx/props/P_GUILD_DEFAULT_SPELLBOOK.rst
new file mode 100644
index 0000000..8b95f62
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_DEFAULT_SPELLBOOK.rst
@@ -0,0 +1,45 @@
+P_GUILD_DEFAULT_SPELLBOOK
+=========================
+
+NAME
+----
+::
+
+	P_GUILD_DEFAULT_SPELLBOOK	"guild_sb"                    
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Gildenproperty enthaelt den Namen des Spellbooks, welches
+	standardmaessig von der Gilde verwendet wird.
+
+BEMERKUNGEN
+-----------
+::
+
+	Bei Spells kann sie mit SI_SPELLBOOK ueberschrieben werden.
+
+BEISPIELE
+---------
+::
+
+	Bei Zauberern waere folgendes denkbar:
+	  SetProp(P_GUILD_DEFAULT_SPELLBOOK,"magie_sp");
+	Das Spellbook ist hierbei unter "/spellbooks/magie_sp.c" zu finden.
+
+SIEHE AUCH
+----------
+::
+
+	P_GUILD
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_GUILD_FEMALE_TITLES.rst b/doc/sphinx/props/P_GUILD_FEMALE_TITLES.rst
new file mode 100644
index 0000000..849677e
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_FEMALE_TITLES.rst
@@ -0,0 +1,43 @@
+P_GUILD_FEMALE_TITLES
+=====================
+
+NAME
+----
+::
+
+	P_GUILD_FEMALE_TITLES		"guild_female_titles"         
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Gildenproperty enthaelt die Stufenbezeichnungen fuer
+	weibliche Gildenmitglieder. Als Schluessel dienen hierbei die
+	Gildenstufen und die entsprechenden Eintraege sind dann die zur
+	Stufe gehoerigen Gildentitel.
+
+BEISPIELE
+---------
+::
+
+	Eine Programmierergilde koennte folgende Stufenbezeichnungen
+	beinhalten:
+	  SetProp(P_GUILD_FEMALE_TITLES,([1:"die Anfaengerin",
+	                                  2:"die Fortgeschrittene",
+	                                  3:"die Professionelle ;)"]));
+
+SIEHE AUCH
+----------
+::
+
+	P_GENDER, P_GUILD_LEVEL, P_GUILD_TITLE, P_GUILD_MALE_TITLES
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_GUILD_LEVEL.rst b/doc/sphinx/props/P_GUILD_LEVEL.rst
new file mode 100644
index 0000000..344cebb
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_LEVEL.rst
@@ -0,0 +1,42 @@
+P_GUILD_LEVEL
+=============
+
+NAME
+----
+::
+
+	P_GUILD_LEVEL			"guild_level"                 
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt die Gildenstufe des Lebewesens, welche nicht
+	unbedingt seiner Spielerstufe entspricht.
+
+BEMERKUNGEN
+-----------
+::
+
+	Bei manchen Gilden entspricht die Gildenstufe standardmaessig der
+	Spielerstufe (Abenteurer, Katzenkrieger). In der Property selbst
+	wird eigentlich ein Mapping eingetragen, welches die Gildennamen als
+	Schluessel und die dazugehoerige Gildenstufe als Eintrag enthaelt.
+	Bei der Abfrage der Property wird jedoch die Gilde beruecksichtigt
+	und die aktuelle Gildenstufe zurueckgeliefert.
+
+SIEHE AUCH
+----------
+::
+
+	P_GUILD, P_GUILD_TITLE, P_GUILD_MALE_TITLES, P_GUILD_FEMALE_TITLES
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_GUILD_LEVELS.rst b/doc/sphinx/props/P_GUILD_LEVELS.rst
new file mode 100644
index 0000000..9b372aa
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_LEVELS.rst
@@ -0,0 +1,57 @@
+P_GUILD_LEVELS
+==============
+
+NAME
+----
+::
+
+	P_GUILD_LEVELS			"guild_levels"                
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Gildenproperty enthaelt ein Mapping mit den
+	Stufenbeschraenkungen fuer die jeweiligen Gildenstufen. Als
+	Schluessel dient der jeweilige Gildenlevel und die entsprechenden
+	Eintraege sind wiederum Mappings, in welchen die Beschraenkungen
+	angegeben sind.
+
+BEMERKUNGEN
+-----------
+::
+
+	Die Beschraenkungen fuer Level 1 sollten auch fuer die
+	Eintrittsbeschraenkungen der Gilde gelten. Letztere kann man in der
+	Property P_GUILD_RESTRICTIONS angeben.
+
+BEISPIELE
+---------
+::
+
+	Das folgende Beispiel zeigt ein paar moegliche Abfragen:
+	  string check(object pl);
+	  SetProp(P_GUILD_LEVELS,([1:([P_LEVEL:3,P_QP:100,SR_FUN:#'check]),
+	                           2:([A_INT:10,P_LEVEL:25]),
+	                           3:([A_INT:20,P_LEVEL:50])]));
+	  string check(object pl)
+	  { if(pl->QueryProp(P_MALE))
+	      return 0;
+	    return "Fuer Frauen ist das nichts!\n";
+	  }
+
+SIEHE AUCH
+----------
+::
+
+	P_GUILD_LEVEL, P_GUILD_RESTRICTIONS, /std/restriction_checker.c
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_GUILD_MALE_TITLES.rst b/doc/sphinx/props/P_GUILD_MALE_TITLES.rst
new file mode 100644
index 0000000..993527b
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_MALE_TITLES.rst
@@ -0,0 +1,43 @@
+P_GUILD_MALE_TITLES
+===================
+
+NAME
+----
+::
+
+	P_GUILD_MALE_TITLES		"guild_male_titles"           
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Gildenproperty enthaelt die Stufenbezeichnungen fuer
+	maennliche Gildenmitglieder. Als Schluessel dienen hierbei die
+	Gildenstufen und die entsprechenden Eintraege sind dann die zur
+	Stufe gehoerigen Gildentitel.
+
+BEISPIELE
+---------
+::
+
+	Eine Programmierergilde koennte folgende Stufenbezeichnungen
+	beinhalten:
+	  SetProp(P_GUILD_MALE_TITLES,([1:"der Anfaenger",
+	                                2:"der Fortgeschrittene",
+	                                3:"der Profi"]));
+
+SIEHE AUCH
+----------
+::
+
+	P_GENDER, P_GILD_LEVEL, P_GUILD_TITLE, P_GUILD_FEMALE_TITLES
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_GUILD_PREPAREBLOCK.rst b/doc/sphinx/props/P_GUILD_PREPAREBLOCK.rst
new file mode 100644
index 0000000..8aeb418
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_PREPAREBLOCK.rst
@@ -0,0 +1,61 @@
+P_GUILD_PREPAREBLOCK
+====================
+
+P_GUILD_PREPAREBLOCK (int)
+--------------------------
+::
+
+NAME
+----
+::
+
+  P_GUILD_PREPAREBLOCK                           "guild_prepareblock" 
+
+DEFINIERT IN
+------------
+::
+
+  /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+  Diese Property enthaelt die Information, ob das Lebewesen in
+  der Konzentrationsphase eines Spells weiterkaempft oder ob
+  die Angriffe derweil ausgesetzt werden.
+
+BEMERKUNGEN
+-----------
+::
+
+  In der Property selbst wird eigentlich ein Mapping eingetragen,
+  welches die Gildennamen als Schluessel und das dazugehoerige
+  Block-Flag als Eintrag enthaelt. Bei der Abfrage der Property wird
+  jedoch die Gilde beruecksichtigt und das aktuelle Flag
+  zurueckgeliefert.
+  Dementsprechend das diese Prop nicht mit Set() manipuliert werden, 
+  bitte ausschliessliche SetProp() verwenden.
+
+BEISPIELE
+---------
+::
+
+  Die Property sollte natuerlich nur von der Gilde gesetzt werden
+  und auch nur bei Gildenmitgliedern
+
+  if ( IsGuildMember(pl) )
+    pl->SetProp(P_GUILD_PREPAREBLOCK,1);
+
+  Resultat: Kein Ausfuehren von Attack(), wenn pl sich auf einen
+  Zauberspruch konzentriert.
+
+SIEHE AUCH
+----------
+::
+
+  P_PREPARED_SPELL
+
+
+18.03.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_GUILD_RATING.rst b/doc/sphinx/props/P_GUILD_RATING.rst
new file mode 100644
index 0000000..b752e00
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_RATING.rst
@@ -0,0 +1,41 @@
+P_GUILD_RATING
+==============
+
+NAME
+----
+::
+
+	P_GUILD_RATING			"guild_rating"                
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property wird die Einstufung des Spielers innerhalb
+	seiner Gilde festgelegt. Der dafuer zu ermittelnde Wert muss in
+	einem Bereich von 0 bis 10000 liegen. Wie sich die Einstufung
+	zusammensetzt, bleibt der jeweiligen Gilde ueberlassen.
+
+BEMERKUNGEN
+-----------
+::
+
+	Der Wert muss von der Gilde ermittelt werden! Meist setzt er sich
+	aus den Faehigkeiten des Mitglieds zusammen und mitunter fliessen
+	auch Gildenquests oder aehnliches mit ein.
+
+SIEHE AUCH
+----------
+::
+
+    P_NEWSKILLS, GuildRating
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_GUILD_RESTRICTIONS.rst b/doc/sphinx/props/P_GUILD_RESTRICTIONS.rst
new file mode 100644
index 0000000..31632a6
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_RESTRICTIONS.rst
@@ -0,0 +1,59 @@
+P_GUILD_RESTRICTIONS
+====================
+
+NAME
+----
+::
+
+    P_GUILD_RESTRICTIONS        "guild_rest"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Gildenproperty enthaelt ein Mapping mit den
+    Eintrittsbeschraenkungen fuer die jeweilige Gilde.
+
+BEMERKUNGEN
+-----------
+::
+
+    Im allgemeinen sollte das Mapping mit den Eintrittsbeschraenkungen
+    mit den Beschraenkungen fuer Level 1 im Mapping von P_GUILD_LEVELS
+    uebereinstimmen.
+
+BEISPIELE
+---------
+::
+
+    Ein paar moegliche Abfragen waeren folgende:
+    string check(object pl);
+
+    SetProp(P_GUILD_RESTRICTIONS,
+            ([P_LEVEL:3,
+              P_QP:100,
+              SR_FUN:#'check]));
+
+    string check(object pl) {
+      if(pl->QueryProp(P_MALE))
+        return 0;
+      return "Fuer Frauen ist das nichts!\n";
+    }
+
+SIEHE AUCH
+----------
+::
+
+    Gildenfkt.:
+    * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+    * Sonstiges:    P_GUILD_LEVELS
+    Sonstiges:      /std/restriction_checker.c
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_GUILD_SKILLS.rst b/doc/sphinx/props/P_GUILD_SKILLS.rst
new file mode 100644
index 0000000..13e1ecb
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_SKILLS.rst
@@ -0,0 +1,42 @@
+P_GUILD_SKILLS
+==============
+
+NAME
+----
+::
+
+    P_GUILD_SKILLS            "guild_skills"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Gildenproperty enthaelt ein Mapping mit allen Skills und
+    Spells der Gilde.
+
+BEMERKUNGEN
+-----------
+::
+
+    Man sollte diese Property sollte nicht per Hand veraendern, sondern
+    die Funktionen AddSkill() bzw. AddSpell() nutzen.
+
+SIEHE AUCH
+----------
+::
+
+    GObj Verwalten:   LearnSkill, LearnSpell, InitialSkillAbility
+    * Sonstiges:      GuildRating
+    Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
+    * Verwalten:      AddSpell, QuerySpell
+    * Properties:     P_SB_SPELLS, P_GLOBAL_SKILLPROPS, P_GUILD_RATING
+    Skills:           P_NEWSKILLS, spruchermuedung, skill_info_liste
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_GUILD_TITLE.rst b/doc/sphinx/props/P_GUILD_TITLE.rst
new file mode 100644
index 0000000..415f3f8
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_TITLE.rst
@@ -0,0 +1,58 @@
+P_GUILD_TITLE
+=============
+
+NAME
+----
+::
+
+     P_GUILD_TITLE			"guild_title"                 
+
+DEFINIERT IN
+------------
+::
+
+     /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt den Gildentitel des Lebewesens, welcher der
+     Gildenstufe des Lebewesens entspricht und jedoch nur angezeigt wird,
+     wenn P_TITLE des Lebewesens gleich Null ist.
+
+BEMERKUNGEN
+-----------
+::
+
+     In der Property selbst wird eigentlich ein Mapping eingetragen, welches
+     die Gildennamen als Schluessel und die dazugehoerigen Gildentitel als
+     Eintrag enthaelt. Bei der Abfrage der Property wird jedoch die Gilde
+     beruecksichtigt und der aktuelle Gildentitel zurueckgeliefert.
+
+BEISPIELE
+---------
+::
+
+	Fuer eine Programmierergilde waere folgendes denkbar:
+	  SetProp(P_GUILD_MALE_TITLES,([1:"der Anfaenger",
+	                                2:"der Fortgeschrittene",
+	                                3:"der Profi"]));
+	  SetProp(P_GUILD_FEMALE_TITLES,([1:"die Anfaengerin",
+	                                  2:"die Fortgeschrittene",
+	                                  3:"die Professionelle"]));
+	Ein weibliches Gildenmitglied mit der dritten Gildenstufe und ohne
+	P_TITLE wuerde dann den Titel "die Professionelle" tragen. Das hat
+	zwar nichts mit Programmierern zu tun, aber wie heisst eigentlich
+	ein weiblicher "Profi"?! :)
+
+SIEHE AUCH
+----------
+::
+
+     P_TITLE, P_GUILD, P_GUILD_LEVEL,
+     P_GUILD_MALE_TITLES, P_GUILD_FEMALE_TITLES,
+     P_SUBGUILD_TITLE
+
+26. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_HANDS.rst b/doc/sphinx/props/P_HANDS.rst
new file mode 100644
index 0000000..c9f739d
--- /dev/null
+++ b/doc/sphinx/props/P_HANDS.rst
@@ -0,0 +1,78 @@
+P_HANDS
+=======
+
+NAME
+----
+::
+
+     P_HANDS                    "hands"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt ein dreielementiges Array mit
+     den folgenden Eintraegen:
+     1. Element: String mit der Meldung, wenn ohne Waffen angegriffen
+                 wird.
+     2. Element: Waffenklasse, wenn ohne Waffen angegriffen wird.
+     3. Element: Array mit Schadensarten (frueher auch: Schadensart)
+
+     eim Setzen dieser Property wird auch P_TOTAL_WC mit veraendert,
+     wenn das Lebewesen keine Waffe gezueckt hat. Steckt das Lebewesen
+     eine gezueckte Waffe weg, so wird ebenfalls P_TOTAL_WC mit der
+     Waffenklasse aus P_HANDS aktualisiert. Zueckt das Lebewesen eine
+     Waffe, so wird P_TOTAL_WC mit der Waffenklasse der Waffe (P_WC)
+     ueberschrieben. Die Property P_TOTAL_WC enthaelt somit immer die
+     aktuelle Angriffsstaerke des Lebewesen.
+
+BEMERKUNGEN
+-----------
+::
+
+     In alten Objekten kann es vorkommen, dass das dritte Element (Angabe des
+     Schadenstyps) fehlt. Dies ist eine Altlast, die Angabe des Schadenstypes
+     ist NICHT optional.)
+
+BEISPIEL
+--------
+::
+
+     Ein starker Tausendfuessler mit Schlagschaden:
+
+       SetProp(P_HANDS,({" mit tausend kleinen Fuesschen",1000, 
+                         ({DT_BLUDGEON}) }));
+
+
+     Ein Saeurededaemon:
+       SetProp(P_HANDS,
+         ({
+           " mit saeuretriefenden Klauen",
+           250,
+           ({DT_RIP, DT_ACID})
+         })
+       );
+
+     Hier wurden gleich zwei Schadensarten angegeben, also wird
+     Mischschaden verursacht. Man sollte es jedoch nicht zu sehr
+     uebertreiben! Mehr als zwei oder drei gleichzeitig verwendete
+     Schadensarten lassen sich kaum mehr begruenden.
+
+SIEHE AUCH
+----------
+::
+
+     P_HANDS_USED_BY
+     P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
+     UseHands, FreeHands
+     P_TOTAL_WC, P_WC
+     /std/living/combat.c, /std/weapon/combat.c, /sys/combat.h
+
+22.02.2014 Zesstra
+
diff --git a/doc/sphinx/props/P_HANDS_USED_BY.rst b/doc/sphinx/props/P_HANDS_USED_BY.rst
new file mode 100644
index 0000000..7a2c310
--- /dev/null
+++ b/doc/sphinx/props/P_HANDS_USED_BY.rst
@@ -0,0 +1,39 @@
+P_HANDS_USED_BY
+===============
+
+NAME
+----
+::
+
+     P_HANDS_USED_BY           "hands_used_by"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Enthaelt eine Liste mit den Objekten, die derzeit die Haende
+     des Livings belegen. Dabei koennen Objekte mehrmals auftauchen,
+     je nachdem wie viele Haende sie belegen.
+
+BEMERKUNGEN
+-----------
+::
+
+     Darf nur ueber UseHands() und FreeHands() manipuliert werden.
+
+SIEHE AUCH
+----------
+::
+
+     P_HANDS
+     P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
+     UseHands, FreeHands
+
+1.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/props/P_HARBOUR.rst b/doc/sphinx/props/P_HARBOUR.rst
new file mode 100644
index 0000000..a8a7515
--- /dev/null
+++ b/doc/sphinx/props/P_HARBOUR.rst
@@ -0,0 +1,96 @@
+P_HARBOUR
+=========
+
+NAME
+----
+::
+
+    P_HARBOUR                                  "harbour_name"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+    Array mit eindeutiger Bezeichnung des 'Hafens'
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Property wird in Raeumen gesetzt, die als Anleger fuer Transporter
+    dienen sollen. Sie enthaelt ein Array aus zwei Elementen, einem String
+    und einem String-Array, zum Beispiel:
+
+    ({ "zur Sonneninsel", ({"sonneninsel"}) }) oder 
+    ({ "nach Titiwu", ({"titiwu"}) })
+
+    Damit bekommt der Spieler bei einer Abfrage seiner Reiseroute mittels
+    "reise route" eine Ausgabe wie 
+      'Du reist mit dem Floss nach Titiwu' oder
+      'Du reist mit dem Wal zur Sonneninsel'.
+
+    Das zweite Element der Property enthaelt eine Liste der IDs, mit denen
+    sich der Hafen mit dem Befehl "reise nach <ID>" ansprechen laesst. Im
+    Beispiel oben wuerde also "reise nach sonneninsel" und 
+    "reise nach titiwu" akzeptiert werden. Der erste Eintrag in dieser ID-
+    Liste wird in der Ausgabe des Befehls "reise route" verwendet, sollte
+    also den Anlegeort korrekt bezeichnen und nicht z.B. eine Abkuerzung
+    enthalten.
+    Es bietet sich an, bei bestimmten, deklinierbaren Bezeichnungen alle
+    Varianten einzutragen, z.B. "verlorenes land" und zusaetzlich
+    "verlorene land" und "verlorenen land", damit alle Varianten von 
+    "reise nach ..." funktionieren.
+
+    Ist in einem Hafen diese Property nicht gesetzt, so bekommt der 
+    Spieler keinerlei Hinweis darauf, wohin ihn ein bestimmter Trans-
+    porter befoerdert. 
+    Stattdessen erhaelt er die Bezeichnung 'unbekannt'.
+
+HINWEISE
+--------
+::
+
+    Wird der zweite Parameter in dieser Property, d.h. die Liste der 
+    Anleger-IDs, nicht korrekt gesetzt, kann das dazu fuehren, dass Spieler
+    den hier anlegenden Transporter nicht benutzen koennen, weil es
+    keine sinnvolle Syntax gibt, um den gewuenschten Zielhafen zu finden.
+
+    Zu achten ist auch darauf, das der erste Eintrag unveraendert in einer 
+    Meldung an den Spieler ausgegeben wird, d.h. Gross-und Kleinschreibung
+    sollte korrekt sein.
+
+HISTORIE
+--------
+::
+
+    Frueher war der zweite Eintrag in dieser Property ein einzelner String.
+    Es existiert eine SetMethode auf dieser Property, die solche Daten in
+    altem Code auf die neue Datenstruktur umbiegt. Dies fuehrt dazu, dass
+    bei solchen Objekten die im geladenen Raum enthaltenen Daten nicht mit
+    den Daten im File uebereinstimmen. Dies moege aber bitte niemand 
+    zum Anlass nehmen, in neuem Code veraltete Daten in die Property zu 
+    schreiben!
+
+    
+
+SIEHE AUCH
+----------
+::
+
+  Properties:     P_NO_TRAVELING, P_TRAVEL_INFO
+  Funktionen:     AddRoute(L)
+  Spielerbefehle: reise
+  weitere Doku:   /d/inseln/schiffe/HowTo
+
+LETZTE AENDERUNG
+----------------
+::
+
+2015-Jan-18, Arathorn
+
diff --git a/doc/sphinx/props/P_HAUS_ERLAUBT.rst b/doc/sphinx/props/P_HAUS_ERLAUBT.rst
new file mode 100644
index 0000000..6e458e9
--- /dev/null
+++ b/doc/sphinx/props/P_HAUS_ERLAUBT.rst
@@ -0,0 +1,47 @@
+P_HAUS_ERLAUBT
+==============
+
+NAME
+----
+::
+
+    P_HAUS_ERLAUBT                "haus_erlaubt"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Hier darf ein Seherhaus abgestellt werden
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Property sollte nicht per default in Raeumen auf einen Wert > 0
+     gesetzt werden um einem Wildwuchs an Seherhaus(-ruinen) vorzubeugen.
+     Auch sei darauf geachtet, dass in Raeumen die P_INDOORS auf einen 
+     Wert > 0 haben, per default nicht gebaut werden kann.     
+     Hier lieber die Property per Hand auf 1 setzen und nach dem Aufstellen
+     des Hauses wieder loeschen.
+
+      
+
+     xcall $h->SetProp(P_HAUS_ERLAUBT,1);
+
+     Angemerkt sei noch, dass der Magier dem der Raum gehoert ueber Hausbau
+     entscheidet und nicht der Regionsmagier. In jedem Fall Ruecksprache 
+     halten falls der entsprechende Magier zumindest ab und an anwesend sein
+     sollte.
+
+     Unter /doc/beispiele/misc liegt ein File, in dem dokumentiert ist,
+     wie nach Aenderungen am Seherhaus zu verfahren ist.
+
+
+Last modified: Fri Nov 26 15:41:47 1999 by Tilly
+
diff --git a/doc/sphinx/props/P_HB.rst b/doc/sphinx/props/P_HB.rst
new file mode 100644
index 0000000..2888fcc
--- /dev/null
+++ b/doc/sphinx/props/P_HB.rst
@@ -0,0 +1,22 @@
+P_HB
+====
+
+NAME
+----
+::
+
+    P_HB                          "hb"                          
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property wird gesetzt, wenn das Monster immer einen
+     heart_beat haben soll. (VORSICHT, nur wenn es WIRKLICH sein muss!)
+
diff --git a/doc/sphinx/props/P_HEAL.rst b/doc/sphinx/props/P_HEAL.rst
new file mode 100644
index 0000000..df6ed73
--- /dev/null
+++ b/doc/sphinx/props/P_HEAL.rst
@@ -0,0 +1,50 @@
+P_HEAL
+======
+
+NAME
+----
+::
+
+     P_HEAL                        "heal"                        
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Numerischer Wert, der beim Verzehr einer Leiche zu den Lebenspunkten 
+     desjenigen hinzugezaehlt wird, der die Leiche isst. Der Wert kann auch 
+     negativ sein. Falls die Leiche den maximalen Verfallszustand erreicht 
+     hat, wird dieser Wert automatisch auf -4 gesetzt, sofern nicht schon
+     ein geringerer Wert eingetragen ist.
+
+     Werte unter -4 sind sehr sparsam und nur in begruendeten Einzelfaellen
+     zu setzen. Die Regionsmagier werden auf sinnvolle Wertebereiche in
+     ihrem Zustaendigkeitsbereich achten und ggf. Grenzwerte fuer ihre 
+     Region festlegen.
+
+     Die Gilden koennen P_HEAL abfragen und eigene, grobe Informationstexte
+     ausgeben, die den Spieler ueber den zu erwartenden Effekt beim Essen
+     einer Leiche informieren.
+
+     Positive Werte von P_HEAL sind bei der Heilungsbalance als Heilstelle
+     zu beantragen.
+
+     Fuer nicht allzu harte NPCs sollte P_HEAL auf 0 gesetzt sein. Dieser
+     Wert ist gleichzeitig der Standardwert.
+
+SIEHE AUCH
+----------
+::
+
+     /std/corpse, QueryHealInfo()
+
+     
+
+31.03.2008 Arathorn
+
diff --git a/doc/sphinx/props/P_HELPER_NPC.rst b/doc/sphinx/props/P_HELPER_NPC.rst
new file mode 100644
index 0000000..b144253
--- /dev/null
+++ b/doc/sphinx/props/P_HELPER_NPC.rst
@@ -0,0 +1,50 @@
+P_HELPER_NPC
+============
+
+NAME
+----
+::
+
+     P_HELPER_NPC             "std:helper_npc
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mit dieser Prop laesst sich herausfinden, ob ein NPC einem Spieler hilft
+    bzw. welche NPC einem Spieler helfen.
+    Wird diese Prop in einem NPC abgefragt, enthaelt sie ein Array 
+      ({ spielerobjekt, flags }) oder 0.
+    Wird diese Prop in einem Spieler abgefragt, enthaelt sie ein Mapping
+      ([npcobjekt1: flags1, npc-objekt2: flags2]).
+
+    <flags> ist ein Integer, der eine Reihe von ver-oder-ten Konstanten (s.
+    RegisterHelperNPC) enthalten kann.
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Prop wird automatisch von RegisterHelperNPC() und
+    UnregisterHelperNPC() verwaltet. Bitte aendert sie nicht per Hand.
+
+BEISPIEL
+--------
+::
+
+    s. RegisterHelperNPC().
+
+SIEHE AUCH
+----------
+::
+
+     RegisterHelperNPC(), UnregisterHelperNPC()
+
+10.03.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_HELPER_OBJECTS.rst b/doc/sphinx/props/P_HELPER_OBJECTS.rst
new file mode 100644
index 0000000..3e045b9
--- /dev/null
+++ b/doc/sphinx/props/P_HELPER_OBJECTS.rst
@@ -0,0 +1,41 @@
+P_HELPER_OBJECTS
+================
+
+NAME
+----
+::
+
+     P_HELPER_OBJECTS "lib_p_helper_objects"
+
+DEFINIERT IN
+------------
+::
+
+     <living/helpers.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt eine Liste von Hilfsobjekten, die das Lebewesen,
+     in dem sie gesetzt ist, bei bestimmten Aktivitaeten wie Tauchen oder
+     Fliegen/Segeln unterstuetzt. Die Property enthaelt ein Mapping der Form
+     ([ HELPER_TYPE : ({ Callback-Closures }) ]).
+
+BEMERKUNGEN
+-----------
+::
+
+     Externe Manipulationen an dieser Property bitte unterlassen, zum Ein-
+     und Austragen von Objekten gibt es die unten aufgefuehrten Methoden.
+
+SIEHE AUCH
+----------
+::
+
+     Methoden:    RegisterHelperObject(L), UnregisterHelperObject(L)
+     Properties:  P_AERIAL_HELPERS, P_AQUATIC_HELPERS
+
+
+18.02.2013, Arathorn
+
diff --git a/doc/sphinx/props/P_HIDE_EXITS.rst b/doc/sphinx/props/P_HIDE_EXITS.rst
new file mode 100644
index 0000000..f4733ef
--- /dev/null
+++ b/doc/sphinx/props/P_HIDE_EXITS.rst
@@ -0,0 +1,53 @@
+P_HIDE_EXITS
+============
+
+NAME
+----
+::
+
+     P_HIDE_EXITS                  "hide_exits"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/room/exits.h
+
+BESCHREIBUNG
+------------
+::
+
+     Ist diese Property in einem Raum auf einen Integerwert ungleich 0
+     gesetzt, werden einem Spieler fuer diesen Raum keine Ausgaenge angezeigt.
+     Auch der Text "Keine sichtbaren Ausgaenge." (oder so) kommt nicht.
+     Alternativ kann man auch ein array von strings uebergeben. In diesem
+     Fall werden all die Ausgaenge nicht angezeigt, deren Index in P_EXITS
+     in dem array vorkommt.
+     In diesem Fall wird ggf. der Text "Keine sichtbaren Ausgaenge."
+     ausgegeben.
+
+BEISPIEL
+--------
+::
+
+     AddExit("raus", "/ganz/wo/anders");
+     AddExit("weiter", "/in/der/naehe");
+
+     // KEINE Ausgaenge anzeigen. Noch nicht mal, dass man keine sieht.
+     SetProp(P_HIDE_EXITS, 1);
+
+     // Der Ausgang weiter wird nicht angezeigt.
+     SetProp(P_HIDE_EXITS, ({"weiter"}) );
+
+     // Keinen Ausgang zeigen, aber den Text, dass keiner sichtbar, ausgeben.
+     SetProp(P_HIDE_EXITS, ({"weiter", "raus"}) );
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	P_SHOW_EXITS
+     Sonstiges:		AddExit(), GetExits(), int_long(), int_short()
+
+25. Apr 1996 Highlander
+
diff --git a/doc/sphinx/props/P_HISTMIN.rst b/doc/sphinx/props/P_HISTMIN.rst
new file mode 100644
index 0000000..a432fde
--- /dev/null
+++ b/doc/sphinx/props/P_HISTMIN.rst
@@ -0,0 +1,21 @@
+P_HISTMIN
+=========
+
+NAME
+----
+::
+
+    P_HISTMIN                     "histmin"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Minimale Laenge, die eine Zeile haben muss, um in die History zu kommen
+
diff --git a/doc/sphinx/props/P_HIT_FUNC.rst b/doc/sphinx/props/P_HIT_FUNC.rst
new file mode 100644
index 0000000..314e294
--- /dev/null
+++ b/doc/sphinx/props/P_HIT_FUNC.rst
@@ -0,0 +1,39 @@
+P_HIT_FUNC
+==========
+
+NAME
+----
+::
+
+     P_HIT_FUNC "hit_func"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Falls ein Objekt eine HitFunc() fuer die Waffe definiert, so muss
+     dieses Objekt in dieser Property eingetragen werden.
+
+     Die Auswertung dieser Property erfolgt in QueryDamage().
+
+BEISPIELE
+---------
+::
+
+     Siehe das Beispiel zu HitFunc()
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon.c, HitFunc()
+
+
+Last modified: Sun May 19 15:37:35 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_HOMEPAGE.rst b/doc/sphinx/props/P_HOMEPAGE.rst
new file mode 100644
index 0000000..3caaf03
--- /dev/null
+++ b/doc/sphinx/props/P_HOMEPAGE.rst
@@ -0,0 +1,21 @@
+P_HOMEPAGE
+==========
+
+NAME
+----
+::
+
+    P_HOMEPAGE                    "homepage"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Die Homepage eines Spielers (mit dem Befehl 'url' zu setzen).
+
diff --git a/doc/sphinx/props/P_HP.rst b/doc/sphinx/props/P_HP.rst
new file mode 100644
index 0000000..59d30b5
--- /dev/null
+++ b/doc/sphinx/props/P_HP.rst
@@ -0,0 +1,40 @@
+P_HP
+====
+
+NAME
+----
+::
+
+    P_HP                          "hp"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     - Lebewesen
+       Anzahl der Lebenspunkte des Wesens.
+
+     - Speisen/Kneipen
+       Heilwirkung einer Portion der Speise auf die Lebenspunkte
+       des Konsumenten
+
+SIEHE AUCH
+----------
+::
+
+     Props:		P_MAX_HP
+     Veraenderung:	reduce_hit_points(), restore_hit_points()
+			do_damage(L), Defend(L)
+			buffer_hp()
+     Ueberwachung:	AddHpHook(L)
+     Speisen/Kneipen:   std/pub, wiz/food, consume
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_HP_DELAY.rst b/doc/sphinx/props/P_HP_DELAY.rst
new file mode 100644
index 0000000..444b0a7
--- /dev/null
+++ b/doc/sphinx/props/P_HP_DELAY.rst
@@ -0,0 +1,23 @@
+P_HP_DELAY
+==========
+
+NAME
+----
+::
+
+    P_HP_DELAY                 "hp_delay"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der heart_beats, bis P_HP um einen Punkt regeneriert.
+     Aenderungen dieser Property in Spielern beduerfen der 
+     Genehmigung des EM fuer Balance.
+
diff --git a/doc/sphinx/props/P_HP_HOOKS.rst b/doc/sphinx/props/P_HP_HOOKS.rst
new file mode 100644
index 0000000..ee8232b
--- /dev/null
+++ b/doc/sphinx/props/P_HP_HOOKS.rst
@@ -0,0 +1,38 @@
+P_HP_HOOKS
+==========
+
+NAME
+----
+::
+
+    P_HP_HOOKS                    "hp_hooks"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Welche Objekte sollen bei HP-Aenderungen benachrichtigt werden?
+     Diese Property bitte NICHT manipulieren! Zum Ein- und Austragen stehen
+     hierfuer AddHpHook() und RemoveHpHook() bereit.
+
+BEMERKUNGEN
+-----------
+::
+
+    Das neuere Hooksystem (s. Manpage std/hooks) stellt ebenfalls Hooks zur
+    Ueberwachung von P_HP bereit.
+
+SIEHE AUCH
+----------
+::
+
+    AddHpHook(), RemoveHpHook(),
+    NotifyHpChange()
+    std/hooks
+
diff --git a/doc/sphinx/props/P_HUNTTIME.rst b/doc/sphinx/props/P_HUNTTIME.rst
new file mode 100644
index 0000000..6b52780
--- /dev/null
+++ b/doc/sphinx/props/P_HUNTTIME.rst
@@ -0,0 +1,59 @@
+P_HUNTTIME
+==========
+
+P_HUNTTIME (int)
+----------------
+::
+
+NAME
+----
+::
+
+     P_HUNTTIME					"p_lib_hunttime"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mit dieser Property laesst sich festlegen, wie lange ein Monster einen 
+    Gegner verfolgt (also automatisch angreift), nachdem dieser geflohen ist.
+    Die Angabe erfolgt in Sekunden.
+    Die Standardzeit ist 600s (300 Heartbeats).
+
+BEMERKUNGEN
+-----------
+::
+
+    1. Wenn der Standardwert akzeptabel ist, bitte die Prop auch nicht setzen.
+    2. Enthaelt die Property keinen Integer oder ist sie <= 0, wird sie 
+       ignoriert und der Standardwert von 600s verwendet.
+    3. Kaempft man mit einem Lebenwesen mit einem groesseren Wert als man 
+       selber und man selber hat das Verfolgen eingestellt, der Gegner aber 
+       nicht, wird dieser beim Reinkommen den Kampf neu starten (und den 
+       ersten Schlag haben).
+
+BEISPIEL
+--------
+::
+
+    Ein NPC soll sich erst eine Stunde nach Flucht des Gegners beruhigen.
+    protected void create() {
+      ...
+      SetProp(P_HUNTTIME, 3600);
+    }
+
+SIEHE AUCH
+----------
+::
+
+     InsertSingleEnemy, InsertEnemy
+     /std/living/combat.c
+
+13.03.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_IDS.rst b/doc/sphinx/props/P_IDS.rst
new file mode 100644
index 0000000..7ec662d
--- /dev/null
+++ b/doc/sphinx/props/P_IDS.rst
@@ -0,0 +1,42 @@
+P_IDS
+=====
+
+NAME
+----
+::
+
+     P_IDS "ids"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property steht ein Array von den Strings, mit denen sich das
+     Objekt ansprechen laesst. Die Verwaltung dieser Property erfolgt ueber
+     die Funktionen AddId() und RemoveId().
+
+     Der Inhalt dieser Property wird von den Funktionen id() und (indirekt)
+     present() ausgewertet.
+
+BEMERKUNGEN
+-----------
+::
+
+     Man sollte an dieser Property nicht "von Hand" herumfummeln, sondern
+     immer die zugehoerigen Funktionen benutzen!
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/description.c, AddId(), RemoveId()
+
+
+Last modified: Sun May 19 20:17:36 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_IGNORE.rst b/doc/sphinx/props/P_IGNORE.rst
new file mode 100644
index 0000000..8eeae75
--- /dev/null
+++ b/doc/sphinx/props/P_IGNORE.rst
@@ -0,0 +1,40 @@
+P_IGNORE
+========
+
+NAME
+----
+::
+
+    P_IGNORE                      "ignore"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+    Array mit Spielern, Kommandos, Aktionen u.ae. die ignoriert werden.
+    In aller Regel sollte die Ignorierepruefung durch Aufruf von TestIgnore()
+    im Spieler erfolgen und nicht selber P_IGNORE durchsucht werden.
+
+BEMERKUNGEN
+-----------
+::
+
+    Die Daten in dieser Property werden intern als Mapping gespeichert, nicht
+    als Array von Strings. Bitte nicht mit Set/Query() an dieser Property
+    herumbasteln.
+
+SIEHE AUCH
+----------
+::
+
+    TestIgnore, /std/player/comm.c
+
+
+Last modified: 02.10.2011, Zesstra
+
diff --git a/doc/sphinx/props/P_INDOORS.rst b/doc/sphinx/props/P_INDOORS.rst
new file mode 100644
index 0000000..9f4f328
--- /dev/null
+++ b/doc/sphinx/props/P_INDOORS.rst
@@ -0,0 +1,52 @@
+P_INDOORS
+=========
+
+NAME
+----
+::
+
+     P_INDOORS                     "indoors"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gesetzt, wenn von dem Raum aus der Himmel nicht sichtbar ist.
+
+     Objekte oder Gilden werten diese Property teilweise aus, fuer
+     Innenraeume sollte sie also sinnvollerweise gesetzt werden.
+
+     Licht wird _nicht_ durch P_INDOORS beeinflusst, muss also
+     selbst angepasst werden.
+
+BEISPIEL
+--------
+::
+
+     // Ein dunkler Innenraum:
+     SetProp(P_INDOORS, 1);            // ein Innenraum liegt innen :)
+     SetProp(P_LIGHT, 0);              // Licht auf 0
+
+     // Ein richtig heller Aussenraum:
+     SetProp(P_INDOORS, 0);
+     SetProp(P_LIGHT, 2);
+
+     // Ein heller Aussenraum mit Mondlicht (gut fuer Delfen)
+     SetProp(P_INDOORS, 0);
+     SetProp(P_LIGHT, 1);
+     SetProp(P_LIGHT_TYPE, LT_STARS|LT_MOON);
+
+SIEHE AUCH
+----------
+::
+
+     P_LIGHT, P_LIGHT_ABSORPTION, P_LIGHT_TYPE
+
+25.Aug 2008 Gloinson
+
diff --git a/doc/sphinx/props/P_INFO.rst b/doc/sphinx/props/P_INFO.rst
new file mode 100644
index 0000000..28d9a4a
--- /dev/null
+++ b/doc/sphinx/props/P_INFO.rst
@@ -0,0 +1,38 @@
+P_INFO
+======
+
+NAME
+----
+::
+
+     P_INFO                        "info"                        
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Geheime Information, die ggf. ueber einen Zauberspruch
+     von Spielern ermittelt werden kann.
+
+     
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_INFO,"Du ergruendest das Geheimnis.\n")
+
+SIEHE AUCH
+----------
+::
+
+     GetOwner(L)
+
+24. April 2006, Vanion 
+
diff --git a/doc/sphinx/props/P_INFORMME.rst b/doc/sphinx/props/P_INFORMME.rst
new file mode 100644
index 0000000..d35316f
--- /dev/null
+++ b/doc/sphinx/props/P_INFORMME.rst
@@ -0,0 +1,30 @@
+P_INFORMME
+==========
+
+NAME
+----
+::
+
+    P_INFORMME                    "informme"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt das Flag, ob der Spieler ueber ein-/ausloggende Spieler
+    informiert werden will.
+
+SIEHE AUCH
+----------
+::
+
+    Spielerkommando: inform
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_INPC_HOME.rst b/doc/sphinx/props/P_INPC_HOME.rst
new file mode 100644
index 0000000..d1f8ac8
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_HOME.rst
@@ -0,0 +1,21 @@
+P_INPC_HOME
+===========
+
+NAME
+----
+::
+
+    P_INPC_HOME                   "inpc_home"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INPC_LAST_ENVIRONMENT.rst b/doc/sphinx/props/P_INPC_LAST_ENVIRONMENT.rst
new file mode 100644
index 0000000..b78d032
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_LAST_ENVIRONMENT.rst
@@ -0,0 +1,21 @@
+P_INPC_LAST_ENVIRONMENT
+=======================
+
+NAME
+----
+::
+
+    P_INPC_LAST_ENVIRONMENT       "inpc_last_environment"       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INPC_LAST_PLAYER_CONTACT.rst b/doc/sphinx/props/P_INPC_LAST_PLAYER_CONTACT.rst
new file mode 100644
index 0000000..5a48fe0
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_LAST_PLAYER_CONTACT.rst
@@ -0,0 +1,21 @@
+P_INPC_LAST_PLAYER_CONTACT
+==========================
+
+NAME
+----
+::
+
+    P_INPC_LAST_PLAYER_CONTACT    "inpc_last_player_contact"    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INPC_WALK_AREA.rst b/doc/sphinx/props/P_INPC_WALK_AREA.rst
new file mode 100644
index 0000000..ebdc9f0
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_WALK_AREA.rst
@@ -0,0 +1,21 @@
+P_INPC_WALK_AREA
+================
+
+NAME
+----
+::
+
+    P_INPC_WALK_AREA              "inpc_walk_area"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INPC_WALK_DELAYS.rst b/doc/sphinx/props/P_INPC_WALK_DELAYS.rst
new file mode 100644
index 0000000..b6a9e24
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_WALK_DELAYS.rst
@@ -0,0 +1,21 @@
+P_INPC_WALK_DELAYS
+==================
+
+NAME
+----
+::
+
+    P_INPC_WALK_DELAYS            "inpc_walk_delay"             
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INPC_WALK_FLAGS.rst b/doc/sphinx/props/P_INPC_WALK_FLAGS.rst
new file mode 100644
index 0000000..294fbbf
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_WALK_FLAGS.rst
@@ -0,0 +1,21 @@
+P_INPC_WALK_FLAGS
+=================
+
+NAME
+----
+::
+
+    P_INPC_WALK_FLAGS             "inpc_walk_flags"             
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INPC_WALK_MODE.rst b/doc/sphinx/props/P_INPC_WALK_MODE.rst
new file mode 100644
index 0000000..ce5f167
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_WALK_MODE.rst
@@ -0,0 +1,21 @@
+P_INPC_WALK_MODE
+================
+
+NAME
+----
+::
+
+    P_INPC_WALK_MODE              "inpc_walk_mode"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INPC_WALK_ROUTE.rst b/doc/sphinx/props/P_INPC_WALK_ROUTE.rst
new file mode 100644
index 0000000..eab8ffc
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_WALK_ROUTE.rst
@@ -0,0 +1,21 @@
+P_INPC_WALK_ROUTE
+=================
+
+NAME
+----
+::
+
+    P_INPC_WALK_ROUTE             "inpc_walk_route"             
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INTERMUD.rst b/doc/sphinx/props/P_INTERMUD.rst
new file mode 100644
index 0000000..e893d7c
--- /dev/null
+++ b/doc/sphinx/props/P_INTERMUD.rst
@@ -0,0 +1,25 @@
+P_INTERMUD
+==========
+
+NAME
+----
+::
+
+    P_INTERMUD                    "intermud"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+   Die Bedeutung dieser Property ist in den praehistorischen Untiefen
+   der Mudlib verlorengegangen.
+   Wird nicht mehr benutzt.
+   Nicht benutzen.
+   Ignorieren.
+
diff --git a/doc/sphinx/props/P_INTERNAL_EXTRA_LOOK.rst b/doc/sphinx/props/P_INTERNAL_EXTRA_LOOK.rst
new file mode 100644
index 0000000..8d07c63
--- /dev/null
+++ b/doc/sphinx/props/P_INTERNAL_EXTRA_LOOK.rst
@@ -0,0 +1,58 @@
+P_INTERNAL_EXTRA_LOOK
+=====================
+
+NAME
+----
+::
+
+	P_INTERNAL_EXTRA_LOOK			"internal_extralook"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/description.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt ein Mapping, in dem alle einzelnen
+  Extra-Look-Eintraege des Livings enthalten sind. Dabei weden die Daten von
+  AddExtraLook() und RemoveExtraLook() verwaltet. Fragt man diese Prop mit
+  QueryProp() ab, erhaelt man die Ausgabe der gueltigen Extralooks des
+  Livings. Bei Abfrage per Query() erhaelt man ein Mapping mit allen
+  Eintraegen und deren Daten. Jeder Wert im Mapping ist erneut ein Mapping, 
+  welches folgende Keys enthalten kann:
+  - "xllook": String, der im Extralook des Living angezeigt wird.
+  - "xlduration": Zeitstempel (int), der angibt, wie lang der Eintrag gueltig
+                  ist. 0 == "Unendlich", negative Zahlen besagen, dass der
+                  Eintrag nur bis Reboot/Ende gueltig sein und abs(xlduration)
+                  ist der Zeitpunkt des Eintrages dieses Extralooks.
+  - "xlende": String, der nach Ablaufen an das Living ausgegeben wird.
+  - "xlfun": Funktion, die gerufen wird und den String zurueckliefern muss, 
+             der ausgeben werden soll.
+  - "xlendefun": Funktion, die gerufen wird, wenn der Eintrag abgelaufen ist
+                 und den String zurueckliefern muss, der dann ans Living
+                 ausgeben wird.
+  - "xlobjectname": Objekt, in dem die o.a. Funktionen gerufen werden.
+
+BEMERKUNG
+---------
+::
+
+  DIESE PROPERTY BITTE NIEMALS PER HAND MIT Set()/SetProp() AENDERN!
+  Die Daten in dieser Prop werden vom Living selber verwaltet. Extralooks
+  koennen mittel AddExtraLook() eingetragen und mit RemoveExtraLook() entfernt
+  werden.
+
+SIEHE AUCH
+----------
+::
+
+  long(), /std/living/description.c, /std/player/base.c
+  AddExtraLook(), RemoveExtraLook()
+
+
+13.05.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_INT_LIGHT.rst b/doc/sphinx/props/P_INT_LIGHT.rst
new file mode 100644
index 0000000..71fb6b7
--- /dev/null
+++ b/doc/sphinx/props/P_INT_LIGHT.rst
@@ -0,0 +1,36 @@
+P_INT_LIGHT
+===========
+
+NAME
+----
+::
+
+    P_INT_LIGHT                       "int_light"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt den Lichtlevel an, der _in_ einem Objekt ist. Ein Abfragen dieser
+    Property kann z.B. in Raeumen sinnvoll sein, wenn es z.B. um das
+    aufwachen einer Eule oder einer Fledermaus geht. Zum Abfragen ob ein
+    Spieler etwas sehen kann, bitte auf jeden Fall P_PLAYER_LIGHT benutzen!
+
+    Bitte _nur_ ueber QueryProp auf diese Property zugreifen,
+    da das Lichtlevel ggf. neu berechnet werden muss!
+
+    Ein direktes setzen dieser Property ist NICHT moeglich, hierzu bitte
+    P_LIGHT benutzen!
+
+SIEHE AUCH
+----------
+::
+
+    P_LIGHT, P_TOTAL_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
+
diff --git a/doc/sphinx/props/P_INT_LONG.rst b/doc/sphinx/props/P_INT_LONG.rst
new file mode 100644
index 0000000..52a627f
--- /dev/null
+++ b/doc/sphinx/props/P_INT_LONG.rst
@@ -0,0 +1,53 @@
+P_INT_LONG
+==========
+
+NAME
+----
+::
+
+     P_INT_LONG                    "int_long"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Enthaelt Beschreibung, die man bekommt, wenn man sich in dem
+     Container (jeder Raum ist einer) umschaut als String.
+
+     Der Text sollte bereits umgebrochen sein.
+
+     Diese Property bestimmt die Ansicht des Containers von innen.
+     Fuer die Aussen(lang)ansicht muss P_LONG benutzt werden.
+
+BEMERKUNGEN
+-----------
+::
+
+     - Beschreibungen fuer etwaige Tueren im Raum werden in int_long()
+       hinzugefuegt. (Frueher wurde dies in einer Querymethode auf diese Prop
+       gemacht.)
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_INT_LONG, break_string(
+      "Du stehst in einem total spannenden Testraum. Seine absolute "
+      "Nichtigkeit erfuellt dich mit ehrfuerchtigem Grauen.",78));
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	P_INT_SHORT
+     Sonstiges:		int_long(), P_LONG
+			process_string(), break_string()
+
+04.06.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_INT_SHORT.rst b/doc/sphinx/props/P_INT_SHORT.rst
new file mode 100644
index 0000000..8a0d866
--- /dev/null
+++ b/doc/sphinx/props/P_INT_SHORT.rst
@@ -0,0 +1,57 @@
+P_INT_SHORT
+===========
+
+NAME
+----
+::
+
+     P_INT_SHORT			"int_short"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt die Innen-Kurzbeschreibung des Containers
+     als String oder Closure (mit String-Rueckgabewert).
+
+     Container sind hierbei z.B. Raeume.
+     ACHTUNG: Die Kurzbeschreibung sollte dabei weder mit einem
+	      Satzzeichen noch mit einem "\n" abgeschlossen sein
+	      (dies wird von den zustaendigen Funktionen erledigt).
+
+     Man sollte die Property nicht auf 0 setzen.
+
+     Diese Property bestimmt die Ansicht des Containers von innen.
+     Fuer die Aussen(kurz)ansicht muss P_SHORT benutzt werden.
+
+BEMERKUNGEN
+-----------
+::
+
+     - int_short() (bei Bewegung) filtert P_INT_SHORT durch process_string()
+       -> daher sind Closures moeglich
+
+BEISPIELE
+---------
+::
+
+     // ein Gang sieht natuerlich so aus
+     SetProp(P_INT_SHORT, "Ein Gang");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	P_INT_LONG
+     Sonstiges:		int_short(), P_SHORT
+			process_string(), break_string()
+
+
+Last modified: Thu May 31 15:34:05 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_INVIS.rst b/doc/sphinx/props/P_INVIS.rst
new file mode 100644
index 0000000..1bd50b2
--- /dev/null
+++ b/doc/sphinx/props/P_INVIS.rst
@@ -0,0 +1,66 @@
+P_INVIS
+=======
+
+NAME
+----
+::
+
+     P_INVIS                       "invis"                       
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Die Property P_INVIS dient dazu, Objekte als unsichtbar zu kennzeichnen.
+     Hierbei versucht P_INVIS die moeglichen Interaktionen mit Spielern zu
+     minimieren (im Gegensatz zu einer fehlenden P_SHORT, welche das Objekt
+     nur einfach nicht-sichtbar macht).
+
+     
+
+     Man sollte drei Arten von unsichtbaren Objekten unterscheiden:
+
+     - Gegenstaende
+       Setzt man P_INVIS auf eine Zahl ungleich 0, wird der Gegenstand
+       unsichtbar und der Name zu "etwas". Zusaetzlich koennen Spieler ihn
+       nicht mehr ansprechen, d.h. nehmen, wegwerfen, weitergeben etc.
+       (Bei magier-eigenen Kommandos ist dies evtl. nicht umgesetzt...)
+       Setzt man P_SHORT auf 0, wird der Gegenstand nur nicht mehr in
+       der Inventarliste von Behaeltern/Raeumen angezeigt, er behaelt aber
+       seinen Namen und ist durch Spieler ansprechbar, wenn sie eine ID
+       kennen.
+
+     - NPCs
+       Bei gesetztem P_INVIS wird der NPC unsichtbar und sein Name wird zu
+       "Jemand". Zusaetzlich koennen Spieler ihn nicht mehr ansprechen, z.B.
+       toeten oder knuddeln.
+       (Bei magier-eigenen Kommandos ist dies evtl. nicht umgesetzt...)
+       Setzt man P_SHORT auf 0, wird der NPC nur nicht mehr in der
+       Inventarliste von Behaeltern/Raeumen angezeigt, er behaelt aber seinen
+       Namen und ist durch Spieler ansprechbar, wenn sie eine ID kennen. Auch
+       angreifen und kaempfen ist moeglich.
+
+     
+
+     - Magier
+       Magier macht man unsichtbar, indem man ihnen die Property P_INVIS auf
+       einen Wert <> 0 setzt.
+       *  Spieler duerfen nicht unsichtbar gemacht werden!               *
+       *  Wird ein Magier unsichtbar gemacht, muss man ihm die Property	 *
+       *  P_INVIS auf den Wert setzen, den die Property P_AGE zu diesem	 *
+       *  Zeitpunkt hat (keine F_QUERY_METHOD !).				                 *
+       Setzt man die Property auf den Wert 1, so erhaelt ein Spieler,
+       wenn er den entsp. Magier fingert, die Ausgabe: Alter: 00:00:02,
+       was genauso verraeterisch ist, wie ein Alter, dass bei einem
+       scheinbar nicht eingeloggten Magier immer weiter hochgezaehlt
+       wird.
+
+
+27.05.2015, Zesstra
+
diff --git a/doc/sphinx/props/P_IP_NAME.rst b/doc/sphinx/props/P_IP_NAME.rst
new file mode 100644
index 0000000..6f655e4
--- /dev/null
+++ b/doc/sphinx/props/P_IP_NAME.rst
@@ -0,0 +1,21 @@
+P_IP_NAME
+=========
+
+NAME
+----
+::
+
+    P_IP_NAME                     "ip_name"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Rechnername des Interactives
+
diff --git a/doc/sphinx/props/P_IS_ARTILLERY.rst b/doc/sphinx/props/P_IS_ARTILLERY.rst
new file mode 100644
index 0000000..d66be6e
--- /dev/null
+++ b/doc/sphinx/props/P_IS_ARTILLERY.rst
@@ -0,0 +1,31 @@
+P_IS_ARTILLERY
+==============
+
+NAME
+----
+::
+
+	P_IS_ARTILLERY			"artillery"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	Is ein Objekt Artillerie, so muss diese Property
+	gesetzt sein. (Derzeit einfach auf 1 setzen.)
+
+SIEHE AUCH
+----------
+::
+
+	artillerie
+
+
+Last modified: Sam,  5. Jul 2003, 22:07:12 by Zook.
+
diff --git a/doc/sphinx/props/P_ITEMS.rst b/doc/sphinx/props/P_ITEMS.rst
new file mode 100644
index 0000000..3e4bbd8
--- /dev/null
+++ b/doc/sphinx/props/P_ITEMS.rst
@@ -0,0 +1,22 @@
+P_ITEMS
+=======
+
+NAME
+----
+::
+
+    P_ITEMS                       "items"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Definition von Gegenstaenden, die in dem Raum liegen sollen.
+     Erklaerung in einem Extrafile.
+
diff --git a/doc/sphinx/props/P_I_HATE_ALCOHOL.rst b/doc/sphinx/props/P_I_HATE_ALCOHOL.rst
new file mode 100644
index 0000000..5e44b86
--- /dev/null
+++ b/doc/sphinx/props/P_I_HATE_ALCOHOL.rst
@@ -0,0 +1,42 @@
+P_I_HATE_ALCOHOL
+================
+
+NAME
+----
+::
+
+    P_I_HATE_ALCOHOL                        "i_hate_alcohol"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/boozing.h
+
+BESCHREIBUNG
+------------
+::
+
+    Numerischer Wert, der die Obergrenze an P_ALCOHOL in einem Monster
+    definiert, welcher beim eigenstaendigen Tanken beruecksichtigt wird.
+
+BEMERKUNG
+---------
+::
+
+    Geht der Npc (und nur fuer solche ist diese Prop gedacht) eigen-
+    staendig tanken, werden vor dem Bestellen die Getraenke und Speisen
+    auf ihren Alkoholgehalt geprueft und mit dem aktuellen Wert von
+    P_ALCOHOL im Verhaeltnis zu P_I_HATE_ALCOHOL verglichen. Laege der
+    Wert fuer P_ALCOHOL dann ueber dem von P_I_HATE_ALCOHOL, wird dieses
+    Getraenk (diese Speise) nicht bestellt.
+
+SIEHE AUCH
+----------
+::
+
+     P_ALCOHOL, P_MAX_ALCOHOL
+
+
+Last modified: Sam Apr 14 12:35:00 2001 by Tilly
+
diff --git a/doc/sphinx/props/P_KEEPER.rst b/doc/sphinx/props/P_KEEPER.rst
new file mode 100644
index 0000000..3b60a47
--- /dev/null
+++ b/doc/sphinx/props/P_KEEPER.rst
@@ -0,0 +1,27 @@
+P_KEEPER
+========
+
+NAME
+----
+::
+
+    P_KEEPER                       "shop_keeper"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    In diese Property kann man in Kneipen und Laeden einen String schreiben.
+    Dann wird vor den Transaktionen geprueft, ob ein NPC anwesend ist,
+    der diesen String als ID hat.
+    Ist der NPC nicht vorhanden, kann nichts ge- oder verkauft werden.
+
+
+Last modified: Mon Aug 23 14:29:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/props/P_KEEP_ON_SELL.rst b/doc/sphinx/props/P_KEEP_ON_SELL.rst
new file mode 100644
index 0000000..d7897e8
--- /dev/null
+++ b/doc/sphinx/props/P_KEEP_ON_SELL.rst
@@ -0,0 +1,21 @@
+P_KEEP_ON_SELL
+==============
+
+NAME
+----
+::
+
+    P_KEEP_ON_SELL                "keep_on_sell"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Bei "verkaufe alles" wird das Objekt behalten.
+
diff --git a/doc/sphinx/props/P_KILLER.rst b/doc/sphinx/props/P_KILLER.rst
new file mode 100644
index 0000000..7bb462d
--- /dev/null
+++ b/doc/sphinx/props/P_KILLER.rst
@@ -0,0 +1,46 @@
+P_KILLER
+========
+
+NAME
+----
+::
+
+    P_KILLER                      "killer"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+   Diese Property enthaelt das Objekt, welches das Lebewesen als letztes
+   getoetet hat. Sie wird von do_damage(), heart_beat() (Vergiftungen) und
+   die() (bei direkten Aufrufen) automatisch gesetzt. Ein manuelles
+   Setzen vor Aufruf von do_damage() oder die() hat keinerlei Wirkung!
+   Sinnvollerweise liest man diese Property im NotifyPlayerDeath() aus,
+   spaeteres Auslesen ist unzuverlaessig, da der Killer inzwischen zerstoert
+   sein koennte.
+   Diese Property sollte _nicht_ per Hand gesetzt werden, schon gar nicht
+   waehrend eines NotifyPlayerDeath(), weil es evtl. noch andere Objekte gibt,
+   die sich dafuer interessieren!
+
+BEMERKUNGEN
+-----------
+::
+
+   Normalerweise steht hier ein Objekt drin (s.o.). Es gibt allerdings eine
+   Ausnahme: Stirbt ein Lebewesen an Gift, enthaelt P_KILLER den String
+   "gift".
+
+SIEHE AUCH
+----------
+::
+
+   do_damage()
+
+29.08.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_KILLS.rst b/doc/sphinx/props/P_KILLS.rst
new file mode 100644
index 0000000..6a4a73a
--- /dev/null
+++ b/doc/sphinx/props/P_KILLS.rst
@@ -0,0 +1,23 @@
+P_KILLS
+=======
+
+NAME
+----
+::
+
+    P_KILLS                       "playerkills"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der Spieler, die dieser Spieler schon getoetet hat.
+     Unerlaubte Manipulation ist ein SCHWERES VERGEHEN gegen
+     die Mudreglen.
+
diff --git a/doc/sphinx/props/P_KILL_MSG.rst b/doc/sphinx/props/P_KILL_MSG.rst
new file mode 100644
index 0000000..5b5d0ba
--- /dev/null
+++ b/doc/sphinx/props/P_KILL_MSG.rst
@@ -0,0 +1,97 @@
+P_KILL_MSG
+==========
+
+NAME
+----
+::
+
+	P_KILL_MSG			"kill_msg"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn ein Spieler getoetet wird, so erscheint dazu eine kurze Information
+     auf dem Todeskanal. Um dem toetenden Objekt zusaetzlich die Moeglichkeit
+     zu geben, noch etwas mehr auf diesem Kanal auszugeben, kann man in
+     dieser Property einen String uebergeben.
+     Noetige Zeilenumbrueche werden hierbei automatisch generiert.
+
+     Es ist auch moeglich anzugeben, ob Emotes verwendet werden und ob das
+     toetende Objekt ein Plural-Objekt ist. Hierzu uebergibt man ein Array
+     der Gestalt:
+
+	({Killmessage,Emotes}) bzw. ({Killmessage,Emotes,PLURAL})
+
+     Der Eintrag <Killmessage> stellt hierbei die Meldung selbst dar, PLURAL
+     gibt an, dass es sich um ein Plural-Objekt handelt und <Emotes> kann
+     folgende Werte annehmen:
+
+	MSG_SAY    - Meldung wird normal ausgegeben.
+	MSG_EMOTE  - Meldung erscheint als Emote.
+	MSG_GEMOTE - Meldung erscheint als Genitiv-Emote.
+	MSG_EMPTY  - Meldung erscheint ohne zuvorige Angabe des
+	               toetenden Objektes.
+
+     Moechte man die Meldung noch etwas "persoenlicher" ;-) gestalten, so
+     kann man den Platzhalter %s verwenden. An dessen Stelle wird dann der
+     Name des Verblichenen eingesetzt.
+
+BEISPIEL
+--------
+::
+
+     Ein nettes Beispiel ist das folgende: Wenn ein Spieler sich als
+     Drachentoeter bewehrt hat, so kann er traditionell in seinem Blut baden.
+     Hin und wieder ist jedoch auch der Drache erfolgreich, dem man eine
+     lustige Zusatzmeldung fuer den Todeskanal uebergeben kann:
+
+     void create() {
+       ::create();
+       ...
+       SetProp(P_KILL_MSG,"Jetzt bade ich mal in DEINEM Blut, %s!");
+       ...
+     }
+
+
+     Falls der 'Killer' ein Plural-Objekt oder -NPC war, koennte eine Meldung
+     auch folgendermassen aussehen:
+
+     SetProp(P_KILL_MSG,({"haun sich jetzt die Hucke voll.",
+			  MSG_EMOTE,
+			  PLURAL}));
+
+     wobei P_KILL_NAME hier natuerlich auf "Eine Menge Orks" oder
+     dergleichen gesetzt sein sollte. Auf dem Kanal waere dann dies zu
+     lesen:
+
+	[Tod:Lars] Eine Menge Orks haben gerade Orktoeter umgebracht.
+	[Tod:Eine Menge Orks haun sich jetzt die Hucke voll.]
+
+
+     Weiteres Beispiel.
+     Man habe einen NPC, dessen Killname als Plural aufzufassen ist, der aber
+     keinen zusaetlichen Text auf -Tod bringen soll.
+
+     SetProp(P_NAME, "Eine Horde Gummibaeren");
+     SetProp(P_KILL_NAME, "Viele kleine Gummibaeren");
+     SetProp(P_KILL_MSG, ({0, 0, 1}));
+
+SIEHE AUCH
+----------
+::
+
+     Tod:		die(L)
+     Todesmeldungen:	P_KILL_NAME, P_DIE_MSG, P_MURDER_MSG
+			P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
+     Sonstiges:		P_CORPSE, P_NOCORPSE, /room/death/death_room.c
+
+
+Last modified: Wed Aug 21 14:36:04 2002 by Bambi
+
diff --git a/doc/sphinx/props/P_KILL_NAME.rst b/doc/sphinx/props/P_KILL_NAME.rst
new file mode 100644
index 0000000..b730b67
--- /dev/null
+++ b/doc/sphinx/props/P_KILL_NAME.rst
@@ -0,0 +1,60 @@
+P_KILL_NAME
+===========
+
+NAME
+----
+::
+
+     P_KILL_NAME			"kill_name"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn ein Spieler getoetet wird, so erscheint eine kurze Information auf
+     dem Todeskanal. Im Normalfall werden die Informationen aus P_NAME,
+     P_ARTICLE und P_GENDER des toetenden Objektes verwendet, um einen Namen
+     fuer eben dieses Objekt zu kreieren. Manchmal moechte man jedoch einen
+     davon unabhaengigen Namen dort stehen haben. Dann kommt die Property
+     P_KILL_NAME zum Einsatz.
+     Man sollte beachten, dass der Name des Toetenden nicht zu lang sein
+     sollte, denn obwohl bei einer Todesmeldung automatisch umgebrochen wird,
+     kann es doch ziemlich stoeren. Wenn das toetende Objekt ein Plural-
+     Objekt ist, so kann man dies zusaetzlich in der Property P_KILL_MSG
+     angeben.
+
+BEISPIEL
+--------
+::
+
+     Eine Wolke, die wahlweise zwischen verschiedenen Zustaenden mutiert,
+     koennte mal eine Eiswolke, mal eine Giftwolke oder auch mal eine
+     Feuerwolke sein. Fuer den Todeskanal soll jedoch immer erscheinen:
+     '[Tod:] Eine mutierende Wolke hat gerade <Spieler> umgebracht.'
+
+     void create()
+     {
+       ::create();
+       ...
+       SetProp(P_KILL_NAME,"Eine mutierende Wolke");
+       ...
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Tod:		die(L)
+     Todesmeldungen:	P_KILL_MSG, P_DIE_MSG, P_MURDER_MSG
+			P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
+     Sonstiges:		P_CORPSE, P_NOCORPSE, /room/death/death_room.c
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_KNOWN_POTIONROOMS.rst b/doc/sphinx/props/P_KNOWN_POTIONROOMS.rst
new file mode 100644
index 0000000..b38f796
--- /dev/null
+++ b/doc/sphinx/props/P_KNOWN_POTIONROOMS.rst
@@ -0,0 +1,35 @@
+P_KNOWN_POTIONROOMS
+===================
+
+NAME
+----
+::
+
+    P_KNOWN_POTIONROOMS                 "known_potionrooms"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/potion.h
+
+BESCHREIBUNG
+------------
+::
+
+    Array mit den Nummern der Raeume, in denen der Spieler Zauber-
+    traenke finden kann. Die Zuordnung der Raeume und Nummern
+    geschieht im Potionmaster.
+
+    Nur lesbare _query - Property.
+
+SIEHE AUCH
+----------
+::
+
+    Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
+    Verwandt:  FindPotion(), AddKnownPotion(), RemoveKnownPotion(), InList()
+    Props:     P_POTIONROOMS
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_LASTDIR.rst b/doc/sphinx/props/P_LASTDIR.rst
new file mode 100644
index 0000000..a692dbb
--- /dev/null
+++ b/doc/sphinx/props/P_LASTDIR.rst
@@ -0,0 +1,28 @@
+P_LASTDIR
+=========
+
+NAME
+----
+::
+
+    P_LASTDIR                  "p_lib_lastdir"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/shells.h
+
+BESCHREIBUNG
+------------
+::
+
+    Das jeweils letzte Verzeichnis, in dem der Magier war.
+    (Nur fuer Magier von Belang)
+
+Siehe auch:
+    P_CURRENTDIR
+
+Letzte Aenderung:
+    03.05.2016, Zesstra
+
diff --git a/doc/sphinx/props/P_LAST_COMBAT_TIME.rst b/doc/sphinx/props/P_LAST_COMBAT_TIME.rst
new file mode 100644
index 0000000..0dbc5ed
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_COMBAT_TIME.rst
@@ -0,0 +1,39 @@
+P_LAST_COMBAT_TIME
+==================
+
+NAME
+----
+::
+
+	P_LAST_COMBAT_TIME		"last_combat_time"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property wird genau die Zeit festgehalten, zu der ein
+	Lebewesen zuletzt einen Angriff abgewehrt oder einen Angriff
+	durchgefuehrt hat. Die Property enthaelt diese Information hierbei
+	immer in Form eines Integerwertes.
+	Dieser Wert koennte z.B. wichtig sein, wenn man wissen moechte, wann
+	ein Lebewesen zuletzt gekaempft hat. Es ist beispielsweise nicht
+	moeglich, waehrend oder auch unmittelbar nach einem Kampf den Befehl
+	'Ende' zu nutzen, da dies zur Flucht missbraucht werden kann. Dafuer
+	wird der Wert der Property zuvor ausgewertet.
+
+SIEHE AUCH
+----------
+::
+
+	P_LAST_DAMTIME, P_LAST_DAMAGE, P_LAST_DAMTYPES, Attack(), Defend(),
+	/std/living/combat.c, /std/living/life.c
+
+
+Last modified: Wed May 26 16:43:00 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_LAST_COMMAND_ENV.rst b/doc/sphinx/props/P_LAST_COMMAND_ENV.rst
new file mode 100644
index 0000000..e7f2636
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_COMMAND_ENV.rst
@@ -0,0 +1,30 @@
+P_LAST_COMMAND_ENV
+==================
+
+NAME
+----
+::
+
+    P_LAST_COMMAND_ENV            "last_command_env"            
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Der Raum, in dem das letzte Kommando eingegeben wurde.
+
+BEMERKUNGEN
+-----------
+::
+
+     Keine echte Property, _query_last_command_env() ist
+     in /std/players/command.c implementiert.
+
+14.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/props/P_LAST_CONTENT_CHANGE.rst b/doc/sphinx/props/P_LAST_CONTENT_CHANGE.rst
new file mode 100644
index 0000000..3fcf1de
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_CONTENT_CHANGE.rst
@@ -0,0 +1,32 @@
+P_LAST_CONTENT_CHANGE
+=====================
+
+NAME
+----
+::
+
+    P_LAST_CONTENT_CHANGE         "last_content_change"         
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wann wurde zum letzten Mal was ins Obj gestopft oder rausgenommen?
+     Wichtig fuer den Weight-Cache
+
+ANMERKUNG
+---------
+::
+
+     Die Property kann nur ueber QueryProp() und SetProp() ausgelesen bzw.
+     gesetzt werden. Query() und Set() funktionieren *nicht*.
+
+     Ausserdem fuehrt ein Setzen per SetProp() zu einer Erhoehung des 
+     Wertes um eins - unabhaengig vom gesetzten Wert.
+
diff --git a/doc/sphinx/props/P_LAST_DAMAGE.rst b/doc/sphinx/props/P_LAST_DAMAGE.rst
new file mode 100644
index 0000000..332b729
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_DAMAGE.rst
@@ -0,0 +1,38 @@
+P_LAST_DAMAGE
+=============
+
+NAME
+----
+::
+
+	P_LAST_DAMAGE			"last_damage"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property wird genau die Schadensstaerke festgehalten,
+	welche ein Lebewesen zuletzt abbekommen hat. Die Property enthaelt
+	diese Information hierbei immer in Form eines Integerwertes.
+	Auch die Staerke des Giftschadens durch die Wirkung einer Vergiftung
+	wird hier festgehalten.
+	Dieser Wert koennte z.B. wichtig sein, wenn man wissen moechte,
+	welche Schadensstaerke nach Einwirkung von Defendern, Ruestung,
+	Hooks und Skills uebriggeblieben ist.
+
+SIEHE AUCH
+----------
+::
+
+	P_LAST_DAMTIME, P_LAST_DAMTYPES, Defend(),
+	/std/living/combat.c, /std/living/life.c
+
+
+Last modified: Tue Jan 26 12:34:29 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_LAST_DAMTIME.rst b/doc/sphinx/props/P_LAST_DAMTIME.rst
new file mode 100644
index 0000000..d4c499f
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_DAMTIME.rst
@@ -0,0 +1,38 @@
+P_LAST_DAMTIME
+==============
+
+NAME
+----
+::
+
+	P_LAST_DAMTIME			"last_damtime"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property wird genau die Zeit festgehalten, zu der ein
+	Lebewesen zuletzt einen Schaden abbekommen hat. Die Property
+	enthaelt diese Information hierbei immer in Form eines
+	Integerwertes.
+	Auch der Zeitpunkt der Einwirkung von Giftschaden durch die Wirkung
+	einer Vergiftung wird hier festgehalten.
+	Dieser Wert koennte z.B. wichtig sein, wenn man wissen moechte, wann
+	ein Lebewesen zuletzt verletzt wurde.
+
+SIEHE AUCH
+----------
+::
+
+	P_LAST_COMBAT_TIME, P_LAST_DAMAGE, P_LAST_DAMTYPES, Defend(),
+	/std/living/combat.c, /std/living/life.c
+
+
+Last modified: Wed May 26 16:44:38 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_LAST_DAMTYPES.rst b/doc/sphinx/props/P_LAST_DAMTYPES.rst
new file mode 100644
index 0000000..e0428a0
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_DAMTYPES.rst
@@ -0,0 +1,37 @@
+P_LAST_DAMTYPES
+===============
+
+NAME
+----
+::
+
+	P_LAST_DAMTYPES			"last_damtypes"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property werden genau die Schadensarten festgehalten,
+	welche ein Lebewesen zuletzt abbekommen hat. Die Property enthaelt
+	diese Information hierbei immer in Form eines Arrays.
+	Auch der Giftschaden durch die Wirkung einer Vergiftung wird hier
+	festgehalten.
+	Dieser Wert koennte z.B. wichtig sein, wenn man nach dem Tod eines
+	Lebewesens feststellen moechte, durch was es umgekommen ist.
+
+SIEHE AUCH
+----------
+::
+
+	P_LAST_DAMAGE, P_LAST_DAMTIME, Defend(),
+	/std/living/combat.c, /std/living/life.c
+
+
+Last modified: Tue Jan 26 12:34:29 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_LAST_DEATH_PROPS.rst b/doc/sphinx/props/P_LAST_DEATH_PROPS.rst
new file mode 100644
index 0000000..8d13c41
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_DEATH_PROPS.rst
@@ -0,0 +1,32 @@
+P_LAST_DEATH_PROPS
+==================
+
+NAME
+----
+::
+
+    P_LAST_DEATH_PROPS                "last_death_props"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt nach dem Tod eines Spielers ein Mapping mit 
+     den Werte aller Properties, die im die() zurueckgesetzt werden.
+
+     Auf diese Weise kann ein Objekt auch im NotifyPlayerDeath() noch 
+     auf die Werte zurueckgreifen, obwohl sie bereits geloescht sind.
+
+     Folgende Properties werden so gesichert:
+
+   
+
+     P_POISON, P_FROG, P_ALCOHOL, P_DRINK, P_FOOD , P_BLIND, P_DEAF, 
+     P_MAX_HANDS, P_PARA, P_NO_REGENERATION , P_HP, P_SP, P_LAST_DEATH_TIME
+
diff --git a/doc/sphinx/props/P_LAST_DEATH_TIME.rst b/doc/sphinx/props/P_LAST_DEATH_TIME.rst
new file mode 100644
index 0000000..40c82b2
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_DEATH_TIME.rst
@@ -0,0 +1,21 @@
+P_LAST_DEATH_TIME
+=================
+
+NAME
+----
+::
+
+    P_LAST_DEATH_TIME                "last_death_time"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Der Zeitpunkt des letzten Todes des Spielers.
+
diff --git a/doc/sphinx/props/P_LAST_LOGIN.rst b/doc/sphinx/props/P_LAST_LOGIN.rst
new file mode 100644
index 0000000..c9b56b2
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_LOGIN.rst
@@ -0,0 +1,35 @@
+P_LAST_LOGIN
+============
+
+NAME
+----
+::
+
+    P_LAST_LOGIN                  "last_login"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zeitpunkt des letzten Logins
+
+BEMERKUNGEN
+-----------
+::
+
+     Gegen aeussere Aenderung und Set/QueryMethoden geschuetzt.
+
+SIEHE AUCH
+----------
+::
+
+     P_LAST_LOGOUT, save_me
+
+28. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_LAST_LOGOUT.rst b/doc/sphinx/props/P_LAST_LOGOUT.rst
new file mode 100644
index 0000000..d8a7843
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_LOGOUT.rst
@@ -0,0 +1,39 @@
+P_LAST_LOGOUT
+=============
+
+NAME
+----
+::
+
+    P_LAST_LOGOUT                 "last_logout"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zeitpunkt des letzten Logouts. Anhand dieser Zeit werden die Feindes-
+     listen und in Abwesenheit eingefuegte Gegenstaende aktualisiert.
+
+     Dieses Datum wird bei Magiern nicht aktualisiert, wenn sie unsichtbar
+     sind/sich unsichtbar ausloggen.
+
+BEMERKUNGEN
+-----------
+::
+
+     Gegen aeussere Aenderung und Set/QueryMethoden geschuetzt.
+
+SIEHE AUCH
+----------
+::
+
+     P_LAST_LOGIN, P_INVIS, save_me, init, StopHuntFor
+
+28. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_LAST_MOVE.rst b/doc/sphinx/props/P_LAST_MOVE.rst
new file mode 100644
index 0000000..af703cc
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_MOVE.rst
@@ -0,0 +1,37 @@
+P_LAST_MOVE
+===========
+
+NAME
+----
+::
+
+	P_LAST_MOVE			"last_move"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property wird die Zeit der letzten Bewegung eines
+	Lebewesens festgehalten. Selbsterklaerend ist auch der dazugehoerige
+	Quellcode innerhalb move() in '/std/living/moving.c':
+	  SetProp(P_LAST_MOVE,time());
+	Wichtig ist diese Property insbesondere fuer die Unterbindung von
+	Rein-Angriff-Raus-Taktiken. Dieser Modus ist standardmaessig in jedem
+	NPC aktiviert und kann ueber die Property P_ENABLE_IN_ATTACK_OUT
+	ausgeschalten werden.
+
+SIEHE AUCH
+----------
+::
+
+	move(), time(), P_ENABLE_IN_ATTACK_OUT, /std/living/moving.c
+
+
+Last modified: Sat Jan 30 12:53:00 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_LAST_USE.rst b/doc/sphinx/props/P_LAST_USE.rst
new file mode 100644
index 0000000..98d674f
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_USE.rst
@@ -0,0 +1,34 @@
+P_LAST_USE
+==========
+
+NAME
+----
+::
+
+     P_LAST_USE "last_use"
+
+DEFINIERT IN
+------------
+::
+
+     <properties.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property wird in Ruestungen und Waffen dazu benutzt um
+     festzuhalten, wann die Ruestung/Waffe zuletzt im Kampf benutzt
+     wurde.
+
+SIEHE AUCH
+----------
+::
+
+     Ruestungen:	QueryDefend(L)
+     Waffen:		QueryDamage(L)
+     Sonstiges:		P_EQUIP_TIME, P_UNWIELD_TIME
+
+
+Last modified: Fri Feb 06 10:15:00 1998 by Paracelsus
+
diff --git a/doc/sphinx/props/P_LAST_WEAR_ACTION.rst b/doc/sphinx/props/P_LAST_WEAR_ACTION.rst
new file mode 100644
index 0000000..ae568ba
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_WEAR_ACTION.rst
@@ -0,0 +1,31 @@
+P_LAST_WEAR_ACTION
+==================
+
+PROPERTY
+--------
+::
+
+	P_LAST_WEAR_ACTION    "last_wear_action"
+
+DEFINIERT IN: 
+
+	/sys/armour.h (und damit auch in properties.h)
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Prop gibt an, welche An/Auszieh-Aktion ein Spieler zuletzt
+	durchgefuehrt hat. Sie ist ein zweielementiges Array, wobei der
+	erste Eintrag angibt, ob der Spieler sich an- oder ausgezogen
+	hat (WA_WEAR, WA_UNWEAR, auch in armour.h definiert) und der
+	zweite den Zeitpunkt.
+
+	Die Property wird (unter anderem?) dafuer verwendet festzustellen ob
+	der Spieler in der letzten Runde schon einen Ruestungswechsel
+	vorgenommen hat und einen entgegengesetzten zu unterbinden.
+
+LETZTE AENDERUNG: 
+
+2003-01-29, 17:30 von Humni
+
diff --git a/doc/sphinx/props/P_LAST_XP.rst b/doc/sphinx/props/P_LAST_XP.rst
new file mode 100644
index 0000000..f69b8ab
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_XP.rst
@@ -0,0 +1,43 @@
+P_LAST_XP
+=========
+
+NAME
+----
+::
+
+    P_LAST_XP                        "last_xp"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+    Ein Array vom Typ ({ pfad, xp }).
+
+    Der Eintrag "pfad" gibt das Gebiet an, in dem ein Spieler zuletzt XP
+    bekommen hat. Dabei wird aus "/d/ebene/magier/room/raum1.c" dann
+    "/d/ebene/magier/room".
+
+    Der Wert "xp" zeigt an, wieviele XP der Spieler _in diesem Gebiet_
+    gesammelt hat. Sobald er auch nur einen XP in einem anderen Gebiet
+    bekommt, zeigt P_LAST_XP nur noch diesen neu erhaltenen XP an.
+
+    Der Anwendungszweck waere z.B. eine Heilstelle, die nur dann Wirkung
+    zeigt, wenn der Spieler wirklich in dem betreffenden Gebiet gemetzelt hat
+    und nicht nur zum Tanken hergerannt ist oder eine Unterscheidung, ob
+    jemand metzelt oder nur uebt (ueber die XP).
+
+SIEHE AUCH
+----------
+::
+
+     Funktionen:  AddExp()
+     Verwandt:    P_NO_XP, P_XP
+
+14.Feb 2007 Gloinson
+
diff --git a/doc/sphinx/props/P_LEAVECMDS.rst b/doc/sphinx/props/P_LEAVECMDS.rst
new file mode 100644
index 0000000..7931548
--- /dev/null
+++ b/doc/sphinx/props/P_LEAVECMDS.rst
@@ -0,0 +1,58 @@
+P_LEAVECMDS
+===========
+
+NAME
+----
+::
+
+    P_LEAVECMDS                   "leavecmds"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+    Ein Array mit Befehlen, die zum Verlassen des Transporters fuehren. 
+
+BEISPIEL
+--------
+::
+
+    SetProp(P_LEAVECMDS,({ "verlass","verlasse" }) );
+
+    Gibt der Spieler nun 'verlasse xxx' ein, so sorgt /std/transport.c 
+    dafuer, das der Spieler auch von oder aus dem Transporter bewegt 
+    wird. Vorausgesetzt natuerlich, er ist an einem Haltepunkt angelangt.
+
+BEMERKUNGEN
+-----------
+::
+
+    Um /std/transport.c nicht aufzublaehen, werden weitere Argumente wie
+    etwa 'verlasse das|die|den xxx' _nicht_ unterstuetzt!
+
+    Hier muss der verantwortliche Magier schon eine eigene Loesung finden
+    und in seinen Transporter schreiben.
+
+    Sollen Kommandos zum Betreten UND Verlassen eines Transporters ver-
+    wendet werden koennen, muessen diese in P_TRAVEL_CMDS gesetzt werden.
+
+SIEHE AUCH
+----------
+::
+
+    P_LEAVEFAIL, P_ENTERFAIL, P_ENTERCMDS, P_TRAVEL_CMDS, transporter,
+
+LETZTE AENDERUNG
+----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
+    
+
diff --git a/doc/sphinx/props/P_LEAVEFAIL.rst b/doc/sphinx/props/P_LEAVEFAIL.rst
new file mode 100644
index 0000000..9af4941
--- /dev/null
+++ b/doc/sphinx/props/P_LEAVEFAIL.rst
@@ -0,0 +1,50 @@
+P_LEAVEFAIL
+===========
+
+NAME
+----
+::
+
+    P_LEAVEFAIL                   "leavefail"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Spieler, wenn er ausserhalb der Anlegezeiten einen 
+     Transporter verlassen will. Ist die Propertie ein Array, so wird 
+     das erste Element als Meldung an den Spieler, das zweite als 
+     Meldung an die Mitspieler im Transporter geschickt. Ist der Eintrag
+     dagegen ein simpler String, so wird die Meldung nur an den Spieler
+     ausgegeben.
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_LEAVEFAIL, "Die Wildgaense fliegen viel zu hoch" );
+
+     SetProp(P_LEAVEFAIL, ({ "Die Wildgaense fliegen viel zu hoch",
+                             "versucht, vom Ruecken der Wildgans zu "
+                            +"klettern und besinnt sich dann doch" }) );
+
+                             
+
+SIEHE AUCH
+----------
+::
+
+     P_LEAVEMSG, P_ENTERMSG, P_ENTERFAIL, transporter
+
+LETZTE AENDERUNG
+----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
diff --git a/doc/sphinx/props/P_LEAVEMSG.rst b/doc/sphinx/props/P_LEAVEMSG.rst
new file mode 100644
index 0000000..3253e77
--- /dev/null
+++ b/doc/sphinx/props/P_LEAVEMSG.rst
@@ -0,0 +1,38 @@
+P_LEAVEMSG
+==========
+
+NAME
+----
+::
+
+    P_LEAVEMSG                    "leavemsg"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+     Array mit zwei Meldungen. Der erste Eintrag wird an den Transporter
+     ausgegeben, der zweite an den Raum in den der Spieler kommt.
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_LEAVEMSG, ({ "klettert vom Ruecken der Wildgans",
+                            "kommt vom Ruecken einer Wildgans herunter" }) );
+
+SIEHE AUCH: 
+     P_ENTERMSG, P_LEAVEFAIL, P_ENTERFAIL, transporter
+
+LETZTE AENDERUNG
+----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
diff --git a/doc/sphinx/props/P_LEP.rst b/doc/sphinx/props/P_LEP.rst
new file mode 100644
index 0000000..afca4cb
--- /dev/null
+++ b/doc/sphinx/props/P_LEP.rst
@@ -0,0 +1,22 @@
+P_LEP
+=====
+
+NAME
+----
+::
+
+    P_LEP                         "lep"                         
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Levelpunkte eines Spielers
+     NICHT VON HAND SETZEN!!!
+
diff --git a/doc/sphinx/props/P_LEVEL.rst b/doc/sphinx/props/P_LEVEL.rst
new file mode 100644
index 0000000..8cbe8f8
--- /dev/null
+++ b/doc/sphinx/props/P_LEVEL.rst
@@ -0,0 +1,48 @@
+P_LEVEL
+=======
+
+NAME
+----
+::
+
+    P_LEVEL                       "level"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Spieler-Level (!= Magierlevel)
+
+     In Krankheits- (CL_DISEASE) und Giftobjekten (CL_POISON) drueckt 
+     P_LEVEL aus, wie schwer die Krankheit/das Gift ist. Je nachdem, wie 
+     hoch oder niedrig der Level gesetzt wird, muss z.B. ein Kleriker mehr 
+     oder weniger oft kurieren, um  eine (ggf. stufenweise) Heilung zu 
+     bewirken.
+
+     In Fluchobjekten (CL_CURSE) gibt P_LEVEL ebenfalls die Schwere des
+     Fluches an, jedoch ist hier zu beachten, dass z.B. Kleriker aktuell
+     keine stufenweise Schwaechung bewirken koennen, sondern entweder den
+     Fluch entfernen koennen oder komplett scheitern. 
+     Der Fluchlevel ist hier grob als Chance des Scheiterns in einem 
+     Wertebereich von 1-100 zu sehen, was bedeutet, dass ein Fluchlevel 
+     von 100 als permanenter, nicht entfernbarer Fluch anzusehen ist.
+
+     Genaueres ist in der Klerusgilde nachzulesen oder beim GM Klerus zu
+     erfragen.
+
+SIEHE AUCH
+----------
+::
+
+     Properties:  P_GUILD_LEVEL
+     Allgemeines: /doc/wiz/gift, /doc/help/gift
+     Funktionen:  AddClass(L), is_class_member(L)
+
+Letzte Aenderung: 2015-Feb-02, Arathorn.
+
diff --git a/doc/sphinx/props/P_LIFETIME.rst b/doc/sphinx/props/P_LIFETIME.rst
new file mode 100644
index 0000000..09f7d4a
--- /dev/null
+++ b/doc/sphinx/props/P_LIFETIME.rst
@@ -0,0 +1,54 @@
+P_LIFETIME
+==========
+
+NAME
+----
+::
+
+     P_LIFETIME                    "std_food_lifetime"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/food.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zeit in Sekunden, die die Speise haltbar ist.
+     Mit Setzen dieser Property wird der Wert fuer P_RESET_LIFETIME und
+     dort gespeichert.
+     Nach dieser Zeit wird diese Speise schlecht und je nach Konfiguration
+     der Speise eventuell zerstoert. Sichergestellt wird dies durch den
+     Aufruf von reset() nach dieser Anzahl Sekunden.
+     Moechte man eine Speise haben, die niemals verdirbt
+     (genehmigungspflichtig!), nutzt man die Property P_NO_BAD
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Sobald der Countdown zum Schlechtwerden der Speise laeuft, also ein
+     Spieler damit in Beruehrung kam, zeigt SetProp auf diese Property keine
+     Wirkung mehr.
+
+DEFAULT
+-------
+::
+
+     Ohne Setzen von P_LIFETIME ,P_RESET_LIFETIME und P_NO_BAD verdirbt die
+     Speise nach einem Reset, also zwischen 30 und 60 Minuten
+
+SIEHE AUCH
+----------
+::
+
+     wiz/food, P_RESET_LIFETIME, P_NO_BAD
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_LIGHT.rst b/doc/sphinx/props/P_LIGHT.rst
new file mode 100644
index 0000000..5f06359
--- /dev/null
+++ b/doc/sphinx/props/P_LIGHT.rst
@@ -0,0 +1,81 @@
+P_LIGHT
+=======
+
+NAME
+----
+::
+
+    P_LIGHT                       "light"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt den Lichtlevel eines Objektes an, d.h. wie hell das Objekt von sich
+    aus leuchtet. Moechte man den gesamten Lichtlevel haben der von einem
+    Objekt ausgeht, so sollte man P_TOTAL_LIGHT nehmen, das den Inhalt eines
+    Containers direkt mit verrechnet.
+
+    Bitte _nur_ ueber SetProp bzw. QueryProp zugreifen, da es fuer die
+    Berechnung wichtig ist, das in allen Containern P_LAST_CONTENT_CHANGE
+    gesetzt wird um ein neuberechnen des Lichtlevels auszuloesen!
+
+ANMERKUNG
+---------
+::
+
+    Um ein ungefaehres Gefuehl davon zu bekommen was ein Lichtlevel in
+    etwa bedeutet hier einige allgemeine Beispiele von Gegenstaenden.
+    Grundsaetzlich sollten Lichtlevel <0 und >2 nur in Ruecksprache mit dem
+    Balanceteam benutzt werden.
+
+    Lichtlevel -1,  z.B. ein schwarzer Ring, von dem eine kleine dunkle Aura
+                    ausgeht, die den Spieler umgibt.
+    Lichtlevel  0,  der Gegenstand beeinflusst das Licht ueberhaupt nicht
+    Lichtlevel  1,  der Spieler haelt eine kleine Lichtquelle in Haenden,
+                    dieses kann ein Leuchtpfirsich, eine Fackel oder ein
+                    Feuerschwert oder aehnliches sein.
+    Lichtlevel  2,  eine etwas groessere Lichtquelle, die aber immer noch
+                    nicht den Raum beleuchtet sondern lediglich dem Spieler
+                    einen Lichtschein gewaehrt mit dem er sehen kann.
+    Lichtlevel >2,  extrem helle Lichtquellen, die den gesamten Raum
+                    ausleuchten, in der Regel wohl eher magischer Natur.
+                    Solche Lichtquellen sollten sich mit der Zeit
+                    verbrauchen, dem Spieler Schaden zufuegen oder
+                    aehnliches, damit die Spieler nicht defaultmaessig mit
+                    einer solchen Lichtquelle durchs MG ziehn.
+
+    Daraus ergeben sich dann folgende Konsequenzen fuer Raeume:
+    Lichtlevel  >1: Der Raum ist sehr hell erleuchtet und kann von Spielern
+                    nicht oder nur sehr schwer abgedunkelt werden. Ein Wert
+                    von 2-3 kann interessant sein, wenn die NPCs im Raum
+                    ueber keine Nachtsicht verfuegen. Ueber ein Abdunkeln des
+                    Raumes kann der Spieler dann doch den Nachtkampf nutzen.
+    Lichtlevel   1: Der Raum ist erleuchtet und die Spieler koennen ohne
+                    weitere Lichtquellen sehen...
+    Lichtlevel   0: Ein dunkler Raum in dem man mit jeder Fackel sehen kann.
+    Lichtlevel  -1: man benoetigt zwei einfache Lichtquellen oder Nachtsicht
+                    um in diesem Raum etwas sehen zu koennen.
+    Lichtlevel  -2: Man benoetigt schon eine besondere Lichtquelle um in
+                    diesem Raum noch etwas sehen zu koennen. Solche
+                    Lichtquellen sind nichts fuer Anfaenger oder mittlere
+                    Spieler da sie schwer zu beschaffen und in der Regel
+                    auch einige Handicaps haben.
+    Lichtlevel <-2: Der Raum ist wirklich absolut stockduster und
+                    Lichtquellen die solch einen Raum ausleuchten koennen,
+                    sind ausserordentlich selten und haben immer ihre
+                    Tuecken. Diese Lichtlevel sollten nur mit Vorsicht
+                    genossen werden.
+
+SIEHE AUCH
+----------
+::
+
+    P_TOTAL_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
+
diff --git a/doc/sphinx/props/P_LIGHTDESC.rst b/doc/sphinx/props/P_LIGHTDESC.rst
new file mode 100644
index 0000000..5bab936
--- /dev/null
+++ b/doc/sphinx/props/P_LIGHTDESC.rst
@@ -0,0 +1,56 @@
+P_LIGHTDESC
+===========
+
+NAME
+----
+::
+
+    P_LIGHTDESC                   "lightdesc"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    String oder Array von Strings mit Adjektiven, die das Leuchten der 
+    Lichtquelle beschreiben (z.B. leuchtend, brennend, gluehend).
+    Standardmaessig ist die Property auf "brennend" gesetzt.
+
+    Wenn ein Array angegeben wird, werden die Beschreibungen passend auf
+    die Benndauer aufgeteilt und das zur aktuell noch vorhandenen Rest-
+    Brenndauer passende Adjektiv ausgegeben. Das Array wird dabei rueck-
+    aerts durchlaufen, d.h. fuer eine frisch entzuendete Lichtquelle wird
+    der letzte Eintrag des Arrays verwendet (s. Beispiele).
+
+BEISPIELE
+---------
+::
+
+    Eine einfache Oellampe:
+
+    SetProp(P_LIGHTDESC, "angezuendet");
+
+    Eine Fackel mit mehreren Brennstadien (aus /items/fackel.c):
+
+    SetProp(P_LIGHTDESC, ({"glimmend","flackernd","leicht flackernd",
+                         "brennend","hell lodernd","frisch angezuendet"}));
+
+SIEHE AUCH
+----------
+::
+
+    Basisklassen: /std/lightsource.c
+    Properties:   P_FUEL, P_DO_DESTRUCT, P_LIGHT
+    Methoden:     AddFuel(L)
+
+LETZTE AENDERUNG
+----------------
+::
+
+    22. Dez. 2015, Arathorn
+
diff --git a/doc/sphinx/props/P_LIGHTED.rst b/doc/sphinx/props/P_LIGHTED.rst
new file mode 100644
index 0000000..05fb255
--- /dev/null
+++ b/doc/sphinx/props/P_LIGHTED.rst
@@ -0,0 +1,21 @@
+P_LIGHTED
+=========
+
+NAME
+----
+::
+
+    P_LIGHTED                     "lighted"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Flag, ob die Lichtquelle in Betrieb ist.
+
diff --git a/doc/sphinx/props/P_LIGHT_ABSORPTION.rst b/doc/sphinx/props/P_LIGHT_ABSORPTION.rst
new file mode 100644
index 0000000..c397ee2
--- /dev/null
+++ b/doc/sphinx/props/P_LIGHT_ABSORPTION.rst
@@ -0,0 +1,31 @@
+P_LIGHT_ABSORPTION
+==================
+
+NAME
+----
+::
+
+    P_LIGHT_ABSORPTION                  "light_absorption"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    In Raeumen verteilt sich aufgrund ihrer Groesse das Licht und gerade in
+    groesseren Raeumen kann eine kleine Fackel unter Umstaenden nicht mehr
+    ausreichen den gesamten Raum auszuleuchten. In diesem Fall kann man
+    ueber diese Property das Verhalten des Lichts steuern.
+    Ein "normaler" durchschnittlicher Raum hat hier den Defaultwert 1.
+
+SIEHE AUCH
+----------
+::
+
+    P_TOTAL_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
+
diff --git a/doc/sphinx/props/P_LIGHT_MODIFIER.rst b/doc/sphinx/props/P_LIGHT_MODIFIER.rst
new file mode 100644
index 0000000..b714418
--- /dev/null
+++ b/doc/sphinx/props/P_LIGHT_MODIFIER.rst
@@ -0,0 +1,75 @@
+P_LIGHT_MODIFIER
+================
+
+NAME
+----
+::
+
+    P_LIGHT_MODIFIER                     "light_modifier"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Veraendert das Lichtlevel das von einem Lebewesen wahrgenommen wird.
+    Der Wert dieser Property wird additiv in P_PLAYER_LIGHT beruecksichtigt.
+    Es ist hiermit z.B. moeglich eine Sonnenbrille zu programmieren, diese
+    veraendert ja nicht das tatsaechliche Lichtlevel, sondern verdunkelt nur
+    die Sicht.
+
+ANMERKUNG
+---------
+::
+
+    Damit NPCs in der Lage sind solche Gegenstaende richtig einzuschaetzen,
+    sollte diese Property in jedem Gegenstand der einen Light-Modifier setzt,
+    auch gesetzt sein. Das veraendern dieser Property in Spielern durch NPCs
+    oder Gegenstaende ist selbstverstaendlich genehmigungspflichtig.
+
+BEISPIELE
+---------
+::
+
+       // Ein NPC der auch in relativ dunklen Raeumen mit Lichtlevel -2
+       // noch sehen kann...
+       create_default_npc(10);
+       SetProp(P_LIGHT_MODIFIER, 3);
+
+       // Eine Sonnenbrille, die das Lichtlevel um eins senkt.
+
+       create()
+       {
+
+          :
+
+          SetProp(P_ARMOUR_TYPE, AT_GLASSES);
+          SetProp(P_LIGHT_MODIFIER, -1);
+
+          :
+
+       }
+
+       // Achtung: Falls pl Query- oder Set-Methoden auf P_LIGHT_MODIFIER hat,
+       // wird diese Methode hier furchtbar schief gehen und im besten Fall
+       // nichts veraendern. In realen Objekten empfiehlt sich zumindest eine
+       // Pruefung im Vorfeld, ob eine Query-/Set-Methode gesetzt ist.
+       protected void InformWear(object pl, int silent, int all) {
+           pl->SetProp(P_LIGHT_MODIFIER, pl->QueryProp(P_LIGHT_MODIFIER) -1);
+       }
+
+       protected void InformUnwear(object pl, int silent, int all) {
+           pl->SetProp(P_LIGHT_MODIFIER, pl->QueryProp(P_LIGHT_MODIFIER) +1);
+       }
+
+SIEHE AUCH
+----------
+::
+
+    P_TOTAL_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
+
diff --git a/doc/sphinx/props/P_LIGHT_TRANSPARENCY.rst b/doc/sphinx/props/P_LIGHT_TRANSPARENCY.rst
new file mode 100644
index 0000000..72fe6c0
--- /dev/null
+++ b/doc/sphinx/props/P_LIGHT_TRANSPARENCY.rst
@@ -0,0 +1,30 @@
+P_LIGHT_TRANSPARENCY
+====================
+
+NAME
+----
+::
+
+    P_LIGHT_TRANSPARENCY             "light_transparency"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container.h
+
+BESCHREIBUNG
+------------
+::
+
+    Wieviel Licht schluckt ein Container, d.h. wieviel Licht dringt aus
+    einem Behaelter noch nach draussen. Bei Containern die _nicht_
+    transparent sind, liefert eine _query_method hier immer 999 zurueck.
+    Defaultmaessig steht diese Property auf 2.
+
+SIEHE AUCH
+----------
+::
+
+    P_TOTAL_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
+
diff --git a/doc/sphinx/props/P_LIGHT_TYPE.rst b/doc/sphinx/props/P_LIGHT_TYPE.rst
new file mode 100644
index 0000000..38021ce
--- /dev/null
+++ b/doc/sphinx/props/P_LIGHT_TYPE.rst
@@ -0,0 +1,106 @@
+P_LIGHT_TYPE
+============
+
+NAME
+----
+::
+
+    P_LIGHT_TYPE                       "light_type"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt an, was fuer ein Licht in einem Objekt vorherrscht. 
+
+    
+
+    Es sind verschiedene 'atomare' Lichttypen, vordefiniert:
+    LT_MISC         Unbestimmt, keine Angaben.
+
+    LT_SUN          Sonnenlicht.
+    LT_MOON         Mondlicht 
+    LT_STARS        Sternenlicht.
+
+    
+
+    LT_DIFFUSE      Indirektes Tageslicht. (z.B. im Wald)
+
+    LT_CANDLE       Kerzenlicht.
+    LT_TORCH        Fackelschein.
+    LT_OPEN_FIRE    Sonstiges offenes Feuer. (Lagerfeuer etc.)
+
+    
+
+    LT_MAGIC        Irgendeine magische Lichtquelle.
+
+    LT_GLOWING      Eine selbstleuchtende Lichtquelle.
+
+    LT_DARKNESS     Kein wirkliches Licht, aber auch Dunkelheit soll
+                    explizit gesetzt werden koennen.
+
+    In einem Objekt koennen mehrere Lichttypen gesetzt werden. Dies
+    geschieht durch logische Oder-Verknuepfungen, siehe man operators.
+
+    Wenn in einem Raum mehr als ein Lichttyp gesetzt ist, bedeutet das, 
+    normalerweise, dass mehrere Lichtquellen verschiedenen Typs im Raum 
+    sind.
+
+    Es gibt zudem noch Lichttypen, die zusammengesetzt sind:
+
+    LT_DAYLIGHT    Tageslicht (Sonne/Diffuse)
+    LT_NATURAL     Natuerliches Licht (Daylight/Sterne/Mond)
+    LT_ARTIFICIAL  Kuenstliches Licht (Magie/Feuer/Gluehen)
+    LT_FIRE        Feuer (Kerzen/Fackeln/offenes Feuer)
+
+BEISPIELE
+---------
+::
+
+    Ein Objekt soll ein geheimnisvolles Gluehen von sich geben:
+
+    
+
+    objekt->SetProp( P_LIGHT_TYPE, LT_GLOWING )
+
+    Soll ein Raum beschrieben werden, der durch Sternenlicht erhellt ist,
+    in dem aber zusaetzlich noch ein Lagerfeuer brennt, sieht die Syntax
+    folgendermassen aus:
+
+    
+
+    raum->SetProp( P_LIGHT_TYPE, LT_STARS|LT_OPEN_FIRE );
+
+    Einer brennenden Hose kann der Lichttyp fuer offenes Feuer mitgegeben 
+    werden. Es muss jedoch nicht zwingend der Lichttyp fuer magische
+    Lichtquellen benutzt werden. Es ist klar, dass es irgendwas mit Magie
+    zu tun hat, wenn brennende Spieler durch die Gegend laufen, ohne zu 
+    schreien. P_LIGHT_TYPE sollte jedoch das fassbare Licht beschreiben.
+    LT_MAGIC ist also eher eine Notloesung fuer Licht, dessen Ursache man
+    nicht erklaeren kann.
+
+ANMERKUNG
+---------
+::
+
+    P_LIGHT_TYPE dient ausschliesslich der Beschreibung des Lichtes, das 
+    vorherrscht. Es ist nicht verbunden mit dem Lichtsystem, und soll es
+    auch nicht werden.
+
+    Die Empfindlichkeit der Dunkelelfen gegen Sonnenlicht wird ueber diese
+    Property gesteuert. Soll ein Raum mit (P_INDOORS==0) so dunkel sein, dass
+    sie nicht in Gefahr sind, sollten nicht LT_MISC oder LT_SUN gesetzt
+    sein.
+
+SIEHE AUCH
+----------
+::
+
+    CheckLightType, /std/thing/description.h, operators
+
diff --git a/doc/sphinx/props/P_LIQUID.rst b/doc/sphinx/props/P_LIQUID.rst
new file mode 100644
index 0000000..e764287
--- /dev/null
+++ b/doc/sphinx/props/P_LIQUID.rst
@@ -0,0 +1,21 @@
+P_LIQUID
+========
+
+NAME
+----
+::
+
+    P_LIQUID                      "w_max_wasserfuellmenge"      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/fishing.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_LOCALCMDS.rst b/doc/sphinx/props/P_LOCALCMDS.rst
new file mode 100644
index 0000000..f558c45
--- /dev/null
+++ b/doc/sphinx/props/P_LOCALCMDS.rst
@@ -0,0 +1,25 @@
+P_LOCALCMDS
+===========
+
+NAME
+----
+::
+
+    P_LOCALCMDS                   "localcmds"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Ein Array von Arrays aller Befehle die im Spieler selbst definiert sind.
+    ({ ({ "befehl", "funktion", flag, wizlevel }) })
+    Wenn flag gesetzt ist werden nur die ersten Zeichen die auch in Befehl
+    angegeben sind mit dem Verb ueberprueft. Siehe auch
+    add_action("funktion", "befehl", 1) und AddCmd("befehl", "funktion", 1).
+
diff --git a/doc/sphinx/props/P_LOCATION.rst b/doc/sphinx/props/P_LOCATION.rst
new file mode 100644
index 0000000..13e37b9
--- /dev/null
+++ b/doc/sphinx/props/P_LOCATION.rst
@@ -0,0 +1,39 @@
+P_LOCATION
+==========
+
+NAME
+----
+::
+
+    P_LOCATION                   "location"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+    Hier kann der Spieler mit dem Befehl "ort" den Ort setzen,
+    von dem er kommt bzw. zu kommen glaubt ;)
+    Um wieder den automatisch ermittelten Ort anzuzeigen, ist
+    P_LOCATION auf 0 zu setzen.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+    ort
+
+
+Last modified: Sat Jul 01 23:16:00 2000 by Mupfel
+
+    
+
+    
+
diff --git a/doc/sphinx/props/P_LOG_INFO.rst b/doc/sphinx/props/P_LOG_INFO.rst
new file mode 100644
index 0000000..71a44f1
--- /dev/null
+++ b/doc/sphinx/props/P_LOG_INFO.rst
@@ -0,0 +1,55 @@
+P_LOG_INFO
+==========
+
+NAME
+----
+::
+
+    P_LOG_INFO                    "log_info"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn diese Property gesetzt ist wird jede Frage, die ein
+     Monster nicht beantworten kann, im Report-File des
+     zustaendigen Magiers geloggt.
+
+     Es ist jedoch auch moeglich, direkt einen Filenamen anzugeben.
+     Bei diesen wird dann jedoch automatisch ein /log/ vorne angehaengt.
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_LOG_INFO,1);           // Alle fehlenden Infos dieses
+                                         Monsters werden in das Report-
+                                         File unter /log/report/ gelogt.
+
+     SetProp(P_LOG_INFO,"tilly/opa"); // Alle fehlenden Infos dieses
+                                         Monsters werden in das File
+                                         monster unter /log/tilly/ ge-
+                                         logt.
+
+BEMERKUNGEN
+-----------
+::
+
+     Bei nachtraeglich angeschlossenen Monstern empfiehlt sich Variante 
+     2 der Beispiele. Ein muehsames Suchen (und Loeschen) der fehlenden 
+     Infos des Monsters im Report-File eruebrigt sich dann naemlich.
+
+SIEHE AUCH
+----------
+::
+
+     P_LOG_FILE, write_file(), log_file(), AddInfo
+
+Letzte Aenderung: 13.09.04 Tilly@MorgenGrauen
+
diff --git a/doc/sphinx/props/P_LONG.rst b/doc/sphinx/props/P_LONG.rst
new file mode 100644
index 0000000..04b0404
--- /dev/null
+++ b/doc/sphinx/props/P_LONG.rst
@@ -0,0 +1,49 @@
+P_LONG
+======
+
+NAME
+----
+::
+
+     P_LONG					"long"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Die Langbeschreibung des Objektes als String oder Closure (diese muss
+     einen String zurueckgeben). Die Langbeschreibung wird beim Untersuchen
+     des Objektes ausgegeben. Sie sollte umgebrochen sein.
+
+     Diese Property bestimmt die Ansicht des Objektes von aussen. Fuer die
+     Innen(lang)ansicht von Raeumen muss man P_INT_LONG benutzen.
+
+BEMERKUNGEN
+-----------
+::
+
+     - long() ("untersuche") filtert P_LONG durch process_string()
+       -> daher sind Closures moeglich
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_LONG, "Diese Axt ist eine furchtbare Waffe!\n");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	P_SHORT, long()
+     Sonstiges:		P_INT_LONG, process_string(), break_string()
+
+
+Last modified: Sun May 19 20:10:18 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_LONG_EMPTY.rst b/doc/sphinx/props/P_LONG_EMPTY.rst
new file mode 100644
index 0000000..ea94fe5
--- /dev/null
+++ b/doc/sphinx/props/P_LONG_EMPTY.rst
@@ -0,0 +1,21 @@
+P_LONG_EMPTY
+============
+
+NAME
+----
+::
+
+    P_LONG_EMPTY                  "w_longdesc_empty"            
+
+DEFINIERT IN
+------------
+::
+
+    /sys/fishing.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_LONG_FULL.rst b/doc/sphinx/props/P_LONG_FULL.rst
new file mode 100644
index 0000000..ab623e0
--- /dev/null
+++ b/doc/sphinx/props/P_LONG_FULL.rst
@@ -0,0 +1,21 @@
+P_LONG_FULL
+===========
+
+NAME
+----
+::
+
+    P_LONG_FULL                   "w_longdesc_full"             
+
+DEFINIERT IN
+------------
+::
+
+    /sys/fishing.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_MAGIC.rst b/doc/sphinx/props/P_MAGIC.rst
new file mode 100644
index 0000000..ec394f1
--- /dev/null
+++ b/doc/sphinx/props/P_MAGIC.rst
@@ -0,0 +1,21 @@
+P_MAGIC
+=======
+
+NAME
+----
+::
+
+    P_MAGIC                       "magic"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Dieses Objekt ist magisch.
+
diff --git a/doc/sphinx/props/P_MAGIC_RESISTANCE_OFFSET.rst b/doc/sphinx/props/P_MAGIC_RESISTANCE_OFFSET.rst
new file mode 100644
index 0000000..a1be37e
--- /dev/null
+++ b/doc/sphinx/props/P_MAGIC_RESISTANCE_OFFSET.rst
@@ -0,0 +1,52 @@
+P_MAGIC_RESISTANCE_OFFSET
+=========================
+
+NAME
+----
+::
+
+     P_MAGIC_RESISTANCE_OFFSET                     "mag_res_offset"                     
+
+DEFINIERT IN
+------------
+::
+
+     /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mapping mit ganzzahligen Prozentwerten in 0.01%-Schritten
+     (0-10000) zur Resistenz/Empfindlichkeit gegen bestimmte
+     Magieklassen.
+
+     Die Property wird in der Methode SpellDefend() ausgewertet und
+     fuer einen auf den NPC/Spieler gesprochenen Spell werden die
+     Werte fuer all dessen Magieklassen aufaddiert. Daher sind auch
+     negative Werte fuer einzelne Magieklassen sinnvoll.
+
+     P_MAGIC_RESISTANCE_OFFSET und SpellDefend werden von den Spellbooks
+     ausgewertet. Der Einfluss ist daher abhaengig vom Spellbook.
+
+BEISPIELE
+---------
+::
+
+     // Goblins
+     SetProp(P_MAGIC_RESISTANCE_OFFSET,
+               ([MT_ANGRIFF:600,         // 6% Resistenz gegen Angriff
+	         MT_ILLUSION:500,        // 6% Resistenz gegen Illusionen
+                 MT_VERWANDLUNG:-300,    // 3% Empfindlichkeit
+		 MT_HELLSICHT:-750,      // 7.5% Empfindlichkeit
+		 MT_BEHERRSCHUNG:250])); // 2.5% Resistenz
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt:     SpellDefend
+     Aehnlich:     P_NOMAGIC
+
+29.Dez 2007 Gloinson
+
diff --git a/doc/sphinx/props/P_MAILADDR.rst b/doc/sphinx/props/P_MAILADDR.rst
new file mode 100644
index 0000000..4a680bf
--- /dev/null
+++ b/doc/sphinx/props/P_MAILADDR.rst
@@ -0,0 +1,21 @@
+P_MAILADDR
+==========
+
+NAME
+----
+::
+
+    P_MAILADDR                    "mailaddr"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     EMailadresse des Spielers.
+
diff --git a/doc/sphinx/props/P_MAP_RESTRICTIONS.rst b/doc/sphinx/props/P_MAP_RESTRICTIONS.rst
new file mode 100644
index 0000000..51cefec
--- /dev/null
+++ b/doc/sphinx/props/P_MAP_RESTRICTIONS.rst
@@ -0,0 +1,57 @@
+P_MAP_RESTRICTIONS
+==================
+
+NAME
+----
+::
+
+    P_MAP_RESTRICTIONS                      "lib_p_map_restrictions"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/rooms.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Property laesst sich beeinflussen, welche Informationen ueber
+     den Raum das Morgengrauen dem Client zukommen laesst (zur Zeit nur via
+     GMCP, aber es mag irgendwann auch andere Wege geben).
+     Beispielsweise sollen vielleicht in einem Labyrinth keine eindeutigen
+     Raum-IDs uebermittelt werden.
+
+     Als Werte duerfen alle MR_-Konstanten aus <rooms.h> verwendet werden.
+     Diese duerfen auch ver-ODER-t werden, wenn mehr als eine davon gelten
+     soll.
+
+     Moegliche Werte:
+       MR_NOUID - verhindert, dass die eindeutige Raum-ID uebertragen wird.
+       MR_NOINFO - verhindert, dass ueberhaupt irgendetwas an den Client
+                   uebermittelt wird. Damit kriegt er ggf. auch nicht mit,
+                   dass er Raum gewechselt wurde. Ist fuer Sequenzraeume
+                   gedacht. Bitte SEHR sparsam einsetzen.
+
+     Die Verwendung dieser Property sollte der Ausnahmefall sein!
+
+BEISPIEL
+--------
+::
+
+     (in einem Raum)
+     SetProp(P_MAP_RESTRICTIONS, MR_NOUID);
+
+     Nun bekommt der Client zwar die Kurzbeschreibung des Raums, die Region
+     und die sichtbaren Ausgaenge, aber keine UID mehr uebermittelt.
+
+SIEHE AUCH
+----------
+::
+
+     gmcp
+
+
+23.02.2013, Zesstra
+
diff --git a/doc/sphinx/props/P_MARRIED.rst b/doc/sphinx/props/P_MARRIED.rst
new file mode 100644
index 0000000..5a1e040
--- /dev/null
+++ b/doc/sphinx/props/P_MARRIED.rst
@@ -0,0 +1,28 @@
+P_MARRIED
+=========
+
+NAME
+----
+::
+
+    P_MARRIED                     "married"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Enthaelt einen String mit der uid des Partners
+     (sofern vorhanden)
+
+SIEHE AUCH
+----------
+::
+
+     scheidung
+
diff --git a/doc/sphinx/props/P_MATERIAL.rst b/doc/sphinx/props/P_MATERIAL.rst
new file mode 100644
index 0000000..1223b56
--- /dev/null
+++ b/doc/sphinx/props/P_MATERIAL.rst
@@ -0,0 +1,99 @@
+P_MATERIAL
+==========
+
+NAME
+----
+::
+
+     P_MATERIAL					"material"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/material.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Mapping mit prozentualen Anteilen von Materialien, aus denen ein Objekt 
+     besteht.
+
+BEMERKUNGEN
+-----------
+::
+
+     Bei SetProp kann man zu Vereinfachung auch ein einzelnes Material oder 
+     ein Array aus Materialien angeben. Die Anteile werden dann 
+     gleichmaessig verteilt.
+
+BEISPIELE
+---------
+::
+
+     // 100% Eis
+     SetProp(P_MATERIAL, MAT_ICE);
+     // QueryProp(P_MATERIAL) -> ([MAT_ICE:100])
+
+     // 50% Eis, 50% Misc-Holz
+     SetProp(P_MATERIAL, ({ MAT_ICE, MAT_MISC_WOOD }));
+     // QueryProp(P_MATERIAL) -> ([MAT_ICE:50, MAT_MISC_WOOD: 50])
+
+     // 60% Eis, 40% Misc-Holz
+     SetProp(P_MATERIAL, ([ MAT_ICE: 60, MAT_MISC_WOOD: 40 ]));
+
+     // 100% Papier
+     SetProp(P_MATERIAL, MAT_PAPER);
+     // QueryProp(P_MATERIAL) -> ([MAT_PAPER:100])
+
+     // 50% Silber, 50% Gold
+     SetProp(P_MATERIAL, ({MAT_SILVER, MAT_GOLD}))
+     // QueryProp(P_MATERIAL) -> ([MAT_SILVER:50,MAT_GOLD:50])
+
+     // ein weiser Schmied, der was daraus macht:
+     int i;
+     string *mat, mname, mgroup;
+     mat=m_indices(ob->QueryProp(P_MATERIAL));
+     i=sizeof(mat);
+
+     write("Der Schmied sagt: "+ob->Name(WER)+" besteht aus ...\n");
+     while(i--) {
+      // den Namen erkennen/aussprechen:
+      // Materialien werden allgemein ganz schlecht erkannt (zu 5%), aber
+      // alles aus Metall wird zu +100% gut erkannt ...
+      mname=MATERIALDB->MaterialName(mat[i], WER,
+	     ({5, ([MATERIAL_SYMMETRIC_RECOGNIZABILITY:
+			({MATGROUP_METAL, 100})])}));
+
+      // und nur Metalle analysieren ...
+      if(MATERIALDB->MaterialGroup(([mat[i]:100]),MATGROUP_METAL)>=100) {
+       int j;
+       string *mgr;
+       mgr=MATERIALDB->GetMatMembership(mat[i]);
+       j=sizeof(mgr);
+       mgroup=" gehoert zu ";
+       while(j--) {
+        mgroup+=MATERIALDB->GroupName(mgr[j]);
+        if(j>0) mgroup+=", ";
+       }
+      } else mgroup=" kenne ich nicht";
+      printf("%-12.12s: %s\n",mname, mgroup);
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: /sys/thing/material.h
+     Methoden:    QueryMaterial(), QueryMaterialGroup(), MaterialList(),
+     Listen:	  AllMaterials(), AllGroups(), Dump()
+		  materialliste, materialgruppen
+     Master:	  AddMaterial(), ConvMaterialList(), MaterialGroup(),
+		  GroupName(), MaterialName(),
+		  GetGroupMembers(), GetMatMembership()
+     Sonstiges:	  P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_MATERIAL_KNOWLEDGE.rst b/doc/sphinx/props/P_MATERIAL_KNOWLEDGE.rst
new file mode 100644
index 0000000..e8ba8a3
--- /dev/null
+++ b/doc/sphinx/props/P_MATERIAL_KNOWLEDGE.rst
@@ -0,0 +1,56 @@
+P_MATERIAL_KNOWLEDGE
+====================
+
+NAME
+----
+::
+
+     P_MATERIAL_KNOWLEDGE				"material_knowledge"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/material.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Mapping, Closure oder Integer mit Regeln zur Materialienerkennung. Die
+     Regeln sind in "man materialerkennung" zu lesen.
+
+     Diese werden bei Angabe eines Spielerobjektes in MaterialList() oder
+     MaterialName() an diesem abgefragt und hat Einfluss darauf, ob ein
+     Material genau, generell oder gar nicht erkannt wird.
+
+     In den einzelnen Rassenshells sind Defaultwerte dafuer angegeben.
+
+BEISPIELE
+---------
+::
+
+     // Erkennungsbonus auf diverse Materialgruppen und
+     // Erkennungsbonus/-malus auf biologische/nichtbiologische Materialien
+     SetProp(P_MATERIAL_KNOWLEDGE,
+	([MATGROUP_WOOD:20,
+	  MATGROUP_METAL:20,
+	  MATGROUP_ELEMENTAL:20,
+	  MATGROUP_CLOTH:20,
+	  MATERIAL_SYMMETRIC_RECOGNIZABILITY: ({MATGROUP_BIO,5})]));
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Methoden:    QueryMaterial(), QueryMaterialGroup(), MaterialList(),
+     Listen:	  AllMaterials(), AllGroups(), Dump()
+		  materialliste, materialgruppen
+     Master:	  AddMaterial(), ConvMaterialList(), MaterialGroup(),
+		  GroupName(), MaterialName(),
+		  GetGroupMembers(), GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_MAX_ALCOHOL.rst b/doc/sphinx/props/P_MAX_ALCOHOL.rst
new file mode 100644
index 0000000..9289522
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_ALCOHOL.rst
@@ -0,0 +1,40 @@
+P_MAX_ALCOHOL
+=============
+
+NAME
+----
+::
+
+	P_MAX_ALCOHOL			"max_alcohol"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+	Numerischer Wert fuer den maximalen Grad der Betrunkenheit eines
+	Lebewesens.
+
+ANMERKUNGEN
+-----------
+::
+
+	Der Wert von P_MAX_ALCOHOL ist bei den einzelnen Rassen verschieden,
+	ebenso wie der fuer P_ALCOHOL_DELAY. Die genauen Werte stehen in den
+	Rassen-Shells (/std/shells).
+
+SIEHE AUCH
+----------
+::
+
+	P_ALCOHOL, P_ALCOHOL_DELAY, drink_alcohol,
+	P_MAX_FOOD, P_MAX_DRINK
+
+
+Last modified: Tue Dec 18 12:16:10 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_MAX_DRINK.rst b/doc/sphinx/props/P_MAX_DRINK.rst
new file mode 100644
index 0000000..a637902
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_DRINK.rst
@@ -0,0 +1,40 @@
+P_MAX_DRINK
+===========
+
+NAME
+----
+::
+
+	P_MAX_DRINK			"max_drink"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+	Numerischer Wert fuer die maximale Saettigung eines Lebewesens mit
+	Getraenken.
+
+ANMERKUNGEN
+-----------
+::
+
+	Der Wert von P_MAX_DRINK ist bei den einzelnen Rassen verschieden,
+	ebenso wie der fuer P_DRINK_DELAY. Die genauen Werte stehen in den
+	Rassen-Shells (/std/shells).
+
+SIEHE AUCH
+----------
+::
+
+	P_DRINK, P_DRINK_DELAY, drink_soft,
+	P_MAX_FOOD, P_MAX_ALCOHOL
+
+
+Last modified: Tue Dec 18 12:16:10 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_MAX_FOOD.rst b/doc/sphinx/props/P_MAX_FOOD.rst
new file mode 100644
index 0000000..bfe87b4
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_FOOD.rst
@@ -0,0 +1,39 @@
+P_MAX_FOOD
+==========
+
+NAME
+----
+::
+
+	P_MAX_FOOD			"max_food"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+	Numerischer Wert fuer die maximale Saettigung eines Lebewesens.
+
+ANMERKUNGEN
+-----------
+::
+
+	Der Wert von P_MAX_FOOD ist bei den einzelnen Rassen verschieden, 
+	ebenso wie der fuer P_FOOD_DELAY. Die genauen Werte stehen in den
+	Rassen-Shells (/std/shells).
+
+SIEHE AUCH
+----------
+::
+
+	P_FOOD, P_FOOD_DELAY, eat_food,
+	P_MAX_DRINK, P_MAX_ALCOHOL
+
+
+Last modified: Tue Dec 18 12:16:10 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_MAX_HANDS.rst b/doc/sphinx/props/P_MAX_HANDS.rst
new file mode 100644
index 0000000..911fe3a
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_HANDS.rst
@@ -0,0 +1,45 @@
+P_MAX_HANDS
+===========
+
+NAME
+----
+::
+
+     P_MAX_HANDS                   "max_hands"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der Haende, die ein Wesen hat.
+
+BEMERKUNGEN
+-----------
+::
+
+     An dieser Propertie sollte bei Spielern nur im Rahmen der
+     Gilden 'gespielt' werden.
+
+     Fuer Magier, die in ihren Npc gerne alle Properties setzen,
+     gilt folgendes:
+
+                  Setzt diese Propertie NIE auf 0 !
+
+     Ohne Haende wird kein Npc irgendeinen Spieler angreifen koennen.
+
+SIEHE AUCH
+----------
+::
+
+     P_HANDS, P_HANDS_USED_BY
+     P_USED_HANDS, P_FREE_HANDS
+     UseHands, FreeHands
+
+1.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/props/P_MAX_HP.rst b/doc/sphinx/props/P_MAX_HP.rst
new file mode 100644
index 0000000..3e23b46
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_HP.rst
@@ -0,0 +1,30 @@
+P_MAX_HP
+========
+
+NAME
+----
+::
+
+    P_MAX_HP                      "max_hp"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Maximale Anzahl der Lebenspunkte.
+
+SIEHE AUCH
+----------
+::
+
+     Props:	P_HP
+     Verwandt:	UpdateAttributes()
+
+21.April 2006 Gloinson
+
diff --git a/doc/sphinx/props/P_MAX_OBJECTS.rst b/doc/sphinx/props/P_MAX_OBJECTS.rst
new file mode 100644
index 0000000..3761d71
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_OBJECTS.rst
@@ -0,0 +1,44 @@
+P_MAX_OBJECTS
+=============
+
+NAME
+----
+::
+
+    P_MAX_OBJECTS                  "max_objects"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container.h
+
+BESCHREIBUNG
+------------
+::
+
+     Maximale Anzahl an Objekten, die in einen Container passen.
+     P_MAX_OBJECTS sollte im Normfall zwischen 0 - 100 liegen.
+
+BEMERKUNGEN
+-----------
+::
+
+     Soll es sich um einen herausragenden Container handeln, der zum
+     Beispiel das Gewicht um mehr als 50% reduziert, sollte P_MAX_OBJECTS
+     einen kleineren Wert haben. Das Verhaeltnis von P_MAX_WEIGHT,
+     P_WEIGHT_PERCENT und dieser Property sollte stimmen.
+
+BEISPIELE
+---------
+::
+
+     Als Beispiel sollte man sich das Postpaket ansehen und sich an dessen
+     Werten orientieren (/p/service/loco/obj/parcel).
+
+SIEHE AUCH
+----------
+::
+
+     P_MAX_WEIGHT, P_WEIGHT_PERCENT, P_LIGHT_TRANSPARENCY, container
+
diff --git a/doc/sphinx/props/P_MAX_PASSENGERS.rst b/doc/sphinx/props/P_MAX_PASSENGERS.rst
new file mode 100644
index 0000000..d85ce26
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_PASSENGERS.rst
@@ -0,0 +1,22 @@
+P_MAX_PASSENGERS
+================
+
+NAME
+----
+::
+
+    P_MAX_PASSENGERS              "maxpass"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+     Numerischer Wert fuer die maximale Anzahl von Wesen in dem Transporter.
+     0 bedeutet unbeschaenkte Spielerzahl.
+
diff --git a/doc/sphinx/props/P_MAX_POISON.rst b/doc/sphinx/props/P_MAX_POISON.rst
new file mode 100644
index 0000000..65739b2
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_POISON.rst
@@ -0,0 +1,21 @@
+P_MAX_POISON
+============
+
+NAME
+----
+::
+
+    P_MAX_POISON                  "max_poison"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Maximale Vergiftung
+
diff --git a/doc/sphinx/props/P_MAX_SP.rst b/doc/sphinx/props/P_MAX_SP.rst
new file mode 100644
index 0000000..2269cd2
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_SP.rst
@@ -0,0 +1,30 @@
+P_MAX_SP
+========
+
+NAME
+----
+::
+
+    P_MAX_SP                      "max_sp"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Maximale Anzahl der Magiepunkte.
+
+SIEHE AUCH
+----------
+::
+
+     Props:	P_SP
+     Verwandt:	UpdateAttributes()
+
+21.April 2006 Gloinson
+
diff --git a/doc/sphinx/props/P_MAX_WEIGHT.rst b/doc/sphinx/props/P_MAX_WEIGHT.rst
new file mode 100644
index 0000000..80b63af
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_WEIGHT.rst
@@ -0,0 +1,38 @@
+P_MAX_WEIGHT
+============
+
+NAME
+----
+::
+
+    P_MAX_WEIGHT                  "max_weight"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container.h
+
+BESCHREIBUNG
+------------
+::
+
+     Maximales Gewicht in Gramm, das in dem Container verstaut werden
+     kann.
+
+BEMERKUNGEN
+-----------
+::
+
+     Das Verhaeltnis von P_WEIGHT_PERCENT, P_MAX_OBJECTS und dieser Property
+     sollte stimmen. Eine feste Grenze gibt es nicht. Als Beispiel kann 
+     das Postpaket von Loco unter /p/servive/loco/obj herangezogen werden.
+     Bessere Werte als in diesem sollte es nicht, und wenn doch nur gut be-
+     gruendet, geben.
+
+SIEHE AUCH
+----------
+::
+
+     P_WEIGHT_PERCENT, P_MAX_OBJECTS, P_LIGHT_TRANSPARENCY, container
+
diff --git a/doc/sphinx/props/P_MESSAGE_BEEP.rst b/doc/sphinx/props/P_MESSAGE_BEEP.rst
new file mode 100644
index 0000000..90b3f72
--- /dev/null
+++ b/doc/sphinx/props/P_MESSAGE_BEEP.rst
@@ -0,0 +1,38 @@
+P_MESSAGE_BEEP
+==============
+
+NAME
+----
+::
+
+    P_MESSAGE_BEEP                        "message_beep"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wertebereich: int=0..3600 (Sekunden)
+     Wenn gesetzt wird in der Kommunikation des Spielers in den angegebenen
+     Zeitraeumen ein Signalton ausgegeben. Wird in player/comm.c in comm_beep()
+     verarbeitet.
+     Ausgabe erfolgt nur, wenn P_VISUALBELL nicht gesetzt ist.
+     Wird im Spielerobjekt gespeichert!
+
+SIEHE AUCH
+----------
+::
+
+     klingelton, ton, P_VISUALBELL, P_MESSAGE_LAST_BEEP
+
+LETZTE AENDERUNG
+----------------
+::
+
+   16. Mai 2007  Ennox
+
diff --git a/doc/sphinx/props/P_MESSAGE_PREPEND.rst b/doc/sphinx/props/P_MESSAGE_PREPEND.rst
new file mode 100644
index 0000000..ab85748
--- /dev/null
+++ b/doc/sphinx/props/P_MESSAGE_PREPEND.rst
@@ -0,0 +1,37 @@
+P_MESSAGE_PREPEND
+=================
+
+NAME
+----
+::
+
+    P_MESSAGE_PREPEND                        "message_prepend"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wertebereich: int = 0,1
+     Wenn vom Ziel eingeschaltet, wird von teile mit (_tell) und sag (_communicate) das 
+     BS_PREPEND_INDENT Flag fuer break_string genutzt, um den Indent (Sender) ggf.
+     vor dem Textblock anzuzeigen.
+     Wird im Spielerobjekt gespeichert!
+
+SIEHE AUCH
+----------
+::
+
+     grafik aus, break_string, senderwiederholung
+
+LETZTE AENDERUNG
+----------------
+::
+
+   16. Mai 2007  Ennox
+
diff --git a/doc/sphinx/props/P_MIN_STOCK.rst b/doc/sphinx/props/P_MIN_STOCK.rst
new file mode 100644
index 0000000..4bd5eec
--- /dev/null
+++ b/doc/sphinx/props/P_MIN_STOCK.rst
@@ -0,0 +1,56 @@
+P_MIN_STOCK
+===========
+
+NAME
+----
+::
+
+	P_MIN_STOCK			"min_stock"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/bank.h
+
+BESCHREIBUNG
+------------
+::
+
+	P_MIN_STOCK enthaelt die Anzahl an Objekten, die ein Lager eines
+	Ladens minimal behaelt. Standardmaessig entspricht dies 20 Objekten
+	und sollte auch nicht wesentlich erhoeht werden. Nur fuer
+	Anfaengergebiete waeren Werte zwischen 20 und 60 akzeptabel. In die
+	Berechnung der Anzahl von Objekten gehen keine Objekte ein, die im
+	Laden mittels AddFixedObject() staendig verfuegbar gemacht worden
+	sind und auch keine Objekte, die per AddItem() im Lager hinzugefuegt
+	wurden und nach jedem Reset aufgefrischt werden.
+	Bei jedem Reset wird nun aus Speicher- und Laggruenden das Lager um
+	eine bestimmte Prozentzahl an Objekten dezimiert. Entscheidend
+	dafuer ist der Wert in der Property P_STORE_CONSUME.
+	Beide hier erwaehnten Properties sollten ueberigens nur mittels
+	QueryProp/SetProp ausgelesen bzw. veraendert werden.
+
+BEISPIEL
+--------
+::
+
+	In '/std/store.c' befindet sich bereits ein gutes Beispiel, da dort
+	der Standardwert von 20 Objekten bereitgestellt wird:
+	  create()
+	  { ...
+	    SetProp(P_MIN_STOCK,20);
+	  }
+	Diesen Wert kann man in einem davon abgeleiteten eigenen Lager
+	natuerlich auch veraendern.
+
+SIEHE AUCH
+----------
+::
+
+	P_STORE_CONSUME, SetStorageRoom(), /std/store.c, /std/shop.c
+	AddItem(), RemoveItem(), AddFixedObject(), RemoveFixedObject()
+
+
+Last modified: 19-Jun-2015, Arathorn 
+
diff --git a/doc/sphinx/props/P_MMSGIN.rst b/doc/sphinx/props/P_MMSGIN.rst
new file mode 100644
index 0000000..4d4dbb4
--- /dev/null
+++ b/doc/sphinx/props/P_MMSGIN.rst
@@ -0,0 +1,22 @@
+P_MMSGIN
+========
+
+NAME
+----
+::
+
+    P_MMSGIN                      "mmsgin"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     String mit der Meldung, die beim Verlassen eines Raumes mit M_TPORT
+     an die uebrigen Anwesenden ausgegeben wird.
+
diff --git a/doc/sphinx/props/P_MMSGOUT.rst b/doc/sphinx/props/P_MMSGOUT.rst
new file mode 100644
index 0000000..762f43e
--- /dev/null
+++ b/doc/sphinx/props/P_MMSGOUT.rst
@@ -0,0 +1,22 @@
+P_MMSGOUT
+=========
+
+NAME
+----
+::
+
+    P_MMSGOUT                     "mmsgout"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     String mit der Meldung, die beim Betreten eines Raumes mit M_TPORT
+     an die uebrigen Anwesenden ausgegeben wird.
+
diff --git a/doc/sphinx/props/P_MSGIN.rst b/doc/sphinx/props/P_MSGIN.rst
new file mode 100644
index 0000000..ab7d73b
--- /dev/null
+++ b/doc/sphinx/props/P_MSGIN.rst
@@ -0,0 +1,22 @@
+P_MSGIN
+=======
+
+NAME
+----
+::
+
+    P_MSGIN                       "msgin"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     String mit der Meldung, die beim Betreten eines Raumes mit M_GO
+     an die uebrigen Anwesenden ausgegeben wird.
+
diff --git a/doc/sphinx/props/P_MSGOUT.rst b/doc/sphinx/props/P_MSGOUT.rst
new file mode 100644
index 0000000..ce046cb
--- /dev/null
+++ b/doc/sphinx/props/P_MSGOUT.rst
@@ -0,0 +1,22 @@
+P_MSGOUT
+========
+
+NAME
+----
+::
+
+    P_MSGOUT                      "msgout"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     String mit der Meldung, die beim Verlassen eines Raumes mit M_GO
+     an die uebrigen Anwesenden ausgegeben wird.
+
diff --git a/doc/sphinx/props/P_MSG_PROB.rst b/doc/sphinx/props/P_MSG_PROB.rst
new file mode 100644
index 0000000..1f0e9ea
--- /dev/null
+++ b/doc/sphinx/props/P_MSG_PROB.rst
@@ -0,0 +1,35 @@
+P_MSG_PROB
+==========
+
+NAME
+----
+::
+
+    P_MSG_PROB                    "msg_prob"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Parameter fuer die Wartezeit in Sekunden bis zur naechsten Ausgabe
+     einer Raumnachricht.
+     Wird in AddRoomMessage() explizit mitgesetzt. Koennte natuerlich von
+     einer Nachrichtenmethode auch regelmaessig geaendert werden, um
+     mehr Zufall in die Intervalle zu bringen.
+
+SIEHE AUCH
+----------
+::
+
+     LFuns:    AddRoomMessage()
+     Props:    P_ROOM_MSG, P_MSG_PROB
+     Verwandt: call_out()
+
+2.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_MUD_NEWBIE.rst b/doc/sphinx/props/P_MUD_NEWBIE.rst
new file mode 100644
index 0000000..ce6b8b8
--- /dev/null
+++ b/doc/sphinx/props/P_MUD_NEWBIE.rst
@@ -0,0 +1,31 @@
+P_MUD_NEWBIE
+============
+
+NAME
+----
+::
+
+    P_MUD_NEWBIE                      "_lib_mud_newbie" 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+    Der Spieler hat bei Erstellung des Charakters angegeben, noch nie in einem
+    Mud gespielt zu haben. In diesem Fall enthaelt die Property den
+    Zeitstempel der Charaktererstellung.
+
+    ACHTUNG: Diese Prop wird nicht gespeichert, d.h. nachdem ein solcher
+    Spieler "ende" gemacht hat oder ein Reboot erfolgte, ist diese Information
+    verloren.
+
+SIEHE AUCH
+----------
+::
+
diff --git a/doc/sphinx/props/P_MURDER_MSG.rst b/doc/sphinx/props/P_MURDER_MSG.rst
new file mode 100644
index 0000000..b7d4e9a
--- /dev/null
+++ b/doc/sphinx/props/P_MURDER_MSG.rst
@@ -0,0 +1,83 @@
+P_MURDER_MSG
+============
+
+NAME
+----
+::
+
+     P_MURDER_MSG			"murder_msg"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property kann man einen String oder eine Closure ablegen
+     dessen Wert bzw. deren Resultat beim Tod des NPCs auf dem
+     Moerder-Kanal erscheint.
+     Normalerweise ist die Property nicht gesetzt, woraufhin zufaellig
+     eine Meldung generiert wird.
+
+     Ob der Tod eines NPCs auf dem Moerder-Kanal erscheint, haengt davon ab,
+     wie oft und welche Art von NPCs in der letzten Zeit getoetet wurden. Zum
+     Beispiel ist es eher selten, dass ein schwacher NPC auf dem Kanal
+     erscheint, wenn kuerzlich viele starke NPCs getoetet wurden. Allerdings
+     kann man auf diese Regelung mittels der Property P_FORCE_MURDER_MSG
+     Einfluss nehmen.
+
+     Wird in einen String der Platzhalter %s eingefuegt, so erscheint an der
+     Stelle spaeter der Name des Moerders.
+
+BEISPIELE
+---------
+::
+
+     // Zum Beispiel koennte man ja bei einer Ratte, die getoetet wird,
+     // folgendes auf dem Moerder-Kanal ausgeben lassen:
+     SetProp(P_MURDER_MSG,
+       "Ratten aller MUDs, vereinigt euch gegen %s!");
+
+
+     // Um auch mal eine Closure zu zeigen: die Ratte koennte auch ihre
+     // Meldung erst bei ihrem Tod erstellen lassen:
+     private string moerder_meldung() {
+       return ({"Achweh!", "Au!", "Weia!"})[random(3)];
+     }
+
+     SetProp(P_MURDER_MSG, #'moerder_meldung);
+
+BEMERKUNGEN
+-----------
+::
+
+     - P_NOCORPSE:
+       Ist in dem NPC die Property P_NOCORPSE gesetzt, so wird die
+       Moerdermeldung nicht auf dem Kanal gesendet, da diese Ausgabe ueber
+       /std/corpse laeuft.
+       Will man dennoch eine Meldung, so sollte man /std/corpse im die()
+       selbst clonen, daran Identify(this_object()) rufen und das geclonte
+       Objekt wieder entsorgen.
+
+     - Closures:
+       Closures bieten sich an, wenn ein zentrales Objekt fuer mehrere NPCs
+       bestimmte Moerdermeldungen generieren soll. Dann muss nur noch bei
+       den NPCs die Closure, die auf die erstellende Methode zeigt gesetzt
+       werden.
+
+SIEHE AUCH
+----------
+::
+
+     Tod:		die(L)
+     Verwandt:		P_FORCE_MURDER_MSG
+     Todesmeldungen:	P_KILL_NAME, P_KILL_MSG, P_DIE_MSG
+			P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
+     Sonstiges:		P_CORPSE, P_NOCORPSE, /std/corpse.c
+
+30. Mai 2006, Gloinson
+
diff --git a/doc/sphinx/props/P_M_ATTR_MOD.rst b/doc/sphinx/props/P_M_ATTR_MOD.rst
new file mode 100644
index 0000000..9c20023
--- /dev/null
+++ b/doc/sphinx/props/P_M_ATTR_MOD.rst
@@ -0,0 +1,64 @@
+P_M_ATTR_MOD
+============
+
+NAME
+----
+::
+
+    P_M_ATTR_MOD                  "magic_attributes_modifier"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mapping, das die Attribute des Spielers veraendert, der diese Ruestung
+    bzw. Waffe traegt bzw. benutzt.
+
+    Zu beachten:
+    P_M_ATTR_MOD kann problemlos durch ein SetProp() gesetzt werden. Es wird
+    nur dann beruecksichtigt, wenn die Ruestung/Waffe getragen/benutzt wird.
+    Beim Tragen/Ausziehen/Zuecken/Wegstecken wird im Spieler automatisch
+    UpdateAttributes() aufgerufen.
+
+    Fuer Krankheiten etc. oder Objekte, deren *Besitz* allein schon die
+    Attribute veraendern sollen, verwendet man besser P_X_ATTR_MOD.
+
+    P_X_ATTR_MOD und P_M_ATTR_MOD duerfen einen gemeinsamen kumulierten
+    positiven Grenzwert nicht ueberschreiten. Dieser Grenzwert,
+    CUMULATIVE_ATTR_LIMIT, ist in /sys/living/attributes.h definiert.
+
+BEMERKUNGEN
+-----------
+::
+
+    Die Werte sollten moeglichst nicht dynamisch geaendert werden.
+    Wenn doch, muss mit TestLimitViolation() am Spieler auf Validitaet
+    geprueft und ggf. mit UpdateAttributes() an ihm upgedatet werden.
+
+BEISPIELE
+---------
+::
+
+    // Dem Spieler, der das Objekt benutzt, wird 2 von A_INT abgezogen und
+    // dafuer 1 auf A_STR aufaddiert.
+    SetProp(P_M_ATTR_MOD, ([A_INT:-2, A_STR:1]) );
+
+SIEHE AUCH
+----------
+::
+
+    QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+    SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+    SetTimedAttrModifier(), QueryTimedAttrModifier(),
+    DeleteTimedAttrModifier(),
+    P_X_HEALTH_MOD, P_M_HEALTH_MOD, P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS,
+    P_TIMED_ATTR_MOD, P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+02.02.2016, Gloinson
+
diff --git a/doc/sphinx/props/P_M_HEALTH_MOD.rst b/doc/sphinx/props/P_M_HEALTH_MOD.rst
new file mode 100644
index 0000000..d04d0d7
--- /dev/null
+++ b/doc/sphinx/props/P_M_HEALTH_MOD.rst
@@ -0,0 +1,64 @@
+P_M_HEALTH_MOD
+==============
+
+NAME
+----
+::
+
+     P_M_HEALTH_MOD                  "magic_health_modifier"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mapping, mit dem die maximalen Lebenspunkte und Magiepunkte eines 
+     Spielers veraendert werden, der diese Ruestung/Waffe traegt/benutzt. Im 
+     Gegensatz zu P_M_ATTR_MOD erfolgt hier jedoch keine Blockade.
+
+     Zu beachten: P_M_HEALTH_MOD kann problemlos durch ein SetProp() gesetzt 
+     werden, es wird nur beruecksichtigt, wenn die Ruestung/Waffe 
+     getragen/benutzt wird. Beim tragen/ausziehen/zuecken/wegstecken wird im 
+     Spieler automatisch UpdateAttributes() aufgerufen.
+
+     Fuer Krankheiten etc. verwendet man besser die Property P_X_HEALTH_MOD.
+
+     Bitte beachten: Die positiven Modifier werden nicht mehr 1:1 auf die
+     Lebens- und Magiepunkte draufaddiert. Stattdessen wird nur noch ein 
+     gewisser Teil dort hinzuaddiert, der mit groesserer Menge von Punkten
+     zunimmt, und im unteren Bereich grob dem Wert entspricht. Das 
+     theoretische Maximum ist insgesamt 149.
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Werte sollten moeglichst nicht dynamisch geaendert werden.
+     Wenn doch, muss mit TestLimitViolation() am Spieler auf Validitaet 
+     geprueft werden und mit UpdateAttributes() an ihm ggf. upgedatet.
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_M_HEALTH_MOD,([P_HP:5,P_SP:-5]));
+     // Dem Spieler, der das Objekt benutzt, wird P_MAX_HP um 5 erhoeht und
+     // P_MAX_SP um 5 erniedrigt.
+
+SIEHE AUCH
+----------
+::
+
+     P_X_HEALTH_MOD, P_X_ATTR_MOD, P_M_ATTR_MOD, balance
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    Fre,11.05.2007, 00:20 von Humni
+
diff --git a/doc/sphinx/props/P_NAME.rst b/doc/sphinx/props/P_NAME.rst
new file mode 100644
index 0000000..a50981f
--- /dev/null
+++ b/doc/sphinx/props/P_NAME.rst
@@ -0,0 +1,85 @@
+P_NAME
+======
+
+NAME
+----
+::
+
+     P_NAME "name"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property wird der Name eines Objektes vermerkt. Wenn der Name
+     regelmaessig dekliniert wird, reicht ein einfacher String. Wird der
+     Name unregelmaessig dekliniert, so kann man ein Array von vier Strings
+     mit dem Namen im Nominativ, Genitiv, Dativ und Akkusativ (in dieser
+     Reihenfolge) angeben.
+
+     Die Funktion name() behandelt recht viele Sonderfaelle; man sollte den
+     Namen also erst einmal in der Form eines einzelnen Strings pruefen.
+
+     Eine Sonderrolle nehmen Unit-Objekte ein: Hier kann man einen Namen
+     fuer den Singular und einen Namen fuer den Plural vergeben.
+
+     Setzt man P_NAME eines Unit-Objekts auf einen einfachen String, so wird
+     dieser als Name sowohl im Singular als auch im Plural verwendet.
+
+     Uebergibt man ein Array von Strings, so wird der erste Eintrag fuer den
+     Singular und der zweite Eintrag fuer den Plural benutzt.
+
+     Bei Unit-Objekten ist es nicht moeglich, auch noch zwischen den
+     verschiedenen Faellen zu unterscheiden.
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Property sollte nur den reinen Namen enthalten; will man dem
+     Namen noch Adjektive voranstellen, so sollte man dies mit P_NAME_ADJ
+     bewerkstelligen, also statt
+
+     SetProp(P_NAME, ({ "alter Hut", "alten Huts",
+                        "alten Hut", "alten Hut" }) );
+
+     besser
+
+     SetProp(P_NAME, "Hut");
+     SetProp(P_NAME_ADJ, "alt");
+
+     Bei Lebewesen wird lower_case(P_NAME) (bei Arrays das erste Element 
+     daraus) automatisch als LivingName gesetzt.
+
+BEISPIELE
+---------
+::
+
+     Ein regelmaessig deklinierbarer Name:
+
+     SetProp(P_NAME, "Arkshat");
+
+     Hier ein Beispiel fuer einen unregelmaessig deklinierbaren Namen:
+
+     SetProp(P_NAME, ({ "Drache", "Drachen", "Drachen", "Drachen" }));
+
+     Und schliesslich der Name eines allseits bekannten Unit-Objektes:
+
+     SetProp(P_NAME, ({ "Muenze", "Muenzen" }));
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/description.c, name(), P_NAME_ADJ, set_living_name(),
+     find_living(), find_livings()
+
+
+Last modified: 19. Okt. 2015, Arathorn. 
+
diff --git a/doc/sphinx/props/P_NAME_ADJ.rst b/doc/sphinx/props/P_NAME_ADJ.rst
new file mode 100644
index 0000000..815c9a6
--- /dev/null
+++ b/doc/sphinx/props/P_NAME_ADJ.rst
@@ -0,0 +1,74 @@
+P_NAME_ADJ
+==========
+
+NAME
+----
+::
+
+     P_NAME_ADJ "name_adj"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt ein oder mehrere Adjektive in Form eines Arrays
+     von Strings. Es ist nur der Wortstamm anzugeben! Die Adjektive werden
+     von der Funktion name() dekliniert und vor den Namen gesetzt, wirken
+     also als Aufzaehlung von Adjektiven vor dem Namen.
+
+     Die hier angegebenen Adjektive dienen nur zur Ausgabe! Soll sich das
+     Objekt auch ueber Adjektive ansprechen lassen, muss man diese mit
+     AddAdjective() uebergeben.
+
+     Soll das Objekt nur ein einzelnes Namensadjektiv besitzen, kann man dem
+     SetProp()-Aufruf auch einen String uebergeben; gespeichert wird die
+     Property aber in jedem Fall als Array.
+
+     Wenn ein Adjektiv unregelmaessig ist, kann man die vier Faelle auch
+     als Array uebergeben. Man muss dann aber Arrays schachteln, damit von den
+     mehrfachen Adjektiven unterschieden werden kann.
+
+	
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_NAME, "Hut");
+     SetProp(P_NAME_ADJ, "alt");
+
+     name(WESSEN,1)      => "des alten Huts"
+
+
+     // Zwei Adjektive, gleichrangig zu Substantiv
+     SetProp(P_NAME_ADJ, ({"alt", "gammelig"}));
+
+     name(WESSEN,1)      => "des alten, gammeligen Huts"
+
+
+     // Zwei Adjektive, erstes ist Attribut zu zweitem
+     falsch:  SetProp(P_NAME_ADJ, ({"gruen", "gestreift"}));
+              name(WESSEN,1)      => "des gruenen, gestreiften Huts"
+     richtig: SetProp(P_NAME_ADJ, ({"gruen gestreift"}));
+              name(WESSEN,1)      => "des gruen gestreiften Huts"
+
+     // Unregelmaessiges Adjektiv
+     SetProp( P_NAME_ADJ,({({"rosa","rosa","rosa","rosa"})});
+              name(WESSEN,1)         => "des rosa Huts"
+     // Ohne inneres Array haette man 4 mal rosa als Adjektiv
+     // => "des rosaen, rosaen, rosaen, rosaen Huts"
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/description.c, name(), P_NAME, DeclAdj()
+
+23.April 2007 Rumata
+
diff --git a/doc/sphinx/props/P_NEEDED_QP.rst b/doc/sphinx/props/P_NEEDED_QP.rst
new file mode 100644
index 0000000..3b084e6
--- /dev/null
+++ b/doc/sphinx/props/P_NEEDED_QP.rst
@@ -0,0 +1,31 @@
+P_NEEDED_QP
+===========
+
+NAME
+----
+::
+
+    P_NEEDED_QP                   "needed_qp"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     APs, die man fuer den Seherstatus braucht
+
+     Diese Property ist mittlerweile obsolet. Die
+     aktuell geltenden Seher-Anforderungen stehen in
+     /secure/lepmaster.h
+
+LETZTE AENDERUNG
+----------------
+::
+
+     2006-09-30, Zook.
+
diff --git a/doc/sphinx/props/P_NETDEAD_ENV.rst b/doc/sphinx/props/P_NETDEAD_ENV.rst
new file mode 100644
index 0000000..a87cf51
--- /dev/null
+++ b/doc/sphinx/props/P_NETDEAD_ENV.rst
@@ -0,0 +1,43 @@
+P_NETDEAD_ENV
+=============
+
+NAME
+----
+::
+
+    P_NETDEAD_ENV                  "netdead_env"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property kann in netztoten Spielern abgefragt werden,
+		um herauszufinden, in welchem Raum sie netztot geworden sind.
+
+		Es wird der selbe Wert zurueckgegeben, den die Mudlib benutzen
+		wuerde, um die Spieler beim reconnect wieder an den richtigen
+		ort zu bringen. Das ist normalerweise das Raumobjekt oder der
+		Dateiname des Raums (zum Beispiel so dieser ein clone war).
+
+		Bei nicht netztoten Spielern wird 0 zurueckgegeben.
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Property ist read-only.
+
+SIEHE AUCH
+----------
+::
+
+    P_NETDEAD_INFO
+
+2009-08-04 Rumata
+
diff --git a/doc/sphinx/props/P_NETDEAD_INFO.rst b/doc/sphinx/props/P_NETDEAD_INFO.rst
new file mode 100644
index 0000000..b1fc201
--- /dev/null
+++ b/doc/sphinx/props/P_NETDEAD_INFO.rst
@@ -0,0 +1,120 @@
+P_NETDEAD_INFO
+==============
+
+NAME
+----
+::
+
+    P_NETDEAD_INFO                "netdead_info"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wird im Raum X gesetzt und wirkt nur, falls dieser Raum ein '#' im
+     object_name() hat (normale Clones, zB "/room/void#10153018").
+
+     
+
+     Bei Einschlafen eines Spielers in diesem Raum werden die Werte aus
+     der Property im Spieler gespeichert (Netztoteninformationen).
+
+     Ist beim Aufwachen des Spielers das Raumobjekt X zerstoert worden, dann
+     wird bei der Blueprint von X per SetProp() die gespeicherte Information
+     gesetzt. Der Rueckgabewert des SetProp wird als Pfad zu einem Ausweich-
+     Aufwach-Raum interpretiert und der Spieler wird in dem Fall dorthin
+     bewegt.
+
+BEMERKUNGEN
+-----------
+::
+
+     Zum Clonen von Raeumen sollten Virtual Compiler benutzt werden:
+     Wird in den erzeugten Objektnamen KEIN '#' verwendet, dann ist diese
+     Property nicht sinnvoll und wird nicht verwendet. Ein ordentlicher
+     VC kann Bewegen eines Spielers in dessen alten, nicht mehr existierenden
+     Raum oder einen Ersatzraum beim Aufwachen selbst loesen.
+
+BEISPIELE
+---------
+::
+
+     // #1: geclonter Raum mit Ausweich-Aufwachraum: Klerus-Gilde
+     #include <properties.h>
+     inherit "/std/room";
+
+     
+
+     void create() {
+       ::create();
+
+       SetProp(P_NETDEAD_INFO, "/gilden/klerus");
+       SetProp(P_LIGHT, 1);
+     }
+
+     
+
+     // #2: komplexerer Beispielraum fuer P_NETDEAD_INFO-Funktionalitaet
+     // Siehe auch: /doc/beispiele/testobjekte/netdead_info_testraum.c
+     #include <properties.h>
+     inherit "/std/room";
+
+     void create() {
+       ::create();
+
+       if (clonep(this_object()))
+         // setze Informationen, die im Netztoten gespeichert werden sollen
+         Set(P_NETDEAD_INFO, random(5));
+       else
+         // Blueprint: hier kann man zu einem Cloneraum gehen
+         AddExit("cloneraum", #'create_room);
+
+       // Set-Method, um die Informationen aus P_NETDEAD_INFO beim Aufwachen
+       // in der Blueprint auswerten zu koennen
+       Set(P_NETDEAD_INFO, #'create_destiny, F_SET_METHOD);
+       SetProp(P_LIGHT, 1);
+     }
+
+     
+
+     // Raum entfernen, normalerweise so KEINE GUTE IDEE!
+     void BecomesNetDead(object pl) {
+       call_out(#'remove, 30);
+     }
+
+     // erzeuge einen Cloneraum und bewege den Spieler dahin
+     int create_room(string dir) {
+       object dest = clone_object(object_name(this_object()));
+       this_player()->move(dest, M_NOCHECK);
+       return 1;
+     }
+
+     
+
+     // Set-Method fuer P_NETDEAD_INFO: gibt Pfad zurueck
+     // benutze die Informationen aus dem jetzt aufwachenden Netztoten, um
+     // einen alternativen Aufwachraum zu ermitteln, da der Einschlafraum
+     // zerstoert ist
+     string create_destiny(mixed val) {
+       if (intp(val)) {
+         switch (val) {
+           case 0:
+             return "/d/ebene/room/PortVain/po_haf1";
+           case 1:
+             return "/gilden/klerus";
+           case 2:
+             return "/gilden/karate";
+           default:
+         }
+         return "/d/ebene/room/waldweg4";
+       }
+     }
+
+2. Jan 2012 Gloinson
+
diff --git a/doc/sphinx/props/P_NEVERDROP.rst b/doc/sphinx/props/P_NEVERDROP.rst
new file mode 100644
index 0000000..3c4b161
--- /dev/null
+++ b/doc/sphinx/props/P_NEVERDROP.rst
@@ -0,0 +1,51 @@
+P_NEVERDROP
+===========
+
+NAME
+----
+::
+
+	P_NEVERDROP			"neverdrop"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+	Objekte, welche diese Property gesetzt haben, werden beim Tod eines
+	Lebewesens nicht automatisch in die Leiche oder in den umgebenden
+	Raum (z.B. bei bei gesetztem P_NOCORPSE) transportiert.
+
+BEMERKUNGEN
+-----------
+::
+
+	Soll das Objekt vom Lebewesen nicht weggelegt werden koennen, so ist
+	die Property P_NODROP zu verwenden.
+	Beide Properties zusammen stellen sicher, dass ein Objekt nicht
+	weitergegeben werden kann.
+
+BEISPIELE
+---------
+::
+
+	Eine dauerhafte Belohnung, die auch beim Tod des Spielers bei ihm
+	verbleiben soll, setzt das so:
+	  SetProp(P_NEVERDROP,1);
+	Sollen auch Reboots ueberstanden werden, ist zusaetzlich
+	P_AUTOLOADOBJ zu setzen.
+
+SIEHE AUCH
+----------
+::
+
+	P_NODROP, P_NOGET, P_NOCORPSE, P_AUTOLOADOBJ, /std/living/life.c
+
+
+Last modified: Thu Jun 14 22:26:29 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_NEVER_CLEAN.rst b/doc/sphinx/props/P_NEVER_CLEAN.rst
new file mode 100644
index 0000000..3d50a4e
--- /dev/null
+++ b/doc/sphinx/props/P_NEVER_CLEAN.rst
@@ -0,0 +1,54 @@
+P_NEVER_CLEAN
+=============
+
+NAME
+----
+::
+
+	P_NEVER_CLEAN			" never clean "                   
+
+DEFINIERT IN
+------------
+::
+
+	/sys/rooms.h
+
+BESCHREIBUNG
+------------
+::
+
+	Normalerweise wird ein Raum nach 2 Resets zerstoert, wenn er waerend
+	dieser Zeit von keinem Lebewesen betreten wurde und wenn
+	keine REFRESH_NONE- oder REFRESH_DESTRUCT-Objekte existieren, die
+	nicht mehr im Raum vorhanden sind.
+	Mit dieser Property kann man den sogenannten Clean-Up unterbinden.
+
+BEISPIEL
+--------
+::
+
+	Der folgende Raum wird nicht mehr zerstoert, wenn er einmal geladen
+	wurde:
+	  #include <properties.h>
+	  // #include <rooms.h> ... wird schon von properties.h included!
+	  inherit "std/room";
+	  void create()
+	  { ::create();
+	    SetProp(P_SHORT,"Ein toller Raum");
+	    ...
+	    SetProp(P_NEVER_CLEAN,1);
+	    ...
+	  }
+	Man sollte die Anwendung nicht uebertreiben! Wichtig ist diese
+	Funktion zum Beispiel fuer Raeume, die gleichzeitig Masterobjekte
+	darstellen.
+
+SIEHE AUCH
+----------
+::
+
+	/std/room.c
+
+
+Last modified: Wed Feb  3 00:54:32 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_NEWSKILLS.rst b/doc/sphinx/props/P_NEWSKILLS.rst
new file mode 100644
index 0000000..066f50c
--- /dev/null
+++ b/doc/sphinx/props/P_NEWSKILLS.rst
@@ -0,0 +1,39 @@
+P_NEWSKILLS
+===========
+
+NAME
+----
+::
+
+	P_NEWSKILLS			"newskills"                   
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property sind saemtliche Skills und Spells vermerkt, die
+	das Lebewesen kennt.
+
+BEMERKUNGEN
+-----------
+::
+
+	Man sollte diese Property nicht per Hand veraendern, sondern die
+	Funktionen von "/std/living/skills.c" nutzen.
+
+SIEHE AUCH
+----------
+::
+
+	ModifySkill(), LearnSkill(), UseSkill(), /std/living/skills.c,
+	P_GUILD_SKILLS, P_SB_SPELLS
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_NEXT_DEATH_SEQUENCE.rst b/doc/sphinx/props/P_NEXT_DEATH_SEQUENCE.rst
new file mode 100644
index 0000000..eb4e85a
--- /dev/null
+++ b/doc/sphinx/props/P_NEXT_DEATH_SEQUENCE.rst
@@ -0,0 +1,68 @@
+P_NEXT_DEATH_SEQUENCE
+=====================
+
+NAME
+----
+::
+
+     P_NEXT_DEATH_SEQUENCE         "p_lib_next_death_sequence"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Im Spieler kann damit dessen eigene Todessequenz fuer den naechsten
+     Tod festgelegt werden. Nach einem Tod (egal welche Todessequenz
+     gewaehlt wurde) wird die Property geloescht und muesste neu gesetzt
+     werden.
+
+     Es gibt folgende gueltige Werte:
+     - string: Pfad zu einer eigenen Todessequenz im gueltigen Format
+     - mixed*  Eine Todessequenz im Format des Todesraumes:
+               ({<int gesamtlaenge>,
+                 ([<int index1>: <string umgebrochene Meldung1>,
+                   <int index2>: <string umgebrochene Meldung2>,
+                   ...])
+               })
+     - mapping In die Standard-Lars-Todessequenz einzufuegende Zeilen:
+               ([<int zeitindex>: <string umgebrochener Text>])
+
+BEMERKUNGEN
+-----------
+::
+
+     Eine Todessequenz eines Gegners, festgelegt ueber
+     P_ENEMY_DEATH_SEQUENCE hat Vorrang vor dieser Property.
+
+BEISPIELE
+---------
+::
+
+     // Pfad zu einer eigenen DSQ
+     SetProp(P_NEXT_DEATH_SEQUENCE,  ".../passende_dsq.txt");
+
+     // eigene DSQ im Todesraumformat:
+     SetProp(P_NEXT_DEATH_SEQUENCE,
+             ({ 2, ([1: "Der Tod entlaesst dich eilig.\n"])}));
+
+     // Einfuegen einer Meldung in die Standard-Todessequenz
+     SetProp(P_NEXT_DEATH_SEQUENCE,
+             ([5: "Du fuehlst dich etwas daemlich.\n"]));
+
+SIEHE AUCH
+----------
+::
+
+     Tod:            die(L)
+     Todesmeldungen: P_KILL_NAME, P_KILL_MSG, P_DIE_MSG, P_MURDER_MSG
+                     P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
+     Sonstiges:      P_CORPSE, P_NOCORPSE, /room/death/death_room.c
+
+10. Nov 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_NEXT_DISABLE_ATTACK.rst b/doc/sphinx/props/P_NEXT_DISABLE_ATTACK.rst
new file mode 100644
index 0000000..2b2357f
--- /dev/null
+++ b/doc/sphinx/props/P_NEXT_DISABLE_ATTACK.rst
@@ -0,0 +1,52 @@
+P_NEXT_DISABLE_ATTACK
+=====================
+
+PROPERTY
+--------
+::
+
+  P_NEXT_DISABLE_ATTACK    "next_diable_attack"
+
+DEFINIERT IN 
+-------------
+::
+
+  combat.h
+
+BESCHREIBUNG
+------------
+::
+
+  Diese Property gibt an, wann der NPC das naechste Mal paralysiert
+  werden kann. Ueblicherweise wird sie automatisch beim Setzen
+  von P_DISABLE_ATTACK gesetzt. Sie gibt einen Zeitpunkt wie
+  die Funktion time() an, an dem zum ersten Mal wieder Paralyse
+  moeglich ist.
+
+  Will man einen NPC schreiben, der immer paralysierbar ist und nicht erst
+  nach einer gewissen Wartezeit nach der letzten Paralyse, laesst sich dies
+  durch eine Set-Methode auf P_NEXT_DISABLE_ATTACK erreichen:
+
+    
+
+  Set(P_NEXT_DISABLE_ATTACK, function int () {return 0;}, F_SET_METHOD);
+
+  Diese Set-Methode verhindert das Setzen von P_NEXT_DISABLE_ATTACK mittels
+  eines SetProp-Aufrufes.
+
+BEMERKUNGEN
+-----------
+::
+
+  Die Zeit zum Schutz vor erneuter Paralyse existiert absichtlich. Bitte
+  waegt sorgfaeltig ab, bevor ihr diese Property an Gegnern/Spielern
+  manipuliert.
+
+SIEHE AUCH
+----------
+::
+
+  P_DISABLE_ATTACK
+
+21.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/props/P_NOBUY.rst b/doc/sphinx/props/P_NOBUY.rst
new file mode 100644
index 0000000..fc880f0
--- /dev/null
+++ b/doc/sphinx/props/P_NOBUY.rst
@@ -0,0 +1,23 @@
+P_NOBUY
+=======
+
+NAME
+----
+::
+
+    P_NOBUY                       "nobuy"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn diese Property gesetzt ist, wird das Objekt nach einem
+     Verkauf im Laden zerstoert, damit es nicht wieder von einem Spieler
+     gekauft werden kann.
+
diff --git a/doc/sphinx/props/P_NOCORPSE.rst b/doc/sphinx/props/P_NOCORPSE.rst
new file mode 100644
index 0000000..cf45f20
--- /dev/null
+++ b/doc/sphinx/props/P_NOCORPSE.rst
@@ -0,0 +1,52 @@
+P_NOCORPSE
+==========
+
+NAME
+----
+::
+
+	P_NOCORPSE			"nocorpse"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property ist gesetzt, wenn im Todesfall kein Leichnam
+	automatisch erzeugt werden soll.
+
+BEMERKUNGEN
+-----------
+::
+
+	In diesem Fall wird die Property P_CORPSE ignoriert, mit der man
+	ein spezielles Leichenobjekt angeben kann, sofern nicht die
+	Standardleiche "/std/corpse.c" verwendet werden soll.
+	Da die Moerdermeldungen ueber ebendiese Objekt laufen, werden
+	hierbei auch keine ausgegeben.
+
+BEISPIELE
+---------
+::
+
+	Das Lebewesen soll keine Leiche hinterlassen, weil es zu Staub
+	zerfaellt:
+	  SetProp(P_DIE_MSG," zerfaellt zu Staub!\n");
+	  SetProp(P_NOCORPSE,1)
+	Es wurde auch gleich die Sterbemeldung dementsprechend gesetzt.
+
+SIEHE AUCH
+----------
+::
+
+	P_CORPSE, P_ZAP_MSG, P_DIE_MSG, P_MURDER_MSG, P_KILL_MSG,
+	P_NEVERDROP, /std/corpse.c
+
+
+Last modified: Thu Jun 14 22:26:29 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_NODRINK_MSG.rst b/doc/sphinx/props/P_NODRINK_MSG.rst
new file mode 100644
index 0000000..82a4798
--- /dev/null
+++ b/doc/sphinx/props/P_NODRINK_MSG.rst
@@ -0,0 +1,51 @@
+P_NODRINK_MSG
+=============
+
+NAME
+----
+::
+
+     P_NODRINK_MSG                 "std_food_nodrink_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn versucht wird, ein Nicht-Getraenk
+     zu trinken. Sobald eine Speise einen Wert in P_FOOD setzt, gilt es als
+     Nicht-Getraenk.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "@WEN1 kann man nicht trinken!"
+
+SIEHE AUCH
+----------
+::
+
+     P_FOOD, P_DRINK, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_NODROP.rst b/doc/sphinx/props/P_NODROP.rst
new file mode 100644
index 0000000..8c3102f
--- /dev/null
+++ b/doc/sphinx/props/P_NODROP.rst
@@ -0,0 +1,61 @@
+P_NODROP
+========
+
+NAME
+----
+::
+
+	P_NODROP			"nodrop"                      
+
+DEFINIERT IN
+------------
+::
+
+	/sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+	Ist diese Property in einem Objekt gesetzt, so kann ein Lebewesen
+	das Objekt nicht weglegen.
+	Als Standardmeldung kommt in diesem Fall beispielsweise:
+	  Du kannst <Objektname> nicht wegwerfen!
+	  Du kannst <Objektname> nicht weggeben.
+	Man kann auch eine alternative Meldung angeben, wobei selbstaendig
+	auf einen korrekten Zeilenumbruch zu achten ist.
+
+BEMERKUNGEN
+-----------
+::
+
+	Soll ein Objekt beim Tod des Lebewesens oder bei Ende eines Spielers
+	nicht in der Leiche bzw. im Raum zurueckgelassen werden, so ist
+	die Property P_NEVERDROP zu nutzen.
+	Beide Properties zusammen stellen sicher, dass ein Objekt nicht
+	weitergegeben werden kann.
+
+BEISPIELE
+---------
+::
+
+	Ein schwer zu erkaempfender Dolch koennte folgendes beinhalten,
+	um nicht weitergegeben werden zu koennen:
+	  SetProp(P_NODROP,1);
+	Informativer jedoch ist eine eigene Meldung:
+	  SetProp(P_NODROP,
+	 "Den Dolch hast Du Dir hart erkaempft, nicht wegwerfen!\n");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_NOGET, P_NEVERDROP, 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
+
+
+Last modified: Thu Jun 14 22:26:29 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_NOFOOD_MSG.rst b/doc/sphinx/props/P_NOFOOD_MSG.rst
new file mode 100644
index 0000000..3276983
--- /dev/null
+++ b/doc/sphinx/props/P_NOFOOD_MSG.rst
@@ -0,0 +1,51 @@
+P_NOFOOD_MSG
+============
+
+NAME
+----
+::
+
+     P_NOFOOD_MSG                  "std_food_nofood_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn versucht wird, ein Getraenk zu essen.
+     Sobald eine Speise keinen Wert in P_FOOD und einen Wert in P_DRINK
+     setzt, gilt es als Getraenk.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "@WEN1 kann man nicht essen!"
+
+SIEHE AUCH
+----------
+::
+
+     P_FOOD, P_DRINK, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_NOGET.rst b/doc/sphinx/props/P_NOGET.rst
new file mode 100644
index 0000000..9e231fd
--- /dev/null
+++ b/doc/sphinx/props/P_NOGET.rst
@@ -0,0 +1,50 @@
+P_NOGET
+=======
+
+NAME
+----
+::
+
+	P_NOGET				"noget"
+
+DEFINIERT IN
+------------
+::
+
+	/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.
+
+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.
+
+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
+
+
+Last modified: Thu Jun 14 22:26:29 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_NOINSERT_MSG.rst b/doc/sphinx/props/P_NOINSERT_MSG.rst
new file mode 100644
index 0000000..f7e510b
--- /dev/null
+++ b/doc/sphinx/props/P_NOINSERT_MSG.rst
@@ -0,0 +1,65 @@
+P_NOINSERT_MSG
+==============
+
+NAME
+----
+::
+
+    P_NOINSERT_MSG                      "noinsert_msg"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn
+     jemand versucht, ein Objekt in einen Behaelter zu bewegen und der
+     Behaelter dieses im PreventInsert() verhindert.
+     Die Property ist im Zielbehaelter zu setzen.
+     Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
+     so wird die Standardmeldung ausgegeben.
+     ("<Objekt> kannst Du dort nicht hineinstecken.")
+     Der String in der Property wird noch durch replace_personal()
+     verarbeitet, das zu bewegende Objekt wird als erstes, der Zielbehaelter
+     als zweites Objekt angegeben. Danach wird der String auf 78 Zeichen
+     umgebrochen.
+     Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
+     ganz.
+
+BEISPIELE
+---------
+::
+
+     1. Ein Kochtopf laesst im PreventInsert nur bestimmte Objekte zu, die zu
+     einer Suppe gehoeren. Fuer eine passende Meldung wird im Topf jetzt die
+     Property gesetzt:
+     SetProp(P_NOINSERT_MSG, "Du kannst @WEN1 nicht in den Kochtopf tun, da"
+	                     " gehoeren doch nur Suppenzutaten rein!");
+     Wenn jemand jetzt versucht, eine Muenze reinzustecken, dann wuerde
+     folgende Meldung erscheinen:
+	Du kannst die Muenze nicht in den Kochtopf tun, da gehoeren doch nur
+	Suppenzutaten rein!
+
+     2. Ein Rucksack soll in einer bestimmten Reihenfolge gepackt werden, dazu
+     kann im PreventInsert die Meldung je nach Bedarf gesetzt werden:
+     if (<objekt noch nicht an der Reihe>)
+	SetProp(P_NOINSERT_MSG, "@WEN1 solltest du erst spaeter einpacken.");
+     else if (<objekt schon im Rucksack>)
+	SetProp(P_NOINSERT_MSG, "Aber @WER1 ist doch schon eingepackt!");
+     else ...
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
+                 P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     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
+
diff --git a/doc/sphinx/props/P_NOLEAVE_MSG.rst b/doc/sphinx/props/P_NOLEAVE_MSG.rst
new file mode 100644
index 0000000..0518409
--- /dev/null
+++ b/doc/sphinx/props/P_NOLEAVE_MSG.rst
@@ -0,0 +1,52 @@
+P_NOLEAVE_MSG
+=============
+
+NAME
+----
+::
+
+    P_NOLEAVE_MSG                      "noleave_msg"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn
+     jemand versucht, ein Objekt aus einem Behaelter zu entfernen und der
+     Behaelter dieses im PreventLeave() verhindert.
+     Die Property ist im verhindernden Behaelter zu setzen.
+     Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
+     so wird die Standardmeldung ausgegeben.
+     ("Du kannst <Objekt> nicht nehmen.")
+     Der String in der Property wird noch durch replace_personal()
+     verarbeitet, das zu bewegende Objekt wird als erstes, der verhindernde
+     Behaelter als zweites Objekt angegeben. Danach wird der String auf 78
+     Zeichen umgebrochen.
+     Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
+     ganz.
+
+BEISPIELE
+---------
+::
+
+     Nur Bierschuettler sollen eine Bierflasche aus einem Kasten nehmen
+     koennen, neben einer entsprechenden Behandlung im PreventLeave setzt man
+     dazu die Property:
+     SetProp(P_NOLEAVE_MSG, "Nur Bierschuettler duerfen das!");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
+                 P_NOINSERT_MSG, P_NODROP, P_NOGET 
+     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
+
diff --git a/doc/sphinx/props/P_NOMAGIC.rst b/doc/sphinx/props/P_NOMAGIC.rst
new file mode 100644
index 0000000..9f31acc
--- /dev/null
+++ b/doc/sphinx/props/P_NOMAGIC.rst
@@ -0,0 +1,42 @@
+P_NOMAGIC
+=========
+
+NAME
+----
+::
+
+    P_NOMAGIC                     "nomagic"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Angabe in Prozent, mit welcher Wahrscheinlichkeit Magie fehlschlaegt.
+
+     
+
+     Fuer einen Raum ist es eine generelle Aussage, wie wahrscheinlich ein
+     Spell in ihm fehlschlaegt. Bei NPC zeigt es an, wie wahrscheinlich
+     ein auf ihn gesprochener Spell fehlschlaegt.
+
+BEISPIEL
+--------
+::
+
+     // in einem Raum keine Spells zulassen
+     SetProp(P_NOMAGIC, 100)
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:     P_MAGIC_RESISTANCE_OFFSET, SpellDefend
+
+29.Dez 2007 Gloinson
+
diff --git a/doc/sphinx/props/P_NOSELL.rst b/doc/sphinx/props/P_NOSELL.rst
new file mode 100644
index 0000000..e716c37
--- /dev/null
+++ b/doc/sphinx/props/P_NOSELL.rst
@@ -0,0 +1,51 @@
+P_NOSELL
+========
+
+NAME
+----
+::
+
+    P_NOSELL                      "nosell"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn diese Property gesetzt ist, kann das Objekt nicht in einem
+     Laden verkauft werden.
+     Gibt man in der Property einen String an, wird dieser ausgegeben,
+     ansonsten erfolgt eine Meldung "Du kannst <NAME> nicht verkaufen!"
+
+     Diese Meldung beinhaltet auch den Namen des in P_NAME einge-
+     tragenen Besitzer des Ladens. Ist dies nicht gesetzt, wird per
+     default 'Der Haendler' ausgegeben.
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_NOSELL,"Den Schrott behaeltst Du lieber selber.");
+
+     ==> Apu sagt: Den Schrott behaeltst Du lieber selber.
+     ==> Der Haendler sagt: Den Schrott behaeltst Du lieber selber.
+
+     SetProp(P_NOSELL,1);
+
+     ==> Apu sagt: Du kannst <name> nicht verkaufen!
+     ==> Der Haendler sagt: Du kannst <name> nicht verkaufen!
+
+SIEHE AUCH
+----------
+::
+
+     P_NOBUY, P_NODROP, P_KEEPER
+
+
+03.09.2010, Zesstra
+
diff --git a/doc/sphinx/props/P_NO_ASCII_ART.rst b/doc/sphinx/props/P_NO_ASCII_ART.rst
new file mode 100644
index 0000000..5ba9bdc
--- /dev/null
+++ b/doc/sphinx/props/P_NO_ASCII_ART.rst
@@ -0,0 +1,37 @@
+P_NO_ASCII_ART
+==============
+
+NAME
+----
+::
+
+    P_NO_ASCII_ART                   "no_ascii_art"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property kann der Spieler mit dem Befehl "grafik aus" auf
+    1 setzen. Damit zeigt er an, dass er keine ASCII Art sehen moechte.
+
+    Wer ASCII-Art einsetzt, sollte an diesen Stellen die Property 
+    abfragen und textliche Umschreibungen oder Alternativloesungen
+    einbauen.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+    grafik
+
+
+    Letzte Aenderung: 2005-10-18, Zook.   
+
diff --git a/doc/sphinx/props/P_NO_ATTACK.rst b/doc/sphinx/props/P_NO_ATTACK.rst
new file mode 100644
index 0000000..bd2ad4d
--- /dev/null
+++ b/doc/sphinx/props/P_NO_ATTACK.rst
@@ -0,0 +1,99 @@
+P_NO_ATTACK
+===========
+
+NAME
+----
+::
+
+     P_NO_ATTACK "no_attack"
+
+DEFINIERT IN
+------------
+::
+
+     <living/combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn ein NPC nicht angreifbar sein soll (weil er zum Beispiel in einer
+     Gilde oder einer Quest Informationen vermittelt oder aehnlichen), sollte
+     man diese Property auf einen Wert ungleich Null setzen. Sie wird immer
+     abgefragt, wenn ermittelt wird, ob ein Lebewesen prinzipiell angreifbar
+     ist. D.h. auch, dass nach Abfragen von P_NO_ATTACK _nicht_ immer ein
+     Kampf gestartet wird und dass man dabei _nicht_ im Kampf sein muss!
+
+     Gibt man hier einen String an (mit einem Satzzeichen und "\n" abge-
+     schlossen), wird dieser bei direkten Angriffen ausgegeben. Bei anderen
+     Datentypen wird eine Defaultmeldung ausgegeben. Die Defaultmeldung
+     lautet: "<Name> laesst sich nicht angreifen!\n"
+
+     Mit direkten Angriffen sind 'toete <name>' und Angriffszauber gemeint
+     (bzw. alles, was living/life::Kill(), spellbook::TryAttackSpell(),
+     spellbook::TryDefaultAttackSpell() und spellbook::FindEnemyVictim()
+     aufruft).
+
+ACHTUNG
+-------
+::
+
+  1) Zum Thema QueryMethoden auf P_NO_ATTACK
+     Grundsaetzlich legt man entweder eine Query-Methode auf P_NO_ATTACK:
+        Set(P_NO_ATTACK, #'my_no_attack, F_QUERY_METHOD);
+     oder definiert eine Funktion _query_no_attack() im NPC.
+
+     Wie muss nun eine solche Funktion aussehen? Z.B.:
+
+     
+
+     int|string my_no_attack() {
+       if (!objectp(this_player())) return 0;
+       if (opfer==getuid(this_player()) || this_player()==this_object())
+         return(0);
+       return(1); //nicht angreifbar
+     }
+
+     Diese Funktion macht den NPC nun nur fuer den Spieler 'opfer' angreifbar.
+     Stattdessen kann natuerlich auch jede andere Bedingung genutzt werden.
+
+     Aber warum die zweite Bedingung, this_player()==this_object()?
+     Warum sollte der NPC sich selber angreifen duerfen?
+
+     Das liegt an folgenden 2 Dingen:
+
+     1. Kaempfer kriegen bei eingeschaltetem Fokus Probleme, wenn man das 
+     nicht macht. Das liegt an folgendem: Wenn der NPC angreift, ruft er 
+     natuerlich Defend() im Spieler auf. Dieses schaut nach, ob der Spieler 
+     den Skill SK_MAGICAL_DEFENSE hat. Dieser ist bei Kaempfern das Parieren.
+     Dieses schaut nach, ob der Fokus aktiv ist, wenn ja, wird dem 
+     ge'fokus'te Gegner besonders gut ausgewichen. Zu diesem Zweck wird die 
+     Liste der Feind im Raum erstellt mit PresentEnemies() abgerufen. Dieses 
+     fragt aber in allen (potentiellen) Gegnern P_NO_ATTACK ab und beendet 
+     den Kampf mit allen Gegnern, die nicht angreifbar sind. Bei dieser 
+     Abfrage ist jedoch TP==NPC, weil der ja angreift. Wenn er nun 1 
+     zurueckgibt, wird der Kampf an der Stelle beendet. 
+
+     2. Wenn der NPC den Spieler angreift, wird im Spieler InsertEnemy(NPC)
+     aufgerufen. Auch diesem Fall findet die Abfrage von P_NO_ATTACK statt, 
+     da InsertEnemy() ja erstmal rausfinden muss, ob der Gegner angreifbar 
+     ist, bevor er in die Feindliste eingetragen wird. Da der NPC den 
+     Angriff beginnt, ist TP der NPC. Wenn die Query-Methode auf P_NO_ATTACK
+     hier abbricht, wird der NPC nicht in die Feindliste des Spielers 
+     eingetragen. Dann bekaempft der NPC den Spieler, aber der Spieler nicht
+     den NPC.
+
+
+  2) P_NO_ATTACK des NPC wird z.B. beim Kampf eines Kaempfers mit dem NPC 
+     pro Kampfrunde um die 10mal abgerufen. Wenn der Kaempfer nur eine 
+     Attacke macht. Wenn er noch Sonderattacken machen, Spells ausfuehrt, 
+     etc. wird das noch mehr. D.h. was auch immer ihr in der Query-Methode 
+     im NPC macht: 
+     Es sollte schnell sein, jeder Tick an Rechenzeit zaehlt hier xfach!
+
+LETZTE AENDERUNG
+----------------
+::
+
+09.11.2015, Arathorn
+
diff --git a/doc/sphinx/props/P_NO_BAD.rst b/doc/sphinx/props/P_NO_BAD.rst
new file mode 100644
index 0000000..81ff011
--- /dev/null
+++ b/doc/sphinx/props/P_NO_BAD.rst
@@ -0,0 +1,46 @@
+P_NO_BAD
+========
+
+NAME
+----
+::
+
+     P_NO_BAD                      "std_food_no_bad"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Flag, ob die Speise ewig haltbar ist.
+     0: Speise verdirbt nach der Anzahl Sekunden, die in P_LIFETIME
+        angegeben ist bzw. nach einem Reset
+     1: Speise verdirbt nicht
+
+     
+
+     ACHTUNG: Diese Property darf nur in Absprache mit der Balance
+              geaendert werden.
+
+     
+
+DEFAULT
+-------
+::
+
+     Initial ist diese Property auf 0 gesetzt.
+
+SIEHE AUCH
+----------
+::
+
+     /std/food.c, wiz/food
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_NO_GLOBAL_ATTACK.rst b/doc/sphinx/props/P_NO_GLOBAL_ATTACK.rst
new file mode 100644
index 0000000..a77ee9b
--- /dev/null
+++ b/doc/sphinx/props/P_NO_GLOBAL_ATTACK.rst
@@ -0,0 +1,34 @@
+P_NO_GLOBAL_ATTACK
+==================
+
+NAME
+----
+::
+
+     P_NO_GLOBAL_ATTACK "no_global_attack"
+
+DEFINIERT IN
+------------
+::
+
+     <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Setzt man diese Property in einem NPC auf einen Wert ungleich 0, so
+     wird der NPC bei einem "toete alle" nicht angegriffen.
+
+     Damit kann man zB. NPCs, die dem eigenen Schutz dienen (als Folge von
+     Zauberspruechen o.ae.) vor versehentlichen Angriffen schuetzen.
+
+SIEHE AUCH
+----------
+::
+
+     /std/npc.c, P_FRIEND
+
+
+Last modified: Sat May 18 15:26:28 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_NO_PARA_TRANS.rst b/doc/sphinx/props/P_NO_PARA_TRANS.rst
new file mode 100644
index 0000000..59f71d1
--- /dev/null
+++ b/doc/sphinx/props/P_NO_PARA_TRANS.rst
@@ -0,0 +1,30 @@
+P_NO_PARA_TRANS
+===============
+
+NAME
+----
+::
+
+	P_NO_PARA_TRANS				"no_para_trans"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+	Wenn in einem Raum diese Property gesetzt ist, darf dort kein
+	Wechsel in oder aus der Paralellwelt erfolgen. Objekte die so
+	einen Wechsel ermoeglichen sind dafuer verantwortlich diese
+	Property abzufragen.
+
+SIEHE AUCH
+----------
+::
+
+	P_NO_TPORT
+
diff --git a/doc/sphinx/props/P_NO_PLAYERS.rst b/doc/sphinx/props/P_NO_PLAYERS.rst
new file mode 100644
index 0000000..de235ed
--- /dev/null
+++ b/doc/sphinx/props/P_NO_PLAYERS.rst
@@ -0,0 +1,56 @@
+P_NO_PLAYERS
+============
+
+NAME
+----
+::
+
+    P_NO_PLAYERS                     "no_players"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/rooms.h
+
+BESCHREIBUNG
+------------
+::
+
+    Wenn in einem Raum die Property P_NO_PLAYERS auf einen Wert != 0 gesetzt
+    ist, kann dieser von Spielern auf normalem Wege nicht mehr betreten werden.
+    Magier und Testspieler(*) koennen den Raum betreten; Spieler muessen mit
+    M_NOCHECK hineinbewegt werden.
+
+    Auf diese Weise koennen Gebiete, die noch nicht offiziell angeschlossen
+    sind, vor 'unbeabsichtigtem' Betreten durch Spieler geschuetzt werden.
+
+    Moechte man zu einem schon angeschlossenen Gebiet nachtraeglich eine
+    Parallelwelt einbauen, so sollte P_NO_PLAYERS *dringend* in den
+    Parallelweltraeumen gesetzt werden, bis die Parallelwelt ausdruecklich
+    fuer Spieler freigegeben wird. Andernfalls sind alle Parallelweltraeume,
+    zu denen angeschlossene Normalweltraeume mit gleichem Filenamen existieren,
+    automatisch durch Spieler erreichbar!
+
+    (*) Ausschliesslich Testspieler, die auf den Namen eines existierenden
+    Magiers markiert sind, koennen 'geschuetzte' Raeume betreten.
+    Gildentesties werden wie Spieler behandelt.
+
+ANMERKUNG
+---------
+::
+
+    Im Gegensatz zu Bewegungen von Livings wird bei der Bewegung von Gegen-
+    staenden P_NO_PLAYERS nur beim Wechsel der Welt ausgewertet, um z.B. zu
+    verhindern, dass Bumerangs in noch nicht angeschlossene Gebiete fliegen.
+
+    Moechte man in seinem eigenen Gebiet mit Bumerangs o.ae. testen, muss
+    in diesen P_TESTPLAYER gesetzt sein. Das ist zwar eher ein Missbrauch
+    der Property, aber ein Umkompieren vom Werfer war auf Dauer zu teuer. ;-)
+
+SIEHE AUCH
+----------
+::
+
+    P_PARA, move
+
diff --git a/doc/sphinx/props/P_NO_REGENERATION.rst b/doc/sphinx/props/P_NO_REGENERATION.rst
new file mode 100644
index 0000000..9940f13
--- /dev/null
+++ b/doc/sphinx/props/P_NO_REGENERATION.rst
@@ -0,0 +1,53 @@
+P_NO_REGENERATION
+=================
+
+NAME
+----
+::
+
+     P_NO_REGENERATION    "no_regeneration"
+
+DEFINIERT IN
+------------
+::
+
+     <living/life.h> und <health.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Durch das Setzen dieser Property kann man verhindern, das ein Lebewesen
+     sich regeneriert.
+     Es gibt sieben moegliche Werte, die man durch verodern kombinieren
+     kann:
+     NO_REG_HP        : es werden keine HP regeneriert
+     NO_REG_BUFFER_HP : es werden beim "tanken" keine HP regeneriert
+     NO_REG_SP        : es werden keine SP regeneriert
+     NO_REG_BUFFER_SP : es werden beim "tanken" keine SP regeneriert
+     NO_REG_ALCOHOL   : der Alkoholspiegel wird nicht gesenkt
+     NO_REG_DRINK     : der Fluessigkeitsspiegel wird nicht gesenkt
+     NO_REG_FOOD      : der Nahrungsspiegel wird nicht gesenkt
+     sowie die Konstante NO_REG, die eine Kombination aller moeglichen
+     Werte darstellt (quasi das groesstmoegliche Uebel ;).
+
+BEISPIELE
+---------
+::
+
+     Dieses Lebewesen heilt nur beim "tanken" in der Kneipe, ansonsten
+     nicht:
+
+     
+
+     SetProp( P_NO_REGENERATION, NO_REG_HP|NO_REG_SP );
+
+SIEHE AUCH
+----------
+::
+
+     /std/living/life.c
+
+
+Last modified: 14-05-2001 by Mupfel
+
diff --git a/doc/sphinx/props/P_NO_SCORE.rst b/doc/sphinx/props/P_NO_SCORE.rst
new file mode 100644
index 0000000..b61c75a
--- /dev/null
+++ b/doc/sphinx/props/P_NO_SCORE.rst
@@ -0,0 +1,73 @@
+P_NO_SCORE
+==========
+
+NAME
+----
+::
+
+     P_NO_SCORE               "no_score"
+
+DEFINIERT IN
+------------
+::
+
+     /secure/scoremaster.h
+
+BESCHREIBUNG
+------------
+::
+
+     Die Property stellt ein Flag innerhalb von Lebewesen dar, welches
+     standardmaessig nicht gesetzt ist. In diesem Fall werden
+     Erstkillstufenpunkte an den Angreifer vergeben, sofern er ein Opfer
+     toetet.
+
+     Innerhalb eines Teams koennen Erstkillstufenpunkte auch an
+     Mitglieder vergeben werden, die das Lebewesen nicht selbst getoetet
+     haben. Voraussetzung hierfuer ist, dass derjenige, der den letzten
+     Schlag ausfuehrte, den Kill schon hat. Danach werden Mitglieder des
+     Teams gesucht, welche den Kill noch nicht haben und in der Formation
+     moeglichst weit vorne stehen.
+
+     Mit der gesetzten Property P_NO_SCORE im Opfer erreicht man nun,
+     dass diese Gutschrift fuer den/die Angreifer unterbunden wird.
+
+BEISPIEL
+--------
+::
+
+     Folgendermassen unterbindet man die Vergabe von
+     Erstkillstufenpunkten fuer den Tod eines NPC's:
+
+       include "/secure/scoremaster.h"
+       inherit "std/npc";
+       void create() {
+         ::create();
+         ...
+         SetProp(P_NO_SCORE,1);
+       }
+
+     Damit kann P_XP einen Wert haben, der eigentlich zum automatischen
+     Eintragen von Erstkillstufenpunkten fuer ein Lebewesen fuehrt, und
+     trotzdem wird dieser Eintrag nicht vorgenommen.
+     Sinnvoll ist dies insbesondere bei Lebewesen, die nicht jeder
+     Spieler erreichen kann (man moechte doch eine gewisse
+     Chancengleichheit fuer das Erreichen von Stufenpunkten bieten).
+
+BEMERKUNGEN
+-----------
+::
+
+     Auch die Vergabe von Erfahrungspunkten kann explizit unterbunden
+     werden. Hierfuer gibt es die aehnlich geartete Property P_NO_XP.
+
+SIEHE AUCH
+----------
+::
+
+     Funktionen:  GiveKillScore(), do_damage()
+     Verwandt:    P_NO_XP
+     Sonstiges:   P_XP
+
+14.Feb 2007 Gloinson
+
diff --git a/doc/sphinx/props/P_NO_STD_DRINK.rst b/doc/sphinx/props/P_NO_STD_DRINK.rst
new file mode 100644
index 0000000..926de9c
--- /dev/null
+++ b/doc/sphinx/props/P_NO_STD_DRINK.rst
@@ -0,0 +1,38 @@
+P_NO_STD_DRINK
+==============
+
+NAME
+----
+::
+
+	P_NO_STD_DRINK			"no_std_drink"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/pub.h
+
+BESCHREIBUNG
+------------
+::
+
+        Durch setzen dieser Property in einer Kneipe sorgt man dafuer, dass 
+        "Standard-Drinks" (z.B. Gluehwein im Dezember) nicht in das Menue
+        der Kneipe aufgenommen werden.
+
+BEMERKUNGEN
+-----------
+::
+
+        Keine.
+
+SIEHE AUCH
+----------
+::
+
+	/std/room/pub.c
+
+
+Last modified: Sat Mar 04 22:42:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/props/P_NO_TPORT.rst b/doc/sphinx/props/P_NO_TPORT.rst
new file mode 100644
index 0000000..5161f0f
--- /dev/null
+++ b/doc/sphinx/props/P_NO_TPORT.rst
@@ -0,0 +1,30 @@
+P_NO_TPORT
+==========
+
+NAME
+----
+::
+
+    P_NO_TPORT                    "tport"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Kann folgende Werte annnehmen (definiert in moving.h):
+     NO_TPORT_IN	= Man kann nicht in den Raum hinein teleportieren.
+     NO_TPORT_OUT = Man kann nicht aus dem Raum hinaus teleportieren.
+     NO_TPORT	= Weder noch.
+
+SIEHE AUCH
+----------
+::
+
+	P_NO_PARA_TRANS
+
diff --git a/doc/sphinx/props/P_NO_TRAVELING.rst b/doc/sphinx/props/P_NO_TRAVELING.rst
new file mode 100644
index 0000000..be63938
--- /dev/null
+++ b/doc/sphinx/props/P_NO_TRAVELING.rst
@@ -0,0 +1,50 @@
+P_NO_TRAVELING
+==============
+
+NAME
+----
+::
+
+    P_NO_TRAVELING                   "no_traveling"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+    Hier steht der allgemeine reise-Befehl nicht zur Verfuegung.
+
+BEMERKUNGEN
+-----------
+::
+
+    P_NO_TRAVELING wird in Transportern gesetzt wenn Spieler ihn 
+    nicht mehr 'automatisch' mittels des 'reise'-Befehls betreten
+    koennen sollen.
+
+    Sie bekommen in dem Transporter und in den Zielraeumen auch 
+    keinerlei Hinweise darauf, wohin sie evtl. reisen koennten.
+
+    
+
+    Standardmaessig ist P_NO_TRAVELING natuerlich 0.
+
+SIEHE AUCH
+----------
+::
+
+    reise
+
+LETZTER AENDERUNG
+-----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
+    
+
diff --git a/doc/sphinx/props/P_NO_XP.rst b/doc/sphinx/props/P_NO_XP.rst
new file mode 100644
index 0000000..0405a0b
--- /dev/null
+++ b/doc/sphinx/props/P_NO_XP.rst
@@ -0,0 +1,65 @@
+P_NO_XP
+=======
+
+NAME
+----
+::
+
+     P_NO_XP                    "no_xp"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Im Normalfall bekommt man im Kampf gegen einen Gegner fuer Treffer
+     und beim Toeten eine XP-Gutschrift.
+
+     Ist P_NO_XP gesetzt, so erhaelt man keinerlei XP-Gutschriften
+     fuer den Kampf oder den Tod des NPCs.
+
+BEISPIEL
+--------
+::
+
+     Folgendermassen unterbindet man die Vergabe von Erfahrungspunkte
+     fuer den Angriff eines NPC's:
+
+       include "/sys/living/life.h"
+       inherit "std/npc";
+       void create() {
+         ::create();
+         ...
+         SetProp(P_NO_XP,1);
+       }
+
+     Damit kann P_XP trotzdem einen Wert im NPC haben, der
+     Erstkillstufenpunkte fuer Lebewesen automatisch eintraegt!
+
+     Auch fuer das kurzzeitige Unterbinden der Vergabe von
+     Erfahrungspunkten ist diese Property sinnvoller, als P_XP im NPC
+     auf 0 zu setzen.
+
+BEMERKUNGEN
+-----------
+::
+
+     Auch die Vergabe von Erstkillstufenpunkten kann explizit unterbunden
+     werden. Hierfuer gibt es die aehnlich geartete Property P_NO_SCORE.
+
+SIEHE AUCH
+----------
+::
+
+     Funktionen:  AddExp(), DistributeExp(), do_damage()
+     Properties:  P_XP, P_LAST_XP
+     Verwandt:    P_NO_SCORE
+     Sonstiges:   P_TOTAL_WC, create_default_npc()
+
+14.Feb 2007 Gloinson
+
diff --git a/doc/sphinx/props/P_NPC.rst b/doc/sphinx/props/P_NPC.rst
new file mode 100644
index 0000000..9f2b1e3
--- /dev/null
+++ b/doc/sphinx/props/P_NPC.rst
@@ -0,0 +1,21 @@
+P_NPC
+=====
+
+NAME
+----
+::
+
+    P_NPC                         "is_npc"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gesetzt bei Monstern.
+
diff --git a/doc/sphinx/props/P_NPC_FASTHEAL.rst b/doc/sphinx/props/P_NPC_FASTHEAL.rst
new file mode 100644
index 0000000..b9bb65d
--- /dev/null
+++ b/doc/sphinx/props/P_NPC_FASTHEAL.rst
@@ -0,0 +1,40 @@
+P_NPC_FASTHEAL
+==============
+
+NAME
+----
+::
+
+	P_NPC_FASTHEAL			"npc_fastheal"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/pub.h
+
+BESCHREIBUNG
+------------
+::
+
+        Durch setzen dieser Property in einer Kneipe sorgt man dafuer, dass 
+        bei NPCs, die dort "tanken", die Lebens- und Konzentrationspunkte
+        direkt erhoeht werden und nicht, wie bei ungesetzter Property, in
+        die jew. Buffer geschrieben werden.
+
+BEMERKUNGEN
+-----------
+::
+
+        Die Benutzung dieser Property sollte nicht unbedingt zum Standard
+        werden.
+
+SIEHE AUCH
+----------
+::
+
+	/std/room/pub.c
+
+
+Last modified: Wed Sep 29 13:58:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/props/P_NR_HANDS.rst b/doc/sphinx/props/P_NR_HANDS.rst
new file mode 100644
index 0000000..2182ed3
--- /dev/null
+++ b/doc/sphinx/props/P_NR_HANDS.rst
@@ -0,0 +1,46 @@
+P_NR_HANDS
+==========
+
+NAME
+----
+::
+
+     P_NR_HANDS "nr_hands"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Wieviele Haende muss man frei haben, um die Waffe zuecken oder den
+     Schild tragen zu koennen?
+     Dieser Wert muss mindestens 1 betragen!
+
+     Sollen Spieler die Waffe benutzen koennen, so sind hier nur die Werte 1
+     und 2 moeglich. Falls die Waffe nur von Monstern benutzbar sein soll,
+     kann man hier auch hoehere Werte eintragen (dazu muss man beim Monster
+     P_MAX_HANDS entsprechend hoch setzen). Als Beispiel sei hier nur das
+     vierhaendige Schwert aus dem Friedhof genannt.
+
+     Defaultmaessig sind alle Waffen Zweihaender.
+
+     Diese Property kann auch bei Zaubern benutzt werden, bei denen man eine
+     oder mehrere Haende frei haben muss.
+
+SIEHE AUCH
+----------
+::
+
+     P_HANDS, P_HANDS_USED_BY
+     P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
+     UseHands, FreeHands
+     /std/weapon.c, /std/spellbook.c
+
+
+Last modified: Sun May 19 15:00:02 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_ORAKEL.rst b/doc/sphinx/props/P_ORAKEL.rst
new file mode 100644
index 0000000..ca412f3
--- /dev/null
+++ b/doc/sphinx/props/P_ORAKEL.rst
@@ -0,0 +1,22 @@
+P_ORAKEL
+========
+
+NAME
+----
+::
+
+    P_ORAKEL                      "orakel"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn diese Property gesetzt ist, kann der Wanderer in diesen
+     Raum hinein.
+
diff --git a/doc/sphinx/props/P_ORIG_FILE_NAME.rst b/doc/sphinx/props/P_ORIG_FILE_NAME.rst
new file mode 100644
index 0000000..f7220e1
--- /dev/null
+++ b/doc/sphinx/props/P_ORIG_FILE_NAME.rst
@@ -0,0 +1,21 @@
+P_ORIG_FILE_NAME
+================
+
+NAME
+----
+::
+
+    P_ORIG_FILE_NAME                "original_object_name"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     In einer Leiche der Filename des Gestorbenen.
+
diff --git a/doc/sphinx/props/P_ORIG_NAME.rst b/doc/sphinx/props/P_ORIG_NAME.rst
new file mode 100644
index 0000000..8361ae8
--- /dev/null
+++ b/doc/sphinx/props/P_ORIG_NAME.rst
@@ -0,0 +1,21 @@
+P_ORIG_NAME
+===========
+
+NAME
+----
+::
+
+    P_ORIG_NAME                   "original_name"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     In einer Leiche der Name des Gestorbenen. (name(RAW))
+
diff --git a/doc/sphinx/props/P_PARA.rst b/doc/sphinx/props/P_PARA.rst
new file mode 100644
index 0000000..aecb22d
--- /dev/null
+++ b/doc/sphinx/props/P_PARA.rst
@@ -0,0 +1,75 @@
+P_PARA
+======
+
+NAME
+----
+::
+
+    P_PARA                        "para"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Nummer der Parallelwelt, in der sich ein Spieler befindet.
+
+    Ist die Property P_PARA auf Null gesetzt, so befindet sich der Spieler in
+    der 'Normalwelt'. Gibt es bei einer Bewegung dieses Spielers mehrere
+    moegliche Zielraeume mit identischem Namen aber unterschiedlichen Endungen
+    'name.c', 'name^1.c', 'name^2.c' etc., so wird der Spieler in den Raum
+    'name.c' bewegt. 
+
+    Wird die Property P_PARA auf einen Wert n>0 gesetzt, so landet der Spieler
+    bei einer Bewegung im Raum 'name^n.c'. Ist kein Raum mit entsprechender
+    Endung vorhanden, wird der Spieler stattdessen in den Normalweltraum
+    bewegt.
+
+    Diese Prop kann auch in einem Virtual Compiler gesetzt werden. In diesem
+    Fall schraenkt sie die Dimensionen ein, in denen der VC Objekte erzeugt.
+    Die Prop kann eine einzelne Ziffer (Int) oder ein Array von Ints 
+    aufnehmen, dann ist der VC fuer alle angegeben Dimensionen zustaendig. 
+    Ein leeres Array erlaubt gar keine Para-Objekte.
+
+ANMERKUNG
+---------
+::
+
+    Die Endung '^0' kennzeichnet _nicht_ die Normalwelt. So lange kein Ausgang
+    explizit auf den Raum 'name^0.c' verweist, wird kein Spieler den Raum
+    betreten koennen. Deshalb kann man die Endung '^0' z.B. dazu benutzen, um
+    eigene Standardraeume fuer ein Gebiet zu schreiben, die dann sowohl von
+    den Normal- als auch von den Parallelweltraeumen inheritet werden.
+
+    Raeume mit Endungen '^n.c', bei denen 'n' keine positive ganze Zahl ist,
+    werden nicht beachtet.
+
+    Fuer die Entscheidung, in welchem Raum ein Spieler in Abhaengigkeit von
+    P_PARA landet, ist die Funktion move() zustaendig. Als Magier muss man sich
+    darum nicht gesondert kuemmern. Das heisst aber auch, dass beim Anschluss
+    eines Normalweltraumes automatisch alle in dem Verzeichnis mit gleichem
+    Namen vorhandenen Parallelweltraeume mit angeschlossen werden.
+
+    Sollen einzelne Parallelweltraeume noch nicht angeschlossen werden, so muss
+    in ihnen die Property P_NO_PLAYERS gesetzt werden. Diese Raeume sind dann
+    nur durch Magier und Testspieler zu betreten (und zu testen).
+
+    In Paraweltraeumen liefert P_PARA 'n' zurueck.
+    Man kann also z.B. in NPCs einfach ueber environment()->QueryProp(P_PARA) 
+    abfragen, in welcher Parawelt sich dieser gerade befindet.
+
+SIEHE AUCH
+----------
+::
+
+    P_NO_PLAYERS, move, pararaeume
+
+    
+
+25.Jan 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_PARRY.rst b/doc/sphinx/props/P_PARRY.rst
new file mode 100644
index 0000000..ffda4f8
--- /dev/null
+++ b/doc/sphinx/props/P_PARRY.rst
@@ -0,0 +1,48 @@
+P_PARRY
+=======
+
+NAME
+----
+::
+
+     P_PARRY "parry"
+
+DEFINIERT IN
+------------
+::
+
+     <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property legt fest, inwiefern eine Waffe als Parierwaffe
+     genutzt werden kann. Moegliche Werte:
+
+         PARRY_NOT     Eine reine Angriffswaffe ohne Parierfunktion.
+
+         PARRY_TOO     Eine kombinierte Angriffs- und Parierwaffe.
+
+         PARRY_ONLY    Eine reine Parierwaffe. Diese kann zusaetzlich
+                       zu einer normalen Waffe gezueckt werden.
+
+     Man sollte nur die in <combat.h> definierten Konstanten verwenden.
+
+BEMERKUNGEN
+-----------
+::
+
+     Durch diese Propertie laesst sich _kein_ Parade-Bonus fuer Trves 
+     setzen! Alle Gilden haben etwas davon. Vor Verwendung bitte mit
+     der Objekt-Balance absprechen.
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon/combat.c
+
+
+Last modified: Sat Jun 01 13:28:45 2001 by Tilly
+
diff --git a/doc/sphinx/props/P_PARRY_WEAPON.rst b/doc/sphinx/props/P_PARRY_WEAPON.rst
new file mode 100644
index 0000000..499bade
--- /dev/null
+++ b/doc/sphinx/props/P_PARRY_WEAPON.rst
@@ -0,0 +1,31 @@
+P_PARRY_WEAPON
+==============
+
+NAME
+----
+::
+
+     P_PARRY_WEAPON "parry_weapon"
+
+DEFINIERT IN
+------------
+::
+
+     <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property gibt an, welche Parierwaffe ein Spieler derzeit
+     gezueckt hat.
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon/combat.c, /std/living/combat.c
+
+
+Last modified: Sat Jun 26 15:23:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/props/P_PEACE_HISTORY.rst b/doc/sphinx/props/P_PEACE_HISTORY.rst
new file mode 100644
index 0000000..e4e36a5
--- /dev/null
+++ b/doc/sphinx/props/P_PEACE_HISTORY.rst
@@ -0,0 +1,62 @@
+P_PEACE_HISTORY
+===============
+
+NAME
+----
+::
+
+     P_PEACE_HISTORY      "_peace_history"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Prop wird nach Gilden getrennt gespeichet, wie oft das Lebewesen
+    in letzter Zeit befriedet worden ist. Diese Information geht in die
+    Chance auf eine zukuenftige Befriedung ein.
+    Die Zaehler werden im Durchschnitt alle 2700s um 2-3 reduziert.
+    Die Datenstruktur ist ein Array, welches einen Zeitstempel als erstes
+    Element und ein Mapping als zweites enthaelt. Das Mapping enthaelt unter
+    den Gildennamen als Keys den ganzzahligen Zaehler erfolgreicher
+    Befriedungen von Spielern dieser Gilde.
+
+BEMERKUNGEN
+-----------
+::
+
+    * Diese Property sollte niemals direkt geaendert werden. Bitte greift also
+      nur lesend darauf zu. Sollte hiermit Schindluder getrieben werden,
+      werden die Daten vor externer Aenderung geschuetzt.
+    * Die Datenstruktur in dieser Prop kann in Zukunft u.U. geaendert werden.
+      Daher aendert sie am besten auch nicht im eigenen NPC oder seid darauf
+      gefasst, irgendwann Hand anlegen zu muessen.
+    * Die Aktualisierung (auch die Reduktion) findet im Zuge eines
+      QueryPacify() statt, nicht im Reset des Lebewesens.
+
+BEISPIEL
+--------
+::
+
+    In P_PEACE_HISTORY steht:
+    ({1209654597, (["zauberer": 3, "klerus": 4]) })
+    Bei der Berechnung der naechsten Befriede-Chance gehen bei Zauberern also
+    3 erfolgreiche Versuche, bei Klerikern 4 erfolgreiche Versuche ein.
+    Der Zeitwert an erster Stelle des Arrays wird der bei der Berechnung der
+    naechsten Reduktion der Zaehler beruecksichtigt. (Genaues: s. combat.c)
+
+SIEHE AUCH
+----------
+::
+
+     P_PEACE_ACCEPT
+     QueryPacify()
+     /std/living/combat.c
+
+01.05.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_PERM_STRING.rst b/doc/sphinx/props/P_PERM_STRING.rst
new file mode 100644
index 0000000..86a7c20
--- /dev/null
+++ b/doc/sphinx/props/P_PERM_STRING.rst
@@ -0,0 +1,24 @@
+P_PERM_STRING
+=============
+
+NAME
+----
+::
+
+    P_PERM_STRING                 "perm_string"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+     Fuer Sprachflueche, Property ist im Spieler-Objekt zu setzen. In dem
+     Objekt, das in P_PERM_STRING gespeichert ist, wird bei Sprachbefehlen
+     permutate_string(str) aufgerufen und der zurueckgegebene String 
+     stattdessen ausgegeben.
+
diff --git a/doc/sphinx/props/P_PICK_MSG.rst b/doc/sphinx/props/P_PICK_MSG.rst
new file mode 100644
index 0000000..e96333e
--- /dev/null
+++ b/doc/sphinx/props/P_PICK_MSG.rst
@@ -0,0 +1,78 @@
+P_PICK_MSG
+==========
+
+NAME
+----
+::
+
+     P_PICK_MSG				"pick_message"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/put_and_get.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mit P_PICK_MSG kann man die Meldung, die man beim Aufnehmen eines
+     Objektes bekommt, modifizieren.
+
+     Folgende Werte sind moeglich:
+
+     o 0
+       Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
+
+     o NO_PNG_MSG       == -1
+       Es wird keinerlei Meldung ausgegeben
+
+     o Ein Array aus Strings
+       Der erste String wird an den Spieler ausgegeben, der zweite
+       (optionale) an den Raum.
+
+       Die Strings werden durch die Funktion replace_personal() geparst.
+	Objekt1 - Spieler
+        Objekt2 - das Objekt, das genommen wird
+
+       Wird der zweite String nicht angegeben, erfolgt keine Meldung an den
+       Raum.
+
+BEISPIEL
+--------
+::
+
+     void create() {
+      ...
+      SetProp( P_SHORT, "Etwas Sand" );
+      SetProp( P_LONG, break_string(
+       "Ein wenig magischer Sand. Sehr feinkruemelig.",78 ));
+
+      SetProp( P_NAME, "Sand" );
+      AddId( ({"sand"}) );
+      SetProp( P_GENDER, MALE );
+
+      SetProp( P_PICK_MSG, ({
+       "Du schaufelst @WEN2 in deine Hand.",
+       "@WER1 schaufelt @WEN2 in eine Hand."}));
+      ...
+     }
+
+     Das ganze fuehrt bei Ugars "nimm sand" zu folgenden
+     Meldungen:
+
+     Ugar: "Du schaufelst den Sand in deine Hand."
+     Raum: "Ugar schaufelt den Sand in eine Hand."
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_WEAR_MSG, P_WIELD_MSG
+     Fehler:     P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
+                 P_NOINSERT_MSG, P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     Sonstiges:  replace_personal(E), pick_obj(L), /std/living/put_and_get.c
+
+14. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_PILE_NAME.rst b/doc/sphinx/props/P_PILE_NAME.rst
new file mode 100644
index 0000000..cb801e0
--- /dev/null
+++ b/doc/sphinx/props/P_PILE_NAME.rst
@@ -0,0 +1,22 @@
+P_PILE_NAME
+===========
+
+NAME
+----
+::
+
+    P_PILE_NAME                   "file_name"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     In einer Leiche der Name des Gestorbenen im Dativ. (name(WEM))
+     Wird vom Haufen benoetigt.
+
diff --git a/doc/sphinx/props/P_PLAYER_LIGHT.rst b/doc/sphinx/props/P_PLAYER_LIGHT.rst
new file mode 100644
index 0000000..7148267
--- /dev/null
+++ b/doc/sphinx/props/P_PLAYER_LIGHT.rst
@@ -0,0 +1,44 @@
+P_PLAYER_LIGHT
+==============
+
+NAME
+----
+::
+
+    P_PLAYER_LIGHT                       "player_light"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt den Lichtlevel an, mit dem ein Lebewesen sieht, ein Abfragen dieser
+    Property kann z.B. sinnvoll sein wenn man abfragen will ob ein Spieler
+    genug Licht dabei hat um ein bestimmtes Detail untersuchen zu koennen.
+
+    Bitte _nur_ ueber QueryProp auf diese Property zugreifen,
+    da das Lichtlevel ggf. neu berechnet werden muss!
+
+    Ein direktes setzen dieser Property ist NICHT moeglich. Es ist jedoch
+    moeglich entweder eine Closure zu benutzen oder den Wert ueber einen
+    P_LIGHT_MODIFIER zu veraendern.
+
+    Um zu erreichen, das ein NPC Nachtsicht bekommt, gibt es nun 3 Varianten.
+    - eine closure:
+        Set(P_PLAYER_LIGHT, function int () {return 1;} , F_QUERY_METHOD) 
+      dieses bedeutet, dass der NPC in jeder Dunkelheit perfekt sehen kann.
+    - das setzen von einem P_LIGHT_MODIFIER
+    - das benutzen des stdskills. Hierzu schreibt man in das create() des
+      NPCs einfach ein: ModifySkill(SK_NIGHTVISION, 10000);
+
+SIEHE AUCH
+----------
+::
+
+    P_LIGHT_MODIFIER, P_LIGHT, P_TOTAL_LIGHT, P_INT_LIGHT, CannotSee()
+
diff --git a/doc/sphinx/props/P_PLURAL.rst b/doc/sphinx/props/P_PLURAL.rst
new file mode 100644
index 0000000..c246d38
--- /dev/null
+++ b/doc/sphinx/props/P_PLURAL.rst
@@ -0,0 +1,58 @@
+P_PLURAL
+========
+
+NAME
+----
+::
+
+    P_PLURAL                      "plural"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/language.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mit Hilfe von P_PLURAL koennen auch nicht Unit Objekte als Pluralobjekte
+    markiert werden. Bei einem Wert > 1 wird der Wert ausserdem auch noch in
+    den Namen eingefuegt. Sollte man in eigenem Code zulassen wollen, das
+    etwas mit bestimmten Objekten geschieht, dann sollte man die Verben
+    entsprechen konjugieren.
+
+BEMERKUNGEN
+-----------
+::
+
+    Wirkt nicht auf Todesmeldungen -> siehe dafuer P_KILL_MSG
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_NAME, "Stiefel"); SetProp(P_PLURAL, 2);
+    name(WER, 1) -> "die zwei Stiefel"
+
+    SetProp(P_NAME, "Stiefel"); SetProp(P_PLURAL, 1);
+    name(WER, 1) -> "die Stiefel"
+
+    // Ein Beispiel fuer das konjugieren von Verben
+    static int cmd_opfer(string str)
+    {
+       int i;
+       object *obs;
+       notify_fail("Was moechtest Du opfern?\n");
+       if (!str || !sizeof(obs=PL->find_obs(str))) return 0;
+       for (i=sizeof(obs)-1; i>=0; i--)
+          if (obs[i]->QueryProp(P_VALUE)<=0)
+            write(obs[i]->Name(WER)+" "
+                 +(ob->QueryProp(P_PLURAL) ? "sind" : "ist")
+                 +" doch gar nichts wert.\n");
+          else obs[i]->remove();
+    }
+
+26. Juni 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_POISON.rst b/doc/sphinx/props/P_POISON.rst
new file mode 100644
index 0000000..d4700b8
--- /dev/null
+++ b/doc/sphinx/props/P_POISON.rst
@@ -0,0 +1,21 @@
+P_POISON
+========
+
+NAME
+----
+::
+
+    P_POISON                      "poison"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wie stark wir vergiftet sind (0-11)
+
diff --git a/doc/sphinx/props/P_POISON_DELAY.rst b/doc/sphinx/props/P_POISON_DELAY.rst
new file mode 100644
index 0000000..662ed10
--- /dev/null
+++ b/doc/sphinx/props/P_POISON_DELAY.rst
@@ -0,0 +1,27 @@
+P_POISON_DELAY
+==============
+
+NAME
+----
+::
+
+    P_POISON_DELAY                     "poison_delay"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der heart_beats nach denen sich die Giftwirkung erneut 
+     zeigt. Je kleiner der Wert, desto empfindlicher ist das Lebewesen
+     gegen Gift.
+     Aenderungen dieser Property in Spielern beduerfen der Genehmigung
+     des EMs fuer Balance.
+
+     
+
diff --git a/doc/sphinx/props/P_PORTIONS.rst b/doc/sphinx/props/P_PORTIONS.rst
new file mode 100644
index 0000000..5147f61
--- /dev/null
+++ b/doc/sphinx/props/P_PORTIONS.rst
@@ -0,0 +1,42 @@
+P_PORTIONS
+==========
+
+NAME
+----
+::
+
+     P_PORTIONS                    "std_food_portions"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property steht die Anzahl der Portionen einer Speise.
+     Es duerfen nur Werte > -1 gesetzt werden. Ist diese Property 0,
+     wird die Speise als leer bzw. verbraucht angesehen und kann nicht
+     konsumiert werden.
+
+     
+
+DEFAULT
+-------
+::
+
+     Initial ist diese Property auf 1 gesetzt, die Speise ist also mit
+     einem Bissen/Schluck verbraucht bzw. leer.
+
+SIEHE AUCH
+----------
+::
+
+     /std/food.c, wiz/food
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_POST.rst b/doc/sphinx/props/P_POST.rst
new file mode 100644
index 0000000..b1435bd
--- /dev/null
+++ b/doc/sphinx/props/P_POST.rst
@@ -0,0 +1,83 @@
+P_POST
+======
+
+NAME
+----
+::
+
+	P_POST				"Post"
+
+DEFINIERT IN
+------------
+::
+
+	/mail/post.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property laesst sich die Versendeerlaubnis von Paketen
+	regeln. Hierbei gibt es zum einen die postlagernden Pakete, die man
+	in einer Post abholen muss, und es gibt die sogenannten
+	Kurierpakete, welche direkt und unmittelbar zugestellt werden.
+	Nicht immer ist es erwuenscht, dass Pakete aus der Ferne in einen
+	Raum geschickt werden duerfen. Dies duerfte insbesondere innerhalb
+	von Gebieten interessant sein, in welche man nur beschraenkt viele
+	Objekte mitfuehren kann. Mit dieser Property nun ist es leicht
+	moeglich, dies zu verbieten. Man kann auch in den Objekten selbst
+	angeben, ob diese per postlagerndem Paket bzw. Kurierpaket
+	verschickt werden duerfen. Dies duerfte zum Beispiel bei Komponenten
+	fuer Spells oder fuer Unique-Objekte interessant sein.
+	Folgende Werte sind moeglich, wobei in Raeumen und Objekten
+	Standardmaessig PP_DEFAULT genutzt wird:
+
+	  PP_FORBIDDEN		-2	// auf jeden Fall verboten
+	  PP_NO_EXPRESS		-1	// Kurierpakete verboten
+	  PP_DEFAULT		 0	// Default
+	  PP_NORMAL_ALLOWED	 1	// postlagernde Pakete erlaubt
+	  PP_ALLOWED		 2	// auf jeden Fall erlaubt
+
+	Raeume, die von /std/post.c abgeleitet wurden, nutzen als Standard
+	natuerlich PP_ALLOWED.
+
+BEISPIEL
+--------
+::
+
+	Um Kurierpakete fuer einen Raum zu verbieten, nutzt man die
+	Funktionalitaet dieser Property folgendermassen:
+
+	  include "/mail/post.h"
+	  ...
+	  void create()
+	  { ::create();
+	    ...
+	    SetProp(P_POST,PP_NO_EXPRESS);
+	    ...
+	  }
+
+	Objekte selbst koennte man folgendermassen aus Paketen verbannen,
+	welche versendet werden sollen:
+
+	  include "/mail/post.h"
+	  ...
+	  void create()
+	  { ::create();
+	    ...
+	    SetProp(P_POST,PP_FORBIDDEN);
+	    ...
+	  }
+
+	In letzterem Fall funktionieren im Gegensatz zum ersten Beispiel
+	auch keine postlagernden Pakete mehr.
+
+SIEHE AUCH
+----------
+::
+
+	/std/post.c, /std/mailcabin.c, /p/service/loco/std/mailcabin.c
+
+
+Last modified: Sun Sep  6 19:34:37 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_POTIONROOMS.rst b/doc/sphinx/props/P_POTIONROOMS.rst
new file mode 100644
index 0000000..c94ec4d
--- /dev/null
+++ b/doc/sphinx/props/P_POTIONROOMS.rst
@@ -0,0 +1,35 @@
+P_POTIONROOMS
+=============
+
+NAME
+----
+::
+
+    P_POTIONROOMS                 "potionrooms"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/potion.h
+
+BESCHREIBUNG
+------------
+::
+
+    Array mit den Nummern der Raeume, in denen der Spieler noch Zauber-
+    traenke hat. Die Freischaltung als bekannt geschieht im Orakel.
+    Die Zuordnung der Raeume und Nummern geschieht im Potionmaster.
+
+    Nur lesbare _query - Property.
+
+SIEHE AUCH
+----------
+::
+
+    Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
+    Verwandt:  FindPotion(), AddKnownPotion(), RemoveKnownPotion(), InList()
+    Props:     P_KNOWN_POTIONROOMS
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_PRAY_ROOM.rst b/doc/sphinx/props/P_PRAY_ROOM.rst
new file mode 100644
index 0000000..183e870
--- /dev/null
+++ b/doc/sphinx/props/P_PRAY_ROOM.rst
@@ -0,0 +1,54 @@
+P_PRAY_ROOM
+===========
+
+NAME
+----
+::
+
+    P_PRAY_ROOM                      "_lib_p_pray_room"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+    Dies ist der Raum, in den der Spieler nach dem Ende der Todessequenz
+    bewegt wird, d.h. ein Raum, wo er beten kann, um einen neuen Koerper zu
+    erhalten.
+    Der Raum muss als String angegeben werden (kein Objekt).
+
+    Diese Property wird im Spieler rebootfest gespeichert.
+
+    Der jeweils gueltige Betraum wird im Spieler mittels QueryPrayRoom()
+    ermittelt. Jede Rasse hat einen Default fuer diese Funktion. Wird die
+    Property auf 0 dgesetzt, wird dieser Default wiederhergestellt.
+
+    Von einer Ueberlagerung mittels Query- oder gar Setmethoden wird
+    abgeraten. Ebenso lasst bitte die Modusbits unveraendert.
+
+    Vor einer Aenderung dieser Property sollte geprueft werden, ob sie 0 ist.
+    Wenn nicht, sollte von einem Setzen der Property abgesehen werden, da dann
+    schon jemand anders den Betraum des Spielers geaendert hat. (Gleiches gilt
+    fuers Loeschen.) Bitte niemals den Inhalt der Property woanders speichern
+    und spaeter zurueckschreiben.
+
+    Eine dauerhafte Aenderung des Betraums des Spielers muss mit dem EM
+    Rassen und dem EM Gilden abgestimmt werden.
+
+SIEHE AUCH
+----------
+::
+
+    QueryPrayRoom(), SetDefaultPrayRoom()
+
+LETZTE AeNDERUNG
+----------------
+::
+
+21.05.2013, Zesstra
+
diff --git a/doc/sphinx/props/P_PREFERED_ENEMY.rst b/doc/sphinx/props/P_PREFERED_ENEMY.rst
new file mode 100644
index 0000000..67c688b
--- /dev/null
+++ b/doc/sphinx/props/P_PREFERED_ENEMY.rst
@@ -0,0 +1,42 @@
+P_PREFERED_ENEMY
+================
+
+NAME
+----
+::
+
+	P_PREFERED_ENEMY		"pref_enemy"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt ein Array mit folgenden Eintraegen:
+	  Eintrag 1:      Integerwert zwischen 0 und 100, welcher die
+	                  Wahrscheinlichkeit dafuer angibt, dass ein
+	                  Lebewesen bevorzugt bei einem Angriff gewaehlt
+	                  werden soll.
+	  Eintraege ab 2: Lebewesen, aus welchen per Zufall eines
+	                  ausgewaehlt wird, welches beim aktuellen Angriff
+	                  bevorzugt wird.
+	Es ist zu beachten, dass solch ein bevorzugtes Opfer natuerlich auch
+	wirklich Gegner sein muss und auch im selben Raum zu stehen hat, wie
+	der Angreifer. Ist dies nicht der Fall, wird dann doch irgendein
+	anderer Gegner aus diesem Raum genommen.
+
+SIEHE AUCH
+----------
+::
+
+	QueryPreferedEnemy(), IsEnemy(), SelectEnemy(), Attack(),
+	/std/living/combat.c, /std/living/life.c
+
+
+Last modified: Wed May 26 16:44:38 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_PRESAY.rst b/doc/sphinx/props/P_PRESAY.rst
new file mode 100644
index 0000000..5f55be6
--- /dev/null
+++ b/doc/sphinx/props/P_PRESAY.rst
@@ -0,0 +1,22 @@
+P_PRESAY
+========
+
+NAME
+----
+::
+
+    P_PRESAY                      "presay"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Presay des Spielers. Erscheint vor dem Namen in Kurz/Langbeschreibung.
+     Erscheint auch in name(), also in sag, ruf, teile mit usw.
+
diff --git a/doc/sphinx/props/P_PREVENT_PILE.rst b/doc/sphinx/props/P_PREVENT_PILE.rst
new file mode 100644
index 0000000..54c52ee
--- /dev/null
+++ b/doc/sphinx/props/P_PREVENT_PILE.rst
@@ -0,0 +1,35 @@
+P_PREVENT_PILE
+==============
+
+NAME
+----
+::
+
+    P_PREVENT_PILE                   "prevent_pile"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Wenn in einem Raum diese Property gesetzt ist, endet das Verwesen einer
+    Leiche damit, dass ihr Inventar in dem Raum verteilt wird. Ist diese
+    Property nicht gesetzt, entsteht ein "Haufen", der das Inventar
+    enthaelt.
+
+    Diese Property sollte nur in Ausnahmefaellen benutzt werden!
+
+    Diese Property ist vor allem fuer "Store-Rooms" gedacht, in denen die
+    Magier die Leiche eines Spieler ablegen und in denen nachher die
+    gesammelten Sachen von einer anderen Stelle aus gesucht werden. In
+    diesem Fall wuerden Spieler sonst die Moeglichkeit haben, einen Haufen
+    als Ganzes zu bekommen, das soll aber *NIE* passieren.
+
+
+Last modified: Tue May 15 13:56:18 CEST 2007 by Rumata
+
diff --git a/doc/sphinx/props/P_PRE_INFO.rst b/doc/sphinx/props/P_PRE_INFO.rst
new file mode 100644
index 0000000..9efed27
--- /dev/null
+++ b/doc/sphinx/props/P_PRE_INFO.rst
@@ -0,0 +1,87 @@
+P_PRE_INFO
+==========
+
+NAME
+----
+::
+
+        P_PRE_INFO                        "npc_pre_info"
+
+DEFINIERT IN
+------------
+::
+
+        /sys/npc.h
+
+BESCHREIBUNG
+------------
+::
+
+        Ist die Property in einem NPC definiert, so wird ihr Ergebnis
+        ausgewertet, bevor eine Frage an das Infosystem uebergeben wird.
+
+        
+
+        Moegliche Werte:
+        - numerischer Wert ungleich 0
+          => der NPC gibt _keinerlei_ Antwort, die Frage fuehrt sozusagen
+             ins Leere
+
+        - Stringwert
+          => wird als Rueckgabe an den Fragenden ausgegeben, umstehende 
+             Personen bekommen den Text:
+            "XY ist nicht gewillt, Spieler YZ zu antworten".
+            Der Fragende selbst bekommt bei angegebenem Stringwert:
+            "XY " + Stringwert.
+
+        - Closure
+          => die Antwort bzw. Reaktion des NPCs obliegt ganz der 
+             angegebenen Closure. Diese muss dabei einen String oder 
+             Ganzzahlen-Wert zurueckgeben
+
+BEISPIEL
+--------
+::
+
+        Ein NPC der manchmal herumrennt, um z.B. eine Aufgabe zu verrichten,
+        koennte so lange Chats abschalten, z.B.
+
+          SetProp(P_CHAT_CHANCE,0); // NPC latscht los
+
+        
+
+        Und eine Weile spaeter:
+
+        
+
+          SetProp(P_CHAT_CHANCE,5); // NPC ruht wieder, quasselt rum
+
+        
+
+        Waehrend des Herumlaufens, also wenn er nicht automatisch schwatzt,
+        soll er auch keinerlei Fragen beantworten:
+
+          
+
+          Set(P_PRE_INFO, function mixed () {
+            return (QueryProp(P_CHAT_CHANCE) ? 0 : 
+              "hat gerade keine Zeit fuer Dich."); 
+            }, F_QUERY_METHOD);
+
+HINWEISE
+--------
+::
+
+        Bitte beachten, dass der interne Name der Property "npc_pre_info" 
+        ist und somit nur das Ueberschreiben von _query_npc_pre_info() 
+        funktioniert. 
+
+SIEHE AUCH
+----------
+::
+
+        AddInfo(), /std/npc/info.c
+
+
+Last modified: 01.03.2016 by Arathorn
+
diff --git a/doc/sphinx/props/P_PROMPT.rst b/doc/sphinx/props/P_PROMPT.rst
new file mode 100644
index 0000000..6345a77
--- /dev/null
+++ b/doc/sphinx/props/P_PROMPT.rst
@@ -0,0 +1,21 @@
+P_PROMPT
+========
+
+NAME
+----
+::
+
+    P_PROMPT                      "prompt"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Das Prompt (Nur fuer Magier).
+
diff --git a/doc/sphinx/props/P_PUB_NOT_ON_MENU.rst b/doc/sphinx/props/P_PUB_NOT_ON_MENU.rst
new file mode 100644
index 0000000..3c278a7
--- /dev/null
+++ b/doc/sphinx/props/P_PUB_NOT_ON_MENU.rst
@@ -0,0 +1,40 @@
+P_PUB_NOT_ON_MENU
+=================
+
+NAME
+----
+::
+
+	P_PUB_NOT_ON_MENU			"pub_not_on_menu"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/pub.h
+
+BESCHREIBUNG
+------------
+::
+
+        In diese Property kann man einen String schreiben, der ausgegeben
+        wird, wenn der Spieler etwas bestellt, was es in der Kneipe nicht
+        gibt.
+
+BEMERKUNGEN
+-----------
+::
+
+        Die Standardmeldung ist:
+        "Tut mir leid, das fuehren wir nicht! Wir sind ein anstaendiges
+         Lokal!\n"
+
+SIEHE AUCH
+----------
+::
+
+	/std/room/pub.c
+
+
+Last modified: Sat Mar 04 22:46:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/props/P_PUB_NO_KEEPER.rst b/doc/sphinx/props/P_PUB_NO_KEEPER.rst
new file mode 100644
index 0000000..20c3d25
--- /dev/null
+++ b/doc/sphinx/props/P_PUB_NO_KEEPER.rst
@@ -0,0 +1,38 @@
+P_PUB_NO_KEEPER
+===============
+
+NAME
+----
+::
+
+	P_PUB_NO_KEEPER				"pub_no_keeper"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/pub.h
+
+BESCHREIBUNG
+------------
+::
+
+        In diese Property kann man einen String schreiben, der ausgegeben
+        wird, wenn der in P_KEEPER eingetragene NPC nicht anwesend ist.
+
+BEMERKUNGEN
+-----------
+::
+
+        Die Standardmeldung ist:
+        "Es ist niemand anwesend, der Dich bedienen koennte.\n"
+
+SIEHE AUCH
+----------
+::
+
+	/std/room/pub.c
+
+
+Last modified: Son Apr 11 19:28:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_PUB_NO_MONEY.rst b/doc/sphinx/props/P_PUB_NO_MONEY.rst
new file mode 100644
index 0000000..31e1b17
--- /dev/null
+++ b/doc/sphinx/props/P_PUB_NO_MONEY.rst
@@ -0,0 +1,40 @@
+P_PUB_NO_MONEY
+==============
+
+NAME
+----
+::
+
+	P_PUB_NO_MONEY				"pub_no_money"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/pub.h
+
+BESCHREIBUNG
+------------
+::
+
+        In diese Property kann man einen String schreiben, der ausgegeben
+        wird, wenn der Spieler nicht ueber genug Geld verfuegt, um das
+        gewuenschte Gericht zu bezahlen.
+        Fuer den Preis kann man ein %d als Platzhalter einfuegen.
+
+BEMERKUNGEN
+-----------
+::
+
+        Die Standardmeldung ist:
+        "Das kostet %d Goldstuecke, und Du hast nicht so viel!\n"
+
+SIEHE AUCH
+----------
+::
+
+	/std/room/pub.c
+
+
+Last modified: Sat Mar 04 22:48:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/props/P_PUB_UNAVAILABLE.rst b/doc/sphinx/props/P_PUB_UNAVAILABLE.rst
new file mode 100644
index 0000000..80cd6ef
--- /dev/null
+++ b/doc/sphinx/props/P_PUB_UNAVAILABLE.rst
@@ -0,0 +1,39 @@
+P_PUB_UNAVAILABLE
+=================
+
+NAME
+----
+::
+
+	P_PUB_UNAVAILABLE			"pub_unavailable"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/pub.h
+
+BESCHREIBUNG
+------------
+::
+
+        In diese Property kann man einen String schreiben, der ausgegeben
+        wird, wenn in einer Kneipe ein Getraenk oder eine Speise nicht mehr
+        vorraetig ist.
+
+BEMERKUNGEN
+-----------
+::
+
+        Die Standardmeldung ist:
+        "Davon ist leider nichts mehr da.\n"
+
+SIEHE AUCH
+----------
+::
+
+	/std/room/pub.c
+
+
+Last modified: Sat Mar 04 22:44:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/props/P_PURSUERS.rst b/doc/sphinx/props/P_PURSUERS.rst
new file mode 100644
index 0000000..24f2b88
--- /dev/null
+++ b/doc/sphinx/props/P_PURSUERS.rst
@@ -0,0 +1,30 @@
+P_PURSUERS
+==========
+
+NAME
+----
+::
+
+    P_PURSUERS                    "pursuers"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     Enthaelt Verfolger - nicht von Hand manipulieren!
+
+SIEHE AUCH
+----------
+::
+
+     AddPursuer(L), RemovePursuer(L)
+
+
+16.06.2016, Arathorn
+
diff --git a/doc/sphinx/props/P_PUT_MSG.rst b/doc/sphinx/props/P_PUT_MSG.rst
new file mode 100644
index 0000000..a86ec40
--- /dev/null
+++ b/doc/sphinx/props/P_PUT_MSG.rst
@@ -0,0 +1,79 @@
+P_PUT_MSG
+=========
+
+NAME
+----
+::
+
+     P_PUT_MSG				"put_message"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/put_and_get.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mit P_PUT_MSG kann man die Meldung, die man beim Hineinstecken eines
+     Objektes in einen Container bekommt, modifizieren.
+
+     Folgende Werte sind moeglich:
+
+     o 0
+       Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
+
+     o NO_PNG_MSG	== -1
+       Es wird keinerlei Meldung ausgegeben
+
+     o Ein Array aus Strings
+       Der erste String wird an den Spieler ausgegeben, der zweite
+       (optionale) an den Raum.
+
+       Die Strings werden durch die Funktion replace_personal() geparst.
+	Objekt1 - Spieler
+        Objekt2 - das Objekt, das irgendwohin gesteckt wird
+	Objekt3 - der Container
+
+       Wird der zweite String nicht angegeben, erfolgt keine Meldung an den
+       Raum.
+
+BEISPIEL
+--------
+::
+
+     void create() {
+      ...
+      SetProp( P_SHORT, "Etwas Sand" );
+      SetProp( P_LONG, break_string(
+       "Ein wenig magischer Sand. Sehr feinkruemelig.",78 ));
+
+      SetProp( P_NAME, "Sand" );
+      AddId( ({"sand"}) );
+      SetProp( P_GENDER, MALE );
+
+      SetProp( P_PUT_MSG, ({
+       "Du laesst @WEN2 in @WENU3 rieseln.",
+       "@WER1 laesst @WEN2 in @WENU3 rieseln."}));
+      ...
+     }
+
+     Das ganze fuehrt bei Ugars "stecke sand in paket" zu folgenden
+     Meldungen:
+
+     Ugar: "Du laesst den Sand in ein Paket rieseln."
+     Raum: "Ugar laesst den Sand in ein Paket rieseln."
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_WEAR_MSG, P_WIELD_MSG
+     Fehler:     P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
+                 P_NOINSERT_MSG, P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     Sonstiges:  replace_personal(E), put_obj(L), /std/living/put_and_get.c
+
+14. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_QP.rst b/doc/sphinx/props/P_QP.rst
new file mode 100644
index 0000000..beba199
--- /dev/null
+++ b/doc/sphinx/props/P_QP.rst
@@ -0,0 +1,29 @@
+P_QP
+====
+
+NAME
+----
+::
+
+    P_QP                          "questpoints"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/quest.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der Questpunkte, die ein Spieler hat.
+
+HINWEIS
+-------
+::
+
+     Nur Abfragen der Property mit QueryProp() liefert den korrekten Wert,
+     da eine Quermethode fuer die Auslieferung der Daten sorgt. Query()
+     oder gar QueryProperties() enthalten u.U. einen veralteten Wert.
+
diff --git a/doc/sphinx/props/P_QUALITY.rst b/doc/sphinx/props/P_QUALITY.rst
new file mode 100644
index 0000000..cce352c
--- /dev/null
+++ b/doc/sphinx/props/P_QUALITY.rst
@@ -0,0 +1,58 @@
+P_QUALITY
+=========
+
+NAME
+----
+::
+
+     P_QUALITY "quality"
+
+DEFINIERT IN
+------------
+::
+
+     <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Ruestungen und Waffen koennen im Eifer des Gefechts beschaedigt werden.
+     Setzt man die Property P_QUALITY auf einen Wert n (n>0), so wird
+     eine Waffe (Ruestung) bei jedem n-ten Schlag (Treffer) beschaedigt,
+     d.h. P_WC (P_AC) wird um 1 erniedrigt und P_DAMAGED um 1 erhoeht.
+
+BEISPIEL
+--------
+::
+
+     inherit "/std/weapon";
+
+     ...
+     #include <combat.h>
+
+     create()
+     {
+       ...
+       SetProp(P_QUALITY,200);
+       ...
+     }
+
+     Diese Waffe wuerde bei jedem 200. Schlag etwas beschaedigt.
+
+BEMERKUNG
+---------
+::
+
+     Defaultmaessig ist P_QUALITY auf 0 gesetzt, d.h. die entspr.
+     Waffe/Ruestung wird nicht beschaedigt.
+
+SIEHE AUCH
+----------
+::
+
+     /std/armour.c, /std/weapon.c, TakeFlaw(), QueryFlaw(), Damage()
+
+
+Last modified: Thu May 22 10:42:39 1997 by Paracelsus
+
diff --git a/doc/sphinx/props/P_QUESTS.rst b/doc/sphinx/props/P_QUESTS.rst
new file mode 100644
index 0000000..9f8a61b
--- /dev/null
+++ b/doc/sphinx/props/P_QUESTS.rst
@@ -0,0 +1,21 @@
+P_QUESTS
+========
+
+NAME
+----
+::
+
+    P_QUESTS                      "quests"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/quest.h
+
+BESCHREIBUNG
+------------
+::
+
+     Liste der geloesten Quests.
+
diff --git a/doc/sphinx/props/P_QUEST_ITEM.rst b/doc/sphinx/props/P_QUEST_ITEM.rst
new file mode 100644
index 0000000..4110a03
--- /dev/null
+++ b/doc/sphinx/props/P_QUEST_ITEM.rst
@@ -0,0 +1,76 @@
+P_QUEST_ITEM
+============
+
+NAME
+----
+::
+
+	P_QUEST_ITEM				"quest_item" 
+
+DEFINIERT IN
+------------
+::
+
+	/sys/quest_items.h
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Property gibt an, ob es sich bei dem Objekt um ein Quest-
+	relevantes Objekt handelt.
+
+	
+
+BEISPIEL
+--------
+::
+
+        Ein Schwert (Notung) koennte folgendermassen definiert sein:
+
+	create()
+	{
+	  ::create() ;
+	  SetProp(P_SHORT, "Notung das neidliche Schwert") ;
+	  SetProp(P_LONG, "Das aus seinen Truemmern neu geschmiedete Schwert " 
+	                  "Notung.\n");
+
+	  SetProp(P_NAME, "Notung");
+	  SetProp(P_GENDER, NEUTER);
+	  SetProp(P_ARTICLE,0);
+	  AddId(({"notung","schwert","Notung", "\nNotung"}));
+
+	
+
+	  SetProp(P_WEAPON_TYPE, WT_SWORD);
+	  SetProp(P_DAM_TYPE, DT_BLUDGEON);
+
+	  SetProp(P_QUEST_ITEM,QI_OBJ);
+	  ...
+	}
+
+	    
+
+	Andere Magier koennen nun auf Notung Ruecksicht nehmen, und zum
+	Beispiel davon absehen, es bei einem NPC-Spell zu destructen.
+
+BEMERKUNGEN
+-----------
+::
+
+        Alle questrelevanten Objekte sollten auf diese Weise markiert werden.
+
+	
+
+	Questrelevante Objekte anderer Magier sollten immer mit Vorsicht 
+	behandelt werden.
+
+SIEHE AUCH
+----------
+::
+
+	"/sys/quest_items.h"
+
+
+Last modified: Thu Jul 10 07:08:32 2003 by Vanion
+
diff --git a/doc/sphinx/props/P_RACE.rst b/doc/sphinx/props/P_RACE.rst
new file mode 100644
index 0000000..ba0bde3
--- /dev/null
+++ b/doc/sphinx/props/P_RACE.rst
@@ -0,0 +1,49 @@
+P_RACE
+======
+
+NAME
+----
+::
+
+	P_RACE				"race"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/description.h
+
+BESCHREIBUNG
+------------
+::
+
+	Die Rasse eines Lebewesens kann ueber diese Property ermittelt bzw.
+	gesetzt werden. Es empfiehlt sich hierbei, Rassen nur in Form von
+	grossgeschriebenen Strings zu setzen. Leichen erhalten mittels
+	dieser Property automatisch die Rasse der Lebewesen, aus denen sie
+	hervorgegangen sind.
+	Der Sinn des Ganzen liegt darin, das Spiel differenzierter zu
+	gestalten und auf Rassenspezifika einzugehen. Zum Beispiel koennen
+	Elfen weniger Alkohol vertragen als Zwerge, was in '/std/pub'
+	beruecksichtigt wurde.
+
+BEISPIEL
+--------
+::
+
+	void create()
+	{ ::create();
+	  // Definitionen
+	  SetProp(P_RACE,"Ork");
+	  // weitere Definitionen
+	}
+
+SIEHE AUCH
+----------
+::
+
+	/std/npc.c, /std/pub.c
+
+
+Last modified: Mon Sep 15 21:15:49 2003 by Vanion
+
diff --git a/doc/sphinx/props/P_RACESTRING.rst b/doc/sphinx/props/P_RACESTRING.rst
new file mode 100644
index 0000000..38f7da8
--- /dev/null
+++ b/doc/sphinx/props/P_RACESTRING.rst
@@ -0,0 +1,22 @@
+P_RACESTRING
+============
+
+NAME
+----
+::
+
+    P_RACESTRING                  "racestring"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt eine dem Geschlecht angepasste Beschreibung der Rasse zurueck
+     ("Zwerg" oder "Zwergin" etc.)
+
diff --git a/doc/sphinx/props/P_RACE_DESCRIPTION.rst b/doc/sphinx/props/P_RACE_DESCRIPTION.rst
new file mode 100644
index 0000000..edb6575
--- /dev/null
+++ b/doc/sphinx/props/P_RACE_DESCRIPTION.rst
@@ -0,0 +1,21 @@
+P_RACE_DESCRIPTION
+==================
+
+NAME
+----
+::
+
+    P_RACE_DESCRIPTION            "racedescr"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Beschreibung der Vor/Nachteile einer Rasse.
+
diff --git a/doc/sphinx/props/P_RANGE.rst b/doc/sphinx/props/P_RANGE.rst
new file mode 100644
index 0000000..a647147
--- /dev/null
+++ b/doc/sphinx/props/P_RANGE.rst
@@ -0,0 +1,43 @@
+P_RANGE
+=======
+
+NAME
+----
+::
+
+    P_RANGE     "range"
+
+DEFINIERT IN
+------------
+::
+
+    <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+    Legt die Reichweite einer Schusswaffe fest. Ist ein Schuetze in einem
+    Raum mit gueltigem P_TARGET_AREA (andere Raum) oder environment() und
+    ist fuer diesen Raum P_SHOOTING_AREA festgelegt, dann kann er mit seiner
+    Schusswaffe in diesen anderen Raum schiessen, wenn die P_RANGE groesser
+    als P_SHOOTING_AREA ist.
+
+BEISPIELE
+---------
+::
+
+    // Langbogen mit 100 Reichweite
+    SetProp(P_RANGE, 100);
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
+    Methoden:  FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
+    Gebiet:    P_SHOOTING_AREA, P_TARGET_AREA
+    Sonstiges: fernwaffen
+
+29.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/props/P_READ_DETAILS.rst b/doc/sphinx/props/P_READ_DETAILS.rst
new file mode 100644
index 0000000..a068ae3
--- /dev/null
+++ b/doc/sphinx/props/P_READ_DETAILS.rst
@@ -0,0 +1,40 @@
+P_READ_DETAILS
+==============
+
+NAME
+----
+::
+
+    P_READ_DETAILS                "read_details"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mapping mit den Daten der Details, die durch Lesen ermittelt werden
+    koennen.
+
+BEMERKUNGEN
+-----------
+::
+
+    Bitte nur mit den entsprechenden Methoden veraendern!
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddReadDetail()
+    Loeschen:  RemoveReadDetail()
+    Aehnlich:  AddDetail(), P_DETAILS
+    Veraltet:  P_READ_MSG
+    Sonstiges: GetDetail(), break_string()
+
+27. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_READ_NEWS.rst b/doc/sphinx/props/P_READ_NEWS.rst
new file mode 100644
index 0000000..149b2b4
--- /dev/null
+++ b/doc/sphinx/props/P_READ_NEWS.rst
@@ -0,0 +1,21 @@
+P_READ_NEWS
+===========
+
+NAME
+----
+::
+
+    P_READ_NEWS                   "read_news"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Welche Artikel bereits gelesen wurde (frueher: in der MPA)
+
diff --git a/doc/sphinx/props/P_REAL_RACE.rst b/doc/sphinx/props/P_REAL_RACE.rst
new file mode 100644
index 0000000..b8d5936
--- /dev/null
+++ b/doc/sphinx/props/P_REAL_RACE.rst
@@ -0,0 +1,100 @@
+P_REAL_RACE
+===========
+
+NAME
+----
+::
+
+	P_REAL_RACE				"real_race"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/description.h
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Property enthaelt die Rasse des Livings. Sie darf nicht durch 
+	Shadows ueberschrieben werden.
+
+	
+
+	Wirklich interessant ist sie, wenn ein Spieler sich tarnt. Dort kann
+	man mit dieser Property trotz Tarnung feststellen, welche Rasse der
+	Spieler hat.
+
+	Bei NPC enthaelt sie den gleichen Wert wie P_RACE. Wenn P_REAL_RACE
+	allerdings gesetzt wird, kann man damit einen getarnten NPC simu-
+	lieren, da dann P_RACE und P_REAL_RACE voneinander abweichen.
+
+	
+
+BEISPIEL
+--------
+::
+
+        Ein Zwerg mag Zwergenbrot, fuer Elfen ist es giftig. Selbst wenn der
+	Elf sich als Zwerg tarnt, wird ihm durch lembas sicher uebel werden:
+
+        int futter(string arg)
+        {
+          notify_fail("Was willst Du essen?\n");
+          if(!arg || !id(arg)) return 0;
+
+          notify_fail("Du kannst nichts mehr essen.\n");
+          if(!this_player()->eat_food(55)) return 0;
+
+          write("Du isst ein Stueck Zwegenbrot. Du versuchst es zumindest!\n");
+          say(sprintf("%s beisst in ein Stueck Zwergenbrot. Zahnschmerz!!!\n",
+              this_player()->Name()));
+
+
+          switch( this_player()->QueryProp(P_REAL_RACE) )
+          {
+          case "Zwerg":
+	    if ((this_player()->QueryProp(P_RACE))!="Zwerg")
+	      write("Zur Tarnung spuckst Du etwas von dem Brot aus!\n"); 
+            this_player()->buffer_hp(100,10);
+            this_player()->buffer_sp(100,10);
+            break;
+
+          case "Elf":
+	    write("Das Zwergenbrot brennt wie Feuer auf Deiner Zunge!");
+	    // Getarnt?
+	    if ((this_player()->QueryProp(P_RACE))!="Elf")
+	      write(" Deine Tarnung nutzt Dir da wenig.\n"
+            else write("\n");
+            this_player()->restore_spell_points(-100);
+            this_player()->do_damage(100,this_object());
+            break;
+
+          default:
+	    write("Du bekommst nur wenig davon herunter..\n");
+            this_player()->buffer_hp(10,1);
+            this_player()->buffer_sp(10,2);
+            break;
+          }
+
+  
+
+          remove();
+
+  
+
+          return 1;
+        }
+
+	
+
+SIEHE AUCH
+----------
+::
+
+	/std/living/description.c, /sys/living/description.h, P_RACE
+
+
+Last modified: Mon Sep 15 21:15:49 2003 by Vanion
+
diff --git a/doc/sphinx/props/P_REFERENCE_OBJECT.rst b/doc/sphinx/props/P_REFERENCE_OBJECT.rst
new file mode 100644
index 0000000..67501f5
--- /dev/null
+++ b/doc/sphinx/props/P_REFERENCE_OBJECT.rst
@@ -0,0 +1,42 @@
+P_REFERENCE_OBJECT
+==================
+
+NAME
+----
+::
+
+     P_REFERENCE_OBJECT            "reference_object"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Propertie wird das aktuelle Bezugsobjekt eines Spielers 
+     gespeichert. Untersucht der Spieler ein Monster, so ist dies das 
+     Monsterobjekt, untersucht der Spieler sich selber, ist es das 
+     Spielerobjekt.
+
+     Der Inhalt dieser Propertie besteht also immer aus dem zuletzt 
+     betrachteten Objekt. Sei es ein Raum, eine Ruestung, ein Monster oder 
+     was auch immer. Bewegungsbefehle und andere Kommandos werden nicht 
+     beruecksichtigt.
+
+     Einzig wenn der Spieler 'schau' tippt, wird der Inhalt der Propertie 
+     geloescht und betraegt 0.
+
+SIEHE AUCH
+----------
+::
+
+     Sonstiges:		P_INT_LONG, P_LONG, P_SHORT
+			int_long(), long(), short(), make_invlist()
+
+
+Letzte Aenderung: 29.06.02, 23:50:00 h, von Tilly
+
diff --git a/doc/sphinx/props/P_REJECT.rst b/doc/sphinx/props/P_REJECT.rst
new file mode 100644
index 0000000..82e6b45
--- /dev/null
+++ b/doc/sphinx/props/P_REJECT.rst
@@ -0,0 +1,73 @@
+P_REJECT
+========
+
+NAME
+----
+::
+
+	P_REJECT			"reject"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property zeigt standardmaessig nur in NPCs eine Wirkung. Mit
+	ihr laesst sich sehr einfach einstellen, wie sich ein solcher NPC
+	gegenueber Gegenstaenden verhalten soll, welche ihm zugesteckt
+	werden. Hierbei besteht die Property aus 2 Elementen, welche
+	bestimmt, was der NPC mit Dingen tuen soll, die ihm gegeben werden.
+	Standardmaessig behaelt der NPC die Sachen einfach.
+	Folgende Moeglichkeiten gibt es ausserdem:
+	  1. Arrayelement: Art der Handlung. (aus "/sys/moving.h")
+	    REJECT_GIVE: Der NPC gibt das Objekt zurueck.
+	    REJECT_DROP: Der NPC laesst das Objekt fallen.
+	    REJECT_KEEP: Der NPC behaelt das Objekt doch.
+	    REJECT_LIGHT_MODIFIER: Der NPC nimmt keine Gegenstaende an, die
+	      sein Lichtlevel veraendern und damit Einfluss auf sein
+	      Kampfverhalten haben koennten.
+	  2. Arrayelement: Meldung, mit welcher der NPC die Handlung
+	                   kommentiert.
+	    Der Meldung wird nichts automatisch vorangestellt und ein
+	    abschliessender Zeilenumbruch ist ebenfalls selbstaendig
+	    vorzunehmen. Mit einem Leerstring ist somit auch gar keine
+	    Rueckmeldung moeglich.
+
+BEISPIEL
+--------
+::
+
+	Der NPC schmeisst alle ihm gegebenen Gegenstaende einfach weg:
+	  void create()
+	  { ::create();
+	    ...
+	    SetProp(P_REJECT,({REJECT_GIVE,
+	    Name(WER)+" murmelt: Was soll ich denn damit?!\n"}));
+	    ...
+	  }
+	Manchmal ist das recht nuetzlich, z.B. kann man so eigentlich schwer
+	zu toetende NPCs dagegen schuetzen, dass man ihnen angezuendetes
+	Dynamit oder aehnliches ueberreicht.
+
+BEMERKUNGEN
+-----------
+::
+
+	Innerhalb von NPCs ist die Funktion give_notify() fuer die
+	automatische Auswertung dieser Property verantwortlich; das sollte
+	man insbesondere beim Ueberschreiben dieser Funktion beachten!
+
+SIEHE AUCH
+----------
+::
+
+	give_notify(), /std/npc/put_and_get.c
+
+
+Last modified: Mon Apr 23 16:54:07 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_REMOVE_FUNC.rst b/doc/sphinx/props/P_REMOVE_FUNC.rst
new file mode 100644
index 0000000..0d13b79
--- /dev/null
+++ b/doc/sphinx/props/P_REMOVE_FUNC.rst
@@ -0,0 +1,42 @@
+P_REMOVE_FUNC
+=============
+
+NAME
+----
+::
+
+     P_REMOVE_FUNC "remove_func"
+
+DEFINIERT IN
+------------
+::
+
+     <armour.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Falls ein Objekt eine RemoveFunc() fuer die Ruestung oder Kleidung 
+     definiert, so muss dieses Objekt in dieser Property eingetragen sein.
+
+     Die Auswertung dieser Property erfolgt im Laufe des DoUnwear() in
+     der nicht-oeffentlichen Funktionen _check_unwear_restrictions().
+
+BEISPIELE
+---------
+::
+
+     Siehe das Beispiel zu RemoveFunc()
+
+SIEHE AUCH
+----------
+::
+
+     /std/armour.c, /std/clothing.c, clothing, armours
+     RemoveFunc()
+
+
+Letzte Aenderung:
+15.02.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_REMOVE_MSG.rst b/doc/sphinx/props/P_REMOVE_MSG.rst
new file mode 100644
index 0000000..f0d100b
--- /dev/null
+++ b/doc/sphinx/props/P_REMOVE_MSG.rst
@@ -0,0 +1,54 @@
+P_REMOVE_MSG
+============
+
+NAME
+----
+::
+
+     P_REMOVE_MSG                  "std_food_remove_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung, wenn eine verdorbene Speise gerade vernichtet wird.
+     Diese Meldung erscheint nur, wenn in P_DESTROY_BAD ein positiver
+     Integer-Wert gesetzt ist.
+     Befindet sich die Speise in einem Spieler, geht die Meldung an genau
+     diesen, liegt die Speise im Raum, geht die Meldung an alle anwesenden
+     Spieler.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "@WER1 zerfaellt zu Staub."
+
+SIEHE AUCH
+----------
+::
+
+     P_DESTROY_BAD, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_RESET_LIFETIME.rst b/doc/sphinx/props/P_RESET_LIFETIME.rst
new file mode 100644
index 0000000..5671ee6
--- /dev/null
+++ b/doc/sphinx/props/P_RESET_LIFETIME.rst
@@ -0,0 +1,55 @@
+P_RESET_LIFETIME
+================
+
+NAME
+----
+::
+
+     P_RESET_LIFETIME              "std_food_lifetime_reset"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/food.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zeit in Resets, die die Speise haltbar ist.
+     Jeder einzelne Reset wird in seiner Laenge zufaellig festgelegt und
+     zu einer Gesamtanzahl von Sekunden zusammengefasst. Diese Zeit in
+     Sekunden wird dann in P_LIFETIME gespeichert.
+     Nach dieser Zeit wird diese Speise schlecht und je nach Konfiguration
+     der Speise eventuell zerstoert. Sichergestellt wird dies durch den
+     Aufruf von reset() nach dieser Anzahl "Resets".
+     Moechte man eine Speise haben, die niemals verdirbt
+     (genehmigungspflichtig!), nutzt man die Property P_NO_BAD
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Sobald der Countdown zum Schlechtwerden der Speise laeuft, also ein
+     Spieler damit in Beruehrung kam, zeigt SetProp auf diese Property keine
+     Wirkung mehr.
+
+DEFAULT
+-------
+::
+
+     Ohne Setzen von P_LIFETIME ,P_RESET_LIFETIME und P_NO_BAD verdirbt die
+     Speise nach einem Reset, also zwischen 30 und 60 Minuten
+
+SIEHE AUCH
+----------
+::
+
+     wiz/food, P_LIFETIME, P_NO_BAD
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_RESISTANCE.rst b/doc/sphinx/props/P_RESISTANCE.rst
new file mode 100644
index 0000000..fede888
--- /dev/null
+++ b/doc/sphinx/props/P_RESISTANCE.rst
@@ -0,0 +1,61 @@
+P_RESISTANCE
+============
+
+NAME
+----
+::
+
+     P_RESISTANCE                  "resistance"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+WICHTIG
+-------
+::
+
+     DIESE PROPERTY IST VERALTET! BITTE P_RESISTANCE_STRENGTHS
+     VERWENDEN! AUCH FUNKTIONIERT Set() NICHT WIE ES SOLLTE.
+
+BESCHREIBUNG
+------------
+::
+
+     Hiermit koennen die Resistenzen eines Lebewesens sehr einfach gesetzt
+     werden. Es kann ein Array mit Schadensarten gesetzt werden, jeder
+     Eintrag eines Schadens verdoppelt die Resistenz gegen diesen.
+
+BEMERKUNGEN
+-----------
+::
+
+     - P_RESISTANCE_STRENGTHS spiegelt diese Eintraege hier wieder
+     - um genauere Werte anzugeben einen AddResistanceModifier() oder
+       P_RESISTANCE_STRENGTHS benutzen.
+     - P_RESISTANCE kann und wird nicht aus P_RESISTANCE_STRENGTHS
+       upgedatet
+
+BEISPIELE
+---------
+::
+
+     // ein NPC mit halbierter Feuerempfindlichkeit und
+     // geviertelter Windempfindlichkeit
+     SetProp(P_RESISTANCE, ({DT_FIRE, DT_AIR, DT_AIR}));
+
+SIEHE AUCH
+----------
+::
+
+     simple Resistenz:	P_RESISTANCE
+     Modifikatoren:	AddResistanceModifier, RemoveResistanceModifier(),
+			P_RESISTANCE_MODIFIER
+     Hauptmapping:	P_RESISTANCE_STRENGTHS
+     Berechnung:	CheckResistance(), UpdateResistanceStrengths()
+     anderes:		balance, /std/armour/combat.c, /std/living/combat.c
+
+1.Dez 2004, Gloinson
+
diff --git a/doc/sphinx/props/P_RESISTANCE_MODIFIER.rst b/doc/sphinx/props/P_RESISTANCE_MODIFIER.rst
new file mode 100644
index 0000000..a87fdeb
--- /dev/null
+++ b/doc/sphinx/props/P_RESISTANCE_MODIFIER.rst
@@ -0,0 +1,45 @@
+P_RESISTANCE_MODIFIER
+=====================
+
+NAME
+----
+::
+
+     P_RESISTANCE_MODIFIER             "rstr:mod"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Hier werden die Resistenzmodifikatoren in einem Mapping abgespeichert.
+
+     Format:
+
+     (["me":<Aufaddition aller Resistenz/Empfindlichkeitsmodifikationen>;0,
+       "<Objektname>#<Schluessel>":<Resistenzmapping>;<Objekreferenz>,
+       ...])
+
+BEMERKUNGEN
+-----------
+::
+
+     Nur ueber AddResistanceModifier(), RemoveResistanceModifier() aendern!
+
+SIEHE AUCH
+----------
+::
+
+     Modifikatoren:	AddResistanceModifier, RemoveResistanceModifier()
+     simple Resistenz:	P_RESISTANCE, P_VULNERABILITY
+     Hauptmapping:	P_RESISTANCE_STRENGTHS
+     Berechnung:	CheckResistance(), UpdateResistanceStrengths()
+     anderes:		balance, /std/armour/combat.c, /std/living/combat.c
+
+29.Apr 2002, Gloinson@MG
+
diff --git a/doc/sphinx/props/P_RESISTANCE_STRENGTHS.rst b/doc/sphinx/props/P_RESISTANCE_STRENGTHS.rst
new file mode 100644
index 0000000..26a4ca8
--- /dev/null
+++ b/doc/sphinx/props/P_RESISTANCE_STRENGTHS.rst
@@ -0,0 +1,114 @@
+P_RESISTANCE_STRENGTHS
+======================
+
+NAME
+----
+::
+
+     P_RESISTANCE_STRENGTHS     "resistance_strengths"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Lebewesen:
+
+     Mapping mit Schadensarten, gegen die das Lebewesen resistent oder
+     anfaellig ist. Durch eine _query_method werden alle existierenden
+     Resistenzen hier zusammengefasst.
+
+     Die Staerke der Resistenz oder Anfaelligkeit wird numerisch aus-
+     gedrueckt:
+     - Resistenzen gehen bis von 0 bis -1.0 (absolute Resistenz)
+       - -0.5 == halbierter Schaden, -0.75 == geviertelter Schaden
+       -> in % des "aufgehaltenen" Schadens interpretierbar
+     - Empfindlichkeiten gehen von 0 bis MAX_INT
+       -  1.0 == verdoppelter Schaden, 3.0 == vervierfachter Schaden
+       -> als Faktor (x+1.0) interpretierbar
+
+     Ruestungen:
+
+     Mapping mit Prozentwerten der Maximalwerte fuer Ruestungen des
+     entsprechenden Typs. Dabei sind positive Werte Resistenzen und
+     negative Empfindlichkeiten. Dabei duerfen die Prozentwerte nur
+     im Bereich von +100 bis -800 (-1000 ?!) liegen.
+
+     Bei Ruestungen ist es damit unnoetig, Resistenzen mittels
+     AddResistanceModifier() im Traeger zu setzen, da dies bereits
+     in /std/armour automatisch gemacht wird. Der Schluessel fuer
+     den Eintrag ist dabei P_ARMOUR_TYPE.
+
+     Die Maximalwerte sind derzeit:
+      AT_CLOAK, AT_RING, AT_AMULET: max 10% Resistenz
+      AT_SHIELD, AT_ARMOUR:  max 15% Resistenz
+      alle anderen:   max 5% Resistenz
+
+BEMERKUNGEN
+-----------
+::
+
+     Ruestungen:
+     * die Property muss _nach_ P_ARMOUR_TYPE gesetzt werden (_set-Method)
+
+     Lebewesen:
+     * -1.0 bedeutet bereits absolute Resistenz, bei kleineren Werten werden
+       die anderen Schadensanteile im Kampf u.U. nicht mehr wie gewuenscht
+       bilanziert. Bitte daher drauf verzichten. ;-)
+     * Aenderungen an P_RESISTANCE und P_VULNERABILITY werden direkt in 
+       P_RESISTANCE_STRENGTHS gespeichert:
+       -> daher niemals im Nachhinein bei fremden NPCs P_RESISTANCE_STRENGTHS
+          manipulieren, dafuer gibt es AddResistanceModifier
+     * QueryProp(P_RESISTANCE_STRENGTHS) enthaelt die gesamten Resistenzen
+       P_RESISTANCE, P_VULNERABILITY, P_RESISTANCE_MODIFIER (_query-Method)
+
+     Die Werte in P_RESISTANCE_STRENGTHS sollten nur in Ausnahmefaellen oder
+     gut begruendet den Hoechstwert haben. Ein Eiswesen kann zwar sehr
+     resistent gegen Kaelteschaden sein, sollte aber zu gleichem Teil auch
+     anfaellig auf Feuerschaden sein.
+
+     Auf dieser Property liegt eine Querymethode, welche eine Kopie der
+     Daten zurueckliefert.
+
+BEISPIELE
+---------
+::
+
+     // ein Eistroll
+     SetProp(P_RESISTANCE_STRENGTHS,([DT_FIRE:0.5,DT_COLD:-0.5,
+                                      DT_MAGIC:0.1]));
+
+     Feuerangriffe werden mit 1.5 multipliziert, magische mit 1.1 und
+     der Schadenswert von Kaelteangriffen wird halbiert. Zum Beispiel
+     wuerde
+     Defend(100, ({DT_FIRE,DT_MAGIC}), ...)
+     einen Schaden von 130 statt den normalen 100 verursachen.
+
+
+     // eine Eisruestung
+     SetProp(P_RESISTANCE_STRENGTHS, ([DT_COLD:50, DT_FIRE:-100]));
+
+     Dieses Kettenhemd schuetzt nun mit 50% des Maximalwertes gegen
+     Kaelte (also 0.5*15%=7,5% Resistenz) und macht mit dem Maximal-
+     wert anfaellig gegen Feuer (1*15%=15% Empfindlichkeit).
+
+     ! der Code spricht zusaetzlich von
+       Empfindlichkeit=(Empfindlichkeit/4)*5 -> 15/4*5=18.75% !
+
+SIEHE AUCH
+----------
+::
+
+     simple Resistenz: P_RESISTANCE, P_VULNERABILITY
+     Modifikatoren: AddResistanceModifier, RemoveResistanceModifier(),
+     P_RESISTANCE_MODIFIER
+     Berechnung: CheckResistance(), UpdateResistanceStrengths()
+     anderes:  balance, /std/armour/combat.c, /std/living/combat.c
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_RESTRICTIONS.rst b/doc/sphinx/props/P_RESTRICTIONS.rst
new file mode 100644
index 0000000..c5682ff
--- /dev/null
+++ b/doc/sphinx/props/P_RESTRICTIONS.rst
@@ -0,0 +1,163 @@
+P_RESTRICTIONS
+==============
+
+NAME
+----
+::
+
+    P_RESTRICTIONS                                "restrictions"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/combat.h
+    (Die SR_*-Parameter sind in /sys/new_skills.h definiert.)
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt ein mapping mit den zu pruefenden Einschraenkungen.
+
+    In dieser Property lassen sich Restriktionen setzen, die vor dem
+    Zuecken einer Waffe / Anziehen einer Ruestung oder Kleidung geprueft
+    werden und dies gegebenfalls verhindern, ohne gleich auf eine evtl.
+    vorhandene WieldFunc / WearFunc zuzugreifen.
+
+    Die Auswertung erfolgt ueber den Aufruf von check_restrictions()
+    in /std/restriction_checker.c
+
+    Folgende Keys werden in dem Mapping ausgewertet:
+
+    P_LEVEL
+      Mindeststufe, die das Lebewesen besitzen muss, um die Aktion
+      auszufuehren.
+    P_GUILD_LEVEL
+      Gildenlevel, das das Lebewesen mindestens erreicht haben muss, um die
+      Aktion auszufuehren.
+    SR_SEER
+      Ist gesetzt, wenn das Lebewesen Seher sein muss.
+      Auswertung nur fuer Interactives, NSC ignorieren das Flag.
+    P_XP
+      Mindestmenge an Erfahrungspunkten, die ein Lebewesen besitzen muss,
+      um die Aktion auszufuehren.
+    P_QP
+      Mindestmenge an Abenteuerpunkten, die das Lebewesen haben muss.
+    P_ALCOHOL
+      Menge an Alkohol, unter der der Alkoholspiegel des Lebewesen liegen
+      muss, um die Aktion noch ausfuehren zu koennen.
+    P_DRINK
+      Menge an Fluessigkeit, unter der der Fluessigkeitsspiegel des
+      Lebewesen liegen muss, um die Aktion noch ausfuehren zu koennen.
+    P_FOOD
+      Beinhaltet die Menge an Nahrung, unter der der Nahrungsspiegel des
+      Spielers liegen muss, um die Aktion noch ausfuehren zu koennen.
+    P_DEAF
+      Ist gesetzt, falls der Spieler nicht taub sein darf.
+    P_FROG
+      Ist gesetzt, falls der Spieler kein Frosch sein darf.
+    P_BLIND
+      Ist gesetzt, falls der Spieler nicht blind sein darf.
+      Achtung: das ist nicht gleichbedeutend mit dem Umstand, dass er evtl.
+      nichts mehr sehen kann. Auch andere Gruende (zum Beispiel Dunkelheit)
+      koennen bewirken, dass ein Spieler nichts mehr sieht.
+    A_INT, A_DEX, A_CON, A_STR
+      Jeweilige Mindesthoehe eines Attribut, um eine Aktion ausfuehren zu
+      koennen.
+    SR_BAD, SR_GOOD
+      Gibt an, wie [minimal] boese bzw. wie [maximal] gut ein Charakter sein
+      darf, um eine Aktion ausfuehren zu koennen.
+    SR_MIN_SIZE, SR_MAX_SIZE
+      Gibt die minimale, bzw. die maximale Groesse an, die ein Charakter
+      maximal haben darf, um eine Aktion ausfuehren zu koennen.
+    SR_FREE_HANDS
+      Gibt an, wieviele freie Haende ein Charakter fuer diese Aktion
+      besitzen muss.
+    SR_EXCLUDE_RACE
+      Mitglieder aller in dieser Liste aufgefuehrten Rassen koennen
+      diese Aktion nicht ausfuehren.
+    SR_INCLUDE_RACE
+      Mitglieder aller NICHT in dieser Liste aufgefuehrten Rassen koennen
+      diese Aktion nicht ausfuehren.
+    SM_RACE
+      Hier kann pro Rasse ein Mapping mit besonderen (nur) fuer diese Rasse
+      geltenden Einschraenkungen vorgenommen werden. Als Keys sind die
+      in dieser Manpage beschriebenen Keys erlaubt, wobei SM_RACE nicht
+      rekursiv ausgewertet wird.
+      Der Rassenname ist gross geschrieben und "*" steht fuer alle Rassen.
+    SR_EXCLUDE_GUILD
+    SR_INCLUDE_GUILD
+      Diese beiden Keys verhalten sich wie SR_*_RACE, nur dass hier Gilden
+      genannt werden.
+    SR_FUN
+      Hier kann eine Funktion in verschiedenen Formen zum Pruefen der
+      Restriktionen angegeben werden, siehe execute_anything().
+      Das kann nuetzlich sein, um andere Restriktionen zu pruefen,
+      wie das Bestehen von Miniquests oder andere Faehigkeiten/Flags.
+      Ist der Test nicht bestanden, gibt die Funktion einen String zurueck.
+    SR_PROP
+      Hier kann ein Mapping mit Properties und zugehoerigen Werten angegeben
+      werden, die jeweils auf Identitaet geprueft werden. Zusaetzlich sollte
+      eine Meldung angegeben werden, die als Fehlermeldung ausgegeben wird,
+      wenn der Spieler die Bedingung nicht erfuellt. Es sollte immer eine
+      passende Meldung fuer den Spieler eingebaut werden. Beispiel:
+      ([ SR_PROP: ([P_AUSGANG_ENTDECKT: 1; "Dein Schwert fluestert "
+          "veraergert: Ich werde Dir erst dann zu Diensten sein, wenn Du "
+          "Dich als wuerdig erwiesen hast!"]) ])
+      Aufgrund der Meldung wird empfohlen, SR_PROP nicht in Restriktionen 
+      einzusetzen, die massenweise in Savefiles landen (z.B. 
+      Spielersavefiles).
+    SR_QUEST
+      Hier kann ein String-Array mit den Namen (Keys) der Quest(s) angegeben
+      werden, die der Spieler bestanden haben muss, um die Aktion ausfuehren
+      zu koennen.
+    SR_MINIQUEST
+      Hier kann entweder ein String-Array mit den Ladenamen der vergebenden
+      Objekte oder ein Int-Array mit den Index-Nummern (IDs) der
+      Miniquest(s) (empfohlen!) angegeben werden, die der Spieler bestanden
+      haben muss, um die Aktion ausfuehren zu koennen.
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Property eignet sich hervorragend dafuer, einige Grundbedingungen
+    fuer das Nutzen der Waffe / Ruestung / Kleidung zu stellen ohne gleich
+    eine Wield- oder WearFunc setzen und auswerten zu muessen.
+
+    Denkbar waere der Einsatz bei hochwertigen Waffen / Ruestungen / Kleidung,
+    z.B. aus der Para-Welt oder solchen, die sich nah am Limit der geltenden
+    Grenzwerte fuer P_WC / P_AC bewegen oder sogar (nach Genehmigung durch
+    die Balance) darueber.
+
+BEISPIEL
+--------
+::
+
+    Mindeststufe 25: SetProp(P_RESTRICTIONS,([P_LEVEL:25]));
+    Keine Menschen:  SetProp(P_RESTRICTIONS,([SR_EXCLUDE_RACE:({"Mensch"})]));
+    Alignment >499:  SetProp(P_RESTRICTIONS,([SR_GOOD:500]));
+
+    Komplexeres Beispiel
+
+    Quest "Diamond Club" bestanden, magiereigene Property P_AUSGANG_GEFUNDEN
+    muss gesetzt sein, Stufe 10, nicht taub, max. 45 Food:
+    SetProp(P_RESTRICTIONS, ([ P_LEVEL: 10, P_DEAF: 1, P_FOOD: 45,
+      SR_PROP: ([P_AUSGANG_GEFUNDEN:1]), SR_QUEST:({"Diamond Club"}) ]));
+
+SIEHE AUCH
+----------
+::
+
+    check_restrictions(L)
+    WieldFunc(L), WearFunc(L), RemoveFunc(L), UnwieldFunc(L),
+    P_WIELD_FUNC, P_WEAR_FUNC, P_REMOVE_FUNC, P_UNWIELD_FUNC
+    /std/armour/wear.c, /std/weapon/combat.c, clothing, armours, weapon
+
+LETZTE AeNDERUNG
+----------------
+::
+
+03. Januar 2014, Arathorn
+
diff --git a/doc/sphinx/props/P_ROOM_MSG.rst b/doc/sphinx/props/P_ROOM_MSG.rst
new file mode 100644
index 0000000..087f9c2
--- /dev/null
+++ b/doc/sphinx/props/P_ROOM_MSG.rst
@@ -0,0 +1,39 @@
+P_ROOM_MSG
+==========
+
+NAME
+----
+::
+
+    P_ROOM_MSG                    "room_msg"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Liste mit Meldungen, die zufaellig im Raum ausgegeben werden.
+
+     Hier sind nur die Textmeldungen als String-Array gespeichert.
+
+ANMERKUNGEN
+-----------
+::
+
+     Bitte AddRoomMessage() zum Hinzufuegen/Ueberschreiben benutzen!
+
+SIEHE AUCH
+----------
+::
+
+     LFuns:    AddRoomMessage()
+     Verwandt: tell_room(), ReceiveMsg()
+     Props:    P_FUNC_MSG, P_MSG_PROB
+
+2.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_ROOM_TYPE.rst b/doc/sphinx/props/P_ROOM_TYPE.rst
new file mode 100644
index 0000000..a1a269a
--- /dev/null
+++ b/doc/sphinx/props/P_ROOM_TYPE.rst
@@ -0,0 +1,39 @@
+P_ROOM_TYPE
+===========
+
+NAME
+----
+::
+
+    P_ROOM_TYPE                       "room_type"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/rooms.h
+
+BESCHREIBUNG
+------------
+::
+
+    In P_ROOM_TYPE wird die Art des Raumes durch entsprechende Flags
+    beschrieben.
+
+    Bisher unterstuetzt werden:
+        - RT_SHOP       fuer Raeume, die /std/room/shop inheriten
+        - RT_PUB        fuer Raeume, die /std/room/pub inheriten
+
+BEISPIEL
+--------
+::
+
+    Wenn ein NPC abfragen moechte, ob er sich in einer Kneipe aufhaelt (um
+    selbststaendig tanken zu koennen) koennte eine Abfrage z.B. so aussehen:
+
+        if ( environment() &&
+             environment()->QueryProp(P_ROOM_TYPE) & RT_PUB ){
+
+            ... tanken ...
+        }
+
diff --git a/doc/sphinx/props/P_SB_SPELLS.rst b/doc/sphinx/props/P_SB_SPELLS.rst
new file mode 100644
index 0000000..c019f46
--- /dev/null
+++ b/doc/sphinx/props/P_SB_SPELLS.rst
@@ -0,0 +1,42 @@
+P_SB_SPELLS
+===========
+
+NAME
+----
+::
+
+    P_SB_SPELLS            "sb_spells"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Spellbookproperty sind saemtliche Sprueche des Spellbooks
+    vermerkt. Veraendert wird sie durch AddSpell().
+
+BEMERKUNGEN
+-----------
+::
+
+    Man sollte diese Property nicht per Hand veraendern, sondern die
+    Funktion AddSpell() nutzen.
+
+SIEHE AUCH
+----------
+::
+
+    GObj Verwalten:   LearnSkill, LearnSpell, InitialSkillAbility
+    * Properties:     P_GUILD_SKILLS
+    Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
+    * Verwalten:      AddSpell, QuerySpell
+    * Properties:     P_GLOBAL_SKILLPROPS
+    Skills:           P_NEWSKILLS, spruchermuedung, skill_info_liste
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_SCREENSIZE.rst b/doc/sphinx/props/P_SCREENSIZE.rst
new file mode 100644
index 0000000..c81b33f
--- /dev/null
+++ b/doc/sphinx/props/P_SCREENSIZE.rst
@@ -0,0 +1,21 @@
+P_SCREENSIZE
+============
+
+NAME
+----
+::
+
+    P_SCREENSIZE                  "screensize"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Bildschirmgroesse in Zeilen (fuer More)
+
diff --git a/doc/sphinx/props/P_SECOND.rst b/doc/sphinx/props/P_SECOND.rst
new file mode 100644
index 0000000..74e1fb3
--- /dev/null
+++ b/doc/sphinx/props/P_SECOND.rst
@@ -0,0 +1,40 @@
+P_SECOND
+========
+
+NAME
+----
+::
+
+    P_SECOND                      "second"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn diese Prop gesetzt ist, ist der Spieler ein Zweitie. Inhalt der
+     Prop ist ein String mit dem (lowercase) Namen des Ersties.
+
+BEISPIEL
+--------
+::
+
+     if (this_player()->QueryProp(P_SECOND)=="notstrom") {
+       tell_object(this_player(), "Nicht alles aufessen!\n");
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Properties: P_SECOND_MARK
+     Sonstiges:  /secure/zweities.c
+
+
+Last modified: 18-Jun-2015, Arathorn.
+
diff --git a/doc/sphinx/props/P_SECOND_MARK.rst b/doc/sphinx/props/P_SECOND_MARK.rst
new file mode 100644
index 0000000..aeea609
--- /dev/null
+++ b/doc/sphinx/props/P_SECOND_MARK.rst
@@ -0,0 +1,31 @@
+P_SECOND_MARK
+=============
+
+NAME
+----
+::
+
+    P_SECOND_MARK                 "second_mark"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt an, wie mit der Zweitie-Markierung eines Spielers umgegangen wird.
+
+     -1  'unsichtbare' Markierung; im wer/kwer wird bei diesem Zweitie s
+         oder S angezeigt.
+
+      0  'sichtbare' Markierung; im wer/kwer wird bei diesem Zweitie z oder
+         Z angezeigt. Der Name des Ersties ist beim Fingern jedoch nur
+         fuer Magier sichtbar.
+
+      1  Markierung 'sichtbar + Name'; wie 0, nur dass beim Fingern alle
+         Spieler den Namen des Ersties sehen koennen.
+
diff --git a/doc/sphinx/props/P_SEERDOORS.rst b/doc/sphinx/props/P_SEERDOORS.rst
new file mode 100644
index 0000000..c90a21e
--- /dev/null
+++ b/doc/sphinx/props/P_SEERDOORS.rst
@@ -0,0 +1,49 @@
+P_SEERDOORS
+===========
+
+NAME
+----
+::
+
+     P_SEERDOORS      "rw_sehertore"
+
+DEFINIERT IN
+------------
+::
+
+     /d/seher/portale/sehertor.h
+
+BESCHREIBUNG
+------------
+::
+
+     Sehertor-relevante Property.
+
+     Enthaelt ein Mapping mit den Wertepaaren
+     ([ Seher-Portal-Nummer: x ])
+     mit x != 0 fuer entdeckte Tore.
+
+     
+
+     0 hat ein Sonderverhalten fuer mobile Tore.
+
+BEMERKUNG
+---------
+::
+
+     Auf gar keinen Fall in Spielern manipulieren! Und bitte das enthaltene
+     Mapping nicht von einem Spieler abfragen und P_SEERDOORS in einem
+     Testspieler zuweisen!
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     P_FAO_PORTALS
+
+     
+
+1.September 2008 Gloinson
+
diff --git a/doc/sphinx/props/P_SEERDOOR_ALLOWED.rst b/doc/sphinx/props/P_SEERDOOR_ALLOWED.rst
new file mode 100644
index 0000000..525e53d
--- /dev/null
+++ b/doc/sphinx/props/P_SEERDOOR_ALLOWED.rst
@@ -0,0 +1,27 @@
+P_SEERDOOR_ALLOWED
+==================
+
+NAME
+----
+::
+
+    P_SEERDOOR_ALLOWED		"rw_sehertor_erlaubt"                          
+
+DEFINIERT IN
+------------
+::
+
+    /d/seher/portale/sehertor.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property muss in einem Raum gesetzt sein, soll
+     ein Seher dort ein mobiles Sehertor abstellen duerfen.
+     Zusaetzlich darf der Raum nicht in PARA liegen und muss
+     als eigenes File existieren.
+     Es ist darauf zu achten, Sehertore nicht in Questgebieten,
+     direkt an Tanken oder aehnlichen Plaetzen zu erlauben.
+     Es gilt die Einschaetzung des fuer den Raum Verantwortlichen.
+
diff --git a/doc/sphinx/props/P_SENSITIVE.rst b/doc/sphinx/props/P_SENSITIVE.rst
new file mode 100644
index 0000000..fa6d633
--- /dev/null
+++ b/doc/sphinx/props/P_SENSITIVE.rst
@@ -0,0 +1,154 @@
+P_SENSITIVE
+===========
+
+NAME
+----
+::
+
+     P_SENSITIVE                   "sensitive"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property kann in Objekten gesetzt werden, die auf bestimmte
+     Schadensarten empfindlich reagieren sollen. Moegliche Anwendungsfaelle:
+     - Das Lebewesen, in dessen Inventar sich ein Objekt befindet, erleidet
+       einen Angriff mit der fraglichen Schadensart (Beispiel: eine 
+       Pusteblume, die bei Angriff mit Luftschaden auseinanderfaellt).
+     - Zwei Objekte treffen im gleichen Environment aufeinander, wobei
+       eines empfindlich auf eine Schadensart reagiert, und das zweite diese
+       Schadensart mitbringt, d.h. die Empfindlichkeit ausloesen kann.
+       (Beispiel: ein feuerempfindlicher Postsack wird angesengt, wenn eine
+        brennende Fackel ins gleiche Inventar kommt.)
+       Das Ausloesen dieser Empfindlichkeit ist unabhaengig davon, welches 
+       Objekt zuerst da war.
+
+     Die Property enthaelt ein Array aus Arrays:
+       ({<sensprops_1>, <sensprops_2>, ..., <sensprops_n>})
+
+     
+
+     wobei jeder Eintrag <sensprops> jeweils folgende Struktur hat:
+       ({string list_key, string damtype, int treshold, mixed options })
+
+     
+
+     Die Eintraege haben dabei folgende Bedeutung:
+
+     
+
+     list_key: Kann einen von folgenden drei Werten annehmen 
+          1) SENSITIVE_INVENTORY, passive Eigenschaft; zeigt an, dass das
+             Objekt empfindlich auf aktive Objekte reagiert, die in das
+             Inventory des Containers hineinbewegt werden
+          2) SENSITIVE_ATTACK, passive Eigenschaft; zeigt an, dass das 
+             Objekt empfindlich auf aeussere Einfluesse bzw. Angriffe 
+             auf ein Lebewesen reagiert, in dessen Inventar es sich befindet
+          3) SENSITIVE_INVENTORY_TRIGGER, aktive Eigenschaft; zeigt an, dass
+             das Objekt eine Ausstrahlung auf andere Objekte im Inventar
+             hat. Wird ausgeloest, wenn das Objekt ins Inventar hineinbewegt
+             wird.
+     damtype: eine Schadensart (DT_FIRE, DT_WATER, ...)
+     treshold: hat zwei Bedeutungen abhaengig von dem Wert in list_key:
+          1) Fuer Objekte mit SENSITIVE_INVENTORY oder SENSITIVE_ATTCK ist
+             dies der Schadenswert, ab dem das Objekt benachrichtigt werden 
+             soll.
+             Hier wird ein Wert in "Defend-Einheiten" erwartet, d.h. das
+             Zehnfache dessen, was am Ende in LP abgezogen wuerde.
+          2) Fuer Objekte mit SENSITIVE_INVENTORY_TRIGGER ist dies der 
+             Schadenswert, mit dem das Objekt andere bereits im Inventar
+             des Containers befindliche Objekte beeinflusst, die eine 
+             entsprechende Empfindlichkeit gesetzt haben
+     options: Optionale Daten, die der programmierende Magier selbst
+            definieren kann. Werden an die in den betroffenen Objekten
+            aufgerufenen Funktionen durchgereicht.
+
+     Ein SENSITIVE_ATTACK-Objekt, dessen Trigger-Bedingungen erfuellt sind,
+     wird durch folgenden Funktionsaufruf darueber informiert:
+       trigger_sensitive_attack(object enemy, string damtype, int damage,
+                 mixed spell, mixed options)
+
+     
+
+     Ein SENSITIVE_INVENTORY-Objekt, dessen Trigger-Bedingungen erfuellt sind,
+     wird durch folgenden Funktionsaufruf darueber informiert:
+       trigger_sensitive_inv(object whodid, string damtype, int threshold,
+                 mixed options, mixed options)
+
+     Die beiden Funktionen muessen selbst ge-/ueberschrieben werden.
+
+BEMERKUNGEN
+-----------
+::
+
+     1. P_SENSITIVE-Objekte kosten Rechenzeit bei jedem Angriff oder jedem
+        move() - daher bitte sparsam verwenden
+     2. Ist P_SENSITIVE nicht statisch, sondern wird es situationsabhaengig 
+        geaendert, muss man das environment() jeweils selbst ueber seine 
+        neue Empfindlichkeit benachrichtigen. Dies geschieht mit den 
+        Funktionen RemoveSensitiveObject() bzw.InsertSensitiveObject(), 
+        siehe deren Manpages.
+
+BEISPIEL
+--------
+::
+
+     Beispiel 1:
+     Beispielcode eines Objektes mit SENSITIVE_ATTACK und SENSITIVE_INVENTORY
+     siehe hier: /doc/beispiele/testobjekte/attack_busy_sensitive_testobj.c
+
+     Beispiel 2:
+     Ein Eiszapfen, der bei Feuerangriffen oder bei heissen Gegenstaenden im
+     gemeinsamen Environment zerschmelzen soll:
+
+     void create() {
+       SetProp( P_SENSITIVE, ({ ({SENSITIVE_ATTACK,     DT_FIRE, 100}),
+                                 ({SENSITIVE_INVENTORY, DT_FIRE, 100}) }) );
+       [...]
+     }
+
+     varargs void trigger_sensitive_attack() {
+       remove();
+     }
+
+     varargs void trigger_sensitive_inv() {
+       call_out("remove",0);  // verzoegert, wegen move()
+     }
+
+     varargs int remove(int silent) {
+       if(!silent) {
+         object room = all_environment(this_object())[<1];
+         tell_room(room, Name()+" zerschmilzt.\n");
+       }
+       return ::remove();
+     }
+
+     - wird eine Fackel mit
+       SetProp(P_SENSITIVE,({({SENSITIVE_INVENTORY_TRIGGER,DT_FIRE,250})}))
+       in das gleiche environment() wie dieser Zapfen bewegt wird, loest
+       diese im Zapfen trigger_sensitive_inv() aus
+     - wird ein Angriff mit DT_FIRE und initialem Schaden > 100 auf das
+       environment() veruebt, loest dies im Zapfen trigger_sensitive_attack()
+       aus
+
+SIEHE AUCH
+----------
+::
+
+     Properties: P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY,
+                 P_SENSITIVE_INVENTORY_TRIGGER
+     Funktionen: InsertSensitiveObject(L), RemoveSensitiveObject(L),
+                 CheckSensitiveAttack(L), Defend(), 
+                 insert_sensitive_inv(L), insert_sensitive_inv_trigger(L),
+                 trigger_sensitive_inv(L), trigger_sensitive_attack(L)
+     Defines:    /sys/sensitive.h
+
+Letzte Aenderung: 10. Januar 2015, Arathorn
+
diff --git a/doc/sphinx/props/P_SENSITIVE_ATTACK.rst b/doc/sphinx/props/P_SENSITIVE_ATTACK.rst
new file mode 100644
index 0000000..818fb06
--- /dev/null
+++ b/doc/sphinx/props/P_SENSITIVE_ATTACK.rst
@@ -0,0 +1,42 @@
+P_SENSITIVE_ATTACK
+==================
+
+NAME
+----
+::
+
+    P_SENSITIVE_ATTACK            "sensitive_attack"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/sensitive.h
+
+BESCHREIBUNG
+------------
+::
+
+    Hier steht die Liste der zu informierenden Objekte, die potentiell
+    auf einen Angriff reagieren koennten.
+    Wird von InsertSensitiveObject() und RemoveSensitiveObject()
+    geschrieben und in CheckSensitiveAttack() ausgewertet.
+
+BEMERKUNGEN
+-----------
+::
+
+    Nicht selbst veraendern - bitte P_SENSITIVE fuer Eintraege benutzen.
+
+SIEHE AUCH
+----------
+::
+
+     P_SENSITIVE
+     InsertSensitiveObject, RemoveSensitiveObject
+     insert_sensitive_inv_trigger, insert_sensitive_inv
+     P_SENSITIVE_INVENTORY_TRIGGER, P_SENSITIVE_INVENTORY
+     CheckSensitiveAttack
+
+25.Apr.2001, Gloinson@MG
+
diff --git a/doc/sphinx/props/P_SENSITIVE_INVENTORY.rst b/doc/sphinx/props/P_SENSITIVE_INVENTORY.rst
new file mode 100644
index 0000000..5ecec2d
--- /dev/null
+++ b/doc/sphinx/props/P_SENSITIVE_INVENTORY.rst
@@ -0,0 +1,43 @@
+P_SENSITIVE_INVENTORY
+=====================
+
+NAME
+----
+::
+
+    P_SENSITIVE_INVENTORY         "sensitive_inv"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/sensitive.h
+
+BESCHREIBUNG
+------------
+::
+
+    Hier steht die Liste der zu informierenden Objekte, die potentiell
+    auf ein anderes Objekt mit gesetztem P_SENSITIVE_INVENTORY_TRIGGER
+    reagieren koennten.
+    Wird von InsertSensitiveObject() und RemoveSensitiveObject()
+    geschrieben.
+
+BEMERKUNGEN
+-----------
+::
+
+    Nicht selbst veraendern - bitte P_SENSITIVE fuer Eintraege benutzen.
+
+SIEHE AUCH
+----------
+::
+
+     P_SENSITIVE
+     InsertSensitiveObject, RemoveSensitiveObject
+     insert_sensitive_inv_trigger, insert_sensitive_inv
+     P_SENSITIVE_INVENTORY_TRIGGER, P_SENSITIVE_ATTACK
+     CheckSensitiveAttack
+
+25.Apr.2001, Gloinson@MG
+
diff --git a/doc/sphinx/props/P_SENSITIVE_INVENTORY_TRIGGER.rst b/doc/sphinx/props/P_SENSITIVE_INVENTORY_TRIGGER.rst
new file mode 100644
index 0000000..94beaae
--- /dev/null
+++ b/doc/sphinx/props/P_SENSITIVE_INVENTORY_TRIGGER.rst
@@ -0,0 +1,42 @@
+P_SENSITIVE_INVENTORY_TRIGGER
+=============================
+
+NAME
+----
+::
+
+    P_SENSITIVE_INVENTORY_TRIGGER "sensitive_inv_trigger"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/sensitive.h
+
+BESCHREIBUNG
+------------
+::
+
+    Hier steht die Liste der aktiven Objekte, die eine potentielle
+    "Ausstrahlung" auf andere Objekte haben.
+    Wird von InsertSensitiveObject() und RemoveSensitiveObject()
+    geschrieben.
+
+BEMERKUNGEN
+-----------
+::
+
+    Nicht selbst veraendern - bitte P_SENSITIVE fuer Eintraege benutzen.
+
+SIEHE AUCH
+----------
+::
+
+     P_SENSITIVE
+     InsertSensitiveObject, RemoveSensitiveObject
+     insert_sensitive_inv_trigger, insert_sensitive_inv
+     P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY
+     CheckSensitiveAttack
+
+25.Apr.2001, Gloinson@MG
+
diff --git a/doc/sphinx/props/P_SHOOTING_AREA.rst b/doc/sphinx/props/P_SHOOTING_AREA.rst
new file mode 100644
index 0000000..b331623
--- /dev/null
+++ b/doc/sphinx/props/P_SHOOTING_AREA.rst
@@ -0,0 +1,38 @@
+P_SHOOTING_AREA
+===============
+
+NAME
+----
+::
+
+    P_SHOOTING_AREA     "shooting_area"
+
+DEFINIERT IN
+------------
+::
+
+    <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+    Legt die 'Groesse' eines Raumes fest. Ein Schuetze kann mit seiner
+    Fernkampfwaffe nur dann aus diesem Raum in einen anderen Raum schiessen,
+    wenn die P_RANGE seiner Waffe mindestens gleich ist.
+
+    Erreichbare Raeume sind entweder das environment() oder der in
+    P_SHOOTING_AREA festgelegte Raum.
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
+    Methoden:  FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
+    Gebiet:    P_RANGE, P_TARGET_AREA
+    Raeume:    P_NEVER_CLEAN
+    Sonstiges: fernwaffen
+
+29.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/props/P_SHOOTING_WC.rst b/doc/sphinx/props/P_SHOOTING_WC.rst
new file mode 100644
index 0000000..06c1759
--- /dev/null
+++ b/doc/sphinx/props/P_SHOOTING_WC.rst
@@ -0,0 +1,48 @@
+P_SHOOTING_WC
+=============
+
+NAME
+----
+::
+
+    P_SHOOTING_WC     "shooting_wc"
+
+DEFINIERT IN
+------------
+::
+
+    <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+    Legt in einer Fernkampfwaffe UND ihrer Munition die Waffenstaerke fest.
+    Bei einem Schuss wird die Summe kombiniert mit der Geschicklichkeit
+    zur Berechnung der Angriffstaerke benutzt.
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_SHOOTING_WC, 70);     // Langbogen
+    SetProp(P_SHOOTING_WC, 50);     // Kurzbogen
+
+    SetProp(P_SHOOTING_WC, 40);     // Bambuspfeil
+    SetProp(P_SHOOTING_WC, 60);     // Aluminiumpfeil
+
+    // So haetten Langbogen mit Aluminiumpfeil eine P_SHOOTING_WC von 70+60.
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_AMMUNITION, P_STRETCH_TIME
+    Methoden:  FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
+    Gebiet:    P_RANGE, P_SHOOTING_AREA, P_TARGET_AREA
+    Waffen:    P_WEAPON_TYPE, P_WC, P_EQUIP_TIME, P_NR_HANDS
+    Kampf:     Attack(L), Defend(L), P_DISABLE_ATTACK, P_ATTACK_BUSY
+    Sonstiges: fernwaffen
+
+29.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/props/P_SHORT.rst b/doc/sphinx/props/P_SHORT.rst
new file mode 100644
index 0000000..34d23e5
--- /dev/null
+++ b/doc/sphinx/props/P_SHORT.rst
@@ -0,0 +1,61 @@
+P_SHORT
+=======
+
+NAME
+----
+::
+
+     P_SHORT				"short"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt die Kurzbeschreibung des Objektes als String 
+     oder Closure (diese muss einen String zurueckgeben).
+
+     ACHTUNG: Die Kurzbeschreibung sollte dabei weder mit einem
+	      Satzzeichen noch mit einem "\n" abgeschlossen sein
+	      (dies wird von den zustaendigen Funktionen erledigt).
+
+     Setzt man diese Property auf 0, so ist das Objekt unsichtbar, allerdings
+     ansprechbar, wenn der Spieler eine ID des Objektes kennt. D.h. Objekte
+     koennen mitgenommen, weggeworfen oder ggf. auch angegriffen werden. Will
+     man dies nicht, sollte man das Objekt mit P_INVIS unsichtbar machen.
+
+     Diese Property bestimmt die Ansicht des Objektes von aussen. Fuer die
+     Innen(kurz)ansicht von Raeumen muss man P_INT_LONG benutzen.
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Funktion, die die Kurzbeschreibung ausgibt (short()), filtert P_SHORT
+     durch process_string(). Von der Nutzung dieses Features wird in neuem
+     Code abgeraten.
+     Soll eine dyn. Kurzbeschreibung geschaffen werden, bitte eine
+     F_QUERY_METHOD einsetzen oder short() passend ueberschreiben.
+
+BEISPIELE
+---------
+::
+
+     // eine Axt sieht natuerlich so aus:
+     SetProp(P_SHORT, "Eine Axt");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	P_LONG, short()
+     Sonstiges:		P_INT_SHORT, process_string()
+
+
+27.05.2015, Zesstra
+
diff --git a/doc/sphinx/props/P_SHORT_CWD.rst b/doc/sphinx/props/P_SHORT_CWD.rst
new file mode 100644
index 0000000..a76cb42
--- /dev/null
+++ b/doc/sphinx/props/P_SHORT_CWD.rst
@@ -0,0 +1,21 @@
+P_SHORT_CWD
+===========
+
+NAME
+----
+::
+
+    P_SHORT_CWD                   "short_cwd"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/shells.h
+
+BESCHREIBUNG
+------------
+::
+
+     .readme bei cd ausgeben oder nicht
+
diff --git a/doc/sphinx/props/P_SHOWEMAIL.rst b/doc/sphinx/props/P_SHOWEMAIL.rst
new file mode 100644
index 0000000..abfb6f4
--- /dev/null
+++ b/doc/sphinx/props/P_SHOWEMAIL.rst
@@ -0,0 +1,23 @@
+P_SHOWEMAIL
+===========
+
+NAME
+----
+::
+
+     P_SHOWEMAIL                        "showemail"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Eintrag, wer die E-Mail im "finger" zu sehen bekommen soll:
+     0, "alle", "freunde"
+     Kann durch "emailanzeige" (/std/player/base.c) geaendert werden.
+
diff --git a/doc/sphinx/props/P_SHOW_ALIAS_PROCESSING.rst b/doc/sphinx/props/P_SHOW_ALIAS_PROCESSING.rst
new file mode 100644
index 0000000..e025ad1
--- /dev/null
+++ b/doc/sphinx/props/P_SHOW_ALIAS_PROCESSING.rst
@@ -0,0 +1,21 @@
+P_SHOW_ALIAS_PROCESSING
+=======================
+
+NAME
+----
+::
+
+    P_SHOW_ALIAS_PROCESSING       "show_alias_processing"       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Arbeit des Parsers beobachten (debugging)
+
diff --git a/doc/sphinx/props/P_SHOW_EXITS.rst b/doc/sphinx/props/P_SHOW_EXITS.rst
new file mode 100644
index 0000000..6949c6a
--- /dev/null
+++ b/doc/sphinx/props/P_SHOW_EXITS.rst
@@ -0,0 +1,31 @@
+P_SHOW_EXITS
+============
+
+NAME
+----
+::
+
+    P_SHOW_EXITS                  "show_exits"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Im Spieler gesetzt, wenn der Spieler die offensichtlichen Ausgaenge
+     immer automatisch sehen will.
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	P_HIDE_EXITS
+     Sonstiges:		AddExit(), GetExits(), int_long(), int_short()
+
+11. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_SHOW_INV.rst b/doc/sphinx/props/P_SHOW_INV.rst
new file mode 100644
index 0000000..c5fea36
--- /dev/null
+++ b/doc/sphinx/props/P_SHOW_INV.rst
@@ -0,0 +1,33 @@
+P_SHOW_INV
+==========
+
+NAME
+----
+::
+
+     P_SHOW_INV "show_inv"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn diese Property auf einen Wert ungleich 0 gesetzt ist, wird das
+     Objekt, soweit es sich in einem Spieler befindet, in dessen
+     Langbeschreibung angezeigt. Zur Anzeige wird der Name des Objektes
+     verwendet.
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/description.c
+
+
+Last modified: Sun May 19 20:36:05 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_SHOW_MSG.rst b/doc/sphinx/props/P_SHOW_MSG.rst
new file mode 100644
index 0000000..7430ffb
--- /dev/null
+++ b/doc/sphinx/props/P_SHOW_MSG.rst
@@ -0,0 +1,69 @@
+P_SHOW_MSG
+==========
+
+NAME
+----
+::
+
+    P_SHOW_MSG                          "show_message"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/put_and_get.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mit P_SHOW_MSG kann man die Meldungen, die beim Vorzeigen eines Objektes
+    ausgegeben werden, modifizieren.
+
+    Folgende Werte sind moeglich:
+
+    o 0
+      Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
+
+    o NO_PNG_MSG        == -1
+      Es wird keinerlei Meldung ausgegeben
+
+    o Ein Array aus Strings
+      Der erste String wird an den Spieler ausgegeben, der zweite
+      (optionale) an den Raum, der dritte (ebenfalls optionale) an den
+      Empfaenger.
+
+      Die Strings werden durch die Funktion replace_personal() geparst.
+        Objekt1 - Spieler
+        Objekt2 - das Objekt, das uebergeben wird
+        Objekt3 - Empfaenger
+
+      Wird der zweite String nicht angegeben, erfolgt keine Meldung an den
+      Raum. Beim Fehlen des dritten gibt es keine Meldung an den Empfaenger.
+
+BEISPIEL
+--------
+::
+
+    SetProp(P_SHOW_MSG, ({
+      "Du haeltst @WEM3 @WEN2 unter die Nase.",
+      "@WER1 haelt @WEM3 @WENU2 unter die Nase.",
+      "@WER1 haelt Dir @WENU2 unter die Nase."
+    }));
+
+    Das fuehrt bei Ugars "zeig peter medaille" zu folgenden Meldungen:
+
+    Ugar: "Du haeltst Peter die Medaille unter die Nase."
+    Raum: "Ugar haelt Peter eine Medaille unter die Nase."
+    Peter: "Ugar haelt Dir eine Medaille unter die Nase."
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_DROP_MSG, P_PUT_MSG, P_PICK_MSG, P_GIVE_MSG
+     Sonstiges:  replace_personal(E), show(L), show_objects(L),
+                 show_notify(L), /std/living/put_and_get.c
+
+3. Juni 2008 Amynthor
+
diff --git a/doc/sphinx/props/P_SIBLINGS.rst b/doc/sphinx/props/P_SIBLINGS.rst
new file mode 100644
index 0000000..4b48849
--- /dev/null
+++ b/doc/sphinx/props/P_SIBLINGS.rst
@@ -0,0 +1,22 @@
+P_SIBLINGS
+==========
+
+NAME
+----
+::
+
+    P_SIBLINGS                     "siblings"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Enthaelt einen String mit den Blutsbruedern eines Spielers
+     (sofern vorhanden).
+
diff --git a/doc/sphinx/props/P_SIZE.rst b/doc/sphinx/props/P_SIZE.rst
new file mode 100644
index 0000000..bf6d182
--- /dev/null
+++ b/doc/sphinx/props/P_SIZE.rst
@@ -0,0 +1,50 @@
+P_SIZE
+======
+
+NAME
+----
+::
+
+    P_SIZE                        "size"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Groesse des Lebewesens bzw. Laenge der Waffe (in cm).
+
+     Wird keine Waffenlaenge explizit angegeben, so sind die Defaultwerte
+     fuer die entsprechenden Waffentypen folgende:
+
+    	WT_SWORD  : 100
+    	WT_AXE    :  80
+    	WT_CLUB   :  80
+    	WT_SPEAR  : 180
+    	WT_KNIFE  :  20
+    	WT_WHIP   : 200
+    	WT_STAFF  : 150
+
+BEMERKUNGEN
+-----------
+::
+
+     1. Uebertreibt es bitte mit der Groesse nicht, auch sehr grosse NPCs 
+        sollten nicht ueber 1000000 liegen. Sonst kriegt die Karategilde 
+        Probleme.
+     2. Negative Werte fuer P_SIZE sind nicht moeglich, da dies zum einen
+        voellig unsinnig ist und zum anderen evtl. zu Problemen mit Waffen
+        fuehrt, die Schaden in Abhaengigkeit von P_SIZE machen und sich
+        darauf verlassen, dass nur positive Werte vorkommen.
+
+LETZTE AENDERUNG
+----------------
+::
+
+    2006-09-29, von Zesstra
+
diff --git a/doc/sphinx/props/P_SKILLS.rst b/doc/sphinx/props/P_SKILLS.rst
new file mode 100644
index 0000000..11f06c3
--- /dev/null
+++ b/doc/sphinx/props/P_SKILLS.rst
@@ -0,0 +1,31 @@
+P_SKILLS
+========
+
+NAME
+----
+::
+
+	P_SKILLS			"skills"                      
+
+DEFINIERT IN
+------------
+::
+
+	/sys/player/skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property sollte nicht mehr verwendet werden. Sie wurde
+	vollstaendig durch P_NEWSKILLS ersetzt.
+
+SIEHE AUCH
+----------
+::
+
+	P_NEW_SKILLS
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_SKILL_ATTRIBUTES.rst b/doc/sphinx/props/P_SKILL_ATTRIBUTES.rst
new file mode 100644
index 0000000..6842bfd
--- /dev/null
+++ b/doc/sphinx/props/P_SKILL_ATTRIBUTES.rst
@@ -0,0 +1,69 @@
+P_SKILL_ATTRIBUTES
+==================
+
+NAME
+----
+::
+
+    P_SKILL_ATTRIBUTES        "skill_attr"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/skill_attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Prop stehen alle nicht-permanenten Modifikatoren der
+    Skill-Attribute.
+    Die Datenstruktur ist ein Mapping mit den SA-Namen als Schluessel und
+    jeweils drei Werten pro Schluessel.
+    Der erste Wert ist ein Array mit drei Werten: der Summe der stat.
+    Modifier, dem Zeitpunkt an dem dies Summe ungueltig wird und der
+    Gesamtzahl aktiver Modifikatoren.
+    Der zweite Wert enthaelt ein Mapping mit allen statischen Modifikatoren
+    und den Objekten dieser Mods als Schluessel. Die beiden Werte dieses
+    Mappings sind der Wert des Modifikators (int) und die Ablaufzeit (int).
+    Der dritte Wert enthaelt ein Mapping mit allen dynamischen
+    Modifikatoren und den Objekten dieser Mods als Schluessel. Die beiden
+    Werte dieses Mappings sind die zu rufende Closure (closure) und die
+    Ablaufzeit des Mods (int).
+
+    ([ SA_ATTR: ({Summe_Stat_Modifier, Zeitpunkt, AnzahlModifier, });
+                ([ ob1:value;duration,
+                   ob2:value;duration, ...]);  // stat. Modifier
+                ([ ob1:closure;duration,
+                   ob2:closure;duration, ...])     // dyn. Modifier
+                ,
+       SA_ATTR2: ({...}); ([]); ([]),
+       SA_ATTR3: ({...}); ([]); ([]),
+    ])
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Property darf AUF GAR KEINEN FALL per Hand manipuliert werden,
+    dafuer gibt es die Funktionen ModifySkillAttribute() und
+    RemoveSkillAttributeModifier().
+    Zum Auslesen stehen QuerySkillAttribute() und
+    QuerySkillAttributeModifier() zur Verfuegung.
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkill, QuerySkillAbility
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung, skill_info_liste
+    * Properties:   P_NEWSKILLS
+
+13.09.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_SKILL_ATTRIBUTE_OFFSETS.rst b/doc/sphinx/props/P_SKILL_ATTRIBUTE_OFFSETS.rst
new file mode 100644
index 0000000..cd0c619
--- /dev/null
+++ b/doc/sphinx/props/P_SKILL_ATTRIBUTE_OFFSETS.rst
@@ -0,0 +1,49 @@
+P_SKILL_ATTRIBUTE_OFFSETS
+=========================
+
+NAME
+----
+::
+
+    P_SKILL_ATTRIBUTE_OFFSETS       "skill_attr_offsets"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/skill_attributes.h
+
+BESHREIBUNG
+-----------
+::
+
+    Der Wert der Property ist ein Mapping: ([Attributname: Wert])
+    In dieser Property stehen permanente Abweichungen der Skillattribute
+    vom Standardwert 100.
+
+    Zu den Moeglichen Attributwerten, siehe P_SKILL_ATTRIBUTES.
+
+    Die Werte duerfen zwischen 10 und 1000 liegen.
+
+BEMERKUNG
+---------
+::
+
+    Diese Property sollte AUF GAR KEINEN FALL in einem Spieler gesetzt
+    werden, ohne Ruecksprachen mit allerhoechsten Stellen!
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkill, QuerySkillAbility
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung, skill_info_liste
+    * Properties:   P_NEWSKILLS
+
+31.12.2013, Zesstra
+
diff --git a/doc/sphinx/props/P_SMELLS.rst b/doc/sphinx/props/P_SMELLS.rst
new file mode 100644
index 0000000..ec53aa6
--- /dev/null
+++ b/doc/sphinx/props/P_SMELLS.rst
@@ -0,0 +1,43 @@
+P_SMELLS
+========
+
+NAME
+----
+::
+
+    P_SMELLS            "smell_details"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property entspricht dem P_DETAILS fuer Standarddetails,
+    nur werden hierin Gerueche gespeichert:
+    Diese Property enthaelt ein Mapping, in der Details im Objekt
+    definiert werden und Beschreibungen, die ausgegeben werden, wenn man
+    sich diese Details anschaut.
+
+BEMERKUNGEN
+-----------
+::
+
+    Man sollte diese Property nicht per Hand veraendern, sondern die
+    Funktionen nutzen.
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddSmells()
+    Loeschen:  RemoveSmells()
+    Aehnlich:  AddDetail(), P_DETAILS
+    Sonstiges: GetDetail(), break_string()
+
+27. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_SNOOPFLAGS.rst b/doc/sphinx/props/P_SNOOPFLAGS.rst
new file mode 100644
index 0000000..4fe7ec6
--- /dev/null
+++ b/doc/sphinx/props/P_SNOOPFLAGS.rst
@@ -0,0 +1,21 @@
+P_SNOOPFLAGS
+============
+
+NAME
+----
+::
+
+    P_SNOOPFLAGS                  "snoopflags"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/snooping.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_SOUNDS.rst b/doc/sphinx/props/P_SOUNDS.rst
new file mode 100644
index 0000000..6ba71ad
--- /dev/null
+++ b/doc/sphinx/props/P_SOUNDS.rst
@@ -0,0 +1,43 @@
+P_SOUNDS
+========
+
+NAME
+----
+::
+
+    P_SOUNDS            "sound_details"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property entspricht dem P_DETAILS fuer Standarddetails,   
+    nur werden hierin Gerauesche gespeichert:
+    Diese Property enthaelt ein Mapping, in der Details im Objekt
+    definiert werden und Beschreibungen, die ausgegeben werden, wenn man
+    sich diese Details anschaut.
+
+BEMERKUNGEN
+-----------
+::
+
+    Man sollte diese Property nicht per Hand veraendern, sondern die
+    Funktionen nutzen.
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddSounds()
+    Loeschen:  RemoveSounds()
+    Aehnlich:  AddDetail(), P_DETAILS
+    Sonstiges: GetDetail(), break_string()
+
+27. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_SP.rst b/doc/sphinx/props/P_SP.rst
new file mode 100644
index 0000000..33978ef
--- /dev/null
+++ b/doc/sphinx/props/P_SP.rst
@@ -0,0 +1,38 @@
+P_SP
+====
+
+NAME
+----
+::
+
+    P_SP                          "sp"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     - Lebewesen
+       Anzahl der Konzentrationspunkte des Wesens.
+
+     - Speisen/Kneipen
+       Heilwirkung einer Portion der Speise auf die Konzentrationspunkte
+       des Konsumenten
+
+SIEHE AUCH
+----------
+::
+
+     Props:		P_MAX_SP
+     Veraenderung:	reduce_spell_points(), restore_spell_points()
+			buffer_sp()
+     Speisen/Kneipen:   std/pub, wiz/food, consume
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_SPECIAL_DETAILS.rst b/doc/sphinx/props/P_SPECIAL_DETAILS.rst
new file mode 100644
index 0000000..e8f7c2b
--- /dev/null
+++ b/doc/sphinx/props/P_SPECIAL_DETAILS.rst
@@ -0,0 +1,42 @@
+P_SPECIAL_DETAILS
+=================
+
+NAME
+----
+::
+
+    P_SPECIAL_DETAILS             "special_details"             
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mapping von Details, die beim Anschauen eine Funktion starten.
+
+BEMERKUNGEN
+-----------
+::
+
+    Dies ist keine "echte" Property. Die Daten werden bei der Abfrage in einer
+    Querymethode dynamisch aus P_DETAILS extrahiert. Dementsprechend
+    funktioniert es auch nicht, hier eine Query- oder Setmethode von aussen
+    drauf zu legen.
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddDetail()
+    Loeschen:  RemoveDetail()
+    Daten:     P_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail()
+    Sonstiges: GetDetail(), break_string()
+
+27. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_SPECIAL_EXITS.rst b/doc/sphinx/props/P_SPECIAL_EXITS.rst
new file mode 100644
index 0000000..8a11c3e
--- /dev/null
+++ b/doc/sphinx/props/P_SPECIAL_EXITS.rst
@@ -0,0 +1,51 @@
+P_SPECIAL_EXITS
+===============
+
+NAME
+----
+::
+
+    P_SPECIAL_EXITS               "special_exits"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt ein Mapping (der Breite 2) mit den Ausgaengen, der Funktion,
+    die jeweils gerufen wird, wenn der Ausgang benutztwird und einer
+    Bewegungsmeldung.
+
+    
+
+    Die Bewegungsmeldung wird bei SpecialExits nicht ausgewertet, sondern
+    ist nur aufgrund der gemeinsamen Datenstruktur vorhanden. Im Normalfall
+    ist sie 0.
+
+BEMERKUNG
+---------
+::
+
+    Keine echte Property, wird bei der Abfrage aus P_EXITS erstellt.
+
+    
+
+    Zugriff nur mit den dafuer vorgesehenen Funktionen, nicht aendern!
+
+SIEHE AUCH
+----------
+::
+
+     AddExit(), AddSpecialExit(), GetExits(),
+     RemoveExit(), RemoveSpecialExit(),
+     GuardExit(),
+     H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
+     ausgaenge
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/props/P_SPELLRATE.rst b/doc/sphinx/props/P_SPELLRATE.rst
new file mode 100644
index 0000000..b6e8249
--- /dev/null
+++ b/doc/sphinx/props/P_SPELLRATE.rst
@@ -0,0 +1,21 @@
+P_SPELLRATE
+===========
+
+NAME
+----
+::
+
+    P_SPELLRATE                   "spellrate"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     NPC-Spellrate (in %)
+
diff --git a/doc/sphinx/props/P_SPELLS.rst b/doc/sphinx/props/P_SPELLS.rst
new file mode 100644
index 0000000..560912b
--- /dev/null
+++ b/doc/sphinx/props/P_SPELLS.rst
@@ -0,0 +1,21 @@
+P_SPELLS
+========
+
+NAME
+----
+::
+
+    P_SPELLS                      "spells"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     NPC-Spells
+
diff --git a/doc/sphinx/props/P_SP_DELAY.rst b/doc/sphinx/props/P_SP_DELAY.rst
new file mode 100644
index 0000000..9e72d2c
--- /dev/null
+++ b/doc/sphinx/props/P_SP_DELAY.rst
@@ -0,0 +1,23 @@
+P_SP_DELAY
+==========
+
+NAME
+----
+::
+
+    P_SP_DELAY                 "sp_delay"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der heart_beats, bis die Magiepunkte um einen Punkt steigen.
+     Aenderungen dieser Property in Spielern beduerfen der 
+     Genehmigung des EM fuer Balance.
+
diff --git a/doc/sphinx/props/P_START_HOME.rst b/doc/sphinx/props/P_START_HOME.rst
new file mode 100644
index 0000000..f81b611
--- /dev/null
+++ b/doc/sphinx/props/P_START_HOME.rst
@@ -0,0 +1,21 @@
+P_START_HOME
+============
+
+NAME
+----
+::
+
+    P_START_HOME                  "start_home"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Raum, in dem der Spieler nach dem Einloggen landen soll
+
diff --git a/doc/sphinx/props/P_STD_OBJECT.rst b/doc/sphinx/props/P_STD_OBJECT.rst
new file mode 100644
index 0000000..6e3e583
--- /dev/null
+++ b/doc/sphinx/props/P_STD_OBJECT.rst
@@ -0,0 +1,59 @@
+P_STD_OBJECT
+============
+
+NAME
+----
+::
+
+    P_STD_OBJECT                  "std_object"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/v_compiler.h
+
+BESCHREIBUNG
+------------
+::
+
+   Enthaelt den Namen eines Files welches als Standard-Objekt fuer den 
+   Virtual Compiler gelten soll.
+
+   In diesem File werden das generelle Aussehen, Ausgaenge, Funktionen
+   usw. der VC-generierten Raeume / Objekte festgelegt.
+
+   Dieses File ist ein 'normales' .c - File, welches geclont wird und
+   anschliessend umbenannt wird.
+
+   
+
+   Ganz wichtig: Falls euer Standardobjekt (direkt oder indirekt) von
+   /std/room.c erbt, solltet ihr darauf achten, dass euer Objekt ausser dem
+   create() noch eine weitere (beliebige) Funktion hat.  
+   Ansonsten wuerde das Programm eures Standardobjekts automatisch durch
+   /std/room.c ersetzt, was in der Regel zu schwer zu findenen Bugs fuehrt.
+
+BEISPIEL
+--------
+::
+
+   (create eines VCs)
+   protected void create() {
+     ...
+     SetProp(P_STD_OBJECT,"/d/region/magier/vc/std_raum");
+     ...
+   }
+
+   Was in diesem std_raum.c nun steht, wird in jedem VC-Clone
+   verfuegbar. Sei es Details, Gerueche, auch Objekte die per 
+   AddItem eingebunden sind, ...
+
+SIEHE AUCH
+----------
+::
+
+   P_COMPILER_PATH, virtual_compiler
+
+Letzte Aenderung: 22.10.07 von Zesstra
+
diff --git a/doc/sphinx/props/P_STORE_CONSUME.rst b/doc/sphinx/props/P_STORE_CONSUME.rst
new file mode 100644
index 0000000..aa5737a
--- /dev/null
+++ b/doc/sphinx/props/P_STORE_CONSUME.rst
@@ -0,0 +1,70 @@
+P_STORE_CONSUME
+===============
+
+NAME
+----
+::
+
+	P_STORE_CONSUME			"store_consume"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/bank.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property ist entscheidend dafuer, wieviel Prozent an Objekten
+	bei jedem Reset in einem Lager eines Ladens vernichtet werden. Dies
+	geschieht aus Speicher- und Laggruenden. Es verbleibt dabei jedoch
+	eine Grundmenge an Objekten, deren Anzahl in der Property
+	P_MIN_STOCK festgehalten ist. Standardwert fuer P_STORE_CONSUME ist
+	hierbei 30%, aber in oft benutzten Laeden kann man dort ruhig einen
+	hoeheren Wert eintragen. Erlaubt sind Werte zwischen 0% und 100%.
+	Aufgeraeumt werden jedoch keine Objekte, die mittels AddItem() im
+	Lager eingebunden wurden. Mittels der Ladenfunktion AddFixedObject()
+	als staendig verfuegbar markierte Objekte werden natuerlich auch
+	nicht beruecksichtigt.
+	Beide hier erwaehnten Properties sollten ueberigens nur mittels
+	QueryProp/SetProp ausgelesen bzw. veraendert werden.
+
+BEISPIEL
+--------
+::
+
+	Ein eigener haeufig benutzter Laden koennte ein Lager in folgender
+	Form erhalten:
+	  // myStore
+	  #include <bank.h>
+	  inherit "std/store";
+	  void create()
+	  { ::create();
+	    SetProp(P_STORE_CONSUME,90);
+	    // keine weiteren Beschreibungen, Spieler sollen da drin
+	    // schliesslich nicht rumwuseln
+	  }
+	Um das Lager dem Laden zuzuweisen, nutzt man folgendes:
+	  // myShop
+	  inherit "std/laden";
+	  void create()
+	  { ::create();
+	    SetStorageRoom("pfad/myStore");
+	    // Beschreibungen folgen
+	    ...
+	  }
+	Es werden hierbei waehrend jedes Lager-Resets 90% der im Lager
+	befindlichen Objekte vernichtet.
+
+SIEHE AUCH
+----------
+::
+
+	P_MIN_STOCK, SetStorageRoom(), /std/store.c, /std/shop.c
+	AddItem(), RemoveItem(), AddFixedObject(), RemoveFixedObject()
+
+
+Last modified: 19-Jun-2015, Arathorn 
+
diff --git a/doc/sphinx/props/P_STRETCH_TIME.rst b/doc/sphinx/props/P_STRETCH_TIME.rst
new file mode 100644
index 0000000..b2e7aa7
--- /dev/null
+++ b/doc/sphinx/props/P_STRETCH_TIME.rst
@@ -0,0 +1,34 @@
+P_STRETCH_TIME
+==============
+
+NAME
+----
+::
+
+    P_STRETCH_TIME     "stretch_time"
+
+DEFINIERT IN
+------------
+::
+
+    <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die Zeit in Runden (2s), die man braucht, um eine Fernwaffe zu
+    spannen/benutzen. Zaehlt seit dem letzten Schuss oder der Zeit des
+    Zueckens (P_EQUIP_TIME).
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_AMMUNITION, P_SHOOTING_WC
+    Methoden:  FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
+    Gebiet:    P_RANGE, P_SHOOTING_AREA, P_TARGET_AREA
+    Sonstiges: fernwaffen
+
+29.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/props/P_SUBGUILD_TITLE.rst b/doc/sphinx/props/P_SUBGUILD_TITLE.rst
new file mode 100644
index 0000000..5759932
--- /dev/null
+++ b/doc/sphinx/props/P_SUBGUILD_TITLE.rst
@@ -0,0 +1,38 @@
+P_SUBGUILD_TITLE
+================
+
+NAME
+----
+::
+
+     P_SUBGUILD_TITLE		"subguild_title"                       
+
+DEFINIERT IN
+------------
+::
+
+     /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt eventuelle Zusatztitel eines Spielers, den er
+     innerhalb einer Gilde traegt. Das kann z.B. ein Clan sein, ein Zweig oder
+     einfach nur der Gildenrang.
+
+BEMERKUNGEN
+-----------
+::
+
+     Inhalt der Property kann 0 sein oder ein String.  Ein Zusatztitel kann
+     mittels P_VISIBLE_SUBGUILD_TITLE vorgetaeuscht werden.
+
+SIEHE AUCH
+----------
+::
+
+     P_GUILD_TITLE, P_VISIBLE_SUBGUILD_TITLE
+
+26. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_SYNTAX_HELP.rst b/doc/sphinx/props/P_SYNTAX_HELP.rst
new file mode 100644
index 0000000..04710b4
--- /dev/null
+++ b/doc/sphinx/props/P_SYNTAX_HELP.rst
@@ -0,0 +1,62 @@
+P_SYNTAX_HELP
+=============
+
+NAME
+----
+::
+
+    P_SYNTAX_HELP              "lib_p_syntax_help"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/commands.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Property kann man fuer Spieler eine ausfuehrliche Syntaxhilfe zu
+    den Kommandos eines Objektes ablegen. Diese wird angezeigt, wenn der
+    Spieler das Kommando "synxtaxhilfe <objekt>" eingibt.
+    Die Property kann verschiedene Datenstrukturen enthalten:
+
+    1) ein String
+    Der String wird angezeigt, hierbei ggf. umgebrochen, vorhandene
+    Zeilenumbrueche werden beibehalten.
+
+    2) ein Array: ({hilfetext, bedingungen})
+
+    <hilfetext>:
+      * ein string:
+        Der String wird angezeigt, hierbei ggf. umgebrochen, vorhandene
+        Zeilenumbrueche werden beibehalten.
+      * eine lfun-closure:
+        Diese erhaelt beim Aufruf das betreffende Objekt als Argument.
+        Wenn diese dann einen String zurueckliefert, wird dieser dem Spieler
+        angezeigt. Hierbei wird ggf. umgebrochen, vorhandene Zeilenumbrueche
+        werden beibehalten.
+
+    <bedingungen>, welche erfuellt sein muessen, damit dem Spieler die Hilfe
+    angezeigt wird. Die Bedingungen sind entweder:
+      * ein Mapping fuer check_restriction()
+      * eine lfun-closure
+        Diese erhaelt beim Aufruf das betreffende Objekt als Argument und darf
+        eine 0 fuer 'erlaubt', 1 fuer 'nicht erlaubt (mit Standardtext)' oder
+        einen string fuer 'nicht erlaubt mit individuellem Text' sein.
+
+BEMERKUNGEN
+-----------
+::
+
+    Hat ein Objekt keine Syntaxhilfe, wird das Kommando "syntaxhilfe" aus dem
+    Objekt wieder entfernt (d.h. die Property muss gesetzt sein, bevor der
+    erste Spieler das Kommando eingibt).
+
+SIEHE AUCH
+----------
+::
+
+    AddCmd
+
diff --git a/doc/sphinx/props/P_TARGET_AREA.rst b/doc/sphinx/props/P_TARGET_AREA.rst
new file mode 100644
index 0000000..e6d3f44
--- /dev/null
+++ b/doc/sphinx/props/P_TARGET_AREA.rst
@@ -0,0 +1,95 @@
+P_TARGET_AREA
+=============
+
+NAME
+----
+::
+
+    P_TARGET_AREA     "target_area"
+
+DEFINIERT IN
+------------
+::
+
+    <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+    Kann in einem Raum gesetzt werden, um einen anderen, von dort aus mit
+    Fernkampfwaffen beschiessbaren Raum als Objekt oder Objektnamen (zu
+    einem geladenen Objekt) festzulegen.
+
+BEMERKUNGEN
+-----------
+::
+
+    Ein Schuetze kann nur in den anderen Raum schiessen, wenn die P_RANGE
+    seiner Waffe mindest gleich der P_SHOOTING_AREA des Raums (nicht des
+    Zielraums) ist.
+
+    Idealerweise sollte in mit P_TARGET_AREA angegebenen Raeumen auch
+    P_NEVER_CLEAN gesetzt sein.
+
+BEISPIELE
+---------
+::
+
+    // #1 Ein Baum-Raum (/std/room)
+    void create() {
+      ::create();
+      SetProp(P_INT_SHORT, "Auf einem Baum");
+      SetProp(P_INT_LONG, break_string("Du hockst auf einem Baum und kannst "
+        "auf die Lichtung unter Dir sehen.\n");
+
+      AddExit("unten", RAEUME("lichtung"));
+
+      SetProp(P_TARGET_AREA, RAEUME("lichtung"));  // Lichtung beschiessbar
+      SetProp(P_SHOOTING_AREA, 15);                // 15 Entfernung
+    }
+
+    // #2 Ein Elefanten-Transporter (/std/transport)
+    // Er trampelt durch mehrere Raeume durch und der Schuetze kann vom
+    // Ruecken des Elefanten aus auf Gegner draussen schiessen.
+    void create() {
+      ::create();
+      SetProp(P_NAME, "Kampfelefant");
+      AddId(({"elefant", "kampfelefant")});
+      SetProp(P_GENDER, MALE);
+      SetProp(P_SHORT, "Ein Kampfelefant");
+      SetProp(P_INT_SHORT, "Auf einem Kampfelefanten");
+      // P_LONG, P_INT_LONG
+
+      SetProp(P_ENTERCMDS, ({"kletter", "erkletter"}));
+      SetProp(P_LEAVECMDS, ({"verlass", "verlasse"}));
+
+      SetProp(P_ARRIVEMSG, ({"Der Elefant trampelt in einen Raum.\n",
+                             "Ein Kampfelefant trampelt herein.\n"}));
+      SetProp(P_DEPARTMSG, ({"Der Elefant trampelt weiter.\n",
+                             "Der Kampfelefant trampelt weiter.\n"}));
+
+      SetProp(P_SHOOTING_AREA, 8); // weiter als 8 sollte man schiessen
+
+      AddRoute(RAEUME("schlachtfeld"), 20+random(10), 6, "Schlachtfeld");
+      AddRoute(RAEUME("burgtor"), 20+random(10), 6, "Burgtor");
+      AddRoute(RAEUME("burghof"), 20+random(10), 6, "Burghof");
+      AddRoute(RAEUME("halle"), 20+random(10), 6, "Halle");
+      AddRoute(RAEUME("bresche"), 20+random(10), 6, "Bresche");
+      // ...
+
+      Start();
+    }
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
+    Methoden:  FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
+    Gebiet:    P_RANGE, P_SHOOTING_AREA
+    Raeume:    P_NEVER_CLEAN
+    Sonstiges: fernwaffen
+
+29.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/props/P_TEAM.rst b/doc/sphinx/props/P_TEAM.rst
new file mode 100644
index 0000000..0d8a798
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM.rst
@@ -0,0 +1,40 @@
+P_TEAM
+======
+
+NAME
+----
+::
+
+	P_TEAM                         "team"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Liefert das Teamobjekt, falls Spieler in einem Team ist, sonst 0.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD, P_TEAM_AUTOFOLLOW,
+                    P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
+                    P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_ASSOC_MEMBERS.rst b/doc/sphinx/props/P_TEAM_ASSOC_MEMBERS.rst
new file mode 100644
index 0000000..8093109
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_ASSOC_MEMBERS.rst
@@ -0,0 +1,49 @@
+P_TEAM_ASSOC_MEMBERS
+====================
+
+NAME
+----
+::
+
+	P_TEAM_ASSOC_MEMBERS           "team_assoc_members"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Array mit den zugeordneten NPCs des Spielers bzw. der Spieler,
+	dem dieser NPC zugeordnet ist.
+	Zugeordnete NPCs sind automatisch im Team des Spielers.
+
+BEMERKUNG
+---------
+::
+
+	Der Zugriff auf diese Property sollte ueber AssocMember()
+	bzw. DeAssocMember() erfolgen.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_TEAM_ATTACK_CMD, P_TEAM_AUTOFOLLOW,
+                    P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
+                    P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_ATTACK_CMD.rst b/doc/sphinx/props/P_TEAM_ATTACK_CMD.rst
new file mode 100644
index 0000000..67fb26d
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_ATTACK_CMD.rst
@@ -0,0 +1,40 @@
+P_TEAM_ATTACK_CMD
+=================
+
+NAME
+----
+::
+
+	P_TEAM_ATTACK_CMD              "team_attack_cmd"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Angriffsbefehl des Spielers, nicht setzbar.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_AUTOFOLLOW,
+                    P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
+                    P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_AUTOFOLLOW.rst b/doc/sphinx/props/P_TEAM_AUTOFOLLOW.rst
new file mode 100644
index 0000000..c972faa
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_AUTOFOLLOW.rst
@@ -0,0 +1,40 @@
+P_TEAM_AUTOFOLLOW
+=================
+
+NAME
+----
+::
+
+	P_TEAM_AUTOFOLLOW              "team_autofollow"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Folgewunsch des Spielers, nicht setzbar.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
+                    P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_COLORS.rst b/doc/sphinx/props/P_TEAM_COLORS.rst
new file mode 100644
index 0000000..99ca3a1
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_COLORS.rst
@@ -0,0 +1,41 @@
+P_TEAM_COLORS
+=============
+
+NAME
+----
+::
+
+	P_TEAM_COLORS                  "team_colors"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Grenzwerte fuer farbige Anzeige im Teaminfo.
+	Array mit 4 Werten: ({ lp_rot, lp_gelb, sp_rot, sp_gelb })
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
+                    P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_LEADER.rst b/doc/sphinx/props/P_TEAM_LEADER.rst
new file mode 100644
index 0000000..9ddae0e
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_LEADER.rst
@@ -0,0 +1,40 @@
+P_TEAM_LEADER
+=============
+
+NAME
+----
+::
+
+	P_TEAM_LEADER                  "team_leader"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Liefert das Teamobjekt, falls Spieler Anfuehrer eines Teams ist.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_NEWMEMBER,
+                    P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_NEWMEMBER.rst b/doc/sphinx/props/P_TEAM_NEWMEMBER.rst
new file mode 100644
index 0000000..6c9180c
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_NEWMEMBER.rst
@@ -0,0 +1,41 @@
+P_TEAM_NEWMEMBER
+================
+
+NAME
+----
+::
+
+	P_TEAM_NEWMEMBER               "potential_team_member"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Enthaelt das Objekt des Teamleaders, sobald ein Spieler um
+	Teamaufnahme gebeten hat, sonst 0.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_WANTED_ROW.rst b/doc/sphinx/props/P_TEAM_WANTED_ROW.rst
new file mode 100644
index 0000000..b590d86
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_WANTED_ROW.rst
@@ -0,0 +1,40 @@
+P_TEAM_WANTED_ROW
+=================
+
+NAME
+----
+::
+
+	P_TEAM_WANTED_ROW              "team_wanted_row"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Gewuenschte Reihe des Spielers (von 1 bis MAX_TEAMROWS)
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD, P_TEAM_AUTOFOLLOW,
+                    P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
+                    P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_WIMPY_ROW.rst b/doc/sphinx/props/P_TEAM_WIMPY_ROW.rst
new file mode 100644
index 0000000..9a3fe17
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_WIMPY_ROW.rst
@@ -0,0 +1,47 @@
+P_TEAM_WIMPY_ROW
+================
+
+NAME
+----
+::
+
+	P_TEAM_WIMPY_ROW               "team_wimpy_row"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Fluchtreihe des Spielers, von 1 bis MAX_TEAMROWS.
+
+BEMERKUNG
+---------
+::
+
+	Wenn die Fluchtreihe <=1 ist, ist die Flucht in eine hintere Reihe
+	deaktiviert.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD, P_TEAM_AUTOFOLLOW,
+                    P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
+                    P_TEAM_WANTED_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TELNET_RTTIME.rst b/doc/sphinx/props/P_TELNET_RTTIME.rst
new file mode 100644
index 0000000..4064df6
--- /dev/null
+++ b/doc/sphinx/props/P_TELNET_RTTIME.rst
@@ -0,0 +1,43 @@
+P_TELNET_RTTIME
+===============
+
+NAME
+----
+::
+
+    P_TELNET_RTTIME                                  "p_lib_telnet_rttime"
+
+DEFINIERT IN
+------------
+::
+
+    /secure/telnetneg.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Properties steht die letzte gemessene 'round-trip' Zeit
+    (in Mikrosekunden) einer 'Telnet timing mark' vom MUD zum Client und
+    zurueck.
+
+    Voraussetzung hierfuer ist allerdings, dass das Telnet des Spielers
+    Telnetnegotiations unterstuetzt und 'telnet keepalive' eingeschaltet
+    ist, ansonsten bleibt diese Property 0.
+    Die meisten Telnets/Clients antworten zumindest eine Ablehnung auf
+    die 'timing marks', so dass trotzdem eine Zeit bestimmt werden kann.
+
+    Die Prop kann nicht gesetzt werden bzw. es hat keinen Effekt.
+
+SIEHE AUCH
+----------
+::
+
+    P_TTY_COLS, P_TTY_ROWS, P_TTY_SHOW, P_TTY, P_TTY_TYPE
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    03.02.2013, Zesstra
+
diff --git a/doc/sphinx/props/P_TESTPLAYER.rst b/doc/sphinx/props/P_TESTPLAYER.rst
new file mode 100644
index 0000000..3cfd0d7
--- /dev/null
+++ b/doc/sphinx/props/P_TESTPLAYER.rst
@@ -0,0 +1,48 @@
+P_TESTPLAYER
+============
+
+NAME
+----
+::
+
+    P_TESTPLAYER                  "testplayer"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gesetzt, wenn der Spieler ein Testspieler ist. Enthaelt die UID des
+     Magiers, dem dieser Testie (momentan) gehoert.
+
+     
+
+     Bei Testspielern duerfen Skills geaendert werden, sie duerfen gezappt
+     werden und - ihre eigentliche Aufgabe - nicht angeschlossene Gebiete
+     testen.
+
+     AUSNAHMEN: Gildentesties duerfen nur sehr eingeschraenkt manipuliert
+                werden werden, da sie im ganzen Mud rumlaufen koennen,
+                Spielerkontakt haben und nach Abschluss der Tests ggf. sogar
+                die Testiemarkierung entfernt werden kann.
+
+                
+
+     Fuer Spielertesties, die von einem Spieler kontrolliert werden, gelten
+     teilweise besondere Regeln, s. 'spielertesties'.
+
+BEMERKUNGEN: 
+     P_TESTPLAYER kann nur per SetProp() gesetzt werden und das auch nur ein
+     Mal! Geloescht werden kann das Flag nur von EM+.
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+05.01.2010, Zesstra
+
diff --git a/doc/sphinx/props/P_TIMED_ATTR_MOD.rst b/doc/sphinx/props/P_TIMED_ATTR_MOD.rst
new file mode 100644
index 0000000..2afd305
--- /dev/null
+++ b/doc/sphinx/props/P_TIMED_ATTR_MOD.rst
@@ -0,0 +1,78 @@
+P_TIMED_ATTR_MOD
+================
+
+NAME
+----
+::
+
+    P_TIMED_ATTR_MOD         "timed_attr_mod"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Property werden Attribut-Modifikatoren gespeichert, die
+    nicht ueber laengere Zeit wirksam sein sollen.
+    Die Wirksamkeit der Modifikatoren kann an Zeit und Objekte
+    gebunden werden.
+
+    Intern werden die Modifikatoren in einer Datenstruktur der Form
+
+    ({
+       ({ Ablaufzeiten }),
+       ([ Key : Ablaufobjekt ]),
+       ([ Key : ([ Mapping mit den Modifikatoren ]);
+         Ablaufzeit ; Ablaufobjekt ; Nachrichtenempfaenger
+       ])
+    })
+
+    gespeichert mit:
+    * Ablaufzeiten:  Zeit in Sekunden seit 1. Jan 1970, 0.0:0 GMT
+    * Ablaufobjekte: Objekte, an deren Existenz die Attribut-
+                     veraenderungen gebunden sind
+    * Nachrichtenempfaenger:
+      Objekte/Klassen, welche ueber abgelaufene Attributveraenderung
+      durch den Aufruf von "NotifyTimedAttrModExpired" (mit key als
+      Argument) benachrichtigt werden.
+
+    Das Setzen der Werte erfolgt NUR ueber die Methoden SetTimedAttrModifier
+    und DeleteTimedAttrModifier.
+
+    Die Daten zu einem Key koennen ueber QueryTimedAttrModifier abgefragt
+    werden. Die Abfrage mittels QueryProp liefert eine Kopie der gueltigen
+    Datenstruktur, die per Query nicht (siehe Bemerkungen).
+
+    Die Bedingungen fuer die ueber P_TIMED_ATTR_MOD gesetzten
+    Attributveraenderungen werden im Heartbeat in der Funktion
+    attribute_hb ueberprueft. Eine verminderte Funktionalitaet im
+    Falle von Magiern ist somit kein Fehlerfall.
+
+BEMERKUNGEN
+-----------
+::
+
+    Keine echte Property. Die Methode _query_timed_attr_mod() in
+    /std/living/attributes.c stellt die Daten zusammen.
+
+    ACHTUNG: Bitte nur die bereitgestellten Methoden zur Manipulation
+             benutzen! Setzen als Property hat keinen Effekt.
+
+SIEHE AUCH
+----------
+::
+
+    QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+    SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+    SetTimedAttrModifier(), QueryTimedAttrModifier(),
+    DeleteTimedAttrModifier(),
+    P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
+    P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/props/P_TIMEZONE.rst b/doc/sphinx/props/P_TIMEZONE.rst
new file mode 100644
index 0000000..561f887
--- /dev/null
+++ b/doc/sphinx/props/P_TIMEZONE.rst
@@ -0,0 +1,23 @@
+P_TIMEZONE
+==========
+
+NAME
+----
+::
+
+    P_TIMEZONE                 "timezone"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Ein Integer-Wert, der bei der Uhrzeitmeldung und beim Befehl
+     "(uhr)zeit" beruecksichtig wird. Gibt die Anzahl der Stunden
+     Zeitabweichung von Berliner Zeit an.
+
diff --git a/doc/sphinx/props/P_TITLE.rst b/doc/sphinx/props/P_TITLE.rst
new file mode 100644
index 0000000..336d5f0
--- /dev/null
+++ b/doc/sphinx/props/P_TITLE.rst
@@ -0,0 +1,21 @@
+P_TITLE
+=======
+
+NAME
+----
+::
+
+    P_TITLE                       "title"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Titel des Spielers. Erscheint hinter dem Namen in Kurz/Langbeschreibung.
+
diff --git a/doc/sphinx/props/P_TOO_HEAVY_MSG.rst b/doc/sphinx/props/P_TOO_HEAVY_MSG.rst
new file mode 100644
index 0000000..e42fd64
--- /dev/null
+++ b/doc/sphinx/props/P_TOO_HEAVY_MSG.rst
@@ -0,0 +1,50 @@
+P_TOO_HEAVY_MSG
+===============
+
+NAME
+----
+::
+
+    P_TOO_HEAVY_MSG                      "too_heavy_msg"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn jemand
+     versucht, ein Objekt in einen Behaelter zu legen, fuer den dieses Objekt
+     zu schwer ist.
+     Die Property ist im Behaelter zu setzen.
+     Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
+     so wird die Standardmeldung ausgegeben.
+     ("<Objekt> passt in <Behaelter> nicht mehr rein.")
+     Der String in der Property wird noch durch replace_personal()
+     verarbeitet, das zu bewegende Objekt wird als erstes, der Behaelter als
+     zweites Objekt angegeben. Danach wird der String auf 78 Zeichen
+     umgebrochen.
+     Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
+     ganz.
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_TOO_HEAVY_MSG, "Wenn du @WEN1 noch in den Beutel stecken"
+			      " wuerdest, wuerde er reissen.");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG, P_NOINSERT_MSG,
+                 P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     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
+
diff --git a/doc/sphinx/props/P_TOO_MANY_MSG.rst b/doc/sphinx/props/P_TOO_MANY_MSG.rst
new file mode 100644
index 0000000..e224275
--- /dev/null
+++ b/doc/sphinx/props/P_TOO_MANY_MSG.rst
@@ -0,0 +1,50 @@
+P_TOO_MANY_MSG
+==============
+
+NAME
+----
+::
+
+    P_TOO_MANY_MSG                      "too_many_msg"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn jemand
+     versucht, ein Objekt in einen Behaelter zu legen, der schon die maximale
+     Anzahl an Objekten enthaelt.
+     Die Property ist im Behaelter zu setzen.
+     Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
+     so wird die Standardmeldung ausgegeben.
+     ("Dafuer ist nicht mehr genug Platz in <Behaelter>.")
+     Der String in der Property wird noch durch replace_personal()
+     verarbeitet, das zu bewegende Objekt wird als erstes, der Behaelter als
+     zweites Objekt angegeben. Danach wird der String auf 78 Zeichen
+     umgebrochen.
+     Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
+     ganz.
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_TOO_MANY_MSG, "Aber der Korb hat doch nur drei Faecher, die"
+			     " sind alle schon voll.");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NOINSERT_MSG,
+                 P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     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
+
diff --git a/doc/sphinx/props/P_TOTAL_AC.rst b/doc/sphinx/props/P_TOTAL_AC.rst
new file mode 100644
index 0000000..2b585d4
--- /dev/null
+++ b/doc/sphinx/props/P_TOTAL_AC.rst
@@ -0,0 +1,42 @@
+P_TOTAL_AC
+==========
+
+NAME
+----
+::
+
+    P_TOTAL_AC                    "total_ac"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Numerischer Wert der Abwehrstaerke des Wesens.
+     Dieser wird durch Aufaddieren der P_AC aller getragenen Ruestungen
+     bestimmt. Aus diesem Grund ist das Abfragen dieser Property ziemlich
+     teuer. Falls das Ergebnis mehrfach kurz hintereinander gebraucht wird,
+     sollte die Property auf jeden Fall nur einmal abgefragt und der Wert
+     gespeichert werden.
+
+BEMERKUNGEN
+-----------
+::
+
+    Auf diese Property sollte nicht mittels Query() oder Set() zugegriffen
+    werden, das Setzen von Query- oder Setmethoden bitte auf jeden Fall
+    unterlassen.
+
+SIEHE AUCH
+----------
+::
+
+    P_AC
+
+05.09.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_TOTAL_LIGHT.rst b/doc/sphinx/props/P_TOTAL_LIGHT.rst
new file mode 100644
index 0000000..a330cd2
--- /dev/null
+++ b/doc/sphinx/props/P_TOTAL_LIGHT.rst
@@ -0,0 +1,42 @@
+P_TOTAL_LIGHT
+=============
+
+NAME
+----
+::
+
+    P_TOTAL_LIGHT                 "total_light"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt das Lichtlevel an, das von einem Objekt ausgeht. Hierzu wird das
+    eigene Lichtlevel P_LIGHT mit dem gesamten Inhalt eines Containers
+    verrechnet.
+
+    Bitte _nur_ ueber QueryProp auf diese Property zugreifen,
+    da das Lichtlevel ggf. neu berechnet werden muss!
+
+    Ein direktes setzen dieser Property ist NICHT moeglich, hierzu bitte
+    P_LIGHT benutzen!
+
+BEMERKUNGEN
+-----------
+::
+
+    Das ist die VON einem Objekt ausgehende Lichtstaerke. Fuer das IN einem
+    Raum herrschende Licht bitte P_INT_LIGHT abfragen!
+
+SIEHE AUCH
+----------
+::
+
+    P_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
+
diff --git a/doc/sphinx/props/P_TOTAL_OBJECTS.rst b/doc/sphinx/props/P_TOTAL_OBJECTS.rst
new file mode 100644
index 0000000..bf0d169
--- /dev/null
+++ b/doc/sphinx/props/P_TOTAL_OBJECTS.rst
@@ -0,0 +1,32 @@
+P_TOTAL_OBJECTS
+===============
+
+NAME
+----
+::
+
+    P_TOTAL_OBJECTS                "total_objects"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der Objekte im Container. Diese Property kann man nur abfragen!
+     Es werden nur Objekte gezaehlt, deren Methode short() einen
+     Wert != 0 zurueckgibt. Insofern koennen Spielern beliebig
+     viele unsichtbare Objekte gegeben werden ohne sie zu behindern.
+
+SIEHE AUCH
+----------
+::
+
+     P_MAX_OBJECTS
+
+26.Jan 2005 Gloinson
+
diff --git a/doc/sphinx/props/P_TOTAL_WC.rst b/doc/sphinx/props/P_TOTAL_WC.rst
new file mode 100644
index 0000000..b5bb5d2
--- /dev/null
+++ b/doc/sphinx/props/P_TOTAL_WC.rst
@@ -0,0 +1,46 @@
+P_TOTAL_WC
+==========
+
+NAME
+----
+::
+
+	P_TOTAL_WC			"total_wc"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property wird der numerische Wert der Angriffsstaerke
+	eines Lebewesens registriert.
+  Hierzu werden die P_WC von P_WEAPON bzw. P_HANDS sowie die Kraft des
+  Lebewesens beruecksichtigt.
+	Nicht eingerechnet in die Angriffsstaerke sind natuerlich Extraspells und
+  -skills des Angreifers.
+  Braucht man den Wert mehrfach kurz hintereinander, sollte man die Prop aber
+  nur einmal abfragen und den Wert speichern (sofern sich in der Zwischenzeit
+  nichts an der Waffe, den Hands oder den Attributen des Lebenwesens aendert).
+
+BEMERKUNGEN
+-----------
+::
+
+  Auf diese Property sollte nicht mittels Query() oder Set() zugegriffen 
+  werden, das Setzen von Query- oder Setmethoden bitte auf jeden Fall 
+  unterlassen.
+
+SIEHE AUCH
+----------
+::
+
+	P_HANDS, P_WC, P_XP
+
+
+05.09.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_TOTAL_WEIGHT.rst b/doc/sphinx/props/P_TOTAL_WEIGHT.rst
new file mode 100644
index 0000000..abc0202
--- /dev/null
+++ b/doc/sphinx/props/P_TOTAL_WEIGHT.rst
@@ -0,0 +1,21 @@
+P_TOTAL_WEIGHT
+==============
+
+NAME
+----
+::
+
+    P_TOTAL_WEIGHT                "total_weight"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/restrictions.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gewicht incl. Inhalt in Gramm. P_WEIGHT_PERCENT wird beruecksichtigt.
+
diff --git a/doc/sphinx/props/P_TOUCH_DETAILS.rst b/doc/sphinx/props/P_TOUCH_DETAILS.rst
new file mode 100644
index 0000000..d813a1a
--- /dev/null
+++ b/doc/sphinx/props/P_TOUCH_DETAILS.rst
@@ -0,0 +1,43 @@
+P_TOUCH_DETAILS
+===============
+
+NAME
+----
+::
+
+    P_TOUCH_DETAILS            "touch_details"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property entspricht dem P_DETAILS fuer Standarddetails,
+    nur werden hierin Gerueche gespeichert:
+    Diese Property enthaelt ein Mapping, in der Details im Objekt
+    definiert werden und Beschreibungen, die ausgegeben werden, wenn man
+    sich diese Details anschaut.
+
+BEMERKUNGEN
+-----------
+::
+
+    Man sollte diese Property nicht per Hand veraendern, sondern die
+    Funktionen nutzen.
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddTouchDetail()
+    Loeschen:  RemoveTouchDetail()
+    Aehnlich:  AddDetail(), P_DETAILS
+    Sonstiges: GetDetail(), break_string()
+
+27. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_TPORT_COST_IN.rst b/doc/sphinx/props/P_TPORT_COST_IN.rst
new file mode 100644
index 0000000..c9f503d
--- /dev/null
+++ b/doc/sphinx/props/P_TPORT_COST_IN.rst
@@ -0,0 +1,22 @@
+P_TPORT_COST_IN
+===============
+
+NAME
+----
+::
+
+    P_TPORT_COST_IN               "tport_cost_in"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     In einem Raum mit Sehertor: Kostenanteil, um sich in den Raum zu
+     teleportieren
+
diff --git a/doc/sphinx/props/P_TPORT_COST_OUT.rst b/doc/sphinx/props/P_TPORT_COST_OUT.rst
new file mode 100644
index 0000000..fc65f12
--- /dev/null
+++ b/doc/sphinx/props/P_TPORT_COST_OUT.rst
@@ -0,0 +1,22 @@
+P_TPORT_COST_OUT
+================
+
+NAME
+----
+::
+
+    P_TPORT_COST_OUT              "tport_cost_out"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     In einem Raum mit Sehertor: Kostenanteil, sich aus dem Raum heraus
+     zu teleportieren
+
diff --git a/doc/sphinx/props/P_TRANK_FINDEN.rst b/doc/sphinx/props/P_TRANK_FINDEN.rst
new file mode 100644
index 0000000..dd856f0
--- /dev/null
+++ b/doc/sphinx/props/P_TRANK_FINDEN.rst
@@ -0,0 +1,22 @@
+P_TRANK_FINDEN
+==============
+
+NAME
+----
+::
+
+    P_TRANK_FINDEN                "trank_finden"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/potion.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn die Property auf 1 steht kann immer ein Zaubertrank gefunden
+     werden, auch wenn er nicht in der Liste des Spielers steht.
+
diff --git a/doc/sphinx/props/P_TRANSPARENT.rst b/doc/sphinx/props/P_TRANSPARENT.rst
new file mode 100644
index 0000000..dbe640d
--- /dev/null
+++ b/doc/sphinx/props/P_TRANSPARENT.rst
@@ -0,0 +1,47 @@
+P_TRANSPARENT
+=============
+
+NAME
+----
+::
+
+     P_TRANSPARENT                 "transparent"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/container.h
+
+BESCHREIBUNG
+------------
+::
+
+     ist != 0, wenn in einen Container hinein (offen) oder aus einem 
+     hinausgeschaut werden kann.
+
+     Schaut man aus einem hinaus, erhaelt der Spieler normalerweise die 
+     Meldung 'Ausserhalb siehst Du:'. Diese kann jedoch durch eine eigene, 
+     stimmigere  Meldung ersetzt werden, wenn in P_TRANSPARENT ein String 
+     mit dieser Meldung angegeben wird.
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_TRANSPARENT,1); -> normale Meldung
+
+     SetProp(P_TRANSPARENT,"Vom Ruecken des Pferdes aus siehst Du:\n");
+
+     Diese Meldung ist natuerlich nur dann sinnvoll, wenn es sich
+     auch tatsaechlich um ein Pferd handelt :-)
+
+SIEHE AUCH
+----------
+::
+
+     int_long()
+
+
+Last modified: Mon Jul 18 24:00:00 2001 by Tilly
+
diff --git a/doc/sphinx/props/P_TRAVEL_CMDS.rst b/doc/sphinx/props/P_TRAVEL_CMDS.rst
new file mode 100644
index 0000000..82b93fc
--- /dev/null
+++ b/doc/sphinx/props/P_TRAVEL_CMDS.rst
@@ -0,0 +1,64 @@
+P_TRAVEL_CMDS
+=============
+
+NAME
+----
+::
+
+    P_TRAVEL_CMDS                   "travel_cmds"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+    Ein Array mit Befehlen, die zum Verlassen UND Betreten des Trans-
+    porters fuehren. 
+
+BEISPIEL
+--------
+::
+
+    void create()
+    {
+      ::create();
+
+      SetProp(P_TRAVEL_CMDS,({ "steig","steige" }) );
+
+    }
+
+    Als Parameter werden hier ausschliesslich 'auf,in' und 'von,aus'
+    verarbeitet.
+
+    steige auf|in  <xxx>    fuehrt also zum Betreten des Transporters,
+    steige von|aus <xxx>    dagegen fuehrt zum Verlassen desselben.
+
+BEMERKUNGEN
+-----------
+::
+
+    Um /std/transport.c nicht aufzublaehen, werden weitere Parameter wie
+    etwa 'steige auf|in das|die|den xxx' _nicht_ unterstuetzt!
+
+    Hier muss der verantwortliche Magier schon eine eigene Loesung finden
+    und in seinen Transporter schreiben.
+
+SIEHE AUCH
+----------
+::
+
+    P_LEAVEFAIL, P_ENTERFAIL, P_ENTERCMDS, P_LEAVECMDS, transporter,
+
+LETZTER AENDERUNG
+-----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
+    
+
diff --git a/doc/sphinx/props/P_TRAVEL_INFO.rst b/doc/sphinx/props/P_TRAVEL_INFO.rst
new file mode 100644
index 0000000..f6dd566
--- /dev/null
+++ b/doc/sphinx/props/P_TRAVEL_INFO.rst
@@ -0,0 +1,53 @@
+P_TRAVEL_INFO
+=============
+
+NAME
+----
+::
+
+    P_TRAVEL_INFO                 "travel_info"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+    Array mit Informationen zur vom Spieler gewuenschten Reiseroute.
+
+    [0]        Der Raum (object), in dem die Reiseroute momentan 
+               'aktiv' ist. Nur hier wird sie beruecksichtigt.
+
+    [1]        Das gewuenschte Transportmittel (object) falls 
+               gewaehlt. Ansonsten 0.
+
+    [2]        Der gewuenschte Zielort (string) oder 0 (ziellos).
+
+    [3]        Der gewuenschte Zielort als Richtung (string), falls
+               gewaehlt (z.B. 'zur Feuerinsel'). Sonst 0. Wird aus
+               P_HARBOUR des Zielraumes ausgelesen.
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Property wird von /std/transport.c sowie std/player/travel.c
+    verwendet, und sollte NICHT von anderen Objekten oder per Hand 
+    veraendert werden!
+
+SIEHE AUCH
+----------
+::
+
+    /std/transport.c, /std/player/travel.c, reise
+
+LETZTER AENDERUNG
+-----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
diff --git a/doc/sphinx/props/P_TRAY.rst b/doc/sphinx/props/P_TRAY.rst
new file mode 100644
index 0000000..1fb912a
--- /dev/null
+++ b/doc/sphinx/props/P_TRAY.rst
@@ -0,0 +1,21 @@
+P_TRAY
+======
+
+NAME
+----
+::
+
+    P_TRAY                        "tray"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_TTY.rst b/doc/sphinx/props/P_TTY.rst
new file mode 100644
index 0000000..08199f2
--- /dev/null
+++ b/doc/sphinx/props/P_TTY.rst
@@ -0,0 +1,47 @@
+P_TTY
+=====
+
+NAME
+----
+::
+
+    P_TTY                         "tty"
+
+DEFINIERT IN
+------------
+::
+
+    /secure/telnetneg.h
+
+BESCHREIBUNG
+------------
+::
+
+     Name der Terminalemulation, die der Spieler nutzt.
+     Es existieren bisher "dumb", "vt100" und "ansi".
+
+	
+
+ANMERKUNG
+---------
+::
+
+     Farben duerfen ausschliesslich bei P_TTY=="ansi" benutzt werden.
+     Bei nicht farbfaehigen Terminals koennen ANSI-Codes die gesamte
+     Ausgabe zerschiessen!
+
+     Die Attribute fett, unterstrichen, blinkend und invers koennen auch
+     schon von vt100-Terminals dargestellt werden. Aber nicht ueberall
+     sind alle Attribute/Farben implementiert.
+
+     Bei allen ANSI-Codes sind drei Sachen zu beachten:
+
+     
+
+        1) Sparsam benutzen! Aufgezwungene Hervorhebungen koennen
+	   Spieler ganz schnell nerven.
+
+	2) Nicht jeder benutzt dieselbe Hintergrundfarbe!
+
+	3) Sparsam benutzen! Beser noch: nur im Notfall!
+
diff --git a/doc/sphinx/props/P_TTY_COLS.rst b/doc/sphinx/props/P_TTY_COLS.rst
new file mode 100644
index 0000000..e76ac71
--- /dev/null
+++ b/doc/sphinx/props/P_TTY_COLS.rst
@@ -0,0 +1,40 @@
+P_TTY_COLS
+==========
+
+NAME
+----
+::
+
+    P_TTY_COLS                                  "tty_cols"
+
+DEFINIERT IN
+------------
+::
+
+    /secure/telnetneg.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Properties steht die Anzahl der Spalten, die das 
+    Terminalfenster des Spielers derzeit hat.
+
+    Voraussetzung hierfuer ist allerdings, dass das Telnet des Spielers
+    Telnetnegotiations unterstuetzt, ansonsten bleibt diese Property
+    leer.
+    Das Setzen der Property aendert die Fenstergroesse des Spielers
+    natuerlich nicht.
+
+SIEHE AUCH
+----------
+::
+
+    P_TTY_ROWS, P_TTY_TYPE, P_TTY_SHOW
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    Sat, 06.02.1999, 14:00:00 von Paracelsus
+
diff --git a/doc/sphinx/props/P_TTY_ROWS.rst b/doc/sphinx/props/P_TTY_ROWS.rst
new file mode 100644
index 0000000..02759fd
--- /dev/null
+++ b/doc/sphinx/props/P_TTY_ROWS.rst
@@ -0,0 +1,40 @@
+P_TTY_ROWS
+==========
+
+NAME
+----
+::
+
+    P_TTY_ROWS                                  "tty_rows"
+
+DEFINIERT IN
+------------
+::
+
+    /secure/telnetneg.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Properties steht die Anzahl der Zeilen, die das
+    Terminalfenster des Spielers derzeit hat.
+
+    Voraussetzung hierfuer ist allerdings, dass das Telnet des Spielers
+    Telnetnegotiations unterstuetzt, ansonsten bleibt diese Property
+    leer.
+    Das Setzen der Property aendert die Fenstergroesse des Spielers
+    natuerlich nicht.
+
+SIEHE AUCH
+----------
+::
+
+    P_TTY_COLS, P_TTY_TYPE, P_TTY_SHOW
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    Sat, 06.02.1999, 14:00:00 von Paracelsus
+
diff --git a/doc/sphinx/props/P_TTY_SHOW.rst b/doc/sphinx/props/P_TTY_SHOW.rst
new file mode 100644
index 0000000..f9d31af
--- /dev/null
+++ b/doc/sphinx/props/P_TTY_SHOW.rst
@@ -0,0 +1,35 @@
+P_TTY_SHOW
+==========
+
+NAME
+----
+::
+
+    P_TTY_SHOW                                  "tty_show"
+
+DEFINIERT IN
+------------
+::
+
+    /secure/telnetneg.h
+
+BESCHREIBUNG
+------------
+::
+
+    Bei Telnets, die Telnetnegotiations unterstuetzen, wird eine Aenderung
+    der Fenstergroesse dem Spielerobjekt mitgeteilt. Steht in P_TTY_SHOW
+    ein Wert ungleich Null, wird dem Spieler diese Aenderung mitgeteilt.
+
+SIEHE AUCH
+----------
+::
+
+    P_TTY_ROWS, P_TTY_COLS, P_TTY_TYPE, telnegs
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    Sat, 06.02.1999, 14:00:00 von Paracelsus
+
diff --git a/doc/sphinx/props/P_TTY_TYPE.rst b/doc/sphinx/props/P_TTY_TYPE.rst
new file mode 100644
index 0000000..a33f937
--- /dev/null
+++ b/doc/sphinx/props/P_TTY_TYPE.rst
@@ -0,0 +1,41 @@
+P_TTY_TYPE
+==========
+
+NAME
+----
+::
+
+    P_TTY_TYPE                                  "tty_type"
+
+DEFINIERT IN
+------------
+::
+
+    /secure/telnetneg.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Properties steht der Terminaltyp, den ein Spieler lokal auf
+    seinem Rechner verwendet.
+
+    Voraussetzung hierfuer ist allerdings, dass das Telnet des Spielers
+    Telnetnegotiations unterstuetzt, ansonsten bleibt diese Property
+    leer. Die meisten Telnets/Clients geben ihren Terminaltyp allerdings
+    nicht preis.
+    Das Setzen der Property aendert den Terminaltyp des Spielers
+    natuerlich nicht.
+
+SIEHE AUCH
+----------
+::
+
+    P_TTY_COLS, P_TTY_ROWS, P_TTY_SHOW
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    Sat, 06.02.1999, 14:00:00 von Paracelsus
+
diff --git a/doc/sphinx/props/P_UNIT_DECAY_FLAGS.rst b/doc/sphinx/props/P_UNIT_DECAY_FLAGS.rst
new file mode 100644
index 0000000..10fe447
--- /dev/null
+++ b/doc/sphinx/props/P_UNIT_DECAY_FLAGS.rst
@@ -0,0 +1,92 @@
+P_UNIT_DECAY_FLAGS
+==================
+
+NAME
+----
+::
+
+     P_UNIT_DECAY_FLAGS					"unit_decay_flags"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/unit.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Prop kann das Zerfallsverhalten gesteuert werden, entweder
+     fuer alle Clones durch Setzen in der Blueprint oder fuer einzelne Clones.
+
+     In dieser Prop koennen momentan 4 Flags gesetzt werden:
+     - NO_DECAY: 
+          Zerfall ist abgeschaltet.
+     - NO_DECAY_UNTIL_MOVE: 
+          Der Zerfall ist solange ausgesetzt, bis dieses Objekt in ein anderes
+          Env bewegt wird. Setzt also ein NPC beim AddItem() diese Prop,
+          zerfaellt seine Unit nicht, bis sie bewegt wurde (Leiche, Spieler
+          etc.). Hierbei zaehlt das move() nicht, wenn das Objekt noch kein
+          Env hatte, es zaehlen nur Moves von einem Env in ein anderes Env.
+          Dieses Flag sollte nur in Clones gesetzt werden.
+     - INACCURATE_DECAY
+          Sollen z.b. 45.34 Einheiten zerfallen, wird der Rest von 0.34
+          normalerweise als Wahrscheinlichkeit aufgefasst, dass eine
+          zusaetzliche Einheit zerfaellt. Dieses Flag sorgt dafuer, dass
+          dieser Rest weggeworfen wird und einfach 45 Einheiten zerfallen.
+          Gleichzeitig wird bei diesem Flag aber _immer min_ 1 Einheit
+          zerstoert!
+     - ABSOLUTE_DECAY
+          P_UNIT_DECAY_QUOTA wird nicht als prozentualer Anteil aufgefasst,
+          sondern als absolute Zahl, d.h. es zerfallen immer einfach
+          P_UNIT_DECAY_QUOTA Einheiten.
+
+     Diese Flags koennen z.B. genutzt werden, den Zerfall fuer einzelne
+     Objekte temporaer oder dauerhaft abzuschalten, auch wenn alle anderen
+     Clones weiterzerfallen.
+
+     Diese Prop kann in der Blueprint gesetzt werden. In diesem Fall wird
+     allerdings NO_DECAY_UNTIL_MOVE ignoriert, weil die BP ja nie bewegt
+     wuerde. NO_DECAY in der BP schaltet den Zerfallsprozess (temporaer) fuer
+     alle Clones aus. Ist nie ein Zerfall gewuenscht, sollte in der Blueprint
+     aber besser P_UNIT_DECAY_INTERVAL auf 0 gesetzt werden!
+
+     Ist die Prop in einem einzelnen Clone nicht explizit gesetzt,
+     liefert ein klon->QueryProp(P_UNIT_DECAY_FLAGS) den in der Blueprint
+     eingestellten Wert zurueck.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     * Setzt man diese Prop in einem Clone auf 0, wird der Wert aus der
+       Blueprint zurueckgeben. Hierbei wird allerdings ein NO_DECAY_UNTIL_MOVE
+       ausgefiltert, da dies den Zerfall fuer alle Objekte dauerhaft stoppen
+       wuerde, weil BPs nicht bewegt werden.
+     * Die Flags koennen "verodert" werden:
+       SetProp(P_UNIT_DECAY_FLAGS, NO_DECAY_UNTIL_MOVE | ABSOLUTE_DECAY);
+
+BEISPIEL
+--------
+::
+
+     // Dieser NPC hat tolle Pfeile, die sollen aber nicht zerfallen, solange
+     // sie im Inventar des NPCs sind:
+     AddItem("/d/tolleregion/tollermagier/obj/pfeile", REFRESH_NONE,
+         ([ P_AMOUNT: 50+random(50),
+            P_UNIT_DECAY_FLAGS: NO_DECAY_UNTIL_MOVE ]) );
+
+SIEHE AUCH
+----------
+::
+
+     unit
+     P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_QUOTA, P_UNIT_DECAY_MIN
+     DoDecay, DoDecayMessage
+     /std/unit.c
+
+14.10.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_UNIT_DECAY_INTERVAL.rst b/doc/sphinx/props/P_UNIT_DECAY_INTERVAL.rst
new file mode 100644
index 0000000..c9b6d2a
--- /dev/null
+++ b/doc/sphinx/props/P_UNIT_DECAY_INTERVAL.rst
@@ -0,0 +1,56 @@
+P_UNIT_DECAY_INTERVAL
+=====================
+
+NAME
+----
+::
+
+     P_UNIT_DECAY_INTERVAL					"unit_decay_interval"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/unit.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Prop bestimmt, wie oft ein Zerfall der entsprechenden Unitobjekte
+     durchgefuehrt wird. Das Intervall ist in Sekunden anzugeben (int).
+     Die Prop muss in der Blueprint der entsprechenden Unitobjekte gesetzt
+     werden, in Clones kann sie nicht gesetzt werden.
+     Die Blueprint resettet dann in diesem Intervall und ruft in allen ihren
+     Clones (und denen alter Versionen der gleichen BP!) DoDecay() auf,
+     woraufhin die Clones den Zerfall durchfuehren.
+     Ist die Prop in der Blueprint nicht gesetzt, erfolgt kein Zerfall.
+
+BEMERKUNGEN
+-----------
+::
+
+     * Ist die Blueprint nicht geladen, erfolgt kein Zerfall der Clones.
+     * Ein Setzen dieser Prop beinhaltet immer auch einen Aufruf von
+       set_next_reset() auf das ensprechende Intervall.
+     * Die Prop kann in den Clones abgefragt werden und liefert das in der
+       Blueprint eingestellte Intervall.
+     * Von einer Manipulation per Set() wird dringend abgeraten.
+     * Die Prop kann nur vom Objekt selber, vom Programmierer des Objekts, vom
+       RM der entsprechenden Region, von einem Weisen oder von einem Objekt
+       gesetzt werden, welches die gleiche UID hat.
+
+BEISPIEL
+--------
+::
+
+SIEHE AUCH
+----------
+::
+
+     unit
+     P_UNIT_DECAY_QUOTA, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_MIN
+     DoDecay(), DoDecayMessage()
+
+13.10.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_UNIT_DECAY_MIN.rst b/doc/sphinx/props/P_UNIT_DECAY_MIN.rst
new file mode 100644
index 0000000..8c97b4e
--- /dev/null
+++ b/doc/sphinx/props/P_UNIT_DECAY_MIN.rst
@@ -0,0 +1,71 @@
+P_UNIT_DECAY_MIN
+================
+
+NAME
+----
+::
+
+     P_UNIT_DECAY_MIN					                    "unit_decay_min"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/unit.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Prop bestimmt, wieviele Einheiten der Unitobjekten mindestens
+     uebrig bleiben sollen. 
+     Faellt die Menge eines Unitobjekts unter diesen Wert, zerfaellt diese
+     Unit solange nicht weiter, bis der Wert wieder ueberschritten wird.
+     Die Prop kann in der Blueprint und in den einzelnen Clones gesetzt
+     werden.
+     Ist die Prop in einem einzelnen Clone nicht explizit gesetzt,
+     liefert ein QueryProp(P_UNIT_DECAY_MIN) den in der Blueprint
+     eingestellten Wert zurueck und die Unit zerfaellt bis zu dieser
+     Mindestmenge..
+     D.h. man sollte diese Prop in der Blueprint setzen und in einzelnen
+     Clones nur soweit diese abweichende Werte haben sollen.
+     Es sind nur Werte zwischen 0 und 100 zulaessig. Auf diese Art laesst sich
+     die minidestens uebrig bleibende Menge aller Clones durch Aendern einer
+     Prop in der Blueprint aendern.
+
+BEMERKUNGEN
+-----------
+::
+
+     * Setzt man diese Prop in einem Clone auf 0, wird der Wert aus er
+       Blueprint zum Zerfall benutzt.
+     * Will man fuer ein bestimmtes Unitobjekt kein Minimum haben, also dass
+       dieses Objekt zerfaellt, bis nichts mehr da ist, die Blueprint hat aber
+       einen Minimalwert gesetzt, sollte diese Prop im betreffenden Objekt auf
+       -1 gesetzt werden.
+     * Diese Prop sollte vorsichtig angewandt werden, da Spieler so den
+       Zerfall von Units stoppen koennen, indem sie die Units entsprechend
+       aufteilen, so dass jedes Einzelobjekt unter dem Minimum liegt.
+
+BEISPIEL
+--------
+::
+
+     // es soll min. 1 Einheit uebrig bleiben.
+     SetProp(P_UNIT_DECAY_MIN, 1);
+
+     // die Blueprint hat ein Minimum von 10 gesetzt, dieser Clone soll
+     // aber zerfallen, bis nix mehr da ist.
+     klon->SetProp(P_UNIT_DECAY_MIN, -1);
+
+SIEHE AUCH
+----------
+::
+
+     unit
+     P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_QUOTA
+     DoDecay, DoDecayMessage
+     /std/unit.c
+
+14.10.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_UNIT_DECAY_QUOTA.rst b/doc/sphinx/props/P_UNIT_DECAY_QUOTA.rst
new file mode 100644
index 0000000..e219c5f
--- /dev/null
+++ b/doc/sphinx/props/P_UNIT_DECAY_QUOTA.rst
@@ -0,0 +1,69 @@
+P_UNIT_DECAY_QUOTA
+==================
+
+P_UNIT_DECAY_QUOTA (int)
+------------------------
+::
+
+NAME
+----
+::
+
+     P_UNIT_DECAY_QUOTA					"unit_decay_quota"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/unit.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Prop bestimmt, welcher Anteil der einzelnen Unitobjekte pro Zerfall
+     zerstoert wird. Dieser Anteil wird als ganze Zahl zwischen 0 und 10000
+     ausgedrueckt. 1 entspricht einem Zerfall von 0.01%, 10000 entspricht
+     100%.
+     Momentan sind keine Werte < 0 zulaessig, die einem Zuwachs entsprechend
+     wurden.
+
+     Falls das Flag ABSOLUTE_DECAY (s. P_UNIT_DECAY_FLAGS) gesetzt ist, steht
+     die Zahl in dieser Prop fuer die absolute Anzahl an zu zerstoerenden
+     Einheiten.
+
+     Die Prop kann in der Blueprint und in den einzelnen Clones gesetzt
+     werden.
+     Ist die Prop in einem einzelnen Clone nicht explizit gesetzt,
+     liefert ein QueryProp(P_UNIT_DECAY_QUOTA) den in der Blueprint
+     eingestellten Wert zurueck und die Unit zerfaellt zu diesem Anteil.
+     D.h. man sollte diese Prop in der Blueprint setzen und in einzelnen
+     Clones nur soweit diese abweichende Zerfallsraten haben sollen.
+
+BEMERKUNGEN
+-----------
+::
+
+     * Setzt man diese Prop in einem Clone auf 0, wird der Wert aus er
+       Blueprint zum Zerfall benutzt.
+     * Will man den Zerfall fuer ein bestimmtes Unitobjekt abschalten, sollte
+       man P_UNIT_DECAY_FLAGS benutzen.
+
+BEISPIEL
+--------
+::
+
+     // pro Zerfallsintervall sollen 12% zerfallen.
+     SetProp(P_UNIT_DECAY_QUOTA, 1200);
+
+SIEHE AUCH
+----------
+::
+
+     unit
+     P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_MIN
+     DoDecay, DoDecayMessage
+     /std/unit.c
+
+14.03.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_UNWEAR_MSG.rst b/doc/sphinx/props/P_UNWEAR_MSG.rst
new file mode 100644
index 0000000..65b3c43
--- /dev/null
+++ b/doc/sphinx/props/P_UNWEAR_MSG.rst
@@ -0,0 +1,78 @@
+P_UNWEAR_MSG
+============
+
+NAME
+----
+::
+
+     P_UNWEAR_MSG                       "unwear_msg"     
+
+DEFINIERT IN
+------------
+::
+
+     /sys/armour.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zweiteiliges Array mit Meldungen, die beim Ausziehen einer Ruestung 
+     oder Kleidung an den Spieler und die Umgebung ausgegeben werden.
+     Der erste Eintrag geht an den Spieler, der zweite Eintrag an die
+     Umgebung. Zeilenumbrueche werden automatisch gemacht, existierende
+     jedoch beruecksichtigt.
+
+     Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
+     man replace_personal()).
+
+     [Wegen Abwaertskompatibilitaet ist auch noch der Platzhalter %s
+      moeglich, wobei in der eigenen Meldung %s fuer den Waffennamen steht,
+      in der an den Raum das erste %s fuer den Spielernamen, das zweite fuer
+      den Waffennamen.]
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_NAME, "Mantel");
+    SetProp(P_UNWEAR_MSG,
+     ({"Du reisst Dir @WEN2 vom Leib.",
+       "@WER1 reisst sich @WENU2 vom Leib." }));
+
+    -> beim Ausziehen durch Urk:
+       Urk bekommt: Du reisst dir den Mantel vom Leib.
+       Der Raum:    Urk reisst sich einen Mantel vom Leib.
+
+    SetProp(P_UNWEAR_MSG,
+     ({"Dir wird furchtbar warm. So eine Hitze aber auch. Schnell "
+       "schluepfst Du aus Deiner dicken Ruestung. Aaaah, was fuer "
+       "eine Wohltat.",
+       "@WEM1 scheint ploetzlich warm zu werden. Schnell schluepft "
+       "@WERQP1 aus @WEMQPPFS1 dicken Ruestung. Du hoffst instaendig, "
+       "das es noch etwas waermer wird ... "}));
+
+    -> beim Ausziehen durch Urk:
+       Urk bekommt: Dir wird furchtbar warm. So eine Hitze aber auch.
+		    Schnell schluepfst Du aus Deiner dicken Ruestung.
+		    Aaaah, was fuer eine Wohltat.
+       Der Raum:    Urk scheint ploetzlich warm zu werden. Schnell
+		    schluepft er aus seiner dicken Ruestung. Du hoffst
+		    instaendig, das es noch etwas waermer wird ...
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_WEAR_MSG, P_WIELD_MSG, P_UNWIELD_MSG
+                 P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_PICK_MSG
+     Funktionen: WearFunc, UnwearFunc
+     Sonstiges:  replace_personal(E), /std/armour/wear.c, armours
+                 clothing, /std/clothing.wear.c
+
+LETZTE AeNDERUNG
+----------------
+::
+
+15.02.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_UNWIELD_FUNC.rst b/doc/sphinx/props/P_UNWIELD_FUNC.rst
new file mode 100644
index 0000000..f1666fd
--- /dev/null
+++ b/doc/sphinx/props/P_UNWIELD_FUNC.rst
@@ -0,0 +1,33 @@
+P_UNWIELD_FUNC
+==============
+
+NAME
+----
+::
+
+     P_UNWIELD_FUNC "unwield_func"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Falls ein Objekt eine UnwieldFunc() fuer die Waffe definiert, so muss
+     dieses Objekt in dieser Property eingetragen werden.
+
+     Die Auswertung dieser Property erfolgt in DoUnwield().
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon.c, UnwieldFunc()
+
+
+Last modified: Sun May 19 15:44:08 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_UNWIELD_MSG.rst b/doc/sphinx/props/P_UNWIELD_MSG.rst
new file mode 100644
index 0000000..665de9b
--- /dev/null
+++ b/doc/sphinx/props/P_UNWIELD_MSG.rst
@@ -0,0 +1,77 @@
+P_UNWIELD_MSG
+=============
+
+NAME
+----
+::
+
+     P_UNWIELD_MSG                       "unwield_msg"                       
+
+DEFINIERT IN
+------------
+::
+
+     /sys/weapon.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zweiteiliges Array mit Meldungen, die beim Wegstecken einer 
+     Waffe an den Spieler und die Umgebung ausgegeben werden.
+
+     Der erste Eintrag geht an den Spieler, der zweite Eintrag an die
+     Umgebung.  Zeilenumbrueche werden automatisch gemacht, existierende
+     jedoch beruecksichtigt.
+
+     Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
+     man replace_personal()).
+
+     [Wegen Abwaertskompatibilitaet ist auch noch der Platzhalter %s
+      moeglich, wobei in der eigenen Meldung %s fuer den Waffennamen steht,
+      in der an den Raum das erste %s fuer den Spielernamen, das zweite fuer
+      den Waffennamen.]
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_NAME, "Streitkolben");
+    SetProp(P_UNWIELD_MSG,
+     ({ "Du steckst @WEN2 zurueck und atmest erstmal tief durch.", 
+        "@WER1 steckt @WENU2 zurueck und atmet erstmal tief durch." }));
+
+    -> beim Wegstecken durch Urk:
+       Urk bekommt: Du steckst den Streitkolben zurueck und atmest erstmal
+		    tief durch.
+       Der Raum:    Urk steckt einen Streitkolben zurueck und atmet erstmal
+		    tief durch.
+
+    SetProp(P_UNWIELD_MSG,
+     ({"Du steckst die schwere Keule zurueck. Zufaellig landet sie "
+       "dabei auf Deinem Fuss. Laut schreiend humpelst Du in der "
+       "Gegend herum.",
+       "@WER1 steckt eine schwere Keule zurueck. Dummerweise landet diese "
+       "direkt auf dem eigenen Fuss. Aua, das tat sicher weh ... nicht "
+       "umsonst humpelt @WERQP1 jetzt schreiend durch die Gegend."}));
+
+    -> beim Wegstecken durch Urk:
+       Urk bekommt: Du steckst die schwere Keule zurueck. Zufaellig landet
+		    sie dabei auf Deinem Fuss. Laut schreiend humpelst Du in
+		    der Gegend herum.
+       Der Raum:    Urk steckt eine schwere Keule zurueck. Dummerweise
+		    landet diese direkt auf dem eigenen Fuss. Aua, das tat
+                    sicher weh ... nicht umsonst humpelt er jetzt schreiend
+                    durch die Gegend.
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_WIELD_MSG, P_WEAR_MSG, P_UNWEAR_MSG
+                 P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_PICK_MSG
+     Funktionen: UnwieldFunc, WieldFunc
+     Sonstiges:  replace_personal(E), /std/weapon/combat.c
+
+29. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_UNWIELD_TIME.rst b/doc/sphinx/props/P_UNWIELD_TIME.rst
new file mode 100644
index 0000000..b4958e8
--- /dev/null
+++ b/doc/sphinx/props/P_UNWIELD_TIME.rst
@@ -0,0 +1,33 @@
+P_UNWIELD_TIME
+==============
+
+NAME
+----
+::
+
+      P_UNWIELD_TIME			"unwield_time"
+
+DEFINIERT IN
+------------
+::
+
+      /sys/weapon.h
+
+BESCHREIBUNG
+------------
+::
+
+      Enthaelt den Zeitpunkt zu dem ein Living eine Waffe weggesteckt hat und
+      ist im Living gesetzt.
+
+SIEHE AUCH
+----------
+::
+
+      Verwandt:		P_WEAPON, P_WIELDED, DoUnwield()
+			P_LAST_USE
+      Sonstiges:	P_EQUIP_TIME
+			time()
+
+10.Feb 2005 Gloinson
+
diff --git a/doc/sphinx/props/P_USED_HANDS.rst b/doc/sphinx/props/P_USED_HANDS.rst
new file mode 100644
index 0000000..32542fb
--- /dev/null
+++ b/doc/sphinx/props/P_USED_HANDS.rst
@@ -0,0 +1,39 @@
+P_USED_HANDS
+============
+
+NAME
+----
+::
+
+    P_USED_HANDS                  "used_hands"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    Anzahl der Haende in Benutzung.
+    Effektiv nur ein sizeof(P_HANDS_USED_BY).
+
+BEMERKUNGEN
+-----------
+::
+
+    Keine echte Property. Die Methode /std/living/combat::_query_used_hands
+    stellt die Daten zusammen. Nicht setzen!
+
+SIEHE AUCH
+----------
+::
+
+    P_HANDS, P_HANDS_USED_BY
+    P_MAX_HANDS, P_FREE_HANDS
+    UseHands, FreeHands
+
+1. Okt 2012, Gloinson
+
diff --git a/doc/sphinx/props/P_VALID_GUILDS.rst b/doc/sphinx/props/P_VALID_GUILDS.rst
new file mode 100644
index 0000000..6343081
--- /dev/null
+++ b/doc/sphinx/props/P_VALID_GUILDS.rst
@@ -0,0 +1,42 @@
+P_VALID_GUILDS
+==============
+
+NAME
+----
+::
+
+	P_VALID_GUILDS			"valid_guilds"                
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt die zugelassenen Gilden in Form von
+	kleingeschriebenen Gildennamen, welche in einem Array
+	zusammengefasst sind. Sie ist nur fuer den Gildenmaster selbst von
+	Bedeutung.
+
+BEISPIELE
+---------
+::
+
+	Abfrage der zugelassenen Gilden:
+	  find_object("/obj/gildenmaster")->QueryProp(P_VALID_GUILDS)
+	Das ergibt zum Beispiel:
+          ({"abenteurer","zauberer","klerus","kaempfer"})
+
+SIEHE AUCH
+----------
+::
+
+	P_GUILD, /obj/gildenmaster.c
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_VALUE.rst b/doc/sphinx/props/P_VALUE.rst
new file mode 100644
index 0000000..5843615
--- /dev/null
+++ b/doc/sphinx/props/P_VALUE.rst
@@ -0,0 +1,48 @@
+P_VALUE
+=======
+
+NAME
+----
+::
+
+    P_VALUE                       "value"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     - Objekte
+       Wert des Objektes in Goldmuenzen. Diesen Wert erhaelt man beim
+       Verkauf. Kaufen kostet ein Vielfaches hiervon.
+
+     - Speisen/Kneipen
+       Wert einer Portion der Speise.
+
+       
+
+BEMERKUNGEN
+-----------
+::
+
+     In tragbaren Speisen (erben von /std/food) setzt man mit SetProp
+     den Wert _einer_ Portion. Per QueryProp erhaelt man aber den Gesamt-
+     wert der Speise inclusive des eventuell vorhandenen Behaelters. Der
+     Wert des Behaelters wird dabei aus P_EMPTY_PROPS[P_VALUE] gelesen.
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     Speisen: std/pub, wiz/food, P_EMPTY_PROPS
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_VALUE_PER_UNIT.rst b/doc/sphinx/props/P_VALUE_PER_UNIT.rst
new file mode 100644
index 0000000..125108e
--- /dev/null
+++ b/doc/sphinx/props/P_VALUE_PER_UNIT.rst
@@ -0,0 +1,29 @@
+P_VALUE_PER_UNIT
+================
+
+NAME
+----
+::
+
+    P_VALUE_PER_UNIT              "value_per_unit"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wert in Goldstuecken pro Untereinheit.
+
+BEMERKUNGEN
+-----------
+::
+
+     Deprecated. Bitte SetCoinsPerUnits() (U_CPU) benutzen.
+
+25.Aug 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_VARIABLES.rst b/doc/sphinx/props/P_VARIABLES.rst
new file mode 100644
index 0000000..97147d4
--- /dev/null
+++ b/doc/sphinx/props/P_VARIABLES.rst
@@ -0,0 +1,31 @@
+P_VARIABLES
+===========
+
+NAME
+----
+::
+
+    P_VARIABLES "variables"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/magier.h
+
+BESCHREIBUNG
+------------
+::
+
+	
+
+     Interne Variable der Magiershell in dem die mit dem 'Set'-Befehl
+     gesetzten Variablen gespeichert werden.
+
+     
+
+     NICHT VON HAND VERAENDERN! IMMER 'SET' VERWENDEN!
+
+
+Letzte Aenderung: 13.02.2003 22:00:00 von Mandragon
+
diff --git a/doc/sphinx/props/P_VISIBLE_GUILD.rst b/doc/sphinx/props/P_VISIBLE_GUILD.rst
new file mode 100644
index 0000000..1f579fb
--- /dev/null
+++ b/doc/sphinx/props/P_VISIBLE_GUILD.rst
@@ -0,0 +1,43 @@
+P_VISIBLE_GUILD
+===============
+
+NAME
+----
+::
+
+     P_VISIBLE_GUILD			"visible_guild"                       
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt die sichtbare Gilde des Lebewesens in Form eines
+     kleingeschriebenen Strings, also die Gilde, die bei Spielern zum
+     Beispiel bei 'kwer' oder 'finger' angezeigt wird. So kann man fremde
+     Gilden testen und trotzdem nach aussen hin in der gleichen Gilde wie
+     zuvor bleiben.
+
+BEISPIEL
+--------
+::
+
+     Wenn man gerne nach aussen hin Zauberer bleiben moechte:
+	  pl->SetProp(P_VISIBLE_GUILD,"zauberer");
+     Nach aussen hin bleibt man jetzt auch Zauberer, wenn P_GUILD eine
+     andere Gilde angibt.
+
+SIEHE AUCH
+----------
+::
+
+     P_GUILD, P_DEFAULT_GUILD
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_VISIBLE_SUBGUILD_TITLE.rst b/doc/sphinx/props/P_VISIBLE_SUBGUILD_TITLE.rst
new file mode 100644
index 0000000..499f5cd
--- /dev/null
+++ b/doc/sphinx/props/P_VISIBLE_SUBGUILD_TITLE.rst
@@ -0,0 +1,40 @@
+P_VISIBLE_SUBGUILD_TITLE
+========================
+
+NAME
+----
+::
+
+     P_VISIBLE_SUBGUILD_TITLE		"visible_subguild_title"                       
+
+DEFINIERT IN
+------------
+::
+
+     /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property dient dazu, als Magier einen Zusatztitel innerhalb einer
+     Gilde vorzutaeuschen, ohne den tatsaechlichen P_SUBGUILD_TITLE zu
+     aendern.
+
+BEMERKUNGEN
+-----------
+::
+
+     Inhalt der Property kann 0 sein oder ein String.
+     Wenn der Inhalt 0 ist, wird bei QueryProp der P_SUBGUILD_TITLE
+     durchgereicht.
+
+SIEHE AUCH
+----------
+::
+
+     P_GUILD_TITLE, P_SUBGUILD_TITLE
+
+
+Last modified: Mon Aug 13 21:20:00 2001 by Nachtwind
+
diff --git a/doc/sphinx/props/P_VISUALBELL.rst b/doc/sphinx/props/P_VISUALBELL.rst
new file mode 100644
index 0000000..de55bde
--- /dev/null
+++ b/doc/sphinx/props/P_VISUALBELL.rst
@@ -0,0 +1,59 @@
+P_VISUALBELL
+============
+
+NAME
+----
+::
+
+	P_VISUALBELL			"visualbell"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+	Die Property stellt ein Flag innerhalb von Spielern dar, welches
+	standardmaessig nicht gesetzt ist. In diesem Fall werden Toene,
+	welche innerhalb einiger Funktionen erzeugt werden, auch wirklich an
+	den Spieler geschickt.
+	Setzt man die Property, so erhaelt der Spieler keine Toene mehr.
+
+BEISPIEL
+--------
+::
+
+	Pieptoene werden durch den ASCII-Code 0x7 praesentiert. Ausgeben
+	kann man diesen folgendermassen:
+	  if(!IS_WIZARD(caster)&&!victim->QueryProp(P_VISUALBELL))
+	    tell_object(victim,sprintf("%c",7));
+	Das waere beispielsweise ein Codestueck aus einem Piepspell. :)
+	Das Opfer bekommt den Piepton hierbei nur ab, wenn der Caster ein
+	Magier ist oder das Spieleropfer die Property P_VISUALBELL gesetzt
+	hat (kann mit Kommando 'ton' vom Spieler beeinflusst werden).
+
+BEMERKUNGEN
+-----------
+::
+
+  Achtung: P_VISUALBELL steht auf 1, wenn der Spieler _keine_ Piepstoene
+	hoeren will!
+	Die Funktionalitaet dieser Property wirkt nur soweit, wie sie auch
+	von tonerzeugenden Befehlen selbst unterstuetzt wird. Es ist darauf
+	zu achten, dass P_VISUALBELL zu diesem Zweck grundsaetzlich
+	ausgewertet wird! Eine Ausnahme sei hierbei zugelassen: Magier
+	koennen Spielern grundsaetzlich Toene zusenden.
+
+SIEHE AUCH
+----------
+::
+
+	ton, wecke, erwarte, P_WAITFOR, /std/player/base.c
+
+
+Last modified: 07.02.2007 by Zesstra
+
diff --git a/doc/sphinx/props/P_VULNERABILITY.rst b/doc/sphinx/props/P_VULNERABILITY.rst
new file mode 100644
index 0000000..9ae5447
--- /dev/null
+++ b/doc/sphinx/props/P_VULNERABILITY.rst
@@ -0,0 +1,62 @@
+P_VULNERABILITY
+===============
+
+NAME
+----
+::
+
+     P_VULNERABILITY               "vulnerability"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+WICHTIG
+-------
+::
+
+     DIESE PROPERTY IST VERALTET! BITTE P_RESISTANCE_STRENGTHS
+     VERWENDEN! AUCH FUNKTIONIERT Set() NICHT WIE ES SOLLTE.
+
+BESCHREIBUNG
+------------
+::
+
+     Hiermit koennen die Empfindlichkeiten eines Lebewesens definiert
+     werden. Es kann ein Array mit Schadensarten gesetzt werden, jeder
+     Eintrag eines Schadens verdoppelt die Empfindlichkeit gegen
+     diesen.
+
+BEMERKUNGEN
+-----------
+::
+
+     - P_RESISTANCE_STRENGTHS spiegelt die Eintraege hier wieder
+     - um genauere Werte anzugeben einen AddResistanceModifier() oder
+       P_RESISTANCE_STRENGTHS benutzen.
+     - P_VULNERABILITY kann und wird nicht aus P_RESISTANCE_STRENGTHS
+       upgedatet
+
+BEISPIELE
+---------
+::
+
+     // ein NPC mit verdoppelter Eisempfindlichkeit und
+     // vervierfachter Wasserempfindlichkeit
+     SetProp(P_VULNERABILITY, ({DT_COLD, DT_WATER, DT_WATER}));
+
+SIEHE AUCH
+----------
+::
+
+     simple Resistenz:	P_RESISTANCE
+     Hauptmapping:	P_RESISTANCE_STRENGTHS
+     Modifikatoren:	AddResistanceModifier, RemoveResistanceModifier(),
+			P_RESISTANCE_MODIFIER
+     Berechnung:	CheckResistance(), UpdateResistanceStrengths()
+     anderes:		balance, /std/armour/combat.c, /std/living/combat.c
+
+1.Dez 2004, Gloinson
+
diff --git a/doc/sphinx/props/P_WAITFOR.rst b/doc/sphinx/props/P_WAITFOR.rst
new file mode 100644
index 0000000..ce863fc
--- /dev/null
+++ b/doc/sphinx/props/P_WAITFOR.rst
@@ -0,0 +1,30 @@
+P_WAITFOR
+=========
+
+NAME
+----
+::
+
+     P_WAITFOR                     "waitfor"                     
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Die Erwarte-Liste. Ein Array mit den Namen der Erwarteten.
+
+SIEHE AUCH
+----------
+::
+
+     erwarte
+     P_WAITFOR_REASON, P_WAITFOR_FLAGS
+
+16. Feb 2008 Gloinson
+
diff --git a/doc/sphinx/props/P_WAITFOR_FLAGS.rst b/doc/sphinx/props/P_WAITFOR_FLAGS.rst
new file mode 100644
index 0000000..218c5b2
--- /dev/null
+++ b/doc/sphinx/props/P_WAITFOR_FLAGS.rst
@@ -0,0 +1,34 @@
+P_WAITFOR_FLAGS
+===============
+
+NAME
+----
+::
+
+     P_WAITFOR_FLAGS                  "waitfor_flags"                     
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Ein Int. Bisher bekannte Flags:
+
+     
+
+     0x01 - "erwarte aus"
+
+SIEHE AUCH
+----------
+::
+
+     erwarte
+     P_WAITFOR, P_WAITFOR_REASON
+
+16. Feb 2008 Gloinson
+
diff --git a/doc/sphinx/props/P_WAITFOR_REASON.rst b/doc/sphinx/props/P_WAITFOR_REASON.rst
new file mode 100644
index 0000000..f812d27
--- /dev/null
+++ b/doc/sphinx/props/P_WAITFOR_REASON.rst
@@ -0,0 +1,35 @@
+P_WAITFOR_REASON
+================
+
+NAME
+----
+::
+
+     P_WAITFOR_REASON                  "waitfor_reason"                     
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Ein Mapping mit den Erwarteten als Schluessel und einem Grund als
+     Key, zB:
+
+     
+
+     (["Zook":"muh muh"])
+
+SIEHE AUCH
+----------
+::
+
+     erwarte (erwarte <wen> wegen <was>)
+     P_WAITFOR, P_WAITFOR_FLAGS
+
+16. Feb 2008 Gloinson
+
diff --git a/doc/sphinx/props/P_WANTS_TO_LEARN.rst b/doc/sphinx/props/P_WANTS_TO_LEARN.rst
new file mode 100644
index 0000000..99ebbf9
--- /dev/null
+++ b/doc/sphinx/props/P_WANTS_TO_LEARN.rst
@@ -0,0 +1,25 @@
+P_WANTS_TO_LEARN
+================
+
+NAME
+----
+::
+
+    P_WANTS_TO_LEARN              "wants_to_learn"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gesetzt, wenn der Magier die Filenamen sehen will.
+     (Nur fuer Magier). Wird diese Property auf 0 gesetzt, gehen auch
+     einige andere Dinge nicht mehr - verfolge zB. Eigentlich sollten
+     dann auch die Magierbefehle wie "goto" usw unterbunden werden -
+     das kommt vielleicht noch.
+
diff --git a/doc/sphinx/props/P_WATER.rst b/doc/sphinx/props/P_WATER.rst
new file mode 100644
index 0000000..cc2d399
--- /dev/null
+++ b/doc/sphinx/props/P_WATER.rst
@@ -0,0 +1,131 @@
+P_WATER
+=======
+
+NAME
+----
+::
+
+    P_WATER                       "water"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/fishing.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt den Gewaessertyp. Kann in Raeumen, Angeln und Wasserbehaeltern
+    verwendet werden. Die verfuegbaren Optionen und Funktionsweisen sind in 
+    den nachfolgenden Abschnitten aufgefuehrt.
+
+    Raum:
+    *****
+      Legt den Typ des Gewaessers fest, das es in diesem Raum gibt. Von
+      diesem Typ haengt ab, welche Arten von Fischen es hier standardmaessig
+      gibt und welche Arten von Angeln verwendet werden koennen. 
+
+      
+
+      Beispiel:
+
+      SetProp(P_WATER, W_HARBOR);
+
+      
+
+      Folgende
+      Typen stehen zur Verfuegung, von denen in Raeumen nur einer gesetzt
+      werden darf:
+
+      Salzwasser:
+        W_BEACH   Strand: Scholle, Flunder, Rochen, Seezunge, Katzenhai
+        W_HARBOR  Hafen: Dorsch, Rochen, Seezunge, Hering, Katzenhai
+        W_OCEAN   Ozean/Meer: Hai, Thunfisch, Kabeljau, Schwertfisch, Seehase,
+                  Seeteufel, Seewolf
+
+      Suesswasser:
+        W_RIVER   Fluss: Piranha, Lachs, Forelle, Bachsaibling
+        W_POOL    Teich: Stichling, Goldfisch, Schlei, Karpfen, Goldorfe
+        W_LAKE    See: Karpfen, Barsch, Hecht, Seesaibling
+        W_ROCK    Bergbach: Lachs, Forelle, Bachsaibling
+        W_STREAM  Bach: Stichling, Bachforelle, Neuauge, Bachsaibling
+
+      Sonstige:
+        W_USER    wenn dieser Gewaessertyp gesetzt wird, MUSS der Raum 
+                  zusaetzlich die Funktion GetAquarium() definieren, die
+                  eine Liste der hier fangbaren Fische zurueckgeben muss.
+                  Beispiel:
+
+                  string* GetAquarium(){ 
+                    return ({"/d/ebene/fraggle/angel/fisch"}); 
+                  }
+        W_DEAD    Lebloses Wasser. Enthaelt keine Fische, man kann
+                  aber die Standardflasche fuellen.
+
+        W_OTHER   1024   // Flasche enthaelt Fluessigkeit!=Wasser
+
+
+    Angel:
+    ******
+      Angeln sind ueblicherweise auf bestimmte Anwendungsbereiche ausgelegt.
+      Ob eine Angel in einem Gewaesser benutzt werden kann, haengt davon ab,
+      ob P_WATER in der Angel den Gewaessertyp des Raumes enthaelt. Von den
+      oben genannten Typen koennen mehrere ver-ODER-t gesetzt werden.
+      Verwendung einer fuer das oertliche Gewaesser ungeeigneten Angel fuehrt
+      zu einer um 60+random(60) Sekunden verlaengerten Wartezeit beim Angeln.
+
+      
+
+      Beispiel: Setzt man den Gewaessertyp mit 
+
+        SetProp(P_WATER, W_HARBOR|W_OCEAN);
+
+      schaltet das die Angel sowohl fuer Haefen, als auch fuer offene Meere
+      (Ozeane) frei.
+
+      Folgende kombinierte Gewaessertypen sind fuer einfache Angeln 
+      vordefiniert:
+
+      Kurze Standardangeln:
+        W_SHORT W_HARBOR|W_RIVER|W_POOL|W_LAKE|W_ROCK|W_USER|W_OCEAN|W_STREAM
+      Spezielle Strandruten:
+        W_LONG  W_BEACH|W_USER
+      funktioniert in allen Salzgewaessern:
+        W_SALT  W_HARBOR|W_OCEAN|W_BEACH
+      funktioniert in allen Suessgewaessern:
+        W_SWEET W_RIVER|W_POOL|W_LAKE|W_ROCK|W_STREAM
+
+      Hinweis: W_DEAD ist in diesen Kombinationen nicht enthalten, da es
+      in solchen Gewaessern ohnehin keine Fische gibt.
+      Die Kombi-Typen enthalten W_USER, um bei entsprechenden Gewaessern
+      zu vermeiden, dass es dort standardmaessig einen Malus auf die 
+      Wartezeit gibt. Standardwert fuer P_WATER in Angeln ist ebenfalls 
+      W_USER.
+
+    Koeder:
+    *******
+      Auch Koeder koennen fuer die Verwendung in bestimmten Gewaessern besser
+      geeignet sein als in anderen, z.B. eine Seeschnecke fuer Salzwasser,
+      ein Mehlwurm hingegen fuer Suesswasser. Gesetzt wird P_WATER hierfuer
+      auf die oben aufgefuehrten Werte.
+      Verwendung eines ungeeigneten Koeders fuehrt zu einer um 60+random(60)
+      Sekunden laengeren Wartezeit beim Angeln.
+
+    Wasserbehaelter:
+    ****************
+      Die Property gibt an, ob der Behaelter Wasser enthaelt oder nicht.
+      Der Wert sollte immer auf den Typ jenes Gewaessers gesetzt sein, aus
+      dem der Behaelter aufgefuellt wurde.
+
+SIEHE AUCH
+----------
+::
+
+    Properties: P_FISH
+    Methoden:   GetAquarium(L)
+
+
+Zuletzt geaendert: 2014-Aug-21, Arathorn
+
diff --git a/doc/sphinx/props/P_WC.rst b/doc/sphinx/props/P_WC.rst
new file mode 100644
index 0000000..9129867
--- /dev/null
+++ b/doc/sphinx/props/P_WC.rst
@@ -0,0 +1,56 @@
+P_WC
+====
+
+NAME
+----
+::
+
+	P_WC				"wc"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/weapon.h
+
+BESCHREIBUNG
+------------
+::
+
+	Die Waffenklasse (engl: weapon class), also die Staerke der Waffe,
+	stellt einen numerischen Wert dar, der umso groesser ist, desto mehr
+	Schaden eine Waffe im Kampf anrichtet. Beim Zuecken oder Wegstecken
+	einer Waffe durch ein Lebewesen wird innerhalb des Lebewesens auch
+	die Property P_TOTAL_WC aktualisiert, welche somit immer die
+	aktuelle Angriffsstaerke enthaelt. Beim Zuecken erhaelt sie hierbei
+	die Waffenklasse der Waffe und beim Wegstecken die Angriffsstaerke
+	aus der Property P_HANDS (Kaempfen mit blossen Haenden).
+	Die Waffenklasse von einhaendigen Waffen sollte 150 nicht
+	ueberschreiten, die Obergrenze fuer zweihaendige Waffen liegt bei
+	200. Ausnahmen von dieser Regel beduerfen der Absprache mit dem
+	Erzmagier fuer Ruestungen, Waffen und Monster!
+	Negative Werte bewirken keinen Schaden, allerdings auch keine
+	Heilung.
+
+BEMERKUNGEN
+-----------
+::
+
+	Query- und Setmethoden auf P_WC sollten unbedingt vermieden werden. Sie
+	fuehren in der Regel zu massiven Inkonsistenzen im Mechanismus der 
+	Ruestungsbeschaedigung und -reparatur.
+	Auch mit einer HitFunc() duerfen die Obergrenzen nicht ohne
+	Absprache ueberschritten werden! Ausserdem ist es ratsam, die
+	zusaetzlichen Kampfeigenschaften in P_EFFECTIVE_WC gesondert
+	anzugeben.
+
+SIEHE AUCH
+----------
+::
+
+	/std/weapon.c, /std/weapon/combat.c
+	P_DAMAGED, P_EFFECTIVE_WC, P_WEAPON_TYPE
+	Damage()
+
+02.10.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_WEAPON.rst b/doc/sphinx/props/P_WEAPON.rst
new file mode 100644
index 0000000..b9fde21
--- /dev/null
+++ b/doc/sphinx/props/P_WEAPON.rst
@@ -0,0 +1,31 @@
+P_WEAPON
+========
+
+NAME
+----
+::
+
+     P_WEAPON                      "weapon"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+      Momentan gezueckte Waffe. Im Living gesetzt.
+
+SIEHE AUCH
+----------
+::
+
+      Verwandt:		P_ARMOURS
+      Waffen:		P_WC, P_WEAPON_TYPE, P_DAM_TYPE, P_NR_HANDS, P_PARRY
+      Sonstiges:	P_UNWIELD_TIME, P_EQUIP_TIME, P_LAST_USE
+
+10.Feb 2005 Gloinson
+
diff --git a/doc/sphinx/props/P_WEAPON_TEACHER.rst b/doc/sphinx/props/P_WEAPON_TEACHER.rst
new file mode 100644
index 0000000..a38f8c9
--- /dev/null
+++ b/doc/sphinx/props/P_WEAPON_TEACHER.rst
@@ -0,0 +1,29 @@
+P_WEAPON_TEACHER
+================
+
+NAME
+----
+::
+
+    P_WEAPON_TEACHER              "weapon_teacher"
+
+DEFINIERT IN
+------------
+::
+
+    combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property wird in einem Azubi gesetzt (zur Zeit nur fuer die 
+    Kaempfer-Gilde), der selbst ueber die allgemeinen Waffenskills
+    verfuegt.
+
+    In diese Property wird der Name eines Kaempfergilden-Ausbilders
+    eingetragen.
+
+    Unter Anleitung des Ausbilders lernt der Azubi dann etwas schneller
+    die allgemeinen Waffenskills.
+
diff --git a/doc/sphinx/props/P_WEAPON_TYPE.rst b/doc/sphinx/props/P_WEAPON_TYPE.rst
new file mode 100644
index 0000000..56622c3
--- /dev/null
+++ b/doc/sphinx/props/P_WEAPON_TYPE.rst
@@ -0,0 +1,42 @@
+P_WEAPON_TYPE
+=============
+
+NAME
+----
+::
+
+     P_WEAPON_TYPE "weapon_type"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Um was fuer eine Waffe handelt es sich? Es stehen verschiedene
+     Typen zur Auswahl. Man sollte hier nur die in <combat.h> definierten
+     Konstanten verwenden:
+
+        WT_AMMU           Munition fuer Fernkampfwaffen
+        WT_AXE            Axt
+        WT_CLUB           Keule
+        WT_HANDS          blosse Haende
+        WT_KNIFE          Messer, Dolch
+        WT_RANGED_WEAPON  Fernkampfwaffe
+        WT_SPEAR          Speer
+        WT_STAFF          Kampfstab
+        WT_SWORD          Schwert
+        WT_WHIP           Peitsche
+        WT_MISC           Sonstiges
+
+    Der Waffentyp WT_MISC ist schnoedem Tand und nutzlosem Kram vorbehalten.
+    Waffen dieses Typs duerfen keine P_WC > 0 besitzen oder kampfrelevante
+    Bedeutung haben.
+
+
+Letzte Aenderung: 27. Mai 2015, Arathorn.
+
diff --git a/doc/sphinx/props/P_WEAR_FUNC.rst b/doc/sphinx/props/P_WEAR_FUNC.rst
new file mode 100644
index 0000000..951eecc
--- /dev/null
+++ b/doc/sphinx/props/P_WEAR_FUNC.rst
@@ -0,0 +1,44 @@
+P_WEAR_FUNC
+===========
+
+NAME
+----
+::
+
+     P_WEAR_FUNC "wear_func"
+
+DEFINIERT IN
+------------
+::
+
+     <armour.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Falls ein Objekt eine WearFunc() fuer die Ruestung / Kleidung definiert, 
+     so muss dieses Objekt in dieser Property eingetragen sein.
+
+     Die Auswertung dieser Property erfolgt in Laufe eines DoWear() in der
+     nicht-oeffentlichen Funktion _check_wear_restrictions()..
+
+BEISPIELE
+---------
+::
+
+     Siehe das Beispiel zu WearFunc()
+
+SIEHE AUCH
+----------
+::
+
+     armours, clothing, /std/clothing/wear.c, /std/armour/wear.c
+     WearFunc(), InformWear()
+
+LETZTE AeNDERUNG
+----------------
+::
+
+15.02.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_WEAR_MSG.rst b/doc/sphinx/props/P_WEAR_MSG.rst
new file mode 100644
index 0000000..231394c
--- /dev/null
+++ b/doc/sphinx/props/P_WEAR_MSG.rst
@@ -0,0 +1,82 @@
+P_WEAR_MSG
+==========
+
+NAME
+----
+::
+
+    P_WEAR_MSG                       "wear_msg"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/armour.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zweiteiliges Array mit Meldungen, die beim Anziehen einer Ruestung oder
+     Kleidung an den Spieler und die Umgebung ausgegeben werden.
+     Der erste Eintrag geht an den Spieler, der zweite Eintrag an die
+     Umgebung. Zeilenumbrueche werden automatisch gemacht, existierende
+     jedoch beruecksichtigt.
+
+     Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
+     man replace_personal()).
+
+     [Wegen Abwaertskompatibilitaet ist auch noch der Platzhalter %s
+      moeglich, wobei in der eigenen Meldung %s fuer den Waffennamen steht,
+      in der an den Raum das erste %s fuer den Spielernamen, das zweite fuer
+      den Waffennamen.]
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_NAME, "Helm");
+    SetProp(P_WEAR_MSG,
+     ({"Du stuelpst die @WEN2 ueber.", 
+       "@WER1 stuelpt sich @WENU2 ueber."}));
+
+    -> beim Anziehe durch Urk:
+       Urk bekommt: Du stuelpst dir den Helm ueber.
+       Der Raum:    Urk stuelpt sich einen Helm ueber.
+
+    SetProp(P_WEAR_MSG,
+     ({"Als Du Dir den langen Mantel ueberziehst, steckst Du erstmal "
+       "mit Deinem dicken Schaedel fest. Doch nach einem kraeftigen "
+       "Ruck bist Du endlich durch und siehst wieder etwas.",
+       "@WER1 zieht sich einen langen Mantel ueber und bleibt "
+       "prompt mit dem dicken Schaedel stecken. Doch nach einem "
+       "kraeftigen Ruck kann @WERQP1 wieder etwas sehen und grinst Dich "
+       "verlegen an."}));
+
+    -> beim Anziehen durch Urk:
+       Urk bekommt: Als Du Dir den langen Mantel ueberziehst, steckst Du
+		    erstmal mit Deinem dicken Schaedel fest. Doch nach einem
+		    kraeftigen Ruck bist Du endlich durch und siehst wieder
+		    etwas.
+
+       Der Raum:    Urk zieht sich einen langen Mantel ueber und bleibt
+		    prompt mit dem dicken Schaedel stecken. Doch nach
+		    einem kraeftigen Ruck kann er wieder etwas sehen und
+		    grinst Dich verlegen an.
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_UNWEAR_MSG, P_WIELD_MSG, P_UNWIELD_MSG
+                 P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_PICK_MSG
+     Funktionen: WearFunc, UnwearFunc, InformWear()
+     Sonstiges:  replace_personal(E), clothing, /std/clothing/wear.c
+                 armour, /std/armour/wear.c
+
+LETZTE AeNDERUNG
+----------------
+::
+
+15.02.2009
+
diff --git a/doc/sphinx/props/P_WEIGHT.rst b/doc/sphinx/props/P_WEIGHT.rst
new file mode 100644
index 0000000..8e51d18
--- /dev/null
+++ b/doc/sphinx/props/P_WEIGHT.rst
@@ -0,0 +1,48 @@
+P_WEIGHT
+========
+
+NAME
+----
+::
+
+    P_WEIGHT                      "weight"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/restrictions.h
+
+BESCHREIBUNG
+------------
+::
+
+     - Objekte
+       Das Gewicht eines Objetes in Gramm.
+
+     - Speisen
+       Gewicht einer Portion der Speise.
+
+       
+
+BEMERKUNGEN
+-----------
+::
+
+     In tragbaren Speisen (erben von /std/food) setzt man mit SetProp
+     das Gewicht _einer_ Portion. Per QueryProp erhaelt man aber das
+     Gesamtgewicht der Speise inclusive des eventuell vorhandenen Behaelters.
+     Das Gewicht des Behaelters wird dabei aus P_EMPTY_PROPS[P_WEIGHT]
+     gelesen.
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     Speisen: wiz/food, P_EMPTY_PROPS
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_WEIGHT_PERCENT.rst b/doc/sphinx/props/P_WEIGHT_PERCENT.rst
new file mode 100644
index 0000000..fbd34d3
--- /dev/null
+++ b/doc/sphinx/props/P_WEIGHT_PERCENT.rst
@@ -0,0 +1,47 @@
+P_WEIGHT_PERCENT
+================
+
+NAME
+----
+::
+
+    P_WEIGHT_PERCENT              "weight_percent"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property gibt an, wieviel Prozent des Gewichts des Inhaltes
+     "nach aussen" wiedergegeben werden.
+
+BEMERKUNGEN
+-----------
+::
+
+     Alle Werte die < 50% liegen sollten sehr gut begruendet und mit Vor-
+     sicht verwendet werden. Hier koennten dann zum Beispiel P_MAX_OBJECTS
+     auf einen kleinen Wert begrenzt werden.
+
+     Container die hier einen Wert ueber dem des Postpakets haben, sollten
+     auch schwer zu erreichen sein. Auf jeden Fall mit dem Regionsmagier
+     besprechen!
+
+BEISPIELE
+---------
+::
+
+     Um sich zu orientieren kann das Postpaket von Loco als Beispiel hin-
+     zugezogen werden (/p/service/loco/obj/parcel).
+
+SIEHE AUCH
+----------
+::
+
+     P_MAX_OBJECTS, P_MAX_WEIGHT, P_LIGHT_TRANSPARENCY, container
+
diff --git a/doc/sphinx/props/P_WEIGHT_PER_UNIT.rst b/doc/sphinx/props/P_WEIGHT_PER_UNIT.rst
new file mode 100644
index 0000000..f1789dc
--- /dev/null
+++ b/doc/sphinx/props/P_WEIGHT_PER_UNIT.rst
@@ -0,0 +1,29 @@
+P_WEIGHT_PER_UNIT
+=================
+
+NAME
+----
+::
+
+    P_WEIGHT_PER_UNIT             "weight_per_unit"             
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gewicht in Gramm pro Untereinheit.
+
+BEMERKUNGEN
+-----------
+::
+
+     Deprecated. Bitte SetGramsPerUnits() (U_GPU) benutzen.
+
+25.Aug 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_WIELDED.rst b/doc/sphinx/props/P_WIELDED.rst
new file mode 100644
index 0000000..578ac3d
--- /dev/null
+++ b/doc/sphinx/props/P_WIELDED.rst
@@ -0,0 +1,38 @@
+P_WIELDED
+=========
+
+NAME
+----
+::
+
+     P_WIELDED "wielded"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Ist diese Property gesetzt, dann ist die Waffe gerade gezueckt. Der
+     Traeger ist in der Property vermerkt.
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Property laesst sich nur abfragen!
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon.c
+     P_WEAPON
+
+
+Last modified: 2015-Jul-11, Arathorn 
+
diff --git a/doc/sphinx/props/P_WIELD_FUNC.rst b/doc/sphinx/props/P_WIELD_FUNC.rst
new file mode 100644
index 0000000..eb0c93d
--- /dev/null
+++ b/doc/sphinx/props/P_WIELD_FUNC.rst
@@ -0,0 +1,39 @@
+P_WIELD_FUNC
+============
+
+NAME
+----
+::
+
+     P_WIELD_FUNC "wield_func"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Falls ein Objekt eine WieldFunc() fuer die Waffe definiert, so muss
+     dieses Objekt in dieser Property eingetragen werden.
+
+     Die Auswertung dieser Property erfolgt in wield_me().
+
+BEISPIELE
+---------
+::
+
+     Siehe das Beispiel zu WieldFunc()
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon.c, WieldFunc()
+
+
+Last modified: Sun May 19 15:40:02 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_WIELD_MSG.rst b/doc/sphinx/props/P_WIELD_MSG.rst
new file mode 100644
index 0000000..5791666
--- /dev/null
+++ b/doc/sphinx/props/P_WIELD_MSG.rst
@@ -0,0 +1,74 @@
+P_WIELD_MSG
+===========
+
+NAME
+----
+::
+
+     P_WIELD_MSG                       "wield_msg" 
+
+DEFINIERT IN
+------------
+::
+
+     /sys/weapon.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zweiteiliges Array mit Meldungen, die beim Zuecken einer Waffe an den
+     Spieler und die Umgebung ausgegeben werden.
+     Der erste Eintrag geht an den Spieler, der zweite Eintrag an die
+     Umgebung.  Zeilenumbrueche werden automatisch gemacht, existierende
+     jedoch beruecksichtigt.
+
+     Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
+     man replace_personal()).
+
+     [Wegen Abwaertskompatibilitaet ist auch noch der Platzhalter %s
+      moeglich, wobei in der eigenen Meldung %s fuer den Waffennamen steht,
+      in der an den Raum das erste %s fuer den Spielernamen, das zweite fuer
+      den Waffennamen.]
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_NAME, "Streitkolben");
+    SetProp(P_WIELD_MSG,
+     ({"Du zueckst @WEN2 und stoesst einen markerschuetternden Schrei aus.", 
+       "@WER1 zueckt @WENU2 und stoesst einen markerschuetternden Schrei "
+       "aus." }));
+
+    -> beim Zuecken durch Urk:
+       Urk bekommt: Du zueckst den Streitkolben und stoesst einen
+		    markerschuetternden Schrei aus.
+       Der Raum:    Urk zueckt einen Streitkolben und stoesst einen
+		    markerschuetternden Schrei aus.
+
+    SetProp(P_WIELD_MSG,
+     ({"Du zueckst den klobigen Streitkolben und fuchtelst damit "
+       "wild vor Deiner Nase herum.",
+       "@WER1 zueckt einen klobigen Streitkolben und fuchtelt "
+       "damit wild vor der eigenen Nase herum. Hoffentlich verletzt "
+       "@WERQP1 sich dabei nicht ..."}));
+
+    -> beim Zuecken durch Urk:
+       Urk bekommt: Du zueckst den klobigen Streitkolben und fuchtelst
+                    damit wild vor Deiner Nase herum.
+       Der Raum:    Urk zueckt einen klobigen Streitkolben und fuchtelt
+		    damit wild vor der eigenen Nase herum. Hoffentlich
+                    verletzt er sich dabei nicht ...
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_UNWIELD_MSG, P_WEAR_MSG, P_UNWEAR_MSG
+                 P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_PICK_MSG
+     Funktionen: UnwieldFunc, WieldFunc
+     Sonstiges:  replace_personal(E), /std/weapon/combat.c
+
+29. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_WIMPY.rst b/doc/sphinx/props/P_WIMPY.rst
new file mode 100644
index 0000000..f24548c
--- /dev/null
+++ b/doc/sphinx/props/P_WIMPY.rst
@@ -0,0 +1,31 @@
+P_WIMPY
+=======
+
+NAME
+----
+::
+
+    P_WIMPY                       "wimpy"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Numerischer Wert. Das Lebewesen flieht, wenn die Lebenspunkte
+     unter diesen Wert sinken.
+
+SIEHE AUCH
+----------
+::
+
+     P_WIMPY_DIRECTION
+
+
+Letzte Aenderung: Mon Feb 12 17:50:47 2001 von Tilly
+
diff --git a/doc/sphinx/props/P_WIMPY_DIRECTION.rst b/doc/sphinx/props/P_WIMPY_DIRECTION.rst
new file mode 100644
index 0000000..8db2198
--- /dev/null
+++ b/doc/sphinx/props/P_WIMPY_DIRECTION.rst
@@ -0,0 +1,41 @@
+P_WIMPY_DIRECTION
+=================
+
+NAME
+----
+::
+
+    P_WIMPY_DIRECTION             "wimpy_dir"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Fluchtrichtung eines Spielers oder NPCs
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Fluchtrichtung kann nicht nur ein Ausgang (sueden, osten, ...)
+     sein, sondern auch ein Kommando, welches der Spieler beim Anschlagen
+     ausfuehrt (z.b. <kletter seil hoch> oder <rufe Elender Mist!>).
+
+     Ausgefuehrt wird die Fluchtrichtung per command(), wenn die LP des 
+     Lebewesens unter die mit <vorsicht> angegebe LP-Grenze sinkt.
+
+SIEHE AUCH
+----------
+::
+
+     P_WIMPY
+
+
+Letzte Aenderung: Mon Feb 12 17:46:47 2001 von Tilly
+
diff --git a/doc/sphinx/props/P_WIZ_DEBUG.rst b/doc/sphinx/props/P_WIZ_DEBUG.rst
new file mode 100644
index 0000000..041090b
--- /dev/null
+++ b/doc/sphinx/props/P_WIZ_DEBUG.rst
@@ -0,0 +1,37 @@
+P_WIZ_DEBUG
+===========
+
+NAME
+----
+::
+
+    P_WIZ_DEBUG                    "std_p_wizdebug"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gesetzt, wenn der Magier (oder ein Testspieler) Debugmeldungen wahrnehmen
+     moechte.
+     Debugmeldungen sind Nachrichten, die mit dem Typ MT_DEBUG an ReceiveMsg()
+     uebergeben werden.
+
+     
+
+     Die Werte von P_WIZ_DEBUG sind zur Zeit 0 oder 1, das kann sich aber
+     jederzeit aendern.
+     Magier aendern diese Prop bitte ueber "mschau".
+
+SIEHE AUCH
+----------
+::
+
+     mschau
+     P_WANTS_TO_LEARN
+
diff --git a/doc/sphinx/props/P_WORN.rst b/doc/sphinx/props/P_WORN.rst
new file mode 100644
index 0000000..ec3b359
--- /dev/null
+++ b/doc/sphinx/props/P_WORN.rst
@@ -0,0 +1,63 @@
+P_WORN
+======
+
+NAME
+----
+::
+
+     P_WORN "worn"
+
+DEFINIERT IN
+------------
+::
+
+     <armour.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Mittels dieser Property laesst sich ermitteln, ob eine Ruestung bzw. 
+     Kleidung derzeit getragen wird und wenn ja, von wem.
+
+     Entweder enthaelt die Property den Wert 0, oder sie enthaelt den
+     Traeger der Ruestung / Kleidung (als Objekt).
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Property laesst sich nur abfragen!
+
+BEISPIELE
+---------
+::
+
+     Eine DefendFunc() koennte dem Traeger der Ruestung wie folgt etwas
+     mitteilen:
+
+     // Die Ruestung gibt Schutz gegen Feuer
+     int DefendFunc(string *dtyp, mixed spell, object enemy)
+     {
+       if (member(dtyp, DT_FIRE) != -1) {
+         // P_WORN ist auf jeden Fall gesetzt, da sonst die
+         // DefendFunc ueberhaupt nicht aufgerufen wuerde!
+         tell_object(QueryProp(P_WORN),
+           "Die Flammen zuengeln nur leicht ueber die Ruestung.\n");
+         return 10;
+       }
+       return 0;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     clothing, /std/clothing.c, armour, /std/armour.c
+
+LETZTE AeNDERUNG
+----------------
+::
+
+15.02.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_XP.rst b/doc/sphinx/props/P_XP.rst
new file mode 100644
index 0000000..ec4864a
--- /dev/null
+++ b/doc/sphinx/props/P_XP.rst
@@ -0,0 +1,81 @@
+P_XP
+====
+
+NAME
+----
+::
+
+     P_XP                    "xp"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt die Anzahl der Erfahrungspunkte, die ein
+     Lebewesen erreicht hat. Dies geschieht insbesondere durch
+     Kampfhandlungen, wobei es sowohl fuer Einzelschlaege als auch fuer
+     das Toeten eines Opfers Punkte gibt.
+
+     Bei einzelnen Schlaegen ist die Vergabe von Erfahrungspunkten davon
+     abhaengig, wie stark man das Opfer getroffen hat, und welche
+     Gesamtwaffenklasse es hat (damage*P_TOTAL_WC/10).
+
+     Beim Todesschlag erhaelt man zusaetzlich die Erfahrungspunkte des
+     Opfers geteilt durch 100 (P_XP/100). Dieser Wert wird allerdings
+     gegebenenfalls auf ein Team aufgeteilt, sofern der Angreifer sich in
+     einem solchigen befindet.
+
+BEISPIEL
+--------
+::
+
+     NPC's gibt man im allgemeinen einen levelabhaengigen Sockelwert an
+     Erfahrungspunkten mit, da sie nicht allzuoft selbst Gegner toeten
+     und somit kaum die Moeglichkeit haben, diese Punkte selbst
+     anzusammeln. Trotzdem sollen sie ja dem Spieler eine gewisse Anzahl
+     an Erfahrungspunkten liefern, wenn sie getoetet werden:
+
+       include "/sys/living/life.h"
+       inherit "std/npc";
+       void create() {
+         ...
+         SetProp(P_XP,25000000);
+       }
+
+     Beim Toeten gibt es nun 25.000.000/100 = 250.000 Erfahrungspunkte.
+     Damit wird der NPC sogar automatisch fuer die Vergabe von
+     Erstkillstufenpunkten vorgesehen.
+
+     Die Funktion create_default_npc() setzt P_XP und andere Eigenschaften
+     auf geeignete Werte.
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Vergabe von Erstkillstufenpunkten kann man ueber die Property
+     P_NO_SCORE unterbinden, die Vergabe von Erfahrungspunkten ueber
+     P_NO_XP. Automatisch werden Lebewesen fuer Erstkillstufenpunkte
+     vorgesehen, sofern sie eine der folgenden Grenzen ueberschritten
+     haben:
+       SCORE_LOW_MARK:  200000 (1 Stufenpunkt)
+       SCORE_HIGH_MARK: 600000 (2 Stufenpunkte)
+     Definiert sind die Konstanten in "/secure/scoremaster.h".
+
+SIEHE AUCH
+----------
+::
+
+     Funktionen:  AddExp(), do_damage()
+     Verwandt:    P_NO_XP, P_LAST_XP
+     Sonstiges:   P_NO_SCORE, create_default_npc()
+                  P_TOTAL_WC
+
+14.Feb 2007 Gloinson
+
diff --git a/doc/sphinx/props/P_X_ATTR_MOD.rst b/doc/sphinx/props/P_X_ATTR_MOD.rst
new file mode 100644
index 0000000..3cd36bf
--- /dev/null
+++ b/doc/sphinx/props/P_X_ATTR_MOD.rst
@@ -0,0 +1,68 @@
+P_X_ATTR_MOD
+============
+
+NAME
+----
+::
+
+    P_X_ATTR_MOD                  "extern_attributes_modifier"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mapping, das die Attribute des Spielers veraendert, der das Objekt bei
+    sich hat.
+
+    Zu beachten:
+    Diese Property bitte _ausschliesslich_ mit SetProp aendern, weil damit
+    gleichzeitig UpdateAttributes() im Lebewesen aufgerufen und ggf. das
+    Objekt als Statmodifizierer registriert wird.
+
+    Diese Property ist fuer Krankheiten, Flueche etc. gedacht. Bei
+    Waffen/Ruestungen, die die Attribute beeinflussen sollen, verwendet
+    man besser P_M_ATTR_MOD.
+
+    P_X_ATTR_MOD und P_M_ATTR_MOD duerfen einen gemeinsamen kumulierten
+    positiven Grenzwert nicht ueberschreiten. Dieser Grenzwert,
+    CUMULATIVE_ATTR_LIMIT, ist in /sys/living/attributes.h definiert.
+
+BEMERKUNGEN
+-----------
+::
+
+    Die Methode /std/thing/restrictions::_set_extern_attributes_modifier()
+    benachrichtigt tragende Livings ueber Aenderungen.
+    Bitte beim "Loeschen" der Prop nicht den Wert des jew. Attributes im
+    uebergebenen Mapping als 0 uebergeben, sondern das Key/Werte-Paar ganz
+    entfernen und bzw. ein leeres Mapping oder 0 uebergeben.
+
+BEISPIEL
+--------
+::
+
+    // Dem Lebewesen, das das Objekt bei sich hat, wird 2 von A_INT abgezogen
+    SetProp(P_X_ATTR_MOD,([A_INT:-2]));
+
+    // Stats wiederherstellen:
+    SetProp(P_X_ATTR_MOD,([]));
+
+SIEHE AUCH
+----------
+::
+
+    QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+    SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+    SetTimedAttrModifier(), QueryTimedAttrModifier(),
+    DeleteTimedAttrModifier(),
+    P_X_HEALTH_MOD, P_M_HEALTH_MOD, P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS,
+    P_TIMED_ATTR_MOD, P_M_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+02.02.2016, Gloinson
+
diff --git a/doc/sphinx/props/P_X_HEALTH_MOD.rst b/doc/sphinx/props/P_X_HEALTH_MOD.rst
new file mode 100644
index 0000000..7f294e3
--- /dev/null
+++ b/doc/sphinx/props/P_X_HEALTH_MOD.rst
@@ -0,0 +1,60 @@
+P_X_HEALTH_MOD
+==============
+
+NAME
+----
+::
+
+    P_X_HEALTH_MOD                  "extern_health_modifier"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mapping, mit dem die maximalen Lebenspunkte und Magiepunkte eines
+    Spielers veraendert werden, der dieses Objekt bei sich traegt.
+
+    Zu beachten: Diese Property bitte _ausschliesslich_ mit SetProp
+    aendern, weil damit gleichzeitig UpdateAttributes() im
+    Lebewesen aufgerufen und ggf. das Objekt als Statmodifizierer 
+    registriert wird.
+
+    Bei Ruestungen/Waffen, die diese Wirkung entfalten sollen, verwendet
+    man besser P_M_HEALTH_MOD.
+
+BEMERKUNGEN
+-----------
+::
+
+    Bitte bei "Loeschen" der Prop nicht den Wert des jew. Attributes im 
+    uebergebenen Mapping als 0 uebergeben, sondern das Key/Werte-Paar ganz 
+    entfernen und ggf. ein leeres Mapping oder 0 uebergeben.
+
+BEISPIEL
+--------
+::
+
+    // Dem Spieler, der das Objekt bei sich traegt, wird P_MAX_HP um 5
+    // erhoeht und P_MAX_SP um 5 erniedrigt.
+    SetProp(P_X_HEALTH_MOD,([P_HP:5,P_SP:-5]));
+    // Stats wiederherstellen:
+    SetProp(P_X_HEALTH_MOD,([]);
+
+SIEHE AUCH
+----------
+::
+
+    P_M_HEALTH_MOD, P_X_ATTR_MOD, P_M_ATTR_MOD, balance
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    Sat, 06.02.1999, 14:00:00 von Paracelsus
+
diff --git a/doc/sphinx/props/P_ZAP_MSG.rst b/doc/sphinx/props/P_ZAP_MSG.rst
new file mode 100644
index 0000000..03ba0c1
--- /dev/null
+++ b/doc/sphinx/props/P_ZAP_MSG.rst
@@ -0,0 +1,42 @@
+P_ZAP_MSG
+=========
+
+NAME
+----
+::
+
+      P_ZAP_MSG			"zap_msg"
+
+DEFINIERT IN
+------------
+::
+
+      /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+      Die Property enthaelt ein dreielementiges Array mit den folgenden
+      Eintraegen:
+	  1.) Meldung, die der Magier beim Zappen bekommt.
+	  2.) Meldung, die die Spieler im Raum beim Zappen bekommen.
+	  3.) Meldung, die das Opfer beim Zappen bekommt.
+
+      Mit @@wer@@, @@wessen@@, ... kann der Name des Opfers und mit @@ich@@
+      der Name des Magiers in die Meldung eingewoben werden.
+
+      Die Property ist in Magiern gesetzt und gilt nur dort.
+
+SIEHE AUCH
+----------
+::
+
+     Tod:		die(L)
+     Todesmeldungen:	P_KILL_NAME, P_KILL_MSG, P_DIE_MSG, P_MURDER_MSG
+			P_ENEMY_DEATH_SEQUENCE
+     Sonstiges:		P_CORPSE, P_NOCORPSE, /room/death/death_room.c
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/U_REQ.rst b/doc/sphinx/props/U_REQ.rst
new file mode 100644
index 0000000..3246b41
--- /dev/null
+++ b/doc/sphinx/props/U_REQ.rst
@@ -0,0 +1,83 @@
+U_REQ
+=====
+
+NAME
+----
+::
+
+    U_REQ                         "u_req"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/unit.h
+
+BESCHREIBUNG
+------------
+::
+
+     Die Prop kann in Unitobjekten gesetzt werden.
+     Sie gibt die Anzahl der Einheiten an, die an der Unit manipuliert werden
+     sollen, falls mit weniger als P_AMOUNT umgegegangen werden soll.
+
+     
+
+     Die Prop wird automatisch gesetzt, wenn id() an einem Unitobjekt gerufen
+     wird und die ID grundsaetzlich zutreffend ist, die aus der ID ermittelte
+     Zahl aber kleiner als P_AMOUNT ist.
+     Sie kann auch manuell mittel SetProp() (aber nicht Set()) gesetzt werden.
+
+     U_REQ wird beim Bewegen und Zerstoeren, bei Ermittlung von Wert und
+     Gewicht beruecksichtigt.
+
+     U_REQ wird vom Unitobjekt automatisch wieder auf P_AMOUNT gesetzt, wenn
+     sich query_verb() oder debug_info(DINFO_EVAL_NUMBER) veraendert haben.
+     (DINFO_EVAL_NUMBER ist eine Zahl, die sich jedesmal erhoeht, wenn der
+      Driver eine neue Berechnung/Ausfuehrung beginnt. Diese Nummer wird fuer
+      jeden vom driver initiierten Aufruf von LPC-Code erhoeht, z.B. bei jedem
+      Kommando, call_out, heart_beat etc. Details s. debug_info().)
+
+     Ebenso wird U_REQ bei der Vereinigung mit einem anderen (gleichen)
+     Objekt auf P_AMOUNT des vereinigten Objektes gesetzt.
+
+BUGS
+----
+::
+
+    Viele. Dies ist ein uebler Hack. Geht aber nicht ohne.
+    Diese Prop war endlos lang gar nicht dokumentiert. Hier beschrieben ist
+    das Verhalten, was zur Zeit vorliegt. Dies mag unterschiedlich zu dem
+    irgendwann intendierten sein.
+
+BEISPIELE
+---------
+::
+
+    object o = clone_object("unitobjekt");
+    o->SetProp(P_AMOUNT, 100);   // ab jetzt hat o 100 Einheiten.
+    o->move(npc, M_GET);         // ob mit 100 Einheiten wird bewegt
+    o->SetProp(U_REQ, 50);
+    o->move(anderernpc, M_GIVE); // 50 Einheiten werden bewegt, 50 verbleiben
+    (Technisch: das Objekt wird auf 50 Einheiten geaendert, bewegt und in der
+     alten Umgebung wird ein neues Objekt mit 50 Einheiten erzeugt.)
+
+    o->SetProp(U_REQ, 42);
+    o->remove(1);               // 42 Einheiten von den 50 werden zerstoert.
+    (Technisch: P_AMOUNT wird einfach um U_REQ reduziert.)
+
+    # gib 18 muenzen an blupp
+    Hierbei wird ob->id("18 muenzen") gerufen, was U_REQ im Geldobjekt auf 18
+    setzt. Bei der Bewegung bekommt blupp daher das Objekt mit P_AMOUNT==18
+    und der Rest wird im Abgebenden neu erzeugt.
+    # gib geld an flubbel
+    Das U_REQ aus dem verherigen Kommando ist jetzt nicht mehr gueltig. Zwar
+    ist es das gleiche Kommandoverb, aber DINFO_EVAL_NUMBER ist jetzt
+    anders.
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+16.01.2015, Zesstra
+
diff --git a/doc/sphinx/props/gildenprops/P_GLOVE_FINGERLESS.rst b/doc/sphinx/props/gildenprops/P_GLOVE_FINGERLESS.rst
new file mode 100644
index 0000000..f304503
--- /dev/null
+++ b/doc/sphinx/props/gildenprops/P_GLOVE_FINGERLESS.rst
@@ -0,0 +1,30 @@
+P_GLOVE_FINGERLESS
+==================
+
+NAME
+----
+::
+
+     P_GLOVE_FINGERLESS                     "fingerfreie_handschuhe"
+
+DEFINIERT IN
+------------
+::
+
+     /p/katzenkrieger/kkrieger.h
+
+BESCHREIBUNG
+------------
+::
+
+     So gekennzeichnete Handschuhe sind fingerlos und koennen
+     waehrend "krallenschlag" getragen werden.
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt:	P_ARMOUR_TYPE, AT_GLOVE
+
+10.Okt 2006 Gloinson
+
diff --git a/doc/sphinx/props/gildenprops/P_Z_AUTOSHIELD.rst b/doc/sphinx/props/gildenprops/P_Z_AUTOSHIELD.rst
new file mode 100644
index 0000000..6113175
--- /dev/null
+++ b/doc/sphinx/props/gildenprops/P_Z_AUTOSHIELD.rst
@@ -0,0 +1,43 @@
+P_Z_AUTOSHIELD
+==============
+
+NAME
+----
+::
+
+     P_Z_AUTOSHIELD				"z_autoshield"
+
+DEFINIERT IN
+------------
+::
+
+     /p/zauberer/wiznpc.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Property  kann man einen automatischen 
+     Schutzzauber in Zauberer-NPCs einstellen, dessen 
+     Vorhandensein dann in jeder Kampfrunde ueberprueft
+     wird, z.B. "schutz","schutzhuelle","zauberschild".
+
+BEMERKUNGEN
+-----------
+::
+
+     "zauberschild" ist ein Magisterspruch und kann nur in 
+     bestimmten Zeitabstaenden benutzt werden. Wer also als
+     Autoshield nur Zauberschild benutzt, blockiert damit
+     alle anderen Spells, solange der Magisterspruch nicht
+     gesprochen werden kann.
+     Abhilfe: _query_next_master_spell_time()  return 0; }
+
+SIEHE AUCH
+----------
+::
+
+     /p/zauberer/text/wiznpc.doku
+
+21.Okt 2006 Chagall
+
diff --git a/doc/sphinx/props/gildenprops/P_Z_INFO.rst b/doc/sphinx/props/gildenprops/P_Z_INFO.rst
new file mode 100644
index 0000000..6d9cbeb
--- /dev/null
+++ b/doc/sphinx/props/gildenprops/P_Z_INFO.rst
@@ -0,0 +1,73 @@
+P_Z_INFO
+========
+
+NAME
+----
+::
+
+     P_Z_INFO						"z_info"
+
+DEFINIERT IN
+------------
+::
+
+     /p/zauberer/wiznpc.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property muss gesetzt werden, wenn man den
+     Zauberergilden-Standard-NPC nutzt. Sie setzt die
+     Grundeinstellungen des NPCs und generiert das 
+     Newskills-Mapping. 
+
+     Die Property ist wie folgt aufgebaut:
+
+     * MIN (minimale Skillability im Bereich von 0 - 10000)
+     * MAX (maximale Skillability im Bereich von 0 - 10000)
+     * LEV (Gildenlevel)
+     * ZWEIG (Gildenzweig)
+
+BEMERKUNGEN
+-----------
+::
+
+     Fuer die Argumente LEV und ZWEIG stehen folgende Auswahl-
+     moeglichkeiten zur Verfuegung.
+
+     LEV:
+
+        Z_ANFAENGER	0
+	Z_LEHRLING	1
+	Z_MEISTER	2
+	Z_ERZMEISTER	3
+
+     ZWEIG:
+
+        ZZW_ANGRIFF		  1
+	ZZW_ABWEHR		  2
+	ZZW_ILLUSION		  4
+	ZZW_BEHERRSCHUNG	  8
+	ZZW_HELLSICHT		 16
+	ZZW_VERWANDLUNG		 32
+	ZZW_SCHWARZ		 64	INAKTIV
+	ZZW_WEISS		128
+	ZZW_ALLE		511
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_Z_INFO, ({9000, 9500, Z_ERZMEISTER, ZZW_ANGRIFF|ZZW_ABWEHR}));
+     erzeugt einen Erzmagister-PC, der alle Lehrlings- sowie die Magister und
+     Erzmagister-Sprueche Angriff und Abwehr mit 90-95% beherrscht.
+
+SIEHE AUCH
+----------
+::
+
+     /p/zauberer/text/wiznpc.doku
+
+21.Okt 2006 Chagall
+
diff --git a/doc/sphinx/props/gildenprops/P_Z_NO_MATERIAL.rst b/doc/sphinx/props/gildenprops/P_Z_NO_MATERIAL.rst
new file mode 100644
index 0000000..b01c43c
--- /dev/null
+++ b/doc/sphinx/props/gildenprops/P_Z_NO_MATERIAL.rst
@@ -0,0 +1,34 @@
+P_Z_NO_MATERIAL
+===============
+
+NAME
+----
+::
+
+     P_Z_NO_MATERIAL                     "npc_braucht_keine_kmp"
+
+DEFINIERT IN
+------------
+::
+
+     /p/zauberer/zauberer.h
+
+BESCHREIBUNG
+------------
+::
+
+     Setzt man diese Property in einem NPC, so benoetigt er fuer die
+     Sprueche der Zauberergilde keine Komponenten.
+
+BEMERKUNGEN
+-----------
+::
+
+     NIEMALS diese Property einfach so in einem Spieler setzen.
+
+SIEHE AUCH
+----------
+::
+
+21.Okt 2006 Chagall
+
diff --git a/doc/sphinx/props/gildenprops/P_Z_NO_NOCONN.rst b/doc/sphinx/props/gildenprops/P_Z_NO_NOCONN.rst
new file mode 100644
index 0000000..32b38a0
--- /dev/null
+++ b/doc/sphinx/props/gildenprops/P_Z_NO_NOCONN.rst
@@ -0,0 +1,42 @@
+P_Z_NO_NOCONN
+=============
+
+P_Z_NO_NOCON
+------------
+::
+
+NAME
+----
+::
+
+     P_Z_NO_NOCON					"no_nocon"
+
+DEFINIERT IN
+------------
+::
+
+     /p/zauberer/wiznpc.h
+
+BESCHREIBUNG
+------------
+::
+
+     Der Standardzauberergildennpc setzt SI_NO_CONSEQUENCES, damit
+     die Gildenpcs nicht den negativen Auswirkungen beim Misslingen
+     der Sprueche geschuetzt sind. Setzt man diese Property vor
+     P_Z_INFO auf 0, wird das Flag nicht gesetzt.
+
+BEMERKUNGEN
+-----------
+::
+
+     Muss vor P_Z_INFO gesetzt werden, damit es wirksam ist.
+
+SIEHE AUCH
+----------
+::
+
+     /p/zauberer/text/wiznpc.doku, P_Z_INFO
+
+21.Okt 2006 Chagall
+
diff --git a/doc/sphinx/props/gildenprops/P_Z_NO_SPELL_SUPPORT.rst b/doc/sphinx/props/gildenprops/P_Z_NO_SPELL_SUPPORT.rst
new file mode 100644
index 0000000..da7a05a
--- /dev/null
+++ b/doc/sphinx/props/gildenprops/P_Z_NO_SPELL_SUPPORT.rst
@@ -0,0 +1,41 @@
+P_Z_NO_SPELL_SUPPORT
+====================
+
+NAME
+----
+::
+
+     P_Z_NO_SPELL_SUPPORT	"zauberer_ruestung_unterstuetzt_noch_nicht"
+
+DEFINIERT IN
+------------
+::
+
+     /p/zauberer/zauberer.h
+
+BESCHREIBUNG
+------------
+::
+
+     Normalerweise unterstuetzt eine Ruestung den Zauberer, sobald sie im
+     entsprechenden Ruestungsmaster eingetragen ist. Moechte man allerdings
+     die Unterstuetzung an bestimmte Bedingungen knuepfen, z.B. das loesen
+     einer Miniquest, so kann man diese Property auf 1 setzen. Die Ruestung
+     unterstuetzt dann nicht. Um die Unterstuetzung wieder zu aktivieren,
+     setzt man die Property wieder auf 0.
+
+BEMERKUNGEN
+-----------
+::
+
+     NIEMALS diese Property einfach so in fremden Zaubererruestungen 
+     setzen. Sollte der Gildenmagier erfahren, dass z.B. ein NPC
+     einfach so die Unterstuetzung der Ruestungen ausschaltet, wird
+     diese Property wieder deaktiviert.
+
+SIEHE AUCH
+----------
+::
+
+21.Okt 2006 Chagall
+
diff --git a/doc/sphinx/props/gildenprops/kaempferboni.rst b/doc/sphinx/props/gildenprops/kaempferboni.rst
new file mode 100644
index 0000000..6d61f83
--- /dev/null
+++ b/doc/sphinx/props/gildenprops/kaempferboni.rst
@@ -0,0 +1,271 @@
+kaempferboni
+============
+
+Kaempferboni und deren Implementation
+
+-------------------------------------
+
+Bei den Kaempfern gibt es einige Properties, die, in Waffen oder Ruestungen
+gesetzt, der Kampfverlauf eines Spielers erheblich beeinflussen koennen.
+
+Zu beachten ist, dass die Abnahme von Waffen oder Ruestungen mit Kaempferboni
+allein der Balance obliegt. Der Gildenmagier der Kaempfer steht aber gerne
+mit Rat und Tat zur Seite.
+
+
+Abschnitt A
+
+
+In Waffen koennen nachfolgende, in /p/kaempfer/kaempfer.h definierten,
+Properties gesetzt werden. Die meisten davon fungieren als 'Boni' und werden
+dem Spieler auch mittels 'schaetz <waffe>' angezeigt
+
+
+1 Waffenschlagbonus - K_BRAWLING_WC (INT) - "k_brawling_wc"
+
+  Wenn die Waffe eine zusaetzlich gefaehrliche Stelle besitzt - z.B. einen
+  harten Dorn am Stielende, eine Spitze am Ruecken einer Axtklinge, Zacken
+  am Dolchgriff - kann man der Waffe einen Waffenschlagbonus geben.
+  Dies bedeutet, dass der Waffenschlag um ein paar Prozente verstaerkt wird,
+  da der Spieler natuerlich versucht, immer genau mit diesem 'feature'
+  den Waffenschlag auszufuehren (der Waffenschlag ist kurz gesagt ein
+  unerwarteter Schlag, der nicht mit dem 'normalen' Waffenende ausgefuehrt
+  wird, der Gegner wird dadurch ueberrascht -> mehr Schaden).
+  Da solch ein 'feature' doch recht auffaellig ist, sollte es in der
+  Langbeschreibung der Waffe auf jeden Fall erwaehnt werden.
+
+  Interessant zu wissen waere noch, dass Zweihandwaffen einen generellen
+  zusaetzlichen Bonus auf den Waffenschlag bekommen und dass es eine
+  Abstufung gibt, nach der die Waffengattungen die Hoehe des Basiswertes
+  gesetzt bekommen, wobei Speere den hoechsten und Messer den niedrigsten
+  besitzen
+
+  Speere - Kampfstaebe - Aexte - Keulen - Schwerter - Messer
+
+  Der max. Bonus fuer diese Property betraegt 30, wobei 1-10 -> geringer
+  Bonus, 11-20 -> guter Bonus, 21-30 -> sehr guter Bonus.
+
+  Bitte beachten ein Zweihand-Speer mit max. P_WC und max. K_BRAWLING_WC
+  haut entsprechend gut rein und sollte nur schwer zu ergattern sein, bzw.
+  noch andere Auflagen haben (ggf. unique, personalisiert, etc.)
+
+
+2 Waffenschlagschaden - K_BRAWLING_DT (STRING) - "k_brawling_dt"
+
+  Wenn die Waffe, mit der der Kaempfer einen Waffenschlag ausfuehrt, ein
+  'feature' hat, mit dem er diesen Schlag ausfuehrt, kann dieses 'feature'
+  einen anderen Waffenschlagschaden besitzen. Z.B. kann ein Schwert, welches
+  normalerweise DT_SLASH macht, besonders lange und spitze Parierstangen
+  besitzen, die vielleicht auch noch vergiftet sind. Dann kann der Magier
+  ({DT_PIERCE,DT_POISON}) setzen, so dass beim Waffenschlag immer ein
+  Mischschaden aus Stiche und Gift erfolgt.
+
+
+3 Waffenschlagsmeldung - K_BRAWLING_MSG (STRING/STRING*) - k_brawling_msg"
+
+  In diese Property kann man hineinschreiben, mit welchem Teil der Waffe
+  der Waffenschlag ausgefuehrt wird. Angenommen, es bietet sich an, mit
+  einer Waffe stets den Waffenschlag mit einem grossen Knauf am Griff
+  auszufuehren, wird schlicht und einfach "mit einem grossen Knauf am
+  Griff der Schlachtaxt" in die Property gesetzt.
+  Sollte sich bei der Programmierung ergeben, dass es sich anbietet, der
+  Waffe mehr als nur eine guenstige Stelle anzudichten mit der man den
+  Waffenschlag ausfuehren kann, so setzt man ein Array, z.B. ({"mit einem
+  grossen Knauf am Griff der Schlachtaxt","mit der breiten Seite der "
+  "Schlachtaxtklinge"}). Insgesamt ist darauf zu achten, dass die Meldungen
+  'vollstandig' sind. Das Array kann beliebige Groesse annehmen, es wird
+  dann zufaellig eine Meldung beim Schlag ausgesucht.
+
+  Es empfiehlt sich, jede Waffe mit dieser Property zu schmuecken, die
+  K_BRAWLING_WC gesetzt haben, da die Waffenschlagmeldungen damit im Kampf
+  'individualisiert' werden. In der Praxis wird es jedoch daran scheitern,
+  dass es viel zu viele alte Waffen gibt, die keiner mehr anfassen moechte.
+  Daher wird auf Standardmeldungen zurueckgegriffen, sollte diese Property
+  nicht gesetzt sein.
+
+
+4 Waffenbruchbonus - K_WEAPON_SHATTER (INT) - "k_weapon_shatter"
+
+  Waffen, die besonders fuer den Waffenbruch konstruiert wurden, koennen
+  einen Bonus einbringen, der in dieser Property angegeben wird. Natuerlich
+  eignen sich die verschiedenen Waffentypen wieder unterschiedlich gut fuer
+  einen Waffenbruch Keulen (meist aufgrund ihres Gewichts) am besten, Messer
+  am schlechtesten, alle anderen dazwischen (Axt - Schwert - Stab - Speer).
+  Dabei kriegen alle Waffen, die u.a. Schlagschaden verursachen, nochmal
+  einen kleinen Bonus obendrauf.
+
+  Der max. Bonus fuer diese Property betraegt 50, wobei 1-10 -> geringer
+  Bonus, 11-30 -> guter Bonus, 31-50 -> sehr guter Bonus.
+
+  Bei gut gelungenem Waffenbruch wird die Waffe des Gegners beschaedigt, wenn
+  die Technik sehr gut gelingt, kann es auch sein, dass dem Gegner die Waffe
+  aus der Hand geschlagen wird (der Spieler kann sie allerdings nicht
+  aufheben und der NPC zueckt sie nach ein paar Kampfrunden wieder).
+
+
+5 Bonus fuer Finte/Waffentrick - K_DISTRACTING_WEAPON (INT) -
+  "k_distracting_weapon"
+
+  Waffen, die fuer den Gegner aufgrund ihrer Bauweise besonders irritierend
+  sein koennen, koennen einen Bonus fuer Finte und Waffentrick haben. Dabei
+  wird der Gegner bei einer Finte bzw. einem Waffentrick NOCH mehr verwirrt,
+  als er es ohnehin schon nur durch die angewandte Technik wird.
+  Ein gutes Beispiel hierfuer ist z.B. der Kriegshamster ein Hamster, der
+  auf einem Holzstab aufgespiesst ist, sollte fuer den Gegner schon SEHR
+  irritierend sein ;).
+  Die Waffengattung hat nur wenig Einfluss auf Finte/Waffentrick.
+
+  Der max. Bonus fuer diese Property betraegt 50, wobei 1-10 -> geringer
+  Bonus, 11-30 -> guter Bonus, 31-50 -> sehr guter Bonus.
+
+
+6 Todesstossbonus - K_CRITICAL_HIT (INT) - "k_critical_hit"
+
+  Man stelle sich eine Waffe mit besonders spitzer, langer Klinge vor oder
+  eine magische Waffe, die dem geschwaechten Gegner die Seele entreisst.
+  Diese Eigenschaften verleihen dem Spieler beim Todesstoss einen
+  entsprechenden Bonus von bis zu 100%.
+
+  Es ist moeglich, dass ein und dasselbe 'feature' sowohl dem Waffenschlag
+  als auch dem Todesstoss den Bonus stellt, z.B. zwei Hiebklingen auf dem
+  Klingenruecken einer grossen Axt. Auch dies sollte man deutlich aus der
+  Langbeschreibung herauslesen koennen.
+
+  Der max. Bonus fuer diese Property betraegt 100, wobei 100 eine Verdopplung
+  der P_WC beim Todesstoss bedeutet!
+  Ansonsten bedeutet 1-20 -> geringer Bonus, 21-60 -> guter Bonus,
+  61-100 -> sehr guter Bonus.
+
+
+7 Waffenwurfbonus - K_THROWING_WEAPON (INT) - "k_throwing_weapon"
+
+  Wenn eine Waffe besonders gut zum Werfen geeignet ist, z.B. ein Wurfdolch,
+  dann kann diese Property gesetzt werden. Natuerlich ist der Grundwert wieder
+  von der Waffengattung abhaengig. Es gilt, dass man Messer und Speere
+  grundsaetzlich am besten werfen - und dabei gut Schaden machen - kann, am
+  schlechtesten schneiden Keulen und Kampfstaebe ab.
+
+  Der max. Bonus fuer diese Property betraegt 50, wobei 1-20 -> geringer
+  Bonus, 21-40 -> guter Bonus, 31-50 -> sehr guter Bonus.
+
+  Zu beachten ist hierbei, dass ein sehr hoher Bonus nur bei Waffen mit etwas
+  geringerer P_WC vergeben werden sollte. Ein reines Wurfmesser ist nunmal im
+  normalen Kampf nicht die gefaehrlichste aller Waffen (speziell
+  ausbalanciert, keinen richtigen Griff, etc.).
+  Natuerlich kann es einen Wurfspeer mit max. P_WC und sehr hohem
+  Waffenwurfbonus geben, allerdings mit den ueblich hohen Restriktionen.
+
+
+8 KO-Schlag-Bonus - K_KO (INT) - "k_ko"
+
+  Waffen, die besonders fuer einen KO-Schlag geeignet sind, koennen einen
+  Bonus mit dieser Property bekommen. Eine entsprechende Waffe koennte z.B.
+  ein lederumwickelter Pruegel sein, denn man will den Gegner ja nur KO
+  schlagen und nicht gleich toeten.
+
+  Der max. Bonus fuer diese Property betraegt 50, wobei 1-20 -> geringer
+  Bonus, 21-30 -> guter Bonus, 31-50 -> sehr guter Bonus.
+
+
+9 Kein Waffenschaerfen - K_NO_HONING (INT) - "k_no_honing"
+
+  Wenn eine Waffe aus irgendeinem Grund nicht geschaerft werden kann oder
+  darf, muss man diese Property auf 1 setzen.
+  Eine Erklaerung dafuer sollte in der P_LONG bzw. P_INFO erfolgen.
+
+
+Abschnitt B
+
+
+Die beiden Properties, P_EFFECTIVE_AC und P_EFFECTIVE_WC, welche in
+<combat.h> definiert sind, sind eigentlich nur dazu da, um Ruestungen und
+Waffen, die eine DefendFunc() bzw. HitFunc() besitzen, korrekt vom Spieler
+einschaetzen lassen zu koennnen.
+
+Das Kaempferspellbook verwendet diese Properties darueberhinaus wie folgt
+
+
+1 Schutzboni in Waffen - P_EFFECTIVE_AC (INT) - "effective_ac"
+
+  Ist diese Property in einer Waffe gesetzt, geht das Kaempferspellbook
+  davon aus, dass diese Waffe mehr oder weniger die Faehigkeit besitzt,
+  auch wie eine Ruestung schuetzen zu koennen. Da man eine Waffe aber nicht
+  anziehen, sondern nur vor sich hertragen kann, kann auch der max.
+  Ruestungsschutz einer Waffe nur gleich dem max. Ruestungsschutz eines
+  Schildes entsprechen.
+  Eine gesetzte P_EFFECTIVE_AC in einer Waffe wird dem Spieler als mehr
+  oder weniger gute 'Paradewaffe' im 'schaetz' angezeigt und geht sowohl bei
+  der Waffenparade als auch beim Block als Bonus mit ein.
+
+  Z.B. koennte ein leichtes Schwert, was aufgrund seiner Bauweise mehr fuer
+  den defensiven Kampf ausgelegt ist (extralange Parierstangen, verstaerkter
+  Handschutz im Griffbereich, ...) wie ein maessiges Schild wirken. Die
+  Vorteile liegen auf der Hand der Spieler bekommt verstaerkten Schutz,
+  kann aber weiterhin eine Zweihandwaffe fuehren.
+
+  Der max. Bonus fuer diese Property betraegt 40, wobei 1-20 -> geringer
+  Bonus, 21-30 -> guter Bonus, 31-40 -> sehr guter Bonus.
+
+  Zu beachten ist hier, dass sehr gute Parierwaffen mit P_EFFECTIVE_AC > 30
+  moeglichst deutlich unter der max. WC liegen sollten.
+
+  Anmerkungen
+  Eine gesetzte P_EFFECTIVE_AC in einem Schild kann den Bonus fuer die
+  Schildparade nach oben oder unten beeinflussen. Moechte man ein Schild
+  herstellen, welches speziell bei der Schildparade der Kaempfer besser
+  als 'normal' schuetzt, sollte man hier einen Wert eintragen, der deutlich
+  groesser als die P_AC des Schildes ist.
+
+  Eine gesetzte P_EFFECTIVE_AC in einer anderen Ruestung hat nur den Nutzen,
+  auf deren erhoehten (und nicht sofort sichtbaren) Verteidigungswert
+  hinzuweisen, der durch eine DefendFunc() realisiert wird.
+
+
+2 Angriffsboni in Ruestungen - P_EFFECTIVE_WC (INT) - "effective_wc"
+
+  Fuer die Kaempfer koennen folgende Ruestungstypen modifiziert werden
+  AT_TROUSERS (Hosen), AT_HELMET (Kopfbedeckung), AT_BOOT (Fusskleidung),
+  AT_ARMOUR (Koerperruestung), AT_SHIELD (Schilde).
+  Ist in einer dieser Typen P_EFFECTIVE_WC gesetzt, so macht diese Ruestung
+  bei einem Angriff mit einer Spezialattacke (Kniestoss, Kopfstoss, Fusstritt,
+  Ellbogenschlag und Schildstoss) entsprechend mehr bzw. weniger Schaden als
+  ohne diese Property. Eine entsprechende Begruendung fuer eine Verstaerkung
+  oder Schwaechung sollte auch hier fuer den Spieler offensichtlich sein
+  (Dornen am Schild, verstaerkter Kniebereich, Zacken am Helm, etc.).
+
+  Wenn man der Ruestung einen Bonus geben moechte, muss man darauf achten,
+  dass P_EFFECTIVE_WC hoeher ist als die P_AC der Ruestung! Sollte
+  P_EFFECTIVE_WC niedriger als P_AC sein, wird dennoch P_EFFECTIVE_WC als
+  Angriffswert genommen. Dies stellt natuerlich eine Schwaechung der
+  Spezialattacke dar. Moeglicherweise ist aber genau das gewollt, wenn eine
+  Ruestung, die sehr gut schuetzt, nur geringen Kaempferbonus aufweisen soll.
+
+  Beispiel ein Schild aus Hartgummi kann recht gut Schlaege aller Art
+  abfangen (-> P_AC 35). Will der Kaempfer jedoch einen Schildstoss damit
+  machen, fehlt ihm aufgrund der Beschaffenheit die Wucht, eher daempft es
+  den Schildstoss noch ein wenig (-> P_EFFECTIVE_WC 25).
+
+  Der Maximalwert fuer die P_EFFECTIVE_WC bei Kaempfern ist der jeweils
+  doppelte maximale P_AC-Wert (s. 'man ruestungen').
+
+  Die Angabe eines Schadenstyps (P_DAM_TYPE) in einer Ruestung kann dann
+  sinnvoll sein, wenn bei der Spezialattacke ein spezieller Schaden gemacht
+  werden soll. Beispielsweise sollten Flammenstiefel logischerweise DT_FIRE
+  und DT_BLUDGEON oder DT_PIERCE bei einem Kampftritt verursachen. Es MUSS
+  (logischerweise) mindestens ein physikalischer Schadenstyp enthalten sein.
+  Wird kein Schadenstyp angegeben, wird auf Standardtypen zurueckgegriffen.
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+::
+
+SIEHE AUCH
+----------
+::
+
+     Waffen:     P_WC, P_TOTAL_WC, P_EFFECTIVE_WC, HitFunc()
+     Ruestungen: P_AC, P_TOTAL_AC, P_EFFECTIVE_AC, DefendFunc()
+     Files:      /std/weapon.c, /std/weapon/combat.c
+     Balance:    waffen, ruestungen, properties
+
+
+26.10.2012, Gabylon
+
diff --git a/doc/sphinx/props/obsolete/P_BALANCED_WEAPON.rst b/doc/sphinx/props/obsolete/P_BALANCED_WEAPON.rst
new file mode 100644
index 0000000..f982030
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_BALANCED_WEAPON.rst
@@ -0,0 +1,58 @@
+P_BALANCED_WEAPON
+=================
+
+********************* UNGENUTZTE PROPERTY *****************************
+* Diese Property wird von der Mudlib NICHT ausgewertet und kann       *
+* als veraltet gelten.                                                *
+* Momentan ist auch keine Gilde bekannt, die mehr macht, als sie      *
+* auszugeben.                                                         *
+***********************************************************************
+
+NAME
+----
+::
+
+        P_BALANCED_WEAPON  "balanced_weapon"
+
+DEFINIERT IN
+------------
+::
+
+        /sys/weapon.h
+
+BESCHREIBUNG
+------------
+::
+
+        Die Property gibt an, ob eine Waffe ausbalanciert ist oder nicht.
+        Die beiden moeglichen Werte sind logischerweise:
+
+                WP_BALANCED       balanciert
+                WP_UNBALANCED     unbalanciert
+
+        Die WP_* sind ebenfalls in <weapon.h> definiert.
+
+BEISPIELE
+---------
+::
+
+        a) Eine ausbalancierte Waffe ist z.B. ein Kampfstab.
+
+            SetProp(P_BALANCED_WEAPON,WP_BALANCED);
+
+        b) Eine nicht ausbalancierte Waffe ist z.B. eine Keule.
+
+            SetProp(P_BALANCED_WEAPON,WP_UNBALANCED);
+
+SIEHE AUCH
+----------
+::
+
+        P_TECHNIQUE, /std/weapon/combat.c
+
+LETZTE AeNDERUNG
+----------------
+::
+
+15.02.2009, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_DEFAULT_INFO.rst b/doc/sphinx/props/obsolete/P_DEFAULT_INFO.rst
new file mode 100644
index 0000000..4b553c9
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_DEFAULT_INFO.rst
@@ -0,0 +1,50 @@
+P_DEFAULT_INFO
+==============
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+
+NAME
+----
+::
+
+    P_DEFAULT_INFO                "default_info"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Default-Antwort eines Npc, wenn er auf das Schluesselwort durch den
+    Spieler kein AddInfo parat hat.
+
+BEMERKUNG
+---------
+::
+
+    Diese Property sollte nicht mehr benutzt werden. Stattdessen bitte
+    AddInfo(DEFAULT_INFO,...) verwenden.
+    Dem in dieser Prop angegeben String wird immer der Name des Npc
+    vorausgestellt. Will man dies verhindern, muss man sie ueberschreiben.
+
+BEISPIEL
+--------
+::
+
+    SetProp(P_DEFAULT_INFO,"bohrt gelangweilt in der Nase.\n");
+
+SIEHE AUCH
+----------
+::
+
+    AddInfo
+
+
+17.08.2010, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_EXTRA_LOOK.rst b/doc/sphinx/props/obsolete/P_EXTRA_LOOK.rst
new file mode 100644
index 0000000..4a649a0
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_EXTRA_LOOK.rst
@@ -0,0 +1,57 @@
+P_EXTRA_LOOK
+============
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte benutzt sie NICHT mehr, sondern  *
+* stattdessden AddExtraLook().                                        *
+***********************************************************************
+
+NAME
+----
+::
+
+	P_EXTRA_LOOK			"extralook"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/description.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt einen String. Sie wird entweder in Lebewesen
+	direkt oder in Objekten gesetzt wird, die im Besitz von Lebewesen
+	sein koennen.
+	Diese Strings erscheinen dann zusaetzlich in der Langbeschreibung
+	des Lebewesens bzw. des Besitzers (wenn das Objekt sich direkt im
+	 Lebewesen befindet, jedoch nicht in einem Behaelter im Lebewesen).
+	Fuer den Zeilenumbruch muss man selbst sorgen.
+
+BEISPIEL
+--------
+::
+
+	Ein Spieler hat eine Pfeife im Mund. In dieser Pfeife setzt man z.B.
+	in der Funktion zum Pfeife Rauchen folgendes:
+	  SetProp(P_EXTRA_LOOK,break_string(
+	 this_player()->Name(WER)+" ist ganz umnebelt.",78);
+
+BEMERKUNG
+---------
+::
+
+  BITTE NICHT MEHR BENUTZEN!
+
+SIEHE AUCH
+----------
+::
+
+	long(), /std/living/description.c, /std/player/base.c
+  AddExtraLook(), RemoveExtraLook()
+
+
+13.05.2007, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_LAST_KILLER.rst b/doc/sphinx/props/obsolete/P_LAST_KILLER.rst
new file mode 100644
index 0000000..1485e96
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_LAST_KILLER.rst
@@ -0,0 +1,36 @@
+P_LAST_KILLER
+=============
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet und wird bald aus der Mudlib entfernt.  *
+***********************************************************************
+
+NAME
+----
+::
+
+    P_LAST_KILLER                 "last_killer"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Letzter Moerdes des Wesens.
+     Diese Property wurde nur in Spielern gesetzt und auch dann nicht immer.
+     Bitte stattdessen P_KILLER abfragen, welche in NPC und Spielern gesetzt
+     wird.
+
+SIEHE AUCH
+----------
+::
+
+    P_KILLER, die()
+
+05.09.2008, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_LAST_PEACE_TIME.rst b/doc/sphinx/props/obsolete/P_LAST_PEACE_TIME.rst
new file mode 100644
index 0000000..06195f4
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_LAST_PEACE_TIME.rst
@@ -0,0 +1,42 @@
+P_LAST_PEACE_TIME
+=================
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet und wird bald aus der Mudlib entfernt.  *
+***********************************************************************
+
+PROPERTY
+--------
+::
+
+	P_LAST_PEACE_TIME	"last_peace_time"
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property gibt an, wann zuletzt versucht wurde, einen NPC zu
+	befrieden. Bitte nach Moeglichkeit nur lesend verwenden. Des weiteren
+	wird sie nur im ueblichen Verhalten von QueryPacify gesetzt, und nur
+	dann, wenn P_ACCEPT_PEACE nicht gesetzt ist.
+
+SIEHE AUCH
+----------
+::
+
+	QueryPacify, P_ACCEPT_PEACE
+
+LETZTE AENDERUNG
+----------------
+::
+
+	2004-03-17, 14:30 von Humni
+
+	
+
diff --git a/doc/sphinx/props/obsolete/P_LOG_FILE.rst b/doc/sphinx/props/obsolete/P_LOG_FILE.rst
new file mode 100644
index 0000000..34cf3d7
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_LOG_FILE.rst
@@ -0,0 +1,68 @@
+P_LOG_FILE
+==========
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property wird nicht mehr ausgewertet.                         *
+***********************************************************************
+
+NAME
+----
+::
+
+    P_LOG_FILE                   "log_file"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt einen String auf einen Filenamen. 
+
+    Werden zu dem Objekt (Raum, Monster, ...) Fehlermeldungen abgesetzt, 
+    werden diese in das angegebene File umgeleitet. Die Eintragung in
+    die per Default fuer Fehlermeldungen vorgesehenen Dateien erfolgt
+    nicht.
+
+BEMERKUNGEN
+-----------
+::
+
+    P_LOG_FILE wird ausgewertet wie log_file().
+
+    Das heisst, es wird AUF JEDEN FALL nach /log geschrieben!
+
+    Direkt in /log kann NICHT geschrieben werden, es muss also ein 
+    Unterverzeichnis mit Eurem Magiernamen vorhanden sein.
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_LOG_FILE,"tilly_log");          // FALSCH, es wuerde versucht, 
+                                                 das File /log/tilly_log 
+                                                 anzulegen
+    SetProp(P_LOG_FILE,"/log/tilly_log");     // FALSCH, es wuerde versucht, 
+                                                 das File /log/log/tilly_log
+                                                 anzulegen
+    SetProp(P_LOG_FILE,"/d/ebene/tilly_log"); // FALSCH, s.o.
+
+    SetProp(P_LOG_FILE,"tilly/tilly_log");    // RICHTIG!
+
+    Im letzten Beispiel werden alle Eintraege in das File tilly_log ge-
+    schrieben, das sich im Verzeichnis /log/tilly/ befindet.
+
+    Das Unterverzeichnis /tilly in /log muss zuvor angelegt werden.
+
+SIEHE AUCH
+----------
+::
+
+    P_LOG_INFO, write_file(), log_file(),
+
+Letzte Aenderung: 13.09.04 Tilly@MorgenGrauen
+
diff --git a/doc/sphinx/props/obsolete/P_NEXT_SPELL_TIME.rst b/doc/sphinx/props/obsolete/P_NEXT_SPELL_TIME.rst
new file mode 100644
index 0000000..d61643f
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_NEXT_SPELL_TIME.rst
@@ -0,0 +1,48 @@
+P_NEXT_SPELL_TIME
+=================
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+
+NAME
+----
+::
+
+    P_NEXT_SPELL_TIME             "next_spell"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+    Wann kann das naechste Mal gezaubert werden?
+    Dies ist eine globale Spruchermuedung/-Sperre.
+    Flexiblere Sperren koennen mittels SetSpellFatigue/CheckSpellFatigue()
+    verwaltet werden.
+
+    Diese Property ist keine echte Property, sondern liefert nur das
+    Ergebnis von von CheckSpellFatigue() zurueck bzw. ruft beim Setzen
+    SetSpellFatigue(<spruchsperre>, 0) auf.
+    Diese Prop sollte _nicht_ mittels Query- oder Setmethoden manupuliert
+    werden, da sonst Inkonsistenzen zum Ergebnis von CheckSpellFatigue()
+    auftreten.
+
+SIEHE AUCH
+----------
+::
+
+    SetSpellFatigue(L), CheckSpellFatigue(L)
+    spruchermuedung
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2010, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_READ_MSG.rst b/doc/sphinx/props/obsolete/P_READ_MSG.rst
new file mode 100644
index 0000000..c1fcfca
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_READ_MSG.rst
@@ -0,0 +1,57 @@
+P_READ_MSG
+==========
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+
+NAME
+----
+::
+
+    P_READ_MSG                "read_msg"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property ist veraltet. Ihre Funktion wird von
+    AddReadDetail(SENSE_DEFAULT, ...) uebernommen.
+
+    
+
+    Hier koennen Informationen gespeichert werden, die beim Lesen
+    des Objektes ausgegeben werden.
+
+     
+
+    Fuer das Identifizieren des zu lesenden Objektes wird der gleiche
+    Mechanismus benutzt wie fuer lesbare und andere Details.
+
+    Die Benutzung von process_string() ist in dieser Prop nicht mehr erlaubt.
+
+BEISPIEL
+--------
+::
+
+    AddId(({"rolle", "schriftrolle"}));
+    SetProp(P_READ_MSG,
+       "Du oeffnest die Rolle und liest: LOREM IPSUM ...\n");
+
+     
+
+SIEHE AUCH
+----------
+::
+
+    Details:   AddReadDetail(), RemoveReadDetail(), P_READ_DETAILS
+    Sonstiges: break_string()
+
+09.12.2012, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_TECHNIQUE.rst b/doc/sphinx/props/obsolete/P_TECHNIQUE.rst
new file mode 100644
index 0000000..ec42c36
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_TECHNIQUE.rst
@@ -0,0 +1,69 @@
+P_TECHNIQUE
+===========
+
+********************* UNGENUTZTE PROPERTY *****************************
+* Diese Property wird von der Mudlib NICHT ausgewertet und kann       *
+* als veraltet gelten.                                                *
+* Momentan ist auch keine Gilde bekannt, die mehr macht, als sie      *
+* auszugeben.                                                         *
+***********************************************************************
+
+NAME
+----
+::
+
+	P_TECHNIQUE				"technique"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/weapon.h
+
+BESCHREIBUNG
+------------
+::
+
+        Die Technik(en), mit denen eine Waffe im Kampf eingesetzt werden
+        kann. Folgende Techniken stehen zur Verfuegung:
+
+                TQ_STROKE       Streichtechnik
+                TQ_THRASH       Schlagtechnik
+                TQ_THRUST       Stosstechnik
+                TQ_WHIP         Peitschtechnik
+
+        Die Techniken sind ebenfalls in <weapon.h> definiert und auf der
+        man-page 'techniken' naeher erlaeutert.
+
+BEMERKUNGEN
+-----------
+::
+
+        Man kann einer Waffe eine oder mehrere Techniken zuweisen.
+
+BEISPIELE
+---------
+::
+
+        a) Eine Waffe, die nur mit einer Peitschtechnik eingesetzt wird,
+           also typischerweise eine Peitsche, aber auch ein Morgenstern:
+
+            SetProp(P_TECHNIQUE,TQ_WHIP);
+
+        b) Eine Waffe, die sowohl mit der Schlag- als auch der Stosstechnik
+           eingesetzt wird, also z.B. eine Hellebarde:
+
+            SetProp(P_TECHNIQUE,({TQ_THRASH,TQ_THRUST}));
+
+SIEHE AUCH
+----------
+::
+
+        techniken, P_BALANCED_WEAPON, /std/weapon/combat.c
+
+LETZTE AeNDERUNG
+----------------
+::
+
+15.02.2009, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_TMP_ATTACK_HOOK.rst b/doc/sphinx/props/obsolete/P_TMP_ATTACK_HOOK.rst
new file mode 100644
index 0000000..4b57f96
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_TMP_ATTACK_HOOK.rst
@@ -0,0 +1,95 @@
+P_TMP_ATTACK_HOOK
+=================
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+P_TMP_ATTACK_HOOK
+
+NAME
+----
+::
+
+    P_TMP_ATTACK_HOOK             "attack_hook"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mittels dieser Property koennen die Attacken eines Livings ggf.
+     abgebrochen werden noch bevor Waffen oder Skills zum ausgewertet
+     wurden.
+
+     Es wird an dem Living die Property als mindestens 3-elementiges Array:
+     ({zeitpunkt, objekt, methode, ...})
+     gesetzt und die Methode 'methode' wird dann waehrend des Attack() des
+     Lebewesens in 'objekt' aufgerufen, solange time()<'zeitpunkt'.
+
+     Der Methode wird als Parameter der Gegner uebergeben.
+
+     Gibt die Methode 0 als Rueckgabewert zurueck, wird die Attacke sofort
+     kommentarlos abgebrochen.
+
+BEMERKUNGEN
+-----------
+::
+
+     - Bitte das neuere Hooksystem (s. Manpage std/hooks) benutzen.
+     - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
+       Property auf 0 gesetzt
+     - vor dem Setzen immer auf die Existenz eines gueltigen Hooks
+       pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
+       im Code anderer und ist andererseits unfair gegenueber ihnen
+
+BEISPIELE
+---------
+::
+
+     *** der Spieler erhaelt eine Verwundung, die ihn manchmal behindert ***
+     if(!pointerp(tmp=TP->QueryProp(P_TMP_ATTACK_HOOK)) ||
+        sizeof(tmp)<3 || tmp[0]<=time()) {
+       TP->SetProp(P_TMP_ATTACK_HOOK,
+		   ({time()+3600, this_object(), "test_hurt"}));
+     ...
+
+     // die entsprechende Methode, die bei jedem Angriff ueber Attack()
+     // gerufen wird ...
+     int test_hurt(object enemy) {
+
+       // mit 10% Chance generell und 20% Chance bei groesseren Gegnern
+       // bricht der Angriff ab ... previous_object() ist natuerlich
+       // der Angreifer
+       if(!random(10) ||
+          (enemy->QueryProp(P_SIZE)>previous_object()->QueryProp(P_SIZE) &&
+           !random(5)) {
+
+          tell_object(previous_object(),
+            "Deine Wunde schmerzt dich zu sehr um anzugreifen.\n");
+          tell_room(environment(previous_object()),
+            previous_object()->Name(WER,1)+" zuckt vor Schmerzen zusammen.\n",
+            ({previous_object()}));
+          return 0;
+       }
+
+       // ansonsten geht der Angriff weiter
+       return 1;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Angriff:	Attack(L)
+     Schutz:    Defend(L)
+     Verwandt:  InternalModifyAttack(L), P_TMP_ATTACK_MOD	
+     Hooks:	P_TMP_DIE_HOOK, P_TMP_MOVE_HOOK, P_TMP_DEFEND_HOOK
+     neue Hooks: std/hooks
+
+08.12.2008, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_TMP_ATTACK_MOD.rst b/doc/sphinx/props/obsolete/P_TMP_ATTACK_MOD.rst
new file mode 100644
index 0000000..8a1f138
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_TMP_ATTACK_MOD.rst
@@ -0,0 +1,134 @@
+P_TMP_ATTACK_MOD
+================
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+P_TMP_ATTACK_MOD
+
+NAME
+----
+::
+
+     P_TMP_ATTACK_MOD              "attack_mod"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mittels dieser Property koennen die Attacken eines Livings temporaer
+     veraendert werden.
+
+     Es wird an dem Living die Property als mindestens 3-elementiges Array
+     ({zeitpunkt, objekt, methode, ...})
+     gesetzt und die Methode 'methode' wird dann waehrend des Attack() des
+     Lebewesens in 'objekt' aufgerufen, solange time()<'zeitpunkt'.
+
+     Der Methode wird beim Aufruf ein Kopie des Mappings uebergeben, in dem
+     die bisherigen Werte des Angriffes vermerkt sind.
+     Aufbau von Mapping 'ainfo':
+     ([ SI_ENEMY :           object Angreifer,			(-> Defend)
+        SI_SPELL :           0/1/array Spellparameter,		(-> Defend)
+        P_WEAPON :           - oder Waffe,
+        SI_SKILLDAMAGE_MSG:  string Angriffsmeldungsende an Raum,
+        SI_SKILLDAMAGE_MSG2: string Angriffsmeldungsende an Kaempfende,
+        SI_SKILLDAMAGE:      int Schaden in Zehntel HP (Skills bis auf Rasse
+			     drin!)				(-> Defend),
+        SI_SKILLDAMAGE_TYPE: string/string* Schadenstypen,	(-> Defend)
+        P_WEAPON_TYPE:       string Waffentyp (combat.h),
+        P_WC:		     - oder int WC der Waffe/Hand,
+        P_NR_HANDS:	     - oder int Hands der Waffe/Hand,
+     ]);
+
+     Gibt die Methode:
+     - 0 oder kein Mapping zurueck, fuehrt das zum Abbruch der Attacke
+       -> da inzwischen Waffen abgefragt wurden, koennen schon Meldungen
+          von diesen ausgegeben worden sein
+     - ein leeres Mapping ( ([]) ) zurueck, fuehrt das zu keiner Modifikation
+     - ein Mapping mit veraenderten Werten zurueck, werden diese in das
+       Angriffsmapping kopiert
+       Die geaenderten Werte werden teilweise von SkillResTransfer() in
+       den eigentlichen Angriff uebernommen.
+
+BEMERKUNGEN
+-----------
+::
+
+     - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
+       Property auf 0 gesetzt
+     - vor dem Setzen immer auf die Existenz eines gueltigen Modifiers
+       pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
+       im Code anderer und ist andererseits unfair gegenueber ihnen
+
+BEISPIELE
+---------
+::
+
+     *** ein besonder heisser Segen modifiziert die Attacken des Spielers ***
+     int action_segen() {
+       ...
+       mixed *tmp;
+
+       // pruefen, ob nicht ein anderer Modifier existiert
+       if(!pointerp(tmp=TP->QueryProp(P_TMP_ATTACK_MOD)) ||
+          sizeof(tmp)<3 || tmp[0]<=time()) {
+
+         object wield;
+         wield=TP->QueryProp(P_WEAPON);
+
+         write(break_string(
+           "Der Priester der Flamme weiht "+
+           (wield?wield->name(WEN,1):"deine Haende")+".", 78));
+
+         // setzen des Modifiers .. 30-40 Sekunden gueltig
+         TP->SetProp(P_TMP_ATTACK_MOD,
+	              ({time()+30+random(10), this_object(), "modfun"}));
+        } else ...
+        ...
+      return 1;
+     }
+
+     // die eigentlich Methode, die waehrend des Angriffs gerufen wird
+     mapping modfun(mapping ainfo) {
+       mapping ret;
+
+       // Returnwert ist immer ein Mapping, damit die Attacke weitergeht
+       ret=m_allocate(0,1);
+
+       // magische Waffen oder Sprueche werden nicht verbessert
+       if(ainfo[P_WEAPON_TYPE]!=WT_MAGIC) {
+         // sonst Verbesserungen ... Feuer addieren ...
+         ret[SI_SKILLDAMAGE_TYPE]=(ainfo[SI_SKILLDAMAGE_TYPE]||({}))+
+				({DT_FIRE});
+	 // ... und bei Waffe Meldungen anpassen
+         if(ainfo[P_WEAPON]) {
+           ret[SI_SKILLDAMAGE_MSG]=
+             " mit sengendem "+ainfo[P_WEAPON]->name(RAW);
+           ret[SI_SKILLDAMAGE_MSG2]=
+             " mit sengendem "+ainfo[P_WEAPON]->name(RAW);
+         }
+       }
+
+       return ret;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Angriff:	Attack(L)
+     Schutz:    Defend(L)
+     Verwandt:  InternalModifyAttack(L)
+		P_TMP_ATTACK_HOOK
+		P_TMP_DEFEND_HOOK
+     Sonstiges: SkillResTransfer(L)
+     Hooks:	P_TMP_DIE_HOOK, P_TMP_MOVE_HOOK
+
+10.Feb 2005 Gloinson
+
diff --git a/doc/sphinx/props/obsolete/P_TMP_DEFEND_HOOK.rst b/doc/sphinx/props/obsolete/P_TMP_DEFEND_HOOK.rst
new file mode 100644
index 0000000..5d9ae39
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_TMP_DEFEND_HOOK.rst
@@ -0,0 +1,131 @@
+P_TMP_DEFEND_HOOK
+=================
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+P_TMP_DEFEND_HOOK
+
+NAME
+----
+::
+
+     P_TMP_DEFEND_HOOK             "defend_hook"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mittels dieser Property koennen die Abwehren eines Livings temporaer
+     veraendert werden.
+
+     Es wird an dem Living die Property als mindestens 3-elementiges Array
+     ({zeitpunkt, objekt, methode, ...})
+     gesetzt und die Methode 'methode' wird dann waehrend des Defend() des
+     Lebewesens in 'objekt' aufgerufen, solange time()<'zeitpunkt'.
+
+     Der Methode werden die Parameter der Defend() uebergeben:
+     int dam, mixed dam_type, mixed spell, object enemy
+     - spell ist definitiv ein Mapping - ein an Defend() uebergebener
+       int-Wert wurde aequivalent umgesetzt.
+     - dam_type ist definitiv ein Array von Schadenswerten oder einem Wert
+
+     Zudem findet der Aufruf der Methode nach dem Abarbeiten der P_DEFENDERS
+     statt, diese koennen also weitere Modifikationen vorgenommen haben.
+
+     Gibt die Funktion:
+     - 0 zurueck, wird Defend() abgebrochen (und damit der Schaden voellig
+       abgefangen) - nur noch die Flucht wird geprueft
+     - ein 3-elementiges Array ({schaden, schadenstypen, spell}) zurueck,
+       werden diese Werte in der Defend() an Stelle der uebergebenen Werte
+       verwendet
+     - weder noch zurueck, wird das Ergebnis ignoriert und die Defend laeuft
+       regulaer weiter
+
+BEMERKUNGEN
+-----------
+::
+
+     - Bitte das neuere Hooksystem (s. Manpage std/hooks) benutzen.
+     - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
+       Property auf 0 gesetzt
+     - vor dem Setzen immer auf die Existenz eines gueltigen Hooks
+       pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
+       im Code anderer und ist andererseits unfair gegenueber ihnen
+
+BEISPIEL
+--------
+::
+
+     *** ein gruener Schutzzauber ***
+     // Setzen der Prop
+     ...
+     tmp=TP->QueryProp(P_TMP_DEFEND_HOOK);
+
+     // ein etwas ausfuehrlicher Check, ob wir ueberschreiben koennen,
+     // Existenz && Gueltigkeit
+     if(pointerp(tmp) && sizeof(tmp) && intp(tmp[0]) && (time()<tmp[0]))
+      write("Der Zauber klappt nicht!\n");
+     else {
+      // der Zauber gilt eine Stunde
+      TP->SetProp(P_TMP_DEFEND_HOOK,({time()+3600,TO,"abwehrfun");
+      write("Ein Zauber legt sich auf dich.\n");
+     }
+     ...
+
+     // die gerufene Methode
+     mixed abwehrfun(int dam, string* dam_type, mapping spell, object en) {
+      // keine rekursiven Schaeden abfangen ... mindestens ein magischer
+      // muss auch dabei sein
+      if((!mappingp(spell) || !spell[SP_RECURSIVE]) &&
+         sizeof(filter(dam_type,MAGICAL_DAMAGE_TYPES))) {
+
+       // mit 10% Whkeit schuetzt der Zauber total
+       if(!random(10)) {
+        tell_object(previous_object(),
+          "Dein Zauber gleisst rund um dich gruen auf.\n");
+        tell_room(environment(previous_object()), break_string(
+          previous_object()->Name(WESSEN)+" Haut gleisst rund um "+
+          previous_object()->QueryPronoun(WEN)+" gruen auf.",78),
+          ({previous_object()}));
+
+        // manchmal geht der Zauber dabei endgueltig kaputt
+        if(!random(10)) previous_object()->SetProp(P_TMP_DEFEND_HOOK, 0);
+
+        return 0;			// volles Abfangen des Angriffs
+       }
+
+       // der Zauber schuetzt auf jeden Fall immer ein bischen
+       tell_object(previous_object(),
+         "Dein Zauber flackert rund um dich gruen auf.\n");
+       tell_room(environment(previous_object()), break_string(
+         previous_object()->Name(WESSEN)+" Haut flackert rund um "+
+         previous_object()->QueryPronoun(WEN)+" gruen auf.",78),
+         ({previous_object()}));
+       dam=(7+random(2))*dam/10;	// Schaden reduzieren
+
+       return(({dam, dam_type, spell}));
+      }
+
+      // der Zauber schuetzt dann gar nicht ...
+      return 1;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Angriff:	Attack(L)
+     Schutz:    Defend(L)
+     Verwandt:	InternalModifyDefend(L), P_TMP_ATTACK_MOD
+     Hooks:	P_TMP_DIE_HOOK, P_TMP_MOVE_HOOK, P_TMP_ATTACK_HOOK
+     neue Hooks: std/hooks
+
+08.12.2008, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_TMP_DIE_HOOK.rst b/doc/sphinx/props/obsolete/P_TMP_DIE_HOOK.rst
new file mode 100644
index 0000000..616da96
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_TMP_DIE_HOOK.rst
@@ -0,0 +1,91 @@
+P_TMP_DIE_HOOK
+==============
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+P_TMP_DIE_HOOK
+
+NAME
+----
+::
+
+    P_TMP_DIE_HOOK                "die_hook"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mittels dieser Property kann der Tod eines Livings abgewendet werden.
+
+     Es wird an dem Living die Property als mindestens 3-elementiges Array
+     ({zeitpunkt, objekt, methode, ...})
+     gesetzt und die Methode 'methode' wird dann waehrend des die() des
+     Lebewesens in 'objekt' aufgerufen, solange time()<'zeitpunkt'.
+     Bei Geistern wird der Hook nicht gerufen.
+
+     Der Methode wird ein int uebergeben, ob das Living Opfer von Gift
+     (P_POISON) war.
+
+     Gibt die Funktion einen Wert != 0 zurueck, wird die() sofort abgebrochen
+     und das Living stirbt nicht.
+
+BEMERKUNGEN
+-----------
+::
+
+    - Bitte das neuere Hooksystem (s. Manpage std/hooks) benutzen.
+    - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
+      Property auf 0 gesetzt
+    - vor dem Setzen immer auf die Existenz eines gueltigen Hooks
+      pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
+      im Code anderer und ist andererseits unfair gegenueber ihnen
+
+BEISPIELE
+---------
+::
+
+     *** ein besonderer Giftschutz .. wirkt beim Tod ***
+     // pruefen, ob nicht ein anderer Modifier existiert
+     if(!pointerp(tmp=TP->QueryProp(P_TMP_DIE_HOOK)) ||
+        sizeof(tmp)<3 || tmp[0]<=time()) {
+       TP->SetProp(P_TMP_DIE_HOOK,
+	           ({time()+120+random(10), this_object(), "prevent_die"}));
+
+     // die gerufene Methode
+     int prevent_die(int poison) {
+       int ret;
+
+       if(poison) {
+         tell_object(previous_object(),
+           "Ein Zauber reinigt im Moment des Todes dein Blut!\n");
+         tell_object(environment(previous_object()),
+           previous_object()->Name(WER,1)+" wird von Lichtern umhuellt.\n",
+           ({previous_object()}));
+
+         ret=1;
+       }
+
+       // wir helfen nur einmal ... und ein Tod vernichtet die Hilfe auch
+       previous_object()->SetProp(P_TMP_DIE_HOOK, 0);
+
+       return ret;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Tod:	die(L)
+     Sonstiges: P_POISON, P_KILLS, P_GHOST
+     Hooks:	P_TMP_MOVE_HOOK, P_TMP_ATTACK_HOOK, P_TMP_DEFEND_HOOK
+     neue Hooks: std/hooks
+
+08.12.2008, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_TMP_MOVE_HOOK.rst b/doc/sphinx/props/obsolete/P_TMP_MOVE_HOOK.rst
new file mode 100644
index 0000000..2b9212e
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_TMP_MOVE_HOOK.rst
@@ -0,0 +1,65 @@
+P_TMP_MOVE_HOOK
+===============
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+
+NAME
+----
+::
+
+    P_TMP_MOVE_HOOK             "move_hook"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mindestens 3-elementiges Array ({zeitpunkt, objekt, funktion, ...}).
+    Die Funktion wird im 'objekt' mit den gleichen Parametern wie move()
+    nach der Abfrage auf P_NO_TPORT aufgerufen, wenn der 'zeitpunkt'
+    noch nicht ueberschritten ist. Wenn die Funktion etwas anderes als ein
+    5-elementiges Array ({dest, methods, direction, textout, textin})
+    oder -1 zurueckgibt, wird move() normal ausgefuehrt, ansonsten werden die
+    5 move-Parameter durch die Array-Eintraege ersetzt bzw. wird bei einem
+    Rueckgabewert von -1 das move() abgebrochen. In letzterem Fall ist
+    die Funktion dafuer verantwortlich, eine entspr. Meldung an den
+    Spieler auszugeben!
+
+HINWEIS
+-------
+::
+
+    Falls man einem Spieler einen Move-Hook setzt, ist es ratsam, im
+    Move-Hook zu pruefen, ob das Spielerobjekt nach Abarbeitung der Hook-
+    Funktion noch lebt. Ansonsten wird ein doppeltes move() ausgefuehrt:
+    in den Todesraum und direkt wieder zurueck zur Leiche.
+
+BEMERKUNGEN
+-----------
+::
+
+     - Bitte das neuere Hooksystem (s. Manpage std/hooks) benutzen.
+     - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
+       Property auf 0 gesetzt
+     - vor dem Setzen immer auf die Existenz eines gueltigen Hooks
+       pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
+       im Code anderer und ist andererseits unfair gegenueber ihnen
+
+SIEHE AUCH
+----------
+::
+
+     Bewegung:	move(L), NotifyMove(), PreventMove()
+     Hooks:	P_TMP_DIE_HOOK, P_TMP_DEFEND_HOOK, P_TMP_ATTACK_HOOK
+     neue Hooks: std/hooks
+
+
+08.12.2008, Zesstra
+
diff --git a/doc/sphinx/props/skill_info_liste.rst b/doc/sphinx/props/skill_info_liste.rst
new file mode 100644
index 0000000..dedaaff
--- /dev/null
+++ b/doc/sphinx/props/skill_info_liste.rst
@@ -0,0 +1,345 @@
+skill_info_liste
+================
+
+SI_*
+----
+::
+
+DEFINIERT IN
+------------
+::
+
+    /sys/newskills.h
+
+BESCHREIBUNG
+------------
+::
+
+    Die folgende Liste der SI-Typen ist grob nach Gueltigkeit fuer Skills
+    und Spells sortiert.
+
+    
+
+    Anwendungsorte der SI_-Werte sind:
+    - /std/living/combat und von dort gerufene Skills (Kampf)
+    - /std/gilden_ob und in Gilden lernbare Spells/Skills
+    - /std/spellbook und von Spellbooks ausgefuehrte Spells
+    - /std/living/life und von dort gerufene Skills (Alkohol)
+    - /std/shells/* und entsprechende Rassenskills
+
+    Im Skillsystem unter /std/living/skills wird vor auf Informationen
+    aus dem Teil #1 Ruecksicht genommen. Einige dieser Werte
+    werden auch permanent im Spieler gespeichert (wie zB die
+    SI_SKILLABILITY).
+
+AKTUELLE LISTE: (5. Oktober 2011)
+ #1 Skills und Spells:
+    SI_SKILLFUNC: string
+     Beinhaltet den Namen der Methode, die die eigentliche Funktionalitaet
+     des Skills/Spells implementiert.
+     Falls nicht angegeben, wird bei Spells durch UseSpell() das Verb, das
+     der Spieler eingegeben hat, als Spell-Methodenname angenommen.
+     Im Gildenobjekt kann hier abweichend von Spell-Namen stehen, wie die
+     Spellfunktion im Spellbook heisst.
+
+    SI_CLOSURE: closure
+     Optimiert den Zugriff fuer den internen Gebrauch, indem die gefundene
+     Spell/Skillfunktion darin direkt gespeichert wird und so lange gueltig
+     ist, bis das/die Objekt(e)/Closure(s) zerstoert sind.
+     Kann theoretisch auch fuer externe Skills durch (Autoload-)Objekte
+     benutzt werden.
+
+    SI_SKILLABILITY: int
+     Faehigkeit, den Spell/Skill zu benutzen. Normal ist von
+     -MAX_ABILITY bis MAX_ABILITY.
+
+    SI_SKILLDAMAGE_TYPE: string*
+     Art des Schadens eines Angriffs: siehe Schadenstypen in /sys/combat.h
+
+    SI_SKILLDAMAGE_MSG: string
+     Meldung anstatt der Waffe oder Haende-Meldung.
+    SI_SKILLDAMAGE_MSG2: string
+     Meldung anstatt der Waffe oder Haende-Meldung fuer den Raum.
+
+    SI_INHERIT: string
+     Enthaelt den Namen des Skills/Spells, von dem geerbt wird. Das
+     bedeutet einerseits, das LearnSkill() auch diesen uebergeordneten
+     Skill beeinflusst und andererseits, dass bei Skills auch dieser
+     uebergeordnete Skill im Rahmen einer Skill-Anwendung gerufen wird.
+
+    SI_DIFFICULTY: int / [Spells: mixed]
+     Schwierigkeit eines Skills/Spells. Beeinflusst die jeweils oberen
+     Schranken fuer das Lernen eines Skills/Spells in Abhaengigkeit 
+     von Spielerlevel.
+     Wenn in einem Spell-Info-Mapping kein Wert steht wird bei Spells
+     automatisch SI_SPELLCOST genommen, der Wert im Spell-Info-Mapping
+     geht beim Lernen aber immer vor Parametern.
+    FACTOR(SI_DIFFICULTY): int / mixed
+    OFFSET(SI_DIFFICULTY): int / mixed
+     Nur fuer Spellbooks/Spells. Der mixed-Parameter kann Funktionen
+     enthalten. Siehe unten bei SI_SPELLCOST.
+
+    SI_LASTLIGHT: int
+     Zeitpunkt, bis wann der Standardskills SK_NIGHTVISION den Spieler
+     sehen laesst.
+
+    SI_TESTFLAG: int
+     Wenn gesetzt, dann soll der Skill nicht genutzt, sondern nur getestet
+     werden, ob er erfolgreich waere. Entspricht also in etwa dem Aufruf
+     von SpellSuccess() in Spellbooks, wird aber bei UseSkill() als
+     Skill-Parameter uebergeben.
+     Der Skill muss entsprechend implementiert sein!
+
+    SI_GUILD: string
+     Angabe der Gilde, aus der der Skill stammt. Sinnvoll, wenn der Skill
+     nicht aus der aktuellen P_GUILD stammt. Fuer generelle Skills/Spells
+     zB waere das "ANY".
+     Gilt nicht fuer Spells!
+
+    SI_ENEMY: object
+     Aktuelles Feindesobjekt, wird bei Skill-Anwendung aus dem Kampf heraus
+     von std/living/combat.c an den Skill uebergeben.
+     Beispiel: Standardwaffenskills, SK_MAGIC_DEFENSE, SK_MAGIC_ATTACK,
+               SK_TWOHANDED, SK_SPELL_DEFEND, SK_INFORM_DEFEND und
+               SK_DEFEND_OTHER.
+
+    SI_FRIEND: object
+     Zu verteidigendes Freundesobjekt, wird bei Skill-Anwendung aus dem
+     Kampf heraus von std/living/combat.c an den Skill uebergeben.
+     Beispiele: SK_INFORM_DEFEND und SK_DEFEND_OTHER.
+
+    SI_MAGIC_TYPE: string*
+     Enthaelt ein Array der Magietypen, die zum Einsatz kommen. Die Angabe
+     geschieht zB im Spellbook und beeinflusst SpellDefend().
+
+    SI_LAST_USE: int (eventuell obsolet)
+     Letzte Nutzung des Skills.
+
+    
+
+    SI_LEARN_PROB: int (eventuell obsolet)
+     Lernwahrscheinlichkeit.
+
+    SI_SKILLDURATION: int
+     Dauer des Skills/Spells. Momentan nicht allzu verbreitet in Nutzung.
+
+ #2 nur fuer Spells:
+    SI_SPELLBOOK: string
+     Kann direkt das enthaltende Spellbook fuer einen Spell enthalten.
+
+    SM_RACE: mapping
+      Mapping, das als Key die Rasse und als Value ein Mapping X
+      enthaelt. Dieses Mapping X wird direkt zu sinfo hinzugefuegt und
+      ueberschreibt damit bei Bedarf Defaultwerte durch rassenspezifische
+      Werte.
+
+    SI_SPELLCOST: int / mixed
+    FACTOR(SI_SPELLCOST): int / mixed
+    OFFSET(SI_SPELLCOST): int / mixed
+     Beinhaltet die Werte, die fuer die Berechnung der Spellkosten
+     zustaendig sind.
+     Dabei gilt: Realkosten = OFFSET(COST) + (COST * FACTOR(COST))/100
+     Die einzelnen Eintraege koennen anstatt eines fixen Wertes auch den
+     Verweis auch eine Funktion in Form von Closure/Methodenname/Array mit
+     Objekt/Objektname und Methodenname enthalten. Siehe dazu auch
+     execute_anything().
+
+    SI_TIME_MSG: string
+     Meldung, die dem Spieler mitteilt, dass er noch nicht wieder einen
+     Spell casten kann. Falls dieser Eintrag nicht gesetzt ist, wird
+     ein Standardtext ausgegeben.
+
+    SI_SP_LOW_MSG: string
+     Meldung, die dem Spieler mitteilt, dass er zu wenige
+     Konzentrationspunkte besitzt, um den Spell zu casten. Falls dieser
+     Eintrag nicht gesetzt ist, wird ein Standardtext ausgegeben.
+
+    SI_PREPARE_MSG: string
+     Meldung, die dem Spieler ausgegeben werden soll, wenn er einen Spell
+     vorbereitet. Ansonsten wird ein Standardtext ausgegeben.
+
+    SI_PREPARE_BUSY_MSG: string
+     Meldung, die dem Spieler ausgegeben werden soll, wenn er schon diesen
+     Spell vorbereitet. Ansonsten wird ein Standardtext ausgegeben.
+
+    SI_PREPARE_ABORT_MSG: string
+     Meldung, die dem Spieler ausgegeben werden soll, wenn er die
+     Vorbereitung dieses Spells durch einen anderen Spell unterbricht.
+     Ansonsten wird ein Standardtext ausgegeben.
+
+    SI_NOMAGIC: int
+     Wert zwischen 0 und 100 (oder mehr), der gegen die P_NOMAGIC-Wirkung
+     eines Raumes wirkt.
+     Je hoeher der Wert ist, desto unwahrscheinlicher ist es, dass ein
+     Raum den Spell durch Antimagie stoert. Ein Raum sollte nur Werte
+     zwischen 0 und 100 gesetzt haben. Ist der Wert des Raums groesser
+     als der hier angegeben, dann blockiert er Magie mit einer gewissen
+     eben seiner angegebenen Wahrscheinlichkeit.
+
+    SI_NOMAGIC_MSG: string
+     Meldung, die bei Fehlschlag durch P_NOMAGIC des Raumes ausgegeben
+     wird. Ansonsten wird ein Standardtext ausgegeben.
+
+      
+
+    SI_SPELLFATIGUE: int / mixed
+    FACTOR(SI_SPELLFATIGUE): int / mixed
+    OFFSET(SI_SPELLFATIGUE): int / mixed
+     Werte, die fuer die Berechnung der Wieder-Cast-Zeit benutzt werden.
+     Die Berechnung und die moeglichen Angaben (Closure etc.) sind
+     identisch zu SI_SPELLCOST.
+     Das Spellbook gibt bei Nicht-Wieder-Bereitschaft SI_TIME_MSG aus.
+
+    SI_X_SPELLFATIGUE: mapping mit ([string key: int val])
+     Werte, die fuer die Berechnung der Wieder-Cast-Zeit benutzt werden.
+     Spellbook-Casten: Mapping wird durch Aufruf von CheckSpellFatigue(<key>)
+     am Caster gefiltert. Nur wenn das resultierende Mapping leer ist (kein
+     <key> hat einen gueltigen Fatigue-Eintrag), ist Spell castbar, sonst
+     Ausgabe von SI_TIME_MSG.
+     Nach Spellbook-Casten: Setzen der Fatigue fuer alle <val> > 0 mit <key>.
+
+    SI_SKILLLEARN: int / mixed
+    FACTOR(SI_SKILLLEARN): int / mixed
+    OFFSET(SI_SKILLLEARN): int / mixed
+     Werte, die fuer die Berechnung der Lerngeschwindigkeit benutzt
+     werden, normalerweise pro A_INT/2 je 0.01% (also 1 von MAX_ABILITY).
+     Die Berechnung und die moeglichen Angaben (Closure etc.) sind
+     identisch zu SI_SPELLCOST.
+
+    SI_LEARN_ATTRIBUTE: mapping
+     Mapping, welches die Attribute, nach denen gelernt werden soll
+     als Keys enthaelt. Der Value legt die Gewichtung fest, denn bei
+     mehreren Attributen wird ein Mittelwert gebildet.
+     Der Normalfall entspraeche ([A_INT: 1]) fuer SI_LEARN_ATTRIBUTE.
+
+    SI_NO_LEARN
+     Wenn man (temporaer!) nicht will, dass dieser Skill gelernt wird.
+     Muss von den Spellbooks beachtet werden.
+     Sollte niemals im Spieler abgespeichert werden. Oder permanent in
+     Gilde/Spellbook gesetzt sein. Sondern im Laufe einesr Nutzung in der
+     jew. Kopie von sinfo gesetzt werden, die gerade genutzt wird.
+
+    
+
+     SI_SKILLARG: string
+     Beinhaltet den Text, den der Spieler nach dem Spellkommando eingegeben
+     hat. Z.B. stuende bei "krallenschlag ork 2" der Text "ork 2" im
+     Parameter.
+
+    SI_SKILLRESTR_USE: mixed
+     Einschraenkungen fuer das Nutzen des Spells.
+     Wird normalerweise direkt im Spellbook fuer den Spell eingetragen.
+     Die einzelnen Moeglichkeiten werden in der manpage zu
+     "check_restrictions" erlaeutert.
+
+     
+
+    SI_SKILLRESTR_LEARN: mixed
+     Einschraenkungen fuer das Lernen des Spells.
+     Wird normalerweise direkt im Gildenobjekt fuer den Spell
+     eingetragen.
+     Die einzelnen Moeglichkeiten werden in der manpage zu
+     "check_restrictions" erlaeutert.
+
+    SI_SKILLINFO: string
+    SI_SKILLINFO_LONG: string
+     Beschreibung des Spells. Wird im Gildenobjekt eingetragen und
+     SI_SKILLINFO wird von SkillListe angezeigt.
+
+    SI_SKILLDAMAGE: int / mixed
+    FACTOR(SI_SKILLDAMAGE): int / mixed
+    OFFSET(SI_SKILLDAMAGE): int / mixed
+     Werte, die fuer die Schadenshoehenberechnung des Spells benutzt
+     werden (random ueber den Gesamtwert normalerweise).
+     Die Berechnung und die moeglichen Angaben (Closure etc.) sind
+     identisch zu SI_SPELLCOST.
+
+    SI_SKILLDAMAGE_BY_ROW
+     Ein Mapping mit Boni fuer den Angriff aus bestimmten Kampfreihen.
+     Funktioniert nur bei Verwendung von TryDefaultAttackSpell-Spells
+     aus dem Spellbook.
+     Der Key steht fuer eine bestimmte Reihe, sein Wert fuer den
+     randomisierten Bonus fuer Lebewesen, die aus dieser Reihe casten.
+    OFFSET(SI_SKILLDAMAGE_BY_ROW)
+     Ein Mapping mit fixem Wert fuer Row-Boni im Kampf.
+
+     Beispiel: AddSpell("feuerball", 20,
+                        ([SI_SKILLDAMAGE:50,
+                          OFFSET(SI_SKILLDAMAGE):100,
+                          SI_SKILLDAMAGE_BY_ROW:([2:40,3:20}),
+                          OFFSET(SI_SKILLDAMAGE_BY_ROW):([2:20]), ...
+     gibt
+      Reihe 1: random(50)+100;
+      Reihe 2: random(50)+100+random(40)+20
+      Reihe 3: random(50)+100+random(20)
+     ACHTUNG: Hier gilt nicht die selbe Struktur wie bei SI_SPELLCOST!
+
+    SI_SPELL: mapping
+     Dieser Eintrag enthaelt verschiedene Unterwerte, die den Spell
+     gerade fuer Angriffs-Spells genauer beschreiben. Siehe Defend()
+     fuer eine Beschreibung der verschiedenen Eintraege (die so auch
+     in das Spellbook uebernommen werden koennen).
+
+    SI_COLLATERAL_DAMAGE: int
+     Hiermit kann man einen Prozentwert von SI_SKILLDAMAGE (inklusive
+     Offsets und Factor) fuer Kollateralschaden an Freunden im definierten
+     Bereich eines Flaechenspells (TryGlobalAttackSpell()) angeben.
+     10 bedeutet bei OFFSET(SI_SKILLDAMAGE)=100 zB 10% von 100 = 10 = 1 LP
+     an mit reduce_hit_points() verursachtem Schaden.
+
+    
+
+    SI_NUMBER_ENEMIES, SI_NUMBER_FRIENDS: int
+     Wird von TryGlobalAttackSpell() im Spell gesetzt und enthaelt die
+     Anzahl der im angegebenen Bereich befindlichen Feinde und Freunde.
+     Ist dementsprechend von informativem Nutzen fuer den Angegriffenen
+     und das Spellbook NACH Aufruf von TryGlobalAttackSpell().
+
+    
+
+    SI_DISTANCE, SI_WIDTH, SI_DEPTH: int
+     Limitiert die Entfernung, Tiefen und Breite der Wirkung eines
+     TryGlobalAttackSpell()
+
+    SI_SKILLHEAL: int
+     Konvention fuer Spells im Spellbook, dort den Heilwert zu hinterlegen,
+     hat keine Auswirkungen unter /std/.
+
+    SI_USR: mixed
+     Fuer selbst definierte Infos, spellbookabhaengig.
+
+    SI_PREPARE_TIME: int
+     Dauer der Zeit fuer zu praeparierende Spells.
+
+    SI_ATTACK_BUSY_MSG: string
+     Meldung, die dem Spieler mitteilt, dass er schon zu beschaeftigt
+     mit einem Angriff ist, um einen Spell zu casten. Falls dieser
+     Eintrag nicht gesetzt ist, wird  ein Standardtext ausgegeben.
+
+    SI_NO_ATTACK_BUSY: int
+     Enthaelt als Flag NO_ATTACK_BUSY_QUERY wenn der Spell NICHT wie
+     eine Spezialwaffe die Aktionen einschraenkt. Siehe P_ATTACK_BUSY.
+
+    SI_ATTACK_BUSY_AMOUNT: int
+     Menge des P_ATTACK_BUSY fuer diesen Spell. Falls dieser Wert nicht
+     gesetzt ist, aber auch SI_NO_ATTACK_BUSY nicht mit
+     NO_ATTACK_BUSY_QUERY ausgezeichnet ist wird 1 angenommen.
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkill, QuerySkillAbility
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung
+    * Properties:   P_NEWSKILLS
+    Spellbook:      UseSpell, Learn, SpellSuccess
+    Gilden:         gilden-doku
+    Kampf:          Defend
+
+7. Nov 2012 Gloinson
+
diff --git a/doc/sphinx/sefun/CountUp.rst b/doc/sphinx/sefun/CountUp.rst
new file mode 100644
index 0000000..cbc27ef
--- /dev/null
+++ b/doc/sphinx/sefun/CountUp.rst
@@ -0,0 +1,41 @@
+CountUp()
+=========
+
+FUNKTION
+--------
+::
+
+	public varargs string CountUp( string *s, string sep, string lastsep );
+
+ARGUMENTE
+---------
+::
+
+	*s
+	  Array von Strings mit Woertern.
+  sep
+    String, der zwischen den Woerten in der Aufzaehlung eingefuegt wird.
+    Standard: ", "
+  lastsep
+    String, der zwischen dem vorletzten und letzten Element eingefuegt wird.
+    Standard: " und "
+
+BESCHREIBUNG
+------------
+::
+
+	Die Woerter Wort_1 bis Wort_n aus dem Stringaray werden als
+	Aufzaehlung in der Form
+	  Wort_1<sep>Wort_2, ... Wort_n-1<lastsep>Wort_n
+	zusammengesetzt. Mit Standardwerten also:
+	  Wort_1, Wort_2, ... Wort_n-1 und Wort_n
+
+RUeCKGABEWERT
+-------------
+::
+
+	String als Aufzaehlung der einzelnen Woerter.
+
+
+15.03.2008, Zesstra
+
diff --git a/doc/sphinx/sefun/_notify_fail.rst b/doc/sphinx/sefun/_notify_fail.rst
new file mode 100644
index 0000000..e72d457
--- /dev/null
+++ b/doc/sphinx/sefun/_notify_fail.rst
@@ -0,0 +1,35 @@
+_notify_fail()
+==============
+
+simul_efun::_notify_fail(E)
+
+FUNKTION
+--------
+::
+
+     void _notify_fail(string str)
+
+ARGUMENTE
+---------
+::
+
+     str
+	umgebrochener Fehlermeldungsstring
+
+BESCHREIBUNG
+------------
+::
+
+     Identisches Verhalten zu notify_fail(E), bis darauf, dass bei bereits
+     gesetzter Fehlermeldung _keine_ neue Fehlermeldung gesetzt wird.
+
+SIEHE AUCH
+----------
+::
+
+     notify_fail(E), P_ACTUAL_NOTIFY_FAIL
+     add_action(E), AddCmd(L), AddAction(L),
+     query_verb(E)
+
+24 Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/sefun/break_string.rst b/doc/sphinx/sefun/break_string.rst
new file mode 100644
index 0000000..b1a92bb
--- /dev/null
+++ b/doc/sphinx/sefun/break_string.rst
@@ -0,0 +1,112 @@
+break_string()
+==============
+
+FUNKTION
+--------
+::
+
+    string break_string(string str)
+    string break_string(string str, int width)
+    string break_string(string str, int width, string indent)
+    string break_string(string str, int width, int space)
+    string break_string(string str, int width, string indent, int flags)
+    string break_string(string str, int width, int space, int flags)
+
+ARGUMENTE
+---------
+::
+
+    str    - umzubrechender String
+    width  - optional: maximale Zeilenlaenge (default 78)
+    indent - optional: String, der vor jeder umgebrochenen Zeile erscheint
+    space  - optional: Anzahl der Leerzeichen vor jeder umgebrochenen Zeile
+    flags  - optional: hiermit laesst sich das Verhalten von break_string()
+             aendern; moegliche Flags siehe Punkt 'Beschreibung'
+
+BESCHREIBUNG
+------------
+::
+
+    In der ersten Form wird der String 'str' durch Einfuegen von "\n" so um-
+    gebrochen, dass bei einer anschliessenden Ausgabe keine Zeile laenger
+    als 'width' Zeichen ist. Eventuell schon in 'str' vorhandene "\n" werden
+    dabei vorher entfernt.
+
+    Gibt man zusaetzlich noch einen String 'indent' an, so wird dieser vor
+    jede der umgebrochenen Zeilen gesetzt.
+
+    Analog wird bei der Angabe der Zahl 'space' ein String mit 'space' Leer-
+    zeichen vor jede umgebrochene Zeile gesetzt.
+
+    Zusaetzlich gibt es folgende optionale Flags, die man beliebig kombinieren
+    kann:
+
+        BS_LEAVE_MY_LFS  -  schon im Text vorhandene "\n" werden beibehalten
+        BS_SINGLE_SPACE  -  doppelte Leerzeichen sowie Leerzeichen nach Zeilen-
+                            umbruechen werden entfernt
+        BS_BLOCK         -  der Text wird im Blocksatz formatiert
+        BS_NO_PARINDENT  -  bei Blocksatz mit vorgegebenen Zeilenumbruechen
+                            (BS_BLOCK|BS_LEAVE_MY_LFS) werden Zeilen nach "\n"
+                            normalerweise mit einem Leerzeichen begonnen.
+                            Um das Einfuegen des fuehrenden Leerzeichens zu
+                            unterdruecken, muss BS_NO_PARINDENT angegeben werden
+        BS_INDENT_ONCE   -  die erste Zeile des Textes wird mit vorangestelltem
+                            'indent' ausgegeben; alle folgenden Zeilen bekommen
+                            einen Leerstring vorangestellt
+        BS_PREPEND_INDENT - der Ident wird dem Text vorangestellt sofern der 
+                            Indent + Text laenger als eine Zeile ist. Der Text
+			    wird um ein Leerzeichen eingerueckt, was mittels
+                            BS_NO_PARINDENT verhindert werden kann.
+
+RUECKGABEWERT
+-------------
+::
+
+    Der umgebrochene Text.
+
+    Laufzeit-Fehler, wenn der Indent laenger ist als die vorgegebene Breite.
+
+BEISPIELE
+---------
+::
+
+    write(break_string("Dies ist ein laengerer Text. Nur so als Beispiel.",27));
+
+        => Dies ist ein laengerer
+           Text. Nur so als Beispiel.
+
+    write(break_string("Mit indent sieht das so aus", 30, "Wargon sagt: "));
+
+        => Wargon sagt: Mit indent sieht
+           Wargon sagt: das so aus
+
+    write(break_string("Mit indent sieht das so aus", 30, "Wargon sagt: ",
+                        BS_INDENT_ONCE));
+
+        => Wargon sagt: Mit indent sieht
+                        das so aus
+
+    write(break_string("Mit Leerzeichen sieht das so aus", 30, 2));
+
+        =>   Mit Leerzeichen sieht das so
+             aus...
+
+    write(break_string("Ich will es\naber vorformatiert!",60,
+                        "Wargon sagt: ", BS_LEAVE_MY_LFS));
+
+        => Wargon sagt: Ich will es
+           Wargon sagt: aber vorformatiert!
+
+    write(break_string("Ich will es\naber vorformatiert!",30,
+                        "Wargon sagt: ", BS_PREPEND_INDENT));
+
+        => Wargon sagt:
+            Ich will es aber 
+            vorformatiert!
+
+SIEHE AUCH
+----------
+::
+
+    senderwiederholung
+
diff --git a/doc/sphinx/sefun/broken_count_bits.rst b/doc/sphinx/sefun/broken_count_bits.rst
new file mode 100644
index 0000000..06f2bc8
--- /dev/null
+++ b/doc/sphinx/sefun/broken_count_bits.rst
@@ -0,0 +1,48 @@
+broken_count_bits()
+===================
+
+SYNOPSIS
+--------
+::
+
+        int count_bits (string str)
+
+DESTRIPTION
+-----------
+::
+
+        Count the number of set bits in bitstring <str> and return the number
+        as result.
+
+NOTE
+----
+::
+
+	Bitstrings store 6 Bits per Character. Consequently, the functions for
+	manipulating bitstrings (see below) do generally not work on most
+	strings. An exception is this (s)efun. It accepts strings which are
+	not correct bitstrings (like getuid(PL)), BUT: It does NOT work
+	correctly on them! The results are NOT the correct number of bits!
+	Additionally, count_bits() in LDMud rejects such strings with an error
+	instead of returning false results, as all the other functions for
+	bitstrings do as well.
+
+EXAMPLES
+--------
+::
+
+        string s;
+
+        s = set_bit("", 3); s = set_bit(s, 15);
+
+        count_bits(s) --> returns 2
+
+SEE ALSO
+--------
+::
+
+        clear_bit(E), set_bit(E), test_bit(E), next_bit(E), last_bit(E),
+        or_bits(E), xor_bits(E), invert_bits(E), copy_bits(E)
+
+19.12.2006, Zesstra
+
diff --git a/doc/sphinx/sefun/cindent.rst b/doc/sphinx/sefun/cindent.rst
new file mode 100644
index 0000000..6285087
--- /dev/null
+++ b/doc/sphinx/sefun/cindent.rst
@@ -0,0 +1,22 @@
+cindent()
+=========
+
+SYNOPSIS
+--------
+::
+
+        int cindent(string file)
+
+DESCRIPTION
+-----------
+::
+
+        Indent a file using an LPC-enhanced version of the GNU indent
+	program, which is modelled after the Berkeley indent(1).
+
+SEE ALSO
+--------
+::
+
+	ed(E)
+
diff --git a/doc/sphinx/sefun/debug_info.rst b/doc/sphinx/sefun/debug_info.rst
new file mode 100644
index 0000000..6303471
--- /dev/null
+++ b/doc/sphinx/sefun/debug_info.rst
@@ -0,0 +1,508 @@
+debug_info()
+============
+
+DEPRECATED
+----------
+::
+
+SYNOPSIS
+--------
+::
+
+        #include <debug_info.h>
+
+        mixed debug_info(int flag)
+        mixed debug_info(int flag, mixed arg)
+        mixed debug_info(int flag, mixed arg2, mixed arg3)
+
+BESCHREIBUNG
+------------
+::
+
+        Sammelt entsprechend den Angaben in <flag> gewisse intere Debuginfos
+        des Treibers. <flag> kann dabei folgende in debug_info.h definierte
+        Werte enthalten:
+
+        DINFO_OBJECT   (0): Angezeigt werden Informationen zum in <arg>
+            spezifizierten Objekt, zum Beispiel heart_beat,
+            enable_commands etc. Die Funktion liefert 0 zurueck.
+
+        DINFO_MEMORY   (1): Angezeigt werden Informationen zu
+            Speicherbelegung und -ausnutzung des in <arg> spezifizierten
+            Objekts, zum Beispiel Anzahl Strings, Variablen, geerbte Files,
+            Objektgroesse etc. Die Funktion liefert 0 zurueck.
+
+        DINFO_OBJLIST  (2): debug_info() liefert Objekte aus der globalen
+            Objektliste. Wenn <arg2> nicht angegeben wird, wird das erste
+            Element aus der Objektliste gelierfert, wenn <arg2> eine Zahl n
+            ist, das n-te Element. Ist <arg2> ein Objekt, werden die
+            nachfolgenden Objekte in der Objektliste zurueck geliefert.
+            Das optionale Argument <arg3> bezeichnet die Anzahl zurueck
+            gelieferter Objekte. Wenn <arg3> 0 ist, wird ein einzelnes
+            Objekt zurueck geliefert. Wenn <arg3> eine Zahl m enthaelt, wird
+            ein Array mit hoechstens m Elementen zurueck geliefert. Auf
+            diese Weise kann ein Array mit saemtlichen Objekten im Spiel
+            erzeugt werden, wenn fuer <arg3> __INT_MAX__ gesetzt wird (eine
+            entsprechende maximale Arraygroesse vorausgesetzt).
+
+        DINFO_MALLOC   (3): Entsprichend der Eingabe des 'malloc'-Kommandos.
+            Es muessen keine weiteren Argumente angegeben werden.
+
+        DINFO_STATUS   (4): Angezeigt wird die Statusinformation des Drivers.
+            Optional kann das Argument <arg> die Werte 0, "tables", "swap",
+            "malloc" oder andere vom Driver akzeptierte Argumente enthalten.
+            Das Resultat ist ein druckbarer String, der die Statusinformation
+            enthaelt, oder 0, wenn ein ungueltiges Argument angegeben wurde.
+
+        DINFO_DUMP     (5): Die durch <arg2> angeforderte Information wird
+            in ein File geschrieben, das man mit <arg3> angeben kann. Wird
+            <arg3> nicht angegeben, wird eine Standarddatei verwendet.
+            debug_info() ueberprueft mittels master->valid_write(), ob es
+            das File schreiben kann. Falls bereits eine entsprechende Datei
+            existiert, wird diese ueberschrieben. Die Funktion liefert 1
+            bei Erfolg, 0 sonst.
+
+            <arg2> == "objects": liefert Informationen ueber alle Objekte im
+                Spiel und schreibt diese standardmaessig in die Datei
+                /OBJ_DUMP, dem valid_write() wird 'objdump' uebergeben.
+                Die Datei enthaelt fuer jedes Objekt eine Zeile, in der
+                jeweils folgende Informationen aufgelistet sind:
+                  - Name des Objekts (object_name)
+                  - Groesse im Speicher, gemeinsamer genutzter Speicher nur
+                    einmal gezaehlt
+                  - Groesse im Speicher, wenn es keine gemeinsam genutzte
+                    Daten geben wuerde
+                  - Anzahl Referenzen
+                  - 'HB', wenn das Objekt einen heart_beat hat, sonst nichts.
+                  - der Name der Umgebung oder '--', wenn das Objekt keine
+                    Umgebung hat
+                  - in Klammern die Anzahl der durch das Objekt verursachten
+                    Verarbeitungsschritten (execution ticks)
+                  - der Swap-Status:
+                      > nichts, wenn das Objekt nicht geswapt wurde
+                      > 'PROG SWAPPED', wenn nur das Programm geswapt wurde
+                      > 'VAR SWAPPED', wenn nur die Variablen geswapt wurden
+                      > 'SWAPPED', wenn beide geswapt wurden
+                  - die Zeit, zu der das Objekt geladen wurde.
+
+            <arg2> == "destructed": liefert Informationen ueber alle
+                zerstoerten Objekte und schreibt diese standardmaessig in
+                die Datei /DEST_OBJ_DUMP, dem valid_write() wird 'objdump'
+                uebergeben. Die Datei enthaelt fuer jedes Objekt eine Zeile,
+                in der jeweils folgende Informationen aufgelistet sind:
+                  - Name des Objekts (object_name)
+                  - Anzahl der Referenzen
+                  - 'NEW', wenn das Objekt in diesem Verarbeitungszyklus
+                    zerstoert wurde, nichts wenn es bereits fruehre zerstoert
+                    worden war.
+
+            <arg2> == "opcodes": liefert Nutzungsinformationen ueber die
+                opcodes. Standardmaessig wird in die Datei /OPC_DUMP
+                geschrieben. valid_write() wird 'opcdump' uebergeben.
+
+            <arg2> == "memory": liefert eine Liste aller allokierten
+                Speicherbloecke.
+                Standardmaessig wird in die Datei /MEMORY_DUMP geschrieben;
+                valid_write() wird 'memdump' uebergeben.  Existiert die
+                Datei bereits, werden die neuen Daten angehaengt.
+                Wenn der Allokator einen Speicherabzug nicht unterstuetzt,
+                wird keine Datei geschrieben und immer 0 zurueckgegeben.
+                Diese Funktion ist am nuetzlichsten wenn der Allokator
+                mit MALLOC_TRACE und MALLOC_LPC_TRACE kompiliert
+                wurde.
+
+
+        DINFO_DATA    (6): Liefert Rohdaten ueber gewisse, durch <arg2>
+            spezifizierte Aspekte des Treibers. Das Resultat der Funktion ist
+            ein Array mit der Information oder 0, falls <arg2> keinen
+            gueltigen Wert enthalten hat.
+            Ist <arg3> eine Zahl, die kleiner ist als die Anzahl Elemente im
+            Resultat-Array, liefert die Funktion nur das entsprechende
+            Element zurueck.
+            Zulaessige Werte fuer <arg2> sind: DID_STATUS, DID_SWAP und
+            DID_MALLOC.
+
+            <arg2> == DID_STATUS (0): Liefert die "status" und "status table"
+                Information. Folgende Indizes sind definiert:
+                  - int DID_ST_BOOT_TIME
+                        die Zeit (time()), zu der das Mud gestartet wurde
+                  - int DID_ST_ACTIONS
+                  - int DID_ST_ACTIONS_SIZE
+                        die Anzahl und Groesse im Speicher der allozierten
+                        Actions.
+                  - int DID_ST_SHADOWS
+                  - int DID_ST_SHADOWS_SIZE
+                        Anzahl und Groesse im Speicher aller allozierten
+                        Shadows.
+                  - int DID_ST_OBJECTS
+                  - int DID_ST_OBJECTS_SIZE
+                        Anzahl und Groesse im Speicher aller Objekte.
+                  - int DID_ST_OBJECTS_SWAPPED
+                  - int DID_ST_OBJECTS_SWAP_SIZE
+                        Anzahl und Groesse im Speicher der geswapten
+                        Variablenbloecke der Objekte
+                  - int DID_ST_OBJECTS_LIST
+                        Anzahl Objekte in der Objektliste
+                  - int DID_ST_OBJECTS_NEWLY_DEST
+                        Anzahl der frisch zerstoerten Objekte (d.h. Objekte,
+                        die in diesem Verarbeitungszyklus zerstoert wurden)
+                  - int DID_ST_OBJECTS_DESTRUCTED
+                        Anzahl der zerstoerten, aber noch immer referenzierten
+                        Objekte, ohne die unter DID_ST_OBJECTS_NEWLY_DEST
+                        bereits gezaehlten.
+                  - int DID_ST_OBJECTS_PROCESSED
+                        Anzahl der gelisteten Objekte, die im letzten
+                        Verarbeitungszyklus verarbeitet wurden.
+                  - float DID_ST_OBJECTS_AVG_PROC
+                        Durchschnittlicher Anteil der pro Zyklus verarbeiteten
+                        Objekte, ausgedrueckt in Prozent (0 .. 1.0)
+                  - int DID_ST_OTABLE
+                        Anzahl eingetragener Objekte in der Objekttabelle
+                  - int DID_ST_OTABLE_SLOTS
+                        Anzahl von Hashplaetzen, die von jeder Objekttabelle
+                        bereitgestellt werden
+                  - int DID_ST_OTABLE_SIZE
+                        Durch die Objekttabelle belegter Speicher
+                  - int DID_ST_HBEAT_OBJS
+                        Anzahl Objekte mit einem heart_beat()
+                  - int DID_ST_HBEAT_CALLS
+                        Anzahl aktiver heart_beat() Zyklen bisher (d.h.
+                        Zyklen, in denen mindestens eine heart_beat() Funktion
+                        aufgerufen wurde)
+                  - int DID_ST_HBEAT_CALLS_TOTAL
+                        Gesamtzahl von heart_beat() Zyklen bisher.
+                  - int DID_ST_HBEAT_SLOTS
+                  - int DID_ST_HBEAT_SIZE
+                        Anzahl und Groesse aller allozierten Eintraege in der
+                        heart_beat() Tabelle.
+                  - int DID_ST_HBEAT_PROCESSED
+                        Anzahl heart_beat()s im letzten Zyklus
+                  - float DID_ST_HBEAT_AVG_PROC
+                        Durchschnittlicher Anteil der pro Zyklus aufgerufenen
+                        heart_beat()s, ausgedrueckt in Prozent (0 .. 1.0)
+                  - int DID_ST_CALLOUTS
+                        Anzahl und Groesse aller laufenden call_out()s
+                  - int DID_ST_ARRAYS
+                  - int DID_ST_ARRAYS_SIZE
+                        Anzahl und Groesse aller Arrays
+                  - int DID_ST_MAPPINGS
+                  - int DID_ST_MAPPINGS_SIZE
+                        Anzahl und Groesse aller Mappings
+                  - int DID_ST_PROGS
+                  - int DID_ST_PROGS_SIZE
+                        Anzahl und Groesse aller Programme
+                  - int DID_ST_PROGS_SWAPPED
+                  - int DID_ST_PROGS_SWAP_SIZE
+                        Anzahl und Groesse der geswapten Programme
+                  - int DID_ST_USER_RESERVE
+                  - int DID_ST_MASTER_RESERVE
+                  - int DID_ST_SYSTEM_RESERVE
+                        Momentane Groesse der drei Speicherreserven
+                  - int DID_ST_ADD_MESSAGE
+                  - int DID_ST_PACKETS
+                  - int DID_ST_PACKET_SIZE
+                        Anzahl Aufrufe von add_message(), Anzahl und Groesse
+                        der versendeten Pakete.
+                        Wenn der Driver nicht mit COMM_STAT kompiliert wurde,
+                        liefern alle drei Werte immer -1 zurueck.
+                  - int DID_ST_APPLY
+                  - int DID_ST_APPLY_HITS
+                        Anzahl Aufrufen von apply_low(), und wie viele davon
+                        Cache-Treffer waren. Wenn der Driver nicht mit
+                        APPLY_CACHE_STAT kompiliert wurde, liefern beide
+                        Werte immer -1.
+                  - int DID_ST_STRINGS
+                  - int DID_ST_STRING_SIZE
+                        Anzahl unterschiedlicher Strings in der Stringtabelle,
+                        sowie ihre Groesse
+                  - int DID_ST_STR_TABLE_SIZE
+                        Groesse der String Tabelle
+                  - int DID_ST_STR_REQ
+                  - int DID_ST_STR_REQ_SIZE
+                        Gesamte Anzahl von String Allokationen, und ihre
+                        Groesse
+                  - int DID_ST_STR_SEARCHES
+                  - int DID_ST_STR_SEARCH_LEN
+                        Anzahl Suchvorgaenge in der Stringtabelle und die
+                        Gesamtlaenge des Suchstrings
+                  - int DID_ST_STR_FOUND
+                        Anzahl erfolgreicher Suchvorgaenge
+                  - int DID_ST_STR_ENTRIES
+                        Anzahl Eintraege (Hash Ketten) in der String Tabelle
+                  - int DID_ST_STR_ADDED
+                        Anzahl zur String Tabelle bisher hinzugefuegter
+                        Strings
+                  - int DID_ST_STR_DELETED
+                        Anzahl aus der String Tabelle bisher geloeschter
+                        Strings
+                  - int DID_ST_STR_COLLISIONS
+                        Anzahl zu einer existierenden Hash Kette hinzugefuegte
+                        Strings
+                  - int DID_ST_RX_CACHED
+                        Anzahl gecacheter regulaerer Ausdruecke (regular
+                        expressions)
+                  - int DID_ST_RX_TABLE
+                  - int DID_ST_RX_TABLE_SIZE
+                        Anzahl Plaetze in der Regexp Cache Tabelle und
+                        Speicherbedarf der gecacheten Ausdruecke
+                  - int DID_ST_RX_REQUESTS
+                        Anzahl Anfragen fuer neue regexps
+                  - int DID_ST_RX_REQ_FOUND
+                        Anzahl gefundener regexps in der regexp Cache Tabelle
+                  - int DID_ST_RX_REQ_COLL
+                        Anzahl angefragter regexps, die mit einer bestehenden
+                        regexp kollidierten
+                  - int DID_ST_MB_FILE
+                        Die Groesse des 'File' Speicherpuffers
+                  - int DID_ST_MB_SWAP
+                        Die Groesse des 'Swap' Speicherpuffers
+
+            <arg2> == DID_SWAP (1): Liefert "status swap"-Information:
+                  - int DID_SW_PROGS
+                  - int DID_SW_PROG_SIZE
+                        Anzahl und Groesse der geswappten Programmbloecke
+                  - int DID_SW_PROG_UNSWAPPED
+                  - int DID_SW_PROG_U_SIZE
+                        Anzahl und Groesse der nicht geswappten Bloecke
+                  - int DID_SW_VARS
+                  - int DID_SW_VAR_SIZE
+                        Anzahl und Groesse der geswappten Variablenbloecke
+                  - int DID_SW_FREE
+                  - int DID_SW_FREE_SIZE
+                        Anzahl und Groesse der freien Bloecke in der
+                        Auslagerungsdatei
+                  - int DID_SW_FILE_SIZE
+                        Groesse der Auslagerungsdatei
+                  - int DID_SW_REUSED
+                        Gesamter wiederverwendeter Speicherplatz in der
+                        Auslagerungsdatei
+                  - int DID_SW_SEARCHES
+                  - int DID_SW_SEARCH_LEN
+                        Anzahl und Gesamtlaenge der Suchvorgaenge nach
+                        wiederverwendbaren Bloecken in der Auslagerungsdatei
+                  - int DID_SW_F_SEARCHES
+                  - int DID_SW_F_SEARCH_LEN
+                        Anzahl und Gesamtlaenge der Suchvorgaenge nach einem
+                        Block, der frei gemacht werden kann.
+                  - int DID_SW_COMPACT
+                        TRUE wenn der Swapper im Compact-Modus laeuft
+                  - int DID_SW_RECYCLE_FREE
+                        TRUE wenn der Swapper gerade einen freien Block
+                        wiederverwendet
+
+            <arg2> == DID_MEMORY (2): Liefert die "status malloc"-Information:
+                  - string DID_MEM_NAME
+                        Der Name des Allokators: "sysmalloc", "smalloc",
+                        "slaballoc"
+                  - int DID_MEM_SBRK
+                  - int DID_MEM_SBRK_SIZE
+                        Anzahl und Groesse der Speicherbloecke, die vom
+                        Betriebssystem angefordert wurden (smalloc, slaballoc)
+                  - int DID_MEM_LARGE
+                  - int DID_MEM_LARGE_SIZE
+                  - int DID_MEM_LFREE
+                  - int DID_MEM_LFREE_SIZE
+                        Anzahl und Groesse der grossen allozierten bzw.
+                        freien Bloecke (smalloc, slaballoc)
+                  - int DID_MEM_LWASTED
+                  - int DID_MEM_LWASTED_SIZE
+                        Anzahl und Groesse der unbrauchbaren grossen
+                        Speicherfragmente (smalloc, slaballoc)
+                  - int DID_MEM_CHUNK
+                  - int DID_MEM_CHUNK_SIZE
+                        Anzahl und Groesse kleiner Speicherbloecke (chunk
+                        blocks; smalloc, slaballoc)
+                  - int DID_MEM_SMALL
+                  - int DID_MEM_SMALL_SIZE
+                  - int DID_MEM_SFREE
+                  - int DID_MEM_SFREE_SIZE
+                        Anzahl und groesse der allozierten bzw. freien
+                        kleinen Speicherbloecke (smalloc, slaballoc)
+                  - int DID_MEM_SWASTED
+                  - int DID_MEM_SWASTED_SIZE
+                        Anzahl und Groesse der unbrauchbar kleinen
+                        Speicherfragmente (smalloc, slaballoc)
+                  - int DID_MEM_MINC_CALLS
+                  - int DID_MEM_MINC_SUCCESS
+                  - int DID_MEM_MINC_SIZE
+                        Anzahl Aufrufe von malloc_increment(), Anzahl der
+                        erfolgreichen Aufrufe und die Groesse des auf diese
+                        Art allozierten Speichers (smalloc, slaballoc)
+                  - int DID_MEM_PERM
+                  - int DID_MEM_PERM_SIZE
+                        Anzahl und Groesse permanenter (non-GCable)
+                        Allokationen (smalloc, slaballoc)
+                  - int DID_MEM_CLIB
+                  - int DID_MEM_CLIB_SIZE
+                        Anzahl und Groesse der Allokationen durch Clib
+                        Funktionen (nur smalloc, slaballoc mit SBRK_OK)
+                  - int DID_MEM_OVERHEAD
+                        Overhead fuer jede Allokation (smalloc, slaballoc)
+                  - int DID_MEM_ALLOCATED
+                        Der Speicher, der durch die Speicherverwaltung
+                        alloziert wurde, inklusive den Overhead fuer die
+                        Speicherverwaltung (smalloc, slaballoc)
+                  - int DID_MEM_USED
+                        Der Speicher, der durch den Driver belegt ist, ohne
+                        den durch die Speicherverwaltung belegten Speicher
+                        (smalloc, slaballoc)
+                  - int DID_MEM_TOTAL_UNUSED
+                        Der Speicher, der vom System zur Verfuegung gestellt,
+                        aber vom Treiber nicht benoetigt wird.
+                  - int DID_MEM_AVL_NODES          (smalloc, slaballoc)
+                        Anzahl der AVL-Knoten, die zur Verwaltung der
+                        freien grossen Speicherbloecke verwendet werden
+                        (nur smalloc). Dieser Wert kann in Zukunft
+                        wieder verschwinden.
+                  - mixed * DID_MEM_EXT_STATISTICS (smalloc, slaballoc)
+                        Detaillierte Statistiken des Allokators sofern
+                        diese aktiviert wurden; 0 anderenfalls.
+
+                        Dieser Wert kann in Zukunft wieder verschwinden.
+
+                        Das Array enthaelt NUM+2 Eintraege, wobei NUM
+                        Anzahl der verschiedenen 'kleinen'
+                        Blockgroessen ist. Eintrag [NUM] beschreibt
+                        die uebergrossen 'kleinen' Bloecke, Eintrag
+                        [NUM+1] beschreibt summarisch die 'grossen'
+                        Bloecke. Jeder Eintrag ist ein Array mit
+                        diesen Feldern:
+
+                        int DID_MEM_ES_MAX_ALLOC:
+                          Maximale Anzahl allokierter Bloecke dieser
+                          Groesse.
+
+                        int DID_MEM_ES_CUR_ALLOC:
+                          Derzeitige Anzahl allokierter Bloecke dieser
+                          Groesse.
+                          Current number of allocated blocks of this size.
+
+                        int DID_MEM_ES_MAX_FREE:
+                          Maximale Anzahl freier Bloecke dieser
+                          Groesse.
+
+                        int DID_MEM_ES_CUR_FREE:
+                          Derzeitige Anzahl freier Bloecke dieser
+                          Groesse.
+
+                        float DID_MEM_ES_AVG_XALLOC:
+                          Durchschnittliche Zahl von Allokationen pro
+                          Sekunde.
+
+                        float DID_MEM_ES_AVG_XFREE:
+                          Durchschnittliche Zahl von Deallokationen pro
+                          Sekunde.
+
+                      Die Durchschnittsstatistiken schliessen interne
+                      Umsortierungen der Blocklisten nicht ein.
+
+
+        DINFO_TRACE    (7): Liefert die 'trace' Information aus dem
+            Call Stack entsprechend der Spezifikation in <arg2>. Das Resultat
+            ist entweder ein Array (dessen Format nachstehend erlaeutert ist)
+            oder ein druckbarer String. Wird <arg2> weggelasen entspricht
+            dies DIT_CURRENT.
+
+            <arg2> == DIT_CURRENT (0): Momentaner Call Trace
+                   == DIT_ERROR   (1): Letzter Fehler Trace (caught oder
+                        uncaught)
+                   == DIT_UNCAUGHT_ERROR (2): Letzer Fehler Trace, der nicht
+                        gefangen werden konnte (uncaught)
+
+            Die Information wird in Form eines Array uebergeben.
+
+            Die Fehlertraces werden nur geaendert, wenn ein entsprechender
+            Fehler auftritt; ausserdem werden sie bei einem GC (Garbage
+            Collection) geloescht. Nach einem Fehler, der nicht gefangen
+            werden konnte (uncaught error), weisen beide Traces auf das
+            gleiche Array, sodass der ==-Operator gilt.
+
+            Wenn das Array mehr als ein Element enthaelt, ist das erste
+            Element 0 oder der Name des Objekts, dessen heart_beat() den
+            laufenden Zyklus begonnen hat; alle nachfolgenden Elemente
+            bezeichnen den Call Stack, beginnen mit der hoechsten
+            aufgerufenen Funktion.
+
+            Alle Eintraege im Array sind wiederum Arrays mit folgenden
+            Elementen:
+              - int[TRACE_TYPE]: Der Typ der aufrufenden Funktion
+                    TRACE_TYPE_SYMBOL (0): ein Funktionssymbol (sollte nicht
+                                           vorkommen)
+                    TRACE_TYPE_SEFUN  (1): eine simul-efun
+                    TRACE_TYPE_EFUN   (2): eine Efun Closure
+                    TRACE_TYPE_LAMBDA (3): eine lambda Closure
+                    TRACE_TYPE_LFUN   (4): eine normale Lfun
+              - int[TRACE_NAME]
+                    _TYPE_EFUN    : entweder der Name der Funktion oder der
+                                    Code einer Operator-Closure
+                    _TYPE_LAMBDA  : die numerische Lambda-ID
+                    _TYPE_LFUN    : der Name der Lfun
+              - string[TRACE_PROGRAM]:  Der Name des Programms mit dem Code
+              - string[TRACE_OBJECT]:   Der Name des Objekts, fuer das der
+                                        Code ausgefuehrt wurde
+              - int[TRACE_LOC]:
+                    _TYPE_LAMBDA  : Der Offset des Programms seit Beginn des
+                                    Closure-Codes
+                    _TYPE_LFUN    : Die Zeilennummer.
+
+            <arg2> == DIT_STR_CURRENT (3): Liefert Informationen ueber den
+                momentanen Call Trace als druckbarer String.
+
+            <arg2> == DIT_CURRENT_DEPTH (4): Liefert die Zahl der Frames auf
+                dem Control Stack (Rekursionstiefe).
+
+        DINFO_EVAL_NUMBER (8): gibt die Nummer der aktuellen Berechnung
+            zurueck. Diese Nummer wird fuer jeden vom driver initiierten
+            Aufruf von LPC-Code erhoeht, also bei Aufruf von:
+              - Kommandos (die per add_action hinzugefuegt wurden)
+              - heart_beat, reset, clean_up
+              - Aufrufe durch call_out oder input_to
+              - master applies, die auf externe Ereignisse zurueckgehen
+              - driver hooks genauso
+              - Rueckrufen von send_erq
+              - logon in interaktiven Objekten
+
+           Dieser Zaehler kann z.B. benutzt werden, um zu verhindern, dass
+           bestimmte Aktionen mehrfach innerhalb eines heart_beat()
+           ausgefuehrt werden. Eine andere Anwendungsmoeglichkeit sind
+           Zeitstempel zur Sortierung zur Sortierung von Ereignissen.
+
+           Es ist zu beachten, dass der Zaehler ueberlaufen kann, insbesondere
+           auf 32-bit-Systemen. Er kann demzufolge auch negativ werden.
+
+GESCHICHTE
+----------
+::
+
+        Seit 3.2.7 liefert DINFO_STATUS die Information zurueck, anstatt sie
+            nur auszugeben.
+        DINFO_DUMP wurde in 3.2.7 eingefuehrt.
+        LDMud 3.2.8 fuegte die Datengroesse des Objekts zum Resultat von
+            DINFO_MEMORY hinzu, ausserdem die DINFO_DATA Abfrage und die
+            verschiedenen DID_MEM_WASTED Statistiken.
+        LDMud 3.2.9 fuegte DINFO_TRACE, das Indizierungs-Feature von
+            DINFO_DATA, den 'destructed'-DINFO_DUMP, die DID_MEM_CLIB*,
+            die DID_MEM_PERM*, ausserdem DID_ST_OBJECTS_NEWLY_DEST,
+            DID_ST_OBJECTS_DEST, DID_MEM_OVERHEAD, DID_MEM_ALLOCATED,
+            DID_MEM_USED, DID_MEM_TOTAL_UNUSED, DID_ST_HBEAT_CALLS_TOTAL
+            und die found / added / collision Stringstatistiken.
+        LDMud 3.2.10 fuegte die Erzeugungszeit zu DINFO_DUMP:"objects" hinzu,
+            entfernte DID_MEM_UNUSED aus DINFO_DATA:DID_MEMORY, fuegte
+            DINFO_DATA:DID_STATUS DID_ST_BOOT_TIME, DID_ST_MB_FILE und
+            DID_ST_MB_SWAP hinzu und entfernte DID_ST_CALLOUT_SLOTS daraus,
+            fuegte das dritte Argument zu DINFO_OBJLIST hinzu, und veraenderte
+            die Bedeutung von DID_ST_CALLOUT_SIZE und DID_ST_HBEAT_SIZE
+            bzw. _SLOTS.
+        LDMud 3.3.533 fuegte DID_MEM_AVL_NODES zu DINFO_DATA:DID_MEMORY
+            hinzu.
+        LDMud 3.3.603 fuegte DID_MEM_EXT_STATISTICS zu DINFO_DATA:DID_MEMORY
+            hinzu.
+        LDMud 3.3.718 fuegte DIT_CURRENT_DEPTH to DINFO_TRACE hinzu.
+        LDMud 3.3.719 fuegte DINFO_EVAL_NUMBER hinzu.
+
+SIEHE AUCH
+----------
+::
+
+        trace(E), traceprefix(E), malloc(D), status(D), dumpallobj(D)
+
diff --git a/doc/sphinx/sefun/deep_present.rst b/doc/sphinx/sefun/deep_present.rst
new file mode 100644
index 0000000..2d7cd5f
--- /dev/null
+++ b/doc/sphinx/sefun/deep_present.rst
@@ -0,0 +1,40 @@
+deep_present()
+==============
+
+FUNKTION
+--------
+::
+
+        object deep_present(string what)
+        object deep_present(object what)
+        object deep_present(string what, object ob)
+        object deep_present(object what, object ob)
+
+ARGUMENTE
+---------
+::
+
+        what - Objekt oder ID des Objektes, nach dem gesucht werden soll
+        ob - Objekt, in dem gesucht werden soll
+
+BESCHREIBUNG
+------------
+::
+
+        deep_present() sucht in this_object() (oder in ob, falls angegeben)
+        nach dem Objekt what oder einem Objekt, das auf what anspricht.
+        Im Gegensatz zu present() wird aber das komplette Inventory berueck-
+        sichtigt (also zB. auch der Inhalt von Beuteln).
+
+RUECKGABEWERT
+-------------
+::
+
+        das gefundene Objekt oder 0
+
+SIEHE AUCH
+----------
+::
+
+        present(E)
+
diff --git a/doc/sphinx/sefun/dtime.rst b/doc/sphinx/sefun/dtime.rst
new file mode 100644
index 0000000..c0336d6
--- /dev/null
+++ b/doc/sphinx/sefun/dtime.rst
@@ -0,0 +1,49 @@
+dtime()
+=======
+
+FUNKTION
+--------
+::
+
+	string dtime(int time)
+
+ARGUMENTE
+---------
+::
+
+	time - Umzuwandelndes Datum in Sekunden seit 1.1.1970, 0:0:0h
+
+BESCHREIBUNG
+------------
+::
+
+	Wandelt das Datum time in einen deutschsprachigen String der Form
+	"<wtag>, <tag>. <mon> <jahr>, <std>:<min>:<sek>" um.
+
+RUECKGABEWERT
+-------------
+::
+
+	Der String mit dem umgewandelten Datum.
+
+BEMERKUNGEN
+-----------
+::
+
+	Als time wird meistens das Ergebnis von time() benutzt.
+  strftime() stellt eine wesentlich flexiblere Moeglichkeit der Ausgabe von
+  Zeiten dar.
+
+BEISPIELE
+---------
+::
+
+	datum = dtime(time());
+        => datum = "Mon,  6. Mar 1994, 15:00:08"
+
+SIEHE AUCH
+----------
+::
+
+	ctime(E), strftime(E), time(E)
+
diff --git a/doc/sphinx/sefun/dump_netdead.rst b/doc/sphinx/sefun/dump_netdead.rst
new file mode 100644
index 0000000..4c94f8c
--- /dev/null
+++ b/doc/sphinx/sefun/dump_netdead.rst
@@ -0,0 +1,29 @@
+dump_netdead()
+==============
+
+FUNKTION
+--------
+::
+
+        string *dump_netdead()
+
+BESCHREIBUNG
+------------
+::
+
+        Gibt ein Array mit den Namen aller zur Zeit netztoten Spieler
+        zurueck.
+
+RUECKGABEWERT
+-------------
+::
+
+        Ein Stringarray mit den Namen der netztoten Spieler.
+        gibt.
+
+SIEHE AUCH
+----------
+::
+
+        find_netdead(E)
+
diff --git a/doc/sphinx/sefun/enable_commands.rst b/doc/sphinx/sefun/enable_commands.rst
new file mode 100644
index 0000000..152aa0f
--- /dev/null
+++ b/doc/sphinx/sefun/enable_commands.rst
@@ -0,0 +1,42 @@
+enable_commands()
+=================
+
+SYNOPSIS
+--------
+::
+
+        void enable_commands();
+
+BESCHREIBUNG
+------------
+::
+
+        Erlaubt dem Objekt, Kommandos zu verwenden, die normalerweise Usern
+        zugaenglich sind. Der Aufruf markiert das Objekt als "living". Dies
+        wird fuer Spieler und alle von /std/npc abgeleiteten Objekte
+        bereits von der Mudlib erledigt und sollte nicht nochmals gemacht
+        werden.
+
+        Diese Funktion darf nicht ausserhalb von create() (oder reset(0) im
+        Compat-Modus) aufgerufen werden, weil der Kommandogeber auf dieses
+        Objekt gesetzt wird.
+
+BEISPIEL
+--------
+::
+
+        void create()
+        {
+            enable_commands();
+            ...
+        }
+
+        Dies markiert das Objekt als "living".
+
+SIEHE AUCH
+----------
+::
+
+        command(E), living(E), disable_commands(E), native(C), hooks(C)
+        set_living_name(E)
+
diff --git a/doc/sphinx/sefun/file_time.rst b/doc/sphinx/sefun/file_time.rst
new file mode 100644
index 0000000..e420bb2
--- /dev/null
+++ b/doc/sphinx/sefun/file_time.rst
@@ -0,0 +1,12 @@
+file_time()
+===========
+
+FUNKTION
+--------
+::
+
+	int file_time(string filename);
+
+Liefert den Zeitpunkt der letzten Modifikation des Files in Sekunden seit
+dem 1.1.1970, 0:00. Kann per ctime() in ein lesbares Format gebracht werden.
+
diff --git a/doc/sphinx/sefun/find_living.rst b/doc/sphinx/sefun/find_living.rst
new file mode 100644
index 0000000..693108a
--- /dev/null
+++ b/doc/sphinx/sefun/find_living.rst
@@ -0,0 +1,42 @@
+find_living()
+=============
+
+SYNOPSIS
+--------
+::
+
+        object find_living(string str)
+
+BESCHREIBUNG
+------------
+::
+
+        Findet das erste "lebende" Objekt, welches per set_living_name() den
+        Namen <str> setzte.
+
+        
+
+        Das Objekt muss ausserdem per enable_commands() als Lebewesen
+        markiert worden sein. Dies ist fuer alle von /std/npc erbenden NPCs
+        _automatisch_ der Fall und sollte daher nicht nochmal explizit gemacht
+        werden.
+
+BEISPIEL
+--------
+::
+
+        object ob;
+        ob = find_living("Public Enemy");
+
+SIEHE AUCH
+----------
+::
+
+        find_player(E), enable_commands(E), set_living_name(E)
+
+LETZTE AeNDERUNG
+----------------
+::
+
+09.10.2011, Zesstra
+
diff --git a/doc/sphinx/sefun/find_livings.rst b/doc/sphinx/sefun/find_livings.rst
new file mode 100644
index 0000000..f439c3e
--- /dev/null
+++ b/doc/sphinx/sefun/find_livings.rst
@@ -0,0 +1,49 @@
+find_livings()
+==============
+
+FUNKTION
+--------
+::
+
+        object *find_livings(string name)
+
+ARGUMENTE
+---------
+::
+
+        name - der living_name der gesuchten Lebewesen
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion liefert ein Array mit allen Lebewesen, die den gleichen
+        living_name haben.
+
+RUECKGABEWERT
+-------------
+::
+
+        Array mit den Lebewesen oder 0, wenn es kein Lebewesen diesen Namens
+        gibt.
+
+BEISPIELE
+---------
+::
+
+        ob = find_livings("herkules");
+        => ob = ({ [/human:herkules], 
+                   [/d/inseln/wargon/luftschloss/mon/herkules] })
+
+SIEHE AUCH
+----------
+::
+
+        find_living(E), set_living_name(E), find_player(E), find_netdead(E)
+
+LETZTE AENDERUNG
+----------------
+::
+
+19. Okt. 2015, Arathorn
+
diff --git a/doc/sphinx/sefun/find_netdead.rst b/doc/sphinx/sefun/find_netdead.rst
new file mode 100644
index 0000000..aa5fd9d
--- /dev/null
+++ b/doc/sphinx/sefun/find_netdead.rst
@@ -0,0 +1,46 @@
+find_netdead()
+==============
+
+FUNKTION
+--------
+::
+
+        object find_netdead(string name)
+
+ARGUMENTE
+---------
+::
+
+        name - Name des gesuchten Spielers
+
+BESCHREIBUNG
+------------
+::
+
+        Falls der Spieler name netztot ist, liefert diese Funktion das Spieler-
+        objekt zurueck.
+
+        Akzeptiert auch die UUID statt einer UID. In diesem Fall erfolgt aber
+        nur eine Pruefung, ob die UID des gefundenen Spielers zur angegebenen
+        UUID passt (d.h. "jof_-1" wuerde dann ggf. auch das Spielerobjekt Jof
+        zurueckliefern, wenn das die UUID "Jof_1234" hat).
+
+RUECKGABEWERT
+-------------
+::
+
+        Der netztote Spieler oder 0, falls es keinen Netztoten diesen Namens
+        gibt.
+
+SIEHE AUCH
+----------
+::
+
+        find_living(E), find_player(E)
+
+LETZT AeNDERUNG
+---------------
+::
+
+06.01.2009, Zesstra
+
diff --git a/doc/sphinx/sefun/find_player.rst b/doc/sphinx/sefun/find_player.rst
new file mode 100644
index 0000000..333c6c5
--- /dev/null
+++ b/doc/sphinx/sefun/find_player.rst
@@ -0,0 +1,63 @@
+find_player()
+=============
+
+FUNKTION
+--------
+::
+
+        object find_player(string uid)
+
+BESCHREIBUNG
+------------
+::
+
+        Findet den Spieler mit dem Namen bzw. der User-ID <uid>.
+
+        
+
+        Akzeptiert auch die UUID statt einer UID. In diesem Fall erfolgt aber
+        nur eine Pruefung, ob die UID des gefundenen Spielers zur angegebenen
+        UUID passt (d.h. "jof_-1" wuerde dann ggf. auch das Spielerobjekt Jof
+        zurueckliefern, wenn das die UUID "Jof_1234" hat).
+
+        Rueckgabewert ist das Spielerobjekt (wenn Spieler anwesend),
+        ansonsten 0.
+
+BEISPIEL
+--------
+::
+
+        object ob;
+        ob = find_player("deepthought");
+
+        if(ob)
+          tell_object(ob,"Tach Du!\n");
+
+        oder auch 
+
+        if(ob = find_player("deepthought"))
+          tell_object(ob,"Tach Du!\n");
+
+ANMERKUNGEN
+-----------
+::
+
+        Via find_player() werden auch unsichtbare Magier gefunden. In 
+        Objekten, die fuer Spieler gedacht sind, muss dies dann extra
+        per Abfrage auf if(ob->QueryProp(P_INVIS)) getestet werden.
+
+        Netztote Spieler und Monster werden nicht gefunden da find_player
+        den Namen aus set_living_name() verwendet, der in player.c ge-
+        setzt wird.
+
+        
+
+SIEHE AUCH
+----------
+::
+
+        find_living(E), set_living_name(E), find_object(E), find_netdead(E)
+
+
+Letzte Aenderung: 06.01.2009, Zesstra 
+
diff --git a/doc/sphinx/sefun/getuuid.rst b/doc/sphinx/sefun/getuuid.rst
new file mode 100644
index 0000000..9398b54
--- /dev/null
+++ b/doc/sphinx/sefun/getuuid.rst
@@ -0,0 +1,31 @@
+getuuid()
+=========
+
+SYNOPSIS
+--------
+::
+
+    string getuuid(object ob)
+
+DESCRIPTION
+-----------
+::
+
+    Liefert eine eindeutige (get unique uid) UID fuer einen Spieler.
+    Wird zusammengesetzt aus der UID des Spielers und seinem
+    Erstlogin-Datum.
+
+    Nach einer Selbstloeschung und neuem Login erhaelt der Spieler eine
+    neue UUID, bei einer Restaurierung behaelt er seine alte UUID.
+
+    Wenn die Funktion ohne Parameter aufgerufen wird, wird per Default
+    this_object() genommen.
+
+    
+
+SEE ALSO
+--------
+::
+
+        getuid(E)
+
diff --git a/doc/sphinx/sefun/iso2ascii.rst b/doc/sphinx/sefun/iso2ascii.rst
new file mode 100644
index 0000000..2d45cf0
--- /dev/null
+++ b/doc/sphinx/sefun/iso2ascii.rst
@@ -0,0 +1,33 @@
+iso2ascii()
+===========
+
+FUNKTION
+--------
+::
+
+	public string iso2ascii( string str );
+
+ARGUMENTE
+---------
+::
+
+	str
+	  String, in welchem Zeichen ersetzt werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+	In dem String werden alle Nicht-ASCII-Zeichen durch ASCII-Zeichen
+	ersetzt, und zwar Umlaute in der bekannten Form und alle anderen
+	durch ein Fragezeichen.
+
+RUeCKGABEWERT
+-------------
+::
+
+	String mit ASCII-Zeichen.
+
+
+Last modified: Fri Jul  6 19:36:09 2001 by Patryn
+
diff --git a/doc/sphinx/sefun/log_file.rst b/doc/sphinx/sefun/log_file.rst
new file mode 100644
index 0000000..b1586be
--- /dev/null
+++ b/doc/sphinx/sefun/log_file.rst
@@ -0,0 +1,59 @@
+log_file()
+==========
+
+FUNKTION
+--------
+::
+
+	int log_file(string file, string text)
+  int log_file(string file, string text, int size_to_break)
+
+ARGUMENTE
+---------
+::
+
+	file - Name der Datei, in die geschrieben werden soll
+	text - Der Text, der geschrieben werden soll
+	size_to_break - Groesse, ab der ein neues File begonnen wird (optional)
+
+BESCHREIBUNG
+------------
+::
+
+	log_file schreibt den Text text in die Datei /log/file.
+	Sollte file schon mit einem /log/ beginnen, wird kein erneutes /log/ davor
+	eingefuegt.
+
+RUECKGABEWERT
+-------------
+::
+
+	1 bei Erfolg oder 0, falls ein Fehler beim Schreiben auftrat.
+
+BEMERKUNGEN
+-----------
+::
+
+	Wenn die Groesse von file vor dem Schreiben 50000 Bytes ueberschreitet,
+	wird sie in file.old umbenannt. Eine schon vorhandene Datei file.old
+	wird dabei geloescht. Der Text wird nach dem Umbenennen geschrieben.
+	Wird 'size_to_break' angegeben und ist dies > 0, wird dieser Wert (in 
+	Bytes) statt der 50000 Bytes zum Rotieren des Logfiles benutzt.
+
+BEISPIELE
+---------
+::
+
+	log_file( "report/wargon.rep", "TYPO von bla in blubb:\ntest\n");
+	In /log/report/wargon.rep finde ich nun die neueste Typomeldung... ;)
+	log_file( "/log/report/wargon.rep", "TYPO von bla in blubb:\ntest\n");
+	Gleiches Ergebnis. ;-)
+
+SIEHE AUCH
+----------
+::
+
+	write_file(E)
+
+29.01.2017, Zesstra
+
diff --git a/doc/sphinx/sefun/lowerchar.rst b/doc/sphinx/sefun/lowerchar.rst
new file mode 100644
index 0000000..b821780
--- /dev/null
+++ b/doc/sphinx/sefun/lowerchar.rst
@@ -0,0 +1,42 @@
+lowerchar()
+===========
+
+FUNKTION
+--------
+::
+
+	int lowerchar(int char)
+
+ARGUMENTE
+---------
+::
+
+	char - Das umzuwandelnde Zeichen
+
+BESCHREIBUNG
+------------
+::
+
+	Wenn char ein Grossbuchstabe ist, so wird es in einen Kleinbuchstaben
+	umgewandelt. Andere Zeichen werden von dieser Funktion nicht beein-
+        flusst.
+
+RUECKGABEWERT
+-------------
+::
+
+	Das umgewandelte Zeichen.
+
+BEISPIELE
+---------
+::
+
+	printf("%c\n", lowerchar('A')); => a
+	printf("%c\n", lowerchar('1')); => 1
+
+SIEHE AUCH
+----------
+::
+
+	lower_case(E), lowerstring(E), upperstring(E), capitalize(E)
+
diff --git a/doc/sphinx/sefun/lowerstring.rst b/doc/sphinx/sefun/lowerstring.rst
new file mode 100644
index 0000000..8570042
--- /dev/null
+++ b/doc/sphinx/sefun/lowerstring.rst
@@ -0,0 +1,45 @@
+lowerstring()
+=============
+
+FUNKTION
+--------
+::
+
+	string lowerstring(string str)
+
+ARGUMENTE
+---------
+::
+
+	str - Der umzuwandelnde String.
+
+BESCHREIBUNG
+------------
+::
+
+	Alle Grossbuchstaben in str werden in Kleinbuchstaben umgewandelt.
+
+RUECKGABEWERT
+-------------
+::
+
+	Der umgewandelte String.
+
+BEMERKUNGEN
+-----------
+::
+
+	lowerstring ist mit lower_case identisch!
+
+BEISPIELE
+---------
+::
+
+	s = lowerstring("So, McLaud...\n"); => s = "so, mclaud...\n"
+
+SIEHE AUCH
+----------
+::
+
+	lower_case(E), lowerchar(E), upperstring(E), capitalize(E)
+
diff --git a/doc/sphinx/sefun/m_copy_delete.rst b/doc/sphinx/sefun/m_copy_delete.rst
new file mode 100644
index 0000000..acf9f1b
--- /dev/null
+++ b/doc/sphinx/sefun/m_copy_delete.rst
@@ -0,0 +1,68 @@
+m_copy_delete()
+===============
+
+FUNKTION
+--------
+::
+
+	mapping m_copy_delete(mapping map, mixed key)
+
+ARGUMENTE
+---------
+::
+
+	map - das Mapping, aus dem geloescht werden soll.
+	key - der zu loeschende Eintrag
+
+BESCHREIBUNG
+------------
+::
+
+	Aus dem Mapping map wird der Eintrag key geloescht (wenn er in map vor-
+	handen ist). map wird dabei nicht veraendert.
+
+RUECKGABEWERT
+-------------
+::
+
+	Eine (flache !) Kopie von map ohne den Eintrag key, d.h. enthaltene
+	Mappings/Arrays werden nicht kopiert.
+
+BEMERKUNGEN
+-----------
+::
+
+	Das urspruengliche Mapping wird bei dieser Operation nicht veraendert!
+	Wenn man nur einen Wert aus dem Mapping loeschen will und die Kopie nicht
+	braucht, bietet sich efun::m_delete(mapping,key) sehr an, da die Erstellung
+  einer Kopie sehr aufwendig sein kann.
+
+BEISPIELE
+---------
+::
+
+	mapping m1, m2;
+
+        m1 = ([ "a":1, "b":2, "c":3 ]);
+
+        m2 = m_copy_delete(m1, "b");
+           => m1 = ([ "a":1, "b":2, "c":3 ])
+	      m2 = ([ "a":1, "c":3 ])
+
+        m_copy_delete(m1, "a");
+           => (es hat sich nichts geaendert)
+
+        m1 = m_copy_delete(m1, "a");
+           => m1 = ([ "b":2, "c":3 ])
+
+        Im letzten Fall sollte aber besser efun::m_delete(m1, "a") benutzt 
+        werden, da ansonsten das Mapping unnoetig kopiert wird und Rechen-
+        leistung frisst. 
+
+SIEHE AUCH
+----------
+::
+
+  efun::m_delete(E), mappingp(E), mkmapping(E), m_indices,(E) m_values(E),
+  sizeof(E), widthof(E)
+
diff --git a/doc/sphinx/sefun/match_living.rst b/doc/sphinx/sefun/match_living.rst
new file mode 100644
index 0000000..e8633dc
--- /dev/null
+++ b/doc/sphinx/sefun/match_living.rst
@@ -0,0 +1,52 @@
+match_living()
+==============
+
+match_living(sefun)
+
+FUNKTION
+--------
+::
+
+     varargs mixed match_living( string str, int players_only,
+				 string *exclude)
+
+ARGUMENTE
+---------
+::
+
+     string str		- Kuerzel, nach dem die living_names durchsucht
+			  werden soll
+     int players_only	- 1, um nur Spieler (Interactives) zu suchen
+     string *exlude	- welche Namen sollen ignoriert werden
+
+BESCHREIBUNG
+------------
+::
+
+     Sucht alle Lebewesen, deren Namen mit str beginnen.
+
+RUECKGABEWERT
+-------------
+::
+
+     Ein String, falls es ein Lebewesen mit dem Namen str gibt (der Name
+     muss genau passen).
+     -1, wenn es mehrere Lebewesen gibt, deren Namen mit str beginnen.
+     -2, wenn es kein Lebewesen gibt, dessen Name mit str beginnt.
+
+BEISPIELE
+---------
+::
+
+     match_living("wargon"); => "wargon", wenn Wargon eingeloggt ist.
+     match_living("war");    => "wargon", wenn es kein anderes Lebewesen
+                                gibt, dessen Name mit "war" beginnt.
+
+SIEHE AUCH
+----------
+::
+
+     find_living(E), find_player(E), find_netdead(E)
+
+27. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/sefun/md5.rst b/doc/sphinx/sefun/md5.rst
new file mode 100644
index 0000000..d4c7013
--- /dev/null
+++ b/doc/sphinx/sefun/md5.rst
@@ -0,0 +1,52 @@
+md5()
+=====
+
+DEPRECATED
+----------
+::
+
+SYNOPSIS
+--------
+::
+
+        string md5 (string arg [ , int iterations ] )
+        string md5 (int *  arg [ , int iterations ] )
+
+BESCHREIBUNG
+------------
+::
+
+        Berechnet den MD5-Hashwert von <arg>.
+        Das Argument kann ein String, oder ein Array von Zahlen sein (von
+        welchen nur das unterste Byte betrachted wird).
+
+        Das Ergebnis wird als 32-stelliger Hexadezimalwert geliefert.
+
+        Ist das <iterations> Argument eine Zahl groesser 0, berechnet der
+        Driver den Digest mit diese Anzahl an Wiederholungen. Fehlt die
+        Angabe, fuehrt der Driver die Digest-Berechnung einmal aus.
+
+BEISPIEL
+--------
+::
+
+        string s;
+
+        s = md5("Hallo");
+        s = md5( ({ 'H', 'e', 'l', 'l', 'o' }) )
+        s = md5( ({ 'H', 'e', 'l', 'l', 'o' }), 2 )
+
+AENDERUNGEN
+-----------
+::
+
+        Eingefuehrt in LDMud 3.2.9
+        LDMud 3.2.12 fuehrte Zaehlenarrays als Argument ein, also auch
+          die Anzahl der Wiederholungen.
+
+SIEHE AUCH
+----------
+::
+
+        crypt(E), md5_crypt(E), sha1(E), hash(E), hmac(E)
+
diff --git a/doc/sphinx/sefun/mkdirp.rst b/doc/sphinx/sefun/mkdirp.rst
new file mode 100644
index 0000000..b7b9285
--- /dev/null
+++ b/doc/sphinx/sefun/mkdirp.rst
@@ -0,0 +1,44 @@
+mkdirp()
+========
+
+FUNKTION
+--------
+::
+
+        int mkdirp(string dir)
+
+ARGUMENTE
+---------
+::
+
+        dir - Name des zu erstellenden Verzeichnisses (absolut)
+
+BESCHREIBUNG
+------------
+::
+
+        Erzeugt das Verzeichnis <dir>. Dies muss als abs. Pfad angegeben
+        werden.
+        Wenn noetig, wird die ganze Verzeichnishierarchie rekursiv erstellt.
+
+        
+
+RUECKGABEWERT
+-------------
+::
+
+        0 - Verzeichnis konnte nicht erstellt werden
+        1 - Verzeichnis wurde erstellt oder existierte bereits
+
+SIEHE AUCH
+----------
+::
+
+        mkdir(E)
+
+LETZT AeNDERUNG
+---------------
+::
+
+26.01.2013, Zesstra
+
diff --git a/doc/sphinx/sefun/notify_fail.rst b/doc/sphinx/sefun/notify_fail.rst
new file mode 100644
index 0000000..99c07f2
--- /dev/null
+++ b/doc/sphinx/sefun/notify_fail.rst
@@ -0,0 +1,107 @@
+notify_fail()
+=============
+
+FUNKTION
+--------
+::
+
+     #include <notify_fail.h>
+
+     varargs void notify_fail(string str, int prio)
+     varargs void notify_fail(closure cl, int prio)
+
+ARGUMENTE
+---------
+::
+
+     str   Meldung die an den Spieler anstatt des 'Wie bitte' ausgegeben
+           werden soll
+     cl    Closure, die bei Fehlschlag ausgefuehrt werden soll
+     prio  Prioritaet dieses Objekts bei diesem Setzen der Meldung
+
+BESCHREIBUNG
+------------
+::
+
+     Merkt sich den angegebenen str und gibt ihn im Falle einer inkorrekten
+     Eingabe des Spielers anstatt eines 'Wie bitte' aus.
+
+     Gedacht ist notify_fail, um dem Spieler eine bessere Hilfestellung
+     bei Kommandos / Eingaben zu geben, um ihn u.U. auf die richtige
+     Syntax hinzuweisen.
+
+     Wird notify_fail mehrfach (durch verschiedene Objekte o.ae.) auf-
+     gerufen, wird der letzte erfolgreiche Aufruf gewertet. Eine Meldung wird
+     dann tatsaechlich gesetzt, wenn die Prioritaet dieses Objekts gleich
+     gross oder groesser ist als die Prioritaet des Objekts, was das bisher
+     gueltige notify_fail() gesetzt hat. Folgende Prioritaeten sind
+     vordefiniert und werden automatisch ermittelt:
+     NF_NL_OWN    100         // eigenes Objekt (soul) ueberschreibt kaum was
+     NF_NL_THING  100000
+     NF_NL_ROOM   1000000     // Raeume ueberschreiben sonstigen Krams
+     NF_NL_LIVING 10000000    // Lebewesen ueberschreiben auch Raeume
+     2 weitere vordefinierte koennen von Magier angegeben werden:
+     NF_NL_NONE   -1          // wird von allem ueberschrieben
+     NF_NL_MAX    __INT_MAX__ // hoechste Prioritaet, ueberschreibt alles
+
+     Wird eine Closure als Argument gegeben, wird sie im Fehlerfall
+     (also erst wenn ein Kommando endgueltig fehlgeschlagen hat)
+     ausgefuehrt und hat die Fehlermeldung als Resultat
+     zurueckzugeben. Die Closure erhaelt als Argument den
+     originalen Befehlsgeber; in der Regel dies ist this_player(),
+     was aber vom MODIFY_CMD hook geaendert werden kann.
+
+     notify_fail() erkennt verschachtelte Kommandos (siehe Efun
+     command()), und ein notify_fail() in einem Unterkommando
+     hat keinen Einfluss auf das uebergeordnete Kommando.
+
+BEMERKUNGEN
+-----------
+::
+
+     - solange man sich nicht absolut sicher ist, dass ein bestimmtes Objekt
+       mit dem Kommando gemeint ist (Identifikation ueber id()), sollte man
+       - notify_fail(str); return 0;
+       nutzen anstatt mit
+       - write(str) return 1;
+       die Kommandoauswertung abzubrechen (und anderen Objekten die Chance
+       zu nehmen das Kommando zu erfuellen)
+     - Kommandos werden uebrigens oft erst vom betretenen Raum, dann von den
+       Objekten abgearbeitet (je nachdem wann diese dazukamen)
+     - die Prioritaet wird momentan nicht gespeichert, sie ist nur beim Setzen
+       relevant. Will spaeter ein anderes Objekt eine Meldung setzen, wird
+       fuer das eigene Objekt die Standardprioritaet ermittelt, auch wenn man
+       eine andere hier uebergeben hat
+     - Die NF_NL_* sind in /sys/notify_fail.h defniert.
+
+BEISPIELE
+---------
+::
+
+     Ein Raum erwartet die korrekte Eingabe von 'iss suppe':
+
+     int iss_cmd(string str){
+       // zu Anfang der Funktion das notify_fail definieren
+       notify_fail("Moechtest Du vielleicht von der Suppe essen?\n");
+
+       // Spieler hat nur 'iss' ohne Parameter eingegeben oder einen anderen
+       // Parameter angegeben ... Abbruch!
+       // Falls kein weiteres Objekt das Kommando erfuellt oder das
+       // notify_fail() mit einer eigenen Meldung ueberschreibt, wird obige
+       // Meldung an den Spieler ausgegeben.
+
+       if(!str || str!="suppe") return 0;
+       // ab hier ist die Eingabe dann wirklich 'suppe' und die Funktion
+       // kann beliebig fortgefuehrt werden
+       ...
+       return   1;
+
+SIEHE AUCH
+----------
+::
+
+     add_action(E), AddCmd(L), AddAction(L),
+     query_verb(E), query_notify_fail(E)
+
+8.Aug 2007 Gloinson
+
diff --git a/doc/sphinx/sefun/object_info.rst b/doc/sphinx/sefun/object_info.rst
new file mode 100644
index 0000000..902caf5
--- /dev/null
+++ b/doc/sphinx/sefun/object_info.rst
@@ -0,0 +1,148 @@
+object_info()
+=============
+
+DEPRECATED
+----------
+::
+
+SYNOPSIS
+--------
+::
+
+        #include <objectinfo.h>
+
+        mixed * object_info(object ob, int what)
+        mixed * object_info(object ob, int what, int index)
+
+DESCRIPTION
+-----------
+::
+
+        Returns some internal information about object <ob>, collected
+        in an array. Argument <what> determines which information is
+        returned.
+
+        The result is usually an array. However, if <index> is specified,
+        the result is the value from position <index> of the array which
+        would have been returned normally.
+
+        The possible values of <what>, and the indices of the returned
+        arrays are defined in the include file <objectinfo.h>, and may
+        change in future versions of the driver!
+
+
+        <what> == OINFO_BASIC:
+
+          This call returns basic information about <ob>:
+
+          int [OIB_HEART_BEAT]:       1 if <ob> has a heart_beat, 0 else.
+          int [OIB_IS_WIZARD]:        1 if <ob> has the wizard flag set,
+                                        0 else.
+            This entry is always 0 when set_is_wizard() is not available.
+          int [OIB_ENABLE_COMMANDS]:  1 if <ob> can give commands, 0 else.
+          int [OIB_CLONE]:            1 if <ob> is a clone, 0 else.
+          int [OIB_DESTRUCTED]:       1 if <ob> is destructed, 0 else.
+          int [OIB_SWAPPED]:          1 if <ob> is swapped, 0 else.
+          int [OIB_ONCE_INTERACTIVE]: 1 if <ob> was once interactive, 0 else.
+          int [OIB_RESET_STATE]:      1 if <ob> is (still) reset, 0 else.
+          int [OIB_WILL_CLEAN_UP]:    1 if <ob> will call clean_up(), 0 else.
+          int [OIB_LAMBDA_REFERENCED]: 1 if <ob> has lambdas, 0 else.
+          int [OIB_SHADOW]:           1 if <ob> has a shadow structure tied
+                                        to it, 0 if not.
+          int [OIB_REPLACED]:         1 if the program for <ob> was replaced,
+                                      0 else.
+          int [OIB_NEXT_RESET]:   time of the next reset
+          int [OIB_TIME_OF_REF]:  time of the last call to <ob>
+          int [OIB_NEXT_CLEANUP]: time of the next data cleanup
+          int [OIB_REF]:          number of references to <ob>
+          int [OIB_GIGATICKS] and [OIB_TICKS]: together, these numbers
+            give the accumulated evaluation cost spend in <ob>
+          int [OIB_SWAP_NUM]:     the swap number for <ob>s program,
+                                  or -1 if not swapped.
+          int [OIB_PROG_SWAPPED]: 1 if <ob>'s program is swapped, 0 else.
+          int [OIB_VAR_SWAPPED]:  1 if <ob>'s variables are swapped, 0 else.
+          int [OIB_NAME]:         <ob>'s object name.
+          int [OIB_LOAD_NAME]:    <ob>'s load name.
+          object [OIB_NEXT_ALL]:  next object in the object list.
+          object [OIB_PREV_ALL]:  previous object in the object list.
+
+
+        <what> == OINFO_POSITION:
+
+          This call returns information about <ob>'s position in the
+          global list of objects:
+
+          object [OIP_NEXT]: next object in the object list.
+          object [OIP_PREV]: previous object in the object list.
+          int    [OIP_POS]:  position of <ob> in list, counting from 0 up.
+
+          This call can be expensive in computing time.
+
+
+        <what> == OINFO_MEMORY:
+
+          This call returns information about the program <ob> uses:
+
+          int    [OIM_REF]:            number of references to the program.
+          string [OIM_NAME]:           name of program.
+          int    [OIM_PROG_SIZE]:      size of the program.
+          int    [OIM_NUM_FUNCTIONS]:  number of functions in the program.
+          int    [OIM_SIZE_FUNCTIONS]: size needed for the function structs.
+          int    [OIM_NUM_VARIABLES]:  number of variables in the program.
+          int    [OIM_SIZE_VARIABLES]: size needed for the variable structs.
+          int    [OIM_NUM_STRINGS]:    number of strings in the program.
+          int    [OIM_SIZE_STRINGS]:   size needed for the string pointers.
+          int    [OIM_SIZE_STRINGS_DATA]: size needed for the string data,
+                                       scaled down according to the extend of
+                                       data sharing.
+          int    [OIM_SIZE_STRINGS_TOTAL]: unmodified size needed for the
+                                       string data.
+          int    [OIM_NUM_INCLUDES]:   number of included files in the program.
+          int    [OIM_NUM_INHERITED]:  number of inherited programs.
+          int    [OIM_SIZE_INHERITED]: size needed for the inherit structs.
+          int    [OIM_TOTAL_SIZE]:     total size of the program.
+          int    [OIM_DATA_SIZE]:      total size of the values held in the
+                                       object's variables, scaled down
+                                       according to the extend of data
+                                       sharing.
+          int    [OIM_DATA_SIZE_TOTAL]: unmodified total size of the values
+                                       held in the object's variables
+          int    [OIM_NO_INHERIT]:     1 if the program can't be inherited.
+          int    [OIM_NO_CLONE]:       1 if the program/blueprint can't be
+                                       cloned.
+          int    [OIM_NO_SHADOW]:      1 if the program's functions can't be
+                                       shadowed.
+          int    [OIM_SHARE_VARIABLES]:  1 if clones of this program share
+                                       their initial variable values with
+                                       the blueprint.
+
+          This call swaps in the program if necessary.
+          Note that the OIM_SIZE_xxx entries only give the size spent on
+          the structures and pointers, not the size of the variable data,
+          function code, and strings themselves.
+
+HISTORY
+-------
+::
+
+        Introduced in LDMud 3.2.6.
+        Changes in LDMud 3.2.7:
+          - new basic result OIB_REPLACED.
+          - basic result OIB_IS_WIZARD is always 0 if set_is_wizard()
+              is not available.
+          - basic result OIB_APPROVED is gone.
+        LDMud 3.2.8 added OIM_DATA_SIZE to the result of OINFO_MEMORY.
+        LDMud 3.2.9 added the index mechanism, OIM_NUM_INCLUDES,
+          OIM_NO_INHERIT, OIM_NO_SHADOW, OIM_NO_CLONE, OIM_SIZE_STRINGS_DATA,
+          OIM_SIZE_STRINGS_TOTAL, and OIM_DATA_SIZE_TOTAL to the result
+          of OINFO_MEMORY.
+        LDMud 3.3.378 added the OIM_SHARE_VARIABLES to the result
+          of OINFO_MEMORY.
+        LDMud 3.3.654 added the OIB_NEXT_CLEANUP to the result of OINFO_BASIC.
+
+SEE ALSO
+--------
+::
+
+        debug_info(E)
+
diff --git a/doc/sphinx/sefun/obsolete/exclude_alist.rst b/doc/sphinx/sefun/obsolete/exclude_alist.rst
new file mode 100644
index 0000000..3d6ce50
--- /dev/null
+++ b/doc/sphinx/sefun/obsolete/exclude_alist.rst
@@ -0,0 +1,11 @@
+exclude_alist()
+===============
+
+SYNOPSIS
+--------
+::
+
+	mixed *exclude_alist(int i, mixed *alist)
+
+Remove element i from alist.
+
diff --git a/doc/sphinx/sefun/obsolete/remove_alist.rst b/doc/sphinx/sefun/obsolete/remove_alist.rst
new file mode 100644
index 0000000..7c990c6
--- /dev/null
+++ b/doc/sphinx/sefun/obsolete/remove_alist.rst
@@ -0,0 +1,7 @@
+remove_alist()
+==============
+
+mixed *remove_alist(mixed key, mixed *alist)
+
+Removes element associated by key key from alist.
+
diff --git a/doc/sphinx/sefun/old_explode.rst b/doc/sphinx/sefun/old_explode.rst
new file mode 100644
index 0000000..ad13486
--- /dev/null
+++ b/doc/sphinx/sefun/old_explode.rst
@@ -0,0 +1,53 @@
+old_explode()
+=============
+
+FUNKTION
+--------
+::
+
+	string *old_explode(string str, string del)
+
+ARGUMENTE
+---------
+::
+
+	str - Der String, der aufgespaltet werden soll.
+	del - Der String, nach dem str aufgespalten werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+	Durch Ausschneiden von del wird der String str in ein Array von Strings
+	zerlegt. Dieses Array wird anschliessend zuruckgegeben.
+
+RUECKGABEWERT
+-------------
+::
+
+	Das Array mit den Bestandteilen der Zerlegung.
+
+BEMERKUNGEN
+-----------
+::
+
+	Das Verhalten von old_explode() entspricht dem dem explode()-Verhalten,
+	das in /doc/efun/explode als "altes" Verhalten bezeichnet wird, d.h.
+	Leerstrings an Anfang und Ende des zerlegten Strings werden entfernt!
+
+BEISPIELE
+---------
+::
+
+	strs = explode( "nimm alles", " "); => strs = ({ "nimm", "alles" })
+	strs = explode( "abc", "abc" );     => strs = ({ })
+	strs = explode( "ein test", "" );   => strs = ({ "ein test" })
+	strs = explode( "a b", "a");        => strs = ({ " b" });
+
+SIEHE AUCH
+----------
+::
+
+	explode(E), new_explode(E), efun::explode(E), sscanf(E)
+        implode(E), regexplode(E)
+
diff --git a/doc/sphinx/sefun/process_call.rst b/doc/sphinx/sefun/process_call.rst
new file mode 100644
index 0000000..24d03cc
--- /dev/null
+++ b/doc/sphinx/sefun/process_call.rst
@@ -0,0 +1,38 @@
+process_call()
+==============
+
+simul_efun::process_call(E)
+
+FUNKTION
+--------
+::
+
+     int process_call()
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt zurueck, ob die Ausfuehrung zum derzeitigen Zeitpunkt durch
+     process_string() ausgerufen wurde.
+
+BEISPIELE
+---------
+::
+
+     process_string("@@current_long@@");
+     ...
+     string current_long() {
+      if(process_call())
+       return("Dieser String wurde durch ein process_string eingefuegt.");
+      else return("Du hast die Funktion direkt gerufen!");
+     }
+
+SIEHE AUCH
+----------
+::
+
+     notify_fail(E), process_string(E), replace_personal(E)
+
+28. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/sefun/process_string.rst b/doc/sphinx/sefun/process_string.rst
new file mode 100644
index 0000000..25a66e2
--- /dev/null
+++ b/doc/sphinx/sefun/process_string.rst
@@ -0,0 +1,77 @@
+process_string()
+================
+
+process_string(E)
+
+FUNKTION
+--------
+::
+
+     string process_string(string str)
+     string process_string(closure cl)
+
+BESCHREIBUNG
+------------
+::
+
+     Durchsucht den String str nach Vorkommnissen von Substrings, die "Wert
+     durch Funktionsaufruf zu ersetzen" andeuten. Die Form ist: @@, gefolgt
+     durch einen impliziten Funktionsaufruf.
+
+     Der zu ersetzenden Substring hat die Form:
+     @@function[:filename][|argument1|argument2]@@
+
+     Die entsprechende Funktion muss einen String zurueckgeben, oder der
+     process_string() uebergebene String str wird nicht modifiziert.
+
+     process_string() arbeitet nicht rekursiv, object_name und argument sind
+     optionale Werte.
+
+     Falls eine Closure angegeben wurde, wird diese lediglich gerufen
+     und nicht gefiltert.
+
+ANMERKUNGEN
+-----------
+::
+
+     - Die Funktion, die gerufen werden soll, _muss_ mit einem Buchstaben
+		   anfangen, '_' ist nicht moeglich!
+     - folgendes Properties und Details werden bei der Abfrage ueber
+       process_string() gefiltert:
+       P_LONG, P_SHORT, P_READ_MSG, AddReadDetail()-Details und NPC-Chats
+       P_INT_LONG ueber int_long(), P_INT_SHORT ueber int_short()
+     - die Nutzung kann zu Sicherheitsproblemen fuehren, siehe auch
+       process_call()
+
+BEISPIEL
+--------
+::
+
+     // komplette Ersetzung ...
+     SetProp(P_LONG,"@@current_long@@");
+     ...
+     string current_long() {
+      if(x) return(break_string("Die Beschreibung."));
+      else return(break_string("Die andere Beschreibung."));
+     }
+
+     -> bei Abfrage: "Die Beschreibung." oder "Die andere Beschreibung."
+
+
+     // Teilersetzung
+     SetProp(P_SHORT, "Ein @@farbenfun|huebsch@@ Ding");
+     ...
+     string farbenfun(string str) {
+      return(str+" "+"gelbes");
+     }
+
+     -> bei Abfrage: "Ein huebsch gelbes Ding."
+
+SIEHE AUCH
+----------
+::
+
+     notify_fail(E), process_call(E), replace_personal(E)
+
+22. Nov. 2006 Arathorn
+
diff --git a/doc/sphinx/sefun/query_editing.rst b/doc/sphinx/sefun/query_editing.rst
new file mode 100644
index 0000000..83b1943
--- /dev/null
+++ b/doc/sphinx/sefun/query_editing.rst
@@ -0,0 +1,29 @@
+query_editing()
+===============
+
+DEPRECATED
+----------
+::
+
+SYNOPSIS
+--------
+::
+
+        mixed query_editing(object ob);
+
+BESCHREIBUNG
+------------
+::
+
+        Liefert 1, wenn <ob> interaktiv ist (das heisst, es gibt einen realen
+        Benutzer mit einer Socketverbindung zum Mud) und gerade mit ed() eine
+        Datei bearbeitet. Wenn ed() mit einem Funktionsnamen als zweites
+        Argument aufgerufen wird, wird das Objekt, aus dem ed() aufgerufen
+        wurde, geliefert, sonst 0.
+
+SIEHE AUCH
+----------
+::
+
+        ed(E)
+
diff --git a/doc/sphinx/sefun/query_idle.rst b/doc/sphinx/sefun/query_idle.rst
new file mode 100644
index 0000000..526bcac
--- /dev/null
+++ b/doc/sphinx/sefun/query_idle.rst
@@ -0,0 +1,21 @@
+query_idle()
+============
+
+SYNOPSIS
+--------
+::
+
+        int query_idle(object ob);
+
+BESCHREIBUNG
+------------
+::
+
+        Gibt an, seit wie vielen Sekunden ein Player Objekt <ob> idle ist.
+
+SIEHE AUCH
+----------
+::
+
+        interactive(E)
+
diff --git a/doc/sphinx/sefun/query_input_pending.rst b/doc/sphinx/sefun/query_input_pending.rst
new file mode 100644
index 0000000..02f8384
--- /dev/null
+++ b/doc/sphinx/sefun/query_input_pending.rst
@@ -0,0 +1,27 @@
+query_input_pending()
+=====================
+
+DEPRECATED
+----------
+::
+
+SYNOPSIS
+--------
+::
+
+        object query_input_pending(object ob);
+
+BESCHREIBUNG
+------------
+::
+
+        Wenn <ob> interaktiv und ein input_to() haengig ist, so liefert die
+        Efun das Objekt zurueck, welches den input_to() aufgerfuen hat. Ist
+        kein input_to() haengig, liefert die Funktion 0.
+
+SIEHE AUCH
+----------
+::
+
+        input_to(E), find_input_to(E), input_to_info(E), remove_input_to(E)
+
diff --git a/doc/sphinx/sefun/query_ip_name.rst b/doc/sphinx/sefun/query_ip_name.rst
new file mode 100644
index 0000000..d136ea9
--- /dev/null
+++ b/doc/sphinx/sefun/query_ip_name.rst
@@ -0,0 +1,28 @@
+query_ip_name()
+===============
+
+GESCHUETZT
+----------
+::
+
+SYNOPSIS
+--------
+::
+
+        string query_ip_name(object ob);
+
+BESCHREIBUNG
+------------
+::
+
+        Liefert den IP-Namen des Users <ob> oder des aktuellen Benutzers, wenn
+        <ob> nicht angegeben wurde. Der IP-Name wird durch den asynchronen
+        Prozess hname ermittelt. Wenn der IP-Name nicht ermittelt werden kann,
+        liefert query_ip_name() die IP-Nummer zurueck.
+
+SIEHE AUCH
+----------
+::
+
+        query_ip_number(E)
+
diff --git a/doc/sphinx/sefun/query_ip_number.rst b/doc/sphinx/sefun/query_ip_number.rst
new file mode 100644
index 0000000..cbd6229
--- /dev/null
+++ b/doc/sphinx/sefun/query_ip_number.rst
@@ -0,0 +1,43 @@
+query_ip_number()
+=================
+
+GESCHUETZT
+----------
+::
+
+SYNOPSIS
+--------
+::
+
+        string query_ip_number(object ob);
+        string query_ip_number(mixed & ob);
+
+BESCHREIBUNG
+------------
+::
+
+        Liefert die IP-Nummer des Benutzers <ob> oder des aktuellen Benutzers,
+        wenn <ob> nicht angegeben wurde.
+
+        Wenn <ob> als Referenz angegeben wird (dann muss es ein gueltiges
+        Objekt sein), wird dieses bei der Ausgabe auf die struct sockaddr_in
+        gesetzt. struct sockaddr_in ist ein Integer-Array, mit einem Integer
+        pro Adressbyte:
+
+            ob[0 .. 1] : sin_family
+            ob[2 .. 3] : sin_port
+            ob[4 .. 7] : sin_addr
+            ob[8 ..15] : nicht definiert.
+
+AENDERUNGEN
+-----------
+::
+
+        Die Rueckgabe von struct sockaddr_in wurde in 3.2.1@81 eingefuehrt.
+
+SIEHE AUCH
+----------
+::
+
+        query_ip_name(E)
+
diff --git a/doc/sphinx/sefun/query_limits.rst b/doc/sphinx/sefun/query_limits.rst
new file mode 100644
index 0000000..d2c4b0e
--- /dev/null
+++ b/doc/sphinx/sefun/query_limits.rst
@@ -0,0 +1,82 @@
+query_limits()
+==============
+
+DEPRECATED
+----------
+::
+
+SYNOPSIS
+--------
+::
+
+        #include <sys/rtlimits.h>
+
+        int *query_limits();
+        int *query_limits(int default);
+
+BESCHREIBUNG
+------------
+::
+
+        Liefert ein Array mit den momentan gueltigen Laufzeit Limiten bzw.
+        die standardmaessigen Laufzeit Limiten, wenn <default> wahr ist.
+        Die Eintraege im gelieferten Array bedeuten:
+
+        int[LIMIT_EVAL]:        die maximalen Eval Kosten
+        int[LIMIT_ARRAY]:       die maximale Anzahl Array Eintraege
+        int[LIMIT_MAPPING]:     die maximale Anzahl Mapping Eintraege
+        int[LIMIT_BYTE]:        die maximale Anzahl Bytes, die mit read_bytes()
+                                /write_bytes() bearbeitet werden koennen
+        int[LIMIT_FILE]:        die maximale Anzahl Bytes, die mit read_file()
+                                /write_file() bearbeitet werden koennen
+        int[LIMIT_CALLOUTS]:    die maximale Anzahl gleichzeitiger call_out()s
+        int[LIMIT_COST]:        wie die aktuellen Kosten einzurechnen sind
+
+        Ausser fuer LIMIT_COST ein Limit von '0' (auch LIMIT_UNLIMITED)
+        bedeutet 'keine Limit'.
+
+        LIMIT_COST hat diese Bedeutungen:
+
+          
+
+          wert > 0: Maximal <wert> fuer als Kosten fuer die aktuelle Ausfuehrung
+                    verwendet, ungeachtet wie lange sie tatsaechlich dauert.
+               = 0: ist die derzeite LIMIT_EVAL groesser als die vorherige
+                    LIMIT_EVAL, kostet die aktuelle Ausfuehrung nur 10
+                    Ticks; andernfalls werden die gesamten Kosten angerechnet.
+                < 0: (-wert)% der aktuellen Ausfuehrungskosten werden
+                     angerechnet.
+
+BEMERKUNGEN
+-----------
+::
+
+        "Aktuelle Kosten" bei LIMIT_COST hat im Falle der Benutzung von
+        limited() die Bedeutung von "im limited verbrauchte Kosten", steuert
+        also, wieviel der im Durchlaufen der Funktion im limited()
+        verbrauchten Ticks mit dem Ende von limited() angezogen wird.
+
+BEISPIELE
+---------
+::
+
+        query_limits()
+        --> liefert die momentan gueltigen Laufzeit Limiten.
+        query_limits(1)
+        --> liefert die standardmaessigen Laufzeit Limiten.
+
+AENDERUNGEN
+-----------
+::
+
+        Eingefuehrt in LDMud 3.2.7.
+        LIMIT_CALLOUTS wurde in LDMud 3.2.9 eingefuehrt.
+
+SIEHE AUCH
+----------
+::
+
+        limited(E), set_limits(E)
+
+16.05.2007, Zesstra
+
diff --git a/doc/sphinx/sefun/query_mud_port.rst b/doc/sphinx/sefun/query_mud_port.rst
new file mode 100644
index 0000000..8913433
--- /dev/null
+++ b/doc/sphinx/sefun/query_mud_port.rst
@@ -0,0 +1,39 @@
+query_mud_port()
+================
+
+DEPRECATED
+----------
+::
+
+SYNOPSIS
+--------
+::
+
+        int query_mud_port(void)
+        int query_mud_port(object user)
+        int query_mud_port(int num)
+
+DESCRIPTION
+-----------
+::
+
+        Returns the port number the parser uses for user connections.
+
+        If no argument is given, the port for this_player() is
+        returned. If this_player() is not existing or not interactive,
+        the first port number open for connections is returned.
+
+        If an user object is given, the port used for its connection
+        is returned.
+        If a positive number is given, the <num>th port number the
+        parser uses for connections is returned (given that there are
+        that many ports).
+        If -1 is given, the number of ports open for connections is
+        returned.
+
+SEE ALSO
+--------
+::
+
+        query_udp_port(E)
+
diff --git a/doc/sphinx/sefun/query_next_reset.rst b/doc/sphinx/sefun/query_next_reset.rst
new file mode 100644
index 0000000..e6afe90
--- /dev/null
+++ b/doc/sphinx/sefun/query_next_reset.rst
@@ -0,0 +1,47 @@
+query_next_reset()
+==================
+
+simul_efun::query_next_reset(E)
+
+FUNKTION
+--------
+::
+
+     varargs int query_next_reset(object ob)
+
+ARGUMENTE
+---------
+::
+
+     ob - das interessierende Objekt; wenn nicht angegeben, wird 
+          this_object() verwendet
+
+BESCHREIBUNG
+------------
+::
+
+     Diese sefun gibt den Zeitpunkt des naechsten Resets des Objektes ob 
+     zurueck. Die Angabe erfolgt in Sekunden, die seit dem 01. Januar 1970 
+     00:00:00 GMT verstrichen sind, analog zu time().
+
+     In der Regel erfolgt der Reset im naechsten Backend-Zyklus nach dem 
+     Faelligkeitszeitpunkt,  d.h. momentan in den nachfolgenden 2s.
+     Allerdings kann dies auch mal nen Zyklus laenger dauern (4s), wenn der
+     Driver viel zu tun hat.
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese sefun ist object_info()-Abfragen vorzuziehen, da die Parameter und
+     Rueckgabewerte von object_info() bei verschiedenen Gamedriverversionen
+     variieren koennen.
+
+SIEHE AUCH
+----------
+::
+
+     call_out(E), object_info(E), reset(L), set_next_reset(E), time(E)
+
+28.07.2014 Arathorn
+
diff --git a/doc/sphinx/sefun/query_once_interactive.rst b/doc/sphinx/sefun/query_once_interactive.rst
new file mode 100644
index 0000000..40e2a60
--- /dev/null
+++ b/doc/sphinx/sefun/query_once_interactive.rst
@@ -0,0 +1,21 @@
+query_once_interactive()
+========================
+
+SYNOPSIS
+--------
+::
+
+        int query_once_interactive(object obj);
+
+BESCHREIBUNG
+------------
+::
+
+        Wahr, wenn <obj> interaktiv ist oder dies einmal war.
+
+SIEHE AUCH
+----------
+::
+
+        remove_interactive(E)
+
diff --git a/doc/sphinx/sefun/query_shadowing.rst b/doc/sphinx/sefun/query_shadowing.rst
new file mode 100644
index 0000000..b04f077
--- /dev/null
+++ b/doc/sphinx/sefun/query_shadowing.rst
@@ -0,0 +1,38 @@
+query_shadowing()
+=================
+
+DEPRECATED
+----------
+::
+
+query_shadowing(E)
+
+FUNKTION
+--------
+::
+
+     object query_shadowing(object obj)
+
+BESCHREIBUNG
+------------
+::
+
+     Die Funktion gibt das derzeit vom Objekt <obj> beschattete Objekt
+     victim oder 0 zurueck.
+
+BEISPIELE
+---------
+::
+
+     // B beschattet A
+     query_shadowing(find_object(B)) == A
+
+SIEHE AUCH
+----------
+::
+
+     Generell:	     shadow(E), unshadow(E)
+     Rechte:	     query_allow_shadow(M), query_prevent_shadow(L)
+
+23.02.2016, Zesstra
+
diff --git a/doc/sphinx/sefun/query_snoop.rst b/doc/sphinx/sefun/query_snoop.rst
new file mode 100644
index 0000000..8cbf628
--- /dev/null
+++ b/doc/sphinx/sefun/query_snoop.rst
@@ -0,0 +1,26 @@
+query_snoop()
+=============
+
+DEPRECATED
+----------
+::
+
+SYNOPSIS
+--------
+::
+
+        object query_snoop(object victim)
+
+DESCRIPTION
+-----------
+::
+
+        Returns the user who currently snoops victim. The calling
+        object must be privileged by the master object.
+
+SEE ALSO
+--------
+::
+
+        snoop(E)
+
diff --git a/doc/sphinx/sefun/query_wiz_grp.rst b/doc/sphinx/sefun/query_wiz_grp.rst
new file mode 100644
index 0000000..f0a7d0e
--- /dev/null
+++ b/doc/sphinx/sefun/query_wiz_grp.rst
@@ -0,0 +1,34 @@
+query_wiz_grp()
+===============
+
+FUNKTION
+--------
+::
+
+        query_wiz_grp(string wiz)
+        query_wiz_grp(object wiz)
+
+ARGUMENTE
+---------
+::
+
+        wiz - Spieler, dessen Magierlevelgruppe ermittelt werden soll
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion ermittelt die Magiergruppe, der der Spieler wiz angehoert.
+
+RUECKGABEWERT
+-------------
+::
+
+        Die Magierlevelgruppe des Spielers.
+
+SIEHE AUCH
+----------
+::
+
+        /secure/wizlevels.h
+
diff --git a/doc/sphinx/sefun/query_wiz_level.rst b/doc/sphinx/sefun/query_wiz_level.rst
new file mode 100644
index 0000000..10a8df0
--- /dev/null
+++ b/doc/sphinx/sefun/query_wiz_level.rst
@@ -0,0 +1,70 @@
+query_wiz_level()
+=================
+
+FUNKTION
+--------
+::
+
+	int query_wiz_level(object ob)
+	int query_wiz_level(string ob)
+
+ARGUMENTE
+---------
+::
+
+	ob - Der Spieler/das Objekt, dessen Magierlevel ermittelt werden soll.
+       Es kann auch eine UID (z.B. "zesstra", "d.inseln.zesstra") als String
+       uebergeben werden.
+
+BESCHREIBUNG
+------------
+::
+
+	query_wiz_level() liefert den Magierlevel des Objekts ob zurueck.
+	Normale Spieler haben einen Magierlevel von 0, Seher normalerweise
+  einen von 1 (auf jeden Fall < 10).
+  Objekte bekommen folgende Level:
+  /d/           - 25
+  /p/           - 21
+  /obj/         - 0
+  /std/         - 0
+  /gilden/      - 30
+  /spellbooks/  - 30
+  /players/     - entsprechend Magier, 20 - 111
+  /secure/      - 100
+
+RUECKGABEWERT
+-------------
+::
+
+	Der Magierlevel des Spielers/Objekts.
+
+BEMERKUNGEN
+-----------
+::
+
+	Wird als Parameter ein String mit einem Spielernamen uebergeben, so 
+	kann auch der Magierlevel eines nicht eingeloggten Spielers heraus-
+	gefunden werden.
+
+BEISPIELE
+---------
+::
+
+	lv = query_wiz_level(find_player("jof"))
+	   => lv = 111, falls Jof eingeloggt ist.
+	lv = query_wiz_level("jof")
+           => lv = 111 in jedem Fall.
+
+SIEHE AUCH
+----------
+::
+
+	/secure/wizlevels.h
+
+LETZTE AeNDERUNG
+----------------
+::
+
+15.10.2007, Zesstra
+
diff --git a/doc/sphinx/sefun/read_data.rst b/doc/sphinx/sefun/read_data.rst
new file mode 100644
index 0000000..86b4472
--- /dev/null
+++ b/doc/sphinx/sefun/read_data.rst
@@ -0,0 +1,34 @@
+read_data()
+===========
+
+SYNOPSIS
+--------
+::
+
+        string read_data(string file, int start, int anzahl)
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion macht genau das, was read_file() tut (also siehe dort),
+        allerdings stellt sie sicher, dass <file> immer mit einem /data/
+        beginnt (setzt es also notfalls davor).
+        Es wird also immer irgendwo unterhalb von /data/ gelesen.
+
+BEISPIEL
+--------
+::
+
+        # read_data("/d/ebene/zesstra/blupp");
+        -> liest das File /data/d/ebene/zesstra/blupp.
+        # read_data("/data/d/ebene/zesstra/blupp");
+        -> tut dasselbe.
+
+SIEHE AUCH
+----------
+::
+
+        write_data()
+        read_file(E), write_file(E), read_bytes(E), write_file(E)
+
diff --git a/doc/sphinx/sefun/replace_personal.rst b/doc/sphinx/sefun/replace_personal.rst
new file mode 100644
index 0000000..ff7c07f
--- /dev/null
+++ b/doc/sphinx/sefun/replace_personal.rst
@@ -0,0 +1,123 @@
+replace_personal()
+==================
+
+FUNKTION
+--------
+::
+
+     varargs string replace_personal(string str, mixed *obs [, int caps]);
+
+DEFINIERT IN
+------------
+::
+
+     /secure/simul_efun.c
+
+ARGUMENTE
+---------
+::
+
+     str    - zu bearbeitender String
+     obs    - Liste von Objekt1, Objekt2, ..., Objekt9
+              (Objekte oder Strings)
+     caps   - 1 fuer Grossschreibung des Ersetzten nach Satzenden (.,?,!,")
+              0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+     Ersetzt in Strings
+     @WERx, @WESSENx, @WEMx, @WENx durch
+        Objectx->name(<casus>, 1);
+     @WERUx, @WESSENUx, @WEMUx, @WENUx durch
+        Objectx->name(<casus>);
+     @WERQPx, @WESSENQPx, @WEMQPx, @WENQPx durch
+        Objectx->QueryPronoun(<casus>);
+     @WERQAx, @WESSENQAx, @WEMQAx, @WENQAx durch
+        Objectx->QueryArticle(<casus>, 1, 1);
+     @WERQPPGNx, @WESSENQPPGNx, @WEMQPPGNx, @WENQPPGNx durch
+        Objectx->QueryPossPronoun(<gender>, <casus>, <number>);
+     oder den entsprechenden String bei "Objektx".            
+
+BEMERKUNGEN
+-----------
+::
+
+     x steht fuer die Position des Objekts/Strings in *obs, beginnend bei 1.
+
+     
+
+     Besonderheiten beim Possessivpronomen (@WERQPPGNx):
+     G muss durch das Geschlecht (M, F oder N) und N durch den Numerus (S 
+     oder P) ersetzt werden. 
+     Alle Angaben, auch der CASUS, beziehen sich dabei auf das Objekt, welches
+     besessen wird, nicht auf den Besitzer! Dieser ist bereits durch x 
+     bestimmt.
+
+     
+
+RUeCKGABEWERT
+-------------
+::
+
+     durchersetzter String 
+
+     
+
+Beispiele
+
+     replace_personal("@WER1", ({find_player("gloinson")}))
+     == "Gloinson"
+-----------------------------------------------------------------------------------------
+::
+
+     
+
+     replace_personal("@WEMQP1", ({find_player("gloinson")}))
+     == "ihm"     
+
+     
+
+     // unbestimmter und bestimmter Artikel:
+     replace_personal("@WER1 zueckt @WENU2 und verhaut @WEN3.", 
+                      ({find_player("gloinson"),
+                        find_object("/obj/mpa"), 
+                        find_object("/obj/wanderer")}))
+     == "Gloinson zueckt eine Zeitung und verhaut den Wanderer."
+
+     
+
+     // Beim Possessivpronomen beziehen sich WEN, F und P (Akkusativ,
+     // Femininum, Plural) auf die Taschen, nicht auf Kessa:
+     replace_personal("@WER1 steckt @WESSEN2 Turnschuhe in @WENQPPFP1 "
+                      "Taschen.", 
+                      ({find_player("kessa"), 
+                        find_player("gloinson")}))
+     == "Kessa steckt Gloinsons Turnschuhe in ihre Taschen."
+
+     // Ein Beispiel mit laengerem *obs:
+     replace_personal("@WER1 zieht @WENQPPMP1 neuen Turnschuhe an. @WER2 ist "
+                      "so beeindruckt, dass @WERQP2 @WEMQP1 @WENU3 auf die "
+                      "@WEN4 haut und die Schuhe in @WEMQPPFS2 Tasche "
+                      "verschwinden laesst. @WERU5 schaut zu und kichert "
+                      "irre. Wenn das @WER6 gesehen haette!",
+                      ({find_player("gloinson"), 
+                        find_player("kessa"),
+                        find_object("/obj/mpa"),                        
+                        "Birne",
+                        find_object("/obj/wanderer"),
+                        find_netdead("jof")}),1)
+     == "Gloinson zieht seine neuen Turnschuhe an. Kessa ist so beeindruckt, "
+        "dass sie ihm eine Zeitung auf die Birne haut und die Schuhe in ihrer "
+        "Tasche verschwinden laesst. Ein Wanderer schaut zu und kichert "
+        "irre. Wenn das Jof gesehen haette!"
+
+SIEHE AUCH
+----------
+::
+
+     AddCmd(L)
+
+05. September 2015, Arathorn
+
diff --git a/doc/sphinx/sefun/restore_object.rst b/doc/sphinx/sefun/restore_object.rst
new file mode 100644
index 0000000..42240ab
--- /dev/null
+++ b/doc/sphinx/sefun/restore_object.rst
@@ -0,0 +1,30 @@
+restore_object()
+================
+
+SYNOPSIS
+--------
+::
+
+        mixed restore_object(string name);
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Simul-Efun unterscheidet sich in einigen Details von der
+        Driver-Efun restore_object() (s. auch dort! Wichtig!).
+
+        1. diese sefun restauriert auch die mit F_SAVE markierten Properties
+        eines Objektes, sofern das Savefile von sefun save_object erstellt
+        wurde (was die efun des Driver nicht tut!).
+        2. Sofern ein Pfad angegeben wird und dieser NICHT mit /data/ beginnt,
+        wird das Savefile als erstes immer unter /data/+name gesucht. Erst wenn es
+        dort nicht gefunden wird, wird unter name gesucht.
+
+SIEHE AUCH
+----------
+::
+
+        save_object(E), restore_object(E), save_value(E)
+29.01.2017, Zesstra
+
diff --git a/doc/sphinx/sefun/save_object.rst b/doc/sphinx/sefun/save_object.rst
new file mode 100644
index 0000000..3dcc523
--- /dev/null
+++ b/doc/sphinx/sefun/save_object.rst
@@ -0,0 +1,34 @@
+save_object()
+=============
+
+SYNOPSIS
+--------
+::
+
+        mixed save_object(string name);
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Simul-Efun unterscheidet sich in einigen Details von der
+        Driver-Efun save_object() (s. auch dort! Wichtig!).
+        1. diese sefun speichert auch die mit F_SAVE markierten Properties
+        eines Objektes ab (was die efun des Driver nicht tut!).
+        2. Sofern ein Pfad angegeben wird und dieser NICHT mit /data/ beginnt,
+        wird /data/ vorangestellt, d.h. das Savefile wird immer unter /data/
+        erstellt.
+        3. das Format, in dem gespeichert wird, kann bei der sefun nicht
+        ausgewaehlt werden (ist aber auch nicht noetig!), sondern ein
+        mudlib-weiter Standard wird benutzt.
+        4. will man nicht in einem File speichern, sondern das, was im File
+        stehen wurde, als String zurueckhaben, muss man 0 als 'name'
+        uebergeben.
+
+SIEHE AUCH
+----------
+::
+
+        save_object(E), restore_object(E), save_value(E)
+29.01.2017, Zesstra
+
diff --git a/doc/sphinx/sefun/send_room.rst b/doc/sphinx/sefun/send_room.rst
new file mode 100644
index 0000000..044b5ca
--- /dev/null
+++ b/doc/sphinx/sefun/send_room.rst
@@ -0,0 +1,42 @@
+send_room()
+===========
+
+FUNKTION
+--------
+::
+
+varargs void send_room(object|string room, string msg, int msg_type,
+                       string msg_action, string msg_prefix,
+                       object *exclude, object origin)
+
+BESCHREIBUNG
+------------
+::
+
+        Sendet msg an alle Objekte in room durch Aufruf von ReceiveMsg() mit
+        den uebergebenen Argumenten.
+        Zur Bedeutung der Argumente siehe Manpage von ReceiveMsg().
+
+        Wenn das Raumobjekt mit seinem Namen angegeben ist, wird das Objekt
+        unter diesem Namen gesucht und und geladen, falls notwendig.
+
+        Mit dem Array <*exclude> kann man verhindern, dass die Nachricht an
+        die darin enthaltenen Objekte gesendet wird.
+        Das ist sinnvoll, wenn zB ein Spieler Ausloeser einer Meldung ist
+        und diese selbst nicht erhalten soll.
+
+        origin gibt an, welches Objekt die Meldung ausloest (muss nicht das
+        sendende Objekt selber) und wird vor allem fuer die Ignorierepruefung
+        verwendet. Default ist das sendende Objekt.
+
+        Letztendlich ist die sefun vergleichbar zu tell_room().
+
+SIEHE AUCH
+----------
+::
+
+        ReceiveMsg(L)
+        tell_object(E), tell_room(E), say(E), write(E)
+
+13.03.2016, Zesstra
+
diff --git a/doc/sphinx/sefun/set_heart_beat.rst b/doc/sphinx/sefun/set_heart_beat.rst
new file mode 100644
index 0000000..b236cae
--- /dev/null
+++ b/doc/sphinx/sefun/set_heart_beat.rst
@@ -0,0 +1,41 @@
+set_heart_beat()
+================
+
+SYNOPSIS
+--------
+::
+
+        int set_heart_beat(int flag);
+
+BESCHREIBUNG
+------------
+::
+
+        Schaltet den Heartbeat ein (1) oder aus (0). Der Treiber wendet die
+        Lfun heart_beat() auf das aktuelle Objekt alle __HEARTBEAT_INTERVAL__
+        Sekunden an, wenn der Heartbeat eingeschaltet ist. Ein Shadow
+        auf der Lfun wird ignoriert.
+
+        
+
+        Der Heartbeat sollte immer ausgeschaltet werden, wenn er nicht
+        gebraucht wird. Das reduziert die Systemauslastung.
+
+        Liefert '1' bei Erfolg, '0' bei Fehler.
+
+        Das Abschalten eines bereits abgeschalteten Heartbeats (und umgekehrt
+        das Einschalten eines bereits eingeschalteten Heartbeats) zaehlt
+        als Fehler.
+
+BEMERKUNGEN
+-----------
+::
+
+        __HEARTBEAT_INTERVAL__ ist in MG = 2 Sekunden
+
+SIEHE AUCH
+----------
+::
+
+        heart_beat(A), call_out(E)
+
diff --git a/doc/sphinx/sefun/set_light.rst b/doc/sphinx/sefun/set_light.rst
new file mode 100644
index 0000000..99d5bee
--- /dev/null
+++ b/doc/sphinx/sefun/set_light.rst
@@ -0,0 +1,32 @@
+set_light()
+===========
+
+SYNOPSIS
+--------
+::
+
+        int set_light(int n)
+
+DESCRIPTION
+-----------
+::
+
+        An object is by default dark. It can be set to not dark by
+        calling set_light(1). The environment will then also get this
+        light. The returned value is the total number of lights in
+        this room. So if you call set_light(0) it will return the
+        light level of the current object.
+
+        
+
+        Note that the value of the argument is added to the light of
+        the current object.
+
+BUGS
+----
+::
+
+	This handling of light by the parser is inappropriate for most
+	purposes: If you put a burning candle into a safe, the safe
+	will start to emit light.
+
diff --git a/doc/sphinx/sefun/set_living_name.rst b/doc/sphinx/sefun/set_living_name.rst
new file mode 100644
index 0000000..2beb859
--- /dev/null
+++ b/doc/sphinx/sefun/set_living_name.rst
@@ -0,0 +1,41 @@
+set_living_name()
+=================
+
+SYNOPSIS
+--------
+::
+
+        void set_living_name(string name)
+
+BESCHREIBUNG
+------------
+::
+
+        Setzt einen "Lebewesennamen" fuer das Objekt, indem Name und Objekt in
+        eine Tabelle eingetragen werden, welche von find_living() durchsucht 
+        wird. Nach Setzen des Namens kann das Objekt per find_living() 
+        gefunden werden.
+
+        Das Objekt muss ausserdem per enable_commands() als Lebewesen
+        markiert worden sein. Dies ist fuer alle von /std/npc erbenden NPCs
+        _automatisch_ der Fall und sollte daher nicht nochmal explizit gemacht
+        werden.
+
+        Alle von /std/npc erbenden NPCs setzen ebenfalls automatisch einen
+        LivingName, der lower_case(P_NAME) entspricht.
+
+        Ein Objekt kann nur einen Namen haben, mit dem es per find_living()
+        gesucht werden kann.
+
+SIEHE AUCH
+----------
+::
+
+        find_living(E), find_livings(E), find_player(E), enable_commands(E)
+
+LETZTE AeNDERNG
+---------------
+::
+
+19.10.2015, Arathorn
+
diff --git a/doc/sphinx/sefun/set_object_heart_beat.rst b/doc/sphinx/sefun/set_object_heart_beat.rst
new file mode 100644
index 0000000..e923926
--- /dev/null
+++ b/doc/sphinx/sefun/set_object_heart_beat.rst
@@ -0,0 +1,34 @@
+set_object_heart_beat()
+=======================
+
+FUNKTION
+--------
+::
+
+        int set_object_heart_beat(object ob, int on)
+
+ARGUMENTE
+---------
+::
+
+        ob - Objekt, dessen heart_beat veraendert werden soll
+        on - Soll der heart_beat ein- oder ausgeschaltet werden?
+
+BESCHREIBUNG
+------------
+::
+
+        Der heart_beat des Objektes wird ein- (on=1) oder aus- (on=0) geschaltet.
+
+RUECKGABEWERT
+-------------
+::
+
+        1, wenn das Setzen geklappt hat, ansonsten 0.
+
+SIEHE AUCH
+----------
+::
+
+        set_heart_beat(E), heart_beat(L), call_out(E)
+
diff --git a/doc/sphinx/sefun/sha1.rst b/doc/sphinx/sefun/sha1.rst
new file mode 100644
index 0000000..241cc3b
--- /dev/null
+++ b/doc/sphinx/sefun/sha1.rst
@@ -0,0 +1,44 @@
+sha1()
+======
+
+DEPRECATED
+----------
+::
+
+SYNOPSIS
+--------
+::
+
+        string sha1 (string arg)
+        string sha1 (int *  arg)
+
+BESCHREIBUNG
+------------
+::
+
+        Berechnet den SHA1-Hashwert von <arg>.
+        Das Argument kann ein String, oder ein Array von Zahlen sein (von
+        welchen nur das unterste Byte betrachted wird).
+
+BEISPIEL
+--------
+::
+
+        string s;
+
+        s = sha1("Hello");
+        s = sha1( ({ 'H', 'e', 'l', 'l', 'o' })
+
+HISTORY
+-------
+::
+
+        Eingefuehrt in LDMud 3.3.523.
+        LDMud 3.3.712 fuehrte Zaehlenarrays als Argument ein.
+
+SIEHE AUCH
+----------
+::
+
+        crypt(E), md5(E)
+
diff --git a/doc/sphinx/sefun/shadow.rst b/doc/sphinx/sefun/shadow.rst
new file mode 100644
index 0000000..556e11b
--- /dev/null
+++ b/doc/sphinx/sefun/shadow.rst
@@ -0,0 +1,162 @@
+shadow()
+========
+
+FUNKTION
+--------
+::
+
+     object shadow(object ob, int flag)
+
+ARGUMENTE
+---------
+::
+
+     object ob		- das vom shadow betroffene Objekt
+     int flag		- 0 fuer eine Shadow-Existenzabfrage
+                      1 fuer Shadow durch previous_object()
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn <flag> nicht 0 ist, wird das aktuelle Objekt dem Objekt obj
+     als Shadow uebergeworfen. Bei Erfolg wird das geshadowte Objekt
+     zurueckgegeben, sonst 0.
+     Wenn <flag> 0 ist, wird entweder 0 oder das geshadowte Objekt
+     zurueck gegeben.
+
+     Wenn ein Objekt A ein Objekt B beschattet, werden alle call_other() fuer
+     B auf A umgeleitet. Wenn die an B gerufene Funktion in A existiert, so
+     wird sie in A gerufen, bei Nichtexistenz in B.
+     A ist das einzige Objekt, welche die beschatteten Funktionen mit 
+     call_other() in B aufrufen kann, selbst B kann nicht per call_other() 
+     diese Funktion rufen.
+     Alle intern verwendeten Funktionen arbeiten jedoch weiterhin normal.
+
+     Das aufrufende Objekt muss vom Master-Objekt die Erlaubnis haben,
+     als Shadow zu wirken.
+
+     Es gibt folgende Kriterien fuer eine erfolgreiche Beschattung:
+     - das zu beschattende Objekt ob:
+       - ist weder ein access_rights-Objekt noch ein ROOT-Objekt
+       - gibt beim Aufruf von query_prevent_shadow(beschatter) eine 0
+         zurueck
+       - beschattet selbst niemanden
+       - hat kein '#pragma no_shadow' gesetzt
+     - der Beschatter:
+       - wird nicht selbst (direkt) beschattet
+       - beschattet noch niemanden (sonst folgt direkter Abbruch)
+       - hat kein environment()
+       - definiert/beschattet keine Methode, die im beschatteten Objekt ob 
+         als nomask definiert ist
+
+     Beschattet man ein Objekt A mit einem Objekt B und dann das Objekt A
+     zusaetzlich mit einem Objekt C, so wird eine Beschattungshierarchie
+     erstellt:
+
+     B macht shadow(A, 1)
+     B->A
+     C macht shadow(A, 1)
+     C->B->A
+
+BEISPIELE
+---------
+::
+
+     // wenn: B beschattet A, dann
+     shadow(find_object(A), 0) == B
+
+
+     // 3 Objekte beschatten in Hierarchie (liegt auch im Pfad)
+     --- aa.c ---
+     void fun() {
+         printf("%O [a] fun()\n", this_object());
+     }
+
+     void fun3() {
+         printf("%O [a] fun3()\n", this_object());
+     }
+
+     --- bb.c ---
+     int fun() {
+         printf("%O [b] fun()\n", this_object());
+         find_object("/doc/beispiele/shadow/aa")->fun();
+     }
+
+     void fun2() {
+         printf("%O [b] fun2()\n", this_object());
+         find_object("/doc/beispiele/shadow/aa")->fun3();
+         this_object()->fun3();
+     }
+
+     void do_shadow(object target) { shadow(target, 1); }
+
+     --- cc.c ---
+     int fun() {
+         printf("%O [c] fun()\n", this_object());
+         find_object("/doc/beispiele/shadow/aa")->fun();
+     }
+
+     void fun3() {
+         printf("%O [c] fun3()\n", this_object());
+     }
+
+     void do_shadow(object target) { shadow(target, 1); }
+
+     // darauf arbeitender Code
+
+     object a, b, c;
+
+     destruct("/doc/beispiele/shadow/aa");
+     a = load_object("/doc/beispiele/shadow/aa");
+     destruct("/doc/beispiele/shadow/bb");
+     b = load_object("/doc/beispiele/shadow/bb");
+     destruct("/doc/beispiele/shadow/cc");
+     c = load_object("/doc/beispiele/shadow/cc");
+
+     b->do_shadow(a);
+     c->do_shadow(a);
+     printf("--- a->fun() ---\n");
+     a->fun();
+     printf("--- b->fun() ---\n");
+     b->fun();
+     printf("--- c->fun() ---\n");
+     c->fun();
+     printf("--- b->fun2() ---\n");
+     b->fun2();
+
+     // ... und seine Ausgabe:
+
+     --- a->fun() ---
+     /doc/beispiele/shadow/cc [c] fun()
+     /doc/beispiele/shadow/bb [b] fun()
+     /doc/beispiele/shadow/aa [a] fun()
+     --- b->fun() ---
+     /doc/beispiele/shadow/cc [c] fun()
+     /doc/beispiele/shadow/bb [b] fun()
+     /doc/beispiele/shadow/aa [a] fun()
+     --- c->fun() ---
+     /doc/beispiele/shadow/cc [c] fun()
+     /doc/beispiele/shadow/bb [b] fun()
+     /doc/beispiele/shadow/aa [a] fun()
+     --- b->fun2() ---
+     /doc/beispiele/shadow/bb [b] fun2()
+     /doc/beispiele/shadow/aa [a] fun3()
+     /doc/beispiele/shadow/cc [c] fun3()
+
+     // Der erste Aufruf von b::fun2() in a findet sofort a::fun3()! Der
+     // Driver nimmt an, dass alle Shadows ab c bei Rufen von b nach a
+     // schon ihre Chance hatten.
+     // Der zweite Aufruf allerdings ist auf b und wird beim Durchgeben
+     // an a von c uebernommen.
+
+SIEHE AUCH
+----------
+::
+
+     Generell:	     shadow(E)
+     Rechte:	     query_allow_shadow(M), query_prevent_shadow(L)
+     Informationen:  query_shadowing(E)
+
+8.Aug 2007 Gloinson
+
diff --git a/doc/sphinx/sefun/shout.rst b/doc/sphinx/sefun/shout.rst
new file mode 100644
index 0000000..a81034d
--- /dev/null
+++ b/doc/sphinx/sefun/shout.rst
@@ -0,0 +1,94 @@
+shout()
+=======
+
+FUNKTION
+--------
+::
+
+     varargs void shout( string text, mixed where )
+
+DEFINIERT IN
+------------
+::
+
+     /secure/simul_efun.c
+
+ARGUMENTE
+---------
+::
+
+     text
+          Der Text, der ausgegeben werden soll
+
+     where [optional]
+          Wo soll man den Text ueberall hoeren koennen?
+
+BESCHREIBUNG
+------------
+::
+
+     Der Text 'text' wird an alle Spieler in einem Gebiet ausgegeben.
+     Wird der Parameter 'where' weggelassen bzw. ist er null, so geht der
+     Text an alle Spieler im Mud. Das catch_tell() von NPCs wird nicht
+     ausgeloest.
+
+     Ist 'where' eine Zahl != 0, so wird der Text nur an Spieler ausgegeben,
+     die sich im selben Gebiet aufhalten wie this_player(). Dabei wird die
+     Zugehoerigkeit zum selben Gebiet an den ersten zwei Ebenen des Pfades
+     der Raeume festgemacht. Befindet sich this_player() z.B. in
+     "/d/ebene/irgendwo", so geht der Text an alle Spieler, deren Aufenthalts-
+     orte in "/d/ebene/*" liegen.
+
+     Fuer 'where' kann auch direkt ein Pfad angegeben werden. So wuerde ein
+     'shout( txt, "/players/" )' an alle Spieler gehen, die sich in
+     (eigentlich nicht erwuenschten) Raeumen in /players/* befinden.
+
+     Um mit einem Aufruf gleich mehrere Pfade abzudecken, kann auch ein Array
+     von Strings uebergeben werden. Alle Pfade werden als 'regular expression'
+     interpretiert. Dadurch ist es moeglich, die Zielraeume auf einfache Art
+     sehr genau einzuschraenken.
+
+     HINWEIS: Bitte ueberleg vor jedem shout() genau, ob es wirklich noetig
+     ist, dass _jeder_ etwas davon mitbekommt oder ob es nicht vielleicht
+     sinnvoller ist, das Zielgebiet etwas einzuschraenken. Im Zweifelsfall
+     sollte der zustaendige RM aufpassen, dass die Spieler nicht durch allzu
+     zahlreiche shouts belaestigt werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+     keiner
+
+BEISPIELE
+---------
+::
+
+     shout( "Du spuerst, wie ein Zittern durch das MorgenGrauen geht.\n" );
+        Der allseits bekannte Text wird an alle Spieler im MG ausgegeben.
+
+     shout( "Du hoerst eine gewaltige Explosion.\n", 1 );
+        Von der Explosion bekommen alle Spieler in derselben Gegend etwas mit,
+        aber nicht am anderen Ende des Muds.
+
+     shout( "Irgendwo ist ein Baum umgefallen.\n", "/d/vland/" );
+        ... gibt eine Meldung aus, die keinen wirklich interessiert. Aber es
+        trifft eh nur Leute in einem unwichtigen Teil des MorgenGrauen. ;-)
+
+     shout( "Aufwachen Du Idler!\n", "/players/.*/workroom" );
+        Mit Hilfe von regular expressions kann man recht einfach z.B. alle
+        Workrooms auf einmal adressieren.
+
+     shout( "Halloooooo, Echoooooo!\n", ({ "/d/gebirge/", "/d/ebene/" }) );
+        Wenn der Spieler hoch oben auf dem Berg laut genug ruft, hoert man
+        ihn auch noch weit in der Ebene.
+
+SIEHE AUCH
+----------
+::
+
+     write(), say(), tell_object(), tell_room(), regexp()
+
+
+Last modified: Sun Nov 28 03:00:00 1999 by Tiamak
+
diff --git a/doc/sphinx/sefun/time2string.rst b/doc/sphinx/sefun/time2string.rst
new file mode 100644
index 0000000..635cffc
--- /dev/null
+++ b/doc/sphinx/sefun/time2string.rst
@@ -0,0 +1,79 @@
+time2string()
+=============
+
+FUNKTION
+--------
+::
+
+	string time2string( string format, int time )
+
+	
+
+ARGUMENTE
+---------
+::
+
+	format: String, der das Format der Zeitausgabe festlegt.
+	time: Eine Anzahl von Sekunden, die ausgegeben werden soll.
+
+ERGEBNIS
+--------
+::
+
+	Zeit in String-Form.
+
+BESCHREIBUNG
+------------
+::
+
+	Der Formatstring wird zurueckgegeben, wobei bestimmte Ersetzungs-
+	symbole durch passende Daten, die aus der Zeit berechnet werden,
+	ersetzt werden. Die Ersetzungssymbole funktionieren aehnlich
+	denen aus 'printf' bekannten Symbolen. Insbesondere kann eine
+	Feldbreite mit angegeben werden.
+
+	Folgende Ersetzungssymbole sind erlaubt:
+	%%	wird durch ein Prozent (%) ersetzt.
+	%n, %w, %d, %h, %m, %s
+		  werden durch die Anzahl der Monate, Wochen, Tage, Stunden, Minuten oder
+      Sekunden ersetzt. Die Funktion erkennt, welches die groesste benutzte
+		  Zeiteinheit ist und rechnet die keineren so um, dass sie zwischen 0 und
+      jeweiligen Maximum der Zeiteinheit liegen (59, 23 etc.) liegen.
+ 	%N	wird durch die Worte 'Woche' oder 'Wochen' ersetzt,
+      je nachdem welchen Wertd %n haette.
+ 	%W	wird durch die Worte 'Woche' oder 'Wochen' ersetzt,
+		  je nachdem welchen Wert %w haette.
+	%D	wird durch die Worte 'Tag' oder 'Tage' ersetzt,
+		  je nachdem welchen Wert %d haette.
+	%H,%M,%S
+		  werden durch die Worte 'Stunde(n)', 'Minute(n)' bzw. 'Sekunde(n)'
+      ersetzt.
+	%X	wird durch die groesste Zeiteinheit ersetzt, die nicht Null ist. Wenn
+      bei %X die Feldbreite 0 angegeben wird (also %0X), dann wird nicht der
+      ausgeschriebene Name, sonder eine Abkuerzung fuer die Zeiteinheit
+      ausgegeben. (Das sind dann 'd','h','m' oder 's'.)
+	%x	wird durch den numerischen Wert dieser Zeiteinheit
+		  ersetzt.
+
+			
+
+BEISPIELE
+---------
+::
+
+	time2string( "%m %M", 60 ) -> "1 Minute"
+	time2string( "%m %M", 120 ) -> "2 Minuten"
+	time2string( "%s %S", 125 ) -> "125 Sekunden"
+	time2string( "%m %M und %s %S" ) -> "2 Minuten und 5 Sekunden"
+	time2string( "%d:%02h:%02m:%02s", 10000 ) -> "0:02:46:40"
+	time2string( "%x %X", 3600 ) -> "1 Stunde"
+	time2string( "%x %0X", 3600 ) -> "1 h"
+	time2string( "%x %X", 360000 ) -> "4 Tage"
+	time2string( "%x %0X", 360000 ) -> "4 d"
+
+SIEHE AUCH
+----------
+::
+
+	sprintf(E)
+
diff --git a/doc/sphinx/sefun/update_actions.rst b/doc/sphinx/sefun/update_actions.rst
new file mode 100644
index 0000000..8684e12
--- /dev/null
+++ b/doc/sphinx/sefun/update_actions.rst
@@ -0,0 +1,63 @@
+update_actions()
+================
+
+FUNKTION
+--------
+::
+
+        void update_actions()
+
+ARGUMENTE
+---------
+::
+
+        keine
+
+BESCHREIBUNG
+------------
+::
+
+        Falls eine Aktion ein add_action() ausgeloest hat, werden mit dieser
+        Funktion die neuen Befehle bei allen Lebewesen im aufrufenden Objekt
+        bzw. in der Umgebung des aufrufenden Objektes aktiv.
+
+RUECKGABEWERT
+-------------
+::
+
+        keiner
+
+BEMERKUNGEN
+-----------
+::
+
+        Diese Funktion wird eigentlich nur benoetigt, wenn man mit add_action()
+        anstelle von AddCmd() arbeitet (zB. bei Objekten, die nicht
+        /std/thing/commands inheriten).
+
+BEISPIELE
+---------
+::
+
+        /* Normalerweise sollte man es SO gerade nicht machen. Stattdessen
+         * sollte die "kletter"-Funktion pruefen, ob die Luke geoeffnet ist, 
+         * und sich im Fehlerfall beschweren.
+         * So aber dient es als schoenes Beispiel fuer update_actions() ;)
+         */
+        int oeffne(string str)
+        {
+          if( str == "luke" ) {
+            write( "Du oeffnest die Luke. Du kannst jetzt nach unten klettern.\n");
+            add_action("kletter", "kletter", 1);
+            update_actions();
+            return 1;
+          }
+          return 0;
+        }
+
+SIEHE AUCH
+----------
+::
+
+  add_action(E), AddCmd(L), RemoveCmd(L)
+
diff --git a/doc/sphinx/sefun/upperstring.rst b/doc/sphinx/sefun/upperstring.rst
new file mode 100644
index 0000000..a180fd2
--- /dev/null
+++ b/doc/sphinx/sefun/upperstring.rst
@@ -0,0 +1,39 @@
+upperstring()
+=============
+
+FUNKTION
+--------
+::
+
+	string upperstring(string str)
+
+ARGUMENTE
+---------
+::
+
+	str - Der umzuwandelnde String.
+
+BESCHREIBUNG
+------------
+::
+
+	Alle Kleinbuchstaben in str werden in Grossbuchstaben umgewandelt.
+
+RUECKGABEWERT
+-------------
+::
+
+	Der umgewandelte String.
+
+BEISPIELE
+---------
+::
+
+	s = upperstring( "Na, Sterblicher!\n") => s = "NA, STERBLICHER!\n"
+
+SIEHE AUCH
+----------
+::
+
+	lowerstring(E), lower_case(E), capitalize(E)
+
diff --git a/doc/sphinx/sefun/uptime.rst b/doc/sphinx/sefun/uptime.rst
new file mode 100644
index 0000000..9160b44
--- /dev/null
+++ b/doc/sphinx/sefun/uptime.rst
@@ -0,0 +1,37 @@
+uptime()
+========
+
+FUNKTION
+--------
+::
+
+        string uptime()
+
+ARGUMENTE
+---------
+::
+
+        keine
+
+BESCHREIBUNG
+------------
+::
+
+        Liefert die aktuelle Uptime des MorgenGrauens.
+
+RUECKGABEWERT
+-------------
+::
+
+        Die Uptime als Zeitstring.
+
+BEISPIELE
+---------
+::
+
+        ut = uptime() => ut = "14 Tage, 9 Stunden, 3 Minuten und 7 Sekunden."
+
+SIEHE AUCH
+----------
+::
+
diff --git a/doc/sphinx/sefun/wizlist.rst b/doc/sphinx/sefun/wizlist.rst
new file mode 100644
index 0000000..b7d1996
--- /dev/null
+++ b/doc/sphinx/sefun/wizlist.rst
@@ -0,0 +1,87 @@
+wizlist()
+=========
+
+SYNOPSIS
+--------
+::
+
+  varargs void wizlist(string name, int sortkey ) 	
+
+DESCRIPTION
+-----------
+::
+
+  wizlist() liefert eine Liste mit verschiedenen Verbrauchsdaten 
+	zu Magiern. Es werden dabei normalerweise 21 Eintraege ausgegeben:
+  10 vor <name>, <name> selbst und 10 nach <name>.
+
+  Die Liste ist dabei folgendermassen aufgebaut:
+
+	1. WL_NAME
+	   Gesammelt werden die Daten pro UID. Hierbei zaehlt aber jede EUID, nicht
+     nur die von Magiern.
+     Das heisst, Objekte unter /d/polar/vanion/eispalast
+	   werden nicht unter "vanion" sondern unter "d.polar.vanion"
+	   abgerechnet.
+
+	2. WL_COMMANDS
+     Anzahl der diesem Objekt zugeordneten commands.
+
+	3. WL_COMMANDS * 100 / total_cmd 
+     Prozentualer Anteil an den gesamt verbrauchten commands.
+
+	4. WL_COST (links in der eckigen Klammer)
+     Anzahl der verbrauchten eval ticks. Dies ist zeitlich gewichtet, d.h.
+     nimmt im Lauf der Zeit ab, wenn nichts mehr dazu kommt.
+
+  5. WL_TOTAL_GIGACOST (rechts in der eckigen Klammer)
+     Anzahl der insgesamt verbrauchten eval ticks in Giga-Ticks.
+     Nicht zeitlich gewichtet.
+
+	6. WL_HEART_BEATS
+     Anzahl der ausgeloesten heart beats.
+
+  
+
+  7. WL_ARRAY_TOTAL
+
+  8. WL_MAPPING_TOTAL
+
+PARAMETERS: 
+  Wird name angegeben, wird erzwungen, dass die erwaehnte EUID mit
+  in der Liste dargestellt wird. Wird name nicht angegeben, wird es
+  automatisch auf this_player()->query_real_name() gesetzt.
+
+  Wird als name "TOP100" angegeben, wird die Top-100-Liste ausgegeben.
+
+  Wird als name "ALL" angegeben, wird die vollstaendige Liste aus-
+  gegeben.
+
+  Durch Angabe von sortkey kann die Liste nach einer der Spalten 
+  sortiert werden. Gueltige Werte sind die in /sys/wizlist.h ange-
+  gebenen Defines.
+
+	
+
+EXAMPLE 
+  > xeval wizlist("vanion", WL_HEART_BEATS)
+      Erzwingt Vanions Eintrag in der Liste und sortiert die Liste anhand
+      der durch die EUIDs ausgefuehrten heart beats.
+
+  > xeval wizlist("ALL", WL_EVAL_COST)
+      Zeigt die komplette Liste nach eval ticks-Verbauch sortiert an.
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+::
+
+SEE ALSO
+--------
+::
+
+      wizlist_info(E)
+
+LAST UPDATED
+------------
+::
+
+  09.05.2015, Zesstra
+
diff --git a/doc/sphinx/sefun/wizlist_info.rst b/doc/sphinx/sefun/wizlist_info.rst
new file mode 100644
index 0000000..68c8ae7
--- /dev/null
+++ b/doc/sphinx/sefun/wizlist_info.rst
@@ -0,0 +1,58 @@
+wizlist_info()
+==============
+
+GESCHUETZT
+----------
+::
+
+SYNOPSIS
+--------
+::
+
+        #include <sys/wizlist.h>
+
+        *mixed wizlist_info();
+
+BESCHREIBUNG
+------------
+::
+
+        Liefert ein Array mit Eintraegen aus der Wizlist (der internen
+        Magierliste). Die Benutzung muss durch das Masterobjekt erlaubt
+        werden.
+
+        Das Resultat ist ein Array mit einem Eintrag fuer jeden Magier (uid).
+        Jeder Eintrag enthaelt wiederum ein Array mit folgenden Elementen:
+
+            string  w[WL_NAME]          Name des Magiers
+            int w[WL_COMMANDS]          Gewichtete Anzahl Kommandi, die von
+                                        Objekten dieses Gottes ausgefuehrt
+                                        wurden
+            int w[WL_COSTE]             Gewichtete Summe der Eval-Kosten
+            int w[WL_GIGACOST]          Gewichtete Summe der Eval-Kosten
+            int W[WL_TOTAL_COST]        Totale Summe der Eval-Kosten
+            int w[WL_TOTAL_GIGACOST]    Totale Summe der Eval-Kosten
+            int w[WL_HEART_BEAT]        Gewichtete Anzahl der heat_beat()s
+            int w[WL_CALL_OUT]          Reserviert fuer call_out()s
+                                        (bisher nicht implementiert)
+            int w[WL_ARRAY_TOTAL]       Totale Groesse aller Arrays in
+                                        Elementen
+            mixed w[WL_EXTRA]           Die eigentliche Wizlist-Info
+
+        Die "gewichteten" Werte verfallen pro Stunde um 10%.
+
+AENDERUNGEN
+-----------
+::
+
+        LDMud 3.2.10 trennte das alte WL_EVAL_COST in WL_COST und WL_GIGACOST,
+        um laengeren Uptimes gerecht zu werden. Ausserdem wurde
+        WL_TOTAL_COST und WL_TOTAL_GIGACOST eingefuehrt.
+
+SIEHE AUCH
+----------
+::
+
+        privilege_violation(M), set_extra_wizinfo_size(E),
+        get_extra_wizinfo(E), set_extra_wizinfo(E)
+
diff --git a/doc/sphinx/sefun/write_data.rst b/doc/sphinx/sefun/write_data.rst
new file mode 100644
index 0000000..b776015
--- /dev/null
+++ b/doc/sphinx/sefun/write_data.rst
@@ -0,0 +1,39 @@
+write_data()
+============
+
+SYNOPSIS
+--------
+::
+
+        string write_data(string file, int start, int anzahl)
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Funktion macht genau das, was write_file() tut (also siehe dort),
+        allerdings stellt sie sicher, dass <file> immer mit einem /data/
+        beginnt (setzt es also notfalls davor).
+        Es wird also immer irgendwo unterhalb von /data/ geschrieben.
+
+        Die Benutzung dieser sefun wird dringend empfohlen, falls Daten
+        ausserhalb von Spielerobjekten gepeichert werden, damit Daten und
+        Code getrennt abgelegt sind. Dies vereinfacht z.B. die
+        Datensicherung.
+
+BEISPIEL
+--------
+::
+
+        # write_file("/d/ebene/zesstra/blupp", "Testdaten.\n");
+        -> schreibt in das File /data/d/ebene/zesstra/blupp.
+        # write_file("/data/d/ebene/zesstra/blupp", "Testdaten.\n");
+        -> tut dasselbe.
+
+SIEHE AUCH
+----------
+::
+
+        read_data()
+        read_file(E), write_file(E), read_bytes(E), write_file(E)
+