[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.9 [New MATLAB Version!]

[Arrowstar]

Great! Please let me know soonish, as I'm hoping to get the release out tonight too

[Mr Shifty]

Great! Please let me know soonish, as I'm hoping to get the release out tonight too

They'll probably have to wait until after release. Play time is hard to come by for me.

[Arrowstar]

They'll probably have to wait until after release. Play time is hard to come by for me.

Okay, sounds good. Please feel free to review the latest version at your leisure.

---

Speaking of which, I'm happy to announce the release of KSP Trajectory Optimization Tool v1.1.0! Here's the major items out of the change log:

• New Application: Flyby Porkchop Plotter. Generates a delta-v contour map for an arbitrary flyby mission sequencer in a similar manner to that of the porkchop plot featured on main GUI. Inspired by diomedea, this application is great for getting the big picture and finding flybys through a more "brute-force" technique.
  
• Updates to the Multi-Flyby Maneuver Sequencer:
  
  • Now accepts a minimum of two waypoints (previously, three) and computes the optimal ballastic trajectory between them. This is basically a way to find optimal, no flyby trajectories using a genetic algorithm.
    
  • GUI now allows users to specify bound on flight time for each waypoint leg. Previously only the launch window could be specified.
    
  • Bug fixes and some other minor tweaks to the underlying algorithm.
    

  [*]A new splash screen now appears when loading the application. Features a new KSP TOT logo inspired by the Voyager I and II missions.

  • Also fixed the issue where the main GUI would half load, displaying filler/placeholder information for a moment before loading the full GUI.
    

  [*]A new Help -> About menu in the main GUI with application development credits (more than just me, I swear! )

  [*]Fixed a regression in Mission Architect that made it hard to find SoI transitions in some cases.

The download is now up at the usual link in the first post. Please let me know what you think, and as always, please report any bugs you find or any suggestions for improvements you might have. As diomedea has demonstrated, I'm more than willing to take interesting or useful requests!

[pina_coladas]

Congrats on the release! This looks even more impressive now. It sounds like you've put a ton of work into the finnickly UI stuff and that is much appreciated.

[TeddyDD]

This program is one of the most amazing things I've ever seen on this forum. Thank you sir!

BTW. I followed the tutorial in pdf and my hypothetical orbit passed 100 kilometers below the surface of Vall xD

I still have lot to figure out in this program

[diomedea]

This program is one of the most amazing things I've ever seen on this forum. Thank you sir!

BTW. I followed the tutorial in pdf and my hypothetical orbit passed 100 kilometers below the surface of Vall xD

I still have lot to figure out in this program

Let me say, don't get discouraged by the steep learning curve with this tool. It takes more time than most other things to acquaint with, because of how complex it is; but once done, the satisfaction you get is much higher. I can hardly think of anything more complex to deal with in the KSP universe, and still so much realistic.

(Note: was the tutorial you followed about the Kerbin-Laythe transfer? Did that but didn't encounter Vall; instead arrived in the Jool system with a pretty high inclination, so to make any possible encounter with other moons very difficult. Did date/time and Delta-V components with the initial orbit match with the ones in the tutorial?)

[Arrowstar]

Congrats on the release! This looks even more impressive now. It sounds like you've put a ton of work into the finnickly UI stuff and that is much appreciated.

Thanks!

This program is one of the most amazing things I've ever seen on this forum. Thank you sir!

BTW. I followed the tutorial in pdf and my hypothetical orbit passed 100 kilometers below the surface of Vall xD

I still have lot to figure out in this program

Thanks! And yes, that can happen sometimes. Best way to avoid that is to set an altitude of periapsis constraint for each body you might encounter when heading into Jool's sytem. That should prevent any issues from cropping up.

Let me say, don't get discouraged by the steep learning curve with this tool. It takes more time than most other things to acquaint with, because of how complex it is; but once done, the satisfaction you get is much higher. I can hardly think of anything more complex to deal with in the KSP universe, and still so much realistic.

Thanks, diomedea! I'm really quite glad you enjoy using KSP TOT.

---

Just a quick heads up, folks. I found a bug or two yesterday in MFMS, so this is an announcement for KSP TOT v.1.1.1.

Change Log:

• Fixed a bug in Multi-Flyby Maneuver Sequencer such that the wrong burn true anomaly was being displayed at flyby periapses.
  
• Added the ability to import masses of the active spacecraft in KSP straight into Mission Architect by right-clicking the mass panel in the Insert State dialog box. Must have KSPTOTConnect plugin installed in KSP and KSP must be running in the flight scene for this to work.
  
• Added ability to tap Enter/Return on keyboard to save and close the Insert State/Coast/DV_Maneuver/Mass_Dump dialog boxes in Mission Architect.
  

The last two are things I've wanted to do for a while, particularly the importing of masses into MA from KSP! Happy it works now.

[diomedea]

I have a small issue with MFMS, using KSP TOT 1.1.0 but still present with 1.1.1. Can't tell for sure if has to be considered a bug (or another of my mistakes using this tool).

If the launch window is set to open later than Year 1, Day 1, solutions are found with departure beyond the Launch Window Close date. Example here:

Launch Window Close set at Year 4, Day 1 (UT=94608000); departure date from Kerbin Year 4, Day 233 (UT=114693128.714).

Arrowstar: I noticed this while trying to force MFMS to replicate the 7 body solution you showed on another thread (could not get that, and when imposing stricter limit to match your solution found this issue).

[Kobymaru]

Hi!

First off, that is an incredible tool that you created! It contains all the math that I was always lacking from KSP. I'm already looking forward to more planning and less trial-and-error

Using Version 1.1.1,

I have tried to use the Multi-Fly-By-Sequencer and have come across several issues.

- As mentioned above by diomedea, when entering an earliest and latest departure, I get a departure date way past the latest departure (latest departure is year 60, suggested departure is in year 99).

- How do I interpret these results? Do I have to burn at every single waypoint? Is there a way to calculate the trajectory without any burns (or at least minimal Burn amounts)?

- The total Delta-V in this case amounts to about 3 km/s to Eloo, but a direct transfer would be about 2.5 km/s. For me, that kind of defeats the purpose of the MFMS, if I want to figure out how to get to a Planet with the least delta-V. Which leads me to my next question:

- The tool can calculate the optimal trajectory for a given sequence of waypoints. But if I only want to know how to get to a planet as cheaply as possible, how do I know which waypoint sequene is the most effective?

[Kobymaru]

Sorry to spam this thread, but I came across another two issues:

- My current KSP time is Year 55, Day 366 but when I load it from KSP, I get Year 17, day 3 which is utime 504791832.807. Does that mean that the time is retrieved incorrectly, or do you use earth time instead of Kerbin time for calculations?

- Here is what I get when I try to compute a transfer from Kerbin to Eloo:

The porkchop plot starts at Year 1, Day 1 and gives a Departure + Arrival Delta-V:of about 16 km/s. That's a bit much, isn't it? Alexmuns calculator gives me a solution for 4.2 km/s.

[Arrowstar]

Hey guys, I've found the issue with the MFMS launch time. Thanks foe reporting. The issue will be resolved in v1.1.2, expected Sunday night.

I'm on mobile at the moment, with respond to the other questions today or tomorrow.

[Arrowstar]

Hey guys,

KSPTOT v1.1.2 is now available. It fixes the issue reported above in the MFMS code. Please download and let me know if the issue recurs. Thanks!

(Will get to questions later, I have a splitting headache at the moment...)

[diomedea]

Tested KSPTOT v.1.1.2, for me the issue with MFMS departure dates is solved. Brilliant!

Sorry to spam this thread, but I came across another two issues:

- My current KSP time is Year 55, Day 366 but when I load it from KSP, I get Year 17, day 3 which is utime 504791832.807. Does that mean that the time is retrieved incorrectly, or do you use earth time instead of Kerbin time for calculations?

- Here is what I get when I try to compute a transfer from Kerbin to Eloo:

http://i.imgur.com/85WcqMK.png

The porkchop plot starts at Year 1, Day 1 and gives a Departure + Arrival Delta-V:of about 16 km/s. That's a bit much, isn't it? Alexmuns calculator gives me a solution for 4.2 km/s.

I'd like to deal a bit on that. First issue, I know KSPTOT shows Earth Years/days; not (yet) Kerbin ones (Hope a day will come for a setting to switch among the two systems). Of course UT is used internally, and for transfer of time with KSPTOTConnect, so KSPTOT will always use the correct data.

Second issue, that is a behaviour I observed as well a number of times with KSPTOT. I want to show a few porkchop plots of that K-Ee transfer shifted in time:

Those show 3 solutions for transfer at one synodic period (about 113 Earth days) difference each other. Please note that the optimal departure date (minimum Delta-V) is with the first of the above plots, BEFORE the initial date in Kobymaru's plot. I guess KSPTOT is giving the correct solution when finds a minimum (in Total Delta-V) within the plotted area, but gets confused when the correct solution is outside the allowed bounds. In that case, the minimum shown on Kobymaru's plot is on a slope. It is not a correct solution (and could be filtered out if a check for gradient was implemented) and indeed the Delta-V shown is way too high. The plot axis lenghts degenerate to 1.0 as the correct times are outside of it.

So, when I see a similar issue, I change dates in the entry boxes until I put a local minimum within the plot area. With the plots shown above, I first went backwards in time as that was the direction KSPTOT was leaning towards in its search. But if limited by a bound, KSPTOT should actually try to find a valid solution in the other direction (with greater departure dates). The third of the plots above shows one such valid solution is found 92 days after the earliest departure date set in Kobymaru's plot, and I suppose it would have been automatically found and plotted if KSPTOT wasn't instead trying to find the best possible solution (occurring in the past).

[Drew Kerman]

Using the latest release, I can't seem to add my own thruster nor modify existing ones. The window lets me do this, but as soon as I close and re-open it the changes/additions are all gone

[Arrowstar]

diomedea: Thanks for the response. Can you describe a bit more about what you're hoping KSP TOT will do? I guess I don't quite understand what you're after.

Gaiiden: Yes, I was able to recreate the issue. I'll figure it out and push a 1.1.3 tonight with a fix. Thanks!

[diomedea]

diomedea: Thanks for the response. Can you describe a bit more about what you're hoping KSP TOT will do? I guess I don't quite understand what you're after.

Actually I could do with KSPTOT as it is now, when I notice that issue shown by Kobymaru, I just tweak the bounds until the plot is centered on a local minimum.

But other users may want to see that solved. That plot by Kobymaru is clearly not showing correctly, returning the data from the point at (0,0) because it is where Delta-V is less than any other point in the vicinity.

My guess is that KSPTOT can't look for data beyond that point because of the set bound, otherwise would find points requiring less Delta-V. To be a local minimum, a value would be less than what returned by the same function with any other point near the one that originated that value. But when bounded, other points close to that one can't be considered, the derivative of the function in that point is not null (and that may be used to test if we have the issue). But thankfully, when dealing with direct planetary transfers, we know solutions are distant (more or less) one synodic period from each other. So, my suggestion would be to test for local minima (derivative function) in case a bound is reached while searching a solution; if the derivative value is too high, it means KSPTOT is stuck against a bound and should instead try a different point, starting one synodic period beyond the date for the last point considered. Of course, KSPTOT must know to look only for a local minimum solution, instead of searching for the unique best solution (given the eccentricity of Eeloo's orbit, I bet the absolute best is when encounter happens at Eeloo's periastron).

Also, I have no idea how actually the size of the date and flight time axis is computed. My guess is normally KSPTOT starts with one synodic period beyond the start date (on the date axis) and at least a duration equal to what required for a Hohmann transfer. And then it changes the size so to have the solution displayed clearly. But when that issue presents, KSPTOT shrinks both axis to 1.0 (days?). Then, size of the axis could be another criterium to detect that issue.

[Arrowstar]

I have resolved the issue discovered by Gaiiden concerning the thrusters in Mission Architect. The fix is in the newly uploaded KSP TOT v1.1.3. Please grab the update on the OP.

---

Actually I could do with KSPTOT as it is now, when I notice that issue shown by Kobymaru, I just tweak the bounds until the plot is centered on a local minimum.

But other users may want to see that solved. That plot by Kobymaru is clearly not showing correctly, returning the data from the point at (0,0) because it is where Delta-V is less than any other point in the vicinity.

My guess is that KSPTOT can't look for data beyond that point because of the set bound, otherwise would find points requiring less Delta-V. To be a local minimum, a value would be less than what returned by the same function with any other point near the one that originated that value. But when bounded, other points close to that one can't be considered, the derivative of the function in that point is not null (and that may be used to test if we have the issue). But thankfully, when dealing with direct planetary transfers, we know solutions are distant (more or less) one synodic period from each other. So, my suggestion would be to test for local minima (derivative function) in case a bound is reached while searching a solution; if the derivative value is too high, it means KSPTOT is stuck against a bound and should instead try a different point, starting one synodic period beyond the date for the last point considered. Of course, KSPTOT must know to look only for a local minimum solution, instead of searching for the unique best solution (given the eccentricity of Eeloo's orbit, I bet the absolute best is when encounter happens at Eeloo's periastron).

I understand the issue. I suppose my initial intuition is that any fix I tried to make would be a lot of effort for very minimal value added. As you pointed out, all you need to do is change the bounds. Typically, changing just the earliest arrival time upwards by +n synodic period(s) will do it. Additionally, there are options on the main GUI (Edit Menu -> Options) that allow you to search for multiple synodic periods (any positive integer number of periods I think) and add/subtract number of points per axis. Or, just increase the maximum delta-v to plot in the Options. In short, I think the issue may be that I haven't properly conveyed how to use the tool (plus the fact that ending up with a blank pork chop plot is confusing) and haven't added any kind of error messages or whatnot to let the user know when things have gone wrong.

What do you think?

Also, I have no idea how actually the size of the date and flight time axis is computed. My guess is normally KSPTOT starts with one synodic period beyond the start date (on the date axis) and at least a duration equal to what required for a Hohmann transfer. And then it changes the size so to have the solution displayed clearly. But when that issue presents, KSPTOT shrinks both axis to 1.0 (days?). Then, size of the axis could be another criterium to detect that issue.

You specify the number of synodic periods to search across in the Options menu (see above). Then the time intervals along the various axes are just the start times you enter on the left part of the GUI + the number of synodic periods entered in the Options times the actual synodic period.

The shrinking to 1.0 days is just an artifact of the issue that occurs when the code doesn't find any points below the maximum delta-v to plot. Since the plotting code doesn't have anything to plot, the axes just kinda get reset to the interval [0,1]. It's a MATLAB behavior, I think.

[Drew Kerman]

Thanks! Still working through my Duna mission based on the Laythe tutorial. Will of course let you know if I come across any other problems

[diomedea]

.

What do you think?

...

You specify the number of synodic periods to search across in the Options menu (see above). Then the time intervals along the various axes are just the start times you enter on the left part of the GUI + the number of synodic periods entered in the Options times the actual synodic period.

The shrinking to 1.0 days is just an artifact of the issue that occurs when the code doesn't find any points below the maximum delta-v to plot. Since the plotting code doesn't have anything to plot, the axes just kinda get reset to the interval [0,1]. It's a MATLAB behavior, I think.

Fine. Different settings in the options menu are definitely good to solve such issues. Certainly not the case then to make an automatic "shifter" so to find solutions somewhere else than the ranges allowed in the options. Probably helpful if, when the plot collapses (axes reset to [0,1]), text may be shown over it suggesting the user to increase the settings.

Anyway, your suggestion about the number of synodic periods proved useful to make evident another possible improvement. As it is now, the porkchop plot for direct transfers has the arrival time on the y-axis (the multi-flyby porkchop plot instead has time of flight). Using arrival time, half the area (lower-right) of the plot is blank, because arrival can't be less than departure time. Most evident when more than 1 synodic period is shown. My guess is both arrival and flight time could be useful when plotted, and could be switched via another setting in the options.

[Drew Kerman]

I made it to Duna!! <- mission plan

Heck I even managed to accidentally work in an Ike flyby, which is pretty sweet if you ask me. Still, I'm rather unsure about how to actually use this in the game. Note this isn't the actual mission I plan to fly, this is just me trying to get to Duna with the MA tool. I'm sending over a SCANsat-equipped probe so I will need a high inclination and proper altitude and all that, will probably want to aerobrake but that's all for later. Right now I want to understand how this Duna mission I just managed to plot would fly in the game.

So I launch my probe ahead of the TDI window and get it set in its proper orbit. Then I guess I can use the in-game connect to upload the TDI burn and wait for that to arrive (just noticed I forgot to rename the DV maneuvers). Okay, so TDI burn complete and I'm on my way to Duna. Will probably need to make minor RCS corrections along the way to ensure an Ike encounter. Then I can upload the circularization burn maneuver and wait for that after I pass Ike. Yay, Duna orbit!

Right?

Also, I don't see where my total delta-v usage is. My final spacecraft state has me arriving 3 days earlier than the porkchop plot so did I use more than the initial amount given to me? I suppose I can change up the amount of L/O fuel in the craft to see what weight gives me 0 on arrival and then calculate the delta-v from that. To be honest I was expecting to see a bit more information about each leg, like the actual maneuver values for the circularization burn.

---------------------------------------------------------------------------------------------------------

Porkchop Plot Results - 25-Jun-2014 04:08:33

--------------------------------------------

Optimal Kerbin Departure: Year 1, Day 290 00:39:00.423 (24971940.4226 sec UT)

Optimal Duna Arrival: Year 1, Day 359 16:42:42.262 (30991362.2622 sec UT)

Transfer Duration: 69 Days 16:03:41.840

Departure + Arrival Delta-V: 1.7388 km/s

---------------------------------------------------------------------------------------------------------

Hyperbolic Departure Orbit from Kerbin

---------------------------------------------

Semi-major Axis = -3833.795 km

Eccentricity = 1.1826

Inclination = 5.727 deg

Right Ascension of AN = 18.153 deg

Argument of Periapse = 0.000 deg

Transfer Orbit about Sun

---------------------------------------------

Semi-major Axis = 17371708.325 km

Eccentricity = 0.21713

Inclination = 0.286 deg

Right Ascension of AN = 76.695 deg

Argument of Periapse = 359.645 deg

Kerbin Depart True Anomaly = 0.355 deg

Duna Arrive True Anomaly = 168.970 deg

---------------------------------------------

Departure Date = Year 1, Day 290 00:39:00.423

(24971940.423 sec UT)

Arrival Date = Year 1, Day 359 16:42:42.262

(30991362.262 sec UT)

Duration = 69 Days 16:03:41.840

Burn Information to Depart Kerbin

---------------------------------------------

Total Delta-V = 1.10636 km/s

Prograde Delta-V = 1055.65184 m/s

Orbit Normal Delta-V = 331.11229 m/s

Radial Delta-V = 0.00000 m/s

---------------------

Burn True Anomaly = 18.15335 deg

Burn Time Past Peri. = 98.7406 sec

Burn Time Before Peri. = 1859.38788 sec

Initial Orbit Period = 1958.12844 sec

[Arrowstar]

Fine. Different settings in the options menu are definitely good to solve such issues. Certainly not the case then to make an automatic "shifter" so to find solutions somewhere else than the ranges allowed in the options. Probably helpful if, when the plot collapses (axes reset to [0,1]), text may be shown over it suggesting the user to increase the settings.

Anyway, your suggestion about the number of synodic periods proved useful to make evident another possible improvement. As it is now, the porkchop plot for direct transfers has the arrival time on the y-axis (the multi-flyby porkchop plot instead has time of flight). Using arrival time, half the area (lower-right) of the plot is blank, because arrival can't be less than departure time. Most evident when more than 1 synodic period is shown. My guess is both arrival and flight time could be useful when plotted, and could be switched via another setting in the options.

So I played around with what I hoped were decent solutions today. The easiest and most intuitive from my perspective was to increase the "maximum delta-v to plot", which is the upper bound on delta-v on the pork chop plot. If all delta-v points are above this point, you get the weird-looking, blank plot that we've been talking about. There are now additional notifications to let the user know what's going on when this happens.

I made it to Duna!! <- mission plan

Heck I even managed to accidentally work in an Ike flyby, which is pretty sweet if you ask me. Still, I'm rather unsure about how to actually use this in the game. Note this isn't the actual mission I plan to fly, this is just me trying to get to Duna with the MA tool. I'm sending over a SCANsat-equipped probe so I will need a high inclination and proper altitude and all that, will probably want to aerobrake but that's all for later. Right now I want to understand how this Duna mission I just managed to plot would fly in the game.

So I launch my probe ahead of the TDI window and get it set in its proper orbit. Then I guess I can use the in-game connect to upload the TDI burn and wait for that to arrive (just noticed I forgot to rename the DV maneuvers). Okay, so TDI burn complete and I'm on my way to Duna. Will probably need to make minor RCS corrections along the way to ensure an Ike encounter. Then I can upload the circularization burn maneuver and wait for that after I pass Ike. Yay, Duna orbit!

Right?

Also, I don't see where my total delta-v usage is. My final spacecraft state has me arriving 3 days earlier than the porkchop plot so did I use more than the initial amount given to me? I suppose I can change up the amount of L/O fuel in the craft to see what weight gives me 0 on arrival and then calculate the delta-v from that. To be honest I was expecting to see a bit more information about each leg, like the actual maneuver values for the circularization burn.

Nice work!

So, how to use this in the game. Here's what I do (of course I use my own software!). I plan the whole mission out ahead of time, just as you've done with the mission plan you linked to here. Then, I get into orbit in KSP. Go back to Mission Architect (pause KSP here). Open up the initial state and import the orbit from KSP using KSPTOTConnect (right click on the orbit display, select get orbit from KSP). KSP must be running and must be in the Flight Scene (where you can see/control your vessel) for this to work. So import the orbit and then save/close the initial state box. Inevitably this will screw up your mission plan, because you didn't launch into exactly the orbit you specified in Mission Architect the first time around. So go ahead and re-optimize the mission with Mission Optimizer. Re-find a mission solution that gets you to Duna or where ever.

Once you've got this, we can use Mission Architect to import maneuvers directly into KSP using KSPTOTConnect. Select the first DV_Maneuver in the Mission Script in Mission Architect, right click it, and select the Upload option. Hit the big red button on the box that comes up. Now go back to KSP and double check that your maneuver was created properly. It should have been. Unpause KSP, execute maneuver.

Once you've executed the maneuver, pause KSP. Go back to Mission Architect. Select the Coast event immediately after your DV_Maneuver in the mission script. Right click the mission script and select "Advance Script Up To Selected Event." This will trim the mission script down to just the events after the burn. Now go back to the initial state, reimport from KSP as above, and rinse and repeat for each engine burn in your mission.

Let me know if you have any questions! I hope that helps. Nice work with Mission Architect, btw.

---

Hi everyone,

This is to announce that KSP TOT v1.1.4 is hereby released. The change log is as follows:

• The pork chop plot now requests an increase in the maximum delta-v to plot if the minimum delta-v in the data points computed is greater than that value.
  
• Added the ability to generate bodies.ini files from KSP! In the File menu of the main GUI, select "Create Bodies File From KSP."
  
• Added a note in the generic time entry dialog box clarifying that those times are Earth times, not Kerbin times.
  
• Added a new constraint to Mission Architect: Universal Time constraint. Restricts event end times to the universal times specified by the user.
  

Download is available on the first post, as always. You MUST update the KSPTOTConnect plugin included in the new KSPTOT package to use the new Create Bodies File functionality.

Let me know if you have any questions!

[Drew Kerman]

Okay so that's generally what I thought I had to do, so nice to know I understand the concept. It seems at first a bit counter-productive to plan the whole thing then redo it as you fly, but understandably you're not going to fly it perfectly as planned and while you're re-optimizing the mission it at least has the original plan to use as a basis for its optimizations. Alright... but still I'm not completely clear on how to build the ship that is capable of carrying out the plan I've laid out. The only thing I can think of is, as I said, to use the final state weight to calculate the amount of dV that was used during the flight. It would still be nicer if we could get dV estimates for each leg of the trip involving a burn.

Also, I'm not clear on what the advantage is to generating the bodies.ini file from KSP, can that be explained a bit more?

And, I wanted to try out a small mission from Kerbin to Minmus but I can't figure out where to even start for that since the porkchop plotter won't let me select Kerbin as a starting point when traveling to Minmus. I'm playing a no-experimenting career so much as I would like to throw together a mock mission to fly, I need to be able to get it as right as possible the first time. Mistakes will of course be made which is why I want to do a simple Minmus transfer first

Edited June 29, 2014 by Gaiiden

[Arrowstar]

Okay so that's generally what I thought I had to do, so nice to know I understand the concept. It seems at first a bit counter-productive to plan the whole thing then redo it as you fly, but understandably you're not going to fly it perfectly as planned and while you're re-optimizing the mission it at least has the original plan to use as a basis for its optimizations.

It may seem counter-intuitive, but this is also what we do in Real Life . Our lead astrodynamicist for a mission will put together the mission plan that places a satellite at geostationary orbit at the correct longitude. We then follow the steps I outlined for you in my last post: 1) execute maneuver, 2) cull out previously executed events, and 3) update initial state with current orbit and repeat. And yes, having the initial plan as the initial guess makes optimization much easier most of the time.

Alright... but still I'm not completely clear on how to build the ship that is capable of carrying out the plan I've laid out. The only thing I can think of is, as I said, to use the final state weight to calculate the amount of dV that was used during the flight. It would still be nicer if we could get dV estimates for each leg of the trip involving a burn.

I can put together a v1.1.5 tomorrow with this feature in it if you can describe for me what exactly you're looking for. Do you just need the total delta-v for every maneuver in a table or something?

Also, I'm not clear on what the advantage is to generating the bodies.ini file from KSP, can that be explained a bit more?

If you're using the stock KSP solar system, there is no advantage. In fact, there's a slight disadvantage because I'm using more significant figures in the bodies.ini file I ship with KSP TOT by default. However, say you were using Real Solar System mod or another Planet Factory body. Then you'd need to get these bodies into KSP TOT some how, and this functionality allows that.

And, I wanted to try out a small mission from Kerbin to Minmus but I can't figure out where to even start for that since the porkchop plotter won't let me select Kerbin as a starting point when traveling to Minmus. I'm playing a no-experimenting career so much as I would like to throw together a mock mission to fly, I need to be able to get it as right as possible the first time. Mistakes will of course be made which is why I want to do a simple Minmus transfer first

Your best bet for finding a good initial guess for burns is to use the Rendezvous Maneuver Sequencer. It's in the Tools -> Maneuver Planning menu. Basically, treat the Kerbin Orbit -> Minmus mission as a rendezvous between two spacecraft and not a transfer from one planet to another. It works, promise! Let me know if you need any help using it.

[Drew Kerman]

I can put together a v1.1.5 tomorrow with this feature in it if you can describe for me what exactly you're looking for. Do you just need the total delta-v for every maneuver in a table or something?

Don't really know yet to be honest. Let me get some practical usage under my belt and I will be able to have a better idea

Your best bet for finding a good initial guess for burns is to use the Rendezvous Maneuver Sequencer. It's in the Tools -> Maneuver Planning menu. Basically, treat the Kerbin Orbit -> Minmus mission as a rendezvous between two spacecraft and not a transfer from one planet to another. It works, promise! Let me know if you need any help using it.

I will give it a go, thanks for all the help

[Arrowstar]

Sounds good, let me know how it goes!