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

[strudo76]

On 5/27/2018 at 5:51 PM, severedsolo said:

• 1) Massively reduce the failure rates (by at least a factor of 3, possibly as much as a factor of 10)

Possibly 

Spoiler

Edited June 4, 2018 by strudo76
spoiler tagged the image

[DarkSlimus]

Hi,

 

First thanks for your mod who improve the game experience with immersive reality and thanks to work on his rebalance, cause it's very hard each launch ...

 

so here are my own propositions to improve the realism

1) Massively reduce the failure rates (by at least a factor of 3, possibly as much as a factor of 10)

Yes, a factor of 3 ( 7% ) or 4 (5%) must be a good thing but keep in mind than actually the base factor is 0.2 ( ie 20% ) so for a vessel of 30 parts the base chance at each launch is approximately   6 parts failure as base factor !!! last launch vessel 29 parts of gen 1 and gen  2 recovered parts => 7 failures

2) To balance the above, introduce a "recurring failure check" chance (ie it won't just happen on first load) - I'm thinking somewhere in the region of every 2-5 (real-time) minutes

I think you must do more on this point : Parts have not the same complexity, parts are not the sames. Some parts fail at usage and it's not realist to see them fail not activated.  I think you must divide parts in sub groups :

a. Usage parts.

when they are activated they can fails, but you can't know they failed before use them . this parts are used once and they not must be involved in the failure check, but checked at each usage

parachutes for example 

b. Mechanical parts.

this parts are robust they can fail but not very often.. and you must perhaps introduce a new failure mechanic for this parts : something like staged failure (hard to explain that with my lack of english but I will try).

A engine is a mechanical part. At  activation normal chance to have a failure (5-7% ? ), to simulate the failure in the launch phase or post activation the failure can be delayed in the first 10 seconds of activation).

After activation chance of failure go down drastically so here you integrate a prefailure stage (pfs)  with a chance of 3%. each 1-2 minutes of usage you do a prefailure test and if it is negative use this formula pfs=pfs+pfs/3 to increase the pfs for next test. If the test is positive, add a random number between 1 and half the actual % chance of failure (ie. chance of failure 20% add randomly something between 1 and 10%) and make a test for failure, positive = failure, if the test is negative pfs=pfs/3

An engineer must be able to predetermine a big failure chance because he heard some weird noise or things like that. more he gain experience earlier he know something is wrong. a base engineer must know a problem at something around 40% each star reduce by 5% so: 

0 star : 40%

1 star : 35%

2 stars : 30 %

3 star : 25 %

4 star : 20 %

5 star : new aptitude, the percentage chance of failure is visible on the part (cause a skilled engineer can know a problem exist and understand his importance)

A pilot must be able to determine the same things with navigational parts (motors, directional parts, etc ... at a higger % of failure chance ( cause he his not an engineer but he is a pilot and he can understand something is wrong at usage) perhaps something who start at 55% with -5% each star but no 5 stars aptitude like the engineer so a 0 star pilot 55% a 5 star pilot 30% like a 2 stars ingeneer

The advantage to introduce the prefailure stage is the possibility to abort the mission before things go too bad, it give a strategic improvement to the mod.

c. electronic parts

This parts have a big fail chance at activation cause court circuit. something like the actual one. But after activated they must be tested really less often, perhaps each game month with the prefailure stage.

this parts can't be detected like the mechanical one or with a special electronic part introduced by the mod

if I say month test for electronic parts it's because I think unloaded vessel must be tested too, by usage parts have problems it's like that things works in reality

And parts must be tested when they are in use, not in a global pretest (if all of that is possible to do)

3, 4 & 5

Completely agree with that

 

[severedsolo]

17 hours ago, DarkSlimus said:

Yes, a factor of 3 ( 7% ) or 4 (5%) must be a good thing but keep in mind than actually the base factor is 0.2 ( ie 20% ) so for a vessel of 30 parts the base chance at each launch is approximately   6 parts failure as base factor !!! last launch vessel 29 parts of gen 1 and gen  2 recovered parts => 7 failures

Yup this is exactly the problem. Up to now I've been looking at it as a "per part" problem, but a KSP vessel is made up of many parts. While a 10% failure rate seems quite reasonable for one part, when you've got 30 of them on your vessel the chances of at least one of them failing is actually quite high.

17 hours ago, DarkSlimus said:

Parts have not the same complexity, parts are not the sames. Some parts fail at usage and it's not realist to see them fail not activated.

Absolutely. When I first made the changes I suggested, I quickly realised that having a reaction wheel fail after a few hours of sitting there not being used is stupid. A part will only fail if it's "in use". For reaction wheels this means generating torque, for RCS you need to actually have RCS activated, control surfaces need to be in the atmosphere, etc. RCS in particular is a huge problem. I don't know about you, but when I use RCS I've usually got at least 8 of them on my craft. That's why RCS seems to fail every 10 minutes or so.

If the "I'm being used" condition is not true, the failure check will always return "passed". Fuel tanks (and possibly batteries) can always be considered to be "in use" but other parts, not so much. On the other hand (as it's set up now), you get less "usage time" from a part that isn't always in use. Initial testing (using the Kerbal X as a baseline) suggests that with the way I have it set up right now, a bunch of Gen 1 fuel tanks can expect a failure (roughly) every 6 hours, and parts that aren't always in use after about 30 minutes of use. - To be clear, that's 6 hours/30 minutes for ONE failure to occur, the actual MTBF of each individual part is actually a fair bit higher.

17 hours ago, DarkSlimus said:

when they are activated they can fails, but you can't know they failed before use them . this parts are used once and they not must be involved in the failure check, but checked at each usage

Yup yup yup. SRBs already fall into this category anyway, it wouldn't be too difficult to extend it to parachutes too - although I'm not 100% sure on this, I always found it annoying to have a chute fail when you activate it. I know it's realistic, but it really can upset a perfect mission to know that you are screwed at that point. On the other hand, as failures aren't happening every 5 minutes any longer, maybe this won't be so bad. Balance testing needed I think

TLDR: This is where I am right now.

• Failure rates have been reduced by a factor of 10ish (with variations on this depending on the type of part it is).
• While all parts are still checked for failure at launch, if a part is not in use it won't fail.
• Parts will recheck themselves for failures approximately once an hour (kerbal) if they are "always in use" (fuel tanks etc) or every 5 seconds if they can only fail while in use (reaction wheels, RCS, control surfaces etc).
• Failures are now instant, rather than occuring at a random time in the next 30 minutes.

 

Edited June 5, 2018 by severedsolo

[DarkSlimus]

10 minutes ago, severedsolo said:

I don't know about you, but when I use RCS I've usually got at least 8 of them on my craft. That's why RCS seems to fail every 10 minutes or so.

I'm in the same proportions . More you have the same parts more you know one will fail, fatally. On the other hand more same parts let you a way to find a way to go out

 

12 minutes ago, severedsolo said:

although I'm not 100% sure on this, I always found it annoying to have a chute fail when you activate it. I know it's realistic, but it really can upset a perfect mission to know that you are screwed at that point.

to give you a feedback on my own experience:

I'm new in the game, don't left kerbin at this point, but want a realistic game play so install your mod after my first game  ... and restart career  cause actually I'm always at a point I must.

So send my second launch to achieve the orbit contract. Send a pilot in orbit, do some science experiment, my only one parachute fail in orbit  can't go back to Kerbin. Not a matter, I make a rescue mission and try to do a rescue mission. Send my second pilot with two pods and try to do a rendez vous, never do that before, don't really have the technologies for that but I will try. put my second pilot in orbit try to cross the orbits, my engine fail ... So my two pilots are orbiting for eternity around Kerbin ... I restart a career. I can't take the decision to cut off the chute failure in game setting, I just reduce the value in the MM patch.

 

28 minutes ago, severedsolo said:

TLDR: This is where I am right now.

• Failure rates have been reduced by a factor of 10ish (with variations on this depending on the type of part it is).
• While all parts are still checked for failure at launch, if a part is not in use it won't fail.
• Parts will recheck themselves for failures once a day (kerbal) if they are "always in use" (fuel tanks etc) or every 5 seconds if they can only fail while in use (reaction wheels, RCS, control surfaces etc).
• Failures are now instant, rather than occuring at a random time in the next 30 minutes.

I think its a good improvement at this time.

what do you think about my prefailure stage concept? hard to implement ? I really think it can be a good improvement of your mod, but you are the creator so you take the decision

[severedsolo]

4 hours ago, DarkSlimus said:

 

what do you think about my prefailure stage concept? hard to implement ?

It's a good idea, and definitely possible, dang it does something similar, but right now I need to get what I already have working nicely.

hopefully I'll have a prerelease ready today or tomorrow

[DarkSlimus]

@severedsolo

Cool, we can wait, let's test the new release 

Another thing, if you provide me a localization file I can do the french version for you if you're interested.

[BlueTiger12]

@severedsolo

If you have the time and are up to it, may i ask you on your thoughts to the other ideas, too?

I would be very interested in reading your opinion on them.

[severedsolo]

8 hours ago, BlueTiger12 said:

@severedsolo

If you have the time and are up to it, may i ask you on your thoughts to the other ideas, too?

I would be very interested in reading your opinion on them.

Sure

Quote

1. Let failures happen on vessels, regardless if they are loaded or on rails

Aside from the fact that it would mean literally rewriting the mod from scratch (because Part Modules aren't active when the vessel is not active) - I just don't find the idea fun. I personally don't want to have to worry about what my station out at Duna is doing while I'm not watching it.

On 5/28/2018 at 11:15 PM, BlueTiger12 said:

2. Dices for failures like engine ignitions, solar panel deploy mechanism, antenna deploy mechanisms or parachutes are rolled on activation, as these are instant failures.
This is also the way it is currently implemented, i think.

3. Failures for things like batteries, fuel tanks and so on are rolled on launch.

4. Failures for engine overheating and so on are also rolled at engine ignition.

5. If a failure if point 3 or 4 is determined, it will occur somewhere between now and the part's expected lifetime.

6. If no failure is determined, the dices are then again rolled when the expected liftetime is reached. Then if a failure is determined, it will happen between now and a part of the original expected lifetim (1/3 for example)

7. At the end of the 2nd expected lifetime, dices are rolled again. The time is again 1/3 of the previous lifetime (which was already 1/3 of the original lifetime).

8. This goes on every time the lifetime ends. Obviously there should be a cap to prevent the dices from rolling to often and making a failure unavoidable. Maybe a minimum time of 30 ingame minutes.

This is pretty close to how it works right now. The only difference is that the re-rolls only happen when you repair a part. It's pretty obvious that this method is not working (while I could go ahead and tweak the failure rates until it does, I like the new system much better. More on that later.)

On 5/28/2018 at 11:15 PM, BlueTiger12 said:

Also the expected lifetime should increase with the failure rate decreasing. So the more often a part is build, the longer it's expected lifetime will be.

New system will implement this indirectly, in that the "shelf life" of a part will be higher the more it's built - while Safety Rating 1 parts are still pretty fragile (but not as bad as they were) - Safety Rating 5 parts will almost never fail (there is still a small chance they can).

On 5/28/2018 at 11:15 PM, BlueTiger12 said:

Lifetime for engines should be pretty short then, but the lifetime should only be counted while they are running (Failure described at point 4).

Again, indirectly implemented. Parts will only fail while in use. Parts that are not in use for massive amounts of time will be checked for failures (where applicable) more often.

On 5/28/2018 at 11:15 PM, BlueTiger12 said:

I also agree with @Gordon Dry that it would make sence that a part being build more often should have an impact on all other older parts of that category, i.e. a highly reliable Poodle should have made a LV-909 a little bit more reliable, too. But i don't know if that is just too dificult or complex to implement. 

I've made my thoughts pretty clear on this (sorry Gordon) - In short - this is a KCT companion mod. KCT doesn't build new Poodles quicker because you've built Terriers before (however proficient you are at them) - only when you've built a few Poodles. - I do agree though that this would probably be needed if failures stayed at the ridiculous level they are now.

 

 

[Starwaster]

2 hours ago, severedsolo said:

Aside from the fact that it would mean literally rewriting the mod from scratch (because Part Modules aren't active when the vessel is not active) - I just don't find the idea fun. I personally don't want to have to worry about what my station out at Duna is doing while I'm not watching it.

Not to mention the fact that having things fail isn't going to be meaningful when the player isn't there to interact with the vessel

[severedsolo]

Pre-Release Time!

https://github.com/severedsolo/OhScrap/releases/tag/1.3.6b1

• Fixed bug where stats wouldn't get refreshed when applying inventory manually.

Failure Model Overhaul

• Reduced overall failure rates by a factor of 10 to 20
• Parts will now check for failures regularly, instead of only when the vessel is first loaded.
• Non-Engineer kerbals will now only have a 50% of repairing a part.
• Engineers will gain a bonus to repairs which scales with experience level.
• Removed "cascade failures"
• Parts can only fail while being actively used (Fuel tanks and batteries are considered to always be in use).
• Probably a bunch of other stuff I've forgotten about.

NOTE:

If you are going to use this, I want some serious feedback. Even if it's "seems to be all perfectly balanced ok". Nobody feeds back, you don't get it fixed.

What I want from you:

1) Obviously report bugs.

2) What I'm really looking for though is balance feedback. At what point did you get failures (whats your MET)? Did that seem fair? What was the safety rating of the part when it failed? How long were you going between failures.

Here's one I wrote for myself while testing:

Quote

Craft: Kerbal X - ALL GEN 1 1st LAUNCH

Test 1:
Control Surface Failure - T+20S
Parachute Failure: T+3d55m
CRITICAL FAILURE

Test 2:
Oxidiser Leak: On Launch.
Reaction Wheel Failure: T+5m
CRITICAL FAILURE

Test 3:
Control Surface Failure: T+2m
MISSION SUCCESS.

3) Performance information - particularly from people who suffer from GC issues or have Potatoes. It can be a little performance intensive, and I have a good PC. How does it run? Any noticeable slowdown/GC stutter (particularly at high warp)

Edited June 6, 2018 by severedsolo

[BlueTiger12]

47 minutes ago, Starwaster said:

Not to mention the fact that having things fail isn't going to be meaningful when the player isn't there to interact with the vessel

My thought was that satellites would die over time and therefore need to be replaced at some time, as i usually don't ever switch back to my comsats, failures would not happen and therefore they would not wear out.

@severedsolo Thanks for your opinion on my suggestions :-)
I am very much looking forward to testing your pre-release but unfortunatelly i don't have much spare time during the next days :-/

 

 

[Beetlecat]

1 hour ago, Starwaster said:

Not to mention the fact that having things fail isn't going to be meaningful when the player isn't there to interact with the vessel

 

18 minutes ago, BlueTiger12 said:

My thought was that satellites would die over time and therefore need to be replaced at some time, as i usually don't ever switch back to my comsats, failures would not happen and therefore they would not wear out.

@severedsolo Thanks for your opinion on my suggestions :-)
I am very much looking forward to testing your pre-release but unfortunatelly i don't have much spare time during the next days :-/

 

 

This is the aspect that "remote" failure would be good for -- creating a *reason* to go visit a long-serving mining station, or relay satellite that's suddenly developed a dodgy solar collector or thruster failure. I totally get how this would be a completely different kind of failure mechanism, and not based on how OhScrap! works at the moment.

Maybe a companion mod/expansion that tracks inactive vessels, and "decides" that something has broken, then applies that broken-ness upon vessel load... Seems like a lot of background processing.

[DarkSlimus]

Prerelease in my GameData folder.

I play it in my career mod, but for testing it do  you prefer we play it on a new career ?

 

 

[severedsolo]

7 hours ago, DarkSlimus said:

I play it in my career mod, but for testing it do  you prefer we play it on a new career ?

A new career would be the absolute ideal, but I've done some pretty serious testing on Gen 1 parts already. I'll take what I can get at this point XD

[DarkSlimus]

Here is my test of the night, I just play normally and report in a text file all missions and failures, so you can see the good missions with no problems ... cause now we have missions with no problems (ok, short missions).

 

so here is my report :

Spoiler

TEST OhScrap!
-------------

-------------
Craft : R2-E 
Mission:Unmaned polar orbital mission

OKTO 
Gen 6 - New part
Reaction wheel failure T+3m35s

Small Inline Reaction Wheel
Gen 6 - New Part
Reaction wheel failure T+4m27s

MK-12R Radial Drogue Mount Chute
Gen 13 - New Part
parachute failure T+7m43s

Mission Failure
Craft recovered but lost some parts at landing (landing speed 14m/s)
---------------
Craft : PGM-11
Mission:Unmaned polar orbital mission

OKTO 
Gen 4 - 1 prev use
Reaction wheel failure T+1m10s

LVT45-Swivel
Gen 23 - New part
Fuel flow failure T+1m37s

Mission Failure
Craft recovered
---------------
Craft : PGM-11
Mission:Unmaned polar orbital mission

OKTO 
Gen 7 - New part
Reaction wheel failure T+34s

Mission Failure
Craft destructed (out of KerbNet Coverage - Stopped the polar orbital programm must have more satellite coverage)
---------------
Craft : R2-E
mission: Unmaned fly above 40,000m

no failure
mission sucess
time duration 3m27
----------------
Craft : R2-E
mission: Unmaned fly above 140,000m

no failure
mission sucess
time duration 14m12
----------------
Craft: Launcher Kebab I
mission: Put a satellite in a circular equatorial orbit at 300km incl max 1°

Small Inline Reaction Wheel
Gen 5 - 1 use
Reaction wheel failure T+52m44s

MK2-R Radial Mounte Chute
Gen 18 - 1 use
parachute failure T+5h21m32s

mission sucess
time duration 5h24m47

So after some missions, I can give you my first analyse.

In general this version work better than the old one, no more 7 failures on a 30 parts craft. I have like it  

I will give you some other test for the next missions

Edited June 7, 2018 by DarkSlimus
add

[Lan_Morehell]

It seems that pre-release lacks part usage count tracking. I have tried to "launch" several times (lifted rocket slowly several meters above the ground, then landed it back to launchpad), now every part in context menu shows 3 previous uses, but safety rating of every part is frozen to 1 (terrible). 

BTW, Why test-firing the rocket on clamps doesnt count as launch? I've had to attach a dosen of landing struts in order to lift and land the rocket

 

[strudo76]

On 6/7/2018 at 5:34 AM, severedsolo said:

Non-Engineer kerbals will now only have a 50% of repairing a part.

Will this be abusable? i.e. just keep trying the repair until it falls on the right side of the 50%. Or a one attempt only per Kerbal mechanism?

[severedsolo]

1 hour ago, strudo76 said:

Will this be abusable? i.e. just keep trying the repair until it falls on the right side of the 50%. Or a one attempt only per Kerbal mechanism?

Same as it's always been, if it fails the check the part is permanently broken.

I'm not ignoring everyone else btw, I've taken it all in, I'm just a little busy atm

[BobTheRocketeer]

One thing that I’ve noticed is that when the prerelease is installed on an already existing save, then all saved parts’ safety rating drops down to 1. Parts pulled fresh from the editor are fine and have the correct saftey values, but all parts on saved and launched vessels all have safety ratings of 1

[severedsolo]

On 6/11/2018 at 10:25 PM, BobTheRocketeer said:

One thing that I’ve noticed is that when the prerelease is installed on an already existing save, then all saved parts’ safety rating drops down to 1. Parts pulled fresh from the editor are fine and have the correct saftey values, but all parts on saved and launched vessels all have safety ratings of 1

 

On 6/9/2018 at 1:17 PM, Lan_Morehell said:

It seems that pre-release lacks part usage count tracking. I have tried to "launch" several times (lifted rocket slowly several meters above the ground, then landed it back to launchpad), now every part in context menu shows 3 previous uses, but safety rating of every part is frozen to 1 (terrible). 

Probably same issue. Safety Rating tracking may not be accurate at this time. It's still tracking it, it's just the numbers it's using as a threshold may be off. Or it's pulling numbers from the persistent file instead of recalcing them (entirely possible).

On 6/7/2018 at 9:14 AM, DarkSlimus said:

Here is my test of the night, I just play normally and report in a text file all missions and failures, so you can see the good missions with no problems ... cause now we have missions with no problems (ok, short missions).

 

so here is my report :

Thank you, this is really good data!

So, the thing that's jumping out at me is that your high generation parts are still failing very often. Would you say that's a fair analysis? If so, I may need to fix that.

[Sokol_323]

Installed version 1.3.5 and I have all the details again have a rating of 1 and started to fail. Even on those crafts, which have already been tested repeatedly and had only minor problems in long flights.  Is it supposed to? Return to the previous version to fix the situation?

[Sokol_323]

Now once again checked the work of fashion. It turns out that if you build a new craft, the details have the rating, which depends on the frequency of their use. But on the existing craft, a rating of 1. You change the details and the rating is restored. Okay, if it's one ship, and if they are more than a dozen and they consist of 50-60 items?

[Sokol_323]

Sorry , the version 1.3.6 beta. Basically ruined my career...

[severedsolo]

On 6/27/2018 at 10:56 AM, Sokol_323 said:

Installed version 1.3.5 and I have all the details again have a rating of 1 and started to fail. Even on those crafts, which have already been tested repeatedly and had only minor problems in long flights.  Is it supposed to? Return to the previous version to fix the situation?

Previous version should indeed fix the situation (but take a backup first just in case). The problem is basically, KSP stores the info OhScrap uses in the craft file. There was some code that forced it to refresh, but apparently that isn't working. Failing that, you can try using the "Refresh" or "Apply Inventory to Craft" buttons in ScrapYard (that should force a refresh too)

[Sokol_323]

I returned to version 1.3.5 and everything was restored.  ScrapYard also showed that the details are new. I didn't understand how it works and decided to use version 1.3.5. At least failures on old ships are, but they are not critical.