Bej Kerman

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.

No, that was literal game design. "Just pan your camera". That's Squad's idea of game design, but not a good alternative to having the navball on the left. The same holds for it being in the center, so it might as well be at the left so that said people with reduced vision and a ballooned UI don't also have to deal with their vessel being hidden behind the navball.

Those aren't solutions, those are workarounds. The navball being a bit further into your peripheral is not a massive problem, and especially for people with accessibility needs who need the UI to be scaled up, having the navball in the middle would be a massive problem.

Never said you were, I'm simply saying that the reasoning behind placing it in the middle only holds inside a physical cockpit.

Being able to see your vessel isn't pointless, docking and landing are still situations where having your vessel in view is important. That's why the navball was moved to the left and all the readouts moved to the navball, to get the best of both worlds.

Moving the navball to the left doesn't move the craft and also, again, forces the player to work with a much smaller view.

And you move the camera over and you can see whatever you need to see Which is much less elegant than moving the navball to the left so that you don't need to move the camera at all. I'm not entirely sure why you keep reiterating this, because the "reality of aerospace" is completely different from KSP 2.

No, its not. Yes it is - UNLESS you send a video of you completing a docking in KSP 1 or 2 with paper stuck to every part of your monitor that doesn't bear a UI element That's a matter of necessity. Pilots can afford to land with less visual information if they're told how ridiculous it is to have their aircraft converted into a podracer. This is a game though, and we can afford to budge the navball to the left so things are easier to see and - in the case of accessibility - so that users who require a large UI scaling don't see an entire sector of their screen obstructed.

Because it's critical for docking and landing perhaps. Simply just standing for the more elegant solution. Just to reiterate, real cockpits aren't a good analogy for a 3rd person interface.

This is an IVA shot, the camera is looking inside a cockpit. The instrument panel being there is entirely unsurprising, but also has no bearing on the rest of the conversation which is about the 3rd person UI. [snip]

Look, I conceded that its your personal preference. I was saying what I did because people other than you are interested in stuff like this. I get you are interested in being "right" so go be right and leave me alone. I'm simply pointing out that in real life, the pfd is located in the middle of your vision because you're looking from the inside out, and in KSP 2 you're looking from the outside in where having the navball in the middle of your vision will block your view, especially on a low res monitor. I'm saying what I'm saying because the situation is completely different and shouldn't be treated as a 1:1 analogy. No problem.

Not sure if you've played KSP 2 yet but the altitude, and several other readouts, were integrated into the navball.

The real life reason sort of falls apart when you're a disembodied camera orbiting a vessel instead of looking outside from the inside.

Because real life does not come with a 3rd person view. In KSP 2, there is a 3rd person view and that negates the need for the navball to be in the middle.

The navball can be smaller but it's still way better to the left and that would still be way more efficient, especially with a scaled up UI. As far as I'm concerned, you telling me that the navball can be less cluttered then immediately suggesting that the player should also have to distract themself with the pan while still contending with a much reduced vertical FOV is nothing more than doublethink because you're so nostalgic for how it was in KSP 1. Having to focus on all 3 at the same time for the sake of the navball placement is ridiculous. Again, kinda rude, definitely ableist. That's a massive stretch, but whatever, let me supplement my last statement. If you have tunnel vision, there are solutions that are a million times better and not nearly as hideous as moving the navball to the center so that it obstructs the bottom of your view.

Lmao, instead of dragging down drag to the side then. That's still awful and clunky compared to just moving the navball. What do you have against being able to see the entire middle third of your screen? Yes, sure, you suggest having to pan using MMB to account for the reduced space which would be distracting to have to do when going between situations where you need to see the top of the rocket vs the bottom (e.g. docking vs landing), and I suggest simply keeping the navball to the left so that there's no need to do that in the first place, and in your world the latter solution is an affront to humanity. That's why your eyeball is capable of moving around inside your skull. The entire reason the altitude move debate happened is because people wanted everything concise so that only one movement of the eyeball was needed to have both the alt and spd within the center of vision. Unless you have severe tunnel vision, the reduced field of view from a centered navball is way worse than the craft being slightly less clear when looking at the navball. Even then, I think you're exaggerating the cloudiness of peripheral vision for the sake of arguing against the navball being offset.

Isn't that lovely, now whatever was in front of the craft (like maybe a space station you're docking with) is offscreen and your vertical field of view is effectively reduced. Let's face it, the middle of the screen is an awful place to put it and if KSP 1 didn't have its awful layout set in sone then you wouldn't need to suggest a workaround as janky as "just offset the camera and cut out whatever was in front of the vessel" You look at the bottom left corner to see your instruments and you look at the middle of the screen to assess the situation. That's how it works in 3rd person. Haha, speaking of resolution, I was watching Matt Lowne play the console edition and it is absurd what a badly placed navball and large UI scale does. The developers clearly have small monitors and accessibility in mind here which I appreciate. If it was layed out like in KSP 1 you could expect to see the entire bottom middle third of the screen wasted.

You hate it because there's not a navball blocking you from seeing the aircraft?

Ah yes, specially with the SAS wobbling your craft all over and the phantom forces from reaction wheels being huge. Those are not issues I've seen people discuss, let alone experienced myself.

Even ignoring the game itself and just reading up on its development, it's way less irritating reading the developers' thoughts and their plans than it was reading up on what Squad was doing with KSP 1. Reading up on Squad's development, it's impossible to not question why they were more bothered with fireworks and textures, than they were with better accommodating low thrust engines (like KSP 2 does now), fixing the holes in the parts list, hell, even extremely easy things like adding one or two more timewarp levels. It's actually stupid that they introduced Jool and Eeloo, and could have easily saved all of us over the years an accumulative tens or hundreds of hours waiting for vessels to sail to the outer parts of the system.

Now you're just being silly! That's an edge case causing a CTD. Indeed! Might I point out, if you used an edge case to discredit KSP 1, people would get mad (read: double standard). I've played KSP 2 fairly regularly this week, launching big rockets and I've even played with docking. it's a fairly smooth experience - dare I say way smoother than KSP 1 when it comes to low thrust gameplay particularly.

It's still Squad's fault for trying to put a game fundamentally unfit for console on console, and finding a company that was unable to do this well. The good old double standard. KSP 2 suffers from flaws -> claim it's a scam and fling excrement KSP 1 suffers from flaws (+ outright lies about the console edition) -> don't hate the developers, it's the engine's fault! Squad is perfect in every way and exempt from criticism of its incompetence and prioritisation of rubbish + fireworks over core features

Console players have waited literally years for a single update they were promised for KSP 1.

And optimisations will happen so don't consider it a permanent mark against KSP 2. Non sequitur Nope, the altimeter is the primary example of bad design but the rest of the UI still suffers much the same of nonsensical (and inconsistent) placements. Or maybe features that receive a lot of compliments and little criticism aren't going to be changed to please the critics? The instrument tapes exist for the same reason they exist in real cockpits, and frankly a complaint about "funny noises" in a game about space frogs is a nitpick of the highest order. Please do explain part models and such loading in when they're created instead of being pulled straight from RAM.

That's objectively wrong. The game handles its assets much differently which is evidenced by the fact that loading times aren't long enough that your resolve to play the game can fizzle out between telling the game to open and seeing the space center (and to some extent, the way parts are coloured and respond to lighting). Engines can burn in warp which is an immediate advantage given that in KSP 1, Better Timewarp and/or Persistent Thrust are prerequisites for ion engines and the NERVA unless you have all the patience of a stray atom in intergalactic space. The UI also doesn't suffer the problem the KSP 1 UI had in terms of layout, that is some jobsworth working at Squad refusing to have the altitude and speed moved closer together from where HarvesteR put them back when KSP 1 had effectively no features (either that, or they seriously didn't see a problem with the layout of the UI for the many years people had to look at it when doing QA). A landing can be done without diverting ones' eyeballs from the navball which would have been impossible if the navball, input gauges and altitude were still scattered haphazardly across the screen. The style might be debatable and the way the UI is rendered is suboptimal, but those are frankly nitpicks compared to the overall layout, which is no longer, to put simply, stupid. People can keep panicking about the features, but when it comes basic QOL features that Squad deprived us of like persistent thrust, a UI that isn't ridiculous, load times that aren't idiotic and acceptable RAM usage, I'd say it improved a great deal on KSP 1 and delivered the more solid foundation we were waiting for.