Zugg Software :: View topic

Newbie Joined: 05 Jan 2004 Posts: 2

Yesterday I want to write a alias like this:

#var arrived 0
#while (@arrived<>1) {#noop}
...

I just want to execute something after variable @arrived turns to 1.In fact,I write a trigger that will set @arrived to 1 when a room name is captured.The problem is, I really hate empty loop and it eats my CPU unbearably.Maybe expression triggers can solve this problem somehow(maybe it also loops and query the variable?[xx(]),however,I prefer to control the flow within this alias, just like calling a function and return -- not like jumping to another trigger -- 'cuz it is just like a nightmare if you want to debug it.Is there a function or something in zmud can resolve this problem? Interruption?

Maybe I am too cupidity... Very Happy

Apprentice Joined: 26 Sep 2001 Posts: 124

I assume that this loop is in the middle of some alias?
If so, i would just create a secondary "sub" alias which contains the instructions for what you want to do when the arrived variable changes to 1.
Then all you have to do is set the trigger that changes the arrived variable, to initiate the "sub" alias.

Or, if you really wish to do the whole thing from one alias, you can call that alias from the trigger that sets arrived to 1, but specify a special parameter (such as "trigger_parse"), so that the alias knows which instructions to perform.
For example:

#if %1=="trigger_parse" {Do whatever you want to do when the alias is initiated by the trigger} {Do whatever is done normally}

Of course the parameter does not have to be %1, you can make it %2 or %3 or whatever suits your alias.

I cant really explain it any better since i dont know what your whole alias does.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

You clearly intend to take some action once you arrive. That being the case, it would be better to "do that action when you arrive" (requires one action) instead of "not doing it as long as you haven't arrived" (requires many nonactions). A self-deleting (#TEMP) trigger would be one solution. I've used ... as the action, because that's what your little script snippet had.

#VAR arrived 0
#TEMP arrived1 {@arrived = 1} {...} {} {exp}

I also used the ID field to assign a name (arrived1) to the trigger. This isn't actually necessary, but it's a good idea. It allows the trigger to be overwritten if you run the alias a second time before the trigger fires. Without it, you can easily get several identical triggers which will all go off at the same time.