Repeated toggling a message with flags using Space gets stuck

[virgo47]

I wanted to create to myself a simple mission with an optional help in a message that I can trigger ON and OFF repeatedly with Space. I decided to employ "X: START WAIT USER RESPONSE" to toggle that message on and off. I soon understood that FLAG IS TRUE is not the most reliable condition compared to TIME SINCE FLAG - especially after the start, however, I got into this reasonably simple design:

• MISSION START just sets an init flag,
• This will be checked by ONCE trigger with TIME SINCE FLAG - this will play the intro sound and sets the show flag:
  
• And then there are two virtually symmetric switched conditions, one to show the message:
  
• And one to hide it:
  

Flag OFF for both may be an overkill, I just wanted to be sure. The problem is, that if I press the space in a rapid succession, the triggering may get stuck in either position - here in ON and with a debug output for both flags (via some F10 OTHER custom script):

When it gets stuck in OFF (seeing fainting away in the picture above) the flags are reversed.

This indicates that the code in "to show message" ran (ON is displayed) and if space is hit, hide flag will be set - and it is. But the problem is that the "to hide message" trigger is not triggered - which indicates that it probably didn't register the hide in FALSE state before it got to TRUE again. And this is where I don't understand why.

I know the mission "code" is not exactly symmetric, one of the triggers is behind the other - but it can get stuck in OFF state as well (tested) - so this is not the factor (or not the only one at least). But my thinking is:

• To show the ON message, both flags were set to OFF before that, then there as the waiting for user response which would set hide to true.
• Even if it was fast (it seems the user response may the flag anytime between the trigger 1s cycle)... it would have to happen between considering the first switched condition (to show message) - which would have just successfully run - and the other condition? Because if at least once the "to hide message" was run with hide flag OFF, it would have to trigger the next time (hide flag clearly being on in the stuck state).

What kind of (non-)atomicity or parallelism is eluding me here?

Now, I have fixed version - the easiest fix being using the TIME SINCE FLAG instead of FLAG IS TRUE - it just gets a bit laggier, but no problem. But I'd like to understand the runtime model of this. Right now I don't get the problem, even with help like https://wiki.hoggitworld.com/view/DCS_editor_triggerBasics#Switched_Condition

I'll be thankful for your insight. (Mission that can get stuck included. EDIT: Used Su-25T and "init" flag is gone in favour of TIME MORE.)

 

Su-25T - message toggle test.miz

Edited April 17, 2024 by virgo47

[TEMPEST.114]

Firstly, have you read this?

It clearly explains SWITCHED CONDITION and some of the Trigger issues you're running into. 

Here's what it says about the triggers you are using:

SWITCHED CONDITION. The trigger will perform the set action(s) every time the
trigger’s condition is checked and evaluated as true and its previous state was false. For
example, such a trigger can be used to show a text message whenever a particular unit
enters a trigger zone. The first time the unit enters the zone, the trigger action will be
activated, because the previous check of the trigger conditions was evaluated as false
(unit was not in zone). The trigger will not activate any longer as long as the unit is
inside the zone, because the previous check of the trigger conditions will be evaluated as
true (unit remains inside zone). However, if the unit exists the zone and then re-enters it
again, the conditions will have once again switched from false to true and the trigger
action will be activated.

Trigger Behavior:
Condition: Evaluated Continuously.
Action: Repeatable, Once per condition-set changes from "False" -> "True". Actions will
be performed again on the next "Switched state-change".
Example:
You want to perform a action each time a unit enters a zone. This differs from them
"being in a zone".
• Add a "SWITCHED CONDITION" trigger.
• Add a "Unit in Zone" condition, select a unit and zone to check.
• Add a "Message" of "A unit is trespassing our Zone!"
Now each time the unit enters the Zone you will get the message Once. The unit needs
to leave and reenter the Zone again to show the message again.



4. MISSION START. The trigger will only be checked at mission start. For example, if you
wanted to set multiple units to a random activation, you would use this option to
evaluate this condition and determine which units are included in the mission according
to the set percentage.

 

Note this part: 'The trigger will perform the set action(s) every time the trigger’s condition is checked and evaluated as true and its previous state was false.'

This catches a lot of people out. 

 

Secondly, if you upload a mission, try and make sure it uses generic units everyone has, unless it's unit specific.

 

Thirdly, your script:

cm = cm or {} -- This is a pointless test, this script gets executed once and you only need to create the table cm by using cm = {}

 

Fourthly, the Mission Start trigger to turn a flag on is unnecessary. You can just use the trigger ONCE -> TIME MORE -> FLAG ON(), but the whole 'init' variable  is redundant too. 

 

Fifthly, All TRIGGERS and their CONDITIONS are tested in sequence and only when they are true are the ACTIONS performed. If the trigger is ONCE, then once the CONDITION is true and the ACTION is executed, then that entire trigger is removed from the list of triggers to process on the next loop. I believe each loop is 1 second. 

MISSION START is executed at mission start, obviously, but having a condition there that can fail means it won't get called again, because the trigger is only at MISSION START. You need this to load your script, but don't do any conditions or other things in it other than setup stuff, unless you can be certain those conditions are ready and set up AT mission start.

You have a typo on the the flag 'show' where you refer to it later in the second switched condition multiple times as 'Show'. It is CASE SENSITIVE. Try and make your own preference and stick to it (camel case, All caps, Caps on each new Word etc), but variables Show and show are two different variables. 

 

Finally, I'm not entirely sure from your post what it is you are actually trying to achieve; I've read it multiple times and you're describing the problems your having but not what the desired goal is. 

So, unless I've misunderstood, you want the player to press spacebar to show a message at any point after the sound effect is played - and this would trigger your  "ON" message, right?

Then the player has to press the space bar to get the "OFF" message, right?

If this is correct, then you don't need switched conditions at all because your player will only be doing this once, so just change the trigger types to ONCE and simplify.

If I've understood your goal, this is working:

TF51 - Triggers.miz

If I've misunderstood, please clarify and I'll try my best to help you out again. 

Edited April 17, 2024 by Elphaba

[virgo47]

Thank you for your input. The most important stuff is probably after the last quote.

1 hour ago, Elphaba said:

Firstly, have you read this? ...

It clearly explains SWITCHED CONDITION and some of the Trigger issues you're running into. 

Note this part: 'The trigger will perform the set action(s) every time the trigger’s condition is checked and evaluated as true and its previous state was false.'

The key point is that the condition must be at least once evaluated as false before it can be again evaluated as true to trigger the actions in the SWITCHED CONDITION. The triggers are tested once a second and in sequence.

1 hour ago, Elphaba said:

Secondly, if you upload a mission, try and make sure it uses generic units everyone has, unless it's unit specific.

My bad, I fixed it in the original post.

1 hour ago, Elphaba said:

Thirdly, your script:

cm = cm or {} -- This is a pointless test, this script gets executed once and you only need to create the table cm by using cm = {}

It's for robustness, I use it at the start of my files/snippets because I can place such a script anywhere and be sure that cm exists, yet it does not replace it. It's superfluous here, but that's OK.

1 hour ago, Elphaba said:

Fourthly, the Mission Start trigger to turn a flag on is unnecessary. You can just use the trigger ONCE -> TIME MORE -> FLAG ON(), but the whole 'init' variable  is redundant too. 

Fifthly, All TRIGGERS and their CONDITIONS are tested in sequence and only when they are true are the ACTIONS performed. If the trigger is ONCE, then once the CONDITION is true and the ACTION is executed, then that entire trigger is removed from the list of triggers to process on the next loop. I believe each loop is 1 second. 

MISSION START is executed at mission start, obviously, but having a condition there that can fail means it won't get called again, because the trigger is only at MISSION START. You need this to load your script, but don't do any conditions or other things in it other than setup stuff, unless you can be certain those conditions are ready and set up AT mission start.

I don't have great practice with these, so I didn't know about TIME MORE, thanks for the tip, "init" flag was useless, indeed. The rest I understand, I believe.

1 hour ago, Elphaba said:

You have a typo on the the flag 'show' where you refer to it later in the second switched condition multiple times as 'Show'. It is CASE SENSITIVE. Try and make your own preference and stick to it (camel case, All caps, Caps on each new Word etc), but variables Show and show are two different variables.

That's strange... I know they are case-sensitive. They are all lowercase in the screenshots as well, unless my eyes are wrong (they're not perfect ;-)) however, the triggering works, and it would have not without the right casing. Let's move on.

1 hour ago, Elphaba said:

Finally, I'm not entirely sure from your post what it is you are actually trying to achieve; I've read it multiple times and you're describing the problems your having but not what the desired goal is. 

So, unless I've misunderstood, you want the player to press spacebar to show a message at any point after the sound effect is played - and this would trigger your  "ON" message, right?

Then the player has to press the space bar to get the "OFF" message, right?

If this is correct, then you don't need switched conditions at all because your player will only be doing this once, so just change the trigger types to ONCE and simplify.

If I've understood your goal, this is working: ...

I got lost in the detail and really didn't describe it properly, so I fixed the first sentence:
I wanted to create to myself a simple mission with an optional help in a message that I can trigger ON and OFF repeatedly with Space.

Initially the message is ON (ONCE trigger sets the flag instead of writing the message, because I don't want to repeat the message ON command at two places. Message OFF will eventually be clearing the message view, but it's OFF for now for better testing.

Because of this repeated triggering, I need SWITCHED CONDITION and two symmetric yet opposite  set of actions.

I suspect the problem is that Space press event is evaluated in a completely different event loop than the once-a-second trigger loop. So what is probably happening is that Space is pressed multiple times between the whole cycle of SWITCHED CONDITIONs (SC) are evaluated.

That is:

• previously OFF was evaluated, so the last seen "hide" state by the second SC was TRUE,
• Space is pressed, "show" is set,
• first SC is triggered, let's say "show" was previously false, so ON message is shown, waiting for the input,
• Space is pressed, "hide" is set
• but last seen "hide" was TRUE as well... no trigger, and the message get's stuck.

First I thought this happens if I'm too fast between the two trigger evaluation cycles, so it can only get stuck in one of the positions. But the repeated testing shows that it can get stuck in the other situation as well, although less likely (last is a debug output):

My goal was to have that trigger action as snappy as possible, but it's probably not easy to make it reliable. As I mentioned, with TIME SINCE FLAG it is reliable - because it always gives the loop the second to see the wrong condition for the flag, yet a bit slower (from Space to visible action 1-2s). It's not a big deal and I'll not fight DCS on this one.

(BTW: Irony wanted it, and your mission uses paid P-51D, but no prob.)

Edited April 17, 2024 by virgo47

[TEMPEST.114]

Ha, I thought it was the TF-51 which is free I believe. Oh well.

So my 'solution' wasn't what you wanted?

Do you have enough now to fix it yourself or would you like more help?

[virgo47]

21 minutes ago, Elphaba said:

So my 'solution' wasn't what you wanted?

Do you have enough now to fix it yourself or would you like more help?

No it wasn't, but that's on me forgetting to state what I wanted in the first place. Sorry about that and thank you for your analysis, it still helped me to tidy up my thoughts.

I'll solve it with TIME SINCE FLAG which gives the "flip-floping" SWITCHED CONDITIONs time to evaluate to false before triggering again.

I think the main flaw in my original idea is that I assumed something like this: "The triggers get all evaluated and the Space press event (for X: START WAIT USER RESPONSE), even if pressed rapidly, can't trigger both of them in one cycle - and in turn, it can't turn one of them two cycles in a row."

But that's all wrong - obviously, it somehow can. So giving it all that one second with TIME SINCE FLAG is the best way... At least from the simple solutions - my son planned to implement some crazy solution with even more flags, maybe I'll let him. Also, there can be additional "guarding" conditions that would unstick the stuck situation, but it's not worth the effort to get something marginally more snappy.

Thanks again for your input!

Edited April 17, 2024 by virgo47

[TEMPEST.114]

1 hour ago, virgo47 said:

Thanks again for your input!

You're most welcome, sorry I couldn't be more help. 

[virgo47]

With the help of my son, we put together two more solutions that are snappier than the original design with TIME SINCE FLAG.

First one uses different flag design - flag toggle is used to indicate that the state of the message should change, and state is true when the message should be visible and false when not.

• ONCE (init) trigger sets flag toggle to TRUE and also plays the sound, I want it only once.
• This trigger is the only one that waits for user input (which sets toggle) and is a REPETITIVE ACTION. It also contains a short script to switch the state flag from TRUE to FALSE and vice versa (toggle):
  
• The other two SWITCHED CONDITIONs are suddenly very simple:
  
• And to hide the message:
  

Because the switched conditions are totally opposite (FLAG IS TRUE vs FALSE for the same flag) and the toggling is in repetitive action that always resets its condition flag (toggle), there is no chance of getting stuck - and this is also noticeably more responsive than triggers with TIME SINCE FLAG.

And then came the other idea, to use REPETITIVE ACTION (RA) for the original solution. "Wait," you may aks, "why didn't you use RA from the start?" And the reason is just wrong thinking, considering RA more demanding than SWITCHED CONDITION (SC) as it may run ACTIONS more often. One of the original ideas was simply to run MESSAGE command every second (as it would clear view in the final solution anyway), but I just didn't like this unnecessary repetition. But while RA may run actions more often than SC, it doesn't mean it has to. As I already set the flag that guards ACTIONS to OFF in those ACTIONS anyway, it will not be run again, unless set to TRUE again.

Which leads us to this simpler solution - this one with flags show and hide:

• ONCE trigger as before, sets show to true.
• And then both REPETITIVE ACTIONs are virtually the same, just opposite - one for show:
  
• And the other for hide:
  

So if someone is fast on Space, it may trigger successive actions and pass all the true conditions for both flags, but if the things settle (no Space banging), both flags eventually get to the FALSE state and no repetition happens.

Sure, the triggers and their conditions are considered again and again, but the same happens for SCs, but this time without the potentially sticky problem. Whenever the flag is TRUE, we do the stuff and reset it.

Sorry for re-discovering America for many of you, I guess, but perhaps this helps someone searching for similar trigger toggle things.

Final notes:

• Yes, I know I could have just used a kneeboard. But editing the message is still much easier for me.
• Yes, you can't use Space in such a mission.
• Both missions are attached.

Su-25T - message toggle - with repetitive toggle.miz Su-25T - message toggle test.miz

[TEMPEST.114]

10 hours ago, virgo47 said:

With the help of my son, we put together two more solutions that are snappier than the original design with TIME SINCE FLAG.

First one uses different flag design - flag toggle is used to indicate that the state of the message should change, and state is true when the message should be visible and false when not.

• ONCE (init) trigger sets flag toggle to TRUE and also plays the sound, I want it only once.
• This trigger is the only one that waits for user input (which sets toggle) and is a REPETITIVE ACTION. It also contains a short script to switch the state flag from TRUE to FALSE and vice versa (toggle):
  
• The other two SWITCHED CONDITIONs are suddenly very simple:
  
• And to hide the message:
  

Because the switched conditions are totally opposite (FLAG IS TRUE vs FALSE for the same flag) and the toggling is in repetitive action that always resets its condition flag (toggle), there is no chance of getting stuck - and this is also noticeably more responsive than triggers with TIME SINCE FLAG.

And then came the other idea, to use REPETITIVE ACTION (RA) for the original solution. "Wait," you may aks, "why didn't you use RA from the start?" And the reason is just wrong thinking, considering RA more demanding than SWITCHED CONDITION (SC) as it may run ACTIONS more often. One of the original ideas was simply to run MESSAGE command every second (as it would clear view in the final solution anyway), but I just didn't like this unnecessary repetition. But while RA may run actions more often than SC, it doesn't mean it has to. As I already set the flag that guards ACTIONS to OFF in those ACTIONS anyway, it will not be run again, unless set to TRUE again.

Which leads us to this simpler solution - this one with flags show and hide:

• ONCE trigger as before, sets show to true.
• And then both REPETITIVE ACTIONs are virtually the same, just opposite - one for show:
  
• And the other for hide:
  

So if someone is fast on Space, it may trigger successive actions and pass all the true conditions for both flags, but if the things settle (no Space banging), both flags eventually get to the FALSE state and no repetition happens.

Sure, the triggers and their conditions are considered again and again, but the same happens for SCs, but this time without the potentially sticky problem. Whenever the flag is TRUE, we do the stuff and reset it.

Sorry for re-discovering America for many of you, I guess, but perhaps this helps someone searching for similar trigger toggle things.

Final notes:

• Yes, I know I could have just used a kneeboard. But editing the message is still much easier for me.
• Yes, you can't use Space in such a mission.
• Both missions are attached.

Su-25T - message toggle - with repetitive toggle.miz 17.43 kB · 3 downloads Su-25T - message toggle test.miz 17.15 kB · 3 downloads

And it won't work for CLIENTS or MP missions..

[virgo47]

20 minutes ago, Elphaba said:

And it won't work for CLIENTS or MP missions..

I needed this for my own single player mini-tutorials (e.g. learning some particular maneuver) and it could be adapted for Client. I'm obviously just a ME beginner, but previously I made a multi-client landing mission which selected the message based on the type. The client spawn detection was in the Lua script (I didn't find other event for it) and so was the message selection, so the flag flow is the same for each client instead of having many flags per client.

The mission (for Su-25T and TF-51D, both free planes) is more script-heavy, obviously, and reflects my newbie skill:

Multi-client - message toggle test.miz

The mission is not the cleanest thing, e.g. the script sends message to the client and cleaning is done by message to all - but in single player it doesn't really matter. I have no idea how this would work in MP, especially with X: START... command which you can't even aim at a single player, so I guess space-based message toggling is not possible there.

That said, this really is for simple single player missions to drill something specific. With or without instructions at your will. (Which, of course, you can do with kneeboards.)

[TEMPEST.114]

I believe you’ll find in client it only works for the host, not every other player. Another DCS vagary. 

[virgo47]

18 minutes ago, Elphaba said:

I believe you’ll find in client it only works for the host, not every other player. Another DCS vagary. 

Yes, you're right, this is only for single-player with multiple slots, that is to support Change Slot. I'd not dare to go MP with such a mission. I have a great admiration for the people who script missions for servers, I have no idea how some of the things are pulled off.

[Rudel_chw]

14 hours ago, virgo47 said:

Which leads us to this simpler solution - this one with flags show and hide:

I think that using the same key for two tasks is inherently complex, it would be simpler to use backspace to show the message and then spacebar to hide it.

[virgo47]

7 minutes ago, Rudel_chw said:

I think that using the same key for two tasks is inherently complex, it would be simpler to use backspace to show the message and then spacebar to hide it.

Yes, thanks for bringing it here! I was considering that as well, I know the other thread and your research in that area:

If it was two different tasks, definitely, but for just toggling the message I see it more convenient (at least for me as a user) to just use Space.

As for complexity, the final SP version for just a single Player slot is no hassle at all. As for getting stuck, I'm sure I would first try some version that I'd get stuck if I was spamming both Space and Backspace.

But yes, I'm keeping the Backspace option in mind for more difficult scenarios. I like your section skipping in tutorials a lot.