severedsolo

[1.7.x] Oh Scrap!- A ScrapYard based Part Failure and Reliability Mod 1.7.1 (25/09/2019)

Recommended Posts

Posted (edited)
1 hour ago, subyng said:

Yep, the configs all look correct. 

Here's the Oh Scrap log:

https://pastebin.com/5rgVn6TQ

Corvus Heat Shield is the part that failed. Interestingly I don't see any "Failure Event" and "Failure Successful" messages at the very end, even though that part did indeed fail. 

I'll need to see your KSP.log I think.

Was it this mod the heatshield came from? https://spacedock.info/mod/1405/Corvus CF

I just tried to make it leak, and all the debugging stuff came back (correctly) as "not allowed to leak"

Obviously I can see from the OhScrap logs that it did indeed try to fail it, but I'm not sure why.

Edited by severedsolo

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites
Posted (edited)

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 by Corax
amount *or rate*

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
Posted (edited)
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? :o

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 by gap

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites
Posted (edited)
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 by severedsolo

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
12 hours ago, gap said:

you seem to enjoy living on the edge

:D

Thanks, I will try BARIS too!

Share this post


Link to post
Share on other sites
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 :P(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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
4 hours ago, Daedalus451 said:

:D

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 :P(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  :sticktongue: :D

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.