krbvax

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB The "Auto-hide Navball in Map View" user interface setting does not behave as the text suggests: the navball is hidden in map view when the setting is off and displayed when it is on, as if the intended name of the setting is actually "Display Navball in Map View". (The description shown when hovering over the item, "Show the Navball and its related instruments while in Map view", also suggests that the setting name was intended to be "Display" rather than "Auto-hide"). Severity: Medium Steps to reproduce: Open the User Interface category in the settings menu, and set " Auto-hide Navball in Map View" to "off". Launch a vehicle. Enter map view, and observe whether the navball is displayed. Open the settings menu, and change the " Auto-hide Navball in Map View" to "on". Close the settings menu, and observe whether the navball is displayed. Expected behavior: The navball is displayed in step 3 and hidden in step 5. Observed behavior: The navball is hidden in step 3 and displayed in step 5. Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB When executing a planned maneuver which causes the vehicle's path to enter another SOI, the burn timer's graph displays incorrectly, as though the burn is being executed in the wrong direction. Severity: Medium Steps to reproduce: Launch a new vehicle to Kerbin orbit. Create a maneuver which intercepts the Mun. Advance time to the beginning of the maneuver, and set the throttle to full. Observe the behavior of the graph in the burn timer as the burn progresses. Expected behavior: The burn graph decreases to empty (gray) as usual. Observed behavior: Partway through the burn, the burn graph jumps back to full (yellow) and begins filling up with orange. Video Evidence: .ipsImage { width: 900px !important; } burn.mp4

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB In the VAB, when hovering over an engine part in the part picker to display its information, the Max Thrust and ISP labels seem to be missing parentheses or some other sort of separator, with "1 atm" and "Vac." running into the category labels. Severity: Low Steps to reproduce: Enter the VAB. Hover the mouse over an engine part in the part picker. Observe the category labels under the "Statistics" section. Expected behavior: "1 atm" and "Vac." are set off from "Max Thrust" and "ISP" with parentheses or some other separator. Observed behavior: The labels read "Max Thrust1 atm", "Max ThrustVac.", "ISP1 atm", and "ISPVac.", with no such separator. Included Attachments:

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB In the G-force meter shown next to crew portraits in flight, the "0" label is not at the actual zero point of the scale (it looks to be at around 1.5G instead). Steps to reproduce: Launch a new vehicle and get it into orbit. Observe the G-force meter. Expected behavior: The tip of the arrow aligns vertically with the middle of the "0" label. Observed behavior: The tip of the arrow is below the bottom of the "0" label. Included Attachments:

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB When hovering the mouse over an engine-type part on a vehicle, the part is not highlighted in the staging stack. Hovering over the staging stack does highlight the part on the vessel, as expected. Steps to reproduce: Go to the VAB, create a new vehicle, and add an engine. Move the mouse pointer to the engine's icon in the staging stack, and observe that the engine part is highlighted. Move the mouse pointer to the engine part, and observe the staging stack. Expected behavior: The engine's icon is highlighted in the staging stack. Observed behavior: Nothing is highlighted in the staging stack. Included Attachments:

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB After launching a vehicle, the ESC menu's Revert to Launch and Revert to VAB options (under "Vehicle") remain enabled even after returning to KSC or a facility. Steps to reproduce: Start a new Exploration campaign. Press ESC, and observe that the Revert to Launch and Revert to VAB options are disabled. Go to the VAB, create a ship consisting of a single craft, and launch it. Press ESC, and observe that the Revert to Launch and Revert to VAB options are enabled. Click the Kerbal Space Center option to return to KSC. Press ESC, and observe the state of the Revert to Launch and Revert to VAB options. Expected behavior: The options are disabled. Observed behavior: The options are enabled. Included Attachments:

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060Ti | RAM: 32GB After launching a vehicle from the VAB, that vehicle is not saved anywhere, forcing the user to recreate it from scratch if they did not save it first - even though an unsaved vehicle remains in the VAB when going to another KSC facility. Steps to reproduce: Create or load a vehicle in the VAB. Use the ESC menu to go to Kerbal Space Center or another facility. Return to the VAB, and observe that the created or loaded vehicle is still present. Click the Launch button to move the vehicle to the launchpad. Use the ESC menu to go to the VAB. Observe the state of the VAB. Expected behavior: The created or loaded vehicle is still present in the VAB. Observed behavior: The VAB is empty. .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB The R&D facility scene does not appear to respect the v-sync option, creating much more GPU load than expected given the simplicity of the scene. Steps to reproduce: (assuming a test system with a sufficiently powerful GPU relative to monitor frame rate) Ensure that the V-Sync option in Settings/Graphics is set to "off". Go to the title screen, and observe (such as by checking GPU power consumption) that GPU usage is high. Change the V-Sync setting to "on". Go to the title screen, and observe that GPU usage is lower than in step 2. Create or load an Exploration campaign. Enter the R&D facility. Observe GPU usage. Open the Settings menu and change the V-Sync setting to "off". Observe GPU usage. Expected behavior: GPU usage remains low in step 7 due to the low complexity of the scene, then increases in step 9 when V-Sync is disabled. Observed behavior: GPU usage increases significantly in step 7 and does not change significantly in step 9. .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060Ti | RAM: 32GB The secondary mission "Going Green", whose objective is to perform an environment survey on Kerbin using the Science Jr. module, can be satisfied by having a Kerbal perform a a sample collection. Steps to reproduce: Start a new Exploration campaign, and put a vessel in Kerbin orbit. Complete the primary missions Launch A Rocket, Out of the Atmosphere, and Orbit Kerbin (switching to the vessel in orbit as necessary), and observe that the secondary mission Going Green becomes available. Go to the VAB, create a ship with just a command pod, and launch it. Send the Kerbal in the launched command pod on EVA. Let go of the ladder, so the Kerbal lands on the ground. Right-click the Kerbal and perform a Surface Survey. Expected behavior: The mission "Going Green" does not complete. Observed behavior: The mission "Going Green" completes. Included Attachments: .ipsImage { width: 900px !important; }

Here's a summary of my UI-related impressions from a couple of days playing with KSP2 version 0.2.0.0. I know some of these points have been raised before, but I'm including them anyway to add my voice to those observations. PROS/LIKES VAB I love the detailed stage view with delta-V/TWR/etc data, and especially that I can tune the delta-V calculations for specific atmospheric situations. Having the Kerbol system delta-V map available in-game (via the trip planner) is convenient. I don't find the trip planner tool itself especially useful, but it lets me easily check dV requirements without having to pull up a web browser and find one of the community-made charts. It's good that I can use Ctrl+Z to say "put the part I just grabbed back where it came from", so I don't have to worry if I e.g. accidentally pick up a booster instead of the separator it's attached to. KSP1 never worked consistently for me in this regard, and a lot of times I ended up having to reload my craft and redo whatever it was I was doing. Flight The new navball is nice; I like having relevant data collected in one place rather than having to scan across 2-3 UI elements and maybe switch into map view to find it all. I also appreciate the light/dark color change indicating surface vs. orbit velocity, especially after burning toward the wrong prograde vector a few too many times in KSP1. I like that the SAS control icons change depending on the current velocity mode, particularly in showing an "up" instead of "radial-out" icon when in surface mode. This is another place I often selected the wrong vector in KSP1, generally when trying to point up while landing - I'm giving most of my attention to my landing site in that situation, and I found it very easy to overlook that I was in the wrong velocity mode before hitting the SAS radial-out button. Having a "warp to burn" button on the burn timer scratches a big itch from KSP1, where it was often hard to get a click to register on the right orbit segment to bring up that option. CONS/WANTS General I hate to be like the 2000th person harping on this, but the pixel font looks bad and is hard to read at a glance, especially compared to KSP1. (And I say this as someone with nostalgia for the monochrome terminals of the 1970s/80s. I could certainly believe that Jeb and friends are stuck looking at that sort of font, but that doesn't mean we players of the 21st century should also have to deal with it.) Also on the readability front, having a "." or "-" instead of a space in window titles ("TIME.WARP", "VESSEL-RESOURCES", etc.) exacerbates the difficulty of reading those small labels. Many UI elements feel larger than their KSP1 equivalents, with the result that I often can barely see the actual world because the screen is full of various UI windows. The pop-up alerts ("no electric charge", "lack of stellar exposure", "inactive vessel changed SOI", etc.) are much too intrusive. Some (like the SOI change and maybe even the solar panel warning) I would argue are completely unneeded; the rest can be top-center one-line text popups like the "no vessel control" message you get when trying to switch to a craft with no control. Pop-up alerts should be reserved for extreme events that require the player's immediate attention, like "inactive crewed vessel is on crash course" - and even then, they would presumably be so infrequent that the presence of the pop-up itself might confuse the player, so it may be best to just do away with the pop-up alert UI altogether. In "load"-type menus (load game, load ship in VAB, etc.), double-clicking a list item should load it. The facility names "Training Center" and "Tracking Station" look similar enough that I've already accidentally gone to the wrong one several times. Could "Training Center" be renamed to something else, perhaps? Mission Control Why do we have to choose a single mission to track? It would be more convenient to just have the full list of active missions available from a menu as in KSP1, especially as more side missions start showing up. The tracking feature feels like a solution in search of a problem. R&D The 1/2/3/4 page (tier) numbers look far too much like column headers. In my first look at the tech tree, I thought tier 1 was just "Starting Rocketry" and "Light Launchers", tier 2 was the "Solid Fuel Boosters" and "Orbital Rocketry" columns, and so on. I would suggest either using much narrower "page"-like icons, or moving the page indicators below the scroll bar so it's clearer they refer to a scale wider than the screen. (The latter option would also help the scroll bar stand out better - right now it's nearly invisible against the background of Kerbin on tier 1.) It would be nice to have facility buttons or at least an "Exit" button visible without having to open the ESC menu, much like Mission Control has VAB and R&D buttons in the lower right corner. VAB I honestly don't see any benefit to VAB "workspaces" as opposed to KSP1's "ships", and I think it would be more straightforward to instead save individual assemblies separately and make them easy to merge. As an example, in KSP1 I made a generic "Launch-o-Matic" launcher (in fact several, for various mass classes) and merged that into whichever new craft I was about to launch. In KSP2, as far as I can tell my options are either (1) clutter up the Launch-o-Matic workspace with every new craft I create, or (2) keep the Launch-o-Matic in its own workspace and merge it in KSP1-style, in which case the "workspace" part is just added fluff that gets in my way. The load menu should not show autosaves separately from manually saved craft files; as presently implemented, there's no obvious difference between files I have manually saved and autosaves, and I have to focus on the description text to tell them apart. Either list autosaves in a "..."-type drop-down menu or similar, or just don't make per-assembly autosaves at all (though that's admittedly a gameplay rather than UI decision, and autosaves may be warranted while the game is still unstable). KSP1's method of a single autosave of the current assembly to an "Auto-Saved Ship" file when switching to another scene was plenty. Clicking "save" should just silently overwrite the current file, with a separate "save as" icon (or perhaps a tooltip saying "shift+click to Save As") to save under an arbitrary name. The delta-V data in the staging stack and launch button are extremely slow to update; updates should be instant as soon as you add or remove a part. There's no way to view current mission information without going back to Mission Control. (KSP1 had the contract list available as a pop-up window.) The propellant label and amount run into each other in the expanded stage view, leading to confusing labels like "CH40.3/0.3t" (what is CH and how do I have 40 tons of it in this tiny tank?). This could be fixed by not using the pixel font. Flight Adding numeric suffixes to launched ships should at least be optional, if not removed entirely. I get the "STS-123" style reference, but I personally find them to be clutter and prefer to do without them, and I'd rather not have to rename them to get rid of the suffix every time I launch. Which leads to... It should be possible to rename a ship in flight, not just from the tracking station. While I do like the new navball overall, it's a bit big in terms of screen real estate. Could the throttle and atmosphere meters perhaps be packed into where the navball currently has those scrolling numbers (which feel like a cute callback to old aviation technology but not something worth the screen space they take up)? I'm not sure where one would put the velocity/altitude in that case, but one way or another it would be nice to pack everything there a bit more closely. The part action menu is rather unwieldy - I'm sure there are contexts in which it will be useful, but (admittedly as someone coming from KSP1) I find it much easier to right-click a part and get a PAW right next to it, instead of having to scan through the PAM window to find the part I just clicked. Similarly, I find the current UI for crew and resource transfers inconvenient. In KSP1, I could just click a command pod's hatch, click "Transfer" on a Kerbal, and click the target pod to do a transfer; in KSP2 I have to shift my attention away from the ship to the app bar, open up the submenu, click on Kerbal Manager, and only then can I start moving Kerbals around. (I actually wasn't even aware of the Kerbal Manager until doing a web search to see if such a thing existed, and I did my first few transfers with manual EVAs thinking that I had no other choice.) Once you get into those menus, they're not bad, but right now the overall UI flow requires too many steps to get things done. It would be nice to have a KSP1-style "vessel stats" display somewhere - I can't find any way to check the current mass or current stage's acceleration in KSP2. There is no indication of the minimum height for various time warp levels when you hit the cap for your current altitude. KSP1 had "Cannot warp faster than 100x below 123456m" messages, but KSP2 doesn't say anything at all when you try to increase time warp beyond the limit. The "science available" light (blue light next to the "Experiment" button in Vessel Actions) should not activate if all available experiments have already been returned to KSC (and thus would not grant any new science). Relatedly, clicking the "Experiment" button should not attempt to run experiments that have already been done, or multiple experiments of the same type at once. Individual experiment buttons should also not run if the experiment would be discarded - for example, I should not have to wait 10 seconds for an EVA report to find out that I actually already did that report once. Map Maneuver nodes really, really need next/previous orbit buttons. I'm a bit disappointed this hasn't been addressed yet given how often I've seen it brought up, though I grant that it entails UI decisions which are probably less trivial than the actual game behavior change. Another often-requested feature, but there needs to be some way to plan maneuvers exceeding the craft's current delta-V budget - whether by having an option to model the node as an instantaneous burn a la KSP1 (my preference), assuming zero fuel consumption after exhaustion, or whatever. The whole point of a maneuver "plan" in my view is that it's just a plan, not a precise program that must be executed exactly. As an example from my KSP1 campaign, I captured an asteroid and set it up in a 60Mm Kerbin orbit as a refueling station for interplanetary travel. If I wanted to plan a trip from LKO to Duna, I'd look for an intercept path that also brought me close to the asteroid, but finding such a path naturally requires creating a maneuver node with a longer burn time than the craft can accommodate without refueling. Once I have that plan, I can then refine it to add the refueling stop, but I need a way to make the rough plan in the first place. Better fine control over maneuver vectors is needed, whether scrolling on the handle icons like in KSP1, a numeric vector editor, or some other interface. It's very difficult to fine-tune an encounter, especially a distant one, just by dragging the handles. The meanings of the maneuver node control icons (warp to point, discard, etc.) are unclear from their appearances - "does >>> mean advance to next orbit?", "is the trash can with circling arrows a discard or an undo button?", etc. - and could really use tooltips. I still have no idea what the green box icon does. There needs to be a way to set a maneuver node within another celestial body's SOI. For example, if I'm planning a Mun capture, I want to set one node in LKO for Mun intercept, then focus on the Mun and add another node in that SOI view at Mun periapsis. Right now, I have to instead place the node at the Mun periapsis point as viewed from Kerbin's SOI. (The vector control handles also do the wrong thing in that case, which I'll file separately as a bug report if it hasn't been done already.) The maneuver burn timer's "required dV" label should change to "remaining dV" and count down the remaining delta-V after starting the burn. Minor issue, but it seems a bit unnecessary to label AP/PE/other orbit points as "0yr:0d:00h:01m:23s" when the point is just a couple of minutes away. (Fixing this, and perhaps removing all the colons, would help address the screen clutter issue as well.) Also, there's no point in using two digits to write the hour when there are only 6 hours in a day. There doesn't seem to be a key to toggle the navball in map view (keypad "." in KSP1, unless I changed it from the default at some point). I thought it was impossible to bring up the navball until I realized that the "auto-hide navball" setting is mislabeled, which I'll file as a separate bug report.