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.

An important consideration when scaling up the solar system will be SSTOs. Both rocket and airbreathing spaceplane SSTOs will be affected. Rocket SSTOs might become entirely infeasible, which would be consistent with the situation on earth and make it more important for the game to facilitate returning first stages to a landing pad. Airbreathing spaceplane SSTOs in the 1/10th scale system achieve a high fraction of their orbital speed in atmosphere on efficient airbreathing engines (around 1500 m/s compared to the ~2200 m/s orbital velocity in LKO), which explains why they achieve such good payload fractions. This will change in a larger scale solar system because a spaceplane SSTO will need to do much more of the work on rocket power. If the solar system were scaled up, I think I'd prefer to see chemical rocket SSTOs consigned to KSP history while preserving airbreathing spaceplane SSTOs as feasible.

This could be better worded as: To reflect the writer's hope rather than declaring we will be excited about a patch when we know nothing about what it will contain.

These statements show pretty well two different views and they're not mutually exclusive, I have both of these. I know to expect an early access game to be unfinished and now that I'm here, I'm sticking with it. But as I've said in a past post, on the Steam store page the developer is required to answer the question: What is the current state of the Early Access version? Keeping in mind the state of the game at launch: a notable omission was the severity of bugs, performance and stability issues that made it difficult or impossible to get to the features that were mentioned. And on top of this, early communications followed the same pattern. That is where the feeling of false advertising comes from.

The terrain system does not of itself allow for caves because it's a heightmap but it may not be impossible to have some caves. When terrain features like sharp cliff edges or overhangs are needed, these are usually separate objects put on top of the heightmap terrain. A cave would have to be a separate object that sits on top of the heightmap terrain. Ordinarily the limitation is that the cave can't go "under" the heightmap terrain, but exceptions could be made. As an example, World of Warcraft uses heightmap based terrain but it also has caves that are separate objects and conceal a hole in the heightmap terrain, allowing the cave system to actually go under the heightmap. See spoiler for an example, it shows how the cave entrances are separate objects from the heightmap terrain and allow you to pass under them into the cave system.

It's likely not feasible to put a lot of devs on particular bugfixing/stability issues like orbital decay and wobbly rockets because their strength lies elsewhere, because it would take time to get them familiar with the landscape of engine bugs and/or because putting more people on one issue would cause interference. Better to have them working on things that are their strength or in areas with a lot of room for gains to be made. Furthermore, since the goal of this early access is to gather feedback, I'd rather we have an initial implementation of science to comment on a little sooner rather than after every single game impeding bug is fixed (which may be never).

These re-entry effects look nice! And thanks for the WIP shots, I'm especially glad to see some taller mountains! I look forward to seeing these your upcoming work in-game!

I voted no on all three but I will say that in science and exploration modes, I would support the idea of starting out with limited knowledge about the Kerbol system, meaning the map view and tracking station show only vague details on bodies outside the Kerbin system until the player sends a vessel or researches the body with a space telescope. In addition, some planets and moons like Eeloo, Pol and Bop could start out with having their orbits unknown, creating a reason for players to use a telescope to discover their orbits. This would then serve as an introduction to discovering planets around other stars, where even their existence is unknown until the player sends a mission to discover them. With the many exoplanets that have been discovered in RL thus far, it may seem like the Kerbals knowing about all the planets in other star systems should be something of a given. But even the most reliable and common method (transits) leaves uncertainty, only works for the few percent of systems where the planetary disk aligns almost perfectly with the host star and the earth and tells us almost nothing about what the planet actually looks like. So I definitely see a place for game mechanics to enable the discovery of unknown planets. Some details being unknown about some of the bodies in the Kerbin system could serve as a good introduction step to the more difficult task of discovering entirely unknown planets in other systems.

Alright, here's some big dreams of mine, which I realize are probably beyond even an extended scope the devs may have of KSP2 past its 1.0 release: Deeper colony management and expansion with a central role for all kinds of vehicles, differing by the environment they have to operate in. Landscaping: The ability to change the terrain and leave your mark on it, from new craters when something big impacts the ground at high speed all the way to shaping the terrain around your colonies to your liking. Flattening, raising and lowering the terrain to make space for colony expansion, roads, or just to make the terrain look a bit nicer. Space habitats: Not the tiny rotating hab rings that exist in KSP mods or even the presumably larger ones that have been teased in KSP2's interstellar content. I'm referring to habitats on the scale of the Stanford Torus and O'Neill cylinder, or even larger, with entire ecosystems inside. Terraforming: Modifying the atmosphere, temperature and ecology of a planet or moon. To make a planet habitable, maybe you need to transport vast amounts of resources from another planet or moon, enough that both will be very different after you're done. With timewarp available to us, KSP2 could be suited to show the vast scale in both time and resources of such a project. Dyson swarm: Terraforming will take huge amounts of energy and what better way to provide it than a dyson swarm?

If people cannot expect an early access product to be enjoyable, it follows that potential buyers should buy the product to support its development into its promised state. Otherwise, why is the product even in early access? But when we talk about consumer expectations of early access, we must also consider the expectations set by publishers and distribution platforms of potential buyers, as exemplified by the warning you get on Steam for any early access product: In essence it tells potential buyers: "Buy only if you would be happy with what you got with no further changes." And indeed, arguments to that effect have been made on these forums many a time in discussions about the state of the game and early access. From this, it follows that potential buyers should wait until such time as the product is enjoyable and not to expect it will be developed any further. So... Are we buying early access games for what they are supposed to become, or what they are right now with a potential bonus in further development? Certainly, the latter is the safer guideline for a potential buyer. But if everyone strictly followed it, there would have been a lot fewer sales at launch.

I haven't lost all hope, but this is what I'm concerned by too. I just today decided to fire up KSP2 again to have a go at making a VTOL aircraft. Slapped some fuselages, engines and wings together and so far so good... Until it came time to configure the engines into action groups. The UI for doing it is finicky and often doesn't respond to my clicks the first time, having to click ui elements or dropdown boxes multiple times to get it to respond. These are the kind of pain points that can be worked around by players who get used to it, but they sap energy out of a play session. When it later turned out my VTOL jets which I had set to independent throttle couldn't be turned off with my action groups nor through the part manager (and this being far from the first time I've had difficulty controlling engines with the part manager), I threw up my hands, gave up and put the game down again in hope for improvements.