diff --git a/doc/lfun/AddAction b/doc/lfun/AddAction
index 29c83c1..967a01b 100644
--- a/doc/lfun/AddAction
+++ b/doc/lfun/AddAction
@@ -3,10 +3,6 @@
 ***********
 
 
-AddAction(L)
-============
-
-
 FUNKTION
 ========
 
@@ -22,24 +18,36 @@
 ARGUMENTE
 =========
 
-   fun        zu rufende Methode im Spieler oder eine Closure
-   cmd        ausloesendes Kommandoverb
-   flag       unscharf ausfuehren
-   lvl        ab welchem (Magierlevel) funktioniert das Kommando
+   fun
+      zu rufende Methode im Spieler oder eine Closure
+
+   cmd
+      ausloesendes Kommandoverb
+
+   flag
+      unscharf ausfuehren
+
+   lvl
+      ab welchem (Magierlevel) funktioniert das Kommando
 
 
 BESCHREIBUNG
 ============
 
-   Dem Spieler wird ein neues Kommando definiert. Dieses kann eine Methode
-   in ihm sein, so wie bei allen Spielerkommandos ueblich, kann aber auch
-   eine Closure (Lfun-Closure oder Lambda) enthalten.
+   Vorweg: Da es keine (risikolose) Moeglichkeit gibt, ein so
+   definiertes Kommando auch wieder zu entfernen, wird von der
+   Verwendung eher abgeraten. Es sei denn, ihr wisst, dass euer
+   Kommando nicht wieder (ohne ende/reboot) entfernt werden soll.
 
-   Mittels "flag" kann man die Kommandoerkennung unscharf halten, d.h. wie
-   bei AddCmd(L) und add_action(E) wird ein 'cmd' bei 'flag = 1' auch
-   schon von Praefix-Strings (hier ohne Leerzeichen) getriggert:
-   AddAction([...], "muh", 1, 0) wird zB auch von 'muhtens' oder 'muh4'
-   ausgeloest.
+   Dem Spieler wird ein neues Kommando definiert. Dieses kann eine
+   Methode in ihm sein, so wie bei allen Spielerkommandos ueblich,
+   kann aber auch eine Closure (Lfun-Closure oder Lambda) enthalten.
+
+   Mittels "flag" kann man die Kommandoerkennung unscharf halten, d.h.
+   wie bei AddCmd(L) und add_action(E) wird ein 'cmd' bei 'flag = 1'
+   auch schon von Praefix-Strings (hier ohne Leerzeichen) getriggert:
+   AddAction([...], "muh", 1, 0) wird zB auch von 'muhtens' oder
+   'muh4' ausgeloest.
 
    Mit "lvl" begrenzt man die Ausfuehrbarkeit. Spieler haben ein
    Magierlevel von 0, Seher von 1.
@@ -52,11 +60,13 @@
 BEMERKUNGEN
 ===========
 
-   - es gibt _noch_ kein RemoveAction! Per Hand in P_LOCALCMDS editieren
-     kann zu ernsten Fehlern fuehren.
-   - echte Spielerkommandos kann man damit _nicht_ ueberschreiben,
+   * es gibt _noch_ kein RemoveAction! Per Hand in P_LOCALCMDS
+     editieren kann zu ernsten Fehlern fuehren.
+
+   * echte Spielerkommandos kann man damit _nicht_ ueberschreiben,
      ein AddAction(...,"sag",1,0); funktioniert nicht
-   - ein generelles AddAction(...,"",1,0); geht nicht
+
+   * ein generelles AddAction(...,"",1,0); geht nicht
 
 
 BEISPIELE
@@ -69,7 +79,6 @@
    write(break_string("Wann immer du jetzt das Kommando \"knorfula\" "
                       "eingibst, werden dir Mysterien enthuellt!",78));
    ...
-
    // im Objekt "knorfula" ...
    int zeige_mysterium(string str) {
      string myst;
@@ -95,10 +104,19 @@
 SIEHE AUCH
 ==========
 
-                      P_LOCALCMDS
-   Fehlermeldungen:   notify_fail(E), _notify_fail(E)
-   Argumentstring:    query_verb(E), _unparsed_args(L)
-   Sonstiges:         replace_personal(E), enable_commands(E)
-   Alternativen:      AddCmd(L), add_action(E)
+   Properties:
+      P_LOCALCMDS
+
+   Fehlermeldungen:
+      *../efun/notify_fail*, _notify_fail()
+
+   Argumentstring:
+      *../efun/query_verb*, _unparsed_args()
+
+   Sonstiges:
+      replace_personal(), *../efun/enable_commands*
+
+   Alternativen:
+      AddCmd(), *../efun/add_action*
 
 24. Maerz 2004 Gloinson
diff --git a/doc/lfun/AddSpell b/doc/lfun/AddSpell
index c0e6da7..b08a296 100644
--- a/doc/lfun/AddSpell
+++ b/doc/lfun/AddSpell
@@ -43,7 +43,9 @@
       aufgerufen werden soll (Optional, bekommt als Argumente object
       enemy, int real_damage, string* dam_type)
 
-   spellarg      - Spell-Argument fuer Defend(), Default ist "1"
+   sinfo         - Skillinfomapping, muss SI_SPELL mit den SP_* fuer
+      den Aufruf von Defend() enthalten Default ist ([SI_SPELL:
+      ([SP_PHYSICAL_ATTACK: 0]), SI_MAGIC_TYPE: ({ MT_ANGRIFF }) ])
 
 
 BESCHREIBUNG
@@ -96,14 +98,30 @@
    im selben Objekt definiert sein, sofern der Funktionsname und keine
    Closure uebergeben wird.
 
-   Will man einen physischen Angriff ausloesen, MUSS <spellarg> ein
-   Mapping mit ([SP_PHYSICAL_ATTACK: 1]) sein. Bei Uebergeben einer 0
-   oder Weglassen des Werts wird an Defend das Default '1' (da es
-   Spells sind) uebergeben.
+   Das Mapping <sinfo> beschreibt den Spell fuer das im Gegner
+   aufgerufene SpellDefend() und Defend(). Es muss ein SI_SPELL fuer
+   das Defend() im Gegner enthalten. Etwaige SI_SKILLDAMAGE,
+   SI_SKILLDAMAGE_TYPE, und SI_CLOSURE werden im Mapping durch die
+   Argumente <damage>, <dam_type> und <func> ueberschrieben. Es wird
+   empfohlen, SI_MAGIC_TYPE zu nutzen, denn dann werden etwaige
+   magische Resistenzen des Ziels beruecksichtigt.
 
-   Wenn damage<=0 oder rate<0 oder keine Meldungen uebergeben werden,
-   wird der Spell NICHT eingetragen, sondern die Funktion bricht mit
-   Rueckgabe von 0 ab.
+   Frueher war das Argument <sinfo> nur das Mapping, was an Defend()
+   uebergeben wird unter in Skillinfomapping unter dem Key SI_SPELL
+   liegt. Wenn <sinfo> kein SI_SPELL enthaelt, wird aus Gruenden der
+   Kompatibilitaet ein Skillinfomapping konstruiert, welches das hier
+   uebergebene <sinfo> unterhalb des Schluessels SI_SPELL enthaelt: ([
+   SI_SPELL: sinfo])
+
+   Will man einen physischen Angriff ausloesen, MUSS in sinfo ein
+   Mapping sein und unter SI_SPELL ein Mapping mit dem Key
+   SP_PHYSICAL_ATTACK (Wert != 0) sein. Bei Uebergeben einer 0 oder
+   Weglassen von <sinfo> wird an Defend der Default
+   ([SP_PHYSICAL_ATTACK: 0]) (da es Spells sind) uebergeben.
+
+   Wenn damage < 0 oder rate <= 0, wird der Spell NICHT eingetragen,
+   sondern die Funktion bricht mit Rueckgabe von 0 ab. Ist damage==0,
+   muss eine <func> angegeben werden.
 
 
 BEISPIELE
@@ -125,7 +143,7 @@
             "Der Hexer piekst Dir in die Augen!",
             "Der Hexer piekst @WEM in die Augen!", ({DT_PIERCE}),
             "augen_stechen");
-   AddSpell(2, 5, (string)0, (string)0, (string*)0, "salto_mortalis");
+   AddSpell(2, 5, 0, 0, 0, "salto_mortalis");
 
    (Kleiner Feuerball mit 80% Wahrscheinlichkeit, riesiger mit 10%,
    "augen_stechen" mit 8%, "salto_mortalis" mit 2%)
@@ -163,8 +181,8 @@
    AddSpell(100, 200+random(200),
      "Die kleine Ratte beisst Dich!\n",
      "@WER wird von einer kleinen Ratte gebissen!\n",
-     ({DT_PIERCE, DT_POISON}), (string)0,
-     ([SP_PHYSICAL_ATTACK:1]));
+     ({DT_PIERCE, DT_POISON}), 0,
+     ([ SI_SPELL: ([SP_PHYSICAL_ATTACK:1]) ]) );
 
    // #3 Selektive physische Angriffe (siehe auch man Defend_bsp):
    //    Will man erreichen, dass einige Ruestungen wirken, andere aber
@@ -179,9 +197,10 @@
    AddSpell(20,200+random(200),
      "Die kleine Ratte beisst Dir blitzschnell in die Wade!\n",
      "@WER wird von einer kleinen Ratte in die Wade gebissen!\n",
-     ({DT_PIERCE, DT_POISON}), (string)0,
-     ([SP_PHYSICAL_ATTACK:1, SP_NO_ACTIVE_DEFENSE:1,
-     SP_REDUCE_ARMOUR: armours]));
+     ({DT_PIERCE, DT_POISON}), 0,
+     ([ SI_SPELL: ([SP_PHYSICAL_ATTACK:1, SP_NO_ACTIVE_DEFENSE:1,
+                    SP_REDUCE_ARMOUR: armours])
+      ]) );
 
    // SP_NO_ACTIVE_DEFENSE = 1 schaltet aktive Abwehr (Karate/Klerus) ab
    // SP_REDUCE_ARMOUR enthaelt eine Liste von Ruestungstypen mit ihren
diff --git a/doc/lfun/SuggestArticle b/doc/lfun/SuggestArticle
index 31c2047..c9311b6 100644
--- a/doc/lfun/SuggestArticle
+++ b/doc/lfun/SuggestArticle
@@ -6,7 +6,7 @@
 FUNKTION
 ========
 
-   varargs int SuggestArticle(string name);
+   protected varargs int SuggestArticle(string name);
 
 
 DEFINIERT IN
diff --git a/doc/lfun/check_restrictions b/doc/lfun/check_restrictions
index e173e8f..1063ec9 100644
--- a/doc/lfun/check_restrictions
+++ b/doc/lfun/check_restrictions
@@ -45,123 +45,112 @@
    NIEMALS solchen Code einfach KOPIEREN. Spaeter muss nur irgendwer
    eurem alten Code hinterherraeumen.
 
-Aktuelle Liste der pruefbaren Parameter:
+   Aktuelle Liste der pruefbaren Parameter:
+
    P_LEVEL
-      Mindeststufe, die das Lebewesen besitzen muss, um die Aktion
-      auszufuehren.
-
+     Mindeststufe, die das Lebewesen besitzen muss, um die Aktion
+     auszufuehren.
    P_GUILD_LEVEL
-      Gildenlevel, das das Lebewesen mindestens erreicht haben muss,
-      um die Aktion auszufuehren.
-
+     Gildenlevel, das das Lebewesen mindestens erreicht haben muss, um die
+     Aktion auszufuehren.
    SR_SEER
-      Ist gesetzt, wenn das Lebewesen Seher sein muss. Auswertung nur
-      fuer Interactives, NSC ignorieren das Flag.
-
+     Ist gesetzt, wenn das Lebewesen Seher sein muss.
+     Auswertung nur fuer Interactives, NSC ignorieren das Flag.
    P_XP
-      Mindestmenge an Erfahrungspunkten, die ein Lebewesen besitzen
-      muss, um die Aktion auszufuehren.
-
+     Mindestmenge an Erfahrungspunkten, die ein Lebewesen besitzen muss,
+     um die Aktion auszufuehren.
    P_QP
-      Mindestmenge an Abenteuerpunkten, die das Lebewesen haben muss.
-
+     Mindestmenge an Abenteuerpunkten, die das Lebewesen haben muss.
    P_ALCOHOL
-      Menge an Alkohol, unter der der Alkoholspiegel des Lebewesen
-      liegen muss, um die Aktion noch ausfuehren zu koennen.
-
+     Menge an Alkohol, unter der der Alkoholspiegel des Lebewesen liegen
+     muss, um die Aktion noch ausfuehren zu koennen.
    P_DRINK
-      Menge an Fluessigkeit, unter der der Fluessigkeitsspiegel des
-      Lebewesen liegen muss, um die Aktion noch ausfuehren zu koennen.
-
+     Menge an Fluessigkeit, unter der der Fluessigkeitsspiegel des
+     Lebewesen liegen muss, um die Aktion noch ausfuehren zu koennen.
    P_FOOD
-      Beinhaltet die Menge an Nahrung, unter der der Nahrungsspiegel
-      des Spielers liegen muss, um die Aktion noch ausfuehren zu
-      koennen.
-
+     Beinhaltet die Menge an Nahrung, unter der der Nahrungsspiegel des
+     Spielers liegen muss, um die Aktion noch ausfuehren zu koennen.
    P_DEAF
-      Ist gesetzt, falls der Spieler nicht taub sein darf.
-
+     Ist gesetzt, falls der Spieler nicht taub sein darf.
    P_FROG
-      Ist gesetzt, falls der Spieler kein Frosch sein darf.
-
+     Ist gesetzt, falls der Spieler kein Frosch sein darf.
    P_BLIND
-      Ist gesetzt, falls der Spieler nicht blind sein darf. Achtung:
-      das ist nicht gleichbedeutend mit dem Umstand, dass er evtl.
-      nichts mehr sehen kann. Auch andere Gruende (zum Beispiel
-      Dunkelheit) koennen bewirken, dass ein Spieler nichts mehr
-      sieht.
-
+     Ist gesetzt, falls der Spieler nicht blind sein darf.
+     Achtung: das ist nicht gleichbedeutend mit dem Umstand, dass er evtl.
+     nichts mehr sehen kann. Auch andere Gruende (zum Beispiel Dunkelheit)
+     koennen bewirken, dass ein Spieler nichts mehr sieht.
    A_INT, A_DEX, A_CON, A_STR
-      Jeweilige Mindesthoehe eines Attribut, um eine Aktion ausfuehren
-      zu koennen.
-
+     Jeweilige Mindesthoehe eines Attribut, um eine Aktion ausfuehren zu
+     koennen.
    SR_BAD, SR_GOOD
-      Gibt an, wie [minimal] boese bzw. wie [maximal] gut ein
-      Charakter sein darf, um eine Aktion ausfuehren zu koennen.
-
+     Gibt an, wie [minimal] boese bzw. wie [maximal] gut ein Charakter sein
+     darf, um eine Aktion ausfuehren zu koennen.
    SR_MIN_SIZE, SR_MAX_SIZE
-      Gibt die minimale, bzw. die maximale Groesse an, die ein
-      Charakter maximal haben darf, um eine Aktion ausfuehren zu
-      koennen.
-
+     Gibt die minimale, bzw. die maximale Groesse an, die ein Charakter
+     maximal haben darf, um eine Aktion ausfuehren zu koennen.
    SR_FREE_HANDS
-      Gibt an, wieviele freie Haende ein Charakter fuer diese Aktion
-      besitzen muss.
-
+     Gibt an, wieviele freie Haende ein Charakter fuer diese Aktion
+     besitzen muss.
    SR_EXCLUDE_RACE
-      Mitglieder aller in dieser Liste aufgefuehrten Rassen koennen
-      diese Aktion nicht ausfuehren.
-
+     Mitglieder aller in dieser Liste aufgefuehrten Rassen koennen
+     diese Aktion nicht ausfuehren.
    SR_INCLUDE_RACE
-      Mitglieder aller NICHT in dieser Liste aufgefuehrten Rassen
-      koennen diese Aktion nicht ausfuehren.
-
+     Mitglieder aller NICHT in dieser Liste aufgefuehrten Rassen koennen
+     diese Aktion nicht ausfuehren.
    SM_RACE
-      Hier kann pro Rasse ein Mapping mit besonderen (nur) fuer diese
-      Rasse geltenden Einschraenkungen vorgenommen werden. Als Keys
-      sind die in dieser Manpage beschriebenen Keys erlaubt, wobei
-      SM_RACE nicht rekursiv ausgewertet wird. Der Rassenname ist
-      gross geschrieben und "*" steht fuer alle Rassen.
-
-   SR_EXCLUDE_GUILD SR_INCLUDE_GUILD
-
-      Diese beiden Keys verhalten sich wie SR_*_RACE, nur dass hier
-      Gilden genannt werden.
-
+     Hier kann pro Rasse ein Mapping mit besonderen (nur) fuer diese Rasse
+     geltenden Einschraenkungen vorgenommen werden. Als Keys sind die
+     in dieser Manpage beschriebenen Keys erlaubt, wobei SM_RACE nicht
+     rekursiv ausgewertet wird.
+     Der Rassenname ist gross geschrieben und "*" steht fuer alle Rassen.
+   SR_EXCLUDE_GUILD
+   SR_INCLUDE_GUILD
+     Diese beiden Keys verhalten sich wie SR_*_RACE, nur dass hier Gilden
+     genannt werden.
    SR_FUN
-      Hier kann eine Funktion in verschiedenen Formen zum Pruefen der
-      Restriktionen angegeben werden, siehe execute_anything(). Das
-      kann nuetzlich sein, um andere Restriktionen zu pruefen, wie das
-      Bestehen von Miniquests oder andere Faehigkeiten/Flags. Ist der
-      Test nicht bestanden, gibt die Funktion einen String zurueck.
+     Hier kann eine Funktion angegeben werden, die aufgerufen wird, um sie
+     die Restriktionen zu pruefen zu lassen. Folgende Formen sind moeglich:
+     - Funktionsname als String; Funktion wird an dem Objekt gerufen, das
+       die Restriktion prueft, d.h. an der Ruestung/Waffe/Kleidung. Soll
+       die Funktion an einem anderen Objekt gerufen werden, ist eine
+       der beiden alternativen Formen zu verwenden.
+     - eine Closure, wird per funcall() gerufen
+     - ein Array mit dem folgenden Aufbau:
+       ({ Objekt/Objektname, Funktionsname, arg_1, arg_2, ... , arg_n })
 
+     Der aufgerufenen Funktion wird das Spielerobjekt immer als erstes
+     Argument uebergeben, d.h. bei der Array-Form ggf. vor dem ersten
+     Extra-Argument arg_1 eingeschoben.
+     SR_FUN kann nuetzlich sein, um Restriktionen zu pruefen, die sich mit
+     den anderen Optionen nicht abbilden lassen.
+     Ist der Test nicht bestanden, muss die Funktion einen String zurueck-
+     geben, ansonsten 0.
+     Eine Besonderheit besteht beim Aufruf per call_other(), d.h. wenn
+     restriction_checker.c nicht geerbt wurde und nur ein Funktionsname
+     uebergeben wird. In diesem Fall, der auch bei Verwendung von
+     P_RESTRICTIONS zum Tragen kommt, wird die Funktion immer am
+     aufrufenden Objekt, d.h. previous_object(), gerufen.
    SR_PROP
-      Hier kann ein Mapping mit Properties und zugehoerigen Werten
-      angegeben werden, die jeweils auf Identitaet geprueft werden.
-      Zusaetzlich sollte eine Meldung angegeben werden, die als
-      Fehlermeldung ausgegeben wird, wenn der Spieler die Bedingung
-      nicht erfuellt. Es sollte immer eine passende Meldung fuer den
-      Spieler eingebaut werden. Beispiel: ([ SR_PROP:
-      ([P_AUSGANG_ENTDECKT: 1; "Dein Schwert fluestert "
-
-         "veraergert: Ich werde Dir erst dann zu Diensten sein, wenn
-         Du " "Dich als wuerdig erwiesen hast!"]) ])
-
-      Aufgrund der Meldung wird empfohlen, SR_PROP nicht in
-      Restriktionen einzusetzen, die massenweise in Savefiles landen
-      (z.B. Spielersavefiles).
-
+     Hier kann ein Mapping mit Properties und zugehoerigen Werten angegeben
+     werden, die jeweils auf Identitaet geprueft werden. Zusaetzlich sollte
+     eine Meldung angegeben werden, die als Fehlermeldung ausgegeben wird,
+     wenn der Spieler die Bedingung nicht erfuellt. Es sollte immer eine
+     passende Meldung fuer den Spieler eingebaut werden. Beispiel:
+     ([ SR_PROP: ([P_AUSGANG_ENTDECKT: 1; "Dein Schwert fluestert "
+         "veraergert: Ich werde Dir erst dann zu Diensten sein, wenn Du "
+         "Dich als wuerdig erwiesen hast!"]) ])
+     Aufgrund der Meldung wird empfohlen, SR_PROP nicht in Restriktionen
+     einzusetzen, die massenweise in Savefiles landen (z.B.
+     Spielersavefiles).
    SR_QUEST
-      Hier kann ein String-Array mit den Namen (Keys) der Quest(s)
-      angegeben werden, die der Spieler bestanden haben muss, um die
-      Aktion ausfuehren zu koennen.
-
+     Hier kann ein String-Array mit den Namen (Keys) der Quest(s) angegeben
+     werden, die der Spieler bestanden haben muss, um die Aktion ausfuehren
+     zu koennen.
    SQ_MINIQUEST
-      Hier kann entweder ein String-Array mit den Ladenamen der
-      vergebenden Objekte oder ein Int-Array mit den Index-Nummern
-      (IDs) der Miniquest(s) (empfohlen!) angegeben werden, die der
-      Spieler bestanden haben muss, um die Aktion ausfuehren zu
-      koennen.
+     Hier kann entweder ein String-Array mit den Ladenamen der vergebenden
+     Objekte oder ein Int-Array mit den Index-Nummern (IDs) der
+     Miniquest(s) (empfohlen!) angegeben werden, die der Spieler bestanden
+     haben muss, um die Aktion ausfuehren zu koennen.
 
 
 BEISPIELE