FlightGear Headless: Difference between revisions

Jump to navigation Jump to search
Line 5: Line 5:
= FlightGear Headless =
= FlightGear Headless =
{{Main article|Supporting multiple renderers}}
{{Main article|Supporting multiple renderers}}
there is no document listing the minimum set of stable features. If someone wants to write one, they can do it, but I guess they won’t volunteer to test release candidates against it; indeed getting people to even run them has been a struggle.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35990557/
  |title  =  <nowiki> Re: [Flightgear-devel] carrier features: is there any modification ,
your policy related ? </nowiki>
  |author =  <nowiki> James Turner </nowiki>
  |date  =  Aug 10th, 2017
  |added  =  Aug 10th, 2017
  |script_version = 0.40
  }}</ref>
with the new test framework it should be possible to add tests for carrier start, as I already did to ensure runway selection with METAR. Indeed the position init code is a very good candidate for testing this way since we broken different aspects (parking position startup, WXR runway selection, the carrier, probably some more things<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35990557/
  |title  =  <nowiki> Re: [Flightgear-devel] carrier features: is there any modification ,
your policy related ? </nowiki>
  |author =  <nowiki> James Turner </nowiki>
  |date  =  Aug 10th, 2017
  |added  =  Aug 10th, 2017
  |script_version = 0.40
  }}</ref>
The original FG scene graph design is based on rigid assumptions of the ordering of the sequence of events for start up and shut down. Branch management is highly inconsistent, and is scattered all over the flightgear and simgear codebases. But it worked perfectly due to the fixed event sequences. The new subsystem design however brings in a much more flexible design, whereby systems can be dynamically turned on, turned off, restarted, initialised, reinitialised, etc. This is essential for enabling rebooting, and allows for custom FlightGear usage of only a small subset of systems and for '''a headless mode'''. The OSG+subsystem breakage occurred once the scene manager subsystem was fully converted to the new design. The OSG scene graph root is created at the start of FGScenery::init(). With the subsystem design, the scene graph root may not be present when other flightgear/simgear code paths are called to create, manage, or destroy the various scene graph branches.<ref>{{cite web
The original FG scene graph design is based on rigid assumptions of the ordering of the sequence of events for start up and shut down. Branch management is highly inconsistent, and is scattered all over the flightgear and simgear codebases. But it worked perfectly due to the fixed event sequences. The new subsystem design however brings in a much more flexible design, whereby systems can be dynamically turned on, turned off, restarted, initialised, reinitialised, etc. This is essential for enabling rebooting, and allows for custom FlightGear usage of only a small subset of systems and for '''a headless mode'''. The OSG+subsystem breakage occurred once the scene manager subsystem was fully converted to the new design. The OSG scene graph root is created at the start of FGScenery::init(). With the subsystem design, the scene graph root may not be present when other flightgear/simgear code paths are called to create, manage, or destroy the various scene graph branches.<ref>{{cite web
   | url    = http://sourceforge.net/p/flightgear/mailman/message/35048478/
   | url    = http://sourceforge.net/p/flightgear/mailman/message/35048478/

Navigation menu