User:Hooray

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
- FlightGear Performance and Run-Time Footprint Debate

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: