FancyMouse

Really depends on my patience. When I do have patience, I will design a really low TWR plane for maximum efficiency. That usually ends up having to dive from 8km to 7km for breaking transonic drag. When I don't have patience, then I just slam more engines and keep constant 10 degree AoA to send it to space.

It's not just water. It's literally almost everything - once you passed triple point (low pressure in here), liquid no longer exists.

Stock aero also models body lift. F12 and look for cyan arrows.

Flooding in KSC seem to spill out to space.

Are you sure you have a control point (probe core/pod/docking port) facing front of the rover? Did you try to press A when your navball looks pure cyan?

It does. It marks a red cross on the surface for your landing spot, which is not necessary at the end of your trajectory path. The path doesn't take rotation into account, but the red cross does. I don't have KSP right in front of me so I don't remember for sure if this one is an optional setting or not, but the red cross is definitely there for quite a long while and I've been using it a lot.

The font of the ship name and the version of KER is pretty alarming. You might be running an early version of KSP where all the above arguments might be invalid. That KER version seems to run on 1.0.* and IIRC 1.0.* contain a lot of heat and atmosphere changes (I remember a few of the versions it's extremely hard to enter Eve atmosphere where it was changed to be a bit easier later). So the best way is to test yourself.

What? I thought RL is a distraction from Kerbal.

Putting Nerv engines at the back is pretty challenging for spaceplanes because they easily pull CoM backwards, making it harder to adjust CoM and CoL. I guess your case is simply CoL gets in front of CoM. In thinner atmo, other stuff can still overcome aerodynamics, but when air gets thicker, you will lose control. In some sense, I think the plane isn't really properly designed for horizontal flight.

1. Make sure you're doing a Hohmann transfer (i.e. arriving in about 10 days). Any other time will increase capture delta V required. Not all 930 m/s maneuvers are the same. 2. Make sure your Minmus periapsis is within 20km. That's when burn is most effective (Oberth effect). If there's still problem, better post a picture for better investigation.

I usually start targeting docking port at a distance about 10-20m. 60m seems too far to click on any small parts on the target ship.

The biggest benefit of this plan is when there's a large inclination when ejecting. This method can correct inclination at apoapsis with minimal fuel, and then you can just burn prograde to eject, saving about up to a hundred m/s or so if the original burn (e.g. suggested by TWP) is like 2km/s prograde and 1km/s normal. It also allows an extra stage if one doesn't want to leave space debris. I do this plan a lot when leaving for Jool from Kerbin directly, for example. It's pretty useless for helping super-low TWR ejection - the 1km/s to burn to edge of SoI is usually less than half of the total dV required (I assume by using Ions you would want to go somewhere further than Duna/Eve). So the final ejection still burns more than half the delta V, which doesn't make the situation any more reasonable.

It's ok to put gears on the wings. In fact, it has automatic strutting that probably already implicitly did what other people suggested. But this kind of gear-on-wing setup puts a demand on descent rate, i.e. you'll need a slower rate of descent upon landing not to break anything. And if it breaks like you said, you typically need to land more gently (don't tell me you approach at -10m/s or even more steep). A pair of biggest gear is enough to handle half fuel of 75t takeoff weight plane (I have one of 100t takeoff weight on a pair of biggest gear on wings and it still lands normally).

Make good use of root tool (which works for inactive part tree as well), and shift click (which can tear apart inactive part tree). Anything that inactive parts can't attach - you go with the previous two methods. Subassembly is a management nightmare. Subassembly itself is stored per-save, but the categorization is stored globally (for each game). Every time you want to move stuff across game installs, or you move around the sandbox/career save for whatever reason, something is going to screwed up. So I use Merge craft exclusively, with the two methods above. Works just how it should work for me.

Interstage fairing never satisfies me in terms of the room inside, so I usually end up with just surface attaching cubic struts and start building from there. It usually ends up something looking peculiar and draggy, but at least it gets the job done.

From my experience, the most important two things are: keep vertical speed (i.e. sink rate) low at touch down (-5m/s at most, as my own guideline), and be prepared for TOGA whenever something doesn't feel right. Even if I've flied hundreds of flights now, I sometimes just fly carelessly and when I neglected any of the above, my crash rate significantly increases.

From my experience, I like putting a RoveMate into orbit, and show entire Kerbin at max FoV. I confirm it works. This way I know I'm not missing any anomalies, so I just need to cover all the surface areas. Removing ? is easy. You just plant flags for all visited anomaly (don't tell me you don't plant flags!). Then you add waypoints from KerbNet (you always do this regardless of flags) and if it overlaps with a flag, you can delete the waypoint and not plan for going there (again). This issue doesn't turn out to be a big annoyance to me after I use this method. Auto refreshing is ok. Doing it in orbit is meaningless, because even if you don't use RoveMate, the dice is rethrown each game day, so you don't gain anything by refreshing more frequently. If you're flying low or driving you can't warp anyway. Some existing easter eggs you don't even need KerbNet - their coordinates are fixed and you could just directly go there. But when you start hunting for the green monolith, which is one per body, and RANDOM per save, that's when you prove whether your method is working or not.

It's pretty delicate to operate on sfs for this matter, but not that hard. The basic principle is that every part's ID is of form part name followed by _ and then a unique integer. So if you want to change part, you can just swap the two names defined in two PART/part (but you need to swap ALL occurrences in sfs). Then also swap all the MODULEs for the two parts (so that you don't end up with LF in your cargo bay). That should do it. I do have similar scenario for me - I have a mk3 SSTO delivering fuel to my station, and payload could be LF tank or LFO tank, which of course has many stuff surface attached including wings - when I'm done with the initial version I just change the part definition similarly and I got my other flavor. Works pretty well if the dimensions are the same where I don't need to worry about coordinates, just substituting part names and adjust MODULEs.

I've never trusted hydraulic manifold exactly because of that. When I separate any stack >= 2.5m I directly go with TT-60 + sepratrons without hesitation. The extra room not only allows a clear separation, but also allows room for 6x symmetry when side stacks are of the same size as central one (the distance between two adjacent side stacks will be exactly the width of the decoupler, and the closer they are, the more likely something bad will happen)

Actually this one is possible and easy to do, just requires sfs editing - you just copy over the whole ProgressTracking scenario section. If one really cares about completed contract items, those are also copyable individually.

Here's a way without mod/map - need a little bit more fuel, though. Since you're just coming back from Mun - can't you just set up maneuver node so that your (future) periapsis of Kerbin is exactly 1 day (+- several minutes don't hurt)? That way what you see in map view is pretty much the same as what Kerbin will be when you return. Of course, this works best if you start with a Mun orbit, since you have a lot of flexibility about the ejection angle. A mere flyby might be tricker, but idea is the same. And if you're high up (like close to SoI edge), you can instead warp a little while until the periapsis is a whole number of days away, and then you start tweaking (this time mostly inclination change to adjust periapsis location).

"When should I go to sleep"

It's simply just not enough intake. Even a large circular intake cannot supply a Wheesley at stationary. For planes it works fine because you can still pick up speed, and intake immediately grab more air because you have a nonzero air speed, and that's a positive feedback that drives intake usage to 100%. However this one critically relies on an initial TWR>1 to lift off. To bust previous theories: During spooling up, KER will show TWR to be like 0.8/2.6, i.e. the first number will be smaller, which is not the case here. In flight KER picks up realtime thrust/weight data, so it has nothing to do with theoretical max thrust or anything like that.

There's the fun part - if you want to minimize life support resources, you actually could catch two consecutive windows (to and from Duna) and you won't even need a full year of resources for the round trip. I barely remember that the key is you just need some extra fuel so that you arrive at year 1 day 400 or so. 30 days of activity is actually pretty tight - IIRC it's reasonable if the activity is controlled under 10 days or so - you'll need to play with TWP and find a good spot for both going to and coming from Duna. Tip for using TWP in this scenario: set both x and y axis to be the same scale (meaning trip time max-min equals departure time max-min). Then you'll know that each 45 degree main diagonal line is corresponding to an arrival date. For any desired arrival date, you could find the diagonal line, then find the best transfer by inspecting that line. This is how I send my elite 4 to Duna and return to Kerbin as early as possible (back on year 2 day 200'ish).

At a time I was feeling the same thing, until I realized after one months IRL that my game time only advances a month as well, and my lovely motherships will never reach their destination - nowadays I'm forcing myself to advance at least 10 days for a single day IRL, if I'm playing career and outside VAB/SPH. And it's already answered why you get Kerbin contracts so often. My solution is, I often modify my save file to tweak different contract weights. I'm not completely avoiding contracts on Kerbin but its weight is already the lowest and I let contract system to decide how often to offer me such thing. Result is acceptable to me.