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

[Ippo]

Release thread

Hello everyone!

I am starting to work on a plugin that will add random failures to the game.

Please note that I know already that it is a very heated debate: however, I'm not here to ask whether you want it or not, I only want to ask for feedback on the model I'm thinking to implement. I'm going to make it anyway, whether people like it or not, because I do want it, so...

So, basically I'm thinking to model it like this:

- every single part of the ship is completely independent of the others, failure-wise (at least, at first);

- the failure rate will be nearly constant for a good part of the part's expected life, and then increasing linearly to 1, to simulate aging;

- all failures will be repairable with an EVA operation: as of now, I'm not big on including unrecoverable failures like something exploding randomly;

About the coding itself, I would like some advice from someone with mod experience: what's better, to develop different modules for each part type (one for engines, one for tanks, one for command pods, etc) or to try to develop a single module to handle the failure of whatever component it is attached to?

As of now, I'm more geared towards the first one because it would allow to have engines age only when they are in use, in contrast with everything else that is essentially always in use (tanks, for examples).

So yeah, that's it... thoughts? About this design, I mean.

Edited October 20, 2014 by Ippo
Alpha 3.3

[Ippo]

Also, forgot to add:

- some failures shouldn't be completely recoverable: for examples, after being repaired the failure rate might be upped a little, and also the part's functionality might be a little limited (e.g., limiting the maximum thrust of an engine)

[Mecripp]

Maybe how smart the kerbal is on how good the repair and is this going to be more mod friendly then http://forum.kerbalspaceprogram.com/threads/75734-WIP-023-%28ARM-Compatible%29-Kerbal-Mechanics-Parts-can-now-fail%21/page4

[spudcosmic]

How about parts have a failure chance when they are used or while being used, and some parts would have a significant failure chance and some parts have practically zero. So technically it is possible to design a craft with close to zero failure chance, but with limitations. Generally main lifting engines would have a high failure chance because of how complex they are, and orbital engines would have close to zero.

I have been thinking about a system like this for a while so I have a lot more ideas, but I really have to go to sleep now, so maybe I'll post some more tomorrow.

[Ippo]

Yes, actually I was thinking about something similar.

Basically the failure rate will be proportional not to the absolute age, but to how much the object has been used. This means that for engines wear out as they are used, while tanks and command pods age with time (since in a sense, a tank is always in use when it's not empty). Science experiments and antennas however have such a small use time that I guess I will simply lock it randomly when it is used (if you think about it, you probably use your antennas for less than 5 minutes during years-long missions).

Alternatively, we could consider the antennas as always-on too, since they need to provide a com link with the KSC.

[Ippo]

MeCripp: yes, I thought about it, but I'm not really sure... Kerbals have 2 stats, courage and stupidity: making the repair ability depending on stupidity means that:

- for medium / long missions you would always pick the same crew of supersmart kerbals, while the others would become relatively useless;

- how about courage, and badS?

All in all, I think we should postpone this until much later, so that we have the time to figure out a way to balance it.

[ahappydude]

You should work together with the man/women who made the mechanics mod

http://forum.kerbalspaceprogram.com/threads/75734-WIP-023-%28ARM-Compatible%29-Kerbal-Mechanics-Parts-can-now-fail!

[Ippo]

Indeed, I didn't know there was another one in development... Oh well, now that I've started I might as well go on, if anything I will learn something new, plus I'm thinking about writing down a short tutorial about it, so.

[Mecripp]

Bad thing about Kerbal Mechanics: Parts can now fail! mod isn't mod friendly as it replacing modules and that was bad and for that his mod is looking like it's dead now.

[regex]

About the coding itself, I would like some advice from someone with mod experience: what's better, to develop different modules for each part type (one for engines, one for tanks, one for command pods, etc) or to try to develop a single module to handle the failure of whatever component it is attached to?

You're the guy who PM'd me about my code, yes? I'd have to look at the code again but I think I was going to have a PartModule for each type of failure and then have ModuleManager do the heavy lifting of adding those PartModules where appropriate (since it can determine if a part has Resources or a ModuleEngineFX, for instance). I feel like it's an easy approach to the issue that doesn't clash with other mods and takes some burden off of the PartModule coder (seriously, why duplicate ModuleManager's job?)

[ahappydude]

Bad thing about Kerbal Mechanics: Parts can now fail! mod isn't mod friendly as it replacing modules and that was bad and for that his mod is looking like it's dead now.

I wouldnt call it dead yet, wasnt that long ago he posted there =) Also someone made a good mm example so you can use it^^

I didnt mean you would stop yours op, its always nice with variety!

[Mecripp]

I wouldnt call it dead yet, wasnt that long ago he posted there =) Also someone made a good mm example so you can use it^^

I didnt mean you would stop yours op, its always nice with variety!

The MM just made it so you didn't have to copy over all the stock parts but it still replaces the Module name that alot of mod's tie in to.

EDIT -- Don't get me wrong there both great idea's and would love to see them in game.

Edited May 9, 2014 by Mecripp2

[Ippo]

You're the guy who PM'd me about my code, yes? I'd have to look at the code again but I think I was going to have a PartModule for each type of failure and then have ModuleManager do the heavy lifting of adding those PartModules where appropriate (since it can determine if a part has Resources or a ModuleEngineFX, for instance). I feel like it's an easy approach to the issue that doesn't clash with other mods and takes some burden off of the PartModule coder (seriously, why duplicate ModuleManager's job?)

Yes, that was me. Thank you again, btw, it's being very useful.

As of now I am following your approach, because after tinkering for a while I agree that it's probably the easiest and most effective solution (and also very elegant, thanks to the Module Manager).

Right now I'm only working on a gimbal module because it's very easy to test. After I'll have solved my issues with the lifecycle of the PartModule, if everything works it should be trivial to extend it to other types of failures.

[Ippo]

I didnt mean you would stop yours op, its always nice with variety!

LOL no problem, it's just that we can basically assume that they are doing a better job than I am, I think

[ahappydude]

LOL no problem, it's just that we can basically assume that they are doing a better job than I am, I think

Dont be hard on yourself Im looking forward to seeing what you comeup with! Im trying to make like a fake fire starting in iva but it dont play out like i want it

[regex]

Right now I'm only working on a gimbal module because it's very easy to test. After I'll have solved my issues with the lifecycle of the PartModule, if everything works it should be trivial to extend it to other types of failures.

That's a good plan, start small.

[Paul Kingtiger]

I talked about this sort of thing with Daishi. We came up with the idea of a settable fail rate, which would come into effect the first time a part was 'used' so the engine was activated, the tank provided fuel and so on. We were working on the idea that you don't know something is going to work until you use it and once it's worked once it'll probably go on working.

I like the concept of fixing things on EVA, it give more stuff to do on EVA (badly needed in this game) and makes sure that everything can be fixed.

Looking forward to seeing how this develops.

[Ippo]

Can you please help me with a small doubt I have?

So, I can now specify the Mean Time Between Failures for the module, in hours, but how can I convert it to the chance that the module will fail at that particular update?

Right now I'm doing:

chance = (1 / MTBF) / 3600 * updateInterval;

Where MTBF is in hours and updateInterval in seconds. Does this look right to you? Because in my tests it seems to fail much more often than it should given a small MTBF...

[Ippo]

Looking good so far

Tomorrow I will run more tests to check that the parts age correctly (only when they are active), also will implement the decay of reliability.

Still not sure how to take timewarp into account though. I *think* that I don't need to change anything... I think.

[Ippo]

Daily update (please tell me if I'm just bumping and should stop): the tests on the aging seemed to work fine. Two new modules (alternator and engine) have joined the mod.

Before moving on with the rest of the modules, I'm going to test how it's going to work with the persistance file etc. I hope that saving doesn't break anything

[theSpeare]

Random failures won't really work without something to maintain or ensure a low probability of occurrence. Failures by random chance (RNG) will always eventually irritate the player, as it is punishment without reason. Perhaps imagine a game like DayZ, where there was a probability that you would simply be "shot" by some "random AI sniper"; failures should occur due to player's decisions.

Science upgrades can probably handle this but I've always thought a lot of what mod balancing is missing is a KSP budget. Probability of random failures would increase if you spent less money on maintenance, or quality assurance. The more money you spend on it, the less chance of failure. Furthermore, science can be invested to work together with this idea.

Think Engine Ignitor - it already has a failure of sorts. The engine can fail to ignite - but if it failed it's because you probably ran out of ignitions, brought the wrong engine type, or forgot to ullage.

[Ippo]

...

Don't use it, then

Anyway, as I said all the failures will be repairable. I'm not planning to implement any catastrophic failure (like parts exploding) in any near future, and with the architecture I am using atm, even if I did removing them would be only a matter of deleting a cfg file.

Also, I think I have a neat little thing to factor the player decisions in, at least to a small degree. Here is the model as of now: the part has an initial MTBF and an expected LifeTime, set in the cfg. The MTBF gives the chance of a failure occurring at a specific moment. Over time, the part will age: either continously (like a tank, that gets old with time) or with use (like an engine, that ages essentially only when it is being used). The MTBF then decays exponentially as:

MTBF = InitialMTBF * exp( - age / lifetime )

This way, the more you use an engine (or parts that age like an engine), the more it becomes prone to failure.

Also, each module can define a "Lambda Multiplier": this value is computed at each fixed update and is multiplied by the instantaneous chance of failure. A use case for this would be increasing the failure rate of an engine as the throttle goes up.

Science upgrade will definitely happen to increase the reliability, but first, let's get this to work

Eventually I hope to factor the budget in, when 0.24 will be out.

Also, daily update: the persistence appears to be fixed now. I have 3 modules working atm (engine, gimbal, alternator): developing more modules is turning out strangely difficult because there is no unified method to disable a module... or I didn't find it (no, module.enable = false doesn't cut it)

P.S: think of it as an AI sniper shooting you at random... but only in the foot, and never shooting you again until you recover.

[nothke]

Another failures mod? Oh cool!

I will copy my post from the other failures mod page

a few modders are also working on random failures mods:

• https://github.com/jbengtson/ksp-partfailure
  
• and HoneyFox (http://forum.kerbalspaceprogram.com/threads/71866-WIP-Random-Failures-%28for-your-masochism-needs-XD%29)
  

Also I was trying to help HoneyFox by assembling a list of whatever came to my mind:

It could help you too (added a few more things today):

https://docs.google.com/spreadsheets/d/1-8iIiyy6Qnurrg2TEO_gfK-IWWjUaCO9U0hyjoFj40U/edit?usp=sharing

also, you can add new things or correct me by commenting on cells =) I will then add it to the sheet

Edited May 12, 2014 by nothke

[regex]

a few modders are also working on random failures mods:

• https://github.com/jbengtson/ksp-partfailure

I have repeatedly said that I am not working on that code at all (if I had been, it'd be done by now). I put it up there for a reference if someone wanted a place to start and because I thought it was a cool approach to the issue.

[Ippo]

... a reference if someone wanted a place to start ...

Hi

Thanks for the pointers nothke: however, I have to say I had already seen it all, including your spreadsheet. I bet it will come in handy when I will need to implement more failure types.

Regarding the other mods... well... I'm kinda of a noob at modding, at a total noob in the forum, so I wouldn't want to sound too smug, but still... Looking at their source code I don't think they are doing it right. For themselves I mean: I can totally see those mods becoming a huge cluster of spaghetti as soon as they get expanded a little, basically because they are hard-coding a lot of behaviour. The failure model is not very realistic, too (well, not that mine is perfect, actually, but I tried to keep it rooted in the course I took about reliability. I'm an engineer IRL).

And finally, I see that both mods haven't been updated in the last month, so I have a bad feeling about their development status.

With that in mind, there is still a good chance that I will just get mad at the lack of documentation and throw all the code out of a window, so yeah, I can understand if they really have abandoned the project. If they didn't, all the better for me: I can peek in their code when I can't figure out something on my own (yeah, I should totally make a github account too)

EDIT: reading my post again, I realized that it did sound much more smug than I intended. What I really mean is that I don't like how they are approaching their mod, especially honeyfox: I don't dig the architecture they are using and I think I found a more scalable approach... that also has the big blind spot of not including decouplers at all atm.

Edited May 12, 2014 by Ippo
smug-ness overflow