Search the Community

Reported Version: v0.1.5 (latest) | Mods: SpaceWarp, K2D2 | Can replicate without mods? Yes OS: Windows 11 | CPU: Intel Core i5 8th Gen | GPU: AMD 5700 XT | RAM: 16.0 GB Severity: Medium Frequency: High Description: I expected to see all five options shown as what they do by hovering over the button to change audio settings. When I went to change my audio settings from headphones to laptop speakers, I noticed that when hovering over any of the buttons, it showed all 4 options except for laptop speakers. Steps To Replicate: Go into the VAB, go to the pause menu, setting, and then audio. When there, hover your mouse over the buttons and the bug will become apparent Included Attachments: KerbalSpaceProgram22023-11-2514-29-47.mp4

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: windows 10 | CPU: AMD ryzen 7 3800X 8-core processor | GPU: NVIDIA GeForce GTX 1050 Ti | RAM: 32 GB Severity: med Frequency: high Description: when you put wings on a vehicle and rotate the vehicle the wings will not produce lift, but they will if they get separated into separate crafts that are contained in a kind of cage like structure (though this is not very useful since they often glitch through it after a while anyway). look at the craft at 4:30 in the video in the post, or in the video in the attachment to get an idea of what i mean (video in the post made in the first ksp 2 version but still works the same way in 1.0.5). they only fly after separating the wings (this is not because of the wings pointing down on this specific craft before separating, it also happens on other crafts with wings in the same place before and after detaching), though logically this should not be needed and it works without needing separate crafts as wings in ksp 1 (robotics propellors also work there). I included a version of the craft as an attachment (though the same issue happened on multiple independently designed crafts). it was meant for jool but can also work on kerbin, just give it enough time to spin up. the same issue will happen on any craft trying to use rotating wings as a source of lift. Included Attachments: KerbalSpaceProgram22023-12-0322-06-38.mp4 JAVprototype.json .ipsImage { width: 900px !important; }

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: R7 5800X | GPU: RTX 3080 Ti | RAM: 32gb im making an ssto (space plane) doig galot of testing ( lauch and go back to VAB). after some time of messing doing test on the craft (lauching/going back to VAB many times for tweaking), and eventually when i go back to launch, my surface control dont to respond, so i cant take off , go up and down, sometime working at the start then stop responding in flight and cant control my craft anymore. my fix is to restart KSP2 completly, then may happen again if i do too much launch/return to VAB. i dont think its related to this specific craft because it did happen to me before 1.5.0 with a diferent one Included Attachments: good.json .ipsImage { width: 900px !important; }

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: 64-bit Windows 11 Home | CPU: 11th Ge Intel(R) Core(TM) i5-11400f | GPU: NVIDIA GeForce GTX 1660 ti | RAM: 16.0 GB (15.8 GB usable) When my camera goes below 0m sea level on Duna within a large Dunian crater (Image attached) the atmosphere behaves in the same way it would when underground, what I imagine is the atmosphere's intended bounds. When looking down while at this altitude, a black void of atmosphere can be seen below the camera towards the center of Duna. The atmosphere's opacity is abruptly increased below the horizon line. This is not specific to EVA view, it happened while I was descending in the rocket as well, only happening after going below 0m above sea level. Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 9 5900X | GPU: AMD 6900XT | RAM: 32GB After flying and crashing a plane, I reverted to the VAB. After loading, the screen would only show the frozen VAB display, even while navigating to other places in the game: KSC, Training Center, etc... The game would recognize where you are (the pop-ups show up if you hover your mouse over different parts of the screen), but the background would remain the same. Screenshots: craftFiles.zip .ipsImage { width: 900px !important; }

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 5 3600 | GPU: Nvidia RTX 2060 | RAM: 32gb A kerbal on EVA is still able to climb a ladder even though it is fully retracted. Extending the ladder does not change the kerbals position and they will act as if the ladder did not change. Included Attachments:

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Interl(R) Core_TM) i5-9400F 2.9GHz | GPU: NVIDIA GeForce GTX 1660 Ti | RAM: 16 GB So I was just messing around in the game, doing a test with the gridfins. I landed a little too hard and broke the engine, the legs of course fell off since they were connected to the engine. However I noticed by accident that I could still make the legs open or close. With the parts manager as well as just pressing the button Video Evidence: 2023-11-3021-29-19.mp4 .ipsImage { width: 900px !important; }

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Pro 64-bit | CPU: AMD Ryzen 5 5600X 6-Core Processor, 3701 Mhz, 6 Core(s), 12 Logical Processor(s) | GPU: Radeon RX 5500 XT ( Trigger 6 External Graphics | RAM: 32GB installed Severity: low ( Workaround of simply setting cloud quality to low, i think user supertiefighter was the first to realize ) Frequency: High, can consistently reproduce the issue Expected Experience: Flying into cloud will obfuscate the gamescreen with white particles that will disappear or thin upon exiting the cloud. Craft dependant: No, bug can be triggered by multiple craft files Upon Flying into a cloud, Artefacts begin appearing, seemingly over anything that is not the cloud or the aircraft ( further testing shows that if the camera is sufficiently zoomed out, the space showing the craft is also subject to artefacting ). these artefacts are black and continue to obscure everything ( including the cloud and craft, if the camera is moved such that the artefact would obscure them ) until disappearing upon reaching some variable distance around 12,000 meters above sea level See screenshots below for severity of the issue and testing results Included Attachments:

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Pro | CPU: Ryzen 5 3600 | GPU: RX 6400 | RAM: 16Gb @ 3200Mhz The game crashes when I revert to VAB during the loading screen step "Loading KSP2 missions" specifically with the background of a rocket rolling to the launch pad. Within 8~9 reverts, that has happened.

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel Core i7-1065G7 | GPU: NVIDIA GeForce MX350 | RAM: 8GB Issue: When working in a workspace with a lot of parts, picking up a subset of parts causes lag. This lag increases seemingly exponentially the more parts are in the subassembly you picked up. Picking up the entire assembly (all parts in the workspace) also causes lag, but to a lesser extend. Steps to Replicate: open '1000_parts_lag.json' in the VAB enable the ingame fps counter. Observe the FPS for the loaded workspace pick up a single truss. Observe the drop in FPS pick up a group of attached parts (subassembly). Observe the more severe drop in FPS pick up the entire assembly (crtl-a). Observe a smaller drop in FPS than steps 3 and 4 Disclaimer: i am playing on a system that is below the minimum required specifications. This specific bug seems to only be exacerbated by my hardware however, not caused by it. Images:

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel i5-8400 | GPU: NVIDIA GTX 1050 Ti | RAM: 16 GB When starting up the game in a setup consisting of three monitors, despite the launcher being in the central monitor (which is monitor number 2 in the display settings and is set as the primary monitor), the game launches on the left monitor (which is monitor number 3 in the display settings). This can be fixed by changing the game to "Windowed" mode, dragging the window to the central monitor, and then switching the game back to "Borderless" or "Windowed". Upon relaunching the game, the game only appears on the central monitor again if the game was previously exited via the in-game "Exit" option on the main menu or via the "Quit Game" option in the game's escape menu. However, if the game was closed via the "Close window" button accessed by right-clicking the game's icon on the taskbar (which is often how I personally exit from fullscreen games) or via termination in the task manager, the game will once again appear on the left monitor upon relaunch. Edit: While writing this bug report, which covers a different but similar issue, I realized that I had only tested this bug in the "Borderless" optioning the graphics settings. Upon looking a little more into it, I found out that this bug probably has to do with the fact that the game window is minimized while the game is being closed.

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 10 Pro 10.0.19045 64-bit | CPU: Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz (8) | GPU: NVIDIA GeForce RTX 2060 SUPER (8019MB) | RAM: 32683 I tried to stage a "daughter" satellite from its "mother" but the game does not register the two craft as separate (resources, probes etc showing in the same list & only one craft in map view and tracking station). It could be something stupid that I'm doing but I can't for the life of me figure out where I could be going wrong. Included Attachments: SeparationDoesNotCreate2Craft_logs.zip Craft File: Duna Comm Sats.json .ipsImage { width: 900px !important; }

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Linux Ubuntu 20.04.6 | CPU: AMD Ryzen 5 3400G | GPU: NVIDIA GeForce GTX 1080 Ti | RAM: 16GB Specs: (Obtained from Steam via Help > System Information) Severity: Med (Causes craft to look wrong and ugly.) Frequency: High (Always occurs) Description: When TOOB parts are duplicated the variable length fairing section becomes offset from the base ring section. This gap increases with each duplication. There should never be a gap between the base and the fairing of the TOOB. Steps to reproduce: Start a new vehicle in the VAB. Select any TOOB part from the structural section of the parts manager. Duplicate the TOOB: With the selection tool hold the Alt key and click on the first TOOB. Attach it to the fairing end of the TOOB. Duplicate again starting with the original TOOB. Attach to the fairing end again. Observer that there is a gap between the faring and base of the 3rd TOOB. Continue duplicating the entire assembly and attaching the duplicate to the top fairing end. Observer more gaps and also observe that the gaps get wider with each duplication. Video Evidence:

Reported Version: v0.1.5 (latest) | Mods: SpaceWarp, Community Fixes, UITK, Fancy Fuel Tanks, No Seizure Warning, Skip Splash Screen | Can replicate without mods? Yes OS: Windows 10 22H2 | CPU: AMD Ryzen 3 3200G | GPU: GTX 1050 Ti | RAM: 16 GB 3200MHz I was about to record a video on another bug (No Stages), when i pressed Alt+F9, it triggered the quickload and it loaded a quicksave. Is this intentional? .ipsImage { width: 900px !important; }

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD R7 3700X | GPU: AMD Radeon RX 7800 XT | RAM: 32 GB Severity: Low Frequency: High (Every time the button is hovered over in the VAB) The tooltip for the VAB Redo icon appears above and to the right of the button, and not to the right like the undo button. This is likely due to it's gameobject being scaled by -1 on the y axis. tThe gameobject in question can be found at this path. /OAB(Clone)/HUDSpawner/HUD/widget_ToolBar/GRP-Undo-Redo/KSP2ButtonText_ToolsBar-Redo Bugged (Current): Expected: Included Attachments:

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows Home Single Language | CPU: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz | GPU: RTX 2060 | RAM: 16 GB When I open the game and try to start a new game, it gets stuck on the loading screen. Some players say that the problem is solved when we change Windows to English. But I can't do this because my windows is only licensed in Turkish. Spicat Edit: Here the loading screen stuck when loading a campaign while Windows is set to Turkish (I tried on Windows 10): Workaround: Change Windows language to English if possible (not the case for the author): https://support.microsoft.com/en-us/windows/manage-display-language-settings-in-windows-219f28b0-9881-cd4c-75ca-dba919c52321

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Win10 | CPU: Intel i7 10700 2.9GHz | GPU: NVIDIA 2060 Super | RAM: 16GB DDR4 The Burn Time window is a welcome new feature to KSP2 ( I would however like to the the numeric DV amount decrease during the burn however). Its best part is the set of 4 LEDs to prep you to manually start your burn. There is an audio sound as each LED turns on to help you get your timing down so that you can hopefully start the burn with only a very small fraction of a second error. The 4 LEDs show yellow, yellow, yellow, green. However sometimes it progresses with yellow, yellow, green, green. When the 3rd LED is erroneously green, I have at times accidently started my burn 1 second early....which has consequences. This issue in NOT consistent. Considering burns are not done every minute of gameplay, this issue has perhaps gone unnoticed. However, in performing tests of around 20 burns of atleast 10s in length, I noticed the problem less than 50% of the time. More like 25%. Therefore I believe it to be a rounding error with the clock of the LED count down versus the clock of the actually burn start time. Sometimes the second(1s) prior to the burn start (the 3rd LED's time to be lit up, yellow colored), the actual burn start time is perhaps slightly less than 1 second away...and the code decides to show a green LED on the 3rd LED, not a yellow colored one. That's just my guess however, as I have no means to obtain sub-second accuracy. Also, that would be able the most plausible explanation for such a trivial problem. It is however a problem, albiet minor and inconsistent. As well, in regards to other inconsistencies with the Burn Timer window, when stopping the burn, I have NEVER seen this issue occur when stopping. It has always been yellow, yellow, yellow, red. 20 tests, no observations of a similar issue when stopping. However....there is no audio sound of the LEDs lighting up when stopping. I dont know if this is design oversight or intent, but one thing is true....burn precision not only matters when you start a burn, but as well when you stop it. So, please address this audio issue as well. Perhaps just play the same tones as starting the the burn, but play them in reverse. Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 11 | CPU: AMD 5600X | GPU: NVidia 3060ti | RAM: 32GB (8x4) DDR4 (MK3 to Large Fuel tank) Fresh launch after 1.5.0 update, new game. Uninstalled mods after update, should not affect anything. There's one between the cockpit and Hydrogen, and one in hand just below the cockpit. Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: W10 | CPU: i7-9700k | GPU: nVidia 1080Ti | RAM: 128GB The clouds are disappearing while rotating the camera. Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Professional | CPU: 5800X With inhouse overclocking | GPU: Zotec 3070 with improved fans. | RAM: 64GB CL14 Not sure this is a "bug" but there is significant lag when I land in the water. .ipsImage { width: 900px !important; }

Reported Version: v0.1.3.2 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz | GPU: NVIDIA GeForce GTX 1660 Ti | RAM: 31.83 GB Med. Severity I made a tiny satellite with xenon ion thruster so naturally I wanted to speed up time to make it accelerate faster. I did so, one step at a time up to 10x speed, then saw it wasn't maintaining prograde so I set the time back to 1x but the throttle was stuck. A message kept telling me that the throttle can't be changes while the time is not at 1x speed. But the close was ticking up at 1x speed. Fuel was being spent at a faster rate though so it was clear that the engine was still burning fuel at 10x speed. I tried turning the speed up and down a few times then gave up an shut off the engine because that function still works. This is going to make it very hard to fly long range xenon missions if this is not a one off. I restarted the game and everything worked fine... until I once again started the engine, throttled up, and advanced time for a bit. Then it got stuck again. I attached my save file... I think that's the one you would need... not sure if you need the meta file, but the JPG seems to just be a visual. Included Attachments: autosave_3.json

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: R5 5600 | GPU: RX 6700XT | RAM: 16GB DDR4 3200 Whenever you place your craft in orbit and want to warp time in order to wait for an interplanetary transfer window, you press Esc > Tracking Station. Once you are in the tracking station, you notice that your warp arrows are still locked to the same speed limit your craft had in Low Kerbin Orbit. This requires you to instead go to the Kerbal Space Center and then get into the Tracking Station. Attached Clip:

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 In the attached .zip file, there is a workspace (autosaved file) that causes my KSP2 to immediately crash when I try to launch it. I created a completely fresh campaign for 0.1.5, then created a fresh workspace for a Buran build. That resulted in the vehicle disappearing into the floor like in previous versions of the game (see this report). But when I load up the last working autosave of this, the craft appears to be fine. But when I press "launch", the game will crash every time. This really needs to be looked at. Attachment info: Video showing what I did. First I had the broken craft with parts hugging the floor. Then I loaded the last known working autosave version. Then the game crashed. The Bug package contains two sets of log files. First the logs from what is shown of the video. The second one is in the "Files" subfolder and was from a crash I experienced before I decided to record myself playing. Included Attachments: BUG137-Vehiclelaunchcasesgamecrash_logs.zip

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 7800X3D | GPU: RTX 4090 | RAM: Corsair Vengeance 64 GB (4x16) 6600MHz Activating the jetpack while submerged significantly increases the buoyant restoring force, overpowering any water drag. You can use this to build a lot of upward momentum using the water like a trampoline each time you resubmerge.

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Win10 | CPU: Intel i7 10700 2.9GHz | GPU: NVIDIA 2060 Super | RAM: 16GB DDR4 When attempting to perform precise maneuvers, the accuracy of when the maneuver starts and stops is vital. When performing this manually, the longer the burn duration, the more accuracy can be given to the DV amount applied in the burn. This is needed, even though the LEDs and sounds for burn stop and start in an AWESOME improvement over KSP1 in this regards. Extending burn duration is even MORE important during correctional burns, when the engine being used was primarily meant for injection burns, not minute course corrections. Therefore small DV burns quite often have a 1 or <1 second burn time, which can yield a large inaccuracy when done manually. Increasing that small DV burn duration from 1 second to 30 seconds as an example can vastly improve the accuracy of the resulting burn. However, when changing the Thrust Limiter setting of the engine AFTER creating a maneuver node does not automatically adjust the duration of the burn (as indicated in the Burn.Timer window's "Stop Burn In" parameter). At this point the use, can delete the maneuver and re-create it again, or MODIFY the burn, which apparently sends an updated value of the Thrust Limiter parameter, causing a recalculation of the Stop Burn In parameter. Thus, the Stop Burn In parameter needs to be automatically updated if and whenever the Thrust Limiter parameter is changed, and an existing maneuver has already been created. Video Evidence: Desktop 2023.11.09 - 18.40.50.01Handbraked.mp4