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 } }

I'm having trouble with the autohibernate script; it doesn't seem to be doing anything for me. Can someone else either confirm that or let me know that it's just an issue for me? Also, any idea how'd I'd go about having fairings start with the interstage nodes disabled? FWIW I suspect that I'm the author of the 'no monoprop' patch; the timing with this post seems right.

Obviously it'd be useful to be able to deflate it. No one's arguing that. It'd also be useful to have a engine with 10^9 Isp. The inflatable heatshield already feels like it's verging on hilariously OP to me - please don't make it even more so.

Good to see this actually happen. On the recovery side: 818 spesos

The challenge gets very different if recovery or mods are allowed.

How'd you load the kerbal into the chair? It hardly seems fair to not count that.

From the devnotes a week before the 1.2 prerelease: I don't know how much more clarity you could possibly want.

You can only use the version of the part you've currently unlocked. In sandbox you get the base version of the part - no upgrades at all. I'm still not sure how I feel about upgradeable parts in general, but the current system is clearly not ready for even beta release (not by KSP beta standard at least - the term beta has become rather devalued over the last decade). I'm also very thankful that they didn't hold up literally everything else to get that system sorted out. Were you expecting these parts in 1.2? They were excruciatingly clear that these parts wouldn't be making it into the update. The fact that we got even a peek at them through a mod is already more than expected.

So it turns out that there's a bug in the upgrade code, and those aren't the final upgraded stats - they are, in fact, the unupgraded stats. My apologies for the confusion.

SECOND EDIT: I made a vastly more compact form once I got home: THIRD EDIT (because why not): it seems to me that there's a bug in the upgrade code - engines with upgrades don't display those upgrades in the right click menu. These are the un-upgraded stats. For example, the terrier doesn't cap out at 340s - it makes it to 345s at least.

I'm thrilled with these changes - not just because they indicate that SQUAD is willing to change well-established parts - but because they're mostly pretty good. The reliant and the twin-boar were totally overshadowed by their brethren (the reliant a little more so). The vector was definitely ridiculous. I'm also excited for the new parts; there was always a bit of a gap between the skipper and the mainsail - hopefully the boar does an adequate job of filling that. I'm not as clear on the reasons for the terrier buff (!?) and a little concerned that the pug will squeeze the spark a little too much - it's effectively a 0.175t engine with more thrust and better Isp - since that isn't really an effective size class for lifter engines. I may have to make an updated version of my command pod rejigger thread if they're open to doing this kind of work...