Bej Kerman

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.

Except it is! It's fine when it's in the left corner, since it's in the left corner there is no problem.

Except they're making instruments to fly spacecraft with. They're not making instruments a newbie can figure out in the time a tutorial lasts and you should not be under the impression they would be any good with that. Lmao. "it can be bad so long as it agrees with what I say". Except it's not bad. But a PFD being unreadable is only a construction inside your mind. Reality begs to disagree, the thing was made to be instantly readable at a glance with minimum training. "readable at a glance with minimum training" means 2 completely different things in the aerospace industry and the gaming industry. The level of discussion that can be expected in this forum. Such as "it's bad because (it's / it's not) skeuomorphic"? [snip]

A graphic designer working in the aviation industry obviously has different goals to a graphic designer working in the gaming industry. If you're listening to the former and not the latter, don't tell me you're listening to the right people. Since we're on Chapter 8 "Appeal to Authority", KSP 2's graphic designer(s) knew what they were doing when they made each element big and recognisable. I thought I just came from a whole page of people crying about the navball eating up a lot of the screen if it was in the middle? Well, it's not in the middle so that's not a problem. The problem only exists when it's in the middle, and surprise surprise, it doesn't need to be in the middle. [snip]

Don't know, I probably wouldn't mind it if it were at the top since that's where the sky is, maybe the devs put it at the bottom since it's a habit to look down for instrumentation, whatever. As long as it's in the corner and a lot of space is given to the rocket, I don't care.

To quote Tantacrul: "Now, obviously this is all subjective and you might think, 'Hm. I prefer [X]'. And that's okay. It's okay to be wrong." I'm just saying, forcing players to disable their UI to get a check in on the physical state of their rocket and pan the camera around when the UI is present, all because you didn't want the navball to be panned to the left, is horrible design, and it isn't justified by the subjectivity argument because, by that token, people aren't going to like having to put a lot more thought into managing their screen space. In a game like KSP where you deal with a lot of intense situations in real time, you don't want them to be managing screen estate at the same time that they're landing a rocket. Don't seriously suggest that panning the camera and juggling between F2 modes while landing a rocket is your idea of a good alternative to simply having the navball on the left so we don't have to do any of that.

I'm not sure how you dock, but when I'm docking, I quickly tab my eye between the navball and the ship itself, and having it in the corner is a massive help because it's just more space to see what's happening around my vessel. Adding a pointless keystroke JUST to have it in the middle would be even more obtuse and pointless than PCDWolf's earlier "solution" of panning the camera when the center-panned navball leaves you with a CinemaScope sized portion of a potentially already tiny screen to view your vessel with. I'm noticing a pattern in all these "solutions" to a center-mounted navball, and that's having to manually adjust the screen and camera during these situations, which would be distracting, instead of just having it at the side as it is now and leaving it at that.

I just gave you a straight answer

Because why not have the navball and the ship visible at the same time, and have an adequate amount of screen space to look at the ship with?

It isn't. It isn't. Just so it's clear, a two year course in graphic design would not start and end on the word "compact". If you or anyone else ever take up the challenge of improving the KSP 2 navball, maybe get familiar with the word "negative space" as well? Because you should expect to hear it a lot if people start making navball concepts. It's a game, aesthetics are extremely important in UX/UI (the way a UI is layed out is not just decorative!) and the nature of a PFD won't do if you need a player to be able to gather info from the navball quickly without having to pause to parse all the numbers and info. A 1:1 copy of the Boeing PFD will simply not do. Because why not both? That's why it's in a corner and not the middle.

I don't think so, a PFD like the example you sent would be an information overload for a new player who has never seen a PFD before. Those things are designed for pilots who are going to spend ages learning the ins and outs of their aircrafts, I still want to see a mockup geared towards KSP itself. You're purely thinking about the size of the navball and treating things like negative space and dividing information into clear clusters as an afterthought. Each part of the navball needs to clearly look like a different readout and have space between them, which I think it does an excellent job of. I still contend that the navball's size only becomes a problem when you shove it inside the center third of the screen and that its current appearance is completely fine where it is by default, but I enjoy a good UI mockup.

The size of the navball is way less of an issue if it's to the left. It's not the end of the world if the navball is 5% bigger than it could be, and I look forward to seeing your idea of what it should look like. Do you suggest that the sides of the navball should be cut off as if it were in a small window and that it should be up to the player to pan the navball window around if they want to bring different parts of the navball into view? Jokes aside, please do make a mockup of what you think it should look like. Surprise me.

And then you waste half your screen on either empty space or the ground. Bruh. That's a funny way to say "and then half your screen is dedicated to being able to see the things around your vessel". So the entire reason you took this stance is because you want the screen to be restricted? Again, doublethink. You say the navball being big is bad, but at the same time you have no objection to the theoretical scenario where you have a user with poor eyesight who increases the UI scale and, as a result if the navball is centered, it blocks most of their view. And for the fifth (or sixth?) time, forcing the user to then pan around with the tiny slit of their screen left (effectively tunneling their in-game FOV) is a terrible idea and MMB is not a replacement for being able to see.