Some of the things are new functions in "view.nas" like
setting a view directly instead of scrolling through the views,
autohide HUD,
autozoom for some views,
a new "Observer View" a Fly-By view which doesn't reposition, ...
additions in "default.xml", because user specific default.xml didn't work for me as it should
...
Then a whole set of functions which are carrier related
Additions to FG Dialogs ,...
Let's say I'm interested from a technical perspective - do we miss things which should be on FGData (aka, do I need to commit some stuff)?
The general idea is at least that one should be able to add things in a fairly modularized way, i.e. a self-contained AI-scenario, a self-contained plane (since we can for instance have Nasal inside xml wrappers).
If that's not the case, I start getting interested, because I'd like to have FGData in a state where you can run things modularized.
For instance autohide HUD or auto-zoom for specific views can reside aircraft-side (assuming we're talking about driving the carrier as 'aircraft' and not AI scenario) and you should not touch view.nas to accomplish it - that holds for basically any new view.
The same is actually true for anything that's AI scenario specific - since AI scenarios can bring their own Nasal, and since dialogs can be dynamically altered by Nasal code, you should not have to edit xml files to accomplish what you want.
Basically code should only reside in the general GUI xml / view.nas etc. if it's useful for every airplane, it should only go to the general Nasal directory if it's something people might generally use, and otherwise it should be modularized.
(The view manager status is... kind of complicated. There's at least two mutually exclusive addons to it floating around, FGCamera and g-force movement, and while there was an intention to use FGCamera at some point, the developer seems to have disappeared...)
FlightGear Forum
Nice to see some interesting ship development recently in FG.
