virgo47

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.

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.

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.)

I'm only interested in this in the context of single-player tutorials.

I've check the DCS manual 2020, p163-4. I know I can stop listening for the response with X: STOP WAIT USER RESPONSE - but what if I don't need to? Can I simply use X: START WAIT USER RESPONSE repeatedly with the same flag safely without worrying about some stack or other resource taken? (Of course X: STOP WAIT USER RESPONSE is undeniably useful when you want to "free" the Space key and let the user do whatever they want with it.) First I assumed that each X: START WAIT USER RESPONSE simply replaces the previous one - but one can actually add two waits for two different flags! After the time, I pressed space and via F10 other action printed the flags - both were 1! That made me thinking, what if I just call STOP WAIT... once? If I waited 10 secs and then pressed Space, no flags turned 1, so both START WAIT... were effectively disabled. Another question, does it set the flag ON just once, or - if not "STOPped..." can it do that repeatedly? Long story short, yes, it only works once. If I press Space, both flags go ON and if something (e.g. timer) resets them, the next Space does nothing. This seems to indicate reasonably safe action - although the option to use it multiple times to eventually set multiple flags really surprised me. Please, let me know if I missed something about this action!

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

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!

Thank you for your input. The most important stuff is probably after the last quote. 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. My bad, I fixed it in the original post. 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. 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. 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. 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.)

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

I've read this far although I'm not at the top of the pyramid by any stretch of imagination. I admire people who put in tons of time and create interesting results with the Mission Editor, the Campaigns, etc. I started around 2 years back and I'm more on that side trying to figure things out. I made my own scripting, and I love that part most - and that's why I struggle with the clickity-clunkity parts of the mission editor. Sure, it is there and we absolutely can do stuff there, but if I can script instead and just put the script there, I take it every single time. It's fun learning a new language and digging through whatever _G table shows you and then deeper and deeper. Fun - for a while. I have no idea what I'd do without Hoggit documentation and some tutorials. It's a painful omission on ED's part I believe, but as many other people still manage I think it will first need to get to some unbearable point (if it ever will) before something is sorted out. But the incurred cost to everybody interested is just crazy.

That's not quite what I wanted. I like Space for things like tutorials, or lately, I just wanted to toggle a message on and off repeatedly. I don't want to use cockpit controls for this one. The question is if the common API is even possible for both SP and MP environment. Perhaps tutorials are not suitable for MP, although if one wanted to teach two-seat planes with two real people there... suddenly it gets interesting. Or there may be scripts just sent to the client to do the stuff with the local state. But here I am on thin ice... I have zero MP mission experience and no idea how that should work and interact.

Yes, that would be even better of course. If I can perform the action on/with a unit, it would be more flexible. I don't really need 1-to-1 translation of those X: actions, just a reasonable alternative to them. Currently, setting up the cockpit is a tedious work, unreadable (can't use Lua constants, just numbers), etc. There will need to be many-years support for old stuff, but that's doable. People used to programming are familiar with deprecation mechanism, it can be arbitrarily slow so the upkeep for existing missions is not unbearable (more than it may be already). As for "Start wait user response", not sure how to translate that to multi-client/multi-player environment, but it should be doable as well.

Just to be sure, please, give as a screenshot when you observe the problem, it always helps a lot.

Thanks for the tip, this at least allows me to disable the whole trigger. My initial idea however came from the Actions list. It's not supercomplicated to create an action, but oftentimes it's annoying, especially if it's a message, sound, script, clickable action or anything that requires more clicking and parameters. To disable such a thing now is to delete and recreate it again. I just expanded the idea to conditions and triggers for consistency, but it is most missing on Actions level, at least as I see it.

I'd also rather script more (as a programmer) but many of the Actions seem to be unavailable in Lua scripts. I'm afraid this is one of them. But at least this one doesn't need to be repeated many a dozen times as some clickable cockpit actions. It would be a big help if every action were available from the scripting environment as well.