Search the Community

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: windows 11 | CPU: i5-10300H | GPU: rtx 3050 (laptop) | RAM: 16gb My rover is having weird problems while trying to climb a mountain. It's spinning, sometimes it will sort of "teleport" into a different position. See video for a better description. Included Attachments: Ksp22023_12.22-18_53_30_02.mp4

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: 7900x | GPU: 4070 ti | RAM: 128 GB Anth requested that i made a bug report on this ------------------------------------------------ Anth Edit: Thanks to @Stephensan for posting this. Note the focus of this is on the visual glitch rather than the physics glitch that is applied. In my testing sometimes the visual glitch occurs and the physics one doesn't appear to so I wanted to have two separate issues posted on the forums ------------------------------------------------ In this case, i been dealing with a bug with rovers (wheels in general) where every 1000m~ in this case "at 2000m (more between 2000m and 2100m) it glitched one of the rear wheels and then the physics glitch happened as well." causing the craft to lose control, How to recreate bug Create a rover with any wheels Go to another planet either using teleport or getting there by rocket Start driving After 1000m the bug will start happening What does the bug do Glitches the wheels upward to "100%" fully compressed suspension In a "single frame" (extremely quickly) it resets to the original position Possible that the game physics decided that it should move the craft due to seeing that the wheels "went up" causing a phantom force that shouldn't be applied to the craft Craft loses control causing it to crash How does it affect the player Driving normally as a player should, starts off as a visual bug, that is related to the 1000m terrain glitch however, with how wheels "collide" with the ground gaining phantom forces when going in the ground this bug should be for the visual side, however it is noted that it still can have the 1000m phantom force You cannot expect when the bug trigger and cannot know if which way the bug will throw you if it decides that it should.. It hinders users driving long term on any planet causing users to need to use a lot of quicksave/adjust autosave to sub 10 seconds when going above the speed of 15-20m/s due to how frequent the gets due to the speed and distance. The video is "Supercut" of 5-7 minutes of just driving and the bug triggering and causing a crash and me reverting save, the parts cut out is(Unimportant) besides just the distance made and was just normal "straight line driving". OG video can be sent via YouTube upon request. Imnotthatinsnaea.mp4 What's included: Player.log Ksp2.log Campaign Save Known issues (thank you anth) Null colliders (i think this is on every quicksave/autosave it has one) Saves throws the "back" out for some reason i think this is due to the craft and not due to the bug, and the issues are separate due to being able do this with MANY other machines. Teleported to Duna from the KSC using cheats throwing up errors Included Attachments: TESTINGTESTINGTESTING.zip Player.log Ksp2.log

Reported Version: v0.2.1 (latest) | Mods: Commnext, Microengineer, Trim Controller | Can replicate without mods? Yes OS: Windows 10 | CPU: i7-10870H | GPU: RTX 3070 | RAM: 16GB COM for angled tailplane (Tail Connector B) is offset such that having the connector pointed to the side places its mass in the middle whereas pointing it up/down offsets its COM to either side (demonstrated in video). This has the result of giving any craft including this tailplane the tendency to roll if it is used as intended. Expected behaviour would be that pointing the tailplane to each side would shift the mass that way. Included Attachments: offsetCOMwrong.mp4

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows | CPU: AMD Ryzen 5 5600X | GPU: 3080 TI | RAM: 32GB Issue: Placing Landing Legs on Trusses Causes Camera Disconnect and Drops The Legs after triggering a stage. Severity: med/low, apparently there is some way to "reconnect" the camera, but it is very tedious Frequency: high, reproducible 100% Description: When placing landing legs on trusses, once triggering a stage after the initial launch, will cause the legs to fall off the trusses and "disconnect" the camera from the craft, meaning the craft will start to distance itself ever so slightly from the camera location until it is entirely out of view. Furthermore, the landing legs will simply drop off the craft when the stage is triggered. I have attached a rocket that will achieve this effect 100% of the time. The reason I know the landing legs on the trusses are to blame is that I modified the rocket until the bug no longer occured, which happened once the landing legs were placed directly on the methalox tank. If required I can upload a video, but as said you should be able to reproduce this 100% of the time. Included Attachments: BUGGED_VEHICLE.json

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Famille 10.0.22621 64 bits | CPU: AMD Ryzen 5 5600H with Radeon Graphics (12) | GPU: NVIDIA GeForce RTX 3060 Laptop GPU (6009MB) | RAM: 16236 Only a part of the rcs work on my craft although they are in the same position. This bug has not reappeared in another save with the same craft. Included Attachments: onlyapartofthercswork_logs.zip Anth Edit: Looks like its the shroud of the heat shield is partially blocking the RCS that are connected to the decoupler. Steps to Reproduce: Be in the VAB with nothing in it Grab a M1-3 Gumball Below attach a heat shield of the same diameter Below attach a decoupler of the same diameter Attach 4 RV-105 RCS ports to the decoupler down slightly from the middle of it Below attach a X200-8 tank to the bottom Launch Turn off SAS Turn on RCS Use Q or E to use roll Note: Only 2 of the RV-105 RCS ports are working. Video Evidence: 2023-10-31 00-03-23.mp4

Reported Version: v0.2.1 (latest) | Mods: Commnext, Microengineer | Can replicate without mods? Yes OS: Windows 10 | CPU: i7-10870H | GPU: RTX 3070 | RAM: 16GB The Diverterless inline air intake has 1t of methane fuel but doesn't show up in resource manager. Included Attachments:

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: win10 | CPU: i710700k | GPU: rtx2060 | RAM: 32gb "Invalid research location" for no reason for RSCM-01 Sample grabber. Requirements were fulfilled according to part info, yet it was impossible to perform - therefore, impossible to test if the arm will work when it arrives several years later at its destination. Included Attachments:

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i9 9900K | GPU: 3070ti | RAM: 32GB Video Evidence: Steps to Replicate: Launch EnginePlateColliderTestCraft.json Decouple Rotate 180 degrees using W to match the video Credit: @QwertyHpp gets 100% of the credit for this. They gave me everything I needed to test this. Original Bug Report:

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 7 6800H with Radeon Graphics. | GPU: NVIDIA GeForce RTX 3050 Ti Laptop | RAM: 40 GB Now, the title explains it all, but I wasn't sure if this was supposed to happen, so here we go. On the exit the atmosphere mission, I was returning to Kerbin after a nice short flight to 100km and on the way back, my ablator wasn't draining and the heat shield wasn't charring either. Now, this is important because my rocket's parachutes only deploy if the ablator is half depleted, so... Revert to save Val.

Reported Version: v0.2.1 (latest) | Mods: Community Fixes v0.13.0 for KSP2 v0.2.1 | Can replicate without mods? Yes OS: Windows 11 Professionnel 64-bit (10.0, Build 22631) (22621.ni_release.220506-1250) | CPU: AMD Ryzen 5 2600 Six-Core Processor (12 CPUs), ~3.4GHz | GPU: NVIDIA GeForce RTX 4060 | RAM: 32768MB Hello I noticed that for the second time Jeb has teleported himself from the list of available kerbal crew to an active rover. The first time Jeb teleport himsleft to a rover on Minmus, for the second time it's in a rover on Mun. Rovers are different and have different command parts. I noticed that the teleportation occured while I was returning a crew of 4 kerbals from a long mission. I have mod installed in my game, but the first occurence of the bug occured with any mod install in 0.2 version of KSP 2. The severity of this bug is quite low since I can return Jeb with teleportation in the cheat menu, but I first have to find him among all the craft with available space for crew in my game.

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 10 | CPU: N/A | GPU: N/A | RAM: N/A The "Forward" control orientation of the Mk2 "Tuna Can" is incorrect. The orientation is rotated such that the ground appears to the left of the viewer, not below them, e.g. as with the Mk1 can. Included Attachments:

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 5700X | GPU: RTX 3050 | RAM: 32GB Parts in question are batteries and solar panels inside a fairing. The batteries are fully inside and are 100% occluded by the fairing. However, while launching through the Kerbin atmosphere, the parts are getting heated up close to the point of destruction. Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: BepInEx, Commlines, Community Fixes, Flight Plan, Hide Orbits, K2D2, Maneuver Node Controller, Node Manager, Orbital Survey, Patch Manager, SpaceWarp, UITK for KSP 2 | Can replicate without mods? Yes OS: Windows 10 Home 19045.3803 | CPU: i7-13700KF | GPU: NVIDIA RTX 3060 12GB | RAM: 32 GB I'm not sure if it's always happening, but it seems to happen every time I launch the specific rocket in the video, as well as happening with other rockets occassionally. The vessel will suddenly have many of it's parts slightly offset from each other mid-flight, without apparent reason. I've also found that this causes the craft to no longer be able to correctly/accurately find SAS points (prograde, etc.). It is off by a degree or two, but there's no indication that the craft is attempting to correct this (no movement on the Pitch/Yaw/Roll indicators). EDIT: On vessels affected, it seems to happen after a non-physics time warp. EDIT 2: I believe I've identified what causes the issue. It seems to be associated with the Tiny Reaction Wheel (TRW-0625). I isolated it after carefully removing each part from the vessel, flying it above 70k, then doing a few short time warps at 0 thrust. Issue doesn't occur when the Tiny Reaction Wheel is not on the vessel. Included Attachments: 2023-12-2923-45-33.mp4 OrbitalRelayProbeMk8.json

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: amd ryzen 7 3800x3d | GPU: AMD RX 7900XT | RAM: 64 GB DDR5 @6000MHz Parts inside of the mk2 cargo bay seem to experience drag. There are 2 craft files attached to this report, one with a cargo bay with a light payload, and one with the cargo bay replaced with a short fuel tank of greater mass. The craft with the payload bay has significantly greater drag than the craft without a payload bay, as evidenced by the fact that it cannot reach a speed greater than 370 m/s, where as the craft without the bay is easily able to push past that speed and reach orbit, despite being heavier with the same external geometry. Included Attachments: SateliteTest1.json TestVehiclenopayload.json

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Core i7-8750H | GPU: GeForce RTX 2070 | RAM: 16 What I expected to happen: In low Ike orbit, at high game time, solar panels on vessel in sunlight collect EC What actually happened: Solar panels are "Blocked by Ike" below 120km altitude Steps to replicate: Load minimal example game save .json (attached) Notice solar panels are listed as "Blocked by Ike" Interestingly, this did not replicate with a UniverseTime near zero, so I pasted in my main save's UniverseTime (almost 15 years elapsed) and then I was able to reproduce the minimal example game save above. The underlying issue is likely causing a similar error on Jool (which I also encountered) and other bodies, possibly related to high game time: Included Attachments: BugreportIke.json .ipsImage { width: 900px !important; }

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: Ryzen 5 5600x | GPU: 3070 LHR (OC'd) | RAM: 64gb Anth1256 requested me report this bug.. The abort Button does not function in its entirety when putting items in the AGM.. How to replicate it. -Craft File In Report What Happens? Pressing the Abort Button only does half the actions that it is supposed to do, in this case, only decoupling the craft, but not activating the engines only AFTER pressing it the a second time. Edit: Upon further testing, it works ONCE properly then it goes to this bug. Urgency? Eh, i be rather disappointed losing Kerbals in science mode due to the Abort Button not functioning properly, but as of right now Anth only really requested me to report it. Included Attachments: Tacobautit.mp4 WgateverTgusUs.zip

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 Pro 64-bit (10.0, Build 22621) | CPU: Intel Core i9-10885H | GPU: NVIDIA Quadro RTX 5000 Max-Q | RAM: 64GB Is anyone experiencing issues with Escape towers fired with the Abort action group? I've tried making both a Mercury clone with sepratrons and an Apollo clone with the bottle rocket without success. If the motor(s) and coupler are in the same action group only the coupler fires. If I put the coupler in say the Brake action group and the motor(s) in the abort action group, they work pressing Brake followed by Abort. I would expect an abort action should fire both the coupler and motor(s) together. I confirmed this is the behavior in KSP 1 (Coupler and escape tower in the abort action group, fire together). This is an un-modded installation of 0.1.5.0.28834 Homer Included Attachments: NewWorkspace.json

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: win 11 | CPU: ryzen 7700x | GPU: radeon 6750 xt | RAM: 32gb When switching the mode between afterburner and cruise for the panther engine, the thrust is locked in place. you can abuse this behavior by switching the mode constantly to allow the engine to function at full throttle even when you leave the atmosphere completely. This obviously can only be useful for leaving kerbin or laythe. I am not sure whether it uses fuel or not. there may be other engines that have mode switching features that take time and might have this problem too. I believe the RAPIER is fine since it's an instant switch. suggested fix: when the mode switch animation plays, set thrust to 0, when the animation is finished, reset thrust to the expected level I recorded a 3 minute video of me sending a plane on escape trajectory out of kerbin and posted it to reddit. https://www.reddit.com/r/KerbalSpaceProgram/comments/1bnzvlh/how_to_get_to_space_with_just_airbreathing_engines/ rapidsave.com_how_to_get_to_space_with_just_airbreathing_engines-pybjle3k2mqc1.mp4

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 (64 bit) | CPU: AMD Ryzen 9 5900X 12-Core Processor | GPU: NVIDIA GeForce RTX 3070 | RAM: 65450 Mb Description: I believe (99.9%) that I caught the Starlab producing samples / data for the wrong biome during time warp. I had a Starlab in a low polar orbit of Kerbin (about 113km) I had done the experiment for Water, Ice and Desert biomes successfully I was doing the experiment for the Moutains biome ("Running requires Mountains") I was at 10x time warp The experiment timer reached zero when I was in a region where the biome changed rapidly Instead of getting data / samples for the Mountains biome I got data / samples for the Highlands biome I had not been running the experiment for the Highlands biome. I was able to repeat the experiment for the Mountains biome and complete it successfully. I suspect that there may be an issue with the Starlab producing data / samples for the biome that the vessel is currently over when the timer reaches zero, rather than the biome that it was running the experiment for and my vessel changed biome at the very last instant, giving me the erroneous science. This is likely to be very difficult to replicate, so I am submitting this in hope that a dev may have a quick inspection to see if there is anything obvious and if anybody else notices the issue they can add to this post.

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: Intel i7 | GPU: Intel iRISxe | RAM: 32gb I had several engines explode on my craft for no reason. I had 4 rhino engines on detachable fuel tanks that surround a central core that had 1 tuba engine. All but 1 of the rhino engines randomly heated up and exploded, both while the central tuba was running and when it wasn't. Included Attachments: Spicat Edit: Video Evidence: 2024-03-18 22-07-38.mp4

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel i7-12700K | GPU: AMD Radeon RX 6800 XT | RAM: 32GB I built a rocket with a set of 4 RCS (RV-105) and for some reason 2 of those RCS parts on one half of the vessel are permanently disabled. Did some testing and it only happens when the parts are installed on the 45 degree points along the longitudinal axis. If I install them on the 90 degree points they work fine.

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 5 5600 6-core Processor | GPU: NVIDEA GeForce RTX 3060 | RAM: 15.91GB I encountered this bug where landing gear can be stuck in "blocked" even when the blockade is cleared. What I found even more weird, is that at some point it can happen so that, even though the craft is fully symmetrical, one gear may get blocked while its mirrored counterpart is not.... Second video: https://cdn.discordapp.com/attachments/938349432943038475/1148280664769167540/Kerbal_Space_Program_2_2023-09-04_17-32-39.mp4 Included Attachments: KerbalSpaceProgram22023-09-0417-19-53.mp4 RovyStray.json

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 5900HX | GPU: GeForce RTX3080 | RAM: 16gb Issue: When you have any type of wheel inside of a cargo bay, when decoupled the wheels do not seem to have physics collisions with the cargo bay. There is no friction for them to drive on or off and just stay stuck in place. After a bit of testing it seems like the steering parts of the wheel objects will collide with the interior of the cargo bay but the actual wheels (tires) do not see them as a valid physics object. Correct Behavior: The wheels should interact with the interior of the cargo bay to allow a rover to drive on and off via a cargo ramp. How To reproduce: Place a docking port and any wheeled rover vehicle inside a cargo bay, when undocked the rover will clip through the bottom of the cargo bay unable to move on its wheels. Tested these cargo bays: Mk3 CGR-LRG Mk3 CGR-R CBL500 Wheels Tested: LY-10 RoveMax S2 RoveMax M1 RoveMax TR-2L RoveMax TR4 Probably an issue with the other cargo bays as well. Included Attachments: KSP2WheelsW-Cargo.zip

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: Ryzen 5 3600 | GPU: 3070 LHR (OC'd) | RAM: 64gb The J-X4, J-404, J-20, J-90, J-33 engines have a bug when sometimes when a sudden lost of air it puts itself in the opposite position of mode/reverses thrust.. Get any of these parts Turn on engine Turn off intake of air Either three things happen; A: It works normally B: It stalls the engine and puts it in the opposite position of where it was C: It double stalls and nothing happens and it works normally How often it happens? about 80% it did it for me, but when needing to mass test/video it showed they worked only about 20% to produce this bug thus no video will be shown... Need to test it separately. I recently did a bug report with the J-33 but upon further testing, and OTHER users reporting it aswell, i decided to report it.. Video Evidence: Desktop2023_09_01-21_27_35_01.mp4

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: Ryzen 5 3600 | GPU: 3070 LHR (OC'd) | RAM: 64gb quite easy, both modded and unmodded gameplay.. Note: also happens to all other jet engines, see merged report Grab the J-33 Engine Put the engine in the a situation where it was on and then it loses air (or cut air from turning off a inlet) Engine "spools down" and then puts itself in reverse. Additional Info: it sometimes puts itself back if it double stalls.. annoying and happens a lot on start up on runway/accidental turn ons in space etc. Included Attachments: Desktop2023_09_01-21_27_35_01.mp4