Added public files

Roughly added all public files. Probably missed some, though.
diff --git a/doc/std/.synonym b/doc/std/.synonym
new file mode 100644
index 0000000..508ee32
--- /dev/null
+++ b/doc/std/.synonym
@@ -0,0 +1,9 @@
+armours armour
+ruestung armour
+ruestungen armour
+weapons weapon
+waffen weapon
+waffe weapon
+units unit
+vc virtual_compiler
+ringbuffer util
diff --git a/doc/std/armour b/doc/std/armour
new file mode 100644
index 0000000..9721cfc
--- /dev/null
+++ b/doc/std/armour
@@ -0,0 +1,87 @@
+ STANDARDKLASSE:
+	"/std/armour"
+ 
+ BENUTZUNG:
+        inherit "/std/armour";
+ 
+        #include <properties.h>
+        #include <combat.h>
+
+ PROPERTIES:
+     Grundlegend:
+	P_AC		setzbar: Ruestungsklasse == Schutz
+	P_ARMOUR_TYPE	setzbar: Ruestungstyp
+
+     Besondere Attribute und Anforderungen fuer Traeger:
+	P_RESTRICTIONS	setzbar: Anforderungen an Traeger
+	P_M_ATTR_MOD	setzbar: Attributmodifikator fuer Traeger
+	P_RESISTANCE_STRENGTHS
+			setzbar: Resistenzmodifikator fuer Traeger
+	P_NR_HANDS	setzbar: notwendige Handanzahl (zB Schilde)
+	P_CURSED	setzbar: Verfluchung (nicht ausziehbar)
+
+     Meldungen und Zeitpunkte:
+	P_EQUIP_TIME	enthaelt den Zeitpunkt des Anziehens
+	P_LAST_USE	enthaelt den Zeitpunkt des letzten Treffers
+	P_WORN		enthaelt den Traeger
+	P_WEAR_MSG	setzbar: eigene Anziehmeldungen
+	P_UNWEAR_MSG	setzbar: eigene Ausziehmeldungen
+
+     Dynamisches Verhalten in Kampf und beim Anziehen:
+	P_WEAR_FUNC	setzbar: Objekt mit Anziehfunktion "WearFunc()"
+	P_REMOVE_FUNC	setzbar: Objekt mit Ausziehfunktion "RemoveFunc()"
+	P_DEFEND_FUNC	setzbar: Objekt mit Defensivfunktion "DefendFunc()"
+
+     Zusaetzliche Eigenschaften:
+	P_DAMAGED	enthaelt den Ausmass des Schadens an Waffe
+	P_QUALITY	setzbar: Qualität/Haltbarkeit der Waffe
+	P_EFFECTIVE_AC	setzbar: falls DefendFunc AC nicht sichbar aendert
+	P_DAM_TYPE	setzbar: interessant bei Kaempferangriffen
+
+     Zusaetzlich sind alle Properties aus /std/thing verfuegbar, also
+     bitte auch folgende setzen:
+	P_MATERIAL	setzbar: Zusammensetzung
+	P_SIZE		setzbar: Groesse
+	P_WEIGHT	setzbar: Gewicht
+
+ MAKROS:
+     Gueltige Ruestungstypen (definiert in "/sys/combat.h").
+ 
+ ERLAEUTERUNG:
+     Basisklasse fuer alle Ruestungen im Spiel. Sie ist von "/std/clothing"
+     abgeleitet und enthaelt alle zusaetzliche Funktionalitaet
+     fuer den Kampf.
+
+     Vor der Programmierung von Ruestungen sollte /doc/MG/waffen_werte
+     gelesen werden. Die Regeln darin sind verbindlich und sollten nur
+     in Ausnahmefaellen und mit Absprache mit dem Erzmagier fuer 
+     Waffen/Ruestungen/Monster ueberschritten werden.
+     Gerade in DefendFuncs sollte auf die korrekte Behandlung der
+     uebergebenen Spellflags geachtet werden - insbesondere SP_RECURSIVE
+     und SP_NO_ACTIVE_DEFENSE.
+
+     Die Maximalwerte und Werte fuer Zerstoerung bei Verkauf sind
+     /sys/combat.h zu entnehmen: VALID_ARMOUR_CLASS/KEEP_ARMOUR_CLASS.
+
+ VERERBUNGSBAUM:
+     [/std/armour]
+     ..... [/std/thing/properties]
+     ..... [/std/thing/language]
+     ..... [/std/thing/commands]
+     ..... [/std/thing/restrictions]
+     ..... [/std/thing/envchk]
+     ..... [/std/armour/description]
+     .......... [/std/clothing/description]
+     .............. [/std/thing/description]
+     ..... [/std/armour/wear]
+     .......... [/std/clothing/wear]
+     ..... [/std/clothing/moving]
+     .......... [/std/thing/moving]
+     ..... [/std/armour/combat]
+
+ SIEHE AUCH:
+     P_ARMOURS, P_LAST_WEAR_ACTION, P_TOTAL_AC
+     Attack(), Defend(), /doc/wiz/ruestungen, balance
+
+03.08.2007, Zesstra
+
diff --git a/doc/std/clothing b/doc/std/clothing
new file mode 100644
index 0000000..91ccb55
--- /dev/null
+++ b/doc/std/clothing
@@ -0,0 +1,77 @@
+ STANDARDKLASSE:
+	"/std/clothing"
+ 
+ BENUTZUNG:
+        inherit "/std/clothing";
+ 
+        #include <properties.h>
+        #include <clothing.h>
+
+ PROPERTIES:
+
+     Besondere Attribute und Anforderungen fuer Traeger:
+	P_RESTRICTIONS	setzbar: Anforderungen an Traeger
+	P_CURSED	setzbar: Verfluchung (nicht ausziehbar)
+
+     Meldungen und Zeitpunkte:
+	P_EQUIP_TIME	enthaelt den Zeitpunkt des Anziehens
+	P_WORN		enthaelt den Traeger
+	P_WEAR_MSG	setzbar: eigene Anziehmeldungen
+	P_UNWEAR_MSG	setzbar: eigene Ausziehmeldungen
+
+     Dynamisches Verhalten in Kampf und beim Anziehen:
+	P_WEAR_FUNC	setzbar: Objekt mit Anziehfunktion "WearFunc()"
+	P_REMOVE_FUNC	setzbar: Objekt mit Ausziehfunktion "RemoveFunc()"
+
+     Zusaetzlich sind alle Properties aus /std/thing verfuegbar, also
+     bitte auch folgende setzen:
+	P_MATERIAL	setzbar: Zusammensetzung
+	P_SIZE		setzbar: Groesse
+	P_WEIGHT	setzbar: Gewicht
+
+ 
+ ERLAEUTERUNG:
+     Basisklasse fuer alle Kleidungen im Spiel. Sie ist von "/std/thing"
+     abgeleitet.
+     Kleidung belegt niemals einen Ruestungsslot und ist nur fuer Kram
+     gedacht, der keine kampfrelevante Funktionalitaet beeinhaltet.
+     Momentan ist die Anzahl an Kleidungsstuecken, die ein Spieler anziehen
+     kann, nicht begrenzt.
+     Kleidung sind im Prinzip Ruestungen ohne alle in den Ruestungen
+     enthaltene kampfrelevante Funktionalitaet.
+     (BTW: Kleidungen koennen allerdings, sofern unbedingt notwendig, mittels
+      P_SENSITIVE, P_SENSITIVE_ATTACK, etc. auch indirekt am Kampf teilnehmen,
+      in dem Sinne, dass sie auf eingehenden Schaden reagieren. Hierbei darf
+      allerdings in keinem Fall in den Kampfverlauf eingegriffen werden.)
+
+     Spezielle Properties:
+     SetProp(P_WEAR_FUNC, ob)
+	Setzt das Objekt, in dem die Funktion WearFunc() definiert
+	wird. WearFunc() wird beim Versuch die Kleidung anzuziehen
+	aufgerufen, gibt sie 0 zurueck so scheitert der Versuch.
+     SetProp(P_REMOVE_FUNC, ob)
+	Setzt das Objekt, in dem die Funktion RemoveFunc() definiert
+	ist. Die Funktion wird beim Versuch die Kleidung auszuziehen
+	aufgerufen, gibt sie 0 zurueck, so scheitert der Versuch.
+
+
+ VERERBUNGSBAUM:
+     [/std/clothing]
+     ..... [/std/thing/properties]
+     ..... [/std/thing/language]
+     ..... [/std/thing/commands]
+     ..... [/std/thing/restrictions]
+     ..... [/std/thing/envchk]
+     ..... [/std/clothing/description]
+     .......... [/std/thing/description]
+     ..... [/std/clothing/moving]
+     .......... [/std/thing/moving]
+     ..... [/std/clothing/wear]
+
+ SIEHE AUCH:
+     armours,
+     FilterClothing, FilterArmours, Wear(), Unwear(), WearArmour(),
+     WearClothing(), UnwearArmour(), UnwearClothing() 
+
+15.02.2009, Zesstra
+
diff --git a/doc/std/container b/doc/std/container
new file mode 100644
index 0000000..667078a
--- /dev/null
+++ b/doc/std/container
@@ -0,0 +1,49 @@
+OBJECT:
+	container 
+
+
+DESCRIPTION:
+	A cointainer is a special object which can contain other objects.
+	It provides the same functions as the thing(S) class, but adds
+	some functions for the handling of contents. It defines some
+	properties related to what and how much is contained in it.
+
+	The following additional properties are defined for a container:
+	P_MAX_WEIGHT, P_WEIGHT_CONTENTS
+
+	Note that the weight of a container is handled especially:
+	SetProp(P_WEIGHT,weight) sets the weight of the container
+	without contents, while QueryProp(P_WEIGHT) returns the total
+	weight of the container plus contents.
+
+	For now, you may use the following function to add or remove
+	weight from the container.
+
+	AddWeight(weight)
+	  Adds <weight> to the container. If its OK, 1 is returned,
+	  otherwise 0. Only if the weight fits into the container, the
+	  weight is adjusted.
+
+	MayAddWeight(weight)
+	  Like AddWeight, but if the weight fits inside the container,
+	  the total weight is NOT updated. You may use this function to
+	  test if an object fits into a container.
+
+	NOTE: Currently, these functions may be called from outside.
+	In a alter stage, movement of objects will be done by calling
+	the move() function in the object to be moved. The move()
+	function of that object will then call (May)AddWeight() itself
+	to determine if it may enter the container.
+
+
+INHERITANCE TREE:
+	container
+	  |-thing/moving
+	  |-thing/properties
+	  |-container/description
+	  |   `-thing/description
+	  `-container/restrictions
+
+
+SEE ALSO:
+	thing(S)
diff --git a/doc/std/corpse b/doc/std/corpse
new file mode 100644
index 0000000..d4e2d47
--- /dev/null
+++ b/doc/std/corpse
@@ -0,0 +1,76 @@
+OBJEKT:
+      corpse
+
+
+SYNOPSIS:
+      inherit "std/corpse";
+
+
+BESCHREIBUNG:
+      Die Standardleiche ist ein spezieller Container. Er beinhaltet die
+      zurueckgelassene Ausruestung gestorbener NPCs und Spieler.
+      Die Standardleiche verfault mit der Zeit und stellt ein paar
+      Funktionalitaeten zur Verfuegung, naemlich das Essen der Leiche
+      und das Verspotten auf dem Moerderkanal.
+      Die Funktion
+        void Identify( object ob );
+      wird im die() eines Livings aufgerufen, damit die Leiche Informationen
+      aus dem Living auslesen kann, ehe dieser endgueltig stirbt. Schreibt
+      man eine eigene Leiche, dann ist dies die geeignete Moeglichkeit, der
+      Leiche Informationen zukommen zu lassen.
+
+
+BEISPIELE:
+      // Eine eigene Leiche.
+      #inherit "std/corpse";
+
+      void create()
+      {
+        ::create();
+        // Irgendwas eigenes...
+      }
+
+      /*
+       * Dieser Funktion wird der getoetete Living uebergeben.
+       */
+      void Identify(object ob)
+      {
+        ::Identify(ob);
+        if (ob)
+        {
+          ob->QueryProp("meine_tolle_property");
+        }
+      }
+
+      /*
+       * Das ist die für "iss leiche" aufgerufene Funktion.
+       */
+      int mampf( string str )
+      {
+        notify_fail("Was willst Du essen?\n");
+        if (!str || !id(str) ) return 0;
+        tell_object(this_player(), "Diese Leiche kann man nicht essen.\n");
+        return 1;
+      }
+
+
+
+BEMERKUNG:
+      Man kann eigene Leichen schreiben, die von der Standardleiche erben
+      oder auch nicht. Man sollte dann aber die im die() aufgerufenen
+      Funktionen implementieren:
+        corpse->Identify(object ob);
+	corpse->SetProp(***); // Fuer P_HEAL
+	corpse->move(***); // Um sie ins environment() des Toten zu bekommen.
+      Die Leiche sollte, muss aber kein Container sein, damit die Ausruestung
+      hineinbewegt werden kann.
+      Wenn man nicht von der Standardleiche erbt, kommt sie nicht auf -Moerder
+      und man kann sie nicht verspotten. Damit dies geht, muss (!) man von der
+      Standardleiche erben.
+
+SIEHE AUCH:
+      P_NOCORPSE, P_CORPSE, P_HEAL, QueryHealInfo()
+
+
+----------------------------------------------------------------------------
+Letzte Aenderung: 31.03.2008, Arathorn
diff --git a/doc/std/hooks b/doc/std/hooks
new file mode 100644
index 0000000..de308bd
--- /dev/null
+++ b/doc/std/hooks
@@ -0,0 +1,278 @@
+Das neue Hooksystem
+(Implementierung von Muadib, ueberarbeitet von Zesstra)
+
+EINLEITUNG
+==========
+Das neue Hooksystem baut nicht mehr auf der Eintragung eines Hooks in einer
+Property auf. Dadurch wird es moeglich, dass nicht nur ein Objekt sich als
+Hook eintraegt.
+
+Es gibt verschiedenen Arten von Hooks, die man eintragen kann:
+* Listener (H_LISTENER)
+            diese Hooks werden ueber ein Ereignis nur informiert,
+            koennen aber nicht eingreifen oder aendern.
+            max. Anzahl: 5
+* Data-Modifier (H_DATA_MODIFICATOR)
+            diese Hooks duerfen die Daten eines Ereignisses aendern.
+            max. Anzahl: 3
+* Hook-Modifier (H_HOOK_MODIFICATOR)
+            diese Hooks duerfen die Daten des Ereignisses aendern und
+            zusaetzlich das Ereignis auch abbrechen.
+            max. Anzahl: 2
+* Surveyor (H_HOOK_SURVEYOR)
+            diese Hooks duerfen alles oben beschriebene. Zusaetzlich werden
+            sie aber auch gefragt, wenn andere Objekte einen Hook eintragen
+            wollen, einen Hook abbrechen wollen oder Daten aendern wollen.
+            Oder anders: Surveyorhooks entscheiden, was andere duerfen.
+            Kein normales Objekte sollte diese Art von Hook eintragen. Der RM
+            muss die Verwendung eines Surveyors genehmigen.
+            max. Anzahl: 1
+
+Ausserdem lassen sich Hooks noch mit unterschiedlicher Prioritaet eintragen,
+welche dann in der entsprechenden Reihenfolge abgearbeitet werden. Wenn ein
+neuer Hook eingetragen wird, aber eigentlich die max. Anzahl schon erreicht
+wird, wird der Konsument mit der niedrigsten Prioritaet geloescht. In diesem
+Fall wird die superseededHook() im verdraengten Konsumenten gerufen.
+
+Um das neue Hook-System zu realisieren, gibt es zwei wesentliche Klassen.
+Die Objekte, die die Eintragung von Hooks erlauben, erben hierzu von
+hook_provider. Objekte, die einen Surveyor-Hook eintragen wollen, sollten von
+der Klasse hook_surveyor erben. Objekte mit normalen Hooks brauchen nichts zu
+erben.
+
+
+Welche Hooks gibt es zur Zeit in der Basis-Mudlib?
+=================================================
+* H_HOOK_MOVE
+  Bei Bewegung eines Objektes ausgeloest. Kann Bewegung beeinflussen oder
+  abbrechen.
+* H_HOOK_DIE
+  Beim Tod eines Lebewesens ausgeloest. Kann den Tod abbrechen oder
+  <poisondeath> abaendern.
+* H_HOOK_DEFEND
+  Im Defend() eines Lebenwesens ausgeloest. Kann das Defend() abbrechen und
+  Daten des Defend() aendern.
+* H_HOOK_ATTACK
+  Im Attack() eines Lebenwesens ausgeloest. Kann das Attack() abbrechen.
+* H_HOOK_HP
+  Bei Veraenderung der HP (LP) eines Lebewesens gerufen. (Zur Zeit keine
+  Datenveraenderung moeglich)
+* H_HOOK_SP
+  Bei Veraenderung der SP (KP) eines Lebewesens gerufen. (Zur Zeit keine
+  Datenveraenderung moeglich)
+* H_HOOK_ATTACK_MOD
+  Wird im Attack() ausgeloest, nachdem die fuer den Angriff wichtigen Daten
+  ermittelt und berechnet wurden. Diese koennen dann vom Hookonsumenten
+  nochmal geaendert werden. Auch ein Abbruch des Attack() ist hier noch
+  moeglich.
+* H_HOOK_ALCOHOL
+  Bei Veraenderung von P_ALCOHOL im Lebewesens gerufen.
+* H_HOOK_FOOD
+  Bei Veraenderung von P_FOOD im Lebewesens gerufen.
+* H_HOOK_DRINK
+  Bei Veraenderung von P_DRINK im Lebewesens gerufen.
+* H_HOOK_POISON
+  Bei Veraenderung von P_POISON im Lebewesens gerufen.
+* H_HOOK_CONSUME
+  Beim Konsumieren von Speisen und Getraenken in Kneipen im Lebewesens
+  gerufen.
+* H_HOOK_TEAMROWCHANGE
+  Bei Teamreihenwechsel vom Lebewesen ausgeloest.
+* H_HOOK_INSERT
+  Wird von Spielerobjekten ausgeloest, wenn ein Objekt ins Spielerinventar
+  bewegt wird. (Keine Datenveraenderung moeglich)
+* H_HOOK_EXIT_USE
+  Wird von einem Raum ausgeloest, wenn ein Lebewesen einen Ausgang benutzt.
+  Abbruch und Aenderung der Daten des Ausgangs moeglich.
+
+HOOK-KONSUMENTEN
+================
+Der Hook-Provider ruft bei Ausloesen des Hooks in allen Konsumenten eine
+bestimmte Methode auf. Wenn bei der Registrierung eines Objekts keine Closure
+angeben wurde, die in diesem Fall gerufen werden, wird standardmaessig die
+lfun HookCallback() gerufen (gibt man eine Closure an, bekommt sie die
+gleichen Argumente und es werden die beschriebenen Rueckgabewerte erwartet):
+  * mixed HookCallback(object hookSource, int hookid, mixed hookData)
+  Diese Methode wird in jedem Hook-Konsumenten eines Hook-Providers
+  aufgerufen, solange die Verarbeitung nicht vorher abgebrochen wurde.
+  Die Reihenfolge der Abarbeitung wird nach Liste (Surveyor,
+  Hook-Modifikator, Data-Modifikator, Listener) und dort nach Prioritaet
+  durchgefuehrt.
+  Ein Surveyor-Hook kann verhindern, dass Hooks bestimmte Aenderungen
+  durchfuehren.
+
+  Rueckgabewert ist ein Array, das die folgenden Werte beinhaltet.
+
+  H_RETCODE Gibt an, welcher Hook-Typ verwendet wurde.
+      H_NO_MOD => Nichts wurde veraendert.
+      H_ALTERED => Daten wurden veraendert.
+      H_CANCELLED => Hook-Kette soll abgebrochen werden.
+                  => Ausserdem soll die Hook-ausloesende Stelle
+                     abgebrochen werden. Z.B. wird das Defend()
+                     abgebrochen, wenn ein H_HOOK_DEFEND
+                     mit cancelled beantwortet wird.
+  H_RETDATA Gibt die (evtl. geaenderten) Daten an.
+      mixed-Objekt, das wie der Parameter hookData aufgebaut ist.
+
+Ein Objekt darf sich mehrfach fuer den gleichen Hook registrieren. Allerdings
+ist fuer jede Registrierung eine andere Closure noetig.
+
+  * void superseededHook(int hookid, object hookprovider)
+    Wird gerufen, wenn der Konsument von einem anderen mit hoeherer Prioritaet
+    verdraengt wurde.
+
+
+HOOK-PROVIDER
+=============
+  Der Hook-Provider bietet eine Menge von Methoden an, die eine Konfiguration
+  ermoeglichen und die Eintragung von Hook-Konsumenten erlauben. Im
+  Normalfall sollte er geerbt und nicht modifiziert werden (ausser natuerlich,
+  die vom Objekte bereitgestellten Hooks einzutragen).
+
+  * int* HListHooks();
+  Diese Methode liefert eine Liste von Hooktypen, fuer die das Objekt
+  Eintragungen annimmt. Hier koennte beispielsweise eine Liste mit den
+  Eintraegen fuer Attack-, Defend- und Move-Hooks stehen.
+
+
+  * protected void offerHook(int hookid, int offerstate);
+  Diese Methode dient dazu, einen bestimmten Hook (z.B. H_HOOK_MOVE)
+  anzubieten. Nur Hooks, die hiermit angeboten wurden, stehen zur
+  Registrierung zur Verfuegung.
+  'offerstate': 0 (nicht verfuegbar), 1 (verfuegbar/angeboten)
+
+
+  * int HRegisterToHook(int hookid, mixed consumer, int hookprio,
+                       int consumertype, int timeInSeconds);
+  Registriert ein Objekt oder eine Closure als Hook-Konsument.
+  Parameter:
+  'hookid'        gibt den Hook-Typ an, z.B. den Defend-Hook.
+                  Man kann sich nur fuer Hooktypen eintragen, die die Methode
+                  HListHooks() angeboten hat.
+  'consumer'      Wenn ein Objekt, wird das Objekt eingetragen und spaeter
+                  HookCallback() gerufen.
+                  Wenn eine Closure, wird das Objekt der Closure eingetragen
+                  und spaeter diese Closure gerufen.
+  'hookprio'      Gibt die Prioritaet an, mit der der Hook laufen soll.
+                  Diese Angabe bestimmt die Reihenfolge, in der die Hooks
+                  in der Liste der Hooks eingetragen werden. Die Prioritaet
+                  ist H_HOOK_LIBPRIO(x), H_HOOK_GUILDPRIO(x) oder
+                  H_HOOK_OTHERPRIO(x). x darf 0, 1 oder 2 sein (je niedriger,
+                  desto hoeher die Prioritaet).
+  'consumertype'  Gibt an, um welche Art von Hook es sich handelt.
+                  Es gibt vier festgelegten Typen, die fuer alle Hooks
+                  existieren koennen. Die Methode HConsumerTypeIsAllowed()
+                  gibt Aufschluss darueber, welche Hook-Typen existieren.
+                  Die Hook-Typen sind in hook.h definiert.
+  'timeInSeconds' gibt die Laufzeit des Hooks an. Falls 0 eingetragen wird,
+                  laeuft der Hook ewig.
+  Rueckgabewerte:
+    1 - Registrierung erfolgreich
+  <=0 - Registrierung fehlgeschlagen:
+        -1 : Hook unbekannt
+        -2 : consumer ist keine closure und es konnte kein Callback auf
+             HookCallback im consumer erstellt werden.
+        -3 : consumer ist bereits registriert
+        -4 : consumertyp ist nicht erlaubt
+        -5 : hookprio ist nicht erlaubt
+        -6 : Surveyor hat Registrierung nicht erlaubt
+        -7 : zuviele Hooks registriert / kein Hookeintrag frei
+
+  * int HUnregisterFromHook(int hookid, mixed consumer);
+  Hebt die Registrierung von <consumer> fuer einen bestimmten Hook-Typ wieder
+  auf.
+  Parameter:
+  'hookid'    Die Kennung des Hook-Typs, z.B. die Kennung des Attack-Hooks.
+  'consumer'  Das Objekt oder die Closure, die/das nicht mehr registriert sein
+              soll. Bei einer Closure wird genau diese ausgetragen. Bei der
+              Angabe eines Objekts wird versucht, die Closure auf
+              HookCallback() in diesem Objekt auszutragen.
+  Rueckgabewerte:
+  0 - 'consumer' nicht als Konsument gefunden
+  1 - Austragen erfolgreich
+
+  * int HConsumerTypeIsAllowed(int type, object consumer);
+  Diese Methode liefert 1 zurueck, wenn ein bestimmter Konsumenten-Typ
+  (fuer diesen Konsumenten) erlaubt wird.
+  Die Standardmethode liefert immer 1 (true) zurueck. Erbende Objekte
+  koennen diese Methode ueberschreiben, wenn sie nicht alle Hooktypen
+  anbieten.
+
+
+  * int HPriorityIsAllowed(int prio, object consumer);
+  Diese Methode gibt an, ob eine bestimmte Prioritaet (fuer den angegebenen
+  Konsumenten) erlaubt ist. Die Standardmethode liefert immer 1 (true)
+  zurueck. Erbende Objekte koennen diese Methode ueberschreiben, wenn
+  sie die verfuegbaren Hook-Prioritaeten einschraenken wollen.
+
+
+  * int HIsHookConsumer(int hookid, mixed consumer);
+  Ist <consumer> ein Objekt, liefert die Methode die Anzahl, wie oft dieses
+  Objekt (mit verschiedenen Closures) fuer den Hook <hookid> eingetragen ist.
+  Ist <consumer> eine Closure, liefert diese Methode 1, wenn diese
+  Closure fuer den Hook <hookid> eingetragen ist.
+
+
+  * protected mapping HCopyHookMapping();
+  Diese Methode liefert eine Kopie des Hook-Mappings.
+  ACHTUNG: diese Daten sollten das Objekt NIEMALS verlassen. (Ausser fuer
+           Debugzwecke)
+
+
+
+HOOK-SURVEYOR
+=============
+  Objekte mit Surveyorhooks muessen eine Menge von Methoden definieren, die
+  der Hookprovider aufruft:
+
+  * status HookRegistrationCallback(
+                object registringObject,
+                int hookid,
+                object hookSource,
+                int registringObjectsPriority,
+                int registringObjectsType)
+  Diese Methode wird vom Hook-Provider aufgerufen, wenn der Hook-Konsument
+  als Surveyor eingetragen ist und ein weiterer Hook eingetragen werden soll.
+  Gibt diese Methode 0 zurueck, dann verbietet der Konsument, dass der
+  andere Konsument als Hook eingetragen wird.
+
+  * int HookCancelAllowanceCallback(
+                object cancellingObject,
+                int hookid,
+                object hookSource,
+                int cancellingObjectsPriority,
+                mixed hookData)
+  Diese Methode wird aufgerufen, um herauszufinden, ob ein bestimmter
+  anderer Hook die Ausfuehrung der Hook-Kette unterbrechen darf.
+  Nur Hooks im Bereich H_HOOK_MODIFICATOR werden der Methode uebergeben.
+
+  * int HookModificationAllowanceCallback(
+                object modifyingObject,
+                int hookid,
+                object hookSource,
+                int modifyingObjectsPriority,
+                mixed hookData)
+  Diese Methode wird aufgerufen, um herauszufinden, ob ein bestimmter
+  anderer Hook die Daten des Hooks veraendern darf oder nicht.
+  Es werden die Hooks in den Bereichen H_HOOK_MODIFICATOR und
+  H_DATA_MODIFICATOR (in dieser Reihenfolge) aufgerufen.
+
+
+WAS KOSTET DAS?
+  Das Ausloesen eines Hooks per HookFlow() kostet 111 Ticks und ca. 7 us, wenn
+  es gar keinen gibt, der drauf lauscht (sozusagen Fixkosten).
+  Pro H_LISTENER kommen dann 31 Ticks und ca. 2 us dazu.
+
+  Gibts einen Surveyor-Hook (der wird dann gefragt, ob andere Objekte die
+  Daten des Hooks aendern oder die Hookverarbeitung abbrechen duerfen):
+  Fixkosten: 155 Ticks, 11 us.
+  Plus pro Data-Modifier:
+  106 Ticks, 5.6 us
+  Plus pro Hook-Modifier, der aber nur Daten aendert:
+  112 Ticks, 6.4 us
+  Und ein Hook-Modifier, der den Hook abbricht:
+  76 Ticks, 4 us
+
+  (Macht der Surveyor natuerlich irgendwas anderes als 'return 1;', wirds
+  natuerlich entsprechend teurer.)
+
diff --git a/doc/std/living b/doc/std/living
new file mode 100644
index 0000000..89d47bd
--- /dev/null
+++ b/doc/std/living
@@ -0,0 +1,120 @@
+
+OBJECT:
+	living 
+
+
+SYNOPSIS:
+	inherit "std/living";
+
+	#include <properties.h>
+	#include <living.h>
+
+
+DESCRIPTION:
+	This is the generic living object which 'lives', can move,
+	can fight.
+
+	It has a number of 'stats', also called 'attributes' in
+	the new system. These include the former stats 
+	strength, dexterity, intelligence and constitution.
+	These attributes determine the life functions and
+	variables like hitpoints and spellpoints, but also the
+	ability to perform certain actions like spellcasting or
+	swordfighting. Attributs are implemented as a property
+	P_ATTRIBUTES. Attributes can be set by using the functions
+
+	SetAttribute(string attribute, int value)
+	  Sets <attribute> to <value>. Certain restrictions might
+	  exist, and the requested attribute might not be set.
+	  Attributes are integer values, and are in the range
+	  of 1 (very bad) to 20 (excellent and highest possible
+	  for a normal human).
+
+	int QueryAttribute(string attribute)
+	  Returns value of <attribute>
+
+	Abilities. A living creature may have special abilities
+	to perform certain actions. These may be very different
+	types of actions, like fighting with a sword, casting
+	a fireball or climbing up a tree. Abilities are
+	implemented as the P_ABILITIES property. An ability may
+	be accompanied by an object which may define special
+	actions and which uses the values of P_ABILITES, for 
+	example a spellbook will store spell levels there or
+	a weapon uses a weapon ability (skill). The abilities
+	can be manipulated:
+
+	SetAbility(string ability, int value)
+	  Sets <ability> to <value>.
+
+	int QueryAbility(string ability)
+	  Ask the value of <ability>.
+
+	Equipment. Weaponclass and armourclass are defined. Unless
+	a weapon is used, the wc is 0. Unless an armour is used,
+	the ac is 0. (P_WC and P_AC)
+
+	Live variables. A living creature has several needs just
+	because it is alive. The complex life functions are
+	reducced to some crucial factors.
+
+	P_HP
+	  These are mainly determined by the constitution and give
+	  the ability of the body to absorb damage. If the
+	  hitpoints go below zero, the creature is dead.
+
+	P_SP
+	  Spellpoints (sometimes called mana) describe the magical
+	  (spiritual) capability of the creature. It is mainly
+	  determined by Intelligence and Wisdom. It is up to the
+	  creature how good it uses the spellpoint resource.
+	  Spellpoints will go down when supernatural actions are
+	  performed by the creature.
+
+	P_MAX_SP, P_MAX_HP
+	  Readonly variable which are computed from attributes.
+
+	P_FOOD, P_DRINK, P_ALCOHOL, (P_POISON)
+	  These three variables describe hunger, thirst and
+	  intoxication by alcohol. The max is dependent on the
+	  constitution of the living, and of the weight.
+	  These variables automatically decrease with time.
+	  When food or drink goes below zero, the creature
+	  suffers hunger or thirst and will lose hitpoints.
+
+	P_MAX_FOOD, P_MAX_DRINK, P_MAX_ALCOHOL
+	  Readonly variables which are computed from attributes.
+
+	P_WEIGHT, P_SIZE
+	  These variables describe the physical proportions of
+	  the creatures body. Both variables are standard properties
+	  and are also used in normal objects.
+
+	P_MAX_WEIGHT 
+	  This is a readonly variable which describes how much
+	  a living creature may carry around.
+
+	P_GENDER
+	  This is obvious. Gender may be MALE, FEMALE or NEUTER,
+	  as defined in <living.h>. Player gender may be only
+	  MALE or FEMALE.
+
+	P_RACE
+	  A string which defines the race.
+
+	P_ALIGNMENT
+	  The alignment of the living, ranging frO
+
+	P_AGE
+	  The age of the living creature in seconds
+	
+
+INHERITANCE TREE:
+	living
+	  |-thing/moving
+	  |-thing/properties
+	  `-thing/description
+
+
+SEE ALSO:
+	properties(C), units(C)
diff --git a/doc/std/obsolete/door b/doc/std/obsolete/door
new file mode 100644
index 0000000..15bad30
--- /dev/null
+++ b/doc/std/obsolete/door
@@ -0,0 +1,22 @@
+****************************************************************************
+************************* VERALTETE LFUN ***********************************
+************************* DO NOT USE!    ***********************************
+****************************************************************************
+
+BITTE STATT DER FUNKTION Door() IMMER  NewDoor() BENUTZEN.
+
+	AddDoor(string command, string roomfile, string doorname,
+		string doordesc, string keyname, int status)
+	  Creates a door which leads in direction <command> to the
+	  room <roomfile>. The door has the short description
+	  <doorname> and the long description <doordesc>, when you
+	  look at it. If a door with the same <doorname> exists in
+	  the other room, the open/close/locked status will be
+	  the same in both rooms at all time. Doors are locked on
+	  reset() if keyname is not 0. If <keyname> is given, the
+	  door is locked and can be opened only with a key which
+	  matches <keyname> with its id(). <status> can be set
+	  to an initial value of DOOR_STATUS_OPEN, DOOR_STATUS_CLOSED
+	  or DOOR_STATUS_LOCKED. These status codes are defined in
+	  <doors.h>.
+
diff --git a/doc/std/pub b/doc/std/pub
new file mode 100644
index 0000000..21544a7
--- /dev/null
+++ b/doc/std/pub
@@ -0,0 +1,95 @@
+Um die Funktionalitaet einer Kneipe nutzen zu koennen, muss der Raum eine
+der folgenden Dateien importieren:
+
+'/std/pub.c'         - die Komplettloesung inclusive der Abhaengigkeit zu
+                       '/std/room'
+
+'/std/room/pub.c'    - die Mindestloesung, bei der man selbst die Abhaengig-
+                       keit zu einem Raum definieren muss
+
+------------------------------------------------------------------------------
+Eine Zusammenfassung der Pub-Properties (fuer genaueres siehe manpages)
+aus '/sys/pub.h'
+
+P_NPC_FASTHEAL       - NPCs tanken hier auf die "schnelle" Art
+
+P_NO_STD_DRINK       - Der Pub soll keine Standard-Getraenke anbieten
+
+P_PUB_UNAVAILABLE    - Meldung, wenn etwas nicht mehr vorhanden ist
+
+P_PUB_NOT_ON_MENU    - Meldung, wenn etwas nicht im Menue steht
+
+P_PUB_NO_MONEY       - Meldung, wenn Spieler nicht genug Geld hat
+
+P_PUB_NO_KEEPER      - Meldung, wenn der P_KEEPER nicht anwesend ist
+
+aus '/sys/room/description.h'
+
+P_KEEPER             - Id des Kneipeninhabers, der anwesend sein muss, 
+                       damit die Kneipe genutzt werden kann
+
+------------------------------------------------------------------------------
+Methoden zur Manipulation des Menues (fuer genaueres siehe manpages)
+
+AddToMenu            - fuegt einen Eintrag zum Menue hinzu
+
+RemoveFromMenu       - entfernt einen Eintrag aus dem Menue
+
+------------------------------------------------------------------------------
+Ablauf und Manipulationsmoeglichkeiten in einer Kneipe
+
+Wunsch wurde ueber 'kaufe', 'bestelle' oder 'spendiere' abgegeben:
+
+search_what()        - prueft, dass nicht mehrere Wuensche auf einmal
+                       geaeussert werden und ruft consume_something() auf
+
+consume_something()  - prueft die Anwesenheit der beteiligten Personen
+                     - prueft die Anwesenheit des Kneipenbesitzers
+                     - prueft das Ignorieren beim Spendieren
+                     - prueft die Verfuegbarkeit von genuegend Geld beim
+                       Besteller ( check_solvency() )
+                     - prueft die Verfuegbarkeit des Gewuenschten
+                       ( CheckAvailability() )
+                     - prueft, ob der Empfaenger in der Lage ist, das
+                       Bestellte zu konsumieren
+                       ( ueber empfaenger->consume(testonly) )
+
+                     - fuehrt die Bezahlung durch ( do_pay() )
+                     - fuehrt die Vergabe von FPs durch ( GiveEP() )
+                     - entnimmt das Bestellte aus der Menge des Angebotes
+                       ( DecreaseAvailibility() )
+                     - prueft, ob eine Verzoegerung der Lieferung erfolgen
+                       soll und uebergibt im Negativfall gleich an
+                       do_deliver()
+                     - Ausgabe der Meldungen zur Bestellung
+                     - verzoegerter Aufruf von do_deliver()
+                     
+do_deliver()         - prueft nochmal die Anwesenheit des Empfaengers
+                     - prueft, ob Heilung erlaubt ist (ueber Pubmaster)
+                     - prueft P_NPC_FASTHEAL und korrigiert die Angaben, die
+                       aus dem Menueeintrag kommen
+                     - fuehrt das Konsumieren beim Empfaenger durch
+                       ( empfaenger->consume() )
+                     - Ausgabe der Meldung zum Konsumieren
+
+pub_init()           - Moeglichkeit fuer Magier, die Werte der angebotenen
+                       Speisen und Getraenke zu ueberpruefen
+                     - erweiterte Moeglichkeiten zum Pruefen von korrekten
+                       Menueeintraegen bietet das Pub-Tool
+                       ( '/obj/tools/pubtool.c' )
+
+Hinweis: Um diese Pruefungen und Aktionen sicher zu gewaehrleisten, sollte
+         man consume_something oder do_deliver NICHT ueberschreiben!
+         Das fuehrt bei Aenderungen mit grosser Wahrscheinlichkeit zu
+         Problemen!
+         Ueberschreibt besser die Methoden, die die Funktionalitaet
+         beinhaltet, die ihr wirklich anpassen wollt.
+         Falls das nicht geht, sprecht lieber mit einem RM+, ob eine Loesung
+         dafuer gefunden werden kann. Der Standard-Pub wurde in der
+         Vergangenheit so immer modularer und besser.
+
+
+SIEHE AUCH: AddToMenu, RemoveFromMenu, consume, QueryMoney, AddMoney 
+
+------------------------------------------------------------------------------
+Last modified: Son Apr 11 19:28:00 2010 by Caldra
diff --git a/doc/std/random b/doc/std/random
new file mode 100644
index 0000000..489214d
--- /dev/null
+++ b/doc/std/random
@@ -0,0 +1,71 @@
+Es gibt im MG zwei Quellen von Pseudo-Zufallszahlen.
+
+1) random()
+  Diese efun liefert eine Zufallszahl aus dem Pseudo-Zufallszahlengenerator
+  (PRNG) des Drivers. (s. Manpage).
+  Wenn keine besonderen Gruenden vorliegen, sollte immer diese verwendet
+  werden.
+
+
+2) /std/util/rand-glfsr.c
+  Falls jemand aus irgendeinem Grund eine Sequenz von Pseudo-Zufallszahlen
+  braucht, die spaeter reproduzierbar sein soll (d.h. der Seed muss
+  konfigurierbar sein), gibt es unter /std/util/rand-glfsr.c einen simplen,
+  nicht allzu guten und sehr ineffizienten Pseudo-Zufallszahlengenerator.
+
+Interface:
+* public varargs void init(int seed, int newp)
+  Setzt das Seed (und das Erzeugungspolynom, wenn gewuenscht, wovon ich
+  aber abraten wuerde). Der Seed darf nicht 0 sein.
+* public void InitWithUUID(string uuid)
+  Berechnet einen Seed aus der uuid und initialisiert den PRNG damit (und dem
+  Default-Polynom).
+* public int nextbit()
+  Liefert ein zufaelliges Bit (also 0 oder 1).
+* public int nextbits(int count)
+  Liefert <count> Bits (max 64) in einem int.
+* public int random(int n)
+  Liefert eine Zufallszahl zwischen 0 und n-1, in welcher 32 bits an 
+  Pseudozufall stecken.
+  Das Seed von der Blueprint wird vermutlich staendig veraendert (d.h.
+  verlasst euch nicht drauf, dass es konstant bleibt), wollt ihr eine
+  'private' Instanz mit eurem Seed, clont das Objekt (aber verliert den Clone
+  nicht).
+
+  Und um es nochmal zu sagen:
+  Die IMHO einzige sinnvolle Anwendung ist, wenn man aus irgendeinem Grund
+  das seed selber waehlen muss, damit man die Sequenz von Pseudozufall immer
+  wieder reproduzieren kann.
+  In allen anderen Faellen nehmt besser das random() vom Driver.
+
+Der PRNG benutzt ein Linear Feedback Shift Register (in Galois-Variante). Die
+Periodenlaenge des per Default benutzten Erzeugngspolynoms ist 2^32 - 1, d.h.
+nach 4294967295 Bits wiederholt sich die Sequenz.
+Das Default-Polynom ist:
+x^32 + x^31 + x^28 + x^27 + x^24 + x^23 + x^20 + x^19 + x^16 + x^15 + x^12
+     + x^11 + x^8 + x^7 + x^5 + x^3 + 1
+(Zahlenwert: 0x1999999a8)
+
+Wer ein anderes Polynom will, kann das per init() konfigurieren, sollte sich
+aber schlau machen, welche sinnvoll nutzbar sind.
+
+
+Ein paar statistische Daten eines Stroms von 40960 Bits:
+Value Char Occurrences Fraction
+  0            20474   0.499854
+  1            20486   0.500146
+
+Total:         40960   1.000000
+
+Entropy = 1.000000 bits per bit.
+
+Optimum compression would reduce the size
+of this 40960 bit file by 0 percent.
+
+Chi square distribution for 40960 samples is 0.00, and randomly
+would exceed this value 95.27 percent of the times.
+
+Arithmetic mean value of data bits is 0.5001 (0.5 = random).
+Monte Carlo value for Pi is 3.109026964 (error 1.04 percent).
+Serial correlation coefficient is -0.008399 (totally uncorrelated = 0.0).
+
diff --git a/doc/std/room b/doc/std/room
new file mode 100644
index 0000000..94e575f
--- /dev/null
+++ b/doc/std/room
@@ -0,0 +1,143 @@
+STANDARDOBJEKT FUER RAEUME:
+
+BENUTZUNG:
+      inherit "/std/room";
+      
+      #include <properties.h>
+      #include <rooms.h>            // Fuer AddItem() und NewDoor()
+
+BESCHREIBUNG:
+      Ein Raum ist ein Objekt, das von Spielern oder anderen Lebewesen
+      betreten werden kann. Er hat Lang- und Kurzbeschreibungen von
+      innen und aussen (zum Beispiel Schiffe oder aehnliche Raeume in
+      Raeumen), die sich der Spieler je nach seinen Beduerfnissen
+      anzeigen lassen kann (kurz/lang-Modus).
+
+   Properties:
+
+      P_INT_SHORT
+            Kurzbeschreibung innerhalb des Raumes
+      P_INT_LONG
+            Langbeschreibung innerhalb des Raumes
+      P_SHORT
+            Kurzbeschreibung von aussen (nur noetig, wenn man den Raum
+            auch wirklich von aussen sehen kann)
+      P_LONG
+            Langbeschreibung von aussen (siehe P_SHORT)
+      Um Situationsbezogene Beschreibungen zu bekommen, kann man 
+      Querymethoden auf die jeweiligen Properties setzen, siehe Dokumentation
+      zu Set().
+
+      P_LIGHT
+            Lichtlevel des Raums (0 dunkel, 1 hell)
+      P_LIGHT_TYPE
+            Lichtart, mit der der Raum beleuchtet ist, zB LT_SUNLIGHT
+      P_INDOORS
+            Wenn es sich um einen Aussenraum handelt, 0. 1 fuer Innenraeume.
+      P_TRANSPARENT
+            Ist ungleich 0, wenn man in den Raum von aussen reinschauen
+            kann, oder von innen nach aussen
+      P_NO_TPORT
+            Zum verhindern von Teleportversuchen in oder aus dem Raum
+      P_NOMAGIC
+            Im Raum kann nicht gezaubert werden.
+  P_WATER
+    Im Raum kann geangelt werden, und man kann ggf. sogar Fische fangen.
+
+   Funktionen:
+
+  AddExit(string|string* kmnd, string zielraum)
+            <kmnd> kann ein String sein oder eine Liste von Strings
+            mit den Kommandos mit denen der Spieler in <zielraum>
+            landen soll.
+      RemoveExit(string|string* kmnd)
+            <kmnd> ist ein String oder eine Liste von Strings, deren
+            Ausgaenge entfernt werden sollen. Dabei muss man etwas vor-
+            sichtig sein, da ein Spieler, der zum Zeitpunkt des Aufrufs
+            im Raum ist, die Aktion fuer sich noch definiert hat.
+            Also: Nur benutzen, wenn man weiss, was man tut!
+      AddSpecialExit(string|string* kmnd, string funktion)
+            <funktion> wird aufgerufen, wenn der Spieler das Kommando
+            <kmnd> tippt (oder eins der Kommandos, wenn <kmnd> eine
+            Liste ist). Nuetzlich zum Beispiel um einen Spieler nur
+            durchzulassen, wenn ein Waechter nicht da ist.
+            P_AERIAL_HELPERS/P_AQUATIC_HELPERS
+              Sollte es gewuenscht sein, dass bestimmte Raeume z.B. nur 
+              fliegend erreicht werden koennen, oder dass man fuer einen 
+              bestimmten Ausgang tauchen koennen muss, sind diese 
+              Properties hilfreich, die im Spielerobjekt definiert sind 
+              und die dort aktuell registrierten Hilfsobjekte fuers 
+              Fliegen/Segeln und Tauchen enthalten.
+      RemoveSpecialExit(string|string* kmnd)
+            siehe RemoveExit()
+      NewDoor()
+            Fuegt dem Raum eine Tuer hinzu, die in einen zweiten Raum fuehrt,
+            und die der Spieler (ggf. mit einem Schluessel) oeffnen und 
+            schliessen kann.
+      
+      Um Raeume interessanter zu machen, kann man ihnen Details, die 
+      vom Spieler angeschaut werden koennen, einbauen:
+
+      AddDetail(string|string* keys, string descr)
+            Eine Beschreibung von Details, die vom Spieler angeschaut
+            werden koennen wird dem Raum gegeben. <keys> kann ein
+            String sein oder eine Liste von Strings. <descr> ist
+            die Beschreibung, die der Spieler erhaelt.
+      RemoveDetail(string|string* keys)
+            Entfernt ein Detail aus einem Raum. <keys> kann ein String
+            sein oder eine Liste von Strings.
+      AddSpecialDetail(string|string* keys, string function)
+            Im Prinzip wie AddDetail(), nur wird als zweites Argument
+            kein fester String angegeben, sondern eine Funktion, die
+            einen String zurueckgeben muss. Damit kann man variable
+            Details programmieren.
+      RemoveSpecialDetail(string|string* keys)
+            siehe RemoveDetail()
+      AddReadDetail(string|string* keys, string desc)
+            <desc> wird ausgegeben, wenn ein Spieler den <key> liest.
+            <keys> kann wieder ein String oder eine Liste von Strings
+            sein.
+      RemoveReadDetail(string|string* keys)
+            siehe RemoveDetail()
+      AddRoomMessage(string* msg, int prob, string|mixed *func)
+            Alle <prob> Sekunden wird aus einer Liste von Meldungen
+            (<msg>) zufaellig eine ausgesucht, die dann im Raum er-
+            scheint. Wenn das Argument <func> angegeben ist, wird
+            eine Funktion diesen Namens aufgerufen, der der Index
+            der ausgegebenen Meldung als Argument uebergeben wird.
+            Func darf auch einen Array von Funktionen enthalten.
+
+      AddCmd(string|string* cmd, string func, int flag)
+            Im Raum wird beim Kommando <cmd> (oder einem der Kommandos)
+            die Funktion <func> aufgerufen. <func> muss 1 zurueck-
+            geben, wenn die Funktion die Kombination aus Kommando
+            und Argumenten akzeptiert, ansonsten 0. Alles was ein
+            Spieler hinter <cmd> noch angibt, wird der Funktion als
+            Argument uebergeben. Wenn <flag> gesetzt ist, wird jedes
+            Kommando, das mit <cmd> beginnt akzeptiert.
+      RemoveCmd(string|string* cmd)
+            Entfernt ein Kommando aus dem Raum.
+            ACHTUNG: Bei Spielern, die zum Zeitpunkt des Funktions-
+            aufrufs noch im Raum sind, ist das Kommando noch definiert.
+            Also: Nur benutzen, wenn man genau weiss, was man tut.
+
+      AddItem(string filename, int refresh)
+            Ein Objekt mit Pfad <filename> wird erzeugt und in den
+            Raum bewegt, dabei gibt es vier verschiedene Modi, die
+            ueber das Argument <refresh> angegeben werden:
+            REFRESH_NONE: Das Objekt wird nur beim allerersten mal
+                  erzeugt, und dann nie wieder (erst beim reboot)
+            REFRESH_DESTRUCT: Ein neues Objekt wird erst erzeugt, 
+                  wenn das alte zerstoert ist. So kann man sicher
+                  gehen, dass nur ein Exemplar im Spiel ist.
+            REFRESH_REMOVE: Beim reset wird ein neues Objekt erzeugt,
+                  wenn sich das alte nicht mehr im Raum befindet.
+            REFRESH_ALWAYS: Bei jedem reset wird ein neues Objekt 
+                  erzeugt. VORSICHT: Kann zu riesigen Mengen von
+                  Objekten fuehren, wenn ein Raum lange nicht be-
+                  sucht wird.
+            Die Konstanten REFRESH_* sind in <rooms.h> definiert.
+
+      Auf die Properties P_EXITS, P_SPECIAL_EXITS, P_DETAILS, 
+      P_SPECIAL_DETAILS, P_READ_DETAILS, P_COMMANDS und P_ITEMS
+      sollte NICHT direkt zugegriffen werden.
diff --git a/doc/std/room.doku b/doc/std/room.doku
new file mode 100644
index 0000000..e1774c6
--- /dev/null
+++ b/doc/std/room.doku
@@ -0,0 +1,132 @@
+STANDARDOBJEKT FUER RAEUME:
+
+BENUTZUNG:
+	inherit "std/room";
+	
+	#include <properties.h>
+	#include <rooms.h>		// Fuer AddItem() und NewDoor()
+
+BESCHREIBUNG:
+	Ein Raum ist ein Objekt, dass von Spielern oder anderen Lebewesen
+	betreten werden kann. Er hat Lang- und Kurzbeschrreibungen von
+	innen und aussen (zum Beispiel Schiffe oder aehnliche Raeume in
+	Raeumen), die sich der Spieler je nach seinen Beduerftnissen
+	anzeigen lassen kann (kurz/lang-Modus).
+
+   Properties:
+
+	P_INT_SHORT
+		Kurzbeschreibung innerhalb des Raumes
+	P_INT_LONG
+		Langbeschreibung innerhalb des Raumes
+	P_SHORT
+		Kurzbeschriebung von aussen (nur noetig, wenn man den Raum
+		auch wirklich von aussen sehen kann)
+	P_LONG
+		Langbeschreibung von aussen (siehe P_SHORT)
+	Um Situationsbezogene Beschreibungen zu bekommen, kann man 
+	int_short(), int_long(), short(), long() ueberschreiben, oder
+	den process_string Mechanismus verwenden (siehe entsprechende
+	Dokumentation)
+
+	P_LIGHT
+		Lichtlevel des Raums (0 dunkel, 1 hell)
+	P_INDOORS
+		1 Wenn der Raum nicht im Freien ist
+	P_TRANSPARENT
+		Ist ungleich 0, wenn man in den Raum von aussen reinschauen
+		kann, oder von innen nach aussen
+	P_NO_TPORT
+		Zum verhindern von Teleportversuchen in oder aus dem Raum
+		(siehe auch /doc/properties.h)
+	P_NOMAGIC
+		Im Raum kann nicht gezaubert werden.
+
+   Funktionen:
+	AddExit(string|string* kmnd, string zielraum)
+		<kmnd> kann ein String sein oder eine Liste von Strings
+		mit den Kommandos mit denen der Spieler in <zielraum>
+		landen soll.
+	RemoveExit(string|string* kmnd)
+		<kmnd> ist ein String oder eine Liste von Strings, deren
+		Ausgaenge entfernt werden sollen. Dabei muss man etwas vor-
+		sichtig sein, da ein Spieler, der zum Zeitpunkt des Aufrufs
+		im Raum ist, die Aktion fuer sich noch definiert hat.
+		Also: Nur benutzen, wenn man weiss, was man tut!
+	AddSpecialExit(string|string* kmnd, string funktion)
+		<funktion> wird aufgerufen, wenn der Spieler das Kommando
+		<kmnd> tippt (oder eins der Kommandos, wenn <kmnd> eine
+		Liste ist). Nuetzlich zum Beispiel um einen Spieler nur
+		durchzulassen, wenn ein Waechter nicht da ist.
+	RemoveSpecialExit(string|string* kmnd)
+		siehe RemoveExit()
+	NewDoor()
+		siehe /doc/std/door
+	
+	Um Raeume interessanter zu machen, kann man ihnen Details, die 
+	vom Spieler angeschaut werden koennen, einbauen:
+
+	AddDetail(string|string* keys, string descr)
+		Eine Beschreibung von Details, die vom Spieler angeschaut
+		werden koennen wird dem Raum gegeben. <keys> kann ein
+		String sein oder eine Liste von Strings. <descr> ist
+		die Beschreibung, die der Spieler erhaelt.
+	RemoveDetail(string|string* keys)
+		Entfernt ein Detail aus einem Raum. <keys> kann ein String
+		sein oder eine Liste von Strings.
+	AddSpecialDetail(string|string* keys, string function)
+		Im Prinzip wie AddDetail(), nur wird als zweites Argument
+		kein fester String angegeben, sonder eine Funktion, die
+		einen String zurueckgeben muss. Damit kann man variable
+		Details programmieren.
+	RemoveSpecialDetail(string|string* keys)
+		siehe RemoveDetail()
+	AddReadDetail(string|string* keys, string desc)
+		<desc> wird ausgegeben, wenn ein Spieler den <key> liest.
+		<keys> kann wieder ein String oder eine Liste von Strings
+		sein.
+	RemoveReadDetail(string|string* keys)
+		siehe RemoveDetail()
+	AddRoomMessage(string* msg, int prob, string|string *func)
+		Alle <prob> Sekunden wird aus einer Liste von Meldungen
+		(<msg>) zufaellig eine ausgesucht, die dann im Raum er-
+		scheint. Wenn das Argument <func> angegeben ist, wird
+		eine Funktion diesen Namens aufgerufen, der der Index
+		der ausgegebenen Meldung als Argument uebergeben wird.
+		func darf auch einen Array von Funktionen enthalten. Es wird
+		dann zufaellig eine ausgewaehlt.
+
+	AddCmd(string|string* cmd, string func, int flag)
+		Im Raum wird beim Kommando <cmd> (oder einem der Kommandos)
+		die Funktion <func> aufgerufen. <func> muss 1 zurueck-
+		geben, wenn die Funktion die Kombination aus Kommando
+		und Argumenten akzeptiert, ansonsten 0. Alles was ein
+		Spieler hinter <cmd> noch angibt, wird der Funktion als
+		Argument uebergeben. Wenn <flag> gesetzt ist, wird jedes
+		Kommando, das mit <cmd> beginnt akzeptiert.
+	RemoveCmd(string|string* cmd)
+		Entfernt ein Kommando aus dem Raum.
+		ACHTUNG: Bei Spielern, die zum Zeitpunkt des Funktions-
+		aufrufs noch im Raum sind, ist das Kommando noch definiert.
+		Also: Nur benutzen, wenn man genau weiss, was man tut.
+
+	AddItem(string filename, int refresh)
+		Ein Objekt mit Pfad <filename> wird erzeugt und in den
+		Raum bewegt, dabei gibt es vier verschiedene Modi, die
+		ueber das Argument <refresh> angegeben werden:
+		REFRESH_NONE: Das Objekt wird nur beim allerersten mal
+			erzeugt, und dann nie wieder (erst beim reboot)
+		REFRESH_DESTRUCT: Ein neues Objekt wird erst erzeugt, 
+			wenn das alte zerstoert ist. So kann man sicher
+			gehen, dass nur ein Exemplar im Spiel ist.
+		REFRESH_REMOVE: Beim reset wird ein neues Objekt erzeugt,
+			wenn sich das alte nicht mehr im Raum befindet.
+		REFRESH_ALWAYS: Bei jedem reset wird ein neues Objekt 
+			erzeugt. VORSICHT: Kann zu riesigen Mengen von
+			Objekten fuehren, wenn ein Raum lange nicht be-
+			sucht wird.
+		Die Konstanten REFRESH_* sind in <rooms.h> definiert.
+
+	Auf die Properties P_EXITS, P_SPECIAL_EXITS, P_DETAILS, 
+	P_SPECIAL_DETAILS, P_READ_DETAILS, P_COMMANDS und P_ITEMS
+	sollte NICHT direkt zugegriffen werden.
diff --git a/doc/std/schluessel b/doc/std/schluessel
new file mode 100644
index 0000000..5a23db2
--- /dev/null
+++ b/doc/std/schluessel
@@ -0,0 +1,24 @@
+STANDARDOBJEKT FUER SCHLUESSEL:
+
+BENUTZUNG
+	inherit "/d/unterwelt/std/schluessel"
+
+BESCHREIBUNG   
+	Du erzeugst einen Schluessel der nur auf eine bestimmte Tuer
+	passt.
+
+    Funktionen:
+
+	create():
+		setzt ein paar Defaultwerte.
+
+	SetDoorKey( string str):
+		gibt den Schluessel eine spezielle Beschreibung, die 
+		auf die Tuer passen muss.
+
+	QueryDoorKey()
+		fragt den string des Schluessels ab.
+
+SIEHE AUCH:
+	tuer
+
diff --git a/doc/std/sequencer b/doc/std/sequencer
new file mode 100644
index 0000000..d9b17a3
--- /dev/null
+++ b/doc/std/sequencer
@@ -0,0 +1,58 @@
+Version 2.0 des Sequencers von Don Rumata 2.7.93
+
+Manchmal soll ein NPC (Monster) eine Serie von Taetigkeiten
+hintereinander weg ausgefuerht werden. Dieses kann man
+mit diesem Mudul relativ einfach realisieren.
+
+Folgende Ereignisse koennen eine Sequenz ausloesen:
+
+	TellEvent: Es wird etwas in dem Raum, in dem der npc sich
+		befindet, gesagt.
+	GiveEvent: Es wird dem npc etwas gegeben.
+
+Weitere Ereignisse koennen durch den Befehl Load() selber
+programmiert werden.
+
+Wie sieht ein Programm aus?
+
+	Ein Programm ist eine Liste von Befehlen.
+	Jeder Befehl ist eine Liste, bestehend aus einem Kommando
+	und einer Zahl.
+	Das Kommendo wird aehnlich der Befehle, die ein Spieler ein-
+	gibt ausgefuehrt.
+	Vorsicht: NPCs koennen nur einen Teil der Befehle, die ein
+	Spieler kann, dafuer aber immer 'echo' und 'emote'.
+	Die Zahl gibt die Anzahl der Sekunden an, in der der naechste
+	Befehl ausgefuehrt wird.
+
+Folgende Funktionen sind im Modul implementiert:
+
+	Vorbereiten von Funktionen, die eine Sequenz ausloesen:
+
+	RegisterTell( funktion, programm )
+		Wenn dem npc etwas gesagt wird, so wird die gesagte Meldung
+		an die Funktion uebergeben. Gibt die Funktionen nicht 0
+		zurueck, wird das Programm gestartet.
+		
+	RegisterGive( funktion, programm )
+		Wird dem npc etwas gegeben, so wird das Objekt an die
+		Funktion uebergeben. Gibt die Funktion nicht 0 zurueck, so
+		wird das Programm gestartet.
+
+	Load( programm )
+		Starte das angegebene Programm.
+
+Anederungen an bestehenden Std-Funktionen:
+
+	give_notify() gibt eine 1 zurueck, wenn das Objekt akzeptiert
+		wurde. (Es muss - falls gewuenscht - dann von Hand zuruech-
+		gegeben werden. (give_obj(ob,this_player())) in dieser
+		Funktion.
+
+	Mittels add_action() kann man im create() des NPCs eigene
+	Verben fuer den NPC einfuehren.
+
+Es kann immer nur eine Funktion (egal ob via Tell, Give oder Load) angemeldet
+sein. Es kann immer nur ein Programm gleichzeitig laufen.
+
+Ideen und Bugreports an Rumata
diff --git a/doc/std/thing b/doc/std/thing
new file mode 100644
index 0000000..445b462
--- /dev/null
+++ b/doc/std/thing
@@ -0,0 +1,205 @@
+STANDARD KLASSE:
+	"/std/thing" 
+
+BENUTZUNG:
+	inherit "/std/thing";
+
+	#include <thing.h>
+	#include <properties.h>
+
+PROPERTIES:
+	<thing/commands>
+		P_COMMANDS	-- Befehle assoziiert mit dem Objekt
+	<thing/description>
+		P_NAME		-- Name
+		P_NAME_ADJ	-- Namensadjektiv
+		P_SHORT		-- Kurzbeschreibung
+		P_LONG		-- Langbeschreibung
+		P_IDS		-- Identifikatoren (Feld von Zeichenketten)
+		P_ADJECTIVES	-- Adjektive zur Beschreibung
+	<thing/language>
+		P_ARTICLE	-- Artikel des Objekts
+		P_GENDER	-- Geschlecht des Objekts
+	<thing/moving>
+		P_NODROP	-- Kann nicht fallengelassen werden
+		P_NOGET		-- Kann nicht genommen werden
+	<thing/properties>
+		P_UID		-- User ID
+		P_EUID		-- Effektive User ID
+	<thing/restrictions>
+		P_WEIGHT	-- Gewicht des Objekts
+		P_TOTAL_WEIGHT	-- Gewicht inklusive des Inhalts
+	
+MAKROS:
+	<thing/properties>
+		F_VALUE		-- Propertywert
+		F_MODE		-- Propertymodus umschalten
+		F_MODE_AS	-- Propertymodus setzen
+		F_MODE_AD	-- Propertymodus loeschen
+		  SAVE		  -- Property wird gespeichert
+		  PROTECTED	  -- Property is geschuetzt
+		  SECURED	  -- Property kann nie mehr geaendert werden
+		  NOSETMETHOD	  -- Property besitzt keine Setzfunktion
+		F_SET_METHOD	-- Funktion zum setzen der Property
+		F_QUERY_METHOD	-- Funktion zum lesen der Property
+	<thing/language>
+		MALE, FEMALE, NEUTER 	-- Geschlechter
+		WER, WESSEN, WEM, WEN 	-- Fall
+		RAW 			-- fuer Namen ohne Artikel
+		SINGULAR, PLURAL 	-- Zeiten
+	
+FUNKTIONEN:
+	"/std/thing/commands":
+		varargs void AddCmd(mixed cmd, mixed func, int flag);
+		varargs void RemoveCmd(mixed cmd);
+	"/std/thing/description":
+		varargs int id(string str, int lvl);
+		void AddId(mixed str);
+		void AddAdjective(mixed str);
+		string name(int casus,int demon);
+	"/std/thing/language":
+		varargs string QueryArticle(int casus, int dem, int force);
+		varargs int SuggestArticle(string id);
+		varargs string QueryPossPronoun(mixed what, int casus, 
+		                                int number);
+		string QueryPronoun(int casus);
+		varargs string QueryDu(int casus,int gender, int zahl);
+		string QueryGenderString();
+		varargs string DeclAdj(string adj, int casus, int demon);
+	"/std/thing/properties":
+		varargs mixed Set(string name, mixed Value, int Type); 
+		varargs mixed Query(string name, int Type);
+		mixed SetProp(string name, mixed Value);
+		mixed QueryProp(string name);
+		void SetProperties(mapping props);
+		mapping QueryProperties();
+	"/std/thing/moving":
+		int move(mixed dest,int method);
+		varargs int remove();
+
+ERLAEUTERUNG:
+	"/std/thing" ist eine generelle Klasse fuer Objekte aller Art.
+	Es bietet generelle Funktionalitaet zur Erstellung von neuen
+	Klassen und Objekten. Sie kann mittels der zur Verfuegung
+	stehenden Funktionen konfiguriert werden:
+
+	** "/std/thing/commands":
+	varargs void AddCmd(mixed cmd, mixed func, int flag);
+	  Um dem Objekt die Moeglichkeit zu geben, auf Befehle zu reagieren,
+	  kann mit AddCmd() Kommandos definiert werden, die eine bestimmte
+	  Funktion (func) aufrufen. flag entscheidet darueber, ob das Kommando
+	  (cmd) abgekuerzt werden kann (flag = 1) oder nicht (flag = 0).
+
+	varargs void RemoveCmd(mixed cmd);
+	  Man kann die Kommandos jederzeit wieder mit der Funktion RemoveCmd()
+	  entfernen.
+
+	** "/std/thing/description":
+	varargs int id(string str, int lvl);
+	  Die Funktion id() behandelt die Identifikatoren eines Objektes, 
+	  welche in der Property P_IDS gespeichert sind. Jedesmal, wenn ein
+	  Objekt durch Kommandos wie "nimm", "lass fallen" etc referenziert
+	  werden soll, wird id() mit dem Namen des Objektes aufgerufen. Dabei
+	  werden dann die Elemente von P_IDS mit str verglichen und das Ergeb-
+	  nis (WAHR/FALSCH == 1/0) zurueckgegeben. lvl ist fuer die Behandlung
+	  von Lebewesen notwendig, siehe living.
+	
+	void AddId(mixed str);
+	  Mittels dieser Funktion kann ein oder mehrere neue Identifikatoren
+	  der Liste der bestehenden, Standard ist "ding", hinzugefuegt werden.
+
+	void AddAdjective(mixed str);
+	  Um den Objekten die Moeglichkeit zu geben, sich besser zu beschreiben
+	  oder zur besseren Identifizierung, kann man mit AddAdjective() dem
+	  Objekt naeher beschreibende Adjektive hinzufuegen. Diese sind in
+	  P_ADJECTIVES gespeichert.
+
+	string name(int casus,int demon);
+	  Diese Funktion liefert den Namen des Objektes mit allen zusaetzlichen
+	  Attributen im gewuenschten Fall (casus), demonstrativ (demon = 1) 
+	  oder nicht demonstrativ (demon = 0).
+
+	** "/std/thing/language":
+	varargs string QueryArticle(int casus, int dem, int force);
+	  Artikel im passenden Fall sowie demonst. bzw undemonst. zurueck-
+	  geben. force ueberschreibt das SetArticle-Flag.
+
+	varargs int SuggestArticle(string id);
+	  Empfehle einen Artikel fuer das Objekt, getestet wird, ob ausser
+	  diesem Objekt sich ein anderes Objekt mit der id im selben
+	  Raum befindet.
+
+	varargs string QueryPossPronoun(mixed what, int casus, int number);
+	  Gib ein Pronomen zurueck, das ausdrueckt, das ein Objekt diesem
+	  Objekt gehoert. Dabei ist what das Geschlecht des Objektes.
+
+	string QueryPronoun( casus );
+	  Er/Sie/Es u.ae. zurueckgeben.
+
+	varargs string QueryDu(int casus,int gender, int zahl);
+	  Du im passenden Fall zurueckgeben (siehe QueryArticle()).
+
+	string QueryGenderString();
+	  Gibt das Geschlecht in Worten zurueck.
+
+	varargs string DeclAdj(string adj, int casus, int demon); 
+	  Dekliniere Adjektive adj mit Casus casus.
+
+	** "/std/thing/properties":
+	varargs mixed Set(string name, mixed Value, int Type); 
+	  Setze einen Wert einer Property direkt, wobei der Typ des Wertes
+	  (Value) durch F_VALUE, F_MODE, F_SET_METHOD, F_QUERY_METHOD (Type)
+	  angegeben wird. 
+	  F_VALUE -- darf ein beliebiger Wert sein
+	  F_MODE  -- muss eine Zahl sein (SAVE, PROTECTED, SECURED, 
+	             NOSETMETHOD)
+	  F_SET_METHOD, F_QUERY_METHOD -- 0 oder eine Closure
+
+	varargs mixed Query(string name, int Type);
+	  Lies den Wert einer Property aus. Dabei gibt Type an, welchen Wert
+	  (F_VALUE, F_MODE, F_SET_METHOD, F_QUERY_METHOD) man auslesen will.
+
+	mixed SetProp(string name, mixed Value);
+	  Setze den Wert einer Property. Dabei wird, falls vorhanden, der Wert
+	  noch durch die F_SET_METHOD behandelt (z.B. Typueberpruefung).
+	  Dies sollte die Standardmethode zum Setzen einer Property sein!
+  
+	mixed QueryProp(string name);
+	  Lies den Wert einer Property, wobei der eigentliche Wert durch die,
+	  falls vorhanden, F_QUERY_METHOD behandelt wird. Als Beispiel dient
+	  hier die Behandlung des Gesamtgewichts, welches durch Abfragen von
+	  P_TOTAL_WEIGHT ausgelesen werden kann; hierbei errechnet die 
+	  F_QUERY_METHOD von P+_TOTAL_WEIGHT erst das totale Gewicht.
+	  Dies sollte die Standardmethode sein um eine Property auszulesen!
+
+	void SetProperties(mapping props);
+	  Diese Funktion kann die in props gespeicherten Properties im Objekt
+	  unterbringen. Dabei werden schon vorher als PROTECTED oder SECURED
+	  gekennzeichnete Properties NICHT ueberschrieben.
+
+	mapping QueryProperties();
+	  Liefert ein mapping, welches von SetProperties() behandelt werden
+	  kann.
+
+	** "/std/thing/moving":
+	int move(mixed dest,int method);
+	  Jedesmal, wenn ein Objekt bewegt werden soll, wird die Funktion
+	  move() aufgerufen, welche dann das eigentliche Bewegen ausfuehrt.
+	  Dazu muss der Funktion ein Ziel (dest) als Zeichenkette oder als
+	  Objekt und eine Methode der Bewegung uebergeben werden.
+	
+	varargs int remove();
+	  Wird ein Objekt zerstoert, wird die Funktion remove() aufgerufen.
+	  Rueckgabewert 1 bedeutet Erfolg und 0 Misserfolg der Zerstoerung.
+
+VERERBUNGSBAUM:
+	thing
+	  |-thing/commands
+	  |-thing/description
+	  |-thing/language
+	  |-thing/moving
+	  |-thing/properties
+	  `-thing/restrictions
+
+SIEHE AUCH:
+	properties, closures 
diff --git a/doc/std/transport b/doc/std/transport
new file mode 100644
index 0000000..3000c97
--- /dev/null
+++ b/doc/std/transport
@@ -0,0 +1,264 @@
+> FUNKTIONSWEISE VON TRANSPORTERN <
+Version 1.0 (04.05.1993) von Rumata
+===================================
+
+
+INHALT:
+======
+
+	1.	Allgemeines
+	2.	Properties
+	3.	Haltestellen
+	4.	Steuerung
+	5.	Betreten und verlassen
+	6.	Extras
+	7.	Kommandos in Trnasportern
+
+
+1. ALLGEMEINES
+==============
+
+	Ein Transporter ist ein Raum mit besonderen Eigenschaften.
+	Waehrend normale Raume miteinnder starr verbunden sind,
+	kann dieser Raum seine Verbindung zu anderen Raeumen mit
+	der Zeit aendern.
+
+	Jeder Transporter besitzt einen 'Kurs' den er abfaehrt; nach der
+	letzten 'Haltestelle' beginnt der Kurs wieder von Vorne.
+	Will man einen Kurs setzen, der entlang einer Strecke hin-
+	und zurueck fuehrt, so muss man jede Haltestelle einmal fuer
+	den Hinweg und einmal fuer den Rueckweg einfuegen.
+
+	Ein Beispiel, wie man einen solchen Transporter programmiert,
+	ist in /doc/beispiele/wolke.c zu sehen (und zu laden :-).
+
+2. PROPERTIES
+=============
+
+	P_ENTERMSG
+		Array mit zwei Meldungen in der Art von msgin und
+		msgout.  Die erste Meldung ist fuer den Raum, den der
+		Spieler verlaesst, und die zweite fuer den Transporter,
+		in den er geht.
+
+	P_LEAVEMSG
+		Array mit zwei Meldungen, eine fuer den Transporter, den
+		er verlaesst, und eine fuer den Raum, in den er kommt.
+
+	P_ENTERFAIL
+		Meldung an ein Wesen, wenn den vollen Transporter
+		betreten will. Ist die Prop. ein Array, so wird das erste
+		Element als Meldung an das Wesen, das zweite als Meldung
+		an die Mitspieler im Raum geschickt. Ist die Property
+		eine Closure, wird diese ausgefuehrt, wenn ein Spieler
+		vergeblich versucht, den Transporter zu betreten.
+
+	P_LEAVEFAIL
+		Meldung an ein Wesen, wenn es ausserhalb der Anlegezeiten
+		den Transporter verlassen will. Ist die Prop. ein Array,
+		so wird das erste Element als Meldung an das Wesen, das
+		zweite als Meldung an die Mitspieler im Transporter
+		geschickt. Ist die Property eine Closure, wird diese
+		ausgefuehrt, wenn ein Spieler vergeblich versucht, den
+		Transporter zu verlassen.
+
+	P_ARRIVEMSG
+		Ein Array mit zwei Meldungen. Das erste Element ist die
+		Meldung, die die Wesen im Transporter bekommen. Die
+		zweite Meldung ist fuer die Wesen in dem Raum, an dem
+		der Transporter anlegt. 
+
+	P_DEPARTMSG
+		Dito fuer das Ablegen.
+
+	P_MAX_PASSENGERS
+		Numerischer Wert fuer die maximale Anzahl von Wesen, die
+		sich in dem Transporter aufhalten duerfen.
+		0 bedeutet unbeschaenkte Spielerzahl.
+
+
+3. HALTESTELLEN
+===============
+
+	Es gibt 3 Sorten von Haltestellen:
+
+	1.) Raeume als Haltestellen.
+
+	FUNKTION:
+	
+		AddRoute( raum, verweil, next );
+		oder
+		AddRoute( raum, verweil, next, code );
+
+	PARAMETER:
+
+		raum	- Raum, an dem der Transporter halten soll.
+		verweil	- Zeit in Sekunden, die der Transporter in dem
+			  Raum verbleibt, bis er weiterfaehrt.
+		next	- Zeit in Sekunden bis zur naechsten Halte-
+			  stelle.
+
+		code	- Text, der von der Funktion QueryArrived
+			  zurueckgegeben wird, wenn der Transporter
+			  an dieser Haltestelle angelegt hat.
+			  Wird dieser Parameter nicht angegeben, wird
+			  ein leerer String als code gesetzt.
+
+	2.) Meldungen als Haltestellen.
+
+	FUNKTION:
+
+	      AddMsg( text, next );
+
+	PARAMETER:
+
+		text	- Text, der Meldung, die in dem Transporter
+			  ausgegeben wird.
+		next	- Zeit in Sekunden bis zur naechsten Halte-
+			  stelle.
+
+	3.) Funktionsaufrufe als Haltestellen.
+
+	FUNKTION:
+
+		AddFun( fun, next );
+
+	PARAMETER:
+
+		fun	- Name einer Funktion, die im Transporter
+			  aufgerufen wird.
+		next	- Zeit in Sekunden bis zur naechsten Halte-
+			  stelle.
+
+4. STEUERUNG
+============
+
+	FUNKTION
+
+		Start();
+		oder
+		Start(nummer);
+
+	BESCHREIBUNG:
+
+		Der Transporter soll sofort an der Haltestelle mit
+		der angegebenen Nummer (keine Nummer heisst an der ersten)
+		anlegen und von da ab seinen Kurs fahren.
+
+	FUNKTION:
+
+		Halt();
+
+	BESCHREIBUNG:
+
+		Halte die Fahrt an. Der Transporter bleibt stehen, wo
+		er ist.
+
+
+5. BETRETEN UND VERLASSEN
+=========================
+
+	Der Transporter hat keine Verben programmiert, mit denen man
+	den Transporter betreten oder verlassen kann.
+	Dafuer muessen mit AddCmd() Verben eingefuehrt werden, die
+	auf selbstgeschriebene Funktionen zugreifen.
+
+	FUNKTION:
+
+		Enter();
+
+	BESCHREIBUNG:
+
+		Teste, ob fuer dun aktuellen Spieler (this_player())
+		noch Platz im Transporter ist und ob er sich ausserhalb
+		des Transporters befindet. Wenn ja, bewege ihn in den
+		Transporter. Wenn der Transporter eine Reaktion (Bewegen des
+		Spielers oder Ueberlauf), so gib eine 1 zurueck sonst eine 0.
+
+		Wenn der Transporter nicht da (also unsichtbar) ist, tue fuer
+		die Spieler ausserhalb des Transporters so,
+		als ob das Verb nicht definiert wurde.
+
+		Dieser Wert kann im allgemeinen direkt als returnwert benutzt
+		werden.
+
+	FUNKTION:
+
+		Leave();
+
+	BESCHREIBUNG:
+
+		Wenn der Momentane Spieler nicht im Transporter ist, so gib
+		eine Fehlermeldung aus. Anderenfalls teste, ob der
+		Transporter an einen Raum angelegt hat. Wenn nein, gebe
+		die LEAVEFAIL Meldung aus; und wenn alles ok ist, so
+		bewege den Spieler aus dem Transporter.
+
+6. EXTRAS
+=========
+
+	FUNKTION:
+
+		QueryArrived();
+
+	BESCHREIBUNG:
+
+		Gebe den Code des Raumes zurueck, an dem der Transporter
+		gerade anliegt. Hat der Raum keinen Code, gebe einen
+		Leerstring zurueck. Liegt der Transporter an keinem Raum
+		an, so gebe 0 zurueck.
+
+		Diese Funktion bietet sich an um mittels process_string
+		die Ankunfts- und Abfahrtsmeldungen abwechslungsreich
+		zu gestalten.
+
+	FUNKTION:
+
+		QueryPassengers(),
+
+	BESCHREIBUNG:
+
+		Gebe eine Liste mit allen Lebewesen, die sich auf/in dem
+		Transporter befinden, zurueck.
+
+	FUNKTION:
+
+		RemoveRoute();
+
+	BESCHREIBUNG:
+
+		Halte den Transporter an und loesche dessen Kurs.
+
+7. KOMMANDOS IN TRANSPORTERN
+============================
+
+	Da sich der Transporter in dem Raum befindet, in dem er angelegt
+	hat, sind alle Kommandos des Transporters auch dort verfuegbar.
+	Selbst wenn der Transporter abgelegt hat, steht er noch immer
+	unsichtbar dort herum.
+
+	Deshabl muss in den Kommandos vorsorge grtroffen werden, dass nur
+	die richtigen Spieler (die drinnen und die draussen) die richtigen
+	Kommandos ausfuehren koennen.
+
+	KOMMANDOS FUER SPIELER AUSSERHALB:
+
+		Es muss abgetestet werden, ob der Spieler nicht im
+		Transporter ist, und ob der Transporter angelegt hat.
+
+		if( environment(this_player())==this_object() 
+			|| !QueryArrived() ) return 0;
+
+	KOMMANDOS FUER SPIELER INNERHALB:
+
+		Abtesten, ob der Spieler wirklich im Transport ist.
+
+		if( environment(this_player())!=this_object() )
+			return 0;
+
+		Vorsicht auch bei AddExits innerhalb des Transporters,
+		aber daran arbiete ich noch... :-)
+
+	Die Funktionen Enter() und Leave() haben diese Funktionalitaet
+	eingebaut.
+
diff --git a/doc/std/tuer b/doc/std/tuer
new file mode 100644
index 0000000..489fd84
--- /dev/null
+++ b/doc/std/tuer
@@ -0,0 +1,42 @@
+STANDARDOBJEKT FUER TUEREN:
+
+BENTUZUNG:
+	inherit "std/tuer";
+
+	#include <tuer.c>
+	
+BESCHREIBUNG:
+	Basisklasse fuer alle Tueren im Spiel. Sie ist von /std/thing
+	abgeleitet.
+
+    Funktionen:
+
+	AddDoor2( strin short,
+		  string long,
+		  mixed id,
+		  mixed dest,
+		  string com,
+		  int flags,
+		  string key,
+		  string func,
+		  object obj )
+
+		Erzeugt eine neue Tuer, wobei die Parameter folgendes angeben:
+
+		short 	= Kurzbeschreibung der Tuer
+		long	= Ausfuehrliche Beschreibung der Tuer
+		id	= Name[n] der Tuer
+		dest	= Kommando zum Durchschreiten der Tuer, z.B. 'norden'
+
+		Optionale Parameter:
+
+		flags	= Flags aus tuer.h
+		key	= String, der im Schluessel definiert sein muss, damit
+			  er 'passt'.
+		func	= Funktion die beim Durchschreiten der Tuer in obj
+			  aufgerufen werden soll.
+		obj	= Objekt in dem func aufgerufen werden soll.
+
+SIEHE AUCH:
+	schluessel
+
diff --git a/doc/std/unit b/doc/std/unit
new file mode 100644
index 0000000..3c75059
--- /dev/null
+++ b/doc/std/unit
@@ -0,0 +1,102 @@
+Units
+
+DEFINIERT IN: 
+        /std/unit.c
+
+BESCHREIBUNG:
+        Das Unit-Objekt kann dazu verwendet werden, um groessere Mengen
+        eines Objektes - wie Muenzen - zu erzeugen.
+
+        Das grundlegende Konzept ist, das Unit-Objekte nicht mehr nur 
+        ueber ihre Namen, sondern auch ueber ihre Menge angesprochen 
+        werden kann.
+
+        So wird das id() der Muenzen nicht nur 'muenzen' sondern auch 
+        '3 muenzen' verstehen und auswerten koennen.
+
+        move() kann Teile des ganzen Unit-Objekts bewegen, ein neuer
+        Clone wird erzeugt und diesem der verbleibende Rest der Menge
+        zugewiesen. Nach erfolgreichem move() schaut das Unit-Objekt am
+        Zielort, ob dort evtl. bereits Units des gleichen Typs vorhanden
+        sind und vereinigt sich ggf. mit ihnen, in dem das alte Unit-
+        Objekt zerstoert wird.
+
+        Unit-Objekte werden in einigen Dinger anders programmiert, dazu
+        gehoert folgendes:
+
+        P_SHORT                 ES WIRD KEINE P_SHORT GESETZT!
+
+        P_AMOUNT                Die Menge des Unit-Objekts 'von Haus aus',
+                                also beim Clonen (daher meistens 1)
+
+        P_NAME                  Bei Unit-Objekten kann hier ein String-Array
+                                in der Form ({ SINGULAR_NAME,PLURAL_NAME })
+                                angegeben werden
+
+        SetCoinsPerUnits        Wieviel ist eine bestimmte Menge wert
+        NICHT P_VALUE
+
+        SetGramsPerUnits        Wieviel wiegt eine bestimmte Menge
+        NICHT P_WEIGHT
+
+        AddSingularId		String-Array mit den Singular-IDs 
+        AddPluralId		String-Array mit den Plural-IDs
+
+        zusaetzlich koennen natuerlich IDs per AddId vergeben werden
+
+        Weiterhin verfuegen Unit-Objekte ueber die Moeglichkeit eines
+        automatischen Zerfalls. Dieser ist steuerbar ueber die Props
+        P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_QUOTA, P_UNIT_DECAY_FLAGS,
+        P_UNIT_DECAY_MIN. Hierbei wird der Zerfall von der Blueprint des
+        Unit-Objektes gesteuert, was als Zerfallsmaster fungiert, weil Clones
+        nicht unbedingt immer nen Reset haben muessen. Die entsprechenden
+        Props sollten daher in der Blueprint konfiguriert werden. (s. Manpages 
+        und Beispiel)
+
+BEISPIELE:
+        Wir basteln uns ein ganz einfaches Unit-Objekt:
+
+        inherit "/std/unit";
+
+        protected void create()
+        {
+          if(!clonep(this_object())) {
+              set_next_reset(-1);
+              return;
+          }
+          ::create();
+          SetProp(P_LONG,"Das ist die kleine Leiche einer Ameise.\n");
+          SetProp(P_NAME,({ "Ameisenleiche","Ameisenleichen" }));
+          SetProp(P_AMOUNT,1);       // es handelt sich um 1 einziges Objekt
+          SetCoinsPerUnits(20,10);   // 10 Objekte sind 20 Muenzen wert
+          SetGramsPerUnits(1,10);    // 10 Objekte wiegen 1 Gramm
+          
+          AddSingularId( ({ "leiche","ameisenleiche" }) );
+          AddPluralId( ({ "leichen","ameisenleichen" }) );
+          
+          AddId("\n-MeineAmeisenleiche");
+        }
+
+        Wir basteln nun ein Unitobjekt, was zerfallen soll:
+        inherit "/std/unit";
+        protected void create() {
+            // Konfig s.o. ...
+            if (!clonep()) {
+              // Zerfall alle 3h
+              SetProp(P_UNIT_DECAY_INTERVAL, 3*3600);
+              // es zerfallen jeweils 10%
+              SetProp(P_UNIT_DECAY_QUOTA, 1000);
+              // es sollen min. 10 Einheiten jeweils uebrigbleiben
+              SetProp(P_UNIT_DECAY_MIN, 10);
+            }
+        }
+
+SIEHE AUCH:
+        P_AMOUNT, P_NAME, P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_QUOTA, 
+        P_UNIT_DECAY_MIN, P_UNIT_DECAY_FLAGS
+        DoDecay(), doDecayMessage(), SetGramsPerUnits(), SetCoinsPerUnits(), 
+        AddSingularId(), AddPluralId(), QueryCoinsPerUnits(),
+        QueryGramsPerUnits()
+        /std/unit.c
+
+14.10.2007, Zesstra
diff --git a/doc/std/util b/doc/std/util
new file mode 100644
index 0000000..8bf3527
--- /dev/null
+++ b/doc/std/util
@@ -0,0 +1,34 @@
+DEFINIERT IN: 
+     /std/*.c
+
+BESCHREIBUNG:
+     Diese Mangepage beschreibt kein Einzelobjekt, sondern eine Sammlung von
+     Programmen.
+     Im Verzeichnis /std/util/ liegen mehrere Helferklassen, die Funktionen
+     bereitstellen, die nicht nur einem Objekt verwendet werden.
+
+     Momentan sind dies:
+     executer.c   - stellt eine Funkton execute_anything() beret.
+     input.c      - stellt eine Funtion intput() bereit, welche inptu_to()
+                    kapselt.
+     pager.c      - Stellt die Funktion More() und ihre Helfer bereit.
+     ringbuffer.c - Stellt einen Ringpuffer und die notwendigen Verwaltungs-
+                    funktionen bereit.
+
+     Ringbuffer.c:
+     ------------
+     Dies ist ein Puffer (Array) einer bestimmten Groesse. Sobald er voll ist
+     wird automatisch die jeweils aeltesten Daten ueberschrieben, sobald etwas
+     neues hineingeschrieben wird. Ein Ringpuffer mit einer Groesse von 30
+     speichert also die letzten 30 hineingeschriebenen Objekte.
+     * CreateRingBuffer(): erstellt einen neuen Ringpuffer.
+     * ResizeRingBuffer(): aendert die Groesse eines Ringpuffers.
+     * RingBufferPut(): schreibt ein neues Datum in den Puffer.
+     * RingBufferGet(): liefert die Daten des Ringpuffers zurueck.
+
+SIEHE AUCH:
+     CreateRingBuffer, ResizeRingBuffer, RingBufferPut, RingBufferGet
+
+LETZTE AeNDERUNG:
+23.05.2008, Zesstra
+
diff --git a/doc/std/vererbungsbaeume b/doc/std/vererbungsbaeume
new file mode 100644
index 0000000..2df21cc
--- /dev/null
+++ b/doc/std/vererbungsbaeume
@@ -0,0 +1,293 @@
+
+  Vererbungsbaeume der Basis-MUDlib
+  =================================
+
+Einfache Gegenstaende
+---------------------
+
+Die einfachsten Objekte der Basis-MudLib. Die Module, die von thing.c
+geerbt werden, enthalten die wichtigsten Funktionen und treten auch in
+den anderen Standardobjekten immer wieder auf.
+
+Da die Ausgabe des Namens eines Objektes (dieser wird in den
+description-Modulen definiert) immer mit einer Deklination verbunden ist,
+findet man in jedem Objekt, welches ein description.c erbt, auch
+thing/language.
+
+thing
+  |- thing/properties    | Verwaltungsfunktionen des Property-Systems
+  |- thing/description   | Aussehen, Name, IDs des Objektes
+  |- thing/moving        | Bewegen und Zerstoeren des Objektes
+  |- thing/language      | Deklination von Namen, Adjektiven etc.; Pronomina
+  |- thing/commands      | vom Objekt definierte Kommandos
+  `- thing/restrictions  | Gewicht: standardmaessig 1Kg
+
+
+Ruestungen
+----------
+
+Bis auf thing/restrictions.c verfuegt armour.c ueber saemtliche Funktionalitaet
+die auch thing.c zur Verfuegung stellt. Zusaetzlich gibt es noch ein Modul,
+welches die Ruestung erst zur Ruestung macht: armour/combat.c
+
+armour                  | evtl. ein "(angezogen") an Kurzbeschreibung haengen
+  |- thing/properties   | Auch Ruestungen haben Eigenschaften
+  |- thing/description  | Aussehen, Name, IDs der Ruestung
+  |- thing/commands     | Kommandos sind auch moeglich
+  |- armour/moving      | Beim Bewegen/Zerstoeren: Ruestung ausziehen...
+  |    `- thing/moving  | ...und dann erst Bewegen/Zerstoeren
+  |- armour/combat      | Ruestungsklasse/-typ, Kampffunktion
+  `- thing/language     | und noch was zum deklinieren.
+
+
+Waffen
+------
+
+Wie Ruestungen, unterscheiden sich Waffen von einfachen Gegenstaenden im
+wesentlichen nur durch die Kampffunktionen.
+
+weapon                  | evtl. ein "(gezueckt)" an Kurzbeschreibung haengen
+  |- weapon/moving      | Waffe beim Bewegen/Zerstoeren erst wegstecken...
+  |    `- thing/moving  | ...und dann erst bewegen/zerstoeren
+  |- thing (s.o.)       | Ansonsten alle thing-Eigenschaften
+  `- weapon/combat      | Waffenklasse/-art, Schadenstyp, Kampffunktion
+
+
+Lichtquellen
+------------
+
+Lichtquellen sind (im Sinne der MudLib) normale Gegenstaende, die zusaetzlich
+die Eigenschaft haben, dass sie leuchten koennen (und auch verbrennen koennen).
+
+lightsource       | Alles, was zum Leuchten noetig ist
+  `- thing (s.o.) | ansonsten ein ganz normaler Gegenstand
+
+
+unit-Objekte
+------------
+
+unit-Objekte sind Gegenstaende, bei denen es sinnvoll ist, dass ein einzelnes
+Objekt eine gewisse Anzahl von gleichartigen Objekten repraesentiert. Das
+beste Beispiel hierfuer ist das liebe Geld: statt 1000 einzelner Muenzen im
+Inventory zu haben, hat man nur ein einziges Geldobjekt, das einer Menge von
+1000 Muenzen entspricht (die bei Kauf-/Verkaufsaktionen um eine entsprechende
+Menge erniedrigt oder erhoeht wird).
+Hierdurch wird a) die Uebersichtlichkeit erhoeht und b) natuerlich massig
+Speicher gespart.
+
+unit               | alle unit-Eigenschaften (Gewicht, Menge, Bewegen, ...)
+  `- thing (s.o.)  | ansonsten sind es normale Gegenstaende
+
+
+Spellbooks
+----------
+
+Fuer Gildenprogrammierer ist dies das Grundobjekt fuer das Zauberverzeichnis
+der Gilde.
+ACHTUNG: Obwohl thing.c geerbt wird, ist das Spellbook nicht zum clonen und
+"unter den Arm klemmen" gedacht! Vielmehr stellt thing.c hier im wesentlichen 
+nur das Property- und das Sprachmodul zur Verfuegung!
+
+spellbook                | Allgemeine Funktionen fuer Zaubersprueche
+  |- thing (s.o.)        | hier nur wg. Properties und Deklinationen
+  `- restriction_checker | fuer Einschraenkungen beim Zaubern
+
+
+Behaelter
+---------
+
+Die bisher beschriebenen Objekte kann man zwar mit sich herumtragen (ausser
+Spellbooks), aber man kann nichts hineinstecken. Hierzu sind einige weitere
+Funktionen noetig, die container.c zur Verfuegung stellt.
+Im wesentlichen sind das in container/restrictions.c Funktionen zum Aus-
+waehlen von Objekten im Behaelter, zum Testen, ob der Behaelter noch weitere
+Objekte aufnehmen kann (gewichtsabhaengig) und zur Ermittlung des Gesamt-
+gewichts des Behaelters.
+In container/description.c wird der Inhalt des Behaelters in eine Beschreibung
+umgewandelt.
+
+container
+  |- thing/properties        | DAS zentrale Modul...
+  |- thing/moving            | Bewegen/Zerstoeren des Behaelters
+  |- thing/commands          | Kommandos sind moeglich
+  |- container/description   | Beschreibung des Inhalts
+  |    `- thing/description  | Lang- und Kurzbeschreibung
+  |- thing/language          | Deklinationsmodul
+  `- container/restrictions  | Gesamtgewicht, Objektauswahl
+       `- thing/restrictions | Standardgewicht: 1Kg
+
+Leichen
+-------
+
+Leichen sind Behaelter mit der zusaetzlichen Eigenschaft, dass sie mit der
+Zeit zerfallen. Ausserdem geben sie ggf. noch eine Meldung ueber den
+Moerderkanal aus
+
+corpse                | Zerfallen, Moerdermeldung
+  `- container (s.o.) | sonst normaler Behaelter
+
+
+Raeume und ihre Abkoemmlinge
+----------------------------
+
+Raeume sind prinzipiell Behaelter mit Lang- und Kurzbeschreibung von INNEN
+und weiteren untersuchbaren Details (auch lesbare Details) sowie
+Ausgaengen und der Moeglichkeit vordefinierte Objekte im Raum zu plazieren.
+
+room
+  |- thing/properties     | Eigenschaften des Raumes
+  |- thing/language       | das obligatorische Sprachmodul
+  |- room/moving          | nur Zerstoeren; KEIN(!) Bewegen
+  |- room/restrictions    | Raeume werden nie voll
+  |    `- container/restrictions  | sonst die gleiche Funktionalitaet wie
+  |	    `- thing/restrictions | beim normalen Behaelter
+  |- room/description     | Raumbeschreibung, Details, etc.
+  |    `- container/description   | Beschreibung des Inhalts
+  |	    `- thing/description  | Beschreibung von aussen (selten sichtbar)
+  |- room/exits           | Verwaltung der Ausgaenge
+  |- room/commands        | notify_fail()s fuer "lies", "suche", "such"
+  |    `- thing/commands  | sonst normale Kommandobehandlung
+  |- room/items           | Verwaltung von Objekten, die im Raum sein sollen
+  `- room/doors           | Tueren (besondere Ausgaenge)
+
+
+Die Kneipe erweitert den Standardraum um Funktionen zur Definition der
+Speisen und Getraenke sowie um Befehle zum Bestellen und Ausgeben.
+
+pub
+  `- room (s.o.)
+
+
+Auch der Laden baut direkt auf dem Standardraum auf. Hier werden noch die
+ueblichen Ein- und Verkaufsbefehle zur Verfuegung gestellt.
+Jeder Laden benoetigt zusaetzlich einen Speicher, in dem verkaufte Objekte
+gelagert werden. Wenn der Laden schon beim ersten Betreten ueber ein
+gewisses Warensortiment verfuegen soll, kann man die mit AddItem()-Aufrufen
+im Speicher bewerkstelligen.
+
+laden
+  `- room (s.o.)
+
+store
+  |- thing/properties  | noetig fuer room/items.c
+  `- room/items        | vordefinierte Objekte im Speicher
+
+
+Die Post ist von der Programmierung her genau so zu behandeln wie ein
+normaler Raum. Die Postkabinen werden automatisch zur Verfuegung gestellt;
+man braucht sich in der Hinsicht um nichts zu kuemmern.
+
+post
+  `- (...) room
+
+
+Schiffe und aehnliche Transporter werden durch "bewegliche" Raeume realisiert.
+So hat man alle Beschreibungsmoeglichkeiten eines Raumes zur Verfuegung und
+kann (wie bei der Jolle geschehen) Ausgaenge in weitere Raume des Transporters
+legen (diese sind normale Raeume, KEINE Transporter!).
+Desweiteren sind Transporter die einzigen (Standard-)Raume, bei denen man
+auch die aeussere Lang- und Kurzbeschreibung zu sehen bekommt, weil man
+nicht nur in einem Transporter sein kann, sondern auch daneben stehen kann.
+
+transport         | Funktionen zur Festlegung der Route, An- und Ablegen
+  |- room (s.o.)  | die normalen Raumfunktionen
+  `- thing/moving | und hier steckt die Beweglichkeit
+
+
+Gilden
+------
+
+Gilden gibt es in zwei Ausfuehrungen: einmal als einfaches Gildenobjekt, dann
+aber auch als Gildenraum (wie zB. die Abenteurergilde).
+Waehrend das Gildenobjekt (gilden_ob) Funktionen zum Lernen von Faehigkeiten
+und Zauberspruechen, dem Gildenein- und -austritt sowie zum gildeninternen
+Aufstieg zur Verfuegung stellt (was zB. auch von einem NPC ausgeuebt werden
+koennte), verfuegt der Gildenraum zusaetzlich noch ueber Funktionen zum
+normalen Stufenaufstieg aufgrund von Abenteuer- und Erfahrungspunkten, die
+Questliste und die Kostenabfrage.
+
+gilden_ob                | Ein-/Austritt, Lernen, Gildenaufstieg
+  `- restriction_checker | Beschraenkungen bei obigen Aktionen
+
+gilden_room
+  |- gilde               | Stufenaufstieg, Questliste, Kosten
+  |    `- room (s.o.)    | normale Raumfunktionen
+  `- gilden_ob (s.o.)    | Gildenaufstieg etc.
+
+NPCs
+----
+
+Das Opfer. Zumindest meistens...
+
+npc
+  |- thing/properties            | Eigenschaften des NPC
+  |- living/description          | Ausgabe des Gesundheitszustandes...
+  |    `- container/description  | ...zusaetzlich zu seinem Inhalt...
+  |	    `- thing/description | ...und seiner Beschreibung
+  |- living/life                 | Die Lebensfunktionen, Essen, Trinken, Gift
+  |- living/attributes           | Die Verwaltung der Stats
+  |- living/moving               | Bewegen von Lebewesen
+  |- living/skills               | Funktionen fuer Faehigkeiten und Sprueche
+  |    `- living/std_skills      | und einige Standardfaehigkeiten
+  |- npc/combat                  | NPC-spezifische Kampffunktionen
+  |    `- living/combat          | der Kampf an sich
+  |- npc/chat                    | Sprueche a la Andy
+  |- npc/comm                    | Basiskommunikation: "sag", "echo", "emote"
+  |- container/restrictions      | wie bei Behaeltern
+  |    `- thing/restrictions
+  |- thing/language              | obligatorisch...
+  |- npc/info                    | Antworten auf Fragen
+  |- npc/put_and_get             | Reaktion auf erhaltene Gegenstaende
+  |    `- living/put_and_get     | Geben und Nehmen von Objekten
+  `- npc/guard                   | fuer Wach-NPCs
+
+Der intelligente NPC befindet sich noch in der Entwicklung.
+
+inpc
+  |- npc (s.o.)  | Erst mal ein ganz normaler NPC...
+  |- inpc/nobank | ...der gegen Bankzweitis vorgehen kann...
+  |    `- player/moneyhandler | ...und selbst Geld mitschleppt; ...
+  |- select      | ...die beste Ausruestung erkennt und auch benutzt...
+  `- boozing     | ...und in der Kneipe die beste Heilmoeglichkeit findet!
+
+
+Spieler- und Magiershell
+------------------------
+
+shells/magier                  | Hier auch noch Spielershells:
+  |- player/base               | Einloggen, Grundfunktionen
+  |    |- player/restrictions  | Maximale Zuladung (Staerke), InsertHooks
+  |    |    `- container/restrictions   | Maximalgewicht, Zuladungstest
+  |    |	 `- thing/restrictions  | Defaultgewicht
+  |    |- living/attributes    | Stats
+  |    |- living/combat        | Kampffunktionen
+  |    |- living/put_and_get   | Nehmen und Geben von Objekten
+  |    |- thing/properties     | DAS zentrale Modul...
+  |    |- thing/language       | Deklinationen
+  |    |- player/description   | Waffe/Ruestungen ausgeben
+  |    |    `- living/description           | Gesundheitszustand anzeigen
+  |    |	 `- container/description   | Ermittlung des Inhalts
+  |    |	      `- thing/description  | Kurz- und Langbeschreibung; IDs
+  |    |- player/moving        | Bewegen/Zerstoeren: Zusatzchecks
+  |    |    `- living/moving   | Bewegen/Zerstoeren von Lebewesen
+  |    |- player/life          | Zusatzchecks bei Lebensfunktionen
+  |    |    `- living/life     | allgemeine Lebensfunktionen
+  |    |- player/comm          | allgemeine Kommunikation
+  |    |    `- player/channel  | Kommunikation ueber die Kanaele
+  |    |- player/moneyhandler  | Geldverwaltung (auch fuer NPCs geeignet)
+  |    |- player/command       | Aliase, History, Parser
+  |    |- living/skills        | allg. Faehigkeitsfunktionen
+  |    |    `- living/std_skills | Standardfaehigkeiten
+  |    |- player/quests        | Verwaltung geloester Abenteuer
+  |    |- player/potion        | Verwaltung gefundener Zaubertraenke
+  |    |- player/soul          | Seelenkommandos (hilfe verben ;)
+  |    |- player/viewcmd       | Untersuchen etc.
+  |    |- more                 | More() fuer lange Texte
+  |    `- user_filter          | Hilfsmodul fuer "kwer in muenster" etc.
+  |                               | Ab hier: Magiershell
+  |- shells/filesys/filesys         | allgemeines Modul zur Dateibehandlung
+  |    |- shells/filesys/manual     | der "hilfe"-Befehl der Magier
+  |    |- shells/filesys/primitives | low-level-Routinen
+  |    |- shells/filesys/asynchron  | zur Vermeidung von Lags
+  |    `- shells/filesys/make       | komfortables updaten von Objekten
+  `- player/objects                 | Objekte clonen, updaten, zerstoeren
diff --git a/doc/std/virtual_compiler b/doc/std/virtual_compiler
new file mode 100644
index 0000000..ac8ec3d
--- /dev/null
+++ b/doc/std/virtual_compiler
@@ -0,0 +1,82 @@
+Was sind 'virtuelle Objekte'?
+=============================
+Virtuelle Objekte sind Objekte fuer die es keine explizite Quelldatei gibt.
+Ansonsten sind die Objekte (fast) genauso wie alle anderen auch.
+
+Was macht ein Virtual Compiler?
+===============================
+Wenn der Driver ein Objekt "/pfad/objekt" laden soll, guckt er erstmal nach,
+ob es so ein File (/pfad/objekt.c) auf der Platte gibt. Wenn ja, laedt er es
+ganz normal. Wenn nicht, passiert folgendes:
+
+1. Der Driver fragt den Master der Mudlib nach dem Objekt.
+2. Der Master guckt im Verzeichnis "/pfad/" nach, ob es ein virtual_compiler.c
+   dort gibt. Wenn ja, wird dieses virtual_compiler.c gefragt, ob es sich 
+   dafuer zustaendig fuehlt, ein Objekt mit dem Namen "/pfad/objekt" zu 
+   erzeugen.
+3. Wenn sich der VC fuer zustaendig fuehlt, clont er ein Objekt (z.B. sein
+   Standardobjekt, "stdob.c"), konfiguriert es evtl. noch ein bisschen und 
+   gibt es an den Master zurueck. Das erzeugte Objekt heisst an dieser Stelle
+   z.B. "/pfad/stdob#42" (weil es ein Clon von "/pfad/stdob" ist).
+4. Der Master gibt dieses erzeugte Objekt an den Driver zurueck.
+5. Der Driver benennt das vom Master erhaltene Objekt "/pfad/stdob#42" um in
+   das gewuenschte Objekt "/pfad/objekt". Von diesem Moment an ist es, als ob
+   es ein File "/pfad/objekt.c" gaebe, was dieses Objekt definiert.
+
+Das ist grundsaetzlich das, was ein VC macht.
+
+Was macht der VC in /std/?
+==========================
+Erstmal das oben beschriebene. Fuer welchen Pfad sich dieser VC zustaendig
+fuehlt und welches Objekt er jeweils clonen soll, wird per P_COMPILER_PATH und
+P_STD_OBJECT konfiguriert.
+Zusaetzlich fuehrt er besagte Liste seiner erzeugten Objekte, damit bei einem
+'ls' auf das Verzeichnis diese Objekte mit angezeigt werden.
+Weiterhin zerstoert er alle diese Objekte in seinem eigenen Remove.
+Ausserdem hat er 2 Funktionen, mit denen er entscheiden kann, ob er fuer ein
+bestimmtes angefragtes Objekt zustaendig ist, Validate() und
+QueryValidObject() und eine Funktion CustomizeObject(), die einem frisch
+geclonten Objekt sagen kann, welchen Namen es spaeter einmal haben soll (s.
+jeweilige Manapages).
+
+Wie baut man sich seinen eigenen VC?
+====================================
+Sagen wir, ihr wollt einen VC bauen, der jedem Spieler seinen eigenen Raum
+gibt, damit jeder Spieler in diesem Raum ein Monster allein erlegen muss,
+ohne dass andere Spieler mit drin sind.
+Dann braucht ihr zuerst mal einen Raum, der die Vorlage fuer alle VC-Raeume
+sein soll, z.B. std_arena.c. Diesen legt ihr in das Verzeichnis, wo der VC hin
+soll, z.B. /d/region/magier/vc/.
+In diesem Verzeichnis legt ihr nun ein File virtual_compiler.c an, welches
+/std/virtual/v_compiler erbt.
+Im create() setzt ihr nun P_COMPILER_PATH auf "/d/region/magier/vc/" und
+P_STD_OBJECT auf "/d/region/magier/vc/std_arena".
+Soll euer VC keine Para-Raeume erzeugen, setzt ihr P_PARA auf ({}).
+Sodann muesst ihr ein Validate() formulieren (s. Manpage), welches prueft, ob
+ein spaeter gewuenschtes Objekt den richtigen Namen (ohne Pfad) hat, z.B.
+'arena|spielername' und in diesem Fall genau diesen Namen zurueckliefert und
+in anderen Faellen 0.
+Das wars. Zumindest in diesem einfachen Fall seid ihr im wesentlichen fertig.
+Ihr koennt einen Spieler nun mit
+  pl->move("/d/region/magier/vc/arena|spielername",M_GO)
+in 'seinen' persoenlichen Raum bewegen.
+
+Bitte beachtet allerdings noch die Hinweise und Beschreibungen in den Manpages
+zu den einzelnen Funktionen und Properties.
+
+
+Beispiele:
+==========
+1. /doc/beispiele/virtual/zesstra/virtual_compiler.c
+   VC, der jedem Spieler einen eigenen Raum gibt. Da hier der Inhalt aller
+   Raeume gleich ist (alle Spieler sollen gleiche Bedingungen haben), ist
+   keine Konfigurierung mit Hilfe von CustomizeObject() noetig.
+
+2. /doc/beispiele/virtual/hate/vr_compiler.c
+   Dies ist ein Beispiel fuer einen sehr allgemeinen VC, der es 
+   erlaubt anzugeben in welchem Bereich sich die x und y Koordinaten befinden
+   und dann Raeume erzeugt, welche Ausgaenge in alle vier Himmelsrichtungen 
+   haben.
+
+-----------------------------------------------------------------------------
+27.10.2007, Zesstra
diff --git a/doc/std/weapon b/doc/std/weapon
new file mode 100644
index 0000000..3894c02
--- /dev/null
+++ b/doc/std/weapon
@@ -0,0 +1,78 @@
+ STANDARDKLASSE:
+	"/std/weapon"
+
+ BENUTZUNG:
+        inherit "std/weapon";
+
+	#include <properties.h>
+	#include <combat.h>
+
+ PROPERTIES:
+     Grundlegend:
+        P_WC		setzbar: Waffenklasse == Angriffsstaerke
+	P_WEAPON_TYPE	setzbar: Waffentyp
+	P_DAM_TYPE	setzbar: Schadenstypen
+	P_NR_HANDS	setzbar: Anzahl benoetigter Haende
+
+     Besondere Attribute und Anforderungen fuer Traeger:
+	P_RESTRICTIONS	setzbar: Anforderungen an Traeger
+	P_M_ATTR_MOD	setzbar: Attributmodifikator fuer Traeger
+	P_CURSED	setzbar: Verfluchung (nicht wegsteckbar)
+	P_PARRY		setzbar: Parierwaffe ?
+	P_AC		setzbar: Schutzfaktor einer Parierwaffe
+
+     Meldungen und Zeitpunkte:
+	P_EQUIP_TIME	enthaelt den Zeitpunkt des Anziehens
+	P_LAST_USE	enthaelt den Zeitpunkt des letzten Angriffs damit
+	P_WIELDED	enthaelt den Traeger
+	P_WIELD_MSG	setzbar: eigene Zueckmeldung
+	P_UNWIELD_MSG	setzbar: eigene Wegsteckmeldung
+
+     Dynamisches Verhalten in Kampf und beim Anziehen:
+	P_WIELD_FUNC	setzbar: Objekt mit Zueckfunktion "WieldFunc()"
+	P_UNWIELD_FUNC	setzbar: Objekt mit Wegsteckfunktion "UnwieldFunc()"
+	P_HIT_FUNC	setzbar: Objekt mit Angriffsfunktion "HitFunc()"
+
+     Zusaetzliche Eigenschaften:
+	P_DAMAGED	enthaelt den Ausmass des Schadens an Waffe
+	P_QUALITY	setzbar: Qualität/Haltbarkeit der Waffe
+	P_EFFECTIVE_AC	setzbar: falls HitFunc WC nicht sichbar aendert
+	P_EFFECTIVE_WC	setzbar: falls Parieren AC nicht sichbar aendert
+
+     Zusaetzlich sind alle Properties aus /std/thing verfuegbar, also
+     bitte auch folgende setzen:
+	P_MATERIAL	setzbar: Zusammensetzung
+	P_SIZE		setzbar: Groesse
+	P_WEIGHT	setzbar: Gewicht
+
+ MAKROS:
+     Gueltige Waffen- und Schadenstypen (definiert in "/sys/combat.h").
+
+ BESCHREIBUNG:
+     Basisklasse fuer alle Waffen im Spiel. Sie ist von /std/thing
+     abgeleitet und enthaelt alle zusaetzliche Funktionalitaet
+     fuer den Kampf.
+
+     Vor der Programmierung von Waffen sollte /doc/wiz/waffen
+     gelesen werden. Die Regeln darin sind verbindlich und sollten nur
+     in Ausnahmefaellen und mit Absprache mit dem Erzmagier fuer 
+     Waffen/Ruestungen/Monster ueberschritten werden.
+
+ VERERBUNGSBAUM:
+     [/std/weapon]
+     ..... [/std/thing/properties]
+     ..... [/std/thing/language]
+     ..... [/std/thing/commands]
+     ..... [/std/thing/restrictions]
+     ..... [/std/weapon/moving]
+     .......... [/std/thing/moving]
+     ..... [/std/weapon/description]
+     .......... [/std/thing/description]
+     ..... [/std/weapon/combat]
+
+
+ SIEHE AUCH:
+     P_WEAPON, P_PARRY_WEAPON, P_TOTAL_WC, P_TOTAL_AC, P_UNWIELD_TIME
+     Attack(), Defend(), /doc/wiz/waffen
+
+ 20 Maerz 2004 Gloinson