PDCWolf

God, your images hadn't loaded at first. Someone who knows what they do related to UI is gonna see that and snap.

The navball is your view, it's the thing that tells you if you're on alignment, going straight at your target or slanted, and how fast. If you're so zoomed in, who's to blame? Still, the navball is the main instrument you're docking with. The navball is the thing you look at, specially on a case where you need an alignment to be established pre approach and for the approach to be strictly straight as to not bang against something. You're setting examples of people specifically shooting themselves in the foot by not knowing how to use instruments and ignoring them, and them crying that they're obstructing the view. No bro, that's the one thing you should be looking at. Based on your example, if you zoom in enough you wouldn't see the ground anyways, so why would zooming out and in be an option in one example but not the other? hmm... Yep, and in both cases the navball is as close to the window as possible for the construction limitations the LEM has. In fact, they took care to put the navball right by their vision in both stations, which is why they're at the edge of the window no matter which side you take.

I don't enjoy mechjeb, but yeah, you just don't hear pilots say "the cockpit is obstructing my view", no, the cockpit is doing a better job of guiding you to a safe landing than whatever your eyes could, specially in bad weather. The cockpit is your view, it's where your eyes should be because even in 3rd person you don't have the correct information. This is why those hyperbolic claims of docking with the camera are not even addressable. Either you're being bad at it and wasting time on alignment, or you aligned everything with instruments before anyways. Set in stone for now. Hopefully they make it movable first, and mod-able second. As for KSP2 being an improvement over 1... yeah, let's just say not yet, on anything. Set altimeter to ground, pick a flat-ish spot and go down slowly... Unless you're going for a fully manual 500m/s to 0 type suicide burn, there's no reason to slam yourself into the ground at any point.

The resolution discussion was attached to accesibility. It's right there, you can go back and check: bigger resolutions push the navball further away, taking the craft even further away from peripheral vision. Now, this is exceptionally funny because it's the opposite when you scale down, right until the UI does become obstructive, but at that point, why even bother discussing at all? Yes, the UI will always either be obstructive, or will also be too far away, or whatever other misconstruction you're interested in continuing to make. Whatever they did with the trainwreck that is the console version I have zero care in the world for, other than a "I'm sorry" to console players. We'd have to resurrect SQUAD and ask them what their intended scale (in reality we know the intended is whatever "1" represents in that menu) is, and at which resolution. And then we'd have to ask them why the console version looks like that. You're projecting industry standard practices on what effectively was a ragtag team of indies most of which were working on their first project. We should be glad they reached a standard at all, and ask why a team of 50 trained professionals produced such a clunky, controversial UI. Matt Lowne's mistake was getting the console version without being informed of what a trainwreck it was. I agree with the rest except for accusing SQUAD of following aviation 101 with their UI.

That screencap is painful to look at, however I don't think it's too fair to the discussion to guide ourselves on what happens outside of standards. The game was designed for and tested at a certain resolution, and for what essentially is the default UI scaling. This is a convoluted way of saying: Yes, if you make it take the whole screen, I agree it's obstructive. However the also would be true no matter where you put it, you can make it obstructive if you play on like 800x600 for example, or scale it to the max. As for people saying it's obstructive in KSP1, I really can't relate, I showed how I play, it's a complain that in like a thousand hours (yeah, not a veteran, I know) I've never had.

Except the trend has been, at least on games that treat their audience as having more than 2 braincells, for healthbars to morph into in-scene assets, or color overlays, or audio cues, or animation cues, and so on. What games need to convey rapidly is damage direction, and guess where damage indicators are... yeah, right in the middle of the screen.

Here, since we're posting game media, here's me landing on KSP1 (I recorded this some time ago for someone on reddit). At least you'll understand how the navball really doesn't bother me at all. https://streamable.com/cuhvcv Also it'd be really cool if the forum embedded Streamable. Edit for data: this is recorded natively at 1080p.

Minimap and healthbars are not on the same category as a navball. A navball is a very basic SA instrument that you wouldn't be able to fly without in a lot of situations. This is what flying looks like in third person in Starfield. Orientation instruments go as close to the middle of the screen as possible, even on top of your ship. Everspace, orientation cues go in the middle of your vision. The fantasy comment is aimed at me not knowing how realistic they made the huds. I know the planes are mashed up from real life, or at least inspired, but I wouldn't know if they put approach and landing type HUD pages because I never played VTOL VR. However I do know in real life people have worked a lot on giving pilots the ability to land whilst still looking at the hud, because it's kinda hard to look through the floor of your plane, and you still need the AOA and vector information anyways. Because saying the navball obstructs the view is in reality much more dependent on it being a giant bloated mess than its positioning on screen. It's an argument we wouldn't be having if it was decently sized and not as wasteful on negative space and useless elements. If we can't have a transparent centered hud like most space games have, we should have the navball as close to the action as possible, because as much as I can move the eyeballs in their eyesockets, I'd prefer it if I'm able to use my peripheral vision instead of going all the way to a corner. 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.

This is such a lousy argument, well, not even an argument but a logical fallacy. Like sure, there's people who have played thousands of hours of nothing but KSP1. I'm pretty sure they're not either the majority, or even the majority that support the navball in the middle. You're not even attacking the argument of having the navball in the middle, you're straight up attacking the person, which has so far been the only argument for the navball on the side: "You're uneducated" "You're nostalgic" "You're too used to how it was" "You dislike change" So far, the only somewhat valid argument is that it obstructs the view, which is much more dependent on how badly designed and wasteful of space the navball is than anything else. As for you having to use see-through to land, I don't know how VTOL VR manages its fantasy planes, but IRL you have a hud mode that tells you the AoA to maintain, and your velocity path, and every modern airliner is pretty much designed to being able to land with 0 visibility, which is why you get a flight director that hooks to the ILS. Now, before this is yet again misconstrued as meaning something else and returned as an attack on my person: No, I'm not saying the navball should cover everything and everyone should fly IFR, I'm saying we should get properly designed, compact and informative-at-a-glance tools and be told how to use them properly. Finally, there are people with Visual Field Deficits, Focus Deficits, and so on, and they'd definitely appreciate the navball in the middle, as looking to the side (made worse depending on monitor size and resolution) means not seeing the rocket anymore.

Area rule requires a whole re-abstraction (or proper simulation) of supersonic aerodynamics, plus there'd still be no way to apply it to fuselages, only wings.

how does life support break timewarp exactly? it'd be no different to an engine draining fuel, and maybe creating another waste resource if they go that route.

You'd probably get a transparent hud like on any HMD. In fact, it's been the biggest interest to keep everything as close to center as possible so the pilot can read stuff and make out details from peripheral or central vision. Particularly, the F35 overlays the zoomed in images from targeting pods right in front of your vision.

I'll try to not just be "make the game better lol", but rather ask for very specific stuff, since that's what you want. Feature parity, DLC included. (Robotics, historical parts). Life Support. More landing gear variety, both wheels and legs. Procedural fuel tanks. A proper color picker with HEX/RGB/HSL A complete elimination of wobble, being replaced with whatever other solution that doesn't make your rockets noodle unrealistically and unintuitively. Non-tree building. Open the UI for total moddability. Stock kOS or expanding the HAL controller from KSP1 robotics. Almost every other "build your own whatever" game has a proper automation system in place. HAL was good but I need to be able to read the status of parts and the environment and program appropriate reactions. A Photo mode that's at least as good as the one in Cities Skylines 2.

In the windshield or HMDs you get a projected transparent HUD, speaking volumes of having the information where you need and not where it looks pretty and "doesn't obstruct your view". The information doesn't obstruct the view, it is part of the view, but hey, I'm the uneducated person. You wouldn't say the cockpit obstructs your vision.

Except they're making instruments to fly spacecraft with. Making the things recognizable is fine, but it's greatly exaggerated. Lmao. "it can be bad so long as it agrees with what I say". [snip] 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. [snip]

On the one hand, you. On the other hand, the entirety of the aviation and aerospace industry coming together on a simple, universally accepted, compact layout to reduce training times and not have your pilot looking all over for information. Yeah no, I know who I'm listening to. 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, that's because it's uselessly big, bloated, includes useless elements, and misuses more negative space than it needs. If you want more graphic design course words, readability is low, specially because all values wobble with phantom forces, and the default altitude is set to ground. There's also a lot of unused borders, as they're borders that open to negative space, which means the negative space could easily be eliminated. There's no skeuomorphism in it at all, as it's completely a fantasy design not inspired by anything real, so it's more gamified than realistic. It is an uninspired mess of clashing signals and misplaced elements that somehow all end up on top of each other for no reason. Lastly, it's inconsistent in a lot of its choices, namely how some things have full labels, others have no labels, and others have l33t_spk_labels. Post it on the challenges subforum / subreddit. I'm sure this'd be fun. You could use orbital parameters plus epoch to know where the mun is, and the height of your lander stage to know the ground altitude true zero. The only hard thing really would be proofing, as it'd require people record their own covered monitors for a very long period of time. How do people not dock through the navball? if you match alignments and correctly set the control point and the target part, the navball is perfectly aligned, and thus your whole craft.

That's just inflated hyperbole. Looking at a PFD is an intuitive as looking at the current navball, the only thing it lacks is the labels on everything, and whatever is not on the KSP navball can be safely removed (which would actually make it more compact).

You saw the PFD picture I uploaded as an example, that's as optimal as it can possible get whilst still keeping the tapes. If you remove the tapes (since they won't ever show useful information anyways) it can get even more compact.

On the contrary. The argument about having your screen restricted comes from willfully ignoring the tools the game gives you and the KSP2 navball being bloated and oversized. You can reduce the size a lot without reducing text size or losing information, that's how badly designed the whole navball is.

And then you waste half your screen on either empty space or the ground. Bruh. It only "blocks" your vision because it is bloated and oversized. Hopefully they revise it at some point. Scaling it down as it is right now would mean you still waste a lot of space on negative space and useless tapes. I wonder where transparent huds go... Opaque: Centered and bottom. Transparent: Right in the middle.

No, that was literal game design. And for people with reduced vision having the navball all the way on a corner means they can't look at their ship.

On the contrary, any problem created by the navball being on the center had a solution. The problems created by the navball being on the side don't until it's correctly sized (or at least scalable) and able to be moved back where it should. Speak for yourself.

Panning would move the craft less than moving the navball all the way to the corner, and works both ways, not just left to right.

And you move the camera over and you can see whatever you need to see, which is even better if the navball wasn't uselessly bigger than it needs to.

That's not a navball, that's a GPS top-down map. Good try though.