2,733
edits
Red Leader (talk | contribs) (A test) |
Red Leader (talk | contribs) (Undo revision 90034 by Red Leader (talk)) |
||
Line 1: | Line 1: | ||
{{FGCquote | |||
|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 | ||
|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. | |||
|{{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> | |||
}} | |||
}} |