Zugg Software :: View topic

Beginner Joined: 07 Nov 2000 Posts: 23 Location: Germany

From a previous posting I know that triggers can be priorized
by moving them up or down.

Now I sort my triggers in class folders that represent certain
features. Unfortunately I cant move up or down class folders.
Where do I know which class and respectivly trigger comes first?

Any hint?

Novice Joined: 20 Nov 2001 Posts: 35 Location: USA

I could be totally missing the point here, but if your ordered triggers are each in a class folder, then I would expect that in the last trigger of one class you'd have #CLASS (next class) 1 to turn that class on, then do something causing the triggers in that class to work, etc.

If that is the case, your folders don't need to be ordered. As they are activated, they are run, by something in the previous trigger.

Just prioritize your triggers as needed, and make sure at the end of each class, you tell it to enable the next class, and just keep going.

Hope this helps

-=Crymson

Reality is the effect of alcohol deficiency

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

quote:

I could be totally missing the point here, but if your ordered triggers are each in a class folder, then I would expect that in the last trigger of one class you'd have #CLASS (next class) 1 to turn that class on, then do something causing the triggers in that class to work, etc.

If that is the case, your folders don't need to be ordered. As they are activated, they are run, by something in the previous trigger.

Just prioritize your triggers as needed, and make sure at the end of each class, you tell it to enable the next class, and just keep going.

Hope this helps

-=Crymson

Reality is the effect of alcohol deficiency

Although it probably wouldn't matter much one way or the other, you CAN prioritize your class folders just like can your triggers and such. ZMud uses a straight top-to-bottom organizational scheme and it will always pick the first occurance of a class, trigger, button, etc to execute.

Here's a class listing as it appears in list form:

None
Autolog
Test1
TestBob
TestTerry
Test2
TestBill
TestJoe
System

Here's that same list in tree form:

None
|
|
|
Autolog
|
| ---TestBob
| |
Test1-------|
| |
| ---TestTerry
|
| ---TestBill
| |
Test2-------|
| |
| ---TestJoe
|
|
System

ZMud will look in None before anything else. Then it will look in Autolog. Next it will look in Test1. It will then look in TestBob and then TestTerry. After that it will look in Test2, followed by TestBill and TestJoe. Finally it will look in System.

It will do so in exactly that order every time a trigger fires, an alias is called, etc. If a class is disabled, it will obviously not look in it but the class will only be checked for disability at the appropriate position.

li'l shmoe of Dragon's Gate MUD

Beginner Joined: 07 Nov 2000 Posts: 23 Location: Germany

Thats the bahavior I also have noticed. However to stay with your example:

None
Autolog
Test1
TestBob
TestTerry
Test2
TestBill
TestJoe
System

If I have this classes, how can I move System further up? The Move up and down
buttons dont work at classes for me. Maybe this is a bug? Can anyone tell me if
moving of classes works for him?

Btw, I am using 6.22 beta.

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

Is View|Sort By|None selected?

Kjata

Beginner Joined: 07 Nov 2000 Posts: 23 Location: Germany

yes is selected...

meanwhile I have a workaround. If I select the "all classes" view,
I find a complete list of all triggers there. I can select triggers
there and move them up/down.
However this is a little bit confusing and it's dangerous if you
forget a trigger out of a certain class. IMHO it would be a great
feature to move class folders and as a result all of the included
triggers could be moved before or behind the triggers of another
class.

Just my few cents...

Apprentice Joined: 14 Nov 2001 Posts: 100

Umm... use unique names for your triggers so that you dont have to worry about order at all?

Beginner Joined: 07 Nov 2000 Posts: 23 Location: Germany

FYI:
Well, thats not a problem of unique names or patterns,
it's a question of design.

I use class folders to collect functionality of a certain
feature I want to create. This on the one hand allows me
to easily spread my scripts among some friends since all
you need to run that feature is in the class folder.

However this leads me to the problem, to have the same
trigger pattern in different class folders for different
features (just think of a duplicate HP bar trigger for
every feature that depends on the chars hit points)

Now some features have to be defined as "non fall through
trigger" which means in zMud language "Trigger on Triger"
disabled. As simple example here imagine a class for
highlighting triggers and a class for healing triggers.
When HPs drop below 50% they are colored red. When they
drop below 30% you launch your auto heal triggers. Now
to avoid the user gets nervous because of the red HP bar
I simply disable "Trigger on Trigger" on the healing
trigger. By this the healing trigger will hit and stop
further processing of any other trigger that would want
to match the same pattern for THIS line of text.
So the color trigger wont hit for this event.

This concept can work only if the healing trigger hits
before the highlight trigger and thats the point where
priority or launch order gets into the game.

Beginner Joined: 25 Nov 2001 Posts: 26 Location: USA

A bit of a late response, but this is an issue for me as well. I use classes as well to organize my triggers. While there are no Up/Down buttons for classes, there are ways to change their order.

One way is to edit the parent class script. The classes come in order in the parent class script, and you can switch around their order. The problem with this is that I haven't found a way to edit the <None> folder class script.

The other way is to cut and paste classes. I found that pasting a class puts it at lowest priority within wherever you paste it. Seems to work pretty well.

I've found some inconsistencies in zMUD's execution of triggers in order, going through subfolders and such. I've seen folders in a certain order in the Settings Editor, while the triggers in those folders execute in a different order when lines come in. I'm still fiddling with this, though, so I'll post again when I figure it out for sure.

Beginner Joined: 25 Nov 2001 Posts: 26 Location: USA

Alright, class priority has gone out the window, as far as I can tell.

I have two classes, NormalClass and OtherClass, inside a class RootClass. Depending on what subclasses I have enabled or disabled inside NormalClass, the NormalClass and OtherClass swap priority rankings. At the same time, though, inside the Settings Editor, NormalClass always comes before OtherClass when I'm looking inside RootClass.

Has anybody noticed this in a stable build? I've been using 6.24 recently, and I don't really feel like uninstalling and installing 6.16.

In any case, be cautious when using class priority to make things work. I trusted that it would execute consistently when designing my triggers, and it doesn't work because of what I described earlier. I might mess around in 6.16 tomorrow.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

quote:

Alright, class priority has gone out the window, as far as I can tell.

I have two classes, NormalClass and OtherClass, inside a class RootClass. Depending on what subclasses I have enabled or disabled inside NormalClass, the NormalClass and OtherClass swap priority rankings. At the same time, though, inside the Settings Editor, NormalClass always comes before OtherClass when I'm looking inside RootClass.

Has anybody noticed this in a stable build? I've been using 6.24 recently, and I don't really feel like uninstalling and installing 6.16.

In any case, be cautious when using class priority to make things work. I trusted that it would execute consistently when designing my triggers, and it doesn't work because of what I described earlier. I might mess around in 6.16 tomorrow.

Quite weird. I just ran a simple test (version 6.16), consisting of the following:

Class Test, containing classes Class1 and Class2. Class Class1 contains two triggers with the pattern of "This is a test" with each trigger IDed as test1 and test2 (duplicate settings cannot exist in the same class folder with the same IDs). Class2 also contained a "This is a test" trigger.

Entering the trigger text via command-line resulted in this unwavering output when both Class1 and Class2 were enabled:

This is a test
Class1 trigger
Class2 trigger
Class1 trigger2

This output is with Class1 disabled:

This is a test
Class2 trigger

This is the output with Class2 disabled:

This is a test
Class1 trigger
Class1 trigger2

And this is the output with both Class1 and Class2 disabled:

This is a test

Your flip-flopping, I would therefore assume, is the result of triggers not finishing their execution before other triggers began theirs. This would indeed seem that priorities have changed when in fact they really haven't. Priority doesn't affect what the triggers do when matched, it only affects the order in which matches occur.

li'l shmoe of Dragon's Gate MUD

Beginner Joined: 25 Nov 2001 Posts: 26 Location: USA

Well, I was showing trigger messages in zMUD, which appeared to say that one trigger was definitely going off before another one. I was under the impression anyway that a trigger with higher priority gets executed to its entirety before other triggers go off. If not, you can't depend on trigger priority to do much of anything, it seems.

Class priority worked most of the time, but it didn't sometimes, causing my triggers to behave incorrectly.