Aamir

I checked with the support staff on this one - it happens when your throttles aren't calibrated in their detents properly. A couple of suggestions would be to run the throttle calibration again, or widen the detent nullzone so that the detents themselves are larger. I'd recommend starting with 4% and going from there.

It isn't for copy protection - it runs all the systems for the aircraft.

If you retract the flaps near to their overspeed limits with the red band, and the aircraft is still accelerating, there is a FWC delay to triggering the overspeed warning while the flaps aren't locked in position despite the red "overspeed" marker disappearing.

I would currently ignore most, if not all, the engine behaviour. We are building an external engine model to better simulate this stuff.

I do a bunch of production stuff so the other CCD is still quite useful for me!

A couple of videos from a user of the 7950X vs. the 7950X3D on a payware airport w/ the Fenix. https://youtu.be/wUjXsoG4xkk https://youtu.be/xSWO4dSfag4 A fairly decent uplift of 20fps or so, with a 4090 and more than 1080p, so there are some gains to be had. Definitely have one of these chips on order myself! 😄

TO CONFIG will warn you, yes, but it's not automatic, needs a button push. Been working on other areas of the aircraft recently so can't remember exactly the conditions and associated warnings.

I do not believe there is an alarm that chirps, or if there is, that is a function of a newer software standard afaik.

Progress on the IAEs is progress on the CFMs. Why build all this infrastructure only to not use it for CFMs also? They will go through the same extensive update, but without the time sink of building the framework and integrations after we're done with the IAEs.

Two for one - we can build a framework which can apply backwards to the CFMs and we can bring those up to a really superb standard also. A321 and A319 have different engines with minutely different characteristics, but this will allow us to dive into those at a higher level also.

Early into the project I had a decision to make, which was namely - do the IAEs quickly or do the IAEs properly. There wasn't an option to go in-between - I mean, we could have thrown it into the MSFS FDE and hammered it into something "acceptable", in that it looks like an IAE, the values would be close-ish, but it would more or less stop there. There would not be a lot more depth, the startups would run on a script to emulate the rough character of an IAE start, we'd script in some timings for spool etc to make it all tick over and call it a day, fuel flow etc would be okay-ish, much like the CFMs, perhaps within 10% of a margin. After all, most had already purchased the product and commercially it makes little sense to go out and try and push the boundary because.. well, frankly we weren't going to get paid for it. So doing the bare minimum was probably the most efficient, commercially rewarding option. With that being said I also recognised that people pay us to go out and find that last tenth. I daresay that's what our customers would expect. So I made the call to go for the hard option. Do it properly. As much as being the director of the company forced me into considering the commercial impact of this, there's something to be said for taking appropriate care and responsibility in maturing a product that, ultimately, customers are invested in. Maturing a product in software takes time, it doesn't matter how many resources you throw at it. An experienced project manager will probably tell you adding too many resources and just throwing bodies at the problem is likely to exacerbate the problem more than speed anything up, too. We've not yet even crested the 1st anniversary of our very first product being out in the market. PMDG, for example, launched their first iteration of 737 in 2003, they'll be celebrating 20 years of that thing being out there in some form or the other, before we celebrate our first - as an example. That's a lot of time to refine, renew, rewrite, etc - and as you can see it's a superb, mature product for it. That latest post that @polosim quoted was from a couple of months ago, and since then we've prototyped the engine model in it's steady state, it's working fine and flying around, we're reasonably happy with the fuel flow and what not. That's the easy part. The real challenge lies with modelling transient states of a turbofan. For example, programming a startup is less script and more physics based. For example a thermal model for EGT cooldown and rise during shutdown and startup is crucial given the IAEs motor the engine if EGT > 250 degrees when start is commanded, so you need to model the air mass effects of the motoring and how the air driven by the fan blade spinning cools the engine, to add to that, you need to accurately place the EGT probe for the actual sensor as the sensor itself isn't in the engine core, so if you stop motoring the engine the temperature fluctuates accordingly as heat transfer changes depending on airflow. If you dry crank a hot engine (right after shutdown), due to where the EGT sensor is (hint: the exhaust), the core will actually blow hot air from the core outwards and backwards over the EGT probes so you end up cranking the engine and the EGT rising for a very short period of time, before cooling. Those EGT probes are over by the exhaust strut, quite far from the core, so on shutdown the EGT reading actually shows it being quite fast to cool as a result, too, however not before slightly rising as the N1 fan and N2 rotor stop spinning and thus providing some airflow over the probes, so there's a little temporary spike. You cannot get these details right on a simple simulation. This is before you start thinking about starting or shutting down an engine mid flight, as the fan windmills at 24,000ft. A whole different ballgame there, but there are a number of startup modes in that case, assisted starts, unassisted starts, depending on the N1, which depends on speed, alt, pressure, etc, which then in turn affects how the engine behaves for all parameters on a start. Even down to the oil. IAE engines do this signature oil "gulp" when they start. Oil goes down then back up during a start. We know that, but why, and how much? We can't just fake up data and call it a day. We need to understand why and model it's effects otherwise the model will fall apart. This effect comes into place because the oil pump is attached to a gearbox which is N2 driven, as it all starts turning on a startup the quantity of the oil tank starts decreasing for a little while because the scavenge flow from the bearings must travel through several pipes and then back into the tank. Related to N2, so the effects on N2 on a start will affect this also. All of this without modelling the pesky EEC and things like the IAE's Keep Out Zones, where the FADEC will flat out refuse to stablise the engine at between 60 and 74% N1 due to fan flutter, which is a whole other kettle of fish. All of this data, absolutely all of it, we've gathered on the real deal. A level-D doesn't give us this much insight and data into what/why/when/how. We needed the real engine to show us what we needed to know. This goes beyond most pilot's comprehension of their equipment, so it's not like it's knocking around in anyone's head either. This is a tiny, small slice of insight into what building a model like this entails. There's dozens upon dozens of little snippets like this that make up the entire thing, and it's safe to say building it is an incredible challenge, even just from a data acquisition, management and organisation front, forget about the actual legwork of coding the thing after the fact. I hope from the little extract above, you can gather why this is taking months of work. But when it happens, it'll be worth it. We wanted to build it because it's frankly just flippin' cool. Forget all the commercial implications, at the end of the day it's satisfying building something you can sit back in your chair and go: "Dang..", after all, we're enthusiasts all said and done too..

We removed it as we incorporated the same level of memory saving into the core texture set, so the current VC set is for-all-intents-and-purposes the "low" version from a memory perspective, just with better optimisation so the resolution doesn't suffer.

Oh, and just to add on as the edit button isn't working.. If anything, I've acknowledged issues with our product's OEI performance and explained our problems with them. Not sure how it could be read otherwise.

It's a free forum. We are here to have a discussion. Your last remark aside, my comments have only been talking about what we do, not what anyone else does. Nowhere have I said or claimed any sort of direct comparison. I'd welcome you showing otherwise. In fact I have so far only responded to people talking about the Fenix 🙂

I agree!

I'm not saying it's impossible. I'm saying there are alternative ways to do it. PMDG have already done theirs, we are doing ours.

Well, this is categorically incorrect. We've released 7 updates, including large scale FM changes, VNAV being remath'd in its entirety, entire soundscape changes, visual model changes, ground friction changes, and building in new Airbus software functionality, to start.

You can have a correct climb profile on both engines, or overpower them and have better OEI performance. We had better OEI performance, the masses complained the airplane was too powerful, so we reduced the thrust to 1:1 match the climb data when both engines are running. Not enough granularity in the MSFS engine model for us to achieve enough accuracy to satisfy both sides of the aisle, so we satisfied the normal use case whilst developing an external turbofan physics engine to achieve both targets.

You're splitting hairs. In the real world, pilots don't download anything to anywhere. Pilots show up to the airplane and hit an uplink button on the FMC. You don't send your flightplan to the Fenix via the EFB. You show up to the airplane and hit an uplink button on the FMC and it pulls it over "datalink", as it would IRL. What's the issue?

There's a "next page" button over at the bottom somewhere.

Discord is an optional community area. Customer support is offered via the usual ticket system if you want to reach support directly.

A very common complaint from (even IRL pilots) transitioning from a Boeing to an Airbus is "it's wobbly", due to PIO (pilot induced oscillations) - this mostly happens as a result of misunderstanding the principals behind flying a fly by wire Airbus. Generally, if you try to fly it like a Boeing, you'll have a fairly terrible time. A helpful thing to remember would be that your stick inputs alter the flight path, instead of thinking about it actuating aileron/elevator. Bump and reset. By this, I mean, when flying the aircraft manually, nudge the stick in the direction you want the airplane to go, and let it center again. Observe what it does. Then put in another input. If you become practised at this, you're bumping, centering, bumping, centering, bumping, centering - while pausing in between to quickly assess the flight path of the aircraft. All this, with your fingertips. The painful way to fly this is to "stir the porridge", i.e you're wiggling the stick around off center all the time, flying it with your "wrist", trying to stay on top of the airplane. It doesn't like that and you'll find yourself wobbling around all over the place. Let the fly by wire work for you.

Active pause is very weird in MSFS, and can break a lot of stuff. Would recommend using the pause from the dev menu instead!

Hey! We include 6 wingviews/cabin seat views by default, but MSFS orders the cameras in a pretty special way: camera dropdown > internal > instruments > scroll down to find all the included wing/cabin views.

A video would be good, for sure, just so I can have a look. With that being said, some common things to check based on the initial report: 1) Make sure your MSFS icing is switched off, we don't play nice with this (for now). 2) Make sure you're not using toolbar pushback, it leaves a tug attached to the nose and the airplane wobbles around all over the place. 3) If you're using FSRealistic, make sure you've got the "low altitude turbulence" setting switched off. If all those are as they should be, then a video would be great to see where the issue may lie.