[WIP] [Dev thread] Dang it! A random failures mod

[Fraz86]

I really like where this is going. In particular, I'm a big fan of the following:

• lack of catastrophic (i.e., immediately mission-ending) failures
  
• all failures are repairable via EVA (which has the added benefit of creating greater purpose for manned missions and EVAs)
  
• customizability via ModuleManager
  
• straitforward but realistic failure model in which there is some chance of failure at any time, and this chance increases with use
  

[8749236]

I prefer the failure are interconnected..

So we can have fun with trying to figure out which one is the route cause of all of this...

Such as electric surge will blow up all of your lightbulbs, kills (some, if not all) instruments, engine and RCS controls are freaking out (which can torn ship apart), fuel tanks go boom and so on...

The only reason why all of these is happening was because one of your battery cooled and fried xD

Well, I exaggerated it a little, but you know what I mean....

I have an abstract idea of how it can be achieved:

- Have a tree of parts where some nodes and below are specific categories... where you have some parts that is in two or more categories aboves those nodes...

- Then stick an id onto each part that you want them to fail...

- Roll for doom!..

- If failure will happen

- Fail the current part

- Search for all other parts that are under the same category.

- Raise failure rate of the parts found.

- Doom it again!..

Perhaps you can done this recursively...

function fail_parts(some parameters..)
    ... fail parts ...
    if(part_fails)
        ... find another part in same category ...
        fail_parts(related_part)
    else
        ... do nothing ...

Note: In the pseudo code above I wrote "part" not "parts".. it is because if one fail triggers potential failure on all other parts in category, it may cascade too much so that it can even fail the computer!.. I mean the player's computer!!..

Eventually, the random chance will stop the recursion... Deeper recursion often implies bigger problems (and yeah, more laggy)... if you do not want the recursion going too deep, perhaps you can insert a variable that prevents further parts failing after certain depth (amount of failures) has achieved... (I believe this is necessary, especially when ships has high count of parts that can fail)

Furthermore, failure rate should be reduced (slightly) on parts that had already failed... so you can actually have double or triple failure to one part in the same incidence, while reducing the possibility of intensive lag, too.

Edited May 12, 2014 by 8749236

[theSpeare]

...

Sounds good! :S I was just sharing some input, I wasn't going to use it now anyway in its current state. Balancing for a lot of mods has been so much in the "workarounds" region. Once budgets and contracts come out I am very confident this mod will skyrocket.

[Ippo]

I prefer the failure are interconnected..

So we can have fun with trying to figure out which one is the route cause of all of this...

Such as electric surge will blow up all of your lightbulbs, kills (some, if not all) instruments, engine and RCS controls are freaking out (which can torn ship apart), fuel tanks go boom and so on...

The only reason why all of these is happening was because one of your battery cooled and fried xD

The problem is that this way it wouldn'be fun: as others have already pointed out, it would only be annoying if all of a sudden the game decided that your ship has to explode and you can't do anything about it. Even just spinning out of control means that, in space, there's no way to stabilize it and repair it, so it's basically lost with all the crew with it.

The vessel in KSP is already a tree structure: the real problem is that the interconnections in the vessel tree are absolutely not related to how real systems are interconnected. For example, if you had a short in a battery near the engines it should disable all the electrical parts of the ship, not only those that are connected to its node in the tree: so recursion wouldn't be my first choice, in this case.

And then, engineering considerations: cascading failures in aircrafts (and therefore, I assume spacecrafts also) are extremely rare because their design is reduntant especially to eliminate the possibility of cascading failures. When they happen, they are often very severe and involve multiple systems in unpredictable ways, and they aren't always recoverable. With this in mind, I am not planning for cascade failures, not even in the future: sure, this mod aims to add a little more realism to this game, but KSP remains a game at its core (that's why you don't have life support or re-entry heat in the stock game), so I think that realism mods should still remain somewhat limited to be accessible to most people.

tl;dr: a vessel-wide systemic failure wouldn't be fun, nor easily repairable by the crew in flight, so I don't like it

Note: In the pseudo code above I wrote "part" not "parts".. it is because if one fail triggers potential failure on all other parts in category, it may cascade too much so that it can even fail the computer!.. I mean the player's computer!!..

About this, I wouldn't worry too much: a typical vessel is under 200 parts, and I think that not even danny exceeds 500 when he goes nuts: recursing in a tree of this size is really not an issue.

So all in all, I am sorry to say that my mod, as currently envisioned, won't probably suit your taste

[Ippo]

Sounds good! :S I was just sharing some input, I wasn't going to use it now anyway in its current state.

And it was most appreciated

Balancing for a lot of mods has been so much in the "workarounds" region. Once budgets and contracts come out I am very confident this mod will skyrocket.

I am looking forward to that too, as a player I mean. If working on modules keeps going at this pace (seriously: I *hate* PartModules now) they will be both long-implemented and tested ^^

[Ippo]

"Daily" update (that pesky real life got in the way again).

So, basically the most of the infrastructure is definitely laid out, and I am working on implementing some more modules to see what I can and can't do.

2 days have been wasted on trying to have the ModuleCommand fail... and when I had almost finished, I realized that in many cases that would have been a non-recoverable failure, so it's now on hold.

About that, what do you think? I think that if the commands became frozen when an engine is running or the ship is rotating fast, there would be no way (in space) to get out and repair it. I can actually think of more scenarios where it would mean certain death than not, so I decided to scrap it. The code is still there (even though it requires just a minor finishing). Just asking for thoughts.

Talking about code, I finally have my very own Git repo! Grab a copy of the code here: https://github.com/Ippo343/DIRandomFailures (no, don't do that actually: it's still very unfinished and very untested, I don't want to hear that I jeb'd up your saves).

I have a kind of urgent project to work on, so the next week will be slow.

[The Yellow Dart]

Hello, so I posted about a part failure idea in the Addon requests forum and someone suggested I share it here because it had some different ideas. This is just copy and pasted, I have only skimmed your post and am not trying to suggest you start over or anything, just sharing ideas if you want them or ignore if not :

"Apollo 13-izer"

It would be random, tuned so that, say every 15 to 20 missions or ships built, a part picked at random malfunctions, with different malfunctions depending on the part.

Some malfunction examples:

• One landing leg gets stuck
  
• A solar panel shorts out
  
• A control surface stops functioning
  
• A fuel line's valve gets stuck in the open or closed position
  
• A flawed rocket motor has a lower ISP than normal or-
  
• Burns through oxidizer faster than fuel or visa versa
  
• Reaction wheels failing (kepler?)
  
• A decoupler fails to blow or-
  
• A separator blows one side only
  

The malfunctioning part, if any, would be determined, unbeknownst to the player, at the time the ship is "built" and put on the pad, so that it isn't a matter of ships absolutely malfunctioning if they are out there in space long enough. If a part goes bad, it was destined to go bad due to some undetected imperfection. What ever part is selected to malfunction would have a randomly set timer, or maybe a use counter (i.e. open & close your landing legs 3 times all is fine, mission success, but the 4th time a leg gets stuck closed) that would set it off at sometime in the mission. The player would be alerted at the time of the malfunction by a text message on screen like the master warning light, saying what happened. On a manned mission you might be able to fix some malfunctions by EVA given time and an appropriate situation (if your parachute fails on reentry good luck fixing it on EVA at 10,000m over Kerbin), but a kerbonaut on EVA can only do so much. A shorted solar panel, sure, we can rewire that, but a bad rocket motor is probably beyond fixing. On unmanned probes, there isn't much you can do but try to compensate for what ever went wrong. I feel like this would be an awesome addition to KSP and could add some real nailbiters as well. Sometime it won't make too much difference, like a solar panel. But if a radially mounted engine burns fuel faster than it's opposite counter part and unbalances your lander, and you don't find out about it until you are committed to a landing, you've got a heck of a landing ahead of you!

[Fraz86]

About that, what do you think? I think that if the commands became frozen when an engine is running or the ship is rotating fast, there would be no way (in space) to get out and repair it. I can actually think of more scenarios where it would mean certain death than not, so I decided to scrap it. The code is still there (even though it requires just a minor finishing). Just asking for thoughts.

Outright disabling the command pod does seem like too catastrophic (and potentially irrecoverable) of a failure. Perhaps if just the SAS functionality could be disabled, that would be more reasonable.

[Ippo]

...

Well, I have to say that I like your idea Only, it doesn't fit my view on the subject very well because it still implies that all the other components are invulnerable: if only one part can fail, then all the others will still work like a charm even after a 20 year mission, which doesn't really look right to me

But if I ever get around to actually make something of this mod, then I'll see if I can implement something like that: for example, a single random part might get its MTBF severely cut, giving a mix of both ideas.

Also, about this: I'm sorry for everyone interested, but RL is having me run around like crazy in these days (they gave me yesterday the components that I need for a project that is due FRIDAY MORNING). I will try to move things as fast as I can, but I can't make any promises. Also, disabling the modules is getting more and more ******ed: it's very easy to "burn" a lightbulb... but it will still respond to the master light switch at the top of the screen -.-

[Ippo]

Outright disabling the command pod does seem like too catastrophic (and potentially irrecoverable) of a failure. Perhaps if just the SAS functionality could be disabled, that would be more reasonable.

Yes, that's what I was thinking. Actually, I had already in place a way to mitigate it (no failures if there is any engine running) but it still leaves too many problems that can't be solved, so no.

[icemonkey]

And then, engineering considerations: cascading failures in aircrafts (and therefore, I assume spacecrafts also) are extremely rare because their design is redundant especially to eliminate the possibility of cascading failures. When they happen, they are often very severe and involve multiple systems in unpredictable ways, and they aren't always recoverable. With this in mind, I am not planning for cascade failures, not even in the future: sure, this mod aims to add a little more realism to this game, but KSP remains a game at its core (that's why you don't have life support or re-entry heat in the stock game), so I think that realism mods should still remain somewhat limited to be accessible to most people.

That said, what about Apollo 13? I know it was a rare case, but one small thing caused a load of other problems. http://www.space.com/8193-caused-apollo-13-accident.html The actual list of minute things that caused the main problem is actually kinda interesting, but I'm getting side tracked. What I think would be cool to happen is very rarely something of Apollo 13 style proportions would happen, and you have to be very Gene Kranz about the situation and try to jerry-rig your way back home. But that's just a thought, and if some people find this too extreme, maybe some sort of difficulty scaler could be included? Like higher difficulty makes random failures more common, and more extreme?

[Ippo]

Maybe some sort of difficulty scaler could be included? Like higher difficulty makes random failures more common, and more extreme?

ATM, all the configuration is done through the values in the cfg file, and I will keep it like this as much as I can, so each can have it their own way.

Thanks for the Apollo 13 article, I'll read it asap but the kind of problems they have is difficult to replicate in ksp. Even using TAC-LS and Deadly Re-entry won't make you have to fit square filters in circular holes

[Ippo]

Hello again everyone, I'm here to ask for feedback and input once more. But first, good news: I'm very close to a functional, testable version.

I only have a bad bug in the tank module and the batteries module to take care of, and then it will be usable (although still lacking).

Now I need some feedback regarding resources, since obviously as soon as I figure out how to do it repairing stuff will cost.

Here's the thing: what resources? A realistic approach is of course unfeasible, or you would need to have tens of different resource types, which is terrible.

On the other hand, the simple, straightforward approach of one resource is terrible.

As of now I was thinking about a very light and simple solution: electrical spares and mechanical spares, and that's it. Mechanical spares would be needed to fix stuff like engines, tanks, control surfaces, while electrical spares would be needed for batteries, antennas, and such. Of course, some things might mix them: a reaction wheel for example might require both.

How do you feel about resources?

Failures "working correctly" as of now:

- alternators

- control surfaces

- engines

- gimbals

- lights

- reaction wheels

Plus tanks and antennas still not working as intended.

Also, I'm still trying to figure out how to model failures in "discrete-use" stuff, like decouplers, antennas and docking nodes.

[Fraz86]

I actually lean toward a single generic "Spare parts" resource. I think it's reasonable to assume that Kerbal engineers would fill the available storage space with an appropriate array of spare parts corresponding to the modules present on the craft. I'm not sure that making the player determine the ideal mixture of spare part sub-types really adds anything to gameplay. I also worry that having multiple spare part sub-types is ultimately just asking the player to slap on additional storage modules, leading to needless extra parts.

[Ippo]

And finally, after fixing that awful bug with the tanks (seriously: I froze WINDOWS somehow), we have a first working-ish release

It is far from complete: lots of parts are stil untouched, there is no resource system, no anything besides some parts that can fail and be repaired.

If you want to give it a try, just grab a copy from the git repo: https://github.com/Ippo343/DIRandomFailures

The GameData zip archive should give you anything you need, but there is also the source code just in case

[Great General Kaboomsky]

Thank you so very much for working on this!

Despite the "controversy" I have felt like random failures are a badly needed par of my game, and I really like the model you are playing with here.

(Also, it might finally give me a reason other than my own stupidity to include my spare part kits via KAS on my manned missions.)

I have no idea how hard it would be to implement (I can barely muck around in a config file, much less actually mod) but have you thought about adding continuous degradation into your mod (for applicable parts obviously)? I have always wanted RTGs which actually ran low on power generation over time or solar panels that were degraded through micro-meteor strikes and needed to be replaced now and then.

Anyway, with that unsolicited request, I’m going to gleefully run off and play with what you have finished so far!

Thanks!

-Kaboomsky

[pxi]

Thanks for the Apollo 13 article, I'll read it asap but the kind of problems they have is difficult to replicate in ksp.

One thing that I might suggest is to look at whether there is comms available between the ailing craft and mission control. The ability of the guys back home to come up with the solution which is then relayed to the astronauts would probably have a large influence in the success of any repair. Beyond that, when there's no comms available, a smart kerbal probably can fix it, wheras a badass presumably hits it with a hammer till it works.

Good luck anyway!

[Ippo]

One thing that I might suggest is to look at whether there is comms available between the ailing craft and mission control. The ability of the guys back home to come up with the solution which is then relayed to the astronauts would probably have a large influence in the success of any repair. Beyond that, when there's no comms available, a smart kerbal probably can fix it, wheras a badass presumably hits it with a hammer till it works.

Good luck anyway!

Now THIS is an awesome suggestion I hadn't thought of. This is going straight to the future features list. I won't make any sort of promise regarding what I will or will not do, but seriously... love this

[Ippo]

Thank you so very much for working on this!

Despite the "controversy" I have felt like random failures are a badly needed par of my game, and I really like the model you are playing with here.

(Also, it might finally give me a reason other than my own stupidity to include my spare part kits via KAS on my manned missions.)

I have no idea how hard it would be to implement (I can barely muck around in a config file, much less actually mod) but have you thought about adding continuous degradation into your mod (for applicable parts obviously)? I have always wanted RTGs which actually ran low on power generation over time or solar panels that were degraded through micro-meteor strikes and needed to be replaced now and then.

Anyway, with that unsolicited request, I’m going to gleefully run off and play with what you have finished so far!

Thanks!

-Kaboomsky

TEACH THE CONTROVERSY.

Ok sorry, I had to make that joke.

Continuous degradation can be added with almost no effort in the structure I got in place: this gets on the future features list too

Also, just a small warning: there might be (no, there *are*) some bugs I didn't catch / solve yet. Be very careful with it and backup everything.

I think I did disable almost all the major debug features when uploading that build: if you see something that shouldn't be there (like buttons that trigger failures, or insane repair distances) it's just a slip-up of a debug control.

[Ippo]

Just a quick update for the interested... once again, please tell me if the mods think I'm bumping and bothering people.

In these screenshot you can see Bill having troubles with the engine on the launchpad. Really wanting to go to space today, he gets out of the pod to grab some spare parts, and head for the engine... and promptly discovers, he didn't bring enough! But after a short gravity hack to the command pod, he is able to grab the remaining spare parts and bring the engine to life again

Javascript is disabled. View full album

On a more serious and informative note, the core things seem to be all in place now: things can fail and can be repaired using a resource called Spare Parts (I settled on a single resource in the end: might change... but unlikely). This resource can only be moved around by kerbals (no flow) and is very heavy: a kerbal fully loaded with this will have trouble moving around.

Now I have some bugs to iron out, but basically, we are close

Edited June 1, 2014 by Ippo
typo

[Mecripp]

So if we have a space station how can we send parts or transfer parts to the station train of kerbals ?

[Ippo]

So if we have a space station how can we send parts or transfer parts to the station train of kerbals ?

Basically, it's like solid fuel: you cannot pump a solid between parts, so you can't pump spare parts. They will have to be manually transfered between the resupply vehicle and the station.

Eventually, when I get around to make some models, you will also have containers: just dock one to the station and you are good

[Mecripp]

Basically, it's like solid fuel: you cannot pump a solid between parts, so you can't pump spare parts. They will have to be manually transfered between the resupply vehicle and the station.

Eventually, when I get around to make some models, you will also have containers: just dock one to the station and you are good

O ok so we can still use like Cargo bags mod or KAS boxes.

[Ippo]

O ok so we can still use like Cargo bags mod or KAS boxes.

Yes, they are just a normal resource like any other, except that it cannot flow.

As such, it can be config'd into any part you like: I still didn't think about how, just that one day there will be containers.

Just a little ago I saw this, tell me it isn't the perfect container

[NathanKell]

Why on earth would posting a progress update be bothering people?

And that progress is looking great!