Manpages als reStructuredText erstellt
Unsere Manpages wurden mit einem LPC-Tool in
reStructuredText konvertiert und liegen jetzt
in diesem Verzeichnis als Quelldaten.
Aus diesen reStructuredText sollen dann per
Script die ASCII-Manpages und per Sphinx HTML u.a.
erzeugt werden.
Change-Id: I75d659a7b3f9863aecb11dbeb0037e6cae227c36
diff --git a/doc/sphinx/lfun/AddAction.rst b/doc/sphinx/lfun/AddAction.rst
new file mode 100644
index 0000000..6791d4e
--- /dev/null
+++ b/doc/sphinx/lfun/AddAction.rst
@@ -0,0 +1,104 @@
+AddAction()
+===========
+
+AddAction(L)
+------------
+::
+
+FUNKTION
+--------
+::
+
+ varargs void AddAction(mixed fun, mixed cmd, int flag, int lvl);
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/command.c
+
+ARGUMENTE
+---------
+::
+
+ fun zu rufende Methode im Spieler oder eine Closure
+ cmd ausloesendes Kommandoverb
+ flag unscharf ausfuehren
+ lvl ab welchem (Magierlevel) funktioniert das Kommando
+
+BESCHREIBUNG
+------------
+::
+
+ Dem Spieler wird ein neues Kommando definiert. Dieses kann eine Methode
+ in ihm sein, so wie bei allen Spielerkommandos ueblich, kann aber auch
+ eine Closure (Lfun-Closure oder Lambda) enthalten.
+
+ Mittels "flag" kann man die Kommandoerkennung unscharf halten, d.h. wie
+ bei AddCmd(L) und add_action(E) wird ein 'cmd' bei 'flag = 1' auch
+ schon von Praefix-Strings (hier ohne Leerzeichen) getriggert:
+ AddAction([...], "muh", 1, 0) wird zB auch von 'muhtens' oder 'muh4'
+ ausgeloest.
+
+ Mit "lvl" begrenzt man die Ausfuehrbarkeit. Spieler haben ein
+ Magierlevel von 0, Seher von 1.
+
+ Das Kommando wird in P_LOCALCMDS eingetragen. Diese Property wird
+ nicht gespeichert! Effektiv kann man mit AddAction() ein kommando-
+ gebendes Objekt im Spieler einsparen.
+
+BEMERKUNGEN
+-----------
+::
+
+ - es gibt _noch_ kein RemoveAction! Per Hand in P_LOCALCMDS editieren
+ kann zu ernsten Fehlern fuehren.
+ - echte Spielerkommandos kann man damit _nicht_ ueberschreiben,
+ ein AddAction(...,"sag",1,0); funktioniert nicht
+ - ein generelles AddAction(...,"",1,0); geht nicht
+
+BEISPIELE
+---------
+::
+
+ ...
+ this_player()->AddAction(symbol_function("zeige_mysterium",
+ find_object(".../mystzeiger")),
+ "knorfula",0,0);
+ write(break_string("Wann immer du jetzt das Kommando \"knorfula\" "
+ "eingibst, werden dir Mysterien enthuellt!",78));
+ ...
+
+ // im Objekt "knorfula" ...
+ int zeige_mysterium(string str) {
+ string myst;
+ myst=environment(TP)->QueryMysterium(str);
+ if(myst) {
+ write("Du hast ein Mysterium entdeckt!\n");
+ write(break_string(myst,78));
+ say(break_string(
+ TP->Name(WER)+" scheint nach kurzer Konzentration etwas "
+ "entdeckt zu haben!",78));
+ } else {
+ write(break_string(
+ "Leider entdeckst du trotz deiner magischen Faehigkeit "
+ "kein Mysterium in deiner Umgebung.",78));
+ say(break_string(
+ TP->Name(WER)+" konzentriert sich sichtbar, sieht dann "
+ "jedoch etwas enttaeuscht aus.",78));
+ }
+ return 1;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ P_LOCALCMDS
+ Fehlermeldungen: notify_fail(E), _notify_fail(E)
+ Argumentstring: query_verb(E), _unparsed_args(L)
+ Sonstiges: replace_personal(E), enable_commands(E)
+ Alternativen: AddCmd(L), add_action(E)
+
+24. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/AddAdjective.rst b/doc/sphinx/lfun/AddAdjective.rst
new file mode 100644
index 0000000..50eb0ad
--- /dev/null
+++ b/doc/sphinx/lfun/AddAdjective.rst
@@ -0,0 +1,63 @@
+AddAdjective()
+==============
+
+FUNKTION
+--------
+::
+
+ void AddAdjective(string|string* adj);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ adj
+ String oder Array von String mit den Adjektiven.
+
+BESCHREIBUNG
+------------
+::
+
+ Zusaetzlich zu den mit AddId() vergebenen Bezeichnern laesst sich mit
+ der Vergabe von Adjektiven die Ansprechbarkeit eines Objektes erhoehen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Die Adjektive werden nicht dekliniert, man muss also fuer jeden
+ sinnvollen Fall ein Adjektiv uebergeben.
+
+BEISPIELE
+---------
+::
+
+ AddId( ({ "zettel", "blatt" }) );
+ AddAdjective( ({ "kleinen", "kleines" }) );
+
+ Das Objekt reagiert jetzt auf "zettel", "kleinen zettel", "blatt",
+ "kleines blatt" sowie auf die (sprachlich nicht ganz so korrekten)
+ Konstruktionen "kleines zettel", "kleinen blatt", "kleines kleinen
+ zettel", ...
+
+SIEHE AUCH
+----------
+::
+
+ AddId(), RemoveAdjective() id(), present(), /std/thing/description.c
+
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddAmount.rst b/doc/sphinx/lfun/AddAmount.rst
new file mode 100644
index 0000000..08c038b
--- /dev/null
+++ b/doc/sphinx/lfun/AddAmount.rst
@@ -0,0 +1,45 @@
+AddAmount()
+===========
+
+FUNKTION
+--------
+::
+
+ void AddAmount(int menge);
+
+DEFINIERT IN
+------------
+::
+
+ /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+ menge
+ Die Menge, die der Unit hinzugefuegt werden soll (kann auch
+ negativ sein).
+
+BESCHREIBUNG
+------------
+::
+
+ menge wird zur aktuellen Menge hinzugezaehlt. Sollte das Ergebnis 0
+ werden, wird die Unit in absehbarer Zeit zerstoert.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ /std/unit.c
+
+
+Last modified: Wed May 8 10:15:50 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/AddClass.rst b/doc/sphinx/lfun/AddClass.rst
new file mode 100644
index 0000000..4c3ef61
--- /dev/null
+++ b/doc/sphinx/lfun/AddClass.rst
@@ -0,0 +1,48 @@
+AddClass()
+==========
+
+FUNKTION
+--------
+::
+
+ void AddClass(string|string* class);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ string/string* class - String oder Stringarray der Klasse(n)
+
+BESCHREIBUNG
+------------
+::
+
+ Dem Objekt werden weitere Klassifizierungen hinzugefuegt.
+
+ Die allgemein verfuegbaren Klassen sind unter /sys/class.h definiert.
+
+BEMERKUNGEN
+-----------
+::
+
+ Vor dem 7. Nov 2012 pruefte is_class_member() auch die P_IDS. Damit war
+ zB ein AddId("daemon") gleichbedeutend einem AddClass(CL_DEMON).
+
+ Bitte prueft eure Objekte (NPCs, Krankheiten, Gifte, ...) auf korrekte
+ Klassifizierung.
+
+SIEHE AUCH
+----------
+::
+
+ RemoveClass(), is_class_member()
+ P_CLASS
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddCmd.rst b/doc/sphinx/lfun/AddCmd.rst
new file mode 100644
index 0000000..ba298eb
--- /dev/null
+++ b/doc/sphinx/lfun/AddCmd.rst
@@ -0,0 +1,239 @@
+AddCmd()
+========
+
+AddCmd(L)
+---------
+::
+
+FUNKTION
+--------
+::
+
+ varargs void AddCmd(mixed cmd, mixed func, [mixed flag, [mixed id]]);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/commands.c
+
+ARGUMENTE
+---------
+::
+
+ cmd
+ Verben, auf die reagiert werden soll
+
+ ODER
+
+ Regel mit Triggerverb und noetigen Keywords/Synonymen
+ func
+ Funktionsname im selben Objekt oder Closure (Funktionspointer)
+ flag (optional)
+ Unscharfe Ausfuehrung == 1
+
+ ODER
+
+ Fehlermeldungen bei Nutzung von Regeln
+ id (optional)
+ eine ID, ueber die das Kommando eindeutig wieder geloescht
+ werden kann
+
+BESCHREIBUNG
+------------
+::
+
+ Wenn ein Spieler im Einflussbereich des Objektes das Verb benutzt,
+ wird die entsprechende Funktion im Objekt aufgerufen:
+ - die Verben sollten Imperative sein
+ - die Funktion muss 1 fuer ERFOLG (und FPs!) und 0 sonst zurueckgeben
+ (sonst werden evtl. weitere Funktionen mit diesem Kommandoverb gerufen)
+ - innerhalb der Funktionen koennen Fehlermeldungen fuer den totalen
+ Misserfolg des Kommandos mit notify_fail gesetzt werden
+ (anstatt "Wie bitte?")
+
+ AddCmd ist ein dynamischer Ersatz fuer add_action - im Gegensatz
+ zu add_action koennen auch ohne erneuten Aufruf der init() neue
+ Kommandos hinzugefuegt werden.
+
+ AddCmd kann das Leben einfacher machen mit:
+ ### REGELN: ###
+ Bei komplexen Syntaxen kann ein String angegeben werden, der die
+ _notwendigen_ (nicht die erlaubten!) Schluesselworte und deren
+ zulaessige Synonyme beschreibt. Damit kann man sich einen grossen
+ Teil eigener Auswertung ersparen.
+
+ Nur wenn in richtiger Reihenfolge aus JEDER der durch & getrennten
+ Synonymgruppen ein Wort im Spielerkommando enthalten ist, wird
+ die zugehoerige Funktion ausgefuehrt.
+
+ Trenner sind: | fuer Alternativen
+ & fuer Konjunktionen
+
+ Beispiel:
+ "ritz|ritze|schnitz|schnitze&mit&messer|schnitzmesser&"
+ "herz|herzchen&rinde|baumrinde"
+ wuerde z.B. durch
+ "ritz mit dem Messer ein Herz in die Rinde des Baumes"
+ "schnitz mit Messer Herzchen Baumrinde"
+ "schnitz mit meinem Messer Herzchen in die harte Baumrinde"
+ erfuellt werden.
+
+ Spezialregelteile sind:
+ - @PRESENT: entspricht einem Objekt in Inv oder Env des Spielers
+ - @ID: entspricht der ID des kommandobesitzenden Objektes
+ (wo die Kommandomethode definiert ist, ist noch unwichtig)
+ - @PUT_GET_DROP, @PUT_GET_TAKE, @PUT_GET_NONE:
+ entsprechend den Filteroptionen fuer find_obs()
+ ACHTUNG: Zusaetzliche Ziffern in Verbindung mit den @-Spezialregeln
+ sind schlecht. @-Regeln versuchen gierig, Objekte exakt im
+ Inventory zu matchen ("objekt 3" anstatt "objekt") und miss-
+ interpretieren daher zB die 4 in "stopf objekt 3 in loch 4" als
+ Teil des Objekt-ID-Strings.
+ Interna: 3 Substrings fuer @PRESENT/@ID ("gruener kristall 2")
+ 5 fuer @PUT... ("kristall 2 in beutel 3")
+
+ ### FEHLERMELDUNGEN (bei Anwendung von Regeln): ###
+ Als dritter Parameter koennen auch Fehlermeldungen fuer jeweils
+ fehlende Synonymgruppen (ausser der ersten - den Kommandoverben)
+ angegeben werden. Sie werden in derselben Reihenfolge (!) wie die
+ Synonymgruppen angegeben.
+
+ Mit nicht von Spielern erfuellbaren Regeln und ^-Fehlermeldungen
+ kann man auch ohne Ausfuehrung einer Funktion Texte an Spieler
+ und Umgebung ausgeben. Siehe dazu AddCmd_bsp.
+
+ Trenner sind: | zum Trennen der einzelnen Fehlermeldungen
+ ^ um
+ - die Auswertung (ab dieser Fehlermeldung!) mit
+ "return 1;" zu beenden und
+ - eine write^say-Meldung zu trennen und
+ - (fuer funktionslose AddCmd auch FPs zu vergeben!)
+
+ Beispielfehlermeldungen fuer obige Regel:
+ "Womit willst Du schnitzen?|Was willst Du schnitzen?|"
+ "Wohinein willst Du das schnitzen?"
+
+ Es koennen in den Fehlermeldungen folgende Platzhalter benutzt
+ werden:
+ - @verb (ersetzt durch query_verb() ohne beendendes 'e')
+ - @VERB (ersetzt durch capitalize(query_verb()) ohne beendendes 'e')
+ - @WERx, @WESSENx, @WEMx, @WENx: siehe alles aus replace_personal()
+ - @WE..1 ist immer der aktive Spieler
+ - alle folgenden sind die matchenden Parameter der Spielereingabe
+ - (x-1)<=Fehlermeldung (da x=1 Spieler und
+ (x-1)>Fehlermeldungsobjekt nicht existent)
+
+ Ausfuehrungsbeispiel:
+ AddCmd("ritz|ritze|schnitz|schnitze&mit&messer|schnitzmesser&"
+ "herz|herzchen&rinde|baumrinde",#'fun,
+ "Willst Du mit etwas @verben?|Womit willst du @verben?|"
+ "Was willst du mit dem @WEM3 @verben?|"
+ "Wohinein willst Du das @WEN4 schnitzen?");
+ 1. "ritze" == "Willst Du mit etwas ritzen?"
+ 2. "schnitz mit" == "Womit willst du schnitzen?"
+ 3. "ritz mit messer" == "Was willst du mit dem messer ritzen?"
+ 4. "ritze mit dem messer ein herz" ==
+ "Wohinein willst Du das herz schnitzen?"
+ 5. "ritze mit dem messer ein herzchen in die baumrinde"
+ == Erfolg!
+
+ ### UNSCHARFER AUSFUEHRUNG: ###
+ Bei unscharfer Ausfuehrung wird die zugehoerige Methode auch dann
+ ausgefuehrt, wenn das verwendete Verb ein Superstring ist und
+ bisher noch nicht behandelt wurde.
+ Dieses Verhalten sollte nur beim generellen Abfangen von
+ Befehlsgruppen benutzt werden und ist ansonsten veraltet. Es
+ entsprich add_action("fun","kommando",1).
+
+
+ Beispiel:
+ 1. AddCmd("klett","fun",1);
+ 2. AddCmd("kletter|klettere&hoch",#'fun2,"Wohin klettern?");
+
+ a) "klett"
+ b) "kletter"
+ c) "klettere hoch"
+
+ Ausgefuehrte Funktion bei: 1a, 1b, 1c; 2c
+ (1 wuerde also immer ausgefuehrt)
+ Fehlermeldung bei: 2b ("Wohin klettern?")
+
+BEMERKUNGEN
+-----------
+::
+
+ - Methoden der put_and_get (nimm/nehme) sollten so nicht versucht
+ werden zu ueberschreiben - dazu sind invis Container da
+ - benutzt man fuer <function> eine Closure, kann man die Fkt. auch
+ protected oder private deklarieren _und_ sie kann in einem
+ anderen Objekt sein
+ - bei Regeln wird an die ggf. gerufene Methode als zweiter Parameter
+ ein Array der erfuellenden Eingabeteile uebergeben:
+ "steck&@PRESENT&in&loch" bei Erfuellung -> ({<Objekt>,"in","loch})
+ - bei Nutzung von @PUT_GET_XXX koennen die Parameter wiederum
+ Arrays sein ("jede Hose" -> mehrere gueltige Objekte)
+ - juengere AddCmd ueberschreiben aeltere, bzw. werden vor diesen
+ ausgewertet
+ - @PUT_GET_XXX kosten sehr viel Auswertungszeit
+
+BEISPIELE (SIEHE AUCH ADDCMD_BSP):
+ // SIMPEL: ganz simpel, beinahe wie add_action
+ AddCmd("befiehl","action_befehlen");
+ ...
+ int action_befehlen(string str) {
+ if(!str || !strlen(str))
+ // Fehlermeldung, falls gar keine Funktion 1 dafuer zurueckgibt
+ notify_fail("Was willst du befehlen?!\n");
+ else {
+ write("Du befiehlst \""+str+"\", und alle folgen!\n");
+ say(TP->Name(WER)+" befiehlt \""+str+"\", und du folgst!\n");
+ return 1; // ERFOLG - Abbruch der Kommandoauswertung
+ }
+ return 0; // MISSERFOLG - Fehlermeldung oben gesetzt
+ }
+
+ // SIMPEL .. weitere Beispiele
+ AddCmd(({"kletter","klettere"}),"action_klettern" );
+ AddCmd(({"renn","renne"}),#'action_rennen);
+
+ // REGELN: eine komplexere Regel
+ AddCmd("loesch|loesche|ersticke&feuer|brand|flammen&decke|wolldecke",
+ "action_loeschen",
+ "Was willst du loeschen?|Womit willst du loeschen?");
+
+ // REGELN: mit Platzhaltern im Fehlerstring
+ AddCmd("spring|springe|huepf|huepfe&von|vom&baum|ast|eiche",
+ #'action_huepfe,
+ "Willst du von etwas @verben?|Von wo willst du @verben?");
+
+ // SCHLECHT: eine unscharfe Regel - sie sollten eine Ausnahme sein (!)
+ AddCmd("kletter","fun_klettern",1);
+
+ // FALSCH: sehr schlecht, kein Imperativ verwendet
+ // ausserdem sollte man fuer solche Syntaxen AddReadDetail benutzen
+ AddCmd("lese","eval_lesen");
+
+ // SIMPLE REGEL OHNE METHODE
+ // mit Regeln kann man auch Aktivitaeten im Raum erlauben, ohne eine
+ // Funktion aufrufen zu muessen: die letzte Regel ist fuer Spieler
+ // unmoeglich zu erfuellen, die dazugehoerige Fehlermeldung wird mit
+ // dem ^ (write-Flag) versehen und entsprechend an den Spieler
+ // (und den Raum (hinter dem ^)) ausgegeben
+ AddCmd("spring|springe&herunter|runter&\n\bimpossible",0,
+ "Wohin oder wovon willst Du springen?|"
+ "Du springst vom Baum und kommst hart auf.^"
+ "@WER1 springt vom Baum und kommt hart auf.");
+
+SIEHE AUCH
+----------
+::
+
+ AddCmd_bsp, RemoveCmd(L), init(E)
+ Fehlermeldungen: notify_fail(E), _notify_fail(E)
+ Argumentstring: query_verb(E), _unparsed_args(L)
+ Sonstiges: replace_personal(E), enable_commands(E)
+ Alternativen: AddAction(L), add_action(E)
+
+30. Aug 2013 Gloinson
+
diff --git a/doc/sphinx/lfun/AddCmd_bsp.rst b/doc/sphinx/lfun/AddCmd_bsp.rst
new file mode 100644
index 0000000..d0665d3
--- /dev/null
+++ b/doc/sphinx/lfun/AddCmd_bsp.rst
@@ -0,0 +1,336 @@
+AddCmd_bsp()
+============
+
+ADDCMD() - BEISPIELE
+--------------------
+::
+
+FUNKTION
+--------
+::
+
+ varargs void AddCmd(mixed cmd, mixed func, mixed flag);
+
+BEMERKUNGEN
+-----------
+::
+
+ Die hier aufgefuehrten Komplexbeispiele sind zum Verstaendnis gedacht,
+ daher fuehren sie oft Alternativen auf. Die letzte Variante ist dann
+ jeweils diejenige, welche am leichtesten das Problem loesen koennte.
+ Falls die einem zu komplex ist, hilft vielleicht die vorletzte.
+
+BEISPIELE
+---------
+::
+
+ // SIMPEL: ganz simpel, beinahe wie add_action
+ AddCmd("befiehl","action_befehlen");
+ ...
+ int action_befehlen(string str) {
+ if(!str || !strlen(str))
+ // Fehlermeldung, falls gar keine Funktion 1 dafuer zurueckgibt
+ notify_fail("Was willst du befehlen?!\n");
+ else {
+ write("Du befiehlst \""+str+"\", und alle folgen!\n");
+ say(TP->Name(WER)+" befiehlt \""+str+"\", und du folgst!\n");
+ return 1; // ERFOLG - Abbruch der Kommandoauswertung
+ }
+ return 0; // MISSERFOLG - Fehlermeldung oben gesetzt
+ }
+
+ // SIMPEL .. weitere Beispiele
+ AddCmd(({"kletter","klettere"}),"action_klettern" );
+ AddCmd(({"renn","renne"}),#'action_rennen);
+
+ // REGELN: eine komplexere Regel
+ AddCmd("loesch|loesche|ersticke&feuer|brand|flammen&decke|wolldecke",
+ "action_loeschen",
+ "Was willst du loeschen?|Womit willst du loeschen?");
+
+ // REGELN: mit Platzhaltern im Fehlerstring
+ AddCmd("spring|springe|huepf|huepfe&von|vom&baum|ast|eiche",
+ #'action_huepfe,
+ "Willst du von etwas @verben?|Von wo willst du @verben?");
+
+ // SCHLECHT: eine unscharfe Regel - sie sollten eine Ausnahme sein (!)
+ AddCmd("kletter","fun_klettern",1);
+
+ // FALSCH: sehr schlecht, kein Imperativ verwendet
+ // ausserdem sollte man fuer solche Syntaxen AddReadDetail benutzen
+ AddCmd("lese","eval_lesen");
+
+ // SIMPLE REGEL
+ static int action_jump(string str); // Prototype (wegen closure)
+ ...
+ AddCmd("spring|springe|huepf|huepfe&von&baum|ast",#'action_jump,
+ "Willst Du von etwas @verben?|Wovon willst Du @verben?");
+ ...
+ static int action_jump(string str) {
+ write(break_string("Du springst vom Baum und kommst hart auf!",78));
+ this_player()->move((XXXROOM+"boden"), M_GO, 0,
+ "springt unelegant vom Baum","faellt vom Baum");
+ this_player()->Defend(random(100),({DT_BLUDGEON}),([SP_RECURSIVE:1]),
+ this_object());
+ return 1;
+ }
+
+ // SIMPLE REGEL OHNE METHODE
+ // mit Regeln kann man auch Aktivitaeten im Raum erlauben, ohne eine
+ // Funktion aufrufen zu muessen: die letzte Regel ist fuer Spieler
+ // unmoeglich zu erfuellen, die dazugehoerige Fehlermeldung wird mit
+ // dem ^ (write-Flag) versehen und entsprechend an den Spieler
+ // (und den Raum (hinter dem ^)) ausgegeben
+ AddCmd("spring|springe&herunter|runter&\n\bimpossible",0,
+ "Wohin oder wovon willst Du springen?|"
+ "Du springst vom Baum und kommst hart auf.^"
+ "@WER1 springt vom Baum und kommt hart auf.");
+
+## Komplexbeispiel: Regeln mit Fehlermeldungen ##
+ ## Variante 1, OHNE REGELN ##
+ // bei Nichtverwendung von Regeln muss man Parameter selbst auswerten
+ AddCmd(({"bohr","bohre"}),#'action_bohren);
+ ...
+ private int action_bohren(string str) {
+ string *tmp;
+ notify_fail("Wo willst (etwas) Du bohren?\n");
+ if(!str) return 0; // Tja, keine Argumente ...
+ tmp=explode(str," "); // nach " " in Argument-Array aufspalten
+ if((i=member(tmp,"loch"))>=0) { // aha, ab jetzt uebernehmen wir :)
+ if((j=member(tmp[(i+1)..],"in"))<0 &&
+ (j=member(tmp[(i+1)..],"durch"))<0)
+ write("Willst Du das Loch in etwas bohren?\n");
+ else if((i=member(tmp[(j+1)..],"boden"))<0 &&
+ (i=member(tmp[(j+1)..],"erde"))<0)
+ write("In/Durch was willst du das Loch bohren?\n");
+ else {
+ write("Du bohrst ein Loch in den Boden.\n");
+ say(this_player()->Name(WER)+" bohrt ein Loch in den Boden.\n");
+ }
+ return 1; // "bohre loch" war so eindeutig, dass nur diese
+ // Methode gemeint sein konnte, also brechen wir die
+ // weitere Auswertung auf jeden Fall ab (und geben
+ // eine write-Fehlermeldung)
+ } // end if(..."loch")
+ return 0; // "bohre" allein muss nicht diese Methode meinen,
+ // also nur obige notify_fail()-Meldung, falls
+ // sich nach dieser Methode gar keine sonst
+ // angesprochen fuehlt
+ } // end fun
+
+ ## Variante 1a, OHNE REGELN ##
+ // prinzipiell koennte die Methode action_bohren auch so
+ // aussehen, ist aber nicht ganz so flexibel:
+ private int action_bohren(string str) {
+ string tmp;
+ if(!str || (sprintf(str,"loch in erde%s",tmp)!=1 &&
+ sprintf(str,"loch durch erde%s",tmp)!=1 &&
+ sprintf(str,"loch in boden%s",tmp)!=1 &&
+ sprintf(str,"loch durch boden%s",tmp)!=1))
+ notify_fail("Willst Du in irgendwas ein Loch bohren?\n");
+ else {
+ ...
+ return 1;
+ }
+ return 0;
+ }
+
+ ## Variante 2, MIT REGEL ##
+ // das gleiche in etwa mal als einfache Regel
+ AddCmd("bohr|bohre&loch&in|durch&erde|boden",#'action_bohren,
+ "Was willst du (wohin) bohren?|"
+ "Willst du das Loch in etwas bohren?|"
+ "Wohin willst du das Loch bohren?");
+ ...
+ private int action_bohren(string str, mixed *param) {
+ write("Du bohrst ein Loch in den Boden.\n");
+ say(this_player()->Name(WER)+" bohrt ein Loch in den Boden.\n");
+ ...
+ return 1;
+ }
+
+ ## Variante 3, MIT REGEL UND FEHLERMELDUNG ##
+ // und nun mit Fehlermeldungen mit Ersetzungen, so dass wir mehr
+ // auf die Eingaben des Spielers eingehen
+ AddCmd("bohr|bohre&loch&in|durch&erde|boden",#'action_bohren,
+ "Was willst du (wohin) @verben?|"
+ "Willst du das Loch in etwas @verben?|"
+ "@WER3 was willst du das Loch @verben?");
+ ...
+ private int action_bohren(string str, mixed *param) ...
+
+ ## Variante 4, MIT REGEL, FEHLERMELDUNG UND RETURN 1 ##
+ // in Variante 1 kam sinnvollerweise sehr frueh der Abbruch mit
+ // "return 1;" und die Ausgabe von write-Fehlermeldungen,
+ // das koennen wir auch
+ AddCmd("bohr|bohre&loch&in|durch&erde|boden",#'action_bohren,
+ "Was willst du (wohin) @verben?|"
+ "Willst du das Loch in etwas @verben?^|"
+ "@WER3 was willst du das Loch @verben?^");
+ ...
+ private int action_bohren(string str, mixed *param) ...
+
+ ## Variante 5, MIT REGEL, FEHLERMELDUNG, RETURN 1, OHNE FUN ##
+ // und falls in action_bohren() nichts ausser Ausgaben passiert, koennen
+ // wir uns die auch ganz sparen indem wir eine nichterfuellbare Regel
+ // samt Fehlermeldung bauen
+ AddCmd("bohr|bohre&loch&in|durch&erde|boden&\nimpossible",0,
+ "Was willst du (wohin) @verben?|"
+ "Willst du das Loch in etwas @verben?^|"
+ "@WER3 was willst du das Loch @verben?^|"
+ "Du @verbst ein Loch @WER3 den Boden.^@WER1 @verbt "
+ "ein Loch @WER3 den Boden.");
+
+ --- Ende Komplexbeispiel Regeln mit Fehlermeldungen ---
+
+## Komplexbeispiel: Spezialregeln @PRESENT und @ID ##
+ ## Variante 1, OHNE REGELN ##
+ // oft agieren Kommandos auf Objekten im Raum, diese muessen dabei per
+ // present() identifiziert werden:
+ // Beispiel ist ein Geldautomat (den man besser mit einem Container
+ // mit PreventInsert() basteln sollte)
+ AddCmd(({"stopf","stopfe"}),#'action_stopf);
+ ...
+ private int action_stopf(string str) {
+ string tmp,tmp2;
+ object o;
+
+ if(str && (sprintf("%s in automat%s",tmp,tmp2)==2 ||
+ sprintf("%s in geldautomat%s",tmp,tmp2)==2 ||
+ sprintf("%s in bankomat%s",tmp,tmp2)==2) {
+ o=present(tmp,this_player());
+ if(o) {
+ if(o->QueryProp(...)) {
+ write(break_string(
+ "Du stopfst "+o->name(WEN,1)+" in den Automaten.",78));
+ say(...);
+ } else {
+ write(break_string(
+ "Du versuchst "+o->name(WEN,1)+" in den Automaten zu stopfen, "
+ "aber "+o->QueryPronoun(WER)+" passt nicht hinein.",78));
+ say(...);
+ }
+ } else {
+ write("Was willst du in den Automaten stopfen?\n");
+ say(....);
+ }
+ return 1;
+ }
+ notify_fail("Was willst du wohin stecken?\n");
+ return 0;
+ }
+
+ ## Variante 2, MIT REGEL ##
+ // einerseits koennen wir das Finden von Objekten in Inv und Env
+ // integrieren und uns andererseits das Aufzaehlen aller IDs des
+ // Automaten ersparen
+ AddCmd("steck|stecke&@PRESENT&in&@ID",#'action_stopf,
+ "Was willst du wohin stopfen?|"
+ "Willst du @WEN2 in etwas stopfen?|"
+ "Wohinein willst du @WEN2 stopfen?");
+ ...
+ // dabei werden wie immer die gefunden Matches als Parameterarray
+ // uebergeben ... und die @PRESENT und @ID als Objekte!
+ private int action_stopf(string str, mixed *param) {
+ if(param[0]->QueryProp(...)) {
+ write(break_string(
+ "Du stopfst "+param[0]->name(WEN,1)+" in den Automaten.",78));
+ say(...);
+ } else {
+ write(break_string(
+ "Du versuchst "+param[0]->name(WEN,1)+" in den Automaten zu "
+ "stopfen, aber "+param[0]->QueryPronoun(WER)+" passt nicht "
+ "hinein.",78));
+ say(...);
+ }
+ return 1;
+ }
+
+ --- Ende Komplexbeispiel Spezialregeln @PRESENT und @ID ---
+
+## Komplexbeispiel: gleiches Verb, mehrere Regeln ##
+ // Das Problem mehrerer Regeln fuer ein Kommandoverb besteht darin, dass
+ // letztlich nur eine der Fehlermeldungen zum Tragen kommt - welche
+ // genau ist etwas vage.
+ // Dabei kann man sich auf eines verlassen: juengere AddCmd werden
+ // zuerst ausgewertet. Wenn sich das aendert, tretet euren EM.
+
+ ## Problem 1: Mehrere Regeln weil mehrere Zwecke ##
+ ## Variante 1 - GLEICHLAUTENDE FEHLERMELDUNG
+ // fuer alles wird eine identische Fehlermeldung gesetzt, das ist
+ // natuerlich nicht sehr flexibel oder schoen
+ AddCmd("kriech|krieche&hoch|hinauf|hinaus|heraus|raus",#'result_kriech,
+ "Wohin willst Du kriechen?");
+ AddCmd("kriech|krieche&nach&oben",#'result_kriech,
+ "Wohin willst Du kriechen??|Wohin willst Du kriechen?");
+ AddCmd("kriech|krieche&aus&loch|grube|falle",#'result_kriech);
+ "Wohin willst Du kriechen?|Wohin willst Du kriechen?");
+
+ // oder man versucht eine bessere Regel zu schaffen, was hier durch
+ // die Moeglichkeit von zwei oder drei Parameter unmoeglich ist
+
+ ## Variante 2 - EIGENE AUSWERTUNG
+ // es bietet sich also eigene Weiterauswertung an, was durch die
+ // Uebergabe der getriggerten Verben erleichtert wird:
+ AddCmd("kriech|krieche&hoch|hinauf|hinaus|heraus|raus|aus|nach",
+ #'result_kriech,
+ "Wohin willst Du kriechen?");
+ ...
+ static int result_kriech(string str, mixed *extra) {
+ if(member(extra,"aus")>=0 &&
+ !sizeof(({str}),"*.\\<(hoehle|grube|falle)\\>.*"))
+ notify_fail("Woraus willst Du kriechen?\n");
+ else if(member(extra,"nach")>=0 && strstr(str,"oben")<0)
+ notify_fail("In welche Richtung willst Du kriechen?\n");
+ else if(this_player()->QueryAttribute(A_DEX)>10 ||
+ member(holding_root,this_player())) {
+ write("Du kriechst mit Muehe heraus.\n");
+ this_player()->move((XXXROOM+"draussen"), M_GO, 0,
+ "kriecht mit Muehe aus der Grube",
+ "kriecht aus einer Grube");
+ return 1;
+ } else
+ write("Du bist zu ungeschickt, halt Dich irgendwo fest.\n");
+ return 1;
+ }
+ return 0;
+ }
+ // (ob sich der Aufwand fuer diese Beispielsyntax lohnt ist fraglich)
+
+ ## Problem 2: mehrere Regeln, weil optionale Parameter ##
+ // Manchmal will man optionale Parameter erlauben, die aber eine
+ // Wirkung zeigen sollen:
+ AddCmd("schlag|schlage&@ID&hart",#'action_schlag_hart,
+ "Was oder wen willst du @verben?|"
+ "Wie willst du @WEN2 schlagen?");
+ AddCmd("schlag|schlage&@ID",#'action_schlag,
+ "Was oder wen willst du @verben?");
+
+ // Da juengere AddCmd aelteren vorgehen, wird die komplexere Regel samt
+ // ihrer Fehlermeldung nie ausgewertet, da ein "schlag ball hart" auch
+ // die zweite Regel triggert.
+
+ // anders herum:
+ AddCmd("schlag|schlage&@ID",#'action_schlag,
+ "Was oder wen willst du @verben?");
+ AddCmd("schlag|schlage&@ID&hart",#'action_schlag_hart,
+ "Was oder wen willst du @verben?|"
+ "Wie willst du @WEN2 schlagen?");
+
+ // Jetzt wird die komplexere Regel zuerst ueberprueft und triggert
+ // auch die richtige Funktion.
+ // Leider kommt die Fehlermeldung nie zum Tragen, denn was durch Regel 2
+ // durchfaellt, triggert entweder Regel 1 oder faellt auch durch Regel 1
+ // durch und ueberschreibt dabei die Meldung.
+
+ AddCmd("schlag|schlage&@ID",#'action_schlag,
+ "Was oder wen willst du wie @verben?");
+ AddCmd("schlag|schlage&@ID&hart",#'action_schlag_hart);
+
+ // Fast perfekt. Besser wird es nicht.
+
+
+ --- Ende Komplexbeispiel mehrere Regeln ---
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/AddDefender.rst b/doc/sphinx/lfun/AddDefender.rst
new file mode 100644
index 0000000..ae5b28b
--- /dev/null
+++ b/doc/sphinx/lfun/AddDefender.rst
@@ -0,0 +1,51 @@
+AddDefender()
+=============
+
+FUNKTION
+--------
+::
+
+ void AddDefender(object friend);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ friend
+ Objekt (normal Lebewesen), welches zukuenftig ueber Angriffe
+ informiert werden soll oder diese sogar abwehrt.
+
+BESCHREIBUNG
+------------
+::
+
+ Ein Lebewesen, welches angegriffen wird, kann andere Objekte ueber
+ einen solchen Angriff per InformDefend() informieren oder ihnen
+ sogar die Moeglichkeit geben, per DefendOther() direkt in den
+ laufenden Angriff einzugreifen (Schaeden abwehren oder umwandeln).
+ Im Normalfall handelt es sich hierbei um andere Lebewesen, welche
+ als Verteidiger des angegriffenen Lebewesens auftreten: Daher der
+ Name der Funktion.
+ Die Objekte sind in Form eines Arrays in der Property P_DEFENDERS
+ abgespeichert und koennen dort abgerufen werden. Natuerlich kann
+ man weitere Objekte direkt dort eintragen, jedoch sollte man die
+ hierfuer bereitgestellte Funktionen AddDefender() verwenden.
+ Zum Loeschen von Eintraegen im Array steht ebenfalls eine Funktion
+ bereit: RemoveDefender().
+
+SIEHE AUCH
+----------
+::
+
+ RemoveDefender(), InformDefend(), DefendOther(),
+ P_DEFENDERS, /std/living/combat.c
+
+
+Last modified: Thu Jul 29 18:48:45 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/AddDetail.rst b/doc/sphinx/lfun/AddDetail.rst
new file mode 100644
index 0000000..69db5da
--- /dev/null
+++ b/doc/sphinx/lfun/AddDetail.rst
@@ -0,0 +1,110 @@
+AddDetail()
+===========
+
+FUNKTION
+--------
+::
+
+ void AddDetail(string|string* keys,
+ string|string*|mapping|closure desc);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ keys
+ String oder Array von Strings mit den Namen der Details.
+ desc
+ String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+
+BESCHREIBUNG
+------------
+::
+
+ Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
+ bei der Untersuchung aussehen, haengt im wesentlichen vom Typ der
+ Beschreibung <desc> ab:
+ <desc> ist ein String.
+ Beim Untersuchen wird dieser String zurueckgegeben.
+ <desc> ist ein String-Array.
+ Beim Untersuchen wird zufaellig einer der Strings zurueckgegeben.
+ <desc> ist ein Mapping.
+ Das Mapping muss folgenden Aufbau haben:
+ ([0: "Defaulttext",
+ "rasse1": "r1text", ...]).
+
+ Falls fuer die Rasse des das Detail untersuchenden Spielers ein
+ Eintrag im Mapping existiert, wird der entsprechende Text
+ zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
+ rassenabhaengige Details moeglich. Siehe auch die Beispiele.
+ <desc> ist eine Closure.
+ In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
+ zurueckgegeben. Die Closure bekommt dabei den Namen des Details
+ als Parameter uebergeben.
+
+ Fuer Details koennen Forscherpunkte eingetragen werden.
+
+BEISPIELE
+---------
+::
+
+ Ein schlichtes Detail:
+
+ AddDetail(({"sofa","couch"}), "Eine kleine Couch.\n");
+
+ Laengere Details sollten hierbei nicht per Hand umgebrochen werden,
+ sondern man kann hierzu die Funktion break_string() nutzen:
+
+ AddDetail("detail", break_string(
+ "Du wolltest es ja nicht anders, jetzt musst Du Dir dieses "
+ "fuerchterlich lange Detail durchlesen!!!", 78));
+
+ Noetige Zeilenumbrueche bei Zeilenlaengen groesser 77 werden so
+ automatisch generiert.
+ Ein rassenabhaengiges Detail:
+
+ AddDetail(({"bett","bettchen"}),
+ ([0 :"Eine kleines Bett.\n", // Der Defaulttext
+ "zwerg": // Die Rasse klein schreiben
+ "Das Bett laedt geradezu zu einem Nickerchen ein.\n"]));
+
+ Und nun ein Detail mit Closure (diese Version ersetzt das Verhalten
+ von AddSpecialDetail).
+
+ int hebel_betaetigt;
+ ...
+ string hebel(string str); // Funktion bekannt machen (Prototyping)
+ ...
+ AddDetail(({"hebel","schalter"}), #'hebel);
+ ...
+ string hebel(string key) {
+ if(hebel_betaetigt)
+ return "Der "+capitalize(key)+" steht auf EIN.\n";
+ else
+ return "Der "+capitalize(key)+" steht auf AUS.\n";
+ }
+
+ Man erhaelt verschiedene Ergebnisse beim Untersuchen, je nachdem
+ ob das Flag hebel_betaetigt gesetzt ist oder nicht.
+
+SIEHE AUCH
+----------
+::
+
+ Setzen: AddReadDetail(), AddSmells(), AddSounds(),
+ AddTouchDetail()
+ Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+ RemoveSounds(), RemoveTouchDetail()
+ Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS,
+ P_TOUCH_DETAILS, P_SPECIAL_DETAILS
+ Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+ Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddDrink.rst b/doc/sphinx/lfun/AddDrink.rst
new file mode 100644
index 0000000..7ced4bb
--- /dev/null
+++ b/doc/sphinx/lfun/AddDrink.rst
@@ -0,0 +1,19 @@
+AddDrink()
+==========
+
+BEMERKUNGEN
+-----------
+::
+
+ Die Funktion AddDrink() sollte NICHT MEHR BENUTZT werden.
+ Bitte AddToMenu() verwenden.
+
+SIEHE AUCH
+----------
+::
+
+ AddToMenu(), RemoveFromMenu()
+
+
+Last modified: Fri Mar 03 13:23:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/lfun/AddExit.rst b/doc/sphinx/lfun/AddExit.rst
new file mode 100644
index 0000000..6c619fd
--- /dev/null
+++ b/doc/sphinx/lfun/AddExit.rst
@@ -0,0 +1,114 @@
+AddExit()
+=========
+
+FUNKTION
+--------
+::
+
+ void AddExit(string|string* cmd, closure|string dest);
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/exits
+
+ARGUMENTE
+---------
+::
+
+ string/string* cmd
+ die Richtung(en), in die der Ausgang fuehrt
+ string/closure dest
+ das Ziel des Ausgangs mit Text/Closure
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird ein Ausgang in die Richtung(en) cmd eingefuegt. Die Art des
+ Ausgangs haengt ab von dest:
+
+ - ein String:
+ - mit einem Dateinamen:
+ Der Ausgang fuehrt in den Raum, den der Dateiname bezeichnet.
+ - der Form "<msg>#dateiname"
+ Der Ausgang fuehrt in den Raum, den der Dateiname bezeichnet,
+ bei der Benutzung wird jedoch statt "<name> geht nach <richtung>"
+ "<name> geht nach <msg>" ausgegeben.
+ - eine Closure:
+ Die Closure wird bei Nutzung des Ausgangs aufgerufen. Das entspricht
+ eine SpecialExit - in der gerufenen Funktion muss man den Spieler
+ selbst in den Zielraum bewegen.
+ Gegebenenfalls kann das durch AddCmd() ersetzt werden.
+
+BEMERKUNGEN
+-----------
+::
+
+ Man kann fuer den Dateinamen des Zielraumes auch einen relativen Pfad
+ angeben. Die Auswertung erfolgt nach folgendem Schema:
+ - "./<dateiname>"
+ Es wird ein Zielraum relativ zum gleichen Verzeichnis wie dieser
+ Raum angesprochen.
+ - "../<dateiname>"
+ Es wird ein Zielraum relativ zur Verzeichnisebene ueber der
+ dieses Raumes angesprochen (analog mit mehrerern "../..")
+
+ Mittels P_HIDE_EXITS kann man Ausgaenge verstecken.
+
+ Bei der Benutzung eines Ausgangs wird der Hook H_HOOK_EXIT_USE
+ ausgeloest.
+
+BEISPIELE
+---------
+::
+
+ ### normale Ausgaenge ###
+ // Beim Kommando "sueden" kommt: "<name> geht nach Sueden."
+ AddExit("sueden", "/gilden/abenteurer");
+
+ // Beim Kommando "sueden" kommt: "<name> geht in die Gilde."
+ AddExit("sueden", "in die Gilde#/gilden/abenteurer");
+
+ ### Ausgaenge mit relativen Pfaden ###
+ // Der Name des Raumes sei "/d/inseln/wargon/hafen1"
+ // Dieser Ausgang geht nach "/d/inseln/wargon/kneipe":
+ AddExit("norden", "./kneipe" );
+
+ // Und dieser nach "/d/inseln/anthea/anlege":
+ AddExit("sueden", "../anthea/anlege" );
+
+ ### dynamische Ausgaenge ###
+ // ein Ausgang soll nur von Froeschen benutzbar sein:
+
+ static int lochfkt(string dir); // Prototyp
+ ...
+ AddExit("loch", #'lochfkt);
+ // auch identisch zu:
+ // AddSpecialExit("loch", #'lochfkt); [eine Closure] oder
+ // AddSpecialExit("loch", "lochfkt"); [ein Funktionsname]
+
+ static int lochfkt(string dir) {
+ if (!(this_player()->QueryProp(P_FROG))) {
+ // Kein Frosch => passt nicht!
+ notify_fail("Du bist zu gross!\n");
+ return 0;
+ }
+ // Meldungen werden im move() gleich mitgegeben
+ return this_player()->move("/room/loch", M_GO, 0,
+ "huepft ins Loch", "huepft herein");
+ }
+
+SIEHE AUCH
+----------
+::
+
+ AddSpecialExit(), GetExits(),
+ RemoveExit(), RemoveSpecialExit(),
+ GuardExit(),
+ H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
+ ausgaenge
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/AddExp.rst b/doc/sphinx/lfun/AddExp.rst
new file mode 100644
index 0000000..eb836ca
--- /dev/null
+++ b/doc/sphinx/lfun/AddExp.rst
@@ -0,0 +1,56 @@
+AddExp()
+========
+
+FUNKTION
+--------
+::
+
+ int AddExp(int e)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ int e - Anzahl der hinzuzufuegenden (abzuziehenden) XP
+
+BESCHREIBUNG
+------------
+::
+
+ Dem Living werden e XP auf seine bisherigen P_XP addiert.
+
+ Falls es sich um einen Spieler mit P_KILLS>0 handelt und
+ e positiv ist, bekommt der Spieler keine XP gutgeschrieben.
+
+ P_LAST_XP wird aktualisiert.
+
+BEMERKUNG
+---------
+::
+
+ - positive und negative Werte sind moeglich
+ - P_XP wird nicht <0 gesetzt.
+
+RUECKGABEWERT
+-------------
+::
+
+ int - neuer XP-Wert
+
+SIEHE AUCH
+----------
+::
+
+ Funktionen: do_damage(), DistributeExp()
+ Properties: P_XP, P_LAST_XP
+ Sonstiges: P_NO_XP, P_NO_SCORE
+ create_default_npc()
+
+14.Feb 2007 Gloinson
+
diff --git a/doc/sphinx/lfun/AddExtraLook.rst b/doc/sphinx/lfun/AddExtraLook.rst
new file mode 100644
index 0000000..30b255a
--- /dev/null
+++ b/doc/sphinx/lfun/AddExtraLook.rst
@@ -0,0 +1,131 @@
+AddExtraLook()
+==============
+
+AddExtraLook()
+varargs int AddExtraLook(string look, [int duration, string key,
+ string lookende, object ob]);
+--------------------------------------------------------------------------------------------------------------------------------------
+::
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/description.c
+
+BESCHREIBUNG
+------------
+::
+
+ Der Extralook erscheint in der Langbeschreibung des Lebewesens.
+ Eintraege koennen mit dieser Funktion hinzugefuegt werden. Dies ist der
+ bevorzugte Weg, wenn ansonsten extra ein Objekt im Spielerinventar abgelegt
+ werden muesste.
+
+
+
+ Alle Parameter bis auf <look> sind optional.
+
+ARGUMENTE
+---------
+::
+
+ - string look:
+ String, der in der Langbeschreibung des Lebewesens zusaetzlich ausgegeben
+ wird.
+ Kann auch ein Funktionsname sein, wenn <ob> angegeben wird (s.u.).
+ - int duration:
+ > 0: Wie lang bleibt der Extralook gueltig (in Sekunden)? Anschliessend
+ wird er automatisch geloescht.
+ 0: Dieser Eintrag bleibt unbegrenzt gueltig.
+ < 0: Dieser Eintrag bleibt bis zum Ende/Reboot bestehen.
+ - string key:
+ Schluesselwort, unter dem der Eintrag registriert wird und mit dem man ihn
+ auch mittels RemoveExtraLook() entfernen kann. Sollte natuerlich
+ moeglichst eindeutig sein. ;-) Wenn <key> nicht angeben wird, wird der
+ Objektname (object_name()) benutzt.
+ - string lookende:
+ String, der an das Lebewesen (nur bei Spielern) ausgegeben wird, wenn der
+ eingetragene Extralook abgelaufen ist.
+ Kann auch ein Funktionsname sein, wenn <ob> angegeben wird.
+ - object ob:
+ Wenn hier ein Objekt angegeben wird, werden <look> und <lookende> als
+ Funktonsnamen aufgefasst. Diese Funktionen werden in <ob> aufgerufen, wenn
+ der Extralook des Lebewesen angezeigt wird bzw. der eingetragene Extralook
+ abgelaufen ist. Diese Funktionen bekommen das jeweilige Lebenwesen als
+ Objekt uebergeben. Sie muessen einen String zurueckliefern, der ausgegeben
+ wird. Dieser String wird direkt so ausgeben, also selber fuer Zeilenumbruch
+ etc. sorgen!
+ WICHTIG: Das Objekt sollte nach Moeglichkeit eine Blueprint sein, da das
+ ganze nix mehr ausgibt, sobald der Clone zerstoert wird, falls hier
+ einer angeben wird. Wenn ihr keine BP uebergebt: Wisst, was ihr tut. ;-)
+
+RUECKGABEWERTE
+--------------
+::
+
+ > 0, falls der Eintrag erfolgreich registriert wurde.
+ < 0 sonst.
+ -1: <key> war nicht gueltig und es konnte keiner ermittelt werden.
+ -2: <look> war kein gueltiger String.
+ -3: <duration> war kein Integer.
+ -4: unter <key> gibt es schon einen Eintrag.
+
+BEMERKUNGEN
+-----------
+::
+
+ Die Strings <look> und <lookende> werden vor Ausgabe durch
+ replace_personal() geschickt, daher ist die Verwendung von @WER1, @WESSEN1
+ usw. moeglich (s. replace_personal). Dies gilt aber _nicht_ fuer den Fall,
+ dass die entsprechenden Funktionen in <ob> gerufen werden, dann muessen die
+ Funktionen selber umbrechen, etc.
+ Nach replace_personal() werden die Strings noch von break_string() auf 78
+ Zeilen umgebrochen, allerdings bleiben dabei vorhandene Umbrueche erhalten.
+ Die Meldung von <lookende> bzw. der Funktionsaufruf erfolgt, wenn der
+ Extralook der Lebewesen das erste Mal nach Ablauf der Gueltigkeit aufgerufen
+ wird.
+
+BEISPIELE
+---------
+::
+
+ # einfacher Eintrag, "fuer die Ewigkeit"
+ living->AddExtraLook("@WER1 hat den Drachengott der SSP besiegt.");
+
+ # Eintrag der nach 1h automatisch weg ist.
+ living->AddExtraLook("@WER1 ist ganz mit Marmelade bedeckt.", 3600);
+
+
+
+ # Eintrag mit bestimmten Schluessel, damit man ihn wieder entfernen kann.
+ living->AddExtraLook("@WER1 ist ganz mit Marmelade bedeckt.", 3600,
+ "humni_marmeladen_look");
+
+
+
+ # Mit "Ende"-Meldung, aber kein eigener Schluessel.
+ living->AddExtraLook("@WER1 ist patschnass.", 1200, 0,
+ "Du bist endlich wieder trocken. Puuh.");
+
+
+
+ # Mit Objekt, was den Extralook dynamisch erzeugt
+ living->AddExtraLook("get_my_special_extralook", 3600, 0, 0, this_object());
+ In diesem Fall muss this_object() natuerlich die Funktion
+ "get_my_special_extralook()" definieren, die einen String zurueckgibt.
+
+ # Mit Objekt, was den Extralook und die Endemeldung dynamisch erzeugt
+ living->AddExtraLook("get_my_special_extralook", 3600, 0,
+ "extralookende", this_object());
+
+SIEHE AUCH
+----------
+::
+
+ RemoveExtraLook(),
+ replace_personal(), break_string()
+ P_INTERNAL_EXTRA_LOOK
+
+14.05.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/AddFixedObject.rst b/doc/sphinx/lfun/AddFixedObject.rst
new file mode 100644
index 0000000..c61c2f7
--- /dev/null
+++ b/doc/sphinx/lfun/AddFixedObject.rst
@@ -0,0 +1,81 @@
+AddFixedObject()
+================
+
+FUNKTION
+--------
+::
+
+ varargs void AddFixedObject(string str, int val, mixed ids);
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/shop.c
+
+ARGUMENTE
+---------
+::
+
+ str
+ Der absolute Filename eines Objekts, das in quasi beliebiger Menge
+ vom betreffenden Laden verkauft werden soll.
+ val
+ Sofern angegeben der angenommene Wert des Objekts. Falls val nicht
+ angegeben oder 0 ist, wird der Wert aus dem angegebenen Objekt
+ selbst ermittelt.
+ Der Verkaufspreis ist 3 * Wert des Objekts.
+ ids
+ String oder Stringarray mit der ID oder den IDs, ueber die man das
+ Objekt im Laden ansprechen kann. Falls nicht angegeben, wird die
+ ID-Liste aus der blueprint des Objekts ausgelesen.
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion kann man einem Laden mitteilen, dass ein Objekt
+ in ihm in unbegrenzter Anzahl verkauft werden soll.
+ WICHTIG: Das zu verkaufende Objekt sollte dies insofern unterstuetzen,
+ dass die Blueprint die notwendigen Informationen
+ (P_SHORT, P_IDS, P_VALUE, P_LONG, P_NAME) beinhaltet. Dies bedeutet im
+ einfachsten Fall, dass im create() auf
+ if (!clonep()) return;
+ verzichtet wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+
+
+BEISPIELE
+---------
+::
+
+ AddFixedObject("/obj/fackel", 5000, "fackel");
+ Der Laden verkauft Fackeln zum Preis von 3*5000 Goldmuenzen und man
+ kann die Fackel (ausser ueber die Inventarnummer) nur mittels der
+ id "fackel" kaufen.
+
+
+
+ AddFixedObject("/obj/fackel");
+ Der Laden verkauft Fackeln zum dreifachen Wert dessen, was im Objekt
+ /obj/fackel.c angegeben ist (derzeit sind das 5 Muenzen) und laesst
+ alle IDs zu, die in /obj/fackel.c angegeben sind. Derzeit ist das
+ auch nur "fackel".
+
+SIEHE AUCH
+----------
+::
+
+ RemoveFixedObject(), SetStorageRoom(), /std/store.c
+
+
+
+----------------------------------------------------------------------------
+Letzte Aenderung: Sat Nov 9 12:59:25 2002 durch Bambi
+
diff --git a/doc/sphinx/lfun/AddFood.rst b/doc/sphinx/lfun/AddFood.rst
new file mode 100644
index 0000000..30bea9d
--- /dev/null
+++ b/doc/sphinx/lfun/AddFood.rst
@@ -0,0 +1,19 @@
+AddFood()
+=========
+
+BEMERKUNGEN
+-----------
+::
+
+ Die Funktion AddFood() sollte NICHT MEHR BENUTZT werden.
+ Bitte AddToMenu() verwenden.
+
+SIEHE AUCH
+----------
+::
+
+ AddToMenu(), RemoveFromMenu()
+
+
+Last modified: Fri Mar 03 13:23:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/lfun/AddFuel.rst b/doc/sphinx/lfun/AddFuel.rst
new file mode 100644
index 0000000..a4af00b
--- /dev/null
+++ b/doc/sphinx/lfun/AddFuel.rst
@@ -0,0 +1,52 @@
+AddFuel()
+=========
+
+FUNKTION
+--------
+::
+
+ void AddFuel(int fuel);
+
+DEFINIERT IN
+------------
+::
+
+ /std/lightsource.c
+
+ARGUMENTE
+---------
+::
+
+ fuel
+ Die zusaetzliche Brenndauer in Sekunden.
+
+BESCHREIBUNG
+------------
+::
+
+ Die Brenndauer der Lichtquelle wird um fuel Sekunden verlaengert.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Es werden keine Checks durchgefuehrt! Wenn man seine Lichtquelle
+ nachfuellbar gestalten will, sollte die Nachfuellfunktion vor dem
+ AddFuel()-Aufruf nachsehen, wie voll die Lichtquelle noch ist, und fuel
+ entsprechend begrenzen.
+
+SIEHE AUCH
+----------
+::
+
+ /std/lightsource.c
+
+
+Last modified: Wed May 8 10:16:39 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/AddFun.rst b/doc/sphinx/lfun/AddFun.rst
new file mode 100644
index 0000000..4e3856a
--- /dev/null
+++ b/doc/sphinx/lfun/AddFun.rst
@@ -0,0 +1,86 @@
+AddFun()
+========
+
+FUNKTION
+--------
+::
+
+ void AddFun(string fun, int next);
+
+DEFINIERT IN
+------------
+::
+
+ /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+ fun
+ Name der Funktion.
+ next
+ Zeit bis zur naechsten Fahrplanstation.
+
+BESCHREIBUNG
+------------
+::
+
+ Dem Fahrplan wird der Aufruf der Funktion fun, die im Transporter
+ definiert sein muss, hinzugefuegt. Nach Aufruf der Funktion vergehen
+ next Sekunden, bis die naechste Station angefahren wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEISPIELE
+---------
+::
+
+ Wenn ein zufaellig ausgewaehlter Passagier eines Schiffes unterwegs
+ seekrank werden soll, koennte man das wie folgt realisieren:
+
+ create()
+ {
+ ...
+
+ AddFun("seekrank", 5);
+ ...
+ }
+
+ seekrank()
+ {
+ object *passagiere, opfer;
+
+ // soll nicht immer passieren
+ if (random(5))
+ return;
+
+ // Opfer auswaehlen
+ passagiere = QueryPassengers();
+ if (sizeof(passagiere))
+ opfer = passagiere[random(sizeof(passagiere))];
+
+ // Und viel Spass...
+ tell_object(opfer,
+ "Du wirst seekrank! Schnell stuerzt Du zur Reling um Dich zu\n"
+ +"uebergeben.\n");
+ tell_room(this_object(),
+ sprintf("%s ueberkommt die Seekrankheit!\n%s stuerzt an die Reling, "
+ +"um sich zu uebergeben.\n",
+ capitalize(opfer->name(WEN)),
+ capitalize(opfer->QueryPronoun(WER))), ({ opfer }) );
+ }
+
+SIEHE AUCH
+----------
+::
+
+ AddRoute(), AddMsg(), /std/transport.c
+
+
+Last modified: Wed May 8 10:16:46 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/AddId.rst b/doc/sphinx/lfun/AddId.rst
new file mode 100644
index 0000000..f132960
--- /dev/null
+++ b/doc/sphinx/lfun/AddId.rst
@@ -0,0 +1,74 @@
+AddId()
+=======
+
+FUNKTION
+--------
+::
+
+ void AddId(string|string* ids);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ ids
+ String oder Array von Strings mit den Bezeichnungen, mit denen
+ sich sich das Objekt ansprechen lassen soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Jedes Objekt sollte sich auf die eine oder andere Weise ansprechen
+ lassen. Zu diesem Zweck kann man dem Objekt mit dieser Funktion
+ Bezeichner uebergeben.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Jedes Objekt sollte man zumindest mit seiner Kurzbeschreibung
+ ansprechen koennen! Fuer Abfragen von Questobjeken o.ae. sollte man
+ zusaetzlich IDs verwenden, die Sonderzeichen wie "\n" oder "\t"
+ enthalten, damit sichergestellt ist, dass der Spieler auch wirklich die
+ richtigen Objekte dabeihat.
+
+BEISPIELE
+---------
+::
+
+ AddId( "buch" );
+ AddId( "buechlein" );
+
+ Das Objekt laesst sich jetzt als "buch" und als "buechlein" ansprechen.
+
+ AddId( ({ "buch", "buechlein" }) );
+
+ Diese Zeile bewirkt das gleiche wie die obigen zwei Zeilen.
+
+ AddId( ({ "puzzle", "\nquest_puzzle" }) );
+
+ Der Spieler kann das Objekt als "puzzle" ansprechen, questrelevante
+ Objekte koennen mit der ID "\nquest_puzzle" nach ihm suchen.
+
+SIEHE AUCH
+----------
+::
+
+ AddAdjective(), RemoveId(), id(), present(), /std/thing/description.c
+
+ -----------------------------------------------------------------------
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddInfo.rst b/doc/sphinx/lfun/AddInfo.rst
new file mode 100644
index 0000000..2a7928a
--- /dev/null
+++ b/doc/sphinx/lfun/AddInfo.rst
@@ -0,0 +1,243 @@
+AddInfo()
+=========
+
+FUNKTION
+--------
+::
+
+ varargs void AddInfo( frage, meldung
+ [, indent [, [silent [, casebased] ] ] );
+
+DEFINIERT IN
+------------
+::
+
+ /std/npc/info.c
+
+ARGUMENTE
+---------
+::
+
+ string/string* frage
+ Schluesseltext(e) auf die Informationen gegeben werden sollen.
+ string/closure meldung
+ Information, die gegeben werden soll/Closure
+ string indent
+ Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
+ int/string silent
+ Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
+ string/closure casebased
+ Closure mit Returnwert string oder int.
+
+BESCHREIBUNG
+------------
+::
+
+ Wenn ein Spieler ein NPC mittels "frage <monstername> nach <frage>" nach
+ einer Information mit dem Schluessel 'frage' fragt, so wird die
+ entsprechende 'meldung' ausgegeben (oder die Closure in 'meldung'
+ gerufen und der zurueckgegebene Text ausgegeben). Der Meldung wird
+ der Name des Monsters vorangestellt.
+
+ Frage:
+ Schluessel muessen kleingeschrieben sein, koennen aber Leerzeichen
+ enthalten.
+
+ Meldung:
+ Wenn kein 'indent' angegeben ist, muss man die Meldung selbst
+ umbrechen.
+
+ Indent:
+ Wird ein 'indent' angegeben so wird jeder Zeile hinter dem
+ Monsternamen noch das 'indent' vorangesetzt. Zusaetzlich wird
+ 'meldung' auf jeden Fall sauber umgebrochen.
+ Ein typisches indent ist "sagt: ".
+
+ Silent:
+ Bei 'silent'==1 erfolgt keine Textausgabe der Antwortmeldung im Raum,
+ ist 'silent' ein String, so wird jener an alle anderen Spieler ausser
+ dem Fragesteller im Raum ausgegeben.
+
+ Casebased:
+ Die als Closure angegebene Methode entscheidet, ob oder wie der NPC
+ auf diese Frage antworten soll:
+ - return 0: normale Antwort mit "meldung"
+ - return 1: keine Antwort/Antwort mit DEFAULT_NOINFO
+ - return string: Antwort mit string unter Beruecksichtigung eines
+ indent
+
+ Die Strings von 'silent' und 'meldung' werden geparsed.
+ Dabei koennen die @...-Tags von replace_personal() verwendet werden,
+ Objekt 1 ist this_player(). Ersetzte String am Satzanfang werden
+ automatisch gross geschrieben.
+ AddInfo() konvertiert die alten Schluesselworte @WER, @WESSEN, @WEM,
+ @WEN zu denen von replace_personal().
+
+ Mittels der in <npc.h> definierten Frage DEFAULT_INFO kann eine
+ Meldung gesetzt werden, die gegeben werden soll, wenn der Spieler
+ etwas fragt, auf das keine Antwort vorgegeben ist (das loest
+ SetProp(P_DEFAULT_INFO, <text>) ab).
+
+BEISPIELE
+---------
+::
+
+ ### eine Standardantwort setzen ###
+ AddInfo(DEFAULT_INFO, "starrt Dir boese in die Augen.\n");
+ // identisch zu
+ SetProp(P_DEFAULT_INFO, "starrt Dir boese in die Augen.\n");
+
+ ### einfache Beispiele, auch mit casebased ###
+ AddInfo(({"knete","kohle"}),
+ "sagt: ich habe so etwas nicht.\n");
+ AddInfo("geld",
+ "Ich habe zwar kein Geld, aber ... blablabla ...",
+ "sagt: " );
+ AddInfo("muenzen",
+ "fluestert: Du willst Geld?\n",
+ 0,
+ "fluestert @WEM etwas zu.\n");
+
+ // "frage monster nach geld": alle im Raum hoeren
+ // Das Monster sagt: Ich habe zwar kein Geld, aber ...
+ // Das Monster sagt: ... blablabla ...
+
+ // "frage monster nach muenzen":
+ // - der Fragensteller hoert:
+ // "Das Monster fluestert: Du willst Geld?"
+ // - alle andere hoeren:
+ // "Das Monster fluestert <Fragenstellernamen> etwas zu."
+
+ ### dynamisch ###
+ // ein Prototyp, damit wir die Methode bekannt machen
+ static string query_kekse();
+ ...
+ AddInfo(({"keks","kekse"}),
+ #'query_kekse, // ein Verweis auf die Funktion
+ "sagt: ");
+ ...
+ static string query_kekse() {
+ if(present("keks"))
+ return("Ich hab noch welche. Aetsch!");
+ return("Menno. Keine mehr da!");
+ }
+
+ // "frage monster nach keks":
+ // - wenn es noch Kekse hat, hoeren alle:
+ // "Das Monster sagt: Ich hab noch welche. Aetsch!
+ // - sonst:
+ // "Das Monster sagt: "Menno. Keine mehr da!
+
+ ### dynamischer ###
+ // ein Prototyp, damit wir die Methode bekannt machen
+ static string query_kekse();
+ static mixed case_fighting();
+ ...
+ AddInfo(({"keks","kekse"}),
+ #'query_kekse," // ein Verweis auf die Funktion
+ sagt: ",
+ 0, // nicht silent :)
+ #'case_fighting); // noch ein Funktionsverweis
+ ...
+ static string query_kekse() {
+ if(present("keks"))
+ return("Ich hab noch welche. Aetsch!");
+ return("Menno. Keine mehr da!");
+ }
+
+ static mixed case_fighting() {
+ if(InFight())
+ return("Keine Zeit fuer Kekse. Muss kaempfen.");
+ return 0;
+ }
+
+ // "frage monster nach keks":
+ // - wenn es kaempft, hoeren alle:
+ // "Das Monster sagt: Keine Zeit fuer Kekse. Muss kaempfen.
+ // - sonst, wenn es noch Kekse hat, hoeren alle:
+ // "Das Monster sagt: Ich hab noch welche. Aetsch!
+ // - sonst:
+ // "Das Monster sagt: "Menno. Keine mehr da!
+
+
+ ### dynamisch und komplex ###
+ // ein Prototyp, damit wir die Methode bekannt machen
+ static string question_gold();
+ ...
+
+ // "gold" wird eine Closure auf die Methode question_gold()
+ // zugewiesen, ausserdem soll es still bleiben (wir informieren
+ // den Restraum selbst)
+ AddInfo("gold",#'question_gold,"murmelt: ",1);
+ ...
+
+ // los gehts, wir generieren unsere Antwort selbst
+ static string question_gold() {
+ int money;
+ string *y, objstr;
+ object o;
+ // wieviel Kohle hat der Spieler
+ money=this_player()->QueryMoney();
+ y=allocate(0);
+ // und jetzt suchen wir die Dinge aus Gold
+ o=first_inventory(this_player());
+ while(o) {
+ if(o->QueryMaterial(MAT_GOLD)>0 &&
+ strstr(object_name(o),"/obj/money"))
+ y+=({o->name(WER,1)});
+ o=next_inventory(o);
+ }
+
+ // das geht an alle anderen im Raum, silent bietet sich hier
+ // nicht an, weil es mehrere Moeglichkeiten gibt
+ say(break_string(
+ Name(WER,1)+" murmelt "+
+ this_player()->name(WEM,1)+
+ " etwas zu"+
+ ((money || sizeof(y))?
+ " und glotzt "+
+ this_player()->QueryPronoun(WEN)+" gierig an.":
+ "."),78),({this_player()}));
+
+ // und hier die Antwort an den Spieler selbst, mit vielen
+ // Verzweigungen fuer dessen Besitztum
+ return("Ich hab kein Gold bei mir."+
+ ((money || sizeof(y))?
+ " Aber du "+
+ (money?"hast ja jede Menge Kohle bei dir, so etwa "+money+
+ " Muenzen."+
+ (sizeof(y)?
+ " Ausserdem "+
+ ((sizeof(y)==1)?"ist":"sind")+
+ " auch noch "+CountUp(y)+" aus Gold.":
+ ""):
+ (sizeof(y)?" Aber was du so bei dir hast: "+
+ CountUp(y)+
+ (sizeof(y)==1?" ist":" sind")+
+ " aus Gold.":"")):
+ ""));
+ }
+
+ // "frage monster nach gold"
+ // - der Fragesteller hoert zB:
+ // Das Monster murmelt: Ich hab kein Gold bei mir. Aber du hast ja
+ // Das Monster murmelt: jede Menge Kohle bei dir, so etwas <number>
+ // Das Monster murmelt: Muenzen. Ausserdem ist/sind noch <object1>
+ // Das Monster murmelt: und <object2> aus Gold."
+ // - die Umstehenden hoeren:
+ // "Das Monster murmelt @WEM etwas zu."
+ // oder
+ // "Das Monster murmelt @WEM etwas zu und glotzt ihn/sie gierig an."
+
+SIEHE AUCH
+----------
+::
+
+ Verwandt: AddSpecialInfo(L), RemoveInfo(L)
+ Props: P_PRE_INFO, P_DEFAULT_INFO
+ Files: /std/npc/info.c
+ Loggen: P_LOG_INFO
+ Interna: GetInfoArr, do_frage
+
+7.Apr 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/AddItem.rst b/doc/sphinx/lfun/AddItem.rst
new file mode 100644
index 0000000..8f15949
--- /dev/null
+++ b/doc/sphinx/lfun/AddItem.rst
@@ -0,0 +1,185 @@
+AddItem()
+=========
+
+FUNKTION
+--------
+::
+
+ varargs object AddItem(mixed filename,int refresh,mixed props);
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/items.c
+ /std/npc/items.c
+
+ARGUMENTE
+---------
+::
+
+ filename
+ String mit dem Namen des zu erzeugenden Objektes oder Array von
+ Strings mit den Namen der zu erzeugenden Objekte. Bei einem Array
+ wird ein Name zufaellig ausgewaehlt.
+ refresh
+ Wann und wie soll das Objekt erneuert werden:
+ - REFRESH_NONE - Kein Refresh bis zum Neuladen des Raums
+ - oder NPCs.
+ - REFRESH_DESTRUCT - Refresh bei Reset, wenn Item zerstoert
+ wurde.
+ - REFRESH_REMOVE - Refresh bei Reset, wenn Item entfernt wurde.
+ - REFRESH_ALWAYS - Neuer Clone bei jedem Reset.
+ - REFRESH_MOVE_HOME - Objekt wird bei Reset automatisch
+ zurueckgeholt, wenn es wegbewegt wurde.
+ (nur in Raeumen!)
+ Bei NPC's gilt zusaetzlich:
+ - CLONE_WEAR - Item Anziehen, wenn es eine Ruestung ist.
+ - CLONE_WIELD - Item zuecken, wenn es eine Waffe ist.
+ - CLONE_NO_CHECK - Zuecken oder Anziehen ohne Ueberpruefungen.
+ props (optional)
+ Mapping mit denen in einem geclonten Objekt zu setzenden
+ Properties oder 1 fuer die Erzeugung einer Blueprint.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Innerhalb von Raeumen wird das erzeugte Objekt zurueckgeliefert. Bei
+ NPC's klappt dies leider nicht, da dort die Objekte nicht sofort
+ erzeugt werden, sondern erst, nachdem der NPC an seinen
+ Bestimmungsort transferiert wurde. Daher wird bei NPC immer 0
+ zurueckgegeben.
+
+BESCHREIBUNG
+------------
+::
+
+ Abhaengig von <filename> und <props> wird ein Objekt erzeugt und in
+ den Raum bzw. NPC bewegt. Dabei gibt es folgende Moeglichkeiten:
+ - <filename> ist ein Dateiname.
+ Es wird ein Clone dieser Datei erstellt oder (wenn <props>=1 ist)
+ deren Blueprint verwendet.
+ - <filename> ist ein Array von Dateinamen.
+ Es wird eine Datei zufaellig aus dem Array ausgewaehlt und von
+ dieser Datei ein Clone erstellt oder (wenn <props>=1 ist) deren
+ Blueprint verwendet.
+ Uebergibt man fuer <props> ein Mapping mit dem Aufbau
+ ([prop_name:prop_wert,...]),
+ so werden diese Properties im erzeugten Objekt gesetzt.
+ Der Parameter <refresh> gibt an, was waehrend eines Resets im Raum
+ bzw. in NPC's oder was beim Erzeugen von NPC's geschehen soll:
+ In <rooms.h> sind dazu folgende Moeglichkeiten definiert:
+ - REFRESH_NONE
+ Das Objekt wird niemals erneuert; falls es zerstoert wurde, wird
+ es erst dann wieder erzeugt, wenn der Raum erneut geladen bzw.
+ der NPC neu erzeugt wird. Man beachte, dass nicht jeder NPC
+ wirklich refreshende Objekte benoetigt, REFRESH_NONE spart
+ hierbei sowohl Rechenzeit als auch Speicher!
+ - REFRESH_DESTRUCT
+ Das Objekt wird nur dann erneuert, wenn es in der Zwischenzeit
+ zerstoert wurde (bei NPC's ist das zum Beispiel der Fall, wenn
+ sie getoetet wurden).
+ REFRESH_NONE & REFRESH_DESTRUCT + Blueprint-Objekt bedeutet bei
+ NPC's ein Unique-Objekt, es wird also nicht beim Neuerzeugen des
+ NPC's zurueckgesetzt.
+ - REFRESH_REMOVE
+ Das Objekt wird erneuert, wenn es sich nicht mehr im Raum bzw.
+ im NPC befindet. Das kein sein, weil es zerstoert wurde, aber
+ auch zum Beispiel in folgenden Faellen:
+ * weil es jemand mitgenommen hat
+ (in Raeumen bei Gegenstaenden)
+ * weil es fortgegangen ist
+ (in Raeumen bei NPC's, die herumlaufen)
+ * weil es weggeworfen wurde
+ (in NPC's bei Gegenstaenden)
+ - REFRESH_ALWAYS
+ Das Objekt wird immer erneuert. Von dieser Refreshmethode sollte
+ man allerdings Abstand nehmen, da sich sonst mit der Zeit
+ gewaltige Mengen von Objekten ansammeln koennen!
+ - REFRESH_MOVE_HOME
+ Das Objekt wird in einen Raum zurueckbewegt, sofern es noch
+ existiert, jedoch nicht mehr in dem Raum ist. Sinnvoll ist dies
+ eigentlich nur fuer Lebewesen, funktioniert aber auch bei
+ beliebigen Objekten. Hauptsaechlich geht es hierbei darum,
+ herumlaufende NPCs oder bei erzwungenen Bewegungen nicht von
+ P_GUARD zurueckgehaltene NPCs wieder an einen definierten
+ Ausgangsort zurueckzubringen.
+ Hat man in Raeumen als <filename> ein Array von Dateinamen
+ uebergeben, so wird beim Reset jedesmal aufs Neue ein zufaelliges
+ Objekt aus der Liste ausgewaehlt (nicht in NPC's).
+ In NPC's gilt der Grundsatz der Vermeidung von ueberfluessigen
+ Objekten im MUD. Neu erzeugt werden Objekte beim Erzeugen eines
+ NPC's oder bei einem Reset im selbigen. Anstatt die Objekte gleich
+ neu zu erschaffen, wird erst geschaut, ob sich identische Objekte
+ schon im Raum befinden. Ist dies der Fall, so nimmt der NPC sie auf,
+ ruft jedoch vorher nochmals create() in ihnen auf!
+ (noetig wegen moeglicher Veraenderungen an den Objekten)
+ Was dann passiert, haengt von weiteren Angaben in <refresh> ab.
+ Folgende weitere Moeglichkeiten sind in <npc.h> definiert:
+ - CLONE_WEAR
+ Ist das hinzugefuegte Item eine Ruestung, so wird sie nach
+ Aufnahme oder Neuerzeugung angezogen.
+ - CLONE_WIELD
+ Ist das hinzugefuegte Item eine Waffe, so wird sie nach Aufnahme
+ oder Neuerzeugung gezueckt.
+ - CLONE_NO_CHECK
+ Hiermit verhindert man eine Ueberpruefung, ob eine Ruestung
+ angezogen oder eine Waffe gezueckt werden kann. Es ist jedoch
+ Vorsicht geboten: So kann es ohne weiteres passieren, dass ein NPC
+ mehrere Ruestungen gleichen Typs angezogen oder mehrere Waffen
+ gezueckt hat.
+ Benutzt man Blueprints (<props>=1) mit REFRESH_REMOVE oder
+ REFRESH_ALWAYS, so kann es zu ungewollten Ueberraschungen kommen, da
+ die Blueprint dann unabhaengig von ihrem momentanen Aufenthaltsort
+ wieder in den Raum bzw. NPC bewegt wird, von dem sie erzeugt wurde!
+
+BEMERKUNGEN
+-----------
+::
+
+ Wenn man Blueprints benutzt, sollte man daran denken, dass sich von
+ dieser dann keine Clones mehr erstellen lassen!
+ RemoveItem() zum Entfernen von Items ist nur fuer Raeume definiert!
+
+ Die Option CLONE_NEW ist veraltet. Die Objekte werden nun immer
+ neu erzeugt. Die Option darf noch angegeben werden, hat aber keine
+ Bedeutung mehr.
+
+BEISPIELE
+---------
+::
+
+ // Ein Wuerfel, der sich nach Entfernen erneuert:
+ AddItem("/obj/misc/wuerfel",REFRESH_REMOVE);
+ // Ein etwas veraenderter Wuerfel:
+ AddItem("/obj/misc/wuerfel",
+ REFRESH_REMOVE,
+ ([P_SHORT :"Ein schwerer Wuerfel",
+ P_WEIGHT:100]));
+ // Eine Blueprint, die nur einmal im MUD existiert. Wenn sie
+ // zerstoert wurde, wird sie bei Reset neu erzeugt:
+ AddItem("/mon/angsthase",REFRESH_DESTRUCT,1);
+ // Eine Blueprint, die nur einmal im MUD existiert. Wenn sie aus dem
+ // Raum entfernt wurde, wird sie bei Reset zurueckgeholt:
+ AddItem("/mon/angsthase",REFRESH_MOVE_HOME,1);
+ // Ein zufaelliges Objekt:
+ AddItem(({"/obj/misc/lolli",
+ "/obj/misc/bonbon",
+ "/obj/misc/bier"}),REFRESH_REMOVE);
+ // Eine Ruestung, die auch angezogen wird (nur in NPC's):
+ AddItem("/ruestung/sommerkleid",REFRESH_REMOVE|CLONE_WEAR);
+ // Eine Unique-Waffe, die auch gezueckt wird (nur in NPC's):
+ AddItem("/waffe/zapper",REFRESH_DESTRUCT|CLONE_WIELD,1);
+
+SIEHE AUCH
+----------
+::
+
+ RemoveItem(), replace_program(), create(), P_GUARD,
+ /std/room/items.c, /std/npc/items.c,
+ /sys/rooms.h, /sys/npc.h
+
+
+Last modified: Thu Nov 23 13:43:30 CET 2006 by Rumata
+
diff --git a/doc/sphinx/lfun/AddKnownPotion.rst b/doc/sphinx/lfun/AddKnownPotion.rst
new file mode 100644
index 0000000..50479bb
--- /dev/null
+++ b/doc/sphinx/lfun/AddKnownPotion.rst
@@ -0,0 +1,45 @@
+AddKnownPotion()
+================
+
+FUNKTION
+--------
+::
+
+ int AddKnownPotion(int nr)
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/potion.c
+
+ARGUMENTE
+---------
+::
+
+ int nr Nummer eines ZTs
+
+BESCHREIBUNG
+------------
+::
+
+ Addiert einen ZT als bekannt in einem Spieler. Nur vom Orakel rufbar.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 Erfolg
+ -1 fehlende Berechtigung
+ -2 Nummer bereits eingetragen
+
+SIEHE AUCH
+----------
+::
+
+ Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
+ Verwandt: FindPotion(), RemoveKnownPotion(), InList()
+ Props: P_POTIONROOMS, P_KNOWN_POTIONROOMS
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/lfun/AddMaterial.rst b/doc/sphinx/lfun/AddMaterial.rst
new file mode 100644
index 0000000..211c51d
--- /dev/null
+++ b/doc/sphinx/lfun/AddMaterial.rst
@@ -0,0 +1,100 @@
+AddMaterial()
+=============
+
+FUNKTION
+--------
+::
+
+ private static varargs void AddMaterial(string mat, int gender,
+ mixed names, mixed groups,
+ mixed dif) {
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/materialdb.c (MATERIALDB)
+
+ARGUMENTE
+---------
+::
+
+ string mat
+ Materialstring, definiert in <thing/material.h>
+
+ int gender
+ Geschlecht des einzutragenden Materials
+
+ mixed names
+ Name des Materials:
+ - "<Nominativ>" oder (meist nur Nom. und Gen. noetig)
+ - ({"<Nominativ>","<Genitiv>","<Dativ>","<Akkusativ>"})
+
+ mixed groups
+ Eingruppierung des Materials:
+ - MATGROUP_XXX oder ({MATGROUP_XXX,...})
+ - ([MAT_GROUP_XXX:xx,MATGROUP_YYY:yy,...])
+
+ mixed dif
+ Schwierigkeiten bei der Erkennbarkeit:
+ - int x oder ({MINMAT,x1,MATPOS1,x2,MATPOS2 ...})
+ - xn: Erkennbarkeitsschwierigkeit (100=100%) -100..100
+ - MINMAT: Erkennung zumindest als _dieses_ Material
+ moeglich
+ - MATPOSn: moegliches Material, erkennbar, wenn
+ Erkennbarkeitfaehigkeit>=xn
+ -> das letzte MATPOS muss natuerlich
+ string mat entsprechen
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird in die Materialiendatenbank eine neues Material aufgenommen,
+ die Stringkonstante dafuer wird vorher in <thing/material.h> fest-
+ gelegt. Falls der Genitiv nicht Nominativ+"s" entspricht (z.B. "Seide"),
+ sollte dieser explizit angegeben werden.
+ Nach Neuladen der Datenbank ist dieses Material auch per MaterialName(),
+ 'erkennbar' (siehe mixed dif, siehe Beispiel) bzw. seinen einzelnen
+ Gruppen zuordnbar.
+
+BEISPIELE
+---------
+::
+
+ AddMaterial(MAT_NITROGLYCERINE,NEUTER,"Nitroglycerin",
+ ({MATGROUP_EXPLOSIVE,MATGROUP_FLUID}),
+ ({MAT_OIL,25,MAT_MISC_EXPLOSIVE,50,MAT_NITROGLYCERINE}));
+
+ Damit wird das Material Nytroglycerin aufgenommen, ein explosiver
+ (damit entflammbarer) sowie fluessiger Stoff. Liegt die Erkennungs-
+ faehigkeit (MaterialName()) unter 25, wird es nur als Oel erkannt,
+ liegt sie unter 50, wird es zumindest als explosives Material erkannt,
+ liegt sie ueber 49, so wird es korrekt erkannt (wie schade :) ).
+
+BEMERKUNGEN
+-----------
+::
+
+ Wird in der create() der Datenbank aufgerufen. Zu beachten:
+ - vor Eintrag eines _neuen_ Materials die Datenbank durchsuchen!
+ - bei den Materialiengruppen die automatischen Abhaengigkeiten in
+ AddMaterial() durchsehen!
+ - bitte Datenbank neu laden
+
+SIEHE AUCH
+----------
+::
+
+ Konzepte: material, materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Methoden: QueryMaterial(), QueryMaterialGroup(), MaterialList(),
+ Listen: AllMaterials(), AllGroups(), Dump()
+ materialliste, materialgruppen
+ Master: ConvMaterialList(), MaterialGroup(),
+ GroupName(), MaterialName(),
+ GetGroupMembers(), GetMatMembership()
+ Sonstiges: P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/AddMiniQuest.rst b/doc/sphinx/lfun/AddMiniQuest.rst
new file mode 100644
index 0000000..7e4e851
--- /dev/null
+++ b/doc/sphinx/lfun/AddMiniQuest.rst
@@ -0,0 +1,71 @@
+AddMiniQuest()
+==============
+
+FUNKTION
+--------
+::
+
+ int AddMiniQuest(int stupse, string questgeber, string desc, int active,
+ string titel, string erledigt, mapping voraussetzungen,
+ string region, string *erlaubte)
+
+DEFINIERT IN
+------------
+::
+
+ /secure/questmaster
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion traegt eine neue Miniquest im Questmaster ein.
+
+ARGUMENTE
+---------
+::
+
+ stupse (>0) - Anzahl Stufenpunkte, die fuer die MQ gutgeschrieben werden
+ questgeber - Ladename des Objekts, das GiveMiniQuest() aufruft
+ desc - Aufgabenbeschreibung der Miniquest
+ active (0/1) - ist die Miniquest aktiv, d.h. spielbar, oder nicht?
+ titel - Titel der Miniquest, darf weder "in", noch "im" enthalten,
+ weil dann der Eintrag in der Fraternitas-Bibliothek nicht
+ gelesen werden kann.
+ erledigt - Beschreibung der Miniquest, nachdem man sie erledigt hat
+ Der Text kann in der Bibliothek der kleinen und grossen
+ Heldentaten in der Fraternitas eingesehen werden.
+ voraussetzungen - Mapping im Format von P_RESTRICTIONS (s. dort), um
+ die Voraussetzungen festzulegen, die ein Spieler
+ erfuellen muss, um die MQ ueberhaupt spielen zu koennen
+ Wird fuer die regionsbezogenen Informationspunkte/-NPCs
+ ausgewertet. 0 oder ([]) eintragen, wenn keine
+ Voraussetzungen bestehen.
+ region - Zuordnung der Miniquest zu einer Region; wird fuer der
+ Bibliothek der Fraternitas verwendet, um die MQs der
+ einzelnen Regionen herauszufiltern.
+ erlaubte - Array mit Ladenamen von Objekten, die berechtigt sind,
+ die Daten der MQ abzufragen, um Spielern einen Hinweis
+ darauf zu geben, die sie noch nicht bestanden haben.
+
+RUECKGABEWERTE
+--------------
+::
+
+ 1: Hat geklappt
+ -1: Parameterformat stimmt nicht (questgeber kein String oder Leerstring,
+ voraussetzungen kein Mapping, region oder titel keine Strings,
+ erlaubte kein Array)
+ -2: weniger als 1 Stufenpunkt einzutragen versucht
+ -3: Das Array in "erlaubte" ist leer, oder zum angegebenen Questgeber
+ wurde keine Datei gefunden.
+ -4: Der angegebene Questgeber vergibt schon eine andere Miniquest
+
+SIEHE AUCH
+----------
+::
+
+ GiveMiniQuest(L), HasMiniQuest(L)
+ P_RESTRICTIONS
+ /secure/questmaster.c
+
diff --git a/doc/sphinx/lfun/AddMoney.rst b/doc/sphinx/lfun/AddMoney.rst
new file mode 100644
index 0000000..e2d4139
--- /dev/null
+++ b/doc/sphinx/lfun/AddMoney.rst
@@ -0,0 +1,92 @@
+AddMoney()
+==========
+
+AddMoney(L)
+-----------
+::
+
+FUNKTION
+--------
+::
+
+ public int AddMoney(int amount);
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/moneyhandler.c
+ /std/living/moneyhandler.c
+ /std/player/moneyhandler.c
+
+ARGUMENTE
+---------
+::
+
+ int amount
+ Die zufuehrende oder abziehende Geldmenge
+
+BESCHREIBUNG
+------------
+::
+
+ Dem Spieler wird die in <amount> festgelegte Geldmenge abgezogen oder
+ zugefuehrt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Technisch gesehen wird Geld mit entsprechendem <amount> erzeugt
+ ("/items/money.c") und mittels "move" in den Spieler bewegt. Das Ergebnis
+ dieses "move"-Aufrufes wird hier uebergeben, z.B. 1 fuer OK.
+ Die moeglichen Fehler-Konstanten sind in /sys/moving.h definiert, siehe
+ auch Dokumentation zu "move".
+
+BEMERKUNGEN
+-----------
+::
+
+ <amount> kann sowohl positiv als auch negativ sein. Welche Auswirkungen
+ beide Faelle haben, sollte klar sein. Doch sollte bei einem negativen
+ <amount> vorher mittels QueryMoney() abgefragt werden, ob der Spieler
+ auch ueber ausreichend Geld verfuegt.
+ Wird dem Spieler Geld abgezogen, ist darauf zu achten, dieses in der
+ Zentralbank einzuzahlen (s.a.:PayIn() ).
+ Verschafft man dem Spieler Geld aus dem Nichts, muss es vorher bei der
+ Zentralbank abgebucht (WithDraw()) werden.
+
+ Achtung: Kann der Spieler die in <amount> angebene Geldmenge nicht
+ tragen, werden ihm keine Muenzen in sein Inventar bewegt. Die
+ Fehlermeldung erkennt man an dem Rueckgabewert ME_TOO_HEAVY.
+
+ Im Gegensatz zu Spielern haben alle anderen Objekte (Raeume, NPC, etc.)
+ standardmaessig keinen Moneyhandler. In diesem Fall muss in Lebewesen
+ "/std/living/moneyhandler"
+ und in nicht-Lebewesen
+ "/std/container/moneyhandler"
+ geerbt werden.
+
+BEISPIELE
+---------
+::
+
+ // gib ihm Geld
+ this_player()->AddMoney(50);
+
+ // nimm ihm Geld
+ if(this_player()->AddMoney(-50)==1)
+ write("Der Ork beklaut dich!\n");
+
+SIEHE AUCH
+----------
+::
+
+ Geldhandling: QueryMoney(L)
+ Zentralbank: PayIn(L), WithDraw(L)
+ Sonstiges: move(L),
+ /items/money.c, /sys/moving.h, /sys/money.h, /sys/bank.h
+ /std/container/moneyhandler.c
+
+18.02.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/AddMsg.rst b/doc/sphinx/lfun/AddMsg.rst
new file mode 100644
index 0000000..7b2393f
--- /dev/null
+++ b/doc/sphinx/lfun/AddMsg.rst
@@ -0,0 +1,63 @@
+AddMsg()
+========
+
+FUNKTION
+--------
+::
+
+ void AddMsg(string msg, int next);
+
+DEFINIERT IN
+------------
+::
+
+ /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+ msg
+ Die auszugebende Meldung.
+ next
+ Zeit bis zur naechsten Fahrplanstation.
+
+BESCHREIBUNG
+------------
+::
+
+ Dem Fahrplan wird die Ausgabe einer Meldung an den Transporter
+ hinzugefuegt. Diese Meldung koennte zum Beispiel das Nahen der
+ naechsten Haltestelle ankuendigen o.ae. Nach Ausgabe der Meldung
+ vergehen next Sekunden, bis die naechste Station angefahren wird.
+
+ Um das Umbrechen der Meldung (normalerweise auf 78 Zeichen pro Zeile)
+ muss sich der Aufrufer selber kuemmern.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEISPIELE
+---------
+::
+
+ AddMsg("In der Ferne taucht eine kleine Inseln auf.\n", 10);
+ AddMsg("Das Schiff steuert einen kleinen Steg an.\n");
+ AddRoute(...);
+
+ Nach der Ankuendigung der Insel vergehen 10 Sekunden, bis die naechste
+ Meldung ausgegeben wird. Da bei der zweiten Meldung keine Zeit
+ angegeben war, legt das Schiff direkt nach der Ausgabe der Meldung an.
+
+SIEHE AUCH
+----------
+::
+
+ AddRoute(), AddFun(), /std/transport.c
+
+
+25.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddPlant.rst b/doc/sphinx/lfun/AddPlant.rst
new file mode 100644
index 0000000..6b4cb4c
--- /dev/null
+++ b/doc/sphinx/lfun/AddPlant.rst
@@ -0,0 +1,85 @@
+AddPlant()
+==========
+
+FUNKTION
+--------
+::
+
+ varargs int AddPlant(string filename, [string|string* npcId])
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/kraeuter.c
+
+ARGUMENTE
+---------
+::
+
+ filename
+ Der Filename des Krauts das hier gefunden werden soll.
+ npcId
+ Die ID eines NPCs oder die IDs einer Liste von NPCs, der/die das
+ Kraut bewachen soll/en. Befindet sich ein NPC mit einer dieser IDs
+ im Raum, kann das Kraut nicht gepflueckt werden. Dieses Argument
+ ist optional!
+
+RUeCKGABEWERT
+-------------
+::
+
+ -1 wenn das Objekt nicht geclont werden konnte
+ >=0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+ Mit Hilfe dieser Funktion koennen Kraeuter fuer den mudweiten
+ Kraeuterskill recht einfach eingebaut werden. Alles was man
+ noch machen muss, ist den Namen der Pflanze in einem Detail oder
+ der Langbeschreibung zu erwaehnen.
+ Mit dem Befehl "showplant" in /obj/tools/planttool kann man sich
+ bequem anzeigen lassen, was es alles an Kraeutern gibt, die man
+ nehmen kann.
+
+BEMERKUNGEN
+-----------
+::
+
+ Damit die Kraeuter von den Spielern zum Brauen von Traenken benutzt
+ werden koennen, muss der Raum erst in einem Master eingetragen werden.
+ Derzeit schickt ihr dazu am besten eine kurze Mail an einen Erzmagier,
+ gerne nimmt Humni die derzeit entgegen.
+ Die Kraeuter wurden von der Balance bereits alle im vorhinein
+ abgenommen. Lediglich die Einhaltung der Kategorien ist zu beachten.
+ Sind Kraeuter nicht im Master konfiguriert (wie z.B. im Homemud), sind
+ alle erzeugten Kraeuter nur "Testkraeuter" mit nur der ID "kraut".
+
+BEISPIELE
+---------
+::
+
+ #include <items/kraeuter/kraeuterliste.h>
+ inherit "/std/room/kraeuter";
+ inherit "/std/room";
+
+
+
+ void create()
+ {
+ ::create();
+ SetProp(P_INT_LONG, "Du siehst eine Wiese voller Feldklee.\n");
+ AddPlant(FELDKLEE);
+ }
+
+SIEHE AUCH
+----------
+::
+
+ AddItem();
+
+
+18.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddPluralId.rst b/doc/sphinx/lfun/AddPluralId.rst
new file mode 100644
index 0000000..36bfc9d
--- /dev/null
+++ b/doc/sphinx/lfun/AddPluralId.rst
@@ -0,0 +1,50 @@
+AddPluralId()
+=============
+
+FUNKTION
+--------
+::
+
+ void AddPluralId(mixed id);
+
+DEFINIERT IN
+------------
+::
+
+ /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+ id
+ Identfikationsstring oder Array von Strings
+
+BESCHREIBUNG
+------------
+::
+
+ Es werden ein oder mehrere Bezeichner hinzugefuegt, mit denen sich
+ mehrere Einheiten der Menge ansprechen lassen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEISPIELE
+---------
+::
+
+ siehe /items/money.c
+
+SIEHE AUCH
+----------
+::
+
+ AddSingularId(), RemovePluralId(), AddId(), id(), /std/unit.c
+
+
+Last modified: Mon Jul 14 11:30:00 1997 by Silvana
+
diff --git a/doc/sphinx/lfun/AddPursuer.rst b/doc/sphinx/lfun/AddPursuer.rst
new file mode 100644
index 0000000..e54f1a9
--- /dev/null
+++ b/doc/sphinx/lfun/AddPursuer.rst
@@ -0,0 +1,52 @@
+AddPursuer()
+============
+
+FUNKTION
+--------
+::
+
+ void AddPursuer(object pursuer)
+
+ARGUMENTE
+---------
+::
+
+ pursuer: Objekt, das demjenigen folgen soll, in dem AddPursuer
+ aufgerufen wurde.
+
+FUNKTION
+--------
+::
+
+ Durch den Aufruf von AddPursuer in einem Objekt, welches living() ist,
+ wird das Object, welches als Argument uebergeben wurde in die Liste
+ der Verfolger eingetragen. Alle Objekte, die in der Verfolgerliste stehen
+ werden bei Bewegungen des Verfolgten in dasselbe Environment bewegt.
+
+RUECKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNG
+---------
+::
+
+ Im Verfolger wird PreventFollow mit dem Zielobjekt, in das der Verfolgte
+ bewegt wird, aufgerufen. Dadurch kann der raeumliche Bereich, in dem
+ verfolgt wird, eingeschraenkt werden.
+
+BEISPIELE
+---------
+::
+
+ find_player("jof")->AddPursuer(find_player("kirk"))
+ Danach wird Jof von Kirk verfolgt.
+
+SIEHE AUCH
+----------
+::
+
+ "RemovePursuer", "PreventFollow"
+
diff --git a/doc/sphinx/lfun/AddReadDetail.rst b/doc/sphinx/lfun/AddReadDetail.rst
new file mode 100644
index 0000000..af20c6e
--- /dev/null
+++ b/doc/sphinx/lfun/AddReadDetail.rst
@@ -0,0 +1,102 @@
+AddReadDetail()
+===============
+
+FUNKTION
+--------
+::
+
+ void AddReadDetail(string|string*keys,
+ string|string*|mapping|closure desc);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ keys
+ String oder Array von Strings mit den Namen der Details.
+ desc
+ String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+
+BESCHREIBUNG
+------------
+::
+
+ Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
+ beim Lesen ausgegeben werden, haengt im wesentlichen vom Typ der
+ Beschreibung <desc> ab:
+ <desc> ist ein String.
+ Beim Lesen wird dieser String zurueckgegeben.
+ <desc> ist ein String-Array.
+ Beim Lesen wird zufaellig einer der Strings zurueckgegeben.
+ <desc> ist ein Mapping.
+ Das Mapping muss folgenden Aufbau haben:
+ ([0: "Defaulttext",
+ "rasse1": "r1text", ...]).
+
+ Falls fuer die Rasse des das Detail untersuchenden Spielers ein
+ Eintrag im Mapping existiert, wird der entsprechende Text
+ zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
+ rassenabhaengige Texte moeglich.
+ <desc> ist eine Closure.
+ In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
+ zurueckgegeben. Die Closure bekommt dabei den Namen des Details
+ als Parameter uebergeben.
+
+ Fuer lesbare Details koennen Forscherpunkte eingetragen werden.
+
+ Will man ein lesbares Detail an einem Objekt haben, welches der Spieler
+ mit "lies <id>" (<id> ist eine ID des Objekts) bekommt, muss man ein
+ Detail SENSE_DEFAULT hinzufuegen.
+ (Ein Detail "<id>" hinzuzufuegen, hat einen ganz anderes Effekt! Dieses
+ wuerde vom Spieler mit "lies <id> an <id>" gelesen werden und ist
+ meistens nicht das, was gewuenscht wird.)
+
+BEMERKUNGEN
+-----------
+::
+
+ (1) Auf die 'desc' wird kein process_string() mehr angewendet.
+ Bitte stattdessen lfun closures bzw. 'inline closures'
+ verwenden.
+
+ (2) Im Gegensatz zum Verhalten von AddTouchDetail(), AddSmells() und
+ AddSounds() wirkt ein SENSE_DEFAULT-Detail in einem Raum nicht.
+ Ein einfaches "lies" bleibt dann ohne Rueckgabewert.
+
+BEISPIELE
+---------
+::
+
+ AddReadDetail( ({ "schild" }),
+ "BETRETEN STRENGSTENS VERBOTEN!\n" );
+
+ AddReadDetail("inschrift",
+ ([0: "Dort steht: Ein Ring sie zu binden. ....\n",
+ "elf": "Alles in dir straeubt sich, DAS DA zu lesen.\n"]));
+
+ AddReadDetail("regeln",
+ function string() {
+ this_player()->More("/etc/WIZRULES", 1);
+ return "";
+ });
+
+SIEHE AUCH
+----------
+::
+
+ Setzen: AddDetail(), AddSmells(), AddSounds(),
+ AddTouchDetail()
+ Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+ RemoveSounds(), RemoveTouchDetail()
+ Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+ Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+ Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddResistanceModifier.rst b/doc/sphinx/lfun/AddResistanceModifier.rst
new file mode 100644
index 0000000..dfc205b
--- /dev/null
+++ b/doc/sphinx/lfun/AddResistanceModifier.rst
@@ -0,0 +1,75 @@
+AddResistanceModifier()
+=======================
+
+FUNKTION
+--------
+::
+
+ varargs int AddResistanceModifier(mapping mod, string add)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ mapping mod:
+ Mapping mit Schadensarten und ihrem Resistenzmodifikator (der im Bereich
+ von -1.0 bis +x liegen kann), z.B. ([DT_FIRE:-1.0]) (Totalresistenz).
+ string add:
+ Ein Identifikator fuer _diesen_ Eintrag des setzenden Objektes.
+
+BESCHREIBUNG
+------------
+::
+
+ Es werden Resistenzen in dem Objekt gesetzt, die solange bestehen, wie
+ das setzende Objekt existiert, oder nicht RemoveResistanceModifier
+ (mit eventuellem Schluessel add) aufgerufen wird. Zusaetzliche Resistenzen
+ werden eingerechnet.
+
+BEMERKUNGEN
+-----------
+::
+
+ Fuer Ruestungen kann und sollte man P_RESISTANCE_STRENGTHS verwenden.
+
+BEISPIELE
+---------
+::
+
+ // Oel mit vervierfachtem Feuerschaden
+ int add_action() {
+ ...
+ write(break_string("Du schuettest das Oel ueber "+
+ npc->name(WEN)+".",78));
+ ...
+ npc->AddResistanceModifier(([DT_FIRE:3.0]), "oel");
+ SetProp(P_INVIS,1);
+ SetProp(P_EXTRA_LOOK, "Ueberall tropft Oel herunter.\n");
+ move(npc,M_NOCHECK);
+ ...
+ }
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 fuer Erfolg
+
+SIEHE AUCH
+----------
+::
+
+ Modifikatoren: RemoveResistanceModifier(), P_RESISTANCE_MODIFIER
+ simple Resistenz: P_RESISTANCE, P_VULNERABILITY
+ Hauptmapping: P_RESISTANCE_STRENGTHS
+ Berechnung: CheckResistance(), UpdateResistanceStrengths()
+ anderes: balance, /std/armour/combat.c, /std/living/combat.c
+
+29.Apr 2002, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/AddRoomCmd.rst b/doc/sphinx/lfun/AddRoomCmd.rst
new file mode 100644
index 0000000..c7b5de3
--- /dev/null
+++ b/doc/sphinx/lfun/AddRoomCmd.rst
@@ -0,0 +1,25 @@
+AddRoomCmd()
+============
+
+SYNTAX
+------
+::
+
+ AddRoomCmd( string kommando, string funktion );
+ AddRoomCmd( string *kommandos, string funktion );
+
+FUNKTION
+--------
+::
+
+
+
+ Diese Funktion ist veraltet. Sie wird vollstaendig durch
+ die Funktion AddCmd ersetzt.
+
+SIEHE AUCH
+----------
+::
+
+ "AddCmd"
+
diff --git a/doc/sphinx/lfun/AddRoomMessage.rst b/doc/sphinx/lfun/AddRoomMessage.rst
new file mode 100644
index 0000000..150a9cd
--- /dev/null
+++ b/doc/sphinx/lfun/AddRoomMessage.rst
@@ -0,0 +1,103 @@
+AddRoomMessage()
+================
+
+FUNKTION
+--------
+::
+
+ void AddRoomMessage(string *msg, int time, mixed *func);
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/description.c
+
+ARGUMENTE
+---------
+::
+
+ msg
+ Array von Strings mit den Meldungen.
+ time
+ Der Abstand zwischen zwei Meldungen in Sekunden.
+ func (optional)
+ String oder Array von Strings mit Funktionsnamen
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion legt man fest, dass in bestimmten Zeitabstaenden
+ Meldungen an den Raum geschickt werden sollen.
+
+ Es wird alle time Sekunden zufaellig eine der in msg angegebenen
+ Meldungen ausgegeben. Hat man auch noch func angegeben, so wird
+ zusaetzlich diese Funktion (bei einem Array: eine zufaellig ausgesuchte
+ Funktion) im Raum aufgerufen. Als Parameter bekommt die Funktion die
+ Nummer der ausgegebenen Meldung.
+
+ Bevor man allerdings jeden Raum mit AddRoomMessage() pflastert, sollte
+ man folgendes bedenken:
+ o Viele Meldungen in vielen Raeumen tendieren dazu, den Spielern auf
+ die Nerven zu gehen!
+ o Da das Timing ueber einen call_out() gesteuert wird, ist das Ganze
+ aus Sicht des GameDrivers auch noch relativ teuer!
+ Fazit: weniger ist mehr!
+
+BEMERKUNGEN
+-----------
+::
+
+ * Falls time < 15 Sekunden ist, wird auf 15 Sekunden aufgerundet.
+ * der Praefix Add... taeuscht hier. Ein Aufruf von AddRoomMessage()
+ ueberschreibt alle vorherigen Werte
+ * THIS_PLAYER() NICHT VERWENDEN!
+ In Funktionen, die durch AddRoomMessage() ausgeloest werden, darf
+ this_player() nicht verwendet werden. AddRoomMessage ist call_out-
+ gesteuert und speichert somit das this_player(). Damit ist this_player()
+ immer der Spieler, der den Raum geladen, also den Raum als erster
+ betreten hat.
+ Spieler also bitte selbst ueber filter(all_inventory(this_object()),
+ #'interactive) suchen.
+
+BEISPIELE
+---------
+::
+
+ Es soll alle halbe Minute eine Meldung ausgegeben werden. Falls es
+ unter den Fuessen knackt, soll man zudem mit 30%-iger
+ Wahrscheinlichkeit zusammenzucken:
+
+ inherit "/std/room";
+
+ void create() {
+ ::create();
+ AddRoomMessage( ({ "In der Ferne schreit ein Kaeuzchen.\n",
+ "Es raschelt im Gebuesch.\n",
+ "Etwas knackt unter Deinen Fuessen.\n" }),
+ 30, ({"sound", "sound_more_rnd"}) );
+ ...
+ }
+
+ void sound(int msg) {
+ if (msg == 2) // Es hat geknackt...
+ if (random(10) < 3) // Schreck lass nach! ;-)
+ tell_room(this_object(), "Erschrocken faehrst Du zusammen!\n" );
+ }
+
+ // Extra-Beispiel: wir setzen die Wartedauer (Parameter tim) neu
+ void sound_more_rnd() {
+ sound(0); // die Message-Nummer ist hier unwichtig
+ SetProp(P_MSG_PROB, 25+random(20)); // neue Wartedauer
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Verwandt: tell_room(), ReceiveMsg()
+ Props: P_ROOM_MSG, P_FUNC_MSG, P_MSG_PROB
+
+2.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/lfun/AddRoute.rst b/doc/sphinx/lfun/AddRoute.rst
new file mode 100644
index 0000000..69b7c3a
--- /dev/null
+++ b/doc/sphinx/lfun/AddRoute.rst
@@ -0,0 +1,116 @@
+AddRoute()
+==========
+
+FUNKTION
+--------
+::
+
+ public varargs void AddRoute(string room, int stay, int next,
+ string harbour_desc, mixed dest_ids, string deststr)
+
+DEFINIERT IN
+------------
+::
+
+ /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+ string room
+ Filename der Haltestelle (des Ziels)
+ int stay
+ Aufenthaltszeit an der Haltestelle.
+ int next
+ Fahrtzeit von dort bis zum naechsten Fahrplanpunkt
+ string harbour_desc
+ Name der Haltestelle (fuer QueryArrived)
+ mixed dest_ids
+ kleingeschriebene IDs der Haltestelle
+ string destrstr
+ Unbenutzt / Undefiniert.
+
+BESCHREIBUNG
+------------
+::
+
+ Dem Fahrplan des Transporters wird eine neue Haltestelle hinzugefuegt.
+
+ Bei Erreichen der Haltestelle wird der Transporter in den Raum 'room'
+ bewegt und sichtbar gemacht. Nun kann man ihn fuer 'stay' Sekunden
+ betreten oder verlassen, bevor er ablegt (unsichtbar gemacht wird).
+ Nach 'next' Sekunden wird dann der naechste Punkt des Fahrplans
+ ausgefuehrt.
+
+
+
+ 'harbour_desc' ist ein String, den QueryArrived() zurueckgibt, wenn sich
+ der Transporter an einer Haltestelle befindet. In der Regel ist das ein
+ String, der die Haltestelle naeher beschreibt.
+
+
+
+ 'dest_ids' ist ein Array von Strings, die als ID-Code fuer diese
+ Haltstelle dienen. Das wird zB bei der Ermittlung einer Haltestelle bei
+ "reise nach" benutzt. Wenn 'dest_ids' nicht gesetzt ist, und auch
+ P_HARBOUR des Zielhafens nicht korrekt gesetzt ist, werden
+ grossgeschriebene Begriffe aus 'harbour_desc' verwendet.
+
+BEISPIELE
+---------
+::
+
+ #1 Hier ein Auszug aus /d/inseln/schiffe/jolle.c:
+
+ AddRoute("/d/ebene/room/PortVain/po_haf2", 40,
+ 10, "Hafen von Port Vain");
+
+ Die Jolle wird also beim Anlegen in den Port Vainer Hafen bewegt und
+ laesst sich dort 40 Sekunden lang betreten oder verlassen.
+ QueryArrived() liefert waehrend dieser Zeit den String "Hafen von Port
+ Vain" zurueck. Nach den 40 Sekunden legt die Jolle ab, und nach
+ weiteren 10 Sekunden wird die naechste Station in ihrem Fahrplan
+ angefahren.
+
+ #2 Die Galeere nach Orkhausen:
+ AddRoute(INSEL("steg"), 30, 20, "Verlorene Land ( Orkhausen )" );
+ - haelt 30 Sekunden
+ - reist 20 Sekunden
+ - reist nach INSEL("steg"), bekannt als "Verlorene Land ( Orkhausen )"
+ - da keine 'dest_ids' angegeben sind, waere eine so definierte
+ Haltstelle nur mit den IDs ansprechbar, die in P_HARBOURS im Zielraum
+ angegeben sind.
+
+ Wenn man nun erreichen wollte, dass das Ziel auch mit dem Kuerzel "vland"
+ ansprechbar ist, kann man zum einen explizite 'dest_ids' eintragen:
+ AddRoute(INSEL("steg"), 30, 20, "Verlorene Land ( Orkhausen )",
+ ({"verlorenes", "land", "orkhausen", "vland"}));
+ Dies laesst sich im Zielhafen aber auch durch Eintragen des Kuerzels
+ "vland" in P_HARBOUR erreichen. Dies hat den Vorteil, dass dieser Hafen
+ dann von allen Transportern, die dort anlegen, unter demselben Namen
+ erreicht werden kann.
+
+
+
+HINWEISE
+--------
+::
+
+ Dadurch, dass die Eintraege aus P_HARBOUR und 'dest_ids' gleichberechtigt
+ fuer "reise nach <ziel>" verwendet werden koennen, ist es moeglich,
+ dass die Reiseziele auf einem Schiff unter zusaetzlichen Bezeichnungen
+ bekannt sind, als an Land (zum Beispiel koennte eine fernwestliche
+ Besatzung die Ziele anders nennen).
+
+SIEHE AUCH
+----------
+::
+
+Funktionen AddMsg(L), AddFun(L), /std/transport.c
+Properties P_HARBOUR, P_NO_TRAVELING, P_TRAVEL_INFO
+
+2015-Jan-18, Arathorn.
+-------------------------------------------------------------------------------------------------------------------------------
+::
+
diff --git a/doc/sphinx/lfun/AddSingularId.rst b/doc/sphinx/lfun/AddSingularId.rst
new file mode 100644
index 0000000..274c8c3
--- /dev/null
+++ b/doc/sphinx/lfun/AddSingularId.rst
@@ -0,0 +1,50 @@
+AddSingularId()
+===============
+
+FUNKTION
+--------
+::
+
+ void AddSingularId(mixed id);
+
+DEFINIERT IN
+------------
+::
+
+ /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+ id
+ Identifikationsstring oder Array von Strings
+
+BESCHREIBUNG
+------------
+::
+
+ Es werden ein oder mehrere Bezeichner hinzugefuegt, mit denen sich eine
+ einzelne Einheit ansprechen laesst.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEISPIELE
+---------
+::
+
+ siehe /items/money.c
+
+SIEHE AUCH
+----------
+::
+
+ AddPluralId(), RemoveSingularId(), AddId(), id(), /std/unit.c
+
+
+Last modified: Mon Jul 14 11:31:00 1997 by Silvana
+
diff --git a/doc/sphinx/lfun/AddSmells.rst b/doc/sphinx/lfun/AddSmells.rst
new file mode 100644
index 0000000..091d7d9
--- /dev/null
+++ b/doc/sphinx/lfun/AddSmells.rst
@@ -0,0 +1,92 @@
+AddSmells()
+===========
+
+FUNKTION
+--------
+::
+
+ void AddSmells(string|string* keys, string|string*|mapping|closure desc);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ keys
+ String oder Array von Strings mit den Namen der Details.
+ desc
+ String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion entspricht dem AddDetail() fuer Standarddetails, nur
+ koennen hiermit Gerueche realisiert werden:
+ Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
+ bei der Untersuchung aussehen, haengt im wesentlichen vom Typ der
+ Beschreibung <desc> ab:
+ <desc> ist ein String.
+ Beim Untersuchen wird dieser String zurueckgegeben.
+ <desc> ist ein String-Array.
+ Beim Untersuchen wird zufaellig einer der Strings zurueckgegeben.
+ <desc> ist ein Mapping.
+ Das Mapping muss folgenden Aufbau haben:
+ ([0: "Defaulttext",
+ "rasse1": "r1text", ...]).
+
+ Falls fuer die Rasse des das Detail untersuchenden Spielers ein
+ Eintrag im Mapping existiert, wird der entsprechende Text
+ zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
+ rassenabhaengige Details moeglich. Siehe auch die Beispiele.
+ <desc> ist eine Closure.
+ In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
+ zurueckgegeben. Die Closure bekommt dabei den Namen des Details
+ als Parameter uebergeben.
+
+ Fuer Geruchsdetails koennen Forscherpunkte eingetragen werden.
+
+ Gerueche koennen allgemein einen Raum oder Objekt zugeordnet werden:
+ dafuer muss man als <key> SENSE_DEFAULT uebergeben.
+
+
+
+ Spielerkommandos: "riech", "rieche", "schnupper", "schnuppere"
+
+BEISPIELE
+---------
+::
+
+ Ein kleines Beispiel fuer rassenabhaengige Gerueche mit Closures:
+ string strafe(string key);
+ ...
+ AddSmells(SENSE_DEFAULT,
+ "Der Geruch von Knoblauch ist ueberwaeltigend!\n");
+ AddSmells(({"knoblauch","geruch"}),
+ ([0: "Puhh, das stinkt!\n",
+ "vampir": #'strafe]));
+ ...
+ string strafe(string key) {
+ this_player()->reduce_hit_points(100);
+ return "Der Knoblauch schmerzt dich furchtbar!\n";
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Setzen: AddDetail(), AddReadDetail(), AddSounds(),
+ AddTouchDetail()
+ Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+ RemoveSounds(), RemoveTouchDetail()
+ Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+ Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+ Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddSounds.rst b/doc/sphinx/lfun/AddSounds.rst
new file mode 100644
index 0000000..df83b42
--- /dev/null
+++ b/doc/sphinx/lfun/AddSounds.rst
@@ -0,0 +1,82 @@
+AddSounds()
+===========
+
+FUNKTION
+--------
+::
+
+ void AddSounds(string|string* keys, string|string*|mapping|closure desc);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ keys
+ String oder Array von Strings mit den Namen der Details.
+ desc
+ String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion entspricht dem AddDetail() fuer Standarddetails, nur
+ koennen hiermit Geraeusche realisiert werden:
+ Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
+ bei der Untersuchung aussehen, haengt im wesentlichen vom Typ der
+ Beschreibung <desc> ab:
+ <desc> ist ein String.
+ Beim Untersuchen wird dieser String zurueckgegeben.
+ <desc> ist ein String-Array.
+ Beim Untersuchen wird zufaellig einer der Strings zurueckgegeben.
+ <desc> ist ein Mapping.
+ Das Mapping muss folgenden Aufbau haben:
+ ([0: "Defaulttext",
+ "rasse1": "r1text", ...]).
+
+ Falls fuer die Rasse des das Detail untersuchenden Spielers ein
+ Eintrag im Mapping existiert, wird der entsprechende Text
+ zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
+ rassenabhaengige Details moeglich. Siehe auch die Beispiele.
+ <desc> ist eine Closure.
+ In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
+ zurueckgegeben. Die Closure bekommt dabei den Namen des Details
+ als Parameter uebergeben.
+
+ Fuer Geraeuschdetails koennen Forscherpunkte eingetragen werden.
+
+ Gerauesche koennen allgemein einen Raum oder Objekt zugeordnet werden:
+ dafuer muss man als <key> SENSE_DEFAULT uebergeben.
+
+ Spielerkommandos: "lausche", "lausch", "hoer", "hoere"
+
+BEISPIELE
+---------
+::
+
+ Ein kleines Beispiel fuer rassenabhaengige Gerauesche
+ AddSounds(SENSE_DEFAULT, "Die Zwergenmusik uebertoent alles!\n");
+ AddSounds(({"zwergenmusik","musik"}),
+ ([0 : "Seltsamer Krach!\n",
+ "zwerg": "Das klingt einfach fantastisch!\n"]));
+
+SIEHE AUCH
+----------
+::
+
+ Setzen: AddDetail(), AddReadDetail(), AddSmells(),
+ AddTouchDetail()
+ Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+ RemoveSounds(), RemoveTouchDetail()
+ Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+ Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+ Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddSpecialDetail.rst b/doc/sphinx/lfun/AddSpecialDetail.rst
new file mode 100644
index 0000000..24f8f64
--- /dev/null
+++ b/doc/sphinx/lfun/AddSpecialDetail.rst
@@ -0,0 +1,87 @@
+AddSpecialDetail()
+==================
+
+VERALTET AddSpecialDetail()
+---------------------------
+::
+
+FUNKTION
+--------
+::
+
+ void AddSpecialDetail(string|string* keys, string func);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ keys
+ String oder Array von Strings mit den Namen der Details.
+ func
+ String mit dem Namen der Funktion, die zur Auswertung aufgerufen
+ wird.
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird ein Detail hinzugefuegt, dessen Inhalt nicht von vornherein
+ feststeht, sondern von aeusseren Bedingungen abhaengt. Zu diesem
+ Zweck wird immer, wenn dieses Detail untersucht wird, die Funktion
+ func aufgerufen, um den aktuellen Zustand des Details zu bestimmen.
+ Der Funktion wird als Parameter das Schluesselwort uebergeben, mit
+ dem das Detail untersucht wurde.
+
+ VERALTET: Bitte AddDetail mit Closure benutzen.
+
+BEISPIELE
+---------
+::
+
+ Ein zustandsabhaengiges Detail:
+
+ int hebel_betaetigt;
+ string hebel(string key);
+ ...
+ // ALT: AddSpecialDetail( ({ "hebel", "schalter" }), "hebel" );
+ AddDetail(({ "hebel", "schalter" }), #'hebel );
+ ...
+ string hebel(string key)
+ { if(hebel_betaetigt)
+ return "Der "+capitalize(key)+" steht auf EIN.\n";
+ else
+ return "Der "+capitalize(key)+" steht auf AUS.\n";
+ }
+
+ Man erhaelt verschiedene Ergebnisse beim Untersuchen, je nachdem
+ ob das Flag hebel_betaetigt gesetzt ist oder nicht.
+
+BEMERKUNG
+---------
+::
+
+ Intern werden Details und SpecialDetails im selben Mapping
+ verwaltet.
+ Man kann statt dieser Funktion deshalb auch AddDetail mit Closures
+ nutzen.
+
+SIEHE AUCH
+----------
+::
+
+ Setzen : AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+ AddTouchDetail()
+ Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+ RemoveSounds(), RemoveTouchDetail()
+ Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+ Veraltet: RemoveSpecialDetail(), P_READ_MSG
+ Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AddSpecialExit.rst b/doc/sphinx/lfun/AddSpecialExit.rst
new file mode 100644
index 0000000..4a367f9
--- /dev/null
+++ b/doc/sphinx/lfun/AddSpecialExit.rst
@@ -0,0 +1,82 @@
+AddSpecialExit()
+================
+
+FUNKTION
+--------
+::
+
+ void AddSpecialExit(string|string* cmd, string|closure func);
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/exits
+
+ARGUMENTE
+---------
+::
+
+ string/string* cmd
+ die Richtung(en), in die der Ausgang fuehrt
+ string/closure func
+ der Name der aufzurufenden Funktion/Closure
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird ein Ausgang in die Richtung(en) cmd eingefuegt. Wird der
+ Ausgang benutzt, so wird die Closure bzw. Funktion func ausgefuehrt.
+
+ AddSpecialExit(cmd, "func") entspricht:
+ - AddExit(keys, #'func)
+
+BEMERKUNGEN
+-----------
+::
+
+ In func muss man den Spieler selbst in den Zielraum bewegen. Im
+ Erfolgsfall sollte man einen Wert >0 zurueckgeben, im Fehlerfall einen
+ Wert <=0.
+
+ func bekommt als Parameter einen String mit der gewaehlten
+ Bewegungsrichtung uebergeben.
+
+BEISPIELE
+---------
+::
+
+ // ein Ausgang soll nur von Froeschen benutzbar sein:
+
+ AddSpecialExit("loch", "lochfkt");
+ // der gleiche Aufruf, nur anders:
+ // static int lochfkt(string dir); // Prototyp
+ // ...
+ // AddSpecialExit("loch", #'lochfkt);
+ // auch identisch zu:
+ // AddExit("loch", #'lochfkt);
+
+ static int lochfkt(string dir) {
+ if (!(this_player()->QueryProp(P_FROG))) {
+ // Kein Frosch => passt nicht!
+ notify_fail("Du bist zu gross!\n");
+ return 0;
+ }
+ // Meldungen werden im move() gleich mitgegeben
+ return this_player()->move("/room/loch", M_GO, 0,
+ "huepft ins Loch", "huepft herein");
+ }
+
+SIEHE AUCH
+----------
+::
+
+ AddExit(), GetExits(),
+ RemoveExit(), RemoveSpecialExit(),
+ GuardExit(),
+ H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
+ ausgaenge
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/AddSpecialInfo.rst b/doc/sphinx/lfun/AddSpecialInfo.rst
new file mode 100644
index 0000000..558b2d2
--- /dev/null
+++ b/doc/sphinx/lfun/AddSpecialInfo.rst
@@ -0,0 +1,88 @@
+AddSpecialInfo()
+================
+
+FUNKTION
+--------
+::
+
+ varargs void AddSpecialInfo( frage, meldung
+ [, indent [, [silent [, casebased] ] ] );
+
+ARGUMENTE
+---------
+::
+
+ string/string* frage
+ Schluesseltext(e) auf die Informationen gegeben werden sollen.
+ string/closure function
+ Methodenname im NPC/Closure
+ string indent
+ Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
+ int/string silent
+ Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
+ string/closure casebased
+ Funktionsname oder Closure mit Returnwert string oder int.
+
+DEFINIERT IN
+------------
+::
+
+ /std/npc/info.c
+
+BESCHREIBUNG
+------------
+::
+
+ Wenn ein Spieler ein NPC mittels "frage <monstername> nach <frage>" nach
+ einer Information mit dem Schluessel frage fragt, so wird die Methode
+ "function" gerufen. Die Rueckgabe wird als Meldung ausgegeben.
+
+ Fuer die Beschreibung der weiteren Parameter siehe man AddInfo(L).
+
+ AddSpecialInfo(keys, "function", ...) entspricht:
+ - AddInfo(keys, #'function, ...)
+
+BEMERKUNGEN
+-----------
+::
+
+ Da AddSpecialInfo() und AddInfo() auf die gleichen Daten zugreifen,
+ kann man Informationen, die mit AddSpecialInfo() gesetzt wurden, auch
+ mit RemoveInfo() entfernen. Es gibt kein RemoveSpecialInfo().
+
+BEISPIELE
+---------
+::
+
+ // Das folgende Beispiel ist auch unter man AddInfo(L) zu finden.
+ ### dynamisch ###
+ AddSpecialInfo(({"keks","kekse"}),
+ "query_kekse", // der Methodenname
+ "sagt: ");
+ // ist uebrigens das gleiche wie:
+ // static string query_kekse();
+ // ...
+ // AddInfo(({"keks","kekse"}),
+ // #'query_kekse, // ein Verweis auf die Methode
+ // "sagt: ");
+ ...
+ static string query_kekse() {
+ if(present("keks"))
+ return("Ich hab noch welche. Aetsch!");
+ return("Menno. Keine mehr da!");
+ }
+
+ // "frage monster nach keks":
+ // - wenn es noch Kekse hat, hoeren alle:
+ // "Das Monster sagt: Ich hab noch welche. Aetsch!
+ // - sonst:
+ // "Das Monster sagt: "Menno. Keine mehr da!
+
+SIEHE AUCH
+----------
+::
+
+ AddInfo(L), RemoveInfo(L)
+
+7.Apr 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/AddSpell.rst b/doc/sphinx/lfun/AddSpell.rst
new file mode 100644
index 0000000..602292f
--- /dev/null
+++ b/doc/sphinx/lfun/AddSpell.rst
@@ -0,0 +1,173 @@
+AddSpell()
+==========
+
+FUNKTION
+--------
+::
+
+ varargs int AddSpell(int rate, int damage, string TextForEnemy,
+ string TextForOthers, string|string* dam_type,
+ string|closure func, int|mapping spellarg)
+
+DEFINIERT IN
+------------
+::
+
+ /std/npc/combat.c
+
+ARGUMENTE
+---------
+::
+
+ rate - Relative Haeufigkeit der Anwendung (*),
+ muss >= 0 sein
+ damage - Der Schadenswert fuer Defend(),
+ muss > 0 sein
+ TextForEnemy - Text, den der Feind erhalten soll
+ TextForOthers - Text, den andere im Raum erhalten sollen
+ dam_type - Schadenstyp(en) fuer Defend(),
+ (Default: ({DT_MAGIC}) )
+ func - Funktionsname oder Closure, die nach Anwendung
+ aufgerufen werden soll
+ (Optional, bekommt als Argumente object enemy,
+ int real_damage, string* dam_type)
+ spellarg - Spell-Argument fuer Defend(), Default ist "1"
+
+BESCHREIBUNG
+------------
+::
+
+ Ermoeglicht einfache Angriffs-Zaubersprueche fuer NPCs. Das Ausfuehren von
+ Spells verursacht bei dem NPC keine KP-Kosten.
+
+ Mit P_SPELLRATE wird die generelle Wahrscheinlichkeit der Ausfuehrung
+ solcher Spells im Heartbeat angegeben, mit 'rate' kann man die relative
+ Wahrscheinlichkeit der Spells untereinander steuern.
+
+ (*) Relative Haeufigkeit heisst, dass sich alle 'rate' der Spells
+ aufaddieren und ein einzelnes 'rate' dann in Relation zur Gesamtsumme
+ steht. D.h. drei Spells mit 80, 10, 10 (Summe 100) haben die selben
+ Aufruf-Wahrscheinlichkeiten wie drei Spells mit 120, 15, 15 oder drei
+ Spells mit 160, 20, 20.
+
+ Ein Spell wird immer in folgender Reihenfolge abgearbeitet:
+ 1. Die Texte werden an die Beteiligten ausgegeben.
+ 2. Es wird ggf. SpellDefend gerufen (wenn kein SP_PHYSICAL_ATTACK).
+ Abbruch bei Schutz.
+ 3. Im Opfer wird Defend() mit den angegebenen Werten aufgerufen.
+ Abbruch bei Tod/Zerstoerung des Opfers.
+ 4. Eine Funktion, so definiert, wird ausgefuehrt.
+
+BEMERKUNGEN
+-----------
+::
+
+ TextForOthers wird vor der Ausgabe der Meldung durch replace_personal()
+ geschickt, d.h. es koennen Platzhalter wie @WER1, @WEMQP1 und aehnliche
+ verwendet werden (siehe auch die Manpage von replace_personal()).
+ Da Ersetzungen nur fuer das Gegnerobjekt beruecksichtigt werden, koennen
+ nur Platzhalter mit Endziffer 1 verwendet werden. Die Ersetzungen werden
+ so gesteuert, dass die eingefuegten Namen nach Satzanfaengen automatisch
+ gross geschrieben werden.
+ Frueher wurden statt replace_personal() die Platzhalter @WER, @WESSEN,
+ @WEM, @WEN verwendet. Diese funktionieren weiterhin, sollten aber nicht
+ mehr in neuem Code benutzt werden.
+
+ In der von AddSpell gerufenen Methode "func" koennen speziellere
+ Sachen mit dem aktuellen Feind angestellt werden koennen. Die Methode
+ muss im selben Objekt definiert sein, sofern der Funktionsname und
+ keine Closure uebergeben wird.
+
+ Will man einen physischen Angriff ausloesen, MUSS <spellarg> ein Mapping
+ mit ([SP_PHYSICAL_ATTACK: 1]) sein. Bei Uebergeben einer 0 oder Weglassen
+ des Werts wird an Defend das Default '1' (da es Spells sind) uebergeben.
+
+ Wenn damage<=0 oder rate<0 oder keine Meldungen uebergeben werden, wird
+ der Spell NICHT eingetragen, sondern die Funktion bricht mit Rueckgabe
+ von 0 ab.
+
+BEISPIELE
+---------
+::
+
+ // #1 Einfacher NPC mit drei Spells, Gesamtrate = 100, also sind die
+ // Raten direkt als Prozent Aufrufwahrscheinlichkeit lesbar.
+ AddSpell(80, 400,
+ "Der Hexer greift Dich mit einem kleinen Feuerball an.\n",
+ "Der Hexer greift @WEN mit einem kleinen Feuerball an.\n",
+ ({DT_FIRE, DT_MAGIC}));
+ AddSpell(10, 800,
+ "Der Hexer greift Dich mit einem riesigen Feuerball an.\n",
+ "Der Hexer greift @WEN mit einem riesigen Feuerball an.\n",
+ ({DT_FIRE, DT_MAGIC}));
+ AddSpell(8, 100,
+ "Der Hexer piekst Dir in die Augen!",
+ "Der Hexer piekst @WEM in die Augen!", ({DT_PIERCE}),
+ "augen_stechen");
+ AddSpell(2, 5, (string)0, (string)0, (string*)0, "salto_mortalis");
+
+ (Kleiner Feuerball mit 80% Wahrscheinlichkeit, riesiger mit 10%,
+ "augen_stechen" mit 8%, "salto_mortalis" mit 2%)
+
+ // Die Funktion "augen_stechen" kann dann so aussehen:
+ void augen_stechen(object enemy, int damage, mixed dam_types ) {
+ if (damage>10 && !enemy->QueryProp(P_BLIND)) {
+ enemy->SetProp(P_BLIND, 1);
+ if(enemy->QueryProp(P_BLIND))
+ tell_object(enemy, "Du bist nun blind!\n");
+ }
+ }
+
+ // Zur Funktion "salto_mortalis" gibt es keine Meldungen, dennoch
+ // wird Defend mit: enemy->Defend(5, ({DT_MAGIC}), 1, this_object())
+ // gerufen!
+ void salto_mortalis(object enemy, int damage, mixed dam_types ) {
+ // dem geneigten Leser ueberlassen, den Gegner zu toeten
+ }
+
+ // #2 Physische Angriffe: die Ruestungen sollen beruecksichtigt werden!
+ // SP_PHYSICAL_ATTACK muss in einem Mapping auf 1 gesetzt werden,
+ // damit Ruestungen physisch wirken (ansonsten werden nur ihre
+ // DefendFuncs() ausgewertet). Es muss auch eine physische Schadensart
+ // enthalten sein!
+ // SpellDefend() wird bei diesem Flag nicht mehr am Gegner gerufen.
+ AddSpell(100, 200+random(200),
+ "Die kleine Ratte beisst Dich!\n",
+ "@WER wird von einer kleinen Ratte gebissen!\n",
+ ({DT_PIERCE, DT_POISON}), (string)0,
+ ([SP_PHYSICAL_ATTACK:1]));
+
+ // #3 Selektive physische Angriffe (siehe auch man Defend_bsp):
+ // Will man erreichen, dass einige Ruestungen wirken, andere aber
+ // nicht oder nur teilweise, kann man das ueber die Spellparameter
+ // ausfuehrlich steuern:
+
+ // erstmal fuer alle Ruestungsarten einen Schutz von 0% einstellen:
+ mapping armours = map_indices(VALID_ARMOUR_CLASS, #'!);
+ armours[AT_TROUSERS] = 120; // 120% Schutz durch Hosen
+ armours[AT_BOOT] = 30; // 30% Schutz durch Stiefel
+
+ AddSpell(20,200+random(200),
+ "Die kleine Ratte beisst Dir blitzschnell in die Wade!\n",
+ "@WER wird von einer kleinen Ratte in die Wade gebissen!\n",
+ ({DT_PIERCE, DT_POISON}), (string)0,
+ ([SP_PHYSICAL_ATTACK:1, SP_NO_ACTIVE_DEFENSE:1,
+ SP_REDUCE_ARMOUR: armours]));
+
+ // SP_NO_ACTIVE_DEFENSE = 1 schaltet aktive Abwehr (Karate/Klerus) ab
+ // SP_REDUCE_ARMOUR enthaelt eine Liste von Ruestungstypen mit ihren
+ // neuen Wirkungsgraden in Prozent. Nicht enthaltene Ruestungen haben
+ // weiterhin 100% Schutzwirkung.
+
+SIEHE AUCH
+----------
+::
+
+ Sonstiges: SpellAttack, SpellDefend, Defend, QueryDefend, SelectEnemy
+ replace_personal
+ Properties: P_DISABLE_ATTACK, P_SPELLRATE, P_AGGRESSIVE
+ Abwehr: Defend, Defend_bsp, SpellDefend
+ Methoden: modifiers
+
+Zuletzt geaendert: 20.11.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/AddToMenu.rst b/doc/sphinx/lfun/AddToMenu.rst
new file mode 100644
index 0000000..29824f6
--- /dev/null
+++ b/doc/sphinx/lfun/AddToMenu.rst
@@ -0,0 +1,281 @@
+AddToMenu()
+===========
+
+FUNKTION
+--------
+::
+
+ varargs string AddToMenu(string menuetext,
+ mixed ids,
+ mapping minfo,
+ mixed rate,
+ mixed msg,
+ mixed refresh,
+ mixed delay,
+ mixed d_msg);
+
+DEFINIERT IN
+------------
+::
+
+ /std/pub.c
+
+ARGUMENTE
+---------
+::
+
+ Die Erlaeuterung der Parameter beschraenkt sich im Folgenden
+ zunaechst auf die Grundfunktionalitaet bei Verwendung fester
+ Werte. Die Moeglichkeiten zur Realisierung dynamischen Verhaltens
+ sind in den Fussnoten zu den einzelnen Parametern beschrieben.
+
+ menuetext
+ Der Text steht als kurze Beschreibung im Menue.
+ ids
+ String oder Array von Strings, mit denen sich die Speise bzw. das
+ Getraenk beim Bestellen ansprechen laesst.
+ minfo
+ Mapping mit Eintraegen fuer:
+ P_HP LP-Heilung in Punkten [*]
+ P_SP KP-Heilung in Punkten [*]
+ P_FOOD Saettigungswirkung der Speise [*]
+ P_DRINK Saettigungswirkung des Getraenks [*]
+ P_ALCOHOL Alkoholgehalt des Getraenks [*]
+ P_VALUE Preis der Speise bzw. des Getraenks [*]
+ rate [*]
+ Heilrate in Punkten pro HeartBeat.
+ msg [**]
+ Meldung beim Essen:
+ Array mit 2 Strings: (1) fuer Empfaenger, (2) fuer Andere.
+ Verfuegbare Platzhalter sind weiter unten im Abschnitt "Beispiel"
+ dokumentiert.
+ refresh
+ Mapping mit Eintraegen fuer:
+ PR_USER (Kontingent fuer einzelnen Spieler) [*]
+ PR_ALL (Zusatzkontingent fuer alle) [*]
+ Alternativ: 0 fuer unbegrenzte Verfuegbarkeit
+ Einem Key muessen dabei zwei Werte zugeordnet werden:
+ Der Erste gibt die Hoehe des Kontingents an, der Zweite legt
+ fest, alle wieviel reset()s das Kontingent wieder aufgefuellt
+ wird.
+ Verwendung des Mappings erfordert Inkludieren von pub.h.
+ delay [*]
+ Zahl der Sekunden, um die verzoegert die Heilung eintritt,
+ z.B. weil das Essen erst zubereitet werden muss.
+ d_msg [**]
+ Meldung beim Bestellen, falls die Heilung verzoegert wird
+ Array mit 2 Strings: (1) fuer Empfaenger, (2) fuer Andere.
+
+
+
+ [*] Dieser Parameter kann statt eines festen Zahlenwerts mit
+ folgenden Werten gefuellt werden:
+
+ 1) Mapping <racemodifier> der Form:
+ ([ 0 : <standardwert> ,
+ <rasse_1> : <wert_1>,
+ ... ,
+ <rasse_n> : <wert_n> ]).
+ Die Eintraege in diesem Mapping werden gegen die Rasse des
+ bestellenden Spielers geprueft und entsprechend die
+ zugehoerigen Werte verwendet.
+ 2) string <func>: Aufruf erfolgt mittels
+ call_other(this_object(), func, empfaenger);
+ gerufen (aber: siehe Hinweise).
+ 3) closure <func>: Aufruf erfolgt mittels
+ funcall(func, empfaenger);
+ 4) Array der Form ({string <obj>, string <func>}) oder
+ ({object <obj>, string <func>})
+ Aufruf erfolgt mittels
+ call_other(obj, func, empfaenger);
+ (aber: siehe Hinweise). <obj> ist folglich als Objektpointer
+ oder dessen object_name() anzugeben. <func> wird mittels
+ function_exists() auf Existenz ueberprueft.
+
+ HINWEISE: im Falle von Lieferverzoegerung ("delay") und
+ Preis (P_VALUE) wird bei allen Funktionsaufrufen NICHT der
+ Empfaenger, sondern der Zahler uebergeben.
+ Im Falle der Kontingent-Liste ("refresh") kann nur die
+ verfuegbare Menge modifiziert werden, nicht die Zeit
+ bis zum Wieder-Auffuellen.
+
+ [**] Zur Erzeugung variabler Meldungen koennen folgende Werte
+ eingetragen werden:
+
+ 1) closure <func>: Aufruf erfolgt mittels
+ funcall(func, zahler, empfaenger, ident, minfo);
+ 2) string <func>: Aufruf erfolgt mittels
+ call_other(this_object(), func, zahler, empfaenger,
+ ident, minfo);
+ <func> bekommt Zahler und Empfaenger als Objektpointer,
+ ident als String und minfo als Mapping mit den
+ jeweiligen Heilwerten uebergeben. minfo entspricht hierbei
+ den Daten, die als dritter Parameter an AddToMenu()
+ uebergeben wurden.
+ HINWEIS: wenn in das minfo-Mapping keine int-Festwerte
+ eingetragen wurden, werden diese gemaess den Regeln unter [*]
+ geprueft; Funktionen/Closures werden ggf. ausgewertet und
+ deren Rueckgabewerte an die Funktion <func> uebergeben.
+ WICHTIG: Die Rueckgabewerte der Funktion werden nicht
+ ausgewertet. Jeder, der anstatt einer Meldung einen
+ Funktionsaufruf programmiert, muss fuer die Ausgabe der
+ Meldungen selbst sorgen.
+
+
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion werden Speisen oder Getraenke in die Karte
+ von Kneipen und Restaurants eingefuegt.
+
+RUECKGABEWERT
+-------------
+::
+
+ Rueckgabewert ist ein String "menuentry%d", wobei %d eine Nummer
+ ist, die darueber Auskunft gibt, den wievielten Eintrag in die
+ interne Karte der Kneipe diese Speise bzw. dieses Getraenk
+ darstellt. Im Prinzip handelt es sich bei dem String um einen Key
+ fuer ein Mapping, in dem die Speisen bzw. Getraenke gespeichert
+ sind.
+
+BEMERKUNGEN
+-----------
+::
+
+ Die aelteren Funktionen 'AddDrink' bzw. 'AddFood' werden zwar mithilfe
+ dieser maechtigeren Funktion aus Gruenden der Abwaertskompatibilitaet
+ simuliert, sollen aber nicht mehr eingesetzt werden.
+
+
+
+ Die alten Platzhalter && etc. (s.u.) werden weiterhin unterstuetzt,
+ sollten aber fuer bessere Wartbarkeit nicht mehr verwendet werden.
+
+
+
+ Fuer das Testen der Kneipe gibt es in jeder Kneipe den Befehl
+ 'pubinit'. Hiermit lassen sich die Speisen und Getraenke durch-
+ checken. Steht in der Ausgabe bei einem Getraenk/Essen ein FAIL,
+ so wird die entsprechende Speise (oder Getraenk) NICHT an Spieler
+ verkauft. Ausnahmen fuer Speisen/Getraenke mit hoeheren maximalen
+ Werten sind durch Balance-EM zu genehmigen.
+
+BEISPIEL
+--------
+::
+
+ include <pub.h>
+
+ create()
+ {
+ AddToMenu("'Opa's Drachenkeule'",({"drachenkeule","keule"}),
+ ([P_HP:63,P_SP:63,P_FOOD:9,P_VALUE:528]), 5,
+ ({"Du isst die Keule mit einem schlechten Gewissen.",
+ "@WER1 isst die Keule mit einem schlechten Gewissen."}),
+ ([ PR_USER : 4; 1 , PR_ALL : 20; 3 ]), 9,
+ ({"Der unsichtbare Kneipier schneidet einem Rentner ein grosses "
+ "Stueck aus dessen Keule und bereitet sie Dir zu. Komisch, muss "
+ "wohl ein Tippfehler auf der Karte gewesen sein.",
+ "Der unsichtbare Kneipier schneidet einem hilflosen Opa ein "
+ "Stueck aus dessen Keule und braet diese fuer @WEN1."}) );
+ }
+
+ 1) Name der Speise (des Getraenks) auf der Karte (bei menue).
+
+ AddToMenu("'Opa's Drachenkeule'",
+
+ 2) ids mit denen sich bestellen laesst (z.B. "kaufe keule").
+
+ ({"drachen","drachenkeule","keule"}),
+
+ 3) Heilung fuer LP und KP, Saettigung (P_FOOD oder P_DRINK,
+ P_ALCOHOL nach Belieben setzen), Preis (P_VALUE).
+ HP und SP muessen nicht gleich sein. Speisen und Getraenke,
+ die nur eines von beiden heilen, sind auch moeglich.
+
+ ([P_HP:63,P_SP:63,P_FOOD:9,P_VALUE:528]),
+
+ 4) Heilung pro Heartbeat (in diesem Beispiel je 5 KP/LP).
+
+
+
+ 5,
+
+ 5) Meldungen fuer Spieler und Umstehende die bei Genuss ausgege-
+ ben werden (also NICHT der Bestell-Text).
+
+ ({"Du isst die Keule mit einem schlechten Gewissen.",
+ "@WER1 isst die Keule mit einem schlechten Gewissen."}),
+
+ Die Ausgabe-Strings werden vor der Ausgabe mit dem Empfaenger
+ als Objekt an replace_personal() uebergeben. Fuer die
+ moeglichen Platzhalter siehe dort.
+
+
+
+ 6) Die Speise ist in ihrer Anzahl begrenzt. Fuer jeden Spieler
+ sind 4 Keulen pro reset() da. Ausserdem gibt es noch einen
+ "Notvorrat" von 20 Keulen, der alle 3 reset()s aufgefuellt
+ wird. Aus diesem (so noch vorhanden) werden die Spieler
+ versorgt, wenn ihr "persoenlicher Vorrat" aufgebraucht ist.
+
+ ([ PR_USER : 4; 1 , PR_ALL : 20; 3 ]),
+
+
+
+ HINWEIS: bei Benutzung des Mappings muss <pub.h> inkludiert
+ werden!
+
+
+
+ Wenn man keine reset-abhaengigen Speisen haben moechte, traegt
+ man hier eine 0 ein.
+
+ 7) Die Zahl ist die Wartezeit in Sekunden, die der Wirt z.B. fuer
+ die Zubereitung und Auslieferung an den Spieler braucht.
+
+ 9,
+
+
+
+ 8) Letztendlich die Meldungen an Spieler und Umstehende, die bei Be-
+ stellung (hier 'kaufe keule') ausgegeben werden.
+
+ ({"Der unsichtbare Kneipier schneidet einem Rentner ein grosses "
+ "Stueck aus dessen Keule und bereitet sie Dir zu. Komisch, muss "
+ "wohl ein Tippfehler auf der Karte gewesen sein.",
+ "Der unsichtbare Kneipier schneidet einem hilflosen Opa ein "
+ "Stueck aus dessen Keule und braet diese fuer @WEN1."}));
+
+LISTE DER ALTEN PLATZHALTER (DEPRECATED):
+ && - pl->name(WER,2)
+ &1& - pl->name(WER,2)
+ &2& - pl->name(WESSEN,2)
+ &3& - pl->name(WEM,2)
+ &4& - pl->name(WEN,2)
+ &1# - capitalize(pl->name(WER,2))
+ &2# - capitalize(pl->name(WESSEN,2))
+ &3# - capitalize(pl->name(WEM,2))
+ &4# - capitalize(pl->name(WEN,2))
+ &! - pl->QueryPronoun(WER)
+ &5& - pl->QueryPronoun(WE);
+ &6& - pl->QueryPronoun(WESSEN)
+ &7& - pl->QueryPronoun(WEM)
+ &8& - pl->QueryPronoun(WEN)
+ &5# - capitalize(pl->QueryPronoun(WER))
+ &6# - capitalize(pl->QueryPronoun(WESSEN))
+ &7# - capitalize(pl->QueryPronoun(WEM))
+ &8# - capitalize(pl->QueryPronoun(WEN))
+
+SIEHE AUCH
+----------
+::
+
+ AddFood(), AddDrink(), /sys/pub.h
+ RemoveFromMenu(), replace_personal()
+
+Last modified: Sam, 01. Okt 2011, 23:40 by Arathorn
+
diff --git a/doc/sphinx/lfun/AddTouchDetail.rst b/doc/sphinx/lfun/AddTouchDetail.rst
new file mode 100644
index 0000000..ca81e2b
--- /dev/null
+++ b/doc/sphinx/lfun/AddTouchDetail.rst
@@ -0,0 +1,90 @@
+AddTouchDetail()
+================
+
+FUNKTION
+--------
+::
+
+ void AddTouchDetail(string|string* keys,
+ string|string*|mapping|closure desc);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ keys
+ String oder Array von Strings mit den Namen der Details.
+ desc
+ String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion entspricht dem AddDetail() fuer Standarddetails, nur
+ koennen hiermit (ab)tastbare bzw. fuehlbare Details realisiert werden:
+ Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
+ beim (Ab)Tasten aussehen, haengt im wesentlichen vom Typ der
+ Beschreibung <desc> ab:
+ <desc> ist ein String.
+ Beim Untersuchen wird dieser String zurueckgegeben.
+ <desc> ist ein String-Array.
+ Beim Untersuchen wird zufaellig einer der Strings zurueckgegeben.
+ <desc> ist ein Mapping.
+ Das Mapping muss folgenden Aufbau haben:
+ ([0: "Defaulttext",
+ "rasse1": "r1text", ...]).
+
+ Falls fuer die Rasse des das Detail untersuchenden Spielers ein
+ Eintrag im Mapping existiert, wird der entsprechende Text
+ zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
+ rassenabhaengige Details moeglich. Siehe auch die Beispiele.
+ <desc> ist eine Closure.
+ In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
+ zurueckgegeben. Die Closure bekommt dabei den Namen des Details
+ als Parameter uebergeben.
+
+ Fuer fuehlbare Details koennen Forscherpunkte eingetragen werden.
+
+ Fuehlbare Details koennen allgemein einen Raum oder Objekt zugeordnet
+ werden: dafuer muss man als <key> SENSE_DEFAULT uebergeben.
+
+ Spielerkommandos: "taste"
+
+BEISPIELE
+---------
+::
+
+ Ein kleines Beispiel fuer rassenabhaengige, fuehlbare Details mit Closures:
+ string strafe(string key);
+ ...
+ AddTouchDetail(SENSE_DEFAULT, "Du fuehlst einige Knollen\n");
+ AddTouchDetail(({"knollen"}),
+ ([0: "Sie fuehlen sich an wie Knoblauchknollen. "
+ "Riech doch mal daran.\n",
+ "vampir": #'strafe]));
+
+ string strafe(string key) {
+ this_player()->reduce_hit_points(100);
+ return "Au! Das waren ja Knoblauchknollen!\n";
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Setzen: AddDetail(), AddReadDetail(), AddSmells(), AddSounds()
+ Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+ RemoveSounds(), RemoveTouchDetail()
+ Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+ Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+ Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/AllGroups.rst b/doc/sphinx/lfun/AllGroups.rst
new file mode 100644
index 0000000..bd4f50f
--- /dev/null
+++ b/doc/sphinx/lfun/AllGroups.rst
@@ -0,0 +1,36 @@
+AllGroups()
+===========
+
+FUNKTION
+--------
+::
+
+ string *AllGroups()
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/materialdb.c (MATERIALDB)
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt ein Array aller existenten Materialgruppen zurueck (ihre
+ Definitionsform wie in <thing/material.h> aufgelistet).
+
+SIEHE AUCH
+----------
+::
+
+ Konzepte: material, materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Listen: AllMaterials(), Dump()
+ materialliste, materialgruppen
+ Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
+ GroupName(), MaterialName(),
+ GetGroupMembers(), GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/AllMaterials.rst b/doc/sphinx/lfun/AllMaterials.rst
new file mode 100644
index 0000000..1d8142a
--- /dev/null
+++ b/doc/sphinx/lfun/AllMaterials.rst
@@ -0,0 +1,36 @@
+AllMaterials()
+==============
+
+FUNKTION
+--------
+::
+
+ string *AllMaterials()
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/materialdb.c (MATERIALDB)
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt ein Array aller existenten Materialien zurueck (ihre Definitions-
+ form wie in <thing/material.h> aufgelistet).
+
+SIEHE AUCH
+----------
+::
+
+ Konzepte: material, materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Listen: AllGroups(), Dump()
+ materialliste, materialgruppen
+ Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
+ GroupName(), MaterialName(),
+ GetGroupMembers(), GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/AssocMember.rst b/doc/sphinx/lfun/AssocMember.rst
new file mode 100644
index 0000000..601587c
--- /dev/null
+++ b/doc/sphinx/lfun/AssocMember.rst
@@ -0,0 +1,75 @@
+AssocMember()
+=============
+
+FUNKTION
+--------
+::
+
+ int AssocMember(object npc)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ Der zuzuordnende NPC.
+
+BESCHREIBUNG
+------------
+::
+
+ Ordnet einen NPC einem Spieler zu. Dieser ist dann
+ immer im Team des Spielers, moeglichst in der gleichen Reihe.
+
+RUECKGABEWERT
+-------------
+::
+
+ 1, falls Zuordnung erfolgreich, sonst 0.
+
+BEISPIEL
+--------
+::
+
+ void fun(object pl)
+ {
+ if ( pl && pl->AssocMember(this_object()) )
+ tell_object(pl,break_string(
+ "Ich kaempfe nun auf Deiner Seite!\n",78,"Ein Feuerteufel "
+ "teilt Dir mit:");
+ ...
+ }
+
+BEMERKUNGEN
+-----------
+::
+
+ 1. Kann nur von Gilden, Spellbooks, vom Objekt selber und vom
+ zuzuordnenden NPC aufgerufen werden.
+ 2. Einem NPC, der selber einem Spieler zugeordnet ist, kann kein
+ NPC zugeordnet werden.
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_TEAM_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+ SelectFarEnemy
+ Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+ PresentTeamPosition, SwapRows
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+
+Last modified: 04.10.2011, Zesstra
+
diff --git a/doc/sphinx/lfun/Attack.rst b/doc/sphinx/lfun/Attack.rst
new file mode 100644
index 0000000..9281478
--- /dev/null
+++ b/doc/sphinx/lfun/Attack.rst
@@ -0,0 +1,42 @@
+Attack()
+========
+
+FUNKTION
+--------
+::
+
+ void Attack(object enemy)
+
+ARGUMENTE
+---------
+::
+
+ enemy: Der Feind.
+
+BESCHREIBUNG
+------------
+::
+
+ Der Feind wird der Staerke der Waffe (bzw. der Haende) entsprechend
+ stark angegriffen.
+
+RUECKGABEWERT
+-------------
+::
+
+ Keiner.
+
+BEMERKUNG
+---------
+::
+
+ Diese Funktion gibt die Angriffsmeldung aus.
+ Falls mit blossen Haenden angegriffen wird, ist die Staerke
+ (2*Staerke_der_Haende + 10*A_STR)/3
+
+SIEHE AUCH
+----------
+::
+
+ "Defend", "QueryDamage"
+
diff --git a/doc/sphinx/lfun/BecomesNetAlive.rst b/doc/sphinx/lfun/BecomesNetAlive.rst
new file mode 100644
index 0000000..a2f0c37
--- /dev/null
+++ b/doc/sphinx/lfun/BecomesNetAlive.rst
@@ -0,0 +1,68 @@
+BecomesNetAlive()
+=================
+
+FUNKTION
+--------
+::
+
+ void BecomesNetAlive(object pl);
+
+GERUFEN VON
+-----------
+::
+
+ /std/player/base.c
+
+ARGUMENTE
+---------
+::
+
+ pl
+ Spieler, der Verbindung zum MUD wiedererlangt.
+
+BESCHREIBUNG
+------------
+::
+
+ Spieler, welche die Verbindung zum MUD freiwillig
+ (z.B. per 'schlafe ein') oder unfreiwillig verlieren, gehen in den
+ Netztotenstatus ueber. Sie verbleiben noch eine definierte Zeit in
+ der zuletzt betretenen Umgebung und werden schliesslich automatisch
+ in den Netztotenraum ueberfuehrt.
+ Wird die Verbindung wieder aufgebaut, so wird der Spielercharakter
+ wieder zum Leben erweckt und gegebenenfalls zuvor aus dem
+ Netztotenraum zurueck zu seiner letzten Umgebung teleportiert.
+ Um nun einen Ueberblick darueber zu erhalten, wann ein Spieler die
+ Verbindung zum MUD wiederherstellt, gibt es die Funktion
+ BecomesNetAlive(). Sie wird automatisch in der Umgebung des
+ Spielers, in allen Objekten in der Umgebung des Spielers
+ (nicht rekursiv) und in allen Objekten im Spieler (rekursiv)
+ aufgerufen. Uebergeben wird hierbei das Spielerobjekt.
+
+ Es gibt auch noch die Funktion BecomesNetDead(), mit der man
+ auf aehnliche Weise einschlafende Spieler registrieren kann.
+
+BEISPIELE
+---------
+::
+
+ In einem NPC waere folgendes denkbar:
+
+
+
+ void BecomesNetAlive(object pl) {
+ tell_room(environment(),break_string(
+ "Guten Morgen "+pl->name(WER)+", auch schon ausgeschlafen?!", 77,
+ Name(WER)+" sagt grinsend: "));
+ }
+ Steht der NPC in einem Raum, wo ein Spieler aufwacht, so wird der
+ Spieler gebuehrend begruesst.
+
+SIEHE AUCH
+----------
+::
+
+ BecomesNetDead(), PlayerQuit(), /std/player/base.c, /room/netztot.c
+
+24. Aug 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/BecomesNetDead.rst b/doc/sphinx/lfun/BecomesNetDead.rst
new file mode 100644
index 0000000..4cd9042
--- /dev/null
+++ b/doc/sphinx/lfun/BecomesNetDead.rst
@@ -0,0 +1,67 @@
+BecomesNetDead()
+================
+
+FUNKTION
+--------
+::
+
+ void BecomesNetDead(object pl);
+
+GERUFEN VON
+-----------
+::
+
+ /std/player/base.c
+
+ARGUMENTE
+---------
+::
+
+ object pl
+ Spieler, der Verbindung zum MUD verliert.
+
+BESCHREIBUNG
+------------
+::
+
+ Spieler, welche die Verbindung zum MUD freiwillig
+ (z.B. per 'schlafe ein') oder unfreiwillig verlieren, gehen in den
+ Netztotenstatus ueber. Sie verbleiben noch eine definierte Zeit in
+ der zuletzt betretenen Umgebung und werden schliesslich automatisch
+ in den Netztotenraum ueberfuehrt.
+ Um nun einen Ueberblick darueber zu erhalten, wann ein Spieler die
+ Verbindung zum MUD verliert, gibt es die Funktion BecomesNetDead().
+ Sie wird automatisch in der Umgebung des Spielers, in allen Objekten
+ in der Umgebung des Spielers (nicht rekursiv) und in allen Objekten
+ im Spieler (rekursiv) aufgerufen. Uebergeben wird hierbei das
+ Spielerobjekt.
+
+ Es gibt auch noch die Funktion BecomesNetAlive(), mit der man
+ auf aehnliche Weise erwachende Spieler registrieren kann.
+
+BEISPIELE
+---------
+::
+
+ Es gibt Gebiete, in denen netztote Spieler unerwuenscht sind.
+ Folgendermassen kann man sich ihrer wirkungsvoll entledigen:
+
+
+
+ void BecomesNetDead(object pl) {
+ pl->move("eingangsraum zu gebiet", M_TPORT|M_NOCHECK);
+ }
+ Man schickt diese Spieler wieder zum Eingang des Gebietes.
+ Da der letzte Aufenthaltsort eines Spielers, der in den
+ Netztotenstatus uebergeht, erst nach Aufruf der Funktion
+ BecomesNetDead() abgespeichert wird, wacht der Spieler dann an dem
+ Ort auf, wo man Ihn innerhalb dieser Funktion hinteleportiert hat.
+
+SIEHE AUCH
+----------
+::
+
+ BecomesNetAlive(), PlayerQuit(), /std/player/base.c, /room/netztot.c
+
+24. Aug 2011, Gloinson
+
diff --git a/doc/sphinx/lfun/CannotSee.rst b/doc/sphinx/lfun/CannotSee.rst
new file mode 100644
index 0000000..b9fe25b
--- /dev/null
+++ b/doc/sphinx/lfun/CannotSee.rst
@@ -0,0 +1,50 @@
+CannotSee()
+===========
+
+FUNKTION
+--------
+::
+
+ varargs int CannotSee(int silent);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/light.c
+
+ARGUMENTE
+---------
+::
+
+ silent - Soll an das Lebewesen direkt automatisch eine Meldung
+ ausgegeben werden wenn es nichts sehen kann?
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion prueft ob das Lebewesen etwas sehen kann, oder nicht.
+ Hierbei wird sowohl das Lichtlevel mit saemtlichen Modifikatoren,
+ als auch Nachtsicht und die Property P_BLIND beruecksichtigt. Da
+ diese Funktion bei zukuenftigen Mudlibaenderungen immer aktualisiert
+ werden duerfte, sollte man sie nach Moeglichkeit benutzen und die
+ Abfragen nicht selbst implementieren.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn der Spieler etwas sehen kann
+ 1, wenn der Spieler nichts sehen kann: Blindheit
+ 2, wenn der Spieler nichts sehen kann: zu wenig Licht/keine Nachtsicht
+
+SIEHE AUCH
+----------
+::
+
+ P_BLIND, P_LIGHT_MODIFIER, P_PLAYER_LIGHT
+
+
+Last modified: Mon Jan 17 18:22:27 2000 by Padreic
+
diff --git a/doc/sphinx/lfun/ChangeMiniQuest.rst b/doc/sphinx/lfun/ChangeMiniQuest.rst
new file mode 100644
index 0000000..cf43274
--- /dev/null
+++ b/doc/sphinx/lfun/ChangeMiniQuest.rst
@@ -0,0 +1,72 @@
+ChangeMiniQuest()
+=================
+
+FUNKTION
+--------
+::
+
+ int ChangeMiniQuest(mixed questgeber, int parameter, mixed newvalue)
+
+DEFINIERT IN
+------------
+::
+
+ /secure/questmaster
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion aendert einen Parameter einer Miniquest im Questmaster,
+ schreibt fuer diese Aktion einen Log-Eintrag und erstellt das Miniquest-
+ Dumpfile neu.
+
+ARGUMENTE
+---------
+::
+
+ questgeber - Ladename des Objekts (string), das die Miniquest vergibt,
+ oderdie Indexnummer (int) der Miniquest in der MQ-Liste
+ parameter - Angabe des zu aendernen Parameters (Position des Values
+ im Miniquests-Mapping):
+ 0 : Miniquest-Stufenpunkte, mind. 1
+ 2 : Aufgabenbeschreibung der Miniquest (string)
+ 3 : Sichtbarkeit der Miniquest (0/1), default ist 1
+ 4 : aktiv/inaktiv (1/0)
+ 5 : Titel der Miniquest
+ 6 : "geschafft"-Beschreibung nach Abschluss der MQ
+ 7 : Voraussetzungen, Mapping im Format von P_RESTRICTIONS
+ 8 : zugeordnete Region, String wie z.B."polar", "gebirge"
+ 9 : erlaubte Abfrageobjekte, Array von Ladenamen, z.B.
+ ({"/d/region/magier/npc/infonpc"}), es koennen mehrere
+ Objekte eingetragen sein
+ newvalue - neuer Wert fuer den angegebenen Parameter
+
+RUECKGABEWERTE
+--------------
+::
+
+ 1: hat geklappt
+ 0: Zugriff verweigert
+ -2: ungueltiger Datentyp eines der Argumente, bei Parameter 9 wird
+ ein uebergebenes Array zusaetzlich auf Leerstrings und Elemente
+ geprueft, die keine Strings sind. Wenn das Array ausschliesslich
+ aus solchen Elementen besteht, wird ebenfalls -2 zurueckgegeben.
+
+BEMERKUNGEN
+-----------
+::
+
+ Das Flag "active" laesst sich bequemer ueber die Questmaster-Funktion
+ SwitchMiniQuestActive() umschalten.
+ Der Miniquest-Titel darf kein "in" oder "im" enthalten, weil dann die
+ Eintraege in der Fraternitas-Bibliothek nicht gelesen werden
+ koennen.
+
+SIEHE AUCH
+----------
+::
+
+ AddMiniQuest(L)
+ P_RESTRICTIONS
+
diff --git a/doc/sphinx/lfun/ChangeReputation.rst b/doc/sphinx/lfun/ChangeReputation.rst
new file mode 100644
index 0000000..362c33d
--- /dev/null
+++ b/doc/sphinx/lfun/ChangeReputation.rst
@@ -0,0 +1,72 @@
+ChangeReputation()
+==================
+
+FUNKTION
+--------
+::
+
+ public varargs int ChangeReputation(string repid, int value, int silent)
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/reputation.c
+
+ARGUMENTE
+---------
+::
+
+ repid
+ Jede neue Reputationsgruppe muss anfangs mit einer eindeutigen ID von
+ einem EM in den Reputationsmaster eingetragen werden. Danach kann man
+ ueber die eindeutige ID <repid> auf sie zugreifen.
+ value
+ Der Wert, um den die Reputation geaendert werden soll. Positive Werte
+ erhoehen die Reputation, negative verschlechtern sie.
+ silent
+ Ein optionales Flag. Falls gesetzt, wird keine Standardmeldung ueber
+ die Reputationsaenderung an den Spieler ausgegeben. Man koennte dann
+ eigene Meldungen ausgeben.
+
+BESCHREIBUNG
+------------
+::
+
+ Vor der Aenderung wird ein Check auf die UID des ausfuehrenden Objektes
+ ausgefuehrt, "fremde" Reputationen darf man somit nicht veraendern.
+ Man kann aber selbstverstaendlich in begruendeten Faellen mit dem
+ zustaendigen Magier/Regionsmagier sprechen, ob man ebenfalls Zugriff
+ erhaelt. Eingetragen wird dies schlussendlich durch einen EM.
+
+RUeCKGABEWERT
+-------------
+::
+
+ REP_RET_SUCCESS Reputation wurde veraender.
+ REP_RET_SUCCESSCUT Reputation wurde auf Min / Max veraendert
+ REP_RET_WRONGARGS Falsche Argumente fuer ChangeRep()
+ REP_RET_INVALIDUID Unzulaessige UID / keine Zugriffsrechte
+ REP_RET_ALREADYMAX Reputation bereits Max / Min
+ REP_RET_INACTIVE Reputation momentan inaktiv
+ REP_RET_INVALIDREP Reputation nicht vorhanden
+
+BEISPIELE
+---------
+::
+
+ s. reputation
+
+SIEHE AUCH
+----------
+::
+
+ reputation
+ GetReputation(), GetReputations()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+06.04.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/CheckFindRestrictions.rst b/doc/sphinx/lfun/CheckFindRestrictions.rst
new file mode 100644
index 0000000..2932eed
--- /dev/null
+++ b/doc/sphinx/lfun/CheckFindRestrictions.rst
@@ -0,0 +1,47 @@
+CheckFindRestrictions()
+=======================
+
+FUNKTION
+--------
+::
+
+ varargs int CheckFindRestrictions(object ob, mixed restr, closure qp)
+
+
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/shop.c
+
+
+
+ARGUMENTE
+---------
+::
+
+ ob - Objekt
+ restr - zusaetzliches Argument
+ qp - symbol_function("QueryProp",ob)
+
+BESCHREIBUNG
+------------
+::
+
+ Funktion, die FindBestWeapon / FindBestArmours einschraenkt.
+ Wird in Wert ungleich 0 zurueckgeliefert, so wird das Objekt
+ nicht genommen.
+
+RUECKGABEWERT
+-------------
+::
+
+ Normalerweise 0
+
+SIEHE AUCH
+----------
+::
+
+ FindBestWeapon(), FindBestArmours()
+
diff --git a/doc/sphinx/lfun/CheckLightType.rst b/doc/sphinx/lfun/CheckLightType.rst
new file mode 100644
index 0000000..eed5317
--- /dev/null
+++ b/doc/sphinx/lfun/CheckLightType.rst
@@ -0,0 +1,110 @@
+CheckLightType()
+================
+
+FUNKTION
+--------
+::
+
+ varargs int CheckLightType(int lighttype, int mode);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ lighttype
+ Auf diesen Lichttyp wird getestet.
+ mode
+ Die Methode, nach der der Lichttyp ueberprueft wird.
+
+BESCHREIBUNG
+------------
+::
+
+ Die Funktion prueft, ob der uebergebene lighttype mit dem in
+ P_LIGHT_TYPE definierten Lichttyp uebereinstimmt.
+
+ Dabei kann in verschiedenen Modi getestet werden:
+
+ LT_CHECK_ANY
+ Es wird geprueft, ob mindestens einer der in lighttype ueber
+ gebenen Lichttypen im Objekt vorhanden ist. Dies ist das
+ Standardverhalten (default) der Funktion.
+
+ LT_CHECK_ALL
+ Es wird geprueft, ob alle in lighttype definierten Lichttypen
+ vorhanden sind. Es koennen aber auch mehr Lichttypen definiert
+ sein.
+
+ LT_CHECK_MATCH
+ Es wird geprueft, ob genau die in lighttype definierten Licht-
+ tyen definiert sind, sind mehr oder weniger vorhanden, gibt die
+ Funktion 0 zurueck.
+
+ LT_CHECK_NONE
+ Es wird geprueft, ob keiner der uebergebenen Lichttypen vorhanden
+ sind. Ob sonst noch andere Lichttypen vorhanden sind, ist dabei
+ egal.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0 wenn die geprueften Bedingungen nicht korrekt sind, sonst
+ ein Wert ungleich 0.
+
+BEISPIELE
+---------
+::
+
+ In einem Raum scheint die Sonne, ausserdem gibt es dort ein Lager-
+ feuer und ein Objekt mit magischem Gluehen (meine Phantasie streikt
+ grad):
+
+ raum->SetProp( P_LIGHT_TYPE, LT_SUN|LT_OPEN_FIRE|LT_GLOWING );
+
+ Es soll getestet werden, ob an in dem Raum Tageslicht herrscht:
+
+ raum->CheckLightType(LT_DAYLIGHT, LT_CHECK_ANY);
+ raum->CheckLightType(LT_DAYLIGHT); // gleichwertig
+
+ Die Funktion ergibt wahr, da LT_DAYLIGHT unter anderem LT_SUN ent-
+ haelt (vgl man P_LIGHT_TYPES).
+
+ Es soll getestet werden, dass weder Mond noch Sterne im Raum sind:
+
+ raum->CheckLightType(LT_MOON|LT_STARS, LT_CHECK_NONE);
+
+ Die Funktion ergibt wahr, da die beiden nicht gesetzt sind.
+
+ Es soll geprueft werden, ob Mond und Sterne im Raum leuchten:
+
+ raum->CheckLightType(LT_MOON|LT_STARS, LT_CHECK_ALL);
+
+ Die Funktion ergibt falsch, da keins der beiden Lichter vorhanden
+ ist. Sie ergaebe aber auch falsch, wenn einer der beiden Typen
+ vorhanden waer. Nur wenn beide vorhanden sind, gibt LT_CHECK_ALL
+ wahr.
+
+BEMERKUNG
+---------
+::
+
+ Lighttypes haben nichts mit dem Lichtsystem zu tun. Sie dienen
+ nur der Beschreibung der Lichtverhaeltnisse an/in einem Objekt.
+ Objekte mit verschiedenen Lichtverhaeltnissen beeinflussen sich
+ gegenseitig nicht.
+
+SIEHE AUCH
+----------
+::
+
+ /std/thing/description.c, /std/thing/lighttypes.h, P_LIGHT_TYPE
+
+Last modified: Fri Jun 11 20:47:33 2004 by Vanion
+
diff --git a/doc/sphinx/lfun/CheckResistance.rst b/doc/sphinx/lfun/CheckResistance.rst
new file mode 100644
index 0000000..7254068
--- /dev/null
+++ b/doc/sphinx/lfun/CheckResistance.rst
@@ -0,0 +1,37 @@
+CheckResistance()
+=================
+
+FUNKTION
+--------
+::
+
+ CheckRessistance(string* dam_type_list)
+
+ARGUMENTE
+---------
+::
+
+ dam_type_list: Liste der Schadensarten, die geprueft werden
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion ueberprueft, gegen welche der angegebenen
+ Schadensarten das Lebewesen resistent oder verletzlich ist und
+ gibt einen Faktor zurueck, der mit dem Schaden multipliziert wird.
+ Dieser Faktor betraegt normalerweise 1, bei bei jeder Resistenz
+ wird er halbiert und bei jeder Verletzlichkeit verdoppelt.
+
+RUECKGABEWERT
+-------------
+::
+
+ Ein Faktor, der mit dem Schaden multipliziert wird, vom Typ "float".
+
+SIEHE AUCH
+----------
+::
+
+ "Defend"
+
diff --git a/doc/sphinx/lfun/CheckSensitiveAttack.rst b/doc/sphinx/lfun/CheckSensitiveAttack.rst
new file mode 100644
index 0000000..7c971d3
--- /dev/null
+++ b/doc/sphinx/lfun/CheckSensitiveAttack.rst
@@ -0,0 +1,54 @@
+CheckSensitiveAttack()
+======================
+
+FUNKTION
+--------
+::
+
+ void CheckSensitiveAttack(int dam, string *dam_type, mixed spell,
+ object enemy)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/inventory.c
+
+ARGUMENTE
+---------
+::
+
+ dam - an Defend uebergebener Schaden
+ dam_type - Schadenstyp(en)
+ spell - spell, int oder mapping
+ enemy - Feindesobjekt
+
+BESCHREIBUNG
+------------
+::
+
+ Wird von Defend() aufgerufen und prueft die Listen in
+ P_SENSITIVE_ATTACK durch.
+ Wenn die Schluessel und Threshold-Werte stimmen, wird
+ trigger_sensitive_attack(enemy,key,dam,spell,options)
+ im Objekt gerufen.
+
+BEMERKUNGEN
+-----------
+::
+
+ Objekte mit P_SENSITIVE mit Schluessel SENSITIVE_ATTACK bitte vorsichtig
+ verwenden, da rechenintensiv.
+
+SIEHE AUCH
+----------
+::
+
+ P_SENSITIVE
+ InsertSensitiveObject, RemoveSensitiveObject
+ insert_sensitive_inv_trigger, insert_sensitive_inv
+ P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY,
+ P_SENSITIVE_INVENTORY_TRIGGER
+
+28.Jan.2001, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/CheckSpellFatigue.rst b/doc/sphinx/lfun/CheckSpellFatigue.rst
new file mode 100644
index 0000000..26a9f6c
--- /dev/null
+++ b/doc/sphinx/lfun/CheckSpellFatigue.rst
@@ -0,0 +1,86 @@
+CheckSpellFatigue()
+===================
+
+FUNKTION
+--------
+::
+
+ public varargs int CheckSpellFatigue(string key)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skills.c
+ /std/player/skills.c
+ /sys/living/skills.h
+
+ARGUMENTE
+---------
+::
+
+ string key : Eindeutiger Name des Spruches, einer Gruppe von Spruechen
+ oder 0 fuer die globale Spruchermuedung.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion dient zum Pruefen von individuellen Spruchermuedungen
+ (Spellfatigue, Spruchsperren).
+ Hiermit lassen sich unabhaengige Ermuedungen/Sperren fuer einzelne
+ Sprueche oder Gruppen von Spruechen gestalten.
+
+ Wird <key> nicht angegeben oder ist 0, wird die globale Spruchsperre
+ geprueft (identisch zu der Property P_NEXT_SPELL_TIME), anderenfalls
+ die unter <key> gespeicherte Spruchermuedung.
+ Prueft man einen Eintrag ohne Angabe von <key> ist das Ergebnis dieser
+ Funktion identisch zur Abfrage von P_NEXT_SPELL_TIME.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0 Spruchermuedung existiert nicht oder ist abgelaufen.
+
+ >0 Spruchermuedung ist noch nicht abgelaufen, Rueckgabewert ist die
+ Zeit, bei der dieser Eintrag ablaeuft. Der Spruch darf _nicht_
+ ausgefuehrt werden.
+
+BEISPIELE
+---------
+::
+
+ Ein Spell gehoert zu einer Gruppe von Spells mit dem Namen 'extrasuess'.
+ Er darf nur ausgefuehrt werden, wenn seit 5s kein anderer Spruch aus der
+ Gruppe ausgefuehrt wurde.
+ if (ob->CheckSpellFatigue("extrasuess") {
+ // alte Sperre noch nicht abgelaufen.
+ tell_object(ob, "Deine unendliche Schokotorte ist noch nicht wieder "
+ "nachgewachsen.\n");
+ return ... ;
+ }
+
+BEMERKUNGEN
+-----------
+::
+
+ Die genauen Zeitdauern koennen von Spielern beeinflusst werden, sie
+ unterliegen der jeweiligen Einstellung von 'spruchermuedung', d.h. koennen
+ auf volle 2s aufgerundet werden.
+ Auch wenn diese Funktion zum Verwalten von beliebigen Zeitsperren genutzt
+ werden koennen, beschraenkt euch bitte auf Spruchermuedungen und benutzt
+ ansonsten check_and_update_timed_key(). Falls ihr diesbzgl. weitere/andere
+ Wuensche habt, sprecht den/die Mudlib-EM an.
+
+SIEHE AUCH
+----------
+::
+
+ SetSpellFatigue(L), DeleteSpellFatigue(L)
+ P_NEXT_SPELL_TIME
+ spruchermuedung
+
+
+27.03.2010, Zesstra
+
diff --git a/doc/sphinx/lfun/ClearRingBuffer.rst b/doc/sphinx/lfun/ClearRingBuffer.rst
new file mode 100644
index 0000000..e7beddc
--- /dev/null
+++ b/doc/sphinx/lfun/ClearRingBuffer.rst
@@ -0,0 +1,58 @@
+ClearRingBuffer()
+=================
+
+FUNKTION
+--------
+::
+
+ protected struct std_ringbuffer ClearRingBuffer(struct std_ringbuffer b);
+
+DEFINIERT IN
+------------
+::
+
+ /std/util/ringbuffer.c
+ /sys/util/ringbuffer.h
+
+ARGUMENTE
+---------
+::
+
+ b - der zu loeschende Ringpuffer
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion loescht alle Daten aus dem Puffer <b> und re-initialisiert
+ ihn.
+
+
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der geloeschte Puffer <b> wird wieder zurueckgegeben.
+
+BEISPIELE
+---------
+::
+
+ // Ringpuffer anlegen:
+ struct std_ringbuffer buffer=CreateRingBuffer(10, MODE_FIFO);
+ // mit irgendwelchen Daten fuellen...
+ // ...
+ // Puffer loeschen
+ buffer = ClearRingBuffer(buffer);
+ // oder:
+ ClearRingBuffer(buffer);
+
+SIEHE AUCH
+----------
+::
+
+ CreateRingBuffer(), RingBufferGet(), ResizeRingBuffer()
+
+23.05.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/Configure.rst b/doc/sphinx/lfun/Configure.rst
new file mode 100644
index 0000000..6d0758b
--- /dev/null
+++ b/doc/sphinx/lfun/Configure.rst
@@ -0,0 +1,104 @@
+Configure()
+===========
+
+Configure()
+
+ public mixed Configure(mixed data)
+-------------------------------------------------
+::
+
+DEFINIERT IN
+------------
+::
+
+ Beliebigen Objekten
+
+ARGUMENTE
+---------
+::
+
+ <data>
+ 0 fuer Datenabfrage
+ beliebige Daten, die ein Configure(0) vorher lieferte
+
+BESCHREIBUNG
+------------
+::
+
+ Viele Objekte werden fuer bestimmte Spieler konfiguriert und so
+ personalisiert. Sie enthalten zusaetzlich zu den Daten, welche waehrend des
+ create() gesetzt wurden, noch weitere spieler-individuelle Daten.
+ Damit diese Objekte im Bedarfsfall neu erstellt werden koennen, sollte ein
+ geeignetes Configure() definfiert werden, um diese Daten abzurufen und in
+ einem neuen Clone (oder neugeladener Blueprint) wieder zu setzen.
+
+
+
+ Existiert Configure() im Objekt, MUSS dieses bei einem Aufruf mit
+ <data>==0 (d.h. Configure(0)) alle individuellen Daten zurueckliefern,
+ die noetig sind, um den aktuellen Zustand des Objektes spaeter
+ wiederherzustellen.
+ Das Objekt darf nach dem Zurueckgeben dieser Daten diese NICHT mehr
+ veraendern, d.h. es muss ggf. eine Kopie erstellt werden (copy, deep_copy)
+
+ Genau diese Daten werden in einem neu geclonten Objekt durch den Aufruf
+ von Configure(data) wieder gesetzt. Das Configure MUSS genau die Daten, die
+ es im alten Objekt zurueckliefert, wieder akzeptieren.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Wenn <data>==0:
+ Alle individuellen Daten in einer beliebigen Form. Ein Mapping bietet
+ sich jedoch an.
+ Nicht erlaubt sind: Objekte und Closures.
+
+ Wenn <data>!=0:
+ 1, wenn die Daten zur Konfiguration akzeptiert wurden.
+ 0, sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+ Configure() ist nicht verpflichtet, erneut Daten zu akzeptieren, wenn es
+ bereits einmal mit gueltigen Daten aufgerufen wurde.
+ Das Zurueckschreiben der Daten kann auch nach Ablauf laengerer Zeit
+ und/oder in einer anderen Uptime erfolgen.
+
+BEISPIELE
+---------
+::
+
+ Ein Objekt, welches ein anderes Objekt sicher ersetzt, d.h. die
+ individuelle Konfiguration bleibt erhalten:
+ mixed data;
+ if (call_resolved(data,ob,"Configure",0) == 1) {
+ string obname = load_name(ob);
+ ob->remove();
+ ob = clone_object(obname);
+ if (data) {
+ if (ob->Configure(data) == 1) {
+ printf("Instanz von %s erfolgreich ersetzt, neues Objekt: %O\n",
+ obname,ob);
+ }
+ else {
+ raise_error(sprintf("Configure() in %O akzeptierte Daten nicht!\n",
+ ob));
+ }
+ }
+ }
+ else {
+ printf(break_string(
+ "Das Objekt %O definiert keine Funktion Configure(). Es kann "
+ "nicht sicher ersetzt werden, da unbekannt ist, ob es individuelle "
+ "Daten enthaelt.",78));
+ }
+
+LETZTE AeNDERUNG
+----------------
+::
+
+26.09.2011, Zesstra
+
diff --git a/doc/sphinx/lfun/ConvMaterialList.rst b/doc/sphinx/lfun/ConvMaterialList.rst
new file mode 100644
index 0000000..0ca9b1a
--- /dev/null
+++ b/doc/sphinx/lfun/ConvMaterialList.rst
@@ -0,0 +1,65 @@
+ConvMaterialList()
+==================
+
+FUNKTION
+--------
+::
+
+ varargs string ConvMaterialList(mixed mats, int casus, mixed idinf)
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/materialdb.c (MATERIALDB)
+
+ARGUMENTE
+---------
+::
+
+ mixed mats: - das zu erkennende Material:
+ - ein Mapping, ein String oder ein Stringarray
+ ([MAT_A:y,MAT_B:x,..]) oder MAT_A oder ({MAT_A,MAT_B,..})
+ int casus: - der Fall: 0..3 -> <language.h>: WAS, WESSEN, WEM, WEN
+ mixed idinf - Dinge, welche die Faehigkeiten des Erkennens beeinflussen
+ (siehe "man MaterialList")
+
+BESCHREIBUNG
+------------
+::
+
+ Man uebergibt ConvMaterialList() eine Liste von Materialien, die die
+ Funktion unter Verwendung von MaterialName() in ihre Bestandteile
+ aufsplittet und mit "und" und "," verknuepft zurueckgibt.
+
+RUECKGABEWERT
+-------------
+::
+
+ string - Materialien, durch Komma und "und" getrennt oder
+ "unbekanntes Material"
+
+BEMERKUNGEN
+-----------
+::
+
+ Wird von /std/thing/description::MaterialList() gerufen.
+ Bitte an Objekten auch MaterialList() verwenden.
+ Ruft direkt MaterialName() auf.
+
+SIEHE AUCH
+----------
+::
+
+ Konzepte: material, materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Methoden: QueryMaterial(), QueryMaterialGroup(), MaterialList(),
+ Listen: AllMaterials(), AllGroups(), Dump()
+ materialliste, materialgruppen
+ Master: AddMaterial(), MaterialGroup(),
+ GroupName(), MaterialName(),
+ GetGroupMembers(), GetMatMembership()
+ Sonstiges: P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/CreateRingBuffer.rst b/doc/sphinx/lfun/CreateRingBuffer.rst
new file mode 100644
index 0000000..e59fe62
--- /dev/null
+++ b/doc/sphinx/lfun/CreateRingBuffer.rst
@@ -0,0 +1,70 @@
+CreateRingBuffer()
+==================
+
+FUNKTION
+--------
+::
+
+ protected struct std_ringbuffer CreateRingBuffer(int size, int newmode);
+
+DEFINIERT IN
+------------
+::
+
+ /std/util/ringbuffer.c
+ /sys/util/ringbuffer.h
+
+ARGUMENTE
+---------
+::
+
+ size - Groesse des neuen Ringpuffers (int)
+ newmode - Ausgabemodus beim Abrufen des Puffers (int):
+ MODE_FIFO: First-in-First-Out
+ MODE_LIFO: Last-in-First-Out
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion erstellt einen neuen, leeren Ringpuffer der Groesse <size>
+ und liefert ihn zurueck. Die Daten des Puffers werden spaeter gemaess
+ <newmode> so gespeichert, dass bei der Ausgabe des Puffers mittels
+ RingBufferGet() die entweder die neuesten Daten zuerst (MODE_LIFO) oder
+ die aeltesten Daten zuerst (MODE_FIFO) geliefert werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der neue Ringpuffer. Dieser wird in einer Struct std_ringbuffer
+ gespeichert. Er ist in einer Variable 'mixed' oder in einer mittels
+ 'struct std_ringbuffer' angelegten Variable speicherbar.
+
+BEMERKUNGEN
+-----------
+::
+
+ Der gelieferte Ringpuffer sollte nicht per Hand verarbeitet oder
+ genaendert werden, sondern nur ueber die Verwaltungsfunktionen aus
+ /std/util/ringbuffer.c.
+
+BEISPIELE
+---------
+::
+
+ // Variable anlegen:
+ struct std_ringbuffer buffer;
+ // _oder_: mixed buffer;
+ // neuen Puffer mit max. 50 Elementen anlegen, der bei der Abfrage die
+ // aeltesten Daten zuerst zurueckliefert:
+ buffer = CreateRingBuffer(50, MODE_FIFO);
+
+SIEHE AUCH
+----------
+::
+
+ RingBufferPut(), RingBufferGet(), ResizeRingBuffer()
+
+23.05.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/CustomizeObject.rst b/doc/sphinx/lfun/CustomizeObject.rst
new file mode 100644
index 0000000..f6e0665
--- /dev/null
+++ b/doc/sphinx/lfun/CustomizeObject.rst
@@ -0,0 +1,84 @@
+CustomizeObject()
+=================
+
+FUNKTION
+--------
+::
+
+ string CustomizeObject();
+
+DEFINIERT IN
+------------
+::
+
+ /std/virtual/v_compiler.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+RUeCKGABEWERT
+-------------
+::
+
+ Den Objektnamen, den das zuletzt erzeugte Objekt (welches gerade die
+ Funktion aufruft) spaeter vom Driver bekommen wird.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion ist aus dem Grunde da, da zum Zeitpunkt des Clonens des
+ VC-Objektes (P_STD_OBJECT) dieses Objekt ja noch nicht weiss Wer
+ oder Was es spaeter mal sein wird.
+ Deshalb kann dieses VC-Objekt im create() (und nur da!) die Funktion
+ CustomizeObject() in dem virtual_compiler aufrufen, welches das Objekt
+ geclont hat und bekommt von diesem den Objektnamen zureck, welches es
+ spaeter mal bekommen wird.
+ Da das VC-Objekt vom VC geclont wurde, ist previous_object() im create()
+ des VC-Objektes der VC, in dem man CustomizeObject() ruft.
+
+BEMERKUNGEN
+-----------
+::
+
+ Das CustomizeObject() im Standard-VC gibt nur den zukuenftigen Objektnamen
+ zurueck und macht sonst nix.
+
+BEISPIELE
+---------
+::
+
+ create() eines VC-Objektes:
+
+
+
+ protected void create() {
+ ...
+
+
+
+ // wer bin ich denn eigentlich?
+ string myname = previous_object()->CustomizeObject();
+ switch(myname) {
+ // Kram konfigurier, ja nach myname...
+ }
+
+
+
+ ...
+ }
+
+SIEHE AUCH
+----------
+::
+
+ virtual_compiler
+ CustomizeObject(), Validate(), NoParaObjects(),
+ P_COMPILER_PATH, P_PARA
+ /std/virtual/v_compiler.c
+
+21.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/Damage.rst b/doc/sphinx/lfun/Damage.rst
new file mode 100644
index 0000000..345a888
--- /dev/null
+++ b/doc/sphinx/lfun/Damage.rst
@@ -0,0 +1,57 @@
+Damage()
+========
+
+FUNKTION
+--------
+::
+
+ int Damage(int dam);
+
+DEFINIERT IN
+------------
+::
+
+ /std/armour/combat.c und
+ /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+ dam Der Wert, mit dem die Waffe/Ruestung beschaedig werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ P_WC bzw. P_AC wird um dam reduziert und P_DAMAGED wird um
+ dam erhoeht.
+ Bei dam>0 wird das Objekt beschaedigt, bei dam<0 repariert.
+ Dabei werden sowohl die Obergrenzen (s. /sys/combat.h) wie auch
+ die Untergrenzen (Waffen:30, Ruestungen: 0) fuer P_WC und P_AC
+ beachtet. Es kann auch nicht mehr repariert werden, als vorher
+ beschaedigt wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der Wert der Beschaedigung, die tatsaechlich vorgenommen wurde.
+
+BEMERKUNGEN
+-----------
+::
+
+ Ist das Objekt in Benutzung, setzt die Funktion Damage automatisch
+ die Properties P_TOTAL_WC bzw. P_TOTAL_AC in dem benutzenden Spieler
+ auf die richtigen Werte.
+
+SIEHE AUCH
+----------
+::
+
+ /std/armour/combat.c, /std/weapon/combat.c
+
+
+Last modified: Thu May 22 10:13:23 1997 by Paracelsus
+
diff --git a/doc/sphinx/lfun/DeAssocMember.rst b/doc/sphinx/lfun/DeAssocMember.rst
new file mode 100644
index 0000000..b43ed68
--- /dev/null
+++ b/doc/sphinx/lfun/DeAssocMember.rst
@@ -0,0 +1,72 @@
+DeAssocMember()
+===============
+
+FUNKTION
+--------
+::
+
+ int DeAssocMember(object npc)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ Der NPC, der nicht mehr zugeordnet sein soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Hebt die Zuordnung eines NPCs zu einem Spieler auf.
+
+RUECKGABEWERT
+-------------
+::
+
+ 1, falls Aufhebung erfolgreich, sonst 0.
+
+BEISPIEL
+--------
+::
+
+ void fun(object pl)
+ {
+ if ( pl && pl->DeAssocMember(this_object()) )
+ tell_object(pl,break_string(
+ "Ich kaempfe nun nicht mehr auf Deiner Seite!\n",78,
+ "Ein Feuerteufel teilt Dir mit:");
+ ...
+ }
+
+BEMERKUNGEN
+-----------
+::
+
+ Kann nur von Gilden, Spellbooks, vom Objekt selber und vom
+ zugeordneten NPC aufgerufen werden.
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: AssocMember, InsertEnemyTeam, SelectNearEnemy,
+ SelectFarEnemy
+ Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+ PresentTeamPosition, SwapRows
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/DeclAdj.rst b/doc/sphinx/lfun/DeclAdj.rst
new file mode 100644
index 0000000..5c250ae
--- /dev/null
+++ b/doc/sphinx/lfun/DeclAdj.rst
@@ -0,0 +1,69 @@
+DeclAdj()
+=========
+
+FUNKTION
+--------
+::
+
+ varargs string DeclAdj( string adj, int casus, int demon);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+ adj
+ Das zu deklinierende Adjektiv.
+
+ casus
+ Der Fall, in den es dekliniert werden soll.
+
+ demon
+ Bezieht sich das Adjektiv auf einen bestimmten oder einen
+ unbestimmten Gegenstand?
+
+BESCHREIBUNG
+------------
+::
+
+ Dekliniert das uebergebene Adjektiv in den angegebenen Fall. Ist demon
+ ungleich Null, so wird das Adjektiv so behandelt, als wuerde es sich
+ auf einen bestimmten Gegenstand beziehen, ansonsten bezieht es sich auf
+ einen unbestimmten Gegenstand.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Das deklinierte Adjektiv. Es wird zusaetzlich noch ein Leerzeichen
+ hinten angefuegt!
+
+BEISPIELE
+---------
+::
+
+ Zunaechst ein bestimmtes Adjektiv:
+
+ printf("Der %sBall.\n", ball->DeclAdj("gruen", WER, 1);
+
+ Nun ein unbestimmtes Adjektiv:
+
+ printf("Ein %sBall.\n", ball->DeclAdj("gruen", WER, 0);
+
+ Da DeclAdj() "gruene " bzw. "gruener " zurueckgibt, darf zwischen dem
+ "%s" und dem "Ball" kein Leerzeichen stehen!
+
+SIEHE AUCH
+----------
+::
+
+ /std/thing/language.c
+
+
+Last modified: Wed May 8 10:18:05 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/Defend.rst b/doc/sphinx/lfun/Defend.rst
new file mode 100644
index 0000000..71f76d6
--- /dev/null
+++ b/doc/sphinx/lfun/Defend.rst
@@ -0,0 +1,174 @@
+Defend()
+========
+
+FUNKTION
+--------
+::
+
+ public int Defend(int dam, string|string* dam_type, int|mapping spell,
+ object enemy)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat
+
+ARGUMENTE
+---------
+::
+
+ int dam initiale Staerke des Angriffs (10 dam ~ 1 HP)
+ string* dam_type Art(en) des Schadens, der angerichtet werden
+ soll
+ Muss ein Array von Schadenstypen sein,
+ alte Objekte uebergeben hier manchmal strings.
+ int/mapping spell - 0 fuer normale Angriffe (keine Zauber)
+ - 1 fuer Zauber (Standardruestungen ignorieren)
+ - mapping fuer mehr Informationen
+ Heute bitte nach Moeglichkeit ein Mapping
+ uebergeben.
+ object enemy der Feind/Schadenverursacher
+
+BESCHREIBUNG
+------------
+::
+
+ 1. Generell
+ Wenn das Lebewesen angegriffen wird, wird geprueft, wie stark die
+ Ruestungen und koerpereigenen Abwehrkraefte sind und die Staerke des
+ Schadens dementsprechend vermindert.
+ Ggf. wird der Schaden zugefuegt und der Feind in die Liste der Feinde
+ aufgenommen. Der Schaden betraegt:
+ (dam-Summe(Ruestungsstaerken)-random(P_BODY+A_DEX))*CheckResistance/10
+ aber nicht unter 0.
+
+ 2. Der Parameter 'spell'
+ Ist 'spell' 0, dann gilt der Angriff als normale physische Attacke
+ Uebergibt man als 'spell'-Parameter ein Mapping, so gibt es dafuer
+ diverse Flags, die das Ergebnis manipulieren (in new_skills.h
+ enthalten). Nichtangabe eines Flags gilt als 0.
+
+ - SP_PHYSICAL_ATTACK ---------- 0/1
+ 1, wenn Ruestungen wirken sollen, 0 sonst
+ -> entspricht !spell, wenn dieses Int ist
+ - SP_NO_ENEMY ----------------- 0/1
+ 1, falls der Angriff nicht toedlich ist, es also keinen echten
+ Gegner gibt
+ -> es wird dann reduce_hit_points() gerufen statt do_damage()
+ - SP_NO_ACTIVE_DEFENSE -------- 0/1
+ 1, falls aktive Abwehren (wie zurueckschlagende Amulette,
+ Karateabwehren oder Ausweichmanoever) unterbleiben sollen
+ -> zB bei Kratzen durch Dornen oder Fall aus grosser Hoehe
+ ist aktive Abwehr oder Ausweichen unlogisch
+ - SP_RECURSIVE ---------------- 0/1
+ 1, falls der Spell aus einem Defend gerufen wurde (oder einer
+ DefendFunc)
+ -> verhindert Rekursionsprobleme
+ - SP_NAME --------------------- string
+ Name des Spells
+ - SP_REDUCE_ARMOUR ------------ Mapping: keys AT_X/P_BODY, values int>=0
+ Die Schutzwirkung durch P_AC/Magie einer Ruestung wird
+ typabhaengig reduziert. Aufbau eines Mappings im Beispiel:
+ ([AT_BOOTS: 0, // Stiefel schuetzen gar nicht
+ P_BODY: 50, // Koerper zu 50%
+ AT_BELT: 600 // Guertel zu 600%
+ ])
+ -> alle 'fehlenden' Eintraege wirken normal
+ - SP_SHOW_DAMAGE -------------- 0/1 oder Array von Arrays
+ 0, fuer keine Treffermeldung, 1 sonst
+ In einem Array koennen Ersatz-Treffermeldungen definiert
+ werden. Format ist:
+ ({
+ ({ int lphit1, string mess_me,
+ string mess_en,
+ string mess_room }),
+ ({ lphit2, mess_me, mess_en, mess_room }),
+ ...
+ ({ lphitn, mess_me, mess_en, mess_room }),
+ })
+ wobei lphit1<lphit2<...<lphitn sein muss, d.h. das Array-
+ Array aufsteigend sortiert.
+
+ Ist ein Treffer x LP hart, werden die Meldungen des lphit-
+ Arrays ausgegeben, dessen Wert am naehesten unter dem Schaden
+ liegt.
+
+ In den Meldungen mess_me (an den Getroffenen), mess_en (an
+ den Feind), mess_room (an die restlichen Umstehenden) koennen
+ Ersatzstrings wie folgt verwendet werden:
+ @WER1/@WESSEN1/@WEM1/@WEN1 - name(casus) des Getroffenen (TO)
+ @WER2/@WESSEN2/@WEM2/@WEN2 - name(casus) des Feindes (enemy)
+ - EINFO_DEFEND ------------ Mapping
+ Dieses Mapping liefert erweiterte Informationen zu dem
+ bisherigen Ablauf des aktiven Attacks.
+ Die verfuegbaren Informationen sind in der Manpage zu
+ DefendInfo festgehalten.
+
+ 3. Reihenfolgen in Defend
+ - das Living wird angegriffen, wenn
+ - P_NO_ATTACK != 0
+ - 'enemy' existiert und kein netztoter Spieler ist
+ - P_DEFENDERS werden durchgegangen (und eventuell benachrichtigt)
+ - P_TMP_ATTACK_HOOK wird abgefragt
+ - die Ruestungen werden vom Schaden gegebenenfalls abgezogen
+ - magischer Ausweichskill beruecksichtigt
+ - sensitive Objekte werden ggf. benachrichtigt
+ - InternalModifyDefend wird gerufen
+ - Koerperabwehr abgezogen
+ - der Schaden an do_damage()/reduce_hit_points() uebergeben
+ - Flucht ueberpruefen mit CheckWimpyAndFlee()
+
+BEMERKUNGEN
+-----------
+::
+
+ Ruestungen wirken konventionell nur, wenn mindestens ein Schadensanteil
+ mechanisch ist und es kein Spell oder ein Spell mit SP_PHYSICAL_ATTACK
+ auf 1 ist.
+
+ Defend() beruecksichtigt magische Verteidigungen, die der Spieler bei
+ sich hat, sollte also aus Fairness gegenueber den Objekten anderer
+ Magier immer dem direkten reduce_hit_points() oder do_damage()
+ vorgezogen werden. Mittels der Flags in 'spell' kann man sehr viel
+ aendern.
+
+RUECKGABEWERT
+-------------
+::
+
+ Hoehe des tatsaechlichen Schadens. Dies kann mehr sein als die
+ Lebenspunkte des Lebewesens.
+
+BEISPIELE (SIEHE AUCH Defend_bsp):
+ // ein simpler Angriff:
+ enem->Defend(100, ({DT_BLUDGEON}), 0, this_object());
+
+ // ein magischer Angriff (ohne Treffermeldung):
+ enem->Defend(100, ({DT_BLUDGEON, DT_FIRE}), 1, this_object());
+
+ // ein magischer Angriff mit Treffermeldung:
+ enem->Defend(100, ({DT_BLUDGEON, DT_FIRE}), ([SP_SHOW_DAMAGE:1]),
+ this_object());
+
+SIEHE AUCH
+----------
+::
+
+ Angriff: Attack(L), P_NO_ATTACK, InsertEnemy(L)
+ Schaden: P_ENABLE_IN_ATTACK_OUT, P_LAST_MOVE,
+ do_damage(L), reduce_hit_points(L)
+ Schutz: P_DEFENDERS, InformDefend(L), DefendOther(L)
+ P_ARMOURS, P_AC, P_DEFEND_FUNC, QueryDefend(L)
+ P_BODY, A_DEX
+ Daten: P_LAST_COMBAT_TIME
+ P_LAST_DAMTYPES, P_LAST_DAMTIME, P_LAST_DAMAGE
+ P_DAMAGE_MSG
+ Resistenz: P_RESISTANCE_STRENGTHS, CheckResistance(L)
+ Sonstiges: CheckSensitiveAttack(L)
+ InternalModifyDefend(L)
+ UseSkill(L),
+ DefendInfo
+
+15.09.2010, Zesstra
+
diff --git a/doc/sphinx/lfun/DefendFunc.rst b/doc/sphinx/lfun/DefendFunc.rst
new file mode 100644
index 0000000..790505a
--- /dev/null
+++ b/doc/sphinx/lfun/DefendFunc.rst
@@ -0,0 +1,108 @@
+DefendFunc()
+============
+
+DefendFunc(L)
+-------------
+::
+
+FUNKTION
+--------
+::
+
+ int DefendFunc(string|string *dtyp, int|mappingspell, object enemy);
+
+DEFINIERT IN
+------------
+::
+
+ eigenen Objekten; fuer /std/armour/combat.c
+
+ARGUMENTE
+---------
+::
+
+ dtyp
+ Schadenstypen der Angriffsart.
+ Sollte heute ein string* sein.
+ spell
+ 0 bei veralteten konventionellen Angriffen im Regelfall jedoch
+ ein Mapping mit weiteren Infos.
+ Bei einem konventionellen Angriff ist spell[SP_PHYSICAL_ATTACK] gleich
+ 1.
+ enemy
+ Der angreifende Gegner
+
+BESCHREIBUNG
+------------
+::
+
+ Anhand der uebergebenen Parameter kann hier ein Ruestungsbonus (oder
+ auch ein Ruestungsmalus) errechnet werden, der zu dem normalen
+ Ruestungswert (abhaengig von der Angriffsart) hinzuaddiert wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der Ruestungsbonus, der zur Ruestungsklasse addiert werden soll.
+
+BEMERKUNGEN
+-----------
+::
+
+ Auch wenn man eine DefendFunc() benutzt, darf der Rueckgabewert
+ zusammen mit der P_AC insgesamt nur in sehr seltenen, wohldurch-
+ dachten Ausnahmefaellen die maximal zulaessige P_AC fuer diesen
+ Ruestungstyp ueberschreiten. In solchen Ausnahmefaellen duerfen
+ die DefendFuncs nicht konstant wirken.
+
+ Bei aktivem Zurueckschlagen IMMER auf Flags wie SP_RECURSIVE und
+ SP_NO_ACTIVE_DEFENSE pruefen und ggf. abbrechen.
+
+BEISPIELE
+---------
+::
+
+ Eine Ruestung, die bei Angriffen mit Feuer ihre volle Staerke entfaltet
+ und bei Angriffen durch Geister geschwaecht wird:
+
+ void create()
+ {
+ ::create();
+
+ SetProp(P_ARMOUR_TYPE, AT_ARMOUR);
+ SetProp(P_AC, 20);
+ ...
+ // Die DefendFunc() ist in der Ruestung selbst definiert
+ SetProp(P_DEFEND_FUNC, this_object());
+ }
+
+ int DefendFunc(string *dtyp, mixed spell, object enemy)
+ {
+ int prot;
+
+ // Zuerst fragen wir den Angriff durch Feuer ab:
+ if (member(dtyp, DT_FIRE) >= 0) // Feuer gehoert zu den Schadenstypen
+ prot = 5 + random(10); // Das ergibt maximal 14. Zusammen mit P_AC
+ // kommt man also maximal auf 14+20 = 34,
+ // liegt also unter der fuer AT_ARMOUR
+ // geltenden Obergrenze
+
+ // Und jetzt der Geistertest
+ if (enemy->QueryProp(P_RACE) == "Geist" ||
+ enemy->is_class_member(CL_GHOST))
+ prot -= random(10);
+
+ // Der Rueckgabewert wird auf den aus P_AC errechneten Wert draufgeschlagen
+ return prot;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ P_DEFEND_FUNC, QueryDefend(), /std/armour/combat.c
+
+
+Last modified: 18.Jul 2006 Muadib
+
diff --git a/doc/sphinx/lfun/DefendInfo.rst b/doc/sphinx/lfun/DefendInfo.rst
new file mode 100644
index 0000000..5067cac
--- /dev/null
+++ b/doc/sphinx/lfun/DefendInfo.rst
@@ -0,0 +1,218 @@
+DefendInfo()
+============
+
+FUNKTION
+--------
+::
+
+DEFINIERT IN
+------------
+::
+
+ /sys/combat.h
+
+ARGUMENTE
+---------
+::
+
+BESCHREIBUNG
+------------
+::
+
+ Die DefendInformationen werden im Runde eines Attack/Defend Vorgangs
+ in Attack initial angelegt und dem Defend ueber den Parameter spell
+ uebergeben. Ist dieser Parameter ein Mapping, so sind die
+ DefendInformationen ueber den Key EINFO_DEFEND zu erhalten.
+ Die Informationen liegen in Form eines Mappings vor.
+ Vor Zugriff sollte immer auf die Existenz dieses Keys in dem Mapping
+ geprueft werden, da nicht alle Informationen immer existieren.
+ Die Keys sind in combat.h definiert und sind folgende:
+
+
+
+ ORIGINAL_AINFO - Mapping
+ Hier ist eine Kopie des originalen ainfo-mappings des Attacks
+ vorhanden mit folgenden Eintraegen:
+ Immer vorhandene Eintraege:
+ SI_ENEMY der angegriffene Gegner
+
+
+
+ Angriff mit gezueckter Waffe:
+ P_WEAPON das Waffenobjekt selbst
+ P_WEAPON_TYPE P_WEAPON_TYPE der Waffe
+ P_WC P_WC der Waffe
+ P_NR_HANDS P_NR_HANDS der Waffe
+ SI_SKILLDAMAGE_TYPE P_DAM_TYPE der Waffe
+ SI_SKILLDAMAGE waffe->QueryDamage(enemy)
+ bei vorhandenem Zweihandskill SK_TWOHANDED wird nur der durch
+ den Skill modifizierte Schadenswert uebernommen
+ SI_SKILLDAMAGE_MSG "mit "+waffe->name(WEM,0)
+ SI_SKILLDAMAGE_MSG2 "mit "+waffe->name(WEM,1)
+ SI_SPELL 0
+
+ Angriff mit blossen Haenden:
+ P_WEAPON_TYPE WT_HANDS
+ P_WC P_HANDS[1]
+ SI_SKILLDAMAGE Schadenswert, aus P_HANDS[1] und A_STR
+ berechnet
+ SI_SKILLDAMAGE_TYPE P_HANDS[2]
+ SI_SKILLDAMAGE_MSG
+ SI_SKILLDAMAGE_MSG2 beides P_HANDS[0]
+ SI_SPELL 0
+
+
+
+ Angriff mit einem Spell (SK_MAGIC_ATTACK):
+ SI_SKILLDAMAGE Schadenswert des Spells
+ SI_SKILLDAMAGE_TYPE Schadenstypen des Spells
+ SI_SKILLDAMAGE_MSG Schadensmeldung des Spells, wenn vorhanden,
+ sonst "mit magischen Faehigkeiten"
+ SI_SKILLDAMAGE_MSG2 entsprechende Meldung des Spells, wenn
+ gesetzt, ansonsten identisch mit
+ SI_SKILLDAMAGE_MSG
+ P_WEAPON_TYPE P_WEAPON_TYPE des Spells, wenn vorhanden,
+ sonst WT_MAGIC
+ SI_SPELL SI_SPELL des Spells
+
+
+
+ Hinweise:
+ - Alle Eintraege in diesem Mapping koennen bereits durch
+ InternalModifyAttack() veraendert worden sein.
+ - Die Daten werden mittels deep_copy(ainfo) eingetragen.
+ - Daten in den Eintraegen SI_SKILLDAMAGE* und SI_SPELL koennen bei
+ physikalischen Angriffen durch die Skills FIGHT(P_WEAPON_TYPE) oder
+ SK_FIGHT oder durch einen P_TMP_ATTACK_MOD bzw. Hook vom Typ
+ H_HOOK_ATTACK_MOD modifiziert worden sein.
+
+
+
+ ORIGINAL_DAM - int
+ Der Originalschaden aus dem Attack
+
+ ORIGINAL_DAM_TYPE - string/string*
+ Der Originaldamagetyp aus dem Attack
+
+ CURRENT_DAM - int
+ Der momentane Schaden, nach schon erfolgten Modifikationen
+
+
+
+ CURRENT_DAM_TYPE - string/string*
+ Der momentane Damagetyp, nach schon erfolgten Modifikationen
+
+
+
+ ENEMY_INSERTED - int
+ 0 oder 1 je nachdem ob der Angreifer schon in der enemy-list
+ vorhanden war oder nicht
+
+
+
+ RFR_REDUCE - int
+ 0 oder reduzierter Schaden durch RFR Modifikation
+
+
+
+ PRESENT_DEFENDERS - Array
+ Liste der durch InformDefend informierten Defender als Objekt.
+ Ein Defender wird immer NACH InformDefend
+ dazugefuegt
+
+
+
+ DEFENDING_DEFENDER - Array ({})
+ Hat ein durch InformDefend ein Defender verteidigt, so wird
+ fuer diesen Defender ein Eintrag in diesem Array vorgenommen,
+ welcher folgende Struktur besitzt.
+ ({
+ DEF_DEFENDER - Object
+ Der Verteidiger, welcher VOR
+ DefendOther eingefuegt wird
+ DEF_DAM - int
+ Der veraenderte Schaden, welcher NACH
+ DefendOther eingefuegt wird
+ DEF_DAMTYPE string/string*
+ Die veraenderte Schadensart, welche
+ NACH DefendOther eingefuegt wird
+ DEF_SPELL - Mapping
+ Das Mapping des veraenderten Spells, welches
+ als Kopie NACH DefendOther eingefuegt wird
+ })
+
+
+
+ DEFEND_HOOK - Int/Array
+ DI_NOHOOK, wenn kein Hook da war, DI_HOOKINTERRUPT, wenn der
+ Hook das Defend unterbricht, DI_HOOK, wenn ein Hook vorhanden
+ ist, dieser das Defend aber unveraendert laesst.
+ Veraendert ein Hook das Defend, so ist hier ein Array zu finden
+ mit den veraenderten Parametern in der Struktur:
+ ({
+ HOOK_DAM - int
+ Der veraenderte Schaden
+ HOOK_DAMTYPE - string/string*
+ Die veraenderte Schadensart
+ HOOK_SPELL - Mapping
+ Das Mapping des veraenderten Spells als Kopie
+ })
+
+
+
+ DEFEND_ARMOURS - Mapping (2 Werte pro Key)
+ Liste der beruecksichtigten Ruestungen. Fuer jede Ruestung
+ wird ein Eintrag vorgenommen, mit dem Objekt der jeweiligen
+ Ruestung als Key. Hierbei werden die Ruestungen erst eingetragen,
+ wenn ihr jeweiliges QueryDefend() aufgerufen wird, d.h. es sind nicht
+ von Anfang an alle getragenen Ruestung drin. Jeder Eintrag im Mapping
+ besitzt die folgenden 2 Werte:
+ DEF_ARMOUR_DAM - int
+ Der Schaden NACH QueryDefend (vorher 0)
+ DEF_ARMOUR_PROT - int
+ Verteidigungswert der Ruestung VOR DefendFunc
+ Bsp: Ich will wissen, wie gut 'ruestung' schuetzte:
+ spell[EINFO_DEFEND][DEFEND_ARMOURS][ruestung,DEF_ARMOUR_PROT]
+
+ DEFEND_GUILD - Array
+ Eine Liste mit der Modifikation der Gilde mit der Struktur
+ ({
+ GUILD_DAM - int
+ Der veraenderte Schaden
+ GUILD_DAMTYPE - string/string*
+ Die veraenderte Schadensart
+ })
+
+
+
+ DEFEND_RESI - int
+ Schaden nach CheckResistance
+
+
+
+ DEFEND_BODY - int
+ Schaden nach Beruecksichtigung des Bodies (nur
+ physikalisch)
+
+
+
+ DEFEND_LOSTLP - int
+ Tatsaechlich abgezogene LP
+
+
+
+ DEFEND_CUR_ARMOUR_PROT - int
+ Schutz der Ruestung vor Call der
+ DefendFunc. Ist nur in der DefendFunc definiert. Kann auch aus
+ DEFEND_ARMOURS entnommen werden
+
+
+
+SIEHE AUCH
+----------
+::
+
+ Attack, Defend
+
+18.Jul 2006 Muadib
+
diff --git a/doc/sphinx/lfun/DefendOther.rst b/doc/sphinx/lfun/DefendOther.rst
new file mode 100644
index 0000000..855d2b8
--- /dev/null
+++ b/doc/sphinx/lfun/DefendOther.rst
@@ -0,0 +1,108 @@
+DefendOther()
+=============
+
+FUNKTION
+--------
+::
+
+ mixed DefendOther(int dam,mixed dam_type,mixed spell,object enemy);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ dam
+ Der Schaden, der voraussichtlich beim zu verteidigenden Lebewesen
+ verursacht werden soll.
+ dam_type
+ Der Schadenstyp (oder die Schadenstypen), der beim zu
+ verteidigenden Lebewesen verursacht werden sollen.
+ spell
+ Wenn das zu verteidigende Lebewesen mit Spells angegriffen wurde,
+ so koennte man hier mehr Infos entnehmen.
+ enemy
+ Der Feind, der ein zu verteidigendes Lebewesen angegriffen hat.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Array mit den Eintraegen der gegebenenfalls veraenderten
+ uebergebenen Parameter:
+ (1) dam [Typ int],
+ (2) dam_type [Typ string*],
+ (3) spell [Typ mapping].
+
+BESCHREIBUNG
+------------
+::
+
+ Es ist moeglich, dass Objekte Angriffe auf Lebewesen abwehren oder
+ umwandeln, sofern diese Objekte bei dem angegriffenen Lebewesen
+ mittels AddDefender() angemeldet wurden und sich der selben Umgebung
+ befinden.
+ Zumeist wird es sich bei den Objekten natuerlich ebenfalls um
+ andere Lebewesen handeln, die das Lebewesen, bei dem sie angemeldet
+ sind, verteidigen sollen.
+ Bei einem Angriff auf das Lebewesen koennen alle Objekte per Aufruf
+ von DefendOther() in einen Angriff eingreifen, wobei die
+ Schadensstaerke, der Schadenstyp (die Schadenstypen),
+ Zusatzinformationen fuer Angriffsspells und der Angreifer als
+ Parameter uebergeben werden.
+ Desweiteren ist zu beachten, dass bei als physikalisch markierten
+ Angriffen in einem Team nur Verteidiger aus der ersten Reihe
+ beruecksichtigt werden und dass bei einem Angriff zufaellig aus
+ allen moeglichen Verteidigern ausgewaehlt wird.
+ Standardmaessig ist diese Funktion in Lebewesen bereits definiert,
+ wobei der Skill SK_DEFEND_OTHER, sofern vorhanden, aufgerufen wird.
+
+BEISPIEL
+--------
+::
+
+ Sehr beliebt sind in Gilden NPCs, die den Beschwoerer begleiten und
+ verteidigen, z.B. beschworene Daemonen:
+ inherit "std/npc";
+ include <properties.h>
+ object owner;
+ void create()
+ { ::create();
+ SetProp(P_NAME,"Daemon");
+ ...
+ }
+ // nach Clonen des Daemons folgende Funktion mit Beschwoerer als
+ // Parameter aufrufen
+ Identify(object caster)
+ { if(!objectp(caster))
+ call_out(#'remove,0);
+ owner=caster;
+ owner->AddDefender(this_object());
+ }
+ // der Daemon wehrt jeden Angriff mit Feuer voll ab, man muss zuerst
+ // den Verteidiger umbringen, um den Beschwoerer toeten zu koennen
+ mixed DefendOther(int dam,mixed dam_type,mixed spell,object enemy)
+ { if(sizeof(dam_type)&&member_array(DT_FIRE,dam_type)!=-1)
+ dam=0;
+ return({dam,dam_type,spell});
+ }
+ Soll der Daemon sich auch in ein Team einordnen, in welchem sich der
+ Beschwoerer eventuell befindet, so ist zusaetzlich AssocMember() in
+ diesem Beschwoerer aufzurufen, wobei der Daemon als Parameter
+ uebergeben wird.
+
+SIEHE AUCH
+----------
+::
+
+ AddDefender(), RemoveDefender(), InformDefend(), Kill(), IsEnemy(),
+ P_DEFENDERS, /std/living/combat.c, /sys/new_skills.h
+
+
+Last modified: Fri Feb 25 14:45:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/lfun/Defend_bsp.rst b/doc/sphinx/lfun/Defend_bsp.rst
new file mode 100644
index 0000000..29e710a
--- /dev/null
+++ b/doc/sphinx/lfun/Defend_bsp.rst
@@ -0,0 +1,155 @@
+Defend_bsp()
+============
+
+Defend() - BEISPIELE
+--------------------
+::
+
+FUNKTION
+--------
+::
+
+ varargs int Defend(int dam, mixed dam_type, mixed spell, object enemy)
+
+BEMERKUNGEN
+-----------
+::
+
+ Die hier aufgefuehrten Komplexbeispiele sind zum Verstaendnis gedacht.
+
+BEISPIELE
+---------
+::
+
+ 1) Ein ordinaerer Biss ins Bein.
+ this_player()->Defend(random(500),
+ ({DT_PIERCE, DT_RIP}),
+ 0,
+ this_object());
+
+ 2) Ein Biss ins Bein, mit der Hose als 200%ige Ruestung und Rest mit 100%.
+ this_player()->Defend(random(500),
+ ({DT_PIERCE, DT_RIP}),
+ ([SP_PHYSICAL_ATTACK: 1,
+ SP_REDUCE_ARMOUR: ([AT_TROUSERS: 200])
+ ]),
+ this_object());
+
+ 3) Der Biss, wenn ein Tier in die Hose gekrochen ist und dieser ohne
+ Treffermeldung und physischen Ruestungsschutz durchgeht.
+ this_player()->Defend(random(500),
+ ({DT_PIERCE, DT_RIP}),
+ ([SP_PHYSICAL_ATTACK: 0]),
+ this_object());
+
+ 4) Spell-Parameter
+ // Beispiel fuer einen Spell, der nur vom Helm normal und von einem
+ // Amulett mit 115% aufgehalten wird, alle anderen (angebenenen)
+ // Ruestungen haben 0% Schutzwirkung.
+ // Mit Ausgabe eigener Meldungen: beginnend mit -1, da der verursachte
+ // Schadenswert minimal 0 wird (fuers Ersetzen: Feind: @WEx2,
+ // Spieler: WEx1); maximal wird er (Empfindlichkeiten jetzt mal aussen
+ // vor) 49 (499/10 = 49), nicht 499!!!
+ this_player()->Defend(
+ random(500),
+ ({DT_PIERCE, DT_AIR}),
+ ([SP_PHYSICAL_ATTACK: 1, // wegen DT_PIERCE
+ SP_REDUCE_ARMOUR: ([AT_ARMOUR: 0,
+ AT_HELMET: 100,
+ AT_RING: 0,
+ AT_GLOVE: 0,
+ AT_CLOAK: 0,
+ AT_BOOT: 0,
+ AT_TROUSERS: 0,
+ AT_SHIELD: 0,
+ AT_AMULET: 115,
+ AT_MISC: 0,
+ AT_BELT: 0,
+ AT_QUIVER: 0])
+ SP_SHOW_DAMAGE:
+ ({({-1,"@WER2 schrammt Dich mit einem durchbohrenden Blick.",
+ "Du schrammst @WEN1 mit einem durchbohrenden Blick.",
+ "@WER2 schrammt @WEN1 mit einem durchbohrenden Blick."
+ }),
+ ({5,"Der durchbohrende Blick von @WEM2 trifft Dich.",
+ "Dein durchbohrender Blick trifft @WEN1.",
+ "Der durchbohrende Blick von @WEM2 trifft @WEN1."
+ }),
+ ({20,"@WESSEN2 stechender Blick durchbohrt Dich.",
+ "Dein stechender Blick durchbohrt @WEN1.",
+ "@WESSEN2 stechender Blick durchbohrt @WEN1."
+ })})
+ ]),
+ this_object());
+
+ // Etwas geschickter geht das Ganze, wenn wir einfach aus der Mudlib
+ // alle existierenden Ruestungen in ein Mapping packen und diese
+ // nullen (damit sind wir auch gegen neue Ruestungstypen sicher):
+ mapping amap = map_indices(VALID_ARMOUR_CLASS,#'!);
+ amap[AT_HELMET]=100;
+ amap[AT_AMULET]=115;
+
+ this_player()->Defend(random(500),
+ ({DT_PIERCE, DT_AIR}),
+ ([SP_PHYSICAL_ATTACK: 1,
+ SP_REDUCE_ARMOUR: amap,
+ SP_SHOW_DAMAGE: ({ ... (siehe oben)
+
+ 5) Der Biss von weiter oben mit Meldung.
+ // Eine Meldung, die nur ausgegeben wird, wenn der Biss auch mindestens
+ // einen LP abzieht.
+ this_player()->Defend(random(500),
+ ({DT_PIERCE, DT_RIP}),
+ ([SP_PHYSICAL_ATTACK: 1,
+ SP_REDUCE_ARMOUR: ([AT_TROUSERS: 200]),
+ SP_SHOW_DAMAGE: ({
+ ({1,"@WER2 beisst Dich ins Bein!",
+ "Du beisst @WEN1 ins Bein!",
+ "@WER2 beisst @WEN1 ins Bein!"
+ }) })
+ ]),
+ this_object());
+
+ 6) DefendFunc() und Defend() in einem Objekt
+ 6a)
+ // eine Luftangriffe reflektierende Ruestung:
+ int DefendFunc(string *dtyp, mixed spell, object enemy) {
+ if(member(dtyp, DT_AIR)>=0 && !spell[SP_RECURSIVE])
+ enemy->Defend(random(200),
+ ({DT_AIR}),
+ ([SP_RECURSIVE: 1,
+ SP_SHOW_DAMAGE:
+ ({"Ein Luftwirbel erfasst auch Dich.",
+ "Deine Ruestung wirbelt @WEN1 herum.",
+ "@WESSEN2 Ruestung wirbelt @WEN1 herum."
+ })
+ ]),
+ QueryProp(P_WORN));
+
+ return 0; // -> In diesem Fall gibts keinen Ruestungsbonus!
+ }
+
+ 6b)
+ // Eine NUR REINE Luftangriffe reflektierende Ruestung:
+ int DefendFunc(string *dtyp, mixed spell, object enemy) {
+ if(!sizeof(dtyp-({DT_AIR})) && !spell[SP_RECURSIVE])
+ ...
+
+SIEHE AUCH
+----------
+::
+
+ Angriff: Attack(L), P_NO_ATTACK, InsertEnemy(L)
+ Schaden: P_ENABLE_IN_ATTACK_OUT, P_LAST_MOVE, do_damage(L),
+ reduce_hit_points(L), reduce_spell_points(L)
+ Schutz: P_DEFENDERS, InformDefend(L), DefendOther(L),
+ P_ARMOURS, P_AC, P_DEFEND_FUNC, QueryDefend(L),
+ P_BODY, A_DEX, Defend(L)
+ Daten: P_LAST_COMBAT_TIME, P_LAST_XP, P_LAST_DAMAGE,
+ P_LAST_DAMTYPES, P_LAST_DAMTIME
+ Resistenz: P_RESISTANCE_STRENGTHS, CheckResistance(L)
+ Sonstiges: CheckSensitiveAttack(L), UseSkill(L),
+ InternalModifyDefend(L)
+
+25. Mai 2011 Gabylon
+
diff --git a/doc/sphinx/lfun/DeleteSpellFatigue.rst b/doc/sphinx/lfun/DeleteSpellFatigue.rst
new file mode 100644
index 0000000..6320ab6
--- /dev/null
+++ b/doc/sphinx/lfun/DeleteSpellFatigue.rst
@@ -0,0 +1,56 @@
+DeleteSpellFatigue()
+====================
+
+FUNKTION
+--------
+::
+
+ public void DeleteSpellFatigue(string key)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skills.c
+ /std/player/skills.c
+ /sys/living/skills.h
+
+ARGUMENTE
+---------
+::
+
+ string key : Eindeutiger Name des Spruches, einer Gruppe von Spruechen
+ oder 0 fuer die globale Spruchermuedung.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion dient zum Loeschen von individuellen Spruchermuedungen
+ (Spellfatigue, Spruchsperren).
+
+ Ist <key> 0, wird die globale Spruchsperre geloescht (identisch zu der
+ Property P_NEXT_SPELL_TIME), anderenfalls die unter <key> gespeicherte
+ Spruchermuedung.
+ Loescht man einen Eintrag 0 ist das Ergebnis dieser Funktion identisch zum
+ Loeschen/Nullen von P_NEXT_SPELL_TIME.
+
+BEMERKUNGEN
+-----------
+::
+
+ Spruchsperren (insb. fremde) duerfen nicht ohne weiteres geloescht oder
+ geaendert werden. Dieses bedarf grundsaetzlich der Genehmigung durch die
+ Gildenbalance!
+
+SIEHE AUCH
+----------
+::
+
+ SetSpellFatigue(L), CheckSpellFatigue(L)
+ P_NEXT_SPELL_TIME
+ spruchermuedung
+
+
+27.03.2010, Zesstra
+
diff --git a/doc/sphinx/lfun/DeleteTimedAttrModifier.rst b/doc/sphinx/lfun/DeleteTimedAttrModifier.rst
new file mode 100644
index 0000000..d7e1ff6
--- /dev/null
+++ b/doc/sphinx/lfun/DeleteTimedAttrModifier.rst
@@ -0,0 +1,55 @@
+DeleteTimedAttrModifier()
+=========================
+
+FUNKTION
+--------
+::
+
+ int DeleteTimedAttrModifier(string key)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+ key - aus P_TIMED_ATTR_MOD zu loeschender Eintrag
+
+BESCHREIBUNG
+------------
+::
+
+ Der zu key gehoerende Eintrag in P_TIMED_ATTR_MOD wird geloescht und
+ update_max_sp_and_hp ausgefuehrt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ TATTR_INVALID_ARGS - Im Falle eines fehlenden key-Arguments
+ TATTR_NO_SUCH_MODIFIER - Falls der Modifier mit diesem Key nicht
+ existiert
+ TATTR_OK - Im Erfolgsfall
+
+
+
+ Die Rueckgabewerte sind in /sys/living/attributes.h definiert.
+
+
+
+SIEHE AUCH
+----------
+::
+
+ QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+ SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+ SetTimedAttrModifier(), QueryTimedAttrModifier(),
+ P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+ P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/DiscoverDoor.rst b/doc/sphinx/lfun/DiscoverDoor.rst
new file mode 100644
index 0000000..2deb1a1
--- /dev/null
+++ b/doc/sphinx/lfun/DiscoverDoor.rst
@@ -0,0 +1,54 @@
+DiscoverDoor()
+==============
+
+FUNKTION
+--------
+::
+
+ varargs int DiscoverDoor(string dname)
+
+ARGUMENTE
+---------
+::
+
+ dname: Name des Raumes, in dem der Seher das Sehertor kennenlernen soll.
+ Default: Die Umgebung des Sehers.
+
+BESCHREIBUNG
+------------
+::
+
+ Nachdem diese Funktion aufgerufen wurde, kann der Seher (this_player())
+ das Tor in dem angegebenen Raum immer verwenden.
+
+RUECKGABEWERT
+-------------
+::
+
+ 1, falls der Seher ein NEUES Tor kennengelernt hat
+ 0, falls er das Tor schon kannte oder kein Seher war
+
+BEMERKUNGEN
+-----------
+::
+
+ Von einem Sehertor wird diese Funktion automatisch beim Betreten des
+ umgebenden Raumes aufgerufen, falls P_SEERDOOR_DISCOVER gesetzt ist. Wenn
+ ein Tor auf diese Art nicht entdeckt werden soll, so darf
+ P_SEERDOOR_DISCOVER nicht gesetzt sein und muss DiscoverDoor() separat,
+ z.B. von einem Questobjekt, aufgerufen werden.
+ Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
+
+BEISPIELE
+---------
+::
+
+ write("Der Zauberer sagt: Im Nichts wirst Du ein weiteres Tor finden!\n");
+ "/d/seher/portale/sehertormaster"->DiscoverDoor("/room/void");
+
+SIEHE AUCH
+----------
+::
+
+ DoorIsKnown, ShowDoors, Teleport, GetDoorsMapping
+
diff --git a/doc/sphinx/lfun/DistributeExp.rst b/doc/sphinx/lfun/DistributeExp.rst
new file mode 100644
index 0000000..dd6696c
--- /dev/null
+++ b/doc/sphinx/lfun/DistributeExp.rst
@@ -0,0 +1,42 @@
+DistributeExp()
+===============
+
+FUNKTION
+--------
+::
+
+ private void DistributeExp(object enemy, int exp_to_give)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ object enemy - toetender Feind
+ int exp_to_give - zu verteilende XP (== P_XP/100)
+
+BESCHREIBUNG
+------------
+::
+
+ Das sterbende Wesen verteilt seine XP an seine Feinde.
+
+ Dabei bekommt jeder Gegner seinen Anteil (abhaengig von 50% von seinem
+ gemachten Schaden) und einen Teamanteil (die anderen 50% ueber das
+ gesamte Team addiert und durch die Teamanzahl geteilt).
+
+SIEHE AUCH
+----------
+::
+
+ Funktionen: AddExp()
+ Properties: P_XP
+ Sonstiges: teamkampf
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/DoDecay.rst b/doc/sphinx/lfun/DoDecay.rst
new file mode 100644
index 0000000..e600daf
--- /dev/null
+++ b/doc/sphinx/lfun/DoDecay.rst
@@ -0,0 +1,69 @@
+DoDecay()
+=========
+
+FUNKTION
+--------
+::
+
+ public int DoDecay(int silent)
+
+DEFINIERT IN
+------------
+::
+
+ /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+ silent (int)
+ Falls != 0, erfolgt beim Zerfall keine Meldung, d.h. doDecayMessaage()
+ wird nicht gerufen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Die Funktion gibt die nach dem Zerfall noch uebrig gebliebene Menge
+ zurueck (int).
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird in Clones von Unitobjekten aus der Blueprint gerufen,
+ wenn ein Zerfallsintervall abgelaufen ist (natuerlich nur, wenn in der BP
+ der Zerfall konfiguriert ist).
+ Die Funktion prueft normalerweise via P_UNIT_DECAY_FLAGS, ob der Zerfall
+ stattfinden soll, bestimmt aus P_UNIT_DECAY_QUOTA die zu zerfallende
+ Menge, ruft DoDecayMessage() und reduziert P_AMOUNT.
+
+
+
+ Sie kann auch von Hand gerufen werden, um einen Zerfall auszuloesen, auch
+ wenn mir gerade nicht einfaellt, in welchen Situationen das sinnvoll
+ waere (vielleicht als Spruchmisserfolg. *g*)
+
+BEMERKUNGEN
+-----------
+::
+
+ Wenn man einen anderen Zerfallsmechanismus haben, will muss man diese
+ Funktion wohl ueberschreiben. In fast allen Faellen sollte dies jedoch
+ unnoetig sein. Hat jemand das Verlangen, diese Funktion zu
+ ueberschreiben, ist vielleicht vorher eine Diskussion mit dem Mudlib-EM
+ angebracht.
+
+SIEHE AUCH
+----------
+::
+
+ unit
+ P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_QUOTA,
+ P_UNIT_DECAY_MIN
+ DoDecayMessage()
+ /std/unit.c
+
+14.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/DoDecayMessage.rst b/doc/sphinx/lfun/DoDecayMessage.rst
new file mode 100644
index 0000000..c21080d
--- /dev/null
+++ b/doc/sphinx/lfun/DoDecayMessage.rst
@@ -0,0 +1,56 @@
+DoDecayMessage()
+================
+
+FUNKTION
+--------
+::
+
+ protected void DoDecayMessage(int oldamount, int zerfall);
+
+
+
+DEFINIERT IN
+------------
+::
+
+ /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+ oldamount (int)
+ Menge vor dem Zerfall
+ zerfall (int)
+ jetzt zerfallende Menge
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird von DoDecay() gerufen und gibt die Standardmeldungen
+ beim Zerfall von Unitobjekten aus.
+ Hierbei ist an der Unit noch alles unveraendert, wenn diese Funktion
+ gerufen wird, die Reduktion von P_AMOUNT erfolgt direkt im Anschluss.
+ Die Funktion wird nicht gerufen, wenn DoDecay() mit silent!=0 gerufen
+ wird.
+
+BEMERKUNGEN
+-----------
+::
+
+ Will man nicht die Standardzerfallsmeldungen (wovon ich meist ausgehe),
+ kann man diese Funktion ueberschreiben und eigene Meldungen erzeugen.
+
+SIEHE AUCH
+----------
+::
+
+ unit
+ P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_QUOTA,
+ P_UNIT_DECAY_MIN
+ DoDecay()
+ /std/unit.c
+
+14.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/DoUnwear.rst b/doc/sphinx/lfun/DoUnwear.rst
new file mode 100644
index 0000000..f4807bf
--- /dev/null
+++ b/doc/sphinx/lfun/DoUnwear.rst
@@ -0,0 +1,56 @@
+DoUnwear()
+==========
+
+FUNKTION
+--------
+::
+
+ varargs int DoUnwear(int silent, int all);
+
+DEFINIERT IN
+------------
+::
+
+ /std/clothing/wear.c
+
+ARGUMENTE
+---------
+::
+
+ silent
+ Falls ungleich 0, so werden keine Meldungen ausgegeben.
+ Falls (silent&M_NOCHECK) werden auch verfluchte Ruestungen
+ ausgezogen
+ all
+ Ungleich 0, wenn DoUnwear() aus einem "ziehe alles aus" heraus
+ aufgerufen wurde.
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird versucht, die Ruestung auszuziehen. Dabei werden eine eventuell
+ vorhandene RemoveFunc() und Flueche mit beruecksichtigt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn die Ruestung gar nicht getragen war, ansonsten 1.
+
+BEMERKUNGEN
+-----------
+::
+
+ Auch wenn eine 1 zurueckgegeben wird, muss das nicht heissen, dass die
+ Ruestung erfolgreich ausgezogen wurde!
+
+SIEHE AUCH
+----------
+::
+
+ DoWear(), RemoveFunc(), InformUnwear(), /std/armour/combat.c
+
+
+Last modified: Sun Jun 27 22:22:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/DoUnwield.rst b/doc/sphinx/lfun/DoUnwield.rst
new file mode 100644
index 0000000..f733e48
--- /dev/null
+++ b/doc/sphinx/lfun/DoUnwield.rst
@@ -0,0 +1,55 @@
+DoUnwield()
+===========
+
+FUNKTION
+--------
+::
+
+ varargs int DoUnwield(int silent);
+
+DEFINIERT IN
+------------
+::
+
+ /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+ silent
+ Ungleich 0, wenn die Waffe ohne Meldungen weggesteckt werden soll.
+ Wenn silent&M_NOCHECK wird die Waffe auch weggesteckt wenn sie
+ verflucht ist und UnwieldFunc() wird nicht ausgewertet.
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird versucht, die Waffe wegzustecken.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn die Waffe gar nicht gezueckt war, ansonsten 1.
+
+BEMERKUNGEN
+-----------
+::
+
+ Anhand des Rueckgabewertes laesst sich nicht ersehen, ob die Waffe sich
+ wegstecken liess oder nicht!
+
+ Wenn die Waffe verflucht ist oder (falls definiert) UnwieldFunc() 0
+ zurueckgibt, laesst sie sich nicht wegstecken.
+
+SIEHE AUCH
+----------
+::
+
+ UnwieldFunc(), InformUnwield(), /std/weapon.c
+
+
+Letzte Aenderung: 18.11.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/DoWear.rst b/doc/sphinx/lfun/DoWear.rst
new file mode 100644
index 0000000..715f416
--- /dev/null
+++ b/doc/sphinx/lfun/DoWear.rst
@@ -0,0 +1,65 @@
+DoWear()
+========
+
+FUNKTION
+--------
+::
+
+ varargs int DoWear(int silent, int all);
+
+DEFINIERT IN
+------------
+::
+
+ /std/armour/combat.c
+
+ARGUMENTE
+---------
+::
+
+ silent
+ Falls ungleich 0, so werden keine Meldungen ausgegeben.
+ all
+ Ungleich 0, wenn DoWear() aus einem "ziehe alles an" heraus
+ aufgerufen wurde.
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird versucht, die Ruestung anzuziehen. Dabei wird eine eventuell
+ vorhandene WearFunc() mit beruecksichtigt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn man die Ruestung gar nicht bei sich hat oder sie schon an hat,
+ ansonsten 1.
+
+BEMERKUNGEN
+-----------
+::
+
+ Auch wenn eine 1 zurueckgegeben wird, muss das nicht heissen, dass die
+ Ruestung erfolgreich angezogen wurde!
+
+ Gruende fuer ein Fehlschlagen des Anziehens koennen sein:
+ o Man hat die Ruestung nicht bei sich.
+ o Man hat die Ruestung schon an.
+ o Man hat schon eine Ruestung des gleichen Typs an.
+ o Der Typ der Ruestung oder die Ruestungsklasse ist illegal.
+ o Falls definiert: WearFunc() gab 0 zurueck.
+ o Falls es sich um einen Schild handelt: Man hat keine Hand mehr
+ frei.
+
+SIEHE AUCH
+----------
+::
+
+ DoUnwear(), WearFunc(), InformWear(), P_EQUIP_TIME,
+ /std/armour/combat.c, P_UNWEAR_MSG, P_WEAR_MSG
+
+
+Last modified: Sun Jun 27 22:22:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/DoWield.rst b/doc/sphinx/lfun/DoWield.rst
new file mode 100644
index 0000000..5334a5b
--- /dev/null
+++ b/doc/sphinx/lfun/DoWield.rst
@@ -0,0 +1,64 @@
+DoWield()
+=========
+
+FUNKTION
+--------
+::
+
+ varargs int DoWield(int silent);
+
+DEFINIERT IN
+------------
+::
+
+ /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+ silent
+ Ungleich 0, wenn die Waffe ohne Meldungen gezueckt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird versucht, die Waffe zu zuecken. Hat man schon eine Waffe
+ gezueckt, so wird versucht, diese wegzustecken. Klappt das nicht, kann
+ die Waffe nicht gezueckt werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn man die Waffe gar nicht bei sich traegt, ansonsten 1.
+
+BEMERKUNGEN
+-----------
+::
+
+ Anhand des Rueckgabewertes laesst sich nicht entscheiden, ob die Waffe
+ sich erfolgreich zuecken liess!
+
+ Gruende, warum sich eine Waffe nicht zuecken lassen kann, sind
+ folgende:
+ o Man traegt sie nicht bei sich (oder sie steckt in einem Beutel
+ o.ae.).
+ o Man hat sie schon gezueckt.
+ o Falls definiert: WieldFunc() gibt 0 zurueck.
+ o Man ist nicht geschickt genug (das haengt von der Waffenklasse
+ ab).
+ o Eine schon gezueckte Waffe laesst sich nicht wegstecken.
+ o Die Waffenklasse ist hoeher als erlaubt.
+ o Man hat nicht genug Haende frei.
+
+SIEHE AUCH
+----------
+::
+
+ WieldFunc(), InformWield(), P_EQUIP_TIME, /std/weapon.c
+
+
+Last modified: Wed Apr 08 10:25:00 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/DoorIsKnown.rst b/doc/sphinx/lfun/DoorIsKnown.rst
new file mode 100644
index 0000000..29a396c
--- /dev/null
+++ b/doc/sphinx/lfun/DoorIsKnown.rst
@@ -0,0 +1,46 @@
+DoorIsKnown()
+=============
+
+FUNKTION
+--------
+::
+
+ int DoorIsKnown()
+
+ARGUMENTE
+---------
+::
+
+ Keine.
+
+BESCHREIBUNG
+------------
+::
+
+ Testet, ob der Seher (this_player()) das Tor in seiner momentanen
+ Umgebung schon kennt.
+
+RUECKGABEWERT
+-------------
+::
+
+ Die Nummer des Tores.
+
+BEMERKUNGEN
+-----------
+::
+
+ Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
+
+BEISPIELE
+---------
+::
+
+ /d/seher/portale/sehertormaster->DoorIsKnown()
+
+SIEHE AUCH
+----------
+::
+
+ DiscoverDoor, ShowDoors, Teleport, GetDoorsMapping
+
diff --git a/doc/sphinx/lfun/Dump.rst b/doc/sphinx/lfun/Dump.rst
new file mode 100644
index 0000000..23f79fe
--- /dev/null
+++ b/doc/sphinx/lfun/Dump.rst
@@ -0,0 +1,38 @@
+Dump()
+======
+
+FUNKTION
+--------
+::
+
+ void Dump()
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/materialdb.c (MATERIALDB)
+
+BESCHREIBUNG
+------------
+::
+
+ Schreibt alle Materialien samt ihren Gruppen und alle Gruppen mit
+ dazugehoerenden Materialien in DUMPFILE (/p/daemon/save/MATERIALS)
+ Wird in create() der Materialiendatenbank automatisch aufgerufen.
+ Das Dumpfile ist zum Recherchieren der Materialien gedacht.
+
+SIEHE AUCH
+----------
+::
+
+ Konzepte: material, materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Listen: AllMaterials(), AllGroups()
+ materialliste, materialgruppen
+ Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
+ GroupName(), MaterialName(),
+ GetGroupMembers(), GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/EnemyPresent.rst b/doc/sphinx/lfun/EnemyPresent.rst
new file mode 100644
index 0000000..b027698
--- /dev/null
+++ b/doc/sphinx/lfun/EnemyPresent.rst
@@ -0,0 +1,34 @@
+EnemyPresent()
+==============
+
+FUNKTION
+--------
+::
+
+ public mixed EnemyPresent()
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt aus der Feindesliste den ersten anwesenden, lebenden und
+ angreifbaren aktuellen Gegner im Raum zurueck.
+ Damit ist die Funktion identisch zu InFight().
+
+ Will man alle Gegner, auf die diese Kriterien zutreffen, sollte man
+ PresentEnemies() verwenden.
+
+SIEHE AUCH
+----------
+::
+
+ PresentEnemies(), Infight()
+
+22.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/Enter.rst b/doc/sphinx/lfun/Enter.rst
new file mode 100644
index 0000000..dd58b38
--- /dev/null
+++ b/doc/sphinx/lfun/Enter.rst
@@ -0,0 +1,65 @@
+Enter()
+=======
+
+FUNKTION
+--------
+::
+
+ int Enter();
+
+DEFINIERT IN
+------------
+::
+
+ /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Wenn sich der Spieler noch nicht auf dem Transporter befindet, und der
+ Transporter momentan an einer Haltestelle liegt, betritt der Spieler
+ den Transporter.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Null, wenn der Spieler den Transporter nicht betreten konnte, sonst
+ ungleich Null.
+
+BEMERKUNGEN
+-----------
+::
+
+ Es werden keine Tests durchgefuehrt, ob der Transporter ueberhaupt
+ angesprochen wurde! Das muss man selber machen.
+
+BEISPIELE
+---------
+::
+
+ int myEnter(string str)
+ {
+ if (str && id(str))
+ return Enter();
+
+ notify_fail("Was willst Du betreten?\n");
+ return 0;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Leave(), /std/transport.c
+
+
+Last modified: Wed May 8 10:18:42 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/EvalArmour.rst b/doc/sphinx/lfun/EvalArmour.rst
new file mode 100644
index 0000000..4f146de
--- /dev/null
+++ b/doc/sphinx/lfun/EvalArmour.rst
@@ -0,0 +1,48 @@
+EvalArmour()
+============
+
+FUNKTION
+--------
+::
+
+ int EvalArmour(object ob, closure qp)
+
+
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/shop.c
+
+
+
+ARGUMENTE
+---------
+::
+
+ ob - Eine Ruestung.
+ qp - symbol_function("QueryProp",ob)
+
+BESCHREIBUNG
+------------
+::
+
+ Bewertet die Ruestung.
+
+
+
+RUECKGABEWERT
+-------------
+::
+
+ Max(P_AC,P_EFFECTIVE_AC);
+
+
+
+SIEHE AUCH
+----------
+::
+
+ FindBestArmour()
+
diff --git a/doc/sphinx/lfun/EvalWeapon.rst b/doc/sphinx/lfun/EvalWeapon.rst
new file mode 100644
index 0000000..d009aaf
--- /dev/null
+++ b/doc/sphinx/lfun/EvalWeapon.rst
@@ -0,0 +1,48 @@
+EvalWeapon()
+============
+
+FUNKTION
+--------
+::
+
+ int EvalWeapon(object ob, closure qp)
+
+
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/shop.c
+
+
+
+ARGUMENTE
+---------
+::
+
+ ob - Eine Waffe.
+ qp - symbol_function("QueryProp",ob)
+
+BESCHREIBUNG
+------------
+::
+
+ Bewertet die Waffe.
+
+
+
+RUECKGABEWERT
+-------------
+::
+
+ Max(P_WC,P_EFFECTIVE_WC);
+
+
+
+SIEHE AUCH
+----------
+::
+
+ FindBestWeapon()
+
diff --git a/doc/sphinx/lfun/ExtraAttack.rst b/doc/sphinx/lfun/ExtraAttack.rst
new file mode 100644
index 0000000..29b6350
--- /dev/null
+++ b/doc/sphinx/lfun/ExtraAttack.rst
@@ -0,0 +1,50 @@
+ExtraAttack()
+=============
+
+FUNKTION
+--------
+::
+
+ varargs public void ExtraAttack(object enemy, int ignore_previous);
+
+ARGUMENTE
+---------
+::
+
+ enemy: Der Feind.
+ ignore_previous: Ein Flag
+
+BESCHREIBUNG
+------------
+::
+
+ Der Feind wird der Staerke der Waffe (bzw. der Haende) entsprechend
+ stark angegriffen. Hierbei wird Attack() aufgerufen.
+ Ist ignore_previous ungleich 0, dann wird die Erstschlagsperre von
+ Attack ignoriert. Dieser Angriff ist also auch dann moeglich, wenn
+ das Lebewesen eigentlich keinen Schlag mehr in dieser Runde ausfuehren
+ duerfte.
+
+RUECKGABEWERT
+-------------
+::
+
+ Keiner.
+
+BEMERKUNG
+---------
+::
+
+ Der Einsatz dieser Funktion ist genehmigungspflichtig.
+ Weitere Hinweise siehe "man Attack".
+
+SIEHE AUCH
+----------
+::
+
+ "Attack"
+ /std/living/combat.c
+
+
+Last modified: Sun Nov 21 12:32:20 2004 by Bambi
+
diff --git a/doc/sphinx/lfun/FilterArmours.rst b/doc/sphinx/lfun/FilterArmours.rst
new file mode 100644
index 0000000..b83edf5
--- /dev/null
+++ b/doc/sphinx/lfun/FilterArmours.rst
@@ -0,0 +1,99 @@
+FilterArmours()
+===============
+
+FUNKTION
+--------
+::
+
+ public object *FilterArmours(closure filterfun, varargs mixed* extra)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+ closure filterfun
+ Die Closure, die entscheiden soll, ob eine Ruestung im Ergebnisarray
+ enthalten sein soll.
+
+
+
+ mixed extra
+ Beliebig viele Extra-Argumente, die <filterfun> uebergeben werden.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion ruft <filterfunc> fuer jede getragene Ruestung des
+ Lebewesen mit der jeweiligen Ruestung als Argument auf und liefert ein
+ Array mit allen Ruestungen zurueck, fuer die <filterfun> einen Wert != 0
+ zurueckliefert.
+ Die <extra> Argumente werden als zusaetzliche Parameter an <filterfun>
+ uebergeben und duerfen keine Referenzen sein.
+
+
+
+ Diese Variante ist zu bevorzugen, wenn man Ruestungen nach bestimmten
+ Kriterien durchsuchen will und QueryArmourByType() nicht ausreichend sein
+ sollte.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ein Array von Objekten mit allen passenden Ruestungen.
+
+BEISPIELE
+---------
+::
+
+ 1) Ich moechte gerne alle Ruestungen haben, die beschaedigt sind:
+ private int _is_damaged(object ruestung) {
+ return ruestung->QueryProp(P_DAMAGE);
+ }
+ ...
+ object *damaged_armours = PL->FilterArmours(#'_is_damaged);
+
+ 2) Ich moechte alle Ruestungen, die groesser als 50cm sind.
+ private int _armour_is_bigger(object ruestung, int size) {
+ return ruestung->QueryProp(P_SIZE) > size;
+ }
+ ...
+ object *big_armours = PL->FilterArmours(#'_amour_is_bigger, 50);
+
+ 3) alle Ruestungen mit einer speziellen ID.
+ private int _has_id(object ruestung, string idstr) {
+ return ruestung->id(idstr);
+ }
+ object *has_id = PL->FilterArmours(#'_has_id, "\ntolleruestung");
+
+ 4) alle Ruestungen mit einer speziellen ID, die groesser als 50cm sind.
+ private int _has_id(object ruestung, string idstr, int size) {
+ return ruestung->id(idstr) && ruestung->QueryProp(P_SIZE) > size;
+ }
+ object *has_id = PL->FilterArmours(#'_has_id, "\ntolleruestung", 50);
+
+ 5) ueberhaupt alle getragene Ruestung
+ object *rue = PL->FilterArmours(#'objectp)
+
+SIEHE AUCH
+----------
+::
+
+ Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour(),
+ UnwearClothing()
+ P_CLOTHING, P_ARMOURS
+ FilterClothing(), QueryArmourByType()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/FilterClothing.rst b/doc/sphinx/lfun/FilterClothing.rst
new file mode 100644
index 0000000..268608e
--- /dev/null
+++ b/doc/sphinx/lfun/FilterClothing.rst
@@ -0,0 +1,80 @@
+FilterClothing()
+================
+
+FUNKTION
+--------
+::
+
+ public object *FilterClothing(closure filterfun, varargs mixed* extra)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+ closure filterfun
+ Die Closure, die entscheiden soll, ob eine Kleidung im Ergebnisarray
+ enthalten sein soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion ruft <filterfunc> fuer jede getragene Kleidung des
+ Lebewesen mit der jeweiligen Kleidung als Argument auf und liefert ein
+ Array mit aller Kleidung zurueck, fuer die <filterfun> einen Wert != 0
+ zurueckliefert.
+ Die <extra> Argumente werden als zusaetzliche Parameter an <filterfun>
+ uebergeben und duerfen keine Referenzen sein.
+
+
+
+ Diese Variante ist zu bevorzugen, wenn man die getrage Kleidung nach
+ bestimmten Kriterien durchsuchen will.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ein Array von Objekten mit allen passenden Kleidung.
+
+BEISPIELE
+---------
+::
+
+ 1) Ich moechte alle Kleidung, die groesser als 50cm ist.
+ private int _armour_is_bigger(object clothing, int size) {
+ return clothing->QueryProp(P_SIZE) > size;
+ }
+ ...
+ object *big_armours = PL->FilterClothing(#'_amour_is_bigger, 50);
+
+ 2) alle Kleidung mit einer speziellen ID.
+ private int _has_id(object clothing, string idstr) {
+ return clothing->id(idstr);
+ }
+ object *has_id = PL->FilterClothing(#'_has_id, "\ntollekleidung");
+
+ 3) ueberhaupt alle getragene Kleidung
+ object *clothing = PL->FilterClothing(#'objectp)
+
+SIEHE AUCH
+----------
+::
+
+ Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour(),
+ UnwearClothing()
+ P_CLOTHING, P_ARMOURS
+ FilterArmours(), QueryArmourByType()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/FindBestArmours.rst b/doc/sphinx/lfun/FindBestArmours.rst
new file mode 100644
index 0000000..adb2b5b
--- /dev/null
+++ b/doc/sphinx/lfun/FindBestArmours.rst
@@ -0,0 +1,74 @@
+FindBestArmours()
+=================
+
+FUNKTION
+--------
+::
+
+ varargs object *FindBestArmours(mixed type, int maxmon, int maxw,
+ mapping minac, mixed restr)
+
+
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/shop.c
+
+
+
+ARGUMENTE
+---------
+::
+
+ type - gewuenschter Ruestungstyp / Ruestungstypen
+ maxmon - Geld das ausgegeben werden darf
+ maxw - Maximales Gewicht
+ minac - minimale gewuenschte Ruestungsklasse pro Typ
+ restr - zusaetzliches Argument fuer CheckFindRestrictions()
+
+BESCHREIBUNG
+------------
+::
+
+ Sucht die besten Ruestungen, die der Laden verkaufen kann.
+
+
+
+RUECKGABEWERT
+-------------
+::
+
+ Die besten Ruestungen
+
+
+
+BEMERKUNG
+---------
+::
+
+ Die Qualitaet der Ruestung wird mit EvalArmour() bestimmt.
+ Haben zwei Ruestungen die gleiche Qualitaet,
+ wird die preiswertere genommen.
+
+
+
+BEISPIEL
+--------
+::
+
+ FindBestArmours(AT_ARMOUR,5000)
+ Bestes Ruestung unter 5000 Muenzen.
+
+ FindBestArmours(({AT_ARMOUR,AT_CLOAK,AT_BOOT}),10000,([AT_ARMOUR:20]))
+ Finded beste Ruestung, Umhang und Schuhe, die der Laden fuer
+ insgesamt 10000 Muenzen verkaufen kann, wobei die Ruestung mindestens
+ AC 20 haben muss.
+
+SIEHE AUCH
+----------
+::
+
+ FindBestWeapon(), CheckFindRestrictions(), EvalArmour()
+
diff --git a/doc/sphinx/lfun/FindBestWeapon.rst b/doc/sphinx/lfun/FindBestWeapon.rst
new file mode 100644
index 0000000..ed8adcb
--- /dev/null
+++ b/doc/sphinx/lfun/FindBestWeapon.rst
@@ -0,0 +1,69 @@
+FindBestWeapon()
+================
+
+FUNKTION
+--------
+::
+
+ varargs object FindBestWeapon(mixed type, int maxmon, int maxw, int hands,
+ int minwc, mixed restr)
+
+
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/shop.c
+
+
+
+ARGUMENTE
+---------
+::
+
+ type - gewuenschter Waffentyp / Waffentypen
+ maxmon - Geld das ausgegeben werden darf
+ maxw - Maximales Gewicht
+ hands - Anzahl Haende, die die Waffe belegen darf
+ minwc - minimale gewuenschte Waffenklasse
+ restr - zusaetzliches Argument fuer CheckFindRestrictions()
+
+BESCHREIBUNG
+------------
+::
+
+ Sucht die beste Waffe, die der Laden verkaufen kann.
+
+
+
+RUECKGABEWERT
+-------------
+::
+
+ Die beste Waffe :-)
+
+
+
+BEMERKUNG
+---------
+::
+
+ Die Qualitaet der Waffe wird mit EvalWeapon() bestimmt.
+ Haben zwei Waffen die gleiche Qualitaet, wird die preiswertere genommen.
+
+
+
+BEISPIEL
+--------
+::
+
+ FindBestWeapon(WT_SWORD,5000,1)
+ Bestes einhaendiges Schwert unter 5000 Muenzen.
+
+SIEHE AUCH
+----------
+::
+
+ FindBestArmours(), CheckFindRestrictions(), EvalWeapon()
+
diff --git a/doc/sphinx/lfun/FindDistantEnemyVictim.rst b/doc/sphinx/lfun/FindDistantEnemyVictim.rst
new file mode 100644
index 0000000..ef0dc66
--- /dev/null
+++ b/doc/sphinx/lfun/FindDistantEnemyVictim.rst
@@ -0,0 +1,57 @@
+FindDistantEnemyVictim()
+========================
+
+FUNKTION
+--------
+::
+
+ object FindDistantEnemyVictim(string wen, object pl, string msg,
+ int dist, int dy)
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ wen - id des gewuenschten Gegners, falls nicht angegeben:
+ SelectEnemy(FindDistantGroup(pl,-1,dist,dy,10000)
+ pl - Caster.
+ msg - Nachricht falls Gegner nicht anwesend ist.
+ dist - Entfernung
+ dy - 2*erlaubte Abweichung von der Entfernung, default 100
+
+BESCHREIBUNG
+------------
+::
+
+ Findet einen Gegner in Entfernung dist-dy/2 bis dist+dy/2
+ z.B. fuer einen Angriffsspruch.
+
+
+
+RUECKGABEWERT
+-------------
+::
+
+ Der Auserwaehlte :-)
+
+BEMERKUNGEN
+-----------
+::
+
+ 1. Der Gegner wird auf jeden Fall angegriffen.
+ 2. dist wird mit SA_RANGE modifiziert,
+ dy wird mit SA_EXTENSION modifiziert.
+ 3. Die Entfernung ist relativ zum Spieler.
+
+SIEHE AUCH
+----------
+::
+
+ teams, FindEnemyVictim, FindNearEnemyVictim, FindFarEnemyVictim
+
diff --git a/doc/sphinx/lfun/FindDistantGroup.rst b/doc/sphinx/lfun/FindDistantGroup.rst
new file mode 100644
index 0000000..95e65b0
--- /dev/null
+++ b/doc/sphinx/lfun/FindDistantGroup.rst
@@ -0,0 +1,53 @@
+FindDistantGroup()
+==================
+
+FUNKTION
+--------
+::
+
+ varargs object *FindDistantGroup(object pl, int who,
+ int dist, int dy, int dx)
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ pl - Caster
+ who - 1=Freunde, -1=Gegner, 0=beide
+ dist - Entfernung
+ dy - Tiefe (default 100)
+ dx - Breite (default 100*MAX_TEAM_ROWLEN)
+
+BESCHREIBUNG
+------------
+::
+
+ Ermittelt Lebewesen, die sich in Entfernung <dist> in einem Bereich
+ der Breite <dx> und Tiefe <dy> befinden.
+
+RUECKGABEWERT
+-------------
+::
+
+ Array mit den gefundenen Lebewesen.
+
+BEMERKUNGEN
+-----------
+::
+
+ Genauere Hinweise unter "FindDistantGroups".
+ Wer sowohl Freunde wie auch Feinde in getrennten Arrays braucht,
+ sollte FindDistantGroups statt FindDistantGroup verwenden.
+
+SIEHE AUCH
+----------
+::
+
+ teams, FindDistantGroups
+
diff --git a/doc/sphinx/lfun/FindDistantGroups.rst b/doc/sphinx/lfun/FindDistantGroups.rst
new file mode 100644
index 0000000..eb81f35
--- /dev/null
+++ b/doc/sphinx/lfun/FindDistantGroups.rst
@@ -0,0 +1,85 @@
+FindDistantGroups()
+===================
+
+FUNKTION
+--------
+::
+
+ varargs mixed FindDistantGroups(object pl, int dist, int dy, int dx)
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ pl - Caster
+ dist - Entfernung
+ dy - Tiefe (default 100)
+ dx - Breite (default 100*MAX_TEAM_ROWLEN)
+
+BESCHREIBUNG
+------------
+::
+
+ Ermitteld feindliche (bei Spielern NPCs, bei NPCs Spieler) und
+ freundliche (bei Spielern Spieler, bei NPCs NPCs) Lebewesen,
+ die sich in Entfernung <dist> in einem Bereich der Breite <dx>
+ und Tiefe <dy> befinden.
+
+RUECKGABEWERT
+-------------
+::
+
+ Array mit zwei Arrays als Inhalt:
+ ({ feindliche Lebewesen, freundliche Lebewesen })
+
+BEMERKUNGEN
+-----------
+::
+
+ Die Entfernungsangaben sind als cm. zu verstehen.
+ Jedes Lebewesen belegt 50cm x 50cm mit Abstand 50cm
+ zum naechsten Lebewesen in jeder Richtung.
+ Die Breitenangabe wirkt sich nur in der Anzahl der
+ Lebewesen aus, die zufaellig pro Reihe ausgewaehlt werden.
+ Die Skillattribute SA_RANGE und SA_EXTENSION werden beruecksichtigt.
+
+BEISPIEL
+--------
+::
+
+ dist=200, dy=200, dx=200, ein Punkt = 50cm x 50cm
+ . . . . . . . . . . . . .
+ 3. . . . . . . G . . . . . .
+ . . . . . . . . . . . . .
+ 2. . . . . . G . G . . . . .dist+dy/2-+
+ . . . . . . . . . . . . . |
+ 1. . . . . G . G . G . . . . dist +-+ (Gegner G)
+ ---.-.-.-.-.-.-.-.-.-.-.-.-. | |
+ 1. . . . . F . F . F . . . .dist-dy/2-+ | (Freunde F)
+ . . . . . . . . . . . . . |
+ 2. . . . . . F . S . . . . .------------+ (Reihe des Spielers S)
+ . . . . . . . . . . . . .
+ 3. . . . . . . F . . . . . .
+ . . . . . . . . . . . . .
+ Abgedeckter Bereich: 100cm bis 300cm
+ Reihe 3: 375cm..425cm 375>300 -> nicht erwischt
+ Reihe 2: 275cm..325cm 275<300 -> erwischt
+ Gegner Reihe 1: 175cm..225cm 100<175,225<300 -> erwischt
+ Freunde Reihe 1: 75cm..125cm 100<125 -> erwischt
+ Reihe 2: -25cm...25cm 100> 25 -> nicht erwischt
+ Reihe 3: -125cm..-75cm 100>-75 -> nicht erwischt
+ Ergebnis: ({({G,G,G,G}),({F,F})})
+ (Maximal 2 Lebewesen pro Reihe bei Breite 200).
+
+SIEHE AUCH
+----------
+::
+
+ teams, FindDistantGroup
+
diff --git a/doc/sphinx/lfun/FindEnemyVictim.rst b/doc/sphinx/lfun/FindEnemyVictim.rst
new file mode 100644
index 0000000..8dad745
--- /dev/null
+++ b/doc/sphinx/lfun/FindEnemyVictim.rst
@@ -0,0 +1,49 @@
+FindEnemyVictim()
+=================
+
+FUNKTION
+--------
+::
+
+ object FindEnemyVictim(string wen, object pl, string msg)
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ wen - id des gewuenschten Gegners, falls nicht angegeben SelectEnemy.
+ pl - Caster.
+ msg - Nachricht falls Gegner nicht anwesend ist.
+
+BESCHREIBUNG
+------------
+::
+
+ Findet einen Gegner, z.B. fuer einen Angriffsspruch.
+
+
+
+RUECKGABEWERT
+-------------
+::
+
+ Der Auserwaehlte :-)
+
+BEMERKUNGEN
+-----------
+::
+
+ Der Gegner wird auf jeden Fall angegriffen.
+
+SIEHE AUCH
+----------
+::
+
+ FindLivingVictim
+
diff --git a/doc/sphinx/lfun/FindFarEnemyVictim.rst b/doc/sphinx/lfun/FindFarEnemyVictim.rst
new file mode 100644
index 0000000..782aa22
--- /dev/null
+++ b/doc/sphinx/lfun/FindFarEnemyVictim.rst
@@ -0,0 +1,55 @@
+FindFarEnemyVictim()
+====================
+
+FUNKTION
+--------
+::
+
+ object FindFarEnemyVictim(string wen, object pl, string msg,
+ int min, int max)
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ wen - id des gewuenschten Gegners, SelectFarEnemy falls n/a.
+ pl - Caster.
+ msg - Nachricht falls Gegner nicht anwesend ist.
+ min - minimale Kampfreihe
+ max - maximale Kampfreihe
+
+BESCHREIBUNG
+------------
+::
+
+ Findet einen Gegner aus Kampfreihe <min> bis <max>
+ z.B. fuer einen Angriffsspruch.
+
+
+
+RUECKGABEWERT
+-------------
+::
+
+ Der Auserwaehlte :-)
+
+BEMERKUNGEN
+-----------
+::
+
+ 1. Der Gegner wird auf jeden Fall angegriffen.
+ 2. Die Reihenangaben werden NICHT mit Skillattributen modifiziert.
+ 3. Die Angabe der Reihe ist absolut.
+
+SIEHE AUCH
+----------
+::
+
+ teams, FindEnemyVictim, FindNearEnemyVictim, FindDistantEnemyVictim
+
diff --git a/doc/sphinx/lfun/FindGroup.rst b/doc/sphinx/lfun/FindGroup.rst
new file mode 100644
index 0000000..d4ad65d
--- /dev/null
+++ b/doc/sphinx/lfun/FindGroup.rst
@@ -0,0 +1,99 @@
+FindGroup()
+===========
+
+FUNKTION
+--------
+::
+
+ object*FindGroup(object pl,int who);
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ pl
+ Lebewesen, von welchem die Freunde oder Feinde in der Umgebung
+ gefunden werden sollen.
+ who
+ Flag, welches anzeigt, ob Freunde oder Feinde gefunden werden
+ sollen (Konstanten definiert in '/sys/new_skills.h'):
+ FG_ENEMIES - (Wert -1) Feinde sollen gefunden werden
+ FG_FRIENDS - (Wert 1) Freunde sollen gefunden werden
+ FG_ALL - (Wert 0) alle Lebewesen sollen gefunden werden
+
+RUeCKGABEWERT
+-------------
+::
+
+ Array mit gefundenen Lebewesen
+
+BESCHREIBUNG
+------------
+::
+
+ Bei Spells, die sich auf mehrere Gegner auswirken oder bei denen man
+ per Hand ein Opfer auswaehlen moechte, laesst sich mittels der
+ Funktion FindGroup() eine Liste von Lebewesen ermitteln, welche in
+ der Umgebung von <pl> zu finden sind.
+ Je nachdem, was man denn genau vorhat, kann man sich von der
+ Funktion freundlich oder feindlich gesinnte Lebewesen heraussuchen
+ lassen.
+ Will man die freundlich gesinnten Lebewesen ermitteln, so uebergibt
+ man in <who> die Konstante FG_FRIENDS, bei feindlich gesinnten die
+ Konstante FG_ENEMIES, und wenn man alle Lebewesen bekommen moechte
+ schliesslich FG_ALL.
+ Bei der Auswahl gelten folgende Regeln:
+ (1) Lebewesen, mit denen <pl> im Kampf ist, sind grundsaetzlich
+ feindlich gesinnt.
+ (2) Teammitglieder von <pl> sind grundsaetzlich freundlich
+ gesinnt.
+ (3) Spieler sind gegenueber Spielern freundlich gesinnt, NPCs
+ gegenueber NPCs. NPCs kann man hierbei mit Hilfe der Property
+ P_FRIEND den Spielern zuordnen.
+ (4) Daraus folgt natuerlich, dass Spieler und NPCs grundsaetzlich
+ eine feindliche Einstellung gegenueber haben, sofern die NPCs
+ nicht die Property P_FRIEND gesetzt haben
+ (was standardmaessig natuerlich nicht der Fall ist).
+ (5) Netztote werden nicht erkannt.
+ (6) Magier werden nicht erkannt, wenn sie unsichtbar sind.
+ (7) Ein Magier wird als feindlich gesinnt nur dann erkannt, wenn
+ <pl> mit ihm im Kampf ist.
+ (6) Sucht man feindlich gesinnte Lebewesen, so werden die, welche
+ eine von den Properties P_NO_ATTACK oder P_NO_GLOBAL_ATTACK
+ gesetzt haben, nicht erkannt.
+ Die Property P_FRIEND sollte man in NPCs setzen, die dem Spieler
+ hilfreich beiseite stehen, z.B. vom Spieler beschworene HilfsNPCs.
+
+BEISPIELE
+---------
+::
+
+ Wenn man einen Feuerball nach jemandem wirft, so trifft dieser unter
+ Umstaenden auch andere, wenn er gross genug ist. Man nimmt hierbei
+ an, dass sich die freundlich gesinnten Lebewesen des Gegners auch
+ naeher bei ihm befinden als die feindlich gesinnten:
+ victim->Defend(500,DT_FIRE,([SP_SHOW_DAMAGE:1]),caster);
+ victimList=FindGroup(victim,FG_FRIENDS);
+ map_objects(victimList,
+ "Defend",
+ 100,
+ DT_FIRE,
+ ([SP_SHOW_DAMAGE:1]),
+ caster);
+ Hiermit trifft man also auch die Freunde von <victim>.
+
+SIEHE AUCH
+----------
+::
+
+ FindGroupN(), FindGroupP(), P_FRIEND, P_NO_GLOBAL_ATTACK
+
+
+Last modified: Mon Jan 28 21:45:00 2002 by Tiamak
+
diff --git a/doc/sphinx/lfun/FindGroupN.rst b/doc/sphinx/lfun/FindGroupN.rst
new file mode 100644
index 0000000..ec436fb
--- /dev/null
+++ b/doc/sphinx/lfun/FindGroupN.rst
@@ -0,0 +1,68 @@
+FindGroupN()
+============
+
+FUNKTION
+--------
+::
+
+ object*FindGroupN(object pl,int who,int n);
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ pl
+ Lebewesen, von welchem die Freunde oder Feinde in der Umgebung
+ gefunden werden sollen.
+ who
+ Flag, welches anzeigt, ob Freunde oder Feinde gefunden werden
+ sollen (Konstanten definiert in '/sys/new_skills.h'):
+ FG_ENEMIES - (Wert -1) Feinde sollen gefunden werden
+ FG_FRIENDS - (Wert 1) Freunde sollen gefunden werden
+ FG_ALL - (Wert 0) alle Lebewesen sollen gefunden werden
+ n
+ Anzahl der Lebewesen, die zurueckgegeben werden sollen.
+ Hierbei geht vorher noch das Skillattribute SA_EXTENSION ein!
+ Es wird mindestens 1 Lebewesen zurueckgeliefert (sofern gefunden).
+
+RUeCKGABEWERT
+-------------
+::
+
+ Array mit gefundenen Lebewesen
+
+BESCHREIBUNG
+------------
+::
+
+ Ausgesucht werden die Lebewesen genauso wie bei FindGroup(), nur
+ dass zum Schluss die Anzahl noch begrenzt wird.
+
+BEISPIELE
+---------
+::
+
+ Man moechte maximal 5 Feinde finden, die man gleichzeitig mit einem
+ Spell belegen kann:
+ enemyList=FindGroupN(caster,FG_ENEMIES,5);
+ Dies gilt jedoch nur bei SA_EXTENSION==100, sonst wird
+ dementsprechend mehr oder weniger zurueckgegeben.
+ (also bei SA_EXTENSION==200 doppelt so viele -> 10 Lebewesen)
+ Das Skillattribute SA_EXTENSION kann auch durch SA_QUALITY
+ veraendert worden sein; das sollte beachtet werden.
+
+SIEHE AUCH
+----------
+::
+
+ FindGroup(), FindGroupP(), P_FRIEND, P_NO_GLOBAL_ATTACK
+
+
+Last modified: Mon Jan 25 15:04:31 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/FindGroupP.rst b/doc/sphinx/lfun/FindGroupP.rst
new file mode 100644
index 0000000..6545e01
--- /dev/null
+++ b/doc/sphinx/lfun/FindGroupP.rst
@@ -0,0 +1,69 @@
+FindGroupP()
+============
+
+FUNKTION
+--------
+::
+
+ object*FindGroupP(object pl,int who,int pr);
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ pl
+ Lebewesen, von welchem die Freunde oder Feinde in der Umgebung
+ gefunden werden sollen.
+ who
+ Flag, welches anzeigt, ob Freunde oder Feinde gefunden werden
+ sollen (Konstanten definiert in '/sys/new_skills.h'):
+ FG_ENEMIES - (Wert -1) Feinde sollen gefunden werden
+ FG_FRIENDS - (Wert 1) Freunde sollen gefunden werden
+ FG_ALL - (Wert 0) alle Lebewesen sollen gefunden werden
+ pr
+ Wahrscheinlichkeit, mit der ein Lebewesen ausgesucht werden soll.
+ Hierbei geht vorher noch das Skillattribute SA_EXTENSION ein!
+
+RUeCKGABEWERT
+-------------
+::
+
+ Array mit gefundenen Lebewesen
+
+BESCHREIBUNG
+------------
+::
+
+ Ausgesucht werden die Lebewesen genauso wie bei FindGroup(), nur
+ dass zum Schluss die einzelnen Lebewesen per Zufall ausgewaehlt
+ werden. Es ist also nicht gesichert, dass ueberhaupt ein Lebewesen
+ zurueckgeliefert wird, trotzdem welche gefunden wurden.
+
+BEISPIELE
+---------
+::
+
+ Man moechte im Schnitt 50% der Feinde finden, die man gleichzeitig
+ mit einem Spell belegt:
+ enemyList=FindGroupP(caster,FG_ENEMIES,50);
+ Dies gilt jedoch nur bei SA_EXTENSION==100, sonst wird mit
+ dementsprechend mehr oder weniger Wahrscheinlichkeit zurueckgegeben.
+ (also bei SA_EXTENSION==200 doppelt so viele -> 100%, also alle)
+ Das Skillattribute SA_EXTENSION kann auch durch SA_QUALITY
+ veraendert worden sein; das sollte beachtet werden.
+
+SIEHE AUCH
+----------
+::
+
+ FindGroup(), FindGroupP(), P_FRIEND, P_NO_GLOBAL_ATTACK
+
+
+Last modified: Mon Jan 25 15:04:31 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/FindNearEnemyVictim.rst b/doc/sphinx/lfun/FindNearEnemyVictim.rst
new file mode 100644
index 0000000..3af915e
--- /dev/null
+++ b/doc/sphinx/lfun/FindNearEnemyVictim.rst
@@ -0,0 +1,50 @@
+FindNearEnemyVictim()
+=====================
+
+FUNKTION
+--------
+::
+
+ object FindNearEnemyVictim(string wen, object pl, string msg)
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ wen - id des gewuenschten Gegners, SelectNearEnemy falls n/a.
+ pl - Caster.
+ msg - Nachricht falls Gegner nicht anwesend ist.
+
+BESCHREIBUNG
+------------
+::
+
+ Findet einen im Nahkampf erreichbaren Gegner,
+ z.B. fuer einen Angriffsspruch.
+
+
+
+RUECKGABEWERT
+-------------
+::
+
+ Der Auserwaehlte :-)
+
+BEMERKUNGEN
+-----------
+::
+
+ Der Gegner wird auf jeden Fall angegriffen.
+
+SIEHE AUCH
+----------
+::
+
+ teams, FindEnemyVictim, FindFarEnemyVictim, FindDistantEnemyVictim
+
diff --git a/doc/sphinx/lfun/FindPotion.rst b/doc/sphinx/lfun/FindPotion.rst
new file mode 100644
index 0000000..834485f
--- /dev/null
+++ b/doc/sphinx/lfun/FindPotion.rst
@@ -0,0 +1,74 @@
+FindPotion()
+============
+
+FUNKTION
+--------
+::
+
+ varargs int FindPotion(string s);
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/potion.c
+
+ARGUMENTE
+---------
+::
+
+ string s
+ Ausgabetext. Wenn 0/Leerstring, wird Default verwendet.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion gibt einem aufrufenden Spieler eventuell diesen ZT.
+
+
+
+ Das aufrufende Spielerobjekt muss dafuer:
+ * diesen ZT im Potionmaster in seiner Liste eingetragen haben
+ * diesen ZT in der Liste der bekannten Traenke haben (durch
+ Orakel also fuer ihn auch freigeschaltet)
+ * darf keine Playerkills haben (P_KILLS)
+ * darf nicht im Editiermodus sein
+ * darf kein Geist sein (Ausnahme: Geisterschloss)
+
+ Wenn alle Kriterien erfolgreich erfuellt sind, wird 's' oder
+ "Du findest einen Zaubertrank, den Du sofort trinkst." ausgegeben
+ und dem Spieler ggf die Wahl der Attribute gegeben.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0 bei Nichtvergabe, 1 bei erfolgreicher Vergabe.
+
+BEISPIELE
+---------
+::
+
+ string detail_papiere() {
+ if (this_player()->FindPotion(
+ break_string("Beim Rumwuehlen in den Papieren entdeckst Du einen "
+ "kleinen Zaubertrank, den Du sofort trinkst.", 78)))
+ return "";
+ // Es muss ein String zurueckgegeben werden, da man sonst
+ // die Fehlermeldung "Sowas siehst du hier nicht." bekommt
+ else
+ return "Die Papiere sind alle unbeschriftet.\n";
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
+ Verwandt: AddKnownPotion(), RemoveKnownPotion(), InList()
+ Props: P_POTIONROOMS, P_KNOWN_POTIONROOMS
+ Befehl: traenke (fuer Magier zum Einschalten des Findens von ZTs)
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/lfun/FindRangedTarget.rst b/doc/sphinx/lfun/FindRangedTarget.rst
new file mode 100644
index 0000000..93c9178
--- /dev/null
+++ b/doc/sphinx/lfun/FindRangedTarget.rst
@@ -0,0 +1,63 @@
+FindRangedTarget()
+==================
+
+FUNKTION
+--------
+::
+
+ static string FindRangedTarget(string str, mapping shoot)
+
+DEFINIERT IN
+------------
+::
+
+ /std/ranged_weapon.c
+
+ARGUMENTE
+---------
+::
+
+ string str - Schusssyntax
+ mapping shoot - Schussdaten
+
+BESCHREIBUNG
+------------
+::
+
+ Erhaelt von /std/ranged_weapon::cmd_shoot() die Schussdaten und eine
+ eventuell bereits modifizierte Syntax und versucht einen passenden Gegner
+ im Raum oder im Gebiet (P_SHOOTING_AREA) zu finden.
+ Dieser wird in SI_ENEMY im Mapping 'shoot' eingetragen und ein Wert != 0
+ zurueckgegeben.
+
+RUECKGABEWERT
+-------------
+::
+
+ 0 bei Fehlschlag
+ != 0 bei gueltigem SI_ENEMY in 'shoot'
+
+BEMERKUNGEN
+-----------
+::
+
+ 'shoot' enthaelt normalerweise folgende Eintraege:
+ * Key P_WEAPON: die Schusswaffe
+ * Key P_WEAPON_TYPE: P_AMMUNITION, also die Munitions-ID
+ * Key P_STRETCH_TIME: P_STRETCH_TIME der Waffe
+ * Key P_WC: P_SHOOTING_WC der Waffe
+
+SIEHE AUCH
+----------
+::
+
+ Generell: P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
+ Methoden: shoot_dam(L), cmd_shoot(L)
+ Gebiet: P_RANGE, P_SHOOTING_AREA, P_TARGET_AREA
+ Team: PresentPosition(L)
+ Suche: present, SelectFarEnemy(L)
+ Syntax: _unparsed_args(L)
+ Sonstiges: fernwaffen
+
+28.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/lfun/Flee.rst b/doc/sphinx/lfun/Flee.rst
new file mode 100644
index 0000000..a0ab6f7
--- /dev/null
+++ b/doc/sphinx/lfun/Flee.rst
@@ -0,0 +1,92 @@
+Flee()
+======
+
+FUNKTION
+--------
+::
+
+ public varargs void Flee( object oldenv, int force )
+
+DEFINIERT IN
+------------
+::
+
+ /sys/living/combat.h
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ oldenv
+ Ein Raum oder 0.
+ Wird ein Raum angegeben, dann muss sich der Fluechtende in diesem
+ Raum befinden, damit er versucht, zu fluechten, es sei denn, das
+ optionale Flag "force" ist gesetzt.
+ force
+ 1, wenn der spieler unabhaengig von seiner Vorsicht fluechten soll.
+ 0 sonst.
+
+BESCHREIBUNG
+------------
+::
+
+ Flee() wird im heart_beat() oder von CheckWimpyAndFlee() aufgerufen,
+ um den Spieler fluechten zu lassen. Man kann die Funktion im Spieler
+ auch "von Hand" aufrufen, beispielsweise in einem Spell. Man sollte
+ dann force auf 1 setzen, damit der Spieler unabhaengig von seiner
+ Vorsicht fluechtet.
+ Hierbei kann die Flucht dazu fuehren, dass man die Teamreihe wechselt,
+ aber auch, dass man den Raum verlaesst.
+
+
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+BEISPIELE
+---------
+::
+
+ this_player()->Flee(0, 1);
+ // Der Spieler soll fluechten, egal, ob seine Lebenspunkte geringer
+ // als seine Vorsicht sind und unabhaengig von seiner Position.
+
+
+
+ this_player()->Flee( find_object("/gilden/abenteurer") );
+ // Der Spieler soll fluechten, wenn er sich in der Abenteurergilde
+ // befindet (oder wenn diese nicht existiert)
+
+
+
+ this_player()->Flee( "/gilden/abenteurer" );
+ // Der Spieler wird nicht fluechten, da der Vergleich von Dateiname
+ // und dem Raum 0 ergibt.
+
+ this_player()->Flee( find_object("/gilden/abenteurer"), 1);
+ // Der Spieler soll auf jeden Fall fluechten, egal ob er sich in der
+ // Abenteurergilde befindet oder nicht. Grund: Gesetztes force-Flag.
+
+
+
+
+
+
+
+SIEHE AUCH
+----------
+::
+
+ CheckWimpyAndFlee(), Defend(), heart_beat(),
+
+
+Last modified: Wed Nov 12 14:44:42 2003 by Bambi
+
diff --git a/doc/sphinx/lfun/FreeHands.rst b/doc/sphinx/lfun/FreeHands.rst
new file mode 100644
index 0000000..6c6e088
--- /dev/null
+++ b/doc/sphinx/lfun/FreeHands.rst
@@ -0,0 +1,60 @@
+FreeHands()
+===========
+
+FUNKTION
+--------
+::
+
+ public varargs int FreeHands(object ob)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ ob - das Objekt, dessen Handnutzung vorbei ist
+ - kann 0 sein, dann wird PO benutzt
+
+RUECKGABEWERT
+-------------
+::
+
+ 0, wenn kein Objekt uebergeben wurde oder kein PO existiert
+ 1, sonst
+
+BESCHREIBUNG
+------------
+::
+
+ Befreit die Haende eines Livings von ein bestimmten Objekt.
+ Es werden _alle_ Haende wieder freigegeben.
+
+BEISPIELE
+---------
+::
+
+ > halte seil fest
+ ...
+ this_player()->UseHands(this_object(),2);
+ ...
+
+ > lasse seil los
+ ...
+ this_player()->FreeHands(this_object());
+ ...
+
+SIEHE AUCH
+----------
+::
+
+ P_HANDS, P_HANDS_USED_BY
+ P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
+ UseHands
+
+1.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/GetAquarium.rst b/doc/sphinx/lfun/GetAquarium.rst
new file mode 100644
index 0000000..bd4e13d
--- /dev/null
+++ b/doc/sphinx/lfun/GetAquarium.rst
@@ -0,0 +1,60 @@
+GetAquarium()
+=============
+
+FUNKTION
+--------
+::
+
+ varargs public string* GetAquarium(object angel)
+
+ARGUMENTE
+---------
+::
+
+ Das optionale Argument <angel> ist die Angel selbst.
+
+BESCHREIBUNG
+------------
+::
+
+ Die Funktion wird beim Angeln in Raeumen gerufen, wenn diese als
+ Gewaessertyp W_USER gesetzt haben (siehe Manpage zu P_WATER).
+ Aus der zurueckgegebenen Liste der Pfade wird einer zufaellig aus-
+ gewaehlt und das Objekt geclont.
+
+RUECKGABEWERT
+-------------
+::
+
+ String-Array mit Pfadnamen zu den in diesem Raum fangbaren Fischen.
+
+BEMERKUNG
+---------
+::
+
+ Man kann die Fangchancen durch Mehrfachnennung einzelner Eintraege
+ modifizieren. Es muss sich bei den Eintraegen um lad- und clonebare
+ Objekte handeln.
+ Fuer selbstprogrammierte Fische ist das Basisobjekt
+ /std/items/fishing/fish zu verwenden. Einige vorgefertigte Fische
+ finden sich darueber hinaus in /items/fishing/aquarium/
+
+BEISPIEL
+--------
+::
+
+ varargs string* GetAquarium(object angel) {
+ return ({"/d/dschungel/rikus/q4e/obj/stichling",
+ "/d/dschungel/rikus/q4e/obj/karpfen",
+ "/p/seher/partymonster/obj/fisch"});
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Properties: P_WATER, P_FISH
+
+
+zuletzt geaendert: 2014-Sep-02, Arathorn
+
diff --git a/doc/sphinx/lfun/GetDetail.rst b/doc/sphinx/lfun/GetDetail.rst
new file mode 100644
index 0000000..2f75779
--- /dev/null
+++ b/doc/sphinx/lfun/GetDetail.rst
@@ -0,0 +1,90 @@
+GetDetail()
+===========
+
+FUNKTION
+--------
+::
+
+ varargs string GetDetail(string key, string race, int sense)
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ key
+ Das zu ermittelnde Detail.
+ race
+ Rasse des ermittelnden Objektes (falls es ein Lebewesen ist).
+ sense
+ Die Art des zu untersuchenden Details:
+ Untersuchen, Riechen, Hoeren, Tasten.
+
+BESCHREIBUNG
+------------
+::
+
+ Die Beschreibung des gewuenschten Details wird ermittelt. Dabei
+ werden rassenspezifische Details beruecksichtigt. Es gibt hierbei
+ verschiedene Detailarten, deren Typ man in <sense> angibt:
+ SENSE_VIEW - Fuer Defaultdetails zum Untersuchen.
+ SENSE_SMELL - Fuer Details, die man riechen kann.
+ SENSE_SOUND - Fuer Details, die man hoeren kann.
+ SENSE_TOUCH - Fuer Details, die man abtasten kann.
+ SENSE_READ - Fuer Details, die man lesen kann.
+
+ Dabei ist 0 == SENSE_VIEW.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Die Beschreibung des Details oder 0, wenn es dieses Detail nicht
+ gibt.
+
+BEISPIEL
+--------
+::
+
+ Im folgenden wird ein kleines Testdetail generiert:
+ AddDetail("test","Das ist ein Test!\n");
+ Im folgenden wird das Detail entfernt, wenn es existiert. Dies ist
+ eigentlich nicht noetig, da RemoveDetail() damit zurechtkommt, aber
+ eventuell sind ja noch weitere Aktionen noetig.
+ if(GetDetail("test"))
+ { RemoveDetail("test");
+ ...
+ }
+ Ein Geruch kann man folgendermassen erzeugen:
+ AddSmells("gold",
+ ([0 :"Gold kann man nicht riechen!\n",
+ "zwerg":"Deine trainierte Nase riecht es muehelos!\n"]));
+ Die Abfrage des Details gestaltet sich recht einfach:
+ GetDetail("gold","zwerg",SENSE_SMELL);
+ Die Funktion liefert das Detail fuer den Zwerg.
+ GetDetail("gold",0,SENSE_SMELL);
+ Die Funktion liefert das Detail fuer die restlichen Rassen.
+ GetDetail("gold",0,SENSE_SOUND);
+ Ein Sounddetail mit dem Namen "gold" existiert nicht, die Funktion
+ liefert 0 zurueck.
+
+SIEHE AUCH
+----------
+::
+
+ Setzen: AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+ AddTouchDetail()
+ Loeschen: RemoveReadDetail(), RemoveSmells(), RemoveDetail(),
+ RemoveSounds(), RemoveTouchDetail()
+ Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS,
+ P_TOUCH_DETAILS, P_SPECIAL_DETAILS
+ Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+ Sonstiges: break_string()
+
+27. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/lfun/GetDoorsMapping.rst b/doc/sphinx/lfun/GetDoorsMapping.rst
new file mode 100644
index 0000000..2a6d920
--- /dev/null
+++ b/doc/sphinx/lfun/GetDoorsMapping.rst
@@ -0,0 +1,46 @@
+GetDoorsMapping()
+=================
+
+FUNKTION
+--------
+::
+
+ mapping GetDoorsMapping()
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion erhaelt man das Mapping der vorhandenen
+ Seherportale.
+
+
+
+ Die Struktur ist von der Form:
+ ([ Pfad: Portalnummer; Portalbeschreibung, ])
+ Es wird eine Kopie dieses Mappings geliefert.
+
+RUECKGABEWERT
+-------------
+::
+
+ Das Sehertormapping
+
+BEMERKUNGEN
+-----------
+::
+
+ Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
+
+BEISPIELE
+---------
+::
+
+ "/d/seher/portale/sehertormaster"->GetDoorsMapping();
+
+SIEHE AUCH
+----------
+::
+
+ DoorIsKnown, ShowDoors, Teleport, DiscoverDoor
+
diff --git a/doc/sphinx/lfun/GetEnemies.rst b/doc/sphinx/lfun/GetEnemies.rst
new file mode 100644
index 0000000..fbd9f6b
--- /dev/null
+++ b/doc/sphinx/lfun/GetEnemies.rst
@@ -0,0 +1,54 @@
+GetEnemies()
+============
+
+FUNKTION
+--------
+::
+
+ mapping GetEnemies();
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+RUeCKGABEWERT
+-------------
+::
+
+ Mapping mit bekannten Gegnern als Schluessel und Zeiten als
+ Eintraegen.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert das interne Mapping zurueck, in dem alle
+ Gegner abgespeichert sind. Diese Gegner stellen die Schluessel in
+ dem Mapping dar. Als Eintraege sind die Zeiten vermerkt, nach
+ welcher Zeit ein Gegner automatisch wieder vergessen werden soll.
+ Mehr Informationen dazu sind in der Dokumentation zur aehnlich
+ gearteten Funktion QueryEnemies() zu finden, die jedoch zwei Arrays
+ getrennte zurueckliefert.
+ Achtung: Es wird keine Kopie des Mappings erstellt. Saemtliche
+ Veraenderungen in dem Mapping wirken sich unmittelbar auf die
+ interne Gegnerliste aus. Die Funktion sollte deshalb nicht genutzt
+ werden. Gegner ein- und austragen sollte man nur mittels
+ InsertEnemy() und StopHuntFor().
+
+SIEHE AUCH
+----------
+::
+
+ QueryEnemies(), SetEnemies(), InsertEnemy(), StopHuntFor()
+
+
+Last modified: Wed May 26 16:47:51 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/GetExits.rst b/doc/sphinx/lfun/GetExits.rst
new file mode 100644
index 0000000..583283d
--- /dev/null
+++ b/doc/sphinx/lfun/GetExits.rst
@@ -0,0 +1,46 @@
+GetExits()
+==========
+
+FUNKTION
+--------
+::
+
+ varargs string GetExits(object viewer);
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/exits
+
+ARGUMENTE
+---------
+::
+
+ viewer
+ Derjenige, der sich die Ausgaenge anschaut.
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird eine Liste der fuer viewer sichtbaren Ausgaenge erstellt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ String mit der Liste der sichtbaren Ausgaenge.
+
+SIEHE AUCH
+----------
+::
+
+ AddExit(), AddSpecialExit(), GetExits(),
+ RemoveExit(), RemoveSpecialExit(),
+ GuardExit(),
+ H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
+ ausgaenge
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/GetFValue.rst b/doc/sphinx/lfun/GetFValue.rst
new file mode 100644
index 0000000..cc872d0
--- /dev/null
+++ b/doc/sphinx/lfun/GetFValue.rst
@@ -0,0 +1,47 @@
+GetFValue()
+===========
+
+FUNKTION
+--------
+::
+
+ varargs int GetFValue(string vname, mapping map, object pl)
+
+ARGUMENTE
+---------
+::
+
+ vname : name des parameters aus dem spellmapping
+ map : spellmapping
+ pl : caster
+
+BESCHREIBUNG
+------------
+::
+
+ Berechnet den Wert und den Factor des Parameters in spellmapping.
+
+RUECKGABEWERT
+-------------
+::
+
+ Berechneter Wert*Factor aus dem Spellmapping.
+
+BEMERKUNGEN
+-----------
+::
+
+ Ruft GetValue(vname,map,pl)*GetFactor(vname,map,pl)/100 auf.
+
+BEISPIEL
+--------
+::
+
+ xxx=GetFValue(SI_SKILLDAMAGE,sinfo,caster);
+
+Siehe auch:
+
+ "GetValue", "GetFactor", "GetOffset", "GetValueO", "GetFValueO"
+
+ Ausfuehrliches Beispiel siehe "GetFValueO".
+
diff --git a/doc/sphinx/lfun/GetFValueO.rst b/doc/sphinx/lfun/GetFValueO.rst
new file mode 100644
index 0000000..a2553a9
--- /dev/null
+++ b/doc/sphinx/lfun/GetFValueO.rst
@@ -0,0 +1,85 @@
+GetFValueO()
+============
+
+FUNKTION
+--------
+::
+
+ varargs int GetFValueO(string vname, mapping map, object pl)
+
+ARGUMENTE
+---------
+::
+
+ vname : name des parameters aus dem spellmapping
+ map : spellmapping
+ pl : caster
+
+BESCHREIBUNG
+------------
+::
+
+ 'Berechnet' den Wert, den Factor und den Offset des Parameters
+ in spellmapping.
+
+RUECKGABEWERT
+-------------
+::
+
+ Berechneter (Wert*Factor)/100+Offset aus dem Spellmapping.
+
+BEMERKUNGEN
+-----------
+::
+
+ Ruft (GetValue(vname,map,pl)*GetFactor(vname,map,pl))/100+
+ GetOffset(vname,map,pl) auf.
+
+BEISPIEL
+--------
+::
+
+ AddSpell("egal",10,
+ ([
+ OFFSET(SI_COST):([SM_RACE:(["Zwerg":4]) ]),
+ FACTOR(SI_COST):([SM_RACE:(["Mensch":90]) ]),
+ SI_SKILLDAMAGE:100,
+ OFFSET(SI_SKILLDAMAGE):25,
+ SI_SKILLDAMAGE_TYPE:DT_EXAMPLE,
+ FACTOR(SI_SKILLDAMAGE):([SM_RACE:(["Zwerg":80,"Elf":120]) ])
+ ]));
+
+ So, was sollen uns diese Zeilen sagen?
+
+ Es wird ein Spruch Names 'egal' ins Spellbook eingetragen. Er kostet
+ regulaer 10 MP. Fuer Zwerge allerdings wird ein Offset von 4 MP
+ aufgeschlagen. Ausserdem machen Zwerge nur 80% Schaden, Elfen
+ hingegen 120%. Der Grundschaden betraegt 100 Schadenspunkte, der
+ Offset des Schadens nochmal 25. Menschen bezahlen fuer diesen
+ Spruch nur 90% der Kosten.
+
+ Nun die Rechenbeispiele:
+
+ Fuer die Kosten:
+ Value ValueO FValue FValueO
+ Mensch 10 10 9 9
+ Elf 10 10 10 10
+ Hobbit 10 10 10 10
+ Zwerg 10 14 10 14
+
+ Fuer den Schaden:
+ Value ValueO FValue FValueO
+ Mensch 100 125 100 125
+ Elf 100 125 120 150
+ Hobbit 100 125 100 125
+ Zwerg 100 125 80 100
+
+ An diesem Beispiel sieht man deutlich, wie man mit ein paar
+ Offsets und Faktoren die Wirkung eines Spruches deutlich
+ veraendern kann. Es sollte bei eigenen Berechnungen immer
+ GetFValueO benutzt werden.
+
+Siehe auch:
+
+ "GetValue", "GetFactor", "GetOffset", "GetFValue", "GetValueO"
+
diff --git a/doc/sphinx/lfun/GetFactor.rst b/doc/sphinx/lfun/GetFactor.rst
new file mode 100644
index 0000000..80fef53
--- /dev/null
+++ b/doc/sphinx/lfun/GetFactor.rst
@@ -0,0 +1,48 @@
+GetFactor()
+===========
+
+FUNKTION
+--------
+::
+
+ varargs int GetFactor(string vname, mapping map, object pl)
+
+ARGUMENTE
+---------
+::
+
+ vname : name des parameters aus dem spellmapping
+ map : spellmapping
+ pl : caster
+
+BESCHREIBUNG
+------------
+::
+
+ 'Berechnet' den Factor des Parameters in spellmapping.
+
+RUECKGABEWERT
+-------------
+::
+
+ Berechneter Factor aus dem Spellmapping.
+
+BEMERKUNGEN
+-----------
+::
+
+ Beschraekung auf 10-1000. Werte groesser oder kleiner als diese
+ werden 'abgeschnitten'.
+
+BEISPIEL
+--------
+::
+
+ xxx=GetFactor(SI_SKILLDAMAGE,sinfo,caster);
+
+Siehe auch:
+
+ "GetValue", "GetOffset", "GetFValue", "GetValueO", "GetFValueO"
+
+ Ausfuehrliches Beispiel siehe "GetFValueO".
+
diff --git a/doc/sphinx/lfun/GetGroupMembers.rst b/doc/sphinx/lfun/GetGroupMembers.rst
new file mode 100644
index 0000000..f5ebfcc
--- /dev/null
+++ b/doc/sphinx/lfun/GetGroupMembers.rst
@@ -0,0 +1,60 @@
+GetGroupMembers()
+=================
+
+FUNKTION
+--------
+::
+
+ string *GetGroupMembers(string grp)
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/materialdb.c (MATERIALDB)
+
+ARGUMENTE
+---------
+::
+
+ string grp - Gruppenname
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt alle dieser Gruppe zugehoerigen Materialien zurueck. Dazu gut, sich
+ einen Ueberblick ueber die aktuelle Liste zu verschaffen.
+
+RUECKGABEWERT
+-------------
+::
+
+ Array von Strings mit Materialien oder ({})
+
+BEISPIELE
+---------
+::
+
+ // wir wollen irgend ein Metall haben, nennen dies aber beim Namen
+ int ind;
+ string* likeit;
+ likeit=MATERIALDB->GetGroupMembers(MATGROUP_METAL);
+ ind=random(sizeof(likeit));
+ ...
+ write("Der Schmied sagt: Mir fehlt noch "+
+ MATERIALDB->MaterialName(likeit[ind], WER, 100)+".\n");
+ ...
+
+SIEHE AUCH
+----------
+::
+
+ Konzepte: material, materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
+ GroupName(), MaterialName(),
+ GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/GetInfoArr.rst b/doc/sphinx/lfun/GetInfoArr.rst
new file mode 100644
index 0000000..dd21cb6
--- /dev/null
+++ b/doc/sphinx/lfun/GetInfoArr.rst
@@ -0,0 +1,55 @@
+GetInfoArr()
+============
+
+FUNKTION
+--------
+::
+
+ static mixed *GetInfoArr(string str)
+
+DEFINIERT IN
+------------
+::
+
+ /std/npc/info.c
+
+ARGUMENTE
+---------
+::
+
+ string str - Schluesselwort der Frage
+
+BESCHREIBUNG
+------------
+::
+
+ Sucht nach einem Schluesselwort in den abgelegten Antworten
+ und gibt die Informationen oder einen 0er-Array zurueck.
+
+BEMERKUNGEN
+-----------
+::
+
+ Ueberschreibbar :)
+
+RUECKGABEWERT
+-------------
+::
+
+ Siehe Parameter von AddInfo:
+
+ Array mit:
+ ({ <Infostring> (0 fuer keine Antwort),
+ <Indent-String> (Default: 0),
+ <Silent> (Default: 0),
+ <Casebased> (Default: 0)
+ })
+
+SIEHE AUCH
+----------
+::
+
+ Verwandt: AddInfo, do_frage
+
+31.Mar 2007 Gloinson
+
diff --git a/doc/sphinx/lfun/GetMatMembership.rst b/doc/sphinx/lfun/GetMatMembership.rst
new file mode 100644
index 0000000..8fe36a7
--- /dev/null
+++ b/doc/sphinx/lfun/GetMatMembership.rst
@@ -0,0 +1,79 @@
+GetMatMembership()
+==================
+
+FUNKTION
+--------
+::
+
+ string *GetMatMembership(string mat)
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/materialdb.c (MATERIALDB)
+
+ARGUMENTE
+---------
+::
+
+ string mat - ein Material
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt alle Gruppen, denen das Material angehoert zurueck. Geeignet, um
+ die Eigenschaften eines Materials zu ueberpruefen.
+
+RUECKGABEWERT
+-------------
+::
+
+ Array von Strings mit Materialiengruppen oder ({})
+
+BEISPIELE
+---------
+::
+
+ // ein weiser Schmied:
+ int i;
+ string *mat, mname, mgroup;
+ mat=m_indices(ob->QueryProp(P_MATERIAL));
+ i=sizeof(mat);
+
+ write("Der Schmied sagt: "+ob->Name(WER)+" besteht aus ...\n");
+ while(i--) {
+ // den Namen erkennen/aussprechen:
+ // Materialien werden allgemein etwas besser erkannt (zu 5%), aber
+ // alles aus Metall wird zu +100% besser erkannt ...
+ mname=MATERIALDB->MaterialName(mat[i], WER,
+ ({5, ([MATRGROUP_METAL, 100])}));
+
+ // und nur Metalle analysieren ...
+ if(MATERIALDB->MaterialGroup(([mat[i]:100]),MATGROUP_METAL)>=100) {
+ int j;
+ string *mgr;
+ mgr=MATERIALDB->GetMatMembership(mat[i]);
+ j=sizeof(mgr);
+ mgroup=" gehoert zu ";
+ while(j--) {
+ mgroup+=MATERIALDB->GroupName(mgr[j]);
+ if(j>0) mgroup+=", ";
+ }
+ } else mgroup=" kenne ich nicht";
+ printf("%-12.12s: %s\n",mname, mgroup);
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Konzepte: material, materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
+ GroupName(), MaterialName(),
+ GetGroupMembers()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/GetOffset.rst b/doc/sphinx/lfun/GetOffset.rst
new file mode 100644
index 0000000..2aa2b70
--- /dev/null
+++ b/doc/sphinx/lfun/GetOffset.rst
@@ -0,0 +1,49 @@
+GetOffset()
+===========
+
+FUNKTION
+--------
+::
+
+ varargs int GetOffset(string vname, mapping map, object pl)
+
+ARGUMENTE
+---------
+::
+
+ vname : name des parameters aus dem spellmapping
+ map : spellmapping
+ pl : caster
+
+BESCHREIBUNG
+------------
+::
+
+ 'Berechnet' den Offset des Parameters in spellmapping.
+
+RUECKGABEWERT
+-------------
+::
+
+ Berechneter Offset aus dem Spellmapping.
+
+BEMERKUNGEN
+-----------
+::
+
+ Beschraekung auf -10000 bis +10000. Werte groesser oder kleiner
+ als diese werden 'abgeschnitten'. Mehr als 100% Bonus oder Malus
+ gibts nicht ;-).
+
+BEISPIEL
+--------
+::
+
+ xxx=GetOffset(SI_SKILLDAMAGE,sinfo,caster);
+
+Siehe auch:
+
+ "GetValue", "GetFactor", "GetFValue", "GetValueO", "GetFValueO"
+
+ Ausfuehrliches Beispiel siehe "GetFValueO".
+
diff --git a/doc/sphinx/lfun/GetOwner.rst b/doc/sphinx/lfun/GetOwner.rst
new file mode 100644
index 0000000..2d8bd73
--- /dev/null
+++ b/doc/sphinx/lfun/GetOwner.rst
@@ -0,0 +1,38 @@
+GetOwner()
+==========
+
+GetOwner(L)
+-----------
+::
+
+FUNKTION
+--------
+::
+
+ string GetOwner();
+
+BESCHREIBUNG
+------------
+::
+
+ Wird vom Hoerrohr gerufen:
+ /d/inseln/shakedbeer/shakyisland/obj/hoerrohr.c
+ und kann einen Besitzer der Dateien zurueckgeben, der vom Besitzer
+ der Pfade in denen die Datei liegt abweicht.
+
+BEISPIELE
+---------
+::
+
+ string GetOwner() {
+ return "Tiamak";
+ }
+
+SIEHE AUCH
+----------
+::
+
+ P_INFO
+
+11. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/GetPhiolenInfos.rst b/doc/sphinx/lfun/GetPhiolenInfos.rst
new file mode 100644
index 0000000..488431d
--- /dev/null
+++ b/doc/sphinx/lfun/GetPhiolenInfos.rst
@@ -0,0 +1,124 @@
+GetPhiolenInfos()
+=================
+
+GetPhiolenInfos(L)
+------------------
+::
+
+FUNKTION
+--------
+::
+
+ mixed *GetPhiolenInfos();
+
+BESCHREIBUNG
+------------
+::
+
+ Wird von der Phiole aufgerufen:
+ /d/inseln/miril/sternquest/obj/phiole.c
+ Der Raum muss /p/service/miril/phiole.h includen.
+ Mit der Phiole kann ein Spieler durch Tueren schauen. Bei Tueren, die
+ vom Doormaster (/obj/doormaster.c) verwaltet werden, klappt dies auto-
+ matisch. Moechte man das verbieten, so muss die Funktion
+ GetPhiolenInfos() im entsprechenden Raum definiert sein.
+ Befinden sich Tueren im Raum, die nicht vom Doormaster verwaltet werden,
+ aber bei denen die Phiole funktionieren soll, so kann dies ebenfalls
+ mittels GetPhiolenInfos() geschehen.
+
+
+
+ Funktion der Phiole:
+ Sie projiziert ein Bild dessen, was hinter der Tuer liegt auf die Tuer.
+ Steht die Tuer offen, so sieht der Spieler nur eine Wand, denn es wird
+ gezeigt, was hinter dieser Tuer ist.
+
+
+
+ Ist die Tuer jedoch ge- oder verschlossen, so sieht er auf der Tuer
+ die Langbeschreibung des Raumes, der hinter der Tuer liegt, sowie das
+ Inventar dieses Raumes.
+
+ Aufbau der Funktion:
+ mixed *GetPhiolenInfos() {
+ return ({
+ ([
+ PHIOLE_DEST: string,
+ PHIOLE_IDS: *string,
+ PHIOLE_GENDER: int,
+ PHIOLE_STATUS: int, (optional)
+ PHIOLE_LONG: string, (optional)
+ PHIOLE_VERBOTEN: int (optional)
+ ]),
+ ([
+ ... Naechste Tuer
+ ])
+ });
+ }
+
+
+
+ PHIOLE_DEST Dateiname des Zielraums
+ PHIOLE_IDS Array der Strings, mit denen sich die Tuer
+ ansprechen laesst
+ PHIOLE_GENDER Geschlecht der Tuer
+ PHIOLE_STATUS aktueller Status der Tuer:
+ 0 geschlossen/verschlossen, 1 offen
+ Bei Tueren, die mit NewDoor erzeugt wurden
+ nicht setzen
+ PHIOLE_LONG Beschreibung des Zielraums (z.B. bei einer
+ Faketuer)
+ PHIOLE_VERBOTEN 0 erlaubt, 1 verboten
+
+BEISPIEL
+--------
+::
+
+ Ein Raum enthaelt eine Holztuer und ein Portal. Erstere ist mittels
+ NewDoor(...) gebaut, soll aber nicht zu durchschauen sein, letztere ist
+ selbstgestrickt. Die erste fuehrt in den Workroom von Jof, die zweite
+ ist nur ein Fake und immer geschlossen. Bei vom Doormaster erzeugten
+ Tueren sollte PHIOLE_STATUS nicht gesetzt werden, da dies automatisch
+ abgefragt wird.
+
+
+
+ #include "/p/service/miril/phiole.h"
+ ...
+ mixed *GetPhiolenInfos(){
+ return ({
+ ([
+ PHIOLE_DEST:"/players/jof/workroom",
+ PHIOLE_IDS:({"holztuer"}),
+ PHIOLE_GENDER:FEMALE,
+ PHIOLE_VERBOTEN:1
+ ]),
+ ([
+ PHIOLE_DEST:0,
+ PHIOLE_IDS:({"portal"}),
+ PHIOLE_GENDER:NEUTER,
+ PHIOLE_STATUS:0,
+ PHIOLE_LONG:"Du stehst in einer riesigen Schatzkammer und "
+ "kannst Dein Glueck kaum fassen. Nun brauchst "
+ "Du nur noch zuzugreifen und bist der reichste "
+ "Bewohner des MorgenGrauen.",
+ PHIOLE_VERBOTEN:0
+ ])
+ });
+ }
+ Mittels PHIOLE_LONG laesst sich auch bei erlaubten und verbotenen Tueren
+ einstellen, was der Spieler statt der normalen Raumbeschreibung und den
+ im Raum befindlichen Objekten sehen soll. Das koennte z.B. sinnvoll
+ sein, falls der Spieler zwar die Raumbeschreibung, aber nicht den fiesen
+ Drachen sehen soll, der sich ebenfalls im Raum befindet.
+
+
+
+SIEHE AUCH
+----------
+::
+
+ NewDoor(), QueryDoorStatus(), SetDoorStatus(), QueryAllDoors()
+
+Letzte Aenderung: Sam, 14. Jan 2006, 12:21, Miril
+
diff --git a/doc/sphinx/lfun/GetReputation.rst b/doc/sphinx/lfun/GetReputation.rst
new file mode 100644
index 0000000..0d3e3a9
--- /dev/null
+++ b/doc/sphinx/lfun/GetReputation.rst
@@ -0,0 +1,53 @@
+GetReputation()
+===============
+
+FUNKTION
+--------
+::
+
+ public int GetReputation(string repid)
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/reputation.c
+
+ARGUMENTE
+---------
+::
+
+ repid
+ Eindeutige ID der angefragten Reputation.
+
+BESCHREIBUNG
+------------
+::
+
+ Liefert den aktuellen Wert der angegebenen Reputation <repid> zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Zahlenwert, Integer.
+
+BEISPIELE
+---------
+::
+
+ s. reputation
+
+SIEHE AUCH
+----------
+::
+
+ reputation
+ ChangeReputation(), GetReputations()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+06.04.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/GetReputations.rst b/doc/sphinx/lfun/GetReputations.rst
new file mode 100644
index 0000000..f3bc764
--- /dev/null
+++ b/doc/sphinx/lfun/GetReputations.rst
@@ -0,0 +1,47 @@
+GetReputations()
+================
+
+FUNKTION
+--------
+::
+
+ public mapping GetReputations()
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/reputation.c
+
+BESCHREIBUNG
+------------
+::
+
+ Liefert ein Mapping aller im Spieler gespeicherten Reputationen und ihrer
+ Werte zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Mapping ([(string)repid: (int)wert])
+
+BEISPIELE
+---------
+::
+
+ s. repuation
+
+SIEHE AUCH
+----------
+::
+
+ reputation
+ GetReputation(), GetReputations()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+06.04.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/GetValue.rst b/doc/sphinx/lfun/GetValue.rst
new file mode 100644
index 0000000..8acb009
--- /dev/null
+++ b/doc/sphinx/lfun/GetValue.rst
@@ -0,0 +1,48 @@
+GetValue()
+==========
+
+FUNKTION
+--------
+::
+
+ varargs int GetValue(string vname, mapping map, object pl)
+
+ARGUMENTE
+---------
+::
+
+ vname : name des parameters aus dem spellmapping
+ map : spellmapping
+ pl : caster
+
+BESCHREIBUNG
+------------
+::
+
+ 'Berechnet' den Wert des uebergebenen Parameters aus dem
+ Spellmapping.
+
+RUECKGABEWERT
+-------------
+::
+
+ Berechneter Wert aus dem Spellmapping.
+
+BEMERKUNGEN
+-----------
+::
+
+
+
+BEISPIEL
+--------
+::
+
+ xxx=GetValue(SI_SKILLDAMAGE,sinfo,caster);
+
+Siehe auch:
+
+ "GetFactor", "GetOffset", "GetFValue", "GetValueO", "GetFValueO"
+
+ Ausfuehrliches Beispiel siehe "GetFValueO".
+
diff --git a/doc/sphinx/lfun/GetValueO.rst b/doc/sphinx/lfun/GetValueO.rst
new file mode 100644
index 0000000..3b75f8d
--- /dev/null
+++ b/doc/sphinx/lfun/GetValueO.rst
@@ -0,0 +1,47 @@
+GetValueO()
+===========
+
+FUNKTION
+--------
+::
+
+ varargs int GetValueO(string vname, mapping map, object pl)
+
+ARGUMENTE
+---------
+::
+
+ vname : name des parameters aus dem spellmapping
+ map : spellmapping
+ pl : caster
+
+BESCHREIBUNG
+------------
+::
+
+ Berechnet den Wert und den Offset des Parameters in spellmapping.
+
+RUECKGABEWERT
+-------------
+::
+
+ Berechneter Wert+Offset aus dem Spellmapping.
+
+BEMERKUNGEN
+-----------
+::
+
+ Ruft GetValue(vname,map,pl)+GetOffset(vname,map,pl) auf.
+
+BEISPIEL
+--------
+::
+
+ xxx=GetValueO(SI_SKILLDAMAGE,sinfo,caster);
+
+Siehe auch:
+
+ "GetValue", "GetFactor", "GetOffset", "GetFValue", "GetFValueO"
+
+ Ausfuehrliches Beispiel siehe "GetFValueO".
+
diff --git a/doc/sphinx/lfun/Gildenproperties.rst b/doc/sphinx/lfun/Gildenproperties.rst
new file mode 100644
index 0000000..5b658e0
--- /dev/null
+++ b/doc/sphinx/lfun/Gildenproperties.rst
@@ -0,0 +1,136 @@
+Gildenproperties()
+==================
+
+Name Beschreibung
+
+P_GUILD_SKILLS Property fuer Skills in der Gilde
+P_GUILD_RESTRICTIONS Restriktionen fuer den Eintritt in die Gilde
+P_GUILD_DEFAULT_SPELLBOOK
+P_GUILD_MALE_TITLES Maennliche Gildentitel
+P_GUILD_FEMALE_TITLES Weibliche Gildentitel
+P_GUILD_LEVELS Gildenstufen
+P_SB_SPELLS Property fuer Spells in Spellbook
+P_GLOBAL_SKILLPROPS Properties der Gilde UND des Spellbooks
+
+Properties des Spielers
+P_GUILD String mit dem Namen der Gilde
+P_GUILD_LEVEL Gildenstufe
+P_GUILD_TITLE Gildentitel
+P_GUILD_RATING Rating in der Gilde
+P_NEWSKILLS mapping mit Skills und Spells
+P_NEXT_SPELL_TIME Zeit bis der naechste Spell gesprochen werden kann
+P_TMP_ATTACK_HOOK Angriffs-Ersatzfunktion
+P_TMP_ATTACK_MOD Angriffs-Modifizierung
+P_TMP_DEFEND_HOOK Abwehr-Ersatzfunktion
+P_TMP_DIE_HOOK "Die"-Ersatzfunktion
+P_TMP_MOVE_HOOK Bewegungs-Ersatzfunktion
+P_DEFENDERS Verteidiger
+P_PREPARED_SPELL Vorbereiteter Spell
+P_DEFAULT_GUILD Standardgilde
+P_MAGIC_RESISTANCE_OFFSET Offset fuer Magie-Resistenzen
+
+Standard-Skills
+SK_FIGHT Kampfskill(global)
+SK_SWORDFIGHTING Schwertkampf
+SK_WEAPONLESS Waffenloser Kampf
+SK_TWOHANDED Zweihandkampf
+SK_CASTING Zauber-Skill
+SK_MAGIC_ATTACK Magischer Angriff
+SK_MAGIC_DEFENSE Magische Abwehr
+SK_NIGHTVISION Nachtsicht
+SK_BOOZE Sauf-Skill
+SK_INFORM_DEFEND
+SK_DEFEND_OTHER
+SK_CARRY Trage-Skill
+SK_SPELL_DEFEND Spruch-Abwehr
+
+Skill-Attribute
+P_SKILL_ATTRIBUTES Property fuer Skill-Attribute
+P_SKILL_ATTRIBUTE_OFFSETS Property fuer Offsets der Skill-Attribute
+SA_QUALITY Allgemeine Qualitaet
+SA_DAMAGE Schaden
+SA_SPEED Geschwindigkeit
+SA_DURATION Dauer
+SA_EXTENSION Ausdehnung
+SA_RANGE Reichweit
+SA_ENEMY_SAVE identisch zu SA_SPELL_PENETRATION (OBSOLET!)
+SA_SPELL_PENETRATION Chance des _Casters_, einen Spell durch ein
+ P_NOMAGIC durchzukriegen.
+
+Skill-Info
+FACTOR(x) Faktor
+OFFSET(x) Offset
+SI_SKILLFUNC Funktion, die aufgerufen wird
+SI_CLOSURE Intern (Geschwindigkeitsoptimierung)
+SI_SPELLBOOK Spellbook, in dem der Spell steht
+SI_SPELLCOST Kosten des Spells
+SI_TIME_MSG Die Meldung wird anstelle von "Du bist noch zu
+ erschoepft von Deinem letzten Spruch." ausgegeben.
+SI_SP_LOW_MSG Die Meldung wird anstelle von "Du hast zu wenig
+ Zauberpunkte fuer diesen Spruch." ausgegeben.
+SI_NOMAGIC Prozentwert, mit dem P_NOMAGIC mgangen werden kann
+SI_SPELLFATIGUE Erschoepfung - Zeit, in der keine weiteren Spells
+ aufgerufen werden koennen
+SI_SKILLLEARN Lerngeschwindigkeit in 0.01% pro A_INT/2
+SI_SKILLABILITY Faehigkeit, diesen Spruch zu benutzen
+SI_SKILLARG Argumente, die uebergeben wurden
+SI_SKILLRESTR_USE Beschraenkungen beim Gebrauch
+SI_SKILLRESTR_LEARN Beschraenkungen beim Lernen
+SI_SKILLINFO Kurzer Informationstext
+SI_SKILLINFO_LONG Langer Informationstext
+SI_SKILLDAMAGE Schaden
+SI_SKILLDAMAGE_TYPE Art des Schadens
+SI_SKILLDAMAGE_MSG Meldung die anstelle einer Waffe kommen soll
+SI_SKILLDAMAGE_MSG2 dito fuer den Text fuer andere im Raum
+SI_SPELL Spell, mit dem angegriffen wurde
+SI_INHERIT Skill, von dem etwas uebernommen werden soll
+SI_DIFFICULTY Wert, der die Obergrenze der Faehigkeit abgrenzt
+SI_LASTLIGHT Fuer Nachtsicht Wann hat der Spieler zum letzten
+ mal Licht gesehen.
+SI_SKILLHEAL Heilung
+SI_USR selbst definierte Infos
+SI_GUILD Gilde, falls Auswahl aus mehreren moeglich
+SI_ENEMY Feind bei Kampfspruechen
+SI_FRIEND Der zu verteidigende Freund bei DefendOther
+ und InformDefend
+SI_MAGIC_TYPE Von was fuer einer Art ist die Magie (s.u.)
+SI_PREPARE_TIME Zeit die zur Vorbereitung benoetigt wird.
+SI_ATTACK_BUSY_MSG Meldung, wenn der Spieler zu beschaeftigt ist
+SI_NO_ATTACK_BUSY Wenn der Spell nicht als Taetigkeit zaehlen/gezaehlt
+ werden soll, kann man hier
+ NO_ATTACK_BUSY[_SET|_QUERY] setzen
+SP_NAME Name des Spells, falls Mapping
+SP_SHOW_DAMAGE Treffermeldung soll gezeigt werden.
+SP_REDUCE_ARMOUR AC soll Typabhaengig reduziert werden.
+SP_PHYSICAL_ATTACK Koerperlicher Angriff
+SP_RECURSIVE Rekursionen
+
+Skill-Restrictions
+SR_FUN Funktion, die weitere Einschraenkungen prueft
+SR_EXCLUDE_RACE Ausgeschlossene Rassen
+SR_INCLUDE_RACE Eingeschlossene Rassen
+SR_GOOD Align <
+SR_BAD Align >
+SR_FREE_HANDS Benoetigte freie Haende
+SR_SEER Muss Seher sein
+SR_MIN_SIZE Mindestgroesse
+SR_MAX_SIZE Maximalgroesse
+SM_RACE Rassenspezifische Besonderheiten
+
+Magie-Arten
+MT_ANGRIFF Angriff
+MT_SCHUTZ Schutz
+MT_ILLUSION Illusion
+MT_BEHERRSCHUNG Beherrschung
+MT_HELLSICHT Hellsicht
+MT_VERWANDLUNG Verwandlung
+MT_BESCHWOERUNG Beschwoerung
+MT_BEWEGUNG Bewegung
+MT_SAKRAL 'Goettliches'
+MT_HEILUNG Heilung
+MT_CREATION Erschaffung
+MT_PSYCHO Psycho-Kram
+MT_MISC Sonstiges
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+::
+
diff --git a/doc/sphinx/lfun/GiveMiniQuest.rst b/doc/sphinx/lfun/GiveMiniQuest.rst
new file mode 100644
index 0000000..65f920a
--- /dev/null
+++ b/doc/sphinx/lfun/GiveMiniQuest.rst
@@ -0,0 +1,71 @@
+GiveMiniQuest()
+===============
+
+FUNKTION
+--------
+::
+
+ int GiveMiniQuest(object winner)
+
+DEFINIERT IN
+------------
+::
+
+ /secure/questmaster
+
+ARGUMENTE
+---------
+::
+
+ winner
+ Spielerobjekt, das die Quest bestanden hat.
+
+RUeCKGABEWERT
+-------------
+::
+
+ (Die Defines fuer den Rueckgabewert finden sich in
+ /secure/questmaster.h)
+ 1 : Hat geklappt (OK)
+ -1 : Spieler hat die Quest bereits geloest (MQ_ALREADY_SET)
+ -2 : Ungueltiger Questname (MQ_KEY_INVALID)
+ -3 : Unbefugter Zugriff (MQ_ILLEGAL_OBJ)
+ -4 : Quest zur Zeit inaktiv (MQ_IS_INACTIVE)
+ -5 : Gaeste loesen keine Quests (MQ_GUEST)
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion wird nach dem erfolgreichen Loesen einer
+ MiniQuest die Quest im Spieler eingetragen. Dabei muss der
+ Aufruf in dem Objekt erfolgen, welches im Questmaster
+ eingetragen ist. Als Argument muss das Spielerobjekt
+ angegeben werden, welches die Quest bestanden hat.
+
+
+
+BEISPIEL
+--------
+::
+
+ QM->GiveMiniQuest(this_player());
+
+SIEHE AUCH
+----------
+::
+
+ HasMiniQuest
+ /secure/questmaster.h, /secure/questmaster.c
+
+HINWEIS
+-------
+::
+
+ Die Informationen fuer den EM fuer Quests sollten diesem
+ beim Eintragen der Miniquest in den Questmaster per Mail
+ zugeschickt werden. Siehe dazu die Hilfe zu AddMiniQuest.
+
+
+Zuletzt geaendert: Don, 30. Jan 2014, 22:14:12 von Ark.
+
diff --git a/doc/sphinx/lfun/GiveQuest.rst b/doc/sphinx/lfun/GiveQuest.rst
new file mode 100644
index 0000000..b6986dd
--- /dev/null
+++ b/doc/sphinx/lfun/GiveQuest.rst
@@ -0,0 +1,87 @@
+GiveQuest()
+===========
+
+FUNKTION
+--------
+::
+
+ varargs int GiveQuest(string questname, string message)
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/quests.c
+
+ARGUMENTE
+---------
+::
+
+ questname
+ Questname, wie er im Questmaster eingetragen wurde.
+ message
+ Optionale Meldung, die auf dem Abenteuer-Kanal statt der
+ Standardmeldung gesendet wird.
+ Dabei wird @@name@@ durch den Spielernamen ersetzt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ (Die Defines fuer den Rueckgabewert finden sich in
+ /secure/questmaster.h)
+ 1 : Hat geklappt (OK)
+ -1 : Spieler hat die Quest bereits geloest (GQ_ALREADY_SET)
+ -2 : Ungueltiger Questname (GQ_KEY_INVALID)
+ -3 : Unbefugter Zugriff (GQ_ILLEGAL_OBJ)
+ -4 : Quest zur Zeit inaktiv (GQ_IS_INACTIVE)
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion wird nach dem erfolgreichen Loesen einer
+ Quest die Quest im Spieler eingetragen. Dabei muss der Aufruf
+ in dem Objekt erfolgen, welches im Questmaster eingetragen ist.
+ Zusaetzlich wird der Zeitpunkt eingetragen, an dem die Quest
+ bestanden wurde.
+
+
+
+ Wer sich da nicht sicher ist, kann mit dem Questtool
+ (/obj/tools/questtool) nachsehen.
+
+ Nachdem eine Quest als geloest markiert wurde, ist dies in einem
+ Logfile fuer die Quest im Verzeichnis /log/quest einzutragen. Dazu
+ wird write_file verwendet.
+
+BEISPIEL
+--------
+::
+
+ int quest;
+
+ quest = this_player()->GiveQuest("Zacharias Eispalast");
+
+ if (quest == 1)
+ {
+ write("Du fuehlst, wie Deine Erfahrung ansteigt.\n");
+ write_file("/log/quest/eispalast",
+ dtime(time())+" Aufgabe geloest von "
+ +this_player()->name()+"\n");
+ }
+ else if (quest != -1)
+ write( "Die Weltenmaschine will Dir Deine Arbeit "
+ +"nicht anerkennen.\n"
+ +"Frage einen Erzmagier um Hilfe.\n" );
+
+SIEHE AUCH
+----------
+::
+
+ /secure/questmaster.h, /obj/tools/questtool
+ QueryQuest(), write_file(), ModifyQuestTime()
+
+
+Zuletzt geaendert: Son, 27. Apr 2014, Arathorn
+
diff --git a/doc/sphinx/lfun/GroupName.rst b/doc/sphinx/lfun/GroupName.rst
new file mode 100644
index 0000000..f50d900
--- /dev/null
+++ b/doc/sphinx/lfun/GroupName.rst
@@ -0,0 +1,87 @@
+GroupName()
+===========
+
+FUNKTION
+--------
+::
+
+ string GroupName(string grp)
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/materialdb.c (MATERIALDB)
+
+ARGUMENTE
+---------
+::
+
+ string grp - ein Gruppenname
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt die Langbeschreibung des Gruppennamens zurueck.
+
+RUECKGABEWERT
+-------------
+::
+
+ Die Gruppenbeschreibung oder "Unbekanntes"
+
+BEISPIELE
+---------
+::
+
+ // simpel
+ tmp=m_indices(ob->QueryProp(P_MATERIAL));
+ write("Dieses Objekt gehoert u.a. zur Gruppe "+
+ MATERIALDB->GroupName(MATERIALDB->GetMatMembership(tmp[0])[0])+
+ ".\n");
+ // gibt die erste Gruppenzugehoerigkeit des erste Materials in
+ // P_MATERIAL zurueck (bei MATGROUP_METAL z.B. "... zur Gruppe Metalle.")
+
+ // ein weiser Schmied:
+ int i;
+ string *mat, mname, mgroup;
+ mat=m_indices(ob->QueryProp(P_MATERIAL));
+ i=sizeof(mat);
+
+ write("Der Schmied sagt: "+ob->Name(WER)+" besteht aus ...\n");
+ while(i--) {
+ // den Namen erkennen/aussprechen:
+ // Materialien werden allgemein ganz schlecht erkannt (zu 5%), aber
+ // alles aus Metall wird zu +100% gut erkannt ...
+ mname=MATERIALDB->MaterialName(mat[i], WER,
+ ({5, ([MATERIAL_SYMMETRIC_RECOGNIZABILITY:
+ ({MATGROUP_METAL, 100})])}));
+
+ // und nur Metalle analysieren ...
+ if(MATERIALDB->MaterialGroup(([mat[i]:100]),MATGROUP_METAL)>=100) {
+ int j;
+ string *mgr;
+ mgr=MATERIALDB->GetMatMembership(mat[i]);
+ j=sizeof(mgr);
+ mgroup=" gehoert zu ";
+ while(j--) {
+ mgroup+=MATERIALDB->GroupName(mgr[j]);
+ if(j>0) mgroup+=", ";
+ }
+ } else mgroup=" kenne ich nicht";
+ printf("%-12.12s: %s\n",mname, mgroup);
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Konzepte: material, materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
+ MaterialName(),
+ GetGroupMembers(), GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/GuardExit.rst b/doc/sphinx/lfun/GuardExit.rst
new file mode 100644
index 0000000..aa5a1df
--- /dev/null
+++ b/doc/sphinx/lfun/GuardExit.rst
@@ -0,0 +1,112 @@
+GuardExit()
+===========
+
+FUNKTION
+--------
+::
+
+ protected <int|<string|closure>* >* GuardExit(object room, int hookid,
+ <string|closure>* hdata);
+
+DEFINIERT IN
+------------
+::
+
+ /std/npc/moving.c
+
+ARGUMENTE
+---------
+::
+
+ room
+ Der den Hook ausloesende Raum (environment())
+ hookid
+ Die ID des Hooks (H_HOOK_EXIT_USE)
+ hdata
+ Ein Array mit 3 Elementen:
+ ({
+ verb - Das Kommandoverb/Ausgangsname (string)
+ dest - Zielraum (string) oder closure (special exits)
+ msg - Bewegungsrichtung (string) oder 0
+ })
+
+BESCHREIBUNG
+------------
+::
+
+ Ist diese Funktion in einem NPC definiert, traegt sich der NPC bei jeder
+ Bewegung automatisch als Konsument von H_HOOK_EXIT_USE ein und diese
+ Funktion wird immer gerufen, wenn ein Lebewesen im gleichen Environment
+ wie der NPC versucht, einen Ausgang zu benutzen.
+ Der NPC kann dann die Bewegung abbrechen (und so den Ausgang
+ blockieren), Ziel oder Bewegungsmeldung aendern oder keine Veraenderung
+ vornehmen.
+ Die Konstanten fuer Hookid und Hookstatus (s. Rueckgabewert) sind in
+ <hook.h> definiert.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Array mit zwei Elementen:
+ ({
+ H_NO_MOD / H_ALTERED / H_CANCELLED,
+ hdata
+ })
+ hdata ist ggf. das geaenderte Array, welches die Funktion uebergeben
+ wird. Weitere Details s. auch /doc/std/hooks
+
+BEMERKUNGEN
+-----------
+::
+
+ Die Anzahl an Konsumenten eines Hooks ist begrenzt. Es ist daher
+ moeglich, dass die Registrierung nicht klappt, wenn zuviele (>5) Waechter
+ im Raum sind. Will man darauf reagieren, muesste man die Registrierung
+ pruefen.
+ Ein NPC, welcher GuardExit() definiert, aber im aktuellen Environment
+ keine Wache halten will, koennte sich selber de-registrieren.
+
+BEISPIELE
+---------
+::
+
+ <int|<string|closure>* >* GuardExit(object room, int hookid,
+ <string|closure>* hdata)
+ {
+ // Nur in Gefaengnisraeumen Wache halten
+ if (strstr(object_name(environment()), "/room/jail")==0)
+ {
+ // Hier gehts nicht raus. ;-)
+ if (hdata[0] == "raus") {
+ tell_object(this_player(), ...);
+ return ({H_CANCELLED, hdata});
+ }
+ // Special exits ersetzen wir durch einen eigenen
+ else if (closurep(hdata[1])) {
+ hdata[1] = #'my_special_exit;
+ return ({H_ALTERED, hdata});
+ }
+ // alle anderen Ausgaenge in die persoenliche Zelle
+ else {
+ tell_object(this_player(), ...);
+ hdata[1] = "/room/jail_"+getuid(this_player());
+ hdata[2] = "Sueden";
+ return ({H_ALTERED, hdata});
+ }
+ }
+ // in allen anderen Raeumen nicht eingreifen
+ return ({H_NO_MOD, hdata});
+ }
+
+SIEHE AUCH
+----------
+::
+
+ AddExit, AddSpecialExit, RemoveExit
+ HRegisterToHook, HRegisterModifier, HUnregisterFromHook
+ /doc/std/hooks
+
+20.02.2016, Zesstra
+22.05.2016, Mupfel (Beispiel korrigiert)
+
diff --git a/doc/sphinx/lfun/Halt.rst b/doc/sphinx/lfun/Halt.rst
new file mode 100644
index 0000000..d54a534
--- /dev/null
+++ b/doc/sphinx/lfun/Halt.rst
@@ -0,0 +1,53 @@
+Halt()
+======
+
+FUNKTION
+--------
+::
+
+ void Halt();
+
+DEFINIERT IN
+------------
+::
+
+ /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Die Fahrt des Transporters wird abgebrochen. Sie muss explizit mit
+ Start() wieder aufgenommen werden!
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Es gibt keine einfache Moeglichkeit, die Fahrt eines Transporters an
+ der Stelle wieder aufzunehmen, an der sie unterbrochen wurde. Man
+ muesste die aktuelle Position mit QueryPosition() ermitteln, mit Hilfe
+ der AddXXX()-Aufrufe in eine Positionsnummer umwandlen und diese an
+ Start() uebergeben.
+
+SIEHE AUCH
+----------
+::
+
+ Start(), /std/transport.c
+
+
+Last modified: Wed May 8 10:19:23 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/HasMiniQuest.rst b/doc/sphinx/lfun/HasMiniQuest.rst
new file mode 100644
index 0000000..6885348
--- /dev/null
+++ b/doc/sphinx/lfun/HasMiniQuest.rst
@@ -0,0 +1,62 @@
+HasMiniQuest()
+==============
+
+FUNKTION
+--------
+::
+
+ int HasMiniQuest(mixed pl, mixed name)
+
+DEFINIERT IN
+------------
+::
+
+ /secure/questmaster
+
+ARGUMENTE
+---------
+::
+
+ pl
+ Name des Spielers oder das Spielerobjekt
+ name
+ Filename des Objekts oder das Objekt selbst, welches die Miniquest
+ im Spieler eintragen darf, oder die Nummer (int) der Miniquest
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 : Der Spieler hat die MiniQuest
+ 0 : Der Spieler hat die MiniQuest noch nicht
+ -2 : angegebene Miniquest existiert nicht
+ -3 : falsche Datentypen fuer pl oder name uebergeben
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion kann getestet werden, ob ein Spieler eine
+ MiniQuest bereits geloest hat. Dabei ist entweder der Filename des
+ Objektes anzugeben, das die Quest im Spieler eintragen darf oder
+ das Objekt selbst.
+
+
+
+BEISPIEL
+--------
+::
+
+ if( QM->HasMiniQuest(getuid(this_player()), this_object())!=1 )
+ write("Du bist noch nicht reif genug.\n");
+
+SIEHE AUCH
+----------
+::
+
+ GiveMiniQuest(L)
+ /secure/questmaster.h, /secure/questmaster.c
+
+
+Zuletzt geaendert: 2014-Feb-03, Arathorn.
+
diff --git a/doc/sphinx/lfun/HitFunc.rst b/doc/sphinx/lfun/HitFunc.rst
new file mode 100644
index 0000000..cf90ff0
--- /dev/null
+++ b/doc/sphinx/lfun/HitFunc.rst
@@ -0,0 +1,94 @@
+HitFunc()
+=========
+
+FUNKTION
+--------
+::
+
+ int HitFunc(object enemy);
+
+DEFINIERT IN
+------------
+::
+
+ eigenen Objekten, fuer /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+ enemy
+ Der Gegner, gegen den die Waffe eingesetzt wird.
+
+BESCHREIBUNG
+------------
+::
+
+ Die Waffe kann anhand des Gegners enemy entscheiden, ob ein
+ Schadensbonus oder auch ein Schadensmalus wirksam wird. Dieser Bonus
+ wird zu dem normalen Schaden der Waffe hinzuaddiert.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der Schadensbonus bzw. der Abschlag.
+
+BEMERKUNGEN
+-----------
+::
+
+ Wenn durch den Bonus die Genehmigungsgrenzen der Balance
+ ueberschritten werden koennen, muss man seinen Regionsmagier und
+ die Objekt-Balance konsultieren!
+
+ Werte der HitFunc sollten immer ueber ein random() zurueckgegeben
+ werden!
+
+ Diese Funktion sollte die Waffe nicht zerstoeren! Falls ihr im Kampf eine
+ Waffe (ggf. in Abhaengigkeit vom Gegner) zerstoeren wollt, nutzt dazu
+ bitte TakeFlaw().
+
+BEISPIELE
+---------
+::
+
+ Eine Waffe, die gegen Orks besonders gut wirkt:
+
+ inherit "std/weapon";
+
+ #include <properties.h>
+ #include <combat.h>
+ #include <class.h>
+
+ create(){
+ if(!clonep(this_object())) {
+ set_next_reset(-1);
+ return;
+ }
+ ::create();
+ /*
+ zig SetProp's, um die Waffe zu konfigurieren
+ HitFunc() ist in der Waffe selbst definiert
+ */
+ SetProp(P_HIT_FUNC, this_object());
+ }
+
+ int HitFunc(object enemy)
+ {
+ /* laesst sich der Gegner als Ork ansprechen? */
+ if (enemy->is_class_member(CL_ORC))
+ return random(10+random(50)); /* Ja => Schaden erhoehen */
+
+ return 0; /* ansonsten keinen zusaetzlichen Schaden anrichten */
+ }
+
+SIEHE AUCH
+----------
+::
+
+ QueryDefend(), /std/weapon.c
+ TakeFlaw()
+
+11.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/Identify.rst b/doc/sphinx/lfun/Identify.rst
new file mode 100644
index 0000000..1a886dd
--- /dev/null
+++ b/doc/sphinx/lfun/Identify.rst
@@ -0,0 +1,44 @@
+Identify()
+==========
+
+FUNKTION
+--------
+::
+
+ void Identify(object ob);
+
+DEFINIERT IN
+------------
+::
+
+ /std/corpse.c
+
+ARGUMENTE
+---------
+::
+
+ ob
+ Das kuerzlich nach langem, hartem Kampf verstorbene Objekt.
+
+BESCHREIBUNG
+------------
+::
+
+ In dieser Funktion werden Lang- und Kurzbeschreibung der Leiche gesetzt
+ sowie die Verwesung in Gang gesetzt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ /std/corpse.c
+
+
+Last modified: Wed May 8 10:19:57 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/InFight.rst b/doc/sphinx/lfun/InFight.rst
new file mode 100644
index 0000000..e8020fa
--- /dev/null
+++ b/doc/sphinx/lfun/InFight.rst
@@ -0,0 +1,52 @@
+InFight()
+=========
+
+FUNKTION
+--------
+::
+
+ mixed InFight()
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wurde dazu geschrieben, um herauszufinden,
+ ob sich ein PC/NPC direkt im Kampf befindet. Dazu wird
+ das Array mit den Namen der Feinden des PC/NPCs durch die
+ Funktion environment gefiltert und so festgestellt, ob
+ die Umgebung der beiden Feinde gleich ist.
+
+RUECKGABEWERT:
+ Als Rueckgabewert enthaelt man entweder 0, wenn das Objekt
+ im Moment keine Feinde hat bzw. die nicht im selben Raum
+ sind, oder aber das Feindobjekt, das als erstes im Array
+ steht und anwesend ist.
+
+BEISPIEL
+--------
+::
+
+ Selbsterklaerend ;)
+
+BEMERKUNG
+---------
+::
+
+ InFight() gibt lediglich das Ergebnis von EnemyPresent() zurueck.
+
+SIEHE AUCH
+----------
+::
+
+ EnemyPresent(), PresentEnemies()
+ /std/living/combat.c
+
+22.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/InList.rst b/doc/sphinx/lfun/InList.rst
new file mode 100644
index 0000000..d6a3a3c
--- /dev/null
+++ b/doc/sphinx/lfun/InList.rst
@@ -0,0 +1,48 @@
+InList()
+========
+
+FUNKTION
+--------
+::
+
+ int InList(object room, int *potionlist, int *knownlist)
+
+DEFINIERT IN
+------------
+::
+
+ /secure/potionmaster.c
+
+ARGUMENTE
+---------
+::
+
+ Implizit: previous_object() - Spielerobjekt, das ZT bekommen soll
+ object room - Objekt, welches ZT vergeben will
+ int* potionlist - Liste der ZTs des Spielers
+ int* knownlist - Liste der bekannten ZTs des Spielers
+
+BESCHREIBUNG
+------------
+::
+
+ Prueft, ob 'room' einen ZT vergeben darf und gibt zurueck, ob die
+ Nummer dieses ZTs in der 'knownlist' enthalten ist.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0 Kein aktiver ZT oder nicht in Liste enthalten.
+ 1 Aktiver ZT und in Liste.
+
+SIEHE AUCH
+----------
+::
+
+ Sonstiges: zaubertraenke, /room/orakel.c
+ Verwandt: FindPotion(), RemoveKnownPotion(), AddKnownPotion()
+ Props: P_POTIONROOMS, P_KNOWN_POTIONROOMS
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/lfun/InformAlcoholEffect.rst b/doc/sphinx/lfun/InformAlcoholEffect.rst
new file mode 100644
index 0000000..dbeedc0
--- /dev/null
+++ b/doc/sphinx/lfun/InformAlcoholEffect.rst
@@ -0,0 +1,68 @@
+InformAlcoholEffect()
+=====================
+
+FUNKTION
+--------
+::
+
+ void InformAlcoholEffect(object pl, int msgid, int area)
+
+DEFINIERT IN
+------------
+::
+
+ eigenen Objekten; fuer /std/living/life.c
+
+
+
+ARGUMENTE
+---------
+::
+
+ pl
+ Das Lebewesen, das alkoholisiert ist.
+ msgid
+ Flag fuer die Meldung, die ausgegeben wird.
+ area
+ Aufruf erfolgt in Gilde (0) oder im Environment (1).
+
+BESCHREIBUNG
+------------
+::
+
+ Wenn ein Lebewesen alkoholisiert ist, werden in unregelmaessigen
+ Abstaenden Meldungen an die Umgebung und ans Lebewesen ausgegeben.
+ Gleichzeitig wird die Funktion InformAlcoholEffect in der Gilde
+ und im Environment des Lebewesens aufgerufen.
+
+
+
+ Es gibt vier verschiedene Meldungen (definiert in /sys/health.h):
+ ALC_EFFECT_HICK (0) : "<Hick>! Oh, Tschuldigung.\n"
+ ALC_EFFECT_RUELPS (1) : "Du ruelpst.\n"
+ ALC_EFFECT_LOOKDRUNK (2) : "Du fuehlst Dich benommen.\n"
+ ALC_EFFECT_STUMBLE (3) : "Du stolperst.\n"
+
+
+
+ Wird die Funktion in einem Gildenraum implementiert, so kann man
+ anhand des 3. Parameters unterscheiden, ob die Gilde als Gilde
+ oder als Raum gemeint ist (die Funktion wird je einmal aufgerufen):
+ ALC_EFFECT_AREA_GUILD (0) : der Aufruf betrifft die Gilde,
+ ALC_EFFECT_AREA_ENV (1) : der Aufruf betrifft die Umgebung.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ P_ALCOHOL, /sys/health.h
+
+
+Last modified: Thu May 23 23:08:00 2002 by Mupfel
+
diff --git a/doc/sphinx/lfun/InformDefend.rst b/doc/sphinx/lfun/InformDefend.rst
new file mode 100644
index 0000000..fbc0b12
--- /dev/null
+++ b/doc/sphinx/lfun/InformDefend.rst
@@ -0,0 +1,82 @@
+InformDefend()
+==============
+
+FUNKTION
+--------
+::
+
+ void InformDefend(object enemy);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ enemy
+ Der Feind, der ein zu verteidigendes Lebewesen angegriffen hat.
+
+BESCHREIBUNG
+------------
+::
+
+ Es ist moeglich, dass Objekte ueber Angriffe auf Lebewesen
+ informiert werden, sofern diese Objekte bei dem angegriffenen
+ Lebewesen mittels AddDefender() angemeldet wurden und sich der
+ selben Umgebung befinden.
+ Zumeist wird es sich bei den Objekten natuerlich ebenfalls um
+ andere Lebewesen handeln, die das Lebewesen, bei dem sie angemeldet
+ sind, verteidigen sollen.
+ Bei einem Angriff auf das Lebewesen werden alle Objekte per Aufruf
+ von InformDefend() darueber informiert, wobei der Angreifer als
+ Parameter uebergeben wird.
+ Standardmaessig ist diese Funktion in Lebewesen bereits definiert,
+ wobei der Skill SK_INFORM_DEFEND, sofern vorhanden, aufgerufen wird.
+
+BEISPIEL
+--------
+::
+
+ Sehr beliebt sind in Gilden NPCs, die den Beschwoerer begleiten und
+ verteidigen, z.B. beschworene Daemonen:
+ inherit "std/npc";
+ include <properties.h>
+ object owner;
+ void create()
+ { ::create();
+ SetProp(P_NAME,"Daemon");
+ ...
+ }
+ // nach Clonen des Daemons folgende Funktion mit Beschwoerer als
+ // Parameter aufrufen
+ Identify(object caster)
+ { if(!objectp(caster))
+ call_out(#'remove,0);
+ owner=caster;
+ owner->AddDefender(this_object());
+ }
+ // folgende Funktion wird automatisch aufgerufen, wenn der
+ // Beschwoerer angegriffen wird
+ void InformDefend(object enemy)
+ { if(!IsEnemy(enemy)&&enemy!=owner)
+ Kill(enemy);
+ }
+ Soll der Daemon sich auch in ein Team einordnen, in welchem sich der
+ Beschwoerer eventuell befindet, so ist zusaetzlich AssocMember() in
+ diesem Beschwoerer aufzurufen, wobei der Daemon als Parameter
+ uebergeben wird.
+
+SIEHE AUCH
+----------
+::
+
+ AddDefender(), RemoveDefender(), DefendOther(), Kill(), IsEnemy(),
+ P_DEFENDERS, /std/living/combat.c, /sys/new_skills.h
+
+
+Last modified: Thu Jul 29 18:48:45 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/InformRowChange.rst b/doc/sphinx/lfun/InformRowChange.rst
new file mode 100644
index 0000000..a642c58
--- /dev/null
+++ b/doc/sphinx/lfun/InformRowChange.rst
@@ -0,0 +1,45 @@
+InformRowChange()
+=================
+
+FUNKTION
+--------
+::
+
+ varargs void InformRowChange(int from, int to, object caster);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ from - Reihe, in die der Spieler vorher war.
+ to - Reihe in der der Spieler jetzt ist.
+ caster - Der Spieler, falls die Funktion in der Gilde aufgerufen wird.
+
+
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird im Spieler und in seiner Gilde aufgerufen,
+ falls sich die aktuelle Kampfreihe in der Teamaufstellung
+ aendert.
+
+RUECKGABEWERT
+-------------
+::
+
+ Keiner.
+
+SIEHE AUCH
+----------
+::
+
+ teams
+
diff --git a/doc/sphinx/lfun/InformUnwear.rst b/doc/sphinx/lfun/InformUnwear.rst
new file mode 100644
index 0000000..350014a
--- /dev/null
+++ b/doc/sphinx/lfun/InformUnwear.rst
@@ -0,0 +1,49 @@
+InformUnwear()
+==============
+
+FUNKTION
+--------
+::
+
+ protected void InformUnwear(object pl, int silent, int all)
+
+DEFINIERT IN
+------------
+::
+
+ /std/clothing/wear.c
+
+ARGUMENTE
+---------
+::
+
+ pl
+ Das Lebewesen, das die Ruestung ausgezogen hat.
+ silent
+ Flag, ob Meldungen unterdruckt werden sollen.
+ all
+ Flag, ob die Ruestung mit "ziehe alles aus"/
+ "ziehe alle ruestungen aus" ausgezogen wurde.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird aufgerufen, wenn die Ruestung erfolgreich
+ ausgezogen wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ InformUnwield(), InformWield(), InformWear()
+
+
+06.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/InformUnwield.rst b/doc/sphinx/lfun/InformUnwield.rst
new file mode 100644
index 0000000..0640e4f
--- /dev/null
+++ b/doc/sphinx/lfun/InformUnwield.rst
@@ -0,0 +1,46 @@
+InformUnwield()
+===============
+
+FUNKTION
+--------
+::
+
+ protected void InformUnwield(object pl, int silent)
+
+DEFINIERT IN
+------------
+::
+
+ /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+ pl
+ Das Lebewesen, das die Waffe gezueckt hatte.
+ silent
+ Flag, ob Meldungen unterdruckt werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird aufgerufen, wenn die Waffe erfolgreich
+ weggesteckt wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ InformWield(), InformWear(), InformUnwear()
+
+
+06.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/InformWear.rst b/doc/sphinx/lfun/InformWear.rst
new file mode 100644
index 0000000..dcef6bc
--- /dev/null
+++ b/doc/sphinx/lfun/InformWear.rst
@@ -0,0 +1,49 @@
+InformWear()
+============
+
+FUNKTION
+--------
+::
+
+ protected void InformWear(object pl, int silent, int all)
+
+DEFINIERT IN
+------------
+::
+
+ /std/clothing/wear.c
+
+ARGUMENTE
+---------
+::
+
+ pl
+ Das Lebewesen, das die Ruestung angezogen hat.
+ silent
+ Flag, ob Meldungen unterdruckt werden sollen.
+ all
+ Flag, ob die Ruestung mit "trage alles"/"trage alle ruestungen"
+ angezogen wurde.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird aufgerufen, wenn die Ruestung erfolgreich
+ angezogen wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ InformUnwield(), InformWield(), InformUnwear()
+
+
+06.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/InformWield.rst b/doc/sphinx/lfun/InformWield.rst
new file mode 100644
index 0000000..f9a5c21
--- /dev/null
+++ b/doc/sphinx/lfun/InformWield.rst
@@ -0,0 +1,46 @@
+InformWield()
+=============
+
+FUNKTION
+--------
+::
+
+ protected void InformWield(object pl, int silent)
+
+DEFINIERT IN
+------------
+::
+
+ /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+ pl
+ Das Lebewesen, das die Waffe gezueckt hat.
+ silent
+ Flag, ob Meldungen unterdruckt werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird aufgerufen, wenn die Waffe erfolgreich
+ gezueckt wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ InformUnwield(), InformWear(), InformUnwear()
+
+
+06.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/InsertEnemy.rst b/doc/sphinx/lfun/InsertEnemy.rst
new file mode 100644
index 0000000..5ceb153
--- /dev/null
+++ b/doc/sphinx/lfun/InsertEnemy.rst
@@ -0,0 +1,63 @@
+InsertEnemy()
+=============
+
+gefunden : lfun/InsertEnemy
+
+FUNKTION
+--------
+::
+
+ int InsertEnemy(object enemy)
+
+
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+
+
+ARGUMENTE
+---------
+::
+
+ enemy: Das Lebewesen, das angegriffen werden soll.
+
+
+
+BESCHREIBUNG
+------------
+::
+
+ Nach Aufruf der Funktion wird das Wesen in die Liste der Feinde
+ aufgenommen.
+ In jedem heart_beat() wird dann ein anwesender Feind
+ angegriffen.
+
+
+
+RUECKGABEWERT
+-------------
+::
+
+ 0, falls der Feind nicht existiert, kein Lebewesen ist, ein Geist ist,
+ oder im Gegner P_NO_ATTACK gesetzt ist, oder schon angegegriffen
+ wurde
+ 1 sonst
+
+
+
+SIEHE AUCH
+----------
+::
+
+ Kill, IsEnemy, StopHuntFor, P_NO_ATTACK
+
+LETZTE AENDERUNG
+----------------
+::
+
+26.08.2010, Zesstra
+
diff --git a/doc/sphinx/lfun/InsertEnemyTeam.rst b/doc/sphinx/lfun/InsertEnemyTeam.rst
new file mode 100644
index 0000000..c738b69
--- /dev/null
+++ b/doc/sphinx/lfun/InsertEnemyTeam.rst
@@ -0,0 +1,67 @@
+InsertEnemyTeam()
+=================
+
+FUNKTION
+--------
+::
+
+ varargs void InsertEnemyTeam(mixed ens, int rek)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ ens object Feind oder object *Feinde
+ rek Wurde von InsertEnemyTeam aufgerufen
+
+BESCHREIBUNG
+------------
+::
+
+ Alle Teammitglieder des Feindes bzw. die angegebenen Feinde (aber
+ nicht deren Teammitglieder) werden zu Feinden
+ a) des Spielers und aller Teammitglieder, falls rek==0
+ b) des Spielers, falls rek!=0
+
+RUECKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ 1. Nur wenn Gegner und Teammitglied im gleichen Raum stehen (aber
+ nicht notwendigerweise im gleichen Raum wie der Spieler) werden
+ sie zu Feinden.
+ 2. Falls Teammitglied und Gegner beides Spieler sind, werden sie
+ nicht zu Feinden gemacht.
+ 3. Ist der Gegner im eigenen Team, so wird nichts gemacht.
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: AssocMember, DeAssocMember, SelectNearEnemy,
+ SelectFarEnemy
+ Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+ PresentTeamPosition, SwapRows
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/InsertSensitiveObject.rst b/doc/sphinx/lfun/InsertSensitiveObject.rst
new file mode 100644
index 0000000..e8f06f0
--- /dev/null
+++ b/doc/sphinx/lfun/InsertSensitiveObject.rst
@@ -0,0 +1,68 @@
+InsertSensitiveObject()
+=======================
+
+FUNKTION
+--------
+::
+
+ void InsertSensitiveObject(object ob, mixed *arg)
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/inventory.c
+ generalizes /std/living/inventory.c
+
+BESCHREIBUNG
+------------
+::
+
+ Fuegt "ob" in die Benachrichtigungslisten des Containers ein.
+ Wird von thing/moving.c im Ziel-Environment gerufen, wenn
+ P_SENSITIVE gesetzt ist.
+
+BEMERKUNGEN
+-----------
+::
+
+ Setzt man P_SENSITIVE nicht als Default sondern situationsabhaengig,
+ dann muss man auch InsertSensitiveObject() im Environment
+ auch selbst rufen!
+
+BEISPIEL
+--------
+::
+
+ // Fackel (inheriting lightsource)
+ // wenn angezuendet, aendert es die Eigenschaften und wird zum
+ // aktiven Objekt - das muss man dem environment() mitteilen
+ static int light(string str) {
+ int i;
+ i=::light(str);
+ if(i && QueryProp(P_LIGHT)>0) {
+ SetProp(P_SENSITIVE,
+ ({({SENSITIVE_INVENTORY_TRIGGER,DT_FIRE,120})}));
+ if(environment())
+ environment()->InsertSensitiveObject(this_object(),
+ QueryProp(P_SENSITIVE));
+ }
+ return i;
+ }
+
+ - falls ein empfindliches Objekt im environment() ist, dann wird
+ in diesem nun eventuell (Treshold) trigger_sensitive_inv()
+ gerufen
+
+SIEHE AUCH
+----------
+::
+
+ P_SENSITIVE
+ RemoveSensitiveObject
+ insert_sensitive_inv_trigger, insert_sensitive_inv
+ P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY, P_SENSITIVE_INVENTORY_TRIGGER
+ CheckSensitiveAttack
+
+25.Apr.2001, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/InternalModifyAttack.rst b/doc/sphinx/lfun/InternalModifyAttack.rst
new file mode 100644
index 0000000..88f93bc
--- /dev/null
+++ b/doc/sphinx/lfun/InternalModifyAttack.rst
@@ -0,0 +1,58 @@
+InternalModifyAttack()
+======================
+
+InternalModifyAttack(L)
+-----------------------
+::
+
+FUNKTION
+--------
+::
+
+ protected void InternalModifyAttack(mapping ainfo)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat
+
+ARGUMENTE
+---------
+::
+
+ mapping ainfo Werte aus der Attack
+
+BESCHREIBUNG
+------------
+::
+
+ Dient dazu noch Aenderungen am Verhalten der Attack() vornehmen zu
+ koennen. Die Parameter werden alle per Referenz uebergeben, Aenderungen
+ wirken also direkt in der Attack()!
+ Einfach ueberschreiben (aber ::InternalModifyAttack(&ainfo) nicht
+ vergessen!
+
+ Aufbau von 'ainfo':
+ ([ SI_ENEMY : object Angreifer, (-> Defend)
+ SI_SPELL : 0/1/array Spellparameter, (-> Defend)
+ P_WEAPON : - oder Waffe,
+ SI_SKILLDAMAGE_MSG: string Angriffsmeldungsende an Raum,
+ SI_SKILLDAMAGE_MSG2: string Angriffsmeldungsende an Kaempfende,
+ SI_SKILLDAMAGE: int Schaden in Zehntel HP (Skills schon drin)
+ (-> Defend),
+ SI_SKILLDAMAGE_TYPE: string/string* Schadenstypen, (-> Defend)
+ P_WEAPON_TYPE: string Waffentyp (combat.h),
+ P_WC: - oder int WC der Waffe/Hand,
+ P_NR_HANDS: - oder int Hands der Waffe/Hand,
+ ]);
+
+SIEHE AUCH
+----------
+::
+
+ InternalModifyDefend(L)
+ Attack(L)
+
+28.03.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/InternalModifyDefend.rst b/doc/sphinx/lfun/InternalModifyDefend.rst
new file mode 100644
index 0000000..c270006
--- /dev/null
+++ b/doc/sphinx/lfun/InternalModifyDefend.rst
@@ -0,0 +1,50 @@
+InternalModifyDefend()
+======================
+
+InternalModifyDefend(L)
+-----------------------
+::
+
+FUNKTION
+--------
+::
+
+ protected void InternalModifyDefend(int dam, mixed dt, mixed spell,
+ object enemy)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat
+
+ARGUMENTE
+---------
+::
+
+ int dam Staerke des abzuwehrenden Angriffs (in HP/10)
+ string/string* dt Art(en) des Schadens, der angerichtet werden soll
+ int/mapping spell 0 fuer normale Angriffe (keine Zauber)
+ 1 fuer Zauber (Standardruestungen ignorieren)
+ mapping fuer mehr Informationen
+ object enemy der Feind/Schadenverursacher
+
+BESCHREIBUNG
+------------
+::
+
+ Dient dazu noch Aenderungen am Verhalten der Defend() vornehmen zu
+ koennen. Die Parameter werden alle per Referenz uebergeben, Aenderungen
+ wirken also direkt in der Defend()!
+ Einfach ueberschreiben, aber ::InternalModifyDefend(&..., &....) nicht
+ vergessen!
+
+SIEHE AUCH
+----------
+::
+
+ InternalModifyAttack(L)
+ Defend(L)
+
+28.03.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/IsArmour.rst b/doc/sphinx/lfun/IsArmour.rst
new file mode 100644
index 0000000..5cb003d
--- /dev/null
+++ b/doc/sphinx/lfun/IsArmour.rst
@@ -0,0 +1,55 @@
+IsArmour()
+==========
+
+FUNKTION
+--------
+::
+
+ status IsArmour()
+
+DEFINIERT IN
+------------
+::
+
+ /std/armour/wear.c
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 wenn ein Ruestung
+ 0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt 1 zurueck, wenn entsprechende Klasse irgendwo geerbt wurden, es
+ also eine Ruestung ist.
+
+BEMERKUNGEN
+-----------
+::
+
+ Entsprechende Basisklasse ueberschreibt und gibt fuer IsClothing()
+ explizit 0 zurueck.
+
+BEISPIEL
+--------
+::
+
+ // enthaelt im Gegensatz zu P_ARMOURS auch nichtgetragenen Kram
+ // im Inventory L1
+ object *allarmours =
+ filter_objects(all_inventory(this_player()), "IsArmour")
+
+SIEHE AUCH
+----------
+::
+
+ Aehnlich: living, interactive
+ Aehnlich: IsBottle, IsClothing, IsPlayerCorpse, IsRoom, IsUnit
+ Props: P_ARMOURS
+
+3. Sep 2016, Gloinson
+
diff --git a/doc/sphinx/lfun/IsBottle.rst b/doc/sphinx/lfun/IsBottle.rst
new file mode 100644
index 0000000..a1c1b1d
--- /dev/null
+++ b/doc/sphinx/lfun/IsBottle.rst
@@ -0,0 +1,42 @@
+IsBottle()
+==========
+
+IsPlayerCorpse
+--------------
+::
+
+FUNKTION
+--------
+::
+
+ int IsBottle()
+
+DEFINIERT IN
+------------
+::
+
+ /std/items/flasche.c
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 wenn Flasche
+ 0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt 1 zurueck, wenn das eine Flasche mit ordentlichem Flaschenverhalten
+ ist.
+
+SIEHE AUCH
+----------
+::
+
+ Aehnlich: living, interactive
+ Aehnlich: IsArmour, IsClothing, IsPlayerCorpse, IsRoom, IsUnit
+
+3. Sep 2016, Gloinson
+
diff --git a/doc/sphinx/lfun/IsClothing.rst b/doc/sphinx/lfun/IsClothing.rst
new file mode 100644
index 0000000..b8108df
--- /dev/null
+++ b/doc/sphinx/lfun/IsClothing.rst
@@ -0,0 +1,49 @@
+IsClothing()
+============
+
+FUNKTION
+--------
+::
+
+ status IsClothing()
+
+DEFINIERT IN
+------------
+::
+
+ /std/clothing.c
+ /std/clothing_container.c
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 wenn ein Kleidungsstueck
+ 0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt 1 zurueck, wenn entsprechende Klassen irgendwo geerbt wurden, es
+ also ein Kleidungsstueck (oder ein Kleidungsstueck mit Taschen) ist.
+
+BEISPIEL
+--------
+::
+
+ // enthaelt im Gegensatz zu P_CLOTHING auch nichtgetragenen Kram
+ // im Inventory L1
+ object *allcloth =
+ filter_objects(all_inventory(this_player()), "IsClothing")
+
+SIEHE AUCH
+----------
+::
+
+ Aehnlich: living, interactive
+ Aehnlich: IsArmour, IsBottle, IsPlayerCorpse, IsRoom, IsUnit
+ Props: P_CLOTHING
+
+3. Sep 2016, Gloinson
+
diff --git a/doc/sphinx/lfun/IsEnemy.rst b/doc/sphinx/lfun/IsEnemy.rst
new file mode 100644
index 0000000..5bd7957
--- /dev/null
+++ b/doc/sphinx/lfun/IsEnemy.rst
@@ -0,0 +1,51 @@
+IsEnemy()
+=========
+
+FUNKTION
+--------
+::
+
+ int IsEnemy(object wer);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ wer
+ Das Objekt, welches darauf ueberprueft werden soll, ob es
+ derzeit als Gegner bekannt ist.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Flag: 1 bei Feindschaft, 0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion kann man ueberpruefen, ob das Objekt <wer>, also
+ im Normalfall ein Lebewesen, derzeit als Gegner erkannt wird. Nach
+ einer gewissen Zeit laeuft die Feindschaft automatisch aus, sodass
+ man sich nicht darauf verlassen, dass ein Gegner auch zukuenftig als
+ solchiger erkannt wird. (Diese Zeit betraegt normal 300 Sekunden.)
+ Solch eine Feindschaft kann im uebrigen auch einseitig sein! Mehr
+ dazu findet man in der Dokumentation zu StopHuntFor(), einer
+ Funktion, die Frieden zwischen Gegnern stiften soll.
+
+SIEHE AUCH
+----------
+::
+
+ SelectEnemy(), QueryEnemies(), StopHuntFor()
+
+
+Last modified: Wed May 26 16:47:51 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/IsEqual.rst b/doc/sphinx/lfun/IsEqual.rst
new file mode 100644
index 0000000..8d12ce3
--- /dev/null
+++ b/doc/sphinx/lfun/IsEqual.rst
@@ -0,0 +1,58 @@
+IsEqual()
+=========
+
+FUNKTION
+--------
+::
+
+ int IsEqual(object ob)
+
+DEFINIERT IN
+------------
+::
+
+ /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+ ob Das Objekt das geprueft werden soll.
+
+BESCHREIBUNG:
+ Diese Funktion prueft ob zwei Objekte vom gleichen Typ sind, also ob
+ z.B. ob und this_object() beides Muenzen sind oder beides Edelsteine.
+ Bei einem Ergebnis != 0 fasst unit.c diese zwei Objekte automatisch
+ zusammen, wenn ob->IsEqual(this_object()) auch einen Wert != 0 ergibt.
+ Hierbei wird das IsEqual() von beiden beteiligten Objekten gerufen und sie
+ muessen uebereinstimmen, dass sie eigentlich das gleiche Objekt sind.
+ Selbstverstaendlich ist diese Funktion nur im Falle von Unitobjekten
+ sinnvoll.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0 - this_object() ist nicht vom selben Typ wie ob
+ 1 - this_object() ist vom gleichen Typ wie ob
+
+BEISPIELE
+---------
+::
+
+ o Ein Unitobjekt das verschiedene Beschreibungen haben kann...
+
+ int IsEqual(object ob)
+ {
+ if (!(int)::IsEqual(ob)) return 0;
+ return (QueryProp(P_SHORT)==ob->QueryProp(P_SHORT));
+ }
+
+SIEHE AUCH
+----------
+::
+
+ /std/unit.c
+
+25.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/IsPlayerCorpse.rst b/doc/sphinx/lfun/IsPlayerCorpse.rst
new file mode 100644
index 0000000..d0fcf19
--- /dev/null
+++ b/doc/sphinx/lfun/IsPlayerCorpse.rst
@@ -0,0 +1,38 @@
+IsPlayerCorpse()
+================
+
+FUNKTION
+--------
+::
+
+ public int IsPlayerCorpse()
+
+DEFINIERT IN
+------------
+::
+
+ /std/corpse.c
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 wenn Spielerleiche
+ 0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt 1 zurueck, wenn diese Leiche eine Spielerleiche ist. Es kann auch
+ eine "normale" NPC-Leiche sein.
+
+SIEHE AUCH
+----------
+::
+
+ Aehnlich: living, interactive
+ Aehnlich: IsArmour, IsBottle, IsClothing, IsRoom, IsUnit
+
+3. Sep 2016, Gloinson
+
diff --git a/doc/sphinx/lfun/IsRoom.rst b/doc/sphinx/lfun/IsRoom.rst
new file mode 100644
index 0000000..3d61120
--- /dev/null
+++ b/doc/sphinx/lfun/IsRoom.rst
@@ -0,0 +1,38 @@
+IsRoom()
+========
+
+FUNKTION
+--------
+::
+
+ status IsRoom()
+
+DEFINIERT IN
+------------
+::
+
+ /std/room.c
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 wenn ein Raum
+ 0 sonst
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt 1 zurueck, wenn /std/room.c irgendwo geerbt wurde, es also ein
+ Raum ist.
+
+SIEHE AUCH
+----------
+::
+
+ Aehnlich: living, interactive
+ Aehnlich: IsArmour, IsBottle, IsClothing, IsPlayerCorpse, IsUnit
+
+3. Sep 2016, Gloinson
+
diff --git a/doc/sphinx/lfun/IsTeamLeader.rst b/doc/sphinx/lfun/IsTeamLeader.rst
new file mode 100644
index 0000000..0035a16
--- /dev/null
+++ b/doc/sphinx/lfun/IsTeamLeader.rst
@@ -0,0 +1,69 @@
+IsTeamLeader()
+==============
+
+FUNKTION
+--------
+::
+
+ object IsTeamLeader()
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Testet, ob der Spieler ein Teamleiter ist.
+
+RUECKGABEWERT
+-------------
+::
+
+ Falls der Spieler Teamleiter ist, wird das Teamobjekt zurueckgegeben,
+ sonst 0.
+
+BEISPIEL
+--------
+::
+
+ string leader_test(object pl)
+ {
+ ...
+
+ if ( objectp(pl->IsTeamLeader()) )
+ return "Als Leiter eines Teams hast Du grosse Verantwortung zu "
+ "tragen!";
+ else
+ return "Wenn Du mal Leiter eines Teams sein moechtes, solltest "
+ "Du Dir vorher der Verantwortung bewusst werden!";
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: TeamMembers
+ Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
+ SelectNearEnemy, SelectFarEnemy
+ Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+ PresentTeamPosition, SwapRows
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/IsTeamMove.rst b/doc/sphinx/lfun/IsTeamMove.rst
new file mode 100644
index 0000000..70ed97f
--- /dev/null
+++ b/doc/sphinx/lfun/IsTeamMove.rst
@@ -0,0 +1,61 @@
+IsTeamMove()
+============
+
+FUNKTION
+--------
+::
+
+ object IsTeamMove()
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Testet, ob momentan die Angriffsbewegung ausgefuehrt wird.
+
+RUECKGABEWERT
+-------------
+::
+
+ Falls die Angriffsbewegung gerade ausgefuehrt wird, wird das
+ Teamobjekt zurueckgegeben, sonst 0.
+
+BEMERKUNGEN
+-----------
+::
+
+ Wird intern benoetigt, damit der Begruessungsschlag verzoegert
+ werden kann, bis alle Teammitglieder ihre Angriffsbewegung
+ ausgefuehrt haben.
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: TeamFlee
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
+ SelectNearEnemy, SelectFarEnemy
+ Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+ PresentTeamPosition, SwapRows
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/IsUnit.rst b/doc/sphinx/lfun/IsUnit.rst
new file mode 100644
index 0000000..1dc26ea
--- /dev/null
+++ b/doc/sphinx/lfun/IsUnit.rst
@@ -0,0 +1,43 @@
+IsUnit()
+========
+
+FUNKTION
+--------
+::
+
+ int IsUnit();
+
+DEFINIERT IN
+------------
+::
+
+ /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert immer 1 zurueck und zeigt damit an, dass es sich
+ bei diesem Objekt um ein Mengenobjekt handelt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 bei allen Objekten, die /std/unit.c erben, ansonsten 0.
+
+SIEHE AUCH
+----------
+::
+
+ /std/unit.c
+
+
+Last modified: Wed May 8 10:20:19 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/Kill.rst b/doc/sphinx/lfun/Kill.rst
new file mode 100644
index 0000000..ba5ae9e
--- /dev/null
+++ b/doc/sphinx/lfun/Kill.rst
@@ -0,0 +1,43 @@
+Kill()
+======
+
+FUNKTION
+--------
+::
+
+ int Kill(object enemy)
+
+ARGUMENTE
+---------
+::
+
+ enemy: Der boese, boese Feind.
+
+BESCHREIBUNG
+------------
+::
+
+ Nach Aufruf der Funktion wird der Feind in jedem
+ heart_beat() attackiert.
+
+RUECKGABEWERT
+-------------
+::
+
+ 0, Falls der Feind nicht existiert
+ -1, falls der Feind ein Geist ist
+ -2, falls der Feind P_NO_ATTACK gesetzt hat
+ -3, falls der Angreifer selber P_NO_ATTACK gesetzt hat
+ -4, falls der Feind bereits angegriffen wurde
+ 1 falls der Feind erfolgreich als Find registriert wurde.
+
+BEMERKUNGEN
+-----------
+::
+
+SIEHE AUCH
+----------
+::
+
+ InsertEnemy
+
diff --git a/doc/sphinx/lfun/LearnSkill.rst b/doc/sphinx/lfun/LearnSkill.rst
new file mode 100644
index 0000000..89694a9
--- /dev/null
+++ b/doc/sphinx/lfun/LearnSkill.rst
@@ -0,0 +1,53 @@
+LearnSkill()
+============
+
+FUNKTION
+--------
+::
+
+ public varargs void LearnSkill(string sname, int add, int diff)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skills.c
+
+ARGUMENTE
+---------
+::
+
+ string sname der zu lernende Skill
+ string add Anzahl zu lernender Skillpunkte
+ int diff Schwierigkeit
+
+BESCHREIBUNG
+------------
+::
+
+ Die Methode laesst einen interaktiven (eingeloggten) Spieler den
+ Skill 'sname' um 'add' Punkte lernen.
+
+ Dabei wird sichergestellt, dass 'add' den Wert MAX_SKILLEARN nicht
+ ueberschreitet, der Skill nicht verschwindet und fuer uebergeordnete
+ Skills (SI_INHERIT) dieser uebergeordnete Skill auch einen Lerneffekt
+ erfaehrt.
+
+ Wird zB von Learn (spellbook) und SpellSuccess (spellbook) gerufen.
+
+SIEHE AUCH
+----------
+::
+
+ Skills Lernen: ModifySkill, LimitAbility
+ * Nutzung: UseSpell, UseSkill
+ * Abfragen: QuerySkill, QuerySkillAbility
+ * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+ QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+ * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+ * sonstig: spruchermuedung
+ * Properties: P_NEWSKILLS
+ Spellbook: Learn, SpellSuccess
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/Leave.rst b/doc/sphinx/lfun/Leave.rst
new file mode 100644
index 0000000..e196f57
--- /dev/null
+++ b/doc/sphinx/lfun/Leave.rst
@@ -0,0 +1,65 @@
+Leave()
+=======
+
+FUNKTION
+--------
+::
+
+ int Leave();
+
+DEFINIERT IN
+------------
+::
+
+ /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Wenn sich der Spieler auf einem Transporter befindet, und dieser sich
+ momentan an einer Haltestelle liegt, verlaesst der Spieler den
+ Transporter.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Null, wenn der Spieler den Transporter nicht verlassen konnte, sonst
+ ungleich Null.
+
+BEMERKUNGEN
+-----------
+::
+
+ Es werden keine Tests durchgefuehrt, ob der Transporter ueberhaupt
+ angesprochen wurde! Das muss man selber machen.
+
+BEISPIELE
+---------
+::
+
+ int myLeave(string str)
+ {
+ if (str && id(str))
+ return Leave();
+
+ notify_fail("Was willst Du verlassen?\n");
+ return 0;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Enter(), /std/transport.c
+
+
+Last modified: Wed May 8 10:20:30 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/LimitAbility.rst b/doc/sphinx/lfun/LimitAbility.rst
new file mode 100644
index 0000000..b061295
--- /dev/null
+++ b/doc/sphinx/lfun/LimitAbility.rst
@@ -0,0 +1,67 @@
+LimitAbility()
+==============
+
+FUNKTION
+--------
+::
+
+ protected varargs mixed LimitAbility(mixed sinfo, int diff)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skills.c
+
+ARGUMENTE
+---------
+::
+
+ mixed sinfo Skill-Informationen
+ int diff Schwierigkeit
+
+BESCHREIBUNG
+------------
+::
+
+ Setzt ein Maximum an Skillfertigkeit basierend auf der Schwierigkeit
+ und dem P_LEVEL des Spielers.
+
+
+
+ Folgend eine Kopie (!) der Tabelle aus /std/living/skills:
+ diff|lvl 1:| 3:| 7:| 10:| 13:| 16:| 19:| 22:| 25:| 28:| 31:| 34:|
+ ----+------+-----+-----+----+----+----+----+----+----+----+----+----+
+ -50| 83%| 84%| 86%| 87%| 89%| 90%| 92%| 93%| 95%| 96%| 98%| 99%|
+ -10| 69%| 72%| 74%| 77%| 80%| 82%| 85%| 88%| 91%| 93%| 96%| 99%|
+ 0| 66%| 69%| 72%| 75%| 78%| 81%| 84%| 87%| 90%| 93%| 96%| 99%|
+ 10| 62%| 65%| 69%| 72%| 75%| 79%| 82%| 85%| 89%| 92%| 95%| 98%|
+ 20| 59%| 62%| 66%| 70%| 73%| 77%| 80%| 84%| 88%| 91%| 95%| 98%|
+ 30| 55%| 59%| 63%| 67%| 71%| 75%| 79%| 83%| 87%| 90%| 94%| 98%|
+ 40| 52%| 56%| 60%| 65%| 69%| 73%| 77%| 81%| 86%| 90%| 94%| 98%|
+ 50| 49%| 53%| 58%| 62%| 67%| 71%| 76%| 80%| 85%| 89%| 94%| 98%|
+ 100| 32%| 38%| 44%| 50%| 56%| 62%| 68%| 74%| 80%| 86%| 92%| 98%|
+ 150| 15%| 22%| 30%| 37%| 45%| 52%| 60%| 67%| 75%| 82%| 90%| 97%|
+ 200| -2%| 7%| 16%| 25%| 34%| 43%| 52%| 61%| 70%| 79%| 88%| 97%|
+ 250| -19%| -8%| 2%| 12%| 23%| 33%| 44%| 54%| 65%| 75%| 86%| 96%|
+ 300| -36%| -24%| -12%| 0%| 12%| 24%| 36%| 48%| 60%| 72%| 84%| 96%|
+ 400| -70%| -55%| -40%|-25%|-10%| 5%| 20%| 35%| 50%| 65%| 80%| 95%|
+ 500| -104%| -86%| -68%|-50%|-32%|-14%| 4%| 22%| 40%| 58%| 76%| 94%|
+ 600| -138%|-117%| -96%|-75%|-54%|-33%|-12%| 9%| 30%| 51%| 72%| 93%|
+
+SIEHE AUCH
+----------
+::
+
+ Skills Lernen: LearnSkill, ModifySkill
+ * Nutzung: UseSpell, UseSkill
+ * Abfragen: QuerySkill, QuerySkillAbility
+ * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+ QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+ * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+ * sonstig: spruchermuedung
+ * Properties: P_NEWSKILLS
+ Spellbook: Learn, SpellSuccess
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/MaterialGroup.rst b/doc/sphinx/lfun/MaterialGroup.rst
new file mode 100644
index 0000000..482281e
--- /dev/null
+++ b/doc/sphinx/lfun/MaterialGroup.rst
@@ -0,0 +1,64 @@
+MaterialGroup()
+===============
+
+FUNKTION
+--------
+::
+
+ int MaterialGroup(mapping mats, string grp)
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/materialdb.c (MATERIALDB)
+
+ARGUMENTE
+---------
+::
+
+ mapping mats - Materialienmapping
+ string grp - Materialiengruppe
+
+BESCHREIBUNG
+------------
+::
+
+ Die Materialien im Mapping werden auf Zugehoerigkeit zu der Gruppe
+ untersucht und der Gesamtanteil dieser Materialiengruppe am Mapping
+ in Prozent zurueckgegeben (wenn das Mapping sich auf 100% aufaddiert).
+
+RUECKGABEWERT
+-------------
+::
+
+ int - prozentualer Anteil der Materialiengruppe -100 ... 100 %
+
+BEISPIELE
+---------
+::
+
+ if(MATERIALDB->MaterialGroup(
+ ([MAT_MISC_STONE:40,MAT_AMETHYST:50,MAT_MISC_METAL:10]),
+ MATGROUP_JEWEL)>50)
+ write("Oh ja, darin sind sehr viele Edelsteine!\n");
+
+BEMERKUNGEN
+-----------
+::
+
+ Wird von /std/thing/description::QueryMaterialGroup() gerufen.
+ Bitte an Objekten auch QueryMaterialGroup() verwenden.
+
+SIEHE AUCH
+----------
+::
+
+ Konzepte: material, materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Master: AddMaterial(), ConvMaterialList()
+ GroupName(), MaterialName(),
+ GetGroupMembers(), GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/MaterialList.rst b/doc/sphinx/lfun/MaterialList.rst
new file mode 100644
index 0000000..141eaad
--- /dev/null
+++ b/doc/sphinx/lfun/MaterialList.rst
@@ -0,0 +1,96 @@
+MaterialList()
+==============
+
+MaterialList(L)
+---------------
+::
+
+FUNKTION
+--------
+::
+
+ varargs string MaterialList(int casus, mixed idinf)
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ int casus - der Fall, in dem die Materialien dekliniert werden sollen
+ mixed idinf - Dinge, welche die Faehigkeiten des Erkennens beeinflussen:
+ Einzelne Werte:
+ * x: allgemeine Erkennung -100 ... 100
+ * who: der Spieler - P_MATERIAL_KNOWLEDGE wird abgefragt
+ * fun: wird evaluiert
+ * what, kann folgendes enthalten:
+ - Eintrag fuer Materialien ([MAT_XXX:-100...100])
+ - Eintrag fuer Materialiengruppen (dito)
+ - ([MATERIAL_SYMMETRIC_RECOGNIZABILITY: mixed mg])
+ * mg ein Array:
+ ({MATGROUP_X1,int z1, MATGROUP_X2, int z2, ...})
+ wobei bei Zugehoerigkeit von string mat zu Gruppe
+ z<n> auf die Faehigkeit addiert, andernfalls davon
+ subtrahiert wird
+ Array mit obigen Werten:
+ - alle Parameter des Arrays sind optional und additiv
+ - ({int x, object who, mapping what, closure fun})
+
+BESCHREIBUNG
+------------
+::
+
+ Listet die Materialien auf, aus denen ein Objekt besteht.
+ Dabei haengt die Genauigkeit der Materialerkennung von idinf ab. D.h.
+ je nach den Faehigkeiten/der angegebenen Faehigkeit wird zB Wolfram
+ als "Wolfram" oder nur als "Metall" erkannt.
+
+ Wenn ein Spieler etwas identifiziert, sollte auch TP uebergeben werden,
+ bei NPCs koennte das anders aussehen.
+
+RUECKGABEWERT
+-------------
+::
+
+ String mit Liste der Materialien.
+
+BEMERKUNGEN
+-----------
+::
+
+ - es werden nur die Materialien angegeben, nicht die Menge.
+ - ruft ConvMaterialList() an der MATERIALDB
+
+BEISPIELE
+---------
+::
+
+ // simpel
+ write("Der Gegenstand besteht aus"+ob->MaterialList(WEM,TP)+".\n")
+ // -> "Der Gegenstand besteht aus Gold, Silber und Rubin.\n"
+
+ // komplexer
+ ob->SetProp(P_MATERIAL, ([P_NITROGLYCERINE:90,P_GUNPOWDER:10]));
+ write("Das enthaelt "+ob->MaterialList(WER,TP)+".\n");
+ // -> "Das enthaelt Schwarzpulver und Nitroglycerin."
+
+SIEHE AUCH
+----------
+::
+
+ Konzepte: material, materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Methoden: QueryMaterial(), QueryMaterialGroup()
+ Listen: AllMaterials(), AllGroups(), Dump()
+ materialliste, materialgruppen
+ Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
+ GroupName(), MaterialName(),
+ GetGroupMembers(), GetMatMembership()
+ Sonstiges: P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/MaterialName.rst b/doc/sphinx/lfun/MaterialName.rst
new file mode 100644
index 0000000..fb30eb4
--- /dev/null
+++ b/doc/sphinx/lfun/MaterialName.rst
@@ -0,0 +1,96 @@
+MaterialName()
+==============
+
+FUNKTION
+--------
+::
+
+ varargs string MaterialName(string mat, int casus, mixed idinf)
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/materialdb.c (MATERIALDB)
+
+ARGUMENTE
+---------
+::
+
+ string mat - das zu erkennende Material
+ int casus - der Fall
+ mixed idinf - Dinge, welche die Faehigkeiten des Erkennens beeinflussen
+ (siehe "man MaterialList")
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion sucht unter Beruecksichtigung der Erkennungsbe-
+ schraenkungen des Materials und Faehigkeiten des Spielers den
+ Klarnamen des Materials heraus und gibt den zurueck.
+
+RUECKGABEWERT
+-------------
+::
+
+ string: Materialname oder genereller Name.
+
+BEISPIELE
+---------
+::
+
+ // der hier mag alle existierenden Juwelen, auch wenn welche ergaenzt
+ // werden sollten
+ // Parameter: 1. ein Juwel, 2. Casus, 3. 100% Erkennung - ob er sie
+ // beim Empfang dann auch zu 100% erkennt, steht hier nicht!
+ string* likeit;
+ likeit=MATERIALDB->GetGroupMembers(MATGROUP_JEWEL);
+ ...
+ write("Der Alte sagt: Ich mag "+
+ MATERIALDB->MaterialName(likeit[random(sizeof(likeit))], WEN, 100)+
+ ".\n");
+ ...
+
+ // ein weiser schmied:
+ int i;
+ string *mat, mname, mgroup;
+ mat=m_indices(ob->queryprop(p_material));
+ i=sizeof(mat);
+
+ write("der schmied sagt: "+ob->name(wer)+" besteht aus ...\n");
+ while(i--) {
+ // den namen erkennen/aussprechen:
+ // materialien werden allgemein ganz schlecht erkannt (zu 5%), aber
+ // alles aus metall wird zu +100% gut erkannt ...
+ mname=materialdb->materialname(mat[i], wer,
+ ({5, ([material_symmetric_recognizability:
+ ({matgroup_metal, 100})])}));
+
+ // und nur metalle analysieren ...
+ if(materialdb->materialgroup(([mat[i]:100]),matgroup_metal)>=100) {
+ int j;
+ string *mgr;
+ mgr=materialdb->getmatmembership(mat[i]);
+ j=sizeof(mgr);
+ mgroup=" gehoert zu ";
+ while(j--) {
+ mgroup+=materialdb->groupname(mgr[j]);
+ if(j>0) mgroup+=", ";
+ }
+ } else mgroup=" kenne ich nicht";
+ printf("%-12.12s: %s\n",mname, mgroup);
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Konzepte: material, materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
+ GroupName()
+ GetGroupMembers(), GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/MayAddObject.rst b/doc/sphinx/lfun/MayAddObject.rst
new file mode 100644
index 0000000..f9b6e9f
--- /dev/null
+++ b/doc/sphinx/lfun/MayAddObject.rst
@@ -0,0 +1,56 @@
+MayAddObject()
+==============
+
+FUNKTION
+--------
+::
+
+ int MayAddObject(object ob);
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+ ob - Das Object bei dem geprueft werden soll, ob es noch in den
+ Container passt.
+
+BESCHREIBUNG
+------------
+::
+
+ Wenn ein Objekt in einen Container bewegt wird, prueft move() ueber
+ diese Funktion, ob das Objekt ueberhaupt noch in den Behaelter hinein
+ passt. Dazu uebergibt move() das Objekt das in den Container bewegt
+ werden soll. (In Raeumen ist diese Funktionen ueberschrieben und
+ liefert immer True zurueck.)
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 - wenn das Objekt noch vom Container aufgenommen werden kann.
+ 0 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+ invis-Objekte passen immer in den Container hinein!
+ move() ruft diese Funktion nicht auf, wenn in den Flags M_NOCHECK
+ gesetzt war!
+
+SIEHE AUCH
+----------
+::
+
+ MayAddWeight(), PreventInsert(), move(), /std/container/restrictions.c
+
+
+Last modified: 23.09.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/MayAddWeight.rst b/doc/sphinx/lfun/MayAddWeight.rst
new file mode 100644
index 0000000..d4d6f3c
--- /dev/null
+++ b/doc/sphinx/lfun/MayAddWeight.rst
@@ -0,0 +1,73 @@
+MayAddWeight()
+==============
+
+FUNKTION
+--------
+::
+
+ int MayAddWeight(int gewicht);
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+ gewicht
+ Das zu pruefende Gewicht.
+
+BESCHREIBUNG
+------------
+::
+
+ Wenn ein Objekt ein einen Behaelter bewegt wird, prueft move() ueber
+ diese Funktion, ob das Objekt ueberhaupt noch in den Behaelter hinein
+ passt. Dazu uebergibt move() dieser Funktion das Gewicht des zu
+ bewegenden Objektes.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn der Behaelter noch ein gewicht Gramm wiegendes Objekt aufnehmen
+ kann, -1 im anderen Fall.
+
+BEMERKUNGEN
+-----------
+::
+
+ move() ruft diese Funktion nicht auf, wenn in den Flags M_NOCHECK
+ gesetzt war!
+
+BEISPIELE
+---------
+::
+
+ Die entsprechende Abfrage in /std/thing/moving.c sieht etwa
+ folgendermassen aus:
+
+ int weight;
+
+ ...
+ weight = QueryProp(P_TOTAL_WEIGHT); // Behaelter? Ja => Gesamtgewicht
+ if (!weight)
+ weight = QueryProp(P_WEIGHT); // Nein: einfaches Gewicht
+
+ if (ziel->MayAddWeight(weight) == -1) // Passt es noch rein?
+ return ME_TOO_HEAVY; // Nein, entspr. Fehler zurueckgeben
+
+ ...
+
+SIEHE AUCH
+----------
+::
+
+ MayAddObject(), PreventInsert(), move(), /std/container/restrictions.c
+
+
+Last modified: 23.09.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/Message.rst b/doc/sphinx/lfun/Message.rst
new file mode 100644
index 0000000..5bfeffe
--- /dev/null
+++ b/doc/sphinx/lfun/Message.rst
@@ -0,0 +1,40 @@
+Message()
+=========
+
+FUNKTION
+--------
+::
+
+ varargs int Message(string str, int flag)
+
+ARGUMENTE
+---------
+::
+
+ str: Den zu uebermittelnden Text.
+ flag: Beschreibt die Art der Meldung naeher, siehe
+ /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+ Einem Spieler wird der Text str uebermittelt.
+
+RUECKGABEWERT
+-------------
+::
+
+ 1 bei erfolgreicher Uebermittlung
+ 0 wenn der Kobold aktiv war
+ <0 wenn Spieler oder verwendetes Verb ignoriert
+ werden
+
+SIEHE AUCH
+----------
+::
+
+ P_IGNORE, TestIgnore()
+
+12. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/ModifyQuestTime.rst b/doc/sphinx/lfun/ModifyQuestTime.rst
new file mode 100644
index 0000000..de4b652
--- /dev/null
+++ b/doc/sphinx/lfun/ModifyQuestTime.rst
@@ -0,0 +1,67 @@
+ModifyQuestTime()
+=================
+
+FUNKTION
+--------
+::
+
+ int ModifyQuestTime(string questname, int zeit)
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/quests.c
+
+ARGUMENTE
+---------
+::
+
+ questname
+ Questname, wie er im Questmaster eingetragen wurde.
+ zeit
+ Zeitpunkt, zu dem die Quest geloest wurde
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 : Questzeitpunkt erfolgreich nachgetragen
+ -1 : keine Zugriffsrechte (nur EM+ und der Tagebuchmaster erlaubt)
+ -2 : Questliste im Spielerobjekt ist unerwartet kein Mapping
+ -3 : Spieler hat diese Quest noch nicht bestanden
+ -4 : kein gueltiger Zeitpunkt uebergeben (kein Integer, Wert < -1
+ oder Wert > time()).
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion kann der Zeitpunkt nachgetragen werden, zu
+ dem ein Spieler eine bestimmte Quest bereits geloest hat.
+ Als Questname wird dazu der Name angegeben, der im Questmaster
+ eingetragen ist. Der Zeitpunkt ist als Integer-Wert im ueblichen
+ time()-Format anzugeben. Uebergibt man -1 als <zeit>, dann wird
+ der Tagebuchmaster erneut versuchen, das Logfile einzulesen,
+ wenn der Spieler das naechste mal sein Abenteuertagebuch liest.
+
+HINWEIS
+-------
+::
+
+ Die Funktion mktime() ist nuetzlich, wenn der Zeitpunkt des
+ Bestehens einer Quest manuell rekonstruiert werden muss, der
+ Zeitpunkt aber nur als Datums-/Zeitangabe in Textform vorliegt
+ (etwa aus einem Logfile oder aus der Quest-Feedbackmail).
+
+SIEHE AUCH
+----------
+::
+
+ /secure/questmaster.h, /obj/tools/questtool
+ GiveQuest(L)
+ mktime(E), dtime(SE)
+
+
+Zuletzt geaendert: Mon, 27. Jan. 2015, Arathorn
+
diff --git a/doc/sphinx/lfun/ModifySkill.rst b/doc/sphinx/lfun/ModifySkill.rst
new file mode 100644
index 0000000..fa716fe
--- /dev/null
+++ b/doc/sphinx/lfun/ModifySkill.rst
@@ -0,0 +1,98 @@
+ModifySkill()
+=============
+
+FUNKTION
+--------
+::
+
+ public varargs void ModifySkill(string sname, mixed val,
+ int diff, string gilde)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skills.c
+
+ARGUMENTE
+---------
+::
+
+ string sname der zu aendernde Skill
+ mixed val Aenderungswert: int fuer SI_SKILLABILITY, sonst mapping
+ int diff Schwierigkeit (optional: default ist existierendes diff)
+ string gilde Gilde (optional: default ist eigene Gilde)
+
+BESCHREIBUNG
+------------
+::
+
+ Mit der Methode kann man die Werte eines Skills/Spells veraendern. Dabei
+ wird ein Skill immer in ein Mapping umgewandelt (Skills/Spells koennen
+ auch einfach nur ihren Skillwert enthalten, diese ist aequivalent zu
+ einem Mapping mit ([SI_SKILLABILITY:<Skillwert>]).
+
+ Ist 'val' ein int, wird dieses als SI_SKILLABILITY gesetzt. Falls der
+ Skill nur ein int war, wird ein 'diff'!=0 als SI_DIFFICULTY gesetzt.
+
+ Ist 'val' ein Mapping, wird dieses zum Skillmapping addiert.
+
+
+
+ Etwaige SI_SKILLABILITY-Aenderungen laufen danach noch durch LimitAbility.
+
+BEISPIELE
+---------
+::
+
+ // #1a: Lerne einen Spell/Skill (einer Gilde)
+ caster->ModifySkill("feuerball", MAX_ABILITY, 100, "abenteurer")
+ // #1b: ... oder ...
+ caster->ModifySkill("feuerball", ([SI_SKILLABILITY: MAX_ABILITY]), 100,
+ "abenteurer")
+ // #1c: ... oder fuer einen Abenteurer ...
+ caster->ModifySkill("feuerball", ([SI_SKILLABILITY: MAX_ABILITY]), 100);
+
+
+
+ // #2: Setze eine Skill-Funktion fuer einen Kampfskill des Klerus
+ this_player()->ModifySkill(FIGHT(WT_CLUB),
+ ([SI_SKILLFUNC: "Keulenkampf",
+ SI_DIFFICULTY: 100]),
+ 100, "klerus");
+
+ // #3: Speichere im Skill (also Spieler) eine Option fuer diesen Skill
+ // Vorteil: dieser Eintrag wird dem Spell immer uebergeben
+ caster->ModifySkill("blitz", (["klerus_spell_option": 2]));
+
+ (Code in /doc/beispiele/testobjekte/modifyskillspell_test)
+ // #4: Lerne einen unabhaengigen Spell: ACHTUNG
+ // dieser Spell funktioniert nur solange, wie die Closure existiert,
+ // SI_SKILLABILITY und Spell bleiben jedoch im Spieler gespeichert (!)
+ this_player()->ModifySkill("fnrx",
+ ([SI_CLOSURE:
+ function int (object caster, string skill, mapping sinf) {
+ caster->LearnSkill("fnrx", 1);
+ tell_object(caster, "Peng! Dein Skillwert steigt auf "+
+ caster->QuerySkillAbility("fnrx")+".\n");
+ return ERFOLG;
+ },
+ SI_SKILLABILITY: 8432]),
+ 100,
+ "ANY");
+
+SIEHE AUCH
+----------
+::
+
+ Skills Lernen: LearnSkill, LimitAbility
+ * Nutzung: UseSpell, UseSkill
+ * Abfragen: QuerySkill, QuerySkillAbility
+ * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+ QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+ * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+ * sonstig: spruchermuedung
+ * Properties: P_NEWSKILLS
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/ModifySkillAttribute.rst b/doc/sphinx/lfun/ModifySkillAttribute.rst
new file mode 100644
index 0000000..9c4131f
--- /dev/null
+++ b/doc/sphinx/lfun/ModifySkillAttribute.rst
@@ -0,0 +1,135 @@
+ModifySkillAttribute()
+======================
+
+FUNKTION
+--------
+::
+
+ public int ModifySkillAttribute(string atrname, mixed value,
+ int duration)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skill_attributes.c
+
+ARGUMENTE
+---------
+::
+
+ <atrname> string
+ Name des zu veraendernden Attributes
+ (Definiert in /sys/living/skill_attributes.h)
+
+ <value> int oder closure
+ Wert des Modifikators
+ oder
+ eine Closure, welche bei Abfrage des betreffenden SAs
+ abgefragt um den Modifikator zu bestimmen.
+
+ <duration> int
+ Dauer in Sekunden
+
+BESCHREIBUNG
+------------
+::
+
+ Aendert temporaer, d.h. fuer eine bestimmte Zeit, ein Skill-Attribut
+ eines Lebewesen, indem ein Modifikator hinzugefuegt wird.
+
+
+
+ Der Standardwert eines SA wird von P_SKILL_ATTRIBUTE_OFFSETS festgelegt
+ oder ist 100, wenn besagte Property leer ist.
+ Alle Modifikatoren (negativ wie positiv) werden addiert und bilden
+ zusammen mit dem Standardwert eine Gesamtsumme.
+ Bei allen SAs ausser SA_QUALITY wird diese Gesamtsumme noch mit
+ SA_QUALITY (welches sich damit auf alle anderen Skill-Attribute
+ auswirkt) multipliziert und das Ergebnis stellt den Endwert des SA dar.
+ (Beispiel s.u.)
+
+ Der Wert eines Modifikators muss zwischen -1000 und 1000 liegen. Der
+ Gesamtwert eines SA kann 10 nicht unter- und 1000 nicht ueberschreiten.
+
+ Falle <value> eine Closure ist, wird diese Closure jedesmal
+ ausgefuehrt, wenn das entsprechende SA abgefragt wird. Der
+ Rueckgabewert dieser Closure stellt dann den Wert des Modifikators
+ dar. Auch dieser muss zwischen -1000 und 1000 liegen. Gibt die
+ Closure keinen int zurueck, wird der Modifikator geloescht.
+
+ Gueltige Skill-Attribute sind momentan:
+ * SA_QUALITY: Allgemeine Qualitaet: wirkt sich auf alle anderen
+ Attribute auch aus (multplikativ auf Basis 100)
+ * SA_DAMAGE: Schaden, den das Lebewesen macht
+ * SA_SPEED: Geschwindigkeit des Lebewesens (zB Angriffe/Runde)
+ * SA_DURATION: Spell-/Skilldauer
+ * SA_ENEMY_SAVE: identisch zu SA_SPELL_PENETRATION (OBSOLET!)
+ * SA_SPELL_PENETRATION: Chance des _Casters_, einen Spell durch ein
+ P_NOMAGIC durchzukriegen.
+ * SA_RANGE: Reichweite des Lebewesens (eher unbenutzt)
+ * SA_EXTENSION: "Ausdehnung" bei Gruppen-/Flaechenspells: FindGroupN/P
+
+RUECKGABEWERT
+-------------
+::
+
+ SA_MOD_OK wenn der Modifikator gesetzt wurde
+ SA_TOO_MANY_MODS wenn die max. Anzahl an Mods schon erreicht ist.
+ SA_MOD_TOO_SMALL wenn der Modifikator zu klein ist
+ SA_MOD_TOO_BIG wenn der Modifikator zu gross ist
+ SA_MOD_INVALID_ATTR wenn das gewuenschte SA gar nicht existiert
+ SA_MOD_INVALID_OBJECT wenn das setzende Objekt ungueltig ist
+ SA_MOD_INVALID_VALUE wenn der Modifikator ungueltig ist
+ Wenn man nur wissen will, ob die Operation erfolgreich war, empfiehlt
+ es sich, auf == SA_MOD_OK zu pruefen.
+
+BEMERKUNGEN
+-----------
+::
+
+ Nachdem ein Objekt, welches Modifikatoren setzte, zerstoert wurde,
+ werden die Modifikatoren spaetestens ungueltig, sobald in dem
+ manipulierten Lebewesen erneut ModifySkillAttribute() gerufen wird!
+ Bei Closures ist der Mod sofort weg.
+
+BEISPIELE
+---------
+::
+
+ // sei PL ein Spieler, den mein NPC schwaechen will:
+ PL->ModifySkillAttribute(SA_QUALITY, -75, 13);
+ // Fuer 13s wird SA_QUALITY um 75 reduziert. Dies wirkt sich auf alle
+ // anderen SAs aus! (s. drittes Beispiel)
+
+ // sei PL ein Lebewesen, welchem ich fuer 11s 2 Schlaege pro Kampfrunde
+ // zusaetzlich geben moechte:
+ PL->ModifySkillAttribute(SA_SPEED, 200, 11);
+ // wenn keine weiteres Modifikatoren wirken, hat PL jetzt 3 Schlaege
+ // pro Kampfrunde (Basiswert 100 + 200 == 300 => 3).
+
+ Angenommen, ein Lebewesen hat einen Basiswert von 130 auf SA_SPEED und
+ 100 auf SA_QUALITY (P_SKILL_ATTRIBUTE_OFFSETS) und nun 3 Modifikatoren
+ gesetzt: SA_SPEED +100, SA_SPEED -30 und SA_QUALITY von -10:
+ Zunaechst wird SA_QUALITY bestimmt: 100 - 10 = 90 => 0.9
+ Anschliessend wird SA_SPEED bestimmt: 130 + 100 - 30 = 200 => 2
+ Nun wird SA_SPEED noch mit SA_QUALITY multipliziert: 2 * 0.9 = 1.8
+ Das Lebewesen hat nun also im Endeffekt 1.8 Schlaege pro Kampfrunde.
+
+
+
+SIEHE AUCH
+----------
+::
+
+ Skills Lernen: LearnSkill, ModifySkill, LimitAbility
+ * Nutzung: UseSpell, UseSkill
+ * Abfragen: QuerySkill
+ * Modifikation: QuerySkillAttribute,
+ QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+ * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+ * sonstig: spruchermuedung, skill_info_liste
+ * Properties: P_NEWSKILLS
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/More.rst b/doc/sphinx/lfun/More.rst
new file mode 100644
index 0000000..c5019dc
--- /dev/null
+++ b/doc/sphinx/lfun/More.rst
@@ -0,0 +1,79 @@
+More()
+======
+
+FUNKTION
+--------
+::
+
+ varargs public void More(string txt, int file,
+ mixed ctrl, mixed *ctrlargs, int flags);
+
+DEFINIERT IN
+------------
+::
+
+ /std/util/pager.c
+
+ARGUMENTE
+---------
+::
+
+ txt - entweder ein Text der ausgegeben werden soll, oder ein filename.
+ file - das flag file gibt an, ob es sich bei <txt> um einen text oder
+ einen Filenamen handelt. Bei einem Filenamen wird der Inhalt
+ dieses Files eingelesen und ausgegeben.
+ ctrl - Eine closure, die aufgerufen wird, falls kein <txt> angegeben
+ wurde.
+ ctrlargs - ctrlargs wird als Parameter an ctrl uebergeben.
+ flags - flags wird mit den im Spieler definierten P_MORE_FLAGS
+ kombiniert.
+
+BESCHREIBUNG
+------------
+::
+
+ More() dient der Ausgabe von Texten an Spieler. Mit Hilfe eines
+ PL->More(txt) oder PL->More(txt, 1) ist es sehr einfach laengere Texte
+ an Spieler auszugeben. Bei der Ausgabe werden die persoenlichen
+ Einstellungen des Spielern (wie z.b. Zeilen pro Bildschirmseite)
+ automatisch beruecksichtigt und der Text dadurch ggf. zerstueckelt
+ und in mehreren Schritten nacheinander angezeigt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Beim einlesen des Files sind die Leserechte des Spieler in dem More()
+ aufgerufen wird von Bedeutung und nicht die Rechte des Objektes das
+ More() aufruft. Spielerobjekte haben im MorgenGrauen jedoch nur sehr
+ eingeschraenkte Leserechte! Ausgegeben werden koennen nur files
+ aus /p/*, /gilden/* und /d/* die _keinen_ code enthalten. Als Code
+ wird hierbei jedes File betrachtet das als vorletztes Zeichen einen .
+ hat (also .c, .h, .o usw.).
+ Will man aus irgendwelchen Gruenden ein File (z.b. aus /players/)
+ ausgeben, so sollte man stattdessen folgendes verwenden:
+ this_player()->More(read_file(filename))
+
+BEISPIELE
+---------
+::
+
+ // Ausgabe eines normalen textes...
+ this_player()->More("Einfach nur mal so ein Test...\n");
+
+ // Ausgabe eines kompletten files
+ this_player()->More("/etc/WIZRULES", 1);
+
+SIEHE AUCH
+----------
+::
+
+----------------------------------------------------------------------------
+Last modified: Mon Feb 22 15:09:18 1999 by Padreic
+
diff --git a/doc/sphinx/lfun/NPC_Killed_by.rst b/doc/sphinx/lfun/NPC_Killed_by.rst
new file mode 100644
index 0000000..eb0ee42
--- /dev/null
+++ b/doc/sphinx/lfun/NPC_Killed_by.rst
@@ -0,0 +1,36 @@
+NPC_Killed_by()
+===============
+
+FUNKTION
+--------
+::
+
+ void NPC_Killed_By(object pl)
+
+
+
+ARGUMENTE
+---------
+::
+
+ Spieler, der einen NPC gekillt hat.
+
+
+
+BESCHREIBUNG
+------------
+::
+
+ Wird in der Gilde des Spielers aufgerufen,
+ wenn dieser einen NPC gekillt hat.
+
+
+
+RUECKGABEWERT
+-------------
+::
+
+ Keiner
+
+
+
diff --git a/doc/sphinx/lfun/NewDoor.rst b/doc/sphinx/lfun/NewDoor.rst
new file mode 100644
index 0000000..22cc177
--- /dev/null
+++ b/doc/sphinx/lfun/NewDoor.rst
@@ -0,0 +1,255 @@
+NewDoor()
+=========
+
+FUNKTION
+--------
+::
+
+ varargs int NewDoor(string|string* cmds, string dest, string|string* ids,
+ mapping|<int|string|string*>* props);
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/doors.c
+
+ARGUMENTE
+---------
+::
+
+ cmds (string|string*)
+ String oder Array von Strings mit den Befehlen, mit denen man
+ durch die Tuer geht (in der Regel Richtungen wie "norden").
+ dest (string)
+ Pfad des Zielraumes, OHNE ".c", sonst wird eine zweiseitige Tuer
+ (wie sie ueblich ist) nicht als solche erkannt.
+ ids (string|string*)
+ String oder Array von Strings mit den Bezeichnern der Tuer. Kann
+ auch 0 sein; in diesem Fall laesst sich die Tuer nur als "tuer"
+ ansprechen.
+ props (mapping|<int|string|string*>*)
+ Die Eigenschaften der Tuer (s.u.).
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird eine neue Tuer geschaffen. Die Tuer laesst sich, wenn sie
+ geoeffnet ist, mit den in <cmds> angegebenen Befehlen durchschreiten.
+ Man gelangt dann in den Raum <dest>.
+
+ Die Kommandos werden bei geoeffneter Tuer in die Liste der sichtbaren
+ Ausgaenge eingefuegt.
+
+ In <props> lassen sich Aussehen und Eigenschaften der Tuer festlegen.
+ Historisch ist es ein Array mit Paaren von Schluesseln und Werten, d.h.
+ es kommt immer erst ein Element, welches die Eigenschaft bezeichnet und
+ dann ein Element mit dem Wert dieser Eigenschaft.
+ Moderner ist es, ein Mapping mit den entsprechenden Schluesseln und
+ Werten zu uebergeben. Dies ist auch dringend empfohlen.
+
+ In <doorroom.h> sind dazu folgende Eigenschaften definiert:
+ D_FLAGS
+ DOOR_OPEN
+ Die Tuer ist beim Erzeugen geoeffnet.
+ DOOR_CLOSED
+ Die Tuer ist beim Erzeugen geschlossen.
+ DOOR_NEEDKEY
+ Man benoetigt einen Schluessel zum Oeffnen der Tuer.
+ DOOR_CLOSEKEY
+ Man benoetigt einen Schluessel zum Schliessen der Tuer.
+ DOOR_RESET_CL
+ Die Tuer schliesst sich beim Reset.
+ DOOR_RESET_OP
+ Die Tuer oeffnet sich beim Reset.
+
+ D_LONG
+ Die Langbeschreibung der Tuer.
+ Hier kann ein Mapping eingetragen werden, das als Keys den Tuer-
+ Status hat und die zugehoerige Langbeschreibung dazu. Beispiel:
+ ([ D_STATUS_CLOSED : "Die Tuer ist geschlossen.\n",
+ D_STATUS_OPEN : "Die Tuer ist offen.\n" ])
+
+
+
+ Default: "Eine Tuer.\n"
+
+ D_SHORT
+ Die Kurzbeschreibung der Tuer. Ein "%s" wird durch "geoeffnet"
+ bzw. "geschlossen" ersetzt.
+
+ Es werden die Kurzbeschreibungen aller im Raum vorhandenen Tueren
+ aneinandergehaengt (es wird jeweils ein Leerzeichen eingeschoben),
+ das Ganze mit break_string() umgebrochen und an P_INT_LONG
+ angehaengt.
+
+ Default: "Eine %se Tuer."
+
+ D_NAME
+ Der Name der Tuer. Dieser Name wird beim Oeffnen und Schliessen
+ der Tuer sowie bei Fehlermeldungen ausgegeben. Man kann wie bei
+ P_NAME einen String oder ein Array von Strings angeben.
+
+ Default: "Tuer"
+
+ D_GENDER
+ Das Geschlecht der Tuer.
+
+ Default: FEMALE
+
+ D_MSGS
+ String oder Array von drei Strings. Diese Strings werden beim
+ Durchschreiten der Tuer an move() als dir bzw. dir, textout und
+ textin uebergeben.
+
+ D_FUNC
+ String mit dem Namen einer Funktion, die im Startraum vor dem
+ Durchschreiten der Tuer aufgerufen werden soll. Diese Funktion
+ kann das Durchschreiten jedoch nicht verhindern!
+
+ D_FUNC2
+ String mit dem Namen einer Funktion, die im Zielraum nach dem
+ Durchschreiten der Tuer aufgerufen werden soll.
+
+ D_TESTFUNC
+ Falls auf den Namen einer Funktion gesetzt, wird diese Funktion
+ vor dem Durchschreiten im Startraum aufgerufen. Wenn sie einen
+ Wert != 0 zurueckliefert, wird die Tuer NICHT durchschritten.
+
+ D_RESET_MSG
+ Meldung, die beim Reset der Tuer ausgegeben wird.
+
+ D_OPEN_WITH_MOVE
+ Tuer oeffnet automatisch bei Eingabe des Befehls zum
+ Hindurchgehen.
+
+
+
+RUECKGABEWERT
+-------------
+::
+
+ 1, wenn die Tuer ordungsgemaess eingebaut werden konnte, sonst 0.
+
+BEMERKUNGEN
+-----------
+::
+
+ Zwei Tuerseiten gelten als verschiedene Seiten einer Tuer, wenn als
+ Ziel in Raum A Raum B und in Raum B Raum A angegeben ist. Der Zustand
+ wird abgefragt, wenn der Raum betreten wird (init), wenn die Tuer
+ geoeffnet/geschlossen wird, P_INT_LONG oder P_EXITS abgefragt wird
+ und beim Reset.
+
+ Es sind auch Tueren moeglich, die nur auf einer Seite existieren, oder
+ auch solche, die auf beiden Seiten verschieden aussehen oder gar auf
+ einer Seite nur mit einem Schluessel zu oeffnen sind, auf der anderen
+ jedoch kein Schluessel noetig ist.
+
+ Wer aus irgendeinem Grund den Zustand einer Tuer selber abfragen oder
+ veraendern will, kann dafuer in /obj/doormaster die Funktionen
+ QueryDoorStatus(ziel) bzw. SetDoorStatus(ziel,status) aufrufen.
+
+ *** ACHTUNG ***
+ Es gibt eine Questbelohnung (Phiole aus der Sternenlicht-Quest von
+ Miril), mit der man durch Tueren hindurchschauen kann. Derzeit ist das
+ per default fuer alle Tueren erlaubt. Wenn man das nicht moechte,
+ oder andere Texte ausgeben, als die Phiole normalerweise erzeugt,
+ dann kann man dies durch Nutzung bestimmter Funktionen bzw. Flags
+ erreichen. Zur Dokumentation siehe Manpage zu GetPhiolenInfos().
+
+BEISPIELE
+---------
+::
+
+ ** Dies ist eine gewoehnliche Tuer ohne Besonderheiten und ohne
+ Extra-Beschreibung:
+
+ NewDoor("sueden","/players/rochus/room/test1");
+
+ ** Ein Portal:
+
+ NewDoor("norden","/players/rochus/room/test2",
+ "portal",
+ ([ D_NAME: "Portal",
+ D_GENDER: NEUTER,
+ D_SHORT: "Im Norden siehst Du ein %ses Portal.",
+ D_LONG: "Das Portal ist einfach nur gigantisch.\n",
+ ]) );
+
+ Alternativ mit props in alter Arraynotation:
+ NewDoor("norden","/players/rochus/room/test2",
+ "portal",
+ ({ D_NAME, "Portal",
+ D_GENDER, NEUTER,
+ D_SHORT, "Im Norden siehst Du ein %ses Portal.",
+ D_LONG, "Das Portal ist einfach nur gigantisch.\n"
+ }) );
+
+
+
+ ** Tueren mit Bewegungsmeldung:
+
+ NewDoor("norden","/room/see2",
+ ({ D_MSGS, ({"nach Norden","schwimmt",
+ "kommt hereingeschwommen"}) }) );
+
+ ** Eine Tuer mit Testfunktion:
+
+ NewDoor("osten","/mein/zielraum",
+ ({ D_TESTFUNC, "blocker_da" }) );
+
+ Die Funktion blocker_da:
+
+ int blocker_da() // KEINE protected-Funktion! Sie wird sonst NICHT
+ { // aufgerufen und ausgewertet!
+ if ( present("mein_fieses_mo\nster",this_object()) )
+ {
+ write("Ein fieses Monster stellt sich Dir in den Weg.\n");
+ return 1;
+ }
+ return 0; // optional
+ }
+
+ ** Nun noch eine Tuer mit einigen Extras:
+
+ NewDoor("nordwesten","/rooms/kammer",
+ ({"tuer","holztuer"}),
+ ({
+ D_FLAGS, (DOOR_CLOSED|DOOR_RESET_CL),
+ D_MSGS, ({"nach Nordwesten","geht",
+ "kommt durch eine Tuer herein"}),
+ D_SHORT, "Im Nordwesten siehst Du eine %se Holztuer.",
+ D_LONG, "Sie trennt den Laden vom dahinterliegenden Raum.\n",
+ D_NAME, "Holztuer",
+ D_FUNC, "view",
+ D_FUNC2, "look_up"
+ }) );
+
+ Im Startraum:
+
+ void view()
+ {
+ write("Der Angestellte wirft Dir einen missbilligenden Blick zu, "
+ "laesst Dich aber passieren.\n");
+ }
+
+ Im Zielraum:
+
+ void look_up()
+ {
+ write("Ein alter Mann schaut kurz zu Dir auf und vertieft sich dann "
+ "wieder in seine Akten.\n");
+ }
+
+SIEHE AUCH
+----------
+::
+
+ QueryDoorKey(), QueryDoorStatus(), SetDoorStatus(),
+ /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+
+
+08.02.2015, Arathorn
+
diff --git a/doc/sphinx/lfun/NoParaObjects.rst b/doc/sphinx/lfun/NoParaObjects.rst
new file mode 100644
index 0000000..3b5a1ba
--- /dev/null
+++ b/doc/sphinx/lfun/NoParaObjects.rst
@@ -0,0 +1,47 @@
+NoParaObjects()
+===============
+
+********************** VERALTETE LFUN ****************************
+NoParaObjects()
+
+FUNKTION
+--------
+::
+
+ int NoParaObjects()
+
+DEFINIERT IN
+------------
+::
+
+ /std/virtual/v_compiler.c
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn der VC keine Parawelt-Objekte erzeugt,
+ 0, wenn er es doch tut.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion ist veraltet. QueryValidObject() ist genereller und
+ einfacher zu handhaben. Bitte in Zukunft P_PARA im VC setzen, siehe hierzu
+ die Manpage von QueryValidObject().
+
+ Die Funktion gibt an, ob ein Virtual Compiler auch Parawelt-Objekte
+ erzeugen kann.
+ Wichtig: Entweder dieser Funktion im VC definieren, wenn der VC keine
+ Para-Objekte erzeugen wird oder P_PARA passend setzen!
+
+SIEHE AUCH
+----------
+::
+
+ virtual_compiler, P_PARA, QueryValidObject
+
+
+04.03.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/NotifyDestruct.rst b/doc/sphinx/lfun/NotifyDestruct.rst
new file mode 100644
index 0000000..851c3c8
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyDestruct.rst
@@ -0,0 +1,67 @@
+NotifyDestruct()
+================
+
+FUNKTION
+--------
+::
+
+ public int|string NotifyRemove(object zerstoerer);
+
+ARGUMENTE
+---------
+::
+
+ zerstoerer
+ Das Objekt, welches destruct() auf dieses Objekt anwendet.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird vom Master der Mudlib in jedem Objekt gerufen,
+ welches zerstoert wird, um Objekten eine letzte Chance zu geben, sich
+ aufzuraeumen.
+ Wenn ihr diese Funktion selber definiert, achtet bittet darauf, dass sie
+ in keinem Fall Fehler ausloesen sollte, d.h. testet entsprechend
+ gruendlich.
+ Wenn ihr aus /std/ erbt und diese Funktion ueberschreibt,, _muesst_ ihr
+ die geerbte NotifyDestruct() aufrufen, da sonst das Lichtsystem nicht
+ aktualisiert wird.
+
+ Privilegierte Objekte (z.B. Root-Objekte, spezielle Ausnahmen wie der
+ Netztotenraum, Armageddon) koennen die Zerstoerung in letzter Sekunde
+ verhindern, indem sie hier einen Wert != 0 zurueckliefern. Wird ein
+ string zurueckgeliefert, wird dieser die Fehlermeldung des
+ prepare_destruct() im Master sein.
+ Bei nicht-privilegierten Objekten (also fast alle) ist an dieser Stelle
+ _kein_ Abbruch der Zerstoerung moeglich!
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der Rueckgabewert muss ein string oder ein int sein. Allerdings wird der
+ Master den Rueckgabewert nur fuer privilegierte Objekte auswerten.
+
+BEMERKUNGEN
+-----------
+::
+
+ Wie gesagt, bitte keine Fehler ausloesen (auch wenn der Master
+ grundsaetzlich damit klar kommt). Speziell ist ein raise_error() zur
+ Verhinderung eines destructs nutzlos.
+ Bitte macht in dieser Funkion nur das, was _unbedingt_ notwendig ist.
+ Wenn jemand ein destruct() anwendet statt ein remove() zu rufen, hat das
+ in der Regel einen Grund (z.B. um buggende remove() zu umgehen). Insb.
+ ist ein save_object() in remove() und NotifyDestruct() vollstaendig
+ ueberfluessig.
+
+SIEHE AUCH
+----------
+::
+
+ NotifyLeave(), NotifyInsert(), NotifyRemove()
+
+
+Last modified: 25.02.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/NotifyInsert.rst b/doc/sphinx/lfun/NotifyInsert.rst
new file mode 100644
index 0000000..ee01336
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyInsert.rst
@@ -0,0 +1,48 @@
+NotifyInsert()
+==============
+
+FUNKTION
+--------
+::
+
+ void NotifyInsert(object ob, object oldenv);
+
+ARGUMENTE
+---------
+::
+
+ ob
+ Das Objekt, das in den Behaelter eingefuegt wurde.
+ oldenv
+ Das Objekt, aus dem <ob> kam.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird im Behaelter aufgerufen, nachdem ein Objekt in
+ besagten Behaelter hinein bewegt wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Diese Funktion wird nur im Falle unbelebter Objekte gerufen. Fuer
+ Lebewesen s. bitte. init().
+
+SIEHE AUCH
+----------
+::
+
+ NotifyLeave(), PreventInsert(), PreventLeave(), move(), NotifyRemove()
+ exit(), init(), NotifyMove(), PreventMove()
+
+
+Last modified: 21.05.2012, Zesstra
+
diff --git a/doc/sphinx/lfun/NotifyLeave.rst b/doc/sphinx/lfun/NotifyLeave.rst
new file mode 100644
index 0000000..47c63bf
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyLeave.rst
@@ -0,0 +1,48 @@
+NotifyLeave()
+=============
+
+FUNKTION
+--------
+::
+
+ void NotifyLeave(object ob, object dest);
+
+ARGUMENTE
+---------
+::
+
+ ob
+ Das Objekt, das aus dem Behaelter entfernt wurde.
+ dest
+ Das Objekt, in das <ob> bewegt wurde.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird im Behaelter aufgerufen, nachdem ein Objekt aus
+ besagten Behaelter entfernt wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Diese Funktion wird nur im Falle unbelebter Objekte gerufen. Fuer
+ Lebewesen s. bitte. exit().
+
+SIEHE AUCH
+----------
+::
+
+ NotifyRemove(), NotifyInsert(), PreventInsert(), PreventLeave(), move(),
+ exit(), init(), NotifyMove(), PreventMove()
+
+
+Last modified: 21.05.2012, Zesstra
+
diff --git a/doc/sphinx/lfun/NotifyMove.rst b/doc/sphinx/lfun/NotifyMove.rst
new file mode 100644
index 0000000..c4cef69
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyMove.rst
@@ -0,0 +1,84 @@
+NotifyMove()
+============
+
+FUNKTION
+--------
+::
+
+ protected void NotifyMove(object dest, object oldenv, int method);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/moving.c
+ /std/living/moving.c
+ /std/player/moving.c
+
+ARGUMENTE
+---------
+::
+
+ dest
+ Das Ziel des Moves bzw. das jetzt aktuelle Environment
+ oldenv
+ Das alte Environment des Objekts
+ method
+ Die Move-Methode(n), mit der/denen bewegt wurde.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird vom move() im Objekt gerufen, sobald die Bewegung im
+ wesentlichen abgeschlossen ist. Sie soll einerseits das Objekt ueber eine
+ stattgefundene Bewegung informieren, aber auch einige Dinge erledigen,
+ die bei der Bewegung stattfinden muessen (bei Livings z.B. das Team
+ nachholen).
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Diese Funktion kann ueberschrieben werden, damit das Objekt Bewegungen
+ mitgekommt, ohne das move() selber zu ueberschreiben oder einen Move-Hook
+ zu setzen. Dabei aber bitte unbedingt beachten:
+ Das geerbte NotifyMove() _MUSS IN JEDEM FALL_ mit aufgerufen werden!
+ Solltet ihr das vergessen, werden eure Objekte buggen. ;-)
+ Die Funktion darf nur objektintern verwendet werden. Beim Ueberschreiben
+ das 'protected' nicht vergessen!
+
+BEISPIELE
+---------
+::
+
+ Eine Bombe, die in Seherhaustruhen explodiert:
+
+ protected void NotifyMove(object dest, object oldenv, int method) {
+ ::NotifyMove(dest, oldenv, method); // WICHTIG!
+ if (objectp(dest) &&
+ load_name(dest) == "/d/seher/haeuser/truhe") {
+ if (find_call_out("explodiere")==-1)
+ call_out("explodiere",900);
+ }
+ else
+ remove_call_out("explodiere");
+ }
+
+SIEHE AUCH
+----------
+::
+
+ PreventLeave(), NotifyInsert(), NotifyLeave(), MayAddObject(),
+ PreventInsertLiving(), PreventLeaveLiving(), NotifyMove(),
+ PreventMove(), MayAddWeight(), move(), /std/container/restrictions.c
+
+
+Last modified: 04.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/NotifyPlayerDeath.rst b/doc/sphinx/lfun/NotifyPlayerDeath.rst
new file mode 100644
index 0000000..7fe7cfa
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyPlayerDeath.rst
@@ -0,0 +1,99 @@
+NotifyPlayerDeath()
+===================
+
+FUNKTION
+--------
+::
+
+ void NotifyPlayerDeath(object victim,object killer,int lost_exp);
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/life.c
+
+ARGUMENTE
+---------
+::
+
+ victim
+ Getoeteter Spieler.
+ killer
+ Objekt, welches den Spieler getoetet hat.
+ lost_exp
+ Erfahrungspunkte, die der Spieler durch den Tod verloren hat.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird aus dem Spielerobjekt heraus immer dann
+ aufgerufen, wenn der Spieler stirbt und zwar:
+ 1) im Gegner, der den Spieler getoetet hat,
+ 2) im Environment des getoeteten Spielers,
+ 3) in der Gilde des Spielers,
+ 4) in allen Objekten in diesem Environment und
+ 5) in allen Objekten (auch innerhalb Containern) im Spieler.
+ Der Gegner wird hierbei nur einmal informiert, also bei letzteren
+ Faellen herausgefiltert, falls noetig!
+ Hauptaufgabe dieser Funktion ist es somit, auf Tode von Spielern zu
+ reagieren oder selbige einfach nur mitzuloggen.
+
+ Zu dem Zeitpunkt des Aufrufs dieser Funktion ist der Spieler noch _nicht_
+ Geist und noch _nicht_ im Todesraum - dies wird im Anschluss an den Aufruf
+ der NotifyPlayerDeath() durchgefuehrt.
+
+
+
+ Aufgerufen wird die Funktion aus '/std/player/life.c' mittels catch() und
+ werden mit limited() auf max. 150k (Gegner, Environment, Gilde) bzw. 80k
+ (alle anderen Objekte) Ticks beschraenkt.
+ Fehler in dieser Funktion haben somit keine negativen Auswirkungen
+ auf das Sterben des Spielers.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEISPIELE
+---------
+::
+
+ Folgendes Beispiel demonstriert beispielsweise, wie man Tode von
+ Spielern mitloggen kann (das Beispiel ist hierbei auf den am
+ haeufigsten auftretenden Fall bezogen, dass nur das toetende Objekt
+ den Tod protokollieren soll):
+
+ void NotifyPlayerDeath(object dead, object killer, int lost_exp)
+ {
+ if ( intp(lost_exp) && objectp(dead) && objectp(killer) &&
+ killer==this_object() )
+ write_file( "/log/patryn/dead", sprintf(
+ "%s - %s von %s getoetet. XP: -%d", ctime(), getuid(dead),
+ killer->name(WEM), lost_exp) );
+ }
+
+ Bitte beachten: write_file() schreibt ohne Groessenbegrenzung in das
+ Logfile. Da dies auf Dauer bzw. in Gebieten mit hoher Log-Aktivitaet
+ zu Logfiles von enormer Groesse fuehren kann, ist die Verwendung
+ von write_file() nicht empfehlenswert. Ausnahmen koennen natuerlich
+ mit dem zustaendigen Regionsmagier abgesprochen werden, z.B. fuer
+ begrenzte Anwendung etwa bei sehr starken, selten besiegten Gegnern.
+
+ Weiterhin ist es empfehlenswert, das toetende Objekt (killer) nicht
+ im NotifyPlayerDeath() zu zestoeren, sondern etwas zeitversetzt,
+ damit nicht etwa im nachfolgenden NotifyPlayerDeath() eines anderen
+ Objektes (s.o. Reihenfolge) killer==0 ist.
+
+SIEHE AUCH
+----------
+::
+
+ Defend(), do_damage(), NotifyHpChange(), catch(), write_file(), log_file()
+ P_LAST_DEATH_PROPS
+
+24.03.2012, Zesstra
+
diff --git a/doc/sphinx/lfun/NotifyRemove.rst b/doc/sphinx/lfun/NotifyRemove.rst
new file mode 100644
index 0000000..1c11263
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyRemove.rst
@@ -0,0 +1,46 @@
+NotifyRemove()
+==============
+
+FUNKTION
+--------
+::
+
+ void NotifyRemove(object ob);
+
+ARGUMENTE
+---------
+::
+
+ ob
+ Das Objekt, das aus dem Behaelter entfernt wurde.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird im Behaelter aufgerufen, wenn ein Objekt im
+ besagten Behaelter zerstoert wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Wird nicht gerufen, wenn ein Spielerobjekt zerstoert wird.
+
+SIEHE AUCH
+----------
+::
+
+ NotifyLeave(), NotifyInsert(), PreventInsert(), PreventLeave(), move(),
+ NotifyMove(), PreventMove(),
+ BecomesNetDead()
+
+
+Last modified: 04.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/NotifyTimedAttrModExpired.rst b/doc/sphinx/lfun/NotifyTimedAttrModExpired.rst
new file mode 100644
index 0000000..5a63fbd
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyTimedAttrModExpired.rst
@@ -0,0 +1,38 @@
+NotifyTimedAttrModExpired()
+===========================
+
+FUNKTION
+--------
+::
+
+ void NotifyTimedAttrModExpired(string key)
+
+DEFINIERT IN
+------------
+::
+
+ Push-Methode in notify-Objekten.
+
+ARGUMENTE
+---------
+::
+
+ string key - der geloeschte Modifier
+
+BESCHREIBUNG
+------------
+::
+
+ Wird aus dem Lebewesen aus aufgerufen, in dem der entsprechenden
+ Modifier soeben ungueltig geworden ist.
+
+SIEHE AUCH
+----------
+::
+
+ Properties: P_ATTRIBUTES, P_TIMED_ATTR_MOD
+ Methoden: SetTimedAttrModifier(L), DeleteTimedAttrModifier(L),
+ QueryTimedAttrModifier(L)
+
+27. Juli 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/NotifyXMAttrModLimitViolation.rst b/doc/sphinx/lfun/NotifyXMAttrModLimitViolation.rst
new file mode 100644
index 0000000..bd25aa3
--- /dev/null
+++ b/doc/sphinx/lfun/NotifyXMAttrModLimitViolation.rst
@@ -0,0 +1,37 @@
+NotifyXMAttrModLimitViolation()
+===============================
+
+FUNKTION
+--------
+::
+
+ void NotifyXMAttrModLimitViolation()
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/restrictions.c
+
+BESCHREIBUNG
+------------
+::
+
+ Wird gerufen wenn die Summe der in P_X_ATTR_MOD oder P_X_ATTR_MOD
+ angegebenen Modifikatoren die Summe aller Modifikatoren im Spieler
+ ueber den zugelassenen Grenzwert hebt und somit nicht mehr in die
+ Berechnung eingeht.
+
+
+
+SIEHE AUCH
+----------
+::
+
+ QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+ SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+ P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
+ P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+13.Jun.2004, Muadib
+
diff --git a/doc/sphinx/lfun/Pacify.rst b/doc/sphinx/lfun/Pacify.rst
new file mode 100644
index 0000000..8a68c42
--- /dev/null
+++ b/doc/sphinx/lfun/Pacify.rst
@@ -0,0 +1,148 @@
+Pacify()
+========
+
+FUNKTION
+--------
+::
+
+ public int Pacify(object caster)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion versucht, ein Lebewesen zu befrieden.
+ Will eine Gilde ein Lebewesen befrieden, muss sie hierfuer diese Funktion
+ in dem Lebewesen aufrufen.
+
+ Ein immer befriedbarer NPC kann durch das Setzen von P_ACCEPT_PEACE in einem
+ Lebewesen realisiert werden.
+
+ Standardmaessig funktioniert die Funktion wie folgt:
+ * Kommt der Versuch vom Spellcaster selbst, ist er immer erfolgreich.
+ * Kommt der Versuch von einem Teamkollegen, ist er immer erfolgreich.
+ * Hat das Lebewesen keine Gegner, ist der Versuch immer erfolglos.
+ In diesen Faellen erfolgt auch keine Erhoehung des Befriedezaehlers.
+
+
+
+ In anderen Faellen wird die in P_PEACE_HISTORY fuer die Gilde des Casters
+ abgelegte Zahl erfolgreicher Befriedungen (ANZ), die Intelligenz des
+ Casters (INT_CASTER) und die Intelligenz des Lebenwesens selber (INT_ME)
+ ermittelt.
+ Anschliessend wird eine Wahrscheinlichkeit w ausgerechnet:
+
+
+
+ w = (INT_CASTER + 10 - ANZ*4) / (INT_ME + 10)
+
+
+
+ Hierbei gibt w die Chance auf eine erfolgreiche Befriedung an. Mittels einer
+ Zufallszahl wird bestimmt, ob der aktuelle Versuch erfolgreich ist. Falls
+ ja, wird der Zaehler fuer die Gilde des Casters in P_PEACE_HISTORY erhoeht.
+
+ Je oefter ein Lebewesen als von einer Gilde schon befriedet wurde, desto
+ unwahrscheinlicher, dass es erneut darauf 'hereinfaellt'.
+
+BEMERKUNGEN
+-----------
+::
+
+ * Die Funktion kann auch ueberschrieben werden, um ein vom Magier
+ gewuenschtes Verhalten zu realisieren. Ein komplettes Abhaengen von
+ Befriedungen sollte dabei aber die Ausnahme sein!
+ * Diese Funktion verwaltet auch das P_PEACE_HISTORY, speziell die Reduktion
+ der Erfolgszaehler. Ueberschreibt man sie ohne das geerbte Pacify()
+ zu nutzen, wird P_PEACE_HISTORY nicht mehr verwaltet.
+
+RUECKGABEWERTE
+--------------
+::
+
+ 1 - das Lebewesen wurde erfolgreich befriedet..
+ 0 - der Befriedeversuch ist gescheitert.
+
+
+
+BEISPIELE
+---------
+::
+
+ Angenommen, der Caster hat eine Intelligenz von 22. Die folgende Tabelle
+ gibt dann die Wahrscheinlichkeiten fuer eine erfolgreiche Befriedung an:
+ (in Abhaengigkeit von eigener Intelligenz und vergangener erfolgreicher
+ Versuche)
+ INT_ME Erfolgswahrscheinlichkeiten je nach Anzahl erfolgreicher Versuche
+ 1 2 3 4 5 6 7 8
+ 0 280 240 200 160 120 80 40 0
+ 2 233,33 200 166,67 133,33 100 66,67 33,33 0
+ 4 200 171,43 142,86 114,29 85,71 57,14 28,57 0
+ 6 175 150 125 100 75 50 25 0
+ 8 155,56 133,33 111,11 88,89 66,67 44,44 22,22 0
+ 10 140 120 100 80 60 40 20 0
+ 12 127,27 109,09 90,91 72,73 54,55 36,36 18,18 0
+ 14 116,67 100 83,33 66,67 50 33,33 16,67 0
+ 16 107,69 92,31 76,92 61,54 46,15 30,77 15,38 0
+ 18 100 85,71 71,43 57,14 42,86 28,57 14,29 0
+ 20 93,33 80 66,67 53,33 40 26,67 13,33 0
+ 22 87,5 75 62,5 50 37,5 25 12,5 0
+ 24 82,35 70,59 58,82 47,06 35,29 23,53 11,76 0
+ 26 77,78 66,67 55,56 44,44 33,33 22,22 11,11 0
+ 28 73,68 63,16 52,63 42,11 31,58 21,05 10,53 0
+ 30 70 60 50 40 30 20 10 0
+ 32 66,67 57,14 47,62 38,1 28,57 19,05 9,52 0
+ 34 63,64 54,55 45,45 36,36 27,27 18,18 9,09 0
+ 35 62,22 53,33 44,44 35,56 26,67 17,78 8,89 0
+ 36 60,87 52,17 43,48 34,78 26,09 17,39 8,7 0
+ 38 58,33 50 41,67 33,33 25 16,67 8,33 0
+ 40 56 48 40 32 24 16 8 0
+ 42 53,85 46,15 38,46 30,77 23,08 15,38 7,69 0
+ 44 51,85 44,44 37,04 29,63 22,22 14,81 7,41 0
+ 46 50 42,86 35,71 28,57 21,43 14,29 7,14 0
+ 48 48,28 41,38 34,48 27,59 20,69 13,79 6,9 0
+ 50 46,67 40 33,33 26,67 20 13,33 6,67 0
+ 52 45,16 38,71 32,26 25,81 19,35 12,9 6,45 0
+ 54 43,75 37,5 31,25 25 18,75 12,5 6,25 0
+ 56 42,42 36,36 30,3 24,24 18,18 12,12 6,06 0
+ 58 41,18 35,29 29,41 23,53 17,65 11,76 5,88 0
+ 60 40 34,29 28,57 22,86 17,14 11,43 5,71 0
+ 62 38,89 33,33 27,78 22,22 16,67 11,11 5,56 0
+ 64 37,84 32,43 27,03 21,62 16,22 10,81 5,41 0
+ 66 36,84 31,58 26,32 21,05 15,79 10,53 5,26 0
+ 68 35,9 30,77 25,64 20,51 15,38 10,26 5,13 0
+ 70 35 30 25 20 15 10 5 0
+ 72 34,15 29,27 24,39 19,51 14,63 9,76 4,88 0
+ 74 33,33 28,57 23,81 19,05 14,29 9,52 4,76 0
+ 76 32,56 27,91 23,26 18,6 13,95 9,3 4,65 0
+ 78 31,82 27,27 22,73 18,18 13,64 9,09 4,55 0
+ 80 31,11 26,67 22,22 17,78 13,33 8,89 4,44 0
+ 82 30,43 26,09 21,74 17,39 13,04 8,7 4,35 0
+ 84 29,79 25,53 21,28 17,02 12,77 8,51 4,26 0
+ 86 29,17 25 20,83 16,67 12,5 8,33 4,17 0
+ 88 28,57 24,49 20,41 16,33 12,24 8,16 4,08 0
+ 90 28 24 20 16 12 8 4 0
+ 92 27,45 23,53 19,61 15,69 11,76 7,84 3,92 0
+ 94 26,92 23,08 19,23 15,38 11,54 7,69 3,85 0
+ 96 26,42 22,64 18,87 15,09 11,32 7,55 3,77 0
+ 98 25,93 22,22 18,52 14,81 11,11 7,41 3,7 0
+ 100 25,45 21,82 18,18 14,55 10,91 7,27 3,64 0
+
+SIEHE AUCH
+----------
+::
+
+ P_ACCEPT_PEACE, P_PEACE_HISTORY
+
+LETZTE AENDERUNG
+----------------
+::
+
+07.06.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/PayIn.rst b/doc/sphinx/lfun/PayIn.rst
new file mode 100644
index 0000000..5345462
--- /dev/null
+++ b/doc/sphinx/lfun/PayIn.rst
@@ -0,0 +1,73 @@
+PayIn()
+=======
+
+FUNKTION
+--------
+::
+
+ varargs void PayIn(int amount, int percent);
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/zentralbank.c
+
+ARGUMENTE
+---------
+::
+
+ int amount - einzuzahlender Betrag
+ int percent - Bewertungsprozentsatz
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird Brutto amount Geld in die Bank eingezahlt. Der Prozentsatz legt
+ fest, wieviel tatsaechlich gutgeschrieben wird:
+ Gutschrift = amount*percent/100
+
+ Wird percent nicht angegeben, dann wird der derzeitige Bankbewertungs-
+ massstab fuer Geld angenommen.
+
+BEISPIELE
+---------
+::
+
+ #include <bank.h>
+ ...
+ AddCmd("spende",#'action_spende,
+ "Was willst du spenden?");
+ ...
+ int action_spende(string str, extra *o) {
+ int i;
+ if(sscanf("%d muenze",i)==1 && i>0)
+ if(this_player()->QueryMoney(i) && this_player()->AddMoney(-i)) {
+ write("Du spendest "+i+" Muenzen.\n");
+ say(this_player()->Name(WER)+" spendet "+i+" Muenzen.\n");
+ ZENTRALBANK->PayIn(i);
+
+
+
+ } else
+ write("Soviel hast du nicht dabei!\n");
+ ...
+
+BEMERKUNGEN
+-----------
+::
+
+ Unsere Zentralbank ist korrupt, vor allem dadurch, dass in Laeden und
+ an anderen Stellen Geld erzeugt wird.
+
+SIEHE AUCH
+----------
+::
+
+ Geldhandling: AddMoney(L), QueryMoney(L)
+ Zentralbank: WithDraw(L), _query_current_money(L)
+ Sonstiges: /items/money.c, /sys/bank.h
+
+27. Apr 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/PlayerQuit.rst b/doc/sphinx/lfun/PlayerQuit.rst
new file mode 100644
index 0000000..dcc6049
--- /dev/null
+++ b/doc/sphinx/lfun/PlayerQuit.rst
@@ -0,0 +1,39 @@
+PlayerQuit()
+============
+
+FUNKTION
+--------
+::
+
+ void PlayerQuit(object pl);
+
+GERUFEN VON
+-----------
+::
+
+ /std/player/base.c
+
+ARGUMENTE
+---------
+::
+
+ object pl
+ Spieler, der Verbindung beendet
+
+BESCHREIBUNG
+------------
+::
+
+ Wird im environment() gerufen, wenn der Spieler das MUD mit "ende"
+ verlaesst.
+
+SIEHE AUCH
+----------
+::
+
+ BecomesNetAlive(), BecomesNetDead()
+
+
+
+24. Aug 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/PresentEnemies.rst b/doc/sphinx/lfun/PresentEnemies.rst
new file mode 100644
index 0000000..a774a12
--- /dev/null
+++ b/doc/sphinx/lfun/PresentEnemies.rst
@@ -0,0 +1,96 @@
+PresentEnemies()
+================
+
+FUNKTION
+--------
+::
+
+ object *PresentEnemies();
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+RUeCKGABEWERT
+-------------
+::
+
+ anwesende Feinde
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert genau die Feinde zurueck, die sich derzeit im
+ selben Raum befinden. Die Feinde unterliegen hierbei noch gewissen
+ Einschraenkungen:
+ (1) Sie duerfen als NPC nicht gestorben sein, das heisst, sie
+ muessen als Objekt noch existieren.
+ (2) Sie duerfen als Spieler nicht gestorben sein, das heisst, sie
+ duerfen keine Geister sein (Property P_GHOST nicht gesetzt).
+ (3) Sie muessen angreifbar sein, das heisst, die Property
+ P_NO_ATTACK darf nicht gesetzt sein.
+ Wird eine dieser Bedingungen verletzt, so wird der Gegner aus der
+ internen Gegnerliste entfernt. Zusaetzlich gilt:
+ Netztote werden nur als Gegner erkannt, wenn keine anderen Gegner
+ zur Verfuegung stehen.
+
+BEISPIEL
+--------
+::
+
+ Im Folgenden erblinden alle Gegner im Raum:
+ string blindThemAll()
+ { ob*livList;
+ if(!livList=PresentEnemies())
+ return break_string(
+ "Mist...keiner da, der blind werden moechte.",77,
+ Name(WER)+" grummelt: ");
+ for(i=sizeof(livList);i--;)
+ { if(livList[i]->QueryProp(P_BLIND))
+ { tell_object(this_object(),break_string(
+ livList[i]->Name(WER)+" ist schon blind.",77));
+ continue;
+ }
+ tell_object(this_object(),break_string(
+ "Du kratzt "+livList[i]->name(WEM)+" die Augen aus.",77));
+ tell_object(livList[i],break_string(
+ Name(WER)+" kratzt Dir die Augen aus!",77));
+ tell_room(environment(this_object()),break_string(
+ Name(WER)+" kratzt "+livList[i]->name(WEM)
+ +" die Augen aus.",77),({this_object(),livList[i]}));
+ livList[i]->SetProp(P_BLIND,1);
+ }
+ return"";
+ }
+ Aufgerufen wird das ganze am Besten in einem Chat:
+ void create()
+ { ::create();
+ ...
+ SetProp(P_CHAT_CHANCE,10);
+ SetChats(20,({break_string(
+ "Nicht angreifen, sonst wirst Du noch blind!",77,
+ Name(WER)+" bruellt: "),
+ "@@blindThemAll@@"}));
+ }
+ Natuerlich sind auch noch mehr Funktionen und Meldungen als Chats
+ moeglich: Die zwei im Beispiel sind im Normalfall etwas wenig.
+
+SIEHE AUCH
+----------
+::
+
+ SelectEnemy(), QueryEnemies(), IsEnemy(), P_GHOST, P_NO_ATTACK,
+ SetChats, P_CHAT_CHANCE
+
+
+Last modified: Thu May 27 15:01:48 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/PresentEnemyRows.rst b/doc/sphinx/lfun/PresentEnemyRows.rst
new file mode 100644
index 0000000..7bd4ddb
--- /dev/null
+++ b/doc/sphinx/lfun/PresentEnemyRows.rst
@@ -0,0 +1,61 @@
+PresentEnemyRows()
+==================
+
+FUNKTION
+--------
+::
+
+ varargs mixed *PresentEnemyRows(object *here)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ Rueckgabewert von PresentEnemies kann uebergeben werden.
+
+BESCHREIBUNG
+------------
+::
+
+ Ergibt die feindlichen Reihen.
+
+RUECKGABEWERT
+-------------
+::
+
+ Ein Array, bestehend aus MAX_TEAMROWS Arrays mit den Objekten
+ der anwesenden Feinde.
+
+BEMERKUNGEN
+-----------
+::
+
+ Jede Reihe ist Summe der entsprechenden Reihen der
+ anwesenden Teams.
+ Feinde, die in keinem Team sind, stehen im ersten Array.
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
+ SelectNearEnemy, SelectFarEnemy
+ Positionen: PresentPosition, PresentRows, PresentTeamPosition,
+ SwapRows
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/PresentPosition.rst b/doc/sphinx/lfun/PresentPosition.rst
new file mode 100644
index 0000000..1a30f3c
--- /dev/null
+++ b/doc/sphinx/lfun/PresentPosition.rst
@@ -0,0 +1,59 @@
+PresentPosition()
+=================
+
+FUNKTION
+--------
+::
+
+ varargs int PresentPosition(mixed pmap)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ Rueckgabewert von PresentTeamRows() oder PresentTeamPositions()
+ kann uebergeben werden.
+
+BESCHREIBUNG
+------------
+::
+
+ Ergibt die Nummer der Reihe, in der der Spieler gerade steht.
+
+RUECKGABEWERT
+-------------
+::
+
+ Reihennummer im Bereich von 1 bis TEAM_MAXROWS.
+
+BEMERKUNGEN
+-----------
+::
+
+ Ist ein Spieler in keinem Team, so steht er automatisch in Reihe 1.
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
+ SelectNearEnemy, SelectFarEnemy
+ Positionen: PresentRows, PresentEnemyRows, PresentTeamPosition,
+ SwapRows
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/PresentRows.rst b/doc/sphinx/lfun/PresentRows.rst
new file mode 100644
index 0000000..e6d3f5e
--- /dev/null
+++ b/doc/sphinx/lfun/PresentRows.rst
@@ -0,0 +1,111 @@
+PresentRows()
+=============
+
+FUNKTION
+--------
+::
+
+ mixed *PresentRows(object env);
+
+DEFINIERT IN
+------------
+::
+
+ TEAM_OBJECT (s. <living/team.h>)
+
+ARGUMENTE
+---------
+::
+
+ object env
+ Das Environment des gewuenschten Objektes.
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion bekommt man die aktuellen Teamreihen, die im Argument
+ env anwesend sind, des Teams zurueckgegeben. Ist env kein Objekt, so
+ wird environment(this_player()) als solches angenommen.
+
+RUECKGABEWERT
+-------------
+::
+
+ Es wird ein mixed-Array zurueckgegeben, dabei sind die einzelnen Reihen
+ selbst wiederum Arrays mit den Spielerobjekten.
+
+BEISPIEL
+--------
+::
+
+ Ein NPC im Kampf laesst eine Feuerwalze auf ein Team los, welche aber nur
+ Spieler in der ersten und zweiten Teamreihe Schaden zufuegen soll.
+
+ void Attack( object enemy )
+ {
+ ...
+
+ object team = enemy->QueryProp(P_TEAM);
+
+ if ( objectp(team) )
+ {
+ mixed teamrows = team->PresentRows(enemy);
+
+// Inhalt von "teamrows" zu diesem Zeitpunkt:
+
+// ({ ({[/dwarf:hauweg]}),({}),({[/elf:spitzohr]}),({}),({}),({}) })
+
+// In der Umgebung von Zwerg Hauweg steht also noch Elf Spitzohr, und zwar
+// in der dritten Teamreihe (der hat Glueck gehabt).
+// Wenn dem Team noch mehr Spieler angehoeren, befinden sie sich gerade
+// nicht in der Umgebung (sprich im selben Raum) wie Hauweg.
+
+ foreach ( i : 2 )
+ {
+ foreach ( object pl : teamrows[i] )
+ {
+ tell_object(pl,"Der Feuerteufel laesst eine Feuerwalze auf Dich "
+ "und Dein Team los.\n");
+
+ pl->Defend(200+random(200),({DT_FIRE}),([SP_SHOW_DAMAGE:1]),TO);
+ }
+ }
+ }
+ else
+ {
+ tell_object(enemy,"Der Feuerteufel laesst eine Feuerwalze auf Dich "
+ "los.\n");
+
+ enemy->Defend(200+random(200),({DT_FIRE}),([SP_SHOW_DAMAGE:1]),TO);
+ }
+
+ ...
+ }
+
+BEMERKUNG
+---------
+::
+
+ Man beachte, dass das erste Argument (also Argument 0) die erste
+ Teamreihe ist.
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
+ SelectNearEnemy, SelectFarEnemy
+ Positionen: PresentPosition, PresentEnemyRows, PresentTeamPosition,
+ SwapRows
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/PresentTeamPositions.rst b/doc/sphinx/lfun/PresentTeamPositions.rst
new file mode 100644
index 0000000..7a35a90
--- /dev/null
+++ b/doc/sphinx/lfun/PresentTeamPositions.rst
@@ -0,0 +1,61 @@
+PresentTeamPositions()
+======================
+
+FUNKTION
+--------
+::
+
+ varargs mapping PresentTeamPositions(mixed pmap)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ Rueckgabewert von PresentTeamRows() kann uebergeben werden.
+
+BESCHREIBUNG
+------------
+::
+
+ Ermittelt die Reihennummern aller anwesender Teammitglieder.
+
+RUECKGABEWERT
+-------------
+::
+
+ Ein Mapping mit den Reihennummern (von 1 bis MAX_TEAMROWS)
+ der anwesenden Teammitglieder.
+
+BEMERKUNGEN
+-----------
+::
+
+ Kann auch zur Konvertierung anderer Kampfreihen-Arrays in
+ ein Positions-Mapping verwendet werden.
+ Ist der Spieler in keinem Team, so steht er in Reihe 1.
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
+ SelectNearEnemy, SelectFarEnemy
+ Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+ SwapRows
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/PresentTeamRows.rst b/doc/sphinx/lfun/PresentTeamRows.rst
new file mode 100644
index 0000000..3356cb6
--- /dev/null
+++ b/doc/sphinx/lfun/PresentTeamRows.rst
@@ -0,0 +1,47 @@
+PresentTeamRows()
+=================
+
+FUNKTION
+--------
+::
+
+ mixed *PresentTeamRows()
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Ergibt die Reihen mit den anwesenden Teammitgliedern.
+
+RUECKGABEWERT
+-------------
+::
+
+ Ein Array bestehend aus MAX_TEAMROWS Arrays mit den Objekten
+ der anwesenden Teammitglieder.
+
+BEMERKUNGEN
+-----------
+::
+
+ Wenn der Spieler in keinem Team ist, enthaelt das erste Array
+ nur den Spieler und die anderen Arrays sind leer.
+
+SIEHE AUCH
+----------
+::
+
+ teams
+
diff --git a/doc/sphinx/lfun/PreventFollow.rst b/doc/sphinx/lfun/PreventFollow.rst
new file mode 100644
index 0000000..1cca2ff
--- /dev/null
+++ b/doc/sphinx/lfun/PreventFollow.rst
@@ -0,0 +1,72 @@
+PreventFollow()
+===============
+
+FUNKTION
+--------
+::
+
+ int PreventFollow(object dest)
+
+ARGUMENTE
+---------
+::
+
+ dest: Zielobjekt, in das der Verfolgte bewegt werden soll.
+
+FUNKTION
+--------
+::
+
+ In jedem Verfolger, der mit AddPursuer in die Liste der Verfolger
+ eingetragen wurde, wird vor dem Bewegen in das Zielobjekt die Funktion
+ PreventFollow mit dem Zielobjekt als Argument aufgerufen.
+
+RUECKGABEWERT
+-------------
+::
+
+ 0: Verfolger darf in das Zielobjekt folgen
+ 1: Verfolger darf in dieses Zielobjekt nicht folgen
+ (Verfolgung bleibt weiterhin aktiv)
+ 2: Verfolger darf in dieses Zielobjekt nicht folgen
+ (Verfolgung wird abgebrochen und Verfolger aus der Verfolgerliste
+ ausgetragen)
+
+BEMERKUNG
+---------
+::
+
+ Durch PreventFollow kann der raeumliche Bereich, in dem verfolgt werden
+ darf, eingeschraenkt werden.
+
+BEISPIELE
+---------
+::
+
+ Man moechte, dass ein NPC auf einer Insel nicht mit dem Spieler in das
+ Boot steigt, um mit dem Spieler zusammen von der Insel herunterzukommen.
+
+ #define PATH(x) ("/d/.../.../mein/pfad/+(x)")
+
+ ...
+
+ int PreventFollow(object boot)
+ {
+ if ( object_name(boot)[0..strlen(PATH("boot"))-1] == PATH("boot") )
+ return 1;
+ }
+
+ Diese Funktions-Definition ist sehr flexibel, denn sie erlaubt sowohl
+ spaetere Pfadanpassung als auch mehrere Boote.
+ Da ueber die Funktion strlen() nur bis zum letzten Buchstaben des
+ angegebenen Strings getestet wird, wird also gleichzeitig auch auf
+ boot[1], boot[2] usw. getestet.
+
+SIEHE AUCH
+----------
+::
+
+ "AddPursuer", "RemovePursuer"
+
+Last modified: Tue Jun 10 13:59:30 2003 by Gabylon
+
diff --git a/doc/sphinx/lfun/PreventInsert.rst b/doc/sphinx/lfun/PreventInsert.rst
new file mode 100644
index 0000000..2e42639
--- /dev/null
+++ b/doc/sphinx/lfun/PreventInsert.rst
@@ -0,0 +1,72 @@
+PreventInsert()
+===============
+
+FUNKTION
+--------
+::
+
+ int PreventInsert(object ob);
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+ ob
+ Das Objekt, das in den Behaelter eingefuegt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion kann ein Behaelter pruefen, ob er das Objekt ob
+ aufnehmen moechte oder nicht.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn das Objekt aufgenommen werden kann; ein Wert groesser als 0
+ zeigt an, dass das Objekt nicht aufgenommen werden soll.
+
+BEMERKUNGEN
+-----------
+::
+
+ Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventInsert() zwar
+ aufgerufen, das Objekt wird jedoch auf jeden Fall in den Behaelter
+ bewegt, unabhaengig vom Rueckgabewert!
+
+BEISPIELE
+---------
+::
+
+ Um zu verhindern, dass man Geld in einen Behaelter stecken kann, sollte
+ man wie folgt vorgehen:
+
+ varargs int PreventInsert(object ob)
+ {
+ // Wenn es Geld ist, erheben wir sofort Einspruch
+ if (ob->id("geld"))
+ return 1;
+ // Ansonsten koennte ein ererbtes Objekt noch Einspruch erheben!
+ else
+ return ::PreventInsert(ob);
+ }
+
+SIEHE AUCH
+----------
+::
+
+ PreventLeave(), NotifyInsert(), NotifyLeave(), MayAddObject(),
+ PreventInsertLiving(), PreventLeaveLiving(), NotifyMove(),
+ PreventMove(), MayAddWeight(), move(), /std/container/restrictions.c
+
+
+Last modified: Sat Dec 18 02:00:00 1999 by Tiamak
+
diff --git a/doc/sphinx/lfun/PreventInsertLiving.rst b/doc/sphinx/lfun/PreventInsertLiving.rst
new file mode 100644
index 0000000..f8d62ec
--- /dev/null
+++ b/doc/sphinx/lfun/PreventInsertLiving.rst
@@ -0,0 +1,57 @@
+PreventInsertLiving()
+=====================
+
+FUNKTION
+--------
+::
+
+ int PreventInsertLiving(object ob);
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+ ob
+ Das Living, das in den Behaelter eingefuegt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion kann ein Behaelter pruefen, ob er das Living ob
+ aufnehmen moechte oder nicht.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn das Living aufgenommen werden kann; ein Wert groesser als 0
+ zeigt an, dass das Living nicht aufgenommen werden soll.
+
+BEMERKUNGEN
+-----------
+::
+
+ Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventInsertLiving()
+ zwar aufgerufen, das Living wird jedoch auf jeden Fall in den Behaelter
+ bewegt, unabhaengig vom Rueckgabewert!
+
+SIEHE AUCH
+----------
+::
+
+ PreventLeaveLiving(), /std/container/restrictions.c,
+ PreventMove(), PreventInsert(), PreventLeave(),
+ NotifyMove(), NotifyInsert(), NotifyLeave(), NotifyRemove(),
+ move(), init(), exit(),
+ InitAttack(), ExitAttack()
+
+
+Last modified: 04.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/PreventLeave.rst b/doc/sphinx/lfun/PreventLeave.rst
new file mode 100644
index 0000000..e29d213
--- /dev/null
+++ b/doc/sphinx/lfun/PreventLeave.rst
@@ -0,0 +1,58 @@
+PreventLeave()
+==============
+
+FUNKTION
+--------
+::
+
+ int PreventLeave(object ob, mixed dest);
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+ ob
+ Das Objekt, das aus dem Behaelter genommen werden soll.
+ dest
+ Das Ziel in das das Objekt ob bewegt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion kann ein Behaelter pruefen, ob er das Objekt ob
+ sich bewegen lassen moechte oder nicht.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn das Objekt bewegt werden kann; ein Wert groesser als 0
+ zeigt an, dass das Objekt nicht bewegt werden soll.
+
+BEMERKUNGEN
+-----------
+::
+
+ Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventLeave() zwar
+ aufgerufen, das Objekt wird jedoch auf jeden Fall aus dem Behaelter
+ bewegt, unabhaengig vom Rueckgabewert!
+
+SIEHE AUCH
+----------
+::
+
+ PreventInsert(), NotifyInsert(), NotifyLeave(),
+ MayAddWeight(), move(), /std/container/restrictions.c
+ PreventLeaveLiving(), PreventInsertLiving(), PreventMove(),
+ NotifyMove(), MayAddObject(), NotifyRemove()
+
+
+Last modified: 04.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/PreventLeaveLiving.rst b/doc/sphinx/lfun/PreventLeaveLiving.rst
new file mode 100644
index 0000000..8616cc2
--- /dev/null
+++ b/doc/sphinx/lfun/PreventLeaveLiving.rst
@@ -0,0 +1,58 @@
+PreventLeaveLiving()
+====================
+
+FUNKTION
+--------
+::
+
+ int PreventLeaveLiving(object ob, mixed dest);
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+ ob
+ Das Living, das aus dem Behaelter genommen werden soll.
+ dest
+ Das Ziel in das das Living ob bewegt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion kann ein Behaelter pruefen, ob er das Living ob
+ sich bewegen lassen moechte oder nicht.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn das Living bewegt werden kann; ein Wert groesser als 0
+ zeigt an, dass das Living nicht bewegt werden soll.
+
+BEMERKUNGEN
+-----------
+::
+
+ Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventLeave() zwar
+ aufgerufen, das Living wird jedoch auf jeden Fall aus dem Behaelter
+ bewegt, unabhaengig vom Rueckgabewert!
+
+SIEHE AUCH
+----------
+::
+
+ PreventInsertLiving(), /std/container/restrictions.c
+ PreventMove(), PreventLeave(), PreventInsert(),
+ NotifyMove(), NotifyLeave(), NotifyInsert(), NotifyRemove(),
+ move(), exit(), init(),
+ InitAttack, ExitAttack()
+
+Last modified: 04.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/PreventMove.rst b/doc/sphinx/lfun/PreventMove.rst
new file mode 100644
index 0000000..a8a7a5a
--- /dev/null
+++ b/doc/sphinx/lfun/PreventMove.rst
@@ -0,0 +1,110 @@
+PreventMove()
+=============
+
+PreventInsert()
+---------------
+::
+
+FUNKTION
+--------
+::
+
+ protected int PreventMove(object dest, object oldenv, int method);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/moving.c
+ /std/living/moving.c
+ /std/player/moving.c
+
+ARGUMENTE
+---------
+::
+
+ dest
+ Das Ziel des Moves
+ oldenv
+ Das (Noch-)Environment des Objekts
+ method
+ Die Move-Methode(n), mit der/denen bewegt werden soll
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion prueft ein Objekt, ob es von 'oldenv' nach 'dest'
+ bewegt werden mag. Dabei wird 'method' beruecksichtigt (z.B. schaltet
+ M_NOCHECK die meisten Pruefungen ab).
+ Bei Gegenstaenden wird z.B. P_NODROP, P_NOGET, das Gewicht, ob das Ziel
+ das Objekt aufnehmen will (MayAddWeight(), PreventInsert) oder auch
+ PreventLeave() geprueft.
+ Bei Lebewesen wird z.B. P_NO_TPORT in 'dest' und 'oldenv' und
+ PreventLeaveLiving/PreventInsertLiving() ausgewertet.
+ Bei Spielern wird auch noch getestet, ob method M_GO oder M_TPORT
+ enthaelt und ob das Ziel nur von Testspielern betreten werden kann.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn das Objekt bewegt werden darf.
+ Wenn es nicht bewegt werden darf, sind als Rueckgabewerte die in
+ /sys/moving.h definierten Move-Fehlerwerte zulaessig (s. move()). Sollte
+ hier ein ungueltiger Fehlerwert zurueckgegeben werden, wird das move()
+ ebenfalls abgebrochen und ME_DONT_WANT_TO_BE_MOVED zurueckgeben.
+
+BEMERKUNGEN
+-----------
+::
+
+ Diese Funktion kann ueberschrieben, um feinere Kontrolle ueber die
+ Bewegungen des Objekt zu haben. Dabei aber bitte einige Dinge beachten:
+ 1. Denkt daran, ggf. M_NOCHECK zu beruecksichtigen und und eure
+ Pruefungen nur zu machen, wenn es nicht in method vorkommt.
+ 2. GANZ WICHTIG: Wenn ihr mit euren Pruefungen fertig sein und das Objekt
+ bewegt werden duerfte, die geerbten Pruefungen noch testen, also _IMMER_
+ das geerbte PreventMove() noch aufrufen und dessen Wert
+ zurueckgeben/beruecksichtigen, da sonst Pruefungen des Gewichts etc.
+ nicht funktionieren oder bei Lebewesen die Prevent*() im Environment
+ nicht gerufen werden!
+ 3. Die Funktion ist nur objektintern zu verwenden, Call-Other von aussen
+ sind nicht moeglich, beim Ueberschreiben 'protected' nicht vergessen.
+ 4. Nochmal: Geerbtes PreventMove() _NICHT VERGESSEN_!
+
+BEISPIELE
+---------
+::
+
+ Ein Objekt, was nur im Sternenlicht aufgenommen werden kann (warum
+ auch immer):
+
+ protected int PreventMove(object dest, object oldenv, int method) {
+ if ( (method & M_NOCHECK) ) {
+ // wenn mit M_NOCHECK bewegt, ist das Sternenlicht egal, nur
+ // geerbtes PreventMove() beruecksichten:
+ return ::PreventMove(dest, oldenv, method);
+ }
+ else if ( method & M_GET) {
+ // wenn es aufgenommen werden soll: nach Sternenlicht im Raum
+ // gucken:
+ if (objectp(dest) &&
+ (dest->QueryProp(P_LIGHT_TYPE) != LT_STARS))
+ return ME_CANT_BE_TAKEN;
+ }
+ // Fall-through:
+ return ::PreventMove(dest, oldenv, method);
+ }
+
+SIEHE AUCH
+----------
+::
+
+ PreventLeave(), NotifyInsert(), NotifyLeave(), MayAddObject(),
+ PreventInsertLiving(), PreventLeaveLiving(), NotifyMove(),
+ PreventMove(), MayAddWeight(), move(), /std/container/restrictions.c
+
+
+Last modified: 04.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/Query.rst b/doc/sphinx/lfun/Query.rst
new file mode 100644
index 0000000..0a27959
--- /dev/null
+++ b/doc/sphinx/lfun/Query.rst
@@ -0,0 +1,108 @@
+Query()
+=======
+
+FUNKTION
+--------
+::
+
+ public varargs mixed Query(string name, int Type);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/properties.c
+
+ARGUMENTE
+---------
+::
+
+ string name - Property, deren Wert(e) ausgelesen werden
+ int type - Art der gewuenschten Information.
+
+BESCHREIBUNG
+------------
+::
+
+ Der Wert einer der inneren Eigenschaften der Property 'name' wird
+ zurueckgegeben. 'Type' ist dabei einer der in /sys/thing/properties.h
+ und folgend aufgelisteten F_XXX-Werte:
+
+ F_VALUE (==0, Default)
+ Unter Umgehung einer eventuell vorhandenen Abfragemethode oder
+ _query_'name'() wird der Datenwert der Property 'name'
+ zurueckgegeben.
+ F_MODE
+ Die internen Flags der Property werden zurueckgegeben.Dies koennen
+ (logisch mit & verknuepft) sein:
+ SAVE - Property soll bei save_object() gespeichert werden
+ PROTECTED - Objekt selbst/EM/Root kann Property manipulieren
+ SECURED - wie PROTECTED, das Flag kann aber nicht
+ zurueckgesetzt werden (immer SECURED)
+ NOSETMETHOD - niemand kann Property manipulieren
+ (auch kein F_SET_METHOD oder _set_'name'())
+ F_SET_METHOD
+ Ein eventuell fuer die Property eingetragene F_SET_METHOD wird
+ zurueckgegeben.
+ (_set_'name'()-Methoden werden so nicht aufgefuehrt!)
+ F_QUERY_METHOD
+ Ein eventuell fuer die Property eingetragene F_QUERY_METHOD wird
+ zurueckgegeben.
+ (_query_'name'()-Methoden werden so nicht aufgefuehrt!)
+
+RUeCKGABEWERT
+-------------
+::
+
+ Die gewuenschte Eigenschaft, abhaengig von 'Type'.
+
+BEMERKUNGEN
+-----------
+::
+
+ - Query() sollte nicht zum regulaeren Auslesen des Inhalt einer
+ Property verwendet werden, da sowohl F_QUERY_METHOD als auch
+ libinterne _query_'name'()-Methoden umgangen werden und das Ergebnis
+ fuer so veraenderte Propertys undefiniert ist
+ - _set_'name'() und _query_'name'() sind alte Propertymethoden und
+ sollten nicht in normalen Objekten benutzt werden ->
+ F_SET_METHOD/F_QUERY_METHOD (ggf. mit PROTECTED) nutzen
+ - F_SET/F_QUERY_METHODs koennen 'protected' (empfohlen) oder 'static'
+ sein. _set_/_query_ duerfen momentan _nicht_ 'protected' sein, fuer
+ diese geht nur 'static' (in diesem Fall empfohlen).
+
+BEISPIELE
+---------
+::
+
+ // Auslesen des Wertes unter Umgehung einer Abfragemethode
+ Query(P_XYZ, F_VALUE);
+
+ // Auslesen der Flags erfaehrt man mit:
+ Query(P_XYZ, F_MODE);
+
+ // sauberes Programmieren, wir wollen eine F_QUERY_METHOD setzen,
+ // pruefen vorher auf Existenz:
+ if(this_player()->Query(P_FROG, F_QUERY_METHOD) {
+ write(break_string(
+ "Ich kann dich nicht weiter vor Froschsein schuetzen!",
+ "Der Magier winkt ab: ", 78));
+ say(break_string(
+ "Ich kann dich nicht weiter vor Froschsein schuetzen!",
+ "Der Magier sagt zu "+this_player()->name(WEM)+": ", 78));
+ } else {
+ this_player()->Set(P_FROG, #'query_protect_frog, F_QUERY_METHOD);
+ ...
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Aehnliches: SetProp(L), QueryProp(L), Set(L)
+ Generell: SetProperties(L), QueryProperties(L)
+ Konzept: properties, /std/thing/properties.c
+ Sonstiges: P_AUTOLOADOBJ
+
+28.03.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/QueryAllDoors.rst b/doc/sphinx/lfun/QueryAllDoors.rst
new file mode 100644
index 0000000..9980ad0
--- /dev/null
+++ b/doc/sphinx/lfun/QueryAllDoors.rst
@@ -0,0 +1,53 @@
+QueryAllDoors()
+===============
+
+FUNKTION
+--------
+::
+
+ mapping QueryAllDoors();
+
+DEFINIERT IN
+------------
+::
+
+ /obj/doormaster.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Es werden die Zustaende ALLER Tueren im MorgenGrauen ermittelt.
+
+RUECKGABEWERT
+-------------
+::
+
+ Ein Mapping mit den Zustaenden aller Tueren im MorgenGrauen. Als
+ Schluessel dienen die Dateinamen der Start- und Zielraeume in
+ lexikographischer (alphabetischer) Reihenfolge, getrennt durch ":",
+ der Wert des Keys ist der aktuelle Zustand dieser Tuer, z.B.:
+
+ ([ "/d/inseln/schiffe/jolle:/d/inseln/schiffe/jolle/masch" : -1,
+ ...
+ ]);
+
+ Es gibt also eine Tuer zwischen Jolle und Maschinenraum, die
+ momenten geschlossen ist (-1 = D_STATUS_CLOSED).
+
+SIEHE AUCH
+----------
+::
+
+ NewDoor(), QueryDoorKey(), QueryDoorStatus(), SetDoorStatus(),
+ /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), P_DOOR_INFOS
+
+
+Letzte Aenderung: Don, 08.05.2014, Gabylon
+
diff --git a/doc/sphinx/lfun/QueryArmourByType.rst b/doc/sphinx/lfun/QueryArmourByType.rst
new file mode 100644
index 0000000..17e6967
--- /dev/null
+++ b/doc/sphinx/lfun/QueryArmourByType.rst
@@ -0,0 +1,91 @@
+QueryArmourByType()
+===================
+
+QyeryArmourByType()
+-------------------
+::
+
+FUNKTION
+--------
+::
+
+ mixed QueryArmourByType(string type)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ string type
+ Typ der Ruestung aus /sys/combat.h, auf die getestet werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Abfrage, ob das Lebewesen eine Ruestung des angegebenen Typs traegt.
+
+ Zurueckgegeben wird je nach Tragestatus und <type>:
+ * 0, falls das Lebewesen die gesuchte Ruestungsart nicht traegt
+ * im Erfolgsfall das Ruestungsobjekt
+ * falls <type> AT_MISC ist:
+ * ({}), wenn es keine AT_MISC-Ruestung traegt
+ * ein Array von AT_MISC-Ruestungen
+ * falls <type> 0 ist: ein Mapping, das diese Informationen mit dem
+ Ruestungstypen als Schluessel enthaelt:
+ ([AT_MISC: ({[object], ...}),
+ AT_...: <object>,
+ ... ])
+
+BEMERKUNG
+---------
+::
+
+ Ist <type> AT_MISC, so wird auf jeden Fall ein Array zurueckgegeben!
+
+BEISPIELE
+---------
+::
+
+ Wir wollen wissen, ob this_player() Handschuhe traegt:
+
+ if (objectp(this_player()->QueryArmourByType(AT_GLOVE)))
+ ...
+
+
+ Wir bauen einen Tuersteher, der auf AT_MISC-Kleidung achtet:
+
+ if (sizeof(this_player()->QueryArmourByType(AT_MISC)) > 3) {
+ if(this_player()->ReceiveMsg(
+ "Du darfst nicht passieren, Du hast zuviele "
+ "unpassende Dinge an!",
+ MT_LISTEN|MSG_DONT_STORE, MA_TELL,
+ "Der Waechter teilt Dir mit: ")<MSG_DELIVERED && // taub?
+ this_player()->ReceiveMsg(
+ "Der Waechter haelt dich auf.", MT_LOOK)<MSG_DELIVERED) // blind?
+ this_player()->ReceiveMsg(
+ "Jemand haelt dich auf.", MT_FEEL); // nu aber!
+ // Aufhalten!
+ } else this_player()->ReceiveMsg(
+ "Du darfst passieren, viel Spass im Casino!",
+ MT_LISTEN|MSG_DONT_STORE, MA_TELL,
+ "Der Waechter teilt Dir mit: ");
+ // im Erfolgsfall ist es uns egal, wenn es der Spieler nicht
+ // liest: er wird dann eben "wortlos" durchgelassen
+
+SIEHE AUCH
+----------
+::
+
+ Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour(),
+ UnwearClothing(), FilterClothing(),
+ P_ARMOUR_TYPE, P_CLOTHING, P_ARMOURS,
+ /std/living/combat.c
+
+02.02.2016, Gloinson
+
diff --git a/doc/sphinx/lfun/QueryArrived.rst b/doc/sphinx/lfun/QueryArrived.rst
new file mode 100644
index 0000000..2ae07e9
--- /dev/null
+++ b/doc/sphinx/lfun/QueryArrived.rst
@@ -0,0 +1,46 @@
+QueryArrived()
+==============
+
+FUNKTION
+--------
+::
+
+ mixed QueryArrived();
+
+DEFINIERT IN
+------------
+::
+
+ /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion ermittelt, ob sich der Transporter momentan an einer
+ Haltestelle befindet (und bestiegen oder verlassen werden kann) oder ob
+ er unterwegs ist.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Null, wenn der Transporter unterwegs ist. Liegt der Transporter an
+ einer Haltestelle, so wird der mit AddRoute als name uebergebene String
+ zurueckgegeben.
+
+SIEHE AUCH
+----------
+::
+
+ AddRoute(), /std/transport.c
+
+
+Last modified: Wed May 8 10:21:47 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryArticle.rst b/doc/sphinx/lfun/QueryArticle.rst
new file mode 100644
index 0000000..4076520
--- /dev/null
+++ b/doc/sphinx/lfun/QueryArticle.rst
@@ -0,0 +1,118 @@
+QueryArticle()
+==============
+
+FUNKTION
+--------
+::
+
+ varargs string QueryArticle(int casus, int dem, int force);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+ casus
+ Der Fall, in dem der Artikel gewuenscht wird.
+ (Konstanten aus /sys/thing/language.h: WER, WEM, WESSEN, WEN.)
+
+ dem
+ Wird ein bestimmter oder ein unbestimmter Artikel verlangt?
+ + dem = 0: Unbestimmter Artikel!
+ + dem = 1: Bestimmter Artikel!
+ + dem = 2: Finde selbst heraus, welcher Artikel passt!
+
+ force
+ Falls ungleich Null, so wird auf jeden Fall ein Artikel
+ zurueckgegeben, trotz P_ARTICLE == 0.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion gibt einen zum Geschlecht des Objektes passenden Artikel
+ zurueck, der in den passenden Fall dekliniert wird.
+
+ Das Herausfinden des passenden Artikels bei 'dem' = 2 bezieht sich auf
+ Situationen, in denen mehrere gleichnamige Objekte im selben Environment
+ sind. Man 'nimmt' dann zB nicht "den Stamm" sondern "einen Stamm".
+
+ Ist P_ARTICLE = 0, so wird ein Leerstring zurueckgegeben, es sei denn,
+ man uebergibt in dem Argument 'force' einen Wert ungleich Null.
+
+BEMERKUNGEN
+-----------
+::
+
+ Achtung: bei gueltigem Artikel wird ein Leerzeichen angehaengt!
+
+ Name()/name() nutzen bereits QueryArticle(), wenn P_ARTICLE gesetzt
+ ist. Deshalb muss man sich "Eines Orks" nicht selbst aus dem
+ QueryArticle() und dem Namen zusammenbasteln, wenn mehrere Orks
+ im Raum herumstehen und man eine Nachricht wie:
+ "Du haust den Ork." und folgend
+ "[Des|Eines] Orks Nase schwillt an."
+ haben moechte:
+ "Du haust "+ork->name(WEN, 1)+". "
+ ork->Name(WESSEN, 2)+" Nase schwillt an."
+
+RUeCKGABEWERT
+-------------
+::
+
+ * gewuenschter Artikel als String plus Leerzeichen (!) ODER
+ * Leerstring
+
+BEISPIELE
+---------
+::
+
+ // "X haut Y auf die Nase. [Der|Die|Das] ist nicht beeindruckt."
+ // Man will:
+ // * auf jeden Fall einen Artikel, auch wenn kein P_ARTICLE gesetzt ist
+ // * nur den bestimmten Artikel
+ send_room(this_object(),
+ pl1->Name(WER)+" haut "+pl2->name(WEM)+" auf die Nase. "+
+ capitalize(pl2->QueryArticle(WER, 1, 1))+"ist nicht beeindruckt.",
+ MT_LOOK|MT_LISTEN, 0, 0, ({pl1, pl2}));
+
+ // "X gibt dir Y. [Er|Sie|Es] prueft [den|die|das] ..."
+ // Man will:
+ // * auf jeden Fall einen Artikel, auch wenn kein P_ARTICLE gesetzt ist
+ // * nur den bestimmten Artikel
+ send_room(this_object(),
+ pl1->Name(WER)+" gibt "+pl2->name(WEM)+" "+obj->name(WER)+". "+
+ capitalize(pl2->QueryPronoun(WER))+" prueft "+
+ ob->QueryArticle(WEN, 1, 1)+"...",
+ MT_LOOK|MT_LISTEN, 0, 0, ({pl1, pl2}));
+
+ // "Dir faellt X auf den Kopf. Du siehst [die|den|das|eine|einen|eines "
+ // "auf dem Boden liegen. [Sie|Er|Es] sieht blutig aus. Aua. Ist das "
+ // "von dir?"
+ // Man will:
+ // * auf jeden Fall einen Artikel, auch wenn kein P_ARTICLE gesetzt ist
+ // * bestimmte/unbestimmte Artikel, wenn bereits gleiche Gegenstaende
+ // (zB Kokosnuesse) auf dem Boden liegen ...
+ ob->move(environment(), M_NOCHECK); // vorher machen!
+ pl->ReceiveMsg(
+ "Dir faellt "+ob->name(WER, 0)+" auf den Kopf. Du siehst "+
+ ob->QueryArticle(WEN, 2, 1)+" auf dem Boden liegen. "+
+ capitalize(ob->QueryPronoun(WER))+" sieht blutig ...
+
+SIEHE AUCH
+----------
+::
+
+ Aehnlich: SuggestArticle(), query_c_article(), query_g_suffix()
+ Sonstiges: QueryOwn(), QueryDu(),
+ QueryPronoun(), QueryPossPronoun()
+ DeclAdj()
+ name()
+
+9. Jun 2016, Gloinson
+
diff --git a/doc/sphinx/lfun/QueryAttribute.rst b/doc/sphinx/lfun/QueryAttribute.rst
new file mode 100644
index 0000000..a5c0c72
--- /dev/null
+++ b/doc/sphinx/lfun/QueryAttribute.rst
@@ -0,0 +1,59 @@
+QueryAttribute()
+================
+
+FUNKTION
+--------
+::
+
+ int QueryAttribute(string attr)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+ attr - interessierendes Gesamtattribut
+
+BESCHREIBUNG
+------------
+::
+
+ Das Attribut samt seiner Offsets (Modifier) wird zurueckgegeben.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Wert des Attributes, bei Spielern nicht groesser als 30.
+
+BEISPIELE
+---------
+::
+
+ if (this_player()->QueryAttribute(A_CON) > 20)
+ write("Du schaffst es den Berg hoch. Aber nur muehsam.\n");
+
+BENERKUNGEN
+-----------
+::
+
+ Wenn es um Attributabfragen geht, bitte diese Methode verwenden!
+
+SIEHE AUCH
+----------
+::
+
+ QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+ SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+ SetTimedAttrModifier(), QueryTimedAttrModifier(),
+ DeleteTimedAttrModifier(),
+ P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+ P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/QueryAttributeOffset.rst b/doc/sphinx/lfun/QueryAttributeOffset.rst
new file mode 100644
index 0000000..55c6909
--- /dev/null
+++ b/doc/sphinx/lfun/QueryAttributeOffset.rst
@@ -0,0 +1,47 @@
+QueryAttributeOffset()
+======================
+
+FUNKTION
+--------
+::
+
+ int QueryAttributeOffset(string attr)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+ attr - gesuchter AttributOffset
+
+BESCHREIBUNG
+------------
+::
+
+ Die Offsets des Attributs (inklusive Modifier) werden zurueckgegeben.
+
+BEISPIELE
+---------
+::
+
+ if(this_player()->QueryAttributeOffset(A_STR)<0)
+ write("Du bist geschwaecht.\n");
+
+SIEHE AUCH
+----------
+::
+
+ QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+ SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+ SetTimedAttrModifier(), QueryTimedAttrModifier(),
+ DeleteTimedAttrModifier(),
+ P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+ P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/QueryBuyFact.rst b/doc/sphinx/lfun/QueryBuyFact.rst
new file mode 100644
index 0000000..fc0fdb5
--- /dev/null
+++ b/doc/sphinx/lfun/QueryBuyFact.rst
@@ -0,0 +1,42 @@
+QueryBuyFact()
+==============
+
+FUNKTION
+--------
+::
+
+ int QueryBuyFact();
+
+DEFINIERT IN
+------------
+::
+
+ /std/laden.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt den mit SetBuyFact() gesetzten Faktor zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der Einkaufspreismultiplikator.
+
+SIEHE AUCH
+----------
+::
+
+ SetBuyFact(), /std/laden.c
+
+
+Last modified: Wed May 8 10:21:57 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryBuyValue.rst b/doc/sphinx/lfun/QueryBuyValue.rst
new file mode 100644
index 0000000..815cf5e
--- /dev/null
+++ b/doc/sphinx/lfun/QueryBuyValue.rst
@@ -0,0 +1,62 @@
+QueryBuyValue()
+===============
+
+QueryBuyValue()
+
+Funktion
+ static varargs int QueryBuyValue(mixed ob, object client)
+
+Definiert in
+ /std/room/shop
+
+Argumente
+ ob
+ Das zu kaufende Objekt (String oder object).
+ Im Normalfall handelt es sich um ein Objekt. Ausnahme sind
+ Gegenstaende, die mit AddFixedObject() hinzugefuegt wurden.
+ client
+ Der Kaeufer.
+
+Beschreibung
+ Ermittelt den Preis, den <client> fuer <ob> zu bezahlen hat.
+
+Rueckgabewert
+ Der Preis als Integer.
+
+Beispiel
+ Ein Haendler, der Spielern die ihm geholfen haben einen Rabatt von 10%
+ gewaehrt
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+::
+
+
+
+ object *helpers;
+ protected void create()
+ {
+ ::create();
+ helpers=({});
+ ...
+ }
+
+
+
+ static varargs int QueryBuyValue(mixed ob, object client)
+ {
+ if(member(helpers,client)!=-1)
+ {
+ return ::QueryBuyValue(ob,client)*9/10;
+ }
+ return ::QueryBuyValue(ob,client);
+ }
+
+Siehe auch:
+ Funktionen:
+ AddFixedObject(), RemoveFixedObject(), SetStorageRoom(),
+ QueryStorageRoom(), QueryBuyFact(), sell_obj(), buy_obj()
+ Properties:
+ P_KEEPER, P_MIN_STOCK, P_STORE_CONSUME
+
+
+Letzte Aenderung: 21.05.2014, Bugfix
+
diff --git a/doc/sphinx/lfun/QueryCoinsPerUnits.rst b/doc/sphinx/lfun/QueryCoinsPerUnits.rst
new file mode 100644
index 0000000..476f243
--- /dev/null
+++ b/doc/sphinx/lfun/QueryCoinsPerUnits.rst
@@ -0,0 +1,58 @@
+QueryCoinsPerUnits()
+====================
+
+QueryCoinsPerUnit()
+-------------------
+::
+
+FUNKTION
+--------
+::
+
+ int *QueryCoinsPerUnits();
+
+DEFINIERT IN
+------------
+::
+
+ /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Liefert das Wertverhaeltnis fuer die Einheiten zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ein Array von zwei Zahlen. Die erste Zahl ist der Wert der in der
+ zweiten Zahl angegebenen Einheiten.
+
+BEISPIELE
+---------
+::
+
+ Steht im Unit-Objekt folgende Wertzuweisung:
+
+ SetCoinsPerUnits(7,2);
+
+ so liefert QueryCoinsPerUnits() als Ergebnis ({7, 2}).
+
+SIEHE AUCH
+----------
+::
+
+ SetCoinsPerUnits(), SetGramsPerUnits(), QueryGramsPerUnit(),
+ /std/unit.c
+
+
+Last modified: Wed May 8 10:22:02 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryDamage.rst b/doc/sphinx/lfun/QueryDamage.rst
new file mode 100644
index 0000000..4576d28
--- /dev/null
+++ b/doc/sphinx/lfun/QueryDamage.rst
@@ -0,0 +1,62 @@
+QueryDamage()
+=============
+
+FUNKTION
+--------
+::
+
+ int QueryDamage(object enemy);
+
+DEFINIERT IN
+------------
+::
+
+ /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+ enemy
+ Der Gegner, gegen den die Waffe eingesetzt wird.
+
+BESCHREIBUNG
+------------
+::
+
+ Dies ist die zentrale Funktion der Waffe. Sie wird in jeder Kampfrunde
+ von Attack() aus aufgerufen und gibt den Schaden zurueck, den der
+ Gegner abwehren muss.
+
+ In den Schaden gehen sowohl die Staerke der Waffe als auch die Staerke
+ des Traegers der Waffe ein.
+
+ Wurde eine HitFunc() angegeben, so wird diese mit den gleichen
+ Parametern wie QueryDamage() aufgerufen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Die Staerke des Schlages fuer diese Kampfrunde. Sie ermittelt sich als
+ Zufallszahl zwischen 0 und einem Wert, der sich aus der Staerke der
+ Waffe und der Staerke ihres Traegers ergibt. Das Ergebnis des
+ HitFunc()-Aufrufs wird zu dieser Zahl hinzugezaehlt.
+
+BEMERKUNGEN
+-----------
+::
+
+ Auch wenn man eine HitFunc() verwendet, darf der Rueckgabewert
+ insgesamt nicht groesser als 200 werden. Im Zweifelsfall sollte
+ man sich mit der zustaendigen Balance besprechen!
+
+SIEHE AUCH
+----------
+::
+
+ HitFunc(), Attack(), /std/weapon.c, grenzwerte
+
+
+Last modified: Fre Feb 16.02.01 12:58:00 von Tilly
+
diff --git a/doc/sphinx/lfun/QueryDefend.rst b/doc/sphinx/lfun/QueryDefend.rst
new file mode 100644
index 0000000..eba5246
--- /dev/null
+++ b/doc/sphinx/lfun/QueryDefend.rst
@@ -0,0 +1,68 @@
+QueryDefend()
+=============
+
+FUNKTION
+--------
+::
+
+ int QueryDefend(string|string* dtyp, int|mapping spell, object enemy);
+
+DEFINIERT IN
+------------
+::
+
+ /std/armour/combat.c
+
+ARGUMENTE
+---------
+::
+
+ dtyp - Schadenstypen der Angriffsart
+ spell - 0 bei konventionellem Angriff,
+ != 0 bei Angriff mit einem nichtphysischen Spell,
+ mapping bei genaueren Angaben zur Wirkung
+ enemy - Der angreifende Gegner
+
+BESCHREIBUNG
+------------
+::
+
+ Dies ist die zentrale Funktion einer Ruestung. Sie wird in jeder
+ Kampfrunde aus /std/living/combat::Defend() fuer jede Ruestung aufgerufen,
+ die der Spieler angezogen hat.
+
+ Der Schutzwert von P_AC entfaltet seine Wirkung nur bei konventionellen
+ Angriffen:
+ * wenn 'spell' 0 ist (bei Aufruf aus der Defend heraus ausgeschlossen)
+ * wenn 'spell' ein Mapping mit dem Flag SP_PHYSICAL_ATTACK != 0 UND
+ in 'dtyp' mindestens ein physischer Schaden enthalten ist
+
+RUeCKGABEWERT
+-------------
+::
+
+ Die Ruestungsstaerke in dieser Kampfrunde. Sie ermittelt sich als
+ Zufallszahl zwischen 0 und P_AC, zuzueglich des Ergebnisses des
+ DefendFunc()-Aufrufs.
+
+BEMERKUNGEN
+-----------
+::
+
+ Auch wenn man eine DefendFunc() benutzt, darf der Rueckgabewert
+ insgesamt nicht groesser werden als der fuer den Ruestungstyp
+ maximal zulaessige!
+
+SIEHE AUCH
+----------
+::
+
+ Ruestungen: P_ARMOUR_TYPE, P_NR_HANDS, P_ARMOURS, P_WORN
+ Schutz: P_AC, Defend(), DefendFunc
+ Sonstiges: P_EQUIP_TIME, P_LAST_USE, P_DAM_TYPE
+ Verwandt: QueryArmourByType(L), P_WEAPON, FilterClothing(),
+ FilterArmours()
+ Resistenz: P_RESISTANCE_STRENGTHS, CheckResistance(L)
+
+28.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/lfun/QueryDisguise.rst b/doc/sphinx/lfun/QueryDisguise.rst
new file mode 100644
index 0000000..a251120
--- /dev/null
+++ b/doc/sphinx/lfun/QueryDisguise.rst
@@ -0,0 +1,52 @@
+QueryDisguise()
+===============
+
+FUNKTION
+--------
+::
+
+ mixed QueryDisguise();
+
+DEFINIERT IN
+------------
+::
+
+ ???
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Prueft, ob der Spieler durch einen Shadow (meistens der Tarnhelm)
+ 'manipuliert' ist.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn dies nicht der Fall ist, ansonsten die Beschreibung des Shadow
+ vom Typ string.
+
+BEMERKUNGEN
+-----------
+::
+
+ In Waffen / Ruestungen u.ae. die P_RESTRICTIONS gesetzt haben,
+ eruebrigt sich eine Abfrage auf QueryDisguise(), da dies bereits im
+ restriction_checker erledigt wird.
+
+SIEHE AUCH
+----------
+::
+
+ P_RESTRICTIONS, /std/restriction_checker.c
+
+
+Last modified: Mon Mar 26 14:48:20 2001 von Tilly
+
diff --git a/doc/sphinx/lfun/QueryDoorKey.rst b/doc/sphinx/lfun/QueryDoorKey.rst
new file mode 100644
index 0000000..355c898
--- /dev/null
+++ b/doc/sphinx/lfun/QueryDoorKey.rst
@@ -0,0 +1,72 @@
+QueryDoorKey()
+==============
+
+FUNKTION
+--------
+::
+
+ mixed QueryDoorKey();
+
+DEFINIERT IN
+------------
+::
+
+ versch. Schluesseln
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird in einem Schluessel aufgerufen, wenn man mit diesem
+ eine Tuer auf- oder abschliessen will. Anhand des Rueckgabewertes wird
+ entschieden, ob der Schluessel passt oder nicht.
+
+RUECKGABEWERT
+-------------
+::
+
+ String oder Array von Strings der Raumpfade, deren gemeinsame Tueren
+ sich mit diesem Schluessel auf- bzw. abschliessen lassen. Die Keys sind
+ dabei die Raumpfade, getrennt durch ein ":". Dabei muessen die Pfade
+ in lexikographischer (alphabetischer) Reihenfolge sortiert sein:
+
+ "<name_raum_1>:<name_raum_2>"
+
+BEISPIELE
+---------
+::
+
+ Ein Schluessel, mit dem sich eine einzige Tuer oeffnen laesst (falls es
+ jemals eine Tuer zwischen Karate- und Abenteurergilde geben sollte...):
+
+ string QueryDoorKey()
+ {
+ return "/gilden/abenteurer:/gilden/karate";
+ }
+
+ Ein Schluessel, der in mehreren Tueren passt:
+
+ string* QueryDoorKey()
+ {
+ return ({ "/gilden/abenteurer:/players/wargon/workroom",
+ "/gilden/abenteurer:/gilden/karate",
+ "/players/jof/workroom:/players/wargon/workroom"
+ });
+ }
+
+SIEHE AUCH
+----------
+::
+
+ NewDoor(), QueryDoorStatus(), SetDoorStatus(), P_DOOR_INFOS,
+ /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+
+
+Letzte Aenderung: Don, 08.05.2014, Gabylon
+
diff --git a/doc/sphinx/lfun/QueryDoorStatus.rst b/doc/sphinx/lfun/QueryDoorStatus.rst
new file mode 100644
index 0000000..58ac8dc
--- /dev/null
+++ b/doc/sphinx/lfun/QueryDoorStatus.rst
@@ -0,0 +1,49 @@
+QueryDoorStatus()
+=================
+
+FUNKTION
+--------
+::
+
+ int QueryDoorStatus(string dest);
+
+DEFINIERT IN
+------------
+::
+
+ /obj/doormaster.c
+
+ARGUMENTE
+---------
+::
+
+ <dest> = Zielraum der Tuer.
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird der Zustand der Tuer, die von diesem Raum nach <dest> fuehrt,
+ ermittelt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0 bei nicht vorhandene Tuer, ansonsten einer der folgenden Zustaende (aus
+ <doorroom.h>):
+
+ D_STATUS_LOCKED - Tuer abgeschlossen
+ D_STATUS_CLOSED - Tuer geschlossen
+ D_STATUS_OPEN - Tuer geoeffnet
+
+SIEHE AUCH
+----------
+::
+
+ NewDoor(), QueryDoorKey(), SetDoorStatus(), P_DOOR_INFOS,
+ /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+
+
+Letzte Aenderung: Don, 08.05.2014, Gabylon
+
diff --git a/doc/sphinx/lfun/QueryDu.rst b/doc/sphinx/lfun/QueryDu.rst
new file mode 100644
index 0000000..f90a7cb
--- /dev/null
+++ b/doc/sphinx/lfun/QueryDu.rst
@@ -0,0 +1,61 @@
+QueryDu()
+=========
+
+FUNKTION
+--------
+::
+
+ varargs string QueryDu(int casus, int gender, int anzahl);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+ casus
+ Der Fall fuer die Anrede.
+
+ gender
+ Das Geschlecht des anzuredenden Objektes.
+
+ anzahl
+ Ist nur ein Objekt anzusprechen oder mehrere?
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert die dem Anlass entsprechende Anrede fuer ein
+ Objekt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ein String mit der Anrede.
+
+BEISPIELE
+---------
+::
+
+ printf("%s setzt %s auf den Boden.\n",
+ capitalize(QueryDu(WER, TP->QueryProp(P_GENDER), SINGULAR),
+ QueryDu(WEN, TP->QueryProp(P_GENDER), SINGULAR));
+
+ (In den meisten Faellen kann man hier auch direkt "Du" und "dich"
+ einsetzen.)
+
+SIEHE AUCH
+----------
+::
+
+ /std/thing/language.c
+ QueryPossPronoun(), QueryOwn(), QueryPronoun()
+
+Last modified: Wed May 8 10:22:27 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryEnemies.rst b/doc/sphinx/lfun/QueryEnemies.rst
new file mode 100644
index 0000000..2816935
--- /dev/null
+++ b/doc/sphinx/lfun/QueryEnemies.rst
@@ -0,0 +1,55 @@
+QueryEnemies()
+==============
+
+FUNKTION
+--------
+::
+
+ mixed QueryEnemies();
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+RUeCKGABEWERT
+-------------
+::
+
+ Array mit Array aus bekannten Gegnern und Array aus Zeiten
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion enthaelt ein Array, das zwei Elemente enthaelt, die
+ wiederum Arrays sind:
+ 1. Array: Die bekannten Gegner als Objektpointer.
+ 2. Array: Die zugeordneten Zeiten, wie lange ein Gegner noch als
+ solcher bekannt sein soll.
+ Im Normalfall wird ein Gegner dann bekannt, wenn man gezielt
+ jemanden atackiert, oder wenn man einen Angriff abwehren muss.
+ Dann wird der Gegner intern abgespeichert, und es wird eine Zeit
+ gesetzt, die dann runtergezaehlt wird. Ist die Zeit auf 0, so wird
+ der Gegner wieder automatisch ausgetragen.
+ (Standardmaessig betraegt diese Zeit 600 Sekunden (300 Heartbeats).)
+ Man kann sich die Gegner auch in Form eines Mappings zurueckgeben
+ lassen. Dies erreicht man mittels der Funktion GetEnemies().
+
+SIEHE AUCH
+----------
+::
+
+ Kill(), Attack(), Defend(), do_my_heart_beat(), PresentEnemies(),
+ GetEnemies(), SelectEnemy(), QueryPreferedEnemy(), P_PREFERED_ENEMY
+
+
+29.12.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/QueryFlaw.rst b/doc/sphinx/lfun/QueryFlaw.rst
new file mode 100644
index 0000000..44db4bf
--- /dev/null
+++ b/doc/sphinx/lfun/QueryFlaw.rst
@@ -0,0 +1,64 @@
+QueryFlaw()
+===========
+
+FUNKTION
+--------
+::
+
+ mixed *QueryFlaw();
+
+DEFINIERT IN
+------------
+::
+
+ /std/armour/combat.c,
+ /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ QueryFlaw() liefert Informationen ueber den Grad der Abnutzung der
+ Waffe bzw. Ruestung. Der Zustand wird als Array mit der Zahl der
+ TakeFlaw()-Aufrufe und dem Datum des ersten TakeFlaw()-Aufrufs
+ zurueckgegeben.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ein Array mit drei Elementen:
+ 1. der aktuelle Zaehlerstand
+ 2. Zeit der ersten Benutzung
+ 3. die Zeit der ersten Benutzung als String
+
+BEISPIELE
+---------
+::
+
+ Den aktuellen Abnutzungsgrad einer Ruestung kann man sich wie folgt
+ anzeigen lassen:
+
+ mixed *flaw;
+
+ flaw = ruestung->QueryFlaw();
+
+ printf("Zaehlerstand: %d, erster Schlag: %s\n", flaw[0], flaw[2]);
+ // oder analog:
+ printf("Zaehlerstand: %d, erster Schlag: %s\n", flaw[0], dtime(flaw[1]));
+
+SIEHE AUCH
+----------
+::
+
+ TakeFlaw(), /std/armour/combat.c, /std/weapon/combat.c
+
+
+Last modified: Wed May 8 10:22:32 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryGenderString.rst b/doc/sphinx/lfun/QueryGenderString.rst
new file mode 100644
index 0000000..a3d1b5b
--- /dev/null
+++ b/doc/sphinx/lfun/QueryGenderString.rst
@@ -0,0 +1,43 @@
+QueryGenderString()
+===================
+
+FUNKTION
+--------
+::
+
+ string QueryGenderString();
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird ein String mit dem Geschlecht des Objektes zurueckgegeben
+ ("maennlich", "weiblich", "saechlich").
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der String mit dem Geschlecht.
+
+SIEHE AUCH
+----------
+::
+
+ /std/thing/language.c
+
+
+Last modified: Wed May 8 10:23:00 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryGramsPerUnits.rst b/doc/sphinx/lfun/QueryGramsPerUnits.rst
new file mode 100644
index 0000000..81d36fd
--- /dev/null
+++ b/doc/sphinx/lfun/QueryGramsPerUnits.rst
@@ -0,0 +1,54 @@
+QueryGramsPerUnits()
+====================
+
+FUNKTION
+--------
+::
+
+ int *QueryGramsPerUnits();
+
+DEFINIERT IN
+------------
+::
+
+ /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Liefert das Gewichtsverhaeltnis fuer die Einheiten zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ein Array von zwei Zahlen. Die erste Zahl ist das Gewicht der in der
+ zweiten Zahl angegebenen Einheiten.
+
+BEISPIELE
+---------
+::
+
+ Steht im Unit-Objekt folgende Gewichtszuweisung:
+
+ SetGramsPerUnits(4,1);
+
+ so liefert QueryGramsPerUnits() als Ergebnis ({4, 1}).
+
+SIEHE AUCH
+----------
+::
+
+ SetCoinsPerUnits(), QueryCoinsPerUnits() SetGramsPerUnits(),
+ /std/unit.c
+
+
+Last modified: Wed May 8 10:22:39 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryGroupedKeys.rst b/doc/sphinx/lfun/QueryGroupedKeys.rst
new file mode 100644
index 0000000..695a36b
--- /dev/null
+++ b/doc/sphinx/lfun/QueryGroupedKeys.rst
@@ -0,0 +1,45 @@
+QueryGroupedKeys()
+==================
+
+FUNKTION
+--------
+::
+
+ mixed *QueryGroupedKeys()
+
+DEFINIERT IN
+------------
+::
+
+ /secure/questmaster.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+RUECKGABEWERT
+-------------
+::
+
+ Array mit Arrays mit den Schluesselwoertern der Quests
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert ein Array mit mehreren Arrays zurueck, die
+ die Schluesselwoerter der Quests enthalten. Dabei enthaelt das
+ erste Array die Schluesselwoerter der Quests der ersten Gruppe etc.
+ Das letzte Array enthaelt die Gruppe der optionalen Quests.
+
+SIEHE AUCH
+----------
+::
+
+ GiveQuest, QueryQuest, /secure/questmaster.h
+
+
+Zuletzt geaendert: Son, 19. Nov 2000, 13:22:15 von Zook.
+
diff --git a/doc/sphinx/lfun/QueryGuest.rst b/doc/sphinx/lfun/QueryGuest.rst
new file mode 100644
index 0000000..90810b2
--- /dev/null
+++ b/doc/sphinx/lfun/QueryGuest.rst
@@ -0,0 +1,54 @@
+QueryGuest()
+============
+
+FUNKTION
+--------
+::
+
+ int QueryGuest();
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/base
+
+BESCHREIBUNG
+------------
+::
+
+ Auf der uid basierende Hilfsfunktion, um Gaeste zu identifizieren.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn Spielerobjekt ein Gast ist; 0 sonst
+
+BEISPIELE
+---------
+::
+
+ if(this_interactive()->QueryGuest())
+ {
+ (this_interactive()->ReceiveMsg(
+ "Wir bedienen hier nur ordentliche Charaktere.",
+ MT_LISTEN, MA_SAY,
+ "Der Wirt sagt: ") != MSG_SENSE_BLOCK) ||
+ (this_interactive()->ReceiveMsg(
+ "Der Wirt gestikuliert dich hinaus.",
+ MT_LOOK, MA_LOOK) != MSG_SENSE_BLOCK) ||
+ (this_interactive()->ReceiveMsg(
+ "Irgendwer stupst dich an. Du sollst wohl gehen.",
+ MT_FEEL, MA_FEEL));
+ return 1;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ getuid()
+
+14. Mai 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/QueryHealInfo.rst b/doc/sphinx/lfun/QueryHealInfo.rst
new file mode 100644
index 0000000..1abfd71
--- /dev/null
+++ b/doc/sphinx/lfun/QueryHealInfo.rst
@@ -0,0 +1,46 @@
+QueryHealInfo()
+===============
+
+FUNKTION
+--------
+::
+
+ string QueryHealInfo();
+
+DEFINIERT IN
+------------
+::
+
+ /std/corpse.c,
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ QueryHealInfo() liefert einen Standardtext zurueck, der grob Auskunft
+ darueber gibt, welche Auswirkungen das Essen einer Leiche haette.
+ Diese Info kann z.B. von Gilden verwendet werden, die P_HEAL (s.dort)
+ einer Leiche nicht selbst auswerten wollen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ein nicht umbrochener String. Fuer Zeilenumbrueche kann derjenige,
+ der den Text ausliest, selbst sorgen.
+
+SIEHE AUCH
+----------
+::
+
+ /std/corpse.c, P_HEAL
+
+
+Last modified: 31.03.2008, Arathorn
+
diff --git a/doc/sphinx/lfun/QueryMaterial.rst b/doc/sphinx/lfun/QueryMaterial.rst
new file mode 100644
index 0000000..ef11821
--- /dev/null
+++ b/doc/sphinx/lfun/QueryMaterial.rst
@@ -0,0 +1,62 @@
+QueryMaterial()
+===============
+
+QueryMaterial(L)
+----------------
+::
+
+FUNKTION
+--------
+::
+
+ int QueryMaterial(string mat)
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ string mat - Material, auf das getestet werden soll
+
+BESCHREIBUNG
+------------
+::
+
+ Testet, ob ein Gegenstand aus dem angegebenen Material besteht
+ und gibt dessen Anteil zurueck.
+ Die Rueckgabe ist im Wertebereich -100 (Antigruppen) bis +100 (%).
+
+RUECKGABEWERT
+-------------
+::
+
+ Anteil in Prozent.
+
+BEISPIELE
+---------
+::
+
+ if(ob->QueryMaterial(MAT_IVORY)<=0)
+ write("Daraus kannst Du keine Billiardkugeln schnitzen!\n");
+
+SIEHE AUCH
+----------
+::
+
+ Konzepte: material, materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Methoden: QueryMaterialGroup(), MaterialList(),
+ Listen: AllMaterials(), AllGroups(), Dump()
+ materialliste, materialgruppen
+ Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
+ GroupName(), MaterialName(),
+ GetGroupMembers(), GetMatMembership()
+ Sonstiges: P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/QueryMaterialGroup.rst b/doc/sphinx/lfun/QueryMaterialGroup.rst
new file mode 100644
index 0000000..9e1c396
--- /dev/null
+++ b/doc/sphinx/lfun/QueryMaterialGroup.rst
@@ -0,0 +1,81 @@
+QueryMaterialGroup()
+====================
+
+QueryMaterialGroup(L)
+---------------------
+::
+
+FUNKTION
+--------
+::
+
+ int QueryMaterialGroup(string grp)
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ string grp - Materialgruppe, auf die getestet werden soll
+
+BESCHREIBUNG
+------------
+::
+
+ Liefert eine Angabe, zu welchem Anteil das Objekt aus Materialien
+ dieser Gruppe besteht.
+ Die Rueckgabe ist im Wertebereich -100 (Antigruppen) bis +100 (%).
+
+RUECKGABEWERT
+-------------
+::
+
+ Anteil in Prozent.
+
+BEMERKUNGEN
+-----------
+::
+
+ Ruft MaterialGroup() an der MATERIALDB.
+
+BEISPIELE
+---------
+::
+
+ // kann man damit was anfangen?
+ if(ob->QueryMaterialGroup(MATGROUP_METAL)<50)
+ write("Der Schmied sagt: Daraus kann ich kein Schwert fertigen.\n");
+
+ // verbrennt das Ding?
+ if(ob->QueryMaterialGroup(MATGROUP_INFLAMMABLE)>50) {
+ write(ob->Name(WER)+" geht in Flammen auf.\n");
+ ob->remove();
+ }
+
+ // wie magnetisch ist es denn?
+ if(ob->QueryMaterialGroup(MATGROUP_MAGNETIC)>50)
+ write(break_string(
+ ob->Name(WER)+" flutscht Dir aus der Hand und bleibt am Magneten "
+ "kleben!",78));
+
+SIEHE AUCH
+----------
+::
+
+ Konzepte: material, materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Methoden: QueryMaterial(), MaterialList(),
+ Listen: AllMaterials(), AllGroups(), Dump()
+ materialliste, materialgruppen
+ Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
+ GroupName(), MaterialName(),
+ GetGroupMembers(), GetMatMembership()
+ Sonstiges: P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/QueryMaxQP.rst b/doc/sphinx/lfun/QueryMaxQP.rst
new file mode 100644
index 0000000..60b4ae7
--- /dev/null
+++ b/doc/sphinx/lfun/QueryMaxQP.rst
@@ -0,0 +1,46 @@
+QueryMaxQP()
+============
+
+FUNKTION
+--------
+::
+
+ int QueryMaxQP()
+
+DEFINIERT IN
+------------
+::
+
+ /secure/questmaster.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+RUECKGABEWERT
+-------------
+::
+
+ Abenteuerpunkte der Pflichtquests
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert die Abenteuerpunkte der als Pflichtquest
+ eingetragenen Abenteuer zurueck. Pflichtquest bedeutet entweder,
+ dass die Quest zwingend geloest werden muss oder dass sie zu
+ der 80%-Regel gehoert.
+
+SIEHE AUCH
+----------
+::
+
+ GiveQuest, QueryQuest, /secure/questmaster.h, QueryGroupedKeys,
+ QueryOptQP, QueryTotalQP
+
+
+Zuletzt geaendert: Sam, 25. Nov 2000, 14:04:28 von Zook.
+
diff --git a/doc/sphinx/lfun/QueryMoney.rst b/doc/sphinx/lfun/QueryMoney.rst
new file mode 100644
index 0000000..d38eed5
--- /dev/null
+++ b/doc/sphinx/lfun/QueryMoney.rst
@@ -0,0 +1,49 @@
+QueryMoney()
+============
+
+FUNKTION
+--------
+::
+
+ int QueryMoney()
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/moneyhandler.c
+
+BESCHREIBUNG
+------------
+::
+
+ Testet, ob ein Spieler, Objekt, Raum oder Npc ueber eine definierte
+ Geldmenge verfuegt, oder nicht.
+
+RUECKGABEWERT
+-------------
+::
+
+ Geldmenge im Besitz des abgefragten Spielers
+
+BEISPIELE
+---------
+::
+
+ int i;
+ i=50+random(10);
+ if(!this_player()->QueryMoney())
+ write("Du besitzt keine Muenzen!\n");
+ if(this_player()->QueryMoney() < i)
+ write("Du besitzt nicht die erforderlichen "+i+" Muenzen.\n");
+
+SIEHE AUCH
+----------
+::
+
+ Geldhandling: AddMoney(L)
+ Zentralbank: PayIn(L), WithDraw(L), _query_current_money(L)
+ Sonstiges: /items/money.c
+
+Last modified: Die, 1. Aug 2000, 16:39:06 by Tilly
+
diff --git a/doc/sphinx/lfun/QueryName.rst b/doc/sphinx/lfun/QueryName.rst
new file mode 100644
index 0000000..0926640
--- /dev/null
+++ b/doc/sphinx/lfun/QueryName.rst
@@ -0,0 +1,44 @@
+QueryName()
+===========
+
+FUNKTION
+--------
+::
+
+ mixed QueryName();
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ DIESE FUNKTION SOLLTE NICHT MEHR BENUTZT WERDEN!
+ Es wird der Inhalt der Property P_NAME zuueckgegeben; dies laesst sich
+ jedoch genau so gut mit QueryProp(P_NAME) bewerkstelligen!
+
+RUeCKGABEWERT
+-------------
+::
+
+ String oder Array von Strings mit dem Namen des Objektes.
+
+SIEHE AUCH
+----------
+::
+
+ QueryProp(), Name(), name(), /std/thing/description.c
+
+
+Last modified: Sat Aug 3 11:21:05 2002 by Vanion
+
diff --git a/doc/sphinx/lfun/QueryOpenMiniQuestsForPlayer.rst b/doc/sphinx/lfun/QueryOpenMiniQuestsForPlayer.rst
new file mode 100644
index 0000000..ab38833
--- /dev/null
+++ b/doc/sphinx/lfun/QueryOpenMiniQuestsForPlayer.rst
@@ -0,0 +1,81 @@
+QueryOpenMiniQuestsForPlayer()
+==============================
+
+FUNKTION
+--------
+::
+
+ mapping QueryOpenMiniQuestsForPlayer(object player)
+
+DEFINIERT IN
+------------
+::
+
+ /secure/questmaster
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion gibt die Liste der offenen Miniquests des Spielers als
+ Mapping zurueck.
+
+ARGUMENTE
+---------
+::
+
+ player - das interessierende Spielerobjekt
+
+RUECKGABEWERTE
+--------------
+::
+
+ Mapping mit der Liste der Miniquests, fuer die das abfragende Objekt
+ zustaendig ist, oder leeres Mapping, wenn der Spieler keine MQs mehr
+ offen hat.
+
+ Die Liste enthaelt die Miniquestnummer als Key. Diesem sind zwei Werte
+ zugeordnet: zum einen ein Miniquest-Aufgabentext, und zum anderen -
+ falls der Spieler eine der Vorbedingungen fuer die Miniquest nicht
+ erfuellt - ein Hinweistext, der Auskunft gibt, welche Bedingung noch
+ zu erfuellen ist ("Seherstatus fehlt"). Diese Hinweistexte entsprechen
+ denen aus check_restrictions() in /std/restriction_checker.c. Der
+ jeweils andere Text wird auf 0 gesetzt.
+
+ Die Struktur des Mappings ist daher folgende:
+ ([ MQ-Nummer : <Aufgabenstellung> ; <Hinderungsgrund> ])
+
+
+
+ Beispiel: ein Spieler hat die Miniquests 18 und 49 noch nicht geloest,
+ erfuellt aber nur fuer Miniquest 49 die Anforderungen. Miniquest 18
+ erfordert den Seherstatus. Dann saehe das Mapping so aus:
+ ([ 18 : 0 ; "Dazu musst Du erst Seher werden.\n",
+ 49 : "Aufgabentext_zu_49" ; 0 ])
+
+ Jedes abfragende Objekt muss daher dieses Mapping zunaecht geeignet
+ auf seinen Inhalt pruefen, um zu ermitteln, welche Meldung jeweils
+ auszugeben ist.
+
+BEMERKUNGEN
+-----------
+::
+
+ Das abfragende Objekt muss von einem Erzmagier oder Gott (z.B. dem
+ zustaendigen Quest-EM) im Questmaster als zugriffsberechtigt bei den-
+ jenigen Miniquests eingetragen sein, fuer die es die entsprechenden
+ Miniquest-Hinweise ausgeben darf. Diese Berechtigung ist mit dem
+ Quest-EM abzustimmen. Anderen Objekten wird ein leeres Mapping zurueck-
+ gegeben.
+
+SIEHE AUCH
+----------
+::
+
+ AddMiniQuest(L), ChangeMiniQuest(L)
+ P_RESTRICTIONS
+ erzmagier
+
+
+Last modified: 6. Juni 2014, Arathorn.
+
diff --git a/doc/sphinx/lfun/QueryOwn.rst b/doc/sphinx/lfun/QueryOwn.rst
new file mode 100644
index 0000000..50e7bdf
--- /dev/null
+++ b/doc/sphinx/lfun/QueryOwn.rst
@@ -0,0 +1,54 @@
+QueryOwn()
+==========
+
+FUNKTION
+--------
+::
+
+ varargs string QueryOwn(int casus)
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+ casus
+ Der Fall fuer die Anrede.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert das dem Anlass entsprechende Possessiv-
+ pronomen fuer den Spieler selber (Dein/Deine).
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ein String mit dem Pronomen.
+
+BEISPIELE
+---------
+::
+
+ printf("%s %s loest sich auf.\n",
+ capitalize(obj->QueryOwn(WER)),obj->name(WER));
+
+ (In den meisten Faellen kann man hier auch direkt "Dein" oder "Deine"
+ einsetzen.)
+
+SIEHE AUCH
+----------
+::
+
+ /std/thing/language.c
+
+
+Last modified: Sun Aug 10 23:55:27 2003 by Mandragon
+
diff --git a/doc/sphinx/lfun/QueryPassengers.rst b/doc/sphinx/lfun/QueryPassengers.rst
new file mode 100644
index 0000000..e87fa45
--- /dev/null
+++ b/doc/sphinx/lfun/QueryPassengers.rst
@@ -0,0 +1,52 @@
+QueryPassengers()
+=================
+
+FUNKTION
+--------
+::
+
+ object *QueryPassengers();
+
+DEFINIERT IN
+------------
+::
+
+ /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion ermittelt die momentan auf dem Transporter befindlichen
+ Passagiere.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Array von Objekten mit den Passagieren.
+
+BEMERKUNGEN
+-----------
+::
+
+ Es werden nur die Passagiere zurueckgegeben, die sich in dem
+ eigentlichen Transporterobjekt befinden! Wenn der Transporter noch um
+ zusaetzliche Raeume vergroessert wird, werden unter Umstaenden nicht
+ alle Passagiere erfasst!
+
+SIEHE AUCH
+----------
+::
+
+ /std/transport.c
+
+
+Last modified: Wed May 8 10:22:48 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryPosition.rst b/doc/sphinx/lfun/QueryPosition.rst
new file mode 100644
index 0000000..2157299
--- /dev/null
+++ b/doc/sphinx/lfun/QueryPosition.rst
@@ -0,0 +1,49 @@
+QueryPosition()
+===============
+
+FUNKTION
+--------
+::
+
+ string *QueryPosition();
+
+DEFINIERT IN
+------------
+::
+
+ /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird ein Array von zwei Strings mit Kennzeichnern der letzten (oder
+ aktuellen) und der naechsten Station im Fahrplan zurueckgegeben.
+
+ Die Kennzeichner sind dabei die ersten Argumente der entsprechenden
+ AddXXX()-Aufrufen, also der Name der Haltestelle bei AddRoute, der Text
+ der Meldung bei AddMsg() und der Name der Funktion bei AddFun().
+
+RUeCKGABEWERT
+-------------
+::
+
+ Array mit zwei Strings. Der erste String gibt den Kennzeichner der
+ momentanen Fahrplanstation an, der zweite String den Kennzeichner der
+ naechsten Fahrplanstation.
+
+SIEHE AUCH
+----------
+::
+
+ AddRoute(), AddMsg(), AddFun(), /std/transport.c
+
+
+Last modified: Wed May 8 10:22:52 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryPossPronoun.rst b/doc/sphinx/lfun/QueryPossPronoun.rst
new file mode 100644
index 0000000..fba61ce
--- /dev/null
+++ b/doc/sphinx/lfun/QueryPossPronoun.rst
@@ -0,0 +1,74 @@
+QueryPossPronoun()
+==================
+
+FUNKTION
+--------
+::
+
+ varargs string QueryPossPronoun(mixed what, int casus, int anzahl);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+ what
+ Geschlecht des Objektes, das besessen wird, oder das Objekt
+ selbst.
+
+ casus
+ Der Fall, in dem das Objekt besessen wird.
+
+ anzahl
+ Handelt es sich um nur ein Objekt oder um mehrere?
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion gibt ein Possessivpronomen zurueck, das das
+ Besitzverhaeltnis eines Objektes zu diesem Objekt anzeigt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Das Possessivpronomen im entsprechenden Fall.
+
+BEMERKUNGEN
+-----------
+::
+
+ what und casus beziehen sich auf das Objekt, welches besessen wird, und
+ nicht auf den Besitzer!!!
+
+BEISPIELE
+---------
+::
+
+ Um eine korrekte Ausgabe beim Haendeklatschen zu erreichen, koennte man
+ zB. folgende Zeile verwenden:
+
+ printf("%s klatscht in %s Haende.\n",this_player()->name(WER),
+ this_player()->QueryPossPronoun(FEMALE, WEN, PLURAL));
+
+ FEMALE, da "die Hand" weiblich ist, WEN, da man im Akkusativ klatscht,
+ und PLURAL, da man dazu beide Haende braucht.
+
+ Ein beliebter Fehler ist es, als Fall WESSEN zu verwenden (in WESSEN
+ Haende klatscht man? => in seine).
+ Die richtige Frage waere aber: WEN klatscht man? (in die Haende)
+
+SIEHE AUCH
+----------
+::
+
+ QueryOwn(), QueryPronoun(), /std/thing/language.c
+
+Last modified: Wed Jan 11 13:13:35 CET 2006 by Rumata
+
diff --git a/doc/sphinx/lfun/QueryPrayRoom.rst b/doc/sphinx/lfun/QueryPrayRoom.rst
new file mode 100644
index 0000000..137335a
--- /dev/null
+++ b/doc/sphinx/lfun/QueryPrayRoom.rst
@@ -0,0 +1,51 @@
+QueryPrayRoom()
+===============
+
+FUNKTION
+--------
+::
+
+ public string QueryPrayRoom()
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/base.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Dies ist der Raum, in den der Spieler nach dem Ende der Todessequenz
+ bewegt wird, d.h. ein Raum, wo er beten kann, um einen neuen Koerper zu
+ erhalten.
+ Der Raum wird als String angegeben (kein Objekt).
+
+ Jede Rasse hat einen Default fuer diese Funktion, welcher mit
+ SetDefaultPrayRoom() gesetzt wird. Dieser Default kann mit der Property
+ P_PRAY_ROOM ueberlagert werden. Wird die Property auf 0 dgesetzt, wird
+ dieser Default aktiv.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der Objektname des Betraums (string)
+
+SIEHE AUCH
+----------
+::
+
+ P_PRAY_ROOM
+ SetDefaultPrayRoom
+
+
+21.05.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/QueryPreferedEnemy.rst b/doc/sphinx/lfun/QueryPreferedEnemy.rst
new file mode 100644
index 0000000..fbf956f
--- /dev/null
+++ b/doc/sphinx/lfun/QueryPreferedEnemy.rst
@@ -0,0 +1,57 @@
+QueryPreferedEnemy()
+====================
+
+FUNKTION
+--------
+::
+
+ object QueryPreferedEnemy();
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+RUeCKGABEWERT
+-------------
+::
+
+ bevorzugter Gegner
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert unter folgenden Bedingungen zufaellig eines
+ der Lebewesen als bevorzugten Gegner zurueck, welche in der
+ Property P_PREFERED_ENEMY in einem Array eingetragen sind:
+ (1) Der erste Eintrag des erwaehnten Propertyarrays enthaelt
+ einen Wert zwischen 0 und 100, der die Wahrscheinlichkeit
+ dafuer angibt, dass ein Lebewesen als Gegner bevorzugt werden
+ soll. Es wird also nicht immer bevorzugt, wenn dort ein Wert
+ kleiner 100 steht! In diesem Fall wird eine 0 zurueckgegeben.
+ (2) Das per Zufall aus den Arrayelementen ab Element 2 gewaehlte
+ Lebewesen muss auch wirklich existieren. Ist dies nicht der
+ Fall, wird das nunmehr leere Element aus dem Array entfernt
+ und eine 0 zurueckgeliefert.
+ (3) Das Lebewesen muss derzeit auch wirklich Feind sein! Ist dies
+ nicht der Fall, wird eine 0 zurueckgegeben.
+ Will man eine andere Bevorzugung von Gegnern erreichen,
+ ueberschreibt man am besten diese Funktion.
+
+SIEHE AUCH
+----------
+::
+
+ SelectEnemy(), IsEnemy(), P_PREFERED_ENEMY
+
+
+Last modified: Wed May 26 16:47:51 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/QueryPronoun.rst b/doc/sphinx/lfun/QueryPronoun.rst
new file mode 100644
index 0000000..2577d05
--- /dev/null
+++ b/doc/sphinx/lfun/QueryPronoun.rst
@@ -0,0 +1,54 @@
+QueryPronoun()
+==============
+
+FUNKTION
+--------
+::
+
+ string QueryPronoun(int casus);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+ casus
+ Der Fall, in dem das Personalpronomen verlangt wird.
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird ein Personalpronomen ("er", "sie", "es") im entsprechenden Fall
+ fuer dieses Objekt berechnet.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Das Pronomen im entsprechenden Fall.
+
+BEISPIELE
+---------
+::
+
+ printf("Du versucht, %s zu nehmen, aber %s ist zu schwer.\n",
+ ob->name(WEN), ob->QueryPronoun(WER));
+
+ Hier wird immer das richtige Pronomen verwendet, egal, welches
+ Geschlecht das Objekt ob hat.
+
+SIEHE AUCH
+----------
+::
+
+ SuggestArticle(), QueryPossPronoun(), /std/thing/language.c
+ QueryOwn()
+
+Last modified: Wed May 8 10:23:14 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/QueryProp.rst b/doc/sphinx/lfun/QueryProp.rst
new file mode 100644
index 0000000..d55316b
--- /dev/null
+++ b/doc/sphinx/lfun/QueryProp.rst
@@ -0,0 +1,63 @@
+QueryProp()
+===========
+
+FUNKTION
+--------
+::
+
+ mixed QueryProp(string name);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/properties.c
+
+ARGUMENTE
+---------
+::
+
+ string name - abzufragende Property
+
+BESCHREIBUNG
+------------
+::
+
+ Der Datenwert der Property 'name' wird zurueckgegeben.
+
+ Existiert eine F_QUERY_METHOD oder eine _query_'name'()-Methode fuer
+ diese Property, so wird diese aufgerufen und ihr 'Value' uebergeben.
+ Eine F_QUERY_METHOD hat dabei Vorrang vor _query_'name'(), d.h.
+ _query_'name'() wird nach erfolgreicher F_QUERY_METHOD nicht mehr
+ gerufen.
+
+ (Diese Methoden nutzen dann Set(), um auf den Datenwert der Property
+ 'name' zurueckzugreifen. Teilweise werden aber auch interne Variablen
+ so oeffentlich gemacht und sind nicht in der ueber Set/Query
+ verfuegbaren Property 'name' abgelegt.)
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der Datenwert der Property.
+ 0, falls diese nicht existiert.
+
+BEISPIELE
+---------
+::
+
+ // wie hoch sind die aktuelle LP des Spielers?
+ hp = this_player()->QueryProp(P_HP);
+
+SIEHE AUCH
+----------
+::
+
+ Aehnliches: SetProp(L), Set(L), Query(L)
+ Generell: SetProperties(L), QueryProperties(L)
+ Konzept: properties, /std/thing/properties.c
+ Sonstiges: P_AUTOLOADOBJ
+
+15.Dez 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/QueryProperties.rst b/doc/sphinx/lfun/QueryProperties.rst
new file mode 100644
index 0000000..eb16392
--- /dev/null
+++ b/doc/sphinx/lfun/QueryProperties.rst
@@ -0,0 +1,54 @@
+QueryProperties()
+=================
+
+FUNKTION
+--------
+::
+
+ mapping QueryProperties()
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/properties.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert ein Mapping mit allen fuer das Objekt
+ definierten Properties zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ein Mapping mit den Properties. Das Mapping hat folgenden Aufbau:
+ ([ name: wert; flags; set_method; query_method,
+ name2: ... ]);
+
+BEMERKUNGEN
+-----------
+::
+
+ - diese Funktion wird von restore_object() und save_object()
+ - F_QUERY_METHODs und _query_'prop'()-Methoden haben keine Auswirkung
+ auf die Wertefelder!
+
+SIEHE AUCH
+----------
+::
+
+ Aehnliches: SetProp(L), QueryProp(L), Set(L), Query(L)
+ Generell: SetProperties(L)
+ Konzept: properties, /std/thing/properties.c
+
+1.Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/QueryQuest.rst b/doc/sphinx/lfun/QueryQuest.rst
new file mode 100644
index 0000000..6ebb184
--- /dev/null
+++ b/doc/sphinx/lfun/QueryQuest.rst
@@ -0,0 +1,54 @@
+QueryQuest()
+============
+
+FUNKTION
+--------
+::
+
+ int QueryQuest(string questname)
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/quests.c
+
+ARGUMENTE
+---------
+::
+
+ questname
+ Questname, wie er im Questmaster eingetragen wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+ (Die Defines fuer den Rueckgabewert finden sich in
+ /secure/questmaster.h)
+ 1 : Spieler hat die Quest bereits geloest (OK)
+ 0 : Ungueltiger Questname oder der Spieler
+ hat die Quest noch nicht. (QQ_KEY_INVALID)
+ 2 : Gaeste koennen keine Quest loesen (QQ_QUEST)
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion kann getestet werden, ob ein Spieler eine
+ bestimmte Quest bereits geloest hat. Als Questname wird dazu
+ der Name angegeben, der im Questmaster eingetragen wurde.
+
+ Wer sich da nicht sicher ist, kann mit dem Questtool
+ (/obj/tools/questtool) nachsehen.
+
+SIEHE AUCH
+----------
+::
+
+ /secure/questmaster.h, /obj/tools/questtool
+ GiveQuest
+
+
+Zuletzt geaendert: Mon, 17. Jul 2000, 12:16:41 von Zook.
+
diff --git a/doc/sphinx/lfun/QueryQuestTime.rst b/doc/sphinx/lfun/QueryQuestTime.rst
new file mode 100644
index 0000000..327c962
--- /dev/null
+++ b/doc/sphinx/lfun/QueryQuestTime.rst
@@ -0,0 +1,49 @@
+QueryQuestTime()
+================
+
+FUNKTION
+--------
+::
+
+ int QueryQuestTime(string questname)
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/quests.c
+
+ARGUMENTE
+---------
+::
+
+ questname
+ Questname, wie er im Questmaster eingetragen wurde.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Questzeitpunkt in Sekunden seit Epoch als positiver Integer-Wert
+ 0 : Tagebuchmaster hat keine Daten in den Logfiles gefunden und
+ macht das auf diese Weise kenntlich
+ -1 : Questzeitpunkt unbekannt
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion kann der Zeitpunkt abgefragt werden, zu
+ dem ein Spieler eine bestimmte Quest geloest hat.
+ Als Questname wird dazu der Name angegeben, der im Questmaster
+ eingetragen ist.
+
+SIEHE AUCH
+----------
+::
+
+ GiveQuest(L), QueryQuest(L), ModifyQuestTime(L)
+
+
+Zuletzt geaendert: 19. Dez. 2015, Arathorn
+
diff --git a/doc/sphinx/lfun/QueryRealAttribute.rst b/doc/sphinx/lfun/QueryRealAttribute.rst
new file mode 100644
index 0000000..5fb0e3b
--- /dev/null
+++ b/doc/sphinx/lfun/QueryRealAttribute.rst
@@ -0,0 +1,47 @@
+QueryRealAttribute()
+====================
+
+FUNKTION
+--------
+::
+
+ int QueryRealAttribute(string attr)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+ attr - das interessierende Attribut
+
+BESCHREIBUNG
+------------
+::
+
+ Das reale Attribut (ohne Offsets) wird zurueckgegeben.
+
+BEISPIELE
+---------
+::
+
+ if(this_player()->QueryRealAttribute(A_INT)>15)
+ write("Du bist auch so ganz schoen clever.\n");
+
+SIEHE AUCH
+----------
+::
+
+ QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+ SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+ SetTimedAttrModifier(), QueryTimedAttrModifier(),
+ DeleteTimedAttrModifier(),
+ P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+ P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/QuerySellValue.rst b/doc/sphinx/lfun/QuerySellValue.rst
new file mode 100644
index 0000000..5f87d55
--- /dev/null
+++ b/doc/sphinx/lfun/QuerySellValue.rst
@@ -0,0 +1,55 @@
+QuerySellValue()
+================
+
+FUNKTION
+--------
+::
+
+ varargs int QuerySellValue(object ob, object client);
+
+DEFINIERT IN
+------------
+::
+
+ /std/trading_price.c
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion kann dazu genutzt werden, den Verkaufspreis in einem
+ Laden global zu veraendern. Sofern dies zugunsten der Spieler geschieht,
+ muss dafuer die Zustimmung des zustaendigen Regionsmagiers und der
+ Balance eingeholt werden. Zudem sollte es nicht in jedem x-beliebigen
+ Laden genutzt werden, sondern nur in recht abgelegenen Gebieten, in
+ die man nicht einfach skripten kann.
+
+ Ein Beispiel ist der Laden auf dem Kutter in Port Vain, der nur in
+ laengeren Intervallen mal zugaenglich ist.
+
+BEISPIEL
+--------
+::
+
+ Ein Laden zahlt 10% ueber dem normalen Verkaufspreis:
+
+ private int sell_factor = 110;
+
+ varargs int QuerySellValue(object ob, object client) {
+ // Es wird nicht naeher geprueft, ob <ob> ein gueltiger Objektpointer
+ // ist, da der Laden selbst sicherstellt, dass das so ist. Wenn
+ // das doch einmal nicht der Fall sein sollte, liegt der Fehler
+ // woanders. Einen Bug auszuloesen ist dann sinnvoll.
+
+ // Basispreis ermitteln
+ int preis = ::QuerySellValue(ob, client);
+ // und den Bonus aufschlagen.
+ preis = (sell_factor * preis)/100;
+
+ // Nicht mehr auszahlen, als das Objekt an sich wert ist.
+ return min(preis, ob->QueryProp(P_VALUE));
+ }
+
+
+LETZTE AENDERUNG: 18-Jun-2015, Arathorn
+
diff --git a/doc/sphinx/lfun/QuerySkill.rst b/doc/sphinx/lfun/QuerySkill.rst
new file mode 100644
index 0000000..cf8ae88
--- /dev/null
+++ b/doc/sphinx/lfun/QuerySkill.rst
@@ -0,0 +1,58 @@
+QuerySkill()
+============
+
+FUNKTION
+--------
+::
+
+ public varargs mapping QuerySkill(string sname, string gilde)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skills.c
+
+
+
+ARGUMENTE
+---------
+::
+
+ string sname Name des abzufragenden Skill
+ string gilde Name der Gilde, unter der der Skill gesucht werden soll
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert das Skillmappings des Skills 'snme' im Lebewesen
+ zurueck. Diese enthaelt Eintraege, die in der Man-Page skill_info_liste
+ beschrieben sind.
+
+ Falls 'gilde' nicht angegeben wird, wird der Skill zuerst fuer die Gilde
+ P_GUILD des Lebewesens gesucht, ansonsten in den allgemeinen Skills
+ "ANY" (es wird NICHT in Gildenobjekt oder Spellbook etwas abgefragt).
+
+RUECKGABEWERT
+-------------
+::
+
+ Ein Mapping mit Skillinfos oder 0, falls der Skill nicht vorhanden ist.
+ Das Mapping ist eine Kopie.
+
+SIEHE AUCH
+----------
+::
+
+ Skills Lernen: LearnSkill, ModifySkill, LimitAbility
+ * Nutzung: UseSpell, UseSkill
+ * Abfragen: QuerySkillAbility
+ * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+ QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+ * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+ * sonstig: spruchermuedung, skill_info_liste
+ * Properties: P_NEWSKILLS
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/QuerySkillAbility.rst b/doc/sphinx/lfun/QuerySkillAbility.rst
new file mode 100644
index 0000000..4679f39
--- /dev/null
+++ b/doc/sphinx/lfun/QuerySkillAbility.rst
@@ -0,0 +1,49 @@
+QuerySkillAbility()
+===================
+
+FUNKTION
+--------
+::
+
+ public varargs int QuerySkillAbility(string sname, string gilde)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skills.c
+
+
+
+ARGUMENTE
+---------
+::
+
+ string sname Name des abzufragenden Skill
+ string gilde Gilde, unter der der Skill gesucht werden soll
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert einen Wert zurueck, der aussagt, wie gut das
+ Lebewesen den Skill 'sname' beherrscht (Key SI_SKILLABILITY im
+ Skillmapping).
+ Dieser Wert kann zwischen -MAX_ABILITY und MAX_ABILITY liegen,
+ normal ist 0 bis MAX_ABILITY (10000 - Skill perfektioniert).
+
+SIEHE AUCH
+----------
+::
+
+ Skills Lernen: LearnSkill, ModifySkill, LimitAbility
+ * Nutzung: UseSpell, UseSkill
+ * Abfragen: QuerySkill
+ * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+ QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+ * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+ * sonstig: spruchermuedung, skill_info_liste
+ * Properties: P_NEWSKILLS
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/QuerySkillAttribute.rst b/doc/sphinx/lfun/QuerySkillAttribute.rst
new file mode 100644
index 0000000..3916290
--- /dev/null
+++ b/doc/sphinx/lfun/QuerySkillAttribute.rst
@@ -0,0 +1,95 @@
+QuerySkillAttribute()
+=====================
+
+FUNKTION
+--------
+::
+
+ public int QuerySkillAttribute(string atrname)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skill_attributes.c
+
+
+
+ARGUMENTE
+---------
+::
+
+ string atrname Name des abzufragenden Attributs
+
+
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion kann man den Wert bestimmter Attribute
+ abfragen, dabei werden das abgefragte Attribut, Todesfolgen,
+ SA_QUALITY und Werte in P_SKILL_ATTRIBUTE_OFFSETS
+ beruecksichtigt.
+
+
+
+ Momentane Skills siehe ModifySkillAttribute.
+
+RUECKGABEWERT
+-------------
+::
+
+ Der Wert des Attributs. Ist nichts bestimmtes gesetzt, wird
+ der Standardwert 100 zurueckgegeben.
+ Der Rueckgabewert liegt zwischen 10 bis 1000 (Prozent).
+
+
+
+BEMERKUNG
+---------
+::
+
+ Die Funktion ist zwar als 'varargs' definiert, gibt man allerdings
+ keinen Attributnamen an, wird immer 100 zurueckgegeben.
+
+
+
+BEISPIEL
+--------
+::
+
+ // ein Spieler kann ein Stueck Kaese stibitzen, wenn er schnell
+ // genug ist ... (15% ueber normal)
+ if(this_player()->QuerySkillAttribute(SA_SPEED)>=115) {
+ tell_object(this_player(),
+ "Du schnappst das Stueck Kaese aus der Falle.\n");
+ obj kaese = clone_object(...);
+ [...]
+ } else {
+ mapping amap=map_indices(VALID_ARMOUR_CLASS,#'!);
+ amap[AT_GLOVE]=100;
+ tell_object(this_player(),
+ "Du bist zu langsam und die Falle schnappt hungrig zu.\n");
+ this_player()->Defend(random(100),
+ ({DT_PIERCE, DT_SQUEEZE}),
+ ([SP_PHYSICAL_ATTACK: 1,
+ SP_REDUCE_ARMOUR: amap,
+ SP_SHOW_DAMAGE: 0]));
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Skills Lernen: LearnSkill, ModifySkill, LimitAbility
+ * Nutzung: UseSpell, UseSkill
+ * Abfragen: QuerySkill, QuerySkillAbility
+ * Modifikation: ModifySkillAttribute,
+ QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+ * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+ * sonstig: spruchermuedung, skill_info_liste
+ * Properties: P_NEWSKILLS
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/QuerySkillAttributeModifier.rst b/doc/sphinx/lfun/QuerySkillAttributeModifier.rst
new file mode 100644
index 0000000..34615c3
--- /dev/null
+++ b/doc/sphinx/lfun/QuerySkillAttributeModifier.rst
@@ -0,0 +1,118 @@
+QuerySkillAttributeModifier()
+=============================
+
+FUNKTION
+--------
+::
+
+ public varargs mapping QuerySkillAttributeModifier(object caster,
+ string *atrnames)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skill_attributes.c
+
+ARGUMENTE
+---------
+::
+
+ <caster> object
+ Objekt, welches die gesuchten Mods gesetzt hat
+
+ <atrnames> string*
+ Array von Skill-Attributen, welche durchsucht werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert alle Mods von <caster> auf den Skill-
+ Attributen <atrnames> in einem Mapping zurueck.
+ Wird <atrnames> nicht angegeben oder ist ein leeres Array, werden alle
+ Skill-Attribute nach Mods abgesucht.
+ Wird <caster> nicht angeben oder ist 0, so werden alle Mods der
+ gewuenschten Skill-Attribute geliefert.
+ Dementsprechend bekommt man alle Mods aller Skill-Attribute, wenn keins
+ von beidem angegeben wird.
+
+RUECKGABEWERT
+-------------
+::
+
+ ([]), falls keine Modifikatoren gefunden wurden.
+ In anderen Faellen ist die Datenstruktur des Mappings wie folgt:
+ ([ atrname1: ([ <caster>: <value>; <duration> ]),
+ atrname2: ([ <caster>: <value>; <duration> ]) ])
+ Die Schluessel im Mapping sind die jeweiligen Skill-Attribute, die Werte
+ des Mappings sind erneut Mappings, welche als Schluessel die Objekte
+ haben, welche die Mods gesetzt haben. In diesem Mapping gehoeren zu jedem
+ Schluessel zwei Werte, den Wert des Modifikators und die Ablaufzeit.
+ <value> kann hierbei ein int oder eine closure sein, <duration> ist ein
+ int, <caster> ist ein Objekt.
+ Ggf. kann das innere Mapping natuerlich auch mehrere Modifikatoren
+ enthalten (also caster1, caster2, usw.).
+
+BEMERKUNGEN
+-----------
+::
+
+BEISPIELE
+---------
+::
+
+ Ein Objekt moechte seinen bestehenden Modifikator um 20 und die
+ Gueltigkeit um 13 erhoehen.
+ mapping res = ob->QuerySkillAttributeModifier(this_object(),
+ ({SA_DAMAGE}) );
+ if (member(res, SA_DAMAGE) && member(res[SA_DAMAGE], this_object())) {
+ // alten Mod ueberschreiben und Werte dabei anheben.
+ ob->ModifySkillAttributeModifier(SA_DAMAGE,
+ res[SA_DAMAGE][this_object(),0] + 20,
+ res[SA_DAMAGE][this_object(),1] + 13 );
+ }
+ else
+ // neuen Mod setzen.
+ ob->ModifySkilAttributeModifier(SA_DAMAGE, 20, 13);
+
+
+
+ Ein Objekt hat den Fluch der unpraezisen Schnelligkeit, welcher SA_DAMAGE
+ reduziert, sofern das Lebewesen einen positiven Modifikator auf SA_SPEED
+ hat:
+ mapping res = ob->QuerySkillAttributeModifier(0, ({SA_SPEED}) );
+ if (member(res, SA_SPEED) {
+ int val, int dur;
+ foreach(object caster, int v, int d: res[SA_SPEED]) {
+ // groessten Mod rausfinden, dabei keine closures
+ // beruecksichtigen.
+ if (intp(v) && v>val) {
+ val=v;
+ dur=d;
+ }
+ }
+ if (val > 0) {
+ // pos. Mod auf SA_SPEED gefunden, entsprechenden neg. Mod auf
+ // SA_DAMAGE setzen, der zum gleichen Zeitpunkt ungueltig wird
+ // wie der Mod auf SA_SPEED.
+ if (ob->ModifySkillAttribute(SA_DAMAGE, -val, dur) == SA_MOD_OK)
+ tell_object(ob, "tolle Fluchmeldung.");
+ }
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Skills Lernen: LearnSkill, ModifySkill, LimitAbility
+ * Nutzung: UseSpell, UseSkill
+ * Abfragen: QuerySkill, QuerySkillAbility
+ * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+ RemoveSkillAttributeModifier
+ * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+ * sonstig: spruchermuedung, skill_info_liste
+ * Properties: P_NEWSKILLS
+
+14.08.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/QuerySkillBonus.rst b/doc/sphinx/lfun/QuerySkillBonus.rst
new file mode 100644
index 0000000..ba19c40
--- /dev/null
+++ b/doc/sphinx/lfun/QuerySkillBonus.rst
@@ -0,0 +1,91 @@
+QuerySkillBonus()
+=================
+
+FUNKTION
+--------
+::
+
+ int QuerySkillBonus(object caster, object target, mapping sinfo)
+
+DEFINIERT IN
+------------
+::
+
+ beliebigen Objekten
+
+ARGUMENTE
+---------
+::
+
+ object caster
+ der Benutzer eines Skills/Spells (Lebewesen)
+ object target
+ das Ziel eines Skills/Spells (beliebiges Objekt oder 0)
+ mapping sinfo
+ das Skillinfomapping
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird von der Gilde des Casters im Environment und ggf.
+ auch im Ziel eines Skills/Spells gerufen.
+ Die Gilde uebergibt neben Caster und Ziel ein Mapping mit Skillinfos (s.
+ SI Konstanten aus new_skills.h fuer Details), welches alle wesentlichen
+ Informationen ueber den benutzten Skill/Spell enthaelt.
+
+ QuerySkillBonus() liefert einen Bonus (oder Malus) zurueck, den der
+ Aufrufer als Faktor in der Berechnung des Effekts des Skills
+ beruecksichtigen kann (aber nicht muss).
+ Der Bonus/Malus wird hierbei als ganzzahliger 0.01-Prozentwert aufgefasst
+ (10000 == 100% == keine Veraenderung, 1 == 0.01%).
+
+ Diese Funktion kann in beliebigen Objekten (re-)definiert werden. Im
+ Falle mobiler Objekte oder anhaltender Effekte ist jedoch eine
+ Balancegenehmigung erforderlich, sofern kampfrelevante Skills beeinflusst
+ werden.
+ Eine flaechendeckende Reduzierung von Skills/Gildenfaehigkeiten ist
+ explizit _nicht_ erwuenscht und soll auf einzelne Raeume und Objekte
+ beschraenkt sein.
+
+BEMERKUNGEN
+-----------
+::
+
+ Das Mapping <sinfo> kann in dieser Funktion geaendert werden. Dieses kann
+ allerdings sehr weitreichende Folgen haben, speziell bei mangelnden
+ Kenntnissen ueber Interna des Skillsystems. Daher bitte von Aenderungen
+ absehen bzw. vorher mit dem jeweiligen Gildenmagier und/oder der
+ Gildenbalance abklaeren.
+ Die Bedeutung der Werte in <sinfo> kann je nach Gilde variieren. Im
+ Zweifelsfall bitte bei den jeweiligen Gildenmagiern nachfragen.
+ Die Gilde kann diese Funktion rufen, muss aber nicht. Ebenso kann sie das
+ Ergebnis beruecksichtigen, muss aber nicht.
+
+BEISPIELE
+---------
+::
+
+ In einem Raum sollen Heilzauber besonders effizient sein:
+ int QuerySkillBonus(object caster, object target, mapping sinfo) {
+ if (pointerp(sinfo[SI_MAGIC_TYPE])
+ && member(sinfo[SI_MAGIC_TYPE], MT_HEILUNG) > -1)
+ {
+ return 12000 + random(3000); // bonus von 120-150%
+ }
+ return 10000;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ gilden-doku
+ <new_skills.h>
+
+LETZTE AeNDERUNG
+----------------
+::
+
+19.08.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/QueryStorageRoom.rst b/doc/sphinx/lfun/QueryStorageRoom.rst
new file mode 100644
index 0000000..f0b9cf7
--- /dev/null
+++ b/doc/sphinx/lfun/QueryStorageRoom.rst
@@ -0,0 +1,27 @@
+QueryStorageRoom()
+==================
+
+QueryStorageRoom()
+
+Funktion
+ string QueryStorageRoom()
+
+Definiert in
+ /std/room/shop
+
+Rueckgabewert
+ Dateiname des Lagers, in dem die aufgekauften Gegenstaende aufbewahrt
+ werden.
+
+Siehe auch
+ Funktionen
+ AddFixedObject(), RemoveFixedObject(), SetStorageRoom(),
+ QueryBuyValue(), QueryBuyFact(), sell_obj(), buy_obj()
+ Properties
+ P_KEEPER, P_MIN_STOCK, P_STORE_CONSUME
+
+
+Letzte Aenderung 21.05.2014, Bugfix
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+::
+
diff --git a/doc/sphinx/lfun/QueryTimedAttrModifier.rst b/doc/sphinx/lfun/QueryTimedAttrModifier.rst
new file mode 100644
index 0000000..b3aa28f
--- /dev/null
+++ b/doc/sphinx/lfun/QueryTimedAttrModifier.rst
@@ -0,0 +1,69 @@
+QueryTimedAttrModifier()
+========================
+
+FUNKTION
+--------
+::
+
+ mapping QueryTimedAttrModifier(string key)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+ key - aus P_TIMED_ATTR_MOD abzufragender Eintrag
+
+BESCHREIBUNG
+------------
+::
+
+ Der zu key gehoerende Eintrag in P_TIMED_ATTR_MOD wird abgefragt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ein leeres Mapping im Falle eines fehlerhaften key-Argumentes oder
+ eines nicht existenten Keys.
+
+
+
+ Ansonsten wird ein Mapping der Form
+
+
+
+ ([
+ Key : ([ Mapping mit den Modifikatoren ]) ;
+ Ablaufzeit ; Ablaufobjekt ; Nachrichtenempfaenger
+ ])
+
+ zurueckgegeben.Die Ablaufzeit ist hierbei die Zeit in Sekunden seit
+ dem 1. Jan 1970, 0.0:0 GMT, das Ablaufobjekt ist das Objekt an dessen
+ Existenz die Attributveraenderungen gebunden ist und der
+ Nachrichtenempfaenger ist dasjenigen Objekte welches im Falle
+ durch den Aufruf von "NotifyTimedAttrModExpired" benachrichtigt
+ wird sobald das Attribut abgelaufen ist.
+ Der Funktion NotifyTimedAttrModExpired wird als Argument der key
+ der abgelaufenen Attributveraenderung uebergeben.
+ Das Mapping ist eine Kopie der Originaldatenstruktur zu diesem Key.
+
+
+
+SIEHE AUCH
+----------
+::
+
+ QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+ SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+ SetTimedAttrModifier(), DeleteTimedAttrModifier(),
+ P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+ P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/QueryTotalQP.rst b/doc/sphinx/lfun/QueryTotalQP.rst
new file mode 100644
index 0000000..1fe7e1d
--- /dev/null
+++ b/doc/sphinx/lfun/QueryTotalQP.rst
@@ -0,0 +1,44 @@
+QueryTotalQP()
+==============
+
+FUNKTION
+--------
+::
+
+ int QueryTotalQP()
+
+DEFINIERT IN
+------------
+::
+
+ /secure/questmaster.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+RUECKGABEWERT
+-------------
+::
+
+ Abenteuerpunkte saemtlicher Quests
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert die Abenteuerpunkte der saemtlicher aktivierter
+ Quests zurueck.
+
+SIEHE AUCH
+----------
+::
+
+ GiveQuest, QueryQuest, /secure/questmaster.h, QueryGroupedKeys,
+ QueryMaxQP, QueryOptQP
+
+
+Zuletzt geaendert: Sam, 25. Nov 2000, 14:04:28 von Zook.
+
diff --git a/doc/sphinx/lfun/QueryUser.rst b/doc/sphinx/lfun/QueryUser.rst
new file mode 100644
index 0000000..d4606c6
--- /dev/null
+++ b/doc/sphinx/lfun/QueryUser.rst
@@ -0,0 +1,79 @@
+QueryUser()
+===========
+
+FUNKTION
+--------
+::
+
+ public object QueryUser()
+
+DEFINIERT IN
+------------
+::
+
+ /std/npc/combat.c
+ /std/clothing/wear.c
+ /std/weapon/combat.c
+ alle Objekte, in denen es darueber hinaus noetig ist
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Liefert den aktuellen Nutzer (Lebewesen) eines Items oder NPCs.
+
+
+
+ Diese Funktion wird z.B. von get_killing_player() benutzt, um
+ herauszufinden, zu welchem Spieler denn das Objekt gehoert, was den
+ toedlichen Schaden verursacht hat.
+
+ Im Falle eines NPCs ist dies standardmaessig der Spieler, bei dem der
+ NPC als Helfer-NPC eingetragen ist (s. RegisterHelperNPC).
+ Im Falle einer Ruestung ist es das Lebewesen, welches sie gerade traegt.
+ Im Falle einer Waffe ist es das Lebewesen, welches sie gerade gezueckt
+ hat.
+ Alle anderen Objekte enthalten keinen Default fuer diese Funktion.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Das nutzende Lebewesen, falls es ermittelt werden konnte, sonst 0.
+
+BEMERKUNGEN
+-----------
+::
+
+ Sollte in allen Objekten definiert werden, welche Lebewesen Schaden
+ zufuegen, ohne dass das verursachende Lebewesen dabei als Feind im
+ Defend() angeben wird.
+ Der gelieferte Nutzer muss explizit kein Spieler sein. Es waere z.B.
+ moeglich, dass von einem Spieler kontrollierter NPC einen Bumerang nutzt.
+
+BEISPIELE
+---------
+::
+
+ Ein von einem Spieler beschworenes Wesen wirft einen Bumerang nach einem
+ Feind.
+ Dann liefert QueryUser() im Bumerang den NPC als Nutzer und
+ QueryUser() im NPC wiederum den Spieler.
+
+
+
+SIEHE AUCH
+----------
+::
+
+ RegisterHelperNPC(), get_killer_player()
+ P_WORN, P_WIELDED
+
+12.11.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/QueryValidObject.rst b/doc/sphinx/lfun/QueryValidObject.rst
new file mode 100644
index 0000000..4e593a9
--- /dev/null
+++ b/doc/sphinx/lfun/QueryValidObject.rst
@@ -0,0 +1,69 @@
+QueryValidObject()
+==================
+
+FUNKTION
+--------
+::
+
+ public int QueryValidObject(string oname);
+
+DEFINIERT IN
+------------
+::
+
+ /std/virtual/v_compiler.c
+
+ARGUMENTE
+---------
+::
+
+ oname
+ Objektname, der geprueft werden soll (kompletter Pfad mit / am Anfang)
+
+RUeCKGABEWERT
+-------------
+::
+
+ <=0 - falls VC nicht zustaendig ist.
+ >0 - falls der VC sich fuer das Objekt zustaendig erklaert.
+
+BESCHREIBUNG
+------------
+::
+
+ Ueber die Funktion laesst sich herausfinden, ob ein VC sich fuer das
+ gewuenschte Objekt zustaendig fuehlt. Dabei wird Validate(),
+ P_COMPILER_PATH, NoParaObjects() und P_PARA im VC ausgewertet:
+ 1. Zuerst wird mit Validate() geprueft, ob der Filename (ohne Pfad) ok ist.
+ 2. wird geguckt, ob das angefragte Objekt im richtigen Pfad liegt
+ (P_COMPILER_PATH).
+ 3. wenn das angefragte Objekt ein Para-Objekt ist:
+ a) wird NoParaObjects() geprueft, wenn das !=0 ist, sind gar keine Para-
+ Objekte erlaubt.
+ b) wird P_PARA _im VC_ abgefragt, dort kann man ein Array aller
+ erlaubten Para-Dimensionen reinschreiben. Fuer alle anderen erklaert
+ sich der VC fuer nicht zustaendig. Wenn P_PARA nicht gesetzt ist,
+ sind alle erlaubt. Ein leeres Array ({}) wuerde einem
+ NoParaObjects() {return 1;} entsprechen.
+
+BEMERKUNGEN
+-----------
+::
+
+ Diese Funktion wird vom move abgefragt. Bitte auf jeden Fall P_PARA oder
+ NoParaObjects() passend definieren, sonst buggts.
+
+ Wenn jemand mit dem oben beschrieben Standardverhalten nicht gluecklich
+ ist, kann man die Funktion passend ueberschreiben.
+
+SIEHE AUCH
+----------
+::
+
+ virtual_compiler
+ CustomizeObject(), Validate(), NoParaObjects(),
+ P_COMPILER_PATH, P_PARA
+ /std/virtual/v_compiler.c
+
+21.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/ReceiveMsg.rst b/doc/sphinx/lfun/ReceiveMsg.rst
new file mode 100644
index 0000000..83941b1
--- /dev/null
+++ b/doc/sphinx/lfun/ReceiveMsg.rst
@@ -0,0 +1,281 @@
+ReceiveMsg()
+============
+
+ReceiveMsg()
+
+public varargs int ReceiveMsg(string msg, int msg_typ, string msg_action,
+ string msg_prefix, mixed origin)
+------------------------------------------------------------------------------------------------------------------------------------------------------
+::
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/comm.c
+ /std/npc/comm.c
+ /std/player/comm.c
+ /std/room/items.c
+
+ARGUMENTE
+---------
+::
+
+ string msg
+ String mit der uebermittelten Nachricht. Muss nicht umgebrochen sein,
+ da ReceiveMsg() das ebenfalls erledigt.
+ int msg_typ
+ Nachrichtentyp(en) fuer Filterung und Flags fuer Behandlung/Umbruch.
+ Siehe unten fuer mit | kombinierbare Konstanten.
+ string msg_action (optional)
+ Ausloesende Aktion, wird auch fuer Ignorieren verwendet.
+ Default ist query_verb(). Siehe unten fuer alternative Konstanten.
+ string msg_prefix (optional)
+ String, welcher ggf. im break_string() als indent verwendet wird.
+ Default ist 0 (kein Indent)
+ mixed origin (<object>) (optional)
+ Das die Meldung ausloesende Objekt, wird fuer Ignorieren verwendet.
+ Default: previous_object()
+
+BESCHREIBUNG
+------------
+::
+
+ ReceiveMsg() wird benutzt, um einem Lebewesen eine Nachricht zu senden.
+ Dabei ruft es das sonst uebliche tell_object() fuer Spieler bzw.
+ catch_tell() im NPC auf.
+
+ Gerade fuer Nachrichten an Spieler bietet die Methode weitere Features,
+ die bisher sonst haendisch zu implementieren waren:
+ 1) Pruefung auf Empfangbarkeit, je nach 'msg_typ', zB
+ MT_LOOK nur an Nichtblinde
+ MT_LISTEN nur an Nichttaube
+ MT_DEBUG nur an Magier/Testspieler
+ 2) Pruefen auf Ignorieren von
+ - Aktion ('msg_action')
+ - mit 'msg_action' || query_verb()
+ - Urheber ('origin')
+ - fuer sendende Spieler mit origin->query_realname()
+ - fuer sendende NPCs mit origin->Name(RAW))
+ 3) Speicherung in der tmhist (Typ MT_COMM)
+ 4) Speicherung im Kobold (Typ MT_COMM + aktiver Kobold)
+ 5) Umbrechen unter Beruecksichtigung von indent, 'msg_typ'-Flags
+ fuer Umbruch und P_PREPEND_BS
+
+ Raeume definieren standardmaessig ebenfalls ein ReceiveMsg(), welches in
+ jedem Objekt im Raum ReceiveMsg() mit den uebergebenen Argumenten aufruft.
+ In diesem Fall ist der Rueckgabe der kleinste von allen gerufenen
+ ReceiveMsg() zurueckgelieferte Wert.
+
+
+
+RUeCKGABEWERT
+-------------
+::
+
+ > 0 fuer Erfolg, < 0 fuer Misserfolg, s.u.
+ MSG_DELIVERED bei erfolgreicher Zustellung
+ MSG_BUFFERED bei Zwischenspeicherung durch den Kobold
+
+ MSG_FAILED nicht naeher spezifizierter Fehler bei Zustellung
+ MSG_IGNORED Nachricht wurde ignoriert (Absender, origin)
+ MSG_VERB_IGN Nachricht wurde ignoriert (Kommandoverb, msg_action)
+ MSG_MUD_IGN Absendendes Mud wurde ignoriert.
+ MSG_SENSE_BLOCK Passende Sinne des Empfaenger sind blockiert (z.B.
+ blind, taub)
+ MSG_BUFFER_FULL Kobold kann sich nichts mehr merken
+
+BEMERKUNGEN
+-----------
+::
+
+ Fuer saemtliche Alternativmeldungen im Falle einer nicht erfolgreich
+ zugestellten Nachricht ist der Aufrufer von ReceiveMsg() verantwortlich.
+
+ NPCs:
+ * ReceiveMsg() ruft zwecks Abwaertskompatibilitaet catch_tell() auf
+ * empfohlen ist, in NPCs nun ReceiveMsg() zu ueberschreiben.
+ * catch_tell() muss weiterhin fuer andere tell_object()
+ ueberschrieben werden
+
+BEISPIELE
+---------
+::
+
+ #1.1 Nachricht an einen Spieler, zB in der Wueste
+ this_player()->ReceiveMsg("Die Sonne brennt dir auf den Kopf.",
+ MT_FEEL|MT_LOOK);
+
+ #1.2 Nachricht an einen Spieler von einem NPC mit Indent
+ // bei aktivem Editor+Kobold landet dieser Text auch im Kobold
+ this_player()->ReceiveMsg("Du haust ja ganz schoen rein!",
+ MT_COMM|MT_FAR|MSG_DONT_STORE,
+ MA_TELL,
+ "Arkshat teilt dir mit: ");
+
+ #1.3 Nachricht an einen Spieler mit Fallback-Kaskade
+ // Achtung, bei MT_COMM oder Ignorieren gibt es natuerlich auch
+ // Misserfolgs-Rueckgaben. Bei einem normalen Kommando wie diesem
+ // hier ist das unproblematisch und daher sinnvoll:
+ if(this_player()->ReceiveMsg(
+ "Du drueckst den Knopf und es oeffnet sich knirschend "
+ "ein kleines Fach in der Wand.", MT_LOOK) < MSG_DELIVERED &&
+ this_player()->ReceiveMsg(
+ "Du drueckst den Knopf und irgend etwas scheint sich "
+ "knirschend zu oeffnen. Das Geraeusch kam von der Wand.",
+ MT_LISTEN) < MSG_DELIVERED) // leider blind UND taub ... also:
+ this_player()->ReceiveMsg(
+ "Du drueckst den Knopf und irgend etwas scheint zu passieren, "
+ "aber leider siehst und hoerst du nichts.", MT_FEEL);
+
+
+ #2.1 Im NPC als Empfaenger auf ein TM reagieren
+ public varargs int ReceiveMsg(string msg, int msg_typ, string msg_action,
+ string msg_prefix, mixed origin) {
+ int ret = MSG_DELIVERED; // Default
+
+ // eine OOC-Kommunikation?
+ if(msg_typ&MT_COMM) {
+ if(strstr(msg, "hilfe")>=0)
+ if(environment(origin)==environment()) {
+ origin->ReceiveMsg("Ich werd dir gleich helfen!",
+ MT_COMM|MSG_DONT_STORE, MA_TELL,
+ "Arkshat teilt dir mit: ");
+ } else {
+ origin->ReceiveMsg("Hilf dir selbst, dann hilft dir Gott!",
+ MT_COMM|MT_FAR|MSG_DONT_STORE,
+ MA_TELL,
+ "Arkshat teilt dir mit: ");
+ }
+ else if(...)
+ [...]
+ } else if(msg_typ&MT_LISTEN && msg_action==MA_SAY) {
+ [...]
+ }
+
+ return ret;
+ }
+
+
+ #3.1 als Sender an viele, Variante mit eigenem filter
+ // Achtung: siehe 3.3. send_room() loest vieles.
+ // Living nickt nur seinen Nichtgegnern zu
+ object *all = filter(all_inventory(environment(this_player())),
+ #'living) - ({this_player()});
+ all -= this_player()->PresentEnemies();
+ all->ReceiveMsg(this_player()->Name()+
+ " nickt dir verstohlen zu und scheint bereit.",
+ MT_LOOK, MA_EMOTE);
+
+ #3.2 als Sender an viele, Variante mit einzelnem Iterieren
+ // Achtung: siehe 3.3. send_room() loest vieles.
+ // Living trinkt etwas, jeder im Raum soll es sehen oder hoeren
+ object ob = first_inventory(environment(this_player()));
+ do {
+ if(living(ob) && ob!=this_player())
+ ob->ReceiveMsg(this_player()->Name()+" trinkt einen Schnaps aus.",
+ MT_LOOK|MT_LISTEN,
+ MA_DRINK);
+ ob = next_inventory(ob);
+ } while(ob);
+
+ #3.3 als Sender an viele, Variante mit send_room
+ // Living gruesst seine Freunde
+ // send_room() ruft ReceiveMsg mit allen entsprechenden Parametern
+ object *exclude = this_player()->PresentEnemies();
+ send_room(this_object(),
+ this_player()->Name()+" gruesst dich.",
+ MT_LOOK|MT_LISTEN,
+ MA_EMOTE,
+ 0,
+ exclude);
+
+ #3.4 als Sender an viele mit send_room und ReceiveMsg()
+ // Living gruesst seine Freunde, seine Feinde sehen das
+ // send_room() ruft ReceiveMsg mit allen entsprechenden Parametern
+ object *exclude = this_player()->PresentEnemies();
+ send_room(this_object(),
+ this_player()->Name()+" gruesst dich.",
+ MT_LOOK|MT_LISTEN, MA_EMOTE, 0, exclude);
+ exclude->ReceiveMessage(
+ this_player()->Name()+" gruesst, aber nicht dich.",
+ MT_LOOK|MT_LISTEN, MA_EMOTE);
+
+KONSTANTEN FUER PARAMETER
+-------------------------
+::
+
+ Saemtlich in "/sys/living/comm.h". Hier nicht notwendigerweise
+ immer aktuell oder vollstaendig.
+
+ <msg_typ>
+ MT_UNKNOWN unspez. Nachrichtentyp (nicht verwenden). Es wird
+ versucht, aufgrund <msg_action> den Typ zu erraten.
+ MT_LOOK alles, was man sieht
+ MT_LISTEN alles, was man hoert
+ MT_FEEL alles, was man fuehlt
+ MT_TASTE alles, was man schmeckt
+ MT_SMELL alles, was man riecht
+ MT_MAGIC alle sonstigen (uebersinnlichen) Wahrnehmungen
+ MT_NOTIFICATION Statusmeldungen, Kommandobestaetigungen
+ MT_COMM alle OOC-Kommunikation, d.h. nicht durch o.g. Sinne
+ abgedeckt.
+ MT_FAR alles, was aus der Ferne / einem anderen Raum kommt.
+ muss mit min. einem anderen Typ kombiniert werden
+ MT_DEBUG Debugmeldungen, sehen nur Magier im Magiermodus
+ MT_NEWS Mails & MPA
+
+ MSG_DONT_BUFFER Nachricht darf nicht im Kobold gespeichert werden
+ MSG_DONT_STORE Nachricht darf nicht in die Comm-History
+ MSG_DONT_WRAP Nachricht nicht per break_string umbrechen
+ MSG_DONT_IGNORE Nachricht kann nicht ignoriert werden
+
+ MSG_BS_LEAVE_LFS wie BS_LEAVE_MY_LFS fuer break_string()
+ MSG_BS_SINGLE_SPACE wie BS_SINGLE_SPACE fuer break_string()
+ MSG_BS_BLOCK wie BS_BLOCK fuer break_string()
+ MSG_BS_NO_PARINDENT wie BS_NO_PARINDENT fuer break_string()
+ MSG_BS_INDENT_ONCE wie BS_INDENT_ONCE fuer break_string()
+ MSG_BS_PREP_INDENT wie BS_PREPEND_INDENT fuer break_string()
+
+ <msg_action> (optional)
+ MA_UNKNOWN Unspez. Aktion. Es wird der Default query_verb()
+ benutzt bzw. versucht, die Aktion zu erraten.
+ MA_PUT Jemand legt etwas hin und gibt jemanden etwas
+ MA_TAKE Jemand nimmt etwas
+ MA_MOVE_IN Jemand betritt den Raum
+ MA_MOVE_OUT Jemand verlaesst den Raum
+ MA_MOVE Jemand bewegt sich
+ MA_FIGHT Jemand kaempft
+ MA_WIELD Jemand zueckt eine Waffe
+ MA_UNWIELD Jemand steckt eine Waffe weg
+ MA_WEAR Jemand zieht etwas an
+ MA_UNWEAR Jemand zieht etwas aus
+ MA_EAT Jemand isst etwas
+ MA_DRINK Jemand trinkt etwas
+ MA_SPELL Jemand wirkt einen Spell
+ MA_LOOK Jemand sieht etwas an, untersucht etwas
+ MA_LISTEN Jemand horcht oder lauscht an etwas
+ MA_FEEL Jemand betastet etwas
+ MA_SMELL Jemand schnueffelt herum
+ MA_SENSE Jemand macht eine uebersinnliche Wahrnehmung
+ MA_READ Jemand liest etwas
+ MA_USE Jemand benutzt etwas
+ MA_SAY Jemand sagt etwas
+ MA_REMOVE Etwas verschwindet
+ // MA_CHAT Chatkrams (z.B. teile-mit, Teamkampfchat)
+ MA_CHANNEL Ebenen
+ MA_EMOTE (r)Emotes, Soulverben (remotes mit Typ MT_COMM|MT_FAR)
+ MA_SHOUT Rufen (nicht: shout()!)
+ MA_SHOUT_SEFUN Rufen ueber shout(SE)
+
+SIEHE AUCH
+----------
+::
+
+ Verwandt: send_room(SE)
+ Lfuns: TestIgnore(L)
+ Efuns: tell_object(E), catch_tell(L), catch_msg(L)
+ query_verb(E), query_once_interactive(E), break_string(SE)
+
+13.03.2016, Zesstra
+
diff --git a/doc/sphinx/lfun/RegisterEvent.rst b/doc/sphinx/lfun/RegisterEvent.rst
new file mode 100644
index 0000000..c104127
--- /dev/null
+++ b/doc/sphinx/lfun/RegisterEvent.rst
@@ -0,0 +1,116 @@
+RegisterEvent()
+===============
+
+FUNKTION
+--------
+::
+
+ int RegisterEvent(string eid, string fun, object listener);
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/eventd.c
+
+DEKLARIERT IN
+-------------
+::
+
+ /sys/events.h
+
+ARGUMENTE
+---------
+::
+
+ string eid,
+ Die ID des Events, fuer den man sich registrieren will. Da dieser
+ String fuer alle Events jeweils eindeutig sein muss, empfiehlt es sich,
+ fuer eigene Events z.B. als Praefix den eigenen Magiernamen zu nehmen,
+ z.B. "zesstra_vulkanausbruch".
+ ACHTUNG: IDs, die mit '_evt_lib_' beginnen, sind AUSSCHLIESSLICH der
+ Mudlib vorbehalten!
+ string fun,
+ Name der Funktion, die im Objekt listener bei Auftreten des Events
+ gerufen werden soll.
+ object listener,
+ Das Objekt, das als Lauscher fuer diesen Event registriert werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Das Objekt 'listener' wird als Lauscher dieses Events registriert. Ab
+ diesem Moment wird immer dann, wenn ein Event mit der ID 'eid' ausgeloest
+ wird, in 'listener' die Funktion 'fun' aufgerufen (zeitverzoegert, meist
+ 0-2s).
+
+
+
+ Die Funktion wird dabei immer mit 3 Argumenten aufgerufen:
+ listener->fun(eid, triggerob, data);
+ Hierbei ist 'eid' die jeweilige Event-ID und 'triggerob' ist das Objekt,
+ welches den Event ausloeste.
+ 'data' kann jeder LPC-Datentyp sein und enthaelt die Daten, die das
+ triggernde Objekt an alle Listener uebermitteln will (damit sind Datentyp
+ und Inhalt komplett abhaengig vom Event!)
+
+ Existiert bisher noch kein Event mit der ID 'eid', wird implizit ein
+ neuer Event erstellt, der erstmal nur das sich gerade registrierende
+ Objekt als Lauscher hat.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 fuer Erfolg, <=0 fuer Misserfolg.
+ 1 - Erfolg, 'listener' wurde eingetragen.
+ -1 - falsche Argumente wurden uebergeben
+ -2 - nicht-oeffentlicher Event und 'listener' wurde nicht fuer diesen
+ Event freigegeben (momentan gibt es noch keine nicht-oeffentlichen
+ Events)
+ -3 - 'fun' in 'listener' ist nicht vorhanden oder nicht von aussen
+ aufrufbar (protected, static, private).
+
+
+
+BEMERKUNGEN
+-----------
+::
+
+ Wenn 'listener' bereits fuer den Event registriert wird, wird die alte
+ Registrierung ueberschrieben (als ggf. gilt dann der jetzt uebergebene
+ Funktionsname).
+ Die Funktion 'fun' sollte sparsam mit den Eval-Ticks umgehen. Momentan
+ ist die max. Menge an Ticks auf 30000 beschraenkt. Dies kann bei
+ Problemen auch jederzeit reduziert werden!
+ Der EVENTD merkt sich Event-Lauscher nicht ueber Reboots hinaus.
+ Sollte sich eine Blueprint anmelden, sich zerstoeren und neugeladen
+ werden, ist die neue Blueprint noch angemeldet, weil das neue Objekt
+ unter dem alten Namen wiedergefunden wird. Dies gilt _nicht_ fuer
+ Clones!
+
+BEISPIELE
+---------
+::
+
+ 1. Ein Objekt moechte ueber Spielertode informiert werden:
+ EVENTD->RegisterEvent(EVT_LIB_PLAYER_DEATH, "spieler_ist_tot",
+ this_object());
+ Ab jetzt wird im Objekt jedes Mal, wenn ein Spieler stirbt, die
+ Funktion "spieler_ist_tot" aufgerufen.
+
+ 2. Ein Objekt will informiert werden, wenn der Event
+ "boing_zwergenkoenig_angriff" ausgeloest wird:
+ EVENTD->RegisterEvent("boing_zwergenkoenig_angriff","alarm",
+ this_object());
+
+SIEHE AUCH
+----------
+::
+
+ events, eventd, UnregisterEvent(), TriggerEvent()
+
+
+Last modified: 15.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/RegisterHelperNPC.rst b/doc/sphinx/lfun/RegisterHelperNPC.rst
new file mode 100644
index 0000000..f5f2e7a
--- /dev/null
+++ b/doc/sphinx/lfun/RegisterHelperNPC.rst
@@ -0,0 +1,114 @@
+RegisterHelperNPC()
+===================
+
+FUNKTION
+--------
+::
+
+ public int RegisterHelperNPC(object npc, int flags);
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/combat.c
+ /sys/living/combat.h
+
+ARGUMENTE
+---------
+::
+
+ object npc
+ Objekt des helfenden NPC, der angemeldet werden soll.
+
+ int flags
+ ver-oder-te Konstanten, die die Art des Helfer-NPC beschreiben (s.u.)
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion wird ein einem Spieler helfender NPC im Spieler
+ angemeldet. Hierdurch kann spaeter herausgefunden werden, welche NPC
+ einem Spieler helfen und ggf. den von diesen verursachten Schaden im
+ Kampf dem Spieler zuzurechnen.
+
+ Die Flags sind eine der folgenden Konstanten oder eine beliebige durch
+ ver-oder-ung gebildete Kombination.
+
+ Momentan gibt es 2 Klassen von Helfer-NPC:
+ + GUILD_HELPER: der Helfer-NPC ist ein Gilden-NPC
+ + MISC_HELPER: der Helfer-NPC ist irgendein NPC, der nicht zu einer Gilde
+ gehoert.
+
+ Zusaetzlich zu den Klassen gibt es noch weitere Flags, die etwas ueber
+ den Helfer-NPC sagen:
+
+ + EXCLUSIVE_HELPER: dieser Helfer-NPC duldet keinen weiteren NPC der
+ gleichen Klasse.
+ + ACTIVE_HELPER: ist dieses Flag gesetzt, ist der NPC mehr als nur reiner
+ Schlagfaenger.
+
+ Wird EXCLUSIVE_HELPER gesetzt und es ist in der gleichen Klasse schon ein
+ NPC angemeldet, schlaegt die Registrierung fehl.
+ Ist in der gleichen Klasse bereits ein NPC mit EXCLUSIVE_HELPER
+ angemeldet, schlaegt die Registierung ebenfalls fehl, auch wenn der neue
+ NPC kein EXCLUSIVE_HELPER setzt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn die Registrierung erfolgreich war.
+ 0 sonst. In diesem Fall darf der NPC dem Spieler NICHT helfen, weder
+ passiv (Schlagfaenger), noch aktiv.
+
+BEMERKUNGEN
+-----------
+::
+
+ Diese Funktion setzt bei der Erfolg die Property P_HELPER_NPC in <npc>
+ auf passende Werte.
+ Bitte auf gar keinen Fall die numerischen Werte der Konstanten fuer
+ <flags> nutzen, diese koennen sich jederzeit aendern.
+
+BEISPIELE
+---------
+::
+
+ 1. Ein nicht-exklusiver Gilden-NPC, der dem Spieler folgt.
+ if (spieler->RegisterHelperNPC(this_object(), GUILD_HELPER) == 1) {
+ move(environment(spieler), M_GO);
+ spieler->AddPursuer(this_object());
+ // meldung ausgebene...
+ }
+
+ 2a. Ein exklusiver Nicht-Gilden-NPC
+ if (spieler->RegisterHelperNPC(this_object(),
+ MISC_HELPER|EXCLUSIVE_HELPER) == 1) {
+ move(environment(spieler), M_GO);
+ }
+
+ 2b. Ein nicht-exklusiver Nicht-Gilde-NPC, der nach 2a. kommt.
+ if (spieler->RegisterHelperNPC(this_object(), MISC_HELPER) == 1) {
+ // ... wenn der NPC aus 2a noch existiert, trifft dies hier nie zu.
+ }
+
+ 3. Ein exklusiver NPC, der weitere Gilden- und sonstige NPC ausschliesst
+ (Solche Kombination bitte mit der Gilden-Balance abstimmen.)
+ if (spieler->RegisterHelperNPC(this_object(),
+ MISC_HELPER|GUILD_HELPER|EXCLUSIVE_HELPER) == 1) {
+ move(environment(spieler), M_GO);
+ }
+
+ 4. Die Registrierung ohne Klasse schlaegt fehl, z.B.:
+ spieler->RegisterHelperNPC(this_object(), 0);
+ spieler->RegisterHelperNPC(this_object(), EXCLUSIVE_HELPER);
+
+SIEHE AUCH
+----------
+::
+
+ UnregisterHelperNPC()
+ P_HELPER_NPC
+
diff --git a/doc/sphinx/lfun/RegisterHelperObject.rst b/doc/sphinx/lfun/RegisterHelperObject.rst
new file mode 100644
index 0000000..2d0def4
--- /dev/null
+++ b/doc/sphinx/lfun/RegisterHelperObject.rst
@@ -0,0 +1,145 @@
+RegisterHelperObject()
+======================
+
+FUNKTION
+--------
+::
+
+ int RegisterHelperObject(object helper, int type,
+ string|closure callback);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/helpers.c
+
+ARGUMENTE
+---------
+::
+
+ object helper
+ Das Objekt, das bei einem Lebewesen als Hilfsobjekt registriert
+ werden soll. Das Objekt muss sich dazu nicht im Inventar des
+ Lebewesens befinden.
+ int type
+ Helfertyp, einer der in /sys/living/helpers.h definierten Typen:
+ - HELPER_TYPE_AERIAL fuer die Flug-/Segelunterstuetzung
+ - HELPER_TYPE_AQUATIC fuer Tauchunterstuetzung
+ string|closure callback
+ Closure oder Funktionsname als String; dies ist die Funktion, die im
+ Objekt helper gerufen wird, um abzufragen, ob es sich aktuell fuer
+ zustaendig erklaert oder nicht.
+
+BESCHREIBUNG
+------------
+::
+
+ Das Objekt "helper" wird als Hilfsobjekt fuer bestimmte Aktivitaeten wie
+ zum Beispiel Fliegen oder Tauchen registriert.
+
+
+
+ Die als Callback uebergebene Funktion wird bei der Abfrage der
+ P_*_HELPERS-Properties (siehe unten) aufgerufen und deren
+ Rueckgabewert in der Property vermerkt.
+
+
+
+ Der Rueckgabewert der Callback-Methode muss im Wertebereich
+ 0..10000 liegen, wobei ein Wert von 0 bedeutet, dass das Hilfsobjekt
+ sich gerade nicht zustaendig fuehlt. Bei den Werten >0 ist es dem
+ abfragenden Objekt ueberlassen, wie es diese Daten bewertet.
+
+ Die Funktion muss existieren und public sein, d.h. von aussen gerufen
+ werden koennen.
+
+
+
+ Die Funktion bekommt das Spielerobjekt und das abfragende Objekt als
+ Parameter uebergeben.
+
+HINWEIS
+-------
+::
+
+ Es ist ein Unterschied, ob sich ein Objekt via UnregisterHelperObject()
+ als Helfer austraegt, oder ob der Aufruf der Callback-Funktion eine
+ 0 zurueckgibt. Im letzteren Fall ist das Objekt nach wie vor
+ registriert und kann trotzdem vom abfragenden Objekt als
+ funktionsfaehig angesehen werden.
+
+RUECKGABEWERTE
+--------------
+::
+
+ 1 Objekt wurde erfolgreich registriert (HELPER_SUCCESS)
+ -1 angegebenes Hilfsobjekt existiert nicht (HELPER_NO_CALLBACK_OBJECT)
+ -2 angegebenes Hilfsobjekt ist bereits fuer diese Art der
+ Unterstuetzung registriert (HELPER_ALREADY_LISTED)
+
+BEISPIELE
+---------
+::
+
+ a) Eine luftgefuellte Blase will sich als Tauch-Helfer am Spieler
+ anmelden und ist zustaendig, solange sich noch Luft in ihr befindet:
+
+ int luft = 5; // globale Variable z.B. fuer Luftinhalt von 5 Atemzuegen
+
+ // Registrierung im Spielerobjekt
+ if ( TP->RegisterHelperObject(ME, HELPER_TYPE_AQUATIC,
+ "DivingCallback") == HELPER_SUCCESS ) {
+ tell_object(TP, "Du kannst jetzt mit Hilfe der Luftblase unter Wasser "
+ "atmen.\n");
+ }
+
+ // hier koennen natuerlich auch noch komplexere Dinge ablaufen, z.B.
+ // wenn ein Wert zurueckgegeben werden soll, der nicht nur 0 oder 1 ist.
+ public int DivingCallback(object player, object caller) {
+ return (environment(ME)==player && luft>0);
+ }
+
+ b) Ein Spieler befindet sich in einem Raum mit einem steilen Abhang, den
+ man hinunterspringen kann. Dies geht aber nur dann gefahrlos, wenn es
+ Hilfsobjekte gibt, die den (Segel)flug erlauben:
+
+ // cmd_springen() sei die Funktion, die bei der Eingabe des Befehls durch
+ // den Spieler aufgerufen wird.
+ static int cmd_springen(string str) {
+ [...]
+ // Property abfragen
+ mapping helpers = TP->QueryProp(P_AERIAL_HELPERS);
+ // Liste der Werte fuer die einzelnen Unterstuetzungsobjekte ermitteln
+ int *values = m_values(helpers,0);
+ // Spieler schonmal runterbewegen, die Folgen seines Handelns spuert
+ // er dann, wenn er unten angekommen ist.
+ TP->move(zielraum, M_GO|M_SILENT);
+ // "helpers" ist immer ein Mapping, das pruefen wir nicht extra.
+ // Wenn die Liste der Objekte noch mindestens ein Element enthaelt,
+ // nachdem alle unzustaendigen Hilfsobjekte (Rueckgabewert der
+ // Callback-Funktion == 0) rausgerechnet wurden, existiert mindestens
+ // ein geeignetes Hilfsobjekt.
+ if ( sizeof(values-({0})) ) {
+ tell_object(TP, "Sanft segelst Du den Hang hinab.\n");
+ }
+ else {
+ tell_object(TP, BS("Todesmutig springst Du den Hang hinab und "
+ "schlaegst hart unten auf. Du haettest vielleicht daran denken "
+ "sollen, Dir geeignete Hilfsmittel fuer so eine Aktion zu "
+ "besorgen.");
+ TP->Defend(800, ({DT_BLUDGEON}), ([SP_NO_ACTIVE_DEFENSE:1]), ME);
+ }
+ return 1;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Funktionen: UnregisterHelperObject()
+ Properties: P_HELPER_OBJECTS, P_AERIAL_HELPERS, P_AQUATIC_HELPERS
+ Sonstiges: /sys/living/helpers.h
+
+05.02.2015 Arathorn
+
diff --git a/doc/sphinx/lfun/RemoveAdjective.rst b/doc/sphinx/lfun/RemoveAdjective.rst
new file mode 100644
index 0000000..28843be
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveAdjective.rst
@@ -0,0 +1,44 @@
+RemoveAdjective()
+=================
+
+FUNKTION
+--------
+::
+
+ void RemoveAdjective(string|string* adj);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ adj
+ String oder Array von String mit den Adjektiven.
+
+BESCHREIBUNG
+------------
+::
+
+ Falls einige der vorhandenen Adjektive nicht mehr verwendet werden
+ sollen, koennen sie mit dieser Funktion entfernt werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ AddAdjective(), RemoveId(), /std/thing/description.c
+
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveClass.rst b/doc/sphinx/lfun/RemoveClass.rst
new file mode 100644
index 0000000..c6ad24d
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveClass.rst
@@ -0,0 +1,39 @@
+RemoveClass()
+=============
+
+FUNKTION
+--------
+::
+
+ void RemoveClass(string|string* class);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ string/string* class - String oder Stringarray der Klasse(n)
+
+BESCHREIBUNG
+------------
+::
+
+ Dem Objekt werden einige der mit AddClass() gesetzten Klassen wieder
+ entzogen.
+ Die allgemein verfuegbaren Klassen sind unter /sys/class.h definiert.
+
+SIEHE AUCH
+----------
+::
+
+ AddClass(), is_class_member()
+ P_CLASS
+
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveCmd.rst b/doc/sphinx/lfun/RemoveCmd.rst
new file mode 100644
index 0000000..ddb6c45
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveCmd.rst
@@ -0,0 +1,91 @@
+RemoveCmd()
+===========
+
+RemoveCmd(L)
+------------
+::
+
+FUNKTION
+--------
+::
+
+ varargs int RemoveCmd(mixed cmd, int norule, mixed id)
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/commands.c
+
+ARGUMENTE
+---------
+::
+
+ com
+ String oder Array von Strings mit den zu entfernenden Kommandos.
+ norule
+ Kommandos mit Regeln werden nicht entfernt (ausser bei cmd==0)
+ id
+ eine ID, mit der man ein vorher mit dieser ID gespeichertes
+ Kommando eindeutig lvschen kann
+
+BESCHREIBUNG
+------------
+::
+
+ Mit AddCmd() hinzugefuegte Kommandos koennen mit diesem Befehl wieder
+ abgemeldet werden. Die entfernten Kommandos sind direkt nach dem
+ RemoveCmd()-Aufruf nicht mehr ansprechbar.
+
+ Wird ein Regelstring angegeben, so wird die identische AddCmd-
+ Regel entfernt.
+
+BEMERKUNGEN
+-----------
+::
+
+ Uebergibt man fuer com eine 0, so werden alle definierten Kommandos
+ entfernt!
+
+RUECKGABEWERT
+-------------
+::
+
+ Anzahl der entfernten Kommandos.
+
+BEISPIELE
+---------
+::
+
+ (1) AddCmd("test");
+ (2) AddCmd("test|teste&mit¶meter");
+ (3) AddCmd(({"test"}),1);
+ (4) AddCmd("test",0,0,"XYZ");
+ (5) AddCmd("test&mit¶meter",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¶meter"
+ RemoveCmd("test|teste&mit¶meter"
+ - entfernt (2)
+ RemoveCmd("test",0,"XYZ");
+ - entfernt (4) und (5)
+ RemoveCmd("test",1,"XYZ");
+ - entfernt (4), nicht (5)
+ RemoveCmd(0,0,"XYZ");
+ - entfernt (4) und (5)
+
+SIEHE AUCH
+----------
+::
+
+ AddCmd(L), AddCmd_bsp
+ Sonstiges: replace_personal(E), enable_commands(E), init(E)
+ Alternativen: AddAction(L), add_action(E)
+
+24.Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/RemoveDefender.rst b/doc/sphinx/lfun/RemoveDefender.rst
new file mode 100644
index 0000000..911e0c5
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveDefender.rst
@@ -0,0 +1,53 @@
+RemoveDefender()
+================
+
+FUNKTION
+--------
+::
+
+ void RemoveDefender(object friend);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ friend
+ Objekt (normal Lebewesen), welches zukuenftig nicht mehr ueber
+ Angriffe informiert werden soll und diese auch nicht mehr abwehrt.
+
+BESCHREIBUNG
+------------
+::
+
+ Ein Lebewesen, welches angegriffen wird, kann andere Objekte ueber
+ einen solchen Angriff per InformDefend() informieren oder ihnen
+ sogar die Moeglichkeit geben, per DefendOther() direkt in den
+ laufenden Angriff einzugreifen (Schaeden abwehren oder umwandeln).
+ Im Normalfall handelt es sich hierbei um andere Lebewesen, welche
+ als Verteidiger des angegriffenen Lebewesens auftreten: Daher der
+ Name der Funktion. Ausserdem besteht die Einschraenkung, dass diese
+ Objekte in der gleichen Umgebung sein muessen, wie das zu
+ verteidigende Lebewesen.
+ Die Objekte sind in Form eines Arrays in der Property P_DEFENDERS
+ abgespeichert und koennen dort abgerufen werden. Natuerlich kann
+ man alte Objekte direkt dort loeschen, jedoch sollte man die
+ hierfuer bereitgestellte Funktionen RemoveDefender() verwenden.
+ Zum Hinzufuegen von Eintraegen im Array steht ebenfalls eine
+ Funktion bereit: AddDefender().
+
+SIEHE AUCH
+----------
+::
+
+ AddDefender(), InformDefend(), DefendOther(),
+ P_DEFENDERS, /std/living/combat.c
+
+
+Last modified: Thu Jul 29 18:48:45 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/RemoveDetail.rst b/doc/sphinx/lfun/RemoveDetail.rst
new file mode 100644
index 0000000..889ac20
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveDetail.rst
@@ -0,0 +1,80 @@
+RemoveDetail()
+==============
+
+FUNKTION
+--------
+::
+
+ void RemoveDetail(mixed *keys);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ keys
+ String oder Array von Strings mit den zu entfernenden Details.
+
+BESCHREIBUNG
+------------
+::
+
+ Entfernt die in <keys> angegebenen Details aus der Liste der
+ vorhandenen Details. Uebergibt man fuer <keys> eine 0, so werden
+ saemtliche Details entfernt!
+
+BEISPIEL
+--------
+::
+
+ Ein kleines Beispiel, bei dem eine Oeffnung erscheint und wieder
+ verschwindet, je nachdem, ob man eine Luke oeffnet oder schliesst.
+ int oeffneLuke(string str);
+ int schliesseLuke(string str);
+ ...
+ AddCmd("oeffne", #'oeffneLuke);
+ AddCmd("schliesse", #'schliesseLuke);
+ ...
+ int oeffneLuke(string str) {
+ if(str!="luke" || GetDetail("oeffnung"))
+ return 0;
+ AddDetail("oeffnung","Du siehst eine kleine Oeffnung.\n");
+ return 1;
+ }
+
+ int schliesseLuke(string str) {
+ if(str!="luke" || !GetDetail("oeffnung"))
+ return 0;
+ RemoveDetail("oeffnung"); // Detail wieder entfernen
+ return 1;
+ }
+
+BEMERKUNGEN
+-----------
+::
+
+ Da intern Details und SpecialDetails im gleichen Mapping verwaltet
+ werden, lassen sich mit dieser Funktion auch SpecialDetails
+ entfernen.
+ Die Funktion RemoveSpecialDetail() sollte also nicht genutzt werden!
+
+SIEHE AUCH
+----------
+::
+
+ Setzen: AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+ AddTouchDetail()
+ Loeschen: RemoveReadDetail(), RemoveSmells(),
+ RemoveSounds(), RemoveTouchDetail()
+ Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS,
+ P_TOUCH_DETAILS, P_SPECIAL_DETAILS
+ Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+ Sonstiges: GetDetail(), break_string()
+
+8. Juli 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/RemoveExit.rst b/doc/sphinx/lfun/RemoveExit.rst
new file mode 100644
index 0000000..aa51cbc
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveExit.rst
@@ -0,0 +1,49 @@
+RemoveExit()
+============
+
+FUNKTION
+--------
+::
+
+ void RemoveExit(string|string* cmd);
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/exits
+
+ARGUMENTE
+---------
+::
+
+ string/string* cmd
+ Richtung(en), die entfernt werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+ Die in cmd angegebenen Ausgaenge werden wieder entfernt.
+
+ Ist cmd = 0, so werden alle Ausgaenge entfernt.
+
+BEMERKUNGEN
+-----------
+::
+
+ Ausgaenge werden an der gleichen Stelle gespeichert:
+ - RemoveExit() greift auf die gleichen Daten wie RemoveSpecialExit()
+ zu, entfernt also auch spezielle Ausgaenge!
+
+SIEHE AUCH
+----------
+::
+
+ AddExit(), AddSpecialExit(), GetExits()
+ RemoveSpecialExit(),
+ H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
+ ausgaenge
+
+31.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveExtraLook.rst b/doc/sphinx/lfun/RemoveExtraLook.rst
new file mode 100644
index 0000000..28ffc6b
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveExtraLook.rst
@@ -0,0 +1,65 @@
+RemoveExtraLook()
+=================
+
+RemoveExtraLook()
+
+int RemoveExtraLook(string look);
+----------------------------------------------------
+::
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/description.c
+
+BESCHREIBUNG
+------------
+::
+
+ Der Extralook erscheint in der Langbeschreibung des Lebewesens.
+ Eintraege koennen mit dieser Funktion (vorzeitig) wieder entfernt werden.
+
+ARGUMENTE
+---------
+::
+
+ - string look:
+ Schluesselwort, unter dem der Eintrag, den man entfernen moechte, von
+ AddExtraLook() registriert wurde.
+
+RUECKGABEWERTE
+--------------
+::
+
+ > 0, falls der Eintrag erfolgreich entfernt wurde.
+ < 0 sonst.
+ -1: keinen (gueltigen) <key> uebergeben.
+ -2: kein Eintrag fuer <key> gefunden.
+
+BEMERKUNGEN
+-----------
+::
+
+ Beim Entfernen mit dieser Funktion wird die "Endemeldung" des entfernten
+ Eintrages nicht ausgegeben.
+
+BEISPIELE
+---------
+::
+
+ # Extralook registrieren.
+ living->AddExtraLook("@WER1 wird von einer Horde Daemonen verfolgt.",
+ "ennox_daemonenhordenverfolgerlook");
+ # Nun kann der Eintrag auch wieder entfernt werden:
+ living->RemoveExtraLook("ennox_daemonenhordenverfolgerlook");
+
+SIEHE AUCH
+----------
+::
+
+ AddExtraLook(),
+ P_INTERNAL_EXTRA_LOOK
+
+14.05.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveFixedObject.rst b/doc/sphinx/lfun/RemoveFixedObject.rst
new file mode 100644
index 0000000..586cd05
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveFixedObject.rst
@@ -0,0 +1,63 @@
+RemoveFixedObject()
+===================
+
+FUNKTION
+--------
+::
+
+ void RemoveFixedObject(string filename);
+
+DEFINIERT IN
+------------
+::
+
+ /std/laden.c
+
+ARGUMENTE
+---------
+::
+
+ str
+ Dateiname des Objektes, welches nicht mehr dauerhaft im Laden sein
+ soll.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BESCHREIBUNG
+------------
+::
+
+ Objekte, die mittels der Funktion AddFixedObject() im Laden
+ eingebunden werden, sind dort staendig verfuegbar. Um diesen Zustand
+ wieder aufzuheben, kann man sie mittels dieser Funktion wieder
+ entfernen. Eventuell im Lager befindliche Objekte dieser Art werden
+ hierbei nicht zerstoert und koennen durchaus noch gekauft werden,
+ bis sie alle sind. Danach gibt es sie dort nicht mehr!
+
+BEISPIELE
+---------
+::
+
+ Im allen Laeden gibt es schon ein Objekt, welches dort
+ standardmaessig erhaeltlich ist. Folgende Zeile sorgt dafuer:
+ AddFixedObject("/obj/boerse",80,({"boerse","geldboerse"}));
+ Wenn man das in seinem Laden nicht wuenscht, kann man die Geldboerse
+ mittels folgender Zeile wieder aus dem Laden loeschen:
+ RemoveFixedObject("/obj/boerse");
+ Es ist nicht moeglich, keine oder mehrere Objekte anzugeben, um auf
+ diese Weise alle bzw. mehrere Objekte als nicht mehr staendig
+ verfuegbar zu markieren.
+
+SIEHE AUCH
+----------
+::
+
+ AddFixedObject(), SetStorageRoom(), /std/store.c
+
+
+Last modified: Thu Jun 18 14:19:19 1998 by Patryn
+
diff --git a/doc/sphinx/lfun/RemoveFromMenu.rst b/doc/sphinx/lfun/RemoveFromMenu.rst
new file mode 100644
index 0000000..f692de9
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveFromMenu.rst
@@ -0,0 +1,57 @@
+RemoveFromMenu()
+================
+
+FUNKTION
+--------
+::
+
+ int RemoveFromMenu(mixed ids)
+
+DEFINIERT IN
+------------
+::
+
+ /std/pub.c
+
+ARGUMENTE
+---------
+::
+
+ ids - string oder string*
+ String oder Array von Strings, mit denen sich die Speise bzw.
+ das Getraenk beim Bestellen ansprechen laesst.
+
+RUECKGABEWERT
+-------------
+::
+
+ int - Anzahl entfernter Einzelmenueeintraege
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Methode kann man id-basiert Speisen und Getraenke
+ wieder von der Karte entfernen (wenn zB nur saisonbasiert
+ bestimmte Dinge angeboten werden sollen).
+
+
+
+BEMERKUNGEN
+-----------
+::
+
+ - sich zwischen zwei Speisen ueberschneidende IDs fuehren zu
+ undefiniertem Verhalten!
+ - bei Benutzung von RemoveFromMenu sollte man in Delay-Speisen oder
+ -Getraenken auf die Nutzung vom ident-Parameter in den
+ Serviernachrichten verzichten (es sei, man weiss was man tut)
+
+SIEHE AUCH
+----------
+::
+
+ AddToMenu(), AddFood(), AddDrink(), /sys/pub.h
+
+15. Februar 2009 Gloinson
+
diff --git a/doc/sphinx/lfun/RemoveFunc.rst b/doc/sphinx/lfun/RemoveFunc.rst
new file mode 100644
index 0000000..4a00e99
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveFunc.rst
@@ -0,0 +1,114 @@
+RemoveFunc()
+============
+
+FUNKTION
+--------
+::
+
+ int RemoveFunc(object ruest, int info, object user);
+
+DEFINIERT IN
+------------
+::
+
+ eigenen Objekten (fuer /std/clothing/wear)
+
+ARGUMENTE
+---------
+::
+
+ ruest (object)
+ Die Ruestung/Kleidung, die ausgezogen werden soll.
+ info (int)
+ Bei (info&M_SILENT) wird keine Meldung ueber das Ausziehen
+ ausgegeben.
+ Bei (info&M_NOCHECK) wird die Kleidung ausgezogen, egal was diese
+ Funktion zurueckgibt. Dies tritt insbesondere dann auf, wenn der
+ Spieler, der die Ruestung traegt, stirbt und die Ruestung in
+ die Leiche bewegt wird.
+ user (object)
+ Das Lebewesen, welches die Ruestung/Kleidung gerade traegt und sie
+ ausziehen will.
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion kann man pruefen, ob sich das Kleidungsstueck bzw.
+ Ruestung <ruest> von this_player() ausziehen laesst oder nicht.
+ Kann die Ruestung ausgezogen werden, so muss ein Wert ungleich 0
+ zurueckgegeben werden.
+
+
+
+ Diese Funktion meldet nur einen _Wunsch_ an. Dieser kann ignoriert
+ werden (z.B. bei bestimmten Bewegungen, Tod des Spielers etc.).
+ Unabhaengig vom Wert dieser Funktion kann das Ausziehen noch Scheitern
+ oder Erzwungen werden.
+ Wenn ihr sicher sein wollt, dass der Spieler ein Objekt angezogen hat,
+ benutzt bitte InformUnwear().
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn sich die Ruestung nicht ausziehen laesst, ansonsten ungleich 0.
+
+BEMERKUNGEN
+-----------
+::
+
+ Verfluchte Ruestungen, die sich erst nach Entfernung des Fluches wieder
+ ausziehen lassen, sollte man besser mit P_CURSED realisieren (man spart
+ die RemoveFunc() ein).
+ Bitte nicht drauf verlassen, dass this_player() das ausziehende Lebewesen
+ ist.
+ Die Reihenfolge der Argumente ist etwas unschoen, aber leider wurde <user>
+ erheblich spaeter hinzugefuegt und es war unmoeglich, einige hundert
+ Objekte zu aendern.
+
+BEISPIELE
+---------
+::
+
+ Ein Umhang, den man nur mit guter Einstellung wieder ausziehen kann:
+
+ inherit "std/armour.c";
+
+ #include <properties.h>
+ #include <moving.h>
+
+ create()
+ {
+ ::create();
+
+ SetProp(P_ARMOUR_TYPE, AT_CLOAK);
+ /* zig weitere SetProp's, um den Umhang zu konfigurieren */
+
+ /* RemoveFunc() ist im Umhang selbst zu finden */
+ SetProp(P_REMOVE_FUNC, this_object());
+ }
+
+ int RemoveFunc(object me, int info, object user)
+ {
+ if (user->QueryProp(P_ALIGN) >= 0 || (info&M_NOCHECK))
+ return 1; /* gute Charaktere koennen den Umhang ausziehen */
+
+ /* Ansonsten geben wir evtl. einen entsprechenden Hinweis aus: */
+ if (!(info&M_SILENT))
+ write( "Der Umhang wird von Deiner Bosheit so sehr "
+ +"angezogen, dass Du ihn\nnicht mehr ausziehen kannst!\n");
+ return 0;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ P_WEAR_MSG, P_UNWEAR_MSG, P_WIELD_MSG, P_UNWIELD_MSG
+ DoUnwear(), DoWear(), InformWear(), InformUnwear()
+ /std/clothing/wear.c
+
+
+02.07.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveId.rst b/doc/sphinx/lfun/RemoveId.rst
new file mode 100644
index 0000000..0d45abc
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveId.rst
@@ -0,0 +1,45 @@
+RemoveId()
+==========
+
+FUNKTION
+--------
+::
+
+ void RemoveId(string|string* ids);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ ids
+ String oder Array von Strings mit den Bezeichnungen, die aus der
+ Liste der IDs des Objektes entfernt werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+ Wenn ein Objekt sich nicht mehr mit gewissen Bezeichnern ansprechen
+ lassen soll, kann man diese mit dieser Funktion entfernen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ AddId(), RemoveAdjective(), /std/thing/description.c
+
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveInfo.rst b/doc/sphinx/lfun/RemoveInfo.rst
new file mode 100644
index 0000000..d550826
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveInfo.rst
@@ -0,0 +1,45 @@
+RemoveInfo()
+============
+
+FUNKTION
+--------
+::
+
+ void RemoveInfo(string key)
+
+DEFINIERT IN
+------------
+::
+
+ /std/npc/info.c
+
+ARGUMENTE
+---------
+::
+
+ key zu loeschender Schluessel
+
+BESCHREIBUNG
+------------
+::
+
+ Loescht die Antwort zum entsprechenden Frageschluessel.
+
+BEISPIEL
+--------
+::
+
+ // erstellen und loeschen
+ AddInfo("gold","sagt: Ich habe keines.\n");
+ RemoveInfo("gold");
+
+SIEHE AUCH
+----------
+::
+
+ AddInfo(L), AddSpecialInfo(L)
+ P_PRE_INFO, P_DEFAULT_INFO
+ /std/npc/info.c
+
+17.Aug.2003 Gloinson
+
diff --git a/doc/sphinx/lfun/RemoveItem.rst b/doc/sphinx/lfun/RemoveItem.rst
new file mode 100644
index 0000000..808704a
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveItem.rst
@@ -0,0 +1,64 @@
+RemoveItem()
+============
+
+FUNKTION
+--------
+::
+
+ void RemoveItem(mixed file);
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/items.c
+
+ARGUMENTE
+---------
+::
+
+ file
+ String oder Array von Strings mit dem Namen des zu entfernenden
+ Objekts.
+
+BESCHREIBUNG
+------------
+::
+
+ Das mit AddItem(file) dem Raum hinzugefuegte Objekt wird wieder aus
+ der Liste der Objekte entfernt.
+ Wurde bei AddItem() ein Array von Dateinamen uebergeben, so muss das
+ selbe Array auch bei RemoveItem() uebergeben werden!
+ Falls das Objekt, das durch den AddItem()-Aufruf erzeugt wurde, sich
+ noch im Raum befindet, wird es durch den RemoveItem()-Aufruf zerstoert.
+
+RUECKGABEWERT
+-------------
+::
+
+ keiner
+
+BEISPIELE
+---------
+::
+
+ Ein muellschluckerfreier Laden laesst sich wie folgt erzeugen:
+
+ inherit "/std/laden";
+ #include <properties.h>
+
+ create()
+ {
+ ::create(); // Hier wird u.a. der Muellschlucker erzeugt
+
+ RemoveItem("/obj/entsorg"); // und weg damit!
+
+ SetProp(...); // und die normale Beschreibung...
+ }
+
+SIEHE AUCH
+----------
+::
+
+ AddItem(), /std/room/items.c
+
diff --git a/doc/sphinx/lfun/RemoveKnownPotion.rst b/doc/sphinx/lfun/RemoveKnownPotion.rst
new file mode 100644
index 0000000..b94313b
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveKnownPotion.rst
@@ -0,0 +1,45 @@
+RemoveKnownPotion()
+===================
+
+FUNKTION
+--------
+::
+
+ int RemoveKnownPotion(int nr)
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/potion.c
+
+ARGUMENTE
+---------
+::
+
+ int nr Nummer eines ZTs
+
+BESCHREIBUNG
+------------
+::
+
+ Entfernt einen bekannten ZT aus einen Spieler. Nur vom Orakel rufbar.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 Erfolg
+ -1 fehlende Berechtigung
+ -2 Nummer nicht eingetragen
+
+SIEHE AUCH
+----------
+::
+
+ Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
+ Verwandt: FindPotion(), AddKnownPotion(), InList()
+ Props: P_POTIONROOMS, P_KNOWN_POTIONROOMS
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/lfun/RemovePluralId.rst b/doc/sphinx/lfun/RemovePluralId.rst
new file mode 100644
index 0000000..1916656
--- /dev/null
+++ b/doc/sphinx/lfun/RemovePluralId.rst
@@ -0,0 +1,50 @@
+RemovePluralId()
+================
+
+FUNKTION
+--------
+::
+
+ void RemovePluralId(mixed id);
+
+DEFINIERT IN
+------------
+::
+
+ /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+ id
+ Identfikationsstring oder Array von Strings
+
+BESCHREIBUNG
+------------
+::
+
+ Es werden ein oder mehrere Bezeichner entfernt, mit denen sich
+ mehrere Einheiten der Menge ansprechen lassen.
+
+RUECKGABEWERT
+-------------
+::
+
+ keiner
+
+BEISPIELE
+---------
+::
+
+ siehe /items/money.c
+
+SIEHE AUCH
+----------
+::
+
+ RemoveSingularId(), AddPluralId(), AddId(), id(), /std/unit.c
+
+
+Last modified: Mon Jul 14 11:30:00 1997 by Silvana
+
diff --git a/doc/sphinx/lfun/RemovePursuer.rst b/doc/sphinx/lfun/RemovePursuer.rst
new file mode 100644
index 0000000..0eca43a
--- /dev/null
+++ b/doc/sphinx/lfun/RemovePursuer.rst
@@ -0,0 +1,53 @@
+RemovePursuer()
+===============
+
+RemoveRursuer()
+---------------
+::
+
+FUNKTION
+--------
+::
+
+ void RemovePursuer(object pursuer)
+
+ARGUMENTE
+---------
+::
+
+ pursuer: Objekt, das aus der Verfolgerliste des Objektes, in dem
+ RemovePursuer aufgerufen wurde, ausgetragen werden soll.
+
+FUNKTION
+--------
+::
+
+ Durch den Aufruf von RemovePursuer in einem Objekt, welches living() ist,
+ wird das Object, welches als Argument uebergeben wurde aus der Liste
+ der Verfolger ausgetragen.
+
+RUECKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNG
+---------
+::
+
+ keine
+
+BEISPIELE
+---------
+::
+
+ find_player("jof")->RemovePursuer(find_player("kirk"))
+ Danach wird Jof nicht mehr von Kirk verfolgt.
+
+SIEHE AUCH
+----------
+::
+
+ "AddPursuer", "PreventFollow"
+
diff --git a/doc/sphinx/lfun/RemoveReadDetail.rst b/doc/sphinx/lfun/RemoveReadDetail.rst
new file mode 100644
index 0000000..6bbc4a7
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveReadDetail.rst
@@ -0,0 +1,50 @@
+RemoveReadDetail()
+==================
+
+FUNKTION
+--------
+::
+
+ void RemoveReadDetail(string|string* keys);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ keys
+ String oder Array von Strings mit den zu entfernenden Details.
+
+BESCHREIBUNG
+------------
+::
+
+ Entfernt die in keys angegebenen Details aus der Liste der vorhandenen
+ lesbaren Details.
+
+BEMERKUNGEN
+-----------
+::
+
+ Uebergibt man fuer keys eine 0, so werden saemtliche lesbaren Details
+ entfernt!
+
+SIEHE AUCH
+----------
+::
+
+ Setzen: AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+ AddTouchDetail()
+ Loeschen: RemoveDetail(), RemoveSmells(),
+ RemoveSounds(), RemoveTouchDetail()
+ Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+ Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+ Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveResistanceModifier.rst b/doc/sphinx/lfun/RemoveResistanceModifier.rst
new file mode 100644
index 0000000..52c754d
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveResistanceModifier.rst
@@ -0,0 +1,57 @@
+RemoveResistanceModifier()
+==========================
+
+FUNKTION
+--------
+::
+
+ varargs void RemoveResistanceModifier(string add);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ string add:
+ Ein eventueller Identifikator fuer einen gesetzten Modifikator.
+
+BESCHREIBUNG
+------------
+::
+
+ Die von einem Objekt im Zielobjekt gesetzte Resistenz wird geloescht,
+ der Schluessel add wird dazu benutzt, eine bestimmte Resistenz zu
+ loeschen (so kann ein setzendes Objekt mehrere verschiedene Re-
+ sistenzen setzen und selektiv loeschen).
+
+BEISPIELE
+---------
+::
+
+ // unser Oel aus AddResistanceModifier() verbrennt endgueltig
+ varargs void trigger_sensitive_attack() {
+ ...
+ if(environment() && living(environment())) {
+ environment()->RemoveResistanceModifier("oel");
+ tell_object(environment(),"Das Oel verbrennt endgueltig.\n");
+ }
+ remove();
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Modifikatoren: AddResistanceModifier, P_RESISTANCE_MODIFIER
+ simple Resistenz: P_RESISTANCE, P_VULNERABILITY
+ Hauptmapping: P_RESISTANCE_STRENGTHS
+ Berechnung: CheckResistance(), UpdateResistanceStrengths()
+ anderes: balance, /std/armour/combat.c, /std/living/combat.c
+
+29.Apr 2002, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/RemoveRoute.rst b/doc/sphinx/lfun/RemoveRoute.rst
new file mode 100644
index 0000000..5e06e2b
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveRoute.rst
@@ -0,0 +1,43 @@
+RemoveRoute()
+=============
+
+FUNKTION
+--------
+::
+
+ void RemoveRoute();
+
+DEFINIERT IN
+------------
+::
+
+ /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Der Transporter wird angehalten und der gesamte Fahrplan wird
+ geloescht. Damit lassen sich zum Beispiel variable Routen konstruieren.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ AddRoute(), AddMsg(), AddFun(), /std/transport.c
+
+
+Last modified: Wed May 8 10:24:26 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/RemoveSensitiveObject.rst b/doc/sphinx/lfun/RemoveSensitiveObject.rst
new file mode 100644
index 0000000..f67224f
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveSensitiveObject.rst
@@ -0,0 +1,79 @@
+RemoveSensitiveObject()
+=======================
+
+FUNKTION
+--------
+::
+
+ void RemoveSensitiveObject(object ob)
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/inventory.c
+ generalizes /std/living/inventory.c
+
+ARGUMENTE
+---------
+::
+
+ ob - zu entfernendes Objekt
+
+BESCHREIBUNG
+------------
+::
+
+ Entfernt ob aus den Benachrichtigungslisten des Containers.
+ Wird von thing/moving.c im alten Environment gerufen, wenn
+ P_SENSITIVE gesetzt ist.
+ Ruft dazu RemoveSensitiveObjectFromList().
+
+BEMERKUNGEN
+-----------
+::
+
+ Setzt man P_SENSITIVE nicht als Default sondern situationsabhaengig,
+ dann muss man auch RemoveSensitiveObject im Environment
+ auch selbst rufen!
+
+BEISPIEL
+--------
+::
+
+ // Fackel (inheriting lightsource)
+ void create() {
+ ...
+ SetProp(P_SENSITIVE,
+ ({({SENSITIVE_INVENTORY_TRIGGER,DT_FIRE,120})}));
+ ...
+ }
+
+ // wenn die Fackel geloescht wird, verliert sie ihre aktive
+ // Eigenschaft und muss das dem environment() mitteilen
+ static int extinguish(string str) {
+ int i;
+ i=::extinguish(str);
+ if(i && QueryProp(P_LIGHT)<=0) {
+ SetProp(P_SENSITIVE,0);
+ if(environment())
+ environment()->RemoveSensitiveObject(this_object());
+ }
+ return i;
+ }
+
+ - empfindliche Objekte wie Eiszapfen koennen jetzt wieder gefahrlos
+ in das selbe environment() bewegt werden
+
+SIEHE AUCH
+----------
+::
+
+ P_SENSITIVE
+ InsertSensitiveObject
+ insert_sensitive_inv_trigger, insert_sensitive_inv
+ P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY, P_SENSITIVE_INVENTORY_TRIGGER
+ CheckSensitiveAttack
+
+25.Apr.2001, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/RemoveSingularId.rst b/doc/sphinx/lfun/RemoveSingularId.rst
new file mode 100644
index 0000000..fe146f2
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveSingularId.rst
@@ -0,0 +1,50 @@
+RemoveSingularId()
+==================
+
+FUNKTION
+--------
+::
+
+ void RemoveSingularId(mixed id);
+
+DEFINIERT IN
+------------
+::
+
+ /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+ id
+ Identifikationsstring oder Array von Strings
+
+BESCHREIBUNG
+------------
+::
+
+ Es werden ein oder mehrere Bezeichner entfernt, mit denen sich eine
+ einzelne Einheit ansprechen laesst.
+
+RUECKGABEWERT
+-------------
+::
+
+ keiner
+
+BEISPIELE
+---------
+::
+
+ siehe /items/money.c
+
+SIEHE AUCH
+----------
+::
+
+ AddSingularId(), RemovePluralId(), AddId(), id(), /std/unit.c
+
+
+Last modified: Mon Jul 14 11:31:00 1997 by Silvana
+
diff --git a/doc/sphinx/lfun/RemoveSkillAttributeModifier.rst b/doc/sphinx/lfun/RemoveSkillAttributeModifier.rst
new file mode 100644
index 0000000..c83c2a7
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveSkillAttributeModifier.rst
@@ -0,0 +1,85 @@
+RemoveSkillAttributeModifier()
+==============================
+
+FUNKTION
+--------
+::
+
+ public int RemoveSkillAttributeModifier(object caster, string atrname)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skill_attributes.c
+
+ARGUMENTE
+---------
+::
+
+ <atrname> string
+ Name des Skill-Attributes, von dem der Modifikator geloescht
+ werden soll.
+ (Definiert in /sys/living/skill_attributes.h)
+
+ <caster> object
+ Objekt, dessen Modifikator wieder entfernt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Entfernt den Modifikator, den Object <caster> gesetzt hat, wieder. Dies
+ ist nur notwendig, wenn der Effekt vor Ablauf der Gueltigkeit des
+ Modifikators aufgehoben werden soll.
+
+RUECKGABEWERT
+-------------
+::
+
+ SA_MOD_REMOVED wenn der Modifikator geloescht wurde
+ SA_MOD_NOT_FOUND wenn der Modifikator nicht gefunden wurde
+ Wenn man nur wissen will, ob die Operation erfolgreich war, empfiehlt es
+ sich, auf == SA_MOD_REMOVED zu pruefen.
+
+BEISPIELE
+---------
+::
+
+ // eine Waffe setzt im InformWield() einen Bonus auf SA_DAMAGE fuer 10min
+ protected void InformWield(object pl, int silent) {
+ if (objectp(pl)) {
+ if (pl->ModifySkillAttribute(SA_DAMAGE, 20, 600) == SA_MOD_OK)
+ // Erfolgsmeldung an Spieler
+ else
+ // Misserfolgsmeldung an Spieler.
+ }
+ }
+
+ // wenn der Spieler die Waffe vor Ablauf der 600s wegstecken will, muss
+ // der Bonus natuerlich auch wieder raus
+ protected void InformUnwield(object pl, int silent) {
+ if (objectp(pl))
+ pl->RemoveSkillAttributeModifier(this_object(), SA_DAMAGE);
+ // falls kein solcher Mod mehr gesetzt war, liefert RSAM()
+ // SA_MOD_NOT_FOUND zurueck. Auswertung des Rueckgabewertes ist
+ // vernachlaessigt.
+ }
+
+
+
+SIEHE AUCH
+----------
+::
+
+ Skills Lernen: LearnSkill, ModifySkill, LimitAbility
+ * Nutzung: UseSpell, UseSkill
+ * Abfragen: QuerySkill, QuerySkillAbility
+ * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+ QuerySkillAttributeModifier
+ * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+ * sonstig: spruchermuedung, skill_info_liste
+ * Properties: P_NEWSKILLS
+
+13.08.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveSmells.rst b/doc/sphinx/lfun/RemoveSmells.rst
new file mode 100644
index 0000000..1a50ebd
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveSmells.rst
@@ -0,0 +1,57 @@
+RemoveSmells()
+==============
+
+FUNKTION
+--------
+::
+
+ void RemoveSmells(string|string* keys);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ keys
+ String oder Array von Strings mit den zu entfernenden Details.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion entspricht dem RemoveDetail() fuer Standarddetails,
+ nur koennen hiermit Gerueche entfernt werden:
+ Entfernt die in <keys> angegebenen Details aus der Liste der
+ vorhandenen Details. Uebergibt man fuer <keys> eine 0, so werden
+ saemtliche Details entfernt!
+
+BEISPIEL
+--------
+::
+
+ Zuerst erzeugen wir ein kleines Detail, mit dem wir am Rauch riechen
+ koennen. Das Feuer brennt langsam ab und das Detail wird wieder
+ entfernt:
+
+ AddSmells("rauch",* H U S T *\n");
+ call_out(#'RemoveSmells, 100, "rauch");
+
+SIEHE AUCH
+----------
+::
+
+ Setzen: AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+ AddTouchDetail()
+ Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+ RemoveSounds(), RemoveTouchDetail()
+ Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+ Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+ Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveSounds.rst b/doc/sphinx/lfun/RemoveSounds.rst
new file mode 100644
index 0000000..4f1290d
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveSounds.rst
@@ -0,0 +1,66 @@
+RemoveSounds()
+==============
+
+FUNKTION
+--------
+::
+
+ void RemoveSounds(string|string* keys);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ keys
+ String oder Array von Strings mit den zu entfernenden Details.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion entspricht dem RemoveDetail() fuer Standarddetails,
+ nur koennen hiermit Gerauesche entfernt werden:
+ Entfernt die in <keys> angegebenen Details aus der Liste der
+ vorhandenen Details. Uebergibt man fuer <keys> eine 0, so werden
+ saemtliche Details entfernt!
+
+BEISPIEL
+--------
+::
+
+ Wir lassen etwas Musik spielen und wenn wir den Plattenspieler
+ ausmachen, dann endet sie und man hoert auch nichts mehr:
+
+ int ausmachen(string str);
+ ...
+ AddSounds(({"musik","hip-hop"}) ,"Klingt nach Hip-Hop...\n");
+ AddCmd("mach|mache&plattenspieler&aus", #'ausmachen,
+ "Was willst du (aus)machen?|Willst du den ausmachen?^");
+ ...
+ int ausmachen(string str) {
+ if(!GetDetail("musik", 0, SENSE_SOUND)) // existiert Musikdetail ?
+ return("Der Plattenspieler laeuft doch gar nicht!\n", 1);
+ RemoveSounds(0);
+ return 1;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Setzen: AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+ AddTouchDetail()
+ Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+ RemoveTouchDetail()
+ Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+ Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+ Sonstiges: GetDetail(), break_string()
+
+8. Juli 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/RemoveSpecialDetail.rst b/doc/sphinx/lfun/RemoveSpecialDetail.rst
new file mode 100644
index 0000000..83bb25a
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveSpecialDetail.rst
@@ -0,0 +1,60 @@
+RemoveSpecialDetail()
+=====================
+
+VERALTET RemoveSpecialDetail()
+------------------------------
+::
+
+FUNKTION
+--------
+::
+
+ void RemoveSpecialDetail(string|string* keys);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ keys
+ String oder Array von Strings mit den zu entfernenden Details.
+
+BESCHREIBUNG
+------------
+::
+
+ Entfernt die in keys angegebenen Details aus der Liste der
+ vorhandenen SpecialDetails.
+
+ VERALTET: Bitte RemoveDetail() benutzen.
+
+BEMERKUNGEN
+-----------
+::
+
+ Uebergibt man fuer keys eine 0, so werden saemtliche SpecialDetails
+ entfernt!
+ Da intern Details und SpecialDetails im gleichen Mapping verwaltet
+ werden, lassen sich mit dieser Funktion auch Details entfernen.
+ Man sollte diese Funktion deshalb nicht mehr verwenden, siehe
+ AddDetail mit Closures.
+
+SIEHE AUCH
+----------
+::
+
+ Setzen : AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+ AddTouchDetail()
+ Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+ RemoveSounds(), RemoveTouchDetail()
+ Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+ Veraltet: AddSpecialDetail(), P_READ_MSG
+ Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveSpecialExit.rst b/doc/sphinx/lfun/RemoveSpecialExit.rst
new file mode 100644
index 0000000..ba3bfbf
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveSpecialExit.rst
@@ -0,0 +1,49 @@
+RemoveSpecialExit()
+===================
+
+FUNKTION
+--------
+::
+
+ void RemoveSpecialExit(string|string* cmd);
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/exits
+
+ARGUMENTE
+---------
+::
+
+ string/string* cmd
+ Richtung(en), die entfernt werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+ Die in cmd angegebenen Ausgaenge werden wieder entfernt.
+
+ Ist cmd = 0, so werden alle Ausgaenge entfernt.
+
+BEMERKUNGEN
+-----------
+::
+
+ Ausgaenge werden an der gleichen Stelle gespeichert:
+ - RemoveSpecialExit() greift auf die gleichen Daten wie RemoveExit()
+ zu, entfernt also auch normale Ausgaenge!
+
+SIEHE AUCH
+----------
+::
+
+ AddExit(), AddSpecialExit(), AddGuardedExit(), GetExits()
+ RemoveExit(),
+ P_EXITS, P_HIDE_EXITS, /std/room/exits.c
+ ausgaenge
+
+31.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/RemoveTouchDetail.rst b/doc/sphinx/lfun/RemoveTouchDetail.rst
new file mode 100644
index 0000000..104f8d2
--- /dev/null
+++ b/doc/sphinx/lfun/RemoveTouchDetail.rst
@@ -0,0 +1,75 @@
+RemoveTouchDetail()
+===================
+
+FUNKTION
+--------
+::
+
+ void RemoveTouchDetail(string|string* keys);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ keys
+ String oder Array von Strings mit den zu entfernenden Details.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion entspricht dem RemoveDetail() fuer Standarddetails,
+ nur koennen hiermit (ab)tastbare Details entfernt werden:
+ Entfernt die in <keys> angegebenen Details aus der Liste der
+ vorhandenen Details. Uebergibt man fuer <keys> eine 0, so werden
+ saemtliche tastbaren/fuehlbaren Details entfernt!
+
+BEISPIEL
+--------
+::
+
+ Zuerst wird ein Detail "boden" erzeugt, das abgetastet werden kann.
+ Dieses kann durch Betaetigen eines Knopfes, aeh, entfernt werden.
+
+ int knopf();
+ void knopf2();
+
+ AddTouchDetail("boden", "Er ist aus Stein.\n");
+ AddCmd("drueck|druecke&knopf", #'knopf, "Was willst du druecken?");
+
+ void knopf() {
+ tell_room(this_object(), break_string(
+ this_player()->Name(WER)+" drueckt einen Knopf, der dabei satt "+
+ "klackt.", 78));
+
+ if(find_call_out(#'knopf2)<=0)
+ call_out(#'knopf2, 1);
+ }
+
+
+
+ void knopf2() {
+ tell_room(this_object(), "Uhoh. Der Boden klappt weg. Du faellst.");
+ RemoveTouchDetails("boden");
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Setzen: AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
+ AddTouchDetail()
+ Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
+ RemoveSounds()
+ Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
+ Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
+ Sonstiges: GetDetail(), break_string()
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/ResizeRingBuffer.rst b/doc/sphinx/lfun/ResizeRingBuffer.rst
new file mode 100644
index 0000000..e00d5ad
--- /dev/null
+++ b/doc/sphinx/lfun/ResizeRingBuffer.rst
@@ -0,0 +1,68 @@
+ResizeRingBuffer()
+==================
+
+FUNKTION
+--------
+::
+
+ protected struct std_ringbuffer buf RingBufferPut(
+ struct std_ringbuffer buf,
+ int size);
+
+DEFINIERT IN
+------------
+::
+
+ /std/util/ringbuffer.c
+ /sys/util/ringbuffer.h
+
+
+
+ARGUMENTE
+---------
+::
+
+ buf - Ringpuffer, dessen Groesse geaendert werden soll
+ size - neue Groesse (int)
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion erstellt einen neuen Ringpuffer der Groesse <size>, welcher
+ den gleichen Modus hat wie <buf> und die gleichen Daten enthaelt.
+ Ist der neue Puffer kleiner als <buf>, so kommt es hierbei zu
+ Datenverlust.
+ <buf> wird nicht veraendert. Ist die Groesse von <buf> gleich der
+ neuen gewuenschten Groesse, wird letztendlich der Ringpuffer kopiert.
+ Je nach Groesse von <buf> und Wert von <size> kann dies eine teure
+ Angelegenheit sein.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der neue Ringpuffer mit Groesse <size>.
+
+BEISPIELE
+---------
+::
+
+ // Ringpuffer anlegen:
+ struct std_ringbuffer buffer = CreateRingBuffer(5, MODE_FIFO);
+ // 5 Werte reinschreiben:
+ foreach(int i: 5) RingBufferPut(buffer, i);
+ // Groesse aendern
+ buffer = ResizeRingBuffer(buffer, 10);
+ // Daten als Array ermitteln:
+ mixed array = RingBufferGet(buffer);
+ // array enthaelt: ({0,0,0,0,0,0,1,2,3,4})
+
+SIEHE AUCH
+----------
+::
+
+ RingBufferGet(), RingBufferPut(), CreateRingBuffer()
+
+23.05.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/RingBufferGet.rst b/doc/sphinx/lfun/RingBufferGet.rst
new file mode 100644
index 0000000..445e9f3
--- /dev/null
+++ b/doc/sphinx/lfun/RingBufferGet.rst
@@ -0,0 +1,63 @@
+RingBufferGet()
+===============
+
+FUNKTION
+--------
+::
+
+ protected mixed RingBufferGet(struct std_ringbuffer buf);
+
+DEFINIERT IN
+------------
+::
+
+ /std/util/ringbuffer.c
+ /sys/util/ringbuffer.h
+
+ARGUMENTE
+---------
+::
+
+ buf - Ringpuffer, welcher ausgeben werden soll
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert die Daten des Ringpuffers in Form eines Arrays
+ zurueck, welches dann weiterverarbeitet werden kann.
+ Die Reihenfolge der Daten ist entsprechend des beim Anlegen des
+ Ringpuffers angebenen Modes:
+ MODE_FIFO: aelteste Daten zuerst
+ MODE_LIFO: neueste Daten zuerst
+
+BEMERKUNGEN
+-----------
+::
+
+ Aenderungen am Array beeinflussen die Daten des Ringpuffers nicht. Aber:
+ Hierbei werden die Daten nicht tief kopiert. D.h. enthaelt der Ringpuffer
+ Referenzen auf weitere Daten, zeigen der Ringpuffer und das hier
+ gelieferte Array auf die gleichen Daten.
+
+BEISPIELE
+---------
+::
+
+ // Ringpuffer anlegen:
+ struct std_ringbuffer buffer = CreateRingBuffer(10, MODE_FIFO);
+ // 15 Werte reinschreiben:
+ foreach(int i: 15) RingBufferPut(buffer, i);
+ // Werte abrufen:
+ mixed array=RingBufferGet(buffer);
+ // array enthaelt nun:
+ // ({5,6,7,8,9,10,11,12,13,14})
+
+SIEHE AUCH
+----------
+::
+
+ CreateRingBuffer(), RingBufferPut(), ResizeRingBuffer()
+
+23.05.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/RingBufferPut.rst b/doc/sphinx/lfun/RingBufferPut.rst
new file mode 100644
index 0000000..4d35ad6
--- /dev/null
+++ b/doc/sphinx/lfun/RingBufferPut.rst
@@ -0,0 +1,49 @@
+RingBufferPut()
+===============
+
+FUNKTION
+--------
+::
+
+ protected void RingBufferPut(struct std_ringbuffer buf, mixed val);
+
+DEFINIERT IN
+------------
+::
+
+ /std/util/ringbuffer.c
+ /sys/util/ringbuffer.h
+
+ARGUMENTE
+---------
+::
+
+ buf - Ringpuffer, in den <val> geschrieben werden soll
+ val - neues Datum
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion schreibt <val> in den Ringpuffer <buf>. Hierbei wird ggf.
+ das aelteste im Puffer existierende Datum ueberschrieben. <buf> muss eine
+ von CreateRingBuffer() oder ResizeRingBuffer() zurueckgelieferter
+ Ringpuffer sein.
+
+BEISPIELE
+---------
+::
+
+ // Ringpuffer anlegen:
+ struct std_ringbuffer buffer = CreateRingBuffer(10, MODE_FIFO);
+ // 15 Werte reinschreiben:
+ foreach(int i: 15) RingBufferPut(buffer, i);
+
+SIEHE AUCH
+----------
+::
+
+ RingBufferGet(), CreateRingBuffer(), ResizeRingBuffer()
+
+23.05.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/SearchPath.rst b/doc/sphinx/lfun/SearchPath.rst
new file mode 100644
index 0000000..34ce6c1
--- /dev/null
+++ b/doc/sphinx/lfun/SearchPath.rst
@@ -0,0 +1,109 @@
+SearchPath()
+============
+
+FUNKTION
+--------
+::
+
+ public int SearchPath(string from, string to, int para,
+ closure callback)
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/pathd.c
+ <sys/path.d>
+
+ARGUMENTE
+---------
+::
+
+ from - Der Startpunkt
+ to - Der Endpunkt
+ para - Die Parawelt in der gesucht wird (Normalwelt: 0)
+ callback - Closure, die am Ende der Pfadsuche gerufen wird
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion berechnet - sofern moeglich - den kuerzesten Pfad zwischen
+ <from> und <to> in der (Para-)Welt <para>.
+
+
+
+ Die Pfadsuche wird anhand von Daten ueber von Spielern gelaufene Wege
+ durchgefuehrt. D.h. Gebiete, die von Spielern nicht (in letzter Zeit mal)
+ betreten werden, sind auch dem Pfaddaemon nicht bekannt. Auch kann es
+ Gebiete geben, wo zwar gebietsintern Pfade bekannt sind, aber keine Wege
+ in den Rest vom MG.
+
+ Da diese Suche im Allgemeinen SEHR aufwendig sein kann, wird sie meistens
+ nicht sofort fertig, sondern dauert eine Weile. Wenn sie fertig ist, wird
+ die Closure <callback> aufgerufen und ihr die Argumente <from>, <to>,
+ <parawelt>, <kosten>, <path> und <cmds> uebergeben. Die Bedeutung
+ dieser Argumente ist unten erklaert.
+
+ Eine Suche nach einem Pfad in einer Parawelt fuehrt durch Raeume der
+ gewuenschen Parawelt und durch Raeume der Normalwelt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 - Suche wurde gestartet
+ 2 - Pfad gefunden (und callback gerufen)
+ -1 - es laeuft schon ein Suchauftrage fuer die UID des anfragenden
+ Objektes
+ -2 - es laufen bereits zuviele Suchanfragen
+ -3 - <from> und/oder <to> sind nicht bekannt
+
+
+
+ An <callback> uebergebene Argumente am Ende der Pfadsuche:
+ <from> - Startpunkt des Weges (string)
+ <to> - Zielpunkt des Weges (string)
+ <para> - Parawelt des Weges (int)
+ <costs>- Kosten des Wege. (int) Je hoeher, desto
+ laenger/unguenstiger. 0, wenn kein Pfad gefunden
+ <path> - Array mit Raumnamen, die durchlaufen werden (string*)
+ 0, wenn kein Pfad gefunden
+ <cmds> - Array mit Kommandos zum Ablaufen des Weges (string*)
+ 0, wenn kein Pfad gefunden
+
+BEMERKUNGEN
+-----------
+::
+
+ Es ist natuerlich nicht dazu gedacht, Spielern fertige Routen zwischen
+ Orten zu geben - bzw. nur in Ausnahmefaellen.
+ Pfadabfrgen werden geloggt.
+
+ Die Angabe <costs> sagt grob etwas ueber die Laenge und vor allem ueber die
+ "Qualitaet" des Pfades aus. Die steigt bei Paraweltwechseln, wenig
+ abgelaufenen Verbindungen zwischen Raeumen oder wenn eine Verbindung kein
+ normaler Ausgang ist.
+
+ Die Closure <callback> sollte nicht zuviele Ticks verbrauchen.
+
+BEISPIEL
+--------
+::
+
+ #include <pathd.h>
+ void suchergebnis(string from, string to, int para, int costs, string*
+ path, string* cmds) {
+ tell_object(find_player("zesstra"), sprintf(
+ "Ergebnis Pfadsuche von %s nach %s in Para %d fuer %d:\n %O\n %O\n",
+ from, to, para, costs, path, cmds));
+ };
+
+ ...
+ mixed res=PATHD->SearchPath("/gilden/abenteurer",
+ "/d/ebene/dancer/lucky/room/pova_la3",
+ 0, #'suchergebnis);
+
+
+22.12.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/SelectEnemy.rst b/doc/sphinx/lfun/SelectEnemy.rst
new file mode 100644
index 0000000..1ce4167
--- /dev/null
+++ b/doc/sphinx/lfun/SelectEnemy.rst
@@ -0,0 +1,52 @@
+SelectEnemy()
+=============
+
+FUNKTION
+--------
+::
+
+ varargs object SelectEnemy(object*here);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ here
+ Gegner, aus welchen ausgewaehlt werden soll (optional!)
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ausgewaehlter Gegner, der angegriffen werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion waehlt einen Gegner aus, der angegriffen werden soll.
+ Werden keine Gegner im Parameter <here> angegeben, so wird der
+ Rueckgabewert der Funktion PresentEnemies() verwandt, welche die
+ aktuell anwesenden Gegner im Raum liefert.
+ Sind keine Gegner anwesend, so wird 0 zurueckgeliefert.
+ Danach wird geschaut, ob Gegner bevorzugt ausgewaehlt werden sollen.
+ Dies geschieht mittels der Funktion QueryPreferedEnemy().
+ Auch dieser bevorzugte Gegner muss im selben Raum sein! Wenn nicht,
+ wird doch irgendein anderer Gegner ausgewaehlt und zurueckgegeben.
+
+SIEHE AUCH
+----------
+::
+
+ PresentEnemies(), QueryPreferedEnemy(), P_PREFERED_ENEMY,
+ InsertEnemy(), StopHuntFor()
+
+
+Last modified: Thu May 27 15:01:48 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/SelectFarEnemy.rst b/doc/sphinx/lfun/SelectFarEnemy.rst
new file mode 100644
index 0000000..9e2c5d9
--- /dev/null
+++ b/doc/sphinx/lfun/SelectFarEnemy.rst
@@ -0,0 +1,66 @@
+SelectFarEnemy()
+================
+
+FUNKTION
+--------
+::
+
+ varargs object SelectFarEnemy(object *here, int min, int max,
+ int forcefrom)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ here - Rueckgabewert von PresentEnemies()
+ min - minimale Kampfreihe
+ max - maximale Kampfreihe
+ forcefrom - Gegner MUSS aus uebergebenem Array ausgewaehlt werden
+
+BESCHREIBUNG
+------------
+::
+
+ Waehlt einen Feind aus Reihe <min> bis <max> aus.
+
+RUECKGABEWERT
+-------------
+::
+
+ Der Auserwaehlte :-)
+
+BEMERKUNGEN
+-----------
+::
+
+ 1. Wenn in den angegeben Reihen kein Feind ist oder <max> kleiner
+ als <min> ist, wird auch keiner zurueckgegeben.
+ 2. Aus Effizienzgruenden sollte forcefrom nur benutzt werden, wenn
+ es wirklich noetig ist (s. hierzu auch SelectNearEnemy()).
+ 3. 0 <= <min> <= <max> < MAX_TEAMROWS
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
+ SelectNearEnemy
+ Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+ PresentTeamPosition, SwapRows
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/SelectNearEnemy.rst b/doc/sphinx/lfun/SelectNearEnemy.rst
new file mode 100644
index 0000000..32cab34
--- /dev/null
+++ b/doc/sphinx/lfun/SelectNearEnemy.rst
@@ -0,0 +1,70 @@
+SelectNearEnemy()
+=================
+
+FUNKTION
+--------
+::
+
+ varargs object SelectNearEnemy(object *here, int forcefrom)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ here - Rueckgabewert von PresentEnemies()
+ forcefrom - Gegner MUSS aus uebergebenem Array ausgewaehlt werden
+
+BESCHREIBUNG
+------------
+::
+
+ Waehlt einen im Nahkampf erreichbaren Feind aus
+
+RUECKGABEWERT
+-------------
+::
+
+ Der Auserwaehlte :-)
+
+BEMERKUNGEN
+-----------
+::
+
+ 1. Falls der Spieler in einem Team ist und in einer hinteren Reihe
+ steht, wird kein Feind ausgewaehlt, es sei denn, der Spieler hat
+ einen Kampf mit einem Teammitglied angefangen.
+ 2. Wenn ein bevorzugter Feind in einer der hinteren Reihen eines
+ Teams steht, wird solange das Team bevorzugt.
+ 3. Auch Feinde in den hinteren Reihen koennen im Nahkampf erreichbar
+ sein, wenn die vorderen Reihen nicht genuegend Deckung bieten.
+ 4. ACHTUNG: Der Auserwaehlte kommt nicht notwendigerweise aus dem
+ uebergebenen Array, wenn forcefrom=0 ist. Normalerweise ist dieses
+ Verhalten beabsichtigt, damit jemand, der sich in der Reihe vor
+ einen Gegner stellt, angegriffen wird, auch wenn er noch nicht
+ Feind ist.
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
+ SelectFarEnemy
+ Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+ PresentTeamPosition, SwapRows
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/Set.rst b/doc/sphinx/lfun/Set.rst
new file mode 100644
index 0000000..ffca76a
--- /dev/null
+++ b/doc/sphinx/lfun/Set.rst
@@ -0,0 +1,174 @@
+Set()
+=====
+
+FUNKTION
+--------
+::
+
+ public varargs mixed Set(string name, mixed Value, int Type, int extern);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/properties.c
+ /sys/thing/properties.h (Prototyp)
+
+ARGUMENTE
+---------
+::
+
+ name - Property, die manipuliert werden soll
+ Value - der zu setzende/aendernde Wert
+ Type - die Eigenschaft der Property, die manipuliert werden soll
+ extern - Interne Verwendung:
+ Wurde Set ueber SetProp von aussen gerufen.
+
+BESCHREIBUNG
+------------
+::
+
+ Eine der inneren Eigenschaften der Property 'name' wird veraendert.
+ 'Type' ist dabei einer der in /sys/thing/properties.h definierten
+ F_XXX - Werte:
+
+ F_VALUE (==0, default)
+ Setzt den Inhalt der Property auf 'Value'. Aehnlich "SetProp",
+ umgeht jedoch eine etwaige F_SET_METHOD oder _set_'name'()-Methode.
+ F_MODE
+ F_MODE_AS
+ F_MODE_AD
+ Aendert eines der internen Flags der Property. F_MODE negiert den
+ vorherigen Wert vom Flag 'Value', F_MODE_AS setzt und F_MODE_AD
+ loescht ihn.
+ Verfuegbare interne Flags:
+
+ SAVE
+
+ Property wird bei save_object() gespeichert
+
+ PROTECTED
+
+ Flag setzbar durch: beliebiges Objekt
+ Flag loeschbar durch: this_object(), ROOT, EM+
+ Inhalt der Property veraendern sowie Set- und Query-Methoden
+ setzen oder loeschen duerfen nur noch this_object(), ROOT, EM+
+ WARNUNG: Dieses Flag nicht leichtfertig bei Spielern setzen!
+
+ SECURED
+
+ Flag setzbar durch: this_object(), ROOT, EM+
+ Flag loeschbar durch: Niemanden!
+ Inhalt der Property veraendern sowie Set- und Query-Methoden
+ setzen oder loeschen duerfen nur noch this_object(), ROOT, EM+
+
+ NOSETMETHOD
+
+ Property nicht mehr ueber SetProp() aenderbar
+ (damit entfallen auch SET_METHOD, _set_'name')
+ F_SET_METHOD
+ Aendert den Eintrag fuer eine SetMethod - eine Closure, die anstatt
+ des Setzens der Property beim Aufruf von SetProp mit 'Value'
+ aufgerufen wird.
+ F_QUERY_METHOD
+ Aendert den Eintrag fuer eine QueryMethod - eine Closure, die anstatt
+ des Lesens der Property beim Aufruf von QueryProp aufgerufen wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Das Ergebnis der Manipulation bzw. einer der definierten
+ Fehlercodes.
+
+BEMERKUNGEN
+-----------
+::
+
+ - Set() sollte nicht zum regulaeren Manipulieren des Inhalts einer
+ Property verwendet werden, da sowohl F_SET_METHOD als auch libinterne
+ _set_'name'()-Methoden umgangen werden und das Ergebnis fuer so
+ veraenderte Properties undefiniert ist.
+ - eine gesetzte F_SET/F_QUERY_METHOD hat bei SetProp/QueryProp Vorrang
+ vor einer _set/_query_method
+ -> _set/_query wird nach erfolgreichem Ruf von F_XXX_METHOD ignoriert
+ - F_SET/F_QUERY_METHOD sollte normalerweise Vorzug vor einer
+ _set_/_query_* gegeben werden.
+
+ SetMethods/QueryMethods:
+ - falls ihr Query/SetMethods an oeffentlichen Properties setzen
+ wollt, prueft bitte vorher, ob dort nicht schon eine (fremde) gesetzt
+ ist und brecht ggf. euer Set() ab, um nicht die Arbeit anderer
+ Mitmagier zu sabotieren (z.B. P_HANDS)
+ - Properties sollten mit Query- oder SetMethoden nur so lange wie
+ noetig belegt werden
+ -> manche Properties sollte man als Wert setzen, _auch wenn_ die
+ Spieler sie zuruecksetzen koennten (zB P_MSGIN/P_MSGOUT)
+ - auf keinen Fall den Wert speichern, ueberschreiben, rueckschreiben,
+ das fuehrt fast immer zu Problemen.
+ - Set/QueryMethoden sollten nicht als Trigger/Listener fuer ein
+ Ereignis (z.B. P_DIE_MSG fuer das Ereignis "Tod des Spielers")
+ missbraucht werden
+ -> es gibt sichere und saubere Moeglichkeiten (NotifyPlayerDeath),
+ und wenn nicht, wendet euch an den EM eures Vertrauens
+ - F_SET/F_QUERY_METHODs koennen 'protected' (empfohlen) oder 'static'
+ sein. _set_/_query_ duerfen momentan _nicht_ 'protected' sein, fuer
+ geht nur 'static' (in diesem Fall empfohlen).
+
+BEISPIELE
+---------
+::
+
+ ### Aendern von Eigenschaften einer Property ###
+ // Setzen des SAVE-Flags (bei save_object() mitzuspeichern)
+ Set(P_XYZ, SAVE, F_MODE_AS);
+
+ // Loeschen des SAVE-Flags
+ Set(P_XYZ, SAVE, F_MODE_AD);
+
+
+
+ // Negieren des bisherigen SAVE-Flags
+ Set(P_XYZ, SAVE, F_MODE);
+ // Hinweis: das Setzen des Flags funktioniert mittels F_MODE nur dann,
+ // wenn sichergestellt ist, dass es vorher nicht gesetzt war. Die
+ // sichere Variante ist daher, F_MODE_AS zu verwenden.
+
+ // Sperren des SetProp/SET_METHOD-Zugriffs:
+ Set(P_XYZ, NOSETMETHOD, F_MODE_AS);
+
+ // Vorlaeufiger Zugriffsschutz fuer eine Property:
+ Set(P_XYZ, PROTECTED, F_MODE_AS);
+
+ // Permanenter Zugriffsschutz fuer eine Property:
+ Set(P_XYZ, SECURED, F_MODE_AS);
+
+ ### Setzen einer SetMethod/QueryMethod ###
+ // Setzen einer internen SetMethod
+ mixed foo(mixed val);
+ ...
+ Set(P_XYZ, #'foo, F_SET_METHOD);
+ ...
+
+ // Setzen einer QueryMethod bei einem anderen Objekt
+ mixed bar();
+ ...
+ other->Set(P_XYZ, #'bar, F_QUERY_METHOD);
+ ...
+
+ // Der Vollstaendigkeit halber sei das Aendern einer Property unter
+ // Umgehung von Set-Methoden angegeben. Es ist aber aus o.g. Gruenden
+ // zu empfehlen, diese Variante nicht zu verwenden.
+ Set(P_XYZ, "bla", F_VALUE);
+
+SIEHE AUCH
+----------
+::
+
+ Aehnliches: SetProp(L), QueryProp(L), Query(L)
+ Generell: SetProperties(L), QueryProperties(L)
+ Konzept: properties, /std/thing/properties.c
+ Sonstiges: P_AUTOLOADOBJ
+
+06. Jan 2008 Arathorn
+
diff --git a/doc/sphinx/lfun/SetAttackChats.rst b/doc/sphinx/lfun/SetAttackChats.rst
new file mode 100644
index 0000000..dbfee76
--- /dev/null
+++ b/doc/sphinx/lfun/SetAttackChats.rst
@@ -0,0 +1,108 @@
+SetAttackChats()
+================
+
+FUNKTION
+--------
+::
+
+ void SetAttackChats(int chance, mixed strs);
+
+DEFINIERT IN
+------------
+::
+
+ /std/npc/chat.c
+
+ARGUMENTE
+---------
+::
+
+ chance
+ Prozentuale Wahrscheinlichkeit einer Ausgabe
+ strs
+ Stringarray mit den Monsterchats
+
+BESCHREIBUNG
+------------
+::
+
+ Der NPC gibt mit der Wahrscheinlichkeit 'chance' einen zufaellig
+ gewaehlten Text aus 'strs' von sich. Die Arrayelemente koennen
+ auch Funktionen ("@@func@@") oder Closures enthalten, die dann
+ aufgerufen werden und deren Rueckgabewerte das Monster dann ausgibt.
+
+RUECKGABEWERT
+-------------
+::
+
+ keiner
+
+
+
+BEMERKUNGEN
+-----------
+::
+
+ AttackChats werden nur im Kampf ausgegeben. Ansonsten ist SetChats()
+ zu verwenden.
+
+
+
+ 'chance' wird in der Property P_ACHAT_CHANCE abgelegt. Um einen NPC
+ voruebergehend 'stillzulegen', kann man P_ACHAT_CHANCE auf 0 setzen.
+
+
+
+ Man kann AttackChats nutzen, um Monsterspells zu realisieren. Besser
+ ist es aber, dafuer 'AddSpell' zu verwenden.
+
+
+
+BEISPIELE
+---------
+::
+
+ SetAttackChats( 20,
+ ({ "Der Ork tritt Dir in den Hintern.\n",
+ "Der Ork bruellt: Lebend kommst Du hier nicht raus!\n",
+ "Der Ork blutet schon aus mehreren Wunden.\n",
+ "@@knirsch@@" }) );
+
+
+
+ string knirsch()
+ {
+ object *ruestung, *tmp, helm;
+
+
+
+ ruestung = this_player()->QueryProp(P_ARMOURS); // getragene Ruestung
+ tmp = filter_objects(ruestung, "id", AT_HELMET);
+ // Wenn der Spieler einen Helm traegt, enthaelt 'tmp' jetzt
+ // ein Array mit dem Helmobjekt als einzigem Element
+ if (sizeof(tmp)) helm = tmp[0];
+ if (objectp(helm))
+ {
+ // AC nur dann senken, wenn sie nicht schon 0 ist.
+ if (helm->QueryProp(P_AC)>0) {
+ helm->Damage(1);
+ return "Der Ork beschaedigt Deinen Helm!\n";
+ }
+ return "";
+ }
+ else
+ return ""; // keine Meldung
+ }
+
+SIEHE AUCH
+----------
+::
+
+ P_ACHAT_CHANCE, SetChats(), /std/npc/chat.c, AddSpell()
+
+LETZTE AENDERUNG
+----------------
+::
+
+ Don, 27.12.2007, 16:35:00 von Arathorn
+
diff --git a/doc/sphinx/lfun/SetAttr.rst b/doc/sphinx/lfun/SetAttr.rst
new file mode 100644
index 0000000..7866e7c
--- /dev/null
+++ b/doc/sphinx/lfun/SetAttr.rst
@@ -0,0 +1,55 @@
+SetAttr()
+=========
+
+FUNKTION
+--------
+::
+
+ public int SetAttr(string attr, int val)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+ attr - zu setzendes Attribut
+ val - Wert
+
+BESCHREIBUNG
+------------
+::
+
+ Filtert den Wert durch _filterattr(). Dadurch werden STR, INT, CON, DEX
+ auf 20 begrenzt. Setzt dann das Attribut.
+ Offsets werden hier nicht beruecksichtigt, QueryAttribute() gibt also
+ val + etwaige Offsets/Modifier zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Tatsaechlich gesetzter Wert.
+
+BEMERKUNGEN
+-----------
+::
+
+ Wird von SetAttribute() und SetRealAttribute() aufgerufen.
+
+SIEHE AUCH
+----------
+::
+
+ QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+ SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+ TestAttributeLock(),
+ P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
+ P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/SetAttribute.rst b/doc/sphinx/lfun/SetAttribute.rst
new file mode 100644
index 0000000..bb52498
--- /dev/null
+++ b/doc/sphinx/lfun/SetAttribute.rst
@@ -0,0 +1,49 @@
+SetAttribute()
+==============
+
+FUNKTION
+--------
+::
+
+ int SetAttribute(string attr, int val)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+ attr - zu setzendes Attribut
+ val - Wert
+
+BESCHREIBUNG
+------------
+::
+
+ Nimm val als Gesamtwert des Attributes, d.h. zieht etwaige Offsets vor
+ Setzen ab. (QueryAttribute gibt dann also val zurueck)
+
+RUeCKGABEWERT
+-------------
+::
+
+ Den durch SetAttr gefilterten gesetzten Wert.
+ Bitte nicht auf Spieler anwenden!
+
+SIEHE AUCH
+----------
+::
+
+ QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+ SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+ SetTimedAttrModifier(), QueryTimedAttrModifier(),
+ DeleteTimedAttrModifier(),
+ P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+ P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/SetBuyFact.rst b/doc/sphinx/lfun/SetBuyFact.rst
new file mode 100644
index 0000000..edf2d9e
--- /dev/null
+++ b/doc/sphinx/lfun/SetBuyFact.rst
@@ -0,0 +1,59 @@
+SetBuyFact()
+============
+
+FUNKTION
+--------
+::
+
+ void SetBuyFact(int fact);
+
+DEFINIERT IN
+------------
+::
+
+ /std/laden.c
+
+ARGUMENTE
+---------
+::
+
+ fact
+ Der Einkaufspreismultiplikator.
+
+BESCHREIBUNG
+------------
+::
+
+ Der Preis, der beim Kauf eines Objekts im Laden zu entrichten ist,
+ errechnet sich aus seinem Wert ( P_VALUE), multipliziert mit dem Faktor
+ fact. Dieser Preis ist konstant und nicht von der aktuellen Marktlage
+ abhaengig.
+
+ Der Defaultwert ist 3. Ein hoeherer Wert entspricht einem teuren Laden,
+ waehrend ein kleinerer Wert zu kleinen Preisen fuehrt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Normalerweise kommt man ohne diese Funktion aus: in teuren Laeden wird
+ nicht viel eingekauft (es sei denn, es liegen standardmaessig gute
+ Objekte im Speicher), einem Billigladen wird bald das Geld ausgehen mit
+ der Folge, dass der Ladenbesitzer nichts mehr ankaufen kann und sein
+ Lager gaehnend leer ist.
+
+SIEHE AUCH
+----------
+::
+
+ QueryBuyFact(), /std/laden.c
+
+
+Last modified: Wed May 8 10:24:52 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/SetChats.rst b/doc/sphinx/lfun/SetChats.rst
new file mode 100644
index 0000000..e14669c
--- /dev/null
+++ b/doc/sphinx/lfun/SetChats.rst
@@ -0,0 +1,95 @@
+SetChats()
+==========
+
+FUNKTION
+--------
+::
+
+ void SetChats(int chance,mixed strs);
+
+DEFINIERT IN
+------------
+::
+
+ /std/npc/chat.c
+
+ARGUMENTE
+---------
+::
+
+ chance
+ Prozentuale Wahrscheinlichkeit einer Ausgabe
+ strs
+ Stringarray mit den Monsterchats
+
+BESCHREIBUNG
+------------
+::
+
+ Der NPC gibt mit der Wahrscheinlichkeit <chance> pro Heartbeat einen
+ zufaellig gewaehlten Text aus dem Array <strs> von sich.
+ Die Arrayelemente koennen auch Closures oder
+ process_string()-Funktionen ("@@func@@") enthalten, die dann
+ aufgerufen werden und deren Rueckgabewerte das Monster dann ausgibt.
+ (Fuer keine Ausgabe dann Leerstring "" zurueckgeben!)
+ In diesen Funktionen ist this_player() das Monster selbst!
+ Fuer Zeilenumbrueche ist immer selbst zu sorgen.
+
+RUECKGABEWERT
+-------------
+::
+
+ keiner
+
+BEISPIELE
+---------
+::
+
+ Ein einfaches Beispiel:
+ // Prototype fuer Closure.
+ static string info1();
+ void create()
+ { ...
+ SetChats(20,
+ ({"Der Ork sagt: Hau ab, bevor ich Dich fresse.\n",
+ "Der Ork grinst Dich unverschaemt an.\n",
+ "Der Ork wedelt mit seinem Saebel vor Deinem Gesicht herum.\n",
+ "Der Ork droht Dir mit der Faust.\n",
+ #'info1,
+ "@@info2@@"}));
+ }
+ // Funktion als Closure. Prototype notwendig!
+ static string info1()
+ { if(QueryProp(P_HP)<QueryProp(P_ALIGN))
+ return"Gleich werde ich von hier fliehen!\n";
+ return"";
+ }
+ // Funktion als process_string().
+ string info2()
+ { return QueryProp(P_HP)==QueryProp(P_MAX_HP)?
+ "Der Ork grinst: Mir geht es fantastisch!\n":
+ "Der Ork seufzt: Mir ging es wirklich schon mal besser.\n";
+ }
+
+BEMERKUNGEN
+-----------
+::
+
+ Im Kampf werden keine Chats ausgegeben. Es ist dann SetAttackChats()
+ zu verwenden.
+ Funktionen als process_string() sollte man nicht mehr verwenden.
+ <chance> wird in der Property P_CHAT_CHANCE abgelegt. Um einen NPC
+ voruebergehend 'stillzulegen', kann man P_CHAT_CHANCE auf 0 setzen.
+ Wenn kein Spieler anwesend ist, haben NPC in der Regel keinen Heartbeat,
+ weswegen dann auch die Chats ausgeschaltet sind.
+ Spieler koennen NPC 'stillen', d.h. Chats und AttackChats abschalten.
+
+SIEHE AUCH
+----------
+::
+
+ P_CHAT_CHANCE, SetAttackChats(), process_string()
+
+
+Last modified: Sat Jan 18 18:48:06 2003 by Patryn
+
diff --git a/doc/sphinx/lfun/SetCoinsPerUnits.rst b/doc/sphinx/lfun/SetCoinsPerUnits.rst
new file mode 100644
index 0000000..5930204
--- /dev/null
+++ b/doc/sphinx/lfun/SetCoinsPerUnits.rst
@@ -0,0 +1,64 @@
+SetCoinsPerUnits()
+==================
+
+FUNKTION
+--------
+::
+
+ void SetCoinsPerUnits(int coins, int units);
+
+DEFINIERT IN
+------------
+::
+
+ /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+ coins
+ Zahl der Muenzen
+ units
+ Zahl der Einheiten
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird festgelegt, wieviel eine bestimmte Menge der Einheiten kostet.
+ Eine einzelne Einheit kostet coins/units Muenzen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Bei der Preisberechnung wird abgerundet. Hat man also ein Verhaeltnis
+ von einer Muenze pro zwei Einheiten, so ist der Preis einer einzelnen
+ Einheit 0!
+
+BEISPIELE
+---------
+::
+
+ Eine Einheit soll 3.5 Muenzen wert sein:
+
+ /* 7 Muenzen / 2 Einheiten = 3.5 Muenzen / Einheit */
+ SetCoinsPerUnits(7,2);
+
+SIEHE AUCH
+----------
+::
+
+ QueryCoinsPerUnits(), SetGramsPerUnits(), QueryGramsPerUnits(),
+ /std/unit.c
+
+
+Last modified: Wed May 8 10:24:57 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/SetDoorStatus.rst b/doc/sphinx/lfun/SetDoorStatus.rst
new file mode 100644
index 0000000..c5b9545
--- /dev/null
+++ b/doc/sphinx/lfun/SetDoorStatus.rst
@@ -0,0 +1,50 @@
+SetDoorStatus()
+===============
+
+FUNKTION
+--------
+::
+
+ void SetDoorStatus(string dest, int status);
+
+DEFINIERT IN
+------------
+::
+
+ /obj/doormaster.c
+
+ARGUMENTE
+---------
+::
+
+ <dest> = Zielraum der Tuer.
+ <status> = Der neue Zustand der Tuer.
+
+BESCHREIBUNG
+------------
+::
+
+ Der Zustand der Tuer, die von diesem Raum nach <dest> fuehrt, wird auf
+ <status> geaendert. Hierbei muss <status> einer der drei folgenden Werte
+ aus <doorroom.h> sein:
+
+ D_STATUS_LOCKED - Tuer abgeschlossen
+ D_STATUS_CLOSED - Tuer geschlossen
+ D_STATUS_OPEN - Tuer geoeffnet
+
+RUECKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ NewDoor(), QueryDoorKey(), QueryDoorStatus(), P_DOOR_INFOS,
+ /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+
+
+Letzte Aenderung: Don, 08.05.2014, Gabylon
+
diff --git a/doc/sphinx/lfun/SetEnemies.rst b/doc/sphinx/lfun/SetEnemies.rst
new file mode 100644
index 0000000..685d08f
--- /dev/null
+++ b/doc/sphinx/lfun/SetEnemies.rst
@@ -0,0 +1,53 @@
+SetEnemies()
+============
+
+FUNKTION
+--------
+::
+
+ mapping SetEnemies(object *myenemies);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ myenemies
+ Array: ({Gegnerarray, Zeitenarray})
+
+RUeCKGABEWERT
+-------------
+::
+
+ Internes Mapping mit bekannten Gegnern und Zeiten.
+
+BESCHREIBUNG
+------------
+::
+
+ Normalerweise fuegt man einzelne Gegner mittels InsertEnemy() ein und
+ loescht alte Feinde mittels StopHuntFor().
+
+ Um jedoch mit einem Schlag viele Veraenderungen vorzunehmen, kann man
+ die Funktion SetEnemies() nutzen.
+
+ Ihr uebergibt man ein Array mit einem Array mit den gewuenschten Gegnern
+ als und einem zweiten, gleichgrossen Array mit den Zeiten, wie lange
+ diese Gegner aktuell sein sollen, als Eintraege.
+
+ Die Funktion traegt diese Werte als Gegner mit entsprechender
+ Feindeszeit ein.
+
+SIEHE AUCH
+----------
+::
+
+ InsertEnemy(), StopHuntFor(), SelectEnemy(), PresentEnemies()
+
+10.Feb 2005 Gloinson
+
diff --git a/doc/sphinx/lfun/SetGramsPerUnits.rst b/doc/sphinx/lfun/SetGramsPerUnits.rst
new file mode 100644
index 0000000..10eac24
--- /dev/null
+++ b/doc/sphinx/lfun/SetGramsPerUnits.rst
@@ -0,0 +1,55 @@
+SetGramsPerUnits()
+==================
+
+FUNKTION
+--------
+::
+
+ void SetGramsPerUnits(int grams, int units);
+
+DEFINIERT IN
+------------
+::
+
+ /std/unit.c
+
+ARGUMENTE
+---------
+::
+
+ grams
+ Gewicht in Gramm
+ units
+ Zahl der Einheiten
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird festgelegt, wieviel eine bestimmte Menge der Einheiten wiegt.
+ Eine einzelne Einheit wiegt grams/units Gramm.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEISPIELE
+---------
+::
+
+ Vier Einheiten sollen 3 Gramm wiegen:
+
+ SetGramsPerUnits(3,4);
+
+SIEHE AUCH
+----------
+::
+
+ SetCoinsPerUnits(), QueryCoinsPerUnits(), QueryGramsPerUnits(),
+ /std/unit.c
+
+
+Last modified: Wed May 8 10:25:09 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/SetProp.rst b/doc/sphinx/lfun/SetProp.rst
new file mode 100644
index 0000000..32883b3
--- /dev/null
+++ b/doc/sphinx/lfun/SetProp.rst
@@ -0,0 +1,70 @@
+SetProp()
+=========
+
+FUNKTION
+--------
+::
+
+ public mixed SetProp(string name, mixed Value);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/properties.c
+ /sys/thing/properties.h (Prototyp)
+
+ARGUMENTE
+---------
+::
+
+ name - Property, deren Wert veraendert werden soll.
+ Value - Wert, auf den der Inhalt der Property gesetzt werden soll
+
+BESCHREIBUNG
+------------
+::
+
+ Der Datenwert der Property 'name' wird auf den Wert 'Value' gesetzt.
+
+ Existiert eine F_SET_METHOD oder eine _set_'name'()-Methode fuer
+ diese Property, so wird diese aufgerufen und ihr 'Value' uebergeben.
+ Eine F_SET_METHOD hat dabei Vorrang vor _set_'name'(), d.h.
+ _set_'name'() wird nach erfolgreicher F_QUERY_METHOD nicht mehr
+ gerufen.
+
+ (Diese Methoden nutzen dann Set(), um den Datenwert der Property
+ 'name' zu aendern. Teilweise werden aber auch interne Variablen so
+ oeffentlich gemacht und sind nicht in der ueber Set/Query verfuegbaren
+ Property 'name' abgelegt.)
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der Wert, der nun in der Property gespeichert ist.
+ In der Regel ist das 'Value'. Wenn die Property ueber eine SET_METHOD
+ oder eine _set_'name'()-Funktion verfuegt und diese 'Value' aendert
+ (zum Beispiel, indem sie 'Value' an einen bestimmten erlaubten
+ Wertebereich anpasst), kann der Rueckgabewert jedoch auch veraendert
+ sein.
+
+ Wenn die Property nicht veraendert werden darf, wird -1 zurueckgegeben.
+
+BEISPIELE
+---------
+::
+
+ // geben wir dem Zwerg eine Kurzbeschreibung
+ SetProp(P_SHORT, "Ein kleiner Zwerg");
+
+SIEHE AUCH
+----------
+::
+
+ Aehnliches: QueryProp(L), Set(L), Query(L)
+ Generell: SetProperties(L), QueryProperties(L)
+ Konzept: properties, /std/thing/properties.c
+
+15.Dez 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/SetProperties.rst b/doc/sphinx/lfun/SetProperties.rst
new file mode 100644
index 0000000..3595aaf
--- /dev/null
+++ b/doc/sphinx/lfun/SetProperties.rst
@@ -0,0 +1,48 @@
+SetProperties()
+===============
+
+FUNKTION
+--------
+::
+
+ void SetProperties(mapping props);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/properties.c
+
+ARGUMENTE
+---------
+::
+
+ props - Mapping mit den Daten fuer alle Properties
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion setzt angegebene Properties auf einen Schlag.
+ Mapping muss wie folgt aufgebaut sein:
+ ([ name: wert; flags; set_method; query_method,
+ name2: ... ]);
+
+BEMERKUNGEN
+-----------
+::
+
+ - diese Funktion wird von restore_object() verwendet, um nicht alle
+ restaurierten Properties einzeln setzen zu muessen.
+ - SECURED/PROTECTED/NOSETMETHOD Properties werden beruecksichtigt
+
+SIEHE AUCH
+----------
+::
+
+ Aehnliches: SetProp(L), QueryProp(L), Set(L), Query(L)
+ Generell: QueryProperties(L)
+ Konzept: properties, /std/thing/properties.c
+
+1.Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/SetRealAttribute.rst b/doc/sphinx/lfun/SetRealAttribute.rst
new file mode 100644
index 0000000..849d697
--- /dev/null
+++ b/doc/sphinx/lfun/SetRealAttribute.rst
@@ -0,0 +1,55 @@
+SetRealAttribute()
+==================
+
+FUNKTION
+--------
+::
+
+ int SetRealAttribute(string attr, int val)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+ attr - zu setzendes Attribut
+ val - Wert
+
+BESCHREIBUNG
+------------
+::
+
+ Setzt den realen Wert des Attributes, d.h. das reine Attribut,
+ wenn moeglich. Lediglich eine Alias-Methode fuer SetAttr().
+ (QueryAttribute() gibt also val + etwaige Offsets/Modifier zurueck)
+
+RUeCKGABEWERT
+-------------
+::
+
+ Den gesetzten Wert.
+
+BEMERKUNGEN
+-----------
+::
+
+ Bitte nicht auf Spieler anwenden!
+
+SIEHE AUCH
+----------
+::
+
+ QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+ SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+ SetTimedAttrModifier(), QueryTimedAttrModifier(),
+ DeleteTimedAttrModifier(),
+ P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+ P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/lfun/SetSpellFatigue.rst b/doc/sphinx/lfun/SetSpellFatigue.rst
new file mode 100644
index 0000000..16b5a6f
--- /dev/null
+++ b/doc/sphinx/lfun/SetSpellFatigue.rst
@@ -0,0 +1,100 @@
+SetSpellFatigue()
+=================
+
+FUNKTION
+--------
+::
+
+ public varargs int SetSpellFatigue(int duration, string key)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skills.c
+ /std/player/skills.c
+ /sys/living/skills.h
+
+ARGUMENTE
+---------
+::
+
+ int duration: Wie lang soll die Spruchermuedung andauern?
+ string key : Eindeutiger Name des Spruches, einer Gruppe von Spruechen
+ oder 0 fuer die globale Spruchermuedung.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion dient zum Verwalten von individuellen Spruchermuedungen
+ (Spellfatigue, Spruchsperren).
+ Hiermit lassen sich unabhaengige Ermuedungen/Sperren fuer einzelne
+ Sprueche oder Gruppen von Spruechen gestalten.
+
+ <duration> ist die Zeit (in Sekunden), welche die Spruchermuedung
+ anhalten soll (nicht die Endzeit).
+
+ Wird <key> nicht angegeben oder ist 0, wird die globale Spruchsperre
+ gesetzt (identisch zu der Property P_NEXT_SPELL_TIME), anderenfalls die
+ unter <key> gespeicherte Spruchermuedung.
+ Setzt man einen Eintrag ohne Angabe von <key> bedeutet dies damit auch,
+ dass der Wert von P_NEXT_SPELL_TIME geaendert wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+ -1 Der Eintrag <key> ist noch nicht abgelaufen, es wurde _keine_
+ neue Spruchermuedung/-Sperre gespeichert.
+
+ >0 Eintrag wurde gespeichert, Rueckgabewert ist die Zeit, zu der die
+ Sperre ablaeuft.
+
+BEISPIELE
+---------
+::
+
+ Ein Spell gehoert zu einer Gruppe von Spells mit dem Namen 'extrasuess'.
+ Er darf nur ausgefuehrt werden, wenn seit 5s kein anderer Spruch aus der
+ Gruppe ausgefuehrt wurde.
+ if (CalculateSpellSuccess(...) > x) {
+ // Spellfatigue setzen (und Erfolg pruefen!)
+ if (ob->SetSpellFatigue(5, "extrasuess") > -1) {
+ tell_object(ob, "Du fuetterst " + enemy->Name(WEN) + " mit einem "
+ "Stueck suesser Schokotorte.\n");
+ ...
+ }
+ else {
+ // Sauerei! Zu ermuedet fuer diesen Spruch. Fehlermdeldung ...
+ }
+ }
+ Dieses setzt natuerlich voraus, dass alle anderen Sprueche der Gruppe
+ "extrasuess" den gleichen <key> pruefen und setzen.
+ (Will man vor CalculateSpellSuccess() wissen, ob der Spruch ueberhaupt
+ gewirkt werden duerfte, sollte man hierzu dann CheckSpellFatigue()
+ verwenden.)
+
+BEMERKUNGEN
+-----------
+::
+
+ Die genauen Zeitdauern koennen von Spielern beeinflusst werden, sie
+ unterliegen der jeweiligen Einstellung von 'spruchermuedung', d.h. koennen
+ auf volle 2s aufgerundet werden. (Dies ist nicht der Fall bei NPC.)
+ Auch wenn diese Funktion zum Verwalten von beliebigen Zeitsperren genutzt
+ werden koennen, beschraenkt euch bitte auf Spruchermuedungen und benutzt
+ ansonsten check_and_update_timed_key(). Falls ihr diesbzgl. weitere/andere
+ Wuensche habt, sprecht den/die Mudlib-EM an.
+
+SIEHE AUCH
+----------
+::
+
+ CheckSpellFatigue(L), DeleteSpellFatigue(L)
+ P_NEXT_SPELL_TIME
+ spruchermuedung
+
+
+27.03.2010, Zesstra
+
diff --git a/doc/sphinx/lfun/SetStorageRoom.rst b/doc/sphinx/lfun/SetStorageRoom.rst
new file mode 100644
index 0000000..fa1b2b0
--- /dev/null
+++ b/doc/sphinx/lfun/SetStorageRoom.rst
@@ -0,0 +1,109 @@
+SetStorageRoom()
+================
+
+FUNKTION
+--------
+::
+
+ void SetStorageRoom(string store);
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/shop.c
+
+ARGUMENTE
+---------
+::
+
+ store
+ Dateiname des Lagers, in dem die aufgekauften Objekte aufbewahrt
+ werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion wird dem Laden bekannt gegeben, welches Objekt
+ als Lager fuer angekaufte Objekte dienen soll. Jeder Laden muss
+ explizit einen eigenen Lagerraum setzen, ansonsten wird ein
+ Laufzeitfehler ausgeloest und der Laden ist nicht ladbar.
+
+
+
+ Das Speicherobjekt sollte /std/store.c erben, da dort einige
+ Aufraeumfunktionen definiert sind. Entscheidend fuer selbige sind
+ die Properties P_MIN_STOCK und P_STORE_CONSUME.
+
+BEISPIELE
+---------
+::
+
+ Der Raum 'myladen.c' koennte etwa so aussehen:
+
+
+
+ // myladen.c
+ inherit "/std/shop";
+ #include <properties.h>
+
+
+
+ protected void create() {
+ ::create();
+ SetProp(...); // Beschreibung wie bei normalen Raeumen
+ SetStorageRoom("/d/beispiel/mystore");
+ AddFixedObject("/items/fackel");
+ }
+
+ In diesem Laden wird nun die Standardfackel als mengenmaessig
+ unbegrenzter Artikel verkauft.
+
+ Der zugehoerige Lagerraum 'mystore.c' kann dann im einfachsten Fall
+ so aussehen:
+
+
+
+ // mystore.c
+ inherit "/std/store";
+ #include <rooms.h> // Fuer AddItem-Konstanten
+
+
+
+ protected void create() {
+ ::create();
+ // KEINE weiteren Beschreibungen!
+ // 1. erbt der Speicher keine Beschreibungsmodule,
+ // 2. sollen da eh nur Sachen und keine Spieler rein!
+ AddItem("/items/schaufel", REFRESH_REMOVE);
+ }
+
+
+
+ Der Laden verkauft nun auch Schaufeln, jedoch nur eine pro Reset.
+
+HINWEISE:
+ Fuer standardmaessig verkaufte Waren beachte man den Unterschied
+ zwischen den Funktionen AddItem() und AddFixedObject().
+ Die erstgenannte Funktion ist im Lager zu verwenden, letztere jedoch
+ im Laden.
+
+SIEHE AUCH
+----------
+::
+
+ Allgemeines: laden
+ Funktionen: AddItem(L), AddFixedObject(L), RemoveFixedObject(L)
+ Basisobjekte: /std/store.c
+ Properties: P_MIN_STOCK, P_STORE_CONSUME
+
+
+Last modified: 19-Jun-2015, Arathorn
+
diff --git a/doc/sphinx/lfun/SetTimedAttrModifier.rst b/doc/sphinx/lfun/SetTimedAttrModifier.rst
new file mode 100644
index 0000000..17b2d9f
--- /dev/null
+++ b/doc/sphinx/lfun/SetTimedAttrModifier.rst
@@ -0,0 +1,114 @@
+SetTimedAttrModifier()
+======================
+
+FUNKTION
+--------
+::
+
+ int SetTimedAttrModifier(string key, mapping modifier,
+ int outdated, object dependent, mixed notify)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/attributes.c
+
+ARGUMENTE
+---------
+::
+
+ key - in P_TIMED_ATTR_MOD vorzunehmender oder zu
+ aendernder Eintrag
+ modifier - Mapping mit den Attributveraenderungen
+ outdated - Zeitpunkt zu dem die Attributveraenderungen
+ ablaufen sollen in Sekunden seit dem
+ 1. Jan 1970, 0.0:0 GMT oder 0
+ dependent - Objekt dessen Existenz eine Bedingung fuer die
+ Attributveraenderung sein soll oder 0
+ notify - Objekt oder File das mittels
+ NotifyTimedAttrModExpired ueber
+ den Attributablauf informiert werden soll
+
+BESCHREIBUNG
+------------
+::
+
+ Der zu key gehoerende Eintrag wird in P_TIMED_ATTR_MOD angelegt oder
+ modifiziert und update_max_sp_and_hp aufgerufen.
+ Es empfiehlt sich auf die Eindeutigkeit des string-Parameters key
+ besonderes Augenmerk zu legen.
+
+ Unter dem Key key wird in P_TIMED_ATTR_MOD ein Eintrag vorgenommen,
+ welcher die Attribute des Livings um die in modifier stehenden Offsets
+ veraendert.
+
+ Diese Veraenderung ist solange aktiv bis entweder die in outdated
+ stehende Zeit ueberschritten ist oder das in dependent uebergebene
+ Objekt nicht mehr existiert.
+ Sind beide Argumente 0 so laeuft die Attributveraenderung nicht ab
+ und kann durch DeleteTimedAttrModifier geloescht werden.
+ Laeuft die Attributveraenderung ab, so wird der in notify angegebene
+ Empfaenger mittels Aufruf NotifyTimedAttrModExpired davon
+ benachrichtigt.
+ Der Funktion NotifyTimedAttrModExpired wird als Argument der key
+ der abgelaufenen Attributveraenderung uebergeben.
+
+BEISPIELE
+---------
+::
+
+ Ein NPC kann einen Spieler auf die folgende Weise solange die
+ Attribute um eins herabsetzen bis entweder eine Stunde verstrichen
+ ist oder der NPC nicht mehr existiert zum Beispiel weil er getoetet
+ wurde.
+
+ player->SetTimedAttrModifier( player->query_real_name(),
+ ([A_STR:-1,A_INT:-1,A_DEX:-1,A_CON:-1]),
+ time()+3600,
+ this_object(),
+ this_object()
+ );
+
+ Will der NPC nun noch darauf reagieren, dass die Attributmodifikation
+ durch Timeout abgelaufen ist, so koennte dies folgendermassen geschehen.
+
+ void NotifyTimedAttrModExpired(string str)
+ {
+ // Die Funktion wird aus dem Lebewesen gerufen, in welchem der Mod
+ // gerade abgelaufen ist. Also Meldungsausgabe an
+ // previous_object().
+ tell_object(previous_object()
+ ,"Da hast Du aber nochmal Glueck gehabt.\n");
+ }
+
+RUeCKGABEWERT
+-------------
+::
+
+ TATTR_INVALID_ARGS - Im Falle eines fehlenden key-Arguments,
+ eines fehlenden modifier-Arguments oder
+ eines bereits abgelaufenen
+ outdatet-Arguments
+ TATTR_OK - Im Erfolgsfall
+
+ Die Rueckgabewerte sind in /sys/living/attributes.h definiert.
+
+SIEHE AUCH
+----------
+::
+
+ Attribute: QueryAttribute(), SetAttribute()
+ SetRealAttribute(), QueryRealAttribute(),
+ QueryAttributeOffset(),
+ UpdateAttributes()
+ Methoden: QueryTimedAttrModifier(), DeleteTimedAttrModifier()
+ Callback: NotifyTimedAttrModExpired()
+ Properties: P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS
+ P_X_ATTR_MOD, P_M_ATTR_MOD
+ P_TIMED_ATTR_MOD
+ Sonstiges: /std/living/attributes.c
+
+LETZTE Aenderung:
+15.02.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/ShowDoors.rst b/doc/sphinx/lfun/ShowDoors.rst
new file mode 100644
index 0000000..c674397
--- /dev/null
+++ b/doc/sphinx/lfun/ShowDoors.rst
@@ -0,0 +1,46 @@
+ShowDoors()
+===========
+
+FUNKTION
+--------
+::
+
+ void ShowDoors()
+
+ARGUMENTE
+---------
+::
+
+ Keine.
+
+BESCHREIBUNG
+------------
+::
+
+ Zeigt alle Sehertor an, die der Seher (this_player()) schon kennt.
+ Falls in seiner Umgebung ein Tor steht, so wird dieses eingeklammert.
+
+RUECKGABEWERT
+-------------
+::
+
+ Keiner.
+
+BEMERKUNGEN
+-----------
+::
+
+ Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
+
+BEISPIELE
+---------
+::
+
+ /d/seher/portale/sehertormaster->ShowDoors()
+
+SIEHE AUCH
+----------
+::
+
+ DiscoverDoor, DoorIsKnown, Teleport, GetDoorsMapping
+
diff --git a/doc/sphinx/lfun/ShowPropList.rst b/doc/sphinx/lfun/ShowPropList.rst
new file mode 100644
index 0000000..40a1df3
--- /dev/null
+++ b/doc/sphinx/lfun/ShowPropList.rst
@@ -0,0 +1,75 @@
+ShowPropList()
+==============
+
+FUNKTION
+--------
+::
+
+ void ShowPropList(string *props);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/util.c
+
+ARGUMENTE
+---------
+::
+
+ props
+ Array von Strings mit den Namen der Properties, die ausgegeben
+ werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt die Inhalte der in props angegebenen Properties aus.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEISPIELE
+---------
+::
+
+ Sei test.c folgendes Programm:
+
+ inherit "std/thing";
+ inherit "std/thing/util";
+
+ create() {
+ ::create();
+
+ SetProp(P_SHORT, "Kurz");
+ SetProp(P_NAME, ({ "Name", "Namens", "Namen", "Namen" }));
+ SetProp("me", this_object() );
+ }
+
+ Mit xcall test->ShowPropList( ({ P_SHORT, P_NAME, "me" }) ); erhielte
+ man dann folgende Ausgabe:
+
+ *short: "Kurz"
+ *name: ({ "Name", "Namens", "Namen", "Namen" })
+ *me: OBJ(/players/wargon/test#12345)
+
+BEMERKUNGEN
+-----------
+::
+
+ Mit dem Befehl xprops des MGtools lassen sich uebrigens saemtliche
+ Properties eines Objekte auf einen Schlag ausgeben.
+
+SIEHE AUCH
+----------
+::
+
+ /std/ting/util.c
+
+
+Last modified: Wed May 8 10:25:26 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/SkillResTransfer.rst b/doc/sphinx/lfun/SkillResTransfer.rst
new file mode 100644
index 0000000..47dd28b
--- /dev/null
+++ b/doc/sphinx/lfun/SkillResTransfer.rst
@@ -0,0 +1,48 @@
+SkillResTransfer()
+==================
+
+FUNKTION
+--------
+::
+
+ protected void SkillResTransfer(mapping from_M, mapping to_M)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skill_utils
+
+ARGUMENTE
+---------
+::
+
+ mapping from_M: Mapping mit zu kopierenden Werten
+ mapping to_M: Zielmapping
+
+BESCHREIBUNG
+------------
+::
+
+ Interne Methode, die zB (!) waehrend der Ausfuehrung von Attack() durch
+ Skills oder P_TMP_ATTACK_MOD geaenderte Werte selektiert in das
+ Hauptangriffsmapping uebertraegt.
+
+ Derzeit werden folgende Werte kopiert:
+ SI_SKILLDAMAGE, SI_SKILLDAMAGE_MSG, SI_SKILLDAMAGE_MSG2,
+ SI_SKILLDAMAGE_TYPE, SI_SPELL
+
+BEMERKUNGEN
+-----------
+::
+
+ * wird an mehreren Stellen, nicht nur der living/combat verwendet
+
+SIEHE AUCH
+----------
+::
+
+ P_TMP_ATTACK_MOD, UseSkill (Waffenfaehigkeiten)
+
+18.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/lfun/SpellAttack.rst b/doc/sphinx/lfun/SpellAttack.rst
new file mode 100644
index 0000000..1a3fe70
--- /dev/null
+++ b/doc/sphinx/lfun/SpellAttack.rst
@@ -0,0 +1,97 @@
+SpellAttack()
+=============
+
+FUNKTION
+--------
+::
+
+ void SpellAttack(object enemy)
+
+ARGUMENTE
+---------
+::
+
+ enemy: Der Feind.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird in jedem Heartbeat eines NPCs ausgefuehrt,
+ falls nicht P_DISABLE_ATTACK gesetzt ist (Paralyse).
+ Standardmaessig tut diese Funktion nichts, aber man kann sie
+ ueberschreiben, damit in jedem Heartbeat Angriffe mit Spells
+ ausgefuehrt werden.
+
+ Man sollte hierbei ein random() einbauen, damit der NPC nicht
+ in jedem Heartbeat auch wirklich einen Angriff ausfuehrt.
+ Ausserdem sollte man auch fuer eventuelle Ausgaben sorgen.
+
+RUECKGABEWERT
+-------------
+::
+
+ Keiner.
+
+BEMERKUNG
+---------
+::
+
+ Die AttackChats, die mittels SetAttackChats gesetzt werden
+ koennen, macht im Grunde nichts anderes, aber Chats sind halt
+ keine Angriffe. :-)
+
+BEISPIELE
+---------
+::
+
+ Im Grunde ist dieses simple Beispiel eine Nachbildung von
+ Attack-Chats und soll dementsprechend nur der Anschauung dienen.
+
+ void SpellAttack(object enemy)
+ {
+ // mit 80% Wahrscheinlichkeit wird nichts gemacht.
+ switch(random(5))
+ {
+ case 0:
+ write("Der Ork tritt Dir in den Hintern.\n");
+ return;
+ case 1:
+ write("Der Ork bruellt: Lebend kommst Du hier nicht raus!\n");
+ return;
+ case 2:
+ write("Der Ork blutet schon aus mehreren Wunden.\n");
+ return;
+ case 3:
+ write(knirsch(enemy));
+ return;
+ default:
+ return;
+ }
+ }
+
+ string knirsch(object enemy)
+ {
+ if (objectp(enemy))
+ helm = enemy->QueryArmourByType(AT_HELMET);
+ if (objectp(helm))
+ {
+ helm->Damage(1);
+ return "Der Ork beschaedigt Deinen Helm!\n";
+ }
+ else
+ return ""; // keine Meldung
+ }
+
+SIEHE AUCH
+----------
+::
+
+ "Attack", "SetAttackChats", /std/npc/combat.c
+
+LETZTE AENDERUNG
+----------------
+::
+
+ Don, 27.02.2003, 12:50:00 von Hirudo
+
diff --git a/doc/sphinx/lfun/SpellDefend.rst b/doc/sphinx/lfun/SpellDefend.rst
new file mode 100644
index 0000000..8d2c140
--- /dev/null
+++ b/doc/sphinx/lfun/SpellDefend.rst
@@ -0,0 +1,71 @@
+SpellDefend()
+=============
+
+FUNKTION
+--------
+::
+
+ public int SpellDefend(object caster,mapping sinfo);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ object caster - Gegner
+ mapping sinfo - Zusatzinformationen zum Spell
+
+BESCHREIBUNG
+------------
+::
+
+ Ueber den Skill SK_SPELL_DEFEND mit den Aufrufparametern
+ SI_ENEMY : <caster>
+ und
+ SI_SKILLARG : <sinfo>
+ wird eine Abwehrchance in 0.01%-Schritten fuer einen
+ Spell ermittelt, also 0% - 100% bzw. als Rueckgabewert
+ 0 - 10000.
+
+
+
+ Weiterhin wird automatisch P_MAGIC_RESISTANCE_OFFSET und der Skill
+ SK_SPELL_DEFEND beruecksichtigt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Die Abwehrchance in 0.01%-Schritten.
+
+
+
+ Fuer Spieler wird dieser Rueckgabewert auf 3333 maximal, also 33,33%
+ Abwehrmoeglichkeit beschraenkt.
+
+BEMERKUNGEN
+-----------
+::
+
+ Die Spellbooks muessen selbst auf die Auswertung dieser Funktion
+ achten! Dies geschieht nur im Falle von TryGlobalAttackSpell()
+ und bei Spells fuer NPCs mittels P_SPELLS automatisch!
+
+ Bitte bei NPCs nicht pauschal 100% / 10000 zurueckgeben. Danke.
+
+SIEHE AUCH
+----------
+::
+
+ Verwandt: P_MAGIC_RESISTANCE_OFFSET
+ Aehnlich: P_NOMAGIC
+ Generell: TryGlobalAttackSpell, /std/spellbook.c
+ Sonstiges: UseSkill, SK_SPELL_DEFEND
+
+29.Dez 2007 Gloinson
+
diff --git a/doc/sphinx/lfun/SpellInform.rst b/doc/sphinx/lfun/SpellInform.rst
new file mode 100644
index 0000000..ac6afdf
--- /dev/null
+++ b/doc/sphinx/lfun/SpellInform.rst
@@ -0,0 +1,52 @@
+SpellInform()
+=============
+
+FUNKTION
+--------
+::
+
+ void SpellInform(caster,spell,sinfo);
+
+DEFINIERT IN
+------------
+::
+
+ selber zu definieren
+
+ARGUMENTE
+---------
+::
+
+ pl
+ Das Lebewesen, das erfolgreich gezaubert hat.
+ spell
+ Der Name des gezauberten Spells
+ sinfo
+ Das komplette Spellmapping des gezauberten Spells
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird vom Spellbuch einer Gilde in der Umgebung
+ (Environment) eines Lebewesens aufgerufen, wenn immer das Lebewesen
+ einen Spell _erfolgreich_ gezaubert hat.
+ Bemerkung: Bitte vermeiden, aufwaendige Sachen in der Funktion zu
+ machen, da sonst u.U. deswegen Gilden anfangen zu buggen. Falls es
+ sein muss, macht dann lieber einen call_out mit 2s Wartezeit.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+
+
+----------------------------------------------------------------------------
+16.04.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/Start.rst b/doc/sphinx/lfun/Start.rst
new file mode 100644
index 0000000..d041e15
--- /dev/null
+++ b/doc/sphinx/lfun/Start.rst
@@ -0,0 +1,45 @@
+Start()
+=======
+
+FUNKTION
+--------
+::
+
+ varargs void Start(int pos);
+
+DEFINIERT IN
+------------
+::
+
+ /std/transport.c
+
+ARGUMENTE
+---------
+::
+
+ pos
+ Fahrplanstation, an der begonnen werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion schickt den Transporter auf die Strecke. Dabei beginnt
+ der Weg an der mit pos bezeichneten Stelle im Fahrplan. Default ist 0,
+ d.h. der Transporter beginnt seinen Weg an der ersten Fahrplanposition.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ Halt(), /std/transport.c
+
+
+Last modified: Wed May 8 10:25:30 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/StopHuntFor.rst b/doc/sphinx/lfun/StopHuntFor.rst
new file mode 100644
index 0000000..eb6300b
--- /dev/null
+++ b/doc/sphinx/lfun/StopHuntFor.rst
@@ -0,0 +1,78 @@
+StopHuntFor()
+=============
+
+FUNKTION
+--------
+::
+
+ varargs int StopHuntFor(object arg,int silent);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ arg
+ Der Gegner, welcher nicht mehr bekaempft werden soll.
+ silent
+ Flag, welches gesetzt anzeigt, dass die beiden Ex-Streithaehne
+ ueber das einseitige Friedensangebot nicht informiert werden
+ sollen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Flag: Bei 0 war der Gegner nicht auffindbar, bei 1 Erfolg.
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion kann man ein Lebewesen <arg> als Gegner
+ austragen. Im Normalfall erhalten sowohl das aktuelle Objekt, als
+ auch der Gegner eine Information darueber. Dies kann jedoch mit dem
+ gesetzten Flag <silent> unterbunden werden.
+ Es ist auch moeglich, auf diese Meldung Einfluss zu nehmen, indem
+ man die Funktion StopHuntText() ueberschreibt, welche dafuer
+ verantwortlich ist.
+ Achtung: Um zwischen beiden Streithaehnen Frieden zu schliessen,
+ muss der eine Gegner jeweils bei dem anderen ausgetragen werden. Ein
+ einzelnes StopHuntFor() ist sozusagen nur ein einseitiges
+ Friedensangebot.
+
+BEMERKUNGEN
+-----------
+::
+
+ Soll ein Viech unter bestimmten Umstaenden nicht angreifbar sein, ist in
+ keinem Fall StopHuntFor() im Defend() zu verwenden, sondern P_NO_ATTACK.
+ Grund: Stoppt man unliebsame Kaempfe jeweils am Anfang vom Defend, kann ein
+ Gegner gefahrlos Angriffsspells ausfuehren (und ueben), ohne dass die Gefahr
+ besteht, dass der NPC zurueckschlaegt.
+
+BEISPIELE
+---------
+::
+
+ Man will aus irgendeinem Grund den Kampf zwischen sich und Gegner enemy
+ einstellen:
+ ...
+ StopHuntFor(enemy); // enemy nicht mehr bekaempfen
+ enemy->StopHuntFor(this_object()); // enemy soll mich nicht bekaempfen.
+ ...
+
+SIEHE AUCH
+----------
+::
+
+ StopHuntText(), SelectEnemy(), QueryEnemies(), IsEnemy()
+
+
+16.03.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/StopHuntText.rst b/doc/sphinx/lfun/StopHuntText.rst
new file mode 100644
index 0000000..400f960
--- /dev/null
+++ b/doc/sphinx/lfun/StopHuntText.rst
@@ -0,0 +1,78 @@
+StopHuntText()
+==============
+
+FUNKTION
+--------
+::
+
+ void StopHuntText(object arg);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ arg
+ Der Gegner, welcher nicht mehr bekaempft wird.
+
+BESCHREIBUNG
+------------
+::
+
+ Mit der Funktion StopHuntFor() kann man ein Lebewesen als Gegner
+ austragen. Dabei erhalten sowohl der Gegner, als auch das Lebewesen,
+ welches (einseitig!) Frieden schliesst, jeweils eine Meldung, sofern
+ man dies nicht mittels eines Flags unterbindet.
+ Es ist nun moeglich, auf diese Meldung Einfluss zu nehmen, indem
+ man die Funktion StopHuntText() ueberschreibt, welche dafuer
+ verantwortlich ist.
+
+BEISPIEL
+--------
+::
+
+ Ein Lebewesen moechte einen Kampf sofort abbrechen, wenn es von
+ einem Frosch angegriffen wird:
+ int Defend(int dam,mixed dam_type,mixed spell,object enemy)
+ { if(enemy&&enemy->QueryProp(P_FROG))
+ { if(StopHuntFor(enemy))
+ { // wenn Frosch angreifen will, der noch kein Gegner war
+ tell_object(arg,
+ this_object()->Name(WER)+" kaempft nicht mit Dir.\n"
+ +"Wahrscheinlich werden Froesche verschont.\n");
+ tell_object(this_object(),
+ "Der bloede Frosch wollte Dich doch tatsaechlich angreifen.\n");
+ }
+ enemy->StopHuntFor(this_object(),1);
+ return 0;
+ }
+ return::Defend(dam,dam_type,spell,enemy);
+ }
+ // wird nur aufgerufen, wenn der Gegner irgendwann Frosch wurde
+ void StopHuntText(object arg)
+ { tell_object(arg,
+ this_object()->Name(WER)+" jagd Dich nicht mehr.\n"
+ +"Wahrscheinlich werden Froesche verschont.\n");
+ tell_object(this_object(),
+ "Dein Gegner ist doch tatsaechlich ploetzlich Frosch geworden!\n");
+ }
+ Warum braucht man nun das erste StopHuntFor(), wenn doch Gegner erst
+ in ::Defend() eingetragen werden, welches doch gar nicht ausgefuehrt
+ wird, wenn der Gegner ein Frosch ist? Man beachte hierbei, dass der
+ Gegner ja auch waehrend des Kampfes oder waehrend der Feindschaft
+ irgendwann Frosch werden koennte und dann schon Gegner war.
+
+SIEHE AUCH
+----------
+::
+
+ StopHuntFor(), SelectEnemy(), QueryEnemies(), IsEnemy()
+
+
+Last modified: Wed May 26 16:47:51 1999 by Patryn
+
diff --git a/doc/sphinx/lfun/SuggestArticle.rst b/doc/sphinx/lfun/SuggestArticle.rst
new file mode 100644
index 0000000..fb72447
--- /dev/null
+++ b/doc/sphinx/lfun/SuggestArticle.rst
@@ -0,0 +1,58 @@
+SuggestArticle()
+================
+
+FUNKTION
+--------
+::
+
+ varargs int SuggestArticle(string name);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/language.c
+
+ARGUMENTE
+---------
+::
+
+ name
+ Der Name zur Entscheidungshilfe.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion versucht herauszufinden, ob der Artikel zu diesem Objekt
+ ein unbestimmter oder besser ein bestimmter Artikel sein sollte. Die
+ Vorgehensweise ist folgende: Gibt es in der Umgebung dieses Objektes
+ ein weiteres Objekt, das den Namen name besitzt, so wird ein
+ unbestimmter Artikel vorgeschlagen, ansonsten ein bestimmter.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn ein unbestimmter Artikel geeignet ist, ansonsten 1.
+
+BEMERKUNGEN
+-----------
+::
+
+ Der Vergleich erfolgt mittels der Property P_NAME. Um Erfolg zu haben,
+ sollte man diese Funktion daher in der Form
+
+ SuggestArticle(QueryProp(P_NAME))
+
+ aufrufen.
+
+SIEHE AUCH
+----------
+::
+
+ QueryArticle(), name(), /std/thing/language.c
+
+
+Last modified: Wed May 8 10:25:34 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/SwapRows.rst b/doc/sphinx/lfun/SwapRows.rst
new file mode 100644
index 0000000..93f27b4
--- /dev/null
+++ b/doc/sphinx/lfun/SwapRows.rst
@@ -0,0 +1,61 @@
+SwapRows()
+==========
+
+FUNKTION
+--------
+::
+
+ int SwapRows( object ob1, object ob2 )
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ ob1, ob2 - Spieler, die die Reihen tauschen sollen.
+
+BESCHREIBUNG
+------------
+::
+
+ Die angegebenen Spieler tauschen die Reihen.
+
+RUECKGABEWERT
+-------------
+::
+
+ 1 bei erfolgreichem Tausch, 0 sonst.
+
+BEMERKUNG
+---------
+::
+
+ Der Tausch wird nur durchgefuehrt, wenn die angegebenen Spieler auch
+ tatsaechlich im Team sind und damit kein NPC vor einen Spieler gestellt
+ wuerde.
+ Moechte man wissen, ob ein Spieler eine Reihe gewechselt hat, muss man
+ sich der Hilfe eines Hooks bedienen: H_HOOK_TEAMROWCHANGE
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_TEAM_LEADER, P_TEAM_ASSOC_MEMBERS,
+ P_TEAM_NEWMEMBER
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: AssocMember, DeAssocMember, InsertEnemyTeam
+ SelectNearEnemy, SelectFarEnemy
+ Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+ PresentTeamPosition
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/TakeFlaw.rst b/doc/sphinx/lfun/TakeFlaw.rst
new file mode 100644
index 0000000..2ab1916
--- /dev/null
+++ b/doc/sphinx/lfun/TakeFlaw.rst
@@ -0,0 +1,101 @@
+TakeFlaw()
+==========
+
+FUNKTION
+--------
+::
+
+ varargs void TakeFlaw(object enemy); (Waffen)
+ varargs void TakeFlaw(mixed dam_types,mapping einfos) (Ruestungen)
+
+DEFINIERT IN
+------------
+::
+
+ /std/armour/combat.c,
+ /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird in Waffen und Ruestungen waehrend des Kampfes
+ aufgerufen. In einer Waffe erfolgt der Aufruf bei jedem Schlag mit
+ dieser Waffe, bei Ruestungen wird TakeFlaw() in einer zufaellig
+ ausgewaehlten getragenen Ruestung aufgerufen.
+ Waffen bekommen das Gegnerobjekt uebergeben, Ruestungen die erweiterten
+ DefendInfos (s. dort fuer Details). Aufgrund dieser Informationen kann
+ man den Schaden, den ein Gegenstand nimmt, flexibler gestalten (z.B. bei
+ einer Waffe in Abhaengigkeit von P_BODY des Gegners.)
+
+ Soweit man die Funktion nicht ueberlaedt, bewirkt sie nichts weiter als
+ das Erhoehen eines Zaehlers, der mit QueryFlaw() abgefragt werden kann.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Die Waffen-/ Ruestungsklasse wird nicht automatisch reduziert! Wenn
+ eine Waffe oder Ruestung sich abnutzen soll, muss man TakeFlaw()
+ ueberladen und dort entsprechend handeln, oder (fuer einfache
+ Faelle) die Property P_QUALITY setzen.
+
+BEISPIELE
+---------
+::
+
+ Eine Waffe, deren Waffenklasse alle 20 Schlaege um 1 abnimmt:
+
+ inherit "std/weapon";
+
+ #include <properties.h>
+ #include <combat.h>
+
+ create()
+ {
+ /* Das Uebliche... */
+ }
+
+ TakeFlaw()
+ {
+ int flaw;
+
+ /* erst mal den Zaehler erhoehen... */
+ ::TakeFlaw();
+
+ /* jetzt den aktuellen Zaehlerstand abfragen */
+ flaw = QueryFlaw()[0];
+
+ /* Abzug nur jeden 20. Schlag */
+ if (!(flaw % 20)) {
+ /* So, jetzt fuer den Schaden sorgen. Hierfuer benutzt */
+ /* man am sichersten die eingebaute Funktion Damage() */
+ Damage(1);
+ }
+ }
+
+ Dieses einfache Beispiel haette natuerlich auch ueber ein
+ SetProp(P_QUALITY,20); im create() realisiert werden koennen.
+
+SIEHE AUCH
+----------
+::
+
+ QueryFlaw(), Damage(), DefendInfo, P_QUIALITY, /std/armour/combat.c,
+ /std/weapon/combat.c
+
+
+Last modified: Thu May 22 10:30:10 1997 by Paracelsus
+
diff --git a/doc/sphinx/lfun/TeamFlee.rst b/doc/sphinx/lfun/TeamFlee.rst
new file mode 100644
index 0000000..4146462
--- /dev/null
+++ b/doc/sphinx/lfun/TeamFlee.rst
@@ -0,0 +1,61 @@
+TeamFlee()
+==========
+
+FUNKTION
+--------
+::
+
+ int TeamFlee()
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Spieler wird zur Flucht in hintere Reihe veranlasst, falls er dies
+ eingestellt hat.
+
+RUECKGABEWERT
+-------------
+::
+
+ 1, falls der Spieler in eine hintere Reihe fliehen wollte und nach
+ dem Versuch nicht mehr in der ersten Reihe steht, sonst 0.
+
+BEMERKUNGEN
+-----------
+::
+
+ Beim Teamleiter fuehrt der Fluchtversuch dazu, dass sein Team nicht
+ mehr folgt.
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
+ SelectNearEnemy, SelectFarEnemy
+ Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+ PresentTeamPosition, SwapRows
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/TeamMembers.rst b/doc/sphinx/lfun/TeamMembers.rst
new file mode 100644
index 0000000..055604d
--- /dev/null
+++ b/doc/sphinx/lfun/TeamMembers.rst
@@ -0,0 +1,59 @@
+TeamMembers()
+=============
+
+FUNKTION
+--------
+::
+
+ object *TeamMembers()
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Liefert Teammitglieder des Teams des Spielers.
+
+RUECKGABEWERT
+-------------
+::
+
+ Array mit ALLEN Teammitgliedern.
+
+BEMERKUNGEN
+-----------
+::
+
+ Falls der Spieler in keinem Team ist, enthaelt das Array nur den
+ Spieler.
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: IsTeamLeader
+ Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
+ SelectNearEnemy, SelectFarEnemy
+ Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+ PresentTeamPosition, SwapRows
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/TeamPrefix.rst b/doc/sphinx/lfun/TeamPrefix.rst
new file mode 100644
index 0000000..ab73ae9
--- /dev/null
+++ b/doc/sphinx/lfun/TeamPrefix.rst
@@ -0,0 +1,57 @@
+TeamPrefix()
+============
+
+FUNKTION
+--------
+::
+
+ string TeamPrefix()
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/team.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Ergibt Team-Prefix eines Spielers.
+
+RUECKGABEWERT
+-------------
+::
+
+ "[Team Teamname] ", falls der Spieler in einem Team ist,
+ "" sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+SIEHE AUCH
+----------
+::
+
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
+ SelectNearEnemy, SelectFarEnemy
+ Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+ PresentTeamPosition, SwapRows
+ Sonstiges: teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/lfun/Teleport.rst b/doc/sphinx/lfun/Teleport.rst
new file mode 100644
index 0000000..9c4cbf4
--- /dev/null
+++ b/doc/sphinx/lfun/Teleport.rst
@@ -0,0 +1,51 @@
+Teleport()
+==========
+
+FUNKTION
+--------
+::
+
+ int Teleport(string ziel)
+
+ARGUMENTE
+---------
+::
+
+ ziel: Nummer des Sehertors, zu dem teleportiert werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Teleportiert den Seher (this_player()) zu dem Tor mit der angegebenen
+ Nummer. Falls keine Nummer angegeben wird, wird mit ShowDoors() die
+ Liste der bekannten Tore angezeigt und auf die Eingabe einer Nummer
+ gewartet.
+
+RUECKGABEWERT
+-------------
+::
+
+ 0, falls der Seher nicht neben einem Tor steht, dass er kennt.
+ 1 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+ Der Seher muss in einem Raum stehen, in dem sich ein Sehertor befindet,
+ dass er kennt. Der Seher muss auch das angegebene Ziel kennen.
+ Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
+
+BEISPIELE
+---------
+::
+
+ /d/seher/portale/sehertormaster->Teleport(1)
+
+SIEHE AUCH
+----------
+::
+
+ DiscoverDoor, DoorIsKnown, ShowDoors, GetDoorsMapping
+
diff --git a/doc/sphinx/lfun/TestIgnore.rst b/doc/sphinx/lfun/TestIgnore.rst
new file mode 100644
index 0000000..7c77dbb
--- /dev/null
+++ b/doc/sphinx/lfun/TestIgnore.rst
@@ -0,0 +1,88 @@
+TestIgnore()
+============
+
+FUNKTION
+--------
+::
+
+ public int TestIgnore(string|string* arg)
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/comm.c
+
+ARGUMENTE
+---------
+::
+
+ arg
+ String oder Array von Strings, die getestet werden sollen,
+ Format jeweils: [spieler].aktion[.qualifizierer]
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn arg nicht ignoriert wird
+ MSG_IGNORED, wenn (min. ein Element von) arg ignoriert wird
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird geprueft, ob der Spieler irgendeinen Eintrag auf seiner Liste
+ hat, der dazu fuehrt, dass <arg> ignoriert wird. Hierbei kommen je nach
+ den Angaben in <arg> folgende Regeln zum Tragen:
+ 1) spieler
+ Wird der Spieler ignoriert?
+ 2) .aktion
+ Ignoriert der Spieler .aktion, d.h. die Aktion komplett (OHNE
+ Qualifizierer)?
+ 3) spieler.aktion
+ Ignoriert der Spieler spieler, .aktion oder spieler.aktion?
+ 4) spieler.aktion.qualifizierer
+ Ignoriert der Spieler spieler, .aktion, spieler.aktion oder
+ spieler.aktion.qualifizierer?
+ 5) .aktion.qualifizierer
+ Ignoriert der Spieler .aktion oder .aktion.qualifizierer?
+
+ Da TestIgnore() damit durchaus etwas aufwendiger sein kann, sollte
+ man dies nicht unnoetig oft aufrufen. (Braucht man das Ergebnis z.B.
+ kurz spaeter nochmal, koennte man das Ergebnis speichern.) Wird der
+ Qualifizierer nicht gebraucht, sollte man ihn weglassen.
+
+BEISPIEL
+--------
+::
+
+ if (!this_player()->TestIgnore("andy"))
+ tell_object(this_player(), "Andy teilt Dir mit: Hallo!\n");
+
+ // Beispiel fuer eine Ignore-Check fuer Aktion (kratzen) fuer einen
+ // Spieler (this_player()) an einem anderen Spieler (target)
+ if (!target->TestIgnore( ({getuid(this_player()) + ".kratze",
+ getuid(this_player()) + ".kratz"}) ))
+ {
+ tell_object(target, this_player()->Name()+" kratzt dich.\n");
+ tell_object(this_player(), "Du kratzt "+target->Name()+".\n");
+ }
+ else
+ tell_object(this_player(), target->Name()+" ignoriert dich.\n");
+
+ // allumfassender Ignorier-Check in einer Gilde (Klerus) auf
+ // eine Aktion (kurieren) fuer einen bestimmten Spieler (den caster)
+ // an einem zu kurierenden Spieler (target)
+ if (target->TestIgnore(getuid(caster)+".kuriere.klerus"))
+ tell_object(caster, break_string(
+ target->Name()+" ignoriert deinen Versuch.", 78));
+
+SIEHE AUCH
+----------
+::
+
+ P_IGNORE, AddIgnore, RemoveIgnore, TestIgnoreSimple, /std/player/comm.c
+
+26.04.2014 Zesstra
+
diff --git a/doc/sphinx/lfun/TestIgnoreSimple.rst b/doc/sphinx/lfun/TestIgnoreSimple.rst
new file mode 100644
index 0000000..2082c30
--- /dev/null
+++ b/doc/sphinx/lfun/TestIgnoreSimple.rst
@@ -0,0 +1,77 @@
+TestIgnoreSimple()
+==================
+
+FUNKTION
+--------
+::
+
+ public int TestIgnoreSimple(string *arg)
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/comm.c
+
+ARGUMENTE
+---------
+::
+
+ arg
+ Liste von Strings, die getestet werden sollen
+
+BESCHREIBUNG
+------------
+::
+
+ TestIgnoreSimple() prueft, ob der Spieler min. einen der uebergebenen
+ Eintraege auf seiner Ignoriereliste hat.
+ Falls man mehrere Eintraege pruefen muss/moechte, ist es schneller, alle
+ Eintraege in einem zu uebergeben anstatt fuer jeden einzeln
+ TestIgnoreSimple() aufzurufen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, falls es mindestens eine Uebereinstimmungen von arg und der
+ Ignoriere-Liste des Spielers gibt.
+ 0, sonst.
+
+BEISPIEL
+--------
+::
+
+ if (!this_player()->TestIgnoreSimple(({"andy"})))
+ tell_object(this_player(), "Andy teilt Dir mit: Hallo!\n");
+
+ // Beispiel fuer eine Ignore-Check fuer Aktion (kratzen) fuer einen
+ // Spieler (this_player()) an einem anderen Spieler (target)
+ if (!target->TestIgnoreSimple(getuid(this_player()),
+ getuid(this_player())+".kratz",
+ getuid(this_player())+".kratze",
+ ".kratz", ".kratze"}))) {
+ tell_object(target, this_player()->Name()+" kratzt dich.\n");
+ tell_object(this_player(), "Du kratzt "+target->Name()+".\n");
+ } else
+ tell_object(this_player(), target->Name()+" ignoriert dich.\n");
+
+ // allumfassender Ignorier-Check in einer Gilde (Klerus) auf
+ // eine Aktion (kurieren) fuer einen bestimmten Spieler (den caster)
+ // an einem zu kurierenden Spieler (target)
+ if (target->TestIgnoreSimple(({getuid(caster),
+ getuid(caster)+".kuriere",
+ getuid(caster)+".kuriere.klerus",
+ ".kuriere",
+ ".kuriere.klerus"})))
+ tell_object(caster, break_string(
+ target->Name()+" ignoriert deinen Versuch.", 78));
+
+SIEHE AUCH
+----------
+::
+
+ P_IGNORE, AddIgnore, RemoveIgnore, TestIgnore, /std/player/comm.c
+
+26.04.2014 Zesstra
+
diff --git a/doc/sphinx/lfun/TestLimitViolation.rst b/doc/sphinx/lfun/TestLimitViolation.rst
new file mode 100644
index 0000000..874dd83
--- /dev/null
+++ b/doc/sphinx/lfun/TestLimitViolation.rst
@@ -0,0 +1,41 @@
+TestLimitViolation()
+====================
+
+FUNKTION
+--------
+::
+
+ status TestLimitViolation(mapping check)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/attributes.c
+
+PARAMETER
+---------
+::
+
+ check - Mapping mit Attributen: ([<attr>:<wert>])
+
+BESCHREIBUNG
+------------
+::
+
+ Prueft, ob die Summe der in check enthaltenen Modifikatoren die Summe
+ aller Modifikatoren im Spieler ueber den zugelassenen Grenzwert hebt.
+
+
+
+SIEHE AUCH
+----------
+::
+
+ QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+ SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+ P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
+ P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+13.Jun.2004, Muadib
+
diff --git a/doc/sphinx/lfun/TriggerEvent.rst b/doc/sphinx/lfun/TriggerEvent.rst
new file mode 100644
index 0000000..2e8e09e
--- /dev/null
+++ b/doc/sphinx/lfun/TriggerEvent.rst
@@ -0,0 +1,88 @@
+TriggerEvent()
+==============
+
+FUNKTION
+--------
+::
+
+ varargs int TriggerEvent(string eid, mixed data);
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/eventd.c
+
+DEKLARIERT IN
+-------------
+::
+
+ /sys/events.h
+
+ARGUMENTE
+---------
+::
+
+ string eid,
+ Die ID des Events, der ausgeloest werden soll.
+ Da dieser String fuer alle Events jeweils eindeutig sein muss,
+ empfiehlt es sich, fuer eigene Events z.B. als Praefix den eigenen
+ Magiernamen zu nehmen, z.B. "zesstra_vulkanausbruch".
+ ACHTUNG: IDs, die mit 'evt_lib_' beginnen, sind AUSSCHLIESSLICH der
+ Mudlib vorbehalten!
+
+ mixed data,
+ Daten, die jeder Lauscher uebergeben bekommt. Kann ein beliebiger
+ Datentyp sein. Ggf. ein Mapping oder Array benutzen.
+
+BESCHREIBUNG
+------------
+::
+
+ Der Event mit der ID 'eid' wird ausgeloest. Mit kurzer Verzoegerung
+ (meist 0-2s) werden alle fuer 'eid' registrierten Lauscher durch Aufruf
+ einer Funktion in ihnen informiert:
+ listener->fun(eid, triggerob, data);
+ 'triggerob' ist hierbei das Objekt, welche TriggerEvent() gerufen hat,
+ 'data' das, was das triggernde Objekte als Daten weiterverteilen moechte.
+ Die einzelnen fun() in den lauschenden Objekten muessen wissen, was sie
+ mit 'data' anfangen sollen. ;-)
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 fuer Erfolg, <=0 fuer Misserfolg.
+ 1 - Erfolg, Event 'eid' wurde ausgeloest.
+ -1 - falsche Argumente wurden uebergeben
+ -2 - nicht-oeffentlicher Event und das triggernde Objekt wurde nicht
+ fuer diesen Event freigegeben (momentan gibt es noch keine
+ nicht-oeffentlichen Events)
+ -3 - Event 'eid' existiert nicht, d.h. es gibt keine Lauscher.
+ -4 - Es gibt zuviele nicht verarbeitete Events.
+
+BEMERKUNGEN
+-----------
+::
+
+BEISPIELE
+---------
+::
+
+ 1. Ein Waechter wird angegriffen:
+ EVENTD->TriggerEvent("xand_holzfaellerlager_angriff",
+ (["angreifer": enemy,
+ "ort": environment(this_object()) ]) );
+ Alle anderen angemeldeten Waechter der Lagers werden nun informiert
+ und koennen ihrerseits reagieren (dem ersten Waechter zuhilfe kommen
+ oder auch die Lagertore schliessen).
+
+SIEHE AUCH
+----------
+::
+
+ events, eventd, UnregisterEvent(), RegisterEvent()
+
+
+Last modified: 15.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/UnregisterEvent.rst b/doc/sphinx/lfun/UnregisterEvent.rst
new file mode 100644
index 0000000..d694d9d
--- /dev/null
+++ b/doc/sphinx/lfun/UnregisterEvent.rst
@@ -0,0 +1,82 @@
+UnregisterEvent()
+=================
+
+FUNKTION
+--------
+::
+
+ int UnregisterEvent(string eid, object listener);
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/eventd.c
+
+DEKLARIERT IN
+-------------
+::
+
+ /sys/events.h
+
+ARGUMENTE
+---------
+::
+
+ string eid,
+ Die ID des Events, vom dem man sich abmelden will.
+ object listener,
+ Das Objekt, das als Lauscher ausgetragen werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Das Objekt 'listener' wird als Lauscher dieses Events ausgetragen. Ab
+ diesem Moment wird es bei Events vom Typ 'eid' nicht mehr informiert.
+
+ Hat der Event 'eid' im Anschluss keine Lauscher mehr, wird er implizit
+ geloescht.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1 fuer Erfolg, <=0 fuer Misserfolg.
+ 1 - Erfolg, 'listener' wurde eingetragen.
+ -1 - falsche Argumente uebergeben
+ -2 - 'listener' ist nicht fuer 'eid' registriert.
+
+
+
+BEMERKUNGEN
+-----------
+::
+
+ Wenn sich ein Objekt vor Zerstoerung nicht abmeldet, wird es ggf. beim
+ naechsten Auftreten von 'eid' automatisch ausgetragen.
+ Falls Blueprints nach Neuladen nicht automatisch angemeldet sein sollen,
+ sollten sie sich im remove() explizit abmelden.
+
+BEISPIELE
+---------
+::
+
+ 1. Ein Objekt moechte nicht mehr ueber Spielertode informiert werden:
+ EVENTD->UnregisterEvent(EVT_LIB_PLAYER_DEATH, this_object());
+
+ 2. Ein Objekt moechte sich bei Zerstoerung abmelden:
+ varargs int remove(int silent) {
+ ...
+ EVENTD->UnregisterEvent("zesstra_vulkanausbruch",this_object());
+ }
+
+SIEHE AUCH
+----------
+::
+
+ events, eventd, UnregisterEvent(), RegisterEvent()
+
+
+Last modified: 15.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/UnregisterHelperNPC.rst b/doc/sphinx/lfun/UnregisterHelperNPC.rst
new file mode 100644
index 0000000..08ec955
--- /dev/null
+++ b/doc/sphinx/lfun/UnregisterHelperNPC.rst
@@ -0,0 +1,72 @@
+UnregisterHelperNPC()
+=====================
+
+FUNKTION
+--------
+::
+
+ public int UnregisterHelperNPC(object npc);
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/combat.c
+
+ARGUMENTE
+---------
+::
+
+ object npc
+ Objekt des helfenden NPC, der abgemeldet werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion wird ein einem Spieler helfender NPC im Spieler
+ wieder abgemeldet, wenn dieser dem Spieler ab jetzt nicht mehr hilft.
+
+ Wenn ein Helfer-NPC zerstoert wird, ist der Aufruf nicht noetig.
+ Bleibt das Objekt des NPC aber existent, bitte auf jeden Fall wieder
+ ordentlich abmelden, da ansonsten ggf. der Spieler unnoetig blockiert
+ wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn die Abmeldung erfolgreich war.
+ 0 sonst, z.B. wenn der NPC gar nicht als Helfer registriert war.
+
+BEMERKUNGEN
+-----------
+::
+
+ Diese Funktion setzt bei der Erfolg die Property P_HELPER_NPC in <npc>
+ auf 0.
+
+BEISPIELE
+---------
+::
+
+ 1. Ein NPC, der dem Spieler nicht mehr helfen will und normalerweisen im
+ Raum verbleiben soll:
+ tell_object(spieler, "Ich mag Dich nicht mehr, Du bist doof!\n");
+ if (spieler->UnregisterHelperNPC(this_object()) != 1) {
+ // das ist ja bloed...
+ remove(0);
+ }
+ else {
+ tell_room(environment(),
+ Name()+" dreht " +spieler->Name(WEM) + " schmollend den Ruecken "
+ "zu.\n");
+ }
+
+SIEHE AUCH
+----------
+::
+
+ UnregisterHelperNPC()
+ P_HELPER_NPC
+
diff --git a/doc/sphinx/lfun/UnregisterHelperObject.rst b/doc/sphinx/lfun/UnregisterHelperObject.rst
new file mode 100644
index 0000000..62ff671
--- /dev/null
+++ b/doc/sphinx/lfun/UnregisterHelperObject.rst
@@ -0,0 +1,71 @@
+UnregisterHelperObject()
+========================
+
+FUNKTION
+--------
+::
+
+ int UnregisterHelperObject(object helper, int type);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/helpers.c
+
+ARGUMENTE
+---------
+::
+
+ object helper
+ Das Objekt, das als Hilfsobjekt deregistriert werden soll.
+ int type
+ Helfertyp, einer der in /sys/living/helpers.h definierten Typen:
+ - HELPER_TYPE_AERIAL fuer die Flug-/Segelunterstuetzung
+ - HELPER_TYPE_AQUATIC fuer Tauchunterstuetzung
+
+BESCHREIBUNG
+------------
+::
+
+ Das als Hilfsobjekt fuer bestimmte Aktivitaeten wie zum Beispiel Tauchen
+ oder Fliegen bei einem Lebewesen registrierte Objekt "helper" meldet
+ sich bei diesem ab.
+ Hinweis: fuer eine temporaer gueltige "Nicht-Zustaendigkeit" kaeme auch
+ in Frage, in dieser Zeit einfach "0" zurueckzugeben, statt sich
+ komplett abzumelden.
+
+RUECKGABEWERTE
+--------------
+::
+
+ 1 Objekt wurde erfolgreich ausgetragen (HELPER_SUCCESS)
+ -1 angegebenes Hilfsobjekt existiert nicht (HELPER_NO_CALLBACK_OBJECT)
+ -3 angegebenes Hilfsobjekt war gar nicht angemeldet
+ (HELPER_NOTHING_TO_UNREGISTER)
+
+BEISPIEL
+--------
+::
+
+ Eine luftgefuellte Blase hatte sich als Tauch-Helfer am Spieler
+ angemeldet, ist jetzt aber verbraucht und meldet sich daher ab:
+
+ // Austragen im Spielerobjekt
+ void BlaseAustragen() {
+ [...]
+ if ( TP->UnregisterHelperObject(ME, HELPER_TYPE_AQUATIC)
+ == HELPER_SUCCESS )
+ remove();
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Funktionen: RegisterHelperObject()
+ Properties: P_HELPER_OBJECTS, P_AERIAL_HELPERS, P_AQUATIC_HELPERS
+ Sonstiges: /sys/living/helpers.h
+
+19.02.2013 Arathorn
+
diff --git a/doc/sphinx/lfun/Unwear.rst b/doc/sphinx/lfun/Unwear.rst
new file mode 100644
index 0000000..f8e7f38
--- /dev/null
+++ b/doc/sphinx/lfun/Unwear.rst
@@ -0,0 +1,65 @@
+Unwear()
+========
+
+FUNKTION
+--------
+::
+
+ public int Unwear(object ob)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+ object ob
+ Die Ruestung oder Kleidung, die ausgezogen wird.
+
+BESCHREIBUNG
+------------
+::
+
+ Das Lebewesen, in dem diese Funktion gerufen wird, zieht die Ruestung
+ oder das Kleidungsstueck <ob> aus.
+ ABER: 'Ausziehen' bedeutet in diesem Kontext lediglich, dass die
+ Ruestung/Kleidung aus P_ARMOURS bzw. P_CLOTHING ausgetragen wird. Es
+ finden zur Zeit keine Pruefungen statt, ob das Lebewesen den Gegenstand
+ ueberhaupt ausziehen kann. Genausowenig werden Funktionen wie
+ InformUnwear()/RemoveFunc() gerufen oder etwaige Stat-Boni deaktiviert.
+
+ Die Funktion ist nur dazu gedacht, im Zuge des Ausziehens eines Objekts
+ von diesem im Lebewesen gerufen zu werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn das Ausziehen erfolgreich war.
+ 0 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+ Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
+ besten auch dann nicht.
+
+SIEHE AUCH
+----------
+::
+
+ Wear(), WearArmour(), WearClothing(), UnwearArmour(), UnwearClothing()
+ P_CLOTHING, P_ARMOURS
+ FilterClothing(), FilterArmours()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/UnwearArmour.rst b/doc/sphinx/lfun/UnwearArmour.rst
new file mode 100644
index 0000000..7344469
--- /dev/null
+++ b/doc/sphinx/lfun/UnwearArmour.rst
@@ -0,0 +1,65 @@
+UnwearArmour()
+==============
+
+FUNKTION
+--------
+::
+
+ public int UnwearArmour(object ob)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+ object ob
+ Die Ruestung, die ausgezogen wird.
+
+BESCHREIBUNG
+------------
+::
+
+ Das Lebewesen, in dem diese Funktion gerufen wird, zieht die Ruestung
+ <ob> aus.
+ ABER: 'Ausziehen' bedeutet in diesem Kontext lediglich, dass die
+ Ruestung/Kleidung aus P_ARMOURS ausgetragen wird. Es finden zur Zeit
+ keine Pruefungen statt, ob das Lebewesen den Gegenstand ueberhaupt
+ ausziehen kann. Genausowenig werden Funktionen wie
+ InformUnwear()/RemoveFunc() gerufen oder etwaige Stat-Boni deaktiviert.
+
+ Die Funktion ist nur dazu gedacht, im Zuge des Ausziehens eines Objekts
+ von diesem im Lebewesen gerufen zu werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn das Ausziehen erfolgreich war.
+ 0 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+ Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
+ besten auch dann nicht.
+
+SIEHE AUCH
+----------
+::
+
+ Wear(), WearArmour(), WearClothing(), Unwear(), UnwearClothing()
+ P_CLOTHING, P_ARMOURS
+ FilterClothing(), FilterArmours()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/UnwearClothing.rst b/doc/sphinx/lfun/UnwearClothing.rst
new file mode 100644
index 0000000..4f73636
--- /dev/null
+++ b/doc/sphinx/lfun/UnwearClothing.rst
@@ -0,0 +1,65 @@
+UnwearClothing()
+================
+
+FUNKTION
+--------
+::
+
+ public int UnwearClothing(object ob)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+ object ob
+ Das Kleidungsstuck, das ausgezogen wird.
+
+BESCHREIBUNG
+------------
+::
+
+ Das Lebewesen, in dem diese Funktion gerufen wird, zieht das
+ Kleidungsstueck <ob> aus.
+ ABER: 'Ausziehen' bedeutet in diesem Kontext lediglich, dass die
+ Ruestung/Kleidung aus P_CLOTHING ausgetragen wird. Es finden zur Zeit
+ keine Pruefungen statt, ob das Lebewesen den Gegenstand ueberhaupt
+ ausziehen kann. Genausowenig werden Funktionen wie
+ InformUnwear()/RemoveFunc() gerufen.
+
+ Die Funktion ist nur dazu gedacht, im Zuge des Ausziehens eines Objekts
+ von diesem im Lebewesen gerufen zu werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn das Ausziehen erfolgreich war.
+ 0 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+ Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
+ besten auch dann nicht.
+
+SIEHE AUCH
+----------
+::
+
+ Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour()
+ P_CLOTHING, P_ARMOURS
+ FilterClothing(), FilterArmours()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/UnwieldFunc.rst b/doc/sphinx/lfun/UnwieldFunc.rst
new file mode 100644
index 0000000..55ed08f
--- /dev/null
+++ b/doc/sphinx/lfun/UnwieldFunc.rst
@@ -0,0 +1,75 @@
+UnwieldFunc()
+=============
+
+FUNKTION
+--------
+::
+
+ int UnwieldFunc(object weapon, int info, object user);
+
+DEFINIERT IN
+------------
+::
+
+ eigenen Objekten, fuer /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+ weapon (object)
+ Die Waffe, die weggesteckt werden soll.
+ info (int)
+ Bei (info&M_SILENT) wird keine Meldung ueber das Wegstecken
+ ausgegeben.
+ Bei (info&M_NOCHECK) wird die Waffe auch weggesteckt, wenn
+ sie verflucht ist. Die tritt insbesondere dann auf, wenn der
+ Spieler, der die Waffe benutzt, stirbt und die Waffe in
+ die Leiche bewegt wird.
+ user (object)
+ Das Lebewesen, welches die Waffe gerade gezueckt hat und sie nun
+ ausziehen will.
+
+BESCHREIBUNG
+------------
+::
+
+ Hier koennen zusaetzliche Abfragen vorgenommen werden, ob sich die
+ Waffe <weapon> wegstecken laesst oder nicht.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn sich die Waffe nicht wegstecken laesst, ansonsten ungleich 0.
+
+BEMERKUNGEN
+-----------
+::
+
+ Verfluchte Waffen, die sich erst nach Entfernung des Fluches wegstecken
+ lassen, sollte man besser mit P_CURSED realisieren.
+ Selbst wenn man einen Wert ungleich Null zurueckgibt, ist das noch
+ keine Garantie, dass sich die Waffe auch wirklich zuecken laesst! Der
+ Spieler koennte zum Beispiel noch eine Waffe gezueckt haben, die sich
+ nicht wegstecken laesst, etc.
+ Wenn ihr sicher sein wollt, dass der Spieler ein Objekt gezueckt hat,
+ benutzt bitte InformWear().
+ Bitte nicht drauf verlassen, dass this_player() das Lebewesen ist,
+ welches die Waffe gezueckt und wegstecken will.
+ Die Reihenfolge der Argumente ist etwas unschoen, aber leider wurde <user>
+ erheblich spaeter hinzugefuegt und es war unmoeglich, einige hundert
+ Objekte zu aendern.
+
+SIEHE AUCH
+----------
+::
+
+ P_WIELD_MSG, P_UNWIELD_MSG, P_WEAR_MSG, P_UNWEAR_MSG
+ DoWield(), DoUnwield(), InformWield(), InformUnwield(),
+ UnwieldFunc, WieldFunc()
+ /std/weapon/combat.c
+
+
+02.02.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/UpdateAttributes.rst b/doc/sphinx/lfun/UpdateAttributes.rst
new file mode 100644
index 0000000..51bbb60
--- /dev/null
+++ b/doc/sphinx/lfun/UpdateAttributes.rst
@@ -0,0 +1,52 @@
+UpdateAttributes()
+==================
+
+FUNKTION
+--------
+::
+
+ void UpdateAttributes()
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/attributes.c
+
+BESCHREIBUNG
+------------
+::
+
+ Rechnet damit alle Attributmodifier der im Inventory befindlichen
+ (P_X_ATTR_MOD, P_X_HEALTH_MOD) und getragenen/gezueckten
+ (P_M_HEALTH_MOD, P_M_ATTR_MOD) Objekte und aller Attributoffsets
+ zusammen und speichert sie in einer intern fuer Attribute
+ verwendete Variablen.
+ Berechnet darauf basierend HP und SP neu.
+
+
+
+ Die Bedingungen fuer die ueber P_TIMED_ATTR_MOD gesetzten
+ Attributveraenderungen werden im Heartbeat in der Funktion
+ attribute_hb ueberprueft.
+
+BEMERKUNGEN
+-----------
+::
+
+ Sollte nach Einbringen neuer Modifikatorobjekte am Living gerufen
+ werden.
+
+SIEHE AUCH
+----------
+::
+
+ QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+ SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+ SetTimedAttrModifier(), QueryTimedAttrModifier(),
+ DeleteTimedAttrModifier(),
+ P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+ P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+09.05.2007 by Zesstra
+
diff --git a/doc/sphinx/lfun/UpdateResistanceStrengths.rst b/doc/sphinx/lfun/UpdateResistanceStrengths.rst
new file mode 100644
index 0000000..cb43c10
--- /dev/null
+++ b/doc/sphinx/lfun/UpdateResistanceStrengths.rst
@@ -0,0 +1,43 @@
+UpdateResistanceStrengths()
+===========================
+
+FUNKTION
+--------
+::
+
+ public void UpdateResistanceStrengths()
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+BESCHREIBUNG
+------------
+::
+
+ Die Funktion wird intern mehrmals (durch Defend, AddResistanceModifier
+ und RemoveResistanceModifier) aufgerufen. In ihr wird das Resistenz-
+ mapping zusammengerechnet und Eintraege geloescht, deren Eintraege
+ invalid sind oder deren setzende Objekte geloescht wurden.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ Berechnung: CheckResistance(), Defend()
+ Modifikatoren: AddResistanceModifier, RemoveResistanceModifier(),
+ P_RESISTANCE_MODIFIER
+ simple Resistenz: P_RESISTANCE, P_VULNERABILITY
+ Hauptmapping: P_RESISTANCE_STRENGTHS
+ anderes: balance, /std/armour/combat.c, /std/living/combat.c
+
+29.Apr 2002, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/UseHands.rst b/doc/sphinx/lfun/UseHands.rst
new file mode 100644
index 0000000..9485e83
--- /dev/null
+++ b/doc/sphinx/lfun/UseHands.rst
@@ -0,0 +1,61 @@
+UseHands()
+==========
+
+FUNKTION
+--------
+::
+
+ public varargs int UseHands(object ob, int num)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ ob - das Objekt, das die Haende belegen soll
+ num - die Anzahl der zu belegenden Haende
+
+RUECKGABEWERT
+-------------
+::
+
+ 1, fuer Erfolg
+ 0, sonst
+
+BESCHREIBUNG
+------------
+::
+
+ Belegt, wenn moeglich Haende eines Livings durch ein bestimmtes
+ Objekt. Wenn die Anzahl der freien Haende (P_MAX_HANDS-P_USED_HANDS)
+ kleiner ist als "num", dann schlaegt diese Belegung fehl.
+
+BEISPIELE
+---------
+::
+
+ > halte seil fest
+ ...
+ this_player()->UseHands(this_object(),2);
+ ...
+
+ > lasse seil los
+ ...
+ this_player()->FreeHands(this_object());
+ ...
+
+SIEHE AUCH
+----------
+::
+
+ P_HANDS, P_HANDS_USED_BY
+ P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
+ FreeHands
+
+1.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/UseSkill.rst b/doc/sphinx/lfun/UseSkill.rst
new file mode 100644
index 0000000..b994e67
--- /dev/null
+++ b/doc/sphinx/lfun/UseSkill.rst
@@ -0,0 +1,74 @@
+UseSkill()
+==========
+
+FUNKTION
+--------
+::
+
+ public varargs mixed UseSkill(string skill, mapping args)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skills.c
+
+ARGUMENTE
+---------
+::
+
+ string skill Skill-Name
+ mapping args Argumente (veraenderte Skillmapping-Informationen)
+
+BESCHREIBUNG
+------------
+::
+
+ Benutzt einen Skill. Dieser Skill sollte (als grossgeschriebener Skill)
+ im Living vorliegen und das Living darf kein Geist sein.
+
+
+
+ Die Argumente 'args' werden temporaer auf das Skillmapping des Living
+ addiert (also nur fuer diesen Aufruf und SI_INHERIT gueltig).
+
+
+
+ Eine ausfuehrbare Skill-Funktion zum Skill wird in folgender
+ Reihenfolge bestimmt:
+ - eine gesetzte SI_CLOSURE nutzen
+ - ein gesetztes SI_SKILLFUNC in der gesetzten Gilde nutzen
+ - im Living die Funktion "StdSkill_"+skill (zB Waffenskills) nutzen
+ - QuerySkillAbility() nutzen
+ Die so bestimmte Skill-Funktion wird dann als SI_CLOSURE im Spieler
+ gesetzt und ist bis zur Zerstoerung der entsprechenden Objekte gueltig.
+ Die Methode wird dann gerufen (der Skill also angewandt).
+
+
+
+ Standardmaessig gibt ein UseSkill() also einfach den SI_SKILLABILITY-Wert
+ eines Skills zurueck, es sei denn, eine Funktion wurde fuer den Skill
+ an einer der oben genannten Stellen implementiert.
+
+
+
+ Ein eventuell uebergeordneter Skill (SI_INHERIT) wird mit dem durch den
+ Aufruf der Skill-Funktion veraenderten Mapping mit UseSkill(skill, args)
+ ebenfalls noch ausgefuehrt, bevor das Resultat zurueckgegeben wird.
+
+SIEHE AUCH
+----------
+::
+
+ Skills Lernen: LearnSkill, ModifySkill, LimitAbility
+ * Nutzung: UseSpell
+ * Abfragen: QuerySkill, QuerySkillAbility
+ * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+ QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+ * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+ * sonstig: spruchermuedung, skill_info_liste
+ * Properties: P_NEWSKILLS
+ Spellbook: Learn, SpellSuccess, Erfolg, Misserfolg
+
+4. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/UseSpell.rst b/doc/sphinx/lfun/UseSpell.rst
new file mode 100644
index 0000000..e9a3e9a
--- /dev/null
+++ b/doc/sphinx/lfun/UseSpell.rst
@@ -0,0 +1,105 @@
+UseSpell()
+==========
+
+FUNKTION
+--------
+::
+
+ public varargs int UseSpell(string str, string spell)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skills.c
+
+ARGUMENTE
+---------
+::
+
+ string str Spell-Optionen
+ string spell optionaler Spellname
+
+BESCHREIBUNG
+------------
+::
+
+ Benutzt einen Spell, dessen Spellname 'spell' ggf ueber query_verb()
+ ermittelt wird. Dieser Spell sollte (als kleingeschriebener
+ Skill/Spell) im Living vorliegen.
+
+
+
+ Die Argumente 'str' werden als SI_SKILLARG temporaer in das
+ Skillmapping eingetragen (also nur fuer diesen Aufruf gueltig).
+
+
+
+ Eine ausfuehrbare Spell-Funktion zum Spell wird in folgender
+ Reihenfolge bestimmt:
+ - eine gesetzte SI_CLOSURE nutzen
+ - "UseSpell" an einem gesetzten SI_SPELLBOOK nutzen
+ - "UseSpell" an der gesetzten P_GUILD nutzen
+ - [UseSpell der Gilde sucht iA ebenfalls nur den Spell am Spellbook]
+ - eine Closure mit Rueckgabewert 0 erstellen
+ Die so bestimmte Spell-Funktion wird dann als SI_CLOSURE im Spieler
+ gesetzt und ist bis zur Zerstoerung der entsprechenden Objekte gueltig.
+ Die Methode wird dann gerufen (der Spell also angewandt).
+
+ Standardmaessig gibt ein UseSpell() also 0 zurueck, es sei denn, eine
+ Funktion wurde fuer den Spell an einer der oben genannten Stellen
+ implementiert.
+
+ SI_INHERIT ist fuer Spells beim Aufruf wirkungslos (gilt aber bei
+ LearnSkill normal).
+
+ Ein Durchlauf von UseSpell durch den Spieler sieht in etwa so aus:
+ 1) Die Methode wird als Empfaenger fuer Kommandos bekannt gemacht.
+ Das passiert mit der Anweisung
+ 'add_action("UseSpell", "", 1);' in den Dateien player/base.c und
+ in living/npc.c.
+
+ 2) /std/living/skills::UseSpell wird durch Kommando oder Heartbeat
+ gerufen.
+
+
+
+ 3) UseSpell() ermittelt eine SI_CLOSURE oder delegiert diesen Aufruf
+ an die gueltige Gilde/das Spellbook weiter.
+
+
+
+ 4) Eine gueltige Closure wird ausgefuehrt. UseSpell() uebergibt dabei
+ die Spell/Skill-Informationen und SI_SKILLARG.
+
+
+
+ 4.1.) Im Normalfall einer Gilde/Spellbook landet der Aufruf ueber
+ /std/gilden_ob::UseSpell() in /std/spellbook::UseSpell() und
+ dieses ruft eine Spellfunktion im Spellbook auf.
+ Die Spellfunktion arbeitet mit den Spell-Informationen und
+ gibt ein ERFOLG, MISSERFOLG oder 0 dafuer zurueck, ob das
+ Spellbook Lernen/Fehlermeldung oder nichts machen soll.
+ Dementsprechend werden P_SP, P_ATTACK_BUSY und
+ P_NEXT_SPELL_TIME im Spellbook geaendert.
+
+ 5.) Der Aufruf der Closure kehrt zurueck und wird zurueckgegeben.
+ Damit ist der 0-Rueckgabewert der Spellfunktion im Spellbook
+ aequivalent einem nicht ausgefuehrten Kommando.
+
+SIEHE AUCH
+----------
+::
+
+ Skills Lernen: LearnSkill, ModifySkill, LimitAbility
+ * Nutzung: UseSkill
+ * Abfragen: QuerySkill, QuerySkillAbility
+ * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+ QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+ * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+ * sonstig: spruchermuedung, skill_info_liste
+ * Properties: P_NEWSKILLS
+ Spellbook: UseSpell (spellbook), Learn, SpellSuccess
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/Validate.rst b/doc/sphinx/lfun/Validate.rst
new file mode 100644
index 0000000..479d1dc
--- /dev/null
+++ b/doc/sphinx/lfun/Validate.rst
@@ -0,0 +1,76 @@
+Validate()
+==========
+
+FUNKTION
+--------
+::
+
+ string Validate(string oname);
+
+DEFINIERT IN
+------------
+::
+
+ /std/virtual/v_compiler.c
+
+ARGUMENTE
+---------
+::
+
+ oname
+ Objektname, der geprueft werden soll
+
+RUeCKGABEWERT
+-------------
+::
+
+
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion hat die Aufgabe zu ueberpruefen ob ein Objekt welches
+ geladen werden soll, in dem VC ueberhaupt erlaubt ist. Dieser
+ Funktion wird nur der reine Filename uebergeben, ohne Pfad!
+ Diese Funktion macht im Standard-VC in /std/ nichts weiter, als
+ das '.c' am File Namen abzuschneiden.
+ Sollte der Dateiname gueltig sein liefert die Funktion als Rueckgabewert
+ den Filenamen ohne .c und sonst 0.
+
+BEMERKUNGEN
+-----------
+::
+
+ Am besten ruft man in seinem Validate() das ::Validate(), was einem die
+ Arbeit abnimmt, ein .c am Ende zu entfernen.
+
+BEISPIEL
+--------
+::
+
+ string Validate(string oname) {
+ string raum, spieler;
+ //.c abschneiden
+ oname=::Validate(oname);
+
+
+
+ // folgt der Raum dem Muster "arena|name"? Wenn nein -> ungueltig,
+ // 0 zureckgeben, sonst den Filenamen.
+ if(sscanf(oname,"%s|%s",raum,spieler)<2 || raum!="arena")
+ return 0;
+ return oname;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ virtual_compiler
+ CustomizeObject(), Validate(), NoParaObjects(),
+ P_COMPILER_PATH, P_PARA
+ /std/virtual/v_compiler.c
+
+27.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/Wear.rst b/doc/sphinx/lfun/Wear.rst
new file mode 100644
index 0000000..2638548
--- /dev/null
+++ b/doc/sphinx/lfun/Wear.rst
@@ -0,0 +1,64 @@
+Wear()
+======
+
+FUNKTION
+--------
+::
+
+ public int Wear(object ob)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+ object ob
+ Die Ruestung oder Kleidung, die angezogen wird.
+
+BESCHREIBUNG
+------------
+::
+
+ Das Lebewesen, in dem diese Funktion gerufen wird, zieht die Ruestung
+ oder das Kleidungsstueck <ob> an.
+ ABER: 'Anziehen' bedeutet in diesem Kontext lediglich, dass die
+ Ruestung/Kleidung in P_ARMOURS bzw. P_CLOTHING eingetragen wird. Es
+ finden zur Zeit keine Pruefungen statt, ob das Lebewesen den Gegenstand
+ ueberhaupt anziehen kann. Genausowenig werden Funktionen wie InformWear()
+ gerufen oder etwaige Stat-Boni aktiviert.
+ Die Funktion ist nur dazu gedacht, im Zuge des Anziehens eines Objekts
+ von diesem im Lebewesen gerufen zu werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn das Anziehen erfolgreich war.
+ 0 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+ Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
+ besten auch dann nicht.
+
+SIEHE AUCH
+----------
+::
+
+ WearArmour(), WearClothing(), Unwear(), UnwearArmour(), UnwearClothing()
+ P_CLOTHING, P_ARMOURS
+ FilterClothing(), FilterArmours()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/WearArmour.rst b/doc/sphinx/lfun/WearArmour.rst
new file mode 100644
index 0000000..0762aea
--- /dev/null
+++ b/doc/sphinx/lfun/WearArmour.rst
@@ -0,0 +1,64 @@
+WearArmour()
+============
+
+FUNKTION
+--------
+::
+
+ public int WearArmour(object ob)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+ object ob
+ Die Ruestung, die angezogen wird.
+
+BESCHREIBUNG
+------------
+::
+
+ Das Lebewesen, in dem diese Funktion gerufen wird, zieht die Ruestung
+ <ob> an.
+ ABER: 'Anziehen' bedeutet in diesem Kontext lediglich, dass die
+ Ruestung/Kleidung in P_ARMOURS eingetragen wird. Es finden zur Zeit keine
+ Pruefungen statt, ob das Lebewesen den Gegenstand ueberhaupt anziehen
+ kann. Genausowenig werden Funktionen wie InformWear() gerufen oder
+ etwaige Stat-Boni aktiviert.
+ Die Funktion ist nur dazu gedacht, im Zuge des Anziehens eines Objekts
+ von diesem im Lebewesen gerufen zu werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn das Anziehen erfolgreich war.
+ 0 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+ Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
+ besten auch dann nicht.
+
+SIEHE AUCH
+----------
+::
+
+ Wear(), WearClothing(), Unwear(), UnwearArmour(), UnwearClothing()
+ P_CLOTHING, P_ARMOURS
+ FilterClothing(), FilterArmours()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/WearClothing.rst b/doc/sphinx/lfun/WearClothing.rst
new file mode 100644
index 0000000..7dc1b2b
--- /dev/null
+++ b/doc/sphinx/lfun/WearClothing.rst
@@ -0,0 +1,64 @@
+WearClothing()
+==============
+
+FUNKTION
+--------
+::
+
+ public int WearClothing(object ob)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/clothing.c
+
+ARGUMENTE
+---------
+::
+
+ object ob
+ Das Kleidungsstuck, das angezogen wird.
+
+BESCHREIBUNG
+------------
+::
+
+ Das Lebewesen, in dem diese Funktion gerufen wird, zieht das
+ Kleidungsstueck <ob> an.
+ ABER: 'Anziehen' bedeutet in diesem Kontext lediglich, dass die
+ Ruestung/Kleidung in P_CLOTHING eingetragen wird. Es finden zur Zeit
+ keine Pruefungen statt, ob das Lebewesen den Gegenstand ueberhaupt
+ anziehen kann. Genausowenig werden Funktionen wie InformWear() gerufen.
+
+ Die Funktion ist nur dazu gedacht, im Zuge des Anziehens eines Objekts
+ von diesem im Lebewesen gerufen zu werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn das Anziehen erfolgreich war.
+ 0 sonst.
+
+BEMERKUNGEN
+-----------
+::
+
+ Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
+ besten auch dann nicht.
+
+SIEHE AUCH
+----------
+::
+
+ Wear(), WearArmour(), Unwear(), UnwearArmour(), UnwearClothing()
+ P_CLOTHING, P_ARMOURS
+ FilterClothing(), FilterArmours()
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/WearFunc.rst b/doc/sphinx/lfun/WearFunc.rst
new file mode 100644
index 0000000..573fee6
--- /dev/null
+++ b/doc/sphinx/lfun/WearFunc.rst
@@ -0,0 +1,106 @@
+WearFunc()
+==========
+
+FUNKTION
+--------
+::
+
+ int WearFunc(object ruest, int silent, object user);
+
+DEFINIERT IN
+------------
+::
+
+ eigenen Objekten (fuer /std/clothing/wear)
+
+ARGUMENTE
+---------
+::
+
+ ruest (object)
+ Die Ruestung/Kleidung, die angezogen werden soll.
+ silent (int)
+ Ob dabei eine Meldung ausgegeben wird.
+ user (object)
+ Das Lebewesen, welches die Ruestung/Kleidung anziehen will.
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion kann man pruefen, ob sich das Kleidungsstueck bzw.
+ Ruestung <ruest> von this_player() anziehen laesst oder nicht.
+ Kann die Ruestung angezogen werden, so muss ein Wert ungleich 0
+ zurueckgegeben werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn sich die Ruestung nicht anziehen laesst, ansonsten ungleich 0.
+
+BEMERKUNGEN
+-----------
+::
+
+ Bitte nicht darauf verlassen, dass der Spieler das Objekt auch wirklich
+ anzieht, wenn man hier 1 zurueckgibt.
+ Speziell bei Schilden kann das Anziehen trotz eines Rueckgabewertes
+ != 0 immer noch schief gehen, wenn der Spieler keine Hand mehr frei hat.
+ Wenn ihr sicher sein wollt, dass der Spieler ein Objekt angezogen hat,
+ benutzt bitte InformWear().
+ Bitte nicht drauf verlassen, dass this_player() das ausziehende Lebewesen
+ ist.
+ Die Reihenfolge der Argumente ist etwas unschoen, aber leider wurde <user>
+ erheblich spaeter hinzugefuegt und es war unmoeglich, einige hundert
+ Objekte zu aendern.
+
+BEISPIELE
+---------
+::
+
+ Ein Helm, der nur von Elfen getragen werden kann:
+
+ inherit "std/armour.c";
+
+ #include <properties.h>
+
+ create()
+ {
+ ::create();
+
+ SetProp(P_ARMOUR_TYPE, AT_HELMET);
+ /* zig weitere SetProp's, um den Helm zu konfigurieren */
+
+ /* WearFunc() ist im Helm selbst zu finden */
+ SetProp(P_WEAR_FUNC, this_object());
+ }
+
+ int WearFunc(object me, int silent, object user)
+ {
+ if (user->QueryProp(P_RACE) == "Elf")
+ return 1; /* Elfen duerfen den Helm tragen */
+
+ /* Die anderen Rassen sollten zumindest erfahren koennen, wieso
+ sie den Helm nicht tragen koennen... */
+ if (!silent)
+ write( "Der Helm rutscht Dir immer ueber Deine runden "
+ +"Ohren.\n" );
+ return 0;
+ }
+
+ Gibt jetzt ein Nicht-Elf "trage helm" ein, so bekommt er die Meldung
+ "Der Helm rutscht Dir immer ueber Deine runden Ohren.", Elfen dagegen
+ passt das Teil wie angegossen.
+
+SIEHE AUCH
+----------
+::
+
+ P_WEAR_MSG, P_UNWEAR_MSG, P_WIELD_MSG, P_UNWIELD_MSG
+ DoWear(), DoUnwear(), InformUnwear(), InformWear()
+ /std/clothing/wear.c
+
+
+02.02.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/WieldFunc.rst b/doc/sphinx/lfun/WieldFunc.rst
new file mode 100644
index 0000000..f6e2a37
--- /dev/null
+++ b/doc/sphinx/lfun/WieldFunc.rst
@@ -0,0 +1,103 @@
+WieldFunc()
+===========
+
+FUNKTION
+--------
+::
+
+ int WieldFunc(object weapon, int silent, object user);
+
+DEFINIERT IN
+------------
+::
+
+ eigenen Objekten (fuer /std/weapon/combat)
+
+ARGUMENTE
+---------
+::
+
+ weapon (object)
+ Die Waffe, die gezueckt werden soll.
+ silent (int)
+ Ob dabei eine Meldung ausgegeben werden soll.
+ user (object)
+ Das Lebewesen, welches die Waffe zuecken will.
+
+BESCHREIBUNG
+------------
+::
+
+ In dieser Funktion kann man zusaetzliche Abfragen vornehmen, ob sich
+ die Waffe <weapon> von <user> zuecken laesst oder nicht.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0, wenn die Waffe nicht gezueckt werden kann, sonst ungleich 0.
+
+BEMERKUNGEN
+-----------
+::
+
+ Selbst wenn man einen Wert ungleich Null zurueckgibt, ist das noch
+ keine Garantie, dass sich die Waffe auch wirklich zuecken laesst! Der
+ Spieler koennte zum Beispiel noch eine Waffe gezueckt haben, die sich
+ nicht wegstecken laesst, etc.
+ Wenn ihr sicher sein wollt, dass der Spieler ein Objekt gezueckt hat,
+ benutzt bitte InformWield().
+ Bitte nicht drauf verlassen, dass this_player() das Lebewesen ist,
+ welches die Waffe zuecke will.
+ Die Reihenfolge der Argumente ist etwas unschoen, aber leider wurde <user>
+ erheblich spaeter hinzugefuegt und es war unmoeglich, einige hundert
+ Objekte zu aendern.
+
+BEISPIELE
+---------
+::
+
+ Eine Waffe, die sich nicht von Zwergen zuecken laesst:
+
+ inherit "std/weapon";
+
+ #include <properties.h>
+ #include <combat.h>
+
+ create()
+ {
+ ::create();
+
+ ... /* zig SetProp's, um die Waffe zu konfigurieren */
+
+ /* WieldFunc() ist in der Waffe selbst zu finden */
+ SetProp(P_WIELD_FUNC, this_object());
+ }
+
+ int WieldFunc(object weapon, int silent, object user)
+ {
+ /* Nicht-Zwerge duerfen die Waffe zuecken */
+ if (user->QueryProp(P_RACE) != "Zwerg")
+ return 1;
+
+ /* Ansonsten sagen wir evtl., warum das Zuecken nicht klappt... */
+ if (!silent)
+ write( "Deine kleinen Haendchen koennen den Griff nicht "+
+ "umklammern.\n");
+
+ /* ...und brechen das Zuecken ab. */
+ return 0;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ P_WIELD_MSG, P_UNWIELD_MSG, P_WEAR_MSG, P_UNWEAR_MSG
+ DoWield(), DoUnwield(), InformUnwield(), InformWield()
+ UnwieldFunc, WieldFunc
+ /std/weapon/combat.c
+
+
+02.02.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/WithDraw.rst b/doc/sphinx/lfun/WithDraw.rst
new file mode 100644
index 0000000..c7aff00
--- /dev/null
+++ b/doc/sphinx/lfun/WithDraw.rst
@@ -0,0 +1,69 @@
+WithDraw()
+==========
+
+FUNKTION
+--------
+::
+
+ int WithDraw(int amount);
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/zentralbank.c
+
+ARGUMENTE
+---------
+::
+
+ int amount - angeforderte Geldmenge
+
+BESCHREIBUNG
+------------
+::
+
+ Damit wird bei der Zentralbank eine bestimmte Menge Geld angefordert.
+ Der Rueckgabewert haengt vom Kassenstand der Zentralbank ab und ist
+ entweder amount oder amount/3.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Menge des bei der Zentralbank "abgehobenen" Geldes.
+
+BEISPIELE
+---------
+::
+
+ #include <bank.h>
+ ...
+ if(ZENTRALBANK->WithDraw(50000)<50000)
+ write(break_string(
+ "Leider koennen wir ihnen keinen vollen Zuschuss zu ihrem Hotelbau "
+ "geben!",
+ "Der Beamte sagt: ",78));
+ say(break_string(
+ "Leider koennen wir ihnen keinen vollen Zuschuss zu ihrem Hotelbau "
+ "geben!",
+ "Der Beamte sagt zu "+this_player()->name(WEM)+": ",78));
+ ...
+
+BEMERKUNGEN
+-----------
+::
+
+ Unsere Zentralbank ist korrupt, vor allem dadurch, dass in Laeden und
+ an anderen Stellen Geld erzeugt wird.
+
+SIEHE AUCH
+----------
+::
+
+ Geldhandling: AddMoney(L), QueryMoney(L)
+ Zentralbank: PayIn(L), _query_current_money(L)
+ Sonstiges: /items/money.c, /sys/bank.h
+
+27. Apr 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/__INIT.rst b/doc/sphinx/lfun/__INIT.rst
new file mode 100644
index 0000000..5af9cd0
--- /dev/null
+++ b/doc/sphinx/lfun/__INIT.rst
@@ -0,0 +1,25 @@
+__INIT()
+========
+
+SYNOPSIS
+--------
+::
+
+ __INIT
+
+DESCRIPTION
+-----------
+::
+
+ This function is constructed automagically by the parser at
+ compiler, if the parser was compiled with #define
+ INITIALISATION__INIT. This function is not intended to be
+ defined by the lpc objects, and never to be called from lpc
+ objects. This man page is here just for completeness.
+
+SEE ALSO
+--------
+::
+
+ initialisation(LPC)
+
diff --git a/doc/sphinx/lfun/_query_current_money.rst b/doc/sphinx/lfun/_query_current_money.rst
new file mode 100644
index 0000000..bbdaebc
--- /dev/null
+++ b/doc/sphinx/lfun/_query_current_money.rst
@@ -0,0 +1,53 @@
+_query_current_money()
+======================
+
+FUNKTION
+--------
+::
+
+ int _query_current_money()
+
+DEFINIERT IN
+------------
+::
+
+ /p/daemon/zentralbank.c
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird zurueckgegeben, wieviel Geld die Zentralbank besitzt.
+
+BEISPIELE
+---------
+::
+
+ #include <bank.h>
+ ...
+ if(ZENTRALBANK->_query_current_money()<30000) {
+ write(break_string(
+ "Leider koennen wir ihren Bausparvertrag derzeit nicht einloesen.",
+ "Der Beamte sagt: ",78));
+ say(break_string(
+ "Leider koennen wir ihren Bausparvertrag derzeit nicht einloesen.",
+ "Der Beamte sagt zu "+this_player()->name(WEM)+": ",78));
+ }
+
+BEMERKUNGEN
+-----------
+::
+
+ Unsere Zentralbank ist korrupt, vor allem dadurch, dass in Laeden und
+ an anderen Stellen Geld erzeugt wird.
+
+SIEHE AUCH
+----------
+::
+
+ Geldhandling: AddMoney(L), QueryMoney(L)
+ Zentralbank: WithDraw(L), PayIn(L)
+ Sonstiges: /items/money.c, /sys/bank.h
+
+27. Apr 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/_unparsed_args.rst b/doc/sphinx/lfun/_unparsed_args.rst
new file mode 100644
index 0000000..25f8d8b
--- /dev/null
+++ b/doc/sphinx/lfun/_unparsed_args.rst
@@ -0,0 +1,49 @@
+_unparsed_args()
+================
+
+FUNKTION
+--------
+::
+
+ varargs string _unparsed_args(int level)
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/command.c:
+
+ARGUMENTE
+---------
+::
+
+ level
+ Gibt an, wieviel des Textes "weggeparsed" werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt den Text des letzten Befehls des Spielers (ohne das Befehlswort
+ selbst) zurueck. "level" gibt dabei an, wieviel geparsed wird:
+ level = 0 : Gar kein Parsing.
+ level = 1 : Der Text wird in Kleinbuchstaben umgewandelt, doppelte
+ Leerzeichen werden entfernt.
+ level = 2 : Semikoli, Kommata und Doppelpunkte werden in Leerzeichen
+ umgewandelt, doppelte Leerzeichen und Artikel (der, die,
+ das, ein,...) werden entfernt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der geparste Text.
+
+SIEHE AUCH
+----------
+::
+
+ query_command(), query_verb(), modify_command()
+
+25.08.2016, Arathorn
+
diff --git a/doc/sphinx/lfun/access_rights.rst b/doc/sphinx/lfun/access_rights.rst
new file mode 100644
index 0000000..e1ccc42
--- /dev/null
+++ b/doc/sphinx/lfun/access_rights.rst
@@ -0,0 +1,98 @@
+access_rights()
+===============
+
+FUNKTION
+--------
+::
+
+ int access_rights(string euid, string file);
+
+DEFINIERT IN
+------------
+::
+
+ access_rights.c (muss man selber schreiben)
+
+PARAMETER
+---------
+::
+
+ euid
+ Die euid desjenigen, der auf das Verzeichnis schreiben will
+ file
+ Name der Datei, auf die zugegriffen werden soll
+
+BESCHREIBUNG
+------------
+::
+
+ access_rights() wird immer dann aufgerufen, wenn jemand, der nicht
+ sowieso schon schreibberechtigt ist, in die Datei/das Verzeichnis file
+ schreiben oder loeschen will.
+
+ Anhand von euid kann man dann entscheiden, ob der Schreibzugriff erlaubt
+ wird oder nicht.
+
+RUECKGABEWERT
+-------------
+::
+
+ 0, wenn der Zugriff verweigert wird,
+ 1, wenn der Zugriff erlaubt wird.
+
+BEISPIELE
+---------
+::
+
+ /* /d/inseln/wargon/access_rights.c */
+
+ int access_rights(string euid, string file)
+ {
+ string dir, rest;
+
+ // Catweazle darf auf alles zugreifen (*argl* ;^)
+ if (euid == "catweazle")
+ return 1;
+
+ // Rechte auf einzelne Verzeichnisse ermitteln:
+ if (sscanf(file, "%s/%s", dir, rest) != 2)
+ rest = file;
+
+ // Jof und Boing duerfen an Tarko Reub rumpfuschen:
+ if (dir == "tarko" && (euid == "jof" || euid == "boing"))
+ return 1;
+
+ // Anthea darf die Karten von Aurora und der Piratenhoehle bearbeiten:
+ if (dir == "MAPS" &&
+ member( ({"Aurora", "Piratenhoehle" }), rest) >= 0 &&
+ euid == "anthea")
+ return 1;
+
+ // alle anderen duerfen nicht!
+ return 0;
+ }
+
+BEMERKUNGEN
+-----------
+::
+
+ file ist immer relativ zu dem Verzeichnis, in dem das access_rights.c
+ liegt! Will also jemand auf /d/inseln/wargon/tarko/macros.h schreiben,
+ wird file "tarko/macros.h" uebergeben.
+
+ In Verzeichnissen von Magiern mit einem Level >= ELDER_LVL wird das
+ access_rights.c NICHT ausgewertet (da damit andere Magier zB. an
+ Erzmagierrechte gelangen koennten).
+
+ Es wird immer nur EIN access_rights.c ausgewertet, naemlich das in der
+ tiefsten Verzeichnisebene.
+
+ Man kann sowohl in seinen Regionsverzeichnissen als auch in seinen
+ Homeverzeichnissen access_rights.c-Dateien anlegen.
+
+ GANZ WICHTIG!!!
+ Fuer die Dateien, die evtl. von anderen angelegt werden, ist man immer
+ noch selbst verantwortlich! Wenn jemand also ein Gebiet bei Dir an-
+ schliesst, muss es erst von den verantwortlichen Regionsmagiern abgesegnet
+ sein!
+
diff --git a/doc/sphinx/lfun/buffer_hp.rst b/doc/sphinx/lfun/buffer_hp.rst
new file mode 100644
index 0000000..db0555c
--- /dev/null
+++ b/doc/sphinx/lfun/buffer_hp.rst
@@ -0,0 +1,106 @@
+buffer_hp()
+===========
+
+FUNKTION
+--------
+::
+
+ int buffer_hp( int val, int rate );
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ val: Gesamte Heilung.
+ rate: LP-Rate.
+
+
+
+BESCHREIBUNG
+------------
+::
+
+ Erhoeht die LP eines Spielers automatisch insgesamt um den Wert "val".
+ Pro heart_beat() wird ihm dabei der Wert "rate" zugefuehrt.
+ Sollen neben P_HP noch weitere Props manipuliert werden - bspw. zur
+ P_FOOD - bietet sich die Funktion consume() an.
+
+RUECKGABEWERTE
+--------------
+::
+
+ Der getankte Wert pro heart_beat().
+
+BEMERKUNG
+---------
+::
+
+ Sollte von jeder tragbaren Heilung genutzt werden, welche den Spieler
+ darauf schliessen lassen kann, auf natuerlichem und nichtmagischem Weg
+ (Essen, Trinken) geheilt worden zu sein.
+
+BEISPIEL
+--------
+::
+
+ #define TP this_player()
+ ...
+
+ int heilung=1;
+ ...
+
+ create()
+ {
+ ::create();
+ SetProp(P_NAME,"Heilpflanze");
+ ...
+
+ AddCmd("iss","eat");
+ }
+
+ int eat(string str)
+ {
+ notify_fail("WAS willst Du essen?\n");
+ if ( !str || !id(str) )
+ return 0;
+ ...
+
+ if ( !TP->eat_food(25) )
+ return 1;
+
+ TP->buffer_hp(20,5);
+ TP->buffer_sp(80,10);
+ heilung--;
+ write(BS("Du fuehlst langsam, wie Deine Kraefte zurueckkehren."));
+
+ return 1;
+ }
+
+ reset()
+ {
+ heilung=1;
+ ::reset();
+ }
+
+ Es wird durch eat_food getestet, ob der Spieler noch genuegend essen kann.
+ Wenn ja, kriegt unser Held die 25 automatisch oben drauf und ausserdem
+ 20 LP in 5-LP-Schritten und 80 KP in 10-LP-Schritten gutgeschrieben.
+
+SIEHE AUCH
+----------
+::
+
+ Aehnlich: heal_self, restore_spell_points, restore_hit_points,
+ buffer_sp
+ Tanken: consume, drink_alcohol, drink_soft, eat_food
+ Props: P_SP, P_HP,
+ Konzepte: heilung
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/buffer_sp.rst b/doc/sphinx/lfun/buffer_sp.rst
new file mode 100644
index 0000000..6eb83ac
--- /dev/null
+++ b/doc/sphinx/lfun/buffer_sp.rst
@@ -0,0 +1,65 @@
+buffer_sp()
+===========
+
+FUNKTION
+--------
+::
+
+ int buffer_sp( int val, int rate );
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ val: Gesamte Heilung.
+ rate: KP-Rate.
+
+
+
+BESCHREIBUNG
+------------
+::
+
+ Erhoeht die KP eines Spielers automatisch insgesamt um den Wert "val".
+ Pro heart_beat() wird ihm dabei der Wert "rate" zugefuehrt.
+ Sollen neben P_SP noch weitere Props manipuliert werden - bspw. zur
+ P_FOOD - bietet sich die Funktion consume() an.
+
+RUECKGABEWERTE
+--------------
+::
+
+ Der getankte Wert pro heart_beat().
+
+BEMERKUNG
+---------
+::
+
+ Sollte von jeder tragbaren Heilung genutzt werden, welche den Spieler
+ darauf schliessen lassen kann, auf natuerlichem und nichtmagischem Weg
+ (Essen, Trinken) geheilt worden zu sein.
+
+BEISPIEL
+--------
+::
+
+ s. Bsp. zu "buffer_hp"
+
+SIEHE AUCH
+----------
+::
+
+ Aehnlich: heal_self, restore_spell_points, restore_hit_points,
+ buffer_hp
+ Tanken: consume, drink_alcohol, drink_soft, eat_food
+ Props: P_SP, P_HP,
+ Konzepte: heilung
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/buy_obj.rst b/doc/sphinx/lfun/buy_obj.rst
new file mode 100644
index 0000000..1aeab6c
--- /dev/null
+++ b/doc/sphinx/lfun/buy_obj.rst
@@ -0,0 +1,66 @@
+buy_obj()
+=========
+
+FUNKTION
+--------
+::
+
+ static string buy_obj(mixed ob, int short);
+
+DEFINIERT IN
+------------
+::
+
+ /std/shop.c
+
+ARGUMENTE
+---------
+::
+
+ ob - der Gegenstand bei dem geprueft werden soll, ob der Laden ihn
+ an this_player() verkauft. Sollte es sich hierbei um ein
+ FixedObject handeln, wird ein String uebergeben, ansonsten ein
+ object.
+ short - Bisher noch nicht in Benutzung. Aber fuer die Zukunft
+ vorgesehn, falls man mehrere Objekte auf einmal kauft.
+ Ein auswerten ist keine Pflicht, waere aber praktisch, damit
+ der Scroll dabei nicht zu gross wird.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ein String was der Haendler sagen soll wieso der Gegenstand nicht
+ verkauft wird. Der String wird dabei wie folgt umgebrochen:
+ break_string(str, 78, Name(WER, 1)+" sagt: ")
+
+BESCHREIBUNG
+------------
+::
+
+ Durch ueberschreiben dieser Funktion ist es moeglich bestimmte
+ Objekte (wie z.b. Questobjekte) nur an ausgewaehlte Spieler zu
+ verkaufen). Aber auch abfragen ob der Laden ueberhaupt mit
+ this_player() handelt, sind moeglich.
+
+BEISPIELE
+---------
+::
+
+ static string buy_obj(mixed ob, int short)
+ {
+ if (PL->QueryProp(P_RACE)=="Zwerg")
+ return "Ich verkaufe nichts an Zwerge!";
+ return ::buy_obj(ob, short);
+ }
+
+SIEHE AUCH
+----------
+::
+
+ sell_obj(), AddFixedObject(), RemoveFixedObject(), SetStorageRoom(),
+ /std/shop.c
+
+
+Last modified: Thu Mar 4 15:26:13 1999 by Padreic
+
diff --git a/doc/sphinx/lfun/catch_msg.rst b/doc/sphinx/lfun/catch_msg.rst
new file mode 100644
index 0000000..481905b
--- /dev/null
+++ b/doc/sphinx/lfun/catch_msg.rst
@@ -0,0 +1,26 @@
+catch_msg()
+===========
+
+SYNOPSIS
+--------
+::
+
+ void catch_msg(mixed *arr, object obj)
+
+DESCRIPTION
+-----------
+::
+
+ When say(), tell_object() or tell_room() are used with an array
+ as message, the array will be passed to catch_message() in all living
+ objects that can hear it, instead of writing to the user resp.
+ sending to catch_tell(). This can be used to implement
+ communication protocols between livings. The second denotes
+ the object that has sent the message.
+
+SEE ALSO
+--------
+::
+
+ say(E), tell_room(E), tell_object(E), catch_tell(L)
+
diff --git a/doc/sphinx/lfun/catch_tell.rst b/doc/sphinx/lfun/catch_tell.rst
new file mode 100644
index 0000000..d5725bc
--- /dev/null
+++ b/doc/sphinx/lfun/catch_tell.rst
@@ -0,0 +1,36 @@
+catch_tell()
+============
+
+SYNOPSIS
+--------
+::
+
+ void catch_tell(string)
+
+DESCRIPTION
+-----------
+::
+
+ When a message is sent to a noninteractive player, via say(),
+ tell_object, tell_room(), printf() or write(), it will get to the
+ function catch_tell(string). This will enable communications between
+ NPCs and from a player to an NPC.
+
+ Also, if an interactive object is being shadowed and the
+ shadow has catch_tell() defined, it will receive all output
+ that would otherwise be written to the user.
+
+ If a message is sent by an interactive object, catch_tell() is
+ not called in that object, to prevent recursive calls. Thus
+ catch_tell() in interactive objects can be used to filter the
+ output that goes to the users.
+
+ The efun shout() sends to interactive objects only.
+
+SEE ALSO
+--------
+::
+
+ enable_commands(E), say(E), tell_object(E), tell_room(E),
+ write(E), catch_msg(L)
+
diff --git a/doc/sphinx/lfun/check_and_update_timed_key.rst b/doc/sphinx/lfun/check_and_update_timed_key.rst
new file mode 100644
index 0000000..47f6bf0
--- /dev/null
+++ b/doc/sphinx/lfun/check_and_update_timed_key.rst
@@ -0,0 +1,117 @@
+check_and_update_timed_key()
+============================
+
+FUNKTION
+--------
+::
+
+ public int check_and_update_timed_key(int duration, string key)
+
+
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ int duration: In wieviel Sekunden wird <key> wieder freigebeben,
+ (z.B. wann kann der Spieler an dieser Stelle eine neue
+ Heilung bekommen).
+ string key : Eindeutiger Name, wird zusammen mit <duration>
+ gespeichert.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion hat die Aufgabe, Zeitsperren verschiedenster Art
+ einfach zu ermoeglichen (z.B. die Realisierung charakter-abhaengiger
+ Heilstellen u.ae.).
+
+ <key> muss eindeutig sein, am besten verwendet man den eigenen
+ Magiernamen (und ggf. nen Gebietsnamen) als Teil des Strings.
+
+ Die Funktion ist definiert in /std/living/life.c. Somit funktioniert
+ sie auch bei NPCs. Die Daten werden in P_TIMING_MAP gespeichert, sind
+ also gegen "ende" resistent. (werden allerdings nach Ablauf ggf.
+ 'aufgeraeumt')
+
+ Das Mapping P_TIMING_MAP ist NICHT zur Abfrage und / oder Manipulation
+ 'per Hand' vorgesehen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0 Irgendein Fehler im Aufruf, evtl. existiert die Funktion (noch)
+ nicht im jew. Objekt.
+
+ -1 Alles okay. Neuer Zeitpunkt wird automatisch gespeichert. In
+ diesem Fall darf der Spieler geheilt werden.
+
+ >0 Key noch gesperrt, in dem Fall darf also nicht geheilt werden.
+ Der Rueckgabewert ist der Zeitpunkt, ab dem <key> wieder frei ist,
+ laesst sich daher dazu nutzen, um dem Spieler einen Anhaltspunkt
+ zu geben, wann er die Stelle wieder nutzen kann, etwa:
+
+ "Die Schale ist erst halb voll, Du musst noch etwas warten."
+
+BEISPIELE
+---------
+::
+
+ Eine Heilstelle soll jedem Spieler alle 5min zur Verfuegung stehen:
+
+ AddCmd(({"trink","trinke"}),"trink_cmd");
+
+ int trink_cmd(string str){
+ ...
+ ...
+ /*
+ Der key sollte natuerlich eine etwas eindeutigere Kennzeichnung
+ wie etwa "tilly_trinken" bekommen, auch wenn er durch einen
+ anderen (gleichnamigen) nicht ueberschrieben werden kann.
+
+ Trifft diese Abfrage hier zu, kann dem Spieler Heilung o.ae. zu-
+ gefuehrt werden. Die neue Zeit (duration) wird automatisch gesetzt.
+ */
+ if(this_player()->check_and_update_timed_key(300,"jof_trinken")==-1){
+ if(this_player()->drink_soft(2)){
+ this_player()->heal_self(50);
+ write("Du fuehlst Dich sichtlich erfrischt.\n");
+ return 1;
+ }
+ else{
+ write("Du hast schon zuviel getrunken.\n");
+ return 1;
+ }
+ }
+ else {
+ write("Du trinkst und denkst . o O (Hmm, nicht schlecht).\n");
+ return 1;
+ }
+ return 0;
+ }
+
+BEMERKUNGEN:
+ Auch bei dieser Funktion ist darauf zu achten, dass Properties wie
+ P_FOOD, P_DRINK und P_ALCOHOL beruecksichtigt werden.
+ Heilstellen sind dem zustaendigen Magier fuer Heilungs-Balance zu
+ melden. Wer dies momentan ist, kann dem Mailalias heilungs_balance
+ entnommen werden.
+
+SIEHE AUCH
+----------
+::
+
+ check_timed_key, eat_food, drink_alcohol, drink_soft, heal_self,
+ restore_spell_points, reduce_hit_point
+
+
+08.01.2012, Zesstra
+
diff --git a/doc/sphinx/lfun/check_restrictions.rst b/doc/sphinx/lfun/check_restrictions.rst
new file mode 100644
index 0000000..b764a5d
--- /dev/null
+++ b/doc/sphinx/lfun/check_restrictions.rst
@@ -0,0 +1,173 @@
+check_restrictions()
+====================
+
+FUNKTION
+--------
+::
+
+ string check_restrictions(object pl, mapping restr)
+
+DEFINIERT IN
+------------
+::
+
+ /std/restriction_checker.c
+
+ARGUMENTE
+---------
+::
+
+ object pl geprueftes Lebewesen
+ mapping restr Mapping mit Restriktionen, s.u.
+
+BESCHREIBUNG
+------------
+::
+
+ Die Methode wird verwendet, um Restriktionen (zum Beispiel fuer das
+ Casten eines Spells) zu pruefen. Sie wird von Spellbook und
+ Gildenobjekt direkt genutzt.
+
+ Ihr wird dabei ein Spielerobjekt sowie ein Mapping mit den jeweiligen
+ Restriktionen uebergeben. Die aktuell moeglichen Keys des Mappings sind
+ weiter unten gelistet.
+
+BEMERKUNGEN
+-----------
+::
+
+ Es wird bei der Rasse P_REAL_RACE geprueft. Der Tarnhelm funktioniert
+ also nicht.
+
+ Bei Erweiterungsvorschlaegen wendet euch bitte an einen EM oder
+ inheritet im Zweifelsfall nach Absprache.
+ NIEMALS solchen Code einfach KOPIEREN. Spaeter muss nur irgendwer
+ eurem alten Code hinterherraeumen.
+
+Aktuelle Liste der pruefbaren Parameter:
+ P_LEVEL
+ Mindeststufe, die das Lebewesen besitzen muss, um die Aktion
+ auszufuehren.
+ P_GUILD_LEVEL
+ Gildenlevel, das das Lebewesen mindestens erreicht haben muss, um die
+ Aktion auszufuehren.
+ SR_SEER
+ Ist gesetzt, wenn das Lebewesen Seher sein muss.
+ Auswertung nur fuer Interactives, NSC ignorieren das Flag.
+ P_XP
+ Mindestmenge an Erfahrungspunkten, die ein Lebewesen besitzen muss,
+ um die Aktion auszufuehren.
+ P_QP
+ Mindestmenge an Abenteuerpunkten, die das Lebewesen haben muss.
+ P_ALCOHOL
+ Menge an Alkohol, unter der der Alkoholspiegel des Lebewesen liegen
+ muss, um die Aktion noch ausfuehren zu koennen.
+ P_DRINK
+ Menge an Fluessigkeit, unter der der Fluessigkeitsspiegel des
+ Lebewesen liegen muss, um die Aktion noch ausfuehren zu koennen.
+ P_FOOD
+ Beinhaltet die Menge an Nahrung, unter der der Nahrungsspiegel des
+ Spielers liegen muss, um die Aktion noch ausfuehren zu koennen.
+ P_DEAF
+ Ist gesetzt, falls der Spieler nicht taub sein darf.
+ P_FROG
+ Ist gesetzt, falls der Spieler kein Frosch sein darf.
+ P_BLIND
+ Ist gesetzt, falls der Spieler nicht blind sein darf.
+ Achtung: das ist nicht gleichbedeutend mit dem Umstand, dass er evtl.
+ nichts mehr sehen kann. Auch andere Gruende (zum Beispiel Dunkelheit)
+ koennen bewirken, dass ein Spieler nichts mehr sieht.
+ A_INT, A_DEX, A_CON, A_STR
+ Jeweilige Mindesthoehe eines Attribut, um eine Aktion ausfuehren zu
+ koennen.
+ SR_BAD, SR_GOOD
+ Gibt an, wie [minimal] boese bzw. wie [maximal] gut ein Charakter sein
+ darf, um eine Aktion ausfuehren zu koennen.
+ SR_MIN_SIZE, SR_MAX_SIZE
+ Gibt die minimale, bzw. die maximale Groesse an, die ein Charakter
+ maximal haben darf, um eine Aktion ausfuehren zu koennen.
+ SR_FREE_HANDS
+ Gibt an, wieviele freie Haende ein Charakter fuer diese Aktion
+ besitzen muss.
+ SR_EXCLUDE_RACE
+ Mitglieder aller in dieser Liste aufgefuehrten Rassen koennen
+ diese Aktion nicht ausfuehren.
+ SR_INCLUDE_RACE
+ Mitglieder aller NICHT in dieser Liste aufgefuehrten Rassen koennen
+ diese Aktion nicht ausfuehren.
+ SM_RACE
+ Hier kann pro Rasse ein Mapping mit besonderen (nur) fuer diese Rasse
+ geltenden Einschraenkungen vorgenommen werden. Als Keys sind die
+ in dieser Manpage beschriebenen Keys erlaubt, wobei SM_RACE nicht
+ rekursiv ausgewertet wird.
+ Der Rassenname ist gross geschrieben und "*" steht fuer alle Rassen.
+ SR_EXCLUDE_GUILD
+ SR_INCLUDE_GUILD
+ Diese beiden Keys verhalten sich wie SR_*_RACE, nur dass hier Gilden
+ genannt werden.
+ SR_FUN
+ Hier kann eine Funktion in verschiedenen Formen zum Pruefen der
+ Restriktionen angegeben werden, siehe execute_anything().
+ Das kann nuetzlich sein, um andere Restriktionen zu pruefen,
+ wie das Bestehen von Miniquests oder andere Faehigkeiten/Flags.
+ Ist der Test nicht bestanden, gibt die Funktion einen String zurueck.
+ SR_PROP
+ Hier kann ein Mapping mit Properties und zugehoerigen Werten angegeben
+ werden, die jeweils auf Identitaet geprueft werden. Zusaetzlich sollte
+ eine Meldung angegeben werden, die als Fehlermeldung ausgegeben wird,
+ wenn der Spieler die Bedingung nicht erfuellt. Es sollte immer eine
+ passende Meldung fuer den Spieler eingebaut werden. Beispiel:
+ ([ SR_PROP: ([P_AUSGANG_ENTDECKT: 1; "Dein Schwert fluestert "
+ "veraergert: Ich werde Dir erst dann zu Diensten sein, wenn Du "
+ "Dich als wuerdig erwiesen hast!"]) ])
+ Aufgrund der Meldung wird empfohlen, SR_PROP nicht in Restriktionen
+ einzusetzen, die massenweise in Savefiles landen (z.B.
+ Spielersavefiles).
+ SR_QUEST
+ Hier kann ein String-Array mit den Namen (Keys) der Quest(s) angegeben
+ werden, die der Spieler bestanden haben muss, um die Aktion ausfuehren
+ zu koennen.
+ SQ_MINIQUEST
+ Hier kann entweder ein String-Array mit den Ladenamen der vergebenden
+ Objekte oder ein Int-Array mit den Index-Nummern (IDs) der
+ Miniquest(s) (empfohlen!) angegeben werden, die der Spieler bestanden
+ haben muss, um die Aktion ausfuehren zu koennen.
+
+BEISPIELE
+---------
+::
+
+ // #1 Levelbeschraenkung in der Abenteurergilde
+ AddSpell("feuerball",20,
+ ([SI_SKILLRESTR_LEARN:([P_LEVEL:15]), ...
+
+ // #2 Glaubenstest im Klerus
+ AddSpell("bete",
+ ([SI_SKILLRESTR_LEARN: ([P_GUILD_LEVEL : LVL_NOVIZE,
+ SR_FUN : #'glaubensTest ]), ...
+ // mit
+ static string glaubensTest(object pl) {
+ if (pl->QueryProp(K_STRENGTH) < 8000)
+ return ("Deine Glaubensstaerke laesst zu wuenschen uebrig!\n");
+ return 0;
+ }
+
+ // #3 SM_RACE-Modifikation der Restriktionen:
+ // haertere Restriktionen fuer Zwerge
+ // - hoeheres Level
+ // - zusaetzlich A_STR pruefen
+ ([P_LEVEL:15,
+ A_INT:10,
+ SM_RACE: (["Zwerg": ([P_LEVEL:17, A_STR:20])])])
+ // ist identisch zu
+ ([SM_RACE: (["*": ([P_LEVEL:15, A_INT:10]),
+ "Zwerg": ([P_LEVEL:17, A_INT:10, A_STR:20])])])
+
+SIEHE AUCH
+----------
+::
+
+ execute_anything(L), AddSpell (Gilde), P_RESTRICTIONS
+
+03. Januar 2014, Arathorn
+
diff --git a/doc/sphinx/lfun/check_timed_key.rst b/doc/sphinx/lfun/check_timed_key.rst
new file mode 100644
index 0000000..9533cea
--- /dev/null
+++ b/doc/sphinx/lfun/check_timed_key.rst
@@ -0,0 +1,55 @@
+check_timed_key()
+=================
+
+FUNKTION
+--------
+::
+
+ public int check_timed_key(string key)
+
+
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ string key : Eindeutiger Name
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion hat die Aufgabe, mittels check_and_update_timed_key()
+ gespeicherte Zeitsperren zu pruefen, aber dabei nicht zu veraendern.
+
+ Es MUSS bei der eigentlichen Aktion (z.B. Heilung des Spielers) der
+ Rueckgabewert von check_and_update_timed_key() beruecksichtigt werden,
+ sollte dieses nicht -1 geliefert haben, MUSS <key> als gesperrt
+ betrachtet werden, d.h. check_timed_key() hat nur informativen
+ Charakter.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 0 Die Zeitsperre <key> ist abgelaufen.
+
+ >0 <key> ist noch gesperrt.
+ Der Rueckgabewert ist der Zeitpunkt, ab dem <key> wieder frei ist,
+
+SIEHE AUCH
+----------
+::
+
+ check_and_update_timed_key, eat_food, drink_alcohol, drink_soft,
+ heal_self, restore_spell_points, reduce_hit_point
+
+
+08.01.2012, Zesstra
+
diff --git a/doc/sphinx/lfun/clean_up.rst b/doc/sphinx/lfun/clean_up.rst
new file mode 100644
index 0000000..26d1022
--- /dev/null
+++ b/doc/sphinx/lfun/clean_up.rst
@@ -0,0 +1,67 @@
+clean_up()
+==========
+
+FUNKTION
+--------
+::
+
+ int clean_up(int ref);
+
+DEFINIERT IN
+------------
+::
+
+ /std/room.c
+ man kann die Funktion jedoch auch in beliebigen Objekten selbst
+ definieren.
+
+ARGUMENTE
+---------
+::
+
+ ref
+ + 0 bei gecloneten Objekten
+ + 1 bei einfachen geladenen Objekten
+ + >1 bei Objekten, die geerbt wurden oder als Blueprint dienen
+ + <0, wenn clean_up() von aussen aufgerufen wurde (das muss man
+ selbst beachten!)
+
+BESCHREIBUNG
+------------
+::
+
+ Wenn ein Objekt seit langer Zeit nicht mehr benutzt wurde, kann es sich
+ hier selbst zerstoeren. Das sollte das Objekt allerdings nur tun, wenn
+ ref kleiner oder gleich 1 ist.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der Rueckgabewert hat nur dann eine Bedeutung, wenn sich das Objekt
+ nicht selbst zerstoert hat. Wird 0 zurueckgegeben, so wird clean_up()
+ erst dann wieder aufgerufen, nachdem das Objekt aus- und wieder
+ eingeswappt wurde.
+
+ Ein Rueckgabewert ungleich 0 zeigt an, dass das Objekt sich
+ wahrscheinlich in der naechsten clean_up()-Runde zerstoeren kann, wenn
+ in der Zwischenzeit zB. noch einmal reset() aufgerufen wurde.
+
+BEMERKUNGEN
+-----------
+::
+
+ Standardmaessig definieren nur Raeume clean_up().
+
+ Die Zeiten zwischen zwei Aufrufen von clean_up() betragen momentan
+ einen Tag (86400 Sekunden).
+
+SIEHE AUCH
+----------
+::
+
+ reset(), P_NEVER_CLEAN
+ memory
+
+21. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/cmd_shoot.rst b/doc/sphinx/lfun/cmd_shoot.rst
new file mode 100644
index 0000000..a8b11d5
--- /dev/null
+++ b/doc/sphinx/lfun/cmd_shoot.rst
@@ -0,0 +1,54 @@
+cmd_shoot()
+===========
+
+FUNKTION
+--------
+::
+
+ static int cmd_shoot(string str)
+
+DEFINIERT IN
+------------
+::
+
+ /std/ranged_weapon.c
+
+ARGUMENTE
+---------
+::
+
+ string str - Schusssyntax
+
+BESCHREIBUNG
+------------
+::
+
+ Kommandofunktion der Fernwaffe. Enthaelt die Vorbereitung und den Schuss.
+
+BEMERKUNGEN
+-----------
+::
+
+ Ist in der Fernwaffe mit AddCmd( ({"schiess", "schiesse"}), "cmd_shoot");
+ angebunden. Will man eine andere Syntax haben, kann man mit
+ AddCmd/RemoveCmd diese umsetzen.
+
+BEISPIELE
+---------
+::
+
+ RemoveCmd(({"schiess", "schiesse"})); // entferne Default-Kommando
+ AddCmd(({"schleuder", "schleudere"}), #'cmd_shoot);
+
+SIEHE AUCH
+----------
+::
+
+ Generell: P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
+ Methoden: shoot_dam(L), cmd_shoot(L)
+ Kommandos: AddCmd(L), RemoveCmd(L)
+ Syntax: _unparsed_args(L)
+ Sonstiges: fernwaffen
+
+28.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/lfun/command_me.rst b/doc/sphinx/lfun/command_me.rst
new file mode 100644
index 0000000..df3eaf3
--- /dev/null
+++ b/doc/sphinx/lfun/command_me.rst
@@ -0,0 +1,110 @@
+command_me()
+============
+
+FUNKTION
+--------
+::
+
+ int command_me(string str)
+
+ARGUMENTE
+---------
+::
+
+ string str - auszufuehrendes Kommando
+
+DEFINIERT IN
+------------
+::
+
+ /std/npc.c, /std/player/command.c
+
+BESCHREIBUNG
+------------
+::
+
+ Fuehrt 'str' wie ein Kommando aus, welches direkt vom Living
+ abgegeben wurde.
+
+ Der Rueckgabewert ist >=1 fuer Erfolg und 0 fuer Misserfolg.
+ Rueckgabewert ist im Erfolgsfall die Hoehe der EvalCost in Ticks.
+
+ command_me() leitet den Befehl an command()(E) weiter und erlaubt
+ dadurch auch den Aufruf von sonst durch "static", "protected" oder
+ "private" vor externem Aufruf geschuetzten Kommando-Funktionen.
+
+ Kommandos mit oeffentlichen Kommandofunktionen (also damit alle mit
+ AddCmd definierten Kommandos) koennen auch durch command()(E)
+ von aussen ausgeloest werden.
+
+BEMERKUNGEN:
+ - beruecksichtigt Aliase, d.h. wenn man Aliase eines Spielers
+ ignorieren will, muss man ein \\ (fuer ein \ im Eingabestring)
+ vor den Befehl stellen
+ - fuer objektinterne Kommandos funktioniert also auch command()(E)
+
+BEISPIEL
+--------
+::
+
+ (Code des Testraum ist in /doc/beispiele/testobjekte/command_me_testraum)
+ // #1: Testraum, zwinge Spieler bei "schleiche heran" zum Furzen
+ // command_me() ist hier noetig, da das Furzen eine geschuetzte
+ // Kommandofunktion hat
+ inherit "/std/room";
+
+ void create() {
+ ::create();
+ AddCmd("schleiche&heran|herum", "action_schleichen");
+ }
+
+
+
+ void init() {
+ ::init();
+ add_action("action_kriechen", "kriech", 1);
+ }
+
+ static int action_schleichen(string str) {
+ string tmp = this_player()->QueryProp(P_RACE);
+ // ...
+ if(tmp[<1]=='e') tmp=tmp[0..<2];
+ write(break_string("Du versuchst leise zu schleichen, dabei passiert "
+ "dir aber ein allzu "+
+ (tmp=="Mensch"?"menschliches":lower_case(tmp)+"isches")+
+ " Missgeschick. Verflucht!", 78));
+ this_player()->command_me("\\furze");
+ return 1;
+ }
+
+
+
+ static int action_kriechen(string str) {
+ write(break_string("Deine Knie tun zu sehr weh dafuer.", 78));
+ tell_room(this_object(), break_string(this_player()->Name(WER)+
+ " knackt mit den Knien.", 78));
+ return 1;
+ }
+
+
+
+ // #2 (in obigem Raum): zwinge Spieler in Raum zu obigem Kommando
+ // Beide Kommandos gelingen, da Kommando mit AddCmd definiert.
+ find_player("naddl")->command_me("schleiche herum")
+ command("schleiche herum", find_player("naddl"));
+
+ // #3 (in obigem Raum): zwinge Spieler in Raum zu obigem Kommando
+ find_player("naddl")->command_me("krieche")
+ // Folgendes Kommando schlaegt fehl, da Kommandofunktion static ist.
+ command("krieche", find_player("naddl"));
+
+
+
+SIEHE AUCH
+----------
+::
+
+ enable_commands(E), command(E)
+
+06 Sep 2012 Gloinson
+
diff --git a/doc/sphinx/lfun/consume.rst b/doc/sphinx/lfun/consume.rst
new file mode 100644
index 0000000..25ab213
--- /dev/null
+++ b/doc/sphinx/lfun/consume.rst
@@ -0,0 +1,115 @@
+consume()
+=========
+
+public varargs int consume(mapping cinfo, int testonly)
+
+FUNKTION
+--------
+::
+
+ public varargs int consume(mapping cinfo, int testonly);
+
+ Aenderung der Gesundheit eines Lebewesens durch etwas Konsumierbares.
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ cinfo
+ Mapping mit Informationen ueber die Gesundheitsaenderung
+ Heilung.
+ testonly
+ Gibt an, ob nur die Bedingungen abgetestet werden sollen,
+ oder auch die Wirkung eintreten soll.
+
+RUECKGABEWERT
+-------------
+::
+
+ 1 erfolgreich konsumiert
+ 0 keine oder falsche Aenderungsdaten in cinfo (nicht benutzbar)
+ <0 Bedingung fuer konsumieren nicht erfuellt, Bitset aus:
+ HC_MAX_FOOD_REACHED - Kann nichts mehr essen
+ HC_MAX_DRINK_REACHED - Kann nichts mehr trinken
+ HC_MAX_ALCOHOL_REACHED - Kann nichts mehr saufen
+ HC_HOOK_CANCELLETION - durch H_HOOK_CONSUME abgebrochen
+
+BESCHREIBUNG
+------------
+::
+
+ Die Funktion stellt eine Moeglichkeit zur Verfuegung, die Aenderung
+ der Gesundheit eines Lebewesens beim Konsumieren von irgendetwas (z.B in
+ einer Kneipe, durch eine Heilstellte oder tragbare Tanke, ...) zentral zu
+ erledigen. Sie vereint in sich die Pruefung auf Durchfuerbarkeit der
+ Aenderung und Anwendung der Aenderung.
+
+ Der erste Parameter gibt die Eigenschaften der Aenderung an, der zweite ob
+ ausschliesslich die Pruefung auf Anwendbarkeit erfolgen soll.
+
+ Das Mapping cinfo hat folgende Struktur:
+ a) Einfache Angabe der betroffenen Properties. In neuem Code bitte nicht
+ machen, dort ein Mapping wie unter b) beschrieben nutzen!
+
+ b) Strukturiert in Effekte und Bedingungen mit folgenden Schluesseln:
+ H_EFFECTS - Mapping der zu aendernden Properties mit dem Umfang der
+ Aenderung, erlaubte Properties siehe H_ALLOWED_EFFECTS
+
+ H_CONDITIONS - Mapping der zu pruefenden Properties mit dem Umfang der
+ Aenderung, erlaubte Properties siehe H_ALLOWED_CONDITIONS
+
+ H_DISTRIBUTION - Verteilung der Aenderung fuer P_SP, P_HP
+ HD_INSTANT bzw. 0: instante Heilung
+ 1 - 50: angebene Zahl pro Heartbeat
+ HD_STANDARD: 5 pro Heartbeat
+
+ Aenderungen koennen sowohl positiv als auch negativ sein.
+
+BEMERKUNGEN
+-----------
+::
+
+ Hierbei aber bitte beachten, dass Tanken/Entanken sowie Heilungen ggf. von
+ der (Heilungs-)Balance genehmigt werden muessen!
+
+BEISPIELE
+---------
+::
+
+ Heilung um 100 KP, 50 LP, aber nur wenn 30 P_FOOD gegessen werden kann:
+
+ consume( ([H_EFFECTS: ([P_HP:50, P_SP:100]),
+ H_CONDITIONS: ([P_FOOD:30]) ]) );
+
+ Heilung um 100 KP und Vergiftung um 2, wenn 15 Alkohol getrunken werden
+ koennen. Die SP werden zeitverzoegert mit 10 pro Heartbeat zugefuehrt.
+
+ consume(([H_EFFECTS: ([P_SP: 100, P_POISON: 2]),
+ H_CONDITIONS: ([P_ALCOHOL: 15]),
+ H_DISTRIBUTION: 10]) )
+
+SIEHE AUCH
+----------
+::
+
+ Aehnlich: drink_alcohol, eat_food, drink_soft
+ Heilung: heal_self, restore_spell_points, restore_hit_points,
+ buffer_hp, buffer_sp
+ Timing: check_and_update_timed_key
+ Enttanken: defuel_drink, defuel_food
+ Props: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+ P_DEFUEL_TIME_DRINK
+ Konzepte: heilung, enttanken, food
+
+LETZTE AeNDERUNG
+----------------
+::
+
+ 29.05.2015, Boing
+
diff --git a/doc/sphinx/lfun/create.rst b/doc/sphinx/lfun/create.rst
new file mode 100644
index 0000000..c89fa17
--- /dev/null
+++ b/doc/sphinx/lfun/create.rst
@@ -0,0 +1,104 @@
+create()
+========
+
+FUNKTION
+--------
+::
+
+ protected void create();
+ void create();
+
+DEFINIERT IN
+------------
+::
+
+ allen Standardobjekten
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird aufgerufen, wenn ein Objekt geladen oder geclont
+ wird.
+ In dieser Funktion wird das Objekt initialisiert und konfiguriert.
+ Waehrend des create() kann es einen this_player()/this_interactive()
+ geben, muss aber nicht!
+ Im create() hat das Objekt noch kein environment().
+ create() wird nur gerufen, wenn das Objekte geclont oder explizit geladen
+ wird. Wenn es aufgrund eines inherit in einem anderen Objekt vom Driver
+ geladen wird, wird das create() nicht ausgefuehrt (s. create_super()).
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Erbt man von anderen Objekten, so besteht die erste Aktion innerhalb
+ von create() normalerweise darin, in diesen Objekten create()
+ aufzurufen.
+ Die Funktion kann protected oder static sein (aber nicht private). Es
+ duerfte fuer die meisten Objekte sinnvoll sein, create() protected zu
+ deklarieren.
+
+ Um Speicher zu sparen, kann man bei Blueprints von der Konfigurierung
+ absehen (siehe Beispiel). Dies sollte man allerdings nicht bei Objekten
+ machen, von denen keine Clones erzeugt werden sollen (zB. bei Raeumen).
+
+ Man sollte bei Abbruch des create() in BP unbedingt set_next_reset(-1);
+ rufen, da sonst die (nicht konfigurierte) BP resetten kann und dann
+ buggt.
+
+BEISPIELE
+---------
+::
+
+ Ein Gegenstand wuerde wie folgt konfiguriert:
+
+ inherit "std/thing";
+
+ #include <properties.h>
+
+ create()
+ {
+ // Wenn wir die Blueprint sind: NICHT konfigurieren!
+ // Bei normalen Raeumen oder Transportern sind diese beiden
+ // Zeilen wegzulassen!!!
+ if (!clonep(this_object())) {
+ set_next_reset(-1); // wichtig, damit die BP nicht resettet.
+ return;
+ }
+
+ // Ansonsten die allgemeinen Eigenschaften von /std/thing
+ // konfigurieren...
+ ::create();
+
+ // ...und nun unsere speziellen Eigenschaften:
+ SetProp(P_NAME, "Muell");
+ SetProp(P_SHORT, "Muell");
+ SetProp(P_LONG, "Voellig unnuetzer Muell!\n");
+ SetProp(P_ARTICLE, 0);
+ SetProp(P_VALUE, 0);
+ SetProp(P_GENDER, MALE);
+ }
+
+SIEHE AUCH
+----------
+::
+
+ create(L), reset(L)
+ hook(C), create(H), create_ob(H), create_super(H, reset(H)
+ create(A), reset(A)
+
+22.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/create_default_npc.rst b/doc/sphinx/lfun/create_default_npc.rst
new file mode 100644
index 0000000..8507388
--- /dev/null
+++ b/doc/sphinx/lfun/create_default_npc.rst
@@ -0,0 +1,76 @@
+create_default_npc()
+====================
+
+FUNKTION
+--------
+::
+
+ varargs void create_default_npc( int level, int maxhp );
+
+BENUTZUNG
+---------
+::
+
+ inherit "std/npc";
+
+FUNKTION
+--------
+::
+
+ Setze die Daten eines Monsters auf einen gewissen Level.
+
+ Der Level sollte zwischen 1 und 20 liegen. Die Stats werden auf diesen
+ Level gesetzt und mehrere andere Werte, so dass das Monster von der
+ Staerke her einem Spieler gleichen Levels entspricht.
+
+ Wird der (optionale) Parameter maxhp weggelassen, wird dieser berechnet
+ nach:
+ maxhp = 42 + 8 * level
+
+ Die genauen Werte sind:
+ P_LEVEL : level
+ P_MAX_HP: maxhp
+ P_MAX_SP: maxhp
+ P_HANDS : 10 * level
+ P_BODY : (20/3) * level
+ P_XP : 50 * level * maxhp (== 5 * P_HANDS * max_hp)
+
+ A_STR, A_INT, A_DEX, A_CON : level
+
+BEMERKUNG
+---------
+::
+
+ Diese Funktion sollte nur im create() eines Monsters benutzt werden.
+ Oben beschriebene Werte, die vor dem Aufruf der Funktion gesetzt
+ wurden, werden durch die neuen Werte ersetzt.
+
+ Ab einem Aufruf mit Level 20 werden P_XP = 202000 gesetzt, also ein
+ Kill-Stup vergeben (siehe P_XP).
+
+BEISPIEL
+--------
+::
+
+ create_default_npc(17) ergibt:
+
+ P_LEVEL : 17
+ P_MAX_HP: 178
+ P_MAX_SP: 178
+ P_HANDS : 170
+ P_BODY : 113
+ P_XP : 151300
+
+ A_STR, A_INT, A_DEX, A_CON : 17
+
+SIEHE AUCH
+----------
+::
+
+ Funktionen: AddExp(), GiveKillScore()
+ Properties: P_XP
+ P_LEVEL, P_MAX_HP, P_MAX_SP, P_HANDS, P_BODY
+ Sonstiges: npcs
+
+14.Feb 2007 Gloinson
+
diff --git a/doc/sphinx/lfun/create_super.rst b/doc/sphinx/lfun/create_super.rst
new file mode 100644
index 0000000..79e3b9d
--- /dev/null
+++ b/doc/sphinx/lfun/create_super.rst
@@ -0,0 +1,77 @@
+create_super()
+==============
+
+FUNKTION
+--------
+::
+
+ protected void create_super();
+
+DEFINIERT IN
+------------
+::
+
+ allen Standardobjekten
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird immer dann aufgerufen, wenn ein Objekt implizit durch
+ ein 'inherit' in einem erbenden Objekte geladen wird.
+ Normalweise muss man dieses so geladene Objekte nicht konfigurieren, weil
+ nur das Programm dieses Objektes fuer die erbenden Objekte interessant
+ ist, nicht seine Daten.
+ Was hier aber z.B. sinnvoll ist, ist das Abschalten des Resets, denn ein
+ Objekt, was nur dazu dient, dass es von anderen geerbt wird, braucht
+ keinen Reset, auch wenn es ein reset() definiert (was in erbenden Objekte
+ benutzt wird).
+ Die create_super() in den Standardobjekten tun momentan genau dieses.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Wenn ihr von /std/ erbt, braucht ihr euch in aller Regel um diese
+ Funktion keine Gedanken machen.
+ Ihr koennt diese Funktion aber in Objekten selber definieren, die nur zum
+ Erben gedacht sind. Dies kann sinnvoll ein, wenn ihr nicht von /std/ erbt
+ und ein reset() im Objekt habt oder was machen wollt, was ueber das
+ Abschalten des Resets hinausgeht.
+
+BEISPIELE
+---------
+::
+
+ Gegeben sei folgende Vererbungskette:
+ /std/room -> /d/inseln/zesstra/stdraum -> /d/inseln/zesstra/raum
+
+ Wird nun 'raum' geladen und 'stdraum' ist noch nicht geladen, wird der
+ Driver implizit von selbst 'stdraum' laden (weil 'raum' das Programm von
+ 'stdraum' braucht). Bei diesem Laden wird das create() in 'stdraum' nicht
+ ausgefuehrt, sondern stattdessen create_super().
+
+
+
+SIEHE AUCH
+----------
+::
+
+ create(L), reset(L)
+ hook(C), create(H), create_ob(H), create_super(H, reset(H)
+ create(A), reset(A)
+
+22.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/defuel_drink.rst b/doc/sphinx/lfun/defuel_drink.rst
new file mode 100644
index 0000000..c094538
--- /dev/null
+++ b/doc/sphinx/lfun/defuel_drink.rst
@@ -0,0 +1,89 @@
+defuel_drink()
+==============
+
+FUNKTION
+--------
+::
+
+ int defuel_drink();
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ Keine.
+
+
+
+BESCHREIBUNG
+------------
+::
+
+ Enttankt den Spieler automatisch um einen gewissen Fluessigkeits-Wert,
+ sofern der Spieler ueber einer bestimmten Enttank-Grenze liegt und seit
+ seinem letzten Enttanken eine gewisse Zeit vergangen ist.
+ Alle diese Werte sind rassenabhaengig.
+ Ausserdem wird dem Spieler eine gewisse Menge Alkohol entzogen. Er wird
+ also mit jedem fluessigen Enttanken etwas nuechterner.
+
+ Es ist also NICHT moeglich, Einfluss auf die Menge des Enttankens
+ zu nehmen. Das ist hier so gewollt.
+
+ Hat der Spieler mindestens
+ * P_DEFUEL_LIMIT_DRINK in P_DRINK
+ kann er alle
+ * P_DEFUEL_TIME_DRINK
+ um
+ * (x=P_DRINK*P_DEFUEL_AMOUNT_DRINK/2) + random(x)
+ (also um (50 bis 100 * P_DRINK) Prozent)
+ enttanken.
+
+RUECKGABEWERTE
+--------------
+::
+
+ DEFUEL_TOO_SOON: -2, wenn Enttankintervallzeiten zu kurz.
+ DEFUEL_TOO_LOW: -1, wenn Enttankgrenze noch nicht erreicht.
+ NO_DEFUEL: 0, wenn Enttanken nicht noetig war (Spieler war leer)
+ >0, wenn Erfolg (enttankte Wert wird zurueckgegeben).
+
+ (Konstanten kommen aus /sys/defuel.h)
+
+BEMERKUNG
+---------
+::
+
+ Bitte defuel_drink() benutzen und nicht P_DRINK oder P_MAX_DRINK des
+ manipulieren!
+
+ Es gibt keine eigene Methode fuer die Verringerung von P_ALCOHOL.
+
+ Achtung: Nur Toiletten sollten diese Funktion im Spieler aufrufen!
+
+BEISPIEL
+--------
+::
+
+ s. Bsp. zu defuel_food()
+
+SIEHE AUCH
+----------
+::
+
+ Aehnlich: defuel_food
+ Tanken: consume, drink_alcohol, drink_soft, eat_food
+ Heilung: heal_self, restore_spell_points, restore_hit_points,
+ buffer_hp, buffer_sp
+ Timing: check_and_update_timed_key
+ Props: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+ P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+ Konzepte: heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/defuel_food.rst b/doc/sphinx/lfun/defuel_food.rst
new file mode 100644
index 0000000..a824946
--- /dev/null
+++ b/doc/sphinx/lfun/defuel_food.rst
@@ -0,0 +1,113 @@
+defuel_food()
+=============
+
+FUNKTION
+--------
+::
+
+ int defuel_food();
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ Keine.
+
+BESCHREIBUNG
+------------
+::
+
+ Enttankt den Spieler automatisch um einen gewissen Essens-Wert,
+ sofern der Spieler ueber einer bestimmten Enttank-Grenze liegt und seit
+ seinem letzten Enttanken eine gewisse Zeit vergangen ist.
+ Alle diese Werte sind rassenabhaengig.
+
+ Es ist also NICHT moeglich, Einfluss auf die Menge des Enttankens
+ zu nehmen. Das ist hier so gewollt.
+
+ Hat der Spieler mindestens
+ * P_DEFUEL_LIMIT_FOOD in P_FOOD
+ kann er alle
+ * P_DEFUEL_TIME_FOOD
+ um
+ * (x=P_DRINK*P_DEFUEL_AMOUNT_FOOD/2) + random(x)
+ (also um (50 bis 100 * P_FOOD) Prozent)
+ enttanken.
+
+RUECKGABEWERTE
+--------------
+::
+
+ DEFUEL_TOO_SOON: -2, wenn Enttankintervallzeiten zu kurz.
+ DEFUEL_TOO_LOW: -1, wenn Enttankgrenze noch nicht erreicht.
+ NO_DEFUEL: 0, wenn Enttanken nicht noetig war (Spieler war leer)
+ >0, wenn Erfolg (enttankte Wert wird zurueckgegeben).
+
+ (Konstanten kommen aus /sys/defuel.h)
+
+BEMERKUNG
+---------
+::
+
+ Bitte defuel_food() benutzen und nicht P_FOOD oder P_MAX_FOOD des
+ Spielers manipulieren!
+
+ Achtung: Nur Toiletten sollten diese Funktion im Spieler aufrufen!
+
+BEISPIEL
+--------
+::
+
+ int action_enttanken() {
+ string msg;
+ int val = this_player()->defuel_food();
+
+ switch (val) {
+ case DEFUEL_TOO_SOON:
+ msg = "Du warst doch erst vor kurzem auf Toilette...";
+ break;
+ case DEFUEL_TOO_LOW:
+ msg = "Du versuchst Dich zu entleeren, aber irgendwie will "
+ "das nicht so recht klappen.";
+ break;
+ case NO_DEFUEL:
+ msg = "Du hast seit langem nichts gegessen, wie willst Du dann "
+ "was loswerden koennen?";
+ break;
+ default:
+ string qualifier;
+ int fuzzypercent = (90+random(20)) *
+ val/this_player()->QueryProp(P_MAX_FOOD);
+ switch(fuzzypercent) {
+ case 0..50: qualifier = "etwas"; break;
+ case 51..75: qualifier = "enorm"; break;
+ default: qualifier = "unglaublich"; break;
+ }
+ msg = "Du entleerst Dich "+qualifier"+. Puh, das tat gut!";
+ break;
+ }
+ tell_object(this_player(), break_string(msg, 78));
+ return 1;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Aehnlich: defuel_drink
+ Tanken: consume, drink_alcohol, drink_soft, eat_food
+ Heilung: heal_self, restore_spell_points, restore_hit_points,
+ buffer_hp, buffer_sp
+ Timing: check_and_update_timed_key
+ Props: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+ P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+ Konzepte: heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/deregister_modifier.rst b/doc/sphinx/lfun/deregister_modifier.rst
new file mode 100644
index 0000000..48f994c
--- /dev/null
+++ b/doc/sphinx/lfun/deregister_modifier.rst
@@ -0,0 +1,42 @@
+deregister_modifier()
+=====================
+
+FUNKTION
+--------
+::
+
+ void deregister_modifier(object modifier)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/attributes.c
+
+PARAMETER
+---------
+::
+
+ modifier - Objekt mit P_X_ATTR_MOD oder P_M_ATTR_MOD
+
+BESCHREIBUNG
+------------
+::
+
+ Meldet einen Modifier im Spieler ab. Wird durch RemoveSensitiveObject
+ beziehungsweise beim Ausziehen oder Wegstecken gerufen.
+ Muss nicht direkt gerufen werden. Bei Veraenderungen von Modifikatoren
+ sollte stattdessen UpdateAttributes gerufen werden.
+
+SIEHE AUCH
+----------
+::
+
+ QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+ SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+ register_modifier(),P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS,
+ P_ATTRIBUTES_MODIFIER, P_X_ATTR_MOD, P_M_ATTR_MOD,
+ /std/living/attributes.c
+
+13.Jun.2004, Muadib
+
diff --git a/doc/sphinx/lfun/die.rst b/doc/sphinx/lfun/die.rst
new file mode 100644
index 0000000..84feb1d
--- /dev/null
+++ b/doc/sphinx/lfun/die.rst
@@ -0,0 +1,68 @@
+die()
+=====
+
+FUNKTION
+--------
+::
+
+ public varargs void die(int poisondeath,int extern);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ int poisondeath
+ Dieses Flag sollte bei einem Gifttod (P_POISON) gesetzt sein.
+ int extern
+ Intern.
+
+BESCHREIBUNG
+------------
+::
+
+ Das Lebewesen stirbt, meist automatisch von do_damage() ausgeloest, wenn
+ 0 HP unterschritten werden. In diesem Fall wird der Kampf beendet, Gift,
+ Alkohol, Trink- und Esswerte, Blindheit, Taubheit u.s.w. auf Null
+ gesetzt oder geloescht.
+
+ Es wird automatisch eine Leiche (siehe auch P_CORPSE, P_NOCORPSE) nebst
+ Todesmeldungen (siehe auch P_DIE_MSG) erzeugt, und fuer Spieler werden
+ Killstupse vergeben, sofern notwendig.
+
+ Ueber den Hook P_TMP_DIE_HOOK kann man jedoch auf den Automatismus
+ Einfluss nehmen, z.B. koennte ein temporaerer Todesbann-Zauber das
+ Sterben fuer kurze Zeit verhindern.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Diese Funktion sollte nur selten direkt verwendet werden. Meist ist der
+ uebliche Weg ueber Defend() -> do_damage() -> die() die logisch bessere
+ und balancetechnisch guenstigere Loesung.
+
+SIEHE AUCH
+----------
+::
+
+ Todesursachen: Defend(L), do_damage(L), P_POISON
+ Verwandt: P_TMP_DIE_HOOK, P_DEADS
+ Todesmeldungen: P_KILL_NAME, P_KILL_MSG, P_MURDER_MSG, P_DIE_MSG
+ P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
+ Sonstiges: P_CORPSE, P_NOCORPSE, /std/corpse.c
+
+
+Last modified: Mon May 14 16:20:34 2001 by Patryn
+
diff --git a/doc/sphinx/lfun/doUnwearMessage.rst b/doc/sphinx/lfun/doUnwearMessage.rst
new file mode 100644
index 0000000..c587ab9
--- /dev/null
+++ b/doc/sphinx/lfun/doUnwearMessage.rst
@@ -0,0 +1,47 @@
+doUnwearMessage()
+=================
+
+FUNKTION
+--------
+::
+
+ void doUnwearMessage(object worn_by, int all);
+
+DEFINIERT IN
+------------
+::
+
+ /std/armour/combat.c
+
+ARGUMENTE
+---------
+::
+
+ worn_by
+ Das Lebewesen, dass die Ruestung bisher getragen hat
+ all
+ Wurde "ziehe alles aus"/"ziehe alle ruestungen aus" eingegeben,
+ so ist all gesetzt, ansonsten nicht.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion gibt beim Ausziehen einer Ruestung die entspr.
+ Meldung an den Traeger und die Umgebung aus.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ doWearMessage(), doWieldMessage(), doUnwieldMessage()
+
+
+Last modified: Sat Jun 26 15:41:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/doUnwieldMessage.rst b/doc/sphinx/lfun/doUnwieldMessage.rst
new file mode 100644
index 0000000..b69d61b
--- /dev/null
+++ b/doc/sphinx/lfun/doUnwieldMessage.rst
@@ -0,0 +1,44 @@
+doUnwieldMessage()
+==================
+
+FUNKTION
+--------
+::
+
+ void doUnwieldMessage(object wielded_by);
+
+DEFINIERT IN
+------------
+::
+
+ /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+ wielded_by
+ Das Lebewesen, dass die (Parier)Waffe bisher gezueckt hatte.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion gibt beim Wegstecken einer Waffe die entspr.
+ Meldung an den Benutzer und die Umgebung aus.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ doWearMessage(), doUnwearMessage(), doWieldMessage()
+
+
+Last modified: Sat Jun 26 15:32:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/doWearMessage.rst b/doc/sphinx/lfun/doWearMessage.rst
new file mode 100644
index 0000000..904d50d
--- /dev/null
+++ b/doc/sphinx/lfun/doWearMessage.rst
@@ -0,0 +1,45 @@
+doWearMessage()
+===============
+
+FUNKTION
+--------
+::
+
+ varargs void doWearMessage(int all);
+
+DEFINIERT IN
+------------
+::
+
+ /std/armour/combat.c
+
+ARGUMENTE
+---------
+::
+
+ all
+ Wurde "trage alles"/"trage alle ruestungen" eingegeben, so
+ ist all gesetzt, ansonsten nicht.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion gibt beim Anziehen einer Ruestung die entspr.
+ Meldung an den Traeger und die Umgebung aus.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ doUnwearMessage(), doWieldMessage(), doUnwieldMessage()
+
+
+Last modified: Sat Jun 26 15:30:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/doWieldMessage.rst b/doc/sphinx/lfun/doWieldMessage.rst
new file mode 100644
index 0000000..5040650
--- /dev/null
+++ b/doc/sphinx/lfun/doWieldMessage.rst
@@ -0,0 +1,43 @@
+doWieldMessage()
+================
+
+FUNKTION
+--------
+::
+
+ void doWieldMessage();
+
+DEFINIERT IN
+------------
+::
+
+ /std/weapon/combat.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion gibt beim Zuecken einer Waffe die entspr.
+ Meldung an den Benutzer und die Umgebung aus.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ doWearMessage(), doUnwearMessage(), doUnwieldMessage()
+
+
+Last modified: Sat Jun 26 15:33:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/do_damage.rst b/doc/sphinx/lfun/do_damage.rst
new file mode 100644
index 0000000..05bc2f5
--- /dev/null
+++ b/doc/sphinx/lfun/do_damage.rst
@@ -0,0 +1,70 @@
+do_damage()
+===========
+
+do_damage(L)
+
+FUNKTION
+--------
+::
+
+ int do_damage(int dam,mixed enemy);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ int dam
+ Die abzuziehenden Lebenspunkte (HP).
+ object enemy
+ Das Objekt, welches den Schaden zufuegt.
+
+BESCHREIBUNG
+------------
+::
+
+ Dem Lebewesen werden <dam> HP abgezogen. Falls weniger als 0 HP uebrig
+ bleiben, so stirbt es automatisch mittels die().
+ Ein Lebewesen, welches sich bewegt hat, trifft die ersten Kampfrunden
+ sehr viel schlechter, um Rein-Raus-Attacken zu verhindern. Dieses
+ Vorgehen kann man mittels P_ENABLE_IN_ATTACK_OUT deaktivieren.
+ Lebewesen, welche P_NO_ATTACK gesetzt haben, kann man mit dieser
+ Funktion nicht schaden.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Der tatsaechlich verursachte Schaden.
+
+BEMERKUNGEN
+-----------
+::
+
+ Beim Gegner <enemy>, falls vorhanden, werden XP und ALIGN entsprechend
+ angepasst, im Opfer wird der Gegner in P_KILLER vermerkt, der Kampf wird
+ beendet.
+ Diese Funktion sollte nur selten direkt verwendet werden. Meist ist der
+ uebliche Weg ueber Defend() -> do_damage() -> die() die logisch bessere
+ und balancetechnisch guenstigere Loesung, da Defend() magische
+ Verteidigungen, die der Spieler bei sich hat beruecksichtigt.
+ Es sollte also allein schon aus Fairness gegenueber den Objekten
+ anderer Magier Defend() immer dem direkten reduce_hit_points() oder
+ do_damage() vorgezogen werden. Mittels der Flags in 'spell' kann man
+ sehr viele Parameter beeinflussen.
+
+SIEHE AUCH
+----------
+::
+
+ Verwandt: Defend(L), reduce_hit_points(L), die(L)
+ Props: P_NO_ATTACK, P_ENABLE_IN_ATTACK_OUT, P_KILLER
+ P_XP, P_ALIGN
+
+23.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/do_frage.rst b/doc/sphinx/lfun/do_frage.rst
new file mode 100644
index 0000000..99b2cc9
--- /dev/null
+++ b/doc/sphinx/lfun/do_frage.rst
@@ -0,0 +1,42 @@
+do_frage()
+==========
+
+FUNKTION
+--------
+::
+
+ int do_frage(string text)
+
+DEFINIERT IN
+------------
+::
+
+ /std/npc/info.c
+
+ARGUMENTE
+---------
+::
+
+ string str - Schluesselwort der Frage
+
+BESCHREIBUNG
+------------
+::
+
+ Bearbeitet ein Schluesselwort, das mit "frage <wen> nach " uebergeben
+ wurde. Gibt entsprechende Antworten formatiert aus.
+
+BEMERKUNGEN
+-----------
+::
+
+ Recht komplex, besser nicht ueberschreiben wenn man es nicht versteht.
+
+SIEHE AUCH
+----------
+::
+
+ Verwandt: GetInfoArr, AddInfo
+
+31.Mar 2007 Gloinson
+
diff --git a/doc/sphinx/lfun/do_unwear.rst b/doc/sphinx/lfun/do_unwear.rst
new file mode 100644
index 0000000..291b085
--- /dev/null
+++ b/doc/sphinx/lfun/do_unwear.rst
@@ -0,0 +1,57 @@
+do_unwear()
+===========
+
+FUNKTION
+--------
+::
+
+ varargs int do_unwear(string str, int silent);
+
+DEFINIERT IN
+------------
+::
+
+ /std/armour/combat.c
+
+ARGUMENTE
+---------
+::
+
+ str
+ String der normalerweise dem Parameter des "ziehe"-Kommandos
+ entspricht.
+
+ silent
+ 1, wenn das Ausziehen ohne Meldungen durchgefuehrt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion stellt fest, ob die Ruestung sich durch str
+ identifizieren laesst und angezogen ist und ruft im Erfolgsfall
+ UnWear(silent) auf.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn alles gut ging, ansonsten 0.
+
+BEMERKUNGEN
+-----------
+::
+
+ Wenn man Ruestungen "von aussen" ausziehen will, sollte man direkt
+ UnWear() verwenden!
+
+SIEHE AUCH
+----------
+::
+
+ do_wear(), UnWear(), RemoveFunc(), InformUnwear(),
+ /std/armour/combat.c
+
+
+Last modified: Sun Jun 27 22:29:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/do_wear.rst b/doc/sphinx/lfun/do_wear.rst
new file mode 100644
index 0000000..32a1b3f
--- /dev/null
+++ b/doc/sphinx/lfun/do_wear.rst
@@ -0,0 +1,47 @@
+do_wear()
+=========
+
+FUNKTION
+--------
+::
+
+ varargs int do_wear(string str, int silent);
+
+DEFINIERT IN
+------------
+::
+
+ /std/armour/combat.c
+
+ARGUMENTE
+---------
+::
+
+ str
+ String, der normalerweise dem Parameter des
+ "ziehe/trage"-Kommandos entspricht.
+ silent
+ 1, wenn das Anziehen ohne Meldungen durchgefuehrt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Wenn sich die Ruestung mit "str" identifizieren laesst, wird versucht,
+ sie mittels DoWear() anzuziehen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn sich die Ruestung anziehen liess, sonst 0.
+
+SIEHE AUCH
+----------
+::
+
+ do_unwear(), DoWear(), WearFunc(), InformWear(), /std/armour/combat.c
+
+
+Last modified: Sun Jun 27 22:31:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/lfun/drink_alcohol.rst b/doc/sphinx/lfun/drink_alcohol.rst
new file mode 100644
index 0000000..f468cd3
--- /dev/null
+++ b/doc/sphinx/lfun/drink_alcohol.rst
@@ -0,0 +1,112 @@
+drink_alcohol()
+===============
+
+FUNKTION
+--------
+::
+
+ public varargs int drink_alcohol(int strength, int testonly, string mytext)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ strength: wird zur aktuellen Saettigung P_ALCOHOL dazu addiert
+ testonly: Ist das Flag gesetzt, wird dem Spieler kein ALCOHOL zugefuehrt.
+ Darf nur zum Testen der Heilstelle verwendet werden und muss
+ im normalen Betrieb auf '0' stehen!
+ mytext: Wer selber einen Text bei Misserfolg ausgeben lassen moechte,
+ darf sich hier was nettes ausdenken.
+ Achtung: Das unterdrueckt nicht die "Nuechtern"-Meldung, die bei
+ negativem strength auftreten kann, wenn P_ALCOHOL wieder 0 ist.
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird geprueft, ob dem Spieler der angegebene Wert fuer 'strength'
+ auf seine aktuelle P_ALCOHOL addiert werden kann oder nicht. Falls
+ das moeglich ist und testonly = 0, wird P_ALCOHOL entsprechend
+ aktualisiert.
+
+ Sollen neben P_ALCOHOL noch weitere Props manipuliert werden - bspw. zur
+ Heilung eines Lebewesens - bietet sich die Funktion consume() an.
+
+RUECKGABEWERT
+-------------
+::
+
+ 0 bei [potentiellem] Misserfolg (strength + P_ALCOHOL > P_MAX_ALCOHOL)
+ 1 bei [potentiellem] Erfolg
+ * potentiell bezieht sich hier auf Nutzung mit 'testonly' != 0
+
+BEMERKUNG
+---------
+::
+
+ drink_alocohol() bitte anstatt eigener Manipulationen von P_ALCOHOL und
+ P_MAX_ALCOHOL verwenden.
+
+ Achtung: Immer erst VOR einer Heilung ausfuehren und bei Erfolg heilen.
+
+ Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
+ dafuer eingerichteten Funktion check_and_update_timed_key realisiert
+ werden.
+
+BEISPIEL
+--------
+::
+
+ int heilstelle() {
+ if(this_player()->drink_alcohol(10, 0,
+ "Du prustest in den Schnaps. "
+ "Der passt nicht mehr rein.\n")) {
+ // Platz fuer 10 "Alkohol" war noch, diese sind jetzt bereits addiert
+ // Nachricht an den Spieler:
+ tell_object(this_player(),
+ break_string("Du trinkst den Schnaps aus.", 78));
+
+ // Nachricht an andere Livings im Raum
+ object ob = first_inventory(environment(this_player()));
+ do {
+ if(living(ob) && ob!=this_player())
+ ob->ReceiveMsg(this_player()->Name()+" trinkt einen Schnaps aus.",
+ MT_LOOK|MT_LISTEN,
+ MA_DRINK);
+ ob = next_inventory(ob);
+ } while(ob);
+
+ // Rassenabhaengige Heilung: Sofort oder in Schritten
+ // Tragbare Heilungen sollten auch eher buffer_hp/_sp benutzen.
+ if(this_player()->QueryProp(P_REAL_RACE)=="Schnapsdrossel")
+ this_player()->heal_self(30);
+ else {
+ this_player()->buffer_hp(30,5);
+ this_player()->buffer_sp(30,5);
+ }
+ }
+
+ return 1;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Aehnlich: consume, eat_food, drink_soft
+ Heilung: heal_self, restore_spell_points, restore_hit_points,
+ buffer_hp, buffer_sp
+ Timing: check_and_update_timed_key
+ Enttanken: defuel_drink, defuel_food
+ Props: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+ P_DEFUEL_TIME_DRINK
+ Konzepte: heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/drink_soft.rst b/doc/sphinx/lfun/drink_soft.rst
new file mode 100644
index 0000000..58c7d57
--- /dev/null
+++ b/doc/sphinx/lfun/drink_soft.rst
@@ -0,0 +1,111 @@
+drink_soft()
+============
+
+FUNKTION
+--------
+::
+
+ public varargs int drink_soft(int strength, int testonly, string mytext)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ strength: Wird zu dem augenblicklichen Saettigungsgrad (P_DRINK) addiert.
+ testonly: Ist das Flag gesetzt, wird dem Spieler kein DRINK zugefuehrt.
+ Darf nur zum Testen der Heilstelle verwendet werden und muss
+ im normalen Betrieb auf '0' stehen!
+ mytext: Wer selber einen Text bei Misserfolg ausgeben lassen moechte,
+ darf sich hier was nettes ausdenken.
+ Achtung: Das unterdrueckt nicht die "Durst"-Meldung, die bei
+ negativem strength auftritt, wenn P_DRINK wieder 0 ist.
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird geprueft, ob dem Spieler der angebene Wert "strength" auf
+ aktuelle P_DRINK addiert werden kann oder nicht. Ist dies moeglich,
+ wird es gemacht, es sei denn das testonly != 0.
+
+ Sollen neben P_DRINK noch weitere Props manipuliert werden - bspw. zur
+ Heilung eines Lebewesens - bietet sich die Funktion consume() an.
+
+RUECKGABEWERT
+-------------
+::
+
+ 0, wenn strength + P_DRINK > P_MAX_DRINK
+ >0, wenn Erfolg
+
+BEMERKUNG
+---------
+::
+
+ drink_soft() bitte anstatt eigener Manipulationen von P_DRINK und
+ P_MAX_DRINK verwenden.
+
+ Achtung: Immer erst VOR einer Heilung ausfuehren und bei Erfolg heilen.
+
+ Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
+ dafuer eingerichteten Funktion check_and_update_timed_key realisiert
+ werden.
+
+BEISPIEL
+--------
+::
+
+ int heilstelle() {
+ if(this_player()->drink_soft(10, 0, "Du blubberst nicht ueberzeugt "
+ "in der Limonade. Das ist zu viel.\n")) {
+ // Platz fuer 10 "Trinken" war noch, diese sind jetzt bereits addiert
+ // Nachricht an den Spieler:
+ tell_object(this_player(), break_string("Du nimmst einen grossen "
+ "Schluck zuckersuesse Limonade.", 78));
+
+ // alle anderen im Raum bekommen es ggf auch mit:
+ // 1) filter(..., #'living) ergibt die Lebewesen im Raum
+ // 2) filter_objects(..., "ReceiveMsg") ruft ReceiveMsg an jedem
+ // 3) ReceiveMsg(...) bekommt die Folgeparameter
+ filter_objects(filter(all_inventory(environment(this_player())),
+ #'living) - ({this_player()}),
+ "ReceiveMsg",
+ this_player()->Name()+
+ " trinkt einen Schluck Limonade.",
+ MT_LOOK|MT_LISTEN,
+ MA_DRINK);
+
+ // Rassenabhaengige Heilung: Sofort oder in Schritten
+ // Tragbare Heilungen sollten auch eher buffer_hp/_sp benutzen.
+ if(this_player()->QueryProp(P_REAL_RACE)=="Saufziege")
+ this_player()->heal_self(30);
+ else {
+ this_player()->buffer_hp(30,5);
+ this_player()->buffer_sp(30,5);
+ }
+ }
+
+ return 1;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Aehnlich: consume, drink_alcohol, eat_food
+ Heilung: heal_self, restore_spell_points, restore_hit_points,
+ buffer_hp, buffer_sp
+ Timing: check_and_update_timed_key
+ Enttanken: defuel_drink, defuel_food
+ Props: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+ P_DEFUEL_TIME_DRINK
+ Konzepte: heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/drop.rst b/doc/sphinx/lfun/drop.rst
new file mode 100644
index 0000000..36147c3
--- /dev/null
+++ b/doc/sphinx/lfun/drop.rst
@@ -0,0 +1,71 @@
+drop()
+======
+
+FUNKTION
+--------
+::
+
+ public varargs int drop(object o, mixed msg);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ object o
+ Das Objekt, das fallengelassen werden soll.
+ mixed msg
+ Eine optionale Meldung, die anstelle von P_DROP_MSG oder der
+ Standardmeldung verwendet wird, oder -1, um die Meldung zu
+ unterdruecken.
+
+BESCHREIBUNG
+------------
+::
+
+ Der Spieler oder NPC laesst das Objekt fallen. Gibt o->move() keinen
+ positiven Wert zurueck, beispielsweise weil das Objekt verflucht ist,
+ bekommt er eine entsprechende Fehlermeldung.
+
+RUECKGABEWERT
+-------------
+::
+
+ Wenn das Fallenlassen geklappt hat, 1, ansonsten 0.
+
+BEMERKUNG
+---------
+::
+
+ Diese Funktion ist dann sinnvoll, wenn man den Spieler ein Objekt
+ fallenlassen lassen und sich nicht selbst um die Fehlerbehandlung kuemmern
+ moechte - und da unzaehlige verschiedene Dinge schiefgehen koennen und
+ manche Objekte eigene Fehlermeldungen definieren, eigentlich immer.
+
+ Die Funktion prueft nicht, ob der Spieler/NPC das Objekt ueberhaupt hat,
+ das muss man ggf. selbst ermitteln.
+
+BEISPIEL
+--------
+::
+
+ if (this_player()->drop(obj, ({
+ "Du wirfst @WEN2 in den Saeureteich.\n",
+ "@WER1 wirft @WENU2 in den Saeureteich.\n" })))
+ obj->remove();
+
+SIEHE AUCH
+----------
+::
+
+ move(L), P_DROP_MSG, drop_objects(L), P_NOINSERT_MSG, P_NOLEAVE_MSG,
+ P_TOO_MANY_MSG, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NODROP
+
+
+Last modified: Thu Aug 28 22:20:37 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/drop_obj.rst b/doc/sphinx/lfun/drop_obj.rst
new file mode 100644
index 0000000..64b7274
--- /dev/null
+++ b/doc/sphinx/lfun/drop_obj.rst
@@ -0,0 +1,44 @@
+drop_obj()
+==========
+
+FUNKTION
+--------
+::
+
+ int drop_obj(object ob);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ ob Das Objekt, das von dem Lebewesen, in dem diese Funktion aufgerufen
+ wird, fallengelassen werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Das Lebewesen, in dem diese Funktion aufgerufen werden soll, laesst
+ den angegebenen Gegenstand fallen, wenn dies moeglich ist.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn das Objekt fallen gelassen wurde oder dies nicht moeglich war.
+ (in diesem Fall wird auch direkt eine Textausgabe ausgegeben)
+ 0 sonst, in diesem Fall wird in notify_fail eine passende Ausgabe
+ plaziert.
+
+SIEHE AUCH
+----------
+::
+
+ find_obs(), give_obj(), pick_obj(), put_obj(), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/lfun/drop_objects.rst b/doc/sphinx/lfun/drop_objects.rst
new file mode 100644
index 0000000..824b9bd
--- /dev/null
+++ b/doc/sphinx/lfun/drop_objects.rst
@@ -0,0 +1,74 @@
+drop_objects()
+==============
+
+FUNKTION
+--------
+::
+
+ public varargs int drop_objects(string str, mixed msg);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ string str
+ Was fallengelassen werden soll.
+ mixed msg
+ Eine optionale Meldung, die anstelle von P_DROP_MSG oder der
+ Standardmeldung verwendet wird, oder -1, um die Meldung zu
+ unterdruecken.
+
+BESCHREIBUNG
+------------
+::
+
+ Der Spieler oder NPC laesst die in <str> benannten Sachen fallen.
+ Kann er ein Objekt nicht fallenlassen, bekommt er eine entsprechende
+ Fehlermeldung. Wenn keine Objekte auf <str> passen, wird per
+ _notify_fail() eine Meldung gesetzt, aber noch nicht ausgegeben.
+
+RUECKGABEWERT
+-------------
+::
+
+ Wenn <str> irgendwelche vorhandenen Sachen sind, 1, sonst 0.
+
+BEMERKUNG
+---------
+::
+
+ Wenn die Funktion 1 zurueckgibt, heisst das noch nicht, dass der Spieler
+ etwas fallengelassen hat! Er hat es nur versucht, d.h. auf jeden Fall eine
+ Meldung bekommen. Gibt die Funktion 0 zurueck, hat er noch keine bekommen.
+
+BEISPIEL
+--------
+::
+
+ private int cmd_opfern(string str)
+ {
+ notify_fail("WAS moechtest Du opfern?\n");
+
+ if (!this_player()->drop_objects(str, ({ "Du opferst @WEN2.",
+ "@WER1 opfert @WENU2.\n" })))
+ return 0;
+
+ filter_objects(this_player()->moved_objects(), "remove");
+ return 1;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ move(L), drop(L), P_DROP_MSG, find_objects(L), moved_objects(L)
+
+
+Last modified: Fri Jul 25 10:59:37 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/eat_food.rst b/doc/sphinx/lfun/eat_food.rst
new file mode 100644
index 0000000..1b967ef
--- /dev/null
+++ b/doc/sphinx/lfun/eat_food.rst
@@ -0,0 +1,114 @@
+eat_food()
+==========
+
+FUNKTION
+--------
+::
+
+ public varargs int eat_food(int food, int testonly, string mytext)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ food: Wird zu dem augenblicklichen Saettigungsgrad (P_FOOD) addiert.
+ testonly: Ist das Flag gesetzt, wird dem Spieler kein FOOD zugefuehrt.
+ Darf nur zum Testen der Heilstelle verwendet werden und muss
+ im normalen Betrieb auf '0' stehen!
+ mytext: Wer selber einen Text bei Misserfolg ausgeben lassen moechte,
+ darf sich hier was nettes ausdenken.
+ Achtung: Das unterdrueckt nicht die "Hunger"-Meldung, die bei
+ negativem food auftreten kann, wenn P_FOOD wieder 0 ist.
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird geprueft, ob dem Spieler der angebene Wert "strength" auf seine
+ aktuelle P_FOOD addiert werden kann oder nicht. Ist dies moeglich, wird
+ wird es gemacht, es sei denn das testonly != 0.
+
+ Sollen neben P_FOOD noch weitere Props manipuliert werden - bspw. zur
+ Heilung eines Lebewesens - bietet sich die Funktion consume() an.
+
+RUECKGABEWERT
+-------------
+::
+
+ 0, wenn strength + P_FOOD > P_MAX_FOOD.
+ >0, wenn Erfolg.
+
+BEMERKUNG
+---------
+::
+
+ eat_food() bitte anstatt eigener Manipulationen von P_FOOD und
+ P_MAX_FOOD verwenden.
+
+ Achtung: Immer erst VOR einer Heilung ausfuehren und bei Erfolg heilen.
+
+ Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
+ dafuer eingerichteten Funktion check_and_update_timed_key realisiert
+ werden.
+
+BEISPIEL
+--------
+::
+
+ int heilstelle() {
+ // Wenn auf das P_FOOD des Spielers die angegebenen 10 nicht mehr addiert
+ // addiert werden koennen (weil sonst P_MAX_FOOD ueberschritten wird),
+ // wird die Fehlermeldung ausgegeben, dass der Spieler nichts mehr
+ // essen/trinken kann.
+ // Bei gesetztem 'mytext' wird 'mytext' an den Spieler ausgegeben.
+ // Ansonsten wird die Standardmeldung ausgegeben.
+ if (!this_player()->eat_food(10, 0, "Der Keks ist einfach "
+ "zuviel fuer Dich.\n") )
+ return 1;
+
+ // Spieler hatte noch ausreichend Spielraum bei P_FOOD. Die 10 sind
+ // schon addiert worden. Jetzt Nachricht ausgeben:
+ tell_object(this_player(), break_string("Du knabberst ein bisschen an "
+ "dem Keks herum und fuehlst Dich gleich viel besser.", 78));
+
+ // alle Lebewesen im Raum bekommen das auch mit
+ foreach(object ob:
+ (filter(all_inventory(environment(this_player())), #'living) -
+ ({this_player()})))
+ ob->ReceiveMsg(this_player()->Name()+" knuspert einen Keks weg.",
+ MT_LOOK|MT_LISTEN,
+ MA_EAT);
+
+ // Rassenabhaengige Heilung: Sofort oder in Schritten
+ // Tragbare Heilungen sollten auch eher buffer_hp/_sp benutzen.
+ if(this_player()->QueryProp(P_REAL_RACE)=="Kruemelmonster")
+ this_player()->heal_self(30);
+ else {
+ this_player()->buffer_hp(30,5);
+ this_player()->buffer_sp(30,5);
+ }
+
+ return 1;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Aehnlich: consume, drink_alcohol, drink_soft
+ Heilung: heal_self, restore_spell_points, restore_hit_points,
+ buffer_hp, buffer_sp
+ Timing: check_and_update_timed_key
+ Enttanken: defuel_drink, defuel_food
+ Props: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+ P_DEFUEL_TIME_DRINK
+ Konzepte: heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/execute_anything.rst b/doc/sphinx/lfun/execute_anything.rst
new file mode 100644
index 0000000..4703299
--- /dev/null
+++ b/doc/sphinx/lfun/execute_anything.rst
@@ -0,0 +1,64 @@
+execute_anything()
+==================
+
+FUNKTION
+--------
+::
+
+ protected mixed execute_anything(mixed fun, mixed args, ...)
+
+DEFINIERT IN
+------------
+::
+
+ /std/util/executer.c
+
+ARGUMENTE
+---------
+::
+
+ mixed fun auszufuehrende Funktion/Array/Closure ... anything
+ mixed args weitere Argumente, werden weiter uebergeben
+
+BESCHREIBUNG
+------------
+::
+
+ Fuehrt "alles" aus:
+
+
+
+ 'fun' kann sein:
+ - eine Closure
+ [funcall(fun, args, ...)]
+ - einen String als Funktion im Objekt
+ [call_other(this_object(), fun, args, ...)]
+ - ein Array mit Objekt/Objektnamen + Funktion als Aufruf der Funktion am
+ Objekt/Objektnamen:
+ [call_other(array[0], array[1], args...)]
+
+ Wird execute_anything() aus dem restriction_checker gerufen, wird als
+ erster Parameter immer das gepruefte Living uebergeben.
+
+BEMERKUNGEN
+-----------
+::
+
+ Es kann sich anbieten, die gerufene Funktion mit varargs-Argumenten zu
+ gestalten, damit ihr mehr Argumente uebergeben werden koennen als in der
+ Funktionsdefinition angegeben sind.
+
+ Der Restriktionspruefer (/std/restriction_checker) versteht im Falle eines
+ Arrays mit Objekt/Objektnamen + Funktion auch ein Array mit mehr als 2
+ Elementen. Die weiteren Elemente werden dann zu weiteren Argumenten der
+ gerufenen Funktion. Hierbei wird <pl> ggf. aber als erstes Argument vor
+ alle anderen eingefuegt.
+
+SIEHE AUCH
+----------
+::
+
+ check_restrictions, varargs
+
+31.12.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/exit.rst b/doc/sphinx/lfun/exit.rst
new file mode 100644
index 0000000..c6cf08e
--- /dev/null
+++ b/doc/sphinx/lfun/exit.rst
@@ -0,0 +1,56 @@
+exit()
+======
+
+FUNKTION
+--------
+::
+
+ varargs void exit(object liv, object dest);
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/description.c
+
+ARGUMENTE
+---------
+::
+
+ liv - (object) Das bewegte Lebewesen.
+ dest - (object) Das Environment, in welches bewegt wird.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird immer dann aufgerufen, wenn ein Lebewesen den
+ Raum verlaesst. Standardmaessig werden hier ggf. die Raummeldungen
+ abgestellt, man kann aber auch eigene Checks einhaengen. In dem Fall MUSS
+ man aber das geerbte exit() auf jeden Fall aufrufen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNG
+---------
+::
+
+ Man beachte, dass this_player() 0 sein kann, wenn z.B. ein netztoter Spieler
+ Spieler den Raum verlaesst.
+ Man beachte ausserdem, dass this_player() nicht unbedingt das bewegte Living
+ sein muss. Wenn z.B. jemand ein Lebewesen bewegt, ist TP der, der die
+ Bewegung durchfuehrt, nicht das Lebewesen.
+
+SIEHE AUCH
+----------
+::
+
+ init(), this_player(), previous_object(), caller_stack(),
+ NotfiyLeave(), NotifyRemove(), NotifyDestruct()
+
+Last modified: 25.02.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/find_obs.rst b/doc/sphinx/lfun/find_obs.rst
new file mode 100644
index 0000000..c0cc707
--- /dev/null
+++ b/doc/sphinx/lfun/find_obs.rst
@@ -0,0 +1,57 @@
+find_obs()
+==========
+
+FUNKTION
+--------
+::
+
+ object* find_obs(string str, int meth)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ str Der String der geparsed werden soll.
+ meth Mit Hilfe dieses Parameters koennen bestimmte Bereichs-
+ eingrenzungen vorgenommen werden (definiert in moving.h):
+
+ PUT_GET_NONE - keinerlei Bereichseingrenzung.
+ PUT_GET_TAKE - es handelt sich um ein Nehmen von Gegenstaenden
+ also wird das inventory ausgenommen.
+ PUT_GET_DROP - es handelt sich um das Entfernen von Gegenstaenden
+ also wird das environment ausgenommen.
+
+
+
+BESCHREIBUNG
+---------------------------------------------------------------------------
+::
+
+
+
+ Der String (str) muss folgendes Format haben damit Objekte gefunden
+ werden.
+
+ <gegenstand> [aus container] [in mir|im raum]
+
+ <gegenstand> kann hierbei sowohl eine Objekt-ID als auch ein
+ Gruppenbezeichner wie z.b. "alles" sein.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ein Array mit allen Objekten die sich angesprochen fuehlen, oder aber 0.
+
+SIEHE AUCH
+----------
+::
+
+ drop_obj(), give_obj(), pick_obj(), put_obj(), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/lfun/get_killing_player.rst b/doc/sphinx/lfun/get_killing_player.rst
new file mode 100644
index 0000000..e75f571
--- /dev/null
+++ b/doc/sphinx/lfun/get_killing_player.rst
@@ -0,0 +1,61 @@
+get_killing_player()
+====================
+
+FUNKTION
+--------
+::
+
+ protected object get_killing_player()
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Liefert im Tod (nach dem toetenden do_damage()) das Spielerobjekt, was
+ den Tod wohl zu verantworten hat, falls es ermittelt werden kann. Es
+ werden registrierte Helfer-NPC und einige schadenverursachende Objekte
+ beruecksichtigt. Hierbei wird QueryUser() in den Objekten abgefragt.
+
+ Es benoetigt ein gueltiges P_KILLER, d.h. falls das Lebewesen vergiftet
+ wurde oder das toetende Objekt aus sonstigen Gruenden nicht in P_KILLER
+ steht, funktioniert es nicht.
+ Auch gibt es bestimmt Objekte, die fuer Spieler toeten koennen, die die
+ diese Funktion nicht kennt.
+ (Dies gilt beides ebenso fuer /p/service/mupfel/getkill.c, ist also kein
+ Grund, jenes statt dieser Funktion zu nutzen.)
+
+RUeCKGABEWERT
+-------------
+::
+
+ Das Objekt des Spielers, falls es ermittelt werden konnte, sonst 0.
+
+BEMERKUNGEN
+-----------
+::
+
+ Der Name des Spieler ist mittel Name() ermittelbar. Will man die Info,
+ womit ein Spieler den Kill ggf. gemacht hat, kann man P_KILLER
+ auswerten/nutzen.
+
+SIEHE AUCH
+----------
+::
+
+ QueryUser
+ P_KILLER
+
+11.11.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/gilde/AddSkill.rst b/doc/sphinx/lfun/gilde/AddSkill.rst
new file mode 100644
index 0000000..4e79df3
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/AddSkill.rst
@@ -0,0 +1,57 @@
+AddSkill()
+==========
+
+FUNKTION
+--------
+::
+
+ varargs int AddSkill(string sname, mapping ski)
+
+DEFINIERT IN
+------------
+::
+
+ /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+ string sname Name des Skills
+ mapping ski Skill-Mapping
+
+BESCHREIBUNG
+------------
+::
+
+ Fuegt den Skill zur Liste der in dieser Gilde lernbaren Skills
+ hinzu. Das Mapping enthaelt Informationen, die der Gildenraum
+ bzw. das Gildenobjekt zum Skill herausgeben und die das Lernen
+ des Skills beeinflussen.
+
+RUECKGABWERT
+------------
+::
+
+ 1 fuer Erfolg
+
+BEISPIEL
+--------
+::
+
+ AddSkill( FIGHT(WT_CLUB), ([ OFFSET(SI_SKILLLEARN) : 1 ]) );
+
+SIEHE AUCH
+----------
+::
+
+ GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
+ * Anzeigen: SkillListe
+ * Verwalten: AddSpell (gilde), QuerySpell, QuerySkill
+ * Nutzen: UseSpell (gilde)
+ * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+ Gildenfkt.: GuildRating
+ * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/AddSpell.rst b/doc/sphinx/lfun/gilde/AddSpell.rst
new file mode 100644
index 0000000..c2daac9
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/AddSpell.rst
@@ -0,0 +1,74 @@
+AddSpell()
+==========
+
+FUNKTION
+--------
+::
+
+ varargs int AddSpell(string verb, mapping ski)
+
+DEFINIERT IN
+------------
+::
+
+ /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+ string verb Name des Spells
+ mapping ski Skill-Mapping
+
+BESCHREIBUNG
+------------
+::
+
+ Fuegt den Spell zur Liste der in dieser Gilde lernbaren Spells
+ hinzu. Das Mapping enthaelt Informationen, die der Gildenraum
+ bzw. das Gildenobjekt zum Spell herausgeben und die das Lernen
+ des Spells beeinflussen.
+
+RUECKGABWERT
+------------
+::
+
+ 1 fuer Erfolg
+
+BEMERKUNGEN
+-----------
+::
+
+ Siehe das Verhalten von QuerySpell (gilde) zum Zusammenfuegen
+ der AddSpell-Informationen aus Gilde und Spellbook. Relevant
+ zB fuer Lernrestriktionen.
+
+BEISPIEL
+--------
+::
+
+ AddSpell("entfluche",
+ ([SI_SKILLRESTR_LEARN :
+ ([P_GUILD_LEVEL: LVL_WANDER,
+ SR_FUN: #'glaubensTest]),
+ SI_DIFFICULTY: 100,
+ SI_SKILLINFO: "Wanderprediger ab Stufe 7",
+ SI_SKILLINFO_LONG: break_string(
+ "Um jemanden von einem laestigen Sprachfluch zu befreien, "
+ "sollte man diese Anrufung benutzen [...]", 78),
+ SI_GOD: LEMBOLD]));
+
+SIEHE AUCH
+----------
+::
+
+ GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
+ * Anzeigen: SkillListe
+ * Verwalten: AddSkill, QuerySpell, QuerySkill, QuerySkill
+ * Nutzen: UseSpell (gilde)
+ * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+ Gildenfkt.: GuildRating
+ * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/GuildRating.rst b/doc/sphinx/lfun/gilde/GuildRating.rst
new file mode 100644
index 0000000..1dbe8f6
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/GuildRating.rst
@@ -0,0 +1,47 @@
+GuildRating()
+=============
+
+FUNKTION
+--------
+::
+
+ int GuildRating(object pl)
+
+DEFINIERT IN
+------------
+::
+
+ /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+ object pl Spieler, der geratet werden soll
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt das Guild-Rating des Spielers im Bereich 0-MAX_ABILITY zurueck
+ und schreibt sie in P_GUILD_RATING. Wichtig fuer Levelbestimmung!
+
+
+
+ Normalerweise ist das der Mittelwert der Skill-Abilities aller Skills
+ und Spells, das Verhalten kann aber ueberschrieben werden.
+
+SIEHE AUCH
+----------
+::
+
+ GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
+ * Anzeigen: SkillListe
+ * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+ * Nutzen: UseSpell (gilde)
+ * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS, P_GUILD_RATING
+ Gildenfkt.:
+ * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+10. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/InitialSkillAbility.rst b/doc/sphinx/lfun/gilde/InitialSkillAbility.rst
new file mode 100644
index 0000000..a239ca5
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/InitialSkillAbility.rst
@@ -0,0 +1,52 @@
+InitialSkillAbility()
+=====================
+
+FUNKTION
+--------
+::
+
+ static int InitialSkillAbility(mapping ski, object pl)
+
+DEFINIERT IN
+------------
+::
+
+ /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+ mapping ski Der zu lernende Skill
+ object pl Spieler
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt den initialen Ability-Wert fuer einen neu zu lernenden Skill (Spell)
+ zurueck. Die Standardformel benutzt nur Intelligenz und SI_SKILLLEARN und
+ kann in der Gilde ueberschrieben werden.
+
+BEMERKUNGEN
+-----------
+::
+
+ Der zurueckgegebene Wert wird noch in das Spieler-Skillsystem eingegeben
+ und daher kann der real gelernte Wert abweichen
+
+SIEHE AUCH
+----------
+::
+
+ Skills: LimitAbility, ModifySkill
+ GObj Lernen: LearnSkill, LearnSpell
+ * Anzeigen: SkillListe
+ * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+ * Nutzen: UseSpell (gilde)
+ * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+ Gildenfkt.: GuildRating
+ * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/LearnSkill.rst b/doc/sphinx/lfun/gilde/LearnSkill.rst
new file mode 100644
index 0000000..cba0d5f
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/LearnSkill.rst
@@ -0,0 +1,59 @@
+LearnSkill()
+============
+
+FUNKTION
+--------
+::
+
+ int LearnSkill(string skill)
+
+DEFINIERT IN
+------------
+::
+
+ /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+ string skill Der zu lernende Skill
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion ueberprueft den Spieler auf Gildenzugehoerigkeit
+ und ruft, falls kein 'skill' angegeben ist die SkillListe()
+ fuer Skills auf.
+
+ Falls ein Argument angegeben wird, wird bei dem Spieler dieser Skill
+ initialisiert, sofern er die notwendigen Anforderungen erfuellt hat.
+
+RUECKGABEWERT
+-------------
+::
+
+ 0 bei Fehler, 1 bei Erfolg.
+
+BEMERKUNGEN
+-----------
+::
+
+ Fuer die Lebewesen-Skills gibt es eine gleichnamige Funktion.
+ Siehe dafuer LearnSkill.
+
+SIEHE AUCH
+----------
+::
+
+ GObj Lernen: LearnSpell, InitialSkillAbility
+ * Anzeigen: SkillListe
+ * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+ * Nutzen: UseSpell (gilde)
+ * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+ Gildenfkt.: GuildRating
+ * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/LearnSpell.rst b/doc/sphinx/lfun/gilde/LearnSpell.rst
new file mode 100644
index 0000000..f09f0cf
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/LearnSpell.rst
@@ -0,0 +1,53 @@
+LearnSpell()
+============
+
+FUNKTION
+--------
+::
+
+ varargs int LearnSpell(string spell, object pl)
+
+DEFINIERT IN
+------------
+::
+
+ /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+ string spell Der zu lernende Spell
+ object pl lernender Spieler, wenn 0, wird this_player() genommen
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion ueberprueft den Spieler auf Gildenzugehoerigkeit
+ und ruft, falls kein 'spell' angegeben ist die SkillListe()
+ fuer Spells auf.
+
+ Falls ein Argument angegeben wird, wird bei dem Spieler dieser Spell
+ initialisiert, sofern er die notwendigen Anforderungen erfuellt hat.
+
+RUECKGABEWERT
+-------------
+::
+
+ 0 bei Fehler, 1 bei Erfolg.
+
+SIEHE AUCH
+----------
+::
+
+ GObj Lernen: LearnSkill, InitialSkillAbility
+ * Anzeigen: SkillListe
+ * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+ * Nutzen: UseSpell (gilde)
+ * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+ Gildenfkt.: GuildRating
+ * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/QuerySkill.rst b/doc/sphinx/lfun/gilde/QuerySkill.rst
new file mode 100644
index 0000000..d4be7c8
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/QuerySkill.rst
@@ -0,0 +1,54 @@
+QuerySkill()
+============
+
+FUNKTION
+--------
+::
+
+ mapping QuerySkill(string skill)
+
+DEFINIERT IN
+------------
+::
+
+ /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+ string skill Name des Skills
+
+BESCHREIBUNG
+------------
+::
+
+ Liefert fuer diesen Skill die Gildeninformationen in einem
+ Mapping zurueck.
+
+BEISPIEL
+--------
+::
+
+ // /gilden/klerus->QuerySkill(FIGHT(WT_CLUB)) gibt zB zurueck:
+ ([SI_FUN: "Fight_club",
+ OFFSET(SI_SKILLLEARN): 1
+ SI_SKILLRESTR_USE: ([SR_FUN:#'gilden/klerus->spellTest()]),
+ OFFSET(SI_SKILLLEARN): #'gilden/klerus->learnOffset,
+ OFFSET(SI_SPELLCOST): #'gilden/klerus->costOffset,
+ FACTOR(SI_SPELLCOST): #'gilden/klerus->costFactor])
+
+SIEHE AUCH
+----------
+::
+
+ GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
+ * Anzeigen: SkillListe
+ * Verwalten: AddSkill, AddSpell, QuerySpell
+ * Nutzen: UseSpell (gilde)
+ * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+ Gildenfkt.: GuildRating
+ * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/QuerySpell.rst b/doc/sphinx/lfun/gilde/QuerySpell.rst
new file mode 100644
index 0000000..b460f03
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/QuerySpell.rst
@@ -0,0 +1,75 @@
+QuerySpell()
+============
+
+FUNKTION
+--------
+::
+
+ mapping QuerySpell(string spell)
+
+DEFINIERT IN
+------------
+::
+
+ /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+ string spell Name des Spells
+
+BESCHREIBUNG
+------------
+::
+
+ Liefert fuer diesen Spell die Gilden- und Spellbookinformationen
+ zusammengefasst in ein Mapping zurueck.
+ Die Gildeninformationen haben dabei Vorrang (d.h. eine Lernrestriktion
+ im Spellbook wird benutzt, bei unterschiedlichen Werten fuer das gleiche
+ Attribut geht der Wert in der Gilde vor).
+
+BEISPIEL
+--------
+::
+
+ // /gilden/klerus->QuerySpell("entfluche") gibt zB zurueck:
+ ([SI_SPELLFATIGUE: 2,
+ SI_SP_LOW_MSG: "Deine Konzentration reicht nicht aus, das Interesse "
+ "der Goetter zu "wecken.\n",
+ SI_TIME_MSG: "So schnell koennen sich die Goetter nicht wieder um "
+ "Dich kuemmern!\n",
+ SI_SKILLLEARN: 5,
+ OFFSET(SI_SKILLLEARN):15
+ SI_SKILLRESTR_LEARN:
+ ([P_LEVEL: 7,
+ P_GUILD_LEVEL: LVL_WANDER,
+ SR_FUN: #'gilden/klerus->glaubensTest]),
+ SI_DIFFICULTY: 100,
+ SI_SKILLINFO: "Wanderprediger ab Stufe 7",
+ SI_SKILLINFO_LONG:
+ "Um jemanden von einem laestigen Sprachfluch zu befreien, "
+ "sollte man diese Anrufung benutzen [...]",
+ SP_NAME: "entfluche",
+ SI_SKILLRESTR_USE: ([ SR_FREE_HANDS : 0 ]),
+ SI_MAGIC_TYPE: ({MT_SAKRAL})
+ SI_GOD: LEMBOLD,
+ SI_SKILLRESTR_USE: ([SR_FUN:#'gilden/klerus->spellTest()]),
+ OFFSET(SI_SKILLLEARN): #'gilden/klerus->learnOffset,
+ OFFSET(SI_SPELLCOST): #'gilden/klerus->costOffset,
+ FACTOR(SI_SPELLCOST): #'gilden/klerus->costFactor])
+
+SIEHE AUCH
+----------
+::
+
+ GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
+ * Anzeigen: SkillListe
+ * Verwalten: AddSkill, AddSpell, QuerySkill
+ * Nutzen: UseSpell (gilde)
+ * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+ Gildenfkt.: GuildRating
+ * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/SkillListe.rst b/doc/sphinx/lfun/gilde/SkillListe.rst
new file mode 100644
index 0000000..6017650
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/SkillListe.rst
@@ -0,0 +1,49 @@
+SkillListe()
+============
+
+FUNKTION
+--------
+::
+
+ int SkillListe(int what)
+
+DEFINIERT IN
+------------
+::
+
+ /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+ int what Rueckgabeoption:
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt eine Text mit Liste mit lernbaren Skills/Spells zurueck:
+
+
+
+ Fuer 'what': 0 - alle; 1 - Spells; 2 - Skills.
+
+
+
+ Zeigt Eintraege aus SI_SKILLINFO.
+
+SIEHE AUCH
+----------
+::
+
+ GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
+ * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+ * Nutzen: UseSpell (gilde)
+ * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+ Gildenfkt.: GuildRating
+ * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+ Skills: skill_info_liste
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/UseSpell.rst b/doc/sphinx/lfun/gilde/UseSpell.rst
new file mode 100644
index 0000000..9cea450
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/UseSpell.rst
@@ -0,0 +1,53 @@
+UseSpell()
+==========
+
+FUNKTION
+--------
+::
+
+ varargs int UseSpell(object caster, string spell, mapping sinfo)
+
+DEFINIERT IN
+------------
+::
+
+ /std/gilden_ob.c
+
+ARGUMENTE
+---------
+::
+
+ object caster Spieler, der Spell nutzt
+ string spell Spell-Name
+ mapping sinfo Spell-Informationen
+
+BESCHREIBUNG
+------------
+::
+
+ Prueft, ob der Spell in der Gilde definiert ist und ruft ihn dann
+ ggf in aus dem Spell-Mapping gelesenen Gilden-SI_SPELLBOOK auf.
+
+ Wird von living/skills::UseSpell gerufen, wenn dieses die SI_CLOSURE,
+ also die Funktion eines Spells sucht, fuer den kein SI_SPELLBOOK
+ explizit angegeben wurde.
+
+RUECKGABWERT
+------------
+::
+
+ Rueckgabewert des Spells aus dem Spellbook oder 0.
+
+SIEHE AUCH
+----------
+::
+
+ GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
+ * Anzeigen: SkillListe
+ * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+ * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+ Gildenfkt.: GuildRating
+ * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/austreten.rst b/doc/sphinx/lfun/gilde/austreten.rst
new file mode 100644
index 0000000..6856558
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/austreten.rst
@@ -0,0 +1,52 @@
+austreten()
+===========
+
+FUNKTION
+--------
+::
+
+ varargs int austreten(int loss)
+
+ARGUMENTE
+---------
+::
+
+ int loss Prozentsatz, um den sich die Gildenskills verschlechtern
+
+DEFINIERT IN
+------------
+::
+
+ /std/gilden_ob.c
+
+BESCHREIBUNG
+------------
+::
+
+ Austrittsfunktion der Gilde. Prueft die Restriktionen der Gilde und
+ laesst this_player() ggf austreten. Das Austreten aus der Standard-
+ gilde ist dabei nicht moeglich.
+
+ Der Gildenmaster loest ggf ein EVT_GUILD_CHANGE aus. Dabei werden
+ E_OBJECT, E_GUILDNAME, E_LAST_GUILDNAME entsprechend gesetzt.
+
+ Der Gildenmaster senkt auch die Skill/Spell-Faehigkeiten um 'loss' bzw.
+ normalerweise mindestens 20%.
+
+ Durch Ueberschreiben koennen hier zB Abschiedsmeldungen gesendet werden.
+
+SIEHE AUCH
+----------
+::
+
+ GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
+ * Anzeigen: SkillListe
+ * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+ * Nutzen: UseSpell (gilde)
+ * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+ Gildenfkt.:
+ * Ein/Austritt: beitreten, bei_oder_aus_treten
+ * Props dafuer: P_GUILD_RESTRICTIONS
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/bei_oder_aus_treten.rst b/doc/sphinx/lfun/gilde/bei_oder_aus_treten.rst
new file mode 100644
index 0000000..504884c
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/bei_oder_aus_treten.rst
@@ -0,0 +1,43 @@
+bei_oder_aus_treten()
+=====================
+
+FUNKTION
+--------
+::
+
+ int bei_oder_aus_treten(string str)
+
+ARGUMENTE
+---------
+::
+
+ string str Spielerparameter
+
+DEFINIERT IN
+------------
+::
+
+ /std/gilden_ob.c
+
+BESCHREIBUNG
+------------
+::
+
+ Aus- oder Eintrittsfunktion, ruft beitreten() bzw. austreten() auf.
+ Wird im Std-Gildenraum per AddCmd zur Verfuegung gestellt.
+
+SIEHE AUCH
+----------
+::
+
+ GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
+ * Anzeigen: SkillListe
+ * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
+ * Nutzen: UseSpell (gilde)
+ * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+ Gildenfkt.:
+ * Ein/Austritt: beitreten, austreten
+ * Props dafuer: P_GUILD_RESTRICTIONS
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/gilde/beitreten.rst b/doc/sphinx/lfun/gilde/beitreten.rst
new file mode 100644
index 0000000..fe269cb
--- /dev/null
+++ b/doc/sphinx/lfun/gilde/beitreten.rst
@@ -0,0 +1,43 @@
+beitreten()
+===========
+
+FUNKTION
+--------
+::
+
+ int beitreten()
+
+DEFINIERT IN
+------------
+::
+
+ /std/gilden_ob.c
+
+BESCHREIBUNG
+------------
+::
+
+ Beitrittsfunktion der Gilde. Prueft die Gilde selbst im Gildenmaster,
+ dann die Restriktionen der Gilde und laesst this_player() ggf eintreten.
+
+ Der Gildenmaster loest ggf ein EVT_GUILD_CHANGE aus. Dabei werden
+ E_OBJECT, E_GUILDNAME, E_LAST_GUILDNAME entsprechend gesetzt.
+
+ Durch Ueberschreiben koennen hier zB Standard-Skills und Spells den
+ Spieler bei Eintritt gelehrt werden.
+
+SIEHE AUCH
+----------
+::
+
+ GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
+ * Anzeigen: SkillListe
+ * Verwalten: AddSpell (gilde), AddSkill, QuerySpell
+ * Nutzen: UseSpell (gilde)
+ * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
+ Gildenfkt.:
+ * Ein/Austritt: bei_oder_aus_treten, austreten
+ * Props dafuer: P_GUILD_RESTRICTIONS
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/give.rst b/doc/sphinx/lfun/give.rst
new file mode 100644
index 0000000..ef88c8a
--- /dev/null
+++ b/doc/sphinx/lfun/give.rst
@@ -0,0 +1,66 @@
+give()
+======
+
+FUNKTION
+--------
+::
+
+ public varargs int give(object o, object dest, mixed msg);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ object o
+ Das Objekt, das uebergeben werden soll.
+ object dest
+ Der Spieler oder NPC, der das Objekt bekommen soll.
+ mixed msg
+ Eine optionale Meldung, die anstelle von P_GIVE_MSG oder der
+ Standardmeldung verwendet wird, oder -1, um die Meldung zu
+ unterdruecken.
+
+BESCHREIBUNG
+------------
+::
+
+ Der Spieler oder NPC uebergibt dem Empfaenger das Objekt. Gibt o->move()
+ keinen positiven Wert zurueck, beispielsweise weil das Objekt verflucht
+ ist oder der Empfaenger es nicht mehr tragen kann, bekommt er eine
+ entsprechende Fehlermeldung.
+
+RUECKGABEWERT
+-------------
+::
+
+ Wenn die Uebergabe geklappt hat, 1, ansonsten 0.
+
+BEMERKUNG
+---------
+::
+
+ Diese Funktion ist dann sinnvoll, wenn man den Spieler ein Objekt
+ weitergeben lassen und sich nicht selbst um die Fehlerbehandlung kuemmern
+ moechte - und da unzaehlige verschiedene Dinge schiefgehen koennen und
+ manche Objekte eigene Fehlermeldungen definieren, eigentlich immer.
+
+ Die Funktion prueft nicht, ob der Spieler/NPC der Objekt ueberhaupt hat,
+ das muss man ggf. selbst ermitteln.
+
+SIEHE AUCH
+----------
+::
+
+ move(L), P_GIVE_MSG, give_objects(L), give_notify(L),
+ P_NOINSERT_MSG, P_NOLEAVE_MSG, P_TOO_MANY_MSG,
+ P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NODROP
+
+
+Last modified: Thu Aug 28 22:21:19 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/give_notify.rst b/doc/sphinx/lfun/give_notify.rst
new file mode 100644
index 0000000..2a56be3
--- /dev/null
+++ b/doc/sphinx/lfun/give_notify.rst
@@ -0,0 +1,87 @@
+give_notify()
+=============
+
+FUNKTION
+--------
+::
+
+ void give_notify(object obj);
+
+DEFINIERT IN
+------------
+::
+
+ /std/npc/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ obj
+ an den NPC uebergebenes Objekt
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird automatisch immer dann aufgerufen, wenn ein
+ Lebewesen (welches kein Spielercharakter ist) ein Objekt uebergeben
+ bekommt. Dies muss jedoch ueber die Funktionalitaet von
+ put_and_get.c geschehen sein, innerhalb von move() wird die Funktion
+ nicht aufgerufen!
+
+BEISPIEL
+--------
+::
+
+ Oftmals will man in Quests erreichen, dass einem NPC ein bestimmtes
+ Item als Beweis der Erfuellung einer bestimmten Aufgabe ueberbracht
+ wird. Folgendermasse kann dies realisiert werden:
+ void create() {
+ ::create();
+ ...
+ SetProp(P_REJECT,({REJECT_GIVE,
+ Name(WER)+" sagt: Das brauche ich nicht!\n"}));
+ ...
+ }
+
+ void quest_ok(object obj) { ...
+ // Vernichtung des Questobjektes und Questtexte
+ // Questbelohnung und Questanerkennung
+ }
+
+ void give_notify(object obj) {
+ if(obj->id("\nquestitem")) // Questitem bekommen?
+ quest_ok(obj);
+ else
+ ::give_notify(obj); // P_REJECT soll sonst greifen
+ }
+ Der Aufruf von ::give_notify() stellt sicher, dass ein Objekt
+ zurueckgegeben wird, sofern es nicht das gesuchte ist. Erreicht wird
+ dies ueber P_REJECT (siehe Bemerkungen).
+
+BEMERKUNGEN
+-----------
+::
+
+ Speziell in NPCs ist diese Funktion normalerweise dafuer
+ verantwortlich, dass mittels der Property P_REJECT die Annahme von
+ Objekten verweigert werden kann. Ueberschreibt man sie, so sollte
+ man gegebenenfalls darauf achten, dass diese Standardfunktion
+ ebenfalls aufgerufen wird.
+
+SIEHE AUCH
+----------
+::
+
+ P_REJECT, show_notify(),
+ /std/npc/put_and_get.c, /std/living/put_and_get.c
+
+22. Oktober 2013, Arathorn.
+
diff --git a/doc/sphinx/lfun/give_obj.rst b/doc/sphinx/lfun/give_obj.rst
new file mode 100644
index 0000000..7c36461
--- /dev/null
+++ b/doc/sphinx/lfun/give_obj.rst
@@ -0,0 +1,43 @@
+give_obj()
+==========
+
+FUNKTION
+--------
+::
+
+ int give_obj(object ob, object where)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ ob Das Objekt, das abgegeben werden soll.
+ where Das Lebewesen, dass das Objekt erhaelt.
+
+BESCHREIBUNG
+------------
+::
+
+ Das Lebewesen, in dem diese Funktion aufgerufen werden soll, gibt
+ den angegebenen Gegenstand (ob) an das angegebene Lebewesen (where).
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn das Objekt uebergeben wurde oder die Uebergabe nicht moeglich war.
+ (in diesem Fall wird auch direkt eine Textausgabe ausgegeben)
+ 0 sonst, in diesem Fall wird in notify_fail eine passende Ausgabe plaziert.
+
+SIEHE AUCH
+----------
+::
+
+ pick_obj(), drop_obj(), put_obj(), find_obs(), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/lfun/heal_self.rst b/doc/sphinx/lfun/heal_self.rst
new file mode 100644
index 0000000..0c81a60
--- /dev/null
+++ b/doc/sphinx/lfun/heal_self.rst
@@ -0,0 +1,70 @@
+heal_self()
+===========
+
+FUNKTION
+--------
+::
+
+ void heal_self(int points);
+
+ARGUMENTE
+---------
+::
+
+ points: Die dem Lebewesen zukommende Heilung.
+
+BESCHREIBUNG
+------------
+::
+
+ Dem Lebewesen werden points Lebens- und Konzentrationspunkte
+ gutgeschrieben und auf die aktuellen addiert. Es werden aber nicht
+ die maximalen Werte ueberschritten.
+
+RUECKGABEWERT
+-------------
+::
+
+ Keiner
+
+BEISPIELE
+---------
+::
+
+
+
+ AddCmd("pflueck&beere","pfluecke_cmd","Was moechtest Du pfluecken?");
+
+ int pfluecke_cmd(string str){
+ write("Du pflueckst eine Beere, isst sie und fuehlst Dich gleich "
+ +"viel besser.\n");
+ this_player()->heal_self(30);
+ return 1;
+ }
+
+ Der Spieler bekommt hier pro Beere die er pflueckt und isst je 30 LP/KP
+ zu seinen momentanen.
+
+BEMERKUNGEN:
+ heal_self wird gerne fuer Heilstellen in Gebieten genommen, in denen ein
+ Spieler diese Heilung auch wirklich braucht. Dennoch ist der Einsatz un-
+ bedingt mit der Heilungsbalance abzusprechen und darauf zu achten, dass
+ pro reset() nur eine bestimmte Anzahl an Heilungen ausgegeben werden.
+
+ Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
+ dafuer eingerichteten Funktion check_and_update_timed_key realisiert
+ werden.
+
+SIEHE AUCH
+----------
+::
+
+ Verwandt: restore_spell_points, restore_hit_points, buffer_hp
+ buffer_sp, check_and_update_timed_key
+ Gegenparts: do_damage, reduce_hit_points, reduce_spell_points
+ Props: P_HP, P_SP
+ Konzept: heilung
+
+
+Last modified: 27.05.2007 by Ennox
+
diff --git a/doc/sphinx/lfun/heart_beat.rst b/doc/sphinx/lfun/heart_beat.rst
new file mode 100644
index 0000000..e440ae1
--- /dev/null
+++ b/doc/sphinx/lfun/heart_beat.rst
@@ -0,0 +1,58 @@
+heart_beat()
+============
+
+FUNKTION
+--------
+::
+
+ protected void heart_beat();
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+ /std/living/combat.c
+ und anderen...
+ kann auch in beliebigen Objekten selbst definiert werden.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird alle zwei Sekunden vom GameDriver aufgerufen. Sie
+ regelt in der MG-MudLib das Heilen von Spielern und Monstern, den
+ Ablauf von Kampfrunden, die Verdauung etc.
+
+ Da heart_beat() ziemlich viele Ressourcen des GameDrivers verbraet,
+ sollte man Objekte mit heart_beat() nur so selten wie moeglich
+ benutzen! Und selbst dann sollte der heart_beat() nicht die ganze Zeit
+ ueber laufen, sondern sich so bald wie moeglich abschalten.
+
+ Das Ein- und Ausschalten des heart_beat()s erfolgt mit
+ set_heart_beat().
+
+BEMERKUNGEN
+-----------
+::
+
+ 1. Teuer, teuer, teuer!
+ 2. Soll euer Viech pro "echtem" Heartbeat mehrere Kampfrunden haben,
+ benutzt dafuer SA_SPEED und ruft auf gar keinen Fall mehrfach
+ ::heart_beat() auf. Also _NICHT_
+ void heart_beat() {
+ ::heart_beat();
+ ::heart_beat(); }
+ sondern:
+ SetProp(P_SKILL_ATTRIBUTE_OFFSETS, ([SA_SPEED: 200]) );
+
+SIEHE AUCH
+----------
+::
+
+ Efuns: set_heart_beat(), absolute_hb_count(), set_next_reset()
+ Fehler: make_immortal(L)
+
+
+22.3.2008, Zesstra
+
diff --git a/doc/sphinx/lfun/id.rst b/doc/sphinx/lfun/id.rst
new file mode 100644
index 0000000..539b0cd
--- /dev/null
+++ b/doc/sphinx/lfun/id.rst
@@ -0,0 +1,99 @@
+id()
+====
+
+FUNKTION
+--------
+::
+
+ varargs int id(string str, int lvl);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+ /std/player/base.c
+
+ARGUMENTE
+---------
+::
+
+ string str
+ String, auf den getestet werden soll.
+ int lvl
+ In /std/player/base.c benutzt. Wenn der Spieler unsichtbar ist
+ und lvl kleiner ist als sein Level, wird 0 zurueckgegeben.
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird geprueft, ob sich das Objekt mit str ansprechen laesst. Dazu
+ wird str mit dem Inhalt der Property P_IDS verglichen. Falls
+ P_ADJECTIVES gesetzt ist, werden auch alle Adjektivkombinationen mit
+ den Bezeichnern geprueft.
+
+ Besondere Bedeutung hat diese Funktion bei Mengenobjekten: Anhand von
+ str wird vermerkt, welche Menge des Objektes angesprochen wird. Es
+ werden dabei mehrere Faelle unterschieden:
+ o str ist einer der mit AddId() angegebener Bezeichner. In diesem
+ Fall ist die angesprochene Menge die Gesamtmenge.
+ o str ist einer der mit AddSingularId() angegebenen Bezeichner. Die
+ angesprochene Menge ist in diesem Fall 1.
+ o str ist einer der mit AddPluralId() angegebenen Bezeichner. Die
+ angesprochene Menge ist in diesem Fall . die Gesamtmenge.
+ o Hat str die Form "<n> <id>", wobei <n>=1 und <id> eine SingularId
+ oder 1 < <n> <= der Gesamtmenge und <id> eine PluralId, so ist die
+ angesprochene Menge = <n>.
+ Wie gesagt, gilt dies einzig und allein bei Mengenobjekten!
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn sich das Objekt von str angesprochen fuehlt, ansonsten 0.
+
+BEISPIELE
+---------
+::
+
+ Angenommen, ein Objekt habe folgende Bezeichner:
+
+ AddId( "murmel" );
+ AddAdjective( "runde" );
+
+ Dann liefern die angegebenen id()-Aufrufe folgende Ergebnisse:
+
+ id( "murmel" ); => 1
+ id( "runde murmel" ); => 1
+ id( "kleine murmel" ); => 0
+ id( "runder ball" ); => 0
+ id( "runde murmel 2" ); => 1, wenn dies die zweite Murmel in der
+ gleichen Umgebung ist, ansonsten 0
+
+ Bei einem Haufen von 100 Muenzen haette man zB.:
+
+ AddId( "geld" );
+ AddSingularId( "muenze" );
+ AddPluralId( "muenzen" );
+
+ Nach fuehlen sich nach den folgenden id()-Aufrufen folgende Anzahlen
+ angesprochen:
+
+ id( "geld" ); => 100 Muenzen
+ id( "muenze" ); => 1 Muenze
+ id( "muenzen" ); => 100 Muenzen
+ id( "1 muenze" ); => 1 Muenze
+ id( "42 muenzen" ); => 42 Muenzen
+
+ id() liefert in all diesen Faellen 1 zurueck.
+
+SIEHE AUCH
+----------
+::
+
+ AddId(), AddAdjective(), AddSingularId(), AddPluralId(), present(),
+ match_ids(), /std/thing/description.c, /std/unit.c
+
+6. Sep 2012 Gloinson
+
diff --git a/doc/sphinx/lfun/init.rst b/doc/sphinx/lfun/init.rst
new file mode 100644
index 0000000..a2855e5
--- /dev/null
+++ b/doc/sphinx/lfun/init.rst
@@ -0,0 +1,91 @@
+init()
+======
+
+FUNKTION
+--------
+::
+
+ void init();
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/description.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ init() wird immer dann aufgerufen, wenn ein lebendes Objekt in die
+ Naehe anderer Objekte bewegt wird oder ein nicht lebendiges Objekt
+ in die Naehe von Lebewesen gelangt. init() wird dabei in allen
+ Objekten aufgerufen, bei denen es notwendig ist.
+
+ Der Hauptzweck dieser Funktion besteht darin, den Objekten
+ untereinander ihre jeweiligen Befehle zugaenglich zu machen.
+ Waehrend dies in anderen MudLibs durch eine Reihe von
+ add_action()-Aufrufen im Rumpf von init() geschah, geschieht dies in
+ der MG-MudLib bei Objekten, die /std/thing/commands.c erben
+ (das sind zB. alle Standardobjekte) quasi automatisch
+ (dort werden die Befehle dann per AddCmd() im create() angemeldet,
+ man spart sich die Implementierung von init() und dem Mud somit
+ Speicher). Der andere Weg ist aber natuerlich immer noch moeglich.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Der Ablauf der init()-Kette ist wie folgt:
+ o Ist das Objekt X, welches ins Zielobjekt D bewegt wurde, ein
+ Lebewesen, so wird in D init() aufgerufen, wobei this_player() auf
+ X gesetzt ist.
+ o Dann wird fuer jedes Objekt C in D folgendes ausgefuehrt:
+ + Ist C ein Lebewesen, dann wird init() in X aufgerufen, wobei
+ this_player() auf C gesetzt ist.
+ + Ist X ein Lebewesen, dann wird init() in C aufgerufen, wobei
+ this_player() auf X gesetzt ist.
+ o Schliesslich wird in dem Fall, dass D lebendig ist, in X init()
+ aufgerufen, wobei this_player() auf D gesetzt ist.
+
+BEISPIELE
+---------
+::
+
+ D sei ein Raum, in dem sich das Lebewesen L1 sowie die Gegenstaende
+ N1 und N2 befinden.
+ Betritt ein Spieler X diesen Raum, so werden folgende init()s
+ aufgerufen:
+
+ D->init(); // this_player() == X
+ X->init(); // this_player() == L1
+ L1->init(); // this_player() == X
+ N1->init(); // this_player() == X
+ N2->init(); // this_player() == X
+
+ Gelangt dagegen ein nichtlebendiges Objekt nach D, so sieht das Ganze
+ wie folgt aus:
+
+ X->init(); // this_player() == L1
+
+SIEHE AUCH
+----------
+::
+
+ exit(), AddCmd(), add_action(),
+ NotifyInsert()
+
+Last modified: 04.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/insert_sensitive_inv.rst b/doc/sphinx/lfun/insert_sensitive_inv.rst
new file mode 100644
index 0000000..409e1f6
--- /dev/null
+++ b/doc/sphinx/lfun/insert_sensitive_inv.rst
@@ -0,0 +1,36 @@
+insert_sensitive_inv()
+======================
+
+FUNKTION
+--------
+::
+
+ void insert_sensitive_inv(object ob, string key,
+ int threshold, mixed *opt)
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/inventory.c
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion sucht, ob beim Hinzufuegen eines sensitiven Objekts
+ schon ein Objekt da ist, dass dieses ausloest.
+
+SIEHE AUCH
+----------
+::
+
+ P_SENSITIVE
+ InsertSensitiveObject, RemoveSensitiveObject
+ insert_sensitive_inv_trigger
+ P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY,
+ P_SENSITIVE_INVENTORY_TRIGGER
+ CheckSensitiveAttack
+
+28.Jan.2001, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/insert_sensitive_inv_trigger.rst b/doc/sphinx/lfun/insert_sensitive_inv_trigger.rst
new file mode 100644
index 0000000..8025faf
--- /dev/null
+++ b/doc/sphinx/lfun/insert_sensitive_inv_trigger.rst
@@ -0,0 +1,36 @@
+insert_sensitive_inv_trigger()
+==============================
+
+FUNKTION
+--------
+::
+
+ void insert_sensitive_inv_trigger(object ob, string key,
+ int threshold, mixed *opt)
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/inventory.c
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion sucht, ob ein sensitives Objekt im Inventory ist,
+ das durch dieses (soeben eingefuegte) Objekt ausgeloest wird.
+
+SIEHE AUCH
+----------
+::
+
+ P_SENSITIVE
+ InsertSensitiveObject, RemoveSensitiveObject
+ insert_sensitive_inv
+ P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY,
+ P_SENSITIVE_INVENTORY_TRIGGER
+ CheckSensitiveAttack
+
+28.Jan.2001, Gloinson@MG
+
diff --git a/doc/sphinx/lfun/int_long.rst b/doc/sphinx/lfun/int_long.rst
new file mode 100644
index 0000000..aa285b1
--- /dev/null
+++ b/doc/sphinx/lfun/int_long.rst
@@ -0,0 +1,91 @@
+int_long()
+==========
+
+FUNKTION
+--------
+::
+
+ varargs string int_long(mixed viewer, mixed viewpoint, int flags)
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/description.c
+
+ARGUMENTE
+---------
+::
+
+ mixed viewer - der Betrachter des Raumes
+ mixed viewpoint - 0/Objekt/Array der/die Ausgangspunkt(e) des
+ Betrachtens (und damit nicht sichtbar!)
+ int flags - Modifikatoren fuer die Anzeige
+ (siehe "man make_invlist", wird mit 3 verUNDet!)
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird die Beschreibung des Rauminneren erstellt. Dabei wird die
+ Langbeschreibung des Raumes, die enthaltenen Objekte (exklusive
+ aller viewpoints (normalerweise nur der Betrachter)) und Ausgaenge,
+ wenn vom Viewer eingeschaltet dargestellt.
+ Falls der Raum innerhalb eines anderen Raumes liegt und selbst
+ transparent ist, wie zusaetzlich die Kurzbeschreibung des Aussen-
+ raumes angezeigt.
+
+ Ist Viewer ein Magier mit eingeschaltetem Magiermodus, so wird der
+ Beschreibung der Dateiname des Raumes vorangestellt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Die Langbeschreibung des Raumes von innen.
+
+BEMERKUNGEN
+-----------
+::
+
+ Die Trennung von viewer und viewpoint hat durchaus ihren Sinn. So ist
+ es zum Beispiel moeglich, einen Raum "mit den Augen eines Anderen" zu
+ betrachten. Dabei saehe man sich selbst, wenn man im Raum waere.
+
+BEISPIELE
+---------
+::
+
+ // in diesem Raum sieht man keine Mitspieler im "schau" oder beim
+ // Betreten (vielleicht ist es zu neblig)
+ // dazu werden einfach alle Interactives zu den viewpoints addiert
+ string int_long(object viewer, mixed viewpoints, int flags) {
+ if(!pointerp(viewpoints)) viewpoints=({viewpoints});
+ return ::int_long(&viewer,
+ viewpoints+
+ filter(all_inventory(this_object()),
+ #'interactive),
+ &flags);
+ }
+
+ string int_short(object viewer, mixed viewpoints) {
+ if(!pointerp(viewpoints)) viewpoints=({viewpoints});
+ return ::int_short(&viewer,
+ viewpoints+
+ filter(all_inventory(this_object()),
+ #'interactive));
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Aehnliches: int_short()
+ Properties: P_INT_LONG, P_SHORT
+ P_HIDE_EXITS, P_SHOW_EXITS
+ P_TRANSPARENT
+ Kommandokette: make_invlist(), short()
+ Sonstiges: P_REFERENCE_OBJECT, P_WANTS_TO_LEARN
+
+11. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/int_short.rst b/doc/sphinx/lfun/int_short.rst
new file mode 100644
index 0000000..dd874b9
--- /dev/null
+++ b/doc/sphinx/lfun/int_short.rst
@@ -0,0 +1,85 @@
+int_short()
+===========
+
+FUNKTION
+--------
+::
+
+ string int_short(mixed viewer, mixed viewpoint);
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/description.c
+
+ARGUMENTE
+---------
+::
+
+ mixed viewer - der Betrachter des Raumes
+ mixed viewpoint - 0/Objekt/Array der/die Ausgangspunkt(e) des
+ Betrachtens (und damit nicht sichtbar!)
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird eine kurze Beschreibung des Rauminneren erstellt. Dabei wird
+ die Kurzbeschreibung des Raumes, die enthaltenen Objekte (exklusive
+ aller viewpoints (normalerweise nur der Betrachter)) und Ausgaenge,
+ wenn vom Viewer eingeschaltet dargestellt.
+
+ Ist Viewer ein Magier mit eingeschaltetem Magiermodus, so wird der
+ Beschreibung der Dateiname des Raumes vorangestellt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Die Kurzbeschreibung des Raumes von innen.
+
+BEMERKUNGEN
+-----------
+::
+
+ Die Trennung von viewer und viewpoint hat durchaus ihren Sinn. So ist
+ es zum Beispiel moeglich, einen Raum "mit den Augen eines Anderen" zu
+ betrachten. Dabei saehe man sich selbst, wenn man im Raum waere.
+
+BEISPIELE
+---------
+::
+
+ // in diesem Raum sieht man keine Mitspieler im "schau" oder beim
+ // Betreten (vielleicht ist es zu neblig)
+ // dazu werden einfach alle Interactives zu den viewpoints addiert
+ string int_long(object viewer, mixed viewpoints, int flags) {
+ if(!pointerp(viewpoints)) viewpoints=({viewpoints});
+ return ::int_long(&viewer,
+ viewpoints+
+ filter(all_inventory(this_object()),
+ #'interactive),
+ &flags);
+ }
+
+ string int_short(object viewer, mixed viewpoints) {
+ if(!pointerp(viewpoints)) viewpoints=({viewpoints});
+ return ::int_short(&viewer,
+ viewpoints+
+ filter(all_inventory(this_object()),
+ #'interactive));
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Aehnliches: int_long()
+ Properties: P_INT_SHORT, P_SHORT
+ P_HIDE_EXITS, P_SHOW_EXITS
+ Kommandokette: make_invlist(), short()
+ Sonstiges: P_REFERENCE_OBJECT, P_WANTS_TO_LEARN
+
+11. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/is_class_member.rst b/doc/sphinx/lfun/is_class_member.rst
new file mode 100644
index 0000000..b44cb66
--- /dev/null
+++ b/doc/sphinx/lfun/is_class_member.rst
@@ -0,0 +1,175 @@
+is_class_member()
+=================
+
+FUNKTION
+--------
+::
+
+ int is_class_member(string|string* class);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ string/string* class - String oder Stringarray der Klasse(n)
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird getestet, ob das Objekt in eine der in class angegebenen
+ Klassen faellt. In diesen Test werden die folgenden Eigenschaften des
+ Objektes einbezogen:
+
+ 1. Die Rasse des Objektes (bei Lebewesen),
+ 2. die IDs des Objektes und
+ 3. die explizit angegebenen Klassen des Objektes.
+ 4. einigen impliziten Klassen, die sich aus den Klassen in 3 ergeben.
+
+ Die moeglichen Klassen sind in /sys/class.h definiert. Momentan stehen
+ folgende Klassen zur Verfuegung:
+
+ CL_AMMUNITION
+ Das Objekt eignet sich als Munition.
+ CL_ANIMAL
+ Das Objekt ist ein Tier.
+ CL_ARACHNID
+ Das Objekt in ein Spinnenwesen.
+ CL_BIGBANG
+ Dieses Objekt kann mehreren Lebewesen auf einmal Schaden zufuegen.
+ CL_BIRD
+ Ein Vogel.
+ CL_CRAWLING
+ Dieses Wesen bewegt sich kriechend.
+ CL_CURSE
+ Das Objekt ist ein Fluch (zB. ein Sprachfluch).
+ CL_DEMON
+ Bei dem Objekt handelt es sich um einen Daemon.
+ CL_DISEASE
+ Eine Krankheit.
+ CL_DRAGON
+ Ein Drache.
+ CL_DWARF
+ Fuer unsere kleinen Gaeste...
+ CL_ELF
+ Elfen aller Art.
+ CL_ELEMENTAL
+ Ein Elementar irgendeiner Art. Material setzen waere angebracht.
+ CL_EXPLOSIVE
+ Bei dem Objekt handelt es sich um einen Sprengstoff.
+ CL_FELINE
+ Felinen und andere katzenartigen Lebewesen.
+ CL_FISH
+ Fische - keine Meeressaeuger!
+ CL_FLYING
+ Dieses Wesen bewegt sich fliegend.
+ CL_FROG
+ Froesche - auch gefroschte Spieler.
+ CL_GHOST
+ Geister und geisterhafte Wesen.
+ CL_GHOUL
+ Ein Ghoul. Er faellt automatisch in die Klasse CL_UNDEAD.
+ CL_GIANT
+ Ein riesiges Lebewesen.
+ CL_GNOME
+ Ein Gnom.
+ CL_GOBLIN
+ Ein Goblin.
+ CL_HOBBIT
+ Ein Hobbit.
+ CL_HOBGOBLIN
+ Ein Hobgoblin. Er faellt automatisch auch in die Klasse CL_GOBLIN.
+ CL_HUMAN
+ Ein Mensch.
+ CL_INORGANIC
+ Anorganische Lebewesen wie Metallmonster
+ CL_INSECT
+ Insekten (Nicht mit Spinnen verwechseln)
+ CL_LIVING
+ Lebewesen im allgemeinen.
+ CL_MAMMAL
+ Saeugetiere.
+ CL_MAMMAL_LAND
+ Landsaeugetiere
+ CL_MAMMAL_WATER
+ Meeressaeuger.
+ CL_ORC
+ Ein Ork.
+ CL_PLANT
+ Pflanzen und pflanzenartige Monster.
+ CL_POISON
+ Das Objekt ist selbst ein Gift
+ CL_POISONOUS
+ Das Objekt kann einen Spieler/NPC vergiften.
+ CL_REPTILE
+ Reptilien.
+ CL_SHADOW
+ Schattenwesen.
+ CL_SKELETON
+ Ein Skelett. Es faellt automatisch in die Klasse CL_UNDEAD.
+ CL_SLIME
+ Fuer Einzeller und aehnliches Schleimgetier
+ CL_SNAKE
+ Schlangen.
+ CL_SWIMMING
+ Dieses Wesen bewegt sich schwimmend.
+ CL_TROLL
+ Ein Troll.
+ CL_UNDEAD
+ Ein untotes Lebewesen.
+ CL_WALKING
+ Dieses Wesen bewegt sich gehend.
+ CL_VAMPIRE
+ Ein Vampir. Er faellt automatisch in die Klasse CL_UNDEAD.
+ CL_ZOMBIE
+ Ein Zombie. Er faellt automatisch in die Klasse CL_UNDEAD.
+
+ Implizite Klassen:
+ Bei einigen Klassen wird im AddClass() automatisch eine oder mehrere
+ weiterer Klassen hinzugefuegt und im RemoveClass() die entsprechenden
+ impliziten Klassen auch automatisch entfernt.
+ Wuenscht man diese impliziten Klassen nicht, muss man nach dem AddClass()
+ diese mittels eines entsprechenden RemoveClass() entfernen.
+ Die impliziten Klassen einer Klasse lassen sich mit Hilfe der Funktion
+ QueryImplicitClasses() in CLASSDB herausfinden:
+ CLASSDB->QueryImplicitClasses(...)
+ Momentan sind dies:
+ CL_ZOMBIE: CL_UNDEAD
+ CL_SKELETON: CL_UNDEAD
+ CL_GHOUL: CL_UNDEAD
+ CL_VAMPIRE: CL_UNDEAD
+ CL_HOBGOBLIN: CL_GOBLIN
+ CL_MAMMAL_LAND: CL_MAMMAL, CL_ANIMAL
+ CL_MAMMAL_WATER: CL_MAMMAL, CL_ANIMAL
+ CL_SNAKE: CL_REPTILE
+ CL_ARACHNID: CL_ANIMAL
+ CL_BIRD: CL_ANIMAL
+ CL_FISH: CL_ANIMAL
+ CL_FROG: CL_ANIMAL
+ CL_INSECT: CL_ANIMAL
+ CL_MAMMAL: CL_ANIMAL
+ CL_REPTILE: CL_ANIMAL
+ CL_SNAKE: CL_ANIMAL
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn das Objekt in eine der angegebenen Klassen faellt, ansonsten 0.
+
+SIEHE AUCH
+----------
+::
+
+ AddClass(), RemoveClass(), /std/thing/description.c
+ P_CLASS
+
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/lfun.rst b/doc/sphinx/lfun/lfun.rst
new file mode 100644
index 0000000..98bdeba
--- /dev/null
+++ b/doc/sphinx/lfun/lfun.rst
@@ -0,0 +1,25 @@
+lfun()
+======
+
+NAME
+----
+::
+
+ lfun()
+
+DESCRIPTION
+-----------
+::
+
+ This directory contains descriptions for the lfuns used by
+ Amylaar's version of the LPC parser.
+
+ These are functions that are applied by the parser to the LPC
+ objects on various occasions.
+
+SEE ALSO
+--------
+::
+
+ efun(E), master(M), concepts(C), lpc(LPC), driver(D)
+
diff --git a/doc/sphinx/lfun/locate_objects.rst b/doc/sphinx/lfun/locate_objects.rst
new file mode 100644
index 0000000..d9040b8
--- /dev/null
+++ b/doc/sphinx/lfun/locate_objects.rst
@@ -0,0 +1,80 @@
+locate_objects()
+================
+
+FUNKTION
+--------
+::
+
+ object *locate_objects(string desc, int info);
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+ desc
+ Die Umschreibung des gesuchten Objektes.
+
+ info
+ Ist ungleich 0, wenn diese Funktion von /std/living/put_and_get.c
+ aus aufgerufen wurde.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion erweitert die Funktionalitaet von present_objects()
+ insofern, als dass es moeglich ist, auch noch Behaelter innerhalb des
+ Behaelters zu durchsuchen. Das genaue Verhalten haengt von desc ab:
+
+ Ist desc von der Form "<id>", so wird das Ergebnis von
+ present_objects(desc) zurueckgegeben.
+
+ Ist desc von der Form "<gesucht> in <id>", so wird in allen Objekten,
+ die von present_objects("<id>") erfasst wurden,
+ locate_objects("<desc>") aufgerufen. Zurueckgegeben werden alle auf
+ diese Weise gefundenen Objekte.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Array von Objekten, die auf die oben geschilderte Art und Weise
+ ermittelt wurden. Konnte kein Objekt ermittelt werden, wird ein leeres
+ Array zurueckgegeben.
+
+BEMERKUNGEN
+-----------
+::
+
+ Theoretisch sollte es moeglich sein, ueber desc rekursiv mehrere
+ Behaelterebenen erfassen zu koennen (etwa mit "schwert in beutel in
+ beutel in wargon"). In der aktuellen Implementierung klappt das jedoch
+ nicht; nach dem ersten "in" ist Schluss!
+
+BEISPIELE
+---------
+::
+
+ Was steckt alles dem Beutel, den der Spieler bei sich traegt?
+
+ object *obs;
+ obs = this_player()->locate_objects("alles in beutel");
+
+ Traegt der Spieler keinen Beutel bei sich oder ist dieser leer, so wird
+ ein leeres Array zurueckgegeben.
+
+SIEHE AUCH
+----------
+::
+
+ present_objects(), /std/container/restrictions.c
+
+
+Last modified: Wed May 8 10:20:36 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/logon.rst b/doc/sphinx/lfun/logon.rst
new file mode 100644
index 0000000..f867428
--- /dev/null
+++ b/doc/sphinx/lfun/logon.rst
@@ -0,0 +1,26 @@
+logon()
+=======
+
+SYNOPSIS
+--------
+::
+
+ int logon(void)
+
+DESCRIPTION
+-----------
+::
+
+ When the parser accepts a new connection, it first calls
+ connect() in the master object and then applies logon() to
+ the object that is returned by the master. That will usually be
+ a special login object, that is expected to clone and get going
+ a user shell or player object.
+ Should return 0 on failure, everything else means success.
+
+SEE ALSO
+--------
+::
+
+ connect(M)
+
diff --git a/doc/sphinx/lfun/long.rst b/doc/sphinx/lfun/long.rst
new file mode 100644
index 0000000..22b5291
--- /dev/null
+++ b/doc/sphinx/lfun/long.rst
@@ -0,0 +1,55 @@
+long()
+======
+
+FUNKTION
+--------
+::
+
+ varargs string long(int mode);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ int mode - Modifikatoren fuer die Anzeige, falls this_object()
+ ein Container ist
+ (siehe "man make_invlist")
+
+BESCHREIBUNG
+------------
+::
+
+ Der Inhalt der Property P_LONG wird ausgewertet und zurueckgegeben.
+ Falls das Objekt ein Container und transparent (offen) ist, wird
+ zudem make_invlist() auf den Inhalt zurueckgegeben.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Die Langbeschreibung des Objektes.
+
+BEMERKUNGEN
+-----------
+::
+
+ Durch Ueberladen von long() lassen sich noch weitere Eigenschaften des
+ Objektes anzeigen. Behaelter koennen zum Beispiel noch ihren Inhalt
+ anzeigen, Lebewesen ihren Gesundheitszustand, o.ae.
+
+SIEHE AUCH
+----------
+::
+
+ Aehnliches: short()
+ Properties: P_LONG, P_INVIS, P_TRANSPARENT
+ Sonstiges: make_invlist()
+
+11. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/make_immortal.rst b/doc/sphinx/lfun/make_immortal.rst
new file mode 100644
index 0000000..97b225f
--- /dev/null
+++ b/doc/sphinx/lfun/make_immortal.rst
@@ -0,0 +1,44 @@
+make_immortal()
+===============
+
+FUNKTION
+--------
+::
+
+ void make_immortal();
+
+DEFINIERT IN
+------------
+::
+
+ /std/npc/combat.c
+
+BESCHREIBUNG
+------------
+::
+
+ Macht den NPC fuer 5 Minuten unangreifbar und heilt ihn.
+
+ Wird bei Fehlern im Herzschlag des NPCs gerufen um Bugnutzung
+ zu unterbinden.
+
+ Ausschrift:
+ "... versteckt sich hinter einem Fehler im Raum-Zeit-Gefuege und
+ entgeht so voruebergehend allen Angriffen."
+
+BEMERKUNGEN
+-----------
+::
+
+ Nicht missbrauchen.
+
+SIEHE AUCH
+----------
+::
+
+ Methoden: heart_beat(), static _check_immortality()
+ Master: heart_beat_error()
+ Properties: "time_to_mortality"
+
+1.Juni 2007 Gloinson
+
diff --git a/doc/sphinx/lfun/make_invlist.rst b/doc/sphinx/lfun/make_invlist.rst
new file mode 100644
index 0000000..94dc5bd
--- /dev/null
+++ b/doc/sphinx/lfun/make_invlist.rst
@@ -0,0 +1,59 @@
+make_invlist()
+==============
+
+FUNKTION
+--------
+::
+
+ varargs mixed make_invlist(object viewer, mixed inv, int flags)
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/description.c
+
+ARGUMENTE
+---------
+::
+
+ object viewer - das Objekt, welches sich den Inhalt ansieht (in
+ der Regel this_player())
+ mixed inv - ein Array von Objekten, die in die Liste
+ aufgenommen werden sollen
+ int flags - Folgende Werte koennen verODERt werden:
+ 1: das Inv nicht als String, sondern als ein
+ Array zurueckgeben
+ 2: gleiche Objekte nicht zusammengefassen
+ 4: unterdrueckt die Ausgabe des Dateinamens hinter
+ jedem trotz eingeschaltetem Magiermodus
+
+BESCHREIBUNG
+------------
+::
+
+ Die Kurzbeschreibungen der Objekte in inv werden zu einer Liste
+ zusammengefasst (eine Zeile pro Objekt). Unsichtbare Objekte tauchen in
+ dieser Liste nicht auf.
+
+ Ist viewer ein Magier mit eingeschaltetem Magiermodus, so wird hinter
+ die Kurzbeschreibungen noch der Dateiname des jeweiligen Objektes in
+ eckigen Klammern angegeben. Unsichtbare Objekte erscheinen in diesem
+ Fall als Filenamen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ein String oder ein Array, die das inv beschreiben.
+
+SIEHE AUCH
+----------
+::
+
+ Kommandokette: short()
+ Properties: P_SHORT, P_INVIS, P_WANTS_TO_LEARN
+ Sonstiges: P_REFERENCE_OBJECT
+
+Last modified: Tue Oct 15 10:10:00 2002 by Rikus
+
diff --git a/doc/sphinx/lfun/master/AddWizardForUID.rst b/doc/sphinx/lfun/master/AddWizardForUID.rst
new file mode 100644
index 0000000..3e9f504
--- /dev/null
+++ b/doc/sphinx/lfun/master/AddWizardForUID.rst
@@ -0,0 +1,74 @@
+AddWizardForUID()
+=================
+
+FUNKTION
+--------
+::
+
+ string* AddWizardForUID(string uid, string wizard);
+
+DEFINIERT IN
+------------
+::
+
+ /secure/master/userinfo.c
+
+ARGUMENTE
+---------
+::
+
+ uid
+ Die UID, fuer die man einen (weiteren) verantwortlichen Magier
+ explizit eintragen moechte.
+ wizard
+ Der Magier, den man eintragen moechte.
+
+BESCHREIBUNG
+------------
+::
+
+ Die Funktion traegt einen Magier 'wizard' explizit als verantwortlichen
+ Magier fuer die UID 'uid' ein. Hierbei kann 'uid' sogar der Name eines
+ anderen Magiers sein, dessen UIDs 'wizard' sozusagen "adoptiert".
+
+ Berechtigt zum Eintragen von Magiern fuer bestimmte UIDs sind alle Magier,
+ die (implizit oder explizit) verantwortlich fuer die jeweilige UID sind.
+ Z.B. kann Zesstra ohne weiteres jemand weiteren als verantwortlich fuer
+ d.inseln.zesstra eintragen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID,
+ fuer die dier Magier jetzt explizit eingetragen ist.
+
+BEMERKUNGEN
+-----------
+::
+
+ Es ist nicht noetig, z.B. Zesstra als verantwortlich fuer d.inseln.zesstra
+ einzutragen, da sie ohnehin schon implizit dafuer zustaendig ist. Auch
+ fuer RMs bzw. GMs muss ihre Region bzw. Gilde nicht explizit eingetragen
+ werden.
+
+BEISPIELE
+---------
+::
+
+ master()->AddWizardForUID("p.waterluh","zook");
+
+
+
+ string *uids = master()->AddWizardForUID("jof","zook");
+ printf("Zook ist nun explizit zustaendig fuer: %s\n",CountUp(uids));
+
+SIEHE AUCH
+----------
+::
+
+ QueryWizardsForUID(), QueryUIDsForWizard,
+ RemoveWizardFromUID()
+
+20.02.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/master/QueryUIDAlias.rst b/doc/sphinx/lfun/master/QueryUIDAlias.rst
new file mode 100644
index 0000000..04a4057
--- /dev/null
+++ b/doc/sphinx/lfun/master/QueryUIDAlias.rst
@@ -0,0 +1,65 @@
+QueryUIDAlias()
+===============
+
+FUNKTION
+--------
+::
+
+ varargs string* QueryUIDsForWizard(string uidalias, int recursive);
+
+DEFINIERT IN
+------------
+::
+
+ /secure/master/userinfo.c
+
+ARGUMENTE
+---------
+::
+
+ uidalias
+ UID, die expandiert werden soll.
+ recursive (optional)
+ Gibt an, ob QueryUIDAlias() (indirekt) rekursiv aufgerufen wurde.
+ Sollte normalerweise nicht per Hand gesetzt werden.
+
+BESCHREIBUNG
+------------
+::
+
+ Die Funktion ermittelt aus einer "Alias-UID" die UID, fuer die sie steht.
+ Hierbei werden folgende UID-Aliase beruecksichtigt:
+ "region": d.region.* + region + d.region
+ "gilde": GUILD.gilde, GUILD.gildenspellbook, p.gilde
+ "p": p.* (ohne p.service)
+ "p.service": p.service.*
+ "magierid": QueryUIDsForWizard()
+
+ Das Ergebnis dieser Funktion wird laengere Zeit gecachet (bis zu 24h).
+
+RUeCKGABEWERT
+-------------
+::
+
+ Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID.
+ Sollte uidaliase keines der o.g. sein, wird ein ({uidalias}) geliefert.
+
+BEISPIELE
+---------
+::
+
+ string *uids = master()->QueryUIDAlias("schattenwelt");
+ // uids enthaelt nun:
+ // ({"d.anfaenger","anfaenger","d.anfaenger.ark","d.anfaenger.ennox",
+ // "d.anfaenger.humni","d.anfaenger.kiria","d.anfaenger.konzepte",
+ // "d.anfaenger.miril"})
+
+SIEHE AUCH
+----------
+::
+
+ QueryWizardsForUID(),
+ AddWizardForUID(), RemoveWizardFromUID()
+
+16.12.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/master/QueryUIDsForWizard.rst b/doc/sphinx/lfun/master/QueryUIDsForWizard.rst
new file mode 100644
index 0000000..0055b97
--- /dev/null
+++ b/doc/sphinx/lfun/master/QueryUIDsForWizard.rst
@@ -0,0 +1,64 @@
+QueryUIDsForWizard()
+====================
+
+FUNKTION
+--------
+::
+
+ varargs string* QueryUIDsForWizard(string wizname, int recursive);
+
+DEFINIERT IN
+------------
+::
+
+ /secure/master/userinfo.c
+
+ARGUMENTE
+---------
+::
+
+ wizname
+ Der Magier, fuer den man die UIDs ermitteln will, fuer die er
+ zustaendig ist.
+ recursive (optional)
+ Gibt an, ob QueryUIDsForWizard() (indirekt) rekursiv aufgerufen wurde.
+ Sollte normalerweise nicht per Hand gesetzt werden.
+
+BESCHREIBUNG
+------------
+::
+
+ Die Funktion ermittelt die UIDs, fuer die dieser Magier zustaendig ist.
+ Dabei wird impliziert beruecksichtigt, wenn der Magier RM einer Region
+ oder Gildenmagier einer Gilde ist, ebenso wie Verzeichnisse in den
+ Regionen oder in /p/service.
+ Ausserdem wird nachgeschaut, fuer welche UIDs dieser Magier explizit
+ eingetragen worden ist.
+ Wenn z.B. Magier A auch fuer alle UIDs von Magier B zustaendig sein
+ sollte, liefert die Funktion auch die UIDs von B zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID.
+ Sollte fuer einen Namen keine UID ermittelbar sein, ist das Arrays leer.
+
+BEISPIELE
+---------
+::
+
+ string *uids = master()->QueryUIDsForWizard("ennox");
+ // uids enthaelt nun:
+ // ({"ennox","d.anfaenger.ennox","d.schattenwelt.ennox",
+ // "p.service.ennox","GUILD.chaos","p.chaos"})
+
+SIEHE AUCH
+----------
+::
+
+ QueryWizardsForUID(),
+ AddWizardForUID(), RemoveWizardFromUID()
+
+16.12.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/master/QueryWizardsForUID.rst b/doc/sphinx/lfun/master/QueryWizardsForUID.rst
new file mode 100644
index 0000000..4d8179d
--- /dev/null
+++ b/doc/sphinx/lfun/master/QueryWizardsForUID.rst
@@ -0,0 +1,71 @@
+QueryWizardsForUID()
+====================
+
+FUNKTION
+--------
+::
+
+ varargs string* QueryWizardsForUID(string uid, int recursive);
+
+DEFINIERT IN
+------------
+::
+
+ /secure/master/userinfo.c
+
+ARGUMENTE
+---------
+::
+
+ uid
+ Die UID, fuer die man die Magier ermitteln will, die fuer sie
+ zustaendig sind.
+ recursive (optional)
+ gibt an, ob das QueryWizardsForUID() (indirekt) aus einem
+ QueryWizardsForUID() heraus gerufen wurde. Sollte nicht manuell gesetzt
+ werden.
+
+BESCHREIBUNG
+------------
+::
+
+ Die Funktion ermittelt die Magier, die fuer diese UID zustaendig sind.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Zurueckgeliefert wird ein Array von Strings, jedes Element ist ein Magier.
+ Sollte fuer eine UID kein Magier ermittelbar sein, ist das Array leer.
+ Wenn z.B. fuer die UID der Magier "Atamur" gefunden wird, aber fuer alle
+ UIDs von "Atamur" auch der Magier "Rumata" zustaendig sein sollte, wird
+ "Rumata" ueber eine rekursive Suche gefunden.
+
+BEMERKUNGEN
+-----------
+::
+
+ Wenn die UID den Magier nicht implizit enthaelt (z.B. GUILD.gilde, im
+ Gegensatz zu d.region.magier), findet diese Funktion nur Magier, fuer die
+ seit Laden des Master bereits einmal get_userinfo() oder
+ QueryUIDsForWizard() im Master gerufen wurde, was z.B. Einloggen passiert.
+ Magier, die lang nicht einloggten, werden also manchmal nicht gefunden,
+ was in der Regel nicht schlimm sein sollte, da sie ja ohnehin den
+ entsprechenden Code gerade nicht warten...
+
+BEISPIELE
+---------
+::
+
+ string *wiz = master()->QueryWizards("GUILD.klerus");
+ // wiz enthaelt nun: ({"morgoth","magdalena"})
+
+SIEHE AUCH
+----------
+::
+
+ QueryUIDsForWizard(),
+ AddWizardForUID(), RemoveWizardFromUID()
+
+16.12.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/master/RemoveWizardFromUID.rst b/doc/sphinx/lfun/master/RemoveWizardFromUID.rst
new file mode 100644
index 0000000..406f3cf
--- /dev/null
+++ b/doc/sphinx/lfun/master/RemoveWizardFromUID.rst
@@ -0,0 +1,62 @@
+RemoveWizardFromUID()
+=====================
+
+FUNKTION
+--------
+::
+
+ string* RemoveWizardFromUID(string uid, string wizard);
+
+DEFINIERT IN
+------------
+::
+
+ /secure/master/userinfo.c
+
+ARGUMENTE
+---------
+::
+
+ uid
+ Die UID, fuer die man einen zustaendigen Magier austragen will.
+ wizard
+ Der Magier, den man austragen moechte.
+
+BESCHREIBUNG
+------------
+::
+
+ Die Funktion loescht die UID 'uid' aus der Liste der UIDs, fuer die
+ 'wizard' explizit zustaendig ist.
+
+ Berechtigt zum Austragen von Magiern fuer bestimmte UIDs sind alle Magier,
+ die (implizit oder explizit) verantwortlich fuer die jeweilige UID sind.
+ Man kann sich auch selber austragen. ;-)
+
+RUeCKGABEWERT
+-------------
+::
+
+ Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID,
+ fuer die dier Magier jetzt explizit eingetragen ist.
+
+BEISPIELE
+---------
+::
+
+ master()->RemoveWizardFromUID("p.waterluh","zook");
+
+
+
+ string *uids = master()->RemoveWizardFromUID("jof","zook");
+ printf("Zook ist nun explizit zustaendig fuer: %s\n",CountUp(uids));
+
+SIEHE AUCH
+----------
+::
+
+ QueryWizardsForUID(), QueryUIDsForWizard()
+ AddWizardForUID()
+
+20.02.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/match_ids.rst b/doc/sphinx/lfun/match_ids.rst
new file mode 100644
index 0000000..556233a
--- /dev/null
+++ b/doc/sphinx/lfun/match_ids.rst
@@ -0,0 +1,70 @@
+match_ids()
+===========
+
+FUNKTION
+--------
+::
+
+ int match_ids(string *list);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ *list String-Array mit zu testenden IDs
+
+BESCHREIBUNG
+------------
+::
+
+ Die Liste der uebergebenen IDs wird mit den IDs des Objektes
+ UND-Verknuepft. Die Groesse des resultierenden Arrays wird
+ zurueckgegeben.
+ Diese Funktion erlaubt also das gleichzeitige Pruefen auf
+ mehrere IDs. Allerdings werden - im Gegensatz zu id() -
+ Adjektive und Ausdruecke der Art "<ID> <nummer>" nicht
+ beruecksichtigt.
+ Ebenso werden Spezialitaeten wie Unitobjekte und Objekte mit
+ ueberschriebenem id() nicht beruecksichtigt! Im Zweifelsfall ist daher
+ doch die Nutzung von id() zu empfehlen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Anzahl der zutreffenden IDs.
+
+BEISPIELE
+---------
+::
+
+ Angenommen, ein Objekt habe folgende Bezeichner:
+
+ AddId( ({"murmel","kugel","glasmurmel","glaskugel"}) );
+ AddAdjective( "rund" );
+
+ Dann liefern die angegebenen match_ids()-Aufrufe folgende Ergebnisse:
+
+ match_ids( ({"murmel","stein"}) ); => 1
+ match_ids( ({"murmel","kugel"}) ); => 2
+ match_ids( ({"runde murmel"}) ); => 0
+ match_ids( ({"murmel 2"}) ); => 0, auch wenn dies die
+ zweite Murmel in der
+ gleichen Umgebung ist
+
+SIEHE AUCH
+----------
+::
+
+ AddId(), AddAdjective(), AddSingularId(), AddPluralId(), present(),
+ id(), /std/thing/description.c, /std/unit.c
+
+
+Last modified: Sat Mar 15 21:40:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/lfun/move.rst b/doc/sphinx/lfun/move.rst
new file mode 100644
index 0000000..6f427d1
--- /dev/null
+++ b/doc/sphinx/lfun/move.rst
@@ -0,0 +1,241 @@
+move()
+======
+
+move()
+
+FUNKTION:
+ Fuer unbelebte Gegenstaende (/std/thing):
+ varargs int move(object|string dest, int method);
+
+ Fuer Lebewesen (/std/living, /std/npc, usw.):
+ varargs int move(object|string dest, int method, string dir,
+ string textout, string textin);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/moving.c
+ /std/living/moving.c
+
+ARGUMENTE
+---------
+::
+
+ dest
+ Das Zielobjekt (entweder der Dateiname oder das Objekt selbst).
+
+ method
+ Die Art der Bewegung (eine der unten aufgefuehrten Arten; es
+ koennen auch mehrere zusammenge-ODER-t werden).
+
+ dir
+ Die Richtung, in die ein Lebewesen geht. Normalerweise ist das die
+ eingeschlagene Laufrichtung (zB. "nach Norden").
+
+ textout
+ Verlaesst ein Lebewesen einen Raum, so wird diese Meldung in den
+ Raum geschickt. Ist bei dir ein String angegeben, so wird dieser
+ noch an textout angehaengt. Der Name des Lebewesens wird der
+ Meldung in jedem Fall vorangestellt.
+
+ textin
+ Dieser Text wird im Zielraum ausgegeben, wenn ein Lebewesen ihn
+ betritt. Bei normaler Fortbewegung ist das "kommt an". Dem Text
+ wird noch der Name des Spielers vorangestellt.
+
+BESCHREIBUNG
+------------
+::
+
+ Es wird versucht, das Objekt in das Zielobjekt dest zu bewegen.
+ Abhaengig vom momentanen Aufenthaltsort und dem Zielobjekt ist die
+ Bewegungsmethode method zu waehlen.
+
+ In <moving.h> sind folgende Konstanten fuer die Art der Bewegung
+ definiert:
+ M_NOCHECK
+ Es werden keine Abfragen durchgefuehrt, ob das Objekt ueberhaupt
+ in das Zielobjekt hineinpasst (was zB. aus Gewichtsgruenden der
+ Fall sein koennte).
+
+ M_GO
+ Ein Lebewesen bewegt sich gehend von einem Raum in den naechsten.
+ Bei normalem Gehen wird diese Methode benutzt; man sollte sie auch
+ benutzen, wenn man Spieler ueber einen SpecialExit in einen
+ benachbarten Raum bewegt.
+
+ M_TPORT
+ Ein Lebewesen wird von einem Raum in einen anderen teleportiert.
+ Im Gegensatz zu M_GO kann ein Raum verhindern, dass man ihn
+ mittels M_TPORT verlaesst oder betritt.
+
+ M_NO_SHOW
+ Beim Bewegen von Lebewesen bekommen diese die Beschreibung des
+ Zielraumes nicht ausgegeben.
+
+ M_NO_ATTACK
+ Beim Bewegen von Lebewesen bekommen diese keinen
+ Begruessungsschlag, wenn ein Feind im Zielraum steht.
+
+ M_SILENT
+ Es werden beim Bewegen keine Meldungen ausgegeben. Dieser
+ Parameter wirkt sich nur auf das Bewegen von Lebenwesen aus.
+
+ M_GET
+ Das Objekt wird von einem unbelebten Objekt (zB. einem Raum, einer
+ Leiche, einem Beutel) in ein lebendes Objekt (Spieler oder NPC)
+ bewegt.
+
+ M_PUT
+ Das Objekt wird von einem lebenden Objekt in ein unbelebtes Objekt
+ bewegt.
+
+ M_GIVE
+ Das Objekt wird von einem Lebewesen an ein anderes Lebewesen
+ weitergereicht.
+
+ M_MOVE_ALL (Nur fuer Objekte, die /std/unit.c erben)
+ Es wird die gesamte Menge bewegt, nicht nur ein Teil.
+
+ Soll das Objekt auf jeden Fall und ohne jede Abfrage bewegt werden, so
+ reicht es, als method M_NOCHECK zu uebergeben.
+
+ Waffen und Ruestungen werden, soweit sie gezueckt bzw. angezogen sind,
+ beim Bewegen auf jeden Fall weggesteckt bzw. ausgezogen. Ist in method
+ M_SILENT enthalten, so geschieht dies ohne Meldungen.
+
+ Die erste Art des Funktionsaufrufs ist sowohl beim Bewegen von
+ Lebewesen als auch von unbelebten Objekten moeglich. Die zweite Art
+ laesst sich nur bei Lebewesen anwenden.
+
+ANMERKUNG
+---------
+::
+
+ Diese Funktion sollte nicht (mehr) ueberschrieben werden. Stattdessen
+ greift bitte auf PreventMove() und NotifyMove() zurueck. RMs sind
+ aufgerufen, Objekt mit ueberschriebenen move() nur noch dann
+ anzuschliessen, wenn der Zweck sonst nicht erreicht werden kann. Solltet
+ ihr move() ueberschreiben: Seid euch sehr genau im klaren, was move()
+ genau macht. ;-)
+
+
+
+ Wenn Livings bewegt werden, sorgt move() automatisch in Abhaengigkeit
+ von P_PARA dafuer, dass das Lebewesen in der korrekten (Parallel-)Welt
+ landet.
+
+ Bei Gegenstaenden wird ebenfalls versucht, die richtige Zielwelt
+ auszuwaehlen (damit z.B. in der Parallelwelt geworfene Bumerangs auch nur
+ innerhalb der Parallelwelt fliegen). Um Rechenzeit zu sparen, wird das
+ allerdings nur versucht, wenn 'dest' ein Filename ist und kein Objekt.
+
+ Grund: bei Zielobjekten handelt es sich meist um Bewegungen in das Inv
+ oder Env eines Spielers - und die sind uninteressant. Raumwechsel dagegen
+ erfolgen fast immer unter Angabe eines Filenamens anstatt eines Objektes.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Alle Rueckgabewerte sind als symbolische Konstanten in <moving.h>
+ definiert. (MOVE_OK ist 1, alle anderen sind <0 und symbolisieren Fehler.
+ Traditionell erfolgt die Pruefung auf erfolgreiches Move mit == 1, in
+ Zukunft wird == MOVE_OK empfohlen.)
+
+
+
+ MOVE_OK
+ Die Bewegung wurde erfolgreich abgeschlossen.
+
+ ME_PLAYER
+ Lebewesen lassen sich nicht ohne weiteres bewegen. Es muss
+ mindestens eine der Methoden M_NOCHECK, M_GO oder M_TPORT
+ angegeben werden.
+
+ ME_TOO_HEAVY
+ Das Zielobjekt kann dieses Objekt aus Gewichtsgruenden nicht mehr
+ aufnehmen.
+
+ ME_CANT_TPORT_IN
+ Das Zielobjekt verbietet das Teleportieren in sich hinein (nur bei
+ M_TPORT ohne M_NOCHECK).
+
+ ME_CANT_TPORT_OUT
+ Der Raum, in dem sich das Lebewesen befindet, verbietet das
+ Teleportieren aus sich hinaus (nur bei M_TPORT ohne M_NOCHECK).
+
+ ME_CANT_BE_DROPPED
+ Das Objekt kann nicht fallen gelassen werden (zB. weil P_NODROP
+ gesetzt ist).
+
+ ME_CANT_BE_TAKEN
+ Das Objekt kann nicht genommen werden (zB. weil P_NOGET gesetzt
+ ist).
+
+ ME_CANT_BE_INSERTED
+ Das Zielobjekt verhindert das Einfuegen aus bestimmten Gruenden.
+
+ ME_CANT_LEAVE_ENV
+ Der Container verhindert ein verlassen des Objektes
+
+ ME_TOO_HEAVY_FOR_ENV
+ Ein Objekt kann einen Behaelter nicht verlassen, da es dem
+ Lebewesen sonst zu schwer wuerde.
+
+ TOO_MANY_OBJECTS
+ Das Zielobjekt kann soviele Objekte nicht mehr aufnehmen.
+
+ ME_NOT_ALLOWED
+ Raeume mit gesetzter Property P_NO_PLAYERS koennen nur von
+ Testspielern und Magiern betreten werden. Bei Spielern oder
+ Gildentesties gibt es diese Fehlermeldung.
+ ME_WAS_DESTRUCTED
+ Das Objekt hat sich entweder im Verlaufe der Bewegung selbst
+ zerstoert oder wurde zerstoert, sodass move() nicht erfolgreich
+ beendet werden konnte. (Bsp: sensitive Objekte)
+
+ ME_DONT_WANT_TO_BE_MOVED
+ Das Objekt moechte nicht bewegt werden.
+
+BEISPIELE
+---------
+::
+
+ o Ein Objekt "gibt sich" dem Spieler:
+
+ move(this_player(), M_GET);
+
+ o Ein Lebewesen wird in die Abenteurergilde teleportiert:
+
+ lv->move("/gilden/abenteurer", M_TPORT);
+
+ o Ein Spieler "wird in die Gilde gegangen":
+
+ this_player()->move("/gilden/abenteurer", M_GO, "in die Gilde");
+
+ Spieler, die mit ihm im gleichen Raum stehen, sehen folgende
+ Meldung:
+ "<name> geht in die Gilde."
+
+ o Ein Spieler schwimmt durchs Meer:
+
+ this_player()->move("meer_xy", M_GO, "nach Norden", "schwimmt",
+ "schwimmt herein");
+
+ Spieler in seinem Startraum sehen "<name> schwimmt nach Norden.",
+ Spieler in seinem Zielraum sehen "<name> schwimmt herein."
+
+SIEHE AUCH
+----------
+::
+
+ move_object(), remove(), setmin, setmmin, setmout, setmmout, review,
+ PreventInsert(), PreventLeave(), PreventInsertLiving(),
+ PreventLeaveLiving(), PreventMove(), NotifyInsert(), NotifyLeave(),
+ NotifyMove(), NotifyRemove(), init(), exit(),
+ P_NO_PLAYERS, P_PARA, /std/thing/moving.c, /std/living/moving.c
+ -----------------------------------------------------------------------
+2015-Jan-19, Arathorn
+
diff --git a/doc/sphinx/lfun/moved_objects.rst b/doc/sphinx/lfun/moved_objects.rst
new file mode 100644
index 0000000..8a3f972
--- /dev/null
+++ b/doc/sphinx/lfun/moved_objects.rst
@@ -0,0 +1,53 @@
+moved_objects()
+===============
+
+FUNKTION
+--------
+::
+
+ public object *moved_objects(void);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion lassen sich die Objekte ermitteln, die das Lebewesen
+ beim letzten Aufruf von drop_objects(L) oder einer aehnlichen Funktion
+ bewegt hat.
+
+RUECKGABEWERT
+-------------
+::
+
+ Array mit den zuletzt bewegten Objekten, oder ein leeres Array, falls
+ keine Objekte auf die Beschreibung des letzten drop_objects() /
+ pick_objects() / put_objects() / give_objects() passten.
+
+BEISPIELE
+---------
+::
+
+ siehe drop_objects() und give_objects()
+
+SIEHE AUCH
+----------
+::
+
+ drop_objects(L), give_objects(L), pick_objects(L), put_objects(L),
+ show_objects(L), NotifyMove(L)
+
+
+Last modified: Thu Aug 28 22:19:26 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/moved_where.rst b/doc/sphinx/lfun/moved_where.rst
new file mode 100644
index 0000000..1d3757f
--- /dev/null
+++ b/doc/sphinx/lfun/moved_where.rst
@@ -0,0 +1,51 @@
+moved_where()
+=============
+
+FUNKTION
+--------
+::
+
+ public object moved_where(void);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Mit dieser Funktion laesst sich ermitteln, wohin das Lebewesen zuletzt
+ mittels put_objects(L) oder give_objects(L) etwas bewegt oder wem es mit
+ show_objects(L) etwas gezeigt hat.
+
+RUECKGABEWERT
+-------------
+::
+
+ Der Container oder das Lebewesen, wohin die Gegenstaende bewegt wurden.
+
+BEISPIEL
+--------
+::
+
+ siehe give_objects()
+
+SIEHE AUCH
+----------
+::
+
+ put_objects(L), give_objects(L), show_objects(L), NotifyInsert(L),
+ P_LAST_CONTENT_CHANGE
+
+
+Last modified: Thu Aug 28 22:16:15 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/muster.rst b/doc/sphinx/lfun/muster.rst
new file mode 100644
index 0000000..a847bcd
--- /dev/null
+++ b/doc/sphinx/lfun/muster.rst
@@ -0,0 +1,41 @@
+muster()
+========
+
+FUNKTION
+--------
+::
+
+ type muster(...)
+
+
+
+ARGUMENTE
+---------
+::
+
+
+
+BESCHREIBUNG
+------------
+::
+
+RUECKGABEWERT
+-------------
+::
+
+
+
+BEMERKUNG
+---------
+::
+
+
+
+BEISPIEL
+--------
+::
+
+SIEHE AUCH
+----------
+::
+
diff --git a/doc/sphinx/lfun/name.rst b/doc/sphinx/lfun/name.rst
new file mode 100644
index 0000000..ff349bc
--- /dev/null
+++ b/doc/sphinx/lfun/name.rst
@@ -0,0 +1,82 @@
+name()
+======
+
+name()|Name()
+
+FUNKTION
+--------
+::
+
+ varargs string name(int casus, int demon);
+ varargs string Name(int casus, int demon);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ casus
+ Der Fall, in dem der Name dekliniert werden soll.
+ demon
+ Gibt an, ob der Name mit bestimmtem oder unbestimmtem Artikel
+ versehen werden soll:
+ + demon = 0: Unbestimmter Artikel.
+ + demon = 1: Bestimmter Artikel.
+ + demon = 2: Finde selbst heraus, ob ein bestimmter oder ein
+ unbestimmter Artikel verwendet werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion ermittelt den Namen des Objektes im gewuenschten Fall
+ und mit dem angegebenen Artikel. Moegliche Werte fuer casus sind in
+ <thing/language.h> definiert. Weiterhin werden auch (falls angegeben)
+ die Namensadjektive dekliniert und in den Namen eingebaut.
+
+ Name() ist ein Alias fuer capitalize(name()), der Artikel wird also
+ gross geschrieben.
+
+RUeCKGABEWERT
+-------------
+::
+
+ String mit dem Namen des Objektes.
+
+BEMERKUNGEN
+-----------
+::
+
+ Falls P_ARTICLE gesetzt ist, werden weder Artikel noch Namensadjektive
+ in den Namen eingebaut.
+
+ Wenn man als casus RAW angibt, wird der Name im Nominativ ohne Artikel
+ und Namensadjektive zurueckgegeben.
+
+BEISPIELE
+---------
+::
+
+ Wenn das Objekt ein Ball mit P_NAME="Ball" und P_NAME_ADJ="klein" ist,
+ so liefern die folgenden Aufrufe die angegebenen Ergebnisse:
+
+ name(WER,0); => "ein kleiner Ball"
+ name(WESSEN,1); => "des kleinen Balls"
+ name(RAW); => "Ball"
+ name(WEM,2); => "einem kleinen Ball" oder "dem kleinen Ball",
+ abhaengig davon, wieviele Baelle gerade da sind.
+
+SIEHE AUCH
+----------
+::
+
+ /std/thing/description.c, Name()
+
+
+Letzte Aenderung: 29.07.2016, Bugfix
+
diff --git a/doc/sphinx/lfun/notify_player_change.rst b/doc/sphinx/lfun/notify_player_change.rst
new file mode 100644
index 0000000..3e81053
--- /dev/null
+++ b/doc/sphinx/lfun/notify_player_change.rst
@@ -0,0 +1,84 @@
+notify_player_change()
+======================
+
+void notify_player_change(string/object who, int rein [, int invis])
+
+FUNKTION
+--------
+::
+
+ void /notify_player_change(object who, int rein)
+ void /std/player/base::notify_player_change(string who, int rein,
+ int invis)
+
+
+
+GERUFEN VON
+-----------
+::
+
+ /std/player/base.c (d.h. alle Spielershells/-Objekte)
+
+ARGUMENTE
+---------
+::
+
+ string who
+ getuid() eines Spielers
+ object who
+ Spieler-Objekt
+ int rein
+ 0 fuer das MUD verlassende, 1 fuer hereinkommende Spieler
+ int invis
+ 1 fuer unsichtbare Spieler (Magier)
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird von Lebewesen fuer hereinkommende und das Spiel
+ verlassende Spieler an verschiedenen Stellen aufgerufen:
+
+
+
+ * in anderen Spielern mit notify_player_change() mit drei Parametern
+ - dies dient fuer die "erwarte"-Funktionalitaet
+ * in der Gilde des Spielern mit zwei Parameter
+ - damit koennen Gilden notwendige Anpassungen vornehmen
+
+ Diese Funktionen werden auch gerufen, wenn Magier "invis -e" bzw.
+ "vis e" benutzen.
+
+BEISPIELE
+---------
+::
+
+ // in einer Gilde:
+ void notify_player_change(object pl, int rein) {
+ if (rein && objectp(pl)) {
+ // Checks, ob Spielerskills in Ordnung sind
+ mapping bete = pl->QuerySkill("bete");
+
+
+
+ if (!mappingp(bete)) {
+ if (IS_LEARNER(pl) || pl->QueryProp(P_TESTPLAYER)) {
+ tell_object(pl, break_string(
+ "Du bist ein kaputter Test-Kleriker ...", 78,
+ "Arkshat teilt dir mit: "));
+ // notduerftige Reparaturen
+ } else
+ raise_error("Klerus: Kaputter oder gesetzer Kleriker!\n");
+ }
+ }
+ }
+
+SIEHE AUCH
+----------
+::
+
+ RegisterEvent mit (EVT_LIB_LOGIN, EVT_LIB_LOGOUT)
+ erwarte
+
+1. Sep 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/obsolete/AddHpHook.rst b/doc/sphinx/lfun/obsolete/AddHpHook.rst
new file mode 100644
index 0000000..d2f09ef
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/AddHpHook.rst
@@ -0,0 +1,52 @@
+AddHpHook()
+===========
+
+********************* OBSOLETE LFUN ***********************************
+* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die *
+* Hooks (s. /doc/std/hooks). *
+***********************************************************************
+AddHpHook()
+
+FUNKTION
+--------
+::
+
+ int AddHpHook(object ob)
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/life.c
+
+ARGUMENTE
+---------
+::
+
+ ob - das Objekt, das sich eintragen moechte.
+
+BESCHREIBUNG
+------------
+::
+
+ Traegt ein Objekt in P_HP_HOOKS ein, wenn es nicht schon darin steht.
+
+ Aendern sich beim Spieler dann HP oder KP (nicht durch Set()), wird
+ an allen eingetragenen Objekten NotifyHpChange() gerufen.
+
+RUECKGABEWERT
+-------------
+::
+
+ 1, wenn Erfolg, 0 sonst
+
+SIEHE AUCH
+----------
+::
+
+ Gegenpart: RemoveHpHook()
+ Props: P_HP_HOOKS, P_HP
+ Verwandt: reduce_hit_points(), do_damage(), buffer_hp()
+
+23.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/obsolete/AddInsertHook.rst b/doc/sphinx/lfun/obsolete/AddInsertHook.rst
new file mode 100644
index 0000000..143efc9
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/AddInsertHook.rst
@@ -0,0 +1,88 @@
+AddInsertHook()
+===============
+
+********************* OBSOLETE LFUN ***********************************
+* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die *
+* Hooks (s. /doc/std/hooks). *
+***********************************************************************
+AddInsertHook()
+
+FUNKTION
+--------
+::
+
+ void AddInsertHook(object ob);
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+ ob - Das Objekt, das informiert werden soll, wenn ein Objekt dem
+ Spielerinventar hinzugefuegt wurde.
+
+BESCHREIBUNG
+------------
+::
+
+ (Diese Funktionalitaet wurde ersetzt durch den allgemeinen Hook
+ H_HOOK_INSERT und ist nur noch aus Gruenden der Kompatibilitaet
+ vorhanden.)
+
+ Diese Funktion wird im Spielerobjekt aufgerufen, um das Objekt ob als
+ Hook-Listener anzumelden. Auf diese Weise eingetragene Listener
+ werden informiert, wenn ein Objekt ins Spielerinventar bewegt wurde.
+ Technisch wird die Bewegung ueber NotifyInsert() im Spielerobjekt
+ detektiert, und im Listener-Objekt wird die Funktion InsertNotify()
+ gerufen, die als Parameter das neu ins Spielerinventar bewegte Objekt
+ uebergeben bekommt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEMERKUNGEN
+-----------
+::
+
+ Das Listener-Objekt muss sich ebenfalls im Spielerinventar befinden,
+ ansonsten wird der eingetragene Hook wieder geloescht.
+
+BEISPIEL
+--------
+::
+
+
+
+ a) Objekt "ob" wird im Spieler als Listener angemeldet:
+ this_player()->AddInsertHook(ob);
+
+ b) Objekt "new" wird ins Spielerinventar bewegt, das Spielerobjekt
+ informiert "ob" darueber:
+ ob->InsertNotify(new);
+
+ c) Das Listener-Objekt "ob" reagiert darauf, z.B. indem es die Fackel
+ loescht, sofern sie vorher brannte:
+ void InsertNotify(object new) {
+ if ( objectp(new) && new->id("\nfackel") &&
+ new->QueryProp(P_LIGHTED) )
+ new->unlight();
+ return;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ NotifyInsert(), RemoveInsertHook(), QueryInsertHooks()
+
+
+Last modified: 14.04.2010, Arathorn
+
diff --git a/doc/sphinx/lfun/obsolete/ModifySkillAttributeOld.rst b/doc/sphinx/lfun/obsolete/ModifySkillAttributeOld.rst
new file mode 100644
index 0000000..948a6d9
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/ModifySkillAttributeOld.rst
@@ -0,0 +1,119 @@
+ModifySkillAttributeOld()
+=========================
+
+FUNKTION
+--------
+::
+
+ varargs int ModifySkillAttributeOld(object caster, string atrname,
+ int value, int duration, mixed fun)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/skill_attributes.c
+
+ARGUMENTE
+---------
+::
+
+ <caster> IGNORIERT
+ frueher Objekt, das die Modifikation vornimmt, heute ist
+ dieses Argument ohne Bedeutung und wird ignoriert.
+
+ <atrname> STRING
+ Name des zu veraendernden Attributes
+ (Definiert in /sys/living/skill_attributes.h)
+
+ <value> INT
+ Neuer Wert des Attributs (Standard: 100)
+
+ <duration> INT
+ Dauer in Sekunden
+
+ <fun> NICHT MEHR UNTERSTUETZT - ModifySkillAttribute() nutzen!!
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion existiert nur aus Kompatibilitaetsgruenden. Bitte in neuen
+ Objekten NICHT mehr verwenden und in alten nach Moeglichkeit ausbauen!
+
+ Aendert ein Skill-Attribut eines Living.
+
+
+
+ Fuer <value> ist folgendes zu beachten:
+ Frueher handelte es sich um einen multiplikativen Faktor. 100 hatte die
+ Bedeutung von 1 und veraenderte nichts. Heute sind die Modifikatoren
+ additiv. Diese Funktion macht eine einfache Umrechnung, indem sie vom hier
+ uebergeben Wert 100 abzieht. (In der Annahme, dass frueher meist eh nur
+ ein Modifikator zur gleichen Zeit aktiv war.)
+ Gibt man hier also hier eine 100 an, wird ein Modifikator von 0 einge-
+ tragen, der nichts aendert, bei 200 wird ein Modifikator von 100 einge-
+ tragen, bei 50 einer von -50, welcher das Skillattribute folglich
+ reduziert.
+
+ Es sind momentan max. 5 gleichzeitige Skillattribute-Modifikatoren pro SA
+ zulaessig.
+
+RUECKGABEWERT
+-------------
+::
+
+ 0 wenn der Wert ungueltig ist oder aus sonstigem Grunde nicht gesetzt
+ werden konnte (fuer bessere Diagnostik -> ModifySkillAttribute()).
+ >0 wenn alles okay war
+
+BEMERKUNGEN
+-----------
+::
+
+ Frueher musste ein setzendes Objekt ein groesseres P_LEVEL haben als das
+ Objekt, welches einen vorherigen Modifikator gesetzt hat, um diesen zu
+ ueberschreiben. Dies ist inzwischen ohne Bedeutung.
+
+BEISPIELE
+---------
+::
+
+ Ein NPC:
+
+ void
+ create() {
+ .
+ .
+ .
+ AddSpell(1, 1,
+ "Der fuerchterliche NPC haut Dir auf den Kopf.\n",
+ "Der fuerchterliche NPC haut @WEN auf den Kopf.\n",
+ DT_MAGIC, "schwaechen");
+ .
+ .
+ }
+
+ schwaechen(object enemy, int damage, mixed *dam_type) {
+ int ergebnis;
+ ergebnis = enemy->ModifySkillAttributeOld(this_object(), SA_QUALITY, 50, 5);
+ if (ergebnis > 0)
+ tell_object(enenmy, "Du fuehlst Dich ganz schwach.\n");
+ }
+
+
+
+ Der NPC schwaecht seinen Gegner erheblich! Alles wird fuer 5 Sekunden um
+ 50, d.h. 0.5 Skillattribute reduziert (50 - 100 => -50 als Modifikator).
+
+SIEHE AUCH
+----------
+::
+
+ P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS,
+ ModifySkillAttribute, QuerySkillAttribute(),
+ RemoveSkillAttributeModifer(), QuerySkillAttributeModifier()
+
+
+07.08.2008 Zesstra
+
diff --git a/doc/sphinx/lfun/obsolete/NotifyGiveQuest.rst b/doc/sphinx/lfun/obsolete/NotifyGiveQuest.rst
new file mode 100644
index 0000000..64a1f9d
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/NotifyGiveQuest.rst
@@ -0,0 +1,74 @@
+NotifyGiveQuest()
+=================
+
+********************* OBSOLETE LFUN ***********************************
+* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die *
+* Events (siehe "man events"). *
+***********************************************************************
+
+NotifyGiveQuest()
+
+FUNKTION
+--------
+::
+
+ void NotifyGiveQuest(object pl, string key);
+
+
+
+DEFINIERT IN
+------------
+::
+
+ /std/gilden_ob.c
+
+
+
+ARGUMENTE
+---------
+::
+
+ pl Der Spieler, der eine Quest geloest hat.
+ key Name der geloesten Quest.
+
+
+
+BESCHREIBUNG
+------------
+::
+
+ Die Funktion wird in der Gilde des Spielers aufgerufen, wenn der
+ Spieler eine gueltige Quest besteht - und zwar unabhaengig davon,
+ ob er sie bereits geloest hat, oder nicht.
+
+
+
+RUECKGABEWERT
+-------------
+::
+
+ keiner
+
+
+
+BEMERKUNGEN
+-----------
+::
+
+ Die Funktion ist dafuer gedacht, von Gildenprogrammierern ueberschrieben
+ zu werden, wenn beispielsweise bestimmte Quests als Aufstiegsbedingung
+ verlangt werden, diese aber in der entsprechenden Gilde geloest sein
+ muessen (z.B. Obergladiator als Level-5-Zauberer).
+
+
+
+SIEHE AUCH
+----------
+::
+
+ /std/gilden_ob.c
+ /std/player/quests.c
+
+
+Last modified: Fri Oct 4 10:17:00 1996 by Silvana
+
diff --git a/doc/sphinx/lfun/obsolete/NotifyHpChange.rst b/doc/sphinx/lfun/obsolete/NotifyHpChange.rst
new file mode 100644
index 0000000..21c4ca3
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/NotifyHpChange.rst
@@ -0,0 +1,72 @@
+NotifyHpChange()
+================
+
+********************* OBSOLETE LFUN ***********************************
+* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die *
+* Hooks (s. /doc/std/hooks). *
+***********************************************************************
+NotifyHpChange()
+
+FUNKTION
+--------
+::
+
+ void NotifyHpChange();
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/life.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Wenn sich die Lebenspunkte eines Spielers aendern, so werden davon
+ auch andere Objekte unterrichtet, sofern diese mittels der Funktion
+ AddHpHook() bei eben diesem Spieler angemeldet wurden.
+ Fortan wird dann die Funktion NotifyHpChange() in diesen
+ angemeldeten Objekten aufgerufen, wenn sich die Property P_HP des
+ Spielers aendert. Es werden hierbei keine Argumente an
+ NotifyHpChange() uebergeben, die aktuellen Lebenspunkte kann man ja
+ auch ohne weiteres ueber die Property P_HP in Erfahrung bringen und
+ aeltere Werte muss man sich gesondert merken. Zu beachten ist, dass
+ die Property P_HP bei Aufruf der Funktion NotifyHpChange() bereits
+ den neuen Wert enthaelt.
+ Bei dem Spieler angemeldete Objekte, die von Lebenspunkteaenderungen
+ informiert werden sollen, werden automatisch aus der Liste entfernt,
+ wenn sie zerstoert wurden. Diese Liste ist in der Property
+ P_HP_HOOKS zu finden. Per Hand kann man sie auch explizit mittels
+ der Funktion RemoveHpHook() entfernen.
+ Stirbt ein Spieler, so wird die Funktion NotifyPlayerDeath()
+ aufgerufen und nicht NotifyHpChange()!
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEISPIELE
+---------
+::
+
+ ist in Arbeit
+
+SIEHE AUCH
+----------
+::
+
+ P_HP, P_HP_HOOKS, AddHpHook(), RemoveHpHook(),
+ Defend(), do_damage(), NotifyPlayerDeath()
+
+
+Last modified: Thu Nov 19 13:54:33 1998 by Patryn
+
diff --git a/doc/sphinx/lfun/obsolete/QueryEnemy.rst b/doc/sphinx/lfun/obsolete/QueryEnemy.rst
new file mode 100644
index 0000000..14c989a
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/QueryEnemy.rst
@@ -0,0 +1,50 @@
+QueryEnemy()
+============
+
+********************* OBSOLETE LFUN ***********************************
+
+FUNKTION
+--------
+::
+
+ object QueryEnemy();
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/combat.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+RUeCKGABEWERT
+-------------
+::
+
+ gefundener Gegner
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert zufaellig einen der anwesenden Gegner
+ zurueck, sofern keine Gegner bevorzugt ausgewaehlt werden.
+
+BEMERKUNGEN
+-----------
+::
+
+ Diese Lfun existiert nicht mehr. Bitte SelectEnemy() benutzen.
+
+SIEHE AUCH
+----------
+::
+
+ SelectEnemy(), QueryPreferedEnemy(), P_PREFERED_ENEMY
+
+07.02.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/obsolete/QueryInsertHooks.rst b/doc/sphinx/lfun/obsolete/QueryInsertHooks.rst
new file mode 100644
index 0000000..b488589
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/QueryInsertHooks.rst
@@ -0,0 +1,53 @@
+QueryInsertHooks()
+==================
+
+********************* OBSOLETE LFUN ***********************************
+* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die *
+* Hooks (s. /doc/std/hooks). *
+***********************************************************************
+QueryInsertHooks()
+
+FUNKTION
+--------
+::
+
+ object *QueryInsertHooks();
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ (Diese Funktionalitaet wurde ersetzt durch den allgemeinen Hook
+ H_HOOK_INSERT und ist nur noch aus Gruenden der Kompatibilitaet
+ vorhanden.)
+
+ Diese Funktion gibt die aktuell beim Spielerobjekt angemeldeten
+ Listener-Objekte zurueck.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Array aus Objektpointern oder leeres Array
+
+SIEHE AUCH
+----------
+::
+
+ NotifyInsert(), AddInsertHook(), RemoveInsertHook()
+
+
+Last modified: 14.04.2010, Arathorn
+
diff --git a/doc/sphinx/lfun/obsolete/QueryOptQP.rst b/doc/sphinx/lfun/obsolete/QueryOptQP.rst
new file mode 100644
index 0000000..50e8ca8
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/QueryOptQP.rst
@@ -0,0 +1,44 @@
+QueryOptQP()
+============
+
+FUNKTION
+--------
+::
+
+ int QueryOptQP()
+
+DEFINIERT IN
+------------
+::
+
+ /secure/questmaster.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+RUECKGABEWERT
+-------------
+::
+
+ Abenteuerpunkte der optionalen Quests
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion liefert die Abenteuerpunkte der optionalen
+ Abenteuer zurueck.
+
+SIEHE AUCH
+----------
+::
+
+ GiveQuest, QueryQuest, /secure/questmaster.h, QueryGroupedKeys,
+ QueryMaxQP, QueryTotalQP
+
+
+Zuletzt geaendert: Sam, 25. Nov 2000, 14:04:28 von Zook.
+
diff --git a/doc/sphinx/lfun/obsolete/RemoveHpHook.rst b/doc/sphinx/lfun/obsolete/RemoveHpHook.rst
new file mode 100644
index 0000000..0ce24fd
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/RemoveHpHook.rst
@@ -0,0 +1,48 @@
+RemoveHpHook()
+==============
+
+********************* OBSOLETE LFUN ***********************************
+* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die *
+* Hooks (s. /doc/std/hooks). *
+***********************************************************************
+RemoveHpHook()
+
+FUNKTION
+--------
+::
+
+ int RemoveHpHook(object ob)
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/life.c
+
+ARGUMENTE
+---------
+::
+
+ ob - das Objekt, das sich austragen moechte.
+
+BESCHREIBUNG
+------------
+::
+
+ Entfernt den Eintrag fuer dieses Objekt in P_HP_HOOKS.
+
+RUECKGABEWERT
+-------------
+::
+
+ 1, wenn Erfolg, 0 sonst
+
+SIEHE AUCH
+----------
+::
+
+ Gegenpart: AddHpHook()
+ Props: P_HP_HOOKS, P_HP
+
+23.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/obsolete/RemoveInsertHook.rst b/doc/sphinx/lfun/obsolete/RemoveInsertHook.rst
new file mode 100644
index 0000000..682e5c5
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/RemoveInsertHook.rst
@@ -0,0 +1,53 @@
+RemoveInsertHook()
+==================
+
+********************* OBSOLETE LFUN ***********************************
+* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die *
+* Hooks (s. /doc/std/hooks). *
+***********************************************************************
+RemoveInsertHook()
+
+FUNKTION
+--------
+::
+
+ void RemoveInsertHook(object ob);
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+ ob - Das Objekt, das als Listener aus der Liste ausgetragen werden soll
+
+BESCHREIBUNG
+------------
+::
+
+ (Diese Funktionalitaet wurde ersetzt durch den allgemeinen Hook
+ H_HOOK_INSERT und ist nur noch aus Gruenden der Kompatibilitaet
+ vorhanden.)
+
+ Diese Funktion wird im Spielerobjekt aufgerufen, um ein als Listener
+ eingetragenes Hook-Objekt ob wieder auszutragen.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+SIEHE AUCH
+----------
+::
+
+ NotifyInsert(), AddInsertHook(), QueryInsertHooks()
+
+
+Last modified: 14.04.2010, Arathorn
+
diff --git a/doc/sphinx/lfun/obsolete/TestAttributeLock.rst b/doc/sphinx/lfun/obsolete/TestAttributeLock.rst
new file mode 100644
index 0000000..7aa6123
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/TestAttributeLock.rst
@@ -0,0 +1,47 @@
+TestAttributeLock()
+===================
+
+********************* OBSOLETE LFUN ***********************************
+TestAttributeLock()
+
+FUNKTION
+--------
+::
+
+ string TestAttributeLock(mapping check)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/attributes.c
+
+PARAMETER
+---------
+::
+
+ check - Mapping mit Attributen: ([<attr>:<wert>])
+
+BESCHREIBUNG
+------------
+::
+
+ Prueft, ob eines der im Mapping enthaltenen Attribute blockiert
+ ist (bereits durch einen anderen Modifier belegt wurde).
+
+
+
+ Da Modifier nicht mehr direkt blockieren ist diese Funktion obsolet
+ und in Livings inzwischen nicht mehr existent.
+
+SIEHE AUCH
+----------
+::
+
+ QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+ SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+ P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
+ P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+11.05.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/obsolete/extra_look.rst b/doc/sphinx/lfun/obsolete/extra_look.rst
new file mode 100644
index 0000000..1e4db82
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/extra_look.rst
@@ -0,0 +1,32 @@
+extra_look()
+============
+
+********************* VERALTETE LFUN ******************************
+* Diese LFUN ist veraltet. Bitte benutzt sie NICHT mehr, sondern *
+* stattdessden AddExtraLook(). *
+*******************************************************************
+
+extra_look()
+
+FUNKTION
+--------
+::
+
+ string extra_look();
+
+BESCHREIBUNG
+------------
+::
+
+ Kann in Objekt definiert sein. Wenn ein Living (std/living/description)
+ das Objekt enthaelt, wird zu dessen long() der zurueckgegebene String
+ hinzugefuegt.
+
+SIEHE AUCH
+----------
+::
+
+ AddExtraLook()
+
+25.Jan 2015 Gloinson
+
diff --git a/doc/sphinx/lfun/obsolete/paramove.rst b/doc/sphinx/lfun/obsolete/paramove.rst
new file mode 100644
index 0000000..0d14d85
--- /dev/null
+++ b/doc/sphinx/lfun/obsolete/paramove.rst
@@ -0,0 +1,73 @@
+paramove()
+==========
+
+****************************************************************************
+************************* VERALTETE LFUN ***********************************
+************************* DO NOT USE! ***********************************
+****************************************************************************
+paramove()
+
+FUNKTION
+--------
+::
+
+ int paramove();
+
+DEFINIERT IN
+------------
+::
+
+ /std/room/para.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Bewegt den Spieler ggf. in eine Paralleldimension.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn der Spieler die Dimension gewechselt hat.
+
+BEISPIEL
+--------
+::
+
+ init(){
+ if(!paramove()) ::init();
+ }
+
+BEMERKUNGEN
+-----------
+::
+
+ DIESE FUNKTION NICHT MEHR BENUTZEN!
+
+ Diese Funktion sollte nur aus einem init() aufgerufen werden!
+
+ Fuer die Entscheidung, in welchem Raum ein Spieler in Abhaengigkeit
+ von P_PARA landet, ist die Funktion move() zustaendig. Als Magier
+ muss man sich darum nicht gesondert kuemmern. Das heisst aber auch,
+ dass beim Anschluss eines Normalweltraumes automatisch alle in dem
+ Verzeichnis mit gleichem Namen vorhandenen Parallelweltraeume mit
+ angeschlossen werden.
+
+ Deswegen ist paramove() veraltet und sollte nicht mehr genutzt werden.
+
+SIEHE AUCH
+----------
+::
+
+ /std/room/para.c, P_PARA, P_NO_PLAYERS, move
+
+
+Last modified: 05.08.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/pick.rst b/doc/sphinx/lfun/pick.rst
new file mode 100644
index 0000000..85d576d
--- /dev/null
+++ b/doc/sphinx/lfun/pick.rst
@@ -0,0 +1,74 @@
+pick()
+======
+
+FUNKTION
+--------
+::
+
+ public varargs int pick(object o, mixed msg);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ object o
+ Das Objekt, das aufgehoben werden soll.
+ mixed msg
+ Eine optionale Meldung, die anstelle von P_PICK_MSG oder der
+ Standardmeldung verwendet wird, oder -1, um die Meldung zu
+ unterdruecken.
+
+BESCHREIBUNG
+------------
+::
+
+ Der Spieler oder NPC nimmt das Objekt auf. Gibt o->move() keinen positiven
+ Wert zurueck, beispielsweise weil das Objekt zu schwer ist oder nicht
+ genommen werden darf, bekommt er eine entsprechende Fehlermeldung.
+
+RUECKGABEWERT
+-------------
+::
+
+ Wenn das Aufnehmen geklappt hat, 1, ansonsten 0.
+
+BEMERKUNG
+---------
+::
+
+ Diese Funktion ist dann sinnvoll, wenn man den Spieler ein Objekt
+ aufnehmen lassen und sich nicht selbst um die Fehlerbehandlung kuemmern
+ moechte - und da unzaehlige verschiedene Dinge schiefgehen koennen und
+ manche Objekte eigene Fehlermeldungen definieren, eigentlich immer.
+
+ Die Funktion prueft nicht, ob sich das Objekt ueberhaupt in der Reichweite
+ des Spielers/NPC befindet, das muss man ggf. selbst ermitteln.
+
+BEISPIEL
+--------
+::
+
+ ob = clone_object(WEINGUMMI);
+
+ if (this_player()->pick(ob, ({ "Du nimmst @WENU2 aus dem Regal.",
+ "@WER1 nimmt @WENU2 aus dem Regal." })))
+ weingummi--;
+ else
+ ob->remove();
+
+SIEHE AUCH
+----------
+::
+
+ move(L), P_PICK_MSG, pick_objects(L), P_NOINSERT_MSG, P_NOLEAVE_MSG,
+ P_TOO_MANY_MSG, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NOGET
+
+
+Last modified: Thu Aug 28 22:21:41 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/pick_obj.rst b/doc/sphinx/lfun/pick_obj.rst
new file mode 100644
index 0000000..84aa6cf
--- /dev/null
+++ b/doc/sphinx/lfun/pick_obj.rst
@@ -0,0 +1,43 @@
+pick_obj()
+==========
+
+FUNKTION
+--------
+::
+
+ int pick_obj(object ob)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ ob Das Objekt, das genommen werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Das Lebewesen, in dem diese Funktion aufgerufen werden soll, hebt
+ den angegebenen Gegenstand (ob) auf, falls es ihm moeglich ist.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn das Objekt genommen wurde oder dies nicht moeglich war. (in diesem
+ Fall wird auch direkt eine Textausgabe ausgegeben)
+ 0 sonst, in diesem Fall wird in notify_fail eine passende Ausgabe
+ plaziert
+
+SIEHE AUCH
+----------
+::
+
+ drop_obj(), find_obs(), give_obj(), put_obj(), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/lfun/pick_objects.rst b/doc/sphinx/lfun/pick_objects.rst
new file mode 100644
index 0000000..77979df
--- /dev/null
+++ b/doc/sphinx/lfun/pick_objects.rst
@@ -0,0 +1,62 @@
+pick_objects()
+==============
+
+FUNKTION
+--------
+::
+
+ public varargs int pick_objects(string str, int flag, mixed msg);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ string str
+ Was aufgehoben werden soll.
+ int flag
+ Muss das Objekt irgendwo drinstecken (flag = 1), oder darf es einfach
+ so herumliegen (flag = 0)? Dieses Argument ist hauptsaechlich fuer das
+ Kommando "hole" gedacht, in der Regel braucht man es nicht anzugeben.
+ mixed msg
+ Eine optionale Meldung, die anstelle von P_PICK_MSG oder der
+ Standardmeldung verwendet wird, oder -1, um die Meldung zu
+ unterdruecken.
+
+BESCHREIBUNG
+------------
+::
+
+ Der Spieler oder NPC nimmt die in <str> benannten Sachen. Kann er ein
+ Objekt nicht nehmen, bekommt er eine entsprechende Fehlermeldung. Wenn
+ keine Objekte auf <str> passen, wird per _notify_fail() eine Meldung
+ gesetzt, aber noch nicht ausgegeben.
+
+RUECKGABEWERT
+-------------
+::
+
+ Wenn <str> irgendwelche vorhandenen Sachen sind, 1, sonst 0.
+
+BEMERKUNG
+---------
+::
+
+ Wenn die Funktion 1 zurueckgibt, heisst das noch nicht, dass der Spieler
+ etwas genommen hat! Er hat es nur versucht, d.h. auf jeden Fall eine
+ Meldung bekommen. Gibt die Funktion 0 zurueck, hat er noch keine bekommen.
+
+SIEHE AUCH
+----------
+::
+
+ move(L), pick(L), P_PICK_MSG, find_objects(L), moved_objects(L)
+
+
+Last modified: Fri Jul 25 10:58:43 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/present_objects.rst b/doc/sphinx/lfun/present_objects.rst
new file mode 100644
index 0000000..4375fe5
--- /dev/null
+++ b/doc/sphinx/lfun/present_objects.rst
@@ -0,0 +1,51 @@
+present_objects()
+=================
+
+FUNKTION
+--------
+::
+
+ object *present_objects(string desc);
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+ desc
+ Umschreibung des gesuchten Objektes oder "alles" oder "alle".
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion gibt die Objekte im Inneren des Behaelters zurueck, die
+ sich mit desc ansprechen lassen. In dem Fall, dass "alle(s)"
+ angefordert wird, sind das alle sichtbaren Objekte, ansonsten das erste
+ Objekt, das sich mit desc ansprechen laesst.
+ Objekte, die P_INVIS gesetzt haben, zaehlen als nicht ansprechbar, im
+ Gegensatz zu solchen Objekten, die keine P_SHORT haben.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Ein Array von Objekten mit den geforderten Eigenschaften.
+
+ Befindet sich kein Objekt im Behaelter, das sich durch desc ansprechen
+ laesst, so wird ein leeres Array zurueckgegeben.
+
+SIEHE AUCH
+----------
+::
+
+ locate_objects(), /std/container/restrictions.c
+
+
+03.03.2013, Zesstra
+
diff --git a/doc/sphinx/lfun/put.rst b/doc/sphinx/lfun/put.rst
new file mode 100644
index 0000000..dee5817
--- /dev/null
+++ b/doc/sphinx/lfun/put.rst
@@ -0,0 +1,66 @@
+put()
+=====
+
+FUNKTION
+--------
+::
+
+ public varargs int put(object o, object dest, mixed msg);
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ object o
+ Das Objekt, das irgendwo hingesteckt werden soll.
+ object dest
+ Der Behaelter, in den das Objekt gesteckt werden soll.
+ mixed msg
+ Eine optionale Meldung, die anstelle von P_PUT_MSG oder der
+ Standardmeldung verwendet wird, oder -1, um die Meldung zu
+ unterdruecken.
+
+BESCHREIBUNG
+------------
+::
+
+ Der Spieler oder NPC steckt das Objekt in einen Behaelter. Gibt o->move()
+ keinen positiven Wert zurueck, beispielsweise weil er das Objekt nicht
+ weggeben darf oder der Behaelter schon voll ist, bekommt er eine
+ entsprechende Fehlermeldung.
+
+RUECKGABEWERT
+-------------
+::
+
+ Wenn das Bewegen geklappt hat, 1, ansonsten 0.
+
+BEMERKUNG
+---------
+::
+
+ Diese Funktion ist dann sinnvoll, wenn man den Spieler ein Objekt irgendwo
+ hinstecken lassen und sich nicht selbst um die Fehlerbehandlung kuemmern
+ moechte - und da unzaehlige verschiedene Dinge schiefgehen koennen und
+ manche Objekte eigene Fehlermeldungen definieren, eigentlich immer.
+
+ Die Funktion prueft nicht, ob sich das Objekt und der Behaelter ueberhaupt
+ in der Reichweite des Spielers/NPC befinden, das muss man ggf. selbst
+ ermitteln.
+
+SIEHE AUCH
+----------
+::
+
+ move(L), P_PUT_MSG, put_objects(L), P_NOINSERT_MSG, P_NOLEAVE_MSG,
+ P_TOO_MANY_MSG, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NOGET, P_NODROP
+
+
+Last modified: Thu Aug 28 22:21:58 2008 by Amynthor
+
diff --git a/doc/sphinx/lfun/put_obj.rst b/doc/sphinx/lfun/put_obj.rst
new file mode 100644
index 0000000..9887173
--- /dev/null
+++ b/doc/sphinx/lfun/put_obj.rst
@@ -0,0 +1,46 @@
+put_obj()
+=========
+
+FUNKTION
+--------
+::
+
+ int put_obj(object ob, object where)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ ob Das Objekt, das irgendwo hineingelegt werden soll.
+ where Das (tote) Objekt, in das etwas hineingelegt werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Das Lebewesen, in dem diese Funktion aufgerufen werden soll, legt
+ den angegebenen Gegenstand (ob) in das angegebene Zielobjekt (where).
+ Dabei sollte es sich bei where um einen Container/Raum handeln.
+ Ist where ein Lebewesen, verwendet man besser give_obj().
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn das Objekt weggelegt wurde oder dies nicht moeglich war. (in diesem
+ Fall wird auch direkt eine Textausgabe ausgegeben)
+ 0 sonst, in diesem Fall wird in notify_fail eine passende Ausgabe
+ plaziert
+
+SIEHE AUCH
+----------
+::
+
+ drop_obj(), find_obs(), give_obj(), pick_obj(), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/lfun/query_prevent_shadow.rst b/doc/sphinx/lfun/query_prevent_shadow.rst
new file mode 100644
index 0000000..ebeb46a
--- /dev/null
+++ b/doc/sphinx/lfun/query_prevent_shadow.rst
@@ -0,0 +1,54 @@
+query_prevent_shadow()
+======================
+
+query_prevent_shadow(L)
+
+FUNKTION
+--------
+::
+
+ varargs int query_prevent_shadow(object shadower)
+
+PARAMETER
+---------
+::
+
+ object shadower - da Objekt, das eine Beschattung beantragt
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Methode kann in Objekten definiert werden, die nicht beschattet
+ werden wollen oder anhand des Objektes shadower entscheiden wollen ob
+ sie beschattet werden wollen.
+
+ Gibt die Funktion 0 zurueck, wird ein Shadow auf das Objekt erlaubt,
+ sonst schlaegt es fehl.
+
+BEISPIEL
+--------
+::
+
+ // generell keine Beschattung
+ int query_prevent_shadow(object who) {
+ return 1;
+ }
+
+ // Beschattung durch offizielle Objekte erlaubt
+ int query_prevent_shadow(object who) {
+ if(who && !strstr(object_name(who),"/std/player"))
+ return 0;
+ return 1;
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Rechte: query_allow_shadow(M)
+ Generell: shadow(E), unshadow(E)
+ Informationen: query_shadowing(E)
+
+20. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/lfun/query_real_name.rst b/doc/sphinx/lfun/query_real_name.rst
new file mode 100644
index 0000000..dbc5651
--- /dev/null
+++ b/doc/sphinx/lfun/query_real_name.rst
@@ -0,0 +1,26 @@
+query_real_name()
+=================
+
+SYNOPSIS
+--------
+::
+
+ string query_real_name(void)
+
+DESCRIPTION
+-----------
+::
+
+ The result of this_player()->query_real_name() is used as
+ default argument for the efun wizlist().
+
+ If LOG_SHOUT was #defined in the parser at compile time, the
+ efun shout will use query_real_name() to log the shouter's
+ name.
+
+SEE ALSO
+--------
+::
+
+ shout(E), wizlist(E)
+
diff --git a/doc/sphinx/lfun/query_weight_contents.rst b/doc/sphinx/lfun/query_weight_contents.rst
new file mode 100644
index 0000000..8446e1b
--- /dev/null
+++ b/doc/sphinx/lfun/query_weight_contents.rst
@@ -0,0 +1,37 @@
+query_weight_contents()
+=======================
+
+FUNKTION
+--------
+::
+
+ int query_weight_contents()
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/restrictions.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt das Gewicht des Inhaltes des Behaelters zurueck (ohne
+ Beruecksichtigung von P_WEIGHT_PERCENT!)
+
+RUeCKGABEWERT
+-------------
+::
+
+ Das Gewicht des Behaelterinhaltes.
+
+
+Last modified: Wed May 8 10:23:32 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/reduce_hit_points.rst b/doc/sphinx/lfun/reduce_hit_points.rst
new file mode 100644
index 0000000..790b078
--- /dev/null
+++ b/doc/sphinx/lfun/reduce_hit_points.rst
@@ -0,0 +1,70 @@
+reduce_hit_points()
+===================
+
+FUNKTION
+--------
+::
+
+ int reduce_hit_points(int damage)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ int damage - der zugefuegte Schaden
+
+BESCHREIBUNG
+------------
+::
+
+ Dem Lebewesen werden damage Lebenspunkte abgezogen, aber der
+ Wert wird hinterher nicht kleiner als 1 sein und das Lebewesen
+ wird dadurch nicht sterben.
+
+RUECKGABEWERT
+-------------
+::
+
+ Die verbleibenden Lebenspunkte.
+
+BEISPIELE
+---------
+::
+
+ write("Ploetzlich schiesst eine scheussliche Kreatur aus der Pfuetze "+
+ "heraus und\nbeisst Dich ins Bein, sie verschwindet so schnell, "+
+ "wie sie gekommen ist.\n");
+ this_player()->reduce_hit_points(50);
+ (Auszug aus /players/boing/friedhof/room/cat1x9)
+
+BEMERKUNGEN
+-----------
+::
+
+ damage kann auch ein negativer Wert sein, dann werden dem Lebewesen
+ diese Lebenspunkte gutgeschrieben und auf die aktuellen Lebenspunkte
+ addiert. Da dies eine Form der Heilung ist, nur nach Ruecksprache mit
+ dem Regionsmagier verwenden.
+
+ Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
+ dafuer eingerichteten Funktion check_and_update_timed_key realisiert
+ werden.
+
+SIEHE AUCH
+----------
+::
+
+ Gegenpart: restore_hit_points()
+ Verwandt: do_damage(), Defend(), reduce_spell_points()
+ Props: P_HP
+ Konzept: heilung
+
+
+Last modified: Sat Dec 13 01:00:47 1999 by Tilly
+
diff --git a/doc/sphinx/lfun/reduce_spell_points.rst b/doc/sphinx/lfun/reduce_spell_points.rst
new file mode 100644
index 0000000..68c3f58
--- /dev/null
+++ b/doc/sphinx/lfun/reduce_spell_points.rst
@@ -0,0 +1,48 @@
+reduce_spell_points()
+=====================
+
+FUNKTION
+--------
+::
+
+ void reduce_spell_points(int points)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/life.c
+
+ARGUMENTE
+---------
+::
+
+ points: Anzahl der Konzentrationspunkte die abgezogen werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+ Dem Lebewesen werden points Konzentrationspunkte abgezogen. Falls
+ das Lebewesen weniger Konzentrationspunkte hat, als abgezogen werden
+ sollen, werden sie auf 0 gesetzt.
+
+BEISPIELE
+---------
+::
+
+ write("Das boese boese Monster schaut Dich grimmig an und labt sich an "
+ +"Deiner Konzentration.\n");
+ this_player()->reduce_spell_points(50);
+
+SIEHE AUCH
+----------
+::
+
+ Gegenpart: restore_spell_points(L)
+ Verwandt: reduce_hit_points(L), buffer_sp(L)
+ Props: P_SP
+ Konzept: heilung
+
+23.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/register_modifier.rst b/doc/sphinx/lfun/register_modifier.rst
new file mode 100644
index 0000000..9d95145
--- /dev/null
+++ b/doc/sphinx/lfun/register_modifier.rst
@@ -0,0 +1,42 @@
+register_modifier()
+===================
+
+FUNKTION
+--------
+::
+
+ void register_modifier(object modifier)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/attributes.c
+
+PARAMETER
+---------
+::
+
+ modifier - Objekt mit P_X_ATTR_MOD oder P_M_ATTR_MOD
+
+BESCHREIBUNG
+------------
+::
+
+ Registriert einen Modifier im Spieler. Wird durch InsertSensitiveObject
+ beziehungsweise beim Anziehen oder Zuecken gerufen.
+ Muss nicht direkt gerufen werden. Bei Veraenderungen von Modifikatoren
+ sollte stattdessen UpdateAttributes gerufen werden.
+
+SIEHE AUCH
+----------
+::
+
+ QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+ SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+ deregister_modifier(), P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS,
+ P_ATTRIBUTES_MODIFIER,P_X_ATTR_MOD, P_M_ATTR_MOD,
+ /std/living/attributes.c
+
+13.Jun.2004, Muadib
+
diff --git a/doc/sphinx/lfun/remove.rst b/doc/sphinx/lfun/remove.rst
new file mode 100644
index 0000000..8d3e313
--- /dev/null
+++ b/doc/sphinx/lfun/remove.rst
@@ -0,0 +1,57 @@
+remove()
+========
+
+FUNKTION
+--------
+::
+
+ varargs int remove(int silent);
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/moving.c
+ /std/living/moving.c
+ /std/room/moving.c
+
+ARGUMENTE
+---------
+::
+
+ silent
+ Falls ungleich 0, so werden beim Zerstoeren keine Meldungen
+ ausgegeben.
+
+BESCHREIBUNG
+------------
+::
+
+ Beim Aufruf dieser Funktion entfernt sich das Objekt selbst. Durch
+ Ueberladen dieser Funktion kann man diesen Vorgang noch durch die
+ Ausgabe von Meldungen kommentieren, oder irgendwelche Daten
+ abspeichern, oder das Zerstoeren ganz verhindern (auf diesem Weg... Mit
+ destruct() kann das Objekt immer noch direkt zerstoert werden!)
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn sich das Objekt erfolgreich selbst zerstoert hat, sonst 0.
+
+BEMERKUNGEN
+-----------
+::
+
+ Nach einem erfolgreichen ::remove() gelten die selben Einschraenkungen
+ wie nach einem destruct()!
+
+SIEHE AUCH
+----------
+::
+
+ destruct()
+
+
+Last modified: Wed May 8 10:23:40 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/remove_multiple.rst b/doc/sphinx/lfun/remove_multiple.rst
new file mode 100644
index 0000000..e24b6ac
--- /dev/null
+++ b/doc/sphinx/lfun/remove_multiple.rst
@@ -0,0 +1,86 @@
+remove_multiple()
+=================
+
+FUNKTION
+--------
+::
+
+ public varargs int remove_multiple(int limit, mixed fun);
+
+DEFINIERT IN
+------------
+::
+
+ /std/container/items.c
+
+ARGUMENTE
+---------
+::
+
+ limit: Anzahl gleicher Objekte, die verbleiben sollen.
+ fun: Funktionsname (string) oder Closure.
+
+BESCHREIBUNG
+------------
+::
+
+ Wird diese Funktion aufgerufen, werden alle gleichen Objekte
+ (standardmaessig definiert als gleicher Ladename, gleiche
+ Kurzbeschreibung und gleiche Langbeschreibung), deren Anzahl <limit>
+ ueberschreitet, entfernt.
+
+
+
+ Ausnahmen: Lebewesen und per AddItem() hinzugefuegte Objekte.
+
+ Mit dem Argument <fun> lassen sich die Kriterien fuer die "Gleichheit"
+ aendern.
+ Ist <fun> ein Funktionsname, wird diese Funktion an allen in Frage
+ kommenenden Objekten im Container gerufen.
+ Ist <fun> eine Closure, werden sie fuer jedes in Frage kommende Objekt
+ einmal gerufen und ihr das Objekt uebergeben.
+ Als 'gleich' werden alle Objekte betrachtet, fuer die <fun> den gleichen
+ Wert zurueckliefert.
+ Objekte, fuer die <fun> 0 zurueckliefert, werden ignoriert.
+
+BEMERKUNGEN
+-----------
+::
+
+ 1) Raeume rufen remove_multiple(3) standardmaessig im reset(), jedoch
+ nur, wenn kein Spieler anwesend ist und mehr als 10 Objekte im Raum
+ sind.
+ 2) remove_multipe(0) entfernt alle entfernbaren Objekte (s. Ausnahmen).
+
+BEISPIELE
+---------
+::
+
+ Ein Container enthaelt 5 Fackeln. Im reset() ruft man nun
+ remove_multiple(3) auf. Anschliessend sind noch 3 Fackeln uebrig.
+
+
+
+ Alle verbleibenden Objekte im Container sollen unterschiedliche Namen
+ haben:
+ remove_multiple(1, "name");
+
+ Ein Container soll nur ein Objekt behalten, welches groesser als 70 cm
+ ist:
+ int groessen_filter(object ob) {
+ if (ob->QueryProp(P_SIZE > 70)) return 1;
+ return 0; // damit das Objekt ignoriert wird.
+ // Alternativ koennte man statt 0 auch object_name(ob) zurueckliefern,
+ // dann sind diese Objekte alle unterschiedlich.
+ }
+ ...
+ remove_multiple(1, #'groessen_filter);
+
+SIEHE AUCH
+----------
+::
+
+ reset()
+
+31.01.2009, Zesstra
+
diff --git a/doc/sphinx/lfun/reset.rst b/doc/sphinx/lfun/reset.rst
new file mode 100644
index 0000000..2c65656
--- /dev/null
+++ b/doc/sphinx/lfun/reset.rst
@@ -0,0 +1,106 @@
+reset()
+=======
+
+FUNKTION
+--------
+::
+
+ void reset();
+ protected void reset();
+
+BESCHREIBUNG
+------------
+::
+
+ reset() wird vom GameDriver in jedem Objekt aufgerufen, um dem Objekt
+ die Gelegenheit zu geben, sich wieder in einen definierten Zustand zu
+ versetzen: Raeume und Monster erzeugen per AddItem() eingefuegte und
+ zwischenzeitlich entfernte Objekte neu, Tueren schliessen sich ...
+
+ Solange das Objekt "benutzt" wird, wird reset() regelmaessig alle
+ 45 Minuten (+/-15 Minuten) mit einer Aufloesung von 2s aufgerufen
+ (d.h. der Driver prueft und ruft nur alle 2 Sekunden reset() auf
+ allen Objekten).
+
+ Wird eine Objekt nicht mehr "benutzt", d.h. wird an einem Objekt nicht
+ von aussen (durch call_other etc.) _nach_ einem reset() eine Methode
+ bzw. LFun gerufen, so bekommt dieses Objekt keinen weiteren reset().
+
+ Ein Funktionsaufruf am Objekt schaltet den reset() wieder ein.
+ Bei einem Objekt in einem Container waere das zB das Benutzen des
+ Containers (Hineinlegen/Herausnehmen/Hineinsehen). Das kann
+ sehr lange dauern.
+
+ Die Abschaltung kann man verhindern, indem man im reset() per call_out()
+ eine Funktion im Objekt ruft. Dies aber bitte _nur_ machen, wenn das
+ Objekt _unbedingt_ auf einen staendigen Reset angewiesen ist, auch wenn
+ es nicht "benutzt" wird.
+
+ Aendern laesst sich die Zeit zwischen den Aufrufen von reset() mit
+ set_next_reset(). Die Aufloesung von 2s kann man nicht aendern.
+
+BEMERKUNGEN
+-----------
+::
+
+ - man kann reset() nutzen, um Ereignisse auszuloesen:
+ - es ist billiger als lange call_out()
+ - siehe Warnung bezueglich Abschalten des reset
+ - man kann reset() als protected oder static definieren, wenn man nicht
+ moechte, dass die Funktion von aussen gerufen werden kann. Dies
+ verhindert Einflussnahme von aussen, kann aber auch Debugmassnahmen
+ erschweren. Es ist aber dennoch fuer einige Objekte sinnvoll.
+ - der Driver ruft reset() unabhaengig von zusaetzlichen, "manuellen"
+ Rufen von reset()
+ - keine Rufe von reset() mit call_out() aus reset() (Callout-Ketten-
+ bildung droht), fuer solche Faelle ist set_next_reset(E) da!
+ - bei Blueprints sollte der reset() in der Regel abgeschaltet werden,
+ sofern er nicht auf wichtige Aufgaben in der BP zu tun hat:
+ protected void create() {
+ if(!clonep(ME)) {
+ set_next_reset(-1);
+ return;
+ }
+ ::create();
+ ...
+ }
+
+BEISPIELE
+---------
+::
+
+ // ein NPC, der bei jedem reset() schaut, ob um ihn herum bessere
+ // Ausruestung liegt als die, die er selbst gerade traegt:
+
+ ...
+ void reset() {
+ ::reset();
+
+ if(clonep(this_object()) && environment()) {
+ object o;
+ o=first_inventory(environment());
+ while(o) {
+ look_for_good_weapons_and_use_them_if_better(o);
+ o=next_inventory(o);
+ }
+ }
+ }
+
+ // ein reset fuer einen Gegenstand, der vielleicht in
+ // in einem Container landet und dann weiter einen reset
+ // bekommen muss/soll
+
+ void reset() {
+ // irgend ein Code hier
+ call_other(this_object(), "???"); // einfach nur was aufrufen
+ }
+
+SIEHE AUCH
+----------
+::
+
+ clean_up(), set_next_reset(E), query_next_reset(E)
+ memory
+
+letzte Aenderung: 2009-01-14 Rumata
+
diff --git a/doc/sphinx/lfun/restore_hit_points.rst b/doc/sphinx/lfun/restore_hit_points.rst
new file mode 100644
index 0000000..e7c2e70
--- /dev/null
+++ b/doc/sphinx/lfun/restore_hit_points.rst
@@ -0,0 +1,57 @@
+restore_hit_points()
+====================
+
+FUNKTION
+--------
+::
+
+ int restore_hit_points(int heal)
+
+ARGUMENTE
+---------
+::
+
+ int heal - der zu heilende Betrag
+
+BESCHREIBUNG
+------------
+::
+
+ Dem Lebewesen werden heal Lebenspunkte aufgeschlagen. Die HP
+ steigen nicht ueber P_MAX_HP.
+
+RUECKGABEWERT
+-------------
+::
+
+ Die verbleibenden Lebenspunkte.
+
+BEISPIELE
+---------
+::
+
+ write("Ploetzlich schiesst eine scheussliche Kreatur aus der Pfuetze "+
+ "heraus und\nschleimt dich heilend voll, sie verschwindet so, "+
+ "wie sie gekommen ist.\n");
+ this_player()->restore_hit_points(50);
+
+BEMERKUNGEN
+-----------
+::
+
+ Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
+ dafuer eingerichteten Funktion check_and_update_timed_key realisiert
+ werden.
+ Ansonsten bitte buffer_hp() benutzen und die Konzeptseite lesen!
+
+SIEHE AUCH
+----------
+::
+
+ Gegenpart: reduce_hit_points()
+ Verwandt: buffer_hp(), heal_self(), restore_spell_points()
+ Props: P_HP
+ Konzept: heilung
+
+23.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/restore_spell_points.rst b/doc/sphinx/lfun/restore_spell_points.rst
new file mode 100644
index 0000000..2638568
--- /dev/null
+++ b/doc/sphinx/lfun/restore_spell_points.rst
@@ -0,0 +1,61 @@
+restore_spell_points()
+======================
+
+FUNKTION
+--------
+::
+
+ void restore_spell_points(int points)
+
+ARGUMENTE
+---------
+::
+
+ points: Anzahl der Konzentrationspunkte die gutgeschrieben werden sollen.
+
+BESCHREIBUNG
+------------
+::
+
+ Dem Lebewesen werden points Konzentrationspunkte gutgeschrieben. Falls
+ Punkte abgezogen werden sollen und das Lebewesen nicht ueber <points>
+ Konzentrationspunkte verfuegt, werden sie auf 0 gesetzt.
+
+RUECKGABEWERT
+-------------
+::
+
+ Keiner
+
+BEISPIELE
+---------
+::
+
+ write("Das boese boese Monster schaut Dich suess an und gibt dir mehr "
+ +"Konzentration.\n");
+ this_player()->restore_spell_points(50);
+
+BEMERKUNGEN
+-----------
+::
+
+ Da das Benutzen der Funktion eine Heilung bedeutet, sollte man bei
+ Verwendung auf jeden Fall Ruecksprache mit seinem RM nehmen, bzw
+ die Heilstelle bei der Heilungsbalance genehmigen lassen.
+
+ Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
+ dafuer eingerichteten Funktion check_and_update_timed_key realisiert
+ werden.
+ Ansonsten bitte buffer_sp() benutzen und die Konzeptseite lesen!
+
+SIEHE AUCH
+----------
+::
+
+ Gegenpart: reduce_spell_points(L)
+ Verwandt: buffer_sp(L), restore_hit_points(L)
+ Props: P_SP
+ Konzept: heilung
+
+23.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/lfun/save_me.rst b/doc/sphinx/lfun/save_me.rst
new file mode 100644
index 0000000..2fc4811
--- /dev/null
+++ b/doc/sphinx/lfun/save_me.rst
@@ -0,0 +1,41 @@
+save_me()
+=========
+
+save_me(L)
+
+FUNKTION
+--------
+::
+
+ void save_me(mixed value_items)
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/base.c
+
+ARGUMENTE
+---------
+::
+
+ value_items
+ Ungleich 0, wenn Wert der Gegenstaende berechnet werden soll.
+
+BESCHREIBUNG
+------------
+::
+
+ Speichert einen Spieler, seine Autoloader, bestimmt sein GuildRating
+ und berechnet/speichert auf Anforderung den Wert der getragenen
+ Gegenstaende.
+
+SIEHE AUCH
+----------
+::
+
+ Props: P_CARRIED_VALUE, P_AUTOLOADOBJ, P_LAST_LOGOUT
+ Kommandos: save, ende
+
+1.September 2008 Gloinson
+
diff --git a/doc/sphinx/lfun/second_life.rst b/doc/sphinx/lfun/second_life.rst
new file mode 100644
index 0000000..f0aef10
--- /dev/null
+++ b/doc/sphinx/lfun/second_life.rst
@@ -0,0 +1,53 @@
+second_life()
+=============
+
+FUNKTION
+--------
+::
+
+ varargs int second_life(object obj);
+
+DEFINIERT IN
+------------
+::
+
+ /std/player/life.c
+
+ARGUMENTE
+---------
+::
+
+ obj
+ Leiche des Lebewesens.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird im die() des Lebewesens aufgerufen, wenn sicher
+ ist, dass es stirbt. Ueblicherweise ist diese Funktion nur im Spieler
+ definiert und regelt EP-Verlust und dergleichen. Ein Shadow wuerde
+ diese Funktion ueberlagern, um zu verhindern, dass ein Spieler stirbt.
+
+RUeCKGABEWERT
+-------------
+::
+
+ 1, wenn das Lebewesen nicht stirbt, sonst 0
+
+BEMERKUNG
+---------
+::
+
+ Bei NPCs sollte man direkt die() ueberschreiben, wenn man nicht
+ moechte, dass sie sterben.
+
+SIEHE AUCH
+----------
+::
+
+ die()
+
+
+Last modified: 2015-Jan-19, Arathorn
+
diff --git a/doc/sphinx/lfun/sell_obj.rst b/doc/sphinx/lfun/sell_obj.rst
new file mode 100644
index 0000000..f65998d
--- /dev/null
+++ b/doc/sphinx/lfun/sell_obj.rst
@@ -0,0 +1,60 @@
+sell_obj()
+==========
+
+sell_obj()
+
+Funktion:
+ static string sell_obj(object ob, int short)
+
+Definiert in:
+ /std/room/shop
+
+Argumente:
+ ob:
+ Das anzukaufende Objekt
+ short:
+ Gibt an, ob der Verkaeufer nur ein Objekt (0) oder mehrere (1)
+ verkauft. (Verkaufe alles etc.)
+
+Beschreibung:
+ Ermittelt ob der Laden bereit ist, <ob> anzukaufen.
+
+Rueckgabewert:
+ Meldung die ausgegeben wird, wenn ein Objekt abgelehnt wird oder 0.
+
+Bemerkung:
+ Man sollte im normalfall _niemals_ einfach 0 zurueckgeben, sondern das
+ geerbte sell_obj() aus /std/room/shop, damit beispielsweise P_NOBUY
+ beachtet wird.
+
+Beispiel:
+ Ein Schmied, der nur Waffen ankauft:
+
+
+
+ protected void create()
+ {
+ ...
+ }
+
+
+
+ static string sell_obj(object ob, int short)
+ {
+ if(!ob->QueryProp(P_WEAPON_TYPE))
+ {
+ return "Ich bin nur an Waffen interessiert.";
+ }
+ return ::sell_obj(ob,short);
+ }
+
+Siehe auch:
+ Funktionen:
+ AddFixedObject(), RemoveFixedObject(), SetStorageRoom(),
+ QueryStorageRoom(), QueryBuyValue(), QueryBuyFact(), buy_obj()
+ Properties:
+ P_KEEPER, P_MIN_STOCK, P_STORE_CONSUME
+
+
+Letzte Aenderung: 21.05.2014, Bugfix
+
diff --git a/doc/sphinx/lfun/set_object_next_reset.rst b/doc/sphinx/lfun/set_object_next_reset.rst
new file mode 100644
index 0000000..3d86b62
--- /dev/null
+++ b/doc/sphinx/lfun/set_object_next_reset.rst
@@ -0,0 +1,41 @@
+set_object_next_reset()
+=======================
+
+FUNKTION
+--------
+::
+
+ int set_object_next_reset(object ob, int zeit );
+
+DEFINIERT IN: /secure/debug.c
+
+ARGUMENTE
+---------
+::
+
+ ob: Das Objekt, dess Reset gesetzt werden soll.
+ zeit: Zeit bis zum naechsten Reset von ob.
+
+FUNKTION
+--------
+::
+
+ Die Funktion ruft letztendlich set_next_reset() in <ob> auf und setzt daher
+ dessen Resetzeit auf einen neuen Wert. Dies ist zu Debugzwecken gedacht.
+
+ Die Benutzung ist nur fuer EM+ moeglich.
+
+RUECKGABEWERT
+-------------
+::
+
+ Gibt den Rueckgabewert des set_next_reset()-Aufrufs in <ob> zurueck.
+
+SIEHE AUCH
+----------
+::
+
+ set_next_reset(E)
+
+10.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/shoot_dam.rst b/doc/sphinx/lfun/shoot_dam.rst
new file mode 100644
index 0000000..eb34c14
--- /dev/null
+++ b/doc/sphinx/lfun/shoot_dam.rst
@@ -0,0 +1,63 @@
+shoot_dam()
+===========
+
+FUNKTION
+--------
+::
+
+ static int shoot_dam(mapping shoot)
+
+DEFINIERT IN
+------------
+::
+
+ /std/ranged_weapon.c
+
+ARGUMENTE
+---------
+::
+
+ mapping shoot - Schussdaten
+
+BESCHREIBUNG
+------------
+::
+
+ Erhaelt von /std/ranged_weapon::cmd_shoot() die Schussdaten und berechnet
+ den Schaden der Waffe, basierend auf den P_SHOOTING_WC von Waffe und
+ Munition sowie der Geschicklichkeit des Schuetzen. HitFuncs der Munition
+ und Skills werden hier ebenfalls beruecksichtigt.
+
+RUECKGABEWERT
+-------------
+::
+
+ Schaden. Ebenfalls in 'shoot' unter SI_SKILLDAMAGE aktualisiert.
+
+BEMERKUNGEN
+-----------
+::
+
+ 'shoot' enthaelt normalerweise folgende Eintraege:
+ * Key P_WEAPON: die Schusswaffe
+ * Key P_WEAPON_TYPE: P_AMMUNITION, also die Munitions-ID
+ * Key P_STRETCH_TIME: P_STRETCH_TIME der Waffe
+ * Key P_WC: P_SHOOTING_WC der Waffe
+ * Key P_SHOOTING_WC: P_SHOOTING_WC der Munition
+ * Key P_AMMUNITION: Munitionsobjekt (eventuell Unit)
+ * Key SI_ENEMY: gueltigen Gegner
+ * Key SI_SKILLDAMAGE_TYPE: Schaden (aus P_DAM_TYPE der Munition)
+ * Key SI_SKILLDAMAGE_MSG/2: Munitionsname
+
+SIEHE AUCH
+----------
+::
+
+ Generell: P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
+ Methoden: FindRangedTarget(L), cmd_shoot(L)
+ Skills: UseSkill(L), SkillResTransfer(L)
+ Attribute: QueryAttribute
+ Sonstiges: fernwaffen, HitFunc
+
+28.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/lfun/short.rst b/doc/sphinx/lfun/short.rst
new file mode 100644
index 0000000..1d1eda3
--- /dev/null
+++ b/doc/sphinx/lfun/short.rst
@@ -0,0 +1,54 @@
+short()
+=======
+
+FUNKTION
+--------
+::
+
+ public varargs string short();
+
+DEFINIERT IN
+------------
+::
+
+ /std/thing/description.c
+
+ARGUMENTE
+---------
+::
+
+ keine
+
+BESCHREIBUNG
+------------
+::
+
+ Der Inhalt der Property P_SHORT wird ausgewertet, mit ".\n"
+ abgeschlossen und zurueckgegeben.
+
+RUeCKGABEWERT
+-------------
+::
+
+ Die Kurzbeschreibung als String oder 0, falls das Objekt unsichtbar
+ ist.
+
+BEMERKUNGEN
+-----------
+::
+
+ Durch Ueberladen von short() lassen sich noch weitere Eigenschaften des
+ Objektes zeigen. Fackeln zeigen zum Beispiel an, ob sie brennen,
+ Ruestungen, ob sie angezogen sind und Waffen, ob sie gezueckt sind.
+
+SIEHE AUCH
+----------
+::
+
+ Aehnliches: long()
+ Properties: P_SHORT, P_INVIS
+ Sonstiges: make_invlist()
+
+
+20.01.2015, Zesstra
+
diff --git a/doc/sphinx/lfun/show_notify.rst b/doc/sphinx/lfun/show_notify.rst
new file mode 100644
index 0000000..92ec9a1
--- /dev/null
+++ b/doc/sphinx/lfun/show_notify.rst
@@ -0,0 +1,73 @@
+show_notify()
+=============
+
+give_notify()
+
+FUNKTION
+--------
+::
+
+ void show_notify(object obj)
+
+DEFINIERT IN
+------------
+::
+
+ /std/living/put_and_get.c
+
+ARGUMENTE
+---------
+::
+
+ obj - dem Lebewesen gezeigtes Objekt
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird automatisch immer dann aufgerufen, wenn einem
+ Lebewesen (welches kein Spielercharakter ist) ein Objekt gezeigt wird.
+ Dies funktioniert nur dann, wenn der Standardbefehl der Spielershell
+ verwendet wird ("zeige <name> <gegenstand>"). Selbstgebautes "zeige"
+ funktioniert nicht.
+
+BEISPIEL
+--------
+::
+
+ Oftmals will man in Quests erreichen, dass einem NPC ein bestimmtes
+ Item als Beweis der Erfuellung einer bestimmten Aufgabe vorgezeigt
+ wird. Folgendermassen kann dies realisiert werden:
+
+ void quest_ok(object obj) { ...
+ // z.B. Vernichtung des Questobjektes und Questtexte
+ // Questbelohnung und Questanerkennung, etc.
+ }
+
+ void show_notify(object obj) {
+ if(obj->id("\nquestitem")) // Ist das das geforderte Questobjekt?
+ quest_ok(obj);
+ }
+
+BEMERKUNGEN
+-----------
+::
+
+ Da es nur um das Vorzeigen von Gegenstaenden geht, die nicht den
+ Besitzer wechseln, sind Mechanismen wie P_REJECT in diesem Fall
+ nicht erforderlich.
+
+SIEHE AUCH
+----------
+::
+
+ give_notify(), /std/npc/put_and_get.c, /std/living/put_and_get.c
+
+22. Oktober 2013 Arathorn
+
diff --git a/doc/sphinx/lfun/spellbook/AddSpell.rst b/doc/sphinx/lfun/spellbook/AddSpell.rst
new file mode 100644
index 0000000..941f6db
--- /dev/null
+++ b/doc/sphinx/lfun/spellbook/AddSpell.rst
@@ -0,0 +1,78 @@
+AddSpell()
+==========
+
+FUNKTION
+--------
+::
+
+ varargs int AddSpell(string verb, int kosten, mixed ski)
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ string verb Name des Spells
+ int kosten normale Kosten (Grundkosten)
+ mixed ski Skillmapping mit allen Eintraegen zum Spell
+
+BESCHREIBUNG
+------------
+::
+
+ Addiert einen Eintrag fuer den Spell im Spellbook. Wenn dieser
+ Spell direkt vom Spieler (SI_SPELLBOOK) oder (normalerweise)
+ ueber ein Gildenobjekt aufgerufen wird, wird das Mapping auf
+ die Skillinformationen aus Spieler und Gilde addiert und
+ beeinflusst damit den Aufruf der letztlichen Spellfunktion.
+
+BEMERKUNGEN
+-----------
+::
+
+ Siehe das Verhalten von QuerySpell (gilde) zum Zusammenfuegen
+ der AddSpell-Informationen aus Gilde und Spellbook. Relevant
+ zB fuer Lernrestriktionen.
+
+BEISPIEL
+--------
+::
+
+ AddSpell("kampfschrei", 30,
+ ([SI_SKILLRESTR_LEARN:([P_LEVEL:13]),
+ SI_MAGIC_TYPE: ({MT_PSYCHO}),
+ SI_SPELL: ([
+ SP_NAME: "Kampfschrei",
+ SP_SHOW_DAMAGE:
+ ({({ -1, "Dir geschieht jedoch nichts.",
+ "@WEM1 geschieht jedoch nichts.",
+ "@WEM1 geschieht jedoch nichts." }),
+ ({ 0, "Du kannst darueber aber nur lachen.",
+ "@WER1 kann darueber aber nur lachen.",
+ "@WER1 kann darueber aber nur lachen." }),
+ ({ 10, "Dir droehnen die Ohren.",
+ "@WEM1 droehnen die Ohren.",
+ "@WEM1 droehnen die Ohren." })
+ })])
+ ]));
+
+SIEHE AUCH
+----------
+::
+
+ Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
+ * Verwalten: QuerySpell
+ * Angriff: TryAttackSpell, TryDefaultAttackSpell,
+ TryGlobalAttackSpell
+ * Properties: P_GLOBAL_SKILLPROPS, P_SB_SPELLS
+ Skills Lernen: LearnSkill, ModifySkill, LimitAbility
+ * Nutzung: UseSpell, UseSkill
+ * sonstig: spruchermuedung, skill_info_liste
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/spellbook/Erfolg.rst b/doc/sphinx/lfun/spellbook/Erfolg.rst
new file mode 100644
index 0000000..98deb90
--- /dev/null
+++ b/doc/sphinx/lfun/spellbook/Erfolg.rst
@@ -0,0 +1,46 @@
+Erfolg()
+========
+
+FUNKTION
+--------
+::
+
+ void Erfolg(object caster, string spell, mapping sinfo)
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ object caster Spell sprechender Spieler
+ string spell Spellname
+ mapping sinfo Spell-Info-Mapping mit allen Informationen
+
+BESCHREIBUNG
+------------
+::
+
+ Wird bei Erfolg eines Spells gerufen. Ruft SpellInform() am
+ Environment.
+
+SIEHE AUCH
+----------
+::
+
+ Sonstiges: SpellInform
+ Spellbook Lernen: Learn, SpellSuccess, Misserfolg
+ * Verwalten: AddSpell, QuerySpell
+ * Angriff: TryAttackSpell, TryDefaultAttackSpell,
+ TryGlobalAttackSpell
+ * Properties: P_GLOBAL_SKILLPROPS, P_SB_SPELLS
+ Skills Lernen: LearnSkill, ModifySkill, LimitAbility
+ * Nutzung: UseSpell, UseSkill
+ * sonstig: spruchermuedung, skill_info_liste
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/spellbook/Learn.rst b/doc/sphinx/lfun/spellbook/Learn.rst
new file mode 100644
index 0000000..19756a6
--- /dev/null
+++ b/doc/sphinx/lfun/spellbook/Learn.rst
@@ -0,0 +1,54 @@
+Learn()
+=======
+
+FUNKTION
+--------
+::
+
+ void Learn(object caster, string spell, mapping sinfo)
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ object caster Derjenige, der den Spruch spricht.
+ string spell Der gesprochene Spell
+ mapping sinfo Mapping mit allen moeglichen Informationen zum Spell
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird von der Funktion "Misserfolg" aus dem
+ Spellbook aufgerufen. Hier lernt der Spieler den Spruch, der
+ nicht geglueckt ist.
+
+BEMERKUNGEN
+-----------
+::
+
+ Kann auch ueberschrieben werden, wenn man komplexe Lern-Aenderungen
+ vornehmen will. Andere Attribute sind ueber SI_LEARN_ATTRIBUTE
+ setzbar.
+
+SIEHE AUCH
+----------
+::
+
+ Spellbook Lernen: SpellSuccess, Erfolg, Misserfolg
+ * Verwalten: AddSpell, QuerySpell
+ * Angriff: TryAttackSpell, TryDefaultAttackSpell,
+ TryGlobalAttackSpell
+ * Properties: P_GLOBAL_SKILLPROPS, P_SB_SPELLS
+ Skills Lernen: LearnSkill, ModifySkill, LimitAbility
+ * Nutzung: UseSpell, UseSkill
+ * sonstig: spruchermuedung, skill_info_liste
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/spellbook/Misserfolg.rst b/doc/sphinx/lfun/spellbook/Misserfolg.rst
new file mode 100644
index 0000000..8951868
--- /dev/null
+++ b/doc/sphinx/lfun/spellbook/Misserfolg.rst
@@ -0,0 +1,78 @@
+Misserfolg()
+============
+
+FUNKTION
+--------
+::
+
+ void Misserfolg(object caster, string spell, mapping sinfo)
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ object caster Spell sprechender Spieler
+ string spell Spellname
+ mapping sinfo Spell-Info-Mapping mit allen Informationen
+
+BESCHREIBUNG
+------------
+::
+
+ Wird bei Misserfolg eines Spells im Spellbook aufgerufen und
+ ruft die Lernfunktion Learn() nach einer Fehlermeldung.
+
+
+
+ Kann ueberschrieben werden, um die Meldungen anzupassen.
+
+BEISPIEL
+--------
+::
+
+ // Misserfolge im Klerus mit angepassten Meldungen
+ void Misserfolg(object caster, string spell, mapping sinfo) {
+ switch(spell) {
+ case "begrabe":
+ tell_object(caster, BS(
+ "Du begraebst Deine Hoffnungen, dass Du diese Anrufung jemals "
+ "perfekt beherrschen wirst."));
+ tell_room(environment(caster),
+ caster->Name(WER)+" tritt die Leiche lustlos.\n", ({caster}));
+ break;
+ case "blitz":
+ [...]
+ }
+
+
+
+ int old_abil = sinfo[SI_SKILLABILITY];
+ Learn(caster, spell, sinfo);
+ int new_abil = caster->QuerySkillAbility(spell);
+ if (old_abil < new_abil)
+ tell_object(caster, "Die Goetter schenken Dir eine Erleuchtung.\n");
+ else
+ tell_object(caster, "Leider lernst Du nicht aus Deinem Fehler.\n");
+ }
+
+SIEHE AUCH
+----------
+::
+
+ Spellbook Lernen: Learn, SpellSuccess, Erfolg
+ * Verwalten: AddSpell, QuerySpell
+ * Angriff: TryAttackSpell, TryDefaultAttackSpell,
+ TryGlobalAttackSpell
+ * Properties: P_GLOBAL_SKILLPROPS, P_SB_SPELLS
+ Skills Lernen: LearnSkill, ModifySkill, LimitAbility
+ * Nutzung: UseSpell, UseSkill
+ * sonstig: spruchermuedung, skill_info_liste
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/spellbook/QuerySpell.rst b/doc/sphinx/lfun/spellbook/QuerySpell.rst
new file mode 100644
index 0000000..23a72fb
--- /dev/null
+++ b/doc/sphinx/lfun/spellbook/QuerySpell.rst
@@ -0,0 +1,46 @@
+QuerySpell()
+============
+
+FUNKTION
+--------
+::
+
+ mapping QuerySpell(string spell)
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ string spell Name des Spells
+
+BESCHREIBUNG
+------------
+::
+
+ Gibt das Spellmapping aus P_SB_SPELLS fuer diesen Spell zurueck.
+
+
+
+ Hier enthaelt QuerySpell nur die Spellbook-Informationen.
+
+SIEHE AUCH
+----------
+::
+
+ Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
+ * Verwalten: AddSpell
+ * Angriff: TryAttackSpell, TryDefaultAttackSpell,
+ TryGlobalAttackSpell
+ * Properties: P_GLOBAL_SKILLPROPS, P_SB_SPELLS
+ Skills Lernen: LearnSkill, ModifySkill, LimitAbility
+ * Nutzung: UseSpell, UseSkill
+ * sonstig: spruchermuedung, skill_info_liste
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/spellbook/SpellSuccess.rst b/doc/sphinx/lfun/spellbook/SpellSuccess.rst
new file mode 100644
index 0000000..2377b8b
--- /dev/null
+++ b/doc/sphinx/lfun/spellbook/SpellSuccess.rst
@@ -0,0 +1,52 @@
+SpellSuccess()
+==============
+
+FUNKTION
+--------
+::
+
+ int SpellSuccess(object caster, mapping sinfo)
+
+DEFINIERT IN
+------------
+::
+
+ /std/spellbook.c
+
+ARGUMENTE
+---------
+::
+
+ object caster Spell sprechender Spieler
+ mapping sinfo Spell-Info-Mapping mit allen Informationen
+
+BESCHREIBUNG
+------------
+::
+
+ Berechnet den Erfolg der Anwendung eines Spells aus seiner
+ SI_SKILLABILITY und dem Skill SK_CASTING im Spieler. Laesst
+ den Spieler bei besonders gutem Gelingen SK_CASTING lernen.
+
+BEMERKUNGEN
+-----------
+::
+
+ SK_CASTING muss fuer die SK_CASTING-Boni beherrscht werden.
+ Das ist zB im Klerus ab bestimmtem Level der Fall.
+
+SIEHE AUCH
+----------
+::
+
+ Spellbook Lernen: Learn, Erfolg, Misserfolg
+ * Verwalten: AddSpell, QuerySpell
+ * Angriff: TryAttackSpell, TryDefaultAttackSpell,
+ TryGlobalAttackSpell
+ * Properties: P_GLOBAL_SKILLPROPS, P_SB_SPELLS
+ Skills Lernen: LearnSkill, ModifySkill, LimitAbility
+ * Nutzung: UseSpell, UseSkill
+ * sonstig: spruchermuedung, skill_info_liste
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/lfun/spellbook/TryAttackSpell.rst b/doc/sphinx/lfun/spellbook/TryAttackSpell.rst
new file mode 100644
index 0000000..d718803
--- /dev/null
+++ b/doc/sphinx/lfun/spellbook/TryAttackSpell.rst
@@ -0,0 +1,58 @@
+TryAttackSpell()
+================
+
+** gilden-doku
+ o TryAttackSpell(opfer,schaden,typen,is_spell,caster,info)
+ Versucht den Angriffs-Spruch auf den Gegner anzuwenden. Die
+ mittleren 4 Werte sind die, die auch bei Defend uebergeben werden.
+ Dabei wird die Abwehrfaehigkeit des Gegners gegen Magie und das
+ Skill-Attribut SA_DAMAGE automatisch beruecksichtigt.
+
+FUNKTION
+--------
+::
+
+int TryAttackSpell(object victim, int damage, mixed dtypes,
+ mixed is_spell, object caster, mapping sinfo)
+
+ARGUMENTE
+---------
+::
+
+ victim : Das arme Opfer.
+ damage : Der Schaden.
+ dtypes : Die Schadensarten.
+ is_spell : Ist es ein Spell? Werden noch Spezielle Parameter
+ uebergeben (als mapping) ?
+ caster : Derjenige, der den Spruch spricht.
+ sinfo : Mapping mit allen moeglichen Informationen zum Spell
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird vom Spellbook aufgerufen, wenn der Spieler
+ einen Angriffsspell gemacht hat und damit Schaden anrichten will.
+
+RUECKGABEWERT
+-------------
+::
+
+ Der Wert, der vom Defend() des Gegners zurueckgeliefert wird.
+
+BEMERKUNGEN
+-----------
+::
+
+ Zu erst wird ueberprueft, ob das Ziel ueberhaupt angreifbar ist. Dies
+ verhindert das ueben von Spells an unangreifbaren NPCs.
+ Als naechstes wird die Faehigkeit, Spells abzuwehren ueberprueft.
+ Falls beide Abfragen ok sind, wird Defend aufgerufen.
+
+
+Siehe auch:
+
+TryDefaultAttackSpell (to be written)
+
+07.10.2007, Zesstra
+
diff --git a/doc/sphinx/lfun/trigger_sensitive_attack.rst b/doc/sphinx/lfun/trigger_sensitive_attack.rst
new file mode 100644
index 0000000..2067246
--- /dev/null
+++ b/doc/sphinx/lfun/trigger_sensitive_attack.rst
@@ -0,0 +1,98 @@
+trigger_sensitive_attack()
+==========================
+
+FUNKTION
+--------
+::
+
+ varargs void trigger_sensitive_attack(object enemy, string key, int
+ dam, mixed spell, mixed *options);
+
+DEFINIERT IN
+------------
+::
+
+ eigenen sensitiven Objekten, wird aufgerufen von
+ /std/living/inventory.c
+
+ARGUMENTE
+---------
+::
+
+ enemy
+ Der Gegner, der die Aktion ausgeloest hat.
+ key
+ Der ausloesende Schadenstyp.
+ dam
+ Der angerichtete Schaden.
+ spell
+ Wie bei Defend().
+ options
+ Array mit den in P_SENSITIVE angegebenen Optionen fuer diese
+ Aktion.
+
+BESCHREIBUNG
+------------
+::
+
+ Wenn der bei einem Angriff zugefuegte Schaden den in P_SENSITIVE
+ angegebenen Grenzwert uebersteigt sowie der als Schluessel angegebene
+ Schadenstyp in den Schaedenstypen des Angriffes vorkommt, wird diese
+ Funktion aufgerufen und kann entsprechend reagieren.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEISPIELE
+---------
+::
+
+ Eine Fackel, die sich bei Feuerattacken selbst entzuendet und bei
+ Wasserattacken verloescht, koennte man wie folgt implementieren:
+
+ inherit "/std/lightsource.c"
+
+ #include <properties.h>
+ #include <sensitive.h>
+ #include <combat.h>
+
+ create()
+ {
+ ::create();
+
+ SetProp(...); // die ueblichen Eigenschaften definieren
+
+ SetProp(P_SENSITIVE,
+ // Ereignis Key Grenze (keine Optionen)
+ ({ ({ SENSITIVE_ATTACK, DT_FIRE, 100 }),
+ ({ SENSITIVE_ATTACK, DT_WATER, 100 }) }) );
+ }
+
+ varargs void
+ trigger_sensitive_attack(object enemy, string key,
+ int dam, mixed spell)
+ {
+ // Es soll nicht verschwiegen werden, dass das Entzuenden und
+ // Loeschen einer Lichtquelle so leider nicht funktioniert...
+ if (key == DT_FIRE && !QueryProp(P_LIGHTED)) {
+ SetProp(P_LIGHTED, 1);
+ tell_object(environment(), "Die Fackel faengt Feuer.\n");
+ }
+ else if (key == DT_WATER && QueryProp(P_LIGHTED)) {
+ SetProp(P_LIGHTED, 0);
+ tell_object(environment(), "Die Fackel verlischt.\n");
+ }
+ }
+
+SIEHE AUCH
+----------
+::
+
+ trigger_sensitive_inv(), sensitive Objekte
+
+
+Last modified: Sun May 19 15:56:25 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/trigger_sensitive_inv.rst b/doc/sphinx/lfun/trigger_sensitive_inv.rst
new file mode 100644
index 0000000..9574c2d
--- /dev/null
+++ b/doc/sphinx/lfun/trigger_sensitive_inv.rst
@@ -0,0 +1,62 @@
+trigger_sensitive_inv()
+=======================
+
+FUNKTION
+--------
+::
+
+ varargs void trigger_sensitive_inv(object ob, string key, int wert,
+ mixed *optionen1, mixed *optionen2);
+
+DEFINIERT IN
+------------
+::
+
+ eigenen Objekten, wird aufgerufen von /std/container/inventory.c
+
+ARGUMENTE
+---------
+::
+
+ ob
+ Das ausloesende Objekt
+ key
+ Der Schluessel, der die Aktion ausloeste.
+ wert
+ Der Grenzwert des ausloesenden Objektes.
+ optionen1
+ Die Optionen des ausloesenden Objektes.
+ optionen2
+ Die Optionen des reagierenden Objektes.
+
+BESCHREIBUNG
+------------
+::
+
+ Diese Funktion wird in Objekten des sensitiven Typs SENSITIVE_INVENTORY
+ aufgerufen, wenn sie in Kontakt mit Objekten des Typs
+ SENSITIVE_INVENTORY_TRIGGER treten, die den gleichen Schluessel
+ aufweisen und einen hoeheren Grenzwert haben.
+
+ Anhand der Parameter koennen dann die noetigen Aktionen ausgeloest
+ werden.
+
+RUeCKGABEWERT
+-------------
+::
+
+ keiner
+
+BEISPIELE
+---------
+::
+
+SIEHE AUCH
+----------
+::
+
+ trigger_sensitive_attack(), sensitive Objekte
+
+
+Last modified: Wed May 8 10:26:10 1996 by Wargon
+
diff --git a/doc/sphinx/lfun/wield_me.rst b/doc/sphinx/lfun/wield_me.rst
new file mode 100644
index 0000000..f9f3fea
--- /dev/null
+++ b/doc/sphinx/lfun/wield_me.rst
@@ -0,0 +1,18 @@
+wield_me()
+==========
+
+BEMERKUNGEN
+-----------
+::
+
+ wield_me wurde durch DoWield ersetzt.
+
+SIEHE AUCH
+----------
+::
+
+ DoWieldFunc(), /std/weapon.c
+
+
+Last modified: Wed Apr 08 10:25:00 2004 by Muadib
+