I made a minor change to one file in the c172p that accommodates a
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.
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.
I made a minor change to one file in the c172p that accommodates a
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.)
Limit the maximum time we spent in the simulation loops.
That means, if the /sim/max-simtime-per-frame value is strictly positive
you can limit the maximum amount of time you will do simulations for
one frame to display. The cpu time spent in simulations code is roughtly
at least O(real_delta_time_sec). If this is (due to running debug
builds or valgrind or something different blowing up execution times)
larger than the real time you will no more get any response
from flightgear. This limits that effect. Just set to property from
your .fgfsrc or commandline ...
I have modeled N7764P, the comanche 250 I co-own with 2 other Seagate engineers.
In the process of doing this model, I have also improved, worked on, or added
instruments, etc. to Instruments-3d.
* I fixed the adf so the azimuth card is tied to the correct property
* Added TO, From, and out-of range indicators to the 3d vor.
* Also added a manifold pressure gage and a pa24-250 asi (using digital photos
of the actual asi as the starting textures.
Affects on other AC. As far as I know, this will add to-from to the vor and
correct the adf behavior for pa28-161. It would be a trivial edit to the
pa28-161.xml to give the same vor performance to that AC.
Now both VORs act as one.
