Update auto-erzeugter Files.
Fuer die Bequemlichkeit von Nutzern, die kein sphinx haben.
Change-Id: Ib49ae3b16fd391b9f89b2297dfcebb1bbc406fc6
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