Jim DiGriz

That got fixed awhile ago in RealismOverhaul. That is a problem with all stock ships with RealismOverhaul. The individual parts all get correctly modified to have the right fuels, but the stock ships wind up with both stock-fuel and RF-fuels in them. It has nothing to do with RSB itself. You have to load the stock ship and then 'rebuild' it with fresh parts from the menu, then save it. There is no other workaround.

A module manager patch to restore the pre-1.7 values would also be easy to create and distribute via CKAN

At some point in the future I might take a run at better auto-tuning quaternion-based PID controllers, but that kind of thing is literally an active area of research in the professional literature. It is not a simple bugfix kind of problem. And whatever changes you make to naive PID controllers it is a process of pushing bugs and tuning issues around that will never satisfy everyone. The solution that you're going towards is likely the correct solution. The way that KSP is designed to be a ragdoll rocket simulation is both one of its strengths and also entirely awful. Mods like KerbalJointReinforcement try to address the problems that it creates. I think you can also use editor extensions to set the default autostruts to grandparent part in the VAB (or you can convert them all with one click, I can't quite recall now -- but it definitely makes it easier to work with autostruts).

Yeah noodles would probably never settle down their angular velocities. Manually starting the warp should kick it off.

The GoodingSolver fixes in the dev builds should fix the "tearing" on the porkchop plot and might be related to the NRE spam but its impossible to say since there's no indication of what is NRE'ing in the logs.

Heh yeah, bit of a long road from uterine contractions to optimal free space n-impulse trajectories: https://arc.aiaa.org/doi/10.2514/3.4949 Matlab code which implements the analysis part of this is here: https://www.mathworks.com/matlabcentral/fileexchange/39160-optimal-impulsive-orbital-transfer?s_tid=prof_contriblnk primer.m, pviniz.m, pvector.m and stm.m seem to be the most relevant files.

And maybe to head off a question about the new biimpulsive transfer planner code -- it still isn't wired up with UX to support manual entering of the search criteria. That means that for certain cases it comes up with optimal-but-not-what-i-wanted trajectories. So from a parking orbit to intercept a hyperbolic asteroid orbit, it will prefer to intercept at the SOI exit of the hyperbolic orbit because that is minimal delta v, but maximally useless if you wanted to burn at the periapsis of the hyperbolic orbit to capture it. Gotta get the basic algorithm working though before adding tons of knobs and dials to it and crawl before you walk before you run and all that...

Other nuts and bolts stuff that has gone into #877 and leading up to it: - Goodings Lambert method got debugged, which may impact some of the accuracy of the porkchop predictions in the advanced transfer planner (or rather may have fixed some bugs that were reported about inaccuracies in the porkchop plot) - The non-simple biimpulsive transfer planner has had a ton of bugfixing and should work now much more reliably. Specifically: * it is now a basin-hopping algorithm instead of simulated annealing (although its probably not terribly well tuned and there's still some annealing-style code in it) * it uses the (debugged) Gooding solver * it is wired up to Shepperd's method for keplerian propagation * several crazy bugs that would have rendered it pretty much unusable got fixed It is now fairly close to being able to calculate the primer vector trajectory using Shepperd's method along the path and analyze it for optimality, which will lead to implementing Jezewski's algorithm for generating optimal N-impulse transfer trajectories (read: MechJeb will be able to figure out optimal mid course corrections -- although not interplanetary ones -- in the somewhat near future).

Should be fixed in #877

You may have wound up with a MechJeb directory inside your MechJeb directory, so both GameData/MechJeb2/Plugins/MechJeb2.dll and GameData/MechJeb2/MechJeb2/Plugins/MechJeb2.dll both existed or something, and then who knows which dll gets wired up right. And if anyone is reading this and blowing away their MJ folder and reinstalled from scratch the GameData/MechJeb2/Plugins/PluginData/MechJeb2 is where all the settings are -- just save and restore that however you like. confirmed in 1.3.1, but i saw this way too late to start worrying about fixing it tonight.

That really sounds like the old bug. Make absolutely certain that you've upgraded and that you only have one MechJeb.dll in your GameData and that the folder layout looks correct.

In the "Attitude Adjustment" make sure you have "Hybrid Controller" selected, and set "MaxStoppingTime" to 10. If you then start to notice that when docking, etc using RCS that it uses piles and piles of monoprop you'll need to set it back down to 2. Difficult to autotune that one based on whatever anyone might be doing with any rocket, so you need to manually tweak that sometimes. Just tried this with the "classic" ascent targeting the moon, and went through that exact process and it warped fine.

In addition to sarbian, he still owns it. I just have commit bits. I'm now leaning towards this being correct behavior to set the flightinputhandler, so I think I'll probably patch it in MJ as well.

That is rather timely and interesting: https://github.com/MuMech/MechJeb2/pull/1143/files#diff-28fc7ff970f6cb096f1480f425495c5bR562 So if you take build #871: https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/871/ Then go into the Settings menu and tick "Module disabling does not kill throttle (RSS/RO)" to being set, does that fix the issue? I was tempted to not gate that behind the rssMode check at all, but didn't know what affect it would have on "stock" behavior.

The latest build from here: https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/ which is as of right now is: https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/869/artifact/MechJeb2-2.8.2.0-869.zip

The mainline MJ and MJ-dev builds are all 1.4/1.5/1.6 there were no codechanges and no symbols changed. Same dll works across all of them. And autohotstaging has been added to PVG.

You keep saying "peg" which may be a large chunk of your problem. The current builds for 1.4/1.5/1.6 and my 1.3 backports are all PVG or "Primer Vector Guidance" And if you're using "Atlas-Centaur PEG" (which isn't even really PEG) and not "Shuttle PEG" that is hopelessly old and I've forgotten all the bugs in it. I rewrote it all twice since then.

https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/868/ that should fix ion drives. and if the delta-V display is not working then the burntime estimation of the node executor will not function -- so fixing the delta v display should fix node execution. also note though that modelling an ion burn as an impulsive burn is pretty inaccurate no matter what. one day i hope to have a PVG-driven node executor that can do those kinds of burns accurately (although i can't help with how boring they are). for now though it won't be accurate and it'll waste a lot of ∆v (particularly compared to the infinite-thrust maneuver node calculation which will be hilariously off).

If you're stuck on 1.3.1 due to RSS/RO/RP-1 you should also be using the MJ-dev backports: https://github.com/lamont-granquist/PrimerVectorMechJeb/releases Otherwise I doubt anyone is going to be able to help you debug the 2.7.0.0 version -- I can't even recall what that code looked like any more.

Yeah, if you check out the approach I used to fix scripted ascents that should actually be more stable -- it should be as stable as the existing saving of .cfg file information to disk. I think I might need some more defensive coding if options go away though since I think it might throw. That approach should also probably be extended to every single other scripting module, but that'll likely entail breaking everything again. It also wasn't made any better by the fact that I was hacking stuff up and kind of feeling my way around the MJ codebase when I was refactoring the ascent autopilot and I made some very questionable choices about which classes to hang state off of... Now I sort of understand how it was supposed to be a Model/View/Controller kind of split up of tasks. Anyway, I've got a pile of launch-to-plane work in the pipeline right now that I've been working on for the past week or two, I'll probably add fixing the scripting autopilot to the list...

Poor initial design. To be fair the initial design only targeted how mechjeb was when it was written. Now that the ascent functions have changed it is painfully obvious how brittle the initial scripting code was. That got fixed to make it more extensible and more stable later, but it isn't completed yet. And fixing it all, correctly, is difficult. The whole scripting system should really be marked "experimental" since it needs some work.

should be fixed in 865: https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/865/

Known issue: https://github.com/MuMech/MechJeb2/issues/1105 I fixed a pile of issues with the scripting autopilot's ascent guidance but I broke that feature. I think it always used to be relative to ASL which I changed for the manual setting here: https://github.com/MuMech/MechJeb2/pull/1101 Probably another case of using altitudeASL or its equivalent somewhere in the path editor.

For reference this is what needs to be done with landing guidance: https://github.com/MuMech/MechJeb2/issues/1052 If you look at that issue, all of the referenced closed PRs are not "fixed" but they're closed because keeping 50 open issues against landing guidance doesn't help anyone solve problems, those are still all valid bugs against landing guidance. So the TL;DR there is that its amazing that it works as well as it does given all the bugs that have been reported against it. Some of the feature requests for it are also quick to dash off as a request and require graduate-level math to solve. And I very much want to solve all the problems with it. So I'd like to be able to hoverslam in an atmosphere with unthrottleable TWR > 1.0 engines accurately on the nearest flat surface with a fuel-optimal descent => tons of graduate level math. Same with solving the problem of optimal boostback and required fuel. Because ultimately I too want to accurately simulate a Falcon 9 Heavy with MJ.

I would not even attempt to use Landing Guidance in MechJeb right now for boostback and landing, there are too many bugs. You must learn to script using kOS/kRPC.