Jump to content

holland786

Members
  • Content Count

    89
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

462 Excellent

2 Followers

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. This is realistic considering the engine performance, at some weights.
  3. The stuttering issue is being worked on, but fixing it requires entirely rewriting a big component of the aircraft, so it will take a bit. We also have multiple display optimisations in the pipeline, which should improve general frametimes too. @NoelRegarding your routing issue, this is also known and will be fixed. However, there is an element of this particular routing situation that is still unknown to me relating to how the real aircraft handles this. So I am waiting on more confirmation from pilots.
  4. Did you get any error messages or would it simply stop progressing ?
  5. After a lot of testing with two kind and patient users on Discord (who suffered through the dozens of different files I sent them to test), we have potentially isolated a major stutter problem to a particular area of the code. We are evaluating what we can do to mitigate the issue as it impacts something non-trivial to fix.
  6. Did you delete a discontinuiity ? This is not routing I'd expect in a valid flight plan.
  7. Important to note that this is also not really an ideal path which you would keep IRL either. Airbus LNAV does not do anything magical with sharp turns, if it overshoots, it's not gonna try anything clever.
  8. This is an unfortunate issue resulting from a change we made in the update. Sorry about that.
  9. After further evaluation with @JimBrown, their issue is not what this build aims to fix unfortunately. This build is an improvement on constant frametimes, (mostly) not random stutters, which is what I assume you have too. I'll be looking into the other issue, but for now I have got no lead.
  10. Would you be willing to try the test version and provide feedback regarding performance?
  11. If you do try the test version, please report back your findings. Multiple users have been offered this test version and have not given any feedback regarding performance, which is very much needed. To everyone else - please remember that you are using an aircraft in alpha stage.
  12. The ND is the Navigation Display of the A320. A software rewrite is done when code that needs a large restructuring for feature/performance reasons is completely redone from the ground up. So what is happening, is that I'm redoing the navigation display code to use a more efficient way of rendering it, which is one of the things that will improve stuttering. It might not fix your specific issue entirely (it might for others, and it might for you, what I'm saying is that many things can cause it so no promises made), but it will certainly alleviate things. And over time, as more things are redone in more efficient way by the team, those issues should disappear - especially as the plane approaches a v1 release.
  13. Hi, we are aware that this is an issue, and optimisations are always being worked on, but as the aircraft is still in alpha they do take the backstage sometimes. However we are getting close to being done with the ND rewrite and this should help the situation a bit.
  14. It will improve as the aircraft is optimised.
×
×
  • Create New...