Josh Babcock wrote:
Does anyone know of some sort of gear serviceable property? I'm trying to model a set of emergency gear motors driven off a separate bus, but I don't know how to connect the gear to the buses, or even make the normal gear mechanism fail.
I'm not aware of a specific gear servicable property.
If not, I think I can do it with nasal, and I will be needing nasal anyway because these gear are controlled by an instantaneous switch, which is not natively supported afaik.
Nasal isn't a bad approach. Many/most of the systems that are common among aircraft are modeled already in the FlightGear code, but things like gear failure and the specific failure modes, system dependencies, work arounds, procedures, etc. can get really aircraft specific. This is where Nasal is really slick. It's very small/tight, and amazingly capable for it's size. It gives you a high degree of programmability, and can be setup so it is specific to your aircraft.
I'm working on a light twin project and one thing I've done recently is to model all the annunciators (similar to the dash board lights in your car.) I'm not aware of any FG airplanes that have annunciators modeled, but these are common in aircraft. We can do them quite easily, but I don't think any aircraft designers have looked into these yet.
For my project I have a couple nasal routines that compute some values derived from the existing properties. With nasal I can test the state of various FG properties, then set a fault/warning condition. In nasal, I can even blink the light for the first 10 seconds. I write the resulting properties into a separate subtree in the global property tree. Finally I created a custom gauge that is driven from these properties. The result looks something like this:
http://www.flightgear.org/~curt/tmp/moj-ann.jpg
One thing I've found is that so many of our subsystem have so much configurability and power, you have to stop and think about the best place to impliment something. For instance I wanted a gear horn that would sound when you cut the throttle but the gear is still up. This can be done entirely in the sound configuration file with conditionals (which speaks a lot for the power of the audio subsystem.) Later though I decided I also wanted an annunciator light to give a visual warning of this same condition, so I moved the logic into a nasal routine. That way a single piece of code could drive both the audio and visual warnings rather than replicating the logic in multiple places.
The combination of nasal and configurable systems (with xml conditionals) give us an amazingly powerful system for modeling aircraft and systems. The more I work with these, the more impressed I am.
Regards,
Curt.
--
Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
