Jump to content

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


severedsolo

Recommended Posts

12 minutes ago, gap said:

How does this 10 seconds / 5 minutes roll-interval rule exactly works (when in the atmosphere)?

By default It's every ten seconds for the first two minutes on the MET timer, after which it will switch to every 5 minutes. 

14 minutes ago, gap said:

Are failure chances checked also for currently inactive parts?

Are physical factors (such as temperature, mechanical stress, ecc) and/or critical steps in the working of some components (i.e engine ignition, stage dropping, chute deployment, etc) also taken into account when calculating overall and part-specific failures? If you did, you could probably apply a more or less constant failure interval...

I think this is really one question. 

Generally speaking, parts which are not actively in use will be excluded from the calculations. So engine's must be firing, rcs must be on etc. With a couple of exceptions: reaction wheels are assumed to always be spinning, unless you have physically turned them off.

Parachutes can also fail if not deployed, but the reasons for this don't really apply any more, so I'll probably change it back in the next update. 

Temperature etc has no bearing, if the part is in use then its a candidate for failure. 

 

Link to comment
Share on other sites

6 minutes ago, severedsolo said:

By default It's every ten seconds for the first two minutes on the MET timer, after which it will switch to every 5 minutes. 

Whether or not you have actually launched the rocket?

 

7 minutes ago, severedsolo said:

Generally speaking, parts which are not actively in use will be excluded from the calculations. So engine's must be firing, rcs must be on etc. With a couple of exceptions: reaction wheels are assumed to always be spinning, unless you have physically turned them off.

Parachutes can also fail if not deployed, but the reasons for this don't really apply any more, so I'll probably change it back in the next update. 

Temperature etc has no bearing, if the part is in use then its a candidate for failure. 

I think ou loud here, so forgive me if say something stupid or if I seem to criticize your work (which, by any means I am not), but I believe that engines are more prone to malfunctions when they are working at full throttle or during/immediately after their ignition; parachutes are more likely to fail in the moment they are deployed and they have to endure a strong deceleration; fuel tanks and aerodynamic parts are more subject to creaking while or after having been exposed to strong forces and high temperatures; gaskets, electric insulators, etc. are more likely to melt down and to cause leakage or short circuits, when they are exposed for a certain amount of time to high temperatures. Some of the failures above might also happen while parts are not active, and then reveal themselves when parts are activated.

How hard would be for you to grab some (very much) simplified physical parameters from the game and applying them to your failure calculations?

Link to comment
Share on other sites

32 minutes ago, gap said:

Whether or not you have actually launched the rocket?

MET doesn't start until the rocket is launched, the mod won't even attempt to start rolling until you launch anyway. 

With regards to your other query - I'm terms of actual difficulty, if the mod was written with that in mind, then it wouldn't be massively difficult. With the way it is now, it would require a massive rewrite, and to be blunt, its not been that long since I ripped the guts out of the mod, and I'm not in any big hurry to do that again ;)

Edited by severedsolo
Link to comment
Share on other sites

2 hours ago, severedsolo said:

MET doesn't start until the rocket is launched, the mod won't even attempt to start rolling until you launch anyway.

Sorry, my bad :)

2 hours ago, severedsolo said:

With regards to your other query - I'm terms of actual difficulty, if the mod was written with that in mind, then it wouldn't be massively difficult. With the way it is now, it would require a massive rewrite, and to be blunt, its not been that long since I ripped the guts out of the mod, and I'm not in any big hurry to do that again ;)

I understand that. If you like the features I have just suggested just place them in your todo list, in case one day you will feel like working on a major revision of OhScrap!, otherwise for what they are worth just... scrap them :lol:

One more note:

On 11/7/2018 at 7:25 AM, severedsolo said:

While a 5% chance of failure might not seem much, if you've got a 50 part vessel, the chances of something failing quickly balloon.  (if the probability of an event occuring is 5%, and there are 50 possible event points, the chance of an event occuring once is 250%) - ie , roll enough dice and chances are, one of them will be a 6.

You are right in stating that, given a sufficient number of eventualities where an event can happen, even the tiniest chance of it occurring at least once becomes substantial, but the way you are calculating this probability is wrong though. In statistic therms, a probability bigger than 100% or 1 (i.e. the certainty that an event will happen), would be a nonsense. The probability of an event occurring at least once is actually calculated as the complement of the event is never occurring. To give you an example, if a rocket is composed of n parts, each with a failure chance of p(1), p(2) ..., p(n-1), p(n), the probability of each part not failing during a failure check will be 1-p(1), 1-p(2), ..., 1-p(n-1), 1-p(n).

From there we can calculate the overall probability of no failure happening at all as:

[1-p(1)] * [1-p(2)] * ...  * [1-p(n-1)] * [1-p(n)]

and subsequently the probability of at least one failure happening during one check will be equal to:

1 - [1-p(1)] * [1-p(2)] * ...  * [1-p(n-1)] * [1-p(n)]

If, as in the example you had chosen, all the parts have the same failure chance, the formula above can be simplified as

1 - (1-p)^n

where p = failure chance and n = number of parts.

Using your numbers (p = 5%, n = 50), this gives a 91% probability that at least one part will fail during a check, which is of course very high.

In the chart below I have plotted the overall chance that one craft will suffer at least one failure during one check, for different p and n values:

2hBaDE1.png

Obviously those are the type of curves we can expect for an exponential function, but for values of p equal or lesser than 0.1% and values of n equal or lesser than 100 the resulting probability could be approximated by a linear function. If you kept the highest (1st generation, 1st use) failure chances of individual parts low enough , the pre-check (where you average those chances and roll the dices to see if any failure will actually happen or not) could be skipped without involving an abnormal increase in the actual failure rates of complex rockets. The advantage of doing that would be obvious since, within reasonable limits, more complex rockets and airplanes being more prone to failures, should be expected.

This has a con though: due to the low number of parts used and to the short duration of missions they are usually involved in, early rockets would have a very low failure rate, which is neither realistic nor fun. Of course we can speculate on the many workarounds we could use to address the issue above; the one I have thought about, is starting with relatively high part failure chances, and dividing those chances by a factor that would reflect the technological advance achieved at any moment. This factor could be calculated as a function of total built parts, total flown and recovered parts and total science points spent in the tech tree. By the time we would start building rockets of some complexity and embarking in missions of some length, the factor would have become high enough that even a space air/craft composed of many mid-rate parts could be launched with some chance of accomplishing its mission.

What do you think? :)

Edited by gap
Link to comment
Share on other sites

@gap - I wasn't expecting anyone to actually go back and look at that post :D - but yes you are right, the maths I used in that particular post was bogus, and was from back in the days when I was still getting a handle on failure rates/probabilities.

The mod is actually balanced using the 1 - (1-p)^n calculation, and not, whatever I did in that post :P 

11 hours ago, gap said:

The advantage of doing that would be obvious since, within reasonable limits, more complex rockets and airplanes being more prone to failures, should be expected.

So, the reason the mod is set up like it is, is for performance purposes. When I played around with having every part regularly check their own failures using PartModules, I found that my CPU could be brought to it's knees relatively quickly. Now yes, I could have probably limited this a bit, but it doesn't change the fact that on a larger vessel (let's say 50 parts again) - that 50 sets of code were running all at the same time. That's more CPU cycles, more garbage. Now, I have a good PC, and a great CPU, and I could easily trigger performance issues.

Then there is the fact that PartModules run in the Editor and the Flight Scene. The extra if(HighLogic.LoadedSceneIsEditor) checks make the code look like a mess. It's messy enough as it is ;)

So this is why the mod does the pre-checks. We have one set of code running, and that's it. Because it's a MonoBehaviour, I can specify that it will only ever run in the Flight Scene without having to introduce a bunch of if statements. More importantly, because there is only ever ONE instance of that code running, I know that the performance impacts are as minimal as they possibly can be.

Edited by severedsolo
Link to comment
Share on other sites

2 hours ago, severedsolo said:

@gap - I wasn't expecting anyone to actually go back and look at that post :D - but yes you are right, the maths I used in that particular post was bogus, and was from back in the days when I was still getting a handle on failure rates/probabilities.

The mod is actually balanced using the 1 - (1-p)^n calculation, and not, whatever I did in that post :P 

Well, talking in my own defense I had warned you that I was going to think out loud lol, and at the beginning I asked you if OhScrap was still based on the considerations contained in that old post, receiving as an answer something that resembled an "essentially yes, with some tweaks" :D

2 hours ago, severedsolo said:

So, the reason the mod is set up like it is, is for performance purposes. When I played around with having every part regularly check their own failures using PartModules, I found that my CPU could be brought to it's knees relatively quickly. Now yes, I could have probably limited this a bit, but it doesn't change the fact that on a larger vessel (let's say 50 parts again) - that 50 sets of code were running all at the same time. That's more CPU cycles, more garbage. Now, I have a good PC, and a great CPU, and I could easily trigger performance issues.

Then there is the fact that PartModules run in the Editor and the Flight Scene. The extra if(HighLogic.LoadedSceneIsEditor) checks make the code look like a mess. It's messy enough as it is ;)

So this is why the mod does the pre-checks. We have one set of code running, and that's it. Because it's a MonoBehaviour, I can specify that it will only ever run in the Flight Scene without having to introduce a bunch of if statements. More importantly, because there is only ever ONE instance of that code running, I know that the performance impacts are as minimal as they possibly can be.

Okay, so if I got you correctly the pre-checks are used for relieving the CPU from having to check all the parts for failures, when (most of the times hopefully) no failure is going to happen anyway. If so, why not testing the overall failure chace for our crafts over the following probability:

1 - [1-p(1)] * [1-p(2)] * ...  * [1-p(n-1)] * [1-p(n)]

rather than this one:

[p(1) + p(2) + ...  + p(n-1) + p(n)] / n  ?

Link to comment
Share on other sites

Quote

Does the parts from mods can fail too ? Or is it only for stock (vanilla) parts ? =)

Thanks !

 

Depends on the part and the mod, but for the most part yes.

Any parts that uses the same modules as stock will fail. Some mods will have issues.  If the mod in question just adds parts without changing game mechanics, than it most likely will work fine. I use this with 150+ other mods , and now have (almost) all of them working correctly.

If you were to install something like airplanes plus, bluedog or restock they will be compatible. Textures and parts (should) be fine. If you install say SSTU which adds parts with tons of switchable variants and options (like internal RCS on parts, or  multiple engine configurations that are still just a single part, etc) you may run into some issues (all your engines failing at once on a multi engine configuration, because there all technically one part for example).

That being said, even if a part cant "Fail", it will still be used to calculate your vessel saftey rating. There will still be a benefit to building it multiple times and testing it, in order to lower the chances of failure across the whole vessel.

Current save is using oh scrap with the following part mods: Airplane plus, grounded, all of the near future mods, restock(+) , the maritime pack,  station parts expansion ,and OPT. I have no issues with failures on any of these.

 

Mods I know that currently arnt supported:

Real chute - Parachutes wont fail. (support may be added in the future)

SSTU - most things wont fail correctly. (probably wont ever work with oh scrap)

Science alert re-alerted - Bug in scrap yard prevents you from recovering root part if this is installed , Severed is aware of this one, and we may see a fix in the future. X-science is a working alternative for the moment.

 

Link to comment
Share on other sites

1 hour ago, NipperySlipples said:

Science alert re-alerted - Bug in scrap yard prevents you from recovering root part if this is installed , Severed is aware of this one, and we may see a fix in the future. X-science is a working alternative for the moment.

Good to know that! I was actually sure I had read somewhere in this thread that [x]Science! has the same problem with Oh Scrap!\ScrapYard as ScienceAlert ReAlerted, but I probably misread that piece of information...

Link to comment
Share on other sites

On 4/12/2019 at 1:46 PM, NipperySlipples said:

Science alert re-alerted - Bug in scrap yard prevents you from recovering root part if this is installed , Severed is aware of this one, and we may see a fix in the future. X-science is a working alternative for the moment. 

Mentioned this in the ScrapYard thread, but I'll mention it here to, as I need to do a post anyway: I looked into this and wasn't able to reproduce it, so I think there is probably another mod causing a conflict with SAA which is then feeding through to ScrapYard

While I'm on the subject of ScrapYard - don't look too closely at safety ratings/generations etc when using the new version of ScrapYard and running a KRASH simulation. The change I made to fix the ScrapYard bug broke OhScrap! a bit - but it's only during simulations, and purely cosmetic. I will be pushing a fix shortly*

*within the next week probably.

Link to comment
Share on other sites

On 4/12/2019 at 8:46 AM, NipperySlipples said:

Science alert re-alerted - Bug in scrap yard prevents you from recovering root part if this is installed , Severed is aware of this one, and we may see a fix in the future. X-science is a working alternative for the moment.

 

Not 100% positive, but I thought this was brought to LGG's attention and he fixed it in Science Alert. (But maybe he only fixed it for the KCT recovery bug.)

Link to comment
Share on other sites

39 minutes ago, chateaudav said:

I read in this topic that "Oh scrap" is now compatible with FAR parachutes but my chutes never fail.. why ?

Well firstly, it's only been compatible with FAR for about two weeks, so depending on your definition of "never" that may be why.

Secondly, there is every chance that your parachutes have not actually attempted to fail. For that one I'd need to see some logs. (It's also entirely possible that it's not working at all, but I assume that Mr Slipples would have checked that before sending me a PR).

Link to comment
Share on other sites

1 hour ago, chateaudav said:

I read in this topic that "Oh scrap" is now compatible with FAR parachutes but my chutes never fail.. why ?

Ive just tested again and they are still working on my install. Here's a screenshot. Perhaps you have parachute failures turned off in the difficulty settings? Otherwise you may just be getting lucky, or perhaps have very high generation/safe parachutes?

That being said, If you truly think its not working you can upload the save file and log somewhere for me and I will look into it.

 

Link to comment
Share on other sites

34 minutes ago, chateaudav said:

That's for sure a first generation faillure ^^ Sorry !!

Here a unique link, the 4 files in one .zip, and i have tested the link this time.

http://s000.tinyupload.com/index.php?file_id=90337576395833062819

OhScrap never attempted a failure in that log.

What we need you to do is play the game as you normally would for a while - then upload the log.

BEFORE YOU START THE GAME - you can also provide your SeveredSolo/OhScrap/Logs folder - this will have the last 24 hours worth of failures so I can see if things are working as they should.

Link to comment
Share on other sites

On 4/14/2019 at 7:42 AM, severedsolo said:

Mentioned this in the ScrapYard thread, but I'll mention it here to, as I need to do a post anyway: I looked into this and wasn't able to reproduce it, so I think there is probably another mod causing a conflict with SAA which is then feeding through to ScrapYard

While I'm on the subject of ScrapYard - don't look too closely at safety ratings/generations etc when using the new version of ScrapYard and running a KRASH simulation. The change I made to fix the ScrapYard bug broke OhScrap! a bit - but it's only during simulations, and purely cosmetic. I will be pushing a fix shortly*

*within the next week probably.

1) I think that either KSP 1.7 coming out or some unrelated update to one of KCT/SY/SAA managed to fix the problem, since the same mod set that was causing issues for me before is working fine now.

2)With regard to the new version of SY/KRASH, i've been noticing that the Generation on my parts have not been ticking up at all since about the time that last update came through. All my engines/new solar panels/various small bits for my satellites are still stuck at Gen 1 or 2 despite being used about a dozen+ times in various configurations. I do have KRASH installed and have been noticing an NRE pop up whenever i finish building something. Sample here with just a simple commsatt:

[LOG 09:28:00.136] [ScrapYard] Adding build (nodes)
[LOG 09:28:00.136] [ScrapYard] probeCoreHex.v2 has been used 17/13/4 (T/N/I) times.
[LOG 09:28:00.136] [ScrapYard] sasModule has been used 19/17/2 (T/N/I) times.
[LOG 09:28:00.136] [ScrapYard] rcsTankMini has been used 15/15/0 (T/N/I) times.
[LOG 09:28:00.136] [ScrapYard] rcsTankMini has been used 16/16/0 (T/N/I) times.
[LOG 09:28:00.136] [ScrapYard] orbital-engine-0625 has been used 8/8/0 (T/N/I) times.
[LOG 09:28:00.136] [ScrapYard] SurfAntenna has been used 29/22/7 (T/N/I) times.
[LOG 09:28:00.136] [ScrapYard] HighGainAntenna5 has been used 7/7/0 (T/N/I) times.
[LOG 09:28:00.136] [ScrapYard] solarPanels3 has been used 29/27/2 (T/N/I) times.
[LOG 09:28:00.137] [ScrapYard] solarPanels3 has been used 30/28/2 (T/N/I) times.
[LOG 09:28:00.137] [ScrapYard] batteryBankMini has been used 21/18/3 (T/N/I) times.
[LOG 09:28:00.137] [ScrapYard] Separator.0 has been used 7/7/0 (T/N/I) times.
[EXC 09:28:00.138] NullReferenceException: Object reference not set to an instance of an object
    KRASH.APIManager+SimAPI.simulationActive ()
    System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture)
    Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
    System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture)
    System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters)
    ScrapYard.KRASHWrapper.simulationActive ()
    ScrapYard.PartTracker.AddBuild (IEnumerable`1 partNodes)
    ScrapYard.APIManager.RecordBuild_Nodes (IEnumerable`1 parts)
    System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture)
    Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
    System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture)
    System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters)
    KerbalConstructionTime.ScrapYardWrapper.invokeMethod (System.String methodName, System.Object[] parameters)
    KerbalConstructionTime.ScrapYardWrapper.RecordBuild (IEnumerable`1 parts)
    KerbalConstructionTime.KCT_Utilities.MoveVesselToWarehouse (Int32 ListIdentifier, Int32 index, KerbalConstructionTime.KCT_KSC KSC)
    KerbalConstructionTime.KCT_Utilities.ProgressBuildTime ()
    KerbalConstructionTime.KerbalConstructionTime.FixedUpdate ()
    UnityEngine.Debug:LogException(Exception)
    KerbalConstructionTime.KerbalConstructionTime:FixedUpdate()



For reference, though i don't know what those T/N/I numbers mean, that particular engine type as been launched  4 times and is still Gen 1, the same thing for the fuel tanks/HG-5, and the Solar Panels/batteries are stuck despite having been used in partically everything sent to orbit. The failure rates defintely feel like they're low gen parts too.
Link to comment
Share on other sites

1 hour ago, ThePhoenixSol said:

can a part fail if its not on the focused vessel? so say, my relay sats. can i just be launching a sat, and all the sudden a relay isnt working anymore?

Nope. Only active vessel.

Link to comment
Share on other sites

On 4/18/2019 at 11:22 AM, ussdefiant said:

1) I think that either KSP 1.7 coming out or some unrelated update to one of KCT/SY/SAA managed to fix the problem, since the same mod set that was causing issues for me before is working fine now.

2)With regard to the new version of SY/KRASH, i've been noticing that the Generation on my parts have not been ticking up at all since about the time that last update came through. All my engines/new solar panels/various small bits for my satellites are still stuck at Gen 1 or 2 despite being used about a dozen+ times in various configurations. I do have KRASH installed and have been noticing an NRE pop up whenever i finish building something. Sample here with just a simple commsatt:

 

I'm getting the same. All my parts are not advancing in generation numbers. Their stuck at Gen 1, so my launches are getting a lot of failures. Nasty problem if its a booster rocket, which can really screw up a launch.

Scrap yard is updated for KSP v1.7.0, but Module manager isn't. I imagine once Oh Scrap! is updated to KSP v1.7.0, these problems will vanish.

Edited by GJNelson
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...