diff --git a/doc/sphinx/props/P_ABILITIES.rst b/doc/sphinx/props/P_ABILITIES.rst
new file mode 100644
index 0000000..d84b229
--- /dev/null
+++ b/doc/sphinx/props/P_ABILITIES.rst
@@ -0,0 +1,22 @@
+P_ABILITIES
+===========
+
+NAME
+----
+::
+
+    P_ABILITIES                   "abilities"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+     *** OBSOLET! ***
+     Siehe P_NEWSKILLS.
+
diff --git a/doc/sphinx/props/P_AC.rst b/doc/sphinx/props/P_AC.rst
new file mode 100644
index 0000000..77cdb40
--- /dev/null
+++ b/doc/sphinx/props/P_AC.rst
@@ -0,0 +1,45 @@
+P_AC
+====
+
+NAME
+----
+::
+
+     P_AC "ac"
+
+DEFINIERT IN
+------------
+::
+
+     <armour.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property beschreibt die Ruestungsklasse (engl: armour class),
+     also den Schutz, den die Ruestung dem Traeger verleiht. Je hoeher der
+     Wert (als Zahl), um so besser ist die Ruestung. Negative Werte bewirken
+     negativen Schutz, d.h. der Schaden wird vergroessert statt verringert.
+
+BEMERKUNGEN
+-----------
+::
+
+     Query- und Setmethoden auf P_AC sollten unbedingt vermieden werden. Sie
+     fuehren in der Regel zu massiven Inkonsistenzen im Mechanismus der
+     Ruestungsbeschaedigung und -reparatur.
+     Fuer jeden Ruestungstyp ist in <combat.h> eine Obergrenze definiert,
+     die man nicht ueberschreiten darf.
+     Ruestungen vom Typ AT_MISC haben immer AC 0 und werden mit keinen 
+     hoeheren Werten genemigt.
+
+SIEHE AUCH
+----------
+::
+
+     /std/armour.c, P_DAMAGED, Damage() P_TOTAL_AC
+
+
+02.10.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_ACCEPT_PEACE.rst b/doc/sphinx/props/P_ACCEPT_PEACE.rst
new file mode 100644
index 0000000..5b0c580
--- /dev/null
+++ b/doc/sphinx/props/P_ACCEPT_PEACE.rst
@@ -0,0 +1,37 @@
+P_ACCEPT_PEACE
+==============
+
+PROPERTY
+--------
+::
+
+     P_ACCEPT_PEACE                           "accept_peace"
+
+DEFINIERT IN 
+-------------
+::
+
+	/sys/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	Mittels setzen Dieser Prop lassen sich leicht NPCs bauen,
+	die von jedem zu befrieden sind. Wenn die Property == 1 ist,
+	ist der NPC immer wieder befriedbar, sonst fuehrt der NPC das
+	uebliche Verhalten aus.
+
+SIEHE AUCH
+----------
+::
+
+  QueryPacify(),
+  P_PEACE_HISTORY
+
+LETZTE AENDERUNG
+----------------
+::
+
+01.05.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_ACHATS.rst b/doc/sphinx/props/P_ACHATS.rst
new file mode 100644
index 0000000..cca00ee
--- /dev/null
+++ b/doc/sphinx/props/P_ACHATS.rst
@@ -0,0 +1,21 @@
+P_ACHATS
+========
+
+NAME
+----
+::
+
+    P_ACHATS                      "achats"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Chats, die das Monster im Kampf ausgibt.
+
diff --git a/doc/sphinx/props/P_ACHAT_CHANCE.rst b/doc/sphinx/props/P_ACHAT_CHANCE.rst
new file mode 100644
index 0000000..68054e6
--- /dev/null
+++ b/doc/sphinx/props/P_ACHAT_CHANCE.rst
@@ -0,0 +1,21 @@
+P_ACHAT_CHANCE
+==============
+
+NAME
+----
+::
+
+    P_ACHAT_CHANCE                "achat_chance"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wahrscheinlichkeit fuer die Attack-Chat-Ausgabe.
+
diff --git a/doc/sphinx/props/P_ACTUAL_NOTIFY_FAIL.rst b/doc/sphinx/props/P_ACTUAL_NOTIFY_FAIL.rst
new file mode 100644
index 0000000..a69d43d
--- /dev/null
+++ b/doc/sphinx/props/P_ACTUAL_NOTIFY_FAIL.rst
@@ -0,0 +1,50 @@
+P_ACTUAL_NOTIFY_FAIL
+====================
+
+********************** VERALTETE PROPERTY *********************************
+
+NAME
+----
+::
+
+     P_ACTUAL_NOTIFY_FAIL          "actual_notify_fail"          
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player.h
+
+ACHTUNG
+-------
+::
+
+     Diese Prop wird nicht mehr gesetzt (und auch nicht mehr abgefragt), da LD
+     eine efun hat, um das Objekt zu ermitteln, was als letztes ein
+     notify_fail() gesetzt hat, ein Speichern im Spieler also voellig
+     ueberfluessig ist.
+
+BESCHREIBUNG
+------------
+::
+
+     Ist im Spielerobjekt  gesetzt und enthaelt das Objekt, welches zuletzt
+     eine Fehlermeldung mit notify_fail()/_notify_fail() erfolgreich
+     waehrend des aktuellen Kommandos abgespeichert hat.
+
+BEMERKUNGEN
+-----------
+::
+
+     Dient dazu, bei _notify_fail() zu ueberpruefen, ob schon vorher eine
+     Fehlermeldung gesetzt wurde.
+
+SIEHE AUCH
+----------
+::
+
+     AddCmd(), add_action()
+     notify_fail(), _notify_fail()
+
+10.03.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_ADJECTIVES.rst b/doc/sphinx/props/P_ADJECTIVES.rst
new file mode 100644
index 0000000..9357c62
--- /dev/null
+++ b/doc/sphinx/props/P_ADJECTIVES.rst
@@ -0,0 +1,39 @@
+P_ADJECTIVES
+============
+
+NAME
+----
+::
+
+     P_ADJECTIVES "adjectives"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Hier steht ein Array von Strings, welche die Identifizierung des
+     Objektes ergaenzen. Die Verwaltung erfolgt ueber die Funktionen
+     AddAdjective() und RemoveAdjective().
+
+BEMERKUNGEN
+-----------
+::
+
+     Man sollte an dieser Property nicht "von Hand" herumfummeln, sondern
+     immer die zugehoerigen Funktionen benutzen!
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/description.c, AddAdjective(), RemoveAdjective()
+
+
+Last modified: Sun May 19 20:22:24 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_AERIAL_HELPERS.rst b/doc/sphinx/props/P_AERIAL_HELPERS.rst
new file mode 100644
index 0000000..df12a3b
--- /dev/null
+++ b/doc/sphinx/props/P_AERIAL_HELPERS.rst
@@ -0,0 +1,64 @@
+P_AERIAL_HELPERS
+================
+
+NAME
+----
+::
+
+     P_AERIAL_HELPERS "lib_p_aerial_helpers"
+
+DEFINIERT IN
+------------
+::
+
+     <living/helpers.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property kann in allen Lebewesen abgefragt werden, um die Objekte
+     zu ermitteln, die fuer die Unterstuetzung beim Fliegen/Segeln bei diesem 
+     Lebewesen registriert haben. Die Daten werden als Mapping der folgenden
+     Form zurueckgeliefert:
+     ([ Objekt : Rueckgabewert von dessen Callback-Methode ])
+     Eine Erlaeuterung dazu findet sich in der Dokumentation zu 
+     RegisterHelperObject().
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Property kann nur abgefragt werden.
+     Es ist erwuenscht, dass entsprechende, neu geschaffene Stellen jegliche 
+     Helfer akzeptieren, deren Callback-Methode >0 zurueckgibt.
+
+BEISPIEL
+--------
+::
+
+     Um zu ermitteln, ob der Spieler mindestens ein Objekt bei sich hat, das 
+     beim Fliegen hilft, sucht man alle Objekte aus dem Mapping heraus, die
+     einen Wert >0 eingetragen haben und prueft deren Anzahl:
+
+     mapping aerial = this_player()->QueryProp(P_AERIAL_HELPERS);
+     object* helpers = filter( aerial, function int (object h) {
+                         return (aerial[h]>0); });
+     if ( sizeof(helpers) ) {
+       tell_object(this_player(), "Du erhebst Dich mit Hilfe "+
+         helpers[0]->name(WESSEN,1)+" elegant in die Luefte.\n");
+     }
+     else {
+       tell_object(this_player(), "Du hast nichts zum Fliegen bei Dir.\n");
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Methoden:    RegisterHelperObject(L), UnregisterHelperObject(L)
+     Properties:  P_HELPER_OBJECTS, P_AQUATIC_HELPERS
+
+
+12.03.2016, Arathorn
+
diff --git a/doc/sphinx/props/P_AGE.rst b/doc/sphinx/props/P_AGE.rst
new file mode 100644
index 0000000..b75a773
--- /dev/null
+++ b/doc/sphinx/props/P_AGE.rst
@@ -0,0 +1,21 @@
+P_AGE
+=====
+
+NAME
+----
+::
+
+    P_AGE                         "age"                         
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Alter des Spielers in Heart-Beats (1 HB == 2 Sekunden)
+
diff --git a/doc/sphinx/props/P_AGGRESSIVE.rst b/doc/sphinx/props/P_AGGRESSIVE.rst
new file mode 100644
index 0000000..fc5ee1b
--- /dev/null
+++ b/doc/sphinx/props/P_AGGRESSIVE.rst
@@ -0,0 +1,55 @@
+P_AGGRESSIVE
+============
+
+NAME
+----
+::
+
+    P_AGGRESSIVE                  "aggressive"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+	Gesetzt, wenn das Wesen von sich aus Angriffe startet.
+
+	Ueblicherweise nimmt man als Wert 1, man kann jedoch auch
+	einen kleineren Wert nehmen wenn es nur mit einer bestimmten
+	Wahrscheinlichkeit automatisch angreifen soll.
+
+	Der Wert von Spieler und Monster wird addiert, um zu entscheiden,
+	ob ein Spieler angegriffen werden soll,	man kann P_AGGRESSIVE
+	also auch bei Spielern setzen, so dass sie von allen Monstern
+	angegriffen werden.
+
+	Bei Monstern (und NUR bei diesen) kann man hier auch ein Mapping
+	angeben, das als Keys Namen von Properties des Spielers enthaelt
+	und als Values Mappings, in denen steht welcher Wert bei welchen
+	Wert fuer die Property genommen werden soll (Beispiele folgen).
+	Mit Key 0 kann man einen Default-Wert (sowohl in inneren Mappings
+	wie auch im aeusseren Mapping) festlegen. Default-Werte werden
+	genommen, falls keine anderen gesetzt sind, also Vorsicht mit
+	0-Eintraegen (Tip: 0.0 ist in LPC ungleich 0).
+	Bei mehreren Properties werden alle gesetzten Werte gemittelt.
+
+BEISPIELE
+---------
+::
+
+	SetProp(P_AGGRESSIVE,([P_RACE:(["Zwerg":1, "Elf":0.0, 0:0.5])]))
+	Zwerge werden immer automatisch angegriffen, Elfen nie und
+	alle anderen mit 50% Wahrscheinlichkeit.
+	Man beachte, dass hier 0.0 genommen werden musste anstelle von 0,
+	weil sonst Elfen auch 50% Wahrscheinlichkeit bekommen haetten.
+
+	SetProp(P_AGGRESSIVE,([P_RACE:(["Zwerg":0.3]),
+	                       P_GUILD:(["Chaos":0.7])]))
+	Zwerge werden mit 30% Wahrscheinlichkeit angegriffen,
+	Chaoten mit 70% und Zwerg-Chaoten mit 50%.
+
diff --git a/doc/sphinx/props/P_ALCOHOL.rst b/doc/sphinx/props/P_ALCOHOL.rst
new file mode 100644
index 0000000..7c29af5
--- /dev/null
+++ b/doc/sphinx/props/P_ALCOHOL.rst
@@ -0,0 +1,37 @@
+P_ALCOHOL
+=========
+
+NAME
+----
+::
+
+     P_ALCOHOL			"alcohol"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     - Lebewesen
+       Numerischer Wert fuer den Grad der Betrunkenheit eines Lebewesens.
+       Der maximale Wert steht in P_MAX_ALCOHOL.
+
+     - Speisen/Kneipen
+       Numerischer Wert fuer den Grad, den eine Portion der Speise den
+       Konsumenten betrunken macht
+
+SIEHE AUCH
+----------
+::
+
+	P_MAX_ALCOHOL, P_ALCOHOL_DELAY, consume,
+	P_FOOD, P_DRINK, wiz/food, 
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_ALCOHOL_DELAY.rst b/doc/sphinx/props/P_ALCOHOL_DELAY.rst
new file mode 100644
index 0000000..d0626a5
--- /dev/null
+++ b/doc/sphinx/props/P_ALCOHOL_DELAY.rst
@@ -0,0 +1,23 @@
+P_ALCOHOL_DELAY
+===============
+
+NAME
+----
+::
+
+    P_ALCOHOL_DELAY                 "alcohol_delay"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der heart_beats, bis P_ALCOHOL um einen Punkt sinkt.
+     Aenderungen dieser Property in Spielern beduerfen der 
+     Genehmigung des EM fuer Balance.
+
diff --git a/doc/sphinx/props/P_ALC_FULL_MSG.rst b/doc/sphinx/props/P_ALC_FULL_MSG.rst
new file mode 100644
index 0000000..3d6e160
--- /dev/null
+++ b/doc/sphinx/props/P_ALC_FULL_MSG.rst
@@ -0,0 +1,50 @@
+P_ALC_FULL_MSG
+==============
+
+NAME
+----
+::
+
+     P_ALC_FULL_MSG                "std_food_alc_full_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn Alkohol konsumiert werden soll,
+     obwohl dieser nicht mehr Alkohol vertraegt.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "Soviel Alkohol vertraegst Du nicht mehr."
+
+SIEHE AUCH
+----------
+::
+
+     P_ALCOHOL, P_MAX_ALCOHOL, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_ALIGN.rst b/doc/sphinx/props/P_ALIGN.rst
new file mode 100644
index 0000000..fd944b2
--- /dev/null
+++ b/doc/sphinx/props/P_ALIGN.rst
@@ -0,0 +1,30 @@
+P_ALIGN
+=======
+
+NAME
+----
+::
+
+    P_ALIGN                       "align"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Numerischer Wert fuer Gut- oder Boesheit des Wesens.
+
+     Kann Werte von -1000 (Boese wie der Teufel hoechstpersoenlich)
+     bis +1000 (Jesus, bist Du's ?) annehmen.
+
+     Werte ausserhalb dieser Skala werden zwar teilweise verwendet,
+     das Setzen derselben sollte jedoch UNBEDINGT unterbleiben.
+
+
+Last modified: Sat Jul 12 17:00:00 by Mandragon
+
diff --git a/doc/sphinx/props/P_ALLOWED_SHADOW.rst b/doc/sphinx/props/P_ALLOWED_SHADOW.rst
new file mode 100644
index 0000000..d6578e4
--- /dev/null
+++ b/doc/sphinx/props/P_ALLOWED_SHADOW.rst
@@ -0,0 +1,38 @@
+P_ALLOWED_SHADOW
+================
+
+NAME
+----
+::
+
+    P_ALLOWED_SHADOW              "allowed_shadow"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Normalerweise koennen nur Shadows an Spieler gebunden werden, die in 
+     /std/player/shadows/ liegen. 
+
+     
+
+     Zu Testzwecken kann in dieser Property der Pfad eines Shadows eingetragen
+     werden. Damit wird die oben beschriebene Regel fuer diesen Spieler und 
+     diesen Shadow ausser Kraft gesetzt.
+
+BEMERKUNG: 
+
+     Der Spieler muss ein Testspieler sein. Ansonsten wird diese Property
+     ignoriert.
+
+     Die Property ist secured gesetzt. Das heisst, nur EM+ koennen
+     diese Property setzen und loeschen.
+
+Last modified: Sun Mar 21 00:27:46 2004 by Vanion
+
diff --git a/doc/sphinx/props/P_AMMUNITION.rst b/doc/sphinx/props/P_AMMUNITION.rst
new file mode 100644
index 0000000..f2a281d
--- /dev/null
+++ b/doc/sphinx/props/P_AMMUNITION.rst
@@ -0,0 +1,62 @@
+P_AMMUNITION
+============
+
+NAME
+----
+::
+
+    P_AMMUNITION     "munition"
+
+DEFINIERT IN
+------------
+::
+
+    <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die fuer eine Waffe gueltige Munition als String. Die
+    Munition muss diesen String als ID besitzen.
+
+    Fuer die Munitionsobjekte gilt:
+    * es kann ein Skill am Spieler definiert werden, dieser wirkt dann
+      zusaetzlich zum generellen SK_SHOOT-Skill.
+    * sie koennen eine HitFunc besitzten, die beim Schuss abgefragt wird
+
+BEMERKUNGEN
+-----------
+::
+
+    Bitte das #define MUN_MISC(x) benutzen. Munition sollte auch immer
+    in Deutsch und Plural angegeben werden, da P_AMMUNITION direkt
+    fuer Ausgaben an den Spieler ausgewertet wird.
+
+    Momentan sind vier Munitionsarten in der combat.h vordefiniert:
+    MUN_ARROW, MUN_STONE, MUN_BOLT, MUN_MISC
+
+BEISPIELE
+---------
+::
+
+    // fuer ein kleines Blasrohr im Blasrohr
+    SetProp(P_AMMUNITION, MUN_MISC("Erbsen"));
+
+    // Entsprechend in der Munition:
+    AddId(MUN_MISC("Erbsen"));
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_SHOOTING_WC, P_STRETCH_TIME
+    Methoden:  FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
+    Gebiet:    P_RANGE, P_SHOOTING_AREA, P_TARGET_AREA
+    Waffen:    P_WEAPON_TYPE, P_WC, P_EQUIP_TIME, P_NR_HANDS
+    Kampf:     Attack(L), Defend(L), P_DISABLE_ATTACK, P_ATTACK_BUSY
+    Team:      PresentPosition(L)
+    Sonstiges: fernwaffen
+
+29.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/props/P_AMOUNT.rst b/doc/sphinx/props/P_AMOUNT.rst
new file mode 100644
index 0000000..632880a
--- /dev/null
+++ b/doc/sphinx/props/P_AMOUNT.rst
@@ -0,0 +1,21 @@
+P_AMOUNT
+========
+
+NAME
+----
+::
+
+    P_AMOUNT                      "amount"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der Objekte, fuer die das Objekt steht.
+
diff --git a/doc/sphinx/props/P_AQUATIC_HELPERS.rst b/doc/sphinx/props/P_AQUATIC_HELPERS.rst
new file mode 100644
index 0000000..6055df9
--- /dev/null
+++ b/doc/sphinx/props/P_AQUATIC_HELPERS.rst
@@ -0,0 +1,65 @@
+P_AQUATIC_HELPERS
+=================
+
+NAME
+----
+::
+
+     P_AQUATIC_HELPERS "lib_p_aquatic_helpers"
+
+DEFINIERT IN
+------------
+::
+
+     <living/helpers.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property kann in allen Lebewesen abgefragt werden, um die Objekte
+     zu ermitteln, die fuer die Unterstuetzung beim Tauchen bei diesem 
+     Lebewesen registriert haben. Die Daten werden als Mapping der folgenden
+     Form zurueckgeliefert:
+     ([ Objekt : Rueckgabewert von dessen Callback-Methode ])
+     Eine Erlaeuterung dazu findet sich in der Dokumentation zu 
+     RegisterHelperObject().
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Property kann nur abgefragt werden.
+     Es ist erwuenscht, dass entsprechende, neu geschaffene Stellen jegliche 
+     Helfer akzeptieren, deren Callback-Methode >0 zurueckgibt.
+
+BEISPIEL
+--------
+::
+
+     Um zu ermitteln, ob der Spieler mindestens ein Objekt bei sich hat, das 
+     beim Tauchen hilft, sucht man alle Objekte aus dem Mapping heraus, die
+     einen Wert >0 eingetragen haben und prueft deren Anzahl:
+
+     mapping aquatic = this_player()->QueryProp(P_AQUATIC_HELPERS);
+     object* helpers = filter( aquatic, function int (object h) {
+                         return (aquatic[h]>0); });
+     if ( sizeof(helpers) ) {
+       tell_object(this_player(), "Du stuerzt Dich in die Fluten und "
+         "stellst ueberrascht fest, dass Du mit Hilfe "+
+         helpers[0]->name(WESSEN,1)+" sogar unter Wasser atmen kannst!\n");
+     }
+     else {
+       tell_object(this_player(), "Du hast nichts zum Tauchen bei Dir.\n");
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Methoden:    RegisterHelperObject(L), UnregisterHelperObject(L)
+     Properties:  P_HELPER_OBJECTS, P_AERIAL_HELPERS
+
+
+06.04.2016, Arathorn
+
diff --git a/doc/sphinx/props/P_ARMOURS.rst b/doc/sphinx/props/P_ARMOURS.rst
new file mode 100644
index 0000000..3268fda
--- /dev/null
+++ b/doc/sphinx/props/P_ARMOURS.rst
@@ -0,0 +1,41 @@
+P_ARMOURS
+=========
+
+NAME
+----
+::
+
+     P_ARMOURS                     "armours"
+
+DEFINIERT IN
+------------
+::
+
+     <living/combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Array mit den getragenen Schutzbekleidungen des Lebewesen.
+
+     Bitte nach Moeglichkeit davon absehen, diese Property zu beschreiben, da
+     es hierbei zu Inkonsistenzen kommen kann.
+
+     
+
+     Falls ihr die Ruestungen des Lebewesens, ggf. mit bestimten Kriterien,
+     ermitteln wollt, benutzt hierfuer bitte die Funktion FilterArmours()
+     statt selber ueber dieses Array zu laufen.
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt:		QueryArmourByType(L), P_WEAPON, FilterClothing(), 
+                  FilterArmours()
+     Ruestungen:	P_AC, P_ARMOUR_TYPE, P_NR_HANDS
+     Sonstiges:		P_EQUIP_TIME, P_LAST_USE
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_ARMOUR_TYPE.rst b/doc/sphinx/props/P_ARMOUR_TYPE.rst
new file mode 100644
index 0000000..71f1bfb
--- /dev/null
+++ b/doc/sphinx/props/P_ARMOUR_TYPE.rst
@@ -0,0 +1,63 @@
+P_ARMOUR_TYPE
+=============
+
+NAME
+----
+::
+
+     P_ARMOUR_TYPE "armour_type"
+
+DEFINIERT IN
+------------
+::
+
+     <armour.h>
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property wird der Typ einer Ruestung festgehalten. Man sollte
+     hier nur die in <combat.h> definierten Konstanten verwenden:
+
+        AT_AMULET     Amulett
+        AT_ARMOUR     Ruestung
+        AT_BELT       Guertel
+        AT_BOOT       Schuhe
+        AT_CLOAK      Umhang
+        AT_GLOVE      Handschuhe
+        AT_HELMET     Helm
+        AT_QUIVER     Koecher
+        AT_RING       Ring
+        AT_SHIELD     Schild
+        AT_TROUSERS   Hosen
+        AT_MISC       Sonstiges
+
+     Der Ruestungstyp AT_MISC ist schnoedem Tand und anderem nutzlosen
+     Kram vorbehalten. Auf keinen Fall darf eine AT_MISC-Ruestung ueber
+     eine AC > 0 verfuegen noch irgendwie kampfrelevante Bedeutung be-
+     sitzen. Ruestungen des Typs AT_MISC, die KEINE DefendFunc benoetigen,
+     muessen mittels /std/clothing als einfaches Kleidungsstueck realisiert
+     werden.
+
+BEMERKUNGEN
+-----------
+::
+
+     Die P_AC wird bei AT_MISC-Ruestungen gar nicht erst ausgewertet.
+     DefendFuncs werden zwar ausgewertet, aber bitte ueberlegt euch gut, ob
+     ihr sie braucht (Rechenzeit im Kampf ist kritisch!) und ob sie seitens 
+     der Balance in eurem Fall erlaubt sind.
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt:          QueryArmourByType(L), P_WEAPON
+     Ruestungen:        P_AC, P_NR_HANDS (Schilde)
+     Sonstiges:         P_EQUIP_TIME, P_LAST_USE
+     Code:              /std/armour.c, /std/clothing.c
+     Gildenergaenzung:  P_GLOVE_FINGERLESS
+
+27. Mai 2015, Arathorn
+
diff --git a/doc/sphinx/props/P_ARRIVEMSG.rst b/doc/sphinx/props/P_ARRIVEMSG.rst
new file mode 100644
index 0000000..73b3ac9
--- /dev/null
+++ b/doc/sphinx/props/P_ARRIVEMSG.rst
@@ -0,0 +1,21 @@
+P_ARRIVEMSG
+===========
+
+NAME
+----
+::
+
+    P_ARRIVEMSG                   "arrivemsg"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung, wenn der Transporter anlegt.
+
diff --git a/doc/sphinx/props/P_ARTICLE.rst b/doc/sphinx/props/P_ARTICLE.rst
new file mode 100644
index 0000000..363cd08
--- /dev/null
+++ b/doc/sphinx/props/P_ARTICLE.rst
@@ -0,0 +1,28 @@
+P_ARTICLE
+=========
+
+NAME
+----
+::
+
+    P_ARTICLE                     "article"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/language.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt an, ob in der Beschreibung ein Artikel ausgegeben werden soll
+     oder nicht.
+
+     Wenn ein Artikel angegeben werden soll, so wird 1 gesetzt, sonst 0.
+     Diese Property ist aus historischen Gruenden auf 1 voreingestellt
+     und intern invertiert. (d.h., beim Auslesen per Query kommt als 
+     Ergebnis genau das falsche heraus). Bitte beachtet das bei Set- bzw.
+     Query-Funktionen.
+
diff --git a/doc/sphinx/props/P_ATTACK_BUSY.rst b/doc/sphinx/props/P_ATTACK_BUSY.rst
new file mode 100644
index 0000000..3e15aef
--- /dev/null
+++ b/doc/sphinx/props/P_ATTACK_BUSY.rst
@@ -0,0 +1,69 @@
+P_ATTACK_BUSY
+=============
+
+NAME
+----
+::
+
+    P_ATTACK_BUSY                 "attack_busy"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    Ueber diese Property kann festgestellt werden, ob ein Spieler noch 
+    Spezialwaffen (zB Flammenkugel) einsetzen kann.
+
+    
+
+    Ist der Wert bei Abfrage ungleich 0, dann darf der Spieler in dieser
+    Runde keine Aktion mehr durchfuehren. Mit SetProp(P_ATTACK_BUSY, 1)
+    wird eine Aktion verbraucht.
+
+    Intern wird relativ fein gerechnet, ein SetProp(P_ATTACK_BUSY, x)
+    wird in das Abziehen von x*100 Punkten umgerechnet. Der Wert freier
+    Aktionen pro Runde berechnet sich wie folgt:
+
+    
+
+    Spieler: 100 + QuerySkillAttribute(SA_SPEED)
+    Seher:   Spieler + 200 + QueryProp(P_LEVEL)
+
+    Das Maximum liegt bei 500.
+    Damit betraegt die Anzahl der moeglichen Aktionen pro Runde: Wert/100,
+    also maximal 5 Aktionen pro Runde.
+
+    Zaubersprueche zaehlen im Normalfall auch als eine Aktion.
+
+BEMERKUNGEN
+-----------
+::
+
+    Benutzt man P_ATTACK_BUSY fuer eine sich nicht sofort verbrauchende
+    Sache, kann ein Seher dieses Objekt im Normalfall dreimal pro Runde
+    benutzen. Wenn ungewollt, muss das ueber einen Zeitmarker selbst
+    verhindert werden.
+
+    
+
+BEISPIELE
+---------
+::
+
+    (Code eines Objektes ist in
+     /doc/beispiele/testobjekte/attack_busy_sensitive_testobj.c)
+    // einfacher Test auf ATTACK_BUSY und anschliessendes Setzen
+    if (this_player()->QueryProp(P_ATTACK_BUSY)) {
+      write("Du hast dafuer momentan einfach nicht mehr die Puste.\n");
+      return 1;
+    }
+    this_player()->SetProp(P_ATTACK_BUSY, 1);
+
+7. Mar 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_ATTRIBUTES.rst b/doc/sphinx/props/P_ATTRIBUTES.rst
new file mode 100644
index 0000000..d3bbc0e
--- /dev/null
+++ b/doc/sphinx/props/P_ATTRIBUTES.rst
@@ -0,0 +1,80 @@
+P_ATTRIBUTES
+============
+
+NAME
+----
+::
+
+	P_ATTRIBUTES			"attributes"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt ein Mapping mit den Attributen des
+	Lebewesens. Die Schluessel kennzeichnen hierbei das jeweilige
+	Attribut. Die verschiedenen Standardattribute findet man in
+	/sys/living/attributes.h, welche derzeit folgende Moeglichkeiten
+	bieten:	- A_STR (Kraft)
+		- A_INT (Intelligenz)
+		- A_DEX (Geschick)
+		- A_CON (Konstitution)
+	Sie werden automatisch an verschiedenen Stellen in der MUDLib
+	ausgewertet, zum Beispiel bestimmt A_INT die maximal moeglichen
+	Konzentrationspunkte und A_CON die maximal moeglichen Lebenspunkte.
+
+BEMERKUNGEN
+-----------
+::
+
+        Keine echte Property, _query_attributes() und _set_attributes() sind 
+        in /std/living/attributes.c implementiert.
+
+	Es bietet sich an, zum Erfragen der Attributwerte die Funktion
+	QueryAttribute() zu nutzen, da es auch moegliche Offsets gibt,
+	so beispielsweise ueber die Properties P_ATTRIBUTES_OFFSETS bzw.
+	P_ATTRIBUTES_MODIFIER im Lebewesen selbst, oder auch ueber
+	P_X_ATTR_MOD bzw. P_M_ATTR_MOD in Objekten im Lebewesen.
+	Kurzfristige zeit- oder objektgebundene Attributveraenderungen
+	koennen ueber die Property P_TIMED_ATTR_MOD realisiert werden.
+
+	Es gibt auch zahlreiche andere Dienstfunktionen fuer diesen sehr
+	balancekritischen Bereich, siehe unten.
+
+BEISPIEL
+--------
+::
+
+	Ein moegliches Ergebnis fuer einen frischen Level 1 Spieler waere:
+	  QueryProp(P_ATTRIBUTES);
+	  Ergebnis: (["int":1,"con":1,"str":1,"dex":1])
+	Hinzu kommen eventuell moegliche Rassenboni, die mittels
+	P_ATTRIBUTE_OFFSETS realisiert werden, Zwerge sind beispielsweise
+	recht stark:
+	  QueryProp(P_ATTRIBUTES_OFFSETS);
+	  Ergebnis: (["int":1,"con":1,"str":1,"dex":3])
+	Jetzt bekaeme man (sofern keine weiteren Offsets realisiert sind)
+	mittels QueryAttribute() insgesamt:
+	  QueryAttribute(A_DEX);
+	  Ergebnis: 4
+
+SIEHE AUCH
+----------
+::
+
+	QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+	SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+	SetTimedAttrModifier(), QueryTimedAttrModifier(),
+	DeleteTimedAttrModifier(),
+	P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,P_TIMED_ATTR_MOD,
+	P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/props/P_ATTRIBUTES_MODIFIER.rst b/doc/sphinx/props/P_ATTRIBUTES_MODIFIER.rst
new file mode 100644
index 0000000..872de97
--- /dev/null
+++ b/doc/sphinx/props/P_ATTRIBUTES_MODIFIER.rst
@@ -0,0 +1,78 @@
+P_ATTRIBUTES_MODIFIER
+=====================
+
+NAME
+----
+::
+
+    P_ATTRIBUTES_MODIFIER         "attributes_modifier"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Property werden Attribut-Modifikatoren gespeichert, die
+    laengere Zeit wirksam sein sollen, tlw. auch ueber einen Reboot
+    hinweg.
+    Intern werden die Modifikatoren in einem Mapping der Form
+
+        ([ Setzer-Key : ([ A_xy : Wert, ... ]) , ... ])
+
+    gespeichert. Das Setzen folg hingegen in der Form
+
+        spieler->SetProp(P_ATTRIBUTES_MODIFIER, ([ A_xy : Wert, ... ]));
+    oder
+        spieler->SetProp(P_ATTRIBUTES_MODIFIER, ({ Setzer-Key, ([ ... ]) }));
+
+    Bei der ersten Variante wird hierbei der Filename des setzenden Objektes
+    als Setzer-Key genommen.
+    Es koennen also durchaus von mehreren Objekten Modifier gesetzt werden.
+    Bekannte Modifier sind:
+
+        #death      Attribut-Abzug durch Todesfolgen      (Mudlib)
+        #drain      Statabzug durch NPCs                  (Paracelsus)
+        #frosch     Staerken-Abzug bei Froeschen          (Mudlib)
+
+BEMERKUNGEN
+-----------
+::
+
+    Keine echte Property, _query_attributes_modifier() und
+    _set_attributes_modifier() sind in /std/living/attributes.c
+    implementiert
+    - SetProp/QueryProp nutzen!
+    - Wenn ein Modifier nicht mehr gebracht wird, nicht die Attributswerte auf
+      0 setzen, sondern den ganzen Eintrag! also:
+      SetProp(P_ATTRIBUTES_MODIFIER, ([]) );
+      oder: SetProp(P_ATTRIBUTES_MODIFIER, 0 ); 
+      aber nicht: SetProp(P_ATTRIBUTES_MODIFIER, ([A_STR:0]));
+
+BEISPIELE
+---------
+::
+
+    // ein Bonus ... 'ende'-fest (muss also per uid gesichert werden)
+    player->SetProp(P_ATTRIBUTES_MODIFIER,
+                    ({"g_klerus_segen", ([A_CON:5, A_INT:5])}));
+    ...
+    player->SetProp(P_ATTRIBUTES_MODIFIER, ({"g_klerus_segen", 0}));
+
+SIEHE AUCH
+----------
+::
+
+	QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+	SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+	SetTimedAttrModifier(), QueryTimedAttrModifier(),
+	DeleteTimedAttrModifier(),
+	P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+	P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/props/P_ATTRIBUTES_OFFSETS.rst b/doc/sphinx/props/P_ATTRIBUTES_OFFSETS.rst
new file mode 100644
index 0000000..a17993e
--- /dev/null
+++ b/doc/sphinx/props/P_ATTRIBUTES_OFFSETS.rst
@@ -0,0 +1,46 @@
+P_ATTRIBUTES_OFFSETS
+====================
+
+NAME
+----
+::
+
+	P_ATTRIBUTES_OFFSETS		"attributes_offsets"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt ein Mapping mit Offsets, die zu den
+	Attributen eine Lebewesens addiert werden. Diese koennen auch
+	negativ sein! Realisiert werden damit beispielsweise Rassenboni.
+	Es gibt noch weitere Moeglichkeiten, Attributoffsets anzugeben.
+	Fuer weiteres siehe P_ATTRIBUTES.
+
+BEMKERUNGEN
+-----------
+::
+
+        Keine echte Property, _query_attributes_offsets() und 
+        _set_attributes_offsets() sind in /std/living/attributes.c 
+        implementiert.
+
+SIEHE AUCH
+----------
+::
+
+	QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+	SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+	SetTimedAttrModifier(), QueryTimedAttrModifier(),
+	DeleteTimedAttrModifier(),
+	P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
+	P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/props/P_AUTH_INFO.rst b/doc/sphinx/props/P_AUTH_INFO.rst
new file mode 100644
index 0000000..357fe6d
--- /dev/null
+++ b/doc/sphinx/props/P_AUTH_INFO.rst
@@ -0,0 +1,21 @@
+P_AUTH_INFO
+===========
+
+NAME
+----
+::
+
+    P_AUTH_INFO                   "auth_info"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Username des Spielers, wenn bei ihm ein AUTHD laeuft
+
diff --git a/doc/sphinx/props/P_AUTOLOAD.rst b/doc/sphinx/props/P_AUTOLOAD.rst
new file mode 100644
index 0000000..31372c1
--- /dev/null
+++ b/doc/sphinx/props/P_AUTOLOAD.rst
@@ -0,0 +1,31 @@
+P_AUTOLOAD
+==========
+
+NAME
+----
+::
+
+    P_AUTOLOAD                    "autoload"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mapping mit der Menge der Autoloadobjekte und den zugeh.
+     Properties.
+
+BEMERKUNGEN
+-----------
+::
+
+     Funktioniert momentan nicht. Die Methode wurde entfernt. Doku bleibt
+     hier bis der Fall geklaert ist. (Stand 27.Aug 2006)
+
+27.Aug 2006 Gloinson
+
diff --git a/doc/sphinx/props/P_AUTOLOADOBJ.rst b/doc/sphinx/props/P_AUTOLOADOBJ.rst
new file mode 100644
index 0000000..d4a0a00
--- /dev/null
+++ b/doc/sphinx/props/P_AUTOLOADOBJ.rst
@@ -0,0 +1,141 @@
+P_AUTOLOADOBJ
+=============
+
+NAME
+----
+::
+
+    P_AUTOLOADOBJ                 "autoloadobj"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Hiermit kann prinzipiell angegeben werden ob ein Objekt ueber das
+     Ausloggen eines Spielers (Reboot/ende) behalten werden soll.
+
+     Als Inhalt der Property koennen permanente Eigenschaften des Objektes
+     angegeben werden.
+     Beim Einloggen wird das Objekt neu erzeugt und P_AUTOLOADOBJ auf die
+     gespeicherten Werte gesetzt. Die Werte muessen allerdings selbst
+     verwaltet werden.
+
+     Bitte geht nicht davon aus, dass es waehrend des Setzens/Abfragens dieser
+     Prop einen this_player() oder ein this_interactive() geben muss.
+     Speziell ist this_interactive() nicht == /secure/login!
+     Ebenfalls muss das Objekt beim Setzen/Abfragen nicht in einem Spieler
+     sein.
+
+BEMERKUNGEN
+-----------
+::
+
+     Autoloadobjekte werden beim Ausloggen nicht fallengelassen!
+
+BEISPIELE
+---------
+::
+
+     ## Variante 1: simples Objekt, bleibt einfach nur erhalten,
+     ##             Variablen werden nicht gesichert ##
+     void create() {
+      ...
+      SetProp(P_AUTOLOADOBJ,1);
+      ...
+     }
+
+
+     ## Variante 2: Speicherung mehrerer Variablen ueber
+     ##             P_AUTOLOADOBJ (elegante Verwaltung)
+
+     // ein paar #defines fuer die Plaetze in der Speichervariablen
+     #define MY_AL_SHORT    0
+     #define MY_AL_ATTRM    1
+     #define MY_AL_OWNER    2
+     #define MY_AL_DESTRUCT 3
+
+     // die Variablen, die erhalten bleiben sollen
+     static object owner;
+     static int destruct_time;
+
+     // diese hier wird gerufen, wenn der Spieler gespeichert wird,
+     // wir packen also alle aktuellen Variablen in eine und geben die
+     // zum Speichern heraus ... wir nehmen hier ein Array (statt
+     // zB eines Mappings), weil das am wenigsten Platz braucht
+     static mixed* _query_autoloadobj() {
+      mixed *ret;
+      ret=allocate(4);
+      ret[MY_AL_SHORT] = QueryProp(P_SHORT);      // SHORT merken
+      ret[MY_AL_ATTRM] = QueryProp(P_M_ATTR_MOD); // einen Modifikator merken
+      ret[MY_AL_OWNER] = getuid(owner);           // ah, ein Besitzer!
+      ret[MY_AL_DESTRUCT]=destruct_time-time();   // und eine Lebensdauer!
+
+      return ret;
+
+      /*
+      // normalerweise wuerde man das einfach so schreiben:
+      return (({QueryProp(P_SHORT),
+                QueryProp(P_M_ATTR_MOD),
+                getuid(owner),
+                destruct_time-time()}));
+      */
+     }
+
+     // diese hier wird gerufen, wenn das Objekt neu im Spieler
+     // erzeugt wurde (Login), also packen wir das Speicherarray wieder
+     // aus und in alle entsprechenden Variablen
+     static mixed* _set_autoloadobj(mixed *new) {
+      // wenn das Format nicht mit dem oben uebereinstimmt ist was
+      // schiefgelaufen
+      if(pointerp(new) && !owner && sizeof(new)>4 &&
+         (owner=find_player(new[MY_AL_OWNER]))) {
+       // los, zuweisen!
+
+       SetProp(P_SHORT,      new[MY_AL_SHORT]);
+       SetProp(P_M_ATTR_MOD, new[MY_AL_ATTRM]);
+       destruct_time=        time()+new[MY_AL_DESTRUCT];
+
+       call_out(#'remove,new[3]);
+      } else call_out(#'remove,0);
+
+      return new;
+     }
+
+
+     ## Variante 3: und das gleiche mit Set/Querymethoden ##
+     // Prototypen fuer Set und Query-Methoden -> man Set
+     static mixed *my_query_autoloadobj();
+     static mixed *my_set_autoloadobj(mixed *new);
+
+     void create() {
+      // Binden der Methoden
+      Set(P_AUTOLOADOBJ, #'my_query_autoloadobj, F_QUERY_METHOD);
+      Set(P_AUTOLOADOBJ, #'my_set_autoloadobj, F_SET_METHOD);
+
+      // die werden nur von mir veraendert!
+      Set(P_AUTOLOADOBJ, PROTECTED, F_MODE_AS);
+      ...
+     }
+
+     static mixed *my_query_autoloadobj () {
+       // s.o.
+     }
+
+     static mixed *my_set_autoloadobj (mixed *new) {
+       // s.o.
+     }
+
+SIEHE AUCH
+----------
+::
+
+     P_AUTOLOAD, SetProp
+
+24.Aug.2006 Gloinson@MG
+
diff --git a/doc/sphinx/props/P_AVATAR_URI.rst b/doc/sphinx/props/P_AVATAR_URI.rst
new file mode 100644
index 0000000..3657d03
--- /dev/null
+++ b/doc/sphinx/props/P_AVATAR_URI.rst
@@ -0,0 +1,44 @@
+P_AVATAR_URI
+============
+
+NAME
+----
+::
+
+    P_AVATAR_URI                    "p_lib_avataruri"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Lebewesen speichern in der Prop P_AVATAR_URI eine URI (string), welche auf
+    ein Bild im Netz verweist, welches ein Client fuer dieses Lebewesen
+    anzeigen kann.
+    Spieler koennen diese Avatar-URI mit dem Befehl 'avatar' anzeigen,
+    aendern und loeschen.
+    Avatar-URIs anderer Spieler lassen sich mit 'finger -a' ausgeben.
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Property kann nur vom Spieler oder einem EM modifiziert werden.
+
+SIEHE AUCH
+----------
+::
+
+    avatar
+
+LETZTER AENDERUNG
+-----------------
+::
+
+    03.9.2011, Zesstra
+
diff --git a/doc/sphinx/props/P_AVERAGE_SIZE.rst b/doc/sphinx/props/P_AVERAGE_SIZE.rst
new file mode 100644
index 0000000..b63f8da
--- /dev/null
+++ b/doc/sphinx/props/P_AVERAGE_SIZE.rst
@@ -0,0 +1,21 @@
+P_AVERAGE_SIZE
+==============
+
+NAME
+----
+::
+
+    P_AVERAGE_SIZE                "average_size"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Durchschnittliche Groesse eines Wesens dieser Rasse (derzeit nur Player)
+
diff --git a/doc/sphinx/props/P_AVERAGE_WEIGHT.rst b/doc/sphinx/props/P_AVERAGE_WEIGHT.rst
new file mode 100644
index 0000000..fbcddeb
--- /dev/null
+++ b/doc/sphinx/props/P_AVERAGE_WEIGHT.rst
@@ -0,0 +1,21 @@
+P_AVERAGE_WEIGHT
+================
+
+NAME
+----
+::
+
+    P_AVERAGE_WEIGHT                "average_weight"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Durchschnittliche Gewicht eines Wesens dieser Rasse (derzeit nur Player)
+
diff --git a/doc/sphinx/props/P_AWAY.rst b/doc/sphinx/props/P_AWAY.rst
new file mode 100644
index 0000000..54ea447
--- /dev/null
+++ b/doc/sphinx/props/P_AWAY.rst
@@ -0,0 +1,21 @@
+P_AWAY
+======
+
+NAME
+----
+::
+
+    P_AWAY                        "away"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     String der ausgegeben wird, wenn man weg ist und eine Mitteilung bekommt.
+
diff --git a/doc/sphinx/props/P_BAD_MSG.rst b/doc/sphinx/props/P_BAD_MSG.rst
new file mode 100644
index 0000000..26f1104
--- /dev/null
+++ b/doc/sphinx/props/P_BAD_MSG.rst
@@ -0,0 +1,53 @@
+P_BAD_MSG
+=========
+
+NAME
+----
+::
+
+     P_BAD_MSG                     "std_food_bad_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung, wenn eine Speise gerade verdirbt.
+     Befindet sich die Speise in einem Spieler, geht die Meldung an genau
+     diesen, liegt die Speise im Raum, geht die Meldung an alle anwesenden
+     Spieler.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "@WER1 verdirbt."
+
+SIEHE AUCH
+----------
+::
+
+     P_LIFETIME, P_RESET_LIFETIME, P_NO_BAD,
+     wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_BLIND.rst b/doc/sphinx/props/P_BLIND.rst
new file mode 100644
index 0000000..2592794
--- /dev/null
+++ b/doc/sphinx/props/P_BLIND.rst
@@ -0,0 +1,57 @@
+P_BLIND
+=======
+
+NAME
+----
+::
+
+    P_BLIND                       "blind"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/viewcmd.h
+
+BESCHREIBUNG
+------------
+::
+
+    1, wenn der Spieler blind ist und nichts mehr sehen kann.
+
+    Wird von CannotSee() bei 'schau' und Betreten von Raeumen 
+    u.ae. ausgewertet.
+
+    P_BLIND kann auch auf einen String gesetzt werden, der 
+    dann statt des 'Du bist blind' ausgegeben wird.
+
+BEISPIELE
+---------
+::
+
+    this_player()->SetProp(P_BLIND,1);
+
+    this_player()->SetProp(P_BLIND,"Du hast Dir vorhin so schoen die "
+                                  +"Augen ausgekratzt ... deswegen "
+                                  +"siehst Du nun nichts mehr.\n");    
+
+BEMERKUNGEN
+-----------
+::
+
+    Um herauszufinden, ob ein Spieler etwas sehen kann oder nicht,
+    sollte man lieber if(this_player()->CannotSee() != 0) pruefen
+    statt if(this_player()->QueryProp(P_BLIND)).
+
+    Denn CannotSee() beruecksichtigt auch Nachtsicht (bzw. hier 
+    eine nicht aktivierte) und die Lichtmodifikatoren.
+
+SIEHE AUCH
+----------
+::
+
+    P_LIGHT_MODIFIER, P_PLAYER_LIGHT, CannotSee
+
+
+Letzte Aenderung: Sa 02.11.02, 00:30:00 Uhr, von Tilly
+
diff --git a/doc/sphinx/props/P_BODY.rst b/doc/sphinx/props/P_BODY.rst
new file mode 100644
index 0000000..5fbb13c
--- /dev/null
+++ b/doc/sphinx/props/P_BODY.rst
@@ -0,0 +1,22 @@
+P_BODY
+======
+
+NAME
+----
+::
+
+    P_BODY                        "body"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Numerischer Wert fuer die Abwehrstaerke des blanken Koerpers
+     des Wesens.
+
diff --git a/doc/sphinx/props/P_BRIEF.rst b/doc/sphinx/props/P_BRIEF.rst
new file mode 100644
index 0000000..d50f389
--- /dev/null
+++ b/doc/sphinx/props/P_BRIEF.rst
@@ -0,0 +1,21 @@
+P_BRIEF
+=======
+
+NAME
+----
+::
+
+    P_BRIEF                       "brief"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/viewcmd.h
+
+BESCHREIBUNG
+------------
+::
+
+     Ist gesetzt, wenn der Spieler nur die Kurzbeschreibung sehen will.
+
diff --git a/doc/sphinx/props/P_BUFFER.rst b/doc/sphinx/props/P_BUFFER.rst
new file mode 100644
index 0000000..dc67f66
--- /dev/null
+++ b/doc/sphinx/props/P_BUFFER.rst
@@ -0,0 +1,21 @@
+P_BUFFER
+========
+
+NAME
+----
+::
+
+    P_BUFFER                      "buffer"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+    Zeigt an, ob der Kobold des Spielers aktiv oder nicht aktiv ist.
+
diff --git a/doc/sphinx/props/P_BUY_ONLY_PLANTS.rst b/doc/sphinx/props/P_BUY_ONLY_PLANTS.rst
new file mode 100644
index 0000000..ec9eb9f
--- /dev/null
+++ b/doc/sphinx/props/P_BUY_ONLY_PLANTS.rst
@@ -0,0 +1,31 @@
+P_BUY_ONLY_PLANTS
+=================
+
+NAME
+----
+::
+
+    P_BUY_ONLY_PLANTS              "lib_p_buy_only_plants"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property kann auf 1 gesetzt werden, wenn ein Laden nur Kraeuter
+    ankaufen darf. Hierzu muss /std/room/kraeuterladen.c geerbt werden,
+    da nur dieses Objekt die Property beruecksichtigt.
+
+SIEHE AUCH
+----------
+::
+
+    /std/room/kraeuterladen.c
+
+Last modified: 02.04.2015 Arathorn 
+
diff --git a/doc/sphinx/props/P_CALLED_FROM_IP.rst b/doc/sphinx/props/P_CALLED_FROM_IP.rst
new file mode 100644
index 0000000..bc2d7f9
--- /dev/null
+++ b/doc/sphinx/props/P_CALLED_FROM_IP.rst
@@ -0,0 +1,21 @@
+P_CALLED_FROM_IP
+================
+
+NAME
+----
+::
+
+    P_CALLED_FROM_IP              "called_from_ip"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Letzte IP-Adr, von der aus sich der Spieler eingeloggt hat.
+
diff --git a/doc/sphinx/props/P_CAN_FLAGS.rst b/doc/sphinx/props/P_CAN_FLAGS.rst
new file mode 100644
index 0000000..1a89a92
--- /dev/null
+++ b/doc/sphinx/props/P_CAN_FLAGS.rst
@@ -0,0 +1,22 @@
+P_CAN_FLAGS
+===========
+
+NAME
+----
+::
+
+    P_CAN_FLAGS                   "can_flags"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/can.h
+
+BESCHREIBUNG
+------------
+::
+
+    Flags die bestimmte Befehle freischalten:
+    CAN_EMOTE, CAN_ECHO, CAN_REMOTE, CAN_PRESAY
+
diff --git a/doc/sphinx/props/P_CAP_NAME.rst b/doc/sphinx/props/P_CAP_NAME.rst
new file mode 100644
index 0000000..88277b6
--- /dev/null
+++ b/doc/sphinx/props/P_CAP_NAME.rst
@@ -0,0 +1,22 @@
+P_CAP_NAME
+==========
+
+NAME
+----
+::
+
+    P_CAP_NAME                    "cap_name"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Name des Spielers, der dekliniert und ausgegen wird.
+     NOT YET IMPLEMENTED.
+
diff --git a/doc/sphinx/props/P_CARRIED_VALUE.rst b/doc/sphinx/props/P_CARRIED_VALUE.rst
new file mode 100644
index 0000000..493d6ab
--- /dev/null
+++ b/doc/sphinx/props/P_CARRIED_VALUE.rst
@@ -0,0 +1,21 @@
+P_CARRIED_VALUE
+===============
+
+NAME
+----
+::
+
+    P_CARRIED_VALUE               "carried"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Entschaedigung, die der Spieler beim Einloggen erhaelt.
+
diff --git a/doc/sphinx/props/P_CHATS.rst b/doc/sphinx/props/P_CHATS.rst
new file mode 100644
index 0000000..4eb9f29
--- /dev/null
+++ b/doc/sphinx/props/P_CHATS.rst
@@ -0,0 +1,21 @@
+P_CHATS
+=======
+
+NAME
+----
+::
+
+    P_CHATS                       "chats"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Alist mit Strings, die das Monster zufaellig ausgibt.
+
diff --git a/doc/sphinx/props/P_CHAT_CHANCE.rst b/doc/sphinx/props/P_CHAT_CHANCE.rst
new file mode 100644
index 0000000..237abc5
--- /dev/null
+++ b/doc/sphinx/props/P_CHAT_CHANCE.rst
@@ -0,0 +1,21 @@
+P_CHAT_CHANCE
+=============
+
+NAME
+----
+::
+
+    P_CHAT_CHANCE                 "chat_chance"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wahrscheinlichkeit, mit der die Chats ausgegeben werden.
+
diff --git a/doc/sphinx/props/P_CLASS.rst b/doc/sphinx/props/P_CLASS.rst
new file mode 100644
index 0000000..c66f6d4
--- /dev/null
+++ b/doc/sphinx/props/P_CLASS.rst
@@ -0,0 +1,34 @@
+P_CLASS
+=======
+
+NAME
+----
+::
+
+     P_CLASS						"class"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Die Klassifizierung eines Objektes, soweit sie nicht schon ueber die 
+     Rasse oder die IDs des Objektes erfolgt ist. Zum Setzen dieser Property 
+     sollte man AddClass() benutzen, zur Klassenabfrage steht 
+     is_class_member() zur Verfuegung.
+     Die moeglichen Klassen findet man in /sys/class.h
+
+SIEHE AUCH
+----------
+::
+
+     AddClass(), RemoveClass(), is_class_member()
+
+
+Last modified: Sun May 19 20:30:09 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_CLOCKMSG.rst b/doc/sphinx/props/P_CLOCKMSG.rst
new file mode 100644
index 0000000..dabf444
--- /dev/null
+++ b/doc/sphinx/props/P_CLOCKMSG.rst
@@ -0,0 +1,21 @@
+P_CLOCKMSG
+==========
+
+NAME
+----
+::
+
+    P_CLOCKMSG                    "clockmsg"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Die Meldung wird zur vollen Stunde ausgegeben
+
diff --git a/doc/sphinx/props/P_CLONER.rst b/doc/sphinx/props/P_CLONER.rst
new file mode 100644
index 0000000..c45bcde
--- /dev/null
+++ b/doc/sphinx/props/P_CLONER.rst
@@ -0,0 +1,28 @@
+P_CLONER
+========
+
+NAME
+----
+::
+
+    P_CLONER                      "cloner"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Enthaelt einen String mit dem Namen desjenigen, der das Objekt gecloned 
+     hat.
+
+SIEHE AUCH
+----------
+::
+
+     P_CLONE_TIME
+
diff --git a/doc/sphinx/props/P_CLONE_MSG.rst b/doc/sphinx/props/P_CLONE_MSG.rst
new file mode 100644
index 0000000..991d2dd
--- /dev/null
+++ b/doc/sphinx/props/P_CLONE_MSG.rst
@@ -0,0 +1,21 @@
+P_CLONE_MSG
+===========
+
+NAME
+----
+::
+
+    P_CLONE_MSG                   "clone_msg"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung, die beim Clonen eines Obj ausgegegen wird (nur Magier)
+
diff --git a/doc/sphinx/props/P_CLONE_TIME.rst b/doc/sphinx/props/P_CLONE_TIME.rst
new file mode 100644
index 0000000..a0f613c
--- /dev/null
+++ b/doc/sphinx/props/P_CLONE_TIME.rst
@@ -0,0 +1,30 @@
+P_CLONE_TIME
+============
+
+NAME
+----
+::
+
+    P_CLONE_TIME                   "clone_time"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Enthaelt die Clone-Time eines Objektes.
+     Heutzutage obsolet, bitte stattdessen lieber die Efun object_time()
+     benutzen.
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt: object_time(E)
+     Aehnlich: program_time(E)
+
diff --git a/doc/sphinx/props/P_CLOTHING.rst b/doc/sphinx/props/P_CLOTHING.rst
new file mode 100644
index 0000000..fc3642e
--- /dev/null
+++ b/doc/sphinx/props/P_CLOTHING.rst
@@ -0,0 +1,44 @@
+P_CLOTHING
+==========
+
+P_CLOTHINGS
+-----------
+::
+
+NAME
+----
+::
+
+     P_CLOTHING                     "std:clothing"
+
+DEFINIERT IN
+------------
+::
+
+     <living/clothing.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Array mit der getragenen nicht-schuetzenden Kleidung des Lebewesen.
+
+     
+
+     Falls ihr die Kleidung des Lebewesens, ggf. mit bestimten Kriterien,
+     ermitteln wollt, benutzt hierfuer bitte die Funktion FilterClothing()
+     statt selber ueber dieses Array zu laufen.
+
+     Diese Property kann nur vom Lebewesen selber beschrieben werden.
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt:		QueryArmourByType(L), FilterClothing(), FilterArmours()
+                  Wear(), Unwear(), P_ARMOURS
+
+14.03.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_CMSG.rst b/doc/sphinx/props/P_CMSG.rst
new file mode 100644
index 0000000..90a7819
--- /dev/null
+++ b/doc/sphinx/props/P_CMSG.rst
@@ -0,0 +1,21 @@
+P_CMSG
+======
+
+NAME
+----
+::
+
+    P_CMSG                        "clonemsg"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     *** OBSOLET! *** Siehe P_CLONE_MSG
+
diff --git a/doc/sphinx/props/P_CNT_STATUS.rst b/doc/sphinx/props/P_CNT_STATUS.rst
new file mode 100644
index 0000000..b988681
--- /dev/null
+++ b/doc/sphinx/props/P_CNT_STATUS.rst
@@ -0,0 +1,22 @@
+P_CNT_STATUS
+============
+
+NAME
+----
+::
+
+    P_CNT_STATUS                  "cnt_status"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container.h
+
+BESCHREIBUNG
+------------
+::
+
+     Status des Containers (offen, geschlossen, abgeschlossen)
+     siehe auch /sys/container.h
+
diff --git a/doc/sphinx/props/P_COMBATCMDS.rst b/doc/sphinx/props/P_COMBATCMDS.rst
new file mode 100644
index 0000000..075d8c4
--- /dev/null
+++ b/doc/sphinx/props/P_COMBATCMDS.rst
@@ -0,0 +1,44 @@
+P_COMBATCMDS
+============
+
+NAME
+----
+::
+
+    P_COMBATCMDS                  "combatcmds"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Fuer den Kampf gebrauchbare Befehle spezieller Objekte (damit auch
+     Monster sie automatisch richtig anwenden koennen)
+     Der Inhalt von P_COMBATCMDS ist ein Mapping, der Key ist das Kommando,
+     um den Gegenstand zu benutzen (also z.B. "wirf flammenkugel"), und der
+     Value ein weiteres Mapping mit Zusatzinfos (definiert in /sys/combat.h).
+     Folgende Keys sind definiert:
+     - C_MIN, C_AVG, C_MAX:
+       minimaler, mittlerer und maximaler Schaden, den das
+       Objekt macht. Alle Angaben in LEBENSPUNKTEN, d.h. Defend-Einheiten/10.
+       Bei einem Aufruf wie 'enemy->Defend(200+random(200), ...)' ist dann
+       C_MIN=20, C_AVG=30, C_MAX=40.
+     - C_DTYPES:
+       Array mit dem Schadenstyp oder den Schadenstypen. Beim Eisstab
+       wuerde der Eintrag dann 'C_DTYPES:({DT_COLD})' lauten.
+     - C_HEAL:
+       Sollte das Kampfobjekt ueber die Moeglichkeit verfuegen, den Anwender
+       irgendwie zu heilen, so wird hier die Heilung in LP/MP eingetragen.
+       Das funktioniert auch bei Objekten, die nur heilen, also sonst
+       nichts mit Kampf zu tun haben.
+       Im Lupinental z.B. gibt es Pfirsiche, die beim Essen 5LP heilen. Da
+       kann man dann 'SetProp(P_COMBATCMDS, (["iss pfirsich":([C_HEAL:5])]))'
+       eintragen.
+     Es sind auch mehrere Kommandos moeglich, z.B. bei Objekten, die sowohl
+     heilen als auch Kampfwirkung haben.
+
diff --git a/doc/sphinx/props/P_COMMANDS.rst b/doc/sphinx/props/P_COMMANDS.rst
new file mode 100644
index 0000000..bc0cb85
--- /dev/null
+++ b/doc/sphinx/props/P_COMMANDS.rst
@@ -0,0 +1,76 @@
+P_COMMANDS
+==========
+
+NAME
+----
+::
+
+     P_COMMANDS "commands"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/commands.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt ein Mapping mit den Befehlen, die dem Objekt
+     zugeordnet sind.
+
+     Sie sollte nicht von Hand manipuliert werden, sondern nur ueber die
+     Funktionen AddCmd() und RemoveCmd().
+
+     Das Mapping hat folgenden Aufbau:
+
+     ([ befehl : ({funktion1,...});
+                 ({flag1,...});
+                 ({regel1,...});
+                 ({id1, ...}),
+                 ({closure auf fun1, ...}),
+        ... ])
+
+     Die Eintraege entsprechen den Parametern des AddCmd()-Aufrufs, sind
+     aber in anderer Form. Als Beispiel:
+
+     AddCmd(verb,fun1,1);
+     AddCmd(verb+syn1a|syn1b&syn2a|syn2b|syn2c, fun2,
+            error1_notify|error2_notify^error2_write);
+     -->
+     ([verb:
+        ({fun1,fun2});                                        // funs
+        ({1,({error1_notify, error2_write^error2_say, 1})});  // flags
+        ({0,({({syn1a,syn1b}),({syn2a,syn2b,syn2c})})});      // rules
+        0;                                                    // IDs
+        ({closure auf fun1, closure auf fun2}) ])             // Cache
+
+     Funs:  ({<fun1> ,...
+              'fun' kann sein: Closure
+                               String: Methodenname - wird etwas geprueft
+                               Objekt: wenn keine Methode, this_object() fuer
+                                       intern, previous_object() fuer extern
+                               0 (erloschenes externes Objekt)
+     Rules: ({<Regelsatz fuer fun1>, ({<1. Synonymgruppe>,
+                                       <2. Synonymgruppe, ...}), ...})
+     Flags: ({<Flag fuer fun1>, ({<Fehlermeldung 1. Synonymgruppe>, ... ,
+                                  [, Index fuer write anstatt notify_fail]}),
+             ... })
+     IDs:   0 oder ({<ID fuer fun1>}) oder ({0, <ID fuer fun2>}) ...
+     Cache: ({<closure fuer fun1>, ...
+
+BEMERKUNGEN
+-----------
+::
+
+     Cache-Closures sind bei Export immer genullt
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/commands.c, AddCmd(), RemoveCmd()
+
+16. Dez 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_COMPILER_PATH.rst b/doc/sphinx/props/P_COMPILER_PATH.rst
new file mode 100644
index 0000000..1462e46
--- /dev/null
+++ b/doc/sphinx/props/P_COMPILER_PATH.rst
@@ -0,0 +1,40 @@
+P_COMPILER_PATH
+===============
+
+NAME
+----
+::
+
+    P_COMPILER_PATH               "compiler_path"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/v_compiler.h
+
+BESCHREIBUNG
+------------
+::
+
+    Directory in dem ein Virtual Compiler Objekte erzeugt.
+    Muss im virtual_compiler.c gesetzt werden.
+
+    Der VirtualCompiler muss nicht zwingend in diesem Verzeichnis
+    liegen, um zu funktionieren, sollte es aber, um die Zuordnung des VCs zu
+    "seinen" Objekten zu erleichern.
+
+BEISPIEL
+--------
+::
+
+    SetProp(P_COMPILER_PATH,"/d/region/magier/vc/");
+
+SIEHE AUCH
+----------
+::
+
+    P_STD_OBJECT, virtual_compiler
+
+Letzte Aenderung: 23.10.2007, von Zesstra
+
diff --git a/doc/sphinx/props/P_CONSUME_MSG.rst b/doc/sphinx/props/P_CONSUME_MSG.rst
new file mode 100644
index 0000000..a176e52
--- /dev/null
+++ b/doc/sphinx/props/P_CONSUME_MSG.rst
@@ -0,0 +1,50 @@
+P_CONSUME_MSG
+=============
+
+NAME
+----
+::
+
+     P_CONSUME_MSG                 "std_food_consume_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Raum exklusive Konsument, wenn eine Speise konsumiert
+     wird.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "@WER2 konsumiert @WEN1."
+
+SIEHE AUCH
+----------
+::
+
+     /std/food.c, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_CONTAINER.rst b/doc/sphinx/props/P_CONTAINER.rst
new file mode 100644
index 0000000..fa1d49d
--- /dev/null
+++ b/doc/sphinx/props/P_CONTAINER.rst
@@ -0,0 +1,21 @@
+P_CONTAINER
+===========
+
+NAME
+----
+::
+
+    P_CONTAINER                   "container"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_CONTENTS.rst b/doc/sphinx/props/P_CONTENTS.rst
new file mode 100644
index 0000000..7c579dc
--- /dev/null
+++ b/doc/sphinx/props/P_CONTENTS.rst
@@ -0,0 +1,21 @@
+P_CONTENTS
+==========
+
+NAME
+----
+::
+
+    P_CONTENTS                    "contents"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container.h
+
+BESCHREIBUNG
+------------
+::
+
+     *** OBSOLET! ***
+
diff --git a/doc/sphinx/props/P_CORPSE.rst b/doc/sphinx/props/P_CORPSE.rst
new file mode 100644
index 0000000..7cbbb89
--- /dev/null
+++ b/doc/sphinx/props/P_CORPSE.rst
@@ -0,0 +1,44 @@
+P_CORPSE
+========
+
+NAME
+----
+::
+
+    P_CORPSE		"corpse"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Hier kann man angeben, welche Art von Leiche beim Tod des NPCs
+    hinterlassen wird. Damit die Leiche auf dem Moerder-Kanal senden
+    kann, muss das Leichen-Objekt /std/corpse sein oder erben.
+
+BEISPIELE
+---------
+::
+
+    Die uebliche Standardleiche befindet sich unter "/std/corpse.c",
+    welches auch die Defaulteinstellung fuer diese Property darstellt:
+      SetProp(P_CORPSE,"/std/corpse");
+    Man koennte aber auch einen Zombie entstehen lassen:
+      SetProp(P_CORPSE,PATH("zombie"));
+    PATH kennzeichnet hierbei den Pfad, unter welchem "zombie.c" zu
+    finden ist.
+
+SIEHE AUCH
+----------
+::
+
+    P_NOCORPSE, P_ZAP_MSG, P_DIE_MSG, P_MURDER_MSG, P_KILL_MSG
+
+
+Last modified: Mon Apr 07 11:02:06 2003 by Mandragon
+
diff --git a/doc/sphinx/props/P_CURRENTDIR.rst b/doc/sphinx/props/P_CURRENTDIR.rst
new file mode 100644
index 0000000..3cf7421
--- /dev/null
+++ b/doc/sphinx/props/P_CURRENTDIR.rst
@@ -0,0 +1,28 @@
+P_CURRENTDIR
+============
+
+NAME
+----
+::
+
+    P_CURRENTDIR                  "currentdir"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/shells.h
+
+BESCHREIBUNG
+------------
+::
+
+    Momentanes Verzeichnis in dem der Magier ist.
+    (nur fuer Magier von Belang)
+
+Siehe auch:
+    P_CURRENTDIR
+
+Letzte Aenderung:
+    03.06.2015, Bugfix
+
diff --git a/doc/sphinx/props/P_CURSED.rst b/doc/sphinx/props/P_CURSED.rst
new file mode 100644
index 0000000..fb293f7
--- /dev/null
+++ b/doc/sphinx/props/P_CURSED.rst
@@ -0,0 +1,56 @@
+P_CURSED
+========
+
+NAME
+----
+::
+
+     P_CURSED "cursed"
+
+DEFINIERT IN
+------------
+::
+
+     <properties.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Ruestungen und Waffen, die sich, einmal angezogen bzw. gezueckt, nicht
+     wieder entfernen lassen sollen, kann man ueber diese Property
+     realisieren. Die Waffe oder Ruestung hat dann in der Regel negative
+     Auswirkungen auf den Traeger...
+
+     Setzt man diese Property auf eine Zahl ungleich 0, so bekommt man bei
+     dem Versuch, den verfluchten Gegenstand auszuziehen bzw. wegzustecken
+     eine Defaultmeldung.
+
+     Traegt man dagegen einen String ein, so wird dieser beim Versuch, den
+     Gegenstand loszuwerden, ausgegeben.
+
+BEMERKUNGEN
+-----------
+::
+
+     Der 'Fluch' wird erst wirksam, wenn das Opfer die Waffe zueckt bzw. die
+     Ruestung anzieht. Ist dies erst einmal geschehen, helfen nur noch
+     Zaubersprueche oder fluchbrechende Institutionen.
+
+     Moechte man, dass der Gegenstand entfluchbar ist, dann sollte er auch
+     ansprechbar sein (gueltige ID, nicht unsichtbar), da das durch derzeitige
+     Entfluchmoeglichkeiten vorausgesetzt wird.
+
+     Flueche koennen ein P_LEVEL 1-100 haben, welches die Schwierigkeit des
+     Enfluchens festlegt. Der Klerus behandelt das nicht linear.
+
+SIEHE AUCH
+----------
+::
+
+     Eigenschaften: P_LEVEL
+     Aehnlich:      AddClass (CL_CURSE)
+     Code:         /std/armour, /std/weapon, /gilden/files.klerus/prayermaster
+
+25. Aug 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_DAMAGED.rst b/doc/sphinx/props/P_DAMAGED.rst
new file mode 100644
index 0000000..b965dd6
--- /dev/null
+++ b/doc/sphinx/props/P_DAMAGED.rst
@@ -0,0 +1,42 @@
+P_DAMAGED
+=========
+
+NAME
+----
+::
+
+     P_DAMAGED "item_damaged"
+
+DEFINIERT IN
+------------
+::
+
+     <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Ruestungen und Waffen koennen im Eifer des Gefechts beschaedigt werden.
+     Der Grad der Beschaedigung sollte in dieser Property festgehalten
+     werden.
+
+     Bei Waffen ergibt sich die urspruengliche Waffenklasse aus der Summe
+     von aktueller Waffenklasse und dem Wert von P_DAMAGED:
+     altes P_WC = aktuelles P_WC + P_DAMAGED.
+
+     Analoges gilt fuer die Ruestungsklasse einer beschaedigten Ruestung:
+     altes P_AC = aktuelles P_AC + P_DAMAGED.
+
+     P_DAMAGED bitte niemals direkt setzen, sondern immer ueber
+     die Funktion Damage() manipulieren!
+
+SIEHE AUCH
+----------
+::
+
+     /std/armour.c, /std/weapon.c, TakeFlaw(), QueryFlaw(), Damage()
+
+
+02.10.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_DAMAGE_MSG.rst b/doc/sphinx/props/P_DAMAGE_MSG.rst
new file mode 100644
index 0000000..0a1834a
--- /dev/null
+++ b/doc/sphinx/props/P_DAMAGE_MSG.rst
@@ -0,0 +1,58 @@
+P_DAMAGE_MSG
+============
+
+NAME
+----
+::
+
+     P_DAMAGE_MSG      "std_p_dam_msg"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property lassen sich individuelle Treffer-/Schadensmeldungen
+     fuer dieses Lebewesen festlegen. Sie werden verwendet, falls bei
+     eingehendem Schaden der Aufrufer von Defend() Schadensmeldungen wuenscht
+     (d.h. SP_SHOW_DAMAGE != 0), jedoch keine eigenen Meldungen vorgibt.
+
+     Enthaelt diese Property kein Array, werden ggf. die Standardmeldungen
+     ausgegeben.
+
+     Datenstruktur der Property:
+       ({
+        ({ int lphit1, string mess_me,
+                       string mess_en,
+                       string mess_room }),
+        ({ lphit2, mess_me, mess_en, mess_room }),
+        ...
+        ({ lphitn, mess_me, mess_en, mess_room }),
+       })
+       wobei lphit1<lphit2<...<lphitn sein muss, d.h. das Array-
+       Array ist aufsteigend sortiert.
+
+     Ist ein Treffer x LP hart, werden die Meldungen des lphit-
+     Arrays ausgegeben, dessen Wert am naechsten unter dem Schaden
+     liegt.
+
+     In den Meldungen mess_me (an den Getroffenen), mess_en (an
+     den Feind), mess_room (an die restlichen Umstehenden) koennen
+     Ersatzstrings wie folgt verwendet werden:
+     @WER1/@WESSEN1/@WEM1/@WEN1 - name(casus) des Getroffenen (TO)
+     @WER2/@WESSEN2/@WEM2/@WEN2 - name(casus) des Feindes (enemy)
+
+SIEHE AUCH
+----------
+::
+
+     Defend()
+     /std/living/combat.c
+
+15.09.2010, Zesstra
+
diff --git a/doc/sphinx/props/P_DAM_DESC.rst b/doc/sphinx/props/P_DAM_DESC.rst
new file mode 100644
index 0000000..093e2f5
--- /dev/null
+++ b/doc/sphinx/props/P_DAM_DESC.rst
@@ -0,0 +1,57 @@
+P_DAM_DESC
+==========
+
+NAME
+----
+::
+
+     P_DAM_DESC "dam_desc"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property befindet sich ein String oder String-Array, durch 
+     den die Langbeschreibung einer Ruestung oder Waffe ergaenzt wird,
+     wenn diese Beschaedigt ist.
+
+BEMERKUNGEN
+-----------
+::
+
+     Wird ein String gesetzt, so wird dieser angezeigt, wenn die Waffe
+     mehr als die Haelfte beschaedigt ist. Bei einem Array wird der
+     Text entsprechend dem Grad der Beschaedigung ausgewaehlt; das Array
+     muss in der Reihenfolge zunehmender Beschaedigung sortiert sein.
+
+     
+
+     Bei Waffen ist P_DAM_DESC defaultmaessig auf DFLT_DAM_DESC gesetzt,
+     bei Ruestungen auf 0.
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_DAM_DESC,"ist beschaedigt");
+     SetProp(P_DAM_DESC,({
+         "ist etwas beschaedigt",
+         "ist beschaedigt",
+         "ist beschaedigt",
+         "ist sehr beschaedigt"}) );
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon/description.c
+
+
+Last modified: Mon Oct 14 15:29:00 1996 by Paracelsus
+
diff --git a/doc/sphinx/props/P_DAM_TYPE.rst b/doc/sphinx/props/P_DAM_TYPE.rst
new file mode 100644
index 0000000..3c634f3
--- /dev/null
+++ b/doc/sphinx/props/P_DAM_TYPE.rst
@@ -0,0 +1,36 @@
+P_DAM_TYPE
+==========
+
+NAME
+----
+::
+
+     P_DAM_TYPE "dam_type"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Was fuer eine Art von Schaden richtet die Waffe an? Hier kann man einen
+     String oder ein Array von Strings angeben, je nachdem, welche Effekte
+     die Waffe ausloesen kann. Man sollte hier nur die in <combat.h>
+     definierten Schadenstypen verwenden.
+
+     Fragt man diese Property ab, bekommt man uebrigens immer ein Array von
+     Strings zurueck.
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon.c
+
+
+Last modified: Sun May 19 15:23:43 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_DEADS.rst b/doc/sphinx/props/P_DEADS.rst
new file mode 100644
index 0000000..44075ae
--- /dev/null
+++ b/doc/sphinx/props/P_DEADS.rst
@@ -0,0 +1,22 @@
+P_DEADS
+=======
+
+NAME
+----
+::
+
+    P_DEADS                       "deads"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der Tode des Spielers seit Einfuehrung dieser Property (irgendwann
+     im Dezember 94)
+
diff --git a/doc/sphinx/props/P_DEAF.rst b/doc/sphinx/props/P_DEAF.rst
new file mode 100644
index 0000000..59128c5
--- /dev/null
+++ b/doc/sphinx/props/P_DEAF.rst
@@ -0,0 +1,23 @@
+P_DEAF
+======
+
+NAME
+----
+::
+
+    P_DEAF                        "deaf"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+     Der Spieler ist taub. Falls hier ein String steht, wird dieser bei
+     "teile ... mit" an den Mitteilenden ausgegeben, ansonsten kommt nur
+     "Soundso ist leider gerade taub.\n"
+
diff --git a/doc/sphinx/props/P_DEATH_MSG.rst b/doc/sphinx/props/P_DEATH_MSG.rst
new file mode 100644
index 0000000..82632e9
--- /dev/null
+++ b/doc/sphinx/props/P_DEATH_MSG.rst
@@ -0,0 +1,79 @@
+P_DEATH_MSG
+===========
+
+DEFINIERT IN
+------------
+::
+
+        /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+        In dieser Property kann man ein Array ablegen, das beim Tod eines
+        Spielers ausgewertet und der darin enthaltene String
+        anschliessend auf dem Todeskanal gesendet wird.
+        Der Array muss folgenden Aufbau haben:
+
+          SetProp( P_DEATH_MSG, ({ Text, Flag }) )
+
+          
+
+        Text: Der Text kann beliebig eingegeben werde. Allerdings darf 
+              er nicht mit einem '\n' abgeschlossen werden.
+
+        
+
+        Flag: Hier kann man drei Arten von Sendemethoden waehlen.
+              1. MSG_SAY      Normales Senden
+              2. MSG_GEMOTE   Genitiv-Emote
+              3. MSG_EMOTE    Emote
+
+BEISPIEL
+--------
+::
+
+        Der Spieler soll direkt nach seinem Tod eine Meldung auf dem 
+        Todeskanal senden.
+
+        
+
+        Nachricht auf dem Todes-Kanal:
+
+	
+
+        [Tod:Spieler] Ich will keine Beleidsbekundungen!
+
+        
+
+        void spieler_stirbt()
+	{
+         this_player()->SetProp( P_DEATH_MSG, ({ "Ich will keine "
+                                        "Beleidsbekundungen!", MSG_SAY}) );
+         this_player()->die();
+        }
+
+        
+
+        Nachricht auf dem Todes-Kanal:
+
+	
+
+        [Tod:Spieler liebt es zu sterben.]
+
+        
+
+        void spieler_stirbt()
+        {
+         this_player()->SetProp( P_DEATH_MSG, ({ "liebt es zu sterben.",
+                                                 MSG_EMOTE }) );
+         this_player()->die();
+        }
+
+SIEHE AUCH
+----------
+::
+
+        P_MURDER_MSG, P_FORCE_MURDER_MSG
+
diff --git a/doc/sphinx/props/P_DEATH_SPONSORED_BY.rst b/doc/sphinx/props/P_DEATH_SPONSORED_BY.rst
new file mode 100644
index 0000000..33e40b3
--- /dev/null
+++ b/doc/sphinx/props/P_DEATH_SPONSORED_BY.rst
@@ -0,0 +1,44 @@
+P_DEATH_SPONSORED_BY
+====================
+
+NAME
+----
+::
+
+    P_DEATH_SPONSORED_BY          "responsible_wizard_for_death"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property hat fuer den Spielverlauf keinerlei Bedeutung.
+    Doch gibt es Magier, die ihren Namen gern in /log/KILLS lesen.
+    Wird ein Spieler durch einen Npc getoetet, ist normalerweise der
+    Magier fuer den Tod verantwortlich, in dessen Verzeichnis sich 
+    das Monster befindet. 
+    Doch gibt es nun auch den Fall, dass sich das Monster in einem 
+    Verzeichnis /alle/mon/ befindet, oder der Spieler durch eine
+    Aktion im Raum oder an einem Objekt stirbt.
+
+    Ist in einem solchen Monster, Raum oder Objekt diese Property
+    gesetzt, wird der dort angebene String an das Log-File ueber-
+    geben.
+
+BEISPIEL
+--------
+::
+
+    SetProp(P_DEATH_SPONSORED_BY,"tilly");
+
+ 
+
+Last modified Don Feb 15 140100 2001 von Tilly
+----------------------------------------------
+::
+
diff --git a/doc/sphinx/props/P_DEFAULT_GUILD.rst b/doc/sphinx/props/P_DEFAULT_GUILD.rst
new file mode 100644
index 0000000..d0ad46a
--- /dev/null
+++ b/doc/sphinx/props/P_DEFAULT_GUILD.rst
@@ -0,0 +1,44 @@
+P_DEFAULT_GUILD
+===============
+
+NAME
+----
+::
+
+	P_DEFAULT_GUILD			"default_guild"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt den Namen der Gilde, welcher der Spieler
+	standardmaessig angehoert. Der Name wird hierbei in Form eines
+	kleingeschriebenen Strings angegeben. Ist P_GUILD gleich Null, so
+	wird bei der Abfrage selbiger Property hierfuer der Eintrag von
+	P_DEFAULT_GUILD eingesetzt.
+
+BEMERKUNGEN
+-----------
+::
+
+	Nach dem ersten Einloggen des Spielers wird ebenfalls dieser Eintrag
+	genutzt, um die Gildenzugehoerigkeit festzulegen. Dies kann dazu
+	genutzt werden, um eine rassenabhaengige Bestimmung der
+	Standardgilde zu gewaehrleisten
+	 (Felinen -> Katzenkrieger, andere Rassen -> Abenteurer).
+
+SIEHE AUCH
+----------
+::
+
+	P_GUILD, P_VISIBLE_GUILD
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_DEFAULT_NOTIFY_FAIL.rst b/doc/sphinx/props/P_DEFAULT_NOTIFY_FAIL.rst
new file mode 100644
index 0000000..d00f304
--- /dev/null
+++ b/doc/sphinx/props/P_DEFAULT_NOTIFY_FAIL.rst
@@ -0,0 +1,21 @@
+P_DEFAULT_NOTIFY_FAIL
+=====================
+
+NAME
+----
+::
+
+    P_DEFAULT_NOTIFY_FAIL         "default_notify_fail"         
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Welche Fehlermeldung kommt, wenn kein Objekt ein notify_fail macht?
+
diff --git a/doc/sphinx/props/P_DEFENDERS.rst b/doc/sphinx/props/P_DEFENDERS.rst
new file mode 100644
index 0000000..bc83fe5
--- /dev/null
+++ b/doc/sphinx/props/P_DEFENDERS.rst
@@ -0,0 +1,46 @@
+P_DEFENDERS
+===========
+
+NAME
+----
+::
+
+	P_DEFENDERS			"defenders"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property wird in Lebewesen gesetzt, welche zum Beispiel durch
+	andere Lebewesen verteidigt werden. Die Verteidiger muessen
+	natuerlich bekannt sein, damit sie per InformDefend() ueber Angriffe
+	informiert werden und per DefendOther() in den laufenden Angriff
+	eingreifen koennen (zum Beispiel Schaeden abwehren oder umwandeln).
+	Es muessen jedoch nicht unbedingt Lebewesen oder echte Verteidiger
+	sein, auch beliebige Objekte koennen ueber Angriffe informiert
+	werden und in diese eingreifen. Allerdings besteht die
+	Einschraenkung, dass diese Objekte in der gleichen Umgebung sein
+	muessen, wie das zu verteidigende Lebewesen oder im zu verteidigenden
+	Lebewesen selbst.
+	Die Objekte, welche dies betrifft, sind in Form eines Arrays in
+	der Property P_DEFENDERS abgelegt.
+	Gesetzt und geloescht werden sollten die Eintraege dieses Arrays
+	jedoch nur mittels der dafuer bereitgestellten Funktionen
+	AddDefender() und RemoveDefender().
+
+SIEHE AUCH
+----------
+::
+
+	AddDefender(), RemoveDefender(), InformDefend(), DefendOther(),
+	/std/living/combat.c
+
+
+Last modified: 21.09.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_DEFEND_FUNC.rst b/doc/sphinx/props/P_DEFEND_FUNC.rst
new file mode 100644
index 0000000..9e370c9
--- /dev/null
+++ b/doc/sphinx/props/P_DEFEND_FUNC.rst
@@ -0,0 +1,51 @@
+P_DEFEND_FUNC
+=============
+
+NAME
+----
+::
+
+     P_DEFEND_FUNC "defend_func"
+
+DEFINIERT IN
+------------
+::
+
+     <armour.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Falls ein Objekt eine DefendFunc() fuer die Ruestung definiert, so muss
+     dieses Objekt in dieser Property eingetragen sein.
+
+     Die Auswertung dieser Property erfolgt in QueryDefend().
+
+BEMERKUNGEN
+-----------
+::
+
+     1. Es funktioniert _nicht_ hier eine Closure reinzuschreiben.
+     2. Diese Prop laesst sich _nicht_ sinnvoll mit Set() setzen, also z.B.
+        keine Query-Methoden hier reinzuschreiben.
+     3. Definieren von _set_defend_func() oder Set-Methoden via Set()
+        funktioniert auch nicht, zumindest nicht mit dem gewuenschten
+        Ergebnis. ;-)
+     4. Bei Verwendung bitte Balance-Richtlinien beachten!
+
+BEISPIELE
+---------
+::
+
+     Siehe das Beispiel zu DefendFunc()
+
+SIEHE AUCH
+----------
+::
+
+     /std/armour.c, DefendFunc(), balance, grenzwerte
+
+
+Last modified: Sat May 18 15:26:17 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_DEFUEL_AMOUNT_DRINK.rst b/doc/sphinx/props/P_DEFUEL_AMOUNT_DRINK.rst
new file mode 100644
index 0000000..7e6db27
--- /dev/null
+++ b/doc/sphinx/props/P_DEFUEL_AMOUNT_DRINK.rst
@@ -0,0 +1,38 @@
+P_DEFUEL_AMOUNT_DRINK
+=====================
+
+NAME
+----
+::
+
+    P_DEFUEL_AMOUNT_DRINK                          "defuel_amount_drink"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/defuel.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die rassenabhaengige Enttankvorgabe fuer Trinken.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+                P_DEFUEL_LIMIT_FOOD, P_DEFUEL_LIMIT_DRINK,
+                P_DEFUEL_AMOUNT_FOOD
+     Methoden:  defuel_drink, defuel_food
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Weitere:   P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_DEFUEL_AMOUNT_FOOD.rst b/doc/sphinx/props/P_DEFUEL_AMOUNT_FOOD.rst
new file mode 100644
index 0000000..27ca45e
--- /dev/null
+++ b/doc/sphinx/props/P_DEFUEL_AMOUNT_FOOD.rst
@@ -0,0 +1,38 @@
+P_DEFUEL_AMOUNT_FOOD
+====================
+
+NAME
+----
+::
+
+    P_DEFUEL_AMOUNT_FOOD                          "defuel_amount_food"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/defuel.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die rassenabhaengige Enttankvorgabe fuer Essen.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+                P_DEFUEL_LIMIT_FOOD, P_DEFUEL_LIMIT_DRINK,
+                P_DEFUEL_AMOUNT_DRINK
+     Methoden:  defuel_drink, defuel_food
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Weitere:   P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_DEFUEL_LIMIT_DRINK.rst b/doc/sphinx/props/P_DEFUEL_LIMIT_DRINK.rst
new file mode 100644
index 0000000..e623554
--- /dev/null
+++ b/doc/sphinx/props/P_DEFUEL_LIMIT_DRINK.rst
@@ -0,0 +1,39 @@
+P_DEFUEL_LIMIT_DRINK
+====================
+
+NAME
+----
+::
+
+    P_DEFUEL_LIMIT_DRINK                          "defuel_limit_drink"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/defuel.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die rassenabhaengige minimale Menge an Trinken, ab dem ein
+    Enttankvorgang fuer den Spieler moeglich ist.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+                P_DEFUEL_LIMIT_FOOD,
+                P_DEFUEL_AMOUNT_FOOD, P_DEFUEL_AMOUNT_DRINK
+     Methoden:  defuel_drink, defuel_food
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Weitere:   P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_DEFUEL_LIMIT_FOOD.rst b/doc/sphinx/props/P_DEFUEL_LIMIT_FOOD.rst
new file mode 100644
index 0000000..ebe9dcd
--- /dev/null
+++ b/doc/sphinx/props/P_DEFUEL_LIMIT_FOOD.rst
@@ -0,0 +1,39 @@
+P_DEFUEL_LIMIT_FOOD
+===================
+
+NAME
+----
+::
+
+    P_DEFUEL_LIMIT_FOOD                          "defuel_limit_food"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/defuel.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die rassenabhaengige minimale Menge an Essen, ab dem ein
+    Enttankvorgang fuer den Spieler moeglich ist.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+                P_DEFUEL_LIMIT_DRINK,
+                P_DEFUEL_AMOUNT_FOOD, P_DEFUEL_AMOUNT_DRINK
+     Methoden:  defuel_drink, defuel_food
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Weitere:   P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_DEFUEL_TIME_DRINK.rst b/doc/sphinx/props/P_DEFUEL_TIME_DRINK.rst
new file mode 100644
index 0000000..236486a
--- /dev/null
+++ b/doc/sphinx/props/P_DEFUEL_TIME_DRINK.rst
@@ -0,0 +1,39 @@
+P_DEFUEL_TIME_DRINK
+===================
+
+NAME
+----
+::
+
+    P_DEFUEL_TIME_DRINK                          "defuel_time_drink"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/defuel.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die rassenabhaengige minimale Zeit zwischen einzelnen
+    Enttankvorgaengen fuer Trinken eines Spielers.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  P_DEFUEL_TIME_FOOD,
+                P_DEFUEL_LIMIT_FOOD, P_DEFUEL_LIMIT_DRINK,
+                P_DEFUEL_AMOUNT_FOOD, P_DEFUEL_AMOUNT_DRINK
+     Methoden:  defuel_drink, defuel_food
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Weitere:   P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_DEFUEL_TIME_FOOD.rst b/doc/sphinx/props/P_DEFUEL_TIME_FOOD.rst
new file mode 100644
index 0000000..b77673f
--- /dev/null
+++ b/doc/sphinx/props/P_DEFUEL_TIME_FOOD.rst
@@ -0,0 +1,39 @@
+P_DEFUEL_TIME_FOOD
+==================
+
+NAME
+----
+::
+
+    P_DEFUEL_TIME_FOOD                          "defuel_time_food"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/defuel.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die rassenabhaengige minimale Zeit zwischen einzelnen
+    Enttankvorgaengen fuer Essen eines Spielers.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:  P_DEFUEL_TIME_DRINK,
+                P_DEFUEL_LIMIT_FOOD, P_DEFUEL_LIMIT_DRINK,
+                P_DEFUEL_AMOUNT_FOOD, P_DEFUEL_AMOUNT_DRINK
+     Methoden:  defuel_drink, defuel_food
+     Tanken:    consume, drink_alcohol, drink_soft, eat_food
+     Weitere:   P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+                P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
+     Konzepte:  heilung, enttanken, food
+
+9. August 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_DEPARTMSG.rst b/doc/sphinx/props/P_DEPARTMSG.rst
new file mode 100644
index 0000000..0913c76
--- /dev/null
+++ b/doc/sphinx/props/P_DEPARTMSG.rst
@@ -0,0 +1,21 @@
+P_DEPARTMSG
+===========
+
+NAME
+----
+::
+
+    P_DEPARTMSG                   "departmsg"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung, mit der ein Transporter ablegt.
+
diff --git a/doc/sphinx/props/P_DESCRIPTION.rst b/doc/sphinx/props/P_DESCRIPTION.rst
new file mode 100644
index 0000000..4066b81
--- /dev/null
+++ b/doc/sphinx/props/P_DESCRIPTION.rst
@@ -0,0 +1,21 @@
+P_DESCRIPTION
+=============
+
+NAME
+----
+::
+
+    P_DESCRIPTION                 "description"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Beschreibung des Spielers
+
diff --git a/doc/sphinx/props/P_DESTROY_BAD.rst b/doc/sphinx/props/P_DESTROY_BAD.rst
new file mode 100644
index 0000000..bc26127
--- /dev/null
+++ b/doc/sphinx/props/P_DESTROY_BAD.rst
@@ -0,0 +1,57 @@
+P_DESTROY_BAD
+=============
+
+NAME
+----
+::
+
+     P_DESTROY_BAD                 "std_food_destroy_bad"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Speichert den Wert fuer das Verhalten, wenn eine Speise verdirbt.
+     Dieses Verhalten wird in make_bad() umgesetzt.
+
+     
+
+     DESTROY_BAD   : Die Speise wird beim Verderben zerstoert
+                     bzw. der Behaelter wird geleert
+     DESTROY_NEVER : Die Speise wird beim Verderben nicht zerstoert
+     pos. Integer  : Anzahl der Sekunden, die zwischen Verderben
+                     und Zerstoeren der Speise liegen sollen
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Ist ein positiver Integer-Wert in dieser Property gespeichert, wird nach
+     Ausfuehren der Methode make_bad() nach Ablauf der angegebenen Sekunden
+     ein weiterer Reset ausgeloest, der make_destroy() aufruft.
+
+     
+
+DEFAULT
+-------
+::
+
+     Initial ist diese Property auf DESTROY_BAD gesetzt.
+
+SIEHE AUCH
+----------
+::
+
+     /std/food.c, wiz/food
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_DESTRUCT_MSG.rst b/doc/sphinx/props/P_DESTRUCT_MSG.rst
new file mode 100644
index 0000000..82257b3
--- /dev/null
+++ b/doc/sphinx/props/P_DESTRUCT_MSG.rst
@@ -0,0 +1,21 @@
+P_DESTRUCT_MSG
+==============
+
+NAME
+----
+::
+
+    P_DESTRUCT_MSG                "destruct_msg"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung, die beim Destructen Obj ausgegegen wird (nur Magier)
+
diff --git a/doc/sphinx/props/P_DETAILS.rst b/doc/sphinx/props/P_DETAILS.rst
new file mode 100644
index 0000000..50f42c9
--- /dev/null
+++ b/doc/sphinx/props/P_DETAILS.rst
@@ -0,0 +1,44 @@
+P_DETAILS
+=========
+
+NAME
+----
+::
+
+    P_DETAILS            "details"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property enthaelt ein Mapping, in der Details im Objekt
+    definiert werden und Beschreibungen, die ausgegeben werden, wenn man
+    sich diese Details anschaut.
+
+BEMERKUNGEN
+-----------
+::
+
+    Man kann diese Property nicht per SetProp() veraendern, sondern muss die
+    entsprechenden Funktionen nutzen.
+    AddSpecialDetail() und RemoveSpecialDetail() sollten nicht mehr
+    verwendet werden.
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddDetail()
+    Loeschen:  RemoveDetail()
+    Aehnlich:  P_SPECIAL_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail()
+    Sonstiges: GetDetail(), break_string()
+
+27. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_DIE_MSG.rst b/doc/sphinx/props/P_DIE_MSG.rst
new file mode 100644
index 0000000..6825d1d
--- /dev/null
+++ b/doc/sphinx/props/P_DIE_MSG.rst
@@ -0,0 +1,57 @@
+P_DIE_MSG
+=========
+
+NAME
+----
+::
+
+     P_DIE_MSG			"die_msg"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property uebergibt man einen String, der ausgegeben wird, wenn
+     das Lebewesen stirbt. Ist die Property nicht gesetzt, so wird als String
+     benutzt:
+	" faellt tot zu Boden.\n".
+
+     Der Name des Lebewesens wird dem String vor der Ausgabe vorangestellt.
+     Der Satzumbruch am Zeilenende und das Leerzeichen nach dem Namen des
+     Lebewesens muss man selbst angegeben. Es sollte allerdings beachtet
+     werden, dass ein Lebewesen, das durch Gift getoetet wird, eine spezielle
+     nicht zu beeinflussende Meldung erhaelt. Es wird dann als String
+     benutzt:
+	" wird von Gift hinweggerafft und kippt um.\n".
+
+BEISPIELE
+---------
+::
+
+     Bei einem mitkaempfenden Schatten waere es eher unlogisch, wenn nach
+     dessen 'Tod' eine Leiche zurueckbliebe. Eine logische Konsequenz waere
+     folgende Meldung:
+	SetProp(P_DIE_MSG," loest sich auf.\n");
+	SetProp(P_NOCORPSE,1);
+
+     Damit dann auch wirklich keine Leiche zurueckbleibt, wird zusaetzlich
+     die Property P_NOCORPSE gesetzt.
+
+SIEHE AUCH
+----------
+::
+
+     Tod:		die(L)
+     Todesmeldungen:	P_KILL_NAME, P_KILL_MSG, P_MURDER_MSG
+			P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
+     Sonstiges:		P_CORPSE, P_NOCORPSE, /std/corpse.c
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_DISABLE_ATTACK.rst b/doc/sphinx/props/P_DISABLE_ATTACK.rst
new file mode 100644
index 0000000..033963e
--- /dev/null
+++ b/doc/sphinx/props/P_DISABLE_ATTACK.rst
@@ -0,0 +1,64 @@
+P_DISABLE_ATTACK
+================
+
+NAME
+----
+::
+
+    P_DISABLE_ATTACK              "disable_attack"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Das Lebewesen kann nicht angreifen. Beim Setzen der Property ist es
+    wichtig, SetProp() zu benutzen und die Anzahl der Kampfrunden anzugeben,
+    die das Lebewesen paralysiert sein soll.
+
+    Ein negativer Wert ist nicht gueltig. Bei mehr als 30 Kampfrunden wird
+    die Paralyse auf 30 Kampfrunden gekappt.
+
+    Fuer jede Paralyse bekommt ein Living eine ebenso lange Schutzzeit nach
+    der Paralyse gewaehrt. Versucht man, vor Ablauf der Paralyse
+    P_DISABLE_ATTACK hoeher zu setzen (oder setzt man innerhalb der folgenden
+    Schutzzeit P_DISABLE_ATTACK auf > 0), wird DISABLE_TOO_EARLY von SetProp
+    zurueck gegeben.
+    Eine Reduktion von einem P_DISABLE_ATTACK ist moeglich, allerdings
+    reduziert dies _nicht_ eine einmal gesetzte Schutzzeit.
+
+    Einen Gegner,der nie paralysiert werden koennen soll, kann man einfach
+    per 
+
+    Set(P_DISABLE_ATTACK, function int () {return 0;}, F_SET_METHOD);
+
+    erstellen, da bei diesem der Wert von P_DISABLE_ATTACK nicht mehr mit
+    einem normalen SetProp()-Aufruf geaendert werden kann.
+
+BEISPIELE
+---------
+::
+
+    // Gegner 17 Runden lang paralysieren, ohne Ruecksicht auf fruehere P.
+    // (in diesem Moment ist das Living bis time() + 4 * 17 vor laengerer
+    //  oder erneuter Paralyse geschuetzt)
+    en->SetProp(P_DISABLE_ATTACK, 17);
+    // Der Gegner kann jetzt fuer 34 Kampfrunden nicht erneut paralysiert
+    // werden.
+    // Paralyse reduzieren auf 10 Kampfrunden
+    en->SetProp(P_DISABLE_ATTACK, 10);
+    // Die Schutzzeit ist immer noch bei 34 Kampfrunden, nicht bei 20.
+
+SIEHE AUCH
+----------
+::
+
+    P_NEXT_DISABLE_ATTACK
+
+19.08.2014, Zesstra
+
diff --git a/doc/sphinx/props/P_DISABLE_COMMANDS.rst b/doc/sphinx/props/P_DISABLE_COMMANDS.rst
new file mode 100644
index 0000000..a219298
--- /dev/null
+++ b/doc/sphinx/props/P_DISABLE_COMMANDS.rst
@@ -0,0 +1,100 @@
+P_DISABLE_COMMANDS
+==================
+
+NAME
+----
+::
+
+     P_DISABLE_COMMANDS             "p_lib_disablecommands"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player/command.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mit dieser Prop kann man verhindern, dass Kommandos eines Spielers
+    verarbeitet werden. Dies ist z.B. in Sequenzen nuetzlich, wo der Spieler
+    rein passiv konsumieren soll.
+    In diese Property muss ein Array mit 2 oder 3 Elementen geschrieben 
+    werden:
+       1) Endzeitpunkt in Sekunden seit 1.1.1970 (int)
+       2) Meldung (String oder Closure)
+       3) (optional) Array von trotzdem erlaubten Verben (string*)
+         (nur ausgewertet, wenn die Meldung ein String ist)
+
+    
+
+    Ist die Meldung ein String, wird dieser einfach bei jedem Kommando so wie
+    er ist an den Spieler ausgegeben und das Kommando abgebrochen.
+    Ist die Meldung eine Closure wird diese bei jedem Kommando aufgerufen und
+    das Kommando abgebrochen, wenn sie einen Rueckgabewert != 0 zurueckgibt.
+    In diesem Fall ist die gerufene Funktion dafuer verantwortlich, geeignete
+    Meldungen an den Spieler auszugeben!
+    Der Funktion wird der vom Spieler eingebene Befehl (string) als erstes
+    Argument uebergeben. Zu diesem Zeitpunkt wurde alle Aliase schon
+    ausgewertet. Die Funktion kann den Kommandogeber via this_player()
+    ermitteln.
+    Fuer weitere Informationen steht auch command_stack() zur Verfuegung,
+    allerdings ist dort die Alias-Ersetzung nicht beruecksichtigt.
+
+    Die Ausnahmeliste wird nur fuer simple Strings als Meldung ausgewertet,
+    wird eine Closure verwendet, kann diese besser selber die Ausnahmen
+    bestimmen.
+
+    
+
+    Fragt man diese Prop ab, erhaelt man ein Array mit 4 Elementen: setzendes
+    Objekt (object), Ablaufzeit (int), Meldung (String oder Closure) und
+    Liste von Ausnahmen (string*).
+
+BEMERKUNGEN
+-----------
+::
+
+    1. Die Prop wird fuer Magier mit eingeschaltetem P_WANTS_TO_LEARN
+       ignoriert.
+    2. Wenn das Objekt zerstoert wird, was die Prop gesetzt hat, wird der
+       Eintrag unwirksam.
+    3. Wenn diese Prop gesetzt und nicht abgelaufen ist, kann nur das gleiche
+       Objekt sie mit neuen Daten ueberschreiben. Alle anderen Objekte koennen
+       die Prop nur loeschen. Dies soll verhindern, dass Magier unabsichtlich
+       einfach anderer Leute Eintraege ueberschreiben. Dementsprechend: Lasst
+       die Finger davon, wenn die schon gesetzt ist. ;-)
+    4. Diese Prop darf _ausschliesslich_ mit SetProp() und QueryProp() benutzt
+       werden, Set() und Query() funktionieren _nicht_.
+    5. Es gibt einige Verben, die NIE blockiert werden. Zur Zeit sind dies
+       "mrufe", "mschau", "bug", "idee", "typo" und "detail".
+    6. Bitte nicht missbrauchen, speziell nicht dazu, die Kommandos von
+       Spieler zu ueberwachen/mitzuschreiben. Das Setzen dieser Prop wird 
+       geloggt.
+
+BEISPIEL
+--------
+::
+
+   In einem Raum startet eine Sequenz, in der der Spieler nichts machen soll:
+
+   if (!pl->QueryProp(P_DISABLE_COMMANDS))
+      pl->SetProp(P_DISABLE_COMMANDS,
+            ({ time() + 120, "Du bist tief in Deinem Traum gefangen!\n" }) );
+   else // ... Fehlerbehandlung, falls Prop schon gesetzt ...
+
+   
+
+   Soll die Prop aus irgendeinem Grund (vorzeitig) geloescht werden:
+   pl->SetProp(P_DISABLE_COMMANDS, 0);
+
+SIEHE AUCH
+----------
+::
+
+     command(), query_command(), command_stack(), modify_command(), 
+     this_player()
+
+01.12.2012, Zesstra
+
diff --git a/doc/sphinx/props/P_DISTRIBUTION.rst b/doc/sphinx/props/P_DISTRIBUTION.rst
new file mode 100644
index 0000000..07b0d99
--- /dev/null
+++ b/doc/sphinx/props/P_DISTRIBUTION.rst
@@ -0,0 +1,34 @@
+P_DISTRIBUTION
+==============
+
+NAME
+----
+::
+
+     P_DISTRIBUTION                "std_food_distribution"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/food.h
+
+BESCHREIBUNG
+------------
+::
+
+     Verteilung der Heilung ueber mehrere Heartbeats.
+     Dieser Wert wird im entry_info als H_DISTRIBUTION dem consume() im
+     Living uebergeben.
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     consume
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_DMSG.rst b/doc/sphinx/props/P_DMSG.rst
new file mode 100644
index 0000000..d276da5
--- /dev/null
+++ b/doc/sphinx/props/P_DMSG.rst
@@ -0,0 +1,21 @@
+P_DMSG
+======
+
+NAME
+----
+::
+
+    P_DMSG                        "destmsg"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     *** OBSOLET! *** Siehe P_DESTRUCT_MSG
+
diff --git a/doc/sphinx/props/P_DOMAIN.rst b/doc/sphinx/props/P_DOMAIN.rst
new file mode 100644
index 0000000..5050d06
--- /dev/null
+++ b/doc/sphinx/props/P_DOMAIN.rst
@@ -0,0 +1,51 @@
+P_DOMAIN
+========
+
+NAME
+----
+::
+
+    P_DOMAIN                                        "lib_p_domain"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt die Region, in der ein Raum liegt, sofern er
+     in /d/ liegt.
+
+     Falls ein Raum nicht in /d/ liegt, aber es eigentlich ein Gebiet ist,
+     welches eindeutig in einer Region zugeordnet ist, kann der Magier
+     hier gezielt einen anderen Wert setzen.
+
+     
+
+     Bitte keine Regionen faelschen!
+
+BEISPIEL
+--------
+::
+
+     In /d/inseln/zesstra/vulkanweg/room/r1 liefert
+     QueryProp(P_DOMAIN)
+     ein "Inseln" zurueck.
+
+     In einem Raum der Chaosgilde:
+     SetProp(P_DOMAIN, "Polar");
+     damit der Raum als Raum der Region Polar angezeigt wird.
+
+SIEHE AUCH
+----------
+::
+
+     gmcp
+
+
+23.02.2013, Zesstra
+
diff --git a/doc/sphinx/props/P_DOOR_INFOS.rst b/doc/sphinx/props/P_DOOR_INFOS.rst
new file mode 100644
index 0000000..20c9e0c
--- /dev/null
+++ b/doc/sphinx/props/P_DOOR_INFOS.rst
@@ -0,0 +1,59 @@
+P_DOOR_INFOS
+============
+
+NAME
+----
+::
+
+    P_DOOR_INFOS                  "door_infos"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/doorroom.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mapping mit Informationen ueber eine im Raum per NewDoor() definierte
+    Tuer. Diese Infos werden ueber /std/room/doors.c an den /obj/doormaster.c
+    weitergegeben und dem Raum, der die Tuer besitzt, als Property gesetzt.
+    Werden mehrere Tueren in einem Raum eingebunden, enthaelt das Mapping
+    entsprechend viele Eintraege.
+
+    Dieses Mapping dient zur internen Verwaltung der Tueren im
+    /obj/doormaster.c und sollte nicht per Hand veraendert werden!
+
+    Die Eintraege im Mapping haben folgende keys (definiert in
+    /sys/doorroom.h):
+
+    D_DEST : Zielraum (string)
+    D_CMDS : Befehl(e), um durch die Tuer zu gehen (string oder *string)
+    D_IDS  : IDs der Tuer (string oder *string)
+    D_FLAGS : Besondere Eigenschaften der Tuer (Tuer braucht Schluessel etc.)
+    D_LONG  : Langbeschreibung (string)
+    D_SHORT : Kurzbeschreibung (string)
+    D_NAME  : Name (string oder *string)
+    D_GENDER  : Geschlecht
+    D_FUNC    : Funktion, die VOR dem Durchschreiten der Tuer aufgerufen wird
+    D_MSGS    : Bewegungsmeldungen
+    D_FUNC2   : Funktion, die NACH dem Durchschreiten der Tuer aufgerufen wird
+    D_TESTFUNC  : Funktion die im Sartraum testet, ob die Tuer durchschritten
+                  werden darf
+    D_RESET_MSG : Meldungen beim Tuer-Reset
+    D_OPEN_WITH_MOVE : Falls gesetzt, wird die Tuer auch mit dem
+                       Bewegungsbefehl geoeffnet und durchschritten, falls
+                       Oeffnen erfolgreich
+
+SIEHE AUCH
+----------
+::
+
+    NewDoor(), QueryDoorKey(), QueryDoorStatus(), SetDoorStatus(),
+    /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+
+
+Letzte Aenderung: Don, 08.05.2014, Gabylon
+
diff --git a/doc/sphinx/props/P_DO_DESTRUCT.rst b/doc/sphinx/props/P_DO_DESTRUCT.rst
new file mode 100644
index 0000000..e6bc84f
--- /dev/null
+++ b/doc/sphinx/props/P_DO_DESTRUCT.rst
@@ -0,0 +1,36 @@
+P_DO_DESTRUCT
+=============
+
+NAME
+----
+::
+
+    P_DO_DESTRUCT                 "do_destruct"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Flag, ob sich die Lichtquelle am Ende der Leuchtzeit selbst
+     zerstoert. 
+
+SIEHE AUCH
+----------
+::
+
+     Basisklassen: /std/lightsource.c
+     Properties: P_FUEL, P_LIGHTDESC, P_LIGHT
+     Methoden: AddFuel(L)
+
+LETZTE AENDERUNG
+----------------
+::
+
+    22. Dez. 2015, Arathorn
+
diff --git a/doc/sphinx/props/P_DRINK.rst b/doc/sphinx/props/P_DRINK.rst
new file mode 100644
index 0000000..28bfb18
--- /dev/null
+++ b/doc/sphinx/props/P_DRINK.rst
@@ -0,0 +1,42 @@
+P_DRINK
+=======
+
+NAME
+----
+::
+
+     P_DRINK                       "drink"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     - Lebewesen
+       Numerischer Wert fuer den Saettigungsgrad eines Lebewesens mit
+       Getraenken. Der maximale Wert steht in P_MAX_DRINK.
+
+     - Speisen/Kneipen
+       Numerischer Wert fuer den Saettigungsgrad einer Portion eines
+       Getraenkes. Ist diese Property nicht gesetzt oder zusaetzlich
+       P_FOOD gesetzt, kann man diese Speise nicht trinken. Eine
+       funktionierende Speise _muss_ entweder P_FOOD oder P_DRINK
+       groesser 0 gesetzt haben.
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     P_MAX_DRINK, P_DRINK_DELAY, consume
+     P_FOOD, P_ALCOHOL, wiz/food
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_DRINK_DELAY.rst b/doc/sphinx/props/P_DRINK_DELAY.rst
new file mode 100644
index 0000000..199436c
--- /dev/null
+++ b/doc/sphinx/props/P_DRINK_DELAY.rst
@@ -0,0 +1,23 @@
+P_DRINK_DELAY
+=============
+
+NAME
+----
+::
+
+    P_DRINK_DELAY                 "drink_delay"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der heart_beats, bis P_DRINK um einen Punkt sinkt.
+     Aenderungen dieser Property in Spielern beduerfen der 
+     Genehmigung des EM fuer Balance.
+
diff --git a/doc/sphinx/props/P_DRINK_FULL_MSG.rst b/doc/sphinx/props/P_DRINK_FULL_MSG.rst
new file mode 100644
index 0000000..a30a49c
--- /dev/null
+++ b/doc/sphinx/props/P_DRINK_FULL_MSG.rst
@@ -0,0 +1,50 @@
+P_DRINK_FULL_MSG
+================
+
+NAME
+----
+::
+
+     P_DRINK_FULL_MSG              "std_food_drink_full_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn ein Getraenk getrunken werden soll,
+     obwohl dieser nichts mehr trinken kann.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "So viel kannst Du im Moment nicht trinken."
+
+SIEHE AUCH
+----------
+::
+
+     P_DRINK, P_MAX_DRINK, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_DROP_MSG.rst b/doc/sphinx/props/P_DROP_MSG.rst
new file mode 100644
index 0000000..7268555
--- /dev/null
+++ b/doc/sphinx/props/P_DROP_MSG.rst
@@ -0,0 +1,100 @@
+P_DROP_MSG
+==========
+
+NAME
+----
+::
+
+     P_DROP_MSG				"drop_message" 
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/put_and_get.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mit P_DROP_MSG kann man die Meldung, die man beim Ablegen eines
+     Objektes bekommt, modifizieren.
+
+     Folgende Werte sind moeglich:
+
+	
+
+     o 0
+       Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung. 
+
+	  
+
+     o NO_PNG_MSG       == -1
+       Es wird keinerlei Meldung ausgegeben
+
+	  
+
+     o Ein Array aus Strings 
+       Der erste String wird an den Spieler ausgegeben, der zweite 
+       (optionale) an den Raum. 
+
+	  
+
+       Die Strings werden durch die Funktion replace_personal() geparst.
+	Objekt1 - Spieler
+        Objekt2 - das Objekt, das fallengelassen wird
+
+	  
+
+       Wird der zweite String nicht angegeben, erfolgt keine Meldung an
+       den Raum.
+
+				
+
+BEISPIEL
+--------
+::
+
+     void create() {
+      ...
+      SetProp( P_SHORT, "Ugars Handaxt" );
+      SetProp( P_LONG, break_string(
+       "Dieses ist eine Kampfaxt, wie sie Orks normalerweise benutzen. "
+       "Da Du Zeit hast, sie Dir anzuschauen, ist der Besitzer wohl "
+       "bereits bei Lars.",78 ));
+
+	  
+
+      SetProp( P_NAME, "Axt" );
+      AddId( ({"handaxt","axt"}) );
+      SetProp( P_GENDER, FEMALE );
+
+	  
+
+      SetProp( P_DROP_MSG, ({
+       "Du schmeisst @WEN2 hin.",
+       "@WER1 schmeisst Dir @WENU2 vor die Fuesse.\n"}));
+      ...
+     }
+
+     Will Ugar seine Axt ablegen und gibt "lasse axt fallen" ein, werden 
+     folgende Meldungen ausgegeben:
+
+	
+
+     Ugar: "Du schmeisst die Axt hin."
+     Raum: "Ugar schmeisst Dir eine Axt vor die Fuesse."
+
+	
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_PICK_MSG, P_PUT_MSG, P_GIVE_MSG, P_WEAR_MSG, P_WIELD_MSG
+     Fehler:     P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
+                 P_NOINSERT_MSG, P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     Sonstiges:  replace_personal(E), drop_obj(L), /std/living/put_and_get.c
+
+14. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_EARMUFFS.rst b/doc/sphinx/props/P_EARMUFFS.rst
new file mode 100644
index 0000000..3ec9835
--- /dev/null
+++ b/doc/sphinx/props/P_EARMUFFS.rst
@@ -0,0 +1,22 @@
+P_EARMUFFS
+==========
+
+NAME
+----
+::
+
+    P_EARMUFFS                    "earmuffs"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Shouts von Spielern und Magiern mit Magierlevel < earmuffs werden
+     abgeblockt (Nur fuer Magier).
+
diff --git a/doc/sphinx/props/P_EATER_MSG.rst b/doc/sphinx/props/P_EATER_MSG.rst
new file mode 100644
index 0000000..75ccb2f
--- /dev/null
+++ b/doc/sphinx/props/P_EATER_MSG.rst
@@ -0,0 +1,49 @@
+P_EATER_MSG
+===========
+
+NAME
+----
+::
+
+     P_EATER_MSG                   "std_food_eater_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn eine Speise konsumiert wird.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "Du konsumierst @WEN1."
+
+SIEHE AUCH
+----------
+::
+
+     /std/food.c, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_EFFECTIVE_AC.rst b/doc/sphinx/props/P_EFFECTIVE_AC.rst
new file mode 100644
index 0000000..50fbeb1
--- /dev/null
+++ b/doc/sphinx/props/P_EFFECTIVE_AC.rst
@@ -0,0 +1,107 @@
+P_EFFECTIVE_AC
+==============
+
+NAME
+----
+::
+
+     P_EFFECTIVE_AC      "effective_ac"
+
+DEFINIERT IN
+------------
+::
+
+     <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property kommt sowohl in Ruestungen als auch in Waffen, die
+     schuetzen sollen, zum Einsatz.
+
+     In Ruestungen kann hier der Effektivwert der Ruestungsklasse vermerkt
+     werden, wenn diese noch durch eine DefendFunc() modifiziert wird
+     (soweit sich ein solcher Effektivwert angeben laesst).
+
+     In einigen Gilden koennen Waffen auch als Ruestung eingesetzt werden
+     (z.B. beim Parieren eines Angriffs). In dieser Property kann man die
+     Ruestungsklasse eintragen, die die Waffe bei solchen Aktionen aufweisen
+     soll. Dabei ist man an die ueblichen Beschraenkungen der
+     Ruestungsklasse gebunden! (s. /sys/combat.h)
+
+BERMERKUNGEN
+------------
+::
+
+     Das Kaempferspellbook verwendet fuer Paraden etc. P_EFFECTIVE_AC anstatt
+     P_AC, wenn verfuegbar.
+
+BEISPIELE
+---------
+::
+
+     * DefendFuncs: 
+       Der doppelte Mittelwert der DefendFunc wird zur Basis-AC dazuaddiert,
+       da sich der 'Schutzwert = random(Basis-AC) + absolut(DefendFunc-Wert)'
+       berechnet.
+
+     // #1 Eine Ruestung mit P_AC von 35 und randomisierter DefendFunc
+        SetProp(P_AC, 35);
+        SetProp(P_DEFEND_FUNC, this_object());
+
+        int DefendFunc(...) {
+          return random(20);                       // Mittelwert: 10
+        }
+        -> SetProp(P_EFFECTIVE_AC, 55);            // 35 + 2*10 = 55
+
+     // #2 Eine Ruestung mit P_AC von 35 und teilrandomisierter DefendFunc
+        SetProp(P_AC, 35);
+        SetProp(P_DEFEND_FUNC, this_object());
+
+        int DefendFunc(...) {
+          return 20 + random(10);                  // Mittelwert: 20 + 5
+        }
+        -> SetProp(P_EFFECTIVE_AC, 85);            // 35 + 2*(20+5) = 85
+
+     * Sonderfunktion im Kontext der Kaempfergilde:
+       Auch wenn der eigentliche AC-Wert durch keine DefendFunc oAe
+       modifiziert wird, sind abweichende Werte in P_EFFECTIVE_AC zB in der
+       Kaempfergilde fuer Paraden oder aehnliches sinnvoll. Maximalwert ist
+       dafuer der doppelte Wert des Basis-AC-Wertes.
+
+     // #3 Ein schon sehr gutes Schild, welches bei der Schildparade aber
+     //    noch besser schuetzen soll.
+        SetProp(P_ARMOUR_TYPE, AT_SHIELD);
+        SetProp(P_AC, 38);
+        SetProp(P_EFFECTIVE_AC, 55);
+
+     // #4 Ein sehr labbriges Schild schuetzt zwar gegen normale Schlaege,
+     //    ist zum Parieren aber irgendwie ungeeignet weil unkontrollierbar.
+        SetProp(P_ARMOUR_TYPE, AT_SHIELD);
+        SetProp(P_AC, 38);
+        SetProp(P_EFFECTIVE_AC, 20);
+
+     * Waffen:
+       P_EFFECTIVE_AC wird im Kaempferspellbook als Bonus dazugezaehlt! Daher
+       sollten gute Parierwaffen auch einen niedrigeren P_WC-Wert haben.
+       Reine Parierwaffen duerfen den maximalen AC-Wert von Schilden als
+       Maximum gesetzt haben - die Balance klaert ggf, ob das auch auf den
+       Gildenparierwert anwendbar ist.
+
+     // #5 Eine maessige Hellebarde/Axtwaffe mit Parierhaken.
+        SetProp(P_WEAPON_TYPE, WT_AXE);
+        SetProp(P_WC, 100);
+        SetProp(P_EFFECTIVE_AC, 25);
+
+SIEHE AUCH
+----------
+::
+
+     Waffen:     P_WC, P_TOTAL_WC, P_EFFECTIVE_WC, HitFunc()
+     Ruestungen: P_AC, P_TOTAL_AC, DefendFunc()
+     Files:      /std/weapon.c, /std/weapon/combat.c
+     Balance:    waffen, ruestungen, properties, kaempferboni
+
+6. Nov 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_EFFECTIVE_WC.rst b/doc/sphinx/props/P_EFFECTIVE_WC.rst
new file mode 100644
index 0000000..6064049
--- /dev/null
+++ b/doc/sphinx/props/P_EFFECTIVE_WC.rst
@@ -0,0 +1,112 @@
+P_EFFECTIVE_WC
+==============
+
+NAME
+----
+::
+
+     P_EFFECTIVE_WC     "effective_wc"
+
+DEFINIERT IN
+------------
+::
+
+     <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property kommt sowohl in Waffen als auch Ruestungen, die Schaden
+     machen sollen, zum Einsatz.
+
+     Falls die Staerke einer Waffe noch durch eine HitFunc() modifiziert
+     wird, sollte hier der Effektivwert der Waffenklasse vermerkt werden,
+     soweit er sich angeben laesst.
+     Diese Property dient vor allem dazu, eine Waffe mit HitFunc() korrekt
+     einzuschaetzen.
+
+     In einigen Gilden koennen Ruestungen auch als Waffen eingesetzt werden
+     (z.B. ein Paar Schuhe zum Treten). In dieser Property kann man die
+     Waffenklasse eintragen, die die Ruestung bei solchen Aktionen aufweisen
+     soll. Dabei ist man an die ueblichen Beschraenkungen der Waffenklasse
+     gebunden! (s. /sys/combat.h)
+     Der Ruestung kann man dann auch einen Schadenstyp mit auf den Weg
+     geben.
+
+BEMERKUNGEN
+-----------
+::
+
+     Das Kaempferspellbook verwendet bei Ruestungen P_AC, wenn
+     P_EFFECTIVE_WC nicht gesetzt ist.
+
+BEISPIELE
+---------
+::
+
+     * HitFuncs:
+       Der doppelte Mittelwert der HitFunc wird zur Basis-WC dazuaddiert,
+       da sich der 'Angriffswert = random(Basis-WC) + absolut(HitFunc-Wert)'
+       berechnet.
+
+     // #1 Waffe mit Basis-WC 120 und randomisierter HitFunc
+        SetProp(P_WC, 120);
+        SetProp(P_HIT_FUNC, this_object());
+
+       
+
+        int HitFunc(...) {
+          return random(30);                       // Mittelwert: 15
+        }
+        -> SetProp(P_EFFECTIVE_WC, 150);           // 120 + 2*15 = 150
+
+     
+
+     // #2 Waffe mit Basis-WC 120 und teilweise absoluter HitFunc
+        SetProp(P_WC, 120);
+        SetProp(P_HIT_FUNC, this_object());
+
+       
+
+        int HitFunc(...) {
+          return 30 + random(10);                  // Mittelwert: 30 + 5
+        }
+        -> SetProp(P_EFFECTIVE_WC, 190);           // 120 + 2*(30+5) = 190
+
+     * Ruestungen (zB Gildennutzung):
+       Der Maximalwert fuer die P_EFFECTIVE_WC bei Kaempfern ist der jeweils
+       doppelte maximale P_AC-Wert. Angabe eines Schadenstyps ist sinnvoll.
+
+     // #3 Ein paar Schuhe, mit maximalem Schlag-/Saeureschaden.
+        SetProp(P_ARMOUR_TYPE, AT_BOOT);
+        SetProp(P_AC, 2);
+        SetProp(P_DAM_TYPE, ({DT_BLUDGEON,DT_ACID}));
+        -> SetProp(P_EFFECTIVE_WC, 12);  // hoechstmoeglicher Wert bei
+                                         // Schuhen, da deren max. P_AC = 6
+     // aequivalent und zukunftssicher:
+        -> SetProp(P_EFFECTIVE_WC, 2 * VALID_ARMOUR_CLASS[AT_BOOT]);
+
+     // #4 Ein Schild mit spitzem Dorn. (Stichschaden beim Schildstoss.)
+        SetProp(P_ARMOUR_TYPE, AT_SHIELD);
+        SetProp(P_AC, 5);
+        SetProp(P_DAM_TYPE, ({DT_PIERCE}));
+        SetProp(P_EFFECTIVE_WC, 55);
+
+     // #5 Ein Gummischild ist schlecht fuer Angriffe. BOING!
+        SetProp(P_ARMOUR_TYPE, AT_SHIELD);
+        SetProp(P_AC, 30);
+        SetProp(P_DAM_TYPE, ({DT_BLUDGEON}));
+        SetProp(P_EFFECTIVE_WC, 10);
+
+SIEHE AUCH
+----------
+::
+
+     Waffen:     P_WC, P_TOTAL_WC, HitFunc()
+     Ruestungen: P_AC, P_TOTAL_AC, P_EFFECTIVE_AC, DefendFunc()
+     Files:      /std/weapon.c, /std/weapon/combat.c
+     Balance:    waffen, ruestungen, properties, kaempferboni
+
+6. Nov 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_EMPTY_MSG.rst b/doc/sphinx/props/P_EMPTY_MSG.rst
new file mode 100644
index 0000000..a7855f4
--- /dev/null
+++ b/doc/sphinx/props/P_EMPTY_MSG.rst
@@ -0,0 +1,50 @@
+P_EMPTY_MSG
+===========
+
+NAME
+----
+::
+
+     P_EMPTY_MSG                   "std_food_eater_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn versucht wird, eine aufgebrauchte Speise
+     (also einen leeren Behaelter) zu konsumieren.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise (also den leeren Behaelter)
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "@WER1 ist bereits leer."
+
+SIEHE AUCH
+----------
+::
+
+     /std/food.c, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_EMPTY_PROPS.rst b/doc/sphinx/props/P_EMPTY_PROPS.rst
new file mode 100644
index 0000000..43512b9
--- /dev/null
+++ b/doc/sphinx/props/P_EMPTY_PROPS.rst
@@ -0,0 +1,59 @@
+P_EMPTY_PROPS
+=============
+
+NAME
+----
+::
+
+     P_EMPTY_PROPS                 "std_food_empty_props"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Mapping mit Properties fuer den leeren Behaelter, der uebrig bleibt,wenn
+     eine Speise aufgebraucht ist. Alle enthaltenen Properties werden gesetzt,
+     wenn keine Portionen mehr vorhanden sind.
+     Bereits in diesen Properties eingetragene Werte werden ueberschrieben!
+     Wenn diese Property nicht gesetzt ist, wird die Speise zerstoert, wenn
+     alle Portionen aufgebraucht ist - es bleibt also kein Behaelter zurueck.
+     Achtung: Es werden keine closures in diesem Mapping unterstuetzt!
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Bei der Abfrage von P_VALUE und P_WEIGHT in der Speise, werden die dazu
+     in P_EMPTY_PROPS gespeicherten Werte verwendet, um das Gewicht/Wert des
+     leeren Behaelters zum Gesamtwert der Speise zu addieren.
+     Man kann alle Properties in dieses Mapping eintragen, die sich in der
+     Speise per SetProp setzen lassen. Zusaetzlich kann man Arrays in P_IDS
+     und P_ADJECTIVES speichern, die per Add-Methode in der Speise
+     hinzugefuegt werden, nachdem die im create() der Speise hinzugefuegten
+     Ids/Adjectives dort entfernt wurden.
+
+     
+
+BEISPIELE
+---------
+::
+
+     Beispiele zur Verwendung findet man unter /doc/beispiele/food
+
+SIEHE AUCH
+----------
+::
+
+     /std/food.c, wiz/food
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_ENABLE_IN_ATTACK_OUT.rst b/doc/sphinx/props/P_ENABLE_IN_ATTACK_OUT.rst
new file mode 100644
index 0000000..af59fb0
--- /dev/null
+++ b/doc/sphinx/props/P_ENABLE_IN_ATTACK_OUT.rst
@@ -0,0 +1,52 @@
+P_ENABLE_IN_ATTACK_OUT
+======================
+
+NAME
+----
+::
+
+	P_ENABLE_IN_ATTACK_OUT		"enable_in_attack_out"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	Normalerweise wird die bekannte Taktik Rein-Angriff-Raus
+	standardmaessig unterbunden, damit NPCs auch eine Chance haben, sich
+	zu verteidigen. Hierzu wird der Schaden innerhalb do_damage()
+	durch einen Wert geteilt, der sich aus der Verweildauer des
+	Angreifers im Raum ergibt (bis zu 3 Sekunden).
+	Da manche NPCs so konzeptioniert wurden, dass man sie nur mit der
+	erwaehnten Taktik toeten kann, kann man sie auch explizit erlauben
+	(manche NPCs verwenden auch eigene Methoden, diese Taktik zu
+	 verbieten, und sie waere dann doppelt abgefangen).
+	Hierzu setzt man einfach die Property P_ENABLE_IN_ATTACK_OUT im NPC.
+
+BEISPIEL
+--------
+::
+
+	Das folgende Beispiel erlaubt einfach mal die angesprochene Taktik:
+	  void create()
+	  { ...
+	    SetProp(P_ENABLE_IN_ATTACK_OUT,1);
+	    ...
+	  }
+	Jetzt kann man den NPC mit Rein-Angriff-Raus auch wirkungsvoll
+	bekaempfen.
+
+SIEHE AUCH
+----------
+::
+
+	do_damage(), P_LAST_MOVE, /std/living/life.c
+
+
+Last modified: Sat Jan 30 12:53:00 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_ENEMY_DAMAGE.rst b/doc/sphinx/props/P_ENEMY_DAMAGE.rst
new file mode 100644
index 0000000..6991f15
--- /dev/null
+++ b/doc/sphinx/props/P_ENEMY_DAMAGE.rst
@@ -0,0 +1,48 @@
+P_ENEMY_DAMAGE
+==============
+
+NAME
+----
+::
+
+     P_ENEMY_DAMAGE "enemy_damage"
+
+DEFINIERT IN
+------------
+::
+
+     <living/life.h>
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property ist vermerkt, welches Wesen diesem Wesen wieviel
+     Schaden zugefuegt hat.
+
+     Die Property enthaelt ein Mapping, das den Angreifern den
+     errechten Schaden zuordnet:
+     ([ <obname1>: <damage>; <owner>, ... ])
+
+       <obname1>: Name des Objekts, das den Schaden verursacht hat (string),
+                  z.B. "/magier:zesstra"
+       <damage> : Schadensmenge (int)
+       <owner>  : wenn das schadensverursachende Wesen ein NPC war/ist,
+                  welches P_HELPER_NPC gesetzt hatte und somit einem Spieler
+                  hilft, steht hier das Objekt des jeweiligen Spielers
+                  (object)
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Property laesst sich nur abfragen!
+
+SIEHE AUCH
+----------
+::
+
+     P_HELPER_NPC
+
+26.10.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_ENEMY_DEATH_SEQUENCE.rst b/doc/sphinx/props/P_ENEMY_DEATH_SEQUENCE.rst
new file mode 100644
index 0000000..82e888e
--- /dev/null
+++ b/doc/sphinx/props/P_ENEMY_DEATH_SEQUENCE.rst
@@ -0,0 +1,61 @@
+P_ENEMY_DEATH_SEQUENCE
+======================
+
+NAME
+----
+::
+
+     P_ENEMY_DEATH_SEQUENCE        "enemy_death_sequence"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Ueber diese Property kann Einfluss auf die Todessequenz eines getoeten
+     Spielers genommen werden. Sie muss im toetenden Objekt, d.h. dem
+     Objekt welches die()/do_damage()/Defend() im Spieler gerufen hat,
+     gesetzt sein.
+
+     Es gibt folgende gueltige Werte:
+     - string: Pfad zu einer eigenen Todessequenz im gueltigen Format
+     - mixed*  Eine Todessequenz im Format des Todesraumes:
+               ({<int gesamtlaenge>,
+                 ([<int index1>: <string umgebrochene Meldung1>,
+                   <int index2>: <string umgebrochene Meldung2>,
+                   ...])
+               })
+     - mapping In die Standard-Lars-Todessequenz einzufuegende Zeilen:
+               ([<int zeitindex>: <string umgebrochener Text>])
+
+BEISPIELE
+---------
+::
+
+     // Pfad zu einer eigenen DSQ
+     SetProp(P_ENEMY_DEATH_SEQUENCE,  ".../passende_dsq.txt");
+
+     // eigene DSQ im Todesraumformat:
+     SetProp(P_ENEMY_DEATH_SEQUENCE,
+             ({ 2, ([1: "DU LERNST AUS DEINEM FEHLER.\n"])}));
+
+     // Einfuegen einer Meldung (des NPCs) in die Standard-Todessequenz
+     SetProp(P_ENEMY_DEATH_SEQUENCE,
+             ([5: "Du hoerst "+name(WEN)+" hoehnisch kichern.\n"]));
+
+SIEHE AUCH
+----------
+::
+
+     Tod:            die(L)
+     Todesmeldungen: P_KILL_NAME, P_KILL_MSG, P_DIE_MSG, P_MURDER_MSG
+                     P_ZAP_MSG, P_NEXT_DEATH_SEQUENCE
+     Sonstiges:      P_CORPSE, P_NOCORPSE, /room/death/death_room.c
+
+10. Nov 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_ENTERCMDS.rst b/doc/sphinx/props/P_ENTERCMDS.rst
new file mode 100644
index 0000000..17f9de1
--- /dev/null
+++ b/doc/sphinx/props/P_ENTERCMDS.rst
@@ -0,0 +1,59 @@
+P_ENTERCMDS
+===========
+
+NAME
+----
+::
+
+    P_ENTERCMDS                   "leavecmds"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+    Ein Array mit Befehlen, die zum Betreten des Transporters fuehren. 
+
+BEISPIEL
+--------
+::
+
+    SetProp(P_ENTERCMDS,({ "betrete","betritt" }) );
+
+    Gibt der Spieler nun 'betrete xxx' ein, so sorgt /std/transport.c 
+    dafuer, das der Spieler auch auf oder in den Transporter bewegt 
+    wird. Vorausgesetzt natuerlich, er ist an einem Haltepunkt ange-
+    langt und es ist genuegend Platz dort.
+
+BEMERKUNGEN
+-----------
+::
+
+    Um /std/transport.c nicht aufzublaehen, werden weitere Argumente wie
+    etwa 'betrete das|die|den xxx' _nicht_ unterstuetzt!
+
+    Hier muss der verantwortliche Magier schon eine eigene Loesung finden
+    und in seinen Transporter schreiben.
+
+    Sollen Kommandos zum Betreten UND Verlassen eines Transporters ver-
+    wendet werden koennen, muessen diese in P_TRAVEL_CMDS gesetzt werden.
+
+SIEHE AUCH
+----------
+::
+
+    P_LEAVEFAIL, P_ENTERFAIL, P_LEAVECMDS, P_TRAVEL_CMDS, transporter,
+
+LETZTE AENDERUNG
+----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
+    
+
diff --git a/doc/sphinx/props/P_ENTERFAIL.rst b/doc/sphinx/props/P_ENTERFAIL.rst
new file mode 100644
index 0000000..538b528
--- /dev/null
+++ b/doc/sphinx/props/P_ENTERFAIL.rst
@@ -0,0 +1,48 @@
+P_ENTERFAIL
+===========
+
+NAME
+----
+::
+
+    P_ENTERFAIL                   "enterfail"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Spieler, wenn er einen vollen Transporter betreten 
+     will. Ist die Propertie ein Array, so wird das erste Element als
+     Meldung an den Spieler, das zweite als Meldung an die Mitspieler 
+     im Raum geschickt.
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_ENTERFAIL,"Dort ist wirklich kein Platz mehr fuer Dich");
+
+     
+
+     SetProp(P_ENTERFAIL, ({ "Dort ist wirklich kein Platz mehr fuer Dich",
+                             "versucht, auf die Kutsche zu klettern, wird "
+                            +"aber wieder heruntergeschickt" }) );
+
+SIEHE AUCH
+----------
+::
+
+     P_ENTERMSG, P_LEAVEFAIL, P_LEAVEMSG, transporter
+
+LETZTE AENDERUNG
+----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
diff --git a/doc/sphinx/props/P_ENTERMSG.rst b/doc/sphinx/props/P_ENTERMSG.rst
new file mode 100644
index 0000000..72e5ea4
--- /dev/null
+++ b/doc/sphinx/props/P_ENTERMSG.rst
@@ -0,0 +1,40 @@
+P_ENTERMSG
+==========
+
+NAME
+----
+::
+
+    P_ENTERMSG                    "entermsg"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+     Array mit zwei Meldungen, eine fuer den Raum, den der Spieler
+     verlaesst, und eine fuer den Transporter, in den er geht.
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_ENTERMSG, ({ "klettert in die Kutsche","klettert herein" }) );
+
+SIEHE AUCH
+----------
+::
+
+     P_ENTERFAIL, P_LEAVEFAIL, P_LEAVEMSG, transporter
+
+LETZTER AENDERUNG
+-----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
diff --git a/doc/sphinx/props/P_ENV_MSG.rst b/doc/sphinx/props/P_ENV_MSG.rst
new file mode 100644
index 0000000..ec38445
--- /dev/null
+++ b/doc/sphinx/props/P_ENV_MSG.rst
@@ -0,0 +1,52 @@
+P_ENV_MSG
+=========
+
+NAME
+----
+::
+
+     P_ENV_MSG                     "std_food_env_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn eine Speise konsumiert werden soll,
+     die nicht im eigenen Inventory liegt.
+     Wenn diese Property leer ist, kann man die Speise dann sogar
+     konsumieren!
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "Vielleicht solltest Du @WEN1 vorher nehmen."
+
+SIEHE AUCH
+----------
+::
+
+     wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_ENV_TOO_HEAVY_MSG.rst b/doc/sphinx/props/P_ENV_TOO_HEAVY_MSG.rst
new file mode 100644
index 0000000..619628c
--- /dev/null
+++ b/doc/sphinx/props/P_ENV_TOO_HEAVY_MSG.rst
@@ -0,0 +1,50 @@
+P_ENV_TOO_HEAVY_MSG
+===================
+
+NAME
+----
+::
+
+    P_ENV_TOO_HEAVY_MSG                      "env_too_heavy_msg"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn jemand
+     versucht, ein Objekt in einen Behaelter zu legen, und dieser dann fuer
+     sein Environment zu schwer wird.
+     Die Property ist im Behaelter zu setzen.
+     Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
+     so wird die Standardmeldung ausgegeben.
+     ("<Behaelter> wuerde dir dann zu schwer werden.")
+     Der String in der Property wird noch durch replace_personal()
+     verarbeitet, das zu bewegende Objekt wird als erstes, der Behaelter als
+     zweites Objekt angegeben. Danach wird der String auf 78 Zeichen
+     umgebrochen.
+     Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
+     ganz.
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_ENV_TOO_HEAVY_MSG, "Mit @WEM1 koenntest du den Rucksack nicht"
+                                  " mehr tragen.");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_TOO_HEAVY_MSG, P_TOO_MANY_MSG, P_NOINSERT_MSG,
+                 P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     Erfolg:     P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
+                 P_WEAR_MSG, P_WIELD_MSG
+     Sonstiges:  replace_personal(E), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/props/P_EQUIP_TIME.rst b/doc/sphinx/props/P_EQUIP_TIME.rst
new file mode 100644
index 0000000..eca2965
--- /dev/null
+++ b/doc/sphinx/props/P_EQUIP_TIME.rst
@@ -0,0 +1,40 @@
+P_EQUIP_TIME
+============
+
+NAME
+----
+::
+
+      P_EQUIP_TIME			"equip_time"
+
+DEFINIERT IN
+------------
+::
+
+      /sys/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+      Innerhalb von Waffen und Ruestungen wird in dieser Property
+      registriert, wann diese zuletzt gezueckt bzw. angezogen wurden.
+      Innerhalb der Funktionen wield_me() in '/std/weapon/combat' bzw.
+      DoWear() in '/std/armour/combat' wird hierbei jeweils folgende Aktion
+      ausgefuehrt:
+	SetProp(P_EQUIP_TIME,time());
+
+SIEHE AUCH
+----------
+::
+
+      Verwandt:		P_LAST_USE
+      Waffen:		P_UNWIELD_TIME
+			DoWield()
+      Ruestungen:	DoWear()
+      Sonstiges:	time()
+			/std/weapon/combat.c, /std/armour/combat.c
+
+
+Last modified: Sun Jul 26 23:59:12 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_EVAL_FACTORS.rst b/doc/sphinx/props/P_EVAL_FACTORS.rst
new file mode 100644
index 0000000..7d390ed
--- /dev/null
+++ b/doc/sphinx/props/P_EVAL_FACTORS.rst
@@ -0,0 +1,21 @@
+P_EVAL_FACTORS
+==============
+
+NAME
+----
+::
+
+    P_EVAL_FACTORS                "inpc_eval_factors"           
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/eval.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_EVAL_OFFSETS.rst b/doc/sphinx/props/P_EVAL_OFFSETS.rst
new file mode 100644
index 0000000..ff6e604
--- /dev/null
+++ b/doc/sphinx/props/P_EVAL_OFFSETS.rst
@@ -0,0 +1,21 @@
+P_EVAL_OFFSETS
+==============
+
+NAME
+----
+::
+
+    P_EVAL_OFFSETS                "inpc_eval_offsets"           
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/eval.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_EXITS.rst b/doc/sphinx/props/P_EXITS.rst
new file mode 100644
index 0000000..574f33c
--- /dev/null
+++ b/doc/sphinx/props/P_EXITS.rst
@@ -0,0 +1,47 @@
+P_EXITS
+=======
+
+NAME
+----
+::
+
+    P_EXITS                       "exits"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mapping (der Breite 2) aller unmittelbar sichtbaren Ausgaenge mit
+    zugehoerigen Nachbarraeumen und der jeweiligen Bewegungsmeldung.
+
+BEMERKUNG
+---------
+::
+
+    Enthaelt auch SpecialExits, bei der Abfrage mit QueryProp() werden
+    diese jedoch ausgefiltert.
+
+    
+
+    Zugriff nur mit den dafuer vorgesehenen Funktionen, bitte nicht aendern.
+
+  
+
+SIEHE AUCH
+----------
+::
+
+     AddExit(), AddSpecialExit(), GetExits(),
+     RemoveExit(), RemoveSpecialExit(),
+     GuardExit(),
+     H_HOOK_EXIT_USE, P_SPECIAL_EXITS, P_HIDE_EXITS, /std/room/exits.c
+     ausgaenge
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/props/P_FAO.rst b/doc/sphinx/props/P_FAO.rst
new file mode 100644
index 0000000..3e692a0
--- /dev/null
+++ b/doc/sphinx/props/P_FAO.rst
@@ -0,0 +1,33 @@
+P_FAO
+=====
+
+NAME
+----
+::
+
+     P_FAO      "fraternitasdonoarchmagorum"
+
+DEFINIERT IN
+------------
+::
+
+     <player/fao.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Fraternitas-relevante Property.
+
+     Genaue Informationen unbekannt.
+     Schreibender Zugriff ist nur EMs oder dem FAOMASTER (s. Headerfile)
+     moeglich.
+
+SIEHE AUCH
+----------
+::
+
+     P_FAO_PORTALS
+
+1.September 2008 Gloinson
+
diff --git a/doc/sphinx/props/P_FAO_PORTALS.rst b/doc/sphinx/props/P_FAO_PORTALS.rst
new file mode 100644
index 0000000..a155488
--- /dev/null
+++ b/doc/sphinx/props/P_FAO_PORTALS.rst
@@ -0,0 +1,38 @@
+P_FAO_PORTALS
+=============
+
+NAME
+----
+::
+
+     P_FAO_PORTALS      "fraternitasdonoarchmagorumPORTALS"
+
+DEFINIERT IN
+------------
+::
+
+     <player/fao.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Fraternitas-relevante Property.
+
+     Enthaelt eine Array mit einer Liste der ueber die Fraternitas
+     gefundenen und benutzbaren Seher-Portale.
+
+     Genaue Informationen unbekannt.
+     Schreibender Zugriff ist nur EMs oder dem FAOMASTER (s. Headerfile) 
+     moeglich.
+
+SIEHE AUCH
+----------
+::
+
+     P_FAO_PORTALS, P_SEERDOORS
+
+     
+
+1.September 2008 Gloinson
+
diff --git a/doc/sphinx/props/P_FISH.rst b/doc/sphinx/props/P_FISH.rst
new file mode 100644
index 0000000..f91a4d8
--- /dev/null
+++ b/doc/sphinx/props/P_FISH.rst
@@ -0,0 +1,93 @@
+P_FISH
+======
+
+NAME
+----
+::
+
+    P_FISH                        "fish"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/fishing.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt Einstellungen zu allem, was mit Fischen zu tun hat. 
+    Kann in Fischen, Raeumen und Koedern gesetzt werden. Die verfuegbaren 
+    Optionen und Funktionsweisen sind in den nachfolgenden Abschnitten 
+    aufgefuehrt.
+
+    Fische:
+    *******
+    Die Property legt zusaetzliche Eigenschaften fest:
+
+      F_NOROTTEN
+        Fisch fault nicht; ggf. sollte hier auch gleich F_NOHEAL gesetzt 
+        werden, weil sonst eine unverderbliche tragbare Tanke erzeugt wuerde.
+      F_NOTHUNGRY
+        Fisch frisst Koeder nur, wenn er auch wirklich nachher an der Angel
+        haengt. Ist er zu schwer fuer die Angel und reisst ab, bleibt der
+        Koeder erhalten.
+      F_REPLACE
+        Fisch soll sich beim Entfernen von der Angel verwandeln. Hierzu ist
+        die Funktion ReplaceFish() im Fisch zu definieren, die sich um die
+        Verwandlung kuemmert (z.B. Monster clonen und Fisch zerstoeren; ein
+        Beispiel findet sich in /d/ebene/fraggle/angel2/obj/saegefisch.c).
+      F_NOHEAL
+        Fisch heilt nicht bei Verzehr
+
+    Raum (OPTIONAL):
+    ****************
+    Legt die Fischdichte des Gewaessers fest. Der eingestellte Wert wirkt 
+    sich auf die Wartezeit aus, die der Angler verbringen muss, bis ein 
+    Fisch anbeisst. Berechnung im Detail (alle Zahlenwerte in Sekunden):
+    - Basis-Wartezeit: delay = 80
+    - Die Werte von P_FISH von Raum und Koeder werden addiert:
+      summe = raum->QueryProp(P_FISH) + koeder->QueryProp(P_FISH)
+      -> positive Werte (Bonus) werden auf 60 begrenzt und mit Zufalls-
+         komponente von <delay> abgezogen:
+         delay -= random(summe)
+      -> negative Werte (Malus) werden auf -300 begrenzt und mit Zufalls-
+         komponente auf <delay> aufgeschlagen:
+         delay += random(-summe)
+
+    Zusaetzlich wird ein weiterer Malus auf die Wartezeit faellig, falls 
+    P_WATER in der Angel und/oder P_WATER im Koeder nicht zum aktuellen 
+    Gewaesser passen. Der Malus betraegt jeweils 60+random(60) Sekunden.
+
+    
+
+    Der Standardwert fuer P_FISH im Raum ist 0 und bedeutet 100 % Bestand.
+    Positive Werte erhoehen die Dichte, negative senken sie. Positive Werte 
+    sollten nicht >100 sein.
+
+    Sofern sich die Werte fuer P_FISH in den empfohlenen Grenzen bewegen,
+    koennen Abzuege fuer falsches Gewaesser ueblicherweise kaum durch
+    Boni auf Angel oder Koeder kompensiert werden. Ausserdem ist zu
+    bedenken, dass es keine Boni fuer richtige Gewaesserwahl gibt.
+
+ 
+
+    Koeder (OPTIONAL):
+    ******************
+    Ein Koeder kann mittels P_FISH die Fischdichte modifizieren, um hierueber
+    ein besseres Beissen der Fische zu simulieren (reduziert die Wartezeit
+    beim Angeln, siehe oben unter "Raum"). Wenn also der Raum einen Wert
+    von -100 gesetzt hat und der Koeder +100, entspricht die Fischdichte im 
+    Gewaesser wieder dem Normalwert.
+
+SIEHE AUCH
+----------
+::
+
+    Properties: P_WATER
+    Methoden:   GetAquarium(L)
+
+
+Zuletzt geaendert: 2014-Aug-21, Arathorn
+
diff --git a/doc/sphinx/props/P_FLAGS.rst b/doc/sphinx/props/P_FLAGS.rst
new file mode 100644
index 0000000..22a2fef
--- /dev/null
+++ b/doc/sphinx/props/P_FLAGS.rst
@@ -0,0 +1,21 @@
+P_FLAGS
+=======
+
+NAME
+----
+::
+
+    P_FLAGS                       "can_flags"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Flags des Spielers
+
diff --git a/doc/sphinx/props/P_FOLLOW_SILENT.rst b/doc/sphinx/props/P_FOLLOW_SILENT.rst
new file mode 100644
index 0000000..5424539
--- /dev/null
+++ b/doc/sphinx/props/P_FOLLOW_SILENT.rst
@@ -0,0 +1,22 @@
+P_FOLLOW_SILENT
+===============
+
+NAME
+----
+::
+
+    P_FOLLOW_SILENT               "follow_silent"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn diese Property 1 ist, wird der MOVE vom verfolge Silent ausge-
+     fuehrt.
+
diff --git a/doc/sphinx/props/P_FOOD.rst b/doc/sphinx/props/P_FOOD.rst
new file mode 100644
index 0000000..4acd9e6
--- /dev/null
+++ b/doc/sphinx/props/P_FOOD.rst
@@ -0,0 +1,39 @@
+P_FOOD
+======
+
+NAME
+----
+::
+
+     P_FOOD                        "food"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     - Lebewesen
+       Numerischer Wert fuer den Saettigungsgrad eines Lebewesens.
+       Der maximale Wert steht in P_MAX_FOOD.
+
+     - Speisen/Kneipen
+       Numerischer Wert fuer den Saettigungsgrad einer Portion einer
+       Speise. Ist diese Property nicht gesetzt, kann man diese
+       Speise nicht essen. Eine funktionierende Speise _muss_ entweder
+       P_FOOD oder P_DRINK groesser 0 gesetzt haben.
+
+SIEHE AUCH
+----------
+::
+
+     P_MAX_FOOD, P_FOOD_DELAY, consume,
+     P_DRINK, P_ALCOHOL, wiz/food
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_FOOD_DELAY.rst b/doc/sphinx/props/P_FOOD_DELAY.rst
new file mode 100644
index 0000000..e19f2e8
--- /dev/null
+++ b/doc/sphinx/props/P_FOOD_DELAY.rst
@@ -0,0 +1,23 @@
+P_FOOD_DELAY
+============
+
+NAME
+----
+::
+
+    P_FOOD_DELAY                 "food_delay"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der heart_beats, bis P_FOOD um einen Punkt sinkt.
+     Aenderungen dieser Property in Spielern beduerfen der 
+     Genehmigung des EM fuer Balance.
+
diff --git a/doc/sphinx/props/P_FOOD_FULL_MSG.rst b/doc/sphinx/props/P_FOOD_FULL_MSG.rst
new file mode 100644
index 0000000..9f74716
--- /dev/null
+++ b/doc/sphinx/props/P_FOOD_FULL_MSG.rst
@@ -0,0 +1,50 @@
+P_FOOD_FULL_MSG
+===============
+
+NAME
+----
+::
+
+     P_FOOD_FULL_MSG               "std_food_full_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn eine Speise gegessen werden soll,
+     obwohl dieser nichts mehr essen kann.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "Du bist zu satt, das schaffst Du nicht mehr."
+
+SIEHE AUCH
+----------
+::
+
+     P_FOOD, P_MAX_FOOD, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_FORCE_MURDER_MSG.rst b/doc/sphinx/props/P_FORCE_MURDER_MSG.rst
new file mode 100644
index 0000000..059b096
--- /dev/null
+++ b/doc/sphinx/props/P_FORCE_MURDER_MSG.rst
@@ -0,0 +1,58 @@
+P_FORCE_MURDER_MSG
+==================
+
+NAME
+----
+::
+
+	P_FORCE_MURDER_MSG		"force_murder_msg"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+	Ob der Tod eines NPCs auf dem Moerder-Kanal erscheint, haengt davon
+	ab, wie oft und welche Art von NPCs in der letzten Zeit getoetet
+	wurden. Zum Beispiel ist es eher selten, dass ein schwacher NPC auf
+	dem Kanal erscheint, wenn kuerzlich viele starke NPCs getoetet
+	wurden. Mittels der Property P_FORCE_MURDER_MSG kann man auf diese
+	Regelung Einfluss nehmen.
+	Ein Wert groesser Null erzwingt die Meldung auf dem Moerder-Kanal,
+	ein Wert kleiner Null unterdrueckt sie generell. Letzteres ist
+	insbesondere fuer allzuoft getoetete Monster sinnvoll, um den
+	Moerder-Kanal nicht uebermaessig zu belasten. Mit dem Erzwingen der
+	Meldungen sollte man somit vorsichtig sein: Weniger ist oftmals
+	besser als zu viel!
+	Die Defaulteinstellung von P_FORCE_MURDER_MSG ist natuerlich Null
+	und fuehrt zur bereits beschriebenen opferabhaengigen Meldung.
+
+BEISPIELE
+---------
+::
+
+	Ein grosser starker NPC, der getoetet wurde, sollte schon eine tolle
+	Meldung auf dem Moerder-Kanal erzeugen. In der Property
+	P_MURDER_MSG koennen hierzu alternative Texte zu den normal per
+	Zufall ausgewaehlten angegeben werden:
+	  SetProp(P_MURDER_MSG,
+                  "Nicht schlecht, aber das schafft eh nur einer!");
+	  SetProp(P_FORCE_MURDER_MSG,1);
+	Zwar ist es bei grossen NPCs hinreichend wahrscheinlich, dass es
+	infolge derer Staerke zur automatischen Ausgabe einer Moerdermeldung
+	kommt, aber mit der letzten Zeile wurde dies absolut sichergestellt.
+
+SIEHE AUCH
+----------
+::
+
+	P_MURDER_MSG, P_ZAP_MSG, P_KILL_MSG, P_DIE_MSG, P_CORPSE, P_NOCORPSE
+
+
+Last modified: Tue Nov 10 02:15:26 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_FREE_HANDS.rst b/doc/sphinx/props/P_FREE_HANDS.rst
new file mode 100644
index 0000000..b05f5ed
--- /dev/null
+++ b/doc/sphinx/props/P_FREE_HANDS.rst
@@ -0,0 +1,40 @@
+P_FREE_HANDS
+============
+
+NAME
+----
+::
+
+    P_FREE_HANDS                  "free_hands"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    Anzahl der freien Haende.
+    Effektiv nur ein die Differenz von P_MAX_HANDS und P_USED_HANDS.
+
+BEMERKUNGEN
+-----------
+::
+
+    Keine echte Property. Die Methode /std/living/combat::_query_free_hands
+    stellt die Daten zusammen. Nicht setzen!
+
+SIEHE AUCH
+----------
+::
+
+    P_HANDS, P_HANDS_USED_BY
+    P_MAX_HANDS, P_USED_HANDS
+    UseHands, FreeHands
+    /std/weapon.c, /std/spellbook.c
+
+1. Okt 2012, Gloinson
+
diff --git a/doc/sphinx/props/P_FRIEND.rst b/doc/sphinx/props/P_FRIEND.rst
new file mode 100644
index 0000000..479dcf9
--- /dev/null
+++ b/doc/sphinx/props/P_FRIEND.rst
@@ -0,0 +1,40 @@
+P_FRIEND
+========
+
+NAME
+----
+::
+
+	P_FRIEND			"friend"
+
+DEFINIERT IN
+------------
+::
+
+	<combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+	Setzt man diese Property in einem NPC auf einen Wert ungleich Null,
+	so wird der NPC bei Zauberspruechen, die auf bestimmte Gruppen
+	wirken, der Gruppe der Spieler und nicht der Gruppe der NPCs
+	zugeordnet. Ausserdem wird der NPC bei einem "toete alle" nicht mit
+	angegriffen.
+	Wurde der NPC einem Spieler per AssocMember() zugeordnet, so
+	befindet sich der NPC automatisch im jeweiligen Team des Spielers
+	 (moeglichst auch in der selben Kampfreihe), und die Property hat
+	dann automatisch das Spielerobjekt als Wert.
+	Da dieser Wert in diesem Fall natuerlich ungleich Null ist, wird der
+	NPC dann auch der Gruppe der Spieler zugeordnet.
+
+SIEHE AUCH
+----------
+::
+
+	FindGroup(), AssocMember(), P_TEAM_ASSOC_MEMBERS, /std/living/team.c
+
+
+Last modified: Tue Dec 29 17:02:55 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_FROG.rst b/doc/sphinx/props/P_FROG.rst
new file mode 100644
index 0000000..e639e8e
--- /dev/null
+++ b/doc/sphinx/props/P_FROG.rst
@@ -0,0 +1,21 @@
+P_FROG
+======
+
+NAME
+----
+::
+
+    P_FROG                        "frog"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gesetzt, wenn der Spieler ein Frosch ist.
+
diff --git a/doc/sphinx/props/P_FUEL.rst b/doc/sphinx/props/P_FUEL.rst
new file mode 100644
index 0000000..8cd22e7
--- /dev/null
+++ b/doc/sphinx/props/P_FUEL.rst
@@ -0,0 +1,48 @@
+P_FUEL
+======
+
+NAME
+----
+::
+
+    P_FUEL                        "fuel"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Numerischer Wert fuer die Zeitdauer, die die Lichtquelle noch
+     leuchten kann. Standardmaessig ist der Wert auf 20 gesetzt.
+
+     Setzt man die Property auf einen Wert, der groesser ist als der vorige
+     Maximalwert, wird dieser auf den neuen Wert erhoeht. Aendert man den
+     Brennstoffvorrat der Lichtquelle hingegen mittels AddFuel(), so wird
+     der Wert von P_FUEL ueber den Maximalwert hinaus erhoeht.
+
+HINWEIS
+-------
+::
+
+     Fuer Aenderungen an der Property kann auch die Funktion AddFuel()
+     verwendet werden. 
+
+SIEHE AUCH
+----------
+::
+
+     Basisklassen: /std/lightsource.c
+     Properties:   P_LIGHTDESC, P_DO_DESTRUCT, P_LIGHT
+     Methoden:     AddFuel(L)
+
+LETZTE AENDERUNG
+----------------
+::
+
+    22. Dez. 2015, Arathorn
+
diff --git a/doc/sphinx/props/P_FUNC_MSG.rst b/doc/sphinx/props/P_FUNC_MSG.rst
new file mode 100644
index 0000000..2acab57
--- /dev/null
+++ b/doc/sphinx/props/P_FUNC_MSG.rst
@@ -0,0 +1,40 @@
+P_FUNC_MSG
+==========
+
+NAME
+----
+::
+
+    P_FUNC_MSG                    "func_msg"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Liste mit Funktionen, die zufaellig im Raum aufgerufen werden.
+
+     Hier ist nur eine zur rufende lokale Methode als String oder eine
+     Sammlung davon als Stringarray gespeichert.
+
+ANMERKUNGEN
+-----------
+::
+
+     Bitte AddRoomMessage() zum Hinzufuegen/Ueberschreiben benutzen!
+
+SIEHE AUCH
+----------
+::
+
+     LFuns:    AddRoomMessage()
+     Verwandt: tell_room(), ReceiveMsg()
+     Props:    P_ROOM_MSG, P_MSG_PROB
+
+2.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_FW_ALWAYS_READABLE.rst b/doc/sphinx/props/P_FW_ALWAYS_READABLE.rst
new file mode 100644
index 0000000..5fa135a
--- /dev/null
+++ b/doc/sphinx/props/P_FW_ALWAYS_READABLE.rst
@@ -0,0 +1,21 @@
+P_FW_ALWAYS_READABLE
+====================
+
+NAME
+----
+::
+
+    P_FW_ALWAYS_READABLE          "fw_always_readable"          
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_FW_UNDERSTAND.rst b/doc/sphinx/props/P_FW_UNDERSTAND.rst
new file mode 100644
index 0000000..d2badf1
--- /dev/null
+++ b/doc/sphinx/props/P_FW_UNDERSTAND.rst
@@ -0,0 +1,21 @@
+P_FW_UNDERSTAND
+===============
+
+NAME
+----
+::
+
+    P_FW_UNDERSTAND               "fw_understand"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_GENDER.rst b/doc/sphinx/props/P_GENDER.rst
new file mode 100644
index 0000000..f1a9aaa
--- /dev/null
+++ b/doc/sphinx/props/P_GENDER.rst
@@ -0,0 +1,22 @@
+P_GENDER
+========
+
+NAME
+----
+::
+
+    P_GENDER                      "gender"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/language.h
+
+BESCHREIBUNG
+------------
+::
+
+     Grammatikalisches Geschlecht des Objektes:
+     (Definiert in language.h) MALE, FEMALE oder NEUTER
+
diff --git a/doc/sphinx/props/P_GHOST.rst b/doc/sphinx/props/P_GHOST.rst
new file mode 100644
index 0000000..1bc4544
--- /dev/null
+++ b/doc/sphinx/props/P_GHOST.rst
@@ -0,0 +1,21 @@
+P_GHOST
+=======
+
+NAME
+----
+::
+
+    P_GHOST                       "ghost"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gesetzt, wenn der Spieler tot ist.
+
diff --git a/doc/sphinx/props/P_GIVE_MSG.rst b/doc/sphinx/props/P_GIVE_MSG.rst
new file mode 100644
index 0000000..497800f
--- /dev/null
+++ b/doc/sphinx/props/P_GIVE_MSG.rst
@@ -0,0 +1,83 @@
+P_GIVE_MSG
+==========
+
+NAME
+----
+::
+
+     P_GIVE_MSG				"give_message"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/put_and_get.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mit P_GIVE_MSG kann man die Meldung, die man beim Uebergeben eines
+     Objektes bekommt, modifizieren.
+
+     Folgende Werte sind moeglich:
+
+     o 0
+       Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
+
+     o NO_PNG_MSG	== -1
+       Es wird keinerlei Meldung ausgegeben
+
+     o Ein Array aus Strings
+       Der erste String wird an den Spieler ausgegeben, der zweite
+       (optionale) an den Raum, der dritte (ebenfalls optionale) an den
+       Empfaenger.
+
+       Die Strings werden durch die Funktion replace_personal() geparst.
+	Objekt1 - Spieler
+        Objekt2 - das Objekt, das uebergeben wird
+	Objekt3 - Empfaenger
+
+       Wird der zweite String nicht angegeben, erfolgt keine Meldung an den
+       Raum. Beim Fehlen des dritten gibt es keine Meldung an den Empfaenger.
+
+BEISPIEL
+--------
+::
+
+     void create() {
+      ...
+      SetProp( P_SHORT, "Etwas Sand" );
+      SetProp( P_LONG, break_string(
+	"Ein wenig magischer Sand. Sehr feinkruemelig.",78 ));
+
+      SetProp( P_NAME, "Sand" );
+      AddId( ({"sand"}) );
+      SetProp( P_GENDER, MALE );
+
+      SetProp( P_GIVE_MSG, ({
+       "Du laesst @WEN2 in @WESSEN3 Haende rieseln.",
+       "@WER1 laesst @WENU2 in @WESSEN3 Haende rieseln.",
+       "@WER1 laesst @WENU2 in deine Haende rieseln."}));
+       ...
+      }
+
+     Das ganze fuehrt bei Ugars "gib sand an peter" zu folgenden
+     Meldungen:
+
+     Ugar: "Du laesst den Sand in Peters Haende rieseln."
+     Raum: "Ugar laesst Sand in Peters Haende rieseln."
+     Peter: "Ugar laesst Sand in deine Haende rieseln."
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_DROP_MSG, P_PUT_MSG, P_PICK_MSG, P_SHOW_MSG
+     Fehler:     P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
+                 P_NOINSERT_MSG, P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     Sonstiges:  replace_personal(E), give(L), give_objects(L),
+		 give_notify(L), /std/living/put_and_get.c
+
+14. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_GLOBAL_SKILLPROPS.rst b/doc/sphinx/props/P_GLOBAL_SKILLPROPS.rst
new file mode 100644
index 0000000..88f92c9
--- /dev/null
+++ b/doc/sphinx/props/P_GLOBAL_SKILLPROPS.rst
@@ -0,0 +1,46 @@
+P_GLOBAL_SKILLPROPS
+===================
+
+NAME
+----
+::
+
+    P_GLOBAL_SKILLPROPS        "sm_global"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Gilden- und Spellbookproperty enthaelt Eigenschaften, die
+    alle Spells eines Spellbooks bzw. alle Skills und Spells einer Gilde
+    haben sollen.
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_GLOBAL_SKILLPROPS,
+      ([SI_SKILLRESTR_USE:     ([SR_FUN: #'spellTest]),
+        OFFSET(SI_SKILLLEARN): #'learnOffset,
+        OFFSET(SI_SPELLCOST):  #'costOffset,
+        FACTOR(SI_SPELLCOST):  #'costFactor]));
+
+SIEHE AUCH
+----------
+::
+
+    GObj Verwalten:   LearnSkill, LearnSpell, InitialSkillAbility
+    * Properties:     P_GUILD_SKILLS
+    Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
+    * Verwalten:      AddSpell, QuerySpell
+    * Properties:     P_SB_SPELLS
+    Skills:           P_NEWSKILLS, spruchermuedung, skill_info_liste
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_GUARD.rst b/doc/sphinx/props/P_GUARD.rst
new file mode 100644
index 0000000..1564a69
--- /dev/null
+++ b/doc/sphinx/props/P_GUARD.rst
@@ -0,0 +1,70 @@
+P_GUARD
+=======
+
+NAME
+----
+::
+
+     P_GUARD				"guard"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/guard.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property gibt an, ob ein NPC aus einem Raum entfernt werden darf
+     oder nicht. Abgefragt werden muss dies von den Items oder Spells, die
+     den NPC zu einer Bewegung zwingen wollen. Es wird nicht automatisch
+     darauf geachtet!
+
+     Entscheidend hierbei ist ein in der Property enthaltene (ganzzahliger)
+     Zahlenwert zwischen 0 und 100, der hierbei den Grad der
+     'Bewachungsstaerke' eines NPCs angibt. Bei 0 laesst sich das Lebewesen
+     immer zu einer Bewegung ueberreden, bei 100 ueberhaupt nicht. Dazwischen
+     gibt es die Wahrscheinlichkeit dafuer an.
+
+BEMERKUNGEN
+-----------
+::
+
+     - alle von /std/npc abgeleiteten NPCs haben standardmaessig P_GUARD
+       auf 100 gesetzt, sind also nicht fortfuehrbar
+     - bei der Erzeugung von NPCs mit P_GUARD < 100 AddItem() mit dem
+       Parameter REFRESH_MOVE_HOME verwenden, damit sie bei einem Raumreset
+       gegebenenfalls an ihren Ausgangsort zurueckkehren. 
+     - gildenspezifische weitere Abfragen auf Level oAe bitte bei Gilden-
+       magiern erfragen
+
+BEISPIELE
+---------
+::
+
+     // ein Test
+     if(random(100)<=liv->QueryProp(P_GUARD))
+      cannotMoveNPC(); // NPC darf nicht bewegt werden!
+     else
+      moveNPC();       // NPC darf bewegt werden
+
+     // ein wegfuehrbarer NPC
+     void create() {
+      ::create();
+      ...
+      SetProp(P_GUARD,50);
+      ...
+     }
+     // mit 50% Wahrscheinlichkeit (pro Versuch) laesst sich der NPC nun
+     // fortfuehren
+
+SIEHE AUCH
+----------
+::
+
+     AddItem()
+
+13.April 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_GUILD.rst b/doc/sphinx/props/P_GUILD.rst
new file mode 100644
index 0000000..deb56f1
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD.rst
@@ -0,0 +1,40 @@
+P_GUILD
+=======
+
+NAME
+----
+::
+
+     P_GUILD				"guild"                       
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt den Namen der Gilde, welcher das Lebewesen
+     angehoert. Der Name der Gilde ist hierbei kleingeschrieben als String
+     definiert.
+
+BEMERKUNGEN
+-----------
+::
+
+     Bei Spielern ist der Wert dieser Property niemals Null, denn sie
+     gehoeren standardmaessig der in P_DEFAULT_GUILD stehenden Gilde an.
+     Ueber die gesetzte P_GUILD werden auch aktive Skills ermittelt.
+
+SIEHE AUCH
+----------
+::
+
+     P_DEFAULT_GUILD, P_VISIBLE_GUILD
+     P_GUILD_TITLE, P_SUBGUILD_TITLE
+
+26. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_GUILD_DEACTIVATE_SKILLS.rst b/doc/sphinx/props/P_GUILD_DEACTIVATE_SKILLS.rst
new file mode 100644
index 0000000..58b6d12
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_DEACTIVATE_SKILLS.rst
@@ -0,0 +1,52 @@
+P_GUILD_DEACTIVATE_SKILLS
+=========================
+
+PROPERTY
+--------
+::
+
+  P_GUILD_DEACTIVATE_SKILLS     "guild_deactivate_skills"
+
+DEFINIERT IN: 
+
+  new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+  Diese Property erlaubt es, Gildenmitgliedern die benutzung von ANY-
+  Skills zu untersagen. Dies sind einerseits die allgemeinen Waffenskills,
+  andererseits koennte das auch der entgifte-Spruch der Duesterwald -
+  Quest sein.
+
+  Wert dieser Property ist ein Mapping, das als Keys die einzelnen
+  Skills und als Wert 1 enthaelt, wenn ein Skill deaktiviert
+  werden soll und 0, falls nicht.
+
+  Diese Property wird nur bei einem Neuerzeugen des Spielers neu 
+  ausgelesen, da es sonst zuviel Rechenzeit kostet.
+
+BEISPIEL
+--------
+::
+
+  Jede Gilde, die keine Waffenskills benutzen soll (oder selbst welche hat)
+  enthaelt folgenden Befehl:
+
+    SetProp(P_GUILD_DEACTIVATE_SKILLS,
+    ([FIGHT(WT_SWORD):1,
+    FIGHT(WT_AXE):1,
+    FIGHT(WT_CLUB):1,
+    FIGHT(WT_SPEAR):1,
+    FIGHT(WT_KNIFE):1,
+    FIGHT(WT_WHIP):1]));
+
+    
+
+LETZTE AENDERUNG 
+
+2003-01-30, 1415, Humni
+------------------------------------------
+::
+
diff --git a/doc/sphinx/props/P_GUILD_DEFAULT_SPELLBOOK.rst b/doc/sphinx/props/P_GUILD_DEFAULT_SPELLBOOK.rst
new file mode 100644
index 0000000..8b95f62
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_DEFAULT_SPELLBOOK.rst
@@ -0,0 +1,45 @@
+P_GUILD_DEFAULT_SPELLBOOK
+=========================
+
+NAME
+----
+::
+
+	P_GUILD_DEFAULT_SPELLBOOK	"guild_sb"                    
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Gildenproperty enthaelt den Namen des Spellbooks, welches
+	standardmaessig von der Gilde verwendet wird.
+
+BEMERKUNGEN
+-----------
+::
+
+	Bei Spells kann sie mit SI_SPELLBOOK ueberschrieben werden.
+
+BEISPIELE
+---------
+::
+
+	Bei Zauberern waere folgendes denkbar:
+	  SetProp(P_GUILD_DEFAULT_SPELLBOOK,"magie_sp");
+	Das Spellbook ist hierbei unter "/spellbooks/magie_sp.c" zu finden.
+
+SIEHE AUCH
+----------
+::
+
+	P_GUILD
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_GUILD_FEMALE_TITLES.rst b/doc/sphinx/props/P_GUILD_FEMALE_TITLES.rst
new file mode 100644
index 0000000..849677e
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_FEMALE_TITLES.rst
@@ -0,0 +1,43 @@
+P_GUILD_FEMALE_TITLES
+=====================
+
+NAME
+----
+::
+
+	P_GUILD_FEMALE_TITLES		"guild_female_titles"         
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Gildenproperty enthaelt die Stufenbezeichnungen fuer
+	weibliche Gildenmitglieder. Als Schluessel dienen hierbei die
+	Gildenstufen und die entsprechenden Eintraege sind dann die zur
+	Stufe gehoerigen Gildentitel.
+
+BEISPIELE
+---------
+::
+
+	Eine Programmierergilde koennte folgende Stufenbezeichnungen
+	beinhalten:
+	  SetProp(P_GUILD_FEMALE_TITLES,([1:"die Anfaengerin",
+	                                  2:"die Fortgeschrittene",
+	                                  3:"die Professionelle ;)"]));
+
+SIEHE AUCH
+----------
+::
+
+	P_GENDER, P_GUILD_LEVEL, P_GUILD_TITLE, P_GUILD_MALE_TITLES
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_GUILD_LEVEL.rst b/doc/sphinx/props/P_GUILD_LEVEL.rst
new file mode 100644
index 0000000..344cebb
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_LEVEL.rst
@@ -0,0 +1,42 @@
+P_GUILD_LEVEL
+=============
+
+NAME
+----
+::
+
+	P_GUILD_LEVEL			"guild_level"                 
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt die Gildenstufe des Lebewesens, welche nicht
+	unbedingt seiner Spielerstufe entspricht.
+
+BEMERKUNGEN
+-----------
+::
+
+	Bei manchen Gilden entspricht die Gildenstufe standardmaessig der
+	Spielerstufe (Abenteurer, Katzenkrieger). In der Property selbst
+	wird eigentlich ein Mapping eingetragen, welches die Gildennamen als
+	Schluessel und die dazugehoerige Gildenstufe als Eintrag enthaelt.
+	Bei der Abfrage der Property wird jedoch die Gilde beruecksichtigt
+	und die aktuelle Gildenstufe zurueckgeliefert.
+
+SIEHE AUCH
+----------
+::
+
+	P_GUILD, P_GUILD_TITLE, P_GUILD_MALE_TITLES, P_GUILD_FEMALE_TITLES
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_GUILD_LEVELS.rst b/doc/sphinx/props/P_GUILD_LEVELS.rst
new file mode 100644
index 0000000..9b372aa
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_LEVELS.rst
@@ -0,0 +1,57 @@
+P_GUILD_LEVELS
+==============
+
+NAME
+----
+::
+
+	P_GUILD_LEVELS			"guild_levels"                
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Gildenproperty enthaelt ein Mapping mit den
+	Stufenbeschraenkungen fuer die jeweiligen Gildenstufen. Als
+	Schluessel dient der jeweilige Gildenlevel und die entsprechenden
+	Eintraege sind wiederum Mappings, in welchen die Beschraenkungen
+	angegeben sind.
+
+BEMERKUNGEN
+-----------
+::
+
+	Die Beschraenkungen fuer Level 1 sollten auch fuer die
+	Eintrittsbeschraenkungen der Gilde gelten. Letztere kann man in der
+	Property P_GUILD_RESTRICTIONS angeben.
+
+BEISPIELE
+---------
+::
+
+	Das folgende Beispiel zeigt ein paar moegliche Abfragen:
+	  string check(object pl);
+	  SetProp(P_GUILD_LEVELS,([1:([P_LEVEL:3,P_QP:100,SR_FUN:#'check]),
+	                           2:([A_INT:10,P_LEVEL:25]),
+	                           3:([A_INT:20,P_LEVEL:50])]));
+	  string check(object pl)
+	  { if(pl->QueryProp(P_MALE))
+	      return 0;
+	    return "Fuer Frauen ist das nichts!\n";
+	  }
+
+SIEHE AUCH
+----------
+::
+
+	P_GUILD_LEVEL, P_GUILD_RESTRICTIONS, /std/restriction_checker.c
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_GUILD_MALE_TITLES.rst b/doc/sphinx/props/P_GUILD_MALE_TITLES.rst
new file mode 100644
index 0000000..993527b
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_MALE_TITLES.rst
@@ -0,0 +1,43 @@
+P_GUILD_MALE_TITLES
+===================
+
+NAME
+----
+::
+
+	P_GUILD_MALE_TITLES		"guild_male_titles"           
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Gildenproperty enthaelt die Stufenbezeichnungen fuer
+	maennliche Gildenmitglieder. Als Schluessel dienen hierbei die
+	Gildenstufen und die entsprechenden Eintraege sind dann die zur
+	Stufe gehoerigen Gildentitel.
+
+BEISPIELE
+---------
+::
+
+	Eine Programmierergilde koennte folgende Stufenbezeichnungen
+	beinhalten:
+	  SetProp(P_GUILD_MALE_TITLES,([1:"der Anfaenger",
+	                                2:"der Fortgeschrittene",
+	                                3:"der Profi"]));
+
+SIEHE AUCH
+----------
+::
+
+	P_GENDER, P_GILD_LEVEL, P_GUILD_TITLE, P_GUILD_FEMALE_TITLES
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_GUILD_PREPAREBLOCK.rst b/doc/sphinx/props/P_GUILD_PREPAREBLOCK.rst
new file mode 100644
index 0000000..8aeb418
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_PREPAREBLOCK.rst
@@ -0,0 +1,61 @@
+P_GUILD_PREPAREBLOCK
+====================
+
+P_GUILD_PREPAREBLOCK (int)
+--------------------------
+::
+
+NAME
+----
+::
+
+  P_GUILD_PREPAREBLOCK                           "guild_prepareblock" 
+
+DEFINIERT IN
+------------
+::
+
+  /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+  Diese Property enthaelt die Information, ob das Lebewesen in
+  der Konzentrationsphase eines Spells weiterkaempft oder ob
+  die Angriffe derweil ausgesetzt werden.
+
+BEMERKUNGEN
+-----------
+::
+
+  In der Property selbst wird eigentlich ein Mapping eingetragen,
+  welches die Gildennamen als Schluessel und das dazugehoerige
+  Block-Flag als Eintrag enthaelt. Bei der Abfrage der Property wird
+  jedoch die Gilde beruecksichtigt und das aktuelle Flag
+  zurueckgeliefert.
+  Dementsprechend das diese Prop nicht mit Set() manipuliert werden, 
+  bitte ausschliessliche SetProp() verwenden.
+
+BEISPIELE
+---------
+::
+
+  Die Property sollte natuerlich nur von der Gilde gesetzt werden
+  und auch nur bei Gildenmitgliedern
+
+  if ( IsGuildMember(pl) )
+    pl->SetProp(P_GUILD_PREPAREBLOCK,1);
+
+  Resultat: Kein Ausfuehren von Attack(), wenn pl sich auf einen
+  Zauberspruch konzentriert.
+
+SIEHE AUCH
+----------
+::
+
+  P_PREPARED_SPELL
+
+
+18.03.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_GUILD_RATING.rst b/doc/sphinx/props/P_GUILD_RATING.rst
new file mode 100644
index 0000000..b752e00
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_RATING.rst
@@ -0,0 +1,41 @@
+P_GUILD_RATING
+==============
+
+NAME
+----
+::
+
+	P_GUILD_RATING			"guild_rating"                
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property wird die Einstufung des Spielers innerhalb
+	seiner Gilde festgelegt. Der dafuer zu ermittelnde Wert muss in
+	einem Bereich von 0 bis 10000 liegen. Wie sich die Einstufung
+	zusammensetzt, bleibt der jeweiligen Gilde ueberlassen.
+
+BEMERKUNGEN
+-----------
+::
+
+	Der Wert muss von der Gilde ermittelt werden! Meist setzt er sich
+	aus den Faehigkeiten des Mitglieds zusammen und mitunter fliessen
+	auch Gildenquests oder aehnliches mit ein.
+
+SIEHE AUCH
+----------
+::
+
+    P_NEWSKILLS, GuildRating
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_GUILD_RESTRICTIONS.rst b/doc/sphinx/props/P_GUILD_RESTRICTIONS.rst
new file mode 100644
index 0000000..31632a6
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_RESTRICTIONS.rst
@@ -0,0 +1,59 @@
+P_GUILD_RESTRICTIONS
+====================
+
+NAME
+----
+::
+
+    P_GUILD_RESTRICTIONS        "guild_rest"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Gildenproperty enthaelt ein Mapping mit den
+    Eintrittsbeschraenkungen fuer die jeweilige Gilde.
+
+BEMERKUNGEN
+-----------
+::
+
+    Im allgemeinen sollte das Mapping mit den Eintrittsbeschraenkungen
+    mit den Beschraenkungen fuer Level 1 im Mapping von P_GUILD_LEVELS
+    uebereinstimmen.
+
+BEISPIELE
+---------
+::
+
+    Ein paar moegliche Abfragen waeren folgende:
+    string check(object pl);
+
+    SetProp(P_GUILD_RESTRICTIONS,
+            ([P_LEVEL:3,
+              P_QP:100,
+              SR_FUN:#'check]));
+
+    string check(object pl) {
+      if(pl->QueryProp(P_MALE))
+        return 0;
+      return "Fuer Frauen ist das nichts!\n";
+    }
+
+SIEHE AUCH
+----------
+::
+
+    Gildenfkt.:
+    * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
+    * Sonstiges:    P_GUILD_LEVELS
+    Sonstiges:      /std/restriction_checker.c
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_GUILD_SKILLS.rst b/doc/sphinx/props/P_GUILD_SKILLS.rst
new file mode 100644
index 0000000..13e1ecb
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_SKILLS.rst
@@ -0,0 +1,42 @@
+P_GUILD_SKILLS
+==============
+
+NAME
+----
+::
+
+    P_GUILD_SKILLS            "guild_skills"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Gildenproperty enthaelt ein Mapping mit allen Skills und
+    Spells der Gilde.
+
+BEMERKUNGEN
+-----------
+::
+
+    Man sollte diese Property sollte nicht per Hand veraendern, sondern
+    die Funktionen AddSkill() bzw. AddSpell() nutzen.
+
+SIEHE AUCH
+----------
+::
+
+    GObj Verwalten:   LearnSkill, LearnSpell, InitialSkillAbility
+    * Sonstiges:      GuildRating
+    Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
+    * Verwalten:      AddSpell, QuerySpell
+    * Properties:     P_SB_SPELLS, P_GLOBAL_SKILLPROPS, P_GUILD_RATING
+    Skills:           P_NEWSKILLS, spruchermuedung, skill_info_liste
+
+3. Okt 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_GUILD_TITLE.rst b/doc/sphinx/props/P_GUILD_TITLE.rst
new file mode 100644
index 0000000..415f3f8
--- /dev/null
+++ b/doc/sphinx/props/P_GUILD_TITLE.rst
@@ -0,0 +1,58 @@
+P_GUILD_TITLE
+=============
+
+NAME
+----
+::
+
+     P_GUILD_TITLE			"guild_title"                 
+
+DEFINIERT IN
+------------
+::
+
+     /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt den Gildentitel des Lebewesens, welcher der
+     Gildenstufe des Lebewesens entspricht und jedoch nur angezeigt wird,
+     wenn P_TITLE des Lebewesens gleich Null ist.
+
+BEMERKUNGEN
+-----------
+::
+
+     In der Property selbst wird eigentlich ein Mapping eingetragen, welches
+     die Gildennamen als Schluessel und die dazugehoerigen Gildentitel als
+     Eintrag enthaelt. Bei der Abfrage der Property wird jedoch die Gilde
+     beruecksichtigt und der aktuelle Gildentitel zurueckgeliefert.
+
+BEISPIELE
+---------
+::
+
+	Fuer eine Programmierergilde waere folgendes denkbar:
+	  SetProp(P_GUILD_MALE_TITLES,([1:"der Anfaenger",
+	                                2:"der Fortgeschrittene",
+	                                3:"der Profi"]));
+	  SetProp(P_GUILD_FEMALE_TITLES,([1:"die Anfaengerin",
+	                                  2:"die Fortgeschrittene",
+	                                  3:"die Professionelle"]));
+	Ein weibliches Gildenmitglied mit der dritten Gildenstufe und ohne
+	P_TITLE wuerde dann den Titel "die Professionelle" tragen. Das hat
+	zwar nichts mit Programmierern zu tun, aber wie heisst eigentlich
+	ein weiblicher "Profi"?! :)
+
+SIEHE AUCH
+----------
+::
+
+     P_TITLE, P_GUILD, P_GUILD_LEVEL,
+     P_GUILD_MALE_TITLES, P_GUILD_FEMALE_TITLES,
+     P_SUBGUILD_TITLE
+
+26. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_HANDS.rst b/doc/sphinx/props/P_HANDS.rst
new file mode 100644
index 0000000..c9f739d
--- /dev/null
+++ b/doc/sphinx/props/P_HANDS.rst
@@ -0,0 +1,78 @@
+P_HANDS
+=======
+
+NAME
+----
+::
+
+     P_HANDS                    "hands"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt ein dreielementiges Array mit
+     den folgenden Eintraegen:
+     1. Element: String mit der Meldung, wenn ohne Waffen angegriffen
+                 wird.
+     2. Element: Waffenklasse, wenn ohne Waffen angegriffen wird.
+     3. Element: Array mit Schadensarten (frueher auch: Schadensart)
+
+     eim Setzen dieser Property wird auch P_TOTAL_WC mit veraendert,
+     wenn das Lebewesen keine Waffe gezueckt hat. Steckt das Lebewesen
+     eine gezueckte Waffe weg, so wird ebenfalls P_TOTAL_WC mit der
+     Waffenklasse aus P_HANDS aktualisiert. Zueckt das Lebewesen eine
+     Waffe, so wird P_TOTAL_WC mit der Waffenklasse der Waffe (P_WC)
+     ueberschrieben. Die Property P_TOTAL_WC enthaelt somit immer die
+     aktuelle Angriffsstaerke des Lebewesen.
+
+BEMERKUNGEN
+-----------
+::
+
+     In alten Objekten kann es vorkommen, dass das dritte Element (Angabe des
+     Schadenstyps) fehlt. Dies ist eine Altlast, die Angabe des Schadenstypes
+     ist NICHT optional.)
+
+BEISPIEL
+--------
+::
+
+     Ein starker Tausendfuessler mit Schlagschaden:
+
+       SetProp(P_HANDS,({" mit tausend kleinen Fuesschen",1000, 
+                         ({DT_BLUDGEON}) }));
+
+
+     Ein Saeurededaemon:
+       SetProp(P_HANDS,
+         ({
+           " mit saeuretriefenden Klauen",
+           250,
+           ({DT_RIP, DT_ACID})
+         })
+       );
+
+     Hier wurden gleich zwei Schadensarten angegeben, also wird
+     Mischschaden verursacht. Man sollte es jedoch nicht zu sehr
+     uebertreiben! Mehr als zwei oder drei gleichzeitig verwendete
+     Schadensarten lassen sich kaum mehr begruenden.
+
+SIEHE AUCH
+----------
+::
+
+     P_HANDS_USED_BY
+     P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
+     UseHands, FreeHands
+     P_TOTAL_WC, P_WC
+     /std/living/combat.c, /std/weapon/combat.c, /sys/combat.h
+
+22.02.2014 Zesstra
+
diff --git a/doc/sphinx/props/P_HANDS_USED_BY.rst b/doc/sphinx/props/P_HANDS_USED_BY.rst
new file mode 100644
index 0000000..7a2c310
--- /dev/null
+++ b/doc/sphinx/props/P_HANDS_USED_BY.rst
@@ -0,0 +1,39 @@
+P_HANDS_USED_BY
+===============
+
+NAME
+----
+::
+
+     P_HANDS_USED_BY           "hands_used_by"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Enthaelt eine Liste mit den Objekten, die derzeit die Haende
+     des Livings belegen. Dabei koennen Objekte mehrmals auftauchen,
+     je nachdem wie viele Haende sie belegen.
+
+BEMERKUNGEN
+-----------
+::
+
+     Darf nur ueber UseHands() und FreeHands() manipuliert werden.
+
+SIEHE AUCH
+----------
+::
+
+     P_HANDS
+     P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
+     UseHands, FreeHands
+
+1.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/props/P_HARBOUR.rst b/doc/sphinx/props/P_HARBOUR.rst
new file mode 100644
index 0000000..a8a7515
--- /dev/null
+++ b/doc/sphinx/props/P_HARBOUR.rst
@@ -0,0 +1,96 @@
+P_HARBOUR
+=========
+
+NAME
+----
+::
+
+    P_HARBOUR                                  "harbour_name"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+    Array mit eindeutiger Bezeichnung des 'Hafens'
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Property wird in Raeumen gesetzt, die als Anleger fuer Transporter
+    dienen sollen. Sie enthaelt ein Array aus zwei Elementen, einem String
+    und einem String-Array, zum Beispiel:
+
+    ({ "zur Sonneninsel", ({"sonneninsel"}) }) oder 
+    ({ "nach Titiwu", ({"titiwu"}) })
+
+    Damit bekommt der Spieler bei einer Abfrage seiner Reiseroute mittels
+    "reise route" eine Ausgabe wie 
+      'Du reist mit dem Floss nach Titiwu' oder
+      'Du reist mit dem Wal zur Sonneninsel'.
+
+    Das zweite Element der Property enthaelt eine Liste der IDs, mit denen
+    sich der Hafen mit dem Befehl "reise nach <ID>" ansprechen laesst. Im
+    Beispiel oben wuerde also "reise nach sonneninsel" und 
+    "reise nach titiwu" akzeptiert werden. Der erste Eintrag in dieser ID-
+    Liste wird in der Ausgabe des Befehls "reise route" verwendet, sollte
+    also den Anlegeort korrekt bezeichnen und nicht z.B. eine Abkuerzung
+    enthalten.
+    Es bietet sich an, bei bestimmten, deklinierbaren Bezeichnungen alle
+    Varianten einzutragen, z.B. "verlorenes land" und zusaetzlich
+    "verlorene land" und "verlorenen land", damit alle Varianten von 
+    "reise nach ..." funktionieren.
+
+    Ist in einem Hafen diese Property nicht gesetzt, so bekommt der 
+    Spieler keinerlei Hinweis darauf, wohin ihn ein bestimmter Trans-
+    porter befoerdert. 
+    Stattdessen erhaelt er die Bezeichnung 'unbekannt'.
+
+HINWEISE
+--------
+::
+
+    Wird der zweite Parameter in dieser Property, d.h. die Liste der 
+    Anleger-IDs, nicht korrekt gesetzt, kann das dazu fuehren, dass Spieler
+    den hier anlegenden Transporter nicht benutzen koennen, weil es
+    keine sinnvolle Syntax gibt, um den gewuenschten Zielhafen zu finden.
+
+    Zu achten ist auch darauf, das der erste Eintrag unveraendert in einer 
+    Meldung an den Spieler ausgegeben wird, d.h. Gross-und Kleinschreibung
+    sollte korrekt sein.
+
+HISTORIE
+--------
+::
+
+    Frueher war der zweite Eintrag in dieser Property ein einzelner String.
+    Es existiert eine SetMethode auf dieser Property, die solche Daten in
+    altem Code auf die neue Datenstruktur umbiegt. Dies fuehrt dazu, dass
+    bei solchen Objekten die im geladenen Raum enthaltenen Daten nicht mit
+    den Daten im File uebereinstimmen. Dies moege aber bitte niemand 
+    zum Anlass nehmen, in neuem Code veraltete Daten in die Property zu 
+    schreiben!
+
+    
+
+SIEHE AUCH
+----------
+::
+
+  Properties:     P_NO_TRAVELING, P_TRAVEL_INFO
+  Funktionen:     AddRoute(L)
+  Spielerbefehle: reise
+  weitere Doku:   /d/inseln/schiffe/HowTo
+
+LETZTE AENDERUNG
+----------------
+::
+
+2015-Jan-18, Arathorn
+
diff --git a/doc/sphinx/props/P_HAUS_ERLAUBT.rst b/doc/sphinx/props/P_HAUS_ERLAUBT.rst
new file mode 100644
index 0000000..6e458e9
--- /dev/null
+++ b/doc/sphinx/props/P_HAUS_ERLAUBT.rst
@@ -0,0 +1,47 @@
+P_HAUS_ERLAUBT
+==============
+
+NAME
+----
+::
+
+    P_HAUS_ERLAUBT                "haus_erlaubt"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Hier darf ein Seherhaus abgestellt werden
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Property sollte nicht per default in Raeumen auf einen Wert > 0
+     gesetzt werden um einem Wildwuchs an Seherhaus(-ruinen) vorzubeugen.
+     Auch sei darauf geachtet, dass in Raeumen die P_INDOORS auf einen 
+     Wert > 0 haben, per default nicht gebaut werden kann.     
+     Hier lieber die Property per Hand auf 1 setzen und nach dem Aufstellen
+     des Hauses wieder loeschen.
+
+      
+
+     xcall $h->SetProp(P_HAUS_ERLAUBT,1);
+
+     Angemerkt sei noch, dass der Magier dem der Raum gehoert ueber Hausbau
+     entscheidet und nicht der Regionsmagier. In jedem Fall Ruecksprache 
+     halten falls der entsprechende Magier zumindest ab und an anwesend sein
+     sollte.
+
+     Unter /doc/beispiele/misc liegt ein File, in dem dokumentiert ist,
+     wie nach Aenderungen am Seherhaus zu verfahren ist.
+
+
+Last modified: Fri Nov 26 15:41:47 1999 by Tilly
+
diff --git a/doc/sphinx/props/P_HB.rst b/doc/sphinx/props/P_HB.rst
new file mode 100644
index 0000000..2888fcc
--- /dev/null
+++ b/doc/sphinx/props/P_HB.rst
@@ -0,0 +1,22 @@
+P_HB
+====
+
+NAME
+----
+::
+
+    P_HB                          "hb"                          
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property wird gesetzt, wenn das Monster immer einen
+     heart_beat haben soll. (VORSICHT, nur wenn es WIRKLICH sein muss!)
+
diff --git a/doc/sphinx/props/P_HEAL.rst b/doc/sphinx/props/P_HEAL.rst
new file mode 100644
index 0000000..df6ed73
--- /dev/null
+++ b/doc/sphinx/props/P_HEAL.rst
@@ -0,0 +1,50 @@
+P_HEAL
+======
+
+NAME
+----
+::
+
+     P_HEAL                        "heal"                        
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Numerischer Wert, der beim Verzehr einer Leiche zu den Lebenspunkten 
+     desjenigen hinzugezaehlt wird, der die Leiche isst. Der Wert kann auch 
+     negativ sein. Falls die Leiche den maximalen Verfallszustand erreicht 
+     hat, wird dieser Wert automatisch auf -4 gesetzt, sofern nicht schon
+     ein geringerer Wert eingetragen ist.
+
+     Werte unter -4 sind sehr sparsam und nur in begruendeten Einzelfaellen
+     zu setzen. Die Regionsmagier werden auf sinnvolle Wertebereiche in
+     ihrem Zustaendigkeitsbereich achten und ggf. Grenzwerte fuer ihre 
+     Region festlegen.
+
+     Die Gilden koennen P_HEAL abfragen und eigene, grobe Informationstexte
+     ausgeben, die den Spieler ueber den zu erwartenden Effekt beim Essen
+     einer Leiche informieren.
+
+     Positive Werte von P_HEAL sind bei der Heilungsbalance als Heilstelle
+     zu beantragen.
+
+     Fuer nicht allzu harte NPCs sollte P_HEAL auf 0 gesetzt sein. Dieser
+     Wert ist gleichzeitig der Standardwert.
+
+SIEHE AUCH
+----------
+::
+
+     /std/corpse, QueryHealInfo()
+
+     
+
+31.03.2008 Arathorn
+
diff --git a/doc/sphinx/props/P_HELPER_NPC.rst b/doc/sphinx/props/P_HELPER_NPC.rst
new file mode 100644
index 0000000..b144253
--- /dev/null
+++ b/doc/sphinx/props/P_HELPER_NPC.rst
@@ -0,0 +1,50 @@
+P_HELPER_NPC
+============
+
+NAME
+----
+::
+
+     P_HELPER_NPC             "std:helper_npc
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mit dieser Prop laesst sich herausfinden, ob ein NPC einem Spieler hilft
+    bzw. welche NPC einem Spieler helfen.
+    Wird diese Prop in einem NPC abgefragt, enthaelt sie ein Array 
+      ({ spielerobjekt, flags }) oder 0.
+    Wird diese Prop in einem Spieler abgefragt, enthaelt sie ein Mapping
+      ([npcobjekt1: flags1, npc-objekt2: flags2]).
+
+    <flags> ist ein Integer, der eine Reihe von ver-oder-ten Konstanten (s.
+    RegisterHelperNPC) enthalten kann.
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Prop wird automatisch von RegisterHelperNPC() und
+    UnregisterHelperNPC() verwaltet. Bitte aendert sie nicht per Hand.
+
+BEISPIEL
+--------
+::
+
+    s. RegisterHelperNPC().
+
+SIEHE AUCH
+----------
+::
+
+     RegisterHelperNPC(), UnregisterHelperNPC()
+
+10.03.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_HELPER_OBJECTS.rst b/doc/sphinx/props/P_HELPER_OBJECTS.rst
new file mode 100644
index 0000000..3e045b9
--- /dev/null
+++ b/doc/sphinx/props/P_HELPER_OBJECTS.rst
@@ -0,0 +1,41 @@
+P_HELPER_OBJECTS
+================
+
+NAME
+----
+::
+
+     P_HELPER_OBJECTS "lib_p_helper_objects"
+
+DEFINIERT IN
+------------
+::
+
+     <living/helpers.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt eine Liste von Hilfsobjekten, die das Lebewesen,
+     in dem sie gesetzt ist, bei bestimmten Aktivitaeten wie Tauchen oder
+     Fliegen/Segeln unterstuetzt. Die Property enthaelt ein Mapping der Form
+     ([ HELPER_TYPE : ({ Callback-Closures }) ]).
+
+BEMERKUNGEN
+-----------
+::
+
+     Externe Manipulationen an dieser Property bitte unterlassen, zum Ein-
+     und Austragen von Objekten gibt es die unten aufgefuehrten Methoden.
+
+SIEHE AUCH
+----------
+::
+
+     Methoden:    RegisterHelperObject(L), UnregisterHelperObject(L)
+     Properties:  P_AERIAL_HELPERS, P_AQUATIC_HELPERS
+
+
+18.02.2013, Arathorn
+
diff --git a/doc/sphinx/props/P_HIDE_EXITS.rst b/doc/sphinx/props/P_HIDE_EXITS.rst
new file mode 100644
index 0000000..f4733ef
--- /dev/null
+++ b/doc/sphinx/props/P_HIDE_EXITS.rst
@@ -0,0 +1,53 @@
+P_HIDE_EXITS
+============
+
+NAME
+----
+::
+
+     P_HIDE_EXITS                  "hide_exits"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/room/exits.h
+
+BESCHREIBUNG
+------------
+::
+
+     Ist diese Property in einem Raum auf einen Integerwert ungleich 0
+     gesetzt, werden einem Spieler fuer diesen Raum keine Ausgaenge angezeigt.
+     Auch der Text "Keine sichtbaren Ausgaenge." (oder so) kommt nicht.
+     Alternativ kann man auch ein array von strings uebergeben. In diesem
+     Fall werden all die Ausgaenge nicht angezeigt, deren Index in P_EXITS
+     in dem array vorkommt.
+     In diesem Fall wird ggf. der Text "Keine sichtbaren Ausgaenge."
+     ausgegeben.
+
+BEISPIEL
+--------
+::
+
+     AddExit("raus", "/ganz/wo/anders");
+     AddExit("weiter", "/in/der/naehe");
+
+     // KEINE Ausgaenge anzeigen. Noch nicht mal, dass man keine sieht.
+     SetProp(P_HIDE_EXITS, 1);
+
+     // Der Ausgang weiter wird nicht angezeigt.
+     SetProp(P_HIDE_EXITS, ({"weiter"}) );
+
+     // Keinen Ausgang zeigen, aber den Text, dass keiner sichtbar, ausgeben.
+     SetProp(P_HIDE_EXITS, ({"weiter", "raus"}) );
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	P_SHOW_EXITS
+     Sonstiges:		AddExit(), GetExits(), int_long(), int_short()
+
+25. Apr 1996 Highlander
+
diff --git a/doc/sphinx/props/P_HISTMIN.rst b/doc/sphinx/props/P_HISTMIN.rst
new file mode 100644
index 0000000..a432fde
--- /dev/null
+++ b/doc/sphinx/props/P_HISTMIN.rst
@@ -0,0 +1,21 @@
+P_HISTMIN
+=========
+
+NAME
+----
+::
+
+    P_HISTMIN                     "histmin"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Minimale Laenge, die eine Zeile haben muss, um in die History zu kommen
+
diff --git a/doc/sphinx/props/P_HIT_FUNC.rst b/doc/sphinx/props/P_HIT_FUNC.rst
new file mode 100644
index 0000000..314e294
--- /dev/null
+++ b/doc/sphinx/props/P_HIT_FUNC.rst
@@ -0,0 +1,39 @@
+P_HIT_FUNC
+==========
+
+NAME
+----
+::
+
+     P_HIT_FUNC "hit_func"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Falls ein Objekt eine HitFunc() fuer die Waffe definiert, so muss
+     dieses Objekt in dieser Property eingetragen werden.
+
+     Die Auswertung dieser Property erfolgt in QueryDamage().
+
+BEISPIELE
+---------
+::
+
+     Siehe das Beispiel zu HitFunc()
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon.c, HitFunc()
+
+
+Last modified: Sun May 19 15:37:35 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_HOMEPAGE.rst b/doc/sphinx/props/P_HOMEPAGE.rst
new file mode 100644
index 0000000..3caaf03
--- /dev/null
+++ b/doc/sphinx/props/P_HOMEPAGE.rst
@@ -0,0 +1,21 @@
+P_HOMEPAGE
+==========
+
+NAME
+----
+::
+
+    P_HOMEPAGE                    "homepage"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Die Homepage eines Spielers (mit dem Befehl 'url' zu setzen).
+
diff --git a/doc/sphinx/props/P_HP.rst b/doc/sphinx/props/P_HP.rst
new file mode 100644
index 0000000..59d30b5
--- /dev/null
+++ b/doc/sphinx/props/P_HP.rst
@@ -0,0 +1,40 @@
+P_HP
+====
+
+NAME
+----
+::
+
+    P_HP                          "hp"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     - Lebewesen
+       Anzahl der Lebenspunkte des Wesens.
+
+     - Speisen/Kneipen
+       Heilwirkung einer Portion der Speise auf die Lebenspunkte
+       des Konsumenten
+
+SIEHE AUCH
+----------
+::
+
+     Props:		P_MAX_HP
+     Veraenderung:	reduce_hit_points(), restore_hit_points()
+			do_damage(L), Defend(L)
+			buffer_hp()
+     Ueberwachung:	AddHpHook(L)
+     Speisen/Kneipen:   std/pub, wiz/food, consume
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_HP_DELAY.rst b/doc/sphinx/props/P_HP_DELAY.rst
new file mode 100644
index 0000000..444b0a7
--- /dev/null
+++ b/doc/sphinx/props/P_HP_DELAY.rst
@@ -0,0 +1,23 @@
+P_HP_DELAY
+==========
+
+NAME
+----
+::
+
+    P_HP_DELAY                 "hp_delay"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der heart_beats, bis P_HP um einen Punkt regeneriert.
+     Aenderungen dieser Property in Spielern beduerfen der 
+     Genehmigung des EM fuer Balance.
+
diff --git a/doc/sphinx/props/P_HP_HOOKS.rst b/doc/sphinx/props/P_HP_HOOKS.rst
new file mode 100644
index 0000000..ee8232b
--- /dev/null
+++ b/doc/sphinx/props/P_HP_HOOKS.rst
@@ -0,0 +1,38 @@
+P_HP_HOOKS
+==========
+
+NAME
+----
+::
+
+    P_HP_HOOKS                    "hp_hooks"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Welche Objekte sollen bei HP-Aenderungen benachrichtigt werden?
+     Diese Property bitte NICHT manipulieren! Zum Ein- und Austragen stehen
+     hierfuer AddHpHook() und RemoveHpHook() bereit.
+
+BEMERKUNGEN
+-----------
+::
+
+    Das neuere Hooksystem (s. Manpage std/hooks) stellt ebenfalls Hooks zur
+    Ueberwachung von P_HP bereit.
+
+SIEHE AUCH
+----------
+::
+
+    AddHpHook(), RemoveHpHook(),
+    NotifyHpChange()
+    std/hooks
+
diff --git a/doc/sphinx/props/P_HUNTTIME.rst b/doc/sphinx/props/P_HUNTTIME.rst
new file mode 100644
index 0000000..6b52780
--- /dev/null
+++ b/doc/sphinx/props/P_HUNTTIME.rst
@@ -0,0 +1,59 @@
+P_HUNTTIME
+==========
+
+P_HUNTTIME (int)
+----------------
+::
+
+NAME
+----
+::
+
+     P_HUNTTIME					"p_lib_hunttime"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mit dieser Property laesst sich festlegen, wie lange ein Monster einen 
+    Gegner verfolgt (also automatisch angreift), nachdem dieser geflohen ist.
+    Die Angabe erfolgt in Sekunden.
+    Die Standardzeit ist 600s (300 Heartbeats).
+
+BEMERKUNGEN
+-----------
+::
+
+    1. Wenn der Standardwert akzeptabel ist, bitte die Prop auch nicht setzen.
+    2. Enthaelt die Property keinen Integer oder ist sie <= 0, wird sie 
+       ignoriert und der Standardwert von 600s verwendet.
+    3. Kaempft man mit einem Lebenwesen mit einem groesseren Wert als man 
+       selber und man selber hat das Verfolgen eingestellt, der Gegner aber 
+       nicht, wird dieser beim Reinkommen den Kampf neu starten (und den 
+       ersten Schlag haben).
+
+BEISPIEL
+--------
+::
+
+    Ein NPC soll sich erst eine Stunde nach Flucht des Gegners beruhigen.
+    protected void create() {
+      ...
+      SetProp(P_HUNTTIME, 3600);
+    }
+
+SIEHE AUCH
+----------
+::
+
+     InsertSingleEnemy, InsertEnemy
+     /std/living/combat.c
+
+13.03.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_IDS.rst b/doc/sphinx/props/P_IDS.rst
new file mode 100644
index 0000000..7ec662d
--- /dev/null
+++ b/doc/sphinx/props/P_IDS.rst
@@ -0,0 +1,42 @@
+P_IDS
+=====
+
+NAME
+----
+::
+
+     P_IDS "ids"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property steht ein Array von den Strings, mit denen sich das
+     Objekt ansprechen laesst. Die Verwaltung dieser Property erfolgt ueber
+     die Funktionen AddId() und RemoveId().
+
+     Der Inhalt dieser Property wird von den Funktionen id() und (indirekt)
+     present() ausgewertet.
+
+BEMERKUNGEN
+-----------
+::
+
+     Man sollte an dieser Property nicht "von Hand" herumfummeln, sondern
+     immer die zugehoerigen Funktionen benutzen!
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/description.c, AddId(), RemoveId()
+
+
+Last modified: Sun May 19 20:17:36 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_IGNORE.rst b/doc/sphinx/props/P_IGNORE.rst
new file mode 100644
index 0000000..8eeae75
--- /dev/null
+++ b/doc/sphinx/props/P_IGNORE.rst
@@ -0,0 +1,40 @@
+P_IGNORE
+========
+
+NAME
+----
+::
+
+    P_IGNORE                      "ignore"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+    Array mit Spielern, Kommandos, Aktionen u.ae. die ignoriert werden.
+    In aller Regel sollte die Ignorierepruefung durch Aufruf von TestIgnore()
+    im Spieler erfolgen und nicht selber P_IGNORE durchsucht werden.
+
+BEMERKUNGEN
+-----------
+::
+
+    Die Daten in dieser Property werden intern als Mapping gespeichert, nicht
+    als Array von Strings. Bitte nicht mit Set/Query() an dieser Property
+    herumbasteln.
+
+SIEHE AUCH
+----------
+::
+
+    TestIgnore, /std/player/comm.c
+
+
+Last modified: 02.10.2011, Zesstra
+
diff --git a/doc/sphinx/props/P_INDOORS.rst b/doc/sphinx/props/P_INDOORS.rst
new file mode 100644
index 0000000..9f4f328
--- /dev/null
+++ b/doc/sphinx/props/P_INDOORS.rst
@@ -0,0 +1,52 @@
+P_INDOORS
+=========
+
+NAME
+----
+::
+
+     P_INDOORS                     "indoors"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gesetzt, wenn von dem Raum aus der Himmel nicht sichtbar ist.
+
+     Objekte oder Gilden werten diese Property teilweise aus, fuer
+     Innenraeume sollte sie also sinnvollerweise gesetzt werden.
+
+     Licht wird _nicht_ durch P_INDOORS beeinflusst, muss also
+     selbst angepasst werden.
+
+BEISPIEL
+--------
+::
+
+     // Ein dunkler Innenraum:
+     SetProp(P_INDOORS, 1);            // ein Innenraum liegt innen :)
+     SetProp(P_LIGHT, 0);              // Licht auf 0
+
+     // Ein richtig heller Aussenraum:
+     SetProp(P_INDOORS, 0);
+     SetProp(P_LIGHT, 2);
+
+     // Ein heller Aussenraum mit Mondlicht (gut fuer Delfen)
+     SetProp(P_INDOORS, 0);
+     SetProp(P_LIGHT, 1);
+     SetProp(P_LIGHT_TYPE, LT_STARS|LT_MOON);
+
+SIEHE AUCH
+----------
+::
+
+     P_LIGHT, P_LIGHT_ABSORPTION, P_LIGHT_TYPE
+
+25.Aug 2008 Gloinson
+
diff --git a/doc/sphinx/props/P_INFO.rst b/doc/sphinx/props/P_INFO.rst
new file mode 100644
index 0000000..28d9a4a
--- /dev/null
+++ b/doc/sphinx/props/P_INFO.rst
@@ -0,0 +1,38 @@
+P_INFO
+======
+
+NAME
+----
+::
+
+     P_INFO                        "info"                        
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Geheime Information, die ggf. ueber einen Zauberspruch
+     von Spielern ermittelt werden kann.
+
+     
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_INFO,"Du ergruendest das Geheimnis.\n")
+
+SIEHE AUCH
+----------
+::
+
+     GetOwner(L)
+
+24. April 2006, Vanion 
+
diff --git a/doc/sphinx/props/P_INFORMME.rst b/doc/sphinx/props/P_INFORMME.rst
new file mode 100644
index 0000000..d35316f
--- /dev/null
+++ b/doc/sphinx/props/P_INFORMME.rst
@@ -0,0 +1,30 @@
+P_INFORMME
+==========
+
+NAME
+----
+::
+
+    P_INFORMME                    "informme"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt das Flag, ob der Spieler ueber ein-/ausloggende Spieler
+    informiert werden will.
+
+SIEHE AUCH
+----------
+::
+
+    Spielerkommando: inform
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_INPC_HOME.rst b/doc/sphinx/props/P_INPC_HOME.rst
new file mode 100644
index 0000000..d1f8ac8
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_HOME.rst
@@ -0,0 +1,21 @@
+P_INPC_HOME
+===========
+
+NAME
+----
+::
+
+    P_INPC_HOME                   "inpc_home"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INPC_LAST_ENVIRONMENT.rst b/doc/sphinx/props/P_INPC_LAST_ENVIRONMENT.rst
new file mode 100644
index 0000000..b78d032
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_LAST_ENVIRONMENT.rst
@@ -0,0 +1,21 @@
+P_INPC_LAST_ENVIRONMENT
+=======================
+
+NAME
+----
+::
+
+    P_INPC_LAST_ENVIRONMENT       "inpc_last_environment"       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INPC_LAST_PLAYER_CONTACT.rst b/doc/sphinx/props/P_INPC_LAST_PLAYER_CONTACT.rst
new file mode 100644
index 0000000..5a48fe0
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_LAST_PLAYER_CONTACT.rst
@@ -0,0 +1,21 @@
+P_INPC_LAST_PLAYER_CONTACT
+==========================
+
+NAME
+----
+::
+
+    P_INPC_LAST_PLAYER_CONTACT    "inpc_last_player_contact"    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INPC_WALK_AREA.rst b/doc/sphinx/props/P_INPC_WALK_AREA.rst
new file mode 100644
index 0000000..ebdc9f0
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_WALK_AREA.rst
@@ -0,0 +1,21 @@
+P_INPC_WALK_AREA
+================
+
+NAME
+----
+::
+
+    P_INPC_WALK_AREA              "inpc_walk_area"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INPC_WALK_DELAYS.rst b/doc/sphinx/props/P_INPC_WALK_DELAYS.rst
new file mode 100644
index 0000000..b6a9e24
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_WALK_DELAYS.rst
@@ -0,0 +1,21 @@
+P_INPC_WALK_DELAYS
+==================
+
+NAME
+----
+::
+
+    P_INPC_WALK_DELAYS            "inpc_walk_delay"             
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INPC_WALK_FLAGS.rst b/doc/sphinx/props/P_INPC_WALK_FLAGS.rst
new file mode 100644
index 0000000..294fbbf
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_WALK_FLAGS.rst
@@ -0,0 +1,21 @@
+P_INPC_WALK_FLAGS
+=================
+
+NAME
+----
+::
+
+    P_INPC_WALK_FLAGS             "inpc_walk_flags"             
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INPC_WALK_MODE.rst b/doc/sphinx/props/P_INPC_WALK_MODE.rst
new file mode 100644
index 0000000..ce5f167
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_WALK_MODE.rst
@@ -0,0 +1,21 @@
+P_INPC_WALK_MODE
+================
+
+NAME
+----
+::
+
+    P_INPC_WALK_MODE              "inpc_walk_mode"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INPC_WALK_ROUTE.rst b/doc/sphinx/props/P_INPC_WALK_ROUTE.rst
new file mode 100644
index 0000000..eab8ffc
--- /dev/null
+++ b/doc/sphinx/props/P_INPC_WALK_ROUTE.rst
@@ -0,0 +1,21 @@
+P_INPC_WALK_ROUTE
+=================
+
+NAME
+----
+::
+
+    P_INPC_WALK_ROUTE             "inpc_walk_route"             
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/walking.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_INTERMUD.rst b/doc/sphinx/props/P_INTERMUD.rst
new file mode 100644
index 0000000..e893d7c
--- /dev/null
+++ b/doc/sphinx/props/P_INTERMUD.rst
@@ -0,0 +1,25 @@
+P_INTERMUD
+==========
+
+NAME
+----
+::
+
+    P_INTERMUD                    "intermud"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+   Die Bedeutung dieser Property ist in den praehistorischen Untiefen
+   der Mudlib verlorengegangen.
+   Wird nicht mehr benutzt.
+   Nicht benutzen.
+   Ignorieren.
+
diff --git a/doc/sphinx/props/P_INTERNAL_EXTRA_LOOK.rst b/doc/sphinx/props/P_INTERNAL_EXTRA_LOOK.rst
new file mode 100644
index 0000000..8d07c63
--- /dev/null
+++ b/doc/sphinx/props/P_INTERNAL_EXTRA_LOOK.rst
@@ -0,0 +1,58 @@
+P_INTERNAL_EXTRA_LOOK
+=====================
+
+NAME
+----
+::
+
+	P_INTERNAL_EXTRA_LOOK			"internal_extralook"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/description.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt ein Mapping, in dem alle einzelnen
+  Extra-Look-Eintraege des Livings enthalten sind. Dabei weden die Daten von
+  AddExtraLook() und RemoveExtraLook() verwaltet. Fragt man diese Prop mit
+  QueryProp() ab, erhaelt man die Ausgabe der gueltigen Extralooks des
+  Livings. Bei Abfrage per Query() erhaelt man ein Mapping mit allen
+  Eintraegen und deren Daten. Jeder Wert im Mapping ist erneut ein Mapping, 
+  welches folgende Keys enthalten kann:
+  - "xllook": String, der im Extralook des Living angezeigt wird.
+  - "xlduration": Zeitstempel (int), der angibt, wie lang der Eintrag gueltig
+                  ist. 0 == "Unendlich", negative Zahlen besagen, dass der
+                  Eintrag nur bis Reboot/Ende gueltig sein und abs(xlduration)
+                  ist der Zeitpunkt des Eintrages dieses Extralooks.
+  - "xlende": String, der nach Ablaufen an das Living ausgegeben wird.
+  - "xlfun": Funktion, die gerufen wird und den String zurueckliefern muss, 
+             der ausgeben werden soll.
+  - "xlendefun": Funktion, die gerufen wird, wenn der Eintrag abgelaufen ist
+                 und den String zurueckliefern muss, der dann ans Living
+                 ausgeben wird.
+  - "xlobjectname": Objekt, in dem die o.a. Funktionen gerufen werden.
+
+BEMERKUNG
+---------
+::
+
+  DIESE PROPERTY BITTE NIEMALS PER HAND MIT Set()/SetProp() AENDERN!
+  Die Daten in dieser Prop werden vom Living selber verwaltet. Extralooks
+  koennen mittel AddExtraLook() eingetragen und mit RemoveExtraLook() entfernt
+  werden.
+
+SIEHE AUCH
+----------
+::
+
+  long(), /std/living/description.c, /std/player/base.c
+  AddExtraLook(), RemoveExtraLook()
+
+
+13.05.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_INT_LIGHT.rst b/doc/sphinx/props/P_INT_LIGHT.rst
new file mode 100644
index 0000000..71fb6b7
--- /dev/null
+++ b/doc/sphinx/props/P_INT_LIGHT.rst
@@ -0,0 +1,36 @@
+P_INT_LIGHT
+===========
+
+NAME
+----
+::
+
+    P_INT_LIGHT                       "int_light"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt den Lichtlevel an, der _in_ einem Objekt ist. Ein Abfragen dieser
+    Property kann z.B. in Raeumen sinnvoll sein, wenn es z.B. um das
+    aufwachen einer Eule oder einer Fledermaus geht. Zum Abfragen ob ein
+    Spieler etwas sehen kann, bitte auf jeden Fall P_PLAYER_LIGHT benutzen!
+
+    Bitte _nur_ ueber QueryProp auf diese Property zugreifen,
+    da das Lichtlevel ggf. neu berechnet werden muss!
+
+    Ein direktes setzen dieser Property ist NICHT moeglich, hierzu bitte
+    P_LIGHT benutzen!
+
+SIEHE AUCH
+----------
+::
+
+    P_LIGHT, P_TOTAL_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
+
diff --git a/doc/sphinx/props/P_INT_LONG.rst b/doc/sphinx/props/P_INT_LONG.rst
new file mode 100644
index 0000000..52a627f
--- /dev/null
+++ b/doc/sphinx/props/P_INT_LONG.rst
@@ -0,0 +1,53 @@
+P_INT_LONG
+==========
+
+NAME
+----
+::
+
+     P_INT_LONG                    "int_long"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Enthaelt Beschreibung, die man bekommt, wenn man sich in dem
+     Container (jeder Raum ist einer) umschaut als String.
+
+     Der Text sollte bereits umgebrochen sein.
+
+     Diese Property bestimmt die Ansicht des Containers von innen.
+     Fuer die Aussen(lang)ansicht muss P_LONG benutzt werden.
+
+BEMERKUNGEN
+-----------
+::
+
+     - Beschreibungen fuer etwaige Tueren im Raum werden in int_long()
+       hinzugefuegt. (Frueher wurde dies in einer Querymethode auf diese Prop
+       gemacht.)
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_INT_LONG, break_string(
+      "Du stehst in einem total spannenden Testraum. Seine absolute "
+      "Nichtigkeit erfuellt dich mit ehrfuerchtigem Grauen.",78));
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	P_INT_SHORT
+     Sonstiges:		int_long(), P_LONG
+			process_string(), break_string()
+
+04.06.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_INT_SHORT.rst b/doc/sphinx/props/P_INT_SHORT.rst
new file mode 100644
index 0000000..8a0d866
--- /dev/null
+++ b/doc/sphinx/props/P_INT_SHORT.rst
@@ -0,0 +1,57 @@
+P_INT_SHORT
+===========
+
+NAME
+----
+::
+
+     P_INT_SHORT			"int_short"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt die Innen-Kurzbeschreibung des Containers
+     als String oder Closure (mit String-Rueckgabewert).
+
+     Container sind hierbei z.B. Raeume.
+     ACHTUNG: Die Kurzbeschreibung sollte dabei weder mit einem
+	      Satzzeichen noch mit einem "\n" abgeschlossen sein
+	      (dies wird von den zustaendigen Funktionen erledigt).
+
+     Man sollte die Property nicht auf 0 setzen.
+
+     Diese Property bestimmt die Ansicht des Containers von innen.
+     Fuer die Aussen(kurz)ansicht muss P_SHORT benutzt werden.
+
+BEMERKUNGEN
+-----------
+::
+
+     - int_short() (bei Bewegung) filtert P_INT_SHORT durch process_string()
+       -> daher sind Closures moeglich
+
+BEISPIELE
+---------
+::
+
+     // ein Gang sieht natuerlich so aus
+     SetProp(P_INT_SHORT, "Ein Gang");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	P_INT_LONG
+     Sonstiges:		int_short(), P_SHORT
+			process_string(), break_string()
+
+
+Last modified: Thu May 31 15:34:05 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_INVIS.rst b/doc/sphinx/props/P_INVIS.rst
new file mode 100644
index 0000000..1bd50b2
--- /dev/null
+++ b/doc/sphinx/props/P_INVIS.rst
@@ -0,0 +1,66 @@
+P_INVIS
+=======
+
+NAME
+----
+::
+
+     P_INVIS                       "invis"                       
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Die Property P_INVIS dient dazu, Objekte als unsichtbar zu kennzeichnen.
+     Hierbei versucht P_INVIS die moeglichen Interaktionen mit Spielern zu
+     minimieren (im Gegensatz zu einer fehlenden P_SHORT, welche das Objekt
+     nur einfach nicht-sichtbar macht).
+
+     
+
+     Man sollte drei Arten von unsichtbaren Objekten unterscheiden:
+
+     - Gegenstaende
+       Setzt man P_INVIS auf eine Zahl ungleich 0, wird der Gegenstand
+       unsichtbar und der Name zu "etwas". Zusaetzlich koennen Spieler ihn
+       nicht mehr ansprechen, d.h. nehmen, wegwerfen, weitergeben etc.
+       (Bei magier-eigenen Kommandos ist dies evtl. nicht umgesetzt...)
+       Setzt man P_SHORT auf 0, wird der Gegenstand nur nicht mehr in
+       der Inventarliste von Behaeltern/Raeumen angezeigt, er behaelt aber
+       seinen Namen und ist durch Spieler ansprechbar, wenn sie eine ID
+       kennen.
+
+     - NPCs
+       Bei gesetztem P_INVIS wird der NPC unsichtbar und sein Name wird zu
+       "Jemand". Zusaetzlich koennen Spieler ihn nicht mehr ansprechen, z.B.
+       toeten oder knuddeln.
+       (Bei magier-eigenen Kommandos ist dies evtl. nicht umgesetzt...)
+       Setzt man P_SHORT auf 0, wird der NPC nur nicht mehr in der
+       Inventarliste von Behaeltern/Raeumen angezeigt, er behaelt aber seinen
+       Namen und ist durch Spieler ansprechbar, wenn sie eine ID kennen. Auch
+       angreifen und kaempfen ist moeglich.
+
+     
+
+     - Magier
+       Magier macht man unsichtbar, indem man ihnen die Property P_INVIS auf
+       einen Wert <> 0 setzt.
+       *  Spieler duerfen nicht unsichtbar gemacht werden!               *
+       *  Wird ein Magier unsichtbar gemacht, muss man ihm die Property	 *
+       *  P_INVIS auf den Wert setzen, den die Property P_AGE zu diesem	 *
+       *  Zeitpunkt hat (keine F_QUERY_METHOD !).				                 *
+       Setzt man die Property auf den Wert 1, so erhaelt ein Spieler,
+       wenn er den entsp. Magier fingert, die Ausgabe: Alter: 00:00:02,
+       was genauso verraeterisch ist, wie ein Alter, dass bei einem
+       scheinbar nicht eingeloggten Magier immer weiter hochgezaehlt
+       wird.
+
+
+27.05.2015, Zesstra
+
diff --git a/doc/sphinx/props/P_IP_NAME.rst b/doc/sphinx/props/P_IP_NAME.rst
new file mode 100644
index 0000000..6f655e4
--- /dev/null
+++ b/doc/sphinx/props/P_IP_NAME.rst
@@ -0,0 +1,21 @@
+P_IP_NAME
+=========
+
+NAME
+----
+::
+
+    P_IP_NAME                     "ip_name"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Rechnername des Interactives
+
diff --git a/doc/sphinx/props/P_IS_ARTILLERY.rst b/doc/sphinx/props/P_IS_ARTILLERY.rst
new file mode 100644
index 0000000..d66be6e
--- /dev/null
+++ b/doc/sphinx/props/P_IS_ARTILLERY.rst
@@ -0,0 +1,31 @@
+P_IS_ARTILLERY
+==============
+
+NAME
+----
+::
+
+	P_IS_ARTILLERY			"artillery"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	Is ein Objekt Artillerie, so muss diese Property
+	gesetzt sein. (Derzeit einfach auf 1 setzen.)
+
+SIEHE AUCH
+----------
+::
+
+	artillerie
+
+
+Last modified: Sam,  5. Jul 2003, 22:07:12 by Zook.
+
diff --git a/doc/sphinx/props/P_ITEMS.rst b/doc/sphinx/props/P_ITEMS.rst
new file mode 100644
index 0000000..3e4bbd8
--- /dev/null
+++ b/doc/sphinx/props/P_ITEMS.rst
@@ -0,0 +1,22 @@
+P_ITEMS
+=======
+
+NAME
+----
+::
+
+    P_ITEMS                       "items"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Definition von Gegenstaenden, die in dem Raum liegen sollen.
+     Erklaerung in einem Extrafile.
+
diff --git a/doc/sphinx/props/P_I_HATE_ALCOHOL.rst b/doc/sphinx/props/P_I_HATE_ALCOHOL.rst
new file mode 100644
index 0000000..5e44b86
--- /dev/null
+++ b/doc/sphinx/props/P_I_HATE_ALCOHOL.rst
@@ -0,0 +1,42 @@
+P_I_HATE_ALCOHOL
+================
+
+NAME
+----
+::
+
+    P_I_HATE_ALCOHOL                        "i_hate_alcohol"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/inpc/boozing.h
+
+BESCHREIBUNG
+------------
+::
+
+    Numerischer Wert, der die Obergrenze an P_ALCOHOL in einem Monster
+    definiert, welcher beim eigenstaendigen Tanken beruecksichtigt wird.
+
+BEMERKUNG
+---------
+::
+
+    Geht der Npc (und nur fuer solche ist diese Prop gedacht) eigen-
+    staendig tanken, werden vor dem Bestellen die Getraenke und Speisen
+    auf ihren Alkoholgehalt geprueft und mit dem aktuellen Wert von
+    P_ALCOHOL im Verhaeltnis zu P_I_HATE_ALCOHOL verglichen. Laege der
+    Wert fuer P_ALCOHOL dann ueber dem von P_I_HATE_ALCOHOL, wird dieses
+    Getraenk (diese Speise) nicht bestellt.
+
+SIEHE AUCH
+----------
+::
+
+     P_ALCOHOL, P_MAX_ALCOHOL
+
+
+Last modified: Sam Apr 14 12:35:00 2001 by Tilly
+
diff --git a/doc/sphinx/props/P_KEEPER.rst b/doc/sphinx/props/P_KEEPER.rst
new file mode 100644
index 0000000..3b60a47
--- /dev/null
+++ b/doc/sphinx/props/P_KEEPER.rst
@@ -0,0 +1,27 @@
+P_KEEPER
+========
+
+NAME
+----
+::
+
+    P_KEEPER                       "shop_keeper"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    In diese Property kann man in Kneipen und Laeden einen String schreiben.
+    Dann wird vor den Transaktionen geprueft, ob ein NPC anwesend ist,
+    der diesen String als ID hat.
+    Ist der NPC nicht vorhanden, kann nichts ge- oder verkauft werden.
+
+
+Last modified: Mon Aug 23 14:29:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/props/P_KEEP_ON_SELL.rst b/doc/sphinx/props/P_KEEP_ON_SELL.rst
new file mode 100644
index 0000000..d7897e8
--- /dev/null
+++ b/doc/sphinx/props/P_KEEP_ON_SELL.rst
@@ -0,0 +1,21 @@
+P_KEEP_ON_SELL
+==============
+
+NAME
+----
+::
+
+    P_KEEP_ON_SELL                "keep_on_sell"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Bei "verkaufe alles" wird das Objekt behalten.
+
diff --git a/doc/sphinx/props/P_KILLER.rst b/doc/sphinx/props/P_KILLER.rst
new file mode 100644
index 0000000..7bb462d
--- /dev/null
+++ b/doc/sphinx/props/P_KILLER.rst
@@ -0,0 +1,46 @@
+P_KILLER
+========
+
+NAME
+----
+::
+
+    P_KILLER                      "killer"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+   Diese Property enthaelt das Objekt, welches das Lebewesen als letztes
+   getoetet hat. Sie wird von do_damage(), heart_beat() (Vergiftungen) und
+   die() (bei direkten Aufrufen) automatisch gesetzt. Ein manuelles
+   Setzen vor Aufruf von do_damage() oder die() hat keinerlei Wirkung!
+   Sinnvollerweise liest man diese Property im NotifyPlayerDeath() aus,
+   spaeteres Auslesen ist unzuverlaessig, da der Killer inzwischen zerstoert
+   sein koennte.
+   Diese Property sollte _nicht_ per Hand gesetzt werden, schon gar nicht
+   waehrend eines NotifyPlayerDeath(), weil es evtl. noch andere Objekte gibt,
+   die sich dafuer interessieren!
+
+BEMERKUNGEN
+-----------
+::
+
+   Normalerweise steht hier ein Objekt drin (s.o.). Es gibt allerdings eine
+   Ausnahme: Stirbt ein Lebewesen an Gift, enthaelt P_KILLER den String
+   "gift".
+
+SIEHE AUCH
+----------
+::
+
+   do_damage()
+
+29.08.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_KILLS.rst b/doc/sphinx/props/P_KILLS.rst
new file mode 100644
index 0000000..6a4a73a
--- /dev/null
+++ b/doc/sphinx/props/P_KILLS.rst
@@ -0,0 +1,23 @@
+P_KILLS
+=======
+
+NAME
+----
+::
+
+    P_KILLS                       "playerkills"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der Spieler, die dieser Spieler schon getoetet hat.
+     Unerlaubte Manipulation ist ein SCHWERES VERGEHEN gegen
+     die Mudreglen.
+
diff --git a/doc/sphinx/props/P_KILL_MSG.rst b/doc/sphinx/props/P_KILL_MSG.rst
new file mode 100644
index 0000000..5b5d0ba
--- /dev/null
+++ b/doc/sphinx/props/P_KILL_MSG.rst
@@ -0,0 +1,97 @@
+P_KILL_MSG
+==========
+
+NAME
+----
+::
+
+	P_KILL_MSG			"kill_msg"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn ein Spieler getoetet wird, so erscheint dazu eine kurze Information
+     auf dem Todeskanal. Um dem toetenden Objekt zusaetzlich die Moeglichkeit
+     zu geben, noch etwas mehr auf diesem Kanal auszugeben, kann man in
+     dieser Property einen String uebergeben.
+     Noetige Zeilenumbrueche werden hierbei automatisch generiert.
+
+     Es ist auch moeglich anzugeben, ob Emotes verwendet werden und ob das
+     toetende Objekt ein Plural-Objekt ist. Hierzu uebergibt man ein Array
+     der Gestalt:
+
+	({Killmessage,Emotes}) bzw. ({Killmessage,Emotes,PLURAL})
+
+     Der Eintrag <Killmessage> stellt hierbei die Meldung selbst dar, PLURAL
+     gibt an, dass es sich um ein Plural-Objekt handelt und <Emotes> kann
+     folgende Werte annehmen:
+
+	MSG_SAY    - Meldung wird normal ausgegeben.
+	MSG_EMOTE  - Meldung erscheint als Emote.
+	MSG_GEMOTE - Meldung erscheint als Genitiv-Emote.
+	MSG_EMPTY  - Meldung erscheint ohne zuvorige Angabe des
+	               toetenden Objektes.
+
+     Moechte man die Meldung noch etwas "persoenlicher" ;-) gestalten, so
+     kann man den Platzhalter %s verwenden. An dessen Stelle wird dann der
+     Name des Verblichenen eingesetzt.
+
+BEISPIEL
+--------
+::
+
+     Ein nettes Beispiel ist das folgende: Wenn ein Spieler sich als
+     Drachentoeter bewehrt hat, so kann er traditionell in seinem Blut baden.
+     Hin und wieder ist jedoch auch der Drache erfolgreich, dem man eine
+     lustige Zusatzmeldung fuer den Todeskanal uebergeben kann:
+
+     void create() {
+       ::create();
+       ...
+       SetProp(P_KILL_MSG,"Jetzt bade ich mal in DEINEM Blut, %s!");
+       ...
+     }
+
+
+     Falls der 'Killer' ein Plural-Objekt oder -NPC war, koennte eine Meldung
+     auch folgendermassen aussehen:
+
+     SetProp(P_KILL_MSG,({"haun sich jetzt die Hucke voll.",
+			  MSG_EMOTE,
+			  PLURAL}));
+
+     wobei P_KILL_NAME hier natuerlich auf "Eine Menge Orks" oder
+     dergleichen gesetzt sein sollte. Auf dem Kanal waere dann dies zu
+     lesen:
+
+	[Tod:Lars] Eine Menge Orks haben gerade Orktoeter umgebracht.
+	[Tod:Eine Menge Orks haun sich jetzt die Hucke voll.]
+
+
+     Weiteres Beispiel.
+     Man habe einen NPC, dessen Killname als Plural aufzufassen ist, der aber
+     keinen zusaetlichen Text auf -Tod bringen soll.
+
+     SetProp(P_NAME, "Eine Horde Gummibaeren");
+     SetProp(P_KILL_NAME, "Viele kleine Gummibaeren");
+     SetProp(P_KILL_MSG, ({0, 0, 1}));
+
+SIEHE AUCH
+----------
+::
+
+     Tod:		die(L)
+     Todesmeldungen:	P_KILL_NAME, P_DIE_MSG, P_MURDER_MSG
+			P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
+     Sonstiges:		P_CORPSE, P_NOCORPSE, /room/death/death_room.c
+
+
+Last modified: Wed Aug 21 14:36:04 2002 by Bambi
+
diff --git a/doc/sphinx/props/P_KILL_NAME.rst b/doc/sphinx/props/P_KILL_NAME.rst
new file mode 100644
index 0000000..b730b67
--- /dev/null
+++ b/doc/sphinx/props/P_KILL_NAME.rst
@@ -0,0 +1,60 @@
+P_KILL_NAME
+===========
+
+NAME
+----
+::
+
+     P_KILL_NAME			"kill_name"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn ein Spieler getoetet wird, so erscheint eine kurze Information auf
+     dem Todeskanal. Im Normalfall werden die Informationen aus P_NAME,
+     P_ARTICLE und P_GENDER des toetenden Objektes verwendet, um einen Namen
+     fuer eben dieses Objekt zu kreieren. Manchmal moechte man jedoch einen
+     davon unabhaengigen Namen dort stehen haben. Dann kommt die Property
+     P_KILL_NAME zum Einsatz.
+     Man sollte beachten, dass der Name des Toetenden nicht zu lang sein
+     sollte, denn obwohl bei einer Todesmeldung automatisch umgebrochen wird,
+     kann es doch ziemlich stoeren. Wenn das toetende Objekt ein Plural-
+     Objekt ist, so kann man dies zusaetzlich in der Property P_KILL_MSG
+     angeben.
+
+BEISPIEL
+--------
+::
+
+     Eine Wolke, die wahlweise zwischen verschiedenen Zustaenden mutiert,
+     koennte mal eine Eiswolke, mal eine Giftwolke oder auch mal eine
+     Feuerwolke sein. Fuer den Todeskanal soll jedoch immer erscheinen:
+     '[Tod:] Eine mutierende Wolke hat gerade <Spieler> umgebracht.'
+
+     void create()
+     {
+       ::create();
+       ...
+       SetProp(P_KILL_NAME,"Eine mutierende Wolke");
+       ...
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Tod:		die(L)
+     Todesmeldungen:	P_KILL_MSG, P_DIE_MSG, P_MURDER_MSG
+			P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
+     Sonstiges:		P_CORPSE, P_NOCORPSE, /room/death/death_room.c
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_KNOWN_POTIONROOMS.rst b/doc/sphinx/props/P_KNOWN_POTIONROOMS.rst
new file mode 100644
index 0000000..b38f796
--- /dev/null
+++ b/doc/sphinx/props/P_KNOWN_POTIONROOMS.rst
@@ -0,0 +1,35 @@
+P_KNOWN_POTIONROOMS
+===================
+
+NAME
+----
+::
+
+    P_KNOWN_POTIONROOMS                 "known_potionrooms"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/potion.h
+
+BESCHREIBUNG
+------------
+::
+
+    Array mit den Nummern der Raeume, in denen der Spieler Zauber-
+    traenke finden kann. Die Zuordnung der Raeume und Nummern
+    geschieht im Potionmaster.
+
+    Nur lesbare _query - Property.
+
+SIEHE AUCH
+----------
+::
+
+    Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
+    Verwandt:  FindPotion(), AddKnownPotion(), RemoveKnownPotion(), InList()
+    Props:     P_POTIONROOMS
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_LASTDIR.rst b/doc/sphinx/props/P_LASTDIR.rst
new file mode 100644
index 0000000..a692dbb
--- /dev/null
+++ b/doc/sphinx/props/P_LASTDIR.rst
@@ -0,0 +1,28 @@
+P_LASTDIR
+=========
+
+NAME
+----
+::
+
+    P_LASTDIR                  "p_lib_lastdir"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/shells.h
+
+BESCHREIBUNG
+------------
+::
+
+    Das jeweils letzte Verzeichnis, in dem der Magier war.
+    (Nur fuer Magier von Belang)
+
+Siehe auch:
+    P_CURRENTDIR
+
+Letzte Aenderung:
+    03.05.2016, Zesstra
+
diff --git a/doc/sphinx/props/P_LAST_COMBAT_TIME.rst b/doc/sphinx/props/P_LAST_COMBAT_TIME.rst
new file mode 100644
index 0000000..0dbc5ed
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_COMBAT_TIME.rst
@@ -0,0 +1,39 @@
+P_LAST_COMBAT_TIME
+==================
+
+NAME
+----
+::
+
+	P_LAST_COMBAT_TIME		"last_combat_time"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property wird genau die Zeit festgehalten, zu der ein
+	Lebewesen zuletzt einen Angriff abgewehrt oder einen Angriff
+	durchgefuehrt hat. Die Property enthaelt diese Information hierbei
+	immer in Form eines Integerwertes.
+	Dieser Wert koennte z.B. wichtig sein, wenn man wissen moechte, wann
+	ein Lebewesen zuletzt gekaempft hat. Es ist beispielsweise nicht
+	moeglich, waehrend oder auch unmittelbar nach einem Kampf den Befehl
+	'Ende' zu nutzen, da dies zur Flucht missbraucht werden kann. Dafuer
+	wird der Wert der Property zuvor ausgewertet.
+
+SIEHE AUCH
+----------
+::
+
+	P_LAST_DAMTIME, P_LAST_DAMAGE, P_LAST_DAMTYPES, Attack(), Defend(),
+	/std/living/combat.c, /std/living/life.c
+
+
+Last modified: Wed May 26 16:43:00 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_LAST_COMMAND_ENV.rst b/doc/sphinx/props/P_LAST_COMMAND_ENV.rst
new file mode 100644
index 0000000..e7f2636
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_COMMAND_ENV.rst
@@ -0,0 +1,30 @@
+P_LAST_COMMAND_ENV
+==================
+
+NAME
+----
+::
+
+    P_LAST_COMMAND_ENV            "last_command_env"            
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Der Raum, in dem das letzte Kommando eingegeben wurde.
+
+BEMERKUNGEN
+-----------
+::
+
+     Keine echte Property, _query_last_command_env() ist
+     in /std/players/command.c implementiert.
+
+14.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/props/P_LAST_CONTENT_CHANGE.rst b/doc/sphinx/props/P_LAST_CONTENT_CHANGE.rst
new file mode 100644
index 0000000..3fcf1de
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_CONTENT_CHANGE.rst
@@ -0,0 +1,32 @@
+P_LAST_CONTENT_CHANGE
+=====================
+
+NAME
+----
+::
+
+    P_LAST_CONTENT_CHANGE         "last_content_change"         
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wann wurde zum letzten Mal was ins Obj gestopft oder rausgenommen?
+     Wichtig fuer den Weight-Cache
+
+ANMERKUNG
+---------
+::
+
+     Die Property kann nur ueber QueryProp() und SetProp() ausgelesen bzw.
+     gesetzt werden. Query() und Set() funktionieren *nicht*.
+
+     Ausserdem fuehrt ein Setzen per SetProp() zu einer Erhoehung des 
+     Wertes um eins - unabhaengig vom gesetzten Wert.
+
diff --git a/doc/sphinx/props/P_LAST_DAMAGE.rst b/doc/sphinx/props/P_LAST_DAMAGE.rst
new file mode 100644
index 0000000..332b729
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_DAMAGE.rst
@@ -0,0 +1,38 @@
+P_LAST_DAMAGE
+=============
+
+NAME
+----
+::
+
+	P_LAST_DAMAGE			"last_damage"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property wird genau die Schadensstaerke festgehalten,
+	welche ein Lebewesen zuletzt abbekommen hat. Die Property enthaelt
+	diese Information hierbei immer in Form eines Integerwertes.
+	Auch die Staerke des Giftschadens durch die Wirkung einer Vergiftung
+	wird hier festgehalten.
+	Dieser Wert koennte z.B. wichtig sein, wenn man wissen moechte,
+	welche Schadensstaerke nach Einwirkung von Defendern, Ruestung,
+	Hooks und Skills uebriggeblieben ist.
+
+SIEHE AUCH
+----------
+::
+
+	P_LAST_DAMTIME, P_LAST_DAMTYPES, Defend(),
+	/std/living/combat.c, /std/living/life.c
+
+
+Last modified: Tue Jan 26 12:34:29 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_LAST_DAMTIME.rst b/doc/sphinx/props/P_LAST_DAMTIME.rst
new file mode 100644
index 0000000..d4c499f
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_DAMTIME.rst
@@ -0,0 +1,38 @@
+P_LAST_DAMTIME
+==============
+
+NAME
+----
+::
+
+	P_LAST_DAMTIME			"last_damtime"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property wird genau die Zeit festgehalten, zu der ein
+	Lebewesen zuletzt einen Schaden abbekommen hat. Die Property
+	enthaelt diese Information hierbei immer in Form eines
+	Integerwertes.
+	Auch der Zeitpunkt der Einwirkung von Giftschaden durch die Wirkung
+	einer Vergiftung wird hier festgehalten.
+	Dieser Wert koennte z.B. wichtig sein, wenn man wissen moechte, wann
+	ein Lebewesen zuletzt verletzt wurde.
+
+SIEHE AUCH
+----------
+::
+
+	P_LAST_COMBAT_TIME, P_LAST_DAMAGE, P_LAST_DAMTYPES, Defend(),
+	/std/living/combat.c, /std/living/life.c
+
+
+Last modified: Wed May 26 16:44:38 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_LAST_DAMTYPES.rst b/doc/sphinx/props/P_LAST_DAMTYPES.rst
new file mode 100644
index 0000000..e0428a0
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_DAMTYPES.rst
@@ -0,0 +1,37 @@
+P_LAST_DAMTYPES
+===============
+
+NAME
+----
+::
+
+	P_LAST_DAMTYPES			"last_damtypes"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property werden genau die Schadensarten festgehalten,
+	welche ein Lebewesen zuletzt abbekommen hat. Die Property enthaelt
+	diese Information hierbei immer in Form eines Arrays.
+	Auch der Giftschaden durch die Wirkung einer Vergiftung wird hier
+	festgehalten.
+	Dieser Wert koennte z.B. wichtig sein, wenn man nach dem Tod eines
+	Lebewesens feststellen moechte, durch was es umgekommen ist.
+
+SIEHE AUCH
+----------
+::
+
+	P_LAST_DAMAGE, P_LAST_DAMTIME, Defend(),
+	/std/living/combat.c, /std/living/life.c
+
+
+Last modified: Tue Jan 26 12:34:29 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_LAST_DEATH_PROPS.rst b/doc/sphinx/props/P_LAST_DEATH_PROPS.rst
new file mode 100644
index 0000000..8d13c41
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_DEATH_PROPS.rst
@@ -0,0 +1,32 @@
+P_LAST_DEATH_PROPS
+==================
+
+NAME
+----
+::
+
+    P_LAST_DEATH_PROPS                "last_death_props"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt nach dem Tod eines Spielers ein Mapping mit 
+     den Werte aller Properties, die im die() zurueckgesetzt werden.
+
+     Auf diese Weise kann ein Objekt auch im NotifyPlayerDeath() noch 
+     auf die Werte zurueckgreifen, obwohl sie bereits geloescht sind.
+
+     Folgende Properties werden so gesichert:
+
+   
+
+     P_POISON, P_FROG, P_ALCOHOL, P_DRINK, P_FOOD , P_BLIND, P_DEAF, 
+     P_MAX_HANDS, P_PARA, P_NO_REGENERATION , P_HP, P_SP, P_LAST_DEATH_TIME
+
diff --git a/doc/sphinx/props/P_LAST_DEATH_TIME.rst b/doc/sphinx/props/P_LAST_DEATH_TIME.rst
new file mode 100644
index 0000000..40c82b2
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_DEATH_TIME.rst
@@ -0,0 +1,21 @@
+P_LAST_DEATH_TIME
+=================
+
+NAME
+----
+::
+
+    P_LAST_DEATH_TIME                "last_death_time"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Der Zeitpunkt des letzten Todes des Spielers.
+
diff --git a/doc/sphinx/props/P_LAST_LOGIN.rst b/doc/sphinx/props/P_LAST_LOGIN.rst
new file mode 100644
index 0000000..c9b56b2
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_LOGIN.rst
@@ -0,0 +1,35 @@
+P_LAST_LOGIN
+============
+
+NAME
+----
+::
+
+    P_LAST_LOGIN                  "last_login"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zeitpunkt des letzten Logins
+
+BEMERKUNGEN
+-----------
+::
+
+     Gegen aeussere Aenderung und Set/QueryMethoden geschuetzt.
+
+SIEHE AUCH
+----------
+::
+
+     P_LAST_LOGOUT, save_me
+
+28. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_LAST_LOGOUT.rst b/doc/sphinx/props/P_LAST_LOGOUT.rst
new file mode 100644
index 0000000..d8a7843
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_LOGOUT.rst
@@ -0,0 +1,39 @@
+P_LAST_LOGOUT
+=============
+
+NAME
+----
+::
+
+    P_LAST_LOGOUT                 "last_logout"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zeitpunkt des letzten Logouts. Anhand dieser Zeit werden die Feindes-
+     listen und in Abwesenheit eingefuegte Gegenstaende aktualisiert.
+
+     Dieses Datum wird bei Magiern nicht aktualisiert, wenn sie unsichtbar
+     sind/sich unsichtbar ausloggen.
+
+BEMERKUNGEN
+-----------
+::
+
+     Gegen aeussere Aenderung und Set/QueryMethoden geschuetzt.
+
+SIEHE AUCH
+----------
+::
+
+     P_LAST_LOGIN, P_INVIS, save_me, init, StopHuntFor
+
+28. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_LAST_MOVE.rst b/doc/sphinx/props/P_LAST_MOVE.rst
new file mode 100644
index 0000000..af703cc
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_MOVE.rst
@@ -0,0 +1,37 @@
+P_LAST_MOVE
+===========
+
+NAME
+----
+::
+
+	P_LAST_MOVE			"last_move"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property wird die Zeit der letzten Bewegung eines
+	Lebewesens festgehalten. Selbsterklaerend ist auch der dazugehoerige
+	Quellcode innerhalb move() in '/std/living/moving.c':
+	  SetProp(P_LAST_MOVE,time());
+	Wichtig ist diese Property insbesondere fuer die Unterbindung von
+	Rein-Angriff-Raus-Taktiken. Dieser Modus ist standardmaessig in jedem
+	NPC aktiviert und kann ueber die Property P_ENABLE_IN_ATTACK_OUT
+	ausgeschalten werden.
+
+SIEHE AUCH
+----------
+::
+
+	move(), time(), P_ENABLE_IN_ATTACK_OUT, /std/living/moving.c
+
+
+Last modified: Sat Jan 30 12:53:00 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_LAST_USE.rst b/doc/sphinx/props/P_LAST_USE.rst
new file mode 100644
index 0000000..98d674f
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_USE.rst
@@ -0,0 +1,34 @@
+P_LAST_USE
+==========
+
+NAME
+----
+::
+
+     P_LAST_USE "last_use"
+
+DEFINIERT IN
+------------
+::
+
+     <properties.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property wird in Ruestungen und Waffen dazu benutzt um
+     festzuhalten, wann die Ruestung/Waffe zuletzt im Kampf benutzt
+     wurde.
+
+SIEHE AUCH
+----------
+::
+
+     Ruestungen:	QueryDefend(L)
+     Waffen:		QueryDamage(L)
+     Sonstiges:		P_EQUIP_TIME, P_UNWIELD_TIME
+
+
+Last modified: Fri Feb 06 10:15:00 1998 by Paracelsus
+
diff --git a/doc/sphinx/props/P_LAST_WEAR_ACTION.rst b/doc/sphinx/props/P_LAST_WEAR_ACTION.rst
new file mode 100644
index 0000000..ae568ba
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_WEAR_ACTION.rst
@@ -0,0 +1,31 @@
+P_LAST_WEAR_ACTION
+==================
+
+PROPERTY
+--------
+::
+
+	P_LAST_WEAR_ACTION    "last_wear_action"
+
+DEFINIERT IN: 
+
+	/sys/armour.h (und damit auch in properties.h)
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Prop gibt an, welche An/Auszieh-Aktion ein Spieler zuletzt
+	durchgefuehrt hat. Sie ist ein zweielementiges Array, wobei der
+	erste Eintrag angibt, ob der Spieler sich an- oder ausgezogen
+	hat (WA_WEAR, WA_UNWEAR, auch in armour.h definiert) und der
+	zweite den Zeitpunkt.
+
+	Die Property wird (unter anderem?) dafuer verwendet festzustellen ob
+	der Spieler in der letzten Runde schon einen Ruestungswechsel
+	vorgenommen hat und einen entgegengesetzten zu unterbinden.
+
+LETZTE AENDERUNG: 
+
+2003-01-29, 17:30 von Humni
+
diff --git a/doc/sphinx/props/P_LAST_XP.rst b/doc/sphinx/props/P_LAST_XP.rst
new file mode 100644
index 0000000..f69b8ab
--- /dev/null
+++ b/doc/sphinx/props/P_LAST_XP.rst
@@ -0,0 +1,43 @@
+P_LAST_XP
+=========
+
+NAME
+----
+::
+
+    P_LAST_XP                        "last_xp"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+    Ein Array vom Typ ({ pfad, xp }).
+
+    Der Eintrag "pfad" gibt das Gebiet an, in dem ein Spieler zuletzt XP
+    bekommen hat. Dabei wird aus "/d/ebene/magier/room/raum1.c" dann
+    "/d/ebene/magier/room".
+
+    Der Wert "xp" zeigt an, wieviele XP der Spieler _in diesem Gebiet_
+    gesammelt hat. Sobald er auch nur einen XP in einem anderen Gebiet
+    bekommt, zeigt P_LAST_XP nur noch diesen neu erhaltenen XP an.
+
+    Der Anwendungszweck waere z.B. eine Heilstelle, die nur dann Wirkung
+    zeigt, wenn der Spieler wirklich in dem betreffenden Gebiet gemetzelt hat
+    und nicht nur zum Tanken hergerannt ist oder eine Unterscheidung, ob
+    jemand metzelt oder nur uebt (ueber die XP).
+
+SIEHE AUCH
+----------
+::
+
+     Funktionen:  AddExp()
+     Verwandt:    P_NO_XP, P_XP
+
+14.Feb 2007 Gloinson
+
diff --git a/doc/sphinx/props/P_LEAVECMDS.rst b/doc/sphinx/props/P_LEAVECMDS.rst
new file mode 100644
index 0000000..7931548
--- /dev/null
+++ b/doc/sphinx/props/P_LEAVECMDS.rst
@@ -0,0 +1,58 @@
+P_LEAVECMDS
+===========
+
+NAME
+----
+::
+
+    P_LEAVECMDS                   "leavecmds"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+    Ein Array mit Befehlen, die zum Verlassen des Transporters fuehren. 
+
+BEISPIEL
+--------
+::
+
+    SetProp(P_LEAVECMDS,({ "verlass","verlasse" }) );
+
+    Gibt der Spieler nun 'verlasse xxx' ein, so sorgt /std/transport.c 
+    dafuer, das der Spieler auch von oder aus dem Transporter bewegt 
+    wird. Vorausgesetzt natuerlich, er ist an einem Haltepunkt angelangt.
+
+BEMERKUNGEN
+-----------
+::
+
+    Um /std/transport.c nicht aufzublaehen, werden weitere Argumente wie
+    etwa 'verlasse das|die|den xxx' _nicht_ unterstuetzt!
+
+    Hier muss der verantwortliche Magier schon eine eigene Loesung finden
+    und in seinen Transporter schreiben.
+
+    Sollen Kommandos zum Betreten UND Verlassen eines Transporters ver-
+    wendet werden koennen, muessen diese in P_TRAVEL_CMDS gesetzt werden.
+
+SIEHE AUCH
+----------
+::
+
+    P_LEAVEFAIL, P_ENTERFAIL, P_ENTERCMDS, P_TRAVEL_CMDS, transporter,
+
+LETZTE AENDERUNG
+----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
+    
+
diff --git a/doc/sphinx/props/P_LEAVEFAIL.rst b/doc/sphinx/props/P_LEAVEFAIL.rst
new file mode 100644
index 0000000..9af4941
--- /dev/null
+++ b/doc/sphinx/props/P_LEAVEFAIL.rst
@@ -0,0 +1,50 @@
+P_LEAVEFAIL
+===========
+
+NAME
+----
+::
+
+    P_LEAVEFAIL                   "leavefail"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Spieler, wenn er ausserhalb der Anlegezeiten einen 
+     Transporter verlassen will. Ist die Propertie ein Array, so wird 
+     das erste Element als Meldung an den Spieler, das zweite als 
+     Meldung an die Mitspieler im Transporter geschickt. Ist der Eintrag
+     dagegen ein simpler String, so wird die Meldung nur an den Spieler
+     ausgegeben.
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_LEAVEFAIL, "Die Wildgaense fliegen viel zu hoch" );
+
+     SetProp(P_LEAVEFAIL, ({ "Die Wildgaense fliegen viel zu hoch",
+                             "versucht, vom Ruecken der Wildgans zu "
+                            +"klettern und besinnt sich dann doch" }) );
+
+                             
+
+SIEHE AUCH
+----------
+::
+
+     P_LEAVEMSG, P_ENTERMSG, P_ENTERFAIL, transporter
+
+LETZTE AENDERUNG
+----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
diff --git a/doc/sphinx/props/P_LEAVEMSG.rst b/doc/sphinx/props/P_LEAVEMSG.rst
new file mode 100644
index 0000000..3253e77
--- /dev/null
+++ b/doc/sphinx/props/P_LEAVEMSG.rst
@@ -0,0 +1,38 @@
+P_LEAVEMSG
+==========
+
+NAME
+----
+::
+
+    P_LEAVEMSG                    "leavemsg"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+     Array mit zwei Meldungen. Der erste Eintrag wird an den Transporter
+     ausgegeben, der zweite an den Raum in den der Spieler kommt.
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_LEAVEMSG, ({ "klettert vom Ruecken der Wildgans",
+                            "kommt vom Ruecken einer Wildgans herunter" }) );
+
+SIEHE AUCH: 
+     P_ENTERMSG, P_LEAVEFAIL, P_ENTERFAIL, transporter
+
+LETZTE AENDERUNG
+----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
diff --git a/doc/sphinx/props/P_LEP.rst b/doc/sphinx/props/P_LEP.rst
new file mode 100644
index 0000000..afca4cb
--- /dev/null
+++ b/doc/sphinx/props/P_LEP.rst
@@ -0,0 +1,22 @@
+P_LEP
+=====
+
+NAME
+----
+::
+
+    P_LEP                         "lep"                         
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Levelpunkte eines Spielers
+     NICHT VON HAND SETZEN!!!
+
diff --git a/doc/sphinx/props/P_LEVEL.rst b/doc/sphinx/props/P_LEVEL.rst
new file mode 100644
index 0000000..8cbe8f8
--- /dev/null
+++ b/doc/sphinx/props/P_LEVEL.rst
@@ -0,0 +1,48 @@
+P_LEVEL
+=======
+
+NAME
+----
+::
+
+    P_LEVEL                       "level"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Spieler-Level (!= Magierlevel)
+
+     In Krankheits- (CL_DISEASE) und Giftobjekten (CL_POISON) drueckt 
+     P_LEVEL aus, wie schwer die Krankheit/das Gift ist. Je nachdem, wie 
+     hoch oder niedrig der Level gesetzt wird, muss z.B. ein Kleriker mehr 
+     oder weniger oft kurieren, um  eine (ggf. stufenweise) Heilung zu 
+     bewirken.
+
+     In Fluchobjekten (CL_CURSE) gibt P_LEVEL ebenfalls die Schwere des
+     Fluches an, jedoch ist hier zu beachten, dass z.B. Kleriker aktuell
+     keine stufenweise Schwaechung bewirken koennen, sondern entweder den
+     Fluch entfernen koennen oder komplett scheitern. 
+     Der Fluchlevel ist hier grob als Chance des Scheiterns in einem 
+     Wertebereich von 1-100 zu sehen, was bedeutet, dass ein Fluchlevel 
+     von 100 als permanenter, nicht entfernbarer Fluch anzusehen ist.
+
+     Genaueres ist in der Klerusgilde nachzulesen oder beim GM Klerus zu
+     erfragen.
+
+SIEHE AUCH
+----------
+::
+
+     Properties:  P_GUILD_LEVEL
+     Allgemeines: /doc/wiz/gift, /doc/help/gift
+     Funktionen:  AddClass(L), is_class_member(L)
+
+Letzte Aenderung: 2015-Feb-02, Arathorn.
+
diff --git a/doc/sphinx/props/P_LIFETIME.rst b/doc/sphinx/props/P_LIFETIME.rst
new file mode 100644
index 0000000..09f7d4a
--- /dev/null
+++ b/doc/sphinx/props/P_LIFETIME.rst
@@ -0,0 +1,54 @@
+P_LIFETIME
+==========
+
+NAME
+----
+::
+
+     P_LIFETIME                    "std_food_lifetime"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/food.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zeit in Sekunden, die die Speise haltbar ist.
+     Mit Setzen dieser Property wird der Wert fuer P_RESET_LIFETIME und
+     dort gespeichert.
+     Nach dieser Zeit wird diese Speise schlecht und je nach Konfiguration
+     der Speise eventuell zerstoert. Sichergestellt wird dies durch den
+     Aufruf von reset() nach dieser Anzahl Sekunden.
+     Moechte man eine Speise haben, die niemals verdirbt
+     (genehmigungspflichtig!), nutzt man die Property P_NO_BAD
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Sobald der Countdown zum Schlechtwerden der Speise laeuft, also ein
+     Spieler damit in Beruehrung kam, zeigt SetProp auf diese Property keine
+     Wirkung mehr.
+
+DEFAULT
+-------
+::
+
+     Ohne Setzen von P_LIFETIME ,P_RESET_LIFETIME und P_NO_BAD verdirbt die
+     Speise nach einem Reset, also zwischen 30 und 60 Minuten
+
+SIEHE AUCH
+----------
+::
+
+     wiz/food, P_RESET_LIFETIME, P_NO_BAD
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_LIGHT.rst b/doc/sphinx/props/P_LIGHT.rst
new file mode 100644
index 0000000..5f06359
--- /dev/null
+++ b/doc/sphinx/props/P_LIGHT.rst
@@ -0,0 +1,81 @@
+P_LIGHT
+=======
+
+NAME
+----
+::
+
+    P_LIGHT                       "light"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt den Lichtlevel eines Objektes an, d.h. wie hell das Objekt von sich
+    aus leuchtet. Moechte man den gesamten Lichtlevel haben der von einem
+    Objekt ausgeht, so sollte man P_TOTAL_LIGHT nehmen, das den Inhalt eines
+    Containers direkt mit verrechnet.
+
+    Bitte _nur_ ueber SetProp bzw. QueryProp zugreifen, da es fuer die
+    Berechnung wichtig ist, das in allen Containern P_LAST_CONTENT_CHANGE
+    gesetzt wird um ein neuberechnen des Lichtlevels auszuloesen!
+
+ANMERKUNG
+---------
+::
+
+    Um ein ungefaehres Gefuehl davon zu bekommen was ein Lichtlevel in
+    etwa bedeutet hier einige allgemeine Beispiele von Gegenstaenden.
+    Grundsaetzlich sollten Lichtlevel <0 und >2 nur in Ruecksprache mit dem
+    Balanceteam benutzt werden.
+
+    Lichtlevel -1,  z.B. ein schwarzer Ring, von dem eine kleine dunkle Aura
+                    ausgeht, die den Spieler umgibt.
+    Lichtlevel  0,  der Gegenstand beeinflusst das Licht ueberhaupt nicht
+    Lichtlevel  1,  der Spieler haelt eine kleine Lichtquelle in Haenden,
+                    dieses kann ein Leuchtpfirsich, eine Fackel oder ein
+                    Feuerschwert oder aehnliches sein.
+    Lichtlevel  2,  eine etwas groessere Lichtquelle, die aber immer noch
+                    nicht den Raum beleuchtet sondern lediglich dem Spieler
+                    einen Lichtschein gewaehrt mit dem er sehen kann.
+    Lichtlevel >2,  extrem helle Lichtquellen, die den gesamten Raum
+                    ausleuchten, in der Regel wohl eher magischer Natur.
+                    Solche Lichtquellen sollten sich mit der Zeit
+                    verbrauchen, dem Spieler Schaden zufuegen oder
+                    aehnliches, damit die Spieler nicht defaultmaessig mit
+                    einer solchen Lichtquelle durchs MG ziehn.
+
+    Daraus ergeben sich dann folgende Konsequenzen fuer Raeume:
+    Lichtlevel  >1: Der Raum ist sehr hell erleuchtet und kann von Spielern
+                    nicht oder nur sehr schwer abgedunkelt werden. Ein Wert
+                    von 2-3 kann interessant sein, wenn die NPCs im Raum
+                    ueber keine Nachtsicht verfuegen. Ueber ein Abdunkeln des
+                    Raumes kann der Spieler dann doch den Nachtkampf nutzen.
+    Lichtlevel   1: Der Raum ist erleuchtet und die Spieler koennen ohne
+                    weitere Lichtquellen sehen...
+    Lichtlevel   0: Ein dunkler Raum in dem man mit jeder Fackel sehen kann.
+    Lichtlevel  -1: man benoetigt zwei einfache Lichtquellen oder Nachtsicht
+                    um in diesem Raum etwas sehen zu koennen.
+    Lichtlevel  -2: Man benoetigt schon eine besondere Lichtquelle um in
+                    diesem Raum noch etwas sehen zu koennen. Solche
+                    Lichtquellen sind nichts fuer Anfaenger oder mittlere
+                    Spieler da sie schwer zu beschaffen und in der Regel
+                    auch einige Handicaps haben.
+    Lichtlevel <-2: Der Raum ist wirklich absolut stockduster und
+                    Lichtquellen die solch einen Raum ausleuchten koennen,
+                    sind ausserordentlich selten und haben immer ihre
+                    Tuecken. Diese Lichtlevel sollten nur mit Vorsicht
+                    genossen werden.
+
+SIEHE AUCH
+----------
+::
+
+    P_TOTAL_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
+
diff --git a/doc/sphinx/props/P_LIGHTDESC.rst b/doc/sphinx/props/P_LIGHTDESC.rst
new file mode 100644
index 0000000..5bab936
--- /dev/null
+++ b/doc/sphinx/props/P_LIGHTDESC.rst
@@ -0,0 +1,56 @@
+P_LIGHTDESC
+===========
+
+NAME
+----
+::
+
+    P_LIGHTDESC                   "lightdesc"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    String oder Array von Strings mit Adjektiven, die das Leuchten der 
+    Lichtquelle beschreiben (z.B. leuchtend, brennend, gluehend).
+    Standardmaessig ist die Property auf "brennend" gesetzt.
+
+    Wenn ein Array angegeben wird, werden die Beschreibungen passend auf
+    die Benndauer aufgeteilt und das zur aktuell noch vorhandenen Rest-
+    Brenndauer passende Adjektiv ausgegeben. Das Array wird dabei rueck-
+    aerts durchlaufen, d.h. fuer eine frisch entzuendete Lichtquelle wird
+    der letzte Eintrag des Arrays verwendet (s. Beispiele).
+
+BEISPIELE
+---------
+::
+
+    Eine einfache Oellampe:
+
+    SetProp(P_LIGHTDESC, "angezuendet");
+
+    Eine Fackel mit mehreren Brennstadien (aus /items/fackel.c):
+
+    SetProp(P_LIGHTDESC, ({"glimmend","flackernd","leicht flackernd",
+                         "brennend","hell lodernd","frisch angezuendet"}));
+
+SIEHE AUCH
+----------
+::
+
+    Basisklassen: /std/lightsource.c
+    Properties:   P_FUEL, P_DO_DESTRUCT, P_LIGHT
+    Methoden:     AddFuel(L)
+
+LETZTE AENDERUNG
+----------------
+::
+
+    22. Dez. 2015, Arathorn
+
diff --git a/doc/sphinx/props/P_LIGHTED.rst b/doc/sphinx/props/P_LIGHTED.rst
new file mode 100644
index 0000000..05fb255
--- /dev/null
+++ b/doc/sphinx/props/P_LIGHTED.rst
@@ -0,0 +1,21 @@
+P_LIGHTED
+=========
+
+NAME
+----
+::
+
+    P_LIGHTED                     "lighted"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Flag, ob die Lichtquelle in Betrieb ist.
+
diff --git a/doc/sphinx/props/P_LIGHT_ABSORPTION.rst b/doc/sphinx/props/P_LIGHT_ABSORPTION.rst
new file mode 100644
index 0000000..c397ee2
--- /dev/null
+++ b/doc/sphinx/props/P_LIGHT_ABSORPTION.rst
@@ -0,0 +1,31 @@
+P_LIGHT_ABSORPTION
+==================
+
+NAME
+----
+::
+
+    P_LIGHT_ABSORPTION                  "light_absorption"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    In Raeumen verteilt sich aufgrund ihrer Groesse das Licht und gerade in
+    groesseren Raeumen kann eine kleine Fackel unter Umstaenden nicht mehr
+    ausreichen den gesamten Raum auszuleuchten. In diesem Fall kann man
+    ueber diese Property das Verhalten des Lichts steuern.
+    Ein "normaler" durchschnittlicher Raum hat hier den Defaultwert 1.
+
+SIEHE AUCH
+----------
+::
+
+    P_TOTAL_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
+
diff --git a/doc/sphinx/props/P_LIGHT_MODIFIER.rst b/doc/sphinx/props/P_LIGHT_MODIFIER.rst
new file mode 100644
index 0000000..b714418
--- /dev/null
+++ b/doc/sphinx/props/P_LIGHT_MODIFIER.rst
@@ -0,0 +1,75 @@
+P_LIGHT_MODIFIER
+================
+
+NAME
+----
+::
+
+    P_LIGHT_MODIFIER                     "light_modifier"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Veraendert das Lichtlevel das von einem Lebewesen wahrgenommen wird.
+    Der Wert dieser Property wird additiv in P_PLAYER_LIGHT beruecksichtigt.
+    Es ist hiermit z.B. moeglich eine Sonnenbrille zu programmieren, diese
+    veraendert ja nicht das tatsaechliche Lichtlevel, sondern verdunkelt nur
+    die Sicht.
+
+ANMERKUNG
+---------
+::
+
+    Damit NPCs in der Lage sind solche Gegenstaende richtig einzuschaetzen,
+    sollte diese Property in jedem Gegenstand der einen Light-Modifier setzt,
+    auch gesetzt sein. Das veraendern dieser Property in Spielern durch NPCs
+    oder Gegenstaende ist selbstverstaendlich genehmigungspflichtig.
+
+BEISPIELE
+---------
+::
+
+       // Ein NPC der auch in relativ dunklen Raeumen mit Lichtlevel -2
+       // noch sehen kann...
+       create_default_npc(10);
+       SetProp(P_LIGHT_MODIFIER, 3);
+
+       // Eine Sonnenbrille, die das Lichtlevel um eins senkt.
+
+       create()
+       {
+
+          :
+
+          SetProp(P_ARMOUR_TYPE, AT_GLASSES);
+          SetProp(P_LIGHT_MODIFIER, -1);
+
+          :
+
+       }
+
+       // Achtung: Falls pl Query- oder Set-Methoden auf P_LIGHT_MODIFIER hat,
+       // wird diese Methode hier furchtbar schief gehen und im besten Fall
+       // nichts veraendern. In realen Objekten empfiehlt sich zumindest eine
+       // Pruefung im Vorfeld, ob eine Query-/Set-Methode gesetzt ist.
+       protected void InformWear(object pl, int silent, int all) {
+           pl->SetProp(P_LIGHT_MODIFIER, pl->QueryProp(P_LIGHT_MODIFIER) -1);
+       }
+
+       protected void InformUnwear(object pl, int silent, int all) {
+           pl->SetProp(P_LIGHT_MODIFIER, pl->QueryProp(P_LIGHT_MODIFIER) +1);
+       }
+
+SIEHE AUCH
+----------
+::
+
+    P_TOTAL_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
+
diff --git a/doc/sphinx/props/P_LIGHT_TRANSPARENCY.rst b/doc/sphinx/props/P_LIGHT_TRANSPARENCY.rst
new file mode 100644
index 0000000..72fe6c0
--- /dev/null
+++ b/doc/sphinx/props/P_LIGHT_TRANSPARENCY.rst
@@ -0,0 +1,30 @@
+P_LIGHT_TRANSPARENCY
+====================
+
+NAME
+----
+::
+
+    P_LIGHT_TRANSPARENCY             "light_transparency"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container.h
+
+BESCHREIBUNG
+------------
+::
+
+    Wieviel Licht schluckt ein Container, d.h. wieviel Licht dringt aus
+    einem Behaelter noch nach draussen. Bei Containern die _nicht_
+    transparent sind, liefert eine _query_method hier immer 999 zurueck.
+    Defaultmaessig steht diese Property auf 2.
+
+SIEHE AUCH
+----------
+::
+
+    P_TOTAL_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
+
diff --git a/doc/sphinx/props/P_LIGHT_TYPE.rst b/doc/sphinx/props/P_LIGHT_TYPE.rst
new file mode 100644
index 0000000..38021ce
--- /dev/null
+++ b/doc/sphinx/props/P_LIGHT_TYPE.rst
@@ -0,0 +1,106 @@
+P_LIGHT_TYPE
+============
+
+NAME
+----
+::
+
+    P_LIGHT_TYPE                       "light_type"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt an, was fuer ein Licht in einem Objekt vorherrscht. 
+
+    
+
+    Es sind verschiedene 'atomare' Lichttypen, vordefiniert:
+    LT_MISC         Unbestimmt, keine Angaben.
+
+    LT_SUN          Sonnenlicht.
+    LT_MOON         Mondlicht 
+    LT_STARS        Sternenlicht.
+
+    
+
+    LT_DIFFUSE      Indirektes Tageslicht. (z.B. im Wald)
+
+    LT_CANDLE       Kerzenlicht.
+    LT_TORCH        Fackelschein.
+    LT_OPEN_FIRE    Sonstiges offenes Feuer. (Lagerfeuer etc.)
+
+    
+
+    LT_MAGIC        Irgendeine magische Lichtquelle.
+
+    LT_GLOWING      Eine selbstleuchtende Lichtquelle.
+
+    LT_DARKNESS     Kein wirkliches Licht, aber auch Dunkelheit soll
+                    explizit gesetzt werden koennen.
+
+    In einem Objekt koennen mehrere Lichttypen gesetzt werden. Dies
+    geschieht durch logische Oder-Verknuepfungen, siehe man operators.
+
+    Wenn in einem Raum mehr als ein Lichttyp gesetzt ist, bedeutet das, 
+    normalerweise, dass mehrere Lichtquellen verschiedenen Typs im Raum 
+    sind.
+
+    Es gibt zudem noch Lichttypen, die zusammengesetzt sind:
+
+    LT_DAYLIGHT    Tageslicht (Sonne/Diffuse)
+    LT_NATURAL     Natuerliches Licht (Daylight/Sterne/Mond)
+    LT_ARTIFICIAL  Kuenstliches Licht (Magie/Feuer/Gluehen)
+    LT_FIRE        Feuer (Kerzen/Fackeln/offenes Feuer)
+
+BEISPIELE
+---------
+::
+
+    Ein Objekt soll ein geheimnisvolles Gluehen von sich geben:
+
+    
+
+    objekt->SetProp( P_LIGHT_TYPE, LT_GLOWING )
+
+    Soll ein Raum beschrieben werden, der durch Sternenlicht erhellt ist,
+    in dem aber zusaetzlich noch ein Lagerfeuer brennt, sieht die Syntax
+    folgendermassen aus:
+
+    
+
+    raum->SetProp( P_LIGHT_TYPE, LT_STARS|LT_OPEN_FIRE );
+
+    Einer brennenden Hose kann der Lichttyp fuer offenes Feuer mitgegeben 
+    werden. Es muss jedoch nicht zwingend der Lichttyp fuer magische
+    Lichtquellen benutzt werden. Es ist klar, dass es irgendwas mit Magie
+    zu tun hat, wenn brennende Spieler durch die Gegend laufen, ohne zu 
+    schreien. P_LIGHT_TYPE sollte jedoch das fassbare Licht beschreiben.
+    LT_MAGIC ist also eher eine Notloesung fuer Licht, dessen Ursache man
+    nicht erklaeren kann.
+
+ANMERKUNG
+---------
+::
+
+    P_LIGHT_TYPE dient ausschliesslich der Beschreibung des Lichtes, das 
+    vorherrscht. Es ist nicht verbunden mit dem Lichtsystem, und soll es
+    auch nicht werden.
+
+    Die Empfindlichkeit der Dunkelelfen gegen Sonnenlicht wird ueber diese
+    Property gesteuert. Soll ein Raum mit (P_INDOORS==0) so dunkel sein, dass
+    sie nicht in Gefahr sind, sollten nicht LT_MISC oder LT_SUN gesetzt
+    sein.
+
+SIEHE AUCH
+----------
+::
+
+    CheckLightType, /std/thing/description.h, operators
+
diff --git a/doc/sphinx/props/P_LIQUID.rst b/doc/sphinx/props/P_LIQUID.rst
new file mode 100644
index 0000000..e764287
--- /dev/null
+++ b/doc/sphinx/props/P_LIQUID.rst
@@ -0,0 +1,21 @@
+P_LIQUID
+========
+
+NAME
+----
+::
+
+    P_LIQUID                      "w_max_wasserfuellmenge"      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/fishing.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_LOCALCMDS.rst b/doc/sphinx/props/P_LOCALCMDS.rst
new file mode 100644
index 0000000..f558c45
--- /dev/null
+++ b/doc/sphinx/props/P_LOCALCMDS.rst
@@ -0,0 +1,25 @@
+P_LOCALCMDS
+===========
+
+NAME
+----
+::
+
+    P_LOCALCMDS                   "localcmds"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Ein Array von Arrays aller Befehle die im Spieler selbst definiert sind.
+    ({ ({ "befehl", "funktion", flag, wizlevel }) })
+    Wenn flag gesetzt ist werden nur die ersten Zeichen die auch in Befehl
+    angegeben sind mit dem Verb ueberprueft. Siehe auch
+    add_action("funktion", "befehl", 1) und AddCmd("befehl", "funktion", 1).
+
diff --git a/doc/sphinx/props/P_LOCATION.rst b/doc/sphinx/props/P_LOCATION.rst
new file mode 100644
index 0000000..13e37b9
--- /dev/null
+++ b/doc/sphinx/props/P_LOCATION.rst
@@ -0,0 +1,39 @@
+P_LOCATION
+==========
+
+NAME
+----
+::
+
+    P_LOCATION                   "location"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+    Hier kann der Spieler mit dem Befehl "ort" den Ort setzen,
+    von dem er kommt bzw. zu kommen glaubt ;)
+    Um wieder den automatisch ermittelten Ort anzuzeigen, ist
+    P_LOCATION auf 0 zu setzen.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+    ort
+
+
+Last modified: Sat Jul 01 23:16:00 2000 by Mupfel
+
+    
+
+    
+
diff --git a/doc/sphinx/props/P_LOG_INFO.rst b/doc/sphinx/props/P_LOG_INFO.rst
new file mode 100644
index 0000000..71a44f1
--- /dev/null
+++ b/doc/sphinx/props/P_LOG_INFO.rst
@@ -0,0 +1,55 @@
+P_LOG_INFO
+==========
+
+NAME
+----
+::
+
+    P_LOG_INFO                    "log_info"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn diese Property gesetzt ist wird jede Frage, die ein
+     Monster nicht beantworten kann, im Report-File des
+     zustaendigen Magiers geloggt.
+
+     Es ist jedoch auch moeglich, direkt einen Filenamen anzugeben.
+     Bei diesen wird dann jedoch automatisch ein /log/ vorne angehaengt.
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_LOG_INFO,1);           // Alle fehlenden Infos dieses
+                                         Monsters werden in das Report-
+                                         File unter /log/report/ gelogt.
+
+     SetProp(P_LOG_INFO,"tilly/opa"); // Alle fehlenden Infos dieses
+                                         Monsters werden in das File
+                                         monster unter /log/tilly/ ge-
+                                         logt.
+
+BEMERKUNGEN
+-----------
+::
+
+     Bei nachtraeglich angeschlossenen Monstern empfiehlt sich Variante 
+     2 der Beispiele. Ein muehsames Suchen (und Loeschen) der fehlenden 
+     Infos des Monsters im Report-File eruebrigt sich dann naemlich.
+
+SIEHE AUCH
+----------
+::
+
+     P_LOG_FILE, write_file(), log_file(), AddInfo
+
+Letzte Aenderung: 13.09.04 Tilly@MorgenGrauen
+
diff --git a/doc/sphinx/props/P_LONG.rst b/doc/sphinx/props/P_LONG.rst
new file mode 100644
index 0000000..04b0404
--- /dev/null
+++ b/doc/sphinx/props/P_LONG.rst
@@ -0,0 +1,49 @@
+P_LONG
+======
+
+NAME
+----
+::
+
+     P_LONG					"long"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Die Langbeschreibung des Objektes als String oder Closure (diese muss
+     einen String zurueckgeben). Die Langbeschreibung wird beim Untersuchen
+     des Objektes ausgegeben. Sie sollte umgebrochen sein.
+
+     Diese Property bestimmt die Ansicht des Objektes von aussen. Fuer die
+     Innen(lang)ansicht von Raeumen muss man P_INT_LONG benutzen.
+
+BEMERKUNGEN
+-----------
+::
+
+     - long() ("untersuche") filtert P_LONG durch process_string()
+       -> daher sind Closures moeglich
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_LONG, "Diese Axt ist eine furchtbare Waffe!\n");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	P_SHORT, long()
+     Sonstiges:		P_INT_LONG, process_string(), break_string()
+
+
+Last modified: Sun May 19 20:10:18 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_LONG_EMPTY.rst b/doc/sphinx/props/P_LONG_EMPTY.rst
new file mode 100644
index 0000000..ea94fe5
--- /dev/null
+++ b/doc/sphinx/props/P_LONG_EMPTY.rst
@@ -0,0 +1,21 @@
+P_LONG_EMPTY
+============
+
+NAME
+----
+::
+
+    P_LONG_EMPTY                  "w_longdesc_empty"            
+
+DEFINIERT IN
+------------
+::
+
+    /sys/fishing.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_LONG_FULL.rst b/doc/sphinx/props/P_LONG_FULL.rst
new file mode 100644
index 0000000..ab623e0
--- /dev/null
+++ b/doc/sphinx/props/P_LONG_FULL.rst
@@ -0,0 +1,21 @@
+P_LONG_FULL
+===========
+
+NAME
+----
+::
+
+    P_LONG_FULL                   "w_longdesc_full"             
+
+DEFINIERT IN
+------------
+::
+
+    /sys/fishing.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_MAGIC.rst b/doc/sphinx/props/P_MAGIC.rst
new file mode 100644
index 0000000..ec394f1
--- /dev/null
+++ b/doc/sphinx/props/P_MAGIC.rst
@@ -0,0 +1,21 @@
+P_MAGIC
+=======
+
+NAME
+----
+::
+
+    P_MAGIC                       "magic"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Dieses Objekt ist magisch.
+
diff --git a/doc/sphinx/props/P_MAGIC_RESISTANCE_OFFSET.rst b/doc/sphinx/props/P_MAGIC_RESISTANCE_OFFSET.rst
new file mode 100644
index 0000000..a1be37e
--- /dev/null
+++ b/doc/sphinx/props/P_MAGIC_RESISTANCE_OFFSET.rst
@@ -0,0 +1,52 @@
+P_MAGIC_RESISTANCE_OFFSET
+=========================
+
+NAME
+----
+::
+
+     P_MAGIC_RESISTANCE_OFFSET                     "mag_res_offset"                     
+
+DEFINIERT IN
+------------
+::
+
+     /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mapping mit ganzzahligen Prozentwerten in 0.01%-Schritten
+     (0-10000) zur Resistenz/Empfindlichkeit gegen bestimmte
+     Magieklassen.
+
+     Die Property wird in der Methode SpellDefend() ausgewertet und
+     fuer einen auf den NPC/Spieler gesprochenen Spell werden die
+     Werte fuer all dessen Magieklassen aufaddiert. Daher sind auch
+     negative Werte fuer einzelne Magieklassen sinnvoll.
+
+     P_MAGIC_RESISTANCE_OFFSET und SpellDefend werden von den Spellbooks
+     ausgewertet. Der Einfluss ist daher abhaengig vom Spellbook.
+
+BEISPIELE
+---------
+::
+
+     // Goblins
+     SetProp(P_MAGIC_RESISTANCE_OFFSET,
+               ([MT_ANGRIFF:600,         // 6% Resistenz gegen Angriff
+	         MT_ILLUSION:500,        // 6% Resistenz gegen Illusionen
+                 MT_VERWANDLUNG:-300,    // 3% Empfindlichkeit
+		 MT_HELLSICHT:-750,      // 7.5% Empfindlichkeit
+		 MT_BEHERRSCHUNG:250])); // 2.5% Resistenz
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt:     SpellDefend
+     Aehnlich:     P_NOMAGIC
+
+29.Dez 2007 Gloinson
+
diff --git a/doc/sphinx/props/P_MAILADDR.rst b/doc/sphinx/props/P_MAILADDR.rst
new file mode 100644
index 0000000..4a680bf
--- /dev/null
+++ b/doc/sphinx/props/P_MAILADDR.rst
@@ -0,0 +1,21 @@
+P_MAILADDR
+==========
+
+NAME
+----
+::
+
+    P_MAILADDR                    "mailaddr"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     EMailadresse des Spielers.
+
diff --git a/doc/sphinx/props/P_MAP_RESTRICTIONS.rst b/doc/sphinx/props/P_MAP_RESTRICTIONS.rst
new file mode 100644
index 0000000..51cefec
--- /dev/null
+++ b/doc/sphinx/props/P_MAP_RESTRICTIONS.rst
@@ -0,0 +1,57 @@
+P_MAP_RESTRICTIONS
+==================
+
+NAME
+----
+::
+
+    P_MAP_RESTRICTIONS                      "lib_p_map_restrictions"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/rooms.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Property laesst sich beeinflussen, welche Informationen ueber
+     den Raum das Morgengrauen dem Client zukommen laesst (zur Zeit nur via
+     GMCP, aber es mag irgendwann auch andere Wege geben).
+     Beispielsweise sollen vielleicht in einem Labyrinth keine eindeutigen
+     Raum-IDs uebermittelt werden.
+
+     Als Werte duerfen alle MR_-Konstanten aus <rooms.h> verwendet werden.
+     Diese duerfen auch ver-ODER-t werden, wenn mehr als eine davon gelten
+     soll.
+
+     Moegliche Werte:
+       MR_NOUID - verhindert, dass die eindeutige Raum-ID uebertragen wird.
+       MR_NOINFO - verhindert, dass ueberhaupt irgendetwas an den Client
+                   uebermittelt wird. Damit kriegt er ggf. auch nicht mit,
+                   dass er Raum gewechselt wurde. Ist fuer Sequenzraeume
+                   gedacht. Bitte SEHR sparsam einsetzen.
+
+     Die Verwendung dieser Property sollte der Ausnahmefall sein!
+
+BEISPIEL
+--------
+::
+
+     (in einem Raum)
+     SetProp(P_MAP_RESTRICTIONS, MR_NOUID);
+
+     Nun bekommt der Client zwar die Kurzbeschreibung des Raums, die Region
+     und die sichtbaren Ausgaenge, aber keine UID mehr uebermittelt.
+
+SIEHE AUCH
+----------
+::
+
+     gmcp
+
+
+23.02.2013, Zesstra
+
diff --git a/doc/sphinx/props/P_MARRIED.rst b/doc/sphinx/props/P_MARRIED.rst
new file mode 100644
index 0000000..5a1e040
--- /dev/null
+++ b/doc/sphinx/props/P_MARRIED.rst
@@ -0,0 +1,28 @@
+P_MARRIED
+=========
+
+NAME
+----
+::
+
+    P_MARRIED                     "married"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Enthaelt einen String mit der uid des Partners
+     (sofern vorhanden)
+
+SIEHE AUCH
+----------
+::
+
+     scheidung
+
diff --git a/doc/sphinx/props/P_MATERIAL.rst b/doc/sphinx/props/P_MATERIAL.rst
new file mode 100644
index 0000000..1223b56
--- /dev/null
+++ b/doc/sphinx/props/P_MATERIAL.rst
@@ -0,0 +1,99 @@
+P_MATERIAL
+==========
+
+NAME
+----
+::
+
+     P_MATERIAL					"material"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/material.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Mapping mit prozentualen Anteilen von Materialien, aus denen ein Objekt 
+     besteht.
+
+BEMERKUNGEN
+-----------
+::
+
+     Bei SetProp kann man zu Vereinfachung auch ein einzelnes Material oder 
+     ein Array aus Materialien angeben. Die Anteile werden dann 
+     gleichmaessig verteilt.
+
+BEISPIELE
+---------
+::
+
+     // 100% Eis
+     SetProp(P_MATERIAL, MAT_ICE);
+     // QueryProp(P_MATERIAL) -> ([MAT_ICE:100])
+
+     // 50% Eis, 50% Misc-Holz
+     SetProp(P_MATERIAL, ({ MAT_ICE, MAT_MISC_WOOD }));
+     // QueryProp(P_MATERIAL) -> ([MAT_ICE:50, MAT_MISC_WOOD: 50])
+
+     // 60% Eis, 40% Misc-Holz
+     SetProp(P_MATERIAL, ([ MAT_ICE: 60, MAT_MISC_WOOD: 40 ]));
+
+     // 100% Papier
+     SetProp(P_MATERIAL, MAT_PAPER);
+     // QueryProp(P_MATERIAL) -> ([MAT_PAPER:100])
+
+     // 50% Silber, 50% Gold
+     SetProp(P_MATERIAL, ({MAT_SILVER, MAT_GOLD}))
+     // QueryProp(P_MATERIAL) -> ([MAT_SILVER:50,MAT_GOLD:50])
+
+     // ein weiser Schmied, der was daraus macht:
+     int i;
+     string *mat, mname, mgroup;
+     mat=m_indices(ob->QueryProp(P_MATERIAL));
+     i=sizeof(mat);
+
+     write("Der Schmied sagt: "+ob->Name(WER)+" besteht aus ...\n");
+     while(i--) {
+      // den Namen erkennen/aussprechen:
+      // Materialien werden allgemein ganz schlecht erkannt (zu 5%), aber
+      // alles aus Metall wird zu +100% gut erkannt ...
+      mname=MATERIALDB->MaterialName(mat[i], WER,
+	     ({5, ([MATERIAL_SYMMETRIC_RECOGNIZABILITY:
+			({MATGROUP_METAL, 100})])}));
+
+      // und nur Metalle analysieren ...
+      if(MATERIALDB->MaterialGroup(([mat[i]:100]),MATGROUP_METAL)>=100) {
+       int j;
+       string *mgr;
+       mgr=MATERIALDB->GetMatMembership(mat[i]);
+       j=sizeof(mgr);
+       mgroup=" gehoert zu ";
+       while(j--) {
+        mgroup+=MATERIALDB->GroupName(mgr[j]);
+        if(j>0) mgroup+=", ";
+       }
+      } else mgroup=" kenne ich nicht";
+      printf("%-12.12s: %s\n",mname, mgroup);
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: /sys/thing/material.h
+     Methoden:    QueryMaterial(), QueryMaterialGroup(), MaterialList(),
+     Listen:	  AllMaterials(), AllGroups(), Dump()
+		  materialliste, materialgruppen
+     Master:	  AddMaterial(), ConvMaterialList(), MaterialGroup(),
+		  GroupName(), MaterialName(),
+		  GetGroupMembers(), GetMatMembership()
+     Sonstiges:	  P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_MATERIAL_KNOWLEDGE.rst b/doc/sphinx/props/P_MATERIAL_KNOWLEDGE.rst
new file mode 100644
index 0000000..e8ba8a3
--- /dev/null
+++ b/doc/sphinx/props/P_MATERIAL_KNOWLEDGE.rst
@@ -0,0 +1,56 @@
+P_MATERIAL_KNOWLEDGE
+====================
+
+NAME
+----
+::
+
+     P_MATERIAL_KNOWLEDGE				"material_knowledge"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/material.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Mapping, Closure oder Integer mit Regeln zur Materialienerkennung. Die
+     Regeln sind in "man materialerkennung" zu lesen.
+
+     Diese werden bei Angabe eines Spielerobjektes in MaterialList() oder
+     MaterialName() an diesem abgefragt und hat Einfluss darauf, ob ein
+     Material genau, generell oder gar nicht erkannt wird.
+
+     In den einzelnen Rassenshells sind Defaultwerte dafuer angegeben.
+
+BEISPIELE
+---------
+::
+
+     // Erkennungsbonus auf diverse Materialgruppen und
+     // Erkennungsbonus/-malus auf biologische/nichtbiologische Materialien
+     SetProp(P_MATERIAL_KNOWLEDGE,
+	([MATGROUP_WOOD:20,
+	  MATGROUP_METAL:20,
+	  MATGROUP_ELEMENTAL:20,
+	  MATGROUP_CLOTH:20,
+	  MATERIAL_SYMMETRIC_RECOGNIZABILITY: ({MATGROUP_BIO,5})]));
+
+SIEHE AUCH
+----------
+::
+
+     Konzepte:	  material, materialerkennung
+     Grundlegend: P_MATERIAL, /sys/thing/material.h
+     Methoden:    QueryMaterial(), QueryMaterialGroup(), MaterialList(),
+     Listen:	  AllMaterials(), AllGroups(), Dump()
+		  materialliste, materialgruppen
+     Master:	  AddMaterial(), ConvMaterialList(), MaterialGroup(),
+		  GroupName(), MaterialName(),
+		  GetGroupMembers(), GetMatMembership()
+
+7. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_MAX_ALCOHOL.rst b/doc/sphinx/props/P_MAX_ALCOHOL.rst
new file mode 100644
index 0000000..9289522
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_ALCOHOL.rst
@@ -0,0 +1,40 @@
+P_MAX_ALCOHOL
+=============
+
+NAME
+----
+::
+
+	P_MAX_ALCOHOL			"max_alcohol"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+	Numerischer Wert fuer den maximalen Grad der Betrunkenheit eines
+	Lebewesens.
+
+ANMERKUNGEN
+-----------
+::
+
+	Der Wert von P_MAX_ALCOHOL ist bei den einzelnen Rassen verschieden,
+	ebenso wie der fuer P_ALCOHOL_DELAY. Die genauen Werte stehen in den
+	Rassen-Shells (/std/shells).
+
+SIEHE AUCH
+----------
+::
+
+	P_ALCOHOL, P_ALCOHOL_DELAY, drink_alcohol,
+	P_MAX_FOOD, P_MAX_DRINK
+
+
+Last modified: Tue Dec 18 12:16:10 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_MAX_DRINK.rst b/doc/sphinx/props/P_MAX_DRINK.rst
new file mode 100644
index 0000000..a637902
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_DRINK.rst
@@ -0,0 +1,40 @@
+P_MAX_DRINK
+===========
+
+NAME
+----
+::
+
+	P_MAX_DRINK			"max_drink"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+	Numerischer Wert fuer die maximale Saettigung eines Lebewesens mit
+	Getraenken.
+
+ANMERKUNGEN
+-----------
+::
+
+	Der Wert von P_MAX_DRINK ist bei den einzelnen Rassen verschieden,
+	ebenso wie der fuer P_DRINK_DELAY. Die genauen Werte stehen in den
+	Rassen-Shells (/std/shells).
+
+SIEHE AUCH
+----------
+::
+
+	P_DRINK, P_DRINK_DELAY, drink_soft,
+	P_MAX_FOOD, P_MAX_ALCOHOL
+
+
+Last modified: Tue Dec 18 12:16:10 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_MAX_FOOD.rst b/doc/sphinx/props/P_MAX_FOOD.rst
new file mode 100644
index 0000000..bfe87b4
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_FOOD.rst
@@ -0,0 +1,39 @@
+P_MAX_FOOD
+==========
+
+NAME
+----
+::
+
+	P_MAX_FOOD			"max_food"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+	Numerischer Wert fuer die maximale Saettigung eines Lebewesens.
+
+ANMERKUNGEN
+-----------
+::
+
+	Der Wert von P_MAX_FOOD ist bei den einzelnen Rassen verschieden, 
+	ebenso wie der fuer P_FOOD_DELAY. Die genauen Werte stehen in den
+	Rassen-Shells (/std/shells).
+
+SIEHE AUCH
+----------
+::
+
+	P_FOOD, P_FOOD_DELAY, eat_food,
+	P_MAX_DRINK, P_MAX_ALCOHOL
+
+
+Last modified: Tue Dec 18 12:16:10 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_MAX_HANDS.rst b/doc/sphinx/props/P_MAX_HANDS.rst
new file mode 100644
index 0000000..911fe3a
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_HANDS.rst
@@ -0,0 +1,45 @@
+P_MAX_HANDS
+===========
+
+NAME
+----
+::
+
+     P_MAX_HANDS                   "max_hands"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der Haende, die ein Wesen hat.
+
+BEMERKUNGEN
+-----------
+::
+
+     An dieser Propertie sollte bei Spielern nur im Rahmen der
+     Gilden 'gespielt' werden.
+
+     Fuer Magier, die in ihren Npc gerne alle Properties setzen,
+     gilt folgendes:
+
+                  Setzt diese Propertie NIE auf 0 !
+
+     Ohne Haende wird kein Npc irgendeinen Spieler angreifen koennen.
+
+SIEHE AUCH
+----------
+::
+
+     P_HANDS, P_HANDS_USED_BY
+     P_USED_HANDS, P_FREE_HANDS
+     UseHands, FreeHands
+
+1.Feb.2004 Gloinson
+
diff --git a/doc/sphinx/props/P_MAX_HP.rst b/doc/sphinx/props/P_MAX_HP.rst
new file mode 100644
index 0000000..3e23b46
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_HP.rst
@@ -0,0 +1,30 @@
+P_MAX_HP
+========
+
+NAME
+----
+::
+
+    P_MAX_HP                      "max_hp"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Maximale Anzahl der Lebenspunkte.
+
+SIEHE AUCH
+----------
+::
+
+     Props:	P_HP
+     Verwandt:	UpdateAttributes()
+
+21.April 2006 Gloinson
+
diff --git a/doc/sphinx/props/P_MAX_OBJECTS.rst b/doc/sphinx/props/P_MAX_OBJECTS.rst
new file mode 100644
index 0000000..3761d71
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_OBJECTS.rst
@@ -0,0 +1,44 @@
+P_MAX_OBJECTS
+=============
+
+NAME
+----
+::
+
+    P_MAX_OBJECTS                  "max_objects"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container.h
+
+BESCHREIBUNG
+------------
+::
+
+     Maximale Anzahl an Objekten, die in einen Container passen.
+     P_MAX_OBJECTS sollte im Normfall zwischen 0 - 100 liegen.
+
+BEMERKUNGEN
+-----------
+::
+
+     Soll es sich um einen herausragenden Container handeln, der zum
+     Beispiel das Gewicht um mehr als 50% reduziert, sollte P_MAX_OBJECTS
+     einen kleineren Wert haben. Das Verhaeltnis von P_MAX_WEIGHT,
+     P_WEIGHT_PERCENT und dieser Property sollte stimmen.
+
+BEISPIELE
+---------
+::
+
+     Als Beispiel sollte man sich das Postpaket ansehen und sich an dessen
+     Werten orientieren (/p/service/loco/obj/parcel).
+
+SIEHE AUCH
+----------
+::
+
+     P_MAX_WEIGHT, P_WEIGHT_PERCENT, P_LIGHT_TRANSPARENCY, container
+
diff --git a/doc/sphinx/props/P_MAX_PASSENGERS.rst b/doc/sphinx/props/P_MAX_PASSENGERS.rst
new file mode 100644
index 0000000..d85ce26
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_PASSENGERS.rst
@@ -0,0 +1,22 @@
+P_MAX_PASSENGERS
+================
+
+NAME
+----
+::
+
+    P_MAX_PASSENGERS              "maxpass"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+     Numerischer Wert fuer die maximale Anzahl von Wesen in dem Transporter.
+     0 bedeutet unbeschaenkte Spielerzahl.
+
diff --git a/doc/sphinx/props/P_MAX_POISON.rst b/doc/sphinx/props/P_MAX_POISON.rst
new file mode 100644
index 0000000..65739b2
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_POISON.rst
@@ -0,0 +1,21 @@
+P_MAX_POISON
+============
+
+NAME
+----
+::
+
+    P_MAX_POISON                  "max_poison"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Maximale Vergiftung
+
diff --git a/doc/sphinx/props/P_MAX_SP.rst b/doc/sphinx/props/P_MAX_SP.rst
new file mode 100644
index 0000000..2269cd2
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_SP.rst
@@ -0,0 +1,30 @@
+P_MAX_SP
+========
+
+NAME
+----
+::
+
+    P_MAX_SP                      "max_sp"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Maximale Anzahl der Magiepunkte.
+
+SIEHE AUCH
+----------
+::
+
+     Props:	P_SP
+     Verwandt:	UpdateAttributes()
+
+21.April 2006 Gloinson
+
diff --git a/doc/sphinx/props/P_MAX_WEIGHT.rst b/doc/sphinx/props/P_MAX_WEIGHT.rst
new file mode 100644
index 0000000..80b63af
--- /dev/null
+++ b/doc/sphinx/props/P_MAX_WEIGHT.rst
@@ -0,0 +1,38 @@
+P_MAX_WEIGHT
+============
+
+NAME
+----
+::
+
+    P_MAX_WEIGHT                  "max_weight"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container.h
+
+BESCHREIBUNG
+------------
+::
+
+     Maximales Gewicht in Gramm, das in dem Container verstaut werden
+     kann.
+
+BEMERKUNGEN
+-----------
+::
+
+     Das Verhaeltnis von P_WEIGHT_PERCENT, P_MAX_OBJECTS und dieser Property
+     sollte stimmen. Eine feste Grenze gibt es nicht. Als Beispiel kann 
+     das Postpaket von Loco unter /p/servive/loco/obj herangezogen werden.
+     Bessere Werte als in diesem sollte es nicht, und wenn doch nur gut be-
+     gruendet, geben.
+
+SIEHE AUCH
+----------
+::
+
+     P_WEIGHT_PERCENT, P_MAX_OBJECTS, P_LIGHT_TRANSPARENCY, container
+
diff --git a/doc/sphinx/props/P_MESSAGE_BEEP.rst b/doc/sphinx/props/P_MESSAGE_BEEP.rst
new file mode 100644
index 0000000..90b3f72
--- /dev/null
+++ b/doc/sphinx/props/P_MESSAGE_BEEP.rst
@@ -0,0 +1,38 @@
+P_MESSAGE_BEEP
+==============
+
+NAME
+----
+::
+
+    P_MESSAGE_BEEP                        "message_beep"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wertebereich: int=0..3600 (Sekunden)
+     Wenn gesetzt wird in der Kommunikation des Spielers in den angegebenen
+     Zeitraeumen ein Signalton ausgegeben. Wird in player/comm.c in comm_beep()
+     verarbeitet.
+     Ausgabe erfolgt nur, wenn P_VISUALBELL nicht gesetzt ist.
+     Wird im Spielerobjekt gespeichert!
+
+SIEHE AUCH
+----------
+::
+
+     klingelton, ton, P_VISUALBELL, P_MESSAGE_LAST_BEEP
+
+LETZTE AENDERUNG
+----------------
+::
+
+   16. Mai 2007  Ennox
+
diff --git a/doc/sphinx/props/P_MESSAGE_PREPEND.rst b/doc/sphinx/props/P_MESSAGE_PREPEND.rst
new file mode 100644
index 0000000..ab85748
--- /dev/null
+++ b/doc/sphinx/props/P_MESSAGE_PREPEND.rst
@@ -0,0 +1,37 @@
+P_MESSAGE_PREPEND
+=================
+
+NAME
+----
+::
+
+    P_MESSAGE_PREPEND                        "message_prepend"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wertebereich: int = 0,1
+     Wenn vom Ziel eingeschaltet, wird von teile mit (_tell) und sag (_communicate) das 
+     BS_PREPEND_INDENT Flag fuer break_string genutzt, um den Indent (Sender) ggf.
+     vor dem Textblock anzuzeigen.
+     Wird im Spielerobjekt gespeichert!
+
+SIEHE AUCH
+----------
+::
+
+     grafik aus, break_string, senderwiederholung
+
+LETZTE AENDERUNG
+----------------
+::
+
+   16. Mai 2007  Ennox
+
diff --git a/doc/sphinx/props/P_MIN_STOCK.rst b/doc/sphinx/props/P_MIN_STOCK.rst
new file mode 100644
index 0000000..4bd5eec
--- /dev/null
+++ b/doc/sphinx/props/P_MIN_STOCK.rst
@@ -0,0 +1,56 @@
+P_MIN_STOCK
+===========
+
+NAME
+----
+::
+
+	P_MIN_STOCK			"min_stock"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/bank.h
+
+BESCHREIBUNG
+------------
+::
+
+	P_MIN_STOCK enthaelt die Anzahl an Objekten, die ein Lager eines
+	Ladens minimal behaelt. Standardmaessig entspricht dies 20 Objekten
+	und sollte auch nicht wesentlich erhoeht werden. Nur fuer
+	Anfaengergebiete waeren Werte zwischen 20 und 60 akzeptabel. In die
+	Berechnung der Anzahl von Objekten gehen keine Objekte ein, die im
+	Laden mittels AddFixedObject() staendig verfuegbar gemacht worden
+	sind und auch keine Objekte, die per AddItem() im Lager hinzugefuegt
+	wurden und nach jedem Reset aufgefrischt werden.
+	Bei jedem Reset wird nun aus Speicher- und Laggruenden das Lager um
+	eine bestimmte Prozentzahl an Objekten dezimiert. Entscheidend
+	dafuer ist der Wert in der Property P_STORE_CONSUME.
+	Beide hier erwaehnten Properties sollten ueberigens nur mittels
+	QueryProp/SetProp ausgelesen bzw. veraendert werden.
+
+BEISPIEL
+--------
+::
+
+	In '/std/store.c' befindet sich bereits ein gutes Beispiel, da dort
+	der Standardwert von 20 Objekten bereitgestellt wird:
+	  create()
+	  { ...
+	    SetProp(P_MIN_STOCK,20);
+	  }
+	Diesen Wert kann man in einem davon abgeleiteten eigenen Lager
+	natuerlich auch veraendern.
+
+SIEHE AUCH
+----------
+::
+
+	P_STORE_CONSUME, SetStorageRoom(), /std/store.c, /std/shop.c
+	AddItem(), RemoveItem(), AddFixedObject(), RemoveFixedObject()
+
+
+Last modified: 19-Jun-2015, Arathorn 
+
diff --git a/doc/sphinx/props/P_MMSGIN.rst b/doc/sphinx/props/P_MMSGIN.rst
new file mode 100644
index 0000000..4d4dbb4
--- /dev/null
+++ b/doc/sphinx/props/P_MMSGIN.rst
@@ -0,0 +1,22 @@
+P_MMSGIN
+========
+
+NAME
+----
+::
+
+    P_MMSGIN                      "mmsgin"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     String mit der Meldung, die beim Verlassen eines Raumes mit M_TPORT
+     an die uebrigen Anwesenden ausgegeben wird.
+
diff --git a/doc/sphinx/props/P_MMSGOUT.rst b/doc/sphinx/props/P_MMSGOUT.rst
new file mode 100644
index 0000000..762f43e
--- /dev/null
+++ b/doc/sphinx/props/P_MMSGOUT.rst
@@ -0,0 +1,22 @@
+P_MMSGOUT
+=========
+
+NAME
+----
+::
+
+    P_MMSGOUT                     "mmsgout"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     String mit der Meldung, die beim Betreten eines Raumes mit M_TPORT
+     an die uebrigen Anwesenden ausgegeben wird.
+
diff --git a/doc/sphinx/props/P_MSGIN.rst b/doc/sphinx/props/P_MSGIN.rst
new file mode 100644
index 0000000..ab7d73b
--- /dev/null
+++ b/doc/sphinx/props/P_MSGIN.rst
@@ -0,0 +1,22 @@
+P_MSGIN
+=======
+
+NAME
+----
+::
+
+    P_MSGIN                       "msgin"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     String mit der Meldung, die beim Betreten eines Raumes mit M_GO
+     an die uebrigen Anwesenden ausgegeben wird.
+
diff --git a/doc/sphinx/props/P_MSGOUT.rst b/doc/sphinx/props/P_MSGOUT.rst
new file mode 100644
index 0000000..ce046cb
--- /dev/null
+++ b/doc/sphinx/props/P_MSGOUT.rst
@@ -0,0 +1,22 @@
+P_MSGOUT
+========
+
+NAME
+----
+::
+
+    P_MSGOUT                      "msgout"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     String mit der Meldung, die beim Verlassen eines Raumes mit M_GO
+     an die uebrigen Anwesenden ausgegeben wird.
+
diff --git a/doc/sphinx/props/P_MSG_PROB.rst b/doc/sphinx/props/P_MSG_PROB.rst
new file mode 100644
index 0000000..1f0e9ea
--- /dev/null
+++ b/doc/sphinx/props/P_MSG_PROB.rst
@@ -0,0 +1,35 @@
+P_MSG_PROB
+==========
+
+NAME
+----
+::
+
+    P_MSG_PROB                    "msg_prob"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Parameter fuer die Wartezeit in Sekunden bis zur naechsten Ausgabe
+     einer Raumnachricht.
+     Wird in AddRoomMessage() explizit mitgesetzt. Koennte natuerlich von
+     einer Nachrichtenmethode auch regelmaessig geaendert werden, um
+     mehr Zufall in die Intervalle zu bringen.
+
+SIEHE AUCH
+----------
+::
+
+     LFuns:    AddRoomMessage()
+     Props:    P_ROOM_MSG, P_MSG_PROB
+     Verwandt: call_out()
+
+2.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_MUD_NEWBIE.rst b/doc/sphinx/props/P_MUD_NEWBIE.rst
new file mode 100644
index 0000000..ce6b8b8
--- /dev/null
+++ b/doc/sphinx/props/P_MUD_NEWBIE.rst
@@ -0,0 +1,31 @@
+P_MUD_NEWBIE
+============
+
+NAME
+----
+::
+
+    P_MUD_NEWBIE                      "_lib_mud_newbie" 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+    Der Spieler hat bei Erstellung des Charakters angegeben, noch nie in einem
+    Mud gespielt zu haben. In diesem Fall enthaelt die Property den
+    Zeitstempel der Charaktererstellung.
+
+    ACHTUNG: Diese Prop wird nicht gespeichert, d.h. nachdem ein solcher
+    Spieler "ende" gemacht hat oder ein Reboot erfolgte, ist diese Information
+    verloren.
+
+SIEHE AUCH
+----------
+::
+
diff --git a/doc/sphinx/props/P_MURDER_MSG.rst b/doc/sphinx/props/P_MURDER_MSG.rst
new file mode 100644
index 0000000..b7d4e9a
--- /dev/null
+++ b/doc/sphinx/props/P_MURDER_MSG.rst
@@ -0,0 +1,83 @@
+P_MURDER_MSG
+============
+
+NAME
+----
+::
+
+     P_MURDER_MSG			"murder_msg"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property kann man einen String oder eine Closure ablegen
+     dessen Wert bzw. deren Resultat beim Tod des NPCs auf dem
+     Moerder-Kanal erscheint.
+     Normalerweise ist die Property nicht gesetzt, woraufhin zufaellig
+     eine Meldung generiert wird.
+
+     Ob der Tod eines NPCs auf dem Moerder-Kanal erscheint, haengt davon ab,
+     wie oft und welche Art von NPCs in der letzten Zeit getoetet wurden. Zum
+     Beispiel ist es eher selten, dass ein schwacher NPC auf dem Kanal
+     erscheint, wenn kuerzlich viele starke NPCs getoetet wurden. Allerdings
+     kann man auf diese Regelung mittels der Property P_FORCE_MURDER_MSG
+     Einfluss nehmen.
+
+     Wird in einen String der Platzhalter %s eingefuegt, so erscheint an der
+     Stelle spaeter der Name des Moerders.
+
+BEISPIELE
+---------
+::
+
+     // Zum Beispiel koennte man ja bei einer Ratte, die getoetet wird,
+     // folgendes auf dem Moerder-Kanal ausgeben lassen:
+     SetProp(P_MURDER_MSG,
+       "Ratten aller MUDs, vereinigt euch gegen %s!");
+
+
+     // Um auch mal eine Closure zu zeigen: die Ratte koennte auch ihre
+     // Meldung erst bei ihrem Tod erstellen lassen:
+     private string moerder_meldung() {
+       return ({"Achweh!", "Au!", "Weia!"})[random(3)];
+     }
+
+     SetProp(P_MURDER_MSG, #'moerder_meldung);
+
+BEMERKUNGEN
+-----------
+::
+
+     - P_NOCORPSE:
+       Ist in dem NPC die Property P_NOCORPSE gesetzt, so wird die
+       Moerdermeldung nicht auf dem Kanal gesendet, da diese Ausgabe ueber
+       /std/corpse laeuft.
+       Will man dennoch eine Meldung, so sollte man /std/corpse im die()
+       selbst clonen, daran Identify(this_object()) rufen und das geclonte
+       Objekt wieder entsorgen.
+
+     - Closures:
+       Closures bieten sich an, wenn ein zentrales Objekt fuer mehrere NPCs
+       bestimmte Moerdermeldungen generieren soll. Dann muss nur noch bei
+       den NPCs die Closure, die auf die erstellende Methode zeigt gesetzt
+       werden.
+
+SIEHE AUCH
+----------
+::
+
+     Tod:		die(L)
+     Verwandt:		P_FORCE_MURDER_MSG
+     Todesmeldungen:	P_KILL_NAME, P_KILL_MSG, P_DIE_MSG
+			P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
+     Sonstiges:		P_CORPSE, P_NOCORPSE, /std/corpse.c
+
+30. Mai 2006, Gloinson
+
diff --git a/doc/sphinx/props/P_M_ATTR_MOD.rst b/doc/sphinx/props/P_M_ATTR_MOD.rst
new file mode 100644
index 0000000..9c20023
--- /dev/null
+++ b/doc/sphinx/props/P_M_ATTR_MOD.rst
@@ -0,0 +1,64 @@
+P_M_ATTR_MOD
+============
+
+NAME
+----
+::
+
+    P_M_ATTR_MOD                  "magic_attributes_modifier"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mapping, das die Attribute des Spielers veraendert, der diese Ruestung
+    bzw. Waffe traegt bzw. benutzt.
+
+    Zu beachten:
+    P_M_ATTR_MOD kann problemlos durch ein SetProp() gesetzt werden. Es wird
+    nur dann beruecksichtigt, wenn die Ruestung/Waffe getragen/benutzt wird.
+    Beim Tragen/Ausziehen/Zuecken/Wegstecken wird im Spieler automatisch
+    UpdateAttributes() aufgerufen.
+
+    Fuer Krankheiten etc. oder Objekte, deren *Besitz* allein schon die
+    Attribute veraendern sollen, verwendet man besser P_X_ATTR_MOD.
+
+    P_X_ATTR_MOD und P_M_ATTR_MOD duerfen einen gemeinsamen kumulierten
+    positiven Grenzwert nicht ueberschreiten. Dieser Grenzwert,
+    CUMULATIVE_ATTR_LIMIT, ist in /sys/living/attributes.h definiert.
+
+BEMERKUNGEN
+-----------
+::
+
+    Die Werte sollten moeglichst nicht dynamisch geaendert werden.
+    Wenn doch, muss mit TestLimitViolation() am Spieler auf Validitaet
+    geprueft und ggf. mit UpdateAttributes() an ihm upgedatet werden.
+
+BEISPIELE
+---------
+::
+
+    // Dem Spieler, der das Objekt benutzt, wird 2 von A_INT abgezogen und
+    // dafuer 1 auf A_STR aufaddiert.
+    SetProp(P_M_ATTR_MOD, ([A_INT:-2, A_STR:1]) );
+
+SIEHE AUCH
+----------
+::
+
+    QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+    SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+    SetTimedAttrModifier(), QueryTimedAttrModifier(),
+    DeleteTimedAttrModifier(),
+    P_X_HEALTH_MOD, P_M_HEALTH_MOD, P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS,
+    P_TIMED_ATTR_MOD, P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+02.02.2016, Gloinson
+
diff --git a/doc/sphinx/props/P_M_HEALTH_MOD.rst b/doc/sphinx/props/P_M_HEALTH_MOD.rst
new file mode 100644
index 0000000..d04d0d7
--- /dev/null
+++ b/doc/sphinx/props/P_M_HEALTH_MOD.rst
@@ -0,0 +1,64 @@
+P_M_HEALTH_MOD
+==============
+
+NAME
+----
+::
+
+     P_M_HEALTH_MOD                  "magic_health_modifier"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mapping, mit dem die maximalen Lebenspunkte und Magiepunkte eines 
+     Spielers veraendert werden, der diese Ruestung/Waffe traegt/benutzt. Im 
+     Gegensatz zu P_M_ATTR_MOD erfolgt hier jedoch keine Blockade.
+
+     Zu beachten: P_M_HEALTH_MOD kann problemlos durch ein SetProp() gesetzt 
+     werden, es wird nur beruecksichtigt, wenn die Ruestung/Waffe 
+     getragen/benutzt wird. Beim tragen/ausziehen/zuecken/wegstecken wird im 
+     Spieler automatisch UpdateAttributes() aufgerufen.
+
+     Fuer Krankheiten etc. verwendet man besser die Property P_X_HEALTH_MOD.
+
+     Bitte beachten: Die positiven Modifier werden nicht mehr 1:1 auf die
+     Lebens- und Magiepunkte draufaddiert. Stattdessen wird nur noch ein 
+     gewisser Teil dort hinzuaddiert, der mit groesserer Menge von Punkten
+     zunimmt, und im unteren Bereich grob dem Wert entspricht. Das 
+     theoretische Maximum ist insgesamt 149.
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Werte sollten moeglichst nicht dynamisch geaendert werden.
+     Wenn doch, muss mit TestLimitViolation() am Spieler auf Validitaet 
+     geprueft werden und mit UpdateAttributes() an ihm ggf. upgedatet.
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_M_HEALTH_MOD,([P_HP:5,P_SP:-5]));
+     // Dem Spieler, der das Objekt benutzt, wird P_MAX_HP um 5 erhoeht und
+     // P_MAX_SP um 5 erniedrigt.
+
+SIEHE AUCH
+----------
+::
+
+     P_X_HEALTH_MOD, P_X_ATTR_MOD, P_M_ATTR_MOD, balance
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    Fre,11.05.2007, 00:20 von Humni
+
diff --git a/doc/sphinx/props/P_NAME.rst b/doc/sphinx/props/P_NAME.rst
new file mode 100644
index 0000000..a50981f
--- /dev/null
+++ b/doc/sphinx/props/P_NAME.rst
@@ -0,0 +1,85 @@
+P_NAME
+======
+
+NAME
+----
+::
+
+     P_NAME "name"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property wird der Name eines Objektes vermerkt. Wenn der Name
+     regelmaessig dekliniert wird, reicht ein einfacher String. Wird der
+     Name unregelmaessig dekliniert, so kann man ein Array von vier Strings
+     mit dem Namen im Nominativ, Genitiv, Dativ und Akkusativ (in dieser
+     Reihenfolge) angeben.
+
+     Die Funktion name() behandelt recht viele Sonderfaelle; man sollte den
+     Namen also erst einmal in der Form eines einzelnen Strings pruefen.
+
+     Eine Sonderrolle nehmen Unit-Objekte ein: Hier kann man einen Namen
+     fuer den Singular und einen Namen fuer den Plural vergeben.
+
+     Setzt man P_NAME eines Unit-Objekts auf einen einfachen String, so wird
+     dieser als Name sowohl im Singular als auch im Plural verwendet.
+
+     Uebergibt man ein Array von Strings, so wird der erste Eintrag fuer den
+     Singular und der zweite Eintrag fuer den Plural benutzt.
+
+     Bei Unit-Objekten ist es nicht moeglich, auch noch zwischen den
+     verschiedenen Faellen zu unterscheiden.
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Property sollte nur den reinen Namen enthalten; will man dem
+     Namen noch Adjektive voranstellen, so sollte man dies mit P_NAME_ADJ
+     bewerkstelligen, also statt
+
+     SetProp(P_NAME, ({ "alter Hut", "alten Huts",
+                        "alten Hut", "alten Hut" }) );
+
+     besser
+
+     SetProp(P_NAME, "Hut");
+     SetProp(P_NAME_ADJ, "alt");
+
+     Bei Lebewesen wird lower_case(P_NAME) (bei Arrays das erste Element 
+     daraus) automatisch als LivingName gesetzt.
+
+BEISPIELE
+---------
+::
+
+     Ein regelmaessig deklinierbarer Name:
+
+     SetProp(P_NAME, "Arkshat");
+
+     Hier ein Beispiel fuer einen unregelmaessig deklinierbaren Namen:
+
+     SetProp(P_NAME, ({ "Drache", "Drachen", "Drachen", "Drachen" }));
+
+     Und schliesslich der Name eines allseits bekannten Unit-Objektes:
+
+     SetProp(P_NAME, ({ "Muenze", "Muenzen" }));
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/description.c, name(), P_NAME_ADJ, set_living_name(),
+     find_living(), find_livings()
+
+
+Last modified: 19. Okt. 2015, Arathorn. 
+
diff --git a/doc/sphinx/props/P_NAME_ADJ.rst b/doc/sphinx/props/P_NAME_ADJ.rst
new file mode 100644
index 0000000..815c9a6
--- /dev/null
+++ b/doc/sphinx/props/P_NAME_ADJ.rst
@@ -0,0 +1,74 @@
+P_NAME_ADJ
+==========
+
+NAME
+----
+::
+
+     P_NAME_ADJ "name_adj"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt ein oder mehrere Adjektive in Form eines Arrays
+     von Strings. Es ist nur der Wortstamm anzugeben! Die Adjektive werden
+     von der Funktion name() dekliniert und vor den Namen gesetzt, wirken
+     also als Aufzaehlung von Adjektiven vor dem Namen.
+
+     Die hier angegebenen Adjektive dienen nur zur Ausgabe! Soll sich das
+     Objekt auch ueber Adjektive ansprechen lassen, muss man diese mit
+     AddAdjective() uebergeben.
+
+     Soll das Objekt nur ein einzelnes Namensadjektiv besitzen, kann man dem
+     SetProp()-Aufruf auch einen String uebergeben; gespeichert wird die
+     Property aber in jedem Fall als Array.
+
+     Wenn ein Adjektiv unregelmaessig ist, kann man die vier Faelle auch
+     als Array uebergeben. Man muss dann aber Arrays schachteln, damit von den
+     mehrfachen Adjektiven unterschieden werden kann.
+
+	
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_NAME, "Hut");
+     SetProp(P_NAME_ADJ, "alt");
+
+     name(WESSEN,1)      => "des alten Huts"
+
+
+     // Zwei Adjektive, gleichrangig zu Substantiv
+     SetProp(P_NAME_ADJ, ({"alt", "gammelig"}));
+
+     name(WESSEN,1)      => "des alten, gammeligen Huts"
+
+
+     // Zwei Adjektive, erstes ist Attribut zu zweitem
+     falsch:  SetProp(P_NAME_ADJ, ({"gruen", "gestreift"}));
+              name(WESSEN,1)      => "des gruenen, gestreiften Huts"
+     richtig: SetProp(P_NAME_ADJ, ({"gruen gestreift"}));
+              name(WESSEN,1)      => "des gruen gestreiften Huts"
+
+     // Unregelmaessiges Adjektiv
+     SetProp( P_NAME_ADJ,({({"rosa","rosa","rosa","rosa"})});
+              name(WESSEN,1)         => "des rosa Huts"
+     // Ohne inneres Array haette man 4 mal rosa als Adjektiv
+     // => "des rosaen, rosaen, rosaen, rosaen Huts"
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/description.c, name(), P_NAME, DeclAdj()
+
+23.April 2007 Rumata
+
diff --git a/doc/sphinx/props/P_NEEDED_QP.rst b/doc/sphinx/props/P_NEEDED_QP.rst
new file mode 100644
index 0000000..3b084e6
--- /dev/null
+++ b/doc/sphinx/props/P_NEEDED_QP.rst
@@ -0,0 +1,31 @@
+P_NEEDED_QP
+===========
+
+NAME
+----
+::
+
+    P_NEEDED_QP                   "needed_qp"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     APs, die man fuer den Seherstatus braucht
+
+     Diese Property ist mittlerweile obsolet. Die
+     aktuell geltenden Seher-Anforderungen stehen in
+     /secure/lepmaster.h
+
+LETZTE AENDERUNG
+----------------
+::
+
+     2006-09-30, Zook.
+
diff --git a/doc/sphinx/props/P_NETDEAD_ENV.rst b/doc/sphinx/props/P_NETDEAD_ENV.rst
new file mode 100644
index 0000000..a87cf51
--- /dev/null
+++ b/doc/sphinx/props/P_NETDEAD_ENV.rst
@@ -0,0 +1,43 @@
+P_NETDEAD_ENV
+=============
+
+NAME
+----
+::
+
+    P_NETDEAD_ENV                  "netdead_env"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property kann in netztoten Spielern abgefragt werden,
+		um herauszufinden, in welchem Raum sie netztot geworden sind.
+
+		Es wird der selbe Wert zurueckgegeben, den die Mudlib benutzen
+		wuerde, um die Spieler beim reconnect wieder an den richtigen
+		ort zu bringen. Das ist normalerweise das Raumobjekt oder der
+		Dateiname des Raums (zum Beispiel so dieser ein clone war).
+
+		Bei nicht netztoten Spielern wird 0 zurueckgegeben.
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Property ist read-only.
+
+SIEHE AUCH
+----------
+::
+
+    P_NETDEAD_INFO
+
+2009-08-04 Rumata
+
diff --git a/doc/sphinx/props/P_NETDEAD_INFO.rst b/doc/sphinx/props/P_NETDEAD_INFO.rst
new file mode 100644
index 0000000..b1fc201
--- /dev/null
+++ b/doc/sphinx/props/P_NETDEAD_INFO.rst
@@ -0,0 +1,120 @@
+P_NETDEAD_INFO
+==============
+
+NAME
+----
+::
+
+    P_NETDEAD_INFO                "netdead_info"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wird im Raum X gesetzt und wirkt nur, falls dieser Raum ein '#' im
+     object_name() hat (normale Clones, zB "/room/void#10153018").
+
+     
+
+     Bei Einschlafen eines Spielers in diesem Raum werden die Werte aus
+     der Property im Spieler gespeichert (Netztoteninformationen).
+
+     Ist beim Aufwachen des Spielers das Raumobjekt X zerstoert worden, dann
+     wird bei der Blueprint von X per SetProp() die gespeicherte Information
+     gesetzt. Der Rueckgabewert des SetProp wird als Pfad zu einem Ausweich-
+     Aufwach-Raum interpretiert und der Spieler wird in dem Fall dorthin
+     bewegt.
+
+BEMERKUNGEN
+-----------
+::
+
+     Zum Clonen von Raeumen sollten Virtual Compiler benutzt werden:
+     Wird in den erzeugten Objektnamen KEIN '#' verwendet, dann ist diese
+     Property nicht sinnvoll und wird nicht verwendet. Ein ordentlicher
+     VC kann Bewegen eines Spielers in dessen alten, nicht mehr existierenden
+     Raum oder einen Ersatzraum beim Aufwachen selbst loesen.
+
+BEISPIELE
+---------
+::
+
+     // #1: geclonter Raum mit Ausweich-Aufwachraum: Klerus-Gilde
+     #include <properties.h>
+     inherit "/std/room";
+
+     
+
+     void create() {
+       ::create();
+
+       SetProp(P_NETDEAD_INFO, "/gilden/klerus");
+       SetProp(P_LIGHT, 1);
+     }
+
+     
+
+     // #2: komplexerer Beispielraum fuer P_NETDEAD_INFO-Funktionalitaet
+     // Siehe auch: /doc/beispiele/testobjekte/netdead_info_testraum.c
+     #include <properties.h>
+     inherit "/std/room";
+
+     void create() {
+       ::create();
+
+       if (clonep(this_object()))
+         // setze Informationen, die im Netztoten gespeichert werden sollen
+         Set(P_NETDEAD_INFO, random(5));
+       else
+         // Blueprint: hier kann man zu einem Cloneraum gehen
+         AddExit("cloneraum", #'create_room);
+
+       // Set-Method, um die Informationen aus P_NETDEAD_INFO beim Aufwachen
+       // in der Blueprint auswerten zu koennen
+       Set(P_NETDEAD_INFO, #'create_destiny, F_SET_METHOD);
+       SetProp(P_LIGHT, 1);
+     }
+
+     
+
+     // Raum entfernen, normalerweise so KEINE GUTE IDEE!
+     void BecomesNetDead(object pl) {
+       call_out(#'remove, 30);
+     }
+
+     // erzeuge einen Cloneraum und bewege den Spieler dahin
+     int create_room(string dir) {
+       object dest = clone_object(object_name(this_object()));
+       this_player()->move(dest, M_NOCHECK);
+       return 1;
+     }
+
+     
+
+     // Set-Method fuer P_NETDEAD_INFO: gibt Pfad zurueck
+     // benutze die Informationen aus dem jetzt aufwachenden Netztoten, um
+     // einen alternativen Aufwachraum zu ermitteln, da der Einschlafraum
+     // zerstoert ist
+     string create_destiny(mixed val) {
+       if (intp(val)) {
+         switch (val) {
+           case 0:
+             return "/d/ebene/room/PortVain/po_haf1";
+           case 1:
+             return "/gilden/klerus";
+           case 2:
+             return "/gilden/karate";
+           default:
+         }
+         return "/d/ebene/room/waldweg4";
+       }
+     }
+
+2. Jan 2012 Gloinson
+
diff --git a/doc/sphinx/props/P_NEVERDROP.rst b/doc/sphinx/props/P_NEVERDROP.rst
new file mode 100644
index 0000000..3c4b161
--- /dev/null
+++ b/doc/sphinx/props/P_NEVERDROP.rst
@@ -0,0 +1,51 @@
+P_NEVERDROP
+===========
+
+NAME
+----
+::
+
+	P_NEVERDROP			"neverdrop"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+	Objekte, welche diese Property gesetzt haben, werden beim Tod eines
+	Lebewesens nicht automatisch in die Leiche oder in den umgebenden
+	Raum (z.B. bei bei gesetztem P_NOCORPSE) transportiert.
+
+BEMERKUNGEN
+-----------
+::
+
+	Soll das Objekt vom Lebewesen nicht weggelegt werden koennen, so ist
+	die Property P_NODROP zu verwenden.
+	Beide Properties zusammen stellen sicher, dass ein Objekt nicht
+	weitergegeben werden kann.
+
+BEISPIELE
+---------
+::
+
+	Eine dauerhafte Belohnung, die auch beim Tod des Spielers bei ihm
+	verbleiben soll, setzt das so:
+	  SetProp(P_NEVERDROP,1);
+	Sollen auch Reboots ueberstanden werden, ist zusaetzlich
+	P_AUTOLOADOBJ zu setzen.
+
+SIEHE AUCH
+----------
+::
+
+	P_NODROP, P_NOGET, P_NOCORPSE, P_AUTOLOADOBJ, /std/living/life.c
+
+
+Last modified: Thu Jun 14 22:26:29 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_NEVER_CLEAN.rst b/doc/sphinx/props/P_NEVER_CLEAN.rst
new file mode 100644
index 0000000..3d50a4e
--- /dev/null
+++ b/doc/sphinx/props/P_NEVER_CLEAN.rst
@@ -0,0 +1,54 @@
+P_NEVER_CLEAN
+=============
+
+NAME
+----
+::
+
+	P_NEVER_CLEAN			" never clean "                   
+
+DEFINIERT IN
+------------
+::
+
+	/sys/rooms.h
+
+BESCHREIBUNG
+------------
+::
+
+	Normalerweise wird ein Raum nach 2 Resets zerstoert, wenn er waerend
+	dieser Zeit von keinem Lebewesen betreten wurde und wenn
+	keine REFRESH_NONE- oder REFRESH_DESTRUCT-Objekte existieren, die
+	nicht mehr im Raum vorhanden sind.
+	Mit dieser Property kann man den sogenannten Clean-Up unterbinden.
+
+BEISPIEL
+--------
+::
+
+	Der folgende Raum wird nicht mehr zerstoert, wenn er einmal geladen
+	wurde:
+	  #include <properties.h>
+	  // #include <rooms.h> ... wird schon von properties.h included!
+	  inherit "std/room";
+	  void create()
+	  { ::create();
+	    SetProp(P_SHORT,"Ein toller Raum");
+	    ...
+	    SetProp(P_NEVER_CLEAN,1);
+	    ...
+	  }
+	Man sollte die Anwendung nicht uebertreiben! Wichtig ist diese
+	Funktion zum Beispiel fuer Raeume, die gleichzeitig Masterobjekte
+	darstellen.
+
+SIEHE AUCH
+----------
+::
+
+	/std/room.c
+
+
+Last modified: Wed Feb  3 00:54:32 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_NEWSKILLS.rst b/doc/sphinx/props/P_NEWSKILLS.rst
new file mode 100644
index 0000000..066f50c
--- /dev/null
+++ b/doc/sphinx/props/P_NEWSKILLS.rst
@@ -0,0 +1,39 @@
+P_NEWSKILLS
+===========
+
+NAME
+----
+::
+
+	P_NEWSKILLS			"newskills"                   
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property sind saemtliche Skills und Spells vermerkt, die
+	das Lebewesen kennt.
+
+BEMERKUNGEN
+-----------
+::
+
+	Man sollte diese Property nicht per Hand veraendern, sondern die
+	Funktionen von "/std/living/skills.c" nutzen.
+
+SIEHE AUCH
+----------
+::
+
+	ModifySkill(), LearnSkill(), UseSkill(), /std/living/skills.c,
+	P_GUILD_SKILLS, P_SB_SPELLS
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_NEXT_DEATH_SEQUENCE.rst b/doc/sphinx/props/P_NEXT_DEATH_SEQUENCE.rst
new file mode 100644
index 0000000..eb4e85a
--- /dev/null
+++ b/doc/sphinx/props/P_NEXT_DEATH_SEQUENCE.rst
@@ -0,0 +1,68 @@
+P_NEXT_DEATH_SEQUENCE
+=====================
+
+NAME
+----
+::
+
+     P_NEXT_DEATH_SEQUENCE         "p_lib_next_death_sequence"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Im Spieler kann damit dessen eigene Todessequenz fuer den naechsten
+     Tod festgelegt werden. Nach einem Tod (egal welche Todessequenz
+     gewaehlt wurde) wird die Property geloescht und muesste neu gesetzt
+     werden.
+
+     Es gibt folgende gueltige Werte:
+     - string: Pfad zu einer eigenen Todessequenz im gueltigen Format
+     - mixed*  Eine Todessequenz im Format des Todesraumes:
+               ({<int gesamtlaenge>,
+                 ([<int index1>: <string umgebrochene Meldung1>,
+                   <int index2>: <string umgebrochene Meldung2>,
+                   ...])
+               })
+     - mapping In die Standard-Lars-Todessequenz einzufuegende Zeilen:
+               ([<int zeitindex>: <string umgebrochener Text>])
+
+BEMERKUNGEN
+-----------
+::
+
+     Eine Todessequenz eines Gegners, festgelegt ueber
+     P_ENEMY_DEATH_SEQUENCE hat Vorrang vor dieser Property.
+
+BEISPIELE
+---------
+::
+
+     // Pfad zu einer eigenen DSQ
+     SetProp(P_NEXT_DEATH_SEQUENCE,  ".../passende_dsq.txt");
+
+     // eigene DSQ im Todesraumformat:
+     SetProp(P_NEXT_DEATH_SEQUENCE,
+             ({ 2, ([1: "Der Tod entlaesst dich eilig.\n"])}));
+
+     // Einfuegen einer Meldung in die Standard-Todessequenz
+     SetProp(P_NEXT_DEATH_SEQUENCE,
+             ([5: "Du fuehlst dich etwas daemlich.\n"]));
+
+SIEHE AUCH
+----------
+::
+
+     Tod:            die(L)
+     Todesmeldungen: P_KILL_NAME, P_KILL_MSG, P_DIE_MSG, P_MURDER_MSG
+                     P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
+     Sonstiges:      P_CORPSE, P_NOCORPSE, /room/death/death_room.c
+
+10. Nov 2011 Gloinson
+
diff --git a/doc/sphinx/props/P_NEXT_DISABLE_ATTACK.rst b/doc/sphinx/props/P_NEXT_DISABLE_ATTACK.rst
new file mode 100644
index 0000000..2b2357f
--- /dev/null
+++ b/doc/sphinx/props/P_NEXT_DISABLE_ATTACK.rst
@@ -0,0 +1,52 @@
+P_NEXT_DISABLE_ATTACK
+=====================
+
+PROPERTY
+--------
+::
+
+  P_NEXT_DISABLE_ATTACK    "next_diable_attack"
+
+DEFINIERT IN 
+-------------
+::
+
+  combat.h
+
+BESCHREIBUNG
+------------
+::
+
+  Diese Property gibt an, wann der NPC das naechste Mal paralysiert
+  werden kann. Ueblicherweise wird sie automatisch beim Setzen
+  von P_DISABLE_ATTACK gesetzt. Sie gibt einen Zeitpunkt wie
+  die Funktion time() an, an dem zum ersten Mal wieder Paralyse
+  moeglich ist.
+
+  Will man einen NPC schreiben, der immer paralysierbar ist und nicht erst
+  nach einer gewissen Wartezeit nach der letzten Paralyse, laesst sich dies
+  durch eine Set-Methode auf P_NEXT_DISABLE_ATTACK erreichen:
+
+    
+
+  Set(P_NEXT_DISABLE_ATTACK, function int () {return 0;}, F_SET_METHOD);
+
+  Diese Set-Methode verhindert das Setzen von P_NEXT_DISABLE_ATTACK mittels
+  eines SetProp-Aufrufes.
+
+BEMERKUNGEN
+-----------
+::
+
+  Die Zeit zum Schutz vor erneuter Paralyse existiert absichtlich. Bitte
+  waegt sorgfaeltig ab, bevor ihr diese Property an Gegnern/Spielern
+  manipuliert.
+
+SIEHE AUCH
+----------
+::
+
+  P_DISABLE_ATTACK
+
+21.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/props/P_NOBUY.rst b/doc/sphinx/props/P_NOBUY.rst
new file mode 100644
index 0000000..fc880f0
--- /dev/null
+++ b/doc/sphinx/props/P_NOBUY.rst
@@ -0,0 +1,23 @@
+P_NOBUY
+=======
+
+NAME
+----
+::
+
+    P_NOBUY                       "nobuy"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn diese Property gesetzt ist, wird das Objekt nach einem
+     Verkauf im Laden zerstoert, damit es nicht wieder von einem Spieler
+     gekauft werden kann.
+
diff --git a/doc/sphinx/props/P_NOCORPSE.rst b/doc/sphinx/props/P_NOCORPSE.rst
new file mode 100644
index 0000000..cf45f20
--- /dev/null
+++ b/doc/sphinx/props/P_NOCORPSE.rst
@@ -0,0 +1,52 @@
+P_NOCORPSE
+==========
+
+NAME
+----
+::
+
+	P_NOCORPSE			"nocorpse"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property ist gesetzt, wenn im Todesfall kein Leichnam
+	automatisch erzeugt werden soll.
+
+BEMERKUNGEN
+-----------
+::
+
+	In diesem Fall wird die Property P_CORPSE ignoriert, mit der man
+	ein spezielles Leichenobjekt angeben kann, sofern nicht die
+	Standardleiche "/std/corpse.c" verwendet werden soll.
+	Da die Moerdermeldungen ueber ebendiese Objekt laufen, werden
+	hierbei auch keine ausgegeben.
+
+BEISPIELE
+---------
+::
+
+	Das Lebewesen soll keine Leiche hinterlassen, weil es zu Staub
+	zerfaellt:
+	  SetProp(P_DIE_MSG," zerfaellt zu Staub!\n");
+	  SetProp(P_NOCORPSE,1)
+	Es wurde auch gleich die Sterbemeldung dementsprechend gesetzt.
+
+SIEHE AUCH
+----------
+::
+
+	P_CORPSE, P_ZAP_MSG, P_DIE_MSG, P_MURDER_MSG, P_KILL_MSG,
+	P_NEVERDROP, /std/corpse.c
+
+
+Last modified: Thu Jun 14 22:26:29 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_NODRINK_MSG.rst b/doc/sphinx/props/P_NODRINK_MSG.rst
new file mode 100644
index 0000000..82a4798
--- /dev/null
+++ b/doc/sphinx/props/P_NODRINK_MSG.rst
@@ -0,0 +1,51 @@
+P_NODRINK_MSG
+=============
+
+NAME
+----
+::
+
+     P_NODRINK_MSG                 "std_food_nodrink_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn versucht wird, ein Nicht-Getraenk
+     zu trinken. Sobald eine Speise einen Wert in P_FOOD setzt, gilt es als
+     Nicht-Getraenk.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "@WEN1 kann man nicht trinken!"
+
+SIEHE AUCH
+----------
+::
+
+     P_FOOD, P_DRINK, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_NODROP.rst b/doc/sphinx/props/P_NODROP.rst
new file mode 100644
index 0000000..8c3102f
--- /dev/null
+++ b/doc/sphinx/props/P_NODROP.rst
@@ -0,0 +1,61 @@
+P_NODROP
+========
+
+NAME
+----
+::
+
+	P_NODROP			"nodrop"                      
+
+DEFINIERT IN
+------------
+::
+
+	/sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+	Ist diese Property in einem Objekt gesetzt, so kann ein Lebewesen
+	das Objekt nicht weglegen.
+	Als Standardmeldung kommt in diesem Fall beispielsweise:
+	  Du kannst <Objektname> nicht wegwerfen!
+	  Du kannst <Objektname> nicht weggeben.
+	Man kann auch eine alternative Meldung angeben, wobei selbstaendig
+	auf einen korrekten Zeilenumbruch zu achten ist.
+
+BEMERKUNGEN
+-----------
+::
+
+	Soll ein Objekt beim Tod des Lebewesens oder bei Ende eines Spielers
+	nicht in der Leiche bzw. im Raum zurueckgelassen werden, so ist
+	die Property P_NEVERDROP zu nutzen.
+	Beide Properties zusammen stellen sicher, dass ein Objekt nicht
+	weitergegeben werden kann.
+
+BEISPIELE
+---------
+::
+
+	Ein schwer zu erkaempfender Dolch koennte folgendes beinhalten,
+	um nicht weitergegeben werden zu koennen:
+	  SetProp(P_NODROP,1);
+	Informativer jedoch ist eine eigene Meldung:
+	  SetProp(P_NODROP,
+	 "Den Dolch hast Du Dir hart erkaempft, nicht wegwerfen!\n");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_NOGET, P_NEVERDROP, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG,
+                 P_TOO_MANY_MSG, P_NOINSERT_MSG, P_NOLEAVE_MSG,  
+     Erfolg:     P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
+                 P_WEAR_MSG, P_WIELD_MSG
+     Sonstiges:  replace_personal(E), /std/living/put_and_get.c
+
+
+Last modified: Thu Jun 14 22:26:29 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_NOFOOD_MSG.rst b/doc/sphinx/props/P_NOFOOD_MSG.rst
new file mode 100644
index 0000000..3276983
--- /dev/null
+++ b/doc/sphinx/props/P_NOFOOD_MSG.rst
@@ -0,0 +1,51 @@
+P_NOFOOD_MSG
+============
+
+NAME
+----
+::
+
+     P_NOFOOD_MSG                  "std_food_nofood_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung an den Konsumenten, wenn versucht wird, ein Getraenk zu essen.
+     Sobald eine Speise keinen Wert in P_FOOD und einen Wert in P_DRINK
+     setzt, gilt es als Getraenk.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "@WEN1 kann man nicht essen!"
+
+SIEHE AUCH
+----------
+::
+
+     P_FOOD, P_DRINK, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_NOGET.rst b/doc/sphinx/props/P_NOGET.rst
new file mode 100644
index 0000000..9e231fd
--- /dev/null
+++ b/doc/sphinx/props/P_NOGET.rst
@@ -0,0 +1,50 @@
+P_NOGET
+=======
+
+NAME
+----
+::
+
+	P_NOGET				"noget"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+	Ist diese Property in einem Objekt gesetzt, so kann ein Lebewesen
+	das Objekt nicht nehmen.
+	Als Standardmeldung kommt in diesem Fall beispielsweise:
+	  Du kannst <Objektname> nicht nehmen.
+	  Du kannst <Objektname> so nirgendwo reinstecken.
+	Man kann auch eine alternative Meldung angeben, wobei selbstaendig
+	auf einen korrekten Zeilenumbruch zu achten ist.
+
+BEISPIELE
+---------
+::
+
+	Ein Objekt, welches fest im Raum verankert ist, kann natuerlich
+	nicht entfernt werden, z.B. ein angebundenes Seil:
+	  SetProp(P_NOGET,"Das Seil ist fest am Baum verknotet!\n");
+	In einem Kommando zum Losknoten koennte man die Property dann
+	loeschen, um ein Wegnehmen zu ermoeglichen.
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_NODROP, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG,
+                 P_TOO_MANY_MSG, P_NOINSERT_MSG, P_NOLEAVE_MSG 
+     Erfolg:     P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
+                 P_WEAR_MSG, P_WIELD_MSG
+     Sonstiges:  replace_personal(E), /std/living/put_and_get.c
+
+
+Last modified: Thu Jun 14 22:26:29 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_NOINSERT_MSG.rst b/doc/sphinx/props/P_NOINSERT_MSG.rst
new file mode 100644
index 0000000..f7e510b
--- /dev/null
+++ b/doc/sphinx/props/P_NOINSERT_MSG.rst
@@ -0,0 +1,65 @@
+P_NOINSERT_MSG
+==============
+
+NAME
+----
+::
+
+    P_NOINSERT_MSG                      "noinsert_msg"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn
+     jemand versucht, ein Objekt in einen Behaelter zu bewegen und der
+     Behaelter dieses im PreventInsert() verhindert.
+     Die Property ist im Zielbehaelter zu setzen.
+     Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
+     so wird die Standardmeldung ausgegeben.
+     ("<Objekt> kannst Du dort nicht hineinstecken.")
+     Der String in der Property wird noch durch replace_personal()
+     verarbeitet, das zu bewegende Objekt wird als erstes, der Zielbehaelter
+     als zweites Objekt angegeben. Danach wird der String auf 78 Zeichen
+     umgebrochen.
+     Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
+     ganz.
+
+BEISPIELE
+---------
+::
+
+     1. Ein Kochtopf laesst im PreventInsert nur bestimmte Objekte zu, die zu
+     einer Suppe gehoeren. Fuer eine passende Meldung wird im Topf jetzt die
+     Property gesetzt:
+     SetProp(P_NOINSERT_MSG, "Du kannst @WEN1 nicht in den Kochtopf tun, da"
+	                     " gehoeren doch nur Suppenzutaten rein!");
+     Wenn jemand jetzt versucht, eine Muenze reinzustecken, dann wuerde
+     folgende Meldung erscheinen:
+	Du kannst die Muenze nicht in den Kochtopf tun, da gehoeren doch nur
+	Suppenzutaten rein!
+
+     2. Ein Rucksack soll in einer bestimmten Reihenfolge gepackt werden, dazu
+     kann im PreventInsert die Meldung je nach Bedarf gesetzt werden:
+     if (<objekt noch nicht an der Reihe>)
+	SetProp(P_NOINSERT_MSG, "@WEN1 solltest du erst spaeter einpacken.");
+     else if (<objekt schon im Rucksack>)
+	SetProp(P_NOINSERT_MSG, "Aber @WER1 ist doch schon eingepackt!");
+     else ...
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
+                 P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     Erfolg:     P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
+                 P_WEAR_MSG, P_WIELD_MSG
+     Sonstiges:  replace_personal(E), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/props/P_NOLEAVE_MSG.rst b/doc/sphinx/props/P_NOLEAVE_MSG.rst
new file mode 100644
index 0000000..0518409
--- /dev/null
+++ b/doc/sphinx/props/P_NOLEAVE_MSG.rst
@@ -0,0 +1,52 @@
+P_NOLEAVE_MSG
+=============
+
+NAME
+----
+::
+
+    P_NOLEAVE_MSG                      "noleave_msg"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn
+     jemand versucht, ein Objekt aus einem Behaelter zu entfernen und der
+     Behaelter dieses im PreventLeave() verhindert.
+     Die Property ist im verhindernden Behaelter zu setzen.
+     Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
+     so wird die Standardmeldung ausgegeben.
+     ("Du kannst <Objekt> nicht nehmen.")
+     Der String in der Property wird noch durch replace_personal()
+     verarbeitet, das zu bewegende Objekt wird als erstes, der verhindernde
+     Behaelter als zweites Objekt angegeben. Danach wird der String auf 78
+     Zeichen umgebrochen.
+     Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
+     ganz.
+
+BEISPIELE
+---------
+::
+
+     Nur Bierschuettler sollen eine Bierflasche aus einem Kasten nehmen
+     koennen, neben einer entsprechenden Behandlung im PreventLeave setzt man
+     dazu die Property:
+     SetProp(P_NOLEAVE_MSG, "Nur Bierschuettler duerfen das!");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
+                 P_NOINSERT_MSG, P_NODROP, P_NOGET 
+     Erfolg:     P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
+                 P_WEAR_MSG, P_WIELD_MSG
+     Sonstiges:  replace_personal(E), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/props/P_NOMAGIC.rst b/doc/sphinx/props/P_NOMAGIC.rst
new file mode 100644
index 0000000..9f31acc
--- /dev/null
+++ b/doc/sphinx/props/P_NOMAGIC.rst
@@ -0,0 +1,42 @@
+P_NOMAGIC
+=========
+
+NAME
+----
+::
+
+    P_NOMAGIC                     "nomagic"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Angabe in Prozent, mit welcher Wahrscheinlichkeit Magie fehlschlaegt.
+
+     
+
+     Fuer einen Raum ist es eine generelle Aussage, wie wahrscheinlich ein
+     Spell in ihm fehlschlaegt. Bei NPC zeigt es an, wie wahrscheinlich
+     ein auf ihn gesprochener Spell fehlschlaegt.
+
+BEISPIEL
+--------
+::
+
+     // in einem Raum keine Spells zulassen
+     SetProp(P_NOMAGIC, 100)
+
+SIEHE AUCH
+----------
+::
+
+     Aehnlich:     P_MAGIC_RESISTANCE_OFFSET, SpellDefend
+
+29.Dez 2007 Gloinson
+
diff --git a/doc/sphinx/props/P_NOSELL.rst b/doc/sphinx/props/P_NOSELL.rst
new file mode 100644
index 0000000..e716c37
--- /dev/null
+++ b/doc/sphinx/props/P_NOSELL.rst
@@ -0,0 +1,51 @@
+P_NOSELL
+========
+
+NAME
+----
+::
+
+    P_NOSELL                      "nosell"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn diese Property gesetzt ist, kann das Objekt nicht in einem
+     Laden verkauft werden.
+     Gibt man in der Property einen String an, wird dieser ausgegeben,
+     ansonsten erfolgt eine Meldung "Du kannst <NAME> nicht verkaufen!"
+
+     Diese Meldung beinhaltet auch den Namen des in P_NAME einge-
+     tragenen Besitzer des Ladens. Ist dies nicht gesetzt, wird per
+     default 'Der Haendler' ausgegeben.
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_NOSELL,"Den Schrott behaeltst Du lieber selber.");
+
+     ==> Apu sagt: Den Schrott behaeltst Du lieber selber.
+     ==> Der Haendler sagt: Den Schrott behaeltst Du lieber selber.
+
+     SetProp(P_NOSELL,1);
+
+     ==> Apu sagt: Du kannst <name> nicht verkaufen!
+     ==> Der Haendler sagt: Du kannst <name> nicht verkaufen!
+
+SIEHE AUCH
+----------
+::
+
+     P_NOBUY, P_NODROP, P_KEEPER
+
+
+03.09.2010, Zesstra
+
diff --git a/doc/sphinx/props/P_NO_ASCII_ART.rst b/doc/sphinx/props/P_NO_ASCII_ART.rst
new file mode 100644
index 0000000..5ba9bdc
--- /dev/null
+++ b/doc/sphinx/props/P_NO_ASCII_ART.rst
@@ -0,0 +1,37 @@
+P_NO_ASCII_ART
+==============
+
+NAME
+----
+::
+
+    P_NO_ASCII_ART                   "no_ascii_art"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property kann der Spieler mit dem Befehl "grafik aus" auf
+    1 setzen. Damit zeigt er an, dass er keine ASCII Art sehen moechte.
+
+    Wer ASCII-Art einsetzt, sollte an diesen Stellen die Property 
+    abfragen und textliche Umschreibungen oder Alternativloesungen
+    einbauen.
+
+    
+
+SIEHE AUCH
+----------
+::
+
+    grafik
+
+
+    Letzte Aenderung: 2005-10-18, Zook.   
+
diff --git a/doc/sphinx/props/P_NO_ATTACK.rst b/doc/sphinx/props/P_NO_ATTACK.rst
new file mode 100644
index 0000000..bd2ad4d
--- /dev/null
+++ b/doc/sphinx/props/P_NO_ATTACK.rst
@@ -0,0 +1,99 @@
+P_NO_ATTACK
+===========
+
+NAME
+----
+::
+
+     P_NO_ATTACK "no_attack"
+
+DEFINIERT IN
+------------
+::
+
+     <living/combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn ein NPC nicht angreifbar sein soll (weil er zum Beispiel in einer
+     Gilde oder einer Quest Informationen vermittelt oder aehnlichen), sollte
+     man diese Property auf einen Wert ungleich Null setzen. Sie wird immer
+     abgefragt, wenn ermittelt wird, ob ein Lebewesen prinzipiell angreifbar
+     ist. D.h. auch, dass nach Abfragen von P_NO_ATTACK _nicht_ immer ein
+     Kampf gestartet wird und dass man dabei _nicht_ im Kampf sein muss!
+
+     Gibt man hier einen String an (mit einem Satzzeichen und "\n" abge-
+     schlossen), wird dieser bei direkten Angriffen ausgegeben. Bei anderen
+     Datentypen wird eine Defaultmeldung ausgegeben. Die Defaultmeldung
+     lautet: "<Name> laesst sich nicht angreifen!\n"
+
+     Mit direkten Angriffen sind 'toete <name>' und Angriffszauber gemeint
+     (bzw. alles, was living/life::Kill(), spellbook::TryAttackSpell(),
+     spellbook::TryDefaultAttackSpell() und spellbook::FindEnemyVictim()
+     aufruft).
+
+ACHTUNG
+-------
+::
+
+  1) Zum Thema QueryMethoden auf P_NO_ATTACK
+     Grundsaetzlich legt man entweder eine Query-Methode auf P_NO_ATTACK:
+        Set(P_NO_ATTACK, #'my_no_attack, F_QUERY_METHOD);
+     oder definiert eine Funktion _query_no_attack() im NPC.
+
+     Wie muss nun eine solche Funktion aussehen? Z.B.:
+
+     
+
+     int|string my_no_attack() {
+       if (!objectp(this_player())) return 0;
+       if (opfer==getuid(this_player()) || this_player()==this_object())
+         return(0);
+       return(1); //nicht angreifbar
+     }
+
+     Diese Funktion macht den NPC nun nur fuer den Spieler 'opfer' angreifbar.
+     Stattdessen kann natuerlich auch jede andere Bedingung genutzt werden.
+
+     Aber warum die zweite Bedingung, this_player()==this_object()?
+     Warum sollte der NPC sich selber angreifen duerfen?
+
+     Das liegt an folgenden 2 Dingen:
+
+     1. Kaempfer kriegen bei eingeschaltetem Fokus Probleme, wenn man das 
+     nicht macht. Das liegt an folgendem: Wenn der NPC angreift, ruft er 
+     natuerlich Defend() im Spieler auf. Dieses schaut nach, ob der Spieler 
+     den Skill SK_MAGICAL_DEFENSE hat. Dieser ist bei Kaempfern das Parieren.
+     Dieses schaut nach, ob der Fokus aktiv ist, wenn ja, wird dem 
+     ge'fokus'te Gegner besonders gut ausgewichen. Zu diesem Zweck wird die 
+     Liste der Feind im Raum erstellt mit PresentEnemies() abgerufen. Dieses 
+     fragt aber in allen (potentiellen) Gegnern P_NO_ATTACK ab und beendet 
+     den Kampf mit allen Gegnern, die nicht angreifbar sind. Bei dieser 
+     Abfrage ist jedoch TP==NPC, weil der ja angreift. Wenn er nun 1 
+     zurueckgibt, wird der Kampf an der Stelle beendet. 
+
+     2. Wenn der NPC den Spieler angreift, wird im Spieler InsertEnemy(NPC)
+     aufgerufen. Auch diesem Fall findet die Abfrage von P_NO_ATTACK statt, 
+     da InsertEnemy() ja erstmal rausfinden muss, ob der Gegner angreifbar 
+     ist, bevor er in die Feindliste eingetragen wird. Da der NPC den 
+     Angriff beginnt, ist TP der NPC. Wenn die Query-Methode auf P_NO_ATTACK
+     hier abbricht, wird der NPC nicht in die Feindliste des Spielers 
+     eingetragen. Dann bekaempft der NPC den Spieler, aber der Spieler nicht
+     den NPC.
+
+
+  2) P_NO_ATTACK des NPC wird z.B. beim Kampf eines Kaempfers mit dem NPC 
+     pro Kampfrunde um die 10mal abgerufen. Wenn der Kaempfer nur eine 
+     Attacke macht. Wenn er noch Sonderattacken machen, Spells ausfuehrt, 
+     etc. wird das noch mehr. D.h. was auch immer ihr in der Query-Methode 
+     im NPC macht: 
+     Es sollte schnell sein, jeder Tick an Rechenzeit zaehlt hier xfach!
+
+LETZTE AENDERUNG
+----------------
+::
+
+09.11.2015, Arathorn
+
diff --git a/doc/sphinx/props/P_NO_BAD.rst b/doc/sphinx/props/P_NO_BAD.rst
new file mode 100644
index 0000000..81ff011
--- /dev/null
+++ b/doc/sphinx/props/P_NO_BAD.rst
@@ -0,0 +1,46 @@
+P_NO_BAD
+========
+
+NAME
+----
+::
+
+     P_NO_BAD                      "std_food_no_bad"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Flag, ob die Speise ewig haltbar ist.
+     0: Speise verdirbt nach der Anzahl Sekunden, die in P_LIFETIME
+        angegeben ist bzw. nach einem Reset
+     1: Speise verdirbt nicht
+
+     
+
+     ACHTUNG: Diese Property darf nur in Absprache mit der Balance
+              geaendert werden.
+
+     
+
+DEFAULT
+-------
+::
+
+     Initial ist diese Property auf 0 gesetzt.
+
+SIEHE AUCH
+----------
+::
+
+     /std/food.c, wiz/food
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_NO_GLOBAL_ATTACK.rst b/doc/sphinx/props/P_NO_GLOBAL_ATTACK.rst
new file mode 100644
index 0000000..a77ee9b
--- /dev/null
+++ b/doc/sphinx/props/P_NO_GLOBAL_ATTACK.rst
@@ -0,0 +1,34 @@
+P_NO_GLOBAL_ATTACK
+==================
+
+NAME
+----
+::
+
+     P_NO_GLOBAL_ATTACK "no_global_attack"
+
+DEFINIERT IN
+------------
+::
+
+     <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Setzt man diese Property in einem NPC auf einen Wert ungleich 0, so
+     wird der NPC bei einem "toete alle" nicht angegriffen.
+
+     Damit kann man zB. NPCs, die dem eigenen Schutz dienen (als Folge von
+     Zauberspruechen o.ae.) vor versehentlichen Angriffen schuetzen.
+
+SIEHE AUCH
+----------
+::
+
+     /std/npc.c, P_FRIEND
+
+
+Last modified: Sat May 18 15:26:28 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_NO_PARA_TRANS.rst b/doc/sphinx/props/P_NO_PARA_TRANS.rst
new file mode 100644
index 0000000..59f71d1
--- /dev/null
+++ b/doc/sphinx/props/P_NO_PARA_TRANS.rst
@@ -0,0 +1,30 @@
+P_NO_PARA_TRANS
+===============
+
+NAME
+----
+::
+
+	P_NO_PARA_TRANS				"no_para_trans"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+	Wenn in einem Raum diese Property gesetzt ist, darf dort kein
+	Wechsel in oder aus der Paralellwelt erfolgen. Objekte die so
+	einen Wechsel ermoeglichen sind dafuer verantwortlich diese
+	Property abzufragen.
+
+SIEHE AUCH
+----------
+::
+
+	P_NO_TPORT
+
diff --git a/doc/sphinx/props/P_NO_PLAYERS.rst b/doc/sphinx/props/P_NO_PLAYERS.rst
new file mode 100644
index 0000000..de235ed
--- /dev/null
+++ b/doc/sphinx/props/P_NO_PLAYERS.rst
@@ -0,0 +1,56 @@
+P_NO_PLAYERS
+============
+
+NAME
+----
+::
+
+    P_NO_PLAYERS                     "no_players"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/rooms.h
+
+BESCHREIBUNG
+------------
+::
+
+    Wenn in einem Raum die Property P_NO_PLAYERS auf einen Wert != 0 gesetzt
+    ist, kann dieser von Spielern auf normalem Wege nicht mehr betreten werden.
+    Magier und Testspieler(*) koennen den Raum betreten; Spieler muessen mit
+    M_NOCHECK hineinbewegt werden.
+
+    Auf diese Weise koennen Gebiete, die noch nicht offiziell angeschlossen
+    sind, vor 'unbeabsichtigtem' Betreten durch Spieler geschuetzt werden.
+
+    Moechte man zu einem schon angeschlossenen Gebiet nachtraeglich eine
+    Parallelwelt einbauen, so sollte P_NO_PLAYERS *dringend* in den
+    Parallelweltraeumen gesetzt werden, bis die Parallelwelt ausdruecklich
+    fuer Spieler freigegeben wird. Andernfalls sind alle Parallelweltraeume,
+    zu denen angeschlossene Normalweltraeume mit gleichem Filenamen existieren,
+    automatisch durch Spieler erreichbar!
+
+    (*) Ausschliesslich Testspieler, die auf den Namen eines existierenden
+    Magiers markiert sind, koennen 'geschuetzte' Raeume betreten.
+    Gildentesties werden wie Spieler behandelt.
+
+ANMERKUNG
+---------
+::
+
+    Im Gegensatz zu Bewegungen von Livings wird bei der Bewegung von Gegen-
+    staenden P_NO_PLAYERS nur beim Wechsel der Welt ausgewertet, um z.B. zu
+    verhindern, dass Bumerangs in noch nicht angeschlossene Gebiete fliegen.
+
+    Moechte man in seinem eigenen Gebiet mit Bumerangs o.ae. testen, muss
+    in diesen P_TESTPLAYER gesetzt sein. Das ist zwar eher ein Missbrauch
+    der Property, aber ein Umkompieren vom Werfer war auf Dauer zu teuer. ;-)
+
+SIEHE AUCH
+----------
+::
+
+    P_PARA, move
+
diff --git a/doc/sphinx/props/P_NO_REGENERATION.rst b/doc/sphinx/props/P_NO_REGENERATION.rst
new file mode 100644
index 0000000..9940f13
--- /dev/null
+++ b/doc/sphinx/props/P_NO_REGENERATION.rst
@@ -0,0 +1,53 @@
+P_NO_REGENERATION
+=================
+
+NAME
+----
+::
+
+     P_NO_REGENERATION    "no_regeneration"
+
+DEFINIERT IN
+------------
+::
+
+     <living/life.h> und <health.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Durch das Setzen dieser Property kann man verhindern, das ein Lebewesen
+     sich regeneriert.
+     Es gibt sieben moegliche Werte, die man durch verodern kombinieren
+     kann:
+     NO_REG_HP        : es werden keine HP regeneriert
+     NO_REG_BUFFER_HP : es werden beim "tanken" keine HP regeneriert
+     NO_REG_SP        : es werden keine SP regeneriert
+     NO_REG_BUFFER_SP : es werden beim "tanken" keine SP regeneriert
+     NO_REG_ALCOHOL   : der Alkoholspiegel wird nicht gesenkt
+     NO_REG_DRINK     : der Fluessigkeitsspiegel wird nicht gesenkt
+     NO_REG_FOOD      : der Nahrungsspiegel wird nicht gesenkt
+     sowie die Konstante NO_REG, die eine Kombination aller moeglichen
+     Werte darstellt (quasi das groesstmoegliche Uebel ;).
+
+BEISPIELE
+---------
+::
+
+     Dieses Lebewesen heilt nur beim "tanken" in der Kneipe, ansonsten
+     nicht:
+
+     
+
+     SetProp( P_NO_REGENERATION, NO_REG_HP|NO_REG_SP );
+
+SIEHE AUCH
+----------
+::
+
+     /std/living/life.c
+
+
+Last modified: 14-05-2001 by Mupfel
+
diff --git a/doc/sphinx/props/P_NO_SCORE.rst b/doc/sphinx/props/P_NO_SCORE.rst
new file mode 100644
index 0000000..b61c75a
--- /dev/null
+++ b/doc/sphinx/props/P_NO_SCORE.rst
@@ -0,0 +1,73 @@
+P_NO_SCORE
+==========
+
+NAME
+----
+::
+
+     P_NO_SCORE               "no_score"
+
+DEFINIERT IN
+------------
+::
+
+     /secure/scoremaster.h
+
+BESCHREIBUNG
+------------
+::
+
+     Die Property stellt ein Flag innerhalb von Lebewesen dar, welches
+     standardmaessig nicht gesetzt ist. In diesem Fall werden
+     Erstkillstufenpunkte an den Angreifer vergeben, sofern er ein Opfer
+     toetet.
+
+     Innerhalb eines Teams koennen Erstkillstufenpunkte auch an
+     Mitglieder vergeben werden, die das Lebewesen nicht selbst getoetet
+     haben. Voraussetzung hierfuer ist, dass derjenige, der den letzten
+     Schlag ausfuehrte, den Kill schon hat. Danach werden Mitglieder des
+     Teams gesucht, welche den Kill noch nicht haben und in der Formation
+     moeglichst weit vorne stehen.
+
+     Mit der gesetzten Property P_NO_SCORE im Opfer erreicht man nun,
+     dass diese Gutschrift fuer den/die Angreifer unterbunden wird.
+
+BEISPIEL
+--------
+::
+
+     Folgendermassen unterbindet man die Vergabe von
+     Erstkillstufenpunkten fuer den Tod eines NPC's:
+
+       include "/secure/scoremaster.h"
+       inherit "std/npc";
+       void create() {
+         ::create();
+         ...
+         SetProp(P_NO_SCORE,1);
+       }
+
+     Damit kann P_XP einen Wert haben, der eigentlich zum automatischen
+     Eintragen von Erstkillstufenpunkten fuer ein Lebewesen fuehrt, und
+     trotzdem wird dieser Eintrag nicht vorgenommen.
+     Sinnvoll ist dies insbesondere bei Lebewesen, die nicht jeder
+     Spieler erreichen kann (man moechte doch eine gewisse
+     Chancengleichheit fuer das Erreichen von Stufenpunkten bieten).
+
+BEMERKUNGEN
+-----------
+::
+
+     Auch die Vergabe von Erfahrungspunkten kann explizit unterbunden
+     werden. Hierfuer gibt es die aehnlich geartete Property P_NO_XP.
+
+SIEHE AUCH
+----------
+::
+
+     Funktionen:  GiveKillScore(), do_damage()
+     Verwandt:    P_NO_XP
+     Sonstiges:   P_XP
+
+14.Feb 2007 Gloinson
+
diff --git a/doc/sphinx/props/P_NO_STD_DRINK.rst b/doc/sphinx/props/P_NO_STD_DRINK.rst
new file mode 100644
index 0000000..926de9c
--- /dev/null
+++ b/doc/sphinx/props/P_NO_STD_DRINK.rst
@@ -0,0 +1,38 @@
+P_NO_STD_DRINK
+==============
+
+NAME
+----
+::
+
+	P_NO_STD_DRINK			"no_std_drink"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/pub.h
+
+BESCHREIBUNG
+------------
+::
+
+        Durch setzen dieser Property in einer Kneipe sorgt man dafuer, dass 
+        "Standard-Drinks" (z.B. Gluehwein im Dezember) nicht in das Menue
+        der Kneipe aufgenommen werden.
+
+BEMERKUNGEN
+-----------
+::
+
+        Keine.
+
+SIEHE AUCH
+----------
+::
+
+	/std/room/pub.c
+
+
+Last modified: Sat Mar 04 22:42:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/props/P_NO_TPORT.rst b/doc/sphinx/props/P_NO_TPORT.rst
new file mode 100644
index 0000000..5161f0f
--- /dev/null
+++ b/doc/sphinx/props/P_NO_TPORT.rst
@@ -0,0 +1,30 @@
+P_NO_TPORT
+==========
+
+NAME
+----
+::
+
+    P_NO_TPORT                    "tport"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Kann folgende Werte annnehmen (definiert in moving.h):
+     NO_TPORT_IN	= Man kann nicht in den Raum hinein teleportieren.
+     NO_TPORT_OUT = Man kann nicht aus dem Raum hinaus teleportieren.
+     NO_TPORT	= Weder noch.
+
+SIEHE AUCH
+----------
+::
+
+	P_NO_PARA_TRANS
+
diff --git a/doc/sphinx/props/P_NO_TRAVELING.rst b/doc/sphinx/props/P_NO_TRAVELING.rst
new file mode 100644
index 0000000..be63938
--- /dev/null
+++ b/doc/sphinx/props/P_NO_TRAVELING.rst
@@ -0,0 +1,50 @@
+P_NO_TRAVELING
+==============
+
+NAME
+----
+::
+
+    P_NO_TRAVELING                   "no_traveling"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+    Hier steht der allgemeine reise-Befehl nicht zur Verfuegung.
+
+BEMERKUNGEN
+-----------
+::
+
+    P_NO_TRAVELING wird in Transportern gesetzt wenn Spieler ihn 
+    nicht mehr 'automatisch' mittels des 'reise'-Befehls betreten
+    koennen sollen.
+
+    Sie bekommen in dem Transporter und in den Zielraeumen auch 
+    keinerlei Hinweise darauf, wohin sie evtl. reisen koennten.
+
+    
+
+    Standardmaessig ist P_NO_TRAVELING natuerlich 0.
+
+SIEHE AUCH
+----------
+::
+
+    reise
+
+LETZTER AENDERUNG
+-----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
+    
+
diff --git a/doc/sphinx/props/P_NO_XP.rst b/doc/sphinx/props/P_NO_XP.rst
new file mode 100644
index 0000000..0405a0b
--- /dev/null
+++ b/doc/sphinx/props/P_NO_XP.rst
@@ -0,0 +1,65 @@
+P_NO_XP
+=======
+
+NAME
+----
+::
+
+     P_NO_XP                    "no_xp"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Im Normalfall bekommt man im Kampf gegen einen Gegner fuer Treffer
+     und beim Toeten eine XP-Gutschrift.
+
+     Ist P_NO_XP gesetzt, so erhaelt man keinerlei XP-Gutschriften
+     fuer den Kampf oder den Tod des NPCs.
+
+BEISPIEL
+--------
+::
+
+     Folgendermassen unterbindet man die Vergabe von Erfahrungspunkte
+     fuer den Angriff eines NPC's:
+
+       include "/sys/living/life.h"
+       inherit "std/npc";
+       void create() {
+         ::create();
+         ...
+         SetProp(P_NO_XP,1);
+       }
+
+     Damit kann P_XP trotzdem einen Wert im NPC haben, der
+     Erstkillstufenpunkte fuer Lebewesen automatisch eintraegt!
+
+     Auch fuer das kurzzeitige Unterbinden der Vergabe von
+     Erfahrungspunkten ist diese Property sinnvoller, als P_XP im NPC
+     auf 0 zu setzen.
+
+BEMERKUNGEN
+-----------
+::
+
+     Auch die Vergabe von Erstkillstufenpunkten kann explizit unterbunden
+     werden. Hierfuer gibt es die aehnlich geartete Property P_NO_SCORE.
+
+SIEHE AUCH
+----------
+::
+
+     Funktionen:  AddExp(), DistributeExp(), do_damage()
+     Properties:  P_XP, P_LAST_XP
+     Verwandt:    P_NO_SCORE
+     Sonstiges:   P_TOTAL_WC, create_default_npc()
+
+14.Feb 2007 Gloinson
+
diff --git a/doc/sphinx/props/P_NPC.rst b/doc/sphinx/props/P_NPC.rst
new file mode 100644
index 0000000..9f2b1e3
--- /dev/null
+++ b/doc/sphinx/props/P_NPC.rst
@@ -0,0 +1,21 @@
+P_NPC
+=====
+
+NAME
+----
+::
+
+    P_NPC                         "is_npc"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gesetzt bei Monstern.
+
diff --git a/doc/sphinx/props/P_NPC_FASTHEAL.rst b/doc/sphinx/props/P_NPC_FASTHEAL.rst
new file mode 100644
index 0000000..b9bb65d
--- /dev/null
+++ b/doc/sphinx/props/P_NPC_FASTHEAL.rst
@@ -0,0 +1,40 @@
+P_NPC_FASTHEAL
+==============
+
+NAME
+----
+::
+
+	P_NPC_FASTHEAL			"npc_fastheal"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/pub.h
+
+BESCHREIBUNG
+------------
+::
+
+        Durch setzen dieser Property in einer Kneipe sorgt man dafuer, dass 
+        bei NPCs, die dort "tanken", die Lebens- und Konzentrationspunkte
+        direkt erhoeht werden und nicht, wie bei ungesetzter Property, in
+        die jew. Buffer geschrieben werden.
+
+BEMERKUNGEN
+-----------
+::
+
+        Die Benutzung dieser Property sollte nicht unbedingt zum Standard
+        werden.
+
+SIEHE AUCH
+----------
+::
+
+	/std/room/pub.c
+
+
+Last modified: Wed Sep 29 13:58:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/props/P_NR_HANDS.rst b/doc/sphinx/props/P_NR_HANDS.rst
new file mode 100644
index 0000000..2182ed3
--- /dev/null
+++ b/doc/sphinx/props/P_NR_HANDS.rst
@@ -0,0 +1,46 @@
+P_NR_HANDS
+==========
+
+NAME
+----
+::
+
+     P_NR_HANDS "nr_hands"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Wieviele Haende muss man frei haben, um die Waffe zuecken oder den
+     Schild tragen zu koennen?
+     Dieser Wert muss mindestens 1 betragen!
+
+     Sollen Spieler die Waffe benutzen koennen, so sind hier nur die Werte 1
+     und 2 moeglich. Falls die Waffe nur von Monstern benutzbar sein soll,
+     kann man hier auch hoehere Werte eintragen (dazu muss man beim Monster
+     P_MAX_HANDS entsprechend hoch setzen). Als Beispiel sei hier nur das
+     vierhaendige Schwert aus dem Friedhof genannt.
+
+     Defaultmaessig sind alle Waffen Zweihaender.
+
+     Diese Property kann auch bei Zaubern benutzt werden, bei denen man eine
+     oder mehrere Haende frei haben muss.
+
+SIEHE AUCH
+----------
+::
+
+     P_HANDS, P_HANDS_USED_BY
+     P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
+     UseHands, FreeHands
+     /std/weapon.c, /std/spellbook.c
+
+
+Last modified: Sun May 19 15:00:02 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_ORAKEL.rst b/doc/sphinx/props/P_ORAKEL.rst
new file mode 100644
index 0000000..ca412f3
--- /dev/null
+++ b/doc/sphinx/props/P_ORAKEL.rst
@@ -0,0 +1,22 @@
+P_ORAKEL
+========
+
+NAME
+----
+::
+
+    P_ORAKEL                      "orakel"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn diese Property gesetzt ist, kann der Wanderer in diesen
+     Raum hinein.
+
diff --git a/doc/sphinx/props/P_ORIG_FILE_NAME.rst b/doc/sphinx/props/P_ORIG_FILE_NAME.rst
new file mode 100644
index 0000000..f7220e1
--- /dev/null
+++ b/doc/sphinx/props/P_ORIG_FILE_NAME.rst
@@ -0,0 +1,21 @@
+P_ORIG_FILE_NAME
+================
+
+NAME
+----
+::
+
+    P_ORIG_FILE_NAME                "original_object_name"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     In einer Leiche der Filename des Gestorbenen.
+
diff --git a/doc/sphinx/props/P_ORIG_NAME.rst b/doc/sphinx/props/P_ORIG_NAME.rst
new file mode 100644
index 0000000..8361ae8
--- /dev/null
+++ b/doc/sphinx/props/P_ORIG_NAME.rst
@@ -0,0 +1,21 @@
+P_ORIG_NAME
+===========
+
+NAME
+----
+::
+
+    P_ORIG_NAME                   "original_name"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     In einer Leiche der Name des Gestorbenen. (name(RAW))
+
diff --git a/doc/sphinx/props/P_PARA.rst b/doc/sphinx/props/P_PARA.rst
new file mode 100644
index 0000000..aecb22d
--- /dev/null
+++ b/doc/sphinx/props/P_PARA.rst
@@ -0,0 +1,75 @@
+P_PARA
+======
+
+NAME
+----
+::
+
+    P_PARA                        "para"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Nummer der Parallelwelt, in der sich ein Spieler befindet.
+
+    Ist die Property P_PARA auf Null gesetzt, so befindet sich der Spieler in
+    der 'Normalwelt'. Gibt es bei einer Bewegung dieses Spielers mehrere
+    moegliche Zielraeume mit identischem Namen aber unterschiedlichen Endungen
+    'name.c', 'name^1.c', 'name^2.c' etc., so wird der Spieler in den Raum
+    'name.c' bewegt. 
+
+    Wird die Property P_PARA auf einen Wert n>0 gesetzt, so landet der Spieler
+    bei einer Bewegung im Raum 'name^n.c'. Ist kein Raum mit entsprechender
+    Endung vorhanden, wird der Spieler stattdessen in den Normalweltraum
+    bewegt.
+
+    Diese Prop kann auch in einem Virtual Compiler gesetzt werden. In diesem
+    Fall schraenkt sie die Dimensionen ein, in denen der VC Objekte erzeugt.
+    Die Prop kann eine einzelne Ziffer (Int) oder ein Array von Ints 
+    aufnehmen, dann ist der VC fuer alle angegeben Dimensionen zustaendig. 
+    Ein leeres Array erlaubt gar keine Para-Objekte.
+
+ANMERKUNG
+---------
+::
+
+    Die Endung '^0' kennzeichnet _nicht_ die Normalwelt. So lange kein Ausgang
+    explizit auf den Raum 'name^0.c' verweist, wird kein Spieler den Raum
+    betreten koennen. Deshalb kann man die Endung '^0' z.B. dazu benutzen, um
+    eigene Standardraeume fuer ein Gebiet zu schreiben, die dann sowohl von
+    den Normal- als auch von den Parallelweltraeumen inheritet werden.
+
+    Raeume mit Endungen '^n.c', bei denen 'n' keine positive ganze Zahl ist,
+    werden nicht beachtet.
+
+    Fuer die Entscheidung, in welchem Raum ein Spieler in Abhaengigkeit von
+    P_PARA landet, ist die Funktion move() zustaendig. Als Magier muss man sich
+    darum nicht gesondert kuemmern. Das heisst aber auch, dass beim Anschluss
+    eines Normalweltraumes automatisch alle in dem Verzeichnis mit gleichem
+    Namen vorhandenen Parallelweltraeume mit angeschlossen werden.
+
+    Sollen einzelne Parallelweltraeume noch nicht angeschlossen werden, so muss
+    in ihnen die Property P_NO_PLAYERS gesetzt werden. Diese Raeume sind dann
+    nur durch Magier und Testspieler zu betreten (und zu testen).
+
+    In Paraweltraeumen liefert P_PARA 'n' zurueck.
+    Man kann also z.B. in NPCs einfach ueber environment()->QueryProp(P_PARA) 
+    abfragen, in welcher Parawelt sich dieser gerade befindet.
+
+SIEHE AUCH
+----------
+::
+
+    P_NO_PLAYERS, move, pararaeume
+
+    
+
+25.Jan 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_PARRY.rst b/doc/sphinx/props/P_PARRY.rst
new file mode 100644
index 0000000..ffda4f8
--- /dev/null
+++ b/doc/sphinx/props/P_PARRY.rst
@@ -0,0 +1,48 @@
+P_PARRY
+=======
+
+NAME
+----
+::
+
+     P_PARRY "parry"
+
+DEFINIERT IN
+------------
+::
+
+     <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property legt fest, inwiefern eine Waffe als Parierwaffe
+     genutzt werden kann. Moegliche Werte:
+
+         PARRY_NOT     Eine reine Angriffswaffe ohne Parierfunktion.
+
+         PARRY_TOO     Eine kombinierte Angriffs- und Parierwaffe.
+
+         PARRY_ONLY    Eine reine Parierwaffe. Diese kann zusaetzlich
+                       zu einer normalen Waffe gezueckt werden.
+
+     Man sollte nur die in <combat.h> definierten Konstanten verwenden.
+
+BEMERKUNGEN
+-----------
+::
+
+     Durch diese Propertie laesst sich _kein_ Parade-Bonus fuer Trves 
+     setzen! Alle Gilden haben etwas davon. Vor Verwendung bitte mit
+     der Objekt-Balance absprechen.
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon/combat.c
+
+
+Last modified: Sat Jun 01 13:28:45 2001 by Tilly
+
diff --git a/doc/sphinx/props/P_PARRY_WEAPON.rst b/doc/sphinx/props/P_PARRY_WEAPON.rst
new file mode 100644
index 0000000..499bade
--- /dev/null
+++ b/doc/sphinx/props/P_PARRY_WEAPON.rst
@@ -0,0 +1,31 @@
+P_PARRY_WEAPON
+==============
+
+NAME
+----
+::
+
+     P_PARRY_WEAPON "parry_weapon"
+
+DEFINIERT IN
+------------
+::
+
+     <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property gibt an, welche Parierwaffe ein Spieler derzeit
+     gezueckt hat.
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon/combat.c, /std/living/combat.c
+
+
+Last modified: Sat Jun 26 15:23:00 1999 by Paracelsus
+
diff --git a/doc/sphinx/props/P_PEACE_HISTORY.rst b/doc/sphinx/props/P_PEACE_HISTORY.rst
new file mode 100644
index 0000000..e4e36a5
--- /dev/null
+++ b/doc/sphinx/props/P_PEACE_HISTORY.rst
@@ -0,0 +1,62 @@
+P_PEACE_HISTORY
+===============
+
+NAME
+----
+::
+
+     P_PEACE_HISTORY      "_peace_history"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Prop wird nach Gilden getrennt gespeichet, wie oft das Lebewesen
+    in letzter Zeit befriedet worden ist. Diese Information geht in die
+    Chance auf eine zukuenftige Befriedung ein.
+    Die Zaehler werden im Durchschnitt alle 2700s um 2-3 reduziert.
+    Die Datenstruktur ist ein Array, welches einen Zeitstempel als erstes
+    Element und ein Mapping als zweites enthaelt. Das Mapping enthaelt unter
+    den Gildennamen als Keys den ganzzahligen Zaehler erfolgreicher
+    Befriedungen von Spielern dieser Gilde.
+
+BEMERKUNGEN
+-----------
+::
+
+    * Diese Property sollte niemals direkt geaendert werden. Bitte greift also
+      nur lesend darauf zu. Sollte hiermit Schindluder getrieben werden,
+      werden die Daten vor externer Aenderung geschuetzt.
+    * Die Datenstruktur in dieser Prop kann in Zukunft u.U. geaendert werden.
+      Daher aendert sie am besten auch nicht im eigenen NPC oder seid darauf
+      gefasst, irgendwann Hand anlegen zu muessen.
+    * Die Aktualisierung (auch die Reduktion) findet im Zuge eines
+      QueryPacify() statt, nicht im Reset des Lebewesens.
+
+BEISPIEL
+--------
+::
+
+    In P_PEACE_HISTORY steht:
+    ({1209654597, (["zauberer": 3, "klerus": 4]) })
+    Bei der Berechnung der naechsten Befriede-Chance gehen bei Zauberern also
+    3 erfolgreiche Versuche, bei Klerikern 4 erfolgreiche Versuche ein.
+    Der Zeitwert an erster Stelle des Arrays wird der bei der Berechnung der
+    naechsten Reduktion der Zaehler beruecksichtigt. (Genaues: s. combat.c)
+
+SIEHE AUCH
+----------
+::
+
+     P_PEACE_ACCEPT
+     QueryPacify()
+     /std/living/combat.c
+
+01.05.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_PERM_STRING.rst b/doc/sphinx/props/P_PERM_STRING.rst
new file mode 100644
index 0000000..86a7c20
--- /dev/null
+++ b/doc/sphinx/props/P_PERM_STRING.rst
@@ -0,0 +1,24 @@
+P_PERM_STRING
+=============
+
+NAME
+----
+::
+
+    P_PERM_STRING                 "perm_string"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+     Fuer Sprachflueche, Property ist im Spieler-Objekt zu setzen. In dem
+     Objekt, das in P_PERM_STRING gespeichert ist, wird bei Sprachbefehlen
+     permutate_string(str) aufgerufen und der zurueckgegebene String 
+     stattdessen ausgegeben.
+
diff --git a/doc/sphinx/props/P_PICK_MSG.rst b/doc/sphinx/props/P_PICK_MSG.rst
new file mode 100644
index 0000000..e96333e
--- /dev/null
+++ b/doc/sphinx/props/P_PICK_MSG.rst
@@ -0,0 +1,78 @@
+P_PICK_MSG
+==========
+
+NAME
+----
+::
+
+     P_PICK_MSG				"pick_message"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/put_and_get.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mit P_PICK_MSG kann man die Meldung, die man beim Aufnehmen eines
+     Objektes bekommt, modifizieren.
+
+     Folgende Werte sind moeglich:
+
+     o 0
+       Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
+
+     o NO_PNG_MSG       == -1
+       Es wird keinerlei Meldung ausgegeben
+
+     o Ein Array aus Strings
+       Der erste String wird an den Spieler ausgegeben, der zweite
+       (optionale) an den Raum.
+
+       Die Strings werden durch die Funktion replace_personal() geparst.
+	Objekt1 - Spieler
+        Objekt2 - das Objekt, das genommen wird
+
+       Wird der zweite String nicht angegeben, erfolgt keine Meldung an den
+       Raum.
+
+BEISPIEL
+--------
+::
+
+     void create() {
+      ...
+      SetProp( P_SHORT, "Etwas Sand" );
+      SetProp( P_LONG, break_string(
+       "Ein wenig magischer Sand. Sehr feinkruemelig.",78 ));
+
+      SetProp( P_NAME, "Sand" );
+      AddId( ({"sand"}) );
+      SetProp( P_GENDER, MALE );
+
+      SetProp( P_PICK_MSG, ({
+       "Du schaufelst @WEN2 in deine Hand.",
+       "@WER1 schaufelt @WEN2 in eine Hand."}));
+      ...
+     }
+
+     Das ganze fuehrt bei Ugars "nimm sand" zu folgenden
+     Meldungen:
+
+     Ugar: "Du schaufelst den Sand in deine Hand."
+     Raum: "Ugar schaufelt den Sand in eine Hand."
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_WEAR_MSG, P_WIELD_MSG
+     Fehler:     P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
+                 P_NOINSERT_MSG, P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     Sonstiges:  replace_personal(E), pick_obj(L), /std/living/put_and_get.c
+
+14. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_PILE_NAME.rst b/doc/sphinx/props/P_PILE_NAME.rst
new file mode 100644
index 0000000..cb801e0
--- /dev/null
+++ b/doc/sphinx/props/P_PILE_NAME.rst
@@ -0,0 +1,22 @@
+P_PILE_NAME
+===========
+
+NAME
+----
+::
+
+    P_PILE_NAME                   "file_name"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     In einer Leiche der Name des Gestorbenen im Dativ. (name(WEM))
+     Wird vom Haufen benoetigt.
+
diff --git a/doc/sphinx/props/P_PLAYER_LIGHT.rst b/doc/sphinx/props/P_PLAYER_LIGHT.rst
new file mode 100644
index 0000000..7148267
--- /dev/null
+++ b/doc/sphinx/props/P_PLAYER_LIGHT.rst
@@ -0,0 +1,44 @@
+P_PLAYER_LIGHT
+==============
+
+NAME
+----
+::
+
+    P_PLAYER_LIGHT                       "player_light"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt den Lichtlevel an, mit dem ein Lebewesen sieht, ein Abfragen dieser
+    Property kann z.B. sinnvoll sein wenn man abfragen will ob ein Spieler
+    genug Licht dabei hat um ein bestimmtes Detail untersuchen zu koennen.
+
+    Bitte _nur_ ueber QueryProp auf diese Property zugreifen,
+    da das Lichtlevel ggf. neu berechnet werden muss!
+
+    Ein direktes setzen dieser Property ist NICHT moeglich. Es ist jedoch
+    moeglich entweder eine Closure zu benutzen oder den Wert ueber einen
+    P_LIGHT_MODIFIER zu veraendern.
+
+    Um zu erreichen, das ein NPC Nachtsicht bekommt, gibt es nun 3 Varianten.
+    - eine closure:
+        Set(P_PLAYER_LIGHT, function int () {return 1;} , F_QUERY_METHOD) 
+      dieses bedeutet, dass der NPC in jeder Dunkelheit perfekt sehen kann.
+    - das setzen von einem P_LIGHT_MODIFIER
+    - das benutzen des stdskills. Hierzu schreibt man in das create() des
+      NPCs einfach ein: ModifySkill(SK_NIGHTVISION, 10000);
+
+SIEHE AUCH
+----------
+::
+
+    P_LIGHT_MODIFIER, P_LIGHT, P_TOTAL_LIGHT, P_INT_LIGHT, CannotSee()
+
diff --git a/doc/sphinx/props/P_PLURAL.rst b/doc/sphinx/props/P_PLURAL.rst
new file mode 100644
index 0000000..c246d38
--- /dev/null
+++ b/doc/sphinx/props/P_PLURAL.rst
@@ -0,0 +1,58 @@
+P_PLURAL
+========
+
+NAME
+----
+::
+
+    P_PLURAL                      "plural"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/language.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mit Hilfe von P_PLURAL koennen auch nicht Unit Objekte als Pluralobjekte
+    markiert werden. Bei einem Wert > 1 wird der Wert ausserdem auch noch in
+    den Namen eingefuegt. Sollte man in eigenem Code zulassen wollen, das
+    etwas mit bestimmten Objekten geschieht, dann sollte man die Verben
+    entsprechen konjugieren.
+
+BEMERKUNGEN
+-----------
+::
+
+    Wirkt nicht auf Todesmeldungen -> siehe dafuer P_KILL_MSG
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_NAME, "Stiefel"); SetProp(P_PLURAL, 2);
+    name(WER, 1) -> "die zwei Stiefel"
+
+    SetProp(P_NAME, "Stiefel"); SetProp(P_PLURAL, 1);
+    name(WER, 1) -> "die Stiefel"
+
+    // Ein Beispiel fuer das konjugieren von Verben
+    static int cmd_opfer(string str)
+    {
+       int i;
+       object *obs;
+       notify_fail("Was moechtest Du opfern?\n");
+       if (!str || !sizeof(obs=PL->find_obs(str))) return 0;
+       for (i=sizeof(obs)-1; i>=0; i--)
+          if (obs[i]->QueryProp(P_VALUE)<=0)
+            write(obs[i]->Name(WER)+" "
+                 +(ob->QueryProp(P_PLURAL) ? "sind" : "ist")
+                 +" doch gar nichts wert.\n");
+          else obs[i]->remove();
+    }
+
+26. Juni 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_POISON.rst b/doc/sphinx/props/P_POISON.rst
new file mode 100644
index 0000000..d4700b8
--- /dev/null
+++ b/doc/sphinx/props/P_POISON.rst
@@ -0,0 +1,21 @@
+P_POISON
+========
+
+NAME
+----
+::
+
+    P_POISON                      "poison"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wie stark wir vergiftet sind (0-11)
+
diff --git a/doc/sphinx/props/P_POISON_DELAY.rst b/doc/sphinx/props/P_POISON_DELAY.rst
new file mode 100644
index 0000000..662ed10
--- /dev/null
+++ b/doc/sphinx/props/P_POISON_DELAY.rst
@@ -0,0 +1,27 @@
+P_POISON_DELAY
+==============
+
+NAME
+----
+::
+
+    P_POISON_DELAY                     "poison_delay"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der heart_beats nach denen sich die Giftwirkung erneut 
+     zeigt. Je kleiner der Wert, desto empfindlicher ist das Lebewesen
+     gegen Gift.
+     Aenderungen dieser Property in Spielern beduerfen der Genehmigung
+     des EMs fuer Balance.
+
+     
+
diff --git a/doc/sphinx/props/P_PORTIONS.rst b/doc/sphinx/props/P_PORTIONS.rst
new file mode 100644
index 0000000..5147f61
--- /dev/null
+++ b/doc/sphinx/props/P_PORTIONS.rst
@@ -0,0 +1,42 @@
+P_PORTIONS
+==========
+
+NAME
+----
+::
+
+     P_PORTIONS                    "std_food_portions"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Property steht die Anzahl der Portionen einer Speise.
+     Es duerfen nur Werte > -1 gesetzt werden. Ist diese Property 0,
+     wird die Speise als leer bzw. verbraucht angesehen und kann nicht
+     konsumiert werden.
+
+     
+
+DEFAULT
+-------
+::
+
+     Initial ist diese Property auf 1 gesetzt, die Speise ist also mit
+     einem Bissen/Schluck verbraucht bzw. leer.
+
+SIEHE AUCH
+----------
+::
+
+     /std/food.c, wiz/food
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_POST.rst b/doc/sphinx/props/P_POST.rst
new file mode 100644
index 0000000..b1435bd
--- /dev/null
+++ b/doc/sphinx/props/P_POST.rst
@@ -0,0 +1,83 @@
+P_POST
+======
+
+NAME
+----
+::
+
+	P_POST				"Post"
+
+DEFINIERT IN
+------------
+::
+
+	/mail/post.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property laesst sich die Versendeerlaubnis von Paketen
+	regeln. Hierbei gibt es zum einen die postlagernden Pakete, die man
+	in einer Post abholen muss, und es gibt die sogenannten
+	Kurierpakete, welche direkt und unmittelbar zugestellt werden.
+	Nicht immer ist es erwuenscht, dass Pakete aus der Ferne in einen
+	Raum geschickt werden duerfen. Dies duerfte insbesondere innerhalb
+	von Gebieten interessant sein, in welche man nur beschraenkt viele
+	Objekte mitfuehren kann. Mit dieser Property nun ist es leicht
+	moeglich, dies zu verbieten. Man kann auch in den Objekten selbst
+	angeben, ob diese per postlagerndem Paket bzw. Kurierpaket
+	verschickt werden duerfen. Dies duerfte zum Beispiel bei Komponenten
+	fuer Spells oder fuer Unique-Objekte interessant sein.
+	Folgende Werte sind moeglich, wobei in Raeumen und Objekten
+	Standardmaessig PP_DEFAULT genutzt wird:
+
+	  PP_FORBIDDEN		-2	// auf jeden Fall verboten
+	  PP_NO_EXPRESS		-1	// Kurierpakete verboten
+	  PP_DEFAULT		 0	// Default
+	  PP_NORMAL_ALLOWED	 1	// postlagernde Pakete erlaubt
+	  PP_ALLOWED		 2	// auf jeden Fall erlaubt
+
+	Raeume, die von /std/post.c abgeleitet wurden, nutzen als Standard
+	natuerlich PP_ALLOWED.
+
+BEISPIEL
+--------
+::
+
+	Um Kurierpakete fuer einen Raum zu verbieten, nutzt man die
+	Funktionalitaet dieser Property folgendermassen:
+
+	  include "/mail/post.h"
+	  ...
+	  void create()
+	  { ::create();
+	    ...
+	    SetProp(P_POST,PP_NO_EXPRESS);
+	    ...
+	  }
+
+	Objekte selbst koennte man folgendermassen aus Paketen verbannen,
+	welche versendet werden sollen:
+
+	  include "/mail/post.h"
+	  ...
+	  void create()
+	  { ::create();
+	    ...
+	    SetProp(P_POST,PP_FORBIDDEN);
+	    ...
+	  }
+
+	In letzterem Fall funktionieren im Gegensatz zum ersten Beispiel
+	auch keine postlagernden Pakete mehr.
+
+SIEHE AUCH
+----------
+::
+
+	/std/post.c, /std/mailcabin.c, /p/service/loco/std/mailcabin.c
+
+
+Last modified: Sun Sep  6 19:34:37 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_POTIONROOMS.rst b/doc/sphinx/props/P_POTIONROOMS.rst
new file mode 100644
index 0000000..c94ec4d
--- /dev/null
+++ b/doc/sphinx/props/P_POTIONROOMS.rst
@@ -0,0 +1,35 @@
+P_POTIONROOMS
+=============
+
+NAME
+----
+::
+
+    P_POTIONROOMS                 "potionrooms"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/potion.h
+
+BESCHREIBUNG
+------------
+::
+
+    Array mit den Nummern der Raeume, in denen der Spieler noch Zauber-
+    traenke hat. Die Freischaltung als bekannt geschieht im Orakel.
+    Die Zuordnung der Raeume und Nummern geschieht im Potionmaster.
+
+    Nur lesbare _query - Property.
+
+SIEHE AUCH
+----------
+::
+
+    Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
+    Verwandt:  FindPotion(), AddKnownPotion(), RemoveKnownPotion(), InList()
+    Props:     P_KNOWN_POTIONROOMS
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_PRAY_ROOM.rst b/doc/sphinx/props/P_PRAY_ROOM.rst
new file mode 100644
index 0000000..183e870
--- /dev/null
+++ b/doc/sphinx/props/P_PRAY_ROOM.rst
@@ -0,0 +1,54 @@
+P_PRAY_ROOM
+===========
+
+NAME
+----
+::
+
+    P_PRAY_ROOM                      "_lib_p_pray_room"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+    Dies ist der Raum, in den der Spieler nach dem Ende der Todessequenz
+    bewegt wird, d.h. ein Raum, wo er beten kann, um einen neuen Koerper zu
+    erhalten.
+    Der Raum muss als String angegeben werden (kein Objekt).
+
+    Diese Property wird im Spieler rebootfest gespeichert.
+
+    Der jeweils gueltige Betraum wird im Spieler mittels QueryPrayRoom()
+    ermittelt. Jede Rasse hat einen Default fuer diese Funktion. Wird die
+    Property auf 0 dgesetzt, wird dieser Default wiederhergestellt.
+
+    Von einer Ueberlagerung mittels Query- oder gar Setmethoden wird
+    abgeraten. Ebenso lasst bitte die Modusbits unveraendert.
+
+    Vor einer Aenderung dieser Property sollte geprueft werden, ob sie 0 ist.
+    Wenn nicht, sollte von einem Setzen der Property abgesehen werden, da dann
+    schon jemand anders den Betraum des Spielers geaendert hat. (Gleiches gilt
+    fuers Loeschen.) Bitte niemals den Inhalt der Property woanders speichern
+    und spaeter zurueckschreiben.
+
+    Eine dauerhafte Aenderung des Betraums des Spielers muss mit dem EM
+    Rassen und dem EM Gilden abgestimmt werden.
+
+SIEHE AUCH
+----------
+::
+
+    QueryPrayRoom(), SetDefaultPrayRoom()
+
+LETZTE AeNDERUNG
+----------------
+::
+
+21.05.2013, Zesstra
+
diff --git a/doc/sphinx/props/P_PREFERED_ENEMY.rst b/doc/sphinx/props/P_PREFERED_ENEMY.rst
new file mode 100644
index 0000000..67c688b
--- /dev/null
+++ b/doc/sphinx/props/P_PREFERED_ENEMY.rst
@@ -0,0 +1,42 @@
+P_PREFERED_ENEMY
+================
+
+NAME
+----
+::
+
+	P_PREFERED_ENEMY		"pref_enemy"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt ein Array mit folgenden Eintraegen:
+	  Eintrag 1:      Integerwert zwischen 0 und 100, welcher die
+	                  Wahrscheinlichkeit dafuer angibt, dass ein
+	                  Lebewesen bevorzugt bei einem Angriff gewaehlt
+	                  werden soll.
+	  Eintraege ab 2: Lebewesen, aus welchen per Zufall eines
+	                  ausgewaehlt wird, welches beim aktuellen Angriff
+	                  bevorzugt wird.
+	Es ist zu beachten, dass solch ein bevorzugtes Opfer natuerlich auch
+	wirklich Gegner sein muss und auch im selben Raum zu stehen hat, wie
+	der Angreifer. Ist dies nicht der Fall, wird dann doch irgendein
+	anderer Gegner aus diesem Raum genommen.
+
+SIEHE AUCH
+----------
+::
+
+	QueryPreferedEnemy(), IsEnemy(), SelectEnemy(), Attack(),
+	/std/living/combat.c, /std/living/life.c
+
+
+Last modified: Wed May 26 16:44:38 1999 by Patryn
+
diff --git a/doc/sphinx/props/P_PRESAY.rst b/doc/sphinx/props/P_PRESAY.rst
new file mode 100644
index 0000000..5f55be6
--- /dev/null
+++ b/doc/sphinx/props/P_PRESAY.rst
@@ -0,0 +1,22 @@
+P_PRESAY
+========
+
+NAME
+----
+::
+
+    P_PRESAY                      "presay"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Presay des Spielers. Erscheint vor dem Namen in Kurz/Langbeschreibung.
+     Erscheint auch in name(), also in sag, ruf, teile mit usw.
+
diff --git a/doc/sphinx/props/P_PREVENT_PILE.rst b/doc/sphinx/props/P_PREVENT_PILE.rst
new file mode 100644
index 0000000..54c52ee
--- /dev/null
+++ b/doc/sphinx/props/P_PREVENT_PILE.rst
@@ -0,0 +1,35 @@
+P_PREVENT_PILE
+==============
+
+NAME
+----
+::
+
+    P_PREVENT_PILE                   "prevent_pile"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Wenn in einem Raum diese Property gesetzt ist, endet das Verwesen einer
+    Leiche damit, dass ihr Inventar in dem Raum verteilt wird. Ist diese
+    Property nicht gesetzt, entsteht ein "Haufen", der das Inventar
+    enthaelt.
+
+    Diese Property sollte nur in Ausnahmefaellen benutzt werden!
+
+    Diese Property ist vor allem fuer "Store-Rooms" gedacht, in denen die
+    Magier die Leiche eines Spieler ablegen und in denen nachher die
+    gesammelten Sachen von einer anderen Stelle aus gesucht werden. In
+    diesem Fall wuerden Spieler sonst die Moeglichkeit haben, einen Haufen
+    als Ganzes zu bekommen, das soll aber *NIE* passieren.
+
+
+Last modified: Tue May 15 13:56:18 CEST 2007 by Rumata
+
diff --git a/doc/sphinx/props/P_PRE_INFO.rst b/doc/sphinx/props/P_PRE_INFO.rst
new file mode 100644
index 0000000..9efed27
--- /dev/null
+++ b/doc/sphinx/props/P_PRE_INFO.rst
@@ -0,0 +1,87 @@
+P_PRE_INFO
+==========
+
+NAME
+----
+::
+
+        P_PRE_INFO                        "npc_pre_info"
+
+DEFINIERT IN
+------------
+::
+
+        /sys/npc.h
+
+BESCHREIBUNG
+------------
+::
+
+        Ist die Property in einem NPC definiert, so wird ihr Ergebnis
+        ausgewertet, bevor eine Frage an das Infosystem uebergeben wird.
+
+        
+
+        Moegliche Werte:
+        - numerischer Wert ungleich 0
+          => der NPC gibt _keinerlei_ Antwort, die Frage fuehrt sozusagen
+             ins Leere
+
+        - Stringwert
+          => wird als Rueckgabe an den Fragenden ausgegeben, umstehende 
+             Personen bekommen den Text:
+            "XY ist nicht gewillt, Spieler YZ zu antworten".
+            Der Fragende selbst bekommt bei angegebenem Stringwert:
+            "XY " + Stringwert.
+
+        - Closure
+          => die Antwort bzw. Reaktion des NPCs obliegt ganz der 
+             angegebenen Closure. Diese muss dabei einen String oder 
+             Ganzzahlen-Wert zurueckgeben
+
+BEISPIEL
+--------
+::
+
+        Ein NPC der manchmal herumrennt, um z.B. eine Aufgabe zu verrichten,
+        koennte so lange Chats abschalten, z.B.
+
+          SetProp(P_CHAT_CHANCE,0); // NPC latscht los
+
+        
+
+        Und eine Weile spaeter:
+
+        
+
+          SetProp(P_CHAT_CHANCE,5); // NPC ruht wieder, quasselt rum
+
+        
+
+        Waehrend des Herumlaufens, also wenn er nicht automatisch schwatzt,
+        soll er auch keinerlei Fragen beantworten:
+
+          
+
+          Set(P_PRE_INFO, function mixed () {
+            return (QueryProp(P_CHAT_CHANCE) ? 0 : 
+              "hat gerade keine Zeit fuer Dich."); 
+            }, F_QUERY_METHOD);
+
+HINWEISE
+--------
+::
+
+        Bitte beachten, dass der interne Name der Property "npc_pre_info" 
+        ist und somit nur das Ueberschreiben von _query_npc_pre_info() 
+        funktioniert. 
+
+SIEHE AUCH
+----------
+::
+
+        AddInfo(), /std/npc/info.c
+
+
+Last modified: 01.03.2016 by Arathorn
+
diff --git a/doc/sphinx/props/P_PROMPT.rst b/doc/sphinx/props/P_PROMPT.rst
new file mode 100644
index 0000000..6345a77
--- /dev/null
+++ b/doc/sphinx/props/P_PROMPT.rst
@@ -0,0 +1,21 @@
+P_PROMPT
+========
+
+NAME
+----
+::
+
+    P_PROMPT                      "prompt"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Das Prompt (Nur fuer Magier).
+
diff --git a/doc/sphinx/props/P_PUB_NOT_ON_MENU.rst b/doc/sphinx/props/P_PUB_NOT_ON_MENU.rst
new file mode 100644
index 0000000..3c278a7
--- /dev/null
+++ b/doc/sphinx/props/P_PUB_NOT_ON_MENU.rst
@@ -0,0 +1,40 @@
+P_PUB_NOT_ON_MENU
+=================
+
+NAME
+----
+::
+
+	P_PUB_NOT_ON_MENU			"pub_not_on_menu"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/pub.h
+
+BESCHREIBUNG
+------------
+::
+
+        In diese Property kann man einen String schreiben, der ausgegeben
+        wird, wenn der Spieler etwas bestellt, was es in der Kneipe nicht
+        gibt.
+
+BEMERKUNGEN
+-----------
+::
+
+        Die Standardmeldung ist:
+        "Tut mir leid, das fuehren wir nicht! Wir sind ein anstaendiges
+         Lokal!\n"
+
+SIEHE AUCH
+----------
+::
+
+	/std/room/pub.c
+
+
+Last modified: Sat Mar 04 22:46:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/props/P_PUB_NO_KEEPER.rst b/doc/sphinx/props/P_PUB_NO_KEEPER.rst
new file mode 100644
index 0000000..20c3d25
--- /dev/null
+++ b/doc/sphinx/props/P_PUB_NO_KEEPER.rst
@@ -0,0 +1,38 @@
+P_PUB_NO_KEEPER
+===============
+
+NAME
+----
+::
+
+	P_PUB_NO_KEEPER				"pub_no_keeper"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/pub.h
+
+BESCHREIBUNG
+------------
+::
+
+        In diese Property kann man einen String schreiben, der ausgegeben
+        wird, wenn der in P_KEEPER eingetragene NPC nicht anwesend ist.
+
+BEMERKUNGEN
+-----------
+::
+
+        Die Standardmeldung ist:
+        "Es ist niemand anwesend, der Dich bedienen koennte.\n"
+
+SIEHE AUCH
+----------
+::
+
+	/std/room/pub.c
+
+
+Last modified: Son Apr 11 19:28:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_PUB_NO_MONEY.rst b/doc/sphinx/props/P_PUB_NO_MONEY.rst
new file mode 100644
index 0000000..31e1b17
--- /dev/null
+++ b/doc/sphinx/props/P_PUB_NO_MONEY.rst
@@ -0,0 +1,40 @@
+P_PUB_NO_MONEY
+==============
+
+NAME
+----
+::
+
+	P_PUB_NO_MONEY				"pub_no_money"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/pub.h
+
+BESCHREIBUNG
+------------
+::
+
+        In diese Property kann man einen String schreiben, der ausgegeben
+        wird, wenn der Spieler nicht ueber genug Geld verfuegt, um das
+        gewuenschte Gericht zu bezahlen.
+        Fuer den Preis kann man ein %d als Platzhalter einfuegen.
+
+BEMERKUNGEN
+-----------
+::
+
+        Die Standardmeldung ist:
+        "Das kostet %d Goldstuecke, und Du hast nicht so viel!\n"
+
+SIEHE AUCH
+----------
+::
+
+	/std/room/pub.c
+
+
+Last modified: Sat Mar 04 22:48:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/props/P_PUB_UNAVAILABLE.rst b/doc/sphinx/props/P_PUB_UNAVAILABLE.rst
new file mode 100644
index 0000000..80cd6ef
--- /dev/null
+++ b/doc/sphinx/props/P_PUB_UNAVAILABLE.rst
@@ -0,0 +1,39 @@
+P_PUB_UNAVAILABLE
+=================
+
+NAME
+----
+::
+
+	P_PUB_UNAVAILABLE			"pub_unavailable"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/pub.h
+
+BESCHREIBUNG
+------------
+::
+
+        In diese Property kann man einen String schreiben, der ausgegeben
+        wird, wenn in einer Kneipe ein Getraenk oder eine Speise nicht mehr
+        vorraetig ist.
+
+BEMERKUNGEN
+-----------
+::
+
+        Die Standardmeldung ist:
+        "Davon ist leider nichts mehr da.\n"
+
+SIEHE AUCH
+----------
+::
+
+	/std/room/pub.c
+
+
+Last modified: Sat Mar 04 22:44:00 2000 by Paracelsus
+
diff --git a/doc/sphinx/props/P_PURSUERS.rst b/doc/sphinx/props/P_PURSUERS.rst
new file mode 100644
index 0000000..24f2b88
--- /dev/null
+++ b/doc/sphinx/props/P_PURSUERS.rst
@@ -0,0 +1,30 @@
+P_PURSUERS
+==========
+
+NAME
+----
+::
+
+    P_PURSUERS                    "pursuers"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     Enthaelt Verfolger - nicht von Hand manipulieren!
+
+SIEHE AUCH
+----------
+::
+
+     AddPursuer(L), RemovePursuer(L)
+
+
+16.06.2016, Arathorn
+
diff --git a/doc/sphinx/props/P_PUT_MSG.rst b/doc/sphinx/props/P_PUT_MSG.rst
new file mode 100644
index 0000000..a86ec40
--- /dev/null
+++ b/doc/sphinx/props/P_PUT_MSG.rst
@@ -0,0 +1,79 @@
+P_PUT_MSG
+=========
+
+NAME
+----
+::
+
+     P_PUT_MSG				"put_message"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/put_and_get.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mit P_PUT_MSG kann man die Meldung, die man beim Hineinstecken eines
+     Objektes in einen Container bekommt, modifizieren.
+
+     Folgende Werte sind moeglich:
+
+     o 0
+       Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
+
+     o NO_PNG_MSG	== -1
+       Es wird keinerlei Meldung ausgegeben
+
+     o Ein Array aus Strings
+       Der erste String wird an den Spieler ausgegeben, der zweite
+       (optionale) an den Raum.
+
+       Die Strings werden durch die Funktion replace_personal() geparst.
+	Objekt1 - Spieler
+        Objekt2 - das Objekt, das irgendwohin gesteckt wird
+	Objekt3 - der Container
+
+       Wird der zweite String nicht angegeben, erfolgt keine Meldung an den
+       Raum.
+
+BEISPIEL
+--------
+::
+
+     void create() {
+      ...
+      SetProp( P_SHORT, "Etwas Sand" );
+      SetProp( P_LONG, break_string(
+       "Ein wenig magischer Sand. Sehr feinkruemelig.",78 ));
+
+      SetProp( P_NAME, "Sand" );
+      AddId( ({"sand"}) );
+      SetProp( P_GENDER, MALE );
+
+      SetProp( P_PUT_MSG, ({
+       "Du laesst @WEN2 in @WENU3 rieseln.",
+       "@WER1 laesst @WEN2 in @WENU3 rieseln."}));
+      ...
+     }
+
+     Das ganze fuehrt bei Ugars "stecke sand in paket" zu folgenden
+     Meldungen:
+
+     Ugar: "Du laesst den Sand in ein Paket rieseln."
+     Raum: "Ugar laesst den Sand in ein Paket rieseln."
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_WEAR_MSG, P_WIELD_MSG
+     Fehler:     P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
+                 P_NOINSERT_MSG, P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     Sonstiges:  replace_personal(E), put_obj(L), /std/living/put_and_get.c
+
+14. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_QP.rst b/doc/sphinx/props/P_QP.rst
new file mode 100644
index 0000000..beba199
--- /dev/null
+++ b/doc/sphinx/props/P_QP.rst
@@ -0,0 +1,29 @@
+P_QP
+====
+
+NAME
+----
+::
+
+    P_QP                          "questpoints"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/quest.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der Questpunkte, die ein Spieler hat.
+
+HINWEIS
+-------
+::
+
+     Nur Abfragen der Property mit QueryProp() liefert den korrekten Wert,
+     da eine Quermethode fuer die Auslieferung der Daten sorgt. Query()
+     oder gar QueryProperties() enthalten u.U. einen veralteten Wert.
+
diff --git a/doc/sphinx/props/P_QUALITY.rst b/doc/sphinx/props/P_QUALITY.rst
new file mode 100644
index 0000000..cce352c
--- /dev/null
+++ b/doc/sphinx/props/P_QUALITY.rst
@@ -0,0 +1,58 @@
+P_QUALITY
+=========
+
+NAME
+----
+::
+
+     P_QUALITY "quality"
+
+DEFINIERT IN
+------------
+::
+
+     <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Ruestungen und Waffen koennen im Eifer des Gefechts beschaedigt werden.
+     Setzt man die Property P_QUALITY auf einen Wert n (n>0), so wird
+     eine Waffe (Ruestung) bei jedem n-ten Schlag (Treffer) beschaedigt,
+     d.h. P_WC (P_AC) wird um 1 erniedrigt und P_DAMAGED um 1 erhoeht.
+
+BEISPIEL
+--------
+::
+
+     inherit "/std/weapon";
+
+     ...
+     #include <combat.h>
+
+     create()
+     {
+       ...
+       SetProp(P_QUALITY,200);
+       ...
+     }
+
+     Diese Waffe wuerde bei jedem 200. Schlag etwas beschaedigt.
+
+BEMERKUNG
+---------
+::
+
+     Defaultmaessig ist P_QUALITY auf 0 gesetzt, d.h. die entspr.
+     Waffe/Ruestung wird nicht beschaedigt.
+
+SIEHE AUCH
+----------
+::
+
+     /std/armour.c, /std/weapon.c, TakeFlaw(), QueryFlaw(), Damage()
+
+
+Last modified: Thu May 22 10:42:39 1997 by Paracelsus
+
diff --git a/doc/sphinx/props/P_QUESTS.rst b/doc/sphinx/props/P_QUESTS.rst
new file mode 100644
index 0000000..9f8a61b
--- /dev/null
+++ b/doc/sphinx/props/P_QUESTS.rst
@@ -0,0 +1,21 @@
+P_QUESTS
+========
+
+NAME
+----
+::
+
+    P_QUESTS                      "quests"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/quest.h
+
+BESCHREIBUNG
+------------
+::
+
+     Liste der geloesten Quests.
+
diff --git a/doc/sphinx/props/P_QUEST_ITEM.rst b/doc/sphinx/props/P_QUEST_ITEM.rst
new file mode 100644
index 0000000..4110a03
--- /dev/null
+++ b/doc/sphinx/props/P_QUEST_ITEM.rst
@@ -0,0 +1,76 @@
+P_QUEST_ITEM
+============
+
+NAME
+----
+::
+
+	P_QUEST_ITEM				"quest_item" 
+
+DEFINIERT IN
+------------
+::
+
+	/sys/quest_items.h
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Property gibt an, ob es sich bei dem Objekt um ein Quest-
+	relevantes Objekt handelt.
+
+	
+
+BEISPIEL
+--------
+::
+
+        Ein Schwert (Notung) koennte folgendermassen definiert sein:
+
+	create()
+	{
+	  ::create() ;
+	  SetProp(P_SHORT, "Notung das neidliche Schwert") ;
+	  SetProp(P_LONG, "Das aus seinen Truemmern neu geschmiedete Schwert " 
+	                  "Notung.\n");
+
+	  SetProp(P_NAME, "Notung");
+	  SetProp(P_GENDER, NEUTER);
+	  SetProp(P_ARTICLE,0);
+	  AddId(({"notung","schwert","Notung", "\nNotung"}));
+
+	
+
+	  SetProp(P_WEAPON_TYPE, WT_SWORD);
+	  SetProp(P_DAM_TYPE, DT_BLUDGEON);
+
+	  SetProp(P_QUEST_ITEM,QI_OBJ);
+	  ...
+	}
+
+	    
+
+	Andere Magier koennen nun auf Notung Ruecksicht nehmen, und zum
+	Beispiel davon absehen, es bei einem NPC-Spell zu destructen.
+
+BEMERKUNGEN
+-----------
+::
+
+        Alle questrelevanten Objekte sollten auf diese Weise markiert werden.
+
+	
+
+	Questrelevante Objekte anderer Magier sollten immer mit Vorsicht 
+	behandelt werden.
+
+SIEHE AUCH
+----------
+::
+
+	"/sys/quest_items.h"
+
+
+Last modified: Thu Jul 10 07:08:32 2003 by Vanion
+
diff --git a/doc/sphinx/props/P_RACE.rst b/doc/sphinx/props/P_RACE.rst
new file mode 100644
index 0000000..ba0bde3
--- /dev/null
+++ b/doc/sphinx/props/P_RACE.rst
@@ -0,0 +1,49 @@
+P_RACE
+======
+
+NAME
+----
+::
+
+	P_RACE				"race"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/description.h
+
+BESCHREIBUNG
+------------
+::
+
+	Die Rasse eines Lebewesens kann ueber diese Property ermittelt bzw.
+	gesetzt werden. Es empfiehlt sich hierbei, Rassen nur in Form von
+	grossgeschriebenen Strings zu setzen. Leichen erhalten mittels
+	dieser Property automatisch die Rasse der Lebewesen, aus denen sie
+	hervorgegangen sind.
+	Der Sinn des Ganzen liegt darin, das Spiel differenzierter zu
+	gestalten und auf Rassenspezifika einzugehen. Zum Beispiel koennen
+	Elfen weniger Alkohol vertragen als Zwerge, was in '/std/pub'
+	beruecksichtigt wurde.
+
+BEISPIEL
+--------
+::
+
+	void create()
+	{ ::create();
+	  // Definitionen
+	  SetProp(P_RACE,"Ork");
+	  // weitere Definitionen
+	}
+
+SIEHE AUCH
+----------
+::
+
+	/std/npc.c, /std/pub.c
+
+
+Last modified: Mon Sep 15 21:15:49 2003 by Vanion
+
diff --git a/doc/sphinx/props/P_RACESTRING.rst b/doc/sphinx/props/P_RACESTRING.rst
new file mode 100644
index 0000000..38f7da8
--- /dev/null
+++ b/doc/sphinx/props/P_RACESTRING.rst
@@ -0,0 +1,22 @@
+P_RACESTRING
+============
+
+NAME
+----
+::
+
+    P_RACESTRING                  "racestring"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt eine dem Geschlecht angepasste Beschreibung der Rasse zurueck
+     ("Zwerg" oder "Zwergin" etc.)
+
diff --git a/doc/sphinx/props/P_RACE_DESCRIPTION.rst b/doc/sphinx/props/P_RACE_DESCRIPTION.rst
new file mode 100644
index 0000000..edb6575
--- /dev/null
+++ b/doc/sphinx/props/P_RACE_DESCRIPTION.rst
@@ -0,0 +1,21 @@
+P_RACE_DESCRIPTION
+==================
+
+NAME
+----
+::
+
+    P_RACE_DESCRIPTION            "racedescr"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Beschreibung der Vor/Nachteile einer Rasse.
+
diff --git a/doc/sphinx/props/P_RANGE.rst b/doc/sphinx/props/P_RANGE.rst
new file mode 100644
index 0000000..a647147
--- /dev/null
+++ b/doc/sphinx/props/P_RANGE.rst
@@ -0,0 +1,43 @@
+P_RANGE
+=======
+
+NAME
+----
+::
+
+    P_RANGE     "range"
+
+DEFINIERT IN
+------------
+::
+
+    <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+    Legt die Reichweite einer Schusswaffe fest. Ist ein Schuetze in einem
+    Raum mit gueltigem P_TARGET_AREA (andere Raum) oder environment() und
+    ist fuer diesen Raum P_SHOOTING_AREA festgelegt, dann kann er mit seiner
+    Schusswaffe in diesen anderen Raum schiessen, wenn die P_RANGE groesser
+    als P_SHOOTING_AREA ist.
+
+BEISPIELE
+---------
+::
+
+    // Langbogen mit 100 Reichweite
+    SetProp(P_RANGE, 100);
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
+    Methoden:  FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
+    Gebiet:    P_SHOOTING_AREA, P_TARGET_AREA
+    Sonstiges: fernwaffen
+
+29.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/props/P_READ_DETAILS.rst b/doc/sphinx/props/P_READ_DETAILS.rst
new file mode 100644
index 0000000..a068ae3
--- /dev/null
+++ b/doc/sphinx/props/P_READ_DETAILS.rst
@@ -0,0 +1,40 @@
+P_READ_DETAILS
+==============
+
+NAME
+----
+::
+
+    P_READ_DETAILS                "read_details"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mapping mit den Daten der Details, die durch Lesen ermittelt werden
+    koennen.
+
+BEMERKUNGEN
+-----------
+::
+
+    Bitte nur mit den entsprechenden Methoden veraendern!
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddReadDetail()
+    Loeschen:  RemoveReadDetail()
+    Aehnlich:  AddDetail(), P_DETAILS
+    Veraltet:  P_READ_MSG
+    Sonstiges: GetDetail(), break_string()
+
+27. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_READ_NEWS.rst b/doc/sphinx/props/P_READ_NEWS.rst
new file mode 100644
index 0000000..149b2b4
--- /dev/null
+++ b/doc/sphinx/props/P_READ_NEWS.rst
@@ -0,0 +1,21 @@
+P_READ_NEWS
+===========
+
+NAME
+----
+::
+
+    P_READ_NEWS                   "read_news"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Welche Artikel bereits gelesen wurde (frueher: in der MPA)
+
diff --git a/doc/sphinx/props/P_REAL_RACE.rst b/doc/sphinx/props/P_REAL_RACE.rst
new file mode 100644
index 0000000..b8d5936
--- /dev/null
+++ b/doc/sphinx/props/P_REAL_RACE.rst
@@ -0,0 +1,100 @@
+P_REAL_RACE
+===========
+
+NAME
+----
+::
+
+	P_REAL_RACE				"real_race"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/description.h
+
+BESCHREIBUNG
+------------
+::
+
+        Diese Property enthaelt die Rasse des Livings. Sie darf nicht durch 
+	Shadows ueberschrieben werden.
+
+	
+
+	Wirklich interessant ist sie, wenn ein Spieler sich tarnt. Dort kann
+	man mit dieser Property trotz Tarnung feststellen, welche Rasse der
+	Spieler hat.
+
+	Bei NPC enthaelt sie den gleichen Wert wie P_RACE. Wenn P_REAL_RACE
+	allerdings gesetzt wird, kann man damit einen getarnten NPC simu-
+	lieren, da dann P_RACE und P_REAL_RACE voneinander abweichen.
+
+	
+
+BEISPIEL
+--------
+::
+
+        Ein Zwerg mag Zwergenbrot, fuer Elfen ist es giftig. Selbst wenn der
+	Elf sich als Zwerg tarnt, wird ihm durch lembas sicher uebel werden:
+
+        int futter(string arg)
+        {
+          notify_fail("Was willst Du essen?\n");
+          if(!arg || !id(arg)) return 0;
+
+          notify_fail("Du kannst nichts mehr essen.\n");
+          if(!this_player()->eat_food(55)) return 0;
+
+          write("Du isst ein Stueck Zwegenbrot. Du versuchst es zumindest!\n");
+          say(sprintf("%s beisst in ein Stueck Zwergenbrot. Zahnschmerz!!!\n",
+              this_player()->Name()));
+
+
+          switch( this_player()->QueryProp(P_REAL_RACE) )
+          {
+          case "Zwerg":
+	    if ((this_player()->QueryProp(P_RACE))!="Zwerg")
+	      write("Zur Tarnung spuckst Du etwas von dem Brot aus!\n"); 
+            this_player()->buffer_hp(100,10);
+            this_player()->buffer_sp(100,10);
+            break;
+
+          case "Elf":
+	    write("Das Zwergenbrot brennt wie Feuer auf Deiner Zunge!");
+	    // Getarnt?
+	    if ((this_player()->QueryProp(P_RACE))!="Elf")
+	      write(" Deine Tarnung nutzt Dir da wenig.\n"
+            else write("\n");
+            this_player()->restore_spell_points(-100);
+            this_player()->do_damage(100,this_object());
+            break;
+
+          default:
+	    write("Du bekommst nur wenig davon herunter..\n");
+            this_player()->buffer_hp(10,1);
+            this_player()->buffer_sp(10,2);
+            break;
+          }
+
+  
+
+          remove();
+
+  
+
+          return 1;
+        }
+
+	
+
+SIEHE AUCH
+----------
+::
+
+	/std/living/description.c, /sys/living/description.h, P_RACE
+
+
+Last modified: Mon Sep 15 21:15:49 2003 by Vanion
+
diff --git a/doc/sphinx/props/P_REFERENCE_OBJECT.rst b/doc/sphinx/props/P_REFERENCE_OBJECT.rst
new file mode 100644
index 0000000..67501f5
--- /dev/null
+++ b/doc/sphinx/props/P_REFERENCE_OBJECT.rst
@@ -0,0 +1,42 @@
+P_REFERENCE_OBJECT
+==================
+
+NAME
+----
+::
+
+     P_REFERENCE_OBJECT            "reference_object"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     In dieser Propertie wird das aktuelle Bezugsobjekt eines Spielers 
+     gespeichert. Untersucht der Spieler ein Monster, so ist dies das 
+     Monsterobjekt, untersucht der Spieler sich selber, ist es das 
+     Spielerobjekt.
+
+     Der Inhalt dieser Propertie besteht also immer aus dem zuletzt 
+     betrachteten Objekt. Sei es ein Raum, eine Ruestung, ein Monster oder 
+     was auch immer. Bewegungsbefehle und andere Kommandos werden nicht 
+     beruecksichtigt.
+
+     Einzig wenn der Spieler 'schau' tippt, wird der Inhalt der Propertie 
+     geloescht und betraegt 0.
+
+SIEHE AUCH
+----------
+::
+
+     Sonstiges:		P_INT_LONG, P_LONG, P_SHORT
+			int_long(), long(), short(), make_invlist()
+
+
+Letzte Aenderung: 29.06.02, 23:50:00 h, von Tilly
+
diff --git a/doc/sphinx/props/P_REJECT.rst b/doc/sphinx/props/P_REJECT.rst
new file mode 100644
index 0000000..82e6b45
--- /dev/null
+++ b/doc/sphinx/props/P_REJECT.rst
@@ -0,0 +1,73 @@
+P_REJECT
+========
+
+NAME
+----
+::
+
+	P_REJECT			"reject"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property zeigt standardmaessig nur in NPCs eine Wirkung. Mit
+	ihr laesst sich sehr einfach einstellen, wie sich ein solcher NPC
+	gegenueber Gegenstaenden verhalten soll, welche ihm zugesteckt
+	werden. Hierbei besteht die Property aus 2 Elementen, welche
+	bestimmt, was der NPC mit Dingen tuen soll, die ihm gegeben werden.
+	Standardmaessig behaelt der NPC die Sachen einfach.
+	Folgende Moeglichkeiten gibt es ausserdem:
+	  1. Arrayelement: Art der Handlung. (aus "/sys/moving.h")
+	    REJECT_GIVE: Der NPC gibt das Objekt zurueck.
+	    REJECT_DROP: Der NPC laesst das Objekt fallen.
+	    REJECT_KEEP: Der NPC behaelt das Objekt doch.
+	    REJECT_LIGHT_MODIFIER: Der NPC nimmt keine Gegenstaende an, die
+	      sein Lichtlevel veraendern und damit Einfluss auf sein
+	      Kampfverhalten haben koennten.
+	  2. Arrayelement: Meldung, mit welcher der NPC die Handlung
+	                   kommentiert.
+	    Der Meldung wird nichts automatisch vorangestellt und ein
+	    abschliessender Zeilenumbruch ist ebenfalls selbstaendig
+	    vorzunehmen. Mit einem Leerstring ist somit auch gar keine
+	    Rueckmeldung moeglich.
+
+BEISPIEL
+--------
+::
+
+	Der NPC schmeisst alle ihm gegebenen Gegenstaende einfach weg:
+	  void create()
+	  { ::create();
+	    ...
+	    SetProp(P_REJECT,({REJECT_GIVE,
+	    Name(WER)+" murmelt: Was soll ich denn damit?!\n"}));
+	    ...
+	  }
+	Manchmal ist das recht nuetzlich, z.B. kann man so eigentlich schwer
+	zu toetende NPCs dagegen schuetzen, dass man ihnen angezuendetes
+	Dynamit oder aehnliches ueberreicht.
+
+BEMERKUNGEN
+-----------
+::
+
+	Innerhalb von NPCs ist die Funktion give_notify() fuer die
+	automatische Auswertung dieser Property verantwortlich; das sollte
+	man insbesondere beim Ueberschreiben dieser Funktion beachten!
+
+SIEHE AUCH
+----------
+::
+
+	give_notify(), /std/npc/put_and_get.c
+
+
+Last modified: Mon Apr 23 16:54:07 2001 by Patryn
+
diff --git a/doc/sphinx/props/P_REMOVE_FUNC.rst b/doc/sphinx/props/P_REMOVE_FUNC.rst
new file mode 100644
index 0000000..0d13b79
--- /dev/null
+++ b/doc/sphinx/props/P_REMOVE_FUNC.rst
@@ -0,0 +1,42 @@
+P_REMOVE_FUNC
+=============
+
+NAME
+----
+::
+
+     P_REMOVE_FUNC "remove_func"
+
+DEFINIERT IN
+------------
+::
+
+     <armour.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Falls ein Objekt eine RemoveFunc() fuer die Ruestung oder Kleidung 
+     definiert, so muss dieses Objekt in dieser Property eingetragen sein.
+
+     Die Auswertung dieser Property erfolgt im Laufe des DoUnwear() in
+     der nicht-oeffentlichen Funktionen _check_unwear_restrictions().
+
+BEISPIELE
+---------
+::
+
+     Siehe das Beispiel zu RemoveFunc()
+
+SIEHE AUCH
+----------
+::
+
+     /std/armour.c, /std/clothing.c, clothing, armours
+     RemoveFunc()
+
+
+Letzte Aenderung:
+15.02.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_REMOVE_MSG.rst b/doc/sphinx/props/P_REMOVE_MSG.rst
new file mode 100644
index 0000000..f0d100b
--- /dev/null
+++ b/doc/sphinx/props/P_REMOVE_MSG.rst
@@ -0,0 +1,54 @@
+P_REMOVE_MSG
+============
+
+NAME
+----
+::
+
+     P_REMOVE_MSG                  "std_food_remove_msg"
+
+DEFINIERT IN
+------------
+::
+
+     <sys/food.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Meldung, wenn eine verdorbene Speise gerade vernichtet wird.
+     Diese Meldung erscheint nur, wenn in P_DESTROY_BAD ein positiver
+     Integer-Wert gesetzt ist.
+     Befindet sich die Speise in einem Spieler, geht die Meldung an genau
+     diesen, liegt die Speise im Raum, geht die Meldung an alle anwesenden
+     Spieler.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Meldung wird von replace_personal mit den Argumenten:
+     1. Speise
+     2. Konsument
+     verarbeitet, kann als entsprechende Platzhalter enthalten
+
+     
+
+DEFAULT
+-------
+::
+
+     "@WER1 zerfaellt zu Staub."
+
+SIEHE AUCH
+----------
+::
+
+     P_DESTROY_BAD, wiz/food, replace_personal
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_RESET_LIFETIME.rst b/doc/sphinx/props/P_RESET_LIFETIME.rst
new file mode 100644
index 0000000..5671ee6
--- /dev/null
+++ b/doc/sphinx/props/P_RESET_LIFETIME.rst
@@ -0,0 +1,55 @@
+P_RESET_LIFETIME
+================
+
+NAME
+----
+::
+
+     P_RESET_LIFETIME              "std_food_lifetime_reset"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/food.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zeit in Resets, die die Speise haltbar ist.
+     Jeder einzelne Reset wird in seiner Laenge zufaellig festgelegt und
+     zu einer Gesamtanzahl von Sekunden zusammengefasst. Diese Zeit in
+     Sekunden wird dann in P_LIFETIME gespeichert.
+     Nach dieser Zeit wird diese Speise schlecht und je nach Konfiguration
+     der Speise eventuell zerstoert. Sichergestellt wird dies durch den
+     Aufruf von reset() nach dieser Anzahl "Resets".
+     Moechte man eine Speise haben, die niemals verdirbt
+     (genehmigungspflichtig!), nutzt man die Property P_NO_BAD
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     Sobald der Countdown zum Schlechtwerden der Speise laeuft, also ein
+     Spieler damit in Beruehrung kam, zeigt SetProp auf diese Property keine
+     Wirkung mehr.
+
+DEFAULT
+-------
+::
+
+     Ohne Setzen von P_LIFETIME ,P_RESET_LIFETIME und P_NO_BAD verdirbt die
+     Speise nach einem Reset, also zwischen 30 und 60 Minuten
+
+SIEHE AUCH
+----------
+::
+
+     wiz/food, P_LIFETIME, P_NO_BAD
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_RESISTANCE.rst b/doc/sphinx/props/P_RESISTANCE.rst
new file mode 100644
index 0000000..fede888
--- /dev/null
+++ b/doc/sphinx/props/P_RESISTANCE.rst
@@ -0,0 +1,61 @@
+P_RESISTANCE
+============
+
+NAME
+----
+::
+
+     P_RESISTANCE                  "resistance"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+WICHTIG
+-------
+::
+
+     DIESE PROPERTY IST VERALTET! BITTE P_RESISTANCE_STRENGTHS
+     VERWENDEN! AUCH FUNKTIONIERT Set() NICHT WIE ES SOLLTE.
+
+BESCHREIBUNG
+------------
+::
+
+     Hiermit koennen die Resistenzen eines Lebewesens sehr einfach gesetzt
+     werden. Es kann ein Array mit Schadensarten gesetzt werden, jeder
+     Eintrag eines Schadens verdoppelt die Resistenz gegen diesen.
+
+BEMERKUNGEN
+-----------
+::
+
+     - P_RESISTANCE_STRENGTHS spiegelt diese Eintraege hier wieder
+     - um genauere Werte anzugeben einen AddResistanceModifier() oder
+       P_RESISTANCE_STRENGTHS benutzen.
+     - P_RESISTANCE kann und wird nicht aus P_RESISTANCE_STRENGTHS
+       upgedatet
+
+BEISPIELE
+---------
+::
+
+     // ein NPC mit halbierter Feuerempfindlichkeit und
+     // geviertelter Windempfindlichkeit
+     SetProp(P_RESISTANCE, ({DT_FIRE, DT_AIR, DT_AIR}));
+
+SIEHE AUCH
+----------
+::
+
+     simple Resistenz:	P_RESISTANCE
+     Modifikatoren:	AddResistanceModifier, RemoveResistanceModifier(),
+			P_RESISTANCE_MODIFIER
+     Hauptmapping:	P_RESISTANCE_STRENGTHS
+     Berechnung:	CheckResistance(), UpdateResistanceStrengths()
+     anderes:		balance, /std/armour/combat.c, /std/living/combat.c
+
+1.Dez 2004, Gloinson
+
diff --git a/doc/sphinx/props/P_RESISTANCE_MODIFIER.rst b/doc/sphinx/props/P_RESISTANCE_MODIFIER.rst
new file mode 100644
index 0000000..a87fdeb
--- /dev/null
+++ b/doc/sphinx/props/P_RESISTANCE_MODIFIER.rst
@@ -0,0 +1,45 @@
+P_RESISTANCE_MODIFIER
+=====================
+
+NAME
+----
+::
+
+     P_RESISTANCE_MODIFIER             "rstr:mod"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Hier werden die Resistenzmodifikatoren in einem Mapping abgespeichert.
+
+     Format:
+
+     (["me":<Aufaddition aller Resistenz/Empfindlichkeitsmodifikationen>;0,
+       "<Objektname>#<Schluessel>":<Resistenzmapping>;<Objekreferenz>,
+       ...])
+
+BEMERKUNGEN
+-----------
+::
+
+     Nur ueber AddResistanceModifier(), RemoveResistanceModifier() aendern!
+
+SIEHE AUCH
+----------
+::
+
+     Modifikatoren:	AddResistanceModifier, RemoveResistanceModifier()
+     simple Resistenz:	P_RESISTANCE, P_VULNERABILITY
+     Hauptmapping:	P_RESISTANCE_STRENGTHS
+     Berechnung:	CheckResistance(), UpdateResistanceStrengths()
+     anderes:		balance, /std/armour/combat.c, /std/living/combat.c
+
+29.Apr 2002, Gloinson@MG
+
diff --git a/doc/sphinx/props/P_RESISTANCE_STRENGTHS.rst b/doc/sphinx/props/P_RESISTANCE_STRENGTHS.rst
new file mode 100644
index 0000000..26a4ca8
--- /dev/null
+++ b/doc/sphinx/props/P_RESISTANCE_STRENGTHS.rst
@@ -0,0 +1,114 @@
+P_RESISTANCE_STRENGTHS
+======================
+
+NAME
+----
+::
+
+     P_RESISTANCE_STRENGTHS     "resistance_strengths"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Lebewesen:
+
+     Mapping mit Schadensarten, gegen die das Lebewesen resistent oder
+     anfaellig ist. Durch eine _query_method werden alle existierenden
+     Resistenzen hier zusammengefasst.
+
+     Die Staerke der Resistenz oder Anfaelligkeit wird numerisch aus-
+     gedrueckt:
+     - Resistenzen gehen bis von 0 bis -1.0 (absolute Resistenz)
+       - -0.5 == halbierter Schaden, -0.75 == geviertelter Schaden
+       -> in % des "aufgehaltenen" Schadens interpretierbar
+     - Empfindlichkeiten gehen von 0 bis MAX_INT
+       -  1.0 == verdoppelter Schaden, 3.0 == vervierfachter Schaden
+       -> als Faktor (x+1.0) interpretierbar
+
+     Ruestungen:
+
+     Mapping mit Prozentwerten der Maximalwerte fuer Ruestungen des
+     entsprechenden Typs. Dabei sind positive Werte Resistenzen und
+     negative Empfindlichkeiten. Dabei duerfen die Prozentwerte nur
+     im Bereich von +100 bis -800 (-1000 ?!) liegen.
+
+     Bei Ruestungen ist es damit unnoetig, Resistenzen mittels
+     AddResistanceModifier() im Traeger zu setzen, da dies bereits
+     in /std/armour automatisch gemacht wird. Der Schluessel fuer
+     den Eintrag ist dabei P_ARMOUR_TYPE.
+
+     Die Maximalwerte sind derzeit:
+      AT_CLOAK, AT_RING, AT_AMULET: max 10% Resistenz
+      AT_SHIELD, AT_ARMOUR:  max 15% Resistenz
+      alle anderen:   max 5% Resistenz
+
+BEMERKUNGEN
+-----------
+::
+
+     Ruestungen:
+     * die Property muss _nach_ P_ARMOUR_TYPE gesetzt werden (_set-Method)
+
+     Lebewesen:
+     * -1.0 bedeutet bereits absolute Resistenz, bei kleineren Werten werden
+       die anderen Schadensanteile im Kampf u.U. nicht mehr wie gewuenscht
+       bilanziert. Bitte daher drauf verzichten. ;-)
+     * Aenderungen an P_RESISTANCE und P_VULNERABILITY werden direkt in 
+       P_RESISTANCE_STRENGTHS gespeichert:
+       -> daher niemals im Nachhinein bei fremden NPCs P_RESISTANCE_STRENGTHS
+          manipulieren, dafuer gibt es AddResistanceModifier
+     * QueryProp(P_RESISTANCE_STRENGTHS) enthaelt die gesamten Resistenzen
+       P_RESISTANCE, P_VULNERABILITY, P_RESISTANCE_MODIFIER (_query-Method)
+
+     Die Werte in P_RESISTANCE_STRENGTHS sollten nur in Ausnahmefaellen oder
+     gut begruendet den Hoechstwert haben. Ein Eiswesen kann zwar sehr
+     resistent gegen Kaelteschaden sein, sollte aber zu gleichem Teil auch
+     anfaellig auf Feuerschaden sein.
+
+     Auf dieser Property liegt eine Querymethode, welche eine Kopie der
+     Daten zurueckliefert.
+
+BEISPIELE
+---------
+::
+
+     // ein Eistroll
+     SetProp(P_RESISTANCE_STRENGTHS,([DT_FIRE:0.5,DT_COLD:-0.5,
+                                      DT_MAGIC:0.1]));
+
+     Feuerangriffe werden mit 1.5 multipliziert, magische mit 1.1 und
+     der Schadenswert von Kaelteangriffen wird halbiert. Zum Beispiel
+     wuerde
+     Defend(100, ({DT_FIRE,DT_MAGIC}), ...)
+     einen Schaden von 130 statt den normalen 100 verursachen.
+
+
+     // eine Eisruestung
+     SetProp(P_RESISTANCE_STRENGTHS, ([DT_COLD:50, DT_FIRE:-100]));
+
+     Dieses Kettenhemd schuetzt nun mit 50% des Maximalwertes gegen
+     Kaelte (also 0.5*15%=7,5% Resistenz) und macht mit dem Maximal-
+     wert anfaellig gegen Feuer (1*15%=15% Empfindlichkeit).
+
+     ! der Code spricht zusaetzlich von
+       Empfindlichkeit=(Empfindlichkeit/4)*5 -> 15/4*5=18.75% !
+
+SIEHE AUCH
+----------
+::
+
+     simple Resistenz: P_RESISTANCE, P_VULNERABILITY
+     Modifikatoren: AddResistanceModifier, RemoveResistanceModifier(),
+     P_RESISTANCE_MODIFIER
+     Berechnung: CheckResistance(), UpdateResistanceStrengths()
+     anderes:  balance, /std/armour/combat.c, /std/living/combat.c
+
+6.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_RESTRICTIONS.rst b/doc/sphinx/props/P_RESTRICTIONS.rst
new file mode 100644
index 0000000..c5682ff
--- /dev/null
+++ b/doc/sphinx/props/P_RESTRICTIONS.rst
@@ -0,0 +1,163 @@
+P_RESTRICTIONS
+==============
+
+NAME
+----
+::
+
+    P_RESTRICTIONS                                "restrictions"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/combat.h
+    (Die SR_*-Parameter sind in /sys/new_skills.h definiert.)
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt ein mapping mit den zu pruefenden Einschraenkungen.
+
+    In dieser Property lassen sich Restriktionen setzen, die vor dem
+    Zuecken einer Waffe / Anziehen einer Ruestung oder Kleidung geprueft
+    werden und dies gegebenfalls verhindern, ohne gleich auf eine evtl.
+    vorhandene WieldFunc / WearFunc zuzugreifen.
+
+    Die Auswertung erfolgt ueber den Aufruf von check_restrictions()
+    in /std/restriction_checker.c
+
+    Folgende Keys werden in dem Mapping ausgewertet:
+
+    P_LEVEL
+      Mindeststufe, die das Lebewesen besitzen muss, um die Aktion
+      auszufuehren.
+    P_GUILD_LEVEL
+      Gildenlevel, das das Lebewesen mindestens erreicht haben muss, um die
+      Aktion auszufuehren.
+    SR_SEER
+      Ist gesetzt, wenn das Lebewesen Seher sein muss.
+      Auswertung nur fuer Interactives, NSC ignorieren das Flag.
+    P_XP
+      Mindestmenge an Erfahrungspunkten, die ein Lebewesen besitzen muss,
+      um die Aktion auszufuehren.
+    P_QP
+      Mindestmenge an Abenteuerpunkten, die das Lebewesen haben muss.
+    P_ALCOHOL
+      Menge an Alkohol, unter der der Alkoholspiegel des Lebewesen liegen
+      muss, um die Aktion noch ausfuehren zu koennen.
+    P_DRINK
+      Menge an Fluessigkeit, unter der der Fluessigkeitsspiegel des
+      Lebewesen liegen muss, um die Aktion noch ausfuehren zu koennen.
+    P_FOOD
+      Beinhaltet die Menge an Nahrung, unter der der Nahrungsspiegel des
+      Spielers liegen muss, um die Aktion noch ausfuehren zu koennen.
+    P_DEAF
+      Ist gesetzt, falls der Spieler nicht taub sein darf.
+    P_FROG
+      Ist gesetzt, falls der Spieler kein Frosch sein darf.
+    P_BLIND
+      Ist gesetzt, falls der Spieler nicht blind sein darf.
+      Achtung: das ist nicht gleichbedeutend mit dem Umstand, dass er evtl.
+      nichts mehr sehen kann. Auch andere Gruende (zum Beispiel Dunkelheit)
+      koennen bewirken, dass ein Spieler nichts mehr sieht.
+    A_INT, A_DEX, A_CON, A_STR
+      Jeweilige Mindesthoehe eines Attribut, um eine Aktion ausfuehren zu
+      koennen.
+    SR_BAD, SR_GOOD
+      Gibt an, wie [minimal] boese bzw. wie [maximal] gut ein Charakter sein
+      darf, um eine Aktion ausfuehren zu koennen.
+    SR_MIN_SIZE, SR_MAX_SIZE
+      Gibt die minimale, bzw. die maximale Groesse an, die ein Charakter
+      maximal haben darf, um eine Aktion ausfuehren zu koennen.
+    SR_FREE_HANDS
+      Gibt an, wieviele freie Haende ein Charakter fuer diese Aktion
+      besitzen muss.
+    SR_EXCLUDE_RACE
+      Mitglieder aller in dieser Liste aufgefuehrten Rassen koennen
+      diese Aktion nicht ausfuehren.
+    SR_INCLUDE_RACE
+      Mitglieder aller NICHT in dieser Liste aufgefuehrten Rassen koennen
+      diese Aktion nicht ausfuehren.
+    SM_RACE
+      Hier kann pro Rasse ein Mapping mit besonderen (nur) fuer diese Rasse
+      geltenden Einschraenkungen vorgenommen werden. Als Keys sind die
+      in dieser Manpage beschriebenen Keys erlaubt, wobei SM_RACE nicht
+      rekursiv ausgewertet wird.
+      Der Rassenname ist gross geschrieben und "*" steht fuer alle Rassen.
+    SR_EXCLUDE_GUILD
+    SR_INCLUDE_GUILD
+      Diese beiden Keys verhalten sich wie SR_*_RACE, nur dass hier Gilden
+      genannt werden.
+    SR_FUN
+      Hier kann eine Funktion in verschiedenen Formen zum Pruefen der
+      Restriktionen angegeben werden, siehe execute_anything().
+      Das kann nuetzlich sein, um andere Restriktionen zu pruefen,
+      wie das Bestehen von Miniquests oder andere Faehigkeiten/Flags.
+      Ist der Test nicht bestanden, gibt die Funktion einen String zurueck.
+    SR_PROP
+      Hier kann ein Mapping mit Properties und zugehoerigen Werten angegeben
+      werden, die jeweils auf Identitaet geprueft werden. Zusaetzlich sollte
+      eine Meldung angegeben werden, die als Fehlermeldung ausgegeben wird,
+      wenn der Spieler die Bedingung nicht erfuellt. Es sollte immer eine
+      passende Meldung fuer den Spieler eingebaut werden. Beispiel:
+      ([ SR_PROP: ([P_AUSGANG_ENTDECKT: 1; "Dein Schwert fluestert "
+          "veraergert: Ich werde Dir erst dann zu Diensten sein, wenn Du "
+          "Dich als wuerdig erwiesen hast!"]) ])
+      Aufgrund der Meldung wird empfohlen, SR_PROP nicht in Restriktionen 
+      einzusetzen, die massenweise in Savefiles landen (z.B. 
+      Spielersavefiles).
+    SR_QUEST
+      Hier kann ein String-Array mit den Namen (Keys) der Quest(s) angegeben
+      werden, die der Spieler bestanden haben muss, um die Aktion ausfuehren
+      zu koennen.
+    SR_MINIQUEST
+      Hier kann entweder ein String-Array mit den Ladenamen der vergebenden
+      Objekte oder ein Int-Array mit den Index-Nummern (IDs) der
+      Miniquest(s) (empfohlen!) angegeben werden, die der Spieler bestanden
+      haben muss, um die Aktion ausfuehren zu koennen.
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Property eignet sich hervorragend dafuer, einige Grundbedingungen
+    fuer das Nutzen der Waffe / Ruestung / Kleidung zu stellen ohne gleich
+    eine Wield- oder WearFunc setzen und auswerten zu muessen.
+
+    Denkbar waere der Einsatz bei hochwertigen Waffen / Ruestungen / Kleidung,
+    z.B. aus der Para-Welt oder solchen, die sich nah am Limit der geltenden
+    Grenzwerte fuer P_WC / P_AC bewegen oder sogar (nach Genehmigung durch
+    die Balance) darueber.
+
+BEISPIEL
+--------
+::
+
+    Mindeststufe 25: SetProp(P_RESTRICTIONS,([P_LEVEL:25]));
+    Keine Menschen:  SetProp(P_RESTRICTIONS,([SR_EXCLUDE_RACE:({"Mensch"})]));
+    Alignment >499:  SetProp(P_RESTRICTIONS,([SR_GOOD:500]));
+
+    Komplexeres Beispiel
+
+    Quest "Diamond Club" bestanden, magiereigene Property P_AUSGANG_GEFUNDEN
+    muss gesetzt sein, Stufe 10, nicht taub, max. 45 Food:
+    SetProp(P_RESTRICTIONS, ([ P_LEVEL: 10, P_DEAF: 1, P_FOOD: 45,
+      SR_PROP: ([P_AUSGANG_GEFUNDEN:1]), SR_QUEST:({"Diamond Club"}) ]));
+
+SIEHE AUCH
+----------
+::
+
+    check_restrictions(L)
+    WieldFunc(L), WearFunc(L), RemoveFunc(L), UnwieldFunc(L),
+    P_WIELD_FUNC, P_WEAR_FUNC, P_REMOVE_FUNC, P_UNWIELD_FUNC
+    /std/armour/wear.c, /std/weapon/combat.c, clothing, armours, weapon
+
+LETZTE AeNDERUNG
+----------------
+::
+
+03. Januar 2014, Arathorn
+
diff --git a/doc/sphinx/props/P_ROOM_MSG.rst b/doc/sphinx/props/P_ROOM_MSG.rst
new file mode 100644
index 0000000..087f9c2
--- /dev/null
+++ b/doc/sphinx/props/P_ROOM_MSG.rst
@@ -0,0 +1,39 @@
+P_ROOM_MSG
+==========
+
+NAME
+----
+::
+
+    P_ROOM_MSG                    "room_msg"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/room/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Liste mit Meldungen, die zufaellig im Raum ausgegeben werden.
+
+     Hier sind nur die Textmeldungen als String-Array gespeichert.
+
+ANMERKUNGEN
+-----------
+::
+
+     Bitte AddRoomMessage() zum Hinzufuegen/Ueberschreiben benutzen!
+
+SIEHE AUCH
+----------
+::
+
+     LFuns:    AddRoomMessage()
+     Verwandt: tell_room(), ReceiveMsg()
+     Props:    P_FUNC_MSG, P_MSG_PROB
+
+2.Feb 2016 Gloinson
+
diff --git a/doc/sphinx/props/P_ROOM_TYPE.rst b/doc/sphinx/props/P_ROOM_TYPE.rst
new file mode 100644
index 0000000..a1a269a
--- /dev/null
+++ b/doc/sphinx/props/P_ROOM_TYPE.rst
@@ -0,0 +1,39 @@
+P_ROOM_TYPE
+===========
+
+NAME
+----
+::
+
+    P_ROOM_TYPE                       "room_type"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/rooms.h
+
+BESCHREIBUNG
+------------
+::
+
+    In P_ROOM_TYPE wird die Art des Raumes durch entsprechende Flags
+    beschrieben.
+
+    Bisher unterstuetzt werden:
+        - RT_SHOP       fuer Raeume, die /std/room/shop inheriten
+        - RT_PUB        fuer Raeume, die /std/room/pub inheriten
+
+BEISPIEL
+--------
+::
+
+    Wenn ein NPC abfragen moechte, ob er sich in einer Kneipe aufhaelt (um
+    selbststaendig tanken zu koennen) koennte eine Abfrage z.B. so aussehen:
+
+        if ( environment() &&
+             environment()->QueryProp(P_ROOM_TYPE) & RT_PUB ){
+
+            ... tanken ...
+        }
+
diff --git a/doc/sphinx/props/P_SB_SPELLS.rst b/doc/sphinx/props/P_SB_SPELLS.rst
new file mode 100644
index 0000000..c019f46
--- /dev/null
+++ b/doc/sphinx/props/P_SB_SPELLS.rst
@@ -0,0 +1,42 @@
+P_SB_SPELLS
+===========
+
+NAME
+----
+::
+
+    P_SB_SPELLS            "sb_spells"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Spellbookproperty sind saemtliche Sprueche des Spellbooks
+    vermerkt. Veraendert wird sie durch AddSpell().
+
+BEMERKUNGEN
+-----------
+::
+
+    Man sollte diese Property nicht per Hand veraendern, sondern die
+    Funktion AddSpell() nutzen.
+
+SIEHE AUCH
+----------
+::
+
+    GObj Verwalten:   LearnSkill, LearnSpell, InitialSkillAbility
+    * Properties:     P_GUILD_SKILLS
+    Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
+    * Verwalten:      AddSpell, QuerySpell
+    * Properties:     P_GLOBAL_SKILLPROPS
+    Skills:           P_NEWSKILLS, spruchermuedung, skill_info_liste
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_SCREENSIZE.rst b/doc/sphinx/props/P_SCREENSIZE.rst
new file mode 100644
index 0000000..c81b33f
--- /dev/null
+++ b/doc/sphinx/props/P_SCREENSIZE.rst
@@ -0,0 +1,21 @@
+P_SCREENSIZE
+============
+
+NAME
+----
+::
+
+    P_SCREENSIZE                  "screensize"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Bildschirmgroesse in Zeilen (fuer More)
+
diff --git a/doc/sphinx/props/P_SECOND.rst b/doc/sphinx/props/P_SECOND.rst
new file mode 100644
index 0000000..74e1fb3
--- /dev/null
+++ b/doc/sphinx/props/P_SECOND.rst
@@ -0,0 +1,40 @@
+P_SECOND
+========
+
+NAME
+----
+::
+
+    P_SECOND                      "second"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn diese Prop gesetzt ist, ist der Spieler ein Zweitie. Inhalt der
+     Prop ist ein String mit dem (lowercase) Namen des Ersties.
+
+BEISPIEL
+--------
+::
+
+     if (this_player()->QueryProp(P_SECOND)=="notstrom") {
+       tell_object(this_player(), "Nicht alles aufessen!\n");
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Properties: P_SECOND_MARK
+     Sonstiges:  /secure/zweities.c
+
+
+Last modified: 18-Jun-2015, Arathorn.
+
diff --git a/doc/sphinx/props/P_SECOND_MARK.rst b/doc/sphinx/props/P_SECOND_MARK.rst
new file mode 100644
index 0000000..aeea609
--- /dev/null
+++ b/doc/sphinx/props/P_SECOND_MARK.rst
@@ -0,0 +1,31 @@
+P_SECOND_MARK
+=============
+
+NAME
+----
+::
+
+    P_SECOND_MARK                 "second_mark"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gibt an, wie mit der Zweitie-Markierung eines Spielers umgegangen wird.
+
+     -1  'unsichtbare' Markierung; im wer/kwer wird bei diesem Zweitie s
+         oder S angezeigt.
+
+      0  'sichtbare' Markierung; im wer/kwer wird bei diesem Zweitie z oder
+         Z angezeigt. Der Name des Ersties ist beim Fingern jedoch nur
+         fuer Magier sichtbar.
+
+      1  Markierung 'sichtbar + Name'; wie 0, nur dass beim Fingern alle
+         Spieler den Namen des Ersties sehen koennen.
+
diff --git a/doc/sphinx/props/P_SEERDOORS.rst b/doc/sphinx/props/P_SEERDOORS.rst
new file mode 100644
index 0000000..c90a21e
--- /dev/null
+++ b/doc/sphinx/props/P_SEERDOORS.rst
@@ -0,0 +1,49 @@
+P_SEERDOORS
+===========
+
+NAME
+----
+::
+
+     P_SEERDOORS      "rw_sehertore"
+
+DEFINIERT IN
+------------
+::
+
+     /d/seher/portale/sehertor.h
+
+BESCHREIBUNG
+------------
+::
+
+     Sehertor-relevante Property.
+
+     Enthaelt ein Mapping mit den Wertepaaren
+     ([ Seher-Portal-Nummer: x ])
+     mit x != 0 fuer entdeckte Tore.
+
+     
+
+     0 hat ein Sonderverhalten fuer mobile Tore.
+
+BEMERKUNG
+---------
+::
+
+     Auf gar keinen Fall in Spielern manipulieren! Und bitte das enthaltene
+     Mapping nicht von einem Spieler abfragen und P_SEERDOORS in einem
+     Testspieler zuweisen!
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     P_FAO_PORTALS
+
+     
+
+1.September 2008 Gloinson
+
diff --git a/doc/sphinx/props/P_SEERDOOR_ALLOWED.rst b/doc/sphinx/props/P_SEERDOOR_ALLOWED.rst
new file mode 100644
index 0000000..525e53d
--- /dev/null
+++ b/doc/sphinx/props/P_SEERDOOR_ALLOWED.rst
@@ -0,0 +1,27 @@
+P_SEERDOOR_ALLOWED
+==================
+
+NAME
+----
+::
+
+    P_SEERDOOR_ALLOWED		"rw_sehertor_erlaubt"                          
+
+DEFINIERT IN
+------------
+::
+
+    /d/seher/portale/sehertor.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property muss in einem Raum gesetzt sein, soll
+     ein Seher dort ein mobiles Sehertor abstellen duerfen.
+     Zusaetzlich darf der Raum nicht in PARA liegen und muss
+     als eigenes File existieren.
+     Es ist darauf zu achten, Sehertore nicht in Questgebieten,
+     direkt an Tanken oder aehnlichen Plaetzen zu erlauben.
+     Es gilt die Einschaetzung des fuer den Raum Verantwortlichen.
+
diff --git a/doc/sphinx/props/P_SENSITIVE.rst b/doc/sphinx/props/P_SENSITIVE.rst
new file mode 100644
index 0000000..fa6d633
--- /dev/null
+++ b/doc/sphinx/props/P_SENSITIVE.rst
@@ -0,0 +1,154 @@
+P_SENSITIVE
+===========
+
+NAME
+----
+::
+
+     P_SENSITIVE                   "sensitive"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property kann in Objekten gesetzt werden, die auf bestimmte
+     Schadensarten empfindlich reagieren sollen. Moegliche Anwendungsfaelle:
+     - Das Lebewesen, in dessen Inventar sich ein Objekt befindet, erleidet
+       einen Angriff mit der fraglichen Schadensart (Beispiel: eine 
+       Pusteblume, die bei Angriff mit Luftschaden auseinanderfaellt).
+     - Zwei Objekte treffen im gleichen Environment aufeinander, wobei
+       eines empfindlich auf eine Schadensart reagiert, und das zweite diese
+       Schadensart mitbringt, d.h. die Empfindlichkeit ausloesen kann.
+       (Beispiel: ein feuerempfindlicher Postsack wird angesengt, wenn eine
+        brennende Fackel ins gleiche Inventar kommt.)
+       Das Ausloesen dieser Empfindlichkeit ist unabhaengig davon, welches 
+       Objekt zuerst da war.
+
+     Die Property enthaelt ein Array aus Arrays:
+       ({<sensprops_1>, <sensprops_2>, ..., <sensprops_n>})
+
+     
+
+     wobei jeder Eintrag <sensprops> jeweils folgende Struktur hat:
+       ({string list_key, string damtype, int treshold, mixed options })
+
+     
+
+     Die Eintraege haben dabei folgende Bedeutung:
+
+     
+
+     list_key: Kann einen von folgenden drei Werten annehmen 
+          1) SENSITIVE_INVENTORY, passive Eigenschaft; zeigt an, dass das
+             Objekt empfindlich auf aktive Objekte reagiert, die in das
+             Inventory des Containers hineinbewegt werden
+          2) SENSITIVE_ATTACK, passive Eigenschaft; zeigt an, dass das 
+             Objekt empfindlich auf aeussere Einfluesse bzw. Angriffe 
+             auf ein Lebewesen reagiert, in dessen Inventar es sich befindet
+          3) SENSITIVE_INVENTORY_TRIGGER, aktive Eigenschaft; zeigt an, dass
+             das Objekt eine Ausstrahlung auf andere Objekte im Inventar
+             hat. Wird ausgeloest, wenn das Objekt ins Inventar hineinbewegt
+             wird.
+     damtype: eine Schadensart (DT_FIRE, DT_WATER, ...)
+     treshold: hat zwei Bedeutungen abhaengig von dem Wert in list_key:
+          1) Fuer Objekte mit SENSITIVE_INVENTORY oder SENSITIVE_ATTCK ist
+             dies der Schadenswert, ab dem das Objekt benachrichtigt werden 
+             soll.
+             Hier wird ein Wert in "Defend-Einheiten" erwartet, d.h. das
+             Zehnfache dessen, was am Ende in LP abgezogen wuerde.
+          2) Fuer Objekte mit SENSITIVE_INVENTORY_TRIGGER ist dies der 
+             Schadenswert, mit dem das Objekt andere bereits im Inventar
+             des Containers befindliche Objekte beeinflusst, die eine 
+             entsprechende Empfindlichkeit gesetzt haben
+     options: Optionale Daten, die der programmierende Magier selbst
+            definieren kann. Werden an die in den betroffenen Objekten
+            aufgerufenen Funktionen durchgereicht.
+
+     Ein SENSITIVE_ATTACK-Objekt, dessen Trigger-Bedingungen erfuellt sind,
+     wird durch folgenden Funktionsaufruf darueber informiert:
+       trigger_sensitive_attack(object enemy, string damtype, int damage,
+                 mixed spell, mixed options)
+
+     
+
+     Ein SENSITIVE_INVENTORY-Objekt, dessen Trigger-Bedingungen erfuellt sind,
+     wird durch folgenden Funktionsaufruf darueber informiert:
+       trigger_sensitive_inv(object whodid, string damtype, int threshold,
+                 mixed options, mixed options)
+
+     Die beiden Funktionen muessen selbst ge-/ueberschrieben werden.
+
+BEMERKUNGEN
+-----------
+::
+
+     1. P_SENSITIVE-Objekte kosten Rechenzeit bei jedem Angriff oder jedem
+        move() - daher bitte sparsam verwenden
+     2. Ist P_SENSITIVE nicht statisch, sondern wird es situationsabhaengig 
+        geaendert, muss man das environment() jeweils selbst ueber seine 
+        neue Empfindlichkeit benachrichtigen. Dies geschieht mit den 
+        Funktionen RemoveSensitiveObject() bzw.InsertSensitiveObject(), 
+        siehe deren Manpages.
+
+BEISPIEL
+--------
+::
+
+     Beispiel 1:
+     Beispielcode eines Objektes mit SENSITIVE_ATTACK und SENSITIVE_INVENTORY
+     siehe hier: /doc/beispiele/testobjekte/attack_busy_sensitive_testobj.c
+
+     Beispiel 2:
+     Ein Eiszapfen, der bei Feuerangriffen oder bei heissen Gegenstaenden im
+     gemeinsamen Environment zerschmelzen soll:
+
+     void create() {
+       SetProp( P_SENSITIVE, ({ ({SENSITIVE_ATTACK,     DT_FIRE, 100}),
+                                 ({SENSITIVE_INVENTORY, DT_FIRE, 100}) }) );
+       [...]
+     }
+
+     varargs void trigger_sensitive_attack() {
+       remove();
+     }
+
+     varargs void trigger_sensitive_inv() {
+       call_out("remove",0);  // verzoegert, wegen move()
+     }
+
+     varargs int remove(int silent) {
+       if(!silent) {
+         object room = all_environment(this_object())[<1];
+         tell_room(room, Name()+" zerschmilzt.\n");
+       }
+       return ::remove();
+     }
+
+     - wird eine Fackel mit
+       SetProp(P_SENSITIVE,({({SENSITIVE_INVENTORY_TRIGGER,DT_FIRE,250})}))
+       in das gleiche environment() wie dieser Zapfen bewegt wird, loest
+       diese im Zapfen trigger_sensitive_inv() aus
+     - wird ein Angriff mit DT_FIRE und initialem Schaden > 100 auf das
+       environment() veruebt, loest dies im Zapfen trigger_sensitive_attack()
+       aus
+
+SIEHE AUCH
+----------
+::
+
+     Properties: P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY,
+                 P_SENSITIVE_INVENTORY_TRIGGER
+     Funktionen: InsertSensitiveObject(L), RemoveSensitiveObject(L),
+                 CheckSensitiveAttack(L), Defend(), 
+                 insert_sensitive_inv(L), insert_sensitive_inv_trigger(L),
+                 trigger_sensitive_inv(L), trigger_sensitive_attack(L)
+     Defines:    /sys/sensitive.h
+
+Letzte Aenderung: 10. Januar 2015, Arathorn
+
diff --git a/doc/sphinx/props/P_SENSITIVE_ATTACK.rst b/doc/sphinx/props/P_SENSITIVE_ATTACK.rst
new file mode 100644
index 0000000..818fb06
--- /dev/null
+++ b/doc/sphinx/props/P_SENSITIVE_ATTACK.rst
@@ -0,0 +1,42 @@
+P_SENSITIVE_ATTACK
+==================
+
+NAME
+----
+::
+
+    P_SENSITIVE_ATTACK            "sensitive_attack"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/sensitive.h
+
+BESCHREIBUNG
+------------
+::
+
+    Hier steht die Liste der zu informierenden Objekte, die potentiell
+    auf einen Angriff reagieren koennten.
+    Wird von InsertSensitiveObject() und RemoveSensitiveObject()
+    geschrieben und in CheckSensitiveAttack() ausgewertet.
+
+BEMERKUNGEN
+-----------
+::
+
+    Nicht selbst veraendern - bitte P_SENSITIVE fuer Eintraege benutzen.
+
+SIEHE AUCH
+----------
+::
+
+     P_SENSITIVE
+     InsertSensitiveObject, RemoveSensitiveObject
+     insert_sensitive_inv_trigger, insert_sensitive_inv
+     P_SENSITIVE_INVENTORY_TRIGGER, P_SENSITIVE_INVENTORY
+     CheckSensitiveAttack
+
+25.Apr.2001, Gloinson@MG
+
diff --git a/doc/sphinx/props/P_SENSITIVE_INVENTORY.rst b/doc/sphinx/props/P_SENSITIVE_INVENTORY.rst
new file mode 100644
index 0000000..5ecec2d
--- /dev/null
+++ b/doc/sphinx/props/P_SENSITIVE_INVENTORY.rst
@@ -0,0 +1,43 @@
+P_SENSITIVE_INVENTORY
+=====================
+
+NAME
+----
+::
+
+    P_SENSITIVE_INVENTORY         "sensitive_inv"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/sensitive.h
+
+BESCHREIBUNG
+------------
+::
+
+    Hier steht die Liste der zu informierenden Objekte, die potentiell
+    auf ein anderes Objekt mit gesetztem P_SENSITIVE_INVENTORY_TRIGGER
+    reagieren koennten.
+    Wird von InsertSensitiveObject() und RemoveSensitiveObject()
+    geschrieben.
+
+BEMERKUNGEN
+-----------
+::
+
+    Nicht selbst veraendern - bitte P_SENSITIVE fuer Eintraege benutzen.
+
+SIEHE AUCH
+----------
+::
+
+     P_SENSITIVE
+     InsertSensitiveObject, RemoveSensitiveObject
+     insert_sensitive_inv_trigger, insert_sensitive_inv
+     P_SENSITIVE_INVENTORY_TRIGGER, P_SENSITIVE_ATTACK
+     CheckSensitiveAttack
+
+25.Apr.2001, Gloinson@MG
+
diff --git a/doc/sphinx/props/P_SENSITIVE_INVENTORY_TRIGGER.rst b/doc/sphinx/props/P_SENSITIVE_INVENTORY_TRIGGER.rst
new file mode 100644
index 0000000..94beaae
--- /dev/null
+++ b/doc/sphinx/props/P_SENSITIVE_INVENTORY_TRIGGER.rst
@@ -0,0 +1,42 @@
+P_SENSITIVE_INVENTORY_TRIGGER
+=============================
+
+NAME
+----
+::
+
+    P_SENSITIVE_INVENTORY_TRIGGER "sensitive_inv_trigger"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/sensitive.h
+
+BESCHREIBUNG
+------------
+::
+
+    Hier steht die Liste der aktiven Objekte, die eine potentielle
+    "Ausstrahlung" auf andere Objekte haben.
+    Wird von InsertSensitiveObject() und RemoveSensitiveObject()
+    geschrieben.
+
+BEMERKUNGEN
+-----------
+::
+
+    Nicht selbst veraendern - bitte P_SENSITIVE fuer Eintraege benutzen.
+
+SIEHE AUCH
+----------
+::
+
+     P_SENSITIVE
+     InsertSensitiveObject, RemoveSensitiveObject
+     insert_sensitive_inv_trigger, insert_sensitive_inv
+     P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY
+     CheckSensitiveAttack
+
+25.Apr.2001, Gloinson@MG
+
diff --git a/doc/sphinx/props/P_SHOOTING_AREA.rst b/doc/sphinx/props/P_SHOOTING_AREA.rst
new file mode 100644
index 0000000..b331623
--- /dev/null
+++ b/doc/sphinx/props/P_SHOOTING_AREA.rst
@@ -0,0 +1,38 @@
+P_SHOOTING_AREA
+===============
+
+NAME
+----
+::
+
+    P_SHOOTING_AREA     "shooting_area"
+
+DEFINIERT IN
+------------
+::
+
+    <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+    Legt die 'Groesse' eines Raumes fest. Ein Schuetze kann mit seiner
+    Fernkampfwaffe nur dann aus diesem Raum in einen anderen Raum schiessen,
+    wenn die P_RANGE seiner Waffe mindestens gleich ist.
+
+    Erreichbare Raeume sind entweder das environment() oder der in
+    P_SHOOTING_AREA festgelegte Raum.
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
+    Methoden:  FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
+    Gebiet:    P_RANGE, P_TARGET_AREA
+    Raeume:    P_NEVER_CLEAN
+    Sonstiges: fernwaffen
+
+29.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/props/P_SHOOTING_WC.rst b/doc/sphinx/props/P_SHOOTING_WC.rst
new file mode 100644
index 0000000..06c1759
--- /dev/null
+++ b/doc/sphinx/props/P_SHOOTING_WC.rst
@@ -0,0 +1,48 @@
+P_SHOOTING_WC
+=============
+
+NAME
+----
+::
+
+    P_SHOOTING_WC     "shooting_wc"
+
+DEFINIERT IN
+------------
+::
+
+    <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+    Legt in einer Fernkampfwaffe UND ihrer Munition die Waffenstaerke fest.
+    Bei einem Schuss wird die Summe kombiniert mit der Geschicklichkeit
+    zur Berechnung der Angriffstaerke benutzt.
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_SHOOTING_WC, 70);     // Langbogen
+    SetProp(P_SHOOTING_WC, 50);     // Kurzbogen
+
+    SetProp(P_SHOOTING_WC, 40);     // Bambuspfeil
+    SetProp(P_SHOOTING_WC, 60);     // Aluminiumpfeil
+
+    // So haetten Langbogen mit Aluminiumpfeil eine P_SHOOTING_WC von 70+60.
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_AMMUNITION, P_STRETCH_TIME
+    Methoden:  FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
+    Gebiet:    P_RANGE, P_SHOOTING_AREA, P_TARGET_AREA
+    Waffen:    P_WEAPON_TYPE, P_WC, P_EQUIP_TIME, P_NR_HANDS
+    Kampf:     Attack(L), Defend(L), P_DISABLE_ATTACK, P_ATTACK_BUSY
+    Sonstiges: fernwaffen
+
+29.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/props/P_SHORT.rst b/doc/sphinx/props/P_SHORT.rst
new file mode 100644
index 0000000..34d23e5
--- /dev/null
+++ b/doc/sphinx/props/P_SHORT.rst
@@ -0,0 +1,61 @@
+P_SHORT
+=======
+
+NAME
+----
+::
+
+     P_SHORT				"short"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt die Kurzbeschreibung des Objektes als String 
+     oder Closure (diese muss einen String zurueckgeben).
+
+     ACHTUNG: Die Kurzbeschreibung sollte dabei weder mit einem
+	      Satzzeichen noch mit einem "\n" abgeschlossen sein
+	      (dies wird von den zustaendigen Funktionen erledigt).
+
+     Setzt man diese Property auf 0, so ist das Objekt unsichtbar, allerdings
+     ansprechbar, wenn der Spieler eine ID des Objektes kennt. D.h. Objekte
+     koennen mitgenommen, weggeworfen oder ggf. auch angegriffen werden. Will
+     man dies nicht, sollte man das Objekt mit P_INVIS unsichtbar machen.
+
+     Diese Property bestimmt die Ansicht des Objektes von aussen. Fuer die
+     Innen(kurz)ansicht von Raeumen muss man P_INT_LONG benutzen.
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Funktion, die die Kurzbeschreibung ausgibt (short()), filtert P_SHORT
+     durch process_string(). Von der Nutzung dieses Features wird in neuem
+     Code abgeraten.
+     Soll eine dyn. Kurzbeschreibung geschaffen werden, bitte eine
+     F_QUERY_METHOD einsetzen oder short() passend ueberschreiben.
+
+BEISPIELE
+---------
+::
+
+     // eine Axt sieht natuerlich so aus:
+     SetProp(P_SHORT, "Eine Axt");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	P_LONG, short()
+     Sonstiges:		P_INT_SHORT, process_string()
+
+
+27.05.2015, Zesstra
+
diff --git a/doc/sphinx/props/P_SHORT_CWD.rst b/doc/sphinx/props/P_SHORT_CWD.rst
new file mode 100644
index 0000000..a76cb42
--- /dev/null
+++ b/doc/sphinx/props/P_SHORT_CWD.rst
@@ -0,0 +1,21 @@
+P_SHORT_CWD
+===========
+
+NAME
+----
+::
+
+    P_SHORT_CWD                   "short_cwd"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/shells.h
+
+BESCHREIBUNG
+------------
+::
+
+     .readme bei cd ausgeben oder nicht
+
diff --git a/doc/sphinx/props/P_SHOWEMAIL.rst b/doc/sphinx/props/P_SHOWEMAIL.rst
new file mode 100644
index 0000000..abfb6f4
--- /dev/null
+++ b/doc/sphinx/props/P_SHOWEMAIL.rst
@@ -0,0 +1,23 @@
+P_SHOWEMAIL
+===========
+
+NAME
+----
+::
+
+     P_SHOWEMAIL                        "showemail"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Eintrag, wer die E-Mail im "finger" zu sehen bekommen soll:
+     0, "alle", "freunde"
+     Kann durch "emailanzeige" (/std/player/base.c) geaendert werden.
+
diff --git a/doc/sphinx/props/P_SHOW_ALIAS_PROCESSING.rst b/doc/sphinx/props/P_SHOW_ALIAS_PROCESSING.rst
new file mode 100644
index 0000000..e025ad1
--- /dev/null
+++ b/doc/sphinx/props/P_SHOW_ALIAS_PROCESSING.rst
@@ -0,0 +1,21 @@
+P_SHOW_ALIAS_PROCESSING
+=======================
+
+NAME
+----
+::
+
+    P_SHOW_ALIAS_PROCESSING       "show_alias_processing"       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Arbeit des Parsers beobachten (debugging)
+
diff --git a/doc/sphinx/props/P_SHOW_EXITS.rst b/doc/sphinx/props/P_SHOW_EXITS.rst
new file mode 100644
index 0000000..6949c6a
--- /dev/null
+++ b/doc/sphinx/props/P_SHOW_EXITS.rst
@@ -0,0 +1,31 @@
+P_SHOW_EXITS
+============
+
+NAME
+----
+::
+
+    P_SHOW_EXITS                  "show_exits"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Im Spieler gesetzt, wenn der Spieler die offensichtlichen Ausgaenge
+     immer automatisch sehen will.
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches:	P_HIDE_EXITS
+     Sonstiges:		AddExit(), GetExits(), int_long(), int_short()
+
+11. Mai 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_SHOW_INV.rst b/doc/sphinx/props/P_SHOW_INV.rst
new file mode 100644
index 0000000..c5fea36
--- /dev/null
+++ b/doc/sphinx/props/P_SHOW_INV.rst
@@ -0,0 +1,33 @@
+P_SHOW_INV
+==========
+
+NAME
+----
+::
+
+     P_SHOW_INV "show_inv"
+
+DEFINIERT IN
+------------
+::
+
+     <thing/description.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn diese Property auf einen Wert ungleich 0 gesetzt ist, wird das
+     Objekt, soweit es sich in einem Spieler befindet, in dessen
+     Langbeschreibung angezeigt. Zur Anzeige wird der Name des Objektes
+     verwendet.
+
+SIEHE AUCH
+----------
+::
+
+     /std/thing/description.c
+
+
+Last modified: Sun May 19 20:36:05 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_SHOW_MSG.rst b/doc/sphinx/props/P_SHOW_MSG.rst
new file mode 100644
index 0000000..7430ffb
--- /dev/null
+++ b/doc/sphinx/props/P_SHOW_MSG.rst
@@ -0,0 +1,69 @@
+P_SHOW_MSG
+==========
+
+NAME
+----
+::
+
+    P_SHOW_MSG                          "show_message"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/put_and_get.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mit P_SHOW_MSG kann man die Meldungen, die beim Vorzeigen eines Objektes
+    ausgegeben werden, modifizieren.
+
+    Folgende Werte sind moeglich:
+
+    o 0
+      Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
+
+    o NO_PNG_MSG        == -1
+      Es wird keinerlei Meldung ausgegeben
+
+    o Ein Array aus Strings
+      Der erste String wird an den Spieler ausgegeben, der zweite
+      (optionale) an den Raum, der dritte (ebenfalls optionale) an den
+      Empfaenger.
+
+      Die Strings werden durch die Funktion replace_personal() geparst.
+        Objekt1 - Spieler
+        Objekt2 - das Objekt, das uebergeben wird
+        Objekt3 - Empfaenger
+
+      Wird der zweite String nicht angegeben, erfolgt keine Meldung an den
+      Raum. Beim Fehlen des dritten gibt es keine Meldung an den Empfaenger.
+
+BEISPIEL
+--------
+::
+
+    SetProp(P_SHOW_MSG, ({
+      "Du haeltst @WEM3 @WEN2 unter die Nase.",
+      "@WER1 haelt @WEM3 @WENU2 unter die Nase.",
+      "@WER1 haelt Dir @WENU2 unter die Nase."
+    }));
+
+    Das fuehrt bei Ugars "zeig peter medaille" zu folgenden Meldungen:
+
+    Ugar: "Du haeltst Peter die Medaille unter die Nase."
+    Raum: "Ugar haelt Peter eine Medaille unter die Nase."
+    Peter: "Ugar haelt Dir eine Medaille unter die Nase."
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_DROP_MSG, P_PUT_MSG, P_PICK_MSG, P_GIVE_MSG
+     Sonstiges:  replace_personal(E), show(L), show_objects(L),
+                 show_notify(L), /std/living/put_and_get.c
+
+3. Juni 2008 Amynthor
+
diff --git a/doc/sphinx/props/P_SIBLINGS.rst b/doc/sphinx/props/P_SIBLINGS.rst
new file mode 100644
index 0000000..4b48849
--- /dev/null
+++ b/doc/sphinx/props/P_SIBLINGS.rst
@@ -0,0 +1,22 @@
+P_SIBLINGS
+==========
+
+NAME
+----
+::
+
+    P_SIBLINGS                     "siblings"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Enthaelt einen String mit den Blutsbruedern eines Spielers
+     (sofern vorhanden).
+
diff --git a/doc/sphinx/props/P_SIZE.rst b/doc/sphinx/props/P_SIZE.rst
new file mode 100644
index 0000000..bf6d182
--- /dev/null
+++ b/doc/sphinx/props/P_SIZE.rst
@@ -0,0 +1,50 @@
+P_SIZE
+======
+
+NAME
+----
+::
+
+    P_SIZE                        "size"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Groesse des Lebewesens bzw. Laenge der Waffe (in cm).
+
+     Wird keine Waffenlaenge explizit angegeben, so sind die Defaultwerte
+     fuer die entsprechenden Waffentypen folgende:
+
+    	WT_SWORD  : 100
+    	WT_AXE    :  80
+    	WT_CLUB   :  80
+    	WT_SPEAR  : 180
+    	WT_KNIFE  :  20
+    	WT_WHIP   : 200
+    	WT_STAFF  : 150
+
+BEMERKUNGEN
+-----------
+::
+
+     1. Uebertreibt es bitte mit der Groesse nicht, auch sehr grosse NPCs 
+        sollten nicht ueber 1000000 liegen. Sonst kriegt die Karategilde 
+        Probleme.
+     2. Negative Werte fuer P_SIZE sind nicht moeglich, da dies zum einen
+        voellig unsinnig ist und zum anderen evtl. zu Problemen mit Waffen
+        fuehrt, die Schaden in Abhaengigkeit von P_SIZE machen und sich
+        darauf verlassen, dass nur positive Werte vorkommen.
+
+LETZTE AENDERUNG
+----------------
+::
+
+    2006-09-29, von Zesstra
+
diff --git a/doc/sphinx/props/P_SKILLS.rst b/doc/sphinx/props/P_SKILLS.rst
new file mode 100644
index 0000000..11f06c3
--- /dev/null
+++ b/doc/sphinx/props/P_SKILLS.rst
@@ -0,0 +1,31 @@
+P_SKILLS
+========
+
+NAME
+----
+::
+
+	P_SKILLS			"skills"                      
+
+DEFINIERT IN
+------------
+::
+
+	/sys/player/skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property sollte nicht mehr verwendet werden. Sie wurde
+	vollstaendig durch P_NEWSKILLS ersetzt.
+
+SIEHE AUCH
+----------
+::
+
+	P_NEW_SKILLS
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_SKILL_ATTRIBUTES.rst b/doc/sphinx/props/P_SKILL_ATTRIBUTES.rst
new file mode 100644
index 0000000..6842bfd
--- /dev/null
+++ b/doc/sphinx/props/P_SKILL_ATTRIBUTES.rst
@@ -0,0 +1,69 @@
+P_SKILL_ATTRIBUTES
+==================
+
+NAME
+----
+::
+
+    P_SKILL_ATTRIBUTES        "skill_attr"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/skill_attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Prop stehen alle nicht-permanenten Modifikatoren der
+    Skill-Attribute.
+    Die Datenstruktur ist ein Mapping mit den SA-Namen als Schluessel und
+    jeweils drei Werten pro Schluessel.
+    Der erste Wert ist ein Array mit drei Werten: der Summe der stat.
+    Modifier, dem Zeitpunkt an dem dies Summe ungueltig wird und der
+    Gesamtzahl aktiver Modifikatoren.
+    Der zweite Wert enthaelt ein Mapping mit allen statischen Modifikatoren
+    und den Objekten dieser Mods als Schluessel. Die beiden Werte dieses
+    Mappings sind der Wert des Modifikators (int) und die Ablaufzeit (int).
+    Der dritte Wert enthaelt ein Mapping mit allen dynamischen
+    Modifikatoren und den Objekten dieser Mods als Schluessel. Die beiden
+    Werte dieses Mappings sind die zu rufende Closure (closure) und die
+    Ablaufzeit des Mods (int).
+
+    ([ SA_ATTR: ({Summe_Stat_Modifier, Zeitpunkt, AnzahlModifier, });
+                ([ ob1:value;duration,
+                   ob2:value;duration, ...]);  // stat. Modifier
+                ([ ob1:closure;duration,
+                   ob2:closure;duration, ...])     // dyn. Modifier
+                ,
+       SA_ATTR2: ({...}); ([]); ([]),
+       SA_ATTR3: ({...}); ([]); ([]),
+    ])
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Property darf AUF GAR KEINEN FALL per Hand manipuliert werden,
+    dafuer gibt es die Funktionen ModifySkillAttribute() und
+    RemoveSkillAttributeModifier().
+    Zum Auslesen stehen QuerySkillAttribute() und
+    QuerySkillAttributeModifier() zur Verfuegung.
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkill, QuerySkillAbility
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung, skill_info_liste
+    * Properties:   P_NEWSKILLS
+
+13.09.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_SKILL_ATTRIBUTE_OFFSETS.rst b/doc/sphinx/props/P_SKILL_ATTRIBUTE_OFFSETS.rst
new file mode 100644
index 0000000..cd0c619
--- /dev/null
+++ b/doc/sphinx/props/P_SKILL_ATTRIBUTE_OFFSETS.rst
@@ -0,0 +1,49 @@
+P_SKILL_ATTRIBUTE_OFFSETS
+=========================
+
+NAME
+----
+::
+
+    P_SKILL_ATTRIBUTE_OFFSETS       "skill_attr_offsets"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/skill_attributes.h
+
+BESHREIBUNG
+-----------
+::
+
+    Der Wert der Property ist ein Mapping: ([Attributname: Wert])
+    In dieser Property stehen permanente Abweichungen der Skillattribute
+    vom Standardwert 100.
+
+    Zu den Moeglichen Attributwerten, siehe P_SKILL_ATTRIBUTES.
+
+    Die Werte duerfen zwischen 10 und 1000 liegen.
+
+BEMERKUNG
+---------
+::
+
+    Diese Property sollte AUF GAR KEINEN FALL in einem Spieler gesetzt
+    werden, ohne Ruecksprachen mit allerhoechsten Stellen!
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkill, QuerySkillAbility
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung, skill_info_liste
+    * Properties:   P_NEWSKILLS
+
+31.12.2013, Zesstra
+
diff --git a/doc/sphinx/props/P_SMELLS.rst b/doc/sphinx/props/P_SMELLS.rst
new file mode 100644
index 0000000..ec53aa6
--- /dev/null
+++ b/doc/sphinx/props/P_SMELLS.rst
@@ -0,0 +1,43 @@
+P_SMELLS
+========
+
+NAME
+----
+::
+
+    P_SMELLS            "smell_details"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property entspricht dem P_DETAILS fuer Standarddetails,
+    nur werden hierin Gerueche gespeichert:
+    Diese Property enthaelt ein Mapping, in der Details im Objekt
+    definiert werden und Beschreibungen, die ausgegeben werden, wenn man
+    sich diese Details anschaut.
+
+BEMERKUNGEN
+-----------
+::
+
+    Man sollte diese Property nicht per Hand veraendern, sondern die
+    Funktionen nutzen.
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddSmells()
+    Loeschen:  RemoveSmells()
+    Aehnlich:  AddDetail(), P_DETAILS
+    Sonstiges: GetDetail(), break_string()
+
+27. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_SNOOPFLAGS.rst b/doc/sphinx/props/P_SNOOPFLAGS.rst
new file mode 100644
index 0000000..4fe7ec6
--- /dev/null
+++ b/doc/sphinx/props/P_SNOOPFLAGS.rst
@@ -0,0 +1,21 @@
+P_SNOOPFLAGS
+============
+
+NAME
+----
+::
+
+    P_SNOOPFLAGS                  "snoopflags"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/snooping.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_SOUNDS.rst b/doc/sphinx/props/P_SOUNDS.rst
new file mode 100644
index 0000000..6ba71ad
--- /dev/null
+++ b/doc/sphinx/props/P_SOUNDS.rst
@@ -0,0 +1,43 @@
+P_SOUNDS
+========
+
+NAME
+----
+::
+
+    P_SOUNDS            "sound_details"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property entspricht dem P_DETAILS fuer Standarddetails,   
+    nur werden hierin Gerauesche gespeichert:
+    Diese Property enthaelt ein Mapping, in der Details im Objekt
+    definiert werden und Beschreibungen, die ausgegeben werden, wenn man
+    sich diese Details anschaut.
+
+BEMERKUNGEN
+-----------
+::
+
+    Man sollte diese Property nicht per Hand veraendern, sondern die
+    Funktionen nutzen.
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddSounds()
+    Loeschen:  RemoveSounds()
+    Aehnlich:  AddDetail(), P_DETAILS
+    Sonstiges: GetDetail(), break_string()
+
+27. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_SP.rst b/doc/sphinx/props/P_SP.rst
new file mode 100644
index 0000000..33978ef
--- /dev/null
+++ b/doc/sphinx/props/P_SP.rst
@@ -0,0 +1,38 @@
+P_SP
+====
+
+NAME
+----
+::
+
+    P_SP                          "sp"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     - Lebewesen
+       Anzahl der Konzentrationspunkte des Wesens.
+
+     - Speisen/Kneipen
+       Heilwirkung einer Portion der Speise auf die Konzentrationspunkte
+       des Konsumenten
+
+SIEHE AUCH
+----------
+::
+
+     Props:		P_MAX_SP
+     Veraenderung:	reduce_spell_points(), restore_spell_points()
+			buffer_sp()
+     Speisen/Kneipen:   std/pub, wiz/food, consume
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_SPECIAL_DETAILS.rst b/doc/sphinx/props/P_SPECIAL_DETAILS.rst
new file mode 100644
index 0000000..e8f7c2b
--- /dev/null
+++ b/doc/sphinx/props/P_SPECIAL_DETAILS.rst
@@ -0,0 +1,42 @@
+P_SPECIAL_DETAILS
+=================
+
+NAME
+----
+::
+
+    P_SPECIAL_DETAILS             "special_details"             
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mapping von Details, die beim Anschauen eine Funktion starten.
+
+BEMERKUNGEN
+-----------
+::
+
+    Dies ist keine "echte" Property. Die Daten werden bei der Abfrage in einer
+    Querymethode dynamisch aus P_DETAILS extrahiert. Dementsprechend
+    funktioniert es auch nicht, hier eine Query- oder Setmethode von aussen
+    drauf zu legen.
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddDetail()
+    Loeschen:  RemoveDetail()
+    Daten:     P_DETAILS
+    Veraltet:  AddSpecialDetail(), RemoveSpecialDetail()
+    Sonstiges: GetDetail(), break_string()
+
+27. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_SPECIAL_EXITS.rst b/doc/sphinx/props/P_SPECIAL_EXITS.rst
new file mode 100644
index 0000000..8a11c3e
--- /dev/null
+++ b/doc/sphinx/props/P_SPECIAL_EXITS.rst
@@ -0,0 +1,51 @@
+P_SPECIAL_EXITS
+===============
+
+NAME
+----
+::
+
+    P_SPECIAL_EXITS               "special_exits"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt ein Mapping (der Breite 2) mit den Ausgaengen, der Funktion,
+    die jeweils gerufen wird, wenn der Ausgang benutztwird und einer
+    Bewegungsmeldung.
+
+    
+
+    Die Bewegungsmeldung wird bei SpecialExits nicht ausgewertet, sondern
+    ist nur aufgrund der gemeinsamen Datenstruktur vorhanden. Im Normalfall
+    ist sie 0.
+
+BEMERKUNG
+---------
+::
+
+    Keine echte Property, wird bei der Abfrage aus P_EXITS erstellt.
+
+    
+
+    Zugriff nur mit den dafuer vorgesehenen Funktionen, nicht aendern!
+
+SIEHE AUCH
+----------
+::
+
+     AddExit(), AddSpecialExit(), GetExits(),
+     RemoveExit(), RemoveSpecialExit(),
+     GuardExit(),
+     H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
+     ausgaenge
+
+Letzte Aenderung: 22.12.2016, Bugfix
+
diff --git a/doc/sphinx/props/P_SPELLRATE.rst b/doc/sphinx/props/P_SPELLRATE.rst
new file mode 100644
index 0000000..b6e8249
--- /dev/null
+++ b/doc/sphinx/props/P_SPELLRATE.rst
@@ -0,0 +1,21 @@
+P_SPELLRATE
+===========
+
+NAME
+----
+::
+
+    P_SPELLRATE                   "spellrate"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     NPC-Spellrate (in %)
+
diff --git a/doc/sphinx/props/P_SPELLS.rst b/doc/sphinx/props/P_SPELLS.rst
new file mode 100644
index 0000000..560912b
--- /dev/null
+++ b/doc/sphinx/props/P_SPELLS.rst
@@ -0,0 +1,21 @@
+P_SPELLS
+========
+
+NAME
+----
+::
+
+    P_SPELLS                      "spells"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     NPC-Spells
+
diff --git a/doc/sphinx/props/P_SP_DELAY.rst b/doc/sphinx/props/P_SP_DELAY.rst
new file mode 100644
index 0000000..9e72d2c
--- /dev/null
+++ b/doc/sphinx/props/P_SP_DELAY.rst
@@ -0,0 +1,23 @@
+P_SP_DELAY
+==========
+
+NAME
+----
+::
+
+    P_SP_DELAY                 "sp_delay"                     
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der heart_beats, bis die Magiepunkte um einen Punkt steigen.
+     Aenderungen dieser Property in Spielern beduerfen der 
+     Genehmigung des EM fuer Balance.
+
diff --git a/doc/sphinx/props/P_START_HOME.rst b/doc/sphinx/props/P_START_HOME.rst
new file mode 100644
index 0000000..f81b611
--- /dev/null
+++ b/doc/sphinx/props/P_START_HOME.rst
@@ -0,0 +1,21 @@
+P_START_HOME
+============
+
+NAME
+----
+::
+
+    P_START_HOME                  "start_home"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Raum, in dem der Spieler nach dem Einloggen landen soll
+
diff --git a/doc/sphinx/props/P_STD_OBJECT.rst b/doc/sphinx/props/P_STD_OBJECT.rst
new file mode 100644
index 0000000..6e3e583
--- /dev/null
+++ b/doc/sphinx/props/P_STD_OBJECT.rst
@@ -0,0 +1,59 @@
+P_STD_OBJECT
+============
+
+NAME
+----
+::
+
+    P_STD_OBJECT                  "std_object"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/v_compiler.h
+
+BESCHREIBUNG
+------------
+::
+
+   Enthaelt den Namen eines Files welches als Standard-Objekt fuer den 
+   Virtual Compiler gelten soll.
+
+   In diesem File werden das generelle Aussehen, Ausgaenge, Funktionen
+   usw. der VC-generierten Raeume / Objekte festgelegt.
+
+   Dieses File ist ein 'normales' .c - File, welches geclont wird und
+   anschliessend umbenannt wird.
+
+   
+
+   Ganz wichtig: Falls euer Standardobjekt (direkt oder indirekt) von
+   /std/room.c erbt, solltet ihr darauf achten, dass euer Objekt ausser dem
+   create() noch eine weitere (beliebige) Funktion hat.  
+   Ansonsten wuerde das Programm eures Standardobjekts automatisch durch
+   /std/room.c ersetzt, was in der Regel zu schwer zu findenen Bugs fuehrt.
+
+BEISPIEL
+--------
+::
+
+   (create eines VCs)
+   protected void create() {
+     ...
+     SetProp(P_STD_OBJECT,"/d/region/magier/vc/std_raum");
+     ...
+   }
+
+   Was in diesem std_raum.c nun steht, wird in jedem VC-Clone
+   verfuegbar. Sei es Details, Gerueche, auch Objekte die per 
+   AddItem eingebunden sind, ...
+
+SIEHE AUCH
+----------
+::
+
+   P_COMPILER_PATH, virtual_compiler
+
+Letzte Aenderung: 22.10.07 von Zesstra
+
diff --git a/doc/sphinx/props/P_STORE_CONSUME.rst b/doc/sphinx/props/P_STORE_CONSUME.rst
new file mode 100644
index 0000000..aa5737a
--- /dev/null
+++ b/doc/sphinx/props/P_STORE_CONSUME.rst
@@ -0,0 +1,70 @@
+P_STORE_CONSUME
+===============
+
+NAME
+----
+::
+
+	P_STORE_CONSUME			"store_consume"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/bank.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property ist entscheidend dafuer, wieviel Prozent an Objekten
+	bei jedem Reset in einem Lager eines Ladens vernichtet werden. Dies
+	geschieht aus Speicher- und Laggruenden. Es verbleibt dabei jedoch
+	eine Grundmenge an Objekten, deren Anzahl in der Property
+	P_MIN_STOCK festgehalten ist. Standardwert fuer P_STORE_CONSUME ist
+	hierbei 30%, aber in oft benutzten Laeden kann man dort ruhig einen
+	hoeheren Wert eintragen. Erlaubt sind Werte zwischen 0% und 100%.
+	Aufgeraeumt werden jedoch keine Objekte, die mittels AddItem() im
+	Lager eingebunden wurden. Mittels der Ladenfunktion AddFixedObject()
+	als staendig verfuegbar markierte Objekte werden natuerlich auch
+	nicht beruecksichtigt.
+	Beide hier erwaehnten Properties sollten ueberigens nur mittels
+	QueryProp/SetProp ausgelesen bzw. veraendert werden.
+
+BEISPIEL
+--------
+::
+
+	Ein eigener haeufig benutzter Laden koennte ein Lager in folgender
+	Form erhalten:
+	  // myStore
+	  #include <bank.h>
+	  inherit "std/store";
+	  void create()
+	  { ::create();
+	    SetProp(P_STORE_CONSUME,90);
+	    // keine weiteren Beschreibungen, Spieler sollen da drin
+	    // schliesslich nicht rumwuseln
+	  }
+	Um das Lager dem Laden zuzuweisen, nutzt man folgendes:
+	  // myShop
+	  inherit "std/laden";
+	  void create()
+	  { ::create();
+	    SetStorageRoom("pfad/myStore");
+	    // Beschreibungen folgen
+	    ...
+	  }
+	Es werden hierbei waehrend jedes Lager-Resets 90% der im Lager
+	befindlichen Objekte vernichtet.
+
+SIEHE AUCH
+----------
+::
+
+	P_MIN_STOCK, SetStorageRoom(), /std/store.c, /std/shop.c
+	AddItem(), RemoveItem(), AddFixedObject(), RemoveFixedObject()
+
+
+Last modified: 19-Jun-2015, Arathorn 
+
diff --git a/doc/sphinx/props/P_STRETCH_TIME.rst b/doc/sphinx/props/P_STRETCH_TIME.rst
new file mode 100644
index 0000000..b2e7aa7
--- /dev/null
+++ b/doc/sphinx/props/P_STRETCH_TIME.rst
@@ -0,0 +1,34 @@
+P_STRETCH_TIME
+==============
+
+NAME
+----
+::
+
+    P_STRETCH_TIME     "stretch_time"
+
+DEFINIERT IN
+------------
+::
+
+    <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt die Zeit in Runden (2s), die man braucht, um eine Fernwaffe zu
+    spannen/benutzen. Zaehlt seit dem letzten Schuss oder der Zeit des
+    Zueckens (P_EQUIP_TIME).
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_AMMUNITION, P_SHOOTING_WC
+    Methoden:  FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
+    Gebiet:    P_RANGE, P_SHOOTING_AREA, P_TARGET_AREA
+    Sonstiges: fernwaffen
+
+29.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/props/P_SUBGUILD_TITLE.rst b/doc/sphinx/props/P_SUBGUILD_TITLE.rst
new file mode 100644
index 0000000..5759932
--- /dev/null
+++ b/doc/sphinx/props/P_SUBGUILD_TITLE.rst
@@ -0,0 +1,38 @@
+P_SUBGUILD_TITLE
+================
+
+NAME
+----
+::
+
+     P_SUBGUILD_TITLE		"subguild_title"                       
+
+DEFINIERT IN
+------------
+::
+
+     /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt eventuelle Zusatztitel eines Spielers, den er
+     innerhalb einer Gilde traegt. Das kann z.B. ein Clan sein, ein Zweig oder
+     einfach nur der Gildenrang.
+
+BEMERKUNGEN
+-----------
+::
+
+     Inhalt der Property kann 0 sein oder ein String.  Ein Zusatztitel kann
+     mittels P_VISIBLE_SUBGUILD_TITLE vorgetaeuscht werden.
+
+SIEHE AUCH
+----------
+::
+
+     P_GUILD_TITLE, P_VISIBLE_SUBGUILD_TITLE
+
+26. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_SYNTAX_HELP.rst b/doc/sphinx/props/P_SYNTAX_HELP.rst
new file mode 100644
index 0000000..04710b4
--- /dev/null
+++ b/doc/sphinx/props/P_SYNTAX_HELP.rst
@@ -0,0 +1,62 @@
+P_SYNTAX_HELP
+=============
+
+NAME
+----
+::
+
+    P_SYNTAX_HELP              "lib_p_syntax_help"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/commands.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Property kann man fuer Spieler eine ausfuehrliche Syntaxhilfe zu
+    den Kommandos eines Objektes ablegen. Diese wird angezeigt, wenn der
+    Spieler das Kommando "synxtaxhilfe <objekt>" eingibt.
+    Die Property kann verschiedene Datenstrukturen enthalten:
+
+    1) ein String
+    Der String wird angezeigt, hierbei ggf. umgebrochen, vorhandene
+    Zeilenumbrueche werden beibehalten.
+
+    2) ein Array: ({hilfetext, bedingungen})
+
+    <hilfetext>:
+      * ein string:
+        Der String wird angezeigt, hierbei ggf. umgebrochen, vorhandene
+        Zeilenumbrueche werden beibehalten.
+      * eine lfun-closure:
+        Diese erhaelt beim Aufruf das betreffende Objekt als Argument.
+        Wenn diese dann einen String zurueckliefert, wird dieser dem Spieler
+        angezeigt. Hierbei wird ggf. umgebrochen, vorhandene Zeilenumbrueche
+        werden beibehalten.
+
+    <bedingungen>, welche erfuellt sein muessen, damit dem Spieler die Hilfe
+    angezeigt wird. Die Bedingungen sind entweder:
+      * ein Mapping fuer check_restriction()
+      * eine lfun-closure
+        Diese erhaelt beim Aufruf das betreffende Objekt als Argument und darf
+        eine 0 fuer 'erlaubt', 1 fuer 'nicht erlaubt (mit Standardtext)' oder
+        einen string fuer 'nicht erlaubt mit individuellem Text' sein.
+
+BEMERKUNGEN
+-----------
+::
+
+    Hat ein Objekt keine Syntaxhilfe, wird das Kommando "syntaxhilfe" aus dem
+    Objekt wieder entfernt (d.h. die Property muss gesetzt sein, bevor der
+    erste Spieler das Kommando eingibt).
+
+SIEHE AUCH
+----------
+::
+
+    AddCmd
+
diff --git a/doc/sphinx/props/P_TARGET_AREA.rst b/doc/sphinx/props/P_TARGET_AREA.rst
new file mode 100644
index 0000000..e6d3f44
--- /dev/null
+++ b/doc/sphinx/props/P_TARGET_AREA.rst
@@ -0,0 +1,95 @@
+P_TARGET_AREA
+=============
+
+NAME
+----
+::
+
+    P_TARGET_AREA     "target_area"
+
+DEFINIERT IN
+------------
+::
+
+    <combat.h>
+
+BESCHREIBUNG
+------------
+::
+
+    Kann in einem Raum gesetzt werden, um einen anderen, von dort aus mit
+    Fernkampfwaffen beschiessbaren Raum als Objekt oder Objektnamen (zu
+    einem geladenen Objekt) festzulegen.
+
+BEMERKUNGEN
+-----------
+::
+
+    Ein Schuetze kann nur in den anderen Raum schiessen, wenn die P_RANGE
+    seiner Waffe mindest gleich der P_SHOOTING_AREA des Raums (nicht des
+    Zielraums) ist.
+
+    Idealerweise sollte in mit P_TARGET_AREA angegebenen Raeumen auch
+    P_NEVER_CLEAN gesetzt sein.
+
+BEISPIELE
+---------
+::
+
+    // #1 Ein Baum-Raum (/std/room)
+    void create() {
+      ::create();
+      SetProp(P_INT_SHORT, "Auf einem Baum");
+      SetProp(P_INT_LONG, break_string("Du hockst auf einem Baum und kannst "
+        "auf die Lichtung unter Dir sehen.\n");
+
+      AddExit("unten", RAEUME("lichtung"));
+
+      SetProp(P_TARGET_AREA, RAEUME("lichtung"));  // Lichtung beschiessbar
+      SetProp(P_SHOOTING_AREA, 15);                // 15 Entfernung
+    }
+
+    // #2 Ein Elefanten-Transporter (/std/transport)
+    // Er trampelt durch mehrere Raeume durch und der Schuetze kann vom
+    // Ruecken des Elefanten aus auf Gegner draussen schiessen.
+    void create() {
+      ::create();
+      SetProp(P_NAME, "Kampfelefant");
+      AddId(({"elefant", "kampfelefant")});
+      SetProp(P_GENDER, MALE);
+      SetProp(P_SHORT, "Ein Kampfelefant");
+      SetProp(P_INT_SHORT, "Auf einem Kampfelefanten");
+      // P_LONG, P_INT_LONG
+
+      SetProp(P_ENTERCMDS, ({"kletter", "erkletter"}));
+      SetProp(P_LEAVECMDS, ({"verlass", "verlasse"}));
+
+      SetProp(P_ARRIVEMSG, ({"Der Elefant trampelt in einen Raum.\n",
+                             "Ein Kampfelefant trampelt herein.\n"}));
+      SetProp(P_DEPARTMSG, ({"Der Elefant trampelt weiter.\n",
+                             "Der Kampfelefant trampelt weiter.\n"}));
+
+      SetProp(P_SHOOTING_AREA, 8); // weiter als 8 sollte man schiessen
+
+      AddRoute(RAEUME("schlachtfeld"), 20+random(10), 6, "Schlachtfeld");
+      AddRoute(RAEUME("burgtor"), 20+random(10), 6, "Burgtor");
+      AddRoute(RAEUME("burghof"), 20+random(10), 6, "Burghof");
+      AddRoute(RAEUME("halle"), 20+random(10), 6, "Halle");
+      AddRoute(RAEUME("bresche"), 20+random(10), 6, "Bresche");
+      // ...
+
+      Start();
+    }
+
+SIEHE AUCH
+----------
+::
+
+    Generell:  P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
+    Methoden:  FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
+    Gebiet:    P_RANGE, P_SHOOTING_AREA
+    Raeume:    P_NEVER_CLEAN
+    Sonstiges: fernwaffen
+
+29.Jul 2014 Gloinson
+
diff --git a/doc/sphinx/props/P_TEAM.rst b/doc/sphinx/props/P_TEAM.rst
new file mode 100644
index 0000000..0d8a798
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM.rst
@@ -0,0 +1,40 @@
+P_TEAM
+======
+
+NAME
+----
+::
+
+	P_TEAM                         "team"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Liefert das Teamobjekt, falls Spieler in einem Team ist, sonst 0.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD, P_TEAM_AUTOFOLLOW,
+                    P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
+                    P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_ASSOC_MEMBERS.rst b/doc/sphinx/props/P_TEAM_ASSOC_MEMBERS.rst
new file mode 100644
index 0000000..8093109
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_ASSOC_MEMBERS.rst
@@ -0,0 +1,49 @@
+P_TEAM_ASSOC_MEMBERS
+====================
+
+NAME
+----
+::
+
+	P_TEAM_ASSOC_MEMBERS           "team_assoc_members"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Array mit den zugeordneten NPCs des Spielers bzw. der Spieler,
+	dem dieser NPC zugeordnet ist.
+	Zugeordnete NPCs sind automatisch im Team des Spielers.
+
+BEMERKUNG
+---------
+::
+
+	Der Zugriff auf diese Property sollte ueber AssocMember()
+	bzw. DeAssocMember() erfolgen.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_TEAM_ATTACK_CMD, P_TEAM_AUTOFOLLOW,
+                    P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
+                    P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_ATTACK_CMD.rst b/doc/sphinx/props/P_TEAM_ATTACK_CMD.rst
new file mode 100644
index 0000000..67fb26d
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_ATTACK_CMD.rst
@@ -0,0 +1,40 @@
+P_TEAM_ATTACK_CMD
+=================
+
+NAME
+----
+::
+
+	P_TEAM_ATTACK_CMD              "team_attack_cmd"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Angriffsbefehl des Spielers, nicht setzbar.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_AUTOFOLLOW,
+                    P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
+                    P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_AUTOFOLLOW.rst b/doc/sphinx/props/P_TEAM_AUTOFOLLOW.rst
new file mode 100644
index 0000000..c972faa
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_AUTOFOLLOW.rst
@@ -0,0 +1,40 @@
+P_TEAM_AUTOFOLLOW
+=================
+
+NAME
+----
+::
+
+	P_TEAM_AUTOFOLLOW              "team_autofollow"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Folgewunsch des Spielers, nicht setzbar.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
+                    P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_COLORS.rst b/doc/sphinx/props/P_TEAM_COLORS.rst
new file mode 100644
index 0000000..99ca3a1
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_COLORS.rst
@@ -0,0 +1,41 @@
+P_TEAM_COLORS
+=============
+
+NAME
+----
+::
+
+	P_TEAM_COLORS                  "team_colors"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Grenzwerte fuer farbige Anzeige im Teaminfo.
+	Array mit 4 Werten: ({ lp_rot, lp_gelb, sp_rot, sp_gelb })
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
+                    P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_LEADER.rst b/doc/sphinx/props/P_TEAM_LEADER.rst
new file mode 100644
index 0000000..9ddae0e
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_LEADER.rst
@@ -0,0 +1,40 @@
+P_TEAM_LEADER
+=============
+
+NAME
+----
+::
+
+	P_TEAM_LEADER                  "team_leader"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Liefert das Teamobjekt, falls Spieler Anfuehrer eines Teams ist.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_NEWMEMBER,
+                    P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_NEWMEMBER.rst b/doc/sphinx/props/P_TEAM_NEWMEMBER.rst
new file mode 100644
index 0000000..6c9180c
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_NEWMEMBER.rst
@@ -0,0 +1,41 @@
+P_TEAM_NEWMEMBER
+================
+
+NAME
+----
+::
+
+	P_TEAM_NEWMEMBER               "potential_team_member"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Enthaelt das Objekt des Teamleaders, sobald ein Spieler um
+	Teamaufnahme gebeten hat, sonst 0.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+                    P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+                    P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_WANTED_ROW.rst b/doc/sphinx/props/P_TEAM_WANTED_ROW.rst
new file mode 100644
index 0000000..b590d86
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_WANTED_ROW.rst
@@ -0,0 +1,40 @@
+P_TEAM_WANTED_ROW
+=================
+
+NAME
+----
+::
+
+	P_TEAM_WANTED_ROW              "team_wanted_row"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Gewuenschte Reihe des Spielers (von 1 bis MAX_TEAMROWS)
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD, P_TEAM_AUTOFOLLOW,
+                    P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
+                    P_TEAM_WIMPY_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TEAM_WIMPY_ROW.rst b/doc/sphinx/props/P_TEAM_WIMPY_ROW.rst
new file mode 100644
index 0000000..9a3fe17
--- /dev/null
+++ b/doc/sphinx/props/P_TEAM_WIMPY_ROW.rst
@@ -0,0 +1,47 @@
+P_TEAM_WIMPY_ROW
+================
+
+NAME
+----
+::
+
+	P_TEAM_WIMPY_ROW               "team_wimpy_row"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/team.h
+
+BESCHREIBUNG
+------------
+::
+
+	Fluchtreihe des Spielers, von 1 bis MAX_TEAMROWS.
+
+BEMERKUNG
+---------
+::
+
+	Wenn die Fluchtreihe <=1 ist, ist die Flucht in eine hintere Reihe
+	deaktiviert.
+
+SIEHE AUCH
+----------
+::
+
+        Uebersicht: teamkampf
+        Properties: P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD, P_TEAM_AUTOFOLLOW,
+                    P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
+                    P_TEAM_WANTED_ROW
+        Bewegung:   IsTeamMove, TeamFlee
+        Mitglieder: IsTeamLeader, TeamMembers
+        Kampf:      DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
+                    SelectFarEnemy
+        Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+                    PresentTeamPosition, SwapRows
+        Sonstiges:  TeamPrefix, teamkampf_intern
+
+
+Last modified: 16-08-2010, Gabylon
+
diff --git a/doc/sphinx/props/P_TELNET_RTTIME.rst b/doc/sphinx/props/P_TELNET_RTTIME.rst
new file mode 100644
index 0000000..4064df6
--- /dev/null
+++ b/doc/sphinx/props/P_TELNET_RTTIME.rst
@@ -0,0 +1,43 @@
+P_TELNET_RTTIME
+===============
+
+NAME
+----
+::
+
+    P_TELNET_RTTIME                                  "p_lib_telnet_rttime"
+
+DEFINIERT IN
+------------
+::
+
+    /secure/telnetneg.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Properties steht die letzte gemessene 'round-trip' Zeit
+    (in Mikrosekunden) einer 'Telnet timing mark' vom MUD zum Client und
+    zurueck.
+
+    Voraussetzung hierfuer ist allerdings, dass das Telnet des Spielers
+    Telnetnegotiations unterstuetzt und 'telnet keepalive' eingeschaltet
+    ist, ansonsten bleibt diese Property 0.
+    Die meisten Telnets/Clients antworten zumindest eine Ablehnung auf
+    die 'timing marks', so dass trotzdem eine Zeit bestimmt werden kann.
+
+    Die Prop kann nicht gesetzt werden bzw. es hat keinen Effekt.
+
+SIEHE AUCH
+----------
+::
+
+    P_TTY_COLS, P_TTY_ROWS, P_TTY_SHOW, P_TTY, P_TTY_TYPE
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    03.02.2013, Zesstra
+
diff --git a/doc/sphinx/props/P_TESTPLAYER.rst b/doc/sphinx/props/P_TESTPLAYER.rst
new file mode 100644
index 0000000..3cfd0d7
--- /dev/null
+++ b/doc/sphinx/props/P_TESTPLAYER.rst
@@ -0,0 +1,48 @@
+P_TESTPLAYER
+============
+
+NAME
+----
+::
+
+    P_TESTPLAYER                  "testplayer"                  
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gesetzt, wenn der Spieler ein Testspieler ist. Enthaelt die UID des
+     Magiers, dem dieser Testie (momentan) gehoert.
+
+     
+
+     Bei Testspielern duerfen Skills geaendert werden, sie duerfen gezappt
+     werden und - ihre eigentliche Aufgabe - nicht angeschlossene Gebiete
+     testen.
+
+     AUSNAHMEN: Gildentesties duerfen nur sehr eingeschraenkt manipuliert
+                werden werden, da sie im ganzen Mud rumlaufen koennen,
+                Spielerkontakt haben und nach Abschluss der Tests ggf. sogar
+                die Testiemarkierung entfernt werden kann.
+
+                
+
+     Fuer Spielertesties, die von einem Spieler kontrolliert werden, gelten
+     teilweise besondere Regeln, s. 'spielertesties'.
+
+BEMERKUNGEN: 
+     P_TESTPLAYER kann nur per SetProp() gesetzt werden und das auch nur ein
+     Mal! Geloescht werden kann das Flag nur von EM+.
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+05.01.2010, Zesstra
+
diff --git a/doc/sphinx/props/P_TIMED_ATTR_MOD.rst b/doc/sphinx/props/P_TIMED_ATTR_MOD.rst
new file mode 100644
index 0000000..2afd305
--- /dev/null
+++ b/doc/sphinx/props/P_TIMED_ATTR_MOD.rst
@@ -0,0 +1,78 @@
+P_TIMED_ATTR_MOD
+================
+
+NAME
+----
+::
+
+    P_TIMED_ATTR_MOD         "timed_attr_mod"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Property werden Attribut-Modifikatoren gespeichert, die
+    nicht ueber laengere Zeit wirksam sein sollen.
+    Die Wirksamkeit der Modifikatoren kann an Zeit und Objekte
+    gebunden werden.
+
+    Intern werden die Modifikatoren in einer Datenstruktur der Form
+
+    ({
+       ({ Ablaufzeiten }),
+       ([ Key : Ablaufobjekt ]),
+       ([ Key : ([ Mapping mit den Modifikatoren ]);
+         Ablaufzeit ; Ablaufobjekt ; Nachrichtenempfaenger
+       ])
+    })
+
+    gespeichert mit:
+    * Ablaufzeiten:  Zeit in Sekunden seit 1. Jan 1970, 0.0:0 GMT
+    * Ablaufobjekte: Objekte, an deren Existenz die Attribut-
+                     veraenderungen gebunden sind
+    * Nachrichtenempfaenger:
+      Objekte/Klassen, welche ueber abgelaufene Attributveraenderung
+      durch den Aufruf von "NotifyTimedAttrModExpired" (mit key als
+      Argument) benachrichtigt werden.
+
+    Das Setzen der Werte erfolgt NUR ueber die Methoden SetTimedAttrModifier
+    und DeleteTimedAttrModifier.
+
+    Die Daten zu einem Key koennen ueber QueryTimedAttrModifier abgefragt
+    werden. Die Abfrage mittels QueryProp liefert eine Kopie der gueltigen
+    Datenstruktur, die per Query nicht (siehe Bemerkungen).
+
+    Die Bedingungen fuer die ueber P_TIMED_ATTR_MOD gesetzten
+    Attributveraenderungen werden im Heartbeat in der Funktion
+    attribute_hb ueberprueft. Eine verminderte Funktionalitaet im
+    Falle von Magiern ist somit kein Fehlerfall.
+
+BEMERKUNGEN
+-----------
+::
+
+    Keine echte Property. Die Methode _query_timed_attr_mod() in
+    /std/living/attributes.c stellt die Daten zusammen.
+
+    ACHTUNG: Bitte nur die bereitgestellten Methoden zur Manipulation
+             benutzen! Setzen als Property hat keinen Effekt.
+
+SIEHE AUCH
+----------
+::
+
+    QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+    SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+    SetTimedAttrModifier(), QueryTimedAttrModifier(),
+    DeleteTimedAttrModifier(),
+    P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
+    P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+Last modified: Tue Jul 27 20:00:20 2004 by Muadib
+
diff --git a/doc/sphinx/props/P_TIMEZONE.rst b/doc/sphinx/props/P_TIMEZONE.rst
new file mode 100644
index 0000000..561f887
--- /dev/null
+++ b/doc/sphinx/props/P_TIMEZONE.rst
@@ -0,0 +1,23 @@
+P_TIMEZONE
+==========
+
+NAME
+----
+::
+
+    P_TIMEZONE                 "timezone"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Ein Integer-Wert, der bei der Uhrzeitmeldung und beim Befehl
+     "(uhr)zeit" beruecksichtig wird. Gibt die Anzahl der Stunden
+     Zeitabweichung von Berliner Zeit an.
+
diff --git a/doc/sphinx/props/P_TITLE.rst b/doc/sphinx/props/P_TITLE.rst
new file mode 100644
index 0000000..336d5f0
--- /dev/null
+++ b/doc/sphinx/props/P_TITLE.rst
@@ -0,0 +1,21 @@
+P_TITLE
+=======
+
+NAME
+----
+::
+
+    P_TITLE                       "title"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/description.h
+
+BESCHREIBUNG
+------------
+::
+
+     Titel des Spielers. Erscheint hinter dem Namen in Kurz/Langbeschreibung.
+
diff --git a/doc/sphinx/props/P_TOO_HEAVY_MSG.rst b/doc/sphinx/props/P_TOO_HEAVY_MSG.rst
new file mode 100644
index 0000000..e42fd64
--- /dev/null
+++ b/doc/sphinx/props/P_TOO_HEAVY_MSG.rst
@@ -0,0 +1,50 @@
+P_TOO_HEAVY_MSG
+===============
+
+NAME
+----
+::
+
+    P_TOO_HEAVY_MSG                      "too_heavy_msg"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn jemand
+     versucht, ein Objekt in einen Behaelter zu legen, fuer den dieses Objekt
+     zu schwer ist.
+     Die Property ist im Behaelter zu setzen.
+     Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
+     so wird die Standardmeldung ausgegeben.
+     ("<Objekt> passt in <Behaelter> nicht mehr rein.")
+     Der String in der Property wird noch durch replace_personal()
+     verarbeitet, das zu bewegende Objekt wird als erstes, der Behaelter als
+     zweites Objekt angegeben. Danach wird der String auf 78 Zeichen
+     umgebrochen.
+     Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
+     ganz.
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_TOO_HEAVY_MSG, "Wenn du @WEN1 noch in den Beutel stecken"
+			      " wuerdest, wuerde er reissen.");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG, P_NOINSERT_MSG,
+                 P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     Erfolg:     P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
+                 P_WEAR_MSG, P_WIELD_MSG
+     Sonstiges:  replace_personal(E), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/props/P_TOO_MANY_MSG.rst b/doc/sphinx/props/P_TOO_MANY_MSG.rst
new file mode 100644
index 0000000..e224275
--- /dev/null
+++ b/doc/sphinx/props/P_TOO_MANY_MSG.rst
@@ -0,0 +1,50 @@
+P_TOO_MANY_MSG
+==============
+
+NAME
+----
+::
+
+    P_TOO_MANY_MSG                      "too_many_msg"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/moving.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn jemand
+     versucht, ein Objekt in einen Behaelter zu legen, der schon die maximale
+     Anzahl an Objekten enthaelt.
+     Die Property ist im Behaelter zu setzen.
+     Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
+     so wird die Standardmeldung ausgegeben.
+     ("Dafuer ist nicht mehr genug Platz in <Behaelter>.")
+     Der String in der Property wird noch durch replace_personal()
+     verarbeitet, das zu bewegende Objekt wird als erstes, der Behaelter als
+     zweites Objekt angegeben. Danach wird der String auf 78 Zeichen
+     umgebrochen.
+     Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
+     ganz.
+
+BEISPIELE
+---------
+::
+
+     SetProp(P_TOO_MANY_MSG, "Aber der Korb hat doch nur drei Faecher, die"
+			     " sind alle schon voll.");
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NOINSERT_MSG,
+                 P_NOLEAVE_MSG, P_NODROP, P_NOGET 
+     Erfolg:     P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
+                 P_WEAR_MSG, P_WIELD_MSG
+     Sonstiges:  replace_personal(E), /std/living/put_and_get.c
+
diff --git a/doc/sphinx/props/P_TOTAL_AC.rst b/doc/sphinx/props/P_TOTAL_AC.rst
new file mode 100644
index 0000000..2b585d4
--- /dev/null
+++ b/doc/sphinx/props/P_TOTAL_AC.rst
@@ -0,0 +1,42 @@
+P_TOTAL_AC
+==========
+
+NAME
+----
+::
+
+    P_TOTAL_AC                    "total_ac"                    
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+     Numerischer Wert der Abwehrstaerke des Wesens.
+     Dieser wird durch Aufaddieren der P_AC aller getragenen Ruestungen
+     bestimmt. Aus diesem Grund ist das Abfragen dieser Property ziemlich
+     teuer. Falls das Ergebnis mehrfach kurz hintereinander gebraucht wird,
+     sollte die Property auf jeden Fall nur einmal abgefragt und der Wert
+     gespeichert werden.
+
+BEMERKUNGEN
+-----------
+::
+
+    Auf diese Property sollte nicht mittels Query() oder Set() zugegriffen
+    werden, das Setzen von Query- oder Setmethoden bitte auf jeden Fall
+    unterlassen.
+
+SIEHE AUCH
+----------
+::
+
+    P_AC
+
+05.09.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_TOTAL_LIGHT.rst b/doc/sphinx/props/P_TOTAL_LIGHT.rst
new file mode 100644
index 0000000..a330cd2
--- /dev/null
+++ b/doc/sphinx/props/P_TOTAL_LIGHT.rst
@@ -0,0 +1,42 @@
+P_TOTAL_LIGHT
+=============
+
+NAME
+----
+::
+
+    P_TOTAL_LIGHT                 "total_light"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Gibt das Lichtlevel an, das von einem Objekt ausgeht. Hierzu wird das
+    eigene Lichtlevel P_LIGHT mit dem gesamten Inhalt eines Containers
+    verrechnet.
+
+    Bitte _nur_ ueber QueryProp auf diese Property zugreifen,
+    da das Lichtlevel ggf. neu berechnet werden muss!
+
+    Ein direktes setzen dieser Property ist NICHT moeglich, hierzu bitte
+    P_LIGHT benutzen!
+
+BEMERKUNGEN
+-----------
+::
+
+    Das ist die VON einem Objekt ausgehende Lichtstaerke. Fuer das IN einem
+    Raum herrschende Licht bitte P_INT_LIGHT abfragen!
+
+SIEHE AUCH
+----------
+::
+
+    P_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
+
diff --git a/doc/sphinx/props/P_TOTAL_OBJECTS.rst b/doc/sphinx/props/P_TOTAL_OBJECTS.rst
new file mode 100644
index 0000000..bf0d169
--- /dev/null
+++ b/doc/sphinx/props/P_TOTAL_OBJECTS.rst
@@ -0,0 +1,32 @@
+P_TOTAL_OBJECTS
+===============
+
+NAME
+----
+::
+
+    P_TOTAL_OBJECTS                "total_objects"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/container.h
+
+BESCHREIBUNG
+------------
+::
+
+     Anzahl der Objekte im Container. Diese Property kann man nur abfragen!
+     Es werden nur Objekte gezaehlt, deren Methode short() einen
+     Wert != 0 zurueckgibt. Insofern koennen Spielern beliebig
+     viele unsichtbare Objekte gegeben werden ohne sie zu behindern.
+
+SIEHE AUCH
+----------
+::
+
+     P_MAX_OBJECTS
+
+26.Jan 2005 Gloinson
+
diff --git a/doc/sphinx/props/P_TOTAL_WC.rst b/doc/sphinx/props/P_TOTAL_WC.rst
new file mode 100644
index 0000000..b5bb5d2
--- /dev/null
+++ b/doc/sphinx/props/P_TOTAL_WC.rst
@@ -0,0 +1,46 @@
+P_TOTAL_WC
+==========
+
+NAME
+----
+::
+
+	P_TOTAL_WC			"total_wc"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+	In dieser Property wird der numerische Wert der Angriffsstaerke
+	eines Lebewesens registriert.
+  Hierzu werden die P_WC von P_WEAPON bzw. P_HANDS sowie die Kraft des
+  Lebewesens beruecksichtigt.
+	Nicht eingerechnet in die Angriffsstaerke sind natuerlich Extraspells und
+  -skills des Angreifers.
+  Braucht man den Wert mehrfach kurz hintereinander, sollte man die Prop aber
+  nur einmal abfragen und den Wert speichern (sofern sich in der Zwischenzeit
+  nichts an der Waffe, den Hands oder den Attributen des Lebenwesens aendert).
+
+BEMERKUNGEN
+-----------
+::
+
+  Auf diese Property sollte nicht mittels Query() oder Set() zugegriffen 
+  werden, das Setzen von Query- oder Setmethoden bitte auf jeden Fall 
+  unterlassen.
+
+SIEHE AUCH
+----------
+::
+
+	P_HANDS, P_WC, P_XP
+
+
+05.09.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_TOTAL_WEIGHT.rst b/doc/sphinx/props/P_TOTAL_WEIGHT.rst
new file mode 100644
index 0000000..abc0202
--- /dev/null
+++ b/doc/sphinx/props/P_TOTAL_WEIGHT.rst
@@ -0,0 +1,21 @@
+P_TOTAL_WEIGHT
+==============
+
+NAME
+----
+::
+
+    P_TOTAL_WEIGHT                "total_weight"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/restrictions.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gewicht incl. Inhalt in Gramm. P_WEIGHT_PERCENT wird beruecksichtigt.
+
diff --git a/doc/sphinx/props/P_TOUCH_DETAILS.rst b/doc/sphinx/props/P_TOUCH_DETAILS.rst
new file mode 100644
index 0000000..d813a1a
--- /dev/null
+++ b/doc/sphinx/props/P_TOUCH_DETAILS.rst
@@ -0,0 +1,43 @@
+P_TOUCH_DETAILS
+===============
+
+NAME
+----
+::
+
+    P_TOUCH_DETAILS            "touch_details"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/description.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property entspricht dem P_DETAILS fuer Standarddetails,
+    nur werden hierin Gerueche gespeichert:
+    Diese Property enthaelt ein Mapping, in der Details im Objekt
+    definiert werden und Beschreibungen, die ausgegeben werden, wenn man
+    sich diese Details anschaut.
+
+BEMERKUNGEN
+-----------
+::
+
+    Man sollte diese Property nicht per Hand veraendern, sondern die
+    Funktionen nutzen.
+
+SIEHE AUCH
+----------
+::
+
+    Setzen:    AddTouchDetail()
+    Loeschen:  RemoveTouchDetail()
+    Aehnlich:  AddDetail(), P_DETAILS
+    Sonstiges: GetDetail(), break_string()
+
+27. Jan 2013 Gloinson
+
diff --git a/doc/sphinx/props/P_TPORT_COST_IN.rst b/doc/sphinx/props/P_TPORT_COST_IN.rst
new file mode 100644
index 0000000..c9f503d
--- /dev/null
+++ b/doc/sphinx/props/P_TPORT_COST_IN.rst
@@ -0,0 +1,22 @@
+P_TPORT_COST_IN
+===============
+
+NAME
+----
+::
+
+    P_TPORT_COST_IN               "tport_cost_in"               
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     In einem Raum mit Sehertor: Kostenanteil, um sich in den Raum zu
+     teleportieren
+
diff --git a/doc/sphinx/props/P_TPORT_COST_OUT.rst b/doc/sphinx/props/P_TPORT_COST_OUT.rst
new file mode 100644
index 0000000..fc65f12
--- /dev/null
+++ b/doc/sphinx/props/P_TPORT_COST_OUT.rst
@@ -0,0 +1,22 @@
+P_TPORT_COST_OUT
+================
+
+NAME
+----
+::
+
+    P_TPORT_COST_OUT              "tport_cost_out"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     In einem Raum mit Sehertor: Kostenanteil, sich aus dem Raum heraus
+     zu teleportieren
+
diff --git a/doc/sphinx/props/P_TRANK_FINDEN.rst b/doc/sphinx/props/P_TRANK_FINDEN.rst
new file mode 100644
index 0000000..dd856f0
--- /dev/null
+++ b/doc/sphinx/props/P_TRANK_FINDEN.rst
@@ -0,0 +1,22 @@
+P_TRANK_FINDEN
+==============
+
+NAME
+----
+::
+
+    P_TRANK_FINDEN                "trank_finden"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/potion.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wenn die Property auf 1 steht kann immer ein Zaubertrank gefunden
+     werden, auch wenn er nicht in der Liste des Spielers steht.
+
diff --git a/doc/sphinx/props/P_TRANSPARENT.rst b/doc/sphinx/props/P_TRANSPARENT.rst
new file mode 100644
index 0000000..dbe640d
--- /dev/null
+++ b/doc/sphinx/props/P_TRANSPARENT.rst
@@ -0,0 +1,47 @@
+P_TRANSPARENT
+=============
+
+NAME
+----
+::
+
+     P_TRANSPARENT                 "transparent"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/container.h
+
+BESCHREIBUNG
+------------
+::
+
+     ist != 0, wenn in einen Container hinein (offen) oder aus einem 
+     hinausgeschaut werden kann.
+
+     Schaut man aus einem hinaus, erhaelt der Spieler normalerweise die 
+     Meldung 'Ausserhalb siehst Du:'. Diese kann jedoch durch eine eigene, 
+     stimmigere  Meldung ersetzt werden, wenn in P_TRANSPARENT ein String 
+     mit dieser Meldung angegeben wird.
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_TRANSPARENT,1); -> normale Meldung
+
+     SetProp(P_TRANSPARENT,"Vom Ruecken des Pferdes aus siehst Du:\n");
+
+     Diese Meldung ist natuerlich nur dann sinnvoll, wenn es sich
+     auch tatsaechlich um ein Pferd handelt :-)
+
+SIEHE AUCH
+----------
+::
+
+     int_long()
+
+
+Last modified: Mon Jul 18 24:00:00 2001 by Tilly
+
diff --git a/doc/sphinx/props/P_TRAVEL_CMDS.rst b/doc/sphinx/props/P_TRAVEL_CMDS.rst
new file mode 100644
index 0000000..82b93fc
--- /dev/null
+++ b/doc/sphinx/props/P_TRAVEL_CMDS.rst
@@ -0,0 +1,64 @@
+P_TRAVEL_CMDS
+=============
+
+NAME
+----
+::
+
+    P_TRAVEL_CMDS                   "travel_cmds"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+    Ein Array mit Befehlen, die zum Verlassen UND Betreten des Trans-
+    porters fuehren. 
+
+BEISPIEL
+--------
+::
+
+    void create()
+    {
+      ::create();
+
+      SetProp(P_TRAVEL_CMDS,({ "steig","steige" }) );
+
+    }
+
+    Als Parameter werden hier ausschliesslich 'auf,in' und 'von,aus'
+    verarbeitet.
+
+    steige auf|in  <xxx>    fuehrt also zum Betreten des Transporters,
+    steige von|aus <xxx>    dagegen fuehrt zum Verlassen desselben.
+
+BEMERKUNGEN
+-----------
+::
+
+    Um /std/transport.c nicht aufzublaehen, werden weitere Parameter wie
+    etwa 'steige auf|in das|die|den xxx' _nicht_ unterstuetzt!
+
+    Hier muss der verantwortliche Magier schon eine eigene Loesung finden
+    und in seinen Transporter schreiben.
+
+SIEHE AUCH
+----------
+::
+
+    P_LEAVEFAIL, P_ENTERFAIL, P_ENTERCMDS, P_LEAVECMDS, transporter,
+
+LETZTER AENDERUNG
+-----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
+    
+
diff --git a/doc/sphinx/props/P_TRAVEL_INFO.rst b/doc/sphinx/props/P_TRAVEL_INFO.rst
new file mode 100644
index 0000000..f6dd566
--- /dev/null
+++ b/doc/sphinx/props/P_TRAVEL_INFO.rst
@@ -0,0 +1,53 @@
+P_TRAVEL_INFO
+=============
+
+NAME
+----
+::
+
+    P_TRAVEL_INFO                 "travel_info"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/transport.h
+
+BESCHREIBUNG
+------------
+::
+
+    Array mit Informationen zur vom Spieler gewuenschten Reiseroute.
+
+    [0]        Der Raum (object), in dem die Reiseroute momentan 
+               'aktiv' ist. Nur hier wird sie beruecksichtigt.
+
+    [1]        Das gewuenschte Transportmittel (object) falls 
+               gewaehlt. Ansonsten 0.
+
+    [2]        Der gewuenschte Zielort (string) oder 0 (ziellos).
+
+    [3]        Der gewuenschte Zielort als Richtung (string), falls
+               gewaehlt (z.B. 'zur Feuerinsel'). Sonst 0. Wird aus
+               P_HARBOUR des Zielraumes ausgelesen.
+
+BEMERKUNGEN
+-----------
+::
+
+    Diese Property wird von /std/transport.c sowie std/player/travel.c
+    verwendet, und sollte NICHT von anderen Objekten oder per Hand 
+    veraendert werden!
+
+SIEHE AUCH
+----------
+::
+
+    /std/transport.c, /std/player/travel.c, reise
+
+LETZTER AENDERUNG
+-----------------
+::
+
+    Don, 24.01.2002, 10:15:07h von Tilly
+
diff --git a/doc/sphinx/props/P_TRAY.rst b/doc/sphinx/props/P_TRAY.rst
new file mode 100644
index 0000000..1fb912a
--- /dev/null
+++ b/doc/sphinx/props/P_TRAY.rst
@@ -0,0 +1,21 @@
+P_TRAY
+======
+
+NAME
+----
+::
+
+    P_TRAY                        "tray"                        
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    *** KEINE BESCHREIBUNG VORHANDEN ***
+
diff --git a/doc/sphinx/props/P_TTY.rst b/doc/sphinx/props/P_TTY.rst
new file mode 100644
index 0000000..08199f2
--- /dev/null
+++ b/doc/sphinx/props/P_TTY.rst
@@ -0,0 +1,47 @@
+P_TTY
+=====
+
+NAME
+----
+::
+
+    P_TTY                         "tty"
+
+DEFINIERT IN
+------------
+::
+
+    /secure/telnetneg.h
+
+BESCHREIBUNG
+------------
+::
+
+     Name der Terminalemulation, die der Spieler nutzt.
+     Es existieren bisher "dumb", "vt100" und "ansi".
+
+	
+
+ANMERKUNG
+---------
+::
+
+     Farben duerfen ausschliesslich bei P_TTY=="ansi" benutzt werden.
+     Bei nicht farbfaehigen Terminals koennen ANSI-Codes die gesamte
+     Ausgabe zerschiessen!
+
+     Die Attribute fett, unterstrichen, blinkend und invers koennen auch
+     schon von vt100-Terminals dargestellt werden. Aber nicht ueberall
+     sind alle Attribute/Farben implementiert.
+
+     Bei allen ANSI-Codes sind drei Sachen zu beachten:
+
+     
+
+        1) Sparsam benutzen! Aufgezwungene Hervorhebungen koennen
+	   Spieler ganz schnell nerven.
+
+	2) Nicht jeder benutzt dieselbe Hintergrundfarbe!
+
+	3) Sparsam benutzen! Beser noch: nur im Notfall!
+
diff --git a/doc/sphinx/props/P_TTY_COLS.rst b/doc/sphinx/props/P_TTY_COLS.rst
new file mode 100644
index 0000000..e76ac71
--- /dev/null
+++ b/doc/sphinx/props/P_TTY_COLS.rst
@@ -0,0 +1,40 @@
+P_TTY_COLS
+==========
+
+NAME
+----
+::
+
+    P_TTY_COLS                                  "tty_cols"
+
+DEFINIERT IN
+------------
+::
+
+    /secure/telnetneg.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Properties steht die Anzahl der Spalten, die das 
+    Terminalfenster des Spielers derzeit hat.
+
+    Voraussetzung hierfuer ist allerdings, dass das Telnet des Spielers
+    Telnetnegotiations unterstuetzt, ansonsten bleibt diese Property
+    leer.
+    Das Setzen der Property aendert die Fenstergroesse des Spielers
+    natuerlich nicht.
+
+SIEHE AUCH
+----------
+::
+
+    P_TTY_ROWS, P_TTY_TYPE, P_TTY_SHOW
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    Sat, 06.02.1999, 14:00:00 von Paracelsus
+
diff --git a/doc/sphinx/props/P_TTY_ROWS.rst b/doc/sphinx/props/P_TTY_ROWS.rst
new file mode 100644
index 0000000..02759fd
--- /dev/null
+++ b/doc/sphinx/props/P_TTY_ROWS.rst
@@ -0,0 +1,40 @@
+P_TTY_ROWS
+==========
+
+NAME
+----
+::
+
+    P_TTY_ROWS                                  "tty_rows"
+
+DEFINIERT IN
+------------
+::
+
+    /secure/telnetneg.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Properties steht die Anzahl der Zeilen, die das
+    Terminalfenster des Spielers derzeit hat.
+
+    Voraussetzung hierfuer ist allerdings, dass das Telnet des Spielers
+    Telnetnegotiations unterstuetzt, ansonsten bleibt diese Property
+    leer.
+    Das Setzen der Property aendert die Fenstergroesse des Spielers
+    natuerlich nicht.
+
+SIEHE AUCH
+----------
+::
+
+    P_TTY_COLS, P_TTY_TYPE, P_TTY_SHOW
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    Sat, 06.02.1999, 14:00:00 von Paracelsus
+
diff --git a/doc/sphinx/props/P_TTY_SHOW.rst b/doc/sphinx/props/P_TTY_SHOW.rst
new file mode 100644
index 0000000..f9d31af
--- /dev/null
+++ b/doc/sphinx/props/P_TTY_SHOW.rst
@@ -0,0 +1,35 @@
+P_TTY_SHOW
+==========
+
+NAME
+----
+::
+
+    P_TTY_SHOW                                  "tty_show"
+
+DEFINIERT IN
+------------
+::
+
+    /secure/telnetneg.h
+
+BESCHREIBUNG
+------------
+::
+
+    Bei Telnets, die Telnetnegotiations unterstuetzen, wird eine Aenderung
+    der Fenstergroesse dem Spielerobjekt mitgeteilt. Steht in P_TTY_SHOW
+    ein Wert ungleich Null, wird dem Spieler diese Aenderung mitgeteilt.
+
+SIEHE AUCH
+----------
+::
+
+    P_TTY_ROWS, P_TTY_COLS, P_TTY_TYPE, telnegs
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    Sat, 06.02.1999, 14:00:00 von Paracelsus
+
diff --git a/doc/sphinx/props/P_TTY_TYPE.rst b/doc/sphinx/props/P_TTY_TYPE.rst
new file mode 100644
index 0000000..a33f937
--- /dev/null
+++ b/doc/sphinx/props/P_TTY_TYPE.rst
@@ -0,0 +1,41 @@
+P_TTY_TYPE
+==========
+
+NAME
+----
+::
+
+    P_TTY_TYPE                                  "tty_type"
+
+DEFINIERT IN
+------------
+::
+
+    /secure/telnetneg.h
+
+BESCHREIBUNG
+------------
+::
+
+    In dieser Properties steht der Terminaltyp, den ein Spieler lokal auf
+    seinem Rechner verwendet.
+
+    Voraussetzung hierfuer ist allerdings, dass das Telnet des Spielers
+    Telnetnegotiations unterstuetzt, ansonsten bleibt diese Property
+    leer. Die meisten Telnets/Clients geben ihren Terminaltyp allerdings
+    nicht preis.
+    Das Setzen der Property aendert den Terminaltyp des Spielers
+    natuerlich nicht.
+
+SIEHE AUCH
+----------
+::
+
+    P_TTY_COLS, P_TTY_ROWS, P_TTY_SHOW
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    Sat, 06.02.1999, 14:00:00 von Paracelsus
+
diff --git a/doc/sphinx/props/P_UNIT_DECAY_FLAGS.rst b/doc/sphinx/props/P_UNIT_DECAY_FLAGS.rst
new file mode 100644
index 0000000..10fe447
--- /dev/null
+++ b/doc/sphinx/props/P_UNIT_DECAY_FLAGS.rst
@@ -0,0 +1,92 @@
+P_UNIT_DECAY_FLAGS
+==================
+
+NAME
+----
+::
+
+     P_UNIT_DECAY_FLAGS					"unit_decay_flags"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/unit.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Prop kann das Zerfallsverhalten gesteuert werden, entweder
+     fuer alle Clones durch Setzen in der Blueprint oder fuer einzelne Clones.
+
+     In dieser Prop koennen momentan 4 Flags gesetzt werden:
+     - NO_DECAY: 
+          Zerfall ist abgeschaltet.
+     - NO_DECAY_UNTIL_MOVE: 
+          Der Zerfall ist solange ausgesetzt, bis dieses Objekt in ein anderes
+          Env bewegt wird. Setzt also ein NPC beim AddItem() diese Prop,
+          zerfaellt seine Unit nicht, bis sie bewegt wurde (Leiche, Spieler
+          etc.). Hierbei zaehlt das move() nicht, wenn das Objekt noch kein
+          Env hatte, es zaehlen nur Moves von einem Env in ein anderes Env.
+          Dieses Flag sollte nur in Clones gesetzt werden.
+     - INACCURATE_DECAY
+          Sollen z.b. 45.34 Einheiten zerfallen, wird der Rest von 0.34
+          normalerweise als Wahrscheinlichkeit aufgefasst, dass eine
+          zusaetzliche Einheit zerfaellt. Dieses Flag sorgt dafuer, dass
+          dieser Rest weggeworfen wird und einfach 45 Einheiten zerfallen.
+          Gleichzeitig wird bei diesem Flag aber _immer min_ 1 Einheit
+          zerstoert!
+     - ABSOLUTE_DECAY
+          P_UNIT_DECAY_QUOTA wird nicht als prozentualer Anteil aufgefasst,
+          sondern als absolute Zahl, d.h. es zerfallen immer einfach
+          P_UNIT_DECAY_QUOTA Einheiten.
+
+     Diese Flags koennen z.B. genutzt werden, den Zerfall fuer einzelne
+     Objekte temporaer oder dauerhaft abzuschalten, auch wenn alle anderen
+     Clones weiterzerfallen.
+
+     Diese Prop kann in der Blueprint gesetzt werden. In diesem Fall wird
+     allerdings NO_DECAY_UNTIL_MOVE ignoriert, weil die BP ja nie bewegt
+     wuerde. NO_DECAY in der BP schaltet den Zerfallsprozess (temporaer) fuer
+     alle Clones aus. Ist nie ein Zerfall gewuenscht, sollte in der Blueprint
+     aber besser P_UNIT_DECAY_INTERVAL auf 0 gesetzt werden!
+
+     Ist die Prop in einem einzelnen Clone nicht explizit gesetzt,
+     liefert ein klon->QueryProp(P_UNIT_DECAY_FLAGS) den in der Blueprint
+     eingestellten Wert zurueck.
+
+     
+
+BEMERKUNGEN
+-----------
+::
+
+     * Setzt man diese Prop in einem Clone auf 0, wird der Wert aus der
+       Blueprint zurueckgeben. Hierbei wird allerdings ein NO_DECAY_UNTIL_MOVE
+       ausgefiltert, da dies den Zerfall fuer alle Objekte dauerhaft stoppen
+       wuerde, weil BPs nicht bewegt werden.
+     * Die Flags koennen "verodert" werden:
+       SetProp(P_UNIT_DECAY_FLAGS, NO_DECAY_UNTIL_MOVE | ABSOLUTE_DECAY);
+
+BEISPIEL
+--------
+::
+
+     // Dieser NPC hat tolle Pfeile, die sollen aber nicht zerfallen, solange
+     // sie im Inventar des NPCs sind:
+     AddItem("/d/tolleregion/tollermagier/obj/pfeile", REFRESH_NONE,
+         ([ P_AMOUNT: 50+random(50),
+            P_UNIT_DECAY_FLAGS: NO_DECAY_UNTIL_MOVE ]) );
+
+SIEHE AUCH
+----------
+::
+
+     unit
+     P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_QUOTA, P_UNIT_DECAY_MIN
+     DoDecay, DoDecayMessage
+     /std/unit.c
+
+14.10.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_UNIT_DECAY_INTERVAL.rst b/doc/sphinx/props/P_UNIT_DECAY_INTERVAL.rst
new file mode 100644
index 0000000..c9b6d2a
--- /dev/null
+++ b/doc/sphinx/props/P_UNIT_DECAY_INTERVAL.rst
@@ -0,0 +1,56 @@
+P_UNIT_DECAY_INTERVAL
+=====================
+
+NAME
+----
+::
+
+     P_UNIT_DECAY_INTERVAL					"unit_decay_interval"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/unit.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Prop bestimmt, wie oft ein Zerfall der entsprechenden Unitobjekte
+     durchgefuehrt wird. Das Intervall ist in Sekunden anzugeben (int).
+     Die Prop muss in der Blueprint der entsprechenden Unitobjekte gesetzt
+     werden, in Clones kann sie nicht gesetzt werden.
+     Die Blueprint resettet dann in diesem Intervall und ruft in allen ihren
+     Clones (und denen alter Versionen der gleichen BP!) DoDecay() auf,
+     woraufhin die Clones den Zerfall durchfuehren.
+     Ist die Prop in der Blueprint nicht gesetzt, erfolgt kein Zerfall.
+
+BEMERKUNGEN
+-----------
+::
+
+     * Ist die Blueprint nicht geladen, erfolgt kein Zerfall der Clones.
+     * Ein Setzen dieser Prop beinhaltet immer auch einen Aufruf von
+       set_next_reset() auf das ensprechende Intervall.
+     * Die Prop kann in den Clones abgefragt werden und liefert das in der
+       Blueprint eingestellte Intervall.
+     * Von einer Manipulation per Set() wird dringend abgeraten.
+     * Die Prop kann nur vom Objekt selber, vom Programmierer des Objekts, vom
+       RM der entsprechenden Region, von einem Weisen oder von einem Objekt
+       gesetzt werden, welches die gleiche UID hat.
+
+BEISPIEL
+--------
+::
+
+SIEHE AUCH
+----------
+::
+
+     unit
+     P_UNIT_DECAY_QUOTA, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_MIN
+     DoDecay(), DoDecayMessage()
+
+13.10.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_UNIT_DECAY_MIN.rst b/doc/sphinx/props/P_UNIT_DECAY_MIN.rst
new file mode 100644
index 0000000..8c97b4e
--- /dev/null
+++ b/doc/sphinx/props/P_UNIT_DECAY_MIN.rst
@@ -0,0 +1,71 @@
+P_UNIT_DECAY_MIN
+================
+
+NAME
+----
+::
+
+     P_UNIT_DECAY_MIN					                    "unit_decay_min"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/unit.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Prop bestimmt, wieviele Einheiten der Unitobjekten mindestens
+     uebrig bleiben sollen. 
+     Faellt die Menge eines Unitobjekts unter diesen Wert, zerfaellt diese
+     Unit solange nicht weiter, bis der Wert wieder ueberschritten wird.
+     Die Prop kann in der Blueprint und in den einzelnen Clones gesetzt
+     werden.
+     Ist die Prop in einem einzelnen Clone nicht explizit gesetzt,
+     liefert ein QueryProp(P_UNIT_DECAY_MIN) den in der Blueprint
+     eingestellten Wert zurueck und die Unit zerfaellt bis zu dieser
+     Mindestmenge..
+     D.h. man sollte diese Prop in der Blueprint setzen und in einzelnen
+     Clones nur soweit diese abweichende Werte haben sollen.
+     Es sind nur Werte zwischen 0 und 100 zulaessig. Auf diese Art laesst sich
+     die minidestens uebrig bleibende Menge aller Clones durch Aendern einer
+     Prop in der Blueprint aendern.
+
+BEMERKUNGEN
+-----------
+::
+
+     * Setzt man diese Prop in einem Clone auf 0, wird der Wert aus er
+       Blueprint zum Zerfall benutzt.
+     * Will man fuer ein bestimmtes Unitobjekt kein Minimum haben, also dass
+       dieses Objekt zerfaellt, bis nichts mehr da ist, die Blueprint hat aber
+       einen Minimalwert gesetzt, sollte diese Prop im betreffenden Objekt auf
+       -1 gesetzt werden.
+     * Diese Prop sollte vorsichtig angewandt werden, da Spieler so den
+       Zerfall von Units stoppen koennen, indem sie die Units entsprechend
+       aufteilen, so dass jedes Einzelobjekt unter dem Minimum liegt.
+
+BEISPIEL
+--------
+::
+
+     // es soll min. 1 Einheit uebrig bleiben.
+     SetProp(P_UNIT_DECAY_MIN, 1);
+
+     // die Blueprint hat ein Minimum von 10 gesetzt, dieser Clone soll
+     // aber zerfallen, bis nix mehr da ist.
+     klon->SetProp(P_UNIT_DECAY_MIN, -1);
+
+SIEHE AUCH
+----------
+::
+
+     unit
+     P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_QUOTA
+     DoDecay, DoDecayMessage
+     /std/unit.c
+
+14.10.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_UNIT_DECAY_QUOTA.rst b/doc/sphinx/props/P_UNIT_DECAY_QUOTA.rst
new file mode 100644
index 0000000..e219c5f
--- /dev/null
+++ b/doc/sphinx/props/P_UNIT_DECAY_QUOTA.rst
@@ -0,0 +1,69 @@
+P_UNIT_DECAY_QUOTA
+==================
+
+P_UNIT_DECAY_QUOTA (int)
+------------------------
+::
+
+NAME
+----
+::
+
+     P_UNIT_DECAY_QUOTA					"unit_decay_quota"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/unit.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Prop bestimmt, welcher Anteil der einzelnen Unitobjekte pro Zerfall
+     zerstoert wird. Dieser Anteil wird als ganze Zahl zwischen 0 und 10000
+     ausgedrueckt. 1 entspricht einem Zerfall von 0.01%, 10000 entspricht
+     100%.
+     Momentan sind keine Werte < 0 zulaessig, die einem Zuwachs entsprechend
+     wurden.
+
+     Falls das Flag ABSOLUTE_DECAY (s. P_UNIT_DECAY_FLAGS) gesetzt ist, steht
+     die Zahl in dieser Prop fuer die absolute Anzahl an zu zerstoerenden
+     Einheiten.
+
+     Die Prop kann in der Blueprint und in den einzelnen Clones gesetzt
+     werden.
+     Ist die Prop in einem einzelnen Clone nicht explizit gesetzt,
+     liefert ein QueryProp(P_UNIT_DECAY_QUOTA) den in der Blueprint
+     eingestellten Wert zurueck und die Unit zerfaellt zu diesem Anteil.
+     D.h. man sollte diese Prop in der Blueprint setzen und in einzelnen
+     Clones nur soweit diese abweichende Zerfallsraten haben sollen.
+
+BEMERKUNGEN
+-----------
+::
+
+     * Setzt man diese Prop in einem Clone auf 0, wird der Wert aus er
+       Blueprint zum Zerfall benutzt.
+     * Will man den Zerfall fuer ein bestimmtes Unitobjekt abschalten, sollte
+       man P_UNIT_DECAY_FLAGS benutzen.
+
+BEISPIEL
+--------
+::
+
+     // pro Zerfallsintervall sollen 12% zerfallen.
+     SetProp(P_UNIT_DECAY_QUOTA, 1200);
+
+SIEHE AUCH
+----------
+::
+
+     unit
+     P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_MIN
+     DoDecay, DoDecayMessage
+     /std/unit.c
+
+14.03.2008, Zesstra
+
diff --git a/doc/sphinx/props/P_UNWEAR_MSG.rst b/doc/sphinx/props/P_UNWEAR_MSG.rst
new file mode 100644
index 0000000..65b3c43
--- /dev/null
+++ b/doc/sphinx/props/P_UNWEAR_MSG.rst
@@ -0,0 +1,78 @@
+P_UNWEAR_MSG
+============
+
+NAME
+----
+::
+
+     P_UNWEAR_MSG                       "unwear_msg"     
+
+DEFINIERT IN
+------------
+::
+
+     /sys/armour.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zweiteiliges Array mit Meldungen, die beim Ausziehen einer Ruestung 
+     oder Kleidung an den Spieler und die Umgebung ausgegeben werden.
+     Der erste Eintrag geht an den Spieler, der zweite Eintrag an die
+     Umgebung. Zeilenumbrueche werden automatisch gemacht, existierende
+     jedoch beruecksichtigt.
+
+     Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
+     man replace_personal()).
+
+     [Wegen Abwaertskompatibilitaet ist auch noch der Platzhalter %s
+      moeglich, wobei in der eigenen Meldung %s fuer den Waffennamen steht,
+      in der an den Raum das erste %s fuer den Spielernamen, das zweite fuer
+      den Waffennamen.]
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_NAME, "Mantel");
+    SetProp(P_UNWEAR_MSG,
+     ({"Du reisst Dir @WEN2 vom Leib.",
+       "@WER1 reisst sich @WENU2 vom Leib." }));
+
+    -> beim Ausziehen durch Urk:
+       Urk bekommt: Du reisst dir den Mantel vom Leib.
+       Der Raum:    Urk reisst sich einen Mantel vom Leib.
+
+    SetProp(P_UNWEAR_MSG,
+     ({"Dir wird furchtbar warm. So eine Hitze aber auch. Schnell "
+       "schluepfst Du aus Deiner dicken Ruestung. Aaaah, was fuer "
+       "eine Wohltat.",
+       "@WEM1 scheint ploetzlich warm zu werden. Schnell schluepft "
+       "@WERQP1 aus @WEMQPPFS1 dicken Ruestung. Du hoffst instaendig, "
+       "das es noch etwas waermer wird ... "}));
+
+    -> beim Ausziehen durch Urk:
+       Urk bekommt: Dir wird furchtbar warm. So eine Hitze aber auch.
+		    Schnell schluepfst Du aus Deiner dicken Ruestung.
+		    Aaaah, was fuer eine Wohltat.
+       Der Raum:    Urk scheint ploetzlich warm zu werden. Schnell
+		    schluepft er aus seiner dicken Ruestung. Du hoffst
+		    instaendig, das es noch etwas waermer wird ...
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_WEAR_MSG, P_WIELD_MSG, P_UNWIELD_MSG
+                 P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_PICK_MSG
+     Funktionen: WearFunc, UnwearFunc
+     Sonstiges:  replace_personal(E), /std/armour/wear.c, armours
+                 clothing, /std/clothing.wear.c
+
+LETZTE AeNDERUNG
+----------------
+::
+
+15.02.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_UNWIELD_FUNC.rst b/doc/sphinx/props/P_UNWIELD_FUNC.rst
new file mode 100644
index 0000000..f1666fd
--- /dev/null
+++ b/doc/sphinx/props/P_UNWIELD_FUNC.rst
@@ -0,0 +1,33 @@
+P_UNWIELD_FUNC
+==============
+
+NAME
+----
+::
+
+     P_UNWIELD_FUNC "unwield_func"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Falls ein Objekt eine UnwieldFunc() fuer die Waffe definiert, so muss
+     dieses Objekt in dieser Property eingetragen werden.
+
+     Die Auswertung dieser Property erfolgt in DoUnwield().
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon.c, UnwieldFunc()
+
+
+Last modified: Sun May 19 15:44:08 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_UNWIELD_MSG.rst b/doc/sphinx/props/P_UNWIELD_MSG.rst
new file mode 100644
index 0000000..665de9b
--- /dev/null
+++ b/doc/sphinx/props/P_UNWIELD_MSG.rst
@@ -0,0 +1,77 @@
+P_UNWIELD_MSG
+=============
+
+NAME
+----
+::
+
+     P_UNWIELD_MSG                       "unwield_msg"                       
+
+DEFINIERT IN
+------------
+::
+
+     /sys/weapon.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zweiteiliges Array mit Meldungen, die beim Wegstecken einer 
+     Waffe an den Spieler und die Umgebung ausgegeben werden.
+
+     Der erste Eintrag geht an den Spieler, der zweite Eintrag an die
+     Umgebung.  Zeilenumbrueche werden automatisch gemacht, existierende
+     jedoch beruecksichtigt.
+
+     Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
+     man replace_personal()).
+
+     [Wegen Abwaertskompatibilitaet ist auch noch der Platzhalter %s
+      moeglich, wobei in der eigenen Meldung %s fuer den Waffennamen steht,
+      in der an den Raum das erste %s fuer den Spielernamen, das zweite fuer
+      den Waffennamen.]
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_NAME, "Streitkolben");
+    SetProp(P_UNWIELD_MSG,
+     ({ "Du steckst @WEN2 zurueck und atmest erstmal tief durch.", 
+        "@WER1 steckt @WENU2 zurueck und atmet erstmal tief durch." }));
+
+    -> beim Wegstecken durch Urk:
+       Urk bekommt: Du steckst den Streitkolben zurueck und atmest erstmal
+		    tief durch.
+       Der Raum:    Urk steckt einen Streitkolben zurueck und atmet erstmal
+		    tief durch.
+
+    SetProp(P_UNWIELD_MSG,
+     ({"Du steckst die schwere Keule zurueck. Zufaellig landet sie "
+       "dabei auf Deinem Fuss. Laut schreiend humpelst Du in der "
+       "Gegend herum.",
+       "@WER1 steckt eine schwere Keule zurueck. Dummerweise landet diese "
+       "direkt auf dem eigenen Fuss. Aua, das tat sicher weh ... nicht "
+       "umsonst humpelt @WERQP1 jetzt schreiend durch die Gegend."}));
+
+    -> beim Wegstecken durch Urk:
+       Urk bekommt: Du steckst die schwere Keule zurueck. Zufaellig landet
+		    sie dabei auf Deinem Fuss. Laut schreiend humpelst Du in
+		    der Gegend herum.
+       Der Raum:    Urk steckt eine schwere Keule zurueck. Dummerweise
+		    landet diese direkt auf dem eigenen Fuss. Aua, das tat
+                    sicher weh ... nicht umsonst humpelt er jetzt schreiend
+                    durch die Gegend.
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_WIELD_MSG, P_WEAR_MSG, P_UNWEAR_MSG
+                 P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_PICK_MSG
+     Funktionen: UnwieldFunc, WieldFunc
+     Sonstiges:  replace_personal(E), /std/weapon/combat.c
+
+29. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_UNWIELD_TIME.rst b/doc/sphinx/props/P_UNWIELD_TIME.rst
new file mode 100644
index 0000000..b4958e8
--- /dev/null
+++ b/doc/sphinx/props/P_UNWIELD_TIME.rst
@@ -0,0 +1,33 @@
+P_UNWIELD_TIME
+==============
+
+NAME
+----
+::
+
+      P_UNWIELD_TIME			"unwield_time"
+
+DEFINIERT IN
+------------
+::
+
+      /sys/weapon.h
+
+BESCHREIBUNG
+------------
+::
+
+      Enthaelt den Zeitpunkt zu dem ein Living eine Waffe weggesteckt hat und
+      ist im Living gesetzt.
+
+SIEHE AUCH
+----------
+::
+
+      Verwandt:		P_WEAPON, P_WIELDED, DoUnwield()
+			P_LAST_USE
+      Sonstiges:	P_EQUIP_TIME
+			time()
+
+10.Feb 2005 Gloinson
+
diff --git a/doc/sphinx/props/P_USED_HANDS.rst b/doc/sphinx/props/P_USED_HANDS.rst
new file mode 100644
index 0000000..32542fb
--- /dev/null
+++ b/doc/sphinx/props/P_USED_HANDS.rst
@@ -0,0 +1,39 @@
+P_USED_HANDS
+============
+
+NAME
+----
+::
+
+    P_USED_HANDS                  "used_hands"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    Anzahl der Haende in Benutzung.
+    Effektiv nur ein sizeof(P_HANDS_USED_BY).
+
+BEMERKUNGEN
+-----------
+::
+
+    Keine echte Property. Die Methode /std/living/combat::_query_used_hands
+    stellt die Daten zusammen. Nicht setzen!
+
+SIEHE AUCH
+----------
+::
+
+    P_HANDS, P_HANDS_USED_BY
+    P_MAX_HANDS, P_FREE_HANDS
+    UseHands, FreeHands
+
+1. Okt 2012, Gloinson
+
diff --git a/doc/sphinx/props/P_VALID_GUILDS.rst b/doc/sphinx/props/P_VALID_GUILDS.rst
new file mode 100644
index 0000000..6343081
--- /dev/null
+++ b/doc/sphinx/props/P_VALID_GUILDS.rst
@@ -0,0 +1,42 @@
+P_VALID_GUILDS
+==============
+
+NAME
+----
+::
+
+	P_VALID_GUILDS			"valid_guilds"                
+
+DEFINIERT IN
+------------
+::
+
+	/sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt die zugelassenen Gilden in Form von
+	kleingeschriebenen Gildennamen, welche in einem Array
+	zusammengefasst sind. Sie ist nur fuer den Gildenmaster selbst von
+	Bedeutung.
+
+BEISPIELE
+---------
+::
+
+	Abfrage der zugelassenen Gilden:
+	  find_object("/obj/gildenmaster")->QueryProp(P_VALID_GUILDS)
+	Das ergibt zum Beispiel:
+          ({"abenteurer","zauberer","klerus","kaempfer"})
+
+SIEHE AUCH
+----------
+::
+
+	P_GUILD, /obj/gildenmaster.c
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_VALUE.rst b/doc/sphinx/props/P_VALUE.rst
new file mode 100644
index 0000000..5843615
--- /dev/null
+++ b/doc/sphinx/props/P_VALUE.rst
@@ -0,0 +1,48 @@
+P_VALUE
+=======
+
+NAME
+----
+::
+
+    P_VALUE                       "value"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     - Objekte
+       Wert des Objektes in Goldmuenzen. Diesen Wert erhaelt man beim
+       Verkauf. Kaufen kostet ein Vielfaches hiervon.
+
+     - Speisen/Kneipen
+       Wert einer Portion der Speise.
+
+       
+
+BEMERKUNGEN
+-----------
+::
+
+     In tragbaren Speisen (erben von /std/food) setzt man mit SetProp
+     den Wert _einer_ Portion. Per QueryProp erhaelt man aber den Gesamt-
+     wert der Speise inclusive des eventuell vorhandenen Behaelters. Der
+     Wert des Behaelters wird dabei aus P_EMPTY_PROPS[P_VALUE] gelesen.
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     Speisen: std/pub, wiz/food, P_EMPTY_PROPS
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_VALUE_PER_UNIT.rst b/doc/sphinx/props/P_VALUE_PER_UNIT.rst
new file mode 100644
index 0000000..125108e
--- /dev/null
+++ b/doc/sphinx/props/P_VALUE_PER_UNIT.rst
@@ -0,0 +1,29 @@
+P_VALUE_PER_UNIT
+================
+
+NAME
+----
+::
+
+    P_VALUE_PER_UNIT              "value_per_unit"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Wert in Goldstuecken pro Untereinheit.
+
+BEMERKUNGEN
+-----------
+::
+
+     Deprecated. Bitte SetCoinsPerUnits() (U_CPU) benutzen.
+
+25.Aug 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_VARIABLES.rst b/doc/sphinx/props/P_VARIABLES.rst
new file mode 100644
index 0000000..97147d4
--- /dev/null
+++ b/doc/sphinx/props/P_VARIABLES.rst
@@ -0,0 +1,31 @@
+P_VARIABLES
+===========
+
+NAME
+----
+::
+
+    P_VARIABLES "variables"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/magier.h
+
+BESCHREIBUNG
+------------
+::
+
+	
+
+     Interne Variable der Magiershell in dem die mit dem 'Set'-Befehl
+     gesetzten Variablen gespeichert werden.
+
+     
+
+     NICHT VON HAND VERAENDERN! IMMER 'SET' VERWENDEN!
+
+
+Letzte Aenderung: 13.02.2003 22:00:00 von Mandragon
+
diff --git a/doc/sphinx/props/P_VISIBLE_GUILD.rst b/doc/sphinx/props/P_VISIBLE_GUILD.rst
new file mode 100644
index 0000000..1f579fb
--- /dev/null
+++ b/doc/sphinx/props/P_VISIBLE_GUILD.rst
@@ -0,0 +1,43 @@
+P_VISIBLE_GUILD
+===============
+
+NAME
+----
+::
+
+     P_VISIBLE_GUILD			"visible_guild"                       
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt die sichtbare Gilde des Lebewesens in Form eines
+     kleingeschriebenen Strings, also die Gilde, die bei Spielern zum
+     Beispiel bei 'kwer' oder 'finger' angezeigt wird. So kann man fremde
+     Gilden testen und trotzdem nach aussen hin in der gleichen Gilde wie
+     zuvor bleiben.
+
+BEISPIEL
+--------
+::
+
+     Wenn man gerne nach aussen hin Zauberer bleiben moechte:
+	  pl->SetProp(P_VISIBLE_GUILD,"zauberer");
+     Nach aussen hin bleibt man jetzt auch Zauberer, wenn P_GUILD eine
+     andere Gilde angibt.
+
+SIEHE AUCH
+----------
+::
+
+     P_GUILD, P_DEFAULT_GUILD
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/P_VISIBLE_SUBGUILD_TITLE.rst b/doc/sphinx/props/P_VISIBLE_SUBGUILD_TITLE.rst
new file mode 100644
index 0000000..499f5cd
--- /dev/null
+++ b/doc/sphinx/props/P_VISIBLE_SUBGUILD_TITLE.rst
@@ -0,0 +1,40 @@
+P_VISIBLE_SUBGUILD_TITLE
+========================
+
+NAME
+----
+::
+
+     P_VISIBLE_SUBGUILD_TITLE		"visible_subguild_title"                       
+
+DEFINIERT IN
+------------
+::
+
+     /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property dient dazu, als Magier einen Zusatztitel innerhalb einer
+     Gilde vorzutaeuschen, ohne den tatsaechlichen P_SUBGUILD_TITLE zu
+     aendern.
+
+BEMERKUNGEN
+-----------
+::
+
+     Inhalt der Property kann 0 sein oder ein String.
+     Wenn der Inhalt 0 ist, wird bei QueryProp der P_SUBGUILD_TITLE
+     durchgereicht.
+
+SIEHE AUCH
+----------
+::
+
+     P_GUILD_TITLE, P_SUBGUILD_TITLE
+
+
+Last modified: Mon Aug 13 21:20:00 2001 by Nachtwind
+
diff --git a/doc/sphinx/props/P_VISUALBELL.rst b/doc/sphinx/props/P_VISUALBELL.rst
new file mode 100644
index 0000000..de55bde
--- /dev/null
+++ b/doc/sphinx/props/P_VISUALBELL.rst
@@ -0,0 +1,59 @@
+P_VISUALBELL
+============
+
+NAME
+----
+::
+
+	P_VISUALBELL			"visualbell"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+	Die Property stellt ein Flag innerhalb von Spielern dar, welches
+	standardmaessig nicht gesetzt ist. In diesem Fall werden Toene,
+	welche innerhalb einiger Funktionen erzeugt werden, auch wirklich an
+	den Spieler geschickt.
+	Setzt man die Property, so erhaelt der Spieler keine Toene mehr.
+
+BEISPIEL
+--------
+::
+
+	Pieptoene werden durch den ASCII-Code 0x7 praesentiert. Ausgeben
+	kann man diesen folgendermassen:
+	  if(!IS_WIZARD(caster)&&!victim->QueryProp(P_VISUALBELL))
+	    tell_object(victim,sprintf("%c",7));
+	Das waere beispielsweise ein Codestueck aus einem Piepspell. :)
+	Das Opfer bekommt den Piepton hierbei nur ab, wenn der Caster ein
+	Magier ist oder das Spieleropfer die Property P_VISUALBELL gesetzt
+	hat (kann mit Kommando 'ton' vom Spieler beeinflusst werden).
+
+BEMERKUNGEN
+-----------
+::
+
+  Achtung: P_VISUALBELL steht auf 1, wenn der Spieler _keine_ Piepstoene
+	hoeren will!
+	Die Funktionalitaet dieser Property wirkt nur soweit, wie sie auch
+	von tonerzeugenden Befehlen selbst unterstuetzt wird. Es ist darauf
+	zu achten, dass P_VISUALBELL zu diesem Zweck grundsaetzlich
+	ausgewertet wird! Eine Ausnahme sei hierbei zugelassen: Magier
+	koennen Spielern grundsaetzlich Toene zusenden.
+
+SIEHE AUCH
+----------
+::
+
+	ton, wecke, erwarte, P_WAITFOR, /std/player/base.c
+
+
+Last modified: 07.02.2007 by Zesstra
+
diff --git a/doc/sphinx/props/P_VULNERABILITY.rst b/doc/sphinx/props/P_VULNERABILITY.rst
new file mode 100644
index 0000000..9ae5447
--- /dev/null
+++ b/doc/sphinx/props/P_VULNERABILITY.rst
@@ -0,0 +1,62 @@
+P_VULNERABILITY
+===============
+
+NAME
+----
+::
+
+     P_VULNERABILITY               "vulnerability"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/combat.h
+
+WICHTIG
+-------
+::
+
+     DIESE PROPERTY IST VERALTET! BITTE P_RESISTANCE_STRENGTHS
+     VERWENDEN! AUCH FUNKTIONIERT Set() NICHT WIE ES SOLLTE.
+
+BESCHREIBUNG
+------------
+::
+
+     Hiermit koennen die Empfindlichkeiten eines Lebewesens definiert
+     werden. Es kann ein Array mit Schadensarten gesetzt werden, jeder
+     Eintrag eines Schadens verdoppelt die Empfindlichkeit gegen
+     diesen.
+
+BEMERKUNGEN
+-----------
+::
+
+     - P_RESISTANCE_STRENGTHS spiegelt die Eintraege hier wieder
+     - um genauere Werte anzugeben einen AddResistanceModifier() oder
+       P_RESISTANCE_STRENGTHS benutzen.
+     - P_VULNERABILITY kann und wird nicht aus P_RESISTANCE_STRENGTHS
+       upgedatet
+
+BEISPIELE
+---------
+::
+
+     // ein NPC mit verdoppelter Eisempfindlichkeit und
+     // vervierfachter Wasserempfindlichkeit
+     SetProp(P_VULNERABILITY, ({DT_COLD, DT_WATER, DT_WATER}));
+
+SIEHE AUCH
+----------
+::
+
+     simple Resistenz:	P_RESISTANCE
+     Hauptmapping:	P_RESISTANCE_STRENGTHS
+     Modifikatoren:	AddResistanceModifier, RemoveResistanceModifier(),
+			P_RESISTANCE_MODIFIER
+     Berechnung:	CheckResistance(), UpdateResistanceStrengths()
+     anderes:		balance, /std/armour/combat.c, /std/living/combat.c
+
+1.Dez 2004, Gloinson
+
diff --git a/doc/sphinx/props/P_WAITFOR.rst b/doc/sphinx/props/P_WAITFOR.rst
new file mode 100644
index 0000000..ce863fc
--- /dev/null
+++ b/doc/sphinx/props/P_WAITFOR.rst
@@ -0,0 +1,30 @@
+P_WAITFOR
+=========
+
+NAME
+----
+::
+
+     P_WAITFOR                     "waitfor"                     
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Die Erwarte-Liste. Ein Array mit den Namen der Erwarteten.
+
+SIEHE AUCH
+----------
+::
+
+     erwarte
+     P_WAITFOR_REASON, P_WAITFOR_FLAGS
+
+16. Feb 2008 Gloinson
+
diff --git a/doc/sphinx/props/P_WAITFOR_FLAGS.rst b/doc/sphinx/props/P_WAITFOR_FLAGS.rst
new file mode 100644
index 0000000..218c5b2
--- /dev/null
+++ b/doc/sphinx/props/P_WAITFOR_FLAGS.rst
@@ -0,0 +1,34 @@
+P_WAITFOR_FLAGS
+===============
+
+NAME
+----
+::
+
+     P_WAITFOR_FLAGS                  "waitfor_flags"                     
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Ein Int. Bisher bekannte Flags:
+
+     
+
+     0x01 - "erwarte aus"
+
+SIEHE AUCH
+----------
+::
+
+     erwarte
+     P_WAITFOR, P_WAITFOR_REASON
+
+16. Feb 2008 Gloinson
+
diff --git a/doc/sphinx/props/P_WAITFOR_REASON.rst b/doc/sphinx/props/P_WAITFOR_REASON.rst
new file mode 100644
index 0000000..f812d27
--- /dev/null
+++ b/doc/sphinx/props/P_WAITFOR_REASON.rst
@@ -0,0 +1,35 @@
+P_WAITFOR_REASON
+================
+
+NAME
+----
+::
+
+     P_WAITFOR_REASON                  "waitfor_reason"                     
+
+DEFINIERT IN
+------------
+::
+
+     /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Ein Mapping mit den Erwarteten als Schluessel und einem Grund als
+     Key, zB:
+
+     
+
+     (["Zook":"muh muh"])
+
+SIEHE AUCH
+----------
+::
+
+     erwarte (erwarte <wen> wegen <was>)
+     P_WAITFOR, P_WAITFOR_FLAGS
+
+16. Feb 2008 Gloinson
+
diff --git a/doc/sphinx/props/P_WANTS_TO_LEARN.rst b/doc/sphinx/props/P_WANTS_TO_LEARN.rst
new file mode 100644
index 0000000..99ebbf9
--- /dev/null
+++ b/doc/sphinx/props/P_WANTS_TO_LEARN.rst
@@ -0,0 +1,25 @@
+P_WANTS_TO_LEARN
+================
+
+NAME
+----
+::
+
+    P_WANTS_TO_LEARN              "wants_to_learn"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/base.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gesetzt, wenn der Magier die Filenamen sehen will.
+     (Nur fuer Magier). Wird diese Property auf 0 gesetzt, gehen auch
+     einige andere Dinge nicht mehr - verfolge zB. Eigentlich sollten
+     dann auch die Magierbefehle wie "goto" usw unterbunden werden -
+     das kommt vielleicht noch.
+
diff --git a/doc/sphinx/props/P_WATER.rst b/doc/sphinx/props/P_WATER.rst
new file mode 100644
index 0000000..cc2d399
--- /dev/null
+++ b/doc/sphinx/props/P_WATER.rst
@@ -0,0 +1,131 @@
+P_WATER
+=======
+
+NAME
+----
+::
+
+    P_WATER                       "water"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/fishing.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt den Gewaessertyp. Kann in Raeumen, Angeln und Wasserbehaeltern
+    verwendet werden. Die verfuegbaren Optionen und Funktionsweisen sind in 
+    den nachfolgenden Abschnitten aufgefuehrt.
+
+    Raum:
+    *****
+      Legt den Typ des Gewaessers fest, das es in diesem Raum gibt. Von
+      diesem Typ haengt ab, welche Arten von Fischen es hier standardmaessig
+      gibt und welche Arten von Angeln verwendet werden koennen. 
+
+      
+
+      Beispiel:
+
+      SetProp(P_WATER, W_HARBOR);
+
+      
+
+      Folgende
+      Typen stehen zur Verfuegung, von denen in Raeumen nur einer gesetzt
+      werden darf:
+
+      Salzwasser:
+        W_BEACH   Strand: Scholle, Flunder, Rochen, Seezunge, Katzenhai
+        W_HARBOR  Hafen: Dorsch, Rochen, Seezunge, Hering, Katzenhai
+        W_OCEAN   Ozean/Meer: Hai, Thunfisch, Kabeljau, Schwertfisch, Seehase,
+                  Seeteufel, Seewolf
+
+      Suesswasser:
+        W_RIVER   Fluss: Piranha, Lachs, Forelle, Bachsaibling
+        W_POOL    Teich: Stichling, Goldfisch, Schlei, Karpfen, Goldorfe
+        W_LAKE    See: Karpfen, Barsch, Hecht, Seesaibling
+        W_ROCK    Bergbach: Lachs, Forelle, Bachsaibling
+        W_STREAM  Bach: Stichling, Bachforelle, Neuauge, Bachsaibling
+
+      Sonstige:
+        W_USER    wenn dieser Gewaessertyp gesetzt wird, MUSS der Raum 
+                  zusaetzlich die Funktion GetAquarium() definieren, die
+                  eine Liste der hier fangbaren Fische zurueckgeben muss.
+                  Beispiel:
+
+                  string* GetAquarium(){ 
+                    return ({"/d/ebene/fraggle/angel/fisch"}); 
+                  }
+        W_DEAD    Lebloses Wasser. Enthaelt keine Fische, man kann
+                  aber die Standardflasche fuellen.
+
+        W_OTHER   1024   // Flasche enthaelt Fluessigkeit!=Wasser
+
+
+    Angel:
+    ******
+      Angeln sind ueblicherweise auf bestimmte Anwendungsbereiche ausgelegt.
+      Ob eine Angel in einem Gewaesser benutzt werden kann, haengt davon ab,
+      ob P_WATER in der Angel den Gewaessertyp des Raumes enthaelt. Von den
+      oben genannten Typen koennen mehrere ver-ODER-t gesetzt werden.
+      Verwendung einer fuer das oertliche Gewaesser ungeeigneten Angel fuehrt
+      zu einer um 60+random(60) Sekunden verlaengerten Wartezeit beim Angeln.
+
+      
+
+      Beispiel: Setzt man den Gewaessertyp mit 
+
+        SetProp(P_WATER, W_HARBOR|W_OCEAN);
+
+      schaltet das die Angel sowohl fuer Haefen, als auch fuer offene Meere
+      (Ozeane) frei.
+
+      Folgende kombinierte Gewaessertypen sind fuer einfache Angeln 
+      vordefiniert:
+
+      Kurze Standardangeln:
+        W_SHORT W_HARBOR|W_RIVER|W_POOL|W_LAKE|W_ROCK|W_USER|W_OCEAN|W_STREAM
+      Spezielle Strandruten:
+        W_LONG  W_BEACH|W_USER
+      funktioniert in allen Salzgewaessern:
+        W_SALT  W_HARBOR|W_OCEAN|W_BEACH
+      funktioniert in allen Suessgewaessern:
+        W_SWEET W_RIVER|W_POOL|W_LAKE|W_ROCK|W_STREAM
+
+      Hinweis: W_DEAD ist in diesen Kombinationen nicht enthalten, da es
+      in solchen Gewaessern ohnehin keine Fische gibt.
+      Die Kombi-Typen enthalten W_USER, um bei entsprechenden Gewaessern
+      zu vermeiden, dass es dort standardmaessig einen Malus auf die 
+      Wartezeit gibt. Standardwert fuer P_WATER in Angeln ist ebenfalls 
+      W_USER.
+
+    Koeder:
+    *******
+      Auch Koeder koennen fuer die Verwendung in bestimmten Gewaessern besser
+      geeignet sein als in anderen, z.B. eine Seeschnecke fuer Salzwasser,
+      ein Mehlwurm hingegen fuer Suesswasser. Gesetzt wird P_WATER hierfuer
+      auf die oben aufgefuehrten Werte.
+      Verwendung eines ungeeigneten Koeders fuehrt zu einer um 60+random(60)
+      Sekunden laengeren Wartezeit beim Angeln.
+
+    Wasserbehaelter:
+    ****************
+      Die Property gibt an, ob der Behaelter Wasser enthaelt oder nicht.
+      Der Wert sollte immer auf den Typ jenes Gewaessers gesetzt sein, aus
+      dem der Behaelter aufgefuellt wurde.
+
+SIEHE AUCH
+----------
+::
+
+    Properties: P_FISH
+    Methoden:   GetAquarium(L)
+
+
+Zuletzt geaendert: 2014-Aug-21, Arathorn
+
diff --git a/doc/sphinx/props/P_WC.rst b/doc/sphinx/props/P_WC.rst
new file mode 100644
index 0000000..9129867
--- /dev/null
+++ b/doc/sphinx/props/P_WC.rst
@@ -0,0 +1,56 @@
+P_WC
+====
+
+NAME
+----
+::
+
+	P_WC				"wc"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/weapon.h
+
+BESCHREIBUNG
+------------
+::
+
+	Die Waffenklasse (engl: weapon class), also die Staerke der Waffe,
+	stellt einen numerischen Wert dar, der umso groesser ist, desto mehr
+	Schaden eine Waffe im Kampf anrichtet. Beim Zuecken oder Wegstecken
+	einer Waffe durch ein Lebewesen wird innerhalb des Lebewesens auch
+	die Property P_TOTAL_WC aktualisiert, welche somit immer die
+	aktuelle Angriffsstaerke enthaelt. Beim Zuecken erhaelt sie hierbei
+	die Waffenklasse der Waffe und beim Wegstecken die Angriffsstaerke
+	aus der Property P_HANDS (Kaempfen mit blossen Haenden).
+	Die Waffenklasse von einhaendigen Waffen sollte 150 nicht
+	ueberschreiten, die Obergrenze fuer zweihaendige Waffen liegt bei
+	200. Ausnahmen von dieser Regel beduerfen der Absprache mit dem
+	Erzmagier fuer Ruestungen, Waffen und Monster!
+	Negative Werte bewirken keinen Schaden, allerdings auch keine
+	Heilung.
+
+BEMERKUNGEN
+-----------
+::
+
+	Query- und Setmethoden auf P_WC sollten unbedingt vermieden werden. Sie
+	fuehren in der Regel zu massiven Inkonsistenzen im Mechanismus der 
+	Ruestungsbeschaedigung und -reparatur.
+	Auch mit einer HitFunc() duerfen die Obergrenzen nicht ohne
+	Absprache ueberschritten werden! Ausserdem ist es ratsam, die
+	zusaetzlichen Kampfeigenschaften in P_EFFECTIVE_WC gesondert
+	anzugeben.
+
+SIEHE AUCH
+----------
+::
+
+	/std/weapon.c, /std/weapon/combat.c
+	P_DAMAGED, P_EFFECTIVE_WC, P_WEAPON_TYPE
+	Damage()
+
+02.10.2007, Zesstra
+
diff --git a/doc/sphinx/props/P_WEAPON.rst b/doc/sphinx/props/P_WEAPON.rst
new file mode 100644
index 0000000..b9fde21
--- /dev/null
+++ b/doc/sphinx/props/P_WEAPON.rst
@@ -0,0 +1,31 @@
+P_WEAPON
+========
+
+NAME
+----
+::
+
+     P_WEAPON                      "weapon"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+      Momentan gezueckte Waffe. Im Living gesetzt.
+
+SIEHE AUCH
+----------
+::
+
+      Verwandt:		P_ARMOURS
+      Waffen:		P_WC, P_WEAPON_TYPE, P_DAM_TYPE, P_NR_HANDS, P_PARRY
+      Sonstiges:	P_UNWIELD_TIME, P_EQUIP_TIME, P_LAST_USE
+
+10.Feb 2005 Gloinson
+
diff --git a/doc/sphinx/props/P_WEAPON_TEACHER.rst b/doc/sphinx/props/P_WEAPON_TEACHER.rst
new file mode 100644
index 0000000..a38f8c9
--- /dev/null
+++ b/doc/sphinx/props/P_WEAPON_TEACHER.rst
@@ -0,0 +1,29 @@
+P_WEAPON_TEACHER
+================
+
+NAME
+----
+::
+
+    P_WEAPON_TEACHER              "weapon_teacher"
+
+DEFINIERT IN
+------------
+::
+
+    combat.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property wird in einem Azubi gesetzt (zur Zeit nur fuer die 
+    Kaempfer-Gilde), der selbst ueber die allgemeinen Waffenskills
+    verfuegt.
+
+    In diese Property wird der Name eines Kaempfergilden-Ausbilders
+    eingetragen.
+
+    Unter Anleitung des Ausbilders lernt der Azubi dann etwas schneller
+    die allgemeinen Waffenskills.
+
diff --git a/doc/sphinx/props/P_WEAPON_TYPE.rst b/doc/sphinx/props/P_WEAPON_TYPE.rst
new file mode 100644
index 0000000..56622c3
--- /dev/null
+++ b/doc/sphinx/props/P_WEAPON_TYPE.rst
@@ -0,0 +1,42 @@
+P_WEAPON_TYPE
+=============
+
+NAME
+----
+::
+
+     P_WEAPON_TYPE "weapon_type"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Um was fuer eine Waffe handelt es sich? Es stehen verschiedene
+     Typen zur Auswahl. Man sollte hier nur die in <combat.h> definierten
+     Konstanten verwenden:
+
+        WT_AMMU           Munition fuer Fernkampfwaffen
+        WT_AXE            Axt
+        WT_CLUB           Keule
+        WT_HANDS          blosse Haende
+        WT_KNIFE          Messer, Dolch
+        WT_RANGED_WEAPON  Fernkampfwaffe
+        WT_SPEAR          Speer
+        WT_STAFF          Kampfstab
+        WT_SWORD          Schwert
+        WT_WHIP           Peitsche
+        WT_MISC           Sonstiges
+
+    Der Waffentyp WT_MISC ist schnoedem Tand und nutzlosem Kram vorbehalten.
+    Waffen dieses Typs duerfen keine P_WC > 0 besitzen oder kampfrelevante
+    Bedeutung haben.
+
+
+Letzte Aenderung: 27. Mai 2015, Arathorn.
+
diff --git a/doc/sphinx/props/P_WEAR_FUNC.rst b/doc/sphinx/props/P_WEAR_FUNC.rst
new file mode 100644
index 0000000..951eecc
--- /dev/null
+++ b/doc/sphinx/props/P_WEAR_FUNC.rst
@@ -0,0 +1,44 @@
+P_WEAR_FUNC
+===========
+
+NAME
+----
+::
+
+     P_WEAR_FUNC "wear_func"
+
+DEFINIERT IN
+------------
+::
+
+     <armour.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Falls ein Objekt eine WearFunc() fuer die Ruestung / Kleidung definiert, 
+     so muss dieses Objekt in dieser Property eingetragen sein.
+
+     Die Auswertung dieser Property erfolgt in Laufe eines DoWear() in der
+     nicht-oeffentlichen Funktion _check_wear_restrictions()..
+
+BEISPIELE
+---------
+::
+
+     Siehe das Beispiel zu WearFunc()
+
+SIEHE AUCH
+----------
+::
+
+     armours, clothing, /std/clothing/wear.c, /std/armour/wear.c
+     WearFunc(), InformWear()
+
+LETZTE AeNDERUNG
+----------------
+::
+
+15.02.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_WEAR_MSG.rst b/doc/sphinx/props/P_WEAR_MSG.rst
new file mode 100644
index 0000000..231394c
--- /dev/null
+++ b/doc/sphinx/props/P_WEAR_MSG.rst
@@ -0,0 +1,82 @@
+P_WEAR_MSG
+==========
+
+NAME
+----
+::
+
+    P_WEAR_MSG                       "wear_msg"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/armour.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zweiteiliges Array mit Meldungen, die beim Anziehen einer Ruestung oder
+     Kleidung an den Spieler und die Umgebung ausgegeben werden.
+     Der erste Eintrag geht an den Spieler, der zweite Eintrag an die
+     Umgebung. Zeilenumbrueche werden automatisch gemacht, existierende
+     jedoch beruecksichtigt.
+
+     Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
+     man replace_personal()).
+
+     [Wegen Abwaertskompatibilitaet ist auch noch der Platzhalter %s
+      moeglich, wobei in der eigenen Meldung %s fuer den Waffennamen steht,
+      in der an den Raum das erste %s fuer den Spielernamen, das zweite fuer
+      den Waffennamen.]
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_NAME, "Helm");
+    SetProp(P_WEAR_MSG,
+     ({"Du stuelpst die @WEN2 ueber.", 
+       "@WER1 stuelpt sich @WENU2 ueber."}));
+
+    -> beim Anziehe durch Urk:
+       Urk bekommt: Du stuelpst dir den Helm ueber.
+       Der Raum:    Urk stuelpt sich einen Helm ueber.
+
+    SetProp(P_WEAR_MSG,
+     ({"Als Du Dir den langen Mantel ueberziehst, steckst Du erstmal "
+       "mit Deinem dicken Schaedel fest. Doch nach einem kraeftigen "
+       "Ruck bist Du endlich durch und siehst wieder etwas.",
+       "@WER1 zieht sich einen langen Mantel ueber und bleibt "
+       "prompt mit dem dicken Schaedel stecken. Doch nach einem "
+       "kraeftigen Ruck kann @WERQP1 wieder etwas sehen und grinst Dich "
+       "verlegen an."}));
+
+    -> beim Anziehen durch Urk:
+       Urk bekommt: Als Du Dir den langen Mantel ueberziehst, steckst Du
+		    erstmal mit Deinem dicken Schaedel fest. Doch nach einem
+		    kraeftigen Ruck bist Du endlich durch und siehst wieder
+		    etwas.
+
+       Der Raum:    Urk zieht sich einen langen Mantel ueber und bleibt
+		    prompt mit dem dicken Schaedel stecken. Doch nach
+		    einem kraeftigen Ruck kann er wieder etwas sehen und
+		    grinst Dich verlegen an.
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_UNWEAR_MSG, P_WIELD_MSG, P_UNWIELD_MSG
+                 P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_PICK_MSG
+     Funktionen: WearFunc, UnwearFunc, InformWear()
+     Sonstiges:  replace_personal(E), clothing, /std/clothing/wear.c
+                 armour, /std/armour/wear.c
+
+LETZTE AeNDERUNG
+----------------
+::
+
+15.02.2009
+
diff --git a/doc/sphinx/props/P_WEIGHT.rst b/doc/sphinx/props/P_WEIGHT.rst
new file mode 100644
index 0000000..8e51d18
--- /dev/null
+++ b/doc/sphinx/props/P_WEIGHT.rst
@@ -0,0 +1,48 @@
+P_WEIGHT
+========
+
+NAME
+----
+::
+
+    P_WEIGHT                      "weight"                      
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/restrictions.h
+
+BESCHREIBUNG
+------------
+::
+
+     - Objekte
+       Das Gewicht eines Objetes in Gramm.
+
+     - Speisen
+       Gewicht einer Portion der Speise.
+
+       
+
+BEMERKUNGEN
+-----------
+::
+
+     In tragbaren Speisen (erben von /std/food) setzt man mit SetProp
+     das Gewicht _einer_ Portion. Per QueryProp erhaelt man aber das
+     Gesamtgewicht der Speise inclusive des eventuell vorhandenen Behaelters.
+     Das Gewicht des Behaelters wird dabei aus P_EMPTY_PROPS[P_WEIGHT]
+     gelesen.
+
+     
+
+SIEHE AUCH
+----------
+::
+
+     Speisen: wiz/food, P_EMPTY_PROPS
+
+
+Last modified: Thu Oct 28 12:15:00 2010 by Caldra
+
diff --git a/doc/sphinx/props/P_WEIGHT_PERCENT.rst b/doc/sphinx/props/P_WEIGHT_PERCENT.rst
new file mode 100644
index 0000000..fbd34d3
--- /dev/null
+++ b/doc/sphinx/props/P_WEIGHT_PERCENT.rst
@@ -0,0 +1,47 @@
+P_WEIGHT_PERCENT
+================
+
+NAME
+----
+::
+
+    P_WEIGHT_PERCENT              "weight_percent"              
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property gibt an, wieviel Prozent des Gewichts des Inhaltes
+     "nach aussen" wiedergegeben werden.
+
+BEMERKUNGEN
+-----------
+::
+
+     Alle Werte die < 50% liegen sollten sehr gut begruendet und mit Vor-
+     sicht verwendet werden. Hier koennten dann zum Beispiel P_MAX_OBJECTS
+     auf einen kleinen Wert begrenzt werden.
+
+     Container die hier einen Wert ueber dem des Postpakets haben, sollten
+     auch schwer zu erreichen sein. Auf jeden Fall mit dem Regionsmagier
+     besprechen!
+
+BEISPIELE
+---------
+::
+
+     Um sich zu orientieren kann das Postpaket von Loco als Beispiel hin-
+     zugezogen werden (/p/service/loco/obj/parcel).
+
+SIEHE AUCH
+----------
+::
+
+     P_MAX_OBJECTS, P_MAX_WEIGHT, P_LIGHT_TRANSPARENCY, container
+
diff --git a/doc/sphinx/props/P_WEIGHT_PER_UNIT.rst b/doc/sphinx/props/P_WEIGHT_PER_UNIT.rst
new file mode 100644
index 0000000..f1789dc
--- /dev/null
+++ b/doc/sphinx/props/P_WEIGHT_PER_UNIT.rst
@@ -0,0 +1,29 @@
+P_WEIGHT_PER_UNIT
+=================
+
+NAME
+----
+::
+
+    P_WEIGHT_PER_UNIT             "weight_per_unit"             
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gewicht in Gramm pro Untereinheit.
+
+BEMERKUNGEN
+-----------
+::
+
+     Deprecated. Bitte SetGramsPerUnits() (U_GPU) benutzen.
+
+25.Aug 2015 Gloinson
+
diff --git a/doc/sphinx/props/P_WIELDED.rst b/doc/sphinx/props/P_WIELDED.rst
new file mode 100644
index 0000000..578ac3d
--- /dev/null
+++ b/doc/sphinx/props/P_WIELDED.rst
@@ -0,0 +1,38 @@
+P_WIELDED
+=========
+
+NAME
+----
+::
+
+     P_WIELDED "wielded"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Ist diese Property gesetzt, dann ist die Waffe gerade gezueckt. Der
+     Traeger ist in der Property vermerkt.
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Property laesst sich nur abfragen!
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon.c
+     P_WEAPON
+
+
+Last modified: 2015-Jul-11, Arathorn 
+
diff --git a/doc/sphinx/props/P_WIELD_FUNC.rst b/doc/sphinx/props/P_WIELD_FUNC.rst
new file mode 100644
index 0000000..eb0c93d
--- /dev/null
+++ b/doc/sphinx/props/P_WIELD_FUNC.rst
@@ -0,0 +1,39 @@
+P_WIELD_FUNC
+============
+
+NAME
+----
+::
+
+     P_WIELD_FUNC "wield_func"
+
+DEFINIERT IN
+------------
+::
+
+     <weapon.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Falls ein Objekt eine WieldFunc() fuer die Waffe definiert, so muss
+     dieses Objekt in dieser Property eingetragen werden.
+
+     Die Auswertung dieser Property erfolgt in wield_me().
+
+BEISPIELE
+---------
+::
+
+     Siehe das Beispiel zu WieldFunc()
+
+SIEHE AUCH
+----------
+::
+
+     /std/weapon.c, WieldFunc()
+
+
+Last modified: Sun May 19 15:40:02 1996 by Wargon
+
diff --git a/doc/sphinx/props/P_WIELD_MSG.rst b/doc/sphinx/props/P_WIELD_MSG.rst
new file mode 100644
index 0000000..5791666
--- /dev/null
+++ b/doc/sphinx/props/P_WIELD_MSG.rst
@@ -0,0 +1,74 @@
+P_WIELD_MSG
+===========
+
+NAME
+----
+::
+
+     P_WIELD_MSG                       "wield_msg" 
+
+DEFINIERT IN
+------------
+::
+
+     /sys/weapon.h
+
+BESCHREIBUNG
+------------
+::
+
+     Zweiteiliges Array mit Meldungen, die beim Zuecken einer Waffe an den
+     Spieler und die Umgebung ausgegeben werden.
+     Der erste Eintrag geht an den Spieler, der zweite Eintrag an die
+     Umgebung.  Zeilenumbrueche werden automatisch gemacht, existierende
+     jedoch beruecksichtigt.
+
+     Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
+     man replace_personal()).
+
+     [Wegen Abwaertskompatibilitaet ist auch noch der Platzhalter %s
+      moeglich, wobei in der eigenen Meldung %s fuer den Waffennamen steht,
+      in der an den Raum das erste %s fuer den Spielernamen, das zweite fuer
+      den Waffennamen.]
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_NAME, "Streitkolben");
+    SetProp(P_WIELD_MSG,
+     ({"Du zueckst @WEN2 und stoesst einen markerschuetternden Schrei aus.", 
+       "@WER1 zueckt @WENU2 und stoesst einen markerschuetternden Schrei "
+       "aus." }));
+
+    -> beim Zuecken durch Urk:
+       Urk bekommt: Du zueckst den Streitkolben und stoesst einen
+		    markerschuetternden Schrei aus.
+       Der Raum:    Urk zueckt einen Streitkolben und stoesst einen
+		    markerschuetternden Schrei aus.
+
+    SetProp(P_WIELD_MSG,
+     ({"Du zueckst den klobigen Streitkolben und fuchtelst damit "
+       "wild vor Deiner Nase herum.",
+       "@WER1 zueckt einen klobigen Streitkolben und fuchtelt "
+       "damit wild vor der eigenen Nase herum. Hoffentlich verletzt "
+       "@WERQP1 sich dabei nicht ..."}));
+
+    -> beim Zuecken durch Urk:
+       Urk bekommt: Du zueckst den klobigen Streitkolben und fuchtelst
+                    damit wild vor Deiner Nase herum.
+       Der Raum:    Urk zueckt einen klobigen Streitkolben und fuchtelt
+		    damit wild vor der eigenen Nase herum. Hoffentlich
+                    verletzt er sich dabei nicht ...
+
+SIEHE AUCH
+----------
+::
+
+     Aehnliches: P_UNWIELD_MSG, P_WEAR_MSG, P_UNWEAR_MSG
+                 P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_PICK_MSG
+     Funktionen: UnwieldFunc, WieldFunc
+     Sonstiges:  replace_personal(E), /std/weapon/combat.c
+
+29. Maerz 2004 Gloinson
+
diff --git a/doc/sphinx/props/P_WIMPY.rst b/doc/sphinx/props/P_WIMPY.rst
new file mode 100644
index 0000000..f24548c
--- /dev/null
+++ b/doc/sphinx/props/P_WIMPY.rst
@@ -0,0 +1,31 @@
+P_WIMPY
+=======
+
+NAME
+----
+::
+
+    P_WIMPY                       "wimpy"                       
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Numerischer Wert. Das Lebewesen flieht, wenn die Lebenspunkte
+     unter diesen Wert sinken.
+
+SIEHE AUCH
+----------
+::
+
+     P_WIMPY_DIRECTION
+
+
+Letzte Aenderung: Mon Feb 12 17:50:47 2001 von Tilly
+
diff --git a/doc/sphinx/props/P_WIMPY_DIRECTION.rst b/doc/sphinx/props/P_WIMPY_DIRECTION.rst
new file mode 100644
index 0000000..8db2198
--- /dev/null
+++ b/doc/sphinx/props/P_WIMPY_DIRECTION.rst
@@ -0,0 +1,41 @@
+P_WIMPY_DIRECTION
+=================
+
+NAME
+----
+::
+
+    P_WIMPY_DIRECTION             "wimpy_dir"                   
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+     Fluchtrichtung eines Spielers oder NPCs
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Fluchtrichtung kann nicht nur ein Ausgang (sueden, osten, ...)
+     sein, sondern auch ein Kommando, welches der Spieler beim Anschlagen
+     ausfuehrt (z.b. <kletter seil hoch> oder <rufe Elender Mist!>).
+
+     Ausgefuehrt wird die Fluchtrichtung per command(), wenn die LP des 
+     Lebewesens unter die mit <vorsicht> angegebe LP-Grenze sinkt.
+
+SIEHE AUCH
+----------
+::
+
+     P_WIMPY
+
+
+Letzte Aenderung: Mon Feb 12 17:46:47 2001 von Tilly
+
diff --git a/doc/sphinx/props/P_WIZ_DEBUG.rst b/doc/sphinx/props/P_WIZ_DEBUG.rst
new file mode 100644
index 0000000..041090b
--- /dev/null
+++ b/doc/sphinx/props/P_WIZ_DEBUG.rst
@@ -0,0 +1,37 @@
+P_WIZ_DEBUG
+===========
+
+NAME
+----
+::
+
+    P_WIZ_DEBUG                    "std_p_wizdebug"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player/comm.h
+
+BESCHREIBUNG
+------------
+::
+
+     Gesetzt, wenn der Magier (oder ein Testspieler) Debugmeldungen wahrnehmen
+     moechte.
+     Debugmeldungen sind Nachrichten, die mit dem Typ MT_DEBUG an ReceiveMsg()
+     uebergeben werden.
+
+     
+
+     Die Werte von P_WIZ_DEBUG sind zur Zeit 0 oder 1, das kann sich aber
+     jederzeit aendern.
+     Magier aendern diese Prop bitte ueber "mschau".
+
+SIEHE AUCH
+----------
+::
+
+     mschau
+     P_WANTS_TO_LEARN
+
diff --git a/doc/sphinx/props/P_WORN.rst b/doc/sphinx/props/P_WORN.rst
new file mode 100644
index 0000000..ec3b359
--- /dev/null
+++ b/doc/sphinx/props/P_WORN.rst
@@ -0,0 +1,63 @@
+P_WORN
+======
+
+NAME
+----
+::
+
+     P_WORN "worn"
+
+DEFINIERT IN
+------------
+::
+
+     <armour.h>
+
+BESCHREIBUNG
+------------
+::
+
+     Mittels dieser Property laesst sich ermitteln, ob eine Ruestung bzw. 
+     Kleidung derzeit getragen wird und wenn ja, von wem.
+
+     Entweder enthaelt die Property den Wert 0, oder sie enthaelt den
+     Traeger der Ruestung / Kleidung (als Objekt).
+
+BEMERKUNGEN
+-----------
+::
+
+     Diese Property laesst sich nur abfragen!
+
+BEISPIELE
+---------
+::
+
+     Eine DefendFunc() koennte dem Traeger der Ruestung wie folgt etwas
+     mitteilen:
+
+     // Die Ruestung gibt Schutz gegen Feuer
+     int DefendFunc(string *dtyp, mixed spell, object enemy)
+     {
+       if (member(dtyp, DT_FIRE) != -1) {
+         // P_WORN ist auf jeden Fall gesetzt, da sonst die
+         // DefendFunc ueberhaupt nicht aufgerufen wuerde!
+         tell_object(QueryProp(P_WORN),
+           "Die Flammen zuengeln nur leicht ueber die Ruestung.\n");
+         return 10;
+       }
+       return 0;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     clothing, /std/clothing.c, armour, /std/armour.c
+
+LETZTE AeNDERUNG
+----------------
+::
+
+15.02.2009, Zesstra
+
diff --git a/doc/sphinx/props/P_XP.rst b/doc/sphinx/props/P_XP.rst
new file mode 100644
index 0000000..ec4864a
--- /dev/null
+++ b/doc/sphinx/props/P_XP.rst
@@ -0,0 +1,81 @@
+P_XP
+====
+
+NAME
+----
+::
+
+     P_XP                    "xp"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/living/life.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property enthaelt die Anzahl der Erfahrungspunkte, die ein
+     Lebewesen erreicht hat. Dies geschieht insbesondere durch
+     Kampfhandlungen, wobei es sowohl fuer Einzelschlaege als auch fuer
+     das Toeten eines Opfers Punkte gibt.
+
+     Bei einzelnen Schlaegen ist die Vergabe von Erfahrungspunkten davon
+     abhaengig, wie stark man das Opfer getroffen hat, und welche
+     Gesamtwaffenklasse es hat (damage*P_TOTAL_WC/10).
+
+     Beim Todesschlag erhaelt man zusaetzlich die Erfahrungspunkte des
+     Opfers geteilt durch 100 (P_XP/100). Dieser Wert wird allerdings
+     gegebenenfalls auf ein Team aufgeteilt, sofern der Angreifer sich in
+     einem solchigen befindet.
+
+BEISPIEL
+--------
+::
+
+     NPC's gibt man im allgemeinen einen levelabhaengigen Sockelwert an
+     Erfahrungspunkten mit, da sie nicht allzuoft selbst Gegner toeten
+     und somit kaum die Moeglichkeit haben, diese Punkte selbst
+     anzusammeln. Trotzdem sollen sie ja dem Spieler eine gewisse Anzahl
+     an Erfahrungspunkten liefern, wenn sie getoetet werden:
+
+       include "/sys/living/life.h"
+       inherit "std/npc";
+       void create() {
+         ...
+         SetProp(P_XP,25000000);
+       }
+
+     Beim Toeten gibt es nun 25.000.000/100 = 250.000 Erfahrungspunkte.
+     Damit wird der NPC sogar automatisch fuer die Vergabe von
+     Erstkillstufenpunkten vorgesehen.
+
+     Die Funktion create_default_npc() setzt P_XP und andere Eigenschaften
+     auf geeignete Werte.
+
+BEMERKUNGEN
+-----------
+::
+
+     Die Vergabe von Erstkillstufenpunkten kann man ueber die Property
+     P_NO_SCORE unterbinden, die Vergabe von Erfahrungspunkten ueber
+     P_NO_XP. Automatisch werden Lebewesen fuer Erstkillstufenpunkte
+     vorgesehen, sofern sie eine der folgenden Grenzen ueberschritten
+     haben:
+       SCORE_LOW_MARK:  200000 (1 Stufenpunkt)
+       SCORE_HIGH_MARK: 600000 (2 Stufenpunkte)
+     Definiert sind die Konstanten in "/secure/scoremaster.h".
+
+SIEHE AUCH
+----------
+::
+
+     Funktionen:  AddExp(), do_damage()
+     Verwandt:    P_NO_XP, P_LAST_XP
+     Sonstiges:   P_NO_SCORE, create_default_npc()
+                  P_TOTAL_WC
+
+14.Feb 2007 Gloinson
+
diff --git a/doc/sphinx/props/P_X_ATTR_MOD.rst b/doc/sphinx/props/P_X_ATTR_MOD.rst
new file mode 100644
index 0000000..3cd36bf
--- /dev/null
+++ b/doc/sphinx/props/P_X_ATTR_MOD.rst
@@ -0,0 +1,68 @@
+P_X_ATTR_MOD
+============
+
+NAME
+----
+::
+
+    P_X_ATTR_MOD                  "extern_attributes_modifier"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mapping, das die Attribute des Spielers veraendert, der das Objekt bei
+    sich hat.
+
+    Zu beachten:
+    Diese Property bitte _ausschliesslich_ mit SetProp aendern, weil damit
+    gleichzeitig UpdateAttributes() im Lebewesen aufgerufen und ggf. das
+    Objekt als Statmodifizierer registriert wird.
+
+    Diese Property ist fuer Krankheiten, Flueche etc. gedacht. Bei
+    Waffen/Ruestungen, die die Attribute beeinflussen sollen, verwendet
+    man besser P_M_ATTR_MOD.
+
+    P_X_ATTR_MOD und P_M_ATTR_MOD duerfen einen gemeinsamen kumulierten
+    positiven Grenzwert nicht ueberschreiten. Dieser Grenzwert,
+    CUMULATIVE_ATTR_LIMIT, ist in /sys/living/attributes.h definiert.
+
+BEMERKUNGEN
+-----------
+::
+
+    Die Methode /std/thing/restrictions::_set_extern_attributes_modifier()
+    benachrichtigt tragende Livings ueber Aenderungen.
+    Bitte beim "Loeschen" der Prop nicht den Wert des jew. Attributes im
+    uebergebenen Mapping als 0 uebergeben, sondern das Key/Werte-Paar ganz
+    entfernen und bzw. ein leeres Mapping oder 0 uebergeben.
+
+BEISPIEL
+--------
+::
+
+    // Dem Lebewesen, das das Objekt bei sich hat, wird 2 von A_INT abgezogen
+    SetProp(P_X_ATTR_MOD,([A_INT:-2]));
+
+    // Stats wiederherstellen:
+    SetProp(P_X_ATTR_MOD,([]));
+
+SIEHE AUCH
+----------
+::
+
+    QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
+    SetAttribute(), SetRealAttribute(), UpdateAttributes(),
+    SetTimedAttrModifier(), QueryTimedAttrModifier(),
+    DeleteTimedAttrModifier(),
+    P_X_HEALTH_MOD, P_M_HEALTH_MOD, P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS,
+    P_TIMED_ATTR_MOD, P_M_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
+
+02.02.2016, Gloinson
+
diff --git a/doc/sphinx/props/P_X_HEALTH_MOD.rst b/doc/sphinx/props/P_X_HEALTH_MOD.rst
new file mode 100644
index 0000000..7f294e3
--- /dev/null
+++ b/doc/sphinx/props/P_X_HEALTH_MOD.rst
@@ -0,0 +1,60 @@
+P_X_HEALTH_MOD
+==============
+
+NAME
+----
+::
+
+    P_X_HEALTH_MOD                  "extern_health_modifier"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/living/attributes.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mapping, mit dem die maximalen Lebenspunkte und Magiepunkte eines
+    Spielers veraendert werden, der dieses Objekt bei sich traegt.
+
+    Zu beachten: Diese Property bitte _ausschliesslich_ mit SetProp
+    aendern, weil damit gleichzeitig UpdateAttributes() im
+    Lebewesen aufgerufen und ggf. das Objekt als Statmodifizierer 
+    registriert wird.
+
+    Bei Ruestungen/Waffen, die diese Wirkung entfalten sollen, verwendet
+    man besser P_M_HEALTH_MOD.
+
+BEMERKUNGEN
+-----------
+::
+
+    Bitte bei "Loeschen" der Prop nicht den Wert des jew. Attributes im 
+    uebergebenen Mapping als 0 uebergeben, sondern das Key/Werte-Paar ganz 
+    entfernen und ggf. ein leeres Mapping oder 0 uebergeben.
+
+BEISPIEL
+--------
+::
+
+    // Dem Spieler, der das Objekt bei sich traegt, wird P_MAX_HP um 5
+    // erhoeht und P_MAX_SP um 5 erniedrigt.
+    SetProp(P_X_HEALTH_MOD,([P_HP:5,P_SP:-5]));
+    // Stats wiederherstellen:
+    SetProp(P_X_HEALTH_MOD,([]);
+
+SIEHE AUCH
+----------
+::
+
+    P_M_HEALTH_MOD, P_X_ATTR_MOD, P_M_ATTR_MOD, balance
+
+LETZTE AeNDERUNG
+----------------
+::
+
+    Sat, 06.02.1999, 14:00:00 von Paracelsus
+
diff --git a/doc/sphinx/props/P_ZAP_MSG.rst b/doc/sphinx/props/P_ZAP_MSG.rst
new file mode 100644
index 0000000..03ba0c1
--- /dev/null
+++ b/doc/sphinx/props/P_ZAP_MSG.rst
@@ -0,0 +1,42 @@
+P_ZAP_MSG
+=========
+
+NAME
+----
+::
+
+      P_ZAP_MSG			"zap_msg"
+
+DEFINIERT IN
+------------
+::
+
+      /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+      Die Property enthaelt ein dreielementiges Array mit den folgenden
+      Eintraegen:
+	  1.) Meldung, die der Magier beim Zappen bekommt.
+	  2.) Meldung, die die Spieler im Raum beim Zappen bekommen.
+	  3.) Meldung, die das Opfer beim Zappen bekommt.
+
+      Mit @@wer@@, @@wessen@@, ... kann der Name des Opfers und mit @@ich@@
+      der Name des Magiers in die Meldung eingewoben werden.
+
+      Die Property ist in Magiern gesetzt und gilt nur dort.
+
+SIEHE AUCH
+----------
+::
+
+     Tod:		die(L)
+     Todesmeldungen:	P_KILL_NAME, P_KILL_MSG, P_DIE_MSG, P_MURDER_MSG
+			P_ENEMY_DEATH_SEQUENCE
+     Sonstiges:		P_CORPSE, P_NOCORPSE, /room/death/death_room.c
+
+
+Last modified: Wed Jan 14 19:17:06 1998 by Patryn
+
diff --git a/doc/sphinx/props/U_REQ.rst b/doc/sphinx/props/U_REQ.rst
new file mode 100644
index 0000000..3246b41
--- /dev/null
+++ b/doc/sphinx/props/U_REQ.rst
@@ -0,0 +1,83 @@
+U_REQ
+=====
+
+NAME
+----
+::
+
+    U_REQ                         "u_req"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/unit.h
+
+BESCHREIBUNG
+------------
+::
+
+     Die Prop kann in Unitobjekten gesetzt werden.
+     Sie gibt die Anzahl der Einheiten an, die an der Unit manipuliert werden
+     sollen, falls mit weniger als P_AMOUNT umgegegangen werden soll.
+
+     
+
+     Die Prop wird automatisch gesetzt, wenn id() an einem Unitobjekt gerufen
+     wird und die ID grundsaetzlich zutreffend ist, die aus der ID ermittelte
+     Zahl aber kleiner als P_AMOUNT ist.
+     Sie kann auch manuell mittel SetProp() (aber nicht Set()) gesetzt werden.
+
+     U_REQ wird beim Bewegen und Zerstoeren, bei Ermittlung von Wert und
+     Gewicht beruecksichtigt.
+
+     U_REQ wird vom Unitobjekt automatisch wieder auf P_AMOUNT gesetzt, wenn
+     sich query_verb() oder debug_info(DINFO_EVAL_NUMBER) veraendert haben.
+     (DINFO_EVAL_NUMBER ist eine Zahl, die sich jedesmal erhoeht, wenn der
+      Driver eine neue Berechnung/Ausfuehrung beginnt. Diese Nummer wird fuer
+      jeden vom driver initiierten Aufruf von LPC-Code erhoeht, z.B. bei jedem
+      Kommando, call_out, heart_beat etc. Details s. debug_info().)
+
+     Ebenso wird U_REQ bei der Vereinigung mit einem anderen (gleichen)
+     Objekt auf P_AMOUNT des vereinigten Objektes gesetzt.
+
+BUGS
+----
+::
+
+    Viele. Dies ist ein uebler Hack. Geht aber nicht ohne.
+    Diese Prop war endlos lang gar nicht dokumentiert. Hier beschrieben ist
+    das Verhalten, was zur Zeit vorliegt. Dies mag unterschiedlich zu dem
+    irgendwann intendierten sein.
+
+BEISPIELE
+---------
+::
+
+    object o = clone_object("unitobjekt");
+    o->SetProp(P_AMOUNT, 100);   // ab jetzt hat o 100 Einheiten.
+    o->move(npc, M_GET);         // ob mit 100 Einheiten wird bewegt
+    o->SetProp(U_REQ, 50);
+    o->move(anderernpc, M_GIVE); // 50 Einheiten werden bewegt, 50 verbleiben
+    (Technisch: das Objekt wird auf 50 Einheiten geaendert, bewegt und in der
+     alten Umgebung wird ein neues Objekt mit 50 Einheiten erzeugt.)
+
+    o->SetProp(U_REQ, 42);
+    o->remove(1);               // 42 Einheiten von den 50 werden zerstoert.
+    (Technisch: P_AMOUNT wird einfach um U_REQ reduziert.)
+
+    # gib 18 muenzen an blupp
+    Hierbei wird ob->id("18 muenzen") gerufen, was U_REQ im Geldobjekt auf 18
+    setzt. Bei der Bewegung bekommt blupp daher das Objekt mit P_AMOUNT==18
+    und der Rest wird im Abgebenden neu erzeugt.
+    # gib geld an flubbel
+    Das U_REQ aus dem verherigen Kommando ist jetzt nicht mehr gueltig. Zwar
+    ist es das gleiche Kommandoverb, aber DINFO_EVAL_NUMBER ist jetzt
+    anders.
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+16.01.2015, Zesstra
+
diff --git a/doc/sphinx/props/gildenprops/P_GLOVE_FINGERLESS.rst b/doc/sphinx/props/gildenprops/P_GLOVE_FINGERLESS.rst
new file mode 100644
index 0000000..f304503
--- /dev/null
+++ b/doc/sphinx/props/gildenprops/P_GLOVE_FINGERLESS.rst
@@ -0,0 +1,30 @@
+P_GLOVE_FINGERLESS
+==================
+
+NAME
+----
+::
+
+     P_GLOVE_FINGERLESS                     "fingerfreie_handschuhe"
+
+DEFINIERT IN
+------------
+::
+
+     /p/katzenkrieger/kkrieger.h
+
+BESCHREIBUNG
+------------
+::
+
+     So gekennzeichnete Handschuhe sind fingerlos und koennen
+     waehrend "krallenschlag" getragen werden.
+
+SIEHE AUCH
+----------
+::
+
+     Verwandt:	P_ARMOUR_TYPE, AT_GLOVE
+
+10.Okt 2006 Gloinson
+
diff --git a/doc/sphinx/props/gildenprops/P_Z_AUTOSHIELD.rst b/doc/sphinx/props/gildenprops/P_Z_AUTOSHIELD.rst
new file mode 100644
index 0000000..6113175
--- /dev/null
+++ b/doc/sphinx/props/gildenprops/P_Z_AUTOSHIELD.rst
@@ -0,0 +1,43 @@
+P_Z_AUTOSHIELD
+==============
+
+NAME
+----
+::
+
+     P_Z_AUTOSHIELD				"z_autoshield"
+
+DEFINIERT IN
+------------
+::
+
+     /p/zauberer/wiznpc.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mit dieser Property  kann man einen automatischen 
+     Schutzzauber in Zauberer-NPCs einstellen, dessen 
+     Vorhandensein dann in jeder Kampfrunde ueberprueft
+     wird, z.B. "schutz","schutzhuelle","zauberschild".
+
+BEMERKUNGEN
+-----------
+::
+
+     "zauberschild" ist ein Magisterspruch und kann nur in 
+     bestimmten Zeitabstaenden benutzt werden. Wer also als
+     Autoshield nur Zauberschild benutzt, blockiert damit
+     alle anderen Spells, solange der Magisterspruch nicht
+     gesprochen werden kann.
+     Abhilfe: _query_next_master_spell_time()  return 0; }
+
+SIEHE AUCH
+----------
+::
+
+     /p/zauberer/text/wiznpc.doku
+
+21.Okt 2006 Chagall
+
diff --git a/doc/sphinx/props/gildenprops/P_Z_INFO.rst b/doc/sphinx/props/gildenprops/P_Z_INFO.rst
new file mode 100644
index 0000000..6d9cbeb
--- /dev/null
+++ b/doc/sphinx/props/gildenprops/P_Z_INFO.rst
@@ -0,0 +1,73 @@
+P_Z_INFO
+========
+
+NAME
+----
+::
+
+     P_Z_INFO						"z_info"
+
+DEFINIERT IN
+------------
+::
+
+     /p/zauberer/wiznpc.h
+
+BESCHREIBUNG
+------------
+::
+
+     Diese Property muss gesetzt werden, wenn man den
+     Zauberergilden-Standard-NPC nutzt. Sie setzt die
+     Grundeinstellungen des NPCs und generiert das 
+     Newskills-Mapping. 
+
+     Die Property ist wie folgt aufgebaut:
+
+     * MIN (minimale Skillability im Bereich von 0 - 10000)
+     * MAX (maximale Skillability im Bereich von 0 - 10000)
+     * LEV (Gildenlevel)
+     * ZWEIG (Gildenzweig)
+
+BEMERKUNGEN
+-----------
+::
+
+     Fuer die Argumente LEV und ZWEIG stehen folgende Auswahl-
+     moeglichkeiten zur Verfuegung.
+
+     LEV:
+
+        Z_ANFAENGER	0
+	Z_LEHRLING	1
+	Z_MEISTER	2
+	Z_ERZMEISTER	3
+
+     ZWEIG:
+
+        ZZW_ANGRIFF		  1
+	ZZW_ABWEHR		  2
+	ZZW_ILLUSION		  4
+	ZZW_BEHERRSCHUNG	  8
+	ZZW_HELLSICHT		 16
+	ZZW_VERWANDLUNG		 32
+	ZZW_SCHWARZ		 64	INAKTIV
+	ZZW_WEISS		128
+	ZZW_ALLE		511
+
+BEISPIEL
+--------
+::
+
+     SetProp(P_Z_INFO, ({9000, 9500, Z_ERZMEISTER, ZZW_ANGRIFF|ZZW_ABWEHR}));
+     erzeugt einen Erzmagister-PC, der alle Lehrlings- sowie die Magister und
+     Erzmagister-Sprueche Angriff und Abwehr mit 90-95% beherrscht.
+
+SIEHE AUCH
+----------
+::
+
+     /p/zauberer/text/wiznpc.doku
+
+21.Okt 2006 Chagall
+
diff --git a/doc/sphinx/props/gildenprops/P_Z_NO_MATERIAL.rst b/doc/sphinx/props/gildenprops/P_Z_NO_MATERIAL.rst
new file mode 100644
index 0000000..b01c43c
--- /dev/null
+++ b/doc/sphinx/props/gildenprops/P_Z_NO_MATERIAL.rst
@@ -0,0 +1,34 @@
+P_Z_NO_MATERIAL
+===============
+
+NAME
+----
+::
+
+     P_Z_NO_MATERIAL                     "npc_braucht_keine_kmp"
+
+DEFINIERT IN
+------------
+::
+
+     /p/zauberer/zauberer.h
+
+BESCHREIBUNG
+------------
+::
+
+     Setzt man diese Property in einem NPC, so benoetigt er fuer die
+     Sprueche der Zauberergilde keine Komponenten.
+
+BEMERKUNGEN
+-----------
+::
+
+     NIEMALS diese Property einfach so in einem Spieler setzen.
+
+SIEHE AUCH
+----------
+::
+
+21.Okt 2006 Chagall
+
diff --git a/doc/sphinx/props/gildenprops/P_Z_NO_NOCONN.rst b/doc/sphinx/props/gildenprops/P_Z_NO_NOCONN.rst
new file mode 100644
index 0000000..32b38a0
--- /dev/null
+++ b/doc/sphinx/props/gildenprops/P_Z_NO_NOCONN.rst
@@ -0,0 +1,42 @@
+P_Z_NO_NOCONN
+=============
+
+P_Z_NO_NOCON
+------------
+::
+
+NAME
+----
+::
+
+     P_Z_NO_NOCON					"no_nocon"
+
+DEFINIERT IN
+------------
+::
+
+     /p/zauberer/wiznpc.h
+
+BESCHREIBUNG
+------------
+::
+
+     Der Standardzauberergildennpc setzt SI_NO_CONSEQUENCES, damit
+     die Gildenpcs nicht den negativen Auswirkungen beim Misslingen
+     der Sprueche geschuetzt sind. Setzt man diese Property vor
+     P_Z_INFO auf 0, wird das Flag nicht gesetzt.
+
+BEMERKUNGEN
+-----------
+::
+
+     Muss vor P_Z_INFO gesetzt werden, damit es wirksam ist.
+
+SIEHE AUCH
+----------
+::
+
+     /p/zauberer/text/wiznpc.doku, P_Z_INFO
+
+21.Okt 2006 Chagall
+
diff --git a/doc/sphinx/props/gildenprops/P_Z_NO_SPELL_SUPPORT.rst b/doc/sphinx/props/gildenprops/P_Z_NO_SPELL_SUPPORT.rst
new file mode 100644
index 0000000..da7a05a
--- /dev/null
+++ b/doc/sphinx/props/gildenprops/P_Z_NO_SPELL_SUPPORT.rst
@@ -0,0 +1,41 @@
+P_Z_NO_SPELL_SUPPORT
+====================
+
+NAME
+----
+::
+
+     P_Z_NO_SPELL_SUPPORT	"zauberer_ruestung_unterstuetzt_noch_nicht"
+
+DEFINIERT IN
+------------
+::
+
+     /p/zauberer/zauberer.h
+
+BESCHREIBUNG
+------------
+::
+
+     Normalerweise unterstuetzt eine Ruestung den Zauberer, sobald sie im
+     entsprechenden Ruestungsmaster eingetragen ist. Moechte man allerdings
+     die Unterstuetzung an bestimmte Bedingungen knuepfen, z.B. das loesen
+     einer Miniquest, so kann man diese Property auf 1 setzen. Die Ruestung
+     unterstuetzt dann nicht. Um die Unterstuetzung wieder zu aktivieren,
+     setzt man die Property wieder auf 0.
+
+BEMERKUNGEN
+-----------
+::
+
+     NIEMALS diese Property einfach so in fremden Zaubererruestungen 
+     setzen. Sollte der Gildenmagier erfahren, dass z.B. ein NPC
+     einfach so die Unterstuetzung der Ruestungen ausschaltet, wird
+     diese Property wieder deaktiviert.
+
+SIEHE AUCH
+----------
+::
+
+21.Okt 2006 Chagall
+
diff --git a/doc/sphinx/props/gildenprops/kaempferboni.rst b/doc/sphinx/props/gildenprops/kaempferboni.rst
new file mode 100644
index 0000000..6d61f83
--- /dev/null
+++ b/doc/sphinx/props/gildenprops/kaempferboni.rst
@@ -0,0 +1,271 @@
+kaempferboni
+============
+
+Kaempferboni und deren Implementation
+
+-------------------------------------
+
+Bei den Kaempfern gibt es einige Properties, die, in Waffen oder Ruestungen
+gesetzt, der Kampfverlauf eines Spielers erheblich beeinflussen koennen.
+
+Zu beachten ist, dass die Abnahme von Waffen oder Ruestungen mit Kaempferboni
+allein der Balance obliegt. Der Gildenmagier der Kaempfer steht aber gerne
+mit Rat und Tat zur Seite.
+
+
+Abschnitt A
+
+
+In Waffen koennen nachfolgende, in /p/kaempfer/kaempfer.h definierten,
+Properties gesetzt werden. Die meisten davon fungieren als 'Boni' und werden
+dem Spieler auch mittels 'schaetz <waffe>' angezeigt
+
+
+1 Waffenschlagbonus - K_BRAWLING_WC (INT) - "k_brawling_wc"
+
+  Wenn die Waffe eine zusaetzlich gefaehrliche Stelle besitzt - z.B. einen
+  harten Dorn am Stielende, eine Spitze am Ruecken einer Axtklinge, Zacken
+  am Dolchgriff - kann man der Waffe einen Waffenschlagbonus geben.
+  Dies bedeutet, dass der Waffenschlag um ein paar Prozente verstaerkt wird,
+  da der Spieler natuerlich versucht, immer genau mit diesem 'feature'
+  den Waffenschlag auszufuehren (der Waffenschlag ist kurz gesagt ein
+  unerwarteter Schlag, der nicht mit dem 'normalen' Waffenende ausgefuehrt
+  wird, der Gegner wird dadurch ueberrascht -> mehr Schaden).
+  Da solch ein 'feature' doch recht auffaellig ist, sollte es in der
+  Langbeschreibung der Waffe auf jeden Fall erwaehnt werden.
+
+  Interessant zu wissen waere noch, dass Zweihandwaffen einen generellen
+  zusaetzlichen Bonus auf den Waffenschlag bekommen und dass es eine
+  Abstufung gibt, nach der die Waffengattungen die Hoehe des Basiswertes
+  gesetzt bekommen, wobei Speere den hoechsten und Messer den niedrigsten
+  besitzen
+
+  Speere - Kampfstaebe - Aexte - Keulen - Schwerter - Messer
+
+  Der max. Bonus fuer diese Property betraegt 30, wobei 1-10 -> geringer
+  Bonus, 11-20 -> guter Bonus, 21-30 -> sehr guter Bonus.
+
+  Bitte beachten ein Zweihand-Speer mit max. P_WC und max. K_BRAWLING_WC
+  haut entsprechend gut rein und sollte nur schwer zu ergattern sein, bzw.
+  noch andere Auflagen haben (ggf. unique, personalisiert, etc.)
+
+
+2 Waffenschlagschaden - K_BRAWLING_DT (STRING) - "k_brawling_dt"
+
+  Wenn die Waffe, mit der der Kaempfer einen Waffenschlag ausfuehrt, ein
+  'feature' hat, mit dem er diesen Schlag ausfuehrt, kann dieses 'feature'
+  einen anderen Waffenschlagschaden besitzen. Z.B. kann ein Schwert, welches
+  normalerweise DT_SLASH macht, besonders lange und spitze Parierstangen
+  besitzen, die vielleicht auch noch vergiftet sind. Dann kann der Magier
+  ({DT_PIERCE,DT_POISON}) setzen, so dass beim Waffenschlag immer ein
+  Mischschaden aus Stiche und Gift erfolgt.
+
+
+3 Waffenschlagsmeldung - K_BRAWLING_MSG (STRING/STRING*) - k_brawling_msg"
+
+  In diese Property kann man hineinschreiben, mit welchem Teil der Waffe
+  der Waffenschlag ausgefuehrt wird. Angenommen, es bietet sich an, mit
+  einer Waffe stets den Waffenschlag mit einem grossen Knauf am Griff
+  auszufuehren, wird schlicht und einfach "mit einem grossen Knauf am
+  Griff der Schlachtaxt" in die Property gesetzt.
+  Sollte sich bei der Programmierung ergeben, dass es sich anbietet, der
+  Waffe mehr als nur eine guenstige Stelle anzudichten mit der man den
+  Waffenschlag ausfuehren kann, so setzt man ein Array, z.B. ({"mit einem
+  grossen Knauf am Griff der Schlachtaxt","mit der breiten Seite der "
+  "Schlachtaxtklinge"}). Insgesamt ist darauf zu achten, dass die Meldungen
+  'vollstandig' sind. Das Array kann beliebige Groesse annehmen, es wird
+  dann zufaellig eine Meldung beim Schlag ausgesucht.
+
+  Es empfiehlt sich, jede Waffe mit dieser Property zu schmuecken, die
+  K_BRAWLING_WC gesetzt haben, da die Waffenschlagmeldungen damit im Kampf
+  'individualisiert' werden. In der Praxis wird es jedoch daran scheitern,
+  dass es viel zu viele alte Waffen gibt, die keiner mehr anfassen moechte.
+  Daher wird auf Standardmeldungen zurueckgegriffen, sollte diese Property
+  nicht gesetzt sein.
+
+
+4 Waffenbruchbonus - K_WEAPON_SHATTER (INT) - "k_weapon_shatter"
+
+  Waffen, die besonders fuer den Waffenbruch konstruiert wurden, koennen
+  einen Bonus einbringen, der in dieser Property angegeben wird. Natuerlich
+  eignen sich die verschiedenen Waffentypen wieder unterschiedlich gut fuer
+  einen Waffenbruch Keulen (meist aufgrund ihres Gewichts) am besten, Messer
+  am schlechtesten, alle anderen dazwischen (Axt - Schwert - Stab - Speer).
+  Dabei kriegen alle Waffen, die u.a. Schlagschaden verursachen, nochmal
+  einen kleinen Bonus obendrauf.
+
+  Der max. Bonus fuer diese Property betraegt 50, wobei 1-10 -> geringer
+  Bonus, 11-30 -> guter Bonus, 31-50 -> sehr guter Bonus.
+
+  Bei gut gelungenem Waffenbruch wird die Waffe des Gegners beschaedigt, wenn
+  die Technik sehr gut gelingt, kann es auch sein, dass dem Gegner die Waffe
+  aus der Hand geschlagen wird (der Spieler kann sie allerdings nicht
+  aufheben und der NPC zueckt sie nach ein paar Kampfrunden wieder).
+
+
+5 Bonus fuer Finte/Waffentrick - K_DISTRACTING_WEAPON (INT) -
+  "k_distracting_weapon"
+
+  Waffen, die fuer den Gegner aufgrund ihrer Bauweise besonders irritierend
+  sein koennen, koennen einen Bonus fuer Finte und Waffentrick haben. Dabei
+  wird der Gegner bei einer Finte bzw. einem Waffentrick NOCH mehr verwirrt,
+  als er es ohnehin schon nur durch die angewandte Technik wird.
+  Ein gutes Beispiel hierfuer ist z.B. der Kriegshamster ein Hamster, der
+  auf einem Holzstab aufgespiesst ist, sollte fuer den Gegner schon SEHR
+  irritierend sein ;).
+  Die Waffengattung hat nur wenig Einfluss auf Finte/Waffentrick.
+
+  Der max. Bonus fuer diese Property betraegt 50, wobei 1-10 -> geringer
+  Bonus, 11-30 -> guter Bonus, 31-50 -> sehr guter Bonus.
+
+
+6 Todesstossbonus - K_CRITICAL_HIT (INT) - "k_critical_hit"
+
+  Man stelle sich eine Waffe mit besonders spitzer, langer Klinge vor oder
+  eine magische Waffe, die dem geschwaechten Gegner die Seele entreisst.
+  Diese Eigenschaften verleihen dem Spieler beim Todesstoss einen
+  entsprechenden Bonus von bis zu 100%.
+
+  Es ist moeglich, dass ein und dasselbe 'feature' sowohl dem Waffenschlag
+  als auch dem Todesstoss den Bonus stellt, z.B. zwei Hiebklingen auf dem
+  Klingenruecken einer grossen Axt. Auch dies sollte man deutlich aus der
+  Langbeschreibung herauslesen koennen.
+
+  Der max. Bonus fuer diese Property betraegt 100, wobei 100 eine Verdopplung
+  der P_WC beim Todesstoss bedeutet!
+  Ansonsten bedeutet 1-20 -> geringer Bonus, 21-60 -> guter Bonus,
+  61-100 -> sehr guter Bonus.
+
+
+7 Waffenwurfbonus - K_THROWING_WEAPON (INT) - "k_throwing_weapon"
+
+  Wenn eine Waffe besonders gut zum Werfen geeignet ist, z.B. ein Wurfdolch,
+  dann kann diese Property gesetzt werden. Natuerlich ist der Grundwert wieder
+  von der Waffengattung abhaengig. Es gilt, dass man Messer und Speere
+  grundsaetzlich am besten werfen - und dabei gut Schaden machen - kann, am
+  schlechtesten schneiden Keulen und Kampfstaebe ab.
+
+  Der max. Bonus fuer diese Property betraegt 50, wobei 1-20 -> geringer
+  Bonus, 21-40 -> guter Bonus, 31-50 -> sehr guter Bonus.
+
+  Zu beachten ist hierbei, dass ein sehr hoher Bonus nur bei Waffen mit etwas
+  geringerer P_WC vergeben werden sollte. Ein reines Wurfmesser ist nunmal im
+  normalen Kampf nicht die gefaehrlichste aller Waffen (speziell
+  ausbalanciert, keinen richtigen Griff, etc.).
+  Natuerlich kann es einen Wurfspeer mit max. P_WC und sehr hohem
+  Waffenwurfbonus geben, allerdings mit den ueblich hohen Restriktionen.
+
+
+8 KO-Schlag-Bonus - K_KO (INT) - "k_ko"
+
+  Waffen, die besonders fuer einen KO-Schlag geeignet sind, koennen einen
+  Bonus mit dieser Property bekommen. Eine entsprechende Waffe koennte z.B.
+  ein lederumwickelter Pruegel sein, denn man will den Gegner ja nur KO
+  schlagen und nicht gleich toeten.
+
+  Der max. Bonus fuer diese Property betraegt 50, wobei 1-20 -> geringer
+  Bonus, 21-30 -> guter Bonus, 31-50 -> sehr guter Bonus.
+
+
+9 Kein Waffenschaerfen - K_NO_HONING (INT) - "k_no_honing"
+
+  Wenn eine Waffe aus irgendeinem Grund nicht geschaerft werden kann oder
+  darf, muss man diese Property auf 1 setzen.
+  Eine Erklaerung dafuer sollte in der P_LONG bzw. P_INFO erfolgen.
+
+
+Abschnitt B
+
+
+Die beiden Properties, P_EFFECTIVE_AC und P_EFFECTIVE_WC, welche in
+<combat.h> definiert sind, sind eigentlich nur dazu da, um Ruestungen und
+Waffen, die eine DefendFunc() bzw. HitFunc() besitzen, korrekt vom Spieler
+einschaetzen lassen zu koennnen.
+
+Das Kaempferspellbook verwendet diese Properties darueberhinaus wie folgt
+
+
+1 Schutzboni in Waffen - P_EFFECTIVE_AC (INT) - "effective_ac"
+
+  Ist diese Property in einer Waffe gesetzt, geht das Kaempferspellbook
+  davon aus, dass diese Waffe mehr oder weniger die Faehigkeit besitzt,
+  auch wie eine Ruestung schuetzen zu koennen. Da man eine Waffe aber nicht
+  anziehen, sondern nur vor sich hertragen kann, kann auch der max.
+  Ruestungsschutz einer Waffe nur gleich dem max. Ruestungsschutz eines
+  Schildes entsprechen.
+  Eine gesetzte P_EFFECTIVE_AC in einer Waffe wird dem Spieler als mehr
+  oder weniger gute 'Paradewaffe' im 'schaetz' angezeigt und geht sowohl bei
+  der Waffenparade als auch beim Block als Bonus mit ein.
+
+  Z.B. koennte ein leichtes Schwert, was aufgrund seiner Bauweise mehr fuer
+  den defensiven Kampf ausgelegt ist (extralange Parierstangen, verstaerkter
+  Handschutz im Griffbereich, ...) wie ein maessiges Schild wirken. Die
+  Vorteile liegen auf der Hand der Spieler bekommt verstaerkten Schutz,
+  kann aber weiterhin eine Zweihandwaffe fuehren.
+
+  Der max. Bonus fuer diese Property betraegt 40, wobei 1-20 -> geringer
+  Bonus, 21-30 -> guter Bonus, 31-40 -> sehr guter Bonus.
+
+  Zu beachten ist hier, dass sehr gute Parierwaffen mit P_EFFECTIVE_AC > 30
+  moeglichst deutlich unter der max. WC liegen sollten.
+
+  Anmerkungen
+  Eine gesetzte P_EFFECTIVE_AC in einem Schild kann den Bonus fuer die
+  Schildparade nach oben oder unten beeinflussen. Moechte man ein Schild
+  herstellen, welches speziell bei der Schildparade der Kaempfer besser
+  als 'normal' schuetzt, sollte man hier einen Wert eintragen, der deutlich
+  groesser als die P_AC des Schildes ist.
+
+  Eine gesetzte P_EFFECTIVE_AC in einer anderen Ruestung hat nur den Nutzen,
+  auf deren erhoehten (und nicht sofort sichtbaren) Verteidigungswert
+  hinzuweisen, der durch eine DefendFunc() realisiert wird.
+
+
+2 Angriffsboni in Ruestungen - P_EFFECTIVE_WC (INT) - "effective_wc"
+
+  Fuer die Kaempfer koennen folgende Ruestungstypen modifiziert werden
+  AT_TROUSERS (Hosen), AT_HELMET (Kopfbedeckung), AT_BOOT (Fusskleidung),
+  AT_ARMOUR (Koerperruestung), AT_SHIELD (Schilde).
+  Ist in einer dieser Typen P_EFFECTIVE_WC gesetzt, so macht diese Ruestung
+  bei einem Angriff mit einer Spezialattacke (Kniestoss, Kopfstoss, Fusstritt,
+  Ellbogenschlag und Schildstoss) entsprechend mehr bzw. weniger Schaden als
+  ohne diese Property. Eine entsprechende Begruendung fuer eine Verstaerkung
+  oder Schwaechung sollte auch hier fuer den Spieler offensichtlich sein
+  (Dornen am Schild, verstaerkter Kniebereich, Zacken am Helm, etc.).
+
+  Wenn man der Ruestung einen Bonus geben moechte, muss man darauf achten,
+  dass P_EFFECTIVE_WC hoeher ist als die P_AC der Ruestung! Sollte
+  P_EFFECTIVE_WC niedriger als P_AC sein, wird dennoch P_EFFECTIVE_WC als
+  Angriffswert genommen. Dies stellt natuerlich eine Schwaechung der
+  Spezialattacke dar. Moeglicherweise ist aber genau das gewollt, wenn eine
+  Ruestung, die sehr gut schuetzt, nur geringen Kaempferbonus aufweisen soll.
+
+  Beispiel ein Schild aus Hartgummi kann recht gut Schlaege aller Art
+  abfangen (-> P_AC 35). Will der Kaempfer jedoch einen Schildstoss damit
+  machen, fehlt ihm aufgrund der Beschaffenheit die Wucht, eher daempft es
+  den Schildstoss noch ein wenig (-> P_EFFECTIVE_WC 25).
+
+  Der Maximalwert fuer die P_EFFECTIVE_WC bei Kaempfern ist der jeweils
+  doppelte maximale P_AC-Wert (s. 'man ruestungen').
+
+  Die Angabe eines Schadenstyps (P_DAM_TYPE) in einer Ruestung kann dann
+  sinnvoll sein, wenn bei der Spezialattacke ein spezieller Schaden gemacht
+  werden soll. Beispielsweise sollten Flammenstiefel logischerweise DT_FIRE
+  und DT_BLUDGEON oder DT_PIERCE bei einem Kampftritt verursachen. Es MUSS
+  (logischerweise) mindestens ein physikalischer Schadenstyp enthalten sein.
+  Wird kein Schadenstyp angegeben, wird auf Standardtypen zurueckgegriffen.
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+::
+
+SIEHE AUCH
+----------
+::
+
+     Waffen:     P_WC, P_TOTAL_WC, P_EFFECTIVE_WC, HitFunc()
+     Ruestungen: P_AC, P_TOTAL_AC, P_EFFECTIVE_AC, DefendFunc()
+     Files:      /std/weapon.c, /std/weapon/combat.c
+     Balance:    waffen, ruestungen, properties
+
+
+26.10.2012, Gabylon
+
diff --git a/doc/sphinx/props/obsolete/P_BALANCED_WEAPON.rst b/doc/sphinx/props/obsolete/P_BALANCED_WEAPON.rst
new file mode 100644
index 0000000..f982030
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_BALANCED_WEAPON.rst
@@ -0,0 +1,58 @@
+P_BALANCED_WEAPON
+=================
+
+********************* UNGENUTZTE PROPERTY *****************************
+* Diese Property wird von der Mudlib NICHT ausgewertet und kann       *
+* als veraltet gelten.                                                *
+* Momentan ist auch keine Gilde bekannt, die mehr macht, als sie      *
+* auszugeben.                                                         *
+***********************************************************************
+
+NAME
+----
+::
+
+        P_BALANCED_WEAPON  "balanced_weapon"
+
+DEFINIERT IN
+------------
+::
+
+        /sys/weapon.h
+
+BESCHREIBUNG
+------------
+::
+
+        Die Property gibt an, ob eine Waffe ausbalanciert ist oder nicht.
+        Die beiden moeglichen Werte sind logischerweise:
+
+                WP_BALANCED       balanciert
+                WP_UNBALANCED     unbalanciert
+
+        Die WP_* sind ebenfalls in <weapon.h> definiert.
+
+BEISPIELE
+---------
+::
+
+        a) Eine ausbalancierte Waffe ist z.B. ein Kampfstab.
+
+            SetProp(P_BALANCED_WEAPON,WP_BALANCED);
+
+        b) Eine nicht ausbalancierte Waffe ist z.B. eine Keule.
+
+            SetProp(P_BALANCED_WEAPON,WP_UNBALANCED);
+
+SIEHE AUCH
+----------
+::
+
+        P_TECHNIQUE, /std/weapon/combat.c
+
+LETZTE AeNDERUNG
+----------------
+::
+
+15.02.2009, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_DEFAULT_INFO.rst b/doc/sphinx/props/obsolete/P_DEFAULT_INFO.rst
new file mode 100644
index 0000000..4b553c9
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_DEFAULT_INFO.rst
@@ -0,0 +1,50 @@
+P_DEFAULT_INFO
+==============
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+
+NAME
+----
+::
+
+    P_DEFAULT_INFO                "default_info"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Default-Antwort eines Npc, wenn er auf das Schluesselwort durch den
+    Spieler kein AddInfo parat hat.
+
+BEMERKUNG
+---------
+::
+
+    Diese Property sollte nicht mehr benutzt werden. Stattdessen bitte
+    AddInfo(DEFAULT_INFO,...) verwenden.
+    Dem in dieser Prop angegeben String wird immer der Name des Npc
+    vorausgestellt. Will man dies verhindern, muss man sie ueberschreiben.
+
+BEISPIEL
+--------
+::
+
+    SetProp(P_DEFAULT_INFO,"bohrt gelangweilt in der Nase.\n");
+
+SIEHE AUCH
+----------
+::
+
+    AddInfo
+
+
+17.08.2010, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_EXTRA_LOOK.rst b/doc/sphinx/props/obsolete/P_EXTRA_LOOK.rst
new file mode 100644
index 0000000..4a649a0
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_EXTRA_LOOK.rst
@@ -0,0 +1,57 @@
+P_EXTRA_LOOK
+============
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte benutzt sie NICHT mehr, sondern  *
+* stattdessden AddExtraLook().                                        *
+***********************************************************************
+
+NAME
+----
+::
+
+	P_EXTRA_LOOK			"extralook"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/living/description.h
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property enthaelt einen String. Sie wird entweder in Lebewesen
+	direkt oder in Objekten gesetzt wird, die im Besitz von Lebewesen
+	sein koennen.
+	Diese Strings erscheinen dann zusaetzlich in der Langbeschreibung
+	des Lebewesens bzw. des Besitzers (wenn das Objekt sich direkt im
+	 Lebewesen befindet, jedoch nicht in einem Behaelter im Lebewesen).
+	Fuer den Zeilenumbruch muss man selbst sorgen.
+
+BEISPIEL
+--------
+::
+
+	Ein Spieler hat eine Pfeife im Mund. In dieser Pfeife setzt man z.B.
+	in der Funktion zum Pfeife Rauchen folgendes:
+	  SetProp(P_EXTRA_LOOK,break_string(
+	 this_player()->Name(WER)+" ist ganz umnebelt.",78);
+
+BEMERKUNG
+---------
+::
+
+  BITTE NICHT MEHR BENUTZEN!
+
+SIEHE AUCH
+----------
+::
+
+	long(), /std/living/description.c, /std/player/base.c
+  AddExtraLook(), RemoveExtraLook()
+
+
+13.05.2007, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_LAST_KILLER.rst b/doc/sphinx/props/obsolete/P_LAST_KILLER.rst
new file mode 100644
index 0000000..1485e96
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_LAST_KILLER.rst
@@ -0,0 +1,36 @@
+P_LAST_KILLER
+=============
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet und wird bald aus der Mudlib entfernt.  *
+***********************************************************************
+
+NAME
+----
+::
+
+    P_LAST_KILLER                 "last_killer"                 
+
+DEFINIERT IN
+------------
+::
+
+    /sys/player.h
+
+BESCHREIBUNG
+------------
+::
+
+     Letzter Moerdes des Wesens.
+     Diese Property wurde nur in Spielern gesetzt und auch dann nicht immer.
+     Bitte stattdessen P_KILLER abfragen, welche in NPC und Spielern gesetzt
+     wird.
+
+SIEHE AUCH
+----------
+::
+
+    P_KILLER, die()
+
+05.09.2008, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_LAST_PEACE_TIME.rst b/doc/sphinx/props/obsolete/P_LAST_PEACE_TIME.rst
new file mode 100644
index 0000000..06195f4
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_LAST_PEACE_TIME.rst
@@ -0,0 +1,42 @@
+P_LAST_PEACE_TIME
+=================
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet und wird bald aus der Mudlib entfernt.  *
+***********************************************************************
+
+PROPERTY
+--------
+::
+
+	P_LAST_PEACE_TIME	"last_peace_time"
+
+DEFINIERT IN
+------------
+::
+
+	/std/living/combat.c
+
+BESCHREIBUNG
+------------
+::
+
+	Diese Property gibt an, wann zuletzt versucht wurde, einen NPC zu
+	befrieden. Bitte nach Moeglichkeit nur lesend verwenden. Des weiteren
+	wird sie nur im ueblichen Verhalten von QueryPacify gesetzt, und nur
+	dann, wenn P_ACCEPT_PEACE nicht gesetzt ist.
+
+SIEHE AUCH
+----------
+::
+
+	QueryPacify, P_ACCEPT_PEACE
+
+LETZTE AENDERUNG
+----------------
+::
+
+	2004-03-17, 14:30 von Humni
+
+	
+
diff --git a/doc/sphinx/props/obsolete/P_LOG_FILE.rst b/doc/sphinx/props/obsolete/P_LOG_FILE.rst
new file mode 100644
index 0000000..34cf3d7
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_LOG_FILE.rst
@@ -0,0 +1,68 @@
+P_LOG_FILE
+==========
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property wird nicht mehr ausgewertet.                         *
+***********************************************************************
+
+NAME
+----
+::
+
+    P_LOG_FILE                   "log_file"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/thing/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Enthaelt einen String auf einen Filenamen. 
+
+    Werden zu dem Objekt (Raum, Monster, ...) Fehlermeldungen abgesetzt, 
+    werden diese in das angegebene File umgeleitet. Die Eintragung in
+    die per Default fuer Fehlermeldungen vorgesehenen Dateien erfolgt
+    nicht.
+
+BEMERKUNGEN
+-----------
+::
+
+    P_LOG_FILE wird ausgewertet wie log_file().
+
+    Das heisst, es wird AUF JEDEN FALL nach /log geschrieben!
+
+    Direkt in /log kann NICHT geschrieben werden, es muss also ein 
+    Unterverzeichnis mit Eurem Magiernamen vorhanden sein.
+
+BEISPIELE
+---------
+::
+
+    SetProp(P_LOG_FILE,"tilly_log");          // FALSCH, es wuerde versucht, 
+                                                 das File /log/tilly_log 
+                                                 anzulegen
+    SetProp(P_LOG_FILE,"/log/tilly_log");     // FALSCH, es wuerde versucht, 
+                                                 das File /log/log/tilly_log
+                                                 anzulegen
+    SetProp(P_LOG_FILE,"/d/ebene/tilly_log"); // FALSCH, s.o.
+
+    SetProp(P_LOG_FILE,"tilly/tilly_log");    // RICHTIG!
+
+    Im letzten Beispiel werden alle Eintraege in das File tilly_log ge-
+    schrieben, das sich im Verzeichnis /log/tilly/ befindet.
+
+    Das Unterverzeichnis /tilly in /log muss zuvor angelegt werden.
+
+SIEHE AUCH
+----------
+::
+
+    P_LOG_INFO, write_file(), log_file(),
+
+Letzte Aenderung: 13.09.04 Tilly@MorgenGrauen
+
diff --git a/doc/sphinx/props/obsolete/P_NEXT_SPELL_TIME.rst b/doc/sphinx/props/obsolete/P_NEXT_SPELL_TIME.rst
new file mode 100644
index 0000000..d61643f
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_NEXT_SPELL_TIME.rst
@@ -0,0 +1,48 @@
+P_NEXT_SPELL_TIME
+=================
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+
+NAME
+----
+::
+
+    P_NEXT_SPELL_TIME             "next_spell"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+    Wann kann das naechste Mal gezaubert werden?
+    Dies ist eine globale Spruchermuedung/-Sperre.
+    Flexiblere Sperren koennen mittels SetSpellFatigue/CheckSpellFatigue()
+    verwaltet werden.
+
+    Diese Property ist keine echte Property, sondern liefert nur das
+    Ergebnis von von CheckSpellFatigue() zurueck bzw. ruft beim Setzen
+    SetSpellFatigue(<spruchsperre>, 0) auf.
+    Diese Prop sollte _nicht_ mittels Query- oder Setmethoden manupuliert
+    werden, da sonst Inkonsistenzen zum Ergebnis von CheckSpellFatigue()
+    auftreten.
+
+SIEHE AUCH
+----------
+::
+
+    SetSpellFatigue(L), CheckSpellFatigue(L)
+    spruchermuedung
+
+ZULETZT GEAeNDERT
+-----------------
+::
+
+14.03.2010, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_READ_MSG.rst b/doc/sphinx/props/obsolete/P_READ_MSG.rst
new file mode 100644
index 0000000..c1fcfca
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_READ_MSG.rst
@@ -0,0 +1,57 @@
+P_READ_MSG
+==========
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+
+NAME
+----
+::
+
+    P_READ_MSG                "read_msg"                
+
+DEFINIERT IN
+------------
+::
+
+    /sys/properties.h
+
+BESCHREIBUNG
+------------
+::
+
+    Diese Property ist veraltet. Ihre Funktion wird von
+    AddReadDetail(SENSE_DEFAULT, ...) uebernommen.
+
+    
+
+    Hier koennen Informationen gespeichert werden, die beim Lesen
+    des Objektes ausgegeben werden.
+
+     
+
+    Fuer das Identifizieren des zu lesenden Objektes wird der gleiche
+    Mechanismus benutzt wie fuer lesbare und andere Details.
+
+    Die Benutzung von process_string() ist in dieser Prop nicht mehr erlaubt.
+
+BEISPIEL
+--------
+::
+
+    AddId(({"rolle", "schriftrolle"}));
+    SetProp(P_READ_MSG,
+       "Du oeffnest die Rolle und liest: LOREM IPSUM ...\n");
+
+     
+
+SIEHE AUCH
+----------
+::
+
+    Details:   AddReadDetail(), RemoveReadDetail(), P_READ_DETAILS
+    Sonstiges: break_string()
+
+09.12.2012, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_TECHNIQUE.rst b/doc/sphinx/props/obsolete/P_TECHNIQUE.rst
new file mode 100644
index 0000000..ec42c36
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_TECHNIQUE.rst
@@ -0,0 +1,69 @@
+P_TECHNIQUE
+===========
+
+********************* UNGENUTZTE PROPERTY *****************************
+* Diese Property wird von der Mudlib NICHT ausgewertet und kann       *
+* als veraltet gelten.                                                *
+* Momentan ist auch keine Gilde bekannt, die mehr macht, als sie      *
+* auszugeben.                                                         *
+***********************************************************************
+
+NAME
+----
+::
+
+	P_TECHNIQUE				"technique"
+
+DEFINIERT IN
+------------
+::
+
+	/sys/weapon.h
+
+BESCHREIBUNG
+------------
+::
+
+        Die Technik(en), mit denen eine Waffe im Kampf eingesetzt werden
+        kann. Folgende Techniken stehen zur Verfuegung:
+
+                TQ_STROKE       Streichtechnik
+                TQ_THRASH       Schlagtechnik
+                TQ_THRUST       Stosstechnik
+                TQ_WHIP         Peitschtechnik
+
+        Die Techniken sind ebenfalls in <weapon.h> definiert und auf der
+        man-page 'techniken' naeher erlaeutert.
+
+BEMERKUNGEN
+-----------
+::
+
+        Man kann einer Waffe eine oder mehrere Techniken zuweisen.
+
+BEISPIELE
+---------
+::
+
+        a) Eine Waffe, die nur mit einer Peitschtechnik eingesetzt wird,
+           also typischerweise eine Peitsche, aber auch ein Morgenstern:
+
+            SetProp(P_TECHNIQUE,TQ_WHIP);
+
+        b) Eine Waffe, die sowohl mit der Schlag- als auch der Stosstechnik
+           eingesetzt wird, also z.B. eine Hellebarde:
+
+            SetProp(P_TECHNIQUE,({TQ_THRASH,TQ_THRUST}));
+
+SIEHE AUCH
+----------
+::
+
+        techniken, P_BALANCED_WEAPON, /std/weapon/combat.c
+
+LETZTE AeNDERUNG
+----------------
+::
+
+15.02.2009, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_TMP_ATTACK_HOOK.rst b/doc/sphinx/props/obsolete/P_TMP_ATTACK_HOOK.rst
new file mode 100644
index 0000000..4b57f96
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_TMP_ATTACK_HOOK.rst
@@ -0,0 +1,95 @@
+P_TMP_ATTACK_HOOK
+=================
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+P_TMP_ATTACK_HOOK
+
+NAME
+----
+::
+
+    P_TMP_ATTACK_HOOK             "attack_hook"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mittels dieser Property koennen die Attacken eines Livings ggf.
+     abgebrochen werden noch bevor Waffen oder Skills zum ausgewertet
+     wurden.
+
+     Es wird an dem Living die Property als mindestens 3-elementiges Array:
+     ({zeitpunkt, objekt, methode, ...})
+     gesetzt und die Methode 'methode' wird dann waehrend des Attack() des
+     Lebewesens in 'objekt' aufgerufen, solange time()<'zeitpunkt'.
+
+     Der Methode wird als Parameter der Gegner uebergeben.
+
+     Gibt die Methode 0 als Rueckgabewert zurueck, wird die Attacke sofort
+     kommentarlos abgebrochen.
+
+BEMERKUNGEN
+-----------
+::
+
+     - Bitte das neuere Hooksystem (s. Manpage std/hooks) benutzen.
+     - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
+       Property auf 0 gesetzt
+     - vor dem Setzen immer auf die Existenz eines gueltigen Hooks
+       pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
+       im Code anderer und ist andererseits unfair gegenueber ihnen
+
+BEISPIELE
+---------
+::
+
+     *** der Spieler erhaelt eine Verwundung, die ihn manchmal behindert ***
+     if(!pointerp(tmp=TP->QueryProp(P_TMP_ATTACK_HOOK)) ||
+        sizeof(tmp)<3 || tmp[0]<=time()) {
+       TP->SetProp(P_TMP_ATTACK_HOOK,
+		   ({time()+3600, this_object(), "test_hurt"}));
+     ...
+
+     // die entsprechende Methode, die bei jedem Angriff ueber Attack()
+     // gerufen wird ...
+     int test_hurt(object enemy) {
+
+       // mit 10% Chance generell und 20% Chance bei groesseren Gegnern
+       // bricht der Angriff ab ... previous_object() ist natuerlich
+       // der Angreifer
+       if(!random(10) ||
+          (enemy->QueryProp(P_SIZE)>previous_object()->QueryProp(P_SIZE) &&
+           !random(5)) {
+
+          tell_object(previous_object(),
+            "Deine Wunde schmerzt dich zu sehr um anzugreifen.\n");
+          tell_room(environment(previous_object()),
+            previous_object()->Name(WER,1)+" zuckt vor Schmerzen zusammen.\n",
+            ({previous_object()}));
+          return 0;
+       }
+
+       // ansonsten geht der Angriff weiter
+       return 1;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Angriff:	Attack(L)
+     Schutz:    Defend(L)
+     Verwandt:  InternalModifyAttack(L), P_TMP_ATTACK_MOD	
+     Hooks:	P_TMP_DIE_HOOK, P_TMP_MOVE_HOOK, P_TMP_DEFEND_HOOK
+     neue Hooks: std/hooks
+
+08.12.2008, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_TMP_ATTACK_MOD.rst b/doc/sphinx/props/obsolete/P_TMP_ATTACK_MOD.rst
new file mode 100644
index 0000000..8a1f138
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_TMP_ATTACK_MOD.rst
@@ -0,0 +1,134 @@
+P_TMP_ATTACK_MOD
+================
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+P_TMP_ATTACK_MOD
+
+NAME
+----
+::
+
+     P_TMP_ATTACK_MOD              "attack_mod"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mittels dieser Property koennen die Attacken eines Livings temporaer
+     veraendert werden.
+
+     Es wird an dem Living die Property als mindestens 3-elementiges Array
+     ({zeitpunkt, objekt, methode, ...})
+     gesetzt und die Methode 'methode' wird dann waehrend des Attack() des
+     Lebewesens in 'objekt' aufgerufen, solange time()<'zeitpunkt'.
+
+     Der Methode wird beim Aufruf ein Kopie des Mappings uebergeben, in dem
+     die bisherigen Werte des Angriffes vermerkt sind.
+     Aufbau von Mapping 'ainfo':
+     ([ SI_ENEMY :           object Angreifer,			(-> Defend)
+        SI_SPELL :           0/1/array Spellparameter,		(-> Defend)
+        P_WEAPON :           - oder Waffe,
+        SI_SKILLDAMAGE_MSG:  string Angriffsmeldungsende an Raum,
+        SI_SKILLDAMAGE_MSG2: string Angriffsmeldungsende an Kaempfende,
+        SI_SKILLDAMAGE:      int Schaden in Zehntel HP (Skills bis auf Rasse
+			     drin!)				(-> Defend),
+        SI_SKILLDAMAGE_TYPE: string/string* Schadenstypen,	(-> Defend)
+        P_WEAPON_TYPE:       string Waffentyp (combat.h),
+        P_WC:		     - oder int WC der Waffe/Hand,
+        P_NR_HANDS:	     - oder int Hands der Waffe/Hand,
+     ]);
+
+     Gibt die Methode:
+     - 0 oder kein Mapping zurueck, fuehrt das zum Abbruch der Attacke
+       -> da inzwischen Waffen abgefragt wurden, koennen schon Meldungen
+          von diesen ausgegeben worden sein
+     - ein leeres Mapping ( ([]) ) zurueck, fuehrt das zu keiner Modifikation
+     - ein Mapping mit veraenderten Werten zurueck, werden diese in das
+       Angriffsmapping kopiert
+       Die geaenderten Werte werden teilweise von SkillResTransfer() in
+       den eigentlichen Angriff uebernommen.
+
+BEMERKUNGEN
+-----------
+::
+
+     - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
+       Property auf 0 gesetzt
+     - vor dem Setzen immer auf die Existenz eines gueltigen Modifiers
+       pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
+       im Code anderer und ist andererseits unfair gegenueber ihnen
+
+BEISPIELE
+---------
+::
+
+     *** ein besonder heisser Segen modifiziert die Attacken des Spielers ***
+     int action_segen() {
+       ...
+       mixed *tmp;
+
+       // pruefen, ob nicht ein anderer Modifier existiert
+       if(!pointerp(tmp=TP->QueryProp(P_TMP_ATTACK_MOD)) ||
+          sizeof(tmp)<3 || tmp[0]<=time()) {
+
+         object wield;
+         wield=TP->QueryProp(P_WEAPON);
+
+         write(break_string(
+           "Der Priester der Flamme weiht "+
+           (wield?wield->name(WEN,1):"deine Haende")+".", 78));
+
+         // setzen des Modifiers .. 30-40 Sekunden gueltig
+         TP->SetProp(P_TMP_ATTACK_MOD,
+	              ({time()+30+random(10), this_object(), "modfun"}));
+        } else ...
+        ...
+      return 1;
+     }
+
+     // die eigentlich Methode, die waehrend des Angriffs gerufen wird
+     mapping modfun(mapping ainfo) {
+       mapping ret;
+
+       // Returnwert ist immer ein Mapping, damit die Attacke weitergeht
+       ret=m_allocate(0,1);
+
+       // magische Waffen oder Sprueche werden nicht verbessert
+       if(ainfo[P_WEAPON_TYPE]!=WT_MAGIC) {
+         // sonst Verbesserungen ... Feuer addieren ...
+         ret[SI_SKILLDAMAGE_TYPE]=(ainfo[SI_SKILLDAMAGE_TYPE]||({}))+
+				({DT_FIRE});
+	 // ... und bei Waffe Meldungen anpassen
+         if(ainfo[P_WEAPON]) {
+           ret[SI_SKILLDAMAGE_MSG]=
+             " mit sengendem "+ainfo[P_WEAPON]->name(RAW);
+           ret[SI_SKILLDAMAGE_MSG2]=
+             " mit sengendem "+ainfo[P_WEAPON]->name(RAW);
+         }
+       }
+
+       return ret;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Angriff:	Attack(L)
+     Schutz:    Defend(L)
+     Verwandt:  InternalModifyAttack(L)
+		P_TMP_ATTACK_HOOK
+		P_TMP_DEFEND_HOOK
+     Sonstiges: SkillResTransfer(L)
+     Hooks:	P_TMP_DIE_HOOK, P_TMP_MOVE_HOOK
+
+10.Feb 2005 Gloinson
+
diff --git a/doc/sphinx/props/obsolete/P_TMP_DEFEND_HOOK.rst b/doc/sphinx/props/obsolete/P_TMP_DEFEND_HOOK.rst
new file mode 100644
index 0000000..5d9ae39
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_TMP_DEFEND_HOOK.rst
@@ -0,0 +1,131 @@
+P_TMP_DEFEND_HOOK
+=================
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+P_TMP_DEFEND_HOOK
+
+NAME
+----
+::
+
+     P_TMP_DEFEND_HOOK             "defend_hook"
+
+DEFINIERT IN
+------------
+::
+
+     /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mittels dieser Property koennen die Abwehren eines Livings temporaer
+     veraendert werden.
+
+     Es wird an dem Living die Property als mindestens 3-elementiges Array
+     ({zeitpunkt, objekt, methode, ...})
+     gesetzt und die Methode 'methode' wird dann waehrend des Defend() des
+     Lebewesens in 'objekt' aufgerufen, solange time()<'zeitpunkt'.
+
+     Der Methode werden die Parameter der Defend() uebergeben:
+     int dam, mixed dam_type, mixed spell, object enemy
+     - spell ist definitiv ein Mapping - ein an Defend() uebergebener
+       int-Wert wurde aequivalent umgesetzt.
+     - dam_type ist definitiv ein Array von Schadenswerten oder einem Wert
+
+     Zudem findet der Aufruf der Methode nach dem Abarbeiten der P_DEFENDERS
+     statt, diese koennen also weitere Modifikationen vorgenommen haben.
+
+     Gibt die Funktion:
+     - 0 zurueck, wird Defend() abgebrochen (und damit der Schaden voellig
+       abgefangen) - nur noch die Flucht wird geprueft
+     - ein 3-elementiges Array ({schaden, schadenstypen, spell}) zurueck,
+       werden diese Werte in der Defend() an Stelle der uebergebenen Werte
+       verwendet
+     - weder noch zurueck, wird das Ergebnis ignoriert und die Defend laeuft
+       regulaer weiter
+
+BEMERKUNGEN
+-----------
+::
+
+     - Bitte das neuere Hooksystem (s. Manpage std/hooks) benutzen.
+     - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
+       Property auf 0 gesetzt
+     - vor dem Setzen immer auf die Existenz eines gueltigen Hooks
+       pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
+       im Code anderer und ist andererseits unfair gegenueber ihnen
+
+BEISPIEL
+--------
+::
+
+     *** ein gruener Schutzzauber ***
+     // Setzen der Prop
+     ...
+     tmp=TP->QueryProp(P_TMP_DEFEND_HOOK);
+
+     // ein etwas ausfuehrlicher Check, ob wir ueberschreiben koennen,
+     // Existenz && Gueltigkeit
+     if(pointerp(tmp) && sizeof(tmp) && intp(tmp[0]) && (time()<tmp[0]))
+      write("Der Zauber klappt nicht!\n");
+     else {
+      // der Zauber gilt eine Stunde
+      TP->SetProp(P_TMP_DEFEND_HOOK,({time()+3600,TO,"abwehrfun");
+      write("Ein Zauber legt sich auf dich.\n");
+     }
+     ...
+
+     // die gerufene Methode
+     mixed abwehrfun(int dam, string* dam_type, mapping spell, object en) {
+      // keine rekursiven Schaeden abfangen ... mindestens ein magischer
+      // muss auch dabei sein
+      if((!mappingp(spell) || !spell[SP_RECURSIVE]) &&
+         sizeof(filter(dam_type,MAGICAL_DAMAGE_TYPES))) {
+
+       // mit 10% Whkeit schuetzt der Zauber total
+       if(!random(10)) {
+        tell_object(previous_object(),
+          "Dein Zauber gleisst rund um dich gruen auf.\n");
+        tell_room(environment(previous_object()), break_string(
+          previous_object()->Name(WESSEN)+" Haut gleisst rund um "+
+          previous_object()->QueryPronoun(WEN)+" gruen auf.",78),
+          ({previous_object()}));
+
+        // manchmal geht der Zauber dabei endgueltig kaputt
+        if(!random(10)) previous_object()->SetProp(P_TMP_DEFEND_HOOK, 0);
+
+        return 0;			// volles Abfangen des Angriffs
+       }
+
+       // der Zauber schuetzt auf jeden Fall immer ein bischen
+       tell_object(previous_object(),
+         "Dein Zauber flackert rund um dich gruen auf.\n");
+       tell_room(environment(previous_object()), break_string(
+         previous_object()->Name(WESSEN)+" Haut flackert rund um "+
+         previous_object()->QueryPronoun(WEN)+" gruen auf.",78),
+         ({previous_object()}));
+       dam=(7+random(2))*dam/10;	// Schaden reduzieren
+
+       return(({dam, dam_type, spell}));
+      }
+
+      // der Zauber schuetzt dann gar nicht ...
+      return 1;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Angriff:	Attack(L)
+     Schutz:    Defend(L)
+     Verwandt:	InternalModifyDefend(L), P_TMP_ATTACK_MOD
+     Hooks:	P_TMP_DIE_HOOK, P_TMP_MOVE_HOOK, P_TMP_ATTACK_HOOK
+     neue Hooks: std/hooks
+
+08.12.2008, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_TMP_DIE_HOOK.rst b/doc/sphinx/props/obsolete/P_TMP_DIE_HOOK.rst
new file mode 100644
index 0000000..616da96
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_TMP_DIE_HOOK.rst
@@ -0,0 +1,91 @@
+P_TMP_DIE_HOOK
+==============
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+P_TMP_DIE_HOOK
+
+NAME
+----
+::
+
+    P_TMP_DIE_HOOK                "die_hook"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+     Mittels dieser Property kann der Tod eines Livings abgewendet werden.
+
+     Es wird an dem Living die Property als mindestens 3-elementiges Array
+     ({zeitpunkt, objekt, methode, ...})
+     gesetzt und die Methode 'methode' wird dann waehrend des die() des
+     Lebewesens in 'objekt' aufgerufen, solange time()<'zeitpunkt'.
+     Bei Geistern wird der Hook nicht gerufen.
+
+     Der Methode wird ein int uebergeben, ob das Living Opfer von Gift
+     (P_POISON) war.
+
+     Gibt die Funktion einen Wert != 0 zurueck, wird die() sofort abgebrochen
+     und das Living stirbt nicht.
+
+BEMERKUNGEN
+-----------
+::
+
+    - Bitte das neuere Hooksystem (s. Manpage std/hooks) benutzen.
+    - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
+      Property auf 0 gesetzt
+    - vor dem Setzen immer auf die Existenz eines gueltigen Hooks
+      pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
+      im Code anderer und ist andererseits unfair gegenueber ihnen
+
+BEISPIELE
+---------
+::
+
+     *** ein besonderer Giftschutz .. wirkt beim Tod ***
+     // pruefen, ob nicht ein anderer Modifier existiert
+     if(!pointerp(tmp=TP->QueryProp(P_TMP_DIE_HOOK)) ||
+        sizeof(tmp)<3 || tmp[0]<=time()) {
+       TP->SetProp(P_TMP_DIE_HOOK,
+	           ({time()+120+random(10), this_object(), "prevent_die"}));
+
+     // die gerufene Methode
+     int prevent_die(int poison) {
+       int ret;
+
+       if(poison) {
+         tell_object(previous_object(),
+           "Ein Zauber reinigt im Moment des Todes dein Blut!\n");
+         tell_object(environment(previous_object()),
+           previous_object()->Name(WER,1)+" wird von Lichtern umhuellt.\n",
+           ({previous_object()}));
+
+         ret=1;
+       }
+
+       // wir helfen nur einmal ... und ein Tod vernichtet die Hilfe auch
+       previous_object()->SetProp(P_TMP_DIE_HOOK, 0);
+
+       return ret;
+     }
+
+SIEHE AUCH
+----------
+::
+
+     Tod:	die(L)
+     Sonstiges: P_POISON, P_KILLS, P_GHOST
+     Hooks:	P_TMP_MOVE_HOOK, P_TMP_ATTACK_HOOK, P_TMP_DEFEND_HOOK
+     neue Hooks: std/hooks
+
+08.12.2008, Zesstra
+
diff --git a/doc/sphinx/props/obsolete/P_TMP_MOVE_HOOK.rst b/doc/sphinx/props/obsolete/P_TMP_MOVE_HOOK.rst
new file mode 100644
index 0000000..2b9212e
--- /dev/null
+++ b/doc/sphinx/props/obsolete/P_TMP_MOVE_HOOK.rst
@@ -0,0 +1,65 @@
+P_TMP_MOVE_HOOK
+===============
+
+********************* VERALTETE PROPERTY ******************************
+* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
+***********************************************************************
+
+NAME
+----
+::
+
+    P_TMP_MOVE_HOOK             "move_hook"
+
+DEFINIERT IN
+------------
+::
+
+    /sys/new_skills.h
+
+BESCHREIBUNG
+------------
+::
+
+    Mindestens 3-elementiges Array ({zeitpunkt, objekt, funktion, ...}).
+    Die Funktion wird im 'objekt' mit den gleichen Parametern wie move()
+    nach der Abfrage auf P_NO_TPORT aufgerufen, wenn der 'zeitpunkt'
+    noch nicht ueberschritten ist. Wenn die Funktion etwas anderes als ein
+    5-elementiges Array ({dest, methods, direction, textout, textin})
+    oder -1 zurueckgibt, wird move() normal ausgefuehrt, ansonsten werden die
+    5 move-Parameter durch die Array-Eintraege ersetzt bzw. wird bei einem
+    Rueckgabewert von -1 das move() abgebrochen. In letzterem Fall ist
+    die Funktion dafuer verantwortlich, eine entspr. Meldung an den
+    Spieler auszugeben!
+
+HINWEIS
+-------
+::
+
+    Falls man einem Spieler einen Move-Hook setzt, ist es ratsam, im
+    Move-Hook zu pruefen, ob das Spielerobjekt nach Abarbeitung der Hook-
+    Funktion noch lebt. Ansonsten wird ein doppeltes move() ausgefuehrt:
+    in den Todesraum und direkt wieder zurueck zur Leiche.
+
+BEMERKUNGEN
+-----------
+::
+
+     - Bitte das neuere Hooksystem (s. Manpage std/hooks) benutzen.
+     - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
+       Property auf 0 gesetzt
+     - vor dem Setzen immer auf die Existenz eines gueltigen Hooks
+       pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
+       im Code anderer und ist andererseits unfair gegenueber ihnen
+
+SIEHE AUCH
+----------
+::
+
+     Bewegung:	move(L), NotifyMove(), PreventMove()
+     Hooks:	P_TMP_DIE_HOOK, P_TMP_DEFEND_HOOK, P_TMP_ATTACK_HOOK
+     neue Hooks: std/hooks
+
+
+08.12.2008, Zesstra
+
diff --git a/doc/sphinx/props/skill_info_liste.rst b/doc/sphinx/props/skill_info_liste.rst
new file mode 100644
index 0000000..dedaaff
--- /dev/null
+++ b/doc/sphinx/props/skill_info_liste.rst
@@ -0,0 +1,345 @@
+skill_info_liste
+================
+
+SI_*
+----
+::
+
+DEFINIERT IN
+------------
+::
+
+    /sys/newskills.h
+
+BESCHREIBUNG
+------------
+::
+
+    Die folgende Liste der SI-Typen ist grob nach Gueltigkeit fuer Skills
+    und Spells sortiert.
+
+    
+
+    Anwendungsorte der SI_-Werte sind:
+    - /std/living/combat und von dort gerufene Skills (Kampf)
+    - /std/gilden_ob und in Gilden lernbare Spells/Skills
+    - /std/spellbook und von Spellbooks ausgefuehrte Spells
+    - /std/living/life und von dort gerufene Skills (Alkohol)
+    - /std/shells/* und entsprechende Rassenskills
+
+    Im Skillsystem unter /std/living/skills wird vor auf Informationen
+    aus dem Teil #1 Ruecksicht genommen. Einige dieser Werte
+    werden auch permanent im Spieler gespeichert (wie zB die
+    SI_SKILLABILITY).
+
+AKTUELLE LISTE: (5. Oktober 2011)
+ #1 Skills und Spells:
+    SI_SKILLFUNC: string
+     Beinhaltet den Namen der Methode, die die eigentliche Funktionalitaet
+     des Skills/Spells implementiert.
+     Falls nicht angegeben, wird bei Spells durch UseSpell() das Verb, das
+     der Spieler eingegeben hat, als Spell-Methodenname angenommen.
+     Im Gildenobjekt kann hier abweichend von Spell-Namen stehen, wie die
+     Spellfunktion im Spellbook heisst.
+
+    SI_CLOSURE: closure
+     Optimiert den Zugriff fuer den internen Gebrauch, indem die gefundene
+     Spell/Skillfunktion darin direkt gespeichert wird und so lange gueltig
+     ist, bis das/die Objekt(e)/Closure(s) zerstoert sind.
+     Kann theoretisch auch fuer externe Skills durch (Autoload-)Objekte
+     benutzt werden.
+
+    SI_SKILLABILITY: int
+     Faehigkeit, den Spell/Skill zu benutzen. Normal ist von
+     -MAX_ABILITY bis MAX_ABILITY.
+
+    SI_SKILLDAMAGE_TYPE: string*
+     Art des Schadens eines Angriffs: siehe Schadenstypen in /sys/combat.h
+
+    SI_SKILLDAMAGE_MSG: string
+     Meldung anstatt der Waffe oder Haende-Meldung.
+    SI_SKILLDAMAGE_MSG2: string
+     Meldung anstatt der Waffe oder Haende-Meldung fuer den Raum.
+
+    SI_INHERIT: string
+     Enthaelt den Namen des Skills/Spells, von dem geerbt wird. Das
+     bedeutet einerseits, das LearnSkill() auch diesen uebergeordneten
+     Skill beeinflusst und andererseits, dass bei Skills auch dieser
+     uebergeordnete Skill im Rahmen einer Skill-Anwendung gerufen wird.
+
+    SI_DIFFICULTY: int / [Spells: mixed]
+     Schwierigkeit eines Skills/Spells. Beeinflusst die jeweils oberen
+     Schranken fuer das Lernen eines Skills/Spells in Abhaengigkeit 
+     von Spielerlevel.
+     Wenn in einem Spell-Info-Mapping kein Wert steht wird bei Spells
+     automatisch SI_SPELLCOST genommen, der Wert im Spell-Info-Mapping
+     geht beim Lernen aber immer vor Parametern.
+    FACTOR(SI_DIFFICULTY): int / mixed
+    OFFSET(SI_DIFFICULTY): int / mixed
+     Nur fuer Spellbooks/Spells. Der mixed-Parameter kann Funktionen
+     enthalten. Siehe unten bei SI_SPELLCOST.
+
+    SI_LASTLIGHT: int
+     Zeitpunkt, bis wann der Standardskills SK_NIGHTVISION den Spieler
+     sehen laesst.
+
+    SI_TESTFLAG: int
+     Wenn gesetzt, dann soll der Skill nicht genutzt, sondern nur getestet
+     werden, ob er erfolgreich waere. Entspricht also in etwa dem Aufruf
+     von SpellSuccess() in Spellbooks, wird aber bei UseSkill() als
+     Skill-Parameter uebergeben.
+     Der Skill muss entsprechend implementiert sein!
+
+    SI_GUILD: string
+     Angabe der Gilde, aus der der Skill stammt. Sinnvoll, wenn der Skill
+     nicht aus der aktuellen P_GUILD stammt. Fuer generelle Skills/Spells
+     zB waere das "ANY".
+     Gilt nicht fuer Spells!
+
+    SI_ENEMY: object
+     Aktuelles Feindesobjekt, wird bei Skill-Anwendung aus dem Kampf heraus
+     von std/living/combat.c an den Skill uebergeben.
+     Beispiel: Standardwaffenskills, SK_MAGIC_DEFENSE, SK_MAGIC_ATTACK,
+               SK_TWOHANDED, SK_SPELL_DEFEND, SK_INFORM_DEFEND und
+               SK_DEFEND_OTHER.
+
+    SI_FRIEND: object
+     Zu verteidigendes Freundesobjekt, wird bei Skill-Anwendung aus dem
+     Kampf heraus von std/living/combat.c an den Skill uebergeben.
+     Beispiele: SK_INFORM_DEFEND und SK_DEFEND_OTHER.
+
+    SI_MAGIC_TYPE: string*
+     Enthaelt ein Array der Magietypen, die zum Einsatz kommen. Die Angabe
+     geschieht zB im Spellbook und beeinflusst SpellDefend().
+
+    SI_LAST_USE: int (eventuell obsolet)
+     Letzte Nutzung des Skills.
+
+    
+
+    SI_LEARN_PROB: int (eventuell obsolet)
+     Lernwahrscheinlichkeit.
+
+    SI_SKILLDURATION: int
+     Dauer des Skills/Spells. Momentan nicht allzu verbreitet in Nutzung.
+
+ #2 nur fuer Spells:
+    SI_SPELLBOOK: string
+     Kann direkt das enthaltende Spellbook fuer einen Spell enthalten.
+
+    SM_RACE: mapping
+      Mapping, das als Key die Rasse und als Value ein Mapping X
+      enthaelt. Dieses Mapping X wird direkt zu sinfo hinzugefuegt und
+      ueberschreibt damit bei Bedarf Defaultwerte durch rassenspezifische
+      Werte.
+
+    SI_SPELLCOST: int / mixed
+    FACTOR(SI_SPELLCOST): int / mixed
+    OFFSET(SI_SPELLCOST): int / mixed
+     Beinhaltet die Werte, die fuer die Berechnung der Spellkosten
+     zustaendig sind.
+     Dabei gilt: Realkosten = OFFSET(COST) + (COST * FACTOR(COST))/100
+     Die einzelnen Eintraege koennen anstatt eines fixen Wertes auch den
+     Verweis auch eine Funktion in Form von Closure/Methodenname/Array mit
+     Objekt/Objektname und Methodenname enthalten. Siehe dazu auch
+     execute_anything().
+
+    SI_TIME_MSG: string
+     Meldung, die dem Spieler mitteilt, dass er noch nicht wieder einen
+     Spell casten kann. Falls dieser Eintrag nicht gesetzt ist, wird
+     ein Standardtext ausgegeben.
+
+    SI_SP_LOW_MSG: string
+     Meldung, die dem Spieler mitteilt, dass er zu wenige
+     Konzentrationspunkte besitzt, um den Spell zu casten. Falls dieser
+     Eintrag nicht gesetzt ist, wird ein Standardtext ausgegeben.
+
+    SI_PREPARE_MSG: string
+     Meldung, die dem Spieler ausgegeben werden soll, wenn er einen Spell
+     vorbereitet. Ansonsten wird ein Standardtext ausgegeben.
+
+    SI_PREPARE_BUSY_MSG: string
+     Meldung, die dem Spieler ausgegeben werden soll, wenn er schon diesen
+     Spell vorbereitet. Ansonsten wird ein Standardtext ausgegeben.
+
+    SI_PREPARE_ABORT_MSG: string
+     Meldung, die dem Spieler ausgegeben werden soll, wenn er die
+     Vorbereitung dieses Spells durch einen anderen Spell unterbricht.
+     Ansonsten wird ein Standardtext ausgegeben.
+
+    SI_NOMAGIC: int
+     Wert zwischen 0 und 100 (oder mehr), der gegen die P_NOMAGIC-Wirkung
+     eines Raumes wirkt.
+     Je hoeher der Wert ist, desto unwahrscheinlicher ist es, dass ein
+     Raum den Spell durch Antimagie stoert. Ein Raum sollte nur Werte
+     zwischen 0 und 100 gesetzt haben. Ist der Wert des Raums groesser
+     als der hier angegeben, dann blockiert er Magie mit einer gewissen
+     eben seiner angegebenen Wahrscheinlichkeit.
+
+    SI_NOMAGIC_MSG: string
+     Meldung, die bei Fehlschlag durch P_NOMAGIC des Raumes ausgegeben
+     wird. Ansonsten wird ein Standardtext ausgegeben.
+
+      
+
+    SI_SPELLFATIGUE: int / mixed
+    FACTOR(SI_SPELLFATIGUE): int / mixed
+    OFFSET(SI_SPELLFATIGUE): int / mixed
+     Werte, die fuer die Berechnung der Wieder-Cast-Zeit benutzt werden.
+     Die Berechnung und die moeglichen Angaben (Closure etc.) sind
+     identisch zu SI_SPELLCOST.
+     Das Spellbook gibt bei Nicht-Wieder-Bereitschaft SI_TIME_MSG aus.
+
+    SI_X_SPELLFATIGUE: mapping mit ([string key: int val])
+     Werte, die fuer die Berechnung der Wieder-Cast-Zeit benutzt werden.
+     Spellbook-Casten: Mapping wird durch Aufruf von CheckSpellFatigue(<key>)
+     am Caster gefiltert. Nur wenn das resultierende Mapping leer ist (kein
+     <key> hat einen gueltigen Fatigue-Eintrag), ist Spell castbar, sonst
+     Ausgabe von SI_TIME_MSG.
+     Nach Spellbook-Casten: Setzen der Fatigue fuer alle <val> > 0 mit <key>.
+
+    SI_SKILLLEARN: int / mixed
+    FACTOR(SI_SKILLLEARN): int / mixed
+    OFFSET(SI_SKILLLEARN): int / mixed
+     Werte, die fuer die Berechnung der Lerngeschwindigkeit benutzt
+     werden, normalerweise pro A_INT/2 je 0.01% (also 1 von MAX_ABILITY).
+     Die Berechnung und die moeglichen Angaben (Closure etc.) sind
+     identisch zu SI_SPELLCOST.
+
+    SI_LEARN_ATTRIBUTE: mapping
+     Mapping, welches die Attribute, nach denen gelernt werden soll
+     als Keys enthaelt. Der Value legt die Gewichtung fest, denn bei
+     mehreren Attributen wird ein Mittelwert gebildet.
+     Der Normalfall entspraeche ([A_INT: 1]) fuer SI_LEARN_ATTRIBUTE.
+
+    SI_NO_LEARN
+     Wenn man (temporaer!) nicht will, dass dieser Skill gelernt wird.
+     Muss von den Spellbooks beachtet werden.
+     Sollte niemals im Spieler abgespeichert werden. Oder permanent in
+     Gilde/Spellbook gesetzt sein. Sondern im Laufe einesr Nutzung in der
+     jew. Kopie von sinfo gesetzt werden, die gerade genutzt wird.
+
+    
+
+     SI_SKILLARG: string
+     Beinhaltet den Text, den der Spieler nach dem Spellkommando eingegeben
+     hat. Z.B. stuende bei "krallenschlag ork 2" der Text "ork 2" im
+     Parameter.
+
+    SI_SKILLRESTR_USE: mixed
+     Einschraenkungen fuer das Nutzen des Spells.
+     Wird normalerweise direkt im Spellbook fuer den Spell eingetragen.
+     Die einzelnen Moeglichkeiten werden in der manpage zu
+     "check_restrictions" erlaeutert.
+
+     
+
+    SI_SKILLRESTR_LEARN: mixed
+     Einschraenkungen fuer das Lernen des Spells.
+     Wird normalerweise direkt im Gildenobjekt fuer den Spell
+     eingetragen.
+     Die einzelnen Moeglichkeiten werden in der manpage zu
+     "check_restrictions" erlaeutert.
+
+    SI_SKILLINFO: string
+    SI_SKILLINFO_LONG: string
+     Beschreibung des Spells. Wird im Gildenobjekt eingetragen und
+     SI_SKILLINFO wird von SkillListe angezeigt.
+
+    SI_SKILLDAMAGE: int / mixed
+    FACTOR(SI_SKILLDAMAGE): int / mixed
+    OFFSET(SI_SKILLDAMAGE): int / mixed
+     Werte, die fuer die Schadenshoehenberechnung des Spells benutzt
+     werden (random ueber den Gesamtwert normalerweise).
+     Die Berechnung und die moeglichen Angaben (Closure etc.) sind
+     identisch zu SI_SPELLCOST.
+
+    SI_SKILLDAMAGE_BY_ROW
+     Ein Mapping mit Boni fuer den Angriff aus bestimmten Kampfreihen.
+     Funktioniert nur bei Verwendung von TryDefaultAttackSpell-Spells
+     aus dem Spellbook.
+     Der Key steht fuer eine bestimmte Reihe, sein Wert fuer den
+     randomisierten Bonus fuer Lebewesen, die aus dieser Reihe casten.
+    OFFSET(SI_SKILLDAMAGE_BY_ROW)
+     Ein Mapping mit fixem Wert fuer Row-Boni im Kampf.
+
+     Beispiel: AddSpell("feuerball", 20,
+                        ([SI_SKILLDAMAGE:50,
+                          OFFSET(SI_SKILLDAMAGE):100,
+                          SI_SKILLDAMAGE_BY_ROW:([2:40,3:20}),
+                          OFFSET(SI_SKILLDAMAGE_BY_ROW):([2:20]), ...
+     gibt
+      Reihe 1: random(50)+100;
+      Reihe 2: random(50)+100+random(40)+20
+      Reihe 3: random(50)+100+random(20)
+     ACHTUNG: Hier gilt nicht die selbe Struktur wie bei SI_SPELLCOST!
+
+    SI_SPELL: mapping
+     Dieser Eintrag enthaelt verschiedene Unterwerte, die den Spell
+     gerade fuer Angriffs-Spells genauer beschreiben. Siehe Defend()
+     fuer eine Beschreibung der verschiedenen Eintraege (die so auch
+     in das Spellbook uebernommen werden koennen).
+
+    SI_COLLATERAL_DAMAGE: int
+     Hiermit kann man einen Prozentwert von SI_SKILLDAMAGE (inklusive
+     Offsets und Factor) fuer Kollateralschaden an Freunden im definierten
+     Bereich eines Flaechenspells (TryGlobalAttackSpell()) angeben.
+     10 bedeutet bei OFFSET(SI_SKILLDAMAGE)=100 zB 10% von 100 = 10 = 1 LP
+     an mit reduce_hit_points() verursachtem Schaden.
+
+    
+
+    SI_NUMBER_ENEMIES, SI_NUMBER_FRIENDS: int
+     Wird von TryGlobalAttackSpell() im Spell gesetzt und enthaelt die
+     Anzahl der im angegebenen Bereich befindlichen Feinde und Freunde.
+     Ist dementsprechend von informativem Nutzen fuer den Angegriffenen
+     und das Spellbook NACH Aufruf von TryGlobalAttackSpell().
+
+    
+
+    SI_DISTANCE, SI_WIDTH, SI_DEPTH: int
+     Limitiert die Entfernung, Tiefen und Breite der Wirkung eines
+     TryGlobalAttackSpell()
+
+    SI_SKILLHEAL: int
+     Konvention fuer Spells im Spellbook, dort den Heilwert zu hinterlegen,
+     hat keine Auswirkungen unter /std/.
+
+    SI_USR: mixed
+     Fuer selbst definierte Infos, spellbookabhaengig.
+
+    SI_PREPARE_TIME: int
+     Dauer der Zeit fuer zu praeparierende Spells.
+
+    SI_ATTACK_BUSY_MSG: string
+     Meldung, die dem Spieler mitteilt, dass er schon zu beschaeftigt
+     mit einem Angriff ist, um einen Spell zu casten. Falls dieser
+     Eintrag nicht gesetzt ist, wird  ein Standardtext ausgegeben.
+
+    SI_NO_ATTACK_BUSY: int
+     Enthaelt als Flag NO_ATTACK_BUSY_QUERY wenn der Spell NICHT wie
+     eine Spezialwaffe die Aktionen einschraenkt. Siehe P_ATTACK_BUSY.
+
+    SI_ATTACK_BUSY_AMOUNT: int
+     Menge des P_ATTACK_BUSY fuer diesen Spell. Falls dieser Wert nicht
+     gesetzt ist, aber auch SI_NO_ATTACK_BUSY nicht mit
+     NO_ATTACK_BUSY_QUERY ausgezeichnet ist wird 1 angenommen.
+
+SIEHE AUCH
+----------
+::
+
+    Skills Lernen:  LearnSkill, ModifySkill, LimitAbility
+    * Nutzung:      UseSpell, UseSkill
+    * Abfragen:     QuerySkill, QuerySkillAbility
+    * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
+                    QuerySkillAttributeModifier, RemoveSkillAttributeModifier
+      * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
+    * sonstig:      spruchermuedung
+    * Properties:   P_NEWSKILLS
+    Spellbook:      UseSpell, Learn, SpellSuccess
+    Gilden:         gilden-doku
+    Kampf:          Defend
+
+7. Nov 2012 Gloinson
+