Bej Kerman

They are addressable, even if it hurts your case because it exposes you to situations in the game where you need the navball on screen without it obstructing your view. Again you're back to blaming the player instead of simply addressing the player's situation. Here's an example, maybe the player is docking a lander inside a tight cargo bay and needs to see the clearance around the lander - and the navball being in the middle would prevent them from making sure they don't scrape the engine on the back of the cargo bay. Are you going to blame the player for daring to save construction resources on smaller cargo bays, or maybe, just maybe, having the navball on the bottom is detrimental. It doesn't matter if the ground is seemingly (keyword: seemingly) flat, it'd still be irritating to only be able to see a few feet below your lander like in the example from Lowne's gameplay. It is, though I wouldn't want the developers to change the current default in an attempt to reduce complaints.

Using prefab parts as a strike against robotics is like using prebuilt LEGO sets as a strike against having a giant tub of bricks to do with as you please. Fair enough, though the game's not going to be in this state forever.

Is this one of those roving goalposts? The pilots are going to be looking at their screen, not out the windows. The screen is effectively their FOV and it's off to the side.

I am pretty sure there's an advanced tweakable in the stock game that lets things deploy while stowed.

How are they clunky? I mean, how would they negatively affect gameplay for you? Just don't use them if you don't like them, for everyone else they're incredibly useful (plus real spacecraft rely a lot on robotics)

Nothing says "there was a tangible sense of momentum" like revamping (not even all-) the part textures, doing a bad job and falling behind ReStock, instead of prioritising bugs and gameplay features. And barely being able to pump out fireworks for the last major update ever.

They can't even trust real life rockets to agree 100% of the time

So... you don't care that the navball covers a horribly large portion of the screen? Completely irrelevant. They received backing from a large company and had every chance to move the navball to the left by default. It doesn't take an industry veteran to think "Wow, this UI element covers too much screen space. It's best off in a corner". No A flat style would've been better but that's all I'm giving. The overall layout is still lightyears ahead of KSP 1. You're blaming Matt Lowne for the default placement of the navball? Back to this. Aviation 101 is not gaming 101, and again, look at how little space the navball gave Lowne to view the ground under his vessel.

????? So we can talk about the KSP 2 UI not handling certain resolutions well (for the record: when it comes to the pixelated style scaling improperly, yeah, I agree that is a problem), but as soon as we discuss the KSP 1 UI becoming outright obstructive at certain common UI scales, especially those you can expect console players to play at, it's "[not] too fair"? Not to mention, claiming "if you make it the whole screen, I agree it's obstructive" which, purposefully or not, implies people who play at these UI scales would do so intentionally only to make their experience worse. I think it's completely fair to cite this example. People playing at lower resolutions or with their monitor across the room like in any living room setup is not unheard of, and if anything, it's frankly not fair to pull the rug from under my argument as soon as any criticism of UI scaling poorly blows KSP 1's way. I guess this is a convoluted way of saying: I don't think it's too fair to the discussion to excuse Squad with "the game was designed for and tested at a certain resolution", as if it isn't standard practice to ensure UIs scale well between 720p and 3840p and super incompetent on Squad's part to not do so! Matt Lowne would not configure his game purposefully to make his console experience even worse, full stop. Players playing with the UI this big is not something that never ever happens and is not something devs shouldn't try to account for when coming up with layouts for their UIs. I'll hold Squad fully accountable for placing the navball in the middle so that players have to zoom way out to see the ground below their landers.

Coming back here cause I wanted to add to Master39's point, that even if the navball was bloated, it's not an issue because it's in the corner of the screen. You also never addressed the screencap I sent of Lowne's gameplay (showing that bloat being a problem if there is any is 100% dependent on the navball being in the middle) and Master39's point that "most people talking about it being in the way are already thinking about the much smaller KSP1 version" so I'm interested in seeing your 2c there as well.

Good for you Unfortunately, not everyone plays with the same UI scale and monitors - this is what Matt Lowne's playthrough of KSP Enhanced Edition looked like. Look at how far he needed to zoom out in order to see the ground immediately beneath the lander.

What I want is to have the one instrument I need right at a glance, and yeah, that's a way to accomplish it right there, but I'd also like to not waste 2 thirds of my screen on nothing if I don't have a reason. Why not zoom in (or rotate said 2/3rds of the screen to a nearby object e.g. space station) then?

Supplemental There you go, I guess.

Even worse. The Earth fell out of orbit

Since this was the solution you proposed when the navball was blocking the rocket, can they not just pan the camera so the rocket is near the navball?

I think it's ironic they're complaining about how the navball being to the left by default is ableist. By the same token, as someone with dyspraxia, "just move the camera folks" is ridiculous and also dismissive of people who need minimising the inputs they need to focus on. I can dock and land OK - but not if the navball is being obstructive as it was in KSP 1 and I'm being told to just "move the camera". (Quoting cause I want your two cents on my minirant about how nonsense this is to hear, struggling with motor control)

I don't think in a very structured manner so I'll just ignore the "top" and "10" parts and just explain how I think aspects of this game can be improved. I'm also going to avoid things that are already confirmed or hidden in the game since it's a bit repetitive to request features the developers themselves want to add. Procedural wings should have a graphical editor since a list of sliders can be hard to parse and there should be more flexibility in their shapes - players should be able to effectively replicate the outward-sloping wings of the Concorde for example. Large lightweight landing gear like those on the Falcon 9 are also a must-have. The Wallaby gear can be too unwieldy in some cases. Control surfaces that flap inwards and outwards like those on the SpaceX Starship, allowing vessels to make extremely high AoA maneuvers during re-entry that aren't possible with standard control surfaces, are another must-have. You could do this in KSP 1 sort of, but DLC was needed and SAS could not interface with robotics, so having something in this as a full feature like the grid fins would be well appreciated. This one's more decorative, but since we're getting re-entry effects in FS!, the system used to generate those effects could probably also be used to create those puffs of air you see around vehicles going trans-sonic. Would also provide some lower-speed visual feedback for your velocity. If a lot of explosions happen at the same time, like when a large launcher crashes into the ground, instead of a bunch of explosions happening that disappear within seconds, the game should recognise that a lot of explosions are happening within a tiny volume and spawn larger, longer-lasting explosion effects for dramatic effect. The game doesn't give you much time to savour the destruction of an ill-fated vessel, immediately showing you your flight report and resetting the camera. The game should keep track of all the debris that came from the active vessel and follow the center of mass of said debris cloud rather than ditching the camera, and the flight report should wait A. a few seconds, or B. till the player hits Escape, before showing up so the player doesn't have to fight against the game to watch the fireworks. That way, you get a good view of the area your vessel is bringing down havoc, and you're not immediately being hit with snark from PAIGE while trying to recover from the emotional low of seeing your rocket crash. More interesting things near the edge of the Kerbol system. I know the devs have turned their nose up at the idea of altering the system before, but the system in KSP 1 clearly wasn't designed for the scale and progression of KSP 2 so I don't believe it's a good idea to copy it 1:~1, and there were several planet concepts that never made it in as KSP 1 didn't have much to justify gas planets beyond Jool. I say the devs should seriously consider adding distant Kuiper-belt objects beyond Jool that could be used for deep-space mining and colonisation, and maybe something analogous to the theoretical Planet 9, so as to help ease the transition into interstellar space. You know, rather than just having the Kerbol system end abruptly at Eeloo, which I think is a bit anti-climatic. UI themes. I'm not on about changing the layout (but I wouldn't be against that) - rather, methinks since that a lot of people don't like the analog/early digital style of the UI, it'd only be fair to have different styles that evoke different styles and time periods. Same layout, different coat of paint. I expect this one would be more carried by the community since it'd probably be a pain in the devs' Equus asinus to redo the UI several times, but an in game choice between skeuomorphism, retro and flat UIs would probably do a lot to quell the community's ire. Hold that thought, It also occurs to me that it'd be a boon to users with accessibility needs. Even just the option between the current UI and one with colour and typeface schemes to help with e.g. dyslexia could more than justify implementing UI switching. Speaking of switching, fuel switching and wet wings. With the exception of hydrogen tanks which are more than justified in their existence, there's no need for methalox and methane tanks to be completely different things, and just to name one example, it's annoying that Mk2 bicouplers suffer from wasted internal space in cases where oxidizer isn't needed. Real life wings also aren't always dry and being able to store fuel inside them would give a compelling reason to bump up the thickness of wings when customising them.

There should be a slider that fills and empties the tanks of a chosen stage according to flow logic and also graphing tools that plot the deflection of the thrust vector over time. Maybe a bit much to ask, but FAR had similar things for aerodynamics and it would be very useful for space shuttle alikes.

For the record, I think the timer UI could be more specific with when the engines should fire. I sometimes wait till my vessel crosses the red prediction line instead of using the HUD.

Fair enough, though I'm still curious what you think made it better given that it doesn't account for acceleration.

The NERV-US engine will be able to do that, and it'll come with a vacuum mode as well. The old way was extremely inaccurate and I'm struggling to figure out how it could be considered better under any circumstance. Unless you were playing with very high TWRs or simple missions, it'd lose accuracy easily, and things only got awful for nuclear vessels. The system KSP 2 uses isn't just more intuitive, it's also incredibly accurate and lets you do maneuvers that would have been extremely hard to predict in KSP 1.

Hm. Might need more clamps.

That's a personal opinion, though, and not representative of what everyone thinks. If you think it being in the left corner is fantastic, that's awesome. But please understand that not all of us like it that way, and we would like at least an option to move it where it would make sense to us. Sounds fine to me.