KSP2 EA Grand Discussion Thread.

[Bej Kerman]

45 minutes ago, PDCWolf said:

Lmao had to pull the single exception in the suite of like 50 images posted to this thread. That really paints the picture of your whole arguing until this point, grasping at straws and creating whatever cherry picked scenario you can to try and maybe dig out a point.

Okay, this one's on me, I should've figured something like this would happen as soon as a real world example of the navball being moved to the left came up.

46 minutes ago, PDCWolf said:

With that, I'm done.

Bye bye

[The Aziz]

Only 10 pages, 3 days and at least two moderator interventions. Nice.

[cocoscacao]

Navball should stop working when electric power is 0.

[Royalswissarmyknife]

28 minutes ago, cocoscacao said:

Navball should stop working when electric power is 0.

They should shut your computer off instead.

[Periple]

5 hours ago, PDCWolf said:

Lmao had to pull the single exception in the suite of like 50 images posted to this thread.

I was taught that it only takes one counterexample to falsify a hypothesis!

[LoSBoL]

10 hours ago, PDCWolf said:

Can't blame game designers for not making a UI work on every resolution and screensize combination possible, that's just a reality of the industry. Ask anyone with an ultrawide monitor and they'll tell you how that reality applies to them as well.

Indeed, if you’d ask me I’d place my navball like below in KSP1, it’s placement resembles the lower left corner of a 16:9 screen and is within my peripheral vision. But as in KSP2 where the UI is so big, it didn’t took long to get used to having it completely in the left corner. I’ll probably be lowering the scale and placing it like below when the opportunity is given.

10 hours ago, Bej Kerman said:

People who suffer from eye problems, as valid as their problems are, are not a majority of the playerbase, same goes for people who go overzealous on ultrawide setups,

I’m sorry that my enthusiasm and sharing my wide screen experiences with KSP2 is being perceived as being shoved down your throat, it isn’t meant to be. It’s not meant to be to set a new standard or ‘where the navball’ should be placed as a standard either.  Yes, 16:9 gaming is the majority and I only point out that KSP2 with its huge UI, huge fonts in PAW’s, Manager Windows and Parts Picker which all diminish the working space when playing it 16:9. Now that might be a personal opinion, but considering that from almost day one quite a few people are being cranky about its UI, its size and its placement, I’m not really alone having a somewhat similar opinion. It's also being acknowledged by Intercept, we've already gotten scaling and modularity in the future is in their scope.

I think the majority just plays with what’s been given as standard and don’t bother changing anything, if the navball is in the center, people play it like that, if it’s to the side, it’s in the side.  I don’t even care what the standard is although I do feel they made the right decision because the Navball in the middle only makes sense in either first person view or when in 3^rd person view with a chase camera. (Again, personal opinion)

16:9 gaming may be the standard, but that doesn’t mean at all that developers don’t look at other scalings and also keep those in mind, and KSP2 scales very, very nicely to 21:9 like many other games these days do, that doesn’t come by itself but only when there has been thought about that by the developers. It’s not ackward that with KSP2 that they have wider screens on top of their mind. So no, I’m not saying they should develop with wide screens in mind, In my opinion they already have been.

Maybe in the future one day you’ll get to play a bit of widescreen gaming as well, and you can experience for yourself where both the enthusiasm and growing popularity comes from and wont be so dismissive towards it being a thing. 

Peace.

Edited November 13, 2023 by LoSBoL

[The Aziz]

12 minutes ago, LoSBoL said:

be so dismissive towards it being a thing. 

Desk space, my friend.

[LoSBoL]

1 minute ago, The Aziz said:

Desk space, my friend.

Can you elaborate? It you're thinking height. going wide doesn't mean you'd loose height, height in this case is 1440P. Like all screenshots except for the the KSP1 one are in 1440P, even the 16:9 one, the UI still keeps being huge in higher resolutions.

[The Aziz]

I mean, I, and probably many others, don't have enough space on their desks to put a wide or ultrawide screen there. I have two monitors right now and changing one to 21/32:9 would be impossible.

Edited November 13, 2023 by The Aziz

[Bej Kerman]

57 minutes ago, LoSBoL said:

Maybe in the future one day you’ll get to play a bit of widescreen gaming as well, and you can experience for yourself where both the enthusiasm and growing popularity comes from and wont be so dismissive towards it being a thing. 

I just did. 2.35 if you're curious. It wasn't bad and it'd work for something like SpaceEngine or Elite Dangerous, things that don't demand vertical space (hell, in Elite Dangerous, it's better since some ships have little vertical leeway but a lot of windows along the sides), but I'd still rather use the top and bottom of my monitor in the case of KSP 2 rather than spend it on black bars.

Maybe I'll revisit using scope in a more literal sense if I ever wanted to record cinematic footage, but for most intents and purposes I think just sticking to 1.78 and scaling down the UI will yield the desired real estate without leaving unused areas of your monitor.

1 hour ago, LoSBoL said:

I’m sorry that my enthusiasm and sharing my wide screen experiences

Don't apologise for that, I was more concerned about you putting 16:9 down as if it's useless. It's a nice compromise between the academy ratio and scope.

[Periple]

12 minutes ago, Bej Kerman said:

Don't apologise for that, I was more concerned about you putting 16:9 down as if it's useless. It's a nice compromise between the academy ratio and scope.

There's a reason 16:9 is the standard. It is a really good compromise for most purposes. Widescreen only really comes into its own in sim pits, a friend of mine has an e-racing pit built around a 32:9 curved monitor and it's amazing. Once IVAs are working properly in KSP2 I might consider buying one, I finally have enough space for it!

(That said I really do love the crispness of the 4K monitor I have; I do use it work for work as well, and 1440p feels like a downgrade for reading.)

[Guest]

4 hours ago, The Aziz said:

Desk space, my friend.

Not to go too much OT, but honestly anyone spending the kind of money that a decent monitor costs should also totally invest in a 50-80 bucks mount for it, one that clamps on the border of the desk instead of taking half of it.
I really don't know why every monitor comes with a giant stand that take away half of any decently sized desk.
My current (16:9) LG monitor came with a stand so big that I couldn't fit my mousepad and keyboard on the desk, and it's not like I use a huge mousepad (Logitech Powerplay), and my current keyboard is a 75%

[The Aziz]

It doesn't change the width these would be taking anyway. I can't move my consoles because there's nowhere for them to go, switching from a stand to a clamp only gives a bit of space under the screen.

[LoSBoL]

6 hours ago, Bej Kerman said:

I just did. 2.35 if you're curious. It wasn't bad and it'd work for something like SpaceEngine or Elite Dangerous, things that don't demand vertical space (hell, in Elite Dangerous, it's better since some ships have little vertical leeway but a lot of windows along the sides), but I'd still rather use the top and bottom of my monitor in the case of KSP 2 rather than spend it on black bars.

Maybe I'll revisit using scope in a more literal sense if I ever wanted to record cinematic footage, but for most intents and purposes I think just sticking to 1.78 and scaling down the UI will yield the desired real estate without leaving unused areas of your monitor.

Don't apologise for that, I was more concerned about you putting 16:9 down as if it's useless. It's a nice compromise between the academy ratio and scope.

Black bars is something you definitely don't want, than you indeed loose height. You don't have those bezels if it's your monitors native resolution though, playing 21:9 on a 16:9 screen is something I wouldn't do either. 

16:9 is far from useless, unless you don't use the additional wide space. I've worked in an office with 400 people, and frequently did some workplace management, I reluctantly replaced 5:4 dual setups for 16:9 dual setups. I was the last one to loose my 5:4 setup, I kept them as long as I could because the added workspace was a nuisance. None of the used applications scaled nicely back then, and the double 16:9 setup was just a waste of deskspace. It became better, because the applications now do mind better that there is space that can be used. And you do see the same thing happening with 21:9 gaming.

i'll try to be more mindfull in how my writing could be perceived, thanks for the feedback.

7 hours ago, The Aziz said:

I mean, I, and probably many others, don't have enough space on their desks to put a wide or ultrawide screen there. I have two monitors right now and changing one to 21/32:9 would be impossible.

I can see how that would be troublesome, a one meter monitor does take up a lot of space indeed, they are more to replace two monitors, not just one. As I mentioned in the other topics, an 32:9 monitor has multiple inputs and can replace a dual monitor desktop. You just loose the physical bezel while retaining a dual setup configuration with the press of a button.

[Scarecrow71]

3 hours ago, The Aziz said:

It doesn't change the width these would be taking anyway. I can't move my consoles because there's nowhere for them to go, switching from a stand to a clamp only gives a bit of space under the screen.

I'm in the same boat you are right now.  I've already got 2 monitors on my desk (one for personal, one for work), and I've got no room to upgrade my personal monitor to something bigger.  I happen to have a 42" flat screen I could use, but it won't fit.  Sigh.

[Wheehaw Kerman]

23 hours ago, The Aziz said:

Only 10 pages, 3 days and at least two moderator interventions. Nice.

I think we’re doing better than we were back in March, though…

[Dakitess]

Wow, i've never seen as many pages on a dedicated topic   Impressive ! I've read something like 75%, it's interesting.

I'll add my 2 cent as a former (it's very (very) recent haha) ergonomist, with a little UI / UX experience in a specific domain I won't elaborate here : you really want "geographic" coherence as much as you can. If I have buttons on both side of my wheels, they need to control accordingly the main pilot HUD and the secondary entertainment screen. If I use proximal cameras, like 5 around the vehicle, they need to be presented in a small grid accordingly to their overall position around the vehicle. On this example, some people can have hard time figuring out that the "top" one on the screen is the "facing" one, because the representation is equal to a top-down view, while you see the screen from a personal perspective view. This is already a compromise, but it's mainly okay because there auto-references : you can set the silhouette of the vehicle in transparent below the camera feeds so that the user will passively understand what is where, what video is showing which axes, etc.

Here, setting the NavBall on the side is not ideal and we know by KSP1 that a center position is doable, while maybe nor perfect either since it can mask a small part of your craft during the crucial step of landing vertically. Fortunately, the panning was perfect for that specific reason and solve in half a second.

Having the NavBall on the side misalign the axes. The NavBall Up is no longer the Craft Up. You need to transpose diagonally, without auto-references since the NavBall is... Well, a sphere. Let's agree on a point : there is nothing impossible or prohibitive here, you can get use to it, and you even will. But it's not ideal, and quite easily less optimal ergonomically speaking than a centered one, even when considering the drawback and advantages of both situation (masking / alignments). I'd rather have it centered and movable than the opposite, while the actual design is totally made up for corner.

Knowing that, a centered NavBall could have been properly designed to minimize the occultation while providing the essential information. Transparency, contrasts, shape, additional easy to read information, etc. Juno has innovate on that aspect, won't say if it's better or not, but there is solution. And really, I need to get the altitude, the speed and the NavBall orientation aligned with my craft, on the center of my screen.

Edited November 14, 2023 by Dakitess

[Bej Kerman]

3 hours ago, Dakitess said:

Here, setting the NavBall on the side is not ideal

You never explain why

3 hours ago, Dakitess said:

Fortunately, the panning was perfect for that specific reason and solve in half a second.

Already explained why that's a bad solution.

[Guest]

3 hours ago, Dakitess said:

I'll add my 2 cent as a former (it's very (very) recent haha) ergonomist, with a little UI / UX experience in a specific domain I won't elaborate here : you really want "geographic" coherence as much as you can. If I have buttons on both side of my wheels, they need to control accordingly the main pilot HUD and the secondary entertainment screen. If I use proximal cameras, like 5 around the vehicle, they need to be presented in a small grid accordingly to their overall position around the vehicle. On this example, some people can have hard time figuring out that the "top" one on the screen is the "facing" one, because the representation is equal to a top-down view, while you see the screen from a personal perspective view. This is already a compromise, but it's mainly okay because there auto-references : you can set the silhouette of the vehicle in transparent below the camera feeds so that the user will passively understand what is where, what video is showing which axes, etc.

Here, setting the NavBall on the side is not ideal and we know by KSP1 that a center position is doable, while maybe nor perfect either since it can mask a small part of your craft during the crucial step of landing vertically. Fortunately, the panning was perfect for that specific reason and solve in half a second.

Good example with the proximal cameras.

Cameras that, in the grid you correctly described, get displayed on the infotainment screen.

Screen that sits on the central console, in the far corner of the driver field of view, not above the wheel, covering 1/3 of the windshield.

 

It's honestly absurd how many of the examples that should point towards a navball in the middle are actually the exact opposite.

[PDCWolf]

4 hours ago, Dakitess said:

Wow, i've never seen as many pages on a dedicated topic   Impressive ! I've read something like 75%, it's interesting.

I'll add my 2 cent as a former (it's very (very) recent haha) ergonomist, with a little UI / UX experience in a specific domain I won't elaborate here : you really want "geographic" coherence as much as you can. If I have buttons on both side of my wheels, they need to control accordingly the main pilot HUD and the secondary entertainment screen. If I use proximal cameras, like 5 around the vehicle, they need to be presented in a small grid accordingly to their overall position around the vehicle. On this example, some people can have hard time figuring out that the "top" one on the screen is the "facing" one, because the representation is equal to a top-down view, while you see the screen from a personal perspective view. This is already a compromise, but it's mainly okay because there auto-references : you can set the silhouette of the vehicle in transparent below the camera feeds so that the user will passively understand what is where, what video is showing which axes, etc.

Here, setting the NavBall on the side is not ideal and we know by KSP1 that a center position is doable, while maybe nor perfect either since it can mask a small part of your craft during the crucial step of landing vertically. Fortunately, the panning was perfect for that specific reason and solve in half a second.

Having the NavBall on the side misalign the axes. The NavBall Up is no longer the Craft Up. You need to transpose diagonally, without auto-references since the NavBall is... Well, a sphere. Let's agree on a point : there is nothing impossible or prohibitive here, you can get use to it, and you even will. But it's not ideal, and quite easily less optimal ergonomically speaking than a centered one, even when considering the drawback and advantages of both situation (masking / alignments). I'd rather have it centered and movable than the opposite, while the actual design is totally made up for corner.

Knowing that, a centered NavBall could have been properly designed to minimize the occultation while providing the essential information. Transparency, contrasts, shape, additional easy to read information, etc. Juno has innovate on that aspect, won't say if it's better or not, but there is solution. And really, I need to get the altitude, the speed and the NavBall orientation aligned with my craft, on the center of my screen.

Very well put. Sadly it's in one ear, out the other 99% of the times.

[Bej Kerman]

Just now, PDCWolf said:

Very well put. Sadly it's in one ear, out the other 99% of the times.

Welcome back!

Per myself and Master39; I'd also be interested in you addressing the flaws in  Dakitess' evaluation.

[PDCWolf]

14 hours ago, Bej Kerman said:

Welcome back!

Per myself and Master39; I'd also be interested in you addressing the flaws in  Dakitess' evaluation.

The "flaw" is misconstrued into existence based on a severe lack of basic understanding, this is why I lost interest in arguing [snip]

Edited November 15, 2023 by Vanamonde

[Dakitess]

1 hour ago, Bej Kerman said:

You never explain why

Uh, like, "geographic coherence" (pardon my English though, it sounds very wrong xD) and the fact that axis are misaligned, forcing the user to correct the boresight (?) since it's diagonally positioned ? Having crucial information not directly close to the center cone of vision but rather on the side, forcing the user to switch from the craft to the data, at crucial moments ?

Did you read it, or ?... Please do, if you want to debate. Totally open for that, as ergonomics can be very subjective, just like this thread shows.

1 hour ago, Master39 said:

Good example with the proximal cameras.

Cameras that, in the grid you correctly described, get displayed on the infotainment screen.

Screen that sits on the central console, in the far corner of the driver field of view, not above the wheel, covering 1/3 of the windshield.

 

It's honestly absurd how many of the examples that should point towards a navball in the middle are actually the exact opposite.

So... Did you read as well ?

The camera feed example is indeed a way to show that centered information, respecting axis, is way better since you don't need a reference to get it right and you don't have to adjust for a misalignment between where / how the information is disposed, and what it actually shows. By the way, theses video flux being off-centered on the entertainment screen on the side is... Not a good thing by any mean, just a compromise, there is no added value, just the obligation to not obstruct the main HUD data already well busy. Which is not the case for KSP and the situation we're discussing about.

Do you actually like to look 25-40° on the side + 25-40° vertically while doing a maneuver ? Because where I work, this is only an acceptable compromise when we can't do otherwise.

My two cents were just a way to get some inputs from an Ergonomics point of view, not totally adequate to the actual situation : this is by no mean any kind of authority argument, just something like... My 2 cents. You can discuss it, you can totally disagree because a 3rd view game is nothing like a 1st subjective view in a vehicle. That's not the point, more about some common principles and a specific subject regarding NavBall position and rather why I would prefer the center view and why my basic knowledge about it would support it, that's it. Video game HUD / IU ergonomics has its own field, but it's quite famously derived from IRL UI

Edited November 14, 2023 by Dakitess

[The Aziz]

A fool's hope...

[Guest]

51 minutes ago, Dakitess said:

Not a good thing by any mean, just a compromise, there is no added value, just the obligation to not obstruct the main HUD data already well busy. Which is not the case for KSP and the situation we're discussing about.

Once again, I have to remember that the whole point of the thing to be moved to the side is exactly because of the navbal obstructing the view in the middle, in many situation in which it's crucial.

 

And I also remember to have proposed at least two options that would keep the instrument in the middle without obstructing the view. 

 

Plenty of people gave plenty of examples for situations in which a view of the landing zone is crucial.

And so far, all the counter examples have been of capsules that gets dropped in the ocean with parachutes and controlled from the ground anyway (the Apollo lander has a navball on the side, and the docking view for the dragon has a navball on the corner of the screen), or planes that either have an holographic HUD (like the one I support) or slowly glide at a low angle towards a paved runways they've aligned with 15 minutes earlier.

 

1 hour ago, Dakitess said:

Do you actually like to look 25-40° on the side + 25-40° vertically while doing a maneuver ? Because where I work, this is only an acceptable compromise when we can't do otherwise.

Depends on the maneuver.

If I'm doing a gravity turn, I need to focus on the navball, and I don't care where the rocket is in my view or even if it is at all, it's not like I expect to hit any obstacle. So the configuration doesn't really matter.

But if I'm landing, I need to see the ground, the obstacles, the slope. In KSP most of the landings happen on improvised surfaces. And yes, you need the navball for that, but other than the altimeter you don't need to focus to it too much, it's a high contrast tool, you can keep it in the peripheral vision while you focus on the much more important landing spot.

Being able to see where you're going is gonna be important enough to justify the compromise.

If anything has to go back to the middle, switch places between the altimeter and the time warp controls.

And no, the last thing I wanna do while trying to land something is start messing with the camera. It's like I'm complaining about the infotainment screen being mounted on the windshield and your solution is to use a periscope out of the side window.