ILS 18R issue

[curt1]

Either my flying skills are way off, or there's an issue with runway 18R.  I've captured the localizer and glide slope, and from 1,600 ft. down the descent decays to where you're coming in high, right past the landing zone.  I tried it three times with always the same result.  Someone want to test this and confirm?

Curt

[cmpbllsjc]

LOL, thats the way the default DFW was as well.

I used to run the Terminal D package by a fellow named Rhett Browning that was available on Avsim. Using his scenery and ADE also produced the same thing for 18R. Since then I  always choose another runway to land on until someone fixes that ILS.

I have the new one by Dennis installed but I have yet to try the 18R ILS.

Dont worry though, your not the only one who experiences this.

[curt1]

Interesting to know, wasn't aware of the ongoing problem.  My problem occurred with the update from Dennis installed, so guess I better side-step to 18L or just hand fly it in.

Curt

[virtuali]

Do NOT use any "ILS fix" addon file! The default scenery is entirely wrong, on most ILS. Our KDFW fixed all of this, but it might not work if you have added other files for this area that deals with ILS.

[DMullert]

Hello Gang!

Just as an FYI, the only thing I did with the updated AFCAD file was properly assign gates and add gates/parking positions.  I did not mess with the ILS's.  I did some testing after this thread started and my ILS approaches into 18R are allright - they're not dead on but they are manageable.  I did speak with an American Eagle pilot friend of mine and he pointed out that the approach to 18R is typically on the high side and that in most cases they disengage the A/P for landing about half a mile from touchdown to ensure they put it down on the numbers.

Food for thought.

Denis D. Mullert

[virtuali]

Yes, that might be the case. However, we were quite surprised to discover that, most of the default ILSs at KDFW, are positioned entirely wrong. Not so much the glide/ or localizers, but almost all DMEs were wrong.

[B777ER]

ILS for 18R brining me in too high as well. This is with nothing else added but FSDT install only.

[virtuali]

I can only confirm the ILS are correct in the scenery.

Have you realized ILS 18R share the same frequency of the one at 36L ? They both are on 111.9 MHz so, you might probably have to enable the Backcourse, and verify the ID it's IVYN (18R) and not IBXN (36L)

[duckbilled]

I was using the DDM AFCAD and found that the approach data was gone on my first flight. ATC was directing all ai, and myself to RWY 18R VISUAL approach. In the default GPS, all of the approach data was gone. I could pull up an ILS frequency in the FSX map and the AP did appear to track an ILS but I wasn't set up properly to tell if it was working well.

Anyway, I uninstalled that AFCAD and reinstalled the one that came with the scenery and the approach data was back in the GPS and ATC was using ILS approaches again.

I have found that every time I replace or modify (even just changing parking designations) in FSDT airports, the approach data gets messed up. I had a big issue with KFLL until I reinstalled the scenery from scratch. At some point, I think I need to reinstall all of my FSDT scenery because I know I have modified most of the to correct parking issues.

If someone doesn't fly using default ATC or use the default GPS for approached, you will probably never know this issue exists. 

[virtuali]

I have found that every time I replace or modify (even just changing parking designations) in FSDT airports, the approach data gets messed up.

No, that doesn't have anything to do with our sceneries. KDFW doesn't include ANY approaches, it relies on the default ones.

Since it doesn't change the default ones, it's correctly programmed with "DeleteAllApproaches=False" in the AFCAD. BUT, if you edit it with ADE, for some reason (I can't understand the reasoning behind it), it gets saved back with DeleteAllApproaches=True so, obviously, since it doesn't include any approaches, it will result in no approaches at all.

So, it's an ADE issue, not an FSDT issue. We could preventing it by *duplicating* all the default approaches into our AFCAD, but it seems somewhat wrong, that the AFCAD should first delete all the default approaches, only to replicate them exactly as they are, just because ADE changes that flag.

What you can do, is to configure ADE to KEEP the XML file of the AFCAD (ADE doesn't generate the .BGL, it only generates an XML file which is compiled with the standard bglcomp from the SDK) and edit the XML to replace the DeleteAllApproaches=False command as it should be, than compile it with the bglcomp from the SDK.

[duckbilled]

Thanks. That explains a lot.

I originally though I was messing them up by using ADE incorrectly or using AFX with the wrong files.

Is this the same for all FSDT airports - no approach data in the AFCADS? I know I am having issues at other airports and I would like to get them fixed.

Also, can I use AFX without causing problems? I just want to adjust parking codes and I have found ADE to be a complicated to master for casual use.

[virtuali]

Is this the same for all FSDT airports - no approach data in the AFCADS? I know I am having issues at other airports and I would luike to get them fixed.

It depends on the scenery. On some sceneries (surely JFK and KORD), we included the approaches that we modifed, but in a separate AFCAD but, in general, if we don't do any modifications, we prefer relying on the default ones, also because not all the AFCAD utilites are able to save back an AFCAD without losing the approaches, the original AFCAD utility, for example, wasn't.