Jim DiGriz

PEG assumes a flat linear gravity model and then tries to correct for that, which works for Earth, but Kerbin is made of some substance that is 1,000x denser than Earth so that a 600km ball has a gravity of 1g, which means that space is more curved, which means PEG doesn't work as well. Plus the delta-V requirements to orbit are lower while the high-TWR rockets that people build will cause burntimes to hit that delta-V to be much lower which mandates a coast, and the coast needs to be placed somewhat optimally. At some point I want to wrap PVG with a SQP solver that marries a zero-lift gravity turn with PVG on the "top" for insertion into the orbit, along with supporting a single optimal stage at an arbitrary time (rather than just at stage jettison) which would solve a lot of these problems.

Wrote a rust crate for a CLI tool which could help with stripping parts, modules and resources: https://crates.io/crates/kspconfigtool

Real Scale Boosters installation instructions on top of RP-1 Express install for 1.12.3: 1. ROEngines hides all the RSB engine parts. To fix this it is easiest to remove the GameData/ROEngines/PatchManager folder entirely. Or else manually use the PatchManager menu in the space center. 2. The NoNonRP0 hiding of parts is forced active by default now, to revert that edit the GameData/RP-1-ExpressInstall/RP-1Express.cfg file and remove the bottom two sections that mention "HardRemove". 3. There is a conflict with Restock and the RSBstrutXL part which reuses the stock strut model which Restock "deletes" from KSPs knowledge. I copied the file from GameData/Squad/Parts/CompoundParts/strutConnector/model.mu to GameData/RealScaleBoosters/Parts/Etc/RSBstrutXL.mu and pointed the RSBstructCL.cfg in that directory to the new location. 4. You need to run through all the stock craft files and delete all the LiquidFuel, Oxidizer and Monopropellant. This is the traditional problem with the RO configs not removing the old stock resources from stock craft for whatever reason. 5. There's a problem with the Delta IV Heavy and MechJeb staging which is only fixed now on the -dev version of MJ because of the addition of Ablator to the RS68 config (but the dev version of MJ is as of this date unstable and buggy and PVG is much different). 6. You'll need to check the engine configs with the UI, and it looks like the rockets are slightly chonky and have too much dry mass and not enough propellant from what I can see so performance is slightly off from reality, it needs some tuning. 7. Some science experiment parts may be attached to a few of the rockets which RP-1 removes.

Using WASM is for solving the problem of those of us that want to use different languages like Rust/Ruby/Python/whatever rather than C# or Lua.

Yeah if MJ3 or whatever was an explicitly modular framework so that the autopilots were external to the core codebase -- allowing stuff like the rover/aircraft/landing/ascent/etc autopilots to be hosted "externally" and potentially managed by other developers that might be very interesting. Then the core parts of MJ would provide core math support, core support for data from VesselState, core support for computing maneuvers, along with attitude control , the stagecontroller, thrustcontroller and common UI elements. I can see obvious downsides to doing that as well as the internal API becomes public and breakages would require coordination, and some mods might have to be abandoned by the core API unless some LGG adopted them. At the same time it would allow customization of what MJ could do and the simplest plugin might only be data readouts without any autopilots. I don't know what the right answer is, but at the same time the scripting autopilot got kind of dumped into MJ and then rotted and never improved, and that seems wrong.

Yeah, that is a distinct possibility to have a generic WASM bridge to build mods on top of. I did about 10 minutes of looking around so far, I did find a few more attempts at it but wasmtime I think looked the most mature. Yeah doing something like PVG on kOS wouldn't work because its too slow for numerical methods like that. What I would suggest these days for a simple launcher would be to model an ascent with a fixed heading and pitchover maneuver following a zero-AoA gravity turn (so two parameters there) followed by a fixed transition (altitude or something like that) to a bilinear tangent law of the form A + B t where those are vectors that determine the heading vector which is just the unit vector in that direction (so 6 parameters plus a normalization constraint on the magnitude of the 6-vector [A B] being equal to 1), plus the end time of the ascent as a final parameter. Feed that into RKF45 or DOPRI45 and integrate that with a drag model and then feed the constraints on the terminal position into a nonlinear solver like the SQP method that alglib has now. That ascent won't be optimal in the mathematical sense, but it will be near optimal and should converge reasonably well without needing an overly precise guess, and the AoA constraint through the bulk of the atmosphere will nullify most of the highly nonlinear issues with the atmosphere. Doing full optimal control theory based ascents is probably the wrong approach and the mathematical approach in PVG absolutely fails to be able to deal with the atmosphere. I have some Matlab code where I finally managed to get an optimal control approach working, but it took me years and would require implementing finite differencing (like Matlab's bvp5c) in C#, which alglib doesn't have, and I don't know if there's any battle tested implementations out there. A better approach for a launcher using very modern algorithms would probably use Picard Iterations or PIPG with convex optimization -- which will be much less of a mathematical dead-end: https://www.sciencedirect.com/science/article/abs/pii/S1270963821007446 https://arc.aiaa.org/doi/10.2514/6.2022-0951 https://arc.aiaa.org/doi/abs/10.2514/1.A35194 That should lead you down the road of dealing with direct optimization and ~1,000x1,000 sparse matricies though. But I think alglib now has a sparse convex QP solver that would be appropriate. This might be straying off topic, but its definitely difficult to jam experimental stuff like this into MJ right now.

Yeah that's what I'd like to do, but I'm not interested in making it "gamey" at all. I would definitely encourage you to produce that, since I'm more interested in focusing on just making it easier to do optimization and control theory, which is hard enough, and intend it to maximally embrace whatever 'cheats' users would like to write.

I'm somewhat unconvinced that MJ is the right way to go. It attempts to do everything and does most of it badly. The work I've done (nearly merged now) on extracting a lot of the code that I wrote into a more permissively licensed library IS really geared towards letting people copy battle tested code out of MJ and build mods. There's obviously a high level of demand for KSP2 mods that do what MJ does for KSP1. My thoughts though are that I'd rather build something so that WASM code built in other languages could run against KSP2 (kind of kRPC without the socket communication) along with a set of library code (lambert solvers, PIDs, optimization algorithms from alglib, etc) could be available to that framework "free of charge" along with sane right-handed vector/matrix/quaternion objects. Then I'd like to build a much better transfer planner/flyby finder/maneuver editor/executor, but focusing on expert use cases rather than novice. Other people could build MJ-like simple launchers on top of that (in languages other than C#). But I don't even own KSP2 right now and I'm in watch and wait mode. And if Sarbs tries to build MJ for KSP2 then I might jump in and help since I certainly would want to see it not fail.

Not possible to turn off MM loading via the MJ settings due to temporal causality in this universe. You can create an empty MechJebUseCommandPod directory in GameData and it should turn off.

Note that this feature in MechJeb still requires ModuleManager to also be installed, but it isn't a dependency of MechJeb. So if it doesn't seem to be working make sure MM is installed as well. Also as noted in that commit even with the magic MechJebUnlocked folder some features require upgrades to get maneuver nodes.

What API do you have to hit to cause it to display? I tried hammering on `dialog.gameObject.SetActive(true)` in Update() and the window still goes away on an ESC.

You have PVG selected but you have "Fine tuning apoapsis" as a status, which is a fixed months-old translation bug which indicates your MJ is out of date. A lot of those argument exception errors should have been fixed by patches to improve handling of crazy transient staging issues which went in after that bug was fixed.

This is hard, I've been working on trying to make it better for months. Circular parking orbits are going to be more successful.

If you switch the ascent autopilot from "Classic" to "Gravity Turn" style you more or less get this kind of ascent. It'll do the intermediate altitude stuff, but I'd recommend just setting your intermediate altitude to your target altitude and doing a 2-burn ascent. It doesn't support any sort of auto-tuning though or doing any of the pitching up at the intermediate altitude to deal with low TWR engines, but it is very simple and effective for what it does. Since it flies strictly zero-AoA it can help with flippy rockets and bad aerodynamics.

@Tonka Crash try #985 and see if that restores diff throttle.

Rendezvous Autopilot fixed by https://github.com/MuMech/MechJeb2/pull/1288 which is available https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/970/ by an external code contribution!

You don't launch to a planet's plane to do interplanetary. Launch to the Mun's plane (plane of the ecliptic) and go from there. Actual launch optimization for interplanetary trips is a mildly horrendous optimization problem and has never been implemented in the KSP universe. It also just does not matter as much as anyone think it does. LAN would also be more important than inclination or plane for being able to do the correct b-plane targeting (you can efficiently eject from the system from a 90 degree inclination orbit provided that your LAN is correct so you do not require a plane change to meet the v_inf).

Engine(s) / Engine(s) / Decoupler Exactly what it has to be.

Launch to Plane should be fixed in #955: https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/955/

Yep, Yep and Yep. The circularization burn is almost a stupid trick, it needs a lot of work done to the Node Executor to make burn precision that precise. And yeah, targeting the inclination and eccentricity could be done, that's just more math. And yeah, the actual porkchop interface is still not satisfying in numerous ways.... Also everyone an overhaul to the launch-to-plane math just landed. If you see anything wonky please report it. It sort of escaped into the dev builds without sufficient testing (I've gotten distracted with a bit of a minor family emergency). Make sure the field next to the launch to plane button is zero though, if its not your plane will always be off by that many degrees (kinda looking at nuking that or more aggressively forcing it to zero to eliminate bug reports due to that field).

Yeah I'm very dissatisfied with that as well, but UX and adding more buttons is almost harder than math to get right though since if you move things around people get confused. Its also very cramped and squishy in the maneuver planner box (and look at everyone complaining about the size of ascent guidance on tiny screens before suggesting making it bigger). But yeah, it needs to be better somehow.

Yeup that's the bug I need to fix.

Yeah think you replicated the problem I was seeing, look in the logs for that "zero miss phase" and "periapsis phase" and look for the dv values jumping around a lot. They shouldn't. They almost certainly are. Gotta lock down the optimizer more. And the psychedelic porkchop may be accurate, I just can't visualize it very well in my head. It does seem weird because you shouldn't be able to see individual orbits on that, and the porkchop omits interactions with minmus and the mun (and the jool moons) so nothing else should really be changing that much. Some of the weird stabbity bits of the porkchop plots I can't quite visualize what is going on there either though and those artifacts show up in professional publications.

I think you should be able to play with it and it'll work if you don't try anything too crazy. If you do find it does weird stuff on non-crazy things that would actually be useful to know about.

Meanwhile https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/948/ should hopefully fix the transfer planner. I'm at least able to replicate alex moon's numbers now from circular nearly-coplanar equatorial orbits to ejection. The porkchop numbers are still high by a few dV which I have a few things I want to try to fix those. EDIT: Well I already found one more bug. If you see it sometimes places a maneuver node which is wildly higher dV than the porkchop prediction that is now known: [LOG 22:27:51.687] zero miss phase before optimization = 14996932537.2083 m (763.306944838952 m/s) [LOG 22:27:52.041] zero miss phase after optimization = 64372.1103050466 m (1153.38572748793 m/s) [LOG 22:27:52.043] periapsis phase before optimization = -315746.987141928 m (1153.38572748793 m/s) [LOG 22:27:52.092] periapsis phase after optimization = -11.7580441570608 m (1153.40341200134 m/s) The m/s values should not be jumping highly like that. That is from a 90 degree inclination, 0.80 eccentricity parking orbit, though, so hopefully most users don't hit that. Probably know what the fix is for that one as well, but it'll take another few days.