[Lupo]

Hi all,

These questions are directed primarily to jvile but any help will be appreciated. I'm curious about how to calculate rho and theta in relation to approach legs. Also the "Distance=" value -- how does one come up with that? Then there is the various Leg definitions and their meaning. I?m not a math wiz as you can probably tell but this stuff really interests me and the SDK is lacking in its descriptions. I would be grateful to anyone patient enough to shed some light on these values and how to arrive at them!

Thanks again,
John

[jvile]

John

Lets first talk about rho and theta

theta is a reciprocal heading value of a plane on an approach

rho is a distance value measured in meters.

In order to see how these two values effect some types of approaches you have to be very familiar with what the GPS can display in the form of white lines that the user aircraft will follow. FS9 uses a lot of "if " "and"  "or" logics in the Approach data. Based on what type Approach is written determines what part of the element statements are used.

You will always see rho and theta nested in a ILS vectors to final approach but is not a element statement that is mandatory for the Use Aircraft or AI Plane. However these lines of data are required by the BGLComp compiler.

Example of a simple vectors to final.

This is the runway information that can be seen for an airport that is decompiled. I don't like to use AFCAD to view this info because it rounds off some of these numbers and we need to deal with precise values.
 
<Runway number="7" designator="NONE"
    lat="N30 30.04767"
    lon="W081 41.09984"
    alt="9.14M"
    length="3046.17M"
    width="45.72M"
    heading="70.5" <------------------------ Runway True heading

Futher down the decompiled airport you start to see all the approach data and an example would be this.

<Approach type="ILS"
    gpsOverlay="FALSE"
    runway="7"
    designator="NONE"
    fixType="TERMINAL_WAYPOINT"
    fixIdent="JVFAF" <------------------------ FAF WAYPOINT Fix
    fixRegion="K7"
    heading="70.5" <------------- Runway True heading and not aircraft heading
    altitude="1900.00F"
    missedAltitude="2000.00F">
    <ApproachLegs>
      <Leg type="IF"
        fixType="WAYPOINT"
        fixRegion="K7"
        fixIdent="JVIAF" <-------------------- IAF WAYPOINT fix
        theta="253.5"    < ----------------- reciprocal of the MAG aircraft heading on approach to runway 7
        rho="22407.407" <-----------------------Distance in meters from the touchdown point to the IAF (JVIAF)
        altitudeDescriptor="+"
        altitude1="2000.00F"
        altitude2="1900.00F"

The rho meter distance value can be calculated from the mile distance which is the runway threshold distance to the IAF seen on the approach chart.

Mile distance on the approach chart says 12.10 miles from the runway threshold to the IAF then rho is 12.10 divided by 0.00054 = 22407.407

None of this is important for ILS type approaches because we usually have fixed waypoints to work from and the white lines seen by the GPS will be arrowed to those fixed points. As the User plane flys on the GPS (toggle switch) mode coupled to the NAV autopilot the white line turns magneta color at each waypoint or the whit line arrow cooresponding to the rho.

Where theta and rho become very important is VOR type approaches with outbound procedure turns to final. These type approaches may not have fixed waypoints and use a clock (timer) and DME from a VOR.

The approach Chart may show the outbound leg from the VOR (theta value) is a little different then the inbound leg to the runway using the same VOR.

The rho value establishes how far out the plane must fly from the VOR before it makes a procedure turn to 30 degree offset for inbound VOR radials. 

If the outbound leg must remain within 10 miles of the airport then the rho must be a value that draws the white line a certain distance before the procedure turn. If the outbound leg has to go 15 miles out then rho has to be calculated further to get a longer white line and a arrow at the end of it.

Again, look at the way the GPS draws the white lines on different type approaches that don't have waypoints to work with and you are seeing the results of certain theta and rho values.

hope this helps somewhat with theta and rho.

[Lupo]

Hi Jim,
Thanks for getting back to me. Your examples help alot. I will work through this some more when I get the chance. I'm sure I'll have more Q's but this gives me something to chew on. Thanks for all your contributions; they are very much appreciated!

John

[Lupo]

Jim

I spent some of my free time today trying to get the ILS for MSP35 working to no avail. I know you will soon release your rework of KMSP but I just have wanted to get AI to land on 35 in IMC till I have your files.

In looking at another release of yours I noticed that it appears you use the default airport to build off of in your ILS bgl. Is it necessary to do this? What I ended up doing in my file was just putting in taxiways to a small parking area to get the basic elements present but I still am not getting something right because FS still treats my rw35 as a visual.

I put in all the steps that I saw present in the other ILS approaches save the transitions but I have yet to get it to work.
I attached the file for you to look at.

Thanks for your help.
John

Attached File(s)

•  KMSP_ILS35.txt (15.1K)
  Number of downloads: 28
•  KMSP_ILS35.txt (15.1K)
  Number of downloads: 8

[jvile]

John


You are real close to activating the ILS 35.

First delete all the airport data after the header down to the Approach data for 35 ILS. This is not needed because AFCAD will add airport runway info and most of that is duplicated any way.

You have LORAH mis-spelled ( LORHA) and it does not align with your waypoint spelling nor can ATC find a IAF for the AI.

now use this airport header

<Airport ident="KMSP" name="Minneapolis&#x2D;St Paul Intl"
lat="44.880547" lon="-93.216922"
magvar="-2.30" alt="840.987F"
city="Minneapolis"
state="Minnesota"
country="United States">

Always use BGLX180 to extract the airport header and not BGLAnalyze. However you must use BGLAnalyze for all the approach data that you copy out of the APnnnnnnnn.bgl. BGLX180 corrupts the approach data area. But then again BGLAnanlyze drops some other leg info that is needed.

Change your magvar in the waypoints to -1.70
LORAH is a TERMINAL_WAYPOINT not a WAYPOINT. All blue triangles seen in the GPS receiver are TERMINAL_WAYPOINT and all pink triangles are WAYPOINTS

The IF 2 leg code needs 2 additional elements at the bottom and then make sure the AFCAD has the same ILS ID of IBMA

<ApproachLegs>
      <Leg type="IF"
        fixType="TERMINAL_WAYPOINT"
        fixRegion="K3"
        fixIdent="SSTAR"
        theta="168.7"
        rho="23148.148"
        altitudeDescriptor="+"
        altitude1="5000.00F"
        altitude2="3000.00F"
        recommendedType="LOCALIZER"
recommendedIdent="IBMA" />

Look over the txt I attached and make a comparison to your txt. Look at missed approach also at the magvar values.

Once you compile and add to the generic scenery folder start FS9. Make sure your AFCAD has the new runway and a ILS for 35.

Always use ATIS and listen to see if ATC is now recognizing your Ruway 35 as a ILS. To do this you must set visibility to less then 3 miles and winds at 350 if you do not have a crosswind runway AFCAD.

If 35 is paralleled to the 30's then ATC (ATIS) will say 30L, 30R and 35 ILS's Active for landing.

Once you correct the minor elements also always go to the GPS receiver and look at the approach lines for the new ILS 35. If you wrote the approach and published missed approach correctly the white lines will appear in the proper window for the User Airplane to track for your vectors to final.

Download Cooktop 2.1 from different web sites so you can work with xml instead of txt documents. If the decompiler names the file a txt file rename it to a xml extension and then open/read with Cooktop 2.1. Much better control of xml element statements that are color coded for possible errors.

See Attachment below and compare to yours   

Attached File(s)

•  kmsp35.txt (3.15K)
  Number of downloads: 18

[Lupo]

Jim

I've looked the files over and have a few questions. The first concerning an entry in the first segment of the written approach:

<Approach type="ILS"
   gpsOverlay="FALSE"
   runway="35"
   designator="NONE"
   fixType="TERMINAL_WAYPOINT"
   fixIdent="LORAH"
   fixRegion="K3"168.71          <--------------Why is the rw hdg here?
   heading="351.00"
   altitude="3000.00F"
   missedAltitude="5000.00F">

Then in the final segment of the approach portion:  

  <Leg type="CF"
       fixType="RUNWAY"
       fixRegion="K3"
       fixIdent="RW35"
       flyOver="FALSE"
       theta="168.7"
       rho="2778.71"       <----------is this the distance to threshold?    
       magneticCourse="348.7"
       distance="12038.89"
       altitudeDescriptor="A"
       altitude1="887.00F"    <------should this be 50ft above rw alt?

Thats my guess anyway I'll let you set me straight!
As far as the Magvar value I was wondering about such a different value in my file -- from what I understand that was a result of using BGLAnalyze. That also was why ?recomendedType=?  ?and recomendedIdent=? were missing.

But I am getting there I think. One last thing before I hang it up for tonight?can you define the Leg segments. I think IF is Initial Fix but I?m not sure on the others.

Again thanks for helping me through this,
John

[jvile]

Quote

fixRegion="K3"168.71          <--------------Why is the rw hdg here?

That is a theta and it should not be there. Only fixRegion="K3"

I keep looking at your txt and the one I attached and don't see any thing that shows the 168.71 in the TF statement. Delete it.

Quote

rho="2778.71"       <----------is this the distance to threshold?     

No, Because the DME transmitter for rwy 35 is at the end of the runway it is the meter distance from the threshold to the DME which is about 1.5 miles.

It is not a value that FS9 uses for anything at the present time but maybe for FSX.

Quote

altitude1="887.00F"    <------should this be 50ft above rw alt?

Should look more like the airport elevation because FS9 does not allow for sloping runways. If the runways slope in FSX then that value will be threshold elevation not airport elevation. Another one of those values that is correct in the leg type but not important yet in the database. 

Quote

As far as the Magvar value I was wondering about such a different value in my file -- from what I understand that was a result of using BGLAnalyze. That also was why ?recomendedType=?  ?and recomendedIdent=? were missing.

it is important to know what decompiler must be used for what element statement. I decompile with both decompilers and then combine what the two leave out which makes one complete file. The hard part was trial and error to fiqure out which one left out what or changed (corrupted) something.

I will post all the definitions for the 2 letter codes after I go back and find them in my computer.

[jzax]

Hello Jim, we are about to publish our freeware version 3 of LEMD (Madrid), and I am now fine-tuning the xml coding of the new ILS approaches.
I've been watching this thread and seen your latest KMSP, and I'd like to have your opinion on the following:

1) Is it really necessary to include recommended type, region, ident, theta & rho in an IF leg? According to the SDK, they are optional parameters, and I guess FS2004 does not do anything with them. Have you observed otherwise?

2) Do you get the missedAltitude value from the charts? Or is it just a guess of some 1000-1200 feet over the altitude value (I mean in the heading of the approach code, before the legs, correspondig to the FAF)?  (I can't find that value in the LEMD approach charts)

3) Shouldn't the last approach leg (TF or CF to the runway threshold) be a "flyover" point?

4) Is there in reality a difference between a "waypoint" and a "terminal_waypoint"? I can't identify as such in the LEMD approach charts either, is it just a gimmick of FS2004?

5) Does the parameter "gpsOverlay=YES" do anything in FS2004?

Thanks a lot!
Joaquin Zafra
www.fshispanic.com

[jvile]

Joaquin

A simple rule first

The entire Approach data is written for a GPS reciever that is for the User Airplane.

Inside that rule are 2 areas

1. Some of the element statements are not used but the real world GPS requires them.
2. Only certain portions of the approach data are used for the AI Plane behavior

Quote

1) Is it really necessary to include recommended type, region, ident, theta & rho in an IF leg? According to the SDK, they are optional parameters, and I guess FS2004 does not do anything with them. Have you observed otherwise?

No, those elements are not a requirement and that is why you will see 2 different decompilers leave cetain elements out of the decompiled IF xml.

Quote

2) Do you get the missedAltitude value from the charts? Or is it just a guess of some 1000-1200 feet over the altitude value (I mean in the heading of the approach code, before the legs, correspondig to the FAF)?  (I can't find that value in the LEMD approach charts)

Yes, I get the missed altitude from the Jeppesen charts (upper right hand corner) that gives the published missed approach procedure in writting. To answer the rest of the question I will use an example from KMSP ILS 35 which you can get the chart from Airnav.com and compare.

<Approach type="ILS" runway="35" suffix="0"
gpsOverlay="FALSE" designator="NONE" fixType="TERMINAL_WAYPOINT"
fixRegion="K3" fixIdent="LORAH" altitude="4000.000F" <---Approach altitude assigned (ATC) to a target point between FAF and IAF or beyound for AI/User Traffic Final
heading="349.00" missedAltitude="5000.000F"> <----------------------------------- Missed approach altitude that is assignd both AI and User from ATC

What is important is how the white lines are drawn for the missed approach in the GPS receiver. I am sure you have studied the white lines that the user plane will fly when the GPS toggle switch is locked to the autopilot NAV button. If you write the approach/missed approach correctly for the user plane the ATC coding will use what is required for the AI Traffic. You can leave certain element statements out of the Approach xml (as and option) and it will compile ok. However, even though there is enough information needed for the ATC engine to properly fly the AI Planes to the runway there may not be sufficent information to draw and connect the white lines for the User GPS receiver.

I accomplish 2 things that may not be important for your LEMD. I want the User Plane Pilot to be able to fly the approach through the GPS reciever (as per the current approach charts)  and the AI Traffic to behave properly. You can do either one or both in the xml by what element statements are written (inserted)  or not written.

Certain element statements are not important or do anything in what type of 2 letter approach code (IF(theta, rho) but are very important in other type 2 letter codes which is used to place the arrow at end of the white line that is drawn. Example

Published Missed Approach for ILS RWY 35 at KMSP says

MISSED APPROACH: Climbiing left turn to 5000 via heading 240 degrees and GEP R-182 to LYDIA INT/32.6 DME and hold 

Now load up FS9 and go to KMSP with my files in the proper folder. Using the default GPS 500 (expand to full window size) right click once on the big knob and 3 times on the small knob to bring up all the approaches and the white lines. PUSH CRSR and rotor down to ILS 35 and ENT. Zoom in look closely at the dashed lines starting at the threshold of the runway which is the missed approach. Notice the first dash line has a arrow at the end of the runway before the left turn. That is the following  <Leg type="CA"
<MissedApproachLegs>
<Leg type="CA"
altitude1="1599.981F" <------------------------- Longer or shorter distance will change distance of the first dashed line arrow before the left turn.
altitudeDescriptor="+"
magneticCourse="346.5"  <--------- Runway heading or a small offset to the left of runway center line
turnDirection="E" /> <------------ Not important because I am going to RUVCE which is "L" LEFT.      "E" Either is not honored

<Leg type="DF"
altitude1="0.000F"
altitude2="0.000F"
theta="0.0000"
rho="0.0000"
flyOver="NO"
turnDirection="E"
fixType="TERMINAL_WAYPOINT"
fixIdent="RUVCE"
fixRegion="K3"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="RUVCE" />

I used RUVCE to get me out to the GEP R-182 radial and then a left turn to LYDIA INT. Notice the theta and rho are 0.0000's. You can also draw the missed approach dash lines with the theta/rho element statements if the holding pattern and getting there has no waypoints or VOR/NDB fixes to work with. Simular to holding in the middle of nowhere based on a radial from a VOR with no waypoints. These type holding patterns are usually associated with remote airports like the Falkland Islands that only have a VOR/NDB to work with. 

The rest is self explanatory . Fly to LYDIA (TF) and hold (HM) at LYDIA INT on a magneticCourse="002.00"  for a time="1.00"  minute and turn turnDirection="R". All that also comes from the Jepp approach chart in the main graphical body.

<Leg type="TF"
altitude1="5000.000F"
altitude2="0.000F"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
magneticCourse="0.00"
time="0.00"
flyOver="NO"
turnDirection="L"
fixType="WAYPOINT"
fixIdent="LYDIA"
fixRegion="K3"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="LYDIA" />
<Leg type="HM"
altitude1="0.000F"
theta="0.0000"
rho="0.0000"
magneticCourse="002.00"
time="1.00"
turnDirection="R"
fixType="WAYPOINT"
fixIdent="LYDIA"
fixRegion="K3"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="LYDIA" />

None of the published missed approach is used for the AI Planes. By default they make a turn and are vectored back to a seperation point for Final.

HOWEVER, there is a way to control the AI Plane on which way it turns on a missed approach. That is hidden in some of the <Approach type="ILS" runway="35" suffix="0" main body xml before the first (IF) statements which is nothing more then a "vectors to final" default (Novice Pilot) approach.

Look once again at the Approach Heading to the runway and ATC assigned Missed altitude. 

heading="349.00" missedAltitude="5000.000F">  Notice I set the approach heading for Final at 349.00 degrees but AFCAD for KMSP says base runway heading is 168.5 True/166.2 Mag. Calculate theta and you get 348.5/346.2. Runway Heading of 348.5 is less then (in a radius turn) of the AI Plane heading on Final which will be calculated at 349 degrees.

What this does is makes the tail of the airplanes degree radius value less then 180 between the runway heading of the plane on final and the approach heading. End result is I have all AI Planes turning left away from the parallel 12/30 runways which simulates a proper left turn missed approach as per the ILS 35 Chart.

I hope you got all that !!!!!!!

I will finish up on the other 2 questions in the next post. Need to give my brain a rest for a few moments.

[jvile]

Joaquin

Back again

I don't like making long post because people loose interest in reading. I never did put together a tutorial on all this and as you can see it may not or I don't have the ability to write all the "if" "and" "or" thoughts (in my brain) that FS9 has to work with in the Approach data.

On to your next question

Quote

3) Shouldn't the last approach leg (TF or CF to the runway threshold) be a "flyover" point?

Does not matter. The approach at this point is straight in from the IAF to the FAF to the Runway. By default that is waypoint to waypoint to runway.

"flyBy"  is normally for a turn at a waypoint such as a GPS/RNAV Transistion Approach or holding pattern. You want the User Plane to anticapate the turn and start it before the waypoint. FS9 does a great job by calculating the speed of the aircraft to start the turn sooner or later so the rollout heading from the waypoint is precise. 

"flyOver" is very precise in approaching the waypoint and used more for VOR/NDB type approaches where the plane has to fly a precise over the VOR/NDB then outbound leg with a procedure turn back to final.

Quote

4) Is there in reality a difference between a "waypoint" and a "terminal_waypoint"? I can't identify as such in the LEMD approach charts either, is it just a gimmick of FS2004?

Yes. Lets talk Terminal_Waypoint first. Any blue triangle symbol (excluding VOR symbols) seen with the GPS receiver are Terminal_Waypoints. If you add a waypoint to LEMD or I add one to KMSP it looks like this

<Waypoint lat="44.6666442129399" lon="-93.1793528787232" waypointType="NAMED"
magvar="-1.70" waypointRegion="K3" waypointIdent="SSTAR" />

That is a Terminal_Waypoint and will show up as a blue triangle. Why? Because it was nested under the Airport Header in the xml Approach data file we are writting and it specifically is owned by that airport IDENT code (<Airport ident="KMSP") ONLY !!! That Terminal_Waypoint is only used by KMSP for some type of NAVdata and in my case is the IAF for ILS RWY 35 and it is not shared with other Airport IDENT's.

A Waypoint which is the pink triangles (using the GPS receiver for viewing) is a shared waypoint for NAVdata and is not embedded under the Airport Header. A Waypoint is fixRegion="xx" specific which means it is in another scenery folder other then the APnnnnnnnn.bgl and can be used as a NAVdata intersection for multiple airports in that same Region Code.

You will see the same thing for NDB's. Some NDB's are Terminal_NDB's nested to a Airport Ident such as a outer marker beacon for a airport runway.  When you open AFCAD and look at NDB properties, if the Terminal Box at the bottom is checked by default and a Airport Code is in the Box that Terminal_NDB is in the APnnnnnnn.bgl under the airport header. If the NDB is shared or used for navagating from one point to another then the property box at the bottom is blank/no checkmark and ghosted because it is in another scenery folder for shared purposes.

Think Terminal_Waypoint = Not Shared with other airports
Think Waypoint = Shared with other airports 
 
I have never used a Region Coded Waypoint and don't think we can make one. Everything we make are Terminal_waypoints. You would probably have to decompile the file that houses all the Waypoints and then add a new one and recompile. I have not even tried to see if the BGLCOMP compiler schema understands this.

Quote

5) Does the parameter "gpsOverlay=YES" do anything in FS2004?

Yes. If you say true to a VOR type approach that you write it attaches in ( ) small letters somethimg like this VOR(GPS) as seen with the GPS receiver.  Here in the USA we may have a VOR non-precision approach that we tune with the NAV radio but the Approach Chart also may say the GPS receiver can fly this approach for you as a GPS approach so we overlay the GPS to the VOR approach. This is becoming less common because of RNAV and GPS approaches are more precise. In the past we may not have trusted the GPS receiver so that is why it is a VOR approach first with a overlay of the GPS. RNAV approaches should actually have a GPS overlay but I just write both approaches which are identical and change the  <Approach type="GPS" or "RNAV"  to give the user airplane a preference. I can also write Transistions that can differ between each type approach.

There are approaches in the default FS9 database that still use the GPS overlay.

Let me give you some "food for thought"

Writting approaches is not all about plugging in numbers. You have to have a plan and think through what it is you are trying to accomplish. It is best if I use an example of my thought process to satisfy every entity of an approach procedure.

Go over to Airnav.com and get the approach charts for the ILS 35 and RNAV 35 for KMSP. The ILS RWY 35 shows 3000 ft for the FAF but notice in my other post I used 4000 ft. The IAF STARR shows 5000 ft and this is the default "vectors to final" both the AI and User plane will be given by ATC . 

You have to think through all the different AI Plane FDE designers out there that only concern themselfs with how the plane touches the runway and rolls out on landing. I harden all the different descent rates of these unstable AI Planes by adding to the hardfloor of the FAF. We know that the AI/USER plane is going to be vectored to final somewhere outside the FAF and inside the IAF if no other planes have taken the first seperation target point. I choose 4000 ft for the descent altitude to final not 3000 ft. which also helps if the AI Planes sink rate is unstable. Many times these unstable type AI Planes will pass through the hardfloor and not recover causing them to land long before the threshold of the runway and taxi along the ground. Of course everyone wants to blame that on MSN and not the AI plane (FD's) someone designed. 

Now you see my thought process for the AI Plane to be vectored to final at 4000 ft outside the FAF but look at the RNAV approach Chart for RWY 35. Hhmmm GPS overlay (GPS) but I went a head and wrote both a RNAV and GPS approach with Transistions. Pay strict attention to the LDASH Transistion with a holding pattern at the JOSAV IAF which is also directly inline with the STARR Terminal_Waypoint IAF "vectors to final" for the AI/Novice plane approach.

The Transistion is for 4000 ft but ATC is going to clear you to LDASH from your present position if you ask for this approach. I coded ATC to descend the user plane to 5000 ft prior to LDASH and then once inbound to the hold at JOSAV it is the pilots discretion when to descend to 4000 ft. If the User Airplane pilot stays at 5000 ft when he enters the hold he is above the AI Planes that are on final by 1000 ft with no conflict. Once the User Plane Pilot (while holding)  knows no more AI Traffic is turning final he can descend to 4000 ft., exit the hold and once inbound from the IAF (JOSAV) contact Tower for landing clearance.

The computer and the xml that we write control the AI Plane. The User Plane is a real person flying in a simulated world of AI Traffic. My goal is not just to plug in the numbers in xml but think through  how the User Plane is inter-acting with ATC and be able to maintain seperation if the User Pilot selects a professional approach to the runway rather then the Novice/AI Plane approach. These are 2 seperate entities in the approach database and require a thought process to keep the guy that downloads my Active ILS airports happy. 

Just another way to help the User Pilot and the computer AI Pilot from having a conflict on sharing the same ILS runway.

     

[jzax]

Jim,

Thanks a lot for your detailed explanation and the time you put to it! I really appreciate all your comments

Re the missedAltitude value, I think I had a misunderstanding, because I was using some kind of "guess" always below the chart required FAF altitude, but you use the altitude for the missed approach hold point, which is of course what it should be!


To capture a VOR radial, I am using the VR or CR, or sometimes CI/VI to intercept the radial (next leg in this case). As an example I coded as follows one of my missed approaches in LEMD:

<MissedApproachLegs>

<Leg type="VI"
       
        magneticCourse="145"
altitudeDescriptor="+"
        altitude1="2400F"
/>

<Leg type="CF"
        fixType="NDB"
        fixRegion="LE"
        fixIdent="GE"
        flyOver="FALSE"
        recommendedType="VOR"
        recommendedRegion="LE"
        recommendedIdent="BRA"
        theta="222"
        rho="38535"
        magneticCourse="222.0"
        distance="38535"
        altitudeDescriptor="+"
        altitude1="5000.00F"
        />   
 

      <Leg type="HM"
        fixType="NDB"
        fixRegion="LE"
        fixIdent="GE"
        turnDirection="R"
        magneticCourse="48.0"
        time="1.00"
        />
</MissedApproachLegs>

And the plane does turn to 145? until it grabs and follows the radial 222 from Vor BRA to NDB GE which is the holding point.


Regarding flyover/flyby, I think I read somewhere that the only flyover point (if any) should be the RW or the MAP if it is coded, but I do not remember where, although it was a real-life document. It works either way of course in FS2004. I was just curious if there was a real-life rule here.

Thanks also for your clarifications about how FS2004 defines "waypoint" and "terminal waypoint". I only found out that if I coded a "terminal-waypoint" only as "waypoint", sometimes I did not get the leg drawn at all in the GPS. Now it is clear why.

Also very interesting to see how you tweak the values to adjust for AI behaviour in FS2004. I have just tried the heading tweaking to make the AI plane at least turn in the right direction in go-arounds (in LEMD), and it works perfectly! Quite a nice discovery!
I have to experiment a bit more with your smart altitude tweaking in order to fly through the AI forest!

Once again, thanks a lot for your comments, and your KMSP is a jewel!!

Regards

Joaquin

[Lupo]

Jim

A lot to digest!!
Being slightly behind in the learning curve I'm still hoping for code definitions -- I do know how needle in the haystack something like that can be so whenever you come across it is fine.

In looking at the missed approach data for runway 35 I noticed that the value for magneticCourse= is 0.00 in the Fly to leg. So I am I right in thinking that because we're pointed at the waypoint, that value is not needed?

Still catching up here!
John

[jzax]

John, I sent to your msn mail some description of legs I had, hope you find them useful

regards

Joaquin

[Lupo]

Joaquin

Thanks for the file! Helps to clear some things up!

John

[jvile]

John

Quote

In looking at the missed approach data for runway 35 I noticed that the value for magneticCourse= is 0.00 in the Fly to leg. So I am I right in thinking that because we're pointed at the waypoint, that value is not needed?

Correct because I am using a "type = DF" or "TF"  not a " type = VI"