SU3: Navdata Queries don't return anymore

Navigation Data General MSFS Data
1

Hello,

with SU3, some navdata queries no longer return any results, causing avionics to freeze. For example this query never returns a result anymore:

await facilityLoader.getFacility(FacilityType.Intersection, ICAO.value("W", "GO", "", "0010N")

This waypoint only exists in the default dataset, but not in the Navigraph data.

In the Working Title Discord it seems that you are aware of the issue and it was suggested to set all delete flags:

<?xml version="1.0" encoding="utf-8"?>
<FSData version="9.0">
  <DeleteNavigation deleteAllWaypoints="TRUE" deleteAllVORs="TRUE" deleteAllNDBs="TRUE" deleteAllTerminalWaypoints="TRUE" deleteAllTerminalNDBs="TRUE" deleteAllILSs="TRUE" deleteAllApproaches="TRUE" deleteAllDepartures="TRUE" deleteAllArrivals="TRUE" deleteAllFrequencies="TRUE" />
</FSData>

Are you still investigating the issue?

Loading Simbrief into the Citation FMS
2

Hi,
I don’t understand your report, sorry. Point #1 - This flag is set since day one. Point #2 - When this waypoint is not in our database, you can’t find it …

So, what do you mean exactly?

Cheers
Richard

3

The problem is, that the query never returns any result at all, it just gets stuck now in SU3. Therefore no further code get executed and the avionics freeze.

You can find more context on the Working Title Discord in the avionics-framework channel where Malte was investigating the issue. It was first suspected, that it is an issue with the avionics framework, but it was then narrowed down to the Navigraph data.

I did not get 0010N randomly, that waypoint seems to be still in the index of the sim in SU3 now, but fails once the details are queried.

You can reproduce the issue if you just run the getFacility JS code yourself and see that it does not return.

4

As I wrote before our data doesn’t have this waypoint, but you can look at the WorldMap and the EFB without freezing.

Here from the WorldMap search - no waypoint found - no freeze:

image
image1249Ă—1046 46.7 KB

… and here from the EFB - no waypoint found, no freeze:

image
image1920Ă—686 49.9 KB

So, why does the search work in the WorldMap and the EFB but not via the WT Framework? When we don´t have this delete flag, you should expect a result (from the stock data), right? However, there is no result (at least in the WorldMap or the EFB). I’m unsure if WorldMap or EFB uses the same WT framework, but why is there no freeze in WorldMap/EFB?

For me, either the WorldMap or the EFB search uses the “getFacility” JS code—therefore, it is working, and you have no freeze. When you use the “getFacility” JS code and it freezes, it is clear that this is an error in this code piece because it accesses an index that was not rebuilt due to the navdata/or not deleted due to this delete flag.

… but I have tried to enter 0010N in the G1000 (which uses the current WT framework) and no freeze - I get the correct message, that the waypoint is not found:

image
image1601Ă—1112 93.5 KB

In other words, I can´t reproduce any freeze with this waypoint 0010N … AIRAC 2508 rev.2 installed and the latest SU3 installed.

Cheers,
Richard

5

Hi,

What avionics suite are you testing this with?

/ Jack

6

It’s the KLN 90B. It currently hangs during startup while initializing its index.

This is the relevant code in short:

        const results = await facilityLoader.searchByIdentWithIcaoStructs(FacilitySearchType.Intersection, "00", 20);
        console.log(results);

This is the result:

image
image523Ă—358 14.4 KB

You can see, 0010N is somehow still in this list, even though it should not exist anymore with Navigraph.

I then query this waypoint like this:

        const test = await facilityLoader.getFacility(FacilityType.Intersection, ICAO.value("W", "GO", "", "0010N"));
        console.log(test);

I then never get a result.

The offending code is the getFacility call, which requires that you already know the whole ICAO struct, so I assume just searching by the ident in the Garmin units may not trigger this constellation.

You cannot reproduce the issue with the code I supplied? This is my package load order:

image
image716Ă—144 18.1 KB

I also have the AIRAC Cycle 2508 rev.2 installed. This problem started fresh with SU3, it was fine two days ago.

7

Can you please do some tests on WorldMap and EFB? Do you get 0010N, 001CW 0025N, … as a result? We have none of these waypoints in our database - not in the source or the MSFS data.

So I´m curious, can you find these waypoints via WorldMap and/or the EFB too?

Cheers,
Richard

8

The question is not if I can reproduce it with the code or not … the central question is, from where are these waypoints when:

  1. These flags are set (these lines are the original AIRAC 2508 rev.2):
<FSData version="9.0" timestamp="27/07/2025 - 14:32:39 UTC" source="Jeppesen Sanderson, Inc." xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="file:///D:/Simulation/Tools/SDKs/MFS/Tools/bin/bglcomp.xsd">
  <DeleteNavigation deleteAllWaypoints="TRUE" deleteAllVORs="TRUE" deleteAllNDBs="TRUE" deleteAllTerminalWaypoints="TRUE" deleteAllTerminalNDBs="TRUE" deleteAllILSs="TRUE" deleteAllApproaches="TRUE" deleteAllDepartures="TRUE" deleteAllArrivals="TRUE" deleteAllFrequencies="TRUE" />
</FSData>
  1. The loading order (including the package hint) is set correctly
  2. These waypoints don´t exist in our data

I assume any index/cache will not be rebuilt or rebuilt correctly in the background; therefore, you get the waypoint indexes from the stock data, not the installed custom navdata. When the code now looks for the data via the wrong index, it crashes/freezes.

I don´t see any other reason when none of these waypoints exist in the custom navdata.

Cheers
Richard

9

I can confirm, that I cannot find 0010N, 001CW or 0025N in the world map or the EFB. As a test, I can find 5430N from the north Atlantic as expected in the world map, but not in the EFB either.

Yes, you are right, it seems that the stock navdata is still in the index, even though the waypoints are deleted. I was hoping you just needed to add a delete flag and the issue would be solved. I did not expect that the issue would be this deep. Maybe it is a sim issue all along, that started with SU3?

10

We are working directly with the WT guys to investigate this issue. We can fix it (but we must know what happened here :wink:).

Please be patient… I will keep this topic open and will update as soon as there is a light at the end of this black hole :+1:

Thank you
Richard

1 Like