Jim DiGriz

@PART[*]:HAS[@MODULE[ModuleCommand]]:Final whatever MM config you are using should have a line somewhat like that, but if it is missing the "Final" bit you need to add that.

Yeah now that I'm a bit more awake I see that is way early in the Init section of F*** F*** S******** which is not stuff I touched.

That smells like my fault. I probably missed something here: https://github.com/MuMech/MechJeb2/pull/1077 I'll need a lot more coffee to figure out what...

They're more useful for the other guidance settings like GravityTurn and PVG. You should still be getting more screen real estate back on classic because a lot of the e.g. "show navball guidance" clutter has been compressed. I'm still thinking about how to manage that whole mess, but PVG really needs the ability to make the options go away to focus on the essential stuff.

No.

Yeah looks like the cfg file isn't making it through jenkins to the zip file. I have to do some spelunking. EDIT: build 837 should fix it.

That has nothing to do with MechJeb

Try removing your module manager cache files.

I was trying to make a method which would "clone" an existing Orbit object into a new Orbit object (as a starting point to be mutated), and looking at the KSP API there are 3 approaches to this, but only 1 of which I was successful with. This is what worked, using "new Orbit()" followed by "UpdateFromStateVectors()". For some reason this failed when I tried setting UT to "o.epoch" which I don't understand. So this method defaults to the current tick and if that isn't valid then its up to the caller to sort it out: // returns a new orbit that is identical to the current one (although the epoch will change) // (i tried many different APIs in the orbit class, but the GetOrbitalStateVectors/UpdateFromStateVectors route was the only one that worked) public static Orbit Clone(this Orbit o, double UT = Double.NegativeInfinity) { Vector3d pos, vel; // hack up a dynamic default value to the current time if ( UT == Double.NegativeInfinity ) UT = Planetarium.GetUniversalTime(); Orbit newOrbit = new Orbit(); o.GetOrbitalStateVectorsAtUT(UT, out pos, out vel); newOrbit.UpdateFromStateVectors(pos, vel, o.referenceBody, UT); return newOrbit; } What failed was going in through the constructor that takes another Orbit object `Orbit new_orbit = new Orbit(o)` and going in through the constructor which takes keplerian elements `new Orbit(inc, e, sma, lan, argPe, maAtEpoch, epoch, body)`. What I found is that I'd get a new Orbit that had the wrong true anomaly, and while it had the correct LAN, ArgPe and inclination (and SMA/ecc) the h vector was rotated and incorrect -- which seems internally inconsistent. I beat my head against this problem for about 4.5 hours before just using the UpdateFromStateVectors() approach above. What I'd kind of like to know is how the constructors are meant to be used and if there needs to be some other call made to initialize or update the object to make it internally consistent or some other undocumented voodoo that I'm missing?

buggy bi-impulsive / hohmann transfers i'm working on right now. (should be fixed in latest dev release last night, although i think the simulated annealing code in the non-simple-coplanar solver still needs mathematical debugging -- but the periodOffset code that was buggy in both implementations is now fixed so the simple solver should be back to old behavior now)

Build 831 now includes "MechJebForAll" style functionality by default. To override it and go back to *having* to use the mechjeb command pod, create the empty directory GameData/MechJebUseCommandPod https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/831/ (It also disables itself if RealismOverhaul/RP-0 are found in the install) https://github.com/MuMech/MechJeb2/pull/1087 You'll need to have ModuleManager to have it work, and I think MM now needs to be added as a dep of MechJeb in CKAN.

Hint: "Some modules are disabled until you unlock the proper node in the R&D tree or upgrade the tracking station"

That isn't a MJ feature, that is stock.

That sounds more like you've run out of eC or something like that. Unless by SAS you mean MJ's Smart A.S.S or something, in which case you should be more explicit about exactly what you are doing.

dev build #830 should apply to KSP 1.4/1.5/1.6 without complaining about compatibility. it looks like 1.6 required no code changes.

tick "simple coplanar Hohmann transfer" and make sure you have dev build >= 824.

Hohmann transfers now have a "period offset" option for doing that, set it to +/- 0.25 or whatever.

If you have a rocket with large fins and your initial pitchover is too great (or your TWR is too low) then the fins act as AoA limiters (or you may have the AoA limiter checked), in which case you execute a way too aggressive gravity turn and you wind up with a ballistic missile instead of an orbital rocket. That is largely just aerodynamics and rocket design, though, not a bug.

In the main menu, open the "Attitude Adjustment" menu and "HybridController" is right at the top

It is back up since yesterday. (and no, if it goes down, builds go offline, would have to manually build them and upload somewhere)

jenkins is back. build #822 also just landed. this has fixes for what I call "pid wiggles" which turned out to be every 10 degrees the attitude of ship changed the PID controller would get reset which would cause transient wiggles with the hybrid and kos controllers. it also has fixes for the delta-v stats for parts with multiple moduleengines (ie. engines with integrated verniers), fixes for non-ISP fuels (HTP), and fixes for something (RealismOverhaul?) leaving random bits of unburned propellant behind in ullage stages confusing MJ as to if the engine could be lit or not. in particular if i screwed something up with the dV stats i could use knowing about it. it is very delicate and complicated code in there (best of luck with 1.6 squad...)

jenkins dead, gotta wait for @sarbian to fix.

After looking at the code, I'd actually suggest everyone use the HybridController with a max stopping time of 2, and I'm reasonable certain it is all around better than the kOS controller and fixes at least one known bug with the kOS controller. Would love to know if I'm incorrect and there's some benefit to the kOS controller that isn't just a difference in the settings.

Okay build 820 is available that all it does is drop the hybrid controller's max stopping time default down to 2 from 10. That should cause the hybrid controller to match the kos controller in terms of how much RCS gets used, and how fast vessels rotate. I think that should make the HybridController the better PID now. Also just like that there's a build 821 which sets the default controller to the hybrid controller. I don't think that affects anyone's existing config (whatever you've set it to manually will overwrite the defaults) but it should hopefully suppress the need to every other page tell some new user to use the hybrid controller. Actually that makes it somewhat difficult for anyone to test these changes, your configs won't get modified at all... So I guess carry on...

For all of you having issues with rocket wobble who are *fixed* by going to the HybridController -- what happens if the MaxStoppingTime is dropped down to 2 or 1 or 0.5 during launch? Do the wobbles come back? If the wobbles don't come back, does the HybridController get better at executing nodes in orbit without wasting piles of RCS?