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

[Gilph]

On ‎1‎/‎15‎/‎2017 at 8:48 PM, Gilph said:

Yep...Rendezvous Maneuver to the rescue, again.

To keep it simple, I launched the relay and just snuck it out of Kerbin SOI, so it was just next to it in a solar orbit. Imported that into RMP and picked Kerbin as the destination.  Changed the Mean Anomaly at the destination until I got the spacing i wanted.  It was a 760 ms burn, and a slightly larger one 1Y80D later.  Thanks again.

 

On ‎1‎/‎15‎/‎2017 at 8:50 PM, Arrowstar said:

No problem!  Glad you got it to work!  Sometimes the simple tools are the best ones when there's a tool exactly designed for the problem you're trying to solve.

Remember this question?  I just completed the second burn to put in back in the same solar orbit path as Kerbin.  The difference between Kerbin orbit and the relay? Less than 2000 meters. Pretty amazing tool.

[Arrowstar]

4 minutes ago, Gilph said:

 

Remember this question?  I just completed the second burn to put in back in the same solar orbit path as Kerbin.  The difference between Kerbin orbit and the relay? Less than 2000 meters. Pretty amazing tool.

Great!  That sounds like amazing maneuver execution too, so nice work. Glad KSPTOT could be of help!

[Noobton]

Hi @Arrowstar this looks great, but the package is not available, could you upload it again, please?

[Arrowstar]

28 minutes ago, Noobton said:

Hi @Arrowstar this looks great, but the package is not available, could you upload it again, please?

Oh bigger, Dropbox finally changed their public folder permissions like they've been talking about forever. Okay, I'll fix it tomorrow. Thanks for the heads up! :-) 

[Arrowstar]

18 hours ago, Noobton said:

Hi @Arrowstar this looks great, but the package is not available, could you upload it again, please?

Okay, I've moved the download links for the KSPTOT packages (Windows and the outdated OSX) to Google Drive and made them accessible to the public for viewing and download.  The first post in this thread has been updated with the new links in the appropriate part of the instructions.  Please let me know if it works or not.  Thanks!

[Noobton]

15 minutes ago, Arrowstar said:

Okay, I've moved the download links for the KSPTOT packages (Windows and the outdated OSX) to Google Drive and made them accessible to the public for viewing and download.  The first post in this thread has been updated with the new links in the appropriate part of the instructions.  Please let me know if it works or not.  Thanks!

I got it, thanks!

[Arrowstar]

On 2/25/2017 at 9:50 PM, Drew Kerman said:

got another interesting trajectory for you to look at when you have a minute @Arrowstar. Still on v1.5.6 w/ KSP v1.1.3 - hitormiss.zip

Found another one, but I don't think this is a bug since it shows up in the game like this too in the Tracking Station until I click on it and it shows an SOI escape. Weird! How can it come up with a closed orbit? - waaaayout.zip

If you add a Coast to Next SOI event and then a Coast to PE event (no target body) you'll see the asteroid swing by Kerbin

If you delete those events and add just a Coast to PE event (no target body), you'll see the asteroid impact Kerbin

Issue is resolved for next release.

[Drew Kerman]

3 hours ago, Arrowstar said:

Issue is resolved for next release.

You say "issue" but I uploaded two mission files. They seemed to me to be separate issues but were they both resolved with one fix? Was one of them not really an issue? Heh, sorry, I'm grateful for the fix but still want more info!

[Arrowstar]

2 minutes ago, Drew Kerman said:

You say "issue" but I uploaded two mission files. They seemed to me to be separate issues but were they both resolved with one fix? Was one of them not really an issue? Heh, sorry, I'm grateful for the fix but still want more info!

I believe so, but you can tell me for sure.  Here's a pre-release of the next release... it basically just contains this fix, plus one "top secret" feature for 1.5.7.  When/if you find it, please don't spoil it.

In case you're curious, the issue had to do with the way that SoI transitions were being checked.  Essentially I create a list of time spans that could have an SoI transition in them and then check each one.  However, if that list isn't in chronological order, sometimes an earlier SoI transition can be get missed and replaced with a later potential one.  Basically I just had to sort of the list.

[Drew Kerman]

hrrmmm nothing obvious jumped out at me no time to go hunting tonight either.

Seems like waaaayout.zip is still showing a closed orbit way outside of Kerbin's SOI. Like I said, it did this in the game too, but is it at all possible to chop the rendering of the orbit so you only see what's in the SOI sphere? Otherwise you end up with this huuuuuuuge orbit that disrupts the entire scale of the plot and you have to zoom way in to see orbits within the SOI and they are cut off before you get too close because the plot is rendered thinly due to the extended orbit

[Arrowstar]

21 minutes ago, Drew Kerman said:

hrrmmm nothing obvious jumped out at me no time to go hunting tonight either.

Seems like waaaayout.zip is still showing a closed orbit way outside of Kerbin's SOI. Like I said, it did this in the game too, but is it at all possible to chop the rendering of the orbit so you only see what's in the SOI sphere? Otherwise you end up with this huuuuuuuge orbit that disrupts the entire scale of the plot and you have to zoom way in to see orbits within the SOI and they are cut off before you get too close because the plot is rendered thinly due to the extended orbit

So I don't see what you're seeing.  The orbit looks fine to me actually.

http://imgur.com/a/SEv8V

What are you seeing?

[Drew Kerman]

1 minute ago, Arrowstar said:

So I don't see what you're seeing.  The orbit looks fine to me actually.

DERP!! I forgot to note that the orbit only shows up when inserted as another spacecraft - so click to show other S.C. orbits.

Also found something new, but I could only guess what its for so no worries about a reveal from me

[Arrowstar]

1 minute ago, Drew Kerman said:

DERP!! I forgot to note that the orbit only shows up when inserted as another spacecraft - so click to show other S.C. orbits.

Well, as I note in the Other Spacecraft box, "Other Spacecraft" do not consider SoI transitions.  So if you start their orbit way out there, then that's where they'll be.  The reason for this is simply due to the CPU time it takes to find SoI transitions.  I suppose it could be done, of course, but it's generally not worth slowing down the simulation for.

[Drew Kerman]

5 minutes ago, Arrowstar said:

Well, as I note in the Other Spacecraft box, "Other Spacecraft" do not consider SoI transitions.  So if you start their orbit way out there, then that's where they'll be.  The reason for this is simply due to the CPU time it takes to find SoI transitions.  I suppose it could be done, of course, but it's generally not worth slowing down the simulation for.

fair enough. It's just that I saw it look that way in the game as well so I was puzzled as to what was happening here. Totally never read that warning, or if I did it was once and I since forgot :P. Still, handles most orbits fine so thought this one was a bug. Here's an example of all the asteroids that were tracked passing Kerbin last month in my role play:

So normally in the case of orbits that close (some of those do show up as just arcs not ellipses) I just show the SOI border and zoom in to cut them off, but in the unique case of that huuuuuge orbit it completely skews the render so when I zoom in the resulting view is too narrow. I'll just leave it out of this month's roundup...

Edited March 18, 2017 by Drew Kerman

[Arrowstar]

I'll just leave this here...

[Drew Kerman]

Ah, so that's what the "nbody" stood for. I saw it but wasn't sure if it was for m-body orbital physics or if it was for some sort of maneuver that propagated through multiple SOIs

So is this directly related to the Principia mod? Because without that I can't see the point of it... unless you're working on your own n-body plugin?

Anyways I'm here with another issue. Reading from an SFS file (Ast. DGU-266 is the vessel), Mission Architect isn't showing a Mun encounter until Day 342 (set the coast revs to 100) but the game is currently at Day 213 and I have a Mun encounter coming up (for this day):

tested in both the last 1.5.6 release and the pre-release you just posted

[Arrowstar]

9 hours ago, Drew Kerman said:

Ah, so that's what the "nbody" stood for. I saw it but wasn't sure if it was for m-body orbital physics or if it was for some sort of maneuver that propagated through multiple SOIs

So is this directly related to the Principia mod? Because without that I can't see the point of it... unless you're working on your own n-body plugin?

Anyways I'm here with another issue. Reading from an SFS file (Ast. DGU-266 is the vessel), Mission Architect isn't showing a Mun encounter until Day 342 (set the coast revs to 100) but the game is currently at Day 213 and I have a Mun encounter coming up (for this day):

tested in both the last 1.5.6 release and the pre-release you just posted

Yes, I intend for it to be used with Principia.  I've had some requests for N-Body simulation in the past, and I had a free weekend so I thought I would investigate it.

I took a look at your SFS file and propagated the orbit out to the time you have shown on your KAC window.  I actually don't show an encounter there when I look at the distance between the asteroid and the Mun.  The Mun SoI radius is ~2400 km and the closest approach I see is ~2767 km. 

Could you try pulling the orbit from KSP using KSPTOTConnect instead?  I'd like to see if there's a difference in the orbit being imported maybe.  The code that finds SoI transitions isn't missing anything because nothing gets close enough to your asteroid to trigger that.  That implies that maybe the imported orbit is suspect.

[Drew Kerman]

On 3/19/2017 at 10:06 AM, Arrowstar said:

I took a look at your SFS file and propagated the orbit out to the time you have shown on your KAC window.  I actually don't show an encounter there when I look at the distance between the asteroid and the Mun.  The Mun SoI radius is ~2400 km and the closest approach I see is ~2767 km. 

Could you try pulling the orbit from KSP using KSPTOTConnect instead?  I'd like to see if there's a difference in the orbit being imported maybe.  The code that finds SoI transitions isn't missing anything because nothing gets close enough to your asteroid to trigger that.  That implies that maybe the imported orbit is suspect.

Ok I did a in-game import from a time shortly prior to what was shown in the screenshot before the game displayed a Mun intercept and with that data Mission Architect was able to plot a proper intercept. I don't know if the MA file will help but here it is anyways. Seems something might indeed be off with the SFS import

[Arrowstar]

2 hours ago, Drew Kerman said:

Ok I did a in-game import from a time shortly prior to what was shown in the screenshot before the game displayed a Mun intercept and with that data Mission Architect was able to plot a proper intercept. I don't know if the MA file will help but here it is anyways. Seems something might indeed be off with the SFS import

Can you try to do an import from SFS and an import from KSPTOTConnect on the same spacecraft and see how the orbits are different for me?

[Drew Kerman]

3 hours ago, Arrowstar said:

Can you try to do an import from SFS and an import from KSPTOTConnect on the same spacecraft and see how the orbits are different for me?

ok redownload the link from the last post, it now contains a mission file with an import from the game while under time acceleration and a save file (persistent.sfs) you can import data from. That save file is from after exiting to the space center without dropping time warp. However if you import the data from the save file you get an intercept as in the game. So I've included also the original save file with the problem orbit (persistent - No SOI Hit.sfs).

To be clear you should be able to see the same results as the following:

1. Import DGU-266 from "persistent - No SOI Hit.sfs" and see no SOI hit within default search revs
2. Open "ImportMunSOI.mat" and see a Mun intercept - this is using data imported from the game after it was loaded using the "persistent - No SOI Hit.sfs" file (this a point in the game just a few hours before the screenshot I posted earlier, so the Tracking Station does not show an intercept with Mun, the asteroid still needs to progress a bit farther in its orbit first)
3. Import data from "persistent.sfs" and still see a Mun intercept. This is the save file updated after returning to the tracking station from step 2.

So again, the only place the problem persists is from the "persistent - No SOI Hit.sfs" import. It's worth noting again also that the Tracking Station doesn't show the Mun intercept until a certain point, since it only seems to look one orbit ahead, so internally it may be doing some updating of the orbital parameters and the SFS file orbital data may be old enough that the propagation done by MA becomes inaccurate. I have seen inaccuracies arise over time between the game and my Flight Tracker. So if I'm using data timestamped a few weeks old and the game is using the same timestamped data in its save file, my Flight Tracker will show the craft in a slightly different position than the Tracking Station does in the game. I haven't really investigated this, just made sure to update the orbit data more often

Edited March 21, 2017 by Drew Kerman

[Snoman314]

15 hours ago, Arrowstar said:

Can you try to do an import from SFS and an import from KSPTOTConnect on the same spacecraft and see how the orbits are different for me?

That's strange, as I get the opposite problem: SFS import is fine, but plugin import has me in the wrong place.

[Arrowstar]

2 hours ago, Snoman314 said:

That's strange, as I get the opposite problem: SFS import is fine, but plugin import has me in the wrong place.

That's very weird. The plugin import should be very accurate as it's pulling directly from the internal KSP orbits in memory. Do you have an examples I could see?

[Snoman314]

Nothing besides what I said here:

Next time I'm using KSPTOT I'll try both methods, and try and get a quicksave where it happens.

[Arrowstar]

2 hours ago, Snoman314 said:

Nothing besides what I said here:

Next time I'm using KSPTOT I'll try both methods, and try and get a quicksave where it happens.

Thanks, please do!

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

Alrighty, everyone, here is the second prerelease for the upcoming version of KSPTOT v1.5.7.

This pre-release features a new type of coast in Mission Architect that uses N-body propagation to determine the orbit instead of the analytical two-body solution.  It can be accessed by adding a "N-Body Coast" event to the mission script.  This new coast type is extremely experimental at the moment and should be used with caution.  This means setting the "maximum propagation time" field to something reasonable and allowing more time than usual for mission scripts to execute.  The goal in having this coast type is to allow for Principia compatibility.

If you find any bugs, and you will find bugs, please let me know in this thread.  Thanks, and happy orbiting!

Edited March 21, 2017 by Arrowstar

[Drew Kerman]

Finally ready to migrate to v1.2.2! So now using the pre-release more often and can finally report this issue I noticed a while ago but on the older releases so had to wait to see if it had been fixed in the recent one... I get this error after startup when I try to launch the application from the Start menu (have it pinned there):

But when I start by just dbl-clicking the EXE, it loads fine.