Loren Pechtel

But how do they know? Besides, it was going at a decent clip (for Minmus orbit) at the time in question. It would feel ok if they reacted like that when the ship pulled up and stopped, but they got happy before the rendezvous burn.

I just had an outcome that feels wrong--this is not a bug. I had some of the orange Kerbals "stranded" (they are in their ascent rocket, it was never meant to get home) in Minmus orbit. I got the timing a bit wrong and they were homesick. Their ride home shows up--and as it is making it's approach they go back on duty. The sight of a passing rocket is enough to end homesickness?!?!?! (From a technical standpoint I know what happened--it got into the 150m sharing range and it's got much nicer quarters--currently completely empty--than the bird they lifted off Minmus in.) I'm not sure why the sharing range exists in the first place but in this case at least an easy fix would be the sharing applies only to rockets that are closely matched in velocity.

As for the circularization: I have seen two cases that can result in it going spectacularly wrong but both are predictable. 1) The circularization burn is computed based on the engine you are using at the time. It is quite accurate if you continue to use that engine but if you stage to a lower thrust engine during the burn (note: there also is an issue that I do not understand, sometimes it can stage during circularization fine, sometimes it can't. Any given rocket either works or must be manually staged.) it will be off on it's timing. The bigger the thrust difference and the lower the target orbit the worse this will be. If I'm going beyond LKO and not landing I use a Nerva engine for space use--and this really shows up the circularization problem. The rocket I'm flying as I write this must be aimed to at least 120km up in order to survive circularization--and the result leaves the apoapsis twice the periapsis, the latter just barely outside the atmosphere. 2) it will not consider the circularization burn until it leaves the atmosphere. With a high thrust first stage (which makes for a less than ideal gravity turn) and a very low target orbit you can end up doing the burn late because it can't start it in time. It touches atmosphere and doesn't know how to recover. As for landings, I am aware of two issues: 1) As far as I can tell both from behavior and from an admittedly not too deep look at the source code the land anywhere function is only safe if you have very little horizontal velocity. 2) MechJeb's safety margins do not consider how fast the rocket can turn. If a rocket isn't maneuverable enough (and note that the more gravity the more maneuverability it needs) it won't be able to point the engine correctly in time. This is especially bad if the rocket is both hard to turn and very powerful. (Beware fuel shuttles--powered to lift with full tanks but landing on nearly empty tanks. Even on Minmus I've watched them get into an overcorrection loop and smack the ground without ever trying to stop.)

Why even have it turned on?

I'm suddenly having a big problem with wheels. I have a rover on Minmus. It's complaining that the wheels aren't on the ground--yet I'm on the Greater Flats, they have to be on the ground! I've rolled it some distance, no change. The one thing unusual about the situation is that there is also a lander on Minmus, well apart from the rover, that has a BV control module on it but has no wheels at all--it's not meant to go anywhere, I put the controller on it so I can switch to the lander without going back to the tracking station. Edit: I Hyperedited fuel onto the lander and put it back in orbit. No change. Note that this rover is an exact copy of one that has successfully crawled all over the Mun. The Mun rover still works, albeit with a speed penalty since I took the crew off. Edit: Tried it with Maja's release--no wheel errors but it shows no BV rovers at all and the rover doesn't move. Edit: I reverted to the release version, went back and launched a new rover. Same problem. It's not just on the flats, I've used MechJeb to drive it to half the biomes on Minmus, BV still gripes about the wheels. Same lander (it was already in flight at my save) but I never landed it. It's in Minmus orbit.

Yeah, it would still have some use--I don't think hitting the atmosphere while doing a spacewalk would be a good idea! (I have had a Kerbal in a command seat while dabbling in the edges of the atmosphere, though--works fine.)

Maybe if you're hitting really hot but so long as the entry angle is low I've found it's perfectly acceptable to wait on the solar panels until I actually hit the atmosphere. The outer fringes won't break them. I've never hit atmosphere with anything but conformal radiators so I can't say how vulnerable they are.

Some comments on this: 1) Things are modeled as if the burn is instant. The greater the orbital rotation during the burn the greater the error will be, to the point that with an interplanetary burn with the Nerva engine from LKO is guaranteed suicide (flies you into Kerbin.) When I use the Nerva I raise my orbit before doing a big burn. 2) The Hohmann routine does not do plane changes. Thus it is normal for it to fail to intercept anything not in your orbital plane--say, Minmus. Ideally you start out with the planes matched, but if they aren't it's much cheaper to do a midcourse correction for Minmus than to match while in Kerbin's orbit. Mun's orbital plane matches Kerbin's equator so that is normally not a factor when heading there.

If you have a folder named KIS-master my first thought would be that you downloaded the source code rather than the mod.

I can't address the rest of your stuff but I think the answer here is a pair of mods: KIS and KAS. (I'm not sure which you actually need in this case.) What they allow is to put things together or take things apart out in space. Thus take an ISRU and attach it to your existing base.

Nope, every time I've tried to use it to fix a Krakened rover it went boom.

Temporarily until they get supplies. What I'm seeing is permanent.

Yes, I have USI-LS, but it doesn't mess with the types of Kerbals. Kolonization does.

I've looked through the pathfinding and I don't believe it can be the culprit. The rover is going where it's supposed to. I do not understand the power issue and haven't looked--that's going to involve too much interaction with KSP as opposed to the code in front of me. The terrain issue always involves the rover being in a seriously weird position that can't be explained by it's movement around the planet. (There is a cosmetic bug that the rover spawns in it's previous orientation and then corrects to the current terrain but the Kraken incidents involve rotations not explained by it's travel, and once, quite some time ago, put it many kilometers above the surface of the world.) The one common element I can find is that it only happens when the rover is on a different world than the focused one--this makes me suspect that somehow it's related to taking data off the wrong world or something. I'm planning a rover to Minmus next and I'm going to try something. I'm going to slap a BV controller on the return rocket (separate mission, the issue mentioned earlier won't bite me) and stay on Minmus for the entire process. (The BV controller will let me switch to it without going back to the tracking center.)

I very much doubt this could be reproduced other than randomly--who spawns in a rescue is semi-random. KSP 1.2.2.1622 MKS: .0.50.18.0 A gazillion other mods but nothing else that messes with the kerbal types which is why I figured it was Kolonization. I think what's happening is it is picking from the available types and not considering that tourists should not be selected.

Minor bug that I think must have been due to this mod: Routine rescue contract about the Mun. The Kerbal I pulled in was a tourist. He had no problems EVAing over to my rocket, though. Update: The mission got home. I have a Tourist in my roster.

I had no problems on Kerbin and I've never seen the Kraken attack one there. I'm wondering if it has something to do with it somehow mixing up the body the rover is on with the current body sometimes. I've looked through the code and I sure can't see how the strangeness is happening. I haven't upgraded to 1.3 yet, though--still waiting on mods.

I've been having some power problems. I have a fairly large rover on the Mun (I'm running USI life support) with Kerbals on board. Three times now it has waited too long for sunlight, when I switch to it it's in the sun. Two of those three times involved Kraken attacks, though--once it was hanging upside-down in space an unknown distance above the ground, when I tried to use HyperEdit to put it back down it blew itself to bits. The second time I found it standing on it's front bumper, it fell forward. The third time nothing was wrong and I was able to continue the mission. There was also a time after reaching it's target I found it with the front about 60 degrees above the horizon. It fell and bounced but survived the experience.

What mirrored symmetry in the VAB?

I built a rover in the SPH, took it over to the VAB and I'm trying to strap boosters to it to get it to where it's going. I've done this before by putting a docking port on the top of the rover and decoupling when it was down but this time I tried to do it by directly coupling the boosters to the side of the rover. Unfortunately it's determined to put one part right side up and one part upside-down. That's very nasty for getting everything nicely balanced for flight! Any way around this?

Been playing with some designs to make Kerbals happy for long voyages and I find myself disagreeing with one decision: Cupolas are listed as providing a multiplier for one Kerbal. I find that strange as a cupola is not something that is going to be used anything remotely like 24/7 and thus multiple Kerbals should be able to benefit.

This is yet another one that probably needs nothing but version updating for 1.3

1.3? I strongly suspect it will simply work but updating the version info on CKAN would be nice.

One more data point: My probe was in a 1000km orbit (nuke engine, that long a burn in low orbit is a bad idea) about Kerbin, burning for Duna. Given my previous experience I was keeping an eye on the intercept so I didn't catch it for certain but I think I reconstructed it: It appears that my orbit went through Minmus' SOI. The orbit projection momentarily went wacky (like it tends to when your burn causes you to touch a SOI), the burn timer added about 250m/s to the burn and quit burning. When I investigated I did not have a Minmus intercept but it looked close. I set SAS to hold the position and burned manually--after about the remaining burn as originally set (not after the Minmus bit) I got an intercept with Duna.

I'll see what I can do with rigging a rudder. Since this is also a rover I don't have a lot of clearance. All the mining gear is in the back, although the ore tank is empty. The craft is as symmetric as I could build it other than the science instruments that are it's reason for existence.