Jason Patterson

I wonder if KER is only counting the mass of parts with physics and the game is counting the mass of everything. I know that the masses in my KER don't agree with the game by a substantial amount usually.

You can allow part collisions and place two docking ports on the end if you don't want to use a bicoupler. It pretty much guarantees alignment. Alternatively, build a double wheel such that both segments must be docked at the same time - again, guaranteed alignment.

This got me with career mode on hard. I can only go to LKO so many times to gather science data before I say the heck with it and start a new savegame.

The issue isn't that the rocket equation itself is hard. It's that it's very easy to make a mistake when you're dealing with a staged rocket (which we all are nearly every time we're building a rocket) with hundreds of parts and engines with multiple Isp, and some of the parts are physicless and shouldn't be included in the total, though the game doesn't tell you which. Can I do the math? Absolutely, and I agree that for anyone who wants to be sufficiently careful, it's not particularly difficult to do any one step in the process. Do I feel that it's valuable to understand the math? Absolutely. Do I feel that it's worth any of our time to actually do the calculation (for a complicated rocket) with anything short of a spreadsheet? No, not even a little bit, unless that person enjoys doing arithmetic for fun. Doing it with a calculator alone seems like a route to frustration when you repeatedly miss a part or mistype a mass. There are good tools to do the job. If there is some particular value that you wish to know that is not given by one of those tools (or, again, if you just enjoy the DIY of it all) then go for it, but doing this yourself is on par with doing long division by hand. We all know how to do it, but if we have a calculator, there is little reason to go through the steps.

One of the real keys to getting good at this game is learning that bigger is not always better. Building a minimal ship is a skill that you'll develop over time, but with as much of the tech tree unlocked as you have, you've got more than enough parts to go anywhere in the entire solar system and come back home. Practice launching into orbit efficiently with a good gravity turn and practice landing efficiently on the Mun with a good gravity turn. If you get bored with that, try heading to Duna and returning instead; it's not much harder. (Check out this page for orbital windows for a good transfer.) Like anything, it takes practice and you probably won't do it properly at first, but you'll get better quickly. Best of luck.

I played this game far too much from 0.15 through 0.22 or so, but then got burnt out. When you've pretty much done all that you find enjoyable to do, it's time to take a break. In my case, I don't find mods to be fun at all, so I only play the stock game. Trying to do all manner of absurd missions with stock (or demo) parts or building the smallest/fastest whatever without cheats was my thing. It's been about a year, and I'm trying to get back into the game again. I'm not sure it will work - very little has changed in the way of actual spaceflight , but I am enjoying flying around doing silly things again. Regarding people ignoring your input, there are snobs on every forum, it's just something you have to deal with. Valuing post count above quality is a great way to get bad advice. The people with the highest numbers are nearly always the ones who have little or nothing to contribute but who spend all day, every day on the forum.

It is entirely possible to build an Eve return vehicle that is not a huge, bloated monster. It's just a lot easier to build one that is. I can't find the challenge thread (it may have been eaten by the forum crash a couple of years ago) but one of the "Lightest Eve Return Vehicle" type missions wound up well under 200 tons, and that isn't going to be a 700 part mission. It's still asparagus, but it doesn't have to be enormous. There and back using only 0.18.3 demo parts. (It was about an hour from launch to orbit on my old computer.) Exactly the type of vessel I'm saying not to build. (*Note: The linked video was not intended to be any sort of submission to this challenge, just a goofy video.)

But that's not the case in numerobis's situation. The way it ought to work is that as mass decreases, nothing happens, since the net force on the craft should remain at 0, with thrust and drag equal in magnitude and opposite in direction.. F = ma only really makes sense when F is the sum of all of the forces on the object (or if you wanted to sum up all the accelerations, I suppose.) That only applies if drag and thrust remain constant (or at least equal in magnitude and opposite in direction.) We know that the engine's thrust doesn't change, and since the plane accelerates, that means that the drag must.

You can just fly close to it and EVA them across if that is an option. The other choice, if it is a powered lander, is to fall in as horizontal a trajectory as you can (so that you slow as much as possible) then open just one chute. Just before 500m above the surface, when the chute deploys, burn all of your engines to slow yourself as much as possible and relieve the strain on the lander can/chute connection. Once the single chute is deployed, open all of the others immediately.

The first situation is bizarre. I can't think of anything other than a change in the navball setting that would cause that large a different between velocities, and none that would give those particular values. I guess that if the target were switched between two objects you would wind up with the same type of thing happening; in any case, it's weird. The second situation is just what happens when you have two objects in non-identical orbits. Even though you were reasonably close, 18km is more than enough difference to give large relative velocities. You would want to burn toward your target until you were closer to try to zero out that relative velocity (my rule of thumb is no more than 10 m/s per 1km separation.)

There has been talk of the ability to colonize other systems since I started playing over a year ago, but most of it has been moonshine thus far. I know that they intend to release a full featured, contained game and then produce expansions to that game later on. With the player base they've already got they'd be crazy not to. Some ideas that have been floated by the devs for interstellar travel include warp drives and collecting parts (via science?) to build a star gate. As far as I know, there's nothing even set in jello yet, let alone stone regarding colonies. I would expect any interstellar colonization to be DLC though, honestly. If you love the demo it's probably worth the money to buy the unfinished version. There's little chance that it won't be finished at some point and you'll save some cash in the process while also getting access to a fully playable, reasonably polished game. If your "No unfinished products" rule is too strong, you'll still enjoy the game when you buy it later. The only real downside to getting it now is if you go crazy and play play play then you might burn out before all of the features are released.

Editing a specific ship's parts is very difficult or effectively impossible without the help of software. There are limited cases where you can make it work, but in most situations you wind up destroying the ship completely. Replacing a vessel that is in orbit with another is fairly easy if you're careful though. Back up your sfs file. If you make even a tiny mistake it can corrupt the entire save. Copy all of the part information from one to the other and include the parts that are particular to a build (nrm, rot, CoM, and stage, I believe.) Keep the original location and orbit information. There is a third option that is probably easier than either of these. Relaunch with your new model. It only takes 5-10 minutes to get to orbit.

It's possible that you've come across a new bug, but it's very unlikely. If you launch another mission in the same way does it recur? A close pass by another body is by far the more likely scenario. Were you completely out of Kerbin's SOI when you left your craft? An unexpected pass by the Mun or Minmus can completely change your orbit, and sometimes the game doesn't track those encounters very well. My only other thought is that perhaps there was some simple recording or arithmetic problem.

It's fuel driven engines or mods, unfortunately. You could probably bodge together something crazy that uses the torque from a disconnected command module with fins, sort of a command module-propeller combo, but that kind of thing is going to be a curiosity rather than a practical ssolution.

Once you set the option that Jenteb07 describes, you have to load the particular save with debris that you want to clear. If you want debris in the game, you can then go turn it back on and it will begin accumulating anew (250 is the default value.)

Not very. If you build a rover with a flat top and place a kerbal on top hanging onto a ladder, it will slide around pretty freely as you speed up/slow down. They appear to be able to resist infinite sideways forces though.

How much extra fuel do you have when you land/launch on the Mun? If it's significant and your TWR is high enough, there's no reason this wouldn't work for both Vall and Moho.

I'm not sure what you mean. If you mean that it is most efficient to lower your periapsis by burning at apoapsis, I agree, but in general you want to slow down (ex: for landing) at the periapsis for the exact same reason that you want to speed up there. Changing direction can also be done very cheaply at apoapsis.

That's pretty much what I wrote, with a few small changes. Oberth relies on two things: Rockets work by changing a vessel's momentum. The size of an orbit is changed by changing a vessel's energy. Burning at or near periapsis always is beneficial compared to not burning there. The difference is the number of times you would have to orbit a body to do stepwise burns at periapsis to get the total delta-v you need. Mass flow rate doesn't have anything to do with it, except in regard to Isp and producing thrust. Higher TWR makes it more practical and lets you do it in a single burn instead of a series, but it is definitely possible to do a dozen separate burns at periapsis that all add up to a single strong burn.

The difference is likely due to rounding. If you used my value for G it would probably explain all of the difference away (it's only 1 part in 1000, after all.) The best that you can do is use the most precise values you can find and go with what you calculate. No synchronous orbit you choose is going to wind up working perfectly. Even real satellites have to use station keeping rockets to stay in place as a function of time. Your 2km difference will correspond to a few seconds of drifting each day for Kerbin, which may or may not be acceptable to you.

Without mods, the best and easiest way is to get your ship into a low altitude parking orbit around Kerbin and then follow the burn advice given at the Interactive Illustrated Interplanetary Guide and Calculator for KSP. It will show you where in your orbit you need to make your burn and where Kerbin and Duna need to be with respect to one another (in their orbits, that is) when you burn. 1. Get Kerbin/Duna in the right spots (just timewarp on the launchpad until they're in roughly the right place.) 2. Launch into LKO. 3. Set up a maneuvering node with a prograde burn at about the location given by the guide. 4. Adjust the prograde/retrograde burn until you get your intercept. You might need to slide it along the orbit a bit or add a touch of radial or normal burn, but for Kerbin-->Duna you ought to be able to get away with prograde only. The total delta-v should be reasonably close to the value given by the guide. 5. Make your burn. Adjust for the intercept of your choice once you're out of Kerbin's SOI. This advice will work for any pair of planets, but the more eccentric the planets' orbits are, the less accurate the guide is. It's still a good suggestion for alignment, but you'll have to tinker with it more, particularly for Moho or Eeloo.

It's not, because your value for G is wrong, but you have the right idea of how to use it. 6.67x10^-11 = 0.0000000000667 (0.---ten zeroes-----667)

t is the period of the orbit. In this case, the length of the day in seconds. Sometimes a capital T is used for period. ETA: To be clear, you don't put ANYTHING in for G other than 6.67x10-11 when you do the math. Units are just units.

Hohmann and bielliptic are really the only two types that we can realistically try in game. NASA and friends have much more computing power, both of the silicon and grey varieties, so they can handle things like fuzzy orbits that bounce objects around among low energy points between bodies and can potentially save a lot of energy. A ballistic transfer isn't anything in particular. The two words don't normally go together, but what it would mean is an unpowered transfer. Make a burn and then watch the rocket go until it gets to where it's headed.

TWR in orbit - This becomes important because orbital maneuvers need to be predictable. If you want to go from Kerbin to Duna, you need to make a particular burn to get there. Assuming you're in a parking orbit around Kerbin, the most efficient burn is going to happen at one instant in your orbit. With a real rocket, it is spread out over time. If that time is relatively brief compared to your orbital period, it is a good enough approximation of instantaneous that only very minor fudging is required to fix the burn from its idealized version. With a very long burn time (TWR<<1) the burn is spread out over a significant fraction of the orbit. This results in a very messy, difficult to predict burn. Further, it wastes much of the Oberth effect's ability to optimize your burn. By burning while slowing down you're losing out on maximum energy per delta-v. You can minimize that by making several small burns and gradually kicking yourself into higher and higher orbits, but in the end you'll have to commit and make a transfer burn, and if nothing else, your real life time is worth something here... In order to get into orbit your ship must accelerate to some velocity and ascend above the atmosphere (or at least the top of the mountains.) That change in velocity and the delta-v associated with the altitude change are the most basic parts of delta-v for ascending to orbit. If you're familiar with the impulse-momentum theorem, you can consider all forces acting in the rockets direction of motion as applying an impulse to it (F dt) and that impulse creating an associated change in momentum (m dv). That's where things like wind resistance can translate into a delta-v. The constant backward impulse from wind resistance equates to a loss in momentum that your rocket engines have to compensate for. The component of gravity that is in the direction that the rocket is traveling does the same (thus the concept of gravity drag and why we make gravity turns while burning.) I can only assume you meant TWR<=1 rather than TWR>=1. If that is the case, then yes, you're right. TWR = 1 is the case for thrust balancing weight. Anything higher and it is (at least theoretically) possible to go arbitrarily high/fast. For ascents you're typically looking for a TWR = 2. That seems to be a good balance of upward thrust and economy of scale. On planets with atmospheres it also is the most efficient way to ascend - always moving upward at terminal velocity. Once you start a gravity turn it becomes less important. For planets without an atmosphere bringing along a smaller engine (lower TWR but less total mass and greater delta-v as a result) is often a better option, but you don't want to go much below 1.8 or so for an ascent or you'll lose a bunch of delta-v to gravity drag. TWR = 2 includes drag. Isp is lower in an atmosphere because the gases being ejected from the rocket nozzle are blocked by the air outside the nozzle. They can't exit freely, at full speed, so the rocket is less effective.