Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

User:Red Leader/Sandbox/AJAX test

From FlightGear wiki
Jump to: navigation, search
Cquote1.png 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)
Cquote2.png
Cquote1.png 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)
Cquote2.png
Cquote1.png 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)
— Hooray (Sat Nov 22). Re: How to add sort of addon?  .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.

And particularly pacm is looking pretty good actually.
However, historically, the project tends to "re-invent the wheel" more often than not ...


— Hooray (Thu Aug 14). Re: Alternative camera control.
(powered by Instant-Cquotes)
Cquote2.png

Test2

This text has also been added via AJAX.