• 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.

Why is this code ignored by AI

adr179

adr179

Resource contributor
Messages
259
Country
slovenia
I made a fithfull copy of a published ILS approach to LJLJ, but all of it's segments but last one from FAF to the runway are completely ignored and aircraft instead of flying to the IAF are being vectored over three counties onto a 30 miles final when coming northern sector, division line seems to be the last leg with HDG 305 deg.. From southern sector it looks like planes are vectored to a heading that is something in the half of 305 and 35 deg., this 35 is heading of CR leg - here's situation in ADE:
basta.jpg


and XML for this looks like this:
Code: 
<Approach
   type="ILS"
   runway="31"
   designator="NONE"
   suffix="0"
   gpsOverlay="FALSE"
   fixType="TERMINAL_WAYPOINT"
   fixRegion="LJ"
   fixIdent="BASTA"
   altitude="1219.2M"
   heading="306.63"
   missedAltitude="1828.8M">
   <ApproachLegs>
      <Leg
         type="IF"
         fixType="TERMINAL_WAYPOINT"
         fixRegion="LJ"
         fixIdent="LBL"
         recommendedType="LOCALIZER"
         recommendedRegion="LJ"
         recommendedIdent="LJB"
         theta="305.43"
         rho="0.4N"
         altitudeDescriptor="+"
         altitude1="2133.6M"
         altitude2="2133.6M"
         />
      <Leg
         type="CF"
         fixType="TERMINAL_WAYPOINT"
         fixRegion="LJ"
         fixIdent="13LBL"
         flyOver="TRUE"
         turnDirection="L"
         recommendedType="TERMINAL_WAYPOINT"
         recommendedRegion="LJ"
         recommendedIdent="13LBL"
         theta="140"
         rho="13.0N"
         magneticCourse="140"
         distance="13.0N"
         altitudeDescriptor="+"
         altitude1="1219.2M"
         altitude2="1219.2M"
         />
      <Leg
         type="CR"
         turnDirection="L"
         recommendedType="LOCALIZER"
         recommendedRegion="LJ"
         recommendedIdent="LJB"
         theta="125.43"
         magneticCourse="35.4"
         distance="0.0N"
         altitudeDescriptor="+"
         altitude1="1219.2M"
         />
      <Leg
         type="CF"
         fixType="TERMINAL_WAYPOINT"
         fixRegion="LJ"
         fixIdent="BASTA"
         flyOver="FALSE"
         turnDirection="L"
         recommendedType="LOCALIZER"
         recommendedRegion="LJ"
         recommendedIdent="LJB"
         theta="125.43"
         rho="10.7N"
         magneticCourse="305.43"
         distance="2.0N"
         altitudeDescriptor="+"
         altitude1="1219.2M"
         altitude2="1219.2M"
         />
      <Leg
         type="CF"
         fixType="RUNWAY"
         fixRegion="LJ"
         fixIdent="RW13"
         flyOver="FALSE"
         turnDirection="L"
         recommendedType="LOCALIZER"
         recommendedRegion="LJ"
         recommendedIdent="LJB"
         theta="125.43"
         rho="2.0N"
         magneticCourse="305.43"
         distance="8.8N"
         altitudeDescriptor="+"
         altitude1="363.016M"
         altitude2="363.016M"
         />
   </ApproachLegs>
   <MissedApproachLegs>
      <Leg
         type="CF"
         fixType="TERMINAL_WAYPOINT"
         fixRegion="LJ"
         fixIdent="LBL"
         flyOver="FALSE"
         turnDirection="L"
         recommendedType="TERMINAL_WAYPOINT"
         recommendedRegion="LJ"
         recommendedIdent="LBL"
         theta="0"
         rho="0.0N"
         magneticCourse="306"
         distance="1.4N"
         altitudeDescriptor="+"
         altitude1="430.0M"
         altitude2="600.0M"
         />
      <Leg
         type="VI"
         turnDirection="L"
         magneticCourse="140"
         altitudeDescriptor="+"
         altitude1="1219.2M"
         />
      <Leg
         type="CF"
         fixType="TERMINAL_WAYPOINT"
         fixRegion="LJ"
         fixIdent="LBL13"
         flyOver="FALSE"
         turnDirection="R"
         recommendedType="TERMINAL_WAYPOINT"
         recommendedRegion="LJ"
         recommendedIdent="LBL13"
         theta="0"
         rho="0.0N"
         magneticCourse="175"
         distance="11.0N"
         altitudeDescriptor="+"
         altitude1="1828.8M"
         altitude2="1828.8M"
         />
      <Leg
         type="CR"
         turnDirection="L"
         recommendedType="VOR"
         recommendedRegion="LJ"
         recommendedIdent="DOL"
         theta="235"
         magneticCourse="115"
         distance="0.0N"
         altitudeDescriptor="A"
         altitude1="1828.8M"
         />
      <Leg
         type="CF"
         fixType="VOR"
         fixRegion="LJ"
         fixIdent="DOL"
         flyOver="TRUE"
         turnDirection="L"
         recommendedType="VOR"
         recommendedRegion="LJ"
         recommendedIdent="DOL"
         theta="0"
         rho="0.0N"
         magneticCourse="55"
         distance="10.0N"
         altitudeDescriptor="A"
         altitude1="1828.8M"
         altitude2="1828.8M"
         />
      <Leg
         type="HM"
         fixType="VOR"
         fixRegion="LJ"
         fixIdent="DOL"
         turnDirection="L"
         recommendedType="VOR"
         recommendedRegion="LJ"
         recommendedIdent="DOL"
         magneticCourse="340"
         distance="5.0N"
         altitudeDescriptor="A"
         altitude1="1828.8M"
         />
   </MissedApproachLegs>
</Approach>

I don't think, I overlooked something, but any suggestion would be much appreciated.
 
Hi,

The AI aircraft ignore everything in all legs (IF, CF, TF, etc.). They will only follow the information in the main ILS header. They:

1. Will approach the FAF (waypoint listed in the header) at the altitude listed there.
2. Will fly the heading listed in the header (descending), until they approach the extended runway centerline. Then they will turn to the runway heading.

Hope this helps,
 
Last edited:
Thank You, sure does help, so for the sake of AI it's also completely fine if I make only two-legged approach - one pointing towards the runway and the other one CF to the runway threshold, pitty, since it looks like there's no was to satisfy all the needs, since I need to force the traffic on missed approach to turn left. I tried many things and tracks flown in one of my setups mislead me, since tracks flown in approach phase wwere almost correct(well, real close to the real thing) in thinking it was something else but just the header, but I needed to drop that setup because missed approach tur was to the right and there are 8000+ foot mountains jus 10 miles to the north of the airport, consequences of such "vectoring" were :eek: as You can imagine. So I'll probably stick to solving this problem and model realistic missed approach for AI and will have to forget about the inbounds.
 
Adding to Tom's post

AI/User plane are always vectored to the center line of the runway on a 30 degree offset heading. This try's to replicate what real world controllers will do.

When testing where the AI Plane will join the turn to final then only use one AI Plane in the FP. FS has a seperation code that many are not aware of. Multiple AI Planes being vectored to the final turn will do so further and further out from the FAF. FS uses a slotted system the same as real world.

The leg types as noted are for drawing lines. The lines are for the GPS. The GPS is for the User Plane only. The approach header (in your case) is a ILS where all the data exist for the AI Planes approach including the non-published missed approach altitude and turn (left or right).

Looking at your XML you have the IAF on one course and the FAF on another course. The FAF is also too far from the runway threshold (should be about 5 NM's).

The IAF and the FAF in most ILS approaches are inline with each other spaced about 5NM's from each other (IAF ------> 5NM's to the FAF -------> 5NM's to the runway.) It is always best to use the proper approach chart for proper placement of the IAF and FAF.

Once that is in place then you make a transition from the T_Waypoint of LBL and tie it to the IAF that you make for the inline runway.
 
pitty, since it looks like there's no was to satisfy all the needs, since I need to force the traffic on missed approach to turn left.
Click to expand...

Bottom of the Approach header is the heading + turn direction for the AI /user plane non-published missed approach turn.
 
So I'll probably stick to solving this problem and model realistic missed approach for AI and will have to forget about the inbounds.
Click to expand...

Force all inbounds on a curved approach so they all enter the 30 degree offset on the same side of the runway.
 
Gentlemen, thank You both for replying.

Bottom of the Approach header is the heading + turn direction for the AI /user plane non-published missed approach turn.
Click to expand...

I'm aware of those two values. In the meantime I discovered a layout that could work and it looks like this:

d5lbl.jpg


BUT, there's a problem. For this layout I need to put HDG 140 in the header of Approach and here ADE plays a little trick as You can see ( images of app. legs descriptions with red
numbers 2 and 3 were copy/pasted from two other screenshots) if I have HDG 330 ADE is happy with value LEFT as shown bottom right. When I change HDG to 140,
ADE automatically changes Default turn value to RIGHT as shown at top left insert and, finally, when I change Default turn value back to LEFT, ADE inserts what
you see in bottom left, marked number 3. This wouldn't be a problem,if I could find Default turn value in the xml, I can locate heading in xml in the approach header,
but I don't know where the Default turn direction value is coded in xml. But, then again my pattern of thoughts was: If HDG is oposite (well, close to opposite),
maybe also the default turn value needs to be mirrored and RIGHT actually means LEFT, so I tried to trick this situation and left HDG in ADE at value 330 degres,
compiled, opened resulting xml and wrote my 140 as HDG after FAF. Result was, my approach wasnt recognised and ATC was issuing VFR app. clearences.

Where is value of Default turn from ADE hidden in the xml?
 
Heading degree at the bottom is the AI heading to the center line of the extented runway. In theory the heading from the IAF to the FAF is what you place in the heading degree window. This will not work in your case since AI planes are hard pressed to fly downwind and then a reversal turn to final.


The best the AI will do is an angle that continues a path toward the runway on downwind not away from the runway. Long red line is runway center line



Notice my heading at the bottom is the IAF to FAF heading which AI seek. The right left turn is not a factor since the AI plane always turns toward the curved approach (lesser radius). However when you plug in the heading degree for the AI plane, ADE will set the right turn by default since it is calculating the lesser radius degree back to the IAF.
 
Hi Jim,

I believe he is asking about the missed approach turn. You mention above that the heading/turn direction in the ILS header controls the AI's missed approach turn direction:

Bottom of the Approach header is the heading + turn direction for the AI /user plane non-published missed approach turn.
Click to expand...

I do not how these affect the missed approach? And where in the XML is the turn direction set, or is this calculated from the heading value? (as ADE seems to do).

Thanks,
 
Tom

It is the difference between the runway heading and the AI plane heading.

Let me put a few pictures together which will illustrate how FS calculates the turn direction as per ATC for the User Plane if the non-published missed approach is used. AI Planes cannot fly the published missed approach so they are always flying the non-published missed approach.
 
Tom

Recently there was a post on UUDD rwy 14R where the Localizer was not properly aligned to the runway. Making alignments may look ok but can affect other parts of the ATC. If we look at UUDD it has a published missed approach that turns to the right. I want to be sure the non-published missed approach that AI planes (and in most cases the User Plane) also turn to the right when instructed by ATC.

If I zoom in on the localizer I will see that it is offset a small amount. I need to correct this first which is not as easy as it may appear. We have to work from a standard setting and that is always the runway heading. In the bottom of my picture the runway heading to the 6th decimal is

Rwy Heading = 147.389999



I go to the Airport mode and I place 147.389999 in the Localizer heading. In my next picture I see the runway (gray line) is center the Localizer (after a small sideways adjustment) but the FAF line to the runway is off (kinked) and the missed approach dash line is no longer on center. These lines were originally tracking the localizer green feather which was not set correctly. Now that the Localizer has been corrected I have to realign the GPS lines.



It is the GPS lines in FS when running that will show us what ATC will do with the non-published missed approach turn. However, since I realigned the Localizer I have got to realign the FAF and the IAF so the Left/Right in ADE can be calculated properly. The runway is 147.389999. The Localizer is now147.389999.

I need to be able to back track the exact center line of the runway and that can only be done if the Start Location is 147.389999. This is where the 6th decimal position is very important in ADE. If we do not have the 6th decimal position to work with there is no way we can back out 10-12 Nm's staying on exact center of the runway.

I set the Start Location to the exact runway heading in the next picture. When I use "Go To" Rwy 14R the plane will slew up and down the runway staying very precisely on the center of the runway. If we could not set the Start Location to what FS says the runway heading is per the 6th decimal you get a rounding on compile of the start location in respect to the runway heading. A compiled start location of 147.3 is not 147.389999 but could be 147.4 or 147.5.



With all that said I can now 'Go To' Rwy 14R and know I am on center line of the runway regardless of how far I back out in slew mode from the runway. In the next picture I am in slew mode, connected to ADE with FSX running. I checked the slew up and down the runway and the plane stayed precisely on center line.



In the next 4 pictures I back out to the FAF and align. Then further out to the IAF and align using the move object to the aircraft.









It is important at this point to know that FS likes to work with a lesser radius in a circumference and in order for my Left/Right coding in ADE to work properly ALL headings starting with the runway and ending with the IAF are in an exact line.

Lets look at the first picture again. At the lower right bottom I have set the default turn to Not_Set. This means the runway heading and the AI Tracking heading are identical.



Lets start FS and 'Go To' rwy 14R at UUDD.

1. Select the Beech Baron
2. Back out in slew mode to the IAF CF14R
3. Bring up the GPS Reciever
4. Go to the approach page and select the ILS 14R vectors
5. 'Load' and 'Activate'

This picture shows the GPS lines in load and being processed by the .dll files instead of using the XML file. When we read the GPS not in Load/Activate we are actaully reading the XML compiled bgl or what I refer to as pre .dll files. When we Load and Activate we are now ingame and post .dll where the GPS is showing us the line draw after the .dll files process the XML compiled bgl data.



In the next picture we have to look at the definition of the 'IF' leg type

type=IF is Initial Fix or IF Leg. Defines a database fix as a point in space.

The point in space if I zoom in real close is directly on the nose of the aircraft. The reason why is because the AI plane heading and the runway heading are exactly the same value in my ADE code Not_Set.



What this now means is ATC does not have a lesser radius to work with in a circumference and the non-published missed approach turn is 50/50 to the left or to the right.

Lets set ADE so it shows to the right. I have the code set so the point in space (IF legtype) heading changes by .2. Using .2 even though a number like .05 would work builds in some varible if a kink is in the FAF T_Waypoint.



I go back into the ingame FS and look at the GPS. The point in space is now off to the right side of the nose by the .2 degree difference in runway heading.



If I zoom out we visualize the radius from the RW14R (runway heading) to the right side and back to the point in space is lesser in value then the radius from RW14R to the left side back to the point in space. This tells ATC to turn all non-published missed approach airplanes to turn right same as the published missed approach.



I realize this post is long but it is the first time I have explained in detail how ATC knows which way to turn a plane on missed approach. I also needed to show that all the lines must be straight in the GPS starting with the runway, localizer, start location, FAF and IAF before the .2 heading change can be honored.

If the FAF is not on center with the runway and has a sideways kink then the IF point in space may be on the wrong side of the airplane nose and the missed approach turning will be the wrong way.

The curved approach is a given. Which ever way the curved approach intercepts the runway center line is also the direction the missed approach will be. This cannot be changed and is a hard code in FS.

In my #8 post above I show a downwind track that AI planes will follow. The missed approach is to the right since the radius turn is a lesser value from the runway heading to the point in space for the IF leg. ADE understands this and sets the right turn by default when we set the AI approach heading (what adr179 is seeing)

Lets not forget Jon !!

Understanding what the Approach Mode must do is one thing. Coding ADE and adding automation to the core of the ADE utility is very complex at times. He continues to amaze and baffle all of us so the designer does not have to manually set such complex ATC coding.

Questions?
 
First of all - I resized my images, so those reading this topic in resolutions lower than 1600 don't need to scroll left-right.

No master Yoda, after this thorouh explanations, I don't have any further questions.
First of all I'd like to make something clear: layout of my LJLJ approach isn't something I made up myself - it's a copy of actual, real life approach layout.
For those who don't have access to the charts, just a little explanation: just 10 miles north of airport there's a mountain ridge extending more or less paralell to the runway heading and MSA in this sector is 10500 ft and that's the reason why everything (STAR's from that sector and approach layout itself) needs to be extended, there's a lot of altitude to loose in a short distance.

After 3 days of tweaking certain elements of approach code, here are
some of my, not necessarily 100% correct, observations:
- there actually is no general rule for AI traffic behavior in initial approach phase, every airport is surrounded with specific airway network and what works on one airport doesn't guarantee anything on another. When tweaking ILS approach header heading after FAF, I encountered situations from approach code not being recognised by AI, aircraft being vectored in a strange manner, go-arounds getting just one vector taking them out of FIR and disappearing due to their FP time exhaustion, with set values were "strange", while with "good" headings I got some situations that almost resemble real life tracks. There is no general rule for a "good" or a "bad" heading - that is (according to my observations) location dependent since points where AI leaves the airway system are unique for each airport.

- first heading an AI go-around gets is 145 degrees, either left or right, of the heading set in the appraoch header. So if I want my go-arounds performing ILS approach where HDG for apprach is 305 degrees to be given a heading of 180, I'll set heading to 330 in approach header. How this heading suits other needs is something else. In my setup I ended up with heading of 095 degreees as this heading on this particular airport results in almost real life initial approach tracks and runway heading as the first heading for go-around.
 
You must log in or register to reply here.
Back
Top