Loren Pechtel

Note that if the periapsis of the stage is above 22km it will remain in "orbit" even though it's actually in the atmosphere--game bug, not a Stage Recovery bug. Careful--if this is what is going on and you switch to the offending stage while it's in the atmosphere it's impossible to switch away until it's either down or destroyed.

I mean outlook.com, not the program Outlook. It's not a sync problem between the server and the client. And for some reason I never got an e-mail notification about replies in this thread, I only saw the reply when I came here to reply to a notification about another thread.

I've seen this behavior before with a long rocket and inadequate control authority. It appears to be in the core game as it can be reproduced with a Kerbal on EVA with the jetpack throttled way down. The problem appears to be waiting until too late to attempt to stop the rotation of the rocket, it overshoots the target and then has to go back looking for it--and overshoots again. And again and again and again.

For 3 months now I have had a message in my e-mail account that will not die. I'm trying to figure out if this board keeps resending it or if Outlook is resurrecting it. Does anyone have any idea?

Moving around between planets a TWR of .5 is fine.

Think SpaceX, not Apollo. Don't throw away your ship after a single mission.

I've seen that sort of behavior when the update couldn't be loaded--doesn't match your KSP version or a dependency doesn't match. Note that by default CKAN is sensitive to even the smallest of version changes, even when the mods are still compatible. In the menus there's an option for what KSP versions to accept as compatible.

My fix was to put some Thuds on it, burn for half a second. Include ISRU capability to refuel. I have a pic around of the drill working fine on Kerbin's ice cap!

Simply being very light for it's size would cause the slow fall you're seeing. A high temperature tolerance would cause the former, I've never looked at what it's temperature tolerance is.

SpaceX just gave us a clear illustration.

How would you know a mod is unmaintained? That's a passive state, not an active state. Some mods can go a long time without changes without anything being wrong.

On Kerbin I've even used it where cars can't go. I built a big rover and mounted some jet engines on it. This allows awkward "driving" out onto the water to get the splashed-down science. I also put a pair of drills and some small rockets--a very short burn and I can grab the flying low science. (You need automated science sampler for this, there's no way to collect it manually fast enough.)

The rendezvous planner will do this, although sometimes not the most efficient way.

There's a MechJeb for all mod that puts MechJeb capability on capsules and cores.

Yeah. I had an experience with this that felt totally wrong. I had messed up, I had a grumpy Kerbal around Minmus(?). The tourist bus came along to pick him up (his booster was one-way, the plan from the start was to bring him home on the bus, I just didn't launch it at the right time.) Set up the rendezvous, the bus comes zipping by at a good clip. (MechJeb, why do you start the matching burn at closest approach? It should start earlier so you match velocities at closest approach!) Before the rocket lit (and while he couldn't see the rocket, either, although I don't expect the mod to track that) he got ungrumpy.

I've experienced it with KSP 1.2.2 and I never figured it out. Revert to launch wasn't a factor. If a rocket was bugged it would fail 100% of the time--it would stage correctly the first time but then keep blowing off stages. So long as your second stage got you to orbit it was easy to stop by limiting the auto staging.

I think the real answer should be to change MechJeb--either make it not resume warp if it's turned off, or make a switch to decide whether it should resume warp. (I do find resuming warp useful at times--combined with biomatic set to dewarp on new biome it allows efficient collection of orbital science with little interaction needed.)

I also use it to deal with situations where the game doesn't do what it's supposed to. For example, doing rescue contracts many times I've found kerbals who aren't willing to leave--they'll get out of their craft but they won't let go of it. When that happens I hyperedit the capsule back to Kerbin. I've also used it a couple of times when the mod that adds a decoupler to heat shields went astray. (The mod works as designed but there's an extra attachment point that if you accidentally use it the decoupler fires for no effect.)

It's not that important anyway. I haven't played with the Kerbstein, but since you say it can push you to velocities measured in %c that's the realm of Brachistochrone trajectories. Point at the planet and burn to turnover is going to get you pretty close.

64-bit machine, plenty of memory, run the 64-bit version of KSP. You can't heavily mod the 32-bit version.

In my experience MJ can even fly bricks so long as they are carefully balanced. I've built some pretty messy rovers in the SPH and very carefully placed their coupling point at the COM. I also make sure the drag is at least very close to symmetric. Turn late and shallow, better to waste a bit of fuel going higher than burn it up on the default trajectory. (It will fly with the defaults, surviving the flight is another matter, and the drag might be enough to keep it from reaching orbit. Once your apoapsis reaches the target altitude MJ uses maneuver nodes and doesn't compensate nearly so well.)

Why would it have any huge amount of delta-v?

This is very inefficient. As soon as you enter the SOI of your target body do a burn to set the periapsis to your desired orbit. Do a circularize at periapsis. Note that if your circularization burn will be very long (low TWR & carrying a lot of velocity) you should do it in two stages--do a circularization burn well clear of the body and then lower it to your desired orbit. The problem is that MechJeb does it's math assuming the burn is instant, then brackets it around the burn point. This has an acceptable error margin when the actual result completes in a quite small fraction of an orbit. However, the closer and longer the burn the greater the amount of orbit completed during the burn and the greater the error--flying it into the planet is quite possible with Nerva-powered interplanetary missions.

It sounds like the real problem is you're using a non-stock engine that takes time to throttle up. MechJeb assumes it can do what it wants with the engine's throttle. I have no idea of a solution other than flying the last part of the landing manually. Better Burn Time will give you a pretty good estimate of the suicide burn time, light it a few seconds early to deal with the throttle delay.

Catastrophic? In my experience the behavior you describe is normal and desirable. When you attempt to land at a target MechJeb actually aims for a point that in my experience is 500m above the target. Once it reaches that point it drops the rocket straight down and then burns to reach a soft touchdown. This is a lot safer than doing a suicide burn that's prone towards leaving inaccuracies that cause the rocket to land not straight up or with a horizontal velocity component like tends to happen when you use the land anywhere function.