Hatch obstruction distance.

[RogueMason]

So, I found a pretty significant problem with hatch obstruction. After extensively testing some base modules on the runway at KSC and deeming them fit for use (tests included the ability of a Kerbal to get into and out of these bases), I've now found that I can't get anyone out of them. I thought perhaps the ladders I'd placed were the root of the problem. Nope, the ladders are fine, hence my deeming of fitness from my tests.

However, it turns out that the ground is the culprit. The ground. That surface a metre or two beneath the hatch! That's what's stopping my crew from getting out of my base modules! I've found this happening on Mun, Minmus, and even Kerbin (excluding the runway, apparently ), so it's a good bet that it's also going to happen to the base module that I've already put on Duna, which fortunately is unoccupied at the moment.

How do I know it's the ground? I got a test base, turned on hack gravity, and a Kerbal was able to escape once the base floated up a bit from the launch pad, even just a tiny bit further above the ground than the legs permit. Ugh.

This shouldn't happen. Those modules have more than enough room for Kerbals to wander around beneath them, so the hatch obstruction distance needs to be reduced so that things things a metre and a half away don't actually interfere when they blatantly shouldn't be doing so. Could this happen, please? I'd imagine it's a pretty small thing to deal with.

Meanwhile, I'm going to go and jury rig some stuff to get these poor souls out of trouble

[klgraham1013]

Yeah. This should be fixed. I've run into issues with it as well.

[sumghai]

Strictingly speaking, hatch obstruction "distance" is a misnomer in the context of KSP.

Based on my experience making space station modules and crew pods, each command pod has an invisible "airlock" cuboid collider, whose bounds determine the region a Kerbal will spawn on EVA. As such, what's happening is that the ground is intersecting with this airlock collider, hence the hatch obstruction error messages.

In theory, it should be possible to reduce the dimensions / volume of a given command pod's airlock collider, but I'm not sure what averse effects may be introduced if said airlock collider has a smaller volume compared to the Kerbal itself.

[Sampa]

Strictingly speaking, hatch obstruction "distance" is a misnomer in the context of KSP.

Based on my experience making space station modules and crew pods, each command pod has an invisible "airlock" cuboid collider, whose bounds determine the region a Kerbal will spawn on EVA. As such, what's happening is that the ground is intersecting with this airlock collider, hence the hatch obstruction error messages.

In theory, it should be possible to reduce the dimensions / volume of a given command pod's airlock collider, but I'm not sure what averse effects may be introduced if said airlock collider has a smaller volume compared to the Kerbal itself.

Why have an airlock collider at all? By the way things look now, the airlock SHOULD be internal to begin with! I agree with the OP, this needs to be changed!

[sumghai]

Why have an airlock collider at all? By the way things look now, the airlock SHOULD be internal to begin with! I agree with the OP, this needs to be changed!

As I've stated clearly in my previous post, the airlock collider determines where the Kerbal will spawn on EVA, relative to the outside of the pod.

If the airlock collider is put inside the body of the pod or omitted, KSP will not know where to spawn the Kerbal, and will also throw a hatch obstruction error.

EDIT: the airlock collider also determines the location of the hatch. Putting it inside the pod means that the user will never be able to click on it.

Edited February 12, 2015 by sumghai

[Brotoro]

This is a problem that is new with version 0.90. I have ships that kerbals could exit from perfectly well in previous versions that no longer allow the kerbal to exit (although they can get IN through the hatch)... And, yes, it's the ground that is the problem when it shouldn't be. I think Squad may have messed something up when they were reworking the ladder code recently.

Good thing Squad did the 0.90 beta after they messed with this feature so they can get it fixed before their release version. Just think how bad things would be if the tried to modify some existing features (or, worse yet, add new features) without doing a beta release before 1.0 so we could help them find these problems.

[sumghai]

This is a problem that is new with version 0.90. I have ships that kerbals could exit from perfectly well in previous versions that no longer allow the kerbal to exit (although they can get IN through the hatch)... And, yes, it's the ground that is the problem when it shouldn't be. I think Squad may have messed something up when they were reworking the ladder code recently.

While I would probably agree that there may have been changes to ground colliders that interfere with airlocks, this isn't related to the ladder code rework - ladders are a separate class of interactive invisible colliders altogether, whose bounds and transforms determine what direction a Kerbal will climb along.

(ASIDE: As a modder, I've found nearly all command pods have the airlock collider paired up with a corresponding ladder collider. If there is only the airlock, the Kerbal will spawn on EVA, and immediately drift away because there is nothing to grab on to).

[Sampa]

I've found nearly all command pods have the airlock collider paired up with a corresponding ladder collider. If there is only the airlock, the Kerbal will spawn on EVA, and immediately drift away because there is nothing to grab on to.

Do you think this would work for fixing the issue with the CSS airlock?

[Brotoro]

OK. I only suspected the changes to the ladder code because this bug first showed up for me after Squad said they changed the ladder code. They said nothing about changing ground colliders. But you may well be right.

[Sampa]

I hate it when he's right... (jk, Sumgai)

[Brotoro]

Here's the ship that has the problem (but which used to work fine), a rover/plane from my Longterm Laythe series: