I spent the whole day figuring out what is going wrong, narrowing down affected BGLs and decompiling, changing and recompiling them and in the end I think I found out what in the navdata is causing the freeze.
From my analysis it is caused by defining a waypoint with the same ident/region combination as a localizer/ILS station.
E.g. in the file navigraph-navdata\scenery\0306\ATX28490.bgl there is the following waypoint:
There is no “EC” VOR, but this waypoint sits on the location of the localizer and has the same ident as the localizer.
With this the G1000 freezes as soon as you dial EC. Change the ident or region in this entry in the BGL and it no longer freezes on EC.
I could reproduce this behaviour with uninstalled Navigraph and my own little navdata addon (unzip to Community folder to try it out). mycompany-navdata.zip (13.3 KB)
This is just the compiled sample navdata projekt from the SDK but with only a single entry:
With this addon (and Navigraph uninstalled!) the G1000 works without freezing UNLESS you try to enter “IMOW”, then it freezes. I think it does not matter were on the world you are located (EC is in South America and caused freezes when entering EC from a position in Germany).
Are those waypoint entries on Localizers/ILS needed for any reason? If not (or they have a real world reason but won’t be useful in MSFS anyway) could they be removed from the navdata?
Thanks,
Jan
EDIT: For clarification, IMOW from my addon is also a localizer at EDDG.
Hi Jan,
first of all, thank you very, very much for this report and your time to figure out what´s going wrong here.
Let me clarify a few things first.
EC isn´t a VOR right, but there is no other possibility in the sim to define these ILS/DME waypoint
EC is not located at the localizer position, it´s located at the glideslope antenna
EC is a ILS/DME navaid and this will sometimes also use in terminal procedures - therefore important but
… since revision 2, we use a new technics, so it could be possible, that we don´t really use this type of waypoints anymore. I´m not sure, if the sim uses this waypoint for the DME information or the glideslope-position from the ILS this should we test.
But all in all Jan, a very good observation - a big thank you for this/your effort … I will make a few tests and possible we will remove it in the next revision, if we don´t see any issues.
Cheers,
Richard
PS: and by the way, the freeze happens also, when you try to enter an airport-icao code and these codes are really unique. So, I´m not really sure, if this is really the only reason … personally, I guess it´s more a search-issue in the G1000 which cause this issue but I can´t really verify it and so, it´s only an assumption from my side and we are still looking on our side
Maybe we are talking about different things but I don’t think the sim uses the <Waypoint> entries for any setup of “physical” navaids. It should use the DME information from a <Dme> inside either a <Vor> or a <Ils> and the glideslope position from the <GlideSlope> inside a <Ils>.
I’m just wondering what those waypoints on the glideslopeantenna/localizer are supposed to be used for, as I cannot find them on charts or as points used in procedures.
Though I don’t have any raw view on the data, I’m using Little Navmap (configured to use Navigraph directly) for lookup.
Staying with the example of “EC”, I cannot find it as a waypoint (of any type VOR, Named, Unnamed, …) or as part of any procedure.
The only place I could see it mentioned in a procedure (for airport SAWC) was as a “Remark”, e.g on ILS
-Z 25: Inital fix ISAXO “Remark: Related EC / 12,0nm / 72°M”
If that’s really the only usecase I don’t think those waypoints have any usage inside the simulator data that MSFS would use.
Do you have an example for that? Usually it freezes well before it reaches the final 4th char of the airport code, but for example I can dial in KJFK just fine without any freeze. And I changed the waypoint ident in my example addon to EDDG and still no freeze on EDDG, so that issue with the waypoint really seems to be isolated to waypoint idents being the same as a localizer/ILS ident.
No, no we are speaking from the same here and I agree with you but due the fact that there are so many “strange” things inside the side, I don´t expect anything.
Such waypoints will be directly used but will be used as an example as recommanded navaids in the procedure to “create/calculate” unnamed waypoints like CIxx, CFxx, … I have looked into the SAWC procedures and exactly this waypoint will be used in several leg-types as recommand navaid, with a theta, rho and magnetic course.So believe me, such waypoints are important but again, I´m not sure if they are “so” important, that they should find the way in the waypoints
Here an example of the SAWC ILS25-X approach, where you can see the EC ILS/DME waypoint. This waypoint is located at the glideslope, all other things wouldn´t make sense:
Doesn’t this Dx.x EC just mean “distance to the DME of the ILS”, which should be the <Dme> entry on the EC<Ils>? I don’t see a dedicated EC waypoint in that chart example.
In addition to this, even if the waypoint is needed as recommendedIdent reference in a procedure <Leg> I think there are 2 possible fixes:
Can another recommendedType be used? Beside WAYPOINT this also supports, among others, RUNWAY, LOCALIZER and VOR. Maybe LOCALIZER is the right one. Then you could reference the ILS and would not need a dedicated <Waypoint> entry.
If it has to be recommendedType=WAYPOINT, does it have to be waypointType="VOR" in the waypoint? If you use waypointType="UNNAMED" this also seems to solve the freeze issue in a few tests I made.
Hi Jan,
I guess, I have found a way … give me a little bit more time for testing please, but thanks your input (indeed, great!!! input), I have it now …
Will come back a little bit later … thanks again for your effort and of course for your help
Richard
Jan, revision 3 is ready for the release now and we will release it in the next hour.
Thanks of your testing and work, we had figured out a possible issue which cause into freezing the G1000. I would say thank you to your effort of your work and to this great communication here.
Thats exactly we love here in our community, everyone helps everyone and also we learn so much from you, from our customer in such situations. A big thank you again for this loyalty, for this support and for all the time, what you have spend to identify a problem.
