How have things that have made the game unplayable made it into 1.1.3?

[glen.mack]

This is every ship I build now...

https://drive.google.com/file/d/0B_Yczh052bfRd3F1ZmdGcWJ1WDQ/view?usp=sharing

Exactly the same problems after I gave up on KSP, deleted everything (shift + deleted the folder) and redownloaded.

EDIT: I'm not asking for help, I just want there to be a discussion as to why this type of behavior is even happening at this stage of the game.

Edited July 22, 2016 by glen.mack

[Superfluous J]

Does every ship you build have clipped parts and extra struts? Or do 10-part rockets with no clipping dance like zombieland 2 as well? I ask because I have also had problems with too many struts causing ships to shake. I've yet to have one vanish on EVA though I've heard of it.

Also, I note you are at exactly 100km in a very circular orbit, 2 minutes past zero-time, and have Hyperedit installed. Did you place the ship in orbit using Hyperedit? 100km is a special height, right where they physics changes over from relative to the ground and relative to... uh... not ground. I don't know the terminology, but hanging out right there causes problems. Try hyperediting your craft to 110km instead.

And finally, have you tried recreating the problem without any mods installed? It is possible that one of your mods or an interaction between mods is causing the problem.

[foamyesque]

Phantom forces like that are usually, in my experience, the result of clipped parts banging against each other. Can you duplicate the problem with simpler crafts?

[glen.mack]

This is directly after I decouple the ship from anything, booster/other parts, yes, there is a physics "update" between it being fine and it doing this, which is basically what you're saying.

However, hyperediting the "base" version of this into a 100km orbit gives 0 problems. The problem comes when I want to detach it from any other ship, considering it's only purpose is to be a glider and ore processing unit, it renders it pretty much useless.

Yes, I have replicated the problem sans hyperediting.

In fact, the reason I deleted everything was because not only was this happening, but the camera was just falling away from full size rockets.

 

On top of this, if you dock two of them together, only the one focused on suffers issues when they undock.

Edited July 22, 2016 by glen.mack

[KerikBalm]

Wow... I was expecting to find something obviously wrong and to just call you a complainer... but... yea, that is strange...

I had some strange issues with this thing, where at certain parts of mun orbit I'd get rover wheels in the cargobay exploding if I wasn't in time warp. And at other parts I'd start to get shaking, put only at certain part of the orbit (I think there was a relationship with its angle to the surface) - I think it was partly bececause of its reliance on wheel autostrutting to hold it together with strategically placed airplane wheels.

I didn't have anything that major, and was able to fly it all the way back to kerbin and land it fine... haven't had similar issues... so I don't know what is happening on your designs that causes that, but I'll agree that it shouldn't be doing that.

And it doesn't seem to be normal struts either... although I have cut down on them since wheel autostrutting became a thing, this still uses some... and no zombieland dances...

I don't know what is wrong with your ship/the game. You have my sympathies

[Brainlord Mesomorph]

I have lots of experience with the spaceship shaking itself apart bug.  I started this thread and this one  when I had a similar problem when I undocked the last tanker from my Eve cruiser.  I eventually did build by assembling things in a different order, and I got documented different results between the first time I would try a given experiment after starting the game, vs reloading.  Specifically, better results the first time. 

Now that I’ve gotten it to Eve, when I undock a lander it starts to shake again!  I undocked a different component from the front of the ship first, then I can undock the lander.  But now the ship is in two parts in Eve orbit and I don’t know what I’m going to do.

And then this weekend, had the exact same problem with a clump of base parts that I had docked together in orbit of Minmus in preparation of bringing them to the surface.  This time, it began as I moved fuel from one tank to another.  I would put the fuel back and the shaking would stop.

So I’ve come to the conclusion that it has something to do with the CoM moving through the ship.  Perhaps as the COM moves between two parts(?) it causes a shockwave which eventually hits the COM and moves it back, which starts another shock wave, etc etc,

oh, I was having this in 1.1.2 (was hoping 1.1.3 was going to fix it)

Edited July 22, 2016 by Brainlord Mesomorph

[Foxster]

I've not had quite that bug - fortunately. But I have had some stuff a little like it. 

First problem has been with EVA too. If I EVA a guy and don't move him on the craft's ladder and hit B then he enters a Schroedinger's Cat state of being both in the craft and out. Both the Kerbal and the craft are uncontrollable. The workaround being to make sure to move the Kerbal about before re-entering the craft. 

Second bug is when the CoM and CoL are right on top of each other. As the craft moves and the CoL shifts slightly it can start to hop about the CoM and shaking can start. Workaround is to make sure that the CoM and CoL stay apart no matter the fuel levels. You can display the CoM and CoL in-flight with MJ. 

Edited July 22, 2016 by Foxster

[Corw]

20 minutes ago, Foxster said:

I've not had quite that bug - fortunately. But I have had some stuff a little like it. 

First problem has been with EVA too. If I EVA a guy and don't move him on the craft's ladder and hit B then he enters a Schroedinger's Cat state of being both in the craft and out. Both the Kerbal and the craft are uncontrollable. The workaround being to make sure to move the Kerbal about before re-entering the craft. 

Second bug is when the CoM and CoL are right on top of each other. As the craft moves and the CoL shifts slightly it can start to hop about the CoM and shaking can start. Workaround is to make sure that the CoM and CoL stay apart no matter the fuel levels. You can display the CoM and CoL in-flight with MJ. 

Schroedinger's Jeb bug, lol

[cantab]

"How have things that have made the game unplayable made it into 1.1.3?"

Because Squad work to 'deadlines' set by upper management with no regard of whether KSP is actually in a fit state to release, do not have adequate QA and testing procedures in place, and are suffering from a large amount of technical debt - program code and design that is buggy and difficult to maintain - because they've spent five years operating that way.

[klesh]

22 minutes ago, cantab said:

"How have things that have made the game unplayable made it into 1.1.3?"

Because Squad work to 'deadlines' set by upper management with no regard of whether KSP is actually in a fit state to release, do not have adequate QA and testing procedures in place, and are suffering from a large amount of technical debt - program code and design that is buggy and difficult to maintain - because they've spent five years operating that way.

That really explains how the game went from years of Alpha updates to one "Beta" phase patch, then right to 1.0 after only 4 months.

[Majorjim!]

2 hours ago, foamyesque said:

Phantom forces like that are usually, in my experience, the result of clipped parts banging against each other. Can you duplicate the problem with simpler crafts?

Clipped parts do not 'bang' into each other. Parts of the same craft ignore collision except wheels and legs and that is due to a bug fix. Even that will be gone in 1.2.

 

1 hour ago, KerikBalm said:

I'd get rover wheels in the cargobay exploding

That is due to them having collision with the parent craft and getting over stressed. It will be gone in 1.2.

Edited July 22, 2016 by Majorjim

[Snark]

5 hours ago, glen.mack said:

I'm not asking for help, I just want there to be a discussion as to why this type of behavior is even happening at this stage of the game.

I understand that this must be really frustrating (even rage-inducing) to you.  Heck, if it were happening to me, it would be really frustrating for me, too, and I would be very unhappy.  If this happened frequently to me, it would pretty quickly become a gamekiller that ruined my enjoyment, and I'd probably wander away from KSP, at least until they fixed it.

The answer to your question is simple, and comes in two parts:

• Because KSP is software.
• And because all software has bugs.

Not sure what you mean by "at this stage of the game".  Given that "this stage of the game" actually is "right after a huge overhaul of pretty much all the code in the game", then yes, this stage of the game is exactly when I'd expect there to be lots of problems.  It's how software works.  You take an intricate, carefully crafted machine with thousands of moving parts and rummage around in its innards, you're going to break stuff.

Of course, I'm being a little facetious there-- I expect that what you really mean by "at this stage of the game" is "when it's been out such a long time, and there have been so many updates," with the implicit expectation that the software ought to get more and more stable over time.  Speaking as a professional software engineer who has been doing this for a living for over twenty years, I can tell you that yes, sometimes it works that way.  For example, if you have a piece of software that's on "life support"-- i.e. development work has stopped, they're just "keeping the lights on", and the only updates that ever happen are bug fixes.  In that case, yes, it's going to get more and more stable over time.  Another example is if you have a product that is purely additive:  i.e. the only thing they're doing is to add brand-new features, and never ever touch the old ones at all.  In that case, you'll often (but not always) have bugs that are mostly limited to the new stuff, and at least the old stuff that used to work won't stop working.

Both of those cases happen in the real world, and both of them have a bug "glide path" that looks like what you're probably expecting.  Except that KSP isn't either of those cases.  It's a product in active development, where they're going in and making major changes (including overhauling existing code), and it's completely unavoidable that bugs are going to creep in and stuff is going to get broken.

Of course, nobody wants to ship broken stuff.  Like any developer, Squad puts a lot of effort into trying to find and fix bugs before each release, so that players don't get smacked with 'em.  And they catch and fix a lot.  You don't ever get to see that, of course, since you only see what actually gets released.

But it's simply not possible to catch all of the bugs:

• It's not possible to find them all, before shipping.
• And even when they are found before shipping, it's not possible to fix them all-- there are going to be some cases where a developer has to make the difficult choice to go ahead and ship with the bug.

Because everything is a tradeoff.  If you've never written software for a living, and you only have a player's perspective, that tradeoff may be difficult to understand.  From your perspective, it's never okay to ship with a bug.  You fix the damn thing before shipping, it seems like a total no-brainer, right?

Except that there are lots of reasons why a bug-- even a really serious game-breaker such as you're experiencing-- can end up going out the door.  And by "lots of reasons", I mean lots of good reasons, which aren't "because the developers are idiots" or "because the managers are idiots" or because someone is evil or whatever.  Some examples of good reasons why a bug goes out the door:

• Because they didn't know about it before it shipped.
  • It's simply not possible to find all the bugs.  Yes, you can hire a QA staff and have them test it a lot... but it's mathematically impossible to test every conceivable combination, especially if you're on a budget and don't have hundreds of full-time testers.
  • Remember that how bad the bug is has nothing at all to do with how hard it is to find, if it only happens in very specific circumstances that nobody knew to check.
  • For example, your bug sounds like a terrible gamebreaker.  But it also seems pretty rare to me.  Not rare to you, of course... but rare across the player base.  The overwhelming majority of players don't have that problem; for example, it's never happened to me, even once.  I make that "overwhelming majority" assertion, because if something that horrible did happen to a significant fraction of the player base, everyone would be screaming bloody murder over it and it would have been much higher on the radar and Squad would have either fixed it in 1.1.3 or else addressed it in some fashion in devnotes or something.
• Because it affects only a very small number of people.
  • Just as a hypothetical example:  Suppose that a game developer does know that there's a horrible gamebreaker of a bug-- one that completely ruins the experience for a player-- but that it only affects, say, one player in a thousand.
  • And also suppose that the bug is a really hard one-- that fixing it would take months of work, and/or be very risky for destabilizing other things.
  • In that case, a developer may make the decision that it's better to ship with the bug-- and it's the right decision. It's a case of the needs of the many outweighing the needs of the few.
  • Yes, it really sucks if you're one of the few.  Can't be helped.
• Because the risk of fixing it would be too high.
  • Sometimes a doctor may find a medical problem in a patient that they'd really like to fix with some surgery... except that the surgery itself comes with risks.  If the medical problem is located right next to a dense nest of really important blood vessels or brain tissue or whatever, the doctor may have to decide to do nothing about it, because the risk of the surgery would outweigh the risk of the problem itself.
  • The same thing sometimes happens with software.
• Because it can't be fixed due to factors outside the developer's control.
  • For example, if your product is based on a third-party engine that's outside of your control, and you've already spent a year migrating your product to a new version of that engine so you're irrevocably committed, and you discover shortly before launch that there's a really serious problem that's tied to the engine itself and can't be fixed on your end, and the only way to address it is to wait for a new version of the engine, except that you don't know exactly when that release may be and in any case it's likely months into the future and you can't afford to slip your own ship date for that many months.
  • In that case, you ship.

In the particular case of the bug that's affecting you, I don't know why it's there.  Nor do you.  Nor does anyone outside of Squad.  I suppose it's possible that it could be "because they're incompetent" or "because they don't care about players"... except that based on reading the forums a lot over the last couple of years, I'm inclined to say that neither one of those is the case-- far from it-- so if anyone's asserting either one of those, I'd like to see some citations of evidence.  On the other hand-- there are lots of potential good reasons why this could happen, as described above.

I'm not saying that I know anything more about what goes on inside Squad than you do-- I don't work for them, I don't have any more information than yours.  I'm just basing this on my 2+ decades of experience in the industry, doing this for a living.  Everything I'm seeing here strikes me as simply being par for the course.

So unless you actually have some insider information and know that the reason for the bug is a "bad one", perhaps not be so hasty at jumping to the conclusion of guilty-until-proven-innocent?

...Of course, for you, all that is just so much hand-waving and nice-nice noises, right?  "That's all well and good," I hear you say, "but what do I do?  I've got a broken game here, what the heck am I supposed to do?"

Well, you can help Squad fix it. 

Aside from reporting the bug, it just so happens that sal_vager just posted a challenge that may be right up your alley:

As long as your bug is, 1. easily reproducible with your .sfs file, and 2. you're reproducing it in a pure stock game... please post your save as requested in that thread!  Essentially, Squad is coming to you on bended knee and begging you to help them help you.

Sharing your bugged save is exactly the kind of thing that Squad is begging you for, so they can fix the problem.

 

2 hours ago, cantab said:

"How have things that have made the game unplayable made it into 1.1.3?"

Because Squad work to 'deadlines' set by upper management with no regard of whether KSP is actually in a fit state to release, do not have adequate QA and testing procedures in place, and are suffering from a large amount of technical debt - program code and design that is buggy and difficult to maintain - because they've spent five years operating that way.

Citation, please?

I assume that you're not asserting that "this is bad because there are any bugs", since we all know (right?) that all software has bugs.

Rather, I'm assuming that you're asserting "this software is at a lower quality than it should be, and Squad is blameworthy for the amount of bugs that are in there."

I'm not asserting you're wrong-- simply that you haven't given any evidence that you're right.  To make such an assertion implies that you have a reliably "correct" idea of what the level-of-acceptable-bugs should be, which implies industry experience.

Squad has taken on a big project.  Physics-intensive games are pretty rare; it's a really hard problem that introduces all sorts of really difficult O(N²) complexity to solve.  Most games don't come even close to solving the difficulty of problem that KSP has to solve.  When someone's trying to solve a really hard problem, there are likely to be more bugs than a game that isn't pushing the envelope.

Now do that as a really tiny indie studio, where you don't have the budget of a Blizzard or an EA and can't throw hundreds of engineers and QA testers at it.  Again, you're going to have a higher bug quotient than the big boys.

And even at that-- I think Squad's doing a pretty good job with what they have.  I've been a computer-game nerd for over thirty years, and have played an awful lot of games.  Frankly, all of them had bug problems to one degree or another, even the ones that didn't have to contend with shifting sands such as multiple platforms or a mod-intensive environment.  KSP doesn't strike me as being especially more buggy than other games I've played, even ones solving simpler problems with bigger budgets.  Squad's batting way above their weight here, so I'm inclined to cut them a bit of slack.

[Guest]

Man, if I had a dollar for every time Snark dropped that novel (or a version thereof) on the forum I'd be a rich man.

[Foxster]

4 minutes ago, regex said:

Man, if I had a dollar for every time Snark dropped that novel (or a version thereof) on the forum I'd be a rich man.

Fan-boys, uh?

[Snark]

35 minutes ago, regex said:

Man, if I had a dollar for every time Snark dropped that novel (or a version thereof) on the forum I'd be a rich man.

31 minutes ago, Foxster said:

Fan-boys, uh?

Not a fan-boy, just someone who actually does this for a living, and has been doing so for a couple of decades, and therefore has a certain amount of perspective about how things actually work in this industry.  (And you'll note that most of my post isn't specifically about Squad, anyway, just about the software industry in general.)

There are plenty of cases of player pain, and plenty of things that KSP does that players are legitimately unhappy about.  Heck, there are plenty of things that I'm unhappy about, and I'm not shy about posting about them, either.  And you don't see me following around with a mop trying to "correct" or "explain" every single instance of somebody expressing something about the game that they're unhappy about.

A player can always legitimately complain about their personal experience with the game-- because that's something within their sphere of knowledge.  Every player is the ultimate authority on what makes that player unhappy about the game experience.  So of course they're within their rights to complain, because they know what they're talking about, by definition.

For example, suppose the OP in this thread had simply said "Here's this terrible thing, it happens to me all the time, I hate this and it's ruining my game.  I really wish Squad would get off their duffs and fix this."  In that case, I would have cheerfully held my peace.

What I do take issue with is when people start complaining about something they don't actually know about, e.g.  software development process.  (E.g. changing the statement from "I don't like this" to "This shouldn't be happening for this stage of development.")

I understand the frustration, really I do.  I've got plenty of friends and relatives (i.e. just about all of them) who aren't software engineers, and of course any time they have a problem with somebody's software, they come to me for tech support.  Occupational hazard of being the resident tech geek. 

And the one universal constant I've experienced is that people who haven't done software for a living have no clue whatsoever how hard it is.  Even when you tell them "it's hard", they still don't really grasp why it's hard, or just how hard.  You pretty much have to do it for a living to understand that.

So when I see a thread get started that consists of people making assertions or implicit assumptions about an area that they don't have personal experience with, and the "echo chamber" gets going... yeah, I like to inject a drop (or in my case, a gallon, usually... sigh) of reality into the discussion.

So I'll stop posting explanations of How Software Development Works as soon as I stop seeing discussions of commercial software development practices by people who aren't familiar with commercial software development practices.

By which I suppose that means "never," but oh well. 

[Guest]

29 minutes ago, Foxster said:

Fan-boys, uh?

Yeah, I always have been.

[Ozzallos]

4 hours ago, Corw said:

Schroedinger's Jeb bug, lol

So if you stick Jeb inside a capsule, is he dead or just waiting to max the throttles?

Edited July 22, 2016 by Ozzallos

[Champ]

42 minutes ago, regex said:

Man, if I had a dollar for every time Snark dropped that novel (or a version thereof) on the forum I'd be a rich man.

what he says is right, but he says it too many times ?

Sorry, i can't understand.

[Foxster]

I think it depends what kind of development you've done. 

I've spent 25 years working in IT, doing development in more languages than I can remember. This is big corporate stuff for a major TelCo. You can't afford to mess about and throw stuff out there and if it doesn't work then try again - you get it right first time or the country's telephones stop working. So I know it is perfectly possible to get it right first time if you have the right people, processes and skills.  

That's why it annoys me when sloppy development, release management and testing leads to the mess that the "production release" of KSP is. I mean, they had a half-decent product and by "upgrading" Unity they managed to introduce loads of seemingly unforeseen bugs that they don't know how to fix and have no timeline for.  But, hey-ho, it doesn't matter because software development is hard and apparently it always goes wrong  - well not in my world it doesn't.

7 minutes ago, Ozzallos said:

So if you stick Jeb inside a capsule, is he dead or just waiting to max the throttles?

Both 

Edited July 22, 2016 by Foxster

[Greenfire32]

5 minutes ago, Foxster said:

That's why it annoys me when sloppy development, release management and testing leads to the mess that the "production release" of KSP is. I mean, they had a half-decent product and by "upgrading" Unity they managed to introduce loads of seemingly unforeseen bugs that they don't know how to fix and have no timeline for.  But, hey-ho, it doesn't matter because software development is hard and it apparently always going wrong  - well not in my world it doesn't.

Same here. KSP was (I would say) 95% stable before "upgrading" Unity.

Now we have random crashes, wheels don't work, landing legs don't work, orbital decay is much more pronounced (despite devs saying otherswise), phantom forces are out in full...force....but hey, we've got 64bit support now!

And the part that annoys me the most is that even if they had no idea the new version of Unity would break so much, once they had their build machines on it, they would have found out. And yet they pushed it out into the wild anyway...

Edited July 22, 2016 by Greenfire32

[Guest]

8 minutes ago, Champ said:

what he says is right, but he says it too many times ?

What he says is correct and it's sad that he has to say it so many times, especially now that Squad are communicating with the playerbase regularly and in detail.

[Violent Jeb]

[redacted, done contributing]

Edited August 16, 2016 by Violent Jeb

[Guest]

1 minute ago, Violent Jeb said:

The defense that KSP development is a Kobayashi Maru is all well and good until you look around and see lots of 1.0 physics or simulation games that are actually stable for a big portion of players. Games where there aren't a handful of uniform game breaking bugs and unintended behavior. This code just cannot be cracked!

Can you name a few?  The ways in which KSP allows you to build are pretty much infinite and the interaction between individual parts are unlike anything I've ever played.  KSP allows you to do some incredibly complex things.

[Archgeek]

6 minutes ago, Violent Jeb said:

The defense that KSP development is a Kobayashi Maru is all well and good until you look around and see lots of 1.0 physics or simulation games that are actually stable for a big portion of players. Games where there aren't a handful of uniform game breaking bugs and unintended behavior. This code just cannot be cracked!

'You miss the part where they're also dealing with a mountain of technical debt?  That's well-known for frustrating efforts of this sort.

[Violent Jeb]

[redacted, done contributing]

Edited August 16, 2016 by Violent Jeb