Customers report that L:vars and L:1:vars related to SystemsPulse don’t get stored, breaking the persistence feature of the aircraft. During our testing it worked when Streaming and downloading.
The SystemsPulse Airvan overrides the base aircraft’s systems.cfg wilth a long list of variables for its various systems.
My suspicion is that it worked for us because of running the place locally in developer mode, so the localcache had already initialised the state saving, but if Streamed/downloaded through Marketplace it cannot. I am attaching my state.cfg file with saved values.
Repro steps:
Clean up LocalCache from sws_ga8_airvan files
Run the Airvan & SystemsPulse from the Marketplace
Fail the oil pump and accessory gearbox (based on L:1 vars) using the tablet
Exit the flight, then exit the game.
Start the game again, select Airvan and go into a flight.
Check the tablet. The failures should normally persist from the previous session. If they don’t, the save failed.
Are you confident your customers experienced this on SU5 and not SU4?
We fixed a similar issue with SU5, where persistent variables would only be saved when starting a new flight, which means data was lost when exiting the sim.
I’ll see if I can replicate the issue with the airvan on SU5.
We are receiving a few reports that the engine hours are not being recorded accurately. We continue to use our own custom save system because we still do not fully trust the new save-state system in MSFS 2024, and it appears there may still be some inconsistencies.
During my own testing yesterday, the engine hours were saved correctly. I tested by exiting the flight and starting a new one, as well as exiting the flight and then completely shutting down the simulator. In both cases, the engine hours were retained as expected.
However, some users report that they lose about one hour of engine time after each flight, suggesting that not all of the flight time is being saved. Another customer reported that the aircraft shows only 2.5 engine hours, while his flight tracking software records a total of 10 hours and 55 minutes. At this point, we’re not yet sure what is causing the discrepancy.
One scenario I still need to test is what happens if you close the simulator directly from an active flight without first selecting Exit Flight. I want to verify whether the engine hours are still saved correctly in that situation.
This is a report from one of the customers. The plane started in a totally failed state and he had to reset it every time he went in the game.
About this - I was one of the people who had originally reported this issue. I decided to try a few things, as I was having problems with the streamed version (and thus downloaded it to get it to work):
1 - Removed all addons via addonlinker and marketplace
2 - Cleaned my files
3 - Removed any edits and known files that might’ve been corrupted
None of this worked. **However,** upon uninstalling the game, and reinstalling it, SystemPulse now works via stream, as well it fixed some other issues. I’m at a complete loss what caused this and other issues.
TLDR: Something between an uninstall and reinstall worked, despite my best efforts to find the issue.
My suspicion is that if a user had the plane without the failure module and then installed SystemsPulse, that’s when the problem would crop up -until they cleared their LocalCache.
Also, the LocalVar.N sequence in systems.cfg is different in base vs SystemsPulse, I don’t know if that plays a role when indexing them.
@FlyingRaccoon I’ve gotten some feedback on this issue from customers, but not yet 100% sure of the cause.
So one customer sent me two state files for the GA-8 Airvan at the same time (attached). The good one was from the FS2024 plane, the bad one turned out to be from the 2020 version. The customer had the 2020 Airvan, then upgraded to the 2024-native one. For some reason, the 2024 plane would read the state.cfg from the 2020 plane and start with several systems failed.
I had him delete the container folders for both 2020 and 2024 planes from the cache and start clean. The 2024 plane worked fine for a couple of days, then the problem came back. Eventually, he disabled the 2020 plane and that fixed it.
There are two potential issues I see:
The 2020 plane isn’t auto-disabled when the 2024 package with the same name is detected
The 2024 plane is sometimes trying to read the 2020 state.cfg on load. I have no idea what it does on save.
Are you sure your customer didn’t activate the 2024 version of system impulse and version 2020 of the base aircraft or vice versa?
The 2020 and 2024 version of your aircraft have different path for the state.cfg file
2020 will be in LocalCache\SimObjects\sws_ga8_airvan\state.cfg
2024 will be in LocalCache\SimObjects\sws_ga8_airvan\common\config\state.cfg
You seem to have backported some of your code from 2024 in your 2020 packages.
Your 2020 system impulse package has references to L:1 variables that do not exist in MSFS 2020.
This ends up writing L variables starting with :1 prefix
So I think what you described can occur if your player has mixed versions for the aircraft and system impulse packages.
I’d also say this will likely not work with both 2020 packages installed because of the incorrect variable naming.
I have forwarded this to the customer. Meanwhile, is it possible to detect if the 2020 SystemsPulse is running with a 2024 plane and deactivate it, through the system?
The customer was using the 2024 plane & SystemsPulse and all was OK. When he selected a repaint that was made for the 2020 version (not installed), then the game created a new SimObject container in LocalCache, which referenced the 2020 version of the plane and everything went bad from there.
It seems that 2020 liveries work on the 2024 plane but still call the 2020 state.cfg files which breaks everything.
