popping up and crashing when the B-29 model is in use. This isn't the
right solution; we should fine the NaN condition. But it's harmless
and allows development with the B-29 to continue.
back, but forgot to put the same fix into the runtime code. Also
added some comments so I don't get confused again the next time I come
through here. :)
I still work on getting the YASim models see the detailed environment
especially the carrier.
I have *forgotten* to initialize and to destruct the ground cache object!
Oooopppss!
currently just returns a lagged normalized value in the range of 0-1 that
is proportional to N1. It's up to the engine gauge to scale to the right
range. This is for lack of a real model of these items so we can have
something to drive the engine gauges.
I have now split out the ground cache functions into src/FDM/groundcache.[ch]xx
Attached are the two files and the patch to integrate that cache into
FGInterface.
The code is nowhere used at the moment, the fdm's need to be updated to use
that ground cache. The JSBSim-dropin.tar.gz from Martins ftp server does this
for example.
The carrier's scenegraph is not yet processed to be visible for ground
intersection testing. So the only benefit up to now is that the api is set
up. Using this I can put the changes to make JSBSim work with that into
JSBSim's cvs. Also I aim to provide Andy a patch to make use of that with
YASim.
I've added two new debug log types for the instrumentation and systems. They
used to use the autopilot debug log, because I couldn't figure out how to
make new log types. Well, now I have figured it out. ;-)
As I had reported on 2004/8/4 00:02:56 ("yasim + bo105 + vrp + @#%$#@ == argh!")
there must be a bug somewhere in YASim, which is responsible for the Bo105
turning around the FDM origin (nose tip) rather than the CG. Some people assumed
that I was just another victim of the "view offset" illusion, but this wasn't
and isn't the case.
Maik Justus (the rotor man) has now supposedly found the bug in YASim[1].
Look at this code in FDM/YASim/Integrator.cpp:35--66:
Stub in hooks for Propeller feathering controls and the turbo prop "condition"
lever.
I added a line in FGFDM.cpp to force control properties to exist if they
don't already. This way you can specify anything you want and find them
in the property browser, otherwise no one else may create them and you are
stuck.
In PropEngine::solve() the code original sets _running = true at the
beginning and then sets running = false at the end. I changed this to
save the current value at the start, set to true, solve(), and then
restore the original value at the end. That way if we start off with
_running = true, we don't have to hack up the calc() routine which wasn't
using the value anyway.
Finally I added some very initial support to shut down a turbine engine
(_running = false) when the condition lever goes to zero.
I have 3 issues that are fixed by this set of patches.
1. In extensions.cxx
#else if !defined( WIN32 ) must be changed by
#elif !defined( WIN32 ) because the text after #else
seems to be ignored
2. banner is not available on windows, only cygwin
3. ANSI escape sequences are not interpreted on the
windows console. We just have garbage that is hard
to read.
the 30 seconds that Maik had originally intended, according to the comment.
This is important for the pending sound and rotor disc changes (and of course
for realism).
"slow/windmilling propeller" regime. I'm happy with the foundations
of the solution, but this hasn't been complete tested yet. The
solution behavior seems fine on the planes I tried.
