virgo47

That just tells you the trim is neutral - not that this is the right trim for current moment in flight. It's only good when you want to reset trim - that is, to find the neutral position.
Some modules even have a trim reset function, which is not always present in the real plane. So it's a kind of "assistant" (or cheat, if someone insists 😉). Su-25T does not have this action - or at least not available in provided bindings.

Today, I upgraded to RTX 5060 Ti 16GB. I haven't tried the situation above before the upgrade, but I clearly remember that F3 flyby views showed ghosting regularly on my previous RTX 3060 - even on pure DLAA without upscaling.
With RTX 5060 Ti, I tried DLSS Quality just to push the limit a bit - and to my positive surprise I see no ghosting in F3 view, I see beautiful and crisp cockpit in Yak-52 (even zoomed out a bit), needles are sharp enough with no obvious ghosting... it's great!
It seems this problem had a HW solution - and perhaps some SW updates helped a bit as well - but as I said, ghosting in F3 was pretty obvious even recently. HW change changed it for much better. Now I seriously consider using DLSS.
Problem solved - and yes, this was not even Yak-52 specific problem.

I'm not OP, but I fly Albatros quite often and I don't see it as a bug, it's a natural need of L-39 for regular trimming.
EDIT: Tested it now with the current patch, trimming seems OK.

It is best to remove the baked in views completely. Otherwise you're forcing those views onto the player. When you want to adjust views later, it will not work for that kind of missions. If you share it later, people may be confused why it doesn't work.
The views get baked in when you "prepare" the mission in the ME (kind of pre-fly it) - this does not happen when you just launch it from ME.

Have you logged in on the web site?

I contacted my ISP (Slovak Telekom) and now they responded that the problem is outside their network and they can't affect the routing. So their mother company Deutsche Telekom AG routes the packets to colt.net - which seems to be the problematic hop - and they don't care that a significant % of the traffic through there is wasted.
So I can try some VPN or ... contact Deutsche Telekom AG directly, or ask colt.net to "just work"... I thought big players could do better with WAN routing and would find an alternative to a route like this. I was wrong, as I often am.
Anyway, apologies to ED and their site - obviously, it works better than it seems from here. 🙂
EDIT 2024-08-20: ISP looked at the problem again, after I asked if they expect I'll talk to Deutsche Telekom or colt.net directly (which was a rhetorical question, of course), and voila, after a week they announced the problem is fixed. And indeed, while colt.net is still in the route, it does not throw away my packets and my favourite ED page works more reliably now!

@Rudel_chw Check this:
 

In ideal world there would be some queueing for events on the same device (flaps here), but as we reopened the topic in the other linked discussion, I came up with some neat solution. Instead of just one pulse, I send two with some not so long space between:

Set Generator Type to GTR2, 60 is for 600ms which should cover most animations.
The only downside is, if the switch acts as a toggle (e.g. toggling between UP/NEUTRAL or DOWN/NEUTRAL), which I hope guys made right for F-4E - or offered all alternatives. I was so happy with this solution only to find, that in MiG-15bis someone was too clever and made the actions toggle, without proper naming. 🙂 Luckily I could fix it with Quaggle's command injector and some Lua.
So now I'm instructing the plane to lower (or retract) the gear twice. And it listens. Not tested on F-4E, but I hope it's applicable.
Technically, this is still just a workaround for a general DCS issue affecting only us - poor flip switchers. 😄

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

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