Moredice

I've experienced this too. Enabling and disabling the fairing's shell, or clicking the fairing edit button and then clicking the green check without any actual edits to the fairing, brings back the colors.

@Anth12 Should this be updated to current version? My report was made after the latest patch.

From what I've experienced, this especially happens when trying to connect struts to an adapter part which has slanted sides.

@Anth12 Looks good to me!

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 22H2 (build 19045.3324) | CPU: AMD Ryzen 9 5950X | GPU: Asus ROG Strix GeForce 1080 Ti OC 11gb | RAM: 32 gb 3200MHz DDR4 In the VAB, while "Center of Mass" indication is enabled, the indicator does not move accordingly as fuel amount is being modified in fuel tanks. One needs to disable and enable the CoM indicator again, pick up another part from the part picker (does not need to be attached to the craft) or detach and reattach any part on the craft to update the CoM's position. How to reproduce: Place two fuel tanks connected with one another. Enable the "Center of Mass" indicator. Right click one tank and change its fuel contents to zero. Observe that the CoM did not move. Either disable and enable CoM indication again, select a new part from the part picker or detach and reattach one of the fuel tanks. Observe that the CoM did in fact move. The screenshot illustrates the issue, the video demonstrates the issue, the craft file contains simply the two fuel tanks from step 1. Included Attachments: Window04-09-202300-20-22.mp4 fuel_tanks.json

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 22H2 (build 19045.3324) | CPU: AMD Ryzen 9 5950X | GPU: Asus ROG Strix GeForce 1080 Ti OC 11gb | RAM: 32 gb 3200MHz DDR4 As the title says: Changing the hotkey for staging only works until the game is restarted. This may apply to other hotkeys too, but I've not tested that. I have previously observed this behavior between game loads without restarting the game, but I was not able to reproduce those conditions this time. How to reproduce: From the settings menu, go into the input menu and change the hotkey for "Activate Next Stage" to right shift. Optionally place a rocket on the launch pad, but this can also be done after the next step. Save and quit the game. Reload the latest (or any) save and launch anything using the staging key that was set. It will not work and only responds to its default key (spacebar). Open the input settings menu again and observe that the setting does in fact read "Right Shift" as set key for staging. To make right shift work for staging again, one needs to go back into the input settings and bind it to spacebar again, then rinse and repeat to bind it back to right shift (which is a little tedious).

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 22H2 (build 19045.3324) | CPU: AMD Ryzen 9 5950X | GPU: Asus ROG Strix GeForce 1080 Ti OC 11gb | RAM: 32 gb The bug occurs when you detach and then attach for example a solid rocket booster (SRB), which was already strutted, to the side of a rocket. Both mirror and radial symmetry behave the same, and with all plural radial symmetry modes (2-8). It does not matter where the struts are attached on the SRB's. It does not matter how many struts there are. It does not matter if the SRB's are attached to decouplers or not. Detaching the SRB from the main rocket and placing it back causes the attachment of an SRB only on the opposite side of the rocket, while the one you were holding remains stuck to your mouse and it has broken free from the symmetry mode. How to reproduce: Place a fuel tank and attach two solid rocket boosters on each side of it, or... Alternatively load the stock vehicle "Stock Kerbal-K1". Place a strut on the SRB's and attach the other end of the struts to any part of the rocket. Detach one SRB, ensure you've enabled mirrored or radial symmetry mode 2-8. Click to place the SRB you are holding. The SRB refuses to attach itself and also refuses to snap to the rocket in this state, instead wanting to clip into the rocket. The SRB on the opposite side has attached itself without issue. The struts all stretch toward the part you are holding, as if there's local symmetry mode on the SRB itself. Click again to place the SRB in order to free it from your mouse cursor. Picking up the SRB again for placing it again will sometimes remove the opposite part, and sometimes not, but the part does attach itself fine. The struts have now become non-interactive (can't pick them up, for example). The screenshot illustrates part of the bug and the video demonstrates the entire issue. The craft file contains the craft seen in the video (craft pasted into text file). Included Attachments: Window02-09-202306-02-58.mp4 SimpleRocket.json

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 22H2 (build 19045.3324) | CPU: AMD Ryzen 9 5950X | GPU: Asus ROG Strix GeForce 1080 Ti OC 11gb | RAM: 32 gb As the title says: Changing the thrust limiter of an engine while having a planned maneuver node does not update the estimated burn time (specifically: the "stop burn time in" value). One is required to either make a tiny change to the planned node, or remove and recreate the node, for the burn time estimation to update itself. Coming from KSP1, it is expected that the burn time is updated when changing thrust limiters while having a planned maneuver node, without having to edit the node. How to reproduce: Enter map mode and create a maneuver plan on your orbital path Observe and take note of the "Stop burn in" value in the burn.timer window Exit map mode and right click the main engine on your craft Change the thrust limiter on the engine to a low value Observe and compare the "Stop burn in" value with step 2 (they will be identical but they shouldn't be) Enter map mode and make a tiny touch adjustment to the node (or remove it and then recreate it identically to step 2) Observe and compare the "Stop burn in" value with step 5, it has now been updated The video illustrates the bug. Included Attachments: Window02-09-202302-55-49.mp4