Can't remember the A32X, but I'm sure that PA28-Warrior did NOT fly over TP after a missed approach,turned left prematurely and continued to PPD. I've actually verified that TP is marked as "fly-over"in the procedures xml file. Why the short-cut then?

The missed approach procedure ends in a hold over ABRAG. Neither A32X nor PA28 were able to enterthe hold (although it was correctly drawn on the Equipment->Map and A32X's ND. After reaching ABRAGthere was no active waypoint in Route Manager and in both cases the planes were heading SW.

Are my expectations overestimated, is there a generic FG AP problem or is this an IT-A related issue?Many thanks for your opinions/responses...

IT-AUTOFLIGHT does not support holding patterns as of now. Support it planned to be added only to:* IDG-A32X* IDG-A33X* IDG-MD-11X

I have no plans to bring that to the core IT-AUTOFLIGHT at this time.

As for actually flying the SID/STAR, Wecsje does it all the time on VATSIM, as IT-AUTOFLIGHT now has predictive turning, and takes crosswinds into account. So, they fly relatively well.

Keep in mind that while IT-AUTOFLIGHT is 100% custom, it still use the Route Manager for route management. The course calculation is custom. The planes mentioned above will have a custom route management, so that problem will be solved, again, I don't plan to backport that to the core as of now.

But what about the 'fly-over' waypoint?Is it possible that your course calculations may ignore the 'fly-over' property?I can confirm this behavior for PA28 (I guess it also uses IT-A), but will verify for the bigger beauties (A's and MD's).

Please do, I verified and confirmed that behaviour also with your A320.This is my missed approach procedure I performed today (same chart as in my orig post at the top):After a MA the procedure says to climb and maintain RWY heading until D271J and then turn left back to PPD.However, IT-A realizes that it's easier to turn back immediately even though D271J is designed as 'fly-over' waypoint.

Another problem:Exactly the same (premature turns) happens for 'fly-by' waypoints. Is there (IRL) any requirement for a max distance from a fly-bywaypoint where an airplane must get in order to mark it as passed?I can provide a screenshot, but look at the approach plate from my orig post above (STAR on pg. 5 and approach on pg. 7).

Navigraph's data almost perfectly copy this approach:after you pass EPEDA, continue to PPD, ABRAG, then there's a fly-by waypoint at 9.9 DME PPD, turn back to ABRAG and track ILS.

However, after passing PPD and ABRAG, IT-A realizes that 9.9 DME PPD wpy is useles, because the next wpy is ABRAG again.So it skips that wpy and turns ABRAG as the next wpy.However, we're still very close to ABRAG so IT-A also marks it as passed and turns the next wpy LZTT RWY 27 ILS as active.The result (very unrealistic) is that the airplane turns around immediately after ABRAG and takes course directly to LZTT.I know that 9.9 DME PPD waypoint is marked as fly-by, but IMHO the plane should fly reasonably close before turning to next wpt,shouldn't it??

Josh (and other guys at IDG) , don't get me wrong. I know these are very marginal situations. But I consider your planes foralmost perfect (at least for my needs) and would like to make them completely perfect (if possible, of course) by reporting suchmarginal issues...

Hi,Don't worry. It's on the list of things to do, but we are waiting for the FMGS/MCDU work to further, as there is a FLYOVER key on the MCDU, where you can tell it to fly-over.

In the mean time if I get spare time, I will see if I can get a quick and dirty fix to check this, providing that the Route Manager knows fly-overs. If it does, I can add that easily to IT-A and thats all thats needed.

It will be added, but not quite yet, as there are more important things at the moment to do.

Wecsje wrote in Sun Jan 21, 2018 11:02 pm:The routemanager knows nothing... Yes, it can read simple sid's and star's from level d data. But it doesn't recognize transitions, and on an airport like EBBR it decides to just not work completely

At EBBR it doesn't work because runway 02/20 is now 01/19 in reality and thus in the navigraph file. You have to either modify your apt.dat (replacing EBBR lines with current rwy layout) or modify your EBBR.procedures.xml so that every instance of rwy 01 or rwy 19 is replaced with 02 or 20.

This is the same for any airport which has changed/added/removed runways or rwy numbers.

- it also knows about transitions, if you enter an enroute point in the route manager and then select a SID or STAR, it will pick the matching transition automatically if one exists. if the first/last enroute point is not a transition point, we use the closest transition point I think. (Will need to check - there's probably bugs to be found in this logic as well)

- there's unfortunately nothing we can do if the data for procedures doesn't match our runway definitions - in that case (such as EBBR) you have to fix the procedures XML data until we update the main nav DB I'm afraid

For the default 'GPS' which is what most people mean by the autopilot, which tries to fly the route, turn anticipation should arm within 2nm of the waypoint for fly-by waypoints, and the WP should sequence when passing a line where the bearing the to the WP is perpendicular to the direction of flight. I.e exactly half-way through the turn when turn-anticipation is active.

(The 2nm distance can be configured by aircraft in the GPS /config/ property section)

Of course if the aircraft is suing a custom GPS/FMS implementation the turn-arm, waypoint sequencing and turn-anticipation logic will be different.

BTW, it's always easy to add additional FlightPlan APis in Nasal if requested, eg to manually select the transition or to toggle the WP fly-by / fly-over type (actually this one already exists), just send a request to the development list and ideally some test data / test case using the UFO or default AP.

Hi,We use non default AP,The course has corrections for drift and such, and it calculates turn anticipation so it gets in the line for the next waypoint. Its working very well. Good to know the underlying system is supporting it. That means when the custom nasal flight plan is released, and the route manager is removed, it will support it.