[WIP] Kip Engineering: Now updating - Universal Docking Ports

[CaptainKipard]

This is the thread for all my small projects

Now updating:

---

Universal Docking ports.

To-do list:

• Optional dorsal, ventral, port and starboard RCS thrusters (maybe)
  

Other projects

---

Science-Bus-a; A Hayabusa-inspired capsule for Kerbin LKO re-entry

The purpose of this mod will be to carry two science containers from LKO to Kerbin surface. The mod when used will be made up of three parts to decrease physics interactions.

To-do list:

Probe part will contain

• Probe core
  
• Reaction wheels
  
• SAS
  
• RCS + Monoproellant
  
• Battery
  
• Parachute
  
• Jr-size Docking port
  
• Antenna
  
• Optional DRE config
  

Science container will include

• Science storage
  

The storage part will be attached to the main core in pairs.

---

Station hubs.

To-do list:

• Minor texture work
  
• Add Tweakscale functionality (possibly)
  
• Remove :FINAL from Life support MM patch.
  

---

Edited November 11, 2015 by Cpt. Kipard

[Dave7]

Does your small port dock with the other multiports? Just a guess but it sounds like the multiple docking modules are fighting against each other. You may be able to set the acquireForce and acquireTorque config settings to help with that.

[CaptainKipard]

The parts dock fine with stock docking ports, but when trying to dock one multiple port to another multiple port the ships just dance around, but never actually dock.

101010101010

[CaptainKipard]

I released the parts anyway. These two problems kind of go hand in hand. It doesn't make sense to fix one without also fixing the other one. If anyone thinks of something let me know. In the meantime go build some space tugs.

[PringleMan]

I don't think that the problem will be solved without making a plugin and coding your own transforms for the docking motion in. Which is unfortunate. I still really like them though!

[CaptainKipard]

...coding your own transforms for the docking motion...

What's this?

Edited March 30, 2014 by Cpt. Kipard

[CaptainKipard]

Testing has left me with even more questions than answers.

I've found that multi-node ports can indeed dock and undock. After several seconds of wiggling the ship around the docks finally connected. It looks as if all the nodes that have an equivalent node on the target universal port actually connect. It still takes way too much effort to make it work though. After I docked when I right click it gave me multiple "Undock" buttons. All of them have to be clicked and then the docks separate.

I think the only way you wouldn't be able to undock multi-node docking ports is if they start docked in the VAB or SPH.

[landeTLS]

Your project Looks interesting. Id suggest looking at the kw 3.75m docking port model as it docks both to itself and to 2.5m stock docking ports. I have a quite different dockingport design in the modelling/rigging stage that is going to be adjustable to different sizes(via animations or use of the infernal Robotics plugin). Im kindof worried about how to make that thing work ingame:P

[CaptainKipard]

That KW docking port has only one ModuleDockingNode. It's nodeType is size2 meaning that, as you said, it'll dock to itself without hassle and to other 2.5 meter ports. It will not dock to a nodeType size3 docking port.

Basically it just looks big, but technically it's a 2.5m part.

Edited March 30, 2014 by Cpt. Kipard

[landeTLS]

That KW docking port has only one ModuleDockingNode. It's nodeType is size2 meaning that, as you said, it'll dock to itself without hassle and to other 2.5 meter ports. It will not dock to a nodeType size3 docking port.

Basically it just looks big, but technically it's a 2.5m part.

O i didnt know that. From the design of the model it looks like it was invisioned to be a double transform docking port but i guess they couldnt figure out how to solve the problem youre facing

[PringleMan]

What's this?

When you know how in unity when you are adding the transforms to the model in order to achieve certain behaviors? Like for example the direction of motion that the docking magnetism is supposed to follow. Or with engines, the direction of thrust and particles.

The problem is that KSP only has one type of dock, with three different "sizes" to help the parts distinguish each other. For your universal ports, you would have to write a plugin that either A) Recodes how docking ports work (ouch) or Write a plugin that allows the part to undock ALL modules docked with it. If the game is not crashing when you have them docked together I don't think it is really complaining that one part has multiple dock nodes on it, it just is unsure how to control it. I mean the plugin could be as simple as a script to feed the undock command to all three sizes of docking node when you hit the undock button in the UI. Then, until you can get the UI duplication issue sorted out, have the button labeled as "Undock this one" or something.

[CaptainKipard]

Option B on it's own doesn't fix the problems with docking in the first place, which is the bigger problem.

Someone would have to write the plugin for me. One thing that could maybe work is checking the nodeType of the target docking port as soon as magnetism kicks in, and then disable all modules that do not have the same nodeType. I don't know if that's possible. I CAN code but i can't be bothered without official API documentation. It's too much work having to figure things out for yourself.

[Matzilla]

Not much of a programmer here, but wouldn't it be fairly simple to have these parts have a single docking node and there own class (ex: 4) so that they could dock with each other universally. They wouldn't dock with the stock parts but they look so cool I know that I won't bother using the stock ports if these can freely dock/undock with each other universally.

Just a thought.

[CaptainKipard]

I was aware of this, but I wanted these to be compatible with the stock ones.

It's a good thought; I think I might just include optional cfgs for people who want to play without stock ports.

Yeah. I'll do that.

[Tallinu]

From the changelog for the structural parts: "- Moved T hub center of mass to be more realistic"

This would imply that some mass has been removed from the part of it where the 4th connection would otherwise have been. Now unless that mass was added back in elsewhere in the structure, that implies that removing a connecting surface reduces the mass of the part. So, even if the small 6-way node is the same mass as the stock node (which I think is heavier than it has any right to be, comparing it to other structural components), I'd suggest giving the 4-way, 3-way, and 2-way parts progressively reduced mass.

If the 6-way node is 1.5 tons, the 4-way could be 1.25, the T 1.125, and the L and I nodes, 1 ton. Personally I would use no more than 1 ton for the small 6-way node, and the others could be .75, .625, and .5 respectively. I mean, really, how thick does the paneling on top of the internal structural supports have to be?

For the 2.5m and 3.75m versions, I'd stick with simply multiplying the mass by 2 and 3. Someone might make an argument about mass being related to volume which is the cube of the part diameter/length, and that's true for solids. But if these parts are traversable by kerbals, they are by definition hollow, meaning it's at most the square of the size (surface area). Further, the main structural strength isn't going to come from the outside paneling but instead, the beams of metal (or whatever material their internal frame is built from), the mass of which would scale linearly with part size. So the truth would be somewhere between linear and square, probably closer to linear (maybe size ^ 1.25). But most importantly, playability: 9 tons (3 squared) for a 3.75m part that does absolutely nothing other than serve to connect other large parts together would simply not be very usable. That's something you can technically do with a .125 ton girder segment and a couple of struts, after all.

So I'd suggest a simple linear scaling of the masses, for example:

1.5, 1.25, 1.125, 1.0

3.0, 2.5, 2.25, 2.0

4.5, 3.75, 3.375, 3.0

or

1.0, .75, .625, .5

2.0, 1.5, 1.25, 1.0

3.0, 2.25, 1.875, 1.5

for the small, medium, and large 6, 4, 3, and 2-way parts respectively. Factoring in an exponent of 1.25, 2.0 and 3.0 become approximately 2.5 and 4.0, so for slightly greater realism the last two lines could instead be:

2.5, 1.875, 1.5625, 1.25

4.0, 3.0, 2.5, 2.0

I hope this is at least food for thought, if not helpful or useful.

[CaptainKipard]

Great analysis, thank you. I'll implement this in the next update. I'm just not sure about the I-Hubs and T-Hubs being lighter than the 6-Hubs of a smaller diameter. Why did you do it like that?

[Tallinu]

Hmm, if you mean the 3.75m I and L parts (the final 2.0 in my last post), I hadn't really thought about the fact that it made them lighter than the 2.5m 6-way part. Still, I don't think there's anything necessarily wrong with that. It could probably be explained by a couple things: the fact that 3.75m parts are only 50% larger than 2.5m parts, and the last post's reasoning regarding the internal structural members being the majority of the part mass. The internal crew tunnels don't need to get any wider either, so that's yet another factor that would scale linearly.

Still, if the given mass reductions for the less-than-6-way parts seem too great, those amounts *were* pretty much off the top of my head. I was looking for relatively easy numbers that made at least *some* sense. The results of that ended up implying that 3/4 of the part mass was in the internal and external structures of the connection faces, which may be a bit on the high side. But 50 / 6 doesn't result in easy to work with numbers. Maybe 60% would be more reasonable. That would give the following masses:

Connections:  6w     X     T      I & L
(1.25m)       1.0    0.8   0.7    0.6
(2.5m)        2.5    2.0   1.75   1.5
(3.75m)       4.0    3.2   2.8    2.4

That would result in a much less noticeable difference between the 3.75m I & L parts and the 2.5m 6-way part. Now that I've put some thought into that, I think I prefer this set of numbers.

[CaptainKipard]

Those look good to me. I'll use them. Thanks for helping.

[stoland]

Looking good.

[MaverickSawyer]

Possible bug, needs confirmation...

RealChute does not play nice with the provided plugin, causing the parachute to deploy upon liftoff. Rather frustrating, but not game breaking.

[CaptainKipard]

Can you replicate with a clean install with only those two mods?

I'm not getting this at all.

Edited April 14, 2014 by Cpt. Kipard

[MaverickSawyer]

No, it occurred after removing the plugin. False alarm.

[AntiMatter001]

"We're giving all that she's got Captain!"

i finally got it working... but it has two of everything in the VAB menu? WTF i'm an idiot for not getting this to work properly!

[Mokmo]

I have the latest version with Toadicus' plugin.

So far all my attempts into docking the 2.5m with the 1.25 stock ports have not worked. No magnets just bouncing off.

Then i hit escape to write this paragraph, and the magnets kick in... derp. I'll try to reproduce for ya.

[CaptainKipard]

"We're giving all that she's got Captain!"

i finally got it working... but it has two of everything in the VAB menu? WTF i'm an idiot for not getting this to work properly!

The only way there would be duplicates is if you have more than one part definition. So you must have an old cfg somewhere. The new update has done away with optional configs so if you delete everything in the UnivDockPorts folder and do a fresh install then everything should be fine.