Arrowstar

No worries! It's probably some weird visualization thing. Next time it happens please check the ksptot.log file and see if there's anything in there you can share with me. Btw, PR6 has been updated again with fixes for the two bugs that were reported yesterday.

I couldn't reproduce the bug you showed. Does this happen consistently? Did you change anything in your LVD or KSPTOT settings that might impact this? Are you using RSS like gravity or something else? RSS-like gravity uses the sum of the parent's gravitational parameter and the current body's gravitational parameter to compute the effective gravitational parameter of the parent body. I would just stick with KSP-like gravitational parameters unless you know what you're doing, it can be a little unintuitive otherwise..

I believe both of these bugs are fixed. I will upload a new version of PR6 tomorrow. Thanks for the reports!

Thanks for the report, I've fixed the bug. About 5 minutes after this post you can re-download PR6 to get the fixed version.

This bug should be fixed in the re-upload of PR6 that I recreated tonight. Can you check it out and tell me if it worked? Sorry it took 10 months to stumble into a fix...

Thanks!

Hi everyone, The other day the latest release of MATLAB, R2022a, was released. I've been trialing it and I see that I'm actually getting a pretty decent speed boost in LVD, perhaps as much as 10% faster when running cases. Could I get some help in evaluating if this is more than just something I see? Here's what I need some folks to do in order to help: Download and install the R2022a MCR package. Download the latest (R2021a) pre-release. Download the same pre-release but for R2022a. Run the KSPTOT executable in the R2021a PR: Open up LVD. Open the LVD MAT file contained in the R2022a pre-release. Tap control-p 10 times in order to run the script. Wait for th script to finish running between each tap. Copy the output window text. You should see a bunch of lines with data concerning how long the script execution took. Now run the KSPTOT exectuable from the R2022a pre-release and repeat the process for this new executable (open LVD, load the MAT file, run the script 10x, etc). In this thread, please copy/paste the two outputs and also provide your CPU and how much RAM you have. Please let me know if you have any questions. Thanks, everyone!

I'm glad it's working for you! Please let me know if you have any other questions.

How many times did you try to run the optimizer? The genetic algorithm underpinning things is semi-random and it's not unusual to see different results from run to run.

You're welcome.

It's pretty straight forward! Just load the bodies.ini file with your planets in it, open up the Multi-flyby Maneuver Sequencer, and set it up like this: The big thing is to make sure the Earth to Earth segment has a max number of revolutions greater than 0. Here I used 2. Tap the "Compute" button and away you go. Let me know if you have any other questions.

Glad to hear it! I updated KSPTOT v1.6.9 pre-release 6 with a fix for your Mission Architect bug. Could you try it out and let me know if that resolves your issue? Thanks!

Select the event you want to edit so it's highlighted. Then right click the name of the event you want to edit. A pop up menu should appear and its first entry will be "Edit Event". As an example:

I'm working the bug you mentioned in MA now and I'll put out an update pre-release soon (probably tomorrow at this rate) with a fix. As for LVD, please see my last post.

Hey, this is a known issue with the App Designer GUI environment at the moment. To edit an event that doesn't seem to be working, right click the list of events and select Edit Event in red. Sorry about the confusion.

There really isn't, sadly. In LVD it'll either be the body named Kerbin or the first body in the list. Otherwise, in some other places it could be the first body in the list or the third body in the list (Kerbin is the third in the default list). Sorry for the inconsistency here, I wrote all this code over the course of 8 years so sometimes things aren't always as they should be.

This is done for the next release.

Assuming you're talking about using MFMS, I think I've got something that might work for you. Today I built KSPTOT v1.6.9 pre-release 6. This new PR contains an update for MFMS that allows you to set a max delta-v limit on flyby maneuvers. You'll see it in the space with the flight time bounds and all that. If you set a delta-v limit to roughly zero (say 0.001 km/s), that'll hopefully allow you to solve your problem without breaking the optimizer too much. Can you try this out and see if it helps? By the way, everyone, a few things: Sorry I haven't been around much. Honestly there hasn't been much to do with KSPTOT lately (can't think of anything to add and haven't been made aware of any new bugs lol) and I've been digging into and learning more about reinforcement learning. Perhaps one day I'll be able to incorporate some machine learning into KSPTOT, but for the moment it's remaining just a personal interest. I had to go to building the Windows version of KSPTOT on a Win10 virtual machine to get around issues I was having building on my Windows 7 installation. I'm not sure if it's a code thing or if it's just that my PC is 9 years old (or some combination of all of the above). One day I'll hopefully get new hardware, but that day is going to come only when PC component prices drop. Anyway, happy orbiting!

Unfortunately it is not, unless you begin using a faster CPU. I could look into those changes. Thanks for bringing them to my attention! Sure! You'll need the parallel computing toolbox, optimization toolbox, global optimization toolbox, instrument control toolbox, and robotics toolbox. Those are the ones I can think of off the top of my head. I can check later (might be next week) to find out for sure. Sorry for the super late replies everyone, apparently my setting to follow this thread got turned off at some point and I didn't notice it. I've re-enabled it for the future.

KSPTOT author here. Thanks for the shoutout! Yes, KSPTOT can handle RSS solar systems if you feed it the celestial body information it needs to understand the RSS solar system. After that, it's just a matter of designing your tour using the Multi-flyby Maneuver Sequencer tool. Let me know if you have any questions, OP. You can post them over on the KSPTOT forum thread.

Is anyone aware of either (1) any bugs in any of the previous pre-releases I've put out, or (2) any features that they might need but are otherwise not already in KSPTOT (particularly but not limited to LVD)?

Hey there! Check out my KSP Trajectory Optimization Tool for use in generating porkchop plots. You can generate the file describing the OMP solar system easily from within KSPTOT, as well, and everything should "just work" at that point. Let me know if you have any questions!

Hi everyone, Tonight I've built KSPTOT v1.5.9 pre-release 5. There are a lot of nice usability improvements and bug fixes in this one. Here's the change log: LVD: Added a camera controls UI to the View menu. Use this to pan, zoom, and rotate your camera view more effectively. LVD: Added the options dialog for the Second Order propagator. LVD: Tooltip for the warning/error labels is custom and now shows the proper width so everything that is meant to be on one line is actually on one line. Fixed bug in main UI options dialog. LVD: The tool tip string on the time slider text now shows the proper events. A few performance improvements. Please let me know if you find any bugs! Thanks and happy orbiting!

I probably duplicated them accidentally when I was creating the tutorial for you. Delete the duplicated constraints, they are not necessary. This is actually coming soon in the next pre-release. I just haven't had time to get the PR pushed out, but yes, I know that it would be nice! Ahhh, this feature I described might actually not have made it into the last pre-release either. Okay, that would be my mistake if that's true. Well anyway, I'm glad you figured out how to add the constraint scale factors in there! Yes, that's what I meant. Thanks for figuring it out! It was getting late by the end of my tutorial and I missed that step. Thanks! I'm glad everything is working as it should now. Please let me know if you have any more questions!

It's a guess. For an orbit to be hyperbolic (which it will be coming from outside the SoI), C3 must be strictly greater than 1. That's why I set the bounds on C3 to 1.001 and 20. Most hyperbolic C3 values show up in the single digit range so 20 is a safe guess for an upper bound. The actual value of 5.0 km^2/s^2 is just a guess that the optimizer will change as needed. The transfer duration for this trajectory is about 250 Earth days. Half of that is 125 Earth days, or 10800000 seconds. The bounds are just half of that and double that value, for lower and upper bounds respectively. I selected these bounds somewhat arbitrarily and they're also just mostly a guess. Good questions! Let me know if you have more.