MattNischan

Those were in MSFS 2020 SU14. The SR22T takes full advantage of the parameters.

Without overriding the engine model entirely and doing it from the ground up outside the sim (with all of the additional weirdness that comes with it, like broken simvars, strange bindings, etc), what is being suggested is impossible to do. The sim piston engine will simply not start with the mixture at cutoff. Now, what might make people "feel good" is if the mixture knob was at cutoff in the virtual cockpit but was like 10% open in the sim. But that's just an animation. Does that mean the plane is more or less realistic at that point?

I don't know what Navigraph does as far as harmonizing the data with the simulator scenery. The stock data build process has the benefit of having all of the scenery on hand in source form when building the navdata. You will still see the fixes to the ILS radio for erroneous deviation swings near the last 100ft or so, as that is an issue in the sim radio itself. But the rest of the issues are just how the navdata relates to the actual scenery (and, to the real world). Lots of the data in the ARINC for ILS is actually not needed for aircraft at all, it's only there for simulation purposes. The antenna position (vertical and lateral) is not required for avionics IRL, as they just tune the radio. So, these things don't get surveyed particularly often, and as budgets get tighter the intervals get longer and accuracy gets worse. So, there are a great many cases where the ARINC data says the runway bearing is X, but the ILS bearing is Y, and it's possible neither of them are actually the real bearing exactly. Or the antenna position is some lat/lon/alt, but if you look at the TCH, that can't be true with either the in-sim scenery runway end height and/or the ARINC runway height. As a result, the navdata in this case cannot possibly be the source of truth, when all of those truths add up to something that isn't internally consistent or consistent with the sim scenery. So, now, during the stock navdata build process, we're fine tuning those data points to align with the actual sim scenery.

Just ILS. There is no globally available data source for PAPI positioning. Some notes I've made about this topic on the official forums about our work here this sim update: And

This is not an issue with the plane itself, it's an issue with the sim's electrical system, which in some configurations is causing circuits to read as powered off intermittently when it should not. The issue is open with Asobo presently and I believe a potential fix has been pushed in SU5.1.

We will use the sim standard mercator projection for both the map and the WXR, so we can utilize what the sim gives us. While not strictly the map projection the real unit uses, we use it everywhere else and almost nobody has noticed in 5 years. It only affects the visuals of some zoomed out leg paths and land geometries, but not in a way that changes functionality. We're taking so many things on the jet so very far, but ultimately on any software platform we feel you have to take your licks and do what's practical and user conscious.

This is not automatically a bug. There are many IRL AT systems that work like this that this may be simulating (we do a similar thing with the Longitude AT). In many ATs of this class, the AT servos are on friction clutches which are actually designed to slip. IRL the pilot can push against the AT to make a quick adjustment of the throttle if needed and the clutches just slip intentionally. When the pilot has removed pressure, the AT returns to the previous commanded position. This does not automatically disconnect the AT.

That assumes the party who owns the data was willing to entertain such a thing. The sim's current LIDO navdata equals and in some cases exceeds the quality of the Jeppesen navdata (remembering that taxiway information is not a part of navdata). For the majority of reports since switching to LIDO we have found folks were comparing to Jeppesen, but it was the Jeppesen data that was out of date. Not every single report, of course, but I'm sure both companies are happy for the extra eyes on the data.

Certainly not. That data is owned by Jeppesen and using it to improve a commercial product is absolutely something that requires a (vary large and very expensive) licensing agreement.

There is no global dataset for airport layouts that includes taxiways. No taxiway data is included in the ARINC spec at all. Some companies offer AMDB data (airport mapping database), but there are none that are totally worldwide (and also are hugely expensive), and the airport coverage isn't spectacular (especially for strips like this). So, the data is a combination of AI looking at aerials and OpenStreetMap data. But you can't run that process all the time, as the results have a lot of their own inaccuracies that need a boatload of human intervention still. Areas tend to get special attention and focus with World Updates. No magic bullets here, unfortunately.

It is a volumetric beam. You can test this by making a flat precip layer, and then slewing up and down towards and away from the layer. You can see the returns move towards and away from your aircraft as a result of the beam intersection. As far as the answers to the other questions, I'm afraid it's not really my place to field them. DevSupport would be the appropriate venue for those kinds of questions. -Matt

It is already modeling a 3D beam (not a slice), and has always. It is not doing that, no.

That post is in error. Asobo did the work on this. We (WT) merely added the JS API. Credit should go to them. Additionally, the weather radar was always 3D, going back to 2020 launch. Just some nonsense rumour and misunderstanding that became internet lore that for some reason will simply not die.

The equivalent process in MSFS 2024 is relatively similar in complexity: - Go to the EFB Planner app, Route page - Enter Origin and Destination, then (optionally) press Auto-Route button if you want something not direct - Go to Flight Detail page, and select VFR or IFR - Optional (back on the Route Page): Go to the SEND menu, and hit Send To Avionics and Send To ATC as desired The Auto-Route button in 2024 is exactly the same code that is engaged in 2020 when it creates a route for you on the world map.

This change is part of the other LOD curve changes implemented in SU4 for 2024 native models. These changes apply to all 2024 native models and there isn't any other option to modulate this other than increasing the already existing LOD settings. For stock MSFS AI aircraft, a number of them have also been fixed to follow LOD rules correctly in SU4. My understanding from the dev Q&As is that this work was to be done by new art contractors over the course of SU4 and SU5. For 2020 native models in 2024, they still obey 2020 LOD laws. This is situation purportedly applies to the AIG models. So there is investigation still to be done there to determine if the models or the engine is at fault for the gear on those aircraft in 2024.