[BUG] Part will only attach to other part nodes through their top or bottom nodes

[Camacha]

When you attach a part to another part in the VAB or SPH, it will only attach if you use its top or bottom node. You can attach it to any node, including side nodes, but when you try to attach with a side node it will not work.

KSP version 0.90, though I am sure earlier versions have the same issue. It does not appear to be system related, so no logs or specifications.

[vexx32]

AFAIK, there are only two parts which exhibit this behaviour -- the Rockomax node, and the not-Rockomax Micronode. Are there any others? If not, this should probably be submitted to the Bug Tracker as a feedback report; it's not exactly an intended feature, but it's not really a bug either. It's a consequence of having strictly-defined parent and child nodes in those parts... I think. It's been a while since I looked into it.

There may be an existing report on the bug tracker already, but I'm sure it could probably do with a little bit of updating, since this first arose quite some time ago.

[steve_v]

Has always been thus, AFAIK. I had always assumed it was a side effect of the craft file / tree structure...

Now that you mention it, it does feel a bit like a bug.

Damn you for pointing out something that never used to annoy me

[Camacha]

AFAIK, there are only two parts which exhibit this behaviour -- the Rockomax node, and the not-Rockomax Micronode. Are there any others?

I think those are the only stock parts that actually have side nodes, so that would be a no Any modpart with side nodes shows the same behaviour, so it appears it is really a problem with how KSP deals with things internally.

If not, this should probably be submitted to the Bug Tracker as a feedback report; it's not exactly an intended feature, but it's not really a bug either. It's a consequence of having strictly-defined parent and child nodes in those parts... I think. It's been a while since I looked into it.

Hum, ha, it has been a while since I submitted anything. So long even that the bug tracker does not seem to remember me. I think it could use fixing though, as it needlessly complicates certain things.

That is another bug, by the way - current security best practice tells us not to return whether a user is known or unknown. It should tell you that an e-mail has been send if the mail was valid and that is it.

Damn you for pointing out something that never used to annoy me

That is what I do

Edited January 10, 2015 by Camacha

[vexx32]

Ah, yes, I remember well the day xkcd changed my perspective forever... by forcing me to notice how atrocious the kerning is just about everywhere.

I've not looked myself (might do it in a moment), but I wonder if the side nodes actually are any different in the .cfg files in any way? And if so... why that is. If not, then yes, it's part of KSP's code itself, although the only possible reason I can think of for that off the top of my head is to rectify potentially problematic fuel flow situations. If that's the case, this may be an semi-intentional side effect of that in some form.

[Camacha]

I've not looked myself (might do it in a moment), but I wonder if the side nodes actually are any different in the .cfg files in any way? And if so... why that is. If not, then yes, it's part of KSP's code itself, although the only possible reason I can think of for that off the top of my head is to rectify potentially problematic fuel flow situations. If that's the case, this may be an semi-intentional side effect of that in some form.

Top and bottom nodes are usually defined as such and, for as far as I understand, this actually means something. I can imagine it is a side effect of something else, but am pretty sure it can be fixed without causing some inherent issue. I am glad I finally figured out why the hexapoint connectors could act up sometimes, since it was a mystery for me until now and it annoyed me to no end.

node_stack_right = 0.9121535, 0, 0, -1, 0, 0, 1
node_stack_left = -0.9121535, 0, 0, 1, 0, 0, 1

node_stack_back = 0, 0, 0.9121535, 0, 0,-1, 1
node_stack_front = 0, 0,-0.9121535, 0, 0, 1, 1

node_stack_top = 0, 0.9121535, 0, 0,-1, 0, 1
node_stack_bottom = 0,-0.9121535, 0, 0, 1, 0, 1

Edited January 10, 2015 by Camacha

[vexx32]

Judging by that, something in how the game deals with top and bottom nodes differs to how it treats side nodes... :/

Heh, looks like a code fix after all. I wonder if Claw would be interested in investigating that... I'll ask him, hehe.

[Camacha]

Heh, looks like a code fix after all. I wonder if Claw would be interested in investigating that... I'll ask him, hehe.

Please do I checked out some of his other (great!) work and it is not entirely clear to me - is he a modder or does he have ties with Squad?

[vexx32]

He's a modder, haha. He's using those little fixes to get familiar with how modding works, really. They're his first project.

I've been having fun with his fixes for symmetry. Nested symmetry is still a little glitchy, but it no longer borks the editor (and craft file) irreversibly, thankfully. It's also a lt more robust. He does good work.

[PB666]

Its not a bug, if you want to root a part on a given node you have to place it as the last node on the list, and remove, potentially other competing parts, its best to make a new alternative part with new attachment nodes.

[Camacha]

if you want to root a part on a given node you have to place it as the last node on the list, and remove, potentially other competing parts, its best to make a new alternative part with new attachment nodes.

That sounds like complicating things rather than simplifying them For parts that have more attachment points the permutations quickly add up. For the Rockomax parts you would already need three variations, and every one or two nodes adds another one.

[Captain Sierra]

That sounds like complicating things rather than simplifying them For parts that have more attachment points the permutations quickly add up. For the Rockomax parts you would already need three variations, and every one or two nodes adds another one.

There's a mod which adds a hub with 3.75m top nodes and six 2.5m nodes in hex symmetry. Throw that into the mix and things very very complicated.

From what I understand, the last two nodes defined in the .cfg are treated as the 'parent' nodes and the only two a part can attach by. All nodes are fair game when attaching to the part.

Not sure if thats a limitation in the way Unity allows the part tree to work or if its a function of how KSP has set up its part tree. In the case of the latter, its actually fixable on Squad's end.

[Claw]

Heh, looks like a code fix after all. I wonder if Claw would be interested in investigating that... I'll ask him, hehe.

Oh noes, more work for my pile!

---

I haven't looked yet, but my initial guess is that it's set up this way intentionally to help the editor when placing symmetric parts on the nodes. Except that you can't place symmetric parts on the nodes around... So it might be a leftover byproduct of logic to deal with something that wasn't actually implemented.

Even if that isn't it, my guess is that it's a self imposed (KSP) limitation rather than an inherent limitation of the tree structure. I'll have a look, but if there is special logic put in, I think it will be difficult/impossible to fix at my level.

It may take a few days before I can even check, so maybe bug me about this again.

Cheers,

~Claw

[Camacha]

so maybe bug me about this again.

Can and certainly will do I am curious to see what you can come up with.