ILS 26L "IFZ" should be placed 9,2DME from NOXOB
That's exactly were it's placed, see the attached screenshot with the airplane placed at NOXOB, DME for 110.70 shows 9.2
08L doesn't have the loc course 282 anymore it is 283° meanwhile.
That's the magnetic heading. ILS course are programmed in the scenery as true headings, and they never change (unless the ILS is really reconfigured) What you see in your instruments, instead, is magnetic, so it's affected by the magvar variation database is installed in your FSX.
I didn't have the time to check all runways yet, but i hope you'll have an eye on that. thank you
We already have, before release, we went to each and every navaid of every approach, manually tuned the ILS and checked all the DME to be correct, and they were.
Check you don't have another AFCAD in conflict. What DME you read at the coordinates of my screenshot ?
I wonder why so many developers don't wanna touch the fsx airport navaids to sync them with AIRAC data, i see it as elementary to have proper navaids when buying any addon airport. It's a primary motive i purchase them, beside using up to date AIRAC data.
Who said we HAVEN'T "touched" them ?
In fact, if you open the CYVR AFCAD with any AFCAD editor, you'll will notice that ALL ILS localizers and DME HAVE been changed by us (AFX, for example, will show them all as being "user modified"), for the precise reason the default ones have usually DMEs misplaced. They were corrected. If you don't read the correct DME, seems to indicate a conflict caused by another AFCAD somewhere.
What we are (and no wonder other developers share the same view) not too keen touching, is changing other items in the area, like terminal VORs, and there are of course sound reasons for this: the first one is that only a fraction of users updates their AIRAC data. Even less now there are not so easily (=free) available as they were before. It would be very wrong to *assume* everybody would always have the latest data.
Suppose something that affects multiple things (it has happened at places we were working on, Zurich at a certain date removed most of the VORs in the area and replaced it with GPS fixes, changing ALL their published approaches AND Sid/Stars AND even lo/hi routes), it would cause problems everywhere, especially for the approaches. Or simply confusing situations, such frequencies that were present in the default scenery that in real world would be assigned to different navaids.
We are of course forced to verify all approaches, when something is changing and is affecting the airport *design*, most obvious example is when new runways are added, such the case of O'Hare. In that case, we HAVE provided new approaches too.
The only solution that makes sense, is being sure the scenery is coherent with the charts SUPPLIED WITH IT, and that's it. This means the scenery will always be usable even years from now, without requiring to supply users with new charts AND scenery updates each time there's an AIRAC update that relates to the scenery. If we were trying to follow that route, the scenery would have to be sold as a subscription.
I'd say that, since there are developers who ARE in the business of charging for regular Navdata updates, same as they supply FMC databases for popular add-ons airplane, they could also supply .BGLs containing ONLY Navaids that, when put on an higher layer in the Scenery Library, could update any airport (default or 3rd party) to be compatible with they data THEY are selling.
This would suit both users: those that are happy with the default FSX scenery and whatever updates comes from a 3rd party add-on and DO NOT subscribe to those services, and those that DO subscribe, and want everything to be current. It will work WAY better if both the FMC navdata and the navigation BGLs would be supplied by the same people, from the same data source, rather then trying to convince each and every scenery developer out there to keep all their products constantly updated with AIRAC cycles.
