diff --git a/doc/lfun-liste b/doc/lfun-liste
index 17d737b..b1d7830 100644
--- a/doc/lfun-liste
+++ b/doc/lfun-liste
@@ -90,6 +90,8 @@
 
 * Attack()
 
+* AutoAttack()
+
 * BecomesNetAlive()
 
 * BecomesNetDead()
@@ -258,6 +260,8 @@
 
 * Halt()
 
+* HasExtraLook()
+
 * HasMiniQuest()
 
 * HitFunc()
diff --git a/doc/lfun/AutoAttack b/doc/lfun/AutoAttack
new file mode 100644
index 0000000..2e94201
--- /dev/null
+++ b/doc/lfun/AutoAttack
@@ -0,0 +1,82 @@
+
+AutoAttack()
+************
+
+
+FUNKTION
+========
+
+   int AutoAttack(object ob)
+
+
+DEFINIERT IN
+============
+
+   /std/npc/combat
+
+
+ARGUMENTE
+=========
+
+   object ob
+      Das ggf. annzugreifende Object. (Achtung, nicht nur Livings)
+
+
+BESCHREIBUNG
+============
+
+   Diese Funktion wird aus heart_beat() heraus aufgerufen. Sie
+   bestimmt, ob ein Living automatisch angegriffen werden soll oder
+   nicht.
+
+
+RUeCKGABEWERT
+=============
+
+   1 fuer Angriff, sonst 0.
+
+
+BEMERKUNGEN
+===========
+
+   Da diese Funktion aus heart_beat() heraus aufgerufen wird, und zwar
+   einmal pro anwesendem Objekt (nicht nur fuer Livings), sollte man
+   hier moeglichst wenig Dinge tun. Verzichtet am besten ganz auf die
+   Nutzung, falls irgendwie moeglich.
+
+   Da auch NPCs uebergeben werden, kann man hier auch diese
+   automatisch angreifen lassen, was normalerweise nicht der Fall ist.
+   Dies funktioniert jedoch nur, wenn der heart_beat() eingeschaltet
+   ist, also normalerweise nicht in Abwesenheit von Spielern.
+
+
+BEISPIELE
+=========
+
+   inherit "/std/npc";
+
+   #include <npc.h>
+
+   protected void create()
+   {
+     ...
+     SetProp(P_AGGRESSIVE,1);
+     ...
+   }
+
+   // Keine Leute angreifen, die auf der Freundesliste stehen.
+   // Bei dieser Variante wir das P_AGGRESSIVE in ob nicht ausgewertet, falls
+   // ob als Freund erkannt wird.
+   int AutoAttack(object ob)
+   {
+     if(member(freunde,ob)!=-1) return 0;
+     else return ::AutoAttack(ob);
+   }
+
+
+SIEHE AUCH
+==========
+
+   heart_beat(), P_AGGRESSIVE
+
+Letzte Aenderung: 28.08.2019, Bugfix
diff --git a/doc/lfun/Defend b/doc/lfun/Defend
index e5ee6ea..189e6b5 100644
--- a/doc/lfun/Defend
+++ b/doc/lfun/Defend
@@ -6,9 +6,8 @@
 FUNKTION
 ========
 
-   public int Defend(int dam, string|string* dam_types, int|mapping
-   si_spell,
-      object enemy)
+   public int Defend(int dam, string|string* dam_types,
+      int|mapping si_spell, object enemy)
 
 
 DEFINIERT IN
@@ -53,13 +52,13 @@
    aber nicht unter 0.
 
 
-Der Parameter 'spell'
----------------------
+Der Parameter 'si_spell'
+------------------------
 
-   Ist 'spell' 0, dann gilt der Angriff als normale physische Attacke
-   Uebergibt man als 'spell'-Parameter ein Mapping, so gibt es dafuer
-   diverse Flags, die das Ergebnis manipulieren (in new_skills.h
-   enthalten). Nichtangabe eines Flags gilt als 0.
+   Ist 'si_spell' 0, dann gilt der Angriff als normale physische
+   Attacke Uebergibt man als 'si_spell'-Parameter ein Mapping, so gibt
+   es dafuer diverse Flags, die das Ergebnis manipulieren (in
+   new_skills.h enthalten). Nichtangabe eines Flags gilt als 0.
 
    * SP_PHYSICAL_ATTACK (int)
 
@@ -95,13 +94,12 @@
 
         1 bei Flaechenspells (die mehrere Ziele treffen koennen)
 
-   * SP_REDUCE_ARMOUR (mapping) ------------ Mapping: keys
-     AT_X/P_BODY, values int>=0
+   * SP_REDUCE_ARMOUR (mapping) ------------
 
-        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:
+        Mapping: keys AT_X/P_BODY, values int>=0 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%
@@ -196,30 +194,37 @@
    enem->Defend(100, ({DT_BLUDGEON}), ([SP_PHYSICAL_ATTACK:1]), this_object());
 
    // ein magischer Angriff (ohne Treffermeldung):
-   enem->Defend(100, ({DT_BLUDGEON, DT_FIRE}), ([SP_PHYSICAL_ATTACK:0]), this_object());
+   enem->Defend(100, ({DT_BLUDGEON, DT_FIRE}), ([SP_PHYSICAL_ATTACK:0]),
+                this_object());
 
    // ein magischer Angriff mit Treffermeldung:
    enem->Defend(100, ({DT_BLUDGEON, DT_FIRE}), ([SP_SHOW_DAMAGE:1]),
-     this_object());
+                this_object());
 
 
 SIEHE AUCH
 ==========
 
-   Angriff: Attack(), P_NO_ATTACK, InsertEnemy()
+   Angriff:
+      Attack(), P_NO_ATTACK, InsertEnemy()
 
-   Schaden:   P_ENABLE_IN_ATTACK_OUT, P_LAST_MOVE, do_damage(),
-   reduce_hit_points()
+   Schaden:
+      P_ENABLE_IN_ATTACK_OUT, P_LAST_MOVE, do_damage(),
+      reduce_hit_points()
 
-   Schutz:    P_DEFENDERS, InformDefend(), DefendOther(), P_ARMOURS,
-   P_AC, P_DEFEND_FUNC, QueryDefend(), P_BODY
+   Schutz:
+      P_DEFENDERS, InformDefend(), DefendOther(), P_ARMOURS, P_AC,
+      P_DEFEND_FUNC, QueryDefend(), P_BODY
 
-   Daten:     P_LAST_COMBAT_TIME, P_LAST_DAMTYPES, P_LAST_DAMTIME,
-   P_LAST_DAMAGE, P_DAMAGE_MSG
+   Daten:
+      P_LAST_COMBAT_TIME, P_LAST_DAMTYPES, P_LAST_DAMTIME,
+      P_LAST_DAMAGE, P_DAMAGE_MSG
 
-   Resistenz: P_RESISTANCE_STRENGTHS, CheckResistance()
+   Resistenz:
+      P_RESISTANCE_STRENGTHS, CheckResistance()
 
-   Sonstiges: CheckSensitiveAttack(), InternalModifyDefend(),
-   normalize_defend_args() UseSkill(), DefendInfo()
+   Sonstiges:
+      CheckSensitiveAttack(), InternalModifyDefend(),
+      normalize_defend_args(), UseSkill(), DefendInfo()
 
 Letzte Aenderung: 20.01.2019, Zesstra
diff --git a/doc/lfun/DefendOther b/doc/lfun/DefendOther
index 0d36fc2..2b706f5 100644
--- a/doc/lfun/DefendOther
+++ b/doc/lfun/DefendOther
@@ -6,8 +6,8 @@
 FUNKTION
 ========
 
-   public <int|string*|mapping>* DefendOther(int dam, string|string* dam_type,
-                                             int|mapping spell, object enemy)
+   public <int|string*|mapping>* DefendOther(int dam, string* dam_type,
+                                       int|mapping si_spell, object enemy)
 
 
 DEFINIERT IN
@@ -19,16 +19,20 @@
 ARGUMENTE
 =========
 
-   dam
+   int dam
      Der Schaden, der voraussichtlich beim zu verteidigenden Lebewesen
      verursacht werden soll.
-   dam_type
+
+   string* dam_type
      Der Schadenstyp (oder die Schadenstypen), der beim zu
      verteidigenden Lebewesen verursacht werden sollen.
-   spell
-     Wenn das zu verteidigende Lebewesen mit Spells angegriffen wurde,
-     so koennte man hier mehr Infos entnehmen.
-   enemy
+
+   mapping si_spell
+     Mapping mit zusaetzlichen Informationen zum Angriff
+     Alte Objekte uebergeben manchmal einen Integer (0 fuer
+     physikalischen Angriff, 1 fuer Zauber.
+
+   object enemy
      Der Feind, der ein zu verteidigendes Lebewesen angegriffen hat.
 
 
@@ -37,9 +41,9 @@
 
    Array mit den Eintraegen der gegebenenfalls veraenderten
    uebergebenen Parameter:
-       (1) dam      [Typ int],
-       (2) dam_type [Typ string*],
-       (3) spell    [Typ mapping].
+           (1) dam      [Typ int],
+           (2) dam_type [Typ string*],
+           (3) spell    [Typ mapping].
 
 
 BESCHREIBUNG
@@ -52,15 +56,18 @@
    Zumeist wird es sich bei den Objekten natuerlich ebenfalls um
    andere Lebewesen handeln, die das Lebewesen, bei dem sie angemeldet
    sind, verteidigen sollen.
+
    Bei einem Angriff auf das Lebewesen koennen alle Objekte per Aufruf
    von DefendOther() in einen Angriff eingreifen, wobei die
    Schadensstaerke, der Schadenstyp (die Schadenstypen),
    Zusatzinformationen fuer Angriffsspells und der Angreifer als
    Parameter uebergeben werden.
-   Desweiteren ist zu beachten, dass bei als physikalisch markierten
+
+   Des weiteren ist zu beachten, dass bei als physikalisch markierten
    Angriffen in einem Team nur Verteidiger aus der ersten Reihe
    beruecksichtigt werden und dass bei einem Angriff zufaellig aus
    allen moeglichen Verteidigern ausgewaehlt wird.
+
    Standardmaessig ist diese Funktion in Lebewesen bereits definiert,
    wobei der Skill SK_DEFEND_OTHER, sofern vorhanden, aufgerufen wird.
 
@@ -70,29 +77,37 @@
 
    Sehr beliebt sind in Gilden NPCs, die den Beschwoerer begleiten und
    verteidigen, z.B. beschworene Daemonen:
-     inherit "std/npc";
-     include <properties.h>
-     object owner;
-     void create()
-     { ::create();
-       SetProp(P_NAME,"Daemon");
-       ...
-     }
+
+   inherit "/std/npc";
+
+   include <properties.h>
+
+   object owner;
+
+   void create() {
+     ::create();
+     SetProp(P_NAME,"Daemon");
+     ...
+   }
+
    // nach Clonen des Daemons folgende Funktion mit Beschwoerer als
    // Parameter aufrufen
-     Identify(object caster)
-     { if(!objectp(caster))
-         call_out(#'remove,0);
-       owner=caster;
-       owner->AddDefender(this_object());
-     }
+   void Identify(object caster) {
+     if (!objectp(caster))
+       call_out(#'remove,0);
+     owner = caster;
+     owner->AddDefender(this_object());
+   }
+
    // der Daemon wehrt jeden Angriff mit Feuer voll ab, man muss zuerst
    // den Verteidiger umbringen, um den Beschwoerer toeten zu koennen
-     mixed DefendOther(int dam,mixed dam_type,mixed spell,object enemy)
-     { if(sizeof(dam_type)&&member_array(DT_FIRE,dam_type)!=-1)
-         dam=0;
-       return({dam,dam_type,spell});
-     }
+   public <int|string*|mapping>* DefendOther(int dam,
+       string|string* dt, int|mapping spell, object enemy) {
+     if (sizeof(dt) && member(dt, DT_FIRE) != -1)
+       dam = 0;
+     return ({dam, dam_type, spell});
+   }
+
    Soll der Daemon sich auch in ein Team einordnen, in welchem sich der
    Beschwoerer eventuell befindet, so ist zusaetzlich AssocMember() in
    diesem Beschwoerer aufzurufen, wobei der Daemon als Parameter
@@ -102,7 +117,14 @@
 SIEHE AUCH
 ==========
 
-   AddDefender(), RemoveDefender(), InformDefend(), Kill(), IsEnemy(),
-   P_DEFENDERS, /std/living/combat.c, /sys/new_skills.h
+   Funktionen:
+      AddDefender(), RemoveDefender(), InformDefend(), Kill(),
+      IsEnemy(), Defend()
 
-Last modified: Fri Feb 25 14:45:00 2000 by Paracelsus
+   Properties
+      P_DEFENDERS
+
+   Objekte:
+      /std/living/combat.c, /sys/new_skills.h
+
+Last modified: 2019-Aug-26, Arathorn
diff --git a/doc/lfun/second_life b/doc/lfun/second_life
index d40c63e..1ab849f 100644
--- a/doc/lfun/second_life
+++ b/doc/lfun/second_life
@@ -6,7 +6,7 @@
 FUNKTION
 ========
 
-   varargs int second_life(object obj);
+   protected varargs int second_life(object corpse);
 
 
 DEFINIERT IN
@@ -18,7 +18,7 @@
 ARGUMENTE
 =========
 
-   obj
+   corpse
       Leiche des Lebewesens (sofern es eine hat)
 
 
@@ -46,9 +46,35 @@
       wenn das Objekt im Tod nicht zerstoert wird (Spieler)
 
 
+BEMERKUNGEN
+===========
+
+   Das Inventar des Livings wurde bei Aufruf von second_live()
+   normalerweise schon in die Leiche bewegt, sofern diese existiert.
+   War das Inventar sehr gross, koennen allerdings noch vereinzelte
+   Objekte im Living sein, die erst spaeter bewegt werden. Will man
+   noch Gegenstaende hinzufuegen, muss man diese direkt in die Leiche
+   bewegen, *nicht* in das gestorbene Lebewesen.
+
+
+BEISPIEL
+========
+
+   protected varargs int second_life(object corpse)
+   {
+     // Wenn man sich wirklich sicher ist, dass das Lebewesen eine Leiche
+     // hat (weil es der eigene NPC ist), ist es verfuehrerisch, die Pruefung
+     // auf die Existenz der Leiche wegzulassen. Aber auch dann koennte es ja
+     // passieren, dass diese vom Raum bereits zerstoert wurde.
+     if (corpse)
+         corpse->AddItem("tolle_trophaehe",REFRESH_NONE);
+     return 0;
+   }
+
+
 SIEHE AUCH
 ==========
 
    die()
 
-Last modified: 17.03.2019, Zesstra
+Letzte Aenderung: 04.09.2019, Bugfix
diff --git a/doc/pcmd/telnet b/doc/pcmd/telnet
index 489708f..1c04d71 100644
--- a/doc/pcmd/telnet
+++ b/doc/pcmd/telnet
@@ -31,7 +31,7 @@
       verschluesselt ist, so dass auf dem Weg niemand mitlesen kann.
 
  SIEHE AUCH:
-    telnegs, telnet keepalive, telnet gmcp
+    telnegs, telnet_keepalive, telnet gmcp
     P_TELNET_KEEPALIVE_DELAY
 
  LETZTE AeNDERUNG:
diff --git a/doc/props/P_AGGRESSIVE b/doc/props/P_AGGRESSIVE
index 5184687..8cff142 100644
--- a/doc/props/P_AGGRESSIVE
+++ b/doc/props/P_AGGRESSIVE
@@ -12,7 +12,7 @@
 DEFINIERT IN
 ============
 
-   /sys/properties.h
+   /sys/npc.h
 
 
 BESCHREIBUNG
@@ -20,36 +20,45 @@
 
    Gesetzt, wenn das Wesen von sich aus Angriffe startet.
 
-   Ueblicherweise nimmt man als Wert 1, man kann jedoch auch
-   einen kleineren Wert nehmen wenn es nur mit einer bestimmten
+   Ueblicherweise nimmt man als Wert 1, man kann jedoch auch einen
+   kleineren Wert nehmen wenn es nur mit einer bestimmten
    Wahrscheinlichkeit automatisch angreifen soll.
 
    Der Wert von Spieler und Monster wird addiert, um zu entscheiden,
-   ob ein Spieler angegriffen werden soll, man kann P_AGGRESSIVE
-   also auch bei Spielern setzen, so dass sie von allen Monstern
+   ob ein Spieler angegriffen werden soll, man kann P_AGGRESSIVE also
+   auch bei Spielern setzen, so dass sie von allen Monstern
    angegriffen werden.
 
    Bei Monstern (und NUR bei diesen) kann man hier auch ein Mapping
    angeben, das als Keys Namen von Properties des Spielers enthaelt
    und als Values Mappings, in denen steht welcher Wert bei welchen
-   Wert fuer die Property genommen werden soll (Beispiele folgen).
-   Mit Key 0 kann man einen Default-Wert (sowohl in inneren Mappings
-   wie auch im aeusseren Mapping) festlegen. Default-Werte werden
+   Wert fuer die Property genommen werden soll (Beispiele folgen). Mit
+   Key 0 kann man einen Default-Wert (sowohl in inneren Mappings wie
+   auch im aeusseren Mapping) festlegen. Default-Werte werden
    genommen, falls keine anderen gesetzt sind, also Vorsicht mit
-   0-Eintraegen (Tip: 0.0 ist in LPC ungleich 0).
-   Bei mehreren Properties werden alle gesetzten Werte gemittelt.
+   0-Eintraegen (Tip: 0.0 ist in LPC ungleich 0). Bei mehreren
+   Properties werden alle gesetzten Werte gemittelt.
 
 
 BEISPIELE
 =========
 
    SetProp(P_AGGRESSIVE,([P_RACE:(["Zwerg":1, "Elf":0.0, 0:0.5])]))
-   Zwerge werden immer automatisch angegriffen, Elfen nie und
-   alle anderen mit 50% Wahrscheinlichkeit.
-   Man beachte, dass hier 0.0 genommen werden musste anstelle von 0,
-   weil sonst Elfen auch 50% Wahrscheinlichkeit bekommen haetten.
+   Zwerge werden immer automatisch angegriffen, Elfen nie und alle
+   anderen mit 50% Wahrscheinlichkeit. Man beachte, dass hier 0.0
+   genommen werden musste anstelle von 0, weil sonst Elfen auch 50%
+   Wahrscheinlichkeit bekommen haetten.
 
    SetProp(P_AGGRESSIVE,([P_RACE:(["Zwerg":0.3]),
-                          P_GUILD:(["Chaos":0.7])]))
-   Zwerge werden mit 30% Wahrscheinlichkeit angegriffen,
-   Chaoten mit 70% und Zwerg-Chaoten mit 50%.
+      P_GUILD:(["Chaos":0.7])]))
+
+   Zwerge werden mit 30% Wahrscheinlichkeit angegriffen, Chaoten mit
+   70% und Zwerg-Chaoten mit 50%.
+
+
+SIEHE AUCH
+==========
+
+   Kill(), AutoAttack()
+
+Letzte Aenderung: 28.08.2019, Bugfix
diff --git a/doc/props/P_LIGHT_TYPE b/doc/props/P_LIGHT_TYPE
index 47abbf4..120cbc4 100644
--- a/doc/props/P_LIGHT_TYPE
+++ b/doc/props/P_LIGHT_TYPE
@@ -20,25 +20,19 @@
 
    Gibt an, was fuer ein Licht in einem Objekt vorherrscht.
 
-
-
-   Es sind verschiedene 'atomare' Lichttypen, vordefiniert:
+   Es sind verschiedene 'atomare' Lichttypen vordefiniert:
    LT_MISC         Unbestimmt, keine Angaben.
 
    LT_SUN          Sonnenlicht.
    LT_MOON         Mondlicht
    LT_STARS        Sternenlicht.
 
-
-
    LT_DIFFUSE      Indirektes Tageslicht. (z.B. im Wald)
 
    LT_CANDLE       Kerzenlicht.
    LT_TORCH        Fackelschein.
    LT_OPEN_FIRE    Sonstiges offenes Feuer. (Lagerfeuer etc.)
 
-
-
    LT_MAGIC        Irgendeine magische Lichtquelle.
 
    LT_GLOWING      Eine selbstleuchtende Lichtquelle.
@@ -55,7 +49,7 @@
 
    Es gibt zudem noch Lichttypen, die zusammengesetzt sind:
 
-   LT_DAYLIGHT    Tageslicht (Sonne/Diffuse)
+   LT_DAYLIGHT    Tageslicht (Sonne/Diffus)
    LT_NATURAL     Natuerliches Licht (Daylight/Sterne/Mond)
    LT_ARTIFICIAL  Kuenstliches Licht (Magie/Feuer/Gluehen)
    LT_FIRE        Feuer (Kerzen/Fackeln/offenes Feuer)
@@ -66,16 +60,12 @@
 
    Ein Objekt soll ein geheimnisvolles Gluehen von sich geben:
 
-
-
    objekt->SetProp( P_LIGHT_TYPE, LT_GLOWING )
 
    Soll ein Raum beschrieben werden, der durch Sternenlicht erhellt ist,
    in dem aber zusaetzlich noch ein Lagerfeuer brennt, sieht die Syntax
    folgendermassen aus:
 
-
-
    raum->SetProp( P_LIGHT_TYPE, LT_STARS|LT_OPEN_FIRE );
 
    Einer brennenden Hose kann der Lichttyp fuer offenes Feuer mitgegeben
@@ -96,11 +86,11 @@
 
    Die Empfindlichkeit der Dunkelelfen gegen Sonnenlicht wird ueber diese
    Property gesteuert. Soll ein Raum mit (P_INDOORS==0) so dunkel sein, dass
-   sie nicht in Gefahr sind, sollten nicht LT_MISC oder LT_SUN gesetzt
+   sie nicht in Gefahr sind, sollten weder LT_MISC, noch LT_SUN gesetzt
    sein.
 
 
 SIEHE AUCH
 ==========
 
-   CheckLightType, /std/thing/description.h, operators
+   CheckLightType(), /std/thing/description.h, operators