blob: fa0dfa81c1267d0435853351028a171f0d269ce7 [file] [log] [blame]
MG Mud User88f12472016-06-24 23:31:02 +02001Was sind Events?
2================
3Events im MorgenGrauen sind Ereignisse, die von beliebigen Objekten ausgeloest
4werden koennen. Es gibt eine Reihe von vordefinierten Ereignissen, die die
5Basis-Lib bereitstellt (s.u.). Zusaetzlich zu diesen koennen Magier beliebige
6weitere Events erstellen bzw. benutzen.
7
8Wenn ein Objekt dem zentralen Event-Dispatcher einen bestimmten Event meldet,
9merkt dieser sich dies und die Daten, die ihm vom ausloesenden Objekt
10uebergeben wurde. Mit kurzer Verzoegerung (0-2s) informiert der
11Event-Dispatcher dann alle Objekte, die sich fuer diesen Event interessieren,
12d.h. dafuer angemeldet sind. Hierzu ruft er eine bestimmte Funktion in den
13angemeldeten Objekten auf.
14Hierbei ist zu beachten, dass die informierten Objekte das Ereignis in keinem
15Fall mehr beeinflussen koennen, da es bereits abgeschlossen wurde. Es ist
16lediglich eine Information ueber das Ereignis. Wenn ein Objekt Einfluss nehmen
17will (z.B. auf einen Tod), ist dafuer ein Hook zu verwenden.
18
19
20Welche Events definiert die Mudlib?
21==================================
22Diese Events haben in /sys/events.h vordefinierte Event-IDs und werden von der
23Basis-Mudlib mit den entsprechenden Daten ausgeloest (s. jew. Event):
24- EVT_LIB_LOGIN: Login eines Spielers
25- EVT_LIB_LOGOUT: Logout eines Spielers
26- EVT_LIB_PLAYER_DEATH: Ein Spieler ist gestorben
27- EVT_LIB_PLAYER_DELETION: Ein Spieler hat sich geloescht
28- EVT_LIB_PLAYER_CREATION: Ein Spieler wurde neu angelegt.
29- EVT_LIB_NPC_DEATH(): Ein NPC ist gestorben (Parameter s. Event-Manpage)
30- EVT_LIB_ADVANCE: Ein Spieler hat seine Spielerstufe erhoeht
31- EVT_LIB_PLAYER_ATTR_CHANGE: Die Attribute eines Spielers wurden geaendert
32- EVT_LIB_CLOCK: Die volle Stunde ist erreicht
33- EVT_LIB_DATECHANGE: Ein neuer Tag ist angebrochen. ;-)
34- EVT_LIB_QUEST_SOLVED: Ein Spieler hat eine Quest geloest
35- EVT_LIB_MINIQUEST_SOLVED: Ein Spieler hat eine Miniquest geloest
36
37Gilden muessen definieren (ggf. via /std/gilden_ob.c):
38- EVT_GUILD_CHANGE: Spieler hat seine Gilde gewechselt.
39- EVT_GUILD_ADVANCE: Ein Spieler hat seine Gildenstufe erhoeht
40
41
42Namenskonvention fuer Event-IDs:
43===============================
44- Die IDs aller Standardevents beginnen mit "evt_lib_".
45 Dementsprechend sind alle Strings, die damit anfangen, fuer ALLE ausser
46 der Mudlib TABU! D.h.
47 - diese Events werden NIEMALS von Objekten ausserhalb der Basislib
48 ausgeloest!
49 - es duerfen keine Events registriert werden, die mit dieser Zeichenfolge
50 anfangen, ausser mit den symbolischen Namen in /sys/events.h
51- Gilden-Events beginnen mit "evt_guild_", sofern es ein Event ist, den jede
52 Gilde definiert (s. /sys/events.h).
53 Die Events einzelner Gilden sollten mit "evt_gildenname_" beginnen.
54- Die IDs einzelner Magier sollten am besten zwecks Eindeutigkeit mit
55 "magiername_" beginnen.
56
57
58Was ist als lauschendes Objekt zu beachten?
59==========================================
60Das lauschende Objekt muss zunaechst /sys/events.h inkludieren und sich
61mittels Aufrufs von RegisterEvent() als Lauscher registrieren.
62Weiterhin muss es eine Funktion oeffentlich definieren (Name beliebig), die
63der EVENTD aufrufen kann. Diese Funktion bekommt 3 Argumente uebergeben:
64Event-ID, event-ausloesendes Objekt und die Event-Daten:
65 public void listen_event(string eid, object trigob, mixed data);
66'data' ist ein Datentyp, der vom Eventtyp abhaengt. Oft handelt es sich
67um ein Mapping. Fuer eine genaue Beschreibung schaut bitte die in die Manpage
68des konkreten Events.
69
70Bitte beachten: Die Daten in 'data' im Falle eines Arrays/Mappings niemals
71aendern. Aus Effizienzgruenden wird 'data' nicht kopiert, bevor es an die
72einzelnen Objekte uebergeben wird. Wenn ihr also Muell reinschreibt, werden
73nach euch informierte Lauscher euren Schrott empfangen. Sollte hier
74'Missbrauch' auffallen, wird das entsprechend geahndet!
75
76Und zum Schluss: Bitte missbraucht die Events nicht und meldet euch (speziell
77fuer haeufige Events) nur an, wenn ihr mit den Informationen was sinnvolles
78macht (also z.B. nicht nur, um ein Log der getoeteten NPCs im Spiel zu
79erstellen. ;-)).
80
81
82Was ist als ausloesendes Objekt zu beachten?
83===========================================
84Eigentlich gar nicht viel. Ihr muesst lediglich /sys/events.h inkludieren und
85bei Auftreten des Events die Funktion TriggerEvent() im EVENTD aufrufen und
86ihr die Event-ID und die Event-Daten uebergeben.
87Bitte uebergebt als Event-Daten ggf. Kopien von Mappings/Arrays, da lauschende
88Objekte diese Daten veraendern koennen.
89
90
91Beispiele:
92========
931. Ein Objekt moechte ueber Spielertode informiert werden:
94 EVENTD->RegisterEvent(EVT_LIB_PLAYER_DEATH, "spieler_ist_tot",
95 this_object());
96 Ab jetzt wird im Objekt jedes Mal, wenn ein Spieler stirbt, die Funktion
97 "spieler_ist_tot" aufgerufen.
98
992. Ein Objekt moechte nicht mehr ueber Spielertode informiert werden:
100 EVENTD->UnregisterEvent(EVT_LIB_PLAYER_DEATH, this_object());
101
1023. Ein Objekt will informiert werden, wenn der Event
103 "boing_zwergenkoenig_angriff" ausgeloest wird:
104 EVENTD->RegisterEvent("boing_zwergenkoenig_angriff","alarm",
105 this_object());
106
1074. Der Zwergenkoenig (oder einer seiner Waechter) wird angegriffen:
108 EVENTD->TriggerEvent("boing_zwergenkoenig_angriff", daten);
109 Anschliessend wird jedes Objekt, das es wissen will (s. 3.) vom EVENTD
110 informiert und kriegt dabei 'daten' uebergeben. Dies kann ein beliebiger
111 Datentyp sein (z.b. ein Mapping). In diesem Fall enthaelt 'daten'
112 zweckmaessigerweise den Angreifer.
113
114
115Siehe auch:
116==========
117 eventd, TriggerEvent(), RegisterEvent(), UnregisterEvent()
118
11918.08.2007, Zesstra
120