ManEatingApe

Clever use of the loophole. I have updated the rules based on your suggestion to close this exploit. You now have the honour of a rule named after you and the infamy of an entry in the rogue's gallery.

To cater for creative mischief, I've added a Rogue's Gallery section for entries that break the rules. Anything there won't count towards the leaderboard but could earn an honorary mention for especailly inventive or amusing antics.

Nice work on the entry...you sweep the 1st place spot in the re-usable category too. 2 down...one to go! I'm always delighted to see entries involving technical ingenuity and/or great piloting skills. Do make sure to stick to the spirit of the challenge and avoid any rule lawyering as it ruins the fun for other entrants.

Welcome to the forums and to the challenge! You jump directly to 1st place in the command chair category. I like the sleek design and clever use of the Okto as an unorthodox heat shield. I'm certain that with a flatter ascent profile some fuel (and hence cost) could be shaved off. The 2 part re-usable design is a good start. Unfortunately I can't accept this specific design - the nuke clipped into the Rapier breakes the rule on excessive clipping. But I feel with some tweaks the leaderboard awaits you in this category too...

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: set config:ipu to 2000. 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.

As several previous answers have already mentioned, this is the gate orbit effect, but reversed. TL;DR Is it cheaper to directly circularize at desired altitude? Non-precise answer: No for Moho, slightly for Duna and probably not for other planets. EDIT: Actual data: Yes for Jool and Eve! No for Dres and Eeloo. Anyways, let's do some math! Our 2 strategies are: Brake directly into circular orbit at desired altitude. Brake into elliptical orbit with PE as low as possible and AP at desired altitude then circularize at AP in a second burn. We'll be making heavy use of the vis-viva equation: v = sqrt(μ*(2 /r - 1/ a)) Define: v = Orbital velocity at edge of target SOI, approximately 4,100 m/s for a direct Kerbin -> Moho transfer. α = r1 = Lowest possible radius for braking e.g. 15km above Moho's surface = 265,000m β = Radius of target SOI, approx 9.6 million meters for Moho μ = Standard gravitational parameters for target, 1.69E11 for Moho Approach 1: Hyperbolic intercept velocity at desired altitude (r2): vh2 = sqrt(v2 + 2μ * (1 / r2 - 1 / β)) Circular orbital velocity at desired altitude: v2 = sqrt(μ / r2) Delta-v: vh2 - v2 Approach 2: Hyperbolic intercept velocity at desired altitude (α = r1) = vh1 = sqrt(v2 + 2μ * (1 / α - 1 / β)) Hohmann transfer orbit velocity at r1: vt1 = sqrt(2μ * (1 / α - 1 / (α + r2))) Hohmann transfer orbit velocity at r2: vt2 = sqrt(2μ * (1 / r2 - 1 / (α + r2))) Circular orbital velocity at desired altitude: v2 = sqrt(μ / r2) Delta-v = vh1 - vt1 + v2 - vt2 Graph: x-axis is desired altitude. y axis is approach 1 delta-v minus approach 2 delta-v: vh2 -vh1 + vt1 + vt2 - 2v2 If y is negative then approach 1 is cheaper. Moho Clearly it's always cheaper to use approach 2! At radius of 1,250,000 = altitude of 1,000,000 the figure of ~400 m/s agrees with @Grogs empirical findings. Duna This is more interesting. Below a radius of 725000 meters it's more efficient to circularize directly at Duna, although not by much (~10 m/s). In general the higher the velocity at SOI edge then the lower the altitude at which approach 2 becomes cheaper. Since Duna is the closest planet to Kerbin, other planets will have a higher intercept velocity at SOI edge and hence a lower altitude for the cut-over point. EDIT: Jool The massive SOI means Strategy 1 is cheaper until 225,000,000 meters (past the AP of Pol) Eve Strategy 1 is good until around 5,750,000 meters.

Your intuition is correct - the faster you burn, the less that Kerbin warps your orbit as you escape, so the closer your angle can be to prograde. This is why Dres's transfer angle is closer to prograde than Duna's transfer angle. The ejection angle is not about giving you time to make the burn; all maneuver node burns are assumed to be instantaneous. Instead it measures how much Kerbin bends your trajectory. In real life, escape trajectories are mathematically hyperbolae. (NOTE: Technically also parabolas and in KSP there is a big exception...but more on that in a bit). The eccentricity of a hyperbola is given by: e = vp2 / (rp × μ) - 1 Where vp is your velocity at periapsis after your transfer burn, rp is the radius at which you made the burn and μ = GM is the standard gravitational parameter for Kerbin. The angle of the tangent to a hyperbola at infinity is related to sin-1(1 / e) and the angle relative to prograde is π/2 + sin-1(1 / e). Now we can see that the faster we go, the greater the eccentricity and the closer the angle from prograde becomes to 90 degrees. For example a parabola (barely escaping, eccentricity = 1) would have a angle to prograde of π/2 + sin-1(1) = π = 180 degrees If we could go infinitely fast the angle to prograde would be π/2 + sin-1(1 / ∞ ) = π/2 + sin-1(0) = π/2 = 90 degrees To see this visually here are some graphs of hyperbolae of increasing eccentricity showing the tangent line at infinity. In KSP however there is a big difference from reality. KSP uses patched conics, where beyond a certain radius the planet's gravity does not affect you at all. This is the planet's sphere of influence (SOI). This makes all orbits instances of the 2-body problem, which is easier to reason about mathematically. It also means that the formula for the tangent that I used earlier is wrong when applied to KSP. Instead of finding the tangent at infinity we need to find the tangent at the SOI radius rs (for Kerbin 84,159,286 meters). This can be calculated by: Semi-major axis is: a = rp / (1 - e) Cosine of the eccentric anomaly (E) is: cos(E) = (a - rs) / (e × a) Slope of the tangent at radius rs is: m = cos(E) × sqrt[ (1 - e2) / (1 - cos(E)2) ]. Angle from prograde = 2π - tan-1(m) Interestingly, if you examine the source code for Alex Moon's solver, it approximates the tangent using the formula for the true anomaly (θ) at a given radius: rs = a × (1 - e2) / (1 + e × cos(θ)) θ = cos-1[ (a × (1 - e2) - rs) / (e × rs) ] This is probably close enough. This MIT lectures notes has very nice details on interplanetary transfer orbits. The Wikipedia articles on eccentricity, hyperbolic trajectory, Kepler's equation, true anomaly and eccentric anomaly are also great reading. What's also fun is that KSP allows you to escape from a planet with an orbit that is mathematically an ellipse, by "chopping" off the top of the ellipse once you go out of SOI. In the Jool system, it's possible to transfer from Tylo to Laythe with such an orbit.

Would you consider kOS overpowered for this challenge? Manual control for a 50m altitude speed run would be nigh on impossible, but a suitably tuned PID controller may be able to do it...

Calling all cave dwellers... @QF9E @LittleBitMore @Space Nerd @JAFO @Mr. Peabody @sevenperforce Any interest in attempting a reboot of this challenge, with new even more fiendish difficulty? (CommNet on & limited probe control) @IncongruousGoat @Jacke @dvader @Muetdhiver @Pds314 Veteran Jool 5 cave dwellers are also encouraged to either participate directly, or provide sage advice, tips & tricks and generally help out. This is an open invitation, anyone at all is totally welcome to volunteer (even if not mentioned here). So far the list contains myself and an enthusiastic @EveMaster ...

Nice work! The extra ladder is a clever touch. 2-axis Kerbal ladder control is now a thing I think it's important to eliminate the unintentional Kraken drive, as it would taint the attempt. There would be no way to prove that we didn't use the drive's effect, even accidentally. Upload the craft files to KerbalX for now. ============================================================================= If there are enough folks interested, then I'm happy to reboot the challenge and start over. Anyone is welcome to volunteer, so it's a nice opportunity for anyone who enjoyed the original attempt but didn't get involved at that time. We'd go through the same phases as before: Agree mission rules Discuss, design and plan mission profile and craft Assemble mothership in orbit Fly the mission! My initial suggestions are: Use 1.10 update, to take advantage of the shiny new Jool system (although planning and craft testing can begin before it's released on July 1st) New Git repo, normal difficulty settings (no changes), enough funds and science added via debug menu.