Added public files
Roughly added all public files. Probably missed some, though.
diff --git a/doc/wiz/.readme b/doc/wiz/.readme
new file mode 100644
index 0000000..40d049c
--- /dev/null
+++ b/doc/wiz/.readme
@@ -0,0 +1,2 @@
+Hier sind allgemeine Themen und Regelungen fuer Magier beschrieben.
+
diff --git a/doc/wiz/.synonym b/doc/wiz/.synonym
new file mode 100644
index 0000000..6c9523f
--- /dev/null
+++ b/doc/wiz/.synonym
@@ -0,0 +1,17 @@
+sponsor befoerderungen
+sponsoring befoerderungen
+befoerderung befoerderungen
+npc npcs
+materialien material
+flueche gift
+fluch gift
+gifte gift
+vergiftung gift
+krankheit gift
+krankheiten gift
+armour ruestungen
+armours ruestungen
+ruestung ruestungen
+weapon waffen
+weapons waffen
+waffe waffen
diff --git a/doc/wiz/anfaenger b/doc/wiz/anfaenger
new file mode 100644
index 0000000..d240909
--- /dev/null
+++ b/doc/wiz/anfaenger
@@ -0,0 +1,116 @@
+Anfaengergebiete
+
+Vielleicht eruebrigt es sich, einen laenglichen Leitfaden zu schreiben,
+weil dies eigentlich Gebiete wie viele andere sein sollten:
+ausreichend beschrieben, logisch durchdacht, balanciert, was NPC und
+Objekte wie Waffen und Ruestungen betrifft, kurzum, es muss Spass fuer
+Spieler machen.
+
+Einiges unterscheidet aber ein solches Gebiet von anderen, denn wie der
+Name schon sagt, sollte man dort eher hauptsaechlich Anfaenger (einmal
+willkuerlich als Spielstufe 1-5 bezeichnet) erwarten.
+
+1. Erreichbarkeit
+Viele Anfaengergebiete befinden sich natuerlich in unmittelbarer Naehe
+einer Rasse, z.B. die Hochebene bei den Zwergen, der Park der Freunde
+bei den Elfen oder der kleine Dschungel im NW von Katzmandu. Hierbei
+ist die Naehe fuer eine Rasse gegeben, so dass zumindest die kleinen
+Spieler dieser Rasse das Gebiet leicht erreichen koennen. Natuerlich
+ist es fuer andere Rassen nicht unbedingt einfach, einige weit entfernt
+gelegene Anfaengergebiete zu erreichen, ohne Dutzende von Raeumen zu
+durchlaufen.
+Man kann auch nicht sofort davon ausgehen, dass sich ein Anfaenger von
+Anfang an eine Karte fuer Wege anlegt. Insofern ist es sinnvoll, wenn
+es Anfaengergebiete in unmittelbarer Naehe zu den Startpunkten der
+Rassen gibt. Die koennen dann entweder unter dem Ebenenpfad oder auch
+unter /d/anfaenger stehen.
+Allgemein zugaengliche Anfaengergebiete sollten zumindest ohne grossen
+Aufwand vom Startpunkt der Rassen aus zu erreichen sein. Das koennte
+durch spezielle Hilfsmittel geschehen, durch NPC, die einen den Weg
+dorthin weisen (vielleicht durch Ueberarbeitung von bestehenden Files)
+oder durch teleportierende Objekte, die nur fuer Anfaenger benutzbar
+sind. Ziel ist es nicht, den Spielern das Laufen und selbststaendige
+Erkunden abzunehmen, sondern nur die Gefahr, sich ueber laengere
+Strecken hin zu "verfransen".
+
+2. Bekanntheitsgrad
+Diesem Punkt sollte man ein wenig Zeit widmen. Am einfachsten ist die
+Bekanntheit zu erreichen, wenn im Gebiet eine Quest spielt, da dann
+frueher oder spaeter zwangslaeufig eine Frage gestellt wird. Ist es
+eine Miniquest, koennte eine Erfolgsmeldung ueber die Ebene Anfaenger
+flimmern statt ueber die Ebene Abenteuer. Wenn es passt, koennten
+auch diverse NPC mit Informationen versorgt werden, oder andere Objekte,
+die man an prominenter Stelle plaziert (Notizen, Buecher, Aufzeichnungen
+oder aehnliches).
+
+3. NPC
+Auch wenn es nur "kleine" NPC sind, kann man in sie mindestens so viel
+Energie fuer Informationen, Verhalten und Details stecken wie fuer
+"grosse". Sie sollten keinesfalls aggressiv sein. Hoher Body (~ >70)
+oder hohe Hands (~ >100) sind zu vermeiden, da man als Anfaenger noch
+kein Gefuehl dafuer hat, was die Schadensmeldungen "hart", "krachende
+Knochen" oder "kitzelt Dich" in etwa an Schaden machen. Dementsprechend
+waere es auch sinnvoll, die NPC zu schreiben. Bedrohlich aussehende
+Drachen, die immer verfehlen, sind eigentlich ebenso wenig plausibel
+wie kleine Ameisen, die einen mit der Saeure immer sehr hart treffen.
+Im Zweifel einfach einen Lvl 1 Testspieler anlegen und ausprobieren,
+mal ganz ohne Waffe (wie komme ich als "nackter" Neuling an meine erste
+Waffe?), mal mit einer schwachen, mal mit einer etwas besseren Waffe.
+Als Ausnahme darf hier gerne auch mal ein eigentlich schwacher NPC
+Killstufenpunkte (Killstupse) vergeben.
+
+4. Cleaning Up
+Hoffentlich besuchen dann auch viele das Gebiet. Eventuell empfiehlt es
+sich dann (wie bei vielen anderen Gebieten aber auch) zu ueberlegen,
+was passiert, wenn eine Unzahl geschriebener Objekte, die viele dann
+doch nicht gebrauchen/mitnehmen, im Raum herumliegt. Bei Ruestungen und
+Waffen sind die Argumente CLONE_WIELD und CLONE_WEAR in der Funktion
+AddItem vorteilhaft, bei anderen Objekten koennte man in deren Reset
+nachsehen, ob sie laengere Zeit in einem Raum des Gebiets oder im Gebiet
+selbst "herumgammeln". Es bleibt zwar zu hoffen, dass sie irgendwann
+dem Ausswappen des Raumes anheimfallen, aber es sieht im allgemeinen
+nicht schoen aus, wenn Objekte oder gar quest-/miniquestrelevante Teile
+sich in einem oder mehreren Raeumen stapeln.
+
+5. ZTs
+Sie helfen, das Gebiet bekannter zu machen (siehe Punkt 2), sollten
+aber einfach zu finden sein (Detail, einfacher Befehl) und nicht gleich
+eine ganze Miniquest beinhalten.
+
+6. Unterstuetzung von wichtigen Standarditems
+Dazu gehoeren immer noch Seil, Fackel oder Schaufel. Eventuell braucht
+man sie fuer die eine oder andere Aufgabe, ihre Benutzung und die damit
+verbundene Syntax sollte dem Anfaenger danach gelaeufig sein.
+
+7. Unterstuetzung von weit verbreiteten Befehlen
+Dazu zaehlen "oeffne", "nimm", "suche/durchsuche", "schliesse", etc.,
+also das, was in vielen Quests auch mitunter gefragt ist.
+
+8. Vielfalt in dem, was man "tun" kann, einfache Umsetzung
+Man koennte diesen Punkt auch unter "einfacher Code fuer Anfaenger"
+zusammenfassen, das ginge aber manchmal zu weit. Wichtig in diesem
+Zusammenhang ist auch, dem Anfaenger spielerisch im Text, durch Details
+oder Infos von NPC die Syntaxen, wenn sie denn einmal abseits der so
+ueblichen Kommandos sind, ein wenig in den Mund zu legen:
+(Spieler weiss, dass in diesem Raum ein ZT fuer ihn ist, es hat was mit
+dem Baum zu tun, vor dem er steht)
+"unt baum" ->
+"Der Baum ist recht beeindruckend und hoch. Dennoch koenntest Du ohne
+ weiteres auf ihn klettern." ->
+"kletter auf baum/baum hoch" ->
+Erfolg
+
+9. Belohnungen
+Sie duerfen ruhig grosszuegig sein: ZTs (Zaubertraenke), FP (Forscher-
+punkte), EK (Erstkills/Killstupse), AP (Abenteuerpunkte/Questpunkte)
+und MQP (Miniquestpunkte) sind wohl dosiert und abwechslungsreich zu
+verteilen und sollen dem Spieler helfen, den anfangs langen Weg bis
+zum naechsten Level zu verkuerzen.
+
+Wie ueberhaupt hilft eine gute Dokumentation auch einem Anfaenger unter
+den Magiern, selbst schnell eine eigene Referenzsammlung fuer einfache
+Dinge in LPC zu erstellen. Man koennte also sagen, wie der Spieler im
+Anfaengergebiet waechst auch der Magier, der es geschrieben hat.
+
+-----------------------------------------------------------------------
+Last modified: Tue Mar 21 01:46:35 2006 by Ark
diff --git a/doc/wiz/angriff b/doc/wiz/angriff
new file mode 100644
index 0000000..a1ee7b8
--- /dev/null
+++ b/doc/wiz/angriff
@@ -0,0 +1,18 @@
+--------Angreifer
+Attack()
+ Holt die Waffe des Spielers.
+ Berechnet den Angriffstyp und gibt die
+ Angriffsmeldung aus.
+
+ Aufruf von:
+
+--------Verteidiger
+Defend( hp, typ )
+ Gibt die Verteidigungsmeldung aus.
+ Berechnet die Anzahl der HP die abgezogen wird.
+
+ Aufruf von:
+
+do_damage( hp )
+
+ Berechnen der HP. Gegebenenfalls sterben etc.
diff --git a/doc/wiz/artillerie b/doc/wiz/artillerie
new file mode 100644
index 0000000..349cec4
--- /dev/null
+++ b/doc/wiz/artillerie
@@ -0,0 +1,61 @@
+Regeln fuer Artillerie-Objekte
+==============================
+
+1. Definition von Artillerie
+----------------------------
+
+Unter dem Begriff "Artillerie" fasst man alle Objekte zusammen, die
+zusaetzlich zu den vorhandenen Gildenfaehigkeiten durch ein vom
+Spieler initiiertes Kommando direkt Schaden an einem oder mehreren
+Gegnern verursachen.
+
+Waffen und Ruestungen, welche per Kommando Schaden verursachen (z. B.
+Eisstab, Ring vom Schlammdrachen), fallen unter diese
+Definition. Waffen und Ruestungen, die "von sich aus" (ueblicherweise
+per Hit-/DefendFunc) Schaden verursachen (z. B. Todesdrachenpanzer,
+Goblinring), fallen nicht unter diese Definition, sind aber natuerlich
+nach wie vor genehmigungspflichtig.
+
+2. Basisanforderungen
+---------------------
+
+Solche Artillerie muss folgenden Anforderungen genuegen:
+
+ a. Artillerie _muss_ P_ATTACK_BUSY beachten (setzen/abfragen).
+ b. Artillerie _muss_ bei Verwendung Konzentrationspunkte
+ verbrauchen.
+ c. Artillerie darf nicht (bzw. nur begrenzt) gehortet werden
+ koennen.
+ d. Artillerie darf bei Paralyse nicht angewendet werden koennen
+ (P_DISABLE_ATTACK).
+ e. Artillerie muss durch Setzen der Property P_IS_ARTILLERY
+ gekennzeichnet sein.
+ f. Artillerie, die Munition benutzt oder selbst Munition ist (wie z.B.
+ Wurfsterne), muss das Unitobjekt und den dortigen Mechanismus zum
+ Zerfall von Objekten nutzen. Dabei sind P_UNIT_DECAY_INTERVAL und
+ P_UNIT_DECAY_QUOTA so zu setzen, dass die Munition eine Halbwertszeit
+ zwischen 5 und 10 Tagen hat, der ihrer Verfuegbarkeit angemessen
+ ist. Dies laesst sich durch geeignetes Einstellen des
+ Prozentsatzes und/oder der Resetzeit erreichen.
+
+ Beispiele:
+ Setzt man p=1% Zerfall pro Reset an, dann muss der Reset
+ fuer eine Halbwertszeit von 5 Tagen dann
+ t=ln(0.5)/ln(0,99)*5*24*3600 s dauern, das sind 6224 s.
+
+ Moechte man lieber den normalen Reset, der im Mittel 45 min, d.h. 160
+ Resets in 5 Tagen betraegt, so erhaelt man folgenden Prozentsatz:
+ p = 1-0,5^(1/160) d.h. ca. 0,43%.
+
+Details werden fallweise entschieden.
+
+
+3. Inkraftreten
+---------------
+
+Diese Regeln treten am 5. August 2003 in Kraft.
+Revision am 5. April 2008
+Revision am 7. April 2011
+
+--------------------------------------------------------------------------
+Letzte Aenderung: Sam, 7. April 2011 von Humni
diff --git a/doc/wiz/autoload b/doc/wiz/autoload
new file mode 100644
index 0000000..f3cd444
--- /dev/null
+++ b/doc/wiz/autoload
@@ -0,0 +1,32 @@
+AUTO_LOADING:
+ Rumata 26.08.92
+
+ DER NEUE AUTOLOAD-MECHANISMUS
+
+FUNKTIONEN:
+ void SetProp( P_AUTOLOADOBJ, mixed wert );
+ mixed QueryProp( P_AUTOLOADOBJ );
+
+ERLAEUTERUNG:
+ Es gibt jetzt eine Property P_AUTOLOADOBJ, die jedes Objekt
+ setzen kann. Ist der Wert dieser Property nicht 0, so gilt
+ das Objekt als Autoloading-Objekt.
+ WICHTIG: Auch Werte wie "" oder ({ }) sind nicht 0.
+
+ Mit der Funktion QueryProp( P_AUTOLOADOBJ ) kann dieser Wert
+ abgefragt werden.
+
+BEMERKUNGEN:
+ Die Property P_AUTOLOADOBJ sollte nicht mit der
+ Property P_AUTO_LOAD verwechselt werden. Diese speichert
+ die Autoload-Informationen im Spieler.
+
+ Die Property P_AUTOLOADOBJ kann selbstverstaendlich auch als
+ Built-in-Property implementiert werden.
+
+BEISPIEL:
+ Ein einfaches Beispiel steht in ***
+ Ein leistungsfaehiges Beispiel steht in /obj/tools/muschel.c
+
+SIEHE AUCH:
+ "doc/MG/properties"
diff --git a/doc/wiz/balance b/doc/wiz/balance
new file mode 100644
index 0000000..efea050
--- /dev/null
+++ b/doc/wiz/balance
@@ -0,0 +1,78 @@
+Beurteilung und Genehmigung von Waffen und Ruestungen im MG
+===========================================================
+
+
+ Was bedeutet Balance im Morgengrauen? Die Balance (bzw. ihr Fehlen)
+ wird vor allem dann wahrgenommen, wenn Spieler sich gelangweilt durch
+ Gebiete zappen, die vor zwei oder drei Jahren noch als anspruchsvoll
+ galten, oder wenn ein Magier feststellen muss, dass sein schoenes
+ Riesenmonster nichtmal dazu kommt, seine ausgefeilten Zaubersprueche
+ anzuwenden, weil es nach durchschnittlich zweieinhalb Runden schon
+ tot ist. Fehlentwicklungen dieser Art zu verhindern ist Aufgabe der
+ Balance. Sie stellt universelle Grenzwerte und Masstaebe, die als
+ gemeinsamer Nenner fuer alle Magier in diesem Mud eine gewisse
+ Ausgewogenheit garantieren. Anhand dieser Werte kann jeder Magier auf
+ der einen Seite einschaetzen, wie begehrt ein neues Objekt sein wird,
+ und auf der anderen weiss er ungefaehr, was auf seine armen Monster
+ zukommen wird, wenn Spieler mit den Objekten anderer Magier angreifen.
+
+ Diese Aufgabe zu bewaeltigen kann jedoch in einem so riesigen Mud keine
+ Instanz allein leisten. Ein grosse Verantwortung lastet auch auf den
+ Regionsmagiern, die innerhalb ihres Verantwortungsbereichs dafuer Sorge
+ tragen sollten, dass aussergewoehnliche Objekte in Gebieten nicht zu
+ gehaeuft auftreten und nicht zu leicht zu erreichen sind.
+
+ Wie laeuft nun eine Genehmigung durch die Balance ab?
+ Zuallererst sollte sich ein Magier ueber den aktuellen Stand der Balance-
+ regeln informieren. Zum einen weiss er dann sofort, welche Ideen ohnehin
+ keine Chance auf Genehmigung haben, zum anderen inspirieren vielleicht
+ sogar die zahlreichen Hinweise und technischen Details das ein oder
+ andere Objekt. Als naechstes steht eine kritische Pruefung der eigenen
+ Ideen an. Braucht das Mud wirklich den 132. Panzer, der gegen Feuer
+ schuetzt? Gibt es nicht irgendwo ohnehin schon eine Waffe dieses Typs
+ mit fast identischen Werten? Addiert sich die Wirkung eines geplanten
+ Kampfobjekts vielleicht irgendwie mit vorhandenen Objekten? Diese und
+ aehnliche Fragen frueh zu klaeren kann spaeter viel Frust vermeiden. Das
+ Balanceteam kann auch zu diesem Zeitpunkt schon ein Ansprechpartner sein,
+ da seine Mitglieder einen guten Ueberblick ueber die meisten heraus-
+ ragenden Objekte im Mud haben und gerne als Berater zur Verfuegung
+ stehen. Die Magier des Teams koennen natuerlich auch zu programmier-
+ technischen Fragen den einen oder anderen Tip geben.
+
+ Sind die Objekte dann programmiert und ist auch der Regionsmagier mit
+ ihnen einverstanden, wird schliesslich der Antrag gestellt. (Per
+ "mail balance"). Der Antrag sollte folgenden Informationen enthalten:
+
+ - Name des Objekts
+ - Vollstaendiger Filename
+ - Alle relevanten Werte: AC bzw. WC, P_NR_HANDS, Gewicht, Wert, ...
+ - Defend/HitFuncs, in Form einer praezisen Beschreibung der
+ Funktionsweise und des Wertebereichs.
+ - Alle sonstigen Informationen ueber Eigenschaften, die den Kampf
+ beeinflussen oder dem Spieler von Nutzen sind
+ - Fundort und subjektive Einschaetzung des Aufwands, um diesen
+ Gegenstand zu ereichen.
+
+ Die Genehmigung erfolgt dann per mail, es sei denn es gibt begruendete
+ Einwaende. In diesem Fall kommt die Genehmigung mit leicht geaenderten
+ Werten oder sogar eine Ablehnung. Im letzteren Fall steht es dem Magier
+ natuerlich frei, das Objekt zu veraendern und neu zu beantragen.
+ Normalerweise ergibt sich dann auch schnell im persoenlichen Gespraech
+ mit Mitgliedern der Balance, wo das Problem genau liegt und welche
+ Alternativen es gibt.
+
+ Anzumerken bleibt noch, dass Objekte, die nach der Genehmigung noch in
+ irgendeiner Weise positiv veraendert werden, natuerlich neu genehmigt
+ werden muessen. Bei kleineren Aenderungen (Gewicht o.ae.) reicht
+ unter Umstaenden eine informelle Anfrage beim Balanceteam.
+
+ SIEHE AUCH
+
+ balanceantrag, ruestungen, waffen, fernwaffen, uniques, npcs, objects,
+ attributsveraenderungen, resistenzen, kampfobjekte, grenzwerte,
+ nachteile
+
+
+------------------------------------------------------------------------------
+ LETZTE AENDERUNG:
+ Son, 18.10.2005, 18:54:00 von Miril
diff --git a/doc/wiz/balanceantrag b/doc/wiz/balanceantrag
new file mode 100644
index 0000000..6124640
--- /dev/null
+++ b/doc/wiz/balanceantrag
@@ -0,0 +1,133 @@
+Hilfe zu Balanceantraegen
+=========================
+
+Um die Arbeit der Balance zu erleichtern und damit die Wartezeit fuer die
+Magier zu verkuerzen, gibt es einige Dinge zu beachten. Das Ganze liest sich
+auf den ersten Blick sehr buerokratisch, ist es aber nicht. Die Anleitung soll
+nur so ausfuehrlich wie moeglich sein, um Missverstaendnissen vorzubeugen.
+Zuerst einmal gibt es grundsaetzlich zwei Arten von Antraegen:
+
+1. Eine Vorabanfrage
+
+Viele Magier scheuen die Arbeit, ein Objekt zu programmieren, das anschliessend
+nicht von der Balance genehmigt wird. Das ist verstaendlich und Vorabanfragen
+werden nicht minder beachtet als konkrete Antraege. Trotzdem sollte man so eine
+Anfrage sorgfaeltig formulieren. Sie sollte das Problem klar umreissen und
+moeglichst eindeutig sein. Auch ein Hinweis darauf, wo der Magier Probleme mit
+der Balancierung erwartet und in welchem Wertebereich eventuelle Zahlen
+erwartet werden, sollte nicht vergessen werden.
+
+Eine Antwort auf eine Vorabanfrage ist allerdings keine Genehmigung eines
+Objekts. Es ist lediglich als Information zu sehen, ob die Balancemitglieder
+so ein Objekt ueberhaupt fuer genehmigungfaehig halten, gegebenenfalls mit
+angepassten Werten oder leicht veraenderten Eigenschaften. Mit einer Antwort
+auf eine Vorabanfrage wollen wir dem Wunsch der Magier entsprechen, zu
+erfahren, ob es sich lohnt, Arbeit in das Objekt zu investieren, bindend ist
+so eine Antwort allerdings nicht.
+
+2. Ein Antrag
+
+Hier geht es um die Festschreibung aller kampfrelevanten Eigenschaften,
+trotzdem sollten alle Eigenschaften, die Einfluss auf das Spielgeschehen haben,
+mit angegeben werden, auch wenn die Objektbalance nicht direkt fuer diese
+Eigenschaft zustaendig ist. Eine Waffe, die den Traeger ab und zu heilt,
+muss auch bei der Heilungsbalance beantragt werden, trotzdem darf diese
+Eigenschaft nicht vor der Objektbalance verschwiegen werden. Alle Werte
+sollten tabellarisch aufgefuehrt werden. Eine Uebersicht, ueber die von der
+Balance benoetigten Werte:
+
+Kurzbeschreibung: P_SHORT
+Pfadangabe: momentan und nach Anschluss
+Typ des Objekt: Schwert, Hose, Ring...
+Waffen/Ruestungsklasse: P_WC, P_AC
+Schadensart: P_DAM_TYPE
+Benoetigte Haende: P_NR_HANDS
+Wert: P_VALUE
+Gewicht: P_WEIGHT
+HitFunc: Mit Erlaeuterung der Umstaende,
+ Begruendung und Werte/Wahrscheinlichkeiten
+Andere Boni: Kaempfer, Zauberer, Heilungen, Resistenzen
+ evtl mit rollensp. Begruendung
+Restriktionen: P_RESTRICTIONS, Paralyse, Zeitbeschraenkungen
+
+Eine Begruendung sollte die Eigenschaft rollenspieltechnisch einbetten und
+nicht beschreiben, warum das MG diese Eigenschaft in einem Objekt unbedingt
+noch braucht. Weiterhin sollte man die Erreichbarkeit kurz umreissen und die
+Haeufigkeit, mit der das Objekt an Spieler gelangt. Auch hierbei gilt, dass
+man das Objekt moeglichst kurz, aber eindeutig beschreibt.
+
+Die Genehmigung oder Ablehnung eines Antrags durch die Objektbalance ist
+bindend. Eigenschaften, die in der Antwort aufgefuehrt sind, sind
+festgeschrieben und beduerfen bei Aenderung eines Neuantrages (das geht in
+der Regel recht schnell, wenn der Magier nicht das Objekt komplett umkrempelt).
+Sollten nicht festgeschriebene Eigenschaften, die das Spielgeschehen
+beeinflussen (die es eigentlich nicht geben sollte), geaendert werden, muss die
+Balance informiert werden. Bei jeglichem Mailverkehr zu einem Objekt, sollte
+die btop Nummer angegeben werden, die in der ersten Mail zu dem Objekt
+angegeben sein sollte. Ist dies nicht der Fall, erfrage diese Nummer bitte bei
+einem der Teammitglieder. Nach Genehmigung des Objektes, sollte diese Nummer
+auch in den Kopf der Datei(en) geschrieben werden.
+
+Bei einem Antrag kommt es immer wieder zu Misverstaendnissen oder
+Zweideutigkeiten. Daher ist es die Regel, dass noch mal nachgefragt wird,
+wie denn genau etwas ablaufen oder implementiert werden soll. Eine schnelle
+Beantwortung dieser Fragen beschleunigt natuerlich auch den
+Genehmigungsprozess. Missfallen dem Balanceteam einzelne Eigenschaften,
+Implementierungen oder Werte, werden haeufig Vorschlaege gemacht, die die
+Akzeptanz eines Objektes durch die Balance entscheidend verbessern. Die
+Mitglieder bemuehen sich, den Genehmigungsprozess so reibungslos und
+konfliktarm wie moeglich ablaufen zu lassen. Solche Aenderungsvorschlage sind
+weder Belehrungen noch boese gemeint, sondern sollen dazu dienen die
+Balancierung zu vereinfachen, zu beschleunigen und Bedenken von
+Balancemitgliedern entgegenzukommen.
+
+Zum Schluss noch ein Antrag, wie er aussiehen koennte:
+
+Antrag fuer ein Zweihandschwert
+-------------------------------
+
+Name: Der Perforator
+Pfad: /d/region/magier/gebiet/obj/perforator.c
+ /d/region/magier/gebiet/obj/loch.c
+P_WEAPON_TYPE: WT_SWORD
+P_WC: 200
+P_NR_HANDS: 2
+P_VALUE: 15000
+P_WEIGHT: 1500
+P_DAM_TYPE: ({DT_PIERCE, DT_UNHOLY})
+HitFunc: unter Umstaenden random(50)
+K_BRAWLING_WC: 25
+K_CRITICAL_HIT: 80
+
+Pseudo-Unique: Es gibt 10 Stueck, wird ein Elftes gebraucht, wird
+das mit der aeltesten Clonezeit zerstoert.
+
+Restriktionen: MiniQuest, Seher, Beteiligung beim Ermetzeln
+
+Beschreibung: Der Perforator perforiert den Gegner. Ist noch kein Loch
+in dem Gegner, wird eins reingepiekt und macht dabei zusaetzlich random(50)
+Schaden. Danach ist ein Loch im Gegner und er verliert jede Runde 10 +
+random(10) HP durch Blutverlust per reduce_hit_points() fuer 10 Runden.
+Ist der Traeger des Schwerts noch im Raum, bekommt er diesen Schaden
+gutgeschrieben, weil das Schwert das Blut trinkt. Ist das Loch weg, gibt es
+kein weiteres.
+
+Das Schwert hat ein schweres, mit Dornen versehenes Heft (BRAWLING_WC) und
+ist rasiermesserscharf, so dass es sich fuer einen Todesstoss gut eignet.
+Das Schwert hat einen Fluch, der es blutdurstig macht und DT_UNHOLY erklaert.
+
+Um das Schwert zu bekommen, braucht man eine Miniquest, die ca 20 AP geben
+wuerde. Am Ende kommt man an einen Endgegner, den man im Team hauen muss,
+alle Mitglieder muessen die Miniquest gerade machen. Zuecken kann das Schwert
+nur jemand, der die Miniquest schon hat und mindestens 20% des Schadens gemacht
+hat. Von dem Schwert gibt es immer nur 10 Stueck, das aelteste wird beim
+clonen des NPC zerstoert und ein Neues erschaffen.
+
+-----------------------------------
+
+ SIEHE AUCH
+
+ ruestungen, waffen, fernwaffen, uniques, npcs, objects, balance
+ attributsveraenderungen, resistenzen, kampfobjekte, grenzwerte, nachteile
+------------------------------------------------------------------------------
+letze Aenderung: 18.10.2005 23:41 - Miril
diff --git a/doc/wiz/befoerderungen b/doc/wiz/befoerderungen
new file mode 100644
index 0000000..f680c08
--- /dev/null
+++ b/doc/wiz/befoerderungen
@@ -0,0 +1,66 @@
+Eine kleine Uebersicht ueber die Befoerderungspolitik im MG
+-----------------------------------------------------------
+
+ Level 1 -> 15:
+ WANN:
+ Man muss Seher sein. (s. auch "hilfe magier")
+ WER:
+ 26+ (siehe auch "hilfe vertrag")
+ RECHTE:
+ Eingeschraenkte Leserechte auf der Lib.
+
+ Level 15 -> 20:
+ WANN:
+ Mindestens eine Woche seit dem Anstieg auf 15, damit
+ Einsprueche gegen den Charakter nicht uebergangen werden.
+ Konzept fuer GS
+ WER:
+ Prinzipiell 66+
+ Normalerweise aber EM Gesellenstuecke und Zook
+ RECHTE:
+ Leserechte auf allgemeine Verzeichnisse, eigenes Verzeichnis, Clonen.
+
+ _Alternativ_ gibt es weitere Moeglichkeit:
+ Level 0 -> 20:
+ WANN:
+ Man muss einen Seher als Erstie und ein von den EMs genehmigtes
+ Konzept fuer ein GS haben. Desweiteren verpflichtet man sich, das
+ GS innerhalb von 6 Monaten fertigzustellen. (s. "hilfe magier")
+ WER:
+ EMs (siehe auch "hilfe vertrag")
+ RECHTE:
+ Eingeschraenkte Leserechte auf der Lib.
+
+
+ Level 20 -> 21:
+ WANN:
+ nach GS-Abnahme
+ WER:
+ EM fuer Gesellenstuecke.
+ RECHTE:
+ Normale Leserechte.
+
+ Level 21 -> 25:
+ WANN:
+ Magier hat etwas fuer eine Region geproggt, was angeschlossen
+ wurde/wird.
+ WER:
+ 45
+ RECHTE:
+ Schreibrechte in der Domain. Vergabe durch zustaendigen RM.
+
+ Level 25 -> 26+:
+ WANN:
+ Magier wird fuer faehig und selbststaendig gehalten.
+ WER:
+ 45
+ RECHTE:
+ Kann nun selbst Spieler sponsoren.
+
+ Vorsicht: dieses Dokument ist im stetigen Wandel und stellt nur die
+ allgemeine Politik dar - sich drauf berufen gilt nicht.
+
+SIEHE AUCH:
+ erzmagier, balance
+
+27.10.2009, Zesstra
\ No newline at end of file
diff --git a/doc/wiz/benennung b/doc/wiz/benennung
new file mode 100644
index 0000000..fe94ebc
--- /dev/null
+++ b/doc/wiz/benennung
@@ -0,0 +1,158 @@
+AUTOR MG, den 22.08.92, Don Rumata
+ This file is part of the Morgengrauen-Mudlib from Jof and Rumata
+
+VERSION 1.1
+
+AKTUALISIERT: MG, den 14.10.93, Chris
+UEBERARBEITET: am 24.08.94 von Viper
+
+THEMA BENENNUNG VON OBJEKTEN IM MorgenGrauen
+
+INHALT:
+ I. Einleitung
+ II. Funktionen, die alle Objekte besitzen muessen
+ III. Unterstuetzung der Funktionen durch die MG_mudlib
+ IV. Benennung von Raeumen
+ V. Benennung von Monstern
+
+I. EINLEITUNG
+
+ Jedes Objekt in der Mudlib muss auf folgende Weisen identifiziert
+ werden koennen:
+
+ 1.) Es muss einen Namen haben, der innerhalb eines Satzes das
+ Objekt bezeichnen kann.
+
+ 2.) Es muss eine Kurzbeschreibung besitzen.
+
+ 3.) Es muss eine ausfuehrliche Beschreibung besitzen.
+
+ 4.) Es muss eine Menge von Synonymen kennen, mit denen ein
+ Spieler das Objekt "ansprechen" kann.
+
+II. FUNKTIONEN, DIE ALLE OBJEKTE BESITZEN MUESSEN
+
+ Jedes Objekt im MorgenGrauen sollte folgende Funktionen
+ implementiert haben:
+
+ 1.) name( fall, dem )
+
+ Diese Funktion soll den Namen des Objektes im jeweiligen
+ Fall mit Artikel (wenn es einen besitzt) zurueckgeben, so
+ dass der Rueckgabewert in einen Satz eingearbeitet werden
+ kann.
+
+ "fall" dient zur Deklination des Objektnamens.
+
+ "dem" bestimmt, welche Artikel benutzt werden sollen.
+ Moegliche Werte fuer "dem":
+
+ 0 Benutze unbestimmte Artikel.
+
+ 1 Benutze bestimmte Artikel.
+
+ 2 Benutze bestimmte Artikel, wenn sich mit dem Objekt
+ kein gleichartiges Objekt im selben Raum befindet,
+ sonst benutze einen unbestimmten.
+
+ Statt der 2 kann auch ein String uebergeben werden.
+ In diesem Fall wird getestet, ob sich ein Objekt mit
+ dem String als id im selben Raum befindet.
+
+ 2.) short()
+
+ Diese Funktion liefert eine Beschreibung, die ausgegeben
+ wird, wenn der Raum, in dem das Objekt sich befindet,
+ betrachtet wird.
+
+ 3.) long()
+
+ Diese Funktion liefert eine Beschreibung, die ausgegeben
+ wird, wenn das Objekt angeschaut wird. Im Unterschied zur
+ 2.4.5 Mudlib wird die Beschreibung jedoch nicht ausgegeben,
+ sondern als return-Wert zurueckgegeben.
+
+ 4.) id( str )
+
+ Diese Funktion soll 1 zurueckgeben, wenn str eine Zeichen-
+ folge ist, die das Objekt bezeichnen koennte. Diese Zeichen-
+ folge wird in kleinen Buchstaben uebergeben.
+
+ 5.) _query_invis()
+
+ Wenn ein Objekt unsichtbar ist, soll es beim Aufruf dieser
+ Funktion 1 zurueckgeben. Sichtbare Objekte brauchen diese
+ Funktion nicht zu implementieren.
+
+III. UNTERSTUETZUNG DER FUNKTIONEN DURCH DIE MG_MUDLIB
+
+ Wenn ein eigenes Objekt aus den Standardobjekten abgeleitet
+ wird, sind alle diese Funktionen bereits fertig definiert.
+ Es muessen beim Erzeugen der Objekte nur noch die entsprechenden
+ Werte mitgeteilt werden. Dieses geschieht mit folgenden Funk-
+ tionen, die am besten im create() aufgerufen werden.
+
+ 1.) SetProp( P_NAME, string );
+
+ In name() wird der uebergebene String dekliniert und automatisch
+ mit Artikeln versehen. Diese Funktion bedenkt auch Faelle, an
+ die ihr wahrscheinlich nie gedacht habt. Der Genitiv von der
+ Lahme ist z.B. des Lahmen! Auch fuer andere Faelle bietet diese
+ Funktion maechtige Unterstuetzung.
+
+ Wenn der String nicht mit Artikeln versehen werden soll, so kann
+ man das mittels der Funktion "SetProp(P_ARTICLE, 0 )" erreichen.
+
+ Damit die Funktion name() ueberhaupt den richtigen Artikel
+ auswaehlen kann, muss man mit "SetProp( P_GENDER, gender)" das
+ Gechlecht des Objektes bekannt machen. Als gender kann man
+ MALE oder 1, FEMALE oder 2 und NEUTER oder 0 verwenden.
+
+ Ist das Objekt unsichtbar, so darf string trotzdem nicht 0 sein;
+ stattdessen ist "SetProp( P_INVIS, 1 )" aufzurufen. (Die Zeile
+ "#include <properties.h>" nicht vergessen. :-))
+
+ Da dieses Verfahren sehr fehleranfaellig ist, ist fuer den Namen
+ ein Array von Namen zugelassen, so dass fuer jeden Fall ein Wort
+ uebergeben werden kann. Beispiel.:
+ SetProp( P_NAME, ({ "Mensch", "Menschen", "Menschen", "Menschen" }) );
+
+ 2.) SetProp( P_SHORT, string )
+
+ In short() wird der uebergebene String ausgegeben. Mittels des
+ process_string-Mechanismus (siehe /doc/efun/process_string)
+ koennen auch varibale Teile in dem String vorkommen.
+ string braucht fuer unsichtbare Objekte nicht auf 0 gesetzt
+ werden.
+
+ 3.) SetProp( P_LONG, string )
+
+ Dito.
+
+ 4.) AddId( string );
+
+ Nehme den String in die Menge der Zeichenketten auf, auf die die
+ eingebaute id-Funktion mit 1 antworten soll.
+
+ 5.) Es reicht, SetProp( P_INVIS, 1 ) aufzurufen, wenn das
+ Objekt unsichtbar wird, und SetProp( P_INVIS, 0 ), wenn es wieder
+ sichtbar wird.
+
+IV. BENENNUNG VON RAEUMEN
+
+ Bei Raeumen wird die long() bzw. short()-Beschreibung nur dann
+ benutzt, wenn der Raum *von aussen* angeschaut wird. Fuer eine
+ Beschreibung des Raumen von innen sind folgende Funktionen
+ bereitgestellt:
+
+ 1.) SetProp( P_INT_SHORT, string );
+
+ Gebe eine Beschreibung des Raumes fuer den "kurz"-Modus aus.
+
+ 2.) SetProp( P_INT_LONG, string );
+
+ Gebe eine ausfuehrliche Beschreibung des Raumes zurueck.
+
+V. BENENNUNG VON MONSTERN
+
+ Siehe oben unter /doc/MG/BANISH.
diff --git a/doc/wiz/called_by_player b/doc/wiz/called_by_player
new file mode 100644
index 0000000..897f546
--- /dev/null
+++ b/doc/wiz/called_by_player
@@ -0,0 +1,8 @@
+void BecomesNetDead(object player) wird im Raum aufgerufen, wenn dort ein
+ Spieler netztot wird. player ist der Spieler.
+
+void PlayerQuit(object player) wird im Raum aufgerufen, wenn darin ein
+ Spieler quittet.
+
+void exit() wird im Raum aufgerufen, wenn ein Lebewesen rausgemoved wird.
+ Das Lebewesen ist previous_object()
diff --git a/doc/wiz/enttanken b/doc/wiz/enttanken
new file mode 100644
index 0000000..9a47d47
--- /dev/null
+++ b/doc/wiz/enttanken
@@ -0,0 +1,99 @@
+Enttanken
+=========
+
+ Generelles:
+ **********
+
+ALLE Enttank-Moeglichkeiten MUESSEN ortsabhaenig sein.
+Ausnahmen KANN es fuer Questbelohnungen geben.
+
+Toiletten
+---------
+Toiletten rufen die Methoden "defuel_drink" bzw. "defuel_food" im Spieler auf.
+Es werden keine Parameter uebergeben. Rueckgabewerte sind entweder die Fehler
+NO_DEFUEL, wenn man nichts zu Enttanken hat, DEFUEL_TOO_LOW, wenn man nicht
+genug im Magen/Blase hat, DEFUEL_TOO_SOON, wenn man noch nicht
+wieder enttanken darf, ODER der enttankte Wert.
+Beispiel hierzu siehe "man defuel_food".
+
+Man darf DANN enttanken, wenn man mindestens den Fuellwert P_DEFUEL_LIMIT_FOOD
+bzw. P_DEFUEL_LIMIT_DRINK hat und das letzte Enttanken mindestens
+P_DEFUEL_TIME_FOOD bzw. P_DEFUEL_TIME_DRINK her ist.
+Ist dies der Fall, kann man P_DRINK/FOOD*P_DEFUEL_AMOUNT_DRINK/FOOD enttanken,
+wobei dies zur Haelfte ueber ein Random geglaettet wird.
+
+Wer regulaer ueber "defuel_drink" enttankt, enttankt auch automatisch eine
+gewisse Menge an Alkohol. Diese Menge ist von der enttankten Menge, von dem
+im Koerper sich befindenen Alkohol und vom Gewicht des Spielers abhaengig.
+
+Alle genannten Props sind rassenabhaengig.
+Die Berechnungen sind gekapselt in "defuel_food/drink".
+
+Andere Objekte
+--------------
+
+Hier bietet sich an, die zeitliche Nutzung der Enttanke spielerbezogen
+mittels der Methode check_and_update_timed_key zu steuern. Dabei sollte
+der zeitliche Abstand nicht zu knapp sein, in der Regel im Bereich von
+ca. einer Stunde. Der eigentliche Enttankvorgang im Spieler geschieht
+mittels eat_food, drink_soft oder drink_alcohol durch Uebergabe negativer
+Werte. Der Betrag dieses Wertes sollte der Erreichbarkeit angemessen sein,
+d.h. leichter erreichbare Enttanken sollten auch nicht zu viel enttanken,
+wenn sie den Spieler komplett enttanken sollen, muessen sie entsprechend
+schwer zu erreichen sein.
+Da die Enttanken ortsabhaengig sind und in der Regel erst erforscht
+werden muessen, ist eine weitere Begrenzung momentan nicht vorgesehen.
+
+ Spezifisches:
+ ************
+
+----------------------------
+Rassenbeschreibungen fuer Berechnungen in "defuel_food/drink":
+----------------------------
+
+MENSCHEN
+sind wie immer nichts Besonderes und definieren das absolute Mittelmass.
+
+ZWERGE
+koennen mehr in Blase und Magen haben und koennen auch so richtig abladen.
+Dafuer muessen sie laenger warten, bis es sich lohnt, zu enttanken.
+
+ELFEN
+sind inkontinent und Kleinmengengeber.
+
+DUNKELELFEN
+sind von den Werten her in etwa wie Elfen.
+
+HOBBITS
+koennen essen bis zum Umfallen. Sie laden dann richtig ab, muessen aber auch
+entsprechend warten.
+
+FELINEN
+sind den Menschen aehnlich.
+
+ORKS
+sind auch nichts Besonderes.
+
+Wer die genauen Werte einsehen moechte, moege in den shells nachgucken.
+
+ Logisches:
+ *********
+
+Jede (!) Moeglichkeit zur Enttankung, muss dem zustaendigen Magier
+fuer Heilungs-Balance gemeldet und von diesem genehmigt werden. Wer
+diesen Posten momentan innehat, kann dem MailAlias "heilungs_balance"
+entnommen werden.
+
+Siehe auch:
+----------
+ Tanken: consume, drink_alcohol, eat_food, drink_soft
+ Heilung: heal_self, restore_spell_points, restore_hit_points,
+ buffer_hp, buffer_sp
+ Timing: check_and_update_timed_key
+ Enttanken: defuel_drink, defuel_food
+ Props: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+ P_DEFUEL_TIME_DRINK
+ Konzepte: heilung, food
+
+----------------------------------------------------------------------------
+Last modified: 02.11.2005 - Miril
diff --git a/doc/wiz/familien b/doc/wiz/familien
new file mode 100644
index 0000000..39bf831
--- /dev/null
+++ b/doc/wiz/familien
@@ -0,0 +1,24 @@
+Eine Familie umfasst den Erstie und alle Zweities, sprich alle diese haben den
+gleichen "Familiennamen". Dieser Name ist in der Regel die UUID des Ersties
+dieser Familie. Falls aber der Erstie sich aendern sollte (z.B. Magierwerdung
+eines Zweities) und sich der Familienname nicht aendern soll, dann koennen
+wir den Namen dieser Familie beibehalten (d.h. alter Erstie).
+
+Will man wissen, welcher Familie ein Char angehoert (egal, ob Erstie oder
+Zweitie), dann geht das mit:
+# xcall /secure/zweities->QueryFamilie(player_object)
+
+Des Weiteren liefert dieses Objekt auch noch zu jedem Zweitie den Erstie und
+zu jedem Erstie die Liste aller bekannten Zweities:
+# xcall /secure/zweities->QueryErstieName(player_object)
+# xcall /secure/zweities->QueryErstieUUID(player_object)
+# xcall /secure/zweities->QueryZweities(player_object)
+
+Der Datenbestand ist (noch) nicht vollstaendig, daher fehlen da noch viele
+Chars. Die werden aber in absehbarer Zeit dort nachgetragen.
+
+Die Familie wird in Zukunft genutzt, um Dinge zu personalisieren, welche fuer
+den Spieler, aber nicht fuer den Char individuell sein sollen. Sprich:
+personalisiert man irgendwas ueber die Familie, koennen alle Chars dieser
+Familie das irgendwas nutzen.
+
diff --git a/doc/wiz/fehlerteufel b/doc/wiz/fehlerteufel
new file mode 100644
index 0000000..7b0b916
--- /dev/null
+++ b/doc/wiz/fehlerteufel
@@ -0,0 +1,181 @@
+Der Fehlerteufel
+================
+
+die Mudlib speichert die aufgetretenen Fehler und Warnungen. Dabei werden
+folgende Daten mitgespeichert:
+- Zeit (erstes Mal, zuletzt)
+- In welchem Objekt und welchem Programm der Fehler war
+- Zeilenr.
+- Fehlermeldung
+- Objekt, dessen Heartbeat, den Fehler ausloeste
+- this_interactive() bzw. this_player()
+- den Befehl, den TI eingegeben hat
+- das Environment von TI oder TP
+- wie oft der Fehler schon auftrat
+- der Backtrace
+- ob der Fehler in einem catch() auftrat
+
+Zusaetzlich werden von Spielern per "bug", "fehler" oder "sonnenfehler"
+gemeldete Fehler gespeichert.
+
+Der Fehlerteufel dient nun dazu, sich diese Infos darstellen zu lassen. Nach
+dem Clonen von /obj/tools/fehlerteufel habt ihr folgende Moeglichkeiten:
+
+- fehlerliste <auswahl s. Kommando fehlermodus>
+ Dieser Befehl stellt euch eine Liste aller bekannten Fehler dar, die unter
+ einer UID auftraten, fuer die ihr zustaendig seid (z.B. "zesstra",
+ "d.inseln.zesstra", "GUILD.magierpack", s. auch QueryUIDsForWizard()). Die
+ Liste umfasst die eindeutige Fehler-ID, den Ladenamen des fehlerausloesenden
+ Objekts und die UID.
+ Je nach Argument werden div. Fehler oder Warnungen ausgegeben. Wird keins
+ von beiden angegeben, wird je nach Einstellung von 'fehlermodus' aufgelistet.
+
+- fehlerabfrage <id>
+ Hiermit lassen sich die Detail-Informationen zu <id> anzeigen. <id> bekommt
+ ihr entweder aus "fehlerliste" oder von -debug/-entwicklung/-warnungen, dort
+ werden diese IDs mit ausgegeben. Ohne Angabe der <id> wird der letzte
+ betrachtete Fehler ausgegeben.
+ Neben der numerischen ID ist hierbei auch die Hash-ID moeglich.
+ Es kann auch der Ladename eines Objekts angegeben werden, dann werden alle
+ zu diesem Objekt gehoerenden Eintraege auf einmal angezeigt, z.B.
+ fehlerabfrage /d/unterwelt/raeume/wald3
+ Der Ladename muss mit einem / beginnen.
+
+- fehlerloeschen <id>
+ Fehler mit der ID <id> zum Loeschen markieren (z.B. wenn gefixt). Die
+ eigentlich Loeschung findet innerhalb von 24h statt. Die Fehler werden nach
+ diesem Befehl nicht mehr in der Fehlerliste angezeigt. Ohne Angabe der <id>
+ wird der letzte benutzte Fehler geloescht.
+ Wiederholt man den Befehl, wird die Loeschmarkierung wieder entfernt.
+ Es kann auch der Ladename eines Objekts angegeben werden, dann werden alle
+ zu diesem Objekt gehoerenden Eintraege auf einmal geloescht, z.B.
+ fehlerloeschen d/unterwelt/raeume/wald3
+
+- fehlereingabe <objekt>
+ Hiermit laesst sich per Hand ein Eintrag fuer das angegebene Objekt im
+ Fehlerteufel erstellen. Das Objekt kann mit einer seiner IDs oder seinem
+ vollstaendigen Objektnamen angegeben werden. Wird kein Objekt angegeben,
+ wird die Umgebung des Magiers als Objekt genutzt. Bsp:
+ fehlereingabe seil
+ fehlereingaeb /obj/seil#5635
+
+- fehlerrefresh
+ Der Fehlerteufel hat einen Zwischenspeicher fuer die Fehlerliste. Dieser
+ Befehl loescht diesen Zwischenspeicher und holt die Fehlerliste neu.
+
+- fehlerfilter
+ Hiermit laesst sich ein Filter fuer UIDs einstellen. (s.u.) Ist er aktiv,
+ werden per 'fehlerliste' keine Fehler mehr angezeigt, die im Filter
+ eingetragen wurden.
+
+- fehlermodus <fehler|warnungen>
+ Einstellen, welche Arten von Eintraegen im Fehlerteufel vom Kommando
+ 'fehlerliste' ausgegeben werden soll:
+ laufzeitfehler: Laufzeitfehler werden ausgegeben (-debug, -entwicklung)
+ laufzeitwarnungen: Laufzeitwarnungen werden ausgegeben (-warnungen)
+ ladezeitfehler: Fehler beim Laden eines Objekts werden ausgegeben
+ ladezeitwarnungen: Warnungen beim Laden eines Objekts werden ausgegeben
+ fehlerhinweise: Fehler, die Spieler/Magier abgesetzt haben
+ ideen: Ideen, die Spieler/Magier abgesetzt haben
+ typos: Typos, die Spieler/Magier abgesetzt haben
+ md: Fehlende Details, die Spieler/Magier abgesetzt haben
+ fehler: alle moeglichen Fehler werden ausgegeben
+ warnungen: alle moeglichen Warnungen werden ausgegeben
+ alle: alle Fehler + Warnungen werden ausgegeben
+
+ Ohne Argument: aktuellen Modus ausgeben.
+
+- fehlermonitor
+ Hiermit lassen sich UIDs angeben, die man zusaetzlich zu den eigenen
+ auch noch beobachten will.
+ Hierbei sind auch einige UID-Aliase moeglich, z.B. 'magier', 'region',
+ 'p.service', 'p' oder 'gilde'.
+ BTW: nach Aenderung dieser Liste sollte man "fehlerrefresh" aufrufen.
+
+- flock <id> <bemerkung>
+ So markierte Fehler werden nicht mehr automatisch (nach 31 Tagen ohne
+ Aenderung) geloescht. ABER: Solcherart gesperrte Fehler werden momentan
+ _niemals_ automatisch geloescht, deshalb denkt bitte daran, sie entweder
+ selber zu loeschen oder sie wieder freizugeben, wenn ihr sie nicht mehr
+ braucht.
+
+- funlock <id> <bemerkung>
+ Gibt den Fehler wieder zum automatischen Loeschen frei.
+
+- ffix <id> <bemerkung zum fix>
+ Fehler wird als "gefixt" markiert und eine Mail an alle fuer das buggende
+ Objekte zustaendigen Magier geschickt (soweit bekannt). Anschliessend
+ werden die Fehler vom Fehlerteufel nicht mehr angezeigt.
+ Im Falle von durch Spieler berichteten Fehlern wird dem jeweiligen Spieler
+ beim Fixen ebenfalls eine Mail geschickt.
+ Als gefixt markierte Fehler werden nach einiger Zeit geloescht.
+ Es empfiehlt sich fuer eigene Fehler, diese nach Beheben einfach zu
+ Loeschen, wenn man keine Mail ueber den Fehler erhalten moechte.
+
+- funfix <id> <bemerkung warum der Bugfix scheisse war ;)>
+ Wenn ihr bis zu der "Archivierung" gefixter Fehler feststellt, dass ihr den
+ Fehler wohl doch nicht gefixt habt, koennt ihr das wieder rueckgaengig
+ machen.
+
+- fnotiz <id> <bemerkung>
+ Wenn euch an so einem Fehler was auffaellt oder ihr eine Idee habt, koennt ihr
+ das so also "verewigen". Notizen kann jeder Magier an Fehler dranhaengen,
+ dafuer braucht man keine besonderen (Schreib)Rechte. Die Notizen werden vom
+ Fehlerteufel ausgegeben und stehen auch im CHANGELOG.
+ Anmerkung: Es gibt (absichtlich) keine Moeglichkeit, Notizen wieder zu
+ loeschen.
+
+- fuebertrage <id> <newuid> <bemerkung>
+ Wenn ihr einen Fehler habt, fuer den ihr nicht zustaendig seid, weil der
+ Ursprung des Fehlers nicht in einem eurer Files liegt, koennt ihr diesen
+ Fehler an eine andere UID mit einer Bemerkung uebertragen. Danach ist der
+ Magier von <newuid> zustaendig und hat Schreibrechte auf den Fehler.
+ <newuid> kann z.B. sowas wie 'd.inseln.zesstra' oder 'zesstra' sein. Liegt
+ der Fehler in einem Objekt in /d/, solltet ihr auf jeden Fall
+ d.region.magier benutzen, damit ggf. der RM der Region auch zustaendig wird.
+
+UID-Filter:
+ a) fehlerfilter an
+ Schaltet den Filter ein
+ b) fehlerfilter aus
+ schaltet den Filter aus
+ c) fehlerfilter alle
+ schaltet den Filter ein _und_ schreibt alle UIDs, fuer die man zustaendig
+ ist, in den Filter, es wird dann nichts mehr angezeigt.
+ d) fehlerfilter keine
+ schaltet den Filter ein _und_ loescht den Filter, d.h. es wird trotzdem
+ erstmal noch nix gefiltert..
+ e) fehlerfilter +zesstra +d.inseln.zesstra -d.ebene.zesstra
+ Fuegt "zesstra" und "d.inseln.zesstra" den aktuellen Filtereinstellungen
+ hinzu und loescht "d.ebene.zesstra" aus dem Filter.
+ Beliebige Kombinationen moeglich. Ohne - oder + am Anfang wird jeweils
+ invertiert, also hinzugefuegt, wenn noch nicht drin und entfernt, wenn
+ schon in der Liste.
+
+Fehler-Monitor:
+ a) fehlermonitor keine
+ Loescht alle beobachteten UIDs
+ b) fehlermonitor +atamur -d.polar.atamur
+ Fuegt "atamur" der Beobachtungsliste hinzu und entfernt "d.polar.atamur".
+ Beliebige Kombinationen moeglich. Ohne - oder + am Anfang wird jeweils
+ invertiert, also hinzugefuegt, wenn noch nicht drin und entfernt, wenn
+ schon in der Liste.
+
+Zugriffsrechte:
+ - Lesen und Anhaengen (Notizen, Loeschsperren) darf jeder Magier
+ - Loeschen, Fixen und UID neu zuordnen duerfen fuer die UID zustaendige Magier
+ - Fixes zurueckziehen darf jeder Magier (solange issue nicht expired)
+ - EM+ duerfen alles
+
+Randbemerkung:
+ Moechte man nicht, dass vom Magier selbst ausgeloeste Fehler in /players/
+ protokolliert werden, kann der Magier _in sich_ die Prop P_DONT_LOG_ERRORS
+ (aus /secure/errord.h) auf 1 setzen.
+ ACHTUNG: das bedeutet, dass ueber Fehler keine Informationen mehr
+ vorliegen, die beim Fixen helfen koennen. Bedenkt das bitte, wenn ihr die
+ Prop setzt.
+
+
+SIEHE AUCH:
+ QueryUIDsForWizard(), QueryWizardForUID()
+
diff --git a/doc/wiz/fernkampfwaffen b/doc/wiz/fernkampfwaffen
new file mode 100644
index 0000000..f8dd285
--- /dev/null
+++ b/doc/wiz/fernkampfwaffen
@@ -0,0 +1,128 @@
+Zusammenfassung zu Fernkampfwaffen
+==================================
+
+ Schusswaffe:
+ ============
+ Standardobjekt: /std/ranged_weapon.c
+
+ P_WC: gibt den Schaden im Nahkampf an (wenn man damit auf einen
+ Gegner einpruegelt. Default 30.
+ P_QUALITY: nur beim Nahkampf relevant. Default 100.
+ P_NR_HANDS: Boegen und Armbrueste sind in jedem Fall zweihaendig.
+ P_SHOOTING_WC: Die Basis-Waffenklasse der Fernwaffe.
+ P_RANGE: Reichweite der Waffe. Default 50.
+ P_STRETCH_TIME: Anzahl der Runden, die zum Laden/Spannen der Waffe
+ benoetigt werden. Default 1.
+ P_AMMUNITION: Benoetigter Munitionstyp.
+
+ Eine HitFunc wirkt sich auf die P_WC aus, nicht auf P_SHOOTING_WC!
+
+ Methoden:
+ static int cmd_shoot(string str);
+ * Befehlsauswertung und Schussvorbereitung, wird durch
+ AddCmd( ({"schiess", "schiesse"}), "cmd_shoot");
+ verknuepft
+
+ static int shoot_dam(mapping shoot);
+ * Schadensermittlung
+
+ static string FindRangedTarget(string str, mapping shoot);
+ * Gegnerermittlung
+
+ Munition:
+ =========
+ Standardobjekt: Nutzung von /std/unit ist empfohlen
+
+ P_SHOOTING_WC: legt die Munitionsstaerke fest
+ P_DAM_TYPE: legt die Schadensart des Schussangriffs fest
+
+ Eine HitFunc in der Munition wirkt sich auf P_SHOOTING_WC aus!
+
+ Allgemeines:
+ ============
+ In der Waffe legt man ueber P_AMMUNITION fest, welche Art Munition
+ damit verschossen werden kann. In der Munition muss diese Munition
+ auch als ID gesetzt werden.
+
+ Ueber P_STRETCH_TIME legt man fest, alle wieviel Runden die
+ Fernkampfwaffe abgefeuert werden kann (default: 1).
+
+ Der verursachte Schaden wird aus der Staerke der Fernkampfwaffe
+ und der Staerke der Munition bestimmt. In beiden wird diese in der
+ Property P_SHOOTING_WC angegeben.
+
+ Zusaetzlich kann man in P_RANGE die Reichweite der Fernkampfwaffe
+ festlegen. Hat man einen Raum A, der sich innerhalb eines anderen
+ Raumes befindet (z.B. Transporter), so kann man mittels P_SHOOTING_AREA
+ dessen 'Groesse' festlegen. Mit einer Waffe, deren P_RANGE mindestens
+ gleich diesem Zahlenwert ist, kann aus diesem Raum heraus geschossen
+ werden.
+ Alternativ kann man in A einen anderen Raum B)in die Property
+ P_TARGET_AREA schreiben.
+
+BEISPIEL:
+ // #1 siehe auch /doc/beispiele/fernwaffen fuer ladbaren Code
+
+ // #2 eine einfache, aber gute Schleuder
+ inherit "/std/ranged_weapon";
+
+ void create() {
+ if (!clonep(this_object())) return;
+ ::create();
+
+ SetProp(P_SHORT, "Eine Schleuder");
+ SetProp(P_INFO,
+ "Die Syntax lautet: schleuder <geschoss> auf <ziel>\n");
+ // sonstige Objektprops ...
+
+ RemoveCmd(({"schiess", "schiesse"})); // entferne Default-Kommando
+ AddCmd(({"schleuder", "schleudere"}), #'cmd_shoot);
+
+ SetProp(P_WC, 10); // eine Schleuder ist erstmal harmlos
+ SetProp(P_DAM_TYPE, DT_WHIP);
+
+ SetProp(P_SHOOTING_WC, 90); // ziemlich gute Schleuder
+ SetProp(P_NR_HANDS, 1); // einhaendig
+ SetProp(P_WEAPON_TYPE, WT_RANGED_WEAPON);
+ SetProp(P_AMMUNITION, MUN_STONE);
+ SetProp(P_STRETCH_TIME, 1);
+ SetProp(P_RANGE, 30); // 30 weit kann man damit nur schleudern
+ }
+
+ // #3 passende Munition
+ inherit "/std/unit";
+
+ void create() {
+ if (!clonep(this_object())) return;
+ ::create();
+
+ SetProp(P_NAME, ({"Schleuderstein", "Schleudersteine"}) );
+ SetProp(P_LONG, break_string(
+ "Hervorragend geformte Schleudersteine aus Murmelnit.", 78));
+ SetProp(P_GENDER, MALE);
+ SetProp(P_AMOUNT, 1);
+ SetProp(P_SHOOTING_WC, 50);
+ SetProp(P_DAM_TYPE, ({DT_BLUDGEON}));
+ SetProp(P_WEAPON_TYPE, WT_AMMU);
+ SetProp(P_MATERIAL, MAT_STONE);
+
+ SetGramsPerUnits(60,1);
+ SetCoinsPerUnits(25,1);
+
+ AddId(MUN_STONE);
+ AddSingularId(({"stein", "schleuderstein"}));
+ AddPluralId(({"steine", "schleudersteine"}));
+ AddClass(CL_AMMUNITION);
+ }
+
+SIEHE AUCH:
+ Generell: P_SHOOTING_WC, P_STRETCH_TIME, P_AMMUNITION
+ Methoden: FindRangedTarget(L), shoot_dam(L)
+ Gebiet: P_RANGE, P_SHOOTING_AREA, P_TARGET_AREA
+ Waffen: P_WEAPON_TYPE, P_WC, P_EQUIP_TIME, P_NR_HANDS
+ Kampf: Attack(L), Defend(L), P_DISABLE_ATTACK, P_ATTACK_BUSY
+ Team: PresentPosition(L)
+ Sonstiges: P_NOGET
+ Balance: fernwaffen, waffen, balance
+
+29.Jul 2014 Gloinson
\ No newline at end of file
diff --git a/doc/wiz/fernwaffen b/doc/wiz/fernwaffen
new file mode 100644
index 0000000..947c517
--- /dev/null
+++ b/doc/wiz/fernwaffen
@@ -0,0 +1,118 @@
+
+ FERNWAFFEN
+
+ a. Allgemeines
+ Fernwaffen sind eine relativ neue Ergaenzung zum Kampfsystem dieses Muds,
+ die mit der Einfuehrung des Teamkampfes erst moeglich wurde.
+ Schon bisher gab es einzelne Fernwaffen (z.B. Robins Bogen), die aber
+ Inselloesungen und Sonderfaelle waren. Das neue Standardobjekt fuer
+ Fernwaffen ist nun /std/ranged_weapon.c, das die noetige Funktionalitaet
+ bietet und leicht ueber Properties zu konfigurieren ist. Mit Fernwaffen
+ sind uebrigens ausnahmslos Waffen gemeint, die Munition benoetigen,
+ nicht etwa Speere oder dergleichen.
+
+ ** Bisher sind alle Fernwaffen ausnahmslos genehmigungspflichtig, das **
+ ** gilt auch fuer jegliche Munition. **
+
+ b. Properties
+ P_WC
+ Vorsicht mit dieser Property. Bei Fernwaffen gibt sie _nur_ den
+ Schaden bei Zweckentfremdung der Waffe als Knueppel an.
+ Dementsprechend ist dieser Wert extrem niedrig zu halten.
+ Standardwert ist hier 30, der auch nur in Ausnahmefaellen
+ ueberschritten werden sollte. Kaum eine Armbrust oder ein Bogen
+ taugt nunmal als grossartige Nahkampfwaffe.
+
+ P_QUALITY
+ Wird nur beim Nahkampf mit der Waffe beachtet. Standardmaessig auf
+ 100 gesetzt, da Boegen und Armbrueste leicht beschaedigt werden,
+ wenn man damit auf jemanden einpruegelt.
+
+ P_HIT_FUNC
+ HitFunc fuer den _Nahkampf_. Hat beim Schuss mit der Waffe keinen
+ Einfluss.
+
+ P_NR_HANDS
+ Boegen und Armbrueste sind in jedem Fall zweihaendig. Einhaendige
+ Fernwaffen sind aber denkbar (Schlingen zum Schleudern kleiner
+ Steine z.B.)
+
+ P_SHOOTING_WC
+ Die Basis-Waffenklasse der Fernwaffe. Zu ihr wird die Waffenklasse
+ der Munition addiert, um den endgueltigen Angriffswert beim Schuss
+ zu berechnen.
+
+ P_RANGE
+ Reichweite der Waffe in Metern. Wichtig, wenn aus Containern
+ (Wachtuermen, Schiffen, etc.) nach aussen geschossen wird.
+ Damit das funktioniert, muss dieser Wert hoeher sein als der
+ im Container definierte (steht dort in der P_SHOOTING_AREA).
+
+ P_STRETCH_TIME
+ Anzahl der Runden, die zum Laden/Spannen der Waffe benoetigt
+ werden. 1 ist hier der Standardwert, das bedeutet, es kann jede
+ Runde geschossen werden.
+
+ P_AMMUNITION
+ Benoetigter Munitionstyp. Hier ist eine der moeglichen Konstanten
+ (MUN_*) einzusetzen (z.B. MUN_ARROW fuer Boegen).
+
+ P_NOGET
+ Hat bei Fernwaffen eine zusaetzliche Bedeutung. Wenn gesetzt, muss
+ die Waffen nicht gezueckt werden, um sie abfeuern zu koennen. Das
+ ist z.B. fuer Katapulte gedacht, die im Raum stehen.
+
+ Fuer die Munition gibt es kein Standardobjekt. Wichtig ist nur, dass
+ die entsprechenden Properties gesetzt sind. Normalerweise sollte die
+ Munition natuerlich eine Unit sein, aber auch Einzelobjekte (ein
+ besonderer Pfeil oder ein grosser Stein fuer ein Katapult) sind
+ moeglich.
+
+ Properties fuer die Munition sind:
+
+ P_SHOOTING_WC
+ Die Waffenklasse der Munition. Wird zur WC der Waffe addiert.
+
+ P_DAM_TYPE
+ Schadenstyp der Munition. Sollte normalerweise DT_PIERCE fuer
+ Pfeile aller Art und DT_BLUDGEON fuer stumpfe Munition wie Steine
+ sein. Magische Schadensarten sind aber natuerlich moeglich.
+
+ P_HIT_FUNC
+ HitFunc, die beim Schuss mit der Munition benutzt wird.
+
+ Ausserdem muss in der Munition mittels AddId() der entsprechende
+ Munitionstyp gesetzt werden, z.B. MUN_ARROW.
+
+ c. Spezialwaffen/Fernwaffen mit Sonderfunktionen
+
+ Siehe Hinweise zu entsprechenden Nahkampfwaffen.
+
+ d. Genehmigungsgrenzen
+ Alle Waffen dieser Art sind grundsaetzlich genehmigungspflichtig.
+ Folgende Werte sollten allerdings Obergrenzen darstellen, die
+ im Normalfall nicht zu Ueberschreiten sind:
+
+ Waffe kann jede Runde abgefeuert werden: P_SHOOTING_WC 100
+ Waffe braucht eine Ladezeit : P_SHOOTING_WC 130
+
+ Die Obergrenze fuer Munition liegt bei : P_SHOOTING_WC 60.
+
+ e. Nachbemerkung
+ Seid bitte vorsichtig mit P_SHOOTING_AREA in Raeumen/Containern.
+ Bisher ist dieses Schiessen von Raum zu Raum weitestgehend ungetestet,
+ und es ist nicht klar, welche Probleme das verursachen kann. Wenn
+ eventuelle Ziele keine Moeglichkeit haben, sich zu wehren oder
+ wegzulaufen, ist schnell jegliche Balance dahin. Die Regionsmagier
+ haben bei Abnahme von Gebieten darauf zu achten, dass diese Property
+ nur in wenigen, gut begruendeten Raeumen gesetzt wird.
+
+ SIEHE AUCH
+
+ balance, ruestungen, waffen, uniques, npcs, grenzwerte,
+ attributsveraenderungen, resistenzen, kampfobjekte,
+ fernkampfwaffen
+
+------------------------------------------------------------------------------
+ LETZTE AeNDERUNG:
+ Don, 10.08.2000, 22:30:00 von Paracelsus
diff --git a/doc/wiz/food b/doc/wiz/food
new file mode 100644
index 0000000..698e3f6
--- /dev/null
+++ b/doc/wiz/food
@@ -0,0 +1,223 @@
+FOOD, DRINK & ALCOHOL
+=====================
+
+ Es wird empfohlen, jede tragbare Heilung ueber "/std/food"
+ zu implementieren. Hier braucht man nur wenige Properties setzen, um
+ sicherzugehen, dass die Heilung korrekt verlaeuft.
+
+ Bitte bei der Realisierung von tragbaren Tanken IMMER mit der Balance
+ sprechen. Die Heilung unterliegt genauer Kontrolle. Ewig haltbare Speisen
+ sind sowieso genehmigungspflichtig und nur mit guter Begruendung und
+ strengen Auflagen erlaubt.
+
+FEATURES:
+ Unterstuetzt wird das Konsumieren von Speisen per Essen oder Trinken auch
+ in mehreren Portionen. Die Speisen verderben und werden vernichtet.
+ Es sind Lebensmittel mit Behaelter moeglich, so dass dieser leer
+ zurueckbleibt, wenn der Inhalt gegessen oder vernichtet wurde.
+ Die Wirkung von Speisen kann neben der Zufuehrung von Lebens- und Konzen-
+ trationspunkten erweitert werden. Die Wirkung verdorbener Speisen kann
+ getrennt definiert werden.
+ Wert und Gewicht der Speise werden in Abhaengigkeit der Restmengen immer
+ korrekt berechnet.
+
+REALISIERUNG:
+ Die Realisierung der Timer laeuft ueber die Resets der Speise. Callouts
+ werden lediglich verwendet, um den Aufruf des Resets zu garantieren.
+ Es wird auch geprueft, dass der Aufruf der Resets per Hand nichts
+ durcheinander bringt.
+
+ Des Weiteren ist sichergestellt, dass der Spieler nicht mit Futter in
+ Beruehrung kommt, dessen Timer zum Verderben initialisiert ist.
+
+ Das Konzept ist dem Heilungskonzept der Kneipen angepasst worden.
+ Dem entsprechend sind die Properties sehr aehnlich.
+
+PROPERTIES:
+
+ P_PORTIONS : Anzahl der Portionen (wie oft kann man abbeissen /
+ einen Schluck nehmen)
+
+ P_FOOD : Fuellgrad der Speise pro Portion, muss gesetzt sein, wenn
+ P_DRINK nicht gesetzt ist
+ P_DRINK : Fuellgrad der Fluessigkeit pro Portion, muss gesetzt sein,
+ wenn P_FOOD nicht gesetzt ist
+ P_ALCOHOL : Alkohollevel pro Portion
+
+ P_WEIGHT : Gewicht pro Portion (bei QueryProp(P_WEIGHT) wird das
+ komplette Gewicht aller Portionen + eventuell Behaelter
+ zurueckgegeben)
+ P_VALUE : Wert pro Portion (bei QueryProp(P_VALUE) wird der
+ komplette Wert aller Portionen + eventuell Behaelter
+ zurueckgegeben)
+
+ P_HP : Anzahl der LP, die prop Portion geheilt/geschwaecht werden
+ P_SP : Anzahl der KP, die prop Portion geheilt/geschwaecht werden
+ P_DISTRIBUTION : Verteilung der Heilung auf die Heartbeats
+ (siehe Hilfe zu H_DISTRIBUTION in consume)
+
+ P_LIFETIME : Zeit in Sekunden, bis die Speise verdirbt (>0)
+ Zaehlt ab der ersten Inbesitznahme durch einen Spieler
+P_RESET_LIFETIME : Zeit in Resets, bis die Speise verdirbt (>0)
+ Die Laenge der einzelnen Resets wird wie ueblich berechnet
+ und P_LIFETIME entsprechend auf durchschnittlich
+ P_RESET_LIFETIME * 45 * 60 gesetzt.
+ (existiert, da bisher meistens in Resets gerechnet wurde)
+ Sollte sinnvollerweise nur als SetProp(P_RESET_LIFETIME)
+ verwendet werden, kann aber auch abgefragt werden
+
+ P_EMPTY_PROPS : Mapping mit Werten des Behaelters
+ Alle hier angegebenen Werte (ausser P_PORTIONS) werden
+ in der Speise gesetzt, wenn die letzte Portion konsumiert
+ wurde. Wenn diese Prop leer ist, wird das Objekt zerstoert,
+ wenn keine Portionen mehr da sind.
+ Achtung: es werden keine closures unterstuetzt!
+ P_IDS : Wert in P_EMPTY_PROPS
+ Liste der IDs des leeren Behaelters
+ Achtung: es werden keine closures unterstuetzt!
+ P_ADJECTIVES : Wert in P_EMPTY_PROPS
+ Liste der Adjektive des leeren Behaelters
+ Achtung: es werden keine closures unterstuetzt!
+ P_VALUE : Wert in P_EMPTY_PROPS
+ Wert des leeren Behaelters
+ P_WEIGHT : Wert in P_EMPTY_PROPS
+ Gewicht des leeren Behaelters
+
+ P_NO_BAD : Flag, ob die Speise verderben kann
+ Darf nur in Absprache mit der Balance auf 1 gesetzt werden!
+
+ P_DESTROY_BAD : Wert, was beim Verderben mit dem Object passiert
+ DESTROY_BAD = Die Speise wird beim Verderben zerstoert
+ bzw. der Behaelter wird geleert (default)
+ DESTROY_NEVER = Die Speise wird beim Verderben nicht
+ zerstoert
+ pos. integer = Anzahl der Sekunden, die zwischen Verderben
+ und Zerstoeren der Speise liegen sollen
+
+MESSAGES: (durchlaufen replace_personal() und koennen somit Platzhalter
+ fuer Speise (1. Argument) und Konsument (2. Argument) enthalten)
+
+ P_CONSUME_MSG : fuer den Raum, wenn konsumiert wird
+ P_EATER_MSG : an den Konsumenten
+ P_EMPTY_MSG : wenn leere Behaelter konsumiert werden
+ P_NOFOOD_MSG : wenn Getraenke gegessen werden
+ P_NODRINK_MSG : wenn Futter getrunken wird
+ P_BAD_MSG : wenn Speisen verderben
+ P_REMOVE_MSG : wenn Speisen vernichtet werden
+ (nur wenn sie nicht beim Verderben vernichtet werden)
+ P_ENV_MSG : wenn im Raum liegende Speisen konsumiert werden
+ (ist diese Prop leer, geht das sogar!)
+ P_FOOD_FULL_MSG : wenn man nix mehr essen kann
+P_DRINK_FULL_MSG : wenn man nix mehr trinken kann
+ P_ALC_FULL_MSG : wenn man keinen Alkohol mehr vertraegt
+
+METHODEN:
+ consume : wird beim Konsumieren aufgerufen, wenn klar ist,
+ dass was zum Konsumieren da ist.
+ gibt das Ergebnis von try_consume() zurueck
+ try_consume : bereitet die Daten auf und fuehrt living->consume() aus
+ kann zur Pruefung mit testonly-Flag aufgerufen werden
+ gibt das Ergebnis von living->consume() zurueck
+ success_consume : wird von consume() aufgerufen, wenn Konsumieren klappt
+ gibt die Meldungen zum Konsumieren aus
+ failed_consume : wird aufgerufen, wenn Konsumieren nicht klappt
+ gibt den Grund fuer den Fehlschlag aus
+ (je nach Ergebnis von living->consume())
+
+ consume_bad : Aendert die Daten fuer living->consume(), wenn eine
+ verdorbene Speise konsumiert wird
+ Standard: Heilung wirkt nicht, Vergiftung +1
+ make_bad : wird aufgerufen, wenn die Speise gerade verdirbt
+ Gibt die Meldungen beim Verderben aus
+ Vernichtet das Objekt, wenn das gewollt ist
+ Die Methode wird auch aufgerufen, wenn nur noch der
+ Behaelter existiert! Also den Test is_not_empty() nicht
+ vergessen!
+ make_destroy : wird aufgerufen, wenn die Speise bereits verdorben ist
+ und die Zeit aus P_DESTROY_BAD abgelaufen ist.
+ Gibt die Meldung zum Zerstoeren aus und ruft
+ make_empty aus, um die Speise bzw. den Inhalt des
+ Behaelters zu zerstoeren. Ausserdem wird der Reset
+ abgeschaltet.
+ Die Methode wird auch aufgerufen, wenn nur noch der
+ Behaelter existiert! Also den Test is_not_empty() nicht
+ vergessen!
+
+ make_empty : wird aufgerufen, wenn die letzte Portion konsumiert wird
+ Macht aus einem vollen Behaelter einen leeren oder
+ vernichtet das Objekt. Der Behaelter verdirbt also im
+ Normalfall nicht!
+
+ init : Startet den Timer zum Verderben der Speise
+ (start_lifetime()), wenn sich das Objekt in einem
+ Spieler befindet.
+ Prueft, ob Laufzeiten fehlerhafterweise nicht beendet
+ wurden und holt es dann nach
+ NotifyMove : Startet den Timer zum Verderben der Speise
+ (start_lifetime()) auch, wenn die Speise in einen
+ Spieler bewegt wird, ohne dass init() aufgerufen
+ wurde.
+ reset : wird fuer 3 Situationen verwendet:
+ 1: Das Futter wurde bewegt, der Timer aber noch nicht
+ initialisiert -> es wird geprueft, ob der Timer
+ gestartet werden muss.
+ 2: Der Timer ist abgelaufen ->
+ laesst die Speise verderben und vernichtet sie
+ gegebenenfalls
+ 3: Der Timer nach dem Verderben ist abgelaufen ->
+ vernichtet die Speise
+ Es wird immer geprueft, ob die Resets zeitgerecht
+ aufgerufen wurden und die Aktionen nicht zur falschen
+ Zeit passieren
+
+ is_not_empty : Flag, ob noch Portionen vorhanden sind
+ is_drinkable : Flag, ob Speise trinkbar ist
+ (nur wenn P_DRINK gesetzt und P_FOOD NICHT gesetzt ist)
+ is_eatable : Flag ob Speise essbar ist
+ (wenn P_FOOD gesetzt (P_DRINK ist egal))
+ is_bad : Flag, ob Speise verdorben ist
+
+get_current_lifetime : Zeit in Sekunden, wie lange der Timer zum Verderben
+ laeuft (ist immer 0, wenn P_NO_BAD gesetzt ist)
+ start_lifetime : startet den Timer zum Verderben der Speise falls keine
+ Gruende dagegen sprechen, wird intern aufgerufen, kann
+ aber in speziellen Situationen auch manuell aufgerufen
+ werden (siehe oben unter REALISIERUNG)
+ message : es werden Meldungen zu Statusaenderungen verarbeitet
+ und korrekt ausgegeben. Es wird der Name der auszu-
+ gebenen Property uebergeben.
+ Es werden alle notwendigen Ersetzungen per
+ replace_personal gemacht und geprueft, ob dem Besitzer
+ oder dem Raum die Meldung ausgegeben werden muss.
+ Hierueber sollten nur Meldungen ausgegeben werden, die
+ durch Aenderungen an der Speise im Reset ausgeloest
+ werden, also im reset selbst und in den make_*-Methoden.
+
+
+STANDARD:
+ Wenn man nichts in seinem Futter ueberschreibt, dann hat es
+ folgendes Standardverhalten.
+ Es muss immer P_FOOD oder P_DRINK explizit groesser 0 gesetzt werden,
+ sonst laesst sich das Lebensmittel nicht konsumieren!
+
+ - Haltbarkeit: 1 Reset (30 + random(30) Minuten)
+ - der Ablauf der Haltbarkeit startet, sobald ein Spieler die Speise nimmt
+ - Wenn die Speise schlecht wird, wird sie zerstoert
+ - Die Speise hat keinen Behaelter
+ - Es gibt nur einen Schluck/Bissen, dann ist die Speise weg
+ - Gewicht: 50 Gramm / Wert: 10 Muenzen
+ - Man heilt weder LP noch KP
+ - Man wuerde ansonsten 5 LP/KP pro Heartbeat heilen
+ - Man kann die Speise nur konsumieren, wenn man sie in der Hand haelt
+ - Wenn man die verdorbene Speise konsumieren koennte, wuerde man nicht
+ heilen sondern vergiftet werden (P_POISON+1)
+
+BEISPIELE:
+ Beispiele zu tragbaren Speisen und Getraenken kann man unter
+ doc/beispiele/food/ nachschauen
+
+SIEHE AUCH:
+ consume, wiz/heilung,
+
+LETZTE AeNDERUNG:
+ 25.09.2010, Caldra
diff --git a/doc/wiz/forscherpunkte b/doc/wiz/forscherpunkte
new file mode 100644
index 0000000..a7f84d1
--- /dev/null
+++ b/doc/wiz/forscherpunkte
@@ -0,0 +1,65 @@
+
+Forscherpunkte
+==============
+
+ FORSCHERPUNKTE:
+ Damit die Spieler beim Erkunden neuer Gebiete auch an Ortskenntnis
+ gewinnen, muessen an bestimmten Stellen Forscherpunkte (FP) vergeben
+ werden. Dazu ist in den meisten Faellen keine Aenderung an den Objekten
+ selbst noetig, die Punkte muessen jedoch von einem Erzmagier in die
+ FP-Liste eingetragen werden.
+
+ DIE FORSCHERPUNKTE MUESSEN EINGETRAGEN WERDEN, BEVOR DAS GEBIET DEN
+ SPIELERN ZUGAENGLICH GEMACHT WIRD!
+
+ Die Testphase ist eine gute Gelegenheit, sich darueber Gedanken zu machen,
+ wo welche FP vergeben werden koennten.
+
+ Fuer das Eintragen der Forscherpunkte ist derzeit Miril zustaendig.
+
+ WAS FUeR FP KANN ICH VERGEBEN?
+ Folgende Typen von Forscherpunkten stehen zur Verfuegung:
+
+ * Details. Darunter fallen auch SpecialDetails.
+ * ReadDetails.
+ * Sounds und Smells.
+ * Kommandos, soweit sie mit AddCmd() angemeldet werden.
+ Kommandos, die mit add_action() angemeldet werden, koennen aus
+ technischen Gruenden nicht beruecksichtigt werden.
+ Kommandos, die als FPs eingetragen sind, geben genau dann den
+ FP, wenn 1 zurueckgegeben wird.
+ * Ausgaenge bei Raeumen. Darunter fallen auch SpecialExits.
+ * Infos bei NPCs. Das Defaultinfo laesst sich allerdings nicht ohne
+ weiteres verwenden.
+ * Getraenke und Speisen in Kneipen.
+ * Besondere Aktionen sind auch moeglich, dazu muss jedoch noch etwas am
+ Code hinzugefuegt werden. Diese Art von Forscherpunkten sollte man nach
+ Moeglichkeit meiden.
+
+ Pro Objekt laesst sich nur ein FP vergeben. Die FP-Dichte sollte etwa bei
+ einem FP pro zehn Raeume liegen.
+
+ In Questgebieten sollten die FP NICHT fuer Details oder Aktionen vergeben
+ werden, die einen direkt in der Quest weiterbringen, sondern eher fuer
+ solche, die zu den entscheidenen Stellen fuehren. Damit werden Spieler,
+ die sich alles genau ansehen, belohnt, wohingegen Komplettloeser, die nur
+ das noetigste eingeben, leer ausgehen.
+
+ WIE SAG ICHS MEINEM ERZMAGIER?
+ Um die FP eintragen zu koennen, brauchen die Erzmagier eine Liste mit den
+ noetigen Informationen. Zu den noetigen Informationen gehoeren:
+
+ * der Dateiname des Objektes
+ * die Art des FP
+ * die Schluesselwoerter, mit denen der FP angesprochen werden soll
+
+ Die Schluesselwoerter sind normalerweise die Schluessel, die bei den
+ jeweiligen AddXXX()-Aufrufen im Objekt angegeben werden.
+
+ Beispiel:
+
+ /players/wargon/workroom: detail wand, waende
+ /players/wargon/mon/errol: info drachen
+
+ LETZTE AeNDERUNG:
+ Thu, 2013-04-04 von Humni
diff --git a/doc/wiz/ftp b/doc/wiz/ftp
new file mode 100644
index 0000000..bca4c5a
--- /dev/null
+++ b/doc/wiz/ftp
@@ -0,0 +1,41 @@
+FTP-Zugang fuer Magier (Zesstra, 12. Dez 2010, 23:17:52):
+Ok, wie in bekanntmachungen geschrieben, waren unsere (und die anderer Muds)
+Versuche bislang erfolglos, das mod_mud-Modul fuer den proftpd wieder ans
+Laufen zu bringen und ich habe als Zwischenloesung zumindest erstmal was
+anderes gebaut.
+
+Allerdings kann die aktuelle Loesung nicht 'live' beim Dateizugriff das Mud
+fragen, ob der User das auch darf. Daher sind alle Magier leider erstmal auf
+ihr Homeverzeichnis beschraenkt - dort duerfen sie natuerlich alles schreiben
+und lesen. Von dort/dorthin muss man dann im Mud mit cp/mv arbeiten.
+
+Wer seinen FTP-Zugang aktivieren will, muss - bis ich das in die Magiershell
+eingebaut habe - folgende zwei Schritte durchfuehren:
+1) xeval master()->update_ftp_access(getuid(this_interactive()), 1)
+ (Deaktivieren mit update_ftp_access(getuid(this_interactive()), 0)
+2) mit passwd ein neues PW setzen
+3) bis zur naechsten vollen Stunde warten
+
+Schritt 2) ist leider zwingend noetig, da wir das PW nicht im Klartext
+speichern und pure-ftpd unsere verschluesselten/gehashten Passwoerter nicht
+versteht. Deswegen muessen wir fuer FTP das PW anders speichern, was wir nur
+beim Neusetzen eines PWs koennen.
+
+Ich moechte euch noch um eins bitten: Wenn ihr was per FTP hin- und
+herschiebt, was dann weiter (z.B. nach /d) verschoben wird (oder von dort ihr
+euer Homeverzeichnis): loescht bitte den Kram aus eurem /players/<magier>
+wieder, denn a) geht das alles sonst ueberfluessig ins Backup und b) wird die
+Uebersicht deutlich schlechter, wenn man x Kopien des gleichen Krams im Mud
+verteilt hat.
+
+BTW: Dieser FTP-Zugang wird deaktiviert, falls sich ein Magier laenger als 2
+Wochen nicht im Mud einloggt, dann muesst ihr die Prozedur da oben
+wiederholen.
+
+Sorry fuer die Unannehmlichkeiten, aber so ists erstmal besser als gar nix.
+Falls wider Erwarten jemand beim mod_mud aushelfen mag, ist er uebrigens
+herzlich willkommen.
+
+Zesstra
+Stand: Februar 2011
+
diff --git a/doc/wiz/gift b/doc/wiz/gift
new file mode 100644
index 0000000..a2c4d9e
--- /dev/null
+++ b/doc/wiz/gift
@@ -0,0 +1,132 @@
+Krankheiten, Gifte und Flueche
+==============================
+
+ Einmal abgesehen vom einfachen Setzen von P_POISON im Spieler lassen
+ sich Gifte und Krankheiten auch als Objekte ausprogrammieren, die dem
+ Spieler in mehr oder weniger regelmaessigen Abstaenden Lebenspunkte
+ abziehen. Auch Flueche koennen nicht nur als P_CURSED in Waffen und
+ Ruestungen, sondern auch als Objekte vorliegen, und dem Spieler das
+ Leben schwermachen
+
+ Um ein Objekt als Gift zu kennzeichnen, wird die Klasse CL_POISON
+ gesetzt, fuer eine Krankheit ist CL_DISEASE und fuer einen Fluch
+ CL_CURSE zu setzen (mit AddClass, siehe dort). Zusaetzlich wird die
+ Schwere der Erkrankung bzw. Vergiftung in der Property P_LEVEL
+ abgelegt, wobei P_LEVEL einen Wert zwischen 1 und 100 haben sollte.
+ Mitglieder der Klerikergilde und andere Heiler koennen dann je nach
+ P_LEVEL den betroffenen Spieler mehr oder weniger gut heilen. (Kleriker
+ koennen CL_POISON-Vergiftungen heilen, einige Heiler jedoch nicht.)
+
+ Eine eindeutige Unterscheidung zwischen Giften, Krankheiten und
+ Fluechen zu treffen, ist schwer, denn die Grenzen verschwimmen.
+ Trotzdem hier eine grobe Klassifizierung:
+
+ Gifte : bringt der Spieler sich meist selbst bei (in dem er z.B.
+ einen giftigen Pilz isst). Oft auch sind die Stellen, wo
+ ein Spieler sich vergiften kann, irgendwie gekennzeichnet,
+ so dass eine Vergiftung umgangen werden kann.
+
+ Bei Giften wird durch das Heilen der Level des Giftobjekts
+ abhaengig vom Erfolg gesenkt. Ist der Level <= 0, wird das
+ Objekt vom Kleriker-Spellbook entfernt. Heiler sollten das
+ aehnlich machen. Logisch waere es daher, den Schaden, den das
+ Objekt macht, vom momentanen Level abhaengig zu machen.
+
+ Krankheit: werden dem Spieler durch Fremdeinwirkung beigebracht, auch
+ durch Ansteckung bei einem anderen Spieler oder NPC.
+ Bei ansteckenden Krankheiten ist auf die Ansteckrate zu achten
+ und darauf, dass die Krankheit mit der Zeit auch wieder
+ ausstirbt. Also entweder bei jeder Generation der Krankheit
+ das Ansteckungsrisiko senken oder einmal infizierte Spieler
+ immunisieren. Es sollten sich 2 idelnde Spieler nicht immer
+ wieder gegenseitig bis in alle ewig anstecken koennen. Auch
+ ist darauf zu achten, dass Netztote nicht angesteckt werden
+ koennen bzw. Netztote niemanden anstecken, da sich sonst die
+ Krankheit im Netztotenraum verbreiten kann.
+
+ Das Heilen geschieht im Kleriker-Spellbook wie bei Gift.
+
+ Flueche: werden wie Krankheiten durch Fremdeinwirkung beigebracht
+ (der Spieler wird halt verflucht). Ausserdem ist die Wirkung
+ von Fluechen oft nicht auf einfaches Abziehen von Lebenspunkten
+ beschraenkt, sondern der Spieler kann z.B. nicht mehr richtig
+ sprechen (Sprachfluch ueber P_PERM_STRING), ist in der Bewegung
+ eingeschraenkt oder greift wahllos NPCs an.
+
+ Hier ist das Entfluchen durch einen Kleriker anders. Findet
+ das Spellbook ein CL_CURSE-Objekt im Inv des Spielers, wird
+ gegen das Level des Objekt gewuerfelt. Bei Erfolg wird das
+ Objekt entfernt, bei Misserfolg passiert nichts!
+
+ Als Anhaltspunkte fuer den Level:
+ - < Level 10 sind einfach zu entfluche
+ - 10 - 20 sind fuer kleine Kleriker schon enorm schwierig
+ fuer max. Kleriker gut zu entfluchen.
+ - ueber 20 gelingt es auch einem max. Kleriker nicht immer
+ beim ersten mal.
+ - ab 30 muss der max. Kleriker schon mal tanken gehen
+ - Ueber Level 40 liegt die Chance schon im Promillebereich!!!
+ - Level 100 laesst sich ueberhaupt nicht mehr entfluchen.
+
+ Will man dem Spieler also eine reelle (und nicht nur
+ mathematische) Chance lassen, sollte der Fluchlevel unter 40
+ bleiben.
+
+ Das Schadensobjekt selbst ist unsichtbar, meist autoload und loest die
+ Schadensfunktion ueber Callouts aus.
+
+ BEISPIEL:
+ Hier ein Beispiel fuer einen Giftpilz (gefunden bei Silvana, in
+ /d/dschungel/silvana/weg/obj/pilz.c):
+ ----------------------------------------------------------------------
+ #pragma strong_types
+ #include "../pfad.h"
+
+ inherit "/std/thing";
+
+ void create() {
+ if(!clonep(TO)) {
+ set_next_reset(-1);
+ return;
+ }
+ ::create();
+
+ SetProp(P_SHORT,0);
+ SetProp(P_INVIS,1);
+ SetProp(P_LONG,0);
+ SetProp(P_NODROP,1);
+ SetProp(P_NEVERDROP,1);
+ SetProp(P_AUTOLOADOBJ,1);
+ SetProp(P_WEIGHT,0);
+ SetProp(P_NAME,"Pilzvergiftung");
+ SetProp(P_KILL_NAME,"Eine Pilzvergiftung");
+ SetProp(P_GENDER,FEMALE);
+ SetProp(P_ARTICLE,1);
+ SetProp(P_LEVEL,10);
+ call_out("next_step",2);
+ AddClass(CL_POISON);
+ }
+
+ void next_step();
+
+ void next_step() {
+ object pl;
+ if(!(pl=TOE) || !query_once_interactive(pl) ||
+ pl->QueryProp(P_GHOST)){
+ remove();
+ return ;
+ }
+ call_out(#'next_step ,5);
+ if(!interactive(pl)) return;
+ tell_object(pl,
+ "Dein Bauch schmerzt. Du windest Dich in Kraempfen.\n");
+ if(ENV(pl)) tell_room(ENV(pl),
+ pl->Name()+" windet sich vor Schmerzen am Boden.\n",({ pl }));
+ pl->do_damage(QueryProp(P_LEVEL)*2 + random(10),TO);
+ }
+
+ SIEHE AUCH:
+ P_POISON, P_CURSED, P_PERM_STRING
+
+ LETZTE AeNDERUNG:
+ 11.08.2007, Zesstra
diff --git a/doc/wiz/gilden-doku b/doc/wiz/gilden-doku
new file mode 100644
index 0000000..08e3aa7
--- /dev/null
+++ b/doc/wiz/gilden-doku
@@ -0,0 +1,496 @@
+Gilden
+*******
+
+Gilden sind dazu da, Spielern besondere Faehigkeiten zu verleihen. Dies
+koennen Zaubersprueche (Spells) sein, es kann aber auch andere Faehigkeiten
+(Skills) geben. Als Spell gilt jede Faehigkeit, die ein Spieler mit einem
+Befehl direkt aufrufen muss. Damit auch andere Gilden die gleichen
+Zaubersprueche verwenden koennen, muessen die Sprueche in eigenen
+Spellbooks abgelegt werden. Eine Gilde kann Sprueche aus beliebigen
+Spellbooks verwenden und diese ggf. leicht modifizieren.
+
+Gildenobjekt
+=============
+
+Eine Gilde muss ein Objekt haben, bei dem der Spieler der Gilde beitreten
+bzw. austreten und die Faehigkeiten der Gilde erwerben kann. Gewoehnlich
+ist dies ein Raum, der "/std/gilden_room" inheritet, es kann aber auch ein
+anderes Objekt sein, fuer diesen Fall ist "/std/gilden_ob" vorgesehen.
+
+Die Beitrittsbedingungen fuer die Gilde werden in Form eines
+Restriction-Mappings in der Property P_GILDEN_RESTRICTIONS
+abgelegt.
+
+Das Spellbook, in dem die Spells der Gilde stehen, muss in
+P_GUILD_DEFAULT_SPELLBOOK genannt sein. Es wird automatisch
+"/spellbooks/" vorne an den Namen angefuegt. Die Spells, die aus diesem
+Spellbook verwendet werden sollen, koennen dann einfach mit
+AddSpell(name) ausgewaehlt werden. Wenn ein Spruch modifiziert werden
+soll so kann ein Mapping mit zusaetzlichen Informationen als zweites
+Argument angegeben werden. In diesem kann man dann auch ein anderes
+Spellbook als das Default-Spellbook mit ([SI_SPELLBOOK:name])
+angeben. In P_GLOBAL_SKILLPROPS kann ein Mapping angegeben
+werden, das alle Spells und Skills modifiziert. P_GLOBAL_SKILLPROPS
+und P_GILDEN_DEFAULT_SPELLBOOK muessen uebrigens gesetzt
+werden bevor mit AddSpell/Skill Spells oder Skills hinzugefuegt werden.
+
+Fuer andere Faehigkeiten sind AddSkill und LearnSkill vorgesehen.
+LearnSkill wird im Gegensatz zu LearnSpell jedoch nicht automatisch vom
+/std/gilden_room mit "lerne" aufgerufen, weil i.A. diese Faehigkeiten auf
+andere Art erworben werden, z.B. beim Gildeneintritt oder durch
+Trainingsstunden. Mit LearnSkill kann man nur solche Faehigkeiten
+erwerben, die mit AddSkill angefuegt wurden.
+
+Skills werden ueblicherweise durch den Aufruf von UseSkill im Spieler
+verwendet. Wenn der Spieler in einer Gilde ist und eine Funktion unter
+SI_SKILLFUNC zu finden ist, so wird diese im Gildenobjekt aufgerufen,
+sonst wird versucht StdSkill_Name im Spieler aufzurufen. Wenn auch das
+fehlschlaegt wird nur der Wert unter SI_ABILITY zurueckgegeben.
+
+Es stehen folgende Funktionen zur Benutzung zur Verfuegung:
+
+ o QuerySpell(name)
+ Liefert die Informationen zu diesem Spell
+ o QuerySkill(name)
+ Liefert die Informationen zu dieser Faehigkeit
+ o AddSpell(name,info)
+ Spell wird hinzugefuegt
+ o AddSkill(name,info)
+ Faehigkeit wird zugefuegt
+ o LearnSpell(name)
+ Spieler lernt den angegebenen Spell, falls moeglich. Liste der Spells
+ wird ausgegeben, falls keiner angegeben ist.
+ o LearnSkill(name)
+ Spieler erwirbt diese Faehigkeit, falls moeglich. Liste aller
+ Faehigkeiten wird ausgegeben, falls keine angegeben ist.
+ o GildenName()
+ Liefert den Namen dieser Gilde.
+ o InitialSkillAbility(info,spieler)
+ Rechnet den Anfangswert fuer SI_SKILLABILITY aus.
+ o SkillListe(x)
+ Es wird angezeigt, welche Spells/Skills der Spieler lernen kann.
+ Dabei bedeutet x:
+ o 1: Nur Spells anzeigen
+ o 2: Nur Skills anzeigen
+ o 3: Beides anzeigen
+
+Von diesen Funktionen stehen in /std/gilden_room automatisch
+bei_oder_austreten und LearnSpell dem Spieler zur Verfuegung.
+
+Spellbook
+==========
+
+Spellbooks stellen die Spells zur Verfuegung, die Spieler oder Monster
+verwenden koennen. Alle Spellbooks sollten /std/spellbook inheriten. In der
+einfachsten Form kann ein Spell wie folgt hinzugefuegt werden:
+AddSpell(verb,kosten,level)
+Dabei ist "verb" sowohl der Name des Verbs, mit dem der Spruch
+aufgerufen werden soll, wie auch der Name der Funktion, die dabei
+aufgerufen wird. "kosten" sind die Magiepunkte, die fuer den Spruch
+benoetigt werden und "level" ist der Spielerlevel, der noetig ist, um diesen
+Spruch zu lernen.
+
+In der flexibleren Form werden Spells mit
+AddSpell(verb,kosten,info)
+hinzugefuegt. Dabei ist "info" ein Mapping, in dem alle anderen
+Spell-Informationen stehen. Dabei kann z.B. eine andere Funktion als das
+Verb als Eintrag
+SI_SKILLFUNC:name
+angegeben werden. Wenn zum Lernen eine bestimmte Stufe erforderlich ist
+so muss
+SI_SKILLRESTR_LEARN:([P_LEVEL:level])
+eingetragen sein. Es sollten alle Werte, von denen ein Spell abhaengt, in dem
+Mapping eingetragen sein. Dadurch haben Gilden die Moeglichkeit, Spells
+mit Offsets und Faktoren zu modifizieren.
+
+In P_GLOBAL_SKILLPROPS kann ein Mapping stehen, dass bei jedem
+Spell zum Info addiert wird. Dieses sollte gesetzt werden, bevor die Spells
+mit AddSpell hinzugefuegt werden.
+
+Die Benutzung von Spells laeuft wie folgt ab:
+
+ o Zuerst wird ueberprueft, ob der Spieler den Spruch verwenden darf.
+ Dazu wird die Funktion CanTrySpell aufgerufen. Diese prueft
+ normalerweise, ob der Spieler kein Geist ist und ob er die
+ Einschraenkungen erfuellt, die als SI_SKILLRESTR_USE
+ angegeben sind.
+ o Als naechstes wird geprueft, ob der Spieler noch genug Magiepunkte
+ hat. Diese stehen im Mapping unter SI_SPELLCOST.
+ o Als letztes wird geprueft, ob der Spieler noch erschoepft ist von
+ seinem letzten Spruch.
+ o Nun wird die eigentliche Funktion des Spells aufgerufen, wenn es die
+ Umgebung zulaesst. Die Funktion muss einen positiven Wert
+ zurueckgeben, wenn der Spruch gelungen ist, und einen negativen,
+ wenn er misslungen ist. Falls der Spruch aus irgend einem Grund
+ nicht anwendbar ist soll 0 zurueckgegeben werden.
+ o Bei Erfolg oder Misserfolg werden die Magiepunkte abgezogen und
+ der Spieler ist fuer die naechste Zeit erschoepft. Die Zeitspanne ist
+ im Mapping unter SI_SPELLFATIGUE zu finden.
+ o Bei Erfolg wird die Funktion "Erfolg" aufgerufen, bei Misserfolg
+ die Funktion "Misserfolg"
+ o Die Funktion "Misserfolg" ruft normalerweise die Funktion "Learn"
+ auf, damit der Spieler aus seinen Fehlern lernt.
+
+Die eigentliche Spellfunktion sollte, falls der Spell anwendbar ist, mit
+SpellSuccess pruefen, ob er erfolgreich ist oder nicht. Dabei gelten Werte
+groesser Null als Erfolg. In der Spellfunktion sollten, falls moeglich,
+SkillAttribute des Spielers sowie Faktoren und Offsets beruecksichtigt
+werden. Fuer beides stehen einfach zu handhabende Funktionen zur
+Verfuegung. Dies ist zwar etwas mehr Arbeit, dafuer geschehen dann Dinge
+wie Interaktionen zwischen den Spells fast automatisch.
+
+Folgende Funktionen stellt das Standard-Spellbook zur Verfuegung:
+
+ o QuerySpell(name)
+ Liefert Informations-Mapping zu diesem Spell.
+ o AddSpell(name,kosten,info)
+ Fuegt Spell mit angegebenen Kosten und dem
+ Informations-Mapping ins Spellbook ein.
+ o TryAttackSpell(opfer,schaden,typen,is_spell,caster,info)
+ Versucht den Angriffs-Spruch auf den Gegner anzuwenden. Die
+ mittleren 4 Werte sind die, die auch bei Defend uebergeben werden.
+ Dabei wird die Abwehrfaehigkeit des Gegners gegen Magie und das
+ Skill-Attribut SA_DAMAGE automatisch beruecksichtigt.
+ o TryDefaultAttackSpell(opfer,caster,info,is_spell)
+ Wie TryAttackSpell, nur werden Schaden und Schadenstypen
+ automatisch aus dem Informations-Mapping entnommen. Bei beiden
+ Funktionen sollte als is_spell uebrigens ein String stehen, z.B.
+ "Feuerball", damit es leichter moeglich ist, Monster zu schreiben, die
+ auf diese reagieren.
+ o SpellSuccess(caster,info)
+ Ermittelt, ob der Spell funktioniert oder fehlschlaegt. Dabei wird
+ auch eine evtl. vorhandene Spellcasting-Faehigkeit (SK_CASTING)
+ beruecksichtigt. Ohne Spellcasting-Faehigkeit liegt das Ergebnis
+ zwischen -MAX_ABILITY und +MAX_ABILITY, mit dieser
+ Faehigkeit koennen die Werte zwischen -2*MAX_ABILITY und
+ +2*MAX_ABILITY liegen. Werte kleiner oder gleich Null sollen
+ als Fehlschlag interpretiert werden.
+ Wer will, kann Werte ueber +MAX_ABILITY als besonders gut
+ gelungene Spells interpretieren und bei Werten unter
+ -MAX_ABILITY unangenehme Wirkungen ausloesen, z.B. kann
+ sich der Spell dann gegen den Spieler richten...
+ Wenn ein Spieler die Spellcasting-Faehigkeit hat und ein Spruch
+ besonders gut gelingt, so freut er sich und verbessert diese
+ Faehigkeit.
+ o CanTrySpell(caster,info)
+ Ermittelt, ob der Spieler den Spruch anwenden darf. Normalerweise
+ ist diese der Fall, wenn er kein Geist ist und die Bedingungen
+ erfuellt, die unter SI_SKILLRESTR_USE im Mapping eingetragen
+ sind.
+ o Learn(caster,spell,info)
+ Diese Funktion wird normalerweise bei Misserfolg aufgerufen,
+ damit der Spieler aus seinen Fehlern lernt. Dabei wird
+ ueblicherweise die Intelligenz des Spielers beruecksichtigt. Fuer je 2
+ Stufen A_INT bekommt der Spieler SI_SKILLLEARN hinzu.
+
+ Moechte man ein anderes Attribut zum lernen verwenden kann man dies
+ in Form eines Mappings in SI_LEARN_ATTRIBUTE tun.
+
+ SI_LEARN_ATTRIBUTE:([A_STR:1]) macht das Lernen rein staerkeabhaengig,
+ SI_LEARN_ATTRIBUTE:([A_STR:1,A_INT:2]) bildet den gewichteten Mittelwert
+ von STR und zweifacher INT.
+
+ o Erfolg(caster,spell,info)
+ Diese Funktion wird bei Erfolg aufgerufen.
+ o Misserfolg (caster,spell,info)
+ Diese Funktion wird bei Misserfolg aufgerufen.
+ o FindVictim(wen,spieler,msg)
+ "wen" wird in der Umgebung des Spielers gesucht. Falls diese
+ Variable Null ist wird zufaellig ein Feind ausgewaehlt. Falls
+ niemand gefunden wird, so wird "msg" ausgegeben.
+ o FindLivingVictim(wen,spieler,msg)
+ Wie FindVictim, nur wird zusaetzlich ueberprueft, ob es ein
+ Lebewesen ist.
+ o FindEnemyVictim(wen,spieler,msg)
+ Wie FindLivingVictim, nur der Spieler selbst wird ausgenommen
+ und wenn es vorher noch kein Feind war, so wird Kill aufgerufen
+ damit es hinterher garantiert einer ist.
+ o FindGroup(spieler,wen)
+ Bei Spielern findet die Funktion alle Monster im Raum, wenn "wen"
+ negativ ist, alle Spieler wenn "wen" positiv ist und alle Lebewesen
+ wenn "wen" Null ist. Bei Monstern ist es genau umgekehrt. Es sollte
+ jedoch FindGroupP mit 100% verwendet werden.
+ o FindGroupN(spieler,wen,n)
+ Wie FindGroup, jedoch maximal n Personen. Das Skill-Attribut
+ SA_EXTENSION wird automatisch beruecksichtigt.
+ o FindGroupP(spieler,wen,prozent)
+ Wie FindGroup, jedoch jede Person mit der angegebenen
+ Wahrscheinlichkeit. Das Skill-Attribut SA_EXTENSION wird
+ automatisch beruecksichtigt.
+
+Neue Funktionen im Living
+==========================
+
+ o QuerySkillAttribute(name)
+ Hiermit kann das Skill-Attribut mit dem angegebenen Namen
+ abgefragt werden.
+ o SetSkillAttribute(caster,name,wert,dauer,func)
+ Hiermit kann das angegebene Skill-Attribut vom caster fuer die
+ angegebene Dauer auf einen Wert gesetzt werden. Es kann eine
+ Funktion angegeben werden, die den Wert statt dessen liefern soll.
+ o QuerySkill(name)
+ Dies liefert die spielerspezifischen Skill-Informationen.
+ o QuerySkillAbility(name)
+ Dies liefert von den Skill-Informationen nur SI_ABILITY.
+ o ModifySkill(name,info,diff)
+ Modifiziert die Skill-Informationen. Wenn "info" ein Mapping ist,
+ so wird es zu dem alten Mapping "addiert" (also die angegebenen
+ Werte geaendert), wenn nur ein Wert angegeben ist, wird
+ angenommen dass es sich dabei um SI_ABILITY handelt.
+ o LearnSkill(name,add,diff)
+ Addiert den angegebenen Wert zu SI_ABILITY. Dabei ist "diff" der
+ Schwierigkeitsgrad von diesem Spell/Skill. Durch den
+ Schwierigkeitsgrad SI_ABILITY abhaengig vom Level begrenzt.
+ o UseSpell(arg,spell)
+ Das Lebewesen benutzt den Spell mit den angegebenen Argumenten.
+ Wenn kein Spell angegeben ist, so wird query_verb() verwendet.
+ o UseSkill(skill,arg)
+ Das Lebewesen benutzt die Faehigkeit.
+
+Neue Properties/Funktionen in Living/Combat
+============================================
+
+Einige Sprueche erfordern es, das Verhalten bei Attack und Defend ziemlich
+weitreichend zu aendern. Dafuer wurden folgende Properties und
+Funktionen eingebaut:
+
+ o P_TMP_ATTACK_HOOK
+ Hier kann ein Array der Form ({Endzeitpunkt,Objekt,Funktion})
+ stehen. Solange der Endzeitpunkt noch nicht ueberschritten wurde
+ und das angegebene Objekt existiert, wird anstelle von Attack die
+ Funktion in dem Objekt aufgerufen. Wenn die Funktion 0 liefert
+ wird der Rest von Attack nicht mehr ausgefuehrt.
+ o P_TMP_DEFEND_HOOK
+ Wie P_ATTACK_HOOK, nur mit Defend. Damit sind z.B.
+ Sprueche moeglich, die fuer kurze Zeit eine magische Schutzhuelle
+ erschaffen. Wenn die Funktion 0 liefert wird der Rest von Defend
+ nicht mehr ausgefuehrt. Wenn es ein Array der Form
+ ({damage,dt,is_spell}) ergibt wird es wie bei DefendOther
+ interpretiert.
+ o P_DEFENDERS
+ Liste von Lebewesen, die mit InformDefend(enemy) informiert
+ werden sollen, sobald ein neuer Feind hinzukommt. Bei einem
+ zufaellig ausgewaehltem Lebewesen aus dieser Liste wird ausserdem
+ DefendOther mit den Argumenten von Defend aufgerufen.
+ o AddDefender(friend)
+ Fuegt Lebewesen in P_DEFENDERS ein, wenn es noch nicht in der
+ Liste ist.
+ o InformDefend(enemy)
+ Siehe oben.
+ o DefendOther(dam,dt,is_spell,enemy)
+ Mit dieser Funktion kann man Lebewesen erschaffen, die Schaden
+ von anderen abwenden oder modifizieren. Wenn diese Funktion ein
+ Array ({dam,dt,is_spell}) zurueckgibt so werden bei dem zu
+ verteidigenden Lebewesen diese Werte genommen anstelle der alten.
+ Man kann also z.B. ein Monster erschaffen, das ein
+ feuerempfindliches anderes Monster verteidigt, indem es z.B.
+ Feuerbaelle in Eishagel verwandelt.
+
+Standard-Skills
+================
+
+Folgende Faehigkeiten werden schon beruecksichtigt und sind auch
+vordefiniert. Wenn sie unveraendert uebernommen werden sollen muss nur
+SI_ABILITY gesetzt werden.
+
+ o SK_SWORDFIGHTING
+ Schwertkampf. Bis zu 33+A_STR+A_DEX Aufschlag bei
+ Schwertern, wenn jemand diese Faehigkeit zu 100% hat.
+ o SK_WEAPONLESS
+ Kampf mit blossen Haenden. Bis zu 100+A_STR+3*A_DEX
+ Aufschlag.
+ o SK_TWOHANDED
+ Kampf mit zweihaendigen Waffen. Bis zu 33+A_STR Aufschlag.
+ o SK_NIGHTVISION
+ Wer diese Faehigkeit zu 100% hat braucht 20 Sekunden pro
+ fehlendem Lichtlevel um sich an die Dunkelheit zu gewoehnen.
+ o SK_BOOZE
+ Mit 100% dieser Faehigkeit wird bei jedem alkoholischen Getraenk
+ 80% vom Alkoholgehalt abgezogen.
+
+Folgende Faehigkeiten werden beruecksichtigt, sind aber nicht vordefiniert:
+
+ o SK_MAGIC_ATTACK
+ Wenn diese Faehigkeit vorhanden ist, wird die Funktion unter
+ SI_SKILLFUNC im Gildenobjekt aufgerufen, falls der Spieler sonst
+ mit blossen Haenden angreifen wuerde. Wenn dabei ein Mapping
+ zurueckgegeben wird, so werden die Werte von
+ SI_SKILLDAMAGE, SI_SKILLDAMAGE_TYPE und
+ SI_SKILLDAMAGE_MSG genommen anstelle der Werte in
+ P_HANDS.
+ o SK_MAGIC_DEFENSE
+ Wenn hier unter SI_SKILLFUNC eine Funktion eingetragen ist, so
+ wird sie bei Defend im Gildenobjekt aufgerufen und bekommt im
+ Informations-Mapping SI_SKILLDAMAGE,
+ SI_SKILLDAMAGE_TYPE und SI_SPELL uebergeben. Wenn sie
+ ein Mapping zurueckgibt werden hieraus SI_SKILLDAMAGE und
+ SI_SKILLDAMAGE_TYPE entnommen und ersetzen die alten
+ Werte von "dam" und "dam_type".
+ o FIGHT(Waffentyp)
+ Falls diese Faehigkeit vorhanden ist wird der entsprechenden
+ Funktion in SI_SKILLDAMAGE der bisherige Schaden uebergeben.
+ Falls sie ein Mapping zurueckliefert wird an dieser Stelle auch der
+ neue Schaden erwartet.
+ o SK_FIGHT
+ Wie Fight(Waffentyp), nur wird diese Faehigkeit, falls vorhanden,
+ bei jeder Waffe benutzt und kann auch zusaetzlich andere Werte fuer
+ SI_SKILLDAMAGE_TYPE ergeben. Waffe und Waffentyp werden
+ uebrigens in SI_WEAPON und SI_WEAPON_TYPE uebergeben.
+ o SK_CASTING
+ Spellcasting. Die Wahrscheinlichkeit, dass der Spell gelingt, steigt
+ bei 100% dieser Faehigkeit auf das Doppelte. Nur mit dieser
+ Faehigkeit ist es moeglich, ueber die Maximalgrenzen zu kommen,
+ so dass dann auch Spells besonders gut gelingen koennen.
+
+Temporaere Property-Aenderungen
+================================
+
+Oft muessen Spells irgendwo Properties fuer kurze Zeit veraendern, wie
+z.B. P_LIGHT oder P_NOMAGIC in Raeumen. Fuer diesen Zweck kann
+man in /obj/tmp_prop_master die Funktion SetTmpProp aufrufen. Diese
+Funktion erwartet das Objekt, in dem die Property zu setzen ist, den Namen
+der Property, den zeitweiligen Wert und den Zeitpunkt, bis zu dem diese
+Aenderung gelten soll.
+
+Skill Informationen
+++++++++++++++++++++
+
+In den Informationsmappings zu den Spells/Skills sollten alle (zusaetzlich)
+noetigen Informationen stehen, denn nur wenn z.B. ein Feuerball in einem
+Spellbook als Schaden 300 eingetragen hat und diesen Wert dem Mapping
+entnimmt, kann eine andere Gilde diesen Spruch recyclen und mit Schaden
+400 anbieten, natuerlich sollte er dann auch in der Gilde mehr kosten.
+
+SIEHE AUCH: skill_info_liste
+
+Faktoren und Offsets
+---------------------
+
+Man kann in dem Informations-Mapping zu jedem numerischen Wert
+"Name" noch zwei zusaetzliche Werte FACTOR("Name") und
+OFFSET("Name") eintragen und diese Werte automatisch zur eigentlichen
+Wertbestimmung beruecksichtigen. Mit folgenden Funktionen sollte man
+im Spellbook dem Mapping Werte entnehmen:
+
+ o GetValue(name,map,spieler)
+ o GetOffset(name,map,spieler)
+ OFFSET(name).
+ o GetFactor(name,map,spieler)
+ Ergibt FACTOR(name), falls ungleich Null, sonst 100.
+ o GetFValue(name,map,spieler)
+ Ergibt (Wert*Faktor)/100.
+ o GetValueO(name,map,spieler)
+ Ergibt Wert+Offset.
+ o GetFValueO(name,map,spieler)
+ Ergibt (Wert*Faktor)/100+Offset.
+
+Nach Moeglichkeit sollte man davon im Spellbook GetFValueO benutzen,
+wenn es angebracht ist. Auf jeden Fall sollten von den drei Werten
+moeglicht viele auf eine angemessene Weise beruecksichtigt werden, denn
+dadurch bekommt das Gildenobjekt feinere Kontrollmoeglichkeiten, wenn
+ein Spruch modifiziert werden soll. Es ist dann fuer die Gilde aeusserst
+einfach festzulegen, dass z.B. Zwerge bei allen Angriffsspruechen 20%
+mehr Schaden verursachen und beim Feuerball Elfen einen hoeheren
+garantierten Wert hinzubekommen.
+
+Funktionen
+-----------
+
+Wenn ein Spellbook eine der oben angesprochenen Funktionen benutz, um
+einen numerischen Wert zu ermitteln und anstelle des Wertes steht etwas,
+das als Funktion interprtiert werden kann, so wird diese Funktion
+ausgewertet und das Ergebnis als Wert genommen. Als Funktion
+interpretiert werden kann:
+
+ o Eine Closure
+ o Ein Array ({objekt,funktionsname}) oder ({objektname,funktionsname})
+ o Ein Funktionsname. Hierbei sollte man sich jedoch darueber im
+ klaren sein, in welchem Objekt versucht wird die Funktion
+ aufzurufen. Ueblicherweise geschieht dies im Spellbook, jedoch
+ werden SI_DIFFICULTY, SI_SKILLLEARN und SI_SPELLCOST
+ auch beim Lernen benoetigt und dies geschieht vom Gildenobjekt
+ aus. Wenn bei diesen 3 Eintraegen eine Funktion den Wert liefern
+ soll, so muss sie in eine der drei anderen Formen eingetragen werden,
+ damit das richtige Objekt ermittelt werden kann.
+
+SIEHE AUCH: execute_anything
+
+Fuer nicht-numerische Werte kann man GetData verwenden. Dabei werden
+jedoch nur closures automatisch ausgewertet.
+
+Skill Attribute
+++++++++++++++++
+
+Skill-Attribute sind Attribute, die alle anderen Skills beeinflussen koennen.
+Normalerweise sind alle Skill-Attribute 100%, sie koennen jedoch fuer
+kurze Zeit auf andere Werte zwischen 10% und 1000% gesetzt werden. Bei
+der Abfrage der Attribute werden 3 Werte beruecksichtigt:
+
+ o Wert, der vom Lebewesen selbst gesetzt wurde.
+ o Wert, der von einem anderen unter 100% gesetzt wurde. Wenn
+ mehrere andere Lebewesen den Wert unter 100% gesetzt haben so
+ gilt die Aenderung von dem mit dem hoechsten Level. Eine solche
+ Aenderung wird ueblicherweise von einem Gegner veranlasst.
+ o Wert, der von einem anderen ueber 100% gesetzt wurde. Auch hier
+ gilt die Aenderung von dem Lebewesen mit dem hoechsten Level.
+
+Wenn z.B. ein Spieler seine Geschwindigkeit fuer zwei Minuten auf 200%
+und ein Monster sie fuer eine Minute auf 25% setzt, so ist sie eine Minute
+lang 50% und die naechste Minute 200% bevor sie wieder auf 100% gesetzt
+wird.
+
+SIEHE AUCH: ModifySkillAttribute
+
+Restriction Mappings
++++++++++++++++++++++
+
+Mit Restriction Mappings koennen Einschraenkungen auesserst einfach
+angegeben werden. In dem Mapping wird einfach nur angegeben, was durch
+welchen Wert eingeschraenkt werden soll. Wenn z.B. mindestens Level 15
+und Intelligenz 10 verlangt wird, so ist das Mapping
+([P_LEVEL:15,A_INT:10]). Folgende Einschraenkungen koennen verlangt
+werden:
+
+SIEHE AUCH: check_restrictions
+
+Einschraenkungen werden mit check_restrictions(spieler,mapping)
+ueberprueft. Die Funktion liefert 0 zurueck wenn der Spieler alle
+Einschraenkungen erfuellt und einen String mit der Begruendung, falls eine
+Einschraenkung nicht erfuellt ist.
+
+Programmierrichtlinien
+=======================
+
+ o In Spellbooks moeglichst oft Faktoren und Offsets beruecksichtigen.
+ o Die Skill-Attribute beruecksichtigen, falls moeglich.
+ o Alles Spells muessen eine Verzoegerungszeit haben, in der kein
+ weiterer Spell anwendbar ist. Hiervon kann es Ausnahmen geben, wenn
+ das Gildenkonzept es anders vorsieht (z.B. bei den Kaempfern) oder
+ sonst reguliert.
+ o Kostenlose Spells sollte es nicht geben. Falls doch, dann nur mit sehr
+ hoher Verzoegerungszeit, sonst lassen die Leute nur ihr Frontend
+ spielen.
+ o Jeder Skill sollte eine levelabhaengige maximale Faehigkeit haben.
+ D.h., wenn SI_DIFFICULTY gesetzt ist sollte der Wert groesser als
+ -100 sein.
+ o Spells duerfen nicht Monster beliebig hoher Staerke einfach
+ umhauen. Es sollte nur bis zu einer Maximalstaerke moeglich sein.
+ o Der Schaden, den ein Spruch bewirkt, darf von der Staerke nicht
+ groesser sein, als der, den eine Waffe mit WC 25*SP bewirken
+ wuerde. Auch hier sollte man ein wenig gesunden Menschenverstand
+ spielen lassen - es kommt auch immer drauf an, ob ein Angriff
+ magisch ist oder physikalisch.
+ o Die Heilung sollte nicht die dafuer noetigen SP ueberschreiten.
+ Ausnahmen fuer explizite Heilgilden (Klerus) kann es geben.
+
+Auswirkung von SI_DIFFICULTY
+-----------------------------
+
+Folgende Maximalwerte sind fuer SI_ABILITY bei den angegebenen Leveln
+moeglich, wenn SI_DIFFICULTY auf den Wert in der linken Spalte gesetzt
+ist.
+
+SIEHE AUCH: LimitAbility oder /std/living/skills::LimitAbility
+
+5. Okt 2011 Gloinson
+
diff --git a/doc/wiz/git b/doc/wiz/git
new file mode 100644
index 0000000..7200ff3
--- /dev/null
+++ b/doc/wiz/git
@@ -0,0 +1,23 @@
+Nutzung von Git im MorgenGrauen
+===============================
+
+Was ist Git?
+ Git ist eine Software zur (verteilten) Versionsverwaltung von Dateien.
+ (http://git-scm.com/, http://de.wikipedia.org/wiki/Git)
+ Fuer Windows gibt es ein Paket, welches auch die Integration in den Explorer
+ anbietet:
+ https://code.google.com/p/gitextensions/
+
+
+SIEHE AUCH
+ git-repositories: Repository-Verwaltung im Mud
+ git-howto: Wie git benutzt wird
+ git-workflow: Ein simples Beispiel eines Arbeitsflusses mit Git
+ git-kooperation: Erweiterung fuer Fortgeschrittene zu git-workflow
+ git-sync: Wie die Synchronisierung zw. git-Repos und Mudlib ablaeuft
+ git-faq: haeufig gestellte Fragen/Probleme
+ git-links: Verweise ins WWW
+
+LETZTE AeNDERUNG:
+ 25.03.2011, Zesstra
+
diff --git a/doc/wiz/git-exclude b/doc/wiz/git-exclude
new file mode 100644
index 0000000..439b5db
--- /dev/null
+++ b/doc/wiz/git-exclude
@@ -0,0 +1,27 @@
+Beim Import von Verzeichnissen aus dem Mud in ein git Repository und bei der
+Synchronisierung zwischen Repositories und Mudlib werden die folgenden
+Verzeichnisse und Dateien komplett ignoriert.
+
+# fuer div. SCMs benutzte Verzeichnisse
+- .svn/
+- .git/
+- .gitignore
+- CVS/
+# Savefiles
+- *.o
+# logs and rep files
+- *.log
+- log/
+- *.rep
+- *.err
+# backups of editors
+- *~
+- *.swp
+# this should als never be imported - marks a directory to be imported.
+- git-mud-import
+# keine gepackten Archive
+- *.gz
+- *.bz2
+- *.zip
+- *.tar
+
diff --git a/doc/wiz/git-faq b/doc/wiz/git-faq
new file mode 100644
index 0000000..7ed4826
--- /dev/null
+++ b/doc/wiz/git-faq
@@ -0,0 +1,83 @@
+Haeufig gestellte Fragen zum Thema Git im Morgengrauen
+======================================================
+
+* Was muss ich machen, damit mein Git-Repo automatisch mit dem MG
+* synchronisiert wird?
+ Eine Synchronisation findet automatisch statt, wenn man einen Import eines
+ Verzeichnisses aus dem Mud durchfuehrt.
+ Macht man dies nicht, sondern erstellt sich unabhaengig vom Mud das Repo,
+ muss man sich an einen Erzmagier mit Shellzugang wenden.
+
+* Aufnahme als Regionsmitarbeiter/Regionsmagier/Weiser/Erzmagier/Gott
+ Dies ist zurzeit nur durch einen EM moeglich.
+
+* Wie benutze ich Git unter Windows?
+ GitHub hat eine Anleitung fuer msysgit, welche im wesentlichen auch fuers MG
+ brauchbar ist:
+ http://help.github.com/win-set-up-git/
+ Eine weitere Moeglichkeit ist hier angeben:
+ http://rogerdudler.github.io/git-guide/
+ Einige in Frage kommende Git-Pakete sind hier kurz vorgestellt:
+ http://www.makeuseof.com/tag/5-windows-git-clients-git-job/
+ Eine Anleitung fuer die Nutzung von Putty als SSH-Client unter Windows
+ findet sich in contrib/putty.mkd auf https://github.com/sitaramc/gitolite/
+
+* Wie kann ich mir die Geschichte meines Repos graphisch anzeigen lassen?
+ Da gibt es verschiedene Loesungen, vor allem auch abhaengig vom
+ Betriebssystem. Auf allen geht vermutlich 'gitk' und 'git gui'.
+ Auf MacOS gibt es auch 'GitX'.
+
+* Kann man Aenderungen/Diffs/ farbig markiert anzeigen?
+ > git log -p --color-words
+ Alternativ kann man .git/config folgende Parameter setzen:
+ [color]
+ color.diff=auto
+ color.grep=auto
+ color.status=auto
+
+ Wenn man es generell bunt haben will, setzt man einfach
+ [color]
+ color.ui=auto
+
+ in die Konfigurationsdatei.
+
+* Warum soll ich denn die color-Einstellungen auf auto und nicht true setzen?
+ Der Wert auto bewirkt, dass git nur dann die Ausgaben einfaerbt, wenn diese
+ nach STDOUT gehen. Ansonsten bekommt man den ASCII-kodierten Farbstring in
+ die Ausgabedatei geschrieben.
+
+* Wie kann ich eine Repository loeschen?
+ Zur Zeit ist dies nur durch einen EM mit Shellzugang auf dem MG-Rechner
+ moeglich.
+
+* Kann ich an einem Gebiet, fuer das ich keinen Schreibzugriff habe, helfen
+* einen Bug zu fixen?
+ Ja - sofern Du Leserechte auf das Repository hast. Du kannst das Repo dann
+ forken, d.h. eine Kopie erstellen. Die beste Methode hierfuer ist
+ > ssh git@mg.mud.de fork d/gebirge/zook/wald players/zesstra/public/zwald
+ Hierbei wird ein Clone des Repos erstellt und sich gemerkt, welches das
+ Original war. In Deinem Repo kannst Du nun einen Bugfix machen. Bist Du
+ fertig, sagst Du dem Gebietsmagier (oder einem zustaendigen RM) Bescheid und
+ bittest ihn, den entsprechenden Branch (z.B. syntax_bugfix) zu pullen.
+
+* Wie vermeide ich einen 'merge commit', wenn ich lokale Aenderungen in einem
+* Zweig habe, in den ich Aenderungen aus dem MG pullen moechte?
+ Eine Moeglichkeit hierfuer ist das Pullen mit 'git pull --rebase', um git
+ einen implizites Rebase beim Pull durchfuehren zu lassen.
+
+
+Was ist git?
+Wo krieg ich git her?
+Wie kann ich das Repository clonen?
+Wie kann ich ein Changelog anzeigen lassen?
+Wie kann ich ein Changelog mit Diff anzeigen lassen?
+
+SIEHE AUCH:
+ git-repositories: Repository-Verwaltung im Mud
+ git-howto: Wie git benutzt wird
+ git-workflow: Ein simples Beispiel eines Arbeitsflusses mit Git
+ git-sync: Wie die Synchronisierung zw. git-Repos und Mudlib ablaeuft
+ git-links: Verweise ins WWW
+
+10.03.2015 Amaryllis
+
diff --git a/doc/wiz/git-howto b/doc/wiz/git-howto
new file mode 100644
index 0000000..8a6acdd
--- /dev/null
+++ b/doc/wiz/git-howto
@@ -0,0 +1,111 @@
+Git-Benutzung im MorgenGrauen
+=============================
+
+0. Einleitung
+ Hier soll kurz beschrieben werden, wie man nun an die Repositories auf dem
+ Mudrechner rankommt.
+ Es wird an dieser Stelle vorausgesetzt, dass der Leser/Magier
+ grundsaetzlich weiss, was Git ist und wie es benutzt wird. Hier sollen
+ lediglich Besonderheiten im Zusammenhang mit dem MG erlaeutert werden.
+ Ebenso wird vorausgesetzt, dass der Magier Git und einen SSH-Client auf
+ seinem Rechner installiert hat.
+
+ Wer jetzt noch nix von Git weiss, sei auf die reichhaltig im Netz
+ verfuegbare Doku verwiesen: s. a. git-links.
+
+
+1. Zugriffsrechte auf Git-Repositories
+ Zunaechst muss man sich als Git-Nutzer eintragen lassen. Hierzu braucht man
+ ein SSH-Schluesselpaar, welches man z.B. mittels ssh-keygen erstellen
+ kann. Den _oeffentlichen_ Schluessel (.pub am Ende) legt man dann als
+ <magier>.pub in sein Homeverzeichnis und spricht einen EM (z.B. Zesstra)
+ an.
+
+ Mittels des Befehls
+ > ssh git@mg.mud.de info
+ kann man sich anzeigen lassen, auf welche existierenden Repositories man
+ welche Zugriffsrechte hat (R: lesen, W: schreiben). Beispiel:
+ R W (zesstra) d/inseln/zesstra/vulkanweg
+ In diesem Fall hat der Benutzer Lese- und Schreibrechte auf
+ d/inseln/zesstra/vulkanweg. Das Repository gehoert zesstra.
+
+ Zusaetzlich umfasst die Ausgabe auch die Zugriffsrechte aller _moeglichen_
+ (aber noch nicht existierenden) Repos.
+ Wichtig ist hier das Erstellungsrecht (C). Beispiel:
+ C R W d/unterwelt/zesstra/[a-zA-Z]{1}[a-zA-Z0-9_.\-]*
+ Hier hat der Benutzer auf alle Repos unterhalb von d/unterwelt/zesstra/
+ (wobei alle diese Repos mit einem Buchstaben beginnen und ansonsten nur
+ Buchstaben, Zahlen, _, . und - enthalten duerfen) Lese-, Schreib- und
+ Erstellungsrechte.
+
+2. Ein existierendes Repository clonen
+ Dies erfolgt ganz simpel mit dem Befehl:
+ > git clone git@mg.mud.de:players/zesstra/testgebiet <zielverzeichnis>
+ Das Zielverzeichnis ist hierbei beliebig. Empfehlung: alle MG-Repos in
+ einem Verzeichnis sammeln und dort die Verzeichnisstruktur aus dem Mud
+ beibehalten:
+ > git clone git@mg.mud.de:players/zesstra/testgebiet
+ players/zesstra/testgebiet
+ Damit Aenderungen spaeter auch Euren Magiernamen tragen, geht nun bitte in
+ Euer geclontes Repo und setzt Namen und eMail-Adresse:
+ > git config user.name "Magier"
+ > git config user.email "user@example.com"
+
+3. Ein neues Repository erstellen.
+ Voraussetzung: das Verzeichnis im Mud existiert.
+ Dies geht, wenn ihr Schreibzugriff auf das Verzeichnis im Mud habt. Legt
+ einfach in dem Verzeichnis eine Datei namens "git-mud-import" an (Inhalt
+ ist egal) und wartet bis zur naechsten vollen Stunde.
+ ACHTUNG: das Verzeichnis im Mud darf NICHT leer sein, sondern muss min.
+ eine Datei (ggf. in einem Unterverzeichnis) enthalten!
+
+ Anmerkungen:
+ Existiert ein Repo bereits, ist ein automatischer Import aus dem Mud nicht
+ mehr moeglich.
+ Bei einem "git clone" auf ein noch nicht existierendes Repo wird das
+ das Repo automatisch angelegt - dieses Repo wird dann aber nicht mit
+ dem Mud synchronisiert!
+ Daher: erst (erfolgreich) importieren, dann clonen.
+
+4. Arbeiten mit dem Repo
+ Hierzu sei zuerst einmal auf die allgemein im Netz verfuegbare Dokumentation
+ zu Git und natuerlich seine Manpages verwiesen.
+ Einen beispielhaften Arbeitsablauf findet sich in der Manpage git-workflow.
+
+5. Synchronisation mit dem Mud
+ Repos koennen bei einem 'git push' von aussen automatisch die Aenderungen
+ des master-Branches ins Mud uebertragen. Desweiteren koennen Aenderungen
+ aus dem Mud automatisch in das Repo importiert werden.
+ Auf diese Weise ist das Verwenden von FTP fast ueberfluessig.
+ Details sind in der Manpage git-sync angegeben.
+
+6. Loeschen von Repositories
+ Git-Repos, die von euch selber GEHOEREN (Schreibrechte allein reichen nicht)
+ koennen geloescht und - zumindest eine Weile auch wieder restauriert werden.
+
+6.1. Loeschen
+ > ssh git@mg.mud.de D trash players/caldra/nebelberge
+ players/caldra/nebelberge moved to trashcan.
+
+6.2. Muelleimer anzeigen
+ > ssh git@mg.mud.de D list-trash
+ players/caldra/nebelberge/2011-11-28_22:35:55
+
+6.3. Restaurieren
+ > ssh git@mg.mud.de D restore players/caldra/nebelberge/2011-11-28_22:35:55
+ players/caldra/nebelberge/2011-11-28_22:35:55 restored to
+ players/caldra/nebelberge
+
+ Es versteht sich von selbst, dass Ihr mit diesem Mittel sehr zurueckhaltend
+ umgehen solltet. Bei Missbrauch wird ggf. ein Backup eingespielt und diese
+ Moeglichkeit wieder geloescht.
+
+SIEHE AUCH:
+ git-repositories: Repository-Verwaltung im Mud
+ git-workflow: Ein simples Beispiel eines Arbeitsflusses mit Git
+ git-sync: Wie die Synchronisierung zw. git-Repos und Mudlib ablaeuft
+ git-faq: haeufig gestellte Fragen/Probleme
+ git-links: Verweise ins WWW
+
+29.01.2013 Gloinson
+Letzte Aenderung: 02.07.2014 Notstrom
diff --git a/doc/wiz/git-kooperation b/doc/wiz/git-kooperation
new file mode 100644
index 0000000..acbda6e
--- /dev/null
+++ b/doc/wiz/git-kooperation
@@ -0,0 +1,68 @@
+Erweiterung zum Git-Workflow:
+=============================
+
+Bei manchen Projekten will man mit anderen Magiern kooperieren, aber:
+* die Dateien im MUD fuer die Spieler unveraendert lassen
+* in einem ordentlichen Zweig zusammenarbeiten
+
+Dazu kann man Zweige auch remote, also im MUD erstellen. Da nur der
+'master'-Zweig in das MUD selbst synchronisiert wird, kann man ueber
+das MUD so die Repositories auf mehr als einen Computer/mehr als einer
+Person synchronisieren, ohne die Spieler mit seiner Entwicklungsarbeit
+zu behelligen:
+
+# Alternativen in/zu Schritt 4: Kooperation in einem remote Zweig.
+Falls ich mit anderen Leuten meinen Code teilen will, dieser aber nicht im
+MUD im 'master'-Zweig auftauchen (also als Dateiaenderung fuer alle Spieler
+gelten) soll, kann ich auch nur meinen Zweig selbst ins MUD schicken:
+> git checkout neue_kampftaktik
+> git push -u git@mg.mud.de:/dings/bums neue_kampftaktik
+
+Als Antwort duerfte sowas wie:
+ * [new branch] neue_kampftaktik -> neue_kampftaktik
+dort stehen.
+
+Mit
+> git pull
+koennen wir uns diese Aenderungen am MUD-Repository holen. Der Zweig
+'neue_kampftaktik' ist jetzt ein Zweig auch im MUD und alle Leute,
+die sich jetzt das Repository /dings/bums clonen, steht genau dieser
+Zweig mit all unseren Aenderungen jetzt auch zur Verfuegung.
+
+Unser lokaler Zweig 'neue_kampftaktik' bekommt aber die Aenderungen
+an diesem Zweig anderer eventuell noch nicht ganz mit. Mit
+> git branch --set-upstream neue_kampftaktik remotes/origin/neue_kampftaktik
+sagen wir dem lokalen Zweig, dass er ab jetzt mit dem remotes-Zweig
+'neue_kampftaktik' verbunden ist.
+
+Damit bekommen wir etwaige remote-Aenderungen in diesem Zweig nach einem
+> git pull
+bei einem folgenden
+> git checkout neue_kampftaktik
+direkt mitgeteilt, eventuell in der Form:
+ Your branch is behind 'origin/neue_kampftaktik' by 1 commit, and can be
+ fast-forwarded.
+Das ist sehr einfach durch ein
+> git merge origin/neue_kampftaktik
+korrigierbar und schon koennen wir selber wieder an dem aktualisierten Zweig
+arbeiten und Aenderungen pushen. Siehe Schritt 5.
+
+Ziel einer solchen Zusammenarbeit ist natuerlich immer, irgendwann auch
+wieder den aus Schritt 4 bekannten Merge gegen den Zweig 'master' durchzu-
+fuehren, damit die Spieler was davon haben.
+Wenn wir also irgendwann diesen Merge durchgefuehrt haben und der Zweig
+'neue_kampftaktik' unnoetig geworden ist, koennen wir ihn auf der Seite
+des MUDs mit:
+> git push git@mg.mud.de:/dings/bums :neue_kampftaktik
+aufraeumen. Der einzige Unterschied zum Erstellen des Zweiges auf MUD-Seite
+ist tatsaechlich der ':' vor dem Namen des Zweigs.
+Achtung: das geht momentan (noch) nicht und auf 'master' ohnehin nie.
+
+SIEHE AUCH
+ git-repositories: Repository-Verwaltung im Mud
+ git-howto: Wie git benutzt wird
+ git-workflow: Ein simples Beispiel eines Arbeitsflusses mit Git
+ git-sync: Wie die Synchronisierung zw. git-Repos und Mudlib ablaeuft
+ git-faq: haeufig gestellte Fragen/Probleme
+
+02. Feb 2013 Gloinson
diff --git a/doc/wiz/git-links b/doc/wiz/git-links
new file mode 100644
index 0000000..02592a2
--- /dev/null
+++ b/doc/wiz/git-links
@@ -0,0 +1,38 @@
+Liste von nuetzlichen und weiterfuehrenden Links im Netz
+========================================================
+
+ * Das 'offizielle' Tutorial
+ http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
+ * Git - SVN Crash Course (fuer Leute, die SVN kennen)
+ http://git.or.cz/course/svn.html
+ * Everyday git with 20 commands or so
+ http://www.kernel.org/pub/software/scm/git/docs/everyday.html
+ (sortiert nach Developers, Integrators, Admins)
+ * Das git Community Book (sehr empfehlenswert)
+ http://book.git-scm.com/
+ * Understanding git conceptually
+ http://www.eecs.harvard.edu/~cduan/technical/git/
+ * Git cheat sheets
+ http://help.github.com/git-cheat-sheets/
+ http://jan-krueger.net/development/git-cheat-sheet-extended-edition
+ https://github.com/AlexZeitler/gitcheatsheet/blob/master/gitcheatsheet.pdf
+ http://www.cheat-sheets.org/saved-copy/git-cheat-sheet.pdf
+ http://cheat.errtheblog.com/s/git
+ * Guides/Howtos von GitHub
+ http://help.github.com/
+ * Difference of merge and pull
+ http://longair.net/blog/2009/04/16/git-fetch-and-merge/
+ * Div. Tips und Tricks
+ http://longair.net/blog/2009/04/25/a-few-git-tips/
+ * Git fuer Windows
+ https://code.google.com/p/gitextensions/
+ (Mit Integration in den Explorer)
+ * Git-Benutzung unter Windows
+ http://rogerdudler.github.io/git-guide/
+ http://help.github.com/win-set-up-git/
+ * Git-Interna verstaendlich erklaert:
+ Git For Ages 4 And Up
+ https://www.youtube.com/watch?v=1ffBJ4sVUb4
+
+10.03.2015 Amaryllis
+
diff --git a/doc/wiz/git-repositories b/doc/wiz/git-repositories
new file mode 100644
index 0000000..9ed7c33
--- /dev/null
+++ b/doc/wiz/git-repositories
@@ -0,0 +1,72 @@
+Git-Repositories im MorgenGrauen
+================================
+
+Die folgenden Repositories stehen fuer die Benutzung durch Magier bereit bzw.
+lassen sich durch Magier bei Bedarf (leer oder durch Import von Verzeichnissen
+aus dem Mud) anlegen:
+
+* /d/region/magier/*
+ Verzeichnisse unterhalb der Magierebene in den Regionen lassen sich in
+ git-Repos aufnehmen.
+ Anlegen: Regionsmitarbeiter, Magier mit Schreibzugriff auf den Pfad
+ Schreibzugriff: Eigentuemer (Magier), Regionsmagier dieser Region, Weise
+ Lesezugriff: s. Schreibzugriff (wegen secure/)
+
+* /p/service/magier/*
+ Anlegen: Weise, Magier mit Schreibzugriff auf den Pfad
+ Schreibzugriff: Eigentuemer (Magier), Weise
+ Lesezugriff: alle Magier (>= 20)
+
+* /players/magier/*
+ Anlegen: Magier selber, Magier mit Schreibzugriff auf den Pfad
+ Schreibzugriff: Magier selber
+ Lesezugriff: Magier selber
+
+* /players/magier/public/*
+ Anlegen: Magier selber, Magier mit Schreibzugriff auf den Pfad
+ Schreibzugriff: Magier selber, Weise
+ Lesezugriff: jeder Magier (>= 20)
+
+* playground/magier/*
+ Spielwiese zum Testen von Magiern. Soll zum Rumspielen und Testen von Git
+ dienen.
+ Diese Repos werden NICHT mit dem Mud synchronisiert.
+ Diese Repos werden automatisch geloescht, wenn sie laenger als 14 Tage nicht
+ veraendert werden.
+ Anlegen: jeder Magier
+ Schreibzugriff: Magier selber, Weise
+ Lesezugriff: jeder Lehrling (und hoeher) (>= 15)
+
+Uebrigens geht es explizit NICHT, sein gesamtes ~ in ein Repo zu fassen.
+
+Wenn man sein kompletten Regionsverzeichnis (/d/region/magier) in ein Repo
+importiert, sind anschliessend keine einzelnen Repos unterhalb dieses
+Verzeichnisses moeglich (bzw. fuehren zu Problemem)! Ebenso kann das komplette
+Magierverzeichnis nicht mehr als Repo importiert werden, wenn es unter ihm
+schon Repos gibt.
+
+Erzmagier und Goetter haben uebrigens auf _alle_ Repositories Lese- und
+Schreibzugriff. Sie sind auch die einzigen, die in den Repositories einen sog.
+Rewind durchfuehren koennen - d.h. die Versionsgeschichte im Nachhinein
+aendern.
+Eine Beruecksichtigung von access_rights.c, ACCESS_RIGHTS etc. findet hierbei
+derzeit NICHT statt.
+
+Zum Loeschen von Repositories siehe Punkt 6 in git-howto.
+
+Ein (automatischer) Import bestehender Verzeichnisse aus dem Mud ist
+moeglich. In diesem Fall werden das so erstellte Repository und die Mudlib
+automatisch synchronisiert, wenn jemand von aussen in das Repository pusht.
+Hierbei wird _versucht_ etwaige gleichzeitige Aenderung im Git-Repo und in der
+Mudlib sinnvoll zu 'mergen' - im Falle von Konflikten ist dies nicht immer
+moeglich, weswegen Magier auf das Ergebnis solcher automatisierter Merges ein
+Auge werfen sollten.
+
+SIEHE AUCH:
+ git-howto: Wie git benutzt wird
+ git-workflow: Ein simples Beispiel eines Arbeitsflusses mit Git
+ git-sync: Wie die Synchronisierung zw. git-Repos und Mudlib ablaeuft
+ git-faq: haeufig gestellte Fragen/Probleme
+ git-links: Verweise ins WWW
+
+29.01.2013 Gloinson.
diff --git a/doc/wiz/git-sync b/doc/wiz/git-sync
new file mode 100644
index 0000000..87c5d9f
--- /dev/null
+++ b/doc/wiz/git-sync
@@ -0,0 +1,49 @@
+Synchronisation zwischen git-Repositories und Mud
+=================================================
+
+I. Push von aussen ins Mud.
+
+Am Ende es Pushes (im sog. post-update hook) wird ein Script gestartet,
+was folgendes macht:
+
+1) Wenn fuer die Synchronisation mit dem Mud aktiv ist, wird mit der Mudlib
+ gesynct. Wenn nicht: Ende
+2) Zunaechst wird in einem lokalen Clone des git-Repositories ein temporaerer
+ Branch zum Mergen von Aenderungen aus dem Mud angelegt (auto-mud-sync),
+ welcher bei dem Tag last-auto-mud-sync startet und dieser Branch
+ ausgecheckt.
+3) Mit Hilfe von rsync werden alle Aenderungen aus der Mudlib hereinkopiert.
+4) Wenn Aenderungen existieren, wird ein neuer Commit auf dem Branch gemacht.
+5) Anschliessend wird Branch master ausgecheckt.
+6) Wenn es Aenderungen gab, die in 4) commitet wurden, wird jetzt der Branch
+ auto-mud-sync mit diesem Commit in master gemergt.
+ Kommt es hierbei zu Konflikten, werden die _automatisch_ zugunsten des
+ Standes der git-Repositories aufgeloest, d.h. es gehen ggf. Aenderungen aus
+ dem Mud verloren. Es kann hierbei daher passieren, dass von 8 im Mud
+ geaenderten Zeilen nur 6 uebernommen werden, weil 2 Zeilen in Konflikt mit
+ den Aenderungen im git-Repository stehen. Daher ist es wichtig, das
+ Ergebnis dieses Merges im Nachhinein zu pruefen und ggf. zu korrigieren!
+7) Falls es Aenderungen gab, wird jetzt der in 7) erstellte Merge-Commit ins
+ git-Repository gepusht.
+8) Der jetzt gemergte Stand wird per rsync ins Mud kopiert.
+9) Das Tag last-auto-mud-sync wird aktualisiert.
+
+
+II. Automatischer regelmaessiger Commit vom Mud
+
+Jeden Tag um 05:11 wird via cronjob und das Script ~/scripts/git-autocommit
+fuer jedes Repo in ~/git-repositories/ das unter I. beschriebene Script
+~/scripts/git-sync2lib ausgefuehrt.
+
+
+III. Import von Verzeichnissen aus dem Mud
+
+Zu jeder vollen Stunde wird in allen Verzeichnissen unter /d/, /p/ und
+/players/ die Datei 'git-mud-import' gesucht. Alle Verzeichnisse, in denen
+diese existiert, werden in gitolite importiert und gleichzeitig auch ein Clone
+in ~/git-repositories/ erstellt, d.h. dass die Synchronisationsmassnahmen
+unter I. und II. fuer dieses neue git-Repository aktiv sind.
+
+LETZTE AeNDERUNG:
+05.04.2011, Zesstra
+
diff --git a/doc/wiz/git-workflow b/doc/wiz/git-workflow
new file mode 100644
index 0000000..655c76d
--- /dev/null
+++ b/doc/wiz/git-workflow
@@ -0,0 +1,151 @@
+Typischer Arbeitsablauf
+=======================
+
+(Es gibt andere Arbeitsweisen, aber dies hier ist eine, die sich bewaehrt
+ hat.)
+
+Nehmen wir an, ich moechte etwas neues einbauen, einen Bug fixen etc.
+Alle der folgenden Schritt werden auf eurem eigenen Rechner in eurem lokalen
+Clone des jeweiligen Repositories durchgefuehrt.
+
+# Schritt 1: Repository clonen und/oder updaten
+> git clone git@mg.mud.de:/dings/bums
+> git checkout master
+> git pull
+Zuerst einmal wird ein checkout des Zweiges 'master' gemacht. Und in diesen
+Zweig hol ich mir erstmal den aktuellen Stand aus dem Mud (pull).
+
+Jetzt moechte ich alle Aenderungen erstmal in einem separaten Zweig machen.
+Warum? Weil dann der 'master' (das ist der aktive Zweig im Mud!) immer in
+einem benutzbaren Zustand ist. Desweiteren kann man einen Zweig einfach
+wegwerfen, wenn irgendwas groesseres schiefgelaufen ist...
+Ausserdem ist es dann einfacher, zwischenzeitliche Aenderungen aus dem Mud zu
+integrieren.
+
+# Schritt 2: Neuen Zweig erstellen
+> git checkout -b neue_kampftaktik
+Hiermit wird ein neuer Zweig erstellt und gleichzeitig in ihn gewechselt.
+
+Hier mach ich jetzt alle moeglichen Arbeiten und Basteleien, die ich fuer die
+neue Kampftaktik brauche. Tipps dazu:
+* Viele und haeufige Commits machen! Je kleiner einzelne Commits sind, desto
+ besser kann man Aenderungen spaeter verfolgen (was z.B. super ist, wenn
+ jemand was abnehmen muss!) und desto besser kann man einzelne Aenderungen
+ spaeter bei Bedarf auch rueckgaengig machen, wenn man merkt, dass man
+ stellenweise Unsinn gebaut hat. ;-)
+* Thematisch unterschiedliche Dinge in verschiedene Commits packen. Also zB
+ erst Syntaxfehler editieren und commiten, dann eine neue Methode fuer
+ etwas ganz andere schreiben und commiten.
+
+# Schritt 3.1: Aenderungen pruefen
+> git status
+Hiermit lasse ich mir anzeigen, welche Dateien nicht-committete Aenderungen
+enthalten (oder neu sind/geloescht wurden).
+
+> git diff
+Dies zeigt mir alle nicht-committeten Aenderungen an - zeilenweise verglichen
+mit dem vorherigen Zustand.
+
+# Schritt 3.2: Aenderungen in lokales Repository commiten
+> git add <file> // einzelne Files auswaehlen
+ODER
+> git add -A ./ // alle Files auswaehlen
+Hiermit merke alle gemachten Aenderungen fuer den naechsten Commit vor.
+Ich koennte hier aber auch einzelne Dateien auswaehlen oder sogar nur
+bestimmte Teile der Aenderungen in einer Datei. (Hierzu bitte die
+Git-Doku bemuehen.)
+
+> git commit
+Hiermit erstelle ich einen Commit, der die bisherigen Aenderungen umfasst.
+Dabei wird ein Editor geoeffnet, in den ich eine informative Nachricht ueber
+meine Aenderungen hinterlassen kann. Das ist besonders wichtig, wenn ich in
+fremden Gebieten arbeite, aber auch fuer mich und einen etwaigen abnehmenden
+Magier sehr sinnvoll.
+Anregung: Die erste Zeile ist das sog. Betreff des Commits - vergleichbar mit
+dem Betreff einer eMail. Anschliessend sollte eine leere Zeile folgen und
+danach eine laengere Beschreibung eingeben werden, sofern noetig/sinnvoll.
+
+Wenn ich an diesem Punkt mit dem Bugfix oder Feature noch nicht fertig bin:
+einfach die letzten 4 Befehle aus Schritt 3 beliebig oft wiederholen, d.h.
+beliebig viele weitere Commits machen.
+
+# Schritt 4: Aenderungen in lokalen Master-Zweig mergen
+Bin ich dann schliesslich aber mal fertig, gehe ich erstmal zurueck zum
+master-Zweig:
+
+> git checkout master
+Huch! Ploetzlich sind alle Dateien auf dem alten Stand! Keine Sorge,
+unsere Aenderungen sind im Zweig 'neue_kampftaktik' sicher verwahrt.
+
+Achtung: wenn ihr mit anderen zusammen arbeitet, koennte jemand
+anderes im MUD Aenderungen vorgenommen haben. Ein einfaches
+> git pull
+um die Dateien im 'master'-Zweig auf den neuesten Stand zu bringen,
+zeigt euch auch Aenderungen. Wenn da jetzt
+ 'Already up-to-date.'
+steht, ist alles in Butter, ansonsten siehe unten bei 4.1.extra.
+
+> git merge neue_kampftaktik
+Mit diesem Kommando hole ich nun alle Aenderungen aus meinem Zweig
+'neue_kampftaktik' in den Zweig 'master' (merge).
+
+# Schritt 5: Aenderungen in das MUD-Repository uebertragen
+Jetzt bin ich bereit, die Aenderungen ins Mud zu uebertragen:
+> git push
+Job done!
+Hier kommen jetzt div. Ausgaben vom Mud, die etwas ueber den Erfolg und
+Misserfolg des Pushes sagen. ;-)
+Wenn am Ende steht
+ 'Your changes were copied to the mudlib.'
+ist alles erfolgreich.
+
+Steht am Ende ein
+ 'Your changes were merged successfull with changes in the mudlib and the
+ merged state was copied to the mudlib. Do not forget to pull the merge
+ commit!"
+ist an sich auch alles gut. Aber dann gab es im Mud eben doch noch
+Aenderungen, die es nicht im Git-Repo gab, die gemerged wurden. In diesem
+Fall sollte man den aktuellen Zustand sich nochmal holen:
+> git pull
+Und dann anschauen, dieser Merge auch das richtige gemacht hat:
+> git log -p
+Hiermit kriege ich eine schoene Liste aller Commits angezeigt und -p sorgt
+dafuer, dass dabei alle Aenderungen angezeigt werden, nicht nur die
+Commit-Nachricht.
+
+# Sonderfaelle und erweiterte Moeglichkeiten
+# Schritt 4.1.extra: Zwischenzeitliche Aenderungen im MUD beruecksichtigen
+
+Es koennte sein, dass man fuer den Branch ne ganze Weile gebraucht hat -
+und dass waehrend meiner Arbeit jemand anders Aenderungen (im Mud oder
+Repo) gemacht hat.
+
+Diese Aenderungen sollte man sich wie geschrieben als erstes nach dem
+Umschalten zum master-Zweig holen:
+> git pull
+
+Jetzt geh ich wieder in meinen Zweig (ohne -b)
+> git checkout neue_kampftaktik
+und mache ein sog. Rebase. Damit verschiebe ich sozusagen, den Punkt,
+an dem mein Zweig vom 'master' abzweigt und tue so, als ob die eben
+geholten Aenderungen schon da gewesen waeren, als ich den Zweig erstellte.
+(Andere Sichtweise: ich nehme meine Zweig und setz ihn auf den aktuellen
+ 'master' dran.)
+> git rebase master
+
+Der Vorteil ist: wenn jetzt was kaputt gegangen ist, es also Konflikte gibt,
+dann gibt es die nur in meinem Zweig 'neue_kampftaktik' und dort kann ich
+sie in aller Ruhe reparieren. Sowohl der 'master' im MUD als auch mein
+lokaler 'master' sind intakt.
+
+Und jetzt geht es wie oben weiter.
+
+SIEHE AUCH
+ git-repositories: Repository-Verwaltung im Mud
+ git-howto: Wie git benutzt wird
+ git-kooperation: Ein ueber git-workflow hinausgehendes Beispiel zur
+ Synchronisation bzw Kooperation mehrerer Magier/Rechner
+ git-sync: Wie die Synchronisierung zw. git-Repos und Mudlib ablaeuft
+ git-faq: haeufig gestellte Fragen/Probleme
+
+02. Feb 2013 Gloinson
diff --git a/doc/wiz/hausbau b/doc/wiz/hausbau
new file mode 100644
index 0000000..6c9c2a5
--- /dev/null
+++ b/doc/wiz/hausbau
@@ -0,0 +1,40 @@
+Hilfeseite fuer Magier: Hausbau im MorgenGrauen
+-----------------------------------------------
+
+Als Magier wird man desoefteren von Spielern gebeten, Ihnen beim
+Hausbau behilflich zu sein. Diese Bitte erfolgt meistens als
+
+1) 'Kannst Du hier in dem Raum wo ich bin, es mal so einrichten,
+ dass ich mein Haus abstellen und giessen kann'
+
+und
+
+2) 'Ich moecht hier gerne mein Haus abstellen, aber es soll un-
+ sichtbar sein, eine andere Kurzbeschreibung haben und man
+ soll es nicht mit <betrete> betreten koennen, oder .... '.
+
+
+Fuer 1) ist es relativ einfach. Man begebe sich als Magier in den
+Raum, zuecke sein MG-Tool und tippe ein
+
+ 'xcall $h->SetProp(P_HAUS_ERLAUBT,1)'.
+
+Dann fordere man den Spieler auf, sein Haus abzustellen und gies-
+sen und setze diese Property wieder auf 0.
+
+ACHTUNG: Das Abstellen eines Hauses muss unbedingt vorher mit dem
+------- Magier abgesprochen werden, dem dieser Raum gehoert! Bei
+ inaktiven Magier ist dies der zustaendige Regionsmagier.
+
+Bei 2) verfaehrt man, wie fuer den Fall 1) geschildert. Jedoch sind
+dazu noch andere Dinge notwendig. Da diese den Rahmen einer Hilfe-
+seite sprengen, liegt unter
+
+ /doc/beispiele/misc/seherhaus.c
+
+ein File, in dem alles ausfuehrlich dokumentiert ist.
+
+SIEHE AUCH: P_HAUS_ERLAUBT
+
+------------------------------------------------------------------------------
+LETZTE AeNDERUNG: Sam, 19.05.2001, 23:00:00 von Tilly
diff --git a/doc/wiz/heilung b/doc/wiz/heilung
new file mode 100644
index 0000000..3d1b6c8
--- /dev/null
+++ b/doc/wiz/heilung
@@ -0,0 +1,156 @@
+Heilung von Spielern durch Objekte, Raeume, portable Heilung
+============================================================
+
+ Generelles:
+ **********
+
+Neben den bekannten Heilstellen fuer Spieler (den Kneipen sowie gildeninterne
+Faehigkeiten) gibt es noch die Moeglichkeit, den Spielern Heilung durch Ver-
+wendung der LFUNs "heal_self", "restore_hit_points", "restore_spell_points",
+"buffer_hp" und "buffer_sp" Heilung zukommen zu lassen.
+
+Dies wird meist ueber Raeume gemacht, in denen der Spieler ein bestimmtes
+Kommando ausfuehren muss oder ueber Objekte, die der Spieler mit sich tragen
+kann ('tragbare Tanken'), um Heilung zu erfahren.
+
+ES WIRD EMPFOHLEN, jede mobile Heilung ueber "/std/food" zu implementieren.
+Dort muessen lediglich ein paar Properties gesetzt werden, um sicherzugehen,
+dass diese Heilungsregeln eingehalten werden.
+Gleichzeitig wird auch sichergestellt, dass z.B. Props von Containern, die
+Heilung enthalten, nach Leerung korrekt gesetzt werden.
+
+Neben diesen Moeglichkeiten gibt es auch noch Enttankungen, also die
+Moeglichkeit, im Spieler eine der Properties P_DRINK, P_FOOD oder P_ALCOHOL
+ueber die LFUNs "defuel_food/drink" oder "reduce_food/drink/alcohol" zu
+mindern. Dies ist eine Form der Heilung, da der Spieler danach wieder
+regulaer essen und trinken kann. Sie muss allerdings ortsgebunden sein.
+
+Grundsaetzlich kann eine Heilstelle natuerlich auch Schaden in einem Spieler
+verursachen. Das macht dann Sinn, wenn er z.B. der - fuer diese Heilstelle -
+'falschen' Gilde oder Rasse angehoert. Dabei MUSS fuer den Spieler aber
+vorher deutlich erkennbar gewesen sein, dass diese 'Heilstelle' fuer ihn
+nicht geeignet ist.
+
+ Spezifisches:
+ ************
+
+Bei jeder Form von Heilung MUSS "eat_food" (bei Essen) oder "drink_soft" (bei
+Trinken) und ggf. "drink_alcohol" verwendet werden! Diese Funktionen sorgen
+fuer einen unkomplizierten Ablauf der Heilung, da sie pruefen, ob der Spieler
+noch genuegend Tankkapazitaeten hat und wenn ja, die entsprechenden Properties
+(P_DRINK, P_FOOD oder P_ALCOHOL) automatisch raufsetzen.
+
+"drink_alcohol" ist in diesem Zusammenhang besonders wichtig, da es auf einen
+evtl. vorhandenen Saufskill prueft!
+
+Die Heilung selber muss dann aber noch ueber "heal_self", "restore_hit_points",
+"restore_spell_points", "buffer_hp" oder "buffer_sp" geschehen!
+
+Ortsgebundene Heilung:
+---------------------
+Kneipen: Hier ist klar, dass, je hoeher die Heilung ist, umso teurer die
+ Heilung sein muss. Ausserdem MUSS "buffer_hp" verwendet werden.
+ Ausnahme hiervon ist die Kneipe bei den Eistrollen im Warok.
+ Mit dem Pubtool ("/obj/tools/pubtool") kann man pruefen, ob die
+ Werte der Kneipe in Ordnung gehen.
+
+Raeume: Es gibt viele ortsgebundene Heilungsstellen im MG, welche in erster
+ Linie dazu da sind, den Spielern *in diesem Gebiet* eine Tankmoeg-
+ lichkeit zur Verfuegung zu stellen (-> Drakonien). Hierfuer sollte
+ man die Property P_LAST_XP benutzen, was aber allerdings keine
+ Pflicht ist, wenn man moechte, dass auch "gebietsfremde" Spieler
+ hier tanken gehen koennen (-> SSP). Dann wiederum sollte man aber
+ darauf achten, dass sie nicht zu gut sind, u.U. schwer zu erreichen
+ sind (-> T'emong), Blockmonster den Weg versperren (-> SSP) etc.
+
+ In jedem Fall aber MUSS eine Begrenzung der Tankmoeglichkeit sicher-
+ gestellt werden; entweder erfolgt die Limitierung durch Reset oder
+ durch Zeitbegrenzung (-> check_and_update_timed_key).
+
+ "eat_food" bzw. "drink_soft" MUSS bei den Tanken gesetzt werden, die
+ den Spieler darauf schliessen lassen, Nahrung aufgenommen zu haben
+ (-> "iss beeren", "trinke schleim", etc.).
+ Bei allen anderen (-> "rieche blume", etc.) sollten Qualitaet und
+ Quantitaet im Rahmen bleiben.
+ Diese ortsgebundenen Heilungen duerfen Instant-Tanken sein.
+
+Tragbare Heilung:
+----------------
+Tragbare Heilung sollte nach max 5 Resets verderben, die Wirkung vermindern
+oder verloren gehen. Sie sollte nicht beliebig im Spieler oder anderswo
+hortbar sein. Eine begrenzte Anzahl pro Reset kommt hierbei auch immer gut
+(gute Beispiele hierfuer: Drops von Twingi, Heilblaetter von Zook).
+
+Richtwerte fuer Aufloesung oder Wirkungsminderung von tragbarer Heilung:
+
+ Heilung Reset-Zeit
+ > 200 : 30- 60 min
+ 150 - 200 : 60-120 min
+ 100 - 150 : 90-180 min
+ 50 - 100 : 120-240 min
+ < 50 : 150-300 min
+
+Diese Richtwerte sind gute Anhaltspunkte, koennen aber bei Bedarf mit dem
+Erzmagier der Heilungs-Balance individuell abgestimmt werden.
+
+'Wirkungsminderung' ist hierbei im Sinne von *deutlich* gemeint.
+
+*** NEU - NEU - NEU - NEU - NEU - NEU - NEU - NEU - NEU - NEU - NEU - NEU ***
+
+ Tragbare Heilungen, die im weitesten Sinne aus Lebensmitteln bestehen,
+ duerfen nicht mehr instant sein, sondern MUESSEN "buffer_hp/sp" verwenden!
+
+*** NEU - NEU - NEU - NEU - NEU - NEU - NEU - NEU - NEU - NEU - NEU - NEU ***
+
+Bei tragbaren Heilungsmoeglichkeiten, die weder aus Essbarem, noch aus Trink-
+barem besteht (bei denen es also nicht logisch waere, "buffer_hp/sp" zu
+benutzen), MUSS "check_and_update_timed_key" verwendet werden, da sie sonst zu
+kritisch werden. Dann darf es natuerlich auch sowas geben. Beispielsweise kann
+man solche Objekte gut als (Mini-)Questbelohnung integrieren.
+
+Hier gilt: Je hoeher die Heilung, um so hoeher die Zeitdauer, nach der der
+Spieler diese Moeglichkeit wieder in Anspruch nehmen darf.
+(Richtwerte: heal_self(50): ~ 1800 sec., heal_self(150): ~ 3600 sec.)
+
+Auch bei diesen Objekten ist es ein MUSS, die Heilungsmoeglichkeiten einmal
+erschoepfen zu lassen, sie also entweder 'verderben' oder sich verabschieden
+(-> Dschinn) zu lassen oder sie 'stillegen', da sie dann einfach eine zeitlang
+Ruhe brauchen, um sich neu 'aufzuladen'.
+
+Questbelohnungen:
+----------------
+Diese Objekte stellen eine Ausnahme unter den tragbaren Heilungen dar. Hier
+kann auf "buffer_hp/sp" verzichtet werden; dafuer muessen aber andere Regeln
+beachtet werden: das Objekt darf pro Reset nur begrenzt heilen bzw. nach der
+Anwendung sich selber zerstoeren (-> gelber Stein). Oder es muss vorher eine
+erhebliche Menge LP/KP investiert werden, um das Objekt zu nutzen
+(-> Infernoblock).
+
+Enttanken:
+---------
+Die Moeglichkeit zur Enttankung MUSS an einen festen Ort gebunden sein. Sie
+darf also nicht durch tragbare Objekte hervorgerufen werden koennen. Ein
+Beispiel hierfuer sind die Toiletten von Wurzel in Wilhelmsburg oder die
+Fleischreste in der SSP. Weiteres hierzu siehe -> "man enttanken".
+
+ Logisches:
+ *********
+
+Jede (!) Moeglichkeit zur Heilung, abgesehen von regulaeren Kneipen, muss dem
+zustaendigen Magier fuer Heilungs-Balance gemeldet und von diesem genehmigt
+werden. Wer diesen Posten momentan innehat, kann dem MailAlias
+"heilungs_balance" entnommen werden.
+
+Siehe auch:
+----------
+ Tanken: consume, drink_alcohol, eat_food, drink_soft
+ Heilung: heal_self, restore_spell_points, restore_hit_points,
+ buffer_hp, buffer_sp
+ Timing: check_and_update_timed_key
+ Enttanken: defuel_drink, defuel_food
+ Props: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
+ P_DEFUEL_TIME_DRINK
+ Konzepte: enttanken, food
+
+----------------------------------------------------------------------------
+17.09.2010, Zesstra
diff --git a/doc/wiz/kampfobjekte b/doc/wiz/kampfobjekte
new file mode 100644
index 0000000..39d6e28
--- /dev/null
+++ b/doc/wiz/kampfobjekte
@@ -0,0 +1,60 @@
+ SONSTIGE KAMPFOBJEKTE:
+
+ Hierzu zaehlen alle Sachen, die irgendeinen Einfluss auf den Kampf nehmen
+ und weder `/std/weapon.c' noch `/std/armour.c' sind. Also die sogenannte
+ Artillerie, Eisstab und artverwandtes, Wurfsterne, Parasteine, Bumis...
+ sowie saemtliche tragbaren Heilmoeglichkeiten und unterstuetzende NPC.
+
+ Prinzipiell sind alle diese Sachen genehmigungspflichtig.
+ Auto-Selbstfahrer, also Sachen, die ohne Eingriff des Spielers agieren,
+ sind unerwuenscht und sollten vermieden werden. Sorry fuer die
+ Laggeplagten...
+
+ Kampfobjekte sollten P_ATTACK_BUSY setzen und auch vor der Anwendung
+ abfragen, damit sie nicht unbegrenzt hintereinander genutzt werden
+ koennen. Magische Sachen sollten entweder aufgeladen werden muessen oder
+ ihre magische Energie verlieren, damit sie nicht unendlich haltbar sind.
+ Ausserdem hat Magie normalerweise auch unerwuenschte Nebenwirkungen. Die
+ Spieler sollen die moeglichen Vorteile gegen Nachteile oder Nebenwirkungen
+ des Gegenstands abwaegen. Auch bei diesen Objekten *muss* P_INFO gesetzt
+ werden, um eine Begruendung fuer die besondere Wirkung und z.B. einen
+ Hinweis auf die Benutzung zu liefern.
+ Sie sollten keinesfalls kaeuflich erworben werden koennen.
+
+ Tragbare Heilstellen sollten aeusserst spaerlich verwendet werden. Handelt
+ es sich um irgendeine Form von Fressalien (Brot, Pfirsich,
+ Schnellhaerter...) so muss P_FOOD oder P_DRINK und evtl. P_ALCOHOL gesetzt
+ werden. Ansonsten sollten solche Dinge wenigstens irgendwelche
+ Auswirkungen auf den Spieler haben ausser der Heilung. Ein sogenanntes
+ "Restrisiko" waere nicht verkehrt...
+
+ Sie sollten niemals unbegrenzt erworben werden koennen, schon gar nicht
+ kaeuflich! Ausserdem ist eine gewisse Verfallszeit sehr sinnvoll und
+ erhoeht die Chancen auf Genehmigung. Richtwerte: erhoehtes Risiko nach 1.
+ Reset, unbrauchbar nach 2-3 Resets.
+
+ Objekte, die Auskunft ueber ein- und/oder ausgehende Schaeden geben,
+ sind genehmigungspflichtig. Solche Objekte sollten nach Moeglichkeit
+ eine Waffe oder Kleidungsstueck - dies jedoch nicht AT_MISC - sein.
+ Dass solche Objekte auch ueber Luecken in der Angabe der Schaeden und
+ Nachteile verfuegen sollten, ist eigentlich klar.
+ Solche Nachteile liessen sich ueber eine Mindest-Schadenshoehe oder
+ random realisieren. Informationen ueber mehrere Schadenstypen durch
+ ein und das selbe Objekt sind nicht erwuenscht.
+
+ Ebenfalls genehmigungspflichtig sind alle Objekte, die in irgend einer
+ Weise Einfluss auf spezifische Gildenfaehigkeiten oder Besonderheiten
+ nehmen. Hierzu sollte neben der Balance auch noch der Gildenmagier
+ befragt werden.
+
+ Hinsichtlich Komponenten der Zauberer ist der Gildenchef der
+ Ansprechpartner.
+
+ SIEHE AUCH
+
+ balance, ruestungen, waffen, fernwaffen, uniques, npcs, objects,
+ attributsveraenderungen, resistenzen, grenzwerte, artillerie
+
+------------------------------------------------------------------------------
+ LETZTE AeNDERUNG:
+ So, 26.01.2003, 18:50:00 von Humni
diff --git a/doc/wiz/katzenkrieger.testspieler b/doc/wiz/katzenkrieger.testspieler
new file mode 100644
index 0000000..33c2ac9
--- /dev/null
+++ b/doc/wiz/katzenkrieger.testspieler
@@ -0,0 +1,37 @@
+Magier-Manpage
+
+Gildentestie "Katzenkrieger".
+
+
+Es gibt in der Katzenkriegergilde eine Funktion, mit der man einen
+Testspieler erschaffen kann, welcher der Katzenkriegergilde angehoert.
+Die Funktion heisst "make_testplayer" und erwartet als einzigen Parameter
+ein Spieler-Objekt.
+
+
+
+Die Funktion verhaelt sich wie folgt.
+
+Der Spieler muss ein Testspieler sein.
+Der Spieler sollte in die Gilde eintreten koennen.
+Der Spieler lernt alle Spells und Skills der Gilde, die er auf seinem
+derzeitigen Spielerlevel lernen kann.
+Die Spells haben je den hoechstmoeglichen Skillwert, den der Spieler auf
+seinem Level erreichen kann, es sei denn, er kannte den Spell zuvor schon.
+Dann bleibt der Spell unveraendert.
+
+
+
+Um einen Testspieler zu erschaffen, geht man wie folgt vor.
+
+Man nehme einen (eigenen!) Testspieler, z.B. "bambs".
+Man setze ihm das gewuenschte Spielerlevel, z.B. 11
+ xcall bambs->SetProp(P_LEVEL, 11);
+Man gehe in den Gildenraum der Katzenkrieger.
+ goto /gilden/katzenkrieger
+Man rufe die Funktion auf, die einen Katzenkrieger aus dem Testspieler macht.
+ xcall $h->make_testplayer(find_player("bambs"));
+Der Testspieler sollte nun Katzenkrieger sein.
+
+******************************************************************************
+Letzte Aenderung: Tue Jan 7 23:03:16 2003 durch Bambi
\ No newline at end of file
diff --git a/doc/wiz/knete b/doc/wiz/knete
new file mode 100644
index 0000000..e4d1f3e
--- /dev/null
+++ b/doc/wiz/knete
@@ -0,0 +1,81 @@
+NAME:
+ *** KNETE ***
+
+BESCHREIBUNG:
+ Die Knete ist ein in LPC geschriebener Lisp-Interpreter. Dieser hat
+ die besondere Eigenschaft, die Lisp-Quellen direkt in den vom
+ Amylaar GameDriver angebotenen closures zu uebersetzen. Dadurch ist
+ mit der Knete alles das moeglich, was auch mit LPC moeglich ist.
+ Es ist ein generisches, frei programmierbares Hilfsmittel.
+
+ Die Knete befindet sich unter: "/obj/tools/lisp"
+
+FUNKTIONSBESCHREIBUNG:
+ Die Knete kann im Prinzip fast alles, was ein einfacher Lisp-
+ Interpreter kann. Ausnahmen sind Tupel (Bsp: (1 . 2)), welche nicht
+ implementiert sind. Die Grundlegenden Funktionen, wie define, setq,
+ cons, cdr, car etc werden beim Laden der Knete angezeigt. Je nach
+ Zeit, werden eventuelle auch weitere Standardfunktionen hinzu-
+ kommen, um die Knete moeglichst common-lisp kompatibel zu machen.
+
+BENUTZUNG:
+ Zu allererst sollte man wissen, dass dies hier keine Einfuehrung in
+ Lisp ist oder sein soll! Die wichtigsten Merkmal der Knete werden
+ aufgefuehrt an einigen kleinen Beispielen. Wer Lisp kennenlernen
+ moechte kann dies mit den handelsueblichen Buechern tun.
+
+ Wer dennoch basteln moechte: Lisp ist eine Sprache in Prefixnotation,
+ d.h. der Funktionsname steht immer als erstes und dann kommen die
+ Argumente. Ein Ausdruck ist mit den ihn umgebenden Klammern komplett.
+ Beispiel: (+ 1 1) ;;; errechnet die Summe aus 1 und 1
+ Solche Klammerausdruecke koennen beliebig geschachtelt werden.
+ Beispiel: (+ 1 (+ (+ 1 1) 1))
+
+ Es stehen alle efuns, sowie einige lfuns zur Verfuegung! Zu den efuns
+ gehoeren auch +,-,*,/,%,!,[,[<,[<.. etc, also alle Operatoren von LPC.
+
+ Die Knete hat zwei Modi:
+ a) Laden von Lisp aus einer Datei
+ b) Verarbeiten von Eingaben aus der Kommandozeile
+
+ Zu a)
+ Mit der Funktion "load" koennen Dateien eingelesen und interpretiert
+ werden. Die Funktion hat nur ein Argument, und das ist der Dateiname.
+
+ Beispiel: (load "/players/hate/lisp.l")
+
+ Zu b)
+ Wenn die Knete gecloned wurde, koennen jederzeit Lispausdruecke
+ eingegeben werden, welche dann interpretiert werden. Dabei sollte
+ beachtet werden, dass die aeusserste Klammer nicht notwendig ist!
+
+ Beispiel: (+ 1 (+ 1 1)) koennte man auch schreiben als:
+ + 1 (+ 1 1)
+
+ Dies ist vor allem dann interessant, wenn man die Moeglichkeiten
+ der Knete als alias-Werkzeug in betracht zieht. Somit ist es
+ moeglich, eine Funktion zu schreiben und diese dann wie ein alias
+ zu benutzen.
+
+ Beispiel: (defun who () (users)) ;;; gibt das users array aus
+ Jetzt muss nur noch who eingegeben werden und das
+ array wird ausgegeben.
+
+ Da Lisp wesentlich komplexere Ausdruecke ermoeglicht, als der
+ normale alias-Interpreter, liegen die Vorteile auf der Hand.
+
+KONFIGURATION:
+ Die Knete laesst sich fuer jeden Nutzer konfigurieren, indem sie eine
+ Datei "/players/<name>/lisp.l" aus dessen Heimatverzeichnis laedt.
+
+ Ein Beispiel, was man damit machen kann befindet sich unter:
+ "/players/hate/lisp.l"
+ Die MUD Spezifischen Teile und Abfragen koennen ignoeriert werden.
+
+BUGS:
+ Es gibt momentan noch ein Problem, wenn auf der Kommandozeile
+ Klammern fehlen. Dann kommt eine Meldung: "*Missing 2 )"
+ In diesem Fall einfach zweimal hintereinander ) auf jeweils einer
+ einzelnen Zeile eingeben! Dieses Problem tritt vor allem dann auf,
+ wenn man zum Beispiel ein :( eingibt.
+
diff --git a/doc/wiz/laden b/doc/wiz/laden
new file mode 100644
index 0000000..2de2ea3
--- /dev/null
+++ b/doc/wiz/laden
@@ -0,0 +1,15 @@
+LAEDEN IM MORGENGRAUEM
+----------------------
+
+Laeden im MorgenGrauen sollten grundsaetzlich /std/shop erben.
+
+Des Weiteren benoetigt man einen StorageRoom, also einen Raum, in dem der
+Laden seine Gegenstaende verwaltet. Dieser wird mit "SetStorageRoom"
+gesetzt. Die Hilfeseite zu diesem Befehl hat auch ein Beispiel.
+
+Objekte, die der Laden immer verkaufen soll, kann man mit "AddFixedObject"
+setzen.
+
+Siehe auch: SetStorageRoom, AddFixedObject, QuerySellValue
+
+Letzte Aenderung: Humni, 2015-06-17
diff --git a/doc/wiz/leitfaden b/doc/wiz/leitfaden
new file mode 100644
index 0000000..7d806c1
--- /dev/null
+++ b/doc/wiz/leitfaden
@@ -0,0 +1,487 @@
+
+
+ACHTUNG: DIESER LEITFADEN IST FURCHTBAR VERALTET! :-(
+
+
+DER LEITFADEN 'WIE SCHLIESSE ICH ERFOLGREICH MEIN GEBIET AN'.
+(in sieben Schritten zum Erfolg, von Tsunami und Feuerwehr)
+-------------------------------------------------------------
+
+Dieser Leitfaden ist absolut unverbindlich und kein Reglement. Die
+Reihenfolge muss nicht eingehalten werden, und auch die Anmerkungen
+zu den einzelnen Punkten sind nicht zwingend zu befolgen.
+
+Fuer Schnellleser:
+
+1) Raeume/Objekte/NPCs proggen
+2) Alles Testen und Mail an die Regionsmagier (RM) schicken.
+3) RMs pruefen Code und weisen auf moegliche Probleme hin.
+4) Antrag Balance verfassen ('goto /players/paracelsus/office').
+5) Forscherpunkte beantragen (hilfe erzmagier).
+6) Mail an RMs, dass nun alles i.O. ist.
+7) RMs schliessen Gebiet an.
+
+Nun etwas ausfuehrlicher.
+
+-------------------------------------------------------------
+P H A S E 1
+-------------------------------------------------------------
+Du bist nun also Magier, voller Ideen und Tatendrang. Bevor Du wild drauflos
+programmierst, ein paar Tips, um Dir und den zustaendigen RMs das Leben zu
+erleichtern:
+
+Fertige Dir eine ASCII-Karte an, und schreibe einen kurzen Text, der Dein
+neues Gebiet beschreibt. Frage schon mal Deinen RM, wo ungefaehr dieses
+neue Gebiet angeschlossen werden koennte. So kannst Du Dir ein paar Gedanken
+machen, wie die Anschlussraeume ausschauen koennten.
+
+Erstelle sinnvolle Unterverzeichnise: es hat sich folgendes bewaehrt:
+Ein Hauptverzeichnis mit dem Namen des Gebietes (kurz, wenns geht). Dort
+kommen dann die Unterverzeichnise rein: z.B. '+/doc +/mon +/obj +/rooms'.
+In das '+/doc' kommen dann Deine Karten und Texte. Falls Du mit
+'NotifyPlayerDeath()' Deine Kerben loggen willst, oder andere wichtige
+Sachen loggen moechtest, dann schreibe diese Files in das '/log/<deinname>/'
+Verzeichnis.
+In das '+/mon' Verzeichnis kommen alle NPCs usw.
+
+Wenn Du ein Textfile aufrufen willst, dass den Inhalt der Unterverzeichnise
+beschreibt, so lege einfach eine '.readme' Datei im entsprechenden
+Verzeichnis an. Dieses File wird bei jedem 'cd' aufgerufen.
+
+Bevor Du jetzt losschlaegst, ueberlege Dir ein Define-File, worin Du die
+ganzen Pfade definierst. Denn wenn Du zuerst alles in Deinem Player-
+Verzeichnis proggst, und vor Anschluss wird das Gebiet in das Regions-
+verzeichnis gemoved, will niemand die ganzen Pfadnamen abaendern.
+Ein Beispiel: in Dein 'gebiet.h' (gib ihm einen praktischen Namen der zu
+Deinem Gebiet passt: eismine.h, hoehle.h oder keller.h usw) kaeme sowas
+in der Art:
+
+#define EISMINE(x) ("/d/polar/tsunami/eismine/"+x)
+#define ROOM(x) (EISMINE("rooms/"+x))
+#define MON(x) (EISMINE("mon/"+x))
+#define OBJ(x) (EISMINE("obj/"+x))
+
+Dein Raum included dann das File: #include "../gebiet.h"
+Dein Ausgang in einen anderen Raum machst Du dann folgendermassen:
+AddExit("norden", ROOM("raum02"));
+
+Ein NPC wuerde somit folgendermassen in den Raum gestellt:
+AddItem(MON("eiself"), REFRESH_DESTRUCT);
+
+Wenn spaeter aus irgend einem Grund Dein Gebiet verschoben werden muss, dann
+kann der RM einfach die erste Zeile in 'gebiet.h' abaendern. Das spart Zeit
+und Nerven.
+
+Weiter bietet das Define-File die Moeglichkeit, laengere Befehle zu
+verkuerzen. Ein Beispiel: Du moechtest Namen des Spielers (gross geschrieben)
+ausgeben. Der Befehl dazu waere: this_player()->Name(WER)
+Das ist ziemlich lang. Definiere in Deinem Define-File doch einfach:
+#define TPN this_player()->Name(WER)
+und schon wird Dein Code etwas uebersichtlicher. Die Anwendung waere z.B.
+say(TPN+" popelt in der Nase.\n");
+
+Wenn Du automatische Zeilenumbrueche moechtest, dann schreibe folgendes
+in Dein Define File:
+#define BS(x) break_string(x, 78 , "", BS_LEAVE_MY_LFS)
+BS_LEAVE_MY_LFS bewirkt, dass Du immer noch selbst Zeilenumbrueche einbauen
+kannst mit \n. Und so wird BS dann benutzt:
+AddDetail( ({"wand","waende"}),BS(
+ "Die Waende bestehen wie alles hier aus purem Saphir. In die noerdliche "+
+ "Wand wurde ein schrecklich gezacktes und scharfkantiges Loch gesprengt."));
+
+Um dies zu benutzen musst Du allerdings noch #include <break_string.h> in das
+Headerfile setzen (vor die #define BS(x)...)-Zeile), sonst kennt der
+Precompiler den Ausdruck BS_LEAVE_MY_LFS nicht.
+
+Du wirst Dein Gebiet evtl. in Deinem Home-Verzeichnis (/players/...)
+schreiben, da Du noch nicht den Sprung zu Level 21 geschafft hast. Du
+solltest aber wissen, dass Deine RegionsmagierInnen nur Gebiete annehmen
+werden, welche im Regionsverzeichnis /d/.../dein_name/ gespeichert sind. Das
+ist wichtig, denn in Deinem Heim-Verzeichnis koennen sie nicht schreiben und
+so keine Fehler korrigieren. Denke daran! Benutze unbedingt die Defines,
+denn vor dem Anschluss wirst Du das Gebiet in das Regionsverzeichnis
+schieben muessen.
+
+Viele Spieler 'loggen', also speichern gerne Tode oder Aktionen von Spielern
+in ihren Heim-Verzeichnissen. Dieses Schreiben funktioniert nicht von
+Regionsverzeichnissen in Heim-Verzeichnisse. Benutze auch hier ein define!
+
+Nun kommen wir zum proggen. Falls Du noch nie programmiert hast, ist es
+sinnvoll, sich Beispielfiles anzuschauen. Wuehl Dich durch das '/doc'
+Verzeichnis oder noch besser: frag Deinen Papimagier/Deine Mamimagierin oder
+den RM, ob er Dir ein paar seiner Files zuschickt. Hast Du diese Huerde
+ueberwunden, kann es losgehen. Wenn Du anfaengst zu proggen und nicht weisst,
+wie man einen bestimmten Befehl benutzt, kannst Du die 'man page' konsultieren
+(das Manual = Online Hilfe). Tipp einfach 'man <befehl>' und schon kommt die
+entsprechende Hilfeseite, falls vorhanden.
+
+Ein paar Worte zu den Raeumen: Details sind hier sehr wichtig.
+Mach viele Details und beschreibe sie nett. 'unt boden' -> 'Der ist unter Dir.'
+ist nicht sehr interessant. Ein Raum mit weniger als 20 Details wird
+mittlerweile als ungenuegend angesehen, auch wenn es noch ein paar Gebiete
+im MG gibt, wo die Raeume fast keine Details haben (diese Zahl schwankt
+natuerlich von Region zu Region -- trotzdem: je mehr Details, desto besser).
+AddSmells und AddSounds solltest Du ebenfalls nicht vergessen. Der Spieler
+von Welt will auch riechen und hoeren koennen. Wenn Du einen Raum erstellst,
+ueberlege Dir auch witzige und/oder sinnvolle Befehle, die man in dem Raum
+ausfuehren kann. Bei laengeren Prozeduren ist es fuer den RM hilfreich, wenn
+Du im jeweiligen Raum einen kurzen Kommentar absetzt.
+
+Schau, dass Du ein atmosphaerisch schoenes Gebiet programmierst. Schau,
+dass es sich mit seiner Umgebung vertraegt. Bevor Du ein abgestuerztes
+Raumschiff von der Vega programmierst, frage lieber Deinen RM, denn
+wahrscheinlich passt es thematisch nicht in seine Region (welche Region auch
+immer es ist :-)).
+
+Achte darauf, dass die Toedlichkeit Deines Gebiets sich mit Deiner Umgebung
+vertraegt. Ueber-Schwere-Mega-Monster sollten von kleinen Spielern nicht
+problemlos erreicht werden koennen. Benutze nicht ganz so toedliche
+'Block-Monster', welche den Zugang versperren. So muss ein Spieler erst
+seine Wuerdigkeit beweisen, bevor er an die harten Monster kommt. Tigonen im
+Glockenwald sind KEINE gute Idee.
+
+Viele Magier finden es lustig, Spieler in ihren Gebieten durch Fallen
+sterben zu lassen. Das sind z.B. Knoepfe, die man drueckt, und die dann sofort
+this_player()->die() aufrufen. Nachdem vor einiger Zeit die Todesfolgen
+verschaerft wurden, sind derartige Fallen nicht mehr gern gesehen. Vermeide
+sie wenn moeglich. Spieler machen jeden Muell, aber lass sie nicht dafuer
+sterben, wenn Du es anders regeln kannst. Jede Todesfalle ist dem RM
+aufzuzueigen.
+
+Die Objekte: dazu gehoeren auch Waffen und Ruestungen, sowie alle anderen
+schraengen Dinge, die Dir noch so einfallen werden. Bevor Du Dir Deine
+erste Mega-Super-Alles-Kaputtschlag-Axt oder den Alle-Schaeden-Abwehr-Panzer
+zusammenbastelst, setz Dich hin, atme ruhig durch und tipp dann 'man balance'.
+Dort stehen alle wichtigen Eckdaten, die Du befolgen solltest. Und denk daran,
+nicht zuviele exklusiven Waffen und/oder Ruestungen in einem einigen Gebiet.
+Wenn Du grosse Objekte schreibst, ist hier auch wieder ein kleiner Kommentar
+im File sehr hilfreich fuer den RM. Denk daran, Du bist vielleicht irgendwann
+einmal nicht mehr erreichbar und dann ist es gut, wenn im File geschrieben
+steht, was das Programm ungefaehr macht.
+
+Jetzt kommen wir zu ein paar haeufigen Problemen:
+Erzeugst Du ein Objekt, das in einen Spieler geschoben wird, musst Du
+unbedingt den Return-Wert abfragen, ob der Spieler das noch tragen kann:
+Ein Beispiel: Eine eigene Funktion 'nehmen'.
+In das create() vom Raum kommt:
+AddCmd(({"nimm","nehm","nehme"}),"nehmen");
+
+Die Funktion 'nehmen' erzeugt eine Zigarre. Sie prueft, ob einen Zigarre
+schon im Raum liegt, dann nimmt der Spieler diese. Falls keine Zigarre
+rumliegt, wird eine neue erzeugt und in den Spieler geschoben.
+Damit ein Spieler nicht hunderte Zigarren erzeugen kann, wurde eine
+globale Variable 'int zaehler; zaehler=5; oben im create() vom Raum erstellt.
+Nach einem Raumreset steht der Zaehler wieder auf 5, wenn man das in der
+reset() Funktion (siehe unten) definiert.
+
+nehmen(string str)
+{
+ object ob;
+
+ notify_fail("Was moechtest Du nehmen?\n");
+ if(!str) return 0;
+ if(str=="zigarre") {
+ if(present("zigarre",this_object())) return 0;
+ // so wird die Zigarre IM Raum genommen
+
+ if (zaehler) {
+ write(BS("Du nimmst eine Zigarre aus dem Fach."));
+ say(TPN+" nimmt eine Zigarre aus einem Fach.\n",this_player());
+ // TPN: siehe oben, Abschnitt 'Defines'
+ ob=clone_object(OBJ("zigarre"));
+ if (ob->move(this_player(),M_GET) !=1) {
+ // dieses '!=1' faengt ME_TOO_HEAVY, ME_TOO_MANY_OBJECTS,
+ // und ME_CANT_BE_INSERTED ab
+
+ write("Du kannst die Zigarre nicht mehr tragen. Sie faellt zu "+
+ "Boden.\n");
+ ob->move(environment(TP),M_PUT);
+ }
+ zaehler--;
+ return 1;
+ }
+ write(BS("So ein Pech. Jemand hat die besten Stuecke bereits genommen."));
+ return 1;
+ }
+ // und damit man auch andere Sachen als Zigarren im Raum nehmen kann:
+ return 0;
+
+}
+
+reset()
+{
+ ::reset();
+ // nach 30-45 min kann man wieder 5 neue Zigarren nehmen
+ zaehler=5;
+}
+
+Die NPCs. Es gibt (noch) keine Vorschrift, wie stark maximal NPCs sein duerfen,
+aber schau Dir trotzdem 'man balance' zu diesem Thema an.
+NPCs werden oft schmerzlich von ihren Magiern vernachlaessigt. Oft
+steht der grosse Drache auf dem Speicher, kann Dich in einem Schlag umhaun,
+weiss aber nicht einmal seinen Namen und besitzt nicht ein Detail. Kuemmer
+Dich um Deine NPCs. Gib ihnen eine schoene Beschreibung, lass sie etwas
+ueber sich erzaehlen, gib ihnen Details, gib ihnen Kleidung.
+
+Oft will man NPCs durch Gebiete laufen lassen, so dass sie mal Land und
+Leute kennenlernen. Das ist etwas rechnerlastig, und auch wenn wir jetzt
+jede Menge Power unter der Haube haben, sollte man einige Dinge beachten:
+* Es gibt einige sehr schoene Standard-Lauf-NPCs. Es bietet sich an, diese
+ zu benutzen. Sie haben alle noetigen Eigenschaften, unter anderem, dass sie
+ stehen bleiben, wenn sie keine Spieler mehr antreffen. Das spart
+ Performance. Ausserdem werden sie oft von einem Master gesteuert, und das
+ spart call_outs.
+* Aufwendig ist besonders das Bewegen von NPCs. Rennende NPCs sind doch
+ oede. Lass sie sich langsam bewegen. Jedes schoene Gespraech mit einem NPC
+ geht in die Hose, wenn der NPC staendig vor einem weglaeuft.
+
+Denke generell daran, uebersichtlich zu programmieren. Benutze nicht
+mehr als 78 Zeichen pro Zeile, fuege ruhig Leerzeilen ein, um die Struktur
+zu unterstreichen. Ruecke in Schleifen den Code ein paar (z.B. 3) Zeichen
+ein. Kommentare machen Deinen RM gluecklich! Wenn Du einst vielleicht nicht
+mehr da bist, wird irgend jemand Deinen Code warten muessen. Denk an den
+armen Kerl! Fuege bei Deinen Objekten einen Hinweis darauf ein, wovon und
+wofuer sie benutzt werden! Wenn Du die Wahl hast, Code in einer
+fuerchterlich effizienten, aber unuebersichtlichen Weise zu schreiben, oder
+etwas weniger effizient, aber intuitiv und einleuchtend, nimm die
+einleuchtende Weise.
+
+Zaubertraenke, Gildenobjekte, Gildenquests
+
+Zaubertraenke
+
+Zaubertraenke sind wichtig, und obwohl es sie schon an vielen Stellen im MG
+gibt, sind sie immer noch gefragt. Man sollte beim Einbauen von ZTs daran
+denken, sie nicht tief in Quest-Gebieten zu verstecken, so dass ein Spieler
+keine Quest nochmal spielen muss, nur um den ZT zu bekommen. Ausserdem
+sollten sie nicht zu schwer versteckt werden. Ein Zaubertrank in einem Buch
+bekommt man z.B. durch:
+
+create() {
+...
+AddReadDetail("buch","@@det_buch@@");
+}
+
+string det_buch()
+{
+ if (this_player()->FindPotion("Du findest Macht in diesem Buch...\n"))
+ return "";
+ else
+ return "Du findest keine Macht in diesem Buch. Wie schade...\n";
+}
+
+Denke daran, auch einen Vers zu schreiben, welcher im Orakel den Tip fuer
+diesen ZT darstellt. Du kennst diese Verse sicher schon zur Genuege :-).
+Du musst den Zaubertrank spaeter zusammen mit den Forscherpunkten anmelden.
+
+Gilden- und Miniquests.
+
+Gildenquests sind kleine Aufgaben, nicht gross genug fuer richtige Quests,
+welche von den Mitgliedern einer Gilde geloest werden muessen, bevor sie
+aufsteigen koennen. Die Dinger sind voll im Kommen. Zauberer-, Kaempfer-
+oder Chaos-Gildenmagier sind immer hinter denen her. Quests wie 'Finde das
+verschollene Buch' oder 'Befreie den Verurteilten' lassen sich oft ohne
+grossen Aufwand in Gebiete einbauen. Sie garantieren auch eine gewisse
+permanente Besucherzahl im Gebiet :-)). Bevor man diese Quests einbaut,
+sollte man das prinzipielle OK der Gildenmagier holen, nachher muss man
+ihnen die Quest vorstellen, damit sie sie bewerten und freigeben.
+
+Will man eine kleine Aufgabe nicht gildenabhaengig, sondern fuer alle
+Spieler einbauen und dafuer Stufenpunkte vergeben, dann kann man die Aufgabe
+auch als Miniquest eintragen lassen, und zwar beim gleichen EM, der auch die
+FPs eintraegt. Es folgen Code-Beispiele fuer die Vergabe der Quests...
+
+int befreie(string wen)
+{
+ notify_fail("Wen moechtest Du befreien?\n");
+ if (wer != "gefangener")
+ return 0;
+
+ // Hier werden die Stufenpunkte fuer die Miniquest vergeben...
+ // Falls man keine Miniquest angemeldet hat, laesst man das natuerlich weg
+ SCOREMASTER->GiveMiniQuest(this_player());
+
+ // Hier sind die Kaempfer. Der Code kann variieren...
+ call_other("/p/kaempfer/std/k_master","SetzeAufgabe",getuid(this_player()),
+ "Befreie den Gefangenen");
+
+ // Letztes Beispiel: Hier sind die Zauberer:
+ call_other("/p/zauberer/npc/test","GiveQuest",this_player(),
+ "Befreie den Gefangenen");
+ ...
+}
+
+Gildenobjekte
+
+Gildenobjekte wirken noch besser als Gildenquesten, um Spieler in Gebiete zu
+locken :-). Dies sollte jedoch kein Anlass sein, ein Gebiet mit derartigen
+Dingen zu ueberladen aber dafuer die Details und die Atmosphaere zu
+vergessen. Ganz generell gilt: Maessige Dich! Weniger ist mehr!
+
+Ganz generell sind Gildenobjekte z.B. Utensilien der Zauberer, Waffen mit
+Kaempfer-Boni fuer Kaempfer oder Kreiden etc. fuer Chaoten. Diese Objekte
+muessen natuerlich von den Gildenmagiern genehmigt werden, bevor das Gebiet
+angeschlossen wird. Sprecht frueh genug mit den Gildenmagiern. Sie werden
+euch sicher genug Beispiele fuer derartige Objekte geben, weshalb hier auf
+derartiges verzichtet wird.
+
+-------------------------------------------------------------
+P H A S E 2
+-------------------------------------------------------------
+Du hast nun alle Raeume/Objekte/NPCs erstellt. Nun geht es in die Testphase.
+Erzeuge Dir einen Testspieler, damit Du Deine Raummeldungen wie z.B. mittels
+tell_room() auf ihre Richtigkeit ueberpruefen kannst. Schau Dir in Ruhe
+Deine Sachen an und versuche, die unsinnigsten Sachen darin zu tun. Das werden
+die Spieler naemlich nachher auch machen. Ist Deiner Meinung nach alles OK,
+schreib eine Email an Deine zustaendigen RMs. Sehr hilfreich (fuer die RMs)
+waere eine zusaetzliche Liste (siehe auch Phase 4) mit:
+
+1) allen NPCs (welche Objekte tragen sie) und allfaellige Sonderfunktionen
+ ganz kurz erlaeutert.
+2) Eine Liste aller Objekte. Bei komplizierten Objekten eine kurze Beschreibung
+3) Eine Liste, in welchem Raum liegt welches Objekt/ZT/Heilstelle/NPC
+
+Diese Liste kannst Du natuerlich in Dein /doc Verzeichnis legen, was dann auch
+spaeter sehr hilfreich sein kann.
+
+Falls sich Deine RMs nicht melden, sprich sie an, mail ihnen nochmal.
+Vielleicht haben sie Deine Mail vergessen. RMs sind prinzipiell vergesslich.
+Sie unterhalten sich jedoch sicherlich gern mit Dir. Keine falsche
+Bescheidenheit, ran an den Feind.
+
+- Testspieler - oder - Zwischen Legalitaet und Wahnsinn -
+
+Kaum ein Magier kann die merkwuerdigen, oft widersinnigen und kranken
+Gedankengaenge eines Spielers nachvollziehen. Deshalb ist es eine gute
+Sache, sein Gebiet von Spielern testen zu lassen. Sie koennen die Staerke
+der NPCs gut einschaetzen und korrigieren, kennen die geheimen Kniffe der
+Gilden und machen generell das, woran man nie gedacht hat.
+
+Spielertesties sind so eine Sache. Als erstes muss man kompetente Spieler
+finden, welche bereit sind, das Gebiet zu testen. Dies ist nicht einfach,
+denn die wirklich guten Tester sind oft hoffnungslos ueberbelegt. Hat man
+einen willigen Spieler gefunden, kreiert man sich einen Testspieler, indem
+man einen neuen Spieler einloggt und im P_TESTPLAYER auf den eigenen Namen
+setzt. Das kannst Du z.B. so machen:
+xcall testi->SetProp(P_TESTPLAYER,"<Magier>") wobei <Magier> Dein Name ist.
+
+Danach darf man ihn wild in Gilden eintreten lassen, ihm seine
+Werte setzen und ihm Ausruestung clonen. Es gibt einige schoene
+Testspieler-Tools, mit denen sich Testies Ruestungen setzen und sich heilen
+koennen.
+
+Hat man Spieler und Testspieler, so kommt man an die legalen Probleme. Alles
+wichtige erfaehrt man durch 'hilfe testspieler'. Dort steht, dass
+Testspieler bei Erzmagiern angemeldet werden muessen, welche sie dann in ein
+Ueberwachungstool eintragen, so dass seine Handlungen geloggt werden.
+Tatsache ist, dass sich aber kaum einer seine Testspieler bei einem
+Erzmagier anmeldet und die meisten EMs das selbst nicht tun. (Testies neuer
+Gilden moegen hier eine Ausnahme bilden).
+
+Generell beachte folgendes: Mach keine Spieler zu Testspielern, denen Du nicht
+traust oder die Du nicht kennst. Wenn ein Spieler mit seinen Tools durchs MG
+laeuft und Unsinn anstellt, bist Du mit Schuld, egal ob der Testie
+angemeldet ist oder nicht. Wenn Du einen Spieler durch ein Gebiet laufen
+laesst, bevor die FPs eingetragen wurden, dann ist das nicht legal, aber es
+wird keiner meckern, wenn Du ihn ueberwachst und somit aufpasst, dass er
+keinen Unsinn ausserhalb des Gebiets anstellt. Wenn Du einen Spieler durch
+ein Gebiet mit FPs laufen laesst und der Spieler die von ihm gefundenen FPs
+bekommen will, so musst Du ihn bei einem Erzmagier anmelden, denn FPs kann
+nur ein Erzmagier setzen.
+
+Oh, und schreibe Dir die Namen und Passwoerter Deiner Testspieler auf. Falls
+man mehrere hat, vergisst man verflucht schnell die Namen :-).
+
+-------------------------------------------------------------
+P H A S E 3
+-------------------------------------------------------------
+Die RMs schauen alle Files an, die Du erzeugt hast. Danach werden sie Dir
+eine Liste zurueckschicken mit allen Problemfaellen, die sie gefunden haben.
+Je nach Umfang Deines Gebietes kann das natuerlich etwas dauern.
+Hast Du die Informationen zurueckbekommen, kannst Du Dich an den Feinschliff
+machen. In der Zwischenzeit solltest Du Phase 4 und Phase 5 erledigen.
+
+-------------------------------------------------------------
+P H A S E 4
+-------------------------------------------------------------
+Falls Du Objekte hast, die genehmigungspflichtig sind (man balance), so musst
+Du einen Antrag an das Balanceteam stellen. In der Zwischenzeit sollte Dein
+Magierlevel so hoch sein, dass Du den Befehl 'goto' benutzen kannst. Es
+gibt einen Extra Raum fuer die Balanceantraege:
+goto /players/paracelsus/office
+Dort gibt es dann eine gute Hilfeseite.
+Wichtiges zum Antrag: mach bitte nicht fuer jedes Objekt einen eigenen
+Antrag, sondern schreibe Dir einen grossen Antrag, in den alle Deine
+Objekte reinkommen, die der Balance vorgelegt werden muessen (siehe Phase 2:
+aus der Liste, die Du erstellt hast). Dazu solltest Du jedes Objekt kurz
+beschreiben. Dazu kommen die wichtigsten Werte, bei Waffen z.B. Waffenart,
+P_WC, P_NR_HANDS, P_DAM_TYPE, P_WEIGHT, und eine kurze Beschreibung der
+Sonderfunktionen.
+Das Bewilligen Deiner Objekte kann eine ziemlich lange Zeit in Anspruch
+nehmen (Wochen). Hier nicht ungeduldig sein. Das dauert seine Zeit.
+Wenn Du Objekte proggst, die bestimmt durch die Balance muessen, gib doch
+Deinem RM fruehzeitig Bescheid, dass er sich das anguckt. Dann kannst Du
+die Sachen bereits beantragen, und in der Zeit, bis die Antraege
+bewilligt wurden, die anderen Dinge proggen. Dieser Ansatz gilt aber eher
+fuer Magier, die bereits etwas angeschlossen haben und neue Gebiete
+erstellen. Fuer den Neuling ist es empfehlenswerter, alles fertigzumachen
+und dann zu beantragen. Grund: siehe oben: So kannst Du vorweisen, dass Du
+Dir Muehe gegeben hast, tolle Sachen auf die Beine zu stellen, und nicht
+einfach einen NPC in die Welt stellen willst, mit hunderten toller Objekte.
+
+-------------------------------------------------------------
+P H A S E 5
+-------------------------------------------------------------
+Gleichzeitig solltest Du die Forscherpunkte beantragen. Welcher Erzmagier
+dafuer zustaendig ist, findest Du mit 'man erzmagier' heraus. Die
+Faustregel lautet: etwa 1 FP pro 10 Raeume. Vermeide FP fuer Details, damit
+die 'Untersuche-Skripte' keine Chance haben. Geh lieber so vor:
+Detail: 'gras' -> 'Du wuerdest Dich am liebsten ins Gras legen.'
+Wenn der Spieler dann eintippt 'lieg ins gras' oder so aehnlich, gib dafuer
+den FP, aber nicht fuers Untersuchen vom Gras.
+Wofuer Du alles Forscherpunkte eintragen kannst, erfaehrst Du durch
+'hilfe forscherpunkte'.
+Mache ein paar Vorschlaege, und schick sie dann dem zustaendigen Erzmagier.
+Der wird aus Deinen Vorschlaegen ein paar rauspicken und anschliessen.
+Aber bevor Du das tust, muss Dein Gebiet zwingend schon im Regionsverzeichnis
+liegen, damit keine FPs aus /players eingetragen werden.
+
+Gleichzeit mit den FPs meldest Du auch MiniQuests und Zaubertraenke
+bei diesem Erzmagier an. Du musst angeben, wieviele Stufenpunkte die
+Miniquest bringen soll und in welche der 3 Kategorien einfach/mittel/schwer
+Deine Zaubertraenke fallen.
+
+Denke daran, spaetestens jetzt die Gildenquests und Gildenobjekte bei den
+Gildenmagiern anzumelden. Unangemeldetes darf nicht angeschlossen werden.
+Wende Dich also frueh genug an diese Leute.
+
+-------------------------------------------------------------
+P H A S E 6
+-------------------------------------------------------------
+Ist alles von der Balance genehmigt worden, und sind die FP angeschlossen,
+solltest Du Deine RMs informieren. Falls Dein Gebiet immer noch im
+Heimverzeichnis liegt, wird es nun in dein Regionsverzeichnis
+verschoben. Du stehst nun kurz vor dem Anschliessen. Ueberleg Dir doch
+schon eine nette Botschaft, die Du dann in der MPA veroeffentlichen wirst.
+
+-------------------------------------------------------------
+P H A S E 7
+-------------------------------------------------------------
+GRATULATION! Du hast es geschafft! Aber jetzt nicht auf den Lohrbeeren
+ausruhen. Die ersten Spieler werden sich einfinden, und viele sind
+wandelnde Konversationslexikons, die auch den kleinsten Grammatikfehler
+in Deinen Beschreibungen finden. Andere Spieler werden Dir neue Vorschlaege
+fuer commands zusenden, die in die entsprechenden Raeume passen wuerden.
+In /log/report/<magiername>.rep wird automatisch Dein Report-File erzeugt,
+in das die Spieler die gefundenen Typos, Bugs und sonstige Ideen reinschreiben.
+Schau Dir Dein Repfile an, und arbeite es ab so gut es geht.
+Nur so wird das Gebiet zu einem wirklich 'gepflegten' Gebiet.
+Denke daran, das rep-File nach dem Abarbeiten zu loeschen, sonst wird
+es zu voll.
+
+
+SIEHE AUCH:
+ balance, hilfe magier, /doc/wiz/
+
+----------------------------------------------------------------------------
+Last modified: 16:00 2003-02-22 by Humni
diff --git a/doc/wiz/licht b/doc/wiz/licht
new file mode 100644
index 0000000..d995a23
--- /dev/null
+++ b/doc/wiz/licht
@@ -0,0 +1,34 @@
+Eine Zusammenfassung aller Lichtproperties (fuer genaueres siehe manpages)
+
+P_LIGHT - gibt an wie stark eine Lichtquelle selbst leuchtet.
+
+P_TOTAL_LIGHT - gibt das Lichtlevel an, das von einem Objekt ausgeht,
+ dieses kann != P_LIGHT sein, z.B. weil eine Fackel in
+ einem Paket liegt.
+
+P_INT_LIGHT - Lichtlevel in einem Objekt, z.B. ein Raum
+ gibt an wie gut dieses Objekt ausgeleuchtet ist.
+
+P_PLAYER_LIGHT - gibt an mit welchem Lichtlevel der Spieler gerade sieht
+
+P_LIGHT_MODIFIER - veraendert den Lichtlevel der von einem Spieler
+ wahrgenommen wird, z.B. eine Sonnenbrille
+
+P_LIGHT_ABSORPTION - Wieviel Licht wird vom Raum geschluckt? wirkt sich
+ direkt auf P_INT_LIGHT des Raumes aus. Andere Spieler
+ profitieren von den Lichtquellen ihrer Mitspieler
+ weniger bei hoeheren Werten. Default: 1.
+
+P_LIGHT_TRANSPARENCY - Wieviel Licht schluckt ein Container und wieviel
+ Licht dringt nach aussen. Defaulttransparenz: 2
+
+Hinweis: Alle Objekte mit Lichtlevel <0 und >2 sowie alle Objekte, die
+ P_LIGHT_MODIFIER oder Closures setzen sind genehmigungspflichtig!
+ Dafuer sind die Regionsmagier zustaendig.
+
+
+SIEHE AUCH: P_LIGHT
+
+------------------------------------------------------------------------------
+ LETZTE AeNDERUNG:
+ 2002-11-21, 17.30 von Zook
diff --git a/doc/wiz/lupe b/doc/wiz/lupe
new file mode 100644
index 0000000..28e23fe
--- /dev/null
+++ b/doc/wiz/lupe
@@ -0,0 +1,209 @@
+ALLGEMEINES:
+ Die Lupe benutzt einen Stapel (Stack), um Objekte zu bearbeiten.
+ Einige Befehle schieben Objekte auf den Stapel, andere wiederum
+ holen sie wieder vom Stapel herunter und benutzen sie fuer die
+ verschiedensten Zwecke.
+ Man kann in einer Zeile mehrere Kommandos gleichzeitig angeben
+ (durch Leerzeichen getrennt).
+ Eine Zeile wird immer von links nach rechts abgearbeitet.
+
+SCHREIBWEISEN:
+ <arg> - Eine Reihe von Zeichen, die weder Leerzeichen noch Punkte
+ (.) enthaelt. Falls doch Leerzeichen oder Punkte in <arg>
+ auftauchen, muss man die Zeichenkette zwischen "...",
+ '...' oder |...| einschliessen.
+ <nr> - Eine (positive oder negative) ganze Zahl.
+ <filename> - Ein Dateiname. Fuer ihn gilt das Gleiche wie fuer <arg>:
+ Wenn er Punkte enthaelt, muss man ihn zwischen "...",
+ '...' oder |...| einschliessen.
+ Es sind alle Variationen moeglich, die man auch aus der
+ Magiershell kennt: absolute Dateinamen (beginnen mit "/"),
+ Dateinamen relativ zum eigenen Homeverzeichnis ("~/")
+ oder zum Homeverzeichnis eines anderen Magiers ("~name/"),
+ Dateinamen in einer Region ("+region/") und Dateinamen
+ relativ zum aktuellen Verzeichnis (alles andere ;).
+ <func> - Name einer LPC-Funktion.
+ TOS - Das Objekt ganz oben auf dem Stapel (Top Of Stack).
+
+DER STAPEL:
+ Bei dem Stapel handelt es sich um einen LIFO-Stapel (Last In - First
+ Out), d.h. das Objekt, das zuletzt auf den Stapel geschoben wurde,
+ wird als erstes bearbeitet.
+ Bei der Bearbeitung wird der TOS in der Regel vom Stapel entfernt
+ (Ausnahmen: =, stk und #), der Stapel wird also im Laufe der Zeit
+ wieder kleiner.
+ Der Stapel kann maximal zehn Elemente aufnehmen. Dieses Limit wird
+ man bei "normalem Betrieb" allerdings selten erreichen.
+ Sollte es trotzdem einmal eng werden, stehen einem noch zehn
+ Variablen zur Verfuegung, in denen man zusaetzlich Objekte (vom
+ Stapel) ablegen kann.
+
+BEFEHLE:
+ Es gibt drei unterschiedliche Befehlsgruppen:
+ a) Befehle, die ein Objekt auf den Stapel schieben;
+ b) Befehle, die mit Objekten auf dem Stapel arbeiten;
+ c) Befehle, die ohne den Stapel auskommen.
+ Einige Befehle setzen voraus, das der TOS ein Lebewesen oder gar ein
+ Spielerobjekt ist; andere Befehle sind erst ab einem bestimmten
+ Magierlevel zugaenglich. Dies ist bei den entsprechenden Befehlen
+ jeweils vermerkt.
+
+ Diese Befehle schieben ein neues Objekt auf den Stapel:
+ creat <filename> Macht das Gleiche wie 'new', das Objekt wird aller-
+ dings nicht in Dein Inventory gesteckt.
+ here Das Objekt, in dem man gerade steht, auf den Stapel
+ schieben.
+ lv <arg> Schiebt das Lebewesen mit dem living_name <arg> auf
+ den Stapel. ACHTUNG! Das muss dann nicht unbedingt
+ das Lebewesen sein, das man dort eigentlich haben
+ will! Es wird einfach das erste Objekt genommen,
+ dessen living_name passt! Wenn man etwas mit einem
+ NPC vorhat, der im gleichen Raum steht, spricht man
+ ihn besser mit here.name an.
+ me Sich selbst auf den Stapel schieben.
+ new <filename> Cloned das mit <filename> angegebene Objekt und
+ schiebt es auf den Stapel. Anschliessend befindet es
+ sich in Deinem Inventory.
+ ob <filename> Laedt das Objekt, das mit <filename> angegeben ist,
+ und schiebt es auf den Stapel.
+ pl <arg> Schiebt das Spielerobjekt mit dem Namen <arg> auf den
+ Stapel.
+ Es werden auch netztote Spieler berucksichtigt.
+ push <filename> Schiebt das Objekt, das mit <filename> angegeben ist,
+ auf den Stapel.
+ <filename> Macht das gleiche wie 'ob', falls <filename> mit "/"
+ oder "~" beginnt.
+
+ Die naechsten Befehle schalten Optionen der Lupe an/aus/um:
+ desc Die zusaetzliche Angabe der Kurzbeschreibung des
+ aktuellen Objektes wird unterdrueckt.
+ rec Schaltet in den "rekursiv"-Modus um. Dieser Modus
+ wird von folgenden Befehlen genutzt:
+ 'inv', 'cln' und 'clnof'
+ Nach Ausfuehrung eines dieser Befehle wird der
+ "rekursiv"-Modus automatisch wieder abgestellt.
+ norec Stellt den "rekursiv"-Modus "von Hand" ab.
+
+ Diese Befehle schieben ebenfalls ein neues Objekt auf den Stapel. Sie
+ arbeiten dabei allerdings relativ zum TOS. Man muss also schon mindestens
+ ein Objekt auf den Stapel geschoben haben. Der alte TOS wird dabei in der
+ Regel entfernt.
+ .<nr> Schiebt das <nr>te Objekt im Inventory des TOS auf den
+ Stapel.
+ .<arg> Schiebt das Objekt mit der ID <arg> im Inventory des
+ TOS auf den Stapel.
+ <<nr> Schiebt die Variable <nr> auf den Stapel. Als <nr>
+ sind Werte zwischen 0 und 9 moeglich.
+ @<nr> Schiebt das <nr>te Objekt von oben noch einmal auf den
+ Stapel. Der alte TOS hat die Nummer 0. Weder der alte
+ TOS noch das verschobene Objekt werden vom Stapel ent-
+ fernt.
+ @1 ist analog zu 'over'.
+ copy Legt eine Kopie des TOS an (inkl. aller Propertywerte)
+ und schiebt diese Kopie auf den Stapel. Die Kopie
+ befindet sich danach in Deinem Inventory.
+ dup Schiebt den TOS doppelt auf den Stapel.
+ env Schiebt das Objekt, in dem sich der TOS befindet, auf
+ den Stapel.
+ over Schiebt das Objekt, das sich unter dem TOS befindet,
+ nochmal auf den Stapel. Dabei werden weder der alte
+ TOS noch das Objekt unter ihm entfernt.
+ result Wenn in einem Objekt eine Funktion aufgerufen wurde,
+ und diese Funktion wieder ein Objekt zurueckgegeben
+ hat, so wird dieses Objekt auf den Stapel geschoben.
+ swap Tauscht TOS und das darunter liegende Element gegen-
+ einander aus.
+
+ Die naechsten Befehle arbeiten mit den auf dem Stapel liegenden Objekten.
+ Dabei werden die bearbeiteten Objekte in der Regel vom Stapel entfernt.
+ ><nr> Speichert den TOS in der Variablen <nr>. Als <nr>
+ sind Werte zwischen 0 und 9 moeglich.
+ = Zeigt den TOS. Dieser bleibt dabei unveraendert.
+ # Der Stack bleibt ueber das naechste Kommando hinaus
+ erhalten.
+ inv Zeigt das Inventory des TOS. Der TOS bleibt dabei
+ unveraendert.
+ cln Entfernt alle Objekte aus dem Inventory des TOS. Es
+ werden allerdings keine Spieler entfernt.
+ clnof <arg> Entfernt alle Objekte, die auf die ID <arg> anspre-
+ chen, aus dem Inventar des TOS.
+ clr Loescht den gesamten Stack.
+ Dest Der TOS wird zerstoert. Das geht allerdings NICHT,
+ wenn der TOS ein Spielerobjekt oder die Lupe selbst
+ ist.
+ dest Wie Dest, allerdings wird zuerst TOS->remove() auf-
+ gerufen, um dem TOS die Moeglichkeit zu geben, noch
+ hinter sich aufzuraeumen.
+ dinfo Gibt einige GameDriver-interne Informationen wie zB.
+ die Zeit des naechsten reset()-Aufrufs oder die an-
+ gesammelte evalcost des TOS aus.
+ disco Unterbricht die Verbindug des TOS (muss ein aktiver
+ Spieler sein) zum MG (disconnect).
+ hl Zeigt die Historyliste des TOS an (hierbei muss es
+ sich um einen Spieler handeln).
+ Dieser Befehl steht ab ELDER_LVL (50) zur Verfuegung.
+ !!!Fuer die Benutzung gilt das Gleiche wie fuer das
+ Snoopen!!!
+ idle Gibt an, wie lange der TOS schon idlet. (Der TOS
+ sollte dabei natuerlich ein Spieler sein).
+ info Gibt einige Informationen ueber den TOS aus.
+ inherit_list Gibt den Vererbungsbaum des TOS aus (allerdings nicht
+ sehr baumfoermig ;)
+ inv Zeigt das Inventory des TOS an.
+
+ make Fuehrt ein Update des TOS durch. Geht nicht bei
+ Spielern! Dafuer gibt es renew.
+ minfo Gibt einige Informationen ueber den Speicherverbrauch
+ des TOS aus.
+ move, mov, mo Das Objekt, das unter dem TOS steht, wird in den TOS
+ gemoved. Beide Objekte werden dabei vom Stapel ent-
+ fernt.
+ _move, _mov, _mo, _mv
+ Das Objekt, das unter dem TOS steht, wird in den TOS
+ gemoved, ohne dass dort init() aufgerufen wird. Beide
+ Objekte werden dabei vom Stapel entfernt.
+ Dieser Befehl steht ab ARCH_LVL (60) zur Verfuegung.
+ pop Entfernt den TOS.
+ renew Aehnlich wie 'make', der TOS muss allerdings ein
+ Spieler sein. ACHTUNG! Man sollte nicht "einfach so"
+ Spieler 'renew'en, sondern nur dann, wenn es wirklich
+ gerechtfertigt ist!
+ scan, sc Kombiniert 'stat' und finger. Der TOS muss ein Lebe-
+ wesen sein.
+ stat Gibt Informationen ueber Zustand, Ausruestung, ge-
+ loeste Quests etc. des TOS aus. Der TOS muss dabei
+ ein Lebewesen sein.
+ stk Zeigt den gesamten Stack. Dieser bleibt dabei unver-
+ aendert.
+ [<func>] Ruft im TOS die Funktion <func> ohne Parameter auf.
+ Falls diese Funktion ein Objekt zurueckgibt, kann man
+ dieses anschliessend mit result auf den Stapel
+ schieben.
+ [<func> <arg1> ... <argn>]
+ Ruft im TOS die Funktion <func> mit den Parametern
+ <arg1> bis <argn> auf. Die Parameter sind mit Leer-
+ zeichen zu trennen. Enthalten die Parameter selbst
+ Leerzeichen, so sind sie in "...", '...' oder |...|
+ einzuschliessen.
+ Mittels @<nr> kann man auch Objekte, die sich auf dem
+ Stapel befinden, als Argumente angeben.
+
+ Die folgenden Befehle kommen ohne Objekte auf dem Stack aus:
+ call_out Gibt eine Liste aller Objekte mit einem laufenden
+ call_out aus.
+ dump Schreibt die Listen aller Objekte mit aktivem
+ heart_beat und aller Objekte mit laufendem call_out
+ in die Datai LISTS.LUPE in Dein Homeverzeichnis.
+ dumphists Schreibt die Befehlshistory aller momentan einge-
+ loggten Spieler nach /log/ARCH/HD.
+ Dieser Befehl steht erst ab ARCH_LVL (60) zur
+ Verfuegung.
+ heart_beat Gibt eine Liste aller Objekte mit aktivem heart_beat
+ aus.
+ rusage Zeigt einige Infos ueber den Ressourcenge-/-verbrauch
+ des Muds an.
+ swho Zeigt (so gut wie) alle aktiven Snoops.
+ vars Zeigt die belegten Variablen an.
+
+----------------------------------------------------------------------------
+Last modified: Wed Jun 26 14:49:02 1996 by Wargon
\ No newline at end of file
diff --git a/doc/wiz/material b/doc/wiz/material
new file mode 100644
index 0000000..cbf8022
--- /dev/null
+++ b/doc/wiz/material
@@ -0,0 +1,98 @@
+Materialien
+===========
+
+ Materialien in Morgengrauen koennen ueber die Property P_MATERIAL jedem
+ Objekt im Spiel zugeordnet werden. Ueber die Materialiendatenbank
+ stehen dafuer jede Menge Materialien zur Verfuegung. Wenn moeglich,
+ sollten diese auch benutzt werden, es werden Defaultmaterialien
+ gesetzt, diese entsprechen aber selten eurer Realitaet.
+
+ Die Materialiendatenbank /secure/materialdb.c haelt saemtliche
+ Informationen ueber die verwendbaren Materialien, die unter
+ /sys/thing/material.h aufgefuehrt sind. Es empfiehlt sich SEHR, Verweise
+ auf die MatDB nur in Form von MATERIALDB zu formulieren.
+ Sie verwaltet auch die Eigenschaften einzelner Materialien. Es gibt
+ diverse Materialiengruppen wie "entflammbar", "Metall", "biologisches
+ Material", denen die Materialien entsprechend zugeordnet sind. Diese
+ Informationen koennen mit entsprechenden Methoden abgerufen/ausgewertet
+ werden.
+ Darueber hinaus sind Materialien bei der Erkennung mit anderen
+ Materialien verwechselbar. Wie das genau funktioniert, ist in "man
+ materialerkennung" ausgefuehrt.
+
+ P_MATERIAL:
+ Die Property P_MATERIAL ist grundsaetzlich ein Mapping, in dem zu
+ jedem Material der Anteil an dem Objekt stehen sollte, Z.B. kann
+ ein Speer zu 80% aus Holz und zu 20% aus Metall (Speerspitze)
+ bestehen:
+
+ SetProp(P_MATERIAL, ([MAT_MISC_METAL:20,MAT_MISC_WOOD:80]))
+
+ (Zur Vereinfachung ist es erlaubt, bei SetProp ein einzelnes Material
+ oder ein Array aus Materialien anzugeben, beides wird automatisch
+ umgewandelt in ein Mapping mit gleichen Anteilen aller Materialien.)
+
+ Defaults für P_MATERIAL:
+ Waffen generell: ([MAT_MISC_METAL:100])
+ Schwerter: ([MAT_MISC_METAL:100])
+ Messer: ([MAT_MISC_METAL:80, MAT_MISC_WOOD:20])
+ Aexte: ([MAT_MISC_METAL:50, MAT_MISC_WOOD:50])
+ Speere: ([MAT_MISC_METAL:20, MAT_MISC_WOOD:80])
+ Keulen: ([MAT_MISC_WOOD:100])
+ Ruestungen generell: ([MAT_LEATHER:100])
+ Koerperruestungen, Helme,
+ Ringe, Amulette, Schilde: ([MAT_MISC_METAL:100])
+ Umhaenge, Hosen: ([MAT_CLOTH:100])
+ Handschuhe, Schuhe: ([MAT_LEATHER:100])
+ andere Dinge: ([MAT_MISC:100])
+
+ Uebersicht ueber die Methoden an Objekten (/std/thing/description):
+ int QueryMaterial(string mat):
+ - gibt % des Materialanteils von mat am Objekt zurueck
+ int QueryMaterialGroup(string grp):
+ - gibt % des Materialgruppenanteils von grp am Objekt zurueck
+ string MaterialList(int casus, mixed idinf):
+ - gibt String mit Zusammensetzung des Objektes zurueck
+
+ Uebersicht ueber die Methoden am Master (MATERIALDB):
+ string *GetMatMembership(string mat):
+ - alle Gruppen, in denen das Material mat ist
+ string *GetGroupMembers(string grp):
+ - alle Materialien, die in der Gruppe grp sind
+ string MaterialName(string mat, int casus, mixed idinf):
+ - ergibt die spielerlesbare Angabe eines Materials mat
+ string GroupName(string grp):
+ - ergibt spielerlesbare Angabe der Gruppe grp
+ string ConvMaterialList(mixed mats, int casus, mixed idinf):
+ - wird von MaterialList() mit den Materialien des Objektes gerufen
+ void Dump():
+ - schreibt Materialien und Gruppen in /p/daemon/save/MATERIALS
+ string *AllMaterials():
+ - Liste aller aktuellen Materialien
+ string *AllGroups():
+ - Liste aller aktuellen Gruppen
+
+ Falls euch ein Material fehlt:
+ - falls es kein genau passendes Material gibt, sollte man das am
+ ehesten passende MAT_MISC-Material verwenden.
+ - falls es sich lohnen wuerde, das bisher noch nicht definierte
+ Material einzubauen (wenn es haeufig genug verwendet wird), bitte
+ Mail an einen EM (-> man AddMaterial() )
+ - verschiedene Eigenschaften lassen sich kombinieren. Z.B. besteht
+ ein (unbekanntes) explosives Gas zu 100% aus Gas und zu 100% aus
+ explosivem Material. Insofern kann man es mit
+ SetProp(P_MATERIAL, ([MAT_MISC_GAS:100, MAT_MISC_EXPLOSIVE:100]))
+ zusammensetzen.
+
+SIEHE AUCH:
+ Konzepte: materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Methoden: QueryMaterial(), QueryMaterialGroup(), MaterialList(),
+ Listen: AllMaterials(), AllGroups(), Dump()
+ materialliste, materialgruppen
+ Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
+ GroupName(), MaterialName(),
+ GetGroupMembers(), GetMatMembership()
+ Sonstiges: P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
diff --git a/doc/wiz/materialerkennung b/doc/wiz/materialerkennung
new file mode 100644
index 0000000..976106f
--- /dev/null
+++ b/doc/wiz/materialerkennung
@@ -0,0 +1,79 @@
+Materialerkennung
+=================
+
+ Bei MaterialName(mat,casus,idinf) und MaterialList(casus,idinf) id der
+ Parameter <idinf> als Angabe dafuer gedacht, wie gut Materialien
+ erkannt werden sollen. Es sind folgende Arten von Angaben moeglich:
+
+ - Ein Array
+ Die einzelnen Arrayelemente werden nach untenstehenden Regeln
+ behandelt und deren Ergebnisse addiert.
+ - Ein Objekt
+ In diesem Fall wird
+ ob->QueryProp(P_MATERIAL_KNOWLEDGE)
+ nach untenstehenden Regeln behandelt.
+ Diese Property ist fuer rassenabhaengige Faehigkeiten gedacht.
+ - Eine Zahl
+ In diesem Fall wird der Wert direkt als Faehigkeit angesehen, das
+ Material erkennen zu koennen.
+ - Eine Closure
+ In diesem Fall wird der Returnwert von
+ funcall(closure,material,gruppen_in_denen_diese_material_ist)
+ genommen.
+ - Ein Mapping
+ In einem Mapping sind 3 Arten von Eintraegen moeglich:
+ - Ist im Mapping unter <mat> eine Zahl eingetragen, wird diese
+ genommen und die weiteren Eintraege nicht weiter ausgewertet.
+ - Die Werte von allen Gruppen im Mapping, zu denen das Material
+ gehoert, werden addiert.
+ - Falls das Mapping einen Eintrag MATERIAL_SYMMETRIC_RECOGNIZABILITY
+ hat, der ein Array von der Form
+ ({gruppe1, wert1, gruppe2, wert2, ...})
+ ist, wird fuer jede dieser Gruppen der zugehoerige Wert
+ addiert, falls das Material in der Gruppe ist, und sonst
+ abgezogen.
+ Im Beispiel: ({MATGROUP_BIO: 5}) gibt einen Erkennbonus von 5% auf
+ alle biologischen Materialien, aber einen Malus von -5% auf alle
+ nichtbiologischen Materialien.
+
+ Schwer erkennbare Materialien haben in der Materialdatenbank eine
+ zusaetzliche Angabe der Form
+ ({mat1, wert2, mat3, wert4, mat5, ... wert(n-1), mat(n)})
+ wobei mat(n) das Material selber ist.
+
+ Das erkannte Material ist das Material mat(k), bei dem die
+ wert(k-1) <= Erkennungsfaehigkeit < wert(k+1)
+ ist. Bei Erkennungsfaehigkeit 100 oder mehr wird das Material auf jeden
+ Fall erkannt.
+
+ Der Wert fuer Durchschnittsspieler ist 0.
+
+BEISPIEL:
+ Angenommen, bei Platin waere die Angabe in der Datenbank
+ ({Metall, -20, Silber, 20, Platin})
+ Ein Spieler ohne besondere Erkennungsfaehigkeiten (also Wert 0) wuerde
+ also Platin fuer Silber halten, jemand, der von Metallen keine Ahnung
+ hat (beispielsweise mit der Angabe ([MATGROUP_METAL:-25]) in
+ P_MATERIAL_KNOWLEDGE) sieht nur noch, dass es ein Metall ist und jemand
+ mit ueberdurchschnittlicher Faehigkeit erkennt Platin als das, was es
+ ist.
+
+ P_MATERIAL_KNOWLEDGE koennte z.B. fuer Rassen wie folgt gesetzt werden:
+ Elf: ([MATGROUP_WOOD:30])
+ Zwerg: ([MATGROUP_STONE:30])
+ oder etwas komplexer
+ Zwerg: ([MATGROUP_STONE:30,
+ MATERIAL_SYMMETRIC_RECOGNIZABILITY: ({MATGROUP_BIO: -5})])
+
+SIEHE AUCH:
+ Konzepte: material
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Methoden: QueryMaterial(), QueryMaterialGroup(), MaterialList(),
+ Listen: AllMaterials(), AllGroups(), Dump()
+ materialliste, materialgruppen
+ Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
+ GroupName(), MaterialName(),
+ GetGroupMembers(), GetMatMembership()
+ Sonstiges: P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
\ No newline at end of file
diff --git a/doc/wiz/materialgruppen b/doc/wiz/materialgruppen
new file mode 100644
index 0000000..5201bae
--- /dev/null
+++ b/doc/wiz/materialgruppen
@@ -0,0 +1,53 @@
+Materialgruppen
+===============
+
+ Die ebenfalls kommentierte Liste unter /sys/thing/material.h ist immer
+ aktueller als diese hier.
+
+ MATGROUP_SOLID feste Dinge
+ MATGROUP_FLUID Fluessigkeiten
+ MATGROUP_GAS Gase
+
+ MATGROUP_WOOD Hoelzer
+ MATGROUP_DECIDUOUS_WOOD Laubhoelzer
+ MATGROUP_CONIFER_WOOD Nadelhoelzer
+ MATGROUP_TROPICAL_WOOD Tropenhoelzer
+ MATGROUP_JEWEL Edelsteine
+ MATGROUP_MINERAL Mineralien
+ MATGROUP_STONE Steine
+ MATGROUP_METAL Metalle
+ MATGROUP_PRECIOUS_METAL Edelmetalle
+ MATGROUP_PAPER Papier und Aehnliches
+ MATGROUP_CLOTH Stoffe
+
+ MATGROUP_ELEMENTAL (altertuemliche) Elemente
+ MATGROUP_BIO Alles, was lebt oder lebte
+ MATGROUP_LIVING Lebewesen
+ MATGROUP_HERBAL Pflanzliches
+ MATGROUP_DEAD Ueberreste von Lebewesen
+ MATGROUP_DRUG Drogen, Heiltraenke
+
+ MATGROUP_INFLAMMABLE Entflammbares
+ MATGROUP_EXPLOSIVE Explosives
+ MATGROUP_POISONOUS Giftiges
+ MATGROUP_MAGIC Magisches
+ MATGROUP_RADIOACTIVE Radioaktives
+ MATGROUP_ELECTRICAL Elektrisches
+ MATGROUP_MAGNETIC Magnetisches
+ MATGROUP_ACIDIC Saures
+ MATGROUP_EATABLE Essbares
+ MATGROUP_FLEXIBLE Biegsames
+ MATGROUP_INVIS Unsichtbares
+
+SIEHE AUCH:
+ Konzepte: material, materialerkennung
+ Grundlegend: P_MATERIAL, /sys/thing/material.h
+ Methoden: QueryMaterial(), QueryMaterialGroup(), MaterialList(),
+ Listen: AllMaterials(), AllGroups(), Dump()
+ materialliste
+ Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
+ GroupName(), MaterialName(),
+ GetGroupMembers(), GetMatMembership()
+ Sonstiges: P_MATERIAL_KNOWLEDGE
+
+7. Mai 2004 Gloinson
\ No newline at end of file
diff --git a/doc/wiz/mudlib-codestyle b/doc/wiz/mudlib-codestyle
new file mode 100644
index 0000000..77b4baa
--- /dev/null
+++ b/doc/wiz/mudlib-codestyle
@@ -0,0 +1,36 @@
+Wollt ihr Code in der allgemeinen, oeffentlichen Mudlib anschliessen, bitte
+beachtet die folgenden Hinweise zum Codestyle (nicht erschoepfend):
+
+* Einrueckungen per Leerzeichen, nicht Tabs
+* Einrueckung von 2 Leerzeichen pro Ebene
+* praegnante und viele Kommentare
+* keine lambdas
+* Bei inline-closures die function-Syntax statt der (: :)-Syntax verwenden.
+* else, else if in eine eigene Zeile
+* { am Beginn von Bloecken soll in eine eigene Zeile.
+* Nach ifs, Loops & Co: umfasst der davon kontrollierte Code mehr als eine
+ physische Zeile Code, einen Block mit { } formulieren.
+* keine return fun(), 0;
+* (type) Casts sollten vermieden werden (Ausnahme: (type)call_other).
+ (type) konvertieren nur, wenn die Typen zur Compilezeit bekannt und
+ unterschiedlich sind. Daher bei gewuenschten Konversionen to_type() nehmen.
+* Pfade, die absolut sind, sollen auch mit / beginnen, z.B.
+ inherit "/std/thing", nicht inherit "std/thing"
+
+Benennung von Properties:
+* der interne Name von Properties in der Basis-Mudlib beginnt immer mit
+ "p_lib_". Niemand sonst sollte Properties mit diesem Praefix erstellen.
+
+Sonstiges:
+* In der Mudlib wird keine neue Funktion(alitaet) angeschlossen, bevor die
+ Dokumentation dafuer fertig ist.
+ Am liebsten ist mir, bei der Konzeptentwicklung zuerst die fertige
+ Dokumentation (Manpage) fuer Nutzer/Spieler zu entwickeln, bevor ein Magier
+ ueberhaupt eine Zeile Code schreibt.
+* Patches muessen eine Zusammenfassung haben, welche kurz erlaeutert,
+ was dieser Patch fixen/aendern/verbessern soll und auf welche Weise
+ diese umgesetzt wird. (Anders gesagt: eine Commit-Message)
+
+LETZTE AeNDERUNG:
+ 15.8.2015, Zesstra
+
diff --git a/doc/wiz/muster_raum.c b/doc/wiz/muster_raum.c
new file mode 100644
index 0000000..74e4c99
--- /dev/null
+++ b/doc/wiz/muster_raum.c
@@ -0,0 +1,82 @@
+/*
+ *----------------------------------------------------------------------
+ * Ein kleiner Beispielraum.
+ * Er laesst sich als /obj/doc/muster_raum ansprechen.
+ *
+ * Dieses File ist Teil der MorgenGrauen-Mudlib von Jof und Rumata
+ * Letzte Aenderung: 17.08.92
+ * #include eingefuegt: Rumata 10.11.98
+ *----------------------------------------------------------------------
+ */
+#pragma strong_types,rtt_checks
+
+inherit "/std/room";
+ /* Diese Zeile deutet an, dass der Raum aus der Standard mudlib */
+ /* abgeleitet wird. Diese Zeile sollte in JEDEM Raum vorkommen. */
+
+#include <properties.h>
+ /* Diese Zeile definiert die grossbuchstabigen Namen, die in den */
+ /* SetProp-Befehlen benutzt werden. Es gibt noch weitere *.h */
+ /* Dateien, die andere nuetzliche Dinge definieren. */
+
+protected void create()
+{
+ ::create();
+ /* Diese Zeile initialisiert die Standard-attribute. */
+ /* Sie darf nicht fehlen ! */
+
+ SetProp(P_INT_SHORT, "Muster-raum" );
+ /* Die Beschreibung des Raumes fuer Spieler, die den */
+ /* kurz/brief-Modus eingestellt haben. */
+
+ SetProp(P_INT_LONG, "Dieses ist ein Musterraum, der nur zur Erlaeuterung\n"
+ + "dient. Ein unangenehmer Raum voller Sterne und schraeger\n"
+ + "Striche. Im Sueden kannst Du in vertrautere Raeume fliehen.\n"
+ + "Im Norden ist etwas seltsames.\n" );
+ /* Diese Beschreibung bekommen Spieler, die den kurz- */
+ /* Modus nicht benutzen, oder wenn sie "schau" eingeben. */
+
+ SetProp(P_LIGHT, 1 );
+ /* Diese Zahl ist 1 fuer Raeume, in denen man ohne */
+ /* Lichtquelle etwas sehen kann und 0 fuer Raeume, */
+ /* in denen man eine Solche braucht. */
+
+ AddExit( "sueden", "room/adv_guild" );
+ /* Baue einen Ausgang nach Sueden, er wird mittels des */
+ /* Kommandos "exits" angezeigt. */
+
+ AddSpecialExit( "norden", "go_nord" );
+ /* Wenn der Spieler versucht, diesen Ausgang zu */
+ /* benutzen, so wird er nicht in einen anderen Raum */
+ /* bewegt, sondern es wird im Raum die angegebene */
+ /* Funktion aufgerufen. */
+
+ AddCmd( "hilfe", "gib_hilfe" );
+ /* Dieses Kommando ruft die Funktion "gib_hilfe" auf, */
+ /* wenn der Spieler das Kommando "hilfe" eingibt. */
+ /* Das Kommando taucht nicht in der "exits-liste" auf. */
+
+}
+
+/*
+ *----------------------------------------------------------------------
+ * So jetzt ist der Raum fetig.
+ * Wirklich? Nein, fast.
+ * Die oben angegebenen Funktion fehlen noch, aber das sind bereits
+ * "Extras".
+ *----------------------------------------------------------------------
+ */
+
+int go_nord()
+{
+ write( "Hmm das war wohl doch nur die Wand.\n" );
+ return 1;
+ /* Das Kommando wirde erfolgeich beendet. */
+}
+
+int gib_hilfe()
+{
+ write( "Gehe nach Sueden, und Du kommst in die Abenteurer-Gilde.\n" );
+ return 1;
+}
+
diff --git a/doc/wiz/nachteile b/doc/wiz/nachteile
new file mode 100644
index 0000000..d37e56f
--- /dev/null
+++ b/doc/wiz/nachteile
@@ -0,0 +1,51 @@
+----------------------------------------------------------------------------
+NACHTEILE
+----------------------------------------------------------------------------
+Bei der Genehmigung von Objekten im Balanceteam kommt immer wieder die Frage
+auf, welche Nachteile das Objekt denn hat, wenn es schon so viele Vorteile
+besitzt. Generell gilt, dass starke Objekte nur dann genehmigt werden, wenn
+sie auch ueber entsprechend grosse Nachteile verfuegen.
+
+Daher hier mal eine kleine Auflistung dessen, was als solcher betrachtet
+wird:
+
+- Gewicht (nicht bei Keulen fuer Kleriker)
+
+- Anfaelligkeiten gegen Schadenarten
+
+- LP-KP-Abzug (Obergrenzen, jede Runde, jeder Reset)
+- Absenken der Maxwerte von LP, KP
+- Absenken von Attributen
+- Absenken von SA_SPEED, SA_QUALITY usw.
+
+- Schaden/Nutzen abhaengig vom Alignment
+- Generelle Restriktionen
+
+- Objekt muss an einer bestimmten Stelle (z.B. durch das Toeten einen NPC)
+ aufgeladen werden
+- wiederkehrende Kosten (ausser LP/KP auch sowas wie Geld/Items/Aufgabe)
+
+- Behinderung anderer Objekte
+- Belegung von Slots (Set)
+
+- Skillobjekt
+
+- Begrenzte Haltbarkeit
+- Abnutzung (z.B. P_QUALITY, oder einfach durch Zeit/Nichtbenutzung)
+- Umstaende, die das Objekt zerstoeren
+- Begrenzte Wirkung (z.B. Waffe wirkt nur gegen eine Rasse)
+
+- Unique
+- Unique mit begrenzter Anzahl
+
+Generell sollten Paraobjekte die Restriktion Seher besitzen, da sie auch nur
+von Sehern geholt werden koennen. Aehnliche Restriktionen sollten fuer
+Objekte aus Gebieten gelten, die erst ab einer gewissen Stufe betreten
+werden koennen.
+
+Objekte, die nur in eng begrenzten Gebieten wirken (z.B. Questitems wie der
+Spinnentoeter) muessen bei der Balance nicht beantragt werden, selbst wenn
+sie Werte besitzen, die die Balancegrenzen ueberschreiten.
+
+----------------------------------------------------------------------------
+Letzte Aenderung: 18.10.2005 - Miril
diff --git a/doc/wiz/netz b/doc/wiz/netz
new file mode 100644
index 0000000..2dd8cf4
--- /dev/null
+++ b/doc/wiz/netz
@@ -0,0 +1,27 @@
+Stand: 17.08.92
+Ueberarbeitet am 24.08.94 von Viper
+
+Die Netzphilosophie im MorgenGrauen
+-----------------------------------
+
+Die wichtigen Wege und Verbindungen in MorgenGrauen sollen eine Art
+Netzstruktur besitzen, d.h. es wird nicht am Rand angebaut (wie im
+alten NF), sondern mitten drin.
+
+Beispiel:
+
+Man stelle sich eine Strasse aus 6 Raeumen vor. Am Anfang verlaeuft
+die Strasse von Osten nach Westen ohne besondere Details am Weges-
+rand. Mit der Zeit bauen einige Magier aus dieser Region noerdlich
+und suedlich ihre Raeume und Quests an. Irgendwann jedoch sind alle
+Raeume ausgeschoepft. Dann kann der Erzmagier der Region ZWISCHEN
+die bestehenden Raeume der Strasse weitere Strassenraeume einfuegen.
+Dort kann dann wieder Noerdlich und Suedlich angebaut werden. In den
+neuen Strassenteilen sollten natuerlich keine Monster oder Hinder-
+nisse aufgestellt werden, so dass die Strasse fuer die SpielerInnen
+lediglich etwas laenger wird, dort aber keine neuen Probleme auf ihn
+/sie warten.
+
+Zusaetzliche Hindernisse sollten nur nach Absprache mit einem Erz-
+magier (das sind die Magier ab Level 60) in bestehende Strassen
+eingebaut werden.
diff --git a/doc/wiz/npcs b/doc/wiz/npcs
new file mode 100644
index 0000000..0242e4c
--- /dev/null
+++ b/doc/wiz/npcs
@@ -0,0 +1,121 @@
+ HINWEISE ZU NPCS:
+
+ a. Allgemeines / Hinweise / Tipps
+
+ Dies sind Richtlinien, keine Vorschriften!!!!
+
+ Nicht jeder NPC braucht einen living_name. Nur in besonderen NPCs
+ sollte man einen solchen setzen. Alles andere ist unsinnig und belastet
+ nur unnoetig den Speicher.
+
+ Ein Monster sollte niemals zu viel Zeug mit sich herumtragen. Ein bis
+ zwei Sachen reichen im Normalfall.
+
+ Niemals sollte ein Monster allein mit mehreren Top-Qualitaets-Sachen
+ (sehr gute Waffe plus gute Ruestung[en]) ausgestattet sein. Das waere
+ doch zu einfach.
+
+ Die Haerte der Monster ist im Prinzip egal; pflastert die Gebiete ruhig
+ mit Hydren.
+ Nur: Anfaengern oder kleineren Spielern zugaengliche Gebiete sollten
+ keine Autoattackmonster enthalten, die die "Kleinen" gleich umnieten.
+ Solche Gegenden sollten entweder mit Wachen bestueckt oder mit einigen
+ zunehmend haerteren Monstern einen "Vorgeschmack" bieten, damit man
+ nicht unbedarft reinrennt. Unfaelle wird's dennoch geben. Was soll's,
+ Rochus liebt seine Statistik... :)
+
+ Auch bei NPCs kann die Property P_INFO gesetzt werden, dies sollte
+ insbesondere bei starken und speziellen NPCs gemacht werden.
+
+ Bei NPCs, die besondere Spells benutzen, sollten die RMs darauf achten,
+ dass nicht ploetzlich die ganze Gegend von NPCs wimmelt, von denen
+ jeder seinen Gegner blind oder taub macht oder vergiftet.
+
+ Nur als Tipp:
+ Monster mit Attack-Chats sind erheblich kniffliger zu killen und machen
+ auch um ihrer Selbst willen mehr Spass als bloede Hau-Drauf-Monster,
+ die zwar ueber unendlich HP verfuegen, aber im Prinzip nur Geduld
+ brauchen, um sie zu besiegen. Phantasie ist gefragt.
+
+ b. Eigenschaften
+ Fuer einfache Monster bitte create_default_npc() benutzen!
+
+ Ansonsten:
+ P_HANDS
+ Bei Monstern ohne Waffen sollte die Property P_HANDS in allen drei
+ Werten dem Erscheinungsbild des Monsters entsprechen, also in Text,
+ Schadenshoehe und Schadensart.
+ Auch bei Monstern mit einer Waffe sollte P_HANDS vernuenftig gesetzt
+ werden, also nicht zu hoch. Darauf zu achten ist Aufgabe der RMs.
+
+ P_BODY
+ Monster sollten nicht ueber undurchdringliche Bodies verfuegen, weil
+ sie dann nur magisch zu schlachten sind. Bodies ueber 150 (oder
+ P_TOTAL_AC ueber 150 incl. Ruestungen!) sind kaum noch
+ "herkoemmlich" zu killen. Normale Monster, also nicht-magische, sind
+ eigentlich immer anfaellig gegen die physikalischen Schadenstypen.
+ Also bitte da keine P_RESISTANCE setzen.
+
+ P_RESISTANCE/P_VULBERABILITY/P_RESISTANCE_STRENGTHS
+ P_NOMAGIC
+ Die RESISTANCE der Monster sollte sich auf ein oder zwei
+ Schadenstypen begrenzen, und die sollten auch begruendbar sein. Ein
+ normales Wesen gegen BLUDGEON, SLASH oder PIERCE unempfindlich zu
+ machen ist unlogisch und sollte vermieden werden. Gleiches gilt fuer
+ Empfindlichkeiten.
+ Ebenso sollte es Gruende geben, warum ein Monster eine Magie
+ unwirksam macht.
+
+ P_XP
+ Der Toetungsbonus in XP, die der Killer erhaelt, betragen 1/100 des
+ Wertes, der in P_XP angegeben wird. Der Wert selbst sollte der
+ Haerte des Monsters angemessen sein, als Faustregel fuer
+ 'gewoehnliche' NPCs gilt:
+
+ P_XP = 5 * WC * MAX_HP
+
+ Die RMs sollten darauf achten, dass hier keine ueberhoehten Werte
+ gesetzt werden.
+
+ Fuer Attack-Spells und aehnlich fieses kann ein Bonus gegeben
+ werden. Fuer questrelevante NPCs oder "Informations-NPCs", die nicht
+ unbedingt als Metzelobjekte herumstehen, kann man auch die EP
+ senken, um sie fuer EP-Sammler uninteressant zu machen.
+
+ P_MURDER_MSG/P_KILL_MSG
+ Nicht jeder NPC braucht seine eigene Moerder- oder Killermeldung.
+ Bei normalen NPCs sollte man also darauf verzichten.
+
+ P_DIE_MSG/P_NOCORPSE
+ Wenn ein NPC ein wenig anders umfaellt als sonst, traegt das auch
+ zum Spiel bei.
+
+ P_GUARD
+ Wenn der NPC nichts bewacht und nicht uebermaessig stark ist, sollte
+ man ihn auch fortlocken koennen. Setzt P_GUARD entsprechend und
+ lasst den NPC mit AddItem und REFRESH_MOVE_HOME erzeugen.
+
+ AddClass
+ Wenn ihr euren NPC in den definierten Klassen einordnen koennt, dann
+ macht das bitte. Besitzer von Spezialwaffen oder Ruestungen werden
+ es euch danken.
+
+ c. Hilfs-/Begleit-NPCs
+
+ Bei solchen NPC wird auf Ausgewogenheit Wert gelegt, der Programmierer
+ sollte sich schon vor Antrag-Stellung an die Balance Gedanken darueber
+ machen, wie sich der NPC selber verhaelt.
+ Beispiel waere hier Unvertraeglichkeit mit anderen NPCs,
+ Aggressivitaet gegenueber anderen NPCs / Spielern, Wankel- muetigkeit,
+ Unzuverlaessigkeit, zeitliche Begrenzung, Schutz oder Schaden in
+ Abhaengigkeit von Align, Gilde des Spielers, Angriff, vom Ort des
+ Geschehens oder der Begabung des Spielers fuer Magie u.ae. Der
+ Phantasie sind hier keine Grenzen gesetzt.
+
+SIEHE AUCH:
+ Verwandt: balance, ruestungen, waffen, fernwaffen, uniques,
+ grenzwerte, attributsveraenderungen, resistenzen,
+ kampfobjekte, begleitnpcs
+ Funktionen: create_default_npc
+
+14.Feb 2007 Gloinson
diff --git a/doc/wiz/obj_geruest b/doc/wiz/obj_geruest
new file mode 100644
index 0000000..fc1f955
--- /dev/null
+++ b/doc/wiz/obj_geruest
@@ -0,0 +1,134 @@
+/*
+ *----------------------------------------------------------------------
+ * obj_geruest
+ * Dieses File ist Teil der Morgengrauen-Mudlib.
+ * Dieses File wird optimal formatiert, wenn Tabulatoren 4 Zeichen breit
+ * sind.
+ *
+ * Allgemeines Geruest fuer ein Objekt. Wer eigene Objekte schreibt,
+ * sollte sie nicht ganz so intensiv kommentieren wie dieses hier, aber
+ * hier sollen gleichzeitig, die grundlegenden Mechanismen erlaeutert
+ * werden.
+ *
+ * 16.08.92 Rumata
+ * Ueberarbeitet am 24.08.94 von Viper
+ *----------------------------------------------------------------------
+ */
+inherit "std/thing"; /* Leite aus den std-Objekten ab */
+
+#include <language.h> /* Stelle Namen der Faelle und der Geschlechter */
+ /* dem Objekt zur Verfuegung. */
+
+create()
+{
+ ::create();
+ /* Diese Zeile NIEMALS vergessen!!! */
+
+ AddId( "ball" );
+ AddId( "strandball" );
+ /* Unter diesen Bezeichnungen fuehlt der Ball sich "angesprochen" */
+ /* Mann sollte mit Ids nicht sparen, damit die Spieler nicht ewig */
+ /* nur nach dem richtigen Namen eines Objektes suchen muessen. */
+
+ SetProp( P_NAME, "Ball" );
+ SetProp( P_GENDER, MALE );
+ SetProp( P_ARTICLE, 1 );
+ /* Diese Meldungen ermoeglichen es der Mudlib, das Objekt richtig */
+ /* zu deklinieren. SetProp(P_ARTICLE, 1) kann wegfallen, da 1 Default ist. */
+
+ SetProp( P_SHORT, "Ein bunter Ball" );
+ SetProp( P_LONG, "Was fuer ein huebscher kleiner Strandball.\n"
+ +"Wem koenntest Du den mal zuwerfen?\n" );
+ /* Beschreibungen zur Betrachtung des Balls. */
+
+ SetProp( P_VALUE, 10 );
+ SetProp( P_WEIGHT, 250 );
+ /* Bei diesen Werten sollte die Verhaeltnismaessigkeit */
+ /* nicht aus den Augen gelassen werden. */
+}
+
+init()
+{
+ ::init();
+ /* NICHT VERGESSEN */
+ /* Wenn keine eigenen Aktionen definiert werden sollen, so kann die */
+ /* Funktion init ganz weggelassen werden. Ein init, das nur */
+ /* ::init() aufruft ist ueberfluessig. */
+
+ add_action( "wurf", "werf", 1 );
+ add_action( "wurf", "wirf" );
+ /* werfe, werf oder wirf jemandem den Ball zu. Man sollte darauf */
+ /* achten, dass natuerliche Saetze als Eingabe akzeptiert werden. */
+}
+
+/*************************************************************************/
+/************* Die grundlegenden Funktionen enden hier *******************/
+/*************************************************************************/
+
+
+/* Eine Beispielaktion fuer den Ball. */
+wurf( argument )
+{
+ /* "werf ball rumata zu" wird als Argument "ball rumata zu" bekommen. */
+ string arg1, arg2;
+ string ziel;
+ object zielObj;
+
+ if ( sscanf( argument, "%s %s zu", arg1, arg2 ) != 2 ) return 0;
+ /* Rueckgabe von 0 bedeutet, dass dieses Objekt mit der Eingabe */
+ /* nichts anfangen konnte, und dass der Gamedriver das naechste */
+ /* Objekt befragen soll. */
+
+ if ( id( arg1 ) )
+ /* Welches der Argumente spricht den Ball an ? */
+ /* Das andere muss dann das Ziel des Balls sein. */
+ ziel = arg2;
+ else if ( id( arg2 ) )
+ ziel = arg1;
+ else
+ return 0;
+ /* Keines der Argumente war der Ball. */
+
+ zielObj = present( ziel, environment() );
+ /* Suche ein Objekt, das sich als Ziel angesprochen fuehlt. */
+
+ if ( ! zielObj )
+ {
+ write( "Hier ist kein \"" + ziel + "\".\n" );
+ return 1;
+ /* Hier wird 1 zurueckgegeben, da der Ball das Kommando den */
+ /* Befehl bearbeiten konnte. Er hat zwar kein Ziel gefunden, */
+ /* aber man kann ja nicht alles haben. :-) */
+ }
+
+ if( !living( zielObj ) )
+ {
+ write( "Und wie soll " + zielObj->name(WER,1) + " den Ball fangen?\n" );
+ return 1;
+ /* Nur lebende Wesen sollen Baelle fangen koennen. */
+ }
+
+ write( "Du wirfst " + zielObj->name(WEN,1) + " den Ball zu.\n" );
+ /* Mitteilung an den Werfer */
+ say( PL->name(WER,2) + " wirft " + zielObj->name(WEM,2)
+ + " einen Ball zu.\n", zielObj );
+ /* Mitteilung an alle Wesem im selben Raum. */
+ tell_object( zielObj, "Hoppla, " + PL->name(WER,2)
+ + " wirft Dir einen Ball zu.\n" );
+ /* Mitteilung an den Beworfenen */
+
+ if ( move( zielObj ) ) return 1;
+ /* Es hat geklappt. */
+
+ move( environment() );
+ /* Im Fehlerfall soll der Ball zu Boden fallen. */
+
+ write( "Aber " + zielObj->QueryPronoun(WER)
+ + " kann ihn nicht fangen.\nDer Ball plumpst zu Boden.\n" );
+ say( "Aber " + zielObj->QueryPronoun(WER)
+ + " kann ihn nicht fangen.\nDer Ball plumpst zu Boden.\n", zielObj );
+ tell_object( zielObj,
+ "Aber Du kannst ihn nicht fangen.\nDer Ball plumpst zu Boden.\n" );
+
+ return 1;
+}
diff --git a/doc/wiz/pararaeume b/doc/wiz/pararaeume
new file mode 100644
index 0000000..9263da6
--- /dev/null
+++ b/doc/wiz/pararaeume
@@ -0,0 +1,84 @@
+Para-Raeume
+
+ Grundsaetzlich wird ein Para-Raum dadurch gekennzeichnet, dass an den
+ Dateinamen ein ^n angehaengt wird, n gibt die Dimension an. Ein Raum in
+ Para 1 wuerde also raum^1.c heissen.
+
+ Man muss sich nicht selbst darum kuemmern, dass Spieler in den richtigen
+ Para-Raum bewegt werden, das passiert im move().
+
+ Damit man bei gleichen Raeumen, die sich nur durch beispielsweise die
+ Anwesenheit eines fiesen Monsters unterscheiden nicht alles doppelt
+ beschreiben muss, sollte man das bekannte Konzept der Vererbung
+ verwenden. Hierfuer gibt es zwei Ansaetze:
+
+LOESUNG 1:
+ Habe ich einen Raum, der in Para exakt so ist wie in Normal, wo nur eine
+ Sache hinzugefuegt wird, schreibe ich meinen Raum in normal so wie ich es
+ immer tun wuerde, erbe diesen im Para-Raum und setze mein fieses Monster
+ hinein.
+ Einziger Unterschied im Normal-Raum: Damit er immer initialisiert wird,
+ muss ich create_super() erstellen und darin create aufrufen. Sonst buggt
+ der Normalraum beim Betreten, falls der Pararaum zuerst betreten wurde,
+ weil der Normalraum dann zwar geladen aber selbst nicht initialisiert
+ wurde.
+
+ Beispiel:
+
+ raum.c:
+ inherit "/std/room";
+
+ protected void create() {
+ ::create();
+ ...
+ }
+
+ protected void create_super() {
+ create();
+ }
+
+ raum^1.c:
+ inherit "raum";
+
+ protected void create() {
+ ::create();
+ AddItem("fieses_monster",REFRESH_REMOVE);
+ }
+
+LOESUNG 2:
+ Habe ich einen Raum, wo auch in Normal Dinge existieren, die es nicht in
+ Para geben soll, kann ich einen Raum mit der Dimensionsnummer 0 erstellen.
+ Dieser wird niemals automatisch betreten, ausser ein Ausgang fuehrt
+ explizit dort hin.
+
+ Beispiel:
+
+ raum^0.c:
+ inherit "/std/room";
+
+ protected void create() {
+ ::create();
+ ...
+ }
+
+ raum.c:
+ inherit "raum^0";
+
+ protected void create() {
+ ::create();
+ AddItem("harmloses_monster",REFRESH_REMOVE);
+ }
+
+ raum^1.c:
+ inherit "raum^0";
+
+ protected void create() {
+ ::create();
+ AddItem("fieses_monster",REFRESH_REMOVE);
+ }
+
+
+SIEHE AUCH:
+ move(L), create_super(L), P_PARA(P)
+
+Letzte Aenderung: 18.01.2015, Bugfix
diff --git a/doc/wiz/parierwaffen b/doc/wiz/parierwaffen
new file mode 100644
index 0000000..64cb9bc
--- /dev/null
+++ b/doc/wiz/parierwaffen
@@ -0,0 +1,18 @@
+==============================================================================
+ Regeln zur Programmierung von Parierwaffen:
+==============================================================================
+
+Standardobjekt: /std/weapon.c
+
+Siehe hierzu: /doc/wiz/balance (oder 'man balance')
+
+Aktuelle Grenzwerte:
+====================
+
+ Parier-Typ Genehmigungsgrenze
+ ------------ --------------------
+ PARRY_ONLY Wie Rustungen vom Typ AT_SHIELD
+ PARRY_TOO Generelle Genehmigungspflicht
+
+==============================================================================
+Paracelsus@MorgenGrauen, 18/08/1999
diff --git a/doc/wiz/potionmaster b/doc/wiz/potionmaster
new file mode 100644
index 0000000..6b8bfd2
--- /dev/null
+++ b/doc/wiz/potionmaster
@@ -0,0 +1,197 @@
+Der Potionmaster (/secure/potionmaster)
+=======================================
+
+BESCHREIBUNG
+
+ Funktion: Verwaltung der Zaubertraenke, die Spieler finden koennen.
+
+ Zaubertraenke koennen von beliebigen Objekten im Spiel vergeben werden.
+ Jeder Spruch ist in einer eigenen Datei in /secure/ARCH/ZT hinterlegt,
+ wobei der Dateiname das allgemeine Format <nr>.zt haben muss. <nr>
+ entspricht hierbei der ZT-Nummer.
+
+ Die Tips zu den Traenken werden vom Orakel /room/orakel ausgegeben,
+ sofern der Spieler genug Stufenpunkte fuer einen neuen Spruch erspielt
+ hat (siehe hierzu "hilfe zt"). Die Tips werden dabei aus den o.g. Dateien
+ eingelesen. Der ZT wird von dem vergebenden Objekt durch Aufruf von
+ FindPotion(string msg) im Spielerobjekt gutgeschrieben.
+
+ In dieser Datei sind die Funktionen des Potionmasters dokumentiert.
+ Inhalt:
+
+ 1. Zaubertraenke eintragen und aktivieren/deaktivieren
+ 2. Zaubertraenke in eine Liste einsortieren
+ 3. Zaubertraenke verlegen
+ 4. Daten zu Zaubertraenken abfragen
+ 5. Ein neuer ZT: Was tun?
+ 6. Format der Zaubertrank-Tips
+ 7. Wo finde ich eigentlich?
+ 8. Verschiedenes
+
+
+FUNKTIONEN
+
+1. Zaubertraenke eintragen und aktivieren/deaktivieren
+
+ int AddPotionroom(string room, int list)
+ Der Raum <room> wird als neuer ZT-Fundort eingetragen und in die Liste
+ mit der Nummer <list> eingefuegt. room muss hierbei der load_name()
+ des Objekts sein, unt <list> darf Werte von 0 bis 7 haben. Der ZT
+ wird dabei aktiviert.
+
+ Rueckgabewerte:
+ <num> Nummer des naechsten neuen ZTs, <num-1> ist die Nummer des
+ neu eingetragenen ZTs.
+ -1 Zugriff verweigert
+ -2 <room> kein String, <list> ist nicht im Bereich 0-7
+ -3 <room> ist nicht ladbar
+ -4 <room> vergibt schon einen (anderen) ZT
+ -6 Datei mit ZT-Spruch (/secure/ARCH/ZT/<num>.zt) existiert nicht.
+
+ int ActivateRoom(string room)
+ Der ZT im Raum <room> wird aktiviert, d.h. er kann aktiv von dem Raum
+ vergeben werden. Technisch wird er aus der Liste der inaktiven ZTs
+ ausgetragen. <room> muss hierbei der load_name() des Raumes sein.
+
+ Rueckgabewerte:
+ <num> Nummer des aktivierten ZTs
+ -1 Zugriff verweigert
+ -5 ungueltiger ZT (Raum ist nicht als ZT-Objekt eingetragen)
+ -8 <room> ist bereits aktiviert
+
+ int DeactivateRoom(string room)
+ Der ZT im Objekt <room> wird deaktiviert, d.h. er kann nicht mehr
+ von dem Objekt vergeben werden. Technisch wird er in die Liste der
+ inaktiven ZTs eingetragen. <room> muss hierbei der load_name() des
+ Raumes sein.
+
+ Rueckgabewerte:
+ <num> Nummer des geaenderten ZTs
+ -1 Zugriff verweigert
+ -5 ungueltiger ZT
+ -9 <room> ist bereits inaktiv
+
+2. Zaubertraenke in eine Liste einsortieren
+
+ int SetListNr(string room, int list)
+ Traegt den Zaubertrank in Raum <room> in die Liste <list> ein.
+ <room> muss hierbei der load_name() des Objekts sein.
+
+ Rueckgabewerte:
+ <num> Nummer des geaenderten ZTs
+ -1 Zugriff verweigert
+ -5 ungueltiger ZT
+ -7 <list> ausserhalb der zugelassenen Werte, d.h. <0 oder >7
+
+3. Zaubertraenke verlegen
+
+ int ChangeRoomPath(string old, string new)
+ Der Zaubertrank in Raum <old> wird in den Raum <new> umgetragen.
+
+ Rueckgabewerte:
+ <num> Nummer des erfolgreich geaenderten Zaubertranks
+ -1 Zugriff verweigert
+ -2 <new> oder <old> oder beide sind keine Strings
+ -3 <old> vergibt keinen ZT, es gibt also nichts zu verlegen, oder
+ <new> ist nicht ladbar, dorthin kann also nicht verlegt werden
+ -4 <new> hat schon einen Zaubertrank
+
+4. Daten zu Zaubertraenken abfragen
+
+ mixed QueryPotionData(int num)
+ Abfrage der Daten zu dem ZT mit der Nummer <num>. Ausgegeben wird ein
+ Mapping der Form ([ num : Raumpfad; Listennummer ])
+
+ int QueryInactivePotions()
+ Liefert ein Array mit den Nummern der aktuell deaktivierten ZTs zurueck.
+
+ int QueryActive(mixed potion)
+ Gibt zu einer ZT-Nummer oder einem Raumpfad an, ob der betreffende ZT
+ aktiv ist oder nicht. Wenn ja, wird die entsprechende ZT-Nummer
+ zurueckgegeben.
+
+ Rueckgabewerte:
+ <num> Nummer des abgefragten ZTs
+ -1 Zugriff verweigert
+ -5 ungueltiger ZT
+ -11 ZT ist nicht aktiv
+
+ string GetFilenameByNumber(int nr)
+ Abfrage des Dateinamens zu Zaubertrank Nummer <nr>.
+
+ Rueckgabewerte:
+ <num> Nummer des abgefragten ZTs
+ -1 Zugriff verweigert
+ -5 ungueltiger ZT
+
+ int HasPotion(object obj)
+ Abfrage der Zaubertranknummer, die von dem Objekt <obj> vergeben wird.
+
+ Rueckgabewerte:
+ <num> Nummer des abgefragten ZTs
+ -1 Zugriff verweigert
+ -3 Raum vergibt keinen ZT
+
+ int GetListByNumber(int nr)
+ Abfrage der Liste aktiver ZTs, in der der ZT mit der Nummer <nr>
+ eingetragen ist.
+ Rueckgabe: Nummer der Liste, in der der ZT enthalten ist, sonst -5.
+
+ int GetInactListByNumber(int nr)
+ Abfrage der Liste inaktiver ZTs, in der der ZT mit der Nummer <nr>
+ eingetragen ist.
+ Rueckgabe: Nummer der Liste, in der der ZT enthalten ist, sonst -10.
+
+5. Ein neuer ZT: Was tun?
+
+ AddPotionRoom(newroom, liste) aufrufen. Wenn ein Fehler auftritt, muss
+ noch der ZT-Tip in dem unter 6. beschriebenen Format hinterlegt werden.
+ Der zu verwendende Dateiname ist in der Fehlermeldung angegeben.
+
+6. Format der Zaubertrank-Tips
+
+ Ein Beispiel mit zwei Tips fuer denselben Zaubertrank:
+
+ Die Zaubermaus wollts wohl verstecken,
+ Im Buecherwald sollst nichts entdecken,
+ Denn Trinkgenuss ist dort verpoent,
+ So ist mans auch RL gewoehnt.
+ XXXXX
+ Der Raum ist prall und star gefuellt,
+ Mit viel Papier, das gern verhuellt
+ In Zauberbuchform manches Od,
+ Das hilft Dir dann aus Deiner Not.
+ %%%%%
+
+ Die Prozentzeichen sind das Endezeichen, danach koennen eventuelle
+ Kommentare stehen. XXXXX ist das Trennzeichen zwischen zwei Tips
+ zum selben ZT. Auswirkung ist, dass der Spieler bei jedem Aufruf
+ seiner Zaubertrank-Liste zufaellig einen Spruch aus der Liste
+ angezeigt bekommt.
+
+7. Wo finde ich eigentlich?
+
+ - die Zaubertrank-Tips: /secure/ARCH/ZT/*.zt
+ - die Gesamtliste der ZTs: /secure/ARCH/POTIONS.dump
+ - das Savefile des Potionmasters: /secure/ARCH/potions.o
+ - das Logfile fuer Aenderungen: /log/ARCH/POTIONS_MOD.log
+
+8. Verschiedenes
+
+ mixed TipLesen(int nr)
+ Das Orakel auf der Hochebene ruft die Zaubertrank-Tipps ab, diese
+ werden von der Platte gelesen und als String an das Orakel
+ zurueckgeliefert.
+ int DumpList()
+ Die Komplettliste der ZTs in das Dumpfile /secure/ARCH/POTIONS.dump
+ schreiben.
+
+SIEHE AUCH:
+ Spielerbefehle: zaubertraenke
+ Magierbefehle: traenke
+ Properties: P_POTIONROOMS, P_KNOWN_POTIONROOMS
+ Anleitung: wiz/zaubertraenke
+ ZT finden: FindPotion(L)
+
+2013-Mai-30 Arathorn
+
diff --git a/doc/wiz/quests b/doc/wiz/quests
new file mode 100644
index 0000000..5c45023
--- /dev/null
+++ b/doc/wiz/quests
@@ -0,0 +1,160 @@
+Leitfaden fuer die Questerstellung/-abnahme:
+============================================
+
+
+Quests im MorgenGrauen:
+-----------------------
+
+Beginnen wir mit einem Zitat:
+
+ Boing sagt: 'Das MorgenGrauen ist ein Questmud.'
+
+Das MorgenGrauen unterscheidet sich von einigen anderen Muds, indem
+eben ein sehr grosser Wert auf Quests gelegt wird. Mittlerweile haben
+wir ja auch schon eine ordentliche Anzahl Quests. Trotzdem ist es
+wichtig und wird immer wieder gerne gesehen, wenn neue Quests geproggt
+werden. Darueberhinaus bleibt man als Magier natuerlich auch laenger
+im Spiel bekannt. Gerade weil Quests auch eine wichtige Anforderung
+zum Sehertum sind, muss ihnen ein besonderes Augenmerk seitens des
+programmierenden Magiers gewidmet werden und besonders sorgfaeltig
+gearbeitet werden. Dazu gibt es nun im folgenden ein paar Hinweise,
+die man als Questprogrammierer einhalten sollte, damit die Quest
+genehmigt werden kann und bei den Spielern gut ankommt.
+
+Questideen:
+-----------
+
+Dies ist der wichtigste Bestandteil einer Quest. Hier sollte man sich
+sehr viel Muehe geben, denn mit dem Konzept steht und faellt eine
+Quest. Damit Spieler Spass an einer Quest haben, ist eine gute Story,
+ein gutes Konzept unabdingbar. Ein wichtiger Erfolgsfaktor ist an
+dieser Stelle auch, sich rechtzeitig mit dem betroffenen Regionsmagier
+und dem Questerzmagier abzusprechen. Spaeter hat man da vielleicht
+keine Gelegenheit mehr und hat sich viel Arbeit gemacht und muss
+wieder viel aendern. Daher: VORHERIGER ABSPRACHE VERMEIDET
+AERGER. Insbesondere bei Quests mit hohem Metzelanteil sollte
+unbedingt Ruecksprache gehalten werden, da solche Quests nicht so
+gerne gesehen sind.
+
+Questumsetzung:
+---------------
+
+Bei der Umsetzung kann man sich an die Regeln halten, die allgemein
+fuer den Anschluss von Gebieten gelten (NPCs, Balance...). Besondere
+Aufmerksamkeit verdienen die Teile, die zur Loesung der Quest
+notwendig sind (Questitems, Questmaster...) Es empfiehlt sich auch in
+dieser Phase, immer mal Ruecksprache mit dem Regionsmagier oder
+Questerzmagier zu halten.
+
+Eine Questbelohnung wird von Spielern immer wieder gerne
+genommen. Dabei sollte man allerdings ein gewisses Augenmass
+anlegen. Nicht fuer jede Quest muss es eine super tolle
+Auto-Load-Belohnung geben.
+
+Fuer das konkrete Umsetzen seien noch ein paar Hinweise gegeben:
+
+ - Fuer die Atmosphaere und die Details sollte man sehr viel Muehe
+ verwenden, so dass sich dem Spieler der logische Aufbau
+ erschliesst. Es ist fuer Spieler ausserordentlich aergerlich, eine
+ Quest zu spielen, deren Bestandteile irgendwie in der Luft
+ haengen.
+ - Es sollte sich sehr gut ueberlegt werden, wie die Quest reagiert,
+ wenn mehrere Spieler gleichzeitig die Quest spielen wollen (das
+ wird inbesondere direkt nach dem Anschluss der Fall sein).
+ Dies bezieht sich insbesondere auf Quest-Objekte, die einem Spieler
+ evtl. nicht zur Verfuegung stehen, weil sie gerade ein andere
+ genommen hat, oder Quest-NPCs, die wichtige Auskuenfte haben,
+ aber leider umgenietet wurden. Wichtige Quest-NPCs sollten nach
+ Moeglichkeit besser nicht als Metzelopfer konzipiert werden.
+ - Nach Moeglichkeit sollte es nicht das hundertste Labyrinth geben.
+ - Werden fuer die Quest allgemeine Objekte (wie Schaufeln, Seile
+ etc.) benoetigt, so sollten auch die an anderer Stelle im Mud
+ erhaeltlichen Objekte funktionieren oder es sollte fuer den Spieler
+ erkennbar sein, wieso nur ein spezielles Objekt den Zweck erfuellt.
+ - Questobjekte sollten fuer Spieler nicht erstellbar sein (->
+ Seherbeutel).
+ - Wird der Questfortschritt in einem Master gespeichert, so empfiehlt
+ es sich, die Daten zu den Spielern nach dem Loesen der Quest wieder
+ zu loeschen (ebenso bei Spielern, die sich geloescht haben).
+ - Es sollten sich auch Gedanken gemacht werden, wie die Quest beim
+ Einschlafen, Beenden oder bei einem Crash reagiert. Es muss also
+ sichergestellt sein, dass der Spieler dann beim naechsten
+ Questversuch nicht in einen inkonsistenten Zustand landet.
+ - Gut ist, den Questverlauf ein wenig variable zu gestalten, so
+ dass die Quest nicht ohne weiteres durchskriptbar ist.
+ - Bei Pflichtquests bitte beachten, dass NPCs, die zwingend zu toeten
+ sind, nicht zu stark sind.
+ - Das Objekt, welches die Quest nach dem Loesen setzen soll, muss einen
+ Aufruf von GiveQuest enthalten. Desweiteren ist beim ersten Loesen
+ in ein Questlogfile im Verzeichnis /log/quest ein Eintrag zu machen,
+ dass der Spieler die Quest bestanden hat. Diesen Eintrag bitte
+ mit write_file schreiben.
+
+Questtest (Magier):
+-------------------
+
+Nun kommt ein entscheidender Schritt fuer die Quest. Denn jetzt
+schauen auch einmal Magierkollegen ueber die Quest und koennen auf
+Bugs, logische Fehler und kleinere Probleme hinweisen. Um moeglichst
+viele derartiger Dinge abzufangen, sollte man auf den Questtest viel
+Zeit verwenden und Magierkollegen bitten, die Quest einmal zu testen.
+
+Questtest (Spieler):
+--------------------
+
+Wenn es moeglich ist, sollte auch ein Spieler die Quest einmal
+testen. Jedoch sind dazu die Regeln fuer Spielertesties ('man
+testies') einzuhalten. Es ist insbesondere darauf zu achten, dass
+wenn dem Testie eventuelle Forscherpunkte o.ae. zugesprochen werden,
+die negativen Seiten der Quest nicht wegfallen duerfen (soweit sie
+nicht auf Fehlern beruhen).
+
+Abnahme der Quest:
+------------------
+
+Sofern noch nicht geschehen, muss nun der Regionsmagier die Quest
+abnehmen. (Ist der Programmierer selbst der Regionsmagier, sollte er
+einen Magierkollegen bitten, dies zu machen (fuer die meisten Regionen
+gibt es ja mehr als einen RM).) Wenn dies alles geschen ist, kann der
+Questerzmagier die Quest abnehmen.
+
+Die Bearbeitung der Quest geht am schnellsten, wenn dem Quest-EM
+folgende Infos vorliegen (z.B. in einer Mail):
+
+ - Eine kurze Beschreibung der Quest, also worum geht es ueberhaupt?
+ - Eine Loesungsskizze (bitte nicht im Home-Verzeichnis rumliegen
+ lassen)
+ - Eine Beschreibung der technischen Loesung, also wie ist das ganze
+ programmiert?
+ - In welchem Objekt wird die Quest mittels GiveQuest gesetzt?
+ - Eine Aufstellung, welche Files zu der Quest gehoeren und wo sie
+ sich befinden.
+ - Eine Liste der Abhaengigkeiten zu anderen Teilen im Mud? (Gilden-NPCs,
+ MNPCs..)
+ - Eine Einschaetzung der Schwierigkeit der Quest. Wie gut sollte man
+ sein? Welchen Level? Was fuer Stats?...
+ - Einen Vorschlag, wieviele APs fuer die Quest vergeben werden sollen.
+ - Einen Vorschlag, welchen Spruch der Wanderer den Spielern sagen
+ soll.
+ - Eine Liste der Magier und Spieler, die die Quest schon getestet haben.
+
+Danach schaut sich der Quest-EM die Quest an und legt mit dem
+Programmierer zusammen APs, Schwierigkeitsgrad, den Spruch fuer den
+Wanderer etc. fest. Dann wird die Quest vom Quest-EM eingetragen.
+
+Questanschluss:
+---------------
+
+Zum Anschluss der Quest sollte man nach Moeglichkeit ebenfalls online
+sein, um eventuelle Probleme, Bugs zu beseitigen. Auch sollte man nach
+Anschluss der Quest gewissenhaft sein Repfile abarbeiten um Typos,
+Ideen und Bugs abzuarbeiten.
+
+Siehe auch:
+-----------
+
+ QueryQuest, GiveQuest, write_file
+
+------------------------------------------------------------------------------
+Zuletzt geaendert: Mon, 17. Jul 2000, 12:16:41 von Zook.
+
diff --git a/doc/wiz/quests.doc b/doc/wiz/quests.doc
new file mode 100644
index 0000000..24c91c8
--- /dev/null
+++ b/doc/wiz/quests.doc
@@ -0,0 +1,66 @@
+ Das Questsystem wird in MorgenGrauen von einem zentralen Questhandler
+gesteuert. Dieser stellt die folgenden Funktionen zur Verfuegung:
+
+AddQuest(string questname, int questpoints, int experience,
+ string *allowedobj, string hint, int difficulty, int needed)
+ Diese Funktion definiert eine Quest und gibt sie zur Benutzung durch die
+ Spieler frei. Sie darf nur von Erzmagiern aufgerufen werden.
+ Bedeutung der Parameter:
+ questname gibt den Namen der zu definierenden Quest an. Es darf bereits
+ eine Quest dieses Namens geben, ihre Parameter werden dann
+ geaendert.
+ questpoints gibt die Zahl der Questpunkte an, die der Spieler fuer die
+ Loesung dieser Quest angerechnet bekommt. Muss >0 sein.
+ experience gibt die Zahl der Erfahrungspunkte an, die der Spieler fuer
+ eine Quest bekommen kann. DIESE ZAHL KANN <0 SEIN!
+ allowedobj ist ein Array mit den Filenamen der Objekte, die diese Quest als
+ durch einen Spieler geloest kennzeichnen duerfen. Darueberhinaus
+ duerfen Erzmagier dies immer tun.
+ hint ist ein String, der Tips zur Loesung der Quest enthaelt. Dieser String
+ wird dem Spieler vom Orakel als Hinweis gegeben.
+ difficulty ist eine Zahl zwischen 0 und 20, die den "Schwierigkeitsgrad"
+ der Quest angibt. 0 hat eine besondere Bedeutung, naemlich die,
+ das keine Einschaetzung vorliegt.
+ needed legt fest, ob die Quest von einem Spieler geloest werden muss, be-
+ vor er Magier werden kann. Falls needed !=0 ist, MUSS er die Quest
+ loesen, unabhaengig von der 90%-Regel.
+
+RemoveQuest(string questname);
+ Gegenstueck zu AddQuest, loescht eine Quest. Kann natuerlich ebenfalls nur
+ von Erzmagiern aufgerufen werden. DIE SPIELER, DIE DIE QUEST SCHON GELOEST
+ HABEN, BEHALTEN DIE ENTSPRECHENDEN QUESTPUNKTE !!
+
+QueryReadyForWiz(object player)
+ Dieser Funktion muss ein Playerobjekt uebergeben bekommen und prueft, ob
+ der Spieler seitens der Quests bereit ist zur Aufstufung zum Magier, dh
+ ob er 90% der QP sowie alle zwingend vorgeschriebenen Quests (siehe
+ AddQuest, Parameter needed) geloest hat. Falls dies der Fall ist, liefert
+ die Funktion eine 1 zurueck. Wenn er die 90% nicht hat, eine -1. Falls
+ ihm noetige Quests fehlen, eine Liste der nicht geloesten, noetigen Quests.
+
+QueryQuest(questname)
+ Liefert eine -1, falls keine Quest dieses Names eingetragen ist, sonst
+ einen Array mit den Daten der Quest, in der Reihenfolge, in der sie in
+ AddQuest eingegeben werden. Dabei ist questpoints das erste Arrayelement.
+
+QueryAdvanceExp(object player)
+ Stellt fest, ob der Spieler player genuegend Questpunkte hat, um seine
+ Erfahrung zu erhoehen.
+
+-----------------------------------------------------------------------------
+ Weiterhin enthaelt jedes Playerobjekt ein Quest-Modul, das die folgenden
+Funktionen offeriert:
+
+GiveQuest(string questname)
+ Markiert eine Quest bei dem Player als geloest. Es wird getestet, ob die
+ Aktion von einem "allowed_object" vorgenommen wird. Die Questpunkte werden
+ entsprechend geupdated.
+
+QueryQuests()
+ Gibt eine Alist mit den Namen der vom Player geloesten Quests zurueck.
+
+QueryQP()
+ Gibt die Anzahl der vom Player erreichten Questpunkte zurueck.
+
+QueryQuest(string questname)
+ Stellt fest, ob ein Spieler die Quest geloest hat oder nicht.
diff --git a/doc/wiz/regionsleitfaden b/doc/wiz/regionsleitfaden
new file mode 100644
index 0000000..0528d02
--- /dev/null
+++ b/doc/wiz/regionsleitfaden
@@ -0,0 +1,200 @@
+
+Hallo, willkommen in den unendlichen Weiten der Regionsverzeichnisse!
+
+Du moechtest in einer Region mitprogrammieren? Prima, neue kreative
+Mitarbeiter sind jederzeit willkommen! Du bist herzlich eingeladen, mit
+Deinen Ideen zur Entwicklung beizutragen.
+
+Um die Programmierung und anschliessende Abnahme fuer alle Beteiligten
+moeglichst reibungslos zu gestalten, seien Dir die in dieser Hilfeseite
+genannten Dinge ans Herz gelegt. Diese lassen sich in folgende Kategorien
+einteilen:
+
+1) Formales zum Codestil
+2) Inhaltliche Anforderungen
+3) Was nicht akzeptiert wird
+4) Was ist vor dem Anschluss zu beachten?
+
+
+1) Formales zum Codestil
+
+o #pragma strong_types,save_types soll in allen Files verwendet werden,
+ ab Driver-Version LD_3.5.x wird auch rrtt_checks dringend empfohlen.
+
+o Der Code soll keine Zeilen mit mehr als 78 Zeichen enthalten.
+
+o Der Code soll sauber eingerueckt und sorgfaeltig formatiert sein, aber
+ bitte ohne Tabulatoren.
+
+o Verwende keine Lambda-Closures! Was auch immer Du vorhast: Es geht
+ ohne. Es sei ausdruecklich auf die Moeglichkeit von inline-Closures
+ verwiesen, wenn Du unbedingt vermeiden willst, eine separate Funktion
+ zu schreiben.
+
+o Kommentiere Deinen Code! Insbesondere dort, wo komplexere Objekt-
+ Interaktionen stattfinden, oder wo implizit besondere Eigenschaften
+ (z.B. der Mudlib, oder mathematische "Features") genutzt werden, die im
+ Code nicht auf den ersten Blick ersichtlich oder durchschaubar sind.
+ Daumenregel: "Wenn Du laenger als eine Minute ueber eine Zeile nachdenken
+ musstest, kommentiere sie." ;-) Rechne immer damit, dass jemand, der
+ Deinen Code liest, keine Ahnung hat, was Du da eigentlich tust. :-)
+
+o Wirf bitte nach Abschluss der Arbeiten Platzhalter-Code raus (z.B. leere
+ AddDetail()-Anweisungen) und entferne nicht fuer das Gebiet benoetigte
+ Dateien aus den Verzeichnissen.
+
+o Speicherung von Daten in secure-Verzeichnissen soll bitte nur sehr
+ sparsam erfolgen und nur in Abstimmung mit dem RM.
+
+o save_object() bitte sehr sparsam verwenden (nicht bei jeder Daten-
+ aenderung, bei Bedarf in reset/remove).
+
+o Wenn Defines zum Einsatz kommen, verwende sie bitte moeglichst sparsam
+ und sorge dafuer, dass Defines klar als solche erkennbar sind. Ausser in
+ Faellen, wo es gar nicht anders geht, solltest Du keine Code-Defines
+ verwenden, die mehr umfassen als einfache Funktionsaufrufe wie z.B.
+ #define TP this_player()
+ Fuer uebliche Standardfaelle existiert bereits eine Headerdatei in der
+ Mudlib unter /sys/defines.h.
+
+o Solltest Du bestimmte Ereignisse in Deinem Gebiet loggen wollen (z.B.
+ (Mini-)Questabschluesse oder besondere Kills), dann benutze bitte
+ log_file(), so dass die Logfiles nach /log/ geschrieben werden. Zusaetzlich
+ werden so erstellte Logfiles automatisch bei Erreichen einer bestimmten
+ Dateigroesse rotiert, so dass sich der Platzverbrauch in Grenzen haelt.
+ Das Protokollieren mittels write_file() in Regionsverzeichnissen unter
+ /d/ ist grundsaetzlich NICHT erwuenscht.
+ Nach Absprache KANN es fuer SELTENE und WICHTIGE Meldungen erlaubt werden,
+ mittels write_file(() nach /log/ zu schreiben.
+
+o Wenn Du in Deinem Gebiet Daten oder Code ablegst, der nicht fuer
+ jedermanns Augen bestimmt ist (Questloesungen, Gebietskarten, Savefiles
+ von questrelevanten (Master-)Objekten), solltest Du in Abstimmung mit
+ Deinem Regionsmagier ueberlegen, diese in ein ./secure/-Verzeichnis
+ zu verschieben, damit sichergestellt ist, dass auch tatsaechlich nur
+ berechtigte Magier darauf Zugriff erhalten. Denn bedenke, dass Lese-
+ und Schreibrechte nur fuer Codedateien geprueft werden, jedoch nicht
+ fuer beliebige sonstige Textdateien.
+
+o Es sei ausdruecklich auf die Manpages "goodstyle", "effizienz", etc.
+ verwiesen.
+
+
+Das soll jetzt nicht heissen, dass der Anschluss von Code kategorisch
+abgelehnt werden wird, der diese Formalien nicht erfuellt. (Ausnahme: Lambda-
+Closures werden in den Regionen nicht mehr akzeptiert.) Ich moechte aber
+wirklich nachdruecklich darum bitten, sie aus einem einfachen Grund
+einzubauen: Du wirst nicht immer der einzige sein, der Deinen Code lesen und
+warten muss, auch in Deiner Abwesenheit koennen Bugs auftreten. Und dann ist
+es wesentlich einfacher, einen Minimalstandard zu haben, der es allen
+ermoeglicht, den Code auch im MG zu lesen und dort zu fixen. Denn nicht immer
+wird es moeglich sein, sich Dateien herunterzuladen und lokal zu bearbeiten.
+
+Zum Bugfixing an dieser Stelle aus aktuellem Anlass eine Anmerkung: Es wird
+von jedem aktiven Regionsmitarbeiter erwartet, dass er einen Fehlerteufel
+(/obj/tools/fehlerteufel) besitzt und dessen Fehlerliste regelmaessig
+durchsieht und aufgetretene Fehler und Warnungen behebt. (Okt. 2007)
+
+
+2) Inhaltliche Anforderungen:
+
+o Wenn Du ein komplett neues Gebiet schreiben moechtest, das in einer Region
+ seinen Platz finden soll, sprich bitte die thematische Ausrichtung mit
+ dem RM ab, bevor Du anfaengst, Code zu schreiben. Falls von Deinen Ideen
+ irgendetwas nicht hierher passen sollte, laesst sich das mit wesentlich
+ weniger Frust im Vorfeld klaeren, als wenn hinterher das halbe Gebiet
+ umgebaut werden muesste. Sollte sich die konzeptionelle Ausrichtung
+ oder der Umfang waehrend der Programmierung grundlegend aendern, besprich
+ dies bitte kurz mit dem RM.
+
+o Ob neue oder alte Rechtschreibung, ist im wesentlichen Dir selbst ueber-
+ lassen, jedoch waere es schoen, wenn Du die Spieler-Anreden wie "frueher"
+ ueblich gross schreiben wuerdest ("Du", "Dich", "Dein").
+
+o Es muessen in jedem Raum gewisse Standarddetails vorhanden sein, z.B.
+ Boden, Decke, Waende, Himmel (Sonne, Wolken), etc. Dies kann man sehr
+ bequem mit dem "Otester" pruefen.
+ Es sei aber ausdruecklich darauf hingewiesen, dass der Otester keinesfalls
+ benutzt werden sollte, um saemtliche vorhandenen Substantive bis ins
+ kleinste zu beschreiben. Es ist schoen, wenn Objekte moeglichst voll-
+ staendig beschrieben werden, aber man sollte es auch nicht uebertreiben.
+
+o Was bitte nur in Ausnahmefaellen gemacht werden sollte, ist, Details,
+ Infos oder Lang-/Kurzbeschreibungen aus Standardraeumen zu inheriten.
+
+o Falls Du Beschreibungen/Ausgaben in ASCII-Grafik einbinden moechtest, achte
+ bitte darauf, dass Du auf jeden Fall einen kurzen Alternativtext mit-
+ lieferst und diesen ausgibst, wenn der Spieler P_NO_ASCII_ART gesetzt hat.
+ Es besteht immer die Moeglichkeit, dass Spieler mit Sehschwaeche oder
+ Blinde Deine Objekte anschauen, und diese kommen mit Objekten in reiner
+ ASCII-Grafik nicht zurecht.
+ (Siehe auch die Manpage zu P_NO_ASCII_ART und "hilfe grafik".)
+
+o Eine Anmerkung zu den Schadensarten DT_HOLY und DT_UNHOLY soll nicht
+ unerwaehnt bleiben: Es wird von vielen Spielern und Magiern als logisch
+ und atmosphaerisch nicht begruendbar empfunden, wenn Gegenstaende oder
+ NPCs diese beiden Schadensarten gleichermassen einsetzen bzw. verursachen
+ koennen. Vergleichbares gilt fuer die gleichzeitige Abwehr beider
+ Schadensarten. Wenngleich bisher diesbezueglich keine klare Einigung
+ erzielt werden konnte, soll an dieser Stelle dennoch empfohlen werden,
+ von einer gleichzeitigen Nutzung von DT_HOLY und DT_UNHOLY abzusehen.
+ Der zustaendige Regionsmagier muss aber auf jeden Fall in Kenntnis
+ gesetzt werden und entsprechende Objekte zur Pruefung vorgelegt bekommen,
+ falls diese Nutzung dennoch fuer unumgaenglich gehalten wird.
+
+
+3) Was keinesfalls akzeptiert wird
+
+o Files, die in /players liegen, incl. Headerfiles. Dies erschwert das
+ Reparieren von Bugs ungemein und bringt eine gewisse Unuebersichtlichkeit
+ mit sich. Bitte auch nichts aus /players inheriten (Ausnahmen hiervon sind
+ aufgrund eines neuen Driver-Features nur noch mit Hilfe eines Erzmagiers
+ moeglich. Kurz gesagt: es gibt eine Whitelist von Objekten, die das
+ duerfen. Alle anderen duerfen das per Default nicht.).
+
+
+4) Was ist vor dem Anschluss zu beachten?
+
+o Code muss vollstaendig fertig sein. Das heisst insbesondere, dass
+ Debug- und nicht mehr benoetigter Code entfernt wurde und dass alle
+ erforderlichen Kommentare vorhanden sind.
+
+o Abnahme durch den RM und ggf. den fuer Gesellenstuecke zustaendigen EM
+ muss erledigt sein. Regionsmagier sind angehalten, eigene Gebiete, die zum
+ Anschluss in der eigenen Region geplant sind, von anderen Magiern abnehmen
+ lassen.
+
+o Der Magier ist angehalten, das Gebiet durch Testspieler testen zu lassen
+ (siehe hierzu die Testspieler-Regeln). Ob ein Spieltest als Voraussetzung
+ fuer die Abnahme gefordert wird, entscheidet der zustaendige RM. Er kann
+ den Test auch selbst durchfuehren oder ganz darauf verzichten.
+
+o Quests und Miniquests muessen vom zustaendigen Quest-EM getestet,
+ eingetragen und aktiviert worden sein.
+
+o Feedback der Testspieler und testenden Magier sollte umgesetzt sein.
+
+o Forscherpunkte muessen vom zustaendigen EM eingetragen worden sein.
+
+o Balance-Genehmigungen (Objekte, Heilung, ggf. Gildenbalance) muessen
+ vorliegen; die genehmigten Eckparameter sollen nachvollziehbar im
+ Gebietsverzeichnis dokumentiert sein: entweder im jeweiligen File, oder
+ als Textfile z.B. in einem Doku-Verzeichnis.
+
+o Kraeuter fuer den Kraeuterskill muessen genehmigt und eingetragen worden
+ sein (dies kann jeder EM mit dem Kraeutertool erledigen).
+
+o Hinweis: Erstkills muessen NICHT ZWINGEND vom zustaendigen EM eingetragen
+ worden sein. Die Erstkill-NPCs werden automatisch in einer vorlaeufigen
+ Liste gesammelt und vom EM entweder freigegeben oder abgelehnt. Auch
+ Sonder-Stufenpunkte fuer EKs muessen nicht vor dem Anschluss beantragt
+ oder genehmigt worden sein, auch diese Eintragung laesst sich erledigen,
+ wenn der betreffende NPC das erste Mal getoetet wurde.
+
+o Auch die fuer den Ruestungsskill so beliebten Ruestungen muessen nicht
+ vor dem Anschluss eingetragen werden. Neue Ruestungen werden automatisch
+ beim zustaendigen Masterobjekt angemeldet, sobald sie das erste Mal
+ repariert werden.
+
+Und nun viel Spass bei der Programmierung!
+
diff --git a/doc/wiz/regionsmagier b/doc/wiz/regionsmagier
new file mode 100644
index 0000000..fae5f9f
--- /dev/null
+++ b/doc/wiz/regionsmagier
@@ -0,0 +1,108 @@
+
+Regionsmagier
+=============
+
+Vorbemerkung: Dieses Dokument ist nicht auf dem aktuellen Stand,
+Anregungen dazu nehme ich, Zook, gerne entgegen. Ich werde das
+Dokument dann nach und nach erweitern, berichtigen.
+
+ Hier sind einige Verhaltensregeln fuer Regionsmagier zusammengetragen. Sie
+ sollten tunlichst beachtet werden, damit es nicht zu Aerger und
+ Enttaeuschungen fuer Spieler und Magier kommt.
+
+ Einstellen von neuen Mitarbeitern:
+
+ * Man sollte dem neuen Magier *vorher* sagen, was fuer Richtlinien fuer
+ die Region gelten.
+ * Der neue Magier sollte zuerst seine Plaene erlaeutern und mit dem RM
+ absprechen, ob das in die Region passt.
+ * Zum Aufnehmen in die Region einfach ein Verzeichnis mit dem Magiernamen
+ anlegen, dann zu Merlin gehen und sagen
+
+ merlin mach <xxx> zum magier / merlin mach <xxx> zur magierin
+
+ Zum Testen von neuen Gebieten:
+
+ * Generell gilt: ERST testen, dann anschliessen.
+ * Logik beachten!
+ * Syntax von Befehlen beachten, kann der Spieler draufkommen?
+ * Objekte pruefen, genaueres siehe unten beim Punkt Balance.
+ * Jedes Monster kurz umhauen (nicht zappen), geht prima mit einem
+ entsprechend hohen Wert fuer P_HANDS. Dann `tail /log/NPC_XP' und die
+ XP-Vergabe ueberpruefen.
+ * Auch den Code anschauen, unnoetige oder schlecht programmierte Dinge
+ bemaengeln, natuerlich mit Verbesserungsvorschlag.
+ * typischer Fehler: darauf achten, ob beim Bewegen von Objekten in den
+ Spieler der Rueckgabewert von move() ueberprueft wird und die
+ entsprechenden Massnahmen ergriffen werden, wenn der Spieler nichts
+ mehr tragen kann.
+ * Bei sich bewegenden Monstern mit dem Magier besprechen, ob das wirklich
+ noetig ist, bzw. ob man den Takt verlaengern kann. Lauf-NPCs sind
+ CPU-Fresser.
+ * Vor dem Anschluss MUESSEN Forscherpunkte eingetragen werden. Das macht
+ der entsprechende Erzmagier, momentan ist das Rikus. Naeheres dazu
+ steht unter `hilfe forscherpunkte'.
+
+ Ein paar grobe Regeln zur Balance:
+
+ * Dies sind Richtlinien, die evtl. nicht mehr aktuell sind. Die aktuellen
+ Regeln, die von den Magiern befolgt werden muessen, stehen im
+ Verzeichnis `/doc/REGELN' sowie insbesondere in `/doc/wiz/balance'.
+ * gute Waffen (WC ueber 190) sollten nur selten ins Spiel kommen, das
+ heisst es sollte keine 5 NPCs auf einem Haufen mit solchen Waffen geben
+ (als Beispiel). Ausserdem sollten diese Waffen schwer zu erlangen sein.
+ * sehr gute Waffen (200 oder mehr) sollten sehr selten sein und sehr
+ schwierig zu bekommen. Extrem gute Waffen koennen ruhig existieren,
+ allerdings sollten sie dann einmalig sein (Beispiel: Hauruck).
+ * Artillerie: Gibt es schon mehr als genug, sollte eigentlich nur noch in
+ extremem Ausnahmefaellen neu reinkommen. Als Artillerie bezeichne ich
+ alles, was im Kampf zusaetzlich hilft (Flammenkugeln, Wurfsterne,
+ Eisstab).
+ * Heilung: tragbare Heilung ist generell nicht erlaubt, allerdings kann
+ man Ausnahmen machen bei entsprechenden Nachteilen, z.b. hohe
+ Saettigung, gleichzeitige Vergiftung, Abhaengigkeit ... der Fantasie
+ sind keine Grenzen gesetzt.
+ * Ausgeglichenheit: Darauf achten, dass nicht nur Mega-Monster rumlaufen,
+ sondern fuer jeden etwas dabei ist. Dabei sollten harte Monster nicht
+ ohne weiteres zu erreichen sein; man sollte spuerbaren Widerstand
+ ueberwinden muessen, bevor man sie erreicht.
+
+Programmhierhinweise: [Ergaenzung vom 2003-03-06, Zook]
+
+Bitte achtet darauf, dass beim Programmieren Eurer Regionsmitarbeiter
+gewisse Standards eingehalten werden und dass typische Fehler vermieden
+werden. Im folgenden ein paar Hinweise:
+
+ * Bei Laeden bitte darauf achten, dass nicht unnoetig "verkaufe" mit
+ einem AddCmd ueberschrieben wird, wenn statt dessen buy_obj() oder
+ sell_obj() verwendet werden kann.
+ Um Laeden besser anzupassen, kann dort auch P_GENDER, P_NAME und
+ P_ARTICLE gesetzt werden.
+ * Bei Waffen kann und sollte die Funktion "is_unsafe" verwendet werden,
+ wenn NPCs die Waffe nicht zuecken sollten. Z.B. liefert einen
+ Runenschwert bei Elfen-NPCs eine 1 zurueck, sonst eine 0.
+ * Es gibt eine Property P_PLURAL. Die sollte man auch verwenden.
+ Siehe dazu die Hilfeseite.
+ * Zum Hantieren mit Gegenstaenden stellt put&get einige komfortable
+ Funktionen zur Verfuegung: pick_obj(), drop_obj(), put_obj(),
+ give_obj().
+ Um Objekte auszuwaehlen kann find_obs() genutzt werden.
+ Prueft ein Objekt, ob es selbst gemeint ist (z.B. in einem AddCmd)
+ bitte pruefen, ob id() verwendet werden sollte.
+
+
+ Sonstiges:
+
+ * Wenn man ein Verzeichnis unter /d/<region> anlegt, muss man darauf
+ achten, dass der entsprechende Name gebanisht wird, sonst ist ein
+ Spieler der diesen Namen hat automatisch Mitarbeiter der Region (das
+ betrifft Verzeichnisse, die nicht fuer Regionsmitglieder, sondern fuer
+ andere Aufgaben gedacht sind).
+ * Ein Name wird gebanisht indem man in die Gilde geht und dort `banish
+ <name>' eingibt. Bitte keine direkten Funktionsaufrufe im master!
+
+ SIEHE AUCH:
+ forscherpunkte, balance, banish
+
+ LETZTE AeNDERUNG:
+ Don, 6. Feb 2003, 13:30:56 von Zook.
diff --git a/doc/wiz/reputation b/doc/wiz/reputation
new file mode 100644
index 0000000..6e1ac20
--- /dev/null
+++ b/doc/wiz/reputation
@@ -0,0 +1,164 @@
+THEMA:
+ Reputationen
+
+
+ALLGEMEINE BESCHREIBUNG:
+ Man kann bei einer Gruppierung/Volk/Partei/etc. Ruf gewinnen oder verlieren
+ und somit entweder deren Respekt erlangen oder auf ihrer Abschussliste
+ landen.
+
+ Am Beispiel der Goblins im Walddorf Skoga: Dort gibt es das Freie Volk, das
+ aus seinem Heimatdorf vertrieben wurde, und die Goblins, welche das Dorf
+ besetzt haben. Hilft man einer Seite, baut man Ruf auf und erhaelt
+ beispielsweise Zugang zu Heilstellen und speziellen Items, waehrend die
+ andere Seite zunehmend misstrauisch reagiert und einen schlussendlich ohne
+ zu fragen attackiert.
+
+ Es muessen nicht immer mehrere Seiten involviert sein. Auch eine einzelne
+ Partei ist denkbar, der man helfen kann und in deren Laeden/Kneipen man mit
+ steigendem Ruf z.B. Verguenstigungen, mehr Informationen, Bonusitems und
+ Aehnliches erhaelt.
+
+ Denkbar ist es auch, das Ganze zu vernetzen. Beispielsweise koennte ein
+ Verwandter eines Mitglieds von obengenanntem Freien Volk vor den Angriffen
+ ins Polargebiet umgezogen sein, aber von des Spielers Heldentaten gehoert
+ haben und ihm so freundlicher gesonnen sein.
+
+
+METHODEN (s. a. einzelne Manpages):
+
+ int ChangeReputation(string repid, int value, int silent)
+ Die Funktion ist in jedem Spielerobjekt vordefiniert.
+ Vor der Aenderung wird ein Check auf die UID des ausfuehrenden Objektes
+ ausgefuehrt, "fremde" Reputationen darf man somit nicht veraendern.
+ Man kann aber selbstverstaendlich in begruendeten Faellen mit dem
+ zustaendigen Magier/Regionsmagier sprechen, ob man ebenfalls Zugriff
+ erhaelt. Eingetragen wird dies schlussendlich durch einen EM.
+
+
+ int GetReputation(string repid)
+ Ebenfalls im Spielerobjekt vordefiniert. Liefert den aktuellen Wert der
+ angegebenen Reputation zurueck.
+
+
+ mapping GetReputations()
+ Ebenso vordefiniert. Liefert ein Mapping aller im Spieler gespeicherten
+ Reputationen und ihrer Werte zurueck.
+
+
+BEISPIELE:
+
+ // Eine kleine Aufgabe fuer das "Freie Volk" bringt dem Spieler etwas
+ // Ansehen.
+
+ void QuestGeloest(object pl) {
+ // Silent, wir geben eine eigene Meldung aus.
+ pl->ChangeReputation("freiesvolk", 250, 1);
+
+ tell_object(pl, "Du befreist einen Gefangenen. Das freie Volk wird es "
+ "Dir danken.\n");
+ }
+
+ // Ein NPC des "Schaedlspalta-Klans". Wenn er getoetet wird, verlieren die
+ // toetenden Spieler Ruf bei dieser Fraktion.
+
+ #include <properties.h>
+
+ inherit "/std/npc.c";
+
+ void create() {
+ npc::create();
+ SetProp(P_SHORT, "Ein Goblin des Schaedlspalta-Klans");
+ ...
+ }
+
+ varargs void die(int poison, int ext) {
+ object *enemies;
+ int value;
+ // Begleit-NPCs brauchen keine Reputation
+ enemies = filter(PresentEnemies(), #'interactive);
+ // 50 Reputationsabzug pro Kill, aufgeteilt auf alle Gegner
+ value = -50 / sizeof(enemies);
+ foreach(object pl : enemies) {
+ pl->ChangeReputation("schaedlspalta", value);
+ // Optional koennte ihre "Feindfraktion" das gutheissen:
+ // pl->ChangeReputation("freiesvolk", abs(value));
+ }
+ return npc::die(poison, ext);
+ }
+
+ // Jeder beteiligte Feind kriegt nun eine Meldung, die in etwa lauten
+ // koennte: "Dein Ansehen beim Schaedlspalta-Klan hat sich etwas
+ // verschlechtert." Der NPC koennte nun Spieler automatisch angreifen,
+ // sobald ihr Ruf zu tief gesunken ist:
+
+ #include <reputation.h>
+
+ void init() {
+ npc::init();
+ if(objectp(this_player()) && !IsEnemy(this_player()) &&
+ this_player()->GetReputation("schaedlspalta") <= REP_DISLIKED)
+ InsertEnemy(this_player());
+ }
+
+ // Ein NPC rueckt bestimmte Informationen erst raus, sobald das Ansehen
+ // des Spielers hoch genug ist:
+
+ #include <properties.h>
+ #include <reputation.h>
+
+ inherit "/std/npc.c";
+
+ string InfoGeheimplan();
+
+ void create() {
+ npc::create();
+ SetProp(P_SHORT, "Der Kommandant des freien Volkes");
+ ...
+ AddInfo("geheimplan", #'InfoGeheimplan, "sagt: ");
+ }
+
+ string InfoGeheimplan() {
+ if(this_player()->GetReputation("freiesvolk") < REP_TRUSTED)
+ return "Das geht Dich ueberhaupt nichts an!";
+ return "Nun, ich vertraue Dir. Also, heute um Mitternacht ... ... ...";
+ }
+
+ // Pruefung der (wichtigsten) Rueckgabewerte:
+
+ #include <reputations.h>
+
+ void QuestGeloest(object pl) {
+ string msg;
+
+ // Sonstige Meldungen
+ ...
+
+ switch(pl->ChangeReputation("freiesvolk", 500, 1)) {
+ // Reputation bereits Max
+ case REP_RET_ALREADYMAX:
+ msg = "Dein Ansehen beim freien Volk kann sich nicht mehr weiter "
+ "verbessern.";
+ break;
+ // Reputation waere hoeher als Max geworden, daher auf Max gesetzt
+ case REP_RET_SUCCESSCUT:
+ msg = "Dein Ansehen beim freien Volk hat sich etwas verbessert, "
+ "aber weiter steigern kannst Du es nicht mehr.";
+ break;
+ // Reputation erfolgreich geaendert
+ case REP_RET_SUCCESS:
+ msg = "Dein Ansehen beim freien Volk hat sich etwas verbessert.";
+ break;
+ default:
+ // Technischer Fehler
+ break;
+ }
+
+ if(stringp(msg) && strlen(msg))
+ tell_object(pl, break_string(msg, 78));
+ }
+
+SIEHE AUCH:
+
+LETZTE AENDERUNG:
+ 2009-22-03, 12:30:00 von Nibel
diff --git a/doc/wiz/rm-howto b/doc/wiz/rm-howto
new file mode 100644
index 0000000..75b9ac7
--- /dev/null
+++ b/doc/wiz/rm-howto
@@ -0,0 +1,334 @@
+RM - HOWTO
+**********
+
+Vorlaeufiges Inhaltsverzeichnis:
+
+1) Allgemeines
+ - Fehlerteufel
+ - Logtool
+ - Kommentierung von Aenderungen
+ - eigene Anschluesse
+2) Abnahme von Code/Gebieten
+ - Balance/Genehmigungen
+ - Konzeptionelle Eignung
+ - formale Pruefung
+ - Gemeinschaftsarbeiten
+3) Verlegung von Dateien
+4) Seherhaeuser
+ - Sonderwuensche/Unsichtbarkeit
+ - anderer Befehl zum Betreten
+ - Verweise auf Beispielcode
+5) Debuggen von Code
+6) besondere Funktionen/Funktionaelitaeten
+ - catch_tell() / ReceiveMsg()
+ - move()
+ - Attack() / Defend()
+ - call_out()
+ - remove() / destruct()
+ - for()-Schleifen
+ - write_file()
+ - Verwalten von charakterbezogenen Daten
+
+1) Allgemeines
+==============
+
+o Um stets einen Ueberblick ueber die in Deiner Region (hoffentlich selten)
+ auftretenden Bugs und Warnungen zu behalten, solltest Du einen
+ Fehlerteufel (/obj/tools/fehlerteufel.c) besitzen, bedienen koennen und
+ regelmaessig dessen Listen durchsehen. Deinen Regionsmitarbeitern solltest
+ Du, allein schon, um zusaetzliche Arbeit fuer Dich selbst zu reduzieren,
+ dieses Werkzeug ebenfalls an die Hand geben und sie auffordern, ihren
+ Kram moeglichst umfassend selbst zu reparieren.
+ Neuen Magiern wird dieses Tool uebrigens automatisch von Merlin in die
+ Hand gedrueckt, so dass sie sich vom ersten Tag an daran gewoehnen koennen.
+
+o Es ist empfehlenswert, das Logtool zu besitzen (/obj/tools/logtool.c) und
+ in diesem fuer jedes Repfile eines Regionsmitarbeiters einen Eintrag vor-
+ zusehen. Warum das? Es ist bereits vorgekommen, dass Spieler ernsthaft
+ argumentiert haben, sie duerften einen von ihnen entdeckten Bug ausnutzen,
+ weil sie ihn ja gemeldet haetten (im Repfile!), er aber nicht repariert
+ worden sei (was nicht verwundert, da er im Repfile in der Mehrzahl der
+ Faelle weit unterhalb des Wahrnehmungshorizonts der allermeisten
+ Regionsmagier schwebt).
+
+o Wenn Du in fremdem Code Aenderungen vornehmen musst, die mehr beruehren
+ als nur ein paar Tippfehler in Details oder Infos, dann kommentiere den
+ defekten Code aus und fuege den reparierten mit Kommentar ein. Es reicht
+ an dieser Stelle aus, Deinen Namen und das Datum zu vermerken. In den
+ Header der Datei solltest Du unbedingt ein Changelog einfuegen, in dem
+ das Datum der Aenderung, der Name des Ausfuehrenden (Deiner) sowie die
+ vorgenommene Aenderung mit Begruendung bzw. u.U. Bug-ID aus dem Fehler-
+ teufel einzutragen ist. Wir haben im MG leider keinen wirkungsvollen
+ Debugger und Bugtracker-Mechanismus, so dass wir zur Erhaltung einer
+ gewissen Code-Hygiene Bugfixes mit Hilfe solcher Eintragungen dokumentieren
+ und rueckverfolgen muessen. Insbesondere ist ein solcher Eintrag wichtig,
+ um im Falle von Folge-Bugs die Ursache schneller zu finden.
+
+o Willst Du in Deiner eigenen Region ein Gebiet anschliessen, solltest Du
+ diesen vor Anschluss entweder vom Co-RM oder von einem RM einer anderen
+ Region lesen lassen. Auch wenn Du ein guter Programmierer bist, findet ein
+ zweites Paar Augen oft Dinge, an die man nicht gedacht hat.
+
+
+2) Code wird zur Abnahme vorgelegt
+==================================
+
+o Bei Waffen und Ruestungen unbedingt auf Einhaltung der Balance-Vorgaben
+ achten.
+
+o Sofern ein Objekt eine Balance-Genehmigung besitzt, muss die BTOP-Nummer,
+ die die Balance als eindeutige ID fuer jeden Antrag vergibt, im Header
+ des betreffenden Objektes erkennbar eingetragen sein.
+
+o Vor Anschluss sollte man Ruecksprache mit verschiedenen Instanzen halten,
+ um sicherzustellen, dass der Magier alle wesentlichen Punkte
+ beruecksichtigt hat:
+ - liegen alle Balance-Genehmigungen vor?
+ - sind die FP eingetragen?
+ - sind die ZTs eingetragen und getestet?
+ - sind Sonder-EK-Stupse genehmigt und eingetragen?
+
+o Fuer neue Gebiete ist eine grundsaetzliche Pruefung des Konzepts auf
+ Regionstauglichkeit sinnvoll, damit nicht alteingesessene Institutionen
+ oder Orte ploetzlich zur zweiten Wahl abgewertet werden - beispielsweise
+ einen grossen, neuen Hauptort in der Ebene anzuschliessen, der Port Vain
+ voraussehbar den Rang ablaufen wuerde.
+
+o Alle NPCs sollten vor Anschluss einmal gekillt werden, um sie auf
+ grundsaetzliche Kampf-Funktionsfaehigkeit zu pruefen.
+
+o Haben NPCs Namen, sollte ueberlegt werden, diese Namen ggf. zu banishen.
+ (hilfe banish).
+
+o Es existiert ein Shell-Skript, mit dessen Hilfe man offensichtliche
+ Formfehler in einem kompletten Verzeichnis ermitteln kann (Umlaute im
+ Code, zu lange Zeilen etc.), wobei bezueglich der Formalien auch auf
+ den Regionsmitarbeiter-Leitfaden fuer neue Projekte verwiesen werden
+ soll. Das Skript hierzu ist auf Anfrage bei Zesstra erhaeltlich. Der
+ Regionsmagier hat hierbei die Entscheidungsfreiheit, die Berichte dieses
+ Skripts dem Programmierer des neuen Gebiets als Anhaltspunkte zur
+ Verfuegung zu stellen, oder die Abarbeitung der gemeldeten Punkte als
+ Voraussetzung vor dem Anschluss vorzuschreiben, aber auch jede Abstufung
+ dazwischen ist OK. :-)
+ Zusaetzlicher Tip: Das Skript differenziert zwischen eigentlich nicht
+ akzeptablen Konstrukten und zumindest fragwuerdigen, d.h. man kann diese
+ Unterscheidung an den Verantwortlichen mit entsprechenden Forderungen
+ weitergeben.
+ Das Skript ist unter ftp://mg.mud.de/Software/src_check/ erhaeltlich.
+
+o Sollte ein zur Abnahme anstehendes Projekt eine (grundsaetzlich
+ selbstverstaendlich zulaessige) Gemeinschaftsarbeit sein, sollte man
+ als Regionsmagier darauf bestehen, eine sauber getrennte Codebasis
+ in unterschiedlichen Verzeichnissen vorgelegt zu bekommen, oder aber
+ eine Auflistung, welcher Beitrag von welchem Magier stammt.
+ Wenn diese Auflistung sich bis auf Funktionsebene erstrecken sollte
+ (z.B. "DoWield() ist von X, Details von Y, DefendFunc von Z"), ist
+ das unschoen und an sich abzulehnen.
+
+
+3) Verlegung von Dateien
+========================
+
+o Sollte ein Objekt aus einer anderen Region bzw. allgemein aus einem
+ anderen Verzeichnis (z.B. /players) in Deine Region verlegt werden
+ muessen, sind VOR dem Umhaengen folgende Punkte zu beachten:
+ -- Forscherpunkte muessen umgetragen werden (EM ansprechen),
+ -- Erstkill-Stufenpunkte muessen umgetragen werden (EM ansprechen),
+ -- Zaubertraenke umtragen lassen (EM ansprechen),
+ -- in Padreics Ruestungsskill umtragen lassen (EM ansprechen),
+ -- evtl. im Gebiete vorhandene Seherhaeuser umziehen,
+ -- evtl. im Gebiet vorhandene Kraeuterskill-Kraeuter beruecksichtigen,
+ -- evtl. Briefempfaenger der Postquest beruecksichtigen,
+ -- ueber die Mudlib greppen lassen, um eventuell in anderen Regionen
+ verwendete Referenzen auf die alten Pfade des umziehenden Codes
+ zu finden und dort umzustellen. Hierbei sind in Ausnahmefaellen von
+ fiesem Code auch in Spielersavefiles gespeicherte Pfade zu
+ beruecksichtigen (*ARGL*).
+
+
+4) Seherhaeuser
+===============
+
+o Die Erlaubnis zum Bau eines Seherhauses in einem Gebiet haengt einzig und
+ allein von dem verantwortlichen Magier ab. Sollte dieser laenger nicht
+ erreichbar sein (auch nicht ueber externe Mail!), liegt die Entscheidung
+ beim Regionsmagier, der aber in jedem Fall die Eignung des Bauplatzes
+ in der Umgebung bewerten muss.
+
+o Fuer Sonderwuensche bezueglich Unsichtbarkeit von Seherhaeusern oder
+ besonderer Kommandos zum Betreten des Hauses sei auf die Datei
+ /doc/beispiele/misc/seherhaus.c verwiesen, wo die Vorgehensweise
+ erlaeutert wird. Ein Beispiel einer sehr umfangreichen Implementierung
+ findet sich in /d/ebene/room/hp_str8a.c.
+
+o Bei geaenderten Befehlen zum Betreten muss beachtet werden, dass bei einer
+ Standardimplementierung die Erlaube-Liste umgangen wird, d.h. ohne
+ besondere Vorkehrungen u.U. JEDER das Haus ungehindert betreten kann.
+ Es ist hingegen moeglich, die Erlaube-Liste abzufragen und entsprechend
+ zu behandeln, ein Beispiel hierfuer ist in /d/ebene/room/hp_str8a.c
+ nachzulesen (derzeit jedoch auf Spielerwunsch deaktiviert).
+
+
+5) Debuggen von Code
+====================
+
+o Nach dem Reparieren eines Objektes ist es meist erforderlich, das
+ betreffende Objekt neu zu laden. Falls es sich dabei um Objekte handelt,
+ die z.B. in einem Raum mittels AddItem() hinzugefuegt wurden (wie etwa
+ ein NPC), dann ist es am besten, die Datei mit dem Befehl
+ <upd -ad datei.c> zu aktualisieren und somit saemtliche Clones zu
+ zerstoeren. Wenn man mittels <upd -ar datei.c> die bestehenden Clones
+ ersetzen wuerde, wuerden diese aus der Item-Liste des clonenden Raumes
+ ausgetragen, so dass dieser Raum dann im reset() neue Items erzeugt und
+ diese in der Folge doppelt existieren wuerden.
+
+
+6) besondere Funktionen
+=======================
+
+Es kommt haeufig vor, dass Funktionen ueberschrieben werden muessen, und das
+ist auch normalerweise vollkommen normal und nicht beanstandenswert. Jedoch
+sollte man bei bestimmten Funktionen einiges Augenmerk auf die korrekte
+Ausfuehrung richten. Einige Beispiele sind nachfolgend aufgefuehrt:
+
+o catch_tell() / ReceiveMsg()
+ Die Reaktion von Objekten, insbesondere NPCs, auf eingehende Textmeldungen
+ laesst sich nutzen, um schoene und stimmungsvolle Gebiete mit dynamisch
+ reagierenden Bewohnern zu schaffen. Es laesst sich auf der dunklen Seite
+ der Macht hingegen auch verwenden, um ueble Konstrukte zu realisieren,
+ fuer die es seit Ewigkeiten geeignete Implementierungen gibt, und die
+ demzufolge niemals durch eine Endabnahme durch einen RM durchschluepfen
+ duerfen. Ein paar reale NPC-Beispiele aus der Praxis:
+
+ Schnipsel 1)
+
+ if (sscanf(str, " %s greift den Priester %s",name1, dummy) == 2)
+ {
+ pl = find_player(lower_case(name1));
+ if (!pl || !living(pl))
+ return 1;
+ else
+ Kill(pl);
+ }
+ Zweck: Simulation von AddDefender() und InformDefend()/DefendOther()
+ Kommentar: Absolutes No-Go! Mit Echo-Faehigkeiten von Spielern (Gilde oder
+ anderweitig) ist hiermit ein indirekter Playerkill moeglich.
+ Inakzeptable Implementierung.
+
+
+ Schnipsel 2)
+
+ if (sscanf(str, "%s sagt: %s\n", wer,was))
+ {
+ if (lower_case(was)=="ja" )
+ this_player()->move(zielraum, M_TPORT);
+ }
+ Zweck: Ausloesen eines Kommandos, ohne "sage ..." als Befehl
+ ueberschreiben zu muessen.
+ Kommentar: Ausnutzbar als Remote-Fluchtteleport, indem man die Meldung
+ mittels teile-mit an den NPC sendet:
+ "Robert teilt Dir mit: sagt: ja", was ungeprueft ein move()
+ zur Folge hat. Offensichtlich ebenso ungeeignet wie das
+ vorige Beispiel.
+
+
+ Schnipsel 3)
+
+ if (sscanf(lower_case(str),"%s sagt: %sversteck%s",s1,s2,s3))
+ tell_room(environment(),sprintf("Der Fisch sagt: Das ist aber keine "
+ "grosse Hilfe, %s.\n",capitalize(s1)),({TO}));
+
+ sieht erstmal harmlos aus, fuehrt aber mit der Anweisung
+
+ SetChats(8, ({ "Der Fisch sagt: Wo kann ich mich nur verstecken?"}) );
+
+ dazu, dass der NPC dauernd mit sich selber schwatzt. Kein kritischer Bug
+ im eigentlichen Sinn, aber auf jeden Fall der Atmosphaere im Gebiet
+ sehr abtraeglich.
+
+o move()
+ Ueberschreiben von move() ist eine extrem heikle Angelegenheit, bei der
+ beim kleinsten Fehler massive Probleme resultieren koennen, jedoch meist
+ nicht offensichtlich ist, woher das resultiert. Als allgemeine Empfehlung
+ sollte gelten, dass move() NIE ueberschrieben wird, und wenn, dann muss
+ ausfuehrlich und aufmerksam geprueft werden, was da passiert, und ob der
+ gewuenschte Effekt nicht anders sauberer erreicht werden kann.
+ Als zusaetzlicher Hinweis sei auf NotifyMove() und PreventMove() verwiesen,
+ mit deren Hilfe sich die allermeisten Faelle erschlagen lassen, in denen
+ Magier faelschlicherweise glauben, move() ueberschreiben zu muessen.
+
+o Defend()/Attack()
+ hier ist ein beliebter Fehler einfach der, dass man am Ende der Funktion
+ ::Defend() bzw. ::Attack() ruft, aber im Codeblock vorher das Objekt
+ durch eigenen Tod oder anderes schon zerstoert wurde. Dann geht das schief.
+ Einfach mal hinschauen - es ist aber kein wirklich gravierender Fehler,
+ da sowas im Kampf meist ziemlich schnell auffaellt.
+
+o call_out()
+ Hierzu zwei Hinweise: zum einen fuehrt call_out("x",0) seit der Umstellung
+ auf LDmud als Driver nicht mehr implizit zu einem call_out("x",1), wie es
+ zuvor war, sondern tatsaechlich zu einem fast sofortigen Funktionsaufruf der
+ Funktion x() - mit allen Konsequenzen, inklusive eines "too long eval"-
+ Bugs. Wer eine echte Verzoegerung braucht, muss mindestens call_out("x",1)
+ verwenden.
+ Zum anderen wurde mit LDmud die Granularitaet des reset()-Aufrufes auf
+ Heartbeat-Genauigkeit (2 s) verfeinert, so dass man bequem laengere
+ Verzoegerungen auf die Verwendung von reset() umstellen kann.
+
+o Zerstoeren von Objekten mit remove() oder destruct()
+ Man sollte einen sehr kritischen Blick auf Konstrukte werfen, die
+ nach einem remove() noch weiteren Code ausfuehren (Ausnahme: echte efuns
+ und Compiler-Konstrukte wie return).
+ Wenn man Objekte zerstoeren will oder muss, sollte man immer zuerst
+ remove() verwenden. Destruct muss dem absoluten Ausnahmefall vorbehalten
+ bleiben. Man sollte im Hinterkopf behalten, dass Objekte gute Gruende haben
+ koennen, sich einem remove() zu verweigern.
+
+o for()-Schleifen
+ Eigentlich keine Funktion, aber an dieser Stelle doch passend:
+ for()-Schleifen sollten generell durch foreach()-Konstruktionen ersetzt
+ werden, da dies signifikant und messbar schneller ist. Die naechst-
+ schnellere Variante waere etwa folgendes, sofern die Reihenfolge der
+ Abarbeitung unerheblich ist (i ist integer, arr ist ein mixed-Array):
+
+ for ( i=sizeof(arr); i--; ) {
+ tu_etwas_mit(arr[i]);
+ }
+
+o write_file()
+ Benutzung dieser Funktion nur in begruendeten Ausnahmefaellen abnehmen, da
+ keinerlei Begrenzung der Dateigroesse existiert. Insbesondere bei Logfiles
+ entstehen hierdurch im Laufe der Zeit Monsterdateien, die nur Plattenplatz
+ verbrauchen, aber kaum zu ueberschauen sind. Statt write_file() wird in
+ den allermeisten Faellen log_file() mit der Standardgroesse von 50 kB fuer
+ Logfile und eine ggf. vorhandene Altversion (*.OLD) ausreichend sein.
+
+o Verwalten von charakterbezogenen Daten
+ Als Beispiel seien hier Statusdaten fuer den Ablauf von Quests genannt,
+ oder Highscores in irgendwelchen Toplisten. Fuer die Umsetzung dieser
+ Datenerfassung werden typischerweise zwei Techniken eingesetzt. Zum
+ einen kann ein Masterobjekt erstellt werden, das die Daten sammelt und
+ mittels save_object() dauerhaft speichert. Zum anderen kann man auch
+ Daten in einer Property im Spieler ablegen und diese je nach Anwendungs-
+ fall auf SAVE setzen.
+
+ Bei der ersten Variante wird man ueblicherweise die UID oder UUID des
+ Spielers als Indizierungsmerkmal verwenden. Der erste Fallstrick ist nun,
+ dass die UID bei Spielern (nicht Sehern) ggf. nach einer Selbstloeschung
+ neu vergeben werden kann, so dass die Daten inkonsistent werden bzw. der
+ Spieler scheinbar schon in Eurem Master eingetragen ist, obwohl es sich
+ eigentlich um jemand ganz anderes handelt.
+ Als Abhilfemassnahme bietet sich folgendes an:
+ a) UUID verwenden, da diese fuer jeden Spieler eindeutig ist.
+ b) Hinweis: find_player() kann auch mit UUIDs umgehen und das zugehoerige
+ Spielerobjekt ermitteln.
+ c) Man sollte ggf. auf das Mudlib-Event EVT_LIB_PLAYER_DELETION lauschen,
+ um Spieler auszutragen, die sich loeschen, wodurch die zugehoerigen
+ Daten obsolet werden.
+
+ Bei der zweiten Variante muss man verschiedene Dinge beruecksichtigen:
+ a) nicht endlos viele Properties machen, sondern pro Thema (z.B. Quest)
+ einfach eine.
+ b) nur die Properties speichern, bei denen das wirklich noetig ist.
+ c) Speichert man Properties und die Aufgabe wird erledigt, d.h. der
+ Inhalt der Property obsolet, muss die Property wieder geloescht werden.
diff --git a/doc/wiz/ruestungen b/doc/wiz/ruestungen
new file mode 100644
index 0000000..6c7425b
--- /dev/null
+++ b/doc/wiz/ruestungen
@@ -0,0 +1,212 @@
+ RUeSTUNGEN:
+ a. Allgemeines
+
+ Auch hier gelten die aktuellen Genehmigungsgrenzwerte. Alles, was
+ diese AC-Grenzwerte uebersteigt, ist prinzipiell
+ genehmigungspflichtig. Die RMs sind gefordert, fuer eine ausgewogene
+ Bestueckung der Ruestungen in ihrem Gebiet zu sorgen. Nicht nur die
+ oberen Schutzwerte gilt es abzudecken, auch die weniger guten
+ Ruestungen sollte es geben.
+
+ Als Richtwert sollte gelten: Eine gute Lederruestung hat ca. AC 20,
+ eine stabile Jeans etwa AC 5, eine gehaertete Lederkappe AC 5. Nur
+ so als Idee...
+
+ Besonders existierende Ruestungen wie der Lichtpanzer etc. sind
+ definitiv zu gut, bzw. er ist fuer eine so leicht erreichbare
+ Ruestung zu gut. Hier sollten die RMs verstaerkt darauf achten, dass
+ nicht unbedingt der Durchschnitt der ACs bei 4/5 der Max-AC liegt,
+ sondern dass auch hier auf eine Ruestung mit hoher AC viele mit
+ niedrigerer AC kommen.
+
+ Ruestungen vom Typ AT_MISC duerfen keinerlei Veraenderungen im
+ Spieler verursachen, keine Attribute veraendern noch sonstwie
+ kampfrelevante Bedeutung besitzen oder Spieler/Gegner manipulieren.
+ Die AC solcher Ruestungen ist immer 0 und wird nicht anders ge-
+ nehmigt. Weiter duerfen solche Ruestungen nicht ueber eine Hit-
+ und/oder DefendFunc verfuegen.
+
+ b. Properties
+
+ P_WEIGHT
+ Bitte realistisch halten. Ringe mit weit ueber 100 Gramm sind
+ Schwachsinn, ebenso Hosen mit Gewichten unter 200 usw.
+ (BTW: Spieler koennen bei Max-Staerke (30) 33200 gr zzgl. etwaige
+ Trageskills der Gilde tragen.)
+
+ P_VALUE
+ Wert der Ruestungen sollte auch nicht zu gross sein und sich ein
+ wenig an der AC orientieren. Ebenfalls: RMs, schaut genau hin.
+
+ P_ARMOUR_TYPE
+ Bitte sinnvoll benutzen! Kleider als Hosen definieren oder
+ aehnliches ist unsinnig und sollte nicht genehmigt werden. Sind mal
+ wieder die RMs fuer zustaendig. Bitte achtet drauf!
+
+ Folgende Ruestungstypen sind moeglich:
+
+ AT_ARMOUR
+ Alles was irgendwie den Torso schuetzt. Also vorn und
+ hinten, wie ein Pullover, ein Kettenhemd, ein Panzer etc.
+ AT_CLOAK
+ Umhaenge, auch im weiteren Sinn wie Decken und Schleier. Im
+ Prinzip das, was normalerweise nur den Ruecken schuetzt, bei
+ Bedarf aber auch vorn herum gewickelt werden koennte.
+ AT_HELMET
+ Kopfbedeckungen jeder Art, vom normalen Hut ueber Kronen bis
+ hin zu Stirnbaendern (wenn sie schuetzen sollen)
+ AT_TROUSERS
+ Hosen. Alles was zum ueberwiegenden Teil dazu gedacht ist,
+ die Beine und/oder den Popo zu schuetzen, also auch
+ Schuerzen oder Leggins. Natuerlich gehoeren auch Badehosen
+ oder Lendenschuerze hierher. AC dann selbstverstaendlich
+ gering.
+ AT_BOOT
+ Schuhe, Stiefel und Fussbekleidungen jeder Art.
+ AT_GLOVE
+ Handschuhe oder alles, was man so zum Schutz der oberen
+ Extremitaeten benutzt, wie Armschoner, Glacehandschuhe,
+ Faeustlinge, Boxhandschuhe etc.
+ AT_QUIVER
+ Koecher und aehnliches, in denen man Munition fuer
+ Schusswaffen unterbringen kann. Schuetzen tut sowas
+ natuerlich nicht.
+ AT_SHIELD
+ Alles, was man so anstelle der eigenen Arme in einen
+ gegnerischen Schlag halten kann und das nicht offiziell als
+ Waffe deklariert ist. Es sollte nicht grade aus Papier
+ bestehen, und das Gewicht ist mit entscheidend fuer die
+ Guete des Schildes. Sie werden sehr wenig im MG genutzt, was
+ eigentlich seltsam ist. Schliesslich erreicht ein guter
+ Schild die Guete von Helm, Hose und Handschuhen zusammen
+ oder 3/4 der Qualitaet einer Ruestung. Andererseits: es gibt
+ auch nicht sehr viele Schilde. Da herrscht Bedarf!
+ AT_RING
+ Ringe. Prinzipiell sollte gelten, das Ringe praktisch keine
+ Schutzwirkung haben (also AC 1 oder max. 2). Nur, und dafuer
+ sind die Dinger da, wenn sie magisch sind koennen sie
+ zusaetzliche Funktionen haben.
+ AT_AMULET
+ Im Prinzip dasselbe wie bei AT_RING, nur werden die Dinger
+ meist an Kordeln um den Hals oder als Broschen an den
+ Klamotten getragen, koennten also je nach Groesse
+ tatsaechlich mehr Schutz bieten als ein Ring. Aber auch hier
+ gilt: AC>2 schreit nach Erklaerung und sollte magischen
+ Dingern vorbehalten bleiben.
+ AT_BELT
+ Guertel aller Art (z.B. Waffenguertel oder Magisterguertel
+ der Zauberer). Schutzwirkung hat sowas natuerlich kaum.
+ AT_MISC
+ Alles, was man sonst noch so anziehen kann, was aber eher
+ als Zierrat gedacht ist. AC immer 0. Bitte *keine*
+ Kleidungsstuecke, die in eine der anderen Kategorien passen,
+ als AT_MISC definieren. Dann lieber die AC sehr tief. Wenn
+ es eh als Gag gedacht ist koennen die Spieler sich auch bei
+ Bedarf umziehen.
+ Solche Ruestungen duerfen keinerlei (!) Bedeutung im Kampf
+ fuer den Spieler haben. Keinerlei Veraenderungen im/an
+ Spieler/Gegner verursachen oder aehnliches.
+
+ P_AC
+ siehe Tabelle weiter unten
+
+ P_EFFECTIVE_AC
+ Falls eine DefendFunc vorhanden ist und die regulaere AC veraendert,
+ sollte sie gesetzt werden. Es wird der Durchschnittswert der AC
+ incl. der DefendFunc gesetzt. Dient der Kaempfergilde zur
+ Einschaetzung.
+
+ P_DAM_TYPE
+ Auch Ruestungen koennen einen Damage-Typ haben. Nutzen tut das
+ bisher nur die Kaempfergilde, aber schaden tut's keinem. Default ist
+ DT_BLUDGEON.
+
+ P_NOBUY
+ Alle Ruestungen ab 2/3 der maximal fuer den jeweiligen Ruestungstyp
+ zulaessigen AC werden beim Verkauf im Laden einbehalten. Dennoch
+ sollten besondere Ruestungen P_NOBUY gesetzt haben. Insbesondere
+ waere das fuer alles mit DefendFuncs zu wuenschen, aber auch Sachen,
+ die als Gag gedacht sind. Dafuer koennen sich die Spieler ruhig
+ etwas recken.
+
+ c. Spezialruestungen/Ruestungen mit Sonderfunktion
+
+ Alle Ruestungen, die ueber eine DefendFunc oder aehnliches verfuegen
+ sind genehmigungspflichtig.
+
+ Prinzipiell sollten die geltenden Grenzwerte (s.u.) nicht
+ ueberschritten werden; Ausnahmen koennen unter Umstaenden genehmigt
+ werden. Immer ist der Return-Wert per random() zurueckzuliefern, da
+ der Wert ohne weiteres random() aufaddiert wird.
+
+ WearFuncs, die Restriktionen vorsehen (Geschlechtsabhaengigkeit,
+ Rassen- oder Gildenrestriktionen) sollten die RMs ueberpruefen.
+
+ Saemtliche Sonderfunktionen, wie Heilungen, Sonderattacken auf
+ Gegner, Waffenbeschaedigungen etc. muessen genehmigt werden.
+
+ Die Properties, mit denen Handschuhe 'handfrei' bzw 'fingerfrei' gemacht
+ werden, duerfen nur vergeben werden, wenn die Handschuhe den Schaden der Hand
+ nicht veraendern und die Beschreibung der Handschuhe dazu passt.
+
+
+ d. AC- und Genehmigungsgrenzen
+
+ Folgende Grenzwerte gelten derzeit:
+
+ +--------------+--------+----------------------------+
+ | Ruestungstyp | MAX_AC | Genehmigungsgrenze (inkl.) |
+ +--------------+--------+----------------------------+
+ | AT_AMULET | 2 | -- |
+ +--------------+--------+----------------------------+
+ | AT_ARMOUR | 50 | 38 |
+ +--------------+--------+----------------------------+
+ | AT_BELT | 2 | -- |
+ +--------------+--------+----------------------------+
+ | AT_BOOT | 6 | 5 |
+ +--------------+--------+----------------------------+
+ | AT_CLOAK | 10 | 8 |
+ +--------------+--------+----------------------------+
+ | AT_GLOVE | 5 | 5 |
+ +--------------+--------+----------------------------+
+ | AT_HELMET | 15 | 13 |
+ +--------------+--------+----------------------------+
+ | AT_QUIVER | 0 | -- |
+ +--------------+--------+----------------------------+
+ | AT_RING | 2 | -- |
+ +--------------+--------+----------------------------+
+ | AT_SHIELD | 40 | 28 |
+ +--------------+--------+----------------------------+
+ | AT_TROUSERS | 15 | 13 |
+ +--------------+--------+----------------------------+
+ +--------------+--------+----------------------------+
+ | AT_MISC | 0 | -- |
+ +--------------+--------+----------------------------+
+
+ e. Ruestungen fuer Zauberer
+
+ Zauberer werden normalerweise durch Ruestungen behindert. Gibt man
+ der Ruestung jedoch die in `/p/zauberer/zauberer.h' definierte ID
+ GILDEN_ROBEN_ID, behindert die Ruestung Zauberer nicht mehr. Das
+ Setzen dieser ID ist auf jeden Fall mit dem Chef der Zauberergilde
+ abzuklaeren sowie mit der Objektbalance!
+
+ Zaubererruestungen koennen ausserdem bestimmte Zaubersprueche
+ unterstuetzen, naeheres dazu ebenfalls beim Zauberergildenchef sowie
+ bei der Objektbalance.
+
+ f. Ruestungen mit sonstigen Gildenfaehigkeiten
+
+ Ruestungen, die in irgend einer Weise die Faehigkeiten der Gilden
+ spezifisch veraendern (zum Beispiel die Schadensart der Karatekas
+ oder des akshara der Tanjian veraendern) sind auf jeden Fall mit den
+ Gildenchefs der jeweiligen Gilde sowie mit der Objektbalance
+ abzusprechen.
+
+ SIEHE AUCH:
+ balance, waffen, fernwaffen, uniques, npcs, grenzwerte,
+ attributsveraenderungen, resistenzen, kampfobjekte
+
+ LETZTE AeNDERUNG:
+ 18.10.2010, Zesstra
+
diff --git a/doc/wiz/schadenstypen b/doc/wiz/schadenstypen
new file mode 100644
index 0000000..b8f0909
--- /dev/null
+++ b/doc/wiz/schadenstypen
@@ -0,0 +1,47 @@
+Schadenstypen:
+
+Es werden zwei Arten von Schadenstypen unterschieden:
+
+a) physikalische Schadenstypen
+
+ DT_BLUDGEON Schlagschaden, z.B. Keulen
+ DT_EXPLOSION Schaden durch eine Explosion
+ DT_PIERCE Stechschaden, z.B. Lanzen
+ DT_RIP Reissender Schade, z.B. Krallen
+ DT_SLASH Schnittschaden, z.B. Schwerter
+ DT_SQUEEZE Quetschschaden, z.B. Tentakel
+ DT_WHIP Peitschenschaden, z.B. Peitschen
+
+ Alle physikalischen Schadenstypen stehen auch in dem Mapping
+ PHYSICAL_DAMAGE_TYPES.
+
+b) magische Schadenstypen
+
+ DT_ACID Saeureschaden
+ DT_AIR Luft(mangel)schaden
+ DT_COLD Kaelteschaden
+ DT_FIRE Feuerschaden
+ DT_HOLY Heiliger Schaden
+ DT_LIGHTNING Blitzschaden
+ DT_MAGIC Genereller magischer Schaden
+ DT_POISON Giftschaden
+ DT_SOUND Laermschaden
+ DT_TERROR Angstschaden
+ DT_UNHOLY Unheiliger/daemonischer Schaden
+ DT_WATER Wasserschaden
+
+ Alle magischen Schadenstypen stehen auch in dem Mapping
+ MAGICAL_DAMAGE_TYPES.
+
+Eine Liste aller definierten Schadenstypen steht ausserdem in dem
+Array ALL_DAMAGE_TYPES.
+
+Alle Schadenstypen und zusammengefasste Gruppen sind definiert in
+<combat.h>
+
+Waffen duerfen maximal 50% mag. Schaden machen. Die Summe der mag.
+Schaeden darf maximal 66% betragen. Es _muss_ immer mind. ein phy.
+Schaden gesetzt sein.
+
+----------------------------------------------------------------------------
+Last modified: Mit, 03.01 12:00:54 2002 von Tilly
diff --git a/doc/wiz/scheidung b/doc/wiz/scheidung
new file mode 100644
index 0000000..d44c5d8
--- /dev/null
+++ b/doc/wiz/scheidung
@@ -0,0 +1,95 @@
+
+ Scheidung einer MG-Ehe
+ ======================
+
+ Die Hochzeit im MorgenGrauen ist ein sehr unterschiedlich durchgefuehrtes
+ Ritual, das mit der Hilfe von NPCs oder auch Spielern vorgenommen werden
+ kann. Aufgrund dieser Vielfalt muessen einige Dinge beachtet werden, wenn
+ man eine Hochzeit rueckgaengig machen will.
+
+ Da dabei auch Properties im Spieler geloescht, ggf. Logfiles editiert und
+ Objekte im Spielerinventar zerstoert werden muessen, empfiehlt es sich,
+ diesen Vorgang von einem Magier mit entsprechender Erfahrung und insbeson-
+ dere den noetigen Schreibrechten in der Unterwelt durchfuehren zu lassen.
+
+ 1) Grundsaetzliches zur Hochzeit
+
+ a) P_MARRIED:
+
+ Property im Spieler, die den Namen des Ehepartners als lowercase
+ String enthaelt (UID, z.B. "boing"). Diese Property wird von allen
+ Objekten, die eine Hochzeit durchfuehren koennen, identisch
+ verwendet.
+
+ b) Priester:
+
+ Neben Mitgliedern der Klerus-Gilde koennen Hochzeiten von folgenden
+ NPCs durchgefuehrt werden:
+ /d/unterwelt/chris/monster/priester.c (Kapelle in der Unterwelt)
+ /d/polar/files.chaos/feuerwehr/mon/cl2_xruur.c (Chaospriester)
+
+ c) Verlobungs- und Eheringe:
+
+ Als Eheringe kommen verschiedene Objekte im MG zum Einsatz:
+ /d/unterwelt/chris/objekte/ring.c (Ring vom Unterweltpriester)
+ /d/polar/files.chaos/feuerwehr/obj/cl2_ehering.c (schwarzer Dorn)
+ /gilden/files.klerus/ehering.c (Ring der Klerusgilde)
+
+ Zusaetzlich existiert noch ein Verlobungsring von Rikus:
+ /players/rikus/obj/verlring.c
+ Ein verheirateter Spieler kann diesen Ring zusaetzlich im Inventar
+ haben. Er wird bei der eigentlichen Hochzeit nicht zerstoert.
+
+ Die beiden Ehepartner sowie das Datum des Hochzeitstags werden
+ zusaetzlich zur Spieler-Property (s. 1a) als Autoload-Daten
+ in den Ringen abgespeichert.
+
+ d) Logfiles:
+
+ Je nachdem, welcher Priester die Hochzeit durchfuehrt, wird der
+ erfolgreiche Abschluss der Zeremonie in unterschiedlichen Logs
+ protokolliert.
+
+ - Die Bluthochzeit der Chaoten in
+ /d/polar/files.chaos/feuerwehr/save/BuchDerHassenden
+ - Die Hochzeit der Kleriker in
+ /log/klerus/HEIRAT
+ - Die Hochzeit in der Unterwelt-Kapelle in
+ /d/unterwelt/chris/HOCHZEITSBUCH
+ und
+ /log/hochzeiten.chris
+
+ 2) Vorgehensweise zur Aufloesung der Ehe
+
+ a) Loeschen von P_MARRIED in _beiden_ Spielern (SetProp(P_MARRIED,0))
+ und anschliessendes Speichern des Spielers
+
+ Ist der zweite Spieler netztot, kann die Property direkt gesetzt werden.
+ Sollte der zweite Spieler nicht existieren, weil er inzwischen
+ geloescht wurde, reicht es, die Property im verbleibenden Spieler
+ zu aendern (dies wird haeufig auch der Grund der Bitte um Scheidung
+ sein).
+
+ Sollte der zweite Spieler in der laufenden Uptime noch nicht eingeloggt
+ gewesen sein, kann die Property nur von einem Erzmagier mit Hilfe
+ der Funktion __create_player_dummy() zurueckgesetzt werden.
+
+ b) Zerstoeren _beider_ Eheringe. Falls jedoch von dem Ehepartner
+ kein Spielerobjekt existiert, ist es nicht moeglich, dessen
+ Ehering zu zerstoeren.
+
+ c) zerstoeren evtl. vorhandener Verlobungsringe, falls gewuenscht.
+
+ d) Im Fall von Hochzeiten, die in der Unterweltkapelle durchgefuehrt
+ wurden, ist es offenbar Tradition, dass die Scheidung dort in Form
+ eines Zusatzes zum Logfile-Eintrag nachgetragen wird. Beispiel:
+ [...] "Cassandra und Viper (ges.: Don, 02. Nov 1995, Wargon)"
+ Dies soll auch in Zukunft beibehalten werden. Fuer die Aenderung
+ sind Schreibrechte in der Region Unterwelt erforderlich.
+
+
+ SIEHE AUCH:
+ Properties: P_MARRIED
+ Klerusgilde: man traue (/doc/g.klerus/traue)
+
+Arathorn, 04.01.2010
diff --git a/doc/wiz/scoremaster b/doc/wiz/scoremaster
new file mode 100644
index 0000000..c32319f
--- /dev/null
+++ b/doc/wiz/scoremaster
@@ -0,0 +1,213 @@
+Der Scoremaster
+===============
+
+BESCHREIBUNG
+
+ Funktion: Verwaltung der Erstkill-Stufenpunkte, die fuer das Toeten von
+ NPCs vergeben werden. Fuer alle NPCs, die mehr als 200000 XP
+ (SCORE_LOW_MARK) geben, wird ein Stufenpunkt vergeben. Ab 600000 XP
+ (SCORE_HIGH_MARK) sind es 2 Stufenpunkte. Ueber diese Werte hinausgehende
+ Punkte muessen beantragt und manuell ueber den Scoremaster eingetragen
+ werden.
+
+ Jeder NPC, der mindestens einen Stufenpunkt gibt, wird automatisch in
+ eine Liste temporaerer EKs eingetragen, die vom EK-Maintainer einzeln
+ bestaetigt werden muessen. Dieses Verfahren ist erforderlich, weil der
+ bis vor einiger Zeit eingesetzte Mechanismus, EKs automatisch einzutragen,
+ dazu gefuehrt hat, dass eigentlich nicht als EK vorgesehene oder erlaubte,
+ aber auch laengst wieder abgehaengte oder gar nie angeschlossene NPCs
+ eingetragen waren. Da aus dem Scoremaster auch die von Brumni in der
+ Fraternitas ausgegebenen EK-Tips abgefragt werden, ist das natuerlich fatal
+ fuer Spieler, wenn sie Tips bekommen, die sie nicht erreichen koennen.
+
+ Die Liste der Erstkills ist ein Mapping, das als Keys eine fortlaufende
+ Nummer enthaelt, zu der jeweils die Daten des NPCs zugeordnet sind. Diese
+ Nummer dient vor allem auch zur Indizierung des Bitstrings im Spieler,
+ in dem die Erstkills gespeichert werden.
+
+ Diese Datei dokumentiert die Funktionalitaet des Scoremasters fuer die
+ Benutzung durch EM und EK-Maintainer, jedoch nicht die vollstaendige
+ interne Arbeitsweise und Verwaltung der Daten.
+
+ Inhaltsverzeichnis dieser Dokumentation
+ 1) Neueintragung von EKs
+ 2) Verwaltung der unbestaetigten EKs
+ 3) Aenderungen an bestehenden EKs
+ 4) Spielerbezogene Daten verwalten
+ 5) Daten von NPCs abfragen
+ 6) Permanentes Loeschen von EKs
+ 7) Verwaltung der EK-Tips von Brumni
+ 8) Sonstige Funktionen (nur von NPCs gerufen)
+
+
+RUECKGABEWERTE:
+
+ SCORE_INVALID_ARG -1
+ SCORE_NO_PERMISSION -2
+
+
+FUNKTIONEN
+
+1) Neueintragung von EKs
+
+ NewNPC(string key, int score)
+ AddNPC(string key, int score) [veraltet, leitet an NewNPC weiter]
+ Neuen NPC eintragen, key ist hierbei der Pfad, score die Punktzahl
+ Die ID des EKs wird automatisch ausgewaehlt, indem der naechste
+ freie Platz im Mapping belegt wird.
+
+
+2) Verwaltung der unbestaetigten EKs
+
+ ConfirmScore(mixed key)
+ unbestaetigten EK mit der Nummer oder dem Pfad "key" genehmigen
+ => EK in den Spielern setzen und Statistik hochzaehlen,
+ => EK aus der Liste der unbestaetigten EKs in die Liste der aktiven
+ uebertragen,
+
+ RejectScore(mixed key)
+ unbestaetigten EK mit der Nummer oder dem Pfad "key" ablehnen
+ => Eintrag aus der Liste der unbestaetigten EKs loeschen
+ => Bit-Nr. in die Liste der freien Nummern eintragen
+
+ DumpUnconfirmedScores()
+ unbestaetigte NPCs an den abfragenden Magier ausgeben
+
+
+3) Aenderungen an bestehenden EKs
+
+ SetScore(mixed key, int score)
+ Punktzahl fuer bereits eingetragenen NPC aendern, key ist der Pfad
+ oder die NPC-Nummer, score die neue Punktzahl
+
+ RemoveScore(mixed key)
+ Setzt die Punktzahl auf 0. Solche EKs koennen spaeter durch Angabe
+ einer neuen Punktzahl reaktiviert werden.
+ Alternativ kann fuer diese Funktion auch SetScore(mixed key, 0)
+ verwendet werden.
+ key kann hierbei der Pfad oder die NPC-Nummer sein
+
+ MoveScore(mixed oldkey, string newpath)
+ Verlegt einen EK
+ oldkey ist der aktuelle Pfad oder die Nummer
+ newpath ist der neue Pfad
+
+
+4) Spielerbezogene Daten verwalten
+
+ HasKill(mixed pl, mixed npc)
+ fragt ab, ob der Spieler "pl" den Kill "npc" hat
+ pl kann hierbei der Spielername oder das Spielerobjekt sein,
+ npc der Pfad oder dessen Nummer
+
+ SetScoreBit(string pl, int bit)
+ Mit dieser Funktion wird dem Spieler "pl" der EK mit der Nummer
+ "bit" gutgeschrieben.
+
+ ClearScoreBit(string pl, int bit)
+ Mit dieser Funktion wird dem Spieler "pl" der EK mit der Nummer
+ "bit" permanent ausgetragen.
+
+ QueryKillPoints(mixed pl)
+ liefert die Anzahl der Stufenpunkte zurueck, die dem Spieler pl
+ durch die aktiven EKs gutgeschrieben wurden
+
+ getFreeEKsForPlayer(object player)
+ liefert alle EKs, die aktiv sind, und die der Spieler noch nicht
+ hat, in einem Mapping entsprechend der Liste "npcs" zurueck.
+
+ QueryAllKills(string pl)
+ liefert alle Kills des Spielers als Bitstring zurueck, auch solche,
+ die momentan ausgetragen/deaktiviert sind
+ pl ist hierbei der Spielername als String
+
+ QueryKills(string pl)
+ liefert die aktiven Kills des Spielers als Bitstring zurueck
+ pl ist hierbei der Spielername als String
+
+
+5) Daten von NPCs abfragen
+
+ QueryNPCbyNumber(int num)
+ liefert die Daten des NPCs mit der Nummer "num" als Array zurueck
+
+ QueryNPCbyObject(object o)
+ liefert die Daten des NPCs mit dem Objekt "o" als Array zurueck
+
+
+6) Permanentes Loeschen von EKs
+
+ MarkEKForLiquidation(mixed key)
+ entfernt einen EK endgueltig und unwiderruflich und gibt die Nr.
+ wieder frei.
+ Technisch wird der EK erstmal in eine Liste eingetragen. Im Reset
+ iteriert der Master ueber alle Spieler-Savefiles und loescht den EK
+ aus allen Spielern. Nach Abschluss wird der Eintrag in "npcs"
+ geloescht und seine Nr. in die Liste freier Nummern eingetragen.
+
+ UnmarkEKForLiquidation(mixed key)
+ Entfernt die Loeschmarkierung von einem EK
+ => Dies geht nur, solange nach einem MarkEKForLiquidation() noch kein
+ reset() gelaufen ist!
+
+ QueryLiquidationMarks()
+ Fragt die fuer Loeschung vorgesehenen EKs ab.
+
+ RestoreEK(string key, int bit, int score)
+ restauriert die Daten eines frueher geloeschten, in den Spielern noch
+ enthaltenen EKs. Moeglich nur dann, wenn der EK frueher mal geloescht
+ wurde, aber in den Bitstrings in den Spielern noch eingetragen ist.
+ Es werden Pfad, Nr. und Punkte benoetigt.
+ Fuer nach dem Umbau des Scoremasters geloeschte EKs nicht mehr
+ moeglich, weil diese permanent aus den Bitstrings ausgetragen wird.
+
+
+7) Verwaltung der EK-Tips von Brumni
+
+ addTip(mixed key,string tip)
+ Traegt fuer den NPC mit der Nummer oder dem Pfad "key" einen EK-Tip-
+ Text fuer Brumni ein.
+
+ changeTip(mixed key,string tip)
+ Aendert den durch Brumni auszugebenden EK-Tip fuer den NPC mit der
+ Nummer oder dem Pfad "key". Der neue Tip wird dabei als 2. Parameter
+ "tip" uebergeben.
+
+ removeTip(mixed key)
+ Loescht den durch Brumni auszugebenden EK-Tip-Spruch. Der Tip als
+ solcher bleibt bestehen - anschliessend wird wieder der Standard-
+ Spruch ausgegeben.
+
+ getTip(mixed key)
+ Gibt den Tip-Spruch fuer den NPC mit der Nummer oder dem Pfad
+ "key" zurueck, oder den Standard-Spruch. Liefert fuer nicht
+ eingetragenen "key" den Leerstring zurueck.
+
+ QueryTipObjects(mixed player)
+ Gibt die Objektnamen der EK-Tips des jeweiligen Spielers zurueck.
+
+ allTipsForPlayer(object player)
+ Gibt den Gesamtstring aller Tips des Spielers "player" zurueck.
+
+ playerMayGetTip(object player)
+ Fragt ab, ob der Spieler "player" einen Tip bekommen kann.
+
+ giveTipForPlayer(object player)
+ Waehlt einen zufaelligen EK aus, den der Spieler noch nicht hat, und
+ traegt diesen im Master in die Liste ein, die mit allTipsForPlayer()
+ abgefragt werden kann.
+
+
+8) Sonstige Funktionen (nur von NPCs gerufen)
+
+ GiveKill(object pl, int bit)
+ schreibt dem Spieler "pl" den EK mit der Nummer "bit" gut.
+ Diese Funktion wird ausschliesslich aus NPCs heraus gerufen.
+
+ QueryNPC(int score)
+ Wird vom getoeteten NPC gerufen, um zu ermitteln, ob dieser einen
+ Erstkill gibt. Wenn der EK noch nicht existiert, wird dieser im
+ Master zunaechst in der Liste der unbestaetigten EKs eingetragen
+ Direkte Abfrage dieser Funktion von aussen z.B. durch Magier nicht
+ moeglich, weil nicht sinnvoll.
+
diff --git a/doc/wiz/seil b/doc/wiz/seil
new file mode 100644
index 0000000..4086842
--- /dev/null
+++ b/doc/wiz/seil
@@ -0,0 +1,68 @@
+
+Dokumentation fuer das Std-Seil: /obj/seil.c
+
+Abhaengigkeiten: /sys/thing/seil.h
+
+Das Standard-Seil ermoeglichst das Festbinden und Loesen eines Seiles an
+Objecten und Raeumen. Es kann im ganzen Morgengrauen verwendet werden.
+
+in den Objecten, die festgebunden werden, wird die Propertie P_TIED gesetzt.
+Sie enthaelt ein Mappng der Form:
+
+([
+
+ objectid: ([ "player" : playerid, "time" : timestamp ])
+
+])
+
+Wenn ein Object festgebunden wird, so wird die Funktion tie() in dem Object
+aufgerufen. Die Funktion muss in dem Object vorhanden sein. Liefert die
+Funktion 1 zurueck, darf man ein Seil daran binden.
+
+Aus der Funktion heraus kann im Seil in der Propertie P_TIE_USER ausgelesen
+werden, welche User die Aktion ausgeloest hat.
+(Diese Daten werden aus Kompatibilitaetsgruenden nicht an die Fkt. direkt
+uebergeben.)
+
+Wird ein Seil wieder losgebunden, so wird die Funktion
+untie()
+in dem Object aufgerufen.
+
+Damit ein Seil in einem Raum festgebunden werden kann, muss der Raum eine
+id() bekommen - wie ein normales Object.
+
+In den Funktionen tie() und untie() kann jeweils ueberprueft werden, ob ein
+Spieler ein Seil benutzen darf oder nicht. Liefern die Funktionen 0 zurueck,
+so wird die Benutzung des Seiles verweigert.
+
+Die Funktion seil->query_tied_to_ob() liefert das Object zurueck, an welches
+ein Seil gebunden ist oder 0;
+
+Bei der Benutzung eines Seiles im Raum wird zur Beschreibung die Funktion
+name() aufgerufen. Es kann also P_NAME gesetzt werden oder direkt name() im
+Raum ueberschrieben werden.
+
+Seile koennen ueber NPC's/Raeume und Zauber gesteuert werden:
+
+varargs int binde_seil(string ziel, string msg)
+
+ Ziel beschreibt das Object oder Raum, wo es festgebunden werden soll
+ msg ist die Ausgabe. Wird msg nicht gesetzt, so wird eine
+ Standard-Ausgabe ausgegeben.
+
+varargs int loese_seil(string msg)
+ Das Seil wird geloest - es wird dabei die msg in den Raum
+ ausgegeben. Ist msg nicht definiert, wird eine Standardausgabe
+ erzeugt.
+
+
+Beide Funktionen werden wir von enem Spieler behandelt - es werden tie() und
+untie() in den festgebundenen Objecten ausgewertet.
+
+Eine weitere Propertie ist P_TIE_AUTO.
+Dieser Wert steht per Default auf 1 und erlaubt damit eine automatische
+Benutzung des Seiles ueber die Funktionen binde_seil() und loese_seil().
+Ist diese Propertie auf 0, so koennen nur Spieler das Seil benutzen.
+
+
+Letzte Änderung: 25.6. Gando
diff --git a/doc/wiz/sensitive b/doc/wiz/sensitive
new file mode 100644
index 0000000..9a920a1
--- /dev/null
+++ b/doc/wiz/sensitive
@@ -0,0 +1,67 @@
+Sensitive Objekte
+
+Man kann ein Objekt mit der Property P_SENSITIVE dazu veranlassen, auf
+gewisse Dinge zu reagieren. Wenn diese Property benutzt wird, sollte sie ein
+Array von Arrays enthalten, das so aussieht:
+
+({ ({ ereignis1, key1, grenzwert1 (,Optionen1) }),
+ ({ ereignis2, key2, grenzwert2 (,Optionen2) }),
+ ...
+ ({ ereignisN, keyN, grenzwertN (,OptionenN) }) })
+
+Folgende moegliche Ereignisse sind in <sensitive.h> definiert:
+
+SENSITIVE_ATTACK - reagiert auf Angriff.
+ In diesem Fall ist der Key der Schadenstyp und der Grenzwert der
+ Schaden, ab dem die Funktion trigger_sensitive_attack() in dem Objekt
+ aufgerufen wird. Diese Funktion bekommt uebergeben:
+ 1. Den Feind
+ 2. Den Key (nicht ALLE Schadenstypen)
+ 3. Den Schaden
+ 4. Das Argument spell von Defend()
+ 5. Die Optionen, und zwar alles nach dem Grenzwert als Array.
+
+ Bemerkungen:
+ o Der Schaden nach Abzug durch Ruestungen und vor Beruecksichtigung
+ von Resistenz und Koerperschutz ist ausschlaggebend.
+ o Ein Ereignis kann mit verschiedenen Keys mehrfach angegeben
+ werden.
+SENSITIVE_INVENTORY - reagiert auf bestimmte Objekte im Inventory.
+ Ein solches Objekt reagiert auf andere Objekte empfindlich, die
+ sensitiv sind und SENSITIVE_INVENTORY_TRIGGER mit dem gleichen Key und
+ einem hoeheren Grenzwert ausloesen.
+
+ Es ist dabei egal, welches der beiden Objekte zuerst da war. In einem
+ solchen Objekt wird dann die Funktion trigger_sensitive_inv()
+ aufgerufen, und zwar mit folgenden Argumenten:
+ 1. Das ausloesende Objekt (Das mit Ereignis
+ SENSITIVE_INVENTORY_TRIGGER)
+ 2. Der Key
+ 3. Der Grenzwert des ausloesenden Objekts
+ 4. Die Optionen des ausloesenden Objekts
+ 5. Die Optionen des reagierenden Objekts
+SENSITIVE_INVENTORY_TRIGGER - siehe oben
+ Mit diesem Objekt selber geschieht nichts, es loest nur Funktionen in
+ anderen Objekten aus (siehe oben).
+
+In Planung ist noch:
+
+SENSITIVE_ENVIRONMENT_CHANGE (falls im Inventory von Lebewesen)
+
+Die Einsatzmoeglichkeiten sensitiver Objekte sind vielfaeltig:
+
+ * Dynamit koennte jetzt SENSITIVE_ATTACK mit DT_FIRE und z.B. Grenzwert
+ 150 haben, die Funktion trigger_sensitive_attack() sollte dann z.B. die
+ Zuendschnur anzuenden...
+ * Bei Nitroglycerin entsprechend mit DT_BLUDGEON, einem sehr kleinen
+ Grenzwert und einer trigger_sensitive_attack()-Funktion, die BUMM
+ macht...
+ * Es soll auch Dinge geben, die man besser NICHT gleichzeitig am gleichen
+ Ort aufbewahren sollte... Fuer solche Dinge sind SENSITIVE_INVENTORY
+ und SENSITIVE_INVENTORY_TRIGGER da.
+ * SENSITIVE_ENVIRONMENT_CHANGE ist dafuer vorgesehen, dass Objekte im
+ Inventory empfindlich auf Tauchen oder Aufenthalt an heissen Orten usw.
+ reagieren, dies ist jedoch noch in Planung.
+
+----------------------------------------------------------------------------
+Last modified: Wed May 8 10:00:28 1996 by Wargon
diff --git a/doc/wiz/sheriff b/doc/wiz/sheriff
new file mode 100644
index 0000000..4fb8366
--- /dev/null
+++ b/doc/wiz/sheriff
@@ -0,0 +1,41 @@
+Was ist zu tun, wenn ich jemanden bei einem Regelverstoss erwische?
+===================================================================
+
+ Grundsaetzlich solltet ihr den Sheriff, einen der Deputies oder
+ einen Erzmagier benachrichtigen.
+
+ Ist kein Magier aus dieser Gruppe anwesend oder sind diese nicht
+ ansprechbar, so empfiehlt sich die folgende Handlungsweise.
+
+ Sprecht den Spieler auf sein Fehlverhalten an und weist ihn darauf
+ hin, dass dies an den Sheriff gemeldet wird, damit er die
+ Gelegenheit hat seine Sicht der Situation festzuhalten und
+ ebenfalls an den Sheriff zu senden.
+ Dieser Hinweis sollte deutlich erfolgen und auch eventuelle Taub-
+ oder Blindheit beruecksichtigen, es empfiehlt sich tell_object()
+ bzw. echoto zu verwenden.
+
+ Sollte der Spieler nicht reagieren und mit seinem Verhalten andere
+ Spieler im Spiel beeintraechtigen, so sollte er nach /room/jail
+ befoerdert werden. Verwendet dazu bitte die Methode move im
+ Player, anstatt ins Jail zu gehen und ihn dann zu transen. Bei
+ letzterem setzt Ihr euch selbst fest.
+
+ Bitte seht von Zaps, Disconnects oder Aehnlichem ab, soweit andere
+ Moeglichkeiten bleiben. Bei den, durchaus nicht unueblichen,
+ obszoenen Level-1-Rufern ist ein Disconnect durchaus angebracht.
+
+ Sendet dem Sheriff eine kurze Beschreibung der Situation und was
+ Ihr unternommen habt.
+
+ Bitte ueberprueft sorgfaeltig bevor Ihr handelt, ob es sich
+ ueberhaupt um einen Regelverstoss handelt und ob die Situation
+ nicht auch ohne obige Eingriffe geklaert werden kann.
+
+
+ SIEHE AUCH:
+ leitfaden
+
+ LETZTE AeNDERUNG:
+ Wed, 30.08.2000, 11:35:00 von Muadib
+
diff --git a/doc/wiz/simul_efuns b/doc/wiz/simul_efuns
new file mode 100644
index 0000000..8670801
--- /dev/null
+++ b/doc/wiz/simul_efuns
@@ -0,0 +1,47 @@
+Allgemein nuetzliche simul_efun's:
+
+file_time(string filename) liefert die Accesstime des Files in Sekunden seit
+ 1.1.1970 (das kann man als input fuer ctime oder dtime verwenden).
+
+query_wiz_level(mixed player) bekommt einen Spielernamen oder ein Spieler-
+ Object als argument und liefert den Magierlevel (siehe auch
+ /secure/wizlevels.h)
+
+query_wiz_grp(mixed player) wie query_wiz_level, liefert aber die Magier-
+ Gruppe (auch wizlevels.h)
+
+mixed *exclude_array(mixed *arr,int from,int to) liefert den array ohne die
+ arr[0..from-1]+arr[to+1..<1]
+
+mixed *remove_alist(mixed key,mixed *alist) nimmt das Elem. mit Schluessel
+ key aus der Alist heraus.
+
+mixed *exclude_alist(int i,mixed *alist) nimmt das Element mit der Nummer i
+ aus der Alist.
+
+string dtime(int wann) wie ctime, aber deutsch (macht aus der Zahl, die time
+ usw liefern, einen lesbaren String)
+
+varags string
+ break_string(string str, int width, mixed indent, int leave_my_lfs)
+ bricht einen String um auf Weite width, man kann einen indent-String
+ angeben, der vor jeden Teilstring gehaengt wird, oder auch eine Zahl
+ dann werden entsprechen viele Leerzeichen dorthin gehaengt. Der letzte
+ Parameter legt fest, ob bereits existierende Linefeeds erhalten bleiben
+ oder nicht.
+
+string uptime() liefert genau diese in lesbarer Form.
+
+public object *all_environment(object ob) liefert einen Array mit dem re-
+ kursiven Environment (den Beutel, in dem ob steckt, den Spieler,
+ der den Beutel traegt, und den Raum, in dem sich der Spieler aufhaelt.
+
+varargs mixed match_living(string str, int players_only)
+ bekommt einen String. Falls der GENAU dem Namen eines nicht netztoten
+ Spielers entspricht, bekommt man den. Falls er genau dem Namen eines
+ Monsters entspricht und man nicht players_only!=0 angegeben hat,
+ liefert er den Namen des Monsters. Ansonsten sucht er nach einem
+ Spieler, dessen Name mit std anfaengt. Gibt es keinen, returned
+ er eine -2, gibt es mehr als einen, eine -1, bei genau einem den
+ Namen.
+
diff --git a/doc/wiz/skills.doc b/doc/wiz/skills.doc
new file mode 100644
index 0000000..685b383
--- /dev/null
+++ b/doc/wiz/skills.doc
@@ -0,0 +1,77 @@
+ Skills sind Fertigkeiten, die ein Spieler erwerben kann. Zu einem Skill koennen
+mehrere Verben gehoeren. Ausserdem kann ein Verb unter Umstaenden bei mehreren
+Skills definiert sein (zB, falls es eine Magiergilde und eine Psionkier-
+gilde gaebe, koennte es skills "magie" und "psi" geben, die beide das
+Verb "teleportiere" definieren).
+
+ Welche Skills es gibt, welche Verben dazugehoeren, welche Objekte und
+Funktionen diesen zugeordnet sind, regelt ein zentraler "Skillmaster".
+Darueberhinaus gibt es in jedem Spielerobjekt ein "Skill"-Modul.
+
+Der Skillmaster offeriert die folgenden Funktionen:
+
+InsertSkill(string skillname, string skilldescr, string *verben,
+ string *objFunDescr)
+ skillname ist (natuerlich) der Name des Skills (zB Magie).
+ skilldescr ist ein string, der den Skill naeher beschreibt, zB
+ "Magie gibt dem Anwender ein breites Spektrum von Moeglichkeiten,
+ sowohl im Kampf als auch ausserhalb."
+ verben ist ein Array, der die Verben zu dem Skill enthaelt.
+ objFunDescr ist ein Array, der dieselbe Groesse haben muss wie Verben. Jedes
+ Element ist ein 4-elementiger Array. Erstes Element dieses Arrays
+ ist ein Filename, zweites eine Funktion. Bei der Eingabe des Verbs
+ wird in dem Objekt die Funktion aufgerufen. Die dabei uebergebenen
+ Parameter werden spaeter beschrieben.
+ Drittes Element ist ein String, der die zu diesem Verb und Skill
+ gehoerende Aktion naeher beschreibt, zB:
+ "Die Magische Rakete kostet den Gegner zwischen 5 und 10 Hitpoints"
+ Das 4. Element muss eine Zahl aus [1..19] sein und gibt den Level
+ an, ab dem ein Player dieses Skillverb erwerben kann.
+ Die Funktion darf nur von Erzmagiern aufgerufen werden.
+ Es darf noch keinen Skill dieses Names geben. Falls man einen bestehenden
+ Skill lediglich erweitern moechte, muss man die Funktion AddVerbs benutzen
+ (siehe unten).
+
+RemoveSkill(skillname)
+ entfernt einen Skill wieder. ACHTUNG: Wenn Player den Skill bereits erworben
+ haben, verlieren sie ihn, wenn sie zum naechsten mal versuchen, ihn zu be-
+ nutzen.
+
+GetSkills()
+ gibt die AList mit den Skills zurueck.
+
+GetSkill(skillname)
+ liefert den entsprechenden Eintrag aus der AList zurueck.
+
+GetFunctionAndDescription(skillname, verb)
+ liefert den in AddSkill uebergebenen 4elementigen Array mit Objektname,
+ Funktionsname, Aktionsbeschreibung und Level zurueck.
+
+GetSkillDescription(skillname)
+ liefert die in AddSkill uebergebene Beschreibung des Skills zurueck.
+
+AddVerbs(skillname, mixed *verbs, mixed *objFunDescr)
+ erweitert einen bestehenden Skill um einige Verben, naehere Beschreibung
+ siehe AddSkill.
+
+-------------------------------------------------------------------------------
+Das Skillmodul im Playerobjekt bietet die folgenden Funktionen:
+
+GiveAbility(verb, skill, int promill)
+ gibt einem Spieler die Faehigkeit, das Verb verb aus dem Skill skill zu benut-
+ zen. Promill wird bei dem Versuch, das Verb zu benutzen, an das Skillobjekt
+ uebergeben und sollte die Wahrscheinlichkeit, das dem Player die Skillaktion
+ gelingt, in Promill beschreiben. Wenn der Player die Ability schon hatte, wird
+ lediglich promill geupdated.
+ Es wird eine -1 zurueckgegeben, falls eine solche Kombination aus Skill und
+ Verb (noch) nicht definiert ist, eine -2 falls der Level des Spielers nicht
+ ausreicht.
+
+GetAllAbilities()
+ gibt die AList mit den Abilities des Spielers zurueck. Schluessel in der AList
+ sind die Verben, Eintraege sind Arrays mit den Skills. Die Arrays haben so
+ viele Eintraege, wie der Player Skills hat, die das betreffende Wort
+ definieren (im Idealfall also EINEN Eintrag, naemlich wenn es keine Ueber-
+ scheidungen gibt). Die Eintraege sind wiederum 2elementige Arrays, die
+ als 1. Element den Skillnamen, als 2. Element die Promill enthalten.
+
diff --git a/doc/wiz/sqlitedb b/doc/wiz/sqlitedb
new file mode 100644
index 0000000..44a7dce
--- /dev/null
+++ b/doc/wiz/sqlitedb
@@ -0,0 +1,14 @@
+SQLite-DBs im Morgengrauen
+
+Im MG koennen Objekte sqlite-Datenbanken verwenden.
+Die notwendigen efuns dafuer sind sl_open, sl_close, sl_exec, sl_insert_id.
+
+Hat man das Speicherfile (Savefile) der DB, kann man dieses mit dem Kommando
+sqlite3 auf einer Shell auch direkt abfragen:
+
+Auf der Shell fragt man die DB recht simpel so ab:
+sqlite3 -column -header <pfad_zur_db>
+
+Alles aus einer Tabelle anzeigen, wo eine Spalte einen bestimmten Wert hat:
+select * from <tabelle> where <spalte>='abc';
+
diff --git a/doc/wiz/teamkampf b/doc/wiz/teamkampf
new file mode 100644
index 0000000..4cfc934
--- /dev/null
+++ b/doc/wiz/teamkampf
@@ -0,0 +1,113 @@
+
+Teamkampf im MorgenGrauen
+=========================
+
+Zum Teamkampf im MG gehoeren zwei Objekte: Das Lebewesen, das im Team ist,
+sowie das Teamobjekt. Ersteres erbt seine Funktionalitaet aus
+
+/std/living/team.c
+
+das Teamobjekt ist ein clone von
+
+/obj/team.c
+
+Allerdings sollte man immer das #define fuer diesen Pfad nutzen, welches
+in /sys/living/team.h definiert ist: TEAM_OBJECT
+
+Darueberhinaus gibt es in diesem Verzeichnis noch den Teammaster.
+
+
+Alle relevanten Funktionen und Properties sind im Teammitglied abrufbar und
+liefern Informationen ueber den Teamkampf.
+
+
+UEBERSICHT ueber die Properties und Funktionen des Teamkampfs
+=============================================================
+
+Properties des Teammitglieds:
+----------------------------
+P_TEAM - Teamobjekt
+P_TEAM_NEWMEMBER - Spieler moechte ins Team hiervon aufgenommen werden.
+P_TEAM_ATTACK_CMD - Angriffsbefehl des Spielers, nicht setzbar.
+P_TEAM_AUTOFOLLOW - Folgewunsch des Spielers, nicht setzbar.
+P_TEAM_WANTED_ROW - Gewuenschte Reihe des Spielers.
+P_TEAM_WIMPY_ROW - Fluchtreihe des Spielers.
+P_TEAM_LEADER - Spieler ist Anfuehrer dieses Teams.
+P_TEAM_ASSOC_MEMBERS - Alle zugeordneten NPCs bzw. der Spieler dem dieser
+ NPC zugeordnet ist.
+P_TEAM_COLORS - Grenzwerte fuer farbige Anzeige.
+
+Funktionen des Teammitglieds:
+----------------------------
+TeamPrefix() - "[Team Teamname] " falls Teammitglied, "" sonst.
+IsTeamLeader() - Test ob Spieler Anfuehrer eines Teams ist.
+IsTeamMove() - Test ob Angriffsbewegung gerade ausgefuehrt wird.
+TeamMembers() - Teammitglieder.
+PresentPosition() - Aktuelle Reihennummer des Spielers.
+PresentTeamPositions() - Reihennummern aller anwesenden Teammitglieder.
+PresentTeamRows() - Reihen aller anwesenden Teammitglieder.
+PresentEnemyRows() - Reihen aller anwesenden Feindteams zusammen.
+SelectNearEnemy() - Waehlt direkt angreifbaren Feind aus.
+SelectFarEnemy() - Waehlt Feind aus hinteren Reihen aus.
+InsertEnemyTeam() - Macht alle Mitglieder von Team des Feindes zu
+ Feinden aller Mitglieder des eigenen Teams.
+AssocMember() - Assoziiert einen HilfsNPC mit einem Spieler.
+DeAssocMember() - Hebt Assoziation zwischen NPC und Spieler auf.
+TeamFlee() - Spieler wird veranlasst in Fluchtreihe zu wechseln.
+
+Funktionen des Teamobjekts:
+--------------------------
+SwapRows() - Spieler tauschen die Reihen
+
+
+BEISPIEL:
+ Man moechte von einem Spieler, welcher sich in einem Team befindet, alle
+ Teammitglieder sowie deren Anzahl ermitteln, die VOR diesem Spieler stehen.
+
+ Im abfragenden Objekt muss man zunaechst die Headerdatei des Teamkampfs
+ includen:
+
+ #include "/sys/living/team.h"
+
+
+ void fun( object pl )
+ {
+ int act_row,all;
+ mixed *rows;
+ object team,*team_members;
+
+ team=pl->QueryProp(P_TEAM); // liefert das Teamobjekt
+
+ act_row=pl->PresentPosition(); // aktuelle Position ermitteln
+
+ team_members=({});
+
+ if ( objectp(team) && (act_row > 1) )
+ {
+ rows=team->PresentRows(ENV(pl)); // die Reihen werden als mixed-array
+ // uebergeben
+
+ foreach ( int i : act_row )
+ team_members+=rows[i]; // die Reihen werden komplett ins
+ // neue Array uebertragen
+ }
+
+ all=sizeof(team_members); // Anzahl der Teammitglieder, die
+ // vor dem Spieler stehen
+ }
+
+
+SIEHE AUCH:
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: AssocMember, DeAssocMember, InsertEnemyTeam
+ SelectNearEnemy, SelectFarEnemy
+ Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+ PresentTeamPosition, SwapRows
+ Sonstiges: TeamPrefix, teamkampf_intern
+
+----------------------------------------------------------------------------
+Last modified: 16-08-2010, Gabylon
diff --git a/doc/wiz/teamkampf_intern b/doc/wiz/teamkampf_intern
new file mode 100644
index 0000000..79c2963
--- /dev/null
+++ b/doc/wiz/teamkampf_intern
@@ -0,0 +1,127 @@
+
+Teamkampf-Interna
+=================
+
+Verwaltung der Kampfreihen
+--------------------------
+
+Die Umordnung der Teammitglieder wird durch die Formation gesteuert.
+
+ formin[reihe] - Minimale Anzahl von Teammitgliedern in dieser Reihe
+ formax[reihe] - Maximale Anzahl von Teammitgliedern in dieser Reihe
+
+Die Funktion CheckFormation() passt die Werte so an, dass sie bei Anwesenheit
+aller Teammitglieder erfuellbar sind, wobei ggf. der Maximalwert vorne
+anfangend erhoeht wird und der Minimalwert hinten anfangend verringert wird.
+Dabei ist der Minimalwert der ersten Reihe 1.
+
+Es ist zwischen der Teamaufstellung und der Raumaufstellung zu unterscheiden.
+Die Teamaufstellung ist die Aufstellung, in der die Mitglieder angeordnet
+waeren, wenn alle anwesend waeren. In der Teamaufstellung ist durch die
+Funktion MakeFormation() sichergestellt, dass die Minimal- und
+Maximalanforderungen erfuellt sind.
+Die Raumaufstellung ergibt sich aus den anwesenden Mitgliedern der
+Teamaufstellung. Sollten die Minimalanforderungen einer vorderen Reihe nicht
+erfuellt sein, werden anwesende Mitglieder aus den hinteren Reihen IN DER
+RAUMAUFSTELLUNG nach vorne geschoben soweit noetig.
+
+Vor Verschiebungen und bei Updates der TEAMAUFSTELLUNG werden die Arrays mit
+den Mitgliedern jeder Reihe sortiert, wobei die gewuenschte Reihe der
+Mitglieder das groesste Gewicht (125) im Sortierkriterium hat und die Anzahl
+der Lebenspunkte einfach eingeht. Solange die Teammitglieder unter 250 LP
+haben, kann ein Mitglied mit wenigen LP hinter einem mit vielen LP einsortiert
+sein, der EINE Reihe weiter hinter stehen will, aber nicht zwei oder mehr.
+Wird es noetig, Mitglieder aus einer Reihe in eine andere zu verschieben,
+werden Mitglieder vom Anfang des Arrays nach vorne verschoben (an das Ende
+des davorliegenden Arrays) bzw. Mitglieder vom Ende des Arrays nach hinten
+(an den Anfang des dahinterliegenden Arrays). Dadurch werden immer die
+Mitglieder mit dem staerksten Drang nach vorne an die Front geschickt :-)
+
+Wenn jemand die Reihe wechselt und dabei die Minimalanforderung der Quellreihe
+unterschritten oder die Maximalanforderung der Zielreihe ueberschritten wird,
+wird mit CycleRows() rotiert. Kommt ein neues Mitglied hinzu und die
+Maximalanforderung seiner gewuenschten Reihe wuerde ueberschritten, wird
+in AddToRow() zunaechst versucht ein Mitglied eine Reihe vorzuschieben, falls
+da noch Platz ist, sonst eine Reihe zurueck, falls da noch Platz ist (die
+Anzahl der Mitglieder also < formax ist). Wird ein Mitglied entfernt oder
+gewaltsam entfernt und wuerde dabei die Minimalanforderung seiner Reihe
+unterschritten, wird in RemoveFromRow() versucht, ein Mitglied aus der
+nachfolgenden Reihe nach vorne zu holen, falls dort Ueberschuss vorhanden ist
+(in der nachfolgenden Reihe also mehr Mitglieder als formin sind), sonst aus
+der vorangehenden Reihe, falls dort Ueberschuss ist.
+
+Sollten diese Umordnungen nicht ausreichen die Formation in der
+TEAMAUFSTELLUNG einzuhalten, wird die Formation mit MakeFormation() erzwungen.
+Dies wird in zwei Durchlaeufen erreicht. Der erste Durchlauf wird von vorne
+nach hinten durchgefuehrt. Ist das Maximum einer Reihe ueberschritten, werden
+soviele Mitglieder nach vorne geschoben wie in der davorliegenden Reihe freie
+Plaetze sind und die restlichen ueberschuessigen Mitglieder nach hinten. Sollte
+das Minimum einer Reihe unterschritten sein, werden soviele Mitglieder aus den
+nachfolgenden Reihen hergeholt, wie zum Erreichen des Minimums noetig ist. Der
+zweite Durchlauf wird von hinten nach vorne ausgefuehrt. Falls das Minimum
+einer Reihe unterschritten wird, werden Mitglieder aus den davorliegenden
+Reihen geholt soweit noetig, wenn jedoch Ueberschuss vorhanden ist, wird
+dieser nach vorne geschoben.
+
+BEISPIEL:
+
+Formation 3-6 2-2 1-2 0-6 1-1 (bloedsinnige Formation ;-)
+
+1. Durchlauf (vorne beginnend):
+
+ 1 1 6 1 0
+ <---- (Minimum Reihe 1 unterschritten)
+ 3 0 5 1 0
+ <-- (Minimum Reihe 2 unterschritten)
+ 3 2 3 1 0
+ --> (Maximum Reihe 3 ueberschritten)
+ 3 2 2 2 0
+
+2. Durchlauf (hinten beginnend):
+
+ 3 2 2 2 0
+ --> (Minimum Reihe 5 unterschritten)
+ 3 2 2 1 1
+
+Ergebnis entspricht der gewuenschten Formation. Ermittlung der RAUMaufstellung:
+
+ 2 0 2 1 1 (Anwesende aus der vorangegangenen TEAMaufstellung)
+ <----
+ 3 0 1 1 1
+ <----
+ 3 2 0 0 1
+ <----
+ 3 2 1 0 0
+
+Ergebnis erfuellt Minimalanforderungen zumindest vorne, Maximalanforderungen
+koennen nicht ueberschritten werden, weil die Raumaufstellung hoechstens
+soviele Mitglieder wie die Teamaufstellung hat.
+
+
+Abarbeitung des Angriffsbefehls und Verteilung der Begruessungsschlaege
+-----------------------------------------------------------------------
+Das Grundprinzip ist folgendes:
+Wenn das ganze Team bewegt wird, werden die Begruessungsschlaege unter
+Vorbehalt weggelassen. Sobald alle Teammitglieder bewegt wurden, macht
+jedes Monster, das noch einen Begruessungsschlag ausfuehren muss, einen
+Schlag auf EIN Teammitglied das im Nahkampf erreichbar ist und der Vorbehalt
+wird fuer alle Mitglieder aufgehoben. Wenn ein Teammitglied versucht
+sich zu bewegen und noch ein Begruessungsschlag unter Vorbehalt fehlt,
+wird dieser noch vor der Bewegung nachgeholt.
+
+
+SIEHE AUCH:
+ Uebersicht: teamkampf
+ Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
+ P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
+ P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
+ Bewegung: IsTeamMove, TeamFlee
+ Mitglieder: IsTeamLeader, TeamMembers
+ Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
+ SelectNearEnemy, SelectFarEnemy
+ Positionen: PresentPosition, PresentRows, PresentEnemyRows,
+ PresentTeamPosition, SwapRows
+ Sonstiges: TeamPrefix
+
+----------------------------------------------------------------------------
+Last modified: 16-08-2010, Gabylon
diff --git a/doc/wiz/techniken b/doc/wiz/techniken
new file mode 100644
index 0000000..5defd59
--- /dev/null
+++ b/doc/wiz/techniken
@@ -0,0 +1,111 @@
+****************************************************************************
+* Dieser Text ist veraltet. Die Techniken werden von der Mudlib nicht *
+* ausgewertet und momentan auch von keiner Gilde (Ausnahme: die Tanjian *
+* zeigt sie an, tut aber nix damit. *
+****************************************************************************
+----------------------------------------------------------------------------
+ Techniken, mit denen Waffen eingesetzt werden koennen
+----------------------------------------------------------------------------
+
+TQ_THRASH - "Schlagtechnik"
+
+ Die vom Verstaendnis her einfachste Technik: Man nehme sich einen
+ Gegenstand, der gross genug ist und halbwegs brauchbare Dichte
+ besitzt - also nicht gerade federleicht fuer seine Groesse ist -
+ und haue drauf. Egal ob Henkersaxt, Stock, Stuhl, Bierflasche
+ (ganz), Knueppel, Keule oder Bratpfanne, das und aehnliches sind
+ brauchbare 'Waffen', um mit dieser Technik Erfolg zu haben. Es
+ ist eine schlagende Bewegung, also das gewollte schwunghafte Zu-
+ sammenfuehren zweier Koerper, fuer gewoehnlich Waffe und Gegner.
+
+
+TQ_THRUST - "Stosstechnik"
+
+ Auch diese Technik erfreut sich zumindest in Kneipenschlaegereien
+ grosser Beliebtheit: Das Stossen. Mit einem vorzugsweise spitzen
+ Gegenstand wie Speer, Dolch, Bierflasche (zerbrochen) oder Helle-
+ barde wird dem Gegner ein Loch in den Leib gestossen, im Falle
+ eines stumpfen Gegenstandes wie z.B. einem Kampfstock oder dem
+ eigenen Zeigefinger oder Knoechel zielt man auf Vitalpunkte oder
+ Weichteile und erzielt auch damit beeindruckende Ergebnisse. Das
+ Gewicht der Waffe ist weniger von Bedeutung, da der Akteur bei
+ einem korrekt ausgefuehrtem seine eigene Masse mit einsetzt.
+
+
+TQ_STROKE - "Streichtechnik"
+
+ Ein etwas eigenwillig anmutender Begriff, aber bei genauerer Be-
+ trachtung hat diese Technik tatsaechlich etwas mit Streicheln zu
+ tun: Die wichtigste Komponente der Bewegung fuehrt mehr oder we-
+ niger am Gegner _entlang_ und nicht auf ihn zu. Man stelle sich
+ ein Schwert vor, das geschmeidig durch die Kehle eines Orks glei-
+ tet und eine Menge Blut freisetzt oder ein Pergamentblatt, das
+ man aus der Hand gezogen bekommt (und ebenfalls eine Menge Blut
+ freisetzt). In den allermeisten Faellen ist also eine moeglichst
+ scharfe Schneide im Spiel und, auch wenn schmerzhafte Erfahrungen
+ mit Pargamentkanten gelegentlich gegenteiliges vermuten lassen,
+ je schaerfer die Schneide, desto weniger Druck in Richtung feind-
+ lichen Zielkoerper muss fuer einen "durchschneidenden Erfolg"
+ ausgeuebt werden.
+
+
+TQ_WHIP - "Peitschtechnik"
+
+ Unter der Peitschtechnik wird nun alles zusammengefasst, was den
+ Umgang mit beweglichen Elementen an der Waffe betrifft. Egal, ob
+ Peitsche a la George Lucas, neunschwaenzige Katze, Manriki-Gusari
+ (eine halbmeter lange Kette mit Gewichten an den Enden), ein- bis
+ dreikoepfigem beketteten Morgenstern oder gar Dreschflegel, sie
+ sind zumindestteilweise sehr unterschiedlich konzipiert (so fehlt
+ der Peitsche am aeusseren Ende das Gewicht, so dass jenes durch
+ eine gegenlaeufige Bewegung beschleunigt werden muss), haben aber
+ eines gemeinsam: Der Schaden wird durch ein ueber die normale Be-
+ wegung des Kaempfers hinaus beschleunigtes Teil der Waffe verur-
+ sacht. Durch jene Beweglichkeit der Waffe wird ein sehr grosses
+ Mass an Koordinationsvermoegen vom Kaempfer abverlangt.
+
+----------------------------------------------------------------------------
+
+Vermischtes
+
+ - Waffen koennen sich fuer mehrere Techniken eignen. Mit einem
+ Katana, dem Schwert der Samurai, beispielsweise kann man in die
+ ungeschuetzten Partien des Gegners stechen, dem Gegner mit der
+ Streichtechnik tiefe Schnitte in die Unterseiten der Arme (ein
+ durch typische Samurairuestungen schlecht geschuetzter Bereich)
+ zufuegen, und mit der beruehmten halben Koerperdrehung dem in-
+ zwischen taumelndem Kontrahenten den Kopf abschlagen.
+
+ - Waffen koennen sich, obwohl von der gleichen Gattung, fuer ver-
+ schiedene Techniken eignen. Ein spitzer Dolch mag eine stumpfe
+ Klinge haben und nur fuer ausschliesslich stossende Praktiken
+ zu gebrauchen zu sein, waehrend ein abgerundetes Kuechenmesser,
+ ebenfalls vom Typ "Zyn", fuer kantiges Zuschlagen und eventuell
+ auch fuer schnittige Streichtechniken herhalten kann.
+
+ - Je nach Zweck und Koennen wird die beste zu verwendende Technik
+ variieren: Wenn es um arme Grashalme geht, wird die Sense mit
+ schneidenden Bewegungen gefuehrt (schoen in der Milka-Werbung
+ zu sehen, fuer die, die es partout nicht glauben wollen), bei
+ einer Bauernrevolte mag das gute Stueck jedoch auch mit anderen
+ Techniken effektiv (und vielleicht sogar effektiver) eingesetzt
+ werden, wer weiss, wer war schon dabei...? Selbst bei normalen
+ Waffen wie Schwertern wuerde ein Ungeuebter selten versuchen,
+ mit Streichtechniken Schaden zu verursachen, denn das Zustechen
+ ist schlicht einfacher.
+
+ - Es wird immer besondere Waffen geben. So sind beispielsweise
+ das Zweililien und die Hellebarde beide dem Typ "Kzrok" (fuer
+ nicht-Trves: Stangenwaffen) zuzuordnen, die Techniken weichen,
+ bedingt durch die Vielseitigkeit der Waffen, jedoch von der
+ Norm ab: Das Zweililien, an jedem Ende eine lange und scharfe
+ Klinge, kann ebenso vielseitig gehandhabt werden wie ein
+ Schwert, waehrend die Hellebarde (eine Mischung aus Lanze und
+ Axt) durch ihre unausgewogene Gewichtsverteilung und dem damit
+ verbundenen Potenzial an Schwung schlichtweg DIE Waffe der Wahl
+ fuer feige Zwerge ist: Schwingen wie eine grosse Axt und den
+ Gegner auf Distanz halten koennen. Gut, dass es keine feigen
+ Zwerge gibt ;o)
+
+----------------------------------------------------------------------------
+Last modified: Tue Apr 13 13:00:00 2000 by Anatol
diff --git a/doc/wiz/testspieler b/doc/wiz/testspieler
new file mode 100644
index 0000000..b7fc2f8
--- /dev/null
+++ b/doc/wiz/testspieler
@@ -0,0 +1,40 @@
+
+Testspieler
+===========
+
+ TESTSPIELER:
+ Testspieler sind Zweitcharaktere von Magiern, die auch gleichzeitig mit
+ dem Magier eingeloggt sein duerfen. Sie muessen entsprechend markiert sein
+ (siehe unten) und duerfen auch ruhig vom Magier manipuliert werden.
+
+ TESTSPIELER UNTERLIEGEN VOLL DEN REGELN DES MAGIERVERTRAGS!
+
+ Testspieler werden hauptsaechlich dann gebraucht, wenn Objekte oder
+ Gebiete wirklich aus Spielersicht getestet werden sollen und das
+ Abschalten des Magiermodus dazu nicht ausreicht. Ein anderes Einsatzgebiet
+ ist das Testen von Meldungen oder Aktionen, die nicht nur den
+ Ausfuehrenden selbst betreffen, sondern z.B. auch umstehende Personen in
+ einem Raum.
+
+ GILDENTESTSPIELER:
+ Sofern eine Gilde das Anlegen von Testspielern unterstuetzt, gibt es
+ entsprechende Hilfeseiten unter "hilfe <gildenname>.testspieler".
+
+ MARKIEREN:
+ Ein Testspieler wird durch setzen der Property P_TESTPLAYER markiert. Es
+ reicht zwar aus, diese Property einfach auf einen Wert != 0 zu setzen,
+ aber man sollte hier lieber den Namen des Magiers eintragen, zu dem der
+ Testie gehoert.
+
+ Einige Magier markieren ihre Testspieler nicht, und zwar mit der
+ Begruendung, dass dann Todesmeldungen nicht ausgegeben werden. Das ist
+ allerdings keine Ausrede mehr, das Testspieler-Todesmeldungen auf -TdT
+ ausgegeben werden.
+ Sind nichtmarkierter Testspieler entsprechend manipuliert, koennte es
+ passieren, dass sie wegen Schummelei geloescht werden...
+
+ SIEHE AUCH:
+ zweitspieler, vertrag, mschau, P_TESTPLAYER
+
+ LETZTE AeNDERUNG:
+ 19. Maerz 2004 Gloinson
diff --git a/doc/wiz/todesfallen b/doc/wiz/todesfallen
new file mode 100644
index 0000000..5585032
--- /dev/null
+++ b/doc/wiz/todesfallen
@@ -0,0 +1,355 @@
+Manpage zu Todesfallen. Technischer Leitfaden.
+
+
+Diese Manpage richtet sich an (Jung)magier, die Todesfallen nutzen wollen,
+um verschiedenste Dinge in ihren Gebieten damit zu erreichen. Dabei soll hier
+nicht diskutiert werden, wo welche Art von Todesfalle Sinn macht (oder auch
+nicht), sondern es sollen technische Aspekte bei der Programmierung einer
+solchen (Todes)falle aufgezeigt werden.
+
+
+Kapitel 1. Das Umfeld einer Todesfalle.
+
+Eine Todesfalle kann wie in spaeteren Kapiteln beschrieben, leicht umgesetzt
+werden. Damit sie sich auch so verhaelt wie sie soll, werden hier einige
+Sicherheitsaspekte behandelt, die durchgegangen werden sollten.
+
+
+Kapitel 1.1 Wer hat die Todesfalle ausgeloest?
+
+Die meisten Todesfallen werden durch ein Kommando ausgeloest, welches der
+Spieler ausfuehrt. Z.B.
+ druecke grossen roten knopf mit der aufschrift "todesfalle ausloesen"
+In diesem Fall existiert in der aufgerufenen Funktion die Moeglichkeit, ueber
+die Funktion this_player() den aktuell "gueltigen" Spieler auszufischen.
+Hierbei ist zu beachten, dass auch NPCs von dieser Funktion zurueckgegeben
+werden koennen. Auch im init() eines Raumes wird in this_player() der Spieler
+zurueckgegeben. Hierbei ist jedoch zu beachten, dass man immer schauen sollte,
+ob this_player() auch tatsaechlich ein Objekt zurueckliefert. Dies ist
+wichtig, da das init() (oder auch andere Funktionen) durch Gegenstaende, wie
+den Bumerang ausgeloest werden koennen. In diesem Fall steht in this_player()
+ueblicherweise kein Objekt. Die Sicherheitsabfrage sollte also wie folgt
+aussehen:
+
+ object spieler;
+ spieler = this_player();
+ if (spieler) // Ein Lebewesen?
+ {
+ ...
+ }
+ // else: Die Falle nicht ausloesen, da kein Lebewesen.
+
+
+Kapitel 1.2 Wer soll die Todesfalle nicht ausloesen?
+
+Oft kommt es vor, dass eine schoene Todesfalle von Gott und der Welt
+ausgeloest wird. Normalerweise moechte man aber nicht, dass "Gott" oder andere
+besondere Personengruppen diese Falle ausloesen. In den folgenden
+Unterkapiteln werden Abfragen gezeigt, um Personengruppen auszuschliessen.
+
+
+Kapitel 1.2.1 Todesfallen, die nicht auf Geister reagieren.
+
+Ueblicherweise sollen Todesfallen bei den Ausloesern Schaden verursachen. Bei
+Geistern laeuft dies jedoch ins Leere. Man koennte nun auf die Idee kommen,
+alternativ auf Geister zu reagieren.
+
+
+Kapitel 1.2.1.1 Nicht auf Geister reagieren.
+
+Angenommen, man hat einen Spieler (siehe oben), der im Begriff ist, die Falle
+auszuloesen. Man sollte nun pruefen, ob er ein Geist ist. Falls er kein Geist
+ist, kann man wie gewuenscht (Todesfalle) reagieren. Falls nicht, sollte man
+eine passende Meldung ausgeben. Z.B. "Als Geist hast Du nicht die notwendige
+Kraft, diesen Knopf zu druecken." Die technische Abfrage, ob ein Spieler ein
+Geist ist, sieht wie folgt aus.
+
+ if (!spieler->QueryProp(P_GHOST))
+ {
+ // ist _kein_ Geist, also Todesfalle.
+ }
+ else
+ {
+ // Alternativer Text, da Geist.
+ }
+
+
+Kapitel 1.2.1.2 Geister entgeistern.
+
+Da ausschliesslich die Rassenstartraeume entgeistern sollen, wurde dieser
+Punkt herausgenommen. Also: Es ist unerwuenscht, Geister zu entgeistern, um
+eine Todesfalle korrekt auszuloesen.
+
+
+Kapitel 1.2.1.3 Alternative fuer Geister.
+
+Rollenspieltechnisch gesehen macht es in den allerwenigsten Faellen Sinn,
+alternativ auf einen Geist zu reagieren. Der Vollstaendigkeit halber sei diese
+Loesung trotzdem erwaehnt. Ein Programmbeispiel sollte ohne grosse Muehe durch
+die schon vorhandenen Beispiele erstellt werden koennen.
+
+
+Kapitel 1.2.2 Gaeste und kleine Spieler.
+
+Rollenspieltechnisch macht es oft keinen Sinn, auf Gaeste oder kleine Spieler
+anders zu reagieren, als auf "den Rest". Moechte man jedoch einen besonderen
+Schutz fuer kleine Spieler einbauen ("Du hast zu grosse Angst, diesen grossen,
+roten Knopf zu druecken.") oder moechte man Gast-Sterbe-Testern den Hahn
+zudrehen (die Weicheier!), so sind folgende Abfragen unter Umstaenden
+sinnvoll.
+
+ // Gast?
+ if (spieler->QueryGuest())
+ {
+ // Ist ein Gast...
+ }
+ else
+ {
+ // Todesfalle. Kein Gast.
+ }
+
+ // Kleiner Spieler?
+ // In diesem Beispiel Abfrage des Spielerlevels.
+ if (spieler->QueryProp(P_LEVEL) < 10)
+ {
+ // Spielerlevel < 10 haben zuviel Angst.
+ }
+ else
+ {
+ // Spielerlevel >= 10 koennen hier ruhig die Todesfalle ausloesen.
+ }
+
+
+Kapitel 1.2.3 Magier
+
+Ueblicherweise sind Magier unsterblich und soll(t)en auch nicht
+(versehentlich) Todesfallen ausloesen. Dies ist vor allem dann der Fall, wenn
+"zufaellig" im gleichen Raum stehende Spieler Meldungen bekommen wuerden und
+dadurch gewarnt werden. Die technische Umsetzung, dass Magier Todesfallen
+nicht ausloesen, sieht wie folgt aus. Die Abfrage beruecksichtigt
+"mschau aus". Das heisst, Magier koennen sterben, wenn sie mschau aus gemacht
+haben.
+
+ #include <wizlevels.h>
+
+ if(IS_LEARNER(spieler) && spieler->QueryProp(P_WANTS_TO_LEARN))
+ {
+ // Magier: Man soll ihm mitteilen, dass er diese Aktion als Magier nicht
+ // tun darf.
+ }
+ else
+ {
+ // Kein Magier. => Todesfalle.
+ }
+
+
+Kapitel 1.3 Wichtige Punkte einer nicht sinnfreien Todesfalle.
+
+Eine Todesfalle ist, wie in Kapitel 2 gezeigt, eigentlich eine einfache Sache.
+Kombiniert mit den schon gezeitgten Sicherheitsabfragen hat man ueblicherweise
+ein gueltiges Opfer. Allgemeine Dinge, wie beispielsweise "Das Opfer sollte
+ein environment haben" werden hier uebergangen und nur die wesentlichen Dinge
+genannt, die beim potentiellen Toeten eines Spielers von Belang sind.
+
+
+Kapitel 1.3.1 Wo ist der Spieler?
+
+Ganz wichtig bei Todesfallen ist die Frage, wo sich der Spieler befindet.
+Wird eine Todesfalle in init() ausgeloest, dann befindet sich der Spieler
+schon in dem entsprechenden Raum, dessen init() nun ausgefuehrt wird. Das
+bedeutet, wenn der Spieler stirbt, sind seine Sachen zunaechst einmal in dem
+betreffenden Raum. In seltenen Faellen spielt es wirklich eine Rolle, wo sich
+der Spieler befindet und er hat eigentlich immer ein environment, in das seine
+Leiche dann kommt. Dennoch sollte man bei Todesfallen testen, wo sich der
+Spieler befindet. Wenn der Spieler die Falle im Vorraus oder von woanders
+ausloesen kann, dann macht es nicht immer Sinn, die Falle tatsaechlich
+auszuloesen oder dem Spieler den Effekt "zuzumuten".
+Eine einfache Abfrage, ob sich der Spieler im gleichen Raum befindet, sieht so
+aus:
+
+ if (environment(spieler) && (environment(spieler) == this_object()))
+ {
+ // Spieler hat ein environment und das environment ist dieser Raum.
+ }
+
+
+Kapitel 1.3.2 Wer toetet den Spieler?
+
+Ueblicherweise toetet man einen Spieler mit den in Kapitel 2 genannten
+Moeglichkeiten. In diesen Moeglichkeiten ist das toetende Objekt der Raum.
+Da aber nun der Raum keinen Namen hat, muss man diesem Raum einige Properties
+setzen, die ueblicherweise erst einmal nur NPCs haben. Die Properties regeln,
+"wer" in Kampfmeldungen, Angriffen und Todesmeldungen als Angreifer oder
+Killer steht. Setzt man diese Werte direkt vor der Ausfuehrung einer
+Todesfalle, dann kann man mehrere Todesfallen in einem Raum mit verschiedenen
+Meldungen versehen.
+
+ SetProp(P_NAME, "Ein gleissender Feuerball"); // Der Angreifer-Name
+ SetProp(P_KILL_NAME, "Ein gleissender Feuerball");
+ // Name fuer den Todeskanal.
+
+
+Kapitel 1.4 Gimmicks
+
+Der Vollstaendigkeit halber soll noch erwaehnt werden, dass man in der
+Property P_ENEMY_DEATH_SEQUENCE das File einer (eigenen) Todessequenz ablegen
+kann.
+
+
+Kapitel 2 Technische Umsetzung von Todesfallen.
+
+Den Tod durch oder den Angriff auf einen Spieler mittels einer Todesfalle kann
+man auf verschiedene Weise bewerkstelligen. Die wichtigsten Moeglichkeiten
+werden in den folgenden Unterkapiteln kurz erlaeutert. Es wird ausserdem auf
+einige technische Feinheiten eingegangen, die zu beachten sind.
+
+
+Kapitel 2.1 Tod durch die()
+
+Die einfachste Moeglichkeit, einen Spieler sicher sterben zu lassen, ist der
+Aufruf von die(). Die spaeter genannten Moeglichkeiten mit Ausnahme des
+Faketods bewirken letztendlich auch einen Aufruf von die(), sollte der Spieler
+sich nicht ausreichend dagegen geschuetzt haben. Bei dem direkten Aufruf kann
+sich der Spieler nicht dagegen wehren. (Ausnahme: Geist sein, siehe oben.)
+Die technische Umsetzung sieht wie folgt aus. Eventuelle Parameter fuer die()
+sind der manpage fuer die() zu entnehmen.
+
+ spieler->die(); // Jetzt ist der Spieler tot.
+
+
+Kapitel 2.2 Todesfalle mit do_damage()
+
+Die zweite Form der Todesfalle ist nicht ganz so aggressiv, wie die erste.
+Hier wird dem Spieler eine feste oder zufaellige Zahl an Schadenspunkten
+zugefuegt. Der erlittene Schaden ist dabei nicht von Ruestung oder sonstigem
+Schutz abhaengig, sondern der Schaden betraegt dem uebergebenen Wert. Ist der
+uebergebene Wert hoeher als die Zahl der Lebenspunkte des Spielers, so stirbt
+der Spieler. Nachlesen kann man dies in der manpage zu do_damage().
+Diese Form der Todesfalle ist vermutlich die am haeufigsten verbreitete, da
+der Magier am einfachsten die Konsequenzen ueberblicken kann, ohne den Spieler
+zwingend zu toeten. Wichtig bei dieser Umsetzung ist, dass der Spieler keine
+Angriffsmeldung oder dergleichen sieht. Er bekommt hoechstenfalls mit, dass er
+ueberhaupt Schaden erhalten hat. Daher sollte vor dem Zufuegen des Schadens
+eine Meldung ausgegeben werden, die dem Spieler anzeigt, weshalb er Schaden
+bekam. (Bsp. "Ein Feuerball rast auf Dich zu und trifft Dich.")
+Die technische Umsetzung sieht wie folgt aus:
+
+ tell_object(spieler, "Ein Feuerball trifft Dich von hinten.\n");
+ spieler->do_damage(10, this_object());
+ // Spieler erhaelt genau 10 Schadenspunkte und
+ // stirbt, wenn er dadurch unter 0 HP kommt.
+
+Kapitel 2.2.1 Angepasste Todesfalle mit do_damage()
+
+Moechte man, dass die Staerke der Todesfalle abhaengig vom Spieler ist, dann
+kann man den in do_damage() uebergebenen Schaden abhaengig vom Spieler machen.
+Dies ist in Gebieten sinnvoll, in denen Anfaenger und groessere Spieler
+gleichermassen gefordert sein sollen (z.B. Quest). Folgendes Beispiel zeigt,
+wie man eine Todesfalle macht, die dem Spieler etwa 1/4 seiner maximalen HP
+abzieht.
+
+ spieler->do_damage(spieler->QueryProp(P_MAX_HP) / 4);
+
+
+Kapitel 2.3 Todesfalle mit reduce_hit_point
+
+Mittels reduce_hit_point() ist es moeglich, eine nicht toedliche "Todes"-Falle
+zu entwickeln. Dies kann genutzt werden, wenn man eine eigentlich toedliche
+Falle machen will, die Auswirkungen eines Todes dem Spieler gegenueber aber zu
+aggressiv waeren. Hierbei ist zu beachten, dass ein negativer Wert eine
+Heilung bewirken wuerde. Daher ist zuvor eine Sicherheitsabfrage zu machen.
+Wie bei do_damage() ist eine Meldung auszugeben, da reduce_hit_point eine
+solche nicht generiert. Alles zusammen saehe der Part wie folgt aus:
+
+ int schaden;
+ tell_object(spieler, "Ein Feuerball trifft Dich.\n");
+ // Hier den Schaden berechnen;
+ // Z.B. schaden = 3;
+ if (schaden < 1) schaden = 1; // Es soll mindestens 1 Schadenspunkt geben!
+ spieler->reduce_hit_point(schaden);
+
+
+Kapitel 2.4 Faketode
+
+Faketode sind keine Tode im eigentlichen Sinn, da der Spieler von den
+meisten negativen Auswirkungen verschont bleibt. Ein Faketod ist im Grunde
+keine komplizierte Sache und eignet sich hervorragend fuer Anfaengergebiete.
+Verschiedenen Auspraegungen (Bsp. Gibt es eine Leiche mit der Ausruestung des
+Spielers oder behaelt er die Ausruestung?) gemein ist die Tatsache, dass der
+Spieler augenscheinlich gestorben ist, jedoch kein die() aufgerufen wird. Es
+werden todesbedingt also keine Attribute abgezogen, die Erfahrungspunkte
+bleiben unangetastet usw, usf.
+Die technische Umsetzung sieht wie folgt aus. Dabei ist zu beachten, dass der
+Spieler Geist werden muss. Zuvor sollte wie bei den vorhergehenden Methoden
+der Kill-Name etc. gesetzt werden.
+
+ spieler->SetProp(P_GHOST,1);
+ clone_object("/room/death/death_mark")->move(spieler);
+
+
+Kapitel 2.4.1 Bedingte Faketode.
+
+Man kann die Technik von Kapitel 2.3 mit den Faketoden kombinieren, indem man
+testet, ob der Spieler auf oder unter 0 Lebenspunkte kommen wuerde, wenn man
+anstatt reduce_hitpoint do_damage() machen wuerde und dann zusaetzlich zum
+Abziehen der LP noch einen Faketod ausfuehrt. Dabei sind zwei Dinge zu
+beachten:
+Erstens sollte man keine zwei Meldungen ausgeben, also der Spieler sollte
+keine zwei Feuerbaelle auf sich zufliegen sehen, obwohl nur einer da ist.
+Zweitens sollte man nicht vergessen, dem Spieler dennoch die LP abzuziehen,
+weil der Spieler ansonsten nach dem Entgeistern anstatt 1 LP noch soviele hat,
+wie vor dem Feuerball-Angriff.
+Die technische Umsetzung dieser Kombination wird an dieser Stelle nicht naeher
+erlaeutert, da das Vorgehen aus den vorigen Kapiteln klar ist.
+
+
+Kapitel 2.5 Angriff mittels Defend()
+
+Eine realistische, wenn auch teilweise heikle Moeglichkeit fuer eine
+Todesfalle ist der Aufruf der Defend()-Funktion des Spielers. Der Vorteil
+von Defend ist, dass man unter Angabe der korrekten Parameter den Schutz der
+Ruestungen eines Spielers oder auch die Gildenfaehigkeiten beruecksichtigt
+werden. Daraus folgt, dass der als Beispiel verwendete Feuerball von einem vor
+Feuer schuetzenden Objekt abgeschwaecht wuerde. Anwendungstechnisch gibt es
+erst einmal keine Probleme, sofern einige wichtige Punkte beachtet werden, auf
+die hier nun eingegangen wird. Einziger Nachteil besteht nur in der mangelnden
+Erfahrung der einzutragenden Schadenswerte, da diese nicht 1:1 an die
+Schadenspunkte gekoppelt sind, die an den Spieler weitergereicht werden.
+Die technische Umsetzung fuer den Angriff eines Spielers durch eine Todesfalle
+ueber Defend sieht wie folgt aus:
+
+ #include <new_skills.h>
+
+ int schaden;
+ schaden = 500+random(500); // Diese Werte machen u.U. viel Schaden.
+
+ spieler->Defend(
+ 100,
+ DT_FIRE,
+ ([
+ SP_SHOW_DAMAGE:0,
+ SP_PHYSICAL_ATTACK:1
+ ]),
+ this_object()
+ );
+
+Wichtig sind hierbei folgende Punkte:
+ 1. Man sollte SP_SHOW_DAMAGE:0 im Mapping angeben, wenn man die Meldung
+ z.B. "Ein Feuerball trifft Dich von hinten.\n" selbst ausgeben will.
+ Tut man dies nicht, muss im Raum zusaetzlich P_GENDER, P_NAME, etc.
+ auf einen sinnvollen Wert gesetzt werden, beispielsweise P_GENDER auf
+ MALE und P_NAME auf "Feuerball".
+ 2. SP_PHYSICAL_ATTACK:1 sollte gesetzt werden, wenn des Spielers Ruestung
+ fuer die Verteidigung beruecksichtigt werden soll. Genaueres findet man
+ auf der Manpage von Defend().
+ 3. this_object() sollte immer angegeben werden, damit der Raum der
+ Angreifer ist, anstatt ein nicht naeher bestimmtes Objekt. Dies koennte
+ dann beispielsweise der Spieler selbst sein, was dazu fuehrt, dass im
+ Falle eines Todes der Spieler als Killer von sich selbst genannt wird,
+ anstatt "Ein Feuerball".
+
+
+
+
+----------------------------------------------------------------------------
+Last modified: Wed Feb 13 17:00:54 2002 by Bambi
diff --git a/doc/wiz/todessequenz b/doc/wiz/todessequenz
new file mode 100644
index 0000000..0ab03e8
--- /dev/null
+++ b/doc/wiz/todessequenz
@@ -0,0 +1,115 @@
+Eine Todessequenz ist eine ganz normale Textdatei mit folgendem Aufbau:
+In der ersten Zeile steht die Dauer der Todessequenz in heart_beat-Einheiten.
+Es folgen Eintraege der Form <zeit>:<text>. <zeit> ist dabei der Zeitpunkt
+(ebenfalls in heart_beat-Einheiten), in denen der Text <text> ausgegeben
+werden soll. <text> kann sich dabei auch ueber mehrere Zeilen erstrecken;
+Leerzeilen werden 1:1 uebernommen.
+
+Beispiel:
+---- <snip> ----
+70
+1:Vor Dir tut sich ein tiefer, schwarzer Abgrund auf. Ein starker Sog
+versucht, Dich hineinzuziehen.
+
+2:Du balancierst muehsam auf dem Rand des Abgrundes, doch dann wird der
+Sog zu stark!
+
+3:Du faellst! Um Dich herum ist nur noch tiefe Schwaerze.
+... usw.
+---- <snip> ---
+
+Um die Todessequenz ein wenig abwechslungsreicher zu gestalten, kann man
+einige Platzhalter verwenden. Man kann Meldungen einbauen, die abhaenig sind
+
+- vom Geschlecht: dies geht mit <G>mText:wText</G>. mText wird bei maennlichen
+ Toten eingebaut, wText bei weiblichen. Man kann auch einen der Texte weg-
+ lassen; der Doppelpunkt ist jedoch Pflicht!
+ Beispiel:
+ 5:Der Tod sagt: KOMM MIT MIR, STERBLICHE<G>R:</G>!
+ 6:Der Tod sagt: WAR WOHL NIX, <G>BUERSCHCHEN:FROLLEINCHEN</G>!
+
+- von der Rasse: Dies geht aehnlich wie beim Geschlecht, und zwar in der Form
+ <R>dText|mText|eText|zText|hText|fText</R>.
+ mText wird bei Menschen ausgegeben, eText bei Elfen, zText bei Zwergen,
+ hText bei Hobbits, fText bei Felinen und dText bei allen anderen
+ (zB. Magier mit selbst gesetzten Rassen).
+
+ Wie bei geschlechtsabhaengigen Meldungen koennen auch hier einzelne Texte
+ weggelassen werden.
+
+ Beispiel:
+ 1:Der Tod sagt: SCHOEN GESTORBEN, <R>FREMDLING|MENSCHLEIN|SPITZOHR|DREIKAESEHOCH</R>?
+ 2:<R>||Der Tod sagt: ELFEN WAREN SCHON LANGE NICHT MEHR HIER!|</R>
+
+- vom Charakter: Der Charakter eines Spielers kann sich im Bereich von -1000
+ (satanisch) bis +1000 (heilig) bewegen. Zwischen <A> und </A> kann man
+ charakterabhaengige Meldungen einbauen. Die Abstufungen werden dabei in der
+ Form ##<Untergrenze>## angegeben, wobei <Untergrenze> die untere Grenze des
+ Charakterwertes ist, ab dem die Meldung ausgegeben wird.
+ Der Text direkt nach <A> entspricht einer Untergrenze von -1000, die
+ weiteren Texte sollten in aufsteigender Reihenfolge angegeben werden.
+ Beispiel:
+ 7:<A>
+ Der Tod sagt: AH, EIN SATANIST!
+ ##-999##
+ Der Tod sagt: SO EIN<G>:E</G> SCHLIMME<G>R:</G>!
+ ##0##
+ Der Tod sagt: EIN TYPISCHES UNENTSCHIEDEN...
+ ##1##
+ Der Tod sagt: SO EIN<G>:E</G> LIEBE<G>R:</G>!
+ ##1000##
+ Der Tod sagt: OH, GUTEN TAG, EUER HEILIGKEIT!
+ </A>
+
+- von der Zahl der Tode: Dies geht aehlich wie beim Charakter, allerdings
+ ist der Platzhalter hier <D>...</D>. Die Untergrenze fuer den ersten Text
+ ist 1 (sonst waere der Spieler ja nicht hier ;)
+ Beispiel:
+ 8:<D>
+ Der Tod sagt: SCHOEN, DICH AUCH MAL HIER ZU SEHEN!
+ ##2##
+ Der Tod sagt: MACH DIR NIX DRAUS, DAS PASSIERT SCHON MAL!
+ ##20##
+ Der Tod sagt: WAS, DU SCHON WIEDER?
+ ##50##
+ Der Tod sagt: NOCH EINMAL, UND ICH BEHALTE DICH ENDGUELTIG HIER!
+ </D>
+
+- vom Level: Auch hier erfolgt die Auswertung wie beim Charakter, allerdings
+ zwischen den Platzhaltern <L> und </L>. Die Untergrenze fuer den ersten
+ Text ist 0.
+ Beispiel:
+ 8:<L>
+ Der Tod sagt: MACH DIR NICHTS DRAUS.
+ ##5##
+ Der Tod sagt: VIELLEICHT SOLLTEST DU DAS NAECHSTE MAL BESSER AUFPASSEN!
+ ##15##
+ Der Tod sagt: SO WIRST DU NIE SEHER ODER MAGIER!
+ ##20##
+ Der Tod sagt: NUR EIN TOTER SEHER IST EIN GUTER SEHER! ;)
+ </L>
+
+- vom Zufall: Und noch mehr Abwechslung... ;) Der Aufbau ist aehnlich dem der
+ vorherigen. Zwischen den Platzhaltern <Z=wert> und </Z> stehen Meldungen der
+ ##x##text, wobei die x die relative Wahrscheinlichkeit (bezogen auf wert)
+ angeben, mit der der Text text ausgegeben wird.
+ Die x sollten zusammengezaehlt wert ergeben! Die Reihenfolge ist zwar
+ prinzipiell egal, aus Performancegruenden sollte man die Texte aber mit
+ absteigender Wahrscheinlichkeit anordnen.
+ Beispiel:
+ 9:<Z=6>
+ ##3##
+ Dieser Text wird in 50% aller Faelle ausgegeben (3/6)
+ ##2##
+ Dieser Text in 33% aller Faelle (2/6)
+ ##1##
+ Und dieser Text in 17% aller Faelle (1/6)
+ </Z>
+
+Ausserdem kann man noch den Namen des Toten einbauen, und zwar mit <n> in
+normaler Schreibweise, und mit <N> in GROSSbuchstaben.
+Beispiel:
+ 10:Du schaust in den Spiegel und siehst: <n>!
+ 11:Der Tod sagt: HALLO, <N>!
+
+
diff --git a/doc/wiz/topliste b/doc/wiz/topliste
new file mode 100644
index 0000000..a39efc6
--- /dev/null
+++ b/doc/wiz/topliste
@@ -0,0 +1,33 @@
+Fuer die Verwaltung der Standardtoplisten gibt es /secure/topliste, welches (zur Zeit) bei Login bei toplisten-willigen Spielern die toplisten-relevanten Daten vom Spieler abfragt und in einer Tabelle eintraegt.
+
+Abfragen laesst die Liste jederzeit wie folgt durch Aufruf folgender Funktionen in /secure/topliste: Liste, SpielerListe, SeherListe und HardcoreListe.
+
+Die 4 sind varargs und bekommen folgende moegliche Argumente:
+* string rasse
+ Nur Spieler der Rasse <rasse> beruecksichtigen
+* string gilde
+ Nur Spieler der Gilde <gilde> beruecksichtigen
+* int limit
+ Max. <limit> Eintraege, Default: 100, Max: 100
+* string sort
+ Liste sortieren nach: lep, qp, xp, age, wizlevel, hardcore, gilde, rasse,
+ name
+ Default: lep
+
+Die Funktionen liefern ein Array zurueck, was fuer jeden Eintrag in der Topliste wieder ein Array enthaelt: < <string|int>* >*
+
+Beispiele:
+# /secure/topliste->Liste()
+ Die 100 Chars mit den meisten Stufenpunkten
+# /secure/topliste->HardcoreListe(0,0,10)
+ Die 10 HC-Chars mit den meisten Stufenpunkten
+# /secure/topliste->Liste(0,"kaempfer",10,"xp")
+ Die 10 Kaempfer-Chars mit den meisten XP
+# /secure/topliste->Liste("Zwerg","zauberer")
+ Die 100 Zwergenzauberer mit den meisten Stufenpunkten
+Weiteres koennt ihr euch ja sicher denken.
+
+Achso, das Ergebnis sieht dann ungefaehr so aus:
+({ ({name, lep, qp, xp, level, age, rasse, gilde, wizlevel, hardcore}), ... })
+({({"hcplay",100,0,0,1,62,"Mensch","abenteurer",0,1})})
+
diff --git a/doc/wiz/transporter b/doc/wiz/transporter
new file mode 100644
index 0000000..a3f001c
--- /dev/null
+++ b/doc/wiz/transporter
@@ -0,0 +1,19 @@
+DEFINIERT IN:
+ "/std/transport"
+ "/sys/transport.h"
+
+BEMERKUNGEN:
+ Zu Transportern gibt es ein Beispiel unter
+ '/doc/beispiele/misc/bsptransporter1.c' und auch die verwendeten
+ Properties sind dokumentiert.
+
+ Um einen Transporter zu aktivieren, muss er in das Preload-File der
+ Region geschrieben werden, oder aber ueber eine Funktion im Start-
+ und Zielraum aufgerufen werden, die das erledigt.
+
+SIEHE AUCH:
+ P_ARRIVEMSG, P_DEPARTMSG, P_ENTERMSG, P_LEAVEMSG, P_LEAVEFAIL,
+ P_ENTERFAIL, P_MAX_PASSENGERS, AddRoute, AddMsg, Start
+ /d/inseln/schiffe/HowTo
+----------------------------------------------------------------------------
+Last modified: Wed Dec 26 14.43:07 2001 by Tilly
diff --git a/doc/wiz/uniques b/doc/wiz/uniques
new file mode 100644
index 0000000..c507ff8
--- /dev/null
+++ b/doc/wiz/uniques
@@ -0,0 +1,42 @@
+
+ UNIQUES
+
+ Sogenannte "uniques" sind Objekte, die nicht in beliebiger Anzahl im Mud
+ vorhanden sein koennen, sondern von denen es entweder nur eins oder eine
+ begrenzte Anzahl gibt. Beispiele fuer uniques sind der bekannte Voll-
+ strecker des Weghiers oder die gruenen Roben aus dem Schemenreich.
+ Die Begrenzung auf wenige Objekte hat normalerweise den Sinn, besondere
+ Eigenschaften oder aussergewoehnliche Staerke zu rechtfertigen. Bei
+ einigen Objekten passiert dies auch aus logischen Gruende, weil das
+ Objekt einfach einzigartig ist.
+
+ Fuer uniques gelten folgende Richtlinien:
+
+ - Die Erreichbarkeit des/der uniques darf nicht vom Reboot abhaengen.
+ Das bedeutet, ein Spieler muss waehrend der gesamten Uptime die
+ theoretische Moeglichkeit haben, ein bestimmtes Objekt durch welchen
+ Aufwand auch immer zu erreichen.
+
+ - Das Objekt muss auch gegen den Willen des bisherigen Besitzers zu
+ bekommen sein.
+
+ - Sollte das Objekt in Umlauf sein, muss an der Fundstelle ein Hinweis
+ darauf existieren, dass dieses Objekt dort zu bekommen ist. Auch wenn
+ fanatische Spieler ein Unique 5 Sekunden nach Reboot wegscripten,
+ sollten nachfolgende Spieler wenigstens wissen, wo es mal gewesen ist.
+
+ Uniques, die aufgrund ihrer Werte nicht genehmigungspflichtig sind, sollten
+ sich trotzdem an diese Richtlinie halten. Uniques ohne jegliches Konzept,
+ die der Balance vorgelegt werden, haben jedoch kaum Chance auf Genehmigung.
+
+
+ SIEHE AUCH
+
+ balance, ruestungen, waffen, fernwaffen, npcs, grenzwerte,
+ attributsveraenderungen, resistenzen, kampfobjekte
+
+
+------------------------------------------------------------------------------
+ LETZTE AeNDERUNG:
+ Don, 31.10.1999, 20:00:00 von Nachtwind
+
diff --git a/doc/wiz/vertrag b/doc/wiz/vertrag
new file mode 100644
index 0000000..1abc68a
--- /dev/null
+++ b/doc/wiz/vertrag
@@ -0,0 +1,128 @@
+
+Herzlich willkommen im Kreis der Magier!
+
+Ab jetzt kannst Du hinter die Kulisse des MorgenGrauens schauen.
+Diese Faehigkeit birgt Verantwortung.
+
+Deshalb gelten ab jetzt zusaetzlich zu den bisherigen Regeln folgende
+Magierregeln fuer Dich:
+
+Man darf Spielern keine Hilfen geben, es sei denn, es liegt ein
+*offensichtlicher* Fehler vor. Dabei zaehlt auch ein Zweitspieler,
+mit dem ein Magier spielt, zu den Spielern!
+Haelt der Sheriff einen Extra-Charakter eines Magiers nicht fuer einen
+echten Zweitie, kann er ihn jederzeit zum Testspieler erklaeren.
+
+Beispiele fuer nicht erlaubte Hilfen:
+- Stats von Monstern mitteilen.
+- Objekte clonen, und Spielern geben.
+- Objekte schreiben, die den Spielern zu sehr helfen, oder umgekehrt
+ die Spieler schaedigen.
+- Spieler teleportieren.
+- Explizite Kommandos angeben, die ein Spieler eingeben muss.
+- Selber (oder mit Zweitcharakteren) mitspielen oder -kaempfen, sobald
+ Insiderwissen in Anwendung kommt. Hier ist der gesunde Menschenverstand
+ bei der Entscheidung gefragt, ab wann dies der Fall ist.
+- Raeume resetten, damit die Spieler Objekte bekommen.
+ (Insbesondere kann das Nebeneffekte haben, die man als normaler
+ Magier nicht ueberschauen kann, ausserdem koennen die Spieler auch mal
+ warten.)
+- Weitergabe von Objektinformationen, die der Spieler nicht einsehen kann.
+
+In den folgenden Faellen darf natuerlich geholfen werden:
+- Spielern aus fehlerhaften Raeumen oder der 'void' heraushelfen.
+- Man sieht, dass der Spieler weiss, was er zu tun hat, aber ihm die
+ abwegige(!) Formulierung nicht einfaellt. (Hier sollte man aber
+ zusaetzlich dem Magier, der das entsprechende Objekt 'verbrochen'
+ hat, eine Mitteilung geben, auf dass er es verbessert.)
+
+Selber spielen soll man nur dann, wenn man den Spielern dabei nicht
+hilft oder ihnen ein Abenteuer vor der Nase wegloest.
+
+
+Generell muss die Privatsphaere von Spielern geachtet werden.
+
+Snoopen von Spielern ist nur dann erlaubt, wenn es darum geht, Fehler
+im Mud zu finden oder Ideen zu sammeln, um seinen _eigenen_ Gebiete,
+bzw. Regionen fuer die man verantwortlich ist, zu verbessern und
+anzupassen. Es darf auf keinen Fall dafuer benutzt werden, Spieler
+ohne besonderen Grund zu beobachten, sich ueber sie lustig zu machen,
+oder sie auszuspionieren. Wenn Spieler Post schreiben oder lesen ist
+snoopen strengstens untersagt (Briefgeheimnis).
+Generell ist es angebracht Spieler darauf hinzuweisen, dass sie
+gesnoopt werden.
+
+Es ist ebenso unzulaessig, andere Moeglichkeiten auszunutzen, die
+dazu dienen Spieler zu beobachten, bzw. auszuspionieren (zB verfolgen).
+
+Insbesondere ist es STRIKT untersagt, Objekte zu schreiben, die in
+irgendeiner Weise (zB add_action(...,"",1)) 'teile mit', 'fluester'
+und aehnliche Kommunikationsbefehle abfangen, um Gespraeche von anderen
+abzuhoeren. Dies stellt einen schweren Eingriff in die Intimsphaere der
+anderen Teilnehmer dar und wird dementsprechend geahndet!
+
+Jegliche Art von Belaestigung von Spielern ist untersagt.
+Dazu gehoert das Verfluchen, Monster auf sie hetzen, oder ihnen auf
+irgendeine Art boeswillig Schaden zuzufuegen.
+
+
+Zu dem, was Du hier so programmierst:
+Alles was Du hier an Daten ablegst ist natuerlich Dein eigenes,
+geistiges Eigentum. Trotzdem gehen wir davon aus, das alles, was hier
+im Mudverzeichnis landet, auch fuer das MorgenGrauen entwickelt worden
+ist, also alles was Du schreibst, auch vom Mud genutzt werden darf.
+Dies fuehrt zu folgender Regelung:
+
+Fuer das MorgenGrauen gilt uneingeschraenktes Nutzungsrecht fuer alle
+Monster, Objekte oder Raeume die Du hier programmierst. Dies gilt
+insbesondere fuer alle Sachen, die bereits an die Regionen des MGs
+angeschlossen sind.
+Das bedeutet fuer Dich, dass unter Umstaenden von Dir geschriebene
+Objekte auch gegen Deinen Willen angeschlossen bleiben, und vielleicht
+sogar ggf. aus einem Backup wieder eingespielt werden.
+Mit dieser Regel soll verhindert werden, das unglueckselige Magier aus-
+steigen und beim Verlassen des MG riesige Loecher in der Landschaft
+und im allgemeinen Gleichgewicht hinterlassen.
+
+
+Sollte Deine Magierzeit beendet sein, verpflichtest Du Dich, ueber
+etwaige waehrend Deiner Magierzeit gewonne nicht-oeffentliche Interna
+- insb. nicht-oeffentlichen Code - auch weiterhin Stillschweigen zu
+bewahren. Dies gilt unabhaengig von dem Grund oder der Art und Weise,
+Deine Magierzeit zu beenden (z.B. Loeschung).
+
+
+Wenn Du diesen Vertrag unterschreibst, erkennst Du die Regeln an.
+Die Regeln in /etc/WIZRULES sind immer verbindlich, unabhaengig davon,
+wie sie zum Zeitpunkt deines Magierwerdens aussahen.
+
+
+Nun genug der strengen Regeln ;).
+Nun zu dem, was Du jeden Moment wirst; und zu dem, was danach kommt:
+
+1.) Wenn Du diesen Vertrag unterschrieben hast, und Dein Sponsor (das ist
+ der, der Dir den Vertrag gegeben hat) Merlin gebeten hat, Dich zum
+ Magier zu machen, bekommst Du die magischen Faehigkeiten der Magier.
+ Du wirst Dich unsichtbar machen koennen, andere Wesen teleportieren
+ koennen (siehe jedoch Regeln), Objekte clonen und so weiter und so
+ weiter. Dein Sponsor hat die Aufgabe, Dir den Umgang mit den neuen
+ Faehigkeiten beizubringen (Du darfst ihn darauf festnageln ;-)).
+
+2.) Du kannst jedoch selbst noch keinerlei Programme schreiben. Wenn Du
+ auch selber programmieren willst, musst Du zuerst ein Gesellenstueck
+ abliefern. Wie das geht, findest du bei der Hilfe zum Gesellenstueck
+ beschrieben("hilfe gesellenstueck").
+
+
+So und nun zu den Dingen, die fuer Dich da sind:
+
+ Mit dem Befehl "mhilfe" kannst Du eine Uebersicht ueber die Befehle
+ bekommen, die ein Magier zusaetzlich zu denen der Spieler hat. In
+ dem Verzeichniss /doc findest Du verschiedene Files, die Dir das
+ Verstaendnis erleichtern sollen. Eine Uebersicht kannst Du mit dem
+ Befehl. "more /doc/README" bekommen.
+
+ Der gute alte Merlin ist nicht nur der Urvater aller Magier, sondern
+ beherbergt darueber hinaus auch einen (ab und zu) gut besuchten WizClub.
+ Wer sich mit "goto" noch nicht so gut auskennt, kann ihn in der
+ Abenteurergilde mit dem Kommando "treff" betreten.
diff --git a/doc/wiz/waffen b/doc/wiz/waffen
new file mode 100644
index 0000000..58c4c04
--- /dev/null
+++ b/doc/wiz/waffen
@@ -0,0 +1,202 @@
+ WAFFEN:
+
+ a. Allgemeines
+
+ Alle (zumindest neuen!) Waffen sollten ueber eine vernuenftige
+ Beschreibung und auch Details verfuegen. Einfach "Ein Schwert" ist
+ ein bissel arg duerftig und rechtfertigt auf keinen Fall
+ irgendwelche hohen WCs oder gar HitFuncs! Darauf sollten schon die
+ RMs achten...
+
+ Nach Moeglichkeit auch P_INFO setzen, das ist fuer Spieler nicht so
+ frustrierend und kann ja auch einen netten Spruch enthalten. P_INFO
+ ist *zwingend* bei Waffen mit HitFuncs! Muss ja nicht absolut ein-
+ deutig sein, aber etwas Liebe zum Detail sollte bei Sonderwaffen auf
+ jeden Fall gelten.
+
+ Waffen vom Typ WT_MISC duerfen weder ueber eine Defend- noch eine
+ HitFunc verfuegen. Die AC solcher Waffen ist immer 0. Weiter duerfen
+ solche Waffen keinerlei andere kampfrelevante Bedeutung besitzen
+ oder Manipulationen am/im Spieler/Gegner verursachen.
+
+
+ b. Bemerkungen zu einigen Properties:
+
+ P_WC
+ Die WC sollte einigermassen "realistisch" gewaehlt werden. Die
+ Verantwortung hierfuer obliegt den jeweiligen RMs. Sie sollte
+ zwischen ca. 35 und 200 liegen. Auf jeden Fall sind die aktuellen
+ Genehmigungsgrenzen zu beachten. Sollte die WC diese Grenzen
+ ueberschreiten, unterliegt die Waffe ausser der Genehmigung durch
+ den RM der Beurteilung durch das Waffengremium.
+
+ P_NR_HANDS
+ Waffen ueber einer effektiven WC von 150 muessen zweihaendig sein.
+ Ausnahmen koennen unter Umstaenden genehmigt werden, zum Beispiel
+ wenn die Waffe schwer erreichbar oder zahlenmaessig begrenzt, eine
+ Questbelohnung etc. ist. Alle einhaendigen Waffen ueber WC 140 sind
+ in jedem Fall genehmigen zu lassen.
+
+ Messer muessen generell einhaendig sein!
+
+ P_WEIGHT
+ Bitte realistisch halten. Damit ist *nicht* das RL-Gewicht
+ gemeint, sondern man sollte am besten vergleichbare Waffen des
+ MG als Massstab nutzen. Da hier z.T. gravierende Diskrepanzen
+ bestehen, evtl. mal mehrere vergleichen. Die Verantwortung
+ hierfuer obliegt den RMs.
+
+ Waffen mit einem Gewicht von ueber 4000 Gramm sollten normalerweise
+ auch zweihaendig sein oder muessen der Balance vorgelegt werden.
+
+ ** Besondere Leichtgewichte bitte genehmigen lassen, um spaeterem **
+ ** Aerger vorzubeugen. Grade fuer Kaempfer ist das Gewicht von Waffen **
+ ** sehr wichtig! **
+
+ Zur Erinnerung: Spieler mit Kraft 20 koennen nur 25000 Gewichts-
+ einheiten ("Gramm") tragen.
+
+ P_SIZE
+ Die Laenge der Waffe in cm. Setzt man sie nicht, so gilt der
+ Default- wert fuer den jeweiligen Waffentyp, welcher in der Manpage
+ zu P_SIZE notiert ist.
+
+ P_VALUE
+ Wie bei P_WEIGHT sind die RMs gefragt: Augenmass zaehlt. Werte ueber
+ 10000 oder so sind zwar nett, aber sinnlos und unrealistisch.
+
+ P_DAM_TYPE
+ Jede Waffe, die aus physikalischem Material besteht (also faktisch
+ alles mit Hardware) *muss* einen physikalischen Schadenstyp haben.
+
+ ** Waffen mit mehr als einem nichtphysikalischen Schadenstyp oder **
+ ** mehr als 50% nichtphysikalischen Anteilen sind generell zur **
+ ** Genehmigung vorzulegen und als Besonderheit zu handhaben. Nicht **
+ ** genehmigt und nur im Rahmen der Gildenbalance ermoeglicht werden **
+ ** a) Waffen mit mehr als 66% nichtphysikalischem Schaden im Array, **
+ ** b) Waffen mit einem nichtphysikalischen Schadenstyp ueber 50% **
+
+ Weiterhin genehmigungspflichtig sind die Schadenstypen:
+
+ DT_TERROR, DT_SOUND, DT_SQUEEZE
+
+ Diese Schadenstypen werden in Waffen nur genehmigt, wenn sie gut
+ begruendet sind.
+
+ Der Schadenstyp DT_EXPLOSION wird in Waffen generell nicht mehr
+ genehmigt.
+
+ P_WEAPON_TYPE
+ Nur zur Erinnerung: es gibt im MG zu viele Schwerter und Speere.
+ Nutzt auch die anderen Waffentypen! (Messer und Peitschen sind sehr
+ rar. Bitte angepasste WCs!)
+
+ P_EFFECTIVE_WC
+ Hier kann die evtl durch eine HitFunc veraenderte WC angegeben
+ werden. Der Durchschnittswert soll da stehen. Die Kaempfergilde kann
+ das in gewissen Grenzen abschaetzen.
+
+ P_EFFECTIVE_AC
+ Fuer Paradewaffen setzen. Werte unbedingt mit Boing absprechen!
+
+ P_NOBUY
+ Waffen ab WC 150 werden beim Verkauf im Laden zurueckbehalten. Es
+ sollte aber auch fuer Waffen, die HitFuncs enthalten, P_NOBUY
+ gesetzt werden.
+
+
+ c. Spezialwaffen/Waffen mit Sonderfunktion
+
+ ** ALLE Waffen mit HitFunc oder entsprechender Fkt. muessen **
+ ** genehmigt werden! **
+
+ Solche Waffen muessen ueber ein P_INFO verfuegen und irgendwo in
+ ihrer Beschreibung oder im P_INFO mindestens eine Andeutung ueber
+ die Herkunft oder den Grund ihrer besonderen Faehigkeit haben.
+
+ Auch Spezialwaffen sollten nach Moeglichkeit nicht ueber eine
+ EFFECTIVE_WC von 200 hinausgehen. Der Return-Wert der HitFunc,
+ sofern er von 0 abweicht, MUSS per random() zurueckgegeben werden,
+ da er ohne weiteres random() auf die WC aufaddiert wird.
+
+ Zu beachten ist, dass man bei Waffen, die nur fuer NPCs mehr Schaden
+ machen sollen, nicht (nur) ueber P_RACE prueft, ob der Benutzer ein
+ solcher ist. Es ist denkbar, dass Spieler ihre Rasse temporaer ver-
+ aendern koennen. Waffen die nur bei
+ !interactive(QueryProp(P_WIELDED)) besser zuschlagen, brauchen
+ natuerlich nicht genehmigt zu werden.
+
+ Die Dichte solcher Waffen in einem Gebiet sollte ein vernuenftiges
+ Mass nicht ueberschreiten. Fuer eine Sonderwaffe sollten auch
+ etliche nicht-magische Waffen in der Umgebung sein. Zumindest die
+ starken Waffen (also nicht die, die nur einen Gag oder so
+ beinhalten, sondern wirklich in den Kampf eingreifen) sollten nicht
+ zu leicht zu bekommen sein. Hierauf sollen die RMs achten. Solche
+ Sachen gehoeren zu Monstern, die ein wenig schlechter erreichbar
+ sind oder die besonders stark oder sonstwie unangenehm sind. Also
+ nix verschenken.
+
+ Waffen, die Monster vergiften (also nicht nur P_DAM_TYPE DT_POISON
+ haben) sind zwar nicht grundsaetzlich verboten, aber doch
+ unerwuenscht. Sie sind auf jeden Fall genehmigungspflichtig.
+ Ausserdem sollte die Wahrscheinlichkeit einer Vergiftung pro
+ Kampfrunde max. bei 1% liegen.
+
+ Des weiteren muessen Waffen, die fuer bestimmte Gilden bestimmte
+ Vorteile bringen (sich beim Kami der Tanjian nicht abnutzen zum
+ Beispiel) ebenfalls von der Balance genehmigt werden.
+
+
+ d. Genehmigungsgrenzen
+
+ Einhaendige Waffen : ab P_WC >= 140
+ Zweihaendige Waffen : ab P_WC >= 175
+
+ Fuer Waffen die einen nichtphysikalischen Schadenstyp enthalten:
+
+ Einhaendige Waffen : ab P_WC >= 120
+ Zweihaendige Waffen : ab P_WC >= 150
+
+
+ e. Spezielle Properties fuer die Kaempfergilde
+
+ Diese Properties sind definiert in '/p/kaempfer/kaempfer.h'. Mit ihnen
+ kann man Boni fuer bestimmte Attacken der Kaempfer vergeben (z.B.
+ Bonus auf Waffenschlag oder Todesstoss).
+
+ Genauere Hinweise zu diesen Properties und den zu setzenden Werten
+ findet man in 'man kaempferboni'.
+
+ Prinzipiell gilt:
+
+ ** Alle Waffen, in denen eine solche Property gesetzt wird, **
+ ** sind mit der Objektbalance abzuklaeren. **
+
+
+ f. Parierwaffen
+
+ Parierwaffen sind Waffen, die die Verteidigung unterstuetzen. Eine
+ Waffe wird als Parierwaffe verwendet, wenn die Property P_PARRY
+ gesetzt ist. Folgende Werte sind moeglich:
+
+ PARRY_NOT Die ist KEINE Parierwaffe (=default).
+
+ PARRY_ONLY Dies ist eine reine Parierwaffe.
+
+ PARRY_TOO Diese Waffe wird sowohl als Parierwaffe als auch
+ als Angriffswaffe benutzt
+
+ Die Schutzwirkung der Parierwaffe wird wie bei Ruestungen ueber die
+ Property P_AC gesetzt. Ueber die Property P_DEFEND_FUNC kann wie bei
+ Ruestungen eine DefendFunc gesetzt werden.
+
+ Waffen mit PARRY_ONLY unterliegen den gleichen P_AC-Grenzwerten wie
+ Ruestungen vom Typ AT_SHIELD. Waffen mit PARRY_TOO oder einer
+ DefendFunc muessen generell genehmigt werden.
+
+ SIEHE AUCH:
+ balance, ruestungen, fernwaffen, uniques, npcs, grenzwerte,
+ attributsveraenderungen, resistenzen, kampfobjekte, kaempferboni
+
+ LETZTE AeNDERUNG:
+ 16. Januar 2014 Gloinson
diff --git a/doc/wiz/waffenskills b/doc/wiz/waffenskills
new file mode 100644
index 0000000..6e2ddf5
--- /dev/null
+++ b/doc/wiz/waffenskills
@@ -0,0 +1,59 @@
+Waffenskills im MorgenGrauen
+----------------------------
+
+Das Skillsystem des MGs ist recht komplex. Hier nur ein paar Bemeerkungen
+zu den Waffenskills.
+
+Es gibt 2 Sorten von Waffenskills:
+
+* allgemeine Waffenskills. Diese sind in die Shell eingebunden.
+* Gildenspezifische Skills. Diese sind in der entsprechenden Gilde definiert.
+
+Die Skills werden in einer Property im Spieler gespeichert (P_NEWSKILLS). Es
+handelt es sich um ein mapping, das diesen Aufbau hat:
+
+(["ANY":([ANYSKILLS]),
+"gilde1":([SKILLS_VON_GILDE_1]),
+"gilde2":([SKILLS_VON_GILDE_2]),
+...])
+
+Mit Query(P_NEWSKILLS) erhaelt man das gesamte Mapping.
+
+Mit QueryProp(P_NEWSKILLS) erhaelt man NUR DIE SKILLS DER AKTUELLEN GILDE!
+Das heisst, im obigen Beispiel, wenn der Spieler in gilde1 ist, ist
+der Returnwert SKILLS_VON_GILDE_1.
+
+Sprich: Allgemeine Skills, wie allgemeine Waffenskills, stehen in diesem
+Mapping nicht drin! Ebenso wie z.B. der entgifte-Spell aus der
+Duesterwaldquest (wohl aber der der Kleriker, wenn man einer ist).
+
+Mit QuerySkill("skillname") kann man einen Skill abfragen. Dabei wird, wenn
+kein Skill unter diesem Namen in der aktuellen Gilde eingetragen ist, ein
+eventuell vorhandener ANY-Skill zurueckgegeben. Daher wird z.B. bei einem
+Abenteurer bei QueryProp(P_NEWSKILLS) der Schwertwaffenskill nicht
+angezeigt, wohl aber bei einem QuerySkill(FIGHT(WT_SWORD)).
+
+Prioritaet hat immer der Skill der Gilde, wenn er vorhanden ist.
+
+Man kann auch Skills in der Gilde unterdruecken. Dies geht ueber die Poperty
+P_GUILD_DEACTIVATE_SKILLS. Diese Skills werden nicht per se unterdrueckt,
+sondern nur die entsprechenden ANY-Skills.
+
+Sprich: Es sei A ein Abenteurer.
+
+xcall A->QuerySkill(FIGHT(WT_SWORD))
+
+mag folgendes zurueckgeben:
+
+Result: (["si_difficulty":150,"si_abil":0,"si_guild":"ANY"])
+
+tritt A daraufhin den Kaempfern bei und hat dort noch keinen Schwertskill
+gelernt, wird hingegen 0 zurueckgegebn. Fuer den Fall eines Austritts ist der
+Wert aber nach wie vor gespeichert, wie man per Query(P_NEWSKILLS) leicht
+sehen kann. Dies wird unterdrueckt, da in der Kaempfergilde die Prop
+P_GUILD_DEACTIVATE_SKILLS gesetzt wird.
+
+Tritt der Spieler den Chaoten bei, aendert sich hingegen bei diesem Aufruf
+nichts.
+
+Letzte Aenderung: Humni, 2003-07-09
diff --git a/doc/wiz/zaubertraenke b/doc/wiz/zaubertraenke
new file mode 100644
index 0000000..aadb54a
--- /dev/null
+++ b/doc/wiz/zaubertraenke
@@ -0,0 +1,95 @@
+
+Zaubertraenke fuer Magier
+=========================
+
+Wie man die Traenke jetzt genau versteckt bleibt dem betreffenden Magier
+ueberlassen, es sollte halt insgesamt ein breites Spektrum von sehr leicht
+zu finden bis fast unmoeglich abgedeckt sein.
+Fuer das Orakel der Hochebene sollte dann ein entsprechender Spruch
+vorbereitet werden, nicht zu kryptisch aber doch orakleig.
+
+Die zufaellige Auswahl an zugeordneten Zaubertraenken wird beim ersten
+Einloggen des Spielers festgelegt.
+
+Die Raeume, in denen Traenke versteckt werden (und es duerfen nur Raeume
+sein), werden in 8 Listen eingeteilt, je nach Schwierigkeitsgrad. Der haengt
+natuerlich von der Lage (so ist ein Trank in einem monsterwimmelnden
+Labyrinth schwieriger zu erreichen, als einer auf der Hochebene), und von
+dem Versteck selbst ab.
+Questraeume, die nur im Rahmen der Quest erreichbar sind, sind ungeeignet.
+
+
+Mein Standardbeispiel fuer ein Versteck ist immer folgendes:
+
+> schaue
+blablablabla .... Ein Schreibtisch steht in der Ecke. ... blablabla
+> unt schreibtisch
+Er hat eine Schublade.
+> oeffne schublade
+Du oeffnest die Schublade.
+> unt schublade
+In der Schublade enteckst Du ein paar Papiere.
+> unt papiere
+Beim Rumwuehlen in den Papieren entdeckst Du einen kleinen Zaubertrank, den
+Du sofort trinkst.
+
+Dann kommt die Auswahlsequenz, welche Eigenschaft man erhoehen will.
+
+In diesem Fall reichen Details, Details mit Closure und eine Kommando fuer
+"oeffne" aus. Etwa wie folgt:
+
+ void create() {
+ [...]
+ SetProp(P_INT_LONG, ... Ein Schreibtisch steht in der Ecke ...);
+
+ AddDetail(({"tisch", "schreibtisch"}),
+ "Er hat eine Schublade.");
+
+ AddCmd("oeffne&schublade", #'action_oeffne,
+ "Was moechtest du oeffnen.");
+ }
+
+ private int action_oeffne() {
+ tell_object(this_player(), "Du oeffnest die Schublade.\n");
+ tell_room(this_object(), this_player()->Name()+
+ " oeffnet eine Schublade.\n", ({this_player()}));
+
+ AddDetail("schublade",
+ "In der Schublade entdeckst du ein paar Papiere.\n");
+ AddDetail("papiere", #'detail_papiere);
+ }
+
+ // Zaubertrankgebendes Detail
+ private string detail_papiere() {
+ if (this_player()->FindPotion(
+ break_string("Beim Rumwuehlen in den Papieren entdeckst Du einen "
+ "kleinen Zaubertrank, den Du sofort trinkst.", 78)))
+ return "";
+ // Es muss ein String zurueckgegeben werden, da man sonst
+ // die Fehlermeldung "Sowas siehst du hier nicht." bekommt
+ else
+ return "Die Papiere sind alle unbeschriftet.\n";
+ }
+
+ // Aufraeumen des Raumes
+ void reset() {
+ if(!sizeof(filter(all_inventory(this_object()), #'interactive))) {
+ RemoveDetail("papiere");
+ RemoveDetail("schublade");
+ }
+ ::reset();
+ }
+
+FindPotion() gibt 1 zurueck, wenn der Spieler den Zaubertrank finden darf.
+
+Wer also Traenke verstecken will, macht sowas in der Art und meldet dann den
+Raum persoenlich oder per Post bei den Erzmagiern bzw seinem aktiven
+Regionsmagier an.
+
+SIEHE AUCH:
+ Weitere Dateinamen mit Beispielen fuer Trankverstecke kann man der
+ Datei /etc/traenke entnehmen.
+
+ Befehl: traenke (fuer Magier zum Einschalten des Findens von ZTs)
+
+10. August 2015 Gloinson
diff --git a/doc/wiz/zweitiedb b/doc/wiz/zweitiedb
new file mode 100644
index 0000000..bf72d26
--- /dev/null
+++ b/doc/wiz/zweitiedb
@@ -0,0 +1,21 @@
+In der Zweitie-DB werden alle Chars verwaltet, die als Zweitie von irgendeinem anderen markiert sind. (Zur Zeit: nur die seit Herbst 2014 eingeloggten.)
+
+Direkte Abfrage der Zweitie-DB (fuer Erzmagier):
+
+Die Zweitie-DB liegt unter
+secure/ARCH/second.sqlite
+Das verwaltende Objekt im Mud ist /secure/zweities
+
+Auf der Shell fragt man die DB recht simpel so ab:
+sqlite3 -column -header secure/ARCH/second.sqlite
+
+Alle Zweities von Arathorn ermitteln:
+select * from zweities where erstie='arathorn';
+
+Erstie von Ahab ermitteln:
+select erstie from zweities where name='ahab';
+
+Diese select-Anweisungen lassen sich (als EM) auch im Mud absetzen:
+xcall /secure/zweities->sql_query(
+ "select * from zweities where erstie='arathorn';")
+