[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.10 [Major LVD Improvements!]

[Arrowstar]

Hi all,

At the behest of /u/voneiden on the KSP subreddit, I've corrected one more set of items in this sequence of patches. Namely, the following, all having to do with the KSPTOT MCC Real Time System:

• All TCP read commands are now performed asynchronously, meaning that there's significantly reduced UI lag in the MCC console displays;
  
• All while()/pause() loops that I had implemented before have now been eliminated on account of that fact that data is being read asynchronously; and
  
• The UI should no longer freeze for long durations after leaving the flight scene in KSP with the KSPTOT/MCC connection still open (it'll freeze for a moment to kill the TCPIP connections, but that's it).
  

Anyway this is a pretty major improvement over what I had released before. If you're looking to use KSPTOT as your mission control center software of choice, it should be much more reliable, stable, and easy to use.

If you update (and I recommend you do), please be sure to update your KSPTOTConnect folder in your KSP/GameData folder! Just delete the old one and replace it the new one I provide, saving your IP address whitelist file in the process. I can help with this if need be, just post here.

You can download this patch release in the first post as per usual. If you have questions, please post here and let me know! Thanks.

Edited May 18, 2014 by Arrowstar

[voneiden]

Hi Arrowstar,

do you prefer me to drop my future notes and what not here instead of reddit? Maybe it's more organized in one place that way. I'll see if I can get a proper multiplayer test for the newest update. Maybe this time we actually hit Minmus.

I accidentally selected yesterday on the Mission Architect an inertial dV maneuver instead of the usual orbital dV maneuver. Noticed it resulted in an error, and after a bit of tinkering I also got another kind of error. Now I know you're really fast at fixing stuff but these are really low priority. I don't even know in what case I'd use inertial maneuver over orbital maneuver.

Case 1 - Attempting to minimize distance to body with a single inertial node and coast.

- Error message: Objective function is undefined at initial point. Fmincon cannot continue.

- Error trace: http://pastebin.com/G36HWrwH

- Mat file: https://dl.dropboxusercontent.com/u/17806420/objective-undefined.mat

Case 2 - Attempting to maximize spacecraft mass, minimize inclination or eccentricity instead in Case 1

- Error message:

There was an error optimizing the mission script. Attempted to access eventLog(0,; index must be positive integer or logical

- Error trace: http://pastebin.com/GAWbaMfv

- Mat file: same as above

Edited May 18, 2014 by voneiden
Formatting

[cmheisel]

It seems like there's an issue between the KSPTOTConnect plugin and the latest version of MechJeb that leads to landing errors. Here's the issue I filed with MechJeb but thought I'd bring it up here as well: https://github.com/MuMech/MechJeb2/issues/363

[Arrowstar]

Hi Arrowstar,

do you prefer me to drop my future notes and what not here instead of reddit? Maybe it's more organized in one place that way. I'll see if I can get a proper multiplayer test for the newest update. Maybe this time we actually hit Minmus.

Yep, let's use this forum thread from here on out. It's easier than checking Reddit and I get email notifications when people post here. Yes, I look forward to your multiplayer test results! Again, if I can help with technical issues in any way, let me know. I'd love to see KSPTOT succeed in the "mission control simulation simulation" arena too.

I accidentally selected yesterday on the Mission Architect an inertial dV maneuver instead of the usual orbital dV maneuver. Noticed it resulted in an error, and after a bit of tinkering I also got another kind of error. Now I know you're really fast at fixing stuff but these are really low priority. I don't even know in what case I'd use inertial maneuver over orbital maneuver.

Case 1 - Attempting to minimize distance to body with a single inertial node and coast.

- Error message: Objective function is undefined at initial point. Fmincon cannot continue.

- Error trace: http://pastebin.com/G36HWrwH

- Mat file: https://dl.dropboxusercontent.com/u/17806420/objective-undefined.mat

Case 2 - Attempting to maximize spacecraft mass, minimize inclination or eccentricity instead in Case 1

- Error message:

There was an error optimizing the mission script. Attempted to access eventLog(0,; index must be positive integer or logical

- Error trace: http://pastebin.com/GAWbaMfv

- Mat file: same as above

Luckily, I was able to find the bug in about 2 minutes. Also luckily, the fix was one additional line of code. I've uploaded a new build (usual location), feel free to try it out. Thanks for the great report! Including the *.mat files is very helpful...

- - - Updated - - -

It seems like there's an issue between the KSPTOTConnect plugin and the latest version of MechJeb that leads to landing errors. Here's the issue I filed with MechJeb but thought I'd bring it up here as well: https://github.com/MuMech/MechJeb2/issues/363

Gotta admit, that's a new one for me. Do you see anything in your debug log that might indicate where things are going awry?

[krmcginnis]

Hi Arrowstar,

Thank you very much for the quick turn around time when it comes to responding and fixing bugs. I am still having the same issue with the porkchop plot and the text output not being the same. Here is a screenshot of what I'm talking about:

http://imgur.com/J9agqiN

This is occurring on all planet calculations. But at least it's not giving me a departure time after the arrival time!

[krmcginnis]

I just noticed this as well, when computing the porkchop plot for Dres, Jool, and Eeloo (all above 10 km/s deltaV), I get "No Solutions or Above Plot Max" for the estimated deltaV:

http://imgur.com/hcsDXdM

[Arrowstar]

Hi Arrowstar,

Thank you very much for the quick turn around time when it comes to responding and fixing bugs. I am still having the same issue with the porkchop plot and the text output not being the same. Here is a screenshot of what I'm talking about:

http://imgur.com/J9agqiN

This is occurring on all planet calculations. But at least it's not giving me a departure time after the arrival time!

Hi there,

So this actually isn't a bug. Here's what's happening. When you run the porkchop plot, it samples the space 2500 times to put together the contour. The tooltip you see on the plot is the best point on the contour map. However, after the contour is generated, the code then runs a function minimizer on the porkchop plot function and finds the actual best ("optimized") times to leave and arrive. This gets displayed in the text window below the plot. Due to the way the contour plot works, it would be hard to get the "optimized" times to show up on the tooltip on the plot itself. So the fact that you see two different arrival/departure times is perfectly normal, though they should be fairly close to each other, as they are in the picture you provided.

Good question though! Does that all make sense?

I just noticed this as well, when computing the porkchop plot for Dres, Jool, and Eeloo (all above 10 km/s deltaV), I get "No Solutions or Above Plot Max" for the estimated deltaV:

http://imgur.com/hcsDXdM

Eeloo and Dres have fairly long orbital periods. You may have to slide your departure/arrival dates around a bit to actually find a valid solution. Or, in the options, increase the max delta-v and/or the number of synodic periods to search for. Either should ultimately resolve the issue.

Can you try that out for me? Does that make sense?

[krmcginnis]

Arrowstar,

I didn't even know there was an option menu! haha anyway, putting a higher "maximum delta-v to plot" fixes the "issue" I was having. Also, I understand why the text output and the tooltip may not match. I took a few courses in college that involved using Matlab but I can't imagine how much work it has taken you to get this amazing program to where it is today. So, thank you, thank you, thank you!

[Arrowstar]

Arrowstar,

I didn't even know there was an option menu! haha anyway, putting a higher "maximum delta-v to plot" fixes the "issue" I was having. Also, I understand why the text output and the tooltip may not match. I took a few courses in college that involved using Matlab but I can't imagine how much work it has taken you to get this amazing program to where it is today. So, thank you, thank you, thank you!

Yup, this is why I need documentation! Anyway, glad you like it. Let me know if you have any more questions!

[voneiden]

Alrighty, here's my current bugger list on the Mission Architect from yesterdays (solo) practice mission.

Bugs and unexpected behaviour

- Double tapping arrow keys while navigating the event list actually opens an event (is interpreted as a double click?)

- "Get state from KSP" can still return negative true anomaly for hyperbolic orbits, but requires the value to be [0,360] to be accepted in the orbit definition window. Manual modulo 360 does the job as a temporary fix.

- "Get state from KSP" doesn't set the orbit reference body? My vessel was in SoI of Minmus, get state returned valid orbital elements for the Minmus orbit, but it left the orbit body droplist selection as Kerbin.

- If there is already an optimization window open, opening a new optimization window from the menu bar/keyboarod shortcut closes the old one, erasing all unsaved constraint settings. Would be nice if the existing window would receive focus instead. I managed to do this somehow twice in a row :-)

- Altitude constraint wants boundaries in degrees (instead of km?)

Feature requests & ideas (do use your own judgement)

- Be able to change constraint associated event after definition (because if user adds a new event before other events, previously defined constraints will likely point to wrong event numbers)

- Relocate constraint associated event droplist from the bottom of the optimize window into the "define new constraint" popup (=better visibility)?

- Remember previously selected constraint associated event instead of defaulting to the last event, or default it to the same event that is currently selected for optimization?

- If events are deleted, some constraints seem to get sometimes deleted automatically too. I would rather delete/reassociate them manually. Alternatively they could be disabled?

- Being able to quickly see from the event list which events have optimization enabled. For example adding an asterisk before or after the event type? Coast with TA Opt set would look like "2 - COAST* - To Periapsis". "*COAST"? "*COAST*"? Bold text? Maybe not possible in the list box. I'm aware I can check it in the Optimize window, but that still requires tapping through all the events.

^ Many of the above seem to be somewhat relevant in my opinion when I have created a mission plan and am attempting to fly through it. Updating the vessel state after executing burns in KSP and creating correction burns etc requires adding/deleting/moving events, but generally the mission constraints do not change. As it is, it requires quite a bit of repetitive redefinition of constraints. In addition to being a repetitive task, it also takes time: the faster the mission planner can respond to the dynamic nature of the mission, the less waiting time for the pilot.

Remarks

- CTRL+O for optimize is great for left handed people.

- CTRL+R for reoptimize is great for right handed people.

Edited May 19, 2014 by voneiden

[Arrowstar]

- Double tapping arrow keys while navigating the event list actually opens an event (is interpreted as a double click?)

Fixed! Yeah, that was the problem: any action that called the listbox callback could get interpreted as a click, and two of them in a row is a double click. Anyway, issue resolved.

- "Get state from KSP" can still return negative true anomaly for hyperbolic orbits, but requires the value to be [0,360] to be accepted in the orbit definition window. Manual modulo 360 does the job as a temporary fix.

Fixed.

- "Get state from KSP" doesn't set the orbit reference body? My vessel was in SoI of Minmus, get state returned valid orbital elements for the Minmus orbit, but it left the orbit body droplist selection as Kerbin.

Also fixed. Had to add a bit of code, but it looks like it works properly now.

- If there is already an optimization window open, opening a new optimization window from the menu bar/keyboarod shortcut closes the old one, erasing all unsaved constraint settings. Would be nice if the existing window would receive focus instead. I managed to do this somehow twice in a row :-)

Fixed. This one was a bit of a challenge, but I think I got it. And yes, I agree, definitely annoying as a bug! Glad you caught it.

- Altitude constraint wants boundaries in degrees (instead of km?)

Whoops. Fixed.

- Be able to change constraint associated event after definition (because if user adds a new event before other events, previously defined constraints will likely point to wrong event numbers)

Done. I agree this is the more flexible way to do things. I added a dropdown in the constraint details box and you can now edit the event to your heart's content.

- Relocate constraint associated event droplist from the bottom of the optimize window into the "define new constraint" popup (=better visibility)?

Done per above.

- Remember previously selected constraint associated event instead of defaulting to the last event, or default it to the same event that is currently selected for optimization?

Decided not to implement until I get feedback on how to new system works. If you still think it's a good improvement, let me know.

- If events are deleted, some constraints seem to get sometimes deleted automatically too. I would rather delete/reassociate them manually. Alternatively they could be disabled?

I did not change this behavior. Constraints are intimately tied to events, and when you remove an event, the corresponding constraint needs to go, too. If it sticks around, garbage collecting gets to be a bit tedious later on. I also don't have a good way of managing "active" vs. "inactive" constraints, as the system was never designed with that in mind. I'm open to thoughts on something like that, though. Do you think that would be useful?

- Being able to quickly see from the event list which events have optimization enabled. For example adding an asterisk before or after the event type? Coast with TA Opt set would look like "2 - COAST* - To Periapsis". "*COAST"? "*COAST*"? Bold text? Maybe not possible in the list box. I'm aware I can check it in the Optimize window, but that still requires tapping through all the events.

Done. I really like this. I went with the "2 - *COAST" version, though. It was easier to see the "*".

^ Many of the above seem to be somewhat relevant in my opinion when I have created a mission plan and am attempting to fly through it. Updating the vessel state after executing burns in KSP and creating correction burns etc requires adding/deleting/moving events, but generally the mission constraints do not change. As it is, it requires quite a bit of repetitive redefinition of constraints. In addition to being a repetitive task, it also takes time: the faster the mission planner can respond to the dynamic nature of the mission, the less waiting time for the pilot.

Indeed, speed is important! I definitely agree. I hope the changes I made above help, and I definitely appreciate any more insight you have as an end user into ways to streamline the process and make the application more friendly to use.

Remarks

- CTRL+O for optimize is great for left handed people.

- CTRL+R for reoptimize is great for right handed people.

Not sure what to make of these... so thanks?

I have a new build ready and waiting to be downloaded. I do caution you, however, that the optimization constraint system did get a bit of an overhaul tonight. I tested everything a few times with a simulated mission to Duna and nothing broke, but there's lots of new code in some places. Please report any bugs you find so I can fix them ASAP.

Thank you again for your invaluable help. KSPTOT and Mission Architect get better everyday!

Btw, have you had a chance to do any testing with the new KSPTOTConnect MCC stuff?

[diomedea]

I know versioning system is a matter of personal preference and totally up to the author to make.

However, it is now (if I am correct) the 4th different release still marked as 0.12.2, not really easy for users to check what each release is by looking at datetime stamps with some files.

If it isn't too much, could you develop the version number so to uniquely stamp each future release?

[Arrowstar]

Hi Diomedea,

Sure. The past 3-4 "releases" have just been bug-fixing patches and I typically save the versioning number increments for new features. However, I can see that what I've been doing could be confusing from an end user perspective. I'll go ahead and come up with something to make things more clear in the future, and I'll consider re-releasing KSPTOT tonight as v0.12.3 with fixes to any new bugs voneiden might find. There have certainly been enough patches to warrant that I think!

Good suggestion, thanks for bringing it up.

[TranceaddicT]

Arrowstar,

Thank you.

Your update schedule is a testament to what can be done when a developer wants to: You da man! I'm sure there are many more among us who are greatly appreciative.

Now, go grab a beer. Order some pizza. Sit back and, well ... enjoy ... or whatever. If the image inserts don't work the album is here: ScreenShots

1.0 Bugs/Quirks/Oopsies:

1.1 If the cursor is present in the Results window during the first calculation, output only displays under area covered by 'Right-click to clear status window'. Click-drag highlighting restores display.

1.2 During the plot calculation, there is a moment during the optimization period where there is a NaN. It happens EVERY time a plot is computed.

Item #2

1.3 When I click to zoom, regardless as to where on the plot, it will zoom to a different location. It's a bizarre thing too, it only happens on plots as below (I haven't tried the moons):

Moho - 94,99

Eve - functions perfectly

Duna - functions almost as expected, not centered

Dres - functions as expected

Jool - 144,269

Eeloo - 90,270

(Coordinates are clicks performed directly on the optimal point; can vary depending on where in the entire plot click occurs.)

1.4 Error: PROBLEM structure should have a non-empty XO field. I'm sure it has something to do with EAT occurring before EDT.

Item #3

2.0 Observations (personal idiosyncrasies):

2.1 Plot Tip Box: Tends to be obscured by elements outside the plot area.

Item #1

2.2 Entering the Earliest X Time: The enter-key does not function; you must click 'OK'.

2.3 Synodic Periods: somewhere around 9-10 things go hinkey.

2.4 Computing plots for Duna (I've only done this specific plot series; no others.), Using a 3 synodic period plot with my current time (EDT:1y 71d 07:11:~~,EAT:1y 71d 07:12:~~) give me the following:

Porkchop Plot Results - 21-May-2014 00:11:40

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

Optimal Kerbin Departure: Year 2, Day 152 20:59:47.027 (44657987.0274 sec UT)

Optimal Duna Arrival: Year 2, Day 229 21:27:18.214 (51312438.2136 sec UT)

Departure + Arrival Delta-V: 1.7338 km/s

Using: EDT:1y 250d ,EAT:1y 300d gets me this:

Porkchop Plot Results - 21-May-2014 00:12:39

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

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)

Departure + Arrival Delta-V: 1.7388 km/s

Don't understand what is happening here.

3.0 Requests:

3.1 Plot tip box: Can you make it so the tip box in the plot can be moved? Sometimes it blocks a portion of the plot that can help with future calculations. See example.

3.2 Transfer Duration: Can you include this in the Plot Results Printout? (Yes, friends it's mimple sath, but it's so convenient too!) <think mitaveatamegevin Yes, I know I'm dating myself. For the deprived youth among us, start at 9:50: http://www.tv.com/shows/i-love-lucy/lucy-does-a-tv-commercial-15110/>

3.3 Output Log: Would it be possible to have any Optimization results output to a log?

4.0 Usage Note:

For those having problems acquiring a valid date pair for the next available window:

Edit:Options:Synodic Period Change this to 10.

Recompute from EDT:1,1 0:0:0; EAT:1,1 0:0:0. (Or, use last good window as starting point.)

Find the date-pair you want.

Reset Synodic Period in Options to 1

Set date-pair to above.

Recalculate.

You'll have a perfect resolution for the date-pair you chose.

Edited May 21, 2014 by TranceaddicT

[Arrowstar]

1.1 If the cursor is present in the Results window during the first calculation, output only displays under area covered by 'Right-click to clear status window'. Click-drag highlighting restores display.

This appears to be either a MATLAB bug or Windows issue. In any event, no combination of refreshing the GUI or text box helped. I think this is a "no fix" issue, even though I was able to reproduce it. Sorry.

1.2 During the plot calculation, there is a moment during the optimization period where there is a NaN. It happens EVERY time a plot is computed.

Item #2

https://plus.google.com/photos/+ScottMcCarthy/albums/6015786221924521585/6015786251884528658?pid=6015786251884528658&oid=100817669061399840558

Fixed! And this fix should be good across the whole application...

1.3 When I click to zoom, regardless as to where on the plot, it will zoom to a different location. It's a bizarre thing too, it only happens on plots as below (I haven't tried the moons):

Moho - 94,99

Eve - functions perfectly

Duna - functions almost as expected, not centered

Dres - functions as expected

Jool - 144,269

Eeloo - 90,270

(Coordinates are clicks performed directly on the optimal point; can vary depending on where in the entire plot click occurs.)

Could not reproduce... can you describe more thoroughly (with screenshots, step by step) how to go about getting this issue to appear?

1.4 Error: PROBLEM structure should have a non-empty XO field. I'm sure it has something to do with EAT occurring before EDT.

Item #3

https://plus.google.com/photos/+ScottMcCarthy/albums/6015786221924521585/6015786268730061266?pid=6015786268730061266&oid=100817669061399840558

Resolved, hopefully.

2.1 Plot Tip Box: Tends to be obscured by elements outside the plot area.

Item #1

https://plus.google.com/photos/+ScottMcCarthy/albums/6015786221924521585/6015786239232275170?pid=6015786239232275170&oid=100817669061399840558

This is a MATLAB bug. I tried for days to resolve this about a year ago, but no joy. I could try to resize/reshape the content of the tooltip, maybe...

2.2 Entering the Earliest X Time: The enter-key does not function; you must click 'OK'.

Do you mean in the box that comes up if you enter the UT as date time? Can you explain this one more?

2.3 Synodic Periods: somewhere around 9-10 things go hinkey.

I'll investigate.

2.4 Computing plots for Duna (I've only done this specific plot series; no others.), Using a 3 synodic period plot with my current time (EDT:1y 71d 07:11:~~,EAT:1y 71d 07:12:~~) give me the following:

Porkchop Plot Results - 21-May-2014 00:11:40

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

Optimal Kerbin Departure: Year 2, Day 152 20:59:47.027 (44657987.0274 sec UT)

Optimal Duna Arrival: Year 2, Day 229 21:27:18.214 (51312438.2136 sec UT)

Departure + Arrival Delta-V: 1.7338 km/s

Using: EDT:1y 250d ,EAT:1y 300d gets me this:

Porkchop Plot Results - 21-May-2014 00:12:39

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

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)

Departure + Arrival Delta-V: 1.7388 km/s

Don't understand what is happening here.

It's probably finding a better local minimum at the second location is all. Can I get pictures? I couldn't reproduce this exactly for some reason...

3.1 Plot tip box: Can you make it so the tip box in the plot can be moved? Sometimes it blocks a portion of the plot that can help with future calculations. See example.

Have you tried clicking and dragging the tip box in the plot window?

3.2 Transfer Duration: Can you include this in the Plot Results Printout? (Yes, friends it's mimple sath, but it's so convenient too!) <think mitaveatamegevin Yes, I know I'm dating myself. For the deprived youth among us, start at 9:50: http://www.tv.com/shows/i-love-lucy/lucy-does-a-tv-commercial-15110/>

Sure, don't see why not. It's another two lines of code.

3.3 Output Log: Would it be possible to have any Optimization results output to a log?

Better logging is something I keep meaning to do and keep putting off because it's tedious. But yes, some day.

Give me a few days to get this all released. I'm planning on doing a v0.12.3 release this weekend, and I'll have what fixes/adjustments I can come up with from your list in it. Thanks for the great feedback!

[diomedea]

Arrowstar, I have a fantasy about one additional feature that could be made possible with KSP TOT. Can't find if anybody ever already proposed that (sorry in case), but would be grateful if you could consider its feasibility.

Mission Architect is great trying to achieve goals within set constraints; but when initial conditions are awful, solutions may not be suitable. Now, if I want to schedule a planetary flyby, I am actually trying to set two different transfers right at the same time: before and after the flyby. E.g., I want to transfer from Kerbin to Jool but making a slingshot at Duna. More complex missions may be conceived (like a voyager mission) involving a sequence of transfers.

Now, the current approach would be to start KSP TOT, find some transfer windows Kerbin-Duna, then separately transfer windows Duna-Jool, then match the times so that arrival and departure from Duna match for a couple of those transfers. That approach is probably less than ideal, being quite long.

Would it be possible to create a "multiple transfer" plot, like KSP TOT already gives for single transfers (the porkchop plot), but showing best solutions with matched transfers?

[Arrowstar]

So are you talking about single- or multi-flyby missions? For single that functionality already exists in the form of flyby maneuver sequencer, a tool already in KSPTOT. If multi... it might be something to consider again, but I looked at it once last year and it's a hard problem. It's time and CPU intensive and I'm not sure it'd work well for the average user on a desktop PC.

Or do you mean something else?

[diomedea]

Actually, my goal is multi flybys, really looking at a possibility to plan a Voyager-like mission. Glad to know you already considered that, if that's beyond a normal CPU capabilities no reason to deal with that.

Anyway, I never tried even the single flyby sequencer till today. Another of the goodies of KSP TOT still unknown to me. Running parallel processes and using some math libraries never called before, and still taking a lot to compute on my PC (about 30 minutes to complete the example Kerbin-Duna-Jool flyby; but then tried other scenarios like Kerbin-Eve-Duna, Kerbin-Eve-Jool, and it took just few minutes).

That is making me think what could be wrong with my simplistic approach. Even if not perfect, trying to match dates for each flyby (arrival and departure transfers) should give at least a raw solution, then to be refined tweaking periapsis at each flyby so to make the orbits match (if at all possible; if not, I would just check with another match of dates). A better mathematical approach would probably consider what are the different angles at arrival and departure with each flyby, compute the energy required to change orbits and find how much of that energy can be obtained by gravity assist. It shows I am not an astrodynamicist, glad if you could point at what inconsistencies are in my procedure , but please don't lose your time if it takes too much.

Edited May 22, 2014 by diomedea
more reports on tests done with Flyby sequencer

[TranceaddicT]

1.3 When I click to zoom, regardless as to where on the plot, it will zoom to a different location.

Could not reproduce... can you describe more thoroughly (with screenshots, step by step) how to go about getting this issue to appear?

It would seem this was an isolated glitch. I replicated it multiple times, but now .. no dice. Maybe system restart cleared something. Who knows; it's gone.

2.2 Entering the Earliest X Time: The enter-key does not function; you must click 'OK'.

Do you mean in the box that comes up if you enter the UT as date time? Can you explain this one more?

Yes, that box. Right-click EDT gets menu: Enter UT as Date/Time -or- Get UT from KSP. Select Enter UT as Date/Time. Enter values and hit enter-key. Result: input not accepted. Click 'OK'; result: input accepted.

2.3 Synodic Periods: somewhere around 9-10 things go hinkey.

Disregard. Looks like it was associated with the click-zoom problem. Can't replicate.

2.4 Computing plots for Duna (I've only done this specific plot series; no others.), Using a 3 synodic period plot with my current time (EDT:1y 71d 07:11:~~,EAT:1y 71d 07:12:~~) give me the following:

Better local minimum at the second location is probably right. Unfortunately, I can't replicate this one either. I think a full system restart is best practice after installing any new KSPTOT.

3.1 Plot tip box:

Have you tried clicking and dragging the tip box in the plot window?

Color me blonde.

3.2 Transfer Duration:

Sure, don't see why not. It's another two lines of code.

Thank you. While you are in there, could you swap the locations of Orbit Normal Delta-V (drop the 'Orbit' part it's distracting) and Radial Delta-V. Making the Departure Information - DV Maneuver Information window flow with MechJeb (Ordered: Prograde, Radial, Normal)? Can't tell you how many times I've entered Normal from you as Radial in MJ and vice versa.

3.3 Output Log:

Better logging is something I keep meaning to do and keep putting off because it's tedious. But yes, some day.

Duly noted. I'll make a calendar entry to pummel you next year.

Good News:

I now have:

Moho1 in a stable orbit.

Dres1 is on it's way.

Eve1 is ready for launch.

THANK YOU ARROWSTAR

[TranceaddicT]

Arrowstar,

One more thing, I agree with diomedea about the versioning thing. I'd recommend going to a 4-digit sequencing: ##.##.##.####. This will eliminate someone wondering if they have the "latest'n'greatest" and allow you more freedom with your revisions.

[Arrowstar]

2.2 Entering the Earliest X Time: The enter-key does not function; you must click 'OK'.

Yes, that box. Right-click EDT gets menu: Enter UT as Date/Time -or- Get UT from KSP. Select Enter UT as Date/Time. Enter values and hit enter-key. Result: input not accepted. Click 'OK'; result: input accepted.

So I coded up a blurb that allows you to hit enter and close the dialog box. To be honest, I don't think there was ever any expectation that the program should work that way, but I'm all for shortcuts, so there it is. It'll be in v0.12.3.

3.2 Transfer Duration:

Sure, don't see why not. It's another two lines of code.

Thank you. While you are in there, could you swap the locations of Orbit Normal Delta-V (drop the 'Orbit' part it's distracting) and Radial Delta-V. Making the Departure Information - DV Maneuver Information window flow with MechJeb (Ordered: Prograde, Radial, Normal)? Can't tell you how many times I've entered Normal from you as Radial in MJ and vice versa.

Transfer Duration added.

I won't be changing the order of the delta-v components, though. In fact, I already changed them in the last build! My personal preference, along with the preference of the author of PreciseNode, is to go P-N-R. I realize that MechJeb goes P-R-N, but I have to conform to one standard and if I have to support one of two competing node editors, I may as well go with the convention I like more. Want me to talk to R4m0n and see if he'll change his program?

3.3 Output Log:

Better logging is something I keep meaning to do and keep putting off because it's tedious. But yes, some day.

Duly noted. I'll make a calendar entry to pummel you next year.

Sounds good! I look forward to your pestering.

Good News:

I now have:

Moho1 in a stable orbit.

Dres1 is on it's way.

Eve1 is ready for launch.

THANK YOU ARROWSTAR

You're welcome. And: Woo! Nice work! Feel free to post screenshots, and if you put them anywhere else on the forum or wider KSP community, be sure to tell folks how you did it. Thanks!

[Arrowstar]

Arrowstar,

One more thing, I agree with diomedea about the versioning thing. I'd recommend going to a 4-digit sequencing: ##.##.##.####. This will eliminate someone wondering if they have the "latest'n'greatest" and allow you more freedom with your revisions.

Yeah, in the future, if I need to, I'll go to a 4 number scheme. For now, though, v0.12.3 will encompass all the fixes to date.

[Arrowstar]

Actually, my goal is multi flybys, really looking at a possibility to plan a Voyager-like mission. Glad to know you already considered that, if that's beyond a normal CPU capabilities no reason to deal with that.

Anyway, I never tried even the single flyby sequencer till today. Another of the goodies of KSP TOT still unknown to me. Running parallel processes and using some math libraries never called before, and still taking a lot to compute on my PC (about 30 minutes to complete the example Kerbin-Duna-Jool flyby; but then tried other scenarios like Kerbin-Eve-Duna, Kerbin-Eve-Jool, and it took just few minutes).

That is making me think what could be wrong with my simplistic approach. Even if not perfect, trying to match dates for each flyby (arrival and departure transfers) should give at least a raw solution, then to be refined tweaking periapsis at each flyby so to make the orbits match (if at all possible; if not, I would just check with another match of dates). A better mathematical approach would probably consider what are the different angles at arrival and departure with each flyby, compute the energy required to change orbits and find how much of that energy can be obtained by gravity assist. It shows I am not an astrodynamicist, glad if you could point at what inconsistencies are in my procedure , but please don't lose your time if it takes too much.

I'm going to retract my statement regarding difficulty, CPU time, and the sort... for now. Allow me to tell you what went through my head as I thought about this today when I should have been working on the analysis I'm in the middle of at work. It went something like this:

1. "Too expensive, can't be done in a timely manner on a desktop PC."
   
2. "...well. What if I vectorized the objective function?"
   
3. "Yes! I bet that would speed it up by at least 100x and I might get the necessary performance of that. Cool!"
   
4. "...drat. That means I would need a vectorized Lambert solver (which I don't have) and a vectorized perigee dv algorithm (also don't have). Maybe not."
   
5. "Unless I wrote my own vectorized Lambert solver. That could be fun..."
   

So anyway, in short, I may just tackle this to see if I can't solve the problem of doing multi-body gravity assists quickly using a vectorized Lambert solver. To get it to work, I'll need to do the following first:

• Write a vectorized Lambert solver in MATLAB. I have a Lambert solver based on Battin's method already, so I'll just take that and try to vectorize it.
  
• Write the perigee dv algorithm as a vectorized function.
  
• Easy stuff: write the objective function with the first two items. Test new objective function for speed.
  
• Do the GUI for a new tool.
  

I admit, I've not tried to vectorized any Lambert code yet. But I have vectorized element conversion code now and a vectorized Kepler solver now (all of which I wrote), so if I can pull those off, maybe I can pull this off. I'm not going to make any promises, though: multi-body gravity assist is probably the most challenging problem in two-body astrodynamics (in terms of CPU time and effort), so results are not guaranteed. If it works, though, we'll call it KSPTOT v0.13. Give me a few weeks...

[Arrowstar]

Hi all,

I'm pleased to announce the release of KSPTOT v0.12.3. I know I said I was going to release it this weekend, but some plans came up and I decided to push what I have now instead of making people wait another week and a half.

Some thanks are in order for this release:

• TranceaddicT, for help with bugs and improvements to the main KSPTOT porkchop plot functionality,
  
• voneiden, for help with bug fixes and improvements to Mission Architect and (frankly) lots of other KSPTOT tools,
  
• krmcginnis, for help with a bug fix or two, and
  
• diomedea, for pushing for this discrete release instead of just calling it another patch.
  

Change log (much abbreviated, given that there's a lot of little things):

• Two new constraints in Mission Architect:
  
  • Altitude of periapsis
    
  • Altitude of apoapsis
    

  [*]Bug fix to graphical analysis' text output when mission plan had not yet been saved

  [*]Major change to MA constraint system (now possible to change assigned event after creating constraint)

  [*]Bug fixes to KSPTOT main functionality, flyby maneuver sequencer, and in other places

  [*]Bug fixes to Mission Architect

That should be it. Get it while it's hot using the usual download link.

Please let me know if you find any issues or bugs, whether new or old. Thanks!

[Galane]

So I coded up a blurb that allows you to hit enter and close the dialog box. To be honest, I don't think there was ever any expectation that the program should work that way, but I'm all for shortcuts, so there it is. It'll be in v0.12.3.

Long time GUI programming convention to have the most commonly used dialog box button pre-selected so that hitting Enter or Return triggers it. Also just as long time a convention on Windows (and possibly other OSes) to have the Enter trigger movable with Tab - and on Macintosh to NOT have it movable.

See also radio buttons (round, only one per group selectable) and checkboxes (square, any or all in a group selectable).

Just some of those "It's always been done that way." things which many people, especially ones who have used computers with GUIs for years, fuss about when some software doesn't follow convention.