How to update while maintaining all customisations?

[Hevii Guy]

I'd like to upgrade from 2017.3.1 to 2018.2.2 but, I don't want to lose all of the customisations made to my /Data directory. These include new and custom AI scripts, Bombable entries, Nasal scripts etc and, of course, scenery files.

My operating system is Mac OS High Sierra (10.13.6). By placing the new .dmg disk image into my /Applications directory, everything that I had done to modify my existing instance of FlightGear will be overwritten. How can this be avoided?

[Hooray]

$FG_ROOT (the base package) is supposed to be considered read-only for exactly the reasons you mentioned.
In other words, you are in uncharted waters and would have to manually backup/restore any customizations done inside $FG_ROOT.


http://wiki.flightgear.org/$FG_ROOT

[FlugHund]

As Hoory already mentioned, try to keep your modifications out of $FG_ROOT and load them via command line options. This is easy for aircaft and scenery and some xml-configurations. However, some things just won't work that way. In such cases the only practical solution I am aware of is maintaining a local git clone of fgdata. https://sourceforge.net/p/flightgear/fg ... next/tree/
This also has the advantage to be able to have several FG versions installed without the massive overhead of several fgdata folders.
Since handling a git repo can be a tad tricky and I am far from being a git-fu blackbelt, I will not outline my idea for now. Hopefully someone with more experience can chime in here.
To get you started: http://wiki.flightgear.org/FlightGear_Git_for_laymen

[Hooray]

fwiw, bugman and others repeatedly tossed with the idea of extending Torsten's addon framework so that it would allow seamless overlays without having to touch any of fgdata, including even complex "addons" like "Bombable" - rominet seemed supportive of the idea at the time, but this touches a number of places in sg/fg where we are currently using hard-coded assumptions about fgdata only

This kind of infrastructure would obviously also come in handy when dealing with pre-configured fgfs installations.

[Necolatis]

As far as I know, the ONLY way to run scenarios is to put them in data. Sadly.

As for Bombable, someone should convert it to use the new --addon system, so it don't have to be copied into the data folder.

For custom nasal files that you want ran no matter what aircraft you fly, the easiest option is still to keep them in data. But they can be converted into an addon: viewtopic.php?f=6&t=32561

In other words, Hevii Guy's concerns is valid, especially for scenarios, and FG is missing some options to have a scenario folder outside data for custom stuff.

[Hooray]

As far as I know, the ONLY way to run scenarios is to put them in data. Sadly.

If that's the case, that's usually pretty simple to fix for the C++ folks - as a matter of fact, rominet fixed up a number of such hard-coded assumptions in response to bug reports raised on the forum. It would probably be a good idea to file a bug report/feature request so that this isn't forgotten. But it's usually a rather straightforward fix, the nature of which can be seen in the other instances where Florent fixed up the C++ code so that it would also honor Addon related search paths.

As for Bombable, someone should convert it to use the new --addon system, so it don't have to be copied into the data folder.

IIRC, someone on the forum actually once mentioned plans doing so - the issue at the time was that the Addon system was still evolving and was lacking support for certain files to be located outside $FG_ROOT (like you stated above). Thus, without having followed fgfs much lately, I don't think that such a port would be immediately successful - however, it might still prove tremendously useful, especially if the people involved in attempting to port the "bombable" mod also share their findings (problems) on the forum, ideally in conjunction with the ticket system to track any issues.

Speaking in general, fixing up the underlying C++ code to search Addon related paths is a rather straightforward change, especially for people familiar with C++ who are able to rebuild fgfs from source - rominet made a number of such changes over the course of the last year, so someone interested in seeing Bombable evolve accordingly, would be well-advised to look up the commit logs and check out his changes.

For custom nasal files that you want ran no matter what aircraft you fly, the easiest option is still to keep them in data. But they can be converted into an addon: viewtopic.php?f=6&t=32561

Actually, no - people should use $FG_HOME/Nasal instead.

In other words, Hevii Guy's concerns is valid, especially for scenarios, and FG is missing some options to have a scenario folder outside data for custom stuff.

please do share/document such findings, ideally using the issue tracker (i.e. file a ticket)
Even people not particularly interested in the bombable addon will surely appreciate seeing the addon system evolve more, i.e. the corresponding changes would be useful regardless of bombable specifically.

[Necolatis]

Actually, no - people should use $FG_HOME/Nasal instead.

Is that a thing, how does it work? Just put the nas file there and it gets loaded per default always?

[Hooray]

yeah, it's where user-specific Nasal modules can be kept, fgfs will look at $FG_HOME/Nasal and load those files it finds there.

it's documented here: http://wiki.flightgear.org/Creating_new ... al_scripts

Obviously, this won't be too useful when it comes to complex addons like the Bombable mod.
However, there's been talks to extend the Addon system so that it also supports such "default addon directories".

This would be primarily useful to ensure that people don't have to touch $FG_ROOT at all when making large-scale customizations.

Besides, a number of core developers toyed with the idea of shipping some addons pre-included with each release - this would mean, that $FG_DATA could also have a dedicated location for such pre-installed addons.

Under the hood, the same C++ code could also search $FG_HOME/Addons for any user-specific Addons.

This is the most promising approach for large-scale addons (along the lines of Bombable) that would currently require fgdata changes, and it's the best option to ship pre-included addons with each release, and one that would be compatible with the ongoing trend to use a package manager/catalog system to download/install/setup and maintain/update fgfs resources (aircraft hangars, scenery etc).

As a matter of fact, bugman once mentioned the idea of extending the package manager so that it would also support the retrieval of addons.

In combination, these two enhancements would make it possible to include certain addons in the installer, install them in $FG_HOME/Addons, while still providing a way to automatically download/update new versions on demand.

From a troubleshooting standpoint, it would be a great asset if fgdata could always be treated as read-only (most Linux distros install it in a read-only fashion anyway).

If you'd like the Addon system to support such configurable "default locations", please do make a feature request at the tracker, so that the discussion can be moved there.