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

[Tallinu]

That's perfectly alright, I run with the texture resizer anyway (so many mods!) - I'm not concerned with uber-detailedness. If you're going to make official 3.75m versions I'll wait for that instead of doing my own so I dont' have to deal with part name changes.

[CaptainKipard]

That's perfectly alright, I run with the texture resizer anyway (so many mods!) - I'm not concerned with uber-detailedness. If you're going to make official 3.75m versions I'll wait for that instead of doing my own so I dont' have to deal with part name changes.

If you want to do it yourself right now, I'll be adding "xl" (that's XL in lower case) to each of the names.

so kip6hubxl, kipihubxl, kiplhubxl, kipthubxl, kipxhubxl

[I.O.M.]

Sorry for the absence Kip, I've been busy with university stuff. The new config that you gave me to test seems to have solved the issue with the part enlarging.

[CaptainKipard]

Thanks for the confirmation. The latest version has that fix applied if you want to grab it.

[CaptainKipard]

==== Universal Docking Port Set ====

Changes:
- Replaced plugin with Toadicus' fixed plugin. It should work correctly now.

Edited June 1, 2014 by Cpt. Kipard

[ctbram]

Making these so they could be assembled in space would solve the huge problem of on orbit construction. Docking ports and KAS struts do not work!

[CaptainKipard]

Can you be more specific?

[phoenix_ca]

Would you consider using Gaius' TweakScale plugin for the hubs? http://forum.kerbalspaceprogram.com/threads/72567-0-23-5-Goodspeed-Aerospace-Parts-TweakScale-plugin-v2014-4-1B/page8

It'd save a fair bit of part spam in the VAB. Actually quite significantly by removing two thirds of the parts necessary. 5 parts for 15 different variations is a good deal.

Edited May 5, 2014 by phoenix_ca

[CaptainKipard]

Yes it's already on my to-do list, it's just that I'm juggling a few projects right now

Also the impression I got is that it's still a bit buggy.

[Eleven]

Any issues with this working with MM 2.1.0? I hadn't tried these with an earlier version of Module Manager so I don't know if there were issues there, but I can only get Universal ports of the exact same size to dock with each other, cannot mix sizes. I also cannot get the Clamp-O-Tron to dock correctly with the Large Universal. Looks like there is no 'magnet attraction' when there should be.

[komodo]

Rather severe bug to report: When combined with the SDHI ( http://forum.kerbalspaceprogram.com/threads/52362-0-23-5-Sum-Dum-Heavy-Industries-Service-Module-System-(V1-9-5-Apr-2014) ) clampotron/chute combo, it causes said combo to deploy on load. This makes launching rockets somewhat less then ideal. Bug traced to the adaptivedockingnode.cfg file in adaptivedockingnode/, but i'm afraid my modulemanager-fu is not up to deciphering the file. If i'm reading it correctly, it's outright removing the ModuleDockingNode and replacing it with ModuleAdaptiveDockingNode? Why would this cause the part to freak out? The part in question also defines referenceAttachNode = top, although i'm not certain of it's significance.

Any ideas?

[toadicus]

Any issues with this working with MM 2.1.0? I hadn't tried these with an earlier version of Module Manager so I don't know if there were issues there, but I can only get Universal ports of the exact same size to dock with each other, cannot mix sizes. I also cannot get the Clamp-O-Tron to dock correctly with the Large Universal. Looks like there is no 'magnet attraction' when there should be.

I haven't tried it at all with MM 2.1.0, but it works fine with 2.0.8.

Can you make sure you are running the latest version of the plugin? That fixes a major issue with the adaptive ports working properly. If you continue to have problems, please provide your debug log, a craft or persistence file that exhibits the problem, and a list of mods required to use it. Thanks!

Rather severe bug to report: When combined with the SDHI ( http://forum.kerbalspaceprogram.com/threads/52362-0-23-5-Sum-Dum-Heavy-Industries-Service-Module-System-(V1-9-5-Apr-2014) ) clampotron/chute combo, it causes said combo to deploy on load. This makes launching rockets somewhat less then ideal. Bug traced to the adaptivedockingnode.cfg file in adaptivedockingnode/, but i'm afraid my modulemanager-fu is not up to deciphering the file. If i'm reading it correctly, it's outright removing the ModuleDockingNode and replacing it with ModuleAdaptiveDockingNode? Why would this cause the part to freak out? The part in question also defines referenceAttachNode = top, although i'm not certain of it's significance.

Any ideas?

You're misreading the cfg slightly, but that doesn't help much in explaining the problem. In fact, MADN does not remove or replace the ModuleDockingNode; it is a helper module that operates alongside it. The incompatibility you're seeing is surely because MADN activates the part during its startup... I don't remember why, but it does. Calling activate on the part is basically the same thing as pressing "space" to activate the stage containing it, so the RealChuteModule is arming, or deploying, or whatever it is those modules do when you activate them.

The good news is that's probably something I can fix pretty easily. The bad news is there's nothing you can do to fix it. If you wanted to hack in a modulemanager patch to prevent MADN from being added to parts that contain a RealChute module, you could add this patch to the end of AdaptiveDockingNode.cfg:

PART[*]:HAS[MODULE[ModuleAdaptiveDockingNode],MODULE[RealChuteModule]]
{
	!MODULE[ModuleAdaptiveDockingNode] {}
}

That will prevent any of the paradock parts from becoming adaptive ports, which in turn means that you will be unable to dock them to adaptive ports of a different size when you are "driving" with the vessel containing the paradock part.

I'll see about working up a proper fix Soon.

[toadicus]

Double posting because releases are worth making sure you all see it.

I've updated AdaptiveDockingNode to 1.2; available at SpacePort and not at SpacePort ([.zip] [tar.gz] [tar.xz]). Should fix the SDHI incompatibility!

[komodo]

Whoa, fast turnaround. Thanks very much both for the explanation and fix! Kudos!

[Eleven]

I haven't tried it at all with MM 2.1.0, but it works fine with 2.0.8.

Can you make sure you are running the latest version of the plugin? That fixes a major issue with the adaptive ports working properly. If you continue to have problems, please provide your debug log, a craft or persistence file that exhibits the problem, and a list of mods required to use it. Thanks!

I just snagged this latest plugin you just posted, and tried it with MM2.1.0 and 2.0.8 but still get the same issues. Docking with different types of ports of the same size is OK. Clamp-O-Tron docks just fine with the Universal Medium. Universal ports of the same size dock with each other as well, but...nothing of different sizes will dock with each other, not even the Universal ones. They just bounce off of each other, and trying 'face target' makes them circle and wobble, like they can't actually center themselves on the target.

I built an almost stock craft to test the docking, I think the KW large dock is the only non-stock piece, other than the Universal Ports. I have KW, and other bits and pieces of other mods installed, but they aren't on these test crafts so that doesn't matter does it? I have Docking Port Alignment and MechJeb installed too.

Here is the craft, it's messy but I wanted one craft with all the docking ports to test with Docking Test Craft

And here is the KSP log Log File

EDIT - I checked the ship and it also has the camera from RPM on it.

Edited May 6, 2014 by Eleven

[CaptainKipard]

Toadicus, could you keep a changelog?

[ctbram]

Double posting because releases are worth making sure you all see it.

I've updated AdaptiveDockingNode to 1.2; available at SpacePort and not at SpacePort ([.zip] [tar.gz] [tar.xz]). Should fix the SDHI incompatibility!

ah thanks I was jsut about to post about the sdhi and realchute incompatibility. I was getting chute deployment on ship load to the pad and so I'd get the nastygram from shdi paradock about not being able to deploy the chute until negative vertical velocity.

I will check the updated adaptivedockingnode and let you know if it fixes the problem. I will also update my post over on the realchute page. My last post identified adaptivedockingnode mod as the cause of the problem before I saw this post.

[ctbram]

okay update guys - I installed the updated AdaptiveDockingNode 1.2 patch to univDockingPort and it fixed the chute deploy on craft load to the launch pad. But I see from another post that there might still be an issue with docking port type combinations so I will keep a watch on the this thread for updates. I will post an update over at the realchute forum as well.

[CaptainKipard]

At the very least the docking ports work the same as stock, so you can still use them in place of stock ones. The plugin seems to be a bit temperamental. It works in some situations and not others.

[toadicus]

I just snagged this latest plugin you just posted, and tried it with MM2.1.0 and 2.0.8 but still get the same issues. Docking with different types of ports of the same size is OK. Clamp-O-Tron docks just fine with the Universal Medium. Universal ports of the same size dock with each other as well, but...nothing of different sizes will dock with each other, not even the Universal ones. They just bounce off of each other, and trying 'face target' makes them circle and wobble, like they can't actually center themselves on the target.

I built an almost stock craft to test the docking, I think the KW large dock is the only non-stock piece, other than the Universal Ports. I have KW, and other bits and pieces of other mods installed, but they aren't on these test crafts so that doesn't matter does it? I have Docking Port Alignment and MechJeb installed too.

Here is the craft, it's messy but I wanted one craft with all the docking ports to test with Docking Test Craft

And here is the KSP log Log File

EDIT - I checked the ship and it also has the camera from RPM on it.

So, I haven't tried to load up the craft yet, but that log is chock full of exception spam. At least the following mods are causing exceptions during program startup:

• 'ExsurgentEngineering'
  
• 'MechJebRPM'
  
• 'SCANsatRPM'
  

The same three also throw an exception during the part compile phase when MechJeb tries to register them in its moduleRegistry.

Since you included KSP.log and not output_log.txt, I can't tell specifically what some of the other exceptions come from. Later, there are literally dozens of NullReferenceException tosses during what could be Awake, Start, or early Update passes (i.e. during or immediately after loading a vessel), then hundreds more from MechJebModuleDockingAutoPilot probably right after a docking event.

KSP doesn't do a great job of making sure that various mod code runs unimpeded when another mod fails to handle an exception. While some of the exceptions in your log are "normal" and I've seen them not make a big deal (mostly to do with clouds, a couple that KSP throws), the exceptions during flight and vessel startup are almost certainly preventing ModuleAdaptiveDockingNode from starting itself properly. When it can't do that, it refuses to do anything and the docking ports are literally no different than stock ports.

I would start by removing those three plugins and see if your problem persists. If it does, this is an issue for the author of those mods. If it doesn't, grab this debug dll, overwrite GameData/AdaptiveDockingNode/AdaptiveDockingNode.dll, run the test again, and report back here.

Toadicus, could you keep a changelog?

Yes; I will start maintaining a release thread in Addon Development, since my plugin isn't useful without a parts mod like yours to give it life. In the meantime, you can follow the git changelog here.

At the very least the docking ports work the same as stock, so you can still use them in place of stock ones. The plugin seems to be a bit temperamental. It works in some situations and not others.

okay update guys - I installed the updated AdaptiveDockingNode 1.2 patch to univDockingPort and it fixed the chute deploy on craft load to the launch pad. But I see from another post that there might still be an issue with docking port type combinations so I will keep a watch on the this thread for updates. I will post an update over at the realchute forum as well.

I am very interested to hear more stability reports. Since the 1.1 release I've only heard from Eleven, whose helpful log inclusion suggests (to me) that the problems he's having are nothing to do with MADN. It's possible that I could beef up its fault tolerance and try to "restart" the module if it doesn't get started properly, but there's nothing I'm ever going to be able to do about a bunch of Exception spam during FixedUpdate from other mods.

Do the adaptive docking nodes work for you? Do they not? When don't they? Thanks, all.

[Eleven]

So, I haven't tried to load up the craft yet, but that log is chock full of exception spam. At least the following mods are causing exceptions during program startup:

• 'ExsurgentEngineering'
  
• 'MechJebRPM'
  
• 'SCANsatRPM'
  

The same three also throw an exception during the part compile phase when MechJeb tries to register them in its moduleRegistry.

Since you included KSP.log and not output_log.txt, I can't tell specifically what some of the other exceptions come from. Later, there are literally dozens of NullReferenceException tosses during what could be Awake, Start, or early Update passes (i.e. during or immediately after loading a vessel), then hundreds more from MechJebModuleDockingAutoPilot probably right after a docking event.

KSP doesn't do a great job of making sure that various mod code runs unimpeded when another mod fails to handle an exception. While some of the exceptions in your log are "normal" and I've seen them not make a big deal (mostly to do with clouds, a couple that KSP throws), the exceptions during flight and vessel startup are almost certainly preventing ModuleAdaptiveDockingNode from starting itself properly. When it can't do that, it refuses to do anything and the docking ports are literally no different than stock ports.

I would start by removing those three plugins and see if your problem persists. If it does, this is an issue for the author of those mods. If it doesn't, grab this debug dll, overwrite GameData/AdaptiveDockingNode/AdaptiveDockingNode.dll, run the test again, and report back here.

I kept looking for output_log, but I don't think linux uses that. Are you talking about player.log? If so, HERE it is. I removed all three of those plugins and the problems remained. (Haven't tried your debug dll yet, will do that next)

EDIT----- HERE is the KSP log file and HERE is the Player log file from your debug dll attempt to dock with 2 different sizes of the Universal Ports.

Edited May 6, 2014 by Eleven

[Thourion]

Dont forget to update the "Universal Docking Ports" link in the OP. Because it still includes the older AdaptiveDockingNode dll in spaceport.

[toadicus]

I kept looking for output_log, but I don't think linux uses that. Are you talking about player.log? If so, HERE it is. I removed all three of those plugins and the problems remained. (Haven't tried your debug dll yet, will do that next)

EDIT----- HERE is the KSP log file and HERE is the Player log file from your debug dll attempt to dock with 2 different sizes of the Universal Ports.

Thanks for that! Those logs pointed me right where I needed to look.

So the problem was this: in order to avoid looping through all the vessels every physics frame looking for potential docking nodes, I filter out all of the vessels that are "too far away" to be useful. Only I was being too aggressive (way too aggressive actually; I had failed to square a multiplication factor), so it was filtering out even very nearby vessels if the vessel was significantly large such that its center of mass was too far from the port you were trying to use. I've changed that to a flat number now; instead of basing it on the port's acquireRange, it's now just "1000 meters". So if you've got a vessel more than 1km long... you might have trouble docking to it. But, that value is now pulled from a config.xml file in AdaptiveDockingNode/Plugins/PluginData/AdaptiveDockingNode (created after you load a port for the first time), so if you need to make it bigger, make it bigger. If you feel like performance is not as good as it should be, make it smaller (100 meters is probably still reasonable).

Here's a new copy of the debug dll. It should also be way friendlier to use while testing. If you could give it another go I'd really appreciate it, and I'll get another release out tonight.

[Eleven]

Thanks for that! Those logs pointed me right where I needed to look.

So the problem was this: in order to avoid looping through all the vessels every physics frame looking for potential docking nodes, I filter out all of the vessels that are "too far away" to be useful. Only I was being too aggressive (way too aggressive actually; I had failed to square a multiplication factor), so it was filtering out even very nearby vessels if the vessel was significantly large such that its center of mass was too far from the port you were trying to use. I've changed that to a flat number now; instead of basing it on the port's acquireRange, it's now just "1000 meters". So if you've got a vessel more than 1km long... you might have trouble docking to it. But, that value is now pulled from a config.xml file in AdaptiveDockingNode/Plugins/PluginData/AdaptiveDockingNode (created after you load a port for the first time), so if you need to make it bigger, make it bigger. If you feel like performance is not as good as it should be, make it smaller (100 meters is probably still reasonable).

Here's a new copy of the debug dll. It should also be way friendlier to use while testing. If you could give it another go I'd really appreciate it, and I'll get another release out tonight.

Cool, got two different sizes to dock with each other, but it took 3 tries, I had to set both crafts to dock with each other with mechjeb to get them to line up perfectly. The first two tries it wasn't PERFECT so they just bounced off each other. But in the end it did work, so thats good! Here is the KSP log file and Here is the Player log from this try!

[CaptainKipard]

Are you saying that your haphazard docking is at fault? Or is the plugin still not working?

Edited May 6, 2014 by Cpt. Kipard