Added public files
Roughly added all public files. Probably missed some, though.
diff --git a/doc/std/.synonym b/doc/std/.synonym
new file mode 100644
index 0000000..508ee32
--- /dev/null
+++ b/doc/std/.synonym
@@ -0,0 +1,9 @@
+armours armour
+ruestung armour
+ruestungen armour
+weapons weapon
+waffen weapon
+waffe weapon
+units unit
+vc virtual_compiler
+ringbuffer util
diff --git a/doc/std/armour b/doc/std/armour
new file mode 100644
index 0000000..9721cfc
--- /dev/null
+++ b/doc/std/armour
@@ -0,0 +1,87 @@
+ STANDARDKLASSE:
+ "/std/armour"
+
+ BENUTZUNG:
+ inherit "/std/armour";
+
+ #include <properties.h>
+ #include <combat.h>
+
+ PROPERTIES:
+ Grundlegend:
+ P_AC setzbar: Ruestungsklasse == Schutz
+ P_ARMOUR_TYPE setzbar: Ruestungstyp
+
+ Besondere Attribute und Anforderungen fuer Traeger:
+ P_RESTRICTIONS setzbar: Anforderungen an Traeger
+ P_M_ATTR_MOD setzbar: Attributmodifikator fuer Traeger
+ P_RESISTANCE_STRENGTHS
+ setzbar: Resistenzmodifikator fuer Traeger
+ P_NR_HANDS setzbar: notwendige Handanzahl (zB Schilde)
+ P_CURSED setzbar: Verfluchung (nicht ausziehbar)
+
+ Meldungen und Zeitpunkte:
+ P_EQUIP_TIME enthaelt den Zeitpunkt des Anziehens
+ P_LAST_USE enthaelt den Zeitpunkt des letzten Treffers
+ P_WORN enthaelt den Traeger
+ P_WEAR_MSG setzbar: eigene Anziehmeldungen
+ P_UNWEAR_MSG setzbar: eigene Ausziehmeldungen
+
+ Dynamisches Verhalten in Kampf und beim Anziehen:
+ P_WEAR_FUNC setzbar: Objekt mit Anziehfunktion "WearFunc()"
+ P_REMOVE_FUNC setzbar: Objekt mit Ausziehfunktion "RemoveFunc()"
+ P_DEFEND_FUNC setzbar: Objekt mit Defensivfunktion "DefendFunc()"
+
+ Zusaetzliche Eigenschaften:
+ P_DAMAGED enthaelt den Ausmass des Schadens an Waffe
+ P_QUALITY setzbar: Qualität/Haltbarkeit der Waffe
+ P_EFFECTIVE_AC setzbar: falls DefendFunc AC nicht sichbar aendert
+ P_DAM_TYPE setzbar: interessant bei Kaempferangriffen
+
+ Zusaetzlich sind alle Properties aus /std/thing verfuegbar, also
+ bitte auch folgende setzen:
+ P_MATERIAL setzbar: Zusammensetzung
+ P_SIZE setzbar: Groesse
+ P_WEIGHT setzbar: Gewicht
+
+ MAKROS:
+ Gueltige Ruestungstypen (definiert in "/sys/combat.h").
+
+ ERLAEUTERUNG:
+ Basisklasse fuer alle Ruestungen im Spiel. Sie ist von "/std/clothing"
+ abgeleitet und enthaelt alle zusaetzliche Funktionalitaet
+ fuer den Kampf.
+
+ Vor der Programmierung von Ruestungen sollte /doc/MG/waffen_werte
+ gelesen werden. Die Regeln darin sind verbindlich und sollten nur
+ in Ausnahmefaellen und mit Absprache mit dem Erzmagier fuer
+ Waffen/Ruestungen/Monster ueberschritten werden.
+ Gerade in DefendFuncs sollte auf die korrekte Behandlung der
+ uebergebenen Spellflags geachtet werden - insbesondere SP_RECURSIVE
+ und SP_NO_ACTIVE_DEFENSE.
+
+ Die Maximalwerte und Werte fuer Zerstoerung bei Verkauf sind
+ /sys/combat.h zu entnehmen: VALID_ARMOUR_CLASS/KEEP_ARMOUR_CLASS.
+
+ VERERBUNGSBAUM:
+ [/std/armour]
+ ..... [/std/thing/properties]
+ ..... [/std/thing/language]
+ ..... [/std/thing/commands]
+ ..... [/std/thing/restrictions]
+ ..... [/std/thing/envchk]
+ ..... [/std/armour/description]
+ .......... [/std/clothing/description]
+ .............. [/std/thing/description]
+ ..... [/std/armour/wear]
+ .......... [/std/clothing/wear]
+ ..... [/std/clothing/moving]
+ .......... [/std/thing/moving]
+ ..... [/std/armour/combat]
+
+ SIEHE AUCH:
+ P_ARMOURS, P_LAST_WEAR_ACTION, P_TOTAL_AC
+ Attack(), Defend(), /doc/wiz/ruestungen, balance
+
+03.08.2007, Zesstra
+
diff --git a/doc/std/clothing b/doc/std/clothing
new file mode 100644
index 0000000..91ccb55
--- /dev/null
+++ b/doc/std/clothing
@@ -0,0 +1,77 @@
+ STANDARDKLASSE:
+ "/std/clothing"
+
+ BENUTZUNG:
+ inherit "/std/clothing";
+
+ #include <properties.h>
+ #include <clothing.h>
+
+ PROPERTIES:
+
+ Besondere Attribute und Anforderungen fuer Traeger:
+ P_RESTRICTIONS setzbar: Anforderungen an Traeger
+ P_CURSED setzbar: Verfluchung (nicht ausziehbar)
+
+ Meldungen und Zeitpunkte:
+ P_EQUIP_TIME enthaelt den Zeitpunkt des Anziehens
+ P_WORN enthaelt den Traeger
+ P_WEAR_MSG setzbar: eigene Anziehmeldungen
+ P_UNWEAR_MSG setzbar: eigene Ausziehmeldungen
+
+ Dynamisches Verhalten in Kampf und beim Anziehen:
+ P_WEAR_FUNC setzbar: Objekt mit Anziehfunktion "WearFunc()"
+ P_REMOVE_FUNC setzbar: Objekt mit Ausziehfunktion "RemoveFunc()"
+
+ Zusaetzlich sind alle Properties aus /std/thing verfuegbar, also
+ bitte auch folgende setzen:
+ P_MATERIAL setzbar: Zusammensetzung
+ P_SIZE setzbar: Groesse
+ P_WEIGHT setzbar: Gewicht
+
+
+ ERLAEUTERUNG:
+ Basisklasse fuer alle Kleidungen im Spiel. Sie ist von "/std/thing"
+ abgeleitet.
+ Kleidung belegt niemals einen Ruestungsslot und ist nur fuer Kram
+ gedacht, der keine kampfrelevante Funktionalitaet beeinhaltet.
+ Momentan ist die Anzahl an Kleidungsstuecken, die ein Spieler anziehen
+ kann, nicht begrenzt.
+ Kleidung sind im Prinzip Ruestungen ohne alle in den Ruestungen
+ enthaltene kampfrelevante Funktionalitaet.
+ (BTW: Kleidungen koennen allerdings, sofern unbedingt notwendig, mittels
+ P_SENSITIVE, P_SENSITIVE_ATTACK, etc. auch indirekt am Kampf teilnehmen,
+ in dem Sinne, dass sie auf eingehenden Schaden reagieren. Hierbei darf
+ allerdings in keinem Fall in den Kampfverlauf eingegriffen werden.)
+
+ Spezielle Properties:
+ SetProp(P_WEAR_FUNC, ob)
+ Setzt das Objekt, in dem die Funktion WearFunc() definiert
+ wird. WearFunc() wird beim Versuch die Kleidung anzuziehen
+ aufgerufen, gibt sie 0 zurueck so scheitert der Versuch.
+ SetProp(P_REMOVE_FUNC, ob)
+ Setzt das Objekt, in dem die Funktion RemoveFunc() definiert
+ ist. Die Funktion wird beim Versuch die Kleidung auszuziehen
+ aufgerufen, gibt sie 0 zurueck, so scheitert der Versuch.
+
+
+ VERERBUNGSBAUM:
+ [/std/clothing]
+ ..... [/std/thing/properties]
+ ..... [/std/thing/language]
+ ..... [/std/thing/commands]
+ ..... [/std/thing/restrictions]
+ ..... [/std/thing/envchk]
+ ..... [/std/clothing/description]
+ .......... [/std/thing/description]
+ ..... [/std/clothing/moving]
+ .......... [/std/thing/moving]
+ ..... [/std/clothing/wear]
+
+ SIEHE AUCH:
+ armours,
+ FilterClothing, FilterArmours, Wear(), Unwear(), WearArmour(),
+ WearClothing(), UnwearArmour(), UnwearClothing()
+
+15.02.2009, Zesstra
+
diff --git a/doc/std/container b/doc/std/container
new file mode 100644
index 0000000..667078a
--- /dev/null
+++ b/doc/std/container
@@ -0,0 +1,49 @@
+OBJECT:
+ container
+
+
+DESCRIPTION:
+ A cointainer is a special object which can contain other objects.
+ It provides the same functions as the thing(S) class, but adds
+ some functions for the handling of contents. It defines some
+ properties related to what and how much is contained in it.
+
+ The following additional properties are defined for a container:
+ P_MAX_WEIGHT, P_WEIGHT_CONTENTS
+
+ Note that the weight of a container is handled especially:
+ SetProp(P_WEIGHT,weight) sets the weight of the container
+ without contents, while QueryProp(P_WEIGHT) returns the total
+ weight of the container plus contents.
+
+ For now, you may use the following function to add or remove
+ weight from the container.
+
+ AddWeight(weight)
+ Adds <weight> to the container. If its OK, 1 is returned,
+ otherwise 0. Only if the weight fits into the container, the
+ weight is adjusted.
+
+ MayAddWeight(weight)
+ Like AddWeight, but if the weight fits inside the container,
+ the total weight is NOT updated. You may use this function to
+ test if an object fits into a container.
+
+ NOTE: Currently, these functions may be called from outside.
+ In a alter stage, movement of objects will be done by calling
+ the move() function in the object to be moved. The move()
+ function of that object will then call (May)AddWeight() itself
+ to determine if it may enter the container.
+
+
+INHERITANCE TREE:
+ container
+ |-thing/moving
+ |-thing/properties
+ |-container/description
+ | `-thing/description
+ `-container/restrictions
+
+
+SEE ALSO:
+ thing(S)
diff --git a/doc/std/corpse b/doc/std/corpse
new file mode 100644
index 0000000..d4e2d47
--- /dev/null
+++ b/doc/std/corpse
@@ -0,0 +1,76 @@
+OBJEKT:
+ corpse
+
+
+SYNOPSIS:
+ inherit "std/corpse";
+
+
+BESCHREIBUNG:
+ Die Standardleiche ist ein spezieller Container. Er beinhaltet die
+ zurueckgelassene Ausruestung gestorbener NPCs und Spieler.
+ Die Standardleiche verfault mit der Zeit und stellt ein paar
+ Funktionalitaeten zur Verfuegung, naemlich das Essen der Leiche
+ und das Verspotten auf dem Moerderkanal.
+ Die Funktion
+ void Identify( object ob );
+ wird im die() eines Livings aufgerufen, damit die Leiche Informationen
+ aus dem Living auslesen kann, ehe dieser endgueltig stirbt. Schreibt
+ man eine eigene Leiche, dann ist dies die geeignete Moeglichkeit, der
+ Leiche Informationen zukommen zu lassen.
+
+
+BEISPIELE:
+ // Eine eigene Leiche.
+ #inherit "std/corpse";
+
+ void create()
+ {
+ ::create();
+ // Irgendwas eigenes...
+ }
+
+ /*
+ * Dieser Funktion wird der getoetete Living uebergeben.
+ */
+ void Identify(object ob)
+ {
+ ::Identify(ob);
+ if (ob)
+ {
+ ob->QueryProp("meine_tolle_property");
+ }
+ }
+
+ /*
+ * Das ist die für "iss leiche" aufgerufene Funktion.
+ */
+ int mampf( string str )
+ {
+ notify_fail("Was willst Du essen?\n");
+ if (!str || !id(str) ) return 0;
+ tell_object(this_player(), "Diese Leiche kann man nicht essen.\n");
+ return 1;
+ }
+
+
+
+BEMERKUNG:
+ Man kann eigene Leichen schreiben, die von der Standardleiche erben
+ oder auch nicht. Man sollte dann aber die im die() aufgerufenen
+ Funktionen implementieren:
+ corpse->Identify(object ob);
+ corpse->SetProp(***); // Fuer P_HEAL
+ corpse->move(***); // Um sie ins environment() des Toten zu bekommen.
+ Die Leiche sollte, muss aber kein Container sein, damit die Ausruestung
+ hineinbewegt werden kann.
+ Wenn man nicht von der Standardleiche erbt, kommt sie nicht auf -Moerder
+ und man kann sie nicht verspotten. Damit dies geht, muss (!) man von der
+ Standardleiche erben.
+
+SIEHE AUCH:
+ P_NOCORPSE, P_CORPSE, P_HEAL, QueryHealInfo()
+
+
+----------------------------------------------------------------------------
+Letzte Aenderung: 31.03.2008, Arathorn
diff --git a/doc/std/hooks b/doc/std/hooks
new file mode 100644
index 0000000..de308bd
--- /dev/null
+++ b/doc/std/hooks
@@ -0,0 +1,278 @@
+Das neue Hooksystem
+(Implementierung von Muadib, ueberarbeitet von Zesstra)
+
+EINLEITUNG
+==========
+Das neue Hooksystem baut nicht mehr auf der Eintragung eines Hooks in einer
+Property auf. Dadurch wird es moeglich, dass nicht nur ein Objekt sich als
+Hook eintraegt.
+
+Es gibt verschiedenen Arten von Hooks, die man eintragen kann:
+* Listener (H_LISTENER)
+ diese Hooks werden ueber ein Ereignis nur informiert,
+ koennen aber nicht eingreifen oder aendern.
+ max. Anzahl: 5
+* Data-Modifier (H_DATA_MODIFICATOR)
+ diese Hooks duerfen die Daten eines Ereignisses aendern.
+ max. Anzahl: 3
+* Hook-Modifier (H_HOOK_MODIFICATOR)
+ diese Hooks duerfen die Daten des Ereignisses aendern und
+ zusaetzlich das Ereignis auch abbrechen.
+ max. Anzahl: 2
+* Surveyor (H_HOOK_SURVEYOR)
+ diese Hooks duerfen alles oben beschriebene. Zusaetzlich werden
+ sie aber auch gefragt, wenn andere Objekte einen Hook eintragen
+ wollen, einen Hook abbrechen wollen oder Daten aendern wollen.
+ Oder anders: Surveyorhooks entscheiden, was andere duerfen.
+ Kein normales Objekte sollte diese Art von Hook eintragen. Der RM
+ muss die Verwendung eines Surveyors genehmigen.
+ max. Anzahl: 1
+
+Ausserdem lassen sich Hooks noch mit unterschiedlicher Prioritaet eintragen,
+welche dann in der entsprechenden Reihenfolge abgearbeitet werden. Wenn ein
+neuer Hook eingetragen wird, aber eigentlich die max. Anzahl schon erreicht
+wird, wird der Konsument mit der niedrigsten Prioritaet geloescht. In diesem
+Fall wird die superseededHook() im verdraengten Konsumenten gerufen.
+
+Um das neue Hook-System zu realisieren, gibt es zwei wesentliche Klassen.
+Die Objekte, die die Eintragung von Hooks erlauben, erben hierzu von
+hook_provider. Objekte, die einen Surveyor-Hook eintragen wollen, sollten von
+der Klasse hook_surveyor erben. Objekte mit normalen Hooks brauchen nichts zu
+erben.
+
+
+Welche Hooks gibt es zur Zeit in der Basis-Mudlib?
+=================================================
+* H_HOOK_MOVE
+ Bei Bewegung eines Objektes ausgeloest. Kann Bewegung beeinflussen oder
+ abbrechen.
+* H_HOOK_DIE
+ Beim Tod eines Lebewesens ausgeloest. Kann den Tod abbrechen oder
+ <poisondeath> abaendern.
+* H_HOOK_DEFEND
+ Im Defend() eines Lebenwesens ausgeloest. Kann das Defend() abbrechen und
+ Daten des Defend() aendern.
+* H_HOOK_ATTACK
+ Im Attack() eines Lebenwesens ausgeloest. Kann das Attack() abbrechen.
+* H_HOOK_HP
+ Bei Veraenderung der HP (LP) eines Lebewesens gerufen. (Zur Zeit keine
+ Datenveraenderung moeglich)
+* H_HOOK_SP
+ Bei Veraenderung der SP (KP) eines Lebewesens gerufen. (Zur Zeit keine
+ Datenveraenderung moeglich)
+* H_HOOK_ATTACK_MOD
+ Wird im Attack() ausgeloest, nachdem die fuer den Angriff wichtigen Daten
+ ermittelt und berechnet wurden. Diese koennen dann vom Hookonsumenten
+ nochmal geaendert werden. Auch ein Abbruch des Attack() ist hier noch
+ moeglich.
+* H_HOOK_ALCOHOL
+ Bei Veraenderung von P_ALCOHOL im Lebewesens gerufen.
+* H_HOOK_FOOD
+ Bei Veraenderung von P_FOOD im Lebewesens gerufen.
+* H_HOOK_DRINK
+ Bei Veraenderung von P_DRINK im Lebewesens gerufen.
+* H_HOOK_POISON
+ Bei Veraenderung von P_POISON im Lebewesens gerufen.
+* H_HOOK_CONSUME
+ Beim Konsumieren von Speisen und Getraenken in Kneipen im Lebewesens
+ gerufen.
+* H_HOOK_TEAMROWCHANGE
+ Bei Teamreihenwechsel vom Lebewesen ausgeloest.
+* H_HOOK_INSERT
+ Wird von Spielerobjekten ausgeloest, wenn ein Objekt ins Spielerinventar
+ bewegt wird. (Keine Datenveraenderung moeglich)
+* H_HOOK_EXIT_USE
+ Wird von einem Raum ausgeloest, wenn ein Lebewesen einen Ausgang benutzt.
+ Abbruch und Aenderung der Daten des Ausgangs moeglich.
+
+HOOK-KONSUMENTEN
+================
+Der Hook-Provider ruft bei Ausloesen des Hooks in allen Konsumenten eine
+bestimmte Methode auf. Wenn bei der Registrierung eines Objekts keine Closure
+angeben wurde, die in diesem Fall gerufen werden, wird standardmaessig die
+lfun HookCallback() gerufen (gibt man eine Closure an, bekommt sie die
+gleichen Argumente und es werden die beschriebenen Rueckgabewerte erwartet):
+ * mixed HookCallback(object hookSource, int hookid, mixed hookData)
+ Diese Methode wird in jedem Hook-Konsumenten eines Hook-Providers
+ aufgerufen, solange die Verarbeitung nicht vorher abgebrochen wurde.
+ Die Reihenfolge der Abarbeitung wird nach Liste (Surveyor,
+ Hook-Modifikator, Data-Modifikator, Listener) und dort nach Prioritaet
+ durchgefuehrt.
+ Ein Surveyor-Hook kann verhindern, dass Hooks bestimmte Aenderungen
+ durchfuehren.
+
+ Rueckgabewert ist ein Array, das die folgenden Werte beinhaltet.
+
+ H_RETCODE Gibt an, welcher Hook-Typ verwendet wurde.
+ H_NO_MOD => Nichts wurde veraendert.
+ H_ALTERED => Daten wurden veraendert.
+ H_CANCELLED => Hook-Kette soll abgebrochen werden.
+ => Ausserdem soll die Hook-ausloesende Stelle
+ abgebrochen werden. Z.B. wird das Defend()
+ abgebrochen, wenn ein H_HOOK_DEFEND
+ mit cancelled beantwortet wird.
+ H_RETDATA Gibt die (evtl. geaenderten) Daten an.
+ mixed-Objekt, das wie der Parameter hookData aufgebaut ist.
+
+Ein Objekt darf sich mehrfach fuer den gleichen Hook registrieren. Allerdings
+ist fuer jede Registrierung eine andere Closure noetig.
+
+ * void superseededHook(int hookid, object hookprovider)
+ Wird gerufen, wenn der Konsument von einem anderen mit hoeherer Prioritaet
+ verdraengt wurde.
+
+
+HOOK-PROVIDER
+=============
+ Der Hook-Provider bietet eine Menge von Methoden an, die eine Konfiguration
+ ermoeglichen und die Eintragung von Hook-Konsumenten erlauben. Im
+ Normalfall sollte er geerbt und nicht modifiziert werden (ausser natuerlich,
+ die vom Objekte bereitgestellten Hooks einzutragen).
+
+ * int* HListHooks();
+ Diese Methode liefert eine Liste von Hooktypen, fuer die das Objekt
+ Eintragungen annimmt. Hier koennte beispielsweise eine Liste mit den
+ Eintraegen fuer Attack-, Defend- und Move-Hooks stehen.
+
+
+ * protected void offerHook(int hookid, int offerstate);
+ Diese Methode dient dazu, einen bestimmten Hook (z.B. H_HOOK_MOVE)
+ anzubieten. Nur Hooks, die hiermit angeboten wurden, stehen zur
+ Registrierung zur Verfuegung.
+ 'offerstate': 0 (nicht verfuegbar), 1 (verfuegbar/angeboten)
+
+
+ * int HRegisterToHook(int hookid, mixed consumer, int hookprio,
+ int consumertype, int timeInSeconds);
+ Registriert ein Objekt oder eine Closure als Hook-Konsument.
+ Parameter:
+ 'hookid' gibt den Hook-Typ an, z.B. den Defend-Hook.
+ Man kann sich nur fuer Hooktypen eintragen, die die Methode
+ HListHooks() angeboten hat.
+ 'consumer' Wenn ein Objekt, wird das Objekt eingetragen und spaeter
+ HookCallback() gerufen.
+ Wenn eine Closure, wird das Objekt der Closure eingetragen
+ und spaeter diese Closure gerufen.
+ 'hookprio' Gibt die Prioritaet an, mit der der Hook laufen soll.
+ Diese Angabe bestimmt die Reihenfolge, in der die Hooks
+ in der Liste der Hooks eingetragen werden. Die Prioritaet
+ ist H_HOOK_LIBPRIO(x), H_HOOK_GUILDPRIO(x) oder
+ H_HOOK_OTHERPRIO(x). x darf 0, 1 oder 2 sein (je niedriger,
+ desto hoeher die Prioritaet).
+ 'consumertype' Gibt an, um welche Art von Hook es sich handelt.
+ Es gibt vier festgelegten Typen, die fuer alle Hooks
+ existieren koennen. Die Methode HConsumerTypeIsAllowed()
+ gibt Aufschluss darueber, welche Hook-Typen existieren.
+ Die Hook-Typen sind in hook.h definiert.
+ 'timeInSeconds' gibt die Laufzeit des Hooks an. Falls 0 eingetragen wird,
+ laeuft der Hook ewig.
+ Rueckgabewerte:
+ 1 - Registrierung erfolgreich
+ <=0 - Registrierung fehlgeschlagen:
+ -1 : Hook unbekannt
+ -2 : consumer ist keine closure und es konnte kein Callback auf
+ HookCallback im consumer erstellt werden.
+ -3 : consumer ist bereits registriert
+ -4 : consumertyp ist nicht erlaubt
+ -5 : hookprio ist nicht erlaubt
+ -6 : Surveyor hat Registrierung nicht erlaubt
+ -7 : zuviele Hooks registriert / kein Hookeintrag frei
+
+ * int HUnregisterFromHook(int hookid, mixed consumer);
+ Hebt die Registrierung von <consumer> fuer einen bestimmten Hook-Typ wieder
+ auf.
+ Parameter:
+ 'hookid' Die Kennung des Hook-Typs, z.B. die Kennung des Attack-Hooks.
+ 'consumer' Das Objekt oder die Closure, die/das nicht mehr registriert sein
+ soll. Bei einer Closure wird genau diese ausgetragen. Bei der
+ Angabe eines Objekts wird versucht, die Closure auf
+ HookCallback() in diesem Objekt auszutragen.
+ Rueckgabewerte:
+ 0 - 'consumer' nicht als Konsument gefunden
+ 1 - Austragen erfolgreich
+
+ * int HConsumerTypeIsAllowed(int type, object consumer);
+ Diese Methode liefert 1 zurueck, wenn ein bestimmter Konsumenten-Typ
+ (fuer diesen Konsumenten) erlaubt wird.
+ Die Standardmethode liefert immer 1 (true) zurueck. Erbende Objekte
+ koennen diese Methode ueberschreiben, wenn sie nicht alle Hooktypen
+ anbieten.
+
+
+ * int HPriorityIsAllowed(int prio, object consumer);
+ Diese Methode gibt an, ob eine bestimmte Prioritaet (fuer den angegebenen
+ Konsumenten) erlaubt ist. Die Standardmethode liefert immer 1 (true)
+ zurueck. Erbende Objekte koennen diese Methode ueberschreiben, wenn
+ sie die verfuegbaren Hook-Prioritaeten einschraenken wollen.
+
+
+ * int HIsHookConsumer(int hookid, mixed consumer);
+ Ist <consumer> ein Objekt, liefert die Methode die Anzahl, wie oft dieses
+ Objekt (mit verschiedenen Closures) fuer den Hook <hookid> eingetragen ist.
+ Ist <consumer> eine Closure, liefert diese Methode 1, wenn diese
+ Closure fuer den Hook <hookid> eingetragen ist.
+
+
+ * protected mapping HCopyHookMapping();
+ Diese Methode liefert eine Kopie des Hook-Mappings.
+ ACHTUNG: diese Daten sollten das Objekt NIEMALS verlassen. (Ausser fuer
+ Debugzwecke)
+
+
+
+HOOK-SURVEYOR
+=============
+ Objekte mit Surveyorhooks muessen eine Menge von Methoden definieren, die
+ der Hookprovider aufruft:
+
+ * status HookRegistrationCallback(
+ object registringObject,
+ int hookid,
+ object hookSource,
+ int registringObjectsPriority,
+ int registringObjectsType)
+ Diese Methode wird vom Hook-Provider aufgerufen, wenn der Hook-Konsument
+ als Surveyor eingetragen ist und ein weiterer Hook eingetragen werden soll.
+ Gibt diese Methode 0 zurueck, dann verbietet der Konsument, dass der
+ andere Konsument als Hook eingetragen wird.
+
+ * int HookCancelAllowanceCallback(
+ object cancellingObject,
+ int hookid,
+ object hookSource,
+ int cancellingObjectsPriority,
+ mixed hookData)
+ Diese Methode wird aufgerufen, um herauszufinden, ob ein bestimmter
+ anderer Hook die Ausfuehrung der Hook-Kette unterbrechen darf.
+ Nur Hooks im Bereich H_HOOK_MODIFICATOR werden der Methode uebergeben.
+
+ * int HookModificationAllowanceCallback(
+ object modifyingObject,
+ int hookid,
+ object hookSource,
+ int modifyingObjectsPriority,
+ mixed hookData)
+ Diese Methode wird aufgerufen, um herauszufinden, ob ein bestimmter
+ anderer Hook die Daten des Hooks veraendern darf oder nicht.
+ Es werden die Hooks in den Bereichen H_HOOK_MODIFICATOR und
+ H_DATA_MODIFICATOR (in dieser Reihenfolge) aufgerufen.
+
+
+WAS KOSTET DAS?
+ Das Ausloesen eines Hooks per HookFlow() kostet 111 Ticks und ca. 7 us, wenn
+ es gar keinen gibt, der drauf lauscht (sozusagen Fixkosten).
+ Pro H_LISTENER kommen dann 31 Ticks und ca. 2 us dazu.
+
+ Gibts einen Surveyor-Hook (der wird dann gefragt, ob andere Objekte die
+ Daten des Hooks aendern oder die Hookverarbeitung abbrechen duerfen):
+ Fixkosten: 155 Ticks, 11 us.
+ Plus pro Data-Modifier:
+ 106 Ticks, 5.6 us
+ Plus pro Hook-Modifier, der aber nur Daten aendert:
+ 112 Ticks, 6.4 us
+ Und ein Hook-Modifier, der den Hook abbricht:
+ 76 Ticks, 4 us
+
+ (Macht der Surveyor natuerlich irgendwas anderes als 'return 1;', wirds
+ natuerlich entsprechend teurer.)
+
diff --git a/doc/std/living b/doc/std/living
new file mode 100644
index 0000000..89d47bd
--- /dev/null
+++ b/doc/std/living
@@ -0,0 +1,120 @@
+
+OBJECT:
+ living
+
+
+SYNOPSIS:
+ inherit "std/living";
+
+ #include <properties.h>
+ #include <living.h>
+
+
+DESCRIPTION:
+ This is the generic living object which 'lives', can move,
+ can fight.
+
+ It has a number of 'stats', also called 'attributes' in
+ the new system. These include the former stats
+ strength, dexterity, intelligence and constitution.
+ These attributes determine the life functions and
+ variables like hitpoints and spellpoints, but also the
+ ability to perform certain actions like spellcasting or
+ swordfighting. Attributs are implemented as a property
+ P_ATTRIBUTES. Attributes can be set by using the functions
+
+ SetAttribute(string attribute, int value)
+ Sets <attribute> to <value>. Certain restrictions might
+ exist, and the requested attribute might not be set.
+ Attributes are integer values, and are in the range
+ of 1 (very bad) to 20 (excellent and highest possible
+ for a normal human).
+
+ int QueryAttribute(string attribute)
+ Returns value of <attribute>
+
+ Abilities. A living creature may have special abilities
+ to perform certain actions. These may be very different
+ types of actions, like fighting with a sword, casting
+ a fireball or climbing up a tree. Abilities are
+ implemented as the P_ABILITIES property. An ability may
+ be accompanied by an object which may define special
+ actions and which uses the values of P_ABILITES, for
+ example a spellbook will store spell levels there or
+ a weapon uses a weapon ability (skill). The abilities
+ can be manipulated:
+
+ SetAbility(string ability, int value)
+ Sets <ability> to <value>.
+
+ int QueryAbility(string ability)
+ Ask the value of <ability>.
+
+ Equipment. Weaponclass and armourclass are defined. Unless
+ a weapon is used, the wc is 0. Unless an armour is used,
+ the ac is 0. (P_WC and P_AC)
+
+ Live variables. A living creature has several needs just
+ because it is alive. The complex life functions are
+ reducced to some crucial factors.
+
+ P_HP
+ These are mainly determined by the constitution and give
+ the ability of the body to absorb damage. If the
+ hitpoints go below zero, the creature is dead.
+
+ P_SP
+ Spellpoints (sometimes called mana) describe the magical
+ (spiritual) capability of the creature. It is mainly
+ determined by Intelligence and Wisdom. It is up to the
+ creature how good it uses the spellpoint resource.
+ Spellpoints will go down when supernatural actions are
+ performed by the creature.
+
+ P_MAX_SP, P_MAX_HP
+ Readonly variable which are computed from attributes.
+
+ P_FOOD, P_DRINK, P_ALCOHOL, (P_POISON)
+ These three variables describe hunger, thirst and
+ intoxication by alcohol. The max is dependent on the
+ constitution of the living, and of the weight.
+ These variables automatically decrease with time.
+ When food or drink goes below zero, the creature
+ suffers hunger or thirst and will lose hitpoints.
+
+ P_MAX_FOOD, P_MAX_DRINK, P_MAX_ALCOHOL
+ Readonly variables which are computed from attributes.
+
+ P_WEIGHT, P_SIZE
+ These variables describe the physical proportions of
+ the creatures body. Both variables are standard properties
+ and are also used in normal objects.
+
+ P_MAX_WEIGHT
+ This is a readonly variable which describes how much
+ a living creature may carry around.
+
+ P_GENDER
+ This is obvious. Gender may be MALE, FEMALE or NEUTER,
+ as defined in <living.h>. Player gender may be only
+ MALE or FEMALE.
+
+ P_RACE
+ A string which defines the race.
+
+ P_ALIGNMENT
+ The alignment of the living, ranging frO
+
+ P_AGE
+ The age of the living creature in seconds
+
+
+INHERITANCE TREE:
+ living
+ |-thing/moving
+ |-thing/properties
+ `-thing/description
+
+
+SEE ALSO:
+ properties(C), units(C)
diff --git a/doc/std/obsolete/door b/doc/std/obsolete/door
new file mode 100644
index 0000000..15bad30
--- /dev/null
+++ b/doc/std/obsolete/door
@@ -0,0 +1,22 @@
+****************************************************************************
+************************* VERALTETE LFUN ***********************************
+************************* DO NOT USE! ***********************************
+****************************************************************************
+
+BITTE STATT DER FUNKTION Door() IMMER NewDoor() BENUTZEN.
+
+ AddDoor(string command, string roomfile, string doorname,
+ string doordesc, string keyname, int status)
+ Creates a door which leads in direction <command> to the
+ room <roomfile>. The door has the short description
+ <doorname> and the long description <doordesc>, when you
+ look at it. If a door with the same <doorname> exists in
+ the other room, the open/close/locked status will be
+ the same in both rooms at all time. Doors are locked on
+ reset() if keyname is not 0. If <keyname> is given, the
+ door is locked and can be opened only with a key which
+ matches <keyname> with its id(). <status> can be set
+ to an initial value of DOOR_STATUS_OPEN, DOOR_STATUS_CLOSED
+ or DOOR_STATUS_LOCKED. These status codes are defined in
+ <doors.h>.
+
diff --git a/doc/std/pub b/doc/std/pub
new file mode 100644
index 0000000..21544a7
--- /dev/null
+++ b/doc/std/pub
@@ -0,0 +1,95 @@
+Um die Funktionalitaet einer Kneipe nutzen zu koennen, muss der Raum eine
+der folgenden Dateien importieren:
+
+'/std/pub.c' - die Komplettloesung inclusive der Abhaengigkeit zu
+ '/std/room'
+
+'/std/room/pub.c' - die Mindestloesung, bei der man selbst die Abhaengig-
+ keit zu einem Raum definieren muss
+
+------------------------------------------------------------------------------
+Eine Zusammenfassung der Pub-Properties (fuer genaueres siehe manpages)
+aus '/sys/pub.h'
+
+P_NPC_FASTHEAL - NPCs tanken hier auf die "schnelle" Art
+
+P_NO_STD_DRINK - Der Pub soll keine Standard-Getraenke anbieten
+
+P_PUB_UNAVAILABLE - Meldung, wenn etwas nicht mehr vorhanden ist
+
+P_PUB_NOT_ON_MENU - Meldung, wenn etwas nicht im Menue steht
+
+P_PUB_NO_MONEY - Meldung, wenn Spieler nicht genug Geld hat
+
+P_PUB_NO_KEEPER - Meldung, wenn der P_KEEPER nicht anwesend ist
+
+aus '/sys/room/description.h'
+
+P_KEEPER - Id des Kneipeninhabers, der anwesend sein muss,
+ damit die Kneipe genutzt werden kann
+
+------------------------------------------------------------------------------
+Methoden zur Manipulation des Menues (fuer genaueres siehe manpages)
+
+AddToMenu - fuegt einen Eintrag zum Menue hinzu
+
+RemoveFromMenu - entfernt einen Eintrag aus dem Menue
+
+------------------------------------------------------------------------------
+Ablauf und Manipulationsmoeglichkeiten in einer Kneipe
+
+Wunsch wurde ueber 'kaufe', 'bestelle' oder 'spendiere' abgegeben:
+
+search_what() - prueft, dass nicht mehrere Wuensche auf einmal
+ geaeussert werden und ruft consume_something() auf
+
+consume_something() - prueft die Anwesenheit der beteiligten Personen
+ - prueft die Anwesenheit des Kneipenbesitzers
+ - prueft das Ignorieren beim Spendieren
+ - prueft die Verfuegbarkeit von genuegend Geld beim
+ Besteller ( check_solvency() )
+ - prueft die Verfuegbarkeit des Gewuenschten
+ ( CheckAvailability() )
+ - prueft, ob der Empfaenger in der Lage ist, das
+ Bestellte zu konsumieren
+ ( ueber empfaenger->consume(testonly) )
+
+ - fuehrt die Bezahlung durch ( do_pay() )
+ - fuehrt die Vergabe von FPs durch ( GiveEP() )
+ - entnimmt das Bestellte aus der Menge des Angebotes
+ ( DecreaseAvailibility() )
+ - prueft, ob eine Verzoegerung der Lieferung erfolgen
+ soll und uebergibt im Negativfall gleich an
+ do_deliver()
+ - Ausgabe der Meldungen zur Bestellung
+ - verzoegerter Aufruf von do_deliver()
+
+do_deliver() - prueft nochmal die Anwesenheit des Empfaengers
+ - prueft, ob Heilung erlaubt ist (ueber Pubmaster)
+ - prueft P_NPC_FASTHEAL und korrigiert die Angaben, die
+ aus dem Menueeintrag kommen
+ - fuehrt das Konsumieren beim Empfaenger durch
+ ( empfaenger->consume() )
+ - Ausgabe der Meldung zum Konsumieren
+
+pub_init() - Moeglichkeit fuer Magier, die Werte der angebotenen
+ Speisen und Getraenke zu ueberpruefen
+ - erweiterte Moeglichkeiten zum Pruefen von korrekten
+ Menueeintraegen bietet das Pub-Tool
+ ( '/obj/tools/pubtool.c' )
+
+Hinweis: Um diese Pruefungen und Aktionen sicher zu gewaehrleisten, sollte
+ man consume_something oder do_deliver NICHT ueberschreiben!
+ Das fuehrt bei Aenderungen mit grosser Wahrscheinlichkeit zu
+ Problemen!
+ Ueberschreibt besser die Methoden, die die Funktionalitaet
+ beinhaltet, die ihr wirklich anpassen wollt.
+ Falls das nicht geht, sprecht lieber mit einem RM+, ob eine Loesung
+ dafuer gefunden werden kann. Der Standard-Pub wurde in der
+ Vergangenheit so immer modularer und besser.
+
+
+SIEHE AUCH: AddToMenu, RemoveFromMenu, consume, QueryMoney, AddMoney
+
+------------------------------------------------------------------------------
+Last modified: Son Apr 11 19:28:00 2010 by Caldra
diff --git a/doc/std/random b/doc/std/random
new file mode 100644
index 0000000..489214d
--- /dev/null
+++ b/doc/std/random
@@ -0,0 +1,71 @@
+Es gibt im MG zwei Quellen von Pseudo-Zufallszahlen.
+
+1) random()
+ Diese efun liefert eine Zufallszahl aus dem Pseudo-Zufallszahlengenerator
+ (PRNG) des Drivers. (s. Manpage).
+ Wenn keine besonderen Gruenden vorliegen, sollte immer diese verwendet
+ werden.
+
+
+2) /std/util/rand-glfsr.c
+ Falls jemand aus irgendeinem Grund eine Sequenz von Pseudo-Zufallszahlen
+ braucht, die spaeter reproduzierbar sein soll (d.h. der Seed muss
+ konfigurierbar sein), gibt es unter /std/util/rand-glfsr.c einen simplen,
+ nicht allzu guten und sehr ineffizienten Pseudo-Zufallszahlengenerator.
+
+Interface:
+* public varargs void init(int seed, int newp)
+ Setzt das Seed (und das Erzeugungspolynom, wenn gewuenscht, wovon ich
+ aber abraten wuerde). Der Seed darf nicht 0 sein.
+* public void InitWithUUID(string uuid)
+ Berechnet einen Seed aus der uuid und initialisiert den PRNG damit (und dem
+ Default-Polynom).
+* public int nextbit()
+ Liefert ein zufaelliges Bit (also 0 oder 1).
+* public int nextbits(int count)
+ Liefert <count> Bits (max 64) in einem int.
+* public int random(int n)
+ Liefert eine Zufallszahl zwischen 0 und n-1, in welcher 32 bits an
+ Pseudozufall stecken.
+ Das Seed von der Blueprint wird vermutlich staendig veraendert (d.h.
+ verlasst euch nicht drauf, dass es konstant bleibt), wollt ihr eine
+ 'private' Instanz mit eurem Seed, clont das Objekt (aber verliert den Clone
+ nicht).
+
+ Und um es nochmal zu sagen:
+ Die IMHO einzige sinnvolle Anwendung ist, wenn man aus irgendeinem Grund
+ das seed selber waehlen muss, damit man die Sequenz von Pseudozufall immer
+ wieder reproduzieren kann.
+ In allen anderen Faellen nehmt besser das random() vom Driver.
+
+Der PRNG benutzt ein Linear Feedback Shift Register (in Galois-Variante). Die
+Periodenlaenge des per Default benutzten Erzeugngspolynoms ist 2^32 - 1, d.h.
+nach 4294967295 Bits wiederholt sich die Sequenz.
+Das Default-Polynom ist:
+x^32 + x^31 + x^28 + x^27 + x^24 + x^23 + x^20 + x^19 + x^16 + x^15 + x^12
+ + x^11 + x^8 + x^7 + x^5 + x^3 + 1
+(Zahlenwert: 0x1999999a8)
+
+Wer ein anderes Polynom will, kann das per init() konfigurieren, sollte sich
+aber schlau machen, welche sinnvoll nutzbar sind.
+
+
+Ein paar statistische Daten eines Stroms von 40960 Bits:
+Value Char Occurrences Fraction
+ 0 20474 0.499854
+ 1 20486 0.500146
+
+Total: 40960 1.000000
+
+Entropy = 1.000000 bits per bit.
+
+Optimum compression would reduce the size
+of this 40960 bit file by 0 percent.
+
+Chi square distribution for 40960 samples is 0.00, and randomly
+would exceed this value 95.27 percent of the times.
+
+Arithmetic mean value of data bits is 0.5001 (0.5 = random).
+Monte Carlo value for Pi is 3.109026964 (error 1.04 percent).
+Serial correlation coefficient is -0.008399 (totally uncorrelated = 0.0).
+
diff --git a/doc/std/room b/doc/std/room
new file mode 100644
index 0000000..94e575f
--- /dev/null
+++ b/doc/std/room
@@ -0,0 +1,143 @@
+STANDARDOBJEKT FUER RAEUME:
+
+BENUTZUNG:
+ inherit "/std/room";
+
+ #include <properties.h>
+ #include <rooms.h> // Fuer AddItem() und NewDoor()
+
+BESCHREIBUNG:
+ Ein Raum ist ein Objekt, das von Spielern oder anderen Lebewesen
+ betreten werden kann. Er hat Lang- und Kurzbeschreibungen von
+ innen und aussen (zum Beispiel Schiffe oder aehnliche Raeume in
+ Raeumen), die sich der Spieler je nach seinen Beduerfnissen
+ anzeigen lassen kann (kurz/lang-Modus).
+
+ Properties:
+
+ P_INT_SHORT
+ Kurzbeschreibung innerhalb des Raumes
+ P_INT_LONG
+ Langbeschreibung innerhalb des Raumes
+ P_SHORT
+ Kurzbeschreibung von aussen (nur noetig, wenn man den Raum
+ auch wirklich von aussen sehen kann)
+ P_LONG
+ Langbeschreibung von aussen (siehe P_SHORT)
+ Um Situationsbezogene Beschreibungen zu bekommen, kann man
+ Querymethoden auf die jeweiligen Properties setzen, siehe Dokumentation
+ zu Set().
+
+ P_LIGHT
+ Lichtlevel des Raums (0 dunkel, 1 hell)
+ P_LIGHT_TYPE
+ Lichtart, mit der der Raum beleuchtet ist, zB LT_SUNLIGHT
+ P_INDOORS
+ Wenn es sich um einen Aussenraum handelt, 0. 1 fuer Innenraeume.
+ P_TRANSPARENT
+ Ist ungleich 0, wenn man in den Raum von aussen reinschauen
+ kann, oder von innen nach aussen
+ P_NO_TPORT
+ Zum verhindern von Teleportversuchen in oder aus dem Raum
+ P_NOMAGIC
+ Im Raum kann nicht gezaubert werden.
+ P_WATER
+ Im Raum kann geangelt werden, und man kann ggf. sogar Fische fangen.
+
+ Funktionen:
+
+ AddExit(string|string* kmnd, string zielraum)
+ <kmnd> kann ein String sein oder eine Liste von Strings
+ mit den Kommandos mit denen der Spieler in <zielraum>
+ landen soll.
+ RemoveExit(string|string* kmnd)
+ <kmnd> ist ein String oder eine Liste von Strings, deren
+ Ausgaenge entfernt werden sollen. Dabei muss man etwas vor-
+ sichtig sein, da ein Spieler, der zum Zeitpunkt des Aufrufs
+ im Raum ist, die Aktion fuer sich noch definiert hat.
+ Also: Nur benutzen, wenn man weiss, was man tut!
+ AddSpecialExit(string|string* kmnd, string funktion)
+ <funktion> wird aufgerufen, wenn der Spieler das Kommando
+ <kmnd> tippt (oder eins der Kommandos, wenn <kmnd> eine
+ Liste ist). Nuetzlich zum Beispiel um einen Spieler nur
+ durchzulassen, wenn ein Waechter nicht da ist.
+ P_AERIAL_HELPERS/P_AQUATIC_HELPERS
+ Sollte es gewuenscht sein, dass bestimmte Raeume z.B. nur
+ fliegend erreicht werden koennen, oder dass man fuer einen
+ bestimmten Ausgang tauchen koennen muss, sind diese
+ Properties hilfreich, die im Spielerobjekt definiert sind
+ und die dort aktuell registrierten Hilfsobjekte fuers
+ Fliegen/Segeln und Tauchen enthalten.
+ RemoveSpecialExit(string|string* kmnd)
+ siehe RemoveExit()
+ NewDoor()
+ Fuegt dem Raum eine Tuer hinzu, die in einen zweiten Raum fuehrt,
+ und die der Spieler (ggf. mit einem Schluessel) oeffnen und
+ schliessen kann.
+
+ Um Raeume interessanter zu machen, kann man ihnen Details, die
+ vom Spieler angeschaut werden koennen, einbauen:
+
+ AddDetail(string|string* keys, string descr)
+ Eine Beschreibung von Details, die vom Spieler angeschaut
+ werden koennen wird dem Raum gegeben. <keys> kann ein
+ String sein oder eine Liste von Strings. <descr> ist
+ die Beschreibung, die der Spieler erhaelt.
+ RemoveDetail(string|string* keys)
+ Entfernt ein Detail aus einem Raum. <keys> kann ein String
+ sein oder eine Liste von Strings.
+ AddSpecialDetail(string|string* keys, string function)
+ Im Prinzip wie AddDetail(), nur wird als zweites Argument
+ kein fester String angegeben, sondern eine Funktion, die
+ einen String zurueckgeben muss. Damit kann man variable
+ Details programmieren.
+ RemoveSpecialDetail(string|string* keys)
+ siehe RemoveDetail()
+ AddReadDetail(string|string* keys, string desc)
+ <desc> wird ausgegeben, wenn ein Spieler den <key> liest.
+ <keys> kann wieder ein String oder eine Liste von Strings
+ sein.
+ RemoveReadDetail(string|string* keys)
+ siehe RemoveDetail()
+ AddRoomMessage(string* msg, int prob, string|mixed *func)
+ Alle <prob> Sekunden wird aus einer Liste von Meldungen
+ (<msg>) zufaellig eine ausgesucht, die dann im Raum er-
+ scheint. Wenn das Argument <func> angegeben ist, wird
+ eine Funktion diesen Namens aufgerufen, der der Index
+ der ausgegebenen Meldung als Argument uebergeben wird.
+ Func darf auch einen Array von Funktionen enthalten.
+
+ AddCmd(string|string* cmd, string func, int flag)
+ Im Raum wird beim Kommando <cmd> (oder einem der Kommandos)
+ die Funktion <func> aufgerufen. <func> muss 1 zurueck-
+ geben, wenn die Funktion die Kombination aus Kommando
+ und Argumenten akzeptiert, ansonsten 0. Alles was ein
+ Spieler hinter <cmd> noch angibt, wird der Funktion als
+ Argument uebergeben. Wenn <flag> gesetzt ist, wird jedes
+ Kommando, das mit <cmd> beginnt akzeptiert.
+ RemoveCmd(string|string* cmd)
+ Entfernt ein Kommando aus dem Raum.
+ ACHTUNG: Bei Spielern, die zum Zeitpunkt des Funktions-
+ aufrufs noch im Raum sind, ist das Kommando noch definiert.
+ Also: Nur benutzen, wenn man genau weiss, was man tut.
+
+ AddItem(string filename, int refresh)
+ Ein Objekt mit Pfad <filename> wird erzeugt und in den
+ Raum bewegt, dabei gibt es vier verschiedene Modi, die
+ ueber das Argument <refresh> angegeben werden:
+ REFRESH_NONE: Das Objekt wird nur beim allerersten mal
+ erzeugt, und dann nie wieder (erst beim reboot)
+ REFRESH_DESTRUCT: Ein neues Objekt wird erst erzeugt,
+ wenn das alte zerstoert ist. So kann man sicher
+ gehen, dass nur ein Exemplar im Spiel ist.
+ REFRESH_REMOVE: Beim reset wird ein neues Objekt erzeugt,
+ wenn sich das alte nicht mehr im Raum befindet.
+ REFRESH_ALWAYS: Bei jedem reset wird ein neues Objekt
+ erzeugt. VORSICHT: Kann zu riesigen Mengen von
+ Objekten fuehren, wenn ein Raum lange nicht be-
+ sucht wird.
+ Die Konstanten REFRESH_* sind in <rooms.h> definiert.
+
+ Auf die Properties P_EXITS, P_SPECIAL_EXITS, P_DETAILS,
+ P_SPECIAL_DETAILS, P_READ_DETAILS, P_COMMANDS und P_ITEMS
+ sollte NICHT direkt zugegriffen werden.
diff --git a/doc/std/room.doku b/doc/std/room.doku
new file mode 100644
index 0000000..e1774c6
--- /dev/null
+++ b/doc/std/room.doku
@@ -0,0 +1,132 @@
+STANDARDOBJEKT FUER RAEUME:
+
+BENUTZUNG:
+ inherit "std/room";
+
+ #include <properties.h>
+ #include <rooms.h> // Fuer AddItem() und NewDoor()
+
+BESCHREIBUNG:
+ Ein Raum ist ein Objekt, dass von Spielern oder anderen Lebewesen
+ betreten werden kann. Er hat Lang- und Kurzbeschrreibungen von
+ innen und aussen (zum Beispiel Schiffe oder aehnliche Raeume in
+ Raeumen), die sich der Spieler je nach seinen Beduerftnissen
+ anzeigen lassen kann (kurz/lang-Modus).
+
+ Properties:
+
+ P_INT_SHORT
+ Kurzbeschreibung innerhalb des Raumes
+ P_INT_LONG
+ Langbeschreibung innerhalb des Raumes
+ P_SHORT
+ Kurzbeschriebung von aussen (nur noetig, wenn man den Raum
+ auch wirklich von aussen sehen kann)
+ P_LONG
+ Langbeschreibung von aussen (siehe P_SHORT)
+ Um Situationsbezogene Beschreibungen zu bekommen, kann man
+ int_short(), int_long(), short(), long() ueberschreiben, oder
+ den process_string Mechanismus verwenden (siehe entsprechende
+ Dokumentation)
+
+ P_LIGHT
+ Lichtlevel des Raums (0 dunkel, 1 hell)
+ P_INDOORS
+ 1 Wenn der Raum nicht im Freien ist
+ P_TRANSPARENT
+ Ist ungleich 0, wenn man in den Raum von aussen reinschauen
+ kann, oder von innen nach aussen
+ P_NO_TPORT
+ Zum verhindern von Teleportversuchen in oder aus dem Raum
+ (siehe auch /doc/properties.h)
+ P_NOMAGIC
+ Im Raum kann nicht gezaubert werden.
+
+ Funktionen:
+ AddExit(string|string* kmnd, string zielraum)
+ <kmnd> kann ein String sein oder eine Liste von Strings
+ mit den Kommandos mit denen der Spieler in <zielraum>
+ landen soll.
+ RemoveExit(string|string* kmnd)
+ <kmnd> ist ein String oder eine Liste von Strings, deren
+ Ausgaenge entfernt werden sollen. Dabei muss man etwas vor-
+ sichtig sein, da ein Spieler, der zum Zeitpunkt des Aufrufs
+ im Raum ist, die Aktion fuer sich noch definiert hat.
+ Also: Nur benutzen, wenn man weiss, was man tut!
+ AddSpecialExit(string|string* kmnd, string funktion)
+ <funktion> wird aufgerufen, wenn der Spieler das Kommando
+ <kmnd> tippt (oder eins der Kommandos, wenn <kmnd> eine
+ Liste ist). Nuetzlich zum Beispiel um einen Spieler nur
+ durchzulassen, wenn ein Waechter nicht da ist.
+ RemoveSpecialExit(string|string* kmnd)
+ siehe RemoveExit()
+ NewDoor()
+ siehe /doc/std/door
+
+ Um Raeume interessanter zu machen, kann man ihnen Details, die
+ vom Spieler angeschaut werden koennen, einbauen:
+
+ AddDetail(string|string* keys, string descr)
+ Eine Beschreibung von Details, die vom Spieler angeschaut
+ werden koennen wird dem Raum gegeben. <keys> kann ein
+ String sein oder eine Liste von Strings. <descr> ist
+ die Beschreibung, die der Spieler erhaelt.
+ RemoveDetail(string|string* keys)
+ Entfernt ein Detail aus einem Raum. <keys> kann ein String
+ sein oder eine Liste von Strings.
+ AddSpecialDetail(string|string* keys, string function)
+ Im Prinzip wie AddDetail(), nur wird als zweites Argument
+ kein fester String angegeben, sonder eine Funktion, die
+ einen String zurueckgeben muss. Damit kann man variable
+ Details programmieren.
+ RemoveSpecialDetail(string|string* keys)
+ siehe RemoveDetail()
+ AddReadDetail(string|string* keys, string desc)
+ <desc> wird ausgegeben, wenn ein Spieler den <key> liest.
+ <keys> kann wieder ein String oder eine Liste von Strings
+ sein.
+ RemoveReadDetail(string|string* keys)
+ siehe RemoveDetail()
+ AddRoomMessage(string* msg, int prob, string|string *func)
+ Alle <prob> Sekunden wird aus einer Liste von Meldungen
+ (<msg>) zufaellig eine ausgesucht, die dann im Raum er-
+ scheint. Wenn das Argument <func> angegeben ist, wird
+ eine Funktion diesen Namens aufgerufen, der der Index
+ der ausgegebenen Meldung als Argument uebergeben wird.
+ func darf auch einen Array von Funktionen enthalten. Es wird
+ dann zufaellig eine ausgewaehlt.
+
+ AddCmd(string|string* cmd, string func, int flag)
+ Im Raum wird beim Kommando <cmd> (oder einem der Kommandos)
+ die Funktion <func> aufgerufen. <func> muss 1 zurueck-
+ geben, wenn die Funktion die Kombination aus Kommando
+ und Argumenten akzeptiert, ansonsten 0. Alles was ein
+ Spieler hinter <cmd> noch angibt, wird der Funktion als
+ Argument uebergeben. Wenn <flag> gesetzt ist, wird jedes
+ Kommando, das mit <cmd> beginnt akzeptiert.
+ RemoveCmd(string|string* cmd)
+ Entfernt ein Kommando aus dem Raum.
+ ACHTUNG: Bei Spielern, die zum Zeitpunkt des Funktions-
+ aufrufs noch im Raum sind, ist das Kommando noch definiert.
+ Also: Nur benutzen, wenn man genau weiss, was man tut.
+
+ AddItem(string filename, int refresh)
+ Ein Objekt mit Pfad <filename> wird erzeugt und in den
+ Raum bewegt, dabei gibt es vier verschiedene Modi, die
+ ueber das Argument <refresh> angegeben werden:
+ REFRESH_NONE: Das Objekt wird nur beim allerersten mal
+ erzeugt, und dann nie wieder (erst beim reboot)
+ REFRESH_DESTRUCT: Ein neues Objekt wird erst erzeugt,
+ wenn das alte zerstoert ist. So kann man sicher
+ gehen, dass nur ein Exemplar im Spiel ist.
+ REFRESH_REMOVE: Beim reset wird ein neues Objekt erzeugt,
+ wenn sich das alte nicht mehr im Raum befindet.
+ REFRESH_ALWAYS: Bei jedem reset wird ein neues Objekt
+ erzeugt. VORSICHT: Kann zu riesigen Mengen von
+ Objekten fuehren, wenn ein Raum lange nicht be-
+ sucht wird.
+ Die Konstanten REFRESH_* sind in <rooms.h> definiert.
+
+ Auf die Properties P_EXITS, P_SPECIAL_EXITS, P_DETAILS,
+ P_SPECIAL_DETAILS, P_READ_DETAILS, P_COMMANDS und P_ITEMS
+ sollte NICHT direkt zugegriffen werden.
diff --git a/doc/std/schluessel b/doc/std/schluessel
new file mode 100644
index 0000000..5a23db2
--- /dev/null
+++ b/doc/std/schluessel
@@ -0,0 +1,24 @@
+STANDARDOBJEKT FUER SCHLUESSEL:
+
+BENUTZUNG
+ inherit "/d/unterwelt/std/schluessel"
+
+BESCHREIBUNG
+ Du erzeugst einen Schluessel der nur auf eine bestimmte Tuer
+ passt.
+
+ Funktionen:
+
+ create():
+ setzt ein paar Defaultwerte.
+
+ SetDoorKey( string str):
+ gibt den Schluessel eine spezielle Beschreibung, die
+ auf die Tuer passen muss.
+
+ QueryDoorKey()
+ fragt den string des Schluessels ab.
+
+SIEHE AUCH:
+ tuer
+
diff --git a/doc/std/sequencer b/doc/std/sequencer
new file mode 100644
index 0000000..d9b17a3
--- /dev/null
+++ b/doc/std/sequencer
@@ -0,0 +1,58 @@
+Version 2.0 des Sequencers von Don Rumata 2.7.93
+
+Manchmal soll ein NPC (Monster) eine Serie von Taetigkeiten
+hintereinander weg ausgefuerht werden. Dieses kann man
+mit diesem Mudul relativ einfach realisieren.
+
+Folgende Ereignisse koennen eine Sequenz ausloesen:
+
+ TellEvent: Es wird etwas in dem Raum, in dem der npc sich
+ befindet, gesagt.
+ GiveEvent: Es wird dem npc etwas gegeben.
+
+Weitere Ereignisse koennen durch den Befehl Load() selber
+programmiert werden.
+
+Wie sieht ein Programm aus?
+
+ Ein Programm ist eine Liste von Befehlen.
+ Jeder Befehl ist eine Liste, bestehend aus einem Kommando
+ und einer Zahl.
+ Das Kommendo wird aehnlich der Befehle, die ein Spieler ein-
+ gibt ausgefuehrt.
+ Vorsicht: NPCs koennen nur einen Teil der Befehle, die ein
+ Spieler kann, dafuer aber immer 'echo' und 'emote'.
+ Die Zahl gibt die Anzahl der Sekunden an, in der der naechste
+ Befehl ausgefuehrt wird.
+
+Folgende Funktionen sind im Modul implementiert:
+
+ Vorbereiten von Funktionen, die eine Sequenz ausloesen:
+
+ RegisterTell( funktion, programm )
+ Wenn dem npc etwas gesagt wird, so wird die gesagte Meldung
+ an die Funktion uebergeben. Gibt die Funktionen nicht 0
+ zurueck, wird das Programm gestartet.
+
+ RegisterGive( funktion, programm )
+ Wird dem npc etwas gegeben, so wird das Objekt an die
+ Funktion uebergeben. Gibt die Funktion nicht 0 zurueck, so
+ wird das Programm gestartet.
+
+ Load( programm )
+ Starte das angegebene Programm.
+
+Anederungen an bestehenden Std-Funktionen:
+
+ give_notify() gibt eine 1 zurueck, wenn das Objekt akzeptiert
+ wurde. (Es muss - falls gewuenscht - dann von Hand zuruech-
+ gegeben werden. (give_obj(ob,this_player())) in dieser
+ Funktion.
+
+ Mittels add_action() kann man im create() des NPCs eigene
+ Verben fuer den NPC einfuehren.
+
+Es kann immer nur eine Funktion (egal ob via Tell, Give oder Load) angemeldet
+sein. Es kann immer nur ein Programm gleichzeitig laufen.
+
+Ideen und Bugreports an Rumata
diff --git a/doc/std/thing b/doc/std/thing
new file mode 100644
index 0000000..445b462
--- /dev/null
+++ b/doc/std/thing
@@ -0,0 +1,205 @@
+STANDARD KLASSE:
+ "/std/thing"
+
+BENUTZUNG:
+ inherit "/std/thing";
+
+ #include <thing.h>
+ #include <properties.h>
+
+PROPERTIES:
+ <thing/commands>
+ P_COMMANDS -- Befehle assoziiert mit dem Objekt
+ <thing/description>
+ P_NAME -- Name
+ P_NAME_ADJ -- Namensadjektiv
+ P_SHORT -- Kurzbeschreibung
+ P_LONG -- Langbeschreibung
+ P_IDS -- Identifikatoren (Feld von Zeichenketten)
+ P_ADJECTIVES -- Adjektive zur Beschreibung
+ <thing/language>
+ P_ARTICLE -- Artikel des Objekts
+ P_GENDER -- Geschlecht des Objekts
+ <thing/moving>
+ P_NODROP -- Kann nicht fallengelassen werden
+ P_NOGET -- Kann nicht genommen werden
+ <thing/properties>
+ P_UID -- User ID
+ P_EUID -- Effektive User ID
+ <thing/restrictions>
+ P_WEIGHT -- Gewicht des Objekts
+ P_TOTAL_WEIGHT -- Gewicht inklusive des Inhalts
+
+MAKROS:
+ <thing/properties>
+ F_VALUE -- Propertywert
+ F_MODE -- Propertymodus umschalten
+ F_MODE_AS -- Propertymodus setzen
+ F_MODE_AD -- Propertymodus loeschen
+ SAVE -- Property wird gespeichert
+ PROTECTED -- Property is geschuetzt
+ SECURED -- Property kann nie mehr geaendert werden
+ NOSETMETHOD -- Property besitzt keine Setzfunktion
+ F_SET_METHOD -- Funktion zum setzen der Property
+ F_QUERY_METHOD -- Funktion zum lesen der Property
+ <thing/language>
+ MALE, FEMALE, NEUTER -- Geschlechter
+ WER, WESSEN, WEM, WEN -- Fall
+ RAW -- fuer Namen ohne Artikel
+ SINGULAR, PLURAL -- Zeiten
+
+FUNKTIONEN:
+ "/std/thing/commands":
+ varargs void AddCmd(mixed cmd, mixed func, int flag);
+ varargs void RemoveCmd(mixed cmd);
+ "/std/thing/description":
+ varargs int id(string str, int lvl);
+ void AddId(mixed str);
+ void AddAdjective(mixed str);
+ string name(int casus,int demon);
+ "/std/thing/language":
+ varargs string QueryArticle(int casus, int dem, int force);
+ varargs int SuggestArticle(string id);
+ varargs string QueryPossPronoun(mixed what, int casus,
+ int number);
+ string QueryPronoun(int casus);
+ varargs string QueryDu(int casus,int gender, int zahl);
+ string QueryGenderString();
+ varargs string DeclAdj(string adj, int casus, int demon);
+ "/std/thing/properties":
+ varargs mixed Set(string name, mixed Value, int Type);
+ varargs mixed Query(string name, int Type);
+ mixed SetProp(string name, mixed Value);
+ mixed QueryProp(string name);
+ void SetProperties(mapping props);
+ mapping QueryProperties();
+ "/std/thing/moving":
+ int move(mixed dest,int method);
+ varargs int remove();
+
+ERLAEUTERUNG:
+ "/std/thing" ist eine generelle Klasse fuer Objekte aller Art.
+ Es bietet generelle Funktionalitaet zur Erstellung von neuen
+ Klassen und Objekten. Sie kann mittels der zur Verfuegung
+ stehenden Funktionen konfiguriert werden:
+
+ ** "/std/thing/commands":
+ varargs void AddCmd(mixed cmd, mixed func, int flag);
+ Um dem Objekt die Moeglichkeit zu geben, auf Befehle zu reagieren,
+ kann mit AddCmd() Kommandos definiert werden, die eine bestimmte
+ Funktion (func) aufrufen. flag entscheidet darueber, ob das Kommando
+ (cmd) abgekuerzt werden kann (flag = 1) oder nicht (flag = 0).
+
+ varargs void RemoveCmd(mixed cmd);
+ Man kann die Kommandos jederzeit wieder mit der Funktion RemoveCmd()
+ entfernen.
+
+ ** "/std/thing/description":
+ varargs int id(string str, int lvl);
+ Die Funktion id() behandelt die Identifikatoren eines Objektes,
+ welche in der Property P_IDS gespeichert sind. Jedesmal, wenn ein
+ Objekt durch Kommandos wie "nimm", "lass fallen" etc referenziert
+ werden soll, wird id() mit dem Namen des Objektes aufgerufen. Dabei
+ werden dann die Elemente von P_IDS mit str verglichen und das Ergeb-
+ nis (WAHR/FALSCH == 1/0) zurueckgegeben. lvl ist fuer die Behandlung
+ von Lebewesen notwendig, siehe living.
+
+ void AddId(mixed str);
+ Mittels dieser Funktion kann ein oder mehrere neue Identifikatoren
+ der Liste der bestehenden, Standard ist "ding", hinzugefuegt werden.
+
+ void AddAdjective(mixed str);
+ Um den Objekten die Moeglichkeit zu geben, sich besser zu beschreiben
+ oder zur besseren Identifizierung, kann man mit AddAdjective() dem
+ Objekt naeher beschreibende Adjektive hinzufuegen. Diese sind in
+ P_ADJECTIVES gespeichert.
+
+ string name(int casus,int demon);
+ Diese Funktion liefert den Namen des Objektes mit allen zusaetzlichen
+ Attributen im gewuenschten Fall (casus), demonstrativ (demon = 1)
+ oder nicht demonstrativ (demon = 0).
+
+ ** "/std/thing/language":
+ varargs string QueryArticle(int casus, int dem, int force);
+ Artikel im passenden Fall sowie demonst. bzw undemonst. zurueck-
+ geben. force ueberschreibt das SetArticle-Flag.
+
+ varargs int SuggestArticle(string id);
+ Empfehle einen Artikel fuer das Objekt, getestet wird, ob ausser
+ diesem Objekt sich ein anderes Objekt mit der id im selben
+ Raum befindet.
+
+ varargs string QueryPossPronoun(mixed what, int casus, int number);
+ Gib ein Pronomen zurueck, das ausdrueckt, das ein Objekt diesem
+ Objekt gehoert. Dabei ist what das Geschlecht des Objektes.
+
+ string QueryPronoun( casus );
+ Er/Sie/Es u.ae. zurueckgeben.
+
+ varargs string QueryDu(int casus,int gender, int zahl);
+ Du im passenden Fall zurueckgeben (siehe QueryArticle()).
+
+ string QueryGenderString();
+ Gibt das Geschlecht in Worten zurueck.
+
+ varargs string DeclAdj(string adj, int casus, int demon);
+ Dekliniere Adjektive adj mit Casus casus.
+
+ ** "/std/thing/properties":
+ varargs mixed Set(string name, mixed Value, int Type);
+ Setze einen Wert einer Property direkt, wobei der Typ des Wertes
+ (Value) durch F_VALUE, F_MODE, F_SET_METHOD, F_QUERY_METHOD (Type)
+ angegeben wird.
+ F_VALUE -- darf ein beliebiger Wert sein
+ F_MODE -- muss eine Zahl sein (SAVE, PROTECTED, SECURED,
+ NOSETMETHOD)
+ F_SET_METHOD, F_QUERY_METHOD -- 0 oder eine Closure
+
+ varargs mixed Query(string name, int Type);
+ Lies den Wert einer Property aus. Dabei gibt Type an, welchen Wert
+ (F_VALUE, F_MODE, F_SET_METHOD, F_QUERY_METHOD) man auslesen will.
+
+ mixed SetProp(string name, mixed Value);
+ Setze den Wert einer Property. Dabei wird, falls vorhanden, der Wert
+ noch durch die F_SET_METHOD behandelt (z.B. Typueberpruefung).
+ Dies sollte die Standardmethode zum Setzen einer Property sein!
+
+ mixed QueryProp(string name);
+ Lies den Wert einer Property, wobei der eigentliche Wert durch die,
+ falls vorhanden, F_QUERY_METHOD behandelt wird. Als Beispiel dient
+ hier die Behandlung des Gesamtgewichts, welches durch Abfragen von
+ P_TOTAL_WEIGHT ausgelesen werden kann; hierbei errechnet die
+ F_QUERY_METHOD von P+_TOTAL_WEIGHT erst das totale Gewicht.
+ Dies sollte die Standardmethode sein um eine Property auszulesen!
+
+ void SetProperties(mapping props);
+ Diese Funktion kann die in props gespeicherten Properties im Objekt
+ unterbringen. Dabei werden schon vorher als PROTECTED oder SECURED
+ gekennzeichnete Properties NICHT ueberschrieben.
+
+ mapping QueryProperties();
+ Liefert ein mapping, welches von SetProperties() behandelt werden
+ kann.
+
+ ** "/std/thing/moving":
+ int move(mixed dest,int method);
+ Jedesmal, wenn ein Objekt bewegt werden soll, wird die Funktion
+ move() aufgerufen, welche dann das eigentliche Bewegen ausfuehrt.
+ Dazu muss der Funktion ein Ziel (dest) als Zeichenkette oder als
+ Objekt und eine Methode der Bewegung uebergeben werden.
+
+ varargs int remove();
+ Wird ein Objekt zerstoert, wird die Funktion remove() aufgerufen.
+ Rueckgabewert 1 bedeutet Erfolg und 0 Misserfolg der Zerstoerung.
+
+VERERBUNGSBAUM:
+ thing
+ |-thing/commands
+ |-thing/description
+ |-thing/language
+ |-thing/moving
+ |-thing/properties
+ `-thing/restrictions
+
+SIEHE AUCH:
+ properties, closures
diff --git a/doc/std/transport b/doc/std/transport
new file mode 100644
index 0000000..3000c97
--- /dev/null
+++ b/doc/std/transport
@@ -0,0 +1,264 @@
+> FUNKTIONSWEISE VON TRANSPORTERN <
+Version 1.0 (04.05.1993) von Rumata
+===================================
+
+
+INHALT:
+======
+
+ 1. Allgemeines
+ 2. Properties
+ 3. Haltestellen
+ 4. Steuerung
+ 5. Betreten und verlassen
+ 6. Extras
+ 7. Kommandos in Trnasportern
+
+
+1. ALLGEMEINES
+==============
+
+ Ein Transporter ist ein Raum mit besonderen Eigenschaften.
+ Waehrend normale Raume miteinnder starr verbunden sind,
+ kann dieser Raum seine Verbindung zu anderen Raeumen mit
+ der Zeit aendern.
+
+ Jeder Transporter besitzt einen 'Kurs' den er abfaehrt; nach der
+ letzten 'Haltestelle' beginnt der Kurs wieder von Vorne.
+ Will man einen Kurs setzen, der entlang einer Strecke hin-
+ und zurueck fuehrt, so muss man jede Haltestelle einmal fuer
+ den Hinweg und einmal fuer den Rueckweg einfuegen.
+
+ Ein Beispiel, wie man einen solchen Transporter programmiert,
+ ist in /doc/beispiele/wolke.c zu sehen (und zu laden :-).
+
+2. PROPERTIES
+=============
+
+ P_ENTERMSG
+ Array mit zwei Meldungen in der Art von msgin und
+ msgout. Die erste Meldung ist fuer den Raum, den der
+ Spieler verlaesst, und die zweite fuer den Transporter,
+ in den er geht.
+
+ P_LEAVEMSG
+ Array mit zwei Meldungen, eine fuer den Transporter, den
+ er verlaesst, und eine fuer den Raum, in den er kommt.
+
+ P_ENTERFAIL
+ Meldung an ein Wesen, wenn den vollen Transporter
+ betreten will. Ist die Prop. ein Array, so wird das erste
+ Element als Meldung an das Wesen, das zweite als Meldung
+ an die Mitspieler im Raum geschickt. Ist die Property
+ eine Closure, wird diese ausgefuehrt, wenn ein Spieler
+ vergeblich versucht, den Transporter zu betreten.
+
+ P_LEAVEFAIL
+ Meldung an ein Wesen, wenn es ausserhalb der Anlegezeiten
+ den Transporter verlassen will. Ist die Prop. ein Array,
+ so wird das erste Element als Meldung an das Wesen, das
+ zweite als Meldung an die Mitspieler im Transporter
+ geschickt. Ist die Property eine Closure, wird diese
+ ausgefuehrt, wenn ein Spieler vergeblich versucht, den
+ Transporter zu verlassen.
+
+ P_ARRIVEMSG
+ Ein Array mit zwei Meldungen. Das erste Element ist die
+ Meldung, die die Wesen im Transporter bekommen. Die
+ zweite Meldung ist fuer die Wesen in dem Raum, an dem
+ der Transporter anlegt.
+
+ P_DEPARTMSG
+ Dito fuer das Ablegen.
+
+ P_MAX_PASSENGERS
+ Numerischer Wert fuer die maximale Anzahl von Wesen, die
+ sich in dem Transporter aufhalten duerfen.
+ 0 bedeutet unbeschaenkte Spielerzahl.
+
+
+3. HALTESTELLEN
+===============
+
+ Es gibt 3 Sorten von Haltestellen:
+
+ 1.) Raeume als Haltestellen.
+
+ FUNKTION:
+
+ AddRoute( raum, verweil, next );
+ oder
+ AddRoute( raum, verweil, next, code );
+
+ PARAMETER:
+
+ raum - Raum, an dem der Transporter halten soll.
+ verweil - Zeit in Sekunden, die der Transporter in dem
+ Raum verbleibt, bis er weiterfaehrt.
+ next - Zeit in Sekunden bis zur naechsten Halte-
+ stelle.
+
+ code - Text, der von der Funktion QueryArrived
+ zurueckgegeben wird, wenn der Transporter
+ an dieser Haltestelle angelegt hat.
+ Wird dieser Parameter nicht angegeben, wird
+ ein leerer String als code gesetzt.
+
+ 2.) Meldungen als Haltestellen.
+
+ FUNKTION:
+
+ AddMsg( text, next );
+
+ PARAMETER:
+
+ text - Text, der Meldung, die in dem Transporter
+ ausgegeben wird.
+ next - Zeit in Sekunden bis zur naechsten Halte-
+ stelle.
+
+ 3.) Funktionsaufrufe als Haltestellen.
+
+ FUNKTION:
+
+ AddFun( fun, next );
+
+ PARAMETER:
+
+ fun - Name einer Funktion, die im Transporter
+ aufgerufen wird.
+ next - Zeit in Sekunden bis zur naechsten Halte-
+ stelle.
+
+4. STEUERUNG
+============
+
+ FUNKTION
+
+ Start();
+ oder
+ Start(nummer);
+
+ BESCHREIBUNG:
+
+ Der Transporter soll sofort an der Haltestelle mit
+ der angegebenen Nummer (keine Nummer heisst an der ersten)
+ anlegen und von da ab seinen Kurs fahren.
+
+ FUNKTION:
+
+ Halt();
+
+ BESCHREIBUNG:
+
+ Halte die Fahrt an. Der Transporter bleibt stehen, wo
+ er ist.
+
+
+5. BETRETEN UND VERLASSEN
+=========================
+
+ Der Transporter hat keine Verben programmiert, mit denen man
+ den Transporter betreten oder verlassen kann.
+ Dafuer muessen mit AddCmd() Verben eingefuehrt werden, die
+ auf selbstgeschriebene Funktionen zugreifen.
+
+ FUNKTION:
+
+ Enter();
+
+ BESCHREIBUNG:
+
+ Teste, ob fuer dun aktuellen Spieler (this_player())
+ noch Platz im Transporter ist und ob er sich ausserhalb
+ des Transporters befindet. Wenn ja, bewege ihn in den
+ Transporter. Wenn der Transporter eine Reaktion (Bewegen des
+ Spielers oder Ueberlauf), so gib eine 1 zurueck sonst eine 0.
+
+ Wenn der Transporter nicht da (also unsichtbar) ist, tue fuer
+ die Spieler ausserhalb des Transporters so,
+ als ob das Verb nicht definiert wurde.
+
+ Dieser Wert kann im allgemeinen direkt als returnwert benutzt
+ werden.
+
+ FUNKTION:
+
+ Leave();
+
+ BESCHREIBUNG:
+
+ Wenn der Momentane Spieler nicht im Transporter ist, so gib
+ eine Fehlermeldung aus. Anderenfalls teste, ob der
+ Transporter an einen Raum angelegt hat. Wenn nein, gebe
+ die LEAVEFAIL Meldung aus; und wenn alles ok ist, so
+ bewege den Spieler aus dem Transporter.
+
+6. EXTRAS
+=========
+
+ FUNKTION:
+
+ QueryArrived();
+
+ BESCHREIBUNG:
+
+ Gebe den Code des Raumes zurueck, an dem der Transporter
+ gerade anliegt. Hat der Raum keinen Code, gebe einen
+ Leerstring zurueck. Liegt der Transporter an keinem Raum
+ an, so gebe 0 zurueck.
+
+ Diese Funktion bietet sich an um mittels process_string
+ die Ankunfts- und Abfahrtsmeldungen abwechslungsreich
+ zu gestalten.
+
+ FUNKTION:
+
+ QueryPassengers(),
+
+ BESCHREIBUNG:
+
+ Gebe eine Liste mit allen Lebewesen, die sich auf/in dem
+ Transporter befinden, zurueck.
+
+ FUNKTION:
+
+ RemoveRoute();
+
+ BESCHREIBUNG:
+
+ Halte den Transporter an und loesche dessen Kurs.
+
+7. KOMMANDOS IN TRANSPORTERN
+============================
+
+ Da sich der Transporter in dem Raum befindet, in dem er angelegt
+ hat, sind alle Kommandos des Transporters auch dort verfuegbar.
+ Selbst wenn der Transporter abgelegt hat, steht er noch immer
+ unsichtbar dort herum.
+
+ Deshabl muss in den Kommandos vorsorge grtroffen werden, dass nur
+ die richtigen Spieler (die drinnen und die draussen) die richtigen
+ Kommandos ausfuehren koennen.
+
+ KOMMANDOS FUER SPIELER AUSSERHALB:
+
+ Es muss abgetestet werden, ob der Spieler nicht im
+ Transporter ist, und ob der Transporter angelegt hat.
+
+ if( environment(this_player())==this_object()
+ || !QueryArrived() ) return 0;
+
+ KOMMANDOS FUER SPIELER INNERHALB:
+
+ Abtesten, ob der Spieler wirklich im Transport ist.
+
+ if( environment(this_player())!=this_object() )
+ return 0;
+
+ Vorsicht auch bei AddExits innerhalb des Transporters,
+ aber daran arbiete ich noch... :-)
+
+ Die Funktionen Enter() und Leave() haben diese Funktionalitaet
+ eingebaut.
+
diff --git a/doc/std/tuer b/doc/std/tuer
new file mode 100644
index 0000000..489fd84
--- /dev/null
+++ b/doc/std/tuer
@@ -0,0 +1,42 @@
+STANDARDOBJEKT FUER TUEREN:
+
+BENTUZUNG:
+ inherit "std/tuer";
+
+ #include <tuer.c>
+
+BESCHREIBUNG:
+ Basisklasse fuer alle Tueren im Spiel. Sie ist von /std/thing
+ abgeleitet.
+
+ Funktionen:
+
+ AddDoor2( strin short,
+ string long,
+ mixed id,
+ mixed dest,
+ string com,
+ int flags,
+ string key,
+ string func,
+ object obj )
+
+ Erzeugt eine neue Tuer, wobei die Parameter folgendes angeben:
+
+ short = Kurzbeschreibung der Tuer
+ long = Ausfuehrliche Beschreibung der Tuer
+ id = Name[n] der Tuer
+ dest = Kommando zum Durchschreiten der Tuer, z.B. 'norden'
+
+ Optionale Parameter:
+
+ flags = Flags aus tuer.h
+ key = String, der im Schluessel definiert sein muss, damit
+ er 'passt'.
+ func = Funktion die beim Durchschreiten der Tuer in obj
+ aufgerufen werden soll.
+ obj = Objekt in dem func aufgerufen werden soll.
+
+SIEHE AUCH:
+ schluessel
+
diff --git a/doc/std/unit b/doc/std/unit
new file mode 100644
index 0000000..3c75059
--- /dev/null
+++ b/doc/std/unit
@@ -0,0 +1,102 @@
+Units
+
+DEFINIERT IN:
+ /std/unit.c
+
+BESCHREIBUNG:
+ Das Unit-Objekt kann dazu verwendet werden, um groessere Mengen
+ eines Objektes - wie Muenzen - zu erzeugen.
+
+ Das grundlegende Konzept ist, das Unit-Objekte nicht mehr nur
+ ueber ihre Namen, sondern auch ueber ihre Menge angesprochen
+ werden kann.
+
+ So wird das id() der Muenzen nicht nur 'muenzen' sondern auch
+ '3 muenzen' verstehen und auswerten koennen.
+
+ move() kann Teile des ganzen Unit-Objekts bewegen, ein neuer
+ Clone wird erzeugt und diesem der verbleibende Rest der Menge
+ zugewiesen. Nach erfolgreichem move() schaut das Unit-Objekt am
+ Zielort, ob dort evtl. bereits Units des gleichen Typs vorhanden
+ sind und vereinigt sich ggf. mit ihnen, in dem das alte Unit-
+ Objekt zerstoert wird.
+
+ Unit-Objekte werden in einigen Dinger anders programmiert, dazu
+ gehoert folgendes:
+
+ P_SHORT ES WIRD KEINE P_SHORT GESETZT!
+
+ P_AMOUNT Die Menge des Unit-Objekts 'von Haus aus',
+ also beim Clonen (daher meistens 1)
+
+ P_NAME Bei Unit-Objekten kann hier ein String-Array
+ in der Form ({ SINGULAR_NAME,PLURAL_NAME })
+ angegeben werden
+
+ SetCoinsPerUnits Wieviel ist eine bestimmte Menge wert
+ NICHT P_VALUE
+
+ SetGramsPerUnits Wieviel wiegt eine bestimmte Menge
+ NICHT P_WEIGHT
+
+ AddSingularId String-Array mit den Singular-IDs
+ AddPluralId String-Array mit den Plural-IDs
+
+ zusaetzlich koennen natuerlich IDs per AddId vergeben werden
+
+ Weiterhin verfuegen Unit-Objekte ueber die Moeglichkeit eines
+ automatischen Zerfalls. Dieser ist steuerbar ueber die Props
+ P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_QUOTA, P_UNIT_DECAY_FLAGS,
+ P_UNIT_DECAY_MIN. Hierbei wird der Zerfall von der Blueprint des
+ Unit-Objektes gesteuert, was als Zerfallsmaster fungiert, weil Clones
+ nicht unbedingt immer nen Reset haben muessen. Die entsprechenden
+ Props sollten daher in der Blueprint konfiguriert werden. (s. Manpages
+ und Beispiel)
+
+BEISPIELE:
+ Wir basteln uns ein ganz einfaches Unit-Objekt:
+
+ inherit "/std/unit";
+
+ protected void create()
+ {
+ if(!clonep(this_object())) {
+ set_next_reset(-1);
+ return;
+ }
+ ::create();
+ SetProp(P_LONG,"Das ist die kleine Leiche einer Ameise.\n");
+ SetProp(P_NAME,({ "Ameisenleiche","Ameisenleichen" }));
+ SetProp(P_AMOUNT,1); // es handelt sich um 1 einziges Objekt
+ SetCoinsPerUnits(20,10); // 10 Objekte sind 20 Muenzen wert
+ SetGramsPerUnits(1,10); // 10 Objekte wiegen 1 Gramm
+
+ AddSingularId( ({ "leiche","ameisenleiche" }) );
+ AddPluralId( ({ "leichen","ameisenleichen" }) );
+
+ AddId("\n-MeineAmeisenleiche");
+ }
+
+ Wir basteln nun ein Unitobjekt, was zerfallen soll:
+ inherit "/std/unit";
+ protected void create() {
+ // Konfig s.o. ...
+ if (!clonep()) {
+ // Zerfall alle 3h
+ SetProp(P_UNIT_DECAY_INTERVAL, 3*3600);
+ // es zerfallen jeweils 10%
+ SetProp(P_UNIT_DECAY_QUOTA, 1000);
+ // es sollen min. 10 Einheiten jeweils uebrigbleiben
+ SetProp(P_UNIT_DECAY_MIN, 10);
+ }
+ }
+
+SIEHE AUCH:
+ P_AMOUNT, P_NAME, P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_QUOTA,
+ P_UNIT_DECAY_MIN, P_UNIT_DECAY_FLAGS
+ DoDecay(), doDecayMessage(), SetGramsPerUnits(), SetCoinsPerUnits(),
+ AddSingularId(), AddPluralId(), QueryCoinsPerUnits(),
+ QueryGramsPerUnits()
+ /std/unit.c
+
+14.10.2007, Zesstra
diff --git a/doc/std/util b/doc/std/util
new file mode 100644
index 0000000..8bf3527
--- /dev/null
+++ b/doc/std/util
@@ -0,0 +1,34 @@
+DEFINIERT IN:
+ /std/*.c
+
+BESCHREIBUNG:
+ Diese Mangepage beschreibt kein Einzelobjekt, sondern eine Sammlung von
+ Programmen.
+ Im Verzeichnis /std/util/ liegen mehrere Helferklassen, die Funktionen
+ bereitstellen, die nicht nur einem Objekt verwendet werden.
+
+ Momentan sind dies:
+ executer.c - stellt eine Funkton execute_anything() beret.
+ input.c - stellt eine Funtion intput() bereit, welche inptu_to()
+ kapselt.
+ pager.c - Stellt die Funktion More() und ihre Helfer bereit.
+ ringbuffer.c - Stellt einen Ringpuffer und die notwendigen Verwaltungs-
+ funktionen bereit.
+
+ Ringbuffer.c:
+ ------------
+ Dies ist ein Puffer (Array) einer bestimmten Groesse. Sobald er voll ist
+ wird automatisch die jeweils aeltesten Daten ueberschrieben, sobald etwas
+ neues hineingeschrieben wird. Ein Ringpuffer mit einer Groesse von 30
+ speichert also die letzten 30 hineingeschriebenen Objekte.
+ * CreateRingBuffer(): erstellt einen neuen Ringpuffer.
+ * ResizeRingBuffer(): aendert die Groesse eines Ringpuffers.
+ * RingBufferPut(): schreibt ein neues Datum in den Puffer.
+ * RingBufferGet(): liefert die Daten des Ringpuffers zurueck.
+
+SIEHE AUCH:
+ CreateRingBuffer, ResizeRingBuffer, RingBufferPut, RingBufferGet
+
+LETZTE AeNDERUNG:
+23.05.2008, Zesstra
+
diff --git a/doc/std/vererbungsbaeume b/doc/std/vererbungsbaeume
new file mode 100644
index 0000000..2df21cc
--- /dev/null
+++ b/doc/std/vererbungsbaeume
@@ -0,0 +1,293 @@
+
+ Vererbungsbaeume der Basis-MUDlib
+ =================================
+
+Einfache Gegenstaende
+---------------------
+
+Die einfachsten Objekte der Basis-MudLib. Die Module, die von thing.c
+geerbt werden, enthalten die wichtigsten Funktionen und treten auch in
+den anderen Standardobjekten immer wieder auf.
+
+Da die Ausgabe des Namens eines Objektes (dieser wird in den
+description-Modulen definiert) immer mit einer Deklination verbunden ist,
+findet man in jedem Objekt, welches ein description.c erbt, auch
+thing/language.
+
+thing
+ |- thing/properties | Verwaltungsfunktionen des Property-Systems
+ |- thing/description | Aussehen, Name, IDs des Objektes
+ |- thing/moving | Bewegen und Zerstoeren des Objektes
+ |- thing/language | Deklination von Namen, Adjektiven etc.; Pronomina
+ |- thing/commands | vom Objekt definierte Kommandos
+ `- thing/restrictions | Gewicht: standardmaessig 1Kg
+
+
+Ruestungen
+----------
+
+Bis auf thing/restrictions.c verfuegt armour.c ueber saemtliche Funktionalitaet
+die auch thing.c zur Verfuegung stellt. Zusaetzlich gibt es noch ein Modul,
+welches die Ruestung erst zur Ruestung macht: armour/combat.c
+
+armour | evtl. ein "(angezogen") an Kurzbeschreibung haengen
+ |- thing/properties | Auch Ruestungen haben Eigenschaften
+ |- thing/description | Aussehen, Name, IDs der Ruestung
+ |- thing/commands | Kommandos sind auch moeglich
+ |- armour/moving | Beim Bewegen/Zerstoeren: Ruestung ausziehen...
+ | `- thing/moving | ...und dann erst Bewegen/Zerstoeren
+ |- armour/combat | Ruestungsklasse/-typ, Kampffunktion
+ `- thing/language | und noch was zum deklinieren.
+
+
+Waffen
+------
+
+Wie Ruestungen, unterscheiden sich Waffen von einfachen Gegenstaenden im
+wesentlichen nur durch die Kampffunktionen.
+
+weapon | evtl. ein "(gezueckt)" an Kurzbeschreibung haengen
+ |- weapon/moving | Waffe beim Bewegen/Zerstoeren erst wegstecken...
+ | `- thing/moving | ...und dann erst bewegen/zerstoeren
+ |- thing (s.o.) | Ansonsten alle thing-Eigenschaften
+ `- weapon/combat | Waffenklasse/-art, Schadenstyp, Kampffunktion
+
+
+Lichtquellen
+------------
+
+Lichtquellen sind (im Sinne der MudLib) normale Gegenstaende, die zusaetzlich
+die Eigenschaft haben, dass sie leuchten koennen (und auch verbrennen koennen).
+
+lightsource | Alles, was zum Leuchten noetig ist
+ `- thing (s.o.) | ansonsten ein ganz normaler Gegenstand
+
+
+unit-Objekte
+------------
+
+unit-Objekte sind Gegenstaende, bei denen es sinnvoll ist, dass ein einzelnes
+Objekt eine gewisse Anzahl von gleichartigen Objekten repraesentiert. Das
+beste Beispiel hierfuer ist das liebe Geld: statt 1000 einzelner Muenzen im
+Inventory zu haben, hat man nur ein einziges Geldobjekt, das einer Menge von
+1000 Muenzen entspricht (die bei Kauf-/Verkaufsaktionen um eine entsprechende
+Menge erniedrigt oder erhoeht wird).
+Hierdurch wird a) die Uebersichtlichkeit erhoeht und b) natuerlich massig
+Speicher gespart.
+
+unit | alle unit-Eigenschaften (Gewicht, Menge, Bewegen, ...)
+ `- thing (s.o.) | ansonsten sind es normale Gegenstaende
+
+
+Spellbooks
+----------
+
+Fuer Gildenprogrammierer ist dies das Grundobjekt fuer das Zauberverzeichnis
+der Gilde.
+ACHTUNG: Obwohl thing.c geerbt wird, ist das Spellbook nicht zum clonen und
+"unter den Arm klemmen" gedacht! Vielmehr stellt thing.c hier im wesentlichen
+nur das Property- und das Sprachmodul zur Verfuegung!
+
+spellbook | Allgemeine Funktionen fuer Zaubersprueche
+ |- thing (s.o.) | hier nur wg. Properties und Deklinationen
+ `- restriction_checker | fuer Einschraenkungen beim Zaubern
+
+
+Behaelter
+---------
+
+Die bisher beschriebenen Objekte kann man zwar mit sich herumtragen (ausser
+Spellbooks), aber man kann nichts hineinstecken. Hierzu sind einige weitere
+Funktionen noetig, die container.c zur Verfuegung stellt.
+Im wesentlichen sind das in container/restrictions.c Funktionen zum Aus-
+waehlen von Objekten im Behaelter, zum Testen, ob der Behaelter noch weitere
+Objekte aufnehmen kann (gewichtsabhaengig) und zur Ermittlung des Gesamt-
+gewichts des Behaelters.
+In container/description.c wird der Inhalt des Behaelters in eine Beschreibung
+umgewandelt.
+
+container
+ |- thing/properties | DAS zentrale Modul...
+ |- thing/moving | Bewegen/Zerstoeren des Behaelters
+ |- thing/commands | Kommandos sind moeglich
+ |- container/description | Beschreibung des Inhalts
+ | `- thing/description | Lang- und Kurzbeschreibung
+ |- thing/language | Deklinationsmodul
+ `- container/restrictions | Gesamtgewicht, Objektauswahl
+ `- thing/restrictions | Standardgewicht: 1Kg
+
+Leichen
+-------
+
+Leichen sind Behaelter mit der zusaetzlichen Eigenschaft, dass sie mit der
+Zeit zerfallen. Ausserdem geben sie ggf. noch eine Meldung ueber den
+Moerderkanal aus
+
+corpse | Zerfallen, Moerdermeldung
+ `- container (s.o.) | sonst normaler Behaelter
+
+
+Raeume und ihre Abkoemmlinge
+----------------------------
+
+Raeume sind prinzipiell Behaelter mit Lang- und Kurzbeschreibung von INNEN
+und weiteren untersuchbaren Details (auch lesbare Details) sowie
+Ausgaengen und der Moeglichkeit vordefinierte Objekte im Raum zu plazieren.
+
+room
+ |- thing/properties | Eigenschaften des Raumes
+ |- thing/language | das obligatorische Sprachmodul
+ |- room/moving | nur Zerstoeren; KEIN(!) Bewegen
+ |- room/restrictions | Raeume werden nie voll
+ | `- container/restrictions | sonst die gleiche Funktionalitaet wie
+ | `- thing/restrictions | beim normalen Behaelter
+ |- room/description | Raumbeschreibung, Details, etc.
+ | `- container/description | Beschreibung des Inhalts
+ | `- thing/description | Beschreibung von aussen (selten sichtbar)
+ |- room/exits | Verwaltung der Ausgaenge
+ |- room/commands | notify_fail()s fuer "lies", "suche", "such"
+ | `- thing/commands | sonst normale Kommandobehandlung
+ |- room/items | Verwaltung von Objekten, die im Raum sein sollen
+ `- room/doors | Tueren (besondere Ausgaenge)
+
+
+Die Kneipe erweitert den Standardraum um Funktionen zur Definition der
+Speisen und Getraenke sowie um Befehle zum Bestellen und Ausgeben.
+
+pub
+ `- room (s.o.)
+
+
+Auch der Laden baut direkt auf dem Standardraum auf. Hier werden noch die
+ueblichen Ein- und Verkaufsbefehle zur Verfuegung gestellt.
+Jeder Laden benoetigt zusaetzlich einen Speicher, in dem verkaufte Objekte
+gelagert werden. Wenn der Laden schon beim ersten Betreten ueber ein
+gewisses Warensortiment verfuegen soll, kann man die mit AddItem()-Aufrufen
+im Speicher bewerkstelligen.
+
+laden
+ `- room (s.o.)
+
+store
+ |- thing/properties | noetig fuer room/items.c
+ `- room/items | vordefinierte Objekte im Speicher
+
+
+Die Post ist von der Programmierung her genau so zu behandeln wie ein
+normaler Raum. Die Postkabinen werden automatisch zur Verfuegung gestellt;
+man braucht sich in der Hinsicht um nichts zu kuemmern.
+
+post
+ `- (...) room
+
+
+Schiffe und aehnliche Transporter werden durch "bewegliche" Raeume realisiert.
+So hat man alle Beschreibungsmoeglichkeiten eines Raumes zur Verfuegung und
+kann (wie bei der Jolle geschehen) Ausgaenge in weitere Raume des Transporters
+legen (diese sind normale Raeume, KEINE Transporter!).
+Desweiteren sind Transporter die einzigen (Standard-)Raume, bei denen man
+auch die aeussere Lang- und Kurzbeschreibung zu sehen bekommt, weil man
+nicht nur in einem Transporter sein kann, sondern auch daneben stehen kann.
+
+transport | Funktionen zur Festlegung der Route, An- und Ablegen
+ |- room (s.o.) | die normalen Raumfunktionen
+ `- thing/moving | und hier steckt die Beweglichkeit
+
+
+Gilden
+------
+
+Gilden gibt es in zwei Ausfuehrungen: einmal als einfaches Gildenobjekt, dann
+aber auch als Gildenraum (wie zB. die Abenteurergilde).
+Waehrend das Gildenobjekt (gilden_ob) Funktionen zum Lernen von Faehigkeiten
+und Zauberspruechen, dem Gildenein- und -austritt sowie zum gildeninternen
+Aufstieg zur Verfuegung stellt (was zB. auch von einem NPC ausgeuebt werden
+koennte), verfuegt der Gildenraum zusaetzlich noch ueber Funktionen zum
+normalen Stufenaufstieg aufgrund von Abenteuer- und Erfahrungspunkten, die
+Questliste und die Kostenabfrage.
+
+gilden_ob | Ein-/Austritt, Lernen, Gildenaufstieg
+ `- restriction_checker | Beschraenkungen bei obigen Aktionen
+
+gilden_room
+ |- gilde | Stufenaufstieg, Questliste, Kosten
+ | `- room (s.o.) | normale Raumfunktionen
+ `- gilden_ob (s.o.) | Gildenaufstieg etc.
+
+NPCs
+----
+
+Das Opfer. Zumindest meistens...
+
+npc
+ |- thing/properties | Eigenschaften des NPC
+ |- living/description | Ausgabe des Gesundheitszustandes...
+ | `- container/description | ...zusaetzlich zu seinem Inhalt...
+ | `- thing/description | ...und seiner Beschreibung
+ |- living/life | Die Lebensfunktionen, Essen, Trinken, Gift
+ |- living/attributes | Die Verwaltung der Stats
+ |- living/moving | Bewegen von Lebewesen
+ |- living/skills | Funktionen fuer Faehigkeiten und Sprueche
+ | `- living/std_skills | und einige Standardfaehigkeiten
+ |- npc/combat | NPC-spezifische Kampffunktionen
+ | `- living/combat | der Kampf an sich
+ |- npc/chat | Sprueche a la Andy
+ |- npc/comm | Basiskommunikation: "sag", "echo", "emote"
+ |- container/restrictions | wie bei Behaeltern
+ | `- thing/restrictions
+ |- thing/language | obligatorisch...
+ |- npc/info | Antworten auf Fragen
+ |- npc/put_and_get | Reaktion auf erhaltene Gegenstaende
+ | `- living/put_and_get | Geben und Nehmen von Objekten
+ `- npc/guard | fuer Wach-NPCs
+
+Der intelligente NPC befindet sich noch in der Entwicklung.
+
+inpc
+ |- npc (s.o.) | Erst mal ein ganz normaler NPC...
+ |- inpc/nobank | ...der gegen Bankzweitis vorgehen kann...
+ | `- player/moneyhandler | ...und selbst Geld mitschleppt; ...
+ |- select | ...die beste Ausruestung erkennt und auch benutzt...
+ `- boozing | ...und in der Kneipe die beste Heilmoeglichkeit findet!
+
+
+Spieler- und Magiershell
+------------------------
+
+shells/magier | Hier auch noch Spielershells:
+ |- player/base | Einloggen, Grundfunktionen
+ | |- player/restrictions | Maximale Zuladung (Staerke), InsertHooks
+ | | `- container/restrictions | Maximalgewicht, Zuladungstest
+ | | `- thing/restrictions | Defaultgewicht
+ | |- living/attributes | Stats
+ | |- living/combat | Kampffunktionen
+ | |- living/put_and_get | Nehmen und Geben von Objekten
+ | |- thing/properties | DAS zentrale Modul...
+ | |- thing/language | Deklinationen
+ | |- player/description | Waffe/Ruestungen ausgeben
+ | | `- living/description | Gesundheitszustand anzeigen
+ | | `- container/description | Ermittlung des Inhalts
+ | | `- thing/description | Kurz- und Langbeschreibung; IDs
+ | |- player/moving | Bewegen/Zerstoeren: Zusatzchecks
+ | | `- living/moving | Bewegen/Zerstoeren von Lebewesen
+ | |- player/life | Zusatzchecks bei Lebensfunktionen
+ | | `- living/life | allgemeine Lebensfunktionen
+ | |- player/comm | allgemeine Kommunikation
+ | | `- player/channel | Kommunikation ueber die Kanaele
+ | |- player/moneyhandler | Geldverwaltung (auch fuer NPCs geeignet)
+ | |- player/command | Aliase, History, Parser
+ | |- living/skills | allg. Faehigkeitsfunktionen
+ | | `- living/std_skills | Standardfaehigkeiten
+ | |- player/quests | Verwaltung geloester Abenteuer
+ | |- player/potion | Verwaltung gefundener Zaubertraenke
+ | |- player/soul | Seelenkommandos (hilfe verben ;)
+ | |- player/viewcmd | Untersuchen etc.
+ | |- more | More() fuer lange Texte
+ | `- user_filter | Hilfsmodul fuer "kwer in muenster" etc.
+ | | Ab hier: Magiershell
+ |- shells/filesys/filesys | allgemeines Modul zur Dateibehandlung
+ | |- shells/filesys/manual | der "hilfe"-Befehl der Magier
+ | |- shells/filesys/primitives | low-level-Routinen
+ | |- shells/filesys/asynchron | zur Vermeidung von Lags
+ | `- shells/filesys/make | komfortables updaten von Objekten
+ `- player/objects | Objekte clonen, updaten, zerstoeren
diff --git a/doc/std/virtual_compiler b/doc/std/virtual_compiler
new file mode 100644
index 0000000..ac8ec3d
--- /dev/null
+++ b/doc/std/virtual_compiler
@@ -0,0 +1,82 @@
+Was sind 'virtuelle Objekte'?
+=============================
+Virtuelle Objekte sind Objekte fuer die es keine explizite Quelldatei gibt.
+Ansonsten sind die Objekte (fast) genauso wie alle anderen auch.
+
+Was macht ein Virtual Compiler?
+===============================
+Wenn der Driver ein Objekt "/pfad/objekt" laden soll, guckt er erstmal nach,
+ob es so ein File (/pfad/objekt.c) auf der Platte gibt. Wenn ja, laedt er es
+ganz normal. Wenn nicht, passiert folgendes:
+
+1. Der Driver fragt den Master der Mudlib nach dem Objekt.
+2. Der Master guckt im Verzeichnis "/pfad/" nach, ob es ein virtual_compiler.c
+ dort gibt. Wenn ja, wird dieses virtual_compiler.c gefragt, ob es sich
+ dafuer zustaendig fuehlt, ein Objekt mit dem Namen "/pfad/objekt" zu
+ erzeugen.
+3. Wenn sich der VC fuer zustaendig fuehlt, clont er ein Objekt (z.B. sein
+ Standardobjekt, "stdob.c"), konfiguriert es evtl. noch ein bisschen und
+ gibt es an den Master zurueck. Das erzeugte Objekt heisst an dieser Stelle
+ z.B. "/pfad/stdob#42" (weil es ein Clon von "/pfad/stdob" ist).
+4. Der Master gibt dieses erzeugte Objekt an den Driver zurueck.
+5. Der Driver benennt das vom Master erhaltene Objekt "/pfad/stdob#42" um in
+ das gewuenschte Objekt "/pfad/objekt". Von diesem Moment an ist es, als ob
+ es ein File "/pfad/objekt.c" gaebe, was dieses Objekt definiert.
+
+Das ist grundsaetzlich das, was ein VC macht.
+
+Was macht der VC in /std/?
+==========================
+Erstmal das oben beschriebene. Fuer welchen Pfad sich dieser VC zustaendig
+fuehlt und welches Objekt er jeweils clonen soll, wird per P_COMPILER_PATH und
+P_STD_OBJECT konfiguriert.
+Zusaetzlich fuehrt er besagte Liste seiner erzeugten Objekte, damit bei einem
+'ls' auf das Verzeichnis diese Objekte mit angezeigt werden.
+Weiterhin zerstoert er alle diese Objekte in seinem eigenen Remove.
+Ausserdem hat er 2 Funktionen, mit denen er entscheiden kann, ob er fuer ein
+bestimmtes angefragtes Objekt zustaendig ist, Validate() und
+QueryValidObject() und eine Funktion CustomizeObject(), die einem frisch
+geclonten Objekt sagen kann, welchen Namen es spaeter einmal haben soll (s.
+jeweilige Manapages).
+
+Wie baut man sich seinen eigenen VC?
+====================================
+Sagen wir, ihr wollt einen VC bauen, der jedem Spieler seinen eigenen Raum
+gibt, damit jeder Spieler in diesem Raum ein Monster allein erlegen muss,
+ohne dass andere Spieler mit drin sind.
+Dann braucht ihr zuerst mal einen Raum, der die Vorlage fuer alle VC-Raeume
+sein soll, z.B. std_arena.c. Diesen legt ihr in das Verzeichnis, wo der VC hin
+soll, z.B. /d/region/magier/vc/.
+In diesem Verzeichnis legt ihr nun ein File virtual_compiler.c an, welches
+/std/virtual/v_compiler erbt.
+Im create() setzt ihr nun P_COMPILER_PATH auf "/d/region/magier/vc/" und
+P_STD_OBJECT auf "/d/region/magier/vc/std_arena".
+Soll euer VC keine Para-Raeume erzeugen, setzt ihr P_PARA auf ({}).
+Sodann muesst ihr ein Validate() formulieren (s. Manpage), welches prueft, ob
+ein spaeter gewuenschtes Objekt den richtigen Namen (ohne Pfad) hat, z.B.
+'arena|spielername' und in diesem Fall genau diesen Namen zurueckliefert und
+in anderen Faellen 0.
+Das wars. Zumindest in diesem einfachen Fall seid ihr im wesentlichen fertig.
+Ihr koennt einen Spieler nun mit
+ pl->move("/d/region/magier/vc/arena|spielername",M_GO)
+in 'seinen' persoenlichen Raum bewegen.
+
+Bitte beachtet allerdings noch die Hinweise und Beschreibungen in den Manpages
+zu den einzelnen Funktionen und Properties.
+
+
+Beispiele:
+==========
+1. /doc/beispiele/virtual/zesstra/virtual_compiler.c
+ VC, der jedem Spieler einen eigenen Raum gibt. Da hier der Inhalt aller
+ Raeume gleich ist (alle Spieler sollen gleiche Bedingungen haben), ist
+ keine Konfigurierung mit Hilfe von CustomizeObject() noetig.
+
+2. /doc/beispiele/virtual/hate/vr_compiler.c
+ Dies ist ein Beispiel fuer einen sehr allgemeinen VC, der es
+ erlaubt anzugeben in welchem Bereich sich die x und y Koordinaten befinden
+ und dann Raeume erzeugt, welche Ausgaenge in alle vier Himmelsrichtungen
+ haben.
+
+-----------------------------------------------------------------------------
+27.10.2007, Zesstra
diff --git a/doc/std/weapon b/doc/std/weapon
new file mode 100644
index 0000000..3894c02
--- /dev/null
+++ b/doc/std/weapon
@@ -0,0 +1,78 @@
+ STANDARDKLASSE:
+ "/std/weapon"
+
+ BENUTZUNG:
+ inherit "std/weapon";
+
+ #include <properties.h>
+ #include <combat.h>
+
+ PROPERTIES:
+ Grundlegend:
+ P_WC setzbar: Waffenklasse == Angriffsstaerke
+ P_WEAPON_TYPE setzbar: Waffentyp
+ P_DAM_TYPE setzbar: Schadenstypen
+ P_NR_HANDS setzbar: Anzahl benoetigter Haende
+
+ Besondere Attribute und Anforderungen fuer Traeger:
+ P_RESTRICTIONS setzbar: Anforderungen an Traeger
+ P_M_ATTR_MOD setzbar: Attributmodifikator fuer Traeger
+ P_CURSED setzbar: Verfluchung (nicht wegsteckbar)
+ P_PARRY setzbar: Parierwaffe ?
+ P_AC setzbar: Schutzfaktor einer Parierwaffe
+
+ Meldungen und Zeitpunkte:
+ P_EQUIP_TIME enthaelt den Zeitpunkt des Anziehens
+ P_LAST_USE enthaelt den Zeitpunkt des letzten Angriffs damit
+ P_WIELDED enthaelt den Traeger
+ P_WIELD_MSG setzbar: eigene Zueckmeldung
+ P_UNWIELD_MSG setzbar: eigene Wegsteckmeldung
+
+ Dynamisches Verhalten in Kampf und beim Anziehen:
+ P_WIELD_FUNC setzbar: Objekt mit Zueckfunktion "WieldFunc()"
+ P_UNWIELD_FUNC setzbar: Objekt mit Wegsteckfunktion "UnwieldFunc()"
+ P_HIT_FUNC setzbar: Objekt mit Angriffsfunktion "HitFunc()"
+
+ Zusaetzliche Eigenschaften:
+ P_DAMAGED enthaelt den Ausmass des Schadens an Waffe
+ P_QUALITY setzbar: Qualität/Haltbarkeit der Waffe
+ P_EFFECTIVE_AC setzbar: falls HitFunc WC nicht sichbar aendert
+ P_EFFECTIVE_WC setzbar: falls Parieren AC nicht sichbar aendert
+
+ Zusaetzlich sind alle Properties aus /std/thing verfuegbar, also
+ bitte auch folgende setzen:
+ P_MATERIAL setzbar: Zusammensetzung
+ P_SIZE setzbar: Groesse
+ P_WEIGHT setzbar: Gewicht
+
+ MAKROS:
+ Gueltige Waffen- und Schadenstypen (definiert in "/sys/combat.h").
+
+ BESCHREIBUNG:
+ Basisklasse fuer alle Waffen im Spiel. Sie ist von /std/thing
+ abgeleitet und enthaelt alle zusaetzliche Funktionalitaet
+ fuer den Kampf.
+
+ Vor der Programmierung von Waffen sollte /doc/wiz/waffen
+ gelesen werden. Die Regeln darin sind verbindlich und sollten nur
+ in Ausnahmefaellen und mit Absprache mit dem Erzmagier fuer
+ Waffen/Ruestungen/Monster ueberschritten werden.
+
+ VERERBUNGSBAUM:
+ [/std/weapon]
+ ..... [/std/thing/properties]
+ ..... [/std/thing/language]
+ ..... [/std/thing/commands]
+ ..... [/std/thing/restrictions]
+ ..... [/std/weapon/moving]
+ .......... [/std/thing/moving]
+ ..... [/std/weapon/description]
+ .......... [/std/thing/description]
+ ..... [/std/weapon/combat]
+
+
+ SIEHE AUCH:
+ P_WEAPON, P_PARRY_WEAPON, P_TOTAL_WC, P_TOTAL_AC, P_UNWIELD_TIME
+ Attack(), Defend(), /doc/wiz/waffen
+
+ 20 Maerz 2004 Gloinson