Anquietas314

Arkie, sum(F) is "the sum of all forces acting on the object". m*V_theta^2/r is already included in that list - and it's gravity. You rearranging it like that just isolates the forces that are retained in polar coordinates, which normally "removes" gravity (in a sense) since your motion in a circular orbit is constant r with theta changing at a constant rate (namely your angular speed in the orbit - sidestepping the detail that the actual value of this speed depends on the strength of gravity). EDIT: I somehow missed this line: Both sides of the equation are forces. The only difference is one side has an explicit expansion in terms of F = ma.

Sounds like a feature of Kerbal Attachment System, though I think that's limited to small parts a Kerbal can reasonably carry.

Until I read that last line, I was going to ask how exactly your screenshots using the stayputnik show that it's useless, but it looks like you just added a couple extra negations you didn't intend to

Well, technically you probably could - this is kerbal technology we're talking about. The problem really is that you can't actually go and pick up the broken pieces (possible idea for a suggestion? )

Okay, now I see how you're misunderstanding this. First off, I said the acceleration has a *corresponding* force, not that actually is one, however, you convert acceleration to force via F = ma. Every high school physics student knows this (or should). Rearranging the formula is not how you convert to force, you do that by multiplying both sides of the equation by m; your equation is in the form "acceleration1 = acceleration2 + acceleration3", where acceleration3 is negative. Remember a force and its corresponding acceleration are always in the same direction. This applies just as much to you as it does me, good sir.

Not always. 90 degrees is certainly vertical, but it could be north or south depending on where you are and how the orbit is oriented. The target orbit's inclination doesn't change as you rotate with the planet underneath the orbit, but what direction the orbit's going in relative to you does.

Doing it separately, even at apoapsis, is actually not always the best approach. You should always try to combine an inclination change with another maneuver - such as your launch trajectory or the circularization burn. It will be far less expensive that way (mostly due to Pythagoras' theorem), provided you can execute it correctly. Of course, if it's a very large inclination change (>30 degrees say) or your ascending node is far away from where you're already going to be doing a burn, then it may be more efficient to raise your apoapsis/periapsis before doing the inclination change separately.

As stated, no this can't currently be done You could actually do it with the maneuver nodes in principle though, if only you could place one where your ship is while it's on the ground It might be worth posting a suggestion for it - check the "do not suggest" / "already suggested" lists first though.

LD has already addressed this, but to clarify: in my example, your V^2/R term is the only non-zero term present in a_r - and it's negative (technically positive, but a negative sign's stuck in front of it in a_r)! Since a_r is the acceleration along the radius vector, a negative term corresponds to a "downward" force. That means gravity, not lift (of any kind): lift would be an "upward" force counteracting gravity, or in other words a_r would have a positive term, which it does not for a circular orbit. Is this clear enough for you? As to whether or not I accept the equation, it's printed in your textbook which I assume passed through at least basic verification steps before being published. Additionally the equation fits with what I would expect acceleration along the radius to look like - change in r over time (in polar coords) plus gravity, so unless I were simply being thorough, I have little to no reason to question it. Technically you could say this is really an "argument from authority" fallacy, but in this case the "authority" is most likely correct. What I disagree with is your interpretation, not the equation itself. LD: I would happily test this on video for you, the only problem is my (ancient) computer lags playing KSP normally if I'm moving too fast close to the surface or there's a lot of parts on screen, and sometimes just for the hell of it. Recording software on top of that would just be unbearable. The "dot" notation for time derivatives is actually quite standard though, if a little bit strange. I'm a little surprised you haven't seen it before but I guess it's not terribly important

Given your screenshots only show you on the surface and at 12,665m (map view info tab), some proof of that would be good. (Also, it's 5:30am here I should probably be off to bed >_>)

Just to wrap this up: this post provided a link to the technical definition of "escape velocity". It seems like you might have missed it. As to your question, there are escape paths which can return you to Mun's SoI shortly after leaving it (in particular, ones that go further from Kerbin and towards Mun's prograde vector). I've had a few unexpected surprises with that back when I wasn't very good at plotting my route home

No no, that's fine I'm sure if I dug enough I'd find one of said threads, but I'm too lazy for that so I'll chalk it up to "unpleasant history" Well, that's still pretty darn fast. As a *very* rough approximation, you need to be about 5km above sea level just to be fairly safe that you're not going to smash into the side of a hill, which should put g somewhere in the region of 95% of sea level. That means around 5% more TWR which could be enough to explain ~2-3% improved efficiency.

Oh I did notice that, hence the "(constant altitude during burn)", but for Slashy's test it would actually be relevant. If you don't mind me asking, what's the deal with you and Slashy? It seems odd that you'd have such a negative response simply to him(?) posting in the thread. - - - Updated - - - Because Kerbin's gravity would take over.

It's possible to do it in less deltaV when the circumstances include dropping g (since this is a major factor in the efficiency of your ascent - TWR is derived from it). In the real world yes, technically. In theory, escape velocity is defined as the minimum velocity required to make an object "go to infinity", under the assumption there are only 2 objects: the thing with a note-worthy gravity well, and the thing the escape velocity applies to. The wikipedia page on it

Considering your result only falls short of the model by a little under 3%, call it 5% accounting for pilot error etc, it may just be enough, especially on top of the part about not reaching escape velocity (see my edit to the post you quoted)

Having quickly read through LD's paper, there is something that it appears hasn't been accounted for: g (acceleration due to gravity) is not constant with altitude (I may have simply missed it). For the purposes of the model (constant altitude during burn) that's not really an issue, but for testing it empirically (at least in KSP) it is: g drops pretty rapidly with altitude in KSP. It could be enough to explain your data, though I haven't run the numbers (out of laziness, if I'm honest). EDIT: I just looked at your screenshots; you didn't actually reach true escape velocity going by that orbit curve; you only reached the speed necessary to leave Mun's SOI (this is considerably smaller due to Kerbin's gravity well). That would also be a factor. The orbit should be a parabola or a hyperbola if you've exactly reached or exceeded escape velocity respectively. Your orbit appears to be a cropped ellipse.

I'm pretty sure that's a bug. You should add the information requested in the bug reporting guidelines (I should really just stick that in my signature at this point...)

This is already mostly how it works. The bug is that the contracts simply don't check if the "satellite" you use to complete them is the one that was launched after accepting the contract.

Those limits are for the launchpad and runway, not the VAB/SPH (though, the size one definitely should be an assembly constraint rather than a launch one). Also remember you can use the runway to launch rockets too (e.g. if you blew up your launchpad and can't replace it yet)

This needs to happen I can't even count the number of times this has been a problem for me - it's certainly in the hundreds.

So, in other words, One Kerbal to Rule Them All? Seriously though I think this belongs in the modding forum - this certainly can't be done in-game, and it may well require a plugin (or worse, replacement of stock code) to do as a mod. Merry Christmas though

Actually you can pretty much do this for any combination of parts using the MOD(Alt)+right click interface. For example, stack decouplers and I-beams do not allow fuel "transfer" normally (fuel crossfeed), and yet:

Technically yes, but the trick is that the hydrogen is heated separately in the reactor, then the oxygen is added afterwards (presumably in a way that does not allow the oxygen itself to get heated before reacting). I suppose you could say the LV-N in KSP is based on that, but at least to me it seems like the idea is that everything's just shoved through the reactor.

That's an interesting question. I think the answer is yes if one of those launches includes a power generator (solars), an antenna and a docking port. I think you can add the rest later.

Orbital mechanics are not basic, no, however the error was.