20,741
edits
FlightGear Headless: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 5: | Line 5: | ||
{{Note|Also see [[Testing]]}} | {{Note|Also see [[Testing]]}} | ||
{{cquote|The primary goals are: | |||
* make startup more predictable and less hard-coded. | |||
* allow running flightgear in a server/test mode with only some subsystems, and no rendering | |||
Obviously supporting a standalone 'fgcanvas' would be quite a small extension from those. I'm not worrying about dynamic dependencies or automatic subsystem creation for the moment - I expect the user / defaults to have defined a set of subsystems that work without crashing You're correct of course that Nasal has many assumptions about subsystems, but I think that can be improved incrementally on the Nasal side. | |||
For the test mode, I really want to start Nasal-the-langauge very early, without loading all the modules in Nasal/ immediately. (Or maybe load a 'safe' subset). That's going to take some thought and I didn't get that far yet!<ref>{{cite web |url=http://forum.flightgear.org |title=incremental initialization of SGSubsystems|author=James Turner |date=Oct 01, 2012}}</ref>|James Turner}} | |||
{{cquote|I'm working on a prototype of this - with no X11 / VLC required at all. It will load scenery tiles (for ground-intersections) but no views or rendering. But don't be in a rush for something to appear in Git, it's just an experiment.<ref>{{cite web |url=https://code.google.com/p/flightgear-bugs/issues/detail?id=882 |title=Issues 882 (Improved CI / regression testing support by providing options to disable interactive features (sound/window))|author=James Turner |date=Sep 26, 2012}}</ref>|James Turner}} | |||
== Status (08/2013) == | == Status (08/2013) == | ||
| Line 15: | Line 28: | ||
{{cquote|I'm interested in the capability of doing multiple builds with different versions, branches and options and in doing some kind of automated testing on the resulting builds<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40416.html|title=<nowiki>Re: [Flightgear-devel] FG 2.12 RC Broken ?</nowiki>|author=Pat|date=Wed, 03 Jul 2013 17:24:19 -0700}}</ref>|Pat}} | {{cquote|I'm interested in the capability of doing multiple builds with different versions, branches and options and in doing some kind of automated testing on the resulting builds<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40416.html|title=<nowiki>Re: [Flightgear-devel] FG 2.12 RC Broken ?</nowiki>|author=Pat|date=Wed, 03 Jul 2013 17:24:19 -0700}}</ref>|Pat}} | ||
{{cquote|Make subsystems create-able and removable from commands. Only some subsystems are supported so far, since many have non-default constructors or other complexities. | {{cquote|Make subsystems create-able and removable from commands. Only some subsystems are supported so far, since many have non-default constructors or other complexities. | ||
| Line 22: | Line 33: | ||
With this, change, it's possible to dynamically add and remove the traffic-manager at runtime, for example: | With this, change, it's possible to dynamically add and remove the traffic-manager at runtime, for example: | ||
<syntaxhighlight lang="nasal">fgcommand("add-subsystem", props.Node.new({ "subsystem": "traffic-manager", "name":"traffic-manager", "do-bind-init":1}));</syntaxhighlight><ref>{{cite web |url=https://gitorious.org/fg/flightgear/commit/8608a480736651999c5ea31a489343ee097ee915 |title=Initial work on dynamic subsystem creation.|author=James Turner |date=Oct 01, 2012}}</ref>|James Turner}} | <syntaxhighlight lang="nasal">fgcommand("add-subsystem", props.Node.new({ "subsystem": "traffic-manager", "name":"traffic-manager", "do-bind-init":1}));</syntaxhighlight><ref>{{cite web |url=https://gitorious.org/fg/flightgear/commit/8608a480736651999c5ea31a489343ee097ee915 |title=Initial work on dynamic subsystem creation.|author=James Turner |date=Oct 01, 2012}}</ref>|James Turner}} | ||
{{cquote|could some thought be given to producing a benchmark suite for Flightgear. It would need to take in all of the, by now well known, variables - making it by no means a simple beast to manage. | {{cquote|could some thought be given to producing a benchmark suite for Flightgear. It would need to take in all of the, by now well known, variables - making it by no means a simple beast to manage. | ||