KONZEPT
Event-Lauscher
AUTOR
Holger@Wunderland
VORBEMERKUNG
Bevor man daran geht, Events zu benutzen oder gar zu erzeugen,
sollte man verstanden haben, um was es geht. Also bitte erst
events(WL) lesen und verstehen und dann hier nachgucken, wies geht.
Danke. :-)
ANMELDUNG ALS LAUSCHER
Wenn man einem Event lauschen will, sollte man erstmal wissen, wie
der Event heisst, also den Event-Typ kennen (event_types(WL)). Will
man beispielsweise dem Event ET_GO lauschen, ruft man im create()
seines Objekts folgendes auf:
listen_event(ET_GO, prio, #'fun);
ET_GO - Define aus /sys/moving.h
prio - Integer zwischen 999 und -10999 (event_prioriaeten(WL))
fun - Eine Closure, die dann aufgerufen werden soll,
oder der Name der aufzurufenden Funktion als String
Danach wird das Objekt alle Events vom Typ ET_GO mit Prioritaet
'prio' ueber Closure 'fun' erhalten. Die Closure kann beim Aufruf
folgende Argumente erwarten:
varargs void fun(mapping data, string type, int prio, int mode);
data - Das Event-Mapping mit den Daten.
type - Der Typ des jeweiligen Events. (hier: ET_GO)
prio - Die Prioritaet mit der 'fun' aufgerufen wurde.
mode - Der Sende-Modus. Ueber ihn kann ermittelt werden, ob das
Daten-Mapping eine Referenz oder nur eine Kopie ist. Ist
das Mapping nur eine Kopie, dann kann der Inhalt durch uns
NICHT veraendert werden. (zu 99% bedeutungslos)
Und das wars auch schon. :-) Das Objekt bekommt jetzt jeden Event
dieses Typs, wenn er in der unmittelbaren 'Naehe' des Objekts
erzeugt wird. Welche Daten im data-Mapping enthalten sind,
ist von Event zu Event unterschiedlich und sollte in der Manpage
des Typs beschrieben sein.
ABMELDUNG ALS LAUSCHER
Will sich das Objekt als Lauscher wieder abmelden, ruft man
folgendes auf:
unlisten_event(ET_GO, prio, #'fun);
Argumente muessen alle IDENTISCH sein mit den Argumenten der An-
meldung.
ANMELDUNG ALS GLOBALER LAUSCHER
Es kann vorkommen, dass ein Objekt nicht nur Events aus der un-
mittelbaren Umgebung lauschen will, sondern generell allen Events
dieses Typs. Grundsaetzlich sollte dies nur im Ausnahmefall gegeben
sein, zum Beispiel fuer Globale Handler.
Zunaechst MUSS sich das Objekt ganz normal anmelden, wie oben be-
schrieben. Danach muss es dem Event-Daemon noch mitteilen, dass es
global lauschen will, mittels:
set_global_listener(ET_GO, 1);
ABMELDUNG ALS GLOBALER LAUSCHER
Will sich das Objekt als globaler Lauscher wieder abmelden, kann man
dies ebenfalls do set_global():
set_global_listener(ET_GO, 0);
Mehr gibts nicht zu tun.
EVENT-MODIFIZIERER (EPRIO_MODIFY = 700, Bereich 999 bis 500)
Empfaengt man einen Event, sollte man zunaechst ueberpruefen, ob
man auch bekommen hat, was man haben wollte. Danach kann man als
Modifizierer (mit hoher Prioritaet) das Mapping veraendern oder
als Canceller ihn abbrechen, oder als Reagierer (mit kleiner
Prioritaet) darauf reagieren. Was genau zu veraendern ist und was
veraendert werden darf, ist bei jedem Event unterschiedlich und
sollte in der Dokumentation des Events stehen. Wichtig ist vor
allem:
1. SCHNELL SEIN (sonst drohen 'too long evaluation errors'!)
2. VORSICHTIG SEIN (Objekte koennten schon destructet sein!)
3. GLOBAL DENKEN (Du bist sicher nicht der einzige, der diesem
Event lauscht und ihn verarbeiten moechte!)
4. NICHTS AUSGEBEN und keine Aktion/Events starten
EVENT-ABBRECHER (EPRIO_CANCEL = 400, Bereich 499 bis 200)
Mit einer positiven Prioritaet erhaelt man den Event in aller Regel
immer, bevor das Ereignis 'gehandelt' wird. Solange darf man den
Objekt abbrechen. Abbrechen kann man den laufenden Event mittels:
cancel_event(mixed info);
Der Inhalt von 'info' ist variabel und kann auch ganz weggelassen
werden. 'info' wird er als E_CANCELLED ins Daten-Mapping eingefuegt.
Das abbrechende Objekt wird als E_CANCELLER eingefuegt.
Objekte, die als Reagierer angemeldet sind, duerfen den Event
NICHT ABBRECHEN, denn dann ist es ohnehin schon zu spaet.
Abbrecher duerfen nichts ausgeben und keine Aktion/Events starten!
Dazu muessen sie ein zweites Mal als EVENT-C-HANDLER angemeldet sein.
EVENT-HANDLER (EPRIO_HANDLE = 100, Bereich von 199 bis 1)
Mit einer Prioriaet um 0 (event_prioriaeten(WL)) gilt das Objekt
als ein Handler. Der Handler macht das, was der Event eigentlich
bedeutet. Der Move-Handler 'erledigt' zum Beispiel das 'Gehen' von
Lebewesen, wenn es ET_GO empfaengt. Der Handler markiert den Event
als gehandeld mittels:
handle_event(mixed info);
Der Wert von 'info' ist von Event-Typ zu Event-Typ verschieden.
'info' wird er als E_HANDLED ins Daten-Mapping eingefuegt.
Das handelnde Objekt wird als E_HANDLER eingefuegt.
Das Handlen von MUDlib-Events (wie ET_GO etc.) sollte auch der
MUDlib selbst ueberlassen bleiben!!!
EVENT-REAGIERER (EPRIO_REACT = -300, Bereich -1 bis -999)
Mit einer negativen Prioritaet (groesser -10000) gilt das Objekt
als ein Reagierer. Reagierer duerfen das Daten-Mapping NICHT
VERAENDERN. Sie duerfen nur verschiedene Aktionen als Reaktion auf
das Ereignis (was schon passiert ist und nicht mehr verhindert
werden kann) ausfuehren.
EVENT-C-HANDLER (EPRIO_C_HANDLE = -10000)
Mit der Prioritaet -10000 koennen EVENT-ABBRECHER ein zweites Mal
lauschen, wenn sie nach einem Abbruch eine Ausgabe erzeugen oder
eine Aktion starten wollen. Von allen eventuell angemeldeten
EVENT-C-HANDLERN wird ausschliesslich das Objekt aufgerufen, welches
auch das Event abbrach (und somit E_CANCELLER ist).
EVENT-C-REAGIERER (EPRIO_C_REACT = -10300, Bereich -10001 bis -10999)
Mit einer Prioritaet kleiner -10000 gilt das Objekt als Reagierer,
jedoch nur auf abgebrochene Ereignisse. Wenn der Spieler also etwas
erreichen will, aber von etwas davon abgehalten wird, so kann
man hier darauf reagieren. Das Ereignis ist jetzt wirklich nicht
passiert und wurde wirklich versucht.
SIEHE AUCH
events(WL), event_types(WL), event_prioriaeten(WL),
event_senders(WL), ET_GO(WL), listen_event(S), unlisten_event(S),
set_global_listener(S), cancel_event(S), handle_event(S)
|
