Fraktal

Another cargo-related problem, this one's a definite bug. If tooltips are enabled, they also show up when mousing over inventory parts in the PAW during flight. If the part you mouse over on the PAW is Breaking Ground deployable science equipment and you click the deploy icon, the PAW closes but the tooltip does not. Instead, the tooltip keeps indefinitely following the mouse around until you open another PAW and mouse over, then out of, any inventory item, at which point it disappears as normal. Are you calling the tooltip hiding command from a mouse-out event handler? Because it sounds as if the event doesn't fire if the PAW gets closed this way.

Just had a very good haul on Minmus. First trip there on my current game, landed and scienced 5 biomes in one mission, then got back to Kerbin with only 12 m/s of fuel left. Would've had a greater margin of error if I hadn't gone for the polar biome right off the bat from an equatorial orbit, but at least it's out of the way now.

That one is caused by the symmetry parts technically being new parts, I think. I've seen a similar issue in Ship Sections: place a part without symmetry, give it a section name, move it elsewhere with symmetry. The counterparts will not inherit the original's section name, but instead get assigned to a default one. Grab the original again and put it back down, counterparts now properly inherit the original's section name.

According to the wiki, all parts have G-limits, but 99% of the time it's set to 50g. Only wheels and decouplers have a different value, so I think it was copy-pasted ridiculously high as an anti-kraken measure.

If you're using KER, it's roughly the mass with which you'll get 3400 m/s of dV if your sea-level launch TWR is at least 1.4. Any lower dV and you won't reach orbit. Any lower TWR and you'll lose too much dV to pushing against gravity. For an upper stage, you can get away with less TWR but too low and you won't be able to circularize in time. That's really the best I can say.

Look at it this way. At least the game is future-proofed in terms of hardware utilization.

It was just a launcher update, not a game update.

Command pods have built-in antennas, but those cannot transmit science data even if in range (they're also weak, so a relay will only connect from close range to begin with).

About to attempt my first return from Duna to Kerbin. Never done it before, so now I'll get to find out how risky interplanetary aerobraking at Kerbin without a heatshield really is. Also turned out that Astrogator's auto-generated maneuver node for the return was a load of BS that missed Kerbin by 3.5 million kilometers, so I tossed it out and made my own that not only costs less dV but actually intersects Kerbin's SOI.

Eh. I had single-digit meter differences in Mun and Minmus relays and they still drifted off after a year. I use probe cores almost exclusively as onboard avionics for manned craft, so I only need the comm uplink back to Kerbin for maneuver nodes.

I use only a few equatorial sats. 'Few' as in, I used to go for three per body but got tired of orbital drift inevitably throwing their spacing off. So now I just use one sat in a medium-height orbit and learn to live with having a limited transmission window.

Try a <0 km periapse reentry from the Mun. If that doesn't work, try it from Minmus.

Rimworld, it's a no-brainer. Hell, you already have to build a spaceship from scratch to win the game and there's a mod that lets you continue playing on the ship itself in orbit.

It might not necessarily be repairable, though. Remember that Sojourner looked intact too aside from the engine nozzles being crooked from groundstrike, yet we're told it's unrepairable with what they have on hand.

I swear someone on the production team is into KSP... Situation: Mars lander needs to get up from the surface to its orbiter to medivac an astronaut, but it doesn't have enough fuel to even get into orbit, let alone dock. They also don't have time to wait for ISRU to make enough fuel because the astronaut's condition can't wait that long. Solution: Mars lander takes off from the surface with the astronaut strapped to the top of the ship. Lander boosts up to a suborbital trajectory within sight range of the orbiter. Near the peak of its trajectory, the lander cuts engines with 7% fuel remaining. Lander tips forward and at the same time, the astronaut unstraps herself and gets flung off towards the orbiter by momentum. Astronaut uses her MMU pack to rendezvous with the orbiter. Lander falls back into the atmosphere on a very steep descent trajectory and lithobrakes with a suicide burn. Last shot is the pilot walking away from the busted and smoking lander like a boss. And least we forget, the gigantic twist reveal last episode that

OK, updating CKAN did the trick. Auto-update was turned off because it has been throwing a 404 error for a long time now. Addon installed fine this time. Sorry for the inconvenience.

I took a screenshot of CKAN just now. As you can see, no Harmony of either version and Harmony2 is not indexed. That's what I have in GameData, yes. Just checked the version file.

I apologize if this is a know issue, but I'm having trouble installing this via CKAN. CKAN says my KSP is incompatible because it's missing Harmony and won't download it either: missing from list and the dependency is marked in red as "not indexed". I downloaded Harmony from the link in the OP and dropped it into GameData, but CKAN still won't recognize it as installed. Was Harmony dropped from CKAN or something?

Private ship was in the lead to get there first, followed by the US ship, followed by the Soviet ship. US ship suddenly deployed a solar sail, which rocketed them to first place. Soviet ship's crew, under pressure from home, overclocked their bootleg NERVAs to close in with the others, resulting in a reactor breach that exposed the crew to radiation. Private ship and US ship agreed that since the latter are in the lead now, the former will double back to save the Soviets. Private ship's ground control, under pressure from the boss, remotely locked the crew out of the ship's systems in order to force the US ship to surrender their lead. US ship doubles back for the rescue and to borrow the Soviet ship's fuel so that they'll have enough delta-V to continue the mission. Soviet ship suffers a malfunction during crew transfer that crashes it into the US ship, killing three. Karma struck in the form the dust storm seen in the video, giving the US ship time to catch up. What the video (and the episode) doesn't show is that in true Kerbal fashion, the US ship struck the ground on landing hard enough to wreck its NERVAs beyond repair, so the crew will be going home without their ship.

Today I used the Klaw for the first time ever, rendezvousing with and deorbiting four spent stages in one flight. Still got four more to go: two in LKO, one in low munar orbit and one on a highly eccentric trajectory between LKO and Minmus' orbit.

Oh yeah. I nearly ripped my hair out trying to juggle stuff around to find something non-stacking that can go alongside the field science gear without exceeding the kerbal's inventory limit.

Did a Duna landing today. Hit the ground harder than I intended (around 5 m/s, using one large parachute, four smaller parachutes, two drogue chutes and minimal engine thrust) but nothing broke and the lander still has about 98% fuel (slightly over 2000 m/s), so it's good enough. Had to do some hairy inventory juggling to be able to deploy my field science equipment, as all the craft's inventory slots were full and the equipment was too heavy to be carried alongside either parachute or jetpack. In the end I succeeded, but the game glitched out: when my engineer got back inside the command pod, the RCS fuel tank in his inventory vanished into thin air and got replaced with an extra parachute for some reason, so now I have four parachutes for three crew and no RCS fuel tank. Not that it matters all that much because Duna's gravity turned out to be about 0.34 m/s2 too much for a jetpack anyway. So now that I transmitted everything, I'm waiting for the field science to finish. Once it does, I'm packing it back up and will try to hop to the nearest biome (I'm sitting on the western slope of the Western Canyon and flew over the Midland Sea and Midlands before the parachutes deployed). Probably won't push my luck with a second one. Once that's done too, it's time for a year-and-a-half wait for the transfer window back home. I'm about 26 points short of unlocking the Klaw, which will be ready in a few days thanks to all the relayed science from Duna making my lab in orbit of Kerbin chugging along at 3 science per day, so I'll be doing orbital debris cleanup next. By the time the Duna trio will be back to Kerbin (as in, docked at the orbital station for refueling until the next transfer window back to Duna), they'll be in for quite a treat in the form of a Mk2 shuttle bringing them down.

Been spending the past two days trying to deploy my first Mun base with a skycrane, without much success. Nothing fancy, just a single Hitchhiker Storage Module and science. Problem is, I cannot precision-land a multi-ton spacecraft onto a deployed ground anchor and I cannot land first and deploy the ground anchor underneath it either because the game absolutely refuses to let me deploy a ground anchor underneath any part belonging to a landed craft, regardless of the craft's actual ground clearance. Tested it out on Kerbin a few minutes ago, ground anchor won't deploy even if there's over four meters of completely empty space underneath the part.

Minor question: is it normal and expected behavior for the mod to not allow locking engine gimbal whatsoever while in flight? Simple test rocket with one HECS, one fuel tank, one Swivel and some aero. While the rocket is standing on the launch pad with engines off and me not touching any controls, the gimbal automatically locks itself every few seconds. This is on purpose, as per the last page. The instant I fire up the engine, the gimbal unlocks immediately and will not let itself be locked at all for the rest of the burn. Even if I lock it manually, it unlocks again after just a few milliseconds. Setting gimbal limit to zero used to prevent this, but it no longer works in the sense that the zero gimbal limit is respected but the gimbal itself is still unlocked. Action groups cannot lock gimbal either while the burn is ongoing. Neither toggle nor lock. Is the latter part on purpose? Because I ran into a problem before where this inability to manually lock engine gimbal during flight caused side effects (caused asymmetric thrust from a force-unlocked gimbal's thrust vector touching the hull). I don't suppose it would be feasible to have the mod detect whether the gimbal was locked by itself or by the player and only unlock it in the former case? I'm thinking... one boolean per engine, set to true when the mod locks the gimbal and checked when it wants to unlock the gimbal. If true, unlock the gimbal and set it to false; if false, leave it locked because it wasn't the mod who locked it.

The [x] Science mod lets you mute these by right-clicking on the mod's button.