diff --git a/doc/beispiele/misc/bsptransporter1.c b/doc/beispiele/misc/bsptransporter1.c
index 3e26020..d3c5475 100644
--- a/doc/beispiele/misc/bsptransporter1.c
+++ b/doc/beispiele/misc/bsptransporter1.c
@@ -26,23 +26,24 @@
   SetProp(P_LIGHT, 1 );
   SetProp(P_TRANSPARENT,1);
   // Man soll auf(in) die Wolke und von ihr herunter schauen koennen.
-    
+
   /*** Meldungen, die Transporter geben koennen ***/
-  
+
   SetProp( P_DEPARTMSG, ({
-    "Die Wolke steigt in die Luft.\n", 
+    "Die Wolke steigt in die Luft.\n",
     "Die Wolke fliegt davon.\n"
   }) );
   // Die erste Meldung ist fuer Leute auf der Wolke.
   // Die zweite fuer Leute in dem Raum, in dem die Wolke ankommt.
-      
-  SetProp( P_ARRIVEMSG, ({
-    "Die Wolke naehert sich dem Boden von @@QueryArrived@@.\n",
-    "Eine kleine Wolke schwebt herab.\n"
-  }) );
+
+  Set( P_ARRIVEMSG, function string* () {
+    return ({
+      sprintf("Die Wolke naehert sich dem Boden von %s.\n",QueryArrived()),
+      "Eine kleine Wolke schwebt herab.\n"});
+  }, F_QUERY_METHOD);
   // Die erste Meldung ist fuer Leute auf der Wolke.
   // Die zweite fuer Leute in dem Raum, aus dem die Wolke abreist.
-    
+
   SetProp( P_ENTERMSG, ({
     "steigt auf die Wolke",
     "kommt auf die Wolke"
@@ -50,7 +51,7 @@
   // Die erste Meldung ist fuer den Raum, aus dem der Spieler kommt.
   // (=Raum). Die zweite Meldung ist fuer Spieler in dem Raum, in
   // den der Spieler geht (=Transporter).
-	
+
   SetProp( P_LEAVEMSG, ({
     "steigt von der Wolke",
     "steigt von der Wolke"
@@ -58,7 +59,7 @@
   // Die erste Meldung ist fuer den Raum, aus dem der Spieler kommt.
   // (=Transporter). Die zweite Meldung ist fuer Spieler in dem Raum,
   // in den der Spieler geht (=Raum).
-      
+
   SetProp( P_LEAVEFAIL, "Die Wolke schwebt viel zu hoch" );
   // Meldung, die kommt, wenn ein Spieler den Transporter verlassen
   // will, aber dieser an keinem Raum angelegt hat.
@@ -108,7 +109,7 @@
   AddMsg( "Die Wolke beginnt zu sinken.\n", 10 );
   // Nach dem Letzten Haltepunkt wird der Kurs wieder von vorn
   // befahren.
- 	
+
   Start();
   // Lasse den Transporter am ersten dieser Haltepunkte starten.
 }
@@ -116,7 +117,7 @@
 steige(str)
 {
   string arg, arg2;
-  
+
   if (sscanf( str, "auf %s", arg ) > 0 && id(old_explode(arg," ")[0]))
     return Enter();
   // Wenn sicher ist, dass der Spieler die Wolke BEsteigen will,
@@ -128,5 +129,3 @@
   // Verben sollten nach Enter() oder Leave() keine weiteren Befehle
   // enthalten.
 }
-
-
diff --git a/doc/lfun/AddInfo b/doc/lfun/AddInfo
index c684fe0..76c6e1c 100644
--- a/doc/lfun/AddInfo
+++ b/doc/lfun/AddInfo
@@ -6,8 +6,8 @@
 FUNKTION
 ========
 
-   varargs void AddInfo( frage, meldung
-      [, indent [, [silent [, casebased] ] ] );
+   public varargs void AddInfo(string|string* key, string|closure info,
+                  string indent, int|string silent, string|closure casebased);
 
 
 DEFINIERT IN
@@ -19,22 +19,23 @@
 ARGUMENTE
 =========
 
-   string/string* frage
-      Schluesseltext(e) auf die Informationen gegeben werden sollen.
+   string|string* frage
+      Schluesselwoerter, fuer die der NPC eine Antwort geben soll,
+      wenn man ihn danach fragt
 
-   string/closure meldung
+   string|closure meldung
       Information, die gegeben werden soll; wenn 'meldung' eine
       Closure ist, wird der gerufenen Funktion nichts uebergeben.
 
-   string indent
+   string indent    (optional)
       Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
 
-   int/string silent
+   int|string silent    (optional)
       Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
 
-   string/closure casebased
-      Closure mit Returnwert string oder int. Bekommt nichts
-      uebergeben.
+   string|closure casebased   (optional)
+      Closure mit Returnwert string oder int. Der Funktion werden
+      keine Argumente uebergeben.
 
 
 BESCHREIBUNG
@@ -79,7 +80,7 @@
 
    Die Strings von 'silent' und 'meldung' werden geparsed. Dabei
    koennen die @[...]-Tags von replace_personal() verwendet werden,
-   Objekt 1 ist this_player(). Ersetzte String am Satzanfang werden
+   Objekt 1 ist this_player(). Ersetzte Strings am Satzanfang werden
    automatisch gross geschrieben. AddInfo() konvertiert die alten
    Schluesselworte @WER, @WESSEN, @WEM, @WEN zu denen von
    replace_personal(), jedoch nicht in den Rueckgabe- werten von
@@ -265,4 +266,4 @@
    Interna:
       GetInfoArr() , do_frage()
 
-7. Mar 2017 Gloinson
+24.09.2020, Arathorn
diff --git a/doc/lfun/AddMoney b/doc/lfun/AddMoney
index 8f15cc6..6518215 100644
--- a/doc/lfun/AddMoney
+++ b/doc/lfun/AddMoney
@@ -69,10 +69,10 @@
 BEISPIELE
 =========
 
-   #include <zentralbank.h>
+   #include <bank.h>
 
    // gib ihm Geld
-   int money = ZENTRALBANK->Withdraw(50);
+   int money = ZENTRALBANK->WithDraw(50);
    this_player()->AddMoney(money);
 
    // nimm ihm Geld
@@ -86,9 +86,11 @@
 SIEHE AUCH
 ==========
 
-   Geldhandling:      QueryMoney(L) Zentralbank:       PayIn(L),
-   WithDraw(L) Sonstiges:         move(L), /items/money.c,
-   /sys/moving.h, /sys/money.h, /sys/bank.h
-   /std/container/moneyhandler.c
+   Geldhandling:  QueryMoney(L)
+   Zentralbank:   PayIn(L), WithDraw(L)
+   Sonstiges:     move(L),
+   /items/money.c
+   /sys/moving.h, /std/container/moneyhandler.c
+   /sys/money.h, /sys/bank.h
 
 18.02.2013, Zesstra
diff --git a/doc/lfun/AddRoomMessage b/doc/lfun/AddRoomMessage
index 82c2c99..47e2b60 100644
--- a/doc/lfun/AddRoomMessage
+++ b/doc/lfun/AddRoomMessage
@@ -66,7 +66,7 @@
        verlassen haben
 
      * ist manuell nur ueber Loeschen der Nachrichten umsetzbar,
-       also mit "AddRoomMessage((string)0, 0, (string)0);"
+       also mit "AddRoomMessage(0, 0, 0);"
 
    In Funktionen, die durch AddRoomMessage() ausgeloest werden, darf
    this_player() nicht verwendet werden, da die call_out()-Kette den
@@ -130,7 +130,7 @@
    }
 
    public int action_laerm(string str) {
-     AddRoomMessage((string)0, 0, (string)0);
+     AddRoomMessage(0, 0, 0);
 
      this_player()->ReceiveMsg(
        "Du schreist dir kurz die Seele aus dem Leib. Alle Tiere "
diff --git a/doc/lfun/AddSpecialInfo b/doc/lfun/AddSpecialInfo
index efc3067..be61558 100644
--- a/doc/lfun/AddSpecialInfo
+++ b/doc/lfun/AddSpecialInfo
@@ -6,23 +6,31 @@
 FUNKTION
 ========
 
-   varargs void AddSpecialInfo( frage, meldung
-                         [, indent [, [silent [, casebased] ] ] );
+   public varargs void AddSpecialInfo(string|string* keys, string functionname,
+                  string indent, int|string silent, string|closure  casebased);
 
 
 ARGUMENTE
 =========
 
-   string/string* frage
-      Schluesseltext(e) auf die Informationen gegeben werden sollen.
-   string/closure function
-      Methodenname im NPC/Closure
-   string indent
-      Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
-   int/string silent
-      Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
-   string/closure casebased
-      Funktionsname oder Closure mit Returnwert string oder int.
+   string|string* frage
+     Schluesselwoerter, fuer die der NPC eine Antwort geben soll, wenn
+     man ihn danach fragt
+
+   string functionname
+     Name der Funktion, die gerufen werden soll, um den Informationstext
+     des NPCs zu ermitteln. Der gerufenen Funktion werden keine Argumente
+     uebergeben.
+
+   string indent    (optional)
+     Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
+
+   int|string silent    (optional)
+     Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
+
+   string|closure casebased   (optional)
+     Closure mit Returnwert string oder int.
+     Der Funktion werden keine Argumente uebergeben.
 
 
 DEFINIERT IN
@@ -83,6 +91,19 @@
 SIEHE AUCH
 ==========
 
-   AddInfo(L), RemoveInfo(L)
+   Verwandt:
+      AddInfo(), RemoveInfo()
 
-7.Apr 2004 Gloinson
+   Props:
+      P_PRE_INFO
+
+   Files:
+      /std/npc/info.c
+
+   Loggen:
+      P_LOG_INFO
+
+   Interna:
+      GetInfoArr() , do_frage()
+
+24.09.2020, Arathorn
diff --git a/doc/lfun/Attack b/doc/lfun/Attack
index 08a0c20..1e958de 100644
--- a/doc/lfun/Attack
+++ b/doc/lfun/Attack
@@ -18,8 +18,8 @@
 BESCHREIBUNG
 ============
 
-   Der Feind wird der Staerke der Waffe (bzw. der Haende) entsprechend
-   stark angegriffen.
+   Der Feind wird entsprechend der Angriffsstaerke der Waffe (P_WC) bzw. der
+   Haende (P_HANDS[1]) angegriffen.
 
 
 RUECKGABEWERT
@@ -33,10 +33,10 @@
 
    Diese Funktion gibt die Angriffsmeldung aus.
    Falls mit blossen Haenden angegriffen wird, ist die Staerke
-   (2*Staerke_der_Haende + 10*A_STR)/3
+   (2 * P_HANDS[1] + 10 * A_STR)/3
 
 
 SIEHE AUCH
 ==========
 
-   "Defend", "QueryDamage"
+   Defend(), QueryDamage()
diff --git a/doc/lfun/CheckResistance b/doc/lfun/CheckResistance
index bcf64ca..52bfe23 100644
--- a/doc/lfun/CheckResistance
+++ b/doc/lfun/CheckResistance
@@ -6,7 +6,7 @@
 FUNKTION
 ========
 
-   CheckRessistance(string* dam_type_list)
+   public float CheckResistance(string* dam_type_list)
 
 
 ARGUMENTE
@@ -34,4 +34,4 @@
 SIEHE AUCH
 ==========
 
-   "Defend"
+   Defend(), P_RESISTANCE_STRENGTHS
diff --git a/doc/lfun/DefendFunc b/doc/lfun/DefendFunc
index 5338a9f..00bfc91 100644
--- a/doc/lfun/DefendFunc
+++ b/doc/lfun/DefendFunc
@@ -61,46 +61,43 @@
 BEISPIELE
 =========
 
-   Eine Ruestung, die bei Angriffen mit Feuer ihre volle Staerke
-   entfaltet und bei Angriffen durch Geister geschwaecht wird:
+   Eine Ruestung, die bei Angriffen mit Feuer ihre volle Staerke entfaltet
+   und bei Angriffen durch Geister geschwaecht wird:
 
-   protected void create() {
+   protected void create()
+   {
+     ::create();
 
-      ::create();
-
-      SetProp(P_ARMOUR_TYPE, AT_ARMOUR); SetProp(P_AC, 20); ... // Die
-      DefendFunc() ist in der Ruestung selbst definiert
-      SetProp(P_DEFEND_FUNC, this_object());
-
+     SetProp(P_ARMOUR_TYPE, AT_ARMOUR);
+     SetProp(P_AC, 20);
+     ...
+     // Die DefendFunc() ist in der Ruestung selbst definiert
+     SetProp(P_DEFEND_FUNC, this_object());
    }
 
-   public int DefendFunc(string* dtyp, mapping spell, object enemy) {
+   public int DefendFunc(string* dtyp, mapping spell, object enemy)
+   {
+     int prot;
 
-      int prot;
+     // Zuerst fragen wir den Angriff durch Feuer ab:
+     if (member(dtyp, DT_FIRE) >= 0)  // Feuer gehoert zu den Schadenstypen
+       prot = 5 + random(10); // Das ergibt maximal 14. Zusammen mit P_AC
+                              // kommt man also maximal auf 14+20 = 34,
+                              // liegt also unter der fuer AT_ARMOUR
+                              // geltenden Obergrenze
 
-      // Zuerst fragen wir den Angriff durch Feuer ab: if
-      (member(dtyp, DT_FIRE) >= 0)  // Feuer gehoert zu den
-      Schadenstypen
+     // Und jetzt der Geistertest
+     if (enemy->QueryProp(P_RACE) == "Geist" ||
+         enemy->is_class_member(CL_GHOST))
+       prot -= random(10);
 
-         prot = 5 + random(10); // Das ergibt maximal 14. Zusammen mit
-         P_AC
-            // kommt man also maximal auf 14+20 = 34, // liegt also
-            unter der fuer AT_ARMOUR // geltenden Obergrenze
-
-      // Und jetzt der Geistertest if (enemy->QueryProp(P_RACE) ==
-      "Geist" ||
-
-            enemy->is_class_member(CL_GHOST))
-
-         prot -= random(10);
-
-      // Der Rueckgabewert wird auf den aus P_AC errechneten Wert
-      draufgeschlagen return prot;
-
+     // Der Rueckgabewert wird auf den aus P_AC errechneten Wert
+     // draufgeschlagen
+     return prot;
    }
 
 
 SIEHE AUCH
 ==========
 
-   P_DEFEND_FUNC, *QueryDefendd* /std/armour/combat.c
+   P_DEFEND_FUNC, QueryDefend() /std/armour/combat.c
diff --git a/doc/lfun/QueryArmourByType b/doc/lfun/QueryArmourByType
index 20fcab5..5c9da6f 100644
--- a/doc/lfun/QueryArmourByType
+++ b/doc/lfun/QueryArmourByType
@@ -10,7 +10,7 @@
 FUNKTION
 ========
 
-   mixed QueryArmourByType(string type)
+   object|object*|mapping QueryArmourByType(string type)
 
 
 DEFINIERT IN
@@ -31,17 +31,27 @@
 
    Abfrage, ob das Lebewesen eine Ruestung des angegebenen Typs traegt.
 
-   Zurueckgegeben wird je nach Tragestatus und <type>:
-   * 0, falls das Lebewesen die gesuchte Ruestungsart nicht traegt
-   * im Erfolgsfall das Ruestungsobjekt
-   * falls <type> AT_MISC ist:
-     * ({}), wenn es keine AT_MISC-Ruestung traegt
-     * ein Array von AT_MISC-Ruestungen
-   * falls <type> 0 ist: ein Mapping, das diese Informationen mit dem
-     Ruestungstypen als Schluessel enthaelt:
-     ([AT_MISC: ({[object], ...}),
-       AT_...: <object>,
-       ... ])
+
+RUECKGABEWERTE
+==============
+
+   Zurueckgegeben wird abhaengig vom Argument <type> folgendes:
+
+   1) Ist <type> ein Typ, von dem man nur eine Ruestung tragen kann:
+      *  0, falls das Lebewesen die gesuchte Ruestungsart nicht traegt,
+      *  ansonsten das Ruestungsobjekt
+
+   2) Ist <type> AT_MISC:
+      *   ein Array mit allen AT_MISC-Ruestungen
+      *   ({}), wenn das Lebewesen keine AT_MISC-Ruestung traegt
+
+   3) Ist <type> 0:
+      * Ein Mapping mit den Ruestungstypen als Schluessel der folgenden
+      Form:
+         ([AT_MISC:  ({object misc1, ... }),
+           AT_CLOAK: object cloak,
+           AT_...:   object ...,
+           ... ])
 
 
 BEMERKUNG
diff --git a/doc/lfun/create_default_npc b/doc/lfun/create_default_npc
index 09c3a14..fac3fe2 100644
--- a/doc/lfun/create_default_npc
+++ b/doc/lfun/create_default_npc
@@ -47,7 +47,10 @@
    wurden, werden durch die neuen Werte ersetzt.
 
    Ab einem Aufruf mit Level 20 werden P_XP = 202000 gesetzt, also ein
-   Kill-Stup vergeben (siehe P_XP).
+   Kill-Stups vergeben (siehe P_XP).
+
+   P_HP und P_SP werden auf dieselben Werte wie P_MAX_HP bzw. P_MAX_SP
+   eingestellt.
 
 
 BEISPIEL
diff --git a/doc/props/P_MAGIC_RESISTANCE_OFFSET b/doc/props/P_MAGIC_RESISTANCE_OFFSET
index 8d270e3..111b94e 100644
--- a/doc/props/P_MAGIC_RESISTANCE_OFFSET
+++ b/doc/props/P_MAGIC_RESISTANCE_OFFSET
@@ -37,7 +37,7 @@
    // Goblins
    SetProp(P_MAGIC_RESISTANCE_OFFSET,
              ([MT_ANGRIFF:600,         // 6% Resistenz gegen Angriff
-               MT_ILLUSION:500,        // 6% Resistenz gegen Illusionen
+               MT_ILLUSION:500,        // 5% Resistenz gegen Illusionen
                MT_VERWANDLUNG:-300,    // 3% Empfindlichkeit
                MT_HELLSICHT:-750,      // 7.5% Empfindlichkeit
                MT_BEHERRSCHUNG:250])); // 2.5% Resistenz
diff --git a/doc/props/P_MAX_HP b/doc/props/P_MAX_HP
index fcb3cb0..6534adb 100644
--- a/doc/props/P_MAX_HP
+++ b/doc/props/P_MAX_HP
@@ -21,6 +21,13 @@
    Maximale Anzahl der Lebenspunkte.
 
 
+HINWEIS
+=======
+
+   Beim Setzen der Property wird gleichzeitig P_HP auf denselben Wert
+   gesetzt.
+
+
 SIEHE AUCH
 ==========
 
diff --git a/doc/props/P_MAX_SP b/doc/props/P_MAX_SP
index 7f7aa43..84f788c 100644
--- a/doc/props/P_MAX_SP
+++ b/doc/props/P_MAX_SP
@@ -21,6 +21,13 @@
    Maximale Anzahl der Magiepunkte.
 
 
+HINWEIS
+=======
+
+   Beim Setzen der Property wird gleichzeitig P_SP auf denselben Wert
+   gesetzt.
+
+
 SIEHE AUCH
 ==========
 
diff --git a/doc/sefun/process_string b/doc/sefun/process_string
index fbc7018..4d72259 100644
--- a/doc/sefun/process_string
+++ b/doc/sefun/process_string
@@ -8,41 +8,43 @@
 FUNKTION
 ========
 
-   string process_string(string str)
-   string process_string(closure cl)
+   string process_string(string str) string process_string(closure cl)
 
 
 BESCHREIBUNG
 ============
 
-   Durchsucht den String str nach Vorkommnissen von Substrings, die "Wert
-   durch Funktionsaufruf zu ersetzen" andeuten. Die Form ist: @@, gefolgt
-   durch einen impliziten Funktionsaufruf.
+   Beschreibung s. efun/process_string.
 
-   Der zu ersetzenden Substring hat die Form:
-   @@function[:filename][|argument1|argument2]@@
+   Abweichend zu der Beschreibung gibt es im MG folgende wichtige
+   Punkte:
 
-   Die entsprechende Funktion muss einen String zurueckgeben, oder der
-   process_string() uebergebene String str wird nicht modifiziert.
+   * nicht in neuem Code nutzen, aus altem Code ausbauen
 
-   process_string() arbeitet nicht rekursiv, object_name und argument sind
-   optionale Werte.
+   * nicht nutzbar fuer Objekte mit einer UID mit einem Level > 30.
 
-   Falls eine Closure angegeben wurde, wird diese lediglich gerufen
-   und nicht gefiltert.
+   * nicht rufbar durch Magiershells
 
+   * kann Funktionen in anderen Objekten nur rufen, wenn diese zum
+     gleichen Magier gehoeren.
 
-ANMERKUNGEN
-===========
+   Folgendes Properties und Details werden bei der Abfrage ueber
+   process_string() gefiltert:
 
-   - Die Funktion, die gerufen werden soll, _muss_ mit einem Buchstaben
-                 anfangen, '_' ist nicht moeglich!
-   - folgendes Properties und Details werden bei der Abfrage ueber
-     process_string() gefiltert:
-     P_LONG, P_SHORT, P_READ_MSG, AddReadDetail()-Details und NPC-Chats
-     P_INT_LONG ueber int_long(), P_INT_SHORT ueber int_short()
-   - die Nutzung kann zu Sicherheitsproblemen fuehren, siehe auch
-     process_call()
+   * P_LONG
+
+   * P_SHORT
+
+   * Details
+
+   * NPC-Chats
+
+   * P_INT_LONG
+
+   * P_INT_SHORT
+
+   Die Nutzung kann zu Sicherheitsproblemen fuehren, siehe auch
+   process_call().
 
 
 BEISPIEL
@@ -58,7 +60,6 @@
 
    -> bei Abfrage: "Die Beschreibung." oder "Die andere Beschreibung."
 
-
    // Teilersetzung
    SetProp(P_SHORT, "Ein @@farbenfun|huebsch@@ Ding");
    ...
@@ -72,6 +73,6 @@
 SIEHE AUCH
 ==========
 
-   notify_fail(E), process_call(E), replace_personal(E)
+   process_call(), replace_personal()
 
-22. Nov. 2006 Arathorn
+02.09.2020 Zesstra
diff --git a/doc/sefun/replace_personal b/doc/sefun/replace_personal
index 3804be3..a8946e5 100644
--- a/doc/sefun/replace_personal
+++ b/doc/sefun/replace_personal
@@ -47,8 +47,6 @@
 
    x steht fuer die Position des Objekts/Strings in *obs, beginnend bei 1.
 
-
-
    Besonderheiten beim Possessivpronomen (@WERQPPGNx):
    G muss durch das Geschlecht (M, F oder N) und N durch den Numerus (S
    oder P) ersetzt werden.
@@ -62,47 +60,45 @@
 
    durchersetzter String
 
+
 Beispiele
+=========
 
-   replace_personal("@WER1", ({find_player("gloinson")})) ==
-   "Gloinson"
+   replace_personal("@WER1", ({find_player("gloinson")})) ==> "Gloinson"
 
-   replace_personal("@WEMQP1", ({find_player("gloinson")})) == "ihm"
+   replace_personal("@WEMQP1", ({find_player("gloinson")})) ==> "ihm"
 
-   // unbestimmter und bestimmter Artikel: replace_personal("@WER1
-   zueckt @WENU2 und verhaut @WEN3.",
+   // unbestimmter und bestimmter Artikel:
+   replace_personal("@WER1 zueckt @WENU2 und verhaut @WEN3.",
+                    ({find_player("gloinson"),
+                      find_object("/obj/mpa"),
+                      find_object("/obj/wanderer")}))
+   ==> "Gloinson zueckt eine Zeitung und verhaut den Wanderer."
 
-      ({find_player("gloinson"),
-         find_object("/obj/mpa"), find_object("/obj/wanderer")}))
-
-   == "Gloinson zueckt eine Zeitung und verhaut den Wanderer."
-
-   // Beim Possessivpronomen beziehen sich WEN, F und P (Akkusativ, //
-   Femininum, Plural) auf die Taschen, nicht auf Kessa:
+   // Beim Possessivpronomen beziehen sich WEN, F und P (Akkusativ,
+   // Femininum, Plural) auf die Taschen, nicht auf Kessa:
    replace_personal("@WER1 steckt @WESSEN2 Turnschuhe in @WENQPPFP1 "
+                    "Taschen.",
+                    ({find_player("kessa"),
+                      find_player("gloinson")}))
+   ==> "Kessa steckt Gloinsons Turnschuhe in ihre Taschen."
 
-      "Taschen.", ({find_player("kessa"),
-
-         find_player("gloinson")}))
-
-   == "Kessa steckt Gloinsons Turnschuhe in ihre Taschen."
-
-   // Ein Beispiel mit laengerem >>*<<obs: replace_personal("@WER1
-   zieht @WENQPPMP1 neuen Turnschuhe an. @WER2 ist "
-
-      "so beeindruckt, dass @WERQP2 @WEMQP1 @WENU3 auf die " "@WEN4
-      haut und die Schuhe in @WEMQPPFS2 Tasche " "verschwinden laesst.
-      @WERU5 schaut zu und kichert " "irre. Wenn das @WER6 gesehen
-      haette!", ({find_player("gloinson"),
-
-         find_player("kessa"), find_object("/obj/mpa"), "Birne",
-         find_object("/obj/wanderer"), find_netdead("jof")}),1)
-
-   == "Gloinson zieht seine neuen Turnschuhe an. Kessa ist so
-   beeindruckt, "
-      "dass sie ihm eine Zeitung auf die Birne haut und die Schuhe in
-      ihrer " "Tasche verschwinden laesst. Ein Wanderer schaut zu und
-      kichert " "irre. Wenn das Jof gesehen haette!"
+   // Ein Beispiel mit laengerem *obs:
+   replace_personal("@WER1 zieht @WENQPPMP1 neuen Turnschuhe an. @WER2 ist "
+                    "so beeindruckt, dass @WERQP2 @WEMQP1 @WENU3 auf die "
+                    "@WEN4 haut und die Schuhe in @WEMQPPFS2 Tasche "
+                    "verschwinden laesst. @WERU5 schaut zu und kichert "
+                    "irre. Wenn das @WER6 gesehen haette!",
+                    ({find_player("gloinson"),
+                      find_player("kessa"),
+                      find_object("/obj/mpa"),
+                      "Birne",
+                      find_object("/obj/wanderer"),
+                      find_netdead("jof")}),1)
+   ==> "Gloinson zieht seine neuen Turnschuhe an. Kessa ist so "
+       "beeindruckt, dass sie ihm eine Zeitung auf die Birne haut und die "
+       "Schuhe in ihrer Tasche verschwinden laesst. Ein Wanderer schaut "
+       "zu und kichert irre. Wenn das Jof gesehen haette!"
 
 
 SIEHE AUCH
diff --git a/doc/sefun/send_debug b/doc/sefun/send_debug
new file mode 100644
index 0000000..f47b748
--- /dev/null
+++ b/doc/sefun/send_debug
@@ -0,0 +1,45 @@
+
+send_debug()
+************
+
+
+FUNKTION
+========
+
+   varargs void send_debug(object|string wiz, string msg, string
+   msg_prefix)
+
+
+BESCHREIBUNG
+============
+
+   Sendet <msg> via ReceiveMsg() an das Spielerobjekt <wiz> (wenn es
+   als string angegeben wird, wird es per find_player gesucht).
+   Hierbei wird mit dem Nachrichtentyp MT_DEBUG gesendet, d.h. die
+   Meldung wird nur angezeigt, wenn das Spielerobjekt Magier oder
+   Testspieler mit aktiviertem P_WIZ_DEBUG ist.
+
+   Magier koennen P_WIZ_DEBUG mit dem Kommando 'mschau' umschalten,
+   Testspieler benoetigen hierfuer einen Magier.
+
+   Diese Debugmeldungen koennten sehr praktisch sein, aber man sollte
+   es in produktivem Code auch nicht uebertreiben, auch wenn keine
+   Ausgabe an Spieler erfolgt, wird die Zustellung jedoch bei jedem
+   Aufruf zumindest geprueft.
+
+
+BEISPIEL
+========
+
+      send_debug("zesstra", "Verbrauchte evalcosts: 42");
+
+      send_debug(this_player(), "Verbrauchte evalcost: 42",
+                 "Unit-Debug: ");
+
+
+SIEHE AUCH
+==========
+
+   ReceiveMsg()
+
+14.10.2020, Zesstra
diff --git a/doc/sphinx/lfun/AddInfo.rst b/doc/sphinx/lfun/AddInfo.rst
index 5db8bef..8b5914a 100644
--- a/doc/sphinx/lfun/AddInfo.rst
+++ b/doc/sphinx/lfun/AddInfo.rst
@@ -3,9 +3,10 @@
 
 FUNKTION
 --------
+:: 
 
-     varargs void AddInfo( frage, meldung
-               [, indent [, [silent [, casebased] ] ] );
+  public varargs void AddInfo(string|string* key, string|closure info,
+                 string indent, int|string silent, string|closure casebased);
 
 DEFINIERT IN
 ------------
@@ -15,18 +16,23 @@
 ARGUMENTE
 ---------
 
-     string/string* frage
-       Schluesseltext(e) auf die Informationen gegeben werden sollen.
-     string/closure meldung
+     string|string* frage
+       Schluesselwoerter, fuer die der NPC eine Antwort geben soll, wenn
+       man ihn danach fragt
+
+     string|closure meldung
        Information, die gegeben werden soll; wenn 'meldung' eine Closure 
        ist, wird der gerufenen Funktion nichts uebergeben.
-     string indent
+
+     string indent    (optional)
        Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
-     int/string silent
+
+     int|string silent    (optional)
        Ist silent gesetzt, so erfolgt Antwort nur an Fragenden. 
-     string/closure casebased
+
+     string|closure casebased   (optional)
        Closure mit Returnwert string oder int.
-       Bekommt nichts uebergeben.
+       Der Funktion werden keine Argumente uebergeben.
 
 BESCHREIBUNG
 ------------
@@ -69,7 +75,7 @@
 
      Die Strings von 'silent' und 'meldung' werden geparsed.
      Dabei koennen die @[...]-Tags von replace_personal() verwendet werden,
-     Objekt 1 ist this_player(). Ersetzte String am Satzanfang werden
+     Objekt 1 ist this_player(). Ersetzte Strings am Satzanfang werden
      automatisch gross geschrieben.
      AddInfo() konvertiert die alten Schluesselworte @WER, @WESSEN, @WEM,
      @WEN zu denen von replace_personal(), jedoch nicht in den Rueckgabe-
@@ -259,4 +265,4 @@
      Interna:
        :doc:`GetInfoArr` , :doc:`do_frage`
 
-7. Mar 2017 Gloinson
+24.09.2020, Arathorn
diff --git a/doc/sphinx/lfun/AddMoney.rst b/doc/sphinx/lfun/AddMoney.rst
index 416bdee..0868e51 100644
--- a/doc/sphinx/lfun/AddMoney.rst
+++ b/doc/sphinx/lfun/AddMoney.rst
@@ -65,10 +65,10 @@
 
 .. code-block:: pike
 
-     #include <zentralbank.h>
+     #include <bank.h>
      
      // gib ihm Geld
-     int money = ZENTRALBANK->Withdraw(50);
+     int money = ZENTRALBANK->WithDraw(50);
      this_player()->AddMoney(money);
 
      // nimm ihm Geld
@@ -80,12 +80,14 @@
 
 SIEHE AUCH
 ----------
+::
 
-     Geldhandling:	QueryMoney(L)
-     Zentralbank:	PayIn(L), WithDraw(L)
-     Sonstiges:		move(L),
-     /items/money.c, /sys/moving.h, /sys/money.h, /sys/bank.h
-     /std/container/moneyhandler.c
+     Geldhandling:  QueryMoney(L)
+     Zentralbank:   PayIn(L), WithDraw(L)
+     Sonstiges:     move(L),
+     /items/money.c
+     /sys/moving.h, /std/container/moneyhandler.c
+     /sys/money.h, /sys/bank.h 
 
 18.02.2013, Zesstra
 
diff --git a/doc/sphinx/lfun/AddRoomMessage.rst b/doc/sphinx/lfun/AddRoomMessage.rst
index 527ea54..ce325ff 100644
--- a/doc/sphinx/lfun/AddRoomMessage.rst
+++ b/doc/sphinx/lfun/AddRoomMessage.rst
@@ -53,7 +53,7 @@
 
        * passiert automatisch nur, wenn alle Spieler den Raum verlassen haben
        * ist manuell nur ueber Loeschen der Nachrichten umsetzbar, also mit
-         ``AddRoomMessage((string)0, 0, (string)0);``
+         ``AddRoomMessage(0, 0, 0);``
 
      In Funktionen, die durch AddRoomMessage() ausgeloest werden, darf
      this_player() nicht verwendet werden, da die call_out()-Kette den
@@ -122,7 +122,7 @@
      }
 
      public int action_laerm(string str) {
-       AddRoomMessage((string)0, 0, (string)0);
+       AddRoomMessage(0, 0, 0);
 
        this_player()->ReceiveMsg(
          "Du schreist dir kurz die Seele aus dem Leib. Alle Tiere "
diff --git a/doc/sphinx/lfun/AddSpecialInfo.rst b/doc/sphinx/lfun/AddSpecialInfo.rst
index 558b2d2..fd67141 100644
--- a/doc/sphinx/lfun/AddSpecialInfo.rst
+++ b/doc/sphinx/lfun/AddSpecialInfo.rst
@@ -5,23 +5,32 @@
 --------
 ::
 
-     varargs void AddSpecialInfo( frage, meldung
-			   [, indent [, [silent [, casebased] ] ] );
+  public varargs void AddSpecialInfo(string|string* keys, string functionname,
+                 string indent, int|string silent, string|closure  casebased);
+
 
 ARGUMENTE
 ---------
 ::
 
-     string/string* frage
-	Schluesseltext(e) auf die Informationen gegeben werden sollen.
-     string/closure function
-	Methodenname im NPC/Closure
-     string indent
-	Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
-     int/string silent
-	Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
-     string/closure casebased
-	Funktionsname oder Closure mit Returnwert string oder int.
+     string|string* frage
+       Schluesselwoerter, fuer die der NPC eine Antwort geben soll, wenn
+       man ihn danach fragt
+
+     string functionname
+       Name der Funktion, die gerufen werden soll, um den Informationstext
+       des NPCs zu ermitteln. Der gerufenen Funktion werden keine Argumente
+       uebergeben.
+
+     string indent    (optional)
+       Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
+
+     int|string silent    (optional)
+       Ist silent gesetzt, so erfolgt Antwort nur an Fragenden. 
+
+     string|closure casebased   (optional)
+       Closure mit Returnwert string oder int.
+       Der Funktion werden keine Argumente uebergeben.
 
 DEFINIERT IN
 ------------
@@ -80,9 +89,17 @@
 
 SIEHE AUCH
 ----------
-::
 
-     AddInfo(L), RemoveInfo(L)
+     Verwandt:
+       :doc:`AddInfo`, :doc:`RemoveInfo`
+     Props:
+       :doc:`../props/P_PRE_INFO`
+     Files:
+       /std/npc/info.c
+     Loggen:
+       :doc:`../props/P_LOG_INFO`
+     Interna:
+       :doc:`GetInfoArr` , :doc:`do_frage`
 
-7.Apr 2004 Gloinson
+24.09.2020, Arathorn
 
diff --git a/doc/sphinx/lfun/Attack.rst b/doc/sphinx/lfun/Attack.rst
index 9281478..c6357d4 100644
--- a/doc/sphinx/lfun/Attack.rst
+++ b/doc/sphinx/lfun/Attack.rst
@@ -17,8 +17,8 @@
 ------------
 ::
 
-	Der Feind wird der Staerke der Waffe (bzw. der Haende) entsprechend
-	stark angegriffen.
+  Der Feind wird entsprechend der Angriffsstaerke der Waffe (P_WC) bzw. der 
+  Haende (P_HANDS[1]) angegriffen.
 
 RUECKGABEWERT
 -------------
@@ -32,11 +32,10 @@
 
 	Diese Funktion gibt die Angriffsmeldung aus.
 	Falls mit blossen Haenden angegriffen wird, ist die Staerke
-	(2*Staerke_der_Haende + 10*A_STR)/3
+	(2 * P_HANDS[1] + 10 * A_STR)/3
 
 SIEHE AUCH
 ----------
 ::
 
-	"Defend", "QueryDamage"
-
+	Defend(), QueryDamage()
diff --git a/doc/sphinx/lfun/CheckResistance.rst b/doc/sphinx/lfun/CheckResistance.rst
index 7254068..b3a83da 100644
--- a/doc/sphinx/lfun/CheckResistance.rst
+++ b/doc/sphinx/lfun/CheckResistance.rst
@@ -5,7 +5,7 @@
 --------
 ::
 
-	CheckRessistance(string* dam_type_list)
+	public float CheckResistance(string* dam_type_list)
 
 ARGUMENTE
 ---------
@@ -33,5 +33,5 @@
 ----------
 ::
 
-	"Defend"
+	Defend(), P_RESISTANCE_STRENGTHS
 
diff --git a/doc/sphinx/lfun/DefendFunc.rst b/doc/sphinx/lfun/DefendFunc.rst
index 6b86f13..e0a9c78 100644
--- a/doc/sphinx/lfun/DefendFunc.rst
+++ b/doc/sphinx/lfun/DefendFunc.rst
@@ -50,6 +50,7 @@
 
 BEISPIELE
 ---------
+:: 
 
      Eine Ruestung, die bei Angriffen mit Feuer ihre volle Staerke entfaltet
      und bei Angriffen durch Geister geschwaecht wird:
@@ -81,12 +82,13 @@
            enemy->is_class_member(CL_GHOST))
          prot -= random(10);
 
-       // Der Rueckgabewert wird auf den aus P_AC errechneten Wert draufgeschlagen
+       // Der Rueckgabewert wird auf den aus P_AC errechneten Wert 
+       // draufgeschlagen
        return prot;
      }
 
 SIEHE AUCH
 ----------
 
-     :doc:`../props/P_DEFEND_FUNC`, :doc:`QueryDefendd`
+     :doc:`../props/P_DEFEND_FUNC`, :doc:`QueryDefend`
      /std/armour/combat.c
diff --git a/doc/sphinx/lfun/QueryArmourByType.rst b/doc/sphinx/lfun/QueryArmourByType.rst
index 17e6967..c3a126d 100644
--- a/doc/sphinx/lfun/QueryArmourByType.rst
+++ b/doc/sphinx/lfun/QueryArmourByType.rst
@@ -9,7 +9,7 @@
 --------
 ::
 
-     mixed QueryArmourByType(string type)
+     object|object*|mapping QueryArmourByType(string type)
 
 DEFINIERT IN
 ------------
@@ -30,17 +30,28 @@
 
      Abfrage, ob das Lebewesen eine Ruestung des angegebenen Typs traegt.
 
-     Zurueckgegeben wird je nach Tragestatus und <type>:
-     * 0, falls das Lebewesen die gesuchte Ruestungsart nicht traegt
-     * im Erfolgsfall das Ruestungsobjekt
-     * falls <type> AT_MISC ist:
-       * ({}), wenn es keine AT_MISC-Ruestung traegt
-       * ein Array von AT_MISC-Ruestungen
-     * falls <type> 0 ist: ein Mapping, das diese Informationen mit dem
-       Ruestungstypen als Schluessel enthaelt:
-       ([AT_MISC: ({[object], ...}),
-         AT_...: <object>,
-         ... ])
+
+RUECKGABEWERTE
+--------------
+::
+    
+    Zurueckgegeben wird abhaengig vom Argument <type> folgendes:
+
+    1) Ist <type> ein Typ, von dem man nur eine Ruestung tragen kann:
+       *  0, falls das Lebewesen die gesuchte Ruestungsart nicht traegt,
+       *  ansonsten das Ruestungsobjekt
+
+    2) Ist <type> AT_MISC:
+       *   ein Array mit allen AT_MISC-Ruestungen
+       *   ({}), wenn das Lebewesen keine AT_MISC-Ruestung traegt
+
+    3) Ist <type> 0:
+       * Ein Mapping mit den Ruestungstypen als Schluessel der folgenden 
+       Form:
+          ([AT_MISC:  ({object misc1, ... }),
+            AT_CLOAK: object cloak,
+            AT_...:   object ...,
+            ... ])
 
 BEMERKUNG
 ---------
diff --git a/doc/sphinx/lfun/create_default_npc.rst b/doc/sphinx/lfun/create_default_npc.rst
index 8507388..999fee2 100644
--- a/doc/sphinx/lfun/create_default_npc.rst
+++ b/doc/sphinx/lfun/create_default_npc.rst
@@ -46,7 +46,10 @@
      wurden, werden durch die neuen Werte ersetzt.
 
      Ab einem Aufruf mit Level 20 werden P_XP = 202000 gesetzt, also ein
-     Kill-Stup vergeben (siehe P_XP).
+     Kill-Stups vergeben (siehe P_XP).
+
+     P_HP und P_SP werden auf dieselben Werte wie P_MAX_HP bzw. P_MAX_SP 
+     eingestellt.
 
 BEISPIEL
 --------
diff --git a/doc/sphinx/props/P_MAGIC_RESISTANCE_OFFSET.rst b/doc/sphinx/props/P_MAGIC_RESISTANCE_OFFSET.rst
index a1be37e..d87ec69 100644
--- a/doc/sphinx/props/P_MAGIC_RESISTANCE_OFFSET.rst
+++ b/doc/sphinx/props/P_MAGIC_RESISTANCE_OFFSET.rst
@@ -36,7 +36,7 @@
      // Goblins
      SetProp(P_MAGIC_RESISTANCE_OFFSET,
                ([MT_ANGRIFF:600,         // 6% Resistenz gegen Angriff
-	         MT_ILLUSION:500,        // 6% Resistenz gegen Illusionen
+	         MT_ILLUSION:500,        // 5% Resistenz gegen Illusionen
                  MT_VERWANDLUNG:-300,    // 3% Empfindlichkeit
 		 MT_HELLSICHT:-750,      // 7.5% Empfindlichkeit
 		 MT_BEHERRSCHUNG:250])); // 2.5% Resistenz
diff --git a/doc/sphinx/props/P_MAX_HP.rst b/doc/sphinx/props/P_MAX_HP.rst
index 3e23b46..ce7049f 100644
--- a/doc/sphinx/props/P_MAX_HP.rst
+++ b/doc/sphinx/props/P_MAX_HP.rst
@@ -19,6 +19,13 @@
 
      Maximale Anzahl der Lebenspunkte.
 
+HINWEIS
+-------
+:: 
+
+     Beim Setzen der Property wird gleichzeitig P_HP auf denselben Wert 
+     gesetzt.
+
 SIEHE AUCH
 ----------
 ::
diff --git a/doc/sphinx/props/P_MAX_SP.rst b/doc/sphinx/props/P_MAX_SP.rst
index 2269cd2..57ef762 100644
--- a/doc/sphinx/props/P_MAX_SP.rst
+++ b/doc/sphinx/props/P_MAX_SP.rst
@@ -19,6 +19,13 @@
 
      Maximale Anzahl der Magiepunkte.
 
+HINWEIS
+-------
+:: 
+
+      Beim Setzen der Property wird gleichzeitig P_SP auf denselben Wert
+      gesetzt.
+
 SIEHE AUCH
 ----------
 ::
diff --git a/doc/sphinx/sefun/replace_personal.rst b/doc/sphinx/sefun/replace_personal.rst
index ff7c07f..e799ddb 100644
--- a/doc/sphinx/sefun/replace_personal.rst
+++ b/doc/sphinx/sefun/replace_personal.rst
@@ -46,8 +46,6 @@
 
      x steht fuer die Position des Objekts/Strings in *obs, beginnend bei 1.
 
-     
-
      Besonderheiten beim Possessivpronomen (@WERQPPGNx):
      G muss durch das Geschlecht (M, F oder N) und N durch den Numerus (S 
      oder P) ersetzt werden. 
@@ -66,27 +64,19 @@
      
 
 Beispiele
-
-     replace_personal("@WER1", ({find_player("gloinson")}))
-     == "Gloinson"
------------------------------------------------------------------------------------------
+---------
 ::
 
+     replace_personal("@WER1", ({find_player("gloinson")})) ==> "Gloinson"
      
-
-     replace_personal("@WEMQP1", ({find_player("gloinson")}))
-     == "ihm"     
-
-     
+     replace_personal("@WEMQP1", ({find_player("gloinson")})) ==> "ihm"     
 
      // unbestimmter und bestimmter Artikel:
      replace_personal("@WER1 zueckt @WENU2 und verhaut @WEN3.", 
                       ({find_player("gloinson"),
                         find_object("/obj/mpa"), 
                         find_object("/obj/wanderer")}))
-     == "Gloinson zueckt eine Zeitung und verhaut den Wanderer."
-
-     
+     ==> "Gloinson zueckt eine Zeitung und verhaut den Wanderer."
 
      // Beim Possessivpronomen beziehen sich WEN, F und P (Akkusativ,
      // Femininum, Plural) auf die Taschen, nicht auf Kessa:
@@ -94,7 +84,7 @@
                       "Taschen.", 
                       ({find_player("kessa"), 
                         find_player("gloinson")}))
-     == "Kessa steckt Gloinsons Turnschuhe in ihre Taschen."
+     ==> "Kessa steckt Gloinsons Turnschuhe in ihre Taschen."
 
      // Ein Beispiel mit laengerem *obs:
      replace_personal("@WER1 zieht @WENQPPMP1 neuen Turnschuhe an. @WER2 ist "
@@ -108,10 +98,10 @@
                         "Birne",
                         find_object("/obj/wanderer"),
                         find_netdead("jof")}),1)
-     == "Gloinson zieht seine neuen Turnschuhe an. Kessa ist so beeindruckt, "
-        "dass sie ihm eine Zeitung auf die Birne haut und die Schuhe in ihrer "
-        "Tasche verschwinden laesst. Ein Wanderer schaut zu und kichert "
-        "irre. Wenn das Jof gesehen haette!"
+     ==> "Gloinson zieht seine neuen Turnschuhe an. Kessa ist so "
+         "beeindruckt, dass sie ihm eine Zeitung auf die Birne haut und die "
+         "Schuhe in ihrer Tasche verschwinden laesst. Ein Wanderer schaut "
+         "zu und kichert irre. Wenn das Jof gesehen haette!"
 
 SIEHE AUCH
 ----------
diff --git a/doc/sphinx/sefun/set_light.rst b/doc/sphinx/sefun/set_light.rst
deleted file mode 100644
index 99d5bee..0000000
--- a/doc/sphinx/sefun/set_light.rst
+++ /dev/null
@@ -1,32 +0,0 @@
-set_light()
-===========
-
-SYNOPSIS
---------
-::
-
-        int set_light(int n)
-
-DESCRIPTION
------------
-::
-
-        An object is by default dark. It can be set to not dark by
-        calling set_light(1). The environment will then also get this
-        light. The returned value is the total number of lights in
-        this room. So if you call set_light(0) it will return the
-        light level of the current object.
-
-        
-
-        Note that the value of the argument is added to the light of
-        the current object.
-
-BUGS
-----
-::
-
-	This handling of light by the parser is inappropriate for most
-	purposes: If you put a burning candle into a safe, the safe
-	will start to emit light.
-
diff --git a/doc/wiz/regionsleitfaden b/doc/wiz/regionsleitfaden
index 70e491a..45e85f5 100644
--- a/doc/wiz/regionsleitfaden
+++ b/doc/wiz/regionsleitfaden
@@ -44,7 +44,9 @@
    Dateien aus den Verzeichnissen.
 
 o  Speicherung von Daten in secure-Verzeichnissen soll bitte nur sehr
-   sparsam erfolgen und nur in Abstimmung mit dem RM.
+   sparsam erfolgen und nur in Abstimmung mit dem RM. Denkt dabei daran,
+   dass Secure-Verzeichnisse im Zusammenspiel mit Git/Gerrit zusaetzliche
+   Probleme aufwerfen.
 
 o  save_object() bitte sehr sparsam verwenden (nicht bei jeder Daten-
    aenderung, bei Bedarf in reset/remove).
diff --git a/doc/wiz/rm-howto b/doc/wiz/rm-howto
index 63c9a84..a722c8c 100644
--- a/doc/wiz/rm-howto
+++ b/doc/wiz/rm-howto
@@ -4,10 +4,11 @@
 Vorlaeufiges Inhaltsverzeichnis:
 
 1) Allgemeines
+   - Konzepte fuer neue Gebiete
    - Fehlerteufel
-   - Logtool
    - Kommentierung von Aenderungen
    - eigene Anschluesse
+   - "Datenhygiene" im Regionsverzeichnis
 2) Abnahme von Code/Gebieten
    - Balance/Genehmigungen
    - Konzeptionelle Eignung
@@ -32,67 +33,116 @@
 1) Allgemeines
 ==============
 
-o Um stets einen Ueberblick ueber die in Deiner Region (hoffentlich selten)
-  auftretenden Bugs und Warnungen zu behalten, solltest Du einen
-  Fehlerteufel (/obj/tools/fehlerteufel.c) besitzen, bedienen koennen und
-  regelmaessig dessen Listen durchsehen. Deinen Regionsmitarbeitern solltest
-  Du, allein schon, um zusaetzliche Arbeit fuer Dich selbst zu reduzieren,
-  dieses Werkzeug ebenfalls an die Hand geben und sie auffordern, ihren
-  Kram moeglichst umfassend selbst zu reparieren.
-  Neuen Magiern wird dieses Tool uebrigens automatisch von Merlin in die
-  Hand gedrueckt, so dass sie sich vom ersten Tag an daran gewoehnen koennen.
+1a) Konzepte und Dokumentation
 
-o Es ist empfehlenswert, das Logtool zu besitzen (/obj/tools/logtool.c) und
-  in diesem fuer jedes Repfile eines Regionsmitarbeiters einen Eintrag vor-
-  zusehen. Warum das? Es ist bereits vorgekommen, dass Spieler ernsthaft
-  argumentiert haben, sie duerften einen von ihnen entdeckten Bug ausnutzen,
-  weil sie ihn ja gemeldet haetten (im Repfile!), er aber nicht repariert
-  worden sei (was nicht verwundert, da er im Repfile in der Mehrzahl der
-  Faelle weit unterhalb des Wahrnehmungshorizonts der allermeisten
-  Regionsmagier schwebt).
+  o Die Erfahrung zeigt, dass es aus verschiedenen Gruenden wirklich dringend
+    zu empfehlen ist, sich fuer neue Gebiete ein Konzept vorlegen zu lassen,
+    dieses gruendlich zu pruefen und zu durchdenken und mit dem betreffenden
+    Regionsmitarbeiter zu diskutieren. Weiterhin empfiehlt es sich ebenfalls,
+    eine ueber das Konzept erzielte Einigung im Verzeichnis "doc" Deiner
+    Region zu dokumentieren. Hierdurch erreichst Du mehrere Dinge:
+    - Du vermeidest Ueberraschungen ("Hier ist mein neues Gebiet zur Abnahme,
+      sind nur 120 Raeume. Oh, hoppla, hab ich Dir nicht Bescheid gesagt?");
+      auch fuer Deine etwaigen Nachfolger.
+    - Du vermeidest bei absehbaren technischen Schwierigkeiten Frustration
+      beim Deinem Regionsmitarbeiter.
+    - Du erhoehst die Wahrscheinlichkeit, dass das Gebiet tatsaechlich
+      fertiggestellt wird.
+    - Jeder kann weitgehend verbindlich nachlesen, was Du genehmigt hast.
+    - Es ist klar ersichtlich, welche Konzepte bekanntermassen schon in Arbeit
+      sind, so dass inhaltliche Aehnlichkeiten im Vorfeld vermieden werden
+      koennen.
+    
+    Du solltest den betreffenden Regionsmitarbeiter auch darauf hinweisen,
+    dass er Dich informieren moege, wenn er eine groessere konzeptionelle
+    Umstellung des neuen Gebietes durchfuehren will.
 
-o Wenn Du in fremdem Code Aenderungen vornehmen musst, die mehr beruehren
-  als nur ein paar Tippfehler in Details oder Infos, dann kommentiere den
-  defekten Code aus und fuege den reparierten mit Kommentar ein. Es reicht
-  an dieser Stelle aus, Deinen Namen und das Datum zu vermerken. In den
-  Header der Datei solltest Du unbedingt ein Changelog einfuegen, in dem
-  das Datum der Aenderung, der Name des Ausfuehrenden (Deiner) sowie die
-  vorgenommene Aenderung mit Begruendung bzw. u.U. Bug-ID aus dem Fehler-
-  teufel einzutragen ist. Wir haben im MG leider keinen wirkungsvollen
-  Debugger und Bugtracker-Mechanismus, so dass wir zur Erhaltung einer
-  gewissen Code-Hygiene Bugfixes mit Hilfe solcher Eintragungen dokumentieren
-  und rueckverfolgen muessen. Insbesondere ist ein solcher Eintrag wichtig,
-  um im Falle von Folge-Bugs die Ursache schneller zu finden.
+    Welche Kriterien man als RM ansetzt, um ein Gebiet als regionstauglich
+    zu bewerten, liegt in der Entscheidung des RM.
 
-o Willst Du in Deiner eigenen Region ein Gebiet anschliessen, solltest Du
-  diesen vor Anschluss entweder vom Co-RM oder von einem RM einer anderen
-  Region lesen lassen. Auch wenn Du ein guter Programmierer bist, findet ein
-  zweites Paar Augen oft Dinge, an die man nicht gedacht hat.
+  o Wenn ein Konzept fuer ein Gesellenstueck eingereicht wird, und es handelt
+    sich um eine Gemeinschaftsarbeit mehrerer Magier (Kooperation mehrerer
+    Lehrlinge oder Lehrling(e) + erfahrene Magier), UEBERLEGT EUCH GUT, OB
+    IHR DAS ZULASSEN WOLLT! Erfahrungsgemaess laesst sich schwer beurteilen,
+    welcher Teil des Codes von wem ist. Wenn es zugelassen wird, sollten mit
+    den betreffenden Lehrlingen klare Vereinbarungen insbesondere ueber die
+    Trennung des Codes nach Autor getroffen werden.
 
+1b) Fehlerteufel / Abarbeitung von Bugs
+
+  o Um stets einen Ueberblick ueber die in Deiner Region (hoffentlich selten)
+    auftretenden Bugs und Warnungen zu behalten, solltest Du einen
+    Fehlerteufel (/obj/tools/fehlerteufel.c) besitzen, bedienen koennen und
+    regelmaessig dessen Listen durchsehen. Deinen Regionsmitarbeitern solltest
+    Du, allein schon, um zusaetzliche Arbeit fuer Dich selbst zu reduzieren,
+    dieses Werkzeug ebenfalls an die Hand geben und sie auffordern, ihren
+    Kram moeglichst umfassend selbst zu reparieren.
+    Neuen Magiern wird dieses Tool uebrigens automatisch von Merlin in die
+    Hand gedrueckt, so dass sie sich vom ersten Tag an daran gewoehnen 
+    koennen.
+
+  o Wenn Du in fremdem Code Aenderungen vornehmen musst, die mehr beruehren
+    als nur ein paar Tippfehler in Details oder Infos, dann fuege den 
+    reparierten Code mit Kommentar ein. Wenn in Deiner Region git/gerrit zur
+    Codeverwaltung verwendet werden, schreibe eine aussagekraeftige Commit-
+    Message, bei Bedarf ergaenzt durch einen Kommentar im Code.
+
+1c) Anschluss eigener Gebiete in der eigenen Region
+
+  o Willst Du in Deiner eigenen Region ein Gebiet anschliessen, solltest Du
+    diesen vor Anschluss entweder vom Co-RM oder von einem RM einer anderen
+    Region lesen lassen. Auch wenn Du ein guter Programmierer bist, findet ein
+    zweites Paar Augen oft Dinge, an die man nicht gedacht hat.
+
+1d) "Hygiene" in den Regionsverzeichnissen
+
+  o Wenn Du nicht angeschlossene Objekte aus Deiner Region aussortieren
+    moechtest, ist sprich am besten einen EM an, der Dir dabei hilft:
+    Einerseits kann man auf der Shell bequemer herausfinden, ob ein Objekt
+    tatsaechlich nicht verwendet wird. Andererseits soll der ungenutzte
+    Code in das /players-Verzeichnis des Autors verschoben werden, was
+    haeufig ebenfalls EM-Rechte benoetigt.
+
+  o Es wird dringend empfohlen, neuen Regionscode nur noch in /players zu
+    entwickeln.
+
+  o Als Regionsmagier hast Du aufgrund eines EM-Beschlusses die Moeglichkeit,
+    fuer Deine jeweilige(n) Region(en) verbindlich festzulegen, ob es erlaubt
+    ist, die Entwicklung neuer Gebiete im Regionsverzeichnis durchzufuehren.
+    
 
 2) Code wird zur Abnahme vorgelegt
 ==================================
 
-o Bei Waffen und Ruestungen unbedingt auf Einhaltung der Balance-Vorgaben
-  achten.
+o Bei Waffen und Ruestungen unbedingt darauf achten, dass Objekte, die die
+  Genehmigungsgrenzen ueberschreiten, bei der Balance zur Genehmigung 
+  vorgestellt wurden. Fuer alle Objekte mit Balance-relevanten Eigenschaften
+  bitte penibel darauf achten, dass die Balance-Vorgaben eingehalten werden.
+  Jeder Magier kann sich ein Balance-Tool "light" clonen, mit dem er den Text
+  der Genehmigung selbst anschauen kann, um den vorgelegten Code damit zu
+  vergleichen. Nicht genehmigte oder in der Funktion abweichende Objekte
+  duerfen nicht angeschlossen werden. (Bei schon sehr lange angeschlossenen
+  Objekten, deren Abweichung von der Genehmigung erst sehr spaet auffaellt,
+  kann man ggf. auf das temporaere Abhaengen verzichten.)
 
 o Sofern ein Objekt eine Balance-Genehmigung besitzt, muss die BTOP-Nummer,
   die die Balance als eindeutige ID fuer jeden Antrag vergibt, im Header
-  des betreffenden Objektes erkennbar eingetragen sein.
+  des betreffenden Objektes erkennbar eingetragen sein. Bevorzugt traegt
+  man auch die genehmigten Eigenschaften ein.
 
-o Vor Anschluss sollte man Ruecksprache mit verschiedenen Instanzen halten,
-  um sicherzustellen, dass der Magier alle wesentlichen Punkte
-  beruecksichtigt hat:
-  - liegen alle Balance-Genehmigungen vor?
-  - sind die FP eingetragen?
-  - sind die ZTs eingetragen und getestet?
-  - sind Sonder-EK-Stupse genehmigt und eingetragen?
-
-o Fuer neue Gebiete ist eine grundsaetzliche Pruefung des Konzepts auf
-  Regionstauglichkeit sinnvoll, damit nicht alteingesessene Institutionen
-  oder Orte ploetzlich zur zweiten Wahl abgewertet werden - beispielsweise
-  einen grossen, neuen Hauptort in der Ebene anzuschliessen, der Port Vain
-  voraussehbar den Rang ablaufen wuerde.
+o Vor Anschluss sollte man kontrollieren, dass der Magier alle wesentlichen 
+  Punkte beruecksichtigt hat:
+  - Liegen alle Balance-Genehmigungen vor? 
+    BTool light gibt's fuer alle, damit kann jeder fuer Objekte in seinem
+    Zustaendigkeitsbereich die Genehmigungen einsehen.
+  - Sind die FP eingetragen?
+    FP kann der RM fuer das neue Gebiet selbst abfragen. 
+  - Sind die ZTs eingetragen und getestet?
+    Dies laesst sich mit dem Magierkommando "traenke" herausfinden.
+  - Falls Sonder-EK-Stupse vorgesehen sind: sind diese genehmigt?
+    Die Eintragung bzw. Anpassung der Stufenpunkte fuer den Kill wird
+    erledigt, sobald der NPC das erste Mal getoetet wurde, dies muss also nicht
+    ueberprueft werden.
 
 o Alle NPCs sollten vor Anschluss einmal gekillt werden, um sie auf
   grundsaetzliche Kampf-Funktionsfaehigkeit zu pruefen.
@@ -104,24 +154,26 @@
   Formfehler in einem kompletten Verzeichnis ermitteln kann (Umlaute im
   Code, zu lange Zeilen etc.), wobei bezueglich der Formalien auch auf
   den Regionsmitarbeiter-Leitfaden fuer neue Projekte verwiesen werden
-  soll. Das Skript hierzu ist auf Anfrage bei Zesstra erhaeltlich. Der
-  Regionsmagier hat hierbei die Entscheidungsfreiheit, die Berichte dieses
-  Skripts dem Programmierer des neuen Gebiets als Anhaltspunkte zur
-  Verfuegung zu stellen, oder die Abarbeitung der gemeldeten Punkte als
-  Voraussetzung vor dem Anschluss vorzuschreiben, aber auch jede Abstufung
-  dazwischen ist OK. :-)
+  soll. Das Skript liegt im oeffentlichen Git-Repo "static-lpc-check" auf
+  dem MG-Gerrit-Server. Man kann es mit git oder ueber das Webinterface
+  herunterladen. Der Regionsmagier hat hierbei die Entscheidungsfreiheit,
+  die Berichte dieses Skripts dem Programmierer des neuen Gebiets als
+  Anhaltspunkte zur Verfuegung zu stellen, oder die Abarbeitung der 
+  gemeldeten Punkte zur Voraussetzung fuer den Anschluss zu machen, aber
+  auch jede Abstufung dazwischen ist OK. :-)
   Zusaetzlicher Tip: Das Skript differenziert zwischen eigentlich nicht
   akzeptablen Konstrukten und zumindest fragwuerdigen, d.h. man kann diese
   Unterscheidung an den Verantwortlichen mit entsprechenden Forderungen
   weitergeben.
-  Das Skript ist unter ftp://mg.mud.de/Software/src_check/ erhaeltlich.
 
-o Sollte ein zur Abnahme anstehendes Projekt eine (grundsaetzlich
+o Sollte ein zur Abnahme anstehendes Gesellenstueck eine (grundsaetzlich
   selbstverstaendlich zulaessige) Gemeinschaftsarbeit sein, sollte man
-  als Regionsmagier darauf bestehen, eine sauber getrennte Codebasis
-  in unterschiedlichen Verzeichnissen vorgelegt zu bekommen, oder aber
-  eine Auflistung, welcher Beitrag von welchem Magier stammt.
-  Wenn diese Auflistung sich bis auf Funktionsebene erstrecken sollte
+  darauf bestehen, eine sauber getrennte Codebasis in unterschiedlichen
+  Verzeichnissen vorgelegt zu bekommen, oder aber eine Auflistung, welcher
+  Beitrag von welchem Magier stammt. Es sollte klar sein, dass die
+  Beurteilung der Faehigkeiten eines Lehrlings darauf angewiesen ist, dass
+  man den Code richtig zuordnen kann.
+  Wenn eine solche Auflistung sich bis auf Funktionsebene erstreckt
   (z.B. "DoWield() ist von X, Details von Y, DefendFunc von Z"), ist
   das unschoen und an sich abzulehnen.
 
@@ -215,7 +267,7 @@
   {
     pl = find_player(lower_case(name1));
     if (!pl || !living(pl))
-      return 1;
+      return;
     else
       Kill(pl);
   }
@@ -296,13 +348,10 @@
 o for()-Schleifen
   Eigentlich keine Funktion, aber an dieser Stelle doch passend:
   for()-Schleifen sollten generell durch foreach()-Konstruktionen ersetzt
-  werden, da dies signifikant und messbar schneller ist. Die naechst-
-  schnellere Variante waere etwa folgendes, sofern die Reihenfolge der
-  Abarbeitung unerheblich ist (i ist integer, arr ist ein mixed-Array):
-
-  for ( i=sizeof(arr); i--; ) {
-    tu_etwas_mit(arr[i]);
-  }
+  werden, da dies signifikant und messbar schneller ist. Der groesste 
+  Zeit- und Kostenfaktor ist die Verwendung von sizeof() als Abbruchkriterium
+  in einer for()-Schleife. Wenn sich die Schleife also nicht ersetzen laesst,
+  dann nehmt zumindest einen konstanten Wert als Abbruchkriterium.
 
 o write_file()
   Benutzung dieser Funktion nur in begruendeten Ausnahmefaellen abnehmen, da
@@ -311,6 +360,10 @@
   verbrauchen, aber kaum zu ueberschauen sind. Statt write_file() wird in
   den allermeisten Faellen log_file() mit der Standardgroesse von 50 kB fuer
   Logfile und eine ggf. vorhandene Altversion (*.OLD) ausreichend sein.
+  Standardmaessig ist das Schreiben eines Questlog-Eintrages in /log/quest
+  der einzige Einsatzzweck, wo write_file() wirklich notwendig ist.
+  Ansonsten sind Ausnahmen vorstellbar, wenn die neuen Daten die alte Datei
+  komplett ersetzen, d.h. nicht angehaengt werden.
 
 o Verwalten von charakterbezogenen Daten
   Als Beispiel seien hier Statusdaten fuer den Ablauf von Quests genannt,