Dunbaratu

Given how the rocketry fuel use equation works, to get a big payload somewhere it's often simpler to, instead of making one massive rocket, send it in smaller parts in multiple separate ships and then dock the parts together when they get there. One of the types of separate "ship" you can send is one in which the payload is just an unburned full fuel tank with docking ports. Put it in orbit around Jool and then ships trying to get back home can dock with it and take fuel from it. Also, get a refueling station in low orbit around Kerbin. Send lots of fuel tank payloads to it and make them contain docking rings so they can be attached to other ships. Then send your ship to the station first, pick up full fuel tanks there, and then from there go on to Jool. This is sort of just another application of the idea of sending your payload in separate launches and attaching them later. Just a warning though - a ship with lots of modules connected by docking rings in space (and therefore modules cannot be strutted to each other because they weren't built in the VAB that way) tends to wobble a bit and you'll have to make all your rotations gentle and slow. But then again, if you're going all the way to the outer planets, you've got plenty of time to wait for very slow rotations to line up your burns.

I think this bonus: - Lander tucked away behind some fairing? +5 Is utterly incompatible with this requirement: -No mods! All stock, no Mechjeb. (Did Neil and Buzz land by auto pilot?) The default fairings that come with stock parts work ONLY on engines and nothing else. To have a fairing part around any other non-engine part, you need a mod. Unless you're talking about a fake fairing composed of flat panel parts glued together.

"Up, Up, Down, Down, Left, Right, Left, Right, B, A, Start Wohoooo! 30 Lives!"

Also, if your payload fuel tank is attached to the delivery rocket with a docking port instead of a decoupler, which of course it probably will be since you want to attach more tanks chained off from it, Be aware that by default a decoupler allows fuel to flow through it, and that usually the available tank farthest from the engine gets depleted first. This means usually the payload's fuel gets burned BEFORE the rocket's fuel when trying to deliver the payload. You can either just accept this and then remember to transfer the fuel back into the payload tank from the lower tanks after you dock but before you undock the delivery vehicle (which is what I usually do), or you have to remember to rightclick the docking port prior to launch on the pad and select "disable crossfeed" before you start.

It sounds like you're talking about some sort of mod without mentioning which one it is (I've never seen balloons as a part in the VAB). But regardless one of the annoying problems everyone experiences in the game is that sometimes it locks you out from being able to switch craft or go to the space center based on rather unfair criteria. (i.e. the ship breaks, the game put your focus on a bit of debris instead of the part with controllable actions you could take to save the rest of the ship, and it won't let you use "[]" or space center to do so until the current part it picked stops moving, by which point the attempt to control the other part to save it is moot because it already crashed while the game had you locked onto the wrong part.) The only solution I've found to this that sort of works is to autosave and then after you're sure it finished writing the files, kill KSP the violent way (i.e. in Windows, with the Task Manager, or in Linux or Mac with the "kill" command in a terminal window.) Then restart the game and as fast as possible before the on-rails calculation crashes the ship, go to the tracking center and take control of the piece you wanted to. Then the game has no choice but to let you pick which ship to control by YOUR criteria, not its. It's a very crude solution and I've only had it work some of the time. I don't recommend it unless there's no other way and the only alternative is disastrous for your whole campaign anyway so it can't make things worse. (Especially since the potential exists to kill the program before it finished getting all the final writes into the save file.)

When your current course is predicted to encounter a planet or moon which is going to alter its orbit, the interface shows you two orbit prediction lines - a blue one and a brown one. The blue one is where you're going on your current path prior to the encounter, and the brown one is where your orbit is predicted to be after that encounter changes it. For some really annoying reason I continually have problems getting the game to let me click to set a maneuver node on the BLUE line when in this situation. It always instead sets one on the nearby brown line when I click on the blue, which is useless if the reason I want to do the maneuver is to change how the encounter will go prior to getting to the planet. I've now gotten into the habit of just not using maneuver nodes to adjust the encounter, instead aligning the ship along exact orthogonal orientations (i.e. aimed toward prograde mark, rotated so "up" is lined up exact with either normal, antinormal, "in" or "out"), and then turning on RCS and using HNIJKL to experimentally see which orthogonal directions cause the encounter periopsis number to get smaller, and that tells me the direction to make my more substantial burn in. (i.e. if I discover that prograde makes the number get smaller fast, and antinormal makes it get smaller slowly, then that tells me to pick an orientation partway between prograde and antinormal, but closer to prograde than antinormal, and make my burn like that. This is the sort of thing I do in lieu of being able to set a maneuver node to see where the blue mark is.) But really I want to know if I'm the only person who has encountered this behavior (can only set a maneuver node on the brown line, not the blue), and what others have done as a workaround if they've encountered it too.

Correction, it's harder than what your strawman OF me suggested. At no point did I suggest the DNA evidence comes from extinct species. I was referring to determining how far apart two modern species are based on their DNA. You can get a pretty good time estimate for the first mammal this way by looking at modern mammals' DNA. Aside from that one strawmanning of my post, the rest of your points are good and I concede them.

It's not crazy to think there's a nonzero chance of some strange form of life independently existing on the moon that is so unlike Earth life that it can live without air and without water. What's crazy is thinking that if such a thing existed it could possibly be a parasitic or virus for any Earth life. That's like thinking there could be a life form in the Sahara Desert that's a parasite that lives off of Giant Squid.

It should be noted, first off, that "mammal" is a term that has a bit of fuzziness around the edges of it. Marsupials, for example, are classified as mammals despite the fact that some of them lay eggs instead of using a womb for incubation. Secondly, fossils are only one kind of record and in fact are not nearly as good as the DNA evidence is. Many animals, not just mammals, are vertebrates, and the way the body builds bone structure looks pretty much the same regardless of whether an animal is cold blooded or warm blooded for example, and for a long time people made the mistake of thinking Dinosaurs were cold-blooded lizard ancestors. The point is that the definitional things that differentiate mammals from other groups are all tied to the soft tissues - mammary glands, hair, warm-blooded, etc - Most of the time these are not preserved in a fossil and all you see is the skeleton. The skeleton of a cold-blooded tetrapod and a warm-blooded tetrapod don't look that different. We share the same basic body plan with lizards - 2 arms, 2 legs, optional tail, 1 head, food goes in the head and waste comes out the back near the tail, and internal organs consisting of lungs, heart, stomach, intestines, throat. The basic body plan for the torso is therefore the same. The fossil record is really the hardest place to look for the dividing line between mammals and what came before. What is a lot easier to see is the DNA record in modern animals. You can identify genes that are associated with those soft-tissue traits that are missing from fossils, and compare them in modern animals to check how similar or different they are from each other, and analyzing that is the best place to get that sort of evidence.

That statement presumes the definition of "illness" only includes maladies caused by viruses, bacteria, and parasites. It also includes things that are not caused by those. A genetic disorder qualifies. Diabetes qualifies, and so on.

I'm aware that you said it in your first post. Just because you said a thing doesn't mean I agreed with it.

The majority of said replies were demanding I correct things that weren't even true about the design in the first place. It wasn't until the suggestion that it was the type of adapter that any of the suggestions were even remotely related to what I'd actually built. Your snarky tone and use of the word "despite" is undeserved trolling. When someone did suggest that solution - the first one ACTUALLY based on noticing what I'd actually built, I specifically said I'd give that one a try despite the fact that it doesn't look like it's where the flexing is happening, and then I did try it. I still stand by what I said that it doesn't visually LOOK like that's the problem. I'm grateful for the advice because the actual culprit and what LOOKS like the culprit don't match. IT looks like the docking ports are bent 5 degrees from each other, not the rockomax brand adapter and its docking port. But what it looks like and what's actually happening don't match. So I'm glad someone gave that advice - it would never have seemed like the culprit. The problem went away ENTIRELY based on just changing the type of adapter. Without changing the strutting. The reason you don't see the 6-way connecter being fully utilized is because of another bug where the attachment point disappeared in the VAB and it refused to allow anything to connect to it, which as it turns out after reporting that bug and reading the replies, is ALSO due to the Rockomax Brand Adapter 02 - that part seems to be very broken - when you attach it to other parts the other parts start acting wrong and it's not visually obvious that it's the adapter that's causing it. The original design would have used the 6-way connecter better but I got tired of fighting with the bug and just left two of the faces of the 6-way unused rather than re-designing everything from scratch.

I just tried it again, replacing the "Rockomax Brand Adaptor 02" with a "Rockomax Brand Adaptor" in the design and leaving everything else as it was. The wobble is GREATLY reduced and it's now managable. That seemed to be the culprit. I looked at the parts files for the two and I can't see any relevant difference in their stats. The only differences seem to be the coordinates for stretching the mesh model.

Even when a ship in orbit is not rendering because it's too far away it still shows a text label describing the distance away, and the colored 4-dots-in-a-diamond icon. This is a dot without any of that labeling.

So, do you think a platoon of soldiers immediately stops functioning and breaks down completely when the first soldier dies? That seems to be what your objections are based on - the idea that human beings are incapable of handling death under stress.

It doesn't look that way to me - it looks like I see the two Sr docking port halves 5 degrees off from each other. But I will try using a different size adaptor - the longer cone shaped one. I'll see if that's any better.

The description DID say that I connected together these parts IN space. Strutting between the two halves of the Sr port connector is not an option because that's the connection that is made by docking in orbit.

Incorrect. Zoom in on the picture. There is a thin adaptor between the RCS tank and the Sr docking port, and the bend is not happening at the skinny end of the adaptor, but at the "fat" end of that adaptor.

It works fine when making stations for me too - but not for making ships out if them.

"I appear to be 1 degree off too far to the left. okay well in that case TURN RIGHT AS HARD AS POSSIBLE!... Oh gee now I appear to be 1 degree too far to the right. Well in that case TURN LEFT AS HARD AS POSSIBLE!... Oh gee now I appear to be 1 degree too far to the left... well in that case TURN RIGHT AS HARD AS POSSIBLE!....Oh never mind the tail section vibrated and broke off so it doesn't matter now."

I ALSO never implied that the plan was to continue indefinitely at the very very end of your ability to exist, lingering to a slow death. This is like doctor-assisted suicide where people chose to die before it gets so far along that they're a total vegetable, except that it would be spaceflight-assisted suicide, essentially. It should be likened to the Dignitas clinic, not a bedridden nursing home. Of course, society's attitude about having the freedom to choose whether you want to continue living would have to change before such a thing would be allowed to go forward, so it's not likely to be implemented, but that's not because it's a bad idea. It's because of cultural attitudes being against it.

Seems unlikely given how it was moving. The Mun doesn't rotate fast enough, and Minimus doesn't travel fast enough, to match how it was tracking across the sky. I could visibly see it moving at no time warp (1x).

Okay, so I made a rather heavy base/rover payload vehicle for a Duna mission, with the idea that I'd have to rendezvous with my space station and pick up a fuel tank there to take with me - rather than trying to lift the fuel in one shot from Kerbin. This is what it looked like when docked with the space station: See the bit of "debris" in that shot? That's not debris, it's my main engine. I detached it on purpose so that I could pick up a fuel tank, disconnect from the station, and then using RCS only (since I don't have my engine), connect the engine up again to the end of the fuel tank, and thus now have my craft with a heavy amount of fuel to take my heavy payload to Duna. But then I encountered a problem. The sr docking port is really weak at resisting twisting. It doesn't have much rigidity and so when I would try to rotate my assembled-in-space vessel, it would almost break off the fuel tank as in this screenshot below: That's just from trying to rotate with capsule torque wheels that's it. When I tried to rotate with RCS, figuring that the RCS thrusters on the tank would help a bit by rotating capsule and tank together... Nope that didn't help either. After any attempt to rotate at all, the craft would oscillate a LOT, making it nearly impossible to line up a maneuver. Has anyone had success with assembling a ship in orbit from parts with docking rings? The problem I'm having is that normally you'd fix this sort of wobble with struts, but of course you can't do that when you're docking the parts together in space.

I've seen a moving white dot from the Mün as well and I assumed it was one of my satellites around the Mün, but then I noticed it didn't have the little text saying how far away it was, so maybe that's not it. I just shrugged it off and assumed it was n error that the text label wasn't there and it must be one of my vessels. But maybe it was this?

I tried having this policy but the "cannot switch vessels while...." (in atmosphere, in motion, etc) check often makes it impossible to get out of the game any other way other than ending the flight. I.e. if I have a kerbal stuck on a wheeled house that's in motion and the controls a broken so I can't stop it, and the house is in a dip so it keeps rolling back and forth, I can't say "well I need a rescue mission to get this guy saved" because the game refuses to allow me to leave behind that particular vessel without ending its flight and deleting the problem. The only real option other than ending the flight is CTRL-ALT-DEL -> Task Manager -> Kill KSP.