Doku-Update
Commit auto-erzeugter Dateien.
Change-Id: I26a870d8c6f82a3648df52621dba6def25897e4b
diff --git a/doc/lfun-liste b/doc/lfun-liste
index 5aa5b31..cbed681 100644
--- a/doc/lfun-liste
+++ b/doc/lfun-liste
@@ -80,7 +80,7 @@
* AddTouchDetail()
-* AddvItem()
+* AddVItem()
* AllGroups()
diff --git a/doc/lfun/AddItem b/doc/lfun/AddItem
index 222b24d..97bd0a8 100644
--- a/doc/lfun/AddItem
+++ b/doc/lfun/AddItem
@@ -33,6 +33,8 @@
- REFRESH_ALWAYS - Neuer Clone bei jedem Reset.
- REFRESH_MOVE_HOME - Objekt wird bei Reset automatisch
zurueckgeholt, wenn es wegbewegt wurde.
+ Wurde das Objekt zerstoert, wird es automatisch neu
+ erzeugt, wie bei REFRESH_DESTRUCT.
(nur in Raeumen!)
Bei NPC's gilt zusaetzlich:
- CLONE_WEAR - Item Anziehen, wenn es eine Ruestung ist.
@@ -56,84 +58,85 @@
BESCHREIBUNG
============
- Abhaengig von <filename> und <props> wird ein Objekt erzeugt und in
- den Raum bzw. NPC bewegt. Dabei gibt es folgende Moeglichkeiten:
- - <filename> ist ein Dateiname.
- Es wird ein Clone dieser Datei erstellt oder (wenn <props>=1 ist)
- deren Blueprint verwendet.
- - <filename> ist ein Array von Dateinamen.
- Es wird eine Datei zufaellig aus dem Array ausgewaehlt und von
- dieser Datei ein Clone erstellt oder (wenn <props>=1 ist) deren
- Blueprint verwendet.
- Uebergibt man fuer <props> ein Mapping mit dem Aufbau
- ([prop_name:prop_wert,...]),
- so werden diese Properties im erzeugten Objekt gesetzt.
- Der Parameter <refresh> gibt an, was waehrend eines Resets im Raum
- bzw. in NPC's oder was beim Erzeugen von NPC's geschehen soll:
- In <rooms.h> sind dazu folgende Moeglichkeiten definiert:
- - REFRESH_NONE
- Das Objekt wird niemals erneuert; falls es zerstoert wurde, wird
- es erst dann wieder erzeugt, wenn der Raum erneut geladen bzw.
- der NPC neu erzeugt wird. Man beachte, dass nicht jeder NPC
- wirklich refreshende Objekte benoetigt, REFRESH_NONE spart
- hierbei sowohl Rechenzeit als auch Speicher!
- - REFRESH_DESTRUCT
- Das Objekt wird nur dann erneuert, wenn es in der Zwischenzeit
- zerstoert wurde (bei NPC's ist das zum Beispiel der Fall, wenn
- sie getoetet wurden).
- REFRESH_NONE & REFRESH_DESTRUCT + Blueprint-Objekt bedeutet bei
- NPC's ein Unique-Objekt, es wird also nicht beim Neuerzeugen des
- NPC's zurueckgesetzt.
- - REFRESH_REMOVE
- Das Objekt wird erneuert, wenn es sich nicht mehr im Raum bzw.
- im NPC befindet. Das kein sein, weil es zerstoert wurde, aber
- auch zum Beispiel in folgenden Faellen:
- * weil es jemand mitgenommen hat
- (in Raeumen bei Gegenstaenden)
- * weil es fortgegangen ist
- (in Raeumen bei NPC's, die herumlaufen)
- * weil es weggeworfen wurde
- (in NPC's bei Gegenstaenden)
- - REFRESH_ALWAYS
- Das Objekt wird immer erneuert. Von dieser Refreshmethode sollte
- man allerdings Abstand nehmen, da sich sonst mit der Zeit
- gewaltige Mengen von Objekten ansammeln koennen!
- - REFRESH_MOVE_HOME
- Das Objekt wird in einen Raum zurueckbewegt, sofern es noch
- existiert, jedoch nicht mehr in dem Raum ist. Sinnvoll ist dies
- eigentlich nur fuer Lebewesen, funktioniert aber auch bei
- beliebigen Objekten. Hauptsaechlich geht es hierbei darum,
- herumlaufende NPCs oder bei erzwungenen Bewegungen nicht von
- P_GUARD zurueckgehaltene NPCs wieder an einen definierten
- Ausgangsort zurueckzubringen.
- Hat man in Raeumen als <filename> ein Array von Dateinamen
- uebergeben, so wird beim Reset jedesmal aufs Neue ein zufaelliges
- Objekt aus der Liste ausgewaehlt (nicht in NPC's).
- In NPC's gilt der Grundsatz der Vermeidung von ueberfluessigen
- Objekten im MUD. Neu erzeugt werden Objekte beim Erzeugen eines
- NPC's oder bei einem Reset im selbigen. Anstatt die Objekte gleich
- neu zu erschaffen, wird erst geschaut, ob sich identische Objekte
- schon im Raum befinden. Ist dies der Fall, so nimmt der NPC sie auf,
- ruft jedoch vorher nochmals create() in ihnen auf!
- (noetig wegen moeglicher Veraenderungen an den Objekten)
- Was dann passiert, haengt von weiteren Angaben in <refresh> ab.
- Folgende weitere Moeglichkeiten sind in <npc.h> definiert:
- - CLONE_WEAR
- Ist das hinzugefuegte Item eine Ruestung, so wird sie nach
- Aufnahme oder Neuerzeugung angezogen.
- - CLONE_WIELD
- Ist das hinzugefuegte Item eine Waffe, so wird sie nach Aufnahme
- oder Neuerzeugung gezueckt.
- - CLONE_NO_CHECK
- Hiermit verhindert man eine Ueberpruefung, ob eine Ruestung
- angezogen oder eine Waffe gezueckt werden kann. Es ist jedoch
- Vorsicht geboten: So kann es ohne weiteres passieren, dass ein NPC
- mehrere Ruestungen gleichen Typs angezogen oder mehrere Waffen
- gezueckt hat.
- Benutzt man Blueprints (<props>=1) mit REFRESH_REMOVE oder
- REFRESH_ALWAYS, so kann es zu ungewollten Ueberraschungen kommen, da
- die Blueprint dann unabhaengig von ihrem momentanen Aufenthaltsort
- wieder in den Raum bzw. NPC bewegt wird, von dem sie erzeugt wurde!
+ Abhaengig von <filename> und <props> wird ein Objekt erzeugt und in
+ den Raum bzw. NPC bewegt. Dabei gibt es folgende Moeglichkeiten:
+ - <filename> ist ein Dateiname.
+ Es wird ein Clone dieser Datei erstellt oder (wenn <props>=1 ist)
+ deren Blueprint verwendet.
+ - <filename> ist ein Array von Dateinamen.
+ Es wird eine Datei zufaellig aus dem Array ausgewaehlt und von
+ dieser Datei ein Clone erstellt oder (wenn <props>=1 ist) deren
+ Blueprint verwendet.
+ Uebergibt man fuer <props> ein Mapping mit dem Aufbau
+ ([prop_name:prop_wert,...]),
+ so werden diese Properties im erzeugten Objekt gesetzt.
+ Der Parameter <refresh> gibt an, was waehrend eines Resets im Raum
+ bzw. in NPC's oder was beim Erzeugen von NPC's geschehen soll:
+ In <rooms.h> sind dazu folgende Moeglichkeiten definiert:
+ - REFRESH_NONE
+ Das Objekt wird niemals erneuert; falls es zerstoert wurde, wird
+ es erst dann wieder erzeugt, wenn der Raum erneut geladen bzw.
+ der NPC neu erzeugt wird. Man beachte, dass nicht jeder NPC
+ wirklich refreshende Objekte benoetigt, REFRESH_NONE spart
+ hierbei sowohl Rechenzeit als auch Speicher!
+ - REFRESH_DESTRUCT
+ Das Objekt wird nur dann erneuert, wenn es in der Zwischenzeit
+ zerstoert wurde (bei NPC's ist das zum Beispiel der Fall, wenn
+ sie getoetet wurden).
+ REFRESH_NONE & REFRESH_DESTRUCT + Blueprint-Objekt bedeutet bei
+ NPC's ein Unique-Objekt, es wird also nicht beim Neuerzeugen des
+ NPC's zurueckgesetzt.
+ - REFRESH_REMOVE
+ Das Objekt wird erneuert, wenn es sich nicht mehr im Raum bzw.
+ im NPC befindet. Das kein sein, weil es zerstoert wurde, aber
+ auch zum Beispiel in folgenden Faellen:
+ * weil es jemand mitgenommen hat
+ (in Raeumen bei Gegenstaenden)
+ * weil es fortgegangen ist
+ (in Raeumen bei NPC's, die herumlaufen)
+ * weil es weggeworfen wurde
+ (in NPC's bei Gegenstaenden)
+ - REFRESH_ALWAYS
+ Das Objekt wird immer erneuert. Von dieser Refreshmethode sollte
+ man allerdings Abstand nehmen, da sich sonst mit der Zeit
+ gewaltige Mengen von Objekten ansammeln koennen!
+ - REFRESH_MOVE_HOME
+ Das Objekt wird in einen Raum zurueckbewegt, sofern es noch
+ existiert, jedoch nicht mehr in dem Raum ist. Sinnvoll ist dies
+ eigentlich nur fuer Lebewesen, funktioniert aber auch bei
+ beliebigen Objekten. Hauptsaechlich geht es hierbei darum,
+ herumlaufende NPCs oder bei erzwungenen Bewegungen nicht von
+ P_GUARD zurueckgehaltene NPCs wieder an einen definierten
+ Ausgangsort zurueckzubringen.
+ Wurde das Objekt zerstoert, wird es neu erzeugt.
+ Hat man in Raeumen als <filename> ein Array von Dateinamen
+ uebergeben, so wird beim Reset jedesmal aufs Neue ein zufaelliges
+ Objekt aus der Liste ausgewaehlt (nicht in NPC's).
+ In NPC's gilt der Grundsatz der Vermeidung von ueberfluessigen
+ Objekten im MUD. Neu erzeugt werden Objekte beim Erzeugen eines
+ NPC's oder bei einem Reset im selbigen. Anstatt die Objekte gleich
+ neu zu erschaffen, wird erst geschaut, ob sich identische Objekte
+ schon im Raum befinden. Ist dies der Fall, so nimmt der NPC sie auf,
+ ruft jedoch vorher nochmals create() in ihnen auf!
+ (noetig wegen moeglicher Veraenderungen an den Objekten)
+ Was dann passiert, haengt von weiteren Angaben in <refresh> ab.
+ Folgende weitere Moeglichkeiten sind in <npc.h> definiert:
+ - CLONE_WEAR
+ Ist das hinzugefuegte Item eine Ruestung, so wird sie nach
+ Aufnahme oder Neuerzeugung angezogen.
+ - CLONE_WIELD
+ Ist das hinzugefuegte Item eine Waffe, so wird sie nach Aufnahme
+ oder Neuerzeugung gezueckt.
+ - CLONE_NO_CHECK
+ Hiermit verhindert man eine Ueberpruefung, ob eine Ruestung
+ angezogen oder eine Waffe gezueckt werden kann. Es ist jedoch
+ Vorsicht geboten: So kann es ohne weiteres passieren, dass ein NPC
+ mehrere Ruestungen gleichen Typs angezogen oder mehrere Waffen
+ gezueckt hat.
+ Benutzt man Blueprints (<props>=1) mit REFRESH_REMOVE oder
+ REFRESH_ALWAYS, so kann es zu ungewollten Ueberraschungen kommen, da
+ die Blueprint dann unabhaengig von ihrem momentanen Aufenthaltsort
+ wieder in den Raum bzw. NPC bewegt wird, von dem sie erzeugt wurde!
BEMERKUNGEN
@@ -141,7 +144,6 @@
Wenn man Blueprints benutzt, sollte man daran denken, dass sich von
dieser dann keine Clones mehr erstellen lassen!
- RemoveItem() zum Entfernen von Items ist nur fuer Raeume definiert!
Die Option CLONE_NEW ist veraltet. Die Objekte werden nun immer
neu erzeugt. Die Option darf noch angegeben werden, hat aber keine
diff --git a/doc/lfun/AddVItem b/doc/lfun/AddVItem
index 0b48656..af42f22 100644
--- a/doc/lfun/AddVItem
+++ b/doc/lfun/AddVItem
@@ -1,5 +1,5 @@
-AddvItem()
+AddVItem()
**********
@@ -21,8 +21,7 @@
key
Eindeutige Bezeichnung des vItems und mit dieser wieder
- loeschbar. Das vItem wird im Raum auch unter dieser ID
- ansprechbar sein.
+ loeschbar. Das vItem bekommt dies u.U. auch als ID (s.u.)
refresh
Refresheinstellungen des vItems, nachdem es mitgenommen wurde
@@ -60,6 +59,10 @@
<props> angegebenen Properties in ihm gesetzt. Auf diese Weise kann
man das genommene Objekt noch individuell konfigurieren.
+ Werden fuer ein reines vItem ohne Vorlage keine P_IDS in
+ <shadowprops> angegeben, so bekommt das vItem den string <key> als
+ ID, damit es irgendwie im Raum ansprechbar ist.
+
Zu beachten ist: in <shadowprops> enthaltene Properties *ersetzen*
(nicht ergaenzen) im Regelfall diejenigen im Templat *und* in
<props>. In <props> enthaltene Properties *ersetzen* wiederum
@@ -189,6 +192,6 @@
SIEHE AUCH
==========
- AddvItem(), AddItem(), RemoveItem() *../std/vitems*
+ RemoveVItem(), AddItem(), RemoveItem() *../std/vitems*
Last modified: 03.04.2019, Zesstra
diff --git a/doc/lfun/PreventInsert b/doc/lfun/PreventInsert
index 3635142..e58e827 100644
--- a/doc/lfun/PreventInsert
+++ b/doc/lfun/PreventInsert
@@ -19,7 +19,7 @@
=========
ob
- Das Objekt, das in den Behaelter eingefuegt werden soll.
+ Das Objekt, das in den Behaelter eingefuegt werden soll.
BESCHREIBUNG
@@ -28,44 +28,49 @@
Mit dieser Funktion kann ein Behaelter pruefen, ob er das Objekt ob
aufnehmen moechte oder nicht.
+ Man beachte bitte, dass nach dieser Funktion *nicht* garantiert
+ ist, dass das Objekt wirklich bewegt wird, es handelt sich
+ lediglich um die Abfrage der Erlaubnis! Die Bewegung kann aus einer
+ Vielzahl an Gruenden noch abgebrochen werden.
+
+ Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventInsert()
+ zwar aufgerufen, aber das Ergebnis ignoriert, d.h. die Aufnahme
+ kann in dem Fall nicht verhindert werden.
+
RUeCKGABEWERT
=============
- 0, wenn das Objekt aufgenommen werden kann; ein Wert groesser als 0
- zeigt an, dass das Objekt nicht aufgenommen werden soll.
+ 0
+ wenn das Objekt aufgenommen werden kann;
-
-BEMERKUNGEN
-===========
-
- Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventInsert() zwar
- aufgerufen, das Objekt wird jedoch auf jeden Fall in den Behaelter
- bewegt, unabhaengig vom Rueckgabewert!
+ > 0
+ ein Wert groesser als 0 zeigt an, dass das Objekt nicht
+ aufgenommen werden soll.
BEISPIELE
=========
- Um zu verhindern, dass man Geld in einen Behaelter stecken kann, sollte
- man wie folgt vorgehen:
+ Um zu verhindern, dass man Geld in einen Behaelter stecken kann,
+ sollte man wie folgt vorgehen:
- varargs int PreventInsert(object ob)
- {
- // Wenn es Geld ist, erheben wir sofort Einspruch
- if (ob->id("geld"))
- return 1;
- // Ansonsten koennte ein ererbtes Objekt noch Einspruch erheben!
- else
- return ::PreventInsert(ob);
- }
+ public int PreventInsert(object ob)
+ {
+ // Wenn es Geld ist, erheben wir sofort Einspruch
+ if (ob->id("geld"))
+ return 1;
+ // Ansonsten koennte ein ererbtes Objekt noch Einspruch erheben!
+ else
+ return ::PreventInsert(ob);
+ }
SIEHE AUCH
==========
PreventLeave(), NotifyInsert(), NotifyLeave(), MayAddObject(),
- PreventInsertLiving(), PreventLeaveLiving(), NotifyMove(),
- PreventMove(), MayAddWeight(), move(), /std/container/restrictions.c
+ MayAddWeight(), PreventInsertLiving(), PreventLeaveLiving(),
+ NotifyMove(), PreventMove(), move(), /std/container/restrictions.c
-Last modified: Sat Dec 18 02:00:00 1999 by Tiamak
+Last modified: 30.01.2020, Zesstra
diff --git a/doc/props-liste b/doc/props-liste
index fe9f231..b1b0cf6 100644
--- a/doc/props-liste
+++ b/doc/props-liste
@@ -636,6 +636,8 @@
* P_PREFERED_ENEMY
+* P_PREPARED_SPELL
+
* P_PRESAY
* P_PREVENT_PILE
diff --git a/doc/props/P_DOOR_INFOS b/doc/props/P_DOOR_INFOS
index dc393da..a432ed0 100644
--- a/doc/props/P_DOOR_INFOS
+++ b/doc/props/P_DOOR_INFOS
@@ -18,17 +18,17 @@
BESCHREIBUNG
============
- Mapping mit Informationen ueber eine im Raum per NewDoor() definierte
+ Array mit Informationen ueber eine im Raum per NewDoor() definierte
Tuer. Diese Infos werden ueber /std/room/doors.c an den /obj/doormaster.c
weitergegeben und dem Raum, der die Tuer besitzt, als Property gesetzt.
- Werden mehrere Tueren in einem Raum eingebunden, enthaelt das Mapping
+ Werden mehrere Tueren in einem Raum eingebunden, enthaelt das Array
entsprechend viele Eintraege.
- Dieses Mapping dient zur internen Verwaltung der Tueren im
+ Dieses Property dient zur internen Verwaltung der Tueren im
/obj/doormaster.c und sollte nicht per Hand veraendert werden!
- Die Eintraege im Mapping haben folgende keys (definiert in
- /sys/doorroom.h):
+ Jeder Eintrag im Array ist erneut ein Array und hat folgende Indices
+ (definiert in /sys/doorroom.h):
D_DEST : Zielraum (string)
D_CMDS : Befehl(e), um durch die Tuer zu gehen (string oder *string)
@@ -55,4 +55,4 @@
NewDoor(), QueryDoorKey(), QueryDoorStatus(), SetDoorStatus(),
/std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
-Letzte Aenderung: Don, 08.05.2014, Gabylon
+Letzte Aenderung: 13.3.2020 Zesstra
diff --git a/doc/props/P_GLOBAL_SKILLPROPS b/doc/props/P_GLOBAL_SKILLPROPS
index 1e3533b..c43c820 100644
--- a/doc/props/P_GLOBAL_SKILLPROPS
+++ b/doc/props/P_GLOBAL_SKILLPROPS
@@ -33,6 +33,14 @@
FACTOR(SI_SPELLCOST): #'costFactor]));
+BEMERKUNG
+=========
+
+ Diese Property wird in AddSpell() ausgewertet, nicht in UseSpell().
+ Sie muss also vor dem Hinzufuegen von Spells mitels AddSpell
+ gesetzt werden.
+
+
SIEHE AUCH
==========
@@ -43,4 +51,4 @@
* Properties: P_SB_SPELLS
Skills: P_NEWSKILLS, spruchermuedung, skill_info_liste
-3. Okt 2011 Gloinson
+Letzte Aenderung: 06.03.2020, Bugfix
diff --git a/doc/props/P_PREPARED_SPELL b/doc/props/P_PREPARED_SPELL
new file mode 100644
index 0000000..6340909
--- /dev/null
+++ b/doc/props/P_PREPARED_SPELL
@@ -0,0 +1,36 @@
+
+P_PREPARED_SPELL
+****************
+
+
+NAME
+====
+
+ P_PREPARED_SPELL "prepared_spell"
+
+
+DEFINIERT IN
+============
+
+ /sys/new_skills.h
+
+
+BESCHREIBUNG
+============
+
+ Enthaelt ein Array mit Daten zu einem in Vorbereitung befindlichen
+ Spell.
+
+ * arr[0]: Ausloesezeitpunkt (int)
+
+ * arr[1]: Spellinformationen (mapping)
+
+ * arr[2]: Skill-Argument (string)
+
+
+SIEHE AUCH
+==========
+
+ P_GUILD_PREPAREBLOCK
+
+Letzte Aenderung: 26.03.2021, Bugfix