Zugg Software :: View topic - Puzzled on alarms with state-triggers

Novice Joined: 24 Jan 2001 Posts: 47

Alright everyone, I've got all of some elaborate scripts for learning skills on Dragonrealms made into rather simple multi-state triggers. However, there is a part where one needs to wait for roundtime... after roundtime, and if the trigger is still enabled, I would like the trigger to start over again at state one -- ONLY IF THE TRIGGER IS STILL ENABLED (I have an alias to turn on/off multiple of these skill-triggers at arbitrary intervals, in order to speed up learning).

Therein lies my problem.

The best solution would seem to be an Alarm state... this would do exactly what I want to, and if the trigger is disabled, the Alarm state's commands won't work. However, a variable interval given for the Alarm is loaded at the beginning of the execution of the ENTIRE TRIGGER, ie state 0. The roundtime isn't calculated till state 1, and the alarm is state 2. This, it is using in stage 2 the roundtime from the LAST run-through, which is no good, as the roundtime varies.

The other, more kludgy option, is to set a temp alarm from state 1... ie #alarm +@roundtime... the problem is, however, checking whether the trigger is enabled. There doesn't seem to be a way, as %trigger does not currently work as I would think it should, and there is no replacement AFAIK.

Help!?

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

Use the %t1...%t99 syntax to get the roundtime from the previous state and use that as your alarm time. Details on %t1...%t99 can be found in the Support Library's Advanced Triggers article.
Accessing patterns from previous states

LightBulb
Advanced Member

Novice Joined: 24 Jan 2001 Posts: 47

Hmm. That's less than ideal for this situation. You see, the trigger pattern for roundtime is GSL q, and determining the actual roundtime is somewhat complex. I've got a bit of scripting that gets the roundtime every time, decrements it correctly, etc, and the current roundtime is always stored in @roundtime.

To use %t1 I would need to actually capture the roundtime in the previous state, instead of just waiting for GSL q, then advancing the state... actually, it wouldn't even really be possible unless I used a text pattern trigger to catch the user display of roundtime.

Wanderer Joined: 26 Jan 2001 Posts: 74

Can you show us the sticky bit of code?

Ana

Novice Joined: 24 Jan 2001 Posts: 47

Sure, one sec...

Here's an example of the actual triggers that do something, this one does stone removing/combining:




#TRIGGER "stones_trig" {You count out one stone from the %w stones.} {} "Learning" {disable}


#COND {q} {#MATH int_waitfor {@roundtime + 1}} {gsl|disable}


#COND {@int_waitfor} {combine my stone with my other stone} {alarm|disable}


#COND {You combine your %w stones.} {} {disable}


#COND {q} {#MATH int_waitfor {@roundtime + 1}} {gsl|disable}


#COND {@int_waitfor} {remove 1 stone from my stones} {alarm|disable}

Here's the meta-alias, that serves to execute all of the learning things in a loop:




#ALIAS do_appstones {#T+ app_trig;appraise my bundle;#alarm +50 {#if (@appstones = 1) {#T+ app_pauser}};#alarm +100 {#if (@appstones = 1) {#T+ stones_pauser}};#alarm +150 {#if (@appstones = 1) {#T+ per_pauser}};#alarm +200 {#if (@appstones = 1) {#T+ foc_pauser}};#alarm +250 {#if (@appstones = 1) {#T+ jugg_pauser}};#alarm +300 {#IF (@appstones = 1) {#T+ harn_pauser}}} "Learning"

Here's what I call the "pauser" trigger for this one, it serves to end the above process (stones) cleanly (after combining), and to "clean up" after:




#TRIGGER "stones_pauser" (%state(stones_trig) = 5) {#STATE stones_trig 0;#T- stones_trig;#T+ per_trig;#MATH waitfor {@int_waitfor + 1} {} {Learning}} "Learning" {disable}


#COND {@waitfor} {put my sjatmal stones in my greatcloak;perceive;#STATE stones_pauser 0;#T- stones_pauser} {alarm|disable}

Wanderer Joined: 26 Jan 2001 Posts: 74

I'm presuming that the 'stones_trig' trigger is activated by an alias that you didn't post, since I don't see how it would fire in the first place.

Honestly, since I'm a big fan of Occam's razor, I'm going to have to stick with what I said in the last thread, and advise picking up the command buffer from the finished scripts folder. With it, your elaborate trigger could simply be replaced by...

#TRIGGER {^You count out one stone from the %w stones.$} {#ADDI commands "combine my stone with my other stone"}
#COND {^You combine your %w stones.$} {#ADDI commands "remove 1 stone from my stones"}

The command buffer would avoid having to calculate the RT each time, and it could be shut down by whatever conditions you thought applicable through #T-. You could even integrate it directly into the two states through a #IF statement, which means you could eliminate the 'stones_pauser' trigger as well.

You could continue to hammer your way through the task like you are now, and the very talented people here on the forums I'm sure will do their best to help, but I still think the command buffer would be the simpler solution.

Ana

Novice Joined: 24 Jan 2001 Posts: 47

I don't think a command buffer is necessary at all, nor is it a proper solution to the problem.

A command buffer stores all the commands in a string list, and pops one out and executes it when roundtime is up.
It is trivial to code, and completely not what I want here.

I want commands executed under specific conditions at specific, adjustable times, in specific, adjustable patterns, and I want them to
end in specific, adjustable ways.

This is not "hammering through," in an effort to make it more simplistic and elegant I recoded my whole system as state triggers
instead of the aliases I was using. I find that this manner of doing it is quite nice indeed, and I DO NOT want to replace it
with the sort of code I wrote 3 years ago before I figured out that having a full buffer and all of a sudden needing to do
something NOW sucks!

This is on the verge of perfection, I just need a way to get this variable-length alarm to work! Help, somebody, anybody!

Novice Joined: 24 Jan 2001 Posts: 47

Here's my current solution, replacing:




#COND {q} {#MATH int_waitfor {@roundtime + 1}} {gsl|disable}


#COND {@int_waitfor} {combine my stone with my other stone} {alarm|disable}

With:




#COND {q} {} {gsl|disable}


#COND {@roundtime = 0} {} {exp|disable}


#COND {1} {combine my stone with my other stone} {alarm|disable}