benjee10

The difference is probably that Nert's part has a single deploy animation, whereas mine has four - one for each radiator panel, and one to start the sun tracking. KSP is capable of auto-generating a drag cube for a part with only one animation, but with multiple it automatically switches to the dynamic drag cube system (which is computationally expensive, and seems to be the source of these errors) rather than trying to pre-generate a drag cube at launch. By defining a specific set of drag cubes in the config, you can tell the game not to use the dynamic drag cube system. It's a little unclear to me exactly how this all actually works, but it seems like I can basically tell the game that 'if any of these animations are triggered, switch to drag cube X. If not, use drag cube Y.' So the trick now it to create a version of the part with only one deploy animation in order to generate appropriate colliders, and take that from the Part Database and put it in the config.

I like that lander a lot. I’m planning an Orion/SLS revamp down the line, so that may well make it in as a part of that.

Try locking every robotic part of the arm and then autostrutting the end effector to root. ALL the joints need to be locked, or the autostrut won’t be able to pass through them.

Ah, IR RO sounds like it was probably the cause, then. If it works any differently to RO Next the patch wouldn't work correctly. No need to delete the patch unless you want to revert to using the stock robotics system. I guess what you're wanting is something like the Canadarm foot restraint: Don't currently have anything like that in the mod, but I suppose you could surface attach a command seat onto the arm and have a kerbal ride it like that. I will be adding the Canadarm2 in a future update so I will likely add something like the foot restraint alongside it.

Hmm, seems like it might be a problem with the IR patch. Did you install IR after building the arm by any chance? If not, the patch itself may be broken - I'll have to take a look into it. Removing the 'Patches' folder from the 'htRobotics' folder should revert the joints to use the Breaking Ground robotics which hopefully should fix the problem. You might need to rebuild the arm to see the effects if that doesn't work. Also - just a heads up, you have the end effector upside down on the top of the arm - the end with the grey stripe is the grappling end!

That's strange. At a guess, it might be a product of the craft file being created with atmospheric autopilot installed (I think that might add custom modules to control surfaces). Will the craft load correctly if you install atmospheric autopilot? If not, do the elevons/control surfaces work correctly when you add them to a craft yourself? Looks like it could be the depth mask from Orbiter Docking System's IVA. There was an issue with that being on the wrong layer in earlier versions but I thought I fixed it. Could you confirm: What version of the mod you are using, What KSP version you are using, Does the docking system IVA appear in cutaway mode, or is it hidden? Does the issue persist with a clean reinstall of the mod (i.e. delete the mod from your GameData, and install fresh download)

It should work fine, just make sure all the dependencies are using the latest version available.

The solar arrays use the solar panel tracking module so that they automatically rotate to track the sun. Unfortunately that means that attached parts won’t rotate with them, just because of how KSP works.

That's incredibly strange but really good to know! Thanks for doing the testing. When I get chance, I'll generate an appropriate drag cube for the radiator and patch that in, and then do some testing just to verify the issue is fixed. KSP works in mysterious ways...

I suspect if this *is* being caused by a drag issue (which might not be the case) it will be to do with how the drag cube is generated, rather than the drag values of the part itself. I know changes were made to how drag cubes are handled recently, and dynamic drag cubes in particular caused a lot of problems (see the solar array loading issue). You could also try deleting PartDatabase.cfg from your Kerbal Space Program folder - this is where generated drag cubes are stored. Deleting it will force the game to re-generate all the drag cubes when you next start it. If HabTech has somehow messed with how the drag cubes are generated, the fix may not show up until the game is forced to re-generate them.

Interesting. I am having a hard time understanding how the drag cube of one part should be affecting the drag of completely unrelated parts. Drag cubes are generated either by the game on startup, during flight (dynamically), or can be defined in the .cfg - you don't need any special software to change them. Deployable parts tend to use dynamically generated drag cubes and I think this is the case for the triple radiator. Try pasting the drag cube fix from the solar array into the radiator .cfg - it will obviously be completely wrong for the radiator, but if the problem is due to the dynamically generated drag cube, it should reveal that. Unfortunately I don't have time today to test it myself.

This is intended - the entire truss of the solar array rotates, so if you were able to surface attach to it, it would be left behind and float in mid air as the arrays track the sun. Consider adding a temporary part to the end of the solar array which you can attach a grapple fixture, to and then remove once the array is in place.

Try autostrutting the booster, adapter, and fuel tanks to the root part. With proper autostrutting there shouldn't be any wobble at all. If that doesn't work there may be an issue somewhere.

Just attach the parachutes directly to capsule, underneath where the forward cover goes. Then you can stage the cover and the parachutes at the same time.

Are you using the craft file included with the mod? As this has RCS transforms disabled in certain axes to help balance the craft. Unfortunately these are relative to the axis of the control point, so changing control from the cockpit to the docking port results in some ports being disabled in an unusual way. There are a couple of workarounds - simplest is to fly the shuttle from the cockpit manually. You can click around the Iva to get a view out of the aft windows which are useful for lining up the docking port. Alternatively, you can enable all the actuation toggles for the RCS in the right click menus. Your RCS will be slightly imbalanced and less efficient but you’ll be able to fly fine from any control point.

That’s very strange, thanks for doing the testing. I’ll take a look at that part and try to figure out what’s going on.

This is very strange - I’m wondering if it is something to do with either Community Resource Pack or B9PartSwitch, because I can’t think of any way HabTech itself would be interfering with other parts. If you remove these two along with HabTech, does the issue persist?

OK - HabTech2 is officially un-broken (mostly)! I still have one more issue to fix, which is the solar arrays spontaneously combusting if they're not the root part - but for now I've applied a workaround which makes the solar arrays themselves physics-less, transferring their mass/drag to whatever part they are attached to (as the stock RCS & antennas do). This might result in the CoM being off slightly in your craft, but the upside is that everything is now stable. You can pick up the new release either through SpaceDock or GitHub.

Thanks for your help on this, it's definitely helped to pin down the issue. I've done some more testing today and it seems that the problem is localised in the central truss element of the solar arrays, i.e. it's a problem with the little animation that plays to signify dual axis tracking is starting. That's a major, major relief, as it's by far the least complex element of the part. Which means that I may well be able to get a fix done relatively quickly.

Today I've pushed an update to the GitHub - it's still a dev release, so please be patient while I iron out bugs. I've incorporated the drag cubes and physics significance fixes so that HabTech should now be playable. However, the 1km spawn bug is still present, and I can't guarantee that the physics significance trick (which seems to prevent immediate combustion of the vessel) won't cause any weirdness, so proceed with caution. Additionally, I've added a half-length MPLM variant, and also made it so both the half-length and full-length MPLMs can be used inline, with switchable endcaps. I intend to add more multi-purpose parts like this in the future to increase the diversity of designs you can build. Download

Make sure your Kerbonauts are feeling extra spooky this Halloween with this handy wearable pumpkin head! Our scientists assure us that pumpkin flesh is 100% airtight, even when carved, so you can enjoy the spooky spirits wherever you are in the Solar System! DOWNLOAD DEPENDENCIES Pumpkin Head requires Kerbal Inventory System + its dependencies to function. Please ensure you have the correct version of KIS for your KSP install. Alternatively, Pumpkin Head can make use of the wearable props plugin included with Benjee10's Historical Kerbal Suits if installed. KNOWN ISSUES Pumpkin may become detached from the head in certain scenarios and appear to hover in the air ominously. This is normal, and you are not in danger. FAQ Q: What functionality does this mod add? A: Absolutely none. Q: Is it literally just a pumpkin that you can put on your head? A: Not only that, but it also glows! Q: Why aren't you fixing your other mods/making Buran/doing something useful? A: I ask myself the same. Happy Halloween everyone!

This is correct - I have actually resolved the drag cube issue on my end and the part will load correctly, but the 1km spawning bug seems to have gotten worse in 1.10 to the point where any craft with the SAW part sometimes randomly explodes on loading onto the pad. Not sure how it affects crafts already in orbit. I'm reluctant to release a fix for the drag cube/loading issues when the part is still critically bugged in other areas - don't want to imply that things should be working as normal and then suffer 100s of bug reports for a known issue. So until I'm able to fix that problem I won't be publishing an update. That said, for those pioneering users who know their way around a config file and want to at least get the mod loading in-game, you can paste the following at the end of the 'ht2_solarArray_duo' .cfg: DRAG_CUBE { cube = RETRACTED, 17.7,0.9,2.621, 17.7,0.8988,2.621, 6.453,0.9394,3.002, 6.453,0.945,8.164, 13.73,0.9184,2.532, 13.72,0.9131,2.522, 0.004805,-1.622,-0.002383, 2.694,9.135,2.332 cube = EXTENDED_A, 18.99,0.8982,21.14, 18.99,0.8973,21.14, 106.4,0.9879,3.002, 106.4,0.9902,8.273, 16.17,0.8916,6.005, 16.24,0.9027,4.106, 9.256,-1.622,-0.4273, 21.2,9.135,6.344 cube = EXTENDED_B, 18.08,0.8954,21.14, 18.08,0.9003,21.14, 19.36,0.8859,5.035, 19.37,0.889,8.244, 102.4,0.9833,1.867, 102.9,0.9812,1.768, 9.256,-0.608,-0.002383, 21.2,11.16,2.332 } Note it's not a perfectly accurate drag cube (AFAIK there's no way of doing that for this part due to the number of deployable elements), but if you're in a situation where the aerodynamics of your solar arrays are important, you probably have bigger problems to deal with. Use at your own risk and, as always, back up your save files. If anyone is brave enough to try it out on a save which has a SAW part already in-orbit, I'd be curious to know what the effects are.

The Cupola IVA is only available via the GitHub download as it's still in development.

You shouldn't place the entire folder in GameData - if you look inside the Shuttle_Orbiter_Construction_Kit folder, there should be a GameData folder which a bunch of subfolders inside. You want to take the contents of that GameData folder, and then move it into your KSP install's GameData folder. Should look something like this:

see the post three above yours