Added public files
Roughly added all public files. Probably missed some, though.
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!
+