Jump to content

[1.9.x] NodeHelper - tool used to edit node positions


Recommended Posts

Originally made by  @Felbourn, original thread is here:  https://forum.kerbalspaceprogram.com/index.php?/topic/115700-161-nodehelper-tool-used-to-edit-node-positions/

I've updated it for KSP 1.8 and added the ToolbarController and ClickThroughBlocker to it, so it now can be in either the Blizzy toolbar or Stock toolbar

NodeHelper is a useful tool for PART developers and people like me who use existing models to create new parts. You can add, remove, and edit the nodes of a part to see how things will fit together, then output your new values to cut-and-paste into the real CFG file. Reload KSP and see your new part nodes in action! This is also very useful for fixing old parts that don't have their node connection directions set correctly. One click of a button and your old parts will connect again!

Dependencies

 

zJrzFQL.png

Availability

Edited by linuxgurugamer
Link to post
Share on other sites

NodeHelper is an absolutely powerful tool. Godly, even. Every other month I find something new to do that benefits from having this around. Just the other day I setup 3-way and 6-way symmetry. Snowball's chance in the inferno, of making that happen without this mod. Thanks much for your efforts to keep this mod alive @linuxgurugamer.

Actually, I think click-through blocker's influence will have a huge impact. I suffer a fair deal from exactly that at times.

UDYakBI.jpg

GZLwcfS.gif

Edited by JadeOfMaar
Link to post
Share on other sites
  • 1 month later...

Just wondering if anyone else is seeing inconsistencies between shown NH node values and those already in part configs?
I've also been seeing a lot of fractional numbers on the node directional axis... ie 1.25, 1.95, etc... when numbers are 0.0, 1.0, etc in the actual cfgs... vOv

I'ma do some moar testing and poking, and see if I can come up with better info for a proper report if needed.
 

Link to post
Share on other sites
51 minutes ago, Stone Blue said:

node directional axis

am confident everybody knows that values other than 1.0 and 0.0 and -1.0 are valid and actually do affect the node attachment direction.

just like there are actually 9 values for a node. yes 9.

x, y, z, angx, angy, angz, size, crossfeed and can't remember the last.

I have always wondered if one could do say 1.5 for a node size....

Link to post
Share on other sites
23 minutes ago, zer0Kerbal said:

am confident everybody knows that values other than 1.0 and 0.0 and -1.0 are valid and actually do affect the node attachment direction.

Yup.. i know that... ;)
My issue is that what NH displays is different than whats actually in the config ;)

So I removed LGG's most recent, and installed Phineas' last fork (NodeHelper v1.5.1-1 (1.6.1, 1.5.1) [PhineasFreak fork]), and seeing the same thing.
Initial poking, shows the node coords in the few configs I've looked at, are getting multiplied by a factor of 1.25 before being displayed by NH... This *inlcudes* the angx/y/z values... vOv
Leads me to believe something with scaling... the cfgs I'm working with do *NOT* have any scale or rescaleFactor keys defined. These are from one mod, so I want to look at some other stuff, to see if its scaling with the models in *my* mod actually *needing* to have scaling keys defined... vOv

Link to post
Share on other sites

OK, false alarm I guess... Turns out the models are modelled at weird, insconsistent sizes across the board, but somehow, in-game they are all 2.5m... with NO scale/rescaleFactor keys defined.... vOv
What ever is going on, its causing NH to display nodes at whatever weird scale number is being used to get the individual parts sized to 2.5m in-game...

Link to post
Share on other sites
20 hours ago, zer0Kerbal said:

am confident everybody knows that values other than 1.0 and 0.0 and -1.0 are valid and actually do affect the node attachment direction.

just like there are actually 9 values for a node. yes 9.

x, y, z, angx, angy, angz, size, crossfeed and can't remember the last.

I have always wondered if one could do say 1.5 for a node size....

No

16 hours ago, zer0Kerbal said:

maybe look at the part.cfg - rescale = or scale = ; I've always suspected that messes with nodehelper.

 

yep that.

I've seen this problem more with older parts

Link to post
Share on other sites
1 hour ago, linuxgurugamer said:

just like there are actually 9 values for a node. yes 9.

x, y, z, angx, angy, angz, size, crossfeed and can't remember the last.

can't find the documentation for the 8th and 9th argument for node =

but if it is discovered - woul you consider adding those to NodeHelper?

Link to post
Share on other sites
5 minutes ago, zer0Kerbal said:

can't find the documentation for the 8th and 9th argument for node =

but if it is discovered - woul you consider adding those to NodeHelper?

What parts have 8 and 9 entries for those?

I'm not aware of any part which has that, and the documentation for it only goes up to 7 entries

Edited by linuxgurugamer
Link to post
Share on other sites

The problem of NodeHelper displaying differing node distances to what's in the config is related to the scale or rescaleFactor key. One of these (likely rescaleFactor), when set to a value other than 1, or not declared in the config, scales the node distances accordingly. NodeHelper reads this output and not the input (before rescaling) when it gets to the part.

You only need to declare rescaleFactor when you use MODEL{} to link a mesh to a part, and either scale, rescaleFactor, or both, default to 1.25 if you don't declare them, which will mess you up by design. When I say "by design" I refer to some deep and obscure way that the standard part sizes are setup in-game.

crossfeed as an argument of attach nodes is obviously deprecated and need not be supported in this mod. It is its own key elsewhere in the part config. Decouplers, many structural parts, and possibly engines, will have the line crossfeed = false set within them.

Note that the problem, if any, with scale = x does not apply when you're concerned with MODEL {} as then you use it inside of MODEL {} if needed, and it's a vector3 and defaults to scale = 1, 1, 1.

Link to post
Share on other sites

From what I have come to understand, yes, scale =, *inside* the MODEL{}, scales *only* the mesh, on x,y,z axes.  (NOT the attachment nodes).

Used *outside* the MODEL{}, it is used to determine the scale of metric units with which the mesh was modelled in. Supposedly, it defaults to 1 in KSP (hence why KSP defaults to 1.25 for rescaleFactor.) (1 = 1 meter, 10 = 10m, 1.25 = 1.25m, 0.1 = 1 dm,  0.01 = cm, 0.001 = mm, etc) In Blender, this would be the number entered in the Units->Metric entry. I'm pretty sure this doesnt need to be defined *outside* the MODEL{} unless the mesh was modelled in something *other* than 1 meter units in a modelling program... vOv... IMHO, if this is the case where scale = serves these two very different purposes, it was a bad choice to use the same name for the key.

rescaleFactor = supposedly rescales the mesh *and* the attach nodes by the entered amount. It defaults to 1.25, if not defined.
It can be combined with scale = *inside* the MODEL{} to offset scaling of the mesh, seperately and differently than the nodes. I wanna say maybe it was ZZZ that used this a lot in his models... vOv

If anyone has definitive info/documentation/sources differing from what I (probably half-sensically) explained above, as to what I *think* all those keys do, PLEASE share it. ;)

And now that I sort of figured out my issue *NOT* being an NH bug, per se, and these last few posts, I *do* now remember having a conversation with Felbourn, a few years ago when i first started using NH. About how NH handled rescaled parts. IIRC, he said yeah, NH output numbers shouldnt be used directly in configs, when used on rescaled parts. (anything with mesh scale other than scale = 1, 1, 1 *inside the MODEL{} (KSP default when not defined); anything with rescaleFactor = defined as *other* than 1.25 (KSP default when not defined); and possibly, i cant remember for sure, with the units scale thing (scale =, *outside* the MODEL{}), as anything other than 1 or 1.0 (KSP default when not defined).


He said, for anything rescaled going *into* NH, he had made himself a spreadsheet with common rescale factors, that he had to refer to, to get "final/corrected/true" values, rescaled from the NH displayed values, to use instead.

What threw me off, with the issue *I* brought up that started this discussion, was that there *was NO* rescaling set at all in the configs. It wasnt till i thought to look at the models in Blender, that I found who ever modelled them, used inconsistent scales and sizes when they modelled them. (the Unit->Metric entry I mentioned above, that *should always* be either 1 (1meter), or 1.25 meter per unit, to make things easy and consistent for KSP modelling...) :face_palm:

I have yet to figure out how they managed to get them all scaled, (I think), at 2.5m in KSP. I'm assuming they used some scaling trickery on each model when they got run thru Unity... vOv

Edited by Stone Blue
Link to post
Share on other sites
30 minutes ago, linuxgurugamer said:

How about I put in a scaling factor which the user can use to specify ?

Won't be perfect, but could make things easier.

That might just help a LOT... at least with consistent scaling across the mesh *AND* the nodes... (ie scale = *inside* the MODEL{}, and/or  rescaleFactor)  and probably as long as scale = used *outside* the MODEL{} isnt changed from KSP default... vOv
I wouldnt bother with a user setting for that usage/instance... i think its so rare that someone actually defines that as other than "1", anyway... vOv i mean, who models in any metric unit scale *other* than 1m/unit??... mebbe 1.25m/per unit, if they dont know better... but anything else? vOv (even tho *I* seem to have been the lucky one to find a mod that fits that edge case...) :P
 

Edited by Stone Blue
Link to post
Share on other sites
26 minutes ago, Stone Blue said:

That might just help a LOT... at least with consistent scaling across the mesh *AND* the nodes... (ie scale = *inside* the MODEL{}, and/or  rescaleFactor)  and probably as long as scale = used *outside* the MODEL{} isnt changed from KSP default... vOv
I wouldnt bother with a user setting for that usage/instance... i think its so rare that someone actually defines that as other than "1", anyway... vOv i mean, who models in any metric unit scale *other* than 1m/unit??... mebbe 1.25m/per unit, if they dont know better... but anything else? vOv (even tho *I* seem to have been the lucky one to find a mod that fits that edge case...) :P
 

It's actually more common then you think, especially with the older mods.

Not going to happen right away, but I'll get to it

 

Link to post
Share on other sites
11 hours ago, JadeOfMaar said:

crossfeed as an argument of attach nodes is obviously deprecated and need not be supported in this mod. It is its own key elsewhere in the part config. Decouplers, many structural parts, and possibly engines, will have the line crossfeed = false set within them.

I personally don't believe these two (8th and 9th) are depreciated; rather unappreciated.

NoCrossFeedNodeKey is one of these two (am looking for the full documentation) - and allows crossfeed control on a per node, rather than a per part basis.

although (stackTriCoupler) uses it this way:

	fuelCrossFeed = True
	NoCrossFeedNodeKey = bottom

I do believe I have found the documentation:

AttachNode (string id, Transform transform, int size, AttachNodeMethod attachMethod, bool crossfeed, bool rigid)

Enumerator
FIXED_JOINT   
HINGE_JOINT   
LOCKED_JOINT   
MERGED_PHYSICS   
NO_PHYSICS   
NONE   
Link to post
Share on other sites
14 hours ago, Stone Blue said:

What threw me off, with the issue *I* brought up that started this discussion, was that there *was NO* rescaling set at all in the configs. It wasnt till i thought to look at the models in Blender, that I found who ever modelled them, used inconsistent scales and sizes when they modelled them. (the Unit->Metric entry I mentioned above, that *should always* be either 1 (1meter), or 1.25 meter per unit, to make things easy and consistent for KSP modelling...) :face_palm:

I have yet to figure out how they managed to get them all scaled, (I think), at 2.5m in KSP. I'm assuming they used some scaling trickery on each model when they got run thru Unity... vOv

OPT's HAE-02 (non-Legacy) Mk2 engine and the ZZZ engine mounts are big-time offenders. (Their scales are in the order of 100s.) The ZZZ boxes used by my Rational Resources have a custom rescaleFactor I set (0.85) but due to this conversation I'm more alert (and more confused) to it now.

Link to post
Share on other sites
34 minutes ago, JadeOfMaar said:

The ZZZ boxes used by my Rational Resources have a custom rescaleFactor I set (0.85) but due to this conversation I'm more alert (and more confused) to it now.

YES!! ... THATS where I remember this issue from... I did extensive work on ZZZ's boxes, among most of his other models, when I first started dabbling in modding. i think the boxes were what prompted me contacting, and having that discussion with Felbourn.

Edited by Stone Blue
Link to post
Share on other sites
20 hours ago, zer0Kerbal said:

can't find the documentation for the 8th and 9th argument for node =

but if it is discovered - woul you consider adding those to NodeHelper?

I'm not sure.  NodeHelper only writes to a file that data which it understands and controls.  Even assuming that you find the documentation, it is nothing to do with what NodeHelper does.  Find the docs and I'll see if it makes sense

Link to post
Share on other sites
4 hours ago, JadeOfMaar said:

OPT's HAE-02 (non-Legacy) Mk2 engine and the ZZZ engine mounts are big-time offenders. (Their scales are in the order of 100s.) The ZZZ boxes used by my Rational Resources have a custom rescaleFactor I set (0.85) but due to this conversation I'm more alert (and more confused) to it now.

Not being fluent in the subject, how difficult would it be to take a model and rescale it inside Blender?  

8 hours ago, zer0Kerbal said:

I personally don't believe these two (8th and 9th) are depreciated; rather unappreciated.

NoCrossFeedNodeKey is one of these two (am looking for the full documentation) - and allows crossfeed control on a per node, rather than a per part basis.

although (stackTriCoupler) uses it this way:

	fuelCrossFeed = True
	NoCrossFeedNodeKey = bottom

I do believe I have found the documentation:

AttachNode (string id, Transform transform, int size, AttachNodeMethod attachMethod, bool crossfeed, bool rigid)

Enumerator
FIXED_JOINT   
HINGE_JOINT   
LOCKED_JOINT   
MERGED_PHYSICS   
NO_PHYSICS   
NONE   

So the last two are crossfeed and rigid.  I suppose I could add them, I'll tack it onto the list of things-to-do :-)

https://github.com/linuxgurugamer/NodeHelper/issues/7

Edited by linuxgurugamer
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...