Davidian1024

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: Low (pretty minor issue) Frequency: High (present in all scenarios) Description: In the Escape Menu within the Vehicle section within the Revert to Launch option there is an extra space before the word Launch. Included Attachments:

There's definitely some sort of change that happens around 22km above sea level. This has been a thing since before patch 3. Maybe as far back as day 1 of early access. If I just fly a rocket straight up through this altitude I always see some sort of visual artifacts as I pass through it. Usually with the exhausts of the engines and the contrails. If I'm flying a particularly unwieldy craft that's under a lot of stress as it passes through this altitude I find that there's also some sort of shock that the craft experiences. Parts might break in the process and the whole craft might be destroyed.

I'm also seeing this since patch 3 was released. The clickable area of each of the SAS buttons is now smaller than the button visually.

Oh, sorry. It's probably because I copied the text into a text editor to reduce the amount of typing I have to do.

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 (This makes using the Dawn Engines anywhere from problematic to useless.) Frequency: High (I cannot figure out how to work around this.) Description: When running the Dawn Engines the electric charge stored in all batteries (including the ones in pods, etc) behaves incorrectly. Running the Dawn Engine with not enough electric charge generation to fully supply them causes the batteries to drain to empty as you would expect. While simultaneously generating enough electric charge to supply all running Dawn Engines the following incorrect battery behavior occurs. All of the batteries will only charge up to a certain level. If they were full when you started running the engines they will all drop to this level. If they were below it, they will charge up, but only to this level. This level seems to be dependent on the craft's amount of electric storage capacity, generation capacity, amount of drain and time warp. I've observed this behavior while generating the EC from both reactors and solar panels. Time warp seems to exaggerate this effect. Time warp high enough and the level seems to work out to a negative number and the batteries end up emptying even though the craft is supplying more than enough power to run all of the engines. This time warp component is why I say this can make the Dawn Engine's useless. The Dawn Engine's need to be run over very long periods of time, making time warp essential. In the past I thought decoupling had something to do with this, but now I don't think so. I launched a craft without any sort of decoupling ability. No decouplers, stack separators or docking ports. And I still observed this behavior. Here is a zip file containing a craft and a save that can be used to demonstrate this effect. The craft is meant to be flown straight up out of Kerbin's SOI. No need to muck around with gravity turns, orbits, etc. Once you're fully out of Kerbin's SOI switch the Mk2 command pod's control orientation to reversed so that the Dawn's are pointed the right way. Dawn EC Bug.zip Included Attachments:

When KSP2 was first made available via Early Access, there was an AeroGUI that could be brought up with F12. I forget which patch got rid of it, but it's been gone for a while now. Is it coming back? Or perhaps an alternative is in the works? Something like what we had in KSP1 with all the little arrows on the individual parts?

Zippo.zip

So, today I tried to reproduce this again, and it's working fine. I'm getting a target velocity close to zero while parked next to my target. FWIW, the target label is grey. @Anth12Is it supposed to be blue? A separate display bug perhaps?

FWIW, this issue is gone for me again. And it's probably been over a day since I've noticed it.

Ok, I see that my "target" has grey text instead of blue. I've never noticed that when things are targeted. Maybe that indicates what's going wrong? Either way they were definitely behaving as if they were targeting each other. All the navball markers seemed to be what I'd expect. I had both craft set to have the docking ports set as "control from here", and they were both targeting the docking port on the other craft. That's basically how I've always done it.

Got my immediate family NASA certified eclipse glasses. We're lucky enough to be getting a total solar eclipse over our city next year. I love the NASA branded packing tape.

I think the sale makes sense. After this patch the performance is actually quite good. I think now's a great time to get more people onboard the KSP2 early access train.

Good example of how fixing one problem can break something else. I think it was a good idea to slow the release cadence. Not saying I want to slow it further. I think finding the right pace is difficult. Looking forward to what's next.

Quite often you'll realize you need to change your staging, action groups, etc. during flight. It's great that you can change them, but it would be wonderful if there was some way to merge those changes into your craft.

Here's an example where I'm not sure if things are working as they should or not. At around 2:21 of the video I'm at my PE which is about 15km. AP is dropping, but slowly. I don't think I should've been able to get back to space. But, I'm not sure. https://drive.google.com/file/d/1Ly0wLfmq087IUqvuSbVuf-W5DWrUrpc3/view?usp=drive_link

FWIW, I can easily see how this would be missed. If this dragless effect is truly limited to the command pod parts, I think it would actually be unlikely to encounter it. It's not normal to reenter with nothing other than a command pod. You're probably going to attach at least a parachute. ...or a heat shield. ...maybe RCS thrusters. If those parts still have drag. Then I think you'd never notice. Also, saving/loading before it would happen has seemed to prevent it from happening for me.

Wow, utilizing this bug I just "skipped" off of Kerbin's atmosphere. Was coming in from a high apoapsis. Something like 6Mm. Periapsis was around 8km just before entering the atmosphere. When I got down to around 5km I started going up. As in my trajectory seemed to be getting deflected away from Kerbin rapidly. I'm finding that I can't create a save that captures the issue. So, saving/loading might be an awkward workaround. I saved the game just before entering the atmosphere so I could try to reproduce the effect. After loading the save, the above atmosphere skipping did not happen. Everything seemed to behave normally. I came in very fast and my AP and PE both dropped the way I would expect and I crashed into the ocean. Here's a craft I created specifically for setting up this scenario: Mk1 Lack of Drag Demonstrator After launch I started a very hard gravity turn once the craft had gotten to about 60m/s. I simply set SAS to prograde relative to orbit once I reached that speed. Just before the clydesdale ran out of fuel I switched to surface prograde until I was out of the atmosphere. I did not decouple the clydesdale until after I was fully out of the atmosphere. Then once I reached the AP I used the cornet section to raise my PE to around 8km. Then I set the impulse of the decoupler to 2kN to prevent the decoupling from changing my PE too much. Then I timewarped until I was just above the atmosphere. Just before entering the atmosphere I set SAS to surface retrograde. I had to adjust the authority limiter on the Mk1 to 20% because SAS seems wonky right now. I think that might be another bug.

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.

Ok, this audio issue has returned for me. Looks like a simple reboot wasn't a true fix.

FWIW, the TR-3 Bulldog doesn't seem to be affected by this issue. Currently re-entering Kerbin's atmosphere in nothing but that pod, and it's aerobraking very well.

As best as I can tell, you can't run the engine with it in retracted mode. When you activate it, it extends. When you deactivate it, it retracts again.

FWIW, I did a quick test with the Mk1 Raven cockpit. Quickly built a super simple rocket plane to get it up to speed. Decoupled the Raven from the rest of the craft and yes it seemed to have zero drag on it as it sailed along the runway. I'm imagining a new challenge that could come from this. (until they fix the bug) Lowest orbit over Kerbin.

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: 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:

The performance seems alot better after this patch. Everything is feeling much snappier.