Small hardpoint problems

[AlpacaMall]

I'm trying to figure out how the small hardpoint works. I set up the following seven-part test:

(textures from Restock)

Both hardpoints are oriented in different directions. The left hardpoint was placed normally; I put it on the central fuselage, then placed the left fuselage on the other end. The right hardpoint was placed in the opposite orientation; I first placed the hardpoint on the right fuselage, then connected it to the central fuselage. 

What I expected to happen was that the hardpoint on one side will decouple the side fuselage, and the hardpoint on the other side would decouple itself. Instead:

Its larger sibling, the Structural Pylon, also exhibits this behavior.

 

Can someone explain what's happening here? I'd like to keep the hardpoint attached to the central fuselage, but the game doesn't want to let me do so.

[Guest]

Seems like an old issue. There’s a workaround of sorts described here but what a palaver.

https://amp.reddit.com/r/KerbalSpaceProgram/comments/8jgv9b/hey_all_how_can_i_use_a_small_hard_point_or/

Edited May 21, 2021 by Guest

[swjr-swis]

It appears to be a bug that has creeped into KSP along with Unity upgrades. This used to work correctly up to version 1.3.1, see the video.

 

 

There is a year old bug report for this in the bug tracker, showing it's a general problem with at least all radial decouplers, and apparently since 1.8.1. No reaction to it, not even confirmed. But it shows the matter to be a bit more complicated.

https://bugs.kerbalspaceprogram.com/issues/25017

 

EDIT: this is a sneaky little bug. Apparently, it only rears its ugly head when you BUILD A NEW CRAFT in the newer versions. Loading the 1.3.1 craft... all works just fine in both 1.9.1 and 1.11.2. Then I thought of also testing making that same craft from scratch in 1.11.2... and BAM, it detaches in the wrong way.

So it would appear the error is in the part/model definitions, and not the decoupling logic/code.

Test craft 1: https://kerbalx.com/swjr-swis/0-hardpoint-test  (made in 1.3.1, tested also to work correctly in 1.11.2)

Test craft 2:  https://kerbalx.com/swjr-swis/0-hardpoint-test2  (this one created from scratch in 1.11.2, detaches incorrectly!)

Edited May 21, 2021 by swjr-swis
bug report - correction, bug manifests in new craft created in 1.9.1+

[bewing]

10 hours ago, AlpacaMall said:

Both hardpoints are oriented in different directions. The left hardpoint was placed normally; I put it on the central fuselage, then placed the left fuselage on the other end. The right hardpoint was placed in the opposite orientation; I first placed the hardpoint on the right fuselage, then connected it to the central fuselage. 

????

But that's not how you do it. When you place the small hardpoint with default rotation, the lower attachment point (assuming editing in the VAB) is the one that always separates. It doesn't matter which attachment point is attached first.

If you want the hardpoints to stay attached to the central fuselage after decoupling, then you need to attach it so that the "high" end is attached to the fuselage. If that orientation isn't the look that you are going for, then attach the high end to the fuselage, and rotate the part vertically after it's attached.

 

[swjr-swis]

28 minutes ago, bewing said:

If you want the hardpoints to stay attached to the central fuselage after decoupling, then you need to attach it so that the "high" end is attached to the fuselage. If that orientation isn't the look that you are going for, then attach the high end to the fuselage, and rotate the part vertically after it's attached.

Have you tried this? If you attach the hardpoint/pylons directly to the fuselage, regardless of how you rotate it, it will detach from the fuselage when decoupling. They go with the 'payload'. No amount of rotating will change this.

The only way to get them to stick to the fuselage after separation is by first attaching them to what will be the payload, then attaching the craft to the hardpoint as if it were the payload, then reroot the whole thing.

 

EDIT: I have to qualify my statement by saying that this is how it used to work, and what you would expect (always decouple from the striped/explosive side, the side that by default it is radially attached by), at least up to 1.3.1. The way it works since at least 1.8.1 may appear to do what you say... but only because it's bugged. 1.3.1 - it will consistently and predictably separate from the indicated/striped side, sp you can build in reverse and reroot and it stays with the fuselage after separation. 1.8.1 and up - it will ALWAYS separate from the fuselage and go with the payload, regardless of how you build.

Edited May 21, 2021 by swjr-swis
edit

[OHara]

14 hours ago, AlpacaMall said:

The right hardpoint was placed in the opposite orientation; I first placed the hardpoint on the right fuselage, then connected it to the central fuselage. 

If I understand correctly, you must have used the re-root tool at some point,
maybe to make the right fuselage the root part so you could pick up the central core and connect it to the hardpoint,
and then again to make something in the central core be the root.

I usually play KSP version 1.7.3 where that method works as you expected it to.  The first connection made with the hardpoint is the one with the dashed band, and that is the connection broken when we stage the hardpoint.

I was intrigued, so looked into the craft file.  In the section for the hardpoint, there is a line 'srfN = srfAttach, name and ID of the part to which the banded end was attached'

I tried again in KSP version 1.11.2.  When I re-root back to the fuselage, that line in the *.craft file changes to 'srfN = srfAttach, name and ID of my current parent'  So it KSP no longer keeps track of what the banded end is logically connected to. 

So, as the bug-report says, in newer versions of KSP, the hardpoints always detach themselves from the 'root' of the craft.  (So making the right-hand tank the root would work in the particular case you show, but I don't see any workaround that would work for complicated cases.)