|
From: James T. <ja...@fl...> - 2023-07-07 05:59:44
|
> On 3 Jul 2023, at 05:37, Wayne Bragg <kil...@co...> wrote: > > I think you could still do this without a core change by saving the new version directly with the io.write_properties command to its own file. Then you could always consider the persistent aircraft-version as the old version unless it matches the io.write_properties saved version. All this would get you though is the ability to tell it is the first time the new version was loaded, you still couldn’t clear the cache before it loaded which doesn’t really help. The aicraft-properties saving is a rather simple feature, as these problems demonstrate. For versioning or conditional loading, the simplest thing is indeed going to be some some Nasal based read_properties / write_properties: this would also let different instruments or systems have their own saved state if necessary. However, extending the FGData/Nasal/aircraft.nas ‘data’ saving code to handle a version tag looks to be pretty simple: just extend the class with some optional string or integer to distinguish the file path which is built. Or you could extend it further to allow an arbitrary file name suffix, so that an instrument could build up an aircraft.data saver that saves to $FG_HOME/aircraft-data/myaircraft-version22-g1000-settings.xml (Right now the code can only save to $FG_HOME/aircraft-data/myaircraft.xml) Kind regards, James |