Streetwind

Whenever this question comes up, I like to link this guide. It's very old by now, and its snarky comments regarding KSP's poor drag calculations are outdated and no longer true. However, all the construction principles remain just as relevant today as they were back then - and I have never seen them explained better in any other place. (And yes, it does address the very common problem of veering off the runway on takeoff.)

There were dev statements along the lines of "the need to keep Kerbals alive will be a thing at some point". You could read into this that there'll be a stock life support mechanic, but I'm not so sure about that. It could simply be that those game mechanics that specifically deal with long-term in-space habitation - i.e. colonies and interstellar spacecraft - will require you to include special parts for life support. But not regular missions, and not in the sense of having actual resources onboard. For example, a colony might not be "complete" until it has a greenhouse. An interstellar craft might not be "complete" until it has cryopods. Or whatever else you can imagine. As long as these parts are present, the life support requirement is ticked off, and everything is fine. That way the game would not need to bother the starting player with budgeting life support resources on their first Mun flyby. But it would have an answer for the question that started this thread. And if players want more, there will most assuredly be mods. (All of the above is, of course, pure speculation.)

Don't modify internal files - use ModuleManager. That's what it's for! But yes, you can swap out audio and visual effects on rocket engines. Doing so is fairly work-intensive, as you'll likely have to adjust offsets on the flame to get it to sit in the right location, which requires repeated testing and tweaking. But it can be done. Look for the EFFECTS { } node in the part config. Most engines have one of them. A few really old ones, like the LV-T30, don't. In that case there'll be some entries directly under the PART { } node. I would recommend patching those out and introducing an EFFECTS { } node if you decide to mod it, as the node can simply do much more than the old way.

@The Aziz In chapter 3.1, at the bottom, you mention the Labradoodle engine, but there is no picture for it. Well, in this latest dev diary, there is one! Together with the Mammoth II, and the Rhino (which I think also hasn't been shown before).

This is true in theory, but they might become so when developer time is factored in. After all, once you give people the expectation that celestial bodies have more than one reason to visit, it significantly raises the work required to add a new celestial body in a way that fulfills these expecations.

Oh yeah, you could absolutely do something with anomalies. Mixing a few hand-designed locations into the procedural generation sounds great too, if potentially difficult to pull off with the PQS system. (Let's be honest, KSP1's anomalies often stuck out like a sore thumb.) EDIT: I'd like to add, since it was left out of the quote, that I deliberately framed that idea in terms of the original KSP1 contract system, to have a common ground that everyone understands. I obviously expect KSP2 to work differently, and thus the actual implementation would likely be markedly different. It's all about giving reasons to go to celestial bodies more than just once or twice, by providing something interesting that pops up later-on.

Honestly, I'd prefer more stuff to do on existing planets over just more planets any day. "Stuff" here meaning interesting reasons to return to the place. In some sense we're getting that with colonies, sure, but I'm pretty sure you won't need a colony on every planet to build yourself an interstellar vessel. You can probably make do with two, or at most three colonies among the stock system's 14-ish colonizable bodies. I'm thinking more akin to small... "storyline prompts", for the lack of a better word, that give a sense of the Kerbals actively exploring space as opposed to just putting flags and footprints everywhere because they can. Something akin to, I don't know... let's think about it in terms of the KSP1 contract system. There's no guarantee KSP2 will have anything like it, but it's a frame of reference we all have, so we can understand each other. You get these "Explore" contracts for each body, like "Explore the Mun", which first has you go there and orbit (if you haven't already), then go there and land and return. Now assume that you've done that for the Mun, and you've also done that for Ike. The game knows this, and because you have both, you now unlock a new unique mission that requires you to land a seismometer in a specific location on the Mun and another in a specific location on Ike and keep them there for a few months, because the scientists ran across a weird and unexpected similarity in the way these moons might have formed, and now they need more data to confirm or reject the hypothesis. It would be a delightfully unexpected reason to do another Mun mission even when you're already going interplanetary - and one that does yield new science even in already-harvested biomes, plus an interesting little story tidbit that lets us learn more about the celestial bodies that we explore. And how deep does that rabbithole go? Maybe if you completed the moon formation study on Mun and Ike, then something new might unlock at Jool too... or perhaps even in another star system... This would be far more interesting to me than having a Gas Planet 2 where I'm puttin an unmanned probe into orbit, press an action group to transmit all science, and then switch back to the Space Center View to do something else.

@Richmountain112 Dude... this thread is almost eight years old... please don't do that.

I'm a minimalist to a fault, and few games have aided and abetted that as much as KSP. Because here, downsizing and keeping things simple actually makes your rockets go faster and further! So I have a sneaking suspicion that any craft I'll build, for any purpose, will be no larger than absolutely necessary and carry no more stuff than absolutely necessary. That doesn't mean that those crafts will necessarily be low-part and single-function, oh no sir. Here's an example of something I launched once in a modded playthrough. It contained an entire 4-piece commsat constellation plus an entire 4-piece ScanSat terrain and resource mapping constellation plus a science lander capable of landing on Ike, sending science, taking off, and then landing on Duna and sending science from there as well. All in a single fairing, on a single rocket, in just 46 tons and 150 parts including the launch clamps. So no, not simple. But the scale and mass budget should give you an idea of how I like to build. If you strip everything out that is not absolutely needed, you can fit way more on a single launcher - and thus, why launch more than once when you don't need to? Incidentally, that was also the first mission I sent towards Duna in that playthrough. Why bother launching for anything less? With surface colonies, though, I can see myself greebling and cluttering some. To make the place actually feel organic and lived-in, you know?

My biggest wishlist item is some form of configurable rescaler mod, like Sigma Dimensions. Part mods can be nice to have. New mechanics can be hit or miss. But I've already determined in KSP1 that I personally like a 2x or 2.5x scale better than stock. Given that we'll be flying in the same solar system to start with, I expect this to hold true for KSP2. At the same time, I don't think this feature will be stock. Ergo - mod, please!

Option A: you've fitted bipropellant engines but only supplied liquid fuel (no oxidizer) Option B: you've fitted airbreathing engines but only supplied liquid fuel (no air intake) Option C: you've placed a part with no fuel crossfeed between your engine and your fuel tanks Option D: you've installed one or more mods incorrectly and have broken your engines Option E: None of the above, and you will post a screenshot to illustrate Pick one (and welcome to the forums!)

There are apparently a few bugs with Kerbal inventories in the latest versions (1.12.2+). There's also a mod that fixes them, among other things.

I think when he said "in game time" he literally meant the date/time in the game. If the challenge is to land on the Mun as quickly as possible, then out of eight players, the winner is the one who manages it on the earliest ingame timestamp. Doesn't matter how much IRL time anyone invested. That way, someone who can play only thirty minutes per evening can meaningfully compete with, and even win against, someone who spends all day in front of their computer. It all depends on how efficiently you go about the task.

Stock is meant to be playable and fun. That includes letting you make sharp turns while buzzing the tower at mach 2. FAR is meant to be realistic. That includes violently ripping your wings off if you look at them wrong while in the lower atmosphere. There's a time and place (and player type) for each of those. The great part is that we get to choose!

Your description tells us close to nothing, so we can only guess... ...but my guess is that your combined center of thrust is not pointing through your center of mass. In other words, your engines are thrusting off-COM and creating torque that turns over your plane. Imagine if you built a bog standard rocket, but instead of attaching a pair of solid boosters, one on each side, you attached only one booster to one side. This rocket will not fly straight - it will constantly turn sideways. Because the single SRB is not thrusting through the center of mass. It is hanging off to the side, and there is no matching booster on the other side to counteract the torque it is creating. The same principle holds for planes, except worse. Because people have this image in their head of "I can just sling my engines under the wing, that's what they do IRL". No, you cannot "just sling them under the wing". If all your engines hang below the center of mass, they torque your plane head over heels whenever they run. Real-life planes are far more complicated than you think, and not all aspects of aerodynamic flight are precisely modeled in KSP. To check if this is your problem, you can turn on the display for center of mass and center of thust in the hangar/editor. If the arrow representing the direction of thrust is not pointing precisely at (or through) the COM, you'll need to rebuild your plane.

Sorry for the dumb question but... is this the correct solar panel? You're floating in front of a fully extended panel. Perhaps the one you need to repair is not this one, but rather a different solar panel, which is not currently extended (because it is broken)? Isn't there a mount visible on the opposite side of the truss in this picture? I'm not sure if it is another panel, but it well could be.

7 is the actual value you will get getting. The -3 tells you that this used to be 10, but something is modifying the contract to pay out less reputation. Could be a strategy activated in the admin building that does this, for example. Your reputation is simply a number that adds up. In your case it will increase by 7 when you complete this contract. You cannot directly see the the sum total you have easily, but the higher the number is, the greener your reputation indicator in the middle of the top bar in the space center view becomes. Reputation has diminishing returns. The sum total always increases linearly, but you get less and less from the same increase the more you already have. That doesn't really matter though, because reputation has close to no discernible effect on your game as long as it isn't negative.

Burning straight ahead for long enough in any direction should eventually get you into solar orbit, barring collisions with Kerbin, Mun, or Minmus. Expect to spend about 1000 m/s worth of dV (or a bit less, depending on your starting orbit around Kerbin). However, your resulting solar orbit is shaped by the direction you chose. If you chose to fire your engines in the direction of Kerbin's orbit around the Sun (prograde escape, nightside burn), then your solar orbit will have a raised apoapsis on the other side of the sun. You use this maneuver if you wish to go to the outer planets. If you chose to fire your engines opposite the direction of Kerbin's orbit around the Sun (retrograde escape, dayside burn), then your solar orbit will have a lowered periapsis on the other side of the Sun. You use this maneuver if you wish to go to the inner planets. If you pointed neither directly Kerbin-prograde nor Kerbin retrograde, but still within the equatorial plane, you will get less of a raising or lowering effect, depending on how far off you were. The energy will get put into a radial shift instead, but those are subtle; your solar orbit is is incredibly high energy compared to anything you do around Kerbin, and thus, spending a few hundred m/s in radial will hardly move it. You can use such an escape burn in niche situations. For example, if you use a transfer planning tool/mod to compute transfers to other planets, they will sometimes give you a burn that goes partially radial in order to correct for being somewhat out-of-window. And personally, I like to use a burn 45 degrees off Kerbin-prograde towards the Sun for my very first dip into solar orbit for science collection, where I just want to spend a minute or two there before getting recaptured by Kerbin. It is easier to get that quick recapture if you're not immediately starting to climb towards Duna the moment you exit the SoI. Finally, if you pointed up or down with respect to the equatorial plane (normal/antinormal), your solar orbit is going to be inclined. Not as much as you think, though. Your inclination will be that of the point where you exited Kerbin's SoI. So the highest inclination solar orbit that you can possibly achieve with a full 90 degree up or down burn is the inclination of the northern or southern tip of Kerbin's SoI, which is... uh, I forget. A few degrees. You can use escape burns like this to help you hit an inclined target orbit, but only if (in addition to the transfer window being open) Kerbin is reasonably close to an ascending or descending node of the target orbit. Most of the time, you'll only use an inclined escape burn because a transfer planner tool/mod told you to.

What @jimmymcgoochie described is pretty much how I always did it as well. 1.) Plan normal Mun transfer, 2.) add some extra dV juice, 3.) move maneuver node counterclockwise around Kerbin until a new encounter shows up, 4.) finetune that encounter into a free return trajectory. You can also go into the game options in the main menu and use the slider there to configure how many SoI changes ahead the trajectory simulation allows. I think the default is 3, you can raise it to as much as 5.

The way back from Jool is typically more expensive, regardless of what conventional wisdom says (orbital mechanics doesn't always obey dV maps). But not that much more expensive if you find the right transfer. Finding it is not always easy though, and that may be what tripped you up. Let me explain, using Alexmoon's handy calculator: (The calculator assumes performing the burn in an equatorial orbit around the origin body, 100km by default, though I set 200km for Jool. I also checked the box for "no insertion burn", since we're only interested about departure burns here.) The earliest available transfer window would have you leave Kerbin for Jool on year 2, day 256. expending slightly less than 2000 m/s (departure burn only), and arriving year 6, day 161. If you look at the porkchop plot (the colorful chart at the bottom), you'll see that there are clear vertical strips of color, red morphing into blue morphing into red, back and forth. The X axis of that chart is the departure date; the Y axis is the travel time. Mousing over the chart will show you a dV cost for that specific combination of departure date and travel time. You can also click the chart to get directions for executing that particular transfer, but the calculator will have the best one pre-selected. The thick, even vertical bands, and the huge differences in dV costs between red and blue areas, show a strong dependance on transfer windows. If you pick a departure date (X axis) within a red area, then no matter where you move the mouse on the Y axis, it'll always be in a red area, and the dV costs are always going to be high. Leaving at that date is a bad idea. You have to wait for the right time. Assuming you took that transfer and arrived on year 6, day 161, the most convenient window back would then be on year 6, day 365, expending some 2930 m/s. You can compute that transfer by swapping origin and destination, and adjusting the earliest possible departure time to the time of your arrival from the first transfer. If you look at the plot of that calculation, however, you'll see a completely different picture: the colored bands are not nice and thick and vertical, they're extremely slanted and pretty thin. The difference in dV costs between red and blue areas still exists, but it's much smaller than it was with the Kerbin->Jool trip. This shows a weak dependance on transfer windows. Each point on the X axis is going to have at least one blue band somewhere, possibly even multiple ones. Meaning no matter when you want to leave, there's a cheap transfer you can find. But the same applies to the red bands. Each point on the X axis is going to have at least one red band somewhere, possibly multiple ones. Meaning no matter when you want to leave, there's room for finding a terrible transfer that has you paying way more than you should. And though the differences between the best and worst transfers are not as bad as they could be, they might well be enough to make or break a mission. When you're sitting ingame without any such handy tools available, just pulling the handles of a maneuver node until you get an encounter, then it's quite possible to accidentally find a pretty bad one. An experienced player might be able to tell that they're being overcharged, and will continue looking for a different route, but someone on their first trip to Jool wouldn't know any better.

Did you wait for the correct Jool->Kerbin transfer window? If you try to leave Jool just whenever you feel like it, you'll pay for an extremely expensive transfer.

According to the screenshot, you are in docking mode, which remaps some of the controls. Ensure you are not in docking mode by using the top or bottom of the four buttons on the righthand edge of the UI element on the bottom left corner.

Independent of how KSP2 looks compared to modded KSP1, don't forget that KSP2 itself can be modded. Indeed, it should be easier to make graphics mods for KSP2 than it is for KSP1. Development with an eye towards moddability from the get-go, a more modern rendering engine, and leaving behind a lot of legacy cruft and idiosyncracies. I don't need a magic crystal ball to predict that there will certainly be modders who will take it upon themselves to crank the visuals up several more steps. Doesn't matter how good it already looks unmodded. There's always room for moar visuals, just like there is always room for moar boosters

I'd just like to point out - landing a probe with a single ion engine on Moho absolutely can work. I've done it before. It just can't be massing two tons. You can get about 1.5 terminal TWR out of a single ion engine while still doing some useful science. It's not fun or easy to land with that, but it's possible. Sample probe: 1x Dawn engine, 1x HECS probe core, 1x radial xenon tank, balanced on the other side by 1x DTS-M1 antenna, 2x OX-4L panels, 2x Z200 batteries, 1x thermometer, 1x barometer, 1x seismometer, 1x gravioli detector. Wet mass 529 kg, dry mass 489 kg, wet TWR = 1.400, dry TWR = 1,515, wet dv = 3238 m/s. You could shave off a battery but I packed two for the sake of the antenna which is pretty hungry when transmitting. Solar panel output should be above 21 EC/s before heat losses, so the engine is going to be fine even with a slightly unfavorable sun angle. The descent trajectory should still be chosen so that the solar panels remain in sunlight - i.e. ideally a polar orbit around Moho aligned with its solar orbit. This will also prevent you from losing your commnet link. The probe has no landing legs, so it must balance on its engine. The HECS' reaction wheels should help keep it upright as long as it has power. If the probe did not spend too much dV maneuvering prior to descent, and you're worried about falling over and/or losing power while on the ground, you might have enough dV to get back to orbit before starting to transmit your surface science.

Yes, you can - because two docked spacecraft aren't two spacecraft. They are one. The docking procedure merges them into one vessel under the hood. As such, there is no problem with attaching parts to both of them.