MattNischan

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.

If these aircraft have been built in 2020 and are 2020 native aircraft packages, then they should be using 2020 LOD rules. If you are finding that they are not, and you have a solid repro for that, please report it on the DevSupport forum, as that is not the intended behavior and is an important backwards compatibility issue that the team would be very interested in. If, however, you are building these packages in 2024 (despite being non-modular 2020 style), then they will obey 2024 LOD rules, and you may need to separate the gear to model attachments and optimize them for the new rules. If properly done, then they will not disappear. As for folks using the stock AI models, as mentioned by Jorg in a Dev Q&A, those models are being worked on to eliminate breakages of the LOD rules in those models that are causing issues, and the LOD rules themselves have recently been changed to be less stringent, especially at long distances. As mentioned in the same comments by Jorg, there was some contracted art he is not happy with, and it has taken some time to find alternative art teams and resources to assign to these art bugs. However, they are actively being worked on, with updates most especially for default aircraft non-AI models coming in SU4.

It might be a lack of competence on my part in explaining, but I feel like there are little bits and pieces of info being repeated here (maybe from bits read on the web) but not really an understanding of the modern game rendering pipeline. Culling and LOD are orthogonal concepts. They can work together, of course, to reduce performance load, but they're not one and the same. MSFS uses multiple culling techniques to avoid drawing geometry where it is not visible, and also uses (separately) LODs to reduce the overall triangle load of the scene. Mesh Shaders are new, and need recent GPUs above the 2024 lower spec range. Very few UE5 games have this feature enabled. DX12 is not a fixed function pipeline, and so doesn't enforce or provide its own LOD system. As far as the automatic LOD generation tools go, AutoLOD has yet to exit from experimental in Unity, and UE5 doesn't make LODs at all. Nanite in UE5 is not a LOD generation device, it's a real-time geometry decimation which works best right now for terrain, although it can be enabled on other types of assets. But it also has pretty high I/O throughout requirements as it streams geometry mashlets from disk, and has its own performance issues still. The other tools fall into the category I described (and aren't part of any game engines), and manual LOD creation is still the primary way by which asset LODs are created today (though with careful use by professionals, these tools can be an assistive boost). In any case, we may be talking past each other more than we're meeting, so I think I'll bow out here. Hopefully this has all been informational for folks!

I do not think this is even remotely accurate to claim (although, as always, I'm happy to be proven wrong if you have other examples). The closest thing I can think of that exists at the moment is something like Nanite in UE5, which is extremely new and also has some serious performance and usage constraints still. Asset creation in modern game engines indeed is almost entirely done with by-hand LOD creation. There are some automated tools to help this baked into various modeling tools like Blender and 3DSMax (and there are a few specialty standalone tools as well), but they can generate very suboptimal topologies even when used very, very carefully (examples of the kind of potentially poor results and recommended techniques here in the SDK docs). As an artist on a game project, you are expected to be able to create assets with all of the required LODs (usually 3-5 of them). This has been the case for decades so is not really a new paradigm at all. That being said, the flight simulator development community also comes from a lot of different areas; a good deal of hobbyists turned second-job, single developers doing all the work, retirement gig folks, etc. This is not a knock on them at all; they all do simply outstanding work and I am constantly humbled by what gets produced in the flight sim world! But, certainly, the transition to a more modern asset pipeline has caught some folks out understandably, and it does also represent additional workload to build those LODs. Nonetheless, sim users of all hardware levels continue to clamor for more and more performance all while also clamoring for more and more graphical detail, and keeping the old addon style viable where everyone just shipped single LODs makes it impossible to hit those targets as graphics and processing power continue to slow in advances. LODs like this have been standard since engines in the 90s, and indeed every version of Flight Simulator (and derivatives) since I believe FS95 has had them; it's just the enforcement that is new.

It is indeed! That is why the LOD setting in the sim directly controls how much screen space an object can take up before it switches to a lower detail LOD. Issues with AI traffic aircraft models incorrectly using the new LOD system and having things like gear culled early (because they don't have sufficiently low detail enough LODs at distance) is something that is included in the things I said Jorg mentioning were being addressed. It's an art issue, not really an engine issue. Appropriately constructed (with the latest limits), you would not need anything like square wheels to keep under the vertex count (1000 vertices from 0% to 1% screen size) and the gear will stay visible long after they would be indistinguishable from the rest of the plane (2-3 pixels).