Severity:Blocker
**Marketplace package name:Kodiak 100 for FS2020, running in FS2024 compatibility
Context: In Community and Dev mode
Similar MSFS 2020 issue: No problem in 2020
Bug description: For our persistent engine failures, we have an update section that uses the UPDATE_ONCE setup. When the flight starts for the first time, it will reset the failures and if the engine health has crossed a certain threshold, it will reset it to factory fresh. In FS2020 this works correctly, but in FS2024 it does not work at all. This is a blocker bug as the customer has no way to reset the L:var that controls the age of the component. The name is SWS_FAILURE_Turbine_1_Age and it should reset on flight start if it goes past 2250.
Going into Behaviors Debug in 2024 and clicking “EXECUTE” in the update, it does the job, but in 2020 this is automatic.
Repro steps: Start on the Apron in cold & dark state. Turn on the fuel selectors in the overhead, push in the firewall valve and move the condition lever to low idle. Then start the battery and engine starter. The engine will blow up. Exit to menu and load back into a new flight. The engine will remain destroyed. In FS2020 this works properly.
Adding some extra observations to the problem, I tried adding the initialisation code to an XML Update that runs constantly. The initialisation variable successfully changes to 1, but the state.cfg stored value for the L:var doesn’t get overwritten, unless I re-run the update.
It seems that the issue is not with UPDATE_ONCE, but with persistent L:var storage. What seems to happen is that when the plane initialises, the code runs and resets the L:var. Afterwards, the stored values get loaded from state.cfg and the reset is essentially nullified.
Maybe the persistent L:var system has been re-designed for FS2024, but for backwards compatible aircraft (like this case) this could be a breaker issue.
—Update—
I ran a test where I created a 10 second delay timer and then attempted to reset the age of the L:var. It failed again.
I used an O:var to initialise my timer. When manually setting that O:var to 0, it resets the age and then sets the O:var back to 1. So the continuous update runs indeed. But for some reason the initialisation code doesn’t run the first time at all, or it doesn’t set the L:var.
This code, without the outer “if” statement is also in an UPDATE_ONCE code. Both of these work fine in 2020, but not in 2024 compatibility.
—UPDATE #2—
As I couldn’t get it to work yet, here are the three possible causes I came up with.
Persistent L:vars are loaded AFTER the plane initialises. It cannot be, as the third test with the 10s timer would have worked around it.
The sim will initialise the plane and run the code while in the menu: it is a possibility as the game is now always “live”. You don’t have a menu and a fake earth, but you’re in the sim all the time. If that is true, then the initialisation algorithm runs while in the menu and will initialise the plane there. However, as the L:vars aren’t initialised until you’re on the runway, the entire “reset” logic is a dud.
Backwards compatibility is broken in some way I can’t explain
I’m posting this as an answer as it is important to stand out. The cause of the problem has been found. It is cause #2.
In FS2024 the UPDATE functions (whether ONCE or continuous) will run while in the menu and won’t restart when you enter the runway. The issue with that is that if someone uses update frequencies to initialise their aircraft L:vars, they won’t work because the L:vars aren’t loaded until you are on the runway.
One solution is for the updates to restart their running after clicking FLY. This will save us from writing extra checks that -whether we like it or not- happen every frame.
An added bonus is that this problem also affects HTML gauges in 2020 and 2024. The init() starts running in the menu, even if the avionics are not turned on.
For HTML gauges, this is expected. If you want specific logic to run after reaching specific game states (i.e. on the world map, or when the flight finishes loading), then you need to use the GameState.
Given the number of places L: vars are accessed (model XML, html/js, wasm, simconnect, typescript) I’d suggest this glitch is an unintended consequence of running the sim from the World Map and missing some of the details that might get affected. Maybe Asobo should include the L: var load in the new sim initialisation / plane load sequence.
Would having an L: var purely for the purposes of working out whether the L: vars have been loaded (i.e. L:L_VARS_LOADED=1 in systems.cfg [LocalVars]) be the most robust workaround?
@MattNischan thanks for the pointer, I’ve forwarded this internally.
Regarding the initialisation of an aircraft, there is an oxymoron in 2024: you have an initialisation method (UPDATE_ONCE) which you can use to initialise variables, but a particular variable type “doesn’t exist” when this initialisation method runs so you cannot really initialise it at all. This might be going even deeper and affecting the “SIMULATION TIME” environment variable -I haven’t checked, but I’ve seen indications of it counting while you are in the menu environment.
My suggestion would be to reset the sim when the user clicks “ready to fly”. This way SIMULATION TIME resets and UPDATE_ONCE also runs. This seems to be the case in 2020 as well; I should note that 2020 does run the simulation while in the menu, as you have the “hangar” mode where the contact point simulations run, but L:vars are only read from FLT files.
Considering how important L:vars are to most developers, there could be a good chunk of add-ons that will be broken by this. It could also force some developers with an established pipeline to re-design code that has been developed over the past four years and slow the introduction of add-ons in the 2024 market.
I tested version 1.5.6 of your package but could not replicate on SU1 or beta SU2.
The Lvar you mentionned was always reset to 0 when starting the second flight in my case.
Do you still witness the problem?
In 1.5.6 I worked around the problem by initialising in a regular update function, in addition to UPDATE_ONCE. If you dont have access to 1.4.0 I will set up a test case for you tomorrow.
I would like to contribute to this discussion, as I am experiencing a similar issue with my S6S native. It appears there is a problem with how the simulation reads and manages persistent states.
For instance:
If a flight is ended and a different variant is selected, the previous state is not retained. Instead, it resets to the initial conditions from the beginning of the first flight.
However, if the aircraft is completely changed or the simulation is terminated, the persistent state is properly saved and loaded.
I suspect that, since the simulation continues running even while in the menu, it does not have an opportunity to save or load persistent states unless the aircraft is changed or the simulation is restarted.
Additionally, I have noticed that persistent states are only stored in the common/config/state.CFG file, despite each variant having its own system.cfg within their respective preset directories, this way effectively preventing users of having a different states per variant.
As some developers pointed out, some of these Lvars are necessary for the aircraft to run properly and can cause issues.