Kerbal Space Program

evanrichter wrote:

I just noticed this issue with 1.11. I don't think it existed in 1.10. Scanning arms will prevent kerbals from exiting hatches when placed within a certain range, even when the arm itself isn't placed in front of the hatch. This will happen with any scanning arm, but the size of the arm does affect the range that it will block. My first thought was that the obstruction corelates with the scanning range, but it seems to be more complicated than that. It's possible to block one hatch, but not another, in which case, kerbals will exit via a second hatch if available. This issue is very easy to reproduce: just place a scanning arm near a crew module with kerbals onbard, then try to EVA after launching craft.

This explains a lot. I was having trouble with an airplane with a scanning arm in a cargo bay where it claimed hatches were obstructed when they weren't. The associated weirdness is that I got the message only when clicking "EVA" on the portrait of the kerbal, even though I could still EVA by clicking the cockpit hatch itself.

Here's some additional info from a modder that might provide help to KSP devs about this (I may be guessing about nothing since I can't see the actual code, so maybe this isn't worth anything, but I post it here in case knowing this helps).

As part of calculating the exact terrain height of a geoposition, the kOS mod does a Physics.Raycast with a bitmask that has layer 15 turned on, and all other layers turned off. This is to try to determine exactly where the surface of the terrain polygon is at a given precise latitude/longitude. Through some sleuthing by one of the users getting weird results, we discovered that if you trace the terrain height this routine gives, the terrain height traces a bizzarre phantom spherical bubble around scanner arms. This happens to look like it's exactly the same shape and size as the green glowing preview sphere you can see in the VAB when you click on the scanner arm and tell it to show you the scanner range. Remember that my routine is performing a Physics.Raycast looking only for hits on layer 15. This seems to be behaving as if a sphere exactly the same as the scanner range preview sphere still exists in some form during flight mode, and is using the same layer 15 as the terrain polygons do.

This anecdotal evidence maybe means (again, this is VERY speculative and I realize that humbly) that the check for blocked exit hatches is being fooled into thinking that phantom preview sphere counts as "terrain" blocking the exits.

[email protected] wrote:

KSP lets me EVA through any hatch not blocked by the scanning arm in its parked position, if I click on the hatch directly to get the EVA option.

If I click on the 'EVA' button on the Kerbal portrait, and the first hatch is obstructed, then KSP lies to me and says "All hatches are obstructed". But if I then click on the secondary hatch, and then click EVA on the pop-up, I can EVA just fine.

I didn't know about clicking on the hatch. That's a good workaround until this is bug is fixed.

New Information: Today I discovered that the scanner arm bug also causes solar panels to be incorrectly "blocked from the sun" by the scanner arm even when the scanner arm is emphatically not in the way. Again, I think it's the same problem - the large invisible fake collider sphere around scanner arms is seen as being "in the way" between the sun and the solar panel. The phantom sphere appears to be marked as being part of the "terrain" layer, so the game sees it as a real physical object whenever it is performing raycasts.

This is indeed caused by the SphereCollider created in ModuleRobotArmScanner.OnStart(), affected to layer 15 ("Local Scenery") and used as a trigger collider to detect in-range ROCs through OnTriggerEnter/OnTriggerExit callbacks.
That trigger collider is interfering with many other raycasts/triggers done elsewhere for other features (hatches, possibly ladders too, solar panels and radiator occlusion, etc).

I suspect that the issue here is that since KSP already use all 32 Unity layers for various stuff, there wasn't any free layer to define a specific collision matrix for that feature, and that doing a SphereCast every frame to detect in-range ROCs wasn't done for performance reasons. Still, there are likely other layers than "Local Scenery" that would work for the purpose.

And, for reference, that issue was already there as far back as KSP 1.8.