[Solved] Self-aligning docking ports and convex colliders

[sumghai]

Solved - see this post for details

 

 

As part of my FusTek Station Parts Expansion, I am developing a new series of docking ports loosely-inspired by the real-life Common Berth Mechanisms (CBMs) and APAS docking ports used on the real ISS.

I managed to get simple stock-like androgynous docking in my earlier prototypes, so I decided to see if I could take a step further and restrict the valid roll alignment offsets between any two of my docking ports to 0°, 90°, 180° and 270°, by using animated colliders, for certain aesthetics reasons (I am aware of and often use sarbian's MechJeb fork with automatic docking roll alignment, but I wanted a built-in collider system for those who prefer manual docking).

My model hierarchy is as follows:

• PartTools_IACBM_1.25m - Empty GameObject for KSP PartTools export
  • IACBM_1.25 - Blender model asset file
    • align_1A ~ align_4B - Docking alignment colliders; animated to switch between Active/Passive modes, intended to "force" relative alignment of docking ports in increments of 90°.
    • collider_docking_toggleable - Intended to help with manual docking; as part of a special design feature exclusive to my Karmony modules, this can be toggled off to allow Kerbals to EVA out of hatches that are otherwise (deliberately) covered by these docking ports
    • docking_guide_fins - Cosmetic mesh with no colliders to emulate APAS-style guidance fins; animated to switch between Active/Passive modes
    • dockingNode - empty GameObject used to determine where the docking port will be controlled from; sits flush with upper surface of main_ring
    • main_ring - Chassis of the docking ring itself; no colliders as to hot interfere with align_1A ~ align_4Band collider_docking_toggleable

As can be seen in the latter screenshots (with the alignment colliders rendered for clarity), the docking ports do dock, but the splines fail to enforce relative roll alignment between them. Repeated testing reveals that as soon as the magnetic force between modules engages, the modules snap towards each other while seemingly ignoring the presence of the alignment splines.

I've linked a copy of my WIP part and CFG, as well as my Firespitter fork animation DLL, for curious folks to examine. Upon request I can also provide my Blender files and Unity configs.

https://www.dropbox.com/s/r5yhaehunk16ydn/sumghai_IACBM_1.25m_wip_15_aug_2013.zip

Any suggestions on how I could make these alignment splines work reliably?

[Nazari1382]

Isn't collision turned off for parts on the same vessel? Or are the guides not working before the dock is complete?

[sumghai]

Isn't collision turned off for parts on the same vessel? Or are the guides not working before the dock is complete?

It seems that the guides do not work properly before docking is complete, even though they have all been set to convex.

[Nazari1382]

the guides may need to be a different part. you could attach your docking node part to a node at the "bottom" of your guide part, so that it still sits against the craft.

[sumghai]

the guides may need to be a different part. you could attach your docking node part to a node at the "bottom" of your guide part, so that it still sits against the craft.

Ideally, I would like to keep the number of parts as low as possible, and since every one of my prototype CBMs will need to be used with these alignment spines, that's basically two parts per docking port.

That being said, I might experiment with using separate MODEL config nodes for the docking port itself and the alignment fins/spines, so that hopefully the colliders would work without being negated by the Docking PartModule. I'll report back with my results soon.

[sumghai]

I've just tried splitting the docking ring into a base part and a guidance fin part, and referenced them in the CFG using MODEL config nodes - the Docking PartModule ignores the alignment splines.

I'm aware of Brotoro's hack using stock panels, but as I've previously stated keeping part count to a minimum is one of my primary goals. So I guess I'll have to leave the guidance fins / alignment splines as purely cosmetic elements with no colliders, and instead recommend people use sarbian's MechJeb 2 fork for docking alignment.

[Legal2k]

Try putting two or three docking port on the end, they should then snap to perfect alignment.

[Greys]

I've been working on a cylindrical* docking system for my hexcans, and what I've found is that colliders just don't work very well and when you get docking ports involved a lot gets thrown out the window. I've tried mechanical alignment and it just does not work. I've tried using ancillary docking nodes, even ones that cannot be resolved and have high force/torque, to pull the object into the correct alignment, and with any pattern of triangulation I could figure out it just made things less likely to work at all. The problem with Ancillary Nodes is that when any docking node gets into a position and velocity where it is permitted to resolve, "**** everybody else, I'm docking", even if the part is in collision, and at that moment all the ancillary nodes stop caring.

Basically, with the system as it is currently you're only going to get it to work poorly. Now, you might be able to assist this by using animations to gimp the docking port, give it a toggle which moves the docking node transform into a position where it cannot resolve, allowing the player to flip it back when the ship is fairly well aligned, moving the transform towards a resolvable state. Better choice is using some kind of post-docking correction factor, for HexCans I'm considering making a mod that immediately on docking, hopefully same frame as it, simply overwrites the hexcan's position and orientation to be a perfect match; yes this will cause a weird looking jump but the largest hexcan is 3 meters long and most of a meter wide, I don't think for such small things it would be too immersion breaking. For docking ships that's not really a choice but you could use a method like Magic Smoke's docking washers to slowly rotate the ship back into alignment and set up the docking ports to get it close enough so it doesn't have to correct much. Alternately, let's petition Squad to add Axis Locks to the moduleDockingPort.

http://i.imgur.com/TC5UPKy.png

http://i.imgur.com/IkcnjnE.png

Docking ports have a very limited band of proper operation,

going outside that band causes krakens.

[Cheebsta]

Couldn't a plugin detect ports a bit farther away and apply rotational force as needed to the incoming port/vessel?

[Alskari]

You can put multiple docking nodes in the same part. See one of my docking ports for an example.

[Greys]

potentially, but it'll be a lot of work. You cannot apply rotational force to a craft, you have to apply linear force in multiple opposing, symmetric places. You also have to calculate how much force to apply to those places you've calculated and when, basically you would be replacing ASAS and RCS with magic.

Once the ships are docked it should be possible to simply rebuild the ship with different rotation values on a joint. That's what DR does, every frame it rebuilds the entire ship and modifies some transform rotations while it's at it.

[sumghai]

My apologies for the less-than-timely response, been experimenting with everyone's suggestions.

Try putting two or three docking port on the end, they should then snap to perfect alignment.

I think you're completely missing the point of this exercise.

This isn't about using multiple stock docking ports and bi/tri couplers, but to design a single docking port that has this alignment function built-in.

I've been working on a cylindrical* docking system for my hexcans, and what I've found is that colliders just don't work very well and when you get docking ports involved a lot gets thrown out the window. I've tried mechanical alignment and it just does not work.

Good to hear that it's not an design issue on our part.

I've tried using ancillary docking nodes, even ones that cannot be resolved and have high force/torque, to pull the object into the correct alignment, and with any pattern of triangulation I could figure out it just made things less likely to work at all. The problem with Ancillary Nodes is that when any docking node gets into a position and velocity where it is permitted to resolve, "**** everybody else, I'm docking", even if the part is in collision, and at that moment all the ancillary nodes stop caring.

You can put multiple docking nodes in the same part. See one of my docking ports for an example.

I went ahead and tried the HSH parts, and three things immediately put me off further experimentation:

- The right-click context menu results in multiple "Control From Here" and "Set As Target" entries. While I presumed that the first from both lists would correspond to the same locations on both ports, for less-savvy users this non-intuitiveness leads to a guessing game of matching combinations.

- In a docking test involving two identical vessels, one attempted to dock with its engines facing the other's docking port.

- Grey's analysis above.

Now, you might be able to assist this by using animations to gimp the docking port, give it a toggle which moves the docking node transform into a position where it cannot resolve, allowing the player to flip it back when the ship is fairly well aligned, moving the transform towards a resolvable state. Better choice is using some kind of post-docking correction factor, for HexCans I'm considering making a mod that immediately on docking, hopefully same frame as it, simply overwrites the hexcan's position and orientation to be a perfect match; yes this will cause a weird looking jump but the largest hexcan is 3 meters long and most of a meter wide, I don't think for such small things it would be too immersion breaking.

While I'm familiar with animating GameObjects in Unity (including resizing/moving colliders), this might be a bit much for me.

For docking ships that's not really a choice but you could use a method like Magic Smoke's docking washers to slowly rotate the ship back into alignment and set up the docking ports to get it close enough so it doesn't have to correct much.

I would prefer not to use the docking washers - that's basically one additional part per docking port.

Alternately, let's petition Squad to add Axis Locks to the moduleDockingPort.

Excellent idea. I'll start a topic in the suggestions area.

Couldn't a plugin detect ports a bit farther away and apply rotational force as needed to the incoming port/vessel?

potentially, but it'll be a lot of work. You cannot apply rotational force to a craft, you have to apply linear force in multiple opposing, symmetric places. You also have to calculate how much force to apply to those places you've calculated and when, basically you would be replacing ASAS and RCS with magic.

I have a feeling that would effectively mean reinventing the KillRot function in sarbian's MechJeb 2 fork, something I don't particular wish to do given that my experience with plugins have been limited to repackaging the Firespitter DLL with Snjo's help.

[Greys]

If you're up to it, I see no reason you couldn't integrate the docking washer functionality directly into your docking ports

[sumghai]

If you're up to it, I see no reason you couldn't integrate the docking washer functionality directly into your docking ports

I don't like the idea of docking and then rotating entire assemblies into alignment after the fact.

I use InfernalRobotics for many other things, but its angular increments are imprecise at best.

[gl0ryh0und]

I've notice in my work that while multiple colliders for one object works however, the engine seems to work poorly with them all at once. Point in case with my larger structure parts I've noticed that not all colliders may actually 'collide' simultaneously .. the result one collider affects the objects range of motion while the others are ignored. I've seen object behave weirdly because of this. I actually practiced crashing my ships into things to see how it would affect the mesh. Perhaps build the collider as all one object with convex off and over size it just a bit?

[Greys]

if your colliders on a part are not convex they'll be ignored completely, it's not a best practices thing. But perhaps a large circular wedge collider would work, it'd only allow two orientations and you would have to have two parts, no two wedge docking ports would be able to dock with eachother.

[gl0ryh0und]

None of my colliders are convex on some of my objects and seems to work with the exception I that mentioned earlier.. only one seems to get detected in a collision at a time, but I haven't noticed them getting totally ignored. The side effects in the VAB is that the editor allows the object to be clipped into other colliders while being attached to another one, which is good for my parts they are supposed to look like a metal framework holding everything up and the clipping adds to that impression.

[Adie123]

Ive had working docking alignment guide parts since feb/march for my station modules. It was one of my first projects. i havent published them for the community as of yet, but may do in the near future. I'll collate images and/or vids to show what ive done and return here to let you know how to possibly get around your issue, sumghai.

I believe i know where your going wrong, but i want to document my things first .. I believe a streaming friend of mine may have recordings somehwere. I'll need to gather them like i said before i divulge tricks of unity part moddling

[Adie123]

Here sumghai, check these parts out and let me know if the function of these is similar to what your trying to figure out.

[WIP] Escepadie Systems: Unique Docking System Parts mod

[sumghai]

Adie123, I read your responses in your project thread, but we've already discussed (and ruled out) multiple docking nodes due to the guessing game multiple "Control From Here" and "Set As Target" involves.

[Adie123]

Adie123, I read your responses in your project thread, but we've already discussed (and ruled out) multiple docking nodes due to the guessing game multiple "Control From Here" and "Set As Target" involves.

I have not said anything that aims at me or anyone else to be using multiple docking nodes. My parts use one dockingnode and no more than one, and my parts align perfectly every single time. I thought this was your aim, to be able to align craft when docking :s

Edited August 21, 2013 by Adie123

[sumghai]

I have not said anything that aims at me or anyone else to be using multiple docking nodes. My parts use one dockingnode and no more than one, and my parts align perfectly every single time. I thought this was your aim, to be able to align craft when docking :s

Then how do you explain the following?:

No. Unfortunatly the more dockingNodes attached to a part you end up seeing multiple toggle/undock/etc options when you right click the part, and have no idea which one is which. The connection is strong and in the center of both spacer types.

EDIT: I've had a look at your thread in further detail, but since there are no parts to download, gameplay videos are insufficient for me to determine whether what you have implemented is precisely what I'm looking for.

Edited August 21, 2013 by sumghai

[Adie123]

sumghai, your from australia. I assume english is your first language or at least your proficient with it. Your misreading things.

That snippet of text you pasted of me talking about multiple dockingNode, says totally opposit of what your accusing me of saying. Someone asked if i had multiple node locking and i said no and said why its a bad idea. So this needed not to be brought up in this threads discussion between me and you. Seeing as we both understand multi-dockingnodes dont work or at least are very messy.

I use multiple objects with multiple convex meshes on parts to align the crafts. The vids show exactly their function and its pretty straight forward. Spikes go into holes and forces alignment every time.

Having tiny little stumps of convex meshes like your OP to rotate and lock isnt going to be possible (unless using code) if the dockingnodes attach first. As soon as they attach, thats it, both craft become one and are locked. This is why my design has long spikes, to have a chance to align the two craft before the nodes snap together. I tried smaller extruded ledges first and they drove me to the conclusion of that.

Edited August 22, 2013 by Adie123

[Greys]

Given the sentence leading up to it, this had to be done.

sumghai, your from australia. I assume english is your first language or at least your proficient with it. You're misreading things.

Long pins may have a greater accuracy than small ones, but they will suffer from exactly the same problems with inaccurate collision mechanics; but also long pins are just usually not going to be an adequately functional solution, most docking pairs are less than half a meter deep. It won't work for what Sumghai is making, and it won't work for what I'm making because we don't have space for long pins.

[Zeblote]

Given the sentence leading up to it, this had to be done.

That's not the only grammar fail in that sentence...