I have added a --aspect-ratio-multiplier=x.xx option to give some end user
control over the aspect ratio. (This may seem a little strange, but it's a
building block towards the capability of doing asymmetric view frustums in
FlightGear.)
ssgSetNearFar(). This by default creates a symmetric view frustum which is
typically what an application wants.
However, to get control of the view frustum in order to build support for
asymmetric view frustums, we need to wrap these calls with a bit of our own
logic.
This set of changes wraps all calls to ssgSetFOV() and ssgSetNearFar() with
FGRenderer methods.
I also standardized how the FGRenderer class is handled in globals.[ch]xx.
This led to some cascading changes in a variety of source files.
As I was working my way through the changes, I fixed a few warnings along
the way.
I attach the long-promised improved version of the USS Nimitz.
It includes an improved version of the FLOLS, which requires the attached
diff to be applied to AICarrier.cxx and AICArrier.hxx.
I've made lots of eye-candy in the form or the flightdeck crew.
Unfortunately, it about doubles the size of the tarball. I'll send it to you
later; when I've figured out some way of only loading on request (any advice
would be very welcome).
I could provide a \u2018bare\u2019 version to cut down on the vertex count for
less capable systems however, the count isn\u2019t huge in the first place.
I've cut the textures down as far as I can without losing definition.
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.
Yesterday night it occurred to me that the current handling of missing METAR
strings isn't good enough:
- in case of missing METAR strings, don't re-send the last successful string,
but the last successful string sent to *this* client. (If one client is
running in virtual December, it won't be happy about dropped in summer
weather.)
- fix a bug that allowed -vc notation (options -v and -c), but broke a lot of
other notations (-b/var/tmp). Only -v can now be accumulated again, as
in -vvvv.
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 a Perl implementation of a METAR proxy server. Tested on Linux only, but
should work on all Unices, and possibly on Windows, too. Its purpose is to:
- provide METAR data for machines without internet connection
- centralize METAR fetching: one machine in a network runs the proxy, all
other connect to the proxy
- deliver defined and reproducible weather for educational purposes
- save weather situations for later use in fgfs
Quick instructions to download the world weather for the last 3 hours
and run proxy and fgfs with it (~ 2MB download; for less bandwidth
consumption see the --record mode):
$ metarproxy --download 3h
$ metarproxy -v -c &
$ fgfs --proxy=localhost:5509 --time-offset=-2 --enable-real-weather-fetch
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)
