Here is my problem. I have FlyTampa KSAN. The problem is for some reason RC ATC is always setting rwy 09 as the TO and landing rwy no matter what the weather, even with fs2004 fair weather set with no wind.. (It's almost always rwy 27 in SAN) Now if I go into afcad and tell it rwy 27 has a Glidepath (which it dosen't) it will use rwy 27 as the main rwy. How can I tell it that RWY 27 is the main rwy without having to add a phoney glidepath to 27. Thanks for any helpBrad

RC gives first priority to the direction AI (if present) is using. AI and RC within certain tailwind limits will prefer an ILS/LOC runway over the opposite direction if no ILS system is available. I believe the AI engine runway scoring includes certain aircraft performance parameters for runway wind determined choices.http://forum.avsim.net/topic/338091-ai-problem-cloud9-kdca/page__p__2003506__hl__jim+vile__fromsearch__1#entry2003506 has a reply dated 6/23 that describes how runways are priority scored for AI. Look for the reply by Jim Vile - jvile01FS AI do not recognize unidirectional runway operation. TO-O and L-O settings must match at each end of the same runway.I am not sure if RC with no AI present recognizes runway TO-O and L-O runway settings.I have a version of KSAN as part of an Fly-Tampa airport scenery suite packaged by Aerosoft. In that version 27 has a LOC/DME and 9 has a full ILS/DME so AI would prefer 9 over 27 even in VMC pending acceptable tailwinds.To clarify how RC interprets TO-O and L-O runway properties with no AI present ask in the RC forum here on AVSIM. It is in RC scenery's data but I'm not sure if it is used that way and also if RC prefers a GS over just an LOC.

Here is my problem. I have FlyTampa KSAN. The problem is for some reason RC ATC is always setting rwy 09 as the TO and landing rwy no matter what the weather, even with fs2004 fair weather set with no wind.. (It's almost always rwy 27 in SAN) Now if I go into afcad and tell it rwy 27 has a Glidepath (which it dosen't) it will use rwy 27 as the main rwy. How can I tell it that RWY 27 is the main rwy without having to add a phoney glidepath to 27. Thanks for any helpBrad

OK, so here I am at KSAN with the wind 290/10 and the AI are using 27... RC gives priority to the runway the AI are using (with some terrifying exceptions) so RC would use it as well. In fact, on every occasion when I've had RC cranked up we're all using 27. I do have an AFCAD that was created by the old Ultimate GA group that may be a factor. Send me a PM with your email and I'll send it to you, because I have no idea where or when I got it.DJ

Most of the 'terifying exceptions' are in FSX if using ASE with DWC forcing global weather control. I believe that has been worked around with the FSUIPC version and the ASE developers. The other exception is when using Ultimate Traffic 2 which by default spawns AI too close to the airport for RC to observe before 40 miles out where the runway is assigned.If that Ultimate GA group afcad file does not match exactly the layout for Fly-Tampa's KSAN scenery that can cause problems with visual allignment meaning RC may have the incorrect runway and taxiway locations for knowing where your aircraft and AI are located in relation to the visual scenery. For the user aircraft it is the usual reason why runway clearance is not given for take-off entry or take-off clearance and RC when the user aircraft is on close final may freeze the incorrect AI in trying to prevent runway incursion.RC's airport data is taken from installed scenery data in order of scenery priority and the alignment of afd (airport facilities data) with the visual aspects is extremely importent.

OK, so here I am at KSAN with the wind 290/10 and the AI are using 27... RC gives priority to the runway the AI are using (with some terrifying exceptions) so RC would use it as well. In fact, on every occasion when I've had RC cranked up we're all using 27. I do have an AFCAD that was created by the old Ultimate GA group that may be a factor. Send me a PM with your email and I'll send it to you, because I have no idea where or when I got it.DJ

Most of the 'terifying exceptions' are in FSX if using ASE with DWC forcing global weather control. I believe that has been worked around with the FSUIPC version and the ASE developers. The other exception is when using Ultimate Traffic 2 which by default spawns AI too close to the airport for RC to observe before 40 miles out where the runway is assigned.If that Ultimate GA group afcad file does not match exactly the layout for Fly-Tampa's KSAN scenery that can cause problems with visual allignment meaning RC may have the incorrect runway and taxiway locations for knowing where your aircraft and AI are located in relation to the visual scenery. For the user aircraft it is the usual reason why runway clearance is not given for take-off entry or take-off clearance and RC when the user aircraft is on close final may freeze the incorrect AI in trying to prevent runway incursion.RC's airport data is taken from installed scenery data in order of scenery priority and the alignment of afd (airport facilities data) with the visual aspects is extremely importent.

Well, so far I have found that the MAIN problem is that FS9 gives priority to runways with full ILS. If I go into afcad and give rwy 27 a GS then everything is fine. Oh, well not realistic but I just won't use the APP mode on rwy 27

I don't know what application Fly Tampa used to create the AF2_ file. It might have been created with a more expansive application. It is best to use the freeware ADE9 or perhaps AFX to make your changes. AFCAD could strip out special objects (it was created before MS released all of the design documentation) allowed by the later released SDK documentation.Since you have a DME on the localizer on both ends of the runway it might be a better choice to remove the GS on 9. You can fly the altitudes based on DME though on higher minimum altitudes and visibility :) That way AI should correctly behave since I believe the 27 end is prime with 9 the reciprocal when all else is equal.While you are in to the localizers disable the back course on each since they appear to be on the same frequency at least in my version. In this case unless you are within two degrees or less of center line you'll be receiving the wrong localizer beam (and GS if you leave it in). This is a known FS default airport problem since in the defaults back courses for localizers are on by default.Current charts show RNAV approaches as well and if your instrument navigation database is up to date with the RNAV approaches those specified altitudes will be in there to allow you to fly a partial altitude A/P coupled approach on either end.

I don't know what application Fly Tampa used to create the AF2_ file. It might have been created with a more expansive application. It is best to use the freeware ADE9 or perhaps AFX to make your changes. AFCAD could strip out special objects (it was created before MS released all of the design documentation) allowed by the later released SDK documentation.Since you have a DME on the localizer on both ends of the runway it might be a better choice to remove the GS on 9. You can fly the altitudes based on DME though on higher minimum altitudes and visibility :) That way AI should correctly behave since I believe the 27 end is prime with 9 the reciprocal when all else is equal.While you are in to the localizers disable the back course on each since they appear to be on the same frequency at least in my version. In this case unless you are within two degrees or less of center line you'll be receiving the wrong localizer beam (and GS if you leave it in). This is a known FS default airport problem since in the defaults back courses for localizers are on by default.Current charts show RNAV approaches as well and if your instrument navigation database is up to date with the RNAV approaches those specified altitudes will be in there to allow you to fly a partial altitude A/P coupled approach on either end.

Which is almost exactly what I do now with the IFly 737 when landing on 27. I use vor/loc to lock on to the Loc. and use a controlled desent and set my altitude in the MCp to rwy Alt, then use VS and line up the green arc on to the end of the rwy. Works pretty well.

Most of the 'terifying exceptions' are in FSX if using ASE with DWC forcing global weather control. I believe that has been worked around with the FSUIPC version and the ASE developers. The other exception is when using Ultimate Traffic 2 which by default spawns AI too close to the airport for RC to observe before 40 miles out where the runway is assigned.If that Ultimate GA group afcad file does not match exactly the layout for Fly-Tampa's KSAN scenery that can cause problems with visual allignment meaning RC may have the incorrect runway and taxiway locations for knowing where your aircraft and AI are located in relation to the visual scenery. For the user aircraft it is the usual reason why runway clearance is not given for take-off entry or take-off clearance and RC when the user aircraft is on close final may freeze the incorrect AI in trying to prevent runway incursion.RC's airport data is taken from installed scenery data in order of scenery priority and the alignment of afd (airport facilities data) with the visual aspects is extremely importent.

No worries - I've used this one for years and it works just fine since it was designed for the FT San Diego. I've had occasions using ASV6.5 where I get landed with the wind and against traffic, although never at KSAN; no big deal - it's a rare thing and notable when it happens. RC is a great program.DJ