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

[Drew Kerman]

Can't try till home sometime this weekend, but any thoughts on my other comments from my last post?

[Arrowstar]

On 6/12/2016 at 10:18 PM, Gaiiden said:

hey how's this sound for a good rule of thumb for transfer length max bounds in the MFMS? Run the porkchop plotter from the target to the destination of the leg and then double the number of days it gives you for the best transfer?

aaaand to make my earlier request slightly more complicated I just realized it might be worth including a third best solution - excess hyperbolic velocity. This would be in the event that you want the probe to stay at the final target, the lower the better.

Is there a situation other than flying into a planet that would cause the "Solution shown may not be feasible - please try again" warning to show up? Because otherwise it should probably be a bit more pointed of an error message. It made me initially assume I could massage these values in Mission Architect but I'm not sure that would indeed be a wise idea when one of my trajectories takes me straight through the center of a planet. I think this warning would be more appropriate for when I get a really close flyby, like a few km into the surface or atmo that could possibly be adjusted in MA

Allllso I really like the Global View of trajectories that the MFMS generates. Would it be possible for MA to generate a view like that as well?

1. That sounds reasonable for the upper bound, yes.  Maybe that same technique but divided by 2 or 4 for the lower bound.  Honestly, you just kinda need to play with these numbers to get a sense for what is resonable - experience will trump everything else here sadly.
2. So I really don't want to start returning solutions that are not the DV optimal solution to your problem.  Part of the usefulness of the way things are set up now is ease of use, and most people think "optimal = less DV".  Presenting a time optimal solution or a "excess velocity" optimal solution is theoretically possible but would make the application harder to use for most people.
3. Yes, there is.  The other possibility is that the lambert solver or departure orbit analysis code won't be able to find a solution for whatever reason, and that would trigger that message too.
4. I suppose MA could generate a plot like that in the Tools menu, but I actually don't see the use case.  Could you describe why you like it?

Edited June 16, 2016 by Arrowstar

[Drew Kerman]

Good answers, thx. I like the overview plot because it's a really great way to show ppl what your mission will accomplish overall. For me, this is for sharing with my KSA audience but in general anyone can say to anyone else "hey look at where my probe is going!"

soooo... Yea I would call this a low-priority request. I only made it cause I hoped it would be relatively easy to adapt the code from the MFMS to MA. But if not I could make the diagram myself

oh yea forgot to check the link - glad to hear Saffire went well good luck with the deorbit ops!

[phoenix_ca]

13 hours ago, Arrowstar said:

So, thoughts on that last pre-release?  Everything working for everyone?  Is the coast mass loss functionality easy to use and understand?

Btw, apologies on not being around much the last few days here, I actually have a real bird to fly atm lol.

It's okay. I have work too. Though it's not nearly as exciting as that.

[Arrowstar]

Has anyone had a chance to try out KSPTOTConnect with KSP v1.1.3?

[Drew Kerman]

4 hours ago, Arrowstar said:

Has anyone had a chance to try out KSPTOTConnect with KSP v1.1.3?

Almost everything appears to be in working order (didn't fully test accuracy of info imported but it all was imported without any error msgs) - body file generated, maneuver exported, orbit data imported to MA. The only problem I saw was the real-time data system. It connected and showed a proper clock but no data was updated or set in any of the windows

Edited June 23, 2016 by Gaiiden

[Arrowstar]

21 hours ago, Gaiiden said:

Almost everything appears to be in working order (didn't fully test accuracy of info imported but it all was imported without any error msgs) - body file generated, maneuver exported, orbit data imported to MA. The only problem I saw was the real-time data system. It connected and showed a proper clock but no data was updated or set in any of the windows

Okay, thanks for reporting!

[Ksp Slingshooter]

Is it necessary to install matlab compiler runtime 2015 or can we install the latest release to run this version of kerbal tot?

[Drew Kerman]

matlab is a requirement that needs to be installed. But once you install the version specified in the OP then you only need to update KSPTOT if Arrowstar pushes new releases of the program. He'll let us know when the matlab runtime needs to be updated as well

[Arrowstar]

As further commentary to Gaiiden's comment: You need EITHER the MCR or the full MATLAB install of the version I specify.  So if you own MATLAB 2015b with the necessary toolboxes, then you don't need the MCR.

[Ksp Slingshooter]

Thanks for the explanation 

So, I already gave it a try and it certainly looks pretty interesting, although a bit difficult to understand at first but I believe I'll fully with some more practice.

Nice work and thanks for the mod, Arrowstar!

Edited June 26, 2016 by Ksp Slingshooter

[Stract]

Hi everyone and many thanks to the author for this incredible tool. It opened a huge terra incognita in KSP for me. Now I'm still trying to learn how to work with it but I hope I've understand at least the very basics of mission architect. I spent the whole day just playing TOT without even running the game itself, just trying to build the flight plan of my dream but I faced a small problem when I tried to perform it in actual game. Excuse me if the answer is already in this topic. I'll be very grateful if somebody will forward me to this answer then.

So the problem is the following. I've created the flight plan in RSS, flight to Saturn with gravity assist near Jupiter. The launch and escape burn were more or less fine and now, after a couple of small trajectory corrections, my space station is on the Sun orbit forward to Jupiter. I decided to check if my actual orbit is good enough, so I imported my current orbit parameters as new initial state into mission architect (not manually, just right-clicking and choosing the option "get orbit from KSP). The thing is mission architect shows everything is perfect. But when I compared the parameters of expected  hyperbolic orbit near Jupiter in mission architect and in the game, I've noticed they are not perfectly the same, though they are close. The game shows my periapsis near Jupiter will be about 5600000 km, while TOT says it is near 4000000 km. Of course my planned burn at Jupiter periapsis will not work because of this difference. I tried to upload this maneuver into the game and, as expected, the resulting orbit didn't pass anywhere near Saturn. Maybe it is not really big problem, I can slightly ajust my orbit manually to make it closer to what mission architect wants. But still it is the thing better to avoid. So can TOT calculations diverge from the game (without any delta-v maneuvers planned), especially across the SOI transitions, even if I input the initial state directly from the game? Or it is just I did something wrong?

Thanks again for this tool, it brings a new life in game for me

[Arrowstar]

On 6/27/2016 at 7:14 AM, Stract said:

Hi everyone and many thanks to the author for this incredible tool. It opened a huge terra incognita in KSP for me. Now I'm still trying to learn how to work with it but I hope I've understand at least the very basics of mission architect. I spent the whole day just playing TOT without even running the game itself, just trying to build the flight plan of my dream but I faced a small problem when I tried to perform it in actual game. Excuse me if the answer is already in this topic. I'll be very grateful if somebody will forward me to this answer then.

So the problem is the following. I've created the flight plan in RSS, flight to Saturn with gravity assist near Jupiter. The launch and escape burn were more or less fine and now, after a couple of small trajectory corrections, my space station is on the Sun orbit forward to Jupiter. I decided to check if my actual orbit is good enough, so I imported my current orbit parameters as new initial state into mission architect (not manually, just right-clicking and choosing the option "get orbit from KSP). The thing is mission architect shows everything is perfect. But when I compared the parameters of expected  hyperbolic orbit near Jupiter in mission architect and in the game, I've noticed they are not perfectly the same, though they are close. The game shows my periapsis near Jupiter will be about 5600000 km, while TOT says it is near 4000000 km. Of course my planned burn at Jupiter periapsis will not work because of this difference. I tried to upload this maneuver into the game and, as expected, the resulting orbit didn't pass anywhere near Saturn. Maybe it is not really big problem, I can slightly ajust my orbit manually to make it closer to what mission architect wants. But still it is the thing better to avoid. So can TOT calculations diverge from the game (without any delta-v maneuvers planned), especially across the SOI transitions, even if I input the initial state directly from the game? Or it is just I did something wrong?

Thanks again for this tool, it brings a new life in game for me

Thanks, glad you're enjoying it.  There always seems to be some kind of issue between RSS and KSPTOT.  To be honest, I'm not entirely sure what it is, but lots of people have reported something similar.  I've never really used RSS/RO, so I'm a bit perplexed myself.  Have you made any progress since posting?

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

Hi everyone,

This afternoon I'm making available pre-release 4 of KSP Trajectory Optimization Tool v1.5.5.  There is only one major change between this version and the previous pre-release:

• Added function to Mission Architect to create a "trajectory map" similar to what MFMS outputs (Tools -> Create Trajectory Map)

Thanks to @Gaiiden for the feature request.

Download link is here: https://dl.dropboxusercontent.com/u/29126891/KSPTOT_v155_prerelease4.zip

As usual, feedback, comments, and questions are welcome!  Thanks.

Edited July 2, 2016 by Arrowstar

[rasta013]

I'm away from my KSP this weekend but had a thought about KSPTOT and my setup and was wondering since I can't test it myself right now...

I run Real Atmospheres which changes the profile of pretty much every planet that has an atmosphere.  Kerbin is a notable exception in that the changes are mainly in the temperature gradients model but for places like Laythe or Jool they are now vastly different.  Will KSPTOT pick these changes up automatically when it generates a bodies.ini file for my OPM install or will I need to go back through and manually update the atmospheric values for each body?  If no one knows then I'll be the guinea pig and do some rather extensive testing with it when I get home...

[Stract]

10 hours ago, Arrowstar said:

Thanks, glad you're enjoying it.  There always seems to be some kind of issue between RSS and KSPTOT.  To be honest, I'm not entirely sure what it is, but lots of people have reported something similar.  I've never really used RSS/RO, so I'm a bit perplexed myself.  Have you made any progress since posting?

Thanks for the answer, Arrowstar!

Not really, the problem is still there. I've just made the following: I have a probe on Sun orbit which is going to enter Mars SOI. I created a new mission plan in architect, then import the initial state from KSP active vessel and created a coast to Mars Periapsis. Then I copied the final state parameters from TOT, fast forwarded the game until the SOI transition and compared these parameters with MechJeb. The results are shown on screenshots below.

Spoiler

Same thing for Jupiter

Spoiler

As you can see, the orbital parameters are not exactly the same, which complicated things if I have a mission plan with gravity assists.

Edited July 3, 2016 by Stract

[jakkarth]

Hello, Arrowstar! When doing some research on gravity assists in KSP I came across your tool, and I must say it looks absolutely amazing. The two included PDF tutorials are great for describing the functions of the tools, especially Mission Architect, and their intended uses. At this point I have worked my way through the two PDF tutorials plus the one in this thread linked in the first post, and I have read through the first 23 pages of this thread. As an idea of how familiar I am with orbital mechanics, I find myself having to look up how to spell Hohmann, ie very little to speak of. I apologize if I've overlooked the solutions to the problem I describe below, and would be grateful for a nudge towards more information. I have some feedback to offer from the eyes of a new user who is familiar with computer science but not much with orbital mechanics, if that would be welcome.

However, before I can provide that, I'd like to make sure I actually understand what it is I'm supposed to be doing, and I'll admit that my ignorance of the math involved here appears to be seriously hampering my ability to meet with success while using KSPTOT. After an initial 2 hours of getting familiar with the tool's components and trying to get information into and out of KSP, I started working through the Kerbin to Lathe tutorial. It took my 4 hours to complete. The Solar System Edge tutorial, while admittedly more complex, took me 10 frustrating hours of trial and error and rerunning identical optimization steps to get through (final optimization attempt to reach Plock SoI took over 2 hours, not counted in the 10, during which I had dinner). I decided from there to attempt my own similar mission, doing a Jool assist to reach Sarnus and Urlum. I'm 8 hours into this one and I haven't left Jool yet in MA. I haven't tried any of this mission in KSP yet.

My problems seem to center around the optimizer not being able to find the solutions I am expecting it to. This is undoubtedly due to my lack of understanding, so I am hoping you can find the flaw in my process. I first open the Mutli-Flyby Maneuver Sequencer and choose the appropriate bodies. It runs through its calculations. I have gotten anywhere from 1500 to 5500m/s solutions. While I understand that there's some randomness involved and that these burns are just a starting point for MA, I still find that to be a very large variance, and I'm afraid this may be the beginnings of my problem.

From there, I set my initial state in MA to be identical to the parking orbit I used in MFMS (I tried the tutorial's suggestion of an optimized parking orbit that only requires prograde as well, same problems encountered). I orbit to true anomaly with -180 to 360 optimization and an initial guess provided by MFMS. I add the ejection burn MFMS provides with some variance in optimization on all three components. I add an SoI coast followed by a coast to Jool periapsis. The final state sometimes shows me in Mun SoI, sometimes in Sun, but never at Jool where I would have hoped to be given the identical parameters to MFMS. But fine, MFMS is just an approximation, I forge ahead. Next comes optimization.

At this point I hopefully haven't screwed anything up too badly. I run the initial pass to land within Jool's SoI successfully. Then I add the Central Body and UT constraints, which take some effort to satisfy by eventually they work out. Then I add Inclination, RAAN and Arg of Peri constraints, giving each of them a wider range than the tutorial suggests is appropriate. This is typically where things start to go wrong in earnest. The optimizer chugs away, and as it goes along the constraint violations go up up up and the radius of periapsis goes up up up. Eventually it gives up much worse off than it started. Sometimes it will show the initial state, think for a while, and then declare that it has finished with no iterations completed. Sometimes it will find a solution better than the one it started with, then wander off again, and clicking Accept ends up applying the last result found instead of the best (both in terms of the objective function and the constraint violations), which I find extremely non-intuitive. The tutorials don't really cover what to do if the constraints aren't satisfied or if the radius can't be brought under control; changing the optimization function around and possibly ignoring some of the constraint problems doesn't seem to help in this case.

Because I can't get the constraints satisfied with anything resembling a low radius of periapsis at Jool, my attempts to flounder around making a burn at Jool to correct the problem and still get to Sarnus all fail miserabily as the dV required continues to skyrocket.

I hope the descriptions of my difficulties are sufficient to send some guidance my way. I've included a link to some screenshots plus the MA file I saved and whatever logs I could find. Please let me know if there's anything additional I can provide.

Screenshots and .MAT file.

Please do not take any of the above as criticism of your work. From what I can tell the tool itself is fantastic and working as intended; I simply do not know how to wield it yet. I very much appreciate your continued work on this project and I look forward to planning some awesome missions with it.

Edited July 3, 2016 by jakkarth

[Arrowstar]

1 hour ago, jakkarth said:

At this point I hopefully haven't screwed anything up too badly. I run the initial pass to land within Jool's SoI successfully. Then I add the Central Body and UT constraints, which take some effort to satisfy by eventually they work out. Then I add Inclination, RAAN and Arg of Peri constraints, giving each of them a wider range than the tutorial suggests is appropriate. This is typically where things start to go wrong in earnest. The optimizer chugs away, and as it goes along the constraint violations go up up up and the radius of periapsis goes up up up. Eventually it gives up much worse off than it started. Sometimes it will show the initial state, think for a while, and then declare that it has finished with no iterations completed. Sometimes it will find a solution better than the one it started with, then wander off again, and clicking Accept ends up applying the last result found instead of the best (both in terms of the objective function and the constraint violations), which I find extremely non-intuitive. The tutorials don't really cover what to do if the constraints aren't satisfied or if the radius can't be brought under control; changing the optimization function around and possibly ignoring some of the constraint problems doesn't seem to help in this case.

Because I can't get the constraints satisfied with anything resembling a low radius of periapsis at Jool, my attempts to flounder around making a burn at Jool to correct the problem and still get to Sarnus all fail miserabily as the dV required continues to skyrocket.

Okay, so this is the elephant in the room with optimizers: they are, fundamentally, dumb mathematical algorithms that simply do what they're told with no context to interpret what they're doing.  This is why they occasionally need hand-holding and tweaking.

My first thought is to eliminate the UT constraint after you've used it to reach Jool and subsequently add the Central Body constraint.  Could be that its prohibiting the optimizer from moving the way it wants to.

As far as the optimizer's constraint value going off to the moon: this happens sometimes.  The cause is that the problem space is, for some reason, not behaving the way the optimizer expects and every time it takes a move to shrink the constraint value, it ends up just doing damage to it instead.  This usually happens when the constraints behave in a highly nonlinear way, as the UT constraint can occasionally do.  Again, I would recommend removing that constraint after you no longer need it.

As far as not being able to achieve your target radius: it is possible, though unlikely, that the way the mission is set up may not allow that radius to be achieved in one go.  In that case, if you absolutely can't get it to do what you want, then you need to start thinking like an orbit analyst.  Try adding another set of maneuvers to your trajectory after you reach the best Jool periapsis you can muster and alter your orbit that way.  Or add a deep-space maneuver somewhere between Kerbin and Jool while in orbit around the Sun.  Or adjust your orbit around Kerbin.  There are lots of possibilities.

I'll take a look at your MAT file and see what I can come up with.  Let me know if you have any questions!

EDIT: Just took a look at the MAT file.  An observations: First, try enabling radial DV in your burn.  You have set to not-optimized right now.  While undesirable from an efficiency prospective, sometimes a small amount is necessary.  Try using +/- 100 m/s in the radial direction.

EDIT 2: Applying my tip in Edit 1 and attempting to sequentially satisfy the inclination, argument, and RAAN constraints in turn, I was able to achieve the inclination and argument of periapsis constraint.  RAAN is a bit of a sticky wicket though, I'm afraid.  Your best bet with this one is going to be either: open up your constraints as wide as you'll allow and accept what you can get, or put in a small, <25 m/s maneuver somewhere between Kebrin and Jool and see if adding another couple degrees of freedom to the problem gets everything working.  Let me know how it goes, and welcome to "real life" interplanetary mission design.

Edited July 3, 2016 by Arrowstar

[Arrowstar]

9 hours ago, rasta013 said:

I'm away from my KSP this weekend but had a thought about KSPTOT and my setup and was wondering since I can't test it myself right now...

I run Real Atmospheres which changes the profile of pretty much every planet that has an atmosphere.  Kerbin is a notable exception in that the changes are mainly in the temperature gradients model but for places like Laythe or Jool they are now vastly different.  Will KSPTOT pick these changes up automatically when it generates a bodies.ini file for my OPM install or will I need to go back through and manually update the atmospheric values for each body?  If no one knows then I'll be the guinea pig and do some rather extensive testing with it when I get home...

I've never used Real Atmospheres before, but by all means give it a whirl and report back with your results.  Thanks!

9 hours ago, Stract said:

Thanks for the answer, Arrowstar!

Not really, the problem is still there. I've just made the following: I have a probe on Sun orbit which is going to enter Mars SOI. I created a new mission plan in architect, then import the initial state from KSP active vessel and created a coast to Mars Periapsis. Then I copied the final state parameters from TOT, fast forwarded the game until the SOI transition and compared these parameters with MechJeb. The results are shown on screenshots below.

  Reveal hidden contents

Same thing for Jupiter

  Reveal hidden contents

As you can see, the orbital parameters are not exactly the same, which complicated things if I have a mission plan with gravity assists.

It does appear that something funny is going on.  Can you check the bodies.ini file you're using to make sure that everything contained in it (that is relevant to your mission design work) looks right?  I'm at a bit of a loss I'm afraid.

[jakkarth]

First please let me say that I am both honored and amazed by the quick and detailed reply. Even after seeing it over and over in this thread that spans years. Quite impressive

32 minutes ago, Arrowstar said:

As far as the optimizer's constraint value going off to the moon: this happens sometimes.  The cause is that the problem space is, for some reason, not behaving the way the optimizer expects and every time it takes a move to shrink the constraint value, it ends up just doing damage to it instead.  This usually happens when the constraints behave in a highly nonlinear way, as the UT constraint can occasionally do.  Again, I would recommend removing that constraint after you no longer need it.

This is the kind of insight I was hoping for. While I understand what the constraint means, in that I know what UT is and why it matters that I show up to Jool on time, I don't understand how the constraint affects the problem space the optimizer is working in. In the Solar System Edge tutorial, there's mention of having to live with some of the constraints not being fully satisfied. I guess I understand why that's the case, but having some explanation of why certain parameters are hard to constrain under which conditions would be very helpful to beginners such as myself. I'm still slightly confused on why I would no longer need it though. Since arriving at Jool on time is a requirement to maintain alignment for the subsequent targets, this seemed like one of the more important ones to maintain?

32 minutes ago, Arrowstar said:

EDIT: Just took a look at the MAT file.  An observations: First, try enabling radial DV in your burn.  You have set to not-optimized right now.  While undesirable from an efficiency prospective, sometimes a small amount is necessary.  Try using +/- 100 m/s in the radial direction.

I am removing the UT constraint and adding +/- 100m/s radial on the ejection burn. Result after attempting optimization twice so far is that the constraint violations are improving at the cost of radius of periapsis. Which again brings up the question, what's the important part here? Is it better to have the inclination on spec or keep the radius down to maximize the gravity assist effect? I don't have an instinctive guess on this.

32 minutes ago, Arrowstar said:

EDIT 2: Applying my tip in Edit 1 and attempting to sequentially satisfy the inclination, argument, and RAAN constraints in turn, I was able to achieve the inclination and argument of periapsis constraint.  RAAN is a bit of a sticky wicket though, I'm afraid.  Your best bet with this one is going to be either: open up your constraints as wide as you'll allow and accept what you can get, or put in a small, <25 m/s maneuver somewhere between Kebrin and Jool and see if adding another couple degrees of freedom to the problem gets everything working.  Let me know how it goes, and welcome to "real life" interplanetary mission design.

If I can't get it within my constraints and a reasonable radius with the first edit's adjustments in place, I'll attempt a mid-transit course correction burn. That wasn't covered in the tutorials I've read so far, but I assume it's as simple as inserting an extra coast between SoI escape of Kerbin and the Jool periapsis coast, using some UT value midway between departure and arrival times. I typically use one or more of these when doing direct transfers based on MechJeb's maneuver planner anyway.

Again, thank you for your quick and detailed response, it's invaluable to newbies such as myself! Would some observations about the interface from the eyes of a new user be valuable to you? I don't know the math so I can't contribute back in that way, but I've got a decade of building software and doing some interface designing. I just don't want it to be interpreted as a list of demands.  Thanks!

[jakkarth]

1 hour ago, Arrowstar said:

EDIT 2: Applying my tip in Edit 1 and attempting to sequentially satisfy the inclination, argument, and RAAN constraints in turn, I was able to achieve the inclination and argument of periapsis constraint.  RAAN is a bit of a sticky wicket though, I'm afraid.  Your best bet with this one is going to be either: open up your constraints as wide as you'll allow and accept what you can get, or put in a small, <25 m/s maneuver somewhere between Kebrin and Jool and see if adding another couple degrees of freedom to the problem gets everything working.  Let me know how it goes, and welcome to "real life" interplanetary mission design.

Alright, I got something fairly close, but I can't seem to get the periapsis out of the atmosphere now without wrecking everything, so I attempted to add a mid-transit correction burn in deep space. I added a coast to 135090396.539s and a dV maneuver at +/-25 with a guess of 0 for the three components. I disabled the opt? boxes on the other events, so only the mid-course correction could be adjusted by the optimizer. When I attempted to run it again, I got an error box:

"There was an error optimizing the mission script: Subscript indices must either be real positive integers or logicals."

Not sure what I did to cause this or how to fix it. There's also an error under the MA orbit display:

"Event 5: struct contents reference from a non-struct array object."

Log file

Edit: and now I can't edit the course correction event. The event editing window pops open for a split second, then closes with a ding. No additional errors on screen.

Edited July 3, 2016 by jakkarth

[Arrowstar]

1 minute ago, jakkarth said:

Alright, I got something fairly close, but I can't seem to get the periapsis out of the atmosphere now without wrecking everything, so I attempted to add a mid-transit correction burn in deep space. I added a coast to 135090396.539s and a dV maneuver at +/-25 with a guess of 0 for the three components. I disabled the opt? boxes on the other events, so only the mid-course correction could be adjusted by the optimizer. When I attempted to run it again, I got an error box:

"There was an error optimizing the mission script: Subscript indices must either be real positive integers or logicals."

Not sure what I did to cause this or how to fix it. There's also an error under the MA orbit display:

"Event 5: struct contents reference from a non-struct array object."

Log file

Try letting it optimize both the Kerbin departure burn and the midcourse burn at the same time.

As far as the error message goes, I've been tracking down the various causes of this bug for as long as Mission Architect has been around.  Can I see the MAT file at the point where you're getting the error?

[jakkarth]

5 minutes ago, Arrowstar said:

Try letting it optimize both the Kerbin departure burn and the midcourse burn at the same time.

I'm restarting the computer in question out of an abundance of caution. I will try this when it comes back up.

Quote

As far as the error message goes, I've been tracking down the various causes of this bug for as long as Mission Architect has been around.  Can I see the MAT file at the point where you're getting the error?

I was going to add the link to the .mat file in an edit to the post, but you're too fast for me

Edit: rebooted. Opened the same .mat file in above link. Red error message is already in the list, and still cannot edit the event.

Edit 2: I can delete the coast event referenced by the message, but when I recreate it the error returns. Steps to reproduce:

1. Load linked .mat file

2. Insert a coast between "Coast to Sun" and "Coast" (ie new event 5)

3. Set type to UT, UT value to 131365182.748s, uncheck opt?, save

4. Error reappears.

Edited July 3, 2016 by jakkarth

[Arrowstar]

5 minutes ago, jakkarth said:

I'm restarting the computer in question out of an abundance of caution. I will try this when it comes back up.

I was going to add the link to the .mat file in an edit to the post, but you're too fast for me

Found and fixed the bug.  I'm building v1.5.5 pre-release 5 with the fix in it.  Download and run this when I post it in 15-30 minutes.

[jakkarth]

Just now, Arrowstar said:

Found and fixed the bug.  I'm building v1.5.5 pre-release 5 with the fix in it.  Download and run this when I post it in 15-30 minutes.

Don't you have a life, some friends to set fireworks off with, etc? Instead you're here fixing bugs for me. What a guy  I'll buy you a beer next time you're in town.

[Arrowstar]

7 minutes ago, jakkarth said:

Don't you have a life, some friends to set fireworks off with, etc? Instead you're here fixing bugs for me. What a guy  I'll buy you a beer next time you're in town.

Haha, fireworks are tonight!   And I'm actually half taking care of my July budgeting and finances while I do this (or maybe I should say I'm taking care of this while doing my July budgeting lol), so it's a nice distraction.  Also I hate bugs.

EDIT: Right, here you are, KSP Trajectory Optimization Tool v1.5.5 pre-release 5.  Only change is bug fix noted above.  Download link: https://dl.dropboxusercontent.com/u/29126891/KSPTOT_v155_prerelease5.zip

Now back to looking at IRA contributions.

Edited July 3, 2016 by Arrowstar