KONZEPT
        Private Events fuer alle (Aufbau-Doku)

VORBEMERKUNG
        Das Event-System im Wunderland ist noch im Aufbau!!! Unter Um-
        staenden werden sich verschiedene Details im Event-Daemon noch
        aendern. Die Benutzung des Daemons, ist somit mit Vorsicht zu
        geniessen und sollte vorerst nur durch Magier geschehen, die
        wissen, worum es geht. Ausserdem sollte mit Holger oder einem
        anderen Erzmagier Ruecksprache genommen werden.

        Diese Dokumentation ist ebenfalls nur ein 'Versuch'. Sie soll dazu
        dienen, in der Uebergangs- und Aufbauzeit des Event-System ein paar
        Anhaltspunkte zu geben.

PRIVATE EVENTS
        Grundsaetzlich sind 'private' Events erlaubt. Als private Events
        gelten solche, die nicht durch die Standardobjekte der MUDLib
        ausgeloest oder verwaltet werden. Es ist jedoch nicht im Sinne des
        Erfinders, wenn jeder Magier fuer all seine Objekte komplett eigne
        Events erfindet, die vielleicht frueher oder spaeter ohnehin in
        der MUDlib implementiert werden. Ich bitte deshalb dringlich darum,
        keine 'privaten Move-Events' oder aehnliches zu erfinden, was mit
        Sicherheit frueher oder spaeter einheitlich wird. Bitte fertigt
        deshalb _vorher_ ein Konzept fuer euren Event und lasst es mal von
        einem Erzmagier lesen.

        Es gibt keine festgeschriebenen Vorgaben fuer private Events, doch
        um unkontrolliertem und vor allem unkontrollierbarem Wildwuchs vor-
        zubeugen, sollten die folgenden Richtlinien beherzigt werden.

EVENT TYPNAME
        Der Typ sollte moeglichst selbstredend sein. Kein Mensch weiss
        etwas mit einem Event-Typ "et_abc_weil_ichs_so_will" anzufangen.
        Handelt es sich beispielsweise um einen Event, der alle Raskire
        zum Altvordernen bestellt, koennte man den "et_raskir_alarm" nennen.
        Dann weiss man auch in einem Jahr noch, um was es sich handeln
        koennte. Weiterhin sollten Namen vermieden werden, die die MUDlib
        frueher oder spaeter verwenden koennte. Z.B. "et_move" oder 
        "et_attack" oder "et_death" usw. Im Zweifel bitte mit Holger reden!

EVENT PRIORITAETEN
        Fuer private Events gibt es auch hier keine Vorgaben. Da es jedem
        Magier selbst ueberlassen ist, was er mit einem Event anstellt,
        muss er auch selbst entscheiden, wie er die Prioriaeten setzt.
        ABER: Im Interesse der Lesbarkeit von Objekten und der Kooperation
        mit anderen Magiern, die auf diesen Event vielleicht auch reagieren
        wollen, sollten auch bei privaten Events die Prioritaeten so gesetzt
        werden, wie es die MUDlib selbst tut. Siehe dazu die Manpage und die
        Defines in /sys/events.h

LAUSCHER-OBJEKTE
        So wie man selbst private Events erzeugen kann, so kann man auch
        seine privaten Lauscher auf diesen Event proggen. Damit dies aber
        allen moeglich ist, sollte auch ein privater Event gut dokumentiert
        sein. Es ist auch darauf zu achten, ob ein Lauscher wirklich global
        lauschen muss, oder ob es nicht lokal reicht. Dies hat vor allem
        Effizienzgruende. Soll ein Event an 5 NPCs in einem 30-Raeume Gebiet
        gehen, macht es Sinn den Event an kein bestimmtes Objekt zu senden,
        und die 5 NPCs global auf diesen Event lauschen zu lassen. Sind je-
        doch 12 Objekte in einem 4-Raum Gebiet zu verstaendigen, ist es
        sinnvoller, die 4 Raeume als Ziel anzugeben und die Lauscher nur
        lokal lauschen zu lassen. Wenn man unsicher ist -> Erzmagier fragen.

GESCHWINDIGKEIT
        Besonders fuer private Events ist das wichtigste eine hohe Geschwin-
        digkeit in der Verarbeitung. Es ist nicht akzeptabel, wenn ein Ob-
        jekt im Heart-Beat an 30 NPCs einen privaten Event sendet und die
        wiederum jeweils 10 teure Funktionen ausfuehren. Ein Event ist kein
        Ersatz fuer eine gezieltes find_object() und call_other(). Es dient
        dazu, auch den Objekten etwas mitzuteilen, von denen man eben nichts
        weiss oder wissen moechte. Hat man zum Beispiel einen Trupp Zwerge
        geschrieben, weiss aber gerade nicht, welche davon noch leben, oder
        wo sich sich rumtreiben, dann sendet man einen Event, den alle
        Zwerge beantworten und sich melden koennen. Haben sich dann alle
        Zwerge gemeldet, dann kann man die mit map_objects() viel effektiver
        steuern, als mit den Event-System. Gehen irgendwann ein paar Zwerge
        verloren oder man weiss nicht genau, ob irgendwo wieder neue rum-
        rennen, dann laesst man wieder sammeln. usw. usf.

        Die Spieler werden es euch zwar nicht danken, wenn ihr effektiv
        programmiert, aber sie werden zumindest weniger ueber das Lag
        jammern. ;-)

SIEHE AUCH
        events(WL), event_prioritaeten(WL)