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?

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 11 CPU,GPU and RAM: i9 9900KF, RTX 2060 (6GB VRAM), 32GB RAM Mods: 0 Description of the problem: The rockets bend very easily, making them quite difficult to launch, especially if they are large. Solution: Modify in the PhysicsSettings.json file and increase the parameter called "JOINT_RIGIDITY"

I am not sure what causes it but often when building planes the wing control surfaces will work backwards at least visually, though sometimes making the plane unable to fly correctly without inverting them. I think it is more likely when adding multiple sets of wings though it sometimes happens with only one set. I am not sure if this guess is correct, but I think it sometimes is the wings getting confused about their position on the craft and whether to change direction by creating drag or pushing the air another direction. I was having issues putting in a screenshot but when trying to make my craft fly up on non-inverted wings, the main wings angle the control surfaces downwards creating drag in the wrong direction with the wings not being in a position to push the air another direction. On atleast 1 plane the effect was so strong I had to invert the wings or else the SAS wouldn't work and I would have to press the opposite button I intended.

While orbiting Mun around 15K my PE and AP constantly change as though I'm gently thrusting toward the ground. It stops at any level of time warp but reappears at normal time scale. Definitely no thrust or RCS active.

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.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

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.

It's impossible to rename a ship in the Tracking station. When you edit a name the line for KSP change, not the line of the ship you were editing. When you exit the tracking station and come back the KSP line is now back to KSP but the name of the ship still has the old name. Also the name is barely visible when editing.

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

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

I sent this to the devs through the support email but I think this is now the preferred communication channel for bugs? So I'm reposting for better visibility. Especially since I saw Matt Lowne hitting this exact bug. I was getting all my kerbals out of my ship in orbit for a group photo, and when I was ready to get them all back inside the ship, none of their EVA jetpacks were working. It's like they stopped accepting input. The fuel gauge showed them all in the 80-90% full range so they weren’t empty. I switched back to the space center and then used the tracking center to take control of them again, only to find they had somehow re-glued themselves to the ladder. Now wondering if they thought they were still on the ladder in some way? It appears to be related to getting additional Kerbals out of the ship Steps to Reproduce: -Have a pod in space with at least two kerbals in it -Have one kerbal get out. -Observe jetpack works fine, even if you switch back and forth between the kerbal and the vessel -Now have the second kerbal get out and fly around -Switch to the first kerbal -Observe, the first kerbal will now no longer accept input, but the second one will work fine -Return to space center -Use tracking center to take control of the broken kerbal -Observe, kerbal loads on the ladder of the vessel that was exited Note that if you go directly to the tracking center rather than going to the space center first, the kerbal will remain broken. Going all the way back to the space center then using the tracking center to take control of the broken kerbal seems to be the way to "fix" this broken state.

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 0.1.1.0.21572 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 531.18) Summary: Predicted trajectories leaving the SOI of most bodies are incorrect. This affects the manuever plan trajectory as well as the trajectory displayed after burn. The trajectory flips to the correct one after leaving the SOI. I noticed that the map view camera rotates by the same amount as the perceived wrong angle of the trajectory relative to the bodies affected when switching focus between the vessel and Kerbol (or the parent body for moons). The following are the approximate rotations relative to the parent body, these match my experiences for Kerbin, Mun, Minmus and Duna, as well as the screenshots of others I have seen in this thread: Original report: KSP2 0.1.0.0.20892 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 528.49) (Save file link removed, this affects all craft). History: This craft launched from Kerbin, landed on Duna, picked up a stranded Kerbal, and launched from Duna to the east. Now in 200km Duna Orbit. Problem: As can be seen in the video, a maneuver node set up to leave Duna retrograde leads to a planned trajectory of a Kerbol orbit with an AP further out than Duna and PE at Duna (this is wrong). This will also be the case for the displayed trajectory after the burn, right until the craft exits Duna SOI. At Duna SOI exit the trajectory flips to the correct one, with a Kerbol AP at Duna and PE further in (see images - images from a different run than video).

Game Information Steam Early Access (0.1.0.0.20892) Visual settings on HIGH System Information Windows 10 Home (10.019044) Intel i5-7400 CPU ASUS Phoenix RTX 3050 (8GB VRAM) 16GB (RAM) Description of the bug. Shadows from Kerbol appear/disappear depending on the camera angle. This occurs on the poles of a planet, in this case the North Pole of Kerbin. Steps to replicate. Go to the poles of a planet (e.g Kerbin North Pole) Turn the camera around, the lighting should flicker on and off. Attachments

If I'm at Kerbin and want to go to Duna, only Ike is available to set as a target in the map view. What I end up having to do is focus on Ike, set Duna as the target, then focus on the Mun or Minmus - whichever one it lets me pick, then I have to zoom way in to be able to focus my view on kerbin again. This was easy to get around in KSP1 by pressing the ` key, or whatever else you bound it to.

KSP: 0.1.0.0.20893 | Windows 11 | i7-12700 | RTX 2080 After deploying a fairing, it falls straight down shortly after deployment. Video below. https://i.imgur.com/AfmR7uo.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: 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 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.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:

So I have been normally playing ksp 2 and I have noticed that the time it took for the game to save my progress was becoming progressively longer. When it took like 3 minutes to save my game I have decided to look into the folder where it saves the game and I have discovered something horrible. The last save had 1.63 GB, yeah GIGABYTES. I have managed to look inside these files and at the bottom (it did not manage to load as a whole so I did not manage to get to the real bottom) I found a lot of text that was repeating itself (I added the image below). I have no idea what causes this, I have no mods installed nor did I change anything with the game. I really need some help because this is making my game completely unplayable. You can see the images below (most of the text will be in Czech but it's useless anyways so just ignore it): Below is the image of the repeating text in the save file Below is the first image of the save file folder. Below is the second image of the save file folder.

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.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.

So heres the thing, basically every inline mounted auxiliary part such as decouplers, batterys, reaction wheels and cargo bays have bugged drag calculations(including those rounded rear hatches but i didnt feel like making a custom plane just to add it to my testing). Any 1 of these parts will effectively double your drag. These bugs are not limited to only the parts ive tested, as far as i can tell, literally every size and shape of said parts is affected. Ive run a couple of tests as you can see below. Every plane configuration is exactly the same other then parts that are in question added to the plane (original plane parts are white and test parts are orange). First test with base line results: Nr1. Base line: ~360m/s with drag being ~55Kn. Base line v.max ~1000m/s with drag being ~110Kn. Nr2. Same plane configuration, but with added reaction wheel. Plane is unable to accelerate past 350m/s with its drag being ~160Kn. Nr3. Same plane configuration, but with added 1 inline battery. Plane is unable to accelerate past ~340m/s with its drag being ~160Kn. Nr4.Same plane configuration, but with added inline decoupler. Plane is unable to accelerate past ~330m/s with its drag being ~160Kn. Nr5.Same plane configuration, but with added inline cargo bay. Plane is unable to accelerate past ~355m/s with its drag being ~160Kn. Nr6. Ive sized up the plane to see if the amount of drag scales with the size of the craft, and it looks like it basically does: Nr6.1 Base line ~750m/s, drag is ~600Kn. Nr6.2 Base line v.max = ~1100m/s, drag is ~1100Kn. Nr6.3 Same plane with inline decoupler. Plane speed is ~750m/s with drag being ~1050Kn. Plane is unable to accelerate further. All of these drag errors are effectively making it impossible to make xeon ssto's, put any sort of cargo capacity on planes or just have auxilary power or reaction wheels, not to mention the numerous implications it has on rockets.... tho i guess there not affected as much, it just dumsters there efficiency, as every vertical stage is going to effectively double your rockets drag. Hopefully this gets noticed and is fixed relatively soon. :)

These may be minor, but I thought you should know about them. It seems only letters (upper and lower case) are allowed in the Site Name, so no "Minmus Site 1", etc. And since the title is character limited, spelling out numbers is not a great option. I'd think limiting the flag title to only upper and lower case is a bug - though a minor one and really just a nuisance in terms of impact. Site Name is forced into Title Case. If you hold down shift to get multiple uppercase characters only every other one will be uppercase, unless you add a space. Also it's not possible to have an all lower case Site Name, if that matters. A kerbal seems to be able to only plan one flag. Is this a bug or a design choice? There is utility in placing more than one flag, so I hope this is a bug. Workaround: Reboard vessel, do another EVA, and you can plant one more flag. Using punctuation in the Plaque Text (or attempting to use it the Site Name) can cause timewarp! So if you put something clever like "I got here first..." then you'll be timewarping ahead at 4x speed. Similarly, using a comma will decrease timewarp and so may pause the game. If you pause the game due to a comma, then you may be waiting a long time for Jeb to plant that flag once you close the dialog box. To reproduce this bug take Jeb out for a walk and try planting more than one flag.