scene management code and organizing it within simgear. My strategy is
to identify the code I want to move, and break it's direct flightgear
dependencies. Then it will be free to move over into the simgear package.
- Moved some property specific code into simgear/props/
- Split out the condition code from fgfs/src/Main/fg_props and put it
in it's own source file in simgear/props/
- Created a scene subdirectory for scenery, model, and material property
related code.
- Moved location.[ch]xx into simgear/scene/model/
- The location and condition code had dependencies on flightgear's global
state (all the globals-> stuff, the flightgear property tree, etc.) SimGear
code can't depend on it so that data has to be passed as parameters to the
functions/methods/constructors.
- This need to pass data as function parameters had a dramatic cascading
effect throughout the FlightGear code.
appears still to be indicating.
Added a 'caged' property to the AI, for aerobatic work.
Temporarily disabled tumbling due to pitch, until I can learn more
about it.
Publish the current amount of tumble (-1.0:1.0) under
/instrumentation/attitude-indicator/tumble-norm.
proceed to search for an VOR of that same frequency. On rare occasion
this search could return true with a far distant VOR and cause a small
amount of confusion.
for a little while, since it uses different properties. There are
some improvements, especially with searching and range. It also has
its own serviceable and in-range properties, independent of any
coupled VOR.
a spinning gyro.
Changed FGInstrumentMgr to inherit from FGSubsystemGroup, greatly
simplifying the (already simple) class. I should probably rename this
to FGInstrumentGroup or something similar, but not today.
Added the gyroscopic turn indicator (part of the TC).
Ok, I found the problem. You're computing the dynamic pressure in
"psf" and adding it to the static pressure in "inHg" to form the
total pressure. The attached patch is the simple fix to the source.
With that fix, failing the pitot while in cruise at 3k' will cause
the airspeed to indicate beyond redline during climb ... well before 4k'.
Thus, a pitot problem can be detected on any IFR altitude change.
Similarly, failing the static (with working pitot) while cruising 4k'
causes the airspeed to indicate beyond redline during a descent
well before reaching 3k' (during which, of course, the ALT looks fine).
Thus, a static failure can be detected before the aircraft breaks out
of the pilot tolerance range and is blatantly conspicuous soon after.
