The Fault in our NODE{}s

[Greys]

PART
{
    NODE
    {
        name      = something
        transform = NameOfTransformInModel
        size      = 1
        method    = FIXED_JOINT
    }
}

This is PART.NODE, it was introduced in 0.20, and nobody could make it work. Part of this was because it was announced as PART.ATTACH, which doesn't exist. Now, it was figured out that this was wrong and that announcement has been corrected.

What PART.NODE is supposed to do is allow you to define an AttachNode on a part via specifying a transform in the .mu 3D asset file, instead of using PART.node_ and specifying a vector with a series of numbers which are frequently difficult to adjust. For instance node_ specifies orientation as the average of 3 one dimensional vectors where the only thing you can impact is the vector's magnitude, not by degrees, but the average of Z=6, Y=0, X=1 composited into a single vector.

Unfortunately knowing of NODE is not simply enough. The depths of faults in the code of this node have become reasonably insurmountable. The first problem with it was that NODE.size was ignored, this has been fixed as of 0.24, Thanks to Mu.

Following that it was discovered that PART.NODE lacked any code permitting it to define a node to be a part's part.srfAttachNode. This has not been fixed but I have been able to correct it with a plugin which iterates over all the AvailableParts and applies the same logic as the base game to select a node to be the srfAttachNode, if a qualified node exists.

DLL: https://github.com/Greys0/Virgin-Kalactic/blob/master/Build/srFix.dll

SRC: https://github.com/Greys0/Virgin-Kalactic/blob/master/Source/Virgin_Kalactic/srFix/FixSurfaceNodes.cs

License: MIT

However, there remains a greater beast. NODE{} definitions are fully exempt from all scale factors applied to the part. PART.scale, PART.rescaleFactor, PART.MODEL.scale; all of it ignored.

This can't easily be fixed from the outside because there's no way after the fact to tell if an AttachNode was defined by PART.NODE or PART.node_. The logical thing to do would be to crossreference the AvailablePart pool at PartLoader.Instance.parts against GameDatabase.Instance.GetNodes("PART"), and then apply the rescaleFactor which is stored in the AvailablePart to any matching nodes; But during the loading process all the PART nodes stored in the GameDatabase are striped of string values, or rather, values that are actually supposed to be text instead of numbers, enums, etc. To say that differently, there is no way to determine what part any given instance of PART in the gamedatabase was originally intended to define, all identifying information has been removed.

This is a problem I've rammed into several times in trying to fix things which get loaded incorrectly and it's really aggravating because the only other option is to load the files again myself and create my own gamedatabase, which would also mean finding some way to apply ModuleManager patches to my duplicate, and that's getting crazy.

As it stands NODE{} is functional, you can define everything about it, there's a fix for the one problem with it; but you Can Not Scale Parts that use NODE{}

Glossary
PART  The structure in a cfg file which KSP uses to define an instance of Part
Part   The class in the code which is instantiated to define a part
part   The instance of Part filled with the values from PART
PartLoader   The class which is responsible for loading parts
GameDatabase  The repository of confignodes parsed from cfg files
AvailablePart   An object type used as a precurser to individual instances of Part on vessels; these define the parts as they are shown in the editor before you pick them out of the sidebar
AttachNode   An object type used to define all 'nodes' on all parts; 'node balls' are based on these and they define part snapping and define some attributes of the joint that is made there

Edited July 30, 2014 by Greys