ManEatingApe

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. 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.

Thanks for the detailed description, investigation and GitHub bug report! I should be able to take a look in the next few days. Out of curiosity what is the 2.5x mod that you're using?

Released Version 9 Bug Fixes Support kOS 1.4.0.0 by renaming local variables to avoid conflict with built-in names. New Features The restriction on running the script when the craft is not in a stable orbit has been relaxed, so that finding future transfer times can happen when on the ground. Maneuver nodes can still only be created when the craft is in a stable orbit.

Possibly - if the interstellar expansion models the suns as orbiting a common point, then in theory it's possible to plot an intercept from Kerbol orbit to orbit of the destination star. Why not give it a try...I'd be curious to see if it works!

Part mods won't affect RSVP, only planet packs (such as Rescale). Without a save it's going to be tricky to pinpoint the issue. I can offer some general suggestions: Is the target planet heavily inclined? Large SOI to orbit ratio? If so try tweaking the "final_orbit_orientation". to "polar. Sometimes this can improve the transfer. What about other broadening the search window? Are all transfers 5m/s? It might be that particular window for some reason. Perhaps the next transfer window a couple of years later might provide better values.

Hey, if you upload the save file somewhere, I can take a look!

Yes! RSVP reads orbital info from the game itself, so any planets packs that modify the stock planets are supported.

@acr_8133Two solutions for now: Sophisticated: Send a probe into orbit, run RSVP from the probe to find dates, then use kOS communication functionality to send launch date back to mothership waiting on the pad. Moar Boosters: Comment out the following lines https://github.com/maneatingape/rsvp/blob/master/src/validate.ks#L59-L61 to override the validation and run the script from the mothership. I'm noodling on modifying the restriction. It's a little tricky as all the defaults are based on the ship's orbit. It (just about) works ok when the destination is in an aunt/uncle relationship to the ship (e.g. ship sitting on Kerbin, heading to Duna) but opens a whole can of worms when that's not the case (e.g. ship on Kerbin heading to Mun).

Is there a reason that waiting on the pad is better than waiting in orbit?

Yeah, concise phrasing that is easily understandable is hard! Essentially, if your ship is orbiting Kerbin, then Kerbin is the direct parent, so valid destinations are: Mun, Minmus Ship also in orbit of Kerbin The sun is the direct grandparent of the ship, so valid destinations in addition: Moho, Eve, Duna, Dres, Jool, Eeloo Ships also in orbit of the Sun Ike is orbiting Duna so it's not directly accessible in a single transfer, but is do-able in two. Plot a transfer to Duna, capturing into an elliptical orbit if Ike is your first destination, then once in Duna orbit, plot a second transfer. ship:obt:period is used if the relationship between origin and destination is sibling, for example ship in orbit of Kerbin to Mun. ship:body:obt:period is used if the relationship between origin and destination is aunt/uncle, for example ship in orbit of Kerbin to Duna.

Released Version 8 Bug Fixes Add a safety check that the predicted insertion velocity at the boundary of the destination's SOI is above the minimum possible (based on the desired final periapsis). This is similar to the existing check that the ejection velocity from the origin is greater than the minimum possible. This prevents an error occurring during transfer refinement in some scenarios when the initial raw point-to-point Lambert solution predicts an intercept velocity less than this minimum.

The initial predicted relative velocity is less than the minimum. Greater than the minimum is no problem, you can come shooting in as fast as you like. Worst case, it would probably throw off the refinement iteration causing the transfer to be bad (i.e cost more delta-v than necessary). I had a think about the solution and decided the best course of action was to simply fail the iteration explicitly. Note this won't fail the entire search (unless by some slim chance this is the only search iteration). There was already a check to ensure the ejection velocity was over the minimum, so I've added a similar check for the insertion velocity. There's a somewhat pleasing symmetry to this, and of course <drumroll>... A predicted transfer for a mere 22 m/s (of course in this instance the craft will intercept Geminus before the manuever node). Me too!

Released Version 7 New Features This release increases the speed of the hill climbing algorithm when searching the pork chop plot in certain scenarios. The larger the relative difference between the origin and destination orbits, the more benefit this provides. The eventual transfer found and delta-v needed is the same as before but takes less time to find. For example a transfer search from Kerbin to Duna takes the same time. A transfer search from Moho to Eeloo takes 15% of the previous time. Technical Improvements When verbose mode is enabled, print details if a problem occurs during a transfer search. Add CPU speed boost to quickstart code snippet

Update on what's going wrong... I originally thought it was due to the fact that the craft intercepts Geminus (no fewer than 3 times in a row!) within the search period, but after some investigation kOS doesn't track future intercepts until the game shows them in the UI so that was ruled out. This extremely polished graphic will help illustrate: KSP uses patched conics, where each body has a finite SOI (sphere of influence). Within each SOI only the central body gravity is considered, reducing orbital equation to readily solvable 2 body forms. This means that at the boundary of the SOI there is a minimum possible velocity. This is given by the vis-viva equation and is 83 m/s for Geminus with a PE of 100km and AP at SOI boundary. RSVP uses a spherical cow approximation for the initial transfer returned by the Lambert solver. This assumes the origin, destination and craft are all zero dimensional points. RSVP then refines this raw initial transfer, using an iterative process that takes into account the finite SOIs of the origin and destination when applicable: https://github.com/maneatingape/rsvp/blob/master/src/refine.ks#L203 For one particular iteration the intercept is returning 28 m/s as the relative velocity of the craft and Geminus. As this is below the minimum possible, it mucks up the math and results in the stack trace you reported. That's the background...so how do we fix it? I'm not sure yet. One solution might be to force a minimum floor on the intercept velocity. Another may be to better mirror how KSP translates velocity when transitioning SOIs.

It was missing Breaking Ground/Making History DLCs. When I added them, then restored a fresh copy of the save file I could see the craft and reproduce the error successfully. Previously I was getting a popup dialog error about unknown parts and it looks like KSP deletes a craft from the save if it has parts it can't load. Depending of the value of the "final_orbit_orientation" https://github.com/maneatingape/rsvp/#final-orbit-orientation RSVP tries to achieve a destination orbit of: "prograde" => 0° "polar" => 90° "retrograde" => 180° In this case the polar orbit was a closer match to the craft's existing orbit. ("circular" is an option for the eccentricity of the final orbit, which is a different unrelated option "final_orbit_type" https://github.com/maneatingape/rsvp/#final-orbit-type )