I missed a few things in the last patch.
1. prop size did not match prop disc size.
2. rescaled yoke to match measured yoke.
3. messed up hot spots for heading indicator knobs when I tweaked the
panel last patch.
The fix that could not wait was #3, so I also re-textured the pilot head
with outdoor face photos. Yep, that's my face. The hair is now
textured also which looks better close up.
that the --dme option sets the switch position correctly, but the
preferences.xml file is read after that and sets the switch back to 1.
And then we do *correctly* get nav1. Ideally, we would only let
preferences set the switch position if it wasn't set before, but
for now lets just comment that out there.
Here is a patch that included the changes in my 2/22/06 posting plus the
3d-instrument light "emission" animations. I also added a magnetic
compas mount and moved it forward and down to better match the real ac
and make it easier to read when adjusting the hi. Ignore the "?" flaged
files at the beginning. none are required. I noticed that there is a
backup copy of pa24-250.ac in the pa24-250 folder in cvs. It can be
deleted. The only copy of that file required is in pa24-25/Models.
I "flew" a shake down instrument XC from 2v2 (Longmont, CO) to KLVN
(Airlake, just south of Minneapolis, MN). Even the fuel management is
realistic. The autopilot on the menu bar works well. Give the changes
a try and enjoy!
feature I added to the navcom-kx155.xml and the dme.xml in the
Instruments folder. I wanted to leave the frequencies, etc. on these
dark until there was voltage applied to
/systems/electrical/outputs/nav. This was accomplished by adding a
param and property alias pointing to the appropriate value. Since the
c172p "always" applies 28 volts, this made no change in the c172p, but
allowed me to model the avionics master and battery master realisticly
in pa24-electrical.nas. I put in comments explaining this at the change
points.
There is a useful "help > aircraft help" that walks you through the
start procedure and lists the key bindings as well as the key to "light
up" the hot spots.
mode according to the switch position. Now dme.cxx is more generic
and can't make these settings any more -- and doesn't. So the dme
didn't display anything even if the knob was on.
The initialization has now to be done in the dme.xml file.
(Button-less actions are fired at init time and then thrown away.)
The comm radio knobs are screwed. Left half increase, right half decrease.
Fixed that. (I wonder since when this is broken. Does nobody use it?)
To reproduce: $ fgfs --aircraft=c310
The c310's adf needle (HSI) doesn't work. The hsi.xml instrument does
still use the old property. The fix didn't have negative effects on
other a/c that I had tested.
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.
Here are some updates to the KAP140 autopilot in the default c172. It now uses
ailerons and elevator instead of aileron-trim and elevator-trim. I've started
to "upgrade" it to the "two axis altitude preselect" version. Vertical speed
select rounds to nearest 100 fpm.
I've also modified the c172 electrical configuration to turn on the gps
instrument.
Perhaps the most important change is that the nasal script for the KAP140 has
moved from data/Nasal to the c172p aircraft subdir. So it is important that
you delete data/Nasal/kap140.nas. Having the kap140.nas script as a global
script was not a good solution. Now it is aircraft specific, and thus
included in the c172p-set.xml file. Ideally I would like it to be instrument
specific, so that it would be included whenever the KAP140*.xml instruments
where included on the panel.
All necessary elements for an ADF gauge had been migrated from
Cockpit/kr_87.cxx to Instrumentation/adf.cxx. Migrating the sound
related elements was apparently planned, but not done yet. This
intermediate state broke the ident morse sound: it couldn't get
turned off and it always indicated "SF", regardless of the tuned-in
frequency. The following patches continue the migration:
adf-radio.diff => Base/Aircraft/Instruments/adf-radio.xml:
---------------------------------------------------------------
* sets maximum volume to 1 (rather than 2); Not only is 1
loud enough (and 2 unpleasantly noisy), it also prevents
the knob from being turned to non-existant positions. :-)
* fixes wrong use of /instrumentation/adf/ident
* the voice/ident selector(?) remains unchanged, but as it's
not switched to "IDENT", there'll be no ident sound by default
this is consistent with other sounds and DME.
radiostack.diff => src/Cockpit/radiostack.[ch]xx:
---------------------------------------------------------------
* comment out use of FGKR_87 class. kr_87.[ch]xx is now no
longer used. kr-87adf.xml would no longer work, either, but
isn't used anywhere, anyway. Future adf radios have to use
the adf instrument, using xml/Nasal for specific hardware
implementation details.
adf.diff => src/Instrumentation/adf.[ch]xx:
---------------------------------------------------------------
* adds ident morse sound capability using two new input
properties:
- /instrumentation/adf/volume-norm (double)
- /instrumentation/adf/ident-audible (bool)
Here's some new AI stuff.
1) AI objects must now be defined in a scenario file, not in preferences.xml
or a *-set file. (Of course this doesn't prevent objects from being created
dynamically, as with Durk's traffic manager).
2) A new demo_scenario file is attached. It creates 3 aircraft, a sailboat,
and a thunderstorm.
3) Objects without flightplans live forever.
4) FGAIShip::ProcessFlightplan() is not yet implemented.
5) preferences.xml should now define only <enabled> and <scenario>
Here is the KAP140 Two Axis Autopilot update.
I think it's fairly complete now, all the modes are working. I tested the
localizer and glideslope hold and it was pretty stable all the way down to
the middle marker.
In the pilot guide for backcourse hold (REV) mode it says to reset the heading
bug to the _front course_. I haven't figured out how to implement this so for
the time beeing one should reset the heading bug to the _backcourse_. Apart
from this the panel should operate identical to the way the pilot guide
describes.
Here is the KAP140 Two Axis Autopilot.
Aircraft/Instruments/KAP140TwoAxis.xml
Is of course the instrument config file.
Aircraft/Instruments/Textures/KAP140.rgb
The texture.
Nasal/kap140.nas
Most of the work is done here. Without Nasal I don't see how I could implement
the NAV-ARM modes and the flashing annunciators.
Aircraft/c172p/Systems/KAP140.xml
The autopilot PID controllers configuration file. Maybe this file should be in
a more accessible directory and not hidden deep inside c172p!?
I've also attached the changes to the default C172 to include this autopilot
in the 3d-cockpit panel and the 2d vfr panel. Or at least I hope that I've
managed to include all that is needed.
Add clickable range selection for the radar and wxradar. Right
now it is clickable only between 20 and 40 mile ranges, which should work for
most uses.
OV10-jsbsim-set.xml has many changes. It creates a thunderstorm over
woodside VOR. It removes the lowest cloud layer so that the storm can be
seen. It sets the surface wind speed to zero, which may help stop the
"drifting left" complaints. It sets the radar range to 40 miles.
The weather radar instrument is corrected.
The radar instrument uses the above three items, and applies a scale factor to
the x-shift and y-shift in order to match the instrument's scale. Changing
the display scale can be done entirely in the XML code for the instrument.
Right now it's set up only to display a 40 mile scale.
The radar is an AWACS view, which is not very realistic, but it is useful and
demonstrates the technology. With just a little more work I can get a HUD
marker. All I need to do there is make a bank angle adjustment to the
current values.
This works great with one target. For two or more targets the radar
instrument will have to know the numbering of the aircraft model properties.
This isn't implemented yet.
David Culp:
I couldn't stop. Here's a better radar instrument. It has:
1) range select knob 20 and 40 nm (not clickable.. yet)
2) target altitude readout at lower right
3) target disappears when range exceeds 43 nm
4) range ring values now are read from instrumentation/radar/range
5) instrumentation/radar/range is preset in the *-set.xml file to 40 nm
The next step would be a clickable range selection. The problem here is that
the instrument currently displays the "blip" only if the target's range is
less then 43 nm. If the range scale is decreased to 20 nm, then the "blip"
will show past the edges of the instrument. I might need to make another
instrument for the 20 nm scale to make that work.
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.
