Version: 1.2.11.0
Frequency: Consistently
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.
1 Like
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 is a snippet showing the code structure:
(O:INIT) ! if{
(L:var) #THRESHOLD# >= if{
0 (>L:var)
}
1 (>O:INIT)
}
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
1 Like
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.
1 Like
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
.
We have logic for getting GameState
in the MSFS Avionics Framework, and if you’re using the framework you can just use this GameStateProvider
to subscribe to the GameState
, or if you aren’t, you can look at this source for how to successfully read the game state: msfs-avionics-mirror/src/sdk/data/GameStateProvider.ts at main · microsoft/msfs-avionics-mirror · GitHub
-Matt