We are starting to utilise more and more data from the SU10 provide Nav Data
API for simconnect. We have found (reproducible by multiple team members) that
querying large amounts of data from the service in areas around dense
aerospace areas such as KLAX and EGLL causes the sim to freeze and never
recover. This only happens using the standard MSFS nav data, when Navigraph is
installed the issue doesn’t occur. The tests were carried out with an empty
community folder, except just to vary the install of Navigraph data. Any ideas
on cause or if this was a known issue? It is occurring on both Su12 beta and
SU11 prod release. EDIT: our evidence suggests this started with the release
NZ World Update - we have testers that used the same code with SU12 and SU11
prior to NZ World Update without issue. Which potentially points to an issue
with the latest navdata included in that update - given Navigraph navdata
still has no issue. It is definitely failing on the RequestFacilityData call
at which point the whole MSFS process freezes. The airport being queried at
the freeze is different on each run. 2 simconnect.logs attached showing the
point it freezes - the data being queried is also visible in the
AddToFacilityDefinition calls. **EDIT2: Isolated to FIX_LATITUDE and
FIX_LONGITUDE from APPROACH_LEG Facility Data Type. If these fields are
excluded everything works fine. And its definitely not all legs with a problem
just some. I can see data coming back from many of them - until the freeze
happens.**
It seems to carry on working in the background - even though the sim itself
has frozen. Will try and catch more in a debug step through. Feels like its
load related - i.e. areas with lots of large airports in close proximity.
I have code that can repeatedly freeze the sim to CTD on demand if using MSFS
core nav data - and works fine with navigraph. This code queries navi data for
330 airports and console logs on the facilityDataEnd event counting the number
of fully successful queries… With MSFS core data this freezes the sim after
276 airports - every time - no matter what order they are requested in. This
is with an empty community folder. When I then add navigraph data to the
community folder and retest all 330 airports return data with no issue and no
freeze to CTD. The code is typescript using a simconnect wrapper. But I can
share the pseudo code if that is useful?
So i have more information and completely repeatable:
This is an issue when the field in the facility definition is float64, i can reproduce with any combo or just one of Fix Lat, Fix Lon or Fix Alt. If they aren’t included there is no issue.
It is parallel load related. I can crash the sim on the world map by asking for the data below for 320 different airports in parallel (exactly the limit is hard to determine but 320 will ensure it happens). It crashes at pretty much the same run through point everytime.
You only need to run requestFacilityData - you do not need to actually process the responses to cause the issue.
If I make those calls sequential - i.e. trigger the next airport requestFacilityData call when FacilityDataEnd has been received for the previous airport, there is no issue.
If I make the requestFacilityData call for the same airport 320 times in parallel - there is no issue.
With Navigraph navdata in place all of the above queries work fine.
So this seems to be some kind of data marshalling issue with large data
quantities. As an event / response API, I feel it should be possible to make
these size of queries without issue and most definitely not crash (freeze) the
whole sim and simconnect process. @FlyingRaccoon I don’t think i can really do
any more with this other than present this issue and hope it will be looked
at! My test Facility Definition is
1. handle.addToFacilityDefinition(1, "OPEN AIRPORT"); // Open
2. handle.addToFacilityDefinition(1, "OPEN ARRIVAL"); // Open
3. handle.addToFacilityDefinition(1, "OPEN ENROUTE_TRANSITION"); // Open
4. handle.addToFacilityDefinition(1, "OPEN APPROACH_LEG"); // Open
5. handle.addToFacilityDefinition(1, "FIX_ALTITUDE");
6. handle.addToFacilityDefinition(1, "CLOSE APPROACH_LEG"); // Open
7. handle.addToFacilityDefinition(1, "CLOSE ENROUTE_TRANSITION"); // Open
8.
9.
10. handle.addToFacilityDefinition(1, "OPEN RUNWAY_TRANSITION"); // Open
11. handle.addToFacilityDefinition(1, "OPEN APPROACH_LEG"); // Open
12. handle.addToFacilityDefinition(1, "FIX_ALTITUDE");
13. handle.addToFacilityDefinition(1, "CLOSE APPROACH_LEG"); // Close
14. handle.addToFacilityDefinition(1, "CLOSE RUNWAY_TRANSITION"); // Close
15. handle.addToFacilityDefinition(1, "CLOSE ARRIVAL"); // Close
16.
17.
18. handle.addToFacilityDefinition(1, "OPEN DEPARTURE"); // Open
19. handle.addToFacilityDefinition(1, "OPEN ENROUTE_TRANSITION"); // Open
20. handle.addToFacilityDefinition(1, "FIX_ALTITUDE");
21. handle.addToFacilityDefinition(1, "CLOSE APPROACH_LEG"); // Close
22. handle.addToFacilityDefinition(1, "CLOSE ENROUTE_TRANSITION"); // Close
23.
24.
25. handle.addToFacilityDefinition(1, "OPEN RUNWAY_TRANSITION"); //Open
26. handle.addToFacilityDefinition(1, "OPEN APPROACH_LEG"); // Open
27. handle.addToFacilityDefinition(1, "FIX_ALTITUDE");
28. handle.addToFacilityDefinition(1, "CLOSE APPROACH_LEG"); // Close
29. handle.addToFacilityDefinition(1, "CLOSE RUNWAY_TRANSITION"); // Close
30. handle.addToFacilityDefinition(1, "CLOSE DEPARTURE"); // Close
31. handle.addToFacilityDefinition(1, "CLOSE AIRPORT"); // Close
Hello @whakamolenz We have reproduced the case
where the game freezes and will investigate further. If you can provide us
with a full dump for when it causes a CTD, we are interested. In case the
example above comes from your real code, the 3rd section is missing an “OPEN
APPROACH_LEG” Thank you for your feedback. Regards, Sylvain
Thanks @FlyingRaccoon for confirmation of
reproducing the issue and the flag of the missing open! We are still pretty
sure this only started after NZ world update. I can’t always produce the CTD -
only the freeze - so will come back if I can make it happen again!
Hi @FlyingRaccoon - i saw in the last dev
update that a section of the SDK update indicated something that sounds like
this issue has been fixed. Can you advise at what point that fix will become
available?
Hello @whakamolenz We have a fix candidate but
it needs to be tested before it can make it into an update so no ETA. Keep an
eye on the release notes. Regards, Sylvain