Gesammelte Doku-Updates
Groesstenteils Formatierung, Whitespace und kleinere
Aenderungen.
Change-Id: I2a7363cb10ff5b4c5252e1e7bef62d2bff6d9ff0
diff --git a/doc/lfun/create b/doc/lfun/create
index 03fc91a..066ee55 100644
--- a/doc/lfun/create
+++ b/doc/lfun/create
@@ -7,7 +7,6 @@
========
protected void create();
- void create();
DEFINIERT IN
@@ -25,15 +24,15 @@
BESCHREIBUNG
============
- Diese Funktion wird aufgerufen, wenn ein Objekt geladen oder geclont
- wird.
- In dieser Funktion wird das Objekt initialisiert und konfiguriert.
- Waehrend des create() kann es einen this_player()/this_interactive()
- geben, muss aber nicht!
- Im create() hat das Objekt noch kein environment().
- create() wird nur gerufen, wenn das Objekte geclont oder explizit geladen
- wird. Wenn es aufgrund eines inherit in einem anderen Objekt vom Driver
- geladen wird, wird das create() nicht ausgefuehrt (s. create_super()).
+ Diese Funktion wird aufgerufen, wenn ein Objekt geladen oder
+ geclont wird. In dieser Funktion wird das Objekt initialisiert und
+ konfiguriert. Waehrend des create() kann es einen
+ this_player()/this_interactive() geben, muss aber nicht! Im
+ create() hat das Objekt noch kein environment(). create() wird nur
+ gerufen, wenn das Objekte geclont oder explizit geladen wird. Wenn
+ es aufgrund eines inherit in einem anderen Objekt vom Driver
+ geladen wird, wird das create() nicht ausgefuehrt (s.
+ create_super()).
RUeCKGABEWERT
@@ -45,20 +44,24 @@
BEMERKUNGEN
===========
- Erbt man von anderen Objekten, so besteht die erste Aktion innerhalb
- von create() normalerweise darin, in diesen Objekten create()
- aufzurufen.
- Die Funktion kann protected oder static sein (aber nicht private). Es
- duerfte fuer die meisten Objekte sinnvoll sein, create() protected zu
- deklarieren.
+ Erbt man von anderen Objekten, so besteht die erste Aktion
+ innerhalb von create() normalerweise darin, in diesen Objekten
+ create() aufzurufen.
- Um Speicher zu sparen, kann man bei Blueprints von der Konfigurierung
- absehen (siehe Beispiel). Dies sollte man allerdings nicht bei Objekten
- machen, von denen keine Clones erzeugt werden sollen (zB. bei Raeumen).
+ In altem Code wird create() haeufig ohne Sichtbarkeitsmodifikator
+ verwendet, es sollte aber immer protected gewaehlt werden, es gibt
+ keinen guten Grund create() mehr als einmal zu rufen, im Gegenteil,
+ wird das geerbte create() mehrfach gerufen kann das zu schwer zu
+ findenden Bugs fuehren.
- Man sollte bei Abbruch des create() in BP unbedingt set_next_reset(-1);
- rufen, da sonst die (nicht konfigurierte) BP resetten kann und dann
- buggt.
+ Um Speicher zu sparen, kann man bei Blueprints von der
+ Konfigurierung absehen (siehe Beispiel). Dies sollte man allerdings
+ nicht bei Objekten machen, von denen keine Clones erzeugt werden
+ sollen (zB. bei Raeumen).
+
+ Man sollte bei Abbruch des create() in BP unbedingt
+ set_next_reset(-1); rufen, da sonst die (nicht konfigurierte) BP
+ resetten kann und dann buggt.
BEISPIELE
@@ -66,18 +69,19 @@
Ein Gegenstand wuerde wie folgt konfiguriert:
- inherit "std/thing";
+ inherit "/std/thing";
#include <properties.h>
- create()
+ protected void create()
{
// Wenn wir die Blueprint sind: NICHT konfigurieren!
- // Bei normalen Raeumen oder Transportern sind diese beiden
+ // Bei normalen Raeumen oder Transportern sind diese
// Zeilen wegzulassen!!!
- if (!clonep(this_object())) {
- set_next_reset(-1); // wichtig, damit die BP nicht resettet.
- return;
+ if (!clonep(this_object()))
+ {
+ set_next_reset(-1); // wichtig, damit die BP nicht resettet.
+ return;
}
// Ansonsten die allgemeinen Eigenschaften von /std/thing
@@ -97,8 +101,6 @@
SIEHE AUCH
==========
- create(L), reset(L)
- hook(C), create(H), create_ob(H), create_super(H, reset(H)
- create(A), reset(A)
+ create(), reset(), create_super() set_next_reset()
-22.10.2007, Zesstra
+Letzte Aenderung: 27.10.2018, Bugfix