Automatisch erzeugte Manpages.
Damit nicht jeder sphinx auf dem Rechner haben muss,
behalten wir bis auf weiteres die aus den .rst
erzeugten Manpoages auch im Repo.
Change-Id: Id556c0d11cf5f79659d8350952ce1c014d81ea44
diff --git a/doc/sphinx/man/lfun/reset b/doc/sphinx/man/lfun/reset
new file mode 100644
index 0000000..5959b3f
--- /dev/null
+++ b/doc/sphinx/man/lfun/reset
@@ -0,0 +1,106 @@
+
+reset()
+*******
+
+
+FUNKTION
+========
+
+ void reset();
+ protected void reset();
+
+
+BESCHREIBUNG
+============
+
+ reset() wird vom GameDriver in jedem Objekt aufgerufen, um dem Objekt
+ die Gelegenheit zu geben, sich wieder in einen definierten Zustand zu
+ versetzen: Raeume und Monster erzeugen per AddItem() eingefuegte und
+ zwischenzeitlich entfernte Objekte neu, Tueren schliessen sich ...
+
+ Solange das Objekt "benutzt" wird, wird reset() regelmaessig alle
+ 45 Minuten (+/-15 Minuten) mit einer Aufloesung von 2s aufgerufen
+ (d.h. der Driver prueft und ruft nur alle 2 Sekunden reset() auf
+ allen Objekten).
+
+ Wird eine Objekt nicht mehr "benutzt", d.h. wird an einem Objekt nicht
+ von aussen (durch call_other etc.) _nach_ einem reset() eine Methode
+ bzw. LFun gerufen, so bekommt dieses Objekt keinen weiteren reset().
+
+ Ein Funktionsaufruf am Objekt schaltet den reset() wieder ein.
+ Bei einem Objekt in einem Container waere das zB das Benutzen des
+ Containers (Hineinlegen/Herausnehmen/Hineinsehen). Das kann
+ sehr lange dauern.
+
+ Die Abschaltung kann man verhindern, indem man im reset() per call_out()
+ eine Funktion im Objekt ruft. Dies aber bitte _nur_ machen, wenn das
+ Objekt _unbedingt_ auf einen staendigen Reset angewiesen ist, auch wenn
+ es nicht "benutzt" wird.
+
+ Aendern laesst sich die Zeit zwischen den Aufrufen von reset() mit
+ set_next_reset(). Die Aufloesung von 2s kann man nicht aendern.
+
+
+BEMERKUNGEN
+===========
+
+ - man kann reset() nutzen, um Ereignisse auszuloesen:
+ - es ist billiger als lange call_out()
+ - siehe Warnung bezueglich Abschalten des reset
+ - man kann reset() als protected oder static definieren, wenn man nicht
+ moechte, dass die Funktion von aussen gerufen werden kann. Dies
+ verhindert Einflussnahme von aussen, kann aber auch Debugmassnahmen
+ erschweren. Es ist aber dennoch fuer einige Objekte sinnvoll.
+ - der Driver ruft reset() unabhaengig von zusaetzlichen, "manuellen"
+ Rufen von reset()
+ - keine Rufe von reset() mit call_out() aus reset() (Callout-Ketten-
+ bildung droht), fuer solche Faelle ist set_next_reset(E) da!
+ - bei Blueprints sollte der reset() in der Regel abgeschaltet werden,
+ sofern er nicht auf wichtige Aufgaben in der BP zu tun hat:
+ protected void create() {
+ if(!clonep(ME)) {
+ set_next_reset(-1);
+ return;
+ }
+ ::create();
+ ...
+ }
+
+
+BEISPIELE
+=========
+
+ // ein NPC, der bei jedem reset() schaut, ob um ihn herum bessere
+ // Ausruestung liegt als die, die er selbst gerade traegt:
+
+ ...
+ void reset() {
+ ::reset();
+
+ if(clonep(this_object()) && environment()) {
+ object o;
+ o=first_inventory(environment());
+ while(o) {
+ look_for_good_weapons_and_use_them_if_better(o);
+ o=next_inventory(o);
+ }
+ }
+ }
+
+ // ein reset fuer einen Gegenstand, der vielleicht in
+ // in einem Container landet und dann weiter einen reset
+ // bekommen muss/soll
+
+ void reset() {
+ // irgend ein Code hier
+ call_other(this_object(), "???"); // einfach nur was aufrufen
+ }
+
+
+SIEHE AUCH
+==========
+
+ clean_up(), set_next_reset(E), query_next_reset(E)
+ memory
+
+letzte Aenderung: 2009-01-14 Rumata