Tony submitted:
JSBsim:
Added trimming routine, it is longitudinal & in-air only at this point
Added support for taking wind & weather data from external source
Added support for flaps.
Added independently settable pitch trim
Added alphamin and max to config file, stall modeling and warning to
follow
c172.cfg:
Flaps!
Adjusted Cmo, model should be speed stable now
FG:
Hooked up Christian's weather code, should be using it soon.
Hooked up the trimming routine. Note that the X-15 will not trim.
This is not a model or trimming routine deficiency, just the
nature of the X-15
The trimming routine sets the pitch trim and and throttle at startup.
The throttle is set using Norman's code for the autothrottle so the
autothrottle is on by default. --notrim will turn it off.
Added --vc, --mach, and --notrim switches
(vc is airspeed in knots)
uBody, vBody, and wBody are still supported, last one entered
on the command line counts, i.e. you can set vc or mach or u,v,
and w but any combination will be ignored.
- the panel uses much, much less texture memory, and draws much
faster, at least on my hardware
- there is a wet (magnetic) compass at the top of the panel
- the gyro compass shows true heading again, but don't get used to it:
we're going to set it up to drift soon
- there are TO/FROM flags on NAV1 and NAV2 (but no GS flag yet)
- the ADF looks a little more realistic (if you can forgive the ugly
needle)
- when the HUD is not open, the framerate is moved to the right side
of the screen so that it won't be obscured by the mag compass
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
it's now possible to choose the LaRCsim model at runtime, as in
fgfs --aircraft=c172
or
fgfs --aircraft=uiuc --aircraft-dir=Aircraft-uiuc/Boeing747
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.
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.
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.
Externally: added a chronometer and a control-position indicator a la
MSFS, along with dummies for the radio-nav gauges.
Internally, substantially reworked the code so that the individual gauges
can be table- (and eventually, file-) driven.
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.
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 ...
much less so due to returning the aero reference point stuff to the config
files. Don't know what happened there ...
Additionally, I have added a new field to the config file: CFG_VERSION. A
version number, currently 1.1, is assigned to the config file and a matching
definition is found in FGDefs.h. The two need to match. Tony has also added
code into FGAircraft.cpp to handle if aero reference point is not specified.
I've reorganized the code in panel.cxx and panel.hxx so that it will
be a little easier to extend the panel later if someone wants to.
It's still basically Friedemann's code at the core, but I've
repackaged it into a saner class hierarchy and encapsulated as much as
I could (there are still a couple of circular dependencies that need
swatting). If someone wants to modify it to use SSG or to add new
gauges, it should be a lot easier now.
There are no user-visible changes.
Dave Eberly's spherical interpolation code (found in the Lib/Math
directory). So it would be great if you could give him also a place
in the thanks file. Changing the WeatherDatabse made actually a heavy
internal redesign necessary but no code outside the database is
affected (isn't code hiding great?).
