Andy Ross writes: > This could actually be done with minimal C++ code. Picture a "failure > manager" that walks a property tree under "/failures". For each > child, it reads a "mtbf-sec" property and sets the "working" boolean > with a random probability that corresponds to the failure rate. This > is maybe a few tens of lines of C++. > > So each failure system then sets something like > "/failures/static-pressure/mtbf" to 100000 in an initialization file. > And the relevant system (the ASI and altimeter, in this case) just > checks the value of "/failures/static-pressure/working". Most of this > can be done using the existing property conditions as-is. A few > failure modes (engine failures, maybe) might require FDM intervention, > but most are just of the "turn off the gadget" form.
I would agree that it makes sense to just load up the failure status into a subtree in our property system, and then the modules that impliment the various items would need to check the failure status and also impliment failure modes in addition to implimenting correctly working behavior. We could have a separate system that tries to impliment realistic failure rates ... that could be cool for the general default behavior if the failure rates were indeed realistic. However, we would also need to be able to turn off the auto-failure generation module and allow an instructor (or a script) have complete control over the failures. This way an instructor could use the sim to train for specific failure scenarios and have complete control over when, where, and what happens. Here's where scripting could be useful to reduce the interactive load on the instructor ... and would allow the instructor to impliment more insidious and 'ill timed' failures. >From what I've seen, instructors take great pleasure in maximizing the pain of their student (so to speak.) :-) But the flip side of this is that if the student can learn to handle the worst case scenarios, then hopefully they'll be well trained to handle more typical emergencies. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
