Update diverser Manpages und Beispiele
Change-Id: I07094305b7697550dac8667a26e150ca23560e41
diff --git a/doc/beispiele/misc/bsptransporter1.c b/doc/beispiele/misc/bsptransporter1.c
index 3e26020..d3c5475 100644
--- a/doc/beispiele/misc/bsptransporter1.c
+++ b/doc/beispiele/misc/bsptransporter1.c
@@ -26,23 +26,24 @@
SetProp(P_LIGHT, 1 );
SetProp(P_TRANSPARENT,1);
// Man soll auf(in) die Wolke und von ihr herunter schauen koennen.
-
+
/*** Meldungen, die Transporter geben koennen ***/
-
+
SetProp( P_DEPARTMSG, ({
- "Die Wolke steigt in die Luft.\n",
+ "Die Wolke steigt in die Luft.\n",
"Die Wolke fliegt davon.\n"
}) );
// Die erste Meldung ist fuer Leute auf der Wolke.
// Die zweite fuer Leute in dem Raum, in dem die Wolke ankommt.
-
- SetProp( P_ARRIVEMSG, ({
- "Die Wolke naehert sich dem Boden von @@QueryArrived@@.\n",
- "Eine kleine Wolke schwebt herab.\n"
- }) );
+
+ Set( P_ARRIVEMSG, function string* () {
+ return ({
+ sprintf("Die Wolke naehert sich dem Boden von %s.\n",QueryArrived()),
+ "Eine kleine Wolke schwebt herab.\n"});
+ }, F_QUERY_METHOD);
// Die erste Meldung ist fuer Leute auf der Wolke.
// Die zweite fuer Leute in dem Raum, aus dem die Wolke abreist.
-
+
SetProp( P_ENTERMSG, ({
"steigt auf die Wolke",
"kommt auf die Wolke"
@@ -50,7 +51,7 @@
// Die erste Meldung ist fuer den Raum, aus dem der Spieler kommt.
// (=Raum). Die zweite Meldung ist fuer Spieler in dem Raum, in
// den der Spieler geht (=Transporter).
-
+
SetProp( P_LEAVEMSG, ({
"steigt von der Wolke",
"steigt von der Wolke"
@@ -58,7 +59,7 @@
// Die erste Meldung ist fuer den Raum, aus dem der Spieler kommt.
// (=Transporter). Die zweite Meldung ist fuer Spieler in dem Raum,
// in den der Spieler geht (=Raum).
-
+
SetProp( P_LEAVEFAIL, "Die Wolke schwebt viel zu hoch" );
// Meldung, die kommt, wenn ein Spieler den Transporter verlassen
// will, aber dieser an keinem Raum angelegt hat.
@@ -108,7 +109,7 @@
AddMsg( "Die Wolke beginnt zu sinken.\n", 10 );
// Nach dem Letzten Haltepunkt wird der Kurs wieder von vorn
// befahren.
-
+
Start();
// Lasse den Transporter am ersten dieser Haltepunkte starten.
}
@@ -116,7 +117,7 @@
steige(str)
{
string arg, arg2;
-
+
if (sscanf( str, "auf %s", arg ) > 0 && id(old_explode(arg," ")[0]))
return Enter();
// Wenn sicher ist, dass der Spieler die Wolke BEsteigen will,
@@ -128,5 +129,3 @@
// Verben sollten nach Enter() oder Leave() keine weiteren Befehle
// enthalten.
}
-
-
diff --git a/doc/lfun/AddInfo b/doc/lfun/AddInfo
index c684fe0..76c6e1c 100644
--- a/doc/lfun/AddInfo
+++ b/doc/lfun/AddInfo
@@ -6,8 +6,8 @@
FUNKTION
========
- varargs void AddInfo( frage, meldung
- [, indent [, [silent [, casebased] ] ] );
+ public varargs void AddInfo(string|string* key, string|closure info,
+ string indent, int|string silent, string|closure casebased);
DEFINIERT IN
@@ -19,22 +19,23 @@
ARGUMENTE
=========
- string/string* frage
- Schluesseltext(e) auf die Informationen gegeben werden sollen.
+ string|string* frage
+ Schluesselwoerter, fuer die der NPC eine Antwort geben soll,
+ wenn man ihn danach fragt
- string/closure meldung
+ string|closure meldung
Information, die gegeben werden soll; wenn 'meldung' eine
Closure ist, wird der gerufenen Funktion nichts uebergeben.
- string indent
+ string indent (optional)
Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
- int/string silent
+ int|string silent (optional)
Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
- string/closure casebased
- Closure mit Returnwert string oder int. Bekommt nichts
- uebergeben.
+ string|closure casebased (optional)
+ Closure mit Returnwert string oder int. Der Funktion werden
+ keine Argumente uebergeben.
BESCHREIBUNG
@@ -79,7 +80,7 @@
Die Strings von 'silent' und 'meldung' werden geparsed. Dabei
koennen die @[...]-Tags von replace_personal() verwendet werden,
- Objekt 1 ist this_player(). Ersetzte String am Satzanfang werden
+ Objekt 1 ist this_player(). Ersetzte Strings am Satzanfang werden
automatisch gross geschrieben. AddInfo() konvertiert die alten
Schluesselworte @WER, @WESSEN, @WEM, @WEN zu denen von
replace_personal(), jedoch nicht in den Rueckgabe- werten von
@@ -265,4 +266,4 @@
Interna:
GetInfoArr() , do_frage()
-7. Mar 2017 Gloinson
+24.09.2020, Arathorn
diff --git a/doc/lfun/AddMoney b/doc/lfun/AddMoney
index 8f15cc6..6518215 100644
--- a/doc/lfun/AddMoney
+++ b/doc/lfun/AddMoney
@@ -69,10 +69,10 @@
BEISPIELE
=========
- #include <zentralbank.h>
+ #include <bank.h>
// gib ihm Geld
- int money = ZENTRALBANK->Withdraw(50);
+ int money = ZENTRALBANK->WithDraw(50);
this_player()->AddMoney(money);
// nimm ihm Geld
@@ -86,9 +86,11 @@
SIEHE AUCH
==========
- Geldhandling: QueryMoney(L) Zentralbank: PayIn(L),
- WithDraw(L) Sonstiges: move(L), /items/money.c,
- /sys/moving.h, /sys/money.h, /sys/bank.h
- /std/container/moneyhandler.c
+ Geldhandling: QueryMoney(L)
+ Zentralbank: PayIn(L), WithDraw(L)
+ Sonstiges: move(L),
+ /items/money.c
+ /sys/moving.h, /std/container/moneyhandler.c
+ /sys/money.h, /sys/bank.h
18.02.2013, Zesstra
diff --git a/doc/lfun/AddRoomMessage b/doc/lfun/AddRoomMessage
index 82c2c99..47e2b60 100644
--- a/doc/lfun/AddRoomMessage
+++ b/doc/lfun/AddRoomMessage
@@ -66,7 +66,7 @@
verlassen haben
* ist manuell nur ueber Loeschen der Nachrichten umsetzbar,
- also mit "AddRoomMessage((string)0, 0, (string)0);"
+ also mit "AddRoomMessage(0, 0, 0);"
In Funktionen, die durch AddRoomMessage() ausgeloest werden, darf
this_player() nicht verwendet werden, da die call_out()-Kette den
@@ -130,7 +130,7 @@
}
public int action_laerm(string str) {
- AddRoomMessage((string)0, 0, (string)0);
+ AddRoomMessage(0, 0, 0);
this_player()->ReceiveMsg(
"Du schreist dir kurz die Seele aus dem Leib. Alle Tiere "
diff --git a/doc/lfun/AddSpecialInfo b/doc/lfun/AddSpecialInfo
index efc3067..be61558 100644
--- a/doc/lfun/AddSpecialInfo
+++ b/doc/lfun/AddSpecialInfo
@@ -6,23 +6,31 @@
FUNKTION
========
- varargs void AddSpecialInfo( frage, meldung
- [, indent [, [silent [, casebased] ] ] );
+ public varargs void AddSpecialInfo(string|string* keys, string functionname,
+ string indent, int|string silent, string|closure casebased);
ARGUMENTE
=========
- string/string* frage
- Schluesseltext(e) auf die Informationen gegeben werden sollen.
- string/closure function
- Methodenname im NPC/Closure
- string indent
- Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
- int/string silent
- Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
- string/closure casebased
- Funktionsname oder Closure mit Returnwert string oder int.
+ string|string* frage
+ Schluesselwoerter, fuer die der NPC eine Antwort geben soll, wenn
+ man ihn danach fragt
+
+ string functionname
+ Name der Funktion, die gerufen werden soll, um den Informationstext
+ des NPCs zu ermitteln. Der gerufenen Funktion werden keine Argumente
+ uebergeben.
+
+ string indent (optional)
+ Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
+
+ int|string silent (optional)
+ Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
+
+ string|closure casebased (optional)
+ Closure mit Returnwert string oder int.
+ Der Funktion werden keine Argumente uebergeben.
DEFINIERT IN
@@ -83,6 +91,19 @@
SIEHE AUCH
==========
- AddInfo(L), RemoveInfo(L)
+ Verwandt:
+ AddInfo(), RemoveInfo()
-7.Apr 2004 Gloinson
+ Props:
+ P_PRE_INFO
+
+ Files:
+ /std/npc/info.c
+
+ Loggen:
+ P_LOG_INFO
+
+ Interna:
+ GetInfoArr() , do_frage()
+
+24.09.2020, Arathorn
diff --git a/doc/lfun/Attack b/doc/lfun/Attack
index 08a0c20..1e958de 100644
--- a/doc/lfun/Attack
+++ b/doc/lfun/Attack
@@ -18,8 +18,8 @@
BESCHREIBUNG
============
- Der Feind wird der Staerke der Waffe (bzw. der Haende) entsprechend
- stark angegriffen.
+ Der Feind wird entsprechend der Angriffsstaerke der Waffe (P_WC) bzw. der
+ Haende (P_HANDS[1]) angegriffen.
RUECKGABEWERT
@@ -33,10 +33,10 @@
Diese Funktion gibt die Angriffsmeldung aus.
Falls mit blossen Haenden angegriffen wird, ist die Staerke
- (2*Staerke_der_Haende + 10*A_STR)/3
+ (2 * P_HANDS[1] + 10 * A_STR)/3
SIEHE AUCH
==========
- "Defend", "QueryDamage"
+ Defend(), QueryDamage()
diff --git a/doc/lfun/CheckResistance b/doc/lfun/CheckResistance
index bcf64ca..52bfe23 100644
--- a/doc/lfun/CheckResistance
+++ b/doc/lfun/CheckResistance
@@ -6,7 +6,7 @@
FUNKTION
========
- CheckRessistance(string* dam_type_list)
+ public float CheckResistance(string* dam_type_list)
ARGUMENTE
@@ -34,4 +34,4 @@
SIEHE AUCH
==========
- "Defend"
+ Defend(), P_RESISTANCE_STRENGTHS
diff --git a/doc/lfun/DefendFunc b/doc/lfun/DefendFunc
index 5338a9f..00bfc91 100644
--- a/doc/lfun/DefendFunc
+++ b/doc/lfun/DefendFunc
@@ -61,46 +61,43 @@
BEISPIELE
=========
- Eine Ruestung, die bei Angriffen mit Feuer ihre volle Staerke
- entfaltet und bei Angriffen durch Geister geschwaecht wird:
+ Eine Ruestung, die bei Angriffen mit Feuer ihre volle Staerke entfaltet
+ und bei Angriffen durch Geister geschwaecht wird:
- protected void create() {
+ protected void create()
+ {
+ ::create();
- ::create();
-
- SetProp(P_ARMOUR_TYPE, AT_ARMOUR); SetProp(P_AC, 20); ... // Die
- DefendFunc() ist in der Ruestung selbst definiert
- SetProp(P_DEFEND_FUNC, this_object());
-
+ SetProp(P_ARMOUR_TYPE, AT_ARMOUR);
+ SetProp(P_AC, 20);
+ ...
+ // Die DefendFunc() ist in der Ruestung selbst definiert
+ SetProp(P_DEFEND_FUNC, this_object());
}
- public int DefendFunc(string* dtyp, mapping spell, object enemy) {
+ public int DefendFunc(string* dtyp, mapping spell, object enemy)
+ {
+ int prot;
- int prot;
+ // Zuerst fragen wir den Angriff durch Feuer ab:
+ if (member(dtyp, DT_FIRE) >= 0) // Feuer gehoert zu den Schadenstypen
+ prot = 5 + random(10); // Das ergibt maximal 14. Zusammen mit P_AC
+ // kommt man also maximal auf 14+20 = 34,
+ // liegt also unter der fuer AT_ARMOUR
+ // geltenden Obergrenze
- // Zuerst fragen wir den Angriff durch Feuer ab: if
- (member(dtyp, DT_FIRE) >= 0) // Feuer gehoert zu den
- Schadenstypen
+ // Und jetzt der Geistertest
+ if (enemy->QueryProp(P_RACE) == "Geist" ||
+ enemy->is_class_member(CL_GHOST))
+ prot -= random(10);
- prot = 5 + random(10); // Das ergibt maximal 14. Zusammen mit
- P_AC
- // kommt man also maximal auf 14+20 = 34, // liegt also
- unter der fuer AT_ARMOUR // geltenden Obergrenze
-
- // Und jetzt der Geistertest if (enemy->QueryProp(P_RACE) ==
- "Geist" ||
-
- enemy->is_class_member(CL_GHOST))
-
- prot -= random(10);
-
- // Der Rueckgabewert wird auf den aus P_AC errechneten Wert
- draufgeschlagen return prot;
-
+ // Der Rueckgabewert wird auf den aus P_AC errechneten Wert
+ // draufgeschlagen
+ return prot;
}
SIEHE AUCH
==========
- P_DEFEND_FUNC, *QueryDefendd* /std/armour/combat.c
+ P_DEFEND_FUNC, QueryDefend() /std/armour/combat.c
diff --git a/doc/lfun/QueryArmourByType b/doc/lfun/QueryArmourByType
index 20fcab5..5c9da6f 100644
--- a/doc/lfun/QueryArmourByType
+++ b/doc/lfun/QueryArmourByType
@@ -10,7 +10,7 @@
FUNKTION
========
- mixed QueryArmourByType(string type)
+ object|object*|mapping QueryArmourByType(string type)
DEFINIERT IN
@@ -31,17 +31,27 @@
Abfrage, ob das Lebewesen eine Ruestung des angegebenen Typs traegt.
- Zurueckgegeben wird je nach Tragestatus und <type>:
- * 0, falls das Lebewesen die gesuchte Ruestungsart nicht traegt
- * im Erfolgsfall das Ruestungsobjekt
- * falls <type> AT_MISC ist:
- * ({}), wenn es keine AT_MISC-Ruestung traegt
- * ein Array von AT_MISC-Ruestungen
- * falls <type> 0 ist: ein Mapping, das diese Informationen mit dem
- Ruestungstypen als Schluessel enthaelt:
- ([AT_MISC: ({[object], ...}),
- AT_...: <object>,
- ... ])
+
+RUECKGABEWERTE
+==============
+
+ Zurueckgegeben wird abhaengig vom Argument <type> folgendes:
+
+ 1) Ist <type> ein Typ, von dem man nur eine Ruestung tragen kann:
+ * 0, falls das Lebewesen die gesuchte Ruestungsart nicht traegt,
+ * ansonsten das Ruestungsobjekt
+
+ 2) Ist <type> AT_MISC:
+ * ein Array mit allen AT_MISC-Ruestungen
+ * ({}), wenn das Lebewesen keine AT_MISC-Ruestung traegt
+
+ 3) Ist <type> 0:
+ * Ein Mapping mit den Ruestungstypen als Schluessel der folgenden
+ Form:
+ ([AT_MISC: ({object misc1, ... }),
+ AT_CLOAK: object cloak,
+ AT_...: object ...,
+ ... ])
BEMERKUNG
diff --git a/doc/lfun/create_default_npc b/doc/lfun/create_default_npc
index 09c3a14..fac3fe2 100644
--- a/doc/lfun/create_default_npc
+++ b/doc/lfun/create_default_npc
@@ -47,7 +47,10 @@
wurden, werden durch die neuen Werte ersetzt.
Ab einem Aufruf mit Level 20 werden P_XP = 202000 gesetzt, also ein
- Kill-Stup vergeben (siehe P_XP).
+ Kill-Stups vergeben (siehe P_XP).
+
+ P_HP und P_SP werden auf dieselben Werte wie P_MAX_HP bzw. P_MAX_SP
+ eingestellt.
BEISPIEL
diff --git a/doc/props/P_MAGIC_RESISTANCE_OFFSET b/doc/props/P_MAGIC_RESISTANCE_OFFSET
index 8d270e3..111b94e 100644
--- a/doc/props/P_MAGIC_RESISTANCE_OFFSET
+++ b/doc/props/P_MAGIC_RESISTANCE_OFFSET
@@ -37,7 +37,7 @@
// Goblins
SetProp(P_MAGIC_RESISTANCE_OFFSET,
([MT_ANGRIFF:600, // 6% Resistenz gegen Angriff
- MT_ILLUSION:500, // 6% Resistenz gegen Illusionen
+ MT_ILLUSION:500, // 5% Resistenz gegen Illusionen
MT_VERWANDLUNG:-300, // 3% Empfindlichkeit
MT_HELLSICHT:-750, // 7.5% Empfindlichkeit
MT_BEHERRSCHUNG:250])); // 2.5% Resistenz
diff --git a/doc/props/P_MAX_HP b/doc/props/P_MAX_HP
index fcb3cb0..6534adb 100644
--- a/doc/props/P_MAX_HP
+++ b/doc/props/P_MAX_HP
@@ -21,6 +21,13 @@
Maximale Anzahl der Lebenspunkte.
+HINWEIS
+=======
+
+ Beim Setzen der Property wird gleichzeitig P_HP auf denselben Wert
+ gesetzt.
+
+
SIEHE AUCH
==========
diff --git a/doc/props/P_MAX_SP b/doc/props/P_MAX_SP
index 7f7aa43..84f788c 100644
--- a/doc/props/P_MAX_SP
+++ b/doc/props/P_MAX_SP
@@ -21,6 +21,13 @@
Maximale Anzahl der Magiepunkte.
+HINWEIS
+=======
+
+ Beim Setzen der Property wird gleichzeitig P_SP auf denselben Wert
+ gesetzt.
+
+
SIEHE AUCH
==========
diff --git a/doc/sefun/process_string b/doc/sefun/process_string
index fbc7018..4d72259 100644
--- a/doc/sefun/process_string
+++ b/doc/sefun/process_string
@@ -8,41 +8,43 @@
FUNKTION
========
- string process_string(string str)
- string process_string(closure cl)
+ string process_string(string str) string process_string(closure cl)
BESCHREIBUNG
============
- Durchsucht den String str nach Vorkommnissen von Substrings, die "Wert
- durch Funktionsaufruf zu ersetzen" andeuten. Die Form ist: @@, gefolgt
- durch einen impliziten Funktionsaufruf.
+ Beschreibung s. efun/process_string.
- Der zu ersetzenden Substring hat die Form:
- @@function[:filename][|argument1|argument2]@@
+ Abweichend zu der Beschreibung gibt es im MG folgende wichtige
+ Punkte:
- Die entsprechende Funktion muss einen String zurueckgeben, oder der
- process_string() uebergebene String str wird nicht modifiziert.
+ * nicht in neuem Code nutzen, aus altem Code ausbauen
- process_string() arbeitet nicht rekursiv, object_name und argument sind
- optionale Werte.
+ * nicht nutzbar fuer Objekte mit einer UID mit einem Level > 30.
- Falls eine Closure angegeben wurde, wird diese lediglich gerufen
- und nicht gefiltert.
+ * nicht rufbar durch Magiershells
+ * kann Funktionen in anderen Objekten nur rufen, wenn diese zum
+ gleichen Magier gehoeren.
-ANMERKUNGEN
-===========
+ Folgendes Properties und Details werden bei der Abfrage ueber
+ process_string() gefiltert:
- - Die Funktion, die gerufen werden soll, _muss_ mit einem Buchstaben
- anfangen, '_' ist nicht moeglich!
- - folgendes Properties und Details werden bei der Abfrage ueber
- process_string() gefiltert:
- P_LONG, P_SHORT, P_READ_MSG, AddReadDetail()-Details und NPC-Chats
- P_INT_LONG ueber int_long(), P_INT_SHORT ueber int_short()
- - die Nutzung kann zu Sicherheitsproblemen fuehren, siehe auch
- process_call()
+ * P_LONG
+
+ * P_SHORT
+
+ * Details
+
+ * NPC-Chats
+
+ * P_INT_LONG
+
+ * P_INT_SHORT
+
+ Die Nutzung kann zu Sicherheitsproblemen fuehren, siehe auch
+ process_call().
BEISPIEL
@@ -58,7 +60,6 @@
-> bei Abfrage: "Die Beschreibung." oder "Die andere Beschreibung."
-
// Teilersetzung
SetProp(P_SHORT, "Ein @@farbenfun|huebsch@@ Ding");
...
@@ -72,6 +73,6 @@
SIEHE AUCH
==========
- notify_fail(E), process_call(E), replace_personal(E)
+ process_call(), replace_personal()
-22. Nov. 2006 Arathorn
+02.09.2020 Zesstra
diff --git a/doc/sefun/replace_personal b/doc/sefun/replace_personal
index 3804be3..a8946e5 100644
--- a/doc/sefun/replace_personal
+++ b/doc/sefun/replace_personal
@@ -47,8 +47,6 @@
x steht fuer die Position des Objekts/Strings in *obs, beginnend bei 1.
-
-
Besonderheiten beim Possessivpronomen (@WERQPPGNx):
G muss durch das Geschlecht (M, F oder N) und N durch den Numerus (S
oder P) ersetzt werden.
@@ -62,47 +60,45 @@
durchersetzter String
+
Beispiele
+=========
- replace_personal("@WER1", ({find_player("gloinson")})) ==
- "Gloinson"
+ replace_personal("@WER1", ({find_player("gloinson")})) ==> "Gloinson"
- replace_personal("@WEMQP1", ({find_player("gloinson")})) == "ihm"
+ replace_personal("@WEMQP1", ({find_player("gloinson")})) ==> "ihm"
- // unbestimmter und bestimmter Artikel: replace_personal("@WER1
- zueckt @WENU2 und verhaut @WEN3.",
+ // unbestimmter und bestimmter Artikel:
+ replace_personal("@WER1 zueckt @WENU2 und verhaut @WEN3.",
+ ({find_player("gloinson"),
+ find_object("/obj/mpa"),
+ find_object("/obj/wanderer")}))
+ ==> "Gloinson zueckt eine Zeitung und verhaut den Wanderer."
- ({find_player("gloinson"),
- find_object("/obj/mpa"), find_object("/obj/wanderer")}))
-
- == "Gloinson zueckt eine Zeitung und verhaut den Wanderer."
-
- // Beim Possessivpronomen beziehen sich WEN, F und P (Akkusativ, //
- Femininum, Plural) auf die Taschen, nicht auf Kessa:
+ // Beim Possessivpronomen beziehen sich WEN, F und P (Akkusativ,
+ // Femininum, Plural) auf die Taschen, nicht auf Kessa:
replace_personal("@WER1 steckt @WESSEN2 Turnschuhe in @WENQPPFP1 "
+ "Taschen.",
+ ({find_player("kessa"),
+ find_player("gloinson")}))
+ ==> "Kessa steckt Gloinsons Turnschuhe in ihre Taschen."
- "Taschen.", ({find_player("kessa"),
-
- find_player("gloinson")}))
-
- == "Kessa steckt Gloinsons Turnschuhe in ihre Taschen."
-
- // Ein Beispiel mit laengerem >>*<<obs: replace_personal("@WER1
- zieht @WENQPPMP1 neuen Turnschuhe an. @WER2 ist "
-
- "so beeindruckt, dass @WERQP2 @WEMQP1 @WENU3 auf die " "@WEN4
- haut und die Schuhe in @WEMQPPFS2 Tasche " "verschwinden laesst.
- @WERU5 schaut zu und kichert " "irre. Wenn das @WER6 gesehen
- haette!", ({find_player("gloinson"),
-
- find_player("kessa"), find_object("/obj/mpa"), "Birne",
- find_object("/obj/wanderer"), find_netdead("jof")}),1)
-
- == "Gloinson zieht seine neuen Turnschuhe an. Kessa ist so
- beeindruckt, "
- "dass sie ihm eine Zeitung auf die Birne haut und die Schuhe in
- ihrer " "Tasche verschwinden laesst. Ein Wanderer schaut zu und
- kichert " "irre. Wenn das Jof gesehen haette!"
+ // Ein Beispiel mit laengerem *obs:
+ replace_personal("@WER1 zieht @WENQPPMP1 neuen Turnschuhe an. @WER2 ist "
+ "so beeindruckt, dass @WERQP2 @WEMQP1 @WENU3 auf die "
+ "@WEN4 haut und die Schuhe in @WEMQPPFS2 Tasche "
+ "verschwinden laesst. @WERU5 schaut zu und kichert "
+ "irre. Wenn das @WER6 gesehen haette!",
+ ({find_player("gloinson"),
+ find_player("kessa"),
+ find_object("/obj/mpa"),
+ "Birne",
+ find_object("/obj/wanderer"),
+ find_netdead("jof")}),1)
+ ==> "Gloinson zieht seine neuen Turnschuhe an. Kessa ist so "
+ "beeindruckt, dass sie ihm eine Zeitung auf die Birne haut und die "
+ "Schuhe in ihrer Tasche verschwinden laesst. Ein Wanderer schaut "
+ "zu und kichert irre. Wenn das Jof gesehen haette!"
SIEHE AUCH
diff --git a/doc/sefun/send_debug b/doc/sefun/send_debug
new file mode 100644
index 0000000..f47b748
--- /dev/null
+++ b/doc/sefun/send_debug
@@ -0,0 +1,45 @@
+
+send_debug()
+************
+
+
+FUNKTION
+========
+
+ varargs void send_debug(object|string wiz, string msg, string
+ msg_prefix)
+
+
+BESCHREIBUNG
+============
+
+ Sendet <msg> via ReceiveMsg() an das Spielerobjekt <wiz> (wenn es
+ als string angegeben wird, wird es per find_player gesucht).
+ Hierbei wird mit dem Nachrichtentyp MT_DEBUG gesendet, d.h. die
+ Meldung wird nur angezeigt, wenn das Spielerobjekt Magier oder
+ Testspieler mit aktiviertem P_WIZ_DEBUG ist.
+
+ Magier koennen P_WIZ_DEBUG mit dem Kommando 'mschau' umschalten,
+ Testspieler benoetigen hierfuer einen Magier.
+
+ Diese Debugmeldungen koennten sehr praktisch sein, aber man sollte
+ es in produktivem Code auch nicht uebertreiben, auch wenn keine
+ Ausgabe an Spieler erfolgt, wird die Zustellung jedoch bei jedem
+ Aufruf zumindest geprueft.
+
+
+BEISPIEL
+========
+
+ send_debug("zesstra", "Verbrauchte evalcosts: 42");
+
+ send_debug(this_player(), "Verbrauchte evalcost: 42",
+ "Unit-Debug: ");
+
+
+SIEHE AUCH
+==========
+
+ ReceiveMsg()
+
+14.10.2020, Zesstra
diff --git a/doc/sphinx/lfun/AddInfo.rst b/doc/sphinx/lfun/AddInfo.rst
index 5db8bef..8b5914a 100644
--- a/doc/sphinx/lfun/AddInfo.rst
+++ b/doc/sphinx/lfun/AddInfo.rst
@@ -3,9 +3,10 @@
FUNKTION
--------
+::
- varargs void AddInfo( frage, meldung
- [, indent [, [silent [, casebased] ] ] );
+ public varargs void AddInfo(string|string* key, string|closure info,
+ string indent, int|string silent, string|closure casebased);
DEFINIERT IN
------------
@@ -15,18 +16,23 @@
ARGUMENTE
---------
- string/string* frage
- Schluesseltext(e) auf die Informationen gegeben werden sollen.
- string/closure meldung
+ string|string* frage
+ Schluesselwoerter, fuer die der NPC eine Antwort geben soll, wenn
+ man ihn danach fragt
+
+ string|closure meldung
Information, die gegeben werden soll; wenn 'meldung' eine Closure
ist, wird der gerufenen Funktion nichts uebergeben.
- string indent
+
+ string indent (optional)
Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
- int/string silent
+
+ int|string silent (optional)
Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
- string/closure casebased
+
+ string|closure casebased (optional)
Closure mit Returnwert string oder int.
- Bekommt nichts uebergeben.
+ Der Funktion werden keine Argumente uebergeben.
BESCHREIBUNG
------------
@@ -69,7 +75,7 @@
Die Strings von 'silent' und 'meldung' werden geparsed.
Dabei koennen die @[...]-Tags von replace_personal() verwendet werden,
- Objekt 1 ist this_player(). Ersetzte String am Satzanfang werden
+ Objekt 1 ist this_player(). Ersetzte Strings am Satzanfang werden
automatisch gross geschrieben.
AddInfo() konvertiert die alten Schluesselworte @WER, @WESSEN, @WEM,
@WEN zu denen von replace_personal(), jedoch nicht in den Rueckgabe-
@@ -259,4 +265,4 @@
Interna:
:doc:`GetInfoArr` , :doc:`do_frage`
-7. Mar 2017 Gloinson
+24.09.2020, Arathorn
diff --git a/doc/sphinx/lfun/AddMoney.rst b/doc/sphinx/lfun/AddMoney.rst
index 416bdee..0868e51 100644
--- a/doc/sphinx/lfun/AddMoney.rst
+++ b/doc/sphinx/lfun/AddMoney.rst
@@ -65,10 +65,10 @@
.. code-block:: pike
- #include <zentralbank.h>
+ #include <bank.h>
// gib ihm Geld
- int money = ZENTRALBANK->Withdraw(50);
+ int money = ZENTRALBANK->WithDraw(50);
this_player()->AddMoney(money);
// nimm ihm Geld
@@ -80,12 +80,14 @@
SIEHE AUCH
----------
+::
- Geldhandling: QueryMoney(L)
- Zentralbank: PayIn(L), WithDraw(L)
- Sonstiges: move(L),
- /items/money.c, /sys/moving.h, /sys/money.h, /sys/bank.h
- /std/container/moneyhandler.c
+ Geldhandling: QueryMoney(L)
+ Zentralbank: PayIn(L), WithDraw(L)
+ Sonstiges: move(L),
+ /items/money.c
+ /sys/moving.h, /std/container/moneyhandler.c
+ /sys/money.h, /sys/bank.h
18.02.2013, Zesstra
diff --git a/doc/sphinx/lfun/AddRoomMessage.rst b/doc/sphinx/lfun/AddRoomMessage.rst
index 527ea54..ce325ff 100644
--- a/doc/sphinx/lfun/AddRoomMessage.rst
+++ b/doc/sphinx/lfun/AddRoomMessage.rst
@@ -53,7 +53,7 @@
* passiert automatisch nur, wenn alle Spieler den Raum verlassen haben
* ist manuell nur ueber Loeschen der Nachrichten umsetzbar, also mit
- ``AddRoomMessage((string)0, 0, (string)0);``
+ ``AddRoomMessage(0, 0, 0);``
In Funktionen, die durch AddRoomMessage() ausgeloest werden, darf
this_player() nicht verwendet werden, da die call_out()-Kette den
@@ -122,7 +122,7 @@
}
public int action_laerm(string str) {
- AddRoomMessage((string)0, 0, (string)0);
+ AddRoomMessage(0, 0, 0);
this_player()->ReceiveMsg(
"Du schreist dir kurz die Seele aus dem Leib. Alle Tiere "
diff --git a/doc/sphinx/lfun/AddSpecialInfo.rst b/doc/sphinx/lfun/AddSpecialInfo.rst
index 558b2d2..fd67141 100644
--- a/doc/sphinx/lfun/AddSpecialInfo.rst
+++ b/doc/sphinx/lfun/AddSpecialInfo.rst
@@ -5,23 +5,32 @@
--------
::
- varargs void AddSpecialInfo( frage, meldung
- [, indent [, [silent [, casebased] ] ] );
+ public varargs void AddSpecialInfo(string|string* keys, string functionname,
+ string indent, int|string silent, string|closure casebased);
+
ARGUMENTE
---------
::
- string/string* frage
- Schluesseltext(e) auf die Informationen gegeben werden sollen.
- string/closure function
- Methodenname im NPC/Closure
- string indent
- Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
- int/string silent
- Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
- string/closure casebased
- Funktionsname oder Closure mit Returnwert string oder int.
+ string|string* frage
+ Schluesselwoerter, fuer die der NPC eine Antwort geben soll, wenn
+ man ihn danach fragt
+
+ string functionname
+ Name der Funktion, die gerufen werden soll, um den Informationstext
+ des NPCs zu ermitteln. Der gerufenen Funktion werden keine Argumente
+ uebergeben.
+
+ string indent (optional)
+ Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
+
+ int|string silent (optional)
+ Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
+
+ string|closure casebased (optional)
+ Closure mit Returnwert string oder int.
+ Der Funktion werden keine Argumente uebergeben.
DEFINIERT IN
------------
@@ -80,9 +89,17 @@
SIEHE AUCH
----------
-::
- AddInfo(L), RemoveInfo(L)
+ Verwandt:
+ :doc:`AddInfo`, :doc:`RemoveInfo`
+ Props:
+ :doc:`../props/P_PRE_INFO`
+ Files:
+ /std/npc/info.c
+ Loggen:
+ :doc:`../props/P_LOG_INFO`
+ Interna:
+ :doc:`GetInfoArr` , :doc:`do_frage`
-7.Apr 2004 Gloinson
+24.09.2020, Arathorn
diff --git a/doc/sphinx/lfun/Attack.rst b/doc/sphinx/lfun/Attack.rst
index 9281478..c6357d4 100644
--- a/doc/sphinx/lfun/Attack.rst
+++ b/doc/sphinx/lfun/Attack.rst
@@ -17,8 +17,8 @@
------------
::
- Der Feind wird der Staerke der Waffe (bzw. der Haende) entsprechend
- stark angegriffen.
+ Der Feind wird entsprechend der Angriffsstaerke der Waffe (P_WC) bzw. der
+ Haende (P_HANDS[1]) angegriffen.
RUECKGABEWERT
-------------
@@ -32,11 +32,10 @@
Diese Funktion gibt die Angriffsmeldung aus.
Falls mit blossen Haenden angegriffen wird, ist die Staerke
- (2*Staerke_der_Haende + 10*A_STR)/3
+ (2 * P_HANDS[1] + 10 * A_STR)/3
SIEHE AUCH
----------
::
- "Defend", "QueryDamage"
-
+ Defend(), QueryDamage()
diff --git a/doc/sphinx/lfun/CheckResistance.rst b/doc/sphinx/lfun/CheckResistance.rst
index 7254068..b3a83da 100644
--- a/doc/sphinx/lfun/CheckResistance.rst
+++ b/doc/sphinx/lfun/CheckResistance.rst
@@ -5,7 +5,7 @@
--------
::
- CheckRessistance(string* dam_type_list)
+ public float CheckResistance(string* dam_type_list)
ARGUMENTE
---------
@@ -33,5 +33,5 @@
----------
::
- "Defend"
+ Defend(), P_RESISTANCE_STRENGTHS
diff --git a/doc/sphinx/lfun/DefendFunc.rst b/doc/sphinx/lfun/DefendFunc.rst
index 6b86f13..e0a9c78 100644
--- a/doc/sphinx/lfun/DefendFunc.rst
+++ b/doc/sphinx/lfun/DefendFunc.rst
@@ -50,6 +50,7 @@
BEISPIELE
---------
+::
Eine Ruestung, die bei Angriffen mit Feuer ihre volle Staerke entfaltet
und bei Angriffen durch Geister geschwaecht wird:
@@ -81,12 +82,13 @@
enemy->is_class_member(CL_GHOST))
prot -= random(10);
- // Der Rueckgabewert wird auf den aus P_AC errechneten Wert draufgeschlagen
+ // Der Rueckgabewert wird auf den aus P_AC errechneten Wert
+ // draufgeschlagen
return prot;
}
SIEHE AUCH
----------
- :doc:`../props/P_DEFEND_FUNC`, :doc:`QueryDefendd`
+ :doc:`../props/P_DEFEND_FUNC`, :doc:`QueryDefend`
/std/armour/combat.c
diff --git a/doc/sphinx/lfun/QueryArmourByType.rst b/doc/sphinx/lfun/QueryArmourByType.rst
index 17e6967..c3a126d 100644
--- a/doc/sphinx/lfun/QueryArmourByType.rst
+++ b/doc/sphinx/lfun/QueryArmourByType.rst
@@ -9,7 +9,7 @@
--------
::
- mixed QueryArmourByType(string type)
+ object|object*|mapping QueryArmourByType(string type)
DEFINIERT IN
------------
@@ -30,17 +30,28 @@
Abfrage, ob das Lebewesen eine Ruestung des angegebenen Typs traegt.
- Zurueckgegeben wird je nach Tragestatus und <type>:
- * 0, falls das Lebewesen die gesuchte Ruestungsart nicht traegt
- * im Erfolgsfall das Ruestungsobjekt
- * falls <type> AT_MISC ist:
- * ({}), wenn es keine AT_MISC-Ruestung traegt
- * ein Array von AT_MISC-Ruestungen
- * falls <type> 0 ist: ein Mapping, das diese Informationen mit dem
- Ruestungstypen als Schluessel enthaelt:
- ([AT_MISC: ({[object], ...}),
- AT_...: <object>,
- ... ])
+
+RUECKGABEWERTE
+--------------
+::
+
+ Zurueckgegeben wird abhaengig vom Argument <type> folgendes:
+
+ 1) Ist <type> ein Typ, von dem man nur eine Ruestung tragen kann:
+ * 0, falls das Lebewesen die gesuchte Ruestungsart nicht traegt,
+ * ansonsten das Ruestungsobjekt
+
+ 2) Ist <type> AT_MISC:
+ * ein Array mit allen AT_MISC-Ruestungen
+ * ({}), wenn das Lebewesen keine AT_MISC-Ruestung traegt
+
+ 3) Ist <type> 0:
+ * Ein Mapping mit den Ruestungstypen als Schluessel der folgenden
+ Form:
+ ([AT_MISC: ({object misc1, ... }),
+ AT_CLOAK: object cloak,
+ AT_...: object ...,
+ ... ])
BEMERKUNG
---------
diff --git a/doc/sphinx/lfun/create_default_npc.rst b/doc/sphinx/lfun/create_default_npc.rst
index 8507388..999fee2 100644
--- a/doc/sphinx/lfun/create_default_npc.rst
+++ b/doc/sphinx/lfun/create_default_npc.rst
@@ -46,7 +46,10 @@
wurden, werden durch die neuen Werte ersetzt.
Ab einem Aufruf mit Level 20 werden P_XP = 202000 gesetzt, also ein
- Kill-Stup vergeben (siehe P_XP).
+ Kill-Stups vergeben (siehe P_XP).
+
+ P_HP und P_SP werden auf dieselben Werte wie P_MAX_HP bzw. P_MAX_SP
+ eingestellt.
BEISPIEL
--------
diff --git a/doc/sphinx/props/P_MAGIC_RESISTANCE_OFFSET.rst b/doc/sphinx/props/P_MAGIC_RESISTANCE_OFFSET.rst
index a1be37e..d87ec69 100644
--- a/doc/sphinx/props/P_MAGIC_RESISTANCE_OFFSET.rst
+++ b/doc/sphinx/props/P_MAGIC_RESISTANCE_OFFSET.rst
@@ -36,7 +36,7 @@
// Goblins
SetProp(P_MAGIC_RESISTANCE_OFFSET,
([MT_ANGRIFF:600, // 6% Resistenz gegen Angriff
- MT_ILLUSION:500, // 6% Resistenz gegen Illusionen
+ MT_ILLUSION:500, // 5% Resistenz gegen Illusionen
MT_VERWANDLUNG:-300, // 3% Empfindlichkeit
MT_HELLSICHT:-750, // 7.5% Empfindlichkeit
MT_BEHERRSCHUNG:250])); // 2.5% Resistenz
diff --git a/doc/sphinx/props/P_MAX_HP.rst b/doc/sphinx/props/P_MAX_HP.rst
index 3e23b46..ce7049f 100644
--- a/doc/sphinx/props/P_MAX_HP.rst
+++ b/doc/sphinx/props/P_MAX_HP.rst
@@ -19,6 +19,13 @@
Maximale Anzahl der Lebenspunkte.
+HINWEIS
+-------
+::
+
+ Beim Setzen der Property wird gleichzeitig P_HP auf denselben Wert
+ gesetzt.
+
SIEHE AUCH
----------
::
diff --git a/doc/sphinx/props/P_MAX_SP.rst b/doc/sphinx/props/P_MAX_SP.rst
index 2269cd2..57ef762 100644
--- a/doc/sphinx/props/P_MAX_SP.rst
+++ b/doc/sphinx/props/P_MAX_SP.rst
@@ -19,6 +19,13 @@
Maximale Anzahl der Magiepunkte.
+HINWEIS
+-------
+::
+
+ Beim Setzen der Property wird gleichzeitig P_SP auf denselben Wert
+ gesetzt.
+
SIEHE AUCH
----------
::
diff --git a/doc/sphinx/sefun/replace_personal.rst b/doc/sphinx/sefun/replace_personal.rst
index ff7c07f..e799ddb 100644
--- a/doc/sphinx/sefun/replace_personal.rst
+++ b/doc/sphinx/sefun/replace_personal.rst
@@ -46,8 +46,6 @@
x steht fuer die Position des Objekts/Strings in *obs, beginnend bei 1.
-
-
Besonderheiten beim Possessivpronomen (@WERQPPGNx):
G muss durch das Geschlecht (M, F oder N) und N durch den Numerus (S
oder P) ersetzt werden.
@@ -66,27 +64,19 @@
Beispiele
-
- replace_personal("@WER1", ({find_player("gloinson")}))
- == "Gloinson"
------------------------------------------------------------------------------------------
+---------
::
+ replace_personal("@WER1", ({find_player("gloinson")})) ==> "Gloinson"
-
- replace_personal("@WEMQP1", ({find_player("gloinson")}))
- == "ihm"
-
-
+ replace_personal("@WEMQP1", ({find_player("gloinson")})) ==> "ihm"
// unbestimmter und bestimmter Artikel:
replace_personal("@WER1 zueckt @WENU2 und verhaut @WEN3.",
({find_player("gloinson"),
find_object("/obj/mpa"),
find_object("/obj/wanderer")}))
- == "Gloinson zueckt eine Zeitung und verhaut den Wanderer."
-
-
+ ==> "Gloinson zueckt eine Zeitung und verhaut den Wanderer."
// Beim Possessivpronomen beziehen sich WEN, F und P (Akkusativ,
// Femininum, Plural) auf die Taschen, nicht auf Kessa:
@@ -94,7 +84,7 @@
"Taschen.",
({find_player("kessa"),
find_player("gloinson")}))
- == "Kessa steckt Gloinsons Turnschuhe in ihre Taschen."
+ ==> "Kessa steckt Gloinsons Turnschuhe in ihre Taschen."
// Ein Beispiel mit laengerem *obs:
replace_personal("@WER1 zieht @WENQPPMP1 neuen Turnschuhe an. @WER2 ist "
@@ -108,10 +98,10 @@
"Birne",
find_object("/obj/wanderer"),
find_netdead("jof")}),1)
- == "Gloinson zieht seine neuen Turnschuhe an. Kessa ist so beeindruckt, "
- "dass sie ihm eine Zeitung auf die Birne haut und die Schuhe in ihrer "
- "Tasche verschwinden laesst. Ein Wanderer schaut zu und kichert "
- "irre. Wenn das Jof gesehen haette!"
+ ==> "Gloinson zieht seine neuen Turnschuhe an. Kessa ist so "
+ "beeindruckt, dass sie ihm eine Zeitung auf die Birne haut und die "
+ "Schuhe in ihrer Tasche verschwinden laesst. Ein Wanderer schaut "
+ "zu und kichert irre. Wenn das Jof gesehen haette!"
SIEHE AUCH
----------
diff --git a/doc/sphinx/sefun/set_light.rst b/doc/sphinx/sefun/set_light.rst
deleted file mode 100644
index 99d5bee..0000000
--- a/doc/sphinx/sefun/set_light.rst
+++ /dev/null
@@ -1,32 +0,0 @@
-set_light()
-===========
-
-SYNOPSIS
---------
-::
-
- int set_light(int n)
-
-DESCRIPTION
------------
-::
-
- An object is by default dark. It can be set to not dark by
- calling set_light(1). The environment will then also get this
- light. The returned value is the total number of lights in
- this room. So if you call set_light(0) it will return the
- light level of the current object.
-
-
-
- Note that the value of the argument is added to the light of
- the current object.
-
-BUGS
-----
-::
-
- This handling of light by the parser is inappropriate for most
- purposes: If you put a burning candle into a safe, the safe
- will start to emit light.
-
diff --git a/doc/wiz/regionsleitfaden b/doc/wiz/regionsleitfaden
index 70e491a..45e85f5 100644
--- a/doc/wiz/regionsleitfaden
+++ b/doc/wiz/regionsleitfaden
@@ -44,7 +44,9 @@
Dateien aus den Verzeichnissen.
o Speicherung von Daten in secure-Verzeichnissen soll bitte nur sehr
- sparsam erfolgen und nur in Abstimmung mit dem RM.
+ sparsam erfolgen und nur in Abstimmung mit dem RM. Denkt dabei daran,
+ dass Secure-Verzeichnisse im Zusammenspiel mit Git/Gerrit zusaetzliche
+ Probleme aufwerfen.
o save_object() bitte sehr sparsam verwenden (nicht bei jeder Daten-
aenderung, bei Bedarf in reset/remove).
diff --git a/doc/wiz/rm-howto b/doc/wiz/rm-howto
index 63c9a84..a722c8c 100644
--- a/doc/wiz/rm-howto
+++ b/doc/wiz/rm-howto
@@ -4,10 +4,11 @@
Vorlaeufiges Inhaltsverzeichnis:
1) Allgemeines
+ - Konzepte fuer neue Gebiete
- Fehlerteufel
- - Logtool
- Kommentierung von Aenderungen
- eigene Anschluesse
+ - "Datenhygiene" im Regionsverzeichnis
2) Abnahme von Code/Gebieten
- Balance/Genehmigungen
- Konzeptionelle Eignung
@@ -32,67 +33,116 @@
1) Allgemeines
==============
-o Um stets einen Ueberblick ueber die in Deiner Region (hoffentlich selten)
- auftretenden Bugs und Warnungen zu behalten, solltest Du einen
- Fehlerteufel (/obj/tools/fehlerteufel.c) besitzen, bedienen koennen und
- regelmaessig dessen Listen durchsehen. Deinen Regionsmitarbeitern solltest
- Du, allein schon, um zusaetzliche Arbeit fuer Dich selbst zu reduzieren,
- dieses Werkzeug ebenfalls an die Hand geben und sie auffordern, ihren
- Kram moeglichst umfassend selbst zu reparieren.
- Neuen Magiern wird dieses Tool uebrigens automatisch von Merlin in die
- Hand gedrueckt, so dass sie sich vom ersten Tag an daran gewoehnen koennen.
+1a) Konzepte und Dokumentation
-o Es ist empfehlenswert, das Logtool zu besitzen (/obj/tools/logtool.c) und
- in diesem fuer jedes Repfile eines Regionsmitarbeiters einen Eintrag vor-
- zusehen. Warum das? Es ist bereits vorgekommen, dass Spieler ernsthaft
- argumentiert haben, sie duerften einen von ihnen entdeckten Bug ausnutzen,
- weil sie ihn ja gemeldet haetten (im Repfile!), er aber nicht repariert
- worden sei (was nicht verwundert, da er im Repfile in der Mehrzahl der
- Faelle weit unterhalb des Wahrnehmungshorizonts der allermeisten
- Regionsmagier schwebt).
+ o Die Erfahrung zeigt, dass es aus verschiedenen Gruenden wirklich dringend
+ zu empfehlen ist, sich fuer neue Gebiete ein Konzept vorlegen zu lassen,
+ dieses gruendlich zu pruefen und zu durchdenken und mit dem betreffenden
+ Regionsmitarbeiter zu diskutieren. Weiterhin empfiehlt es sich ebenfalls,
+ eine ueber das Konzept erzielte Einigung im Verzeichnis "doc" Deiner
+ Region zu dokumentieren. Hierdurch erreichst Du mehrere Dinge:
+ - Du vermeidest Ueberraschungen ("Hier ist mein neues Gebiet zur Abnahme,
+ sind nur 120 Raeume. Oh, hoppla, hab ich Dir nicht Bescheid gesagt?");
+ auch fuer Deine etwaigen Nachfolger.
+ - Du vermeidest bei absehbaren technischen Schwierigkeiten Frustration
+ beim Deinem Regionsmitarbeiter.
+ - Du erhoehst die Wahrscheinlichkeit, dass das Gebiet tatsaechlich
+ fertiggestellt wird.
+ - Jeder kann weitgehend verbindlich nachlesen, was Du genehmigt hast.
+ - Es ist klar ersichtlich, welche Konzepte bekanntermassen schon in Arbeit
+ sind, so dass inhaltliche Aehnlichkeiten im Vorfeld vermieden werden
+ koennen.
+
+ Du solltest den betreffenden Regionsmitarbeiter auch darauf hinweisen,
+ dass er Dich informieren moege, wenn er eine groessere konzeptionelle
+ Umstellung des neuen Gebietes durchfuehren will.
-o Wenn Du in fremdem Code Aenderungen vornehmen musst, die mehr beruehren
- als nur ein paar Tippfehler in Details oder Infos, dann kommentiere den
- defekten Code aus und fuege den reparierten mit Kommentar ein. Es reicht
- an dieser Stelle aus, Deinen Namen und das Datum zu vermerken. In den
- Header der Datei solltest Du unbedingt ein Changelog einfuegen, in dem
- das Datum der Aenderung, der Name des Ausfuehrenden (Deiner) sowie die
- vorgenommene Aenderung mit Begruendung bzw. u.U. Bug-ID aus dem Fehler-
- teufel einzutragen ist. Wir haben im MG leider keinen wirkungsvollen
- Debugger und Bugtracker-Mechanismus, so dass wir zur Erhaltung einer
- gewissen Code-Hygiene Bugfixes mit Hilfe solcher Eintragungen dokumentieren
- und rueckverfolgen muessen. Insbesondere ist ein solcher Eintrag wichtig,
- um im Falle von Folge-Bugs die Ursache schneller zu finden.
+ Welche Kriterien man als RM ansetzt, um ein Gebiet als regionstauglich
+ zu bewerten, liegt in der Entscheidung des RM.
-o Willst Du in Deiner eigenen Region ein Gebiet anschliessen, solltest Du
- diesen vor Anschluss entweder vom Co-RM oder von einem RM einer anderen
- Region lesen lassen. Auch wenn Du ein guter Programmierer bist, findet ein
- zweites Paar Augen oft Dinge, an die man nicht gedacht hat.
+ o Wenn ein Konzept fuer ein Gesellenstueck eingereicht wird, und es handelt
+ sich um eine Gemeinschaftsarbeit mehrerer Magier (Kooperation mehrerer
+ Lehrlinge oder Lehrling(e) + erfahrene Magier), UEBERLEGT EUCH GUT, OB
+ IHR DAS ZULASSEN WOLLT! Erfahrungsgemaess laesst sich schwer beurteilen,
+ welcher Teil des Codes von wem ist. Wenn es zugelassen wird, sollten mit
+ den betreffenden Lehrlingen klare Vereinbarungen insbesondere ueber die
+ Trennung des Codes nach Autor getroffen werden.
+1b) Fehlerteufel / Abarbeitung von Bugs
+
+ o Um stets einen Ueberblick ueber die in Deiner Region (hoffentlich selten)
+ auftretenden Bugs und Warnungen zu behalten, solltest Du einen
+ Fehlerteufel (/obj/tools/fehlerteufel.c) besitzen, bedienen koennen und
+ regelmaessig dessen Listen durchsehen. Deinen Regionsmitarbeitern solltest
+ Du, allein schon, um zusaetzliche Arbeit fuer Dich selbst zu reduzieren,
+ dieses Werkzeug ebenfalls an die Hand geben und sie auffordern, ihren
+ Kram moeglichst umfassend selbst zu reparieren.
+ Neuen Magiern wird dieses Tool uebrigens automatisch von Merlin in die
+ Hand gedrueckt, so dass sie sich vom ersten Tag an daran gewoehnen
+ koennen.
+
+ o Wenn Du in fremdem Code Aenderungen vornehmen musst, die mehr beruehren
+ als nur ein paar Tippfehler in Details oder Infos, dann fuege den
+ reparierten Code mit Kommentar ein. Wenn in Deiner Region git/gerrit zur
+ Codeverwaltung verwendet werden, schreibe eine aussagekraeftige Commit-
+ Message, bei Bedarf ergaenzt durch einen Kommentar im Code.
+
+1c) Anschluss eigener Gebiete in der eigenen Region
+
+ o Willst Du in Deiner eigenen Region ein Gebiet anschliessen, solltest Du
+ diesen vor Anschluss entweder vom Co-RM oder von einem RM einer anderen
+ Region lesen lassen. Auch wenn Du ein guter Programmierer bist, findet ein
+ zweites Paar Augen oft Dinge, an die man nicht gedacht hat.
+
+1d) "Hygiene" in den Regionsverzeichnissen
+
+ o Wenn Du nicht angeschlossene Objekte aus Deiner Region aussortieren
+ moechtest, ist sprich am besten einen EM an, der Dir dabei hilft:
+ Einerseits kann man auf der Shell bequemer herausfinden, ob ein Objekt
+ tatsaechlich nicht verwendet wird. Andererseits soll der ungenutzte
+ Code in das /players-Verzeichnis des Autors verschoben werden, was
+ haeufig ebenfalls EM-Rechte benoetigt.
+
+ o Es wird dringend empfohlen, neuen Regionscode nur noch in /players zu
+ entwickeln.
+
+ o Als Regionsmagier hast Du aufgrund eines EM-Beschlusses die Moeglichkeit,
+ fuer Deine jeweilige(n) Region(en) verbindlich festzulegen, ob es erlaubt
+ ist, die Entwicklung neuer Gebiete im Regionsverzeichnis durchzufuehren.
+
2) Code wird zur Abnahme vorgelegt
==================================
-o Bei Waffen und Ruestungen unbedingt auf Einhaltung der Balance-Vorgaben
- achten.
+o Bei Waffen und Ruestungen unbedingt darauf achten, dass Objekte, die die
+ Genehmigungsgrenzen ueberschreiten, bei der Balance zur Genehmigung
+ vorgestellt wurden. Fuer alle Objekte mit Balance-relevanten Eigenschaften
+ bitte penibel darauf achten, dass die Balance-Vorgaben eingehalten werden.
+ Jeder Magier kann sich ein Balance-Tool "light" clonen, mit dem er den Text
+ der Genehmigung selbst anschauen kann, um den vorgelegten Code damit zu
+ vergleichen. Nicht genehmigte oder in der Funktion abweichende Objekte
+ duerfen nicht angeschlossen werden. (Bei schon sehr lange angeschlossenen
+ Objekten, deren Abweichung von der Genehmigung erst sehr spaet auffaellt,
+ kann man ggf. auf das temporaere Abhaengen verzichten.)
o Sofern ein Objekt eine Balance-Genehmigung besitzt, muss die BTOP-Nummer,
die die Balance als eindeutige ID fuer jeden Antrag vergibt, im Header
- des betreffenden Objektes erkennbar eingetragen sein.
+ des betreffenden Objektes erkennbar eingetragen sein. Bevorzugt traegt
+ man auch die genehmigten Eigenschaften ein.
-o Vor Anschluss sollte man Ruecksprache mit verschiedenen Instanzen halten,
- um sicherzustellen, dass der Magier alle wesentlichen Punkte
- beruecksichtigt hat:
- - liegen alle Balance-Genehmigungen vor?
- - sind die FP eingetragen?
- - sind die ZTs eingetragen und getestet?
- - sind Sonder-EK-Stupse genehmigt und eingetragen?
-
-o Fuer neue Gebiete ist eine grundsaetzliche Pruefung des Konzepts auf
- Regionstauglichkeit sinnvoll, damit nicht alteingesessene Institutionen
- oder Orte ploetzlich zur zweiten Wahl abgewertet werden - beispielsweise
- einen grossen, neuen Hauptort in der Ebene anzuschliessen, der Port Vain
- voraussehbar den Rang ablaufen wuerde.
+o Vor Anschluss sollte man kontrollieren, dass der Magier alle wesentlichen
+ Punkte beruecksichtigt hat:
+ - Liegen alle Balance-Genehmigungen vor?
+ BTool light gibt's fuer alle, damit kann jeder fuer Objekte in seinem
+ Zustaendigkeitsbereich die Genehmigungen einsehen.
+ - Sind die FP eingetragen?
+ FP kann der RM fuer das neue Gebiet selbst abfragen.
+ - Sind die ZTs eingetragen und getestet?
+ Dies laesst sich mit dem Magierkommando "traenke" herausfinden.
+ - Falls Sonder-EK-Stupse vorgesehen sind: sind diese genehmigt?
+ Die Eintragung bzw. Anpassung der Stufenpunkte fuer den Kill wird
+ erledigt, sobald der NPC das erste Mal getoetet wurde, dies muss also nicht
+ ueberprueft werden.
o Alle NPCs sollten vor Anschluss einmal gekillt werden, um sie auf
grundsaetzliche Kampf-Funktionsfaehigkeit zu pruefen.
@@ -104,24 +154,26 @@
Formfehler in einem kompletten Verzeichnis ermitteln kann (Umlaute im
Code, zu lange Zeilen etc.), wobei bezueglich der Formalien auch auf
den Regionsmitarbeiter-Leitfaden fuer neue Projekte verwiesen werden
- soll. Das Skript hierzu ist auf Anfrage bei Zesstra erhaeltlich. Der
- Regionsmagier hat hierbei die Entscheidungsfreiheit, die Berichte dieses
- Skripts dem Programmierer des neuen Gebiets als Anhaltspunkte zur
- Verfuegung zu stellen, oder die Abarbeitung der gemeldeten Punkte als
- Voraussetzung vor dem Anschluss vorzuschreiben, aber auch jede Abstufung
- dazwischen ist OK. :-)
+ soll. Das Skript liegt im oeffentlichen Git-Repo "static-lpc-check" auf
+ dem MG-Gerrit-Server. Man kann es mit git oder ueber das Webinterface
+ herunterladen. Der Regionsmagier hat hierbei die Entscheidungsfreiheit,
+ die Berichte dieses Skripts dem Programmierer des neuen Gebiets als
+ Anhaltspunkte zur Verfuegung zu stellen, oder die Abarbeitung der
+ gemeldeten Punkte zur Voraussetzung fuer den Anschluss zu machen, aber
+ auch jede Abstufung dazwischen ist OK. :-)
Zusaetzlicher Tip: Das Skript differenziert zwischen eigentlich nicht
akzeptablen Konstrukten und zumindest fragwuerdigen, d.h. man kann diese
Unterscheidung an den Verantwortlichen mit entsprechenden Forderungen
weitergeben.
- Das Skript ist unter ftp://mg.mud.de/Software/src_check/ erhaeltlich.
-o Sollte ein zur Abnahme anstehendes Projekt eine (grundsaetzlich
+o Sollte ein zur Abnahme anstehendes Gesellenstueck eine (grundsaetzlich
selbstverstaendlich zulaessige) Gemeinschaftsarbeit sein, sollte man
- als Regionsmagier darauf bestehen, eine sauber getrennte Codebasis
- in unterschiedlichen Verzeichnissen vorgelegt zu bekommen, oder aber
- eine Auflistung, welcher Beitrag von welchem Magier stammt.
- Wenn diese Auflistung sich bis auf Funktionsebene erstrecken sollte
+ darauf bestehen, eine sauber getrennte Codebasis in unterschiedlichen
+ Verzeichnissen vorgelegt zu bekommen, oder aber eine Auflistung, welcher
+ Beitrag von welchem Magier stammt. Es sollte klar sein, dass die
+ Beurteilung der Faehigkeiten eines Lehrlings darauf angewiesen ist, dass
+ man den Code richtig zuordnen kann.
+ Wenn eine solche Auflistung sich bis auf Funktionsebene erstreckt
(z.B. "DoWield() ist von X, Details von Y, DefendFunc von Z"), ist
das unschoen und an sich abzulehnen.
@@ -215,7 +267,7 @@
{
pl = find_player(lower_case(name1));
if (!pl || !living(pl))
- return 1;
+ return;
else
Kill(pl);
}
@@ -296,13 +348,10 @@
o for()-Schleifen
Eigentlich keine Funktion, aber an dieser Stelle doch passend:
for()-Schleifen sollten generell durch foreach()-Konstruktionen ersetzt
- werden, da dies signifikant und messbar schneller ist. Die naechst-
- schnellere Variante waere etwa folgendes, sofern die Reihenfolge der
- Abarbeitung unerheblich ist (i ist integer, arr ist ein mixed-Array):
-
- for ( i=sizeof(arr); i--; ) {
- tu_etwas_mit(arr[i]);
- }
+ werden, da dies signifikant und messbar schneller ist. Der groesste
+ Zeit- und Kostenfaktor ist die Verwendung von sizeof() als Abbruchkriterium
+ in einer for()-Schleife. Wenn sich die Schleife also nicht ersetzen laesst,
+ dann nehmt zumindest einen konstanten Wert als Abbruchkriterium.
o write_file()
Benutzung dieser Funktion nur in begruendeten Ausnahmefaellen abnehmen, da
@@ -311,6 +360,10 @@
verbrauchen, aber kaum zu ueberschauen sind. Statt write_file() wird in
den allermeisten Faellen log_file() mit der Standardgroesse von 50 kB fuer
Logfile und eine ggf. vorhandene Altversion (*.OLD) ausreichend sein.
+ Standardmaessig ist das Schreiben eines Questlog-Eintrages in /log/quest
+ der einzige Einsatzzweck, wo write_file() wirklich notwendig ist.
+ Ansonsten sind Ausnahmen vorstellbar, wenn die neuen Daten die alte Datei
+ komplett ersetzen, d.h. nicht angehaengt werden.
o Verwalten von charakterbezogenen Daten
Als Beispiel seien hier Statusdaten fuer den Ablauf von Quests genannt,