Re: [Flightgear-devel] Re: Subsystem run-levels

[James Turner]

On 18 Apr 2006, at 10:07, Melchior FRANZ wrote: As you know, the reason for Nasal being the last of the subsystems is that it processes the files in $FG_ROOT/Nasal/ on initialization. And the idea was that these scripts should find all subsystems initialized, so that they can access some generated properties immediately (such as values added by the envirnoment subsystem etc.). But some of the subsystems do in turn need Nasal, which is why the postinit() method was introduced. To make things worse, some of the startup Nasal scripts need each other. Most require props.nas, for example. And this is why we need the "settimer(INIT, 0)" delay. I noticed most of the above, and some of that evolution was apparent from the comments, but it's good to see the whole progression in one place! Alternatively, the subsystems could set a 'signal'. This is a trivial but useful feature that I introduced not too long ago. Some events in fgfs simply set a bool property in /sim/signals/, for example: /sim/signals/reinit on reinitialization (Shift-Esc), or /sim/signals/exit on exit. That way Nasal code can attach listeners to the signal, and have code triggered by the event. A wrapper around that could look like this:   what) {       setlistener("/sim/signals/subsystem/" ~ which, what);   } Then Nasal files that *really* want to wait for a subsystem, could say   on_subsystem_init("environment", print_temperature); Or one could make the boolean become true on subsystem initialization, and false on subsystem destruction (useful for changing aircraft during an fgfs session, etc.) 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. H&H James