Aamir

1 hour ago, Krakin said:

The refresh rates I'm getting on all screens is atrocious even when I'm in cruise and the fps is high. If I turn nobs, I sometimes have to wait 3 seconds for the numbers to change. Basically anything that uses prosim chugs.

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

34 minutes ago, BWBriscoe said:

Well then the Fenix tolerance of wind shifts needs to reflect the platform it's decided to put itself on...

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. 

Just now, BWBriscoe said:

It was a very windy day over Europe. However, I can't believe in real life there are hundreds of Airbus A320s suddenly having their AP disconnect because of a little wind. It seems the tolerance of the Fenix needs to be higher.

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. 

4 hours ago, SierraDelta said:

There’s an acknowledged problem with the SRS not guiding you to V2+15, but only V2. I,ve seen this on a few flights, but the team is looking into it.

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 🙂 

1 hour ago, jcomm said:

Another nice vid @Cpt_Piett !
 

it raised a complaint I still have regarding most aircraft in MSFS2020, specially the airliners and in particular the Fenix A320 - the highly unrealistic stop distance on landing.

Your approach and landing were conducted at the preconized speeds, yet the aircraft, even considering you used "manual braking", stopped incredibly fast - way too fast ...

I'd like to know what causes this behavior, and I believe it is more likely related to the not so accurate ground physics than with the efficiency of thrust reverse and / or spoiler drag because I also experience it in prop aircraft.

Braking efficiency is way overdone on most MSFS 2020 fixed wing aircraft 😕

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

On 3/21/2024 at 12:02 AM, Noel said:

How so?  Explain exactly why a circuit breaker is more difficult to program.   

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. 

Just now, polosim said:

Let's say that this is not entirely correct, in cases of SEVERE TURBULENCE it is recommended to proceed according to the dictated by the Abnormal list described in the QRH. This applies to what @Aamir  says, in some phases of the flight, except for approach where the same list mentions that the Autothrust must be turned on and must be used in managed mode. 
In conditions of strong winds and gusts, the use of autothrust is highly recommended to take advantage of the Ground Speed Mini system.

he Ground Speed Mini function takes advantage of the aircraft inertia when the wind varies during the approach in order to provide an appropriate indicated target speed (i.e. the managed target speed represented by the magenta triangle on the PFD). When the flight crew flies this indicated target speed, the energy of the aircraft is maintained above a minimum level that ensures standard aerodynamic margins versus the stall. The minimum energy level is the energy level the aircraft will have at touchdown with an indicated airspeed equal to VAPP, and with the wind equal to the tower reported wind as inserted in the PERF APPR page. The ground speed then equals the Ground Speed Mini. The Ground Speed Mini is not displayed to the flight crew. During the approach, the FMGS continuously computes the managed target speed in order to keep the ground speed at or above the Ground Speed Mini.

I hope this information serves to clarify some doubts about the use of the auto thrust.

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. 

1 hour ago, martinboehme said:

In fact, it's Airbus philosophy to leave autothrust on for manual landings too, though some airlines have a "manual flight, manual thrust" policy (Lufthansa is one, I believe). 

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. 

Just now, carlito777 said:

Not yet. Actually, I don't know where to start. Sometimes the sim crashes moments after hitting "Ready to fly". Sometimes before. Then, in some cases, I can enter the cockpit but the screens are all just blue. There is no clear pattern. I tried loading the Fenix app before starting MSFS, but also tried to let MSFS load the app. This also sometimes works and sometimes doesn't. I eliminated all add-ons in the community folder except for the Fenix. Also wiped the exe.xml. Installed the newest AMD display drivers, etc. etc. I tried nearly everything in the past two days but can't get it to work reliably. Today, I was able to do one flight, but then it crashed on final. And as I said: With other add-ons, I have no problems.

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. 

1 minute ago, carlito777 said:

Great to hear that all of you are enjoying the new version. On my system, it just doesn't work. Keeps crashing all the time. If I replicate the scenario with another aircraft, then no problem. Must be the Fenix. Used to be one of my favorite add-ons in v1, but v2 is just useless for me. Too bad.

Have you sent in a support ticket?

16 hours ago, aniiran said:

The Fenix has never performed as well as the PMDG 737 series.  But I think it really depends on the scenario.  The Fenix and the PMDG do about the same at iniBuilds LAX, of course the frame rate is low to begin with.  At a minor airport or stock airport the PMDG has a significantly better frame rate, it always has.

I have noticed a bit of a performance penalty with the IAE model specifically, but not with the CFM...   strange.  I think one of the differences is that there are no 4k repaints.  I never use 8k liveries always 4k, so for me I think that has something to do with my stuttering in the outside view and wing views.

The cockpit textures seem sharper to me, maybe they are 8k now as well?

I get a new system soon so all of this won't matter.

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.

9 minutes ago, Fiorentoni said:

I'd like to have a chance to have this occur before the first flight, at least as an option (like on the Maddog, PMDG, A300 etc.). This makes checking these items more immersive, and it's also not uncommon in real world to have the oil refilled during preflight. I'd consider that a part of normal operations. For the rest I agree with you.

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 🙂

2 hours ago, Fiorentoni said:

EDIT: That said - I'd except a persistant state (oil, hydraulics, tires, brakes) for a high quality product like a Fenix. I hope it's on their list; any other study level addons has this.

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". 

57 minutes ago, Cpt_Piett said:

I had a few disconnects yesterday - unfortunately both on go-arounds after flap 3 landings. I guess the AoA Prot submode kicked in as I always have trouble managing thrust and pitch on a go-around. 

 

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

21 hours ago, abennett said:

Again, the Aircraft is all working great, apart from the announcements, but nothing Fenix related showing in task manager....

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?

50 minutes ago, cyyzrwy24 said:

While I haven't had any major problems with V2 (once AP disconnect but recovered with Stick movement), my concern or question perhaps is that I have not used Rev Thrust once....?! Not with V1 or V2. I would be using AB, either LOW or MED and I would always be able to slow down at the exit I planned to get out, It seems that once I start rolling, brake "intensity" or force is only what is required. Even on runway 7000 ft long. Not sure that is correct but would like to hear what is your experience. I am watching Live plane spotting on YT and there is not even one Airbus that have not used TR. What's up with that? Is that MSFT issue or I am doing something different.....? Or Fenix....? bit odd I would say.

With PMDG it is exactly as it should be. Unless Airbus AB system is much stronger and enough to slow down plane without use of TR.... would like to hear different opinion....Thanks

 

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. 

2 hours ago, btacon said:

Howdy Aamir.  Amazing upgrade…one for the record books!  Question:  Frame Gen Mod or just FG enabled in sim?

Thanks and congrats again Team Fenix!

-B

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.

Just now, abennett said:

Awesome thanks. Yeah it seems very weird, haven't come across many people with this issue. Just can't get this GqlGateway to run, I found it in the Program Files Directory and tried to manual start it by clicking, but just doesn't want to run...

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.

49 minutes ago, abennett said:

If Aamir sees this and has a moment, wonder whether he might be able to give me a quick advice on how to get the Fenix.GqlGateway to run and also show in volume mixer?

I’m not getting any announcements sounds because it either isn’t running, or when I can see it running in task manager it still doesn’t show in sound settings and so I still don’t have any announcements sounds.

 

Thanks

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.

20 minutes ago, JaneRachel said:

Loving the update..

A couple of things I have noticed. The aircraft seems to often spawn at the gate with the gear up and promptly slams in to the ground, requiring me to go back to the main menu. I have tried Heathrow and Manchester, same result. It is not every flight so looking for an obvious cause and will report back.

A slight bump on the taxiway and the aircraft sometimes goes a few feet in to the air, even at very low speed (just had this again at the payware Manchester a few seconds ago).

I keep getting repeatedly asked to enter DEST data in the MCDU, even when already entered (I saw this on the previous version also)

Pedantic, wishlist item - button repeat on the MCDU pls so I can scroll through the flight plan etc by keeping the button pressed as per the real unit 🙂

 

Fantastic work guys. Such a lot of hard work here that is appreciated by many,

 

all the best

Jane

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. 

6 minutes ago, BWBriscoe said:

Thanks. I'll try this. 

This was never an issue in V1 and I have done some flights in V2, so unsure why it's suddenly a problem?

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. 

9 minutes ago, BWBriscoe said:

On loading up I have a white ND and upper ECAM. Can anyone help? I didn't have any problems with V1, but since the update I seem to have a bug on every flight.
Screenshot here...  https://imgur.com/8ChAe06

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

2 minutes ago, JYW said:

This does not work. There is only dark mode available.  (He's not referring to the Navigraph map.  On the Navigraph page of the EFB, there's a small link that says "None Navigraph users. Click here (limited functionality)".   If you click there, there is a nice map.  But it's always on dark mode and hard to read in daylight.

I have forwarded to my EFB team.