20,741
edits
FlightGear run levels: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
mNo edit summary |
|||
| Line 18: | Line 18: | ||
Come up with a design to make subsystem initialization more explicit, and provide dependency resolution (run levels or system groups), so that subsystem initialization can be better controlled and explicitly enabled/disabled during startup. | Come up with a design to make subsystem initialization more explicit, and provide dependency resolution (run levels or system groups), so that subsystem initialization can be better controlled and explicitly enabled/disabled during startup. | ||
== Ideas == | |||
{{cquote|My 'run-level' idea is almost the same, but rather than a flag, I'd have a /sim/runlevel property, and have the listeners watch for it changing. Eg, have the listener fire when run level was > 4 or 8, and stop when the run-level dropped lower again. Having separate signals for each subsystem seems like overkill, but what I am considering is naming the groups, and then having a /sim/signals/ or /sim/subsystems/ entry for each; of course we would need to introduce finer-grained groups but that's easy enough to do - the code already works with everything in just one flat group! | |||
As I say, I'm still trying to decide what approach is cleaner; the run-level concept is just one property, and nicely encapsulates the hierarchy of subsystems (if you're switching to level 8, all lower levels must already be initialized). But having names and separate flags makes the actual dependency clearer: 'this script depends on the aircraft subsystems' or 'this script depends on the environmental subsystems'. I guess it partly depends how complex the dependencies for any given script are in practice - hopefully they're actually quite simple.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03386.html |title=Subsystem run-levels|author=James Turner |date=17 April 2006 }}</ref>}} | |||
<references/> | <references/> | ||