FusTek Station Parts Dev Thread (continuation of fusty's original work)

[XanderTek]

Sumghai, do your plans for the IVAs include that new RasterPropMonitor?

[Nibb31]

I've been using the new engineering models successfully this last couple of days. The only issue I'm having is extreme wobble from the IACBMs, especially when I turn MechJeb on. Is anyone else experiencing this? I've had to resort to using the stock docking ports which don't wobble nearly as much, which is strange because it used to be the other way round.

[15nelsoc]

I've been using the new engineering models successfully this last couple of days. The only issue I'm having is extreme wobble from the IACBMs, especially when I turn MechJeb on. Is anyone else experiencing this? I've had to resort to using the stock docking ports which don't wobble nearly as much, which is strange because it used to be the other way round.

I have noticed this as well, my stations shake themselves apart now.

[MOARdV]

I have noticed this as well, my stations shake themselves apart now.

I've seen that with the current release 1,25m IACBM, not just the engineering release version. I think it started happening with 0.22, but I am not completely certain. I suspect it has to do with the mass of the part (?), since I also have heavier docking ports that I made compatible with IACBM, and they don't show the wobble.

[XanderTek]

Yeah, there does seem to be something a bit odd with the docking ports. Here's a test I did:

The central module is supported by tusses going to the ground. The side modules are hanging off of that. On the left I'm using stock Clamp-o-Trons, on the right I'm using 1.25m IACBMs. The stock dock is holding together just fine, while the fustek one is bending strangely (it's still attached, but it's not strong enough to hold up the module). I took a look at the cfg files, and nothing jumps out at me to explain that difference.

Edited November 17, 2013 by XanderTek

[Nibb31]

I can't run KSP on my week-end rig, but maybe you could try editing the cfgs and increasing the mass of the IACBMs to 0.5 instead of 0.05 and see if it solves the problems.

I think MOARdv might be onto something and that the mass of the part influences how the physics engine handles its rigidity.

[XanderTek]

I can't run KSP on my week-end rig, but maybe you could try editing the cfgs and increasing the mass of the IACBMs to 0.5 instead of 0.05 and see if it solves the problems.

I think MOARdv might be onto something and that the mass of the part influences how the physics engine handles its rigidity.

That was one of the things I checked in the config files. The Clamp-o=Tron weights 0.05, same as the FusTek one. I am using Kerbal Joint Reinforcement, but I think that would apply to both types of docks equally.

[sharpspoonful]

I'm noticing significantly weak 1.25m docking clamps, and my stations seem to want to spin uncontrollably, even after time warping to negate any rotational velocity. This is something I've only noticed with the dev build.

[MOARdV]

That was one of the things I checked in the config files. The Clamp-o=Tron weights 0.05, same as the FusTek one. I am using Kerbal Joint Reinforcement, but I think that would apply to both types of docks equally.

Hmm. That wasn't it, then. Something to do with colliders? The IACBM has that capability of letting kerbals crawl through. The SDHI parachute / docking port doesn't do that - maybe see how that compares?

[XanderTek]

Hmm. That wasn't it, then. Something to do with colliders? The IACBM has that capability of letting kerbals crawl through. The SDHI parachute / docking port doesn't do that - maybe see how that compares?

Ok, just tried this. The SDHI IACBM performs somewhere in between. More bending than the stock 1.25m dock, less than the one included in X0.04-1 of this mod. But the SDHI one wasn't updated to this latest ENG pack, so it's not necessarily due to the crawl-through capability.

I also tested a part that contained the exact cfg of the stock dock except for pointing to the IACBM model. This performed as well as the stock clamp-o-tron. So I suspect the cause is some obscure difference between the cfgs of the parts. I'll investigate more when I have a chance...

EDIT: Ok, I think I've found the problem. Having ModuleAnimateGeneric or ModuleLight in the docking port's .cfg file seems to weaken it considerably. I have no idea why... Perhaps those of you with station wobble problems would like to try commenting those modules out?

EDIT2: FusTek_SG_animateGeneric normally doesn't weaken the connection, but if you activate the active/passive toggle, the dock is weakened until the animation completes.

Edited November 17, 2013 by XanderTek

[BFGfreak]

Edit: It looks like you found the problem before I could post

Could it be the fact that he's using a custom node type and the game isn't applying proper sticking force on the part because of it?

From the stock part

	nodeType = size1

From the IACBM

	nodeType = IACBM_125

[onkelsiebdruck]

My Dockingport has also its own node-name. And like the IACBM a hole and an animated Collisioncollider,

also my collider is very small compared to the stock one. -> I think the stock one intersects with connected parts...but i don´t think thats necessary, cause mine does not.

I used nonconvex-colliders and box-colliders, maybe that helps.

ps:you can´t see the motion-part in this screenshot it´s only a small plate, thats prevents kerbals to pass if the door is closed, all other meshes are fix.

Does the IACBM using something similar or maybe something with the complete collider?

Edited November 17, 2013 by onkelsiebdruck

[czokletmuss]

This was probably already asked but are you planning doing support for ECLSS life support mod? It would be perfect with these parts

[sumghai]

This was probably already asked but are you planning doing support for ECLSS life support mod? It would be perfect with these parts

Since there are a myriad of Life Support mods out there (Ioncross, TAC, ECLSS), I'd probably wait until the next stable release for this - even then, they would all have to be ModuleManager configs.

---

Minor hotfix to X0.04-1 DEV BUILD released - refer to the blog post for download link

Tweaked IACBM colliders back to what they originally were in R0.03.5a - I suspect I borked them as part of my experimentation / migration to PartTools 0.20.

[XanderTek]

Tweaked IACBM colliders back to what they originally were in R0.03.5a - I suspect I borked them as part of my experimentation / migration to PartTools 0.20.

Will this affect existing ships? If so, is there much risk of it causing them to spontaneously disassemble?

[sumghai]

Will this affect existing ships? If so, is there much risk of it causing them to spontaneously disassemble?

No, this hotfix shouldn't break crafts.

[johnsonwax]

Ok, just getting around to building some stuff with the dev build. One question: I understand .4 is not save compatible, but is it designed to be otherwise equivalent to past parts?

An an example, the old node end ring had a node that would sit it flush with a flat Karmony module, and a second node near the surface of the ring, so that an IACBM wouldn't sit flush to the Karmony, but would instead sit on top of the ring. This was handy for me to build up a way to attach 2.5 meter parts to the side nodes of the Karmony hub. This made sense before the IACBMs with Fusty's old berthing modules.

The new node end ring has two nodes that sit flush with the Karmony modules. One to attach it to the Karmony, and one to receive the IACBM properly inset into the ring. This is much more sensible with the IACBMs, but means that some kinds of constructions are now either not possible with the new parts, or are possible but look, well, quite silly.

Are you worried about this sort of thing? I don't think you should be, but you have set this up in order to migrate parts forward, and I don't think it's going to work in a lot of these cases. I also noticed you kept the odd CoM for the Karmony Node, which leaves me to think that you are trying to minimize breakage.

(For those that don't know, the Karmony modules' part origin isn't in the center along the long axis, it's 1m offset, so the CoM needs a 1m adjustment to balance. It's the kind of thing you notice when you are welding parts and have to do this. In a save breaking update, it would make sense to correct this and shift the origin and eliminate the CoM offset. Just makes all of the math easier.)

[sumghai]

An an example, the old node end ring had a node that would sit it flush with a flat Karmony module, and a second node near the surface of the ring, so that an IACBM wouldn't sit flush to the Karmony, but would instead sit on top of the ring. This was handy for me to build up a way to attach 2.5 meter parts to the side nodes of the Karmony hub. This made sense before the IACBMs with Fusty's old berthing modules.

The new node end ring has two nodes that sit flush with the Karmony modules. One to attach it to the Karmony, and one to receive the IACBM properly inset into the ring. This is much more sensible with the IACBMs, but means that some kinds of constructions are now either not possible with the new parts, or are possible but look, well, quite silly.

This is one of the sacrifices I had to make when making MODEL{} node calls to reuse the Karmony Mission Module mesh (from which nearly all crewed compartments are derived from)

I also noticed you kept the odd CoM for the Karmony Node, which leaves me to think that you are trying to minimize breakage.

(For those that don't know, the Karmony modules' part origin isn't in the center along the long axis, it's 1m offset, so the CoM needs a 1m adjustment to balance. It's the kind of thing you notice when you are welding parts and have to do this. In a save breaking update, it would make sense to correct this and shift the origin and eliminate the CoM offset. Just makes all of the math easier.)

Hatch obstruction detection doesn't work correctly if the airlock collider is >1m away from the part CoM - it's an old KSP bug I discovered from R0.02a. After consulting with Ted about a month ago, I've filed a bug report.

In the meantime, the shifted origin / CoM offset is the only workaround for modules of this size.

[molo]

I'm noticing significantly weak 1.25m docking clamps, and my stations seem to want to spin uncontrollably, even after time warping to negate any rotational velocity. This is something I've only noticed with the dev build.

I've been seeing this as well. I'm not sure what is up - I also see it with the SDHI service module (but not the service module ring). It's pretty bizarre. I thought it might be an issue with the rigidity plugin, but that doesn't change it.

[sumghai]

I've been seeing this as well. I'm not sure what is up - I also see it with the SDHI service module (but not the service module ring). It's pretty bizarre. I thought it might be an issue with the rigidity plugin, but that doesn't change it.

Did you try the hotfix?

[Starwaster]

Edited the development build files.

Commented out the texture lines (not sure that was necessary but assumed it was)

Added the following:

	MODULE
	{
		name = FlagDecal
		textureQuadName = module_id_symbol
	}

Not really scaled properly because it stretches to the edges of the quad but it's for demonstration purposes anyway.

Edited November 20, 2013 by Starwaster
thumbnailed / linkified

[Nibb31]

Even with the hotfix, I'm experiencing wobble on the IACBMs. There is definitely a mass problem, because when I increased them to 0.350 instead of 0.05, they worked fine.

[sumghai]

Even with the hotfix, I'm experiencing wobble on the IACBMs. There is definitely a mass problem, because when I increased them to 0.350 instead of 0.05, they worked fine.

Interesting - so all I have to do is to make the IACBMs heavier, and then the wobbles will stop?

If so, that should be very easy.

[sumghai]

Minor hotfix to X0.04-1 DEV BUILD released - refer to the blog post for download link

Increased IACBM part masses to 0.35 (1.25m) and 0.7 (2.5m), as per Nibb31's suggestion. Hopefully this should put the wobbling docking port issues to rest.

[XanderTek]

I really don't think mass is the problem. Perhaps adding more helps, but the stock Clamp-o-Tron weights 0.05 and doesn't experience this wobble.