[1.8.x] Oh Scrap!- A ScrapYard based Part Failure and Reliability Mod 2.0.1 (07/12/2019)

[gap]

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 October 14, 2019 by gap

[severedsolo]

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.

[linuxgurugamer]

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

[severedsolo]

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

[severedsolo]

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 December 7, 2019 by severedsolo

[Jade_Falcon]

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.

 

[severedsolo]

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

[Jade_Falcon]

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!

[coppercore]

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.

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

Edited December 7, 2019 by coppercore

[severedsolo]

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 December 7, 2019 by severedsolo

[coppercore]

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!

[linuxgurugamer]

@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

[severedsolo]

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

[Craze]

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?

[severedsolo]

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.

[Craze]

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.

[Craze]

What if there was nothing left of the ship?

[Beetlecat]

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.

[Craze]

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.

[Beetlecat]

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.

[Craze]

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.

[severedsolo]

I should really write some documentation one of these days, that question comes up alot

[MarvinKosh]

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

[DasValdez]

On 12/23/2019 at 12:51 AM, 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.

I've been running into issues with this lately, specifically for STTOs/spaceplanes.

I fly a complete SSTO mission from the runway, all the way to orbit, deploy the payload, land back at the runway... and get no generation increase. At first I thought it was KCT conflicting, with it's "recover to SPH" function, but specific testing by using only the stock recovery function gives the same behavior. I can't get it to reliably upgrade gens. Any chance you could define how/when the generation increase code is called @severedsolo? Would help with further troubleshooting.

Additionally, we've run into the old issue where Oh Scrap is spamming fail tests as fast as it can for a craft that spawns on the runway. Even at overall reliability 9, a craft sitting on the runway for about 60s had almost every non-reliability-10 part fail. Only way to mitigate is to spawn to the runway and immediately light a stage, which flips the fail check spam down to a more reasonable level.

Is there anything we can check there? Under what circumstances would the mod attempt to spam a check per second? It may be a conflict with World Stabilizer, which spawns the craft off the ground and "eases" it down... so perhaps the game is thinking a newly spawned craft starts at a state of flying and then becomes landed? Still not sure why a landed craft would spam a fail check per second, though...

Currently on Oh Scrap 2.0.1

[severedsolo]

16 minutes ago, DasValdez said:

Any chance you could define how/when the generation increase code is called @severedsolo? Would help with further troubleshooting.

Well the generation won't increase if you are fully recovering and re-using the parts. OhScrap stores the PartID and recalls it when the PartModule loads. It's a fairly complex bit of code but it starts here: https://github.com/severedsolo/OhScrap/blob/c4028fa93ee707fd250250bd250b20a78d3812e9/OhScrap/BaseFailureModule.cs#L162 - if the safety rate isn't changing that's a definite bug.

27 minutes ago, DasValdez said:

Is there anything we can check there? Under what circumstances would the mod attempt to spam a check per second? It may be a conflict with World Stabilizer, which spawns the craft off the ground and "eases" it down... so perhaps the game is thinking a newly spawned craft starts at a state of flying and then becomes landed? Still not sure why a landed craft would spam a fail check per second, though...

You are probably onto something with WorldStabiliser actually. When the situation changes, it immediately rolls. I bet the situation is changing really quickly. That's the only thing I can think of that would cause this - the fallback option is "deep space" which is about every 30 days or something stupid like that.

Test build for you: https://1drv.ms/u/s!AtG2PODa0fmwisQTp1nEgy1d20HKDg?e=67sTLV

Won't fix the issue, but should log enough to tell me what's going on. Reproduce and provide the log please.