[Discontinued] AdaptiveDockingNode 1.7 - Make Your Awesome Docking Port Models Universal!

[toadicus]

Give me until after October 4th and I'm game. I've got a Big Professional Licensure exam on the 4th and what with family, work, and studying I've got no time right now. Things will let up after the 4th and at that point I'll absolutely be up for it.

[CaptainKipard]

Ok. I'll just leave this here then so that when you're ready you can think about how realistic you want to make it. Probe and drogue docking systems have moving parts, the most obvious of which is the probe which extends quite far before docking.

[toadicus]

So, thinking about this... there are a few of ways I can think of to consider approaching it.

First, the "do nothing" option. If you can construct the colliders and place the node transform in such a way that the two modules won't acquire until you get the "ATV" extension into the socket, you can make ports that will provide a nominally-gendered behavior without any plugin support. The parts won't move or turn you into alignment, but it'll be easier to maintain and to use.

Second, the "gendered plugin" option. If building the parts like that just doesn't work or is way too hard (I have no idea), I can add some simple functionality to ADN to enforce gendered docking when relevant.

Finally, the "fully articulated parts" option. If you actually want the parts to push and pull and grip and twist as indicated in that diagram, I'll get in touch with sirkut and see if I can find a way to do an Inferal Robotics-powered plugin that will do all those awesome things before actually docking the vessels. If I recall correctly, IR has some limitations related to pistons and docking, so some parts of the movement may be Very Challenging. But, it'd be awesome.

[CaptainKipard]

First, the "do nothing" option. If you can construct the colliders and place the node transform in such a way that the two modules won't acquire until you get the "ATV" extension into the socket, you can make ports that will provide a nominally-gendered behavior without any plugin support. The parts won't move or turn you into alignment, but it'll be easier to maintain and to use.

Actually afaik ATV is the name of the ship Automated Transfer Vehicle. It's not a component of the docking system.

This option is... an option, but it'll still need a variation of the adaptive node because the male and female ports should always be hetero, as it were. Stock docking nodes don't make that distinction.

It would require something like this for male:

MODULE
{
	name = ModuleGenderedDockingNode
	nodeType = size2
	gender = male
}

and for female:

MODULE
{
	name = ModuleGenderedDockingNode
	nodeType = size2
	gender = female
}

Other sizes should also be available. 0 - 4 like before should be fine. Only ports of same type/size and opposite gender should be allowed to dock.

Second, the "gendered plugin" option. If building the parts like that just doesn't work or is way too hard (I have no idea), I can add some simple functionality to ADN to enforce gendered docking when relevant.

Yes. By the way gendered docking ports should not be allowed to dock to any other ports at all.

Finally, the "fully articulated parts" option. If you actually want the parts to push and pull and grip and twist as indicated in that diagram, I'll get in touch with sirkut and see if I can find a way to do an Inferal Robotics-powered plugin that will do all those awesome things before actually docking the vessels. If I recall correctly, IR has some limitations related to pistons and docking, so some parts of the movement may be Very Challenging. But, it'd be awesome.

If you could get something like this working that would be a lot of fun for players who play KSP as a simulator, myself included.

[toadicus]

So, what I meant in option 1 is to arrange the transforms in such a way that getting them to be close enough to trigger docking is physically impossible with nongendered ports. It might take some tricky geometry, but since the default acquire distance is 1 meter, if you positioned the transforms such that a nongendered or incorrectly gendered port couldn't physically get closer than 1.5 meters from the transform, undesired ports would never be able to dock with it. Again, I don't know if that's really a thing that will work with the geometry you have in mind, or if it's possible to build parts that way, etc, but I feel like it should be.

If the male geometry is long and narrow, you can put the transform 1.5 meters (or whatever) behind the tip. If the female geometry is correspondingly deep and narrow, you can again put the transform 1.5 meters behind the opening. Any nongendered port (which it blunt and has its transform right on the surface) will not be able to get closer than 1.5 meters, so it will never be able to dock. Then we could use a node type like "size2_gendered", which would work just fine in the existing logic but would make sure that no amount of shennanigans with non-gendered ports could make a dock happen. We could then also play with all these numbers so you could have differently-sized ports, etc.

I'll touch base with sirkut about what he thinks in terms of the more advanced plugin. In the meantime, I don't know anything about how the parts need to be designed to get all of that motion involved; you might want to talk to ZodiusInfuser if you haven't already.

[CaptainKipard]

So, what I meant in option 1...

I see. Yes, I could hide the docking node inside the drogue part, so that nothing else can dock apart from the probe part, but unfortunately there's no way that I can think of that would prevent the probe parts from docking with each other. The simplest way to make it work without breaking immersion is to re-use the checking code for gender and not animate anything.

I'll touch base with sirkut about what he thinks in terms of the more advanced plugin. In the meantime, I don't know anything about how the parts need to be designed to get all of that motion involved; you might want to talk to ZodiusInfuser if you haven't already.

Animations and collisions aren't a problem. As long as everything else is working I should be able to create a set of parts that align mechanically (or at least close enough). The only problem I can see at the moment is how to make the probe latch onto the inside of the drogue port reliably and consistently before the actual docking. You can then tell the part to play the animations in sequence, and finally unlatch and dock.

Are you able to execute the magnet and docking function at will, or will it always start to attract the other port when it's close?

[toadicus]

AdaptiveDockingNode has been updated to version 1.5.1! This update is nothing but a recompile against the KSP 0.25 assemblies.

Cpt. Kipard, I know I owe you an answer. Trying to finish my follow-up first.

Changelog

v 1.5.1 [2014-10-07]
* Updated for KSP 0.25.

[Gaalidas]

File does not exist. Error, Error... everybody panic... .... well... are you panicking yet? No? Come on people... work with me!

[toadicus]

Fixed! Apparently my magical deployment script is slightly less magical than I thought. Thanks for letting me know.

[CaptainKipard]

follow-up

What's that?

[toadicus]

Kip, see your PMs from me.

[CaptainKipard]

Kip, see your PMs from me.

Yes already saw it. I understand the need for discretion, but my inbox is almost full and I need to hash out some details before uploading any model.

@sirkut

Are you ok specifying what components you want? I have the model almost done, I just need to know how to refine it according to what functionality will be available to us.

[CaptRobau]

Any news on gendered docking ports?

[toadicus]

There's been some talk between sirkut and Cpt. Kipard about mechanizing them, and I think that's generally unresolved pending some future work that sirkut has cooking. I'll be adding simple "magic" gendered support to ADN in the near future.

[toadicus]

Cross-posting from Kip's development thread:

Pending [sekrit new things from other people], I'm going to go ahead and implement an optional gender restriction in ADN. Unless you strongly disagree, I'm going to continue using the "helper module" approach, so the parts can be used without the plugin (though they won't behave like gendered ports in that case).

A sample part definition might include something like this:

MODULE
{
	name = ModuleDockingNode
	nodeType = size2
}

MODULE
{
	name = ModuleAdaptiveDockingNode
	ValidSizes = size2
	Gender = male
}

The Gender field will be optional. No or invalid definition will result in non-gendered behavior (as we have currently); male or female (or any other capitalization thereof) will result in enforced gendered behavior.

Specifically, ADN will obfuscate the ModuleDockingNode's "nodeType", to prevent Squad's code from recognizing the ports as a match. When ADN detects an appropriate match (same size in ValidSizes, opposite gender), it will swap the types to something consistent (but still incompatible with other ports), and Squad's code will do docking as normal.

I can manipulate the magnet force in a variety of ways, including just shutting it off entirely (technically so can you, by manipulating acquireRange in your ModuleDockingNode definition). But, to keep things playable without a mechanized solution, you'd need to have your colliders matched perfectly so players can get the transforms lined up appropriately. If you have a specific behavior in mind let me know.

I have messed around with requiring a specific rotation for TweakableEverything, and I recall Squad's code for it basically just didn't work. With ADN I can probably revisit that, if it's something you want for this.

Edited October 29, 2014 by toadicus

[CaptRobau]

That's awesome. While the mechanized version would put KSP into another league of realism, I'm also happy with magnetic gendered docking nodes.

[ctbram]

Is this mod supposed to allow a clamp-o-tron jr and normal clamp-o-tron to dock? It did not work but I am using the SDHI clamp-o-tron. Is there something I need to do to make this work?

[sidfu]

one of them ctbram probaly didnt have the module from this mod added to it. can anyone post a mm cfg that would add it to all docking ports. i cant seem to get it right

[CaptainKipard]

The MM configs aren't set up to allow different sizes in stock to dock to eachother, if that's what you're asking.

You can dock to the Universal Ports with anything only because they're set up to accept various sizes in the cfg. Have a look through the configs and MM configs for the differences.

[ctbram]

The MM configs aren't set up to allow different sizes in stock to dock to eachother, if that's what you're asking.

You can dock to the Universal Ports with anything only because they're set up to accept various sizes in the cfg. Have a look through the configs and MM configs for the differences.

Okay so what is the MM patch set up for? Can it be made to work with stock docking ports? Does it only work with kip universal docking ports. The documentation is very vague and ambiguous!

The first post has two little code snippets but I don't know what to make of them. Not everyone understands MM patches. To work are we supposed to make some kind of MM cfg file? Instructions or better yet examples would be helpful for those of us that are not mod'er and do not know how to write MM patch files.

Edited December 2, 2014 by ctbram

[CaptainKipard]

Tell me precisely what you want to happen with what ports.

[ctbram]

Tell me precisely what you want to happen with what ports.

Well

1. I would like the stock ports to act like the kipeng universal ones. IE 0.625 <> 1.25 <> 2.5 <> 3.75.

2. I would like to also be able to dock to the SDHI 1.25 paradocking port

3. I would like to also be able to dock to the OKS 1.25 docking port.

At the moment I have a bunch of ships in orbit that cannot dock to each other and I do not want to have to de-orbit them to make the docking port compatible. Here is a screen shot as just one example. It's the SDHI and OKS docking rings and they just bounce off each other and I cannot dock!!!! The screen shot below is after I contacted dead center and bounced off. I have drifted off center a bit when I grabbed the image. I just wanted to show the oks docking ring and the SDHI rings was an example of what I would like to dock.

As mentioned above I cannot dock clap-o-tron jr to normal clamp-o-tron.

I know that adaptiveDockingNode was originally written for kips universal docking ports but I thought it was made to work with all the stock ports as well??? Is there some kind of config I am missing?

Edited December 3, 2014 by ctbram

[CaptainKipard]

First of all, if you want to change ports that you already launched, I'm pretty sure you'll have to edit the save files, and I'm not comfortable with that enough to give you advice.

Well

1. I would like the stock ports to act like the kipeng universal ones. IE 0.625 <> 1.25 <> 2.5 <> 3.75.

2. I would like to also be able to dock to the SDHI 1.25 paradocking port

3. I would like to also be able to dock to the OKS 1.25 docking port.

At the moment I have a bunch of ships in orbit that cannot dock to each other and I do not want to have to de-orbit them to make the docking port compatible. Here is a screen shot as just one example. It's the SDHI and OKS docking rings and they just bounce off each other and I cannot dock!!!! The screen shot below is after I contacted dead center and bounced off. I have drifted off center a bit when I grabbed the image. I just wanted to show the oks docking ring and the SDHI rings was an example of what I would like to dock.

As mentioned above I cannot dock clap-o-tron jr to normal clamp-o-tron.

If you want every single docking port ever to be able to dock with every other port, then you don't need this plugin for that. Just create a MM config that changes all nodeTypes to the same value.

@PART[*]:HAS[@MODULE[ModuleDockingNode]]
{
	@MODULE[ModuleDockingNode]
	{
		@nodeType = potato
	}
}

I know that adaptiveDockingNode was originally written for kips universal docking ports but I thought it was made to work with all the stock ports as well??? Is there some kind of config I am missing?

The plugin here includes a MM config for stock nodes and the KW 3.75m docking ring to make them compatible only. It doesn't change what sizes that you can dock to them.

[toadicus]

The MM patch included in this mod sets up all docking ports that declare themselves as "size0" (0.625 by convention), "size1" (1.25 by convention), and "size2" (2.5 by convention) as "single-size" adaptive nodes so that multi-size adaptive nodes will properly change size to match them if they can. It also configures the 3.75m docking ring ring from KW rocketry as a two-size "size2" and "size3" docking node.

Kip's ports ship with configs that set up each port as a multi-size port capable of accepting any size smaller than itself. So, Kip's 1.25m port can dock to any "size1" and "size0" port, but could only dock to a "size2" port if that port itself was able to adapt down to "size1" (by default, only Kip's 2.5m port can do this).

To add available sizes to a given node type, you can add those sizes in a comma-delineated list to the "ValidSizes" line for the relevant size. For example, if you wanted to make every "size1" port ever able to dock to "size0" ports also, you would change the second patch (with HAS[#nodeType[size1]] in the specifier) to this:

@PART[*]:HAS[!MODULE[ModuleAdaptiveDockingNode],@MODULE[ModuleDockingNode]:HAS[#nodeType[size1]]]:FOR[AdaptiveDockingNode]
{
	MODULE
	{
		name = ModuleAdaptiveDockingNode
		[b]ValidSizes = size0,size1[/b]
	}
}

I didn't do that because the stock ports clearly aren't modeled with interoperability in mind. That's unlikely to change in the official distribution, but if you want pointers on learning how to change MM configs, I'm happy to help out.

I can't tell from your screenshot which SDHI ports you're using, or which one is the MKS port, because I don't know what they look like. But from the looks of things, SDHI's Service Module System ships with two docking ports, the "IACBM 1.25m - Parachute version" and the "Clamp-O-Tron Docking Port - Parachute version". The latter has a normal "size1" nodeType in its ModuleDockingNode definition, so it will get the adaptive module from my MM patch and should happily dock to any other "size1" port, or any larger port with "size1" in the ValidSizes list (as shipped, only Kip's 2.5 and 3.75 ports). The former, however, has a non-standard nodeType of "IACBM_125" which means that it was intentionally designed not to dock to Squad's ports or any other ports conforming to Squad's "size0", "size1", "size2" convention. None of my patches nor Kip's ports ship with configs that allow them to adapt to "IACBM_125". No other ports will dock to that port, with or without my or Kip's mods.

I've never even looked at SDHI before, so I have no idea why sumghai opted to keep the IACBM ports incompatible, but I can tell you that he did it on purpose so he's probably got a reason. If you don't care and want those ports to dock to everything else anyway, you could add a ModuleManager patch like this:

@PART[*]:HAS[!MODULE[ModuleAdaptiveDockingNode],@MODULE[ModuleDockingNode]:HAS[#nodeType[IACBM_125]]]:FOR[AdaptiveDockingNode]
{
	@MODULE[ModuleDockingNode]
	{
		@nodeType = size1
	}

	MODULE
	{
		name = ModuleAdaptiveDockingNode
		ValidSizes = size0,size1
	}
}

ModuleManager patches can go in literally any text file ending in ".cfg" within the GameData folder.

That patch will change the IACBM port to a standard "size1" port, and allow it to be downwards-compatible with "size0" ports.

Edited December 3, 2014 by toadicus

[toadicus]

Cross-posting from Kip's development thread:

Kip, I've finally got a chance to test the gendered port code I worked up at the end of October, and based on preliminary lab tests, it works!

Here's a zipball of the latest plugin. To test it (in the absence of actual gendered parts), I used this patch:

// Kip's 1.25m docking port
@PART[kipunivdockport125]
{
	@MODULE[ModuleAdaptiveDockingNode]
	{
		Gender = female
	}
}

// Squad's shielded docking port
@PART[dockingPort1]:AFTER[AdaptiveDockingNode]
{
	@MODULE[ModuleAdaptiveDockingNode]
	{
		Gender = male
	}
}