Thanks Cap.
1 Like
If you want to compare MSFS to an iPhone, then it would be like having the latest phone with all brand new features and gizmos , has the latest software, looks really cool and has been hyped as the " best phone ever " , but , there is one problemâŠit constantly drops calls for no reason.
The problem for me with MSFS is that the countless bugs are not making this game an enjoyable flight simming experience at the moment.
For example : A few days ago I tried to make a flight from KMQI to KJYO ( Manteo NC to Leesburg VA ) in the C172. Everything looked and worked pretty much as the present software limitations allows . All except , of course , the weather. The weather at KMQI was about 12 hours old with broken clouds and winds at 335/ 25K. Real time WX was clear skies and winds 080/ 8K.
I said OK, Iâll fly the route anyway with the weather given by the " sim " . I took off and leveled off at 4000â when all of sudden , out of the blue , the wind shifted from 330/ 30K to 145/ 12K. I thought OK the weather updated closer to real time as these were the correct winds at the altitude for that time and the skies actually started to clear ahead.
Unfortunately what I thought was going to be a pleasant flight sim experience didnât last long. Not ten minutes later the winds suddenly shifted back to 330/ 30K like I hit a brick wall. This wind shifting happened three more times about every ten minutes until I finally gave up , ended the flight and turned the sim off.
I plan to keep it off for a while too⊠At least until Asobo and MS fix this mess of game they have created. Just like I wouldnât use an iPhone that I couldnât use for what it was primarily designed to doâŠmake calls.
2 Likes
Excellent, Lyle. This is what I want to hear. A specific issue that obviously has nothing to do with your hardware. this is a bug report. (sort of, missing some details that Zendesk would ask for, butâŠ)
I hope you added this to the weather thread.
Feedmachine, not only the delivery system has changed but also the complexity. âIn the old timesâ I brought home âRed Baronâ, a ground breaking combat flight experience, on three 1.44 MB floppy discs. Took up nearly 20% of my hard drive.
Now, MSFS.
How many GBs have we downloaded so far?
Discussions like this have the power to refocus. Get us talking about the things the developers can solve. Hopefully stop the red faced ranting. Woosaw.
Complexity is an aspect which is rather hard to evaluate, which is why I did not bring it up in the first place. In any case while I do have some knowledge about programming, I donât feel that confident so as to discuss it, but anywaysâŠ
Bugs, patches, fixes are generally related to code, and as such I tend consider code as what complexity is about in this case. Indeed, the main issues of the game seem to be mainly related to the under-the-hood mechanics of the game, which are related to the code base of the game. The graphical issues are generally related to how the graphic elements behave in the simulator, which is again something related to code; e.g. we complain about the buildings height-bug, which is a graphical issue due (simplifying) to the way the code handles 2D sat imagery, which is a code issue, not a graphical one.
In any case I donât think size is a good indicator of the complexity of a game since the vast majority of space consists of graphic elements like textures and models. In the years textures went from something more than a couple of pixels, to enormous aggregates of color-maps, alpha-maps, bump-maps etc, which in most cases are only loosely compressed (if at all). I mean, PS1 console games had cinematics that were something like 320x240-8bit, now we have 4k, sometimes even 3D-4k. I dare say that the size of the code base is slim compared to the visual compartment of modern games.
So, in terms of complexity of code, I am not sure that its increase (which is there, to be sure) is the main culprit in the buggyness of modern software. Code is more complex from a functional perspective, but modern code is also easier to write, easier to debug and easier to test (there is a whole new universe in this regard, that was not there 20 years ago, and most of it is to help the developer). I donât have sufficient inside-knowledge about it though to be sure of it. 
Iâm not a computer programmer, but in essence , are you saying that Asobo and/or MS didnât code this game properly? If so, then they have a major task at hand to get this right. Which may take a while.
Iâll have salted please. I may have to share.
Hello Tom, thank you for your constructive reply, which makes absolutely sense. Obviously this is your âfieldâ and you are the specialist. I am a pilot, an aviator and look at things from a different point of view. Happy though that people like you, Asobo, Blackshark, Microsoft etc. develop all kinds of software for simulation purposes. I fully accept your reply. Greetings and happy flying
I liked the story. Thank you. May I add that in the old days Microsoft devoted room after room in their headquarters in Redmond to test their software in all sorts of equipment you can imagine. Any device or brand that existed in the market, Microsoft owned a sample for testing purposes. Today the customer has become the tester. Bugs and glitches are tackled by having the software call home, unless you choose to opt out. They call it analytics technology and Windows Insider Program.
Software has evolved, complexity is a lot greater than years before, but at the same time, development tools, debuggers, testing units, regression testing, etc, also have evolved accordingly, and in a lot of cases automated tools were created, development studios had become bigger than ever in last years, so software complexity is not an excuse in my book for launching a buggy piece of software, regardless its size.
People are angry because MSFS was advertised and hyped as hell, MS asked for full price, so people expected at least a product which can be started without major problems, and with full completion about the advertised features. If MS had launched the title as an early access, or had they advertised it as a VFR GA only simulator at start, with full IFR simulation and airliners in the making, things would been a lot easier for people to decide if itâs for them, and for the developer to avoid all the complaints and negativities on this forum.
Any piece of software has bugs, the difference between a solid released title against a very poor one, are the amount of game breaking and/or major bugs, plus missing or bugged major functionalities expected by the buyer accordingly with the advertised ones.
I donât fully agree with your assesment that implies all major problems in MSFS are because people hardware diversity. A Gigabyte RTX 2080 uses the same drivers as a MSI 2060 Super, AMD X570 chipset motherboards use the same drivers regardless manufacturer. All those drivers are approved and signed by Microsoft for the OS, and more importantly, all these same hardware and drivers combinations are utilized by all the games and software you run all day on your computer, without crashes, CTDs, etc., so who to blame here?
Apart for the irritating functionality bugs this game has, I donât have problems with this software, but a couple CTDs at landing every two or three fly sessions tell me itâs not my system, itâs this poor quality testing software the culpruit.
In other note, Where are the managed software exceptions on this software to present a managed error code in the case of a CTD event? The lack of it is also which makes finding fatal crash bugs a lot difficult, because you donât know on which part of your code it happened. Thatâs another example of the poor programing of this title in my opinion, and why itâs hard to find and solve bugs for the team in charge. Is not all reduced to userâs hardware as you are infering.
There could very well be a fair bit of unmanaged code. Managed code does have a performance cost, and in a performance-critical application like a game / simulator, the cost can be a bit high. I assume they also turn off debugging for the final released product, as the debugging code itself has a performance cost as well.
. . . and itâs not like an end user knows what to do with an error code anyways, itâs generally best to send back any telemetry and terminate the process.
1 Like
I 99% agree, but at this time I think at least managed exceptions are needed. There are several CTDs on the software, the devs need to know where to start tracking them.
The end user donât have to know about error codes, but they need to know an error had happened, and which information they need to send to the dev team. If you only greet them with the windows desktop, without any further information, you only get whatâs happening here, ie: A lot of moaning and angry people. And for the devs, If I have to file a zendesk bug report only with the description of the problem, without any other technical data such as a log describing at which function or code path the error happened, how is it supposed to help them to find the problem?
Given the track record of bug regression and new bugs introduced on every update, it tells me they donât have any clue whatâs really happening because they have almost no critical information, and are guessing and testing things internally that they canât reproduce.
Every big and complex software development like this has a way to inform the user that a critical error has occured, and what log file they have to send to allow the devs to take a look at (if there is no automated telemetry implemented, which I think itâs the case here). Itâs not about enabling debug code, you donât have the necesity to include debug code to inform the user an error and to generate a log file.
This sounds like a case for automatic reporting. Maybe a debug selection in the UI that would give users the option of having MSFS generate an error report and send it. I program business DB software and use a system of reporting that automatically generates a ticket and sends me an error report.
2 Likes
I agree itâs hard but letâs not pretend that MSFS is at the forefront and the only ones to be solving the âeveryone has a different machineâ problem. Thereâs plenty of best practices out there. Asobo themselves have developed multiple games that have had to deal with âeveryone has a different machineâ. Some of the practices that Asobo employs are not top tier (testing of patches for 1).
It is what it is though.
1 Like