LethalDose

You probably wouldn't be if you actually read what I wrote instead of the rest of community's reaction to it, but I guess I forgot which community I was dealing with.

If some people out there can understand my frustration, that's all I care about really trying to accomplish. I just hope some of them are actually in Squad and can help them pull their heads out of their freaking exhaust nozzles. Beyond that, I can only say I envy your optimism.

To any one who can't seem comprehend "the point" here it is from two other sources that aren't me: As for: Do I need to explain how disrespectful it was before and now, AGAIN!? And yes, that is the issue, they should have stated they reversed, or at least modified, their previous position. The only reason I could possibly have to criticize the developers behavior is to start a fight? Yeah, thanks. And yes, I blew him off because he forced opinions and statements on me which I never stated, held, or even implied. Directly, because he said this: I have to deal with this: In addition to that line, their front page states: and I can't count how many times they've been "OMG we love our community"So thank you for helping point out that they're hypocrites. - - - Updated - - - I'm not chastising the change, I'm expressing frustration with the way it was done. In general Squad, but even more so with Max and Felipe, have done and absolutely abysmal job with communicating with the community they claim they appreciate so much. Here, let me quote myself about what I expected or what I would find acceptable, 'cause it really ain't that much: That's it! That's all I would have wanted to hear from them. It's small, but it's important. And they couldn't even be bothered.

I don't know if it's what he was talking about in the post, but a way to generate/consume resources during time-warp almost has to be added now to support the new science-over-time generation capability of the Science lab.

Because you fail to see it, then it doesn't exist? Well, you're new here, so maybe you haven't seen how dismissive the devs are/were towards ideas like this. To the point of being disrespectful. It's simply a matter of etiquette when you change an opinion about something that you previously dismissed, you acknowledge it. The devs', and specifically Harvester's, failure to do so is, again, disrespectful. The development team has a long history of doing a crap job of communicating with the community, and this is just another example. Besides, I'm not expecting an "official letter of apology", I said "acknowledge". I never said that, so stop putting words in my mouth. This is one of the lowest forms of argument. I never said any of this, and I never assumed any of this... you're just not worth talking to.

[sarcasm] Yep, that's exactly what I said. Acknowledgment = Groveling. The two terms are completely and perfectly coextensive [/sarcasm] Thanks for the hyperbole, son. There's the door.

I expected them to say "We changed our minds about this" or "We looked at this, and realized that we were wrong about time-based mechanics being un-fun and impossible to implement". And as I stated in the OP, I expected to get lots of hate about this. - - - Updated - - - Ask Harvester! He was DEAD-SET against them! I've always thought it's absurd position!

I'm talking specifically about this line: Generating science over time. I like that there is a time-dependent mechanic is the game. I dislike that the devs decried such a system being fun or even reasonable for years, and I hate that they're changing their mind without any acknowledgment.

Okay, wow... So after years of Harv taking a hardline against including any kind of what he has referred to as "time-based mechanics in the game (namely life support and long-term research labs), we see this: In the latest DevNotes. Wait, I thought it was impossible for time-based mechanics to be fun? I thought the mere existence of time-warp would completely negate such a mechanic!? I know I'm gonna get hate for this position, but it just drives me up the wall that, suddenly, this mechanic can be fun... It is just so frustrating to see the devs do a complete 180 on these topics without any kind of acknowledgement that of the shift. I really hope they implement this right, but I'm getting really nervous about the quality of 1.0 with all these features being shoved in at the last minute without any time to test balance. And to be clear, I'm all for time-based mechanics, and if we're including them, then I think life support systems are worth being re-evaluated.

You need to check your math. Burning an escape from LKO into interplanetary space, followed by a separate transfer burn from interplanetary space is never more efficient than burning a transfer directly from LKO.

Well, What you're describing really isn't a bi-elipitcal transfer, but sorry to have wasted your time. I won't make the mistake of trying to help you again in the future...

If you're disqualifying games on the basis of procedural generation, then you need to DQ KSP as well; the craters on the Mun, and I suspect several other bodies, are procedurally generated.

I'd recommend removing and replacing ALL the fuel lines on the vessel. The fuel flow rules in this games are, in a word, dumb. It's one of the many fixes we've been promised in the release version. We'll se if that pans out. It's very possible that something didn't translate well in your reinstall. It's unlikely it's something you did, it's just one of the issues we have to live with in a pre-release game.

I think its fair to point out that Moho is the single glaring exception where your orbital position would matter in an ejection from a higher-than-LKO parking orbit, but I feel like we're all in agreement that the method is a bad idea anyway. The only reason we brought up the counterpoint was to point out that the problems with the method are not so much the positional difficulties, but increased dV costs. Also Moho is almost always the exception because Moho is a freaking nightmare of a planet to reach, regardless of method. But since you brought it up, this paragraph makes gives me the impression that you're doing direct Hohmann transfers to Moho. And that makes me very sad. I've found the best approaches to Moho do not determine transfer windows based on relative locations between Kerbin and Moho, but between Kebin and Moho's AN/DN. Moho orbits so fast that you don't need to line up with the planet on your first approach, you can just slow yourself down at the PE (which should be near to Moho's orbit) so you can catch it on the next orbit. This also reduces the TWR requirements for the capture burn, since you've already killed some orbital velocity relative to Moho. Direct Moho transfers are just bad ideas. And if you're trying to use such a complex method to approach Moho in the first place, you're either (a) smart enough to figure out when to launch from Kerbins SoI OR ( screwed from the get-go because you're trying to imitate what you saw someone else do without really understanding what's going on.

Well, technically, "sideways" is kind of a flat line But I agree, in retrospect, the shuttle kind of stagnated the space program, but I largely blame the USAF's involvement/shenanigans for a large portion of why the shuttle never lived up to it's hype.

Eh, not quite. You still need center of drag and, even with FAR, there are nuances of flight at various angles of attack that could be easily assessed via a wind tunnel.

THHHIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIISSSSSSSS!!!! I HAD to stop watching Squadcast because it was such a waste of time. Max's play isn't entertaining or enjoyable in any way, it's just intolerable. I felt like I was being punished for being interested in his announcements because he would usually, but not always, subject the viewers to 45 mins or more of his incompetence before saying anything useful. Yes, but "Serious Business crowd" are equally worthy of hearing the SquadCast announcements. And seriously, who are your long term players that have worked to help push the game forward? Here's a hint: It's ain't the ones that giggle and clap their hands everytime anything explodes on-screen. - - - Updated - - - Amen, brother.

I assume the OP was talking about largest game world, and not largest as in HD footprint, content, etc. And claiming it's the largest game world is a bit of a cheat since KSP re-scales itself at various vessel speeds as part of it's "floating origin" system.

The more I look at this: the more I love it. At least when I rearrange it to: Vbo2 = Vesc2 + V∞2 This method is so much more direct and easier than the other methods I've used to figure out IP transfer costs. Srsly, thank you for bringing this to my attention.

I don't think the timing is as big of an issue as you've presented it. Yes, the orbital period is 56 days, but these are 6 hr kerbal days. It orbits Kerbin every fourteen 24 hr days, so it's not that bad. And with some appropriate planning, you can completely mitigate the issue. The transfer windows are also typically wide enough to accomodate some fudging by a few days on each side. I've never done direct interplanetary transfers from Minmus, but I have done a handful of Minmus-to-LKO IP transfers, which are even trickier to time. I have never had a problem with Minmus being in such a bad position that I completely missed a transfer, or even had a transfer that would have cost more dV than a direct LKO escape.

While the escape velocities are calculated slightly differently in the game due to patched conics, the differences are pretty small. For example, the "proper" escape velocity from a 70 km orbit around Kerbin is 3246.9 m/s (dV = 951.0 m/s) where the "effective" escape velocity is 3234.1 m/s (dV = 938.1 m/s). That's a 13 m/s difference in nearly 1 km/s burn, just above a 1% difference. Now since these escape velocities are practically interchangeable, Vinf is a reasonable approximation of the relative velocity to the parent at the SoI change, and we can use your presented equations to answer some of the OP's questions that have kind of gotten ignored, specifcally this passage: We can translate his A, B & C terms into equivalent terms in your equation: A is Vesc B* is V∞ C is Vbo *Note this is using the OP's "Heliocentric orbit" definition Your equation can be rewritten: A2 - C2 = B2 Which can be directly rearranged to the Pythagorean theorem: A2+ B2 = C2 In this light, the triangle inequality theorem should support the OP's intuition on the following points: A + B > C C > B C > A Specifically the second point, because the OP states: However, this would seem to be contradicted by Alexmoon's transfer calculator, which I confirmed gives values similar to those in the original post: The burn is almost identical to the Minmus orbit at an even higher starting altitude of 75 Mm. And, by my calculations, the dV cost of a burn from a Heliocentric orbit at Kerbin's altitude (which should be equivalent to the hyperbolic excess for the transfer) is greater still at 2760 m/s. I think what is being missed here is the speed of the vessel relative to the sun due to it's prograde orbit around Kerbin. When orbiting around Kerbin at 100 km, a vessel has an prograde orbital velocity relative to the sun of 9284.5 m/s (Kerbin's orbital speed) + 2246.1 (Orbital speed around Kerbin at 100 km) = 11530.6 m/s. At 47,000 km, orbital velocity around kerbin is ~ 272 m/s, almost 2 km/s slower than LKO, and when starting from a slower speed relative to the sun you have to spend more dV to accelerate to initiate the transfer. I found it illuminating to to fully comparing the two sets of numbers. For a 100 km LKO burn: Vbo2= (2760 m/s)2 + (3176 m/s)2 Vbo = 4208 m/s dV = Vbo - Vorb = 4208 m/s - 2246 m/s = 1962 m/s For a "near Minmus" burn (47,000 km): Vbo2= (2760 m/s)2 + (385 m/s)2 Vbo = 2787 m/s dV = Vbo - Vorb = 2787 m/s - 272 m/s = 2515 m/s So while the target burnout velocity is smaller in Minmus escape scenario (i.e. C is reduced because A is reduced, and C > B remains true) , it actually takes more dV to achieve that velocity because the starting orbital speed is lower. Essentially, I think A, B, C's presented by the OP work provided that you remember they're true for velocities, but are not true for the delta Vs in this situation, and I think this may have been where the OP was getting hung up. Certainly was for me. And this is math doing a direct burn from Minmus' altitude, not dropping down to LKO from Minmus before performing an ejection burn. The latter is still an awesome idea that works well. Okay, I feel way better about this now. P.S. the numbers are a little rough because I was dropping decimal places for expediency. Also they won't exactly match Alexmoon's calculator because he tweaks ejection phase angles, which I'm not doing. Alexmoon's numbers should be more accurate. - - - Updated - - - It's true that increasing TWR can reduce dV costs. However, It's basically assumed, for everything presented here, that the changes in speed are instantaneous (essentially TWR is infinite). In reality, all the transfers and burns presented with have slightly higher dV costs than what we've calculated and presented, and as OhioBob pointed out, lower TWR is going to have less effect at high altitudes, but it's never really going to save you anything worth noting.

Can I ask for a clarification, OhioBob? When you refer to "hyperbolic excess velocity", is that effectively the velocity of the vessel when you leave the SoI? I understand it should be the velocity when the body is infinitely far from the parent and is no longer being affected by the parent's gravity, but with the patched conics, the parent no longer exerts gravity after leaving the SoI. If this is true, the "hyperbolic excess velocity" is essentially the target velocity to transfer from one body to another, right?

Scott Manley did a great job demonstrating into an interplanetary transfer exploiting the Oberth effect. This is the video that really clarified the Oberth effect to me. OhioBob demonstrated the math very well above for this specific case. Another way to summarize and generalize the "Oberth maths" (and how I think about it) is that that escaping a planet's gravity is about specific orbital energy ("E", and otherwise labeled simply "orbital energy" from here), which is calculated using the equation: E = 1/2 V2 - mu/r V is orbital velocity mu is the gravimetric constant r is the orbital radiuys It's basically the difference between the kinetic and potential energy with the mass term dropped (don't worry, it's cool, and I can show you why it doesn't matter if you want. It doesn't make a difference for this application). For any given orbit, E is constant at all points (all r) on the orbit. So long as E < 0, you will have a "closed" orbit (you're captured) and when E =>0, you will escape the body you're orbiting. Put another way, you can escape a planet when your kinetic energy exceeds the gravitational potential energy the planet is exerting on it. So you want to increase your kinetic energy to escape, and your KE is determined by velocity squared. You increase your KE and velocity by spending dV, and the change in E created by spending a fixed amount of dV at a given altitude is calculated: dE = 1/2 V2 - 1/2 (V + dV)2 = 1/2 V2 - 1/2 (V2 + 2 V*dV + dV2) = V*dV +1/2 dV2 Since V appears in the expression of dE (the red term in the simplification), the amount of E changes when dV is spent is dependent on the vessel's velocity. Spefically, higher V leads to greater changes in E, so you want to be travelling as fast as possible when you spend the dV to escape. So, since you tend have lower orbital velocities very high up (as high as Minmus) and you tend to have higher orbital velocities when orbiting at low altitudes, it should be clear that you want to spend dV at low altitudes/high speeds to maximize the effect of that dV. Hope that helps.

Yes, but based on your descriptions, you performed the burns in ways that aren't comparable. Since you did it this way, it seems clear that you weren't aware they aren't comparible and I was trying to explain the source of the problem to you. Sorry? As TheXRuler pointed out, KER can get confused about dV calculations when the rocket isn't a simple "top down" staging.

Personally, I don't think it's reasonable to build SSTO aircraft without at least turbojets, which require High Altitude flight, which you've disallowed. Possible, yes, but it's a major hassle. In my book, TJs really are the critical technology that makes SSTO spaceplanes feasible. With TJ's, you can add small efficient LFO engines (48-7S, 24-77s, or 909s) or O10's to complete the orbit. I know I was to build a low-tech 2-man SSTO in FAR that used 1 TJ, 2 909s, and I believe 3 circular intakes, but that was in 0.24 or maybe even 0.23.5. PS Expect someone to come in here and get snotty about how it doesn't have to be an aircraft to be an SSTO.