with different modifiers (the format of the key bindings has changed
again slightly, adding a <code>..</code> element; see keyboard.xml for
details).
2. Modified FGInput to try default modifiers for ctrl, shift, and alt
when the initial bindings fail (i.e. you don't have to specify
mod-shift explicitly for upper-case 'P' any more).
3. Fixed problems with properties and panel reloading reported by
Martin Dressler and John Check.
4. Updated preferences.xml to get rid of obsolete references to
/controls/brakes/left and /controls/brakes/right (as reported by John
Check).
There were also two non-bugs reported by John Check:
(a) Differential braking doesn't work (John was using the obsolete
properties from #4 above).
(b) Duplicates show up in the property tree using the telnet interface
(the property tree doesn't show indices, and John was seeing separate
entries for each possible engine, etc.).
FGOptions is history, and the modules are (starting) to use the property
manager directly. Let me know if I left any files out.
Inevitably, there will be some problems with broken options, etc.,
that I haven't found in my tests, but I'll try to fix them quickly.
We also need to stress that the property names currently in use are
not stable -- we need to reorganize them a bit for clarity.
derive specific viewer classes from it. Here's what I currently have in mind:
FGViewer
|
|-> FGViewerPRH (current system with orientation specified in
| LaRCsim Euler angle convention)
|
|-> FGViewerLookAt Feed in a position, view direction, and up vector
|
|-> FGViewerHPR (similar to PRH, but using ssg hpr euler angle
| convention)
|-> others?
ing features:
a) ADA Flight model - ADA.cxx, ADA.hxx, flight.hxx
b) Fighter a/c HUD - flight.hxx, hud.hxx, hud.cxx, cockpit.cxx, hud_ladr.c
xx, hud_card.cxx
c) 3-window display - options.hxx, options.cxx, viewer.cxx
d) Moving objects (ship) - main.cxx
e) Patches - main.cxx
ADA.cxx, ADA.hxx
--------------------------
Interface to the external ADA flight dynamics package.
flight.hxx
----------
Included prototypes for accepting additional data fron the External flight
model for fighter aircraft HUD
Hud.hxx
-------
Included prototypes for accepting additional data for fighter HUD from Exernal F
light model.
Defined FIGHTER_HUD pre-processor directive to enable compilation of fighter hud
code.
hud.cxx, cockpit.cxx, hud_ladr.cxx, hud_card.cxx
---------------------------------------
Included code to initialise additional reticles/text for fighter HUD which is co
nditionally
compiled if FIGHTER_HUD is defined.
options.hxx
-----------
Added window_offset, and function to retrieve its value for 3 windows
options.cxx
-----------
Changed few options to suit ADA/CEF projection system/screens and checks for win
dow offset.
views.cxx
---------
Added code to retrieve view offset for window.
Main.cxx
--------
Added code to load and move an aircraft carrier.
Patch to enable clouds from command line until Curtis fixes it. By default cloud
s are disabled.
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
I've done some substantial reengineering of the 2D panel: except for the
radios, the whole panel is built from a large table now. I'd be
grateful if you could add these changes to the main distribution.
Since I always like to provide some eye-candy with my updates, I've
fixed the ADF gauge to be more usable by slimming the needle and adding
markings every 45 deg (you'll need to use the attached textures).
- 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
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.
