Structural Integrity (environment wears down your parts)

[JadeOfMaar]

A simplified but more comprehensive concept for a new breed of part failure mechanics. Failure is facilitated by interaction with planet mods or the universe and not (as usual) letting yourself be taken by surprise by an RNG and a countdown machine. Its purpose is to add more tangible gameplay value to planets. This rises from an unrelated discussion on a planet mod's Discord server, of how planetary rings in this KSP could be more tangible and hence, hazardous, and I saw a connection back to my earlier post, linked here:

Some folks I discussed with: @WarriorSabe @StarCrusher96

Some folks who may find this evolved concept interesting: @linuxgurugamer (who showed interest in taking a shot at coding the predecessor), @Angel-125 (who owns a mod that contains a whipple shield and interstellar engines: WBI DSEV), @R-T-B @prestja (Kopernicus devs).

The component concepts that came up were as follows:

Durability

How a part fails is decided by the health gauge itself and the saturation and mitigation system. In a nutshell, saturation is how much punishment the part can take before it starts actually failing (this has its own gauge). If saturation is below a certain minimum, no damage is taken. If that minimum is exceeded, health (and if possible, other stats) start falling. The higher the saturation bar is, the faster the positive stats fall. The relevant stats to implement would be crash tolerance, heat tolerance, joint strength.

A bonus feature of the impact system is that parts with certain attributes or modules, if hit with seemingly non-lethal force, can still stand to have modules shutdown or status flags raised that can be used by other mods to represent a situation. Example: an exposed crew cabin gets hit: the glass shatters, all its resources empty out, its modules stop working, and a life support mod uses the flag (or more) for a compromised habitat. It will require a kerbal with the relevant trait and skill to "repair" the part and clear the status flag(s). The part could have a flag that requires a scientist, and a flag that requires an engineer. While these flags up, modules can refuse to start, and resources can continue to empty out.

Debris Fields

Assuming planetary rings and Kopernicus asteroid fields could have tangible micro-meteor debris fields, their threat would take the form of raycasts occurring, with random vectors, speeds and virtual masses, trying to strike the active vessel. The saturation and mitigation system are virtually not present when traveling at leisurely low interplanetary speeds. It's mostly the small and basic matter of building your ship to be extra sturdy (whether by using struts, structural parts with higher crash tolerance, or involving ablative hull plating in your ship designs). These systems begin to become prominent when encountering extremely dense debris fields such as the proto-planetary discs of young stars. The faster you go, the more the impacts tend towards the frontal surfaces of your ship, and saturation of your forward shields become a concern.

Visualization: A basic and sufficient visualization for an impact would be sparks (there's an engine flameout plume or 2 for that, for example) at the point of impact.

The planet-level collision areas would ideally be setup like resource bands for ISRU or Kopernicus asteroid fields themselves, but instead of customizing resources, you're customizing ranges of micro-meteor speeds, sizes, force, frequency.

Corrosion

This is heavily detailed in the linked thread above, and concerns any and all planets that were made to be corrosive but cannot be as no mod for this mechanic does exists to date. But to simplify for here, this manifests in the ability to set corrosion parameters for a planet's:

• Atmosphere (including strength, whether acid or alkaline, and an altitude curve so there can be a safe region and a hazard region);
• Surface (strength, whether acid or alkaline, whole planet or per biome);
• Ocean (same params as surface);
• Exosphere (possibly. I'm not aware of any case of corrosives in vacuum but having it still makes for some creative freedom).

The health bar and saturation system are the most prominent here as parts are subject to DPS (damage per second) due to prolonged and heavy exposure. Measures can be taken to reduce the effect of ambient corrosives on individual parts or the whole ship. Hull parts could be tailor made (being fabricated the right way and with the right stuff) or boosted (painted with ablators or potentially toxic anti-corrosives, or insulated by an electromagnetic field) to have great(er) resistance.

Visualization: A part that is overwhelmed by corrosion could have indicators in the form of the black-body overlay (but that it starts glowing purple. Seems fitting for a starter. It's like having the poison status in an RPG) and a purple saturation bar. This glow and this bar show how much the part is being punished and is the same as hearing a geiger counter crackling increasingly loudly. If you can get away in time then this bar empties and health stops falling-- you don't die immediately if you let that bar fill up but you know you won't last that long a 2nd time.

Heat (Conductivity/Thermal Stress)

Everyone knows that if you heat certain substances enough, they physically weaken, and melt, but some can stay strong or become stronger. When the saturation bar (due to heat) stars filling up (let's say, it acts up between 80% and 100% of the part's heat tolerance), joint strength and crash tolerance for parts with low resistance start going down and they become increasingly wet noodle, increasingly easy to break something off if it is impacted or if a high powered engine suddenly fires at full throttle. Health doesn't drain away in this case, however it adds a new dimension to "Deadly Reentry."

Heat (Reflectivity)

Certain heatshields work by being mirrors and not sweaters or ablators. (See: Icarus ship in the Sunshine movie.) A shield in this case is ideally only useful for reflecting light and heat from a star, and would be appropriate for the likes of Parker's Solar Probe. If appropriate and if KSP allows, this may be as simple as giving the part an emissiveConstant value > 1 so that it's exceptionally radiative, and values for the keys concerning insulation which will lessen the part's ability to exchange heat with other parts. If I have the right image, a mirror heatshield is very slow to absorb heat and very quick to emit or reflect heat. However, it should not allow to be used as a cheaty new form of radiator or reentry-rated heatshield. This may easily be done by giving it a very low dynamic pressure rating (as in deployable antennas).

Cryo-Hazard

A big one that's been sorely overlooked by Squad.  Parts (including kerbals) should have a defined lower temperature limit (skin and internal, not too far from Kerbin's ambient temperature of roughly 290K). If the ambient temperature (especially on splashdown, as in cryogenic seas) is extremely far below these limits, the part will suffer module failure or instantly shatter. Module failures here may possibly be unfixable unlike from debris impact. Parts that have extreme lower limits ideally should not also have good overheat resistance. Thermal gradients become serious business.

Visualization: There's no special effect to add here.

Relativistic Speed Impact

This one only becomes important to vessels using reaction engines to travel interstellar. As your ship reaches speeds measured in fractions of c, you face the debris field mechanic in a different and more aggressive way-- a constant rain of micrometeor impacts, which brings relevance to whipple shields in KSP. The faster you go, the harder you're hit by even the tiniest of objects, and the more frontal surface area you have, the more impacts and DPS you have to face. The more you have to face will add up to saturation from relativistic impact forces. If your frontal surfaces start saturating, their health chips away, so you'll have to watch your cruise speed, buff the shield somehow, or add ablative layers.

Whipple shield parts would have the unique property of having resistance to the relativistic virtual masses that fire at it during these speeds. Any other parts, if struck by a single relativistic virtual mass object can be blown off or melted, not being recognized as able to withstand it. Whipple shield parts would be expected to come not only in the form of frontal shields, but a suite of modular pieces like stock structural panels so that you have plenty opportunity to get creative with your armor design.

Visualization: The frontal surface of your ship could be peppered by little flares representing explosions of the tiny masses on impact. Some heat could be picked up as a side-effect. This is not necessary at all but only for a hint as to where you're being hit and could be switched off by default.

...

Documentation

I was asked by @ValiZockt to produce documentation for stats that would be immediately important in the VAB info window or the PAW. So I created it. OneDrive link.

I'll add concept writing for configuration options for planets later, but these options near-entirely borrow from how Kopernicus' HazardousBody module works. This module can already assign heat zones to planets via: altitude + latitude + longitude curves, grayscale texture (heat map), biome filters.

 

 

Edited November 4, 2020 by JadeOfMaar

[taniwha]

This is quite an interesting idea. I can see the consequences fitting in nicely with some of my plans for EL (part refurbishment/repair).

Also, as a reminder: overheating can cause permanent weakening as well as temporary weakening, depending on the material in question. Eg, the hardened steel can lose its temper and become soft (or is it brittle? Either way, those sewing pins I overheated when I was a kid were trivially easy to bend and break).

[hemeac]

When I was reading your previous post about corrosion, I was reminded of the rust/dirt maps used by Transport Fever to indicate the spots that the vehicles start to show their age over time. https://www.transportfever2.com/wiki/doku.php?id=modding:resourcetypes:mtl

Edited October 31, 2020 by hemeac

[WarriorSabe]

For debris, I wouldn't use random vectors - it's generally directional.  Damage would scale with the vector difference between current velocity (orbital frame) and circular orbit velocity. The raycast should come from this vector as well, but for simplicity it should come from the prograde direction I think - that way an SAS hold can be used. During railwarp it'd just remember the orientation from when it entered, the way Kerbalism does for solar panels.

I also wouldn't treat them like impacts at all - it'd be thousands of micro-impacts, too many to treat as individual ones. It'd just be a general abrasion, like by a sandblaster

[taniwha]

1 minute ago, WarriorSabe said:

I also wouldn't treat them like impacts at all - it'd be thousands of micro-impacts, too many to treat as individual ones. It'd just be a general abrasion, like by a sandblaster

Yeah, maybe an orthographic projection of the vessel in that direction and any exposed parts suffer "hits" based on visible area and micro-fod density.

Could use a part id as the pixel color in the projection (much like Blender does for its selection logic)

[WarriorSabe]

Just now, taniwha said:

Yeah, maybe an orthographic projection of the vessel in that direction and any exposed parts suffer "hits" based on visible area and micro-fod density.

Yeah, Kerbalism does a raycast for solar storm shadow shielding, which is basically the same thing but with a different direction vector and effect, so it should be doable

[taniwha]

The orthographic project is effectively NxM raycasts done for you by the GPU, and the pixel colors tell you what, if anything was hit. Then it's just a matter of counting the pixels of each color.

[fatcargo]

To add my two cents, the visual damage can be done with code adapted from conformal decals mod . This way all impact can accumulate on surface and fit more or less nicely with surface. Oh and also this can add challenge to solar powered rovers on celestial bodies with dusty atmosphere (Opportunity rover survival challenge).

As for impacts in interplanetary space, it can be expected to take craft cross-section area into probability calculation, but not all impact vectors point in direction of travel. There can always be impact from any direction and i don't know of any analysis / scientific paper describing distribution of matter in our solar system that can be used as starting point to make those calculations.

I can only tell that the angle difference between impact vector and direction of travel does decrease as craft travels through space if its speed is approaching the average speed of particles defined for that particular volume of space.

For example, in case of planetary rings, you can be fairly sure that particles travel in single plane and in same direction as it parent body rotation (i did say "fairly sure" since i'm not an astronomer). If you travel through them above their average speed, they will strike the craft "on the front".

Edited October 31, 2020 by fatcargo

[taniwha]

Rings have thickness, so the particles will have some motion normal to the ring's plane, but the speed will be quite low (proportional to the thickness/diameter * orbital velocity). There's likely to be some radial motion, too, but that will be quite low. Thus, yeah, ring particle velocity relative to planar circular orbit velocity is probably negligible except maybe in the vicinity of small moons stirring up the ring.

I'd say that any impact vectors will form a normal distribution around the vessel and ring relative velocities with a very tight sigma. Then the imacts could be calculated by multiplying that distribution by the local particle density and taking the part's surface normal into account (much light lighting where the particle shower is the light).

[WarriorSabe]

30 minutes ago, taniwha said:

Rings have thickness, so the particles will have some motion normal to the ring's plane, but the speed will be quite low (proportional to the thickness/diameter * orbital velocity). There's likely to be some radial motion, too, but that will be quite low. Thus, yeah, ring particle velocity relative to planar circular orbit velocity is probably negligible except maybe in the vicinity of small moons stirring up the ring.

I'd say that any impact vectors will form a normal distribution around the vessel and ring relative velocities with a very tight sigma. Then the imacts could be calculated by multiplying that distribution by the local particle density and taking the part's surface normal into account (much light lighting where the particle shower is the light).

I don't think you'd even need to use the surface normal; if you can get the parts' projected area via raycast that'll do the job for you.
And, yeah, while assuming the particles are in a circular orbit may not be the most accurate, it should be accurate enough. As for direction though, I vote that we fudge that and pretend it's coming from prograde (but still use the relative speed given the correct velocity vectors) so that you can use an SAS lock to align yourself with it.

Edit: another thing that just came to me, the dps would actually be proportional to the cube of relative velocity - not only is each particle imparting more kinetic energy by the square of velocity, you're running into more of them as you plow through faster

Edited October 31, 2020 by WarriorSabe

[taniwha]

1 hour ago, WarriorSabe said:

I don't think you'd even need to use the surface normal; if you can get the parts' projected area via raycast that'll do the job for you.

A glancing blow will generally produce less damage than a direct hit.

1 hour ago, WarriorSabe said:

Edit: another thing that just came to me, the dps would actually be proportional to the cube of relative velocity - not only is each particle imparting more kinetic energy by the square of velocity, you're running into more of them as you plow through faster

Good point Yeah, it's probably cubed. While it may be more, I have my doubts and as a first approximation (which is all that's needed, really), cubed is plenty good enough.

[ValiZockt]

Very cool concept! What also came into my mind is the celestial bodies pressure. Currently the atmopsheric pressure of  a planet doesn't affect that much. Over time pressure could add to the parts overall stress (saturation).

[Clamp-o-Tron]

1 minute ago, ValiZockt said:

Very cool concept! What also came into my mind is the celestial bodies pressure. Currently the atmopsheric pressure of  a planet doesn't affect that much. Over time pressure could add to the parts overall stress (saturation).

Or perhaps even make the "pressure limits" in the difficulty settings matter. Right now parts only break if under 1/2 a km of water. It would be cool if some of them just burst on Eve or Jool.

[taniwha]

Just a reminder that at "reasonable" pressures (eg, Eve surface), it's the pressure difference between inside and outside (eg, a habitation unit) that matters, not the absolute pressure (most materials are in the GPa range for strength). 95bar is "only" 1330psi, and hydraulics run higher than that.

If parts are breaking under 1/2km of water but not on Eve, then either Eve's pressure is too low, or something's not right in KSP (1/2km under water on Earth (or Kerbiin) equates to about 50atm pressure: approximately 1atm/10m of depth)

Even 1km depth is reasonable. It's when you get to 11km that things become unreasonable

[JadeOfMaar]

2 hours ago, taniwha said:

1/2km under water on Earth (or Kerbiin) equates to about 50atm pressure:

That sounds about right. Parts by default have a pressure limit of 40atm. Judging by @Clamp-o-Tron's statement, they haven't learned yet that:

• Due to Eve's SL pressure, the undersea pressure scales faster, so parts will crumble at a lesser depth.
• Since Jool lies about its SL pressure in the Tracking Station, it will destroy you before you reach the kraken at -250m altitude. Jool's SL pressure is actually 50+ atm.

[Clamp-o-Tron]

24 minutes ago, JadeOfMaar said:

That sounds about right. Parts by default have a pressure limit of 40atm. Judging by @Clamp-o-Tron's statement, they haven't learned yet that:

• Due to Eve's SL pressure, the undersea pressure scales faster, so parts will crumble at a lesser depth.
• Since Jool lies about its SL pressure in the Tracking Station, it will destroy you before you reach the kraken at -250m altitude. Jool's SL pressure is actually 50+ atm.

I will eat my hat. I have, though, had parts go puff at fairly low depths underwater. I'm on FAR though, so it might not count  .

[taniwha]

29 minutes ago, Clamp-o-Tron said:

I will eat my hat. I have, though, had parts go puff at fairly low depths underwater. I'm on FAR though, so it might not count  .

I use FAR, too (though I haven't been underwater for a while), but I'm pretty sure FAR worries only about dynamic pressure so trying to do things at speed underwater probably doesn't go well. I will have to experiment.

[Clamp-o-Tron]

14 minutes ago, taniwha said:

I use FAR, too (though I haven't been underwater for a while), but I'm pretty sure FAR worries only about dynamic pressure so trying to do things at speed underwater probably doesn't go well. I will have to experiment.

It was actually a command pod with a few parts clipped into it in just the right way, so it sank at like 15 m/s.

[WarriorSabe]

1 hour ago, JadeOfMaar said:

Due to Eve's SL pressure, the undersea pressure scales faster, so parts will crumble at a lesser depth.

The SL pressure doesn't increase the rate at which pressure builds underwater, only the value it starts from. The rate of pressure buildup is driven by the 70% higher gravity and 50% denser oceans, which account for the majority of the crush depth reduction.

[taniwha]

Yeah, Eve's SL air pressure is simply the start offset of the undersea pressure.

[fatcargo]

How is buoyancy affected by this ? Is it even considered as a sideffect of calculations ?

I'm not mentioning it in objective headspace since i have waited long for someone to solve this problem. There was an effort to fix it, but it required adding extra module/field in part cfg and manually tweak the value of each part. You can see this method got nowhere. I did try for several times to build a combination of quadcopter and a bathysphere that was winched up and down on a KAS cable. It worked to some depth (below cable limit) until the kraken, after which cable physics stopped working. The bathysphere had a small module {} added to a cockpit part to artifically add/remove mass. It looked as if when buoyancy forces were excessively different among parts on bathysphere, hell broke loose (only a modified cockpit had its mass changed, rest of part were untouched).

Edited November 4, 2020 by fatcargo

[JadeOfMaar]

@fatcargo The first and best thing to do is to manipulate these:

// passive undeclared keys and values
PART
{
	buoyancy = 1 // dimensionless (0 ~ 1). do not exceed 1
	maxPressure = 4000 // in kPa
}

All parts have these values by default, and so, have maximum buoyancy (before what other calculations are applied like mass-volume ratio? which cause some parts to still sink in spite of this or still float when they should sink). Angel-125 has a solution for buoyancy and pressure limits already in his Buffalo/Guppy rover.

[JadeOfMaar]

On 10/31/2020 at 1:32 AM, JadeOfMaar said:

Documentation

I was asked by @ValiZockt to produce documentation for stats that would be immediately important in the VAB info window or the PAW. So I created it. OneDrive link

I just produced this bit of documentation and came up with two new aspects while doing so:

• Reflectivity (we have ablator and sweater type heatshields, but what about polished mirror heatshields?)
• Cryo-Hazard (exposure to extreme cold, such as splashdown in LqdNitrogen).

[fatcargo]

21 hours ago, JadeOfMaar said:

@fatcargo The first and best thing to do is to manipulate these:

// passive undeclared keys and values
PART
{
	buoyancy = 1 // dimensionless (0 ~ 1). do not exceed 1
	maxPressure = 4000 // in kPa
}

All parts have these values by default, and so, have maximum buoyancy (before what other calculations are applied like mass-volume ratio? which cause some parts to still sink in spite of this or still float when they should sink). Angel-125 has a solution for buoyancy and pressure limits already in his Buffalo/Guppy rover.

Thanks for the link, but beyond adding own modules to add ballast management and defining buoyancy for its own parts, it really does not address the issue en masse. There is still no clearly defined method to derive required parameters from part itself. The  forum post i linked to does discuss about this, alas without definitive solution. Hence my post here. I'm hoping not to have hijacked (too much) of this thread to discuss this.

[fatcargo]

Hoping to reignite the discussion (even by going slightly OT again) , i've looked at Modular Flight Integrator which is written as VesselModule that manages part aerodynamics and heating model.

Link:

I assume it is designed only for crafts moving in air medium (ie low Reynolds number), but i'm not entirely sure if it can do other things, like modeling part behaviour in liquid medium (ie high Reynolds number).

If MFI can't be used to model part motion in liquids, is it possible to write a separate VesselModule plugin that can override stock fluid mechanics in KSP and perform its own calculations ?

In the above linked old post discussing the "Analysis of the buoyancy of parts and how to improve things" it has in OP mention of

Quote

The game uses a formula which, as far as I can tell, involves basic part mass, density/mass of resource(s), volume and funny enough, sometimes surface area instead of volume.

If this still holds true (and i assume this wasn't addressed by Squad since their first release), a separate plugin to tackle this would be welcome.