Talk:FlightGear Sessions

Related discussions

• http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20398.html The [Re-]Initialization Process in FlightGear: A Specification Proposal
• https://forum.flightgear.org/viewtopic.php?t=5322
• http://www.mail-archive.com/flightgear-devel@flightgear.org/msg37358.html
• http://www.opensubscriber.com/message/flightgear-users@lists.sourceforge.net/9589296.html

Thinking in terms of FG startup modes

"FlightGear is an old code base, and lots of the old assumptions (like a single aircraft) need to be teased out of the code before progress can be made on new features. This kind of work isn't glamorous, and often requires more effort than the new development does. But it's not brain surgery either." [1]

• without FDM
• without 2D/3D panel
• remove the implicit assumption that FG always simulates an aircraft (FDM + instrumentation + panel) (think non-aircraft or non-FDM modes, i.e. ATC)
• start up without aircraft
• reload vehicles, ATC
• remove assumption: always FDM running, always panel present (i.e. replay mode)
• generic protocol playback
• without scenery

FG Initialization

• should be decoupled from the entry loop, so that it can also be invoked by setting a listener (i.e. aircraft-name) - so that switching aircraft would boil down to setting a property to a valid filename, which in turn would invoke all the relevant init routines.
• just adding such a listener right away, would also make it much more straightforward to run everything in a debugger and see how things need to be changed to make it work
• all the explicit legacy init code would preferably be re-implemented by using listeners instead
• things would probably be simplified quite a bit by modifying FlightGear so that it can be started without specifying and running any aircraft at all, that in itself would remove the assumption that FlightGear is always simulating a particular aircraft, so that the init code could be properly modified to provide support for changing aircraft.
• to really tackle this, one will probably need to modify FG to support a "bare bones" mode, that does not yet use any of its optional subsystems - subsystems should be dynamically enabled/disabled, on to demand
• the "null FDM" is already an option, so it needs support for "null aircraft", "null panel", "null scenery"

Global State Management

In its current form, FlightGear fails badly whenever it has to deal with managing global state - that applies to many situations and components:

• simulator resets (partial) [2] [3] [4]
• saving/loading, resuming flights (partial) [5] [6]
• simulator replays (along with an option to continue flights)
• saving/loading startup "situations" (partial) - similar to loading saved flights
• internal subsystem state [7] [8]
• property "classes" (velocities, orientation, position, cockpit animations, exterior animations, instrumentation) - select classes and reset/save/load accordingly
• provide corresponding signal handlers: reinit/reset, save-state, load-state etc
• have aircraft authors provide scripts to register listeners for the corresponding signals and implement corresponding aircraft specific handlers to handle cleanup/reinit work