Search the Community

The flight controls pretty much snap to their maximum authority, this leads to excessive stress on the aircraft and oscillations with SAS enabled. The control surfaces need to move more gradually, ideally this would also be tweakable by the player. In the FAR mod for KSP you can enable a feature that adjusts the maximum deflection based on the vehicles speed, like a real aircraft FCS would. Also would be a good improvement.

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Kubuntu (via Proton Experimental, up to date at time of post) | CPU: Ryzen 5 3600 | GPU: Radeon RX 5700 | RAM: 32 GB Title: TD-06 (extra small decoupler) or TS-06 (extra small stack separator) will, when attached to ST-Micro-1 (tiny cube strut), fall off at any decoupling event. Specs: Severity: Medium (breaks certain vessel designs, otherwise invisible) Frequency: High Description: Place a cube strut (ST-Micro-1) on a part, either surface attach or node attach. Place a TD-06 (arrow pointing either direction) or TS-06 on the cube strut's node. Then place a decoupler anywhere else on the vehicle (again, arrow pointing either direction). (My test vessel includes some other structural parts.) The extra parts on each decoupler are not necessary (though see next caption regarding arrow direction of the trigger). I've pointed the arrow on the TD-06 towards the beam on this craft to disambiguate "decoupler fires" from "decoupler just falls off." However, I believe every permutation of arrow direction exhibits the same behavior, so long as the "trigger" decoupler actually causes a part to fall off the craft. Take it out to the launchpad, fire the "trigger" decoupler, and the TD-06 falls off. Note that there is no ring, in violation of the expected decoupling behavior (because it didn't decouple). Additionally, the part is still considered to be a member of the vessel, as demonstrated by the fact that it appears in the PAM and can be triggered. When multiple instances are involved, the parts which fell off are seen to not collide with one another (further demonstrating that they are still members of the vessel). So far as my testing has revealed, this behavior occurs only between the ST-Micro-1 and either the TD-06 and TS-06. It appears to be triggered by the activation of any decoupler or separator, but not when the vessel is modified by a part exploding on impact. Included Attachments:

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: windows 11 | CPU: 13700k | GPU: 3070 | RAM: 32gb Specs: 13700k, 16 physical cores, 24 logical cores, 5.2ghz, rtx 3070, 8gb vram, 32gb ram Severity: low Frequency: high Description: Go into VAB, place at least one plane part (Ship orientation needs to be horizontal but only way to do that is start with plane cockpit). Hold down middle mouse button and slide up or down. Middle mouse click on any part to recenter camera. Hold right click and drag to orbit and camera immediately jumps to whatever distance you panned away, either left or right. Video evidence: recording2023-06-24062100-1_5wwk7Jl0.mp4

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Linux Ubuntu 20.04.6 | CPU: AMD Ryzen 5 3400G | GPU: NVIDIA GeForce GTX 1080 Ti | RAM: 16GB Specs: (Obtained from Steam via Help > System Information) Severity: Med (Causes craft to look wrong and ugly.) Frequency: High (Always occurs) Description: When TOOB parts are duplicated the variable length fairing section becomes offset from the base ring section. This gap increases with each duplication. There should never be a gap between the base and the fairing of the TOOB. Steps to reproduce: Start a new vehicle in the VAB. Select any TOOB part from the structural section of the parts manager. Duplicate the TOOB: With the selection tool hold the Alt key and click on the first TOOB. Attach it to the fairing end of the TOOB. Duplicate again starting with the original TOOB. Attach to the fairing end again. Observer that there is a gap between the faring and base of the 3rd TOOB. Continue duplicating the entire assembly and attaching the duplicate to the top fairing end. Observer more gaps and also observe that the gaps get wider with each duplication. Video Evidence:

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: win10 | CPU: Ryzen 5 3600 | GPU: 3080 | RAM: 32 The fairing generated by the large engine plate has returned after loading a save. It should be gone, since that stage and engines have already been initiated through the staging process. Included Attachments: LargeEnginePlateFairingRespawnsonload_logs.zip

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Linux Ubuntu 20.04.6 | CPU: AMD Ryzen 5 3400G | GPU: NVIDIA GeForce GTX 1080 Ti | RAM: 16GB Specs: (Obtained from Steam via Help > System Information) Severity: High (This essentially makes TOOB parts unusable in anything other than the vertical orientation.) Frequency: High (Always occurs) Description: When I adjust the length of a TOOB part via the slider in the parts manager, the position of the part attached to the fairing end of the part is adjusted incorrectly. when it should be adjusted to match the location of the end of the TOOB. Steps to reproduce: Start a new vehicle in the VAB. Select any of the TOOB parts from the structural section of the parts manager. Rotate the TOOB to any angle other than vertical. Attach anything to the fairing end of the TOOB part. Adjust the length of the TOOB fairing via the slider in the parts manager. Observe that the length of the TOOB's fairing changes as expected, but the change in location of the part that is attached to the TOOB does not match the change in location of the end of the TOOB. Video Evidence:

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 64-bit | CPU: AMD Ryzen 7 4700G | GPU: NVIDIA GeForce RTX 3060 Ti | RAM: 16GB (16384MB) Tried launching a small ship using a new recoverable (spacex style) launch vehicle, suborbital trajectory (ap 92k, pe 61k) with the ship boosting itself into orbit (ap 92k, pe 75k). Controlled the launcher all the way down, landed decently but fell over (very spacex style)(bad terrain didn't help) and I recovered it. Went directly to the tracking center and saw that the ship had left in orbit was in a widely different trajectory (ap 427k, pe -235k) and already at an altitude of 404k (first two screenshots). I looked at the map occasionally when landing the launcher and didn't notice anything unusual with the ship then, so I'm assuming the velocity of the craft was locked in while on rails for orbit but the recovery of the launch vehicle made the orbit simulation freak out, as the numbers roughly add up to the same velocity. Forgot to screenshot the map view but the orbit was very circular. Third and fourth screenshots are after loading a quicksave and boosting to the same periapsis as the previous one, hoping to replicate the bug. Failed to replicate the bug due to another landing failure (even more spacex), where the probe core of the launch vehicle exploded upon impact after toppling over. Opened the tracking center and saw that the ship was in the orbit I left it in, but when I pressed M to leave the tracking station (idk why you can press M to leave) the fallen over launch vehicle started flying away by itself (SAS bug? Shown in attached video) until I sped up time and it disappeared immediately, somehow removing the orbiting space ship too. Not entirely sure if it's the same bug in different clothes or two unrelated bugs. Did also discover a few other bugs I've not seen before during the same flight, will post reports for those as well. Included Attachments: KerbalSpaceProgram22023-06-2517-30-36.mp4

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: 11th Gen Intel(R) Core(TM) i7-11700F @ 2.5GHz | GPU: NVIDIA GeForce RTX 3060 | RAM: 31.68 GB Airbrakes sometimes deploy in the wrong direction. I found two different ways this can happen. If you launch a craft, return to VAB, and try to launch again some airbrakes will deploy the wrong way. Two workarounds to this are to 1) take the airbrakes off and put them back on, or 2) when in the VAB save and reload the craft. Another time the airbrakes deploy the wrong is when they are in a place where they act as control surfaces. If you take the attached craft and roll, one of the airbrakes will deploy the wrong way going through the craft. Included Attachments: whyworkspacesexist_____.json

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i9-10850k | GPU: RTX 2060 Super | RAM: 24GB 3200MHz System Specs: Severity: Low Frequency: High, consistently reproducable The nozzle was extended and firing. After reloading, the nozzle is retracted and the plume appears where it normally would. The screenshot was taken after reloading a different save than the attached one because I overwrote it on accident, but the bug persists in both of them. Included Attachments: quicksave_1.meta

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Kubuntu (via Proton Experimental, up to date at time of post) | CPU: Ryzen 5 3600 | GPU: Radeon RX 5700 | RAM: 32 GB Title: When in the VAB, the camera can be zoomed "in" past the orbit focus point. Specs: Severity: Low Frequency: Certain Description: Enter the VAB. Use the scroll wheel to zoom in. Continue to use the scroll wheel to zoom in, passing the vessel. You can go all the way to the wall on the far side of the VAB. You can even go past the wall of the VAB, but it's just a white void so I don't see much point in including a screenshot of that. The camera resets to a vaguely reasonable minimum distance as soon as you use RMB or MMB to orbit it. If you zoom past the wall and into the white void, you cannot zoom back out of it; the only way to return the camera to usability in this case is by orbiting it. Included Attachments:

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Linux Ubuntu 20.04.6 | CPU: AMD Ryzen 5 3400G | GPU: NVIDIA GeForce GTX 1080 Ti | RAM: 16GB [Anth12 Edit: Adding Save Files + Video for 0.1.3.2 Repo and 0.1.4.0 Fix Confirmation] --------------------------------------------------------------- Happens When Undocking From a Craft and then Re-targetting. Video Evidence: 0.1.3.2 Bug Replication: https://youtu.be/XPd0cSTucoI 0.1.4.0 Working as intended: https://youtu.be/pUm5xS7mnO8 Steps to Replicate in 0.1.3.2: Load quicksave_6.json Undock the craft with the pod Target the craft undocked from. --------------------------------------------------------------- Specs: (Obtained from Steam via Help > System Information) Severity: Med (This feels like it's on the high end of medium. I can see it causing docking to be difficult if not impossible, as this information can be critical to performing docking maneuvers.) Frequency: High (This has happened every time I've performed docking maneuvers since version 0.1.3 came out. It wasn't happening prior.) Description: The velocity display to the left of the Navball does not appear to display the speed relative to the target when target velocity is selected. In the screenshot below I parked the lower vehicle about 3 meters away from the command pod at the top of the picture. To be sure I was right, I left them about this far apart for at least a couple of minutes. The display continued to show the command pod being 3 meters away. This tells me the velocity relative to the target should be close to zero. But as you can see in the screenshot it's showing 5484m/s. Which is close to what my orbital and surface velocities were at the time.

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 10 | CPU: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz | GPU: NVIDIA GeForce RTX 2070 | RAM: 16GB Severity: Very low, just a text change Frequency: High, always happening but still very minor Description: There is a confirmation box when you destroy a craft now (very nice change). But, it's missing a question mark, because it's a question, see below: Included Attachments:

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 Home | CPU: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2.59 GHz | GPU: NVIDIA GeForce GTX 1660 TI | RAM: 16 gb So... I found out that if I undock vehicles while on pause, when you unpause the vehicle disintegrate. Video for reference. Sorry the quality is a bit bad.

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: windows | CPU: ryzen 7 | GPU: Nvidia Geforce GTX 1660 | RAM: idk This has happened to me sporadically but seemingly randomly, unfortunately I can't tell what causes this glitch. When going for a spacewalk, my kerbal will sometimes be flung away from the craft at high speeds as soon as they exit the vehicle.

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 10 | CPU: i7 10700K | GPU: RTX2060 | RAM: 32GB "Landed" a craft on its engine, didn't really plan it but it stood stable. Went on EVA, moved away from the ship, as soon as the distance hit 50m the ship bounced off the surface. Included Attachments: fli.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.

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 Attach an AIRBRAKE to any part. Launch the vehicle. Press Q/E for rolling. Result: AIRBRAKES will deploy with the roll input and even exceed their angle limit doing so. See video and bug package file for more details. Included Attachments: BUG124.mp4 BUG124_logs.zip

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 5 3600 | GPU: Radeon RX 5600 XT | RAM: 32GB After picking up a strut from the parts menu, the symmetry icon appears greyed out and cannot be changed until I put the strut down. This is not an issue with other radially attached parts. The workaround is to change symmetry before picking up the strut. Severity: Low Frequency: High

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: Ryzen 5 3600 | GPU: MSI 3080 | RAM: 32 gig Specs: Severity: Medium- The workaround that was available has regressed. See the follow-up for more details. Frequency: High- following this build process results in the bug every time. Description: Make a plane using an Oscar-B tank, copy and paste. Wings flip. Included Attachments: NewBugs0001-11861.mp4

It's a major bug for me and really annoying, the maneuver doesn't behave correctly: KSP Version: v0.1.2.0 Operating System and version (Windows 10, Windows 11): Windows 10 CPU and GPU models, any other system information which could be relevant: i7-10700 / RTX 2070 / 16GB RAM Steps to Replicate On an orbit, place a maneuver and use the normal arrow. Execute the burn and you will see that the path doesn't match with the maneuver path. Description of the bug. Expected Behavior In ksp 1, when we use the normal arrow and execute the burn, the maneuver icon move on the navball. Thus, it results in a path which is not just normal (a orbit with a different angle) but also prograde (a orbit with a different angle AND a different apogee). Observed Behavior Here in ksp 2 the maneuver icon on the navball stay on the normal icon, it doesn't move, so when following this icon we obtain the path of a normal maneuver (just change the angle) In ksp 2. Either the maneuver should move when executing the burn like in ksp 1, or the maneuver path should show the path of just the normal maneuver (so not like in ksp 1). Fixes / Workarounds (if known..): Not a fix but => not using the maneuver, which is a shame A list of ALL mods. If the list is long, please consider using a spoiler window: No mods Other Notes / Screenshots / Log Files (if possible..) Here a video to better understand the problem (I only burn Normal because the maneuver icon is not moving): https://i.imgur.com/2MviOiD.mp4 I don't know if it's just the normal and anti-normal, but I think the problem is the maneuver icon not auto correcting. I think I have this bug since release.

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 11 | CPU: Ryzen 9 5900HX | GPU: 6800M | RAM: 32GB DDR4 3200MHz All of the UI elements with an amount of transparency, including the hamburger, Kerbal viewpoint, Staging window, the text map telling you which celestial body you are in their sphere of influence etc. have artifacting constantly, in both VAB and in-flight views. The artifacting is less prominent when in space, but that may just be different things that are less visible artifacting. Included Attachments: 2023-06-2218-07-20.mkv

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

0.1.2.0.22258 Win 11 22H2 i7-12700KF RAM 32.0 GB RTX 3080 Ti At 23317m (Mun) and 27097m (Minmus) there is a noticeable camera shift, orbit starts it's well know decay, and ships start blowing up (Mun) or Orbit changes drastically (Minmus) if they warp into, or below this point. Spent some time testing, so the numbers are solid and very repeatable. Both of these limits may have already been identified, There's many, many threads on decaying orbit and crashing out of warp, but I haven't seen the actual numbers called out yet.