Lyneira

I'm glad to see these strides being made and look forward to trying out For Science! in december!

Perhaps also because he was a developer who passed away and subsequently added as one of the "main character" kerbals to honor him. Because it's so obvious now, seeing him as part of the main character list feels a bit like opening your newspaper and seeing an obituary of one of the newspaper's valued colleagues posted on page 1. Every day. There is no community lore or game lore behind him other than this. Compare with the previous addition to the "main character" cast in KSP1 which was Valentina, celebrating the addition of female kerbal models. A monument somewhere on Kerbin, perhaps even in a corner at the KSC, and his inclusion in the randomly generated "developer kerbal" list would have been enough for me.

An overview of a vessel's potential EC production and consumption might fit well in the Engineering Report app in the VAB.

To clarify, the suggestion is not to render distant terrain itself (pqs) as a 2d sprite, but rather the objects (rocks, trees, grasses etc) scattered procedurally on top of it, to break the "circle of terrain scatter" effect that is currently very clear to see when flying close to the ground or driving.

A somewhat tangential question, but I've seen mention of software engineer positions at IG with different roman numerals in them such as: Software Engineer II, Visual Effects Software Engineer III, Multiplayer Software Engineer III, Audio I imagine there's also a Software Engineer I. What's the significance of the roman numerals?

The underlying question I gather from the OP is: "What is holding back KSP2's progress?" From the type of issues that are sitting at the top of KERB now and the issues I've experienced personally over the past months, it's clear there is a bottleneck in the engineering side of the project right now, not so much the content creation. (planets, environments, music, sounds, parts etc.) Can the bottleneck be removed by adding more engineers? There's a common adage that very likely applies here: "Adding more workers to a late project makes it later", so hiring new engineers right now won't give any short term benefits. But there may be plenty of engineering work left for the roadmap that it will be worthwhile for the future. Could the bottleneck have been prevented? Perhaps with different processes or a larger engineering staff in the years before launch. The confidence about "slaying the kraken" from communications prior to launch compared to what we experienced after launch suggests the engineering task turned out to be more difficult than expected.

Thanks for the overview and figuring this out! For the most part in KSP1 I didn't really bother with getting attached to kerbals in my saves, primarily because it wasn't possible to customize them. Getting the ability to name my kerbals and customize their looks in-game would help with the immersion aspect of a campaign and be of benefit to content creators as well.

I would have preferred if Tim C would follow the standard naming convention as just "Tim Kerman".

Alt-X does reset your trim. It also instantly sets your throttle to 0 because "x" without modifiers is the key for that.

After hearing a friend's frustration with Starfield's buggy cargo link system (they couldn't get their bases to ship cargo between them anymore), I definitely hope the KSP2 devs take this advice to heart.

Some CPUs with integrated graphics can approach the performance of older budget discrete GPUs, making them acceptable for lightweight games or well optimized, fancier games at lower settings. That said, while KSP2 has made good strides in performance compared to launch, I wouldn't bet a purchase on it qualifying for the above.

I'm definitely in favor of having a way to fine tune a maneuver without having the node's location in sight. For example, precisely planning an interplanetary encounter from an ejection burn in LKO, fine tuning a gravity assist or mid-course interplanetary correction burn is quite a hassle.

In KSP2, time doesn't pause while you're in the VAB. I'd also be curious if in an OAB which is open to space, we'll get to see Kerbin or another planet passing by below us as we orbit it. I hope so, at least.

I'd like to add a closely related suggestion from an older thread to improve quality of life when editing procedural wings: A way to resize the wing (or multiple attached/smoothed wing segments as suggested in this thread) in 2 dimensions while keeping the same aspect ratio and shape. Right now, when you're happy with a wing shape but you realize that you need more (or less) wing area, you have to do the following steps: change wing span change root length change tip length adjust wing angle to approximate what you had Reposition everything that was already attached to the wing It would make plane building so much smoother if this process could be condensed down to just a gizmo or slider to scale the wing. It doesn't need to scale it up in 3 dimensions, just dynamically calculate span, root, tip and angle to maintain the same shape. If any one of them would exceed a limit for the wing part, don't let the wing scale to that size.

I understand why you disagree with this but there is a use case where text input could be useful: Attaching multiple objects to a fuselage when not in symmetry mode but you want them offset by the exact same amount. I don't know if text based input is the only way to achieve this or if some other UI element could do the job, though.