MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame] | 1 | Was sind Events? |
| 2 | ================ |
| 3 | Events im MorgenGrauen sind Ereignisse, die von beliebigen Objekten ausgeloest |
| 4 | werden koennen. Es gibt eine Reihe von vordefinierten Ereignissen, die die |
| 5 | Basis-Lib bereitstellt (s.u.). Zusaetzlich zu diesen koennen Magier beliebige |
| 6 | weitere Events erstellen bzw. benutzen. |
| 7 | |
| 8 | Wenn ein Objekt dem zentralen Event-Dispatcher einen bestimmten Event meldet, |
| 9 | merkt dieser sich dies und die Daten, die ihm vom ausloesenden Objekt |
| 10 | uebergeben wurde. Mit kurzer Verzoegerung (0-2s) informiert der |
| 11 | Event-Dispatcher dann alle Objekte, die sich fuer diesen Event interessieren, |
| 12 | d.h. dafuer angemeldet sind. Hierzu ruft er eine bestimmte Funktion in den |
| 13 | angemeldeten Objekten auf. |
| 14 | Hierbei ist zu beachten, dass die informierten Objekte das Ereignis in keinem |
| 15 | Fall mehr beeinflussen koennen, da es bereits abgeschlossen wurde. Es ist |
| 16 | lediglich eine Information ueber das Ereignis. Wenn ein Objekt Einfluss nehmen |
| 17 | will (z.B. auf einen Tod), ist dafuer ein Hook zu verwenden. |
| 18 | |
| 19 | |
| 20 | Welche Events definiert die Mudlib? |
| 21 | ================================== |
| 22 | Diese Events haben in /sys/events.h vordefinierte Event-IDs und werden von der |
| 23 | Basis-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 | |
| 37 | Gilden 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 | |
| 42 | Namenskonvention 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 | |
| 58 | Was ist als lauschendes Objekt zu beachten? |
| 59 | ========================================== |
| 60 | Das lauschende Objekt muss zunaechst /sys/events.h inkludieren und sich |
| 61 | mittels Aufrufs von RegisterEvent() als Lauscher registrieren. |
| 62 | Weiterhin muss es eine Funktion oeffentlich definieren (Name beliebig), die |
| 63 | der EVENTD aufrufen kann. Diese Funktion bekommt 3 Argumente uebergeben: |
| 64 | Event-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 |
| 67 | um ein Mapping. Fuer eine genaue Beschreibung schaut bitte die in die Manpage |
| 68 | des konkreten Events. |
| 69 | |
| 70 | Bitte beachten: Die Daten in 'data' im Falle eines Arrays/Mappings niemals |
| 71 | aendern. Aus Effizienzgruenden wird 'data' nicht kopiert, bevor es an die |
| 72 | einzelnen Objekte uebergeben wird. Wenn ihr also Muell reinschreibt, werden |
| 73 | nach euch informierte Lauscher euren Schrott empfangen. Sollte hier |
| 74 | 'Missbrauch' auffallen, wird das entsprechend geahndet! |
| 75 | |
| 76 | Und zum Schluss: Bitte missbraucht die Events nicht und meldet euch (speziell |
| 77 | fuer haeufige Events) nur an, wenn ihr mit den Informationen was sinnvolles |
| 78 | macht (also z.B. nicht nur, um ein Log der getoeteten NPCs im Spiel zu |
| 79 | erstellen. ;-)). |
| 80 | |
| 81 | |
| 82 | Was ist als ausloesendes Objekt zu beachten? |
| 83 | =========================================== |
| 84 | Eigentlich gar nicht viel. Ihr muesst lediglich /sys/events.h inkludieren und |
| 85 | bei Auftreten des Events die Funktion TriggerEvent() im EVENTD aufrufen und |
| 86 | ihr die Event-ID und die Event-Daten uebergeben. |
| 87 | Bitte uebergebt als Event-Daten ggf. Kopien von Mappings/Arrays, da lauschende |
| 88 | Objekte diese Daten veraendern koennen. |
| 89 | |
| 90 | |
| 91 | Beispiele: |
| 92 | ======== |
| 93 | 1. 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 | |
| 99 | 2. Ein Objekt moechte nicht mehr ueber Spielertode informiert werden: |
| 100 | EVENTD->UnregisterEvent(EVT_LIB_PLAYER_DEATH, this_object()); |
| 101 | |
| 102 | 3. 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 | |
| 107 | 4. 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 | |
| 115 | Siehe auch: |
| 116 | ========== |
| 117 | eventd, TriggerEvent(), RegisterEvent(), UnregisterEvent() |
| 118 | |
| 119 | 18.08.2007, Zesstra |
| 120 | |