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 )

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.

Let's start with item 1: RSVP's default search parameters are very conservative. The intention is to always find the best (lowest dV) transfer with the tradeoff of using extra time when performing the search. The default search period is the maximum of either the synodic period between the two bodies or the sidereal orbital period . The synodic period is defined as the period for the phase angle between the 2 bodies to repeat. This period covers every possible relative orientation of the 2 bodies. Here's the relevant code line: https://github.com/maneatingape/rsvp/blob/master/src/search.ks#L36 The search interval is smaller than the search period and is how often RSVP begins a new search using its hill climbing algorithm. The default search interval is half of the minimum orbital period. Relevant code line: https://github.com/maneatingape/rsvp/blob/master/src/search.ks#L59 Here's a table of the 3 transfers from Test-0 Destination Search Period (s) Search Interval (s) Ratio Tellumo 18625942 4600800 4 Niven 17061136 2988830 5.7 Iota 495456 1792 276 Note that the search interval used is half the orbital period of Gael when going to Tellumo/Niven, but half the orbital period of Test-0 when going to Iota. The default parameters work well for the planet to planet case and I was able to reproduce the decent transfers that you found. Now we can see why the Iota transfer search is so much slower than the others. So the question isn't why the Niven/Tellumo transfers are so fast (they seem fine) but what can we do to speed up the transfer search between Test-0 and Iota. One suggestion is to use the knowledge that Test-0 and Iota are in co-planar orbits. So a single orbit of Test-0 will cover all possible scenarios. Test-0 has an orbital period of ~30 min, so I changed the parameters to local options is lexicon( "search_duration", 30 * 60, "search_interval", 0.25 * 30 * 60, "create_maneuver_nodes", "first", "verbose", true). This found a decent transfer in a fraction of the time. I'll investigate item 2 next.

Hey @Black-Two- thanks for the save file. I have setup: Clean install of KSP 1.12.2 GPP 1.6.7 kOS 1.3.2 RSVP v6 Your save file "Abyss of the Void" (love the name!) Reading your post, looks like the items to investigate are: Discrepancy in search duration when searching transfer from Test-0 to Iota (takes a while) vs searching for a transfer to Niven/Tellumo (quick) Long pause between starting script and seeing any output. Bad transfer from Test-1 to Iota Higher delta-v from Test-1 to Niven/Tellumo than with Test-0

If you could upload some pictures of your lander design(s) then we could take a look and see if there are some design tweaks that could be made. I'd recommend creating a new thread (perhaps in "The Spacecraft Exchange" section ) to avoid cluttering this thread.

Hang in there Scarecrow, we've all been stuck in that frustrating zone! It might help to take a small break and try something else, sometimes insights may come to you when least expected. Getting to Dres is trickier than Duna, most folks do it the other way around, so that's a neat achievement. If you like, you could post ask a question in the "Gameplay Questions and Tutorials" seeking feedback on your lander design. I'm sure there will be some good suggestions.

Delighted to hear it! Hmm...the default search parameters could need tweaking to better suit GPP. If you upload a copy of your save file and the transfer(s) you're attempting, I can take a look.

Well, just Kerbin orbit without any unlocks although the Jool 5 was very primitive. I'd love to see someone attempt a Mun landing with Fleas only! In the spirit of this thread, have a meme... https://imgur.com/qgTjLvw