Zugg Software :: View topic

Posted: Fri Dec 22, 2006 8:55 pm

As I understand it "#abort" will abort all processing within the current block,
while "#abort 1" will abort all processing currently going on.

If I type "#abort 1" in command, it does do the trick to stop all current processes.

But when I put "#abort 1" in Triggers it was unable to stop some trigger like below.

#tr {Zugg tell you: stop} {#abort 1}
#tr {Monster is just walking into this room} {berserk;#wait 10000;powerup;berserk;#wait 10000;powerup;berserk;}

I defined when monster walking into this room I will berserk it. but if Zugg tell me stop I wish to stop the rest of powerup and berserk. But even I try to tell it stop. And trigger is triggered. But the "#abort 1" seems only abort itself. And the rest of "#wait 10000;powerup;berserk;" are still processed after I triggered {Zugg tell you: stop}.

It's weird that "#abort 1" does the trick when I execute it in command to stop all the rest of command but not working when I put "#abort 1" in the trigger.

Anyone have any idea about this? I have tested zMUD 7.21 & cMUD 1.24. They all act same way as I mentioned.

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

#ABORT 1 does not work against multiple triggers. Only on the trigger it's used in.

#ABORT only works on the innermost set of curly braces. If in an #IF, it will abort the #IF processing and continue on with whatever was after the #IF.

Also, #WAIT stops all trigger processing for the duration, which actually DOES stretch across multiple triggers (it also pauses). This is why #WAIT is so bad, especially if you have time-sensitive stuff you need to work on.

Posted: Fri Dec 22, 2006 11:00 pm

Thanks for your fast and helpful respond. Very Happy

#WAIT is so bad, so do you have any recommendation alternate way to delay fire rest of current trigger command?

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

#ALARM, when used with the +duration option, will allow for a one-time alarm that deletes itself after firing:

#alarm +10 {#say RAAAAAWR!}

#ALARM also has more permanent options:

#ALARM *10 {stuff} //executes every 10 seconds
#ALARM -1?:00 {stuff} //executes every hour from 10:00 to 12:00, and possibly 1:00 as well
#ALARM 2:59 {stuff} //executes when your system clock reaches 2:59

If you just want to delay a multi-state trigger, you can use a wait-state condition:

#trigger {blah} {blah}
#condition {} {blah} "wait|param=100" (I don't recall if this is in milliseconds or just seconds)

Posted: Fri Dec 22, 2006 11:42 pm

Thanks MattLofton!!
That is really brief and helpful!! Very Happy

I think I got lots work to fix my triggers now Rolling Eyes

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

When using #ALARM it's best to name them too, otherwise you can lose track of them and they can carry on firing when you don't want them to
#alarm testalarm +4 {#say RAAAAAWR!}
etc

that way you can also cancel an alarm (since an alarm is just a type of trigger)
#untrigger test

Posted: Tue Dec 26, 2006 11:41 am

Now I found something is not supposed to be happened in cMUD 1.24.
When I have a session with 2 window or even more. #alarm in "window A" is friezed after I have the focus on "Window B".
And When I put the focus back to "Window A". The #alarm back to work.

Ex:

Windows A: #alarm (* +10) {#say tick!!}
If I switch to "Window B" for 43 secs then switch back to "Window A", this alarm will be frieze for 43 sec than back to working.

Is it suppose to be normal? If so, is there a better solution to have alarm like what I expected?

PS. I Know I probably should post in cMUD forum but the question is related with this thread. And I am wondering is zMUD act same way or just cMUD.

Posted: Tue Dec 26, 2006 11:45 am

I am trying to adapt into cMUD. But cMUD seems very unstable in my Windows XP. It often crashed itself. I wonder if cMUD stable on the others computer.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

I've posted the #ALARM bug in the CMUD forums cojad. It's not the same behaviour as zMUD and I'm guessing it's a bug
http://forums.zuggsoft.com/phpbb/viewtopic.php?p=103895

As for CMUD crashing often, is it a particular trigger or alias that's causing the crashes? It's been pretty solid for a while on my laptop in both XP and Vista, and my desktop in both Server 2003 and Vista