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

[severedsolo]

Deprecated - Oh Scrap is now maintained by zer0kerbal here:

 

 

 

Oh Scrap! (formerly UPFM)

Poor Val, she's not having a good day. There she was on her way back from orbit, and this happened:

Spoiler

You see, I forgot to take her shiny new ship for a test flight before sending it to space, so the reaction wheels failed. Then her oxygen started venting into space. So she quickly burned retrograde and started her re-entry. Except that as she came into land, the parachute failed too. Like I said, not a good day.

Sound exciting? Then why don't you install Oh Scrap! today.

Features

• Part Failures: Parachutes, Engines, Gimbals, Resources, Batteries, Reaction Wheels, Control Surfaces - all these failures can make your day turn out like Vals. (all can be disabled or enabled through the difficulty settings menu)
• Failures follow the bathtub curve - brand new untested parts are more likely to fail than pre-tested models. If you re-use a part too many times though, it will reach the end of it's shelf-life and be more prone to failure.
• Subsequent "new models" of parts become more reliable than their earlier counterparts. Ie, a part you've just researched is more likely to fail than a part that has been tried and tested many times - even if it's brand new.
• Repairs - some parts can be repaired remotely, some need an EVA. You always have a better chance of repairing a part on EVA

Dependencies and Recommendations

• This mod uses ScrapYard to keep track of how many times a part has been built/recovered so that is a hard dependency. (obtained separately)
• Module Manager is required if you want the mod to actually do anything. (obtained separately)
• I've designed this with Kerbal Construction Time in mind, so would recommend that mod (make sure you use the latest dev version)
• If you plan to actually re-use your parts (and have them fail), you'll probably want StageRecovery too (see Kerbal Construction Time link)

Eye candy of a really awesome Static Test that someone set up on facebook (used with permission):

Spoiler

Spoiler

Special Thanks

@magico13 both for ScrapYard, and helping me with all my questions issues while making this.

The maintainers/authors of DangIt - most of this would never have happened without looking at your code to figure out how to make stuff work.

DOWNLOAD:

CHECK YOU HAVE SCRAPYARD AND MODULE MANAGER INSTALLED FIRST

Download Here

License: MIT

A note to CKAN USERS:
 

Quote

Kerbal Changelog is not a hard dependency, in that "Oh Scrap will load just fine without it".

However, on CKAN it is a dependency.

When I make a serious save / mod breaking change, CKAN will happily update you without you ever seeing a changelog. This means you could happily load your save, not notice the major version number has changed, and seriously break something. I do not like this. So CKAN users must use Kerbal Changelog, because that way nobody can say they weren't warned .

 

Edited April 1, 2020 by severedsolo

[nascarlaser1]

This looks cool!

1 quick question though. Minus the need for scrapyard and the recommendation for KAC, are there any major differences between this and @linuxgurugamer's Dangit continued mod?

[severedsolo]

8 minutes ago, nascarlaser1 said:

This looks cool!

1 quick question though. Minus the need for scrapyard and the recommendation for KAC, are there any major differences between this and @linuxgurugamer's Dangit continued mod?

The differences are mostly in the reliability model.

With DangIt parts start off reliable, and wear out as the mission goes on, so on longer missions a failure is almost inevitable.

With UPFM a part is essentially rated for x amount of missions. That's not to say it won't fail beforehand, but if it's a tried and tested part, and only on it's 2nd or 3rd launch then chances are it won't. (1st launches have a higher failure rate). Just doing the maths in my head, a part that has been built 4 times, and has survived it's test flight will only have a 6.25% chance of failing (over the course of the entire mission) - even if you were to send it to Eeloo for 5 years.

DangIt also has a few failures I don't, and vice versa.

Edited May 20, 2017 by severedsolo

[nascarlaser1]

2 minutes ago, severedsolo said:

The differences are mostly in the reliability model.

With DangIt parts start off reliable, and wear out as the mission goes on, so on longer missions a failure is almost inevitable.

With UPFM a part is essentially rated for x amount of missions. That's not to say it won't fail beforehand, but if it's a tried and tested part, and only on it's 2nd or 3rd launch then chances are it won't. (1st launches have a higher failure rate). Just doing the maths in my head, a part that has been built 4 times, and has survived it's test flight will only have a 6.25% chance of failing (over the course of the entire mission) - even if you were to send it to Eeloo for 5 years.

DangIt also has a few failures I don't, and vice versa.

oh ok thanks! As far as you know, would there be any reason for the two mods to clash with each other on the same save?

[severedsolo]

Just now, nascarlaser1 said:

oh ok thanks! As far as you know, would there be any reason for the two mods to clash with each other on the same save?

The only thing I could think of off the top of my head is if one of them thought a part has failed, and one didn't. They might fight each other (I'm not sure how DangIt handles this, but UPFM will reset the failure event every physics frame, to stop you from re-activating your engines etc).

[nascarlaser1]

18 minutes ago, severedsolo said:

The only thing I could think of off the top of my head is if one of them thought a part has failed, and one didn't. They might fight each other (I'm not sure how DangIt handles this, but UPFM will reset the failure event every physics frame, to stop you from re-activating your engines etc).

ok thxs!

[Pand5461]

21 hours ago, severedsolo said:

Subsequent "new models" of parts become more reliable than their earlier counterparts. Ie, a part you've just researched is more likely to fail than a part that has been tried and tested many times - even if it's brand new.

Is it like what TestFlight mod is doing? I love this idea but find TF too complicated with its aim to RO, lots of failure types and need for configs.

Does your mod also need configs for each part or it uses reasonable defaults for each type of part (solar panel, engine, parachute etc.)?

[severedsolo]

27 minutes ago, Pand5461 said:

Is it like what TestFlight mod is doing? I love this idea but find TF too complicated with its aim to RO, lots of failure types and need for configs.

Essentially yes, but rather than needing to gather in-flight data it's assumed the data is automatically streamed back to KSC and the next build will be more reliable.

27 minutes ago, Pand5461 said:

Does your mod also need configs for each part or it uses reasonable defaults for each type of part (solar panel, engine, parachute etc.)?

Configs should be handled automatically, I'm sure they will need tweaking (for instance, I discovered yesterday that IntakeAir can leak... which I've fixed but not released yet) - but essentially it will attach itself to anything that has a resource/ModuleEngines/ModuleParachutes/ModuleControlSurface etc.

Right now everything is using default values (most of the work is actually done by a Base failure module, with each part having it's own module to actually do the failures) - depending on feedback I may tweak these at some point.

Edited May 21, 2017 by severedsolo

[Pand5461]

14 minutes ago, severedsolo said:

essentially it will attach itself to anything that has a resource/ModuleEngines/ModuleParachutes/ModuleControlSurface etc.

So it isn't supposed to accidentally make mod parts that have no config files failure-prone as TF usually does?

Also, it would be nice if part recovery contributed more to the reliability of next generation than just plain flight.

And having tweaked stats for some parts may be useful to somewhat balance the stock game (I am talking about Vectors, of course). Actually, even some automated guessing is possible, like giving parts with high performance/size ratio (e.g. thrust/attachment size for engines, EC/mass for batteries, ECpersec/mass for solar panels) lower MTBF and higher wear rates.

[severedsolo]

1 minute ago, Pand5461 said:

So it isn't supposed to accidentally make mod parts that have no config files failure-prone as TF usually does?

I don't know how TestFlight does it, but UPFM will attach itself to all engines, all resource tanks (unless that resource is blacklisted), all parachutes, reaction wheels and batteries (assuming they use the stock Modules)

5 minutes ago, Pand5461 said:

Also, it would be nice if part recovery contributed more to the reliability of next generation than just plain flight.

Thats possible, will add it to the list (thats why we are in Beta). 

 

5 minutes ago, Pand5461 said:

And having tweaked stats for some parts may be useful to somewhat balance the stock game (I am talking about Vectors, of course). Actually, even some automated guessing is possible, like giving parts with high performance/size ratio (e.g. thrust/attachment size for engines, EC/mass for batteries, ECpersec/mass for solar panels) lower MTBF and higher wear rates.

There is no MTBF - what matters is how many times that part has been flown/built. Parts don't become more prone to failure on long missions (I made a concious decision to do this, as I would essentially be making DangIt! otherwise).

Your point is well made though, as Beta continues individual parts may well get tweaked, depending on feedback received.

[Pand5461]

Another question - what is a "first flight" for a specific part, exactly? Does it need to be activated, then recovered? If not, then player might just rollout a rocket, recover it and put back on launchpad for the second flight.

[severedsolo]

9 minutes ago, Pand5461 said:

Another question - what is a "first flight" for a specific part, exactly? Does it need to be activated, then recovered? If not, then player might just rollout a rocket, recover it and put back on launchpad for the second flight.

Well yes, that is a concern. There isn't really alot I can do about that as ScrapYard just tracks each recovery. In my mind, the "typical" player using this will also be using KCT though, so the extra build time would put them off.

Sometimes you just have to trust the player.

Edit: Actually I've just realised it's possible to tell ScrapYard to not add a part to the inventory under certain circumstances (I already do this when a part is broken) - I can make it so the part won't be saved if it's not used. Added to the list.

Edited May 21, 2017 by severedsolo

[Pand5461]

4 minutes ago, severedsolo said:

Sometimes you just have to trust the player.

When you're doing a mod which makes their life harder, probably so.

If you're making a mod which helps them, they're going to massively abuse it and blame you for it not working in edge cases (I guess, not a modder myself).

[severedsolo]

2 hours ago, Pand5461 said:

When you're doing a mod which makes their life harder, probably so.

If you're making a mod which helps them, they're going to massively abuse it and blame you for it not working in edge cases (I guess, not a modder myself).

Probably. The only person they are really cheating is themselves though. Anyway, the latest beta should help a little. You could still exploit it if you really wanted to, but meh.

UPFM 0.2 (Beta 2) released:

• Solid Fuel & Intake Air are now blacklisted as potential leaks
• Solid Fuel engines can no longer fail.
• Vessels that haven't been launched will be blocked from being added to the inventory on recovery.
• Fixed mismatched headings in Settings Menu

 

Edited May 21, 2017 by severedsolo

[Pand5461]

Tried a launch in Sandbox, nothing bad happened. Disappointed

Do not want to test this in career because of possible save breaking.

So, a question: is it possible, for testing purposes, to make a failure chance multiplier somewhere in Settings or config file? Raise

Also, how is the mod supposed to know mission duration for a part to fail at certain chance per mission? Or all the failures just happen at launchpad?

[severedsolo]

15 minutes ago, Pand5461 said:

Tried a launch in Sandbox, nothing bad happened. Disappointed

Nothing at all? The 1st launch failure rate is really high (like 50%) - something should have failed. Might be worth checking your log for entries starting with [UPFM]:

To answer your question, you could change the configs to add this line to the modules:

chanceOfFailure = 1

which would give a base chance failure of 100%

15 minutes ago, Pand5461 said:

Also, how is the mod supposed to know mission duration for a part to fail at certain chance per mission? Or all the failures just happen at launchpad?

It fudges it a little bit, everything is rolled when the vessel is loaded, and then any failures that are rolled are assigned a "failure time" - so the actual failure will occur at some point in the future.

Edited May 21, 2017 by severedsolo

[Pand5461]

4 minutes ago, severedsolo said:

Nothing at all? The 1st launch failure rate is really high (like 50%) - something should have failed. Might be worth checking your log for entries starting with [UPFM]:

The only log line with UPFM in it is:

[GameParameters]: Loaded custom parameter class UPFMSettings.

So, probably, nothing at all. Is mod supposed to work on Linux?
I haven't gone past LKO, though.

Log file

17 minutes ago, severedsolo said:

It fudges it a little bit, everything is rolled when the vessel is loaded, and then any failures that are rolled are assigned a "failure time" - if the vessel is active at that time the failure happens. If not, it's re-rolled next time you load the ship. Basically, if something is going to fail, it should do it within 30 minutes of launch.

And time of failure has something like gaussian distribution?

From what I can understand in the code engine is only going to fail if it's on at the failure time. So, if an upper stage engine is set to fail 1s into the flight, it won't do so? If so, maybe it's more realistic to reroll after each staging? It also would help to set engine fail times within a minute or so, so they have higher chance of being not yet jettisoned when scheduled to fail.

[severedsolo]

26 minutes ago, Pand5461 said:

So, probably, nothing at all. Is mod supposed to work on Linux?

Could you send me your save? Your issue is that Magicore is freaking out about a negative number of builds. You could try just wiping the whole Inventory out of the save, and starting again, but I'd like to have a look at your save anyway.

Quote

From what I can understand in the code engine is only going to fail if it's on at the failure time. So, if an upper stage engine is set to fail 1s into the flight, it won't do so?

Eh, yes and no. The failure will "happen", but the event will be suppressed until you try to use the engine. The moment you throttle up that engine, the failure event will occur.

[Pand5461]

OK, started game afresh, now KCT can't build anything at all. Wasted the old save in the process. Last time I built a ship with only KCT installed, then copied ScrapYard and UPFM to GameData, and managed to launch. I suspect my MagiCore from KCT is inconsistent with ScrapYard or something.

Found the code which sets the failure time. Uniform time distribution and 30 minutes put the typical time to failure of first-stage engines too far into the flight.

I think, it's better to set gaussian-distributed failure times (here is the explanation how this may be done) with standard deviation, say, 2 minutes for engines and 30 minutes for everything else.

Another mathematical issue is this:

if (SYP.TimesRecovered > 0) chanceOfFailure = chanceOfFailure * ((SYP.TimesRecovered / expectedLifetime));

Maybe try this way:

chanceOfFailure = 1 - (1 - chanceOfFailure) * Math.Exp(- SYP.TimesRecovered / expectedLifetime);

This ensures that chanceOfFailure always < 1 and eliminates the need for "if" check.

[severedsolo]

2 minutes ago, Pand5461 said:

I suspect my MagiCore from KCT is inconsistent with ScrapYard or something.

Oh yeah, use the magicore that comes bundled with ScrapYard, the one that comes with KCT will not work.

Thanks for the tips about the math, I will look into it and will probably end up using them.

[Pand5461]

17 minutes ago, severedsolo said:

use the magicore that comes bundled with ScrapYard, the one that comes with KCT will not work.

Thanks!

So far, so good. First flight: got failed reaction wheels and leaky tank, failed to get to orbit. Second flight: did a test, recovered, flew for real. Got a stuck winglet on the launchpad. Reaction wheel stopped working midflight.

First test are well, I suppose.

Now, question. What are generations and how to increase them (especially, in Sandbox)?

Some feature requests:

- Failures for solar panels and antennae (would be fun to see panels fail to retract and burn on reentry)

- Width of failure time distribution depending on part type. For engines, about Isp/2, for other stuff 30 minutes is actually an excellent value (meaning most failures happen within the first orbit).

- If possible, a change of failure model for engines. Currently, the total chance of failure may be expressed as min(1, chanceOfFailure*(TimeInUse/1800)), TimeInUse is time in seconds part actually stays attached to the craft during the mission. From here, you can clearly see the flaw: lower stage engines are going to have much lower failure rates because they don't stay together with the rocket for very long.

A model for engine failure, if I may:

1) At the initialization, set a flag for each engine if it's going to fail at all on this mission.

2) For each engine to fail, choose whether it's going to happen at ignition or midflight (say, 75% from the total fail chance is at ignition, other 25% midflight)

3) Choose the failure mode.

4) For engines set to fail at ignition, apply the failure mode when engine is activated.

5) For engines set to fail midflight, calculate failure time when they're activated.

6) For more realistic behavior, time to failure should be gaussian with standard deviation 1-3 min, so let it be Isp/2, where Isp is vacuum specific impulse in seconds.

 

[severedsolo]

1 minute ago, Pand5461 said:

Now, question. What are generations and how to increase them (especially, in Sandbox)?

A parts generation is how many "new builds" there have been of that part. Essentially, everytime you build a new part and don't apply the scrapyard inventory, thats a new generation (kind of - you could slap 20 of them on the same rocket, it would only increase the generation by 1, but you get the gist).

Every new generation is more reliable than the last (the actual formula is Base Failure Rate (default 50%) divided by generation).

5 minutes ago, Pand5461 said:

- Failures for solar panels and antennae (would be fun to see panels fail to retract and burn on reentry)

Thats on the list. Antennae in particular.

Quote

Lots of great stuff about engines

Yeah, my early playtesting kinda suggests the same thing as you are saying, engines stay with the craft for about 2 minutes or less, so 30 minutes is way too much time to wait to fail. I like your model, I am raising this on Github so I don't forget.

[TheRagingIrishman]

5 hours ago, severedsolo said:

Solid Fuel engines can no longer fail.

The astronauts on Space Shuttle Challenger's last flight would disagree with this statement (if they could)

Edited May 21, 2017 by TheRagingIrishman

[severedsolo]

1 minute ago, TheRagingIrishman said:

The astronauts on Space Shuttle Challenger's last flight would disagree with this statement if they could

Alright Mr Picky.

"Solid Fuel engines will no longer fail in UPFM because KSP doesn't model the failures very well"

Edited May 21, 2017 by severedsolo

[Daelkyr]

This is a very cool looking mod. I'll have to give it a try in a play thru.