Jump to content

Jim DiGriz

Members
  • Posts

    429
  • Joined

  • Last visited

Reputation

181 Excellent

2 Followers

Profile Information

  • About me
    Spacecraft Engineer
  • Location
    Seattle, WA
  • Interests
    Cave Diving

Recent Profile Visitors

4,482 profile views
  1. 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.
  2. Wrote a rust crate for a CLI tool which could help with stripping parts, modules and resources: https://crates.io/crates/kspconfigtool
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. This is hard, I've been working on trying to make it better for months. Circular parking orbits are going to be more successful.
  14. 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.
×
×
  • Create New...