Dunbaratu

I think that was what was meant by "orange". For most of us, it looks brown but maybe for someone with color vision problems it might look more orange. I assume it was meant as "the color of the ground on the ball".

Technically you could work it out if you know the ISP in vacuum of the engine(s) being used, and the sum total fuel left, and the mass of the craft, presuming they're all given in the same units (it's hard to tell since stock KSP so often doesn't bother telling you what units the numbers are in and just gives you a raw number).

In stock KSP: If you set a maneuver node it does show you the total delta-V that maneuver consists of. So you can use that to gauge things ahead of time before you do them, even if you don't actually use the maneuver node but rather just used it to see the numbers ahead of time.

Thief 2: Best. Game. Ever. Graphics are a bit dated, and were even when it came out in 2000, but the gameplay, and the sounds, and the voice acting, and the artsy cutscenes before each mission were just...... wow. It's hard to describe in just a few words what was good about the gameplay. Basically they knew they wanted and FPS about sneaking, which rewards stealth over button mashing, and makes the careful player do better than the twitchy player, and (this is very important) made your ability to sneak into a PLAYER skill not a character skill. Most modern games say that if your character has the right level of skill in sneaking the character sneaks successfully no matter how stupid the player is being at walking right through well lit areas (i.e. Skyrim style sneaking). But in the Thief series they did it *right*. They provided you with the tools for how to move the character around, how to carefully control the speed you move at with keyboard control tapping, which in turn controls how much noise you make. Then they made sure the lighting actually mattered - where the darkness of the place you stand affects how close guards have to be to see you. Then they made sure that having weapons drawn made you easier to see so you had to make the judgement call yourself whether it's better to be unarmed and sneaky or armed and visible. Then they made sure that you do very poorly if you try to fight more than one guard at a time - such that preventing someone from noticing you and raising the alarm and thus attracting other guards became more important than actually fighting him. And all of this depended on the player's skill so YOU felt like the thief and YOU felt the tension as you tried to gauge how fast to tiptoe across the well lit room to the safety of the other side before the guard comes back, balancing the need to be quick against the need to be quiet. One twitchy move too fast and suddenly you hear in the distance "Hey what was that?; and think "Yikes" and try to blend in as best you can before he comes looking for you... such a GREAT immersive game.

I think some people are saying "math" when what they mean is "arithmetic". Just because you don't use numbers doesn't mean you're not doing math. Geometry is also math. Doing vector arithmetic graphically by rulers and protractors is still math. The sort of stuff you do when you fly KSP seat-of-the-pants style is still math. Knowing that slowing your speed by burning retrograde at apoapsis will cause your eliptical path to get narrower and skinnier due to reducing the size of your velocity vector, for example, is still a form of math.

Short answer: Making the satellite less massive reduces the amount of force gravity pulls on it with but also increases the acceleration effect per unit of force applied to it... in such a way that the two effects cancel each other out exactly and the acceleration due to gravity (and therefore the path the craft follows) remains the same as it was before. Long Answer: The definition of Force is: F = m*a and the force caused by gravity on mass m1 (a ship) due to being in the proximity of another mass m2 (big planet) is this: F=G*( (m1*m2)/r^2) (Where G is a constant) Therefore if you want to solve for the acceleration on mass 1: F = m1*a, therefore a = F/m1 And what is F? F = G*( (m1*m2) / (r^2) ) So: a = G*( (m1*m2) / (r^2) ) / m1 The m1's cancel each other out and become irrelevant. a = G*( m2 / r^2 ) Summary: When you are being pulled toward another object due to gravity, your OWN mass doesn't affect how much acceleration you experience but the mass of the object pulling you does. If you reduce the mass of a satellite you won't change the satellite's acceleration toward the planet, but you'll reduce the PLANET's acceleration toward the satellite, which was already so tiny as to be unnoticeable anyway.

But you hit the spacebar each time you drop a stage. If you have multiple stages, which one do you mean by the stage action group?

Are you my ASAS unit?

The vessel stores the name of which flag file was active when it was first launched. Change the flag in the space center and you change the flag that will be attached to each flight thereafter that you start, NOT the flags for vessels that were previously launched. (Note it only stores the filename not the image data so if you remove the file later the old flags using the image retroactively get wiped clean.) When a kerbalnaut exits a vessel, the kerbalnaut inherits the flag filename from the parent vessel, so when it plants the flag it's the flag that the vessel it left from had. I don't know what happens if you EVA a kerbal from ship 1, walk to ship 2, and enter ship 2, then leave ship 2 and plant a flag. Will it be the flag of ship 1 or the flag of ship 2? I haven't experimented to find out.

It's very hard to build in KSP without at least the subassembly mod, not because of the parts used but because of the symmetry types available in the construction buildings. Ideally you want the shuttle to be built as an aircraft using aircraft symmetry rules - so you build it in the aircraft hanger, but you need to attach it to the big orange tank and the boosters in the rocket assembly building and you need to launch it vertically not on the runway. To get that combination of building techniques available requires the subassembly mod since without it you can't get BOTH airplane-style symmetry AND a vertical rocket take-off in the same vehicle. The only way to build it without the mod is to be 100% perfect in your placement of the wings because you'll have to put them on manually without symmetry help. (if you use symmetry in the rocket assembly building to build your wings, it will end up putting one wing upside down, and be only able to give you a dihedral angle of zero.)

As a final project before the big update breaks the saves, I decided to dismantle my Kerbin-orbital refueling station and use it to build an interplanetary mission to Laythe. I ended up using lots of the atomic engines on the fuel delivery ship, and the small 50-thrust engines on the lander itself (whcih was launched as a seperate ship. I sent two ships - one containing nothing but fuel, and the other containing the lander and boat for laythe: Original space station before breaking it apart and adding other modules to it: The lander/boat ship to send: The refueler ship to send: Them re-united around Jool: And after the fuel was transferred, the middle bit was removed and the lander/returner ship was ready to use:

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.