Hi Sébastien,
Sébastien MARQUE wrote:
<snip>
> I'm sure I'm not clever enough to invent powder, but I've tried a way to
> manage failures in a transparent way for the pilots using alias/unalias
> Nasal capacities.
>
> Indeed every instrument in the panel is the reflect of a property
> aliased to the real data as given by the fdm. When a instrument fails, I
> unalias the property and manage the output calculation with some Nasal
> code, if necessary (i.e. when the output needs to vary even if the
> instrument fails, or gives a wrong information even if the system works
> fine: levels/temps/pressures). This part is still to be done... indeed
> it is in an early devel stage.
>
> I'm also going to try the system too with the rudder, elevator and
> ailerons properties, it means that the fdm config files need to be
> modified to use the aliased prop rather than the usual
> /controls/flight/* ones. This should allow to unalias the props and even
> if the pilot try to make the controls act, it doesn't have the pilot's
> expected effect on fdm.
That's an interesting approach - I hadn't thought of it. However, it has
the disadvantage of requiring changes to aircraft to make it work. The
advantage of the current system is that it is completely generic, and
should work for pretty much every aircraft in the hangar.
> BTW in the same fork I've implemented an engine failure when it is used
> in a non-proper way (more than 5 min full throttle, engine damages
> calculation above 90% throttle, soon will come oil temp and cht temp,
> following engine and flight manuals descriptions, see limitations.nas).
> In order to stop the engine in a more "realistic" manner I use the
> /engines/engine/out-of-fuel prop allowing engine coughs for a certain
> amount of time before being complety off without using magnetos (I find
> ugly to see the magneto switch moving alone in a cokpit :p).
That sounds like a much better way than turning off the magnetos - I'll
investigate using it instead. Thanks!
> For brakes I also use my own implementation of controls.applyBrakes (see
> actions.nas) which is a kind of failure system to avoid the aircraft to
> slow down too quickly and is intented to be improved in order to manage
> wet surfaces and brakes failures.
That's something I haven't implemented yet, but it sounds like a nice
enhancement,
and should be fairly easy to add.
> I've got a question about your script: what do mean MTBF and MCBF, and
> what is the purpose of JAM failure?
MTBF - Mean Time Between Failure
MCBF - Mean Cycles Between Failure
The JAM failure changes the attributes of the property so that is is read-only,
and
cannot be written.
> Last point: I think I've found a possible mistake in static system
> failure with airspeed indicator: indeed I though that with blocked
> statics (dirty or forgotten flames) and pitot working fine, the
> indicated airspeed is higher than real airspeed, but actually it seems
> not to be the case. Indeed the ASI gives some relatively high speed near
> the ground but falls down to zero quite quickly when climbing, then goes
> back to a high value at 0ft/mn climbing... I'm maybe complety wrong and
> the simulated behaviour is correct.
I'd have to look at my books, but I think the ASI only uses the pitot.
Note that I haven't actually changed any of the existing failure modes
(including
/system/static/serviceable) - so it is entirely possible that there are bugs
there.
> PS: I found very nice to have a closer look in failures management
> because this is one of the few "dangers" we have and can simulate,
> keeping the fun-side of FG and improving pilot-skills entertainment.
Absolutely - I think there's a lot of room for interesting development here.
I think the failure manager should be even more generic. In particular, as well
as
the defined failure modes, it would be good to be able to pass in a function to
be
triggered on failure to the manager.
Additionally, the dialog should be built up from the contents of the manager.
-Stuart
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
