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)"


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.


Reply via email to