#2600 "Use voice synthesis" setting is not saved

[Bjoern K]

Disabling the "Use voice synthesis for tutorials and comms" setting does not get carried over into a new session. At the next restart, I still get the (annoying) "Need help?" TTS message.

I suppose this setting is saved in "~/.fgfs/autosave_2020_4.xml"?
If yes, how is the corresponding entry named?

Alternatively/Additionally, is there a way to disable that startup message?

[Bjoern K]

Since I can't edit the original ticket: Milestone is 2020.4 ("Next" branch)

I've clicked "Apply", so I assume that the sound settings get written to Autosave or wherever else FG saves its settings.

The corresponding checkbox also remains checked.

FG HEAD: c8d5296f7bef162311a303ff904577b4010c5e80
SG HEAD: 9ec9d8e4233f9f8a03e3ad6a0525ce47d34d4c9d

[James Turner]

I don't know the voice synth code so I've pinged folks on the devel list to see if anyone knows if this is just a GUI oversight or something deeper.

[Bjoern K]

Thanks!

I think this may just be a GUI bug or oversicht.

[James Turner]

I just tested on next, and for me the setthing is persistent. How are you quit-ing FG? Via the menu -> 'quit' or by clicking the OSG window close box? Or Alt-F4 (etc)?

[Bjoern K]

Good question. I'm not at my FG PC, so I can't check my habit. I think it's usually the method with the confirmation box ("Menu" --> "Quit")?

Shouldn't the setting be saved by the "Apply" button regardless of how the FG session is terminated?

[James Turner]

Unfortunately there are some termination methods where we are unable to save settings: due to some limitations of the rendering libraries we use. Basically if you don't see the 'exit FlightGear yes /no?' dialog, we don't save settings.

[Bjoern K]

And the "Apply" button actually triggers a write to the preferences/autosave file?

Is there a method to debug file I/O (logfile or stdout in a terinal)?

[James Turner]

For historical reasons, we don't save to 'autosave', until we are actually exiting. (Not when closing a particular dialog or changing a particular setting). You can set a breakpoint around FGGlobals::saveUserSettings and check if/when it's being called.

[Anonymous]

Speaking of which, would it be possible to have either a Nasal binding or a fgcommand that does that so that I could add a menu item to flush settings to autosave at any point of simulation?

[James Turner]

Yeah adding a 'save autosave now' command would be easy. You just need to add a command which fires globals->saveUserSettings();

[Anonymous]

Btw what about aircraft-data, are they saved on the same cue?

[Anonymous]

I think I know how to solve the problem of not handling Ctrl-C termination: we can make each write to userarchive="y" and aircraft-data properties flush autosave. That would also prevent saved-settings loss on crashes.

But then there's a problem: what if something is writing into one of those properties, in a loop? Would the I/O get too heavy? For example an aircraft system that uses aircraft-data for its persistence? Maybe we would need a way to rate-limit the flushing somehow (but how?)?

[Anonymous]

I made a patch that adds options to flush settings and aircraft data. I'm not sure whether it's best to have them as one menu item or separate. They use very different code paths.

[James Turner]

I would be very reluctant to save on every property write, something bad could happen.
What we could consider, is doing a save every five minutes, or when a dialog is closed - those should ensure most settings are saved, without adding any weird interactions.

[Anonymous]

Yes. Only autosave but not aircraft-data, can rely on this, though, because aircraft-data is more likely to be changed by something non-dialog.

I don't know though. Personally I do rely on the non-saving of autosave etc when debugging. I can Control-C FG and be sure that no changes I've made to the settings will affect the next try.

[James Turner]

Yeah this is maybe one to discuss on the developer mailing list?

[Anonymous]

Sorry about the delay, I will indeed ask on ML.