Random failures of experimental parts

[fairytalefox]

Yep, I'm aware of our "do not suggest" list. And I think the devs are right when they say "we don't want you to fail a mission because of RNG, KSP is not a casino".

What I'm going to suggest here is something else.

Since 0.24 we have contracts. Some of them are like "test part X in situation Y". Some of these tests involve "blue" parts that aren't unlocked by the tech tree yet and are (I believe) supposed to be sort of work in progress rather than just parts of another color. And these tests sometimes are, well, boring. Bring part X to situation Y, press space bar, done. You usually already know the result even before taking a contract, and this is IMHO completely wrong. Because what is the point? Why we call it "test"?

Let's make these "blue" parts to do random and weird things. Like, for example, a decoupler at the launch pad does KABOOM and the whole ship is gone by the wind. Or "Mainsail" suddenly casts "x10 thrust, x50 fuel consumption, full throttle and stop responding" on itself. Or something else.

Pros:

1. It does not fail missions randomly (unless you are Kerbal enough to use a highly experimental heavily duct-taped something-that-looks-like-an-engine in your first manned Mun landing).

1.5. It explicitly separates "test" missions from "science" ones. I. e. more different gameplays for your money.

2. It is realistic, fun and not hard to play with. All at the same time.

3. It isn't (probably) too hard to implement.

4. More KABOOM! For SCIENCE and FUNDS!

Cons:

I don't see any.

[JokingHinge]

If this is added, there should be a warning stating it might fail at any time.

[fairytalefox]

If this is added, there should be a warning stating it might fail at any time.

I believe it's exactly the thing the word "experimental" stands for. Especially when we're talking about rocket engines or explosive-driven decouplers.

[BudgetHedgehog]

Like, for example, a decoupler at the launch pad does KABOOM and the whole ship is gone by the wind. Or "Mainsail" suddenly casts "x10 thrust, x50 fuel consumption, full throttle and stop responding" on itself.

Right, because that won't be annoying at all. This is why Squad is against random failures - they want everyones experience to be the same. If one person presses Space at X altitude and Y speed, the exact same thing should happen to someone else who presses Space at X altitude and Y speed. Having this just randomly fail results in one of two things - A, ragequit because the thing that failed is integral to your design and you've spent the past 2 weeks getting to this stage or B, revert to launch. Neither of these increases enjoyment of the game by any means.

Also, what you are suggesting is exactly the kind of thing that is both against Squads wishes and on the WNTS list - random failures. It doesn't matter if the parts are well-proven or experimental, a random failure is a random failure.

[fairytalefox]

Contracts are random.

Asteroids are random.

This is why Squad is against random failures - they want everyones experience to be the same.

So no, they don't.

Having this just randomly fail results in one of two things - A, ragequit because the thing that failed is integral to your design and you've spent the past 2 weeks getting to this stage or B, revert to launch.

Did you do any of these contracts? Because all and every of them run in exactly the same way: transport part X to situation Y; do the test; terminate flight. I don't understand what ragequit you're talking about. And making a part that is technically inaccessible (and will become really inaccessible after the test completion) "integral to your design" doesn't sound like a wise decision, too.

[BudgetHedgehog]

Contracts are random.

Asteroids are random.

So no, they don't.

True, the specifics are different, but everyone knows that if you have an asteroid of X tons travelling at Y speed at Z height above kerbin, you need to always apply the same amount of dV to it to capture it. Parts do not and should not differ in any way across players. That is what's meant by 'everyones experience is the same', not that 'everyone gets exactly the same contracts and asteroids'. Yes, you might get a contract that says 'test part A at between 24000m and 24025m and 450 and 455m/s' and no-one else might ever get that same contract, but the point is that if they do, the results of it will be the same as yours.

I don't understand what ragequit you're talking about. And making a part that is technically inaccessible (and will become really inaccessible after the test completion) "integral to your design" doesn't sound like a wise decision, too.

"Test Stack Decoupler landed on Tylo". A part that, no matter which way you slice it, is going to be pretty integral to your mission to test it. Even if it's not and it's just on a spare node somewhere, if a part has some random failure of any kind (explosions, stuck throttle etc), you've still spent all that time getting there only to have it ruined by something that you didn't even need to bring in the first place. It's either needed in your design, in which case your weeks of planning go out the window because it catastrophically fails, or it's not needed in your design and it messes up your weeks of planning by catastrophically failing anyway. I don't know about you but bringing the Kerbodyne 4x1 cluster out to Eeloo just tacked on the side on a spare node somewhere and then having it stuck at 100% throttle and using up my return fuel would be just the tiniest bit annoying. Why even bother carting it all the way out here if it (as a extraneous part) is just going to ruin the entire mission? I could just as easily done the exact same but without carrying all that unnecessary weight and trying to fit it on the craft in a reasonable way. It's either that or I depend on it for my return journey and it explodes.

EDIT: Also, as I said, "it doesn't matter if the parts are well-proven or experimental, a random failure is a random failure" and random failures are on the WNTS list.

Edited August 3, 2014 by ObsessedWithKSP

[fairytalefox]

I see some misunderstanding here.

In my personal expirience all the missions are either "test" or "routine". There never was one mission to have both tasks. Just because "flying 700 to 800 m/s 1000 to 1500 meters above Mun" is suicidal AND completely meaningless unless you have to stage darn Rockomax BACC SRB somewhere around there. So your whole mission is dedicated to one task. So you physically can't fail anything other than this particular test.

Now, all conditions are met, you run test, and that's all. It does not matter (in terms of success or failure) what exactly happens next because the test has been ran, so the contract is completed. This was a triumph, huge success. Yes, that part in testing does something strange. Or does as usual. Or does nothing. But who really cares? Not you.

I'll write down my key points again:

* Only "blue" parts. I. e. irregular parts outside of unlocked nodes of the tech tree. Typically unusable in regular designs at your current game progress.

* Only when they are "tested". Staged, or you click "test" button in their UI, or whatever is written in the contract.

* The contract is completed even if the part failed. It's completely consistent because the contract was "test it", not "do not fail it".

I don't know about you but bringing the Kerbodyne 4x1 cluster out to Eeloo just tacked on the side on a spare node somewhere and then having it stuck at 100% throttle and using up my return fuel would be just the tiniest bit annoying.

Yep, this would be a problem. Why not to decouple this funny little toy before running it? You don't need it onboard anyway. And if you are completely non-Kerbal type of mind (like myself), why not to put your main ship on the return course before runnibg the cluster, just in case?

On the second thought, you have the point. May be one's particular approach to such missions does matter, too. I don't know. In my case, it does not, but, well, people aren't the same.

But "a random failure is a random failure" is not a valid reason anyway. Random failure of a mission definitely isn't an option (gosh I hate with all my heart and mind those little funny miracles at SoI transitions), but a small firework at the end of the work, in my humble opinion, is.

[CaptRobau]

Contracts are random.

Asteroids are random.

That's different. First of they're not random, they're procedurally generated meaning they spawn according to a ruleset. You won't get Duna missions until you go to the Mun/Minmus, the payoff is based on distance and other variables, etc. Second it would completely remove crazy contraptions like this:

[fairytalefox]

Second it would completely remove crazy contraptions like this:

How can this be removed? You have a chance to lose your contraption, that's all. Minus ~10k funds, not a big deal. Oh, it's piloted...

BTW, nice craft

[Sirrobert]

Here's what will happen if your test mission randomly explodes:

Most of the people will sigh in annoyance, and than revert and do it again.

The rest, who doesn't like revert, will sigh in even MORe annoyence, since the game just randomly blew up a bunch of funds, and maybe even a Kerbal, and relaunch the test.

That's it. It'll be annoying, nothing else.

How exactly is that an improvement?

[CaptRobau]

How can this be removed? You have a chance to lose your contraption, that's all. Minus ~10k funds, not a big deal. Oh, it's piloted...

BTW, nice craft

Because people are building this to do a lot of test runs in a single mission. If you have parts that won't work as you expect them to on such an unstable design, then the chances of such an outlandish working safely are almost zero. Thus people will stop building them. As everyone else has said, random annoyances add absolutely nothing to the game, but frustration.

[technicalfool]

Hi. Thanks for the reports guys. A couple of us decided to let this one run because while random failures are on WNTS, this is something of a novel suggestion.

Personally, I think the tech tree could be tweaked to put one of the probe parts in a really low node. That would give you a way of testing some of the more highly-explosive parts (like engines) without risking kerbals. I don't know whether making a decoupler explode with the force of a small nuke would be that enjoyable, but certainly having it not do what it's supposed to do in some way would be in line with the fact that it's a test. Perhaps this instability would only apply to part tests for parts you don't yet have access to in the tech tree, and a successful test could move that part down a few nodes or just unlock it for you? Perhaps the chance of failure could be related to how many science points you currently need to get the part.

[Stargate525]

That's it. It'll be annoying, nothing else.

How exactly is that an improvement?

I would rather be annoyed than bored. And that's what these test missions are for me currently.

The fact of the matter is that, if your mission is to take something somewhere and test it, you don't make it a critical part of your vessel. Test an experimental jet engine, you don't make it the primary engine on your plane. Testing a decoupler, you don't make it detach crucial stuff.

And I don't think he's suggesting that a 'failed' part even fails the contract. You went there, tested it, and it didn't go as planned. What is the POINT of testing something if you know what the result is going to be?

[Zilentification]

Stargate525 has it right when he points out that you don't make a test mission component part of you vessel. You just shove it on at the end. Decouplers that Decouple nothing, Engines without fuel etc. I think a much easier solution to prevent this is for the mission to encourage use of the component. Instead of a mission reading "Go the Mun and test X." A mission could tell you to "Use X to get to the Mun."

I dislike the idea of part failure though. The problem is that this game doesn't give you a lot of troubleshooting options in relation to problems. Just imagine a scenario like this, while in orbit your ship starts rotating. Well, its easy to see whats causing the problem, you just switch to Third person view. A RCS engine is stuck on, so what do you do? You turn it off, or stop fuel flow and the issue is resolved. There is just no challenge to solve the problem.

Its interesting to note that I consider 3rd person one of the major hurdles that would need to be overcome. If your stuck in First person it could actually be a challenge to find what's wrong and solve it.

The trick is to make a failure fun, and with the current stock KSS I don't think that's possible. I believe part damage is currently planned (along with the capability to repair parts) and maybe then this could be looked at again.

[fairytalefox]

Thank you guys for support

this instability would only apply to part tests for parts you don't yet have access to in the tech tree

^ this. And yes, low-tech probe core would be a great help. We don't want to lose our fellow Jeb (anymore).

And I don't think he's suggesting that a 'failed' part even fails the contract.

^ and this. I definitely do not want to fail more contracts

Actually I think it would be good to have a rate of failure (for "failable" parts) extremely high, like 95%. So part's behavior stays kind of predictable, just slightly different In single-task missions it changes nothing, in multitask ones, well, you have to adjust your mission plan a bit in order to isolate a part in testing from it's mother ship. Just another engineering task.

[M3tal_Warrior]

I personally like the idea of random failures for testing components. I just don't think they should be like exploding the whole ship (unless you're testing a tank), because that's ridiculous - you only have so much TNT in a decoupler, the only things that could possibly happen are:

• failed ejection (TNT doesn't blow)
  
• failed ejection (TNT is too weak to separate the stages)
  
• ejection with force being applied in a different angle, rotating your ship and such
  

Same with engines. You should always be able to kill the fuel line, this is not an integral part of the engine itself. Engine not working, OK. Engine not responding to toggle, OK. Engine with not responding thrust vector, thrust slider, different thrust, ... perfectly reasonable. Even boosters can't really explode, reason being material density, thermoconductivity and reaction activation energy (sorry, guys, my job's talking here). Breaking apart, non-symmetrical burn profile, different thrust profile - now these are real life problems.

I think this would add a really nice component to the game. Take my like for the general suggestion.

[r4pt0r]

this would make it exciting when people use contracts only for early access to later tier parts

[Stargate525]

Same with engines. You should always be able to kill the fuel line, this is not an integral part of the engine itself. Engine not working, OK. Engine not responding to toggle, OK. Engine with not responding thrust vector, thrust slider, different thrust, ... perfectly reasonable. Even boosters can't really explode, reason being material density, thermoconductivity and reaction activation energy (sorry, guys, my job's talking here). Breaking apart, non-symmetrical burn profile, different thrust profile - now these are real life problems.

I like this. Reasonable issues, but not overt failure in most cases.

The one problem I see with this is that at the current game dev stage, these issues can be mistaken for bugs.

[fairytalefox]

I personally like the idea of random failures for testing components. I just don't think they should be like exploding the whole ship (unless you're testing a tank), because that's ridiculous - you only have so much TNT in a decoupler, the only things that could possibly happen are:

• failed ejection (TNT doesn't blow)
  
• failed ejection (TNT is too weak to separate the stages)
  
• ejection with force being applied in a different angle, rotating your ship and such
  

Same with engines. You should always be able to kill the fuel line, this is not an integral part of the engine itself. Engine not working, OK. Engine not responding to toggle, OK. Engine with not responding thrust vector, thrust slider, different thrust, ... perfectly reasonable. Even boosters can't really explode, reason being material density, thermoconductivity and reaction activation energy (sorry, guys, my job's talking here). Breaking apart, non-symmetrical burn profile, different thrust profile - now these are real life problems.

I think this would add a really nice component to the game. Take my like for the general suggestion.

Thank you.

Decouplers. What about such scenario: "let's put 20 pounds of TNT in this little guy as the spec suggests... or what does this little 'g' mean, may be grams? Nah, pounds are way better"... and two days later: "well, now it's scientifically proven that pounds aren't always better". In my opinion, it's pretty Kerbal way to gain knowledge

The one problem I see with this is that at the current game dev stage, these issues can be mistaken for bugs.

What about changing these parts color from blue to red? And BIG letters somewhere in the contract: "This part isn't tested yet, it might be dangerous to use it!"

Edited August 4, 2014 by fairytalefox

[M3tal_Warrior]

The one problem I see with this is that at the current game dev stage, these issues can be mistaken for bugs.

This is not a problem of the game but of communication. It can be solved easily, by just telling guys in the contract statement.

"let's put 20 pounds of TNT in this little guy as the spec suggests... or what does this little 'g' mean, may be grams? /snip

This is actually a reasonable way (in the Kerbal universe, that is). This is why one does these nice ground tests first. Afterwards one knows how much TNT is to be used (about, with higher altitudes you need less).

Would fit perfectly in my proposed system, I think.

Edited August 4, 2014 by M3tal_Warrior

[Stargate525]

What about changing these parts color from blue to red? And BIG letters somewhere in the contract: "This part isn't tested yet, it might be dangerous to use it!"

This is not a problem of the game but of communication. It can be solved easily, by just telling guys in the contract statement.

It's adorable you think people read.

[Kerbart]

Keep in mind that just because a part fails, the test doesn'tâ€â€The contract is testing the part, and it didn't work. I'm sure everyone agrees on this but it's good to get it out of the way.

Second of all, I think there's a fairly simple solution to what is described above that would meet all criteria, and also defeat the current wave (at least that how I am doing it) of unmanned probes that, with brutal efficiency, test 2 parts on the launch platform, 5 parts on the way up, 3 on the way down, and another two when splashed down. I know that HarvesteR loves those contraptions and for the first three times they're fun, but it gets old quickly.

This thread, and a recent bunch of contracts that had me lift a LFB KR1X2 into orbit (before staging it) and use that to get a KR2L into Munar orbit made me think... Things can be made a little bit more challenging if you require a Kerbal to inspect it (during an EVA). In some cases there might be an additional requirement to inspection ("in orbit") and maybe in some cases a second "run test" gets unlocked after an inspection.

Maybe the inspection reveals a "part failed" result which unlocks a new contract to repair/redo the test (eva: "reset part")

[Stargate525]

This thread, and a recent bunch of contracts that had me lift a LFB KR1X2 into orbit (before staging it) and use that to get a KR2L into Munar orbit made me think... Things can be made a little bit more challenging if you require a Kerbal to inspect it (during an EVA). In some cases there might be an additional requirement to inspection ("in orbit") and maybe in some cases a second "run test" gets unlocked after an inspection.

Can't be done in flight.

[fairytalefox]

It's adorable you think people read.

People do discover somehow what to do in order to complete the contract. By reading it, or by looking into crystal ball, or by eating shrooms endemic to Kerbin, I don't know exactly. Anyway, lacking some essential skill and thus failing your mission is a legit part of the gameplay.

[fairytalefox]

Can't be done in flight.

"Run test" can.

EDIT. I mean, you can't run engine while EVA but you can make Kerbal do "run test". It's not exactly the same but sort of.

Edited August 4, 2014 by fairytalefox