Is there a schedule posted anywhere for the Dev Q&As on Twitch? I would love to be able to put that on my calendar. I’m hoping there’s one for the year, so I can just schedule 'em all now.
That’s because Asobo explained that thermals were implemented and also how, during a Q&A.
Unfortunately there isn’t a schedule anywhere for the dates of the Q&As. They’re normally announced in the forums in the “News and Announcements” thread, normally about 2-3 weeks out of the expected broadcast date. (they may be announced elsewhere, too. But this is the only place I look for them)
Regards
1 Like
Ahhh ok. That’s what I thought I remembered, but I wanted to ask to make sure. I do believe the next one is the end of July? Or was it August?
It seems to me, just my opinion, from what we have seen in all previous betas that
the intent is different from what you would expect from a traditional beta run.
Traditional: get feedback on bugs or items that need attention, attempt to fix and repeat the cycle multiple times. This includes new bugs/problems that are discovered, reported and get addressed/fixed in one of the iterations. Repeat the loop until a Release Candidate is born.
MSFS: starts with a Release Candidate and a list of specific items to test against to verify they have been fixed. The intent is to stick to the list, not to look for anything new UNLESS it is a game breaker or absolute show-stopper. If new bugs/issues are reported, add them to a list for later (not intended to be fixed in the beta).
So when the Community gets the beta, it’s as if 99% of the bug fix work is done and it’s just a dry run for a Release Candidate from the start. See if the stuff we tried to fix is actually fixed (that has already been verified by their internal testing). It seems like they don’t expect or anticipate fixing anything new that is reported unless it’s a major drop-dead showstopper.
That’s what I mean by the intent is different from what you would expect from a traditional beta run. And they set their timing off of that requirement.
4 Likes
This is a quite bad “intent” as it would mean that you theoretically could have added many many additional “not showstopper defects” who then go unnoticed and undocumented.
PS: if in a Beta they would focus on real showstopper defects like the constant CTDs and blank screens that would be different may be
1 Like
Oh, they’re noticed, and documented. They just start to grow hair and turn green in the back of the fridge until you say, “what is this?” and throw it away.
4 Likes
The problem is that they can’t just remove them without getting noticed as they did with gusts in su4. Some people know what the hairy and green thing is. It’s many that uses the same fridge.
Good example though 
I would like them to improve/fix those things ASAP instead especially the things that has got broken after an update that worked perfectly fine at release or before the new update.
And i don’t understand why we should test the issues that they fixed. Isn’t it more important to test if something they not touched got broken in a BETA? Agree those issues they fixed is important to work but those things we have already reported as issues. It’s up to them to fix them propperly. We can’t help them fix them only report them and that we have done.
We know. We also know that after they release the beta that code is locked unless its something major.
Maybe its just me and i spoiled my “business partners” but we in our group, we never did business like that. I would always take that list in and then list back to them what will be included in the release. Barring any “new” features. That is a no and always would be in the current beta.
I don’t really understand why we have a Beta. I’ve been in almost everyone and report the bugs, but nothing is done about it.
Beta should not have a voting system. We are there to test & report. Everyone is not testing the same things, I’m quite certain, so the votes don’t mean anything in Beta.
Might as well just skip it and realease SU10 to the general public and let everyone else report the bugs. More votes that way.
4 Likes
Maybe you forgot the SimConnect bug that we found on day one after SU9 dropped? That was fixed in beta 2 a few days later. So no, I don’t agree…
But that could have been fixed in the public build as well.
1 Like
And was only fixed this “fast” because we screamed loud enough
2 Likes
I tend to disagree with these kind of statements. Just a bug post with the facts and the steps to reproduce was enough to get this fixed. No emotional yelling and ranting is needed.
1 Like
Absolutely not. This forum would have exploded with people who weren’t able to fly anymore because of all their peripherals becoming inop.
This really needed to be fixed in the beta. This is exactly what a beta is for. Apart from the fact that this shouldn’t have been broken in the first place, but that’s another matter.
2 Likes
But instead it exploded with other things that not been fixed. Well, we are all forced to use that BETA at some point and that beta may have issues even in August. I would like to have at least 2 different versions all the time to be able to choose the one that are most stable for me.
2 Likes
Voting for wishes of new features i could agree but voting for issues, no. An issue that has only 1 vote could be equally important to be fixed as an issue with 1000 votes.
3 Likes
Yea votes have no place in testing.
Take a poll on a sinking ship, the lower decks will all vote to fix the leak, the rest of the boat … ?
2 Likes
Yes, on the lower deck there maybe only 1 person.
1 Like
Exactly.
For example, I have filed a bug report on Quickviews being incorrect. ie, you pull the hat-stick back/left and the view looks forward/right in most aircraft. The C-172 and C-208 both work as expected.
Anyways, that bug report has no votes. I’m certain it’s because hardly anyone uses Quickviews.
They are using VR, default hat-switch views, or the mouse to look around.
1 Like