MODEL, NODE, and all the 0.25 faff

[Greys]

As many part modders and users of KW in particular may have noticed, something big, and tiny, happened this update in KSP. To explain it's best to step back

0.20 introduced the GameDatabase, and changed how cfg files worked. In the beginning! Well in the beginning it was even worse; but Slightly after that! The way cfg files worked is that you'd have a file called part.cfg and in it you would have all the keys and nodes to define the part; though early on there weren't even nodes because everything was based on modules. In 0.17 or so PartModules were added, and the MODULE node was born to define them, somewhere around here RESOURCE was also added and that was most of it. Now fast forward to 0.20, and the big change.

PART{}, Now we could define any node in any cfg file, and any number of them, it was great! a bit nasty because /everything/ had to change, but it really wasn't that bad, and it came along with two new nodes inside PART, MODEL, and NODE. NODE was promptly forgotten because it simply didn't work and really wasn't anywhere near working either, but MODEL has found a lot of use in welding and asset reuse, however. Do not mistake, MODEL was also broken.

MODEL suffered from a surprisingly simple error which turned out to stem from the same place as many of NODE's glitches. MODEL didn't fit into the paradigm of part loading as KSP wanted it to be, and Squad hadn't jammed it into the right place in the process, the result

PART.rescaleFactor has been applied to MODEL nodes twice, starting with their inception in 0.20, and ending in 0.24.2

The impact of that if you wanted to scale an asset, anything other than 1:1, you had to do some weird stuff. My preferred method was the X*Y=1 method, say for a 2:1 scale you'd set PART.rescaleFactor=2, and PART.MODEL.scale=0.5,0.5,0.5, or the other way round, I forget. The other option was to leave PART.MODEL.scale=1, etc, and set PART.rescaleFactor to the square root of the multiplier you want, in this example 1.414213562etc, it's all in floats so you only need a bitdepth of 16.

That's gone.

It works now

And this is a bit of a problem.

Now, if you have the numbers manipulated as described above, you are specifically not going to get what you want. KW Rocketry has, or had, I haven't checked since discussing the issues with somebody making a patch for it yesterday. The solution is easy, because of the glitch with MODEL we had to manipulate the numbers in a certain way to get the result we wanted, and now we don't. To fix your parts simply put in the normal numbers as were originally intended. If you are not going to try to use NODE then put the intended multiplier in rescaleFactor, and leave all the MODEL.scale fields at 1,1,1; this way KSP will automagically scale the attachnodes and FX nodes and CoMOffsets and etc, and you won't have to fix these yourself.

On to the larger bag of worms.

NODE allows, theoretically, for attachnodes to be defined by transform gameobjects defined and positioned in the Unity Editor and compiled into the .mu file. This is a lot easier and more reliable than the PART.node_* method. However~

NODE was originally announced as ATTACH, suffice to say ATTACH DOES NOT EXIST, it's here where the expletives start btw, insert them of your own accord since I can't include them due to forum policy.

So for a good, well, until about June, it was assumed that ATTACH was so incredibly broken that nothing happened; and nothing did happen, because ATTACH DOES NOT EXIST.

Moving forward from there it was noted that NODE.size was completely ignored. Prior to 0.24 that didn't matter, but 0.24 came out slightly before it was realized that ATTACH DOES NOT EXIST, and 0.24 introduced joint strengthening based on the size of the attach node, so it did matter.

It was shortly after that discovered that NODE could not be used to define a given attachnode as being that part's srfattachnode, aka node_attach or the node that positions and orients the part when placed on the surface of another part. This in particular has not been fixed yet, but more about that later.

Then it was discovered that NODE was, and still is completely bypassed by rescaleFactor, the situation has improved though, now NODE is impacted by the MODEL.scale values of the MODEL that the transform exists in, this is functional but rescaleFactor does not apply to NODEs, while it does apply to MODEL, but not somehow not the transforms in the MODEL, I'm a bit confused by that myself but the result is that if you wish to use NODE, rescaleFactor must equal 1, and if you want to scale the part you must use MODEL, which then means that any coordinates defined in the cfg file will be wrong, unless you compensate by hand! Yay math! Ffffffff.

So glad that doesn't apply to me, I won't have coordinates in my cfgs once I figure out this last bit.

I don't yet have it pinned down and I don't understand why, I'll be doing more testing on friday. About 2 thirds of my NODEs render correctly in the world, in the right place, snap the right way, are the right size; but they won't.... attach... I've confirmed it's not related to colliders, they don't attach even with the node way off floating in air and with collision allowed, they only snap in the correct orientation; I really just don't know. But some of them do work! And I don't know why they work either!

Now, I mentioned that you cannot define srfAttachNodes via NODE, and really that is supposed to work, the feature's just missing the critical bit and by luck this one thing was something I could do myself.

Tada! SrFix, it locates all parts which do not have a srfAttachNode but do have an AttachNode that qualifies to be one, and makes that node be it for that part.

https://kerbalstuff.com/mod/258/SrFix

If I, or any of you, can figure out that one last hitch of the nodes not noding, then NODE will finally (with srfix's assistance) be fully viable, with an adequate dose of caveats

Final note; so far as I can tell the appropriate orientation of the transform is with the blue arrow pointing away from where the other part should attach.

HOPE! I can feel it!

Edited October 11, 2014 by Greys

[CaptainKipard]

now NODE is impacted by the MODEL.scale values of the MODEL that the transform exists in, this is functional but rescaleFactor does not apply to NODEs, while it does apply to MODEL, but not somehow not the transforms in the MODEL, I'm a bit confused by that myself but the result is that if you wish to use NODE, rescaleFactor must equal 1, and if you want to scale the part you must use MODEL,

I was wondering about that thanks.

which then means that any coordinates defined in the cfg file will be wrong, unless you compensate by hand!

What coordinates are you referring to?

About 2 thirds of my NODEs render correctly in the world, in the right place, snap the right way, are the right size; but they won't.... attach... I've confirmed it's not related to colliders, they don't attach even with the node way off floating in air and with collision allowed, they only snap in the correct orientation; I really just don't know. But some of them do work! And I don't know why they work either!

I had this once, and in my case it was misspelled node names.

Now, I mentioned that you cannot define srfAttachNodes via NODE

Sorry to treat you like an idiot. You probably know this, but are you using hinge_joint?

[toadicus]

Greys, about nodes not attaching things: are you referring to the behavior where only the first and last nodes defined in a part file will allow parent-style attachments?

For example, TweakableEverything adds a third node to the inline docking port. However, this node can only be used for child-style attachments. That is, if I place another part, and then fetch an inline docking port, I can still only attach it to the ship by the "top" or "bottom" nodes: the new node that I added in the middle doesn't work (it sorta looks like it does; it snaps on but the part stays greyed out and if you launch or save etc, it's gone). If I attach it by the "top" or "bottom" node, I can then attach new parts as children to the "middle" node.

[Gaalidas]

I see your text on the screen but I have no clue what you are saying. Still, it looks like you really researched all this and made us a nice little fix in a compact package which, until I am told it is not needed, will be installed now.

[Ruedii]

I was thinking to see if there is a way to do this with module manager. Do you think it's possible?

[Gaalidas]

maybe, but without the ability to set variables, manipulate them, and then use them in place of normal config data during a MM patch process, it might be a little bit difficult. What we really need is a MM style plugin that implements a sequential scripting system similar to the windows batch file system with environment variable I/O.

[toadicus]

ModuleManager patches can be used for "quick fixes" to the scaling issues for some/many parts, but it needs to be designed specifically to the method that the part creator was using. ModuleManager doesn't handle any of the data in its target forms, so doing math on the vectors isn't a thing at this point. I made such a patch for KW Rocketry, because both Kyle & Winston are incapacitated at the moment, but since a "one-size fits all" solution doesn't really work, the best way forward for users is to wait for part authors to fix things.

[Greys]

Greys, about nodes not attaching things: are you referring to the behavior where only the first and last nodes defined in a part file will allow parent-style attachments?

For example, TweakableEverything adds a third node to the inline docking port. However, this node can only be used for child-style attachments. That is, if I place another part, and then fetch an inline docking port, I can still only attach it to the ship by the "top" or "bottom" nodes: the new node that I added in the middle doesn't work (it sorta looks like it does; it snaps on but the part stays greyed out and if you launch or save etc, it's gone). If I attach it by the "top" or "bottom" node, I can then attach new parts as children to the "middle" node.

Yanno, that could totally definitely be it; however for me it's the Last Two defined nodes in the cfg file that do work, testing, testing

What coordinates are you referring to?

// --- node definitions ---
node_stack_top = 0.0, 0.7783, 0.0, 0.0, 1.0, 0.0



// --- FX definitions ---

fx_exhaustLight_blue = 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, power
fx_smokeTrail_light  = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, power
fx_exhaustSparks_flameout = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, flameout

Edit: Now of course, the coordinate 0, 0, 0 never scales, unless you do something which cannot be done except by code, scale from somewhere other than the origin

Edited October 9, 2014 by Greys

[CaptainKipard]

Thanks for your explanation. I should have realised it wasn't a simple a config mistake from all the class lingo.

Anyway I'll add this to the dev compilation now. Could you make the dl link a little more prominent?

[slumpie]

I'm a bit confused by that myself but the result is that if you wish to use NODE, rescaleFactor must equal 1, and if you want to scale the part you must use MODEL, which then means that any coordinates defined in the cfg file will be wrong, unless you compensate by hand! Yay math! Ffffffff.

Maybe I'm misunderstanding something, but using scale outside of MODEL should work as well, shouldn't it?

EDIT: Instead of "compensating by hand".

[Greys]

Maybe I'm misunderstanding something, but using scale outside of MODEL should work as well, shouldn't it?

EDIT: Instead of "compensating by hand".

scale outside of MODEL is a completely unrelated thing; it multiplies the coordinate space of the part; which Only moves things that are defined by coordinates in the cfg file.

[toadicus]

Yanno, that could totally definitely be it; however for me it's the Last Two defined nodes in the cfg file that do work, testing, testing

TweakableDockingNode does this:

!node_stack_bottom = DELETE

node_stack_tdn = 0, 0, -.671, 0, 0, 1, 1
node_stack_bottom = 0.0, -0.5753132, 0.0, 0.0, 1.0, 0.0, 1

Last time I checked, it behaved exactly as I described. Granted, that's been a few months... but the order [node_stack_top, node_stack_tdn, node_stack_bottom] worked for me then, and for the users who reported / helped fix the problem.

[slumpie]

scale outside of MODEL is a completely unrelated thing; it multiplies the coordinate space of the part; which Only moves things that are defined by coordinates in the cfg file.

In this case I don't see what you mean with this:

which then means that any coordinates defined in the cfg file will be wrong, unless you compensate by hand! Yay math! Ffffffff.

What coordinates? I thought you meant the ones for the node definitions in the config file.

I just thought that as an alternative you could use scale outside MODEL, instead of recalculating all the node coordinates.

--------------

EDIT:

Let's say NODE is used on your parts.

If you want to rescale a part, you would do that by using scale inside MODEL together with rF=1, right?

If you start with this:

MODEL

[INDENT]{
model = something
scale = 1, 1, 1
}
[/INDENT]

[B]scale = 1[/B]
rescaleFactor = 1
node_stack_bottom = 0.2378, -1.4321, 0.4567, 0, -1, 0, 2
NODE
{
name = top
transform = topTransform
size = 1.0
method = FIXED_JOINT
}

And then if you want to scale it by the factor 3.75:

MODEL

[INDENT]{
model = something
scale = 3.75, 3.75, 3.75
}
[/INDENT]

[B]scale = 3.75[/B]
rescaleFactor = 1
node_stack_bottom = 0.2378, -1.4321, 0.4567, 0, -1, 0, 2
NODE
{
name = top
transform = topTransform
size = 1.0
method = FIXED_JOINT
}

*note changed scale factor*

It's easier this way to adjust coordinates, isn't it?

Although it's questionable how often this will actually be the case. Why defining nodes in the model and in the config.

I mean if as example FX coordinates were actually working, then...

Edited October 10, 2014 by slumpie

[toadicus]

So, if I'm right in thinking that Greys is saying that PART.scale applies scalar transforms to cfg-local coordinates (e.g. node_stack_... entries), I think slumpie is right, and I also think that Squad should formally deprecate either scale or rescaleFactor and roll its function into the other.

Currently:

• PART.MODEL.scale - A PART's MODEL's scale value applies to both the actual size of the part model and cfg-local coordinates.
  
• PART.scale - A PART's scale value applies only to the cfg-local coordinates, e.g. node_stack_XXX.
  
• PART.rescaleFactor - A PART's rescaleFactor value applies applies only to the actual size of the part model.

So, if you scale your part with PART.MODEL.scale, no worries. Leave the other two alone. If you further scale your part with PART.MODEL.scale and PART.rescaleFactor, change PART.scale to match.

It seems to me like the best way to solve this would be:

• PART.MODEL.scale - A PART's MODEL's scale value applies to both the actual size of the part model and cfg-local coordinates.
  
• PART.scale - A PART's scale value applies to both the actual size of the part model and cfg-local coordinates.
  
• PART.rescaleFactor - OBSOLETE. No longer applies any transformations.

I can't think of a compelling reason to keep the scale of the node coordinates and the part size separately. On the other hand, I've never built a part ever, so what do I know?

[slumpie]

Currently:

• PART.MODEL.scale - A PART's MODEL's scale value applies to both the actual size of the part model and cfg-local coordinates.
  
• PART.scale - A PART's scale value applies only to the cfg-local coordinates, e.g. node_stack_XXX.
  
• PART.rescaleFactor - A PART's rescaleFactor value applies applies only to the actual size of the part model.
  

Ehm, no you got that wrong.

MODEL scale - Only applies to MODEL (the part size), to NODE and to the MODULE objects (unless you meant that with local(?) coordinates...).

scale - Only applies to coordinates in the config

rescaleFactor - Applies to mesh (if used), to coordinates in the config, to MODEL and to MODULEs, but not NODE (according to Greys, I didn't test this).

Edited October 10, 2014 by slumpie

[raidernick]

If you start with this:

MODEL

[INDENT]{
model = something
scale = 1, 1, 1
}
[/INDENT]

[B]scale = 1[/B]
rescaleFactor = 1
node_stack_bottom = 0.2378, -1.4321, 0.4567, 0, -1, 0, 2
NODE
{
name = top
transform = topTransform
size = 1.0
method = FIXED_JOINT
}

And then if you want to scale it by the factor 3.75:

MODEL

[INDENT]{
model = something
scale = 3.75, 3.75, 3.75
}
[/INDENT]

[B]scale = 3.75[/B]
rescaleFactor = 1
node_stack_bottom = 0.2378, -1.4321, 0.4567, 0, -1, 0, 2
NODE
{
name = top
transform = topTransform
size = 1.0
method = FIXED_JOINT
}

*note changed scale factor*

It's easier this way to adjust coordinates, isn't it?

This is how I scale all of my parts/nodes and have not had any issues with it. Having avoided the use of rescalefactor means the parts weren't broken by the update. I think it's better practice to scale it this way rather than using rescalefactor.

[Greys]

Right, rescaleFactor applies to everything, except weirdly NODE. In the following picture I had the same .mu file in 3 sizes with MODEL.scale=1,1,1, and 3 values of rescaleFactor, using NODE blocks

Don't mind the red, development in progress.

This immediately stuck out when I made the change realizing that MODEL had been fixed, the very first run was pretty confusing; with the rescale^2 glitch fixed XY=1 was actually true, so all 3 parts were the same size, but their nodes varied wildly, upon correcting the scales I was faced with that image and gave up for the day.

Admittedly the result is less asinine than I initially believed; for some reason I jumped to the conclusion that MODEL was driving the scale of NODES, when really NODES are based on transforms in the model that MODEL is loading; so really it's just that all of the scales are being applied in the correct order to result in NODE's transforms being where they aught'; except for the part where rescaleFactor is bypassed.

scale applies only to the coordinate space, and I for one fully support taking scale under the bridge and setting it on fire. I don't see any way that scale contributes to the game anymore; and arguably it was a bad solution for what it was added for

and what it was added for is the fact that prior to .mu files, KSP would load any .dae file and assume that their coordinate space was in meters; so if you gave it a coordinate space in feet, you might set the scale to 3.28~, the holes in this logic are large enough to fly a small mountain through.

deprecate scale ++

Edit: I have recompiled and patched SrFix successfully; but I don't have time to package it; will be available in about 14 hours

Edited October 10, 2014 by Greys

[Supernovy]

I don't yet have it pinned down and I don't understand why, I'll be doing more testing on friday. About 2 thirds of my NODEs render correctly in the world, in the right place, snap the right way, are the right size; but they won't.... attach... I've confirmed it's not related to colliders, they don't attach even with the node way off floating in air and with collision allowed, they only snap in the correct orientation; I really just don't know. But some of them do work! And I don't know why they work either!

Do your nodes point in multiple directions? Because you may be running into a really really old bug where having nodes in different directions in the wrong order in the config would cause exactly that - snapping, but it would prevent actual attachment. Since they're evidently not in the config, I don't know what can help with that.

I can't remember the details, but it was something like you had to make the very last two defined nodes the top and bottom ones.

[slumpie]

Three possibilities/rules:

• Only nodes that are defined to be on the same axis AND are at the end of the node_stack list will attach properly if used as first attachment point of a part.
  
  • Note: There is no limit, you can have as many node_stacks as you want as long as they share the same axis.
    

  [*]If NODE is used only the NODE definitions with the same axis AND which are at the end of the list can be used as first attachment point.

  • Note: If NODE and node coordinates are used, then only the last NODE transforms with the same axis will have this ability, no matter if you followed the first rule or not.
    

  [*] node_attach DOES WORK in combination with node_stack or NODE.

  • So far the only workaround for parts that are meant to be attachable on two different axis!
    

The only workaround is to follow the first two rules for all NODE or node_stack definitions and then to add node_attach. Surface attachment can be messy though...

Edited October 10, 2014 by slumpie

[Greys]

ok so that was more than 14 hours, by about 12 hours, but here

SrFix

updated to 0.25, fixed the remnant nodeball for the srf node

Still testing on how to make all the nodes work; thanks for the suggestions about what to try.

Edited May 4, 2021 by Snark
Link to defunct website removed by moderator

[slumpie]

Well, that weren't really suggestions.

I pretty much just listed the results of my testing.

What I found interesting is that I couldn't replicate the limitation of one or two nodes. I think I had about six nodes sharing an axis and they all worked. NOTE: With sharing an axis I don't mean them being on the same position vector (understandable?), I'm actually talking about the node defining axis being parallel to each other.

[CaptainKipard]

Am I understanding correctly that HINGE_JOINTs aren't working with this yet?

[AlphaAsh]

Been systematically hacking away at how to use MODEL without the revert bug doing it's evilness and finally found the correct combination.

	MODEL
	{
		model = KashCorp/BoxBases/Assets/kapcubecab2
		scale = 1.25, 1.25, 1.25
	}
	scale = 1.25
	rescaleFactor = 1

The scale in Unity for the model is of course 1,1,1.

[CaptainKipard]

Is this fix still necessary?

[raidernick]

Yes, if you use model nodes and rescalefactor is not 1 when you revert or load saves parts change size.