DibzNr

God this looks so good, I can't wait for it!!!!

Reported Version: v0.1.4 (latest) | Mods: Micro Engineer, Lazy Orbit | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 5 5500 | GPU: RTX 2060 | RAM: 40GB Whenever I grab my harrier jet design the right wing suddenly inverts itself, this occurs even if I remove and then replace the wing Also, when grabbing the non-inverted left wing and trying to replace it, it does a lot of very strange things (See video) Should be noted that saving and then reloading the file seems to fix things until the craft is grabbed again, and this does not persist into flight, this solely affects OAB construction Included Attachments: Desktop2023_09.29-13_37_59_04.mp4 Harrier.json

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 5 5500 | GPU: RTX 2060 | RAM: 40GB I've recently been encountering a semi-consistent game crash whereas the game will crash upon reaching the "Applying legacy module data to vessel parts" part of the loading process after reverting to either launch or the VAB Upon checking my logs, I've noticed that it's being continually spammed with errors like the two below. [ERR 11:09:19.591] Screen position out of view frustum (screen pos 0.000000, 1080.000000, 0.500000) (Camera rect 0 0 1920 1080) [ERR 11:09:19.591] Screen position out of view frustum (screen pos 1920.000000, 1080.000000, 0.500000) (Camera rect 0 0 1920 1080) It should be noted that I am using the -popupwindow boot option in steam with a windowed video setting to get around the game's borderless video setting not being properly implemented yet, as I have two monitors, although I am unsure if that is playing any part in this (It's the only thing I can think of since this seems to have something to do with the window display). Included Attachments: Ksp2.log

The time warp bar gives you the option to switch between UT (Universal Time) and MT (Mission Time), the default option should be MT, just like in KSP1, however for some reason it's UT and it's really annoying not having the mission timer there by default, especially when going back on recordings and stuff and realising I've forgotten to change the mode This is a really small, absolutely tiny thing ik, but it bugs me so much

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 5 5500 | GPU: RTX 2060 | RAM: 40GB This is a very annoying bug/mechanic introduced in 0.1.3 that affects all jet engines, to deactivate a jet engine now it must first be throttled down to 0 and then can be shut off, whereas before it could be immediately shut off regardless of what throttle it was at, this makes building VTOLs even more difficult than it already was, as the only way to work around this is to set the engines to switch to independent throttle when you want to shut them off so that they throttle down on their own, which is very unintuitive and clunky.

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 5 5500 | GPU: RTX 2060 | RAM: 40GB Issue: A persistent visual bug that's been in the game since day one, Dres's rings currently always render behind the planet regardless of what angle they are viewed from, this has no impact on actual gameplay itself but severely ruins what would be otherwise one of the most scenic and beautiful places in the game This image below shows the visual bug: Some people were getting confused over the perspective before, so below is this image but with the near and far rings highlighted, as can be seen the rings should overlap Dres, but don't: From map view:

The title is pretty self explanatory, now that many of KSP2's other largest UI issues have been solved it's a little disappointing to see that even now 6 months in the engineer's report within the VAB is still the only way to get any sort of idea what your vessel's exact TWR is in the entire game. The game is currently severely lacking in critical information that is very important for giving the user a firm understanding of how their rocket will exactly perform and how well it will perform under specific gravitational and atmospheric conditions (This last part makes building Eve ascent rockets an order of magnitude more difficult than it would be otherwise), it's perplexing to see such critical information completely absent since, from what I've gathered from my experience modding this game, all of the relevant information is already fully tracked and calculated internally within the game, so as far as I can tell all that would be needed is for it to be inserted into the UI in some form. At minimum a simple stage TWR indicator that appears when you expand out the stage tab would be more than sufficient, with a configuration window in the app bar to view the TWRs relative to certain bodies and either under vacuum or a certain atmospheric pressure, however ideally it'd be nice to have a clean dedicated UI for it all similar to KER in KSP1 or the recent micro engineer mod for this game to give the user all of the information they need in one concise location.

leek!

Pretty self explanatory, making perfectly square wings is very cumbersome and inconvenient atm, so just having a set of premade square wings would be great for structural purposes

Could be a fun difficulty option

Can't wait

Nice work!

This is gonna be fun

Really appreciate you all directly addressing community feedback and concerns, can't wait to see these fixes implemented

Upvote any% wr

I'd love this, being able to send submarines and such to distant bodies to explore their depths, and maybe even set up underwater bases, would be such a sick mechanic

Yeah, it's incredibly annoying

Just a quick explanation of what this all means: The PAM (Part Action Menu) is a new UI menu implemented in KSP2 that replaces KSP1's PAW (Part Action Window) for parts, the PAM is designed to give a single centralised UI where all parts within a vessel can be searched for. The PAW (Part Action Window) was a menu system in KSP1 where right clicking a part would bring up a singular interaction menu for that part, windows brought up can then be pinned to the screen, forcing them to stay on screen until the user unpins them. On paper, the PAM seems like a step up over KSP1's PAW system, giving you one centralised location to access every part on your vessel and allowing you to search your vessel for parts that would otherwise be unreachable by right clicking (E.G. parts that are clipped inside your craft or inside fairings), however there are two primary problems with the current PAM system: 1) It's very slow Needless to say this is a huge problem and one of KSP2's core issues that bring down the gameplay experience at the moment in my opinion. The critical UI interface that serves as the primary interaction point between the player and their craft's parts is hideously slow for vessels with even moderate part counts, let alone vessels with high triple digit part counts; for my Duna SSTO with over 160 parts the entire game freezes for over four entire seconds before the PAM opens every time I right click a part, which is quite easy to do accidentally by the way. 2) It's very large While less significant than the first point, it cannot be ignored that needing to bring up a UI that eats up an entire 1/6th of your screen every time you want to do the smallest thing is very cumbersome and inelegant to say the least, and while yes the PAM can be rescaled, this tends to not work too well as it's very difficult to find a scale that works well for all parts without eating up too much of the screen space, often forcing constant adjustments to the scale of the UI when switching through different parts, combined with the PAM not locking camera scrolling while moused over it, causing you to zoom the camera as you scroll through the menu, and it feels very clunky and inconvenient to use overall. Even if the PAM were made to be more snappy, it still wouldn't solve the 2nd problem of it feeling very cumbersome to use while needing to manage many parts at once, as such I believe the best course of action would be to bring back KSP1's PAW system alongside it: This mockup is designed to give an idea of how KSP1's PAW system would look in KSP2; as can be seen the already segmented and isolated window design of the PAM's submenus lend well to being disconnected and allowed to float on their own, along with this I also had the idea of incorporating a PAM button within the PAW, allowing the user to quickly jump to that part's location in the PAM should they wish to. I personally believe that the PAW should be the default when right clicking parts, allowing for a quick and snappy experience when looking through parts, with the PAM complimenting it as a more in depth search option for searching for parts within the vessel as needed when they're difficult to locate with the camera, implementing things this way brings back the snappy experience of KSP1's PAW without eliminating the advantages of the PAM.

Added Kapybaras

This was a really insightful read, glad this bug's been sorted

Laythe is beautiful, so I sent a fighter jet there

click...?

PC Specs Ryzen 5 5500 40GB RAM RTX 2060 (6GB) Game Settings Video Game Screen Mode: Windowed (Using -popupwindow on steam to bypass borderless option not functioning correctly) V-Sync: On Resolution: 1920x1080 Rendering Anti-aliasing: 4x Anisotropic Filtering: On Quality Presets PC: Medium Visual Options Environment Prop: On (All subsequent graphics settings set to medium) Severity Medium (Cannot land properly at all here) Frequency High (100% consistently affected all terrain I tried to land on here) Description For a specific area of land on Laythe the terrain seems to behave very oddly, landing gear for some reason just clips straight through the ground and Kerbals float on the ground while on EVA, I am uncertain of the full extent of this problem as the initial continent I landed on (Directly west of this one) did not have this issue whatsoever, however I flew around most of this continent and the terrain behaved the same at both the top and bottom of it, so I believe the problem applies to the entire thing, however of course trying to land at every point on the continent to test whether the terrain works correctly or not is incredibly impractical, so it's possible part of the content's terrain still works fine. I subsequently flew over to the islands to the east of this one and confirmed that the terrain works there (Ignore my plane exploding, that's just me being bad at the game, what's important is that my landing gear isn't clipping into the ground) So to summarise where the terrain is and isn't working from my experience: UPDATE (05/05/23) I have found buggy terrain in the west island that I previously highlighted as being good, as such I believe this is not an isolated problem but rather affects a large amount of Laythe's terrain Softlock issue I've also noticed a persistent and very consistent issue where the game seems to consistently softlock upon trying to load a quicksave with F9 after making contact with this buggy terrain, followed by trying to load a manual save. After landing on buggy terrain, pressing F9 to reload your F5 quicksave plays the Reload Quicksave sound effect, but otherwise does nothing, then loading a quicksave from the "Load Game" button in the pause menu causes the game to get stuck on this loading screen (The background music continues to play and time warp controls can still be used, but the loading bar never shows up and the game never transitions back to gameplay)