Update auto-erzeugter Manapges
Change-Id: Ib72cf75d55022c97029bde5fa2a8e4112c6e421d
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