Dunbaratu

This is one of the many cases where just because there's a mod that does it that's still not a good enough reason to shelve the suggestion and ignore it. If everything that a mod did was never put into the stock game then we wouldn't have subassemblies, or the selection tabs in the map view, and so on.

The only problem with the idea of putting the lander can on the bottom is that you need to be a LOT more gentle when landing directly on the can then when landing on lander legs. Lander legs can support a much harsher landing than landing right on the bottom of the can can.

False. It's based on force and mass and the fact that the two happen to cancel out in Imperial units when at sea level on earth is NOT hardcoded in the defintion of what ISP means. You can always express it in terms of a unit of time, regardless of which system you are using. The fact that it happens to end up becoming exactly one second in Imperial units is NOT hardcoded into the defintion. But the fact that it CAN be expressed as an amount of time of some sort IS. You are using your dislike of the Imperial system to try to justify the claim that it is incorrect to tell people to think of ISP as a measure of time. The fact that it can be *accurately* explained in terms of a length of time is not in any way dependant on the fact that NASA used Imperial units. The fact that the unit of time happens to become exactly 1s is. The fact that it's a unit of time of SOME sort, however, is not. You could just as easily express it in MKS in a way so as to make it come out to be exactly 1 second as well if you like. The exact units used is arbitrary. The definition of ISP is not. You could just as easily mix and match units willy-nilly and express it as how many fortnights it takes to burn a gallon of fuel if pushing at a force of one nanonewton. That wouldn't change the fact that it can be defined as how long it takes to burn (some amount) of fuel when burning at (some force).

It is not nonsensical as it results in a value that is intuitive: "how long does fuel last".

Exhaust velocity is not an intuitive explanation of why the number matters. It matters because it's a measure of given the same amount of thrust, how long can the fuel last while maintaining that thrust. And the idea that the people in the US space program were ignorant of the difference between mass and force is hogwash. The fact that they're represented with the same word "pound" does NOT mean the people using that word think they mean the same thing. It was well understood that depending on context "pound" might mean a measure of weight or a measure of mass. If used in the mass context, the word "pound" changes its meaning to mean "the amount of mass that would weigh 1 pound at sea level on Earth". The metric Mks system starts from mass as a first principle and then derives a measure of force from that. The system in the US used weight as a first principle and then derived a measure of mass from that that happened to carry the same name. The fact that it confusingly uses the same name does not mean people treated them as identical. The problem is that the question "what is ISP" needs to be answered first in terms of what it means and then second in terms of what the units are that different conventions use. Saying that ISP *IS* by definition an expression using pounds is like saying that by definition velocity is meters per second. Velocity is a distance traveled divided by time it took to get that far. The fact that it's meters and seconds in one system is secondary to the definition. Just like saying ISP is the time it takes to consume a given amount of fuel at a given amount of force is a universal definition of what ISP means that works regardless of what units you use, and is much easier for people to understand.

That doesn't really change anything important in the explanation. Using different units for force doesn't change anything that matters in what ISP means. It just means you need a conversion coefficient to multiply by. When KSP doesn't really give you the exact numbers anyway it just doesn't matter. (You don't have a "how many newtons am I thrusting right now" figure.)

But that's an utter non-sequitor. The fact that you need an attachment point does not imply you can't use a command pod. Other than the stayputnik, all the command pods have at least 2 attachment points on them, so you can have an assembly dangling off one of the attachment points and yet still have an open attachment point on the other end of the command core. If you can't use a command core as the root of a subassembly, that fact is NOT something you can automatically assume from the fact that the root part needs an open attachment point.

The problem is that the error message is an utter lie. It's not your fault that it doesn't makes sense because it doesn't tell you what the real complaint is. All parts are attachable. Telling you the part isn't attachable isn't true. What it's ACTUALLY trying (and failing) to communicate is that a sub-assembly must be "rooted" on a part for which the following two things are both true: 1 - It must have an OPEN, UNUSED attachment point on it. If the part you drag has all its attachment points (the green balls) already consumed by being attached to other parts, it will incorrectly claim the part has no attachment points on it. What it's REALLY complaining about is that even though the part has attachment points, they're all already consumed. It needs an attachment point that's open-ended. 2 - It must be a subset of what's in the editor. You can't put the entire build into the subassembly tab. You must leave some piece behind. Therefore if you want to put the entire thing in the subassembly, then start it with a pointless dummy command core that you plan to leave behind in the editor. Also remember that having open attachment points at the "leaf" nodes of the assembly isn't good enough. It must have an open attachment point at the ROOT of the part tree in the subassembly. And the root is always the piece you picked up to drag. The error message is utterly useless to tell people what they need to do to get it to work. It's very misleading.

One way to look at ISP that's easier to understand (and turns out to arrive at the same number) is to think of it as an amount of time. ISP is how many seconds will one kilogram of fuel last while the engine uses it to push with a force of one Newton. Now, a force of one Newton is very small, and even at one "tick" up the throttle most engines will be already pushing a lot more than just one Newton. An engine with ISP of 800 being used to push with a certain amount of force will make the fuel last 4 times longer than an engine with an ISP of 200 pushing with the same amount of force. In real life, the same engine will have different ISP depending on what throttle setting it's on, with one particular throttle setting being its most efficient setting. But in KSP, an engine has a constant ISP no matter the throttle setting.

It makes perfect sense to me why it would be worse when looking at the horizon. If you look straight down, how many square miles of ocean are in your view? Now compare with how many square miles of ocean are in view if you look at the horizon. There's more ocean polygons on your screen when looking at the horizon.

There appears to be code in the github source that deals with saving and restoring the program state when the craft goes on/off of rails. But I've had a lot of trouble getting it to behave right so I'm not sure that part works right yet. For example, I have one program that runs just fine as long as it stays within 2.2 km, but the moment I send a craft away form it and leave the 2.2 km distance and then turn around and come back to it, the entire KSP game bogs down as soon as it re-loads, dropping to a frame rate of less than 1/sec. I'm not sure what's happening but I assume something about the re-loading code isn't working right.

Having peeked at the github code it looks like there is a calculation that makes electrical drain depend on clock speed. The faster the clock rate the faster the electrical drain. But you don't notice that this calculation is taking place because currently there's only one kind of CPU with one hardcoded clock speed. It seems as if the groundwork is there to be able to support multiple different speeds of CPU in the future.

Only if you do the sloppy approximation to an inclination burn that you get from the maneuver nodes. When you request a normal or antinormal burn from a maneuver node, you don't *really" get one. What you get is a burn in a single direction, when to stay normal or antinormal through the duration of the burn requires rotating while you burn - something the maneuver node system doesn't have the capacity to do. If you want to change your inclination by 10 degrees, for example. the normal vector will turn 10 degrees while you're doing the burn. So you have to slowly rotate through 10 degrees while burning to keep following the normal vector. It's the fact that a straight-line maneuver doesn't do this that causes your apoapsis to change.

I don't think that's true. It's actually worse than that - the higher antennae up the tech tree are listed as having LOWER percentages of science retention. If you transmit with a low antenna, it retains 0.6 of the science, but the higher ones have values of 0.4.

Right. So to ask the same question again. Is it true that it only works on the component of your delta-V that is in the same direction as your velocity vector? In other words, if you are thrusting off at 45 degrees from your current direction, Is it true that only that cos(45) of your delta-V that is in the same direction as your current velocity gets the benefit of the v^2 effect? Or if you are aimed normal to your direction, then it doesn't help at all, because none of your delta-V is in the same direction as your current velocity? Is that correct? I don't feel as if this question was addressed. I ask because I'm pretty sure that it takes a heck of a lot less fuel to change inclination at apoapsis than periapsis, which seems to run contrary to the Oberth effect unless you also add that caveat about the direction of the delta V in question.

I assume that effect only applies to when your desired delta V is in the same direction as your velocity. When burning normal or anti-normal to change inclination angle, it seems to be a lot more efficient when you're at apoapsis going slowly.

The dummy core idea fixes the problem. Thank you. The real problem is that the error message is extremely misleading. When it says there's no attachment point that's false. There's plenty of them. What it should have said is that it needs an attachment point at the ROOT of the part tree rather than at the leafs of it. That error message, while it might confuse some people who don't know about the tree structure, would have immediately made it clear to me what was going on. Simply telling me there's no attachment point when there's clearly LOTS of them just didn't help at all.

That is false. They have the green balls that indicate the attachment points. The problem is that the error message is lying to me. It's not the lack of attachment points that's the problem. It's got plenty of them. It just wants the attachment point to be at the HEAD of the part tree and not the leafs of the part tree. It's a misleading error message.

The first rocket Von Braun made for the US after they stopped asking him to just keep showing them how to launch V2's was a rocket he called "The Redstone". It was used for the first US manned flights. When you play KSP and Minecraft it brings to mind a completely different picture when you say you're going to try to build a "redstone rocket".

I thought "Orion" was the name for the concept of a ship propelled by mini nuclear bombs. Are they seriously planning on using that for a moon mission? And putting the payload "under" the Orion sounds like it would arrive quite irradiated.

I'm trying to use the new subassembly feature to build the payloads as separate subassemblies - rovers, landers, habitats, etc, with the intent of adding them to the tops of rockets later. And I just can't make it work. Every time I do it I seem to be only able to store parts that don't include the command core, which is pointless as the command core is the center of the craft with everything attached to it. Any time I try to include the command core in the subassembly, the game (quite incorrectly) claims the assembly has no attachment point, which is utterly false as the design has docking ports meant to be used when attaching to the rest of the rocket.

If its a planet where there's no atmosphere to help, is it better to aim for a pass very close to the planet, and make your retrograde please-capture-me burn close to the body? I've been doing that under the assumption that because its normal for an orbit that swoops in low to a planet to have a high speed at its periopsis, that this means the lower you are, the less speed needs to be bled off in order to get captured. But it's entirely possible that this is 100% offset by the fact that the gravity will add to your speed as you fall in close. I haven't done the math to work it out to know if it really is better or not. Is it?

It makes no sense to me why the antennae higher up the tech tree have LESS science retention percentages.

I agree. That would be a simple fix to the problem: Pure data - like numbers from science instruments, should be worth the same if transmitted as if carried back manually (if they're carried back all that means is you've carried paper copies of the electronic data you already sent. ) But, physical items, like samples, must be returned to be worth anything. So you completely split up the data into: Instrument Information only - transmission just as good as returning - so no reason to return it. (100% value for transmission). Physical things - samples and material bays - only worth something if returned: (transmission disabled- no value for transmission). That gives you two different types of mission to go on, without a lot of overlap between them.

Presumably what PatriotBob meant is that the programming is allowed to get more complex because it becomes capable of doing more things as it gets access to more information. A program will probably be simpler if it can't do much because there's not much information to go on.