severedsolo

[1.7.x] Oh Scrap!- A ScrapYard based Part Failure and Reliability Mod 1.7.1 (25/09/2019)

Recommended Posts

3 minutes ago, eightiesboi said:

I *did* say my stats was rusty... lol

But I do think that an 18% chance of failure on launch with four SRBs is a little high... And, if I understand your intended modeling, I don't think that's right. Shouldn't the probability of failure be impacted by the overall failure of the vessel? For parts other than SRBs (as I understand it), there are two checks rolled: vessel failure, and then part failure. If the vessel passes, no part rolls. If the vessel fails, all the parts roll until either one fails or they all succeed. If the SRBs are rolling independently--without the vessel failure roll--then the probability that one of them will fail is both independent of the overall vessel AND is greater the number of SRBs on the vessel. With all of the other parts (again, based on my admittedly feeble understanding), the probability that one of them will fail is conditioned on the probability of failure for the overall vessel (i.e., the chance that a part will fail is irrelevant if the vessel passes its failure roll). If the overall chance that a vessel will experience a failure is 5%, and each part has an independent 5% chance of failure, and there are four parts that could fail, isn't the chance that a failure will occur closer to 1%?

Again, I haven't done statistics in over a decade, and my memories of HLM and MLM have long faded, so forgive me if I am totally wrong. :)

Nah, you're right. SRBs are the one part that still use the old model of rolling individually (and this demonstrates precisely why I went away from that model, despite complaints from some users). I 100% agree with you, 18% is way too high, it's just this is the first time I've actually sat down and done the maths on it. When I got the answer (and double checked my work) I was, surprised.

SRBs don't use that model because the chance of a failure becomes vanishingly small, but I didn't take into account multiple SRBs.

So assuming I changed it to work exactly the same way that other parts work (calculations in the spoiler)
 

Spoiler

Chance of Event A (Overall vessel failure roll) = 0.01

Change of Event B (individual part failure) = 0.05

Chance of both events occuring: A*B = 0.01*0.05=0.0005

Chance of no event occuring: 0.9995

Assume 4 potential failure points (4 SRBs): 0.9995^4 = 0.998(rounded)

 

Chance of failure: 0.002%.

That's.... unacceptably low tbh. It works for other parts because they have multiple failure points (get rolled often) - but for SRBs I need to do something different.

What that's going to be I don't know yet :P but you are right that the current model is just as bad but the other way.

Share this post


Link to post
Share on other sites
17 minutes ago, severedsolo said:

Nah, you're right. SRBs are the one part that still use the old model of rolling individually (and this demonstrates precisely why I went away from that model, despite complaints from some users). I 100% agree with you, 18% is way too high, it's just this is the first time I've actually sat down and done the maths on it. When I got the answer (and double checked my work) I was, surprised.

SRBs don't use that model because the chance of a failure becomes vanishingly small, but I didn't take into account multiple SRBs.

So assuming I changed it to work exactly the same way that other parts work (calculations in the spoiler)
 

  Hide contents

Chance of Event A (Overall vessel failure roll) = 0.01

Change of Event B (individual part failure) = 0.05

Chance of both events occuring: A*B = 0.01*0.05=0.0005

Chance of no event occuring: 0.9995

Assume 4 potential failure points (4 SRBs): 0.9995^4 = 0.998(rounded)

 

Chance of failure: 0.002%.

That's.... unacceptably low tbh. It works for other parts because they have multiple failure points (get rolled often) - but for SRBs I need to do something different.

What that's going to be I don't know yet :P but you are right that the current model is just as bad but the other way.

My professor would be proud of me. &):lol:

Thank you for looking into this! I've had so many interesting (in many senses of the word) missions because of the feeling of realism (and real stakes) that this mod brings to the game. It's why I set up real abort sequences and use a LES.

Share this post


Link to post
Share on other sites

Hi @severedsolo,

while reading this thread today I had one or two ideas that you might find interesting (or maybe not). To cut short: I have not been playing the game for quite a while now so forgive me if am going to say something totally wrong, but IIRC when this mod is installed, failures are almost immediate. Indeed sudden and catastrophic failures are realistic in most situations, especially where rockets and big fuel masses are involved, yet I can imagine situations where a system starts malfunctioning before it fails. An engine for instance might start overheating and/or vibrating before it shuts down or explodes, a battery might start leaking liquid before it actually starts losing its charge, an electrical system might suffer electrical dispersion before it blows up, etc, etc. Moreover, some malfunctions might evolve in major failures, while others, like a loose electrical connection might cause certains parts to work intermittently.

So my idea is: after certain parts * are marked for failure, a second dice should be rolled for deciding whether the said part will fail immediately or not.

  • If true (sudden failure), the failure is handled as per current version of OhScrap!;
  • if false (malfunction):
  • the part is marked as "malfunctioning";
  • the player gets an alarm and a notification on the defective part and on the nature of the anomaly/malfunction **;
  • another dice is rolled for deciding whether the malfunctioning part will eventually fail or not:
    • if yes, after a random number of seconds unknown to the player, the anomaly will irrevocably evolve in major failure if not fixed; during this time the player can take action to limit the (future) damage, and he can try fixing the problem the way we currently do with normal failures ***;
    • if no, no random timer will be set but, unless fixed, the part will have an higher chance of failure during the next dice rolls (i.e. a multiplier >1 will be applied to its regular failure chance).

Malfunctioning/defective parts might still accomplish their function normally though, if not too complicated, it would be cool if they worked poorly (e.g: thrusters and engines working intermittently, burning too much fuel or having a reduced power, solar panels recharging batteries at  a low rate, radio and other electrical equipment switching on and off, etc.). Only a a successful fix should revert a malfunctioning part to its normal status. Moreover, a defect/malfunction shouldn't apply to a defective part more than once, so if during regular failure checks a part previously (and still) marked as "malfunctioning" is chosen again for failure, the routines above shouldn't apply and the part should fail immediately.

Notes:

* Of course, the ideas discussed here can't apply to all the rocket parts. SRBs and probably tanks are a good example of parts that can surely fail but hardly malfunction.

**  It  would be cool if the detection and notification of some anomalies required appropriate sensors, in the form of stock or custom parts that we could fit on our command modules. In their absence, malfunctions would still happen as described above, but we would only know about them from their effects.

*** Maybe, due to their lesser severe nature, malfunctions should have a slight better chances of being fixed compared to failures.

Well, that should be more or less all. I hope I made myself clear enough. Let me know if among my ravings you found something useful.

Edited by gap

Share this post


Link to post
Share on other sites

1.8 Compatibility

Initial testing suggests no (new) major problems with Oh Scrap - recompile will come along after the inevitable KSP 1.8.x patches.

Minor issue: Parts that incorporate "TankFailureModule" but have no resources that can leak, will display a "Base Failure Module" field in the PAW. This can be ignored.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.