I've fixed a bug in FGRunways::search(aptid, tgt_hdg) which wasn't working properly for airports with multiple parallel runways. I've also firmed up and pulled out into it's own function the GetReverseRunwayNo code, and done some input checking.
As a result of fixing the above in runways.cxx, I've pulled out the
parallel implementation in the functions that set position by airport and
heading/runway number in fg_init.cxx and called the runways functions
instead.
ttStandard is copied from ttBerndt, with the following modifications:
1. All turbulence is diminished within three wingspans of the ground.
2. The horizontal forces are used to calculate the moments, but then
zeroed out so that only the vertical force is actually applied to
the aircraft.
3. The yaw moment is not used.
In fact, the horizontal forces and the yaw moment should be allowed,
but they are extremely rare compared to the vertical force and the
pitch/roll moments. For now, simply zeroing them gives the most
accurate feel.
The "switch" layer type now takes any number of child layers, and will
use the first child that has a condition that evaluates to 'true' (no
condition is automatically true). Previously, it could take only two
children, controlled by a boolean property.
for a little while, since it uses different properties. There are
some improvements, especially with searching and range. It also has
its own serviceable and in-range properties, independent of any
coupled VOR.
// search for the specified apt id and runway no
bool FGRunways::search( const string& aptid, const string& rwyno, FGRunway*
r )
there was a bug, in that each runway corresponds to *two* runway numbers
(eg 01/19, 10L/28R) but the function was only checking one. I've modified
it to check the supplied number against both possible numbers for each
runway.
Secondly, I sent in the function:
// Return the runway closest to a given heading
bool FGRunways::search( const string& aptid, const int tgt_hdg,
FGRunway* runway )
a year or two ago now when I first did the ATIS. I'm not sure what I was
doing at the time (copied most of it out of fg_init.cxx) but I don't think
it's ever worked, so here's a brutal modification that does!
FGExternalPipe is destructed.) This leaves the name pipe hanging around
even after flightgear exits, but assuming we put the files in /tmp that
shouldn't be a big deal.
ExternalNet interface:
- allows a much more closely coupled execution. A remote network FDM will run
at it's own rate, and maybe a particular data packets will come, maybe it
won't. This makes it very hard to control timing and keep the animation
smooth. There are also cpu scheduling issues with running multiple
processes on a single machine. The linux scheduler by default runs at
100hz. If an FDM process uses a sleep/alarm system to avoid wasting
CPU, it will be forced to run at 100hz, 50hz, 25hz, 20hz, etc. This
makes it *impossible* to serve a display system running at 60hz without
dropping frames.
- the downside is that the FDM process must now run on the same machine as
the master flightgear process.
