Would you have preferred Squad go on a 3-week vacation without releasing 1.1.2 at all?

[MircoMars]

First of all. the devs deserved a long vacation! actually, everyone does. the last thing we I want for them is to be burned out and frustrated with their work (as I was once in my short working life). I think what annoys the playerbase most is when expectations are first raised by promises and then not fulfilled.

I was never an active participant in QA, so I lack a good bit of insight, but to me it seems that the wheel problems and the spontaneous crashes should have been detected earlier and dealt with. In case they are unfixable and inherent of the current unity version, there should have been an announcement saying:

"we are very sorry, but despite our best effords Unity 5 is not ready for what we need it to do, yet. we'll keep trying with every new update, here's the U5-dev-built for those who are willing to take the pains and risks. Meanwhile we work on assets, parts and general gameplay ideas that are not bound by the engine's version."

and dear devs, you had have one of the nicest and most helpful communities outside "open"-projects. keep them close, be honest and they will understand and help you.

[The_Rocketeer]

@5thHorseman u got a typo in there, doesn't scan...

[Superfluous J]

Just now, The_Rocketeer said:

@5thHorseman u got a typo in there, doesn't scan...

I (think I) was fixing it when you posted. If not, tell me what it was

[The_Rocketeer]

U nailed that sucker

[Red Iron Crown]

I voted the second option, I would have complained if they hadn't released before going.

The prerelease made putting off release by too much untenable. Half the playerbase was playing the new version, the other half unable to even try it (fractions may vary, but you see my point). Modders were being pestered into oblivion to update their mods for 1.1, even when they had explicitly said they would not update until 1.1 was finalized.

I am amused by the notion that people would have been content for them to take a longish vacation before releasing, during the testing period. I'm fairly confident that the forum would have gone nuts. "How can you take vacation when the prerelease testing is still going on?!?!"

I'm fine with how it played out, given the options here. Many people are playing 1.1 and enjoying it. Those for whom 1.1 doesn't work well can still download and play 1.0.5, which is exactly where they'd be if 1.1 hadn't been released.

[Columbia]

7 hours ago, Snark said:

Fixing bugs is all about triage.

• There are a wide variety of tasks sitting on the developers' plates.  Example: fix a bug.  Example:  implement a feature.
• There are far, far, far more tasks than there is time to do them.  It's simply not possible to do everything at once.
• Therefore it is necessary to prioritize.  "We should fix this bug before we fix that one."  Or, "We should implement this feature before (or after) fixing that bug."
• Fixing one thing means not fixing something else.
• Prioritizing thing A over thing B is a function of several inputs.  It's a balancing act.  Examples of factors to consider:
  • How common is it?  (i.e. how many users are affected, how often)
  • How severe is it?  (i.e. when someone is bitten by the bug, or suffers the lack of the feature, how much does it impact game enjoyment)
  • How expensive is it to fix / implement and then test?  (e.g. is it a quickie that just takes a few hours for one dev, or is it weeks of effort for a team?)

 

I'll take the landing gear bugs of 1.1 as an example:

-That's true.

-And that's why some people -- myself included -- would have appreciated it more if Squad spent a little bit more time on the prerelease instead of having to patch twice. It's their call though. 

3, 4, 5: That's also true. I can't code for crap, but I'll try my best to answer:

--Pretty common, most people who use the low-tier landing gear have problems with it. Some wheels also lack proper braking.

--Not too severe but very frustrating at times. (In my experience)

--Well, there's a community stock patch out there so that means it didn't take them too long to trace the cause. (Kudos to whoever did that.)

 

Quote

You'll note that "how long has it been around" isn't in the list, there.  That's not to say that longevity is completely irrelevant-- just that it's a fairly minor consideration compared with frequency, severity, and expense.

I understand that it can be frustrating (even infuriating) to see what looks to you like a bad bug go on and on forever and not get fixed.  However, bear in mind that you don't have the full picture.  There are reasons why a bug does or doesn't get fixed.  But when you're only seeing a small piece of the puzzle, it can lead to very inaccurate assumptions.

Some specific problems that can lead to misunderstandings:

• You don't know how bad the problem actually is.  It can be hard to estimate how common or severe a problem is, either for you as a user or for Squad as a developer.  Consider the "clamshell fairings" feature.  If I weren't in the habit of following the KSP forums, I might have looked at that feature and thought:  "Well, damn.  That's dumb.  Squad did a stupid thing.  Why on earth did they waste even a single engineer-day on that irrelevant, useless feature that has no impact on gameplay and isn't really much in terms of eye-candy?"  Because to me, that's what it is.  However... there are a lot of folks out there who really care about it and are extremely vocal.  If I hadn't heard those folks' input, it never would have occurred to me that this is an issue that anyone actually cares about.  The fact is, different people have different opinions about things.  What one person considers a "game-breaker," another person doesn't even notice, because of differing play style or whatever.  So just because something affects you, even affects you very badly, doesn't necessarily mean it affects enough people to make it higher-frequency or higher-severity than some other issue.

But in the case of the landing gear bugs, it does affect many people who even fly a plane. Game-breaking might be an exaggeration, but it's a pretty big problem if you're considering that it's pretty much essential to the operation of aircraft and landers.

 

Quote

•  
• You don't know how bad are the other problems that got fixed instead.  Part of what makes software development a thankless task is that often, when you're doing your job best, is when nobody notices that anything's wrong.  Yes, that bug that's been nagging you since forever is annoying.  But would you rather have another bug instead?  One that's even worse?  One that you never heard about because somebody already fixed it when they were still in QA, or in experimentals?  Because there are plenty of bugs out there that you never heard of.
•  

I don't want to crap on Squad just because one bug's here and another isn't, but in this case, it's irrelevant if we're discussing the prominent bugs that are there. And it's scenarios like this that make some of us believe that if a little more time was spent on the prerelease, it might have been better for Squad than having to release patches. Even in the prerelease were there people reporting and complaining about the landing gear bugs. 
 

Quote

• You don't know how expensive it would be, in terms of engineering time, to fix.  If a bug is mildly annoying, but stupefyingly expensive to fix... yeah, it's gonna be on the bottom of the pile, and will likely hang around a long time.  If you're not a software engineer-- and even if you are one, but aren't familiar with the internals of the code in question-- then you simply have no clue about the relative difficulty of fixing a particular problem.  Something that looks really simple might actually be incredibly hard.  The "burn time" indicator is an example-- it's rudimentary, it's inaccurate, it's annoying.  Several months ago I couldn't stand it any longer, and thought heck, I could do better than that myself, why don't I write a mod.  So I did.  And it actually works pretty well... but it turned out to be a lot harder than I expected, took me weeks to do, and even so, it has to make certain simplifying assumptions that it can only get away with because it's a mod and not part of the stock game.  Having been through that experience... I'm no longer inclined to kvetch at Squad for not having taken care of that yet.

I don't, but seeing that there are community patches to fix this and exactly this, I'd say.. around a few days/hours. I don't know fully though. It's a rough figure and probably inaccurate, but still gives an insight into the complexity of the bug. 

Quote

Squad, unlike you or me, does know how expensive the features are to implement.  Squad, unlike you or me, does have full visibility into all the problems (including the ones you never heard of).  Squad doesn't necessarily have omniscience into frequency/impact ... but they've got a pretty good idea there, in general they know that better than the average player, and it's abundantly clear that they spend a lot of time reading these forums to keep themselves up to date on that.

So all in all... I'd say they know what they're doing.  They certainly know what they're doing a lot better than anyone who doesn't work there is in any position to say.  I have seen nothing from Squad to indicate that the folks there are incompetent at developing, testing, or triaging.

If this all sounds like I'm telling you "don't worry your pretty little head, trust Squad" ... well, yeah, that's galling.  But honestly, that's about all you can do.  When you see a bug, speak up about it-- by which I mean, provide useful information about it if it's something Squad doesn't know already; and if it's a severe impact on your game experience, speak up about that, too.

Yes, they do know what they're doing. Yes, they've worked hard to make the full release playable for as many as possible. And yes, we as a community don't know much about what is behind the scenes. But what we do know is that it might have been better had they spent a little bit more time -- say, a week -- in the prerelease. That way, they'd have more time to sort through the bug reports. I know they're not incompetent, I know they work hard, but more time would have been better than having to release two-three patches after release.

9 hours ago, FullMetalMachinist said:

It's not our business to have an opinion? 

This poll and thread are about discussing how we would have felt if things went a different way. Not to tell Squad what they should have done. 

This. I mean, Squad has the freedom to their decisions, but this is what I and we as players of the game feel KSP would have benefited from. 

[Reactordrone]

Second option for me. 1.1.2 at fixed a lot of the landing gear/strut issues making the game more playable. Leaving those bugs for another three weeks would have been bad and I probably would have reverted to my 1.0.5 game.

[razark]

I would have preferred Squad not have gone "beta" after 0.24.  It's been an endless stream of "Why are you doing this?" since then, and the response has always been "We have a choice, we're not being forced, but we have to do this now for undisclosed reasons."

Edited May 30, 2016 by razark

[Sandworm]

Working hard and not being "incompetent" are the minimum for any business.  But you can be a genius, work very hard, and still churn out junk.  I would like to see squad up their game by hiring a proper QA team.  That doesn't mean a handful of recent grads "playtesting" on their home machines.  That means an array of hardware/OS combinations in a lab environment, a regimented and scientific approach.  That means getting ahead of bug reports.  A community-reported bug should be seen as a failure, a bug that wasn't detected in-house prior to release.

From the plethora of bugs, including those that have been with KSP for a year or more, I suspect a morass of technical debt is home to roost.  Continuing the same scheme that built the debt mountain isn't a solution.  "High fliers" need to have their wings clipped and be replaced by a strong team dedicated to code review.

[steve_v]

My gripe has very little to do with 1.1.2, rather that 1.1.whatever was released at all with outstanding critical bugs.
Minor post-release patches to deal with minor bugs, cool. Post-release patches that still don't fix (IMO) release-blocking critical issues, not cool at all. If 1.1.1 / 1.1.2 had actually fixed the crashing, I would be playing rather than complaining. Whether that was 3 weeks ago or yesterday is beside the point.

[AlamoVampire]

i would have preferred they NOT release 1.1.0 at all until after taking the proper time to completely check it out. rushing it out the door followed by two rapid fire patches that did not fix the huge issues we have with the crashing did not help their image. They should have said we are going to go on vacation to get some rest and come back, finish up 1.1.0 and then launch it. meeting deadlines is fine and well, but, when you meet deadlines with broken products or products that are badly flawed is just failure. Some how, not sure who is to blame here, but, some how, the issue with unity slipped past someone or everyone or no one <last one scares me to death> and 1.1.0 was launched. then 2 swift patches that did nothing to address the major issue didnt help. 

I hope they got the rest they sorely needed, I really do, because they have a mountain to fix now. MAYBE 1.1.3 will start the stability and 1.2 will weld it down, but, it needs fixing. Now, if you dont mind, I am going to go and cry for my cat now.

[steve_v]

12 hours ago, AlamoVampire said:

i would have preferred they NOT release 1.1.0 at all until after taking the proper time to completely check it out.

I'd say much the same, but I'd replace "check it out" with "actually fix the known issues".
The crashing was raised during pre-release, either the "fixes" were not tested properly, or for some unfathomable reason it wasn't considered worth the effort to fix before release.

12 hours ago, AlamoVampire said:

two rapid fire patches that did not fix the huge issues we have with the crashing

And there it is.
Why, after 2 rapid-fire patches, does this thing still crash to desktop? Sure fiddling with wheels was important (note they are still lousy), maybe even important enough to warrant a couple of patches. Was it more important than game-engine crashes... I think not.
That this instability has persisted through two patches already does not inspire confidence in a timely resolution.

What I would like right now is some assurance that 1.1.3 will actually fix the crashing. Regardless of when said patch is released, CTDs should be priority one.
Or one could just mess around with the wheels some more I guess, it's probably easier.

[AlamoVampire]

@steve_v i am neither defending nor attacking how this went down, but, from what I can tell this is a unity thing what with all my crashes since 1.1.X came to be list with it showing NTDLL.DLL <caps for illustrative purposes> as part of the issue, and the thread I started on that particular subject lists this as Unity and its MONO/memory issues...so im not sure who is at fault here, squad? unity? both? i cant and wont say, but, its a mess pure and simple.

[cantab]

7 hours ago, Sandworm said:

From the plethora of bugs, including those that have been with KSP for a year or more, I suspect a morass of technical debt is home to roost.

Based on some of the more bizarre bugs I've seen in KSP, both stock and with mods, I agree with this. I imagine KSP is a considerable mass of spaghetti code. I also imagine that spaghetti code is the norm in video games.

 

[HoloYolo]

I'm a little late, but if SQUAD just decided to take a random vacation for almost no reason with no released updates, I'd be pretty upset that they did that out of the blue, unless it was for important and/or private matters.

[Cerberus738]

23 hours ago, Mike Mars said:

I paid $17.99 for this game two year ago.

I have enjoyed 1,050 hours of game play.

That works out to less than $.02 per hour.

For that kind of value, I will take the occasional inconvenience caused by upgrades.

MM

^This

[Starwaster]

You forgot voting option #5: 'I have not complained at all because it's none of my damned business.'

[TimePeriod]

15 minutes ago, Starwaster said:

You forgot voting option #5: 'I have not complained at all because it's none of my damned business.'

I wish I could vote for that too.

Too many angry hipsters in this forum, not knowing when to shut up.

[Bloody_looser]

26 minutes ago, Starwaster said:

You forgot voting option #5: 'I have not complained at all because it's none of my damned business.'

Exactly.

 

I've worked my ass off and really looking forward to a vacation in July. And I dare anyone to complain about that.

[The_Rocketeer]

25 minutes ago, Starwaster said:

You forgot voting option #5: 'I have not complained at all because it's none of my damned business.'

 

8 minutes ago, TimePeriod said:

I wish I could vote for that too.

Too many angry hipsters in this forum, not knowing when to shut up.

Option: didn't complain, wouldn't complain.

You personally: haven't complained, wouldn't complain (ever).

Where's the issue?

[m4v]

1 hour ago, TimePeriod said:

I wish I could vote for that too.

Too many angry hipsters in this forum, not knowing when to shut up.

Aren't you breaking a rule somewhere with this inflammatory post?

[TimePeriod]

22 minutes ago, m4v said:

Aren't you breaking a rule somewhere with this inflammatory post?

A spade is a spade, might as well say it as it is rather than cover it in bubble-warp, put up a warning sign, a fence and a guard. 

[Glaran K'erman]

12 hours ago, Red Iron Crown said:

I am amused by the notion that people would have been content for them to take a longish vacation before releasing, during the testing period. I'm fairly confident that the forum would have gone nuts. "How can you take vacation when the prerelease testing is still going on?!?!"

I agree that would not be ideal, but how would you feel if they took their break a 2-3 months before release? I understand the need to recharge, but when and what for should be thought about carefully. I just wish they had done all necessary head cleaning before going into a prerelease/release phase and used that energy to address the inevitable issues.

[Red Iron Crown]

19 minutes ago, Glaran K'erman said:

I agree that would not be ideal, but how would you feel if they took their break a 2-3 months before release? I understand the need to recharge, but when and what for should be thought about carefully. I just wish they had done all necessary head cleaning before going into a prerelease/release phase and used that energy to address the inevitable issues.

That's a bit outside the scope of the options presented here. That said, it seems like that would be the better plan (or significantly after release would work, I guess). My bet is the schedule slipped enough to put vacations precariously close to release time, but who can say?

[Dispatcher]

I think Squad should just release updates after they have been thoroughly tested (with or without the open beta tests).  I can wait.  One reason is that modders can update mods once instead of having to do so multiple times following a patch or two on the heals of a hasty update release of KSP.  Yes, I think Squad released 1.1(.2) prematurely.  This forces me to wait until at least 1.1.3 to see results that I feel would be comparable to the quality state of 1.0.5.  I also have no desire to play "betas"; there are plenty of other people who will play them but again, I am willing to wait for  quality "official" updates.