Supervisoren fuer Ebenen
************************

Die Supervisoren von Ebenen werden vom CHANNELD gefragt, ob ein Objekt eine
bestimmte Aktion auf einer bestimmten Ebenen tun darf, z.B. Betreten einer
Ebene oder Senden auf einer Ebene. Die SVs sind ebenfalls immer Zuhoerer auf
der Ebene.

Wird ein SV zerstoert, wird im Normalfall ein neuer SV aus dem Kreise der
aktuellen Zuhoerer bestimmt, ueblicherweise das am laengsten zuhoerende
Objekt.

Betritt ein Objekt, was eine Ebene erschaffen hat (der erste Supervisor), eine
Ebene nach Verlassen erneut, uebernimmt es automatisch die SV-Rolle wieder,
sofern das Objekt *kein* Spieler oder Magier ist.


Erstellen von Supervisoren
==========================

Im einfachsten Fall wird /std/channel_supervisor geerbt, ein Name konfiguriert
und das systemweite Init-File fuer Ebenen eingelesen. Anschliessend erhaelt
man das Standardverhalten, was im Init-File konfiguriert ist. Ein Beispiel
hierfuer findet sich /doc/beispiele/ebenen/supervisor.c.

Man kann ein bestehendes Objekt zu einem SV machen, indem man
/std/channel_supervisor zusaetzlich erbt. In diesem Fall muss man ggf. auf
name() und Name() aufpassen, sofern das Objekt auch /std/thing/description
oder aehnliche erbt und gezielt die von dort geerbten lfuns aufrufen. Ein
Beispiel hierfuer steht in /doc/beispiele/ebenen/supervisor-thing.c.

Will man einen SV fuer eine Ebene konfigurieren, die keine Standardebene ist,
kann man ein eigenes Init-File einlesen (Format s. u.). In diesem Fall ist
aber zu beachten, dass man auch selber Sorge dafuer tragen muss, dass die
Ebene erstellt wird (CHANNELD->new()).

Will man einen SV mit einem gaenzlich anderen Verhalten bauen, so ist auch das
moeglich, indem man die lfun
  public int ch_check_access(string ch, object user, string cmd)
ueberschreibt. Diese wird vom CHANNELD im SV gerufen. Gibt sie eine 1 zurueck,
darf das Objekt <user> auf der Ebene <ch> die Aktion <cmd> ausfuehren.
Anderenfalls muss 0 zurueckgeben werden.
<cmd> ist hierbei eine der in /p/daemon/channel.h definierten Kommandos.

Die Ebene <ch> wird immer kleingeschrieben uebergeben. Auch wenn der Name
Spielern case-sensitiv angezeigt wird, kann es keine zwei Ebenen geben,
welche sich nur in Gross-/Kleinschreibung unterscheiden und intern erfolgt
die Verwaltung *immer* kleingeschrieben - dies gilt auch fuer die
Rechtepruefung.


Eigenes Init-File
-----------------

Das Init-File hat folgenden Aufbau:
<name>:<recv>:<send>:<accessflags>:<channelflags>:<desc>:<supervisor>
z.B.
abgilde: 0: 0: 0: 0:Fuer Abenteurer:/gilden/abenteurer

Fuer SVs sind nur die Felder <name>, <recv>, <send> und <accessflags>
relevant. Das vordefinierte ch_check_access() entscheidet wie folgt anhand der
Angaben:

Verlassen (C_LEAVE) ist immer erlaubt. Die anderen Aktionen sind in zwei
Gruppen eingeteilt:
  1) RECV. Die Aktionen dieser Gruppe sind Suchen (C_FIND), Auflisten
           (C_LIST) und Betreten (C_JOIN).
  2) SEND. Die Aktion dieser Gruppe ist zur Zeit nur Senden (C_SEND).

Aktionen werden zugelassen, wenn Spieler/MagierLevel groesser oder gleich ist
wie die fuer die jeweilige Aktionsgruppe RECV oder SEND festgelegte Stufe.

Handelt es sich um eine Magierebene (<accessflags> enthaelt das Flag
CH_ACCESS_WIZARD), muss die Magierstufe des Spielers groesser oder gleich sein
wie die Mindeststufe der Ebene. Ansonsten wird gegen den Spielerlevel geprueft.
Enthaelt <accessflags> das Flag CH_ACCESS_NOGUEST, darf die Ebene nicht von
Gaesten benutzt werden (weder Empfangen noch Senden).

Wenn RECV_LVL oder SEND_LVL auf -1 gesetzt ist, sind die Aktionen der
jeweiligen Gruppen komplett geblockt.

Bemerkung: Im Initfile sollten nur Blueprints als SVs verwendet werden - aber
im Allgemeinen koennen SVs auch Clones sein!