diff --git a/doc/lfun-liste b/doc/lfun-liste
index e7e21eb..17d737b 100644
--- a/doc/lfun-liste
+++ b/doc/lfun-liste
@@ -820,6 +820,8 @@
 
 * name()
 
+* normalize_defend_args()
+
 * notify_player_change()
 
 * pick()
diff --git a/doc/lfun/Defend b/doc/lfun/Defend
index 1de1f78..e5ee6ea 100644
--- a/doc/lfun/Defend
+++ b/doc/lfun/Defend
@@ -6,8 +6,8 @@
 FUNKTION
 ========
 
-   public int Defend(int dam, string|string* dam_type, int|mapping
-   spell,
+   public int Defend(int dam, string|string* dam_types, int|mapping
+   si_spell,
       object enemy)
 
 
@@ -23,12 +23,12 @@
    int dam
       Initiale Staerke des Angriffs (10 dam ~ 1 HP)
 
-   string* dam_type
+   string* dam_types
       Art des Schadens, der angerichtet werden soll Muss ein Array von
       Schadenstypen sein, alte Objekte uebergeben hier manchmal
       strings.
 
-   mapping spell
+   mapping si_spell
       Mapping mit zusaetzlichen Informationen zum Angriff(Siehe unten)
       Alte Objekte uebergeben manchmal einen Integer (0 fuer
       Physikalischen Angriff, 1 fuer Zauber.
@@ -61,58 +61,86 @@
    diverse Flags, die das Ergebnis manipulieren (in new_skills.h
    enthalten). Nichtangabe eines Flags gilt als 0.
 
-   * SP_PHYSICAL_ATTACK ---------- 0/1 1, wenn Ruestungen wirken
-     sollen, 0 sonst -> entspricht !spell, wenn dieses Int ist
+   * SP_PHYSICAL_ATTACK (int)
 
-   * SP_NO_ENEMY ----------------- 0/1 1, falls der Angriff nicht
-     toedlich ist, es also keinen echten Gegner gibt -> es wird dann
-     reduce_hit_points() gerufen statt do_damage()
+        1, wenn es ein physischer Angriff ist, d.h. Ruestungen wirken
+        sollen, 0 sonst. Dies entspricht dem alten !spell (wenn Spell
+        kein Mapping ist).
 
-   * SP_NO_ACTIVE_DEFENSE -------- 0/1 1, falls aktive Abwehren (wie
-     zurueckschlagende Amulette, Karateabwehren oder Ausweichmanoever)
-     unterbleiben sollen -> zB bei Kratzen durch Dornen oder Fall aus
-     grosser Hoehe ist aktive Abwehr oder Ausweichen unlogisch
+   * SP_NO_ENEMY (int)
 
-   * SP_RECURSIVE ---------------- 0/1 1, falls der Spell aus einem
-     Defend gerufen wurde (oder einer DefendFunc) -> verhindert
-     Rekursionsprobleme
+        1, falls der Angriff nicht toedlich ist, es also keinen echten
+        Gegner gibt. Es wird dann reduce_hit_points() gerufen statt
+        do_damage()
 
-   * SP_NAME --------------------- string Name des Spells
+   * SP_NO_ACTIVE_DEFENSE (int)
 
-   * SP_GLOBAL_ATTACK ------------ 0/1 1 bei Flaechenspells
+        1, falls aktive Abwehren (wie zurueckschlagende Amulette,
+        Karateabwehren oder Ausweichmanoever) unterbleiben sollen, zB
+        bei Kratzen durch Dornen oder Fall aus grosser Hoehe ist
+        aktive Abwehr oder Ausweichen unlogisch
 
-   * SP_REDUCE_ARMOUR ------------ Mapping: keys AT_X/P_BODY, values
-     int>=0 Die Schutzwirkung durch P_AC/Magie einer Ruestung wird
-     typabhaengig reduziert. Aufbau eines Mappings im Beispiel:
+   * SP_RECURSIVE (int)
 
-     ([AT_BOOTS: 0,  // Stiefel schuetzen gar nicht P_BODY:  50,  //
-     Koerper zu 50% AT_BELT: 600  // Guertel zu 600% ]) -> alle
-     'fehlenden' Eintraege wirken normal
+        1, falls der Spell aus einem Defend gerufen wurde (oder einer
+        DefendFunc). Dies ist sehr wichtig, um unendliche Rekursionen
+        zu vermeiden, wenn zwei zurueckschlagende Verteidigungen
+        zusammentreffen.
 
-   * SP_SHOW_DAMAGE -------------- 0/1 oder Array von Arrays 0, fuer
-     keine Treffermeldung, 1 sonst In einem Array koennen Ersatz-
-     Treffermeldungen definiert werden. Format ist:
+   * SP_NAME (string)
 
-        ({ ({ int lphit1, string mess_me, string mess_en, string
-        mess_room }), ({ lphit2, mess_me, mess_en, mess_room }), ...
-        ({ lphitn, mess_me, mess_en, mess_room }), }) wobei
-        lphit1<lphit2<...<lphitn sein muss, d.h. das Array-Array
-        aufsteigend sortiert.
+        Name des Spells
 
-     Ist ein Treffer x LP hart, werden die Meldungen des lphit-Arrays
-     ausgegeben, dessen Wert am naehesten unter dem Schaden liegt.
+   * SP_GLOBAL_ATTACK (int)
 
-     In den Meldungen mess_me (an den Getroffenen), mess_en (an den
-     Feind), mess_room (an die restlichen Umstehenden) koennen
-     Ersatzstrings wie folgt verwendet werden:
+        1 bei Flaechenspells (die mehrere Ziele treffen koennen)
 
-     @WER1/@WESSEN1/@WEM1/@WEN1 - name(casus) des Getroffenen (TO)
-     @WER2/@WESSEN2/@WEM2/@WEN2 - name(casus) des Feindes (enemy)
+   * SP_REDUCE_ARMOUR (mapping) ------------ Mapping: keys
+     AT_X/P_BODY, values int>=0
 
-     EINFO_DEFEND ------------ Mapping Dieses Mapping liefert
-     erweiterte Informationen zu dem bisherigen Ablauf des aktiven
-     Attacks. Die verfuegbaren Informationen sind in der Manpage zu
-     DefendInfo festgehalten.
+        Die Schutzwirkung durch P_AC/Magie einer Ruestung wird
+        typabhaengig reduziert. Als Keys sind P_BODY und die AT_*
+        erlaubt, die Werte muessen ints > 0 sein. Aufbau eines
+        Mappings im Beispiel:
+
+           ([AT_BOOTS: 0,  // Stiefel schuetzen gar nicht
+             P_BODY:  50,  // Koerper zu 50%
+             AT_BELT: 600  // Guertel zu 600%
+           ])
+           -> alle 'fehlenden' Eintraege wirken normal
+
+   * SP_SHOW_DAMAGE (int or Array von Array)
+
+        0 fuer keine Treffermeldung, 1 fuer Standardtreffermeldungen.
+        Falls individuelle Treffermeldungen geschwuenscht sind,
+        koennen aber auch in einem Array Ersatz-Treffermeldungen
+        definiert werden. Das Format ist:
+
+           ({
+           ({ int lphit1, string mess_me, string mess_en, string mess_room }),
+           ({ lphit2, mess_me, mess_en, mess_room }),
+           ...
+           ({ lphitn, mess_me, mess_en, mess_room }),
+           })
+           wobei lphit1<lphit2<...<lphitn sein muss, d.h. das Array-Array
+           aufsteigend sortiert.
+
+        Ist ein Treffer x LP hart, werden die Meldungen des lphit-
+        Arrays ausgegeben, dessen Wert am naehesten unter dem Schaden
+        liegt.
+
+        In den Meldungen mess_me (an den Getroffenen), mess_en (an den
+        Feind), mess_room (an die restlichen Umstehenden) koennen
+        Ersatzstrings wie folgt verwendet werden:
+
+           @WER1/@WESSEN1/@WEM1/@WEN1 - name(casus) des Getroffenen (TO)
+           @WER2/@WESSEN2/@WEM2/@WEN2 - name(casus) des Feindes (enemy)
+
+   * EINFO_DEFEND (mapping)
+
+        Dieses Mapping liefert erweiterte Informationen zu dem
+        bisherigen Ablauf des aktiven Attacks. Die verfuegbaren
+        Informationen sind in der Manpage zu DefendInfo festgehalten.
 
 
 Reihenfolgen in Defend
@@ -192,6 +220,6 @@
    Resistenz: P_RESISTANCE_STRENGTHS, CheckResistance()
 
    Sonstiges: CheckSensitiveAttack(), InternalModifyDefend(),
-   UseSkill(), DefendInfo()
+   normalize_defend_args() UseSkill(), DefendInfo()
 
-Letzte Aenderung: 29.12.2017, Bugfix
+Letzte Aenderung: 20.01.2019, Zesstra
diff --git a/doc/lfun/InternalModifyDefend b/doc/lfun/InternalModifyDefend
index efe50ab..7fbfae5 100644
--- a/doc/lfun/InternalModifyDefend
+++ b/doc/lfun/InternalModifyDefend
@@ -10,8 +10,8 @@
 FUNKTION
 ========
 
-   protected void InternalModifyDefend(int dam, string* dt, mapping
-   spell, object enemy)
+   protected void InternalModifyDefend(int dam, string* dam_types,
+      mapping si_spell, object enemy)
 
 
 DEFINIERT IN
@@ -26,10 +26,10 @@
    int dam
       Staerke des abzuwehrenden Angriffs (in HP/10)
 
-   string* dt
+   string* dam_types
       Art(en) des Schadens, der angerichtet werden soll
 
-   mapping spell
+   mapping si_spell
       Mapping mit zusaetzlichen Informationen ueber den Angriff
 
    object enemy
diff --git a/doc/lfun/normalize_defend_args b/doc/lfun/normalize_defend_args
new file mode 100644
index 0000000..7b41e74
--- /dev/null
+++ b/doc/lfun/normalize_defend_args
@@ -0,0 +1,89 @@
+
+normalize_defend_args()
+***********************
+
+
+FUNKTION
+========
+
+   protected nomask void normalize_defend_args(int dam,
+      string|string* dam_types, int|mapping si_spell, object enemy)
+
+
+DEFINIERT IN
+============
+
+   /std/living/combat.c
+
+
+ARGUMENTE
+=========
+
+   Die Argumente sind die Argumente, welche Defend() uebergeben
+   bekommt (siehe dort!)
+
+
+BESCHREIBUNG
+============
+
+   Defend bekommt aus historischem Code haeufig Argumente uebergeben,
+   die nicht der aktuellen Konvention entsprechen (z.B. si_spell als 0
+   oder 1 statt eines Mappings). Damit nun nicht jedes Objekt seine
+   eigene Anpassung vornehmen muss und dabei evtl. noch etwas
+   vergessen wird, kann man mit dieser Funktion die Argumente genauso
+   "normieren", wie es in der Standardlib in Defend() auch gemacht
+   wuerde.
+
+   Dieses wird ganz dringend empfohlen statt diese Normierung selber
+   vorzunehmen. Und sollte es hier Aenderungen geben, bekommt man
+   diese automatisch mit.
+
+   Nach dem Aufruf dieser Funktion (Argumente als Referenz
+   uebergeben!) liegen die Argumente dann wie folgt vor:
+
+   dam
+      ein Integer (unveraendert)
+
+   dam_types
+      ein Array von Schadenstypen
+
+   si_spell
+      ein Mapping - wenn es neu angelegt wurde, enthaelt es die
+      Eintraege SP_PHYSICAL_ATTACK, SP_SHOW_DAMAGE, SP_REDUCE_ARMOUR
+      und EINFO_DEFEND. SP_PHYSICAL_ATTACK und SP_SHOW_DAMAGE sind 1,
+      wenn si_spell 0 wahr, sonst 1.
+
+   enemy
+      ist das Objekt des Gegners oder this_player()
+
+   Alternativ zum Ueberschreiben von Defend() und Nutzung dieser
+   Funktion ist haeufig auch InternalModifyDefend() gut geeignet. Dort
+   muss *keine* eigene Normierung der uebergebenen Argumente mehr
+   vorgenommen werden!
+
+
+BEISPIELE
+=========
+
+   // Ein eigenes Defend soll Dinge tun, bevor das geerbte Defend() gerufen
+   // wird. Um den Code zu vereinfachen, sollen die Typen der Argumente aber
+   // schon sicher in einem "normierten Zustand" sein.
+   public int Defend(int dam, string|string* dam_types, int|mapping spell,
+                     object enemy)
+   {
+     // Uebergabe per Referenz noetig!
+     normalize_defend_args(&dam, &dam_type, &spell, &enemy);
+     if (member(dam_types, DT_FIRE) > -1
+         && si_spell[SP_NAME] == "Drachenfeuer")
+       dam *= 2; // Schaden verdoppeln
+     return ::Defend(dam, dam_types, si_spell, enemy);
+   }
+
+
+SIEHE AUCH
+==========
+
+   Verwandt:
+      InternalModifyDefend(), Defend(), DefendInfo()
+
+16.01.2019 Zesstra
diff --git a/doc/props/P_AVERAGE_SIZE b/doc/props/P_AVERAGE_SIZE
index 155528f..0208ef4 100644
--- a/doc/props/P_AVERAGE_SIZE
+++ b/doc/props/P_AVERAGE_SIZE
@@ -18,4 +18,15 @@
 BESCHREIBUNG
 ============
 
-   Durchschnittliche Groesse eines Wesens dieser Rasse (derzeit nur Player)
+   Durchschnittliche Groesse eines Wesens dieser Rasse (in cm).
+   Bei den Rassen im Morgengrauen sind das:
+
+                Menschen    175
+                Magier      sind im Durchschnitt etwas groesser ;-)
+                Orks        195
+                Hobbits     105
+                Goblins      80
+                Felinen     200
+                Zwerge      120
+                Elfen       195
+                Dunkelfen   175
diff --git a/doc/props/P_SECOND b/doc/props/P_SECOND
index 69c97d6..dc0a6f7 100644
--- a/doc/props/P_SECOND
+++ b/doc/props/P_SECOND
@@ -6,7 +6,7 @@
 NAME
 ====
 
-   P_SECOND                      "second"
+   P_SECOND "second"
 
 
 DEFINIERT IN
@@ -18,8 +18,18 @@
 BESCHREIBUNG
 ============
 
-   Wenn diese Prop gesetzt ist, ist der Spieler ein Zweitie. Inhalt der
-   Prop ist ein String mit dem (lowercase) Namen des Ersties.
+   Wenn diese Prop gesetzt ist, ist der Spieler ein Zweitie. Inhalt
+   der Prop ist ein String mit dem (lowercase) Namen des Ersties. Ob
+   anderen Spielern angezeigt wird, dass jemand Zweitie ist, kann
+   mittels der Property P_SECOND_MARK gesteuert werden.
+
+   Bitte auch das Konzept der Familie beachten (s. FAMILIEN) und
+   speziell bei Aenderung von P_SECOND ggf. die Familie eintragen
+   lassen.
+
+   Soll ein Spieler kein Zweitie mehr sein, bitte zusaetzlich zum
+   Loeschen dieser Property den Zweitieeintrage auch in
+   /secure/zweities loeschen (lassen).
 
 
 BEISPIEL
@@ -33,7 +43,16 @@
 SIEHE AUCH
 ==========
 
-   Properties: P_SECOND_MARK
-   Sonstiges:  /secure/zweities.c
+   Familien:
+      FAMILIEN
 
-Last modified: 18-Jun-2015, Arathorn.
+   Kommandos:
+      *../pcmd/zweitiemarkierung*
+
+   Properties:
+      P_SECOND_MARK
+
+   Sonstiges:
+      /secure/zweities.c
+
+Last modified: 08.01.2019, Zesstra
diff --git a/doc/wiz.index b/doc/wiz.index
index f402650..bf37c11 100644
--- a/doc/wiz.index
+++ b/doc/wiz.index
@@ -9,4 +9,10 @@
 
 Verzeichnis der Manpages:
 
+* FAMILIEN
+
+* Erstellung neuer Repositories in Gerrit
+
+* Hinweise fuer Erzmagier / Admins
+
 * Homemud
diff --git a/doc/wiz/familien b/doc/wiz/familien
index 5998c3c..6f1d305 100644
--- a/doc/wiz/familien
+++ b/doc/wiz/familien
@@ -1,52 +1,67 @@
+
 FAMILIEN
-========
+********
+
 
 BESCHREIBUNG
-------------
+============
 
-Eine Familie umfasst den Erstie und alle Zweities, sprich alle diese haben den
-gleichen "Familiennamen". Dieser Name ist in der Regel die UUID des Ersties
-dieser Familie. Falls aber der Erstie sich aendern sollte (z.B. Magierwerdung
-eines Zweities) und sich der Familienname nicht aendern soll, dann koennen
-wir den Namen dieser Familie beibehalten (d.h. alter Erstie).
+   Eine Familie umfasst den Erstie und alle Zweities, sprich alle
+   diese haben den gleichen "Familiennamen". Dieser Name ist in der
+   Regel die UUID des Ersties dieser Familie. Falls aber der Erstie
+   sich aendern sollte (z.B. Magierwerdung eines Zweities) und sich
+   der Familienname nicht aendern soll, dann koennen wir den Namen
+   dieser Familie beibehalten (d.h. alter Erstie).
 
-Will man wissen, welcher Familie ein Char angehoert (egal, ob Erstie oder
-Zweitie), dann geht das mit:
-# xcall /secure/zweities->QueryFamilie(player_object)
+   Will man wissen, welcher Familie ein Char angehoert (egal, ob
+   Erstie oder Zweitie), dann geht das mit:
 
-Des Weiteren liefert dieses Objekt auch noch zu jedem Zweitie den Erstie und
-zu jedem Erstie die Liste aller bekannten Zweities:
-# xcall /secure/zweities->QueryErstieName(player_object)
-# xcall /secure/zweities->QueryErstieUUID(player_object)
-# xcall /secure/zweities->QueryZweities(player_object)
+      # xcall /secure/zweities->QueryFamilie(player_object)
 
-Der Datenbestand ist (noch) nicht vollstaendig, daher fehlen da noch viele
-Chars. Die werden aber in absehbarer Zeit dort nachgetragen.
+   Des Weiteren liefert dieses Objekt auch noch zu jedem Zweitie den
+   Erstie und zu jedem Erstie die Liste aller bekannten Zweities:
 
-Die Familie wird in Zukunft genutzt, um Dinge zu personalisieren, welche fuer
-den Spieler, aber nicht fuer den Char individuell sein sollen. Sprich:
-personalisiert man irgendwas ueber die Familie, koennen alle Chars dieser
-Familie das irgendwas nutzen.
+      # xcall /secure/zweities->QueryErstieName(player_object)
+      # xcall /secure/zweities->QueryErstieUUID(player_object)
+      # xcall /secure/zweities->QueryZweities(player_object)
+
+   Der Datenbestand ist (noch) nicht vollstaendig, daher fehlen da
+   noch viele Chars. Die werden aber in absehbarer Zeit dort
+   nachgetragen.
+
+   Die Familie wird in Zukunft genutzt, um Dinge zu personalisieren,
+   welche fuer den Spieler, aber nicht fuer den Char individuell sein
+   sollen. Sprich: personalisiert man irgendwas ueber die Familie,
+   koennen alle Chars dieser Familie das irgendwas nutzen.
+
 
 VERWALTUNG
-----------
+==========
 
-Wenn sich der Erstie aendert, aber die Familie aller Zweities erhalten bleiben
-soll (z.B. weil sich der Erstie innerhalb der Familie wegen Magierwerdung
-aendert), muss dies in der Familienverwaltung hinterlegt werden, indem fuer
-den *neuen* Erstie die alte Familien-ID eingetragen wird. Dies koennen zur
-Zeit EM+.
+   Wenn sich der Erstie aendert, aber die Familie aller Zweities
+   erhalten bleiben soll (z.B. weil sich der Erstie innerhalb der
+   Familie wegen Magierwerdung aendert), muss dies in der
+   Familienverwaltung hinterlegt werden, indem fuer den *neuen* Erstie
+   die alte Familien-ID eingetragen wird. Dies koennen zur Zeit EM+.
 
-Beispiel: Der alte Erstie einer Familie ist bert_123456, der neue Erstie ist
-alice_654321. Die Familie soll aber weiterhin bert_123456 sein:
-# xcall /secure/zweities->SetFamilie("alice_654321, "bert_123456")
-Ein solcher expliziter Familieneintrag kann wieder geloescht werden:
-# xcall /secure/zweities->DeleteFamilie("alice_654321")
+   Beispiel: Der alte Erstie einer Familie ist bert_123456, der neue
+   Erstie ist alice_654321. Die Familie soll aber weiterhin
+   bert_123456 sein:
 
-EM+ koennen Zweities wieder aus der Datenbank loeschen (UUID angeben!):
-# xcall /secure/zweities->DeleteZweitie("bert_12345")
+      # xcall /secure/zweities->SetFamilie("alice_654321, "bert_123456")
 
+   Ein solcher expliziter Familieneintrag kann wieder geloescht
+   werden:
+
+      # xcall /secure/zweities->DeleteFamilie("alice_654321")
+
+   EM+ koennen Zweities wieder aus der Datenbank loeschen (UUID
+   angeben!):
+
+      # xcall /secure/zweities->DeleteZweitie("bert_12345")
+
+SIEHE AUCH:
+   P_SECOND, P_SECOND_MARK
 
 LETZTE AeNDERUNG:
-  8.1.2019, Zesstra
-
+   8.1.2019, Zesstra