HazardousBody corrosion effect

[linuxgurugamer]

1 hour ago, WarriorSabe said:

Yeah, I agree. Corrosion doesn't care how much of the part is exposed; if even a tiny bit is it'll corrode through that tiny bit, and your crew probably doesn't care that the hole in the fuel tank is only half a centimeter across. I do wonder if FAR's out-of-airstream detection method (the thing that lets you build custom fairings and cargo bays that work like the real thing in FAR) can be ported over though, and work in a way that'd make sense for this.

Anything is possible, but is it worth it?  I don’t think so

[WarriorSabe]

8 hours ago, linuxgurugamer said:

Anything is possible, but is it worth it?  I don’t think so

Yeah, that's probably true. That's probably a lot of extra development work, and would also probably make it less performant. Things like supercritical CO2 (like on Venus) have a tendency to seep in and corrode things in a way that regular gasses can't anyways.

Man, I'd probably make this if I knew anything about KSP's API and wasn't already working on a planet pack.

[Manul]

10 hours ago, WarriorSabe said:

Corrosion doesn't care how much of the part is exposed

 If it is pressurized and any breach causes failure. A structural part should not explode due to a small hole. But if it's hollow it will be completely destroyed from inside after this.
I'm not sure that explosions in BDArmory care about the size of exposed area, my experience says that they don't.

[WarriorSabe]

6 minutes ago, Manul said:

 If it is pressurized and any breach causes failure. A structural part should not explode due to a small hole. But if it's hollow it will be completely destroyed from inside after this.
I'm not sure that explosions in BDArmory care about the size of exposed area, my experience says that they don't.

True, but most parts fall into the category of "get a hole anywhere and it's ruined", so if we treat all parts that way there'd only be a few minor edge cases, and it would be much more performant.

Don't get me wrong, it would be cool to get the cases of structural panels halfway clipped into your fuselage, but situations like that are rare, and accounting for them would not only add more calculations, it also means there's more part stats to keep track of, and that makes it harder to support unknown parts. You can't just say "structural parts need to check for clipping", because many are either hollow or trusses, either of which are just as susceptible to small area damage. The remaining parts can probably just be explained away as having weak spots you can't see, or being actually hollow or something (e.g., structural panels are just a truss with some sheeting over that frame)

[Manul]

11 hours ago, linuxgurugamer said:

Anything is possible, but is it worth it?  I don’t think so

Airstream is also a directional thing, so using FAR to determine something that looks like a sealed interior might be tricky. Maybe the corrosion shielding should be limited by stock cargobay shielding mechanics or something similar but as simple. Creating hangars, living quarters and airlocks looks amazing but hard to achieve.

[WarriorSabe]

3 minutes ago, Manul said:

Airstream is also a directional thing, so using FAR to determine something that looks like a sealed interior might be tricky. Maybe the corrosion shielding should be limited by stock cargobay shielding mechanics or something similar but as simple. Creating hangars, living quarters and airlocks looks amazing but hard to achieve.

Oh, I wasn't actually suggesting using FAR itself, but rather seeing how it does that determination. Either way, though, it's not really that necessary

[sturmhauke]

I think the corrosion resistance for hollow parts (e.g. fuel tanks, passenger cabins, etc.) shouldn't be a function of mass, volume, or surface area, but rather the skin thickness and material (which this mod would have to define). For instance, two Rockomax X200-8s holds the same amount of fuel as one X200-16, and they have most of the same game properties (mass, heat resistance, etc.), but the skin is the same thickness. Let's assume the corrosive atmosphere eats through kerbalsteel plating at an estimated rate of 5 mm/hr, that once the skin develops a hole clear through it's considered breached, and the tanks have the same outer skin thickness of 2 cm. That gives a mean time to failure of 4 hours. It doesn't matter if you have 10 of the smaller tanks, or 5 of the larger ones, or another combination, the skin is always the same thickness and is being corroded at the same rate. A different tank model line (Kerbodyne S3, for instance) might have different skin, but within a line they would have the same outer skin. If you model this as hitpoints, I think that therefore tanks within the same model line should have the same number of hitpoints regardless of their size.

I think that this can lead to some interesting gameplay tradeoffs. You could have the corrosion rate and/or the part failure time be somewhat variable, so that you can only predict a part's lifetime within a certain range. You could add anti-corrosion plating or anodes or whatever, with a protection value proportional to the surface area of the part. A craft with more and smaller parts might be more expensive to protect, but might also be less prone to complete craft destruction due to being more modular.

[WarriorSabe]

7 minutes ago, sturmhauke said:

I think the corrosion resistance for hollow parts (e.g. fuel tanks, passenger cabins, etc.) shouldn't be a function of mass, volume, or surface area, but rather the skin thickness and material (which this mod would have to define). For instance, two Rockomax X200-8s holds the same amount of fuel as one X200-16, and they have most of the same game properties (mass, heat resistance, etc.), but the skin is the same thickness. Let's assume the corrosive atmosphere eats through kerbalsteel plating at an estimated rate of 5 mm/hr, that once the skin develops a hole clear through it's considered breached, and the tanks have the same outer skin thickness of 2 cm. That gives a mean time to failure of 4 hours. It doesn't matter if you have 10 of the smaller tanks, or 5 of the larger ones, or another combination, the skin is always the same thickness and is being corroded at the same rate. A different tank model line (Kerbodyne S3, for instance) might have different skin, but within a line they would have the same outer skin. If you model this as hitpoints, I think that therefore tanks within the same model line should have the same number of hitpoints regardless of their size.

I think that this can lead to some interesting gameplay tradeoffs. You could have the corrosion rate and/or the part failure time be somewhat variable, so that you can only predict a part's lifetime within a certain range. You could add anti-corrosion plating or anodes or whatever, with a protection value proportional to the surface area of the part. A craft with more and smaller parts might be more expensive to protect, but might also be less prone to complete craft destruction due to being more modular.

That would be ideal, though how would you estimate it for parts that aren't stock? Ideally this would be able to use some existing property to assign some estimated default values to any part, not just the ones built in. \

Maybe a combination of radial size and some other aspect related to that kind of part? For example, since all fuel tanks have the same mass ratio, the larger ones must have proportionately thicker skins, and the relation between radial size and skin thickness could be determined by what it holds, since there are some standard mass ratios that most tanks have for given fuel types. Or maybe even calculate the mass ratio and use that with the radial size. Crewed parts can be related to radial size and mass, since most have rather similar proportions. Structural parts can maybe use the impact tolerance; we can assume they're all made of similar materials and the stronger ones just have a thicker truss structure (speaking of impact tolerance, maybe that and skin max temp could be decreased as the part corrodes?). I'll have to think about how to do the rest and how we're differentiating those kinds of parts.

It could also still have override settings for whatever things we can think of that would need that.

[sturmhauke]

Yeah something like that sounds good. We would have to think carefully about how to do the formula though. For example, I was poking around in the BDArmory code to see how hitpoints are calculated, and it's kind of a mess. It's not entirely predictable how many hitpoints a given part will have, which is not a great quality to have. There should also be an easy to use config system where you can just edit a text file to change corrosion properties.

[WarriorSabe]

9 minutes ago, sturmhauke said:

Yeah something like that sounds good. We would have to think carefully about how to do the formula though. For example, I was poking around in the BDArmory code to see how hitpoints are calculated, and it's kind of a mess. It's not entirely predictable how many hitpoints a given part will have, which is not a great quality to have. There should also be an easy to use config system where you can just edit a text file to change corrosion properties.

Definitely. And if it comes down to it, even having them all identical wouldn't be that bad.

[sturmhauke]

Has there been any work done on this? Do you need any help? I'm a professional programmer and I know my way around git/GitHub.

[WarriorSabe]

On 3/10/2020 at 2:07 AM, sturmhauke said:

Has there been any work done on this? Do you need any help? I'm a professional programmer and I know my way around git/GitHub.

Not as far as I know; if you want to make this it'd be great because I think a lot of planet packs could benefit.

[WarriorSabe]

It's been a good while; any progress?

[Misguided Kerbal]

Could this possibly be adapted for reentry scorch marks on parts @JadeOfMaar ? 

[linuxgurugamer]

On 3/10/2020 at 5:07 AM, sturmhauke said:

Has there been any work done on this? Do you need any help? I'm a professional programmer and I know my way around git/GitHub.

 

On 5/16/2020 at 8:50 PM, WarriorSabe said:

It's been a good while; any progress?

@JadeOfMaar

Just an update.  I have a number of other projects in the works, but this has just been added to my list of ModsInDevelopment.  Doesn't mean that much yet, other than I'm still thinking about it. With a bit of luck, I'll be able to seriously start work on this in the next few weeks

 

[JadeOfMaar]

@linuxgurugamer Take your time. I haven't seen reason to suggest that you dropped this. I know you are and can still be committed to this as you still (apparently easily) maintain a few hundred mods. I've been engrossed elsewhere in modding so I haven't minded this topic much.

[sturmhauke]

My problem is I code all day for my job, and then when it comes to coding for fun I've often used all my code juice.

[WarriorSabe]

Oh, good. No rush or anything, it's been several months and I have no problems waiting another several. Just was curious since the thread had been quiet.

[WarriorSabe]

With the recent Kopernicus news, has there been any impact here? Or is it going to be implemented in a way that doesn't need Kopernicus / not been started yet anyways?

[linuxgurugamer]

1 minute ago, WarriorSabe said:

With the recent Kopernicus news, has there been any impact here? Or is it going to be implemented in a way that doesn't need Kopernicus / not been started yet anyways?

It never was going to be dependent on Kopernicus, although it would have been complementary to K.

And, no work has been done on this yet

[WarriorSabe]

Apparently it's been long enough for this to get the "thread is old" message. I do hope that this hasn't been forgotten about.