Closed colingeniet closed 4 years ago
After more tests, the issue triggered by many other flightplan related events.
The fastest/most reliable I found is to cycle runways with the L
button on the TI.
Culprit is in Nasal/flightplan.nas
, line 890:
setlistener("autopilot/route-manager/current-wp", func {Polygon._wpChanged()});
It doesn't look like much, but
_wpChanged
can call land.L
, which can activate a flightplancurrent-wp
is manipulated a lot by the c++ route manager code, and can among other things be modified during a call to Flightplan::activate
Result is a re-entering call of Flightplan::activate
, and more specifically a re-entering call of Flightplan::unlockDelegates
, which messes up the code tasked with keeping track of waypoint modifications, and triggered the assertion failure.
I think the most reasonable fix is to break the recursion with an ugly timer.
Weird stuff happens when adding a timer. I don't understand the interactions of _wpChanged
with the rest of flightplan.nas
, in particular with activateLandingBase
.
Fixed by https://github.com/NikolaiVChr/flightgear-saab-ja-37-viggen/commit/1180dd85500d9e59731561754a6bff3ab69425c7 for recent flightgear versions. It requires the following FG commit to work properly (FG 2020+): https://sourceforge.net/p/flightgear/flightgear/ci/45df8f51b2fdc2b2da53f778f633b9915792ebe6/
For earlier FG versions, some automation functionality are lost (e.g. automatic selection of RTB plan at the end of mission plan), but at least it does not crash (tested with 2018.3.6, current stable version).
FG crashes with
steps to reproduce:
versions: