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

[severedsolo]

10 hours ago, subyng said:

I'm using DeadlyEntry, and I noticed it defines a resource "AblativeShielding". Perhaps its overriding the "Ablator" resource used in stock, which is why it was targeted by this mod. I will try adding AblativeShielding to the blacklist and report back!

Oh yeah that would do it. That takes me back, I didn't even realise DRE was still a thing, but yes it does override Ablator.

I'll add it to the blacklist for the next release, once I get ScrapYard fixed.

[Starwaster]

On 6/9/2019 at 3:44 AM, severedsolo said:

Oh yeah that would do it. That takes me back, I didn't even realise DRE was still a thing, but yes it does override Ablator.

I'll add it to the blacklist for the next release, once I get ScrapYard fixed.

As long as stock parts routinely have failure temperatures above the melting point of tungsten then Deadly Reentry will always be a thing. 

As far as heat shields go, any legacy parts that used the old ablative resources continue to use them for compatibility purposes but that’s it. 

[severedsolo]

On 6/8/2019 at 9:04 PM, subyng said:

Yep, that's the mod. Here's my ksp log:

https://ufile.io/z4nuge7w

And my mod folder: 

https://imgur.com/a/MYK5Nyt

I'm using DeadlyEntry, and I noticed it defines a resource "AblativeShielding". Perhaps its overriding the "Ablator" resource used in stock, which is why it was targeted by this mod. I will try adding AblativeShielding to the blacklist and report back!

Thanks!

Just got time to look at your log, it was indeed AblativeShielding that caused the issue:
 

Quote

[LOG 01:10:55.772] [OhScrap]: Failure Event! Safety Rating: 1, MET: 66032.0447739788
[LOG 01:10:55.775] [OhScrap]: 3483863895 of type Corvus Heat Shield has suffered a AblativeShielding leak

 

[Corax]

IMO heat shields leaking ablator is a fair approximation of general failures; just think of John Glenn's Friendship 7, or Shuttle tiles dropping off during flight. Maybe there should be a way to limit the amount or rate, but I think there needs to be some way of heat shields failing.

The same goes for food; that's another resource where I think of "leaking" as a stand-in for spoil, or in fact actual loss overboard.

I've always removed them from being blacklisted in my installs.

Edited June 11, 2019 by Corax
amount *or rate*

[gap]

22 minutes ago, Corax said:

IMO heat shields leaking ablator is a fair approximation of general failures; just think of John Glenn's Friendship 7, or Shuttle tiles dropping off during flight. Maybe there should be a way to limit the amount or rate, but I think there needs to be some way of heat shields failing.

The same goes for food; that's another resource where I think of "leaking" as a stand-in for spoil, or in fact actual loss overboard.

I've always removed them from being blacklisted in my installs.

Aren't ablative materials synthetic resins or a solid foam of some sort? For the life of me, I don't see how such a type of resource could actually leak or fail in any way...

[Corax]

31 minutes ago, gap said:

Aren't ablative materials synthetic resins or a solid foam of some sort? For the life of me, I don't see how such a type of resource could actually leak or fail in any way...

 

1 hour ago, Corax said:

a fair approximation of general failures

Works for me, doesn't have to work for you.

[Starwaster]

1 hour ago, gap said:

Aren't ablative materials synthetic resins or a solid foam of some sort? For the life of me, I don't see how such a type of resource could actually leak or fail in any way...

Bond line failure comes to mind. That would mostly be an issue during reentry. 

[gap]

2 hours ago, Corax said:

 

Works for me, doesn't have to work for you.

Are you serious?
I thought we were thinking out loud here, trying to contribute ideas politely and on a mutual basis.
Where is this harsh answer coming from? 

1 hour ago, Starwaster said:

Bond line failure comes to mind. That would mostly be an issue during reentry. 

Thank you Starwaster!
What you are suggesting makes more sense than leakage, though I would expect such a type of failure to be "all or nothing" and to only happen during reentries...

Edited June 11, 2019 by gap

[dylsh]

Hi. Great mod. I’m a big fan, as I was also for DangIt! My question is: in this mid, is there a possibility of engines/tanks/SRB’s exploding? Or are the failures limited to gimbling/leaks/failing, etc?

Also, is there the possibility for RSC parts to malfunction and start firing? Throwing the craft into an unwanted spin?

 

thanks!

[severedsolo]

14 hours ago, Corax said:

IMO heat shields leaking ablator is a fair approximation of general failures; just think of John Glenn's Friendship 7, or Shuttle tiles dropping off during flight. Maybe there should be a way to limit the amount or rate, but I think there needs to be some way of heat shields failing.

The same goes for food; that's another resource where I think of "leaking" as a stand-in for spoil, or in fact actual loss overboard.

I've always removed them from being blacklisted in my installs. 

The reason that this in particular was a bug, was that the TankFailureModule specifically simulates a pressurised tank dumping it's contents into space. Leaks start quickly, and then drop off as the amount of resource drops off in the tank. This obviously doesn't make sense for Ablator.

10 hours ago, dylsh said:

My question is: in this mid, is there a possibility of engines/tanks/SRB’s exploding? Or are the failures limited to gimbling/leaks/failing, etc?

Also, is there the possibility for RSC parts to malfunction and start firing? Throwing the craft into an unwanted spin?

Liquid Engines can explode, but you'll get a little warning before that happens. One of the failure modes is a "fuel line leak" which will flash up a warning on the screen. If you don't shut down the engine, then it will ignite the fuel and explode. SRBs and tanks only have one failure mode, which is "failed to ignite" on an SRB (which usually leads to an explosion anyway if you are on the ground, because if you are using one you get asymmetrical thrust), and for tanks it's the pressurised leak which I spoke about above.

10 hours ago, dylsh said:

Also, is there the possibility for RSC parts to malfunction and start firing? Throwing the craft into an unwanted spin? 

RCS won't randomly fire, if a RCS failure occurs the RCS module will just shut down. This can of course still throw your craft into a spin, if your RCS isn't balanced to compensate.

IMO unwanted spins are pointless while the "timewarp to stop all spin" is a thing.

Edited June 12, 2019 by severedsolo

[Starwaster]

@severedsolo Gemini 8 suffered an uncontrolled spin due to unwanted RCS firing. The cause was believed to be an electrical short. 

[dylsh]

7 hours ago, severedsolo said:

.IMO unwanted spins are pointless while the "timewarp to stop all spin" is a thing.

Yes you’re right. I’ve been using persistent rotation so long I’ve forgotten about the stock mechanics. I do hope we have an RCS failure like that one day though. It would add those white knuckle stress moments if it were to happen at the wrong time. 

 

26 minutes ago, Starwaster said:

@severedsolo Gemini 8 suffered an uncontrolled spin due to unwanted RCS firing. The cause was believed to be an electrical short. 

This is a problem I’d love to be forced to deal with. 

[gap]

Hi @severedsolo, I am considering to expand my mod list and I have a question for you: if a life support mod is used together with OhScrap!, are supplies (food, water, oxygen, etc.) and wastes ("mulch", CO2, etc.) added to the game by similar mods, treated as any other resource that can leak at times?

[severedsolo]

18 minutes ago, gap said:

Hi @severedsolo, I am considering to expand my mod list and I have a question for you: if a life support mod is used together with OhScrap!, are supplies (food, water, oxygen, etc.) and wastes ("mulch", CO2, etc.) added to the game by similar mods, treated as any other resource that can leak at times? 

Food is blacklisted by default because I use TAC, other than that yes they will be treated like any resource.

It's dead easy to blacklist a resource though, you just make a MM patch like so:

OHSCRAP_RESOURCE_BLACKLIST
{
	name = ElectricCharge
}

OHSCRAP_RESOURCE_BLACKLIST
{
	name = Food
}

etc

[gap]

1 minute ago, severedsolo said:

Food is blacklisted by default because I use TAC, other than that yes they will be treated like any resource.

It's dead easy to blacklist a resource though, you just make a MM patch like so:

OHSCRAP_RESOURCE_BLACKLIST
{
	name = ElectricCharge
}

OHSCRAP_RESOURCE_BLACKLIST
{
	name = Food
}

etc

Thank you for your quick answer.
I seem to understand that you support the TAC Life Support mod, good to know!

Have you ever tried other similar mods? Kerbalism (as I understand by far the most complex of them) for example has its own failure module. I wonder if blacklisting the resources  that this mod adds to the game, is enough for avoiding conflicts between it and OhScrap!

[Daedalus451]

I'm not getting any Oh Scrap failures with liquid engines at all. Untested solid rockets fail all the time, and I've had a control surface failure too, but never any problems with liquid engines (from this mod).

I'm also using three other mods which produce failures: Dang It, Kerbalism and Kerbal Launch Failure. I'm also using Engine Ignitor. Could any of those be causing a conflict?

[severedsolo]

2 hours ago, Daedalus451 said:

I'm not getting any Oh Scrap failures with liquid engines at all. Untested solid rockets fail all the time, and I've had a control surface failure too, but never any problems with liquid engines (from this mod).

I'm also using three other mods which produce failures: Dang It, Kerbalism and Kerbal Launch Failure. I'm also using Engine Ignitor. Could any of those be causing a conflict?

I'd have to see a log to be certain, and it's not unfeasible that kerbalism et Al are causing a conflict (it's unlikely to be dang it, I drew alot of inspiration from that mod, and I know how it works, it shouldn't interfere).

I think the most likely explanation though is that you just got (un)lucky. The way the failure system is set up, the part has to actively be in use to even be considered for failure. In an engines case that means throttled up. Usually liquid engines win out to the tanks above them, just by law of averages (the mod is more likely to select a tank, just simply because there are more of them)

[Daedalus451]

14 minutes ago, severedsolo said:

I'd have to see a log to be certain, and it's not unfeasible that kerbalism et Al are causing a conflict (it's unlikely to be dang it, I drew alot of inspiration from that mod, and I know how it works, it shouldn't interfere).

 I think the most likely explanation though is that you just got (un)lucky. The way the failure system is set up, the part has to actively be in use to even be considered for failure. In an engines case that means throttled up. Usually liquid engines win out to the tanks above them, just by law of averages (the mod is more likely to select a tank, just simply because there are more of them)

Ok, I can't get you a log right now. I'll see what I can do later.

That seems a shame about the low likelihood of engine failures though. I'd have thought the engine, being the most complicated thing on a rocket after the guidance system, would be far more prone to failures if it's not tested properly.

What kind of engine failures can occur? Does it just shut down, or can you get gimbal lock, underthrust etc?

[gap]

8 hours ago, Daedalus451 said:

I'm not getting any Oh Scrap failures with liquid engines at all. Untested solid rockets fail all the time, and I've had a control surface failure too, but never any problems with liquid engines (from this mod).

I'm also using three other mods which produce failures: Dang It, Kerbalism and Kerbal Launch Failure. I'm also using Engine Ignitor. Could any of those be causing a conflict?

Since you seem to enjoy living on the edge, you might also be interested in this other mod:

 

Anyway my doubt is, don't multiple failure mods risk to mess with each other or, at best, to create a totally unbalanced failure rate?

@severedsolo what is your opinion on that? Talking in general, would you recommend using OhScrap! together with Dang It| and/or other similar mods?

[Daedalus451]

12 hours ago, gap said:

you seem to enjoy living on the edge

Thanks, I will try BARIS too!

[severedsolo]

13 hours ago, gap said:

 what is your opinion on that? Talking in general, would you recommend using OhScrap! together with Dang It| and/or other similar mods?

No, but I'm not a masochist (kidding)

From a technical point of view, there is no real reason that you can't run more than one failure mod.

KSP modding is not really like modding other games, I'll use Stellaris as an example here: there are files that you edit, which if more than one mod tries to edit they will conflict with each other, because they are trying to overwrite each other. KSP doesn't work like that, there isn't an API, the code is just thrown wide open and we can write code that interacts with it.

In effect, each mod is it's own independent computer program which just occasionally interacts with KSP by calling the same methods that the stock game does. Where conflicts occur, it's usually because another mod has put the game into a state that the first mod isn't expecting.

I'll use the EngineFailureModule as an example here: when I want to shutdown an engine, I just call engine.shutdown. In essence, this clicks the button that says "Shutdown Engine" in the PAW, it just does it via code.

If another mod tries to restart the engines, then OhScrap isn't going to allow that. Because the player can restart the engines themselves, OhScrap is constantly checking that the engine is still shutdown. If it finds it isn't, the engine is shutdown again.

So, really your only danger is that two failure mods try to initiate the same failure. If you repair it in one, the other is going to keep enforcing it's failures.

TL:DR They should work fine together, as long as you remember which mod caused which failure.

18 hours ago, Daedalus451 said:

That seems a shame about the low likelihood of engine failures though. I'd have thought the engine, being the most complicated thing on a rocket after the guidance system, would be far more prone to failures if it's not tested properly.

I agree with you in theory, but it also doesn't make sense that an engine will fail while it's sitting there not being used. I'm not saying that liquid engines will never/rarely fail, as with everything it very much depends on the craft. Beetlecat for example had a craft that had so many engines, the only thing that failed was engines.

18 hours ago, Daedalus451 said:

What kind of engine failures can occur? Does it just shut down, or can you get gimbal lock, underthrust etc?

Off the top of my head you can get: Full engine shutdown, underthrust, gimbal lock, and a fuel line leak which if left unchecked will cause the engine to explode.

[severedsolo]

Heads up

New ScrapYard is out. Oh Scrap! is compatible but if you are using KRASH the build counters will look a bit messed up during simulations. This is purely cosmetic, as OhScrap! will not do anything during simulations anyway. I will fix it up soon

[gap]

4 hours ago, Daedalus451 said:

Thanks, I will try BARIS too!

I never tried it, but going by the info I have read on its thread, it looks cool too!
 

4 hours ago, severedsolo said:

No, but I'm not a masochist (kidding)

LOL. The other day on the KKS thread, I was commenting with Betlecat how for many of us it is right the opposite: we don't seem to enjoy the game if we can't smash up our rockets in many unpredictable ways   

 

4 hours ago, severedsolo said:

From a technical point of view, there is no real reason that you can't run more than one failure mod.

KSP modding is not really like modding other games, I'll use Stellaris as an example here: there are files that you edit, which if more than one mod tries to edit they will conflict with each other, because they are trying to overwrite each other. KSP doesn't work like that, there isn't an API, the code is just thrown wide open and we can write code that interacts with it.

In effect, each mod is it's own independent computer program which just occasionally interacts with KSP by calling the same methods that the stock game does. Where conflicts occur, it's usually because another mod has put the game into a state that the first mod isn't expecting.

I'll use the EngineFailureModule as an example here: when I want to shutdown an engine, I just call engine.shutdown. In essence, this clicks the button that says "Shutdown Engine" in the PAW, it just does it via code.

If another mod tries to restart the engines, then OhScrap isn't going to allow that. Because the player can restart the engines themselves, OhScrap is constantly checking that the engine is still shutdown. If it finds it isn't, the engine is shutdown again.

So, really your only danger is that two failure mods try to initiate the same failure. If you repair it in one, the other is going to keep enforcing it's failures.

TL:DR They should work fine together, as long as you remember which mod caused which failure.

That makes sense.
So, If we could set the general failure chance of each failure mod, we could even benefit in therms of failure variety, from using several of them...

[subyng]

So I'm having a problem with the generation not advancing after a flight. I'm using v.1.1.1 as suggested earlier in the thread. I'm using the stock recover button after actually flying my craft (not just a static test), but not explicitly using any of the scrapyard functionality. 

My ksp log:

https://ufile.io/xo11qmee

Also, are parts supposed to be able to fail after being repaired? Once again this is with the corvus mod, the parachute/RCS combo failed twice. 

[gap]

4 minutes ago, subyng said:

So I'm having a problem with the generation not advancing after a flight. I'm using v.1.1.1 as suggested earlier in the thread. I'm using the stock recover button after actually flying my craft (not just a static test), but not explicitly using any of the scrapyard functionality. 

My ksp log:

https://ufile.io/xo11qmee

Also, are parts supposed to be able to fail after being repaired? Once again this is with the corvus mod, the parachute/RCS combo failed twice. 

I can be very much mistaken, but I thing that "generation" is how many times you have built a certain part during your career. It not advancing after a flight might be perfectly normal: If SY's auto-apply function is checked, every time a craft is assembled/loaded in the VAB/SPH, the mod tries using already built parts if they are available. The result is that at each new launch, usage number increases, while generation number keeps constant.
Recycling parts is a cost- and time-effective method if you are using SY's (experimental) fund override method and KCT, but every time  you re-use a part after the second usage the reliability of that part will decrease and, even worst, you will miss the advantages of increasing the generation number.

P.S: SrapYard v1.1.3 is out for testing. You might want to install that version instead of  v.1.1.1