Is it possible to introduce a waiting time between the execution of one trigger action and the following one, or, alternatively, to introduce a stop before executing the next trigger action? All trigger actions are performed in rapid succession and it is only possible to see the final total effect and not the intermediate ones.
You could do an “empty” trigger action with an associated report trait that contains an Alert. E.g., your primary trigger is A, which should do B and C, but you want a pause between B and C.
A -> B -> C
So let’s introduce another trigger action D between B and C, and a report trait R that reacts to D
A -> B -> D (triggers R) -> C
and R contains an Alert line in the report attribute. This should make the trigger chain stop after D and wait for the user to dismiss the Alert pop-up. The D trigger action has no actionKeys.
In one of my modules, flipping over exploration tokens has one of a few effects that each require some bookkeeping, and the token is immediately discarded. Instead of relegating everything to a report, I had an alert pause so the face up token could be seen, and the effects announced. When the player clicks OK, everything is resolved.
Whether this is better than just cutting out the additional click and reporting what happened is debatable, but it works.
The case I was investigating was trying to make it happen between actions in a single trigger. Having delays between different triggers is a different issue.
@Benkyo are you saying that running a series of different triggers, an Alert() in a later trigger reveals the changes from the Triggers up to that point?
@panther_2010, which where you looking for? Delay (with refresh) between triggers or between Key Commands in a single trigger?
What if Alert() were cloned and the message parts replaced by the delay functionality ?
If Alert() is working in some cases to refresh the UI, then it’s because it is displaying a UI element, the message. The problem I had was that a simple delay does not affect the UI, so it never updates.
I just checked, and no. In my case, a single trigger
changed two layer traits, revealing the other side of the piece
set a dynamic property the value of which was an Alert()
did the bookeeping
discarded the piece
None of those involved further triggers.
The effect is the alert popup while the piece is shown after the layer changes. The bookkeeping and the discard happens after the alert is acknowledged.