Klassen


islandbar.gif

Trigger Klassen Variablen

Stichwoerter:

Einfuehrung

Wozu sind die Klassen gut? Hauptsaechlich, um Scripte zu gruppieren. Jede Klasse kann ein- und ausgeschaltet werden, damit werden die Triggers und Aliasse in der Klasse ebenfalls ein- oder ausgeschaltet. (Wenn ausgeschaltet, haben diese dann keine Wirkung.)
In der Settings-Editor von Version 6.15 werden die Klassen als Order angezeigt, Klassen die ausgeschaltet sind werden transparent angezeigt.
Um eine Klasse zu bearbeiten, waehle sie mit der linke Maustaste aus (einmal klciken!), und um ihre Inhalt zu bearbeiten/anzuzeigen, klicke zweimal.
Um ein Trigger eine Klasse zuzuteilen, muss man nur beim erzeugen der Trigger die Klasse als drittes Argument mitangeben, eg.:
#TRIGGER {* blah *} {Trigger in class test} {test}
Hiermit wird auch die Klasse 'test' angelegt, falls sie noch nicht existiert.
Man kann sie natuerlich auch im Settings-Editor auswaehlen, und in die richtige Klasse schieben, genauso wie man Dateien im Windows-Explorer (tm!!) verschiebt. Hier kann man auch leere Klassen anlegen, in der Symbolleiste auf der Pfeiltaste neben 'New' klicken, 'New Class Folder' auswaehlen, und dann die Name eintippen.

Scripten mit Stufen

Wie kann man also die Klassen einsetzen? Nachdem die Scripte schoen sortiert sind, kann man nun im Settings-Editor die einzelne Klassen mit einem rechten Mausklick, und dem auswaehlen von 'enable' ein- oder ausschalten.
Dies spart schonmal, das zMUD z. B. mit irgendwelche Kampf-Triggers das System bremst, wenn Du nur am Chatten bist.
Ein- und ausschalten geht auch mit einen Befehl:
Ein - #T+ test
Aus - #T- test
Damit koennen wir einen Trigger bauen, der eine Klasse einschaltet, der sich dann selber abschaltet. Das ist zu vieles gut, nehmen wir ein Beispiel, ein Script welches automatisch jeden Detail im Raum zutiefst untersucht. Unter anderem muss es ein Befehl zum untersuchen von einen Detail abgeben, und den Ergebnis davon speichern. Da zMUD nicht wissen kann, wo ein Befehl startet und endet, fangen wir einfach alles, was nach dem 'untersuche XZY' erscheint, und hoeren auf, wenn der naechste Prompt kommt.
#TRIGGER {tueirgendwas;unt XZY;#T+ untersuche}
#TRIGGER {(*)} {Details=%concat(@Details, " ", "%1")} {untersuche}
#TRIGGER {>} {#T- untersuche} {untersuche} 577

Wenn wir keine Klassen hatten, werde das Trigger mit {(*)} als Muster immer aktiv sein, und ziemlich viel Speicher verbrauchen.
Uebrigens, das 577 gibt an, dass das einen 'Prompt' Trigger ist, d.h. auch die Zeilen ohne Newline werden untersucht.
Oder was einfacheres, den Trigger um die 'teile mits' farbig zu machen bewirkt sich nur auf die Zeile, die 'XZY teilt Dir mit:' beeinhaltet, um die folgende Zeilen einzufarben geht man genauso wie oben vor. Allerdings schickt das Mud ein Prompt nur nachdem man selber was eingegeben hat, und nicht nach Zeilen die vom Mud kommen, also muss man sich darauf verlassen, dass die folgende tm-zeilen eindeutig zu erkennen sind. Im Wunderland werden die Zeilen eingerueckt, also muss man alle Zeilen nach dem tm auffangen, und die Farbe wieder ausschalten, wenn eine Zeile ohne Leerzeichen anfaengt. (!) ->
#TRIGGER {* teilt Dir mit:*} {#COLOR red;#T+ tmfarbe}
#TRIGGER {(*)} {#IF(%begins("%1"," ")) {#COLOR red;#T- tmfarbe}} {tmfarbe}