Zugg Software :: View topic

Posted: Thu Nov 22, 2007 8:08 pm

In recent times, when discussing alarms and #wait, I have suggested the use of a wait trigger state to accomplish the same. I was told that this system is flawed because it will only fire on the first line to be received after the wait period is up, and so relies on having many lines spammed in order for it to be accurate. This seemed odd to me, as I distinctly recall the zMud beta when multistate triggers were first implemented, and being told by Zugg that this is what the wait trigger state was designed for - to replace the buggy #wait in many scripts. However, I took the word of those who had told me this, as they are much more advanced users than I.

Then, I noticed some behaviour which suggested them to be wrong.

Create the following in the blank session window:

Posted: Fri Nov 23, 2007 1:39 am

Caled, this isn't entirely. The reason you second state fires is that you are matching on a empty pattern ( with the default of option of trigger on new line ) so it will basically match on any line matched after three seconds. For the problem you are trying to address, it essentially works the same, but I just wanted to make that clarification.

Posted: Fri Nov 23, 2007 7:03 am

I am saying that this is not the case. No line was received, it still fired. If I put * in the pattern, it would fire on any line. Having a blank pattern means it fires when the timer runs out, independent of lines received from the mud. My example above shows this to be true.

Wizard Joined: 14 Aug 2004 Posts: 1269

I don't have a recent version of CMUD installed on this computer, so, Caled, maybe instead of "#sh line1", you can do a "#sh line1;#THREAD" for us, so we can see if a new thread is spawned for the wait. From your post, it does sound like <trigger type="Wait" param="x"> with no pattern operates differently to one with patterns... (and this does ring a vague bell in my head).

Enchanter Joined: 09 Sep 2007 Posts: 605

2.13 output for "#sh line1;#THREAD"

Wizard Joined: 14 Aug 2004 Posts: 1269

Looks good then, I guess. Zugg probably forgot how these particular alarm triggers worked. Wink

This will be more efficient then creating one time alarms (although you can have alarms that you just enable and disable). #ALARMs currently do not create new threads - it was changed again, but I suppose it may yet change for a 3rd time if a good reason comes up. It could be that these particular alarm triggers work essentially the same as #ALARMs, using the same underlieing code.

Posted: Sat Nov 24, 2007 8:57 am

I just like the controllability of it. Sure, alarms have #T+/-

But there is no #SET to finish it early AND execute the commands.

Plus, sometimes the first state of the trigger is not a dummy state, but an actual used/useful one, which makes your script neat.

Its also a pretty neat way to temporarily disable a trigger. I use it with my affliction tracker (that is, tracking my opponents' afflictions, not my own). I know they don't have salve balance for a second after I see them apply a salve.. so my trigger for them applying a salve has a blank wait state for 800ms.. which basically just disables the trig for that period after it fires. Its the more 'eloquent' solution than using an alarm or #wait.

Its just not really known about, though I think Larkin uses it occasionally in ACP.

Posted: Mon Nov 26, 2007 1:30 am

Posted: Mon Nov 26, 2007 2:03 am

I stand corrected, I'm not sure why it didn't work the first time I tested it but it does work as Arde describes.

Posted: Mon Nov 26, 2007 5:10 pm