AHHans

At Mercury's orbit there is not enough "solar atmosphere" to lead to significant aerobraking. (Not really surprising.) Once you get close enough to the sun to have significant aerobraking you also face massive heating, not only from the radiation, but also from the sun's atmosphere itself. So for practical purposes it is the "same" as flying into the sun. If you bring enough of a heat-shield, then yes. (Wasn't there a probe recently that was something like two thirds heat-shield and burned away most of that while entering Jupiter's atmosphere?) But unless you are aiming for a really low orbit you probably save mass by doing a propulsive capture instead of lugging a heavy heat shield around with you. No. With a single capture burn the capture into a lower orbit requires more dV than capture into a higher orbit. (You need to get rid of more energy.) But clever use of the Oberth effect can save significant dV. A propulsive capture maneuver is the same as a transfer maneuver, except in the other direction. So once you figured out what the best maneuver for a transfer burn is, you also know what the best maneuver for the capture burn is. And in nearly all cases the best maneuver is to capture into a circular orbit is to enter the SOI with a low PE, do most of the capture burn at that low PE until your AP is where you want the target orbit to be, and then circularize at that new AP. That way you make maximum use of the Oberth effect. The exception is when you come into the SOI with little extra velocity so that the additional cost of the circularization burn is higher than the savings from the Oberth effect. I don't really understand what you want to say about the Oberth effect, but I have the impression that you didn't really understand it. The Oberth effect says that using your engines is more efficient when you do that at high speeds than when doing that at lower speeds - all relative to the system in which you want to change your orbit. Because of orbital mechanics that means doing a burn at lower altitude is more efficient than doing it at a larger altitude.

[Getting the elephant out of the room first: I assume you close the service and science bay doors before launch.] Indeed. I usually put a small reaction wheel between the pod and the parachute on my designs. You could also try to do a gravity turn where you always point surface -> prograde during the ascent through the atmosphere. That way the wind comes straight from the front, which on a craft with rotational symmetry - which your craft seems to be - minimizes the torque from aerodynamic forces. And thus reduces the need for control forces.

Hmmm... The common solution to this would be to build the rover differently. (SCNR! ) When you press the "drive forward" button, then the wheels try to rotate in a way that will propel your craft into the direction that is considered "forward" (i.e. the direction in the center of the navball). Similar for turning the rover. If the wheels are placed in a way that these directions are not well defined then - well - the results are not well defined either. If you want a more specific answer then it would help to have a screenshot of the rover.

To solve this problem AHTech Industries invented the: GeeMaster 2000 Your one step solution for all your nasty thrill seeker problems! AHTech Industries' patented "separating cabin" centrifuge technology allows you to swirl these pesky, so-called tourists around and around until their money finally separates from their wallets. After parking the GeeMaster 2000 in orbit you can use a common passenger shuttle to ferry Kerbals with a too large wallet/brains ratio to it, rotate (See the pun here!!11!) them through the centrifuge cabins, and return them back to Kerbin with only a minimal expenditure of fuel. On request AHTech Industries can also provide you with a single use design that includes a suitable crew return pod, with or without use of the special broken ground technology. O.K. marketing BS aside: Yes and no: Kerbals only register the acceleration of the CoM of the craft that they are currently on. So if you have one craft and "only" rotate that around then the Kerbals won't register acceleration because the CoM of that craft doesn't move. But if you have craft that are separate craft according to the game engine, then rotating these separate around a common CoM will expose the Kerbals in the outer craft to g-forces.

Didn't know that. But it makes sense, while the difference isn't as large as for travel on Earth you are still more likely to be hit from your prograde direction than your retrograde direction. You don't need the 10 t/m2 that I mentioned to shield against solar wind, I guess a lot less than 1 t/m2 will be enough(*). That's still a few orders of magnitude more than you want to use on any spacecraft we are going to build in RL any time soon, but a lot less than you need to shield against the high-energy cosmic rays you get from outside the solar system. P.S. (*) Oh, crud! For this kind of stuff the kind of material actually does make a difference. Heavier elements are better at shielding electrons and photons. So 1 t/m2 of air (or carbon, or water) might actually be on the low side for shielding, while 1 t/m2 of steel should be plenty.

Two comments: A) Instead of pasting the craft file here, please either provide a screenshot of the craft or upload the craft file to a file hosting service (google drive, dropbox, or whatever) and post the link here. B) The Mk1 Command Pod has reaction wheels with 5 kNm torque, the Probodobodyne OKTO has reaction wheels with 0.3 kNm torque. So it is not surprising to me that you have a much harder time controlling the rocket with the OKTO. My suggested solution would be to add another way of controlling the craft in atmosphere: either an engine with gimbaling or steerable tail fins.

Well, docking two large ships isn't really much different than docking two small ships. You mostly have to take more time and take it slow, because you can't throw large ships around like smaller ships. But don't expect to learn in half a day what took me a few months to learn. But I'm glad I was able to help.

Select "Control from here" on the docking ports that you want to use! (On both "ship" and "station".) That way the orientation (or lack thereof) of the probe core doesn't matter, and the "target" marker will point in the direction from one docking port to the other. Hmmm... Double click (with the left mouse button) doesn't work? Double click on empty space should deselect the target and double click on a craft should select that craft as a target. (Or are you playing on console?) Open the PAWs and de-select the rotation controls on all the RCS thrusters. (You may need to enable "advanced tweakables if you haven't done that already.)

Errr... Thanks, I guess. (IIRC I had only one link...) I don't actually use that too often: when you separate the controls for rotation and translation, then rotation won't affect translation (because reaction wheels can't do that) and translation won't affect rotation as long you have SAS on (because SAS will use the RWs to counteract any rotation from the RCS thrusters). Great! Practice makes perfect! (As annoying as it may be in the meantime.)

[Part 2, answers to the concrete problem:] So you have four different craft: the main ship, the payload (undocked from the main ship), the refueler, and the fuel tug. Keeping them flying in close formation is not going to be easy. I guess the biggest source of your "drifting away" problem is that the docking ports push the craft away from each other upon decoupling, so they don't even start out with zero relative velocity. But even if the did: during the time hour or so that I think your refueling operation lasts they will drift apart (see the "nitpicky" explanation above). I personally have never tried something like this. When I want several craft to stay close to each other, then I dock them together. Most of my larger craft have more than one docking port so that I can usually find an empty one to stick a temporarily unneeded part. And if I don't have one, then I'm not above using an adapter consisting of only a clamp-o-tron and a Klaw. (Make sure that adapter is always connected to something, otherwise it becomes debris.) @bewing already gave a tip on how to deal with craft that are drifting apart. My addition (or clarification) would be to regularly switch control to the parts that are drifting away and give them a push back to the main craft. (Which requires them to be individually controllable. I'm a bit confused: when you are controlling the tug and then select a docking port on the refueler as target, then you should have the refueler targeted. Not so? (And no, it shouldn't have anything to do with what you did or didn't do in the VAB.)

For all practical purposes: yes. If you are close to each other and have the very little relative velocity then you are on near identical orbits. (It is only my nitpicky part, that insists that unless you are exactly at the same location with zero relative velocity then you are technically not on identical orbits.) No. (Seriously: I thought about other smart things to say, but they all boiled down to saying "no" with more words.) Double click on the ship (or docking port) you want to target in ship view. Or right-click and select "target this" in the PAW. Careful. I use essentially the method described in @Snark's Illustrated guide to docking. Some of my space stations are quite large and with "wiggly" bits sticking out (e.g. a big-ish ship docked with a standard size clamp-o-tron). So when docking I usually don't move the "station" at all(!). (I do switch between ship and station often, to check the alignment of the docking ports, so that I don't need a docking port alignment mod. But when controlling the station I only look at the navball and take care not to give any movement input.) When the ship and the station are close enough to each other, then the orbits are also close enough that I can take my time to maneuver the ship into the correct position for docking. Typical relative velocities when doing that are < 5 m/s. (And for actual docking I usually slow down to 0.1 m/s, so that the prograde marker just vanishes.) The one thing I do in the VAB is to set up RCS and the reaction wheels so that I control the attitude (yaw/pitch/roll) with only the reaction wheels and use RCS only for translation.

@JoeSchmuckatelli, @18Watt A screenshot of the map view might help a lot.

Quick partial answer before I fall into bed: the double arrow, warp to "buttons" are a feature of KAC. In my config they are near the AN / DN markers, but do not replace them. (I.e. I still see the AN / DN markers.) The only way I managed (in a quick test) to get rid of the AN / DN markers on my current orbit is to de-select the target.

Well, the error message essentially says that something is missing. On the Kerbalism release post I see: I don't see the ModuleManager.X.X.X.dll file in your directory. I guess it is in the ModuleManager-4.1.4 subdirectory. Does it work that way?

Hmmm... Bring a planet. Seriously: the atmospheric depth of 10 t/m2 is very good at shielding us from cosmic radiation and impacts of solid objects. And being a gas that is bound to our "spacecraft" by gravitation means that it will "self heal" after every impact. If you "just" want to shield against cosmic radiation as good as out atmosphere does, then that 10 t/m2 is what you need. It doesn't really matter what material (and thus the physical thickness) that is made of. If you want better shielding then you need to add more mass, but if you think that the lack of radio-isotopes in your ship's hull - as compared to Earth - allows you to have more radiation exposure due to cosmic radiation then you can reduce the hull thickness. As for the material? Anything that can withstand the impact of (micro?) meteorites and is cheap.

Well, Kerbal Aerodynamics 201: uncovered nodes (e.g. the points where you attach fuel tanks to each other) cause large amounts of drag, both when they are facing into the wind and when facing away from the wind. When connecting nodes of different sizes then the larger node is only considered partially covered and thus still generates large amounts of drag. Using size adapters reduce the amount of drag by a lot (no uncovered nodes, but still some drag from the adapter itself). If the uncovered nodes are inside a fairing, then they don't generate drag at all. The result of this is e.g. why many designs include a small nose cone on the business end of a RAPIER: the nose-cone reduces the drag of the end of the RAPIER and clipping the cone partly into the RAPIER will prevent the cone from being fried by the exhaust.

A rocket that wants to flip is because there is more drag at the front of the rocket than at the back. So if you reduce the drag at the front then you can reduce the tendency of the rocket to flip. In your screenshot I can see a narrow "waist" in the rocket: it looks to me like you have a smaller size engine between two larger size fuel tanks. This kind of construction generates lots of drag in an atmosphere. So if you could cover this waist with e.g. a fairing then you'd have less drag fairly high up on the rocket. Maybe you have more issues like this on the rocket that you could eliminate. Another thing to stabilize a rocket in Eve's lower (below 20 km) atmosphere is to add fins with control surfaces to the bottom of the rocket. Due to Eve's thick soup they work well. O.K. That does sound like you want a healthy amount of reaction wheel power, or more gimballing on the engines. Do you have one or more Vectors in the design?

Well, at 2.5 km above the sea level of Eve you are very deep in the soup that is sometimes called Eve's atmosphere. (Ca. 3.9 atm according to the wiki page.) Don't be surprised if rocket engines designed for vacuum don't do much there. P.S. That also explains why they use fuel: they are running, they are just not doing anything.

Well, you said that you have RCS on. I assume that you also have fuel for the vernors, they need Lf and Ox. Do you have control of the craft, i.e. Commnet connection? If all three are true, then it would help if you could post a screenshot of the craft around Eve.

Well, I don't know how many hours in game it took me before I learned that Kerbals on EVA have suit-lights. But I do know, that I got really good at finding my way around a spacecraft in pitch-black darkness. I guess we all have similar stories to tell.

My post was meant as an answer to the general question about the differences between neutral buoyancy and micro gravity. About the question of babies being born (or not) in space, there are some videos from Medlife Crisis: What If Babies Were Born In Space? A Doctor Explains, and Space Doctor Analyses Medicine In THE EXPANSE. P.S. I just re-watched those two: the first is highly entertaining but doesn't really say anything about growing up in space, the second is more informative and mentions several issues of reproduction in microgravity but doesn't mention the pre-natal development of the cardiovascular system.

My guess is because "significant changes [...] to well-established HIV testing procedures in the healthcare setting" cost money. If that would be the only promising COVID-19 vaccine around then it probably wouldn't be a showstopper. But with several other vaccines to choose from then the one that interferes with established HIV testing is unlikely to be commercially viable. tldr: Because money!

Below is a screenshot of me refueling a spaceplane without recovering it in between missions: I could do that on the runway because I had the refueling truck parked next to (but outside of!) the runway before the plane landed. Depending on your difficulty settings you also have to deal with the fact that fuel may not flow through all parts, in particular not through the Klaw.

You are still experiencing full gravity. E.g. if you are upright then the blood from your legs still need to work against gravity to get back to your heart. Also you have the fluid resistance that makes moving your body around harder - and thus trains your muscles.

Oh! My desire to make a poop joke and my tendency to try to educate people are getting into a serious fight here.