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

[garwel]

Can you add RadiationShielding resource from Kerbal Health as non-leakable?

PS: Looking at your mod with interest for my own playthrough as I like some reasonable and realistic challenge. But part failures seem to be a very tricky thing to simulate: on one hand, we have all these failed launches, Apollo-13-like disasters, etc. On the other hand, we have Voyagers and other interplanetary probes that have been operating for decades without catastrophic malfunctions. So I wonder how a mod like this can be balanced to give you a challenge while not making long missions impossible.

Edited November 14, 2017 by garwel

[severedsolo]

7 hours ago, jlcarneiro said:

This is getting better and better!

What about dropping out of warp and playing a sound when a failure occurs? Kind of what [X] Science! does upon entering new biomes...

Yeah I'm pretty happy with it now, I feel like it's getting close to being release ready.

I'll add the dropping out of warp as a difficulty option, then I need to stop the window from jumping in your face every time you switch to the flight scene and go on Eva (it's driving me insane) and exclude Eva herbals from the gui, and I think it will basically be ready.

[severedsolo]

4 hours ago, garwel said:

Can you add RadiationShielding resource from Kerbal Health as non-leakable?

Sure, for now you can add it to DontLeak.cfg - the format should be pretty self explanatory

[garwel]

46 minutes ago, severedsolo said:

Sure, for now you can add it to DontLeak.cfg - the format should be pretty self explanatory

Can I use an MM patch for that? Something like this:

BLACKLISTED:NEEDS[UPFM]
{
	name = RadiationShielding
}

 

[severedsolo]

3 hours ago, garwel said:

Can I use an MM patch for that? Something like this:

BLACKLISTED:NEEDS[UPFM]
{
	name = RadiationShielding
}

 

It's not currently doable via MM it reads the file directly, but that's on the list for the full release.

Edit: OK apparently it's actually easier to read the GameDatabase than it is to read the file directly, so I've turned this on in build 32.

Format is as follows (this will change when I officially change the name of the mod):

OHSCRAP_RESOURCE_BLACKLIST:NEEDS[UntitledFailures]
{
	name = RadiationShielding
}

 

Edited November 14, 2017 by severedsolo

[severedsolo]

New beta with lots of goodies:

UPFM Beta 12 (0.12) released!

• Removed secondary failure check
• Fixed failures always happening at maxTimeToFailure instead of randomly
• Resource Blacklist is now editable via MM - see this post for details on format required.
• Solar panels can now have sun tracking failures.
• Fixed issue where fixed panels would report failures even though they can't be deployed or retracted (thanks to forum user @New Horizons for showing me how to fix this.)
• MASSIVELY reduced logging for release versions. It will now only log when something interesting happens.
• EVA kerbals will no longer prompt warnings about the safety threshold.
• GUI will no longer open by itself in the flight scene.
• RCS Failures now actually work.
• Parachutes will now warn you of a failure before you try to deploy them.
• Fuel Line Leaks will warn you before the explosion happens. If the engine is shut down quickly enough the explosion won't happen.
• Fuel Line Leaks will now actually leak liquid fuel (very slowly). This will happen regardless of whether the engine is throttled up or not.
• Added option to stop timewarp when failure happens (defaults to on)

 

[New Horizons]

I am testing the new version. 

What are the consequences of an RCS failure?  don't see failure rates at RCS parts so far.

[severedsolo]

27 minutes ago, New Horizons said:

What are the consequences of an RCS failure?  don't see failure rates at RCS parts so far.

An RCS Failure will just stop the RCS block from working (it won't produce any thrust from that block at all).

[notJebKerman]

It seems like failure rates have gone up again with the last update again. 12 minutes into the flight and I've had an engine failure, a short circuit on the main battery and a parachute failure.

[severedsolo]

1 hour ago, notJebKerman said:

It seems like failure rates have gone up again with the last update again. 12 minutes into the flight and I've had an engine failure, a short circuit on the main battery and a parachute failure.

Hmm, I've been playtesting this for nearly a week, and while the failure rates are slightly higher (well, actually they just aren't being artificially limited any longer) - I've not noticed it being that bad. Can you provide a log? (and a save actually too please)

Edited November 20, 2017 by severedsolo

[severedsolo]

Ok wasn't planning to do a new release this quickly but I found a nasty bug while working on the too high failure rate problems that @NotJeb was talking about - this new build should help with the failure rates, and fix the bug.

UPFM Beta 13 (0.13) released

• Rewrote Random Number Generator to make it less random - see below for details
• Fixed Solar Panel Failures spamming NextDouble if the panel wasn't deployed.

So, generating decent random numbers has always been a problem for UPFM - while the numbers it was generating were random, the human brain is not good at interpreting randomness.

To give an example: Take a failure rate of 10% per part. To the human brain, that means "oh it probably won't fail at all" - but of course, a vessel has many parts. On a 20 part vessel, statistically, 2 of those parts are going to fail. Thats basically a botched launch, every time. That's not fun.

So, what i used to do, was when we got a random failure, I'd roll the dice again, and if that succeeded, then I would allow the part to fail. I never really liked this, because I felt like I was artificially limiting your failures, when really the problem was that my tiny human brain can't comprehend true randomness.

So, what can we do about it.

Well I found a great tip here - if the human brain doesn't like randomness, the answer is: make it less random.

So I placed 100 entries between 0.01 and 0.99 into a "shuffle bag" - incrementing each value by 0.01 each time (0.02, 0.03, etc) then when we need a random number, we draw one of those at random, and remove it from the "bag". While this is not "truly" random, the results are more in line with what you would expect.

While this helped, the failures were still coming slightly more often than I would like them to. So whats better than one shuffle bag? 3 shuffle bags obviously. So now, UPFM will pick a bag at random, then select an entry at random from that bag and remove it. The results are, I think, very positive.

While you still TECHNICALLY have a 1/10 chance of that 10% failure happening, the actual results are much more in line with what we would perceive as "right". At the end of the day, that's what its about. It can be as "accurate" as you like, but if it's not fun, whats the point.

The great thing about this system, is that if you are having a ran of "bad luck" - the low entries are removed from the bag, so you will get more higher rolls (and less failures) until the bag refills itself, and if I feel the results are still skewed, I can just add/remove a shuffle bag as needed.

Anyway, apologies for the long post: please feedback on how you feel the new system works.

Edited November 21, 2017 by severedsolo

[New Horizons]

Even with V0.13 RCS thrusters do not show a Failure Rate, other engines and parts do work. How can I suppoprt you to find my issue?

[severedsolo]

8 hours ago, New Horizons said:

Even with V0.13 RCS thrusters do not show a Failure Rate, other engines and parts do work. How can I suppoprt you to find my issue?

Ok, lets check the obvious first - Go into GameData/UntitledFailures/MM Patches and check you have a file called RCSFailures.cfg - if you don't, install it from the release zip again.

Assuming that you do have that, can you please provide your output_log or player.log depending on your OS

 

Edit: Nevermind I'm seeing it too. I've obviously broken something. Will investigate later

Edited November 22, 2017 by severedsolo

[severedsolo]

19 hours ago, New Horizons said:

Even with V0.13 RCS thrusters do not show a Failure Rate, other engines and parts do work. How can I suppoprt you to find my issue?

Derp. I messed up the patch, noticed and fixed it in my version but never committed the changes to Github.

Latest build should fix it as well as tweaking the randomiser a little bit as it wasn't as great as I first thought in the release version.

[New Horizons]

Hey super. Now I experienced my first RCS engine failing. Thank you very much.

May I suggest an improvement of the GUI statements for already happened failures?

When a part already malfunctioned, it still shows "Chance of xx Failure: yy %" (a little correction here: units should be seperated from numbers by a blank)
Shouldn't that place used for something like: "Failed due to kind of failure"?

In the UPFM window it would be nice to see, what failure occured. Especially for solar panels with different kind of malfunctions this would give more information, experienced sun tracking and retracting error already ;-) Can these failure hit the same part?

Up to now, I did not see a failed RCS thruster glowing red :-(

 

 

 

[New Horizons]

I am thinking about procedural parts support.

As I can understand now resources in there a set a little bit deeper in modules. Maybe there is a way to modify

    MODULE
    {
        name = TankContentSwitcher

        TANK_TYPE_OPTION 
        {
            name = Mixed | LiquidFuel | Oxidizer | RCS //all 4 possible

            RESOURCE 
            {
                name = Oxidizer | LiquidFuel //all 2 possible

             }

       }

    }

 

With Real Fuels it becomes even more interesting.
This happens:

@PART[proceduralTankLiquid]:AFTER[modularFuelTanks]
{
    !MODULE[TankContentSwitcher] { }
    MODULE
    {
        name = ModuleFuelTanks
        type = Default
        volume = 211
        tankVolumeConversion = 200
    }
}

@PART[proceduralTankRCS]:AFTER[modularFuelTanks]
{
    !MODULE[TankContentSwitcher] { }
    MODULE
    {
        name = ModuleFuelTanks
        type = RCS
        volume = 106
        tankVolumeConversion = 200
    }
}

@PART[proceduralTankXenon]:AFTER[modularFuelTanks]
{
    !MODULE[TankContentSwitcher] { }
    MODULE
    {
        name = ModuleFuelTanks
        type = Xenon
        volume = 792
        tankVolumeConversion = 10000
    }
}
@PART[proceduralConeLiquid]:AFTER[modularFuelTanks]
{
    !MODULE[TankContentSwitcher] { }
    MODULE
    {
        name = ModuleFuelTanks
        type = Default
        volume = 77
        tankVolumeConversion = 200
    }
}

 

What do you think about this thoughts?

[notJebKerman]

Question: If a part has a switchable engine, will the failure affect both engine modules or only the active one (unless it causes an explosion of the whole part)?

[severedsolo]

10 hours ago, New Horizons said:

I am thinking about procedural parts support.

As I can understand now resources in there a set a little bit deeper in modules. Maybe there is a way to modify

Did you mean to post that to this thread? UPFM shouldn't care if you are using procedural parts, when it comes to leak, it will query the part for any available resources and then pick one at random.

 

6 hours ago, notJebKerman said:

Question: If a part has a switchable engine, will the failure affect both engine modules or only the active one (unless it causes an explosion of the whole part)?

Sorry I don't really understand this one either. I wasn't aware of any mods that had multiple engine modules. If you can give me an example I will look into it, but I would expect in that scenario for it to not work properly, as it just grabs ModuleEngines - it doesn't check whether there is more than one.

[New Horizons]

15 hours ago, severedsolo said:

Did you mean to post that to this thread? UPFM shouldn't care if you are using procedural parts

Procedural tanks don't get a failure module - in VAB and in flight they do not have a failure rate. I suspect that their resources are too deep within modules.

Supplemental: I figured it out ;-)
Now even my procedural real fuels fueled tanks can suffer a leackage

For this here is the extension for "TankFailureModule.cfg"

//Procedural Parts only - actually not needed, when using Real Fuels
@PART[*]:HAS[@MODULE[TankContentSwitcher]]
{
	MODULE
	{
		name = TankFailureModule
		baseChanceOfFailure = 0.008
		expectedLifetime = 50
	}
}

//Using Real Fuels and Procedural Parts
@PART[*]:HAS[@MODULE[ModuleFuelTanks]]
{
	MODULE
	{
		name = TankFailureModule
		baseChanceOfFailure = 0.008
		expectedLifetime = 50
	}
}

 

 

 

 

Edited November 23, 2017 by New Horizons

[severedsolo]

Awesome, I'll add that to the next release with your permission

[New Horizons]

7 hours ago, severedsolo said:

Awesome, I'll add that to the next release with your permission

I am looking forward to.

[TailDragger]

@severedsolo This is exactly the type of mod I've been hoping for! Thank you!!!

Now, I have a couple things... 1) When I replace a part in the editor with an identical part, they often come up with different failure probabilities (for new parts only) is this a bug, or intentional? If its intentional, it seems a little odd.

2) do you have any plans / the ability to make science experiments fail?  It would be really disappointing (but realistic) to get your fancy probe all the way to Jool, only to have the Science, Jr.'s doors get jammed 

Thanks, again! This mod rocks!

 

[JoshuaRaven]

I have three mini battery packs attached to my ship. I've flown it once, and recovered it. Now it says that two of the three have a high chance of failure (25+%).

I don't really understand some mechanics here:

• Why do only two of the three have a high chance of failure? (the third battery is at 15%)
• I thought the idea was that flown parts become more flight-proven and thus less likely to fail, yet for those two batteries, the failure chance went up compared to the maiden flight

[severedsolo]

On 30/11/2017 at 2:16 AM, TailDragger said:

Now, I have a couple things... 1) When I replace a part in the editor with an identical part, they often come up with different failure probabilities (for new parts only) is this a bug, or intentional? If its intentional, it seems a little odd.

Intentional, but may be exasperated by @JoshuaRaven's issue (and better explanation below)

34 minutes ago, JoshuaRaven said:

• Why do only two of the three have a high chance of failure? (the third battery is at 15%)
• I thought the idea was that flown parts become more flight-proven and thus less likely to fail, yet for those two batteries, the failure chance went up compared to the maiden flight

Individual parts are supposed to show a slight deviation in failure rates, to simulate manufacturing defects etc, but it's not supposed to be THAT bad.

It sounds like those parts returned REALLY bad results for expectedLifetime - which may be a bug in the new randomiser I wrote, or (more likely) I need to do some sense checking.

So, to eliminate the first - I assume you are using the release version - can you try the dev version (here) and see if it helps. It won't help the existing parts (their failure rates are already set), but may with new ones. In the meantime I will do some tweaking of the values that expectedLifetime can return.

[severedsolo]

UPFM Beta 14 (0.14 released)

• Fixed RCS failures not working
• Fixed situation where 2nd flights could be more likely to fail than 1st flights.
• Failure rates for the same types of part will no longer be allowed to vary by more than 10% (assuming all other things are equal)
• reduced expectedLifetime for all parts, but also changed the way it's calculated, so they will fail less while within their lifetime, but won't last as many launches as they did before.
• Parts will now never be more likely to fail than the safety threshold allows.