Search the Community

KSP2 Version Info: 0.1.1.0.21572 OS: Windows 11 (10.0.22621) 64bit CPU: AMD Ryzen 9 5950X 16-Core Processor (32) RAM: 130992 GPU: NVIDIA GeForce RTX 3090 (24340MB) SM: 50 (Direct3D 11.0 [level 11.1]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, BGRA32, RGB111110Float, RG32, RGBAUShort, RG16, BGRA10101010_XR, BGR101010_XR, R16 Description of the bug. Expected Behavior - When looking down through a deployed parachute, that has a gap, you'd want to see what is directly below the parachute (ground, water, capsule, kerbin) Observed Behavior - When over water the view shows ground and parachute shadow, instead of water (see image below). Even over land, its not showing the correct land that is directly underneath. Steps to Replicate - Deploy a parachute 1000m from ground, view from top down. Look through the gaps in the parachute. I did this with a non-radial chute. Not sure if the same thing happens on all types of parachutes. Fixes / Workarounds (if known..) - unknown A list of ALL mods. If the list is long, please consider using a spoiler window. Other Notes / Screenshots / Log Files (if possible..)

Patch one broke my game. One of two things happen: 1) The game fails to load to main menu and a secondary window with the ksp2 logo opens then crashes game. 2) The game gets to main menu but crashes when I attempt to load a campaign file or create a new campaign. Secondary ksp2 window with logo also appears here before the crash. Attempts at solution: I have attempted to verify integrity of files via Steam, uninstalled/reinstalled ksp2, updated steam. None have worked so far. I do not have any mods installed, nor have I altered any files.

KSP Version 0.1.1.0. Operating System Windows 10 CPU Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz 16 GB RAM GPU Nvidia GeForce RTX 4070 Ti Description of the bug. Expected Behavior Normal take-off from Kerbin with a rover with a landing can as cocpit Observed Behavior At about 22km there is a physical impulse downwards. You can see this in the condensation trails. The wheels of the rover are torn off. The rocket is destroyed. Steps to Replicate: Build a Rover with landing can Whether MK1 or Mk2. Connect it with a stacking operator, underneath a smaller stacking operator. Put the lander construction in a cargo cover. Fixes / Workarounds (if known..) No Rover to take with you A list of ALL mods. None, all Stoke Other Notes / Screenshots / Log Files (if possible..) https://imgbox.io/ib/OTz9Qg1zDB https://imgbox.io/ib/kzF8dx0gLl https://imgbox.io/ib/xZw6xdX6eP

The previous bug where you could not name ships with the letter M is now when you name workshop items. I've seen this happen to me twice, so it is replicable. Its the bug where pressing M takes you to the map

I've noticed that the mk2 fuel tanks seem extremely under capacity. Assuming the relative sizes between parts has carried over from KSP1, which looks to be the case, then a mk2 tank has slightly more than double the internal volume of a 1.25m tank of the same length. However, the current mk2 fuselage tanks have the same fuel capacity (and dry mass) as the same length 1.25m tank. And the mk2 to 1.25m adapters have 3/4 the capacity of the same length 1.25m tank despite having much more volume, comfortably above 50% more volume than the 1.25m tank. For comparison, the 1.25m tank has 2T of fuel, the .625m to 1.25m adapter has 1.2T of fuel (which is spot-on according to my math), but the1.25 to mk2 adapter has only 1.5T of fuel, barely more than the next size down in adapters. Then there's the mk2 to 2.5m adapter, which is a bit harder to calculate, but clipping 1.25m tanks into it suggests it may also be at half capacity. I'm not quite sure what to make of the mk2 to mk3 adapter yet, since it is even trickier to measure and that might belong in a discussion on how underfilled the mk3 tanks are, but the mk2 to mk3 adapter definitely seems more underfilled than the rest of the mk3 tanks. This is why this looks like a bug to me, because it looks like being at half capacity afflicts the whole mk2 parts family. This has the effect of making mk2 stuff behave really draggy because they have more surface area and volume, but less fuel and mass than the same length of 1.25m tanks, and more drag, less fuel, and less mass are a perfect combo for a poorly performing plane that must be built larger than it has any right to be. This was a problem in KSP1, but players lived with it because the adapters wasn't quite as bad as in KSP2 is at the moment, mk2 stuff looks cool, 1.25m tanks could be added to make up the bulk of the functionality of the craft, and because mk2 parts had no competition in KSP1. But in KSP2, the drag and fuel capacity of the mk2 parts is a big deal, since mk2 stuff now has to compete with 2.5m planes due to the new 2.5m cargo bays. I could understand if the devs decided that the mk2 parts shouldn't be filled to their full geometric volume because they are a more complicated shape for a fuel tank, will have higher heat tolerance, and have some body lift, luckily 1.8x or 1.6x the current values for dry mass and fuel would result in nice round numbers. I'd like to see at least 1.8x, but the parts will still be semi-usable with 1.6x their current values. Side note: mk2 parts were really draggy in ksp1 yet had less than 1/3 the body lift that their horizontal area suggested when measured, seems like it had something to do with both the large but lightweight mk2 fuel tanks creating lots of drag and generating extra drag from the lifting surface they had to simulate body lift, I'm not sure if that's been changed for KSP2, but in the end, the aerodynamics will need to be fair for these parts to compete against planes made from cylindrical tanks and cargo bays. Anyway, devs, please fix the mk2 part fuel levels (and dry mass), I think it's important this be done soon, before players get too used to building with the bugged fuel tanks.

I’ve been messing around with trying to piggy back satellites to orbit with a mk2 SSTO. (Think how the SR-71 carried the drone, except the plane gets to orbit before launching the payload) But it seems putting even a small mk1 size space craft on the back causes some ridiculous drag. I built the launcher plane first and it blasts through 440 m/s without breaking a sweat. But with the mk1 craft piggy backed on, it struggles to hit 300 m/s. I know cargo bays have been thought to be an issue but I have none on either craft.

As pictured below, I thought that this would have been patched out. I was streaming this mission on my twitch channel, where I have the whole vod of numerous bugs still present after the update yesterday. https://imgur.com/B1R6oyO Here's the link to the image. Sorry about that.

KSP Version: 0.1.1.0 Operating System and version (Windows 10, Windows 11): Windws 10 CPU and GPU models, any other system information which could be relevant: CPU, Intel i7 @3,6Ghz, GPU, Nvidia RTX 4070 Ti, 16 GB RAM Description of the bug. I have the bug that since the patch the radial decouplers no longer hold on the main body of the rocket. I use 6 XL decouplers in the asparagus system. Even with struts the whole thing does not hold and the structure fails. A list of ALL mods. If the list is long, please consider using a spoiler window. I don't use MODS, and the joint strength is on stock.

Whenever an autosave is loaded, the game freezes when the tooltip: "Never leaving Eve" Appears.

when a kerbal goes on eva, the command pod it exits spontaneously decides it no longer wishes to exist and explodes

KSP Version = 0.1.1.0 Operating System = Windows 11 CPU and GPU models, any other system information which could be relevant = intel 13700K, RTX 4090 Description of the bug. Expected Behavior: When extending the Wheels, it shouldn't create any forces. Observed Behavior: When finishing the extending/deploying animation, the wheels seem to snap from a compressed state to a uncompressed state. This also seems to cause the part attached to the wheels to lose a lot of its velocity instantly, creating a strong pulse of force inside the rocket, potentially ripping parts of (e.g. wheels on the Wings). Steps to Replicate: Take the premade K1 rocket, put two LY99 roughly in the middle of it. and launch. Once in the air, retracting and extending the wheels to trigger the end of the extension animation. This causes the Part attached to the wheels to be instantly slowed down, visibly stretching the rocket parts apart. The snappping from compressed to uncompressed can be demonstrated, by building anything standing on the LY99. When the animation ends and the craft sits on the wheels, it is catapulted upwards, by the "uncompression". Notes: The same effect is reproducible with all sizes of retractable wheels, though the smaller they get, the smaller the forces seem to be. Also as a note, the Gforce at the top right jumps towards 0, remains there for a short while and then jumps back, at the end of the extension animation.

Hello, System Info per Rules: Version is KSP2 0.1.1.0.21572 (vanilla), I am on Windows 10 using a RTX 2080 and Ryzen 9 5900X. I just encountered multiple bugs while flying a jet with afterburning Panther Engines, they are: One of the two engines has its Nozzle expand again after switching modes (as expected), the other one does not. Both Engines are locked at exactly one power setting of 77.49kN, despite the Change in Altitude and Speed which normaly would mean decreasing thrust with more altitude and increasing thrust with more speed. After passing 20.000m in Altitude, both Engines suddenly cut out (without the thrust decreasing before) only to enter a very quick cycle of activating and de-activating again (although they of course should not work at all at this high altitude). When the craft glides back below 20.000m, the Cycle of stopping and starting stops, only for the Engines to be "Methane-Air Deprived" (with plenty of fuel on bord and while low in the atmosphere) while in afterburner or "Nominal at 0.00kN" after trying to switch back to Cruise-Mode Saving and Re-loading also does not help (although it detatched the wings ion this particular case). To better follow these points, I have recorded the flight. The Problems start after engaging the Afterburners via Action Group at 0:37 in the Video Link: Feel free to ask if you have any Questions.

As seen in provided screenshots, I have an intersect with the mun, which then ejects me back around kerbin, for another intersect with the mun. Current Trajectory (Intersect #1): I am unable to create a maneuver plan. Future Trajectory (Intersect #2): I am able to create a trajectory (for some reason?) This simply seems like a mix up in the code between which trajectory the buttons are available. so hopefully an east fix? Note: this is directly after updating to the first patch. PC specs are in a previous post of mine if required. Steps to recreate: get an intersect with the mun, which then gives you a gravity assist for another intersect with the mun, this will show you your current intersect in BLUE orbital lines, and future intersect in ORANGE orbital lines. Images: https://ibb.co/QJ0b8Hy https://ibb.co/y48RjF1 https://ibb.co/QM2NLnr

Hello, KSP Version 0.1.1.0.21572 Windows 11 Laptop with an i7 1280P and a desktop GTX 1080 Ti as eGPU When orbiting at fairly low altitudes the camera begins to spam messages because it can't decide which setting it should use. It's at potentially not safe altitudes, so I can't really blame it for panicking. Expected Behavior: Decide for one setting camera, you are trained for spaceflight, so behave like that Observed Behavior: See the screenshot below Steps to Replicate: Go to a very low orbit around a celestial body (I just tried it on Moho so far) Fixes / Workarounds (if known..) No mods Screenshots: Also the probe just crashed into the surface because it altered the orbit while writing this post (is there a secret atmosphere on Moho?)..

Description of Bug: Clicking on the area next to an item after using the stage Delta v pop out in the VAB will result in the staging item disappearing. Steps to Replicate: Click the Delta V pop out While in VAB, then click on either the fuel lines or the empty space. This will cause the stage item image to disappear Fixes / Workarounds: Pull off then reattach the affected part to bring back the image in the staging list. Images: Before/after The mouse is hovering over the decoupler, however since it has been clicked it does not appear in the list. KSP Version: 0.1.1.0 OS: Windows 10 Home edition CPU: Intel i7-9700 GPU: NVIDIA GeForce GTX 1660 Ti RAM: 16 GB Mods: none

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.

Parts in flight stay highlighted even after reloading a quick save, but disappears after reloading the quick save when loaded from the main menu or after restarting a the game.

Even after several tries, after restarting from main menu and game, it detaches as a separate craft and becomes a debris. I had my engines and landing gears directly under the wings too.

Im not sure if its the 4 engine plums that are causing it or something else and the fuel lines are not currently working for me. not sure if anyone else has come across this problem plus after the R.A.P.I.E.R. test there another bug about the engine working, but not working during time warp (using fuel but going know where) and the camera separating from the ship but i would stick to the fuel lines, camera, and R.A.P.I.E.R. if these are going to be fixed \/ video demo

I was playing the game as normal and i crashed my plane, following the crash i wanted to go into the VAB and improve my design. I improved it, but the game didn't allow to launch it using the launch button which also red out that i had 0 delta-V. I went to the KSC to select the runway and launch it from there but the vehicle i had saved using the save button in the VAB didn't show up. I returned to the VAB and found that the "Revert to VAB", "Recover vehicle", and the "Revert to launch" buttons were there, I clicked "Revert to launch" and the game froze with the screen as seen on the screenshot below.

So there is bugs, yea we expected some. but looking at the most common bugs raises concerns that they need to go "back to formula" see what outers think is simply a annoyance bug points to much larger issues. and there are a few "gotcha's" First off is simply user interface, how key and button input is handled. but also how it is processed. an example is when writing a ship's name, M key takes you to a map view. this shows inputs are global instead of mode specific and/or the mode swapping is not handled properly. then there is the lack of response from interface when crafts of extreme loads are being launched, lets say you get time to pass once every 10 seconds, pressing esc you wait up to 10 seconds to see map. this is first a ticking issue, shows the menu is not calculated independently and have to wait for the world render cycle to complete before it is acted upon. the menu us a slave function to rendering. this should not be so. next there is time itself. time should pass once every second, no lag or load should reduce that. any function should be a slave of time and use "time passed since last action" as part of its calculations. instead of relying on each action's output to calculate the next, formula's should allow passing of any amount of time and be able to adapt to those. an example is rotating to a position over time, instead of needing to take action at every passing unit of time, a simple formula can be used to see how far it would be towards its goal giving this amount of time passed. so if a craft would need 8 seconds to rotate from prograde to retro, and you are on 10x speed, then simply assume that in the passing of 10 seconds it made the rotation and set it as such, and deduct the propellant it would have used for that. simple this will fix rotation and acceleration not functioning over time warp of any kind. then as for physics, this should be simplified where you can pre-calculate it take the assembled craft in its current state, then do a linetrace from it from every direction, get the relevant angle of the hit and assign a value to it. do an additive overlay for control surfaces and other moving parts. now simplify it into center of drag, and center of mass use this along with speed to calculate everything else needed, bit you now get to treat it as a single part and not 100's of parts, and only needs to recalculate if the assembly changes. you can further pre-calculate each part and in the final calculation use those as an is visible basis. you're welcome. the current setup looks to prioritize visual priority of execution should be: 1 - time 2 - interface input and response 3 - control input and response 4 - vehicle movement 5 - actual rendering, here going LOD or even complete basic Low poly will be acceptable as long as time keeps passing, input responding and actions happening reliably. next assembly again looks like rendering is prioritized. it looks like everything is as movable and lighting is dynamic, this is wrong and even bad for performance. treat every placed object as static, use directional light and pre-bake light as much as possible, then calculate dynamic shadows for the single combined model. also VAB should have better uniform lighting with less shadows, it's a rocket factory after all so can assume its getting at least 4x light from each side and from on top, this makes baking light easier. as for placement sockets, sure snapping to anything is a function now, but how about if we mid-mouse-button select something to then prioritize snapping to the object that we are focusing our view on? also you dont have to make an entire assembly as moveable to attach it, simply rendering a 2d version of it for the current view and using a depth offset, use that as a card for the moveable part, and hide the static once you render the card, then you dont even need movables. there is also collision issues with many parts, the simple solution is to do a visual interrace and get tangent at location, use that instead of collision, so a surface mount item will mount to the visual outer surface. these are just a few bug fixes and performance booster i would have looked at. again this is speculative and only the opinion of a play test, and I have no actual knowledge of how the code actually functions

Version: 1.12.4 Windows Problem: When attempting to load any active vessel for the first time after starting the game, the craft violently shakes with an "approaching G-Limits" warning and explodes. Reloading the last quicksave returns the vessel to normal, at the cost of any progress since then. However, for some craft, the game just crashes upon attempting to load (again, only after first starting up the game). Mods installed: Reproduction steps: Start up game, Enter tracking station, Switch to any active vessel Crash Logs: