Kind of thinking “out loud”, but I wonder if the MSFS development team has access to some kind of statistical analysis of a compiled MSFS users configuration data base?
Reading and participating in some of the threads in this forum, it seems to me like there has to be at least several commonalities that link the more prevalent complaints and performance issues, I.E. CTDs, stutters, low frame rates, etc.
Examples of just some of those commonalities could be things like:
Windows 10 Version
Anti-virus/Spyware apps - Type/version
GPU, CPU Processor Types and driver versions
Overclocking used
Add On’s present
Input-Output device types
etc.
It’s just a thought, but with today’s advanced data collection methods (I’m obviously not suggesting a paper customer-survey questionnaire, here.) it seems to me like the MSFS developers would benefit greatly with access to this kind of information.
If nothing else, it could be be far more efficient at identifying the “low-hanging fruit” than by just counting the number of votes for each of the various issues/bugs identified in the forums.
I truly hope that I am just stating the obvious, here, but perhaps not?
Well Microsoft are no strangers to data mining and having experimented recently with data on/off it seems like you are never truly “offline” at all with msfs2020
Even with all data options disabled (checked and double checked) there is a persistent connection and data transfer that the flightsim.exe is making.
The numbers are very small. But it’s constant and persistent. One assumes a continuous validation “heartbeat” while running the sim?
So, if validation data is constantly being collected presumably it would not be outside the realms of possibility to collect system and performance data?
Take a look using performance monitor. Check the flightsimulator.exe to isolate only that activity…
Even with everything (data) turned off in the sim there is a persistent data connection that is transferring small packages all the time when in flight.
In the main menu there is a lot more activity but that must be related to menu assets loading.
I shut down all online functionality over the weekend and enabled each part one at a time trying to trace which connections were serving which function and which had the most/least impact on performance.
Still a work in progress which I won’t get time to look into in greater depth until this coming weekend, but there is definitely constant data transfer even will every data setting I could find set to disabled.
Diags/performance data could actually be gathered using the DevMode tools and MS already have the capability/tools to collect system data, this would seem like a wasted opportunity to streamline fault finding if it’s not already being done.
(After all, compared to what we stream live during a flight it would be a very small package.)
I am impressed by your very methodical and deliberate plans to better determine data transfers vs. simulator performance. Not a simple effort, in my mind at least…
My hat’s off to you!
What got me thinking along these lines, though, was that it really seems like there is a significant number of simmers (not the majority for sure) who are trying really hard to wrestle-out some decent performance via some of the voodoo, witchcraft, & snake oil techniques found in various threads of this forum.
To me, this approach is not really that much more advanced than sending out customer satisfaction surveys through the mail.
Maybe I just don’t understand all the ins and outs of the “gaming industry”…
I’ll certainly be interested in hearing what you determine after you finish your testing, though!
You raise an interesting point.
I too have questioned the veracity of the current way in which bug reports are prioritised for action.
Action apparently based on a simple ‘head count’ of votes.
I don’t think anyone wants to get bogged down with metrics here, but the simple expedient of incorporating a time component into the current method would perhaps allow for a more reactive choice
as to where the bug ‘fixing’ effort should be focused.
Eg.
200 reports in 1 week = average 28 per day.
500 reports in 8 weeks = average 09 per day.
Of course, these averages would change in a non-linear fashion [averages would start high
and taper off over time]. But this is what I meant when I said “more reactive”.
I hear you and certainly would not disagree. Seriously, though, I am really quite at a loss as to exactly what the current method is.
Is it simply just a tally of the vote count for each issue that determines the priorities for fixes?
I honestly can’t believe that!!
I sincerely hope that those numbers are being presented to us primarily for the sake of interest, you know?
“Misery loves company”, so to speak and I am strongly inclined to believe that the bug status lists are more of an appeasement/reference tool for us simmers, rather than a real drop-dead, priority list that drives the developers daily to-do actions.
