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.

Just a C# IDE and a copy of KSP, possibly Unity (but not necessarily). You can use one of the free versions of Visual C# (Like Visual C# Express 2010), or SharpDevelop (that is also open source). Make sure to add the references to UnityEngine and Assembly-CSharp, both located in the KSP installation folder (KSP/KSP_Data/Managed). You can grab Unity on their site.

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...

THAT WAS IT!? THE TYPE!? :'( Thank you very much, I just found out why I wasted one night awake ^^

Hi everyone, I'm having a hard time understanding how I can load a parameter from the cfg file of a module. I mean: MODULE { name = MyModule aDouble = value } I would like to have a field called aDouble in my class and read it from the cfg file, but I can't find how to do that

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

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.

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.

<snip> AWESOME IDEA!!!

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.

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.

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)

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.

I just tested it with the gimbal lock: it works Thank you very much, now that you told me it's quite obvious actually. Many thanks.

Hello everyone, is it possible to disable / enable a part programmatically? For example, locking the gimbal of an engine, or disabling the reaction wheels of a command pod. I feel this question might have already been answered, but I couldn't bring anything up with the search :/ sorry in that case. Thanks.