AlexinTokyo

This is an old thread, and unfortunately the pictures have fallen to link rot, but it explains pretty well (I think) a highly efficient and simple way to do a Moho transfer:

Not certain it's your issue, but I've found that lights absolutely murder the frame rate I get. As in, I can have a 30-odd part rover which putts around fine, but turn on the lights and the physics engine can't keep up and I go into yellow-clock slow down. I notice you have all the cabin lights on in the second station pic, so I wonder if that has something to do with the problem?

It's a mod recommendation, but SCANsat (found here) allows you to do altimetry scans which can produce slope maps. You can use those to find predominantly flat areas.

You're very welcome @Philae_Rosetta2021.

I had thought it was not mappable, but it seems I was wrong. From the main menu, go to Settings > Input > Game, and set it using "Show/Hide Vessel Labels" under the UI block:

@Philae_Rosetta2021 Are you using a laptop of some kind? Many laptops replace the standard function keys with 'useful' functions not normally available on the keyboard, which has the unfortunate side effect of making the F-keys unavailable to any other software that might want to use them. Usually, there will be a 'Fn' key somewhere which allows you to access the 'normal' function key by pressing them in combination (e.g. Fn + F4). You can also change this behaviour in the BIOS (usually) so that the F-keys default to being F-keys, and you need to push Fn + FX to change the volume/brightness/whatever your laptop manufacturer thought was more important than providing standard functionality. No, I'm not bitter about this, why would you think that? Check the user manual for your machine for details on how to change the BIOS setting.

Just be really careful trying to re-enter with it. It seems to stick out beyond the 2.5 m heat sheild and has a nasty habit of burning up as a result.

Oberth still applies retrograde, so you lose more kinetic energy the faster you're going. From the Wikipedia entry (the expample is a prograde burn, but it's easy enough to reverse it: To illustrate, here's a simple Mun encounter. At SoI entry, with a hyperbolic periapsis of 20k, it would take me 305 m/s Δv to capture into a 20 km / SoI edge orbit. This burn requires a radial-out component, otherwise the periapsis will be several km below the Munar surface. Capturing into the same (or at least a very similar) orbit at periapsis requires only 74 m/s Yeah, Tylo is great for gravity assists (you can capture into Joolian orbit for just the cost of the course correction to set it up and no additional Δv), because of it's high mass. The Mun... not so much

There's no limit as far as I'm aware, but since they're going to be in roughly the same place it can get kind of difficult to manage. Since you can never have a (combined) Δv for the non-escaping burns of more than 950m/s (or you will escape), the most common way would be to use three burns total, on of about 450m/s, the second to go right to the edge of the SoI, and the third for the remainder of the burn. Of course, it will be difficult to work a Munar assist into this, which brings me to point 2 The Mun doesn't really have enough mass (in the stock game) to make it worthwhile using it for a gravity assist. If you are going to do it (and it is definitely fun to do so), then try to make the burn as close to the surface as you can, to get full advantage of the Oberth effect (although it is much less pronounced at The Mun than at Kerbin, due to the lower mass). You can increase the course plot by changing the CONIC_PATCH_LIMIT setting in the config file (settings.cfg). This can be done in game using the PreciseNode mod (or it may be possible in stock in more recent versions, but I don't know where that setting might be). If you are trying ro raise or lower your apo- or peri-apsis, then it is most efficient to burn at the opposite apsis (so at perapsis if tyring to raise apoapsis so as to escape from orbit). Since in a capture burn you want to lower your apoapsis (from infinity), you should burn at periapsis. This also gives the most benefit from the Oberth effect.

Are those wheels tilted out of the perpendicular? I'm pretty sure that KSP wheels only have a valid collision mesh for applying power at the "bottom" of the wheel (the part that would touch the ground if mounted "normally", and having any other point in contact with the ground makes them incapable of movement. They just spin and do nothing, exactly as you have described.

OK, let's do some maths. With a starting mass of 211 t, and a Δv of 1348, you have: Δv = g0.Isp.ln(m0/m1) m1 = m0/e^(Δv/(g0.Isp)) = 211 / e^(1348.0 / (9.81 x 800)) = 177.7 Δm = m0 - m1 = 211 - 177.7 = 33.3 Ft = g0.Isp.mbar mbar = Ft/(g0.Isp) = 60 / (9.81*800) = 0.007645 So each engine will consume 7.6kg (0.0076t) of fuel per second, and your total mass change is 33.3t (in fuel consumed). This gives: t = Δm/(mbar*engine_count) = 33.3 / (0.007645 * 4) = 1088.94 (18m 9s) = 33.3 / (0.007645 * 6) = 725.96 (12m 6s) = 33.3 / (0.007645 * 8) = 544.47 (9m 4.5s) So these are the expected burn times for 4, 6, and 8 LV-N engines. I'm including all three, because I'm now confused as to which times from screenshots above refer to which version of the craft and therefore number of engines. Note of course, that the starting mass will (I assume) be slightly different for the differing variants, so the above will not be fully accurate for all iterations. So if you're seeing figures wildly different to these for the Burn Time indicated on the nav ball, then the game is having a problem correctly calculating the times. Using the above method, you should be able to calculate exactly the time required, then (as has been said) split it 50/50 before and after the node time. Since you're using KER, note that it has a burn time calculator (I think in the Vessel menu???) which I have found to be more accurate than the KSP native one. Maybe see what that says and if it agrees with KSP or with the values above. One thing that I noticed hasn't been mentioned: I don't suppose you are dropping into the atmosphere at any point during the burn (as you're starting off pointed well below the horizon)?

To give what @FruitGoose says some visual reference, here are some explanatory images: This is the default burn-time indicator. It shows the time to the node (T - 8 minutes), and the duration of the burn (Burn Time of 2 minutes). As in FruitGoose's example, you want to split the 2 minute burn so that about 50% (i.e. 1 minute) is on either side of the node. So, in the above expample you would start burning in 7 minutes (1 minute before the node time of 8 minutes) There is also an "Extended Burn Indicator" (this image) which displays a countdown to the start of the burn ("Start Burn in") as well as the above node countdown and burn duration. In this case, you can simply start burning when that countdown reaches 0. You can activte this extended mode from the in-flight settings menu (Esc menu) as below. Note that both "Node in" and "Start Burn in" are count downs, while "Burn Time" should not change once you have fixed the burn Δv. If the "Burn Time" is changing, then either your ship is experiencing some acceleration (engine on at low thrust?) or there's something strange going on. When you start burning, the Burn Time does count down; you can stop the burn when it reaches 0, at which time (in the above example) the "Node in" countdown should be at about T + 1 minute.

From the wiki (https://wiki.kerbalspaceprogram.com/wiki/Kerbin), 100% is 101,325 Pa, so 50 kPa is 50,000 / 101,325 = 0.4934 (so 0.5 is close enough for government work).

This seems to be a known issue that was supposed to have been fixed but apparently hasn't been for everyone. Forum thread: Bug report thread: https://bugs.kerbalspaceprogram.com/issues/26944 It seems originally there was an issue with mods that used non-standard EVA propellant not auto refilling (are you using any such mods?) but it also appears to affect stock users in some cases. As far as I've read, no one seems to know what the trigger is for this bug to occur. "Persisent Kerbal Loadout" shouldn't be the cause, and certainly hasn't affected EVA prop in my current 1.11.2 Career save. (That setting is designed to set the Kerbals' inventories to the same as the last time they flew, and if off will revert to EVA pack and personal parachute each time.

If the contract requirement is 'in orbit above 94,500 meters', then you are correct, anywhere in Eve's SoI (above that altitude, of course) should fulfil it.