Fixed bug due to longstanding inconsistency in FGAirport
getter functions return types.
Durk Talsma: Fixed traffic record initialization bug that occured
when taxiing traffic was waiting for traffic on runway
I refactored the XML loading code out of FGAirportDynamics and
FGRunwayPreference. I also added a new class XMLLoader, which serves as a
facade to the loader functions. Further I changed FGRunwayPreference to just
keep a FGAirport ref, which is more concise and closer to the right(tm)
solution than storing the airport data a second time ;-)
- Moved AIModels/Traffic Manager related AI functions to a new file
- Rewrote the traffic manager so that the containers use pointers to
objects instead of the objects themselves, which will allow for a
more flexible memory management.
- Rewrote parts of the airport groundnetwork code, also because the
stl containers now contain object pointers instead of the objects
themselves.
- Fixed an uninitialized iterator in the AI distance tracking code
- Fixed flawed logic in some of the traffic controller's while loops
- Added a tower controller, which paces take-off behavior of AITraffic
in a more realistic way.
- Various other minor fixes and fine tuning.
a single apt.dat.gz file which is in the native X-Plane format.
To do this I wrote a front end loader than builds the airport and runway
list. Some of the changes I needed to make had a cascading effect, so there
are minor naming changes scattered throughout the code.
- Removed some old cruft.
- Removed some support for older versions of automake which technically was
correct, but caused the newer automakes to squawk warnings during an
initial sanity check (which isn't done very intelligently.)
NOTE: this fix is technically not correct for older version of automake.
These older version use the variable "INCLUDES" internally and could have
them already set to an important value. That is why we were appending
our values to them. However, newer versions of automake don't set this
value themselves so it is an error to append to a non-existant variable.
We seem to "get away" with overwriting the value on older versions of
automake, but if you have problems, consider upgrading to at least
automake-1.5.
- automake-1.4 sets default values for INCLUDES which we can't
overwrite.
- automake-1.5 renames this to DEFAULT_INCLUDES and leaves INCLUDES
open for the developer to use.
Thus for automake-1.4 we are forced to 'append' to INCLUDES and in
automake-1.5 we can just set the value to whatever we like.
Unfortunately, the behaviors of the two versions are mutually
incompatible.
The solution I am committing now works for both versions but
automake-1.5 generates a lot of spurious warning messages that are
annoying, but not fatal.
from the pre-ssg / render everything ourselves days. Replaced with a
material library manager that is much better suited for working in the
context of ssg. This simplified and cleaned up a ton of old junk.
