I did this so that I could play with the UIUC stuff without losing
Tony's C172 with its flaps, etc. I did my best to respect the design
of the LaRCsim code by staying in C, making only minimal changes, and
not introducing any dependencies on the rest of FlightGear. The
modified files are attached.
Removed all sgMultMat4 in favor of Pre/PostMultMat4. Steve says there is
an error in MultMat4 that isn't found in Pre/Post. He wants to fix it which
means different versions of plib could work differently from each other.
curt [Sun, 26 Mar 2000 17:19:39 +0000 (17:19 +0000)]
David Megginson: I've created a couple of very simple textures: one for
the NAV face, and one for a NAV needle (just a thin, slightly blurry red
line for now). I'm attaching my two new textures, together with my newest
panel.cxx (modified from Alex's to use the new textures). Obviously,
there's a lot more to do, including TO/FROM indicators, but this is a
start, and it's fun.
curt [Sun, 26 Mar 2000 16:52:36 +0000 (16:52 +0000)]
NAV1 is now the ILS-28R on airport KMYF,
NAV2 is now the VOR radial 068 from MZB,
ADF is now the Compass locator on the outer marker.
This combination is more than the legally required to
fly any of KMYF-ILS-28R, KMYF-LOC-28R KMYF-NDB28.
If you don't have access to the approach plates
and would like them, let me know and I'll scan them
(and put them on the webpage area).
The approaches do work; I've checked them all out in
terms of altitude profile, centerlines and other stuff.
In real life, the radar vectoring will basically abandon you
overhead KSEE airport at 4000 ft heading 210 or so. Sometime
later you'll be turned to a heading of 260 if the controller
doesn't have too much else to do, just before you hit the
extended centerline. You can't rely on that though.
Maintain 3500ft until established, 2100 ft until the outer marker,
If non-precision, maintain 1340 until crossing the radial,
then 900 thereafter until you miss, based on time from the NDB.
The miss takes you heading 270 to intercept a radial which this
hacky implementation will not let you set up the computer for.
The hacky math implementation does not take range and/or signal
strength into account, so you can fly to San Diego from England
by following the needle indication on the ADF. It is also
fairly inaccurate math; about as accurate as the real-life signals.
When we have a _real_ radio module, I will be very happy to
throw all that code away. For now, it makes it demonstratable.
Please notice the nastiness involving the "VARY_E" constant.
This is _not_ something that will go away with the radio module.
As far as I know, we don't have a routine that calculates
magnetic variation as a function of global position.
We will need one, probably within the next two months.
curt [Wed, 22 Mar 2000 22:01:33 +0000 (22:01 +0000)]
UIUC flight model contribution. This is based on LaRCsim, but can read
the aircraft parameters from a file. It still uses Tony's <crappy> (and I
mean that in a constructive way) gear model. :-)
curt [Sat, 19 Feb 2000 14:29:27 +0000 (14:29 +0000)]
Removed all dependencies on <simgear/math/mat3.h> and friends. These are
old routines from SRGP. Steve's plib/sg.h does a nice job of completely
replacing this (and since plib is already around) and is a nice clean design
so it just makes sense.
curt [Thu, 13 Jan 2000 20:12:16 +0000 (20:12 +0000)]
The aircraft model used for external views was being included in the height
above terrain check so when the view position and the aircraft model collided
the current altitude kept getting pushed up to compensate, but of course the
aircraft model would get pushed up as well because it tracks the current
aircraft position and orientation. Thus you had a never ending cycle ...
projects / flightgear.git / log