Spazmataz

I wonder if they released the correct build. There's still a lot of bugs. After updating, I did a quick Mun mission. Nothing fancy. (a) Attitude control failed in Kerbin orbit. Craft would change attitude just fine if I clicked on the attitude icons (prograde, retrograde, etc.) but manual controls using the keyboard (W, A, S, D) were completely unresponsive. Saved, quit to the main menu, and reloaded: didn't help. Completely quit the game (back to windows), restarted and reloaded, and that fixed it. Finally. (b) Made it to the Mun, then back to Kerbin. Parachute deployed as expected, and eventually fully inflated as expected, but once fully inflated, it failed to slow down the ship. Ship careened into Kerbin about at 70 m/s. Jeb, Bill and Bob are all dead again.

For what it's worth, every time I recover a vessel (even ones that completely unscathed) it kills all the kerbals aboard. Or if it doesn't kill them, maybe they resign in protest, never to fly again. I don't know. It just seems that for whatever reason for me, kerbals only fly once in KSP2. (I'm sure it's just a bug that will be fixed soon). If the kerbal in question hasn't been "recovered" (i.e., killed) yet, and you're building multiple vessels in the VAB, check all the vessels you're working on in the VAB. The kerbal might be hiding in a command pod. --- I don't know much about how they are stored in the JSON save files, but here's something I've noticed. In terms of the save file specifics, I've noticed that if the kerbal in question is a main kerbal (e.g., "BILL_KERMAN", "BOB_KERMAN", "VALENTINA_KERMAN", "JEBEDIAH_KERMAN", or "TIM_C_KERMAN"), and alive, they'll be in both KerbalData {Kerbals {} } and KerbalData {CustomKerbals {} }. But if they are recoverd (killed), they are removed from both of those and placed in KerbalData {CustomKerbalRefresh {} } I'm guessing -- although I don't know for sure -- that if the kerbal in question is not one of the main kerbals, and is just a random kerbal, and is recovered (killed) , then that kerbal is simply removed from the save file altogether. Have you tried searching the save file for the kerbal's name? (Nevermind. I see you solved it.)

I agree. Another reason to allow control of debris is merely to allow the player to see what they're going to destroy before they destroy it. Putting it another way, as it stands now you can see in map view that you have a lot of debris, but you have no way of knowing what that debris actually is. The auto-name convention doesn't help at all, and there's presently no way to figure out what any particular piece of debris actually is. Allowing the player to "control" debris would solve this.

Yes, I look forward to that too. And along with that (of course), some sort of method to toggle the display of different types of vessels in the map view (to reduce visual clutter when you have a lot of vessels). But right now, the way KSP2 is in its present state, I can't even reliably change the name of a vessel, much less its type. (It appears that you can change the name of a vessel in the tracking station, but the implementation is bugged and broken). So that would need to be fixed first, of course.

Made it to Dres (no cheats -- did it the old fashioned way). Dres has rings! Figure 1. Bob Kerman (left) and Valentina Kerbin (right) gathered on Dres' surface at the totem, secretly conspiring to ritualistically sacrifice Bill Kerman (center) according to custom. Note Dres' ring system visible from the surface, arching across the sky. Figure 2. Flyby of Dres' rings, before heading back to Kerbin. Okay, Bill gets to live another day. Figure 3. Another shot of Dres' ring system during flyby.

Yes, it happened to me too, both on Mun and Minmus. In the case of Minmus, in what started as a low, circular orbit, the periapsis would mysteriously decay into the surface, -- but here's the weird thing -- the apoapsis would mysteriously rise too. This is not consistent with atmospheric drag. The rocket had no RCS available, and I made sure that the engines were not firing at all, even a little. So I have no explanation for the orbit decay, besides just being a bug, I guess.

I hate the look of the navball (I don't mean the whole cluster, just the navball itself). I said the same thing to myself regarding the navball when first seeing KSP2, "Dithering?! really?! Is this some sort of joke??" Developers: You have access to real, 3D shaders. Please use them for the navball. I look at the navball all the time. Not only is "simulating" 3D with dithering pointless when you have actual 3D shaders at your fingertips, it hurts my eyes. Please bring back a true 3D navball.

Ah, I understand. Right. This mod is completely different than that. With this mod you are trading off time in favor of increased efficiency. 'Quite the opposite from Brachistochrone then. Precise Node is mod that lets you fine tune individual nodes. In contrast, this mod (Maneuver Node Splitter) is used to automatically break up a given node into multiple nodes (one node per orbit) specifically for interplanetary* transfer ejection burns. *(or moon, if you're leaving a moon) If your vessel has very low TWR, you might not be able to perform the ejection in a single burn, without first raising your initial, circular orbit. However, this raising to a higher circular orbit wastes fuel, since the new periapsis is higher (less Oberth effect gains). This mod aids with breaking up that burn into multiple burns (one burn per orbit) allowing you to keep your low periapsis, and thus keep your Oberth effect gain goodness. [Edit: even with this mod you might have to do some fine tuning with node positions from one orbit to the next; it doesn't eliminate the hassle all-together, but it sounds like it might reduce the hassle.]

Well, yes, you could do a constant thrust trajectory (I think that's what you mean by Brachistochrone) for the whole Kerbin escape, even with high TWR crafts, merely by reducing the throttle. But that's not the most efficient way to go about it, all else being equal (apples to apples). But even if you don't have the option to raise the throttle, and are limited to extremely low TWR, it's still more efficient (although perhaps more tedious) to break up the orbit raising burn into many separate burns such that each burn is quite close to periapsis. The idea behind this is that periapsis remains low; only the apoapsis rises. Limiting the burns to short burns near a low periapsis maximizes the Oberth effect. And it can save a lot of fuel. On a planet like Kerbin, escaping via this all-burns-at-low-periapsis approach might save around 1/3 (maybe even closer to 1/2) the fuel that it would take if you slowly and gradually spiral out of Kerbin's orbit (by "gradually spiraling out of orbit," I mean a constant thrust [i.e., gradual spiral or by moving to higher circular orbits] trajectory). You can also use this efficient, all-burns-near-periapsis approach for capture on a body like Tylo -- one in which you can't rely on atmospheric braking. [Edit: although I don't know if this mod works on captures. It's just the strategy I'm referring to here.] Of course, this only works though when the orbit is still elliptical. As soon as the orbit goes parabolic, there is little/no reason to reduce the burn times. [Edit: Thus it's better to continue to burn on that last periapsis burn (when the hyperbolic orbit is established), for however long it takes -- but do it sooner rather than later. Ideally, you'll keep burning until you get your encounter at your target body, burning as close as possible to the planet/moon which you happen to be escaping (e.g., try to keep that last, final burn as close to Kerbin as possible, if you are escaping Kerbin). Waiting until you escape the escaping body before setting up a maneuver node to get the encounter of your target body is shooting yourself in the foot, efficiency wise.]

Have you considered using a joystick or at least a controller? That way you can use the full range of gimbal if you prefer. Keyboard keys are inherently discrete input sources. Even if Squad was to reduce the stock rate of change of gimbal motion, the [gimbal] accleration rate would still be all-or-nothing based on a keypress -- and it would make the gimbal response more sluggish. I'd rather have responsive gimbals than sluggish ones. I have a joystick if I need it, but I rarely ever use it. Instead I do the "modulation" approach by repeatedly tapping on keys to get the gradual, desired effect. I acknowledge though that it would be a lot more smooth if I bothered to pick up the joystick. If you feel that accurate and smooth gimbal motion is important to your style of play, I recommend a joystick or controller for those times you will need it. Here is a link on how to configure the joystick for use in KSP: http://forum.kerbalspaceprogram.com/index.php?/topic/79780-how-to-set-up-a-joystick/

Yes, I believe the mod is to aid in multiple orbit raising maneuvers (between launch and "departure") such as used on the MOM (image not to scale): https://en.wikipedia.org/wiki/Mars_Orbiter_Mission#Orbit_raising_manoeuvres Edit: The idea of splitting up such maneuvers, as hieywiey points out, is to fully exploit the Oberth effect. This is of particular usefulness if the thrust to mass ratio is low.

You might be able to miraculously find/reviver her! (If it helps mentally, think of this process as a something like the upcoming movie The Martian.) Browse your KSP local files, in the folder "saves" and then navigate to the subfolder specific to the instance of the game your are playing (same name that you click on when the game starts and you click on a particular saved game). In that folder you should see a file called "persistent.sfs." Open that folder with notepad. Find the section called "ROSTER" There you should see all your kerbals. You might notice that in Valentina's entry, there is a line that says something like, "state = Dead" or "Missing" or some such. Change that line to "state = Available" such as is the case with your other available kerbals.

Is it just me or does Jeb appear to be fixin' to make a Fallout bottlecap mine. <just some="" humor=""></just>(just some humor.)

I don't mind the idea of upgradable buildings. It seems like a logical step toward the original design goals of the game. Don't get me wrong though, none of this "tycoon" style gameplay stuff relates to why I fell in love with the game. Of course it's the intuitive orbital mechanics and the semi-realistic physics that hooked me and keep me playing (and playing and playing and playing at the expense of other aspects of life). The rest is less important to me. But let's not forget that the game is about creating and managing your own space program. And although that includes neat physics it's more encompassing that just that. I mean, space program is even part of the game's name after all. So upgradable buildings along with some of the recent economical additions seems like a logical step toward the original design goals. The game's developers have been up front about having things like this from the get-go. As long as nothing distracts too much from the neat physics and science, then I'm all for it.

I'm pretty sure the OP's comment, "what this means for some of you is that you can lay off the F5 for a bit" means you can lay off the quicksaves for a bit. "F5" if quicksave in KSP. (It has nothing to do with browsers. The reference is to the KSP program. I'm pretty sure the OP is saying that since so many bugs have been fixed, there's not as much need to quicksave.)

they pretty definitively said those would NOT get recovered w/o a mod at the moment Pardon me for my ignorance, but when/where was this said?

How did you arrive at this 80% figure? For me, the numbers in the video were not clear enough to make out specifics.