Although the reverse lookup of a model is correct, it's aircraft ICAO code is wrong
Issues found
* in the driver the ICAO code is permanently overridden -> commented out
* there are two contexts, own aircraft and simulator, but only one uses reverse lookup -> now both
* using Qt::QueuedConnection for context -> GUI
- Use common function for Session and P2P connections
- Don't use the DBus service watcher as it did not allow to test in regular intervals
- Add a XSwiftBus version check to X-Plane listener
- Try to initialize and acquire multiplayer planes in checkConnection() already and warn the user if any of those failed. The plugin will be loaded only if everything succeeded.
* force full updates for some cycles "m_updateAllRemoteAircraftCycles"
* only use "emitSimulatorCombinedStatus" to emit changed simulator status
* renamed to "finishUpdateRemoteAircraftAndSetStatistics"
* override "forced" in "getInterpolationSetupConsolidated"
This addresses the issue that aircraft appear below ground after moving the aircraft
X-Plane returns com frequencies in 10 kHz, so we don't have the necessary
precision for the 25 kHz spacing. By using CComSystem::setFrequencyActive
we get the rounding to the system wide spacing for free.
Without that correction we run into system wide issues in code that assumes
the correct frequency spacing is in place.
ref T399
* view rows not selectable
* added settings to ISimulator
* ISimulator implements initSimulatorInternals() and sets default values
* also display plugin name
* XPlane using initSimulatorInternals()
* the most accurate value seems to be returned if the height is close to the elevation
* in normal scenarios there is no much difference of the results if 0 is used
* in Lukla (9200ft MSL) the difference between 0 and 9200 is around 1ft
* in the LOWW scenario using 50000ft MSL results in around 3ft too low elevation
* typo getRemoteAircraftsData -> getRemoteAircraftData (no "s")
* typo getEelevationAtPosition (double "Ee")
* get functions "const"
* added unit for some variables such as latitudeDeg
* 2 queues, one for pending "to be added" aircraft and one for "adding in progress" (easier timeout detection)
* disconnect DBus when unloading
* check if aircraft "are still in range" before adding
* adding to XPlane only in one place
* data for aircraft can be explicitly request and are requested directly when an aircraft has been added
Rational: Except for FS9 we interpolate all aircraft in one loop at the same time. This can cause that some steps are always done at the same time for all aircraft of that loop. By passing the number we can more equally distribute such tasks, avoiding peaks.
* connect with "about to quit"
* added interface declarations
* sim statistics, use common function setStatsRemoteAircraftUpdate and double for average values
Instead of requesting it individually for each callsign and waiting for a
signal from xswiftbus, pass in a list of callsigns and use async callback
to read the data.
* return interpolation results parts/situation in one step
* base class init for each interpolation step, less redundant code
* removed old interpolation/parts function
* adjusted unit tests and simulator objects (such as SimObject)
* split functions, added findClosestElevationWithinRangeOrRequest
* obtain elevation ids (separate ids are easier to track)
* also added experimental "physicallyAddAITerrainProbe" (FSX) for the FSX elevation probing
* callback / signal when requested elevation is received (async)
Previously all own aircraft values were request via single DBus calls.
Since DBus allows up to 8 values in its reply, use this mechanism
to group the requests and reduce the amount of single calls.
