Automatisch erzeugte Manpages.

Damit nicht jeder sphinx auf dem Rechner haben muss,
behalten wir bis auf weiteres die aus den .rst
erzeugten Manpoages auch im Repo.

Change-Id: Id556c0d11cf5f79659d8350952ce1c014d81ea44
diff --git a/doc/lfun/create b/doc/lfun/create
index 9582609..03fc91a 100644
--- a/doc/lfun/create
+++ b/doc/lfun/create
@@ -1,78 +1,104 @@
+
 create()
+********
 
-FUNKTION:
-     protected void create();
-     void create();
 
-DEFINIERT IN:
-     allen Standardobjekten
+FUNKTION
+========
 
-ARGUMENTE:
-     keine
+   protected void create();
+   void create();
 
-BESCHREIBUNG:
-     Diese Funktion wird aufgerufen, wenn ein Objekt geladen oder geclont
-     wird.
-     In dieser Funktion wird das Objekt initialisiert und konfiguriert.
-     Waehrend des create() kann es einen this_player()/this_interactive()
-     geben, muss aber nicht!
-     Im create() hat das Objekt noch kein environment().
-     create() wird nur gerufen, wenn das Objekte geclont oder explizit geladen
-     wird. Wenn es aufgrund eines inherit in einem anderen Objekt vom Driver
-     geladen wird, wird das create() nicht ausgefuehrt (s. create_super()).
 
-RUeCKGABEWERT:
-     keiner
+DEFINIERT IN
+============
 
-BEMERKUNGEN:
-     Erbt man von anderen Objekten, so besteht die erste Aktion innerhalb
-     von create() normalerweise darin, in diesen Objekten create()
-     aufzurufen.
-     Die Funktion kann protected oder static sein (aber nicht private). Es
-     duerfte fuer die meisten Objekte sinnvoll sein, create() protected zu
-     deklarieren.
+   allen Standardobjekten
 
-     Um Speicher zu sparen, kann man bei Blueprints von der Konfigurierung
-     absehen (siehe Beispiel). Dies sollte man allerdings nicht bei Objekten
-     machen, von denen keine Clones erzeugt werden sollen (zB. bei Raeumen). 
 
-     Man sollte bei Abbruch des create() in BP unbedingt set_next_reset(-1);
-     rufen, da sonst die (nicht konfigurierte) BP resetten kann und dann
-     buggt.
+ARGUMENTE
+=========
 
-BEISPIELE:
-     Ein Gegenstand wuerde wie folgt konfiguriert:
+   keine
 
-     inherit "std/thing";
 
-     #include <properties.h>
+BESCHREIBUNG
+============
 
-     create()
-     {
-       // Wenn wir die Blueprint sind: NICHT konfigurieren!
-       // Bei normalen Raeumen oder Transportern sind diese beiden
-       // Zeilen wegzulassen!!!
-       if (!clonep(this_object())) {
-           set_next_reset(-1);    // wichtig, damit die BP nicht resettet.
-           return;
-       }
+   Diese Funktion wird aufgerufen, wenn ein Objekt geladen oder geclont
+   wird.
+   In dieser Funktion wird das Objekt initialisiert und konfiguriert.
+   Waehrend des create() kann es einen this_player()/this_interactive()
+   geben, muss aber nicht!
+   Im create() hat das Objekt noch kein environment().
+   create() wird nur gerufen, wenn das Objekte geclont oder explizit geladen
+   wird. Wenn es aufgrund eines inherit in einem anderen Objekt vom Driver
+   geladen wird, wird das create() nicht ausgefuehrt (s. create_super()).
 
-       // Ansonsten die allgemeinen Eigenschaften von /std/thing
-       // konfigurieren...
-       ::create();
 
-       // ...und nun unsere speziellen Eigenschaften:
-       SetProp(P_NAME, "Muell");
-       SetProp(P_SHORT, "Muell");
-       SetProp(P_LONG, "Voellig unnuetzer Muell!\n");
-       SetProp(P_ARTICLE, 0);
-       SetProp(P_VALUE, 0);
-       SetProp(P_GENDER, MALE);
+RUeCKGABEWERT
+=============
+
+   keiner
+
+
+BEMERKUNGEN
+===========
+
+   Erbt man von anderen Objekten, so besteht die erste Aktion innerhalb
+   von create() normalerweise darin, in diesen Objekten create()
+   aufzurufen.
+   Die Funktion kann protected oder static sein (aber nicht private). Es
+   duerfte fuer die meisten Objekte sinnvoll sein, create() protected zu
+   deklarieren.
+
+   Um Speicher zu sparen, kann man bei Blueprints von der Konfigurierung
+   absehen (siehe Beispiel). Dies sollte man allerdings nicht bei Objekten
+   machen, von denen keine Clones erzeugt werden sollen (zB. bei Raeumen).
+
+   Man sollte bei Abbruch des create() in BP unbedingt set_next_reset(-1);
+   rufen, da sonst die (nicht konfigurierte) BP resetten kann und dann
+   buggt.
+
+
+BEISPIELE
+=========
+
+   Ein Gegenstand wuerde wie folgt konfiguriert:
+
+   inherit "std/thing";
+
+   #include <properties.h>
+
+   create()
+   {
+     // Wenn wir die Blueprint sind: NICHT konfigurieren!
+     // Bei normalen Raeumen oder Transportern sind diese beiden
+     // Zeilen wegzulassen!!!
+     if (!clonep(this_object())) {
+         set_next_reset(-1);    // wichtig, damit die BP nicht resettet.
+         return;
      }
 
-SIEHE AUCH:
-     create(L), reset(L)
-     hook(C), create(H), create_ob(H), create_super(H, reset(H)
-     create(A), reset(A)
-----------------------------------------------------------------------------
+     // Ansonsten die allgemeinen Eigenschaften von /std/thing
+     // konfigurieren...
+     ::create();
+
+     // ...und nun unsere speziellen Eigenschaften:
+     SetProp(P_NAME, "Muell");
+     SetProp(P_SHORT, "Muell");
+     SetProp(P_LONG, "Voellig unnuetzer Muell!\n");
+     SetProp(P_ARTICLE, 0);
+     SetProp(P_VALUE, 0);
+     SetProp(P_GENDER, MALE);
+   }
+
+
+SIEHE AUCH
+==========
+
+   create(L), reset(L)
+   hook(C), create(H), create_ob(H), create_super(H, reset(H)
+   create(A), reset(A)
+
 22.10.2007, Zesstra