MechJeb 2.5.0 on KSP 1.0.2

Maybe fail on all planets with atmosphere.

It reports that it needs delta-v more than 4000 m/s to land at KSC launchpad from a equatorial orbit (height 100km)

Yeah there seems to be something wrong, while the AP is active the landing estimation goes all over the planet, if it is somewhere on it at all.

But the estimations alone seem to be fine, even the old chute use bug seems to be gone.

Maybe the AP forgets to reset the estimation each simulation and just stacks them? Would explain why they go all around constantly and only sometimes for one frame are even somewhere near the real estimation.

Ya, it seems that the aerodynamic model works fine. The impact location is correct, but the autopilot goes wrong.

I've noticed the same thing, but I realized I have a slightly old version of mechjeb(since I get the "update me!" notification, even though I'm also running 2.5.0.0) so I hadn't wanted to post anything about it. Can confirm this bug happens on Kerbin and confirm it is not happening on Mun/Minmus so atmosphere presence looks to be the likely culprit.

As far as I can tell it points in the wrong direction to make course corrections. I've also noticed some uncertainty during course correction as far as landing location, usually while the improper corrections are made, as observed by BloodyRain2k. The landing location flickers when course correction begins, sometimes appearing at the proper place, sometimes not even close.

There are some errors in 2.5.0.0 as far as atmospheric drag is concerned, as landing guidance aerobrake node display is almost always wrong. During aerobraking the finished orbit tends to lose a few KM from both Ap and Pe, the estimates slowly grow smaller as aerobraking progresses, and I would highly recommend being conservative with your aerobraking as I've accidentally re-entered when landing guidance said I'd still have an Ap in space. This may or may not be related, I'm not sure, I just thought I'd throw it out there since it might be related. It seems more likely to me that the course correction code is what's causing this error, and given how it tends to point in the wrong direction, it could be something as simple as a missed sign.

What build of 2.5.0.0? Current is 2.5.0.0-455 ( as of right now, this may change within minutes or days.

I'm not sure, it took me a while to even find 2.5.0.0 (compared to 2.5)

Where would I find that number?

Where you downloaded it. If that was anywhere other than http://jenkins.mumech.com/job/MechJeb2/ it is out of date.

Also, just made the connection that the dV required to land does not take into account aerobraking. The majority of the dV required to land on kerbin will be supplied through aerobraking, and with sufficient parachutes, all of it will be.

While I've noticed this absurd amount of dV required before atmospheric reentry, I haven't watched during the actual landing phase whether or not dV decreases as aerobraking happens. I would assume it does. This functionality seems "wrong," as aerobraking will be applied automatically, and dV required to land implies dV you need to apply to land successfully, but it is useful in that you can examine how much aerobraking will happen, which will be somewhat related to heat generated.

@ futrtrubl: I downloaded on April 29th so I'm using 438 at best. Will update to newest version and run through this issue again.

The dV required is more a function of the terminal velocity at the altitude you will land at unless there is incomplete aerobraking. Currently terminal velocity is calculated by your current drag and speed, which wouldn't apply for different atmosphere density, and of course doesn't apply while you are still in orbit.

Futrtrubl: Ah, so even in the newest version, aerobraking dV will be shown in the dV required to land while still above atmo?

I'm still not sure whether or not that's good or not. It confirms my assumption that the shown dV required will decrease as aerobraking occurs. Perhaps a way to differentiate between dV which must be applied versus dV automatically applied by atmo, via calculating landing terminal vel (or actual vel if f_drag is greater than f_g at time of landing)? Parachutes throw a bit of a monkey wrench into the works though, since on the majority of my landings I need 0 dV.

I have noticed that on a body without atmosphere, when you enter final descent stage at 500m above the surface after hvel has been cancelled, dV required to land is zero. This is definitely erroneous. But I think I'm probably deviating from the original issue a bit too much with that.

By default CKAN gives you the official build. That one has all the error you mention and I should release a new one today or tomorrow.
If you want the "dev builds" that follow all the code updates (and has some new bugs from time to time) you can configure CKAN to get them. Go in the settings, press the "New" button and in the list choose the Mechjeb2-Dev line and add it. Once you refresh the mod list you ll see a new Mechjeb2-dev mod.

I don't known how to figure out the build, but I downloaded it from CKAN

In build 455, dV shown to land on kerbin from suborbital (above atmo and in atmo) is zero, on a craft which does not need any dV to land (aerobraking + parachutes results in safe landing).

Better to have people pleasantly surprised than screaming hordes asking why it don't werk ;']

umm, it seems that build#455 works fine, far better than claimed "not working properly" :)

The current system assume you are going backward in the atmo. The code to set that is in here but not the UI.

After seeing this, I'm about 60% certain that the drag model is where the problem is occurring. Also, it flips occasionally, from saying I'm going to land (where it will constantly change the location, I noticed that target difference is always increasing) to saying it's going to aerobrake. I also noticed that while it is not the predicted orbit from before, the new predicted orbit (shown in the second picture) is actually staying stable during aerobraking.

Also, I hate to say it, but craft profile will have an affect on aerobraking, which may be where this comes into play. Since Squad updated the drag mechanic, you can go from pulling 1g while pointed svel-, to pulling tens of g's while perpendicular to svel.

I'm not sure if this is relevant or not, but it seems like it might be tied into the autolander code at least. I'm trying to autoland from a retrograde orbit (inclination 176 degrees) on minmus, and I already had a craft impact hard once. I'm running through it again, and I'm getting the same problem as before. During descent after deorbit burn, it will warp for a short time before dropping out of warp to readjust alignment. It missed braking burn completely the first time, I'm not giving it a second chance to. If you think this is a completely separate issue I can drop a new issue ticket.

Update on original issue: build 455 now seems to be fairly accurate on getting me to where I want to land on kerbin, was only off by 1.2km and I didn't see the same error I had previously with correcting trajectory. However, it did not deploy parachutes and was attempting to use the engines to slow down still, I had to manually deploy parachutes at 600m. Even though terminal with parachutes was below landing target vel, it still used the engines to slow down further until I disabled autoland.

Some craft are unstable when aimed svel-, and most craft without WAY too many torque modules cannot sit for any length of time at their high-drag profile alignment when compared to their low drag profile. It might be possible to determine the lowest drag profile alignment and use that, as it would be the stable alignment. I'm not sure a UI choice would be useful because of how much it would take to be able to maintain that profile, but that code would be very useful for craft which are unstable in svel-

basically another dup of #1052 and fix everything about landing.