MattNischan

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

I'm not totally sure where within what I said would it be implied that there's none of the usual normal culling happening which happens in all modern engines. I can't say I follow what additional option would be needed; the LOD option that is already in the sim multiplies the screen size before which objects move to the next less detailed LOD. If you want more detail for longer, you can increase that setting. What other option could possibly exist? This has been changed to be 5x smaller (0.1% screen-size).

The amount of screen space required before objects switch to less detailed LODs is affected by the graphics settings. The higher the graphics settings, the longer higher detailed LODs will remain on screen before switching to less detailed LODs. Ultimately it is up to addon developers to create LODs that are appropriate to the object screen size and that fit within the (generous IMO as of SU4) rules that govern which LOD is displayed. If addon developers choose to remove objects completely at certain LODs or not provide lower detail LODs at all, that would be up to the individual developer to address.

As has been explained in one or more dev Q&As, this is not so. Changing the LOD rules for 2024 3D assets was an intentional design choice in order to keep performance levels high across all scales of hardware, low and high. Unfortunately, throughout the lifetime of MSFS 2020, it was seen time and time again that many developers would not use the LOD system at all, creating one super complex LOD0 that would display no matter the distance. So if a plane was 10 pixels high way off in the distance, you're still having individual pipes and tubes in something like the landing gear drawn, and that eats performance quickly, especially when those models can also be selected by the model matching system for AI traffic, leaving little room for other things that need that performance budget, like clouds. For models that are in 2020 backwards-compatible mode (i.e. MSFS 2020 packages/addons running in 2024), the 2020 LOD rules still apply, thus causing no backwards compatibility issue. But for models in native 2024 packages, then the new LOD rules apply; this puts pressure on developers to properly optimize their models so single addons aren't monopolizing valuable hardware resources and performance can be consistent across varying sets of addon installs. And, the Asobo team has taken developer feedback about this system to heart, making adjustments to strike a reasonable balance at every SU (and especially SU4 with the new LOD selection curve). As Jorg as said, issues with Microsoft/first-party assets relating to LOD are being worked on actively (it was a matter of finding new art teams and resources to work on this effort, to ensure good results), with a large number of them landing in SU4 (especially regarding aircraft).

For approach procedures, for the case in which the MAP isn't just the runway fix, it will be a labeled fix in the procedure, so can be tracked as such and will appear in the list of approach legs (after the FAF).

This is the case with some avionics suites, but not with the Garmins. You would use the APPR button (arming GP) in all RNAV cases with vertical guidance (LNAV+V, LNAV/VNAV, LP+V, and LPV). VPTH will discontinue vertical guidance at the FAF. When to arm GP (by pressing the APPR) button is a matter of pilot preference and situation. You can arm it any time after you have passed the IAF on the approach. Most commonly it is armed some time while enroute to the FAF. Definitely do not wait until after passing the FAF to press APPR. Because VNAV guidance will discontinue at the FAF, you will level off and likely miss the GP; Garmins do not capture the GP from above (the above limit is very small, like 10-15 feet) so you will have to then dive to meet the GP to get GP to go from armed (in white) to active (in green).

It isn't really clear to me I'm afraid, no. Let me attempt to try to communicate this once more, perhaps I'm not being clear enough: There is no specific data source for true-to-life ILS range at all in AIRAC data. Therefore, there is not a publicly available place for simulators to source this information to set true-to-life, navaid specific ranges As such the default MSFS navdata uses some default ranges which should cover all or very nearly all published FAF scenarios Third-party sim navdata providers may have additional data sources outside of the worldwide AIRAC that they are using to get specific ranges of ILS navaids The sim provides a range field for ILS navaids that can be used to set the range of the navaid, which some third-party sim navdata providers use to set these ranges The sim uses this range number directly as the signal range. E.G. if this field is set to 75NM, then the LOC and DME will be available at 75NM. There is no other modification of this range inside the simulator or by any of the simulator programming teams responsible for this area (WT, Asobo) As such, if one is using third-party navdata that utilizes this range field and finds that a particular ILS navaid is not being received at the correct range, then the third-party navdata provider must update this range field to the correct value for that specific navaid Hopefully that helps clear up how this all works for both you and for other folks reading along.

I'm not understanding how you're coming to that conclusion. The range value is set directly in the navdata. If any third party sim navdata provider wants a particular ILS DME or LOC to have a range of 75NM, they just need to set that range value to 75NM. It's that basic, and it isn't arbitrary at all, nor does it have anything to do with Asobo, since the sim doesn't at all mess with or modulate that value in any way.

The sim does not simulate bad signals or signal degradation at all. The receive distance for a given ILS transmitter is given in the data. If your distance is equal to or less than the distance in the data, you will receive the ILS signal. If you are not receiving the signal when you expect, then you should report that specific location to your navdata provider for investigation.

The ILS issue is mostly an issue with what range data is available in the AIRAC, and that's very little. There is not really a field in the AIRAC that provides range data other than some guaranteed ranges (there's some extremely new fields but they're not really used by most AIPs yet), which are usually the 15NM class. Other sim navdata providers may add some extra percentage on top of this but that isn't really necessarily going to be accurate either IMO. The stance we've taken is that you will receive the ILS by the time it is guaranteed that you should be able to based on the data in the AIRAC, which will then also by definition correspond to any published procedures. Anything else is really just a guess.

I'll give my two cents as a developer, I love Discord for support. Yes, superficially, it does seem like you could have the same "responsiveness" if a developer was sitting on a forum, but in practice that doesn't at all pan out, and it isn't anyone's fault really, it's just the format. You can't really have a live conversation on a forum board. A forum board is more like trading letters or emails, and users understandably get annoyed if a support thread degenerates into very small rapid-fire questions back and forth that start to take up pages. On the other hand, if I need real-time details from a user and they just posted a message, I know they're live, likely to be experiencing the problem now, and I can have a direct conversation with them bested only by face-to-face communication and try and either a) understand the root cause of the issue, see the reproduction steps as the user is doing them, and be much closer to understanding how to fix a bug quickly or b) help the user with an error in how they're using the software. I can even step into a room and have them stream the problem right now. Attaching images? Just drag and drop or copy and paste, no forum wonkiness or needing to upload to some other image site and then figuring out how to embed it. Need video? User just screencaps a video clip super quick and drops it into the app. The downsides are yes, searching for solutions can often be less straightforward, and you are at the end of the chat firehose, so to speak. Nonetheless, I can't even begin to count how many bugs I've been able to locate down to the line just by having an actual conversation and/or seeing the actual software in action with the user as the problem is happening. It feels like the stuff of magic, and I say that as someone who grew up on usenet and Prodigy boards.

Sorry, I can't really comment on anything PS5 specific.

A runtime is something that "runs in time", i.e. something that interprets the WASM intermediate language instructions directly and executes those in sequence in real-time. That is not at all what happens in the sim. It ships with an AOT WASM to native DLL compiler, not a runtime. WASM runtimes are like what are present in your web browser; they don't compile the code (well, it's slightly more subtle than that as they may do little bits of compilation called JIT at runtime, but they don't do full ahead-of-time, or AOT compilation), they interpret the WASM IL in real-time, like the .Net runtime or like the Node V8 JS runtime. No, there are not three distinct code branches. As has been confirmed on a few dev Q&As, the codebase is the same for everything. There are compiler flags that switch between the small amount of platform specific code to produce a platform specific build.

The sim does not run on top of a WASM runtime nor does it include one. It is coded in native C++. There is no particular WASM translation performance penalty, as this is not how the sim uses WASM. WASM is simply a way to present C++ MSFS add-ons with a consistent and limited set of platform agnostic APIs to target. When compiled by the developer, it becomes WASM intermediate language code that describes the original code. Then, when the addon is first run in the sim (or ahead of time during the ingestion process, in the XBox case, since that's a fixed hardware target), the WASM IL is read and compiled directly to normal platform specific native instructions (into a DLL) just as if you had compiled it directly from C++, and loaded by the sim to run. Again, there is no WASM runtime, just this compiler system. I have no comments or details on the PS5 launch but just wanted to correct this wrong information.