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?

Oh, I did not want to say that there were exactly or even close to 30k bugs. I presented the 30k figure as a rough number how I remembered it (and you did confirm that I remembered correctly). In the context of QC which we were discussing it does not matter. Removing the duplicates or the not-a-bug-cases in no way invalidates my statement about QC. So let me rephrase the part about QC once more very clearly: Managing tens of thousands of issues is not indicating a shoddy QC how @MarcG claimed. These number prove the opposite. QC guys know, that a project is very large, very complex and QC is running at full speed if the ID's in the bug tracking tool become five-digit numbers or are even approaching six-digits. In fact the 50k of managed issues totally, which you mentioned, are a great testimony to the MSFS QC operations. The 50k indicate a very large and efficient QC organization (because I ask once more, how could an inefficient QC raise and manage that many issues?). Do you think, if QC had raised 70k issues at release (a total number which could well be reached in their bug tracker by now, listing issues in any state like open, duplicate, fixed, deferred, not-a-bug) the released product would have been better? In aviation terms, they were clearly behind the power curve, so the dev side failed to close known issues fast enough. In that situation, QC is not to blame. QC is only to blame, if they would not have known the state of the software. But they knew. Which basically was the essence of Jörgs admission in that dev stream. Marc, don't forget that given these dimensions, it is very very likely that every single issue that is plaguing you exists in their bug tracker. You need to be aware that there are many reasons why known bugs, including regressions, won't be fixed for a release. Sometimes the risk of damaging even more important parts is larger than the benefit of fixing a comparibly minor issue. When public betas start, it is not the time anymore for large scale code changes. Trade offs to be made from that point onwards are e.g. "avoid fixing issues that affect less than 5% of users if it requires architecture changes", "don't touch code anymore which requires large efforts to stabilize it", "minimize changing particular code which is known to cause significant ripple effects", "we can't address these bugs anymore because it would require mandatory updates from all addon devs", "feasibility to fix is not given", "this is not a bug but a new feature request -> deferred", "fixing bug A unmasked bug B, which impossibly can't be addressed anymore for this release". Btw. I am neither blaming the dev side. What we have is lacking in parts, because it (mainly) is the result of one of the most complex software projects I could think of. In absolute terms. Across all industries. And I have a worked on a lot of incredibly complex software projects. Considering all that, 2024 overall is working exceptionally well.

The symptom that at release 30k bugs remained open, indicates several areas which were lacking, but QC is not among them. Where I worked, it was also like that. More than qc not being supportive enough, devs were not able to address the flood of issues. If the bug burndown rate barely matches the rate of new bugs being detected (or even exceeds it, a dreaded situation in which I personally was for 2-3 years) you are watching at an organization with a good oiled QC which is potentially lacking in many other departments. I mean, just think about the large number of dev teams who work for MSFS and the over the top complex nature of the sim. I have nothing but the highest respect for what they achieved no matter what.

Sorry, you seem to not understand how it works. QA only reports issues which are managed in huge bug tracking and managing tools. Whether and to what degree they are fixed is not in their responsibility. Jorg mentioned in one of the early dev streams that they had 30k or so open bugs at release of 2024. Who has found them? Who reported them and managed them? Calling that a shoddy QA setup more than anything else just reveals one thing: you misjudged them and have no clue how QA or testing is handled professionally in big projects.

When I read these posts, many people are lacking the knowledge how QA works and how it affects the shipped product. You guys are aware that a perfectly working QA can be in place and the software still ships with lots of evident bugs?

No, since 2020 colors of (summer) image tiles affect the coloring of e.g. forests. So if an area has darker trees like needle trees, that area will show correctly darker trees. This answers your question: Since when has the colour of trees in the base satellite images determined the colour of the displayed autogen trees? But, as mentioned, it is not about seasons.

No, colors of the imagery impacted coloring of areas of vegetation or forests since the beginning of 2020. Everybody is aware, that boundaries between satelite images can look like that. On a global level, that problem can not be solved. So you should stop asking for impossible things. And the very least you should stop blaming those who are not responsible (QC at Asobo). Even better: you complain to the dentist, that your car can't fly to the moon! 🙂 There is an AI pass over the image tiles in MSFS. Further improvements would not be easy but very hard. In software development, going from 90% to 95% to 98% to 99% perfection every time doubles efforts (and costs). And the OP is asking going from 99% perfection to 99.999%.

It seems, the sim is not lacking so much as you are lacking insights. Please educate yourself here under the section "Note on collision damage / wear and tear": flight_model.cfg - Additional Information

Simply: MSFS2024 is also a study level heat and noise simulation (as real aircraft produce tremendous amounts of heat and noise too 🙂 )!!

Comparing 1:1 the two screenshots I see several issues with MSFS 2020: - The unrealistic green roads in MSFS2020 (motorway in the lower right corner). Perfectly asphalty in 2024. - The same motorway has washed out markings in 2020, in 2024 they are sharper even though the motorway is shown a bit more distant in the 2024 screenshot. - Actually details are rendered less far out in MSFS2020! - The horizonline immediately tells which one is MSFS2020. Fixed in 2024. - The mobile antenna is added in 2024 at the correct place. Missing in 2020. - In 2020, the blue lake in the center has a curved surface like a blob of paint. In 2024, it is flat like a mirror.

So your assesment of his post also applies to yours.