When AIFlightPlanCreateTaxi() function is called with the firstFlight
argument set to true, this is supposed to handle situations where the
the aircraft's timetable indicates it should have left between about 5 to
20 minutes earlier. In the previous version, all these aircraft started
taxiing from the first parking location available in the network, due
to the fact that the variable gateId was not assigned a value. In this
patch, route tracing starts from an assigned gate and the network node
following code is fast forwarded to a random location along the taxiways
to give a more realistic and natural distribution of taxiing aircraft
after startup.
This patch further addresses some weird ballet-dancing behavior that
aircraft were showing just prior to/right after parking and which was
related to a number of more or less duplicate waypoints in the transition
from createTaxi() to createParking() to createPushBack() to createTaxi().
Finally, a blatant typing error in the getParking() function was fixed.
at (lon, lat) coordinates -1000,0. This patch fixes the AIModels/Traffic
Manager side of things. The AIModels subsystems allowed the creation of
AIAircraft with non-existent 3D models. If such a model didn't exist, the
aip class didn't get initialized, resulting in the above-mentioned bogus
position information. Here I circumvent this problem by a) only interacting
with the tile loader if the model is visible (and hence has succesfully been
initialized) and b) by disallowing the traffic manager to create AIAircraft
objects if the path to the 3D model doesn't exist.
bunch of memory leaks that had accumulated over the years. FlightGear
doesn't currently bother to destroy and recreate a YASim context, but
at least it can do so now without worry.
groundcache addition -- the ground callback doesn't do anything at
solution time, so the ground plane was unset. Valgrind was whining
about this; it's not clear that it was actually causing a problem.
a race condition ending in warping twice and having huge increments for the
second warp.
I am not aware of such a flush function in glut. So we emulate that by
ignoring mouse move events between a warp mouse and the next frame.
That should make glut behavour aequivalent to sdl behavour.
