| 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! |
| |