It seems that some aircraft sometimes incorrectly pass view indices rather
than numbers resulting in out-of-range access to FGViewMgr::views[]; See
flightgear-devel thread with subject "View crash (after loading errors)".
With this commit, if we are given an incorrect view number, we output a
diagnostic with SG_ALERT, assert fail, and cope with the problem. Arguably we
could do something more serious such as opening a popup or throw an exception.
We now attach global event handler to extra view windows so key presses are
handled as normal.
And the main event handler for mouse movements now calls new SviewMouseMotion()
which pans/tilts extra view windows in response to right-button mouse-drag.
Check for NaNs after each FDM iteration, and freeze the sim if found.
Report this condition to the user and to the reporting backend, along
with the last valid position.
Probably needs some refinement, this is just a first guess.
Sentry-Id: FLIGHTGEAR-AM
- Instantiate an HTTPSConnection object when the URL scheme is 'https'.
- Clarify and simplify the initialization of HTTPSocketRequest and
HTTPDownloadRequest:
+ clarify initialization of their 'callback' attribute (it's the
method of the same name; make it clear that the base class
constructor, namely HTTPGetCallback.__init__(), doesn't modify the
'callback' attribute when an object of class HTTPSocketRequest or
HTTPDownloadRequest is initialized);
+ HTTPDownloadRequest doesn't need access to the TerraSync object
-> remove the corresponding instance attribute and constructor
argument.
- Don't use super() when initializing HTTPDownloadRequest objects
(see [1]).
[1] https://fuhm.net/super-harmful/
When in LEG mode, and within the intercept cone, but further away from
the leg waypoint than the leg origin, we were computing a bogus
abeam point and hence a bogus desired track.
Detect this situation, and invert the computed along-track-distance,
so the computed abeam point is actually near where we are, and not ahead
of us.
- exclude POIs and some other types from the ident match, to avoid
confusing results
- improve how the search vicinity is computed when inserting a leg,
which is the common case for a route with a destination set. Use
the midpoint of the leg ending at the insert position, as the optimal
search vicinity
- move the waypointFromString code into route.cxx, since it is mostly
independent of a FlightPlan instance
- extend the tests to cover the bug which flagged these issues
Ticket-Id: https://sourceforge.net/p/flightgear/codetickets/2372/
