virgo47

Thanks for the info and for the method, I'll add that to my palette.
It's a bummer it is so complicated and unsearchable. But it's possible. 🙂
(Half an hour later before I actually pressed submit.)
But this left me wondering that DCS-BIOS guys must know it already and perhaps have such a database. Old dcs-bios repo wasn't helpful as it only defined seven indicator lamps, but I found this treasure - and it contains:
C_101:defineIndicatorLight("CC_FRONT_WARN_AOA", 167, "Warning, Caution and IndicatorLights", "C-101CC FRONT Warning Panel AOA/STALL Lamp (yellow)") Now how they got from this to this piece of JSON that is available in their release...
"CC_FRONT_WARN_AOA": { "category": "Warning, Caution and IndicatorLights", "control_type": "led", "description": "C-101CC FRONT Warning Panel AOA/STALL Lamp (yellow)", "identifier": "CC_FRONT_WARN_AOA", "inputs": [ ], "outputs": [ { "address": 14182, "address_mask_identifier": "C_101_CC_FRONT_WARN_AOA_AM", "address_mask_shift_identifier": "C_101_CC_FRONT_WARN_AOA", "description": "0 if light is off, 1 if light is on", "mask": 4, "max_value": 1, "shift_by": 2, "suffix": "", "type": "integer" } ] ...is a mystery to me. Also, I don't see any relation between the address and mask and the original 167 - so I guess there is none. But at least they have it all sorted out in their sources, which is great. That's the "database" I needed!
(I assume, someone did all the digging in the Modelviewer, or even knew how to read some of the binary files.)

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

So this now seems to be reported as a part of:
I guess this is a duplicate now. 😉

I'm totally puzzled now. I tried today and couldn't reproduce it either, although previously I definitely managed to repeat it a couple of times - otherwise, I would not be able to figure out the "workaround" and I'd not dare to report it. 😉 So I guess it's "cannot reproduce" for now. Sorry about it.
If you see something suspicious in the script, cool, but while I'm not 100% sure it's OK, I can't do more about it now.

Never mind... now, after realizing it's not just "Brake Override Switch" but most of the toggles, I can see the other threads I didn't find previously. 😞
E.g.
But, c'mon, two (or more) years later new module users have to be surprised by this?
"Solved" as a duplicate.

The debugging was not very fast for a newbie in Lua (I used some online Lua demo for simple stuff, but some errors appear only during the mission load)... but I got what I want with the following script (Mission start trigger, obviously):
-- Let's call this "my library" of reusable stuff for the future. dunlib = {} -- duration in seconds function dunlib.messageUnit(unitId, text, duration, clearView) trigger.action.outTextForUnit(unitId, text or "Undefined message!", duration or 10, clearView or false) end -- delay and duration in seconds function dunlib.messageUnitDelayed(unitId, text, delay, duration, clearView) timer.scheduleFunction(function() dunlib.messageUnit(unitId, text, duration, clearView) end, {}, timer.getTime() + (delay or 2)) end -- cm = current mission cm = {} -- Just a small demo of messages for a few planes. cm.messageTable = {} cm.messageTable["L-39C"] = [[ Hi kursant... get it down without any damage, will you? ]] cm.messageTable["L-39ZA"] = cm.messageTable["L-39C"] cm.messageTable["F-15C"] = [[ Fly, Eagle, Fly! ... Oh, I mean land, actually...]] function cm.defaultIntroMessage(event) return "Sorry, no instructions for " .. event.initiator:getTypeName() .. ".\n" .. "Get it down somehow..." end function cm:onEvent(event) if event.id ~= 20 then -- We only want a "player enter unit" event: -- https://wiki.hoggitworld.com/view/DCS_event_player_enter_unit return end dunlib.messageUnitDelayed(event.initiator:getID(), cm.messageTable[event.initiator:getTypeName()] or cm.defaultIntroMessage(event), 3, 600, true) -- 3s delay, show for 10 mins, true for clearing previous messages end world.addEventHandler(cm) I didn't use DML for this after all, but I'd not get there this quickly without your pointers. Thank you very much for the directions.

TL;DR: Does not relate to SnapViews.lua saving. Annoying FOV after mission load, but not serious.
Now the details:
I guess I got lost in my experiments with default view and editing SnapViews.lua manually while doing so.
This actually does not have anything with saving the file.
Every time I set my preferred view and its FOV, it is saved nicely into the file, but without HOTAS sync the initial FOV is always higher. E.g., default view FOV 20 will give you 28.2 after the mission loads, 89 will show 108.8, etc. It's not even linear!
With HOTAS sync, this can be mitigated, if you have a zoom axis and it is centered perfectly on your preferred FOV - which is possible with some tweaking.
Strangely though, some planes (e.g. TF-51D) do not read the zoom axis after the mission start. So you still need to tap Zoom normal or touch the axis. No problem.
It would be nice if the FOV after mission start was the default view FOV. There clearly is some relation - can't it be 1:1 for a change? 🙂

Revisiting this after many months with 2.8 and the contrast seems better. Pictures are not aligned, this one is more up close, but it is also overcast, like before. But the brightness and contrast are both much better and I'm actually seeing what I'm shooting at. So I guess it's somehow resolved. 🙂

Oh, my bad... I was so used to Steam updating... My openbeta is still 2.7. I found the instructions and going to update it. Never mind... sorry. 😉

Fixed itself somehow, works fine in 2.8.0.32235

Nah, it wasn't that - I was always on the front seat. But I figured it out, because the idea with the rear seat got me experimenting more. In some of my missions starting in the air the STOP worked, in some it didn't. It worked in solo flights. So I checked the rear cockpit where it doesn't work - and indeed - the rear pilot used what is called a "throttle limiter" in the in-cockpit tooltip. 🙂
I reviewed the docs and it is described from page 87, picture in 88:
Now, sure I read it, but I didn't digest it at the moment and forgot it in the meantime. Now it all makes sense.
Thanks for the push to the right direction - that is to the rear seat. 😉