Aamir

I'm not sure what it has to do with ProSim - regardless, try changing the display render modes you're using.

Unfortunately you cannot build a tolerance for which you do not know the severity. Generally a full "fix" would be to completely remove this sub-sys and prot, which for obvious reasons we don't really want to do. The wind shifts in MSFS can be as violent as -100knts to 0 to 100knts in a millisecond if it so desires. Sometimes not so severe. Depends on the day.

If you had wind shifts IRL as you do in MSFS, you'd be hearing about it on the news 🙂

It was for both, really. Atm with people coming over to support for spurious disconnects, it's either 1) Wind shifts kicking the aircraft into A.Prot, or some other reason the aircraft has entered A.Prot 2) Turbulence setting on anything higher than LOW 3) Noise in joystick sensor (or rudder!), kicking off AP 4) Too small a deadzone on either rudder or joystick Right now the reports seem to be isolated to people with the above, as far as I've seen so far anyway.

Flap 3 is a valid take off computation, especially when optimising for TOPL as the EFB does. Some other airlines do not use this optimisation and instead optimise for other factors - hence they never land up with F3 takeoffs. To say it is a bug for providing the computation is probably a bit far. I will do a bit more research into the actual behind the scenes here, however. SRS guides you to V2+10, the system does this in the background whilst speed target remains at V2, so visually it "looks" a little weird but the FD is not guiding you to that speed. You can see it here:

This work is only possible thanks to your patronage funding our continued development efforts! For this, the team and I thank you greatly 🙂

I think you'd be surprised how quickly an A320 can stop IRL with max manual and a light load.

I can tell ya this much - circuit breakers are infinitely more complex to add than an interactive checklist. The latter can be accomplished in about a week. The former, probably 3-6 months depending on how much inherent complexity the aircraft already has. If background system logic is "simplified" then add rewriting all that code on top so it actually functions correctly, which takes you into the "years" side of things.

Please bear in mind all I said was "appropriately gusty" - in this case I mean severely gusty, something I imagine in the real world you will encounter probably a handful of times over your entire career. This, for obvious reasons, can happen more often in MSFS than the norm.

Correct, there is one exception you can observe on the Fenix as well - which is when the conditions are appropriately gusty and the ATHR is oscillating a lot attempting to keep VApp. Then the recommended course of action is to disconnect ATHR and handle it yourself.

A support ticket with a general description as above and your logs attached is a good place to start - but I would also give it a go with display sync ticked off. Display sync doesn't play nice with RivaTuner, MSI Afterburner, or Frame Gen mods - so eliminating those is also a good place to start if you do really want to use it.

Have you sent in a support ticket?

We've seen a lot of speculation around the textures being the 'culprit' for bad performance since Block 2; so far our investigation has found several code-side items leading to poor performance on some systems, which we be doing our best to address. On the other hand, we've yet to find a scenario where lowering our already very low texture memory usage makes a measurable impact for any of those reporting lower performance than Block 1. To this end here's some hard numbers to help visualise just how efficient Block 2 is in terms of resources: PMDG's 737 has 421 cockpit textures totalling 709MB, of those 4 are 4k. Fenix A320 has 142 cockpit textures totalling 271MB, of those 4 are 4k. To put the above into perspective, the default A320 NEO as shipped uses 235MB of textures for the cockpit - we're using just 36MB more. In fact, Block 2 actually falls within the stringent memory requirements to be shipped on XBOX if we so wished. Beyond textures, our drawcalls are significantly reduced compared to Block 1, and in-line with other aircraft even though we have a significant amount of extra interactive items such as nearly 300 circuit breakers. Our cockpit is a little under 4000 drawcalls 'at scene' compared to the 737 which has about 3700 'at scene' - there's not much in it. When you get towards CPU-intensive aspects of the art like bone animations, we're also doing pretty well here, using 238 bones to the 737's 396. Ultimately, numbers are meaningless if the performance isn't there, but I wanted to clear up any misconceptions that we've just "thrown more polygons and textures" at the A320 for Block 2 - the reality is in almost every measurable way we've done the opposite, and utilised some seriously innovative tech to bring that level of visual quality whilst keeping within the aforementioned XBOX budget. Beyond the bigger code-side performance bugs, we're continuing to investigate every aspect of the product to make little nip and tucks to eek out as much performance as we can across a variety of systems.

Brakes are particularly interesting to me. I worked out that someone would need to do 7 landings per day, for 365 days straight - before the brakes need to be replaced - that context makes me think of implementing these things.. differently 😃 Or, alternatively, someone doing 1 landing per day would wait 7 years before replacing the brakes, provided they never missed a single day in those 7 years. Either/or.

Planning on this and more - but it's a long term plan and with some other spice thrown in. With that being said, no promises as usual 🙂