Jump to content

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


Recommended Posts

4 hours ago, linuxgurugamer said:

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

Why do you want to know?
Just asking, since depending on that, (and I cant put words in his mouth), but if you can get ahold of Taniwha, he can probably explain *anything* you could possibly want to know about scaling models in Blender, and how it might have effects when running it thru Unity/PartTools, and then how KSP handles it. 
Heck, if he's still as active developing his Blender Import Tool, you may even talk him into adding some kind of KSP-friendly scaling method into it... vOv
He *knows* Blender... IIRC, he's even brought up issues/bugs during 2.8 dev that have been addressed/looked into..... vOv

Link to post
Share on other sites

@linuxgurugamer So I discovered something, and am not sure if it might be useful with NodeHelper or not... but here goes:

I found some information backing up what I was trying to explain in an earlier post. Per the following info in the Kerbal CFG Wiki regarding *both* scale = keys, (although the definitions seem to be listed incorrectly for the respective key: the definition for the one under MODEL{}, is the def. for the one that should be *outside* the MODEL node, and the one listed under mesh = is the one that should be listed for *inside* the MODEL node.)
 

Quote

Model Parameters

At this point, you can use the deprecated style of mesh on a line by itself, or open a new sub called MODEL. The preferred method is to use MODEL:

Actual part Explanation
MODEL { opens the MODEL sub
model The name of the mesh. Write its name therein and keep the mesh file in the same directory as the part file.
scale The scale of the model - depending on the units in your 3D modelling program. If you used one unit = one meter, then use a scale of 1. If it's 1 unit = 0.1 meters, then use a scale of 0.1. Using a 0.1 scale factor and then scaling to fit the other parts is easier than fiddling around with scale factors. This factor will only affect the units involved in node placement and will not affect the actual size of the part.
texture Specifies let location of the texture file - e.g. texture = texturefilename , folder/../texturefilename (/folder would be GameData/folder)

If you do not use MODEL, you must use mesh to define the parts collision mesh, like so:

Actual part Explanation
mesh Mesh defines the mesh and texture package used to create the in-game appearance of your part. Acceptable meshes include .mu files.

Asset Parameters

Actual part Explanation
mesh = DoesItAll.mu Mesh defines the mesh and texture package used to create the in-game appearance of your part. Acceptable meshes include .mu files
scale scale defines the size of your part. I am uncertain as to what will happen when you change this value
specPower Specific Power? fuelLine
rimFalloff 3 fuelLine
alphaCutoff Number: 0.0 fuelLine
rescaleFactor

An optional parameter that is not usually included in most parts, but the option is available for resizing a part for personal use. In order to retain correct node placements, the scale parameter must also be proportionally changed to match the new rescaleFactor. The default value for rescaleFactor is 1.25 but can be changed to any value.

I've tested both. I just set a part cfg with this:

Quote

    MODEL
    {
        model = HorizonAeronautics/Assets/Aero/HA_3SL_Fairing_Proc
        rotation = 0, 180, 0
    }
    scale = 1.15
    rescaleFactor = 1.0

    node_stack_connect = 0.0, 1.0, 0.0, 0.0, -1.0, 0.0, 0

Note the angy = 1.0 in the attach node. When using NH on the part, the initial node coord is displayed as angy = 1.15 in NH. I know rescaleFactor = also plays a part in factoring in the node coords also.
I then set rescaleFactor = 2, and sure enough, the NH displayed value was 2.3.
So, NH seems to display values as equal to ang(x/y/z) x rescaleFactor x scale(outside MODEL{}). Could it be just that simple and easy? vOv

Also, @JadeOfMaar , I dont remember exactly whether I used scale = 0.75 *inside* the MODEL{}, or if it was 0.85 or something, but I know it was somehow smaller, but proportional to the rescaleFactor I used, to get the ZZZ boxes to fit a standard KSP stack size.... So that matches with the definition for rescaleFactor ;)

Edited by Stone Blue
Link to post
Share on other sites

New release, 1.5.1.2

  • Added/fixed code to save position of windows
  • Deleted old code for the Blizzy toolbar
  • Thanks to @whale2 for this:
    • Fixed saving data for parts having names with underscores
  • Added support for last two field in an attach node:  Crossfeed and Rigid.  They only get added if not false
Link to post
Share on other sites
  • 4 months later...
  • 3 weeks later...

@linuxgurugamer It looks like there is a poorly designed patch in GameData/NodeHelper/Configs/NM_PartInfo.cfg

It is adding ModulePartInfo to all parts if you don't have PartInfo, but the module is only found if you have PartInfo (which I have never used)  This is the source of a Cannot find a PartModule of typename 'ModulePartInfo' erro on every single part in my game. :FINAL is also bad practice in distributed mods.

@PART[*]:NEEDS[!PartInfo]:Final
{
        MODULE
        {
                name = ModulePartInfo

                originalPartName = #$../name$
        }
}

Is this patch even necessary at all?  Doesn't PartInfo do this already?  Why the need for another patch?

 

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

@linuxgurugamer It looks like there is a poorly designed patch in GameData/NodeHelper/Configs/NM_PartInfo.cfg

It is adding ModulePartInfo to all parts if you don't have PartInfo, but the module is only found if you have PartInfo (which I have never used)  This is the source of a Cannot find a PartModule of typename 'ModulePartInfo' erro on every single part in my game. :FINAL is also bad practice in distributed mods.

@PART[*]:NEEDS[!PartInfo]:Final
{
        MODULE
        {
                name = ModulePartInfo

                originalPartName = #$../name$
        }
}

Is this patch even necessary at all?  Doesn't PartInfo do this already?  Why the need for another patch?

 

Look very carefully at the patch.  It is very specific, if you do NOT have PartInfo installed, THEN it adds a reference to it's own.

Which, is the real problem, it's not there. 

I'm fixing it, it is supposed to add a link to it's own PartInfo module (ModuleNMPartInfo), looks like the wrong version got committed.

It's there because if you are using NodeHelper to work on nodes, knowing the partinfo is very useful as well.

Edited by linuxgurugamer
Link to post
Share on other sites
5 minutes ago, linuxgurugamer said:

Look very carefully at the patch.  It is very specific, if you do NOT have PartInfo installed, THEN it adds a reference to it's own.

Which, is the real problem, it's not there.  

I understand exactly what it's doing.  If the mod Partinfo is not installed, add this module.  Which is throwing errors from the partcompiler because ModulePartInfo does not exist on my computer.  I don't see it doing anything but being the source of thousands of errors.

Link to post
Share on other sites
Just now, Tonka Crash said:

I understand exactly what it's doing.  If the mod Partinfo is not installed, add this module.  Which is throwing errors from the partcompiler because ModulePartInfo does not exist on my computer.  I don't see it doing anything but being the source of thousands of errors.

See my edited reply, I'm fixing it now

New release, 1.5.1.3

  • Fixed the internal ModuleNMPartInfo (was missing and patch was bad)
Link to post
Share on other sites
9 minutes ago, linuxgurugamer said:

Look very carefully at the patch.  It is very specific, if you do NOT have PartInfo installed, THEN it adds a reference to it's own.

Which, is the real problem, it's not there. 

I'm fixing it, it is supposed to add a link to it's own PartInfo module (ModuleNMPartInfo), looks like the wrong version got committed.

It's there because if you are using NodeHelper to work on nodes, knowing the partinfo is very useful as well.

Why duplicate functionality into NodeHelper when the PartInfo mod is out there for people that want that functionality?  I have my own MM patch for this because I see PartInfo as unnecessary bloat.

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

Why duplicate functionality into NodeHelper when the PartInfo mod is out there for people that want that functionality?  I have my own MM patch for this because I see PartInfo as unnecessary bloat.

Because most people won't know about your patches.  If someone is using NodeHelper, then they are going to need to know the internal names of the parts.  Without one or the other, it's more difficult.

And, because I've added some functionality which you can't do with your patches.  There is now a PAW action to show the partinfo data for parts which are already placed in the editor.

The Partinfo code does not run when in flight, it destroy's itself if it's not in the editor.

You are free, of course, to delete that patch and use your methods.  In that case, there will be less then 1k of code which won't be executed at all in the mod

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

Because most people won't know about your patches.  If someone is using NodeHelper, then they are going to need to know the internal names of the parts.  Without one or the other, it's more difficult.

And, because I've added some functionality which you can't do with your patches.  There is now a PAW action to show the partinfo data for parts which are already placed in the editor.

The Partinfo code does not run when in flight, it destroy's itself if it's not in the editor.

You are free, of course, to delete that patch and use your methods.  In that case, there will be less then 1k of code which won't be executed at all in the mod

You missed the point of my post.  I do have my own way of doing it. But you also have a mod for that functionality so why duplicate the same function into multiple mods?  Once a user realized they need the info they will either implement something themselves like I did, go find PartInfo or suffer from being uniformed.  I don't see the point of duplicating functions.

Link to post
Share on other sites
6 minutes ago, Tonka Crash said:

You missed the point of my post.  I do have my own way of doing it. But you also have a mod for that functionality so why duplicate the same function into multiple mods?  Once a user realized they need the info they will either implement something themselves like I did, go find PartInfo or suffer from being uniformed.  I don't see the point of duplicating functions.

No, I didn't.  It's called being helpful and anticipating a customer's needs.  Sometimes someone won't realize that they need the PartInfo functionality.  This way they don't have to stop, lose what they are doing in order to download and install another mod.  It's not that much code, and IMHO, the benefit outweighs the minor drawback.  And it really is minor.  There is no performance impact, nothing is forcing itself into someone's face, the information will just be there when they right click ona part in the part list, and there will also be a PAW action to show the info for the part that they are currently working on

Link to post
Share on other sites
  • 1 month later...
  • 2 weeks later...

New release, 1.5.1.4

  • Thanks to github user @kevinowen for this:
    • Exclude ThrottleControlledAvionics "parts" because ThrottleControlledAvionics uses dummy parts for tech tree unlocks of its modules.
    • Along the same lines, Breaking Ground's deployable parts are now excluded
Link to post
Share on other sites
  • 3 weeks later...
On 1/13/2020 at 3:26 PM, JadeOfMaar said:

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.

Was there a work around for this problem ?

Link to post
Share on other sites
53 minutes ago, Mecripp said:

Was there a work around for this problem ?

Other than doing math outside of NodeHelper, I dont believe so... A long time ago, i had this discussion with Felbourn, and even *they* said they couldnt figure out a code fix, concerning 'rescaleFactor =', and even they were left resorting to using a cutom spreadsheet with macros for anything but default rescalefactor values, that did the math for various typical scales, to get the proper coords for nodes, that would have to be entered manually, outside NodeHelper writing them to the cfg. :(

Ahh.. here we go..my 1st post on it...next 5 or 6 posts are relevant

 

Edited by Stone Blue
Link to post
Share on other sites
  • 3 months later...

1.11 Scatterer - Node helper bug
After much time isolating and identifying the issue I have come to realise their is a incompatability between scatterer 0.0722 and Node helper 1.5.1.4 that causes the ocean and atmosphere config files of Scatterer to corrupt when both are installed, I have repeated this several times with the same result each time.

All mods installed via ckan on KSP 1.11

Edited by lamberto29
Link to post
Share on other sites
4 hours ago, lamberto29 said:

1.11 Scatterer - Node helper bug
After much time isolating and identifying the issue I have come to realise their is a incompatability between scatterer 0.0722 and Node helper 1.5.1.4 that causes the ocean and atmosphere config files of Scatterer to corrupt when both are installed, I have repeated this several times with the same result each time.

All mods installed via ckan on KSP 1.11

Can you try it in 1.10 as well, please?

This is a low priority, this is a development tool, and as such isn't really meant to be used in a full game.  I'll look at it, but not sure what might be the problem

Frankly, there is nothing here which would interface at all with scatterer.  You may want to contact the scatterer author about it.

There is no patch which affects anything else, other than adding a module for it to use, and it only runs in the editor

Link to post
Share on other sites
10 hours ago, linuxgurugamer said:

Can you try it in 1.10 as well, please?

This is a low priority, this is a development tool, and as such isn't really meant to be used in a full game.  I'll look at it, but not sure what might be the problem

Frankly, there is nothing here which would interface at all with scatterer.  You may want to contact the scatterer author about it.

There is no patch which affects anything else, other than adding a module for it to use, and it only runs in the editor

I'll try and get round to testing in 1.10 when I get time.

I also found it quite odd that "Node Helper" would be interfering with Scatter but I was isolate it to just these two mods installed and the "Oceanless/Atmosphereless" bug appeared (Basically Scatterer is unloading the planet details asif it's far away)

I'll get a messege sent over to the Scatterer dev/team too, just wanted to give you a heads up.

Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

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...