QuiescentRabbitt

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD Ryzen 7 3700x | GPU: Nvidia RTX 3080 Ti | RAM: DDR4 16GB 3200Mhz When putting a heatshield on your craft in the VAB, you can select how much ablator it has, and lower the amount in order to reduce weight. If you do this, the heatshield will continue to look normal in the VAB, but in flight it will have a charred and burned appearance as if the heatshield was used. If reducing ablator should result in this charred appearance despite it being unused, then it should also appear in the VAB. Reproduction steps: 1. Put a heatshield on your craft 2. Reduce its ablator to near empty. Observe how it looks normal. 3. Launch the craft and observe the heatshield now appears charred, as if it was used.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD Ryzen 7 3700x | GPU: Nvidia RTX 3080 Ti | RAM: DDR4 16GB 3200Mhz In my own testing, ladders placed on crew capsules sometimes claim to be blocked within the vicinity of a heatshield + additional part. This prevents you from deploying/retracting them. This occurs even when there is no clear cause of the blockage. Attached is a craft file with one such ladder. Removing the heatshield unblocks the ladder. It is not even close to said heatshield. Included Attachments: BlockedLadder2.json .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD Ryzen 7 3700x | GPU: Nvidia RTX 3080 Ti | RAM: DDR4 16GB 3200Mhz Despite a fix being implemented into 0.2 intended to improve background vessel performance, background vessels still continue to impact game performance in a very significant way that needs further work. This can be seen in the chart I provided where a save file with 40 satellites around Kerbin nearly halves the frame-rate both in orbit and around KSC. This result is nearly unchanged from 0.1.5 which experienced nearly the same performance hit. As things are now, save files that accumulate vessels from continual play will experience severe performance slow-down. Included Attachments: Mk1PodonLaunchpad40Mini.json

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD Ryzen 7 3700x | GPU: Nvidia RTX 3080 Ti | RAM: DDR4 16GB 3200Mhz Certain conditions in KSP impose timewarp restrictions on the active vessel such as being in low orbit of a celestial body. However, if you swap to the tracking station, these restrictions should be lifted so you can timewarp to a launch window for instance. This isn't the current behavior, instead the tracking station will retain the timewarp restrictions placed on the vessel. In order to get around this, you have to first go to KSC, and then to the tracking station, and only then will the timewarp restrictions be lifted. This is very troublesome as it introduces a significant loading time. I find myself having to constantly do this in gameplay. Reproduction steps: 1. Set up a craft in a situation that imposes a timewarp restriction such as low Kerbin orbit 2. Hit ESC and select Tracking Station 3. Observe that you are unable to timewarp any faster than the vessel could due to it's timewarp restrictions. Here is a screenshot showing the Tracking Station with restricted timewarp. Included Attachments:

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD Ryzen 7 3700x | GPU: Nvidia RTX 3080 Ti | RAM: DDR4 16GB 3200Mhz These issues pertain to both the deleting of the first node causing all nodes to be deleted, and unusual behavior in the properties of consecutive nodes. Node Deletion Reproduction Steps: 1. Create a Maneuver Node 2. Create a Maneuver Node after the first one 3. Delete the first Maneuver Node 4. Observe all nodes were deleted. This shouldn't happen and isn't the way KSP 1 functioned. The second issue is unusual node behavior. Essentially, the second node will not function like a regular node when you attempt to use it. If you were to give the node a lot of prograde, it will say something completely different will happen than the reality of what would happen. It's not accurately predicting what said burn would do. Node Unusual Behavior Reproduction Steps: 1. Put a vessel with plenty of deltaV in Low Kerbin Orbit 2. Set up a Mun intercept with the 1st Maneuver Node which sets you up to burn to Mun orbit. 3. Place a second Maneuver Node on your Mun Intercept periapsis, and attempt to input enough retrograde to create a circular orbit. 4. Observe how the second node doesn't allow you to create a circular orbit, and instead predicts unusual and incorrect burn behavior. Both of these issues currently prevent the usage of consecutive maneuver nodes, but they are essential for setting up more complex burns, like consecutive gravity assists. I've attached a screenshot showing how attempting to create a node that would leave me in Mun orbit instead predicts some incredibly unusual orbital behavior. Included Attachments:

I have to agree. By the time that you get the tech that makes this mission not overwhelmingly difficult and complex the science gain is worthless. I'd consider myself a very experienced builder and I couldn't figure out a good way to do it without 3.75m parts.

I can confirm, this mission completed for me when I planted a flag on Duna

They make minmus ice-cream cookies

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 7 3700x | GPU: RTX 3080 Ti | RAM: DDR4 16GB 3200Mhz Severity: Medium Frequency: Medium Description: I've experienced this bug multiple times, where using 50x+ timewarp in LO above The Mun results in sudden craft destruction upon exiting it. I'm not sure what causes it, although every craft has been a lander of some variety. It's only been around The Mun, I cannot confirm whether it may occur elsewhere. Steps To Replicate: Load RUD.json set Timewarp to 50x for a few seconds, then stop it. The craft will disappear and the mission failed screen will pop up, saying the vessel was destroyed. Note: Alternatively, send any lander up to low Mun orbit, timewarp to 50x, and then exit. Repeat until craft explodes. I'm not certain, but this may be a start. Media: Additional Information: After some further testing it was determined this is a combination of 2 bugs; Extended Landing Legs are Causing a Massive Kick in the Retrograde Direction when in Low Orbit After Disengaging Time Warp, and Control pod not destroyed, yet forced to Flight Report upon crashing/destroying parts of the vehicle

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 7 3700x | GPU: RTX 3080 Ti | RAM: DDR4 16GB 3200Mhz Current game behavior disables your ability to make maneuver nodes if it believes your ship to have no deltaV. This also can occur when you have plenty of fuel in the form of monopropellent, which the game doesn't actually calculate the deltaV for. It can also cause you issues if the deltaV calculation has an error and believes your ship has none, even though you can still burn fuel. This seems intentional on the surface, but is prone to causing lots of frustration. Even if it works exactly as intended, I could want to set up a node before refueling my ship to get an idea on the potential fuel cost. How to replicate: Launch any ship in a configuration where the game detects you have no deltaV, and attempt to create a maneuver node. It will pop up an error. Included Attachments:

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 7 3700x | GPU: RTX 3080 Ti | RAM: DDR4 16GB 3200Mhz Severity: Medium or Low. The issue cannot be completely mitigated, only partially. Frequency: High. It occurs seemingly every time. Description: When creating a plane, the game attempts to detect whether or not to invert the pitch of any placed wings based on their placement relative to the COM (Center of Mass). This results in problematic behavior where you have a plane that is designed with it's main wings placed behind the COM in order to achieve the correct lift profile, but the game decides to invert it's pitch control on it's own. You can invert the entire wing, but that will result in an inverted roll profile. This system of automatically inverting the pitch needs to be adjusted, or the player needs to be given the ability to invert pitch in the advanced controls part menu themselves. It can be very frustrating to build a plane that requires wings behind the COM to fly correctly, but doing so results in wings with inverted controls. I've attached a craft file that contains two identical planes, one where the wings are in front of the COM and it has the standard pitch behavior, and the other where the wings are behind the COM, and it experiences inverted pitch behavior. EDIT: I looked into how KSP 1 handles this exact situation, and just like KSP 2, it inverts the pitch of any wings behind the COM. However, most people who built planes in KSP 1 made use of the mod FAR (Ferram Aerospace Research), which allowed you to invert Pitch, Yaw, and Roll. So technically, this is problematic behavior in KSP 1 too, but it was addressed by a mod that many people used. Included Attachments: PitchControlPlanes.json

Edit: Submitted my own bug report which should be merged which explains the issue in-depth. I'd delete this reply but I can't.