User:Red Leader/Sandbox/AJAX test
< User:Red Leader | Sandbox
Jump to navigation
Jump to search
|
My long term goal here would be that fg-aircraft goes away, and we actually specify aircraft via their package ID only, with no aircraft-dir set either. But that’s a much bigger step.
(Of course only in a world where all aircraft are run from a package, we still need these options for ad-hoc aircraft and development) — James Turner (2015-04-03). Re: [Flightgear-devel] Launcher issues on Linux.
(powered by Instant-Cquotes) |
|
|
|
The dependencies system has never been tried, but the intent is to allow non-aircraft packages of shared resources to be used (i.e common files for all aircraft in a hangar), the question is what option(s) are used to add those packages to the aircraft search list at runtime. Probably the fg-aircraft mechanism is exactly what is needed here.
— James Turner (2015-04-03). Re: [Flightgear-devel] Launcher issues on Linux.
(powered by Instant-Cquotes) |
|
|
|
Historically, FlightGear tends to re-invent the wheel more often than not unfortunately - but adopting a package/plugin framework would definitely make sense. While we can certainly proceed without one, the outcome is likely to be hugely incompatible and cause a ton of chaos - once you think about just how many features were/are developed as "addons", some more attention should be given to such considerations and requirements (bombable, advanced weather, fgcamera, tutorials etc)
|
|
|
|
The question is how far we'd want to go with something like this - because at some point, it would make more sense to adopt an existing package management system that is multi-platform and open source (e.g. pacm or miniconda). Otherwise, most of the building blocks for a simple package manager are already available to Nasal, i.e. http bindings and SGPath wrappers to download stuff into $FG_HOME and install stuff there. Even though it would probably make sense to also expose zlib (i.e. for extracting compressed archives). Metadata for package names, dependencies, URLs and version/description info could be provided via existing PropertyList XML files. So there's very little missing to pull this off, and a simple prototype for an existing addon, like FGCamera, should be fairly straightforward to build - it's mainly a matter of integrating existing technologies properly, and exposing them first to scripting space. But most of the infrastructure is already available, i.e. was implemented for installing aircraft and managing scenery via TerraSync. |
|
Test2
This text has also been added via AJAX.