diff --git a/doc/sphinx/man/lfun/AddAction b/doc/sphinx/man/lfun/AddAction
new file mode 100644
index 0000000..29c83c1
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddAction
@@ -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/man/lfun/AddAdjective b/doc/sphinx/man/lfun/AddAdjective
new file mode 100644
index 0000000..a96a5e5
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddAdjective
@@ -0,0 +1,62 @@
+
+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/man/lfun/AddAmount b/doc/sphinx/man/lfun/AddAmount
new file mode 100644
index 0000000..59bb9b1
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddAmount
@@ -0,0 +1,44 @@
+
+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/man/lfun/AddClass b/doc/sphinx/man/lfun/AddClass
new file mode 100644
index 0000000..fee72e3
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddClass
@@ -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/man/lfun/AddCmd b/doc/sphinx/man/lfun/AddCmd
new file mode 100644
index 0000000..088da28
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddCmd
@@ -0,0 +1,244 @@
+
+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&f
+   euer|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&nbimpossible",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/man/lfun/AddCmd_bsp b/doc/sphinx/man/lfun/AddCmd_bsp
new file mode 100644
index 0000000..ec8ff17
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddCmd_bsp
@@ -0,0 +1,382 @@
+
+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|hin
+      auf|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/man/lfun/AddDefender b/doc/sphinx/man/lfun/AddDefender
new file mode 100644
index 0000000..5b33e14
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddDefender
@@ -0,0 +1,50 @@
+
+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/man/lfun/AddDetail b/doc/sphinx/man/lfun/AddDetail
new file mode 100644
index 0000000..951b48a
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddDetail
@@ -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/man/lfun/AddDrink b/doc/sphinx/man/lfun/AddDrink
new file mode 100644
index 0000000..4d722ec
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddDrink
@@ -0,0 +1,18 @@
+
+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/man/lfun/AddExit b/doc/sphinx/man/lfun/AddExit
new file mode 100644
index 0000000..384975f
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddExit
@@ -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/man/lfun/AddExp b/doc/sphinx/man/lfun/AddExp
new file mode 100644
index 0000000..a8bf488
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddExp
@@ -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/man/lfun/AddExtraLook b/doc/sphinx/man/lfun/AddExtraLook
new file mode 100644
index 0000000..7436f7e
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddExtraLook
@@ -0,0 +1,130 @@
+
+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/man/lfun/AddFixedObject b/doc/sphinx/man/lfun/AddFixedObject
new file mode 100644
index 0000000..5875ee2
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddFixedObject
@@ -0,0 +1,74 @@
+
+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
diff --git a/doc/sphinx/man/lfun/AddFood b/doc/sphinx/man/lfun/AddFood
new file mode 100644
index 0000000..b870a5e
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddFood
@@ -0,0 +1,18 @@
+
+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/man/lfun/AddFuel b/doc/sphinx/man/lfun/AddFuel
new file mode 100644
index 0000000..cd0b25e
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddFuel
@@ -0,0 +1,51 @@
+
+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/man/lfun/AddFun b/doc/sphinx/man/lfun/AddFun
new file mode 100644
index 0000000..5ba6cf1
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddFun
@@ -0,0 +1,85 @@
+
+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/man/lfun/AddId b/doc/sphinx/man/lfun/AddId
new file mode 100644
index 0000000..8c2aa4e
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddId
@@ -0,0 +1,75 @@
+
+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/man/lfun/AddInfo b/doc/sphinx/man/lfun/AddInfo
new file mode 100644
index 0000000..759a300
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddInfo
@@ -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/man/lfun/AddItem b/doc/sphinx/man/lfun/AddItem
new file mode 100644
index 0000000..222b24d
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddItem
@@ -0,0 +1,184 @@
+
+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/man/lfun/AddKnownPotion b/doc/sphinx/man/lfun/AddKnownPotion
new file mode 100644
index 0000000..874e55c
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddKnownPotion
@@ -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/man/lfun/AddMaterial b/doc/sphinx/man/lfun/AddMaterial
new file mode 100644
index 0000000..7f90d82
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddMaterial
@@ -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/man/lfun/AddMiniQuest b/doc/sphinx/man/lfun/AddMiniQuest
new file mode 100644
index 0000000..787e718
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddMiniQuest
@@ -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/man/lfun/AddMoney b/doc/sphinx/man/lfun/AddMoney
new file mode 100644
index 0000000..b9e16b2
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddMoney
@@ -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/man/lfun/AddMsg b/doc/sphinx/man/lfun/AddMsg
new file mode 100644
index 0000000..9faad47
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddMsg
@@ -0,0 +1,62 @@
+
+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/man/lfun/AddPlant b/doc/sphinx/man/lfun/AddPlant
new file mode 100644
index 0000000..ae2df8b
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddPlant
@@ -0,0 +1,84 @@
+
+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/man/lfun/AddPluralId b/doc/sphinx/man/lfun/AddPluralId
new file mode 100644
index 0000000..8d6d249
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddPluralId
@@ -0,0 +1,49 @@
+
+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/man/lfun/AddPursuer b/doc/sphinx/man/lfun/AddPursuer
new file mode 100644
index 0000000..f4839e6
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddPursuer
@@ -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/man/lfun/AddReadDetail b/doc/sphinx/man/lfun/AddReadDetail
new file mode 100644
index 0000000..7f36aa4
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddReadDetail
@@ -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/man/lfun/AddResistanceModifier b/doc/sphinx/man/lfun/AddResistanceModifier
new file mode 100644
index 0000000..b8a5ad8
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddResistanceModifier
@@ -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/man/lfun/AddRoomCmd b/doc/sphinx/man/lfun/AddRoomCmd
new file mode 100644
index 0000000..f4aeb68
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddRoomCmd
@@ -0,0 +1,23 @@
+
+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/man/lfun/AddRoomMessage b/doc/sphinx/man/lfun/AddRoomMessage
new file mode 100644
index 0000000..aa700c1
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddRoomMessage
@@ -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/man/lfun/AddRoute b/doc/sphinx/man/lfun/AddRoute
new file mode 100644
index 0000000..265fa8a
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddRoute
@@ -0,0 +1,114 @@
+
+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/man/lfun/AddSingularId b/doc/sphinx/man/lfun/AddSingularId
new file mode 100644
index 0000000..c45199e
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddSingularId
@@ -0,0 +1,49 @@
+
+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/man/lfun/AddSmells b/doc/sphinx/man/lfun/AddSmells
new file mode 100644
index 0000000..2623f98
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddSmells
@@ -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/man/lfun/AddSounds b/doc/sphinx/man/lfun/AddSounds
new file mode 100644
index 0000000..b14b976
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddSounds
@@ -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/man/lfun/AddSpecialDetail b/doc/sphinx/man/lfun/AddSpecialDetail
new file mode 100644
index 0000000..3405eec
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddSpecialDetail
@@ -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/man/lfun/AddSpecialExit b/doc/sphinx/man/lfun/AddSpecialExit
new file mode 100644
index 0000000..2f16c17
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddSpecialExit
@@ -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/man/lfun/AddSpecialInfo b/doc/sphinx/man/lfun/AddSpecialInfo
new file mode 100644
index 0000000..efc3067
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddSpecialInfo
@@ -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/man/lfun/AddSpell b/doc/sphinx/man/lfun/AddSpell
new file mode 100644
index 0000000..1661f8c
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddSpell
@@ -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/man/lfun/AddToMenu b/doc/sphinx/man/lfun/AddToMenu
new file mode 100644
index 0000000..01d46b6
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddToMenu
@@ -0,0 +1,271 @@
+
+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/man/lfun/AddTouchDetail b/doc/sphinx/man/lfun/AddTouchDetail
new file mode 100644
index 0000000..6ca61e8
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddTouchDetail
@@ -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/man/lfun/AllGroups b/doc/sphinx/man/lfun/AllGroups
new file mode 100644
index 0000000..6511189
--- /dev/null
+++ b/doc/sphinx/man/lfun/AllGroups
@@ -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/man/lfun/AllMaterials b/doc/sphinx/man/lfun/AllMaterials
new file mode 100644
index 0000000..57d1f6d
--- /dev/null
+++ b/doc/sphinx/man/lfun/AllMaterials
@@ -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/man/lfun/AssocMember b/doc/sphinx/man/lfun/AssocMember
new file mode 100644
index 0000000..139a670
--- /dev/null
+++ b/doc/sphinx/man/lfun/AssocMember
@@ -0,0 +1,74 @@
+
+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/man/lfun/Attack b/doc/sphinx/man/lfun/Attack
new file mode 100644
index 0000000..08a0c20
--- /dev/null
+++ b/doc/sphinx/man/lfun/Attack
@@ -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/man/lfun/BecomesNetAlive b/doc/sphinx/man/lfun/BecomesNetAlive
new file mode 100644
index 0000000..a64f328
--- /dev/null
+++ b/doc/sphinx/man/lfun/BecomesNetAlive
@@ -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/man/lfun/BecomesNetDead b/doc/sphinx/man/lfun/BecomesNetDead
new file mode 100644
index 0000000..8938d13
--- /dev/null
+++ b/doc/sphinx/man/lfun/BecomesNetDead
@@ -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/man/lfun/CannotSee b/doc/sphinx/man/lfun/CannotSee
new file mode 100644
index 0000000..b86d33a
--- /dev/null
+++ b/doc/sphinx/man/lfun/CannotSee
@@ -0,0 +1,49 @@
+
+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/man/lfun/ChangeMiniQuest b/doc/sphinx/man/lfun/ChangeMiniQuest
new file mode 100644
index 0000000..507bd68
--- /dev/null
+++ b/doc/sphinx/man/lfun/ChangeMiniQuest
@@ -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/man/lfun/ChangeReputation b/doc/sphinx/man/lfun/ChangeReputation
new file mode 100644
index 0000000..c3d010e
--- /dev/null
+++ b/doc/sphinx/man/lfun/ChangeReputation
@@ -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/man/lfun/CheckFindRestrictions b/doc/sphinx/man/lfun/CheckFindRestrictions
new file mode 100644
index 0000000..a021a58
--- /dev/null
+++ b/doc/sphinx/man/lfun/CheckFindRestrictions
@@ -0,0 +1,43 @@
+
+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/man/lfun/CheckLightType b/doc/sphinx/man/lfun/CheckLightType
new file mode 100644
index 0000000..2296ab8
--- /dev/null
+++ b/doc/sphinx/man/lfun/CheckLightType
@@ -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/man/lfun/CheckResistance b/doc/sphinx/man/lfun/CheckResistance
new file mode 100644
index 0000000..bcf64ca
--- /dev/null
+++ b/doc/sphinx/man/lfun/CheckResistance
@@ -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/man/lfun/CheckSensitiveAttack b/doc/sphinx/man/lfun/CheckSensitiveAttack
new file mode 100644
index 0000000..74f6220
--- /dev/null
+++ b/doc/sphinx/man/lfun/CheckSensitiveAttack
@@ -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/man/lfun/CheckSpellFatigue b/doc/sphinx/man/lfun/CheckSpellFatigue
new file mode 100644
index 0000000..ac9d3fe
--- /dev/null
+++ b/doc/sphinx/man/lfun/CheckSpellFatigue
@@ -0,0 +1,85 @@
+
+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/man/lfun/ClearRingBuffer b/doc/sphinx/man/lfun/ClearRingBuffer
new file mode 100644
index 0000000..869d298
--- /dev/null
+++ b/doc/sphinx/man/lfun/ClearRingBuffer
@@ -0,0 +1,56 @@
+
+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/man/lfun/Configure b/doc/sphinx/man/lfun/Configure
new file mode 100644
index 0000000..5a919ce
--- /dev/null
+++ b/doc/sphinx/man/lfun/Configure
@@ -0,0 +1,102 @@
+
+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/man/lfun/ConvMaterialList b/doc/sphinx/man/lfun/ConvMaterialList
new file mode 100644
index 0000000..874753b
--- /dev/null
+++ b/doc/sphinx/man/lfun/ConvMaterialList
@@ -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/man/lfun/CreateRingBuffer b/doc/sphinx/man/lfun/CreateRingBuffer
new file mode 100644
index 0000000..e10b671
--- /dev/null
+++ b/doc/sphinx/man/lfun/CreateRingBuffer
@@ -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/man/lfun/CustomizeObject b/doc/sphinx/man/lfun/CustomizeObject
new file mode 100644
index 0000000..2c7736a
--- /dev/null
+++ b/doc/sphinx/man/lfun/CustomizeObject
@@ -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/man/lfun/Damage b/doc/sphinx/man/lfun/Damage
new file mode 100644
index 0000000..b36061b
--- /dev/null
+++ b/doc/sphinx/man/lfun/Damage
@@ -0,0 +1,56 @@
+
+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/man/lfun/DeAssocMember b/doc/sphinx/man/lfun/DeAssocMember
new file mode 100644
index 0000000..f47d548
--- /dev/null
+++ b/doc/sphinx/man/lfun/DeAssocMember
@@ -0,0 +1,71 @@
+
+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/man/lfun/DeclAdj b/doc/sphinx/man/lfun/DeclAdj
new file mode 100644
index 0000000..d7a7f91
--- /dev/null
+++ b/doc/sphinx/man/lfun/DeclAdj
@@ -0,0 +1,68 @@
+
+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/man/lfun/Defend b/doc/sphinx/man/lfun/Defend
new file mode 100644
index 0000000..aa53945
--- /dev/null
+++ b/doc/sphinx/man/lfun/Defend
@@ -0,0 +1,175 @@
+
+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/man/lfun/DefendFunc b/doc/sphinx/man/lfun/DefendFunc
new file mode 100644
index 0000000..1683b3f
--- /dev/null
+++ b/doc/sphinx/man/lfun/DefendFunc
@@ -0,0 +1,107 @@
+
+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/man/lfun/DefendInfo b/doc/sphinx/man/lfun/DefendInfo
new file mode 100644
index 0000000..21d41ac
--- /dev/null
+++ b/doc/sphinx/man/lfun/DefendInfo
@@ -0,0 +1,216 @@
+
+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/man/lfun/DefendOther b/doc/sphinx/man/lfun/DefendOther
new file mode 100644
index 0000000..f0386f2
--- /dev/null
+++ b/doc/sphinx/man/lfun/DefendOther
@@ -0,0 +1,107 @@
+
+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/man/lfun/Defend_bsp b/doc/sphinx/man/lfun/Defend_bsp
new file mode 100644
index 0000000..9feb25f
--- /dev/null
+++ b/doc/sphinx/man/lfun/Defend_bsp
@@ -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/man/lfun/DeleteSpellFatigue b/doc/sphinx/man/lfun/DeleteSpellFatigue
new file mode 100644
index 0000000..f01755b
--- /dev/null
+++ b/doc/sphinx/man/lfun/DeleteSpellFatigue
@@ -0,0 +1,55 @@
+
+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/man/lfun/DeleteTimedAttrModifier b/doc/sphinx/man/lfun/DeleteTimedAttrModifier
new file mode 100644
index 0000000..2d1bd1e
--- /dev/null
+++ b/doc/sphinx/man/lfun/DeleteTimedAttrModifier
@@ -0,0 +1,53 @@
+
+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/man/lfun/DiscoverDoor b/doc/sphinx/man/lfun/DiscoverDoor
new file mode 100644
index 0000000..9046a0e
--- /dev/null
+++ b/doc/sphinx/man/lfun/DiscoverDoor
@@ -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/man/lfun/DistributeExp b/doc/sphinx/man/lfun/DistributeExp
new file mode 100644
index 0000000..e29427d
--- /dev/null
+++ b/doc/sphinx/man/lfun/DistributeExp
@@ -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/man/lfun/DoDecay b/doc/sphinx/man/lfun/DoDecay
new file mode 100644
index 0000000..695856a
--- /dev/null
+++ b/doc/sphinx/man/lfun/DoDecay
@@ -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/man/lfun/DoDecayMessage b/doc/sphinx/man/lfun/DoDecayMessage
new file mode 100644
index 0000000..671f9c7
--- /dev/null
+++ b/doc/sphinx/man/lfun/DoDecayMessage
@@ -0,0 +1,54 @@
+
+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/man/lfun/DoUnwear b/doc/sphinx/man/lfun/DoUnwear
new file mode 100644
index 0000000..56e53d3
--- /dev/null
+++ b/doc/sphinx/man/lfun/DoUnwear
@@ -0,0 +1,55 @@
+
+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/man/lfun/DoUnwield b/doc/sphinx/man/lfun/DoUnwield
new file mode 100644
index 0000000..d003bfc
--- /dev/null
+++ b/doc/sphinx/man/lfun/DoUnwield
@@ -0,0 +1,54 @@
+
+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/man/lfun/DoWear b/doc/sphinx/man/lfun/DoWear
new file mode 100644
index 0000000..e253290
--- /dev/null
+++ b/doc/sphinx/man/lfun/DoWear
@@ -0,0 +1,64 @@
+
+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/man/lfun/DoWield b/doc/sphinx/man/lfun/DoWield
new file mode 100644
index 0000000..6e6c06c
--- /dev/null
+++ b/doc/sphinx/man/lfun/DoWield
@@ -0,0 +1,63 @@
+
+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/man/lfun/DoorIsKnown b/doc/sphinx/man/lfun/DoorIsKnown
new file mode 100644
index 0000000..b799698
--- /dev/null
+++ b/doc/sphinx/man/lfun/DoorIsKnown
@@ -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/man/lfun/Dump b/doc/sphinx/man/lfun/Dump
new file mode 100644
index 0000000..9d8d7e0
--- /dev/null
+++ b/doc/sphinx/man/lfun/Dump
@@ -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/man/lfun/EnemyPresent b/doc/sphinx/man/lfun/EnemyPresent
new file mode 100644
index 0000000..bf3853c
--- /dev/null
+++ b/doc/sphinx/man/lfun/EnemyPresent
@@ -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/man/lfun/Enter b/doc/sphinx/man/lfun/Enter
new file mode 100644
index 0000000..0ebc7f0
--- /dev/null
+++ b/doc/sphinx/man/lfun/Enter
@@ -0,0 +1,64 @@
+
+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/man/lfun/EvalArmour b/doc/sphinx/man/lfun/EvalArmour
new file mode 100644
index 0000000..7daf07c
--- /dev/null
+++ b/doc/sphinx/man/lfun/EvalArmour
@@ -0,0 +1,40 @@
+
+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/man/lfun/EvalWeapon b/doc/sphinx/man/lfun/EvalWeapon
new file mode 100644
index 0000000..395a0a1
--- /dev/null
+++ b/doc/sphinx/man/lfun/EvalWeapon
@@ -0,0 +1,40 @@
+
+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/man/lfun/ExtraAttack b/doc/sphinx/man/lfun/ExtraAttack
new file mode 100644
index 0000000..cc0b109
--- /dev/null
+++ b/doc/sphinx/man/lfun/ExtraAttack
@@ -0,0 +1,49 @@
+
+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/man/lfun/FilterArmours b/doc/sphinx/man/lfun/FilterArmours
new file mode 100644
index 0000000..32a7f2b
--- /dev/null
+++ b/doc/sphinx/man/lfun/FilterArmours
@@ -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/man/lfun/FilterClothing b/doc/sphinx/man/lfun/FilterClothing
new file mode 100644
index 0000000..a7e1d01
--- /dev/null
+++ b/doc/sphinx/man/lfun/FilterClothing
@@ -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/man/lfun/FindBestArmours b/doc/sphinx/man/lfun/FindBestArmours
new file mode 100644
index 0000000..10a5d80
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindBestArmours
@@ -0,0 +1,64 @@
+
+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/man/lfun/FindBestWeapon b/doc/sphinx/man/lfun/FindBestWeapon
new file mode 100644
index 0000000..1aaeb0d
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindBestWeapon
@@ -0,0 +1,59 @@
+
+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/man/lfun/FindDistantEnemyVictim b/doc/sphinx/man/lfun/FindDistantEnemyVictim
new file mode 100644
index 0000000..5ea712d
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindDistantEnemyVictim
@@ -0,0 +1,55 @@
+
+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/man/lfun/FindDistantGroup b/doc/sphinx/man/lfun/FindDistantGroup
new file mode 100644
index 0000000..b94e048
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindDistantGroup
@@ -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/man/lfun/FindDistantGroups b/doc/sphinx/man/lfun/FindDistantGroups
new file mode 100644
index 0000000..efb3354
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindDistantGroups
@@ -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/man/lfun/FindEnemyVictim b/doc/sphinx/man/lfun/FindEnemyVictim
new file mode 100644
index 0000000..c5a81a6
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindEnemyVictim
@@ -0,0 +1,47 @@
+
+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/man/lfun/FindFarEnemyVictim b/doc/sphinx/man/lfun/FindFarEnemyVictim
new file mode 100644
index 0000000..455cf89
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindFarEnemyVictim
@@ -0,0 +1,53 @@
+
+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/man/lfun/FindGroup b/doc/sphinx/man/lfun/FindGroup
new file mode 100644
index 0000000..112c76f
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindGroup
@@ -0,0 +1,98 @@
+
+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/man/lfun/FindGroupN b/doc/sphinx/man/lfun/FindGroupN
new file mode 100644
index 0000000..b0104ee
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindGroupN
@@ -0,0 +1,67 @@
+
+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/man/lfun/FindGroupP b/doc/sphinx/man/lfun/FindGroupP
new file mode 100644
index 0000000..e4c297b
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindGroupP
@@ -0,0 +1,68 @@
+
+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/man/lfun/FindNearEnemyVictim b/doc/sphinx/man/lfun/FindNearEnemyVictim
new file mode 100644
index 0000000..4bd0458
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindNearEnemyVictim
@@ -0,0 +1,48 @@
+
+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/man/lfun/FindPotion b/doc/sphinx/man/lfun/FindPotion
new file mode 100644
index 0000000..5d8cae1
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindPotion
@@ -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/man/lfun/FindRangedTarget b/doc/sphinx/man/lfun/FindRangedTarget
new file mode 100644
index 0000000..5fa6776
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindRangedTarget
@@ -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/man/lfun/Flee b/doc/sphinx/man/lfun/Flee
new file mode 100644
index 0000000..995cf26
--- /dev/null
+++ b/doc/sphinx/man/lfun/Flee
@@ -0,0 +1,83 @@
+
+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/man/lfun/FreeHands b/doc/sphinx/man/lfun/FreeHands
new file mode 100644
index 0000000..c876b21
--- /dev/null
+++ b/doc/sphinx/man/lfun/FreeHands
@@ -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/man/lfun/GetAquarium b/doc/sphinx/man/lfun/GetAquarium
new file mode 100644
index 0000000..3896ac5
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetAquarium
@@ -0,0 +1,59 @@
+
+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/man/lfun/GetDetail b/doc/sphinx/man/lfun/GetDetail
new file mode 100644
index 0000000..7e5a092
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetDetail
@@ -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/man/lfun/GetDoorsMapping b/doc/sphinx/man/lfun/GetDoorsMapping
new file mode 100644
index 0000000..68beb0d
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetDoorsMapping
@@ -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/man/lfun/GetEnemies b/doc/sphinx/man/lfun/GetEnemies
new file mode 100644
index 0000000..e288250
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetEnemies
@@ -0,0 +1,53 @@
+
+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/man/lfun/GetExits b/doc/sphinx/man/lfun/GetExits
new file mode 100644
index 0000000..a235b1f
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetExits
@@ -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/man/lfun/GetFValue b/doc/sphinx/man/lfun/GetFValue
new file mode 100644
index 0000000..30db195
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetFValue
@@ -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/man/lfun/GetFValueO b/doc/sphinx/man/lfun/GetFValueO
new file mode 100644
index 0000000..25650fb
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetFValueO
@@ -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/man/lfun/GetFactor b/doc/sphinx/man/lfun/GetFactor
new file mode 100644
index 0000000..adc6a19
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetFactor
@@ -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/man/lfun/GetGroupMembers b/doc/sphinx/man/lfun/GetGroupMembers
new file mode 100644
index 0000000..8c765d7
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetGroupMembers
@@ -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/man/lfun/GetInfoArr b/doc/sphinx/man/lfun/GetInfoArr
new file mode 100644
index 0000000..ba6c4c4
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetInfoArr
@@ -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/man/lfun/GetMatMembership b/doc/sphinx/man/lfun/GetMatMembership
new file mode 100644
index 0000000..e25e991
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetMatMembership
@@ -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/man/lfun/GetOffset b/doc/sphinx/man/lfun/GetOffset
new file mode 100644
index 0000000..ee982b7
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetOffset
@@ -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/man/lfun/GetOwner b/doc/sphinx/man/lfun/GetOwner
new file mode 100644
index 0000000..92543f0
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetOwner
@@ -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/man/lfun/GetPhiolenInfos b/doc/sphinx/man/lfun/GetPhiolenInfos
new file mode 100644
index 0000000..ccd0f68
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetPhiolenInfos
@@ -0,0 +1,122 @@
+
+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/man/lfun/GetReputation b/doc/sphinx/man/lfun/GetReputation
new file mode 100644
index 0000000..b27d053
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetReputation
@@ -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/man/lfun/GetReputations b/doc/sphinx/man/lfun/GetReputations
new file mode 100644
index 0000000..134bd2c
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetReputations
@@ -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/man/lfun/GetValue b/doc/sphinx/man/lfun/GetValue
new file mode 100644
index 0000000..29eea03
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetValue
@@ -0,0 +1,46 @@
+
+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/man/lfun/GetValueO b/doc/sphinx/man/lfun/GetValueO
new file mode 100644
index 0000000..e9a7522
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetValueO
@@ -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/man/lfun/Gildenproperties b/doc/sphinx/man/lfun/Gildenproperties
new file mode 100644
index 0000000..dd5676f
--- /dev/null
+++ b/doc/sphinx/man/lfun/Gildenproperties
@@ -0,0 +1,186 @@
+
+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/man/lfun/GiveMiniQuest b/doc/sphinx/man/lfun/GiveMiniQuest
new file mode 100644
index 0000000..d208dbd
--- /dev/null
+++ b/doc/sphinx/man/lfun/GiveMiniQuest
@@ -0,0 +1,68 @@
+
+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/man/lfun/GiveQuest b/doc/sphinx/man/lfun/GiveQuest
new file mode 100644
index 0000000..daedc6c
--- /dev/null
+++ b/doc/sphinx/man/lfun/GiveQuest
@@ -0,0 +1,86 @@
+
+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/man/lfun/GroupName b/doc/sphinx/man/lfun/GroupName
new file mode 100644
index 0000000..7b819be
--- /dev/null
+++ b/doc/sphinx/man/lfun/GroupName
@@ -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/man/lfun/GuardExit b/doc/sphinx/man/lfun/GuardExit
new file mode 100644
index 0000000..88da3c9
--- /dev/null
+++ b/doc/sphinx/man/lfun/GuardExit
@@ -0,0 +1,111 @@
+
+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/man/lfun/Halt b/doc/sphinx/man/lfun/Halt
new file mode 100644
index 0000000..2fb45e8
--- /dev/null
+++ b/doc/sphinx/man/lfun/Halt
@@ -0,0 +1,52 @@
+
+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/man/lfun/HasMiniQuest b/doc/sphinx/man/lfun/HasMiniQuest
new file mode 100644
index 0000000..c832f00
--- /dev/null
+++ b/doc/sphinx/man/lfun/HasMiniQuest
@@ -0,0 +1,59 @@
+
+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/man/lfun/HitFunc b/doc/sphinx/man/lfun/HitFunc
new file mode 100644
index 0000000..2fb9b79
--- /dev/null
+++ b/doc/sphinx/man/lfun/HitFunc
@@ -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/man/lfun/Identify b/doc/sphinx/man/lfun/Identify
new file mode 100644
index 0000000..9f55541
--- /dev/null
+++ b/doc/sphinx/man/lfun/Identify
@@ -0,0 +1,43 @@
+
+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/man/lfun/InFight b/doc/sphinx/man/lfun/InFight
new file mode 100644
index 0000000..73fef03
--- /dev/null
+++ b/doc/sphinx/man/lfun/InFight
@@ -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/man/lfun/InList b/doc/sphinx/man/lfun/InList
new file mode 100644
index 0000000..82de3c9
--- /dev/null
+++ b/doc/sphinx/man/lfun/InList
@@ -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/man/lfun/InformAlcoholEffect b/doc/sphinx/man/lfun/InformAlcoholEffect
new file mode 100644
index 0000000..4967510
--- /dev/null
+++ b/doc/sphinx/man/lfun/InformAlcoholEffect
@@ -0,0 +1,65 @@
+
+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/man/lfun/InformDefend b/doc/sphinx/man/lfun/InformDefend
new file mode 100644
index 0000000..d6a401e
--- /dev/null
+++ b/doc/sphinx/man/lfun/InformDefend
@@ -0,0 +1,81 @@
+
+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/man/lfun/InformRowChange b/doc/sphinx/man/lfun/InformRowChange
new file mode 100644
index 0000000..7e7b804
--- /dev/null
+++ b/doc/sphinx/man/lfun/InformRowChange
@@ -0,0 +1,43 @@
+
+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/man/lfun/InformUnwear b/doc/sphinx/man/lfun/InformUnwear
new file mode 100644
index 0000000..01e9886
--- /dev/null
+++ b/doc/sphinx/man/lfun/InformUnwear
@@ -0,0 +1,48 @@
+
+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/man/lfun/InformUnwield b/doc/sphinx/man/lfun/InformUnwield
new file mode 100644
index 0000000..1f10e72
--- /dev/null
+++ b/doc/sphinx/man/lfun/InformUnwield
@@ -0,0 +1,45 @@
+
+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/man/lfun/InformWear b/doc/sphinx/man/lfun/InformWear
new file mode 100644
index 0000000..6860633
--- /dev/null
+++ b/doc/sphinx/man/lfun/InformWear
@@ -0,0 +1,48 @@
+
+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/man/lfun/InformWield b/doc/sphinx/man/lfun/InformWield
new file mode 100644
index 0000000..0c14c2a
--- /dev/null
+++ b/doc/sphinx/man/lfun/InformWield
@@ -0,0 +1,45 @@
+
+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/man/lfun/InsertEnemy b/doc/sphinx/man/lfun/InsertEnemy
new file mode 100644
index 0000000..84885db
--- /dev/null
+++ b/doc/sphinx/man/lfun/InsertEnemy
@@ -0,0 +1,53 @@
+
+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/man/lfun/InsertEnemyTeam b/doc/sphinx/man/lfun/InsertEnemyTeam
new file mode 100644
index 0000000..b25843d
--- /dev/null
+++ b/doc/sphinx/man/lfun/InsertEnemyTeam
@@ -0,0 +1,66 @@
+
+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/man/lfun/InsertSensitiveObject b/doc/sphinx/man/lfun/InsertSensitiveObject
new file mode 100644
index 0000000..534db19
--- /dev/null
+++ b/doc/sphinx/man/lfun/InsertSensitiveObject
@@ -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/man/lfun/InternalModifyAttack b/doc/sphinx/man/lfun/InternalModifyAttack
new file mode 100644
index 0000000..2d9f3eb
--- /dev/null
+++ b/doc/sphinx/man/lfun/InternalModifyAttack
@@ -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/man/lfun/InternalModifyDefend b/doc/sphinx/man/lfun/InternalModifyDefend
new file mode 100644
index 0000000..3015534
--- /dev/null
+++ b/doc/sphinx/man/lfun/InternalModifyDefend
@@ -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/man/lfun/IsArmour b/doc/sphinx/man/lfun/IsArmour
new file mode 100644
index 0000000..a7e5daf
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsArmour
@@ -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/man/lfun/IsBottle b/doc/sphinx/man/lfun/IsBottle
new file mode 100644
index 0000000..08f0125
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsBottle
@@ -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/man/lfun/IsClothing b/doc/sphinx/man/lfun/IsClothing
new file mode 100644
index 0000000..c51f3f6
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsClothing
@@ -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/man/lfun/IsEnemy b/doc/sphinx/man/lfun/IsEnemy
new file mode 100644
index 0000000..45fb1fc
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsEnemy
@@ -0,0 +1,50 @@
+
+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/man/lfun/IsEqual b/doc/sphinx/man/lfun/IsEqual
new file mode 100644
index 0000000..34d142f
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsEqual
@@ -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/man/lfun/IsPlayerCorpse b/doc/sphinx/man/lfun/IsPlayerCorpse
new file mode 100644
index 0000000..3cccc05
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsPlayerCorpse
@@ -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/man/lfun/IsRoom b/doc/sphinx/man/lfun/IsRoom
new file mode 100644
index 0000000..61ce904
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsRoom
@@ -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/man/lfun/IsTeamLeader b/doc/sphinx/man/lfun/IsTeamLeader
new file mode 100644
index 0000000..1880cc9
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsTeamLeader
@@ -0,0 +1,68 @@
+
+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/man/lfun/IsTeamMove b/doc/sphinx/man/lfun/IsTeamMove
new file mode 100644
index 0000000..584dc13
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsTeamMove
@@ -0,0 +1,60 @@
+
+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/man/lfun/IsUnit b/doc/sphinx/man/lfun/IsUnit
new file mode 100644
index 0000000..230f09e
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsUnit
@@ -0,0 +1,42 @@
+
+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/man/lfun/Kill b/doc/sphinx/man/lfun/Kill
new file mode 100644
index 0000000..1125345
--- /dev/null
+++ b/doc/sphinx/man/lfun/Kill
@@ -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/man/lfun/LearnSkill b/doc/sphinx/man/lfun/LearnSkill
new file mode 100644
index 0000000..caab276
--- /dev/null
+++ b/doc/sphinx/man/lfun/LearnSkill
@@ -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/man/lfun/Leave b/doc/sphinx/man/lfun/Leave
new file mode 100644
index 0000000..fef5e6f
--- /dev/null
+++ b/doc/sphinx/man/lfun/Leave
@@ -0,0 +1,64 @@
+
+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/man/lfun/LimitAbility b/doc/sphinx/man/lfun/LimitAbility
new file mode 100644
index 0000000..6c31eed
--- /dev/null
+++ b/doc/sphinx/man/lfun/LimitAbility
@@ -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/man/lfun/MaterialGroup b/doc/sphinx/man/lfun/MaterialGroup
new file mode 100644
index 0000000..1b4e61e
--- /dev/null
+++ b/doc/sphinx/man/lfun/MaterialGroup
@@ -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/man/lfun/MaterialList b/doc/sphinx/man/lfun/MaterialList
new file mode 100644
index 0000000..228f7a8
--- /dev/null
+++ b/doc/sphinx/man/lfun/MaterialList
@@ -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/man/lfun/MaterialName b/doc/sphinx/man/lfun/MaterialName
new file mode 100644
index 0000000..782a9f7
--- /dev/null
+++ b/doc/sphinx/man/lfun/MaterialName
@@ -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/man/lfun/MayAddObject b/doc/sphinx/man/lfun/MayAddObject
new file mode 100644
index 0000000..1df06ea
--- /dev/null
+++ b/doc/sphinx/man/lfun/MayAddObject
@@ -0,0 +1,55 @@
+
+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/man/lfun/MayAddWeight b/doc/sphinx/man/lfun/MayAddWeight
new file mode 100644
index 0000000..bc8e06d
--- /dev/null
+++ b/doc/sphinx/man/lfun/MayAddWeight
@@ -0,0 +1,72 @@
+
+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/man/lfun/Message b/doc/sphinx/man/lfun/Message
new file mode 100644
index 0000000..bee1d46
--- /dev/null
+++ b/doc/sphinx/man/lfun/Message
@@ -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/man/lfun/ModifyQuestTime b/doc/sphinx/man/lfun/ModifyQuestTime
new file mode 100644
index 0000000..432a362
--- /dev/null
+++ b/doc/sphinx/man/lfun/ModifyQuestTime
@@ -0,0 +1,66 @@
+
+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/man/lfun/ModifySkill b/doc/sphinx/man/lfun/ModifySkill
new file mode 100644
index 0000000..70c33ba
--- /dev/null
+++ b/doc/sphinx/man/lfun/ModifySkill
@@ -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/man/lfun/ModifySkillAttribute b/doc/sphinx/man/lfun/ModifySkillAttribute
new file mode 100644
index 0000000..1b4fe40
--- /dev/null
+++ b/doc/sphinx/man/lfun/ModifySkillAttribute
@@ -0,0 +1,133 @@
+
+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/man/lfun/More b/doc/sphinx/man/lfun/More
new file mode 100644
index 0000000..c504209
--- /dev/null
+++ b/doc/sphinx/man/lfun/More
@@ -0,0 +1,80 @@
+
+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/man/lfun/NPC_Killed_by b/doc/sphinx/man/lfun/NPC_Killed_by
new file mode 100644
index 0000000..3b8801d
--- /dev/null
+++ b/doc/sphinx/man/lfun/NPC_Killed_by
@@ -0,0 +1,28 @@
+
+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/man/lfun/NewDoor b/doc/sphinx/man/lfun/NewDoor
new file mode 100644
index 0000000..c534be5
--- /dev/null
+++ b/doc/sphinx/man/lfun/NewDoor
@@ -0,0 +1,252 @@
+
+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/man/lfun/NoParaObjects b/doc/sphinx/man/lfun/NoParaObjects
new file mode 100644
index 0000000..4b6013a
--- /dev/null
+++ b/doc/sphinx/man/lfun/NoParaObjects
@@ -0,0 +1,46 @@
+
+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/man/lfun/NotifyDestruct b/doc/sphinx/man/lfun/NotifyDestruct
new file mode 100644
index 0000000..31e02e9
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyDestruct
@@ -0,0 +1,66 @@
+
+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/man/lfun/NotifyInsert b/doc/sphinx/man/lfun/NotifyInsert
new file mode 100644
index 0000000..fa2f2ac
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyInsert
@@ -0,0 +1,47 @@
+
+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/man/lfun/NotifyLeave b/doc/sphinx/man/lfun/NotifyLeave
new file mode 100644
index 0000000..fbfc1c3
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyLeave
@@ -0,0 +1,47 @@
+
+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/man/lfun/NotifyMove b/doc/sphinx/man/lfun/NotifyMove
new file mode 100644
index 0000000..18261f8
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyMove
@@ -0,0 +1,83 @@
+
+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/man/lfun/NotifyPlayerDeath b/doc/sphinx/man/lfun/NotifyPlayerDeath
new file mode 100644
index 0000000..96678ea
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyPlayerDeath
@@ -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/man/lfun/NotifyRemove b/doc/sphinx/man/lfun/NotifyRemove
new file mode 100644
index 0000000..2604b77
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyRemove
@@ -0,0 +1,45 @@
+
+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/man/lfun/NotifyTimedAttrModExpired b/doc/sphinx/man/lfun/NotifyTimedAttrModExpired
new file mode 100644
index 0000000..09dc168
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyTimedAttrModExpired
@@ -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/man/lfun/NotifyXMAttrModLimitViolation b/doc/sphinx/man/lfun/NotifyXMAttrModLimitViolation
new file mode 100644
index 0000000..f3c54a4
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyXMAttrModLimitViolation
@@ -0,0 +1,35 @@
+
+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/man/lfun/Pacify b/doc/sphinx/man/lfun/Pacify
new file mode 100644
index 0000000..feca7bf
--- /dev/null
+++ b/doc/sphinx/man/lfun/Pacify
@@ -0,0 +1,146 @@
+
+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/man/lfun/PayIn b/doc/sphinx/man/lfun/PayIn
new file mode 100644
index 0000000..35616de
--- /dev/null
+++ b/doc/sphinx/man/lfun/PayIn
@@ -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/man/lfun/PlayerQuit b/doc/sphinx/man/lfun/PlayerQuit
new file mode 100644
index 0000000..0eb8fbf
--- /dev/null
+++ b/doc/sphinx/man/lfun/PlayerQuit
@@ -0,0 +1,37 @@
+
+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/man/lfun/PresentEnemies b/doc/sphinx/man/lfun/PresentEnemies
new file mode 100644
index 0000000..12ac650
--- /dev/null
+++ b/doc/sphinx/man/lfun/PresentEnemies
@@ -0,0 +1,95 @@
+
+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/man/lfun/PresentEnemyRows b/doc/sphinx/man/lfun/PresentEnemyRows
new file mode 100644
index 0000000..003d6c3
--- /dev/null
+++ b/doc/sphinx/man/lfun/PresentEnemyRows
@@ -0,0 +1,60 @@
+
+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/man/lfun/PresentPosition b/doc/sphinx/man/lfun/PresentPosition
new file mode 100644
index 0000000..c94d129
--- /dev/null
+++ b/doc/sphinx/man/lfun/PresentPosition
@@ -0,0 +1,58 @@
+
+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/man/lfun/PresentRows b/doc/sphinx/man/lfun/PresentRows
new file mode 100644
index 0000000..37e3ab8
--- /dev/null
+++ b/doc/sphinx/man/lfun/PresentRows
@@ -0,0 +1,120 @@
+
+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_S
+                        HOW_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_DAMAG
+            E: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/man/lfun/PresentTeamPositions b/doc/sphinx/man/lfun/PresentTeamPositions
new file mode 100644
index 0000000..3af354b
--- /dev/null
+++ b/doc/sphinx/man/lfun/PresentTeamPositions
@@ -0,0 +1,60 @@
+
+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/man/lfun/PresentTeamRows b/doc/sphinx/man/lfun/PresentTeamRows
new file mode 100644
index 0000000..7875918
--- /dev/null
+++ b/doc/sphinx/man/lfun/PresentTeamRows
@@ -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/man/lfun/PreventFollow b/doc/sphinx/man/lfun/PreventFollow
new file mode 100644
index 0000000..c3de6b1
--- /dev/null
+++ b/doc/sphinx/man/lfun/PreventFollow
@@ -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/man/lfun/PreventInsert b/doc/sphinx/man/lfun/PreventInsert
new file mode 100644
index 0000000..3635142
--- /dev/null
+++ b/doc/sphinx/man/lfun/PreventInsert
@@ -0,0 +1,71 @@
+
+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/man/lfun/PreventInsertLiving b/doc/sphinx/man/lfun/PreventInsertLiving
new file mode 100644
index 0000000..fbde29f
--- /dev/null
+++ b/doc/sphinx/man/lfun/PreventInsertLiving
@@ -0,0 +1,56 @@
+
+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/man/lfun/PreventLeave b/doc/sphinx/man/lfun/PreventLeave
new file mode 100644
index 0000000..24c33d2
--- /dev/null
+++ b/doc/sphinx/man/lfun/PreventLeave
@@ -0,0 +1,57 @@
+
+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/man/lfun/PreventLeaveLiving b/doc/sphinx/man/lfun/PreventLeaveLiving
new file mode 100644
index 0000000..20a5844
--- /dev/null
+++ b/doc/sphinx/man/lfun/PreventLeaveLiving
@@ -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/man/lfun/PreventMove b/doc/sphinx/man/lfun/PreventMove
new file mode 100644
index 0000000..920372d
--- /dev/null
+++ b/doc/sphinx/man/lfun/PreventMove
@@ -0,0 +1,109 @@
+
+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/man/lfun/Query b/doc/sphinx/man/lfun/Query
new file mode 100644
index 0000000..27c2d9e
--- /dev/null
+++ b/doc/sphinx/man/lfun/Query
@@ -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/man/lfun/QueryAllDoors b/doc/sphinx/man/lfun/QueryAllDoors
new file mode 100644
index 0000000..cdf7140
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryAllDoors
@@ -0,0 +1,52 @@
+
+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/man/lfun/QueryArmourByType b/doc/sphinx/man/lfun/QueryArmourByType
new file mode 100644
index 0000000..20fcab5
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryArmourByType
@@ -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/man/lfun/QueryArrived b/doc/sphinx/man/lfun/QueryArrived
new file mode 100644
index 0000000..9c4de60
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryArrived
@@ -0,0 +1,45 @@
+
+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/man/lfun/QueryArticle b/doc/sphinx/man/lfun/QueryArticle
new file mode 100644
index 0000000..3be5ecc
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryArticle
@@ -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/man/lfun/QueryAttribute b/doc/sphinx/man/lfun/QueryAttribute
new file mode 100644
index 0000000..978c6c0
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryAttribute
@@ -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/man/lfun/QueryAttributeOffset b/doc/sphinx/man/lfun/QueryAttributeOffset
new file mode 100644
index 0000000..b16d10c
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryAttributeOffset
@@ -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/man/lfun/QueryBuyFact b/doc/sphinx/man/lfun/QueryBuyFact
new file mode 100644
index 0000000..3f728c3
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryBuyFact
@@ -0,0 +1,41 @@
+
+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/man/lfun/QueryBuyValue b/doc/sphinx/man/lfun/QueryBuyValue
new file mode 100644
index 0000000..cecc57c
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryBuyValue
@@ -0,0 +1,56 @@
+
+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/man/lfun/QueryCoinsPerUnits b/doc/sphinx/man/lfun/QueryCoinsPerUnits
new file mode 100644
index 0000000..7261758
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryCoinsPerUnits
@@ -0,0 +1,57 @@
+
+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/man/lfun/QueryDamage b/doc/sphinx/man/lfun/QueryDamage
new file mode 100644
index 0000000..812636a
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryDamage
@@ -0,0 +1,61 @@
+
+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/man/lfun/QueryDefend b/doc/sphinx/man/lfun/QueryDefend
new file mode 100644
index 0000000..fa3fb11
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryDefend
@@ -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/man/lfun/QueryDisguise b/doc/sphinx/man/lfun/QueryDisguise
new file mode 100644
index 0000000..3cf4b8d
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryDisguise
@@ -0,0 +1,51 @@
+
+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/man/lfun/QueryDoorKey b/doc/sphinx/man/lfun/QueryDoorKey
new file mode 100644
index 0000000..f606c52
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryDoorKey
@@ -0,0 +1,71 @@
+
+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/man/lfun/QueryDoorStatus b/doc/sphinx/man/lfun/QueryDoorStatus
new file mode 100644
index 0000000..74f7034
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryDoorStatus
@@ -0,0 +1,48 @@
+
+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/man/lfun/QueryDu b/doc/sphinx/man/lfun/QueryDu
new file mode 100644
index 0000000..aa184cc
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryDu
@@ -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/man/lfun/QueryEnemies b/doc/sphinx/man/lfun/QueryEnemies
new file mode 100644
index 0000000..fc00c0e
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryEnemies
@@ -0,0 +1,54 @@
+
+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/man/lfun/QueryFlaw b/doc/sphinx/man/lfun/QueryFlaw
new file mode 100644
index 0000000..e12a119
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryFlaw
@@ -0,0 +1,63 @@
+
+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/man/lfun/QueryGenderString b/doc/sphinx/man/lfun/QueryGenderString
new file mode 100644
index 0000000..845758f
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryGenderString
@@ -0,0 +1,42 @@
+
+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/man/lfun/QueryGramsPerUnits b/doc/sphinx/man/lfun/QueryGramsPerUnits
new file mode 100644
index 0000000..62d5580
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryGramsPerUnits
@@ -0,0 +1,53 @@
+
+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/man/lfun/QueryGroupedKeys b/doc/sphinx/man/lfun/QueryGroupedKeys
new file mode 100644
index 0000000..5101e8d
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryGroupedKeys
@@ -0,0 +1,44 @@
+
+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/man/lfun/QueryGuest b/doc/sphinx/man/lfun/QueryGuest
new file mode 100644
index 0000000..61cfb04
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryGuest
@@ -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/man/lfun/QueryHealInfo b/doc/sphinx/man/lfun/QueryHealInfo
new file mode 100644
index 0000000..cc42fbc
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryHealInfo
@@ -0,0 +1,45 @@
+
+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/man/lfun/QueryMaterial b/doc/sphinx/man/lfun/QueryMaterial
new file mode 100644
index 0000000..94a5367
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryMaterial
@@ -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/man/lfun/QueryMaterialGroup b/doc/sphinx/man/lfun/QueryMaterialGroup
new file mode 100644
index 0000000..3365f73
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryMaterialGroup
@@ -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/man/lfun/QueryMaxQP b/doc/sphinx/man/lfun/QueryMaxQP
new file mode 100644
index 0000000..7b5aba2
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryMaxQP
@@ -0,0 +1,45 @@
+
+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/man/lfun/QueryMoney b/doc/sphinx/man/lfun/QueryMoney
new file mode 100644
index 0000000..775a65c
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryMoney
@@ -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/man/lfun/QueryName b/doc/sphinx/man/lfun/QueryName
new file mode 100644
index 0000000..71e65e3
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryName
@@ -0,0 +1,43 @@
+
+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/man/lfun/QueryOpenMiniQuestsForPlayer b/doc/sphinx/man/lfun/QueryOpenMiniQuestsForPlayer
new file mode 100644
index 0000000..f43d7cc
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryOpenMiniQuestsForPlayer
@@ -0,0 +1,80 @@
+
+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/man/lfun/QueryOwn b/doc/sphinx/man/lfun/QueryOwn
new file mode 100644
index 0000000..22e9e5f
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryOwn
@@ -0,0 +1,53 @@
+
+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/man/lfun/QueryPassengers b/doc/sphinx/man/lfun/QueryPassengers
new file mode 100644
index 0000000..d6f9331
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryPassengers
@@ -0,0 +1,51 @@
+
+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/man/lfun/QueryPosition b/doc/sphinx/man/lfun/QueryPosition
new file mode 100644
index 0000000..08af6fe
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryPosition
@@ -0,0 +1,48 @@
+
+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/man/lfun/QueryPossPronoun b/doc/sphinx/man/lfun/QueryPossPronoun
new file mode 100644
index 0000000..90af78a
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryPossPronoun
@@ -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/man/lfun/QueryPrayRoom b/doc/sphinx/man/lfun/QueryPrayRoom
new file mode 100644
index 0000000..b783174
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryPrayRoom
@@ -0,0 +1,50 @@
+
+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/man/lfun/QueryPreferedEnemy b/doc/sphinx/man/lfun/QueryPreferedEnemy
new file mode 100644
index 0000000..10a8ae0
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryPreferedEnemy
@@ -0,0 +1,56 @@
+
+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/man/lfun/QueryPronoun b/doc/sphinx/man/lfun/QueryPronoun
new file mode 100644
index 0000000..39088f9
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryPronoun
@@ -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/man/lfun/QueryProp b/doc/sphinx/man/lfun/QueryProp
new file mode 100644
index 0000000..71c4fdf
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryProp
@@ -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/man/lfun/QueryProperties b/doc/sphinx/man/lfun/QueryProperties
new file mode 100644
index 0000000..6949e0f
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryProperties
@@ -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/man/lfun/QueryQuest b/doc/sphinx/man/lfun/QueryQuest
new file mode 100644
index 0000000..338ed77
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryQuest
@@ -0,0 +1,53 @@
+
+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/man/lfun/QueryQuestTime b/doc/sphinx/man/lfun/QueryQuestTime
new file mode 100644
index 0000000..9b93c8d
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryQuestTime
@@ -0,0 +1,48 @@
+
+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/man/lfun/QueryRealAttribute b/doc/sphinx/man/lfun/QueryRealAttribute
new file mode 100644
index 0000000..246008f
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryRealAttribute
@@ -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/man/lfun/QuerySellValue b/doc/sphinx/man/lfun/QuerySellValue
new file mode 100644
index 0000000..4d5a518
--- /dev/null
+++ b/doc/sphinx/man/lfun/QuerySellValue
@@ -0,0 +1,54 @@
+
+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/man/lfun/QuerySkill b/doc/sphinx/man/lfun/QuerySkill
new file mode 100644
index 0000000..0978df1
--- /dev/null
+++ b/doc/sphinx/man/lfun/QuerySkill
@@ -0,0 +1,56 @@
+
+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/man/lfun/QuerySkillAbility b/doc/sphinx/man/lfun/QuerySkillAbility
new file mode 100644
index 0000000..fd8666f
--- /dev/null
+++ b/doc/sphinx/man/lfun/QuerySkillAbility
@@ -0,0 +1,47 @@
+
+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/man/lfun/QuerySkillAttribute b/doc/sphinx/man/lfun/QuerySkillAttribute
new file mode 100644
index 0000000..1b3a71e
--- /dev/null
+++ b/doc/sphinx/man/lfun/QuerySkillAttribute
@@ -0,0 +1,87 @@
+
+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/man/lfun/QuerySkillAttributeModifier b/doc/sphinx/man/lfun/QuerySkillAttributeModifier
new file mode 100644
index 0000000..055815e
--- /dev/null
+++ b/doc/sphinx/man/lfun/QuerySkillAttributeModifier
@@ -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/man/lfun/QuerySkillBonus b/doc/sphinx/man/lfun/QuerySkillBonus
new file mode 100644
index 0000000..1cb82e8
--- /dev/null
+++ b/doc/sphinx/man/lfun/QuerySkillBonus
@@ -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/man/lfun/QueryStorageRoom b/doc/sphinx/man/lfun/QueryStorageRoom
new file mode 100644
index 0000000..4442237
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryStorageRoom
@@ -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/man/lfun/QueryTimedAttrModifier b/doc/sphinx/man/lfun/QueryTimedAttrModifier
new file mode 100644
index 0000000..4d858a8
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryTimedAttrModifier
@@ -0,0 +1,67 @@
+
+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/man/lfun/QueryTotalQP b/doc/sphinx/man/lfun/QueryTotalQP
new file mode 100644
index 0000000..1471010
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryTotalQP
@@ -0,0 +1,43 @@
+
+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/man/lfun/QueryUser b/doc/sphinx/man/lfun/QueryUser
new file mode 100644
index 0000000..ad1e4fa
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryUser
@@ -0,0 +1,77 @@
+
+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/man/lfun/QueryValidObject b/doc/sphinx/man/lfun/QueryValidObject
new file mode 100644
index 0000000..649a0b2
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryValidObject
@@ -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/man/lfun/ReceiveMsg b/doc/sphinx/man/lfun/ReceiveMsg
new file mode 100644
index 0000000..cd1a34d
--- /dev/null
+++ b/doc/sphinx/man/lfun/ReceiveMsg
@@ -0,0 +1,278 @@
+
+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/man/lfun/RegisterEvent b/doc/sphinx/man/lfun/RegisterEvent
new file mode 100644
index 0000000..a664b3b
--- /dev/null
+++ b/doc/sphinx/man/lfun/RegisterEvent
@@ -0,0 +1,113 @@
+
+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/man/lfun/RegisterHelperNPC b/doc/sphinx/man/lfun/RegisterHelperNPC
new file mode 100644
index 0000000..f8b6a2e
--- /dev/null
+++ b/doc/sphinx/man/lfun/RegisterHelperNPC
@@ -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/man/lfun/RegisterHelperObject b/doc/sphinx/man/lfun/RegisterHelperObject
new file mode 100644
index 0000000..af33a5c
--- /dev/null
+++ b/doc/sphinx/man/lfun/RegisterHelperObject
@@ -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/man/lfun/RemoveAdjective b/doc/sphinx/man/lfun/RemoveAdjective
new file mode 100644
index 0000000..bd1796f
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveAdjective
@@ -0,0 +1,43 @@
+
+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/man/lfun/RemoveClass b/doc/sphinx/man/lfun/RemoveClass
new file mode 100644
index 0000000..26b0b79
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveClass
@@ -0,0 +1,38 @@
+
+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/man/lfun/RemoveCmd b/doc/sphinx/man/lfun/RemoveCmd
new file mode 100644
index 0000000..6adffbf
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveCmd
@@ -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/man/lfun/RemoveDefender b/doc/sphinx/man/lfun/RemoveDefender
new file mode 100644
index 0000000..1dec97a
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveDefender
@@ -0,0 +1,52 @@
+
+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/man/lfun/RemoveDetail b/doc/sphinx/man/lfun/RemoveDetail
new file mode 100644
index 0000000..48a0330
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveDetail
@@ -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/man/lfun/RemoveExit b/doc/sphinx/man/lfun/RemoveExit
new file mode 100644
index 0000000..6854229
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveExit
@@ -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/man/lfun/RemoveExtraLook b/doc/sphinx/man/lfun/RemoveExtraLook
new file mode 100644
index 0000000..0369992
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveExtraLook
@@ -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/man/lfun/RemoveFixedObject b/doc/sphinx/man/lfun/RemoveFixedObject
new file mode 100644
index 0000000..22179de
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveFixedObject
@@ -0,0 +1,62 @@
+
+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/man/lfun/RemoveFromMenu b/doc/sphinx/man/lfun/RemoveFromMenu
new file mode 100644
index 0000000..fdcb916
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveFromMenu
@@ -0,0 +1,55 @@
+
+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/man/lfun/RemoveFunc b/doc/sphinx/man/lfun/RemoveFunc
new file mode 100644
index 0000000..bf01ae9
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveFunc
@@ -0,0 +1,113 @@
+
+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/man/lfun/RemoveId b/doc/sphinx/man/lfun/RemoveId
new file mode 100644
index 0000000..efd709d
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveId
@@ -0,0 +1,44 @@
+
+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/man/lfun/RemoveInfo b/doc/sphinx/man/lfun/RemoveInfo
new file mode 100644
index 0000000..75485c6
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveInfo
@@ -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/man/lfun/RemoveItem b/doc/sphinx/man/lfun/RemoveItem
new file mode 100644
index 0000000..a21cdc2
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveItem
@@ -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/man/lfun/RemoveKnownPotion b/doc/sphinx/man/lfun/RemoveKnownPotion
new file mode 100644
index 0000000..f7af610
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveKnownPotion
@@ -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/man/lfun/RemovePluralId b/doc/sphinx/man/lfun/RemovePluralId
new file mode 100644
index 0000000..23f394a
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemovePluralId
@@ -0,0 +1,49 @@
+
+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/man/lfun/RemovePursuer b/doc/sphinx/man/lfun/RemovePursuer
new file mode 100644
index 0000000..cf8f0dc
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemovePursuer
@@ -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/man/lfun/RemoveReadDetail b/doc/sphinx/man/lfun/RemoveReadDetail
new file mode 100644
index 0000000..495dfe3
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveReadDetail
@@ -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/man/lfun/RemoveResistanceModifier b/doc/sphinx/man/lfun/RemoveResistanceModifier
new file mode 100644
index 0000000..ca14c74
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveResistanceModifier
@@ -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/man/lfun/RemoveRoute b/doc/sphinx/man/lfun/RemoveRoute
new file mode 100644
index 0000000..61fb082
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveRoute
@@ -0,0 +1,42 @@
+
+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/man/lfun/RemoveSensitiveObject b/doc/sphinx/man/lfun/RemoveSensitiveObject
new file mode 100644
index 0000000..0678e70
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveSensitiveObject
@@ -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/man/lfun/RemoveSingularId b/doc/sphinx/man/lfun/RemoveSingularId
new file mode 100644
index 0000000..fcf0c3d
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveSingularId
@@ -0,0 +1,49 @@
+
+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/man/lfun/RemoveSkillAttributeModifier b/doc/sphinx/man/lfun/RemoveSkillAttributeModifier
new file mode 100644
index 0000000..5fa69b2
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveSkillAttributeModifier
@@ -0,0 +1,83 @@
+
+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/man/lfun/RemoveSmells b/doc/sphinx/man/lfun/RemoveSmells
new file mode 100644
index 0000000..b56fe27
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveSmells
@@ -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/man/lfun/RemoveSounds b/doc/sphinx/man/lfun/RemoveSounds
new file mode 100644
index 0000000..4ef4263
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveSounds
@@ -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/man/lfun/RemoveSpecialDetail b/doc/sphinx/man/lfun/RemoveSpecialDetail
new file mode 100644
index 0000000..96a7a39
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveSpecialDetail
@@ -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/man/lfun/RemoveSpecialExit b/doc/sphinx/man/lfun/RemoveSpecialExit
new file mode 100644
index 0000000..ee2e8e8
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveSpecialExit
@@ -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/man/lfun/RemoveTouchDetail b/doc/sphinx/man/lfun/RemoveTouchDetail
new file mode 100644
index 0000000..4f6ace3
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveTouchDetail
@@ -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/man/lfun/ResizeRingBuffer b/doc/sphinx/man/lfun/ResizeRingBuffer
new file mode 100644
index 0000000..17c3332
--- /dev/null
+++ b/doc/sphinx/man/lfun/ResizeRingBuffer
@@ -0,0 +1,66 @@
+
+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/man/lfun/RingBufferGet b/doc/sphinx/man/lfun/RingBufferGet
new file mode 100644
index 0000000..128807f
--- /dev/null
+++ b/doc/sphinx/man/lfun/RingBufferGet
@@ -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/man/lfun/RingBufferPut b/doc/sphinx/man/lfun/RingBufferPut
new file mode 100644
index 0000000..00c046c
--- /dev/null
+++ b/doc/sphinx/man/lfun/RingBufferPut
@@ -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/man/lfun/SearchPath b/doc/sphinx/man/lfun/SearchPath
new file mode 100644
index 0000000..040965e
--- /dev/null
+++ b/doc/sphinx/man/lfun/SearchPath
@@ -0,0 +1,108 @@
+
+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/man/lfun/SelectEnemy b/doc/sphinx/man/lfun/SelectEnemy
new file mode 100644
index 0000000..5a05eab
--- /dev/null
+++ b/doc/sphinx/man/lfun/SelectEnemy
@@ -0,0 +1,51 @@
+
+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/man/lfun/SelectFarEnemy b/doc/sphinx/man/lfun/SelectFarEnemy
new file mode 100644
index 0000000..c390d42
--- /dev/null
+++ b/doc/sphinx/man/lfun/SelectFarEnemy
@@ -0,0 +1,65 @@
+
+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/man/lfun/SelectNearEnemy b/doc/sphinx/man/lfun/SelectNearEnemy
new file mode 100644
index 0000000..43ba033
--- /dev/null
+++ b/doc/sphinx/man/lfun/SelectNearEnemy
@@ -0,0 +1,69 @@
+
+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/man/lfun/Set b/doc/sphinx/man/lfun/Set
new file mode 100644
index 0000000..d654027
--- /dev/null
+++ b/doc/sphinx/man/lfun/Set
@@ -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
+
+6. Jan 2008 Arathorn
diff --git a/doc/sphinx/man/lfun/SetAttackChats b/doc/sphinx/man/lfun/SetAttackChats
new file mode 100644
index 0000000..90e8a66
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetAttackChats
@@ -0,0 +1,104 @@
+
+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/man/lfun/SetAttr b/doc/sphinx/man/lfun/SetAttr
new file mode 100644
index 0000000..fe5d97b
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetAttr
@@ -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/man/lfun/SetAttribute b/doc/sphinx/man/lfun/SetAttribute
new file mode 100644
index 0000000..139fc99
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetAttribute
@@ -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/man/lfun/SetBuyFact b/doc/sphinx/man/lfun/SetBuyFact
new file mode 100644
index 0000000..8994bd3
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetBuyFact
@@ -0,0 +1,58 @@
+
+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/man/lfun/SetChats b/doc/sphinx/man/lfun/SetChats
new file mode 100644
index 0000000..70d312e
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetChats
@@ -0,0 +1,94 @@
+
+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/man/lfun/SetCoinsPerUnits b/doc/sphinx/man/lfun/SetCoinsPerUnits
new file mode 100644
index 0000000..0533275
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetCoinsPerUnits
@@ -0,0 +1,63 @@
+
+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/man/lfun/SetDoorStatus b/doc/sphinx/man/lfun/SetDoorStatus
new file mode 100644
index 0000000..c433c40
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetDoorStatus
@@ -0,0 +1,49 @@
+
+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/man/lfun/SetEnemies b/doc/sphinx/man/lfun/SetEnemies
new file mode 100644
index 0000000..2c92035
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetEnemies
@@ -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/man/lfun/SetGramsPerUnits b/doc/sphinx/man/lfun/SetGramsPerUnits
new file mode 100644
index 0000000..66c1934
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetGramsPerUnits
@@ -0,0 +1,54 @@
+
+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/man/lfun/SetProp b/doc/sphinx/man/lfun/SetProp
new file mode 100644
index 0000000..9664be8
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetProp
@@ -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/man/lfun/SetProperties b/doc/sphinx/man/lfun/SetProperties
new file mode 100644
index 0000000..a4ac72a
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetProperties
@@ -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/man/lfun/SetRealAttribute b/doc/sphinx/man/lfun/SetRealAttribute
new file mode 100644
index 0000000..fc72d9b
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetRealAttribute
@@ -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/man/lfun/SetSpellFatigue b/doc/sphinx/man/lfun/SetSpellFatigue
new file mode 100644
index 0000000..f2c5861
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetSpellFatigue
@@ -0,0 +1,99 @@
+
+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/man/lfun/SetStorageRoom b/doc/sphinx/man/lfun/SetStorageRoom
new file mode 100644
index 0000000..f1d66a5
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetStorageRoom
@@ -0,0 +1,108 @@
+
+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/man/lfun/SetTimedAttrModifier b/doc/sphinx/man/lfun/SetTimedAttrModifier
new file mode 100644
index 0000000..5ab39dd
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetTimedAttrModifier
@@ -0,0 +1,113 @@
+
+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/man/lfun/ShowDoors b/doc/sphinx/man/lfun/ShowDoors
new file mode 100644
index 0000000..c315632
--- /dev/null
+++ b/doc/sphinx/man/lfun/ShowDoors
@@ -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/man/lfun/ShowPropList b/doc/sphinx/man/lfun/ShowPropList
new file mode 100644
index 0000000..41599d7
--- /dev/null
+++ b/doc/sphinx/man/lfun/ShowPropList
@@ -0,0 +1,74 @@
+
+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/man/lfun/SkillResTransfer b/doc/sphinx/man/lfun/SkillResTransfer
new file mode 100644
index 0000000..128cea7
--- /dev/null
+++ b/doc/sphinx/man/lfun/SkillResTransfer
@@ -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/man/lfun/SpellAttack b/doc/sphinx/man/lfun/SpellAttack
new file mode 100644
index 0000000..ba00347
--- /dev/null
+++ b/doc/sphinx/man/lfun/SpellAttack
@@ -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/man/lfun/SpellDefend b/doc/sphinx/man/lfun/SpellDefend
new file mode 100644
index 0000000..22b038c
--- /dev/null
+++ b/doc/sphinx/man/lfun/SpellDefend
@@ -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/man/lfun/SpellInform b/doc/sphinx/man/lfun/SpellInform
new file mode 100644
index 0000000..ce8fdbd
--- /dev/null
+++ b/doc/sphinx/man/lfun/SpellInform
@@ -0,0 +1,51 @@
+
+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/man/lfun/Start b/doc/sphinx/man/lfun/Start
new file mode 100644
index 0000000..e0b1070
--- /dev/null
+++ b/doc/sphinx/man/lfun/Start
@@ -0,0 +1,44 @@
+
+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/man/lfun/StopHuntFor b/doc/sphinx/man/lfun/StopHuntFor
new file mode 100644
index 0000000..e09d9fa
--- /dev/null
+++ b/doc/sphinx/man/lfun/StopHuntFor
@@ -0,0 +1,77 @@
+
+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/man/lfun/StopHuntText b/doc/sphinx/man/lfun/StopHuntText
new file mode 100644
index 0000000..fca271b
--- /dev/null
+++ b/doc/sphinx/man/lfun/StopHuntText
@@ -0,0 +1,77 @@
+
+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/man/lfun/SuggestArticle b/doc/sphinx/man/lfun/SuggestArticle
new file mode 100644
index 0000000..31c2047
--- /dev/null
+++ b/doc/sphinx/man/lfun/SuggestArticle
@@ -0,0 +1,57 @@
+
+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/man/lfun/SwapRows b/doc/sphinx/man/lfun/SwapRows
new file mode 100644
index 0000000..aa18364
--- /dev/null
+++ b/doc/sphinx/man/lfun/SwapRows
@@ -0,0 +1,60 @@
+
+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/man/lfun/TakeFlaw b/doc/sphinx/man/lfun/TakeFlaw
new file mode 100644
index 0000000..40d99a2
--- /dev/null
+++ b/doc/sphinx/man/lfun/TakeFlaw
@@ -0,0 +1,100 @@
+
+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/man/lfun/TeamFlee b/doc/sphinx/man/lfun/TeamFlee
new file mode 100644
index 0000000..216fbbf
--- /dev/null
+++ b/doc/sphinx/man/lfun/TeamFlee
@@ -0,0 +1,60 @@
+
+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/man/lfun/TeamMembers b/doc/sphinx/man/lfun/TeamMembers
new file mode 100644
index 0000000..5971bfb
--- /dev/null
+++ b/doc/sphinx/man/lfun/TeamMembers
@@ -0,0 +1,58 @@
+
+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/man/lfun/TeamPrefix b/doc/sphinx/man/lfun/TeamPrefix
new file mode 100644
index 0000000..2cf1582
--- /dev/null
+++ b/doc/sphinx/man/lfun/TeamPrefix
@@ -0,0 +1,56 @@
+
+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/man/lfun/Teleport b/doc/sphinx/man/lfun/Teleport
new file mode 100644
index 0000000..ddddb89
--- /dev/null
+++ b/doc/sphinx/man/lfun/Teleport
@@ -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/man/lfun/TestIgnore b/doc/sphinx/man/lfun/TestIgnore
new file mode 100644
index 0000000..d1d2b95
--- /dev/null
+++ b/doc/sphinx/man/lfun/TestIgnore
@@ -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/man/lfun/TestIgnoreSimple b/doc/sphinx/man/lfun/TestIgnoreSimple
new file mode 100644
index 0000000..c0ec76e
--- /dev/null
+++ b/doc/sphinx/man/lfun/TestIgnoreSimple
@@ -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/man/lfun/TestLimitViolation b/doc/sphinx/man/lfun/TestLimitViolation
new file mode 100644
index 0000000..df9f7b2
--- /dev/null
+++ b/doc/sphinx/man/lfun/TestLimitViolation
@@ -0,0 +1,39 @@
+
+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/man/lfun/TriggerEvent b/doc/sphinx/man/lfun/TriggerEvent
new file mode 100644
index 0000000..44dd2e4
--- /dev/null
+++ b/doc/sphinx/man/lfun/TriggerEvent
@@ -0,0 +1,87 @@
+
+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/man/lfun/UnregisterEvent b/doc/sphinx/man/lfun/UnregisterEvent
new file mode 100644
index 0000000..6d9bfb7
--- /dev/null
+++ b/doc/sphinx/man/lfun/UnregisterEvent
@@ -0,0 +1,79 @@
+
+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/man/lfun/UnregisterHelperNPC b/doc/sphinx/man/lfun/UnregisterHelperNPC
new file mode 100644
index 0000000..79c18f6
--- /dev/null
+++ b/doc/sphinx/man/lfun/UnregisterHelperNPC
@@ -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/man/lfun/UnregisterHelperObject b/doc/sphinx/man/lfun/UnregisterHelperObject
new file mode 100644
index 0000000..d6242c9
--- /dev/null
+++ b/doc/sphinx/man/lfun/UnregisterHelperObject
@@ -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/man/lfun/Unwear b/doc/sphinx/man/lfun/Unwear
new file mode 100644
index 0000000..0ef0a2a
--- /dev/null
+++ b/doc/sphinx/man/lfun/Unwear
@@ -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/man/lfun/UnwearArmour b/doc/sphinx/man/lfun/UnwearArmour
new file mode 100644
index 0000000..b3c7d77
--- /dev/null
+++ b/doc/sphinx/man/lfun/UnwearArmour
@@ -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/man/lfun/UnwearClothing b/doc/sphinx/man/lfun/UnwearClothing
new file mode 100644
index 0000000..fe0372b
--- /dev/null
+++ b/doc/sphinx/man/lfun/UnwearClothing
@@ -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/man/lfun/UnwieldFunc b/doc/sphinx/man/lfun/UnwieldFunc
new file mode 100644
index 0000000..0301182
--- /dev/null
+++ b/doc/sphinx/man/lfun/UnwieldFunc
@@ -0,0 +1,74 @@
+
+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/man/lfun/UpdateAttributes b/doc/sphinx/man/lfun/UpdateAttributes
new file mode 100644
index 0000000..cdebaa7
--- /dev/null
+++ b/doc/sphinx/man/lfun/UpdateAttributes
@@ -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/man/lfun/UpdateResistanceStrengths b/doc/sphinx/man/lfun/UpdateResistanceStrengths
new file mode 100644
index 0000000..8ae9198
--- /dev/null
+++ b/doc/sphinx/man/lfun/UpdateResistanceStrengths
@@ -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/man/lfun/UseHands b/doc/sphinx/man/lfun/UseHands
new file mode 100644
index 0000000..d11723c
--- /dev/null
+++ b/doc/sphinx/man/lfun/UseHands
@@ -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/man/lfun/UseSkill b/doc/sphinx/man/lfun/UseSkill
new file mode 100644
index 0000000..4f3398d
--- /dev/null
+++ b/doc/sphinx/man/lfun/UseSkill
@@ -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/man/lfun/UseSpell b/doc/sphinx/man/lfun/UseSpell
new file mode 100644
index 0000000..b5cfbf7
--- /dev/null
+++ b/doc/sphinx/man/lfun/UseSpell
@@ -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/man/lfun/Validate b/doc/sphinx/man/lfun/Validate
new file mode 100644
index 0000000..ddfceef
--- /dev/null
+++ b/doc/sphinx/man/lfun/Validate
@@ -0,0 +1,74 @@
+
+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/man/lfun/Wear b/doc/sphinx/man/lfun/Wear
new file mode 100644
index 0000000..6a46903
--- /dev/null
+++ b/doc/sphinx/man/lfun/Wear
@@ -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/man/lfun/WearArmour b/doc/sphinx/man/lfun/WearArmour
new file mode 100644
index 0000000..a6961b2
--- /dev/null
+++ b/doc/sphinx/man/lfun/WearArmour
@@ -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/man/lfun/WearClothing b/doc/sphinx/man/lfun/WearClothing
new file mode 100644
index 0000000..51cc015
--- /dev/null
+++ b/doc/sphinx/man/lfun/WearClothing
@@ -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/man/lfun/WearFunc b/doc/sphinx/man/lfun/WearFunc
new file mode 100644
index 0000000..d1d0121
--- /dev/null
+++ b/doc/sphinx/man/lfun/WearFunc
@@ -0,0 +1,105 @@
+
+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/man/lfun/WieldFunc b/doc/sphinx/man/lfun/WieldFunc
new file mode 100644
index 0000000..7c607e4
--- /dev/null
+++ b/doc/sphinx/man/lfun/WieldFunc
@@ -0,0 +1,102 @@
+
+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/man/lfun/WithDraw b/doc/sphinx/man/lfun/WithDraw
new file mode 100644
index 0000000..1bff547
--- /dev/null
+++ b/doc/sphinx/man/lfun/WithDraw
@@ -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/man/lfun/__INIT b/doc/sphinx/man/lfun/__INIT
new file mode 100644
index 0000000..3ba4793
--- /dev/null
+++ b/doc/sphinx/man/lfun/__INIT
@@ -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/man/lfun/_query_current_money b/doc/sphinx/man/lfun/_query_current_money
new file mode 100644
index 0000000..db3663f
--- /dev/null
+++ b/doc/sphinx/man/lfun/_query_current_money
@@ -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/man/lfun/_unparsed_args b/doc/sphinx/man/lfun/_unparsed_args
new file mode 100644
index 0000000..caf3653
--- /dev/null
+++ b/doc/sphinx/man/lfun/_unparsed_args
@@ -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/man/lfun/access_rights b/doc/sphinx/man/lfun/access_rights
new file mode 100644
index 0000000..7a99a99
--- /dev/null
+++ b/doc/sphinx/man/lfun/access_rights
@@ -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/man/lfun/buffer_hp b/doc/sphinx/man/lfun/buffer_hp
new file mode 100644
index 0000000..181751c
--- /dev/null
+++ b/doc/sphinx/man/lfun/buffer_hp
@@ -0,0 +1,104 @@
+
+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/man/lfun/buffer_sp b/doc/sphinx/man/lfun/buffer_sp
new file mode 100644
index 0000000..09cad72
--- /dev/null
+++ b/doc/sphinx/man/lfun/buffer_sp
@@ -0,0 +1,63 @@
+
+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/man/lfun/buy_obj b/doc/sphinx/man/lfun/buy_obj
new file mode 100644
index 0000000..0f0b965
--- /dev/null
+++ b/doc/sphinx/man/lfun/buy_obj
@@ -0,0 +1,65 @@
+
+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/man/lfun/catch_msg b/doc/sphinx/man/lfun/catch_msg
new file mode 100644
index 0000000..42d1950
--- /dev/null
+++ b/doc/sphinx/man/lfun/catch_msg
@@ -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/man/lfun/catch_tell b/doc/sphinx/man/lfun/catch_tell
new file mode 100644
index 0000000..ff4e030
--- /dev/null
+++ b/doc/sphinx/man/lfun/catch_tell
@@ -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/man/lfun/check_and_update_timed_key b/doc/sphinx/man/lfun/check_and_update_timed_key
new file mode 100644
index 0000000..aa96667
--- /dev/null
+++ b/doc/sphinx/man/lfun/check_and_update_timed_key
@@ -0,0 +1,114 @@
+
+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/man/lfun/check_restrictions b/doc/sphinx/man/lfun/check_restrictions
new file mode 100644
index 0000000..e173e8f
--- /dev/null
+++ b/doc/sphinx/man/lfun/check_restrictions
@@ -0,0 +1,202 @@
+
+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
+
+3. Januar 2014, Arathorn
diff --git a/doc/sphinx/man/lfun/check_timed_key b/doc/sphinx/man/lfun/check_timed_key
new file mode 100644
index 0000000..58c70ab
--- /dev/null
+++ b/doc/sphinx/man/lfun/check_timed_key
@@ -0,0 +1,52 @@
+
+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/man/lfun/clean_up b/doc/sphinx/man/lfun/clean_up
new file mode 100644
index 0000000..7c124fb
--- /dev/null
+++ b/doc/sphinx/man/lfun/clean_up
@@ -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/man/lfun/cmd_shoot b/doc/sphinx/man/lfun/cmd_shoot
new file mode 100644
index 0000000..9cbc9b9
--- /dev/null
+++ b/doc/sphinx/man/lfun/cmd_shoot
@@ -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/man/lfun/command_me b/doc/sphinx/man/lfun/command_me
new file mode 100644
index 0000000..77a3cc5
--- /dev/null
+++ b/doc/sphinx/man/lfun/command_me
@@ -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/man/lfun/consume b/doc/sphinx/man/lfun/consume
new file mode 100644
index 0000000..f07ece3
--- /dev/null
+++ b/doc/sphinx/man/lfun/consume
@@ -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/man/lfun/create b/doc/sphinx/man/lfun/create
new file mode 100644
index 0000000..03fc91a
--- /dev/null
+++ b/doc/sphinx/man/lfun/create
@@ -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/man/lfun/create_default_npc b/doc/sphinx/man/lfun/create_default_npc
new file mode 100644
index 0000000..09c3a14
--- /dev/null
+++ b/doc/sphinx/man/lfun/create_default_npc
@@ -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/man/lfun/create_super b/doc/sphinx/man/lfun/create_super
new file mode 100644
index 0000000..101531f
--- /dev/null
+++ b/doc/sphinx/man/lfun/create_super
@@ -0,0 +1,75 @@
+
+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/man/lfun/defuel_drink b/doc/sphinx/man/lfun/defuel_drink
new file mode 100644
index 0000000..266907e
--- /dev/null
+++ b/doc/sphinx/man/lfun/defuel_drink
@@ -0,0 +1,87 @@
+
+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/man/lfun/defuel_food b/doc/sphinx/man/lfun/defuel_food
new file mode 100644
index 0000000..380c2bc
--- /dev/null
+++ b/doc/sphinx/man/lfun/defuel_food
@@ -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/man/lfun/deregister_modifier b/doc/sphinx/man/lfun/deregister_modifier
new file mode 100644
index 0000000..eb0c160
--- /dev/null
+++ b/doc/sphinx/man/lfun/deregister_modifier
@@ -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/man/lfun/die b/doc/sphinx/man/lfun/die
new file mode 100644
index 0000000..a76a1aa
--- /dev/null
+++ b/doc/sphinx/man/lfun/die
@@ -0,0 +1,67 @@
+
+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/man/lfun/doUnwearMessage b/doc/sphinx/man/lfun/doUnwearMessage
new file mode 100644
index 0000000..b6128ce
--- /dev/null
+++ b/doc/sphinx/man/lfun/doUnwearMessage
@@ -0,0 +1,46 @@
+
+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/man/lfun/doUnwieldMessage b/doc/sphinx/man/lfun/doUnwieldMessage
new file mode 100644
index 0000000..f2245b6
--- /dev/null
+++ b/doc/sphinx/man/lfun/doUnwieldMessage
@@ -0,0 +1,43 @@
+
+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/man/lfun/doWearMessage b/doc/sphinx/man/lfun/doWearMessage
new file mode 100644
index 0000000..6770180
--- /dev/null
+++ b/doc/sphinx/man/lfun/doWearMessage
@@ -0,0 +1,44 @@
+
+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/man/lfun/doWieldMessage b/doc/sphinx/man/lfun/doWieldMessage
new file mode 100644
index 0000000..a3b737f
--- /dev/null
+++ b/doc/sphinx/man/lfun/doWieldMessage
@@ -0,0 +1,42 @@
+
+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/man/lfun/do_damage b/doc/sphinx/man/lfun/do_damage
new file mode 100644
index 0000000..91c6bc8
--- /dev/null
+++ b/doc/sphinx/man/lfun/do_damage
@@ -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/man/lfun/do_frage b/doc/sphinx/man/lfun/do_frage
new file mode 100644
index 0000000..6c848b8
--- /dev/null
+++ b/doc/sphinx/man/lfun/do_frage
@@ -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/man/lfun/do_unwear b/doc/sphinx/man/lfun/do_unwear
new file mode 100644
index 0000000..dd91478
--- /dev/null
+++ b/doc/sphinx/man/lfun/do_unwear
@@ -0,0 +1,56 @@
+
+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/man/lfun/do_wear b/doc/sphinx/man/lfun/do_wear
new file mode 100644
index 0000000..abf7051
--- /dev/null
+++ b/doc/sphinx/man/lfun/do_wear
@@ -0,0 +1,46 @@
+
+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/man/lfun/drink_alcohol b/doc/sphinx/man/lfun/drink_alcohol
new file mode 100644
index 0000000..01d0a77
--- /dev/null
+++ b/doc/sphinx/man/lfun/drink_alcohol
@@ -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/man/lfun/drink_soft b/doc/sphinx/man/lfun/drink_soft
new file mode 100644
index 0000000..0f030f6
--- /dev/null
+++ b/doc/sphinx/man/lfun/drink_soft
@@ -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/man/lfun/drop b/doc/sphinx/man/lfun/drop
new file mode 100644
index 0000000..cdd372b
--- /dev/null
+++ b/doc/sphinx/man/lfun/drop
@@ -0,0 +1,70 @@
+
+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/man/lfun/drop_obj b/doc/sphinx/man/lfun/drop_obj
new file mode 100644
index 0000000..3e1057f
--- /dev/null
+++ b/doc/sphinx/man/lfun/drop_obj
@@ -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/man/lfun/drop_objects b/doc/sphinx/man/lfun/drop_objects
new file mode 100644
index 0000000..93cbee5
--- /dev/null
+++ b/doc/sphinx/man/lfun/drop_objects
@@ -0,0 +1,73 @@
+
+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/man/lfun/eat_food b/doc/sphinx/man/lfun/eat_food
new file mode 100644
index 0000000..32327e2
--- /dev/null
+++ b/doc/sphinx/man/lfun/eat_food
@@ -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/man/lfun/execute_anything b/doc/sphinx/man/lfun/execute_anything
new file mode 100644
index 0000000..39ec45a
--- /dev/null
+++ b/doc/sphinx/man/lfun/execute_anything
@@ -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/man/lfun/exit b/doc/sphinx/man/lfun/exit
new file mode 100644
index 0000000..f2d0b00
--- /dev/null
+++ b/doc/sphinx/man/lfun/exit
@@ -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/man/lfun/find_obs b/doc/sphinx/man/lfun/find_obs
new file mode 100644
index 0000000..994ac6f
--- /dev/null
+++ b/doc/sphinx/man/lfun/find_obs
@@ -0,0 +1,53 @@
+
+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/man/lfun/get_killing_player b/doc/sphinx/man/lfun/get_killing_player
new file mode 100644
index 0000000..3500be1
--- /dev/null
+++ b/doc/sphinx/man/lfun/get_killing_player
@@ -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/man/lfun/gilde/AddSkill b/doc/sphinx/man/lfun/gilde/AddSkill
new file mode 100644
index 0000000..6be310b
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/AddSkill
@@ -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/man/lfun/gilde/AddSpell b/doc/sphinx/man/lfun/gilde/AddSpell
new file mode 100644
index 0000000..027b4d6
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/AddSpell
@@ -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/man/lfun/gilde/GuildRating b/doc/sphinx/man/lfun/gilde/GuildRating
new file mode 100644
index 0000000..ca4ec1b
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/GuildRating
@@ -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/man/lfun/gilde/InitialSkillAbility b/doc/sphinx/man/lfun/gilde/InitialSkillAbility
new file mode 100644
index 0000000..afea3e9
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/InitialSkillAbility
@@ -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/man/lfun/gilde/LearnSkill b/doc/sphinx/man/lfun/gilde/LearnSkill
new file mode 100644
index 0000000..07a4dc9
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/LearnSkill
@@ -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/man/lfun/gilde/LearnSpell b/doc/sphinx/man/lfun/gilde/LearnSpell
new file mode 100644
index 0000000..385da3e
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/LearnSpell
@@ -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/man/lfun/gilde/QuerySkill b/doc/sphinx/man/lfun/gilde/QuerySkill
new file mode 100644
index 0000000..ee3e68a
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/QuerySkill
@@ -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/man/lfun/gilde/QuerySpell b/doc/sphinx/man/lfun/gilde/QuerySpell
new file mode 100644
index 0000000..32eff3a
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/QuerySpell
@@ -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/man/lfun/gilde/SkillListe b/doc/sphinx/man/lfun/gilde/SkillListe
new file mode 100644
index 0000000..200650b
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/SkillListe
@@ -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/man/lfun/gilde/UseSpell b/doc/sphinx/man/lfun/gilde/UseSpell
new file mode 100644
index 0000000..4f3724c
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/UseSpell
@@ -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/man/lfun/gilde/austreten b/doc/sphinx/man/lfun/gilde/austreten
new file mode 100644
index 0000000..cde77e2
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/austreten
@@ -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/man/lfun/gilde/bei_oder_aus_treten b/doc/sphinx/man/lfun/gilde/bei_oder_aus_treten
new file mode 100644
index 0000000..abed024
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/bei_oder_aus_treten
@@ -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/man/lfun/gilde/beitreten b/doc/sphinx/man/lfun/gilde/beitreten
new file mode 100644
index 0000000..6e5a957
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/beitreten
@@ -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/man/lfun/give b/doc/sphinx/man/lfun/give
new file mode 100644
index 0000000..866c1e3
--- /dev/null
+++ b/doc/sphinx/man/lfun/give
@@ -0,0 +1,65 @@
+
+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/man/lfun/give_notify b/doc/sphinx/man/lfun/give_notify
new file mode 100644
index 0000000..ef316cb
--- /dev/null
+++ b/doc/sphinx/man/lfun/give_notify
@@ -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/man/lfun/give_obj b/doc/sphinx/man/lfun/give_obj
new file mode 100644
index 0000000..753fd09
--- /dev/null
+++ b/doc/sphinx/man/lfun/give_obj
@@ -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/man/lfun/heal_self b/doc/sphinx/man/lfun/heal_self
new file mode 100644
index 0000000..53697a2
--- /dev/null
+++ b/doc/sphinx/man/lfun/heal_self
@@ -0,0 +1,68 @@
+
+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/man/lfun/heart_beat b/doc/sphinx/man/lfun/heart_beat
new file mode 100644
index 0000000..475a781
--- /dev/null
+++ b/doc/sphinx/man/lfun/heart_beat
@@ -0,0 +1,57 @@
+
+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/man/lfun/id b/doc/sphinx/man/lfun/id
new file mode 100644
index 0000000..4921395
--- /dev/null
+++ b/doc/sphinx/man/lfun/id
@@ -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/man/lfun/init b/doc/sphinx/man/lfun/init
new file mode 100644
index 0000000..481eec2
--- /dev/null
+++ b/doc/sphinx/man/lfun/init
@@ -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/man/lfun/insert_sensitive_inv b/doc/sphinx/man/lfun/insert_sensitive_inv
new file mode 100644
index 0000000..513632a
--- /dev/null
+++ b/doc/sphinx/man/lfun/insert_sensitive_inv
@@ -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/man/lfun/insert_sensitive_inv_trigger b/doc/sphinx/man/lfun/insert_sensitive_inv_trigger
new file mode 100644
index 0000000..edb78f8
--- /dev/null
+++ b/doc/sphinx/man/lfun/insert_sensitive_inv_trigger
@@ -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/man/lfun/int_long b/doc/sphinx/man/lfun/int_long
new file mode 100644
index 0000000..931e132
--- /dev/null
+++ b/doc/sphinx/man/lfun/int_long
@@ -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/man/lfun/int_short b/doc/sphinx/man/lfun/int_short
new file mode 100644
index 0000000..aabd547
--- /dev/null
+++ b/doc/sphinx/man/lfun/int_short
@@ -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/man/lfun/is_class_member b/doc/sphinx/man/lfun/is_class_member
new file mode 100644
index 0000000..1018e71
--- /dev/null
+++ b/doc/sphinx/man/lfun/is_class_member
@@ -0,0 +1,174 @@
+
+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/man/lfun/lfun b/doc/sphinx/man/lfun/lfun
new file mode 100644
index 0000000..6e35081
--- /dev/null
+++ b/doc/sphinx/man/lfun/lfun
@@ -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/man/lfun/locate_objects b/doc/sphinx/man/lfun/locate_objects
new file mode 100644
index 0000000..5854980
--- /dev/null
+++ b/doc/sphinx/man/lfun/locate_objects
@@ -0,0 +1,79 @@
+
+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/man/lfun/logon b/doc/sphinx/man/lfun/logon
new file mode 100644
index 0000000..4fb7117
--- /dev/null
+++ b/doc/sphinx/man/lfun/logon
@@ -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/man/lfun/long b/doc/sphinx/man/lfun/long
new file mode 100644
index 0000000..a186cf9
--- /dev/null
+++ b/doc/sphinx/man/lfun/long
@@ -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/man/lfun/make_immortal b/doc/sphinx/man/lfun/make_immortal
new file mode 100644
index 0000000..9d0f402
--- /dev/null
+++ b/doc/sphinx/man/lfun/make_immortal
@@ -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/man/lfun/make_invlist b/doc/sphinx/man/lfun/make_invlist
new file mode 100644
index 0000000..379b47c
--- /dev/null
+++ b/doc/sphinx/man/lfun/make_invlist
@@ -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/man/lfun/master/AddWizardForUID b/doc/sphinx/man/lfun/master/AddWizardForUID
new file mode 100644
index 0000000..249e27c
--- /dev/null
+++ b/doc/sphinx/man/lfun/master/AddWizardForUID
@@ -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/man/lfun/master/QueryUIDAlias b/doc/sphinx/man/lfun/master/QueryUIDAlias
new file mode 100644
index 0000000..8f58509
--- /dev/null
+++ b/doc/sphinx/man/lfun/master/QueryUIDAlias
@@ -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/man/lfun/master/QueryUIDsForWizard b/doc/sphinx/man/lfun/master/QueryUIDsForWizard
new file mode 100644
index 0000000..e0d5816
--- /dev/null
+++ b/doc/sphinx/man/lfun/master/QueryUIDsForWizard
@@ -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/man/lfun/master/QueryWizardsForUID b/doc/sphinx/man/lfun/master/QueryWizardsForUID
new file mode 100644
index 0000000..6ddbdc3
--- /dev/null
+++ b/doc/sphinx/man/lfun/master/QueryWizardsForUID
@@ -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/man/lfun/master/RemoveWizardFromUID b/doc/sphinx/man/lfun/master/RemoveWizardFromUID
new file mode 100644
index 0000000..1fdeba5
--- /dev/null
+++ b/doc/sphinx/man/lfun/master/RemoveWizardFromUID
@@ -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/man/lfun/match_ids b/doc/sphinx/man/lfun/match_ids
new file mode 100644
index 0000000..48f368f
--- /dev/null
+++ b/doc/sphinx/man/lfun/match_ids
@@ -0,0 +1,69 @@
+
+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/man/lfun/move b/doc/sphinx/man/lfun/move
new file mode 100644
index 0000000..bd9d924
--- /dev/null
+++ b/doc/sphinx/man/lfun/move
@@ -0,0 +1,242 @@
+
+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/man/lfun/moved_objects b/doc/sphinx/man/lfun/moved_objects
new file mode 100644
index 0000000..8a5b536
--- /dev/null
+++ b/doc/sphinx/man/lfun/moved_objects
@@ -0,0 +1,52 @@
+
+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/man/lfun/moved_where b/doc/sphinx/man/lfun/moved_where
new file mode 100644
index 0000000..640acae
--- /dev/null
+++ b/doc/sphinx/man/lfun/moved_where
@@ -0,0 +1,50 @@
+
+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/man/lfun/muster b/doc/sphinx/man/lfun/muster
new file mode 100644
index 0000000..aa7279c
--- /dev/null
+++ b/doc/sphinx/man/lfun/muster
@@ -0,0 +1,33 @@
+
+muster()
+********
+
+
+FUNKTION
+========
+
+   type muster(...)
+
+
+ARGUMENTE
+=========
+
+
+BESCHREIBUNG
+============
+
+
+RUECKGABEWERT
+=============
+
+
+BEMERKUNG
+=========
+
+
+BEISPIEL
+========
+
+
+SIEHE AUCH
+==========
diff --git a/doc/sphinx/man/lfun/name b/doc/sphinx/man/lfun/name
new file mode 100644
index 0000000..3509366
--- /dev/null
+++ b/doc/sphinx/man/lfun/name
@@ -0,0 +1,81 @@
+
+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/man/lfun/notify_player_change b/doc/sphinx/man/lfun/notify_player_change
new file mode 100644
index 0000000..34c4024
--- /dev/null
+++ b/doc/sphinx/man/lfun/notify_player_change
@@ -0,0 +1,82 @@
+
+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/man/lfun/obsolete/AddHpHook b/doc/sphinx/man/lfun/obsolete/AddHpHook
new file mode 100644
index 0000000..5a2adce
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/AddHpHook
@@ -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/man/lfun/obsolete/AddInsertHook b/doc/sphinx/man/lfun/obsolete/AddInsertHook
new file mode 100644
index 0000000..9a372ba
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/AddInsertHook
@@ -0,0 +1,85 @@
+
+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/man/lfun/obsolete/ModifySkillAttributeOld b/doc/sphinx/man/lfun/obsolete/ModifySkillAttributeOld
new file mode 100644
index 0000000..b0b81ab
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/ModifySkillAttributeOld
@@ -0,0 +1,118 @@
+
+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/man/lfun/obsolete/NotifyGiveQuest b/doc/sphinx/man/lfun/obsolete/NotifyGiveQuest
new file mode 100644
index 0000000..220942b
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/NotifyGiveQuest
@@ -0,0 +1,62 @@
+
+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/man/lfun/obsolete/NotifyHpChange b/doc/sphinx/man/lfun/obsolete/NotifyHpChange
new file mode 100644
index 0000000..3c96222
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/NotifyHpChange
@@ -0,0 +1,71 @@
+
+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/man/lfun/obsolete/QueryEnemy b/doc/sphinx/man/lfun/obsolete/QueryEnemy
new file mode 100644
index 0000000..2613f53
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/QueryEnemy
@@ -0,0 +1,51 @@
+
+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/man/lfun/obsolete/QueryInsertHooks b/doc/sphinx/man/lfun/obsolete/QueryInsertHooks
new file mode 100644
index 0000000..317104c
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/QueryInsertHooks
@@ -0,0 +1,52 @@
+
+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/man/lfun/obsolete/QueryOptQP b/doc/sphinx/man/lfun/obsolete/QueryOptQP
new file mode 100644
index 0000000..77404ad
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/QueryOptQP
@@ -0,0 +1,43 @@
+
+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/man/lfun/obsolete/RemoveHpHook b/doc/sphinx/man/lfun/obsolete/RemoveHpHook
new file mode 100644
index 0000000..54c93ec
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/RemoveHpHook
@@ -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/man/lfun/obsolete/RemoveInsertHook b/doc/sphinx/man/lfun/obsolete/RemoveInsertHook
new file mode 100644
index 0000000..6c77edf
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/RemoveInsertHook
@@ -0,0 +1,52 @@
+
+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/man/lfun/obsolete/TestAttributeLock b/doc/sphinx/man/lfun/obsolete/TestAttributeLock
new file mode 100644
index 0000000..3d5d54d
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/TestAttributeLock
@@ -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/man/lfun/obsolete/extra_look b/doc/sphinx/man/lfun/obsolete/extra_look
new file mode 100644
index 0000000..d8e9703
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/extra_look
@@ -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/man/lfun/obsolete/paramove b/doc/sphinx/man/lfun/obsolete/paramove
new file mode 100644
index 0000000..25ce252
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/paramove
@@ -0,0 +1,66 @@
+
+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/man/lfun/pick b/doc/sphinx/man/lfun/pick
new file mode 100644
index 0000000..5063ee6
--- /dev/null
+++ b/doc/sphinx/man/lfun/pick
@@ -0,0 +1,73 @@
+
+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/man/lfun/pick_obj b/doc/sphinx/man/lfun/pick_obj
new file mode 100644
index 0000000..6557cee
--- /dev/null
+++ b/doc/sphinx/man/lfun/pick_obj
@@ -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/man/lfun/pick_objects b/doc/sphinx/man/lfun/pick_objects
new file mode 100644
index 0000000..ac70415
--- /dev/null
+++ b/doc/sphinx/man/lfun/pick_objects
@@ -0,0 +1,61 @@
+
+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/man/lfun/present_objects b/doc/sphinx/man/lfun/present_objects
new file mode 100644
index 0000000..77f31fa
--- /dev/null
+++ b/doc/sphinx/man/lfun/present_objects
@@ -0,0 +1,50 @@
+
+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/man/lfun/put b/doc/sphinx/man/lfun/put
new file mode 100644
index 0000000..9b1d5eb
--- /dev/null
+++ b/doc/sphinx/man/lfun/put
@@ -0,0 +1,65 @@
+
+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/man/lfun/put_obj b/doc/sphinx/man/lfun/put_obj
new file mode 100644
index 0000000..ff4dd91
--- /dev/null
+++ b/doc/sphinx/man/lfun/put_obj
@@ -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/man/lfun/query_prevent_shadow b/doc/sphinx/man/lfun/query_prevent_shadow
new file mode 100644
index 0000000..2c8d2f3
--- /dev/null
+++ b/doc/sphinx/man/lfun/query_prevent_shadow
@@ -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/man/lfun/query_real_name b/doc/sphinx/man/lfun/query_real_name
new file mode 100644
index 0000000..1ebc69f
--- /dev/null
+++ b/doc/sphinx/man/lfun/query_real_name
@@ -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/man/lfun/query_weight_contents b/doc/sphinx/man/lfun/query_weight_contents
new file mode 100644
index 0000000..bd644f5
--- /dev/null
+++ b/doc/sphinx/man/lfun/query_weight_contents
@@ -0,0 +1,36 @@
+
+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/man/lfun/reduce_hit_points b/doc/sphinx/man/lfun/reduce_hit_points
new file mode 100644
index 0000000..7a1dcf0
--- /dev/null
+++ b/doc/sphinx/man/lfun/reduce_hit_points
@@ -0,0 +1,69 @@
+
+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/man/lfun/reduce_spell_points b/doc/sphinx/man/lfun/reduce_spell_points
new file mode 100644
index 0000000..cddb7da
--- /dev/null
+++ b/doc/sphinx/man/lfun/reduce_spell_points
@@ -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/man/lfun/register_modifier b/doc/sphinx/man/lfun/register_modifier
new file mode 100644
index 0000000..afe086c
--- /dev/null
+++ b/doc/sphinx/man/lfun/register_modifier
@@ -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/man/lfun/remove b/doc/sphinx/man/lfun/remove
new file mode 100644
index 0000000..914c1e1
--- /dev/null
+++ b/doc/sphinx/man/lfun/remove
@@ -0,0 +1,56 @@
+
+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/man/lfun/remove_multiple b/doc/sphinx/man/lfun/remove_multiple
new file mode 100644
index 0000000..9e60d55
--- /dev/null
+++ b/doc/sphinx/man/lfun/remove_multiple
@@ -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/man/lfun/reset b/doc/sphinx/man/lfun/reset
new file mode 100644
index 0000000..5959b3f
--- /dev/null
+++ b/doc/sphinx/man/lfun/reset
@@ -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/man/lfun/restore_hit_points b/doc/sphinx/man/lfun/restore_hit_points
new file mode 100644
index 0000000..b4917cf
--- /dev/null
+++ b/doc/sphinx/man/lfun/restore_hit_points
@@ -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/man/lfun/restore_spell_points b/doc/sphinx/man/lfun/restore_spell_points
new file mode 100644
index 0000000..2c8e42c
--- /dev/null
+++ b/doc/sphinx/man/lfun/restore_spell_points
@@ -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/man/lfun/save_me b/doc/sphinx/man/lfun/save_me
new file mode 100644
index 0000000..cbce90a
--- /dev/null
+++ b/doc/sphinx/man/lfun/save_me
@@ -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/man/lfun/second_life b/doc/sphinx/man/lfun/second_life
new file mode 100644
index 0000000..1c3fc8b
--- /dev/null
+++ b/doc/sphinx/man/lfun/second_life
@@ -0,0 +1,52 @@
+
+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/man/lfun/sell_obj b/doc/sphinx/man/lfun/sell_obj
new file mode 100644
index 0000000..580fd87
--- /dev/null
+++ b/doc/sphinx/man/lfun/sell_obj
@@ -0,0 +1,59 @@
+
+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/man/lfun/set_object_next_reset b/doc/sphinx/man/lfun/set_object_next_reset
new file mode 100644
index 0000000..9b77a9e
--- /dev/null
+++ b/doc/sphinx/man/lfun/set_object_next_reset
@@ -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/man/lfun/shoot_dam b/doc/sphinx/man/lfun/shoot_dam
new file mode 100644
index 0000000..f66be19
--- /dev/null
+++ b/doc/sphinx/man/lfun/shoot_dam
@@ -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/man/lfun/short b/doc/sphinx/man/lfun/short
new file mode 100644
index 0000000..f7bb169
--- /dev/null
+++ b/doc/sphinx/man/lfun/short
@@ -0,0 +1,53 @@
+
+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/man/lfun/show_notify b/doc/sphinx/man/lfun/show_notify
new file mode 100644
index 0000000..0ce99ac
--- /dev/null
+++ b/doc/sphinx/man/lfun/show_notify
@@ -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/man/lfun/spellbook/AddSpell b/doc/sphinx/man/lfun/spellbook/AddSpell
new file mode 100644
index 0000000..65f0df8
--- /dev/null
+++ b/doc/sphinx/man/lfun/spellbook/AddSpell
@@ -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/man/lfun/spellbook/Erfolg b/doc/sphinx/man/lfun/spellbook/Erfolg
new file mode 100644
index 0000000..6338e6d
--- /dev/null
+++ b/doc/sphinx/man/lfun/spellbook/Erfolg
@@ -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/man/lfun/spellbook/Learn b/doc/sphinx/man/lfun/spellbook/Learn
new file mode 100644
index 0000000..8de112e
--- /dev/null
+++ b/doc/sphinx/man/lfun/spellbook/Learn
@@ -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/man/lfun/spellbook/Misserfolg b/doc/sphinx/man/lfun/spellbook/Misserfolg
new file mode 100644
index 0000000..5ffe8de
--- /dev/null
+++ b/doc/sphinx/man/lfun/spellbook/Misserfolg
@@ -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/man/lfun/spellbook/QuerySpell b/doc/sphinx/man/lfun/spellbook/QuerySpell
new file mode 100644
index 0000000..963d30c
--- /dev/null
+++ b/doc/sphinx/man/lfun/spellbook/QuerySpell
@@ -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/man/lfun/spellbook/SpellSuccess b/doc/sphinx/man/lfun/spellbook/SpellSuccess
new file mode 100644
index 0000000..564c948
--- /dev/null
+++ b/doc/sphinx/man/lfun/spellbook/SpellSuccess
@@ -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/man/lfun/spellbook/TryAttackSpell b/doc/sphinx/man/lfun/spellbook/TryAttackSpell
new file mode 100644
index 0000000..d66684e
--- /dev/null
+++ b/doc/sphinx/man/lfun/spellbook/TryAttackSpell
@@ -0,0 +1,57 @@
+
+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/man/lfun/trigger_sensitive_attack b/doc/sphinx/man/lfun/trigger_sensitive_attack
new file mode 100644
index 0000000..f290fc8
--- /dev/null
+++ b/doc/sphinx/man/lfun/trigger_sensitive_attack
@@ -0,0 +1,97 @@
+
+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/man/lfun/trigger_sensitive_inv b/doc/sphinx/man/lfun/trigger_sensitive_inv
new file mode 100644
index 0000000..27e26fb
--- /dev/null
+++ b/doc/sphinx/man/lfun/trigger_sensitive_inv
@@ -0,0 +1,61 @@
+
+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/man/lfun/wield_me b/doc/sphinx/man/lfun/wield_me
new file mode 100644
index 0000000..d1aa842
--- /dev/null
+++ b/doc/sphinx/man/lfun/wield_me
@@ -0,0 +1,17 @@
+
+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