I have some small updates to the ground cache.
- Remove the usage of dynamic_cast where it is known that the result will be
non null.
- Renormalize the surface normal in double precision.
- Place the groundcaches center at the point it was requested not at the
scenery center. This fixes the problems with JSBSim's trimming together with
the ground cache. Now I am ready to commit JSBSim's ground cache usage.
have a "property" mode as well as the original "binary" mode. The property mode
will allow the remote module to request any set of properties, and it will send
those properties each frame. The remote module can reply with a list of arbitrary
property name/value pairs to update on the FlightGear side.
This is a first stab, so it's not the cleanest, most well concieved code, but it
allows an external module (communicating via a pipe) to have a huge amount of
flexibility in the data in can access and update.
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.
PistonEngine class has grown an "Engine" superclass. Some other stuff
moved around too, and I cleaned up some property naming while I was in
there. This hasn't been tested very thorougly, hopefully I didn't
break anything.
configure and compile out-of-the-box on a MinGW target:
Use -lSDL instead of -lglut32 on windows builds when --enable-sdl
is set.
Link against alut.dll in addition to openal32.dll.
Replace BSD bcopy() with ANSI C memmove() in a few places. This is
simpler than trying to abstract it out as a platform dependency in a
header file; bcopy() has never been standard.
The ENABLE_THREADS handling has changed to be set to 0 when threads
are not in use. This breaks expressions like #ifdef ENABLE_THREADS.
Replace with a slightly more complicated expression. It might have
been better to fix the configure.ac script, but I didn't know how and
this whole setting is likely to go away soon anyway.
The MinGW C runtime actually does include snprintf, so only MSVC
builds (and not all WIN32 ones) need _snprintf in JSBSim/FGState.cpp
Building on a platform with no glut at all exposed some spots where
plib/pu.h was being included without a toolkit setting (it defaults to
glut). Include fg_os.hxx first.
And when still using glut, glut.h has a bizarre dependency on a
_WCHAR_T_DEFINED symbol. It it's not defined, it tries to redefine
(!!) wchar_t to disasterous effect.
This update contains a change to not overwrite the altitude-ft preset during
"onground" start. The change also prevents a ground trim issue with the
JSBSim fdm when a "reset" is done by FlightGear.
work on the pa28 idle and without creating ridiculous side effects
(like being able to fly the aircraft with the starter motor, heh).
This one looks pretty good for now, pending work on the propeller to
get its low speed drag in line with reality.
reads the /consumables tree for input to determine weights, but
places output only in /engines/engine[n]/fuel-consumed-lbs where
it gets picked up by the Nasal code.
This is a fix for my earlier "Remove some hardcoded dependencies between fdm,
viewer and acmodel" patch. The problem was discovered when testing the
wrightFlyer.
deriving a class and the base class used this type.) Return to using
const char and hope people compiling against earlier versions of plib
have compilers that think typedef const char cchar; char *abc; is equivalent
to const char *abd;
controls in the cockpit vs. which wheels they apply to. FlightGear now
sets /controls/gear/brake-left, /controls/gear/brake-right, and
/controls/gear/brake-parking. It should be up to the FDM to sort out
which wheels under which circumstances are affected by these controls
and ultimately what happens to the physical motion of the aircraft.
places now use sgCartToGeod() instead of rolling their own
approximation. And YASim is now using exactly the same 3D coordinate
system as the rest of FlightGear is.
the core YASim stuff. Mostly cosmetic: whitespace adjustment, dead
code & meaningless comment removal, a little code motion to better
partition the helicopter handling from the original code (no more
giant if() { ... } around the solver). Added a warning to the parser
to try to eliminate the string booleans that crept in.
There should be NO behavioral changes with this checkin.
Here's a new FGSimTurbine module. Changes are:
1. Adds starting and stopping functionality
2. Calculate() now calls other functions, based on the engine's state, which gives more readable code.
Until now turbine engines were always running as long as fuel was available. With this new module the engine defaults to OFF. To start with the engine running, the variable FGEngine::Running must be set to true at sim startup. In FlightGear this is done with --prop:/engines/engine[n]/running=true.
To start the engine (on the ground), first set the starter to ON, i.e. FGEngine::Starter is set to true. In FlightGear this is done by toggling /controls/engines/engine[n]/starter to TRUE. Note that the current FlightGear key binding will not work, as it causes the starter to quit when the key is released. A new key binding is needed, without the mod-up.
When N2 reaches 15% or greater, place the fuel cutoff control to FALSE. This is FGEngine::Cutoff. In FlightGear this is done with /controls/engines/engine[n]/cutoff set to FALSE. The engine will then accelerate to idle. Upon reaching idle, the starter is automatically turned off, and the engine is running. There is presently no FlightGear key binding for the fuel cutoff switch.
To shut off the engine, place the fuel cutoff control to TRUE.
If you shut down the engine in flight it will windmill. To airstart you will need at least 15% N2, just as with a ground start. When you have enough N2, place the cutoff control to FALSE and the engine will restart. Note that if you can't get enough N2 by speeding up, you can get it by using the starter.
The reverser still works, and is controlled in FlightGear with /controls/engines/engine[n]/reverser. With the reverser control on (TRUE), the engine will produce negative thrust in proportion to throttle position, i.e. to get more reverse
thrust, increase throttle.
Here's a new FGSimTurbine module. Changes are:
1. Adds starting and stopping functionality
2. Calculate() now calls other functions, based on the engine's state, which gives more readable code.
Until now turbine engines were always running as long as fuel was available. With this new module the engine defaults to OFF. To start with the engine running, the variable FGEngine::Running must be set to true at sim startup. In FlightGear this is done with --prop:/engines/engine[n]/running=true.
To start the engine (on the ground), first set the starter to ON, i.e. FGEngine::Starter is set to true. In FlightGear this is done by toggling /controls/engines/engine[n]/starter to TRUE. Note that the current FlightGear key binding will not work, as it causes the starter to quit when the key is released. A new key binding is needed, without the mod-up.
When N2 reaches 15% or greater, place the fuel cutoff control to FALSE. This is FGEngine::Cutoff. In FlightGear this is done with /controls/engines/engine[n]/cutoff set to FALSE. The engine will then accelerate to idle. Upon reaching idle, the starter is automatically turned off, and the engine is running. There is presently no FlightGear key binding for the fuel cutoff switch.
To shut off the engine, place the fuel cutoff control to TRUE.
If you shut down the engine in flight it will windmill. To airstart you will need at least 15% N2, just as with a ground start. When you have enough N2, place the cutoff control to FALSE and the engine will restart. Note that if you can't get enough N2 by speeding up, you can get it by using the starter.
The reverser still works, and is controlled in FlightGear with /controls/engines/engine[n]/reverser. With the reverser control on (TRUE), the engine will produce negative thrust in proportion to throttle position, i.e. to get more reverse thrust, increase throttle.
now read the config file out of the individual aircraft directory rather
than the collective Aircraft-yasim/ directory (which is now obsolete.)
This requires a corresponding update of the base package cvs.
The Propeller class ignored negative RPM but still returned a torque
value, which ratcheted up a higher and higher negative RPM until drag
overwhelmed the aircraft.
In reality, the propeller should windmill at a reasonable postive RPM,
introducing a constant drag on the aircraft -- the propeller should
*not* stop unless the plane is flying very slowly. That's a future
project.
I have added a fledgling replay system that records flight data and control
positions during the flight.
I have added an internal command called "replay" which will trigger a replay
of the entire saved flight data set. This could be bound to a keyboard or
menu command, in fact this entire module is screaming for someone to build
a gui to control playback speed, amount of playback, etc.
This is the initial version so there are kinks that still need to be worked
out, please be patient.
Square the normalized direction acceleration for the y and z axes, so
that turbulence predominantly affects pitch.
Bind to the /environment/turbulence/magnitude-norm and
/environment/turbulence/rate-hz properties in FlightGear.
