[1.0.5] Kip Engineering: All Docking Ports updated for 1.0.5! (11th Nov 2015)

[juanml82]

Download link is dead. Also, the ports aren't working with smaller, stock ports - but I'm using 0.9, I was hoping to update

[Corscaria]

54 minutes ago, juanml82 said:

Download link is dead. Also, the ports aren't working with smaller, stock ports - but I'm using 0.9, I was hoping to update

It's not dead. Its hosted on mediafire. All mediafire links on the site have been mangled, because of porn ads. You can fix the link yourself simply by re-adding the mediafire domain back into the download URL. Or you can wait for the mod creator to paste new links on a different site.

[Chonner]

9 hours ago, juanml82 said:

Download link is dead. Also, the ports aren't working with smaller, stock ports - but I'm using 0.9, I was hoping to update

Have tried reading back a whole 3 comments before the one you posted? Because I already rehosted them on Dropbox as a temporary measure until CaptainKipard returns.

It is a good idea and good forum etiquette to read back at least the last 10 or so posts at least whenever you have a mod problem, as often the problem has already been noticed and perhaps solved by someone else and it saves on repeating things.

[Drew Kerman]

I've not tested all in-game functionality but all these parts load up into v1.1 release with no logged errors (unless you're missing CLS, but the module is just disabled in that case no harm done).

I'm not sure if the handles on the station parts were ever meant to be grabbed, but if so that no longer works

[FreeThinker]

Because the media link wasn't workeing, I taken the liberty to upload it to spacedock.  

Non-Androgynous Docking Port Set can be downloaded from here

 

Edited May 2, 2016 by FreeThinker

[Wolf Baginski]

On 27/04/2016 at 7:25 PM, Gaiiden said:

I've not tested all in-game functionality but all these parts load up into v1.1 release with no logged errors (unless you're missing CLS, but the module is just disabled in that case no harm done).

I'm not sure if the handles on the station parts were ever meant to be grabbed, but if so that no longer works

Good to hear this. I shall give them a run with 1.1.2 though, since I am running under Linux, anything could happen. (it is annoying when people are wailing about problems I have never seen, and are not bothering to say which of the three versions they are using.)

[FreeThinker]

18 minutes ago, Wolf Baginski said:

Good to hear this. I shall give them a run with 1.1.2 though, since I am running under Linux, anything could happen. (it is annoying when people are wailing about problems I have never seen, and are not bothering to say which of the three versions they are using.)

Alright, let me know it if it works in 1.1.2, the I will update the version.

The big advantage of this mod is that it uses stock only parts, so it should be compatible with any future updates

Edited May 2, 2016 by FreeThinker

[Wolf Baginski]

Sorry to say that I've not had any success with v1.1.2 but it may not be an issue with these parts specifically. I noticed that the equivalent stock parts specify nodes in a totally different manner. This is the style all the KipEng parts use.

NODE
{
	name = top
	transform = n_top
	size = 1
	method = FIXED_JOINT
}
NODE
{
	name = bottom
	transform = n_bottom
	size = 1
	method = FIXED_JOINT
}

And this is the stock docking port.

	node_stack_top = 0.0, 0.2828832, 0.0, 0.0, 1.0, 0.0, 1
	node_stack_bottom = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 1
	node_attach = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0

It's two completely different methods of specifying the node location and the string "FIXED_JOINT" doesn't seem to come up anywhere else but in the KipEng folder.

[rasta013]

Does anyone have a copy of the Universal Docking Ports mod as last updated by @CaptainKipard ?  I've tried hunting it down but can't seem to find a good link to a download anywhere.

[Chonner]

6 hours ago, rasta013 said:

Does anyone have a copy of the Universal Docking Ports mod as last updated by @CaptainKipard ?  I've tried hunting it down but can't seem to find a good link to a download anywhere.

You obviously didn't hunt very hard  I've posted a Dropbox rehost about 10 posts up which I've just checked is still working. 

Edit: I've also hopefully made it glaringly obvious where they are now. 

Edited May 3, 2016 by Chonner

[rasta013]

4 hours ago, Chonner said:

You obviously didn't hunt very hard  I've posted a Dropbox rehost about 10 posts up which I've just checked is still working. 

Edit: I've also hopefully made it glaringly obvious where they are now. 

OMG....well...uhm...uhhhhhh....uhmmmm.  Yeah.  Oops?

This is the kind of stuff that happens when you start looking for stuff at 3 AM after bug hunting for the previous 15 hours. LOL.    Jeez I haven't been this blind in a long time.  Thanks for the assist and yeah...the glaringly obvious worked. 

[FreeThinker]

19 hours ago, Wolf Baginski said:

Sorry to say that I've not had any success with v1.1.2 but it may not be an issue with these parts specifically. I noticed that the equivalent stock parts specify nodes in a totally different manner. This is the style all the KipEng parts use.

NODE
{
	name = top
	transform = n_top
	size = 1
	method = FIXED_JOINT
}
NODE
{
	name = bottom
	transform = n_bottom
	size = 1
	method = FIXED_JOINT
}

And this is the stock docking port.

	node_stack_top = 0.0, 0.2828832, 0.0, 0.0, 1.0, 0.0, 1
	node_stack_bottom = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 1
	node_attach = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0

It's two completely different methods of specifying the node location and the string "FIXED_JOINT" doesn't seem to come up anywhere else but in the KipEng folder.

It puzzled me as well how stock ksp is supposed to know where the nodes are located. It though it had something to do with the transforms which refer to some resource inside the na docking models.

 

I found some old post which can clarify the nodes system

 

Edited May 3, 2016 by FreeThinker

[Wolf Baginski]

So Squad are still using the original method for everything, and everybody else copies them. I suppose that the key details for the position and orientation are defined elsewhere. But note that the details of the old-style node specification changed with v1.0 and that bottom node needed the minus sign adding.

Here's the nodes for the current Rockomax Hub, the stock equivalent, which conveniently shows the six directions.

	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

The first three numbers in the set are the coordinates of the attachment point, the next three are the direction-vector, the last digit is the size.

The two systems might still be there, in parallel, but I feel a bit doubtful about relying on a "New Nodes System" which seems so completely not used. 

[rasta013]

38 minutes ago, FreeThinker said:

It puzzled me as well how stock ksp is supposed to know where the nodes are located. It though it had something to do with the transforms which refer to some resource inside the na docking models.

@FreeThinker, @Wolf Baginski Just a bit of info gleaned from experience in playing with these and some from the wiki...

For the node_stack_(x) parameters

These values determine the vertical stack parameters in relation to the actual node placements.  Any docking port should have 2, the node_stack_top and node_stack_bottom.

The values represent X,Y,Z coordinates (the first 3 values) which specify where the attachment node actually is in relation to the model

The second set of 3 values specify the vector attachment locations with a range of -1 to 1 with -1 being a bottom oriented attachment node in relation to the model and 1 being a top oriented attachment node in relation to the model. For docking ports this is generally going to be 0.0, -1.0, 0.0 for the bottom node and 0.0, 1.0, 0.0 for the top node.

The 7th and final value is the visual size of the node with a range of 0-2 (Sm/Med/Lg) with it defaulting to 1 if no value is specified.  

For the node_attach parameter

This value specifies the where other parts will attach to this part's surface - in other words, the horizontal location with the same format as the node_stack

Now the tricky part is lining up the nodes so that they are far enough apart that they will attach easily but without making the part end up visually hanging off an another attachment node.  Also, the nodes on docking ports need to be far enough apart to make sure the top/bottom nodes can't get confused with each other.  Without having access to the original models in order to determine a model's unit and scale factors, this is all going to be trial and error.  It should be possible to do but may take a few reloads and flight tests to get it working properly.  

I will be trying to do this for the Universal Docking Ports mod which is going to be really tricky as those are custom models.  I've never used the androgynous ports but if they are based on stock models I would think it might be a little bit easier to find good values by referencing the stock cfg files as a starting point anyway.  While this may take a lot of trial and error to get right there is no reason why both the Universal and Androgynous ports can't be made compatible with 1.1.x.

[FreeThinker]

But the question is, what changed between KSP 1.05. and KSP 1.1.x that they suddenly are no longer aligned?

[rasta013]

Just now, FreeThinker said:

But the question is, what changed between KSP 1.05. and KSP 1.1.x that they suddenly are no longer aligned?

Honestly, I don't know but to take a shot in the dark...perhaps the old methods worked perfectly fine under the Unity 4 code and was removed completely, or became inoperable, under Unity 5.

[Wolf Baginski]

4 hours ago, FreeThinker said:

But the question is, what changed between KSP 1.05. and KSP 1.1.x that they suddenly are no longer aligned?

I can't rule out that something else was messing me up, but I do wonder why Squad so consistently does not use the NODE-module method,

I have earlier downloads, but the oldest version I have easily accessible is v1.04 and the only place where I find the "FIXED_JOINT" string is the part-configs in the KipEng folder. It all worked then. It's the same for "JOINT". The string "NODE" is in a few more places, but not in part-configs.

So I reckon the new-style node specification, which came in around v0.20, has been abandoned. It may have been deprecated earlier than v1.0, when it became necessary to get the direction vector correct.

Ah, I found my v0.90 install. Only one item uses the NODE-module, a rover body from Kerbal Foundries

Unity 5 may have been the final straw. It may not have been that it couldn't support both methods, but why do the work to transfer and test both?

It's not going to be trivial to sort this out. There must be something in the .mu files which marks the node locations, there's nowhere else for the data. I know there are ways to load them back into Blender, but after that I'm screaming "Run away! Run away!". Guessing wildly, there are mesh components that are tagged as markers, with specific names. It's likely the top and bottom nodes are (x,y)=(0,0) and only the z-coordinate matters, at least for the docking ports and other KipEng 2-node parts.

But that's reverse-engineering the parts, not the best way of doing things.

[FreeThinker]

15 minutes ago, Wolf Baginski said:

I can't rule out that something else was messing me up, but I do wonder why Squad so consistently does not use the NODE-module method,

I have earlier downloads, but the oldest version I have easily accessible is v1.04 and the only place where I find the "FIXED_JOINT" string is the part-configs in the KipEng folder. It all worked then. It's the same for "JOINT". The string "NODE" is in a few more places, but not in part-configs.

So I reckon the new-style node specification, which came in around v0.20, has been abandoned. It may have been deprecated earlier than v1.0, when it became necessary to get the direction vector correct.

Ah, I found my v0.90 install. Only one item uses the NODE-module, a rover body from Kerbal Foundries

Unity 5 may have been the final straw. It may not have been that it couldn't support both methods, but why do the work to transfer and test both?

It's not going to be trivial to sort this out. There must be something in the .mu files which marks the node locations, there's nowhere else for the data. I know there are ways to load them back into Blender, but after that I'm screaming "Run away! Run away!". Guessing wildly, there are mesh components that are tagged as markers, with specific names. It's likely the top and bottom nodes are (x,y)=(0,0) and only the z-coordinate matters, at least for the docking ports and other KipEng 2-node parts.

But that's reverse-engineering the parts, not the best way of doing things.

There might be a 3th way, you can create a little part mod in 1.0.5, which loads the part node and readout it position and offset, and displays it.

[swjr-swis]

29 minutes ago, Wolf Baginski said:

There must be something in the .mu files which marks the node locations, there's nowhere else for the data.

Guys, I don't consider myself a mod creator, but from what I know, the entire definition of attach nodes is in those node_stack_xxx and node_attach lines in the part cfg files. They contain all the information required for the game to know where the attach nodes are on a part.

I know this, because I have edited part cfg files to move and or create new attach nodes on existing parts. All I did was edit those lines.

 

	node_stack_top = 0.0, 0.2828832, 0.0, 0.0, 1.0, 0.0, 1
	node_stack_bottom = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 1
	node_attach = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0

[Starwaster]

Guys, I don't know what problem you were having, exactly, with these parts nodes and 1.1.2 but the parts do work in KSP 1.1.3

[FreeThinker]

7 hours ago, Starwaster said:

Guys, I don't know what problem you were having, exactly, with these parts nodes and 1.1.2 but the parts do work in KSP 1.1.3

Without any alterations?

[Starwaster]

5 hours ago, FreeThinker said:

Without any alterations?

Correct, as is. Using the files from @Chonner's dropbox link a page back.

Everything connects in the VAB at proper orientations in the VAB as expected and all docking ports function as they are supposed to. (i.e. docking only at configured angle and with respect to gender for gendered ports)

[FreeThinker]

1 hour ago, Starwaster said:

Correct, as is. Using the files from @Chonner's dropbox link a page back.

Everything connects in the VAB at proper orientations in the VAB as expected and all docking ports function as they are supposed to. (i.e. docking only at configured angle and with respect to gender for gendered ports)

By that one version is identical to my upload at Spacedock

I guess 1.1.3 somehow made it compatible again with nodes

[Starwaster]

1 hour ago, FreeThinker said:

By that one version is identical to my upload at Spacedock

I guess 1.1.3 somehow made it compatible again with nodes

I'm not even clear what the incompatibility was supposed to be

[Wolf Baginski]

I   loaded the multi-size Universal Docking Ports into KSP 1.2 and was able to assemble a craft in the VAB, send it into orbit, and undock, no problems.

I still feel nervous about the different way the mod uses for specifying node positions, but it does work.

I am, however, lousy at manual docking, I don't see any reason why the mod shouldn't continue to work since KSP 1.2 recognises the node positions and the docking/undocking functions seem to be unchanged in part.cfg files, but I have too many other reasons for earth-shattering kabooms.

I may have a go at re-writing the part.cfg to use the usual method of defining the node position, once there is a release version of MechJeb. (It is a consistent control tool for testing.) But there are all sorts of ways that could go wrong.