Zugg Software :: View topic

Apprentice Joined: 06 Apr 2004 Posts: 173

I've been thinking a lot about the trigger priority, and I know you already have it designed a certain way, but since it's still very new I thought I'd give you my ideas about it.

- Having priority assigned to EVERY trigger gets rid of a lot of the optomizations that might be possible thru some smart regex processing (that might be implemented much later)

I was thinking that instead of ordering every trigger you might have:

Priority High (0000-99999) - these would be numbered triggers. and you could assign the number.

Priority Normal - these would be unnumbered general triggers whose position could be optomizable by using really good hash trees on the trigger pattern.

Priority Low (0000-99999) - these would be numbered reverse order so that a 0 would mean it fires last, 1 next to last, etc.

One of the reasons I'm writing about this is because I was looking for ways to guarantee that a trigger would fire last, and since there aren't any #EVENTS that control leaving the trigger loop, and that there aren't any ways of ordering the tail-priority events, I decided to write about this.

Anyway, cheers.
looking forward to the July release.

Graham Mueller

Posted: Sat Jun 30, 2007 12:28 am

There is, it's just not as easy to manage as I'd like. It'd be nice, as I said a while ago, if there were a scripting function to set, or edit, or compact or whatever the priority values. As it stands, you can do this just by making your tail-priority triggers have priority numbers higher than your other triggers. Triggers don't need unique numbers, so you can create your own priority levels using the current system.

I imagine the new XML format in the next version will help some with this.

Apprentice Joined: 06 Apr 2004 Posts: 173

problem with that is, when new triggers are created you're not guaranteed that their priority is lower unless you manually set everything... I hate being forced to specify everything

EDIT: Thanks for the reminder that pri values need not be unique Fang. I think this will allow me to at least get something I was working on done.

EDIT: Default would be Normal priority, so you wouldnt have to "set" it during trigger creation.
I think only about 1% of all triggers need a value anyway, most are order independent- which is why I suggested it.

Posted: Sat Jun 30, 2007 1:32 am

Well, under the system you suggested, you'd have to specify which catagory the trigger falls into anyway. You might as well do it yourself using the current system.

Apprentice Joined: 06 Apr 2004 Posts: 173

that would work if I never needed to import someone elses triggers... but supposing that I did, I'd have to rework all of their values to the constraints of my current triggers... So much for independence?

hehe, it's an idea, but I still think it's a good one.

Posted: Mon Jul 02, 2007 5:41 pm

My experience over the years with zMUD is that most people want to be able to directly see and control the exact order of trigger processing. I don't want CMUD to "magically" try to optimize the trigger order...then it's very hard for the user to see what order the triggers are executing to debug possible problems. Also, since I'm using the PCRE regular expression library, I'm not going to be writing my own hash tree or anything. Current speed bottle necks are in the script processing and not the trigger processing.

With the current system, you can easily see the exact order that triggers are processed (sort by priority in the settings editor). You can easily drag/drop triggers to new positions, or manually edit the priority numbers.

As Fang mentioned, I'll eventually add functions to set/retrieve priority values, which will give more control over this within scripts. But the current priority system is very integrated into the core CMUD code, so I don't plan to make any massive changes to it.

Apprentice Joined: 06 Apr 2004 Posts: 173

Posted: Tue Jul 03, 2007 5:14 pm

Yes, I know that trigger priority isn't unique. But the order that you see the triggers listed in the settings editor when Sort by Priority is turned on, is still the exact order that the triggers will actually be executed.