Aircraft update sync

[spencer.james]

Would there be a way to have the sim automatically update aircraft to the latest release version? Or can this already be done?

So, for instance, I have the Airbus 320 NEO package. I updated some of the XML to include the ATIS audio. I could then submit that change to flightgear, and should it pass, that small change could be rolled out automatically to those with the aircraft installed. It could work in the same method as the scenery database?

[elgaton]

It's currently an open issue (as well as allowing dynamic apt.dat/navaids updates), however there's some related work towards this (see the Aircraft Center wiki page).

[Hooray]

The other issue here being that for for an older binary (think 3.0) to work with aircraft for 3.2+, the updated aircraft needs to be specifically developed with backward compatibility in mind, which is very rarely the case given the added manpower requirements - there are a few role models on doing this properly, such as the bluebird for example - but otherwise, most aircraft really only target a single version, and rarely, if ever, provide different -set.xml files for different FG versions - in addition, FlightGear itself isn't internally structured with a focus on backward compatibility, which doesn't just apply to 99% of the fgdata resources, but also most of the c++/core code.

For instance, the recent route manager changes are implemented in a hard-coded fashion (for reasons that elude me completely...), so that it will be next to impossible to override/customize or update any related logic short of updating the whole fgfs binary itself - and the way aircraft updates have been applied to respond to these changes, updated aircraft like the 777 won't work as well with older binaries any longer, because there's the implicit assumption that the latest binary will be used (or even git/next).

The hard-coded route manager in particular has been known to be a problematic/unstable feature among many aircraft developers causing a lot of frustration, up to a point where /some/ aircraft developers would go as far as re-implementing the whole system in scripting space just to be on the safe side, and just to be able to implement custom functionality, without being restricted by core development.


In other words, it is technically very well possible to allow aircraft/scenery and navdata to be downloaded/updated on the fly -but actually applying/using these resources requires a shift in thinking that seems very unlikely to happen anytime soon.

[Johan G]

...most aircraft really only target a single version, and rarely, if ever, provide different -set.xml files for different FG versions - in addition, FlightGear itself isn't internally structured with a focus on backward compatibility, which doesn't just apply to 99% of the fgdata resources, but also most of the c++/core code.
...
In other words, it is technically very well possible to allow aircraft/scenery and navdata to be downloaded/updated on the fly -but actually applying/using these resources requires a shift in thinking that seems very unlikely to happen anytime soon.

I would like to mention that in addition to that it is pretty much impossible for an aircraft developer/maintainer to make an aircraft that is backward compatible, mainly due to two reasons:

• It is takes an effort to install a new version of FlightGear in parallel with one or more older versions without messing up the settings of those, and
• when it comes to documentation on how one should adapt an aircraft to be fully compatible with earlier versions of FlightGear, there is not really any documentation of changes except for browsing through several years of commits to the repository. (The changelogs only have the highlights and at least sometimes are missing "breaking" changes.)

In essence it is not going to happen any day soon.

[Bomber]

I'd like to say why should an aircraft developer do so....

He's already made a plane that's compatible with an FG version.... When a new version of FG is released he has to do the same for this, but the single file shouldn't be compatible will all back versions, its just a nightmare.

Surely it would be better if FG chose the current version of plane to suit the current version of FG running... That way a developer creates a plane3_1.xml, plane3_2.xml, plane 3_3.xml etc..

Keep the updates simple.

And can I say I have never not had to rework my planes FDM for every new release of FG... The more complicated the FDM the more likely this is to happen....

[Hooray]

Like I said, given a variety of known restrictions, the bluebird should be considered the "role model" (referenence implementation) for anything involving backward compatibility.
While it would definitely be possible to add additional hooks/support for backward compatibility, the real bottleneck is not so much the degree of core-level support, but real resources/manpower available to actual implement backward compatibility properly.
From a scripting standpoint, the local weather system (AW) used to be using a few hashes to encapsulate version-specific things - equally, Bombable is well-known for supporting a variety of FG versions, without breaking.
So it is possible to work around many FG issues, but you need to be intimately familiar with FG internals and also need to be able to test your work across a plethora of FG releases.