• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Tutorial: Approaches

Since FSX does not allow (RNP) after the RNAV but does allow (GPS) then I always use the RNAV(GPS) approaches. The difference between (GPS) and (RNP) is the minimum sight distance which FSX does not understand.
Click to expand...

The RNPs at KIAD are new (or at least the plates are newly published). I suspected that FSX did not allow and thanks for confirming.

The RNAV(GPS) type approach does not have vetical descent profiles so I tune the radio to the ILS (if equip'ed). I use the RNAV(GPS) Transitions I write but once established on final I fly the ILS so the GS controls the vertical descent.
Click to expand...

I do the same and often wondered how others fly these approaches.

FSX does not know what a CAT I, CAT II, or CAT III approach means and they all have to do with minimums prior to a missed approach.
Click to expand...

I wondered how to handle these as well. Thanks for this info as well.

The same applies to a RNAV(GPS) vs a RNAV(RNP) type approach. I write all the RNAV(GPS) type approaches which is what the USA is going to.
Click to expand...

I was under the impression that the US might be transitioning (no pun intended) to RNP using the GPS. I have begun to see more RNAV(RNP) approach plates being published at some of the larger US airports.

Thank you for your thoughts!

kagazi
 
I was under the impression that the US might be transitioning (no pun intended) to RNP using the GPS. I have begun to see more RNAV(RNP) approach plates being published at some of the larger US airports.
Click to expand...

I see the same thing. The RNP is a more precise approach then the (GPS). If there is a choice I write the (GPS). If only a (RNP) exist I use (GPS) but will state in my readme that the (GPS) in the list approach menu is actally the (RNP) approach plate so download and use it when flying my RNAV(GPS).

FSX is behind the 8 ball and these newer type RNAV approaches did not exist in April of 2004 which was the cutoff date for the approach database in FSX. That is why so many approaches are out of date and need updating.

The (RNP) is not understood by the raw XML. The following shows how the XML adds the (GPS) to the RNAV

<Approach
type="RNAV"
runway="19"
designator="LEFT"
suffix="0" <<<<============ Suffix letter if it exist
gpsOverlay="TRUE" <<<<======== (GPS) added to the RNAV so the approach page says RNAV(GPS)

The problem is the XML has no way of placing (RNP) after the RNAV type approach.

If the RNAV(GPS) has a suffix letter like Y then add that in appr mode of ADE which will look like this in the GPS receiver

RNAV 19L-Y(GPS)

If I wrote the RNAV(RNP) I would say download that chart and I would do this with the GPS Reciever

<Approach
type="RNAV"
runway="19"
designator="LEFT"
suffix="Z" <<<<============ Suffix letter if it exist
gpsOverlay="TRUE" <<<<======== (GPS) added to the RNAV so the approach page says RNAV(GPS)


RNAV 19L-Z(GPS) <<<<===== but state that it is the chart for the RNAV(RNP)

or

you could leave the (GPS) overlay off the RNAV and just show

RNAV 19L-Z which points to the RNAV(RNP) Z RWY 19L approach chart
 
Last edited:
Jim, thanks for this info it was very helpful. I may experiment with one RNAV(RNP) at 19L using the gps overlay but z in the suffix as you show it. This is consistent with the KIAD RNAV(RNP) Z RWY 19L plate. All of this depends on whether I can figure out the RF approach at TRING :eek:
 
Jim: Back to the discussion above, when I added the suffix and overlay, the GPS receiver shows the correct approach type with runway etc, e.g., RNAV-19L-Y GPS or something along those lines; however, the ATC window simply says GPS Y without the runway number or RNAV. Is there a way to have the ATC window display what is shown in the GPS receiver?
 
the ATC window simply says GPS Y without the runway number or RNAV. Is there a way to have the ATC window display what is shown in the GPS receiver?
Click to expand...

If I recall the ATC Window uses the Suffix instead of the number. Most approaches that have a suffix use RWY 00 which does not display in the ATC window.

FS uses the RWY 00 with a Suffix for many Circle to Land type approaches for the User /AI planes.

I will test further to see if my memory is correct.
 
Jim: Just to reconfirm, with the suffix ("Y") indicated in ADE for an RNAV(GPS) approach, the ATC window will only display GPS Y and RNAV Y.

When I remove the suffix ("Y"), the ATC display shows GPS 19L and RNAV 19L (for example). The GPS reveiver correctly displays RNAV 19L-GPS. The ATC display shows two approaches for one plate - I'm not a RW pilot, so I'm not sure if this is how it's supposed to be displayed.
 
I think the FSX ATC wasn't set up for multiple straight-in procedures of the same type to the same runway. Same problem in real world nav gear, so FAA and industry came up with the Z,Y,X suffix. The idea is to allow the pilot to pull up the right procedure. From what I've seen, FAA issued procedures are either RNAV(GPS) or RNAV(RNP). Since the RNAV(RNP) are SAAAR, I suspect most database distributors don't even include them. The old GPS overlay of conventional navaids and GPS procedures are going away.

scott s.
.
 
There is still another configuration. Using ADE change the runways so each is 25/07 and 19/01 (don't forget the start locations). This sets the original base end of 07 to 25 (same with the 19/01's). Now Xwind from 19 up to 25 using the high numbers. In some cases this can reverse the usage so the 19/01's take the bulk of the arrivals. I cannot give specific rules but if you don't like what runways are being used the most you reverse the process. It's all trial and error at this point.
Click to expand...

Jim, I'm experimenting a bit with reversing primary ends to see if it makes any difference regarding which end gets used when winds are not a factor.

My first experiment is with KLAS. The FSX stock condition is that the 1s and 7s are the primary end. When winds are calm they are always used.

My goal is to reverse which end gets used when winds are calm.

At KLAS I reversed the four ends as mentioned above and set the winds to calm; however, FSX was still using the 1s and 7s. From this I take it that FSX does not provide a higher score to the primary end? If this is true and assuming that I've reversed the ends successfully, what other tricks are there to get FSX to "prefer" the "other" end of the runway?
 
At KLAS I reversed the four ends as mentioned above and set the winds to calm; however, FSX was still using the 1s and 7s. From this I take it that FSX does not provide a higher score to the primary end? If this is true and assuming that I've reversed the ends successfully, what other tricks are there to get FSX to "prefer" the "other" end of the runway?
Click to expand...


The problem with KLAS is the runway ends are not equal in score to begin with. Some ends have ILS Approach code and some ends do not. If by example a 07 has a ILS approach and the 25 does not, the reversing to 25/07 will not lower the 07 score enough to make 25 the default runway.

Now that example is the opposite for KLAS but the point is a ILS approach on a low number runway end may have too much of a score to get the 25 to be the zero wind default runway.

Another problem is the wind. FS does not know what 0.0 wind speed is. When zero wind speed is set FS uses a very small amount of wind to force a runway to be the default. FS does not know what 0.0 wind means. The catch is FS likes to work in a clockwise direction from 0 to 180 and 180 to 360.

Some airports will not use the high number runway end even when the 07/25 is reversed to 25/07. The clockwise very small amount of wind when we set FS to 0.0 wind speed will see 07 first in a semi circle.

For every airport we can reverse the low to high runway number effectively there is another airport that will not work the same.

Its trial and error to see if a runway honors what we want it to do.
 
but the point is a ILS approach on a low number runway end may have too much of a score to get the 25 to be the zero wind default runway
Click to expand...

Jim, thanks for the explanation. I have a hunch that the ILS I added to 7R using your curved approach technique has possibly altered the scoring in favor of the 7s for the zero wind condition. I have not attempted to reverse the 7s/25s on the default FSX stock to see if this is true but it's something for me to test once I find some time.
 
Hi guys i tried to follow all the instruction how to make an curve approach but still i failed and all my AI are having an miss approach anyway i attached the approach i made maybe you can give some suggestion :) thanks
 

Attachments

  • h.jpg
    h.jpg
    74.6 KB · Views: 791
chris_ca said:
Hi guys i tried to follow all the instruction how to make an curve approach but still i failed and all my AI are having an miss approach anyway i attached the approach i made maybe you can give some suggestion :) thanks
Click to expand...

List the XML header for the approach
 
jvile said:
List the XML header for the approach
Click to expand...
Hi heres the XML. Sorry this the first time i made an curve approach.

<Approach
type="ILS"
runway="24"
designator="NONE"
suffix="0"
gpsOverlay="FALSE"
fixType="TERMINAL_WAYPOINT"
fixRegion="RO"
fixIdent="IAF24"
altitude="2300.0F"
heading="239"
missedAltitude="3300.0F">
<ApproachLegs>
<Leg
type="IF"
fixType="TERMINAL_WAYPOINT"
fixRegion="RO"
fixIdent="FAF24"
altitudeDescriptor="+"
altitude1="2300.0F"
/>
<Leg
type="CF"
fixType="TERMINAL_WAYPOINT"
fixRegion="RO"
fixIdent="IAF24"
flyOver="TRUE"
turnDirection="E"
recommendedType="WAYPOINT"
theta="0"
rho="0.0N"
trueCourse="0"
distance="0.0N"
/>
<Leg
type="CF"
fixType="RUNWAY"
fixRegion="RO"
fixIdent="RW24"
flyOver="TRUE"
recommendedType="WAYPOINT"
theta="0"
rho="0.0N"
trueCourse="0"
distance="0.0N"
/>
</ApproachLegs>
</Approach>
 
chris_ca said:
Hi heres the XML. Sorry this the first time i made an curve approach.
Click to expand...

Hi chris_ca

look at my notes below

<Approach
type="ILS"
runway="24"
designator="NONE"
suffix="0"
gpsOverlay="FALSE"
fixType="TERMINAL_WAYPOINT"
fixRegion="RO"
fixIdent="IAF24" <<<<<<<<----------- This must be FAF24
altitude="2300.0F"
heading="239" <<<<<<<---------- This must be the heading the AI Plane will fly toward the runway
missedAltitude="3300.0F">


In your picture above the XML heading = "xxx" should be very close to the same heading as your Localizer.

The rest of the XML is for the GPS line draw and has no affect on AI Plane behavior

<ApproachLegs>
<Leg
type="IF"
fixType="TERMINAL_WAYPOINT"
fixRegion="RO"
fixIdent="FAF24" <<<<<<<<<<<<<---------------- This must be IAF24
altitudeDescriptor="+"
altitude1="2300.0F"
/>
<Leg
type="CF"
fixType="TERMINAL_WAYPOINT"
fixRegion="RO"
fixIdent="IAF24" <<<<<<<--------------- This must be FAF24
flyOver="TRUE"
turnDirection="E"
recommendedType="WAYPOINT" <<<<--- Should be LOCALIZER for all CF's but is an option entry that FS does not use for these legtypes.
theta="0"
rho="0.0N"
trueCourse="0"
distance="0.0N"
/>

You will need another CF here with a new T_waypoint such as MAP24 so the line draw will curve to the left and attach to the runway end. Place the MAP24 where the runway extended center line intersects the Planes approach course heading

<Leg
type="CF"
fixType="RUNWAY"
fixRegion="RO"
fixIdent="RW24"
flyOver="TRUE"
recommendedType="WAYPOINT"
theta="0"
rho="0.0N"
trueCourse="0"
distance="0.0N"
/>
</ApproachLegs>
</Approach>

Note

IAF must be the first T_Waypoint the plane will cross over and FAF must be the second (closest to the runway threshold) the AI Plane crosses over.
 
Last edited:
Hi Jim,

I can see my AI are following the approach i made but there's something wrong, they turn and land on the side of the runway not on the exact runway. Is there something wrong i did anyway here's the XML.

<Approach
type="ILS"
runway="24"
designator="NONE"
suffix="0"
gpsOverlay="FALSE"
fixType="TERMINAL_WAYPOINT"
fixRegion="RO"
fixIdent="FAF"
altitude="2300.0F"
heading="327"
missedAltitude="3300.0F">
<ApproachLegs>
<Leg
type="IF"
fixType="TERMINAL_WAYPOINT"
fixRegion="RO"
fixIdent="IAF"
recommendedType="WAYPOINT"
altitudeDescriptor="+"
altitude1="2300.0F"
/>
<Leg
type="CF"
fixType="TERMINAL_WAYPOINT"
fixRegion="RO"
fixIdent="FAF"
flyOver="TRUE"
turnDirection="E"
recommendedType="WAYPOINT"
theta="0"
rho="0.0N"
trueCourse="327"
distance="0.0N"
/>
<Leg
type="CF"
fixType="RUNWAY"
fixRegion="RO"
fixIdent="RW24"
flyOver="TRUE"
turnDirection="E"
recommendedType="WAYPOINT"
theta="0"
rho="0.0N"
trueCourse="327"
distance="0.0N"
/>
</ApproachLegs>
</Approach>
 
Hi,

Normally when they land on the side of the runway, it means that you did not give them enough time to turn (i.e. they are turning too close to the runway) or you are forcing them to turn far from the heading from the FAF vs the runway heading (i.e. they are turning through too many degrees).

You can have them turn up to about 80 degrees 3 NM from the runway, but only about 45 degrees around 1/2 NM from the runway.

Either move your FAF waypoint so it is further from the airport, change the heading value in the ILS header section (I have found that reducing the curvature *or* increasing it may be the answer - try one and then the other), or you may have to do both. My best results come from moving the waypoint further from the airport and reducing the curvature the planes have to take to get lined up with the runway.

Hope this helps,
 
chris_ca

I did not mean to change the ID of the T_Waypoint to IAF and FAF. Keep them as IAF24 and FAF24 but just be sure they are listed properly in the XML. Your last XML listing above is correct.

Adding to Tom's post, the larger and faster the AI Plane the harder to make the turn and land on center line.

If you were making a curved approach for single engine prop planes the turn to final could be close in. For a B747 as Tom says the turn to final must be further out and not as sharp in the turn.

I have curved approaches for small float planes that I am testing that are real close to flying what looks like a downwind for the runway and once past the runway threshold the plane makes a 180 degree turn to final. This type curved approach only works for very small and slow planes.
 
Hi,

Yeah, my AI Convair 990's (which had the fastest approach speed of any common jet airliner) really do require a lot of room. :)
 
hello guys,

thank you all for the tips finally they land on the runway, i just love seeing them having a sharp turn :)...well except for the Dash8-400 it never lands coz the altitude of the a/c is to high i dunno whats wrong with that model.

Thanks again :)

Chris

P.s most of them are turboprops. :)
 
You must log in or register to reply here.
Back
Top