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 🙂

Ehhhhh I'm not so convinced on this being the value add most seem to think - I like the general concept, but we've sort of done it in our own way. My viewpoint on this is that - realistically speaking, a line pilot and aircraft aren't going to "meet" very often. As a line pilot when you're done with the day's sectors you'll come back to another aircraft in the morning, at least in the case of short-haul aircraft like the A320. This aircraft is going to be in a "flyable" state by the time you get to it, i.e Oil is not low, tyres are "OK", so on so forth. What we've done is add some "persistence" in a way that aligns with the realistic use case of the airplane. So you come to the aircraft each initialisation with randomised engine oil, brake mass, so on so forth. These will get "used up" as you go on. If you're lucky your oil levels are good on start, and things are OK if you fly 2-3 sectors. If you're unlucky your oil is low and you'll need to call maint to sort it when you land on one of your sectors, or on a turnaround somewhere. For most other areas the failure system is MTBF - so it will fail "realistically", randomly. Obviously the aircraft are quite robust and reasonbly reliable - so it's rare, but definitely not impossible to have something or the other break. The combination of both of these things, I feel, gives you the best representation of the line pilot/aircraft experience in terms of "stuff to watch out for".

I think this is now fixed - at least in scenarios like this - will roll out with the next update over the coming days.

So, here's an interesting tidbit from debugging this with some users in Discord. Give this a go - if you've disabled any audio devices in your Windows audio settings, go ahead and renable everything - you don't need to change anything besides renabling them - let me know if they start playing? Autobrake on the Airbus targets a deceleration rate - not a fixed pressure. It will vary braking to achieve this. If you use reversers, it will simply use less brake pressure - net result is the same assuming you land on the exact same spot. You can check this in the landing app where you see a very marginal decrease in braking distance with reverse applied. EDIT: Just checked and I believe Boeings do the same thing re deceleration rate, so in theory on both you should see little to no difference with rev on/off.

Thanks 🙂 Just the mod, FG in sim is ok.

We are tracking the performance issues and sent out some builds to affected users earlier today to assess which direction we need to go. Will push this through ASAP for those of you that are suffering from degredation - but I will also caution this may not be a magic fix for every single configuration and setup - but we're actively taking in various reports and acting on them, so if the next version doesn't quite do it - keep us in the loop and we'll keep working on it. We're using some state-of-the-art modelling techniques to increase visual quality without increasing memory usage or drawcalls, but as we're the only ones really utilising these aspects of the SDK, there's a lot of 'first time' discoveries being made about the effect on some systems. With time we will improve it.

Thing is, if this isn't running your EFB is likely cooked too. So something weird is going on. We're looking into it though.

Hm, weird one - but I know Ben from our team who is responsible is tracking and attempting to fix these issues. I'll double check with him. The spawn issue we know about, trying to recreate and fix but it's a slippery one. DEST data is a correct prompt, I'm guessing you've uplinked your winds and not overwritten the already inserted wind data in the APPR page - it's reminding you to update the wind with an actual entry as opposed to an uplinked one.

We changed the default render method to the "most performant" on an average of PCs - but there are always cases where it doesn't work as well - so your old settings aren't applied. You'll have to reset them if you want them. For example, it can crash if you use MSI afterburner - I can't tell yet what causes it but I know it does cause crashing. As does RivaTuner. Both of these do not play nicely with DisplaySync. The frame-gen mod is also breaking it. Not sure how, again.

Try disabling display sync as an option in the Fenix App, and select Alternate Renderer.

I have forwarded to my EFB team.