Meumeu

If you're talking about this test: + if (Quaternion.Dot(value, _lastAttitudeTarget) < 0) + _attitudeTarget = value.Mult(-1); + else + _attitudeTarget = value; It's to make sure the quaternion is continuous before differentiating it for the feedforward.

That should be fixed in the latest dev build. Thanks for the tip Starwaster.

Yes, if you try to extend or retract a fixed solar panel, they will get stuck in the extending or retracting state and core.solarpanel.AllRetracted() will stay false and the ascent guidance won't switch to the vertical ascent phase. There's a retractable variable too but it is not set in any stock solar panel configuration file so I'm not sure what it does... I'll check with a debugger when I have the time to see which property should be checked (probably this evening)

They only have to be a ModuleDeployableSolarPanel, so they should work; but the autodeployment is not enabled by default anymore you have to enable it in the utilities window or in the ascent guidance.

That's not surprising, if the engines are slow to start MechJeb won't be able to apply the correct torque on the engines. It might work if the attitude control response is slower than the engine response but that's just a gut feeling, I've never tried this.

µ is the standard gravitational parameter, also µ for Earth is 398600 km^3/s^2, be careful when comparing values or you can easily be wrong by a factor one billion...

Basically it needs at least 3 liquid fueled engines that are not aligned, I used this to test it: craft file It works with solid rockets as long as the main throttle is high enough to produce enough torque, and changing the throttle limit won't do anything since it works by calculating new values depending on the commanded torque.

It is you can fly monstrosities into space now. Yes, that was me too.

Yeah, I hesitated between replacing the old interplanetary transfer and adding it as a new maneuver, in case there was a bug I didn't see or if someone didn't like porkchops... Also, by putting it at the top of the list, everyone can see there's a new maneuver. By the way, did anybody try it on a not-so-fast CPU? Xytovl and I only tested it on our cores i7, we're not sure how long it takes on other CPUs...

I think that tahib's problem is that when the text value is parsed, the time is then converted to a text again and replaces the value he typed. I fixed that in my latest pull request, based on the timestamps it should be fixed in version 338.

That's because the thrust from jet engines depends on the velocity, MechJeb doesn't take that in account. There are some plots here to explain how they work.

There's a null reference if the spacecraft is in orbit around the Sun, it should be fixed in the latest dev build.

Previously, even the planned maneuver could have a periapsis far from the planet, and sometimes not even intersect the SoI. Now the planned maneuver intersects the planet most of the time. So yes, you should still check if a course correction is required, but it should be much smaller than before.

Basically, this is meant to replace the old boring interplanetary transfer maneuver. Instead of doing a Hohmann transfer, it shows a plot of all possible transfers (within a reasonable period) and their deltaV, the cheapest transfer is selected by default but you can pick another one if you're in a hurry: the X axis is the departure date and the Y axis is the transfer duration, the exact values for the dates and the deltaV are shown under the plot. Also because it actually uses the Lambert solver, the transfer actually reaches the target instead of requiring a course correction.

Hi, I've wanted the same thing and I managed to make it land a few centimeters from the target. I've actually just done the pull request here, but I've only tried it on one craft and only on Kerbin and the Mün...