Aamir

I mean, it does take all of 10 seconds to do this - all you have to do is have it installed on both systems and when you want to use a different system, log into your account on the website, go to settings and click RESET LICENSE. Run it on your new PC. Rinse and repeat each time you change system. https://kb.fenixsim.com/license-reset < for more information.

Not a problem, sorry for the inconvenience!

There is no hotfix. The latest version is 1.0.5.139. Umberto was in this thread earlier giving us some more explanation on this, so we will amend it once again. We have disabled the brake temperature simulation when we're told pushback is occuring, but there seem to be exceptions to that case where other variables are triggered to 1 and we need to disable the brake temperature modelling also. We will add this. For now, instead of waiting 15 minutes for the overheated brakes - head into MCDU MENU > MAINT > FAILURES, hit the CLR button on your MCDU and select the line with Brake Temperatures. It will clear the high brake temps instantly.

Interesting! Yeah, do let me know if it happens again and ideally a video would be great to assess what's going on.

PATH TOO STEEP is just a message. It does not have operational ramifications, so you can just ignore it. As for AP disconnects, there's nothing we have done to change any logic there other than change the amount of travel needed for a Disconnect and made it larger. We usually find in 99% of the cases that the AP disconnects in MSFS are caused by significant wind shifts, dumping the airplane into (or lower than) VLS - or an errant control binding that will cause/hold an input. There are also Airbus "gotchas" where in several cases the aircraft will NOT engage the autopilot. For example, it will not engage the autopilot if there is a control input currently active. i.e you cannot hold the stick left and engage the AP at the same time. You also cannot engage the autopilot whilst below VLS. If below VLS, funnily enough, your airplane will also enter TOGA LK, slamming in thrust. So, if you hit one of the numpad buttons to change view for example, MSFS also has that bound to trim or elevator, can't remember which. This will put an input in that will disconnect the AP.

It's bound to AUTOPILOT OFF in MSFS, so assign the button you want to this binding and use that as the AP Disco. Not needed, it's already been seen and acknowledged in development updates channel, Dave's Updates. Will get it fixed shortly.

If you own a hydraulically damped Airbus sidestick. So, something £2000+, think Brunner or the likes. Meant to go in a proper FTD or something like that.

For those in the SU11 beta - please don't expect a fix in the immediate short term for the displays - we expressly do not support beta builds of MSFS because they pretty variable. We will, of course, investigate the display issue internally, but we will not be rushing a new build out to support it until we know more.

Ok, thanks for that - I'll make the required changes and disable the brake simulation for all these cases too. I'm not too worried about the brake simulation being switched off during Active Pause, at least on first glance. I'll see if any unexpected MSFS'isms occur when we do this, though. I respectfully disagree. We are unequivocally not making changes to make the aircraft more accessible and non-frustrating. We're making changes to the aircraft to make it more realistic and true to the characteristics of the actual thing. At the end of the day, FLARE moved backwards instead of forwards in the last couple of updates due to unrelated changes in flap lift - this had a knock on effect. We could leave it be and just go: "It is what it is, deal with it.", but that's not really in the spirit of continued forward development. Things will change from time to time as we learn more about MSFS's aero engine that will allow us to exploit and find more areas we can bring our virtual airplane closer to the real beast - in this case it moved backward at first, then forwards. All said and done about wind changes and whatnot, mea culpa. But I would rather make these changes than just live with something that is a sub-par experience. Here is a nice overview of how Blackbox, a type rated line captain on the A320, feels about the latest changes: https://clips.twitch.tv/EnchantingPopularVelociraptorSoonerLater-Ry3uTevTWCjnHrM0 At the end of the day, I appreciate the basic sentiment of your message, however. Thankfully, we don't plan to change FLARE much past what we've done now. I think it's in a good spot now.

If it needs to slew the aircraft for any reason, it will. Currently we disable the brake simulation when the GSX pushback is detected. If the pushback is completed and during disconnect if the aircraft is moved for whatever reason, it'll eat your brakes up. We'll look into how to avoid this, but for now you can go into MCDU > MAINT > FAILURES and hit CLR and select the brakes, it will reset your brake temperatures.

Lovely to hear, many long nights spent getting it right. Now it's done we can move on to some of the fun stuff!

Will be added in time. Had to spend the resources elsewhere these last few months!

Hey! You can do either, so feel free to just download the file, and run it. We'll take care of the rest.

The reworked lights are cool, if you manage to find some nasty weather. You can actually see, if you look closely, that the volumetric "effect" shows that the strobes aren't one bulb doing two flashes, it's actually two bulbs doing one flash each, one after the other. Loved this video during one of the beta test flights I did. https://streamable.com/a65xs1

We do not use simbrief downloader for anything.

I mean, this is just a classic example of why we absolutely point blank refuse to give any sort of loose timeframe for anything - despite it being prefaced with "attempt to" - I've asked him to go back and put that word in bold for now.

I don't know who the someone is but as far as we're concerned we've never shared any concrete timeframes. "As soon as possible" is the answer. Would highly recommend reading my post just one page prior.

Should be Feb.

I don't think you guys are understanding what I'm saying. Instead of words, I guess I'll take you guys down the debug journey for this issue and let you take a look for yourself. Here are the issues: 1) Apparent wing stalls in flap full config when landing at the MCDU's computed VApp, usually with offside wind, or you're doing BIG bank angles in flap full config. Video: https://drive.google.com/file/d/1Q0-0Yed4eryUNH_PDRKRKRwAT3L-Iv6b/view?usp=sharing You can see the right wing basically just give up. 2) Complete sluggishness of the aircraft's V/S in relation to pitch change. It's important to note here that the pitch change itself is satisfactory, i.e - the you pull back on the stick and the pitch does change. Your V/S does not. This leads to landings where you flare the aircraft and it feels like nothing is happening - leading to hard landings. Video: https://drive.google.com/file/d/1TfTPzUdUyXNhGX7GIsjGZZxvScTnjsWm/view?usp=sharing You can see for a given pitch change of nearly 5 degrees, the V/S doesn't contract at all, or maybe by 200-300fpm. This is inherently incorrect. I exacerbate the issue in that video by coming in high and hot, and attempting to change the pitch quite strongly, just to observe what the aircraft would do re it's inertia. Nothing, is the answer. -- The first thing to do is understand the mechanisms at play when you pull back on the stick. If you pull back, you increase AOA. This increases lift, which increases FPA. As a result, V/S will increase. Variation of AOA is equal to variation of FPA at a given speed, so V/S is geometrically tied to FPA/AOA variation rate and TAS. So when we report that "pitch change" (which is equal to AOA and FPA change in the short time) doesn't change V/S - we are immediately confused. But this says to me, let's go back and check our "by the numbers" claim re lift. So we checked 2 extreme gross weight variations (both ends of the spectrum, heavy and light) for its AoA in sim, and we were matching the real values in each flap config. So CL vs AOA slope and positioning seems correct. CL vs AOA is linear, so two ends of the spectrum are "good enough" for testing. We then checked the stall AOA according to the flight manual and we were also correct. So now the confusing part. Seems to be that lift is technically fine "by the numbers", so what on earth is going on? You have to then recognise that in Asobo's engine, certain characteristics like drag are cumulative between flap positions, whereas others are not - and the internal engine does what it wants from the value you set with no transparent logic. Now, there is logic behind it, but we are completely blind on how it works. In the deployed FM, we have verified correct CL vs AOA slope at each flap position and correct stall AOA as above. Drag has also been painfully tuned to get correct Flap 2 drag, which was really quite wrong in .104 (old version). Now, drag is a hidden computation via the lift and camber entries so anything related to "tweaking" the drag is not easy - you can often find when you are happy with CL vs AOA, that the drag is completely off because of the camber input needed to achieve this "perfect" CL vs AOA... It's a bit of a nightmare to get it all in line with official performance figures and tuned correctly - but we're there based on the results from testing. So, that's great. Then why is the airplane non-responsive to pitch change? This is a very confusing result if one assumes the physics engine is a "perfect" recreation. Let's go back to a real world video to observe what an A320 does. Super helpful video - and it confirmed how reactive the V/S is to a pitch change in a relatively low energy state. Much much snappier. But then, if we’re “by the numbers” - why isn’t ours doing that? Instead, your stick inputs seem to be going into a bowl of porridge... Weird question, and here we were stumped for a while. Then I reinstalled .104 with the incorrect flap drag/lift values. Felt responsive! Just like the video. A quick comparison was run and .104 has, basically, slightly higher than “by the numbers” lift on flap full. So, I requested a small “lift bump” on flap full in our deployed version. Just to assess what it felt like. Less than the wholly incorrect .104, but within a sensible realm - a couple of %, if that. Here’s what it looked like: https://drive.google.com/file/d/1kZnsHfk4ZAm6osV1UqR96lq_7lTm5fFi/view?usp=sharing Delightful. And what you’d expect. V/S is nice and reactive, not overly so. Looks about right compared to the video vs. what you’d expect in “stick feel”. But not, absolutely, utterly, infallibly “on the numbers” - however you can see, visually, the difference in V/S. It’s not a small difference. And the only change is a small bump in flap full lift when slower. Your end result: AOA vs. CAS in flap full. Blue is the real world. Red is Fenix. The result of this small lift bump is that you’re now 0.3 degrees off in AoA at 175knts. You're probably around 0.1-0.2 degrees off in the phase we're discussing. The ones you don’t see a Red marker for? That’s because it’s absolutely and directly nailed to the Blue engineering/IRL data. Yes, those are the margins we’re talking about when it comes to “on the numbers” vs. “off the numbers”. 0.3 degrees at max. That’s what we talk about at Fenix because that’s the standard we’re looking for. We’re not hiding it under a margin of error or something, even though we probably could - and would get away with it. Admittedly, it does bother me somewhat on a personal level that most assume our product is simply inferior due to our open communications policy about what is and isn’t perfect. We’re happy to admit when something isn’t 100% correct. That doesn’t mean it’s 100% incorrect. You will find these sorts of margins or frankly likely worse in most developers claiming to be “on the numbers”, because I can tell you this - even a Level D full fidelity simulator with a multi million dollar datapack isn’t 100% perfect. Pilots will absolutely tell you it “feels” different. It may, however, hit the numbers. Hell of a lot closer than the rest of us, sure, but still not perfect. And that’s probably because the computational power to recreate absolute, infallible, real world physics for flight in real time doesn’t exist. Much less on your home desktop, on a game engine. So you make little nips, tucks, and adjustments inside of a small margin to get the desired behavior. We will continue to push and change things around so that we move toward that "perfect window", I'm sure there's more for us to learn with this new and evolving aero engine. Tbh, we could have probably left it alone from .104 and just “accepted it”, but that's not why any of us spent 2 years reworking and building upon the ProSim base. Certainly would have been the easier and more fiscally “sound” route - as time is money, and we’ve committed lots of time to chasing 0.3 degrees of AOA. But the promise we make to you all is that we’re here to do the best we can. Sometimes things that should be a forward step, aren’t. I think that’s OK. I think that’s the price of moving forward and trying to push boundaries with respect to “degrees of accuracy”. For anyone that has questions about our approach, we try to answer any questions with transparency and fullness over on our Discord (I know most here don't like it, but we now have a forum area for verified customers that's much more conventional!).

Welllllll not really. You're basically positing that Asobo's recreation of the world of aerodynamics is perfect.

Hey Bob, allow me to summarize what we sent to you last time you enquired about this, and to give some extra information to those here struggling with landing. These issues with approach/landing/flare are a side-effect of getting the aircraft to match the real world data more closely, not by us changing tuning values to make it more challenging etc. To put it simply, MSFS has a very strange relationship with inertia/mass; it seems plausible some internal calculations were written and checked against light aircraft, and fail to scale properly to airliners. Regardless, it's fast becoming apparent that a trade-off will need to be made between how it 'feels' to fly vs. how accurate to the real world figures it is, and what makes most sense for this product. Leaning fully into "it feels really nice" will ultimately lead to unrealistic behaviour in drag/lift/performance, but likewise going full-out "it's hit all the numbers according to the plethora of real world data" will lead to issues in how the aircraft 'feels' in certain flight profiles, as you and many other users are discovering. Ultimately 99.9% of simmers aren't sitting there with Airbus engineering tables in front of them, looking for a 0.5 degree discrepancy at 12,000ft in flap 3, so there is definitely some wiggle-room before most people notice the deviation. Now as for the the delay in pushing an update that resolves a multitude of issues, we temporarily lost a couple of key devs during the last 2 weeks that significantly hampered progress. I had an unexpected medical issue that required emergency surgery, and our senior programmer's town was hit with missiles, knocking out most of the water and power. Whilst we agree the above landing issues need to be resolved swiftly, the team's health and well-being has been coming first this last week or so. Regardless, our latest internal build is now auto-landing properly in gusty/xwind conditions, pilot feedback has been much better on qualitative items such as pitch/flare, several areas of the autothrust system have been rewritten including GS mini and we've also managed to tune some better behaviour into the flaps. Provided we squeeze in the last few rounds of tuning and testing over the next few days I'm hopeful we can have an update out this coming week. In the meantime, not a bad idea to sit on an extra cushion whilst driving the Fenix.

Stick wise it would probably feel just a touch too sensitive right off-center as the real stick is strongly damped, so I'd recommend maybe a tiny starting curve and then go linear after - but I use a warthog and just leave it all on linear and have learned to fly the aircraft with my fingers and not my entire arm. You end up over controlling it otherwise. Like @Fiorentoni said - a really good way to fly the airplane (and imho the best way to do to) is the bump and reset. Flying it toward the FD, just keep bumping the controls in the direction you want to go - or nudge it. Let the stick fall to center. Observe the change. Add another input. Bump, reset, bump, reset, bump, reset. That is in normal flight. If you "bump, reset" during takeoff or the last 50ft of landing, then that's not quite going to work 😁

it's worth trying a fenix livery - sometimes it can be down to the 3rd party author setting up their configs also.

Hm, in response to this I just checked the behaviour of the app on my PC - it did exactly this, it minimised itself. The caveat is that I used the "auto-launch", so I just let it do it's thing.

Don't worry, given sufficient and appropriate abuse, you'll find yourself headed skywards again. Yessir.