There was a patch from Manuel Masing a few months ago which cleaned up
SGLocation's way depending on input values. That means that with that patch
SGLocation does no longer have calls with unneeded input arguments.
I took his patch and integrated that into flightgear and made maximum use of
that changes.
Erik Hofman:
Remove some duplicate code that was moved to simgear/compiler.h
I have prepared a patch that:
- Introduces a FGTileMgr::scenery_available method which asks the tilemanager
if scenery for a given range around a lat/lon pair is already loaded and make
use of that method at some -9999 meter checks.
- Introduces a FGScenery::get_elevation_m method which queries the altitude at
a given position. In constrast to the groundcache functions this is the best
choice if you ask for one *single* altitude value. Make use of that thing in
AI/ATC classes and for the current views ground level. At the current views
part the groundcache is reused if possible.
- The computation of the 'current groundlevel' is no longer done on the
tilemanagers update since the required functions are now better seperated.
Alltogether it eliminates somehow redundant terrain level computations which
are now superseeded by that more finegrained functions and the existence of
the groundcache. Additionally it introduces an api to commonly required
functions which was very complex to do prevously.
I have now included a patch to the multiplyer protocoll which does:
1. place the 3d model into the scenery using a placement transform which can
dynamically change its scenry center.
2. Transmits unique position and orientation data for the 3d model.
3. Thus breaks protocol compatibility.
Oliver Schroeder:
With help from Norman I fixed the alignment in the used headers.
But this patch again fixes only symtoms, not the problems. I suggest to
put it into cvs anyway, as it will enable the majority to get experience
with the multiplayer mode.
in terms of predictable packing and byte ordering. So rather than trying to
get fancy and shave a few bits off the structure sizes, just go with 32 bit
ints for everthing which saves a lot of potential headaches in the cross
platform and cross architecture arenas.
ssgSetNearFar(). This by default creates a symmetric view frustum which is
typically what an application wants.
However, to get control of the view frustum in order to build support for
asymmetric view frustums, we need to wrap these calls with a bit of our own
logic.
This set of changes wraps all calls to ssgSetFOV() and ssgSetNearFar() with
FGRenderer methods.
I also standardized how the FGRenderer class is handled in globals.[ch]xx.
This led to some cascading changes in a variety of source files.
As I was working my way through the changes, I fixed a few warnings along
the way.
I've finished the emigration of the radiostack, and I've also removed it
completely. It turned out that the comm radio is completely implemented in
the ATC subsystem. I've changed the affected ATC files to point
to /instrumentation/com, but I guess that the maintainer of the ATC code
should decide wether to make it configureable, and how.
I also had to change some files in Network and Main. The changes in network
should be obvious, but the changes in Main were a bit suspect. The files
included radiostack.hxx, but they weren't directly depending on
radiostack-hxx. They were depending on other files that were included by
radiostack.hxx. I got it to compile, but I'm not sure if I included the
correct directly depending file.
For the data directory I changed every occurrence of /radios/
with /instrumentation/ with this simple one-liner that I found on the net:
find -name '*.xml' -type f | xargs perl -pi -e
's/\/radios\//\/instrumentation\//g'
Instead of me sending all the files that got changed by this I suggest that
you execute the one-liner yourself. Of course I can not guarantee that this
will work perfectly, but I considered hand editing to be not an option (I'm
lazy). I don't want to test every aircraft to see if everything still works,
I think it's better to wait and see if anyone complaints about broken nav
radios/instruments.
systems. Fix a couple bugs/oversights.
- atc610x.cxx: Much code has moved into the configurable input mapper
(ATC-Inputs.cxx) and the remaining input massaging code has moved into
the atcsim.nas module.
- 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.)
Some more cmall changes to the SimGear header files and removed the
SG_HAVE_NATIVE_SGI_COMPILERS dependancies from FlightGear.
I've added a seperate JSBSim patch for the JSBSim source tree.
Use getDisplayName instead of duplicated code: gives a better
decision on whether to display the index.
Replace unnecessary node lookups by name with direct access: tidier
and more efficient. E.g. "getValueTypeString
(node->getNode(name.c_str()))" -> "getValueTypeString (child)".
- Removed some old cruft.
- Removed some support for older versions of automake which technically was
correct, but caused the newer automakes to squawk warnings during an
initial sanity check (which isn't done very intelligently.)
NOTE: this fix is technically not correct for older version of automake.
These older version use the variable "INCLUDES" internally and could have
them already set to an important value. That is why we were appending
our values to them. However, newer versions of automake don't set this
value themselves so it is an error to append to a non-existant variable.
We seem to "get away" with overwriting the value on older versions of
automake, but if you have problems, consider upgrading to at least
automake-1.5.
I've merged FGProps and FGTelnet so there is just a single property server.
I've left in the --telnet=port# command line option but it could be removed
if we wanted to. The command line accepts two forms of the --props option.
The original (--props=medium,dir,hz,host,port#,style) and the shorter
--props=port#. If you accept this change then src/Network/telnet.[ch]xx
can be removed from the cvs repository.
- More progress with proper radio freq tuning and proper interpreting of the
hardware values.
- Filter ignition and flap switch values since the hardware implimentation has
a dead zone where the value can go to zero in the middle of a change in
switch position.
Fetch all pending remote fdm network packets so there is not chance of
getting behind.
Add support for driving control panel lights.
Working on better modeling KX 155 tuning behavior.
