[1.8.1 - 1.12.5] RSVP - kOS library for scripted interplanetary transfers and vessel rendezvous

[Kurld]

It's Rescale, which as I understand it is a SigmaDimensions config.

I'll apologize for all my "helpful suggestions" in the post above.  Once I got into to the code, I realized it already does them, one way or another.

I'm curious now about how I might be able to extend this to be able to find solutions that result in a free-return trajectory.  Do you have any thoughts about that?

[ManEatingApe]

6 hours ago, Kurld said:

It's Rescale, which as I understand it is a SigmaDimensions config.

I'll apologize for all my "helpful suggestions" in the post above.  Once I got into to the code, I realized it already does them, one way or another.

I appreciate all the suggestions and another pair of eyes checking that the code actually does what it's supposed to! .

IIUC the core issue is:
* Searching for a transfer from LKO to Mun takes a longer time than desired (assuming that CONFIG:IPU is set to 2000 for a "moar boosters" style of speedup) but results in a reasonable transfer.

* Shortening the search to a single orbital period of the origin results in janky transfer results.

So we're trying to find either a reasonable combination of setting to make the shorter search reliable and/or update the library code.

6 hours ago, Kurld said:

I'm curious now about how I might be able to extend this to be able to find solutions that result in a free-return trajectory.  Do you have any thoughts about that?

The most reasonable approach I can think of is what you're already doing - look for a retrograde target orbit, without a 2nd circularization node at the destination. Presumably some extra math can calculate the desired destination AP ahead of time.
 

Edited April 17, 2023 by ManEatingApe

[Kurld]

I think the long time it was taking was because it seems to be (by default) searching over the entire synodic period which I think would be some larger fraction of the Mun's orbital period.  Setting it with the options to be something like the ship's orbital period covers pretty much the same realm of possibilities (assuming the ship's orbit is more or less circular).

There does still seem to be some variability in the results,  when run several times in succession.  Not nearly as much as I was seeing when it was using the (as coded) default value for max flight time.

Shortening the search interval to give more opportunities for it to find the "best" solution seems to help tighten things up, but honestly, the default value has so far been "good enough" so I set it back to the default.  It finds a solution in only a moment, so it's plenty fast.

From the perspective of "good enough is the enemy of perfect" I will observe that it is still generally finding solutions that use some amount of radial-in or out. It seems to fire earlier/later than it needs to, because of this, or else it adds the radial component to compensate.  The amount it adds is a lot less than before.  I wonder if it can be further adjusted out by further increasing the maximum flight time?  I'll have to test some more.