We need a new menu apply button that does...

[clrCoda]

We need a new menu apply button that does a save of the current configuration in the manor that closing the simulator does now when it writes out to auto save files.

Often, we make a change in the 3.5 system and then we should then close the sim so that the save files are written after the change. If we don't close before a flight, we have an opportunity to lose our current changes if the simulator crashes.

A new "Apply Changes" menu option could be created to force the save right then when the button is pushed to that we don't have to go thru the motions of shutting down the sim after a change to make sure they are saved, and then restarting the sim for our flight.

--opinions? I will send this idea to Devel-ML if opinions agree.
Ray

[Hooray]

so you want to serialize all config stuff without actually shutting down ?
If so, please feel free to file a corresponding feature request via the issue tracker and post a follow-up on the devel list - it is generally a good thing to aim for to separate re-initialization and serialization of settings, and touching on a number of ongoing effots, primarily:

http://wiki.flightgear.org/Reset_%26_re-init
http://wiki.flightgear.org/Fixing_Presets
http://wiki.flightgear.org/FlightGear_Sessions

The main guy behind the reset/re-init work, is Zakalawe.

The issue tracker is to be found at: https://sourceforge.net/p/flightgear/codetickets/

[clrCoda]

Thanks for posting Hooray:

No, that is way off of what I am suggesting, or so I believe. Unless those things are somehow linked with this.

I want to write the autosave file with the push of a new menu button so that changes I make to the launcher or simulator that would normally get written when the simulator is properly closed get written when I press the button so that I don't take a chance on losing the things I change should I crash the simulator before autosave stuff gets a chance to be written the way it is written now on the proper close of sim.

If those things you mentioned are somehow related to doing that, and I am not aware of it, then you do me a service of pointing that out before I make a fool of myself, which I appreciate.

It's one thing to dream up helpful features. Clearly another to ask people to abandon years of doing things a certain way when those things are still being worked on.

I don't know that what you have posted is in any way related to what I am asking for, and/or I don't see how what I am asking for bothers anything you have posted.

I'm not asking for reset/init. I'm asking for the autosave files to be written to on the push of a button.

Thanks for you input in the matter.
--Ray

[clrCoda]

In otherwords:

If I make a change to rendering options, that fact does not get saved until the simulator is properly closed. I want to save that fact before I get a chance to crash the simulator by flying, in which case auto-save does not get written now.

--

[Hooray]

yes, those are related features - basically, there's currently a hard-coded shutdown sequence invoked once you terminate the program, part of which serializes all configuration stuff using autosave.xml - you're asking for a dedicated API/fgcommand to just call the serialization routines without actually terminating the program, which does make sense, and is in fact overlapping with the efforts mentioned above. I am sure that core developers will understand what you're aiming at once you file a feature request or discuss this on the devel list, if in doubt, just post a link to this thread.

In developer's terms, you are asking for the shutdown sequence to be refactored so that the serialization scheme (the part dealing with saving to autosave.xml) can be trigged separately, and expose this to the simulator as a corresponding fgcommand.

Alternatively, the userarchive/autosave logic could be modified to always update/store an updated file on disk whenever any related properties are modified, which would not require a dedicated API/fgcommand, but would work transparently for the end-user - however, it would also mean that changing, say, ~30 userarchive options, would result in the file being written >=30 times ... instead of just once.

I suggest to raise this on the devel list, possibly after the release - or just file a feature request linking back to the corresponding devel list/forum threads.

[Tomaskom]

This sure would be useful, but if every config dialog causes the changes to be written immediately (or offers such option), there is a somewhat high risk of trouble in case you make some change that would cause severe problems or crashes. I think the fact that the configuration is saved only on successful sim close is kind of a "feature" preventing you from entering a crash-on-start situation where the only solution would be to clear the settings manually by deleting related file(s).
Of course I'm not discouraging anyone from requesting this, all I'm trying to say is that the way it would be implemented should be carefully considered with this in mind.

[clrCoda]

Most excellent point, Tomaskom. Fully the reason I wanted to discuss it before creating the feature request.

Thank you
--Ray

[clrCoda]

Tomaskom,

I do appreciate the point you made above. After a few days of thinking about it and a conversation with a friend about it I came to realize that if we make a change and force the writing of the autosave file, that situation would happen even if we didn't hit the button and the sim autosaved on close.

In both cases the answer would be to fix the situation by deleting the autosave file, like we do now anyway.

Because I don't have to immediately close the simulator after making a change and then hitting the new save now button, I believe the mechanical advantage is to add the button. I then don't have to worry that I crash the simulator when flying, the sim will start with the new change next time because it was forced saved, and if it doesn't start next time then the answer is still the same: delete the autosave file and rebuild it next sim run.

Thanks
--Ray

[clrCoda]

my buddy calls it "Write Config" and says it goes on the file menu

[Hooray]

that's just cosmetics, from a development standpoint, this is about decoupling program termination and runtime state serialization (autosave) to expose the latter as a dedicated fgcommand, so that the corresponding routines can be invoked without requiring an actual termination of the program - like I said, Zakalawe is well familiar with the corresponding code due to his reset/re-init work, so he will understand what you're suggesting and he will probably even agree that it makes sense to decouple these things accordingly, simply because that will also help with reset/re-init.

[Tomaskom]

my buddy calls it "Write Config" and says it goes on the file menu

That is probably the best solution. Anyway, I think it would be useful if it briefly showed a message when writing the config, which would include the path to the file where the config is stored. So one could easily locate and backup/delete it when needed.

[Hooray]

such a message could be written to a property, which would be trivial to display using Nasal - in either (or both) the startup console or the GUI.
We were once talking about adding a switch to automatically delete/re-create this file simply by specifiying a corresponding startup argument - so that people would no longer need to do this manually, but could just "reset" their autosave/navcache stuff in $FG_HOME - given all the trouble these features have been causing, that would certainly still be the best option.