1 hour ago, Twenty6 said:

It should not have happened ... period.

What industry do you work in? People don’t get fired for this sort of thing. A mistake happened in a beta, of a video game. This is not the medical field, no one’s gonna die. 

1 hour ago, NZ255 said:

What industry do you work in? People don’t get fired for this sort of thing. A mistake happened in a beta, of a video game. This is not the medical field, no one’s gonna die. 

I don't, I'm retired.

And who's dying? This is not about people dying or it being a beta video game. It's all about being paid real money to do a job and then not doing it properly. Workers get fired for not doing their job all the time.

4 hours ago, Twenty6 said:

Workers get fired for not doing their job all the time.

That would make for a pretty toxic work environment if people get fired for things like that.

5 hours ago, Twenty6 said:

I don't, I'm retired.

And who's dying? This is not about people dying or it being a beta video game. It's all about being paid real money to do a job and then not doing it properly. Workers get fired for not doing their job all the time.

Is this the part where we salute? 😉

ns

Edited April 17, 20224 yr by bean_sprout

On 4/15/2022 at 12:25 AM, ChaoticBeauty said:

SimConnect:

• We’re currently refactoring the SimConnect input system.

This worries me. Please don't refactor it entirely. People can become quite disappointed when their external hardware stops working. From a small deskpit to full blown home cockpits, all solutions to power extra hardware rely on SimConnect. Should the methods and procedures change, become inop or even vanish (like the camera controls), all this hardware will grind to a halt. 
Please keep the API consistent with previous specs - just add a couple of methods so we can write to/read from BVars, HVars and LVars. Thank you for your consideration.

Edited April 17, 20224 yr by Lorby_SI

6 hours ago, NZ255 said:

That would make for a pretty toxic work environment if people get fired for things like that.

That would seem to me to depend on how it happened.

If it was just an unfortunate accident then you need to take steps to avoid it happening again but it's not anybody's fault.

But if it's the result of someone deliberately ignoring procedures that are intended to prevent this sorry of thing happening that is a very different matter.

21 hours ago, Twenty6 said:

the only person delusional was the person entrusted with putting the updated files together into the beta release

Before making such assumptions, you should understand how these things work in this development industry. The hundreds of people working on the code will be uploading to a server several times a day, or in some cases multiple servers (I would guess it's multiple servers for MSFS), which automatically compile each team member's code into a single build every time it/they receive code from a member of the dev team.

Sometimes the servers will be able to identify if a build won't work and send an error report back to the relevant developer, but sometimes the automated build servers can't determine that.

So I guess the compile servers should be fired...

Edited April 17, 20224 yr by March Hare

7 hours ago, Matchstick said:

That would seem to me to depend on how it happened.

If it was just an unfortunate accident then you need to take steps to avoid it happening again but it's not anybody's fault.

But if it's the result of someone deliberately ignoring procedures that are intended to prevent this sorry of thing happening that is a very different matter.

See my post above. Final builds are automated by servers. In a beta test run, they have no reason not to trust the servers, if they haven't returned an error report.

For a release build, it would be tested by a dedicated team before going live/burned to disc. But as it's a beta test anyway, there's no point spending dedicated test team resources when the servers say it should run.

Edited April 17, 20224 yr by March Hare

18 minutes ago, March Hare said:

See my post above. Final builds are automated by servers. In a beta test run, they have no reason not to trust the servers, if they haven't returned an error report.

For a release build, it would be tested by a dedicated team before going live/burned to disc. But as it's a beta test anyway, there's no point spending dedicated test team resources when the servers say it should run.

The issue here wans't a continuous integration or build server issue. Of course the executable delivered passed the tests, it was the final SU8 release executable, the problem here was with someone creating a release containing that executable at all as part of an SU9 release.

I can see ways that could happen but they all require someone to have made a mistake, specified the wrong file version, tagged something as belonging to the wrong branch etc which then cascaded through into this messed up release

 

I think I'll re-open my pitchfork and burning torch shop again.

I can't believe we're talking about (or in some cases, calling for) somebody being fired over this.🙄

20 minutes ago, Matchstick said:

The issue here wans't a continuous integration or build server issue. Of course the executable delivered passed the tests, it was the final SU8 release executable, the problem here was with someone creating a release containing that executable at all as part of an SU9 release.

I can see ways that could happen but they all require someone to have made a mistake, specified the wrong file version, tagged something as belonging to the wrong branch etc which then cascaded through into this messed up release

 

Right. My first comment still applies to the person I was responding to, because they thought someone compiles all these files into the release (or beta) build, whereas it's done "intelligently" by servers. But yes, as you point out, that kind of mistake is going to be caused by an individual. It happened on a big name game a couple of years back that my brother's team were working on; somebody accidentally uploaded an older version of their code section to the build server. Still, a mistake like that isn't worth firing someone over.

1 hour ago, March Hare said:

Still, a mistake like that isn't worth firing someone over.

Doink!

(Not the sound of another kicker missing a field goal attempt, just the flat-faced implement hitting the pointed object on the appropriate spot).

Where is this "vegetation distance render slider"?  I can push my trees to Ultra which still has a ring of trees about 9 odd km away from my plane, suddenly stopping, on TLOD of 200.  Anything else is a stutterfest in big cities.  Are we just meant to push terrain LOD to 400 now?