Zugg Software :: View topic

Apprentice Joined: 19 Nov 2010 Posts: 119

So..why is alarm a trigger now, isnt there a #waitfor command and multistate triggers that can wait to already utilize something like that ?
So If i wanted my #alarm to capture %'s i would make a proper trigger for that.

In Zmud this simple trigger would have worked perfectly fine:

#trigger (%w) tells you 'hello' {#alarm hello {15} {#var hellotarget %1}}

This would set a target for my helloalias back to %1 every 15 seconds, even if i changed it afterwards.

I know its a silly trigger example but it explains my problem perfectly without refering to miles of complex script that relied on this.

I could use a new variable for every person that tells me hello, to keep that name permanently on record so my alarm can access it - but why ?

So, How do i go about this in Cmud ?

Wizard Joined: 22 Mar 2007 Posts: 2320

#alarm always was a trigger, even under Zmud.

Try the following:

Apprentice Joined: 19 Nov 2010 Posts: 119

What if someone else tells me hello, is it going to reset the $target to that new person, start another timer and i will end up with 2 timers setting the same $hellotarget to $target, hello ? Smile

I do want to have 2 timers if someone else tells me hello, but i also want them to assign different names to the $target, just like a %1 would.

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

I forget what happens with $target in this case, but if it's not expanding prior to the execution of the #alarm definition (to produce the command #VAR hellotarget whateverwasin%1) then your variable will be reset to a blank value as soon as the alarm fires the first time.

Regardless, though, you will still only have 1 alarm. Had you not included the alarm name, your use of #ALARM would have created multiple alarms.

Apprentice Joined: 19 Nov 2010 Posts: 119

Then this is not an acceptable options. The solution i personally know is
#trigger {(%w) tells you 'hello'} {# var target%1 = %1; #alarm %1 {15} {#var hellotarget @target%1}}

This will create new alarms with different names every time someone tells me hello and it will assign a different value to @hellotarget every 15 seconds depending on which alarm fires first.

This is what i want to accomplish but avoiding the creation of new variables every time someone tells me hello.
Again, this is very easily accomplished in Zmud without any need for variables, why is Cmud so bad at this ?

Wizard Joined: 22 Mar 2007 Posts: 2320

I'm confused--you actually _want_ to create multiple alarms that will each reset the same variable hellotarget to different values? That is _not_ what the Zmud code you posted at the beginning would do. It would create a _single_ alarm trigger named "hello" which would be changed every time the "(%w) tells you 'hello'" trigger fires, and that's what I tried to show you how to do. Did you try it?

If you actually want multiple alarms, do you realize that they will be repeatedly changing the same variable over and over? That is, if at time 0, the trigger fires with a target of "Fred", and at time 5 seconds, the trigger fire with a time of "Barney", then at time 15 seconds, @hellotarget will be set to "Fred", at time 20 seconds it will become "Barney", at 30 seconds it will become "Fred" again, at 35 seconds "Barney", and continue alternating indefinitely? Somehow I doubt that's what you intend. Please explain exactly what you do want, and I'm sure we can show an easy way to do it in Cmud.

Apprentice Joined: 19 Nov 2010 Posts: 119

Yep, i do realise what i said and i do realize what i want and what you explained in the second paragraph is exactly what i want. And you are right - i did make a slight mistake in the first trigger i posted. The trigger that i do want is.

#trigger {(%w) tells you 'hello'} {#alarm %1 {15} {#var hellotarget %1}}

This will make sure that i will have multiple alarms with the name of the person that told me hello as its ID and what it would do is set a variable named hellotarget to different values as the alarms expire.

I know it sounds weird, but we all play different muds and it makes complete sense on the mud that i play :)

Wizard Joined: 22 Mar 2007 Posts: 2320

All right, if you're sure. And you understand that the alarms you are setting will not "expire" but will repeat indefinitely?

If you're sure, try:

Apprentice Joined: 19 Nov 2010 Posts: 119

Thanks Rehab, managed to test this today and your solution worked. Was also told to try #exec {#alarm} which worked fine and expanded the %1 into the alarm

Apprentice Joined: 19 Nov 2010 Posts: 119

Hey again guys, ran into another slight problem i cant find a obvious solution - if use #alarm {time} {command1} my next alarm with the same {time} will replace the {command1} with {command2}, is there any way to make #alarm {time} report both {command1 and command2} after i use #alarm {time} {command2}.

Thanks!

Apprentice Joined: 19 Nov 2010 Posts: 119

I also found another weird occurence, when i run a #loop trigger to activate an alarm:

#loop 1,3 {#exec {#alarm {+2} {#read 1 %i}}}

this will read lines from my test file - but its out of order, sometimes it will start at line 3 first and then go to line 1 and then read line 2, is it broken ? Shouldnt it read things in order the #alarm was created where each loop slightly delays the creation of the next #alarm?

Apprentice Joined: 19 Nov 2010 Posts: 119

#loop 1,3 {#exec {#alarm {+1} {#show %i}}}

Will show different numbers ranging from 3,2,1 to 2,1,3, most common occurence was 3,2,1

#loop 3,1 {#exec {#alarm {+1} {#show %i}}}

Will most often show 1,2,3 but will sometimes show 2,1,3 and 3,2,1.

Am i doing something wrong ? My cmud version is 3.32

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

#EXECUTE is such a slow command that we recommend nobody ever uses it, and that if they ever do something that requires legitimate use of this command they figure out a different way that doesn't require #EXECUTE.

Apprentice Joined: 19 Nov 2010 Posts: 119

Could anyone pleaase tell me how i could make my trigger open a file, read a number of lines through the #loop command from it, close it almost instantly and have everything that was in the text file read to the person who requested it in the exact order with any delay that he specified before opening the file. I think im at my wits end here.

#if i do #file 1 test; #loop x,x {#read 1 %i;#wait xxx}; close 1 it results in the text file being open for awhile as it #waits to read the lines from it.

Posted: Mon Nov 22, 2010 12:07 am

Not sure what the text you are firing off of, but if you are wanting it to tell the stuff to another player, or to say it out loud, you might be better of using %read instead of #READ.

#READ executes the line of text from the file as if it was a command entered on the command line.
%read just returns the line of text as a string for you to manipulate.

e.g

Apprentice Joined: 19 Nov 2010 Posts: 119

Thank you, that is awesome!