Search the Community

Flight ui is displaying when first opening save after booting up the game. The opening menu is not visible.

UI elements being pixel art / sprites is ok, but only if you scale them using the correct scaling algo's. You can't use the same algo's as you do for non-pixel art or it makes the elements blurry. Typically for Pixel you want to use Nearest Neighbor scaling methods, it's clear that right now the UI doesn't and it makes several elements fuzzy and hard to see.

After bailing from a vessel, recovering the kerbal, and reverting to vab soft locks on the confirmation screen but the game doesn't crash.

KSP Version : 0.1.0.0.20892 Operating System and version : Windows 11, 22H2 version, build 22621.1265 CPU and GPU models : I5 12400F, 3060 Ti FE Description of the bug : the ToggleFlightUI key (changed for F1 in my game) doesn't work at the launch, I must reassign on the same key in settings to make it work Expected Behavior : the key should work and hide the hud Observed Behavior : the key don't work and don't hide the HUD, until the reassign Steps to Replicate : just launch the game, éventually with a custom assign (F1) if the problem don't appears with the default assign Fixes / Workarounds (if known..) : workaround is "reassign the key" A list of ALL mods. If the list is long, please consider using a spoiler window : actually Space Warp and Custom Flags, but the problem existed before their install Other Notes / Screenshots / Log Files (if possible..) : nope.

There are currently clearly much bigger and more important problems than those related to the UI (mainly performance & physics) but I still want to take the opportunity to share here my current issues with the flight UI. This is no stylistic overhaul suggestion (since I have my doubts that the developers will consider significant art style changes in the near future) but rather smaller things which are relatively easy to fix. A lot of the UI elements are not properly aligned: most elements have a margin to the screen edge (and it is also inconsistent) while some elements are put right at the border of the screen. Either stick everything to the screen edge or give every element a consistent marign. Also especially in the lower right corner there are a lot of unaligned elements which is quite unpleasant to the eye. See the following screenshot with added guidelines and colored margins: Addionally, the stage button is bit big in my opinion. Why not take some space of it to integrate that arrow button? The time warp and game view panels in the lower center are too cramped considering they are shown in two distinct panels. Add a small margin in between. The deltaV readout for the individual stages is too close to the stage number. Seperate them better by adding the unit and amybe also a small divider. As often criticized, the new navigational instruments take up a lot of screen space. Especially the new SAS controls panel is just unnecessarily large. If the devs don't want to take the KSP1 route with semi transparent buttons, I suggest a smaller bar with the most important buttons (lock, prograde, retrograde, maybe also maneuver node) while all the other rather rarely used buttons are hidden in a drawer only shown when the mouse hovers over the panel. (But of course it should also be able to be pinned and kept open). In addition to the most prominent buttons mentioned the main bar should also show the last used button from the extended list. With that, the current SAS direction is always visible and it's easy to quickly toggle between the main directions and one additional dynamic direction. The navball is also quite massive. Two things I suggest here: Remove the heading tape. It's unnecessary because you already get that information by the navball itself. (It is basically a 2D tape.) Use that new free space for other stuff which allows my second suggestion: Push the orbital info panel a bit into the navball panel to save even more space. Also it would be cool if users are allowed to reposition all elements freely to their liking. The following screen shows how I imagine the screen to look like if all these things are integrated

We need to have a talk. I understand the artistic choice of having the game world be realistically depicted while the UI is representative of Kerbal technology with ASCII art and pixelated graphics and icons. I like the idea. But some of the graphics are too pixelated. Just look at the icons in map view. It hurts the eyes.

At this point most of us have probably seen the Early Access trailer - including the part where @Nate Simpson showed off the new UI and talked about the tape indicator concept. Overall, it's great that Intercept is looking to real-world systems for design inspiration, but I feel like certain elements of their current UI are a bit lacking in terms of readability and usability (and in fact, could be improved by leaning even harder into modern real-world flight UIs). I thought this thread would be good to summarize some of the comments from the announcement thread and share my own thoughts, including the good parts of the new design! Readability of atmospheric indicator This one was brought up by @poopslayer78, who commented that "the rocket is very tall compared to each atmosphere layer indicator, which makes it ambiguous where layer you're in." You can see the current implementation below: The devs are already working to improve this, which is sweet. Previous concepts below for posterity: It would be nice as well if there was an indicator LED or symbol w/ text to say "You are in space now! No need to worry about drag!" like poopslayer mentioned in their comment, since the topmost box of this UI suggests that there is still some atmosphere with the pale blue dots. Alternatively, KSP1's atmosphere indicator did a great job of indicating that you were in space since the last region of the indicator had no colouring at all: Visualizing the relative depth of the different atmospheric layers as shown in a previous concept would be very cool, particularly if this could change for different celestial bodies. If not, then sticking with equal size boxes as shown is fine. Readability of navball This one was mentioned by @t_v, who pointed out that " the amount of lines and markers on the navball makes it hard to really distinguish specific pitch angles, and the text on the rest of the UI fades into the information surrounding it". I partly agree with this comment, because some views look quite readable for precision orientation (kind of like the KSP1 navball, see first image below), whereas others are definitely hard to read with a combination of dithering at the edges, pixelated numbers, and low contrast secondary numbers (see 2nd image): Nate said that this has already become more legible in a newer build, which is great. The markers shown in the image are different from the KSP1-style normal and radial indicators, but that is most likely because they switch to a KSP1 style in orbit mode. Obsolete criticism below for posterity: Overly "retro" aesthetic of the UI This is perhaps the most subjective opinion, but it's one that I share. @The Aziz said in a post "the pixely font and icons just don't work for a civilization that is about to hit interstellar space. Instead, we landed in the late 90's." I think the dithering and font choice for UI elements is a big part of this, since it causes what would otherwise be a very modern interface to look rather busy, hard to read, and outdated. A bit strange for a society operating advanced jets and (eventually) interstellar technology that is decades or centuries ahead of 2022 humanity. They highlighted these SpaceX UIs which look exactly as modern as you'd expect a flight control interface to be in the 2020s: You can see that SpaceX uses a smooth gradient shadow to indicate the 3D-ness of the navball, without any dithering or pixelation to be seen anywhere I actually don't think the SpaceX navball is a perfect fit for players who will be flying their crafts manually, so having more numbers like the current KSP2 concept and KSP1 is better than having fewer numbers and markings like the older concept below (and maybe like SpaceX too): Personally, I think that something like the real world HUD below would be ideal as a working UI that is in the same style as what we have seen in the past: Everything is easy to read at a glance, highly legible, and uses high-contrast text and colours (even in this photo, which reduced some of the contrast). It also uses the "tape indicators" that the current UI does, so good job devs on implementing them The main area where we could diverge is adding a smooth (non-dithered) gradient to the navball as shown in one of the team's earlier concepts, since we will make more dramatic attitude adjustments than most airliners Summary of likes and dislikes with the new UI Since we were kindly asked to share things we like as well as what we don't like (thank you Fernanda), here is a list of what I think the new UI does well compared to previous concepts: Great stuff The rolling tape indicators are a great way to show critical altitude, speed, and heading information at a glance, and having the indicators scroll based on rate of change will be super cool and engaging. The button outlines on the altitude and speed tapes make it more obvious that you can change between different modes, compared to the older concept I showed above. The mission time is super legible compared to a previous UI concept, and the button makes it obvious that you can switch between MET and UT. Having UI section "titles" like SAS.CONTROL and TIME.WARP = 1.0X will be useful for new and returning players alike The throttle indicator suggests to players that you can adjust your throttle smoothly (including by dragging the handle), which is great for people who may have thought that you can only adjust it in 5% increments or what-have-you. Putting a separate and legible rate of descent indicator right next to the navball is genius, and will probably help a lot of people to not slam into the ground (accidentally, anyway). Hopefully the warning and danger zones update based on local gravity and the strength of your landing gear. The numbers on the pop-out tape indicators are easier to read than the 8 segment style digits of the previous UI and the pixelated numbers of other parts of the current UI. The amount of interval markers on the navball makes it easier to burn at a specific angle and heading compared to a previous UI concept and kind of like the KSP1 navball. The navball will be movable to the centre of the screen to match KSP1's position (source: ShadowZone's October UI video). The radial/anti-radial and normal/anti-normal markers are replaced with North/South and up/down (?) markers when the navball is in surface mode, which is cool and useful (source). At a glance apoapsis and periapsis info is presented well. The map view shows spheres of influence for celestial bodies and more readable icons for when you get in them, which is awesome! (source1, source2) The staging diagram is on the same side of the screen in both the VAB and in flight. The GO button is solid green! And a summary of what was said in the sections above, with some additions: Areas for improvement The previous concept (shown under the aesthetic section) had a very tasteful and legible style of dithering, probably because dithering wasn't used for any elements that were intended to be read. If the team would like to stick with dithering instead of smooth shading, that is probably the way to go. Units should follow SI capitalization consistently to avoid confusion (ex. lowercase "m" for meters", "km" for kilometers, "Mm" for megameters (millions of meters), etc.) - thanks shimmy00! The text on the tapes themselves is a bit hard to read because of the pixelated font. The text in the UI section titles is hard to read because of the pixelated font combined with its small size (the size would be fine if it was used with a normal minimal-serif font). The atmospheric indicator doesn't show neither exactly where a craft is in the atmosphere (KSP1 style) nor the relative depth of the atmospheric layers (older KSP2 concept style) - precision improvements in development The atmospheric indicator implies that a craft is still experiencing partial drag even when it is at its darkest colour due to the chosen dithering. The hinting of where other orientation markers were in a previous UI was very cool (appropriately futuristic) and useful, and that is missing from the latest UI. The removal of normal/anti-normal and radial/anti-radial markers is a step back in terms of rocketry education and general legibility KSP1-style markers are still there in orbit mode! The current navball is hard to read wherever dithering and pixelated numbers interact with attitude lines and oblique view angles (ex. flying straight up from the surface) - more legible in a newer build Having pitch/attitude marks and labels only on the cardinal heading lines like KSP1 would make the overall navball more clear. Because of the dithering on the RCS and SAS buttons, it is not obvious that they are enabled if they are both on. Subjectively, everything pixelated and dithered in the current UI looks too outdated for the level of polish the rest of the game will have. The fuel and oxidiser gauges for engines could get out of hand for a lot of engines (think Soviet N1 level), but hopefully the engine group button lets us collapse all the individual fuel gages into one overall, representative gage. The stage number on the GO button is harder to read compared to a previous UI due to the choice of font and the green on black colour choice. Overall, I know that we're commenting on "pre-alpha" footage and that things could have already changed, but since we're approaching early access, I think its better to get this feedback out now so that we can ensure the best possible reviews at KSP2's EA launch . Thread updated with some of @ShadowZone 's info from his comprehensive summary video, which you should definitely check out!

BetterUI hehe big text I am attempting to build a mod that makes the KSP UI look less... old. I am looking to do something like this: This is a part of my series of mods to make KSP better. Uhh lets see... intro, based off... Ah! Heres the repo that has nothing in it: https://github.com/staticalliam7/BetterUI/ I'll add stuff to the OP as we go

So this is a mod by u/Rattraps123 from reddit He was trying to finish this when he was not able to load it on ksp 1.11 so the download will not be provided and the provided ones are the broken version, so I asked him to take over his mod I am consulting linuxgurugamer for help, but the reddit discussion thread

When I control a craft I'm seldom interested in the "Display Staging" info (lower left). I want to see the "Maneuver Mode" view, with info about apsides, inclination etc. Similarly, I'm most comfortable with UT rather than MET "Time Mode" (upper left). It's getting very old having to toggle these views Every. Single. Time. I switch between craft. Is there some way to make these settings stick? (I'm no stranger to manually editing files if that's what it takes.) (I have an annotated screenshot that shows what I'm talking about, but there doesn't seem to be any way to attach an image to a post? Just "Insert image from URL"?)

I for the longest time have wanted a mod that changes the look of the Vanilla UI, especially more so now with KSP2 coming and the devs sharing more footage, like the VAB screen. The only problem is that I can't find any mods that change the look of the UI. I've only seen like two posts on the idea, both of them being from people playing around with the idea but never full on making a UI mod. If I knew anything about modding I would make one myself, but considering the fact that no one has made any UI mod, I assume it must be pretty tricky. I don't really know the point of this post, I guess its just to get the mod idea out there and hopefully a modder is inspired by this to make one, or maybe someone can point me in the right direction for making such a mod. Anyways that was my tedtalk, I hope somebody sees this and considers the idea and/or people can discuss it in the replies. <3 Here's one good HUD redesign that I was informed of, I guess it can be used as inspo or help feed a discussion here

Its very weird but UI is complety borked and its not even listed on ksp.log. Its is just so out of shape. I think issue may be because i updated mod while in game but yea the ui was destroyed. Heres issue: Sometimes Ui will not even exists or be even more broken. This is just in flight

Image of the UI When an engine malfunctions due to Kerbalism, mechjeb Ascent Guidance seems to bug out and the only way to disengage it would be to let it continue running until complete. This is a strange bug and doesn't happen all the time, and thankfully it hasn't been a catosrophic bug for my space agency. However, this isn't the first time one of these UI things have bugged out for me. During a RP-1/RO career playthrough, the Ferram Aerospace Research UI would be broken 9 times out of ten, in a similar way to the way the Mechjeb UI looks. All the buttons dissapear. Anyone know what might be causing this? It can be very annoying sometimes (and like I said, it's not happening all the time). Cheers everyone! EDIT: I'm playing on 1.11.2, all the mods are updated to the most recent releases

I've been following the UI Creation Tutorial here on the forum and I'm stuck on the "Exporting the Asset Bundle" section. I really do not understand what they are talking about. Are there any video tutorials for this? I'm a very visual learner and this section literally makes no sense to me. I do not know where the Asset Compiler Window is, I do not know what they mean by prefabs, and I don't have any clue what they mean by the second bullet point. Any help is appreciated, please help!

The almost surely closely related issues (which always occur around the same time)are: 1. Celestial bodies vanish in map and Tracking Station 2. Either only the skybox and the foreground UI is visible in the KSC screen, or the ground is entirely black, the Sun and the Mun is invisible ,there is no spreaded light in daytime and the buildings are shown as holes in the ground through which the skybox is visible. 3. Crafts are invisible, whith the exception of highlights. 4. The game sometimes crash when launching a new craft. When this happens, I constantly get the debug report "Screen position out of view frustrum (screen pos (number 0-1920), (number 0-1080)) (Camera rect 0, 0, 1920, 1080) Mods: -Kerbal Reusability Expansion -Kerbal Alarm Clock -All mods in the KSPI-E modpack Log: Initialize engine version: 2017.1.3p1 (02d73f71d3bd) GfxDevice: creating device client; threaded=1 Direct3D: Version: Direct3D 9.0c [aticfx64.dll 26.20.11008.3003] Renderer: AMD Radeon(TM) Vega 8 Graphics Vendor: ATI VRAM: 1008 MB (via DXGI) Caps: Shader=30 DepthRT=1 NativeDepth=1 NativeShadow=1 DF16=1 INTZ=1 NULL=1 RESZ=1 SlowINTZ=1 ATOC=0 BC4=1 BC5=1 Begin MonoManager ReloadAssembly Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\UnityEngine.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\UnityEngine.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\I18N.dll (this message is harmless) Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\I18N.West.dll (this message is harmless) Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\Assembly-CSharp-firstpass.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\Assembly-CSharp-firstpass.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\Assembly-CSharp.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\Assembly-CSharp.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\Assembly-UnityScript-firstpass.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\Assembly-UnityScript-firstpass.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\Assembly-UnityScript.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\Assembly-UnityScript.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\UnityEngine.UI.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\UnityEngine.UI.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\UnityEngine.Networking.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\UnityEngine.Networking.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\UnityEngine.Timeline.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\UnityEngine.Timeline.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\UnityEngine.Analytics.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\UnityEngine.Analytics.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\Mono.Cecil.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\Mono.Cecil.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\Ionic.Zip.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\Ionic.Zip.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\I18N.CJK.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\I18N.CJK.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\I18N.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\I18N.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\I18N.MidEast.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\I18N.MidEast.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\I18N.Other.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\I18N.Other.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\I18N.Rare.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\I18N.Rare.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\I18N.West.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\I18N.West.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\KSPAssets.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\KSPAssets.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\TDx.TDxInput.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\TDx.TDxInput.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\KSPTrackIR.dll (this message is harmless) Loading C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\KSPTrackIR.dll into Unity Child Domain Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\System.dll (this message is harmless) Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\System.Core.dll (this message is harmless) - Completed reload, in 0.811 seconds Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\Boo.Lang.dll (this message is harmless) Platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\System.Xml.dll (this message is harmless) <RI> Initializing input. XInput1_3.dll not found. Trying XInput9_1_0.dll instead... <RI> Input initialized. <RI> Initialized touch support.

SafeBrakes 1.1.6 Save your airbrakes on reentry. FEATURES You can activate the brakes by pressing the modifier key and brakes simultaneously (alt+b by default on Windows). When activated, the anti lock system (ABS) temporarily deactivates the brakes to avoid drifting and crashing onto the runway during landing. The anti-overheat system (SAB) deactivates the brakes to prevent the airbrakes from overheating and reactivates them when they are cooled down. INSTALLATION Download the mod from Spacedock, GitHub or CKAN CHANGELOG Mod licensed under a Creative Commons Attribution 4.0 International License.

Hello, sorry in advance. I know maybe is a stupid question but someone know where this info comes from? I have a bunch of Mods so I can't differentiate if it's from a mod or from the original game. The thing is I don't know how I activate this (if is not a bug) and I want to hide it. Thanks & regards!

Disclaimer: Hey devs, don't take this as criticism. I know how regular people usually are clueless about how complex things are beyond the surface of a development process... This is just for fun, peace ✌️ Hello folks! I work as a full-time UI/UX designer, and something that grinds my gears is how a super complex game as Kerbal Space Program lacks a good interaction design foundation in some parts. I'm always worried about how hard is the learning curve for newbies... To understand how basic things work. So, I decided to give a little bit of love back to the community by doing some design experiments. I hope this gets people inspired somehow. --- Experiment on a possible Tweakables Redesign 1. Analysis Ok, so this tweakable popover looks too complex for a basic part. I start by analyzing the content, trying to understand the patterns behind. I added a color-coded interpretation on how most of the content relationship, so I could compare with other screens. Using Advanced Tweakables sounds unfair, so let's get it going without it. I will miss you Autostrut. The screens stills look complex, with a loose relationship between the content. The main thing that draws my attention are: Lack of order and relationship Inconsistent readouts Different kind of controls look like the same button Parameters (input) and Resources (output) looks too similar "#" have a loose mapping to the Parameters input "Crew report" generates science, but it doesn't stand out from secondary stuff. This is a "cold" analysis that I'm doing without a proper user research process. To do it for real, the right way would be doing some usability tests and card sorting with real people. If you are short on time, the best way to start studying a user interface is by these two points of views: 10 Usability Heuristics for User Interface Design https://www.nngroup.com/articles/ten-usability-heuristics/ Understanding mental and conceptual models in product design https://uxdesign.cc/understanding-mental-and-conceptual-models-in-product-design-7d69de3cae26 Alright, let's see what else I can collect... Comparing some basic tweakables side-by-side opened my mind that the "real" problem in the pods is how they fail to communicate the different modules bundled in a single part. Most of the smaller tweakables are pretty straightforward to understand, even with some features that feels they slipped through Advanced Tweakables and ended in the stock mode. This a non-extensive list of the inputs/outputs, so I can have a clear picture of the main UI patterns. 2. Process I decided to use the Mk1-3 Command Pod as a reference. It's fairly complex and it covers a god range input/outputs. I start from a basic wireframe (to focus on the content) and then move my way up adding more structure... In the end, I decided to not use the "collapsible category" idea because of the amount of visual noise it introduced and rollbacked some of the ideas because the original ones seem better. 3. Result This looks like the first steps of a draft for a UI library. It was way harder than I expected to give proper feedback/affordability to the buttons. The main idea is that the user can figure it out what kind of button it is before clicking it. What do you think? My favorite parts are the science indicator and divisors Source file: https://www.figma.com/file/09xWDTa5XQJy140q7sCyPX/Kerbak-–-Tweakables-Redesign?node-id=0%3A1

Disclaimer: I am not an expert on this, the following is just what I have discovered. Some of this information is deduced based on empirical observation of KSP / Unity behavior. There's only fragmented info out there re: how to set up UI textures. Hopefully by organizing this information together will help put an end to blurry fuzzy UI woes and nasty hacky workarounds. Plugin authors: This will hopefully explain why your buttons/icons/etc are a horrible mess and what you should do to avoid it. Part modders: This does not really affect textures you use in models, but may be informative. (Side note: if you aren't already using DDS with mipmaps, you should be doing so.) Players: This is probably too technical. If you want to fix blurry UI in mods that you are using, see instructions here. So I finally needed to make a mod with toolbar button and ran into the issue where the icon gets all blurry when graphics settings are at less than full resolution textures. Within the modding community I found that: - some modders not aware or haven't address the issue (e.g. low priority, haven't figured out what to do) - blame placed on Unity and it's texture compression (loosely true but not strictly correct) - some workarounds involving DIY reading texture directly from file, ignoring the version in GameDatabase --- file i/o overhead, yucks - some workarounds using textures that are larger than they need to be The crux of the problem isn't actually compression per se, it's mipmaps. If you don't know what they are, you might want to google and read up more, but the short explanation is: mipmaps are just a bunch of smaller copies of the texture which can be used on-the-fly depending on the size required, rather than having to do expensive calculations to get a scaled version from the original at runtime. This is great for model textures, so if you're looking at a capsule in game at close range it would be textured using a high res (or fullres) version of the texture but if it is zoomed out and far away then a lower res mipmap can be used. (See explanation by HebaruSan below.) Depending on what format texture files you're using and how they get loaded, they may already contain mipmaps in the file, or mipmaps may be generated for them during loading. And the problem is, if you have small textures for UI purposes e.g. icons, buttons, you've probably already made it at appropriate size and want it to be used at crisp full res all the time. You do not want any of that fancy mipmap stuff. When a texture has mipmaps, and the Texture Resolution option KSP's graphics settings are set to anything less than full resolution, then the following happens: - At half res, only mipmap level 1 (halved width and height) and smaller is uploaded to GPU <-- "factory default" - At quarter res, only mipmap level 2 onwards is uploaded - At eighth res, only level 3 onwards is available This means that your appropriately-sized, original full res version of the texture (mipmap level 0) simply gets thrown away, so when your UI element is displayed it is forced to use a too-small version of the texture and scale it up. What KSP / Unity does when loading textures Textures are loaded from file into Unity Texture2D object. All of the textures are kept in the GameDatabase along with some metadata in the form of GameDatabase.TextureInfo object. TextureInfo attributes: name: This is the "url" used to lookup a texture when you call GameDatabase.Instance.GetTexture() basically the path of the file relative to GameData folder, minus file extension file: Internal UrlDir.UrlFile format for storing path information texture: The Texture2D object with the texture in it isNormal: whether the texture is a normal map. Note that this can change at runtime. So if you have a texture that isn't a normal map, and then call GetTexture() with asNormalMap true it will (try to) convert the existing texture to normal map, and isNormal flag will be changed to reflect this isReadable: a Texture2D can be set to be "no longer readable" which according to Unity documentation means "memory will be freed after uploading to GPU" and texture cannot be manipulated (e.g. edit the pixels) from CPU side. this flag is supposed to reflect that. isCompressed: whether the texture has been compressed during the loading process. Unity documentation: "Compressed textures use less graphics memory and are faster to render. After compression, texture will be in DXT1 format if the original texture had no alpha channel, and in DXT5 format if it had alpha channel." This flag may be incorrect, it appears to be set as long as there was an attempt to compress the texture with Texture2D.Compress(). But that process can fail, and is usually seen in KSP.log when it complains such as "Texture resolution is not valid for compression: <filename> - consider changing the image's width and height to enable compression" This gives us some insights into the texture loading process. What KSP does when loading each texture depends on the file format, but the general steps include: - read the texture data from file - convert image format (if needed) - (optional) try to compress to DXT - (optional) generate mipmaps - upload to GPU -- behavior depends on Texture Resolution setting, more on this later - (optional) make texture no longer readable (discard from RAM) We can learn more about how different texture file types are handled by observing what happens to them. Below is a partial list of textures info dumped from a stock 1.7.0 install just after GameDatabase finished loading in LOADING scene. I've trimmed it down from the full set. First three letters NRC reflect the three boolean flags. The fourth C shows whether the texture itself is actually DXT format. This is followed by image dimensions, mipmapCount (1 if none) and TextureFormat, then the name of the texture. The source code that dumped this info can be found here, it is part of the unBlur mod. If you install unBlur you can use it replicate the above as well as investigate what KSP is doing to your textures. It provides access to its functionality via a console command in the Alt+F12 debug console so you can inspect individual texture info, disable mipmaps for textures, and dump the full list of textures from GameDatabase. It is also possible to have unBlur dump the state of textures from GameDatabase immediately after loading, while in the loading screen, by turning on verbose debug mode. For details, consult the unBlur forum thread. How the texture resolution setting affects texture loading The texture resolution option in KSP's graphics settings actually control a Unity setting called QualitySettings.masterTextureLimit. The setting is stored in settings.cfg as TEXTURE_QUALITY with 0 = full res, 1 = half res, ... 3 = eighth res. As described earlier, masterTextureLimit prevents the n highest resolution mipmap(s) from being uploaded to the GPU. Per Unity docs, "This can be used to decrease video memory requirements on low-end computers." However, if a texture does not have mipmaps, then the full texture must of course be used. Once the texture has been upload to the GPU, that's the copy we have to work with. If the texture resolution setting was at eighth res when starting the game, that's the quality that you are stuck with -- changing the setting at run time does not appear to have any effect -- because only a lower res version is available in the GPU, and in general because the texture was made no longer readable by CPU side after loading, even if you turn the quality back up to full res, the full res texture data is not available anymore without actually reloading from file again. In cases where the texture is still readable and in RAM, plugins can access the full res version of the texture from there. (This is how unBlur fixes blurry png textures.) How various file formats are handled Based on observations from GameDatabase TextureInfo dumps, including both stock and modded. *.dds These files are already in the compressed format preferred internally. Loading them is fast, because the data is loaded as-is and no conversion is needed. Being compressed, they use less graphics memory and are faster to render. - Loaded format: as per file, i.e. DXT1 (no alpha) or DXT5 (with alpha) - already compressed - mipmaps: as per file - not kept readable *.mbm Old KSP propietary format, very few instances left. - Loaded format: DXT - compressed - mipmaps: yes - kept readable *.png Loading them is slow, because they have to be converted from RGBA32 and additional processing is done. They usually get compressed to DXT5 for upload to GPU, but are kept CPU-readable so also consume RAM. - Loaded format: usually DXT5 - will usually be compressed - mipmaps: may be generated <-- blame your blurry UI on this - kept readable Notes Some stock pngs avoid having mipmaps generated (e.g. Squad/Flags/*, Squad/PartList/SimpleIcons/*, Squad/Strategies/Icons/*) but others do (e.g. Squad/Props/IVANavBallNoBase/*) mechanism not well understood, perhaps hardcoded to identify certain directories (*/Flags/* maybe?) but not sure we can rely on this behavior A very small number of new normal maps (_NRM) for redesigned parts are *.png that store in GameDatabase as RGBA32, unreadable, uncompressed (despite isCompressed true), with mipmaps generated. Squad/Tutorials/YPRDiagram fails to compress, which reveals that pngs are loaded as ARGB32 before getting compressed to DXT mipmaps may still be generated even if compression fails, I have positively observed this (38x38 ARGB32 CommNetConstellation/Textures/cnclauncherbutton.png with mipmapCount of 6) *.truecolor Notably used for small (_scaled) versions of agency logos. Explanation here. Actually renamed *.png files, so loading needs to convert format from RGBA32. - Loaded format: ARGB32 - will not be compressed - mipmaps: will not be generated - not kept readable *.jpg Like png, these are comparatively slower to load. They are compressed to DXT1 since they don't have transparency, and kept CPU-readable after loading to GPU - Loaded format: DXT1 - compressed - mipmaps: will be generated - kept readable Why does it behave like that? If you provide a texture in DDS format, it is already in the format that is used by the GPU, so KSP/Unity takes the file as-is and treats it as what you intended -- so you can provide exactly what you want. If you are using a texture for models, you'd include mipmaps, and things would work great (because that's exactly the use-case they were designed for.) If you are using a texture for UI, you wouldn't generate mipmaps when saving the file, and KSP/Unity will just always use it at full-res (exactly as intended) The texture file is already in the correct format, already compressed, and has mipmaps if you want them. KSP/Unity presumes that everything is as you want it to be, and the texture will no longer be modified by code once loaded, and so discards its data from main memory after it has been loaded into graphics memory. For other formats, however, they need to be converted for use. Because the API doesn't provide a mechanism for us to attach any metadata to png/jpg/etc files to indicate to KSP/Unity what our intentions are and what the texture is for, I think the texture loader simply makes the assumption that whatever textures it loads are for models. So, in general, it will generate mipmaps from the full-res image, and after that it will attempt to compress the texture to DXT for better performance. But it keeps the texture's pixel-by-pixel data available in RAM, in case you might want to write some code that accesses/manipulates that. This is actually a reasonable default assumption, after all, most textures are going to be model textures. As for UI textures, pretty much most if not all of the UI in the stock game are built in Unity, prefabbed, and saved into assets, so that takes care of loading UI textures for the stock game. (Mods could do the same thing, but most of the time it's far too much trouble if all we need is some simple UI.) Anyway, this is the behavior in general for formats like png and jpg. It seems like KSP might have some code that handles special cases in the stock game's data like flag textures (Squad/Flags/*) and icons (Squad/PartList/SimpleIcons/*, Squad/Strategies/Icons/*) so that they don't get treated like model textures. Those cases can be hardcoded because they know about it in advance, but for modders I don't recommend we rely on that behavior. *.truecolor files are the special case, which seems to be added to handle agency logos. Agency logos in general are stored as DDS and are displayed in game at various medium-ish sizes, e.g. contracts window. However, for the part-picker in editor when sorted by manufacturer, it needs to be a small icon. Scaling down from the fullsize logo at runtime didn't work well visually, so smaller "*_scaled" version of the logos were specifically made. These were png files, but as above the texture loader would have generated mipmaps for them and cause blurriness. To deal with that, the files were named as *.truecolor instead and the texture loader instructed specifically to treat them differently, i.e don't generate mipmaps. How to proceed from here UI textures in your own mod Including toolbar button icons for stock AppLauncher or blizzy toolbar. If you are currently using *.png for icon/button graphics, the quick hotfix is to simply rename to *.truecolor. Besides not having mipmaps generated, the other benefit is that it will not be kept in RAM after uploading to GPU. The one downside compared to png is that it will no longer be compressed. Also, like png, it is still slower to load. For long term, if you can convert your files to *.dds without mipmaps would be most ideal: fast to load, compressed, not kept in RAM. If you are using the workaround of reading textures directly from file yourself Specifically the workaround offered here. Stop doing this if it is for textures in your own mod that you have control over. Rename/convert them instead, see above. By reading the file yourself and creating another texture, you incur file IO overheads and consume additional resources for the texture that you create, while the copy in GameDatabase continues to occupy both RAM and GPU. And if not implemented properly, you may be leaking memory. If you have to use the workaround because you have no control over the textures, i.e. they are passed to you by other mods. You can use unBlur, call unBlur to tell it to strip mipmaps from the texture in GameDatabase before you fetch and use it. If you are using the workaround of making textures larger than they need to be This workaround costs a disproportionate amount of disk space and loading time, don't use it. The way that this worked is as follows: Suppose you make a 64x64 image when you actually only need 32x32, this will work at half res settings because the 64x64 copy is thrown away but mipmap level 1 at 32x32 is still available. But at eighth res setting, only mipmap level 3 at 8x8 is available so it doesn't fully solve to problem. You would need to make full res at 256x256 in order for eighth res setting to still have a 32x32 copy. If you have programmatically created Texture2Ds in UI for other reasons Here are tips for best performance and results Make sure you use the constructor that lets you specify mimmap false. Use Compress() if possible. Works more consistently if you do this before making unreadable using Apply(). (ref) Once finished making modifications to the pixel data, call Apply(false, true) to upload to GPU and discard from RAM Make sure you dispose of the texture when done with it. For most monobehaviors (i.e. destroyed/recreated when changing scenes) you should do it in OnDestroy even if it is something you "hang on to", otherwise the texture will not be GC'd and you end up making another copy. Other ideas: you can have a singleton monobehavior with DontDestroyOnLoad that is responsible for hanging on to one copy of textures only. Or init once into a static field. UI textures that require mipmapping If you have UI textures that are larger, such as banners or backgrounds that need to be displayed at different sizes, then you might actually want mipmapping. But then, you'll need some way of getting around the texture quality settings causing the n highest-res mipmaps being discarded. If you find yourself in this situation, my suggestion is to use png format so that mipmaps will be automatically generated for you, but the texture is also kept readable in RAM. After the texture has been loaded into GameDatabase, you will need to fetch the texture -- which is missing first few mipmaps on GPU, but still has full-res data preserved in RAM -- and upload to GPU again, forcing it to include all mipmaps this time. This should be achievable by temporarily forcing QualitySettings.masterTextureLimit to 0, calling Apply(false, false) on the texture, and then restoring the masterTextureLimit when done. (unBlur will also provide such functionality in the future.) Non-UI, i.e. model textures You've probably heard this before, but for fastest loading and best performance you should really encode in dds with appropriate mipmap level.

It is not possible to scroll through long lists like before by simply hovering the cursor over a list and holding the right stick downwards to scroll down. Details: Platform -> Xbox Version -> Latest update 31/03/2019 without Making History DLC (I'd suggest that the version number be displayed in the main menu screen or the settings screen!) Control Preset -> Cursor or Radial Steps to reproduce: Have the active control preset as Cursor or Radial; Be in control of any vessel; Hover the cursor over the controls app (Top right of the screen, under resources, above contracts); Press A (X for PS4) over the controls app icon to toggle it; Move the cursor over the list that has popped showing all the controls mapping; Try scrolling down (unable!). Steps taken / workaround / notes: The Right Stick should be cursor dependent when Move Cursor is toggled on (by clicking the Left Stick) and the cursor is over a scrollable list, as opposed to control the camera; Now, the list is only scrollable when the "UI focus" is over the controls app icon (workaround): Be in control of a vessel and in Cursor/Radial control preset mode; Press Y (triangle for PS4) to open the Radial Action Menu; Select the "Select an App" action (3ºclock postion); Use the Left Stick to move down through the apps until the green square ("UI focus") is over the Controls app; Use the Right Stick to scroll down/up through the list. This is a workaround, but it adds a lot more unnecessary steps - compared to only having the cursor over the list as before and being able to scroll through. If using the Simplified control preset, you must hold Y (triangle) and move the UI focus over the controls app, very similar to the point above; I'm using the Controls list as an example of scrollable list here, but this problem will be present in every scrollable list, requiring that the Move Cursor is toggled off (click Left Stick) and that the list is the UI focus so that the Right Stick controls the list scroll as opposed to the camera.

While I play KSP, I sometimes listen to music,so , I have to leave the ksp windows to check chrome or others. When I do this, usually there is no problem but sometimes my UI(navball, toolbar, etc.) Changes in size to, I'd say, a half. I'm using KSP 1.6.1 and the following mods(all installed and updated by ckan): -AirplanePlus -Atmosphere Autopilot -Attitude adjuster -B9part Switch -B9 procedural wings modified -BDArmory Continued -BetterBurnTime -Better Crew Asignment -Click through blocker -CommNet antenas info -Community category kit and resource pack -Distant object enhancement and default config -Docking port aligment indicator -Draggable navball -Easy Vessel Switch -(non ckan)Editor extensions redux -EVA follower -ExtraPlanetaryLaunchpads -Feline Utility rovers -Filter extensions -Firespitter and core and resources config -Flag Pack -Hangar extender -Hyper edit -Interstellar fuel switch and core -Kerbal alarm clock -Kerbal engineer redux -Kerbal Inventory System -Kerbal NRAP -Kerbal Reusability Expansion -Kerbal-Konstructs -KerbalX mod -kOS -KXAPI -MechJeb2 and enginner for all -Mk2 Stockalike expansion -Module Manager -notes -Physics range extender -(non ckan)Plane mode v 1.4.5 (for 1.4.2) -RasterPropMonitor and Core -RCS build aid continued -Reentry particle effect -Scatterer and sunflare and default config -Stage recovery -The Janitor's closet -Toolbar controller -Trajectories -Tweak Scale -(non ckan) Vessel Mover All the non ckan install were downloaded from spacedock and github. I'm using windows 10 and installed via steam. I hope you can fix it for future versions or show a "tirck" to solve this. Thanks in advance.

I can not change the body in the new DeltaV tool in the VAB. When I try to open the body list by clicking on the Kerbin button or the arrow right next to it first after entering the VAB the list will show up for a split second but the tool will close immediately. When I click that button again (after reopening the DeltaV tool) the tool stays open, but the body list doesn't appear. KSP 1.6.1 (english) Windows 10 64bit Steam installation

I seem to recall that a long time ago, someone suggested a simplified part selection UI. The gist is that instead of having to pick from tens of different but similar-looking fuel tanks, you just pick any fuel tank, right click on it, pick the length and radial size, and the part changes accordingly. Kind of like tweakscale, but the part actually switches to another part instead of simply altering the size of part. It's also not procedural parts, because it uses the parts already in the game. Now that part variants are a thing, I think this is not too far off. It could be like that, but with size instead of color. This could really save some time when designing a rocket.

This is 1.4.4 related issue only, it never happened on 1.4.3 or any prior version. When I play and go to VAB or SPH, then press ESC instead of Quit button, the game shows the Save/Load/Settings/Quit menu on the screen, which is OK. Now, pressing ESC while the menu is displayed will hide the menu, but will not return the game to its normal state. Some controls are enabled, but quit doesn't work in SPH or VAB anymore, the right mouse click doesn't rotate, the Build/Actions/Crew assignment buttons are disabled, the Switch editor type does nothing, I can't pick any new parts, save the craft or do anything. Pressing ESC again does NOT bring the menu back, the game is locked, but it's not hanging. The highlight still works when moving mouse cursor over the craft, or any UI controls, but they just don't react. The only way I can quit the game is via ALT+F4 and/or Alt+Tab and Close. I tested it on plain vanilla 1.4.4, as well as modded one, and they behave the same. It never happened on 1.4.3 before, or any other prior version, and I played the game since 0.22 or something.

I set the UI Scale option to 150% in Settings > General when using a high screen resolution. Unfortunately scaling the UI does not seem to affect the UI of any of the mods, so all the mods are too small for me to read and use. I know some mods offer ways to scale the mod's UI, but I want to know if there is a way to scale the UI of all the mods. Or, if that is not possible if there is a way to do this on each mod that doesn't have a UI scale option. I hope there is a solution to this issue other than getting better glasses (or changing the resolution I run KSP in). I don't know if it is relevant, but I use a MacBook Pro (Retina, Mid 2012) with macOS 10.13.3 and KSP 1.2.2.