MS2020 Simconect

[nathaniel mitchell]

so am concerned that ms2020 have not given an update regarding the sim connect issue. as seen on the ms2020 web page they have not even put it up on there list of known issues, simconect fps bug is far to bad to fly

i feel that if vatsim is a partner why are then not updating on the progress, people of the vatsim community are just going back to old sims because of it. do you think it will be corrected soon or even give an update as to when it my be sorted.

 

https://www.flightsimulator.com/known-issues/

 

https://forums.flightsimulator.com/t/simconnect-stutter/162526/84

Edited August 21, 2020 at 10:49 PM by nathaniel mitchell

[Garett Keeler]

I agree, Vatsim is a MSFS partner. I figured they will at least get an update. 

[nathaniel mitchell]

am sure that if they are partner this is priority and should of been parched two days ago. they made such a big thing about it. but its unstable and probs giving that newbie a bad time on are lovely network 

[Diego Vasquez]

12 hours ago, Garett Keeler said:

I agree, Vatsim is a MSFS partner. I figured they will at least get an update. 

Not that they can do a lot I suppose, but If I were on the team who engaged MS/Asobo, I would feel used and betrayed, especially due to the "day 1" promise.

[nathaniel mitchell]

am sure that if they are partner this is priority and should of been parched two days ago. they made such a big thing about it. but its unstable and probs giving that newbie a bad time on are lovely network 

 

agreed

[Matthew Bartels]

No reason to feel upset or betrayed. Microsoft and Asobo have been very good about working with us and are well aware of the issue. We have been in constant communication about it and hope to have a resolution soon.

[nathaniel mitchell]

ya say that but its not even on the list 

[Matthew Bartels]

12 minutes ago, nathaniel mitchell said:

ya say that but its not even on the list 

It doesn't need to be. We have been in direct communication with them all week about the issue. 

[nathaniel mitchell]

so you know when it will be fixed?

[Diego Vasquez]

 

13 minutes ago, nathaniel mitchell said:

so you know when it will be fixed?

Whether the SimConnect fix is included in the announced Aug 27 patch or not, will reveal how important "being on the list" really is.

 

Edited August 22, 2020 at 02:20 PM by Diego Vasquez

[Calum Stevens]

deleted

Edited August 24, 2020 at 02:50 PM by Calum Stevens

[Calum Stevens]

On 8/22/2020 at 12:58 PM, Matthew Bartels said:

It doesn't need to be. We have been in direct communication with them all week about the issue. 

Just because behind closed doors you are talking to Asobo. Doesnt mean they can or should just leave the public hanging with no message about them being aware of the problem, working on a fix or a date for the fix. 
It's all well and good that you have insider knowledge, but we are the paying and playing public should be given the curtosy of the fix being made public, esspecially (as said earlier) as Vatsim was promised functionality. 

[nathaniel mitchell]

agreed. 27th is announcement day not a guarantee that its a patch day. Vatsim your post says that you will have an update for us were is it. if it is true that you have inside knowledge why have you not given us an update like it says in the post.

"We have been in constant communication about it and hope to have a resolution soon."

the patch should of been out long by now if vatsim was a vauled partner. just awful

[Brad Littlejohn]

40 minutes ago, nathaniel mitchell said:

agreed. 27th is announcement day not a guarantee that its a patch day. Vatsim your post says that you will have an update for us were is it. if it is true that you have inside knowledge why have you not given us an update like it says in the post.

"We have been in constant communication about it and hope to have a resolution soon."

the patch should of been out long by now if vatsim was a vauled partner. just awful

 

One thing you should know about software development: NEVER give a date for when a certain patch or feature is going to be released, because if it isn't released, the consumer complains. When it is announced, the consumer complains ("Why wasn't it released earlier?!?!!?"). Either way, because of how the consumer in the western world thinks, the software developer loses, because either they get blasted for not having it out any faster, or not having it out when they give a release date (which that date is to appease the consumer because they keep asking when the release date is)).

I would rather be patient, give them the time to make sure that the fix is ready, made right, thoroughly tested, and idiotproof so that it is guaranteed to not break, before releasing it. You know; measure twice, cut once.. not rush a fix because consumers demand it, still not have it working, and have to go back to the drawing board again to figure out another patch.

That's why, back in the day, when Mike Evans developed ASRC, everyone kept asking "when is it going to be released!? We need a release date!!" Mike replied "it will be released when it's ready." Right now, we have a new sim to get used to. new functionality, new everything. We finally have an ear and access straight to the developers of MSFS. That is something VATSIM, nor any other ATC network has had since MSFS was first developed. They (MSFS and the BoG) have no reason to lie or deceive us as to if a patch for this is coming. So let's just sit back, be patient, and let them get it done, and get it done right, so you have a solid fix that doesn't have to be revisited again, instead of rushing something that could cause something else to break.

 

BL.

 

[Luke Bennellick]

19 hours ago, Brad Littlejohn said:

 

One thing you should know about software development: NEVER give a date for when a certain patch or feature is going to be released, because if it isn't released, the consumer complains. When it is announced, the consumer complains ("Why wasn't it released earlier?!?!!?"). Either way, because of how the consumer in the western world thinks, the software developer loses, because either they get blasted for not having it out any faster, or not having it out when they give a release date (which that date is to appease the consumer because they keep asking when the release date is)).

I would rather be patient, give them the time to make sure that the fix is ready, made right, thoroughly tested, and idiotproof so that it is guaranteed to not break, before releasing it. You know; measure twice, cut once.. not rush a fix because consumers demand it, still not have it working, and have to go back to the drawing board again to figure out another patch.

That's why, back in the day, when Mike Evans developed ASRC, everyone kept asking "when is it going to be released!? We need a release date!!" Mike replied "it will be released when it's ready." Right now, we have a new sim to get used to. new functionality, new everything. We finally have an ear and access straight to the developers of MSFS. That is something VATSIM, nor any other ATC network has had since MSFS was first developed. They (MSFS and the BoG) have no reason to lie or deceive us as to if a patch for this is coming. So let's just sit back, be patient, and let them get it done, and get it done right, so you have a solid fix that doesn't have to be revisited again, instead of rushing something that could cause something else to break.

 

BL.

 

I've been a software engineer for twelve years, and I'm not sure I've ever worked for a company that hasn't given deadlines for when features will be released. This isn't open source software, or a charity. We're paying customers that bought a piece of software on the basis of functionality that was broken. When I tell a client I'll have x feature implemented by y, you can be damn sure I'll have that feature ready in time because I'm a professional, and because otherwise the customer will take their contract elsewhere.

I'm not particularly unhappy about the delay, because I know it'll likely be fixed soon - but please don't imply software development as a field should not be subject to deadlines. Delays (with a valid reason, when openly communicated) are tolerable to an extent, but this idea what the almighty dev should have forever to work on something, and everyone else needs to wait, isn't economically viable, or professional, at all.

Edited August 25, 2020 at 12:11 PM by Luke Bennellick

[James Drake]

On the MSFS forums, the devs did acknowledge the issue publicly:

 

Quote

SpringTrout3797 Developer

Hello all,

We are aware of this issue. We already tracked its source, and we working on a solution at this moment.
We will provide a patch as soon as possible.

We apologize for the inconvencience,

Engine Developer / Asobo

Source: https://forums.flightsimulator.com/t/simconnect-stutter/162526/170

[nathaniel mitchell]

so the patch is Not happening https://forums.flightsimulator.com/t/edit-patch-details-incoming-on-the-27-according-to-support-release-also-27th-follow-instructions-if-you-use-liveries-and-custom-scenery/214475/80

it had been said that it was happing but it is not being pushed.

looks like we still caint use vatsim.

also vatsim can we get a statement regarding this  you must know something now as you guys say that you are always talking to them.

we can't use your services and you are there partner  

Edited August 27, 2020 at 02:12 PM by nathaniel mitchell

[Luke Kolin]

On 8/24/2020 at 12:15 PM, nathaniel mitchell said:

the patch should of been out long by now if vatsim was a vauled partner. just awful

I think it's pretty obvious you don't have a background in software development (or even usage), especially in larger systems. Nothing that's happened here has been particularly surprising. A little disappointing, sure. Nothing more.

Cheers!

Luke

[Brad Littlejohn]

On 8/25/2020 at 5:10 AM, Luke Bennellick said:

I've been a software engineer for twelve years, and I'm not sure I've ever worked for a company that hasn't given deadlines for when features will be released. This isn't open source software, or a charity. We're paying customers that bought a piece of software on the basis of functionality that was broken. When I tell a client I'll have x feature implemented by y, you can be damn sure I'll have that feature ready in time because I'm a professional, and because otherwise the customer will take their contract elsewhere.

I'm not particularly unhappy about the delay, because I know it'll likely be fixed soon - but please don't imply software development as a field should not be subject to deadlines. Delays (with a valid reason, when openly communicated) are tolerable to an extent, but this idea what the almighty dev should have forever to work on something, and everyone else needs to wait, isn't economically viable, or professional, at all.

 

The difference here is that this isn't a feature. this is a BUG. They know this is a known issue and has to fix it. If this were a feature, then you're right; they would have to be forthright and public about what is going on, because at that point they are controlling the narrative because it is a feature that they are introducing. They control the testing and the QA on it. If they meet the deadline, they are good. If they aren't, then they need to give an update. I've been a sysadmin/database admin for the past 25 years in both the public and private sectors, have more than enough knowledge in the software development life cycle.

But this is the exact opposite. You have the user community that has identified the bug, and then DEMANDING that it get fixed; and more so than that, are trying to push them into possibly releasing something that they are not comfortable in releasing yet, because those that picked up the software on release date (read: early adopters) want to have that component working for them NOW, because they bought into it with the expectation that that feature would work and work flawlessly for them. I get that and understand that. But as a software developer yourself, You have to ask yourself the question: Does 100% of all software work, and work flawlessly 100% of the time upon immediate release?

If so, then there are some unrealistic expectations there. For example: Microsoft didn't take into account the typo in their OpenStreetMap data that someone accidentally created a 212-floor building in North Melbourne, Australia, when the building was supposed to be 2 floors only. The data was corrected, but not before Microsoft pulled that data into Flight Simulator.

https://www.engadget.com/flight-simulator-open-street-map-building-205545509.html

My point: The bug will be fixed when it is fixed, and no pushing or prodding VATSIM is going to make that go faster, especially if they were to act on it, that bugfix could be even buggier than what was originally broken. So let's set realistic expectations, including time for fixing the bug, proper Q/A, and let that drive the release time for the bugfix, instead of user demand for it that could inadvertedly push out something worse in haste.

BL.

 

[Diego Vasquez]

So, apparently 27th August was NOT patch date, instead the date when they would announce the game's first patch (promise to promise), and here I was counting the hours... I am either too gullible or wishful-thinking?

But even that came and went without any news, especially if one is based in Kiribati (pun intended).

: P

 

[Matthew Bartels]

https://www.flightsimulator.com/august-27th-2020-development-update/

In short, simconnect performance bug should be fixed once the Microsoft Flight Simulator update goes live within the next 7 days.

[Calum Stevens]

I don't understand why a fix has a "release date"? As above, it's not a feature update, it's a fix. To announce a release date would suggest they have a fix now, but are intentionally delaying the release to.... Eh, generate hype? Drum up marketing and anticipation? It makes no sense. Surely if you have a fix you should release it as soon as possible. That's what other developers do with other software. Why do all these fixes need bundled together? Just release them when they are ready! I don't know, it shows something of immaturity from asobo. 

 

[Ross Carlson]

10 minutes ago, Calum Stevens said:

To announce a release date would suggest they have a fix now, but are intentionally delaying the release to.... Eh, generate hype?

Usually it's to allow an appropriate amount of time for testing. Rushing a patch out the door is generally a bad idea because without sufficient testing, you might be introducing new problems inadvertently.

Plus, it's not like the issues addressed by this patch are complete show-stoppers. The sim is still fully usable for most people. I'm sure if something broke the sim completely, they would strive to get the fix delivered with near-zero delay.

[Roger Hanson]

19 hours ago, Diego Vasquez said:

So, apparently 27th August was NOT patch date, instead the date when they would announce the game's first patch (promise to promise), and here I was counting the hours... I am either too gullible or wishful-thinking?

But even that came and went without any news, especially if one is based in Kiribati (pun intended).

: P

 

They said that they would be making an announcement on the 27th not issuing the fix/patch. Bear in mind that at the time you posted this it was still around 3PM on the USA west coast so still the 27th. 

[Luke Kolin]

12 hours ago, Calum Stevens said:

I don't understand why a fix has a "release date"? As above, it's not a feature update, it's a fix. To announce a release date would suggest they have a fix now, but are intentionally delaying the release to.... Eh, generate hype? Drum up marketing and anticipation? It makes no sense. Surely if you have a fix you should release it as soon as possible. That's what other developers do with other software.

No, they don't. As Ross points out you have to test them, and given the complexity of the system there's a test suite that is run over the overall package. It makes sense to batch the fixes into a unified release, rather than doing each one at a time.

Cheers!