wlbragg
commented
1 year ago @wkitty42 sorry I didn't see this until now. I don't know how much I explained this in the mailing list thread. I did some testing and the problem is we cannot delete that persistent data prior to it loading. So even a if version check was possible, as is, it wouldn't help. If you save the version in aircraft-data, the old "saved" version will overwrite the new version and there is no way to catch that new version. Unless you save either the new or old version outside the persistent aircraft-data node. In other words, save the new current version manually in a stand alone file like we do for the save aircraft state option. Then you can consider the aircraft-data "persistent data" as the old version and pull the current version from the independent file on FDM load. Compare those two data and, if different, right then copy the new version value to the /sim/aircraft-version value (that is the default version that gets cached) and force save it to the persistent aircraft-data file. On exit it would save it anyway, but just in case the user bails or the program crashes and the persistent data isn't saved with this changed value. What would really help is to understand what, why and exactly when that persistent data difference causes errors?
We need a core change to give us a chance to manipulate the saved data cache. Another fix would be to use the saved data cache differently, requiring a major rework and rethinking of saved "persistent" data. This is the same issue I ran into when trying to create some startup states, The saved "persistent" data was interfering. We are saving properties that cause issues in aircraft states.
wkitty42
occasionally we have to delete the file fg-home/aircraft-data/c172p.xml because there's some sort of conflict that causes problems with the craft... deleting or ignoring this data file allows the craft to load and operate properly...
my thoughts are that if we also stored the aircraft-version in this data file and compared the value to the current aircraft-version value when loading, we could then decide to keep the data and use it or we can decide to not use the data and start "clean"... this would avoid loading whatever bad/missing/no-longer-used values that cause the problems and when the sim is exited or some other craft is loaded, the new good values of this craft would be written to this data file thus eliminating the problem...
how to do this, i don't know but there should be some way of accomplishing it... i can see in c172p-main.xml where we set the properties to be saved but i cannot find where or how they are loaded... i also cannot see if it is possibly to load only one property from this saved data file so it might be compared/validated before loading the rest of the data...
anyway, there's my (current) thoughts on this problem... i had told someone i would publish them to get them out here so we could delve deeper into how to handle this situation...
FWIW: i know some properties (eg hobbs clock(s)) should be ok to keep when deciding to use or ignore the aircraft-data... if there is maybe a way to load these saved properties into a temporary property tree branch to compare with the regular property tree branch, this may be one path to handling this situation... then we could at least ignore properties no longer used, or that were typoed and then fixed, and also be able to use those that are general properties that should not cause problems if they exist or not...