diff --git a/doc/lfun-liste b/doc/lfun-liste
index 5aa5b31..cbed681 100644
--- a/doc/lfun-liste
+++ b/doc/lfun-liste
@@ -80,7 +80,7 @@
 
 * AddTouchDetail()
 
-* AddvItem()
+* AddVItem()
 
 * AllGroups()
 
diff --git a/doc/lfun/AddItem b/doc/lfun/AddItem
index 222b24d..97bd0a8 100644
--- a/doc/lfun/AddItem
+++ b/doc/lfun/AddItem
@@ -33,6 +33,8 @@
      - REFRESH_ALWAYS    - Neuer Clone bei jedem Reset.
      - REFRESH_MOVE_HOME - Objekt wird bei Reset automatisch
                            zurueckgeholt, wenn es wegbewegt wurde.
+                     Wurde das Objekt zerstoert, wird es automatisch neu
+                     erzeugt, wie bei REFRESH_DESTRUCT.
                            (nur in Raeumen!)
      Bei NPC's gilt zusaetzlich:
      - CLONE_WEAR       - Item Anziehen, wenn es eine Ruestung ist.
@@ -56,84 +58,85 @@
 BESCHREIBUNG
 ============
 
-   Abhaengig von <filename> und <props> wird ein Objekt erzeugt und in
-   den Raum bzw. NPC bewegt. Dabei gibt es folgende Moeglichkeiten:
-   - <filename> ist ein Dateiname.
-     Es wird ein Clone dieser Datei erstellt oder (wenn <props>=1 ist)
-     deren Blueprint verwendet.
-   - <filename> ist ein Array von Dateinamen.
-     Es wird eine Datei zufaellig aus dem Array ausgewaehlt und von
-     dieser Datei ein Clone erstellt oder (wenn <props>=1 ist) deren
-     Blueprint verwendet.
-   Uebergibt man fuer <props> ein Mapping mit dem Aufbau
-     ([prop_name:prop_wert,...]),
-   so werden diese Properties im erzeugten Objekt gesetzt.
-   Der Parameter <refresh> gibt an, was waehrend eines Resets im Raum
-   bzw. in NPC's oder was beim Erzeugen von NPC's geschehen soll:
-   In <rooms.h> sind dazu folgende Moeglichkeiten definiert:
-   - REFRESH_NONE
-       Das Objekt wird niemals erneuert; falls es zerstoert wurde, wird
-       es erst dann wieder erzeugt, wenn der Raum erneut geladen bzw.
-       der NPC neu erzeugt wird. Man beachte, dass nicht jeder NPC
-       wirklich refreshende Objekte benoetigt, REFRESH_NONE spart
-       hierbei sowohl Rechenzeit als auch Speicher!
-   - REFRESH_DESTRUCT
-       Das Objekt wird nur dann erneuert, wenn es in der Zwischenzeit
-       zerstoert wurde (bei NPC's ist das zum Beispiel der Fall, wenn
-       sie getoetet wurden).
-       REFRESH_NONE & REFRESH_DESTRUCT + Blueprint-Objekt bedeutet bei
-       NPC's ein Unique-Objekt, es wird also nicht beim Neuerzeugen des
-       NPC's zurueckgesetzt.
-   - REFRESH_REMOVE
-       Das Objekt wird erneuert, wenn es sich nicht mehr im Raum bzw.
-       im NPC befindet. Das kein sein, weil es zerstoert wurde, aber
-       auch zum Beispiel in folgenden Faellen:
-       * weil es jemand mitgenommen hat
-          (in Raeumen bei Gegenstaenden)
-       * weil es fortgegangen ist
-          (in Raeumen bei NPC's, die herumlaufen)
-       * weil es weggeworfen wurde
-          (in NPC's bei Gegenstaenden)
-   - REFRESH_ALWAYS
-       Das Objekt wird immer erneuert. Von dieser Refreshmethode sollte
-       man allerdings Abstand nehmen, da sich sonst mit der Zeit
-       gewaltige Mengen von Objekten ansammeln koennen!
-   - REFRESH_MOVE_HOME
-       Das Objekt wird in einen Raum zurueckbewegt, sofern es noch
-       existiert, jedoch nicht mehr in dem Raum ist. Sinnvoll ist dies
-       eigentlich nur fuer Lebewesen, funktioniert aber auch bei
-       beliebigen Objekten. Hauptsaechlich geht es hierbei darum,
-       herumlaufende NPCs oder bei erzwungenen Bewegungen nicht von
-       P_GUARD zurueckgehaltene NPCs wieder an einen definierten
-       Ausgangsort zurueckzubringen.
-   Hat man in Raeumen als <filename> ein Array von Dateinamen
-   uebergeben, so wird beim Reset jedesmal aufs Neue ein zufaelliges
-   Objekt aus der Liste ausgewaehlt (nicht in NPC's).
-   In NPC's gilt der Grundsatz der Vermeidung von ueberfluessigen
-   Objekten im MUD. Neu erzeugt werden Objekte beim Erzeugen eines
-   NPC's oder bei einem Reset im selbigen. Anstatt die Objekte gleich
-   neu zu erschaffen, wird erst geschaut, ob sich identische Objekte
-   schon im Raum befinden. Ist dies der Fall, so nimmt der NPC sie auf,
-   ruft jedoch vorher nochmals create() in ihnen auf!
-     (noetig wegen moeglicher Veraenderungen an den Objekten)
-   Was dann passiert, haengt von weiteren Angaben in <refresh> ab.
-   Folgende weitere Moeglichkeiten sind in <npc.h> definiert:
-   - CLONE_WEAR
-     Ist das hinzugefuegte Item eine Ruestung, so wird sie nach
-     Aufnahme oder Neuerzeugung angezogen.
-   - CLONE_WIELD
-     Ist das hinzugefuegte Item eine Waffe, so wird sie nach Aufnahme
-     oder Neuerzeugung gezueckt.
-   - CLONE_NO_CHECK
-     Hiermit verhindert man eine Ueberpruefung, ob eine Ruestung
-     angezogen oder eine Waffe gezueckt werden kann. Es ist jedoch
-     Vorsicht geboten: So kann es ohne weiteres passieren, dass ein NPC
-     mehrere Ruestungen gleichen Typs angezogen oder mehrere Waffen
-     gezueckt hat.
-   Benutzt man Blueprints (<props>=1) mit REFRESH_REMOVE oder
-   REFRESH_ALWAYS, so kann es zu ungewollten Ueberraschungen kommen, da
-   die Blueprint dann unabhaengig von ihrem momentanen Aufenthaltsort
-   wieder in den Raum bzw. NPC bewegt wird, von dem sie erzeugt wurde!
+     Abhaengig von <filename> und <props> wird ein Objekt erzeugt und in
+     den Raum bzw. NPC bewegt. Dabei gibt es folgende Moeglichkeiten:
+     - <filename> ist ein Dateiname.
+       Es wird ein Clone dieser Datei erstellt oder (wenn <props>=1 ist)
+       deren Blueprint verwendet.
+     - <filename> ist ein Array von Dateinamen.
+       Es wird eine Datei zufaellig aus dem Array ausgewaehlt und von
+       dieser Datei ein Clone erstellt oder (wenn <props>=1 ist) deren
+       Blueprint verwendet.
+     Uebergibt man fuer <props> ein Mapping mit dem Aufbau
+       ([prop_name:prop_wert,...]),
+     so werden diese Properties im erzeugten Objekt gesetzt.
+     Der Parameter <refresh> gibt an, was waehrend eines Resets im Raum
+     bzw. in NPC's oder was beim Erzeugen von NPC's geschehen soll:
+     In <rooms.h> sind dazu folgende Moeglichkeiten definiert:
+     - REFRESH_NONE
+         Das Objekt wird niemals erneuert; falls es zerstoert wurde, wird
+         es erst dann wieder erzeugt, wenn der Raum erneut geladen bzw.
+         der NPC neu erzeugt wird. Man beachte, dass nicht jeder NPC
+         wirklich refreshende Objekte benoetigt, REFRESH_NONE spart
+         hierbei sowohl Rechenzeit als auch Speicher!
+     - REFRESH_DESTRUCT
+         Das Objekt wird nur dann erneuert, wenn es in der Zwischenzeit
+         zerstoert wurde (bei NPC's ist das zum Beispiel der Fall, wenn
+         sie getoetet wurden).
+         REFRESH_NONE & REFRESH_DESTRUCT + Blueprint-Objekt bedeutet bei
+         NPC's ein Unique-Objekt, es wird also nicht beim Neuerzeugen des
+         NPC's zurueckgesetzt.
+     - REFRESH_REMOVE
+         Das Objekt wird erneuert, wenn es sich nicht mehr im Raum bzw.
+         im NPC befindet. Das kein sein, weil es zerstoert wurde, aber
+         auch zum Beispiel in folgenden Faellen:
+         * weil es jemand mitgenommen hat
+            (in Raeumen bei Gegenstaenden)
+         * weil es fortgegangen ist
+            (in Raeumen bei NPC's, die herumlaufen)
+         * weil es weggeworfen wurde
+            (in NPC's bei Gegenstaenden)
+     - REFRESH_ALWAYS
+         Das Objekt wird immer erneuert. Von dieser Refreshmethode sollte
+         man allerdings Abstand nehmen, da sich sonst mit der Zeit
+         gewaltige Mengen von Objekten ansammeln koennen!
+     - REFRESH_MOVE_HOME
+         Das Objekt wird in einen Raum zurueckbewegt, sofern es noch
+         existiert, jedoch nicht mehr in dem Raum ist. Sinnvoll ist dies
+         eigentlich nur fuer Lebewesen, funktioniert aber auch bei
+         beliebigen Objekten. Hauptsaechlich geht es hierbei darum,
+         herumlaufende NPCs oder bei erzwungenen Bewegungen nicht von
+         P_GUARD zurueckgehaltene NPCs wieder an einen definierten
+         Ausgangsort zurueckzubringen.
+   Wurde das Objekt zerstoert, wird es neu erzeugt.
+     Hat man in Raeumen als <filename> ein Array von Dateinamen
+     uebergeben, so wird beim Reset jedesmal aufs Neue ein zufaelliges
+     Objekt aus der Liste ausgewaehlt (nicht in NPC's).
+     In NPC's gilt der Grundsatz der Vermeidung von ueberfluessigen
+     Objekten im MUD. Neu erzeugt werden Objekte beim Erzeugen eines
+     NPC's oder bei einem Reset im selbigen. Anstatt die Objekte gleich
+     neu zu erschaffen, wird erst geschaut, ob sich identische Objekte
+     schon im Raum befinden. Ist dies der Fall, so nimmt der NPC sie auf,
+     ruft jedoch vorher nochmals create() in ihnen auf!
+       (noetig wegen moeglicher Veraenderungen an den Objekten)
+     Was dann passiert, haengt von weiteren Angaben in <refresh> ab.
+     Folgende weitere Moeglichkeiten sind in <npc.h> definiert:
+     - CLONE_WEAR
+       Ist das hinzugefuegte Item eine Ruestung, so wird sie nach
+       Aufnahme oder Neuerzeugung angezogen.
+     - CLONE_WIELD
+       Ist das hinzugefuegte Item eine Waffe, so wird sie nach Aufnahme
+       oder Neuerzeugung gezueckt.
+     - CLONE_NO_CHECK
+       Hiermit verhindert man eine Ueberpruefung, ob eine Ruestung
+       angezogen oder eine Waffe gezueckt werden kann. Es ist jedoch
+       Vorsicht geboten: So kann es ohne weiteres passieren, dass ein NPC
+       mehrere Ruestungen gleichen Typs angezogen oder mehrere Waffen
+       gezueckt hat.
+     Benutzt man Blueprints (<props>=1) mit REFRESH_REMOVE oder
+     REFRESH_ALWAYS, so kann es zu ungewollten Ueberraschungen kommen, da
+     die Blueprint dann unabhaengig von ihrem momentanen Aufenthaltsort
+     wieder in den Raum bzw. NPC bewegt wird, von dem sie erzeugt wurde!
 
 
 BEMERKUNGEN
@@ -141,7 +144,6 @@
 
    Wenn man Blueprints benutzt, sollte man daran denken, dass sich von
    dieser dann keine Clones mehr erstellen lassen!
-   RemoveItem() zum Entfernen von Items ist nur fuer Raeume definiert!
 
    Die Option CLONE_NEW ist veraltet. Die Objekte werden nun immer
    neu erzeugt. Die Option darf noch angegeben werden, hat aber keine
diff --git a/doc/lfun/AddVItem b/doc/lfun/AddVItem
index 0b48656..af42f22 100644
--- a/doc/lfun/AddVItem
+++ b/doc/lfun/AddVItem
@@ -1,5 +1,5 @@
 
-AddvItem()
+AddVItem()
 **********
 
 
@@ -21,8 +21,7 @@
 
    key
       Eindeutige Bezeichnung des vItems und mit dieser wieder
-      loeschbar. Das vItem wird im Raum auch unter dieser ID
-      ansprechbar sein.
+      loeschbar. Das vItem bekommt dies u.U. auch als ID (s.u.)
 
    refresh
       Refresheinstellungen des vItems, nachdem es mitgenommen wurde
@@ -60,6 +59,10 @@
    <props> angegebenen Properties in ihm gesetzt. Auf diese Weise kann
    man das genommene Objekt noch individuell konfigurieren.
 
+   Werden fuer ein reines vItem ohne Vorlage keine P_IDS in
+   <shadowprops> angegeben, so bekommt das vItem den string <key> als
+   ID, damit es irgendwie im Raum ansprechbar ist.
+
    Zu beachten ist: in <shadowprops> enthaltene Properties *ersetzen*
    (nicht ergaenzen) im Regelfall diejenigen im Templat *und* in
    <props>. In <props> enthaltene Properties *ersetzen* wiederum
@@ -189,6 +192,6 @@
 SIEHE AUCH
 ==========
 
-   AddvItem(), AddItem(), RemoveItem() *../std/vitems*
+   RemoveVItem(), AddItem(), RemoveItem() *../std/vitems*
 
 Last modified: 03.04.2019, Zesstra
diff --git a/doc/lfun/PreventInsert b/doc/lfun/PreventInsert
index 3635142..e58e827 100644
--- a/doc/lfun/PreventInsert
+++ b/doc/lfun/PreventInsert
@@ -19,7 +19,7 @@
 =========
 
    ob
-        Das Objekt, das in den Behaelter eingefuegt werden soll.
+      Das Objekt, das in den Behaelter eingefuegt werden soll.
 
 
 BESCHREIBUNG
@@ -28,44 +28,49 @@
    Mit dieser Funktion kann ein Behaelter pruefen, ob er das Objekt ob
    aufnehmen moechte oder nicht.
 
+   Man beachte bitte, dass nach dieser Funktion *nicht* garantiert
+   ist, dass das Objekt wirklich bewegt wird, es handelt sich
+   lediglich um die Abfrage der Erlaubnis! Die Bewegung kann aus einer
+   Vielzahl an Gruenden noch abgebrochen werden.
+
+   Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventInsert()
+   zwar aufgerufen, aber das Ergebnis ignoriert, d.h. die Aufnahme
+   kann in dem Fall nicht verhindert werden.
+
 
 RUeCKGABEWERT
 =============
 
-   0, wenn das Objekt aufgenommen werden kann; ein Wert groesser als 0
-   zeigt an, dass das Objekt nicht aufgenommen werden soll.
+   0
+      wenn das Objekt aufgenommen werden kann;
 
-
-BEMERKUNGEN
-===========
-
-   Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventInsert() zwar
-   aufgerufen, das Objekt wird jedoch auf jeden Fall in den Behaelter
-   bewegt, unabhaengig vom Rueckgabewert!
+   > 0
+      ein Wert groesser als 0 zeigt an, dass das Objekt nicht
+      aufgenommen werden soll.
 
 
 BEISPIELE
 =========
 
-   Um zu verhindern, dass man Geld in einen Behaelter stecken kann, sollte
-   man wie folgt vorgehen:
+   Um zu verhindern, dass man Geld in einen Behaelter stecken kann,
+   sollte man wie folgt vorgehen:
 
-   varargs int PreventInsert(object ob)
-   {
-     // Wenn es Geld ist, erheben wir sofort Einspruch
-     if (ob->id("geld"))
-       return 1;
-     // Ansonsten koennte ein ererbtes Objekt noch Einspruch erheben!
-     else
-       return ::PreventInsert(ob);
-   }
+      public int PreventInsert(object ob)
+      {
+        // Wenn es Geld ist, erheben wir sofort Einspruch
+        if (ob->id("geld"))
+          return 1;
+        // Ansonsten koennte ein ererbtes Objekt noch Einspruch erheben!
+        else
+          return ::PreventInsert(ob);
+      }
 
 
 SIEHE AUCH
 ==========
 
    PreventLeave(), NotifyInsert(), NotifyLeave(), MayAddObject(),
-   PreventInsertLiving(), PreventLeaveLiving(), NotifyMove(),
-   PreventMove(), MayAddWeight(), move(), /std/container/restrictions.c
+   MayAddWeight(), PreventInsertLiving(), PreventLeaveLiving(),
+   NotifyMove(), PreventMove(), move(), /std/container/restrictions.c
 
-Last modified: Sat Dec 18 02:00:00 1999 by Tiamak
+Last modified: 30.01.2020, Zesstra
diff --git a/doc/props-liste b/doc/props-liste
index fe9f231..b1b0cf6 100644
--- a/doc/props-liste
+++ b/doc/props-liste
@@ -636,6 +636,8 @@
 
 * P_PREFERED_ENEMY
 
+* P_PREPARED_SPELL
+
 * P_PRESAY
 
 * P_PREVENT_PILE
diff --git a/doc/props/P_DOOR_INFOS b/doc/props/P_DOOR_INFOS
index dc393da..a432ed0 100644
--- a/doc/props/P_DOOR_INFOS
+++ b/doc/props/P_DOOR_INFOS
@@ -18,17 +18,17 @@
 BESCHREIBUNG
 ============
 
-   Mapping mit Informationen ueber eine im Raum per NewDoor() definierte
+   Array mit Informationen ueber eine im Raum per NewDoor() definierte
    Tuer. Diese Infos werden ueber /std/room/doors.c an den /obj/doormaster.c
    weitergegeben und dem Raum, der die Tuer besitzt, als Property gesetzt.
-   Werden mehrere Tueren in einem Raum eingebunden, enthaelt das Mapping
+   Werden mehrere Tueren in einem Raum eingebunden, enthaelt das Array
    entsprechend viele Eintraege.
 
-   Dieses Mapping dient zur internen Verwaltung der Tueren im
+   Dieses Property dient zur internen Verwaltung der Tueren im
    /obj/doormaster.c und sollte nicht per Hand veraendert werden!
 
-   Die Eintraege im Mapping haben folgende keys (definiert in
-   /sys/doorroom.h):
+   Jeder Eintrag im Array ist erneut ein Array und hat folgende Indices
+   (definiert in /sys/doorroom.h):
 
    D_DEST : Zielraum (string)
    D_CMDS : Befehl(e), um durch die Tuer zu gehen (string oder *string)
@@ -55,4 +55,4 @@
    NewDoor(), QueryDoorKey(), QueryDoorStatus(), SetDoorStatus(),
    /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
 
-Letzte Aenderung: Don, 08.05.2014, Gabylon
+Letzte Aenderung: 13.3.2020 Zesstra
diff --git a/doc/props/P_GLOBAL_SKILLPROPS b/doc/props/P_GLOBAL_SKILLPROPS
index 1e3533b..c43c820 100644
--- a/doc/props/P_GLOBAL_SKILLPROPS
+++ b/doc/props/P_GLOBAL_SKILLPROPS
@@ -33,6 +33,14 @@
        FACTOR(SI_SPELLCOST):  #'costFactor]));
 
 
+BEMERKUNG
+=========
+
+   Diese Property wird in AddSpell() ausgewertet, nicht in UseSpell().
+   Sie muss also vor dem Hinzufuegen von Spells mitels AddSpell
+   gesetzt werden.
+
+
 SIEHE AUCH
 ==========
 
@@ -43,4 +51,4 @@
    * Properties:     P_SB_SPELLS
    Skills:           P_NEWSKILLS, spruchermuedung, skill_info_liste
 
-3. Okt 2011 Gloinson
+Letzte Aenderung: 06.03.2020, Bugfix
diff --git a/doc/props/P_PREPARED_SPELL b/doc/props/P_PREPARED_SPELL
new file mode 100644
index 0000000..6340909
--- /dev/null
+++ b/doc/props/P_PREPARED_SPELL
@@ -0,0 +1,36 @@
+
+P_PREPARED_SPELL
+****************
+
+
+NAME
+====
+
+   P_PREPARED_SPELL  "prepared_spell"
+
+
+DEFINIERT IN
+============
+
+   /sys/new_skills.h
+
+
+BESCHREIBUNG
+============
+
+   Enthaelt ein Array mit Daten zu einem in Vorbereitung befindlichen
+   Spell.
+
+   * arr[0]: Ausloesezeitpunkt (int)
+
+   * arr[1]: Spellinformationen (mapping)
+
+   * arr[2]: Skill-Argument (string)
+
+
+SIEHE AUCH
+==========
+
+   P_GUILD_PREPAREBLOCK
+
+Letzte Aenderung: 26.03.2021, Bugfix