WingC3

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 11 23H2 | CPU: AMD Ryzen 9 3900XT | GPU: nVidia GeForce 3900 | RAM: 32GB The retractable ladders always produce their full drag (as if they are deployed) even when they are retracted. This drag amount is also quite extreme, preventing craft from flying straight in without significant gimballing or reaction wheels. This definitely should not be the case for retracted ladders. Launch the top part of this craft (above the final docking port) to see what I mean. Included Attachments: LaytheLander.json

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 11 23H2 | CPU: AMD Ryzen 9 3900XT | GPU: nVidia GeForce 3900 | RAM: 32GB This issue has been around since before 0.2.0 based on a search of the archive. In my case, the craft is in a 23km orbit around Ike and in clear sunlight. The issue exists for at least 25% of the circumference of Ike. In other areas it is either legitimately dark or the solar panels DO work. But for 25% of the orbit, the craft is in clear sunlight but the panels say it is blocked by Ike. (Just for clarity, it's not blocked by Duna either.) Included Attachments: .ipsImage { width: 900px !important; }

I've had this once as well. I think it MAY relate to entering physics range while in timewarp, but I've not been able to reproduce it. It may also be that the game doesn't see the two craft as entirely separate entities?

Yeah, I tried it on a very shallow Kerbin entry and it didn't survive. The engines on the lander handled the heat better just being exposed. Really looking for this to be fixed as I have an awesome Laythe lander that would be GREAT with it, but won't make it without it.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 11 23H2 | CPU: AMD Ryzen 9 3900XT | GPU: nVidia GeForce 3900 | RAM: 32GB It looks like someone overlooked the text for the high orbit radiation survey for Duna. I can only speculat ethat that's because on most players' first trips out there, they won't have it unlocked yet. In any case, as you will see in the screenshot. The text is a placeholder. Included Attachments: .ipsImage { width: 900px !important; }

Yeah, I've had a couple of parachutes deploy and a couple of parachutes not deploy even on the same stage. And even clicking the manual deploy button does not work. The only option is to reload.

More heating, in and of itself is not an issue. However, a constellation of other items are combining to make it an issue: 1. More heat at an equivalent altitude as compared to KSP 1 (ok on its own) 2. Less drag at an equivalent altitude as compared to KSP 1 (also ok on its own, but problematic in combination with 1) 3. Inflatable heat shield and fairings NOT working as expected. The inflatable heatshield is overheating and the fairing is not actually shielding components within it. All three of these taken together renders aerocaptures basically impossible at this time. If that wasn't the goal then I think at least 2 of these need to be fixed.

I don't think this is a bug, I think they changed it to work this way intentionally. However, I would agree that this is a poor way to indicate to the player that a part is clipping. They should have some kind of textual warning instead.

And to be clear, this IS NOT just a VAB UI bug like the one that causes all stages to show 0dV in the VAB, but shows values in flight. THIS issues actually persists into flight.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 11 23H2 | CPU: AMD Ryzen 9 3900XT | GPU: nVidia GeForce 3900 | RAM: 32GB For reasons I have been unable to determine, craft in the VAB will sometimes begin showing 0dV for all of their stages. Reloading does not resolve the issue, and separating and re-attaching parts doesn't solve it either. I have observed a few things, though, that may help: 1. The issue does not persist to the launch pad. Loading the craft there will display dV values correctly. So, it is unique to the VAB. 2. If you select the vehicle and copy it to a new workspace, dV calculations are done correctly. 2. It does not affect all assemblies within the same craft file, it can affect only one of them. (See attached screenshots and craft file: one vehicle is affected while the other is not.) So this appears to be an issue with workspaces containing more than one assembly. 3. It MAY have some relation to attaching one assembly to another and then separating them again, but even then, not all assemblies are affected. 4. In the deltaV info for the stage, it does not show a planetary body AND does not allow you to select one. So I peaked into the JSON, and saw that this was reflected there too: "StageID": 0, "IsActive": false, "DeltaVSituation": { "CelestialBody": null, "IsAtmosphere": false, "Altitude": 0.0 } HOWEVER, changing this value back to "Kerbin" does NOT resolve the issue. The root cause lies elsewhere. Included Attachments: DunaMissions.json

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 11 23H2 | CPU: AMD Ryzen 9 3900XT | GPU: nVidia GeForce 3900 | RAM: 32GB Weird glitch changes the skybox and causes ship to jump nearly 1000m backwards. Happens on ascent AND descent. On descent it causes the parachutes to jump forwards in front of the ship. It also interrupts the atmosphere sniffer, if that experiment is in progress. Video available here: Included Attachments:

I too am completely baffled as to how this was missed. Either no one took a flight at all after committing this change, or no one with an understanding of how it should work took a flight after committing the change. So now there's no re-entry heating OR re-entry drag. Next Kerbin will lose its atmosphere and all life on the planet will perish...

I splashed down a refueling vessel last night that contained a 20ton hydrogen tank. When it hit the water it repeatedly bounced dozens of meters back into the air. I think it's boyancy is WAY too high.

It's possible that this calculation is intentional, though probably not the performance drop. If it is true that interstellar craft will be burning for years at a time, then the only way for the player to do anything else but fly that craft during that time period is for the game to continue calculating updates for that craft even when it's out of focus. But clearly, if there's any hope of decent performance for this, especially with colonies and trade runs happening on top of this, they are going to have to optimise the HECK out of this. I cannot see how we will see any of those features on a time scale shorter than years at the moment. That being said, if they can keep churning out 300+ fixes per patch, I could be wrong!

Same experience here.

But something is triggering this misbehaviour. Ever since I sanitised my file of the 3 objects that were constantly repeating, I have played for hours without issue. I've constructed and reverted craft, flown to other planets. The save file has grown by a couple MB, but not the hundreds of MB it was doing after just a little bit of play early on.

One thing that is evident from the save file structure is that multiplayer is clearly already beings structured. Craft have an attribute both for an owner and for a player holding control authority.

The moment I entered Duna's SOI I had the sense that something good was coming, but I was completely unprepared for what I would encounter the moment I went suborbital. That soundtrack is simply epic, and it singlehandedly illustrates the potential this game has. Absolutely stunning music! Congratulations to the composers and sound designers!

Solved it: The kerbals have an attribute called "SimObjectIdString" and it contains the GUID of the vessel's root part. Prior to assignment to a vessel they appear to all have the same GUID in there. Perhaps it's the VAB/Astronaut centre. Afterwards it's the aforementioned root part.

I have a ship whose Kerbal has magically disappeared. I've been looking through the save file after he disappeared with the one before, and I cannot see any discrepancy in any of the key-value pairs that could be related to kerbals. Any help appreciated.

I hadn't noticed it, but that would make sense for the behaviour that I'm seeing. That doesn't sound like it's intentional.

Ships that land on the easter egg monument on Minmus are not saved by the game. Upon return to KSC, they are gone from the save. They don't appear in the tracking station nor in the save game file. They're literally gone. Landing outside the ring of the site is perfectly safe. One would expect that ships laned in the monument are persisted just like landing everywhere else. (Or if their disappearance is intentional...some kind of indication that this is the case while on the site) KSP2: v0.1 PC: AMD Ryzen 9 3900XT | Geforce RTX 3090 Founders | 32GB RAM

Craft occassionally seem to get put back into "AtRest"status in the save files when they're actually in space. This may be what leads to that.

I've had this happen with some RCS thrusters. Reloading did not resolve the issue. Very frustrating. Had to de-orbit and re-launch the craft. Example: https://we.tl/t-4MLLxPwGJo

So it turns out that you can, but you have to do it by right clicking the debris directly on the map, and then enter and re-enter the tracking station. But, you're absolutely right that it cannot be done from the list.