holland786

Could you try out the Stable version and see if there is any difference? Are you on the SU15 Beta? And are you using DX11 or DX12?

Almost, it's actually a difference between the Thales and Honeywell FMSes. So either behavior is right for both ceo and neo, as long as it's consistent with the FMS version used in that particular product. In this case, it is correct for both since Fenix does the Thales FMS and we do the Honeywell FMS. Note that the A380 version of the same FMS behaves like Thales, even though Honeywell produces it.

I don't think this is quite completely true, the quote I've gotten from pilots is that it doesn't work well, but I'm sure it's used a fair bit. I did however hear that intervention is quite frequent though. BTW, VNAV is more than managed descent. It provides more accurate predictions and extra symbology on the ND.

Glad you found the performance to be good. It's been an area of focus recently and we are going to bring even more optimizations going forward. it is much easier for us to optimize things now that we have a somewhat established idea of how we want to structure the aircraft's code and approaching three years of experience developing for MSFS😉 I'm currently working on a major, commonly requested feature for the A380 that involves very complex display rendering and animation - and performance has been my #1 priority since the start. So we really do want to bring all of you the smoothest experience possible. It is a challenge to do that in Alpha, but we try our best!

Out of curiosity, what's wrong with the LNAV? While I'm obviously biased as having developed large parts of it, last time I checked it is one of the only LNAV systems that properly model the real life capabilities and limitations of the FMS - other sim aircraft trying to fix every path no matter how broken an inserted flight plan is - which does not occur in real life on an Airbus. The only flaw I can think about right now is the excessive TAD value during path capture turn generation on some leg pairs. Other than that, I have myself compared it with the real plane and they both mess up in the exact same spots.

Keep in mind the A32NX models the Honeywell FMS computer while Fenix has the Thales version. One of the differences is that Thales creates temporary flight plans for more modifications than the Honeywell one does, which will often let you delete stuff without confirming. Either versions could be on CEO or NEO in real life.

Did you try this recently? Curved DTO paths have been in for more than a year. This is how this FMS works in real life. DME arcs are fully supported, but keep in mind both aircraft use different navdata sources. It might be a navdata issue. Do you have navigraph data installed in the base sim?

I have attempted to contact you to get you to test various builds for a while now with no answer... There is also no "bubble" to "burst". We are not under the impression that this will fix all problems. There are other fixes on the way, and so far the feedback is much better than we anticipated.

You need to post the error message if you want a chance of someone being able to find the issue.

That is absolutely our goal. Since we have recently ported the last screen (apart from the MCDU) to be entirely comprised of our own code, it is now much more practical for us to optimise them.

This is actually in the development version now. Sorry, forgot to notify. Btw, most of the fix is by Eearslya#7831 on our Discord, to give proper credit 😉 I just did the original investigation and prototype.

Not sure yet, I think some of them will go straight to dev. They are currrently not in any version.

We currently have 4 performance related changes in the pipeline, including one related to the largest stutters (200+ ms spikes). The other ones focus on improving intra-frame performance (which target general stuttering as opposed to addressing stutters every 20/30 seconds). The fix for the 200+ ms spikes is being finalised as we speak and has recieved positive feedback so far. here are some: https://github.com/flybywiresim/a32nx/pull/7698 https://github.com/flybywiresim/a32nx/pull/7776 https://github.com/flybywiresim/a32nx/pull/7736

No - until AAU1, the data required was not available in the sim. This is now possible and will come with FMS v2.

The airbus FMS selects a few algorithms to generate LNAV turns based on multiple conditions, like the type of routing at play (DME arcs use a different algorithm than for example). Sometimes, this condition is that a prior algorithm failed to generate an appropriate turn (too big, overshoots, too tight/wide, etc.) In this case here, a "path capture" turn algorithm is used, which while not uncommon, here begins way too early along the leg. There is in fact a leg between EBOMA and the next waypoint which I can't make out the name of (CI25 maybe?) but the turn generates so far away from the end of it that it is completely cut off. Turns generating away from the very end of a leg is normal, since the aircraft needs distance to complete the turn, but here, it is excessive. This algorithm is quite simple. Its only goal is to turn to intercept the next course at a 45 degree angle - if you look close, here, you can actually see that the massive line going into the void (part of the turn) is stopping when it intercepts the approach course. This issue actually happens in the real plane - albeit at a smaller scale and generally only in unusual scenarios, like when the speed exceeds the limits designed for a procedure. We have experienced it flying an A380 simulator out of a SID from which this kind of traffic does not depart. My guess here is either: a) that a discontinuity was deleted when it should not have been. This looks like maybe a TF -> CF turn which would never happen in a correct procedure at that kind of distance. Deleting discontinuities is effectively telling the FMS to compute things that could be geometrically impossible with the simple-ish algorithms the Airbus FMSes employ. b) that a normal turn was generated at a too high distance due to the A32NX not yet accounting for speed predictions when computing turns. this is being worked on, but effectively means that some turns could be computed with 400 KTAS in mind when it will really be flown at 200 KTAS. This can have very large effects.