Arrowstar

[WIN/MAC] KSP Trajectory Optimization Tool v1.5.7 [Launch, Landing, Docking!]

2533 posts in this topic

16 hours ago, Drew Kerman said:

Which makes me wonder what he's thinking of tackling next :P Arrowstar have you done any roadmapping for new features or enhanced implementation of existing ones? Or just going wherever your interest takes you when you have the time to work on things?

At the moment I don't actually have anything coming down the pipe, to be honest.  At this point, I usually look to user requests for ideas, since what you guys need and what I envision don't always line up perfectly. :)

Share this post


Link to post
Share on other sites

So, I'm getting a bug trying to load KSPTOT v1.5.7 (Windows 10, Core i5-6600K that I should really get around to overclocking someday).

On program start, it pops up an error message, saying this:

Reference to non-existent field ".
Error in => projectMain.m at line 49

The problem disappears if I delete appOptions.ini, which has these contents:

[ksptot]
bodiesinifile = C:\path\to\KSPTOT\Gal32.ini
rtsHostName = localhost
timeSystem = Earth

Of course, this means I have to delete appOptions.ini each time I load KSPTOT.

Otherwise, though: it's a wonderful tool that I'll have to learn how to use a bit better. I think I mostly have the hang of the multi-flyby sequencer*, and have found a Gael-Niven-Icarus path that saves a couple hundred m/sec off a direct Gael-Icarus transfer.

Granted, that's not much relative to the overall >17 km/sec cost of getting there and circularizing at 3.2x scale, but it's entirely plausible to me that's mostly on account of astrodynamics being utterly unforgiving, particularly when going inwards instead of outwards.

*One thing I'm trying to get the hang of is setting appropriate min/max time bounds. Empirically, I think the time bounds are in 6-hour days (despite setting it to use Earth time), and one could use Hohmann transfer times as a loose guide for how much time to set, but I can still get some wonky results.

EDIT: Also, is there a way to plug in a programmed set of "try these flybys and see if anything works"? I know fully unconstrained flyby optimization is basically "do you have a supercomputer?" territory, but I might want to, say, have KSPTOT grind through a dozen or so ideas overnight or while I'm at work, stuff like "try Gael-Tellumo-Gauss, Gael-Gael-Gauss, Gael-Niven-Gauss, Gael-Otho-Gauss, Gael-Tellumo-Otho-Gauss, Gael-Tellumo-Gael-Gauss, Gael-Gael-Tellumo-Gauss".

Edited by Starman4308

Share this post


Link to post
Share on other sites
5 hours ago, Starman4308 said:

On program start, it pops up an error message, saying this:


Reference to non-existent field ".
Error in => projectMain.m at line 49

The problem disappears if I delete appOptions.ini, which has these contents:


[ksptot]
bodiesinifile = C:\path\to\KSPTOT\Gal32.ini
rtsHostName = localhost
timeSystem = Earth

Of course, this means I have to delete appOptions.ini each time I load KSPTOT.

Seems similar to an issue I reported a while ago when trying to start the program from the Start menu. Did you manually create a shortcut link to it in your Start menu, and do you happen to be using Start10 from Stardock instead of the stock Win10 Start menu?

Edited by Drew Kerman

Share this post


Link to post
Share on other sites
4 hours ago, Drew Kerman said:

Seems similar to an issue I reported a while ago when trying to start the program from the Start menu. Did you manually create a shortcut link to it in your Start menu, and do you happen to be using Start10 from Stardock instead of the stock Win10 Start menu?

Nope; I just double-click on the executable from a file explorer window.

As a side note: I was wondering why A, KSPTOT used such a large default SMA of 800 km, and B, why all my Gael ejection burns required so much delta-V.

Palms have recently been applied to faces as I have realized I have started every single Gael departure plan from over a thousand kilometers beneath its surface*. I swear, one day, I shall actually get the hang of this tool.

*On reflection, I suppose I should have realized that, while you can sort-of describe apses relative to the surface, SMA makes no sense whatsoever unless defined from the center of the body in question. I swear I'm usually smarter than this.

This new run is vastly more reasonable; I got a Gael-Tellumo-Otho-Gauss-Grannus grand tour for just 3.301 km/sec of delta-V, using just 5 optimizer runs.

Share this post


Link to post
Share on other sites
33 minutes ago, Starman4308 said:

Nope; I just double-click on the executable from a file explorer window.

there is a log file in the directory where the EXE is. Post it up somewhere for Arrowstar to look at

33 minutes ago, Starman4308 said:

why A, KSPTOT used such a large default SMA of 800 km

Looks like you figured it out :P It does all become easier with practice...

Share this post


Link to post
Share on other sites

Alrighty, two logs. This one comes from a run that works perfectly well, and probably has superfluous information because I was actively using KSPTOT.

https://www.dropbox.com/s/4dhkfkxbypwskxa/ksptot-preFailure.log?dl=0

This one comes from when it fails to start:

https://www.dropbox.com/s/mnjtfek126i4cie/ksptot-fails.log?dl=0

I shall continue to, on my own, debug such PEBKAC bugs as starting transfers from subterranean orbits...

Share this post


Link to post
Share on other sites
10 hours ago, Starman4308 said:

So, I'm getting a bug trying to load KSPTOT v1.5.7 (Windows 10, Core i5-6600K that I should really get around to overclocking someday).

On program start, it pops up an error message, saying this:


Reference to non-existent field ".
Error in => projectMain.m at line 49

The problem disappears if I delete appOptions.ini, which has these contents:


[ksptot]
bodiesinifile = C:\path\to\KSPTOT\Gal32.ini
rtsHostName = localhost
timeSystem = Earth

Of course, this means I have to delete appOptions.ini each time I load KSPTOT.

Otherwise, though: it's a wonderful tool that I'll have to learn how to use a bit better. I think I mostly have the hang of the multi-flyby sequencer*, and have found a Gael-Niven-Icarus path that saves a couple hundred m/sec off a direct Gael-Icarus transfer.

Granted, that's not much relative to the overall >17 km/sec cost of getting there and circularizing at 3.2x scale, but it's entirely plausible to me that's mostly on account of astrodynamics being utterly unforgiving, particularly when going inwards instead of outwards.

*One thing I'm trying to get the hang of is setting appropriate min/max time bounds. Empirically, I think the time bounds are in 6-hour days (despite setting it to use Earth time), and one could use Hohmann transfer times as a loose guide for how much time to set, but I can still get some wonky results.

EDIT: Also, is there a way to plug in a programmed set of "try these flybys and see if anything works"? I know fully unconstrained flyby optimization is basically "do you have a supercomputer?" territory, but I might want to, say, have KSPTOT grind through a dozen or so ideas overnight or while I'm at work, stuff like "try Gael-Tellumo-Gauss, Gael-Gael-Gauss, Gael-Niven-Gauss, Gael-Otho-Gauss, Gael-Tellumo-Otho-Gauss, Gael-Tellumo-Gael-Gauss, Gael-Gael-Tellumo-Gauss".

1) Try out the new prerelease, v1.5.8 pre-release 5, and tell me if that resolves your issue.  It should be in the last page or two of posts in this thread.  I think I remember finding this bug...

2) Bounds should obey the time system selected, I have been sure to check that on a few occasions.  Nevertheless, if you can provide some steps that can help me reproduce what you're seeing that would make you think that, I would be happy to look into it for you.

3) There is not, unfortunately.  I suppose you could start multiple instances of the program, or perhaps write some sort of Windows script to do it externally, but as it is now, no, that option sadly doesn't exist.  I'm sorry!

35 minutes ago, Starman4308 said:

Nope; I just double-click on the executable from a file explorer window.

As a side note: I was wondering why A, KSPTOT used such a large default SMA of 800 km, and B, why all my Gael ejection burns required so much delta-V.

Palms have recently been applied to faces as I have realized I have started every single Gael departure plan from over a thousand kilometers beneath its surface*. I swear, one day, I shall actually get the hang of this tool.

*On reflection, I suppose I should have realized that, while you can sort-of describe apses relative to the surface, SMA makes no sense whatsoever unless defined from the center of the body in question. I swear I'm usually smarter than this.

This new run is vastly more reasonable; I got a Gael-Tellumo-Otho-Gauss-Grannus grand tour for just 3.301 km/sec of delta-V, using just 5 optimizer runs.

1) Please do provide me with the log file that was just mentioned. :)

2) By definition, SMA is always defined from the center of the body, not the surface.  Orbital mechanics is rarely concerned about the altitude of anything or the radius of a body.  Go ahead and look SMA up on Wikipedia or Google if you would like some more information.  Thanks! :) 

Share this post


Link to post
Share on other sites
21 minutes ago, Arrowstar said:

1) Try out the new prerelease, v1.5.8 pre-release 5, and tell me if that resolves your issue.  It should be in the last page or two of posts in this thread.  I think I remember finding this bug...

2) Bounds should obey the time system selected, I have been sure to check that on a few occasions.  Nevertheless, if you can provide some steps that can help me reproduce what you're seeing that would make you think that, I would be happy to look into it for you.

3) There is not, unfortunately.  I suppose you could start multiple instances of the program, or perhaps write some sort of Windows script to do it externally, but as it is now, no, that option sadly doesn't exist.  I'm sorry!

1) It appears resolved in the 1.5.8 pre-release. Quick question: is all the other stuff in the 1.5.7 release .zip (example missions, etc) still good, or did that get moved into the 1.5.8 .exe file?

2) Will investigate further; there is a very non-zero chance of this being a PEBKAC from a novice user.

3) I demand a refund.

21 minutes ago, Arrowstar said:

1) Please do provide me with the log file that was just mentioned. :)

2) By definition, SMA is always defined from the center of the body, not the surface.  Orbital mechanics is rarely concerned about the altitude of anything or the radius of a body.  Go ahead and look SMA up on Wikipedia or Google if you would like some more information.  Thanks! :) 

1) Provided above

2) I'm aware of what SMA is. It was a truly impressive chain of illogic that lead me to plotting subterranean ejections from Gael.

First: in circular orbits, SMA == apoapsis and periapsis.

Second, 800 km (at 3.2x scale) would be subterranean, so clearly you're referring to the in-game convention of apoapsis/periapsis above the surface

Third, 800 km above the surface is ridiculously over-conservative

Fourth, enter in a more reasonable 150 km and profit

Logic!

EDIT: Also, to make sure it's completely clear, I'm being sarcastic about the refund thing. Thanks bunches for creating and maintaining this tool; I look forwards to doing some real mission planning instead of "stuff it full of propellant and go".

Edited by Starman4308
1 person likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now