VoxATC & FSAerodata

[mikced76 57]

Hi

Would you recommend this combination. I have an old cycle of FsAerodata that I plan to install but if there will be more headaches than joy I might not. For example when I update my Airports with ADE should I edit the com frequensies or does FSAerodata have its own database that takes priority over anything I edit in the Airport afx files (and if so, does it also handle its own Aproach/departure freq?). In other words does it matter if I update the frequencies if I use FSAerodata

Mike

   

 

Edited December 14, 2018 by mikced76

[jabloomf1230 2,445]

As long as the edited airports are a higher priority in your scenery library than fsaerodata, the comm frequencies will not be impacted. I have about 150 airports that I edited with ADE, but I use fsaerodata with the most recent AIRAC. I let fsaerodata worry about new comm frequencies because I only update taxiway links, taxiway designators, airports, aprons and gates. ADE is addictive, but it beats buying a ton of  3rd party offerings for midsized airports.

I should add though that there has been some concern that the "Delete Comms" entry in airport BGL files edited with ADE might be ignored by VOXATC, although I've never experienced that supposed conflict. If this bug was extant a lot of payware airports might also display the wrong frequencies.

[Mad_Mac 21]

I just had an e-mail from Jose of fsAerodata. He thinks he has found a solution for the default 135.475 universal frequency at untowered airports in the US. He says it has to do with how fsAerodata prioritizes frequencies, currently approach has the highest priority, but moving coms to a higher priority (in the NAVAID folder) seems to fix the problem.  He plans to include this in the next AIRAC cycle. 

He’s not sure why VoxATC behaves this way, but you have to admire his persistence. 

[Mad_Mac 21]

This is a follow up post on the “135.475 bug” that used to happen at some untowered airports. The issue was: after contacting Unicom to ask for airport information, and  opening your flight plan on FSS, one was prompted to tune to 135.475 instead of the local CATF (Usually the same as Unicom at most small airports). For the last 2 AIRAC cycles I have no longer encountered this issue. There are directions for setting the priorities in World Scenery in the help area of FsAerodata. I believe the install does this automatically now. 

With some experimentation I have learned that how the priorities are set can cause problems between VoxATC and addon airports. Problems can include: Fatal errors mid route; ATC simply forgetting about you and discontinuing flight following without telling you; and weird frequency anomalies. Setting the FsAerodata files (In their correct sequence) beneath my addon airports, but above everything else has resolved almost all of these issues. 

Seeking realism in simulating can be challenging, but is also rewarding. Hope this is helpful. 

[jabloomf1230 2,445]

This problem is not specific to VOXATC and is related to the way that MS established priorities in the scenery library. It worked fine until 3rd party developers started adding airports. Even that worked more or less okay if certain rules were followed. But then add-ons like ORBX regions/Vector and  My Traffic started installing airports en masse. Now it's a complete carp shoot as to whether the user will see a perfectly crafted airport that has been revised by a 3rd party. The P3d add-on.xml method has just made everything even more difficult to troubleshoot.