Regarding Your Feedback + Upcoming Hotfix

[MultiMediaWill 14]

18 minutes ago, Bobsk8 said:

From the time I have flown sims, decades ago, almost everyone understood that if you moved the sliders to the left, you FPS increased. Doesn't take a genius to figure that out. So in reducing what we see on the screen in SU5, we get more FPS and less memory usage. What is ground breaking about that? I see the target of 6GB of memory used, why did they pick that amount, why not 10, or 8 GBs? Could it possibly be that this is what is available  in an X box? Just trying to figure out what happened here causing the roll back of quality in the images we are seeing. So many are saying this has nothing to do with X box, but it sure smells like  it does.

Agreed 100%. Based on the fact that the sim now doesn't use more RAM/VRAM than the Xbox speaks volumes to why these changes were made. To say it has nothing to do with Xbox would simply be a lie. Now time will tell whether this was deliberate or if they just ran out of time and pushed a really buggy update. Either way, PC users need a way to access the full extent of their hardware again. 

[Matchstick 1,902]

4 minutes ago, jarmstro said:

Of course no one should be fired or terminated! It's just a pc program. But are you seriously suggesting that Asobo didn't notice the graphical degradation and the bugs before SU5 was released? I find that very hard to believe to be honest.

I agree with you that Asobo were almost certainly aware of (at least some of) the issues before they released the software.

But I think the decision to release with these issues was because they had an externally set release date set in stone and no time to fix them, rather than the release looking the way they intended.

[ADamiani 470]

56 minutes ago, Matchstick said:

So that's evidence that the visuals have been downgraded, but where's the evidence that it's the result of a deliberate decision not bugs ?

I'm not suggesting that things haven't been downgraded (though the severity of the effects may not be same for everyone), my questions it whether it's happened by accident or design. Considering the state of this release in general "accident" is entirely believable for me.,

So, to put things in order, we have some facts:

1) the XBox version is announced for 27/7 

2) su5 is announced exactly for the same day 

3) in su5 they decide to do a lot of optimization. Especially in memory utilization, but not only. 

4) su5 has a number of bugs, even ctd's, Lighting is not working ok, a number of other problems.

5) su5 is pushed on ALL users and presented as a great improvement

Now, if we really want to believe that the devs were unaware of all bugs, ctd's, regressions, before users started complaining, then we can believe anything (I am not going to give an example because people around here are offended easily) and we are really insulting the devs. It would also imply believing that the "public" beta testing went smooth without problems, which is, let's say, improbable.

It is only logical to conclude that a buggy, unstable, regressive update (better defined crashdate) was pushed on every user.

Why? Examine facts 1 - 5 and you will know. Suggestion: they had an alternative: wait until the update was ready. They didn't. Why?

Why did they push a compulsory bugged update instead of waiting for a stable, working one?

A.

[Matchstick 1,902]

1 minute ago, ADamiani said:

Why did they push a compulsory bugged update instead of waiting for a stable, working one?

I agree that Asobo should have delayed the release but my suspicion is that MS insisted that they hit that release date no matter what (I believe we saw something similar with the highly problematic original release nearly a year ago).

[jarmstro 2,405]

2 minutes ago, Matchstick said:

I agree with you that Asobo were almost certainly aware of (at least some of) the issues before they released the software.

But I think the decision to release with these issues was because they had an externally set release date set in stone and no time to fix them, rather than the release looking the way they intended.

Their deadlines are not my problem. I have been gaming and using simulators on PC's since their dawn. Bugs I can tolerate in programs because they will be patched. Regression I cannot tolerate. And SU5 is the worst case of regression I can ever recall.

[Sesquashtoo 2,846]

10 minutes ago, jarmstro said:

Of course no one should be fired or terminated! It's just a pc program. But are you seriously suggesting that Asobo didn't notice the graphical degradation and the bugs before SU5 was released? I find that very hard to believe to be honest.

I agree with you, for under my current executive chain of command,  you would and have, and can be fired, if they feel that those myriad bugs were not found, by the very people that they pay the 'six figures (or more) to...for to NOT have a bug ridden software property be let out into the 'wild' with the embarrassment and hit to the Company Logo and sense of prestige.  My company's exec's hold us to a much higher standard as Department Heads, than what I am reading some others do in their chain of command.  That is why they pay us the 'big bucks', to NOT have non-oversight in these matters.   Maybe I work for the only Senior Management Team that holds you to a '6/7 figure' professional grade of due diligence.  I dunno....

[Matchstick 1,902]

3 minutes ago, jarmstro said:

Their deadlines are not my problem. I have been gaming and using simulators on PC's since their dawn. Bugs I can tolerate in programs because they will be patched. Regression I cannot tolerate. And SU5 is the worst case of regression I can ever recall.

I can't really argue with that position but I would point out that doesn't necessarily represent a deliberate regression but rather one that's potentially the result of just running out of time and having to deliver code that wasn't finished yet.

Edited August 5, 2021 by Matchstick

[abrams_tank 7,470]

18 minutes ago, ADamiani said:

So, to put things in order, we have some facts:

1) the XBox version is announced for 27/7 

2) su5 is announced exactly for the same day 

3) in su5 they decide to do a lot of optimization. Especially in memory utilization, but not only. 

4) su5 has a number of bugs, even ctd's, Lighting is not working ok, a number of other problems.

5) su5 is pushed on ALL users and presented as a great improvement

Now, if we really want to believe that the devs were unaware of all bugs, ctd's, regressions, before users started complaining, then we can believe anything (I am not going to give an example because people around here are offended easily) and we are really insulting the devs. It would also imply believing that the "public" beta testing went smooth without problems, which is, let's say, improbable.

It is only logical to conclude that a buggy, unstable, regressive update (better defined crashdate) was pushed on every user.

Why? Examine facts 1 - 5 and you will know. Suggestion: they had an alternative: wait until the update was ready. They didn't. Why?

Why did they push a compulsory bugged update instead of waiting for a stable, working one?

A.

It's been repeated over and over in this thread.  July 27th was an immovable date.  Microsoft has spent a lot of $$$ advertising that date.  People learned of July 27th as the release date of MSFS on X-Box.  You can't undo the advertising of July 27th without spending probably 10x more than your original advertising.  And it's also very embarrassing for Microsoft if they move the date back.

For software development reasons and testing reasons, SU5 had to be released with the X-Box release and it was always planned that way.  Of course Asobo knew of the some of the bugs but because July 27th was set in stone, they did the best they could.

In hindsight, they should have either:

1. Picked a later date to give themselves more time to polish the release

or

2. Cut some of the features for the X-Box and SU5 release, and started beta testing sooner and done a longer beta test

What's done is done.  Let's just wait for the hotfix and subsequent fixes in the next World Update.  The good thing is, there probably won't be another major release like X-Box with an immovable date for some time.

Edited August 5, 2021 by abrams_tank

[Alpine Scenery 1,609]

I don't think there is much to speculate about, i would not try to speculate on motives, just processes anyhow.

1) They want to keep the 2 code branches as similar as possible. Part of the issue is the SIZE of the code they are dealing with, it's so monstrously large from all the old FSX code too.

2) They needed to optimize for Xbox-S (or whichever), so they decided to also use the same techniques for the PC version

3) Many of them probably were viewing on average size dev monitors (20" to 30"), and then some of us had 50-150" screens and noticed some changes. I'm sure they also had a viewing room, but these changes are sometimes hard to see.

4) Very possible the cumulative changes were just seen as barely different fidelity-wise, and pushed it through

5) All the OCD people (I am one) in the forums started finding issues, but what some people don't realize is your own personal setup like monitor differences could possibly enhance some of those minor issues.

 

Edited August 5, 2021 by Alpine Scenery

[Sesquashtoo 2,846]

20 minutes ago, Matchstick said:

I agree that Asobo should have delayed the release but my suspicion is that MS insisted that they hit that release date no matter what (I believe we saw something similar with the highly problematic original release nearly a year ago).

...as I said in another thread and posting,  the bottom line, is that M.S. pays the bills, for the 'thrills'...and is the source of the salary deposited into all those  employed at Asobo from the C.E.O, down to the cook at the Lunch Counter's accounts every week.  Asobo will write to their (M.S.'s) hardware platform, if directed to. They will also dance to the tune M.S. is playing on the corporate 'piano' of the day and hour, and ....that one, (I speculate) is to align one permutation of their Xbox Game, MSFS Flight Simulator, that can also be coded to run on a P.C., and not the other way around.  My personal opinion. 🙂   I bought an Xbox in the flavor 'X'......

Edited August 5, 2021 by Sesquashtoo

[Alpine Scenery 1,609]

23 minutes ago, Sesquashtoo said:

I agree with you, for under my current executive chain of command,  you would and have, and can be fired, if they feel that those myriad bugs were not found, by the very people that they pay the 'six figures (or more) to...for to NOT have a bug ridden software property be let out into the 'wild' with the embarrassment and hit to the Company Logo and sense of prestige.  

Let us not forget some of the autopilot designs in REAL planes that have had bugs. I am not that type of engineer, but I never understood why they didn't implement a fail-safe hard pull like a fail-safe switch between the actual control systems and the AP. I guess it's so digitally driven and pilots would probably try the hard pull method too late, and knowing its there in the first place could be a distraction. Or what about a lot of pilots who have said there is WAY TOO many warning systems in planes that go off simultaneously, and the warnings themselves were partially responsible for their crashes (excuse or just pilot error, debatable in each situation I suppose).

It's different in gaming code. The bugs are often not as prioritized. Sure you see some almost bug-free complex environments like RDR 2, but you also have other examples like Star Citizen. I see MSFS as in the middle, it's fairly stable in the game, but the DEV environment changes too quickly in terms of stability for sure.

Edited August 5, 2021 by Alpine Scenery

[Sesquashtoo 2,846]

7 minutes ago, Alpine Scenery said:

Let us not forget some of the autopilot designs in REAL planes that have had bugs. I am not that type of engineer, but I never understood why they didn't implement a fail-safe hard pull like a fail-safe switch between the actual control systems and the AP. I guess it's so digitally driven and pilots would probably try the hard pull method too late, and knowing its there in the first place could be a distraction. Or what about a lot of pilots who have said there is WAY TOO many warning systems in planes that go off simultaneously, and the warnings themselves were partially responsible for their crashes (excuse or just pilot error, debatable in each situation I suppose).

It's different in gaming code. The bugs are often not as prioritized. Sure you see some almost bug-free complex environments like RDR 2, but you also have other examples like Star Citizen. I see MSFS as in the middle, it's fairly stable in the game, but the DEV environment changes too quickly in terms of stability for sure.

A post to chew the cud on....thank you!

[Dominique_K 10,152]

1 hour ago, MattNischan said:

I have to defend Lionel a bit here, because he's a really, truly, a great dude, super smart, and that's a very out of context take.

A game LOD system is a super complex beast, especially in a system like this where you have a multitude of streaming assets with widely varying sizes and texture requirements. They all need to be on the screen at an appropriate level of detail, but what determines appropriate? Well, one simple approach is that you load everything in for each asset that could potentially be visible, and you burn a ton of RAM and waste CPU on your main thread doing memory management. This is maybe sometimes the safest in I/O terms, but not really a well optimized solution for the sim use case. And what is it that you actually display? Should the shrub that is 4x4 pixels screen size but 5m away get full LOD while the skyscraper that's 1500m away but 150x150 pixels get a lower LOD, just due to distance? Do you keep every LOD in memory or only the ones likely to be displayed? Do you stream in compressed or uncompressed textures, and when for each? Each answer to this question has follow on effects for the next answer, and the next answer, etc.

The whole thing is a complex dance that is way more art than science, and that's what Lionel means by "tuning". At a certain point, no matter the architecture, there's little gained (and much to be lost) by holding assets in memory if the I/O subsystem is sufficiently speedy and threaded, but what that exact breakpoint might be is never precise (and changes depending on hardware). So, you try to do this whole balance thing to not affect any one part too much, win some cases, hopefully not lose in other cases. What was done was thought to be a pretty clear net win overall. PC performance is objectively positively affected by these optimizations.

However, it's clear that a part of the community disagrees, and the team listens to that. And that's why you'll see more options going forward.

-Matt

I do not think that any reasonable simmer attacks Lionel Fuentes. He did a remarkable and altogether honest explanation of what he did. Very welcome.  We may have interpreted wrongly (or not) what he said but in anycase he is not the boss, the bucket stops two storeys upstairs.

The FSX/P3D world has suffered from an irritating LOD (and morphing) problem for an eternity. Lo and behold, on August 18th, 2020 Asobo's baby had not the problem anymore. Tears of joy. Then the problem came back with an update, then SU5  tries to solve the problem in a way that is perceived as a regression by many people. In the meantime, Neuman continued to make his PR dance around the fire, chanting that all would be so much better with SU5.  People get  irritated, surprise !  

Make no mistake, I don't try to convince you of anything, I try to make you understand why you have willy nilly a pile of doo doo at your door. Because I like this sim. 

 

Edited August 5, 2021 by Dominique_K

[Ray Proudfoot 9,038]

2 hours ago, simbol said:

member tag 🙂

@Ray Proudfoot, what do you think?

Not my area, sorry. I’m just a humble mod, not management. 😉

[Alpine Scenery 1,609]

LODs are so complex, it's a research topic at places like MIT. That said, there are industry standards now that cover most use cases, and most programmers that do LOD stuff are quite specialized and know a lot of the standards.

It's kind of like a watch maker or a transmission repair guy, it takes highly specialized knowledge to master LODs, to say the least. Even as programmers, you really don't understand the details that well of what all they are doing, some of the formulas are kind of (shall we say long enough to fill up an Excel spreadsheet), while other formulas might be as simple as a slope deviation factor.

 

Edited August 5, 2021 by Alpine Scenery