Eric S

Quite a bit of the science fiction that came out before about Star Wars would fit. Much of Heinlein's early stuff was near-future based and much harder science fiction than his later stuff, for example.

Jeb, maniacally laughing at the worst the writers can throw at him. Though none of the recent companions were quite the screamers that Bill and Bob are.

And since the engine is already being used to launch the craft, you really can't count its weight against the cost of this style of recovery. As for the fuel, the fuel will weigh less than the parachutes.

Was just getting on to say that a full reboot of the computer, thanks to a fan dieing, fixed the problem.

Also off if the engines are located above the ships center of mass, since the gimballing code doesn't take that into consideration, resulting in the higher gimballed engines fighting against the rest of the craft's control authority.

Actually, career mode isn't going to be anything like a campaign in a normal computer game. The devs have already made it clear that campaign mode doesn't follow a set script/set of missions, just that certain things have to be done before certain parts/missions become available. If you can do a manned mission to the Mun without needing anything that's unlocked by lesser goals, then that could easily be your first mission. Really, career mode is like sandbox mode but with budget/recruiting(/research?) issues tying your launches together so that it feels more like a space program than it does just a bunch of individual launches.

Yup. I've landed everywhere, and landings are still that way. As for the original moon landings, even though computers were primitive, they still had a fly by wire system that provides more help than you get from stock KSP. Not to mention the fact that they were actual pilots, had all the math done ahead of time, etc.

When We Left Earth. It's available in the Netflix instant queue if you have access to that, if I remember right.

Ground clearance may become a bit more of an issue with the procedural craters, emphasis on may.

I think Chrome 28 broke this, sadly. It still works in Firefox, so I don't think the site itself is broken. :-( EDIT: I should be more specific. The graphic isn't displaying (at all, even before I hit calculate), but everything else seems to be working fine.

Not quite true, the AIES parts pack has several antennas. On the other hand, they all have "antenna" or "dish" in the name, so maybe they could be attached to that way.

My first moon landing was with a forum posted mk59 something-or-other that I can't find anymore, thought I had seen it since the forum oops, but it doesn't look like it. Was a reasonable landing, nothing fell off. And then, when I was ready to get back into orbit and return to kerbin, out of reflex I hit the space bar. The only stage left was the one that separates the capsule from the lander/service module, so that kind of killed that mission right there.

I remember reading something about this to the effect that the fuel it uses to land is the emergency reserve fuel that is already there in case something goes wrong (like an engine failure that reduces the total TWR, causing the craft to spend more delta-v fighting gravity). So basically, if nothing goes wrong, it uses the emergency reserve to land, if something does go wrong and the emergency reserve gets used, they lose that stage. Remember, with no payload, most of the fuel gone, and atmospheric drag working in your favor instead of against you, it doesn't take that much fuel to land like this, at least not compared to launching.

Sorry I didn't make that more clear, but yes, that's what we were discussing. Basically, a craft in KSP is a tree of parts. When you attach a part to a craft, the part you attached the part to becomes that part's parent, so the attachment doesn't create a symmetrical relationship. Because of the tree structure, while several parts can share a single parent, each part can have at most a single parent part. A side effect of this is that any craft can only have a single node that has no parent, as there's no way to create a tree that has two "root" parts. So, when you're trying to attach a subassembly, with or without any of the mods or versions of mods that do this, you can only attach a subassembly by its root piece, because that's the only part of the subassembly that doesn't already have a parent. It would be theoretically possible to restructure the subassembly to change what piece is its root, allowing you to use any of the attachment points present, but that has proven to be more difficult than it sounds, and I'm not sure if it would be possible for a mod to decide which node you're trying to use and rearrange the subassembly in response.

If he means the root of the subassembly rather than the main craft, it was still true for the patched Deadbeef version, and something that people complained about regularly.

Right after the existing "Recruiting Kerbals" hint... "Checking Player Launch History.... Recruiting even MORE Kerbals."

My first Munar landing went amazingly well... right up until I went to launch, and hit the space bar out of reflex. My next two attempts both employed excessive lithobraking, so my first land and return wasn't until the fourth mission to make contact with the moon. We won't discuss the fact that the mission prior to the space bar mishap, a Munar orbit mission, had landing legs on the craft.

The truth of fuel lines: they don't actually transfer fuel, all they control is where the engines pull their fuel from. Also, you do not EVER want to have a case where you have two different routes to go from one engine to a single tank, especially not with loops. Branches that remerge can cause problems, fuel loops do so more consistently.

The problem isn't in the save though. It's in how the KSP VAB/SPH interface handles detached parts. As I said before, you can see this behavior just by pulling a few parts off of a craft. Only the part that was originally attached to the craft will have functional nodes until you reattach the assembly to the craft. This is because that part is the root of the part tree that you detached, so in order for the craft to remain a tree, that part has to be what gets reattached to the tree that represents the craft. In a tree structure, each item can have at most one parent. Only one item in the tree will have no parent, and that item is considered the "root" of the tree. On the other hand, each item can have as many children as you want. That first part is the cause of this issue. It's also the reason you can't close a loop of parts without docking rings or EAS-4 struts. Let me see if I can explain this with some ASCII art. Say you've got a capsule as the first part of your ship. We'll use C to represent that part. So your initial tree looks like this. C So C is the root of the tree. Now, let's attach a fuel tank to the capsule. We'll use F to represent the fuel tank. C <- F So C is the parent of F, and F is the child of C. Now, if we attach two RCS quads to the fuel tank, we get a tree that looks more like C <-F <-R <-R So at this point C has F as a child, and F has two R as a child. Now let's add a Hubmax. C <-F <-R <-R <-H Now, if you pick up the tank, the craft tree reverts to just C And you have a tree that looks like this "picked up" F <-R <-R <-H Now, since this tree starts at F, that can be the only node that can be reattached to the craft, since all the other nodes already have a parent node. Yes, the H part should have nodes available to connect to a parent part, but since it already has a parent, it's nodes are disabled until the tree is reattached to the craft.

That's correct, but I'm missing your point, because I don't see how that really affects the problem or the discussed possible solutions. Saved craft files still have the tree structure for parts, which is the root of this problem.

The first wouldn't help. The problem with only being able to reattach a subassembly by the part that it was originally attached to is due to the KSP tree structure and can be seen even without using subassembly manager. Create a new craft starting with a command pod (it doesn't actually have to be a command pod, just as an example). Stack two Hubmax six-way connectors under it. Pick up the Hubmax that is the center piece, so you're removing both Hubmax parts and detach it from the command pod. You will notice that the subassembly that you're holding only has five nodes on it, and all of them were on the Hubmax that had been attached to the base part. None of the nodes on the Hubmax attached to the one you pulled off are active. This will happen even in a stock game, so it's almost definitely not a subassembly manager issue. The second could have issues as well, since it would require the ability to create new parts on the fly that exactly match the subassembly, and I suspect that at least some of the parts modules may have issues with multiple parts merged into one, and that's ignoring the fact that some parts have stats on them that you don't want the entire structure to take over. On top of that, decouplers/separators in the merged part certainly wouldn't work, defeating the whole point of using a mod like this to create lift vehicles. The only possibly viable solution that I see that can be done by a modder would be as TheUndeadFish said, rearranging the part tree so that the part you wanted to attach the subassembly by to the craft is the root part. The easiest way I see of doing that would be to have an option either when you save or load the subassembly to designate a part as the root part, so that you could use the nodes of that part, or surface attach that part. Getting all of the nodes on the subassembly to activate is something Squad might be able to fix, but I don't think a mod could do that. EDIT: From what I understand about struts and fuel lines, those would probably be the hardest part of rearranging the tree, since the vector that controls which way the strut/fuel line points is relative to the root part, so changing the root part would require that vector to be recomputed.

Without Kerbal Crew Manifest, your best bet is to EVA the kerbals and then end mission them before you launch the craft (you can do that as soon as you EVA them).

Part of the difference between KSP and RL launches comes from a difference in aerodynamics. Some rockets tend to be overly stable, wanting to stay on a prograde heading, so turning them 45 degrees in one shot just isn't possible, they lack the command authority to do it. Other rockets tend to be less stable, wanting to flip around if they get more than a few degrees off of prograde, at which point trying to do a 45 degree turn in one shot is just bad planning. RL gravity turns are, as pointed out above, a small tilt at the start of the launch, and then just following prograde as the gravity turn gradually shifts the prograde from "up" to "sideways" which avoids both of these issues. If you've launched rockets using the FAR mod, you've probably seen both of these issues in action. As for why they don't have a coasting phase, this may have to do with the fact that they need three times the velocity to achieve orbit, or it could just be because they're better at planning their gravity turns. I've generally found that if I find the right aggressiveness in my gravity turn, then I don't pick up as much vertical speed during my launch, so my horizontal speed is already approaching orbital velocity by the time I reach my desired orbital height.

I think it comes down to a few factors. First is general distrust in government, or even large corporations. I've seen the government lie over little things, it's no great stretch to imagine that they could lie over bigger things. Second is the fact that people think that they can evaluate arguments for or against conspiracies using common sense. I recently decided to look around at some apollo conspiracy stuff, and while I was knowledgeable enough to be able to shred every argument I found, in most cases without doing any research, I realized that these arguments could carry weight with people that don't have a scientific background. If all you've got is a layman's understanding of radiation, the Van Allen belts can seem like a much nastier problem than they actually are. If you don't understand orbital mechanics, you wouldn't understand that reaching LEO really is well over half way to the moon in delta-V terms, despite being a few orders of magnitude short distance-wise. Look at all the "video evidence" where people are interpreting things in terms of what they know to be true because that's how things work here, when they're overlooking the fact that there isn't here, and things really can work differently. Finally, if you're not into conspiracies, you're a sheep, and sheep aren't cool. Or some such logic as that. Personally, I always kept an open mind on conspiracy theories, never really accepting any of them, but other than the apollo ones, never being sure that they're wrong either. Well, after seeing and understanding just how bad but possibly convincing the apollo conspiracies are, I've gotten a lot more skeptical about the other ones, just because I see how easy it is to sound knowledgeable when the listener is trying to use common sense rather than actual knowledge to evaluate the argument. And so, the world seems a less wonderous place to me now, which may be the fourth factor.

Does this mean that the map will update itself as deposits are depleted? Mixed feelings, though overall I think it's a good thing, just think of it as the operation that depletes the deposit registers an update to the database. Updating a map when a deposit was depleted using the old system was a pain, I usually deleted the map just so that I'd know when I had scanned enough to have an accurate map again.