Jim DiGriz

If you want a bit of promising developments I just found this paper: https://arc.aiaa.org/doi/abs/10.2514/1.G004048 That has a clearest explanation of apollo descent guidance I've seen, with successively increasing levels of tweaks to make it more and more optimal, but without needing to solve a full pseudospectral convex optimization problem. That bumps landing guidance up significantly on the list of things I might take a run at cleaning up.

Right the problem is that MJ isn't built on particularly good foundations and I'm thinking about KSP2. So there's a reasonably solid ODE integrator in MJ now which is approaching the functionality of Matlab's ODE45, there's now Brent's 1-d minimization and root finding algorithms, there's a pretty well debugged Gooding Lambert solver, there's alglib.net's implementation of Levenburg-Marquardt for gradient descent rootfinding in N-dimensions, there's other stuff like Shepperd's solution for orbit propagation (and sometime soon calculation of the primer vector and state transition matrix). All of that is getting MJ on a much more solid foundation where its both more debuggable and easier to rip out large pieces of MJ in the event that KSP2 happens and hit the ground running. Some of that is noodling on issues that don't seem important but ultimately it leads to things like being able to simplify the flying sim to be able to more accurately land rockets (and maybe doing something about the parts sim in the fuelflowsimulation as well). So the stuff which seems pointlessly foundational can feed back into fixing bugs across the board by leveraging battle tested components (which is why I messed up Hohmann transfers which nobody really needed in order to get Brent's algorithm solidly tested). The idea of doing a multi-node KAC-like suspendable node executor probably is something that "well maybe that is more a plan for KSP2" comes up, IDK. Depends on when KSP2 happens or if it happens. And the problem is that I've never used rovers, and don't think I've ever touched the rover autopilot once. MJ is way too sprawlingly vast. Similarly I haven't had any time to play with any of the new features. And there's hundreds of hours of work that I'd like to get done ahead of that just to make rockets work better. I've got some code right now which implements a quaternion-based PID controller which might be a quantum jump up in PID control and fix a lot of the issues people have with controls which cuts across the board. Before I touched rovers/BG I'd probably look at fixing the rendezvous autopilot since there HAS to be a way to make that better and easier to use without wasting so much RCS. In the RSS/RO world people have been bugging me a lot about mid-course corrections since often plane changes in low orbit are very suboptimal. Could also do bi-elliptic transfers now that the maneuver planner supports multi-node planning (which is like a 4 year old user request).

kOS is the answer. People keep asking for this, but the code is very difficult. I took a run at it awhile back and got frustrated with what I wanted to do with it. The existing code is actually very full featured, but tightly coupled to itself in ways that make it difficult to e.g. extract the ODE integrator. If the ODE integrator and the parts simulation of the flying sim were extracted to be more self contained then the remaining actual physics sim would be vastly simpler to debug and extend. Implementing features on top of the existing code is likely to produce a mess of spaghetti that nobody can understand.

Yeah MJ really needs a proper finite burn executor. There's already a button though to omit the circularization burn completely from the porkchop and then you don't get the maneuver node. I've got plans of extending the UI to support targeting an inclination and an apoapsis (or SMA + ECC). I can probably include a button though to omit the second burn. At some point though I'm going to want to implement a flyby finder which will necessarily require dropping maneuver nodes on every flyby. There needs to be some kind of better solution to this -- ideally a multinode finite burn executor that target a list of orbits rather than a list of maneuver nodes and which can be suspended in the background and will wake itself up like KAC. #942 looks right. Still working on the buggy behavior, I went barking up the wrong tree last night, got a few things to try today. I don't think I have any need for more replication cases, it is pretty obviously broken in the coplanar case (I did a lot of testing in awful non-coplanar, elliptical cases that I assumed would be the best problems to find bug but never bothered much with the trivial cases). EDIT: I figured it out, just needed to keep reading further in the paper I was implementing. Replicated some values for Kerbin->Duna from Alex Moon's transfer planner in Matlab. Might have it fixed in a couple days.

So the porkchop plotter for the transfers WHEN including the transfer burn will be off by a bit. Currently it is still just taking the difference between the helocentric transfer orbit and the helocentric velocity of the target planet and calling that the "capture burn". So there's a discrepancy of 200 m/s extra that I find when I actually plot it. That's a known issue. Oh yeah, delta-V maps have kerbin LEO to duna intercept of about 1060 and 600 to capture. And visibly it just looks poor to my eye, the transfers burn isn't very tangential to the parking orbit. And since it affects the porkchop plot equally, and from the logs it doesn't look like the optimization of the maneuver node is changing the dV much, it looks like its a bug in the new analytical burn calculator. Okay, that repos really simply. There's no workaround, I probably just have a math bug someplace to track down.

What is in the logs? Also it helps if you annotate what the different screengrabs are, otherwise I'm stuck looking for clues as to what you're doing and what you are trying to highlight (sometimes it is obvious, but without seeing the buttons you were pressing sometimes its hard to tell what you are actually doing). Also, it is expected that the porkchop plots will differ from all the other existing transfer planners now. The calculations that MJ uses now takes into account noncoplanar elliptical inclined parking orbits. Alex Moon's planner specifies that it is from circular, equatorial orbits only (and I don't know if he's squashed the solar system down into a plane or not to keep the math simple). MJ used to use a circular approximation (so elliptical orbits were entirely broken) and the code was somewhat unreadable and might or might not have supported inclined non-coplanar parking orbits correctly. So far I'm having a somewhat difficult time replicating this, although I did notice that at first "box drawing" on the porkchop plot seemed to be entirely broken, although when I hit "create node" once after trying to draw boxes that it picked a completely insane transfer (incredibly expensive but it worked), then I clicked "reset" and it went back to normal. So it was like it was drawing the boxes and zooming into a section of the porkchop plot but wasn't display it back properly. IDK how that happened, and it seemed to magically fix itself. EDIT: Oh I seem to have figured it out. First create a node so you have a transfer and "initial orbit cannot be hyperbolic" comes up. Then draw a box somewhere reasonably expensive (like a small box around some "green" stuff). The porkchop display will not change, but the box selection will have been made. The press "remove all nodes" followed by "create node" and get some relatively insane ~4000 m/s transfer even though the display is saying that there should be much better transfers. Press "remove all nodes" followed by "reset" and then you can go back and draw correctly and it all makes sense. That seems to just be a UI bug rather than a math bug if that's the problem.

Yeah so that button IS there for a reason. The problem is that I see too many twitch streamers playing with KSP + MJ thinking that they can just button mash, and mashing reset guidance is guaranteed to screw up your day eventually. You've now figured out when + why you should actually go ahead and press that button. It should maybe say "pressing this button voids your warranty" -- if it works, great, if it kills your launch you were warned.

No, there is no RSS switch, the configuration of the planets don't matter at all. If you are using 1.8 or 1.9 you should be on the latest dev release which has the major overhaul of the advanced transfer planner that I posted the message about awhile back. If you are not on that version then that behavior is due to known bugs. If you are playing on 1.7 there is no real solution, except that you need to be in the plane of the ecliptic and need to be in a circular parking orbit. If you're on the dev version in 1.8/1.9 then I'd need a better bug report.

For PVG you need to read this: https://github.com/KSP-RO/RP-0/wiki/TroubleshootingMechJebPVG For that specific problem, I can't guess how you got there or what went wrong. PVG diagnosis is dramatically easier with a full video of the launch compared to a screenshot. All I can tell from that screenshot is that something has definitely broken, which you already know.

Yeah I was sorta afraid that would be the result. Can you get the source and destination orbital elements? (ideally I could use all 6 of them for both orbits) Nevermind, I got a repro case first try. EDIT: aaaand its gone. Found one repo case, which then disappeared before I could get any debugging around it. #946 build may have fixed the problem, the patch in the #945 build clearly had an issue.

Build #945 may help with this

Just merged this: https://github.com/MuMech/MechJeb2/pull/1235 Which is a pretty major overhaul to the guts of the advanced transfer planner. Prior to this change elliptical orbits definitely would have been poor and often failed to converged to a node at all. It should be a lot more reliable now. The porkchop plot should also be more accurate. The biggest new feature is that if you click the "include capture burn" button you actually get a second manuever node which is a circularization burn around the target. The porkchop plot for the "include capture burn" option is inaccurate, I need to fix it the same way I fixed the ejection burn. Lots of math behind the scenes got a huge forklift upgrade a lot of highly "Kerballed-Up" math got nuked that was standing in the way. There may be bugs, it was quite a bit of extremely difficult code. The periapsis control and circularization accuracy may be off until fixes land in KSP 1.10.x due to floating point round off error issues. Also without a highly precise finite burn executor, results of actually trying to execute the second burn may be wildly off. That is now available as dev build #943

You can go into the settings and select the compact gui skin, and you can adjust the UI scale to 0.9 or even 0.8

You need ModuleManager installed and/or you need to use the AR202 part probably (assuming you are starting over clean in KSP 1.9 and have only installed MJ). With no apparent issues, and nothing in the release notes that should require issues, sarbian is just going to bump the compat checker and release 1.8/1.9 compatible MJ binaries -- which means that ignoring the compat checker warning is the correct thing to do. EDIT: Sarbian has done a release so once CKAN is done updating it should show up and stop complaining about the version checker. There's also a PR into CKAN to add MM as an explicit dep of MJ, once that gets merged to CKAN then it should eliminate most of the complaints from users who forget to MM/AR202 (users who hand install MJ and forget MM may of course still hit that problem).

That shouldn't be it then. MechJeb doesn't run on debris, has to have the MechJebCore module attached to it, so the AR404 part or the MM patched CommandPods, unless something really weird has happened and you have managed to get the MJ module on debris.

I think some RO players determined that this happens when a vessel has multiple command pods and during separation (or presumably RUD) the command pod on the inactive vessel starts spamming FAR debug stuff. That smells more like a FAR bug associated with inactive vessels. The workaround is to disable mechjeb manually via the tweakable on the part for command pods which should be active (this is more of an issue with RO and multiple command pods due to the need to include avionics on every significant stage, so boosters commonly drop command pods).

Go into the Attitude Controller and under the Hybrid Controller tweak the MaxStoppingTime up to 10.0 or so, or just include a lot more reaction wheels on your vessel. Once you do that, though, you will waste a lot of RCS if you have a vessel using primarily RCS.

I can't replicate that, but give #935 a try.

Dev build #932 shipped which supports multi-node maneuvers being generated from the maneuver planner, although nothing uses this, so should be no user-visible changes at all.

Dev build #931 shipped which may affect fine-tune-closest-approach and rendezvous functions, the old Lambert solver was removed and converted.

Ancient bugs in some heuristics in the ApR raise maneuver which was exposed by stricter checking by the new rootfinder. Dev build #930 just went out and should fix this problem.

Hmm, yeah now that I finally fixed my builds, I immediately got a repro now without trying too hard.

When you see this error what is the exact orbit that you're starting from, the exact altitude that you're using (and are you going towards the Pe or the Ap), and the target ApR that you're punching in to raise to?

No, all MechJeb has ever done is "follow the navball burn indicator" which is a impulsive (infinitely short time) approxmation to the burn that you need to do. As you go to lower TWR engines, particularly in tight orbits around Kerbin, that approximation starts to fail worse and accurate node execution will suffer. Use higher TWR engines or launch to somewhat higher orbits. Even with an accurate, optimal, precision finite burn executor long low TWR burns from low kerbin orbit will tend to crash you into the atmosphere and would need to be broken up.

Yes. Modding shouldn't be an upaid job and modders should not be getting requests for status updates, which just a nice way of phrasing pestering. Your boss pesters you for status updates and you put up with it because you're being paid for it. The existence of a branch in github only means that the problem is being worked on. If it was complete and shippable, it would be merged and released. And the irritating bit of the question is leading it off with "not pestering but..." followed by essentially pestering.