saving for beacons, but since they're surprisingly few (in nav.dat), not a
an enormous saving in real terms. The major motivation is that marker beacons
don't behave like other NavRecords for radio interaction - they have no ident,
frequency or range (in the sense that NavRecord means them).
This makes taxiways smaller (important since at present there are so many).
Restructure the apt.dat parsing code to use a helper class instead of one long
function, and to do less work when parsing the file.
Some of these ideas come from Yon Uriarte's patches - thanks Yon.
This was lost when I stopped cloning the near camera to make the far
camera. The result was a lot of breakage, including explicit camera
configurations not working and various ordering issues too.
This seems to be accepted OSG usage for slave cameras. It's possible
that this order is important for rendering instruments that use RTT
textures on systems without frame buffer object support. I'm thinking
that the resulting bugs may be implicated in the "black rectangle" problem.
The near/far boundary, called "near-field", can be set to 0 which
disables the far camera and renders the whole scene using only one
camera. I'm hoping that this may be useful in resolving some
system-specific rendering bugs.
Various fixes were made to correctly render the scene using only the
near camera.
airportList search function. At least for me (with a mutex-based SGAtomic),
large vectors of referenced-pointers is a Bad Thing - copying on vector
resize is thrashing the locks.
static FGAirport helpers. As a result, another global index goes away. Use
the helpers to avoid ugly FGPositioned down-casts in various places.
Also converts the environment/METAR code to deal with FGAirport pointers,
instead of string identifiers, and contains work-in-progress code to implement
the AirportList dialog using FGPositioned. This isn't enabled yet for various
reasons, but is the final piece to allow FGAirportList to be removed.
gone. This is good news, since the old query was implemented as a linear
search, sorted by Manhattan distance, and with a warning not to use the logic
at runtime. Various systems (such as the Mk-VIII) do query such data often,
eg every second.
Also gets Point3D out of Airports/simple.hxx, as a precursor to removing it
completely.
by frequency (which makes sense), and use the FGPositioned spatial data if
required. As a result, the marker beacon list is gone (since beacons are only
searched spatially). In the process, clean up various minor things - most
notably, all the 'airport-related' navaids (ILS, GS, LOC, and the beacons) now
store a FGRunway* instead of an airport id string. This is more precise, and
saves string allocations.
const) which were previously tricky but now easy. Make it possible not to
index certain types (used for taxiways) and exclude anonymous items from
the name index. Related to this, clean up FGRunway further - remove some public
members, and fix a dumb bug of mine, where we create reciprocal entries for
taxiways.
This should make startup (slightly) quicker, and shrinks FGRunway somewhat.
Add a helper predicate to FGAirport to encapsulate the common 'does this
airport have a suitable runway of at least xxxx ft?' query. Also add a
FGPositioned filter built on the predicate, and a 'closest airport' helper.
"I've managed to fix this by differentiating rebuilding the 3D layers
(e.g. due to METAR updates) from rebuilding the entire environment (due to a
change in scenario)."
dirs is only fast enough with hot file-cache, but a bit too painful
otherwise. Updating the aircraft.list is now easier, though: Just
type $ fgfs --aircraft=?<TAB>
reverts one of my changes which ensured that the 3D clouds were updated with
METAR. Unfortunately this had the side-effect of over-writing the environment
properties, and therefore nuking the interpolation work.
