Archer

Just retested all six attachment nodes on the four karmony nodes, they're working as expected.

Bug report: Installation: KSP 1.0.2.842 Fustek Station Parts DEV (Downloaded: 6MAY2015) Dependencies: CLS 1.1.3.0 DEV (found at https://github.com/PapaJoesSoup/ConnectedLivingSpace/releases/tag/1.1.3.0) MM 2.6.3 Ship Manifest 4.2.0.2 RasterPropMonitor 0.19.2 Issue: All four Karmony modules appear to have their side node orientations reversed, top and bottom nodes are unaffected. - Parts affected: Karmony compactNode Karmony compactNode Adapter Karmony Node Karmony Node Adapter - Parts Tested Karmony Node Cover Karmony Node Cover - Viewport Variant IACBM 1.25m Clamp-O-Tron Docking Port IACBM 2.5m* -Testing Attachment of the above parts was attempted on all six nodes of each Karmony module. -The Top and Bottom nodes accepted attachment of each part as expected. -None of the parts attached to the side nodes as expected. --The Clamp-O-Tron and 1.25m IACBM clipped into the module and attached to their "back" node. --The Node covers would not attach while oriented properly. --When attempting to attach the Node covers inside-out, they clip into the module and attach. -*The 2.5m IACBM was only tested on the Top and Bottom nodes of the flat variants, to satisfactory results. -The issue does not appear while "Non-strict part attachment orientation checks" in the KSP debugging menu is checked.

This should answer your question as to what nuFar is. Though I would HIGHLY suggest reading Ferram's full post (I stripped it down a bit). Where to get it? Ferram has a link to the source on GitHub in the first post. You'll be looking for voxelAero (for KSP 0.90) or voxelAeroPort (for KSP 1.0+).

I've thrown together a very basic (stock) tech tree integration config for use with module manager. I stuck the 0.5m ST in Precision Engineering, with the Oscar-B Tank; the 1m ST in Heavy Rocketry, one above the longest ~1m stock tank; the 2m, 3m, and 4m ST's in Very Heavy Rocketry, with the longest 2.5m stock tank (there are no stock nodes above this, or they would go there); and I stuck the Super ST in Meta Materials, as that seemed more fitting than with the others. And the entry costs I pretty much pulled out of... thin air.

This looks awesome, I'm going to try it out this after noon. Two questions though. I have FAR, DREC, MFS (RFRM) & ST; what else would you recommend? Which tech tree would you recommend?

I personally use your heat shield attached to Bahamuto's Module it works like a charm, but only looks passable. Otherwise the parts look awesome!

Any chance on built in folding solar panels?

A bigger IACBM makes sense. I get the feeling this is going to be the second part pack I won't be able to go without (you could probably guess the first). Also, I do use Deadly Re-entry, so when you release the heat shield I could probably set it up.

Helix, how far did you back off from the port you undocked from? usually you have to back off a few meters before KSP will be willing to dock again.

Or, since he plans on creating modified versions of both docking ports any way, he could add an addition attachment node to both ports for the shroud to attach to.

Quick question, are your IACBM's the same thickness as the stock clamp-o-trons? If not wouldn't that shift the attachment point of the shroud?

Since it is now possible, and relatively easy, to "weld" parts together, it is easier to create singular parts with multiple docking nodes (e.g. Rockomax hub with six clamp-o-trons as one physical part). However, issues arise in flight. The current docking port selection process of bringing up the Right Click Menu (RCM) of the port in question works quite well for one docking node per part; when the RCM has multiple docking targets without unique RCM identifiers it becomes cumbersome to target the correct docking node, and near impossible to undock the correct node as well! My suggestion, the ability to add/modify/remove unique RCM identifiers to specific docking nodes (e.g. "front", "back", "top", "alpha", "beta", "this one", etc) in much the same way vessels can be given unique identifiers, resulting in the GUI options stating things like "Set Node Front as Target", "Undock Node Beta", or "Control from <tag>". Having separate dedicated docking port parts allows greater construction flexibility, the ability to condense multiple docking nodes into a single part in a usable fashion allows for sturdier and less resource intensive construction.

The IACBMs look awesome, can hardly wait to start using them. I've started attempts at welding parts together to increase stability and reduce part count (using your modules and stock docking ports as a test). Unfortunately I think trying to create one part with multiple docking ports, while possible, creates too much of a pain in selecting specific docking ports for docking (lets not even go into making sure you have to correct docking port when undocking), being able to name individual docking ports (modules) seems like a good fix. I guess I'm off to see if I'm better at coding than modeling.

Personally, I like the sliding/iris idea, though that may change with the right concept art.

I too would enjoy the stepped design, though this looks excellent (as usuall).