MP aircraft are loaded by a separate OSG thread (introduced after FG2.4.0).
The OSG thread also calls the "modelLoaded" callback. However, we mustn't
allow the OSG thread to call FGNasalModelData::modelLoaded directly:
FGNasalModelData isn't thread-safe. There are obvious issues (_callCount++;),
tricky issues like calling the Nasal _parser_ or creating hashes and
modifying the global Nasal namespace. It doesn't use locks to protect
against another thread executing a Nasal context or running garbage
collection. It also executes Nasal code itself (the model's "load" hook),
which we also cannot allow in a separate thread...
This patch returns all Nasal parts of MP-aircraft loading (parsing,
module creation, execution) to the main thread, while keeping the
multi-threaded OSG part (loading of MP-aircraft model files itself).
The same issue exists with scenery models (see other commit).
To summarize with 2 words: It s*cks... ;-)
are the accelerations (forces) as felt from the pilot's perspective. This
combines the accelerations due to change in velocity vector and gravity.
Previosly the gravity part was right, but the body accelerations were being
transformed incorrectly. The error was very subtle and basically amounted to
the fact that inverting an axis of a vector before transforming it is not
equivalent to transforming the vector and then inverting that axis.
After this fix, pilot accelerations + gyro + gps can be fed into an external
kalman filter and it will converge properly (extra confirmation that there
was a problem and this fix corrects it.)
* Pregenerating taxiroutes could interfere with runway assignments by ATC, when conditions changed, resulting in a taxi to one runway and a takeoff from another
* A simpler solution for the "Error in Traffic record bug". This still needs some more testing, but I haven't seen any error message anymore, since changing to the current code.
* Initialize AI traffic at speed zero, this should prevent some weirdness observed under boundary conditions.
* Don't activate groundnetwork proximity detection for pushback traffic until the "ready for startup message is transmitted. this should allow sufficient time for them to reserve a route, but a little more testing still needs to be done.
