severedsolo

[1.8.x] Oh Scrap!- A ScrapYard based Part Failure and Reliability Mod 2.0.1 (07/12/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
On 10/17/2019 at 1:56 PM, severedsolo said:

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.

Just an FYI, they are now talking about 1.9, so I don't think there will be any more updates for 1.8

Share this post


Link to post
Share on other sites
1 hour ago, linuxgurugamer said:

Just an FYI, they are now talking about 1.9, so I don't think there will be any more updates for 1.8

Yeah, I know I'm behind, it's been a busy few weeks, I'm off work next week so hopefully I can find some time

Share this post


Link to post
Share on other sites

Oh Scrap 2.0 Released

  • Recompile against KSP 1.8 / .Net 4.2.7
  • Resized icon so KSP can properly compress it when using half res textures
  • Added Alternator Failures
  • Added Landing Gear Failures
  • Support MADLAD's Install Validator

Oh Scrap 2.0.0.1 Released

  • Fix bad .version file
Edited by severedsolo

Share this post


Link to post
Share on other sites
5 hours ago, severedsolo said:

Oh Scrap 2.0 Released

  • Recompile against KSP 1.8 / .Net 4.2.7
  • Resized icon so KSP can properly compress it when using half res textures
  • Added Alternator Failures
  • Added Landing Gear Failures
  • Support MADLAD's Install Validator

Oh Scrap 2.0.0.1 Released

  • Fix bad .version file

I noticed an issue running KSP 1.8.1 and this newest version (2.0.0.1) on an existing save (along with Scrapyard, of course).  With the newest version, the scene never loads.  This error shows up in KSP.log:

[EXC 11:09:36.456] NullReferenceException: Object reference not set to an instance of an object
    OhScrap.BaseFailureModule.Initialise () (at <a6ec50f290af4da2b6f40211fa3cb8f5>:0)
    OhScrap.BaseFailureModule.FixedUpdate () (at <a6ec50f290af4da2b6f40211fa3cb8f5>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

If I roll back to Oh Scrap 1.7.1, everything is good to go. I have a saved KSP.log and mod list if that helps.  I noticed I can get a scene to load from the tracking center, but then KSP slows to a crawl.

 

Share this post


Link to post
Share on other sites
2 minutes ago, Jade_Falcon said:

I have a saved KSP.log and mod list if that helps.

No need, I know what the issue is. It's trying to call some debug stuff that doesn't get compiled into the release version and falling over when it can't find it. I forgot that it doesn't compile that code in Release, I thought it just hid it. Sorry about that.

Oh Scrap 2.0.1 Released

  • Fixed NRE Spam and slowdown

Share this post


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

No need, I know what the issue is. It's trying to call some debug stuff that doesn't get compiled into the release version and falling over when it can't find it. I forgot that it doesn't compile that code in Release, I thought it just hid it. Sorry about that.

Oh Scrap 2.0.1 Released

  • Fixed NRE Spam and slowdown

No worries 2.0.1 works a treat! Thanks!

Share this post


Link to post
Share on other sites

Running KSP 1.8.1, no matter what mods are or are not loaded, getting this error repeating endlessly when in the editor:

[EXC 16:06:29.931] NullReferenceException: Object reference not set to an instance of an object
    OhScrap.BaseFailureModule.Initialise () (at <a6ec50f290af4da2b6f40211fa3cb8f5>:0)
    OhScrap.BaseFailureModule.Start () (at <a6ec50f290af4da2b6f40211fa3cb8f5>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

I've stripped the mods down to MagiCore, ScrapYard, ModuleManager, and OhScrap!

I"ve also noticed that all the Safety Ratings are set to -1 on all parts as show below.

I can provide more info if needed. I've tried new saves and everything and am still getting the same results.

yg6gzE8.pngBKBY9Qu.jpg

EDIT: This is Running OhScrap! 2.0.1, the latest version.

Edited by coppercore

Share this post


Link to post
Share on other sites
16 minutes ago, coppercore said:

Running KSP 1.8.1, no matter what mods are or are not loaded, getting this error repeating endlessly when in the editor:

Look three posts up :) already reported and fixed, you need to update again.

Edited by severedsolo

Share this post


Link to post
Share on other sites

Can confirm this has fixed the issue, mod seems to be working properly now.

I swear up and down I had grabbed 2.0.1, maybe I mistakenly grabbed 2.0.0.1.

Regardless, thanks!

Share this post


Link to post
Share on other sites

@severedsolo

I saw this while working on another mod:

Uploading Crash Report
NullReferenceException: Object reference not set to an instance of an object
  at OhScrap.StageRecoveryHandler.OnDisable () [0x00005] in <3c44eb5767564bfe8283ef47bbcfb754>:0 
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object

I'm' not sure how significant it is, I believe it happened when exiting the game.  I did have Stage Recovery installed.  Let me know if there is anything else you would want.

Here is a link to the full log:  https://www.dropbox.com/s/1e31mp66z4yd1pu/OhScrapStageRecoveryError.zip?dl=0

Share this post


Link to post
Share on other sites
14 hours ago, linuxgurugamer said:

@severedsolo

I saw this while working on another mod:


Uploading Crash Report
NullReferenceException: Object reference not set to an instance of an object
  at OhScrap.StageRecoveryHandler.OnDisable () [0x00005] in <3c44eb5767564bfe8283ef47bbcfb754>:0 
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object

I'm' not sure how significant it is, I believe it happened when exiting the game.  I did have Stage Recovery installed.  Let me know if there is anything else you would want.

Here is a link to the full log:  https://www.dropbox.com/s/1e31mp66z4yd1pu/OhScrapStageRecoveryError.zip?dl=0

Oh yeah, I know what that is. Game.Mode doesn't exist on the Main Menu. Thanks

Share this post


Link to post
Share on other sites

Explain one point, if there was an accident on the ship, and I canceled the flight, the reliability of the parts will remain the same?

Share this post


Link to post
Share on other sites
6 hours ago, Craze said:

Explain one point, if there was an accident on the ship, and I canceled the flight, the reliability of the parts will remain the same?

Do you mean if you revert? - the reliability won't change if you revert because it's like the flight never happened.

If you mean "did a successful rescue/recovery" then the reliability will change. Oh Scrap doesn't care how far the parts got, only that they flew.

Share this post


Link to post
Share on other sites
4 hours ago, severedsolo said:

Do you mean if you revert? - the reliability won't change if you revert because it's like the flight never happened.

If you mean "did a successful rescue/recovery" then the reliability will change. Oh Scrap doesn't care how far the parts got, only that they flew.

Thanks, that's what I expected.

Share this post


Link to post
Share on other sites
1 hour ago, Craze said:

What if there was nothing left of the ship?

not sure what you mean... if *any* parts were recovered intact, they could make it back into the part pool, otherwise reliability would improve because newer versions of the parts would be built next time.

Share this post


Link to post
Share on other sites
57 minutes ago, Beetlecat said:

not sure what you mean... if *any* parts were recovered intact, they could make it back into the part pool, otherwise reliability would improve because newer versions of the parts would be built next time.

If the part or the whole ship was vaporized by the explosion, then the next time you use such a part, it will be more reliable? Just some subtleties are not fully understood.

Share this post


Link to post
Share on other sites
3 minutes ago, Craze said:

If the part or the whole ship was vaporized by the explosion, then the next time you use such a part, it will be more reliable? Just some subtleties are not fully understood.

Every time a part gets built "new" -- it gets considered a newer "generation" of part --- so if you build the same craft five times in a row, the fifth craft will be "better" because of all the refining of part making and materials, or whatever version of improvement that the mod is simulating. :)

Share this post


Link to post
Share on other sites
Just now, Beetlecat said:

Every time a part gets built "new" -- it gets considered a newer "generation" of part --- so if you build the same craft five times in a row, the fifth craft will be "better" because of all the refining of part making and materials, or whatever version of improvement that the mod is simulating

Nice. Ty for you.

Share this post


Link to post
Share on other sites
On 10/13/2019 at 4:38 PM, severedsolo said:

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.

Well... consider this. If any SRB fails, it's likely going to be a problem for the flight unless it and the symmetrical counterpart(s) of that SRB are ditched before they can be used.

So, the overall rating of SRBs could be approximated to the rating of the least reliable SRB on the ship. But when an actual failure occurs, you can still roll on a weighted table to see which one actually fails.

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.