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.

Pictures of the craft (VAB, pad, and in flight) will help, but here are a couple of (possible) ideas: What's connecting the station payload to the fairing base? I've found that that connection can be quite tenuous, and needs lots of care to prevent shennanigans from occurring. Are you using any form of autostrutting? If so, what to what? Edit: In response to FG's ninja, I'm focusing on the wobble here, rather than the flip (which I kind of assume is a result of the wobble).

Welcome @Kristian Kerman. It's very hard to see (I very nearly missed it), but theres a restart button on the scenario selection screen: I've tested it (once) and it appears to work. Note: This is on PC, latest version. Not sure if it's the same on older versions or on console.

Sounds like you want to play the way I do; lots of missions going on concurrently in appropriate timeslots without a lot of warping around. First thing (as @Curveball Anders says) is to get and learn Kerbal Alarm Clock - this will give you the ability to jump out of a mission part way through and come back at the next important time (even if that is 180 days away). As a side benefit, you can also set Earth-time alarms, so you don't forget to sleep ) The other mod I use a lot for this is Transfer Window Planner. This implements the functionality of Alex Moon's Launch Window Planner in the game (and should be similar to Mechjeb's porkchop plotter, but I have never used that, so I can't comment) and also has the ability to sync directly to KAC, so once you've found a transfer you can save the details directly to a KAC alarm. With these two, you can both plan ahead and find transfers that are possible even if not optimal, and jump between missions as required, so you can have a Jool probe on the way when you launch your Duna mission at the optimal launch window.

The deployable seismometer doesn't passively gather science; you have to crash something into the body to get measurements. The more massive and faster the object is moving the more science you get, also you will get more the closer the impact is to the sensor. So you'll need to, Apollo-style, crash your transfer stage into the Mun, or send a dedicated lithobraking impactor.

Nope; no oxygen in the atmosphere. Props do, though, which are OK as the OP has Breaking Ground. Or I once had an ion-powered semi-glider Eve probe (although that was so long ago I can't remember which atmosphere model it was ).

Thanks. Let me know if you think I'm wildly out with any of the volumes The old parts are still included in the mod (for backwards compatibility) but are restricted somehow from appearing in the tech-tree / part selector. I imagine it would not be too difficult to add them back (probably another CFG patch could do it), although I have to admit that I have no idea what values you'd neeed to patch in. That said, I agree with Grimmas that it's not too difficult when you get used to it. Essentially you have the following scanner types: Radar (2 tiers) - gets you low-res altimetry data SAR (3 tiers) - gets you high-res altimetry data (and biomes for the tier-3 scanner) Multispectral (3 tiers) - gets you low-res visual data, biomes, and (except the tier 1 version) low-res resource data Visual (3 tiers) - gets you high-res visual data and (except the tier 1 version) anomaly data Resource (3 tiers, plus the two stock components if you disable stock resource scanning) - gets you high-res resource data BTDT - this is the same as the previous version; short-range detection of anomalies and Breaking Ground surface features. In general, the higher-tier scanners have wider fields of view, higher operating altitudes, and greater power consumption. To be honest, the biggest thing to get used to, I think, is that the resource, multispectral, and visual scanners all require the surface to be in daylight in order to scan, which makes the choice of orbit a little more complex. Although I believe you can disable this restriction in the settings.

If you're interested in how best to achieve solar-orbit rendezvous, check out this excellent post by Claw: https://forum.kerbalspaceprogram.com/index.php?/topic/68613-asteroid-rendezvous-outside-of-kerbins-soi/

Welcome to the game and the forums, and congratulations on your first orbit The Δv required to launch into Kerbin orbit is highly dependent upon both your craft and your launch flight profile. As it says on the Δv map (I assume you mean this one), "More/less efficient ascents are likely, depending on ascent profile, TWR, and aerodynamic effects." So if you have a small, aerodynamic rocket and fly a very efficient profile you can definitely get to orbit for less than 3,400 m/s. That said, it's more likely that you were seeing the atmospheric Δv of your ship in the VAB, while the map uses vacuum Δv exclusively. This difference, which can be quite large, is caused by the fact that rocket engines (especially those designed to work in a vacuum) suffer an efficiency penalty (represented by a lower specific impulse - Isp and commensurately lower thrust) under atmospheric pressure. So it's likely that you had significantly more vacuum Δv than the 3,100 m/s displayed. I use KER (a mod) for my vehicle information readouts, so I'm not familiar with the stock game's Δv data in the VAB, but there should be an option to switch between vaccuum and atmospheric values. Ninja Edit: What HebaruSan said

Wow, I did not know that. I might have to do it before fully unlocking the tech tree in my current save just to say I've done it.

You can get techs from monoliths??