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

[severedsolo]

@vardicd so, watching the video, I saw the old chutes apply when you clicked them manually from the inventory, are you saying it's just quick apply that's not working?

Do the chutes happen to be the root part? (I doubt it, but just wondering)

[vardicd]

Just now, severedsolo said:

@vardicd so, watching the video, I saw the old chutes apply when you clicked them manually from the inventory, are you saying it's just quick apply that's not working?

Do the chutes happen to be the root part? (I doubt it, but just wondering)

chutes are not a root part, and can be manually applied from the inventory, when I can get it to stay up. sometimes it flickers in and out, but yes the quick apply does NOT seem to be applying the old chutes to be re-used. it just places a new chute part.

 

[severedsolo]

3 minutes ago, vardicd said:

chutes are not a root part, and can be manually applied from the inventory, when I can get it to stay up. sometimes it flickers in and out, but yes the quick apply does NOT seem to be applying the old chutes to be re-used. it just places a new chute part. 

  

Alright, sounds like a bonafide bug. Leave it with me, and I'll see if I can reproduce, thanks.

[vardicd]

Just now, severedsolo said:

Alright, sounds like a bonafide bug. Leave it with me, and I'll see if I can reproduce, thanks.

Okay, let me know if there's anything else you need from me. Will be glad to help.

[vardicd]

@severedsolo Update on the parachute issue, I just launched a rocket in which I manually placed a gen 1 parachute from my inventory, but when it finished constructing and I launched it, when it came time to deploy the chute, I saw it was rated as a gen 4. Seems to imply the manual placement of the previous gen parachutes isn't sticking through the build process. {using Kerbal Construction Time, if it matters?}

[vardicd]

@severedsolo I'm afraid I may have another issue to set in your lap. I'm seeing irregular behavior between oh scrap and KRASH. In several instances now, when I run a simulation to see if a particular design has enough Dv to escape the atmosphere of Kerbin, any stages dropped that despawn, that would have gotten caught by stage recovery, which I use, seem to have a random chance of advancing the generation of those parts, even though the KRASH mod supposedly works by reverting your game back to before it let you launch your test flight. This supposedly prevents it from having actual effects on your game, such as a kerbal dying, or a part test counting and upping the generation or safety rating. it doesn't happen every time. I've been watching, it seems to be hit and miss, unless there's something going on I'm not aware of. I am new to this mod. other suspect mods posted below.

 

[vardicd]

@severedsolo I'm going to go ahead and drop a link to my output log for KSP {which honestly had I not been tired last night when I was posting I would have done then, in the off chance it would help you, and I should have done so} So here it is: https://www.dropbox.com/s/jk7gd90zavd6o6y/output_log For Oh Scrap.txt?dl=0 I had just saved and exited right after an incident of gen 1 parachute in the VAB, but a Gen 5 on the Launchpad after building. I've been purposely testing this, and the Oh Scrap/KRASH/Stage Recovery issues }which I still can not reliably reproduce, and am beginning to suspect I'm making mistakes somewhere.} on separate installs, so I'm not sure if you'll see that behavior in this log or not.  Sorry if I'm being annoying, with the repeated posts. I'm just trying to help, and I sometimes don't see the line between being helpful, and becoming a nuisance.

Before and after build pictures with parachute comparison stats.

[severedsolo]

@vardicd don't worry mate, you've been following my mods for long enough to know that I'm not shy about telling people when they are getting on my wick

It's all helpful, I just haven't replied because I just don't have time to look at it right now. I really only get time to look at this stuff on a Tuesday or a Wednesday, but I've got alot on over the next couple of weeks, as my daughter is on school holidays from next week, I'm reading it all, and will let you know when I find something. 

[vardicd]

44 minutes ago, severedsolo said:

@vardicd don't worry mate, you've been following my mods for long enough to know that I'm not shy about telling people when they are getting on my wick

It's all helpful, I just haven't replied because I just don't have time to look at it right now. I really only get time to look at this stuff on a Tuesday or a Wednesday, but I've got alot on over the next couple of weeks, as my daughter is on school holidays from next week, I'm reading it all, and will let you know when I find something. 

Understood.

[severedsolo]

@vardicd - Managed to reproduce the KRASH issue. Probably a ScrapYard issue - raised #2

For the parachute thing, RealChute is not really supported right now, it's on the roadmap (was meant to make it into 1.6... but things happened).

Edit: Can you try this build and see if it helps? https://github.com/severedsolo/ScrapYard/releases/tag/1.2pr1

Word of warning - back your save up, this has barely been tested at all. (I know about the OhScrap generations being messed up during KRASH simulations, I want to fix the ScrapYard issue first)

Edited April 4, 2019 by severedsolo

[vardicd]

4 hours ago, severedsolo said:

@vardicd - Managed to reproduce the KRASH issue. Probably a ScrapYard issue - raised #2

For the parachute thing, RealChute is not really supported right now, it's on the roadmap (was meant to make it into 1.6... but things happened).

Edit: Can you try this build and see if it helps? https://github.com/severedsolo/ScrapYard/releases/tag/1.2pr1

Word of warning - back your save up, this has barely been tested at all. (I know about the OhScrap generations being messed up during KRASH simulations, I want to fix the ScrapYard issue first)

I can test this out over the next couple of days. Just for clarity sake, I'm unclear which issue is this fix supposed to help, the KRASH/Scrapyard or the parachute?

[severedsolo]

5 hours ago, vardicd said:

I can test this out over the next couple of days. Just for clarity sake, I'm unclear which issue is this fix supposed to help, the KRASH/Scrapyard or the parachute?

This should fix KRASH simulations incrementing the build count. Parachutes will have to wait until I get round to implementing RealChute support properly.

Known issue right now is that if you happen to check your parts during KRASH simulations the generations will look wrong (this is a side effect of the fix I put in, because OhScrap! checks the build count to determine the generation.) - I will fix this once I know ScrapYard is working properly

Edited April 5, 2019 by severedsolo

[vardicd]

1 minute ago, severedsolo said:

This should fix KRASH simulations incrementing the build count. Parachutes will have to wait until I get round to implementing RealChute support properly.

Okay, did you find a way to reliably reproduce the Krash generation increase issue? I've only actually had it happen a couple of times in all my testing, so even if it's not fixed, I don't know if i'll see it happen?

[severedsolo]

2 minutes ago, vardicd said:

Okay, did you find a way to reliably reproduce the Krash generation increase issue? I've only actually had it happen a couple of times in all my testing, so even if it's not fixed, I don't know if i'll see it happen?

It was happening regularly for me, I just threw a Mk1 Pod and a chute onto the pad, and ran a simulation before terminating it. After clicking "apply new parts" in the VAB it was ticking up the counter.

I will do a proper test over the weekend, but I'm fairly confident this will fix it.

Edited April 5, 2019 by severedsolo

[vardicd]

1 minute ago, severedsolo said:

It was happening regularly for me, I just threw a Mk1 Pod and a chute onto the pad, and ran a simulation before terminating it. After clicking "apply new parts" in the VAB it was ticking up the counter.

Okay, I'll give it a try.

[vardicd]

@severedsolo Good lord, I don't know what the difference between the build you gave me to test and the official version is, but my anti-virus does not like the new build. I have Kerbal, as well as most of my game saved to a SSD, that my anti-virus is blacklisted from reading. It's not even supposed to know that drive exists, unless I ask it to manually check a file there, and then only that file, but even with that restriction in place, everytime I'd unpack the new version into my KSP folder, Norton was on that thing like a blood hound ripping every Dll out of it, yet the official version of the mod, which was still on that drive, just moved out of the KSP folder while I tested the new version it never reacted to. I literally spent 5-10 minutes forcing Norton to ignore every file in that new version manually. I've got it running now though. will let you know my test results as soon as I have something to report.

[severedsolo]

33 minutes ago, vardicd said:

@severedsolo Good lord, I don't know what the difference between the build you gave me to test and the official version is, but my anti-virus does not like the new build. I have Kerbal, as well as most of my game saved to a SSD, that my anti-virus is blacklisted from reading. It's not even supposed to know that drive exists, unless I ask it to manually check a file there, and then only that file, but even with that restriction in place, everytime I'd unpack the new version into my KSP folder, Norton was on that thing like a blood hound ripping every Dll out of it, yet the official version of the mod, which was still on that drive, just moved out of the KSP folder while I tested the new version it never reacted to. I literally spent 5-10 minutes forcing Norton to ignore every file in that new version manually. I've got it running now though. will let you know my test results as soon as I have something to report.

Weird... Although I did compile it on Linux, using Rider rather than on Windows with VS, like I usually do. Possibly it doesn't like the compiler. 

Edit: oh and I compiled it in debug mode, that may make a difference, as it includes some stuff to hook into unity if you do it that way. 

Edited April 5, 2019 by severedsolo

[vardicd]

34 minutes ago, severedsolo said:

Weird... Although I did compile it on Linux, using Rider rather than on Windows with VS, like I usually do. Possibly it doesn't like the compiler. 

Edit: oh and I compiled it in debug mode, that may make a difference, as it includes some stuff to hook into unity if you do it that way. 

Ah, who knows, but so far I've been testing for a while just rolling out sim after sim, and I'm not seeing a generation increase on any parts.

[gap]

Hi @severedsolo, I am a new KSP player and already a fan of your mod. I have a few questions/remarks relative to the failure system you have applied if you don't mind, but before I start exposing them I wish to know: it the current version of the mod (1.6.1.1) still based on your considerations below or something has changes since the last July?

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

So, the logic behind this is that as you said, previously parts were failing way too often. One of the reasons for this was that every part was handling it's failures individually. 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.

With the new system, we have a one time event instead (balanced by the fact that the event is re-rolled every 10 seconds).

Now, with the old system, failure rates were easy to calculate, the part just rolls against it's own chance of failure. When we are rolling once per vessel though, which parts failure rate do you use? You could use the worst part on the vessel, but then for fairness you have to fail that part - which means that the same part fails every time (boring) - so by using the average failure rate of the entire vessel, we make it fair and can then select any part at random to fail.

One thing I didn't mention in the changelog, is that your crappy parts are still more likely to take the hit on the failure. A simplified version of how it works is this:

1) Determine whether a failure will occur, if not, return. Otherwise go to 2.

2) Select a part at random, increment the counter by 1 and roll against it's individual failure rate.

3) if the counter is greater than 100 (ie we've tried to fail 100 parts and they have all passed the test) OR the part has failed the test, fail the part selected in 2. Otherwise, go back to 2.

 

 

[severedsolo]

15 hours ago, gap said:

I wish to know: it the current version of the mod (1.6.1.1) still based on your considerations below or something has changes since the last July?

It still works like that - but there's been a couple of minor tweaks.

Now the time between rolls changes depending on the vessels situation (ie in space it will roll every 30 (kerbal) minutes by default, whereas in atmosphere it will be every 10 seconds/5 minutes (depending on how long it's been active).

Also a failure is not guaranteed to happen on a success roll any more, it will roll against every part's failureChance (starting with the most likely to fail) and if they all "pass" no failure will happen.

[gap]

4 hours ago, severedsolo said:

It still works like that - but there's been a couple of minor tweaks.

Now the time between rolls changes depending on the vessels situation (ie in space it will roll every 30 (kerbal) minutes by default, whereas in atmosphere it will be every 10 seconds/5 minutes (depending on how long it's been active).

Also a failure is not guaranteed to happen on a success roll any more, it will roll against every part's failureChance (starting with the most likely to fail) and if they all "pass" no failure will happen.

In other words, on loading a vessel you calculate its overall failure chance by averaging the failure chances of its components, then you roll the dices and check the result; if the check fails, no failures will ever happen during the current mission; else, every x in-game seconds (variable depending on circumstance  and part) you keep rolling the dices over the individual failure chances of currently active parts, in order to determine which one will actually fail. If a cycle of dice rolls fails (i.e. all the currently active parts have been checked and none has failed), your code waits until the next roll and then checks again if one of the active parts fails.

Is that correct?

[severedsolo]

@gap

Not quite. The mod will roll every x seconds against the average failure rate of the vessel. 

If the vessel passes the roll, no further action will be taken until the next roll in x seconds. 

If it fails, the mod will then start rolling against the individual failure rates of each part, starting with the most likely to fail (if you are familiar with tabletop gaming, think of this as a "saving roll") 

If a part fails this roll, that part will be chosen as the part to fail and the failure will be initiated. No further checks are then done until the next x second roll comes around again, at which point the process will restart. 

If every part passes this saving roll, the failure will be aborted and no parts will fail this time. 

[gap]

57 minutes ago, severedsolo said:

@gap

Not quite. The mod will roll every x seconds against the average failure rate of the vessel. 

If the vessel passes the roll, no further action will be taken until the next roll in x seconds. 

If it fails, the mod will then start rolling against the individual failure rates of each part, starting with the most likely to fail (if you are familiar with tabletop gaming, think of this as a "saving roll") 

If a part fails this roll, that part will be chosen as the part to fail and the failure will be initiated. No further checks are then done until the next x second roll comes around again, at which point the process will restart. 

If every part passes this saving roll, the failure will be aborted and no parts will fail this time. 

Okay, so if I got you correctly, the number of rolls is not limited, i.e. the longer a mission will last, the more likely one or more failures will happen. Right?

[severedsolo]

55 minutes ago, gap said:

Okay, so if I got you correctly, the number of rolls is not limited, i.e. the longer a mission will last, the more likely one or more failures will happen. Right?

Correct, as long as the vessel is the active vessel rolls will happen. Vessels you aren't looking at will be left alone (and the mod won't play catch up, so you could let your duna probe fly on its merry way while unloaded and it would be fine when it got there) 

[gap]

57 minutes ago, severedsolo said:

Correct, as long as the vessel is the active vessel rolls will happen. Vessels you aren't looking at will be left alone (and the mod won't play catch up, so you could let your duna probe fly on its merry way while unloaded and it would be fine when it got there) 

Okay thanks, I think I have got the picture now but I have a few more questions if you don't mind

8 hours ago, severedsolo said:

Now the time between rolls changes depending on the vessels situation (ie in space it will roll every 30 (kerbal) minutes by default, whereas in atmosphere it will be every 10 seconds/5 minutes (depending on how long it's been active).

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

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...