appenz

Understood. Still, if you post it we can have a look. Otherwise it's super hard to debug this.

@AsteroH This looks to me like either the file is not even a text file or it is empty. If you post it somewhere, we can take a look.

I believe anything you log in the console appears in the KSP.log file. See here: https://kontrolsystem2.readthedocs.io/en/latest/reference/core/logging.html There is no persistent storage for Kontrolsystem2, if that is what you are looking for.

Are you comfortable with (simple) coding? If yes, python is very good at this. For example: https://www.geeksforgeeks.org/convert-json-to-csv-in-python/ As JSON is a more complex structure, there is no 1:1 conversion. You will have to parse through the tree and generate what you want.

It looks like the scripts that are part of the Kontrolsystem2 install are there, but your can't add them, correct? If yes, my guess is that this might be a path or permission issue. Can you: Post full stdLib and localLib paths? Check permissions on the localLib path Try saving the script with a name not containing a space. Not sure if or what escaping is needed. What happens if you add a script to the stdLib path, does that show up correctly?

Spelling is hard.

I just posted an updated version of my Kontrolsystem 2 libraries and missions. Key updates Fully automated scripts to autonomously fly to and land on Mun and Minimus Fully automated return from Mun. Should work for Minimus too, but not tested yet. For transfers, it does a two stage burn making it very precise and efficient Correction burn uses the new maneuver node functionality to optimize the encounter Updated debugging information More reliable warp code Tested with Kontrolsystem 0.5.2.4. Code on GitHub here: https://github.com/appenz/kerbal2 Release (zip file) here: https://github.com/appenz/kerbal2/releases/tag/v0.2.0

Misspell was unintentional (and is fixed in my internal repo). The problem with Minimus is my current ejection burn calculation isn't precise enough for cases where there is staging during the ejection burn. I have code that adds a second burn to fine tune the trajectory (which is what you need to get to other planets anyways), but it's not quite working yet.

You can edit this in the file maneuver_vacuum.to2 (link here) in line 244. Code is this: // Need code here to orient vessel first while( current_time() < node.time - 15 ) { <-- Edit this number! warp_to(node.time - 10) // <-- Edit this number! sleep(1) wait_until(fn() -> current_rate() < 1.5) } This is the time it waits in seconds. Just make both numbers something big and the first one slightly bigger (e.g. 65 and 60). I added an enhancement request for my code on GitHub, you can track it here. It shouldn't be hard to add code that actually detects if the ship is fully turned. BTW @Untoldwind fixed the global_position() and global_velocity() issues and I am working on much more precise transfer code.

@DimiBD Small update: Untoldwind fixed the global_position() bug in 5.2.4 which is awesome! But a new bug for global_velocity() is now blocking as it prevents me from correcting inclination. Fix appears to be planned for the next release.

So I tried this today, and I can't burn maneuver nodes with enough precision to reliably get an encounter with Minimus with a single burn. I tried adding a correction burn using the new maneuver node functionality in Kontrolsyste, 0.5.2 but ran into bugs. I can't reliably calculate the distance to a bod that I am not orbiting (e.g. Minimus). In theory this should be easy with global_position() from Orbit, but it looks like global_position() isn't working as intended right now (or I don't understand it). I filed a bug and will take another look once I hear back.

Thanks for testing. It seems like something is off with the MN calculation. Doesn't matter for easy transfers like Mun, but causes it to fail for Minmums. I'll take a closer look.

@DimiBD I think I fixed it, at least for a Mun transfer it works again. There were basically two issues: Bugs in how I calculate the transfer altitude (i.e. the highest point of the new orbit that should be inside the Sphere of influence of the target body. My maneuver node burn isn't nearly as precise as I want it to be. I fixed (1) but (2) may still be an issue if you have a craft that stages during the transfer burn. The planTransfer() function no directly takes a target altitude. I would set it to something that's high, but not close to the SOI. So maybe 10% of the SOI is safe. Let me know if this gets you to Minimums. I didn't test that I know this is a bit late, but I code for this here on GitHub. The basic idea is: Check if we are landed at KSP, if yes fly up 2,000m Land on one of the landing pads Basic logic of the code is that it constantly calculates the dV between the desired trajectory and the actual one and tries to correct it. While we are well ahead of time when we'd have to start a suicide burn it corrects only horizontally. As it gets close to the suicide burn time we add vertical breaking. Works for a decent variety of vessels for me.

Alright, I'll try to fix this week. Tracking it as a bug on GitHub here.

I am also seeing the interplanetary transfer coming up short. In the past this was necessary in order to not overshoot, but it looks like something changed. There is a parameter to adjust this, so it should be easy to fix. In the file go-mun.to2, change the parameter from 0.6 to something bigger. See the t.planTransfer() line below: // We made it to Orbit, are we still around Kerbin if (vessel.orbit.reference_body.name == "Kerbin" && vessel.orbit.apoapsis.defined && vessel.orbit.apoapsis.value < 5000000) { const t = Transfer() t.planTransfer(mission,"Mun", 0.6) // <-- Edit this parameter const n = t.getTransferNode() mission.addManeuver(n) mission.burnNextNode() con.log(" ejection burn complete.") } Now @Untoldwind just dropped code that can gives access to the trajectory after the maneuver node (see here). Haven't tried it out yet, but this should allow us to do a gradient-descent type calculation for the entire trajectory. That will be much more reliable. Yes, I found this out the hard way as well.

Awesome! Was it an intentional crash, or did the landing algorithm not brake correctly? If it was an unintentional crash I'd love to know to craft so I can debug. It's really hard to write code that works with any space craft.

I fixed the exponentiation notation issue in my repo as well. Latest code on GitHub here. This is tested against 0.2.0.0 and seems to work mostly fine up to geting into orbit with all vessels that I tested. The transfer burn to Mun seems to need some tweaking for some ships. Thanks to @AndyMt for pointing this out and awesome to see that anyone is actually trying out this code. I haven't tried out Andy's new gravity turn code yet, but it looks super promising.

I wrote a KontrolSystem2 script for a fully automated mission to the Mun and back to Kerbin. Details: Requires a rocket with enough delta V for the trip Gravity turn isn't optimal, but works pretty well for most craft Methods to circularize and adjust inclination Transfer planning within the Kerbin system Breaking for orbital capture around the Mun Landing on the Mun is at a pretty steep angle, and could be more efficient It always uses a specific landing spot that is a flat area and usually lands with < 1m accuracy Takeoff from the Mun, circularize and fairly optimal ejection burn Uses aerocapture, if necessary with multiple orbits Checks parachutes for safe opening The script uses none of the higher-level TO2 functions, it was more fun to re-implement everything myself. Coding style is a bit different from Untoldwind's. I try to be as object oriented as possible and when in doubt err on the side of readability of code, so expect code to be a lot less compact. Source code on GitHub here: https://github.com/appenz/kerbal2 Critique, Enhancement, Pull-requests or any other Feedback is highly welcome.

Recently jumped back into writing code with Kontrolsystem2 and re-tested to previous bugs: The "stuck on rebooting" issue is fixed in 0.4.3. The "invalid stack" seems to have disappeared. I now have a fully automated Mun mission including the return to Kerbin with aerocapture working. Great work, thank you!

100% agreed that this is an issue. I am calculating and burning nodes with KontrolSystem 2 and for many maneuvers I have to split them into multiple burns because the precision of a single burn is just terrible. KS1 was vastly better.

Welcome!

Have you looked at KontrolSystem 2? It's a mod that includes a type safe language that allows you to do simple scripts or write more elaborate programs to execute complex maneuvers. It's still a little buggy, but for simple things should work well.

If you are an armchair astrophysicist, have a look at KontrolSystem2. With it, you can do even more math (calculate the orbital maneuvers) and it feels a lot more like real rocket science.

Hi Untoldwind, First, amazing work with the plugin. It's awesome to have a programmable framework for KSP2. It's when it runs it is very stable and I have a fully automated launch to low Mun orbit working. That said, at this point I am a little stuck. My main issue is that more and more frequently KS2 gets stuck on rebooting. The "Rebooting" button is greyed out, no entry points, no errors, indicator light is green. Game works normally, but KS2 can't be used. Restarting KSP2 used to reliably fix the issue. But I now have a 50% chance to land in this frozen state when I start the game and it usually happens again after a few minutes. It's not main memory, I have about 20GB available. Is there any way to root-cause what is causing the reboot to freeze (short of a C# debugger)? My second issue is that sometimes I get very opaque compiler errors. The error message is something like "invalid stack", with no file or line number given. Any guidance on how to debug those? Codebase is on GitHub here if it helps. Current checkin (9b26c6f) will *NOT* boot successfully, but it does trigger freeze bug. https://github.com/appenz/kerbal2 And again thanks for making this great mod! Guido