Amazing GPS (A) at Palmer, AK

[betelgeuse 41]

I've been testing AI behaviour at PAAQ in FS9 with a default Dash 8. The only published IFR approach at PAAQ is a GPS (A) approach to Rwy 34. I set visibility to 2 nm, wind 330/8. I ran FS9 for approx 15 minutes before the approach was scheduled to begin. The plane approached the initial approach fix (IAF) (I think CF008) on a southerly heading at around 5000 ft. The FP was 5000 ft for a 50 nm flight. According to the approach plate the altitude at this point should have been 2500 ft, so it was far too high. (I know that AI planes do not follow the published data too well). The plane then made a curved approach to what I think was the final approach fix (FAF) at ZUYEB but at this point it was still far too high (3700 ft instead of 2500 ft). It then made a left descending 150 degree turn away from the airfield back towards the IAF. This brought it back on track at around 1500 ft. It completed the approach by making a smooth left turn on to finals and finished with a perfect flare! Wow! I ran it again with the same result. I thought all AI pilots were dumb. Now I want the plane to do this in VMC and this is where I need help. In the decompiled APXXXXXX.bgl am not sure if I can just change the

[jvile 1]

JohnThere are many circle to land approaches in both FS9 and FSX that the AI Plane honors. The problem is most User's do not know this because they fly with visibilty above 3 miles.The ILS approach is the prefered based on a score regardless of weather. What that means is many never see the exotic approaches that are part of the AI Engine/plane behavior. When weather falls below 3 miles and no ILS exist then the AI Engine starts looking for some kind of non-precision approach. There is a pecking order that is used so as the AI Engine starts looking down through the Approach XML it looks for the next lower type approach below a ILS such as a LDA. If that does not exist then it looks for a GPS or RNAV. ILS being the highest score and NDB (no DME) being the lowest on the list.In your case the AI Plane was given the GPS A approach and if you look at the approach code you will see the approach heading is not aligned with the runway. When visiblity is less then 3 the AI flies the first part of the GPS A which has all the data needed to approach the airport at a altitude and heading that will cause a circle to land.The trick is with clear weather the only type approach honored is the ILS in all weather so you have to make the GPS A think it is a ILS Approach. This can be done by changing the first part of the GPS A code to resemble a ILS code. The AI Plane will now be cleared for a ILS by ATC which does not exist and it will actually fly a circle to land in clear weather. This is the fundamental code that I use for all my exotic clear weather approaches such as the IGS 13 at Kai Tak.

[betelgeuse 41]

Thanks a bunch for replying, Jim. The ILS coded version of the GPS approach worked and I watched in awe as the Dash 8 did its thing in VMC. I added the ILS proc instead of substituting so that I kept the GPS (A) for the user plane.I noticed that there are two transitions for this approach at PAAQ, one beginning with fixType="VOR" fixIdent="BGQ" Altitude="3999.951F"the other beginning with fixType="TERMINAL WAYPOINT" fixIdent="OWGAT" altitude="3999.951F"I think I am right in saying that these data are used for drawing lines in the GPS and that when coupled up to the auto pilot the user plane will attempt to fly the designated route. I assume that the above are for GPS or vectored approaches selectable by the user pilot on the GPS. Is this correct? Do AI planes use any of this or do they always go straight to the IF (=IAF)? I get mixed messages about this from different sources. Finally, assuming I do not create any new waypoints, do I always need to add the default waypoint data when I create an ILS approach from a GPS or VOR approach? In other words does the use of DeleteAllApproaches = "TRUE" make the base waypoint information unavailable?

[jvile 1]

Transitions are not part of the ATC code for AI Planes. AI Planes only work with the first part of any approach such as the part you changed for GPS to ILS. All the transitions are for the User plane. The User can ask ATC for a Transition and then Load/Activate as a option so the GPS will lock to the autopilot and fly the transition if the User does not want to do it manually.All Aproaches are written for the User Plane not AI Planes. What FS does is reads certain lines of the approach code for the AI Planes.Example <<<<<<<======== AI Plane climbs to this altitude The AI Plane does not use the IAF, only the FAFNothing below this part of the XML is for AI Planes. User Plane uses all the approach code which draws the lines in the GPS so the User can ask for the approach/Transition and follow the lines or load/activate and autopilot will fly the approach.If you don't make a T_waypoint leave all waypoints in the base file.If you make a T_waypoint leave all waypoints in the base except the one you made.FS is smart enough to read the originals in the base and then add your new one in your XML. FS will now combine them for you.If you need to move/tweak one of the original waypoints then copy it up to your XML. FS will use the one in the XML and you can move it if needed.If you copy all the original T_waypoints up to your xml (ADE V 1.20 is doing that) FS is smart enough to see all the waypoints in your XML and will not load the ones in the original base folder. FS again understands all the originals are in your compiled xml at a higher priority so it will not duplicate the waypoint in the GPS receiver. Its your option at this point and FS handles what way you do it without any type deleteALL=.deleteALL Approach is for approach code and works the same way as T-waypoints (almost).You copied the GPS-A and changed it to a ILS. You wanted to leave the original GPS-A for the User Plane and that is 100 percent correct. You now have an approach just for AI and one just for the User.You did not need to copy all the approach data from the base file up to your XML because you did not change anything. You 'ADDED TO' the overall database and FS will combine all the original approaches to your new XML GPS-A/ILS that is now in your XML.If you have to change something in the base Approach code then you have to copy ALL the Approach code to your XML. Now you rewrite the approach code in your XML. Here is the catch!!FS does not know how to read only the approach code in the XML like T_waypoints. FS will now read and duplicate every single approach in the GPS Reciever and list it twice. We need to tell FS that the original Approach code we want to use is in a higher priority and only use it.deleteAllApproaches="TRUE" tells FS to block the base original and only use your new code in your xml. Now the GPS reciever only list the approach one time and list all approaches only once.Some areas of the base XML code can be brought into your XML and FS knows how to automatically block the base code (T-waypoints)Some areas of the base XML code has to have a deletall= in order for FS to block the base code and use your XML code.Am I making sense here?There comes a point you start to realize that you can write approach code just for the AI Plane, just for the User Plane or for both type planes and ATC is smart enough to work this out for you.In my FSX KMSP approach code I have the AI planes as per ATC descending to 2000 ft and then a extended 30 degree turn to final (RWY35). The User Plane is told by ATC to descend to 3000 ft and hold at the IAF. The USer is 1000 ft in hold above all AI Planes that pass under him as per ATC. This allows the User to space himself properly before attemptimg the final approach and if done properly never gets a go around by ATC.If a User ask for the right Transition at my FSX Kai Tak some of the same type code is there also so no conflicts occur with AI and User prior to the IGS 13. You can set the ILS circle to land approach altitude (what ATC will instruct) to whatever suits you within reason and set the User GPS-A altitude to what a chart says. If you change the GPS-A Approach that now differs from the stock base approach then copy all approaches into your XML and use the deleteALL attribute. Go To PAUN and it also has a circle to land approach that the B737 or a B757 will use and work because the runway is long enough. Add some parking spots with ADE version 1.20Once you see how FS is writting the circle to land approaches you can add them to many mainstream airports that have a circle to land approach as per charts and AI will honor it in VMC if you tag it as a ILS.

[betelgeuse 41]

Wow! I realise this knowledge can only have been learned the hard way (trial and error). There is a lot to digest! I will go through it bit by bit and check your approaches again. Especially where you have coded for separate ILS (AI) and LDA or GPS (User) approaches to the same runway e.g. VHHX Rwy 13. With ref to my previous post, I watched in awe as the AI pilot did his ILS approach in VMC. Trouble is that it in no way resembled the GPS (A) approach he did so well in pea soup. In clear skies he did a high straight in approach, went missed, and went around endlessly. This was the flight: I set the altitude to 4000 ft in the 'approach type' coding header and my FP to 5000 ft for a 50 nm hop. In VMC with 'ILS' coded, on departure from the airfield of origin the AI plane climbed to 8200 ft ASL on a southeasterly heading. It stayed there until it was within 10 nm of the airfield (high terrain to the south). I tried a flight from the south heading northeast with the same result - 8200 ft ASL always! When I ran the flight in low visibility with GPS(A) coded the AI plane honoured the altitude settings in the FP and although it did not honour the altitudes specified in the code at BGQ, OWGAT, ZUYEB, it performed a very realistic GPS circle to land approach. Tracking was near perfect as per the FAA approach plate.Is there any way of knowing the lat/lon values where the default 'approach type' altitude (3999.971 ft in this case) is honoured by an AI plane? I assumed that this point was the IAF and that it could be coded for AI. You may already have answered this in your post as there must be a point before FAF which can be coded for AI. BTW, it seems you are now using FSX - I assume all your information and xml coding applies the same to FS9.Again, many thanks, Jim. I cannot wait to get the hang of this. It's time to give something back for all the help I've been given by you and others. John H

[betelgeuse 41]

JimI've been testing non-stop at Rwy 34 PAAQ. I have learned a few things. My comments are solely concerned with AI approaches in VFR i.e. ILS approaches.First, altitude appears to be hard-coded for terrain clearance in IFR FPs. This seems to take priority over code in the

[betelgeuse 41]

Hmm.....I re-tested the .bgl attached in the .zip file in my previous post. The AI plane (Dash 8 default) now fails to land on Rwy 34 - it goes around ad infinitum! This is exactly the same file which produced good landings yesterday. Weird. Back to the drawing board.

[jvile 1]

Different AI Planes behave differently.Are you using TTool FP's or something written with the TDBB type FP's?

[betelgeuse 41]

AITM - which as you know uses Ttools.exe. I've been using the default Dash 8 for all testing. Two days (and nights) of tweaking have failed to produce anything worthwhile. The only thing I have been able to do is to induce a rapid descent to the runway on a straight in approach after a go-around. This worked a few times and I thought I was getting somewhere. Then today, even this was not reproducible. It seems I am light years away from a VFR version of the curved GPS (A) approach which the Dash 8 performs flawlessly in low visibility. No matter what I do the plane flies along at 8200 ft until it hits the default IAF (?) on the straight in approach. Then it plunges earthward in a futile attempt to land. If AI planes do not use any of the 'Leg type' data how are they able to follow LDA or GPS approaches accurately in low visibility? I am confused.

[jvile 1]

Is your FP IFR?What Altitude for the Dash8 is compiled in the FPHow far is the departure from the arrival airport.What is the highest elevation between those 2 airports.AI Planes do not use legTypes. FSX generates what I call target points during approach outside the FAF. These can be seen with TrafficToolBox and every target point has several key desired vs actual values. The AI Plane as per the AI/ATC engine is told by ATC to change headings toward a target point. In that target point is also a altitude the AI Plane must descend to. When the AI Plane reaches the 30 degree turn to final it should be at the FAF Altitude.These same type target points are also used for the User plane on the approach to a airport based on vectors to final and altitudes assigned.

[betelgeuse 41]

Thanks. I use FS9, not FSX. >Is your FP IFR?Yes>What Altitude for the Dash8 is compiled in the FP7000 ft>How far is the departure from the arrival airport.50 nm>What is the highest elevation between those 2 airports.Depends what you mean:4675 ft ASL as the crow flies. 400 ft ASL when the AI plane flies the route in visibility less than 3 nm (i.e. the GPS (A) approach).7500 ft when the AI plane flies a default straight in approach in VMC. John

[jvile 1]

John I took a look at PAAQ. The first problem with the stock GPS-A is it is not written for a circle to land or a proper GPS approach. The last TF leg points to RWY 34 and this confuses the approach code. The last TF leg MUST be a Terminal_Waypoint and not A RUNWAY. This is why you are seeing the AI Dash 8 fly or not fly the approach IMC or VMC.The GPS approach resembles more of a LDA approach but with no room for the left turn to short final.I rewrote the GPS-A approach at PAAQ but the DASH 8 did not behave or honor the approach properly. I went to PADU which has a properly written GPS circle to land approach and FSX is not working the way FS9 worked.With weather set to IMC, no AI Planes would ever see the runway code. It appears that in FSX, SP1 or in SP2 the approach code is being distorted and causing AI Planes to fly past the airport at mid center point of the runway. I am still testing some of my GPS visual circle to land approaches I wrote for FS9 but it is starting to appear that FSX has some runtime issues in this area as well as other areas. We do know that many parts of FSX did not get worked on but Runtime errors crepe into the code because of other updates (runway flattens, etc.)EDIT*******I have been testing PAAQ/PADU with FSX. I need to go back to FS9 which you are using.

[betelgeuse 41]

Thanks, Jim. I will also test PADQ Rwy 30 in FS9 with various planes. I am still confused about the thing. It seems from what you say that the GPS code must be written correctly in order for AI planes to honour a fake 'ILS'. On the other hand, in low visibility the circle to land approach to Rwy 35 at PAAQ works beautifully with the Dash 8 every time. I wonder why MS used a non-standard GPS code at PAAQ? Is there something in it which could be used other places?John

[betelgeuse 41]

JimAn update. In FS9 at PADU AI planes fly the published GPS (E) approach to Rwy 30 when vis < 3nm. I re-wrote this code for an ILS (E) and saved it as a new .bgl in FS9......scenerygenericscenery. I have a batch file for errors and the .bgl compiled/parsed correctly. The user plane GPS shows the new ILS (E) approach but AI planes (Dash 8; Cessna Caravan) do not honour it in VMC. The FP is IFR. I am not using: Maybe this is my mistake.