6,609
edits
FlightGear run levels: Difference between revisions
Jump to navigation
Jump to search
Switch to {{flightgear source}} and {{flightgear url}} to fix the broken Gitorious links.
(Switch to {{flightgear source}} and {{flightgear url}} to fix the broken Gitorious links.) |
|||
| Line 15: | Line 15: | ||
{{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. | ||
With this, change, it's possible to dynamically add and remove the traffic-manager at runtime, for example: fgcommand("add-subsystem", props.Node.new({ "subsystem": "traffic-manager", "name":"traffic-manager", "do-bind-init":1}));<ref>{{cite web |url= | With this, change, it's possible to dynamically add and remove the traffic-manager at runtime, for example: fgcommand("add-subsystem", props.Node.new({ "subsystem": "traffic-manager", "name":"traffic-manager", "do-bind-init":1}));<ref>{{cite web |url={{flightgear url|commit=8608a480736651999c5ea31a489343ee097ee915|view=commit}} |title=Initial work on dynamic subsystem creation.|author=James Turner |date=Oct 01, 2012}}</ref>|James Turner}} | ||
{{cquote|The primary goals are: | {{cquote|The primary goals are: | ||
| Line 146: | Line 146: | ||
It is worth noting that all startup arguments implemented via properties (--prop:) can be also trivially supported at runtime using listeners or conventional polling, i.e. supporting runtime changes of these properties is comparatively simple and a well-understood task. | It is worth noting that all startup arguments implemented via properties (--prop:) can be also trivially supported at runtime using listeners or conventional polling, i.e. supporting runtime changes of these properties is comparatively simple and a well-understood task. | ||
So looking at the code in | So looking at the code in {{flightgear source|src/Main/fg_init.cxx|text=fg_init.cxx}}, the major problem is indeed all the static, hard coded, initialization code which assumes a statically defined initialization order. | ||
In other words, our problem is that we have routines which are sequentially called and which call each other. Routines that were never designed to be called individually, in a different order. | In other words, our problem is that we have routines which are sequentially called and which call each other. Routines that were never designed to be called individually, in a different order. | ||
| Line 152: | Line 152: | ||
These hard coded init assumptions are exactly what makes runtime re-initialization so difficult and non-deterministic currently (see [[FlightGear Sessions]] for more info). Once we start using properties and listeners to implement '''all''' existing startup arguments, we would ''automatically'' have a fully runtime-configurable system, because callbacks would never be invoked directly at the C++ level, but instead be indirectly invoked by setting properties. | These hard coded init assumptions are exactly what makes runtime re-initialization so difficult and non-deterministic currently (see [[FlightGear Sessions]] for more info). Once we start using properties and listeners to implement '''all''' existing startup arguments, we would ''automatically'' have a fully runtime-configurable system, because callbacks would never be invoked directly at the C++ level, but instead be indirectly invoked by setting properties. | ||
For example, at the moment we have code in | For example, at the moment we have code in {{flightgear source|src/Main/options.cxx|line=1282|pre=$FG_SRC}} which maps the startup parameters to callbacks, which in turn call custom parsers to further process these arguments. What is really needed is a single SGPropertyChangeListener interface class which wraps the concept of a startup/runtime argument, so that all the argument-related code is wrapped inside a single helper class, instead of being spread over many different places in legacy procedural code. | ||
Such a class would then register property listeners and it would transparently map its properties to startup arguments, so that the valueChanged() callback will be invoked by FlightGear, regardless of it being invoked during startup or at run time. | Such a class would then register property listeners and it would transparently map its properties to startup arguments, so that the valueChanged() callback will be invoked by FlightGear, regardless of it being invoked during startup or at run time. | ||
Furthermore, it is worth noting that we can significantly reduce the complexity of the options/init handling code by moving code to Nasal space and initializing the Nasal interpreter earlier. This applies especially to all the legacy C++ code setting up property defaults, i.e. see [ | Furthermore, it is worth noting that we can significantly reduce the complexity of the options/init handling code by moving code to Nasal space and initializing the Nasal interpreter earlier. This applies especially to all the legacy C++ code setting up property defaults, i.e. see [{{flightgear url|src/Main/options.cxx|line=115}}]. Most of this would be better dealt with in Nasal space. | ||
Once core features and subsystems are initialized via properties, it would be possible to even implement complex run level setups in scripting space. | Once core features and subsystems are initialized via properties, it would be possible to even implement complex run level setups in scripting space. | ||