Asobo/MSFS need to fix the code base…

[bean_sprout 1,201]

On 9/19/2021 at 1:15 PM, Bobsk8 said:

When I suffered crash after crash, I was told by just about everyone that there was something wrong with my brand new system. After months of this, I sent my PC to the company that made it and they replaced the AMD GPU with a Nvidia GPU, because I was getting many driver time outs with the AMD card, and a new PSU for the new GPU. Haven't had one crash in 5 months after getting my PC back. . 

Hardware is one thing but configuration / bios is another.  Drivers are the big one but don't update them unless you read the readme.  

Software bugs, get pretty well tested so often things downstreem cause issues.  They fail because noone expected them to. Duh.

Cheers

bs

[RobJC 2,069]

1 hour ago, MattNischan said:

This is one of the best replies to this topic that has ever existed on these types of topics.

-Matt

Of course he is wrong on all three points, but he did put effort into it. 

[Car147 2,276]

14 hours ago, Moria15 said:

As a developer, (although not a member of the fraternity mentioned above 🙂  ) I can tell you that CTD's are generated by Windows 99.9% of the time.  ( Null pointers typically make up the rest)

Since it is windows terminating, there is pretty much no way that Asobo can intercept it to do anything with it gracefully.  Example.. on your liveries..  If Asobo tried the livery before putting it on your aircraft.. windows would still CTD.  You could spend a lot of time in the program finding a way to examine the livery and test it, but it would have to be done real time, each time  and have a default replacement livery and guess what..  then you would have stutters and people complaining about stutters and it not being the livery they selected.

This situation becomes worse when you have multiple threads running, because now a CTD can come from any thread.

If windows blows your program out, it's gone before the application can do anything about it.  The wiindows crash log will tell you (and it does) what program it was executing (and where it was in that program) when the CTD happens, but the program itself is being controlled by windows, not the other way around.  This is why every CTD should be Zendesked with the full windows error log so it can be located to see if there is anything Asobo could add to prevent it  (unlikely).

The only way you could exit gracefully (in most cases) is to take your program away from windows and run it in your own operating system, and thats a non-starter these days with the complexity of these things.

I will make a prophecy however...  when DX12 is introduced..  we are going to see a huge number of CTD's from people who don't have DX12 set-up properly on their machine, as this is another new high level wrapper which has even less protection in it than DX11  and that will also be a windows issue not an Asobo one.

Graham

I think your onto something there, as any CTD's i have had usually clear up after a Win 10 update. Again after the last WU, i started getting infrequent CTD's. A few days later another Win update dropped, and apart from one on loading the sim yhesterday aal has been fine with at least 6hrs flown without issue.

[MattNischan 3,778]

2 hours ago, RobJC said:

Of course he is wrong on all three points, but he did put effort into it. 

Well, between you and I, one of us has the sim source and interfaces amongst us all on the MSFS team daily. 😉

Not to put too fine a point on it, but that post was spot on. Lots more going on behind the scenes and it's all quite organized and analytical.

-Matt

[bobcat999 8,439]

20 minutes ago, MattNischan said:

...Lots more going on behind the scenes and it's all quite organized and analytical.

-Matt

Well that is quite uplifting to hear.  We could do with more of these posts with positive feedback.  has it been analysed how the regression are creeping back into the code?

[Dominique_K 10,133]

 

3 hours ago, bobcat999 said:

has it been analysed how the regression are creeping back into the code?

Regression ? What regression ? The  LOD back at 5 nm, the permanent widget on screen, the lightnings, the overexposure of the whites, the flawed ATIS, the clouds pixelated at the edges, the morphing and coastal glitches etc. etc.   all analysed in a well thought organization. No regression, just a way for MS to keep us on our toes and check  if we are attentive.
 

[bobcat999 8,439]

30 minutes ago, Dominique_K said:

 ... No regression, just a way for MS to keep us on our toes and check if we are attentive.

Hey!  That's clever.  I never thought of that!  I have often wondered if it is a psychological experiment on observation.  

[MarcG 2,903]

Organised? Asobo? Lol 😆

[orchestra_nl 923]

On 9/19/2021 at 10:57 PM, HiFlyer said:

Which might have been the famous AMD usb issues which are, once again, something that is (slowly) fading away.

AMD user here. I can confirm the USB issues.

From last year august till late spring this year all my flights would end in CTD if they were long enough. It turned out to be a combination of USB controlllers. The more USB controllers I hooked up, the earlier in flight the CTD's would occur. Without USB controllers, there were no CTD's.

I am still not sure what fixed it (mostly) in the end. After removing some old controller xml files from my msfs profile folder MSFS seemed more stable, but in the same period AMD had some USB fixes while MSFS received updates (SU4 and SU5)

I still have the occasional CTD, mostly related to commercial addon airports, but on the whole the sim seems quite stable at the moment.

[mrueedi 702]

15 hours ago, RobJC said:

I have lost count of the number of bugs that appeared after working initially, then got fixed, broken again and then fixed again. If you have ever done any serious programming in your life you already know this speaks to a problem related to how the code is being managed, or how the code is structured. 

Are you a programmer? Because i am. 

Again, you only notice bugs as they appear to users. That tells nothing about the root cause. Ten times the same issue on user level can have a different root cause every time. If you programmed complex software you should know.

I am also a programmer and system architect. I was deeply involved in an extremely complex (say MSFS scale), 200-men project (actually I was the owner on IT side), in which for many months every day a bug tracking meeting was made, with dozens of people in the call who did nothing than priorize and discuss the issues (the project manager of one stream once told me: the most depressing meeting series she ever knew due to the intense focus on negative things). Going through the list of open issues took up to 3 hours. Every single day. It was organized as good as humanly possible. Still the bug burn down rate often was only a bit faster than the bug detection rate. At times slower. The total bug count reached severall ten thousands. So trust me, I do know the other side very well. And I stand by my comment: you impossibly can judge Asobos work based on the experience on your machine.

Let me also add, that I dont consider humanity to have mastered software development at all. It still is one of the youngest engineering disciplines. Skills in mechanical engineering matured over a much longer time. Even in aircraft engineering. Even with all the lean, agile, rapide, adaptive design, TDD ... buzzwords, software engineering pretty much depends on humans falability any day. As you are a programmer, have you seen about the silver bullet syndrome? It teaches me, that users should be graceful to programmers!

And MSFS is incredibly complex. I is much more complex than any other game that I can imagine. Bringing this overwhelming complexity to this huge variety of existing PCs with good performance requires tons of trade-offs on all levels.

Having insights and being involved hands on in many complex software projets (right now at my workplace a team of the best specialists is trying to fix a nasty issue in production since 10 days. Only a handfull of code-lines is suspected to be wrong. In a multi billion company. For a software that every day moves around huge amounts of financial assests), I consider MSFS as one of the most complex piece of software existing.

 

[MarcG 2,903]

Sensitivity page missing after an update = Organised

Pre Caching Terrain Option missing from an update on the VR section of the UI = Organised

Lights on planes missing since SU5 meanwhile fixed by a community member in days = Organised

The flaps issue... = Organised

These are but a few examples of poor organisation on Asobos behalf, regardless of the deep code structure they are anything but organised. Quality Control? there is none.

[mrueedi 702]

7 minutes ago, MarcG said:

Sensitivity page missing after an update = Organised

Pre Caching Terrain Option missing from an update on the VR section of the UI = Organised

Lights on planes missing since SU5 meanwhile fixed by a community member in days = Organised

The flaps issue... = Organised

These are but a few examples of poor organisation on Asobos behalf, regardless of the deep code structure they are anything but organised. Quality Control? there is none.

Uneducated and wrong speculation...

Do you want to say, that without any quality control they only created so few issues? That would be a spectacular accomplishment!

Btw. what is an "organised" bug?

[MarcG 2,903]

11 minutes ago, mrueedi said:

Uneducated and wrong speculation...

Do you want to say, that without any quality control they only created so few issues? That would be a spectacular accomplishment!

Btw. what is an "organised" bug?

You need to read the context of the past couple of pages (= organised is with tongue in cheek!) 😉

[RobJC 2,069]

I like MSFS and have had some good times with it, but i stand by my comments. Far too many regressions to say the code base is organized. Asobo needs to take a deeper dive into why these basic problems are occurring in the source code. I get it is a complicated project. They have built something really cool. But we are a year out and it feels like we are chasing out tails. Need to tighten up the process. 

[mrueedi 702]

2 hours ago, RobJC said:

Far too many regressions to say the code base is organized.

Can you tell Asobo's defect escape rate (the ratio between caught and uncaught bugs)? No, you can't. And therefore your rant is unsubstantiated speculation.

I am not making any statement about MSFS codebase. Because I can't. I just say, you can neither.

I do say however, that a project needs to be organized pretty good to get so far. The ratio of broken things vs working things would be much worse otherwise. Don't fool yourselves. If you count function points, the lacking parts form a very small percentage of the whole package. There is a vast amount of stable and working functionality.

Also don't forget, not everything depends on the code of MSFS. A lot depends on configuration settings (server and client side). Also, as a distributed system MSFS depends heavily on local and server-side infrastructure.