MattNischan

The Comanche uses an external flight model coded in AccuSim and thus the sim ground modeling is bypassed.

Autothrottle, logic, and control loops are implemented entirely aircraft-side with all G3000/5000 aircraft. As a result, sim updates would not affect any change in these systems.

I can't vouch for the Horizon, but I'm unable to reproduce the wrong trim values in the 787-10, at least. Those loads and CGs produce 4.75 and 7.25, respectively, which match the FCOM.

This is how the real PC-12 is, as well. The aircraft automatically has a bit of rudder cross-control with ailerons, to make turns more coordinated without extra pilot input. I don't think this has anything to do with the realism on either platform (although the MSFS flight model is light years ahead of the FSX one). Rudder and aileron cross connect is a developer choice: it requires custom code to drive the sim to do that on any of the platforms. So it's possible no previous developer decided to implement that feature of the real plane (or perhaps were unaware of it).

This is not really the case. FSR3 comes with a bunch of different requirements than FSR2, including a totally different async swapchain implementation, the necessity to integrate the frame generation (not even present in FSR2), and a whole new requirement to split UI into a different rendering path entirely. Definitely will probably take a good amount of doing, if I had to guess, based on the FSR upgrade docs and presentation. Keep in mind that in software development land big features like this can easily take even an experienced engine programmer a few weeks to a month+ (especially to ensure the render path changes haven't broken anything unrelated), the SU15 beta starts in a few weeks, and code for big features should be well out of dev and in internal testing a good amount of time before beta.

No possibility, no. The way the system upon which these instruments is built in MSFS (CoherentGT made by a company called Coherent), this is not technologically possible.

It will indeed be possible! However, the instruments are not even vaguely similar. The old WT G3X was just a tiny mod of a very old version of the Asobo G3X, whereas the new G3X is well over 10K hours of work capturing the interfacing possibilities (with, of course, some resultant complexities) of the real unit. It's easily one of the most difficult units we've had to model to date because of it's flexibility and high numbers of ways it can be used and configured with different aircraft, autopilots, and navigators. Since this announcement was just today, I don't expect third party GPS devs to necessarily have answers to the questions about interfacing yet. I'm sure we'll end up in closer contact with them as the beta is released and progresses.

For the WT Garmins, that would be up to plugin developers. The G3000 and G1000 support SimBrief import using the Navigraph plugin. These instruments cannot read from the file system, so that method would not be possible. For external navigators like the GTN, that would be up to th developers of those instruments. The G3X is a product designed for the small sport and experimental aircraft market, so would not be found (and cannot be installed) on aircraft in the categories like the Phenom.

Well, it's gonna start with SU15 beta, which is just a few weeks away. So not much time to wait. 🙂 As sorta mentioned in the Q&A, external navigators like the GTN are going to need some code updates to those units to support the integration with the new G3X. The G3X is, without an external navigator, just a simple VFR box that supports limited flight plan operations (no procedures). However, as in real life, when paired with an external navigator like a GNS or a GTN, they can support IFR flightplans and guidance from the external navigator. Because of this need to communicate with the G3X, we are updating the MSFS Avionics Framework to support independent per-unit guidance, as well as flight plan and guidance communication between the units. However, this is not just something that drops in, developers of those external GPS units will need to implement those changes. We of course will be providing guidance to those developers who wish to do that, as well as documentation. We will be including those integrations in the GNS in SU15, as well as some options to disable the built-in WT AP in the GNS, in case some advanced developers want to develop their own autopilot just accepting guidance from the GNS.

ACES was the developer for FSX and prior, and before that the developer was BAO, and before that the developer was Sublogic.

Again, we at WT don't have any artists on staff, the art is handled by other teams. Whether or not any art issues are addressed are decisions made at a level high above our team. If you have an art issue, I would report a Zendesk. Finally, let me just preface this by saying I have the absolute utmost, massive respect for the folks at Horizon and Kuro, whom we've spoken with personally, sometimes frequently. Prior to AAU2, the systems available in the 787 mods were not even remotely as complete as they are today, missing major systems through no fault of theirs; as we were also freeware developers we know just how long it takes to develop stuff like this in just one's free time (it's truly daunting, and how far they did get is no less impressive). However, I think it's also then fair to recognize that the free work they're doing now is built on the back of something like 15000 hours of WT development time, making all of our lives (and by extension we, the users, benefit) a great deal easier. As always, specific feedback is the most helpful, and we very much take it to heart. If you have more specific feedback regarding the items you mentioned, we're always happy to look into it (as folks who provide feedback to us here, on our Discord, and on the MSFS forums will gladly attest to). But it's hard to make actionable items when the problem listed is "trim" or "brakes", for example. So, happy to hear more details, if one has them.

Sure, happy to address these issues! 🙂 For control feel, we got a lot of feedback on that from our type rated 78 test pilots. The control feel, due to the FBW, is quite surprisingly light on the real aircraft. We had a colorful anecdote from one real world pilot about during training, he was over-controlling the aircraft, and got some quick scolding from the instructor, telling the pilot to delicately, gingerly hold the control wheel more like <insert colorful private parts anecdote here>. We also got some very adamant feedback that the control carryover in the plane is basically non-existent. The plane responds nearly instantly and when input is removed has little to no carryover, but arrests the pitch or roll rate right away. So, we chose to use the manufacturer data, real world control laws, and pilot feedback to as closely replicate the actual flying experience as much as can be in a simulator. This may be contrary to one's expectations given the size of the aircraft, but we felt it important not to add artificial weight or slow reactivity. For the doors, WT doesn't handle art or have any art staff, so that report would be something for Zendesk. For the pitch and trim, the test pilots reported being able to use the settings they expect from the real airplane with the sim plane, and were especially happy with the approach pitch angle. The trim system uses the same math and FBW control loop as the real aircraft, and has identical response times (rate of change in trim speed per second). Additionally, the trim settings for the takeoff and landing phases match the documentation provided by the manufacturer. And finally, for the brakes, the braking ability was calibrated over many many hours and tests to match the manufacturer provided performance data for stopping distances. Hope that provides some insight! EDIT: Forgot to add, we were not able to reproduce until just recently the ND blank flight plan issue, despite many hours and attempts. However, we do feel we have an idea of what the issue may be now (a very tricky hardware timing based race condition based on some in-sim timings we don't have control over), and so hope to be able to fix this in a future update.

This is off-topic, but I'd be interested to hear what those might be. Keep in mind that our involvement with the 787 only began with AAU2 (we haven't been a company for 4 years yet). Our intention was never to go to the PMDG level. Instead, we wanted to provide something that could be used correctly for normal ops, with a good, featureful, and faithful avionics and navigation experience within that flight regime. Our type rated 787 test pilots give it, honestly, quite high marks given those criteria, and they had no issues using their personal flows for normal ops they use on the real plane to also operate the new 787. Yes, the aircraft is in the premium package, but the goal was never to make it a $79.95 aircraft on its own. As for the other developers you mention, a number of them are already on the WT team. So, I'm not sure sacking them would provide the benefit you imply. 😉

Apparently not this guy 😅

Really, a custom G1000 NXi is not needed. The sim stock NXi is a lot more advanced than the XP G1000 and replicates to a very high fidelity 90-95% of the functions a pilot uses on the daily. If your concern is that the avionics won't be good enough without a mod, that won't be true here. Add the Navigraph plugin and you even get full charts support, on any G1000 NXi plane. All the G1000 planes on the market use the sim NXi (except a few older add-ons that still use the original AS1000). If you want FADEC and good vis specifically, I'd recommend the DA-62 mod, which is excellent. Or, if you want a single with deep systems and easy management, the SR22T just released in the latest sim update (part of Premium Deluxe package) is a good choice, too. And it has the Cirrus exclusive Perspective Plus additions to the NXi.

The autopilot will always capture the alt preselector while your active AP mode is VNAV. The autopilot, conversely, will always ignore the alt preselector once in either GS or GP.

He didn't. Yes, he did change the flight model to free castoring, but it will still only be able to be taxi'd with toe brakes. Or I guess if you crank up the power to takeoff power and jam the rudders wildly around. Not really an optimal situation for folks without toe brakes (most people), but that's what mods are for. If you have toe brakes, this will work.

The sim doesn't really support this very well from a control scheme standpoint. Having it be free castoring would mean only folks with toe brakes could taxi the plane, and there's no way to make this a configurable option (it's a fixed configuration in the flight model).

I think a lot is being attributed to this mod that hasn't changed. The CAS message was always present. The climb out performance currently is exactly in line with POH numbers and manufacturer data, so you are free to deviate from that of course if that is your preference, but I would hesitate to call it more realistic.

No, we goofed. 🙂 I know folks like to blame Asobo for all sorts of things, but we're perfectly capable of creating bone-headed bugs too, thank you very much. 😅 Again, as for sounds, they're bit for bit identical to before, no changes at all. It's just a consequence of the engine running at a different RPM than previously. But if you ran the old plane at 2500 RPM it would sound identical to now.

We didn't alter any sounds, no. But I think the introduction of the fixed governor has definitely subjectively changed the cruise soundscape a bit.

One of the MSFS art teams worked their magic on the model, which I think looks absolutely awesome.

Yeah, this indicates to me that's there's probably a mod in conflict. We've seen a few interfere, mostly the SR22 Realism Mod and a flight model mod.

The SR22T, unlike the SR22, has a fixed governor at 2500RPM. It does not have the combined throttle/prop linkage system. The RPM will not drop even at idle until you are below around 90kts. Not totally clear what you're seeing here. The CHTs do not move particularly quickly in this aircraft. For example, on takeoff, going from idle power to WOT, the CHT will go from around 225 to about 320-340. But this takes a good few minutes. You will certainly see your CHT move on that timescale. However, if you are just quickly changing power or mixture and waiting a few seconds, you're not going to see much CHT change at all. They're a large thermal mass that take time to change. The resolution on the expanded engine page is 5 degrees as well, so that can subjectively influence the feel of it. There's really not much CHT difference in any of the cruise power settings. You'll get some change based on mixture. We based all of this on manufacturer data and video references. Here's a great video reference: you can see the CHT doesn't move even 5 degrees during the entire cruise power setting procedure: It's hard to say, but if your tanks are empty and you have TKS on you will get a CAS message to that effect. If you need to refill them, you can reset the weight in the TKS payload station. Maybe someone smarter at art than me knows (we don't have any artists at WT), but I'm not aware of any way of doing that in the sim. The climate control system is not modeled.

Yes, it does. Do you have a screenshot of what you're seeing, by any chance?