whatsEJstandfor

I believe the maneuver planner takes a vehicle's TWR into account as it does its burn, doesn't it? If this is the case, then how would the maneuver plan treat a vessel that runs out of fuel? It can't just keep increasing the predicted TWR throughout the burn, because it could potentially just increase unbounded and lead to physically impossible burns, which'd be of no use to the player. Should it just assume the vessel's TWR remains constant after it runs out of fuel? I suspect that it's this nonlinearity in the TWR's change that makes the current system not able to handle out-of-fuel trajectory calculations. In other words, I'd bet that the current trajectory calculations require that d/dt of the TWR remains constant throughout the burn. If this is indeed what makes it currently impossible to calculate burns beyond out-of-fuel-events, then maybe, while editing a plan, you should be able to toggle between KSP2's non-instantaneous maneuver plans and KSP1's instantaneous maneuver nodes. The instantaneous one would be less accurate, but would sidestep the issue of taking a changing TWR into account.

I believe this is a known bug. The way I've gotten around it is, supposing I want 6 boosters around the outside (3 sets of two), I put on 2x symmetry instead of 6x, and then place those 3 sets of two manually. That way, you can separate each pair of decouplers from the others. I hope this is fixed at some point, though, since it's impossible to line stuff up perfectly.

This is pretty much what I do, except I do adjust the throttle so that my apoapsis stays around 50 seconds ahead of me at all times. I guess it might not be the most efficient but it seems to work pretty flawlessly for me.

Not to hijack the thread but I haven't been able to get asparagus staging to work in general (at least not in the way I did it in KSP1) because if I put, say, 6 decouplers in symmetry around my center stage, I can't move individual decouplers to their own stages; it seems like I can only move the decouplers to other stages all as one unit. In your example, how'd you get those decouplers in their own stages? Did you just do 2x symmetry and place multiple sets of them? EDIT: I must not have looked very closely at the image; I see now that yours isn't symmetrical, so I'm guessing you didn't use radial symmetry, so you bypassed the problem I have.

Just wanted to say that, since For Science!, I've been having so much g*sh d*ng fun. Last night, I stayed up till 5 AM trying to rescue Bob from the Duna monument. The mission was a success, and good times were had by all (except for Bob). There are still some extremely frustrating bugs, but, for the first time since launch, absolutely none of them have made me stop playing. For the first time since launch, I'm stopping each play session because I'm an adult and unfortunately have other responsibilities. anyway good job ig ilu

MORE LIKE FIVE SCIENCE

Here's the link for those of us who hate looking for things:

My wife minored in German and, when she was teaching me German vowels, she described pronouncing ü as making a long-E sound with your tongue, but then shaping your lips to be a long-U. Incidentally, ü is often transliterated as "ue".

You know I love a technical deep dive and this is no exception. Thank you for this!

Is this the most "Fix implemented and verified"s we've seen in a KERB? Stokeddddd

LET. US. GOOOOOOOOOOOOOOOOOOOOOOO

oh yeah big time

I think this is planned for multiplayer

I really really really liked that he gave a very specific example (mirroring procedural wings) and walked through why it can go from being a simple one-liner bug, to a multitude of new bugs, back to just appearing as one line in the patch notes. From the sounds of it, time estimates from now on (or I guess as of several months ago) are going to be more accurate, because the people making those estimates will be familiar enough with the systems involved that they'll be able to foresee cases like the above one in advance.

No need to be a jerk. I was saying that, since it mostly already works, it shouldn't be too difficult to add 5120x1440 as an option and then add 32:9 versions of the loading screen images.

The nice thing is that it already (mostly) works out of the box by editing settings.json. Legit the only issue I've noticed is that the loading screen images are stretched out, but I can't think of anything else that's been broken at that resolution.

It'd make for a very interesting case study in (mis)management. Duke Nukem Forever and Daikatana come to mind as games that absolutely nobody cares about, and are only famous BECAUSE of the interesting behind-the-scenes intrigue and drama. On the other hand, there are also games that are beloved, but still had notoriously rocky developments (Halo 2 as an example), and I think knowing those stories makes me appreciate those games even more. I'd like to think that KSP2 will ultimately end up in the latter category. For me, the short answer is, "I'm extraordinarily curious". I mean, why do people watch behind-the-scenes stuff on Blu-Rays, or listen to crew commentary? It's just genuinely thrilling to see how the sausage is made sometimes.

I love the aesthetic; the music, the retro and compact UI, and ATMOSPHERIC SCATTERINGGGG

Oh mannnnnnnn, just based on these patch notes, this might be the most impactful patch since 0.1.1.0 or 0.1.2.0. I'm extremely excited to try it out! AND ATMOSPHERIC SCATTERING, I'M GONNA CRY

Here's a livestream link for Nate's presentation: Since it's still going, I can't link to the timestamp, but, at the time of this post, it's about one hour and 20 minutes behind realtime. Anyway, I was smiling throughout pretty much the whole thing. December is honestly sooner than I thought, and 0.1.5.0 coming out THIS WEEK was a huge and welcome surprise! The hype train is about to hit 88 miles per hour

How much would I have to Venmo you for you to, say, DM me those dates What do you mean, "there's only a little time left"? Does KSP2 turn into a pumpkin at midnight

Best you can do is contact Steam's support and ask them nicely

I'm loving the dev chat format! More of this! And I love hearing engineers talk about the nuts and bolts of the issue! That being said, I'm not sure what we learned that we didn't already know. We already knew it was a complex issue and that different solutions have pros and cons. Couldn't that be said about literally every choice made during development? Nate's follow-up post is encouraging but, yet again, it's a case of telling us rather than showing us. It's good to know, though, that many solutions are presumably being explored deeply, and I'm excited to see what the ultimate one chosen is!

What's that I hear? Could it be? Someone shoveling some coal? CHOO CHOO

yes yes yes yes yes