kendfrey

I built a ship using the Breaking Ground robotic parts for control, instead of the standard thrust vectoring and control surfaces. I set up the Pitch/Yaw axis groups to set the play position on a couple of robotic controllers. I'm able to control it using my keyboard (WASD) but turning on SAS does not seem to use the robotic controls, so it's still unstable. Does SAS ignore the axis groups, or am I doing something wrong? How do I stabilize a craft with robotic controls? (MechJeb isn't able to stabilize it either.)

I assumed you weren't crazy enough to actually replace them by hand, but good idea, thanks!

Can you explain how you fixed it? I can't access those parts through the category view, but I prefer to use that view.

FYI, I was experiencing a crash during loading with this mod in KSP 1.3. It wasn't the surface sampler, it was the active struts. Deleting the contents of GameData\MagicSmokeIndustries\IRActiveStruts\Plugins fixed the crash. I haven't done much additional testing to see if anything else broke. HTH anyone who is experiencing the same thing.

Links are dead. Can you reupload? archive.org only has the drop shadow version: http://web.archive.org/web/20140205085903/http://everylittlepixel.com/wp-content/uploads/2013/05/KSP-LogoFullRed1.png Also, do you have an SVG (or other vectorized) version?

There are plenty of situations in which you only want to dock to the IR end. For example, a docking washer, or a temporarily berthed spacecraft. A real-life example is the Hubble Space Telescope. It was never docked to the main docking port of the shuttle.

Mmm, magnets. I actually played with those first (can you spot one in the screenshot?) but they're too power-hungry to be useful for me. It's the never-ending tradeoff between practicality and realism. Magnets are impractical due to power consumption. Docking ports are impractical due to the part tree. The non-magnetic grabber thingie isn't realistic due to being able to grab onto any part, even smooth fuel tanks.

This is a gross and misleading oversimplification of the problem. As I understand it, there's nothing wrong with using docking ports on the end of an arm. The trouble only comes when a ship interacts with itself.

I considered this, but it wouldn't help for maneuvering uncontrolled space station modules around, which is the whole idea of this robot arm. I'm starting to think building a self-controlled robotic arm is the way to go, rather than having it be controlled by (and docked to) the parent ship. More thought required though...

The difference there is that the tug and the deorbiter are not already connected. If they were, the part tree would form a loop when you attach the second klaw to the junk. In a space station, it's important that everything is connected to everything else at every moment in time, otherwise you have two smaller stations, which will become permanent if you don't react quickly.

Well now I understand why that warning is there. I had assumed it was some sort of kraken or bug, not a limitation of KSP itself. Too bad the IR/KAS parts aren't sufficient for a manipulator arm of the sort I'm looking for. They don't actually merge the vessels, so I won't be able to transfer crew/resources if using them for docking, and I won't be able to control the arm if it is attached by them. I tested this, and they yield the same results as docking ports. They detach when the part tree is broken. I take it the answer is "No, you simply can't do that." I guess I'll have to bring my arm back home and redesign it with these constraints in mind. Ah, science!

I'm having trouble visualizing this. I don't understand how adding another piece will let me rearrange the pieces of my station. Can you provide a picture or sketch of some kind, illustrating what you mean?

I have this arm docked to the space station, and I'd like to undock it from the shuttle it was launched in, but unfortunately, the way KSP's part tree works means that when I disconnect the arm from the shuttle, it disconnects the other end from the station as well. Is there a mod (or maybe even something in stock) that will let me do this? The logical part tree goes station <-> shuttle <-> arm, so KSP can't disconnect the shuttle while leaving the other two connected.

What I'd like to see in the name of gameplay and balanced mechanics is this set of parts: Passive heat sinks with high conductivity and high heat capacity. They would probably be medium-heavy. Active (liquid refrigerant?) cooling parts that transfer heat in a specific direction. They would be quite heavy, and use electric charge to run. Radiators with low-ish conductivity but high surface area for radiation. They wouldn't need to be heavy, but to use them for heavy-duty cooling, you'd need to combine them with the heavier parts to get more heat into the radiators.

This looks like a bug in the math of KSP. One possible workaround (use at your own risk, I haven't tried it) is to open your save file in a text editor and find the ISRU part that's overheating. Each ISRU "MODULE" section should have a setting called "heat throttle" (I forget the exact label). Change this value to 1 on all the modules. You may also need to change the "average heat throttle" value to 1.

I've done some more investigation with the debug menu and by viewing the save file. Overheating in an ISRU is linked to the part's heat, but not in a way you would expect. This is the behaviour as it appears to me: When the temperature goes above 500K, the ISRU is throttled down until the temperature goes below 500K. When the temperature goes below 475K, the ISRU is throttled up until the temperature goes above 475K. How fast the throttle moves depends on how low the throttle is, i.e. it moves exponentially. If it's running at 1% efficiency, it will take about 50x as long to reach 2% as it would from 50% to 51%. The "overheat" display is nothing but 100% minus the real throttle value. So really 100% overheat means the throttle is at 0. During timewarp, the temperature can overshoot by a long way before the converter can throttle down. If you're timewarping, the temperature could hit 510K before the throttle kicks in, in which case it will take some time to cool down to below 500K, and the converter will be throttling down exponentially the entire time, even though the converter is cooling. "Nerv" engines tend to produce temperatures significantly above 500K, so firing them can heat any nearby ISRU units to the point where they begin throttling down, thinking they're overworked, even though they're not processing any ore. Due to the nature of the exponential throttling, the longer it spends unnecessarily throttling down, the slower it will throttle back up. Due to the nature of the floating-point math used, there is a certain point where the throttle becomes so low that rounding errors take over, and it becomes stuck at a very very small value, and it can't throttle back up. If you're not a geek and don't care about all that, basically all you need to know is to avoid overheating these units for extended periods of time. Using "Nerv" engines to do long burns is a good way to make sure you won't be able to process any ore when you arrive at your destination.

The overheating behaviour on ISRU converters is pretty erratic. This is what it looks like to me so far: At 1000x time warp, overheating goes quickly to 0. This is the only way I found to efficiently process Ore. Once 100% overheat and "zero efficiency" is reached, there is no going back. No amount of timewarping or spacecraft cooling will cool the converter. Not even an Engineer can fix it, as far as I can tell. At 100x time warp and below, the behaviour is unpredictable. Overheating seems to tend toward 100%. It will quickly rise, but stop in a random spot. It will sometimes change, but that also appears to be random. Overheat is not the same thing as the normal temperature of a part. Can someone confirm this, especially the first two? They seem like bugs to me.

It appears to be the exhaust hitting the rover. I pointed the engines outward, and the rotation was mostly eliminated. My messages don't seem to be going through very fast. I think it's been almost half an hour since I posted the first reply and it still hasn't appeared. Sorry about that.

Ohh, that makes sense, Blue. I didn't have any luck with my little green men climbing across vertical ladders so far, but I'll try again.

I see no way possible that those ladders could be the cause. They don't change the centre of mass much, and the ship flips over in a different direction. It spins as though the left engine (on the picture) is stronger. Exactly along the pitch axis. It's a powerful spinning, too, not something that would be caused by a slight misalignment of the centre of mass.

I'm having trouble with one of my ships. I've balanced the mass and thrust to the best of my ability. Yet it is still torquing when I throttle up. The sepratrons are only to get it off the ground. I originally ran into this issue halfway to space. Only the two main engines were there. The SAS and command pod's reaction wheels could keep it relatively controlled until about 1/3 to 1/2 throttle. Above that, it spun uncontrollably. Shutting the engines off removed the torque and I could stop the spinning again. Does anyone know why it would be acting this way? Craft file: http://www.filedropper.com/munlandertest