2-2.2.1.257 bugs in ascent guidance
BigTexun opened this issue · 4 comments
So I generally like to manually launch to orbit, because I can usually do it wasting less fuel than mechjeb, which tends to overshoot and constantly correct, when I can anticipate and prevent overshoot.
So I will use it to time the launch, then disengage and select "show navball ascent guidence", then launch into orbit by hand, using the navball guidence as a visual aid.
So the "bug" is that when I hit the "show navball ascent guidence" button, my target is de-selected. Of course there is no ascent guidance now, because there is no target. Ooops!
In the flight attempts going to the same asteroid, I try to use one of the "launch to interplanetary window" or "Launch to redevous", the orbit escape burn crashes be into Kerbin. In my last attempt, I made sure the maneuver node looked sane, but when I executed is started the burn well before the node, and the resulting trajectory looks like it was trying to sling-shot around the Kerban center of gravity, well within the inside of the planet.
I know I can avoid these issues, there is a thousand different ways to do everything, but these seemed like bugs to me.
I think atleast the node "bug" isn't one. MJ starts a node burn 50%
before it's set, meaning a 2min node will be started 1min before the node.
So if you have a high dV node and by comparison low TWR then MJ will
start while pointing seemingly completely wrong.
Normally the result works out close enough but it has of course it's limits.
But I haven't used the mentioned features yet so this is as far as my
knowledge goes.
Well, this was a 600km orbit, and the burn ENDED at least 20 minutes
early, and the resulting flight path departed orbit in the opposite
direction of the intended node, and the only nodes that existed were
the ones created by Mechjeb. AND I did it three times in a row,
changing things slightly each time in an attempt to correct. I think
it was a feature of the particular object, which orbit was one that
crosses Kerbin, and was on an intersect. My flight path was to
intersect the rock well before the kerbin intersect, and 4 months
away. The node appeared to be in the correct place, I think that only
a math anomaly could cause this sort of issue.
But you are right, it is probably a feature in the math somewhere, and
it is working as designed, and the design may not take some
characteristics of the asteroid problem into account. It could be
that Mechjeb planet transfers cannot transfer between planets that
have the same orbit with varying levels of eccentricity.
What I saw could one of two different bugs. It could be that it
simply misfired and the problem is in the math that decides when the
burn starts, OR it could be a problem with orbit types such as
expected by orbit-crossing objects.
The bug may be simply that Mechjeb should have refused to accept the
maneuver. I may have been asking for an improper application of the
function I was requesting. Or that I needed to use a lower orbit. (I
like orbits slightly higher than 600km, so that when I have a log
warp-wait in a parking orbit, I can warp at the highest possible
speed. Low parking orbits are probably more efficient, but they are
painfully slow when it comes to waiting for a node that is several
orbits out.
Keoki
On Saturday 07/06/2014 at 7:01 pm, BloodyRain2k wrote:
I think atleast the node "bug" isn't one. MJ starts a node burn 50%
before it's set, meaning a 2min node will be started 1min before the
node.
So if you have a high dV node and by comparison low TWR then MJ will
start while pointing seemingly completely wrong.
Normally the result works out close enough but it has of course it's
limits.But I haven't used the mentioned features yet so this is as far as my
knowledge goes. —
Reply to this email directly or view it on GitHub.
KSP and MechJeb are known to do some questionable things with maneuver nodes set 10+ orbits out. A workaround might be to just manually time warp until you are within a single orbit of the burn and then set up the maneuver.
It does seem like this could be done automatically by MechJeb, but that would be more of a feature request at this point. Neither MechJeb or KSP were built to handle maneuvers many orbits out... yet...
As a side note, higher orbits should result in more accurate burns, but this may just be my opinion/experience.
Closing this as an old MechJeb issue. Many MechJeb issues have had little interest in years, have been fixed for years, do not include adequate replication steps, refer to old problems which are no longer applicable, or are difficult to determine what the problem is. This issue is being closed for one of those reasons. We apologize for any inconvenience, but keeping the TODO list tidy helps the developers.
If this bug/issue is still a problem, please open a new issue. For bugs please try to include a Minimal, Complete, Verifiable Example that explains all the steps required to replicate the issue. A link to the KSP.log file should be ideally included, but is often not sufficient information. Screenshots or short videos are often the best way to show a bug.