Armisael

It’s entirely safe for reentry from Mun. Heating is a joke in stock KSP. Mk1 Lander Can has always been safe for that (I don’t know about the old heavy Mk2 can - I never used it) . That’s why I didn’t use a cargo bay: it doesn’t add anything but weight. You’re right about saving the science experiments. You can keep everything but the science he with negligible changes in performance, which makes up about 18k of the 20k returnable science (can’t bring back the ground experiments).

@Streetwind This still had 577 m/s of dv after my Munar ejection burn so there's still more cutting to do, but here's a quick first cut at it. I wasn't sure if you included the antenna as part of the ground experiments, but assumed not since the numbers lined up without it (and you'd want relays for continual coverage of the site anyways). You're absolutely right about reusing your science gear many times for actual cost-efficiency, of course.

@Streetwind I'm honestly not sure how to read a post saying 'this rocket is just about as tight as it'll go, but it also has gobs of excess dv'. If your goal is to deliver kerbals and science gear to Mun's surface then get the kerbals back, you could easily cut 15k off the cost of that ship - more if you decide to simply always use the probe core.

I was really looking at how much dv it actually costs to reach orbit from the surface (or to land), which depends both on orbital altitude and surface elevation. I think the reasonable thing to do for the landing numbers is to assume that the craft is landing at either the mean or minimum equatorial altitudes; the altitude of the orbit is mostly a separate choice.

I think this is more a philosophical matter. Should ascents and landings describe that absolute best possible case, a more average case, or a worst-case (based on landing location, not technique)? I think expecting people to know that they'll need to land on the top of the tallest mountain is somewhat unreasonable, but I suppose that's up to you. Some more numbers (min/max/mean equatorial surface altitudes were measured using a kOS script that measured the surface elevation on the equator every 0.01°).

I'm interested in working out the average elevation above sea level for the equators of the airless bodies (ideally both mean and median). I can do this by putting a satellite in an equatorial orbit and using kerbnet, but then I have to manually log an altitude every 3.5s for like 40 minutes per body. I'm hoping there's a somewhat less labor-intensive approach. Is there are kOS script or a website that has already logged them?

You already have Minmus's value at 180 m/s, so that's already handled. No need to change anything; the comment was on my numbers. The numbers above are costs for Hohmann transfers to/from sea level with perfect point burns. I'm not aware of any superior technique. Bielliptic transfers and gravity assists are the usual culprits but I don't see how you'd use them for a simple landing. You can beat them if you land at or ascend from taller geography; landing on Mun at 5.5km ASL saves you about 8 m/s. I'm not aware of any resource listing the tallest point as a function of latitude on each body, or even just on the equator. I also need to think over the precise math on how much dv it's worth expending to reach a non-equatorial high point. I suppose we could simply use 10km below the listed low orbit and assume that altitude is available equatorially.

The arithmetic all looks correct. I don't understand the intended routes between bodies well enough for out-of-Kerbin bodies well enough to meaningfully comment on those. If you were interested in landing values: Exact values are less important for these than the capture costs, I think, since it's so much harder to actually achieve these. I also might opt to disagree with the rounding on Minmus - rounding 174.93 to 170 is... technically correct, but perhaps unhelpful.

Everything on that chart to the right of the low orbit altitude is calculated, mostly using the vis-viva equation (with the exception of the 50x time warp altitude). I’ve done some testing (edit: using maneuver nodes, not burns) to confirm my results were right using hyperedit, but haven’t tested on all bodies. I can upload the file when I get home from work It’d certainly be neat to have my name on something so important to the community, but the real driver for me was getting that 310 m/s number for Mun capture fixed. (For what it’s worth I think the 10k above minimum is a very reasonable standard.) EDIT: Link on google sheets

I think most of the capture numbers are wrong. I've gone back and looked at Curious Metaphor's numbers (based on the dv map linked on the front page), and I can only replicate them when I assume that you're departing from an orbit at the 50x time warp altitude (not what's listed on this thread's map), and that you're attempting to escape to infinity (which you aren't in this game). It's really simple to verify - if you hyperedit yourself into an 80km Kerbin orbit, you'll see that it simply doesn't cost 950 m/s to escape the SoI. I've checked Kerbin, Eve, Mun, and Laythe, and they all line up with my numbers within 0.1 m/s. Here are my numbers. (If someone can tell me what I've done wrong I'd be happy to understand how I'm misreading the map, of course)

@Aethon That's only true if your trajectory is always exactly at sea level.

I don't think you're calculating the eccentricity correctly for the pitch angle in the sample case - you need to wrap a sqrt around the (1-sin(θ/2))/(1+sin(θ/2)). The numbers you have to the right of that definitely aren't right, since the pitch angle should never go above 45 degrees (not in the simple case, at least).

@jofwu Yeah, I think you're right. If you run through r = p/[1 + e cos(ν)] using both r_Ap (where ν = 180°) and r_Moon (where ν = 180° - θ/2) you get an eccentricity of [r_Ap - r_Moon]/[r_Ap - r_Moon cos(θ/2)]. From there it's pretty trivial to calculate the semi-latus rectum and SMA, and then you're basically done - we have easy expressions for any other interesting quantity in terms of those.

The assumption is just two sites - a launch site and a landing site. We've been looking at figuring out the most dv-efficient suborbital path between those two points, not pathfinding algorithms. The problem with simply figuring out how far the landing site moves mid-flight is that the duration of the flight is a function of the position of the landing site. It seems like it ought to be possible to figure out the motion precisely, though. You might not be going very far on a non-smooth planet - maybe you want to travel 3km and land on top of that mountain.

I was having a dumb moment - left the files as txt instead of cfg. Anways, @fourfa if you're still looking for that radial decoupler crossfeed default: //New radial decouplers allow crossfeed //Author: Armisael @PART[*]:HAS[@MODULE[ModuleAnchoredDecoupler]]:FINAL { @MODULE[ModuleToggleCrossfeed] { @crossfeedStatus = true } } @PART[*]:HAS[@MODULE[ModuleDecouple]:HAS[#explosiveNodeID[srf]]]:FINAL { @MODULE[ModuleToggleCrossfeed] { @crossfeedStatus = true } }