From FlightGear wiki
Jump to navigation Jump to search
Note  If you are also interested in any of these, please get in touch via the forum - even if I am not around, you'll typically find many pointers here (or on the forum). See also User:Hooray/Useful Patches

Primarily interested in helping/working towards these things in the long-term:

  • Towards better troubleshooting
  • better support for run-time re-initialization, as per Reset & re-init and FlightGear Headless, but ideally also including:
    • Howto:Disable Nasal entirely - for troubleshooting purposes, so that we can exclude Nasal (its GC) as the culprit, but also to facilitate related developments like FGPythonSys
    • Initializing Nasal early, to help re-implement certain fg_init/options.cxx stuff in scripting space (all the procedural legacy code there which isn't performance critical and which hasn't been touched in a decade)
    • introducing "run-levels" for booting FlightGear, i.e. for better troubleshooting
    • but also benchmarking, and scripted regression tests / test flights
    • and to get rid of the plethora of unmaintained external GUI launchers, and instead provide a native/integrated Canvas-based launcher, which may include adding a few custom Canvas Elements, especially a camera mode to render 3D models/views to a canvas texture (based on Zan's work)
  • Adding run-time diagnostics to better understand why FG in general, and certain features in particular, are such resource hogs, as per Subsystem-level Memory Tracking for FlightGear
    • exposing more Nasal internals for better debugging/instrumenting
  • Getting rid of legacy 2D rendering code (GUI, 2D panels, HUD) as per Unifying the 2D rendering backend via canvas
  • splitting up the FlightGear boot process such that certain subsystems/features (e.g. canvas, scripting, AI) may become available in a lightweight/standalone mode FGCanvas, i.e. having Nasal/Canvas based "FlightGear Applications" (think Instructor Station) that can directly access all important subsystems (terrain, scenery, FDM, AP, GUI, scripting etc) because, after all, it's just FlightGear minus a few optional features.
  • supporting distributed multi-instance setups that properly synchronize state (including glass cockpit and GUI stuff), not just across MP, but also in master/slave setups, quite certainly using High-Level Architecture and Developing with HLA
  • time being our most precious resource to contribute, I am constantly trying to identify "time eaters", as in common debates/discussions or features requests and flame wars, and summarize things using the wiki, to hopefully waste a little less time when dealing with them in the future, just posting a link instead.
  • consistency not exactly being our greatest forte, trying to structure and streamline things, also using primarily the wiki

Realistically, none of these will be finished anytime soon - but we can certainly pave the way, i.e. by writing tutorials and documenting issues.

Overall, this includes coming up with various Canvas/Nasal based frameworks that actually support these use-cases right from the beginning, in particular:

Wiki Stuff

Note  These are articles I am hoping to revisit sooner or later