If I had more time, I’d look into contacting the FAA or the National Archives and see if there’s a historic A/FD or even an old database of navaids. I’d bet money there is.
But I don’t have time right now.
If this project gathers steam and I do free up some time, I’d be willing to share info from the 90’s-era A/FDs, sectionals, and terps charts I have.
The only problem that would remain should we integrate the FSX navaids into MSFS are the procedures. Flying radio arrivals is half the fun of a /A flight. FSX already contains some procedures for many airfields in its databse (for example NDB approach to EPKK that’s long gone in our timeline) so would it be possible to import it too?
Please do not forget the runway approach Markers. Outer/Mid/Inner. These are fast disappearing as well.
Last time I checked, I think there were less runways WORLDWIDE, still with all 3, than you can count on the fingers of one hand !! (and these could be errors !! )
To answer both of these questions:
Some of you might not like this answer (it’s going to be long), but this is the best I can give you to solve your issue.
Easynavs allows us to obtain VOR data from anywhere, input it manually (or in batch), and bake it into a bgl. Now, what are you referring to is very likely possible (haven’t tried, in all likelyhood it would work), but this is not the project we are doing, as we are focusing on enroute navdata.
Just for the record, I don’t want to reuse files from FSX and then publish it. Also, personal use is one matter, distributing it openly is another.
While you can get VOR info from a lot of places, Runway Approach Marker data are harder to come by (and this is why I believe they will be left out of what we’re doing, at least for the moment).
There could be a solution to both of your questions, as (luckily )FSX navdata data seems to be compatible with MSFS.
It requires some computer heavy lifting (not a lot though, but this can seem a lot to some out there). If you are one of those persons who refuse to do any effort/legwork/completely unwilling to learn, then sorry, this is not for you. Also, this is not PHD level stuff, if you own a multi-hundred (or thousand) dollar piece of equipment, and can barely use it, well… it’s like buying a Ferrari, and afraid to step on the gas pedal. The only reason I’m saying is is to stop questions like I don’t want to do this / I don’t know how to copy files / What is a file anyway / I don’t know how to find a file, even if I know the name / I don’t know where is FSX installed /I don’t where custom sceneries are stored in MSFS/ I don’t know how to find .apx files in the FSX folder/ I don’t know how to use Google, etc.
So theoretically you can use all those nvx, apx and atx .bgl files from FSX, in MSFS.
The key is:
B) NVXFiles subfolder containing the new en route navaid BGL files.
C) APXFiles subfolder containing corrected ILS, markers, terminal NDBs and airport data.
D) ATXFiles subfolder containing corrected airways and en route intersections.
What you guys (both of you) are referring to are the APX files.
I haven’t tried, but using the .bgl files from FSX should work in MSFS.
So this is the issue, that needs to be solved.
They don’t even have to be in their own little subfolders (as by default they are stored in regionally separate, numbered folders), they can all be in one folder (this will make editing the layout.json file easier for you later.
You can make an addon scenery out of them (in your MSFS Community folder).
If you don’t know how to make an addon scenery (I’m not a super expert either), just download one (tips at the end of the post), rename the main folder (just so you can differentiate it once it’s in the Commnunity folder), copy your lovely .blg-s into the ‘scenery’ folder, then edit the LAYOUT.JSON and MANIFEST.JSON files. Both needs to be done, however the main stress in on the LAYOUT.JSON file, as this will tell the scenery which .bgl files to use. Make sure to include all your .bgls, (there’s around 70ish, use of Ctrl+C / Ctrl+V shortcuts is highly recommended). It’s a bit tedious, but it can be done in less than 30 mins, and then you’re set for life. Pay attention the correct folder names as well, they can be renamed, however the .json file contents will have to match the real file names/paths (hence it’s easier to have them in a single folder, CTRL+C / Ctrl+V type editing will be easier, as you’d only have to change the file name. Don’t bother changing the ‘size’ and ‘date’ files, those can stay as they are.
Since you are inputting multiple bgl files, make sure you use a comma between, like this:
},
{
However make sure that there is no comma after the VERY LAST bgl in your list
}
]
}
…and this is how the end of the file should look.
Just to give you a little more concrete example, if I were to want to make a scenery for Airways (these are ATX files, not APX, but the concept is the same), the file would look something like this (and I’m totally NOT saying that I have done this):
{
“content”: [
{
“path”: “ContentInfo/FSX-Airways/ContentHistory.json”,
“size”: 170,
“date”: 133269743428255099
},
{
“path”: “ContentInfo/FSX-Airways/Thumbnail.jpg”,
“size”: 5446,
“date”: 133088245198508011
},
{
“path”: “Scenery/FSX-Airways/ATX00000.bgl”,
“size”: 1783536,
“date”: 133269743428155122
},
.
.
.
{
“path”: “Scenery/FSX-Airways/ATX11070.bgl”,
“size”: 1783536,
“date”: 133269743428155122
}
]
}
The . . . section is for the rest of the 70 files.
Now, where to find an ideal, simple candidate scenery?
I would recommend WWII Kure Atoll Airport - United States
from flightsim dot to - it’s very basic, but has all the minimum bits you need.
Once it’s done, you might want to test it (altough this should work straight away in MSFS). Of course the scenery has to be in your Community folder, otherwise it won’t work.
The easiest way to do this, is in Little Nav Map (which you’ll probably need anyway if you’re planning to use older Navdata).
So in Little Nav map: Make sure you’re Navigraph data is off, as to not to skew results (Scenery Library, Navigraph, Do not Use).
Then do a Load Scenery Library (this will refresh all the data that Little Nav Map has pulled from MSFS, including any new addon sceneries, including the one you’ve just made).
Once that is done, just right click on your favorite big airport (which FSX also had data for), go on ‘Show Information’. If you scroll down the the very bottom of the Overview Tab on the left, you will see Data Sources, where it lists the .bgl files. Default Navdata is coming from the Official/Onestore folder. If MSFS is using your addon, it will be listed here. If you don’t see it the first time, try multiple airports. You might have an addon that superseedes it (so try multiple airports, and see if it works)
That’s roughly it. I know this can be a lot, but due to the nature of this, I cannot help any further. Also, please don’t come to me with basic questions. If you are enjoying the perks of owning a PC (and not a Playstation), then it’s a good idea to learn a little bit on how to harvest that power in that computer. Also, using Total Commander (it’s FREE) makes this whole process a lot easier, the default file explorer in Windows is designed for… well, people with less advanced skills, and it probably won’t even let you edit non .txt files without some fight. However it’s not necessary.
Just a quick note concerning airport navaids:
In MSFS, the airport related navaid data (ie. ILS, Marker-NDB’s plus many more parameters) are stored in the NAXnnnnn.bgl files.
This differs from FSX where this type of data is stored in the APXnnnnn.bgl files.
I’m not certain that one could simply rename an APX file and insert it into an addon.
I personally haven’t investigated, but I imagine that the effort would require extracting the pertinent data for the airport from the APX file and then “porting” that data into an NAX file (ie building a new file).
I’m sure that factors such as runway alignment, existence of runways, elevation, would need to be taken into account.
Not trivial.
Regards,
John
If the navaids were restored into the map, one could always hand-build their own radio arrivals and departures. That would complete the fun…
well, yes and no. The procedures already available already have correct altitude restrictions, intercept headings, racetrack timings etc etc. It’s much more comfortable than planning each approach individually. approach procedures exist for a reason
Oh sorry, now I’ve realized we’re talking a DIY solution, not some github big mod project. In that case I’ll be tryin to do these things myself now, procedures included. If I get any success I’ll report here.
Okay folks, so I have good and bad news.
The good news is that the method outlined by @Susu986 works very well, and in fact the airport APXnnnn files do load, along with terminal navaids, ILS however…
the bad news is that the MSFS aerodrome data such as parking positions is overwritten by the FSX aerodrome data, the runways are duplicated and in general it’s not a net benefit for me, also the procedures do not work either.
Hi Juk,
I’ve a done quick looks around, and read on a forum that ADE (Airport Design Editor), and it might read them. I’ve never done any FSX editing myself, so cannot comment whether this works, but might be a good starting point. However disassembling all those bgl files airport-by-airport is a monstrous job - definitely not something for a world-wide solution, more just doing on a per-airport basis.
But at least the FSX files will serve as a time-capsule, so nothing will get lost.
Hello all.
First post for me here… flying back on MSFS 2020 few weeks ago after PC update (my old GPU was not good enough).
I’m not an hardcore simmer but I start a 1924 World Tour run with the Black Square 208 Analog Caravan (with KX155, no GPS) and I discover the issue with VOR.
Flying on the magenta line is not for me, as it’s boring like a highway drive in real life.
So, after digging the net, i found this topic and it’s a real pleasure to see that i’m not alone.
I’ve no skill in code, files management, json arcanes and all this stuff so i’m afraid i can’t help on this project (except if you need hands to copy datas from files to anothers…) but if someone manage to publish an addon with legacy vor all around the world it will be amazing.
Thanks a lot for all the time spent on this project !
And it’s a shame if Asobo not listen about the VOR and radionav slow death…
Hi everyone,
Jumping in just to raise awareness of a mod I am working on:
Question to @Susu986 - did you have any issues with navaids close together one coming from MSFS and the other from your mod which share the same ID or frequency or both? Any idea how the sim handles such situation?
Thanks!
Hey Apollon, so I’m just using the navaids from directly from FSX as an addon scenery (I don’t have the patience to go through and parse the data, I just wanted to make sure that the VOR stations from 2006 would never go away, despite what’s going on IRL, so I’m just reusing the files). Obviously this is not something I can publish, but I van explain how to create the addon (you’d need a copy of FSX of course). These are just enroute VORs and NDBs mind you, not terminal ones. Yes, there are duplicate navaids with the same freq, or sometimes two Navaids at almost (or exactly) the same place, with different freq. I’m using Little Navmap to see the data. I’m flying a lot, but this never seems to be a problem, seemingly everything works… I can’t recall a VOR station not working (but I could be flying in the wrong part of the word). If I have time in the afternoon, I’ll test this. This solution is far from perfect but at least future proofs the availability of navaids. Little Navmap is HIGHLY recommended.
Done some expirementing with the analog Caravan (mine favourite too):
If Asobo and my addon VOR has different frequencies, same identifier (TAS), same region:
Only the addon VOR is picked up by the radio, even if their location is slightly different (5000 feet in case of FCM VOR which I’ve also tested)
If MSFS and my VOR is on the same location, same frequency, but different identifier (EHK, and CDC), same region:
Interestingly, the Asobo one is picked up (listening to the morse code, that’s the only way to discern) Although Asobo’s was high power, and mine low, I was only 5nm away. Couldn’t find more examples.
If everything is the same: Little Navmap only shows me the addon VOR, like as it the Asobo one wouldn’t exist. I’m sure it does, because it’s on Skyvector, however LMN only show these as strictly addon VORs. My COM radio picks it up of course, I’m just not sure which one as it’s impossible to tell.
If both the ident and the freq is the same, but they show up as double (I’ve only found one, they are rare, and their elevation was different by like 5 feet), then it’s impossible to tell which one I’m receiving, LNM shows both.
Different frequency, different identifier, same location: I couldn’t find any example to test on.
I think that’s all situations covered 
Definitely shows the viability of the mod. What you’re doing is amazing! Luckily, MSFS 2024 is like 99% the same as MSFS 2020, so this mod you are creating will be viable in the future as well.
Thank you for testing.
It behaves the same way as I describe in the “1958” thread 
Sure thing!
What you are doing with your 1958 is amazing!
I’ve never had the patience to go that far (and right now just happy to have the FSX navaids), kudos to you!
