Part overheating in cargo bays + Approach to solving randomly overheating parts in time warp

[funk]

At first: I know that I'm playing with a bunch of mods, but I'm sure it concerns stock as well, therefore I'm posting here.

So let's start with the issue:

A lot of players reported some bugs with overheating parts in cargobays while flying with (space)planes. Perhaps it's the same bug with fairings. Here is my attempt to explain what's happening:

After this explanation (

So taking a step back, what we really need is a solution that hits the 'predictability' zone, where if something looks like it should be contained, it should be contained. The emphasis is on the word 'looks' there, you'll see why in a bit.

Here's how we tackle the problem of detecting containment:

* The cargo bay first detects all parts inside a spherical radius that entirely encloses it. Those are the nearby parts that will be tested. This detection method is independent of vessel relationships, being solely dependent on the position of parts. A lot of the parts in this first list will be outside the bay, and that's fine. We just do this to avoid having to iterate through every single part in every single vessel.

* Next, we compute a centroid point for the part, based on its renderer bounds. That centroid is then a product of the part's visual mesh, not dependent on attachment position, center of mass or even colliders. It's the visual center of the part. This is now our reference to test the part in a visually accurate way.

* We then rule out any part whose centroid lies outside the merged visual bounds of the cargo bay itself. This is just a sanity check to avoid performing needless calculations on parts that are clearly outside the cargo area already. The merged bounds are a bounding box we calculate off all renderer bounds, to encompass the entirety of the part. This is necessary as cargo bays (or fairings) can potentially be made out of multiple objects, meaning multiple renderers, and multiple bounds, hence the need to merge them.

* So, we now end up with a much shorter list, comprised of nothing but parts which are in a reasonable range to warrant further testing. Now it's time to really check whether we are in or out of the bay.

[a quick note here to explain that all this is done with the assumption that the bay doors are closed. If they are open, no part would be considered as shielded by that cargo bay, so that's something we can safely not worry about]

* The test itself is simply a raycast, from each part's visual centroid to the bay's own centroid. Now, the thing with raycasts is that they can (and do) hit any parts along the way, and we don't want that. We are just concerned with the bay itself and each part, in isolation. This testing then is done against only the bay's own colliders.

* From this we can now determine if a part is inside or outside of the bay with a pretty decent level of accuracy. If the raycast reaches the bay centroid without hitting anything, we can be quite sure it's inside the bay. If it hits anything, it must by necessity have been a wall of the bay itself, and therefore must be outside the bay.

Now, you may be wondering then, what of the open sides of the bays then? Surely there is no wall there. Indeed there isn't, but that doesn't mean we can't add a 'wall' that only exists to catch a raycast. Trigger type colliders will do just that in fact, so for all testing purposes the open ends of the cargo bays are effectively closed. This still lets you pass though the open spaces normally, but catches the raycasting so we have a fully enclosed volume which defines the cargo bay.

) the game determines a part as occluded in cargo bays after the following tests:

1. Is the parts reference point within the sphere of the cargobay? The radius of the sphere can be found in the cfgs: MODULE[ModuleCargoBay] -> lookupRadius. It seems to me, that the origin is the center of mass of the cargo bay, because the radius has mostly the same absolute value as the y-axis-value of the attachment nodes.
   
2. If 1. is true the part has to have a clear line of sight to the origin of the sphere, no other parts are accounted for.
   

If both tests are true the part is occluded if the cargo bay is closed.

Now the problem is, that in some cases the lookupRadius is too small. We've to consider the absolute value of a 3-dimensional vector from the origin of the sphere to the farest point inside the cargo bay.

Here you can see what happens under test 1. for the large Mk2 cargo bay (pay attention that this is only a 2-dimensional circle, KSP uses a sphere):

Javascript is disabled. View full album

As a result there are two solutions for this:

• don't attach parts near to the edges of the cargo bays
  
• increase lookupRadius in the configs
  

During my tests I've recognized another thing, which might lead to the warp bug:

It seems that either the sphere of the cargo bay or the reference point of the parts or the collider of the cargo bay changes depending on the orientation of the craft. In the pictures below I`ve built a craft with clipped intakes near to the cargo bay. On the runway and at the most angles I could open and close the cargo bay without problems. But at an pitch angle of ~30° the game decided that the intakes are suddenly occluded after closing the cargo bay.

Javascript is disabled. View full album

The observations above and the jumping flux values (already mentioned in other threads) lead me to assume that the jumping values are just a symptom of undefined states for parts, either occluded or not or non-constistent states between two iterations or when (un)packing a craft for default warp. Possible that physics warp causes the game to skip some iterations?!?

For the last assumption pls keep in mind, that I'm not a programer and I've no clue how KSP works internally. So perhaps I'm wrong with the warp bug, but the spheres are partly wrong for sure.

edit: I forgot to mention, that the conv. flux and rad. flux sometimes disappears for non-occluded parts between mach 1 and mach 2. Not sure why...

Crafts for testing:

Mk2-cargobay-battery test I

Mk2-cargobay-intake test II

Edited August 5, 2015 by funk

[yorshee]

I assume this happens with service bays too? If it does then it explains the annoying glitch I've been having with them.

[funk]

I assume this happens with service bays too? If it does then it explains the annoying glitch I've been having with them.

It could affect fairings, too. I assume that the spheres for fairings are procedural, so if they are stingy, parts at the edge aren't occluded or in superposition...

edit: To be sure enable thermal and aero data in the debug menu (alt+F12) under physics and compare parts that behave normal and not through alt+right-click.

Edited July 31, 2015 by funk

[Michaelo90]

What about overheating parts when they have no drag with the right-click menu? I have two gigantors mounted on a 2.5m ore tank inside a mk 3 cargo bay, and they seem to slightly overheat at the end of reentry, when all other parts have lost their heat bars. They never seem to overheat on ascent, even when going so fast the rest of the plane explodes. The gigantors are never close to exploding, but they seem to lose a lot of efficiency. Does anyone know what causes this and how to fix it?

[funk]

What about overheating parts when they have no drag with the right-click menu? I have two gigantors mounted on a 2.5m ore tank inside a mk 3 cargo bay, and they seem to slightly overheat at the end of reentry, when all other parts have lost their heat bars. They never seem to overheat on ascent, even when going so fast the rest of the plane explodes. The gigantors are never close to exploding, but they seem to lose a lot of efficiency. Does anyone know what causes this and how to fix it?

I´m not sure, but usually your velocity is higher during reentry than ascent. Further you won't have your ore tanks filled up, so the thermal mass of the tanks is low. And last the panels have low maximum temperature, I assume that the bars are enabled when the internal temperature reaches a determined per cent of the max value. So this doesn't mean they're near to explosion, but if you can provide a craft file and a use case, this would help a lot!

Edited August 1, 2015 by funk

[Michaelo90]

True, the panels do have a low max temp. I guess heat is transfering from the tank in front of the cargo bay, through the ISRU and the ore tank, to the gigantors. The problem isn't the explosion risk, it's that the panels barely produce any electricity when they're hot. I guess I need some radiators.

[Claw]

This kind of digging around helps a lot. Nice post!

[funk]

For further tests and descriptions in this thread I will define occlusion-bug as a faulty result of the occlusion tests, mentioned in the OP. For example a part is occluded , but shouldn't or vice versa. After investigations so far the occlusion bug is caused by:

1. Incomplete spheres of the cargo and service bays and probably fairings (has to be tested). I'm working on a MM-Patch to increase lookupRadius of the bays to reasonable values.
   
2. Inconsistent or non reliable points of reference for parts which are inside the spheres.
   
3. Problems with colliders of the bays
   

I had some issues with a spaceplane a while ago. Parts suddenly explode during reentry due to overheating. Usually I'm using 4x physics warp during reentry. I had to descent with open cargo bays (which was suprisingly easy:)). After the tests above I decided to load the craft again to investigate the issues. I've successfully rebuilt a simplified, but similiar stock craft to reproduce the super heating bug (expression stolen from Claws awesome stockbugfix thread,thx), which describes suddenly exploding parts during 4x-physics warp. Test-Craftfile

The following results and questions showed up during testing:

occlusion-bug:

• the occlusion tests are proceeded once, when the cargo bays have been closed or when the vessel is leaving non-physics warp. That means a part can be occluded before entering non-physics warp, but isn't after leaving non-physics warp.
  
• occlusion, especially at the edges of the spheres, depends on the orientation of the craft. It will have to be tested/explained, if this is caused by a changing reference point of the tested part or if the colliders or search spheres of the bays are changing.
  
• The MK3 Cargo Bays may have some problems with their colliders, I could occlude parts, which had at least 1.25m distance between their own colliders and the colliders of the bays.
  

superheating-bug (all regarding my testcraft):

1. occurs during 4x-physics warp, if a child part is occluded but its parent part isn't. Doesn't effect every occluded part.
   
2. the parent part has to have a few child and grandchild parts.
   

My hypothesis is, that occlusion causes the formula/iteration for cond. flux to crash. Because this doesn't effect every occluded part there have to be more indications to determine what's going on, but at this point we will need more information... anyone ideas?

Meanwhile there is a workaround for it:

1. search near the exploding part for a part which is occluded, but its parent isn't.

2. move the ship around (reorientate) and open->close the bay nearby or enter->leave non-physics timewarp

3. check, that the part isn't occluded anymore, else try 2. again in another orientation

Edited August 5, 2015 by funk

[funk]

As a first step, I've written a MM-patch, it can be downloaded here (Copy to /Gamedata, ModuleManager is needed). Now, all parts inside the bays should be occluded. I would appreciate some testing by other players to preclude side effects.

@Claw: Feel free to include it to your bug fixes, if you like.

For fairings I've done some tests, but couldn't find any issues. They have ModuleCargoBay in their config files and the lookupRadius seems to be to small, but I suppose, that occlusion ist determined by ModuleProceduralFairing somehow. I've tested with the craft below and all parts, which where outside the fairing have drag and conv.flux and all parts inside have not.

Javascript is disabled. View full album

Edit: Meanwhile, during playing, I've recognized the occlusion bug with fairings, too.

Edited October 17, 2015 by funk

[yorshee]

Sweet! I'll give it a go tomorrow.

[fireblade274]

I just had a part randomly overheat in space; I believe I was using physical time warp, and it was really weird. T'was not in the cargo bay. I'm just happy it didn't destroy my entire ship or corrupt my save file

https://www.dropbox.com/s/nlddpy28do9wes3/2015-08-04_00001.jpg?dl=0

[Grossbeer]

Awesome. I guess this fix wont work with Crafts already in Space, right?

[funk]

Awesome. I guess this fix wont work with Crafts already in Space, right?

It doesn't seem to. I've already had one ship in orbit before installing the fix, which parts have overheated inside the cargo bay during reentry.

[fireblade274]

Yep now im getting an over-heat inside the cargo bay this time; I tried placing a radial decoupler inside the cargo bay and placed a jumbo fuel tank on that while editing my ship. shortly after launch (about 1 min) the radial decoupler explodes.. I'll try the patch mentioned and let er body know if it worked for me. Its like everywhere I turn there's a bug (this one is not that bad at least)

- - - Updated - - -

Yeaa the bug fix did not work for me. Launched from a new vessel, t'was not in orbit

Odd hud issue showing decoupler overheating, to left of screen by stages https://www.dropbox.com/s/a6hqbtldnen13r5/2015-08-05_00008.jpg?dl=0

Tank configuration in cargobay https://www.dropbox.com/s/p36t7zo72mlpx7k/2015-08-05_00009.jpg?dl=0

All stock game, with Claw's stock bug fixes, and that one fix mentioned earlier (that sadly did not work and im removing it)

If it helps anyone (it is a big ship, sorry. Not complicated inside cargo bay tho)

Persistent file https://www.dropbox.com/s/n09fmnup907fbxx/persistent.sfs?dl=0

Craft file https://www.dropbox.com/s/giuqrvisjgfbl4t/SP333%20Fuel.craft?dl=0

Edited August 6, 2015 by fireblade274

[Grossbeer]

I can conform that the fix doesent work for me. I have a Spaceplane with some mystery goos and material bays inside a mk2 Cargobay small and they overheat very very fast.

Playing with Kerbal Construction Time SSTOs are very important, so this bug really annoys me.

How do parts overheat? if i edit the goo container to not have any drag, could that be a temporary solution for the problem?

EDIT:

What i did notice, when editing a save file and looking at a specific crat which has a cargobay, i cant find any lookupradius or drag sphere of the cargobay part. The only modules on the parts are:

PART			{
				name = mk2CargoBayS
				cid = 4294568996
				uid = 1620959657
				mid = 4223273479
				launchID = 107
				parent = 0
				position = 0,-2.18750166893005,2.60770491422591E-07
				rotation = 0,0,0,1
				mirror = 1,1,1
				symMethod = Radial
				istg = 0
				dstg = 0
				sqor = -1
				sepI = 0
				sidx = -1
				attm = 0
				srfN = , -1
				attN = top2, -1
				attN = bottom2, -1
				attN = top, 0
				attN = bottom, 3
				mass = 0.25
				temp = 248.415802390051
				tempExt = 249.804332355903
				expt = 0.5
				state = 1
				connected = True
				attached = True
				flag = Squad/Flags/default
				rTrf = mk2CargoBayS
				modCost = 0
				EVENTS
				{
				}
				ACTIONS
				{
				}
				PARTDATA
				{
				}
				MODULE
				{
					name = ModuleAnimateGeneric
					isEnabled = True
					status = Locked
					animSwitch = False
					animTime = 1
					animSpeed = 1
					EVENTS
					{
						Toggle
						{
							active = True
							guiActive = True
							guiActiveEditor = True
							guiIcon = Toggle
							guiName = Open
							category = Toggle
							guiActiveUnfocused = True
							unfocusedRange = 5
							externalToEVAOnly = True
						}
					}
					ACTIONS
					{
						ToggleAction
						{
							actionGroup = None
						}
					}
				}
				MODULE
				{
					name = GeometryPartModule
					isEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
					}
				}
				MODULE
				{
					name = FARAeroPartModule
					isEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
					}
				}
				MODULE
				{
					name = FARPartModule
					isEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
					}
				}
			}

is it possible that the functionality in the original part cfg is not applied on constructed ships or are they simply not inside the save file?

cheers

Edited August 6, 2015 by Grossbeer

[funk]

Yep now im getting an over-heat inside the cargo bay this time;...

I'll have a look at your craft. First thing I can imagine, is that you use the claw, even with the stockbugfix, its causing issues. Second thing I was mentioning earlier, is that there might be problems with the colliders especially the Mk3 ones. So that the second test mentioned in the OP isn't accurate. I'll investigate...

I can conform that the fix doesent work for me. I have a Spaceplane with some mystery goos and material bays inside a mk2 Cargobay small and they overheat very very fast.

Playing with Kerbal Construction Time SSTOs are very important, so this bug really annoys me.

How do parts overheat? if i edit the goo container to not have any drag, could that be a temporary solution for the problem?

EDIT:

What i did notice, when editing a save file and looking at a specific crat which has a cargobay, i cant find any lookupradius or drag sphere of the cargobay part. The only modules on the parts are:

is it possible that the functionality in the original part cfg is not applied on constructed ships or are they simply not inside the save file?

cheers

I don't think that removing drag helps with that. Perhaps anyone familiar with heat mechanics can explain how it works. For the lookupRadius: I suppose it's been used from the config files, but this would mean, that the updated configs should work for existing crafts. Maybe I'm wrong here. Can you provide a craft file, pls?

[Grossbeer]

Here is the Craft file:

http://wikisend.com/download/388334/Hawk I Cargo test.craft

Althou i have several Mods installed, most notably: SETI (for the radial Science Experiments) and FAR.

The Equipment is very centered around a Beam inside the Cargo bay, so there schould not be a Problem with the Sphere, so im kind of clueless.

cheers

[funk]

Here is the Craft file:

http://wikisend.com/download/388334/Hawk I Cargo test.craft

Althou i have several Mods installed, most notably: SETI (for the radial Science Experiments) and FAR.

The Equipment is very centered around a Beam inside the Cargo bay, so there schould not be a Problem with the Sphere, so im kind of clueless.

cheers

I may be wrong, but doesn't FAR occlude all parts within the voxel hull? There was a bug regarding overheating parts with FAR, so be sure you're using the last version...

[funk]

I've done some more tests and found some problems, which seem to be related to the raycast between the tested part and and the centroid of the bays. It's always the same behaviour, a part overheats, because it's occluded while its parent isn't. There seem to be gaps in the colliders especially at the top and bottom nodes of the bays. Due to my patch the search radius is increased, so it can affect more parts.

[Claw]

For those of you whom seem most stricken by this and not opposed to add-ons, give this a try: http://forum.kerbalspaceprogram.com/threads/97285-KSP-v1-0-4-Stock-Bug-Fix-Modules-%28Release-v1-0-4b-2-1-Aug-15%29?p=2153984&viewfull=1#post2153984

You're looking for the OverheatFix, which is completely stand alone. I have no test cases available with parts inside cargo bays, but it seems to work pretty well for other cases.

Cheers,

~Claw