Streetwind

Whether wing aspect ratio and/or wing sweep matters. And while I doubt the devs would go there, might as well check for area ruling.

Then you haven't looked at this one. Generally though, you can guesstimate yourself a way to a transfer window in this case because they reoccur so frequently - once every seven Kerbin days, roughly, maybe a little quicker even. Just plot a transfer that touches the Mun's orbit, and see if any close approach markers show up. None visible? Kill the node, timewarp a bit, and try again. You can make informed guesses as to roughly when you can expect to see something by looking at the time to periapsis of that transfer. If it takes you two days (completely made up number btw, I don't know what it is ingame), and you know that the Mun orbits Kerbin roughly every six and a half days (this is the real, proper value), that means that you should look for a transfer when the Mun is roughly one sixth of its orbit ahead of Minmus (because then it has one third of its orbit, or roughly two days, to get to the point where your transfer will meet it). You could also just click the "orbit forward" button on your maneuver node a zillion times to move it into the future until an encounter happens, if you were less inclined to think and more inclined to click a button a lot.

I... was pretty sure? When playing I plan out missions like that somewhat regularly, making three or four successive nodes to visualize the path I will be taking and the intercepts I'm going to get. I suppose it depends a lot on whether you're actually making the second node on your current orbit, and not on the first maneuver node's projected orbit. Since the first maneuver node will have no dV in it, its projected orbit will be the same as the current one, and they will overlap. My first instinct is to say that that's a case to avoid, as I would not be able to guarantee clicking the correct orbit every time. It should be safer to first create a node with dV and then clicking that projected orbit for the second node.

That would be my technique as well, but just to add: you need to make these nodes in reverse order. First a node you can add dV to, and then a second node you can use to calculate future intercepts. Otherwise, if you made the future node first, then any additional node you place after that would be happening after that future node. You need it before. Make liberal use of the ability to move nodes along the orbital path, to find the optimal place for your minimal burn to affect the desired outcome.

I usually don't suggest this, because I'm of the opinion that it's an unnecessary crutch in 99% of all cases... but for planes, it might actually be required: Have you tried autostrutting every part? Especially the wings, and the parts the wheels are attached to?

Is this a trick limited to a select few engines, or is it supposed to work with all engines? I was doing a silly thing on a lark where I was trying to get something into orbit with nuclear engines alone for propulsion, which is obviously tricky given that the LV-N alone without any fuel or other parts has something like 0.5 TWR at sea level. I got pretty far but felt like I had drag issues, so I tried the nosecone trick. Didn't work on the LV-N. Or rather, it might have worked if I could have flown, but I couldn't, because the nosecone blocked all thrust even when clipped deep into the nozzle. Have you ever tried it with a LV-N?

Vessels in KSP exist in two states: physicalized, and "on rails". Only the vessel you are currently focusing on, plus everything around it in a bubble with a radius of 2 to 2.5 km, is physicalized. Everything else is packed up and put on rails, and only unpacked again if it comes close enough or you switch focus to it. A vessel that is on rails does not have any physics calculations performed on it. It does not check for atmospheric drag, it does not change its speed or orbital parameters for any reason, and it does not process collisions. Not even with the ground. They phase straight through. Because that makes no sense, all celestial bodies have a certain altitude threshold below which on-rails vessels simply get deleted, as a stand-in for colliding with the ground and/or burning up in the atmosphere. As you left Bob behind, he was put on rails. The game then checked his altitude above Kerbin sea level, eventually concluded that he was too close, and deleted him.

Yes. a - c is the periapsis altitude, and 2a - (a - c) is the apoapsis altitude. No, because an orbit needs additional parameters. For a given AP/PE pair, there is an infinite number of possible orbits. You need to narrow it down further by supplying an inclination, and a longitude of the ascending node. That still leaves you with a technically infinite number of solutions, albeit in a narrow band. Specifiying the argument of periapsis finally results in a single, precisely defined orbit. https://en.wikipedia.org/wiki/Orbital_elements

KSP2 was planning to do future propulsion concepts and interplanetary flight long before they hired Nertea. Since Nertea's mods often implemented proposed realworld concepts, it's unavoidable that there would be some overlap. That said, it's not impossible that he did work on some of these parts. I imagine that might have felt odd to him as well

Have you brought oxidizer? Plane engines typically run on liquid fuel alone, and this includes the RAPIER engine in open cycle mode. That is because they harvest oxygen from the atmosphere to act as oxidizer. To switch the RAPIERs into closed cycle mode, they need a new source of oxidizer that isn't harvested from any atmosphere. Meaning, you need to bring some in a tank that they can draw from. Did you?

There is no single "best day", as orbits are endlessly repeating, and thus transfer windows between orbits are, too. When the origin and destination orbits are inclined relative to each other, and/or eccentricity comes into play, not all transfer winows are equal; some will be worse, and some will be better. But let enough time pass, and a good one will come around again. I wrote something about the nature and frequency of transfer windows in the past that may help you understand it better. But if that didn't help, feel free to ask what exactly you find confusing, and we'll try to clear it up.

Agreed with Zacspace, you are way outside the transfer window and forced the transfer by spending a massive amount of dV at Kerbin. Now you are traveling at a very high relative velocity to Jool. When flying to other planets, the dV cost and quality of transfer depends strongly on when exactly you leave. Origin and destination must be in the correct alignment with each other. The game should provide you a list of upcoming transfer windows in its alarm clock tool.

Rendezvous are a multi-step process, and it's hard to figure out how to help you if your description of what went wrong isn't a bit more detailed. Generally, it involves five steps: (1) get into a similar orbit, (2) match inclination, (3) match the orbit, (4) phase the orbit, (5) match the target. However, the order you perform these steps in isn't set in stone. Even "get into a similar orbit" doesn't necessarily have to come first, despite what it might sound (but to be fair, in most cases it does come first). You make the call what you want to do next. It is not uncommon to do some steps more than once, edging a little closer each time. As an example, let's take a rescue contract which is in an 80km by 90km low Kerbin orbit with zero inclination. If I were to do this rendezvous, I would... (1) ...start by launching into a similar, but intentionally not too similar orbit. Something like 75km by 75km. The more the semimajor axis (think average altitude) of my orbit is different from that of the target, the quicker it is to phase the orbit, but the lower the precision will be. I will typically time this launch so that the target spacecraft is directly overhead the launch site, so that I insert into orbit slightly behind it, but it's not a necessity - it just makes the process faster. (2) I'll select the marooned spacecraft as my target, so I get an AN/DN marker. I'll make a maneuver node there with a plane change to cancel out any minute deviations from 0° inclination that I may have picked up during launch. Even a tiny inclination mismatch can screw with some of the later steps. (3) Then I will look at where the target spacecraft is along its orbital path, relative to where I am. Because I am in a lower orbit, I want to be behind the target (hence my launch timing in step 1). Lower orbits are faster, so I will be catching up to my target from behind. Now a judgement call must be made: am I close enough behind? Not close enough? Too close? The answer depends not just on the current position, but also on the difference in orbits. The greater the difference in SMA, the faster I will catch up with the target on each orbit around Kerbin, so if I am really close to the target but the orbits are too dissimilar, I will overshoot. It is best to err on the side of not being close enough, both in your launch timing, and in selecting how close you make your approach orbit to that of the target. (3a) To help this judgement call, I will make a maneuver node somewhere ahead of me, and give it enough dV to cross the target orbit. This will display a close approach marker, and also fill in numbers in the rendezvous tab of the flight data display in the lower left. I will then select the maneuver node and toggle it one orbit ahead into the future. The close approach marker and data will change. If the marker jumped ahead of the intersect, I am too close, and must either force a rendezvous immediately, or pass the target and wait a week or two to come up behind it again, or pass the target and then assume an orbit higher than the target so that it will begin catching up to me instead and I can do the rendezvous from the other side. If the marker is still behind the intersect, I will push the node another orbit into the future. (3b) The goal is to get myself into a position where the maneuver node shows a close approach marker more or less on top of the point where the orbits intersect at some point in the future. There will typically be two such points, and having a close approach at either one is fine. This whole process of one spacecraft catching up with the other is called "orbit phasing", and its purpose is to get both spacecraft to arrive at the same point in space at the same time. It doesn't matter how well I match the target orbit if I am not phased correctly and thus will never be in the same place as the target at the same time. (4) Most often, I will not get a close approach marker on top of an intersect, no matter what I do. I just blindly picked my initial orbit, after all, so there's no guarantee that it is suitable for rendezvous. If this happens, I must match orbits better. I will typically phase the orbit until I am quite close behind and in danger of overshooting soon. Then, I will make a maneuver node next to the target orbit's periapsis, and make a burn to roughly match apoapsis. My orbit will turn from a 75 by 75 km orbit into something like a 75 by 89 km orbit (the target being in an 80 by 90 km one as you recall). Because I am doing this burn next to my target's periapsis, this means I am not just matching SMA more closely, but my eccentricity will also align with the target's eccentricity (the so-called argument of periapsis will match). (4a) After this burn completes, I will once again make a maneuver node, have it cross the target orbit, and see if I get a close encounter near the intersect. As my orbit still differs slightly, I will still phase forward ever so slowly with each revolution around the planet, but the steps will be really small now. I will find the point in the future where the close approach jumps from behind the intersect to in front, and then I will click and drag the maneuver node around the orbit and observe how the close approach changes. Typically I can find a close approach of under 300 meters like this. I may also occasionally find that my intersect disappears completely while I do this, because dragging the node to a different part of the orbit means it no longer has enough dV to cross orbits with the target from that position. In which case I add more dV and then repeat the process. This is also the part where inclination mismatch really interferes, so hopefully I did my step 2 properly. (4b) Once I have my close approach of under a few hundred meters, it's just a matter of time to wait for the node to come up and execute the burn. I will typically turn my engine power down really low for this (by rightclicking on the part), and carefully use the throttle so that the burn takes three to five seconds despite expending only 1-2 m/s worth of dV. This greatly helps with precision. I will look at the rendezvous data display in the lower left to see my close approach change in real time as I burn. Often I can get even closer than the maneuver node suggested. I've managed to get an impact trajectory more than once! (5) And then I just wait for half an orbit until I come up right next to the target, and light my engines one last time to match it and remain stationary.

The Discord is fine. You just have to focus on the channels that interest you, and rightclick->mute the rest. Particularly everything under "The Lounge" 95% of what I've seen in the #ksp2-general channel for example is rehashes from the main couple discussion threads here, talking about multiplayer, the pricing of early access, the rumored new planet, counting down the days, and so on and so forth. In other words, it's no different from here at all. If there is aimless chatter, then I feel like it's due to the game not being out yet. What else are people going to do but chatter aimlessly? Once EA drops, it's going to get a lot more focused.

Scientists do not influence the yield of ship-mounted experiments. The main reason to bring a scientist along is that they can reset goo and materials experiments, so you don't need to carry more than one of them even if you plan on visiting half a dozen biomes. Scientists do modify the yield of Breaking Ground DLC surface experiments they deploy.

Your idea was entirely valid! Unfortunately, in contrast to equatorial ones, inclined orbits are sensitive to the exact time of launch. This is because Kerbin itself rotates around its polar axis. Yes, the same axis around which the LAN is defined. Think about trying to launch directly into a low Kerbin orbit matching Minmus' inclination so you have an easier time successfully getting a Minmus transfer. This is an excellent plan, but it only works twice per Kerbin day - once every three ingame hours. Because only then, the launch site is in a location that actually allows you to match the target plane. The same is true for your polar orbit with a specific LAN.

The "longitude of the ascending node" specifies the rotation of an inclined orbit around the axis perpendicular to the reference plane (usually the equatorial plane, making it the axis going through the poles). It's a value in degrees offset from a reference direction. You're almost exactly 90 degrees off, meaning if Kerbin was viewed from the top, your polar orbit would cross the pole east to west instead of north to south. ...or, you know, something like that. I don't actually know off the top of my head where Kerbin's reference direction actually is. What's important is that you understand that your orbit must rotate 90 degrees around the axis going through the poles. To do this, you need to perform a plane change (normal or antinormal burn) above one of the poles. EDIT for a more general answer: In your case with a 89.4° inclination, you can just burn when your orbit crosses a pole and there will be minimal error. However, as the devitation from 90° inclination increases, this maneuver introduces more and more error in other values of your orbit. In such a situation you will have no other choice than to first plane change at AN/DN into a full polar orbit of around 90° inclination, then turn the orbit around the pole, and then plane change back into your desired inclination. Alternatively you can also flatten your orbit into a perfectly equatorial one of around 0° inclination, and then plane change at the correct moment in time to "create" your ascending node at the correct longitude and enter a correctly rotated target orbit. And what if you currently happen to be in an orbit of around 45° inclination? Well, I'm sorry, but then you're royally screwed and need to pay dV out the nose no matter which strategy you pick. LAN errors are among the most costly errors to fix in mid-inclination orbits, so if you're going into one of those, be very sure you get it right the first time!

To address the actual topic: if we get something akin to KSP1's EVA Construction Mode in KSP2, I would expect it to appear in phase 3 of early access, which deals with, quote, "orbital vehicle construction". (Source) Of course, it really depends on how that construction is implemented in practice. If it doesn't appear during early access at all, then maybe it'll appear in a future update or DLC.

I think everyone is kinda missing the point here. The question was not about how to get into the right plane. It was about how to remove having to manually time your launch using map mode every single time.

Admittedly most of the bomb wasn't fuelled at the time. It's only the three solid motors that were in any state to go off. And their ignition system is actually pretty safe.

You can also toggle symmetry mode from SPH-style to VAB-style and back with some button. I forget which. You can look it up in the keybinds menu.

Orbiting is easy! Just miss the ground while you fall back from space (And no, I'm not joking, that's literally what an orbit is. Gravity will always pull you back down, but if you go sideways fast enough, you can avoid hitting the planet and keep curving around it.)

Any tool capable of repeating timers should be able to do it. Since a launch window under an AN/DN comes up every three hours, all you'd have to do would be timing it once via eyeballing the map, and then set a repeating timer that ticks down three hours and then starts over. You could do a similar timer for an AN/DN intercept from an equatorial orbit. That said - I don't know if MechJeb or KAC or the stock implementation is capable of manually creating repeating timers. It's just not something that has ever come up for me.

I haven't played KSP since 1.12.2 dropped, one and a half years ago. Given that I've got some four-digit number of hours played privately ever since I started in alpha 0.21, and additionally did volunteer prerelease testing for Private Division on both DLCs and most major updates before they went live, I think that I've earned the break And I do plan on waiting for KSP 2 to drop. Even though the anticipation has lately been making me want to put together some rockets again. I know that, if I "get my fix" now, then February won't be quite as sweet.

I love the last image At least she has the decency to be flustered...