This avoids an issue where the dialog doesn’t update on macOS, if it’s
shown immediately after a native message box, such as the migration
warning dialog.
This was intended to only affect Debug builds, but when using a multi-
config generator (XCode, Visual Studio etc) it affects all builds.
Disabling for now until we figure out a better way to do this.
Testcase for running posinit twice.
posinit sets various properties which it then reads, so there's
a possibility that it could write a value which causes unexpected
behaviour when run later.
Unclear if this should be a unit test or a system test, but it's
simple enough to be a unit test.
Previously /sim/current-view/viewer-[lon|lat]-deg were set to
(0,0) when a view was bind() for the first time by the view
manager. This cause the scenery tile cache to immediately clear
and all scenery to be reloaded.
Now these values are set correctly the first time the view
bind() is called, so the cache behaves correctly.
Also fixed what looks like a possible bug on code read where
the tiles of the current view had a very short expiry time
set. Seems wrong.
Add translation macros for the text of the lock-file warning dialog,
and update the default text after some discussion on the devel list.
Also allow quiting the app, as an alternative option.
Speculative fix for a reposition assert which Huntley is seeing:
https://sourceforge.net/p/flightgear/codetickets/2229/
Unclear why it’s not happening for me other some other folks, but this
should logically be the correct fix. Let’s find out.
Only the in-sim version works for now, the test-suite mode is not
implemented yet. Also the test API will evolve, but should stay close
to what CppUnit defines.
Run a test file by specifying a path to nasal-test : examples will be
added to FGData shortly.
See ticket:
https://sourceforge.net/p/flightgear/codetickets/2133/
Give the user a chance to intervene, if we select read-only mode.
Offer a button to clear the lock file if it’s stale, and start in
read-write mode.
This is still evolving, but want to get some feedback on it.
Fix for: https://sourceforge.net/p/flightgear/codetickets/2059/
When copying addon-config into the main property tree, skip props
which already exist and which are marked ARCHIVE, on the assumption
they came from autosave.xml.
When load a GPX route, run normal departure/arrival airport callbacks
on the delegates. (They are blocked for ‘native’ XML routes to avoid
losing SIDs and STARs)
https://sourceforge.net/p/flightgear/codetickets/2227/
Similar to enable-velocity-vector, but indicates velocity relative to ground,
rather than velocity relative to air. E.g. useful for crosswind landings.
To support FMS which delete ‘past’ waypoints, add some helpers:
- waypoints can be flagged as hidden, this property is exposed to Nasal
- currentWP() accepts an offset parameter, allowing FlightPlan indexing
to treat the current WP as index 0
- a ‘numRemainingWaypoints()’ function on flightPlan in Nasal, again
to range how many waypoints are left, starting from the current WP
Add some basic tests of these new features to the route-manager tests.
Bug report and testing by Jonathan Redpath (see details in issue #276 at GitHub).
The check of FGInterface::get_agl_ft return value has been discarded a few years ago (commit 86b346) on the ground that the method was returning a meaningful altitude above ground level even if it failed.
See mailing lists discussions:
https://sourceforge.net/p/flightgear/mailman/message/32246380/https://sourceforge.net/p/flightgear/mailman/message/32247050/
There is no indication however that the other parameters are populated with meaningful values when FGInterface::get_agl_ft reports an error. The returned `material` pointer is therefore discarded when an error is reported. Ground reactions are still processed in all cases as was decided in 2014.
Took the opportunity to initialize the `material` pointer to null, to avoid yet another problem with unitialized values.
Some members were used before being initialized in FGPiston which could randomly generate invalid floating point values that could propagate to many places in JSBSim.
As a cure to the problem, all variables are now initialized to valid default values in the header (as allowed by C++11). The constructor is only expected to set the members to meaningful values.
