Kerbart

Imagine Lex Fridman doing an interview with Nate! This is pretty much how it would look like, kinda.

Some of the concerns are legit, but the plea gets watered down by listing known bugs. For instance, Kerbals disappearing after a mission will be addressed in upcoming patch 2. Some of the decisions are clearly in the "I don't like it, so it's bad" category. You're in mission control, you're staring at a mission control monitor. A 1978 Space Invaders font and primitive icons emphasizes that feeling, a retina Calibri font does not. That's a styling choice. Perhaps we get skins in the future where you can specify that, but I doubt it's "generally" considered a bad font choice. There are also a slew of things that are attempts to improve the interface, or at the very least take a fresh look at things, The burn indicator is one of those things, very deliberately moved away from the navball (remember there are plenty comments "the navball is too busy"). Yes, there's information missing, and that's valuable feedback. Be very careful stating "KSP2 is bad because it's not KSP1," which is, maybe unintentional, the tone of your post. Yes, that's the point. At least you're not making the mistake of saying that features are "not intuitive" — usually only for KSP1 players who have hundreds, if not thousands of hours under their belt. In the same sense. a tutorial that spends more time on "basics" is not "dumbed down," it's doing something that wasn't there in KSP1; showing a bit more of the why instead of just how. That isn't to say that the game is perfect. It's Early Access, and to be honest, in a disappointing state. But things are not different because the dev team isn't aware of KSP1, I'd say it's the opposite. They are very aware of it, and trying out new things to improve the game, especially for those who never played it before. There's two approaches to this subject. One is what you chose to, a emotional plea with many stylistic constructs that "scores points" with the audience that doesn't like KSP2. Like listing things that are known bugs, or known to be slated for improvement. And that's choice everyone is free to make. Another approach is a constructive approach, listing what was changed, how it worked originally, why the change doesn't work and how to improve it. And skip the known bugs, especially when you know they're being addressed in the upcoming patch. What's the point of saying "hey devs, X doesn't work" when they clearly know X doesn't work?

I was more thinking along the lines of Intel HD 500?

Are we playing the same game? Because I do have agency over what parts I pick for my rocket. Practically any video I've seen about "noodle rockets" involves incredibly bad design by stacking larger parts on top of smaller parts and expecting it to be stable. Then there's the unrealistic expectation that a single strut should stabilize that monument of bad engineering ("I have strutted the ### out of it," without exception, shows me a picture where three or four struts are applied). You think structural flexing isn't a problem of real life rocketry? You think that in real life engineers are not frustrated that they can't launch whatever they want? Are you aware that the ISS was launched in many parts, not as a single structure, because that would certainly have noodled during launch? There's more to getting into space than just the rocket equation. Read up on Hooke's law. You're barking up the wrong tree here. If physics where as realistic as you want them to be, your rockets made of single procedural parts would still flex and break in flight. Just not at the joints.

On top of it, the most laughable argument against wobble is "not realistic" because it tends to be a really bad problem with unrealistic rockets and far less with well engineered ones. "In reality my rocket wouldn't wobble like that" "In reality that pile of metal you dare to call a rocket wouldn't make it off the launch pad"

Ah, I see. I would still be optimistic about the interestingness of the presentation though. My experience with non-(game-) dev conventions is that if you're a corporate sponsor at a certain level you do get slots. And it would be a waste not to fill them. Not sure if it was IG, PD or T2 who was the sponsor but given that KSP2 runs on Unity, one way or another they'd seem like a good candidate to fill that slot, one assumes (I doubt the sponsorship money came from the IG budget). And yes while corporate and marketing will quickly label anything "interesting" (I once signed up for an "interesting" podcast that suggested data science and the next three episodes were interviews from HR with VP's celebrating their 25th anniversary with the company, but I digress), the developer who's actually doing the presentation doesn't want to look like a total tool, so it probably will be interesting. Even if it's just regular PQS he might give insights and what was tried and why it didn't work; no doubt others can learn from that as well (no experiment is ever a complete failure; at the very least it can serve as an example to everyone else).

Well, yes, this is how these conferences work. Months in advance tickets go on sale, with a detailed agenda, as no one wants to spend $1500 on a conference without knowing what the presented topics are. So months before that speakers are requested to submit their topics and the most interesting ones are picked. At least six months ago, if not longer. It's not inconceivable that IG was working on a better system and initial tests looked promising. Then some showstoppers were discovered during testing. Do you go ahead and hope you can fix the issues on time? The agonizing decision was made to revert to PQS because, well, Feb 24 was on the horizon. This is all speculation and conjecture of course. But it's also a good illustration of what have they been doing in the past three years. Working on improvements, that not always work out. And reverting back to the original system isn't just a matter of swapping out two libraries, as there probably is a ton of code depending on it as well. If improving code was only as simple as adding the line make_code_go_fast = true;

Part of me says yes. But from a realistic perspective, and if we want to see continued development, DLC is unavoidable and Robotics is just too much of a golden DLC oppty to release in the base game. Given the hundreds, if notthousands of hours of playtime we get out of the game I’ll be happy to see it as DLC, rather than not getting it at all.

The cinematic trailer takes a lot of “artistic license,” and I would be reluctant to draw any conclusions from it. It would be nice if theyhave chutes though.

It used to be that in the Old Days, before KSP 1.0 even was released, Webec would indeed show blacked out sections where, if you were doing window sharing, a dialog box (even non modal ones) or anything else covering would result in a blacked out box. Nowadays anything running in the window you share regardless of it being in the background or not, will be rendered perfectly. I'll try it with OBS but my expectation it is. Which is also not perfect in Teams, as I'm often troubleshooting and my colleague shared a window, not their desktop, and now I am completely oblivious that they pulled up something else, and they are oblivious I'm not seeing it.

If you get a popup notification, it will show up when recording the desktop but not when recording the window. I know how it works in other software but not games, and the answer is yes — at least in Teams it works this way, and given that this usually all evolves around the same system calls, I have little doubt it would work any other way.

KSP’s history, including the micro-history of version 2, is full of “should have but doesn’t” subjects. That alone is not a viable source for “it will be there.” However, someone will mod it, and it will be DLC either to beat the modders to it (unlikely) or to cash in on the proven demand for it.

When they copied over the codebase there was no DLC and the used the feature set available at that point. Not the strongest argument given that they revamped the game a couple of times since (those years were spent on something after all), but that’s the narrative why it’s not there. I can see adding it as DLC eventually. Where he are going to slot in 1.875m parts between SM and MD is a bigger question. And given how much fun Robotics and Propellors are, it’s a shame if they don’t get added back.

By the time it’s implemented as intended people will be used to “one vessel per workspace” and oblivious to how it’s supposed to work. I’m usually not on the “after three years this is what they rooled out” fence, but this is one of those cases. It seems they did the hard part but never finished it. With the way it currently works my “load vessel” dialog is littered with autosave workspaces that do very little.

Once the patches have lifted the game out of the "broken/unplayable" bin (not my words but many consider it that way) the frequency will drop considerable, probably to 6-8 weeks if not longer. I'm also assuming that right now the team is working full throttle, you can only do that for a limited time before everyone burns out. I'd say half a dozen updates for the remainder of the year with Science rolled out in the second half of the year and a continued focus on bugs and QOL improvements before the next EA milestone is published. Science will be Make Or Break for many, as it will give an indication what the previous three years was spent on. If it's merely a polished version of KSP1 science there's going to be a lot of (justified) disgruntlement. With the pressure slightly off, they probably want to make sure it's released in a much better state than what the game currently is in. I don't like it but you do have a point.