Search the Community

Reported Version: v0.1.3.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel i9 9900K | GPU: Nvidia 3070ti | RAM: 32GB Appears to have happened since 0.1.0.0 Frequency: Not every time but regularly. Steps to Replicate: Simple Craft Test for Over the Top Distortion: More Complicated Craft to Show Side Distortion: Additional Information: Not just visual. It will affect crafts handling as well. Is this a floating origin problem?

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD Ryzen 5 5600 | GPU: RTX 3060 Ti | RAM: 128 GB What I did: 1. I picked the Crater Crusher standard rover and launched from one of the runways 2. Accelerated until the vehicle was fast enough to tilt to the side when cornering and steered it into a curve What happened: The vehicle tilted to the side. As soon a this happened, the wheel started to sink into the ground. What I expected: All parts of the vehicle stay on the surface. Frequency: Consistently reproducable Included Attachments: sinking_wheels.mp4

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 10 | CPU: i7 10700K | GPU: RTX2060 | RAM: 32GB Placing the maneuver node somewhere, opening to edit and turning the camera around (e.g to see how the trajectory is affected on the opposite side of the planet) makes it impossible to operate. As in the screenshot. Included Attachments:

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 10 | CPU: Intel Core i7-6700K | GPU: 2 x NVIDIA 1080 | RAM: 32 GB Scenario: Having no engine on a craft but consumers of EC will have no effect on EC level. The level of EC remains at max no matter how long you use anything that is supposed to consume EC. Test vehicle: MK1-3 pod with 150 EC internal storage capacity, 2 medium sized reaction wheels right underneath it, a medium decoupler underneath them, a tank and an engine (mainsail, but that does not matter at all). Test: Launch vehicle to some point where it can fly for a bit, decouple the engine and tank bit so that only the command pod and the 2 reaction wheels remain. While flying keep pressed any key that performs an action that requires the reaction wheels, e.g. keep q depressed to roll faster and faster. The wheels are supposed to consume 2.xx EC per second (according to tooltip in VAB) so it should drain the 150 EC from the command pod fairly quickly. Result: The EC level remains at 150 EC without any change at all no matter how long I use the EC consumers. Either the EC consumption is 0 or the EC production is constantly at a very high level without any engine or solar panel. Both of these conditions are wrong and should be classed as a bug.

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Threadripper Pro | GPU: TUFF 4090 | RAM: 128 gb Borderless mode and Fullscreen mode both work the same but I was under the impression that you can move your mouse to another window in Borderless mode.

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i7-8700 | GPU: Geforce 1070Ti | RAM: 16GB While in flight view while using right click on the mouse to move the camera is it very easy to accidentally open the part menu. If you hold down right click, move the camera a little and release right click while the cursor is hovering over a part it will often open that part menu, even if your mouse didn't originally start over top of any parts when right click was depressed. In order to replicate it you have to press down right click, move the camera, and release in less than a second (maybe 100to 500ms or so) to trigger the issue. If you hold down right click and take your time moving the camera around the issue does not trigger when right click is released. I have never triggered the same issue in KSP1 while using the camera in the same way. The same issue exists in the VAB as well when you use right click to move the camera there as well except it centers the camera on the part as though you had just right clicked on a part. Included Attachments:

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 5800X | GPU: GTX 1060 6GB | RAM: 16GB Despite using 2x symmetry, only one engine appears in the situation below: Included Attachments:

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 (launched separately for ksp) | CPU: Ryzen 5 5500 | GPU: 2060 | RAM: 16gb 3600 If the first vessel you launch lands on the mun before kerbin, the tutorial assumes the player has just splashed down and recommends recovering your vessel. Included Attachments:

Reported Version: v0.1.2 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home | CPU: Ryzen 7 5800X3D | GPU: GeForce RTX 4070 12gb | RAM: 32gb DDR4-3200 CL16 RAM Recently upgraded to an RTX 4070 and I'm seeing these weird green / purple dots that move with the anti-aliasing on distant terrain objects, and sometimes flash their respective colours. Only happens on distant terrain, not close terrain or any part of the craft. Multiple high-stress benchmarks and testing in other games seems to confirm it is not a hardware problem. I have the latest NVIDIA drivers installed. Included Attachments: ksp2_x64.exe2023_06.11-10_01.59_01.mp4

Here it is in action:

KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.1.0.21572 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None Video Evidence: https://youtu.be/_Umxp6djskY (11 Seconds) Save File: https://www.dropbox.com/s/x7yytoau97nn8l0/0120TStationScrollIssueSave.zip?dl=0

KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.1.0.21572 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None Important: To be Clear the Docking Happens in Normal Time. Then Timewarp is Used and Disengaged Afterwards. I Don't Believe that the Movement in the Videos is the Cause. Report is Broken up into three parts: Glitch Moving Up with Disengaging Timewarp After Docking. Showing From Left and From Right in Separate Videos. Docking and Then Undocking Staight Afterwards and Disengaging Timewarp. Glitch Moving Up with Disengaging Timewarp After Docking: Showing From Left and From Right in Separate Videos: Docking and Then Undocking Staight Afterwards and Disengaging Timewarp: Save File From Videos for Testing: https://www.dropbox.com/s/4xnijmi6bh1ta57/DockTimeWarpDirectionalTestSav.zip?dl=0 Additional Information: Using the save from 0.1.2.0 it appears that this issue has been in the game since 0.1.0.0 Work Around: Quick Save then Quick Load (F5 then F9)

KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.1.0.21572 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None Three issues are happening here: The control point on undocking a craft can in some cases not reset to the undocking craft. The Navball freezes and doesnt reflect the correct orientation of the craft but Control From Here change it to the current orientation like a photo. On using Timewarp and then going back to normal time the craft freezes in place even if the engines are activated. Below are Two Different Situations Using the Same Crafts to Make this Happen for Different Docking Ports: 1. Tug Undock Bug Test: 2. Tank Undock Test: Additional Test Which I Did Earlier in Testing That I Only Have a Save File For: Tank Radial and Node Undock Test: Important Information: Log Files indicate the following after disengaging timewarp: [Flight] PartComponent must have a root part! Additional Information: Testing in 0.1.0.0 Appears to have the bugged craft move in a radial out direction even with no engines being fired when there is no directional change in 0.1.2.0 Testing in 0.1.1.0 Appears to be the same as 0.1.2.0 Work Arounds: Undock from the other docking port and then change to the craft F5, F9 (Quick Save, Load Quick Save) Control Point Not Resetting Aspect is Similar to the Following:

KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.1.0.21572 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None Two Confirmations Below: Video Evidence and Replication Steps. Save Files Before and After using a Text Editor. Video Evidence and Replication Steps: Confirming Via Opening the save files Via a Text Editor: Save Files: Additional Information: 0.1.0.0 + 0.1.1.0 Using the save file that I made in 0.1.2.0 have the same issue. If save compatibility is still good between versions this started in 0.1.0.0

KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.1.0.21572 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None Issues covered in this bug report: Control point doesn't reset to the undocked craft. Choosing docking ports on the other craft after the undocking displays "Control From Here" when they should be "Set Target" except for the one undocked from. That it is an intermittent problem. Sometimes it happens. Sometimes it doesn't. I have supplied two save files for the same craft here for comparison and 1 for testing: Bugged Undocking: https://www.dropbox.com/s/ody5j8pcq4v4c3z/UndockingIncorrect.zip?dl=0 Correct Undocking: https://www.dropbox.com/s/v2k5wygnrf73176/UndockCorrect.zip?dl=0 Video Evidence: That it is an Intermittent Problem (Video Evidence of inconsistent fails and passes over a few minutes): Log Files and Locations for Passed and Failed Undocking From Video: Work Around: Save and Reload. Additional Information: Comparing save files seems to show docked crafts are inverted somehow. I just cant read it to know why thats causing the problem. Also Tested in 0.1.0.0 and 0.1.1.0. Same Problem.

KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.1.0.21572 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None Important Information to Start With: The expected behaviors below might be an interim fix due to that craft priorities aren't a thing yet. Minor testing with 0.1.0.0 and 0.1.1.0 appear to have the same issues so not a regression as long as a 0.1.2.0 save is backwards compatible. On Docking: Expected Behavior: Docked craft should maintain the SAS/RCS state of whichever craft has SAS/RCS on. Observed Behavior: After docking SAS/RCS are both off. On Undocking: Expected Behavior: If the original craft has SAS/RCS on then on undocking both crafts should maintain SAS Stability/RCS states. Observed Behavior: One craft will lose SAS/RCS on undocking. Video Evidence: https://youtu.be/ulCGmmh2fNQ (22 Seconds) Save File: https://www.dropbox.com/s/l5b4efhw6qb5nne/DockUndockTestSave.zip?dl=0

KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.1.0.21572 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None How to Replicate: Start KSP2 Load Save files below Videos below show the following: Loading the save files for the first time showing the problem Loading the save files for the second time showing the problem has gone away. Launch Pad: Orbital: Workaround: As I said above: Load the save file 2 times. Additional Information: Been in the game since 0.1.0.0

KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.1.0.21572 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None 2 Videos for this Bug Report: First video shows it happening in space Second video shows COM appears to be calculating between the two separated crafts soon after launch. First Video: Second Video: Work Around: Jettison the Engine Plate's fairing/shroud However SAS is not engaged anymore. Change root part to the top of the craft.

KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.1.0.21572 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None I created the following test save for Minmus: First there are crafts with various heights to eliminate crafts being part of this bug 4 Kerbals on top of a platform made of girder segments so they were off the ground 1 Kerbal at the top of the rocket on the nose cone to put a kerbal up high 3 Kerbals on the ground 1 Kerbal on a thin craft 1 Kerbal on a small lander which is close to the height of a kerbal 1 Kerbal that is on the (inbuilt) ladder of the pod 1 Kerbal that is on the hatch of the crew cabin below First Screenshot of all 12 Kerbals: Second Screenshot of only 2 Kerbals remaining: Video Evidence: Note I edited out the majority of the loading times. Look to 30 Seconds when it happens from Orbit when some of the Kerbal indicators disappear. https://youtu.be/1bL-0YC9Af0 (48 Seconds. Edited out load times between scenes) Steps to Replicate: Start KSP2 From main menu load 0120Scene12Kerbals Load 0120Scene12Kerbals again (to counter another bug) Change to Map Mode Change to Minmus Orbiter 1 QuickSave QuickLoad Flight Mode face Minmus looking at cluster of icon names Hit timewarp Turn off timewarp (probably an unnecessary step) Go to KSC Screen (to counter another bug) Go to Tracking Station Go to Minmus on left menu and choose to Control KerbalTestStand Save File: https://www.dropbox.com/s/v0fgk3k0vxkckqz/0120Scene12Kerbals.zip?dl=0 Log Files: https://www.dropbox.com/s/scq3ptd57tk148j/Ksp2.log%2BPlayer.log.zip?dl=0 Things of Note: Log files show that the game thinks they are colliding with the surface (search for "Approximate collision between " to find lines for Kerbals being destroyed) Kerbals are being deleted no matter the distances above the surface with what they are standing on. Kerbals on ladders are unaffected. Crafts of different heights aren't affected. The bug doesn't happen initially after changing to the orbital craft. Needs a QuickSave and QuickLoad first. Did a limited test on Mun with 1 kerbal just standing on the ground with the same result. Note: Tested Supplied Save in 0.1.0.0 and 0.1.1.0 using the 0.1.2.0 save. Orbital Craft is within render range of the Kerbals on the ground.

KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.1.0.21572 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None The issue appears to relate to the following: Radial Decouplers position on a part. Inline Decouplers but I am not sure of position on craft. Note I haven't tested all the decouplers for these issues. I used the TT-38X because it gave the most extreme results. I didn't test all the decouplers but the bigger radial one does it too. Only tested one inline decoupler. I have 3 Tests for this bug report: Multi-position Radial Decouple test to show different directions decoupling is throwing parts. 8x Symmetry Booster in orbit decouple moving in a radial out direction. Inline Decouple in orbit moving in a radial out direction. Multi-position Radial Decouple Test: 8x Symmetry Booster in Orbit Decouple Moving in a Radial Out Direction: Inline Decouple in Orbit Moving in a Radial Out Direction: Additional Information: Is this caused by some sort connection like an autostrut connecting at angles? I did a quick test with a 0.1.0.0 craft file for 0.1.0.0 and 0.1.1.0 and the results indicates it started with the first version.

KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None I did the following: Started KSP2 From the Main Menu I loaded a campaign Did some tasks Saved and went back to the Main Menu Loaded a new campaign Then ALL the new campaign information is missing from Ksp2.log but is still there in the Player.log Ksp2.log + Player.log Attached: https://www.dropbox.com/s/dfnq8c9d0dn6fv7/Ksp2%20%2B%20Player%20Logs.zip?dl=0 Ksp2.log has the following final entry at line 2076: [LOG 14:43:06.624] [System] Game Shutdown completed in 1.2352s. Player.log has a similar entry at line 2113 but continues afterwards until line 49676: [System] Game Shutdown completed in 1.2352s. Additional Information: This issue also happens in 0.1.0.0 Ksp2.log is quite useful for tracking down issues because of the timestamps.

Sometimes struts from a rocket core to a rocket booster are weak and flop around like they are barely attached. One workaround may be to go with single strutting. Another workaround may be to reverse the direction of strutting. A final workaround may be to change from mirror to dual symmetry.

When setting the panther engine to afterburner mode this changes the animation to afterburner in the VAB. But when loaded in the nozzles are in non-afterburner mode but they act like they are in afterburner. Also as someone else pointed out the animation itself may be in reverse. I don't know enough about that to make a determination. And also as I pointed out I think the plume should expand just like a rocket plume does in lower pressure.

This has been a problem since the beginning where when mounting a vehicle to another one there is a high chance of one or both vehicles failing in some way. This adds yet another element to a long long long build checklist. A beautiful orbit was ruined today by this bug being discovered on a parasite fighter.

More often that not the result of clicking the pause button is nothing or an immediate pause and unpause. Get somebody that knows what they are doing and run the game UI on another thread entirely.