ManEatingApe

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 )

Ah, that's a good one! I tried the save file but could find no craft in orbit of Gratian. There's also a bunch of missing part errors (I don't have the same mods) Would you mind uploading the save again - with only the craft in question, with only stock parts (you can use the debug menu to rendezvous a dummy craft to the same orbit).

@Black-Two- Let's take a look at the next two issues. Test-1 is in an inclined orbit around Gael. By default RVSP assumes that you want to inject into a prograde orbit at 0° inclination. This is causing it to "force" the 1st node at the cost of extra delta-v, essentially trying to hammer a square peg into a round hole. The tweak is to change the desired final orbit type to polar. Relaxing this constraint allows RSVP to find a much better transfer. Here's a table of results: Settings Delta-V Manual testing (not using RSVP) 888 m/s Default RSVP settings 1184 m/s "final_orbit_orientation", "polar" 902 m/s In general, transferring from an inclined orbit around one planet to another is going to cost more delta-v than launching from an equatorial orbit at 0° inclination. RSVP usually finds the transfer that intersects the destination planet at its ascending/descending node which tends to be optimal. Using the velocity in the inclined orbit required precise timing on the maneuver node to depart at exactly the right time. Any offset from this time is harmful, as the manuever node delta-v is fighting against the inclination velocity. That said, RSVP doesn't blindly create maneuver nodes at the exact time returned by the hill climb search. It adjusts them based on the ship's orbit to find the very best time possible. You can see the implementation in the "create_maneuver_node_in_correct_location" function (no prizes for guessing what that does ) https://github.com/maneatingape/rsvp/blob/master/src/transfer.ks#L285 (Interesting implementation detail: This uses the same code as the 2 dimensional pork chop hill climb, but restricted to 1 dimenstion).

@Black-Two- Nice find, this was an interesting issue to investigate! The long pause was caused by the very first pork chop search taking many more iterations than subsequent searches. The root cause was that the search period was very much less than the time of flight. RSVP uses the search period to determine the size of the "step" used when searching. A visual example should help. The search period is on the x-axis and the time of flight is on the y-axis. A planet to planet transfer (for example Gael to Niven) has a reasonably square aspect ratio. As width and height are matched, the step size is a good choice for both horizontal and vertical steps. Here's an example with a more skewed 1:3 ratio. (the actual ratio of Test-0 to Iota was even more extreme at 103). We can see that the step size is still fine in the horizontal direction but too small in the vertical direction, resulting in extra steps. Now that the problem is clear the fix is straightforward - scale the horizontal and vertical steps independently. With a larger vertical step the ratio is effectively square once again and the search time improves. Here's the details from your provided save: The Test-0/Iota case is 55% faster. The Niven/Tellumo duration remained around the same. Delta-V was the same except for 2 cases that were a bit higher.