Multiple Docking Ports on a single Part

[chrisl]

I've tried searching for this topic but what I keep finding is related to multi-port docking instead of multiple available docking ports.  What I'm trying to accomplish is the creation of a space station part that includes a number of separate, individual docking ports, all using existing models.  For instance, one of the parts I'm trying to create is a recreation of the Unity (or Node 1) module of the International Space Station.  That module has 6 docking ports: Forward, Aft, Port, Starboard, Nadir and Zenith.  Rather than having a space station component that requires 7 parts (module plus 6 docking ports) I want to create a single Part that includes everything in one.  I've got the cfg mostly working.  It looks correct and all the correct attachment points are available in the VAB.  But once I launch the component, only the Forward docking port (which happens to be the first one listed in the cfg file) seems to work.  All the other ports show up and are named correctly, but if I do anything with any of them, they all react together and it only seems to be possible to target and/or dock with the Forward port.  So is it at all possible to make this work just with a cfg file?

[CobaltWolf]

1 hour ago, chrisl said:

I've tried searching for this topic but what I keep finding is related to multi-port docking instead of multiple available docking ports.  What I'm trying to accomplish is the creation of a space station part that includes a number of separate, individual docking ports, all using existing models.  For instance, one of the parts I'm trying to create is a recreation of the Unity (or Node 1) module of the International Space Station.  That module has 6 docking ports: Forward, Aft, Port, Starboard, Nadir and Zenith.  Rather than having a space station component that requires 7 parts (module plus 6 docking ports) I want to create a single Part that includes everything in one.  I've got the cfg mostly working.  It looks correct and all the correct attachment points are available in the VAB.  But once I launch the component, only the Forward docking port (which happens to be the first one listed in the cfg file) seems to work.  All the other ports show up and are named correctly, but if I do anything with any of them, they all react together and it only seems to be possible to target and/or dock with the Forward port.  So is it at all possible to make this work just with a cfg file?

what extent have you tested this? Have you placed other docking module cfgs in that first spot?

[chrisl]

I've got two station parts setup so far.  One recreates Zarya from ISS and has a forward, aft and nadir docking port.  The second recreates Unity from ISS with the 6 ports I mentions above.  The station itself is made up of just 2 Parts: ISS_UNITY & ISS_ZARYA.  On the ISS_ZARYA part, there are three "ModuleDockingNode" MODULEs.  On the ISS_UNITY part, there are six "ModuleDockingNode" MODULEs.  I can dock the "forward" port of each PART to each other without issue.  I'm pretty sure that's simply because the "forward" port for each PART is the first "ModuleDockingNode" I have listed on each PART.  If I undock these two station PARTs and try to have ISS_Zarya dock with the aft port of ISS_Unity, it won't work.  Everything in game makes it clear that I'm still targeting the forward node on Unity.

I also can't try to dock the aft or nadir ports on Zarya with any port on Unity.  Regardless of which "control from here" button I select, I'm always controlling from the forward port.

[Tyko]

The Tokamak Industries mod has a part with 3 ports on it...might want to look at that.

 

[DatBoi]

3 hours ago, Tyko said:

The Tokamak Industries mod has a part with 3 ports on it...might want to look at that.

 

Of course lgg has that one under his belt too...

[chrisl]

That looks really promising.  I'm just not sure if the model has designed in Unity to have multiple control and docking points or if it all done using the extra modules.  But it gives me an example to try some tests from.

[wasml]

Are you taking an existing part and adding ModuleDockingNode's  to the config file? If so that's not going to work as the module needs a transform to tell it what position and direction the port docks from - Unless the model you're using already has a transform for each docking port.

[artwhaley]

I've done a lot of work with docking ports, including multiple ports on a part, so I think I can help you get part way.

Are you putting individual transforms with unique names in the model for each port, and then pointing a different ModuleDockingNode at each of them?   Doing THAT will get the docking working.   THEN - giving each port ANOTHER transform, this time with (I'm going from like 2 year old memory here) the GREEN axis pointed out in Unity.  (So it's co-located with the dockingNode, but oriented differently!)  These nodes also each need a unique name - and they get assigned as the controlTransformName for each ModuleDockingNode.  That will make 'control from here' work on all of the ports...  Though they won't be labeled...  you'll just have 6 'control from here' buttons and have to guess which is which.  

As for making the ports targetable...   well... there you might be screwed.  There's SOME possibility that it could use whichever 'control from here' you'd last selected?  I haven't tested that.  More likely...   not... unfortunately.  I can't think of a good way to make this work.   You MIGHT look at SSTU as well... he also uses multiple docking ports, and I know there's a plugin module involved, but haven't investigated what it does or if it solves this problem.  In stock...  'set target' is by part...  I can't think of a way to tell it to select a specific port.   If you figured out what transform it used by default....  you could animate it to move to the right docking port based on a menu selection...  maybe?   

Sorry!  I could only get you part way!

[chrisl]

So the only way to make it work is to mess around in Unity?  All I've been doing is using existing models and merging them together.  Then adding ModuleDockingNode to the part config.  I had been hoping there was a way to point to the transforms of the individual models.

As for SSTU, I'm actually using some of his models for what I'm doing but as far as I know, in the latest versions he removed the docking ports from the models.  Probably for the same issues I'm encountering.

[artwhaley]

I found someone with a working solution to your problem!   Porkjet's Habitats - which are now part of Tokomak Industries Refurbished Parts has multiple docking ports on a single part and he has written a plugin that lets them actually fully work.   I haven't combed the plugin's code yet, but wanted to keep you updated.  He ALSO did something really cool that I'd never thought of.  If you look at the cfg file for the hab with multiple docking ports (Habitat Pack Flat) you'll see that he used two .mu model files - one with the part... and another with JUST the control nodes.  You'd still need to make a unity file that places your control nodes, but you could load it with the other parts you're playing with to set all of your named transforms!  

[chrisl]

8 hours ago, artwhaley said:

I found someone with a working solution to your problem!   Porkjet's Habitats - which are now part of Tokomak Industries Refurbished Parts has multiple docking ports on a single part and he has written a plugin that lets them actually fully work.   I haven't combed the plugin's code yet, but wanted to keep you updated.  He ALSO did something really cool that I'd never thought of.  If you look at the cfg file for the hab with multiple docking ports (Habitat Pack Flat) you'll see that he used two .mu model files - one with the part... and another with JUST the control nodes.  You'd still need to make a unity file that places your control nodes, but you could load it with the other parts you're playing with to set all of your named transforms!  

Yup.  Tyko pointed out the Tokomak stuff earlier and I've been looking at them.  Haven't had a chance to test things out yet but I'm hoping I can use the control nodes .mu to avoid creating my own unity file.  I just have to have some free moments to put things together and test. 

[artwhaley]

I'm afraid you'll still have to do it yourself... because the position of those control nodes is important.  But making a unity file with a handful of empty game objects isn't the most difficult thing in the world.  I don't have it all set up right now or I'd volunteer...  I bet someone else will be happy to at some point soon.

I haven't looked at the license on PJ's plugin for handling it to see if you can distribute it yourself?

[chrisl]

Could you create a single "controlNode.mu", then use the position and rotate values of MODEL to position and point them in the correct direction?  But then, how would you tell the part which controlNode to use?  I guess at a minimum you'd need 6 of these empty models so that each could have it's own name.

[Wolf Baginski]

I just want to point at a Mod which uses a different .cfg structure for docking ports.

The standard stock docking port uses the normal numeric definition for a Node, and then the following code block:

	MODULE
	{
		name = ModuleDockingNode
		referenceAttachNode = top
		nodeType = size1
		stagingEnabled = False
	}

The nodeType can specify multiple sizes.

There's a multi-size docking port set from CaptainKipard that still worked up to v1.3.1, I haven't tested it with the v1.4.x generation yet, but this thread suggests it could work. Details are here.

The download links are to Mediafire, and you have to point them at the correct Domain now, the forum software changes the link because of the way Mediafire uses advertising. The stuff is still there.

The format for the nodes is like this:

NODE
{
	name = top
	transform = n_top
	size = 3
	method = FIXED_JOINT
}

After reading this thread, I think I get how it works. 

It then uses this for the docking process.

MODULE
{
    name = ModuleDockingNode
    nodeType = size0,size1,size2,size3
    referenceAttachNode = top
    nodeTransformName = n_top
}

I suspect that the method Captain Kipard's set uses involves a Unity structure of the sort artwhaley describes. Just getting the multiple sizes in the nodeType line works with the stock ports.

When I have made multiple port structures for stations, it all seemed to work better with some spacer components between the 6-way hub and the docking ports, making the hub effectively a size larger to give a bit more clearance between the radial ports

 

[chrisl]

Does that NODE method still work in 1.2.2/1.3.1?

[Wolf Baginski]

On 15/03/2018 at 8:05 PM, chrisl said:

Does that NODE method still work in 1.2.2/1.3.1?

Yes. It's used by some parts in the Making History expansion (which I don't have currently installed). Engine Plates, or is that the equivalent part on the SpaceY mods? It's a mounting for multiple engines.

I'm also using Captain Kipard's docking ports without problems.

There's nothing in the Wiki on this method that I can find, and some of the info on attachment nodes is looking very old. I reckon somebody who knows how this method work needs to write a Wiki page. It might not be wise for general use, but if that's true, we need to know why.

(This isn't they only place with user-created content that suffers from documentation gaps, and it inclines me to grumpiness. And, with staff turnover, if something isn't documented, sooner or later nobody is left who knows about it.)

[artwhaley]

the node{} tag is still supported.   

Yes, the name of the transform in that node definition refers to a unity game object that's invisible on it's own, but is inserted into the model's .mu file in Unity or Blender.

The Node{} definition creates an attachment node that's usable in the VAB to stick things on the part, or to attach the part to other part's snap nodes (green spheres).  It's function is identical to the old style where it's all spelled out numerically in the cfg  with the string of digits.

To document it here, the 4 parameters are the

• name that KSP will use for it,
• the transform name as specified in the unity file,
• the size parameter specifies how big the green sphere is in the VAB when you go to attach it to things.   Node size does NOT affect ability to attach - you can connect 0 to 2 all day long, for example.
• The joint type is always fixed...  and I believe changing this does nothing... but we all leave it in the file just in case someday KSP supports other types in node definitions.

The way that file defines the docking node still requires transforms in the file, and they'd still need unique names, unfortunately.  

• Nodetype DOES affect what you can connect a docking port to in the flight scene.  They must have the same number.  0  for junior, 1 for standard, 2 for sr.  other numbers for custom mods.  And as shown, you can specify compatibility with multiple sizes the way it's shown there.
• referenceAttachNode actually tells the docking port which node to use in the VAB for sticking things together, so that you're able to decouple it in flight successfully.  Without this, or with the wrong node named, and you won't be able to undock things that leave the VAB attached to your docking port!
• nodeTransformName is still specifying the unity game object that should be used as the docking port's capture point.  In your example it's pointed at the same empty unity object as the main attachment node, but it doesn't have to be!

Here's a link to a discussion Cap'n Kipard and I had about the subject  -  

 

[Wolf Baginski]

For me, the reassuring thing is that parts in the Making History DLC are using it. Node{} isn't going away soon. There are parts I use from mods that use Node{}

I am guessing a bit, but it sounds as though using Node{} uses a bit more memory, the overhead for extra Unity objects. That would add up if it were used for every part. Could be something else, CPU clock cycles maybe, but there are a lot pf parts. It would add up.

 

 

 

[chrisl]

So it sounds like no matter what I'd need to create a number of blank .mu files in Unity, each with a different transform name.  At least one for each docking port I wanted to include on a part.  I may have to look at setting up my system so I can create those.

[artwhaley]

3 hours ago, Wolf Baginski said:

For me, the reassuring thing is that parts in the Making History DLC are using it. Node{} isn't going away soon. There are parts I use from mods that use Node{}

I am guessing a bit, but it sounds as though using Node{} uses a bit more memory, the overhead for extra Unity objects. That would add up if it were used for every part. Could be something else, CPU clock cycles maybe, but there are a lot pf parts. It would add up.

 

 

 

An empty node is just a point in space with a name, a location and a rotation, essentially.   A minuscule amount of data.  And all of that data has to be available whether you're using node{} tags or specifying it numerically.   When you specify them numerically, KSP just creates the empty game objects for you.    There is no performance hit to using node{} tags.

 I'm not using bold text to yell at you!   I promise I'm not upset.   But a thing happens on this forum...  since so much of what we know about KSP is from trial and error and conjecture since we're not looking at their code.  Someone guesses something aloud... and someone else without the knowledge to confirm or refute it repeats it... and then it becomes law for 3 years.  lol.   Your original post where you admitted to hypothesizing gets forgotten and the other guy's post where he pronounces it with absolute certainty is the one people refer to.  So I wanted to make sure that those who come after in this thread saw my refutation! 

 

2 hours ago, chrisl said:

So it sounds like no matter what I'd need to create a number of blank .mu files in Unity, each with a different transform name.  At least one for each docking port I wanted to include on a part.  I may have to look at setting up my system so I can create those.

I really can't think of any way around it!   But your part making options will be greatly increased if you get used to it!   As an alternative to Unity.... I think you COULD also create your file in Blender with the .mu import/export plugin?   If you don't know either program...  it's a tossup... but if you have some blender experience, thought I'd mention it!

[Wolf Baginski]

There's a lot of stuff that lingers. I had become resigned to never being able to see what was in a .mu file, after seeing an old reference to the file format being specific to KSP, and now you just mention in passing that there is a Blender import/export tool. And there are dozens of web pages around which mention an English pub I know, with glowing reviews, which was closed 2 years ago, and was demolished last December.

Google gives us everything at once, an amorphous blob of knowledge encompassing every version of the transient truths there might be. And perhaps we might learn how unreliable history can be, and how the Mayflower was the B-Ark of the European adventure in the Americas.

Meanwhile, documentation isn't, bugs aren't, and features don't. Also, three shalt be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, nor either count thou two, excepting that thou then proceed to three. Five is right out.

[artwhaley]

LOL.  Documentation, like the stickies that still tell you to download Unity freaking 4?  Yeah.  There's regular rumbling about improving it... but it's a lot of work too.

But yes!   The blender import/export plugin will totally let you dissect a .mu to try to figure out how it worked!