|
|
| Line 1: |
Line 1: |
| {{FGCquote
| | undefined |
| |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)
| |
| |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33699619/
| |
| |title=<nowiki>Re: [Flightgear-devel] Launcher issues on Linux</nowiki>
| |
| |author=<nowiki>James Turner</nowiki>
| |
| |date=<nowiki>2015-04-03</nowiki>
| |
| }}
| |
| }}
| |
|
| |
|
| {{FGCquote
| | === Test === |
| |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.
| | This text has been added via AJAX. |
| |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33699619/
| |
| |title=<nowiki>Re: [Flightgear-devel] Launcher issues on Linux</nowiki>
| |
| |author=<nowiki>James Turner</nowiki>
| |
| |date=<nowiki>2015-04-03</nowiki>
| |
| }}
| |
| }}
| |
| | |
| {{FGCquote
| |
| |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)
| |
| |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=225196#p225196
| |
| |title=<nowiki>Re: How to add sort of addon? </nowiki>
| |
| |author=<nowiki>Hooray</nowiki>
| |
| |date=<nowiki>Sat Nov 22</nowiki>
| |
| }}
| |
| }}
| |
| | |
| {{FGCquote
| |
| |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 [https://en.wikipedia.org/wiki/Package_management_system package management system] that is multi-platform and open source (e.g. [http://sourcey.com/pacm/ pacm] or [http://conda.pydata.org/miniconda.html#miniconda 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.<br/>
| |
| But most of the infrastructure is already available, i.e. was implemented for installing aircraft and managing scenery via TerraSync.<br/>
| |
| <br/>
| |
| And particularly [http://sourcey.com/pacm/ pacm] is looking pretty good actually.<br/>
| |
| However, historically, the project tends to "re-invent the wheel" more often than not ...
| |
| |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=216665#p216665
| |
| |title=<nowiki>Re: Alternative camera control</nowiki>
| |
| |author=<nowiki>Hooray</nowiki>
| |
| |date=<nowiki>Thu Aug 14</nowiki>
| |
| }}
| |
| }}
| |