- We need to be able to support a per engine master bat/alt switch.
- Forgot to write the gear level state into the network structure.
native_fdm:
- renamed EGT->egt for consistancy.
- added manifold pressure to the structure.
null space without killing the engine (hardware specific problem.)
- NMEA output: I'm slightly confused but it appears that a real GPS outputs
traditional unix line endings on it's gps strings, we were outputing DOS
CR/LF which was causing some confusion. This changes the line ending
convention to match that of a real gps.
- Calculate true ground track and speed for NMEA.
I just met a couple of warnings about depricated headers beeng used.
Please take a look at patch (against today cvs) attached wich
does strstream -> stringstream migration. I hope you found it usefull.
latest version is attached to reduce need to search property
tree each frame. I don't think this will break any Fg code and
opengc has been updated a while back and have had no complaints ;-) so it
should be a no impact change, hopefully.
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.
net_ctrls.hxx net_fdm.hxx net_fdm_mini.hxx net_gui.hxx
I, Curtis Olson, being the primary author of these header files, hereby
release them into the public domain to facilitate interfacing FlightGear
with other external code (which might need to remain proprietary or may
be licensed under some not quite GPL compatible terms.)
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.
clarity:
nav_radial => nav_target_radial (same as selected, except for a LOC)
nav_heading => nav_reciprocal_radial
nav_magvar => nav_twist (it's not always the same as magvar)
nav_heading_needle_deflection => nav_cdi_deflection
nav_gs_needle_deflection => nav_gs_deflection
Added nav_radial back in, but now it shows the current radial from the
VOR, as one would expect. This value also appears in the
/radios/nav[*]/radials/actual-deg property.
Normally for smoothest frame rates you would configure to sync
to your monitor's vertical refresh signal. This is card/platform
dependent ... for instance with Linux/Nvidia there is
an environment variable you can set to enable this feature.
However, if your monitor is refreshing at 60hz and you can't quite sustain
that with flightgear, you can get smoother frame rates by artificially
throttling yourself to 30hz. Note that once you are about about 24fps, it
is *change* or inconsistancy in frame rate that leads to percieved jerkiness.
You want to do whole divisors of your monitor refresh rate, so if your
display is syncing at 75 hz, you might want to try throttling to 25 hz.
slave to a specific frame rate (i.e. 30hz). This is potentially desireable
if you are running on the ragged edge between 30/60 hz ...
It would be nice at some point to make the code a bit more flexible and
configurable so it could be activated from the command line or preferences
file.
I split the FGModelPlacement code out into it's own set of source files.
I created two versions of the fgLoad3DModel() routine. One that is
unecumbered by a panelnode dependency and one that is. acmodel.cxx is
the only place that needs to load an aircraft with instrument panels.
model.[ch]xx are now pretty much free to move over into simgear.
loader.[ch]xx should be able to follow closely behind.
This will be a big step towards being able to move the material management
code over into simgear.
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.
hemisphere the distance is positive, if you are in the departure hemisphere
the distance is negature. (Possible use for graphing approach distance
vs. glide slope or cdi.)
