Inventing Spirit

VR is the tool take make these kind of approaches not only much more realistic but also much more precise (and easier). Here are two YT videos I did showing fantastic approaches in the Swiss Alps, which I could never have done without VR. With VR you sense the angles where the runway is much more precise (i.e. like in real world) by the direction where you have to turn your head: MSFS - Ulrichen Airport - LSMC MSFS - LSFR - Frutigen - TBM 930 - Spectacular approach

What API did FSLTL use? Or, in other words, what data was provided by FR24? Is it just the flightplans, e.g. airline, type, arrival/departure times, possibly gates? Or, is it also real time position data (adsb) for the exact recreation of every movement? Because comparing the movements on a big airport and comparing them with the FR24 live screen, I can recognize many distinct planes (type/airline are matching) but runway usage, taxiway routes and even gates are different than in real live. So I assume, the injector did anyway not recreate the exact real world operations.

A Pilatus test pilot was test flying the PC-21 in MSFS (from Iris I think) and found it surprisingly good within the normal flight envelope with some weak spots at the edge or beyond the envelope. The video also gives a nice impression about the rugged terrain around the Pilatus factory airfield (LSZC). Many years back, when watching Buochs ops, I still remember very well, how the F-5 Tigers dropped over the Eastern ridge of Bürgenstock leveling their wings barely before reaching short final.

I somehow can't find the menu or link where I could ask to become a commercial member?

This does apparently no longer work because when I try the same today it remains at the full price. Or, how did you do that?

Some scenes (within the rocks) in the video remind me on this real world video: I wonder when a good Mirage III will be released...

I can't imagine that they ever refueled over unfriendly territory. With or without transponder.

There are other reasons for modular design like reuseable components over multiple variants of the same aircraft. E.g. the cargo and the pax version of an airliner can reuse the same gear models. Another reason are if multiple instances of the same model can exist (e.g. like tires or seats). Loading a model once and render it multiple times can improve the performance. Anyway I have quickly loaded the Asobo Max and the Virtual File System is showing separate attachments for all 3 gears. So we can conclude that the discussion about the gear needs to consider modular design principles in 2024. And, that the AIG models quite likely are not fully modular:

Unless you have studied the new 2024 modular modelling, you will quite likely not be able to draw the correct conclusion about the issue: Modular Aircraft SimObjects The structure, @SayAgain posted in his first post is 100% MSFS 2020. A modern model probably should have own gltf files just for the gear.

I think, 3rd party addons don't have access to the sims elevation data. Btw. would not sending you off route be quite unrealistic in the first place?

Will this ATC also control ai traffic?

From QA perspective, there were 50k. Because duplicates and all these other categories need to be managed by them too. Which is why it is relevant here. You missed the relevant part of Seedy's post: That sentence in very simple terms tells the story of a capable and efficient QA organization.

You can only judge how good MSFS runs on your desk. But you impossibly can know which team inside Asobo/MS you should blame for that. That's all I try to explain. If "QC" for you is just a diffuse synonym for the organization that causes the bugs on your desk, then I am 100% fine with you! Real QC is just something else then. You should not make jokes if you didn't read what SeedyL said. I simply took the 50k (in total) from his post. You understand the difference between issues in total and open issues at release? The total number includes closed ones (but raised and managed by QC nevertheless, which is why they are highly relevant for the discussed topic).

I have provided a list of scenarios which result in fixes not making it into the release or being deferred. There are significant efforts going on to flag issues with a priority. Whether an issue is blatant obvious is only one criteria among a list of many others (like risk, effort, potential ripple down effects, compatibility considerations, ...). And the priority list is then worked down. Some will make the final cut, some not.

How would you know that QC "missed" them vs. that they are still there for one of the other reasons I mentioned? And - if they would have no QC, who would have raised 50k issues prior release? Do you have the slightest idea about the effort to raise and manage 50k issues?