Zugg Software :: View topic

Newbie Joined: 04 Oct 2003 Posts: 8

This is just a hypothetical question here that has to do with how triggers are handled. My question is, what happens when you have a trigger defined that takes a while to perform, say a second or two. Lets say it is sorting a giant string list of names (I don't know how fast or what algorithm the sort uses, so maybe it takes a while, but probably doesnt... ). So lets say I am sorting this giant list of names, when text scrolls by on the mud really fast and the next input sets off another trigger which take the top name off the list and does something with it. Then the next line sorts again.

Let me try to explain this better.

The output would be something like this:

This line sets off a trigger to add a name to the list and resort it.

This line sets off a trigger to grab the top name off the list.

This line sets off a trigger to add a name to the list and resort it.

So those 3 lines scroll by really fast and fire off the trigger multiple times, and lets say the 1st line grabbed a name that should go in the first sorted spot on the list, and the second line expects to grab that name that was just added. If the sort takes a long time, does zmud simply queue the triggers and run each one as the last one finishes, or does it try to run all the events as they scroll by in the mud?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Short version: zMud runs a first come first served basis in trigger scripts.
Long version: all triggers are tested at end of line (for those set to fire on end of line), and end of packet (for those with "prompt" flag). All of those that match are then fired. Thier scripts are placed into a queue based on thier order in the settings (this allows you to control the order the scripts proccess). The scripts are proccessed from begining till end before the next trigger in the queue is proccessed. Once all are done then the next trigger test can be done.
The exception to this is looping commands within scripts. When a looping command is encountered zMud assumes it might take a while and moves on to the next script in the queue. Once all scripts in the queue have had a chance to start triggers are checked, then loops are revisited. When that passes then the loop and all remaining portions of the script are preformed until another loop or end of script removes the whole trigger from the queue. The #PRIORITY command overrides this behavior by making it so the loop does not put the script on hold. Looping commands include #LOOP, #LOOPDB, #FORALL, #REPEAT, #UNTIL, and #nnn.

This may be slightly inaccurate, but is mostly right. Zugg posted a higly detailed explanantion somewhere, but I can't find it.

Newbie Joined: 04 Oct 2003 Posts: 8

That should be enough info... Thank you for the prompt answer :) Great forums here :)