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.
ehofman [Thu, 22 May 2003 08:42:38 +0000 (08:42 +0000)]
from the C++ FAQ:
TITLE: Using delete [] versus delete
The extra "[]" warns the compiler that there is a whole array of objects here so that P's destructor must be called on each element of the array rather than just on P itself (which would be equivalent to the first element only).
ehofman [Sun, 18 May 2003 11:40:57 +0000 (11:40 +0000)]
Latest cosmetic updates to the sunrise code. I still have to figure out why the colors on a PC are much nrighter in some places and much darker in others, but the color itself matches nicely now.
curt [Fri, 16 May 2003 17:27:17 +0000 (17:27 +0000)]
Jim Wilson:
> > Here's a patch to add manual-pitch control to the propeller in YASim. A new
> > control axis "PROPPITCH" is added. Requires "manual-pitch" boolean property
> > in the "propeller" tag.
> >
> > Tags and Properties to add in order to enable:
> >
> > manual-pitch="true"
> >
> > <control-input axis="/controls/engines/engine[0]/propeller-pitch"
> > control="PROPPITCH" src0="0" src1="1" dst0="0.40" dst1="0.80"/>
> >
> > Note that for the time being, excessively low RPM or excessively high RPM is
> > brought undercontrol by a scaling range defined in the control-input tag
> > (see "dst0" and "dst1" properties).