TROPtastic

I agree it's hard to find the relevant numbers right now, but after thinking about it, I don't think removing all the leading zeroes is the right approach. Leading zeros are used to prevent a timer from resizing as time changes, which can be janky and distracting. See this screenshot of a SpaceX livestream where they work well: One reason they work here is because there aren't any "h, m, s" labels, but these labels are necessary for maneuvers that will also have days and years of waiting time. A different approach would be to fade or ghost unused time fields in KSP2, like this: This prevents the timer from jumping around and resizing itself, but it also highlights the most important information. It also fits with the current theme if you imagine the faded numbers as displays that have been "turned off."

I actually kinda like "Pause" counting as a time warp level, because it means that I can mash the slow down key until time stops altogether, which is nice if I'm panicking. Of course, I could also learn to use the forward slash key to pause time immediately, so changing this wouldn't be a major problem for me.

Fully agree that we need some way of reproducing exact colours, but I think it will be more complicated than a hex code. The current colour selector uses Hue-Saturation-Value *and* metallicity/transparency (the vertical slider), so the devs will have to come up with a custom scheme that captures all 4 values in one code.

I'm glad to see the UI/UX team is working on unifying the UI and making it more legible. I hope some of that work extends to removing the "serifs" (the slashes and dots) from the middle of 0s. That should help a lot with legibility, as this quick mockup hopefully shows: The main reason that some coding fonts have zero "serifs" is to distinguish them from the letter O, but since these UI fields are only used for numbers, this doesn't seem necessary. Being able to see at a glance that a zero is a zero (and not an 8 for example) will be more useful for most players. Thanks for keeping us in the loop!

CommNet occlusion and line of sight needs to be implemented to provide more meaningful gameplay in the early to mid-game. Some visualization, tutorial, and mission work will be needed to properly explain the concepts to new players, but keeping the mechanic out will boost the argument of people who say that KSP1 + graphics & gameplay mods is a better purchase than KSP2. This would be a shame since the team is passionate about making KSP2 a worthy successor to the original.

I saw this happen on a stream by Mike Aben (around 51:15), so it can even catch out experienced KSP players who are new to KSP2. I suggest changing the pop-up warning to say "Your current flight and mission progress will be lost" instead of "Your flight will be reverted to the VAB" (which is evident from the option "Revert to VAB"). That would show why reverting is different from moving to the VAB.

At what speed should ablation happen in KSP2? Agreed that it should be minimal for a suborbital hop, but there should be some scorching at least for a return from LKO and definitely degradation for a return from outside Kerbin's SoI.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Pro 64-bit (10.0, Build 19045) | CPU: AMD Ryzen 7 5800X 8-Core Processor (16 CPUs), ~3.8GHz | GPU: RTX 3080 12GB | RAM: 32GB I had an issue with re-entering Kerbin's atmosphere from the Mun. Before I hit the atmosphere I was travelling at around 3000 m/s and I had a PE of 32 km. I expected the heatshield to be ablated, but despite the re-entry effects appearing the heatshield wasn't damaged at all. Steps to reproduce: Load the attached quicksave, fast forward time to re-entry, watch as the ablator isn't consumed at all during re-entry. Included Attachments: quicksave_10.meta quicksave_10.json .ipsImage { width: 900px !important; }

Thank you!

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Pro 64-bit (10.0, Build 19045) | CPU: AMD Ryzen 7 5800X 8-Core Processor (16 CPUs), ~3.8GHz | GPU: RTX 3080 12GB | RAM: 32GB Landed on the Mun after having loaded multiple saves and quicksaves to get there, went on EVA and touched down on the surface, right-clicked a Kerbal to plant a flag, and filled out the info for the flag site. What I expected would happen: my Kerbal would place a flag that matched the flag I had chosen when creating my Exploration save. What actually happened: the default space agency flag was placed. Severity: Low - it's annoying, but it doesn't affect gameplay. Workaround: None Included Attachments:

Just happened to me in a 12km orbit around the Mun and subsequent descent. It was very unpleasant to realize that my orbit was decaying through no fault of my own, and that reloading a save made my orbit worse than it had looked when I made the save. Will try again with a 20x20km orbit and see if it reoccurs. Yup, I set myself into a stable 21x21 km orbit around the Mun, and after loading another save and loading back, I was greeted with the sight of my craft spinning wildly and my PE having dropped to 3km (although also on a collision course somehow). Something is very wrong with how orbits are calculated.

Some KSP1 UI windows are great (well, really just the maneuver node editor window), and some KSP1 UI designs are good (like the Navball increment readability and the compact part popouts). That isn't enough to justify the amount of dev-hours that would be needed to reimplement the entire KSP1 UI in KSP2 *and* maintain two options going forward. Instead, it would be more efficient for IG to tweak the existing UIs and add one or two new window types to KSP2. I do think it would be nice for IG to create a "KSP\Music" folder structure in KSP2 for people to drop custom audio into. Then the game could automatically play their chosen songs in specific situations like orbit or launch.

I've noticed this as well, although frequently I'm able to stage with only one press of the spacebar (as intended).

@Spicat is it possible to change the bug report title from: "When unpaused it's difficult to select the maneuver plan gizmo highlights correctly because of the arrows (when paused, it highlights correctly)" to: "When unpaused it's difficult to select the maneuver plan gizmo because of the arrows (when paused, it highlights correctly)" ? I think the second title is more concise.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Pro 64-bit (10.0, Build 19045) | CPU: AMD Ryzen 7 5800X 8-Core Processor (16 CPUs), ~3.8GHz | GPU: RTX 3080 12GB | RAM: 32GB Language: English (Regional Setting: English) | System Manufacturer: ASUS | System Model: System Product Name | BIOS: 4021 (type: UEFI) | Page File: 36586MB used, 9244MB available | DirectX Version: DirectX 12 | Resolution: 1920x1080 | UI Scale: 100% Severity: Low Frequency: Always Description: What I was doing: From the Training Center, I loaded the "Planning a Maneuver" tutorial from the "Orbital Transfers" section. I played through the tutorial until it was time to place a maneuver plan. I placed one in the indicated location, adjusted its prograde handle, then I tried to move the plan as suggested. What I expected: I would be easily able to highlight the main "yellow circle" of the maneuver plan and drag it around my orbit. What actually happened: I was unable to consistently move the maneuver plan because the orientation arrows kept being highlighted as the camera shifted and my craft moved around Kerbin. However, when I paused the game I was easily able to highlight the "yellow circle" of the maneuver plan. I suspect this has something to do with how the "interaction zones" are activated as the camera moves around. Suggested fix: promoting the "yellow circle" of the maneuver plan so that it can always be selected over the orientation arrows, or (better yet) make the orientation arrows unselectable so that only the orientation icons can be dragged. Additional details and pictures can be found here. Included Attachments: Kerbalspaceprogram22023-12-2300-32-29.mp4