I just heard from John Wojnaroski that you and he are going to work on getting
a flightgear demo machine up for the linux expo thursday and Friday. John
indicated that he would very much like to get a CVS version with the new
traffic code up and running before the expo.
I've added some features to the PID controller:
Ability to set desired sampling interval in seconds. Use <Ts> under <config>
to set the desired sampling interval of the PID controller.
Example:
<config>
<Ts>0.1</Ts> <!-- desired sampling interval -->
<Kp>-0.05</Kp> <!-- proportional gain -->
<beta>1.0</beta> <!-- input value weighing factor -->
...
...
</config>
Ts defaults to 0.0, so if you don't set it it samples at the highest possible
frequency.
Add an offset to the input variables (input and reference).
Example:
<reference>
<prop>/controls/flight/elevator</prop>
<scale>-1.5</scale>
<offset>1.0</offset>
</reference>
Note that <scale> has higher precedence than <offset>, regardless of the order
that they appear in the config file.
I have made the
'Select Airport from List' option in FlightGear work
(I think) properly. I have some concerns about the
solution, which could be broken by changes to plib (if
they re-use the value I have assigned to
PUCLASS_LIST), but for the moment it seems to work OK.
Erik Hofman:
A request has been sent to John Fay to include the puList
code in the puAux subdirectory of plib so expect some
changes for future version of FlightGear.
RE: --aircraft=ufo in system.fgfsrc is ignored
To change a 'feature', one that has been mentioned here many
times, and again recently, place the following code block
into fgInitFGAircraft.
In its favour, I would argue this means FG can be run without
a command line, provided FG_ROOT has been set in the
environment, and that seems to me, as it should be ... ;=))
Perhaps the only counter, is that system.fgfsrc is read twice,
but so are others, like .fgfsrc, for other (local) options ...
or system.fgfsrc should .nt. be used for 'aircraft' ?
Here's again one of the more obscure bugs that valgrind complains about: somehow
the STL container classes manage to read out values before they were ever set.
This patch fixes that. This may not cause any harm in this case, but valgrind
seems to *always* be right about them.
The following patches to SimGear & FlightGear ...
- create an FGMetar abstraction layer, whose purpose is:
* provide defaults for unset values
* interpolate/randomize data (GREATER_THAN)
* derive additional values (time, age, snow cover)
* consider minimum identifier (CAVOK, mil. color codes)
- add rain/hail/snow/snowcover support on the METAR side
- add max age of METAR data handling (currently set to
- add support for an external METAR cache proxy server
- add CAVOK handling
- set missing year/month in regular METAR messages
- fix a small bug in metar.cxx (wrong return value)
rather than /instrumentation/comm ... we need to be a little careful here
because typically, a single knob controls power to both matched com/nav pairs.
explicit calls to shutdown_all() which was causing this to be called twice.
This could cause problems with some IO modules (such as attempting to close
an invalid file descriptor the second time.)
a seperate explicite call or the io channels will be forced to try to shutdown
twice which could cause problems for some IO modules (i.e. attempting to
close an invalid file descriptor the second time ...)
We should now be able to find
wires or catapults when the ac3d model is loaded without the crease patch
(caused by the much more unstructured scene graph emitted by the old loader).
It should also emit more warnings if the carrier hardware configuration
includes conflicting definitions.
That code is the most intrusive one, it should not be used until you configure
an aircraft carrier as a aimodel. So I think it should be save to apply that
before the release too.
Attached is a patched runways.cxx. This fixes the find runway nearest to a given heading code. This was returning the last runway loaded at a given airport, not the nearest runway to the heading requested (which seems to always be 270deg by default). I have no idea how this has survived unnoticed for so long - I think it might be because you need to start at an airport with a runway near to 27 and one much greater than 27 eg. 36 to really tickle it, otherwise the runway nearest to 27 tends to be the final one loaded anyway. Try starting at KARR with and without the patch and note the surface wind. This should go in before the release.
