Snark

Currently, if the game is paused, everything involved in the maneuver UI goes dead (is locked, read-only, can't interact with or edit). For example, player can't place a maneuver node player can't edit an existing maneuver node player can't toggle maneuver node between expanded/collapsed appearance player can't delete a maneuver node There's no reason why a player shouldn't be able to do all of those things while paused. Everything else in the game allows paused interaction-- for example, I can switch back and forth between map and flight view, I can look at the properties of parts, I can toggle settings on parts, etc. Note that, since getting maneuver nodes set up juuuust right is a fiddly process that can be time-consuming, this is actually one of the most important things to be able to do when paused. "Pause the game, do maneuver node tinkering, now go" is a thing a player should be able to do. (What makes it especially bad right now is that not only does the UI not work, but there's no visual indication that it's deactivated-- it looks as though it should work, it's just that nothing happens when you click on it. This is of especial concern to new users who may not be familiar with the UI, whose instinct is going to be "this is hard, better pause the game while I figure it out" and the confusion results because they can't tell what they're supposed to be able to click on.)

Details below, but short answer boils down to "make it work like it did in KSP1", or something pretty close to that. Right now, what the ESC key does is: Toggles the display of the game menu, regardless of context Does not pause the game, if in flight view What I contend it should do, instead: If any dismissable UI (other than the game menu) is present: Dismisses the UI. In the editor: If a part has been picked but not yet attached to a craft, cancels the action (i.e. it winks out of existence) If the game menu is currently displayed: Dismisses the game menu. If in flight view, returns the game to whatever time warp setting it was before. If none of the above is the case: Pops up the game menu, and, if in flight view, pauses the game if it wasn't already paused. Because right now, the current behavior causes several confusing and undesired behaviors that keep tripping me up: If the part info window is open and I want to dismiss it... the ESC key is how I want to do that. Instead, it pops up the game menu, which I don't need-- I will never need to interact with that menu while I'm tinkering with the properties of a part. Right now, there's no way for me to dismiss the window without moving the mouse cursor up to the little X button in the corner, which is distracting and intrusive and requires me to move the mouse away from where I want it to be. If I'm in flight and want to check something out on the game menu... there is no circumstance in which I don't want the game paused while that menu is up. Right now I have to manually pause it and then bring up the menu. If I pick a part in the editor accidentally (or pick one and then change my mind), getting rid of the darn thing is a pain-- I have to use the DELETE key, which is on the wrong side of the keyboard (I have to move my left hand way over, since my right hand is occupied with the mouse). Picking a part is an action, and I want to cancel the action, and ESC is how one cancels things. The constant metaphor, here, is that "ESC is how you cancel actions" is an overwhelmingly common UI metaphor. It's how KSP1 worked, it's how just about every game (or other software, for that matter) works. It's intuitive and instinctive. KSP2 should adhere to that and use the ESC key as the general "cancel what I'm doing" key.

Basically just what the title says. Give us a slider in the game settings somewhere that lets us set the UI scale. Right now the controls are ginormous and take up a lot of real estate. That may be appropriate and necessary when running on a smaller monitor, in order for them to be readable, but on larger monitors it's off-puttingly oversized and wastes a lot of space.

[Flight UI / VAB] The staging icon for the parachute is extremely confusing, at least for me. My first launch, I spent many frustrating minutes trying to understand "why the heck is there no staging icon for my parachute!?!?!" Turns out it's right there, but the way they've drawn it-- with a stylized capsule under a poofy fat chute cartoon-- looks to me like an engine: The capsule is the engine bell, the chute is the mounting hardware. My eyeballs saw that icon and immediately went "yeah that's an engine" and skated right over it. Even now, when I look at it, my eye is drawn more to the capsule than the chute. If the icon is for a parachute, don't include stuff-that-isn't-a-parachute in the drawing. Make the icon look more obviously and definitely like a parachute-and-nothing-but. Get rid of the capsule, draw obvious shrouds, something like that. For example, I always found the KSP1 parachute icon very easily recognizable. For example, something like this: (please excuse my crappy "art" skills)

RIGHT NOW, MANY UI CONTROLS, INCLUDING ALL TOOLTIPS, ARE IN ALL CAPITAL LETTERS, LIKE THIS: MY SUGGESTION IS TO PUT THESE THINGS IN MIXED CASE, SUCH AS "Symmetry Mode" IN THIS EXAMPLE, AND RESERVE ALL-CAPITALS ONLY FOR THINGS THAT ACTUALLY NEED IT, SUCH AS SECTION HEADERS OR ACRONYMS. RATIONALE WHY I THINK THE CURRENT "ALL CAPS" APPROACH IS NOT OPTIMAL: UNPLEASANT. IT FEELS LIKE THE GAME IS YELLING AT ME. FOR EXAMPLE, IT'S KIND OF UNPLEASANT TO BE READING THIS TEXT NOW. LESS READABLE. Mixed case contains a mixture of tall and short characters, which gives the eye plenty of visual reference points. ALL CAPS IS A UNIFORM HEIGHT AND IS HARDER TO TAKE IN AT A GLANCE. OBSCURES MEANING. THERE ARE SOME THINGS THAT LEGITIMATELY SHOULD BE IN ALL CAPS, SUCH AS ACRONYMS LIKE SAS AND RCS. IN A MIXED CASE UI, THOSE APPROPRIATELY STAND OUT AND ARE EASY TO TAKE IN AT A GLANCE. BUT WHEN THEY'RE ACCOMPANIED BY ALL-CAPS TEXT THAT DOESN'T NEED TO BE, THEY BECOME DIFFICULT TO DECIPHER. CONVERSELY, WHEN I SEE SOMETHING LIKE "APP.BAR" IN ALL CAPS, MY BRAIN INSISTS ON TRYING TO MAKE ACRONYMS OUT OF IT AND CAUSES COGNITIVE DISSONANCE ALL THE TIME. WHEREAS IF IT SAID "App Bar", THAT WOULDN'T COME UP. If for some reason there's a legitimate desire by folks to have all caps in the UI... it would be nice to at least have this as a UI settings option somewhere, so that those of us that it causes real problems for would have some recourse.

The UI is full of tooltips like this one: When displaying tooltips, there are basically three options I can think of for displaying. KSP2 is currently using the third. Instant. When the mouse goes over the control, the tooltip instantly pops up, with full text Advantage: Instantly informative. Disadvantage: Distracting (too easy to trigger accidentally or unnecessarily). Delayed. When the mouse goes over the control, nothing happens at once. But if the mouse hovers there for some timer period, then the tooltip pops up, with full text. Advantage: Unintrusive (doesn't show up unless you hover, which is typically an intentional act). Disadvantage: Slow (if the user wants the info, forces them to wait for it) Swipe-animated. When the mouse goes over the control, instantly pop up a blank tooltip with no text. Then the text gradually animates into place, "swiping" from left, like low-baud-rate text coming over a modem or something. (This is what KSP2 is doing now.) Advantage: None Disadvantage: Manages to be both distracting and slow. Triggers instantly and distractingly every time, even if you didn't need the tip... but once it does trigger, forces you to wait for the content while it swipes. Also, maybe this is just me, but the motion and animation is absolutely maddening and jarring-- it's injecting flashy motion into a scene that's otherwise fairly static, and it drags my eye away from the important stuff on the screen. It's a really cute idea, and I'm sure it sounded great on paper, and it certainly is "stylish". However, in practical terms, these animated tooltips are driving me absolutely batty. The animation serves no useful purpose, and gives them the worst of both worlds. My suggestion is, pick either the "instant" or the "delayed" model, and go with that. My personal preference is for the "delayed" model, since that's how tooltips work for virtually every UI I've ever used, and for good reason. However, even though I would like "instant" a lot less than "delayed", it would still be infinitely better than the current animated behavior, which I find a distracting nuisance.

There are buttons in the UI that don't say what their hotkeys are. For example, in the VAB, what key do I press to toggle symmetry modes? I have no idea. If I hover over the symmetry button, it just says "SYMMETRY MODE". That tells me what the UI button does, but it doesn't tell me what UI key I could press to do the same thing. What's the hotkey? I use that as an example, but this is a general comment that should be followed consistently across the UI. If a button's important enough to have a tooltip, it's probably important enough to have a hotkey, and that hotkey needs to be surfaced. How to fix: Show the hotkey in the UI tooltip. For suppose that R were the hotkey (it isn't, but I haven't been able to figure out what it actually is), it could say "SYMMETRY MODE (R)" or something like that. Without this feature, it's extremely difficult to discover what all the hotkeys are from the UI. (And if the answer is "um, there actually isn't any hotkey for that"-- surely not!-- then this suggestion becomes "you really need to add hotkeys for things.")

Strength of reaction wheels is displayed in kilonewtons, "kN". That's not a torque, that's a force-- these are completely meaningless numbers. The units of torque are force times distance, such as "meter newtons".

Some content has been redacted and/or removed. Folks, a gentle reminder to please don't make things personal. Personal remarks are never okay. It's fine to address a person's points, but please steer clear of addressing the person themselves (such as your opinion about their behavior or attitude). It never ends well. In other words, please address the post, not the poster. Thank you for your understanding.

Thread temporarily locked, pending resolution of remaining issues.

Hello @kramken, and welcome to the forums! We're glad to see that you're looking to contribute to the KSP modding community. However, there are some rules-related issues to sort out, so for the time being we've removed your download link. We'll contact you about the issues and see if we can help you get things sorted out. Welcome aboard!

Yes, notably @Nertea , of "Near Future" fame. (Perhaps others, but that's the one I remember seeing most recently and was very excited about. If Nertea's doing parts, they're gonna be purty.)

It's real.

Y'know, I was thinking about all the really excellent discussions people have been having about the new navball (really excellent photoshopping here, by the way!), and realizing that different people like different things, and then was thinking about this comment I made yesterday, ...and was just now reminded about a comment from Nate Simpson way back in 2019, when I had a chance to interview him: There's been a lot of water under the bridge since then, and who knows what they've actually had the time and budget to do, so I'm not exactly going to take that to the bank. But at least it shows that they were thinking about it, even then, and that their hearts are in the right place, which I find encouraging. Guess we'll find out soon.

Fingers on the suit gloves! No more mittens!

I've been trained so hard on KSP1's navball, from looking at it for thousands of hours, that I expect I'd probably have a knee-jerk negative reaction to anything that looks different from it, at least at first. Will take a few hours of playing for me to get used to it and find out whether I like it or not. (I look forward to seeing what modders do to offer alternate navball styling. Betcha that's gonna be a hot topic.)

They just announced.

Well, there's this:

Thank you! Got a link to the mod? (i.e. its forum thread)

No idea. I'd need to know what mod you're talking about, first-- do you have a link to its KSP forum page? Also, I'm having issues getting to the images you've posted-- could you try posting them to some other hosting site, such as imgur.com for example? Also, "does not work" isn't a super helpful description; would be nice to have some more details.

Oh, sure. It would be a design time decision in the VAB. It's already implemented that way in KSP1.

Those are the same two things. Saying "these two parts are joined by explosive bolts", in game terms, is literally exactly the same thing as saying the part you're attaching, is attached with explosive bolts. " Which KSP1 already has. It's a piece of functionality that is implemented by a piece of code called ModuleDecouple. If you put that functionality on a part, then the part has the ability to explosively decouple from the part it's attached to. It just happens to be the case, in KSP1, that only the "decoupler" parts have that module on them, which is why they're the only ones that can decouple. So, the way to add that feature to other parts is just to add ModuleDecouple to them via config. Of course, we don't know yet how KSP2 will imllent things, exactly, but if I had to guess, I'd guess that part module's will work at least somewhat similarly to how they work in KSP1. It just seems like too useful a programming model not to leverage. Guess we'll find out pretty soon.

Fair 'nuff. However, it's worth noting that not all mods are alike in terms of how much "load" they put on your system. A mod like this would be a very lightweight one. Mods that add a ton of parts and textures and such? Those are expensive.

FWIW, this would be a pretty easy functionality to mod into the game-- for example, in KSP1 terms, could just use ModuleManager to add ModuleDecouple to whatever parts are desired. It wouldn't even need any code, just a ModuleManager config patch. (Though the UI implementation could get a little cleaner with a small amount of code added.) Essentially what the OP is asking for is literally identical to saying "I want every part to be a decoupler, rather than having decouplers as separate parts." (If it was implemented in the game, that's literally, exactly what the functionality would be. Your description is identical to what the decoupler parts already do right now. The sole difference between the existing decouplers and what you're asking for is that the decoupling function would be built into the part itself.) Personally, I tend to side with @Kerbart on this one, as a matter of gameplay design-- his post above is exactly how my own thoughts ran. I don't like the idea of "every part has everything-and-the-kitchen-sink functionality built into it". I like having limited designs per-part, as part of the design challenge. Bear in mind that you're dealing with a tiny sample of people responding, so please don't be discouraged. The microscopically tiny number of people who have answered here thus far is not big enough to be any sort of representative sample of players. I'd also add that even though this idea isn't my personal cup of tea... I certainly wouldn't call it a bad idea. Different people like different things, and I'm glad you raised the topic for folks to consider. (And the good news, as I mention above, is that if this is functionality that you like, it would be really easy for someone to write a mod to do this. So absolutely hang on to the idea, and if KSP2 doesn't do it, raise the topic in Add-on Discussions and I wouldn't be surprised if someone doesn't take you up on it and just goes ahead and writes the mod.)