Part Degradation Proposal (Please Read top before auto-lock, this is not random fail)

[Mazon Del]

Yes I have seen that the random failure item was listed as a "no-way-no-how-stop-asking". This is different. What I am proposing here is a failure system that incorporates a random element, but in a predictable manner so that players are not blindsided by ruination. IE: The failures would only happen in cases of player neglect, player accident, or during a player calculated acceptable risk. It seemed that the main argument against random failures was because they could ruin a rocket with no warning or ability for the player to work against it or correct it. My idea should fix this problem and results in a failure system similar to engine overheating, if the player is careless then they get punished.

Short Explanation:

As parts are utilized (not all parts would necessarily have this apply) a counter of sorts (similar to the fuel counter) drops at some rate. This counter is mostly green, but the last third is banded in increasingly evil colors (yellow, orange, red, black). As long as the counter is in green, then the part has NO chance of failing and will operate correctly. When it enters the first color band (yellow) there is now a 5% chance per unit of time (say 5 seconds?) of use that the part will fail in some way (see Long Explanation for more details on part failure). At the orange color, 15% chance per unit of time, Red gives 35%, and Black gives 65%. Failure severity would scale with the color. An important point is that the part degradation counter can be refilled and some failures can be repaired by having a Kerbal go on EVA to repair the component (adding some more utility to EVAs).

Long Explanation:

------------------------------------------Failure Bands------------------------------------------

Parts that have a failure band (rocket motors, SAS gear, radios, etc. Anything that feels like it would be interesting to have fail. Things like fuel tanks probably wouldn't have one, but could.) operate as normal, except that as they are utilized they use up a resource local to the part only, presented similarly to the fuel display indicators. From right to left the colors are Green, Yellow, Orange, Red, Black. As the indicator is used up the chances for failure increase, as well as the chance for severe failure (discussed in the next section). The green section takes up 2/3 of the available space, the remaining 1/3 is split evenly between the remaining colors (or in some decreasing fashion). While in the Green section no failures can occur (honestly I'd be fine with 0.5-1% here personally, but I recognize most people are not). In the yellow section, failures can occur but only disabling minor failures (the part refuses to activate), nothing severe as this area is more like a 'Check Engine' light. In the Orange section, you now introduce the possibility of a severe failure (explained below). The red section increases the possibility of a severe behavior, and the black section introduces the possibility of a catastrophic failure. You are capable of repairing parts and raising the degradation status through EVA (discussed in another section).

------------------------------------------Scaling Failures------------------------------------------

To explain how the failures scale, below is a reference chart.

Green: 0% chance of failure. 0% chance of the failure being minor. 0% chance of the failure being severe. 0% chance of the failure being catastrophic.

Yellow: 5%, 100%, 0%, 0%.

Orange: 15%, 70%, 30%, 0%.

Red: 35%, 10%, 60%, 30%.

Black: 65%, 0%, 40%, 60%.

The chance of failure determines how likely a part is to fail per given unit of time (again, I'm just throwing out the time of 5 seconds being the unit of time). Once it is determined that a failure is going to happen, it becomes a question of how bad the failure is. Initially you are only going to get minor failures, but as you allow your parts to degrade the chances of the failure becoming severe or catastrophic get worse and worse.

The following are the possible failures and what they mean.

Minor Failure: The part does not operate at full capacity, is sluggish, or overly wasteful of resources. Examples: SAS being slow, a solar panel may jam open or shot, etc. Problematic and possibly dangerous depending on your situation, but generally not ship-threatening.

Severe Failure: This sort of failure can put the craft at risk depending on the part. Examples: An engine once activated will not throttle down (cut the fuel supply or deactivate it), a gimbal may lock, a thruster may refuse to fire or continuously fire, SAS may work or not work or work in reverse, etc. These are problems that CAN put your ship at risk in most situations they would occur in, however they are still repairable.

Catastrophic Failure: This failure will likely permanently reduce the capabilities of your craft and could lead to its destruction. Examples: The part in question simply explodes (like an overheating engine, but maybe it is just 'broken' like a solar panel), the engine once activated cannot be deactivated (though you can still cut the fuel), SAS may try to roll the ship continuously as hard as it can in one direction, parachutes fail to deploy etc. These failures are generally NOT going to be repairable, if you choose to run the risk of a catastrophic failure then you accept this.

I would encourage Squad and others to be imaginative in how these failures could happen. My favorite example of this sort of thing was Roller Coaster Tycoon. You could have all kinds of failures, most were just inconvenient (roller coaster stuck in position) and sometimes hilarious (such as when the Merry Go-Round lost its speed control and went to plaid with the music matching the new tempo), and sometimes were horrifying (station breaks failure...nothing more need be said).

------------------------------------------Degradation/Failure Repair------------------------------------------

Main Method: At any time a Kerbal on EVA can approach a part, select it, and choose to perform maintenance/repairs on it. This corrects the failure (if possible) and resets the degradation counter to full. All features of the part in question would be restored.

Tweak 1: One of the technologies in the tech tree would be "Repair Robots" that would allow you to place a part on your ship that allows you to repair without going on an EVA. Perhaps a second technology would be "Autonomous Repair Robots" which automatically fix any item that reaches the yellow bar or has a repairable failure. Of course, the robot bay part can suffer failures as well!

Tweak 2: A ship part that exists carries stored amounts of spare parts (again, implemented like fuel), and when repairs are made some of these parts are used, limiting how many times this may be done in a variable method (resupply exists).

Tweak 3: (This is compatible with Tweak 2 if desired) A part only has so many maintenance cycles/repairs it can undergo. This can be implemented in many ways. One example is that each part only has 3-5 maintenance cycles that can be applied. Another example, each maintenance cycle 10% of the bar is removed (the first time, you can bring it up to 90% effectiveness, then 80, etc), or every time a failure happens you reduce the max that the bar may reach.

Tweak 4: All parts have a veeerrry slow passive degradation rate. Space is quite a dangerous place after all. As you advance your tech tree, maybe you have a "Materials Science" track that allows your parts to degrade slower. This is useful to provide a reason for why a single use parachute may fail after a long journey from Kerbin to Duna or something. If you wanted, you could even tie this degradation rate into the altitude of planets with atmospheres. In low Earth Orbit where parts are exposed to small bits of our atmosphere, they rapidly degrade, so you could simulate this fairly simply in this manner. When weather is implemented on various planets, it could also have an input on the degradation rate.

Tweak 5: Impacts and G loads can harm parts through the degradation system. When you land hard then parts can become degraded, not necessarily damaged. Already we have parts falling off from exceeding their impact tolerance, but this system would allow for consequences to hard landings (or fast accelerations) that still succeeded. Additionally, if you have some part that is deemed fragile (let’s say a radio dish) and you subject it to 10Gs if the part has a 6G rating then it should start degrading on the system, this somewhat forces you to design your probes/ships to not be too crazy on the acceleration (admittedly a rare happenstance for me).

------------------------------------------------------------------------------------

Final Summary:

I feel that this system solves the gameplay related issues that exist from just having randomly induced failures. For most of a parts life it won’t have any problems, only after heavy use and strain will a part begin to break down, but it does not take that much effort to go out and fix it, so really any failures you encounter are at their root, your fault. And I feel it adds to the gameplay by both adding further purpose to EVAs and in how probes work. Probes would now suffer from age related failures instead of only "woops" and "WTF?!" related failures.

What do you think? Would you play with this? What would you change?

Thanks for reading.

[Dunbaratu]

This is still a random fail of the sort that they don't want in the game. The fact that the random factor is predictable within a narrow window does not change the primary fact that the devs want all behavior to be deterministic. What they're trying to avoid is scenarios where exactly the same identical starting situation, performing exactly the same identical operations, could yield different results on one run than it does on another run. Any suggestion that would make that impossible is automatically rejected.

It would be different if you had described a *deterministic* degradation of things, like a set of hit points each part has, that get worn down by specific actions, or by hard-coded time functions. Its when you start throwing around words like "chance of" that it is verbotten.

[Captain Sierra]

This is still a random fail of the sort that they don't want in the game. The fact that the random factor is predictable within a narrow window does not change the primary fact that the devs want all behavior to be deterministic. What they're trying to avoid is scenarios where exactly the same identical starting situation, performing exactly the same identical operations, could yield different results on one run than it does on another run. Any suggestion that would make that impossible is automatically rejected.

It would be different if you had described a *deterministic* degradation of things, like a set of hit points each part has, that get worn down by specific actions, or by hard-coded time functions. Its when you start throwing around words like "chance of" that it is verbotten.

I disagree. There is indeed a random element here but hey, such is rocket science.

I do think one tweak would be when parts in question are repaired, they do not repair to full, making routine maintenance less effective than replacement. Also, given this is set up to have a fairly high predictability, and easy methods to avert, I'll +1 this, especially on how well thought out this idea is. My biggest pet peev is welll thought out ideas like this closed down. These are good suggestions that try to bridge the gap between community desires and developer decisions. IF this gets shut down, then SQUAD is being deprived of a good idea to make everyone happy and it might be time to mention the concept of overmoderation to the dev team.

[Mazon Del]

Thank you both for the quick replies.

Steven Mading:

I see where you are coming from with that, and if that is SQUAD's decision then so be it, but I think that on some level a little randomness can help a video game. There is such a thing as being overly predictable and real rocket science is not filled with certainties. And even if the random chance thing were the true sticking point, then most of my idea is still applicable to how parts work, just with ever degrading performance until eventual total failure, but I think of this as much less interesting.

Captain Sierra:

Thank you for your +1. I had intended for your idea to be part of the Tweak 3 proposal, but I see that I apparently left out the words to describe "repairing" instead of just maintenance.

I welcome further discussions and suggestions!

[UbioZur]

This is still a random fail of the sort that they don't want in the game. The fact that the random factor is predictable within a narrow window does not change the primary fact that the devs want all behavior to be deterministic. What they're trying to avoid is scenarios where exactly the same identical starting situation, performing exactly the same identical operations, could yield different results on one run than it does on another run. Any suggestion that would make that impossible is automatically rejected.

Agree with the fact that SQUAD does not want to have random failure that would lead two similar launch to two different outcome.

However, on his suggestion, it is easy (if there is a GUI to display it of course) to know when a failure could happen (and one will happen), Just the failure itself is random, not so much the when.

My biggest pet peev is welll thought out ideas like this closed down. These are good suggestions that try to bridge the gap between community desires and developer decisions. IF this gets shut down, then SQUAD is being deprived of a good idea to make everyone happy and it might be time to mention the concept of overmoderation to the dev team.

Locking a thread is far from deleting it, it just allow actual new idea to be visible, and when the dev need, they can research the forum for all the ideas about a topic, research failure, and you will get all the suggestion that have been posted about failure in KSP, locked or not.

Now to the OP, It does sadly still enter the category of random failure (I have discussed it with other mods),And even so this is a good idea and well explained (to my opinion), we have to lock the thread.

I do strongly suggest you to suggest that idea to the modders, and I hope for one day to see a mod doing it.