Search the Community

If the user corrupts the save name in the save dialog it is not refreshed with the current name when the dialog is closed and reopened. It is easy to lose track of ship version numbers with this bug.

KSP 0.1.0.0.20892 Windows 10 Ryzen 7 5800H RTX 3060 Laptop In KSP 1 there was a setting for the move/rotate tool to snap to a grid and angles relative to the root part, so you could get two parts to be perfectly aligned in position and orientation no matter where you initially put them. In KSP 2 the "AlignmentAssemblyButton" actually still snaps relative to the part you're moving's original position, so you cannot use it to move parts to the exact center of the vehicle, or get them aligned perfectly vertical or horizontal or to a certain snap angle.

KSP Version: 0.1.0.0.20892 Operating System: Windoze 10 because FPS in Linux is currently too poor on my potato CPU, GPU, RAM: i7-2600K, GTX 1650, 16Gb DDR3 Description of the bug: Placing any OX-4L solar panel on any payload inside a fairing causes the drag reduction effect of the fairing to disappear. Expected Behavior: OX-4L part should not add to craft drag when inside a fairing, nor should it remove all drag mitigating effects a fairing is having on all the other parts inside the fairing. Observed Behaviour: When an OX-4L is placed on a payload inside a fairing the Total Drag (as shown on the F12 AeroGUI) changes to the same value as if the fairing were already jetisoned. Steps to Replicate: Build a simple probe with a poor aerodynamic profile. My probe was 1xOKTO, 1xPB-X150, 1xST-Micro-4 truss and I put 5 small SP-S06 structural panels on the front of the probe oriented flat side on to the direction of flight. Launch this (on a BACC Thumper with fins for example) with no fairing and at 5 km altitude record the Total Drag value from the F12 GUI dialog. My result, Total Drag = 198.8 kN Now cover over the same probe with a fairing AE-FF125 "Cockleshell" and reduce the amount of argon in the payload to bring the mass down by the an amount equal to the fairing mass. Launch again same thumper and at 5 km observe the Total Drag. My result, Total Drag = 24.5 kN Now finally add a OX-4L solar panel inside the fairing attached to the truss and launch again. My result, Total Drag = 255.1 kN Optional exercise 1: Launch again with OX-4L but pre-jettison fairing in VAB. My result, Total Drag = 237.7 kN Optional exercise 2: Launch again replacing OX-4L with solar panel OX-4W and closed fairing. My result, Total Drag = 26.0 kN (i.e. no problem) Fixes / Workarounds: Don't use the OX-4L until the bug is fixed, instead use only OX-4W solar panels. A list of ALL mods: It doesn't matter as I have replicated without mods but I do normally use Space-Warp, Maneuver Node Controller, Sticky Orbit Markers and Micro Engineer, also "JOINT_RIGIDITY": 1500000.0, in PhysicsSettings.json Other Notes / Screenshots / Log Files: None this time

Delta V calculations seem dramatically inaccurate, and or stated requirements to go somewhere appear to be drastically overexaggerated. I don't know if this is intended to provide a buffer for less experienced players or in error.

KSP Version: 0.1.00.20892 Operating System and version (Windows 10, Windows 11): Windows 11 Pro 22H2 CPU and GPU models, any other system information which could be relevant: Intel Core i7-8650U, NVIDIA GeForce GTX1060, Microsoft Surface Book 2 Description of the bug. Expected Behavior: land and stay on Mun Observed Behavior: land on Mun, navigate to tracking center, return to controlling the craft that is stationary on Mun, but it is now "falling" on the interior of the Mun. After a while is now near the space center (see screen captures) Steps to Replicate: unknown Fixes / Workarounds (if known..): none A list of ALL mods. If the list is long, please consider using a spoiler window: none Other Notes / Screenshots / Log Files (if possible..) First time noticing that is is not on the surface... Google Photo Falling Now is seems to have found a new home? Interesting scenery inside Mun!

EVA Broken.

I was on Dres and went in the menu to the KSC. I opened up the Tracking Station and my ship was gone!

so far everything works until I try to revert to VAB then it just sits there spinning bat does nothing.

To possibly re-crate this bug/glitch: Land a vessel on the Mun or Minmus then launch off While in a sub-orbital or orbital trajectory: create a maneuver and try to change it (even slightly) - observe that the maneuver node doesn't move no matter the change, but the "Required Delta-V" is displaying tiny requirements on Dela-V with decimals (an extremely small Delta-V required) The vessel's "Situation" in JSON save file now changes from 'Orbital' to 'Landed' Write a topic about the bug on the forums This bug can somehow affect the previous save files of the same quick saved lander vessel but doesn't change their "Situation" but somehow "infects" or "inherits" this bug. A way to fix this bug for the player: Re-load the save when you were still landed Do not leave the game until you are done from that forsaken vessel. You are a prisoner of the Kraken until you leave this to it.

This in turn glitches out the main vessel that was attached on even though the decoupled part has already detached, but feels like the part is still attached to the vessel and its still pulling and acting with drag and weight, therefore slowing down and misguides the rocket even though decoupled part is now registered as a debris and is kilometers away.

Image: Screenshot of the staging

Landed space craft also jumps or spawns several meters above the ground after time warp.

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods used: None Expected Behavior: Whenever KSP determines that x4 time warp is necessary it should be physics warp just like a planet with an atmosphere. Observed Behavior: First it's in standard unlocked timewarp When it gets closer to the ground but still a fair way up it will drop to 4x Timewarp (non responsive to controls) When it gets much closer to the ground it will change to physics warp (4x) From the ground: Its physics warp from the ground up to a certain altitude and then It changes to time warp but maintains a lock at 4x Until it gets high enough and locks to full timewarp Video Evidence: This shows what happens from the ground on the Mun. https://youtu.be/MVMaa7iuK2s First it starts with the 4x physics warp and becomes unresponsive (changes to timewarp) at 3300m (sealevel) maintaining 4x Conclusion: I definitely would have expected this to be physics warp all the way up to timewarp being fully unlocked but its not.

KSP Version: 0.1.0.0.20892 Operating System and version: Windows 10 Pro 21H2 CPU: Xeon E5-1620 0 @ 3.60 GHz GPU: AMD RX 6700 XT Description of the bug. Expected Behavior Landing legs do not impart force on vessel when deployed Observed Behavior Landing legs impart force on vessel when deployed, causing orbit change and tumble Steps to Replicate Create lander with LT-1 legs, deploy landing legs near surface of Mun/Minmus Fixes / Workarounds (if known..) None A list of ALL mods. If the list is long, please consider using a spoiler window. None Other Notes / Screenshots: I only captured one event, but it's happened twice at the Mun with different vessels and the one time I visited Minmus Imgur album

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods used: None How KSP1 Works Without Robotics Which Keeps Parts Permanently In Their Original Positions: Whenever KSP1 saves: Only the original part positions from the VAB/SPH are saved Whenever a craft leaves physics/render range: KSP1 when leaving physics range will snap all parts to their original positions. Then when it moves out of render range those coordinates are held in memory for when the game saves. How KSP2 Works: Whenever KSP2 saves: The current real time part positions are saved which are different to the original parts positions due to the stress on the parts by gravity or by other means. Whenever a craft leaves physics/render range: I flew in a plane until the KSC disappeared and then flew back a few times. There is some form of drift but it's not exactly like the game saving and loading. Video Evidence of Drift Over Multiple Saves or Visits to a Craft: The following video shows the worse of this situation. Drift over multiple saves or visits to the craft. Its accumulative. (5 Quicksaves+ 5 Quickloads) I have timestamped it so the loading screens can be skipped to save time. End of video I undocked the weight and the craft stayed bent which doesn't happen if it's undocked on launching it for the first time. https://youtu.be/yYUN4lqQZsE Screenshots of Extreme Drift after 1 or 2 Quicksaves and Quickloads: What it's like in the VAB: And this is after 1 or 2 QuickSaves and QuickLoads. This is permanent. Obviously I used a heavy weight to force the issue: Craft Files from Video and Screenshot: https://www.dropbox.com/s/bdlg15vpdn5hg3r/KSP2%20Drift%20Testers.zip?dl=0 Conclusion: Drift via Gravity: If the player wants to reuse crafts again and again the parts will drift over time until they looked warped or are entirely useless Because the main drift is caused by gravity imagine what a craft on Eve will end up looking like. Drift via Wobbling Parts: If a rocket is wobbling or flexing while in space and the player or the game saves, the rocket will now stay permanently in a flexed state on reloading. Additional Information: For further information I recommend talking to @JPLRepo (Jamie Leighton) who is one of the developers for KSP2. KSP1's 1.12.3 which fixed docking port drift (introduced in 1.12.0) and added a way to counter drift to some degree when locking was his work.

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods used: None Video Evidence: Kerbal will contact the surface at 43.1m/s horizonal speed without momentum affecting it and ends up just standing. https://youtu.be/P756NwqFSCo First Compliments to the Developers: I love what has been done here. It's amazing. So smooth and it seems almost natural to be able to travel horizonally and hit the ground at 43.1m/s and just be standing at the end of it. (a bit below 60m/s is actually the top speed) Truly its surprising how well this works. Suggestions for Animations to make it "seem" a little more realistic: If slow enough the Kerbal just staggers. If a bit faster the Kerbal falls onto its face and then gets back up and then dusts themselves off. If a lot faster than that the Kerbal falls over onto its face and travels a small distance before stopping and then gets up and dusts themselves off. Also there could be on rare occasions that the Kerbal actually does a sort of crouch and do a slide to a heroic stop like the movies (or nearly makes it) Additional Information: The rag dolling in KSP1 wasn't really that enjoyable so let's not go back there please

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods used: None Video Evidence: First look to see that I activate the engines. Then I stop after 2 seconds into the burn and the timer still keeps counting down. https://youtu.be/3h5p-kF6N9c Possible Expected Behavior: This is more complicated because what if the player only drops the throttle to 50% or 80% because once that happens the timer is inaccurate. Alternative possibility: A way around it might be that the timer just stops and turns to another colour indicating an error on the part of the player? Additional Information: This wouldn't matter very much if it was the same as KSP1 where dV is a much more important indicator of how a maneuver is progressing which I made another bug report for:

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods used: None The following explanation is to show why the required dV actually should be counting down on the Burn Timer. An experienced Kerbal player (well...me at least) does the following for executing a maneuver node burn typically (KSP1): They start the burn at 100% throttle at the appropriate time. They are watching the required dV reducing as the fuel gets used up. Towards the end of the burn they drop the throttle for finer control. They watch the dV display until it hits exactly zero but are also watching the actual maneuver to see if it matches the predicted one. Video Evidence using KSP1: This follows the above 4 steps. https://youtu.be/9DLHwIUxFP8 Video Evidence using KSP2: This is less precise than KSP1 primarily because the deltav isn't reducing like KSP1. https://youtu.be/aJxAZ9nnexc Additional Information: In the case of a maneuver node execution 1 second is a very long time. Recommended actions: Have the dV display reduce as the burn progresses as its being used up like how KSP1 does it. If dV passes below 0 show negative numbers to show how far to recover using RCS etc. Have the dV display on the burn timer a little bigger and reduce the size of the time remaining.

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods used: None Note this Happens if it's Via a Maneuver Node of if There is no Maneuver Node. When a SOI is inside another (Bugged): Mun inside Kerbin (Craft is anywhere within Kerbin SOI) Minmus inside Kerbin (Craft is anywhere within Kerbin SOI) Tylo inside Jool (craft is anywhere within Jool SOI) Screenshot 1 Showing the Lack of Trajectory (Kerbin Orbit to Mun): When a SOI isn't inside another (Works Correctly): Mun and Minmus (Craft is within Mun SOI heading towards Minmus) Tylo and Jool (Craft is within Jools SOI heading towards Tylo) Screenshot 2 Showing Correct Trajectory (Mun Orbit to Minmus): Save Files From the Screenshots: https://www.dropbox.com/s/jawws84aovxokb4/Saves.zip?dl=0

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB It's a small issue but let's say that was a command pod being upside down every time it was taken from the parts menu... For a plane it needs to be rotated 90 degrees every time it's taken from the parts menu. Video Evidence: https://youtu.be/fBzGamd-juI

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Current Behavior: As long as a craft is close to the KSC and the camera is looking at it the CPU will be close to maximum. Sorry I don't have any AMD screenshots. I only have intel CPUs. Following Screenshot shows CPU maxing out: This screenshot shows CPU out of render range of the KSC:

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB There are three things happening: 1. Pixelation 2. Flickering in the pixelation 3. A kind of light shadow that is affected by the camera angle that covers from the left of the screen to the right. Video Evidence: Note quality might need to be increased to see it clearly