FlightGear Newsletter November 2015: Difference between revisions

Jump to navigation Jump to search
(scenery project3000)
Line 61: Line 61:


The next steps Stuart is planning are as follows: - Flesh out the Viewer Federate implementation, possibly to include mapping of HLA data to properties. - Publish the FlightGear aircraft instance position to the RTI so it can be picked up by other viewers. - Create a Multiplayer Proxy as a Federate that proxies between the MP network and the RTI. This will run in a separate thread or as a separate executable. - Split out the traffic Manager in a similar way. This is obviously focussing on the viewer aspect, and doesn't address splitting out the FDM or control elements.<ref>http://sourceforge.net/p/flightgear/mailman/message/34625641/</ref>
The next steps Stuart is planning are as follows: - Flesh out the Viewer Federate implementation, possibly to include mapping of HLA data to properties. - Publish the FlightGear aircraft instance position to the RTI so it can be picked up by other viewers. - Create a Multiplayer Proxy as a Federate that proxies between the MP network and the RTI. This will run in a separate thread or as a separate executable. - Split out the traffic Manager in a similar way. This is obviously focussing on the viewer aspect, and doesn't address splitting out the FDM or control elements.<ref>http://sourceforge.net/p/flightgear/mailman/message/34625641/</ref>
<references/>
== Troubleshooting reset/re-init ==
[[File:Reset-reinit-control-panel.png|thumb|reset/reinit control panel for regression testing purposes implemented using Nasal & Canvas]]
FlightGear does not currently support saving/loading flights or reliably switching between aircraft at run-time, this is extensively discussed at [[FlightGear Sessions]].
[[Reset & re-init]] is the effort to refactor the FlightGear initialization process such that resetting/repositioning is supported, without having to exit/restart FlightGear. Currently, this is exposed via the [[Aircraft Center]] (Canvas based), but is considered broken by most core developers (fragile at best).
In addition, core developers are hoping to better establish data dependencies between different subsystems, so that more and more subsystems can be made optional (analogous to [[FlightGear Run Levels|run-levels]], to be dynamically removed and re-added at run-time.  This will be particularly important to untangle implicit/hard-coded dependencies among different subsystems, and will be one of the key-tasks to move certain subsystems into dedicated HLA federates.
One of the long-term goals here is to provide a so called [[FlightGear Headless|headless]] mode so that certain, non-graphics related, features (=subsystems) can be better tested in isolation, e.g. in an automated fashion on the [[FlightGear Build Server]], which could help increasingly automate the build/release process, but also related regression testing.
The other goal here being to increasingly modularize FlightGear by using [[HLA]] (high-level architecture), and splitting off the simulation/rendering loops (see [[FGViewer]]), as well as [Supporting multiple renderers]] (think Rembrandt/ALS), and scenery engines (standard and osgEarth), analogous to how FlightGear already supports different FDM engines (JSBSim and YASim), but also different weather engines and rendering engines (standard/Rembrandt, ALS). HLA will make it possible for certain subsystems to be moved to dedicated cores by using separate threads or even processes, which also means that certain subsystems may even be running on a different computer, in a distributed setup.
The underlying requirement that these efforts share is that there needs to be a much better re-/initialization process, so that there are no hard-coded assumptions about running subsystems or initialization order.
For the time being, many of these efforts are not yet completely functional, so more feedback and data are needed.
This article describes the lower-level features that are needed to exercise/test the corresponding reset/re-init related APIs, so that contributors can be provide actionable bug reports.
People running the code shown below should be prepared to trigger segfaults, and should ideally be able to provide gdb backtraces (if you are on Windows, please send [[CrashRpt|crash reports]].
For testing purposes, it does make sense to run FlightGear using the minimal startup profile, with graphics/rendering disabled using [[Draw masks]].
Learn more at [[Howto:Reset/re-init Troubleshooting]]


<references/>
<references/>

Navigation menu