ehofman [Fri, 27 Jun 2003 08:46:57 +0000 (08:46 +0000)]
Melchior FRANZ:
These patches add a clock instrument, which allows to model failure ("serviceable") and to adjust the time independently of the system time (defaults to GMT). The main incentive is to make the p51d clock work and adjustable via the knob.
o Offers a time string ("12:03:15") for the LCD or for LED
clocks, or an empty string in case of failure/power off. The
instrument assumes that digital clocks are battery buffered,
so they will be updated even if there's nothing on the display.
o Offers the number of seconds since midnight for analog
clocks, like in the p51d. This number is not increased
if !serviceable. So the clock will stand still and continue
where it stopped when it's serviceable again.
I did not consider voltage yet, because the Mustang's clock will need a lot more current than the LCD clock. The instrument is updated 4 times per second but returns immediately if neither time nor offset changed. The function getGMTString() in fg_props.cxx could be removed after applying these patches.
curt [Wed, 25 Jun 2003 18:10:10 +0000 (18:10 +0000)]
Many ILS approaches do not have a listed GS elevation in the FAA or in the
DAFIFT data base. Use the field elevation as a reasonable approximation
when no other data is available.
curt [Tue, 24 Jun 2003 20:04:29 +0000 (20:04 +0000)]
Previously the weather dialog box and environment system had some confusion
between temperature at altitude vs. temperature at sea level. The dialog
box asked for temperature at altitude which makes sense, but all the
internal crunching expected temperature at sea level. However, it makes no
logical sense to specify the sea level temperature for different layers so
I changed the internal processing to work with temperature at altitude and
then derive an approximate sea level temperature at the end.
If you know the ground temperature, you can just enter this temperature
for the first boundary layer and the system should do the right thing.
daveluff [Wed, 11 Jun 2003 21:49:46 +0000 (21:49 +0000)]
Initial stab at making the AI plane take the user into account when flying a circuit. The AI plane will now delay it's turns to the various legs if the user has flown a wider pattern that it normally would in front of it. However, this is very much still work in progress - when the pattern gets extended the AI plane lands short of the runway, and it doesn't alter its speed around the circuit at all, only the turn positions. Still, its a start...
david [Sun, 8 Jun 2003 14:47:03 +0000 (14:47 +0000)]
Removed FGEnvironmentMgr as a special case in globals, initialization,
etc.
Improved the weather system to interpolate between different
elevations and deal with boundary-layer conditions. The configuration
properties are now different (see $FG_ROOT/preferences.xml).
ehofman [Sun, 8 Jun 2003 08:45:07 +0000 (08:45 +0000)]
Fix a problem where the contents could be specified by JSBSim and by FlightGear, where JSBSim would override the FlightGear specified value. Now the JSBSim specified value will be discarded if Contents is already set.
ehofman [Sun, 8 Jun 2003 08:44:30 +0000 (08:44 +0000)]
David Culp:
This version handles a zero fuel load better. I found that if you try to consume fuel from an empty tank, with zero fuel flow, the FGEngine::Starved flag alternates
ehofman [Tue, 3 Jun 2003 14:34:02 +0000 (14:34 +0000)]
Fix a bug where FlightGear would crach when an aiport id was geven in lower
case. It turned out that MetaKit is case insensitive, so I adden an extra
check to see if we got what we were asking for.
curt [Mon, 2 Jun 2003 16:35:36 +0000 (16:35 +0000)]
Implimented a simple frame rate throttle.
Normally for smoothest frame rates you would configure to sync
to your monitor's vertical refresh signal. This is card/platform
dependent ... for instance with Linux/Nvidia there is
an environment variable you can set to enable this feature.
However, if your monitor is refreshing at 60hz and you can't quite sustain
that with flightgear, you can get smoother frame rates by artificially
throttling yourself to 30hz. Note that once you are about about 24fps, it
is *change* or inconsistancy in frame rate that leads to percieved jerkiness.
You want to do whole divisors of your monitor refresh rate, so if your
display is syncing at 75 hz, you might want to try throttling to 25 hz.
curt [Tue, 27 May 2003 19:25:27 +0000 (19:25 +0000)]
- Added a redundant (left/right) vacuum pump.
- Modified the rpm vs. suction formula to hit much more realistic numbers.
We should be seeing just over 4 inhg at idle and approaching 5 inhg at
full throttle.
curt [Tue, 27 May 2003 19:18:14 +0000 (19:18 +0000)]
Added very simplistic volt and amp modeling to the electrical model. This
should really be made more generic and part of the electrical model config
but this is all I had time for this weekend.
curt [Tue, 27 May 2003 19:15:58 +0000 (19:15 +0000)]
Added some test code (currently commented out) to limit a remote visual
slave to a specific frame rate (i.e. 30hz). This is potentially desireable
if you are running on the ragged edge between 30/60 hz ...
It would be nice at some point to make the code a bit more flexible and
configurable so it could be activated from the command line or preferences
file.
curt [Tue, 27 May 2003 19:13:51 +0000 (19:13 +0000)]
Make the attitude indicator gyro error kick in earlier in the gyro spin down
process.
Add the annunciator model to the list of managed instrumentation modules.
curt [Tue, 27 May 2003 19:12:33 +0000 (19:12 +0000)]
Add a very simplistic (small single engine type) annunciator model. With
the exception of flashing the annunciator light for 10 seconds and then going
steady on, this could almost be done entirely in an xml instrument ...
curt [Tue, 27 May 2003 18:59:14 +0000 (18:59 +0000)]
Add a utility that given a specific localizer position and corresponding
runway info, repositions the localizer and realigns it with the runway
heading so that the approach lines up perfectly.
curt [Tue, 27 May 2003 18:57:40 +0000 (18:57 +0000)]
This script should be moved because it really isn't dafift specific. It
builds the ILS database from several sources and uses an external compiled
utility to crunch the math to straighten out the approaches whenever we can
match them to specific runway headings and threshold locations. This should
be *always* but our runway data is horribly outdated so that needs to be
updated soon to get into sync.
curt [Thu, 22 May 2003 19:05:16 +0000 (19:05 +0000)]
This is a little something I'm dabbling with ... an alternate approach
to doing random ground cover objects. This is still in it's embrionic
state so don't expect this to do anything useful or interesting yet.
It shouldn't hurt anything though either.