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

[severedsolo]

9 hours ago, gap said:

It works! With this new version, vessel's safety rating is always updated even after having closed a previously assembled/loaded vessel and having started a new craft.

There is one remaining bug though: some parts seem to be ignored as "worst part" in the OhScrap window. You can notice that if you run the save game I sent you yesterday and you load the "Gliding Lizard Mk. III" in the VAB; its SRB (safety rating = 4) is always reported as the worst part, even though one of the Mk 16 parachutes has a worst safety rating (=2). Curiously, if I replace any of the tested/used parts (including the Mk 16 chutes) with a completely new one (safety rating = 1), the new part will be correctly considered the worst part rather than the said RT-10 solid fuel booster. Any idea on why that might happen?

It genuinely is the worst part.

                        for (int b = 0; b < bfmList.Count(); b++)
                        {
                            BaseFailureModule bfm = bfmList.ElementAt(b);
                            if (bfm == null) continue;
                            if (!bfm.ready) return;
                            if (bfm.chanceOfFailure > worstPartChance)
                            {
                                worstPart = p;
                                worstPartChance = bfm.chanceOfFailure;
                            }
                            vesselSafetyRating += bfm.safetyRating;
                            bfmCount++;
                        }
}

Note that worst part is looking for chanceOfFailure not safetyRating - when I look at that craft file, I can see that your SRB says:

chanceOfFailure = 0.100000001

When I look at your Parachute, I see this:

chanceOfFailure = 0.0544999987

Remember, Safety Ratings are relative. For an SRB, 10% isn't bad, for a parachute 5% is quite bad. (because SRBs have one failure point, so they are set higher to start with, whereas parachutes can fail at any point).

When you place a new chute, the baseChanceOfFailure is 0.109999999 - higher than the SRB, so it genuinely is the worst part.

Just to pre-empt your next question, the reason the SRB is not shown as the worst part in the flight scene is that they are excluded from the calculations, because they can only fail on launch, so you are more interested in a part that can fail any time.

[Nnimrod]

Hi, I want SRBs to be able to spontaneously and catastrophically fail while in use. You have liquid engines doing just that, although it's preceded by the "Fuel line leak". Also, is there a way that you could make liquid engines fail catastrophically some of the? So there is no "Fuel line leak"? Or at least no message about the leak.

 

Also, how exactly does expectedLifetime work?

Edited July 7, 2019 by Nnimrod

[AnotherCompatiblityIssue!!]

Would it be possible to change the 'test' check to become permanent if you complete a testing contract for the specific part?

The current way to do it is more tedious than fun.

Other than that, great mod!

[Daedalus451]

Getting this nullref spam from Oh Scrap. Any ideas?

Spoiler

[EXC 02:10:49.394] NullReferenceException: Object reference not set to an instance of an object
    OhScrap.ReactionWheelFailureModule.FailureAllowed ()
    OhScrap.UPFMUtils.SetNextCheck (System.Collections.Generic.List`1 failureModules)
    OhScrap.UPFMUtils.CheckForFailures ()

Could Mandatory RCS be causing this?

[severedsolo]

7 minutes ago, Daedalus451 said:

Getting this nullref spam from Oh Scrap. Any ideas?

  Hide contents

[EXC 02:10:49.394] NullReferenceException: Object reference not set to an instance of an object
    OhScrap.ReactionWheelFailureModule.FailureAllowed ()
    OhScrap.UPFMUtils.SetNextCheck (System.Collections.Generic.List`1 failureModules)
    OhScrap.UPFMUtils.CheckForFailures ()

Could Mandatory RCS be causing this?

That method only has one thing that can possibly throw an NRE.

Probably what's happening is that something is removing ModuleReactionWheel after the OhScrap patches have ran, so when it's trying to grab ModuleReactionWheel it's returning null.

As a bandaid, you can put :FINAL at the end of the ReactionWheelFailureModule patch

@PART[*]:HAS[@MODULE[ModuleReactionWheel]]:FINAL

Having said that, I should handle that ALOT better. Raised #19

[severedsolo]

On 7/7/2019 at 5:33 PM, Nnimrod said:

Also, how exactly does expectedLifetime work? 

Apologies for the slow replies here, it's been a difficult few weeks.

A modifier is applied to the failure rate which is equivalent to timesRecovered/expectedLifetime. If timesRecovered is greater than expectedLifetime (ie it has exceeded it's lifetime) then a further penalty is applied to the failure rate.

Practical example:
Control Surfaces have a base failure rate of 0.11% and an expectedLifetime of 6. For simplicity we'll assume our part is generation 1 (further bonuses are applied for higher generations)

Case 1 - Part is brand new.

failureRate = baseFailureRate+0.01 (the 0.01 is applied as generation 10+ parts would have a failure rate of 0 otherwise).

failureRate = 0.12

12% chance of failure.

Case 2 - Part has been used once

failureRate = (baseFailureRate+0.01) * (timesRecovered / expectedLifetime)

failureRate = 0.12 * (1/6)

failureRate = 0.12 *  0.166666667 = 0.02

2% chance of Failure.

Case 3 - Part has been used ten times (beyond expectedLifetime)

failureRate = (baseFailureRate+0.01) * (timesRecovered / expectedLifetime)

failureRate = 0.12 * (10/6) + endOfLifePenalty.

failureRate = 0.12 * 1.666666667 + 0.04 (complicated calculation that I won't get into here)

failureRate = 0.24

24% chance of failure.

I think I'm going to remove the additional penalty though. It already ramps up enough when beyond EOL anyway, I think that's a hangover from when we only checked once for failures.

 

 

[Nnimrod]

13 hours ago, severedsolo said:

Apologies for the slow replies here, it's been a difficult few weeks.

A modifier is applied to the failure rate which is equivalent to timesRecovered/expectedLifetime. If timesRecovered is greater than expectedLifetime (ie it has exceeded it's lifetime) then a further penalty is applied to the failure rate.

Practical example:
Control Surfaces have a base failure rate of 0.11% and an expectedLifetime of 6. For simplicity we'll assume our part is generation 1 (further bonuses are applied for higher generations)

Case 1 - Part is brand new.

failureRate = baseFailureRate+0.01 (the 0.01 is applied as generation 10+ parts would have a failure rate of 0 otherwise).

failureRate = 0.12

12% chance of failure.

Case 2 - Part has been used once

failureRate = (baseFailureRate+0.01) * (timesRecovered / expectedLifetime)

failureRate = 0.12 * (1/6)

failureRate = 0.12 *  0.166666667 = 0.02

2% chance of Failure.

Case 3 - Part has been used ten times (beyond expectedLifetime)

failureRate = (baseFailureRate+0.01) * (timesRecovered / expectedLifetime)

failureRate = 0.12 * (10/6) + endOfLifePenalty.

failureRate = 0.12 * 1.666666667 + 0.04 (complicated calculation that I won't get into here)

failureRate = 0.24

24% chance of failure.

I think I'm going to remove the additional penalty though. It already ramps up enough when beyond EOL anyway, I think that's a hangover from when we only checked once for failures.

 

 

Thanks, I appreciate your work

[Daedalus451]

On 8/4/2019 at 12:17 PM, severedsolo said:

 As a bandaid, you can put :FINAL at the end of the ReactionWheelFailureModule patch

@PART[*]:HAS[@MODULE[ModuleReactionWheel]]:FINAL

Having said that, I should handle that ALOT better. Raised #19

Great, I'll try that. Many thanks.

[bobisback]

I did a search and could not find anything about this, but what does the part mean when it says "tested" true or false?

 

Thanks,

Bob

[severedsolo]

18 hours ago, bobisback said:

I did a search and could not find anything about this, but what does the part mean when it says "tested" true or false?

 

Thanks,

Bob

It means whether the part has gone through a "shakedown cruise".

In essence, the bonuses that parts get for being reused don't get applied if the part is just stuck on the pad and recovered without a test.

[bobisback]

So far I have been running a rocket through a couple of generations of tests. I am guessing this has no effect? Also if I have a rocket use it and then reuse it does it have any benefit for testing?

[severedsolo]

5 hours ago, bobisback said:

So far I have been running a rocket through a couple of generations of tests. I am guessing this has no effect? Also if I have a rocket use it and then reuse it does it have any benefit for testing?

I'm going to assume by "a couple of generations" you mean new builds? (not applying parts from the ScrapYard inventory).

Parts will get gradually better with each new generation, by the time you reach Gen 10 there is no need to run tests, as they will have reached the minimum failure level.

Reusing your rocket is the way you are supposed to "test" them. After a successful test (ie, you use the rocket, and then use the same parts from the ScrapYard inventory again after recovery) - the parts will get the bonus for being tested. A part is at it's most reliable on it's second use, after that the reliability will gradually drop off again as it starts to wear out after multiple uses (but usually they have to get to at least 6 uses before they can be considered unreliable)

[baldamundo]

6 hours ago, severedsolo said:

Reusing your rocket is the way you are supposed to "test" them. After a successful test (ie, you use the rocket, and then use the same parts from the ScrapYard inventory again after recovery) - the parts will get the bonus for being tested. A part is at it's most reliable on it's second use, after that the reliability will gradually drop off again as it starts to wear out after multiple uses (but usually they have to get to at least 6 uses before they can be considered unreliable)

How does reusing parts affect the generation, if at all? If I reuse a part 10 times before building a second fresh copy, will it still be only generation two?

Absolutely love the mod by the way. Thought I was just downloading a minor realism/difficulty mod, but actually the amount of strategic depth this adds to a career game is enormous.

[severedsolo]

57 minutes ago, baldamundo said:

How does reusing parts affect the generation, if at all? If I reuse a part 10 times before building a second fresh copy, will it still be only generation two?

Yep, generation specifically refers to new builds of a particular part. While a part will be more reliable once it's completed it's shakedown cruise, it's still the first iteration of that part (with the manufacturing defects baked into it). As your engineers build more of that same component, they will get better at it, and first builds won't be so likely to fail.

Recovering and re-using means that your engineers can retrofit/repair them to work around the manufacturing defects.

Don't get too attached to the current system though, I might, have a play with it.

 

[bobisback]

So does the testing still apply to each generation? Aka if I have a brand new gen two rocket, i should test it before use?

[gamerscircle]

I am curious, is there a way that oh scrap can stop time warp when there is an failure?

[baldamundo]

12 hours ago, severedsolo said:

Yep, generation specifically refers to new builds of a particular part. While a part will be more reliable once it's completed it's shakedown cruise, it's still the first iteration of that part (with the manufacturing defects baked into it). As your engineers build more of that same component, they will get better at it, and first builds won't be so likely to fail.

Recovering and re-using means that your engineers can retrofit/repair them to work around the manufacturing defects.

Don't get too attached to the current system though, I might, have a play with it.

 

So the present system gives a significant disincentive against trying to build reuseable vehicles. Or at least encourages you to extensively test the hardware with disposable versions first.

That may actually be realistic and desirable behaviour, but worth thinking about how it affects the balance.

My instinct is that there should be some added benefit to reusing a part repeatedly, even if it's much lower than building the part repeatedly - you would think that reusing a spaceplane twenty times would give some level of experience/information relative to just launching it once.

Edit: BTW have been playing this alongside Kerbalism and wondered whether there are any prospects for having extended compatibility between the two mods. If Oh Scrap was capable of part failures during background simulation, and if Kerbalism's UI could recognise Oh Scrap failures, it would basically make the Kerbalism part failure system redundant. Opened a thread about it here - https://github.com/Kerbalism/Kerbalism/issues/493

Edited August 18, 2019 by baldamundo

[severedsolo]

16 hours ago, bobisback said:

So does the testing still apply to each generation? Aka if I have a brand new gen two rocket, i should test it before use?

 

5 hours ago, baldamundo said:

So the present system gives a significant disincentive against trying to build reuseable vehicles. Or at least encourages you to extensively test the hardware with disposable versions first.

These are kind of related, so I'll address them together.

Reusable vehicles are worth it in the sense that reusing the vehicle will immediately bump up the reliability from the second flight onwards. As you keep reusing it, the parts will eventually wear out, but that just means that you replace the part that wore out, the next iteration will be a bit more reliable on it's first flight and then much more reliable on it's second flight again. In essence, you get more bang for your buck for reusing, because the improvements between generations are much slower than the improvements gained by testing.

I take your point baldamundo about gaining experience by reusing that can be implemented in future generations, but that's a difficult thing to code.

9 hours ago, gamerscircle said:

I am curious, is there a way that oh scrap can stop time warp when there is an failure?

It already does (or it should do anyway).

[gamerscircle]

4 hours ago, severedsolo said:

It already does (or it should do anyway).

You are correct, there is an option, thanks for the reply

[eightiesboi]

Hey @severedsolo,

Just came back to KSP after a several month hiatus (getting married can throw a wrench into any launch plan!). I was loading mods into my favorite KSP install when I noticed that Oh Scrap doesn't show up in CKAN (yeah, I am lazy), which surprised me as I could see it was updated and I had all the listed dependencies installed. On a hunch, I dug deeper and noted that CKAN has Kerbal Changelog as a dependency (and it is not listed as updated since 1.6.9). Since on the OP for "Oh Scrap" "Kerbal Changelog" isn't listed as a dependency I was going to leave a note in the CKAN thread when I saw a post from you on the KC thread indicating that KC *is* a dependency. If that's correct, I'd like to suggest editing the first post to show it so anyone starting fresh (or masochistic newbies) don't have a hard time figuring out what is missing. If it isn't correct, let me know and I'll bounce over to the CKAN thread to let them know it shouldn't be listed as a dependency. 

I also posted to the KC thread in case other mods are effected by this.

As always, thank you for all the work you have done and continue to do!!!

 

[severedsolo]

11 minutes ago, eightiesboi said:

Since on the OP for "Oh Scrap" "Kerbal Changelog" isn't listed as a dependency I was going to leave a note in the CKAN thread when I saw a post from you on the KC thread indicating that KC *is* a dependency.

It's complicated

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 .

You can read all about it here:

 

Edited August 31, 2019 by severedsolo

[eightiesboi]

3 minutes ago, severedsolo said:

It's complicated

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 .

 

Thank you for the quick response!

I totally understand. I used to eschew CKAN but it makes it so easy to maintain a large mod list. OTOH, I wish other mod authors followed your example. I am in the habit of reading the forum every time CKAN shows a mod has updated, and I am subscribed to about 80 threads (okay, so maybe 40 of them are still alive), but I really like the changelog that also pops up in game.

Obviously, you and I just posted about this, so in theory if anyone else has a problem finding or installing Oh Scrap in CKAN, they should see our posts, install KC by overriding compatibility (or just do it manually), and not bother you. However, based on my observations of the boards for the past few years, might I suggest you add a note on the front page saying exactly what you just said?  Not that I am suggesting that three or four posts from now, someone will post a note asking why the mod doesn't show up--that would never happen here. 

[severedsolo]

31 minutes ago, eightiesboi said:

However, based on my observations of the boards for the past few years, might I suggest you add a note on the front page saying exactly what you just said? 

that's a good idea. Done.

[eightiesboi]

Thank you! 

[The-Doctor]

On 5/21/2017 at 9:49 PM, Daelkyr said:

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

where did you get those logos? Can I have them for flags?