Auto-erzeugte Manpages aktualisiert.
Change-Id: I56922c76705a17682137843fd743c1f2068b2e42
diff --git a/doc/lfun-liste b/doc/lfun-liste
index e7e21eb..17d737b 100644
--- a/doc/lfun-liste
+++ b/doc/lfun-liste
@@ -820,6 +820,8 @@
* name()
+* normalize_defend_args()
+
* notify_player_change()
* pick()
diff --git a/doc/lfun/Defend b/doc/lfun/Defend
index 1de1f78..e5ee6ea 100644
--- a/doc/lfun/Defend
+++ b/doc/lfun/Defend
@@ -6,8 +6,8 @@
FUNKTION
========
- public int Defend(int dam, string|string* dam_type, int|mapping
- spell,
+ public int Defend(int dam, string|string* dam_types, int|mapping
+ si_spell,
object enemy)
@@ -23,12 +23,12 @@
int dam
Initiale Staerke des Angriffs (10 dam ~ 1 HP)
- string* dam_type
+ string* dam_types
Art des Schadens, der angerichtet werden soll Muss ein Array von
Schadenstypen sein, alte Objekte uebergeben hier manchmal
strings.
- mapping spell
+ mapping si_spell
Mapping mit zusaetzlichen Informationen zum Angriff(Siehe unten)
Alte Objekte uebergeben manchmal einen Integer (0 fuer
Physikalischen Angriff, 1 fuer Zauber.
@@ -61,58 +61,86 @@
diverse Flags, die das Ergebnis manipulieren (in new_skills.h
enthalten). Nichtangabe eines Flags gilt als 0.
- * SP_PHYSICAL_ATTACK ---------- 0/1 1, wenn Ruestungen wirken
- sollen, 0 sonst -> entspricht !spell, wenn dieses Int ist
+ * SP_PHYSICAL_ATTACK (int)
- * SP_NO_ENEMY ----------------- 0/1 1, falls der Angriff nicht
- toedlich ist, es also keinen echten Gegner gibt -> es wird dann
- reduce_hit_points() gerufen statt do_damage()
+ 1, wenn es ein physischer Angriff ist, d.h. Ruestungen wirken
+ sollen, 0 sonst. Dies entspricht dem alten !spell (wenn Spell
+ kein Mapping ist).
- * SP_NO_ACTIVE_DEFENSE -------- 0/1 1, falls aktive Abwehren (wie
- zurueckschlagende Amulette, Karateabwehren oder Ausweichmanoever)
- unterbleiben sollen -> zB bei Kratzen durch Dornen oder Fall aus
- grosser Hoehe ist aktive Abwehr oder Ausweichen unlogisch
+ * SP_NO_ENEMY (int)
- * SP_RECURSIVE ---------------- 0/1 1, falls der Spell aus einem
- Defend gerufen wurde (oder einer DefendFunc) -> verhindert
- Rekursionsprobleme
+ 1, falls der Angriff nicht toedlich ist, es also keinen echten
+ Gegner gibt. Es wird dann reduce_hit_points() gerufen statt
+ do_damage()
- * SP_NAME --------------------- string Name des Spells
+ * SP_NO_ACTIVE_DEFENSE (int)
- * SP_GLOBAL_ATTACK ------------ 0/1 1 bei Flaechenspells
+ 1, falls aktive Abwehren (wie zurueckschlagende Amulette,
+ Karateabwehren oder Ausweichmanoever) unterbleiben sollen, zB
+ bei Kratzen durch Dornen oder Fall aus grosser Hoehe ist
+ aktive Abwehr oder Ausweichen unlogisch
- * SP_REDUCE_ARMOUR ------------ Mapping: keys AT_X/P_BODY, values
- int>=0 Die Schutzwirkung durch P_AC/Magie einer Ruestung wird
- typabhaengig reduziert. Aufbau eines Mappings im Beispiel:
+ * SP_RECURSIVE (int)
- ([AT_BOOTS: 0, // Stiefel schuetzen gar nicht P_BODY: 50, //
- Koerper zu 50% AT_BELT: 600 // Guertel zu 600% ]) -> alle
- 'fehlenden' Eintraege wirken normal
+ 1, falls der Spell aus einem Defend gerufen wurde (oder einer
+ DefendFunc). Dies ist sehr wichtig, um unendliche Rekursionen
+ zu vermeiden, wenn zwei zurueckschlagende Verteidigungen
+ zusammentreffen.
- * SP_SHOW_DAMAGE -------------- 0/1 oder Array von Arrays 0, fuer
- keine Treffermeldung, 1 sonst In einem Array koennen Ersatz-
- Treffermeldungen definiert werden. Format ist:
+ * SP_NAME (string)
- ({ ({ int lphit1, string mess_me, string mess_en, string
- mess_room }), ({ lphit2, mess_me, mess_en, mess_room }), ...
- ({ lphitn, mess_me, mess_en, mess_room }), }) wobei
- lphit1<lphit2<...<lphitn sein muss, d.h. das Array-Array
- aufsteigend sortiert.
+ Name des Spells
- Ist ein Treffer x LP hart, werden die Meldungen des lphit-Arrays
- ausgegeben, dessen Wert am naehesten unter dem Schaden liegt.
+ * SP_GLOBAL_ATTACK (int)
- In den Meldungen mess_me (an den Getroffenen), mess_en (an den
- Feind), mess_room (an die restlichen Umstehenden) koennen
- Ersatzstrings wie folgt verwendet werden:
+ 1 bei Flaechenspells (die mehrere Ziele treffen koennen)
- @WER1/@WESSEN1/@WEM1/@WEN1 - name(casus) des Getroffenen (TO)
- @WER2/@WESSEN2/@WEM2/@WEN2 - name(casus) des Feindes (enemy)
+ * SP_REDUCE_ARMOUR (mapping) ------------ Mapping: keys
+ AT_X/P_BODY, values int>=0
- EINFO_DEFEND ------------ Mapping Dieses Mapping liefert
- erweiterte Informationen zu dem bisherigen Ablauf des aktiven
- Attacks. Die verfuegbaren Informationen sind in der Manpage zu
- DefendInfo festgehalten.
+ 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%
+ AT_BELT: 600 // Guertel zu 600%
+ ])
+ -> alle 'fehlenden' Eintraege wirken normal
+
+ * SP_SHOW_DAMAGE (int or Array von Array)
+
+ 0 fuer keine Treffermeldung, 1 fuer Standardtreffermeldungen.
+ Falls individuelle Treffermeldungen geschwuenscht sind,
+ koennen aber auch in einem Array Ersatz-Treffermeldungen
+ definiert werden. Das Format ist:
+
+ ({
+ ({ int lphit1, string mess_me, string mess_en, string mess_room }),
+ ({ lphit2, mess_me, mess_en, mess_room }),
+ ...
+ ({ lphitn, mess_me, mess_en, mess_room }),
+ })
+ wobei lphit1<lphit2<...<lphitn sein muss, d.h. das Array-Array
+ aufsteigend sortiert.
+
+ Ist ein Treffer x LP hart, werden die Meldungen des lphit-
+ Arrays ausgegeben, dessen Wert am naehesten unter dem Schaden
+ liegt.
+
+ In den Meldungen mess_me (an den Getroffenen), mess_en (an den
+ Feind), mess_room (an die restlichen Umstehenden) koennen
+ Ersatzstrings wie folgt verwendet werden:
+
+ @WER1/@WESSEN1/@WEM1/@WEN1 - name(casus) des Getroffenen (TO)
+ @WER2/@WESSEN2/@WEM2/@WEN2 - name(casus) des Feindes (enemy)
+
+ * EINFO_DEFEND (mapping)
+
+ Dieses Mapping liefert erweiterte Informationen zu dem
+ bisherigen Ablauf des aktiven Attacks. Die verfuegbaren
+ Informationen sind in der Manpage zu DefendInfo festgehalten.
Reihenfolgen in Defend
@@ -192,6 +220,6 @@
Resistenz: P_RESISTANCE_STRENGTHS, CheckResistance()
Sonstiges: CheckSensitiveAttack(), InternalModifyDefend(),
- UseSkill(), DefendInfo()
+ normalize_defend_args() UseSkill(), DefendInfo()
-Letzte Aenderung: 29.12.2017, Bugfix
+Letzte Aenderung: 20.01.2019, Zesstra
diff --git a/doc/lfun/InternalModifyDefend b/doc/lfun/InternalModifyDefend
index efe50ab..7fbfae5 100644
--- a/doc/lfun/InternalModifyDefend
+++ b/doc/lfun/InternalModifyDefend
@@ -10,8 +10,8 @@
FUNKTION
========
- protected void InternalModifyDefend(int dam, string* dt, mapping
- spell, object enemy)
+ protected void InternalModifyDefend(int dam, string* dam_types,
+ mapping si_spell, object enemy)
DEFINIERT IN
@@ -26,10 +26,10 @@
int dam
Staerke des abzuwehrenden Angriffs (in HP/10)
- string* dt
+ string* dam_types
Art(en) des Schadens, der angerichtet werden soll
- mapping spell
+ mapping si_spell
Mapping mit zusaetzlichen Informationen ueber den Angriff
object enemy
diff --git a/doc/lfun/normalize_defend_args b/doc/lfun/normalize_defend_args
new file mode 100644
index 0000000..7b41e74
--- /dev/null
+++ b/doc/lfun/normalize_defend_args
@@ -0,0 +1,89 @@
+
+normalize_defend_args()
+***********************
+
+
+FUNKTION
+========
+
+ protected nomask void normalize_defend_args(int dam,
+ string|string* dam_types, int|mapping si_spell, object enemy)
+
+
+DEFINIERT IN
+============
+
+ /std/living/combat.c
+
+
+ARGUMENTE
+=========
+
+ Die Argumente sind die Argumente, welche Defend() uebergeben
+ bekommt (siehe dort!)
+
+
+BESCHREIBUNG
+============
+
+ Defend bekommt aus historischem Code haeufig Argumente uebergeben,
+ die nicht der aktuellen Konvention entsprechen (z.B. si_spell als 0
+ oder 1 statt eines Mappings). Damit nun nicht jedes Objekt seine
+ eigene Anpassung vornehmen muss und dabei evtl. noch etwas
+ vergessen wird, kann man mit dieser Funktion die Argumente genauso
+ "normieren", wie es in der Standardlib in Defend() auch gemacht
+ wuerde.
+
+ Dieses wird ganz dringend empfohlen statt diese Normierung selber
+ vorzunehmen. Und sollte es hier Aenderungen geben, bekommt man
+ diese automatisch mit.
+
+ Nach dem Aufruf dieser Funktion (Argumente als Referenz
+ uebergeben!) liegen die Argumente dann wie folgt vor:
+
+ dam
+ ein Integer (unveraendert)
+
+ dam_types
+ ein Array von Schadenstypen
+
+ si_spell
+ ein Mapping - wenn es neu angelegt wurde, enthaelt es die
+ Eintraege SP_PHYSICAL_ATTACK, SP_SHOW_DAMAGE, SP_REDUCE_ARMOUR
+ und EINFO_DEFEND. SP_PHYSICAL_ATTACK und SP_SHOW_DAMAGE sind 1,
+ wenn si_spell 0 wahr, sonst 1.
+
+ enemy
+ ist das Objekt des Gegners oder this_player()
+
+ Alternativ zum Ueberschreiben von Defend() und Nutzung dieser
+ Funktion ist haeufig auch InternalModifyDefend() gut geeignet. Dort
+ muss *keine* eigene Normierung der uebergebenen Argumente mehr
+ vorgenommen werden!
+
+
+BEISPIELE
+=========
+
+ // Ein eigenes Defend soll Dinge tun, bevor das geerbte Defend() gerufen
+ // wird. Um den Code zu vereinfachen, sollen die Typen der Argumente aber
+ // schon sicher in einem "normierten Zustand" sein.
+ public int Defend(int dam, string|string* dam_types, int|mapping spell,
+ object enemy)
+ {
+ // Uebergabe per Referenz noetig!
+ normalize_defend_args(&dam, &dam_type, &spell, &enemy);
+ if (member(dam_types, DT_FIRE) > -1
+ && si_spell[SP_NAME] == "Drachenfeuer")
+ dam *= 2; // Schaden verdoppeln
+ return ::Defend(dam, dam_types, si_spell, enemy);
+ }
+
+
+SIEHE AUCH
+==========
+
+ Verwandt:
+ InternalModifyDefend(), Defend(), DefendInfo()
+
+16.01.2019 Zesstra
diff --git a/doc/props/P_AVERAGE_SIZE b/doc/props/P_AVERAGE_SIZE
index 155528f..0208ef4 100644
--- a/doc/props/P_AVERAGE_SIZE
+++ b/doc/props/P_AVERAGE_SIZE
@@ -18,4 +18,15 @@
BESCHREIBUNG
============
- Durchschnittliche Groesse eines Wesens dieser Rasse (derzeit nur Player)
+ Durchschnittliche Groesse eines Wesens dieser Rasse (in cm).
+ Bei den Rassen im Morgengrauen sind das:
+
+ Menschen 175
+ Magier sind im Durchschnitt etwas groesser ;-)
+ Orks 195
+ Hobbits 105
+ Goblins 80
+ Felinen 200
+ Zwerge 120
+ Elfen 195
+ Dunkelfen 175
diff --git a/doc/props/P_SECOND b/doc/props/P_SECOND
index 69c97d6..dc0a6f7 100644
--- a/doc/props/P_SECOND
+++ b/doc/props/P_SECOND
@@ -6,7 +6,7 @@
NAME
====
- P_SECOND "second"
+ P_SECOND "second"
DEFINIERT IN
@@ -18,8 +18,18 @@
BESCHREIBUNG
============
- Wenn diese Prop gesetzt ist, ist der Spieler ein Zweitie. Inhalt der
- Prop ist ein String mit dem (lowercase) Namen des Ersties.
+ Wenn diese Prop gesetzt ist, ist der Spieler ein Zweitie. Inhalt
+ der Prop ist ein String mit dem (lowercase) Namen des Ersties. Ob
+ anderen Spielern angezeigt wird, dass jemand Zweitie ist, kann
+ mittels der Property P_SECOND_MARK gesteuert werden.
+
+ Bitte auch das Konzept der Familie beachten (s. FAMILIEN) und
+ speziell bei Aenderung von P_SECOND ggf. die Familie eintragen
+ lassen.
+
+ Soll ein Spieler kein Zweitie mehr sein, bitte zusaetzlich zum
+ Loeschen dieser Property den Zweitieeintrage auch in
+ /secure/zweities loeschen (lassen).
BEISPIEL
@@ -33,7 +43,16 @@
SIEHE AUCH
==========
- Properties: P_SECOND_MARK
- Sonstiges: /secure/zweities.c
+ Familien:
+ FAMILIEN
-Last modified: 18-Jun-2015, Arathorn.
+ Kommandos:
+ *../pcmd/zweitiemarkierung*
+
+ Properties:
+ P_SECOND_MARK
+
+ Sonstiges:
+ /secure/zweities.c
+
+Last modified: 08.01.2019, Zesstra
diff --git a/doc/wiz.index b/doc/wiz.index
index f402650..bf37c11 100644
--- a/doc/wiz.index
+++ b/doc/wiz.index
@@ -9,4 +9,10 @@
Verzeichnis der Manpages:
+* FAMILIEN
+
+* Erstellung neuer Repositories in Gerrit
+
+* Hinweise fuer Erzmagier / Admins
+
* Homemud
diff --git a/doc/wiz/familien b/doc/wiz/familien
index 5998c3c..6f1d305 100644
--- a/doc/wiz/familien
+++ b/doc/wiz/familien
@@ -1,52 +1,67 @@
+
FAMILIEN
-========
+********
+
BESCHREIBUNG
-------------
+============
-Eine Familie umfasst den Erstie und alle Zweities, sprich alle diese haben den
-gleichen "Familiennamen". Dieser Name ist in der Regel die UUID des Ersties
-dieser Familie. Falls aber der Erstie sich aendern sollte (z.B. Magierwerdung
-eines Zweities) und sich der Familienname nicht aendern soll, dann koennen
-wir den Namen dieser Familie beibehalten (d.h. alter Erstie).
+ Eine Familie umfasst den Erstie und alle Zweities, sprich alle
+ diese haben den gleichen "Familiennamen". Dieser Name ist in der
+ Regel die UUID des Ersties dieser Familie. Falls aber der Erstie
+ sich aendern sollte (z.B. Magierwerdung eines Zweities) und sich
+ der Familienname nicht aendern soll, dann koennen wir den Namen
+ dieser Familie beibehalten (d.h. alter Erstie).
-Will man wissen, welcher Familie ein Char angehoert (egal, ob Erstie oder
-Zweitie), dann geht das mit:
-# xcall /secure/zweities->QueryFamilie(player_object)
+ Will man wissen, welcher Familie ein Char angehoert (egal, ob
+ Erstie oder Zweitie), dann geht das mit:
-Des Weiteren liefert dieses Objekt auch noch zu jedem Zweitie den Erstie und
-zu jedem Erstie die Liste aller bekannten Zweities:
-# xcall /secure/zweities->QueryErstieName(player_object)
-# xcall /secure/zweities->QueryErstieUUID(player_object)
-# xcall /secure/zweities->QueryZweities(player_object)
+ # xcall /secure/zweities->QueryFamilie(player_object)
-Der Datenbestand ist (noch) nicht vollstaendig, daher fehlen da noch viele
-Chars. Die werden aber in absehbarer Zeit dort nachgetragen.
+ Des Weiteren liefert dieses Objekt auch noch zu jedem Zweitie den
+ Erstie und zu jedem Erstie die Liste aller bekannten Zweities:
-Die Familie wird in Zukunft genutzt, um Dinge zu personalisieren, welche fuer
-den Spieler, aber nicht fuer den Char individuell sein sollen. Sprich:
-personalisiert man irgendwas ueber die Familie, koennen alle Chars dieser
-Familie das irgendwas nutzen.
+ # xcall /secure/zweities->QueryErstieName(player_object)
+ # xcall /secure/zweities->QueryErstieUUID(player_object)
+ # xcall /secure/zweities->QueryZweities(player_object)
+
+ Der Datenbestand ist (noch) nicht vollstaendig, daher fehlen da
+ noch viele Chars. Die werden aber in absehbarer Zeit dort
+ nachgetragen.
+
+ Die Familie wird in Zukunft genutzt, um Dinge zu personalisieren,
+ welche fuer den Spieler, aber nicht fuer den Char individuell sein
+ sollen. Sprich: personalisiert man irgendwas ueber die Familie,
+ koennen alle Chars dieser Familie das irgendwas nutzen.
+
VERWALTUNG
-----------
+==========
-Wenn sich der Erstie aendert, aber die Familie aller Zweities erhalten bleiben
-soll (z.B. weil sich der Erstie innerhalb der Familie wegen Magierwerdung
-aendert), muss dies in der Familienverwaltung hinterlegt werden, indem fuer
-den *neuen* Erstie die alte Familien-ID eingetragen wird. Dies koennen zur
-Zeit EM+.
+ Wenn sich der Erstie aendert, aber die Familie aller Zweities
+ erhalten bleiben soll (z.B. weil sich der Erstie innerhalb der
+ Familie wegen Magierwerdung aendert), muss dies in der
+ Familienverwaltung hinterlegt werden, indem fuer den *neuen* Erstie
+ die alte Familien-ID eingetragen wird. Dies koennen zur Zeit EM+.
-Beispiel: Der alte Erstie einer Familie ist bert_123456, der neue Erstie ist
-alice_654321. Die Familie soll aber weiterhin bert_123456 sein:
-# xcall /secure/zweities->SetFamilie("alice_654321, "bert_123456")
-Ein solcher expliziter Familieneintrag kann wieder geloescht werden:
-# xcall /secure/zweities->DeleteFamilie("alice_654321")
+ Beispiel: Der alte Erstie einer Familie ist bert_123456, der neue
+ Erstie ist alice_654321. Die Familie soll aber weiterhin
+ bert_123456 sein:
-EM+ koennen Zweities wieder aus der Datenbank loeschen (UUID angeben!):
-# xcall /secure/zweities->DeleteZweitie("bert_12345")
+ # xcall /secure/zweities->SetFamilie("alice_654321, "bert_123456")
+ Ein solcher expliziter Familieneintrag kann wieder geloescht
+ werden:
+
+ # xcall /secure/zweities->DeleteFamilie("alice_654321")
+
+ EM+ koennen Zweities wieder aus der Datenbank loeschen (UUID
+ angeben!):
+
+ # xcall /secure/zweities->DeleteZweitie("bert_12345")
+
+SIEHE AUCH:
+ P_SECOND, P_SECOND_MARK
LETZTE AeNDERUNG:
- 8.1.2019, Zesstra
-
+ 8.1.2019, Zesstra