Zugg Software :: View topic

Beginner Joined: 06 Apr 2003 Posts: 15

Hi there

is there any possibility to tell zmud to only firering one trigger, and all other triggers will not fire (although they have a matching pattern)? some examples

#TRIGGER {^(*) sagt: *$} {...}
#TRIGGER {^(*) teilt dir mit *$} {...}

so every time you get a 'bla bla teilt dir mit: blabla sagt: text'
both triggers will fire

next example:

'^* triffst *.$'
'^* triffst * hart.$'
'^* triffst * sehr hart.$'

if you recieve the third line all 3 triggers will firing. Ok you can get around and use only the first trigger and do some #if (%ends...), but thats only a workaround

and last but no least:

for mud i recieve:

line1
line2

ok easy: a trigger with a #cond wihtinlines=1 and thats it.
But line 2 can be also recieved alone, and i have a second trigger of line2
but now when i recieve the two-lines-version, also the second-trigger will fire.
yes i know, i can do in the code of trigger1 state 0 a #t- but thats also a workaround.

So why not implementing trigger priority so that only the trigger with the highest priority will fire, ore, if two trigger have the same priority they will both fire.
For the beginning an option like 'Prevent other triggers from firing' will be ok, so the most problems like this examples will be obsolet.

So i hope my english is understandable

Bye

Posted: Sun Mar 21, 2004 9:45 pm

There are features in place to do all of that.

If you want to only disable a single trigger, you can assign a trigger ID to that trigger to enable or disable it:

Code:

#TRIGGER test1 {^(*) sagt: *$} {...}

This trigger is given a trigger ID "test1". You can enable it by doing #t+ test1, and disable it with #t- test1. You can check its status with %trigger(test1) or %class(test1).

If you want to set up an entire class of triggers/variables/aliases/etc. for enabling and disabling:

Code:

#TRIGGER {^(*) sagt: *$} {...} test2
#ALIAS flee {#3 fl} test2

The above trigger and alias are placed in a class called "test2".
Now you can turn them on with #t+ test2, turn them off with #t- test2, and check its status with %trigger(test2) or %class(test2).

If you have 3 triggers that will all fire on a single pattern, you can assign which one to always fire first on the same pattern. zMUD fires triggers sequentially. There are two ways to do it:

First, in your settings menu, set View|Sort by... to None. To help you focus on triggers, set Show|Triggers. Now you can choose between detail or list view, highlight a trigger in that window and then you should be able to move it up or down in the list by clicking on the Up or Down buttons in the Standard buttons toolbar. The triggers at the top have the most priority. Make sure your settings are saved if you want to keep these changes.

Second, you can assign the priority of triggers when loading fresh triggers. Importing or entering triggers into your command-line will assign the earlier trigger entries with higher priority. However these will always be of lower priority than existing triggers, unless triggers are overwritten.

Beginner Joined: 06 Apr 2003 Posts: 15

Thanx very much for your answers

The enabling and disabling of triggers an classes i alredy know and that's not the problem.
I tried servaral things an i think i get it now, but that are all crude workarounds

My Example1 was an error from my side, this thing has nothing to do with trigger priorities, but with better and exact trigger patterns.

For example 2 I have now this 4 Triggers (in this order-> thx for the tip with the sorting)

#TRIGGER {Du triffst * sehr hart.$} {#T- trefftrigger1;#T- trefftrigger2;...code1...}
#TRIGGER trefftrigger1 {Du triffst * hart.$} {#T- trefftrigger2;...code2...}
#TRIGGER trefftrigger2 {Du triffst *.$} {...code3...}
#TRIGGER {Du triffst **.$} {#T+ trefftrigger1;#T+ trefftrigger2}

You see, its a very crude workaround, and the 4th trigger must be there to reaktivate the other triggers cause for next line recieved from the mud they must be all active. This crude pattern in trigger 4 must be there cause zmud do not allow two or more triggers with the same pattern in the same class

With Trigger Priorities and an 'Fall Through' Option like in TF this coul be done so simple, only the first 3 Triggers the first one with a higher priority then the second one (and so one). fall-through off and no aktivating and deaktivating is needed.

So as Feature Request:

Implementing of Trigger Priority, and an Fall Through-Option
With Fall Through off only the matching trigger with the highest priority will fire (and of cause zmud can save cpu time as no other triggers must be tested)
with Fall Through on, the matching trigger with the highest Priority will fire first, next the matching trigger with the second highest Priority (if there also fall trough on, the next(third) matching trigger with the third highest Priority, and so on...)
With this you can save many of this T#+ and T#- things
For backward compatibility, all old triggers should have Fall Through default on, so the behavior of the 'old' triggers is the same as before

so hope my wishes are not too much

So Long

Posted: Tue Mar 23, 2004 2:20 am

Here are the two possibilities I can find.

This applies to example 1,

Posted: Tue Mar 23, 2004 2:27 am

Yeah basically I changed: #TRIGGER {Du triffst **.$} to #TRIG {^}.

By the way, the *$ in #TRIGGER {^(*) sagt: *$} is redundant too.
Since, #TRIGGER {^(*) sagt: } would do the exact same thing.

Posted: Tue Mar 23, 2004 2:59 am

As I said the features are in place, there are so many other possibilities:

You can still eliminate all these #t- #t+ with better patterns.
For example,

#TRIG {Du triffst (*).$} {#if %ends("%1"," sehr hart") {...code1...} {#if %ends("%1"," hart") {...code2...} {...code3...}}

or,
#TRIG {Du triffst * sehr hart.$} {...code1...}
#TRIG {Du triffst *{^sehr} hart.$} {...code2...}
#TRIG {Du triffst *{^hart}.$} {...code3...}

Better handling of code, you can append code3 on top of code1 before executing them.

Enveloping everything into a single class, since they are all only run once per line:
#TRIG {Du triffst * sehr hart.$} {#T- trefftrigger;...code1...} trefftrigger
#TRIG {Du triffst * hart.$} {#T- trefftrigger;...code2...} trefftrigger
#TRIG {Du triffst *.$} {...code3...} trefftrigger
#TRIG {^} {#T+ trefftrigger}

IMHO, it all boils down to your algorithm.
Implementing unneccessary semantical structures in a script simply creates more overhead. Razz

Disabling single triggers may seem inefficient, but it is not always the case.