ManEatingApe

Released Version 6. New Features This release adds a new mathematical approach to refining transfers when the ratio of the destination SOI to Periapsis exceeds a threshold. This fixes 2 issues: Transfers to larger moons (especially in the Jool system) are much less likely to go astray. Polar orbit orientation when travelling to Mun or Ike no longer results in huge delta-v values. The new approach is based on the paper A new method of patched-conic for interplanetary orbit by Jin Li, Jianhui Zhao and Fan Li. Given a velocity vector at SOI boundary, periapsis altitude and inclination, this approach calculates the position vector that satisifies these contraints. This position vector is combined in a feedback loop with the Lambert solver to refine the initial estimate from one that only considers planets as points to one that takes the SOI spheres into account. This removes the need both for the impact_parameter function and the line search algorithm simplifying the vessel-to-body case. The body-to-body case also simplifies into a single step instead of two. For vessels and planets with a SOI to Periapsis ratio of less than 1% the existing strategy is used. This strategy considers the planets as a zero-width point on the assumption that over large distance only small adjustments will be need to the predicted transfer. However some bodies in KSP have extremely large SOI to Periapsis ratios, for example Ike (38%), Mun (23%) and Tylo (17%). For transfers to and from these bodies, the SOI sphere needs to be taken into account when finding the lowest cost transfer. The offset_from_soi_edge and duration_from_soi_edge function in orbit.ks predict the time and position where a craft will exit/enter SOI. Interestingly another challenge with very large SOI to Periapsis ratios is that the minimum escape velocity can be higher than the desired transfer. For example a direct Hohmann transfer from Laythe to Vall is impossible, as the minmum escape velocity from Laythe is higher than the velocity required. The search algorithm now supports a minimum value for deltav, making this type of transfer possible. Bug Fixes Fix calculation of periapis time when insertion orbit is mathematically elliptical. Insertion manuever node will now be placed in the correct location. Fix bug in a guard clause in the Lambert solver that was throwing NaN exception is certain situations. Technical Improvements Add validation check to final_orbit_periapsis option to ensure that supplied value is within SOI radius of destination. Refactor maneuver related code from orbit.ks to maneuver.ks.

We can solve numerically using Kepler's equation. Mean anomaly (M) is zero at periapsis, increases uniformly to π at as the craft reaches apoapis, then increases to 2π as the craft returns to periapsis. If we want to find the altitude that half the orbital time is spent above, then we set M to 0.5 * π. (As another example, if we wanted the radius above which 30% of the time is spent, then we would set M = 0.7 * π). Kepler's equation relating mean anomaly and eccentric anomaly (E) is: (1) M = E - e * sin(E) So we have: (2) 0 = E - e * sin(E) - 0.5 * π Define: Periapsis radius = rp = 220000 km (from center of Mun) Threshold radius = rt = 260000 km Apoapsis radius = r = ? Eccentricity (e) in terms of our unknown (r): (3) e = (r - rp) / (r + rp) Derivative of equation 3: (4) de/dr = e' = 2rp / (r + rp)2 Cosine of eccentric anomaly (E) in terms of our unknown (r): (5) cos(E) = c = (r + rp - 2rt) / (r - rp) Derivative of equation 5: (6) d(cos(E))/dr = c' = 2 * (rt - rp) / (r - rp)2 For convenience: (7) sin(E) = s = sqrt(1 - c2) (8) E = cos-1(c) Putting (2), (7) and (8) together, our function to find r (will be zero when r is our desired apoapsis): f(r) = cos-1(c) - e * s - 0.5 * π The derivative of this function (liberally applying chain and product rules) is: f'(r) = -c` / sqrt(1 - c2) - [e' * s - e * c * c' / sqrt(1-c2)] Tidying: f'(r) = c` * (e * c - 1) / s - (e' * s) Solve numerically using your favorite method (e.g Newton's method). kOS code in the spoiler r ≈ 290,408m (from center of Mun) ≈ 90,408m in-game altitude.

If you can fling it to the Island Airfield, then it's a slightly surreal entry to this challenge

Released Version 5. Bug Fixes Fix issue Tried to push NAN into the stack when attempting an intercept from a nearly-approaching orbit. This was preventing a craft that had just missed an intercept from correcting its orbit. The root cause was slight numeric inaccuracies in the Lambert solver for certain time of flight calculations resulting in an attempt to take the log of a negative number. Added a guard to protect against this edge case. Technical Improvements Add build_documentation Github Action that creates documentation in the same format as kOS. On any change to the doc folder, this action will automatically run the Sphinx generator to convert raw .rst text files to HTML, then publish the changes to Github Pages. This keeps a clean separation in the repository between the raw source files and the generated output.

Those are some interesting use-cases! If all you need is a Lambert solver, then the code in lambert.ks is completely general and has no KSP/kOS specifics, so it should be relatively straightforward to port to Python. How wedded are you to Python? The reason I ask is that's there are some advantages to staying within the kOS ecosystem. Kerboscript is a neat flexible functional language. Kerboscript pros: Leverage existing RSVP code Use built-in kOS functions for vessel and celestial body position and velocity (no need to copy orbital parameters back and forth, then use an external Kepler solver) Would also adapt to any planet pack mods "for free" with no extra effort, for example GPP, RSS, JNSQ. Users have access to the tool "in-game" as they fly missions. Python pros: Faster execution Access to the entire Python library ecosystem

Released Version 4. Support .ksm compiled files. New Features Implement issue Running other files should not include extension. Add ability to use more compact compiled version of the source on craft that have limited volume space. Compiled files take about 20% of the space of the raw source, resulting in a significant space savings. Add compile_to convenience function that compiles the source to a user-specified destination, for example a kOS processor hard drive.

Released Version 3. Improve handling of objects on hyperbolic orbits. Technical Improvements Use different strategy when calculating default search_duration, max_time_of_flight and search_interval values for a destination with a hyperbolic orbit, for example an asteroid or comet. This change prevents a Tried to push Infinity onto the stack error that occurred because the approach used for planets assumes an elliptical orbit with a finite orbital period.

Released Version 2. First bugfix, first new feature and first technical improvement. New Features Add cleanup_maneuver_nodes option. Enabled by default, this will delete any maneuver nodes created if any problem occurs when creating the transfer, in order to leave a clean slate for the next attempt. Bug Fixes Fix issue search.ks fails when time:seconds > 2^31. The kOS range expression expects values to fit within a signed 32 bit integer. This caused the script to break when run on save games with a universal time greater than 2³¹ seconds or about 233 years. Replaced the range expression with a from loop as a straightforward workaround. Technical Improvements Calculate the time at destination periapsis (used when creating the arrival node) directly from Keplerian orbital parameters of the intercept patch. This is more efficient and accurate than the previous approach, which used a line search to find the closest approach distance by trying different times.

Today I released version 1 of RSVP, a kOS library that finds orbital launch windows then creates maneuver nodes to make the transfer. This enables players to make automated low delta-v transfers between two planets or vessels in-game, either directly from their own kOS scripts or from the kOS console. There are still some rough edges and not everything works perfectly, however I'd really like for people try it out and give feedback on the main release thread. See these features in action: The main release thread has more details:

RSVP RSVP is a kOS library that finds orbital launch windows then creates maneuver nodes to make the transfer. The acronym stands for "Rendezvous s’il vous plaît", a playful pun on the regular meaning of the phrase. This library enables players to make automated low delta-v transfers between two planets or vessels in-game, either directly from their own kOS scripts or from the kOS console. It provides a script-able alternative to existing tools, such as the excellent web based Launch Window Planner or the snazzy MechJeb Maneuver Planner. Features Integrates with your kOS scripts. Creates departure and arrival maneuver nodes. Supports rendezvous between vessels, planets, moons, asteroids and comets. Adapts to planetary packs such as Galileo's Planet Pack, Outer Planets Mods and JNSQ. See these features in action: Links Download Documentation Dependency: kOS 1.2.0 or greater Source Code GPL-3.0 License Quickstart Acquire latest version of rsvp.zip from download link. Unzip into <KSP install location>/Ships/Script directory. This step adds the library to the kOS archive volume, making it available to all vessels. Launch a craft into a stable orbit of Kerbin. Run this script from the craft: runoncepath("0:/rsvp/main.ks"). local options is lexicon("create_maneuver_nodes", "both", "verbose", true). rsvp:goto(duna, options). This will find the next transfer window from Kerbin to Duna then create the corresponding maneuver nodes necessary to make the journey. Additionally it will print details to the console during the search.

If it's using normal physics then any type of siege weapon is totally fine, cannons included! If you're planning on using Kraken related shenanigans (similar to @Tyr Anasazi's entry) then that would put your entry into the Rogue's Gallery

Fellow cave-dwellers, you may find it amusing to know that our mission has been preserved for posterity as part of the GitHub Arctic Code Vault. Our craft designs and save files have been transferred to film, then buried under hundreds of meters of permafrost, above the Arctic circle. Ten thousand years from now, some very confused archaeologists will marvel at our antics.

TIL Juypter Notebooks exist, good call on the recommendation. Now if only there was a Kerboscript option... Nice insight!

Good catch! I have corrected the original post.

There's no sheet, just the formulas mentioned previously, plugged into a grapher. As best as I can tidy it the combined formula is: The values for α, β and μ are obtained from the KSP wiki page for each body. The value for "v" I found empirically for each body by running a quick test mission, however you could probably work this out analytically.