Davidian1024

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Ubuntu 22.04.3 LTS | CPU: AMD Ryzen 5 3400G | GPU: NVIDIA GeForce GTX 1080 Ti | RAM: 32GB Upon a recent mission to Eve, I found that the craft I made seemed to be too wide for the atmospheric entry effects to cover the entire craft. I'm including a video that shows what I mean along with a save during the moment it was most noticeable. Included Attachments: Screencastfrom02-11-2024032211PM.mp4 re-entry_bug.zip

I planted a flag in the Mohole and that completed the Plant a flag on Pol mission for me.

Well, shucks, wish I had come across this YouTube video sooner. Sounds like it's getting even easier to run games on Macs.

For what it's worth, I was able to get KSP2 running on my mom's MacBook Pro (M2 Apple Silicon). It depends on something Apple recently released called Game Porting Toolkit. I installed the Windows edition of Steam by followed the instructions in this GitHub repo: https://github.com/domschl/WinSteamOnMac I've been running KSP2 on my own Ubuntu Linux machine since day one of early access, and the experience is nearly identical. This method is in fact using wine under the hood. One additional thing I had to do for KSP2 was to set the launch options to bypass the little launcher app, which would just crash. I actually have to skip the launcher on Linux for the same reason. Counterintuitively, on the Mac, I had to specify a the Windows style path to the KSP2 executable. The line must also end with # %command% Here is what I ended up putting in the game's launch options: "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program 2\KSP2_x64.exe" # %command% Just skimmed through the little Mac vs PC argument in this thread. Obviously PC is better. As long as you run Linux on it.

This didn't start happening until I loaded a save with my craft parked here by the bones. Before having loaded my save I had taxied my plane all the way over here. I can get them unstuck for a moment by retracting the gear and extending them again, but a second or two later they get stuck again.

I also think something seems really wrong in the uppermost parts of atmospheres. I am trying to enter Laythe's atmosphere at a very shallow angle. AP is 49,669m and PE is 48,218m. Speed is 1829m/s. But many parts keep overheating and exploding. I seem to remember being able to point my space planes fully radial out in KSP1 in situations like this. If this is more realistic as some people are claiming, what's the right way to enter the atmosphere now?

I think this is related: Fairings disable parachutes, even after staging Possible workaround included.

@Anth This is still an issue as of 0.2.0.0 (For Science!). I've run into this many times and it's always been extremely frustrating and puzzling. It ends up completely sabotaging missions. I would consider this one game breaking. After a little testing I can see that @nicholasluigi has it exactly right. Fairings seem to disable parachutes permanently. This seems to depend on whether the game thinks the parachute is inside of the faring or not. Beyond normal fairings, the fairings that come with engine mounts also cause nearby parachutes to become disabled. This is where I run into this problem most often. The fairings that come with engines do not seem to have any effect on parachutes. Note: The way the game determines whether the chutes are inside the fairing is inconsistent. On a somewhat positive note, I've stumbled upon a workaround. Unfortunately, you need to do this at the VAB during your design/build phase. If you are already well into a mission and you didn't do it, this won't help you. Attach parachutes in whatever way caused them to become disabled. Pull them off with the selection tool and press the delete key to delete them. Press Left Control + Z to undo the delete. Note: This procedure seems to affect the fairing object. As opposed to the parachute object. After going through these steps, the fairing no longer seems to have the ability to disable any parachute. The undo step seems to be the one that affects the fairing. Here is a craft that demonstrates this behavior: Fairings Parachute Bug.zip Launch the craft and go through all stages. Two of the parachutes will deploy, two will not. The two that did not deploy through the staging sequence should be permanently disabled now. The workaround described above can be followed on this craft to demonstrate it.

https://soylent.com/

@Anth I have been using the F2 key alot. The game is just so pretty, I can't help but take alot of screenshots. So, I need to get the HUD out of the way. And I guess for what it's worth, occasionally while I was fighting with this last night, the lines would be gone, but the AP, PE, etc markers would be there, but no line. And no way to create a maneuver plan. So, I managed to get my orbital lines to show up again. Fully quitting out of the game and loading my most recent save might've been what did it.

Not sure if this is new info for the devs or not. But it's new info to me so I thought I'd share. I just took off from the Mun after finding the Mun arch for the mysterious signal mission. No orbital lines for my craft unfortunately. Save/Load workaround not helping. Oh well. Interestingly enough, as I pass over the highlands of the Mun the new science action on the left is telling me to go outside in order to perform an experiment. I think the game thinks I'm on the ground. At this point I haven't done any experiments on the Highlands of the Mun yet. Hopefully this helps.

It was possible in the first version before any patches. Though, I don't remember which patch changed it. In Steam it's possible to select previous versions of the game and use those. I've never actually tried it though. Here's where you can select the previous versions: Right click on the game and select "Properties..." On the left hand column select "Betas" The drop-down menus on the right should default to "None". If you pull that down you'll see all the previous versions.

Hmm... not sure what to say about that DirectX error. I know I've seen it in the past with other games running under Proton. I don't think I've ever run into that one with KSP2. Overall, Proton seems to just keep getting better. After running under the new OS for a few days it seems like things are running great. I had issues with a number of games. Now, it seems like nearly everything is working flawlessly. Performance seems better across the board too. I think KSP2 is the only one where I'm still having to set launch options. I added my system specs to my post. Maybe you're just unlucky enough to have a particular hardware combo that's triggering that.

I would like to add this. I sometimes build unusually configured craft with things like fuel tanks attached via radial decouplers. The plan is to manually pump the fuel into some main tank and then jettison the empty tank(s). The staging thing has no way of knowing what my intentions are which causes it to ignore alot of the fuel i still have. This essentially prevents me from using the maneuver planner fully.

The most supported way to run KSP2 on Linux as of 2023-11-21 (YMMV) TL;DR Ubuntu 22.04 & Proton 8 with these launch options: PROTON_NO_XIM=1 '/home/username/.local/share/Steam/steamapps/common/Proton 8.0'/proton waitforexitandrun '/home/username/.local/share/Steam/steamapps/common/Kerbal Space Program 2/KSP2_x64.exe' #%command% Full Story I finally decided to update to a newer Linux, so I thought I'd share my experience in getting KSP2 running from scratch. I installed Ubuntu 22.04 on a fresh SSD. Previously, I had been running 20.04. FWIW, I chose this Linux distribution after finding the following on the Steam Client Troubleshooting on Linux page. When I installed Ubuntu I made sure to check the box labelled "Install third-party software for graphics and Wi-Fi hardware and additional media formats". I obtained Steam via the green install button at the top of steampowered.com. That ultimately links to https://cdn.cloudflare.steamstatic.com/client/installer/steam.deb. Which yields a Debian package named steam_latest.deb. I installed that from the command line like so: sudo apt-get install ~/Downloads/steam_latest.deb After that I launched Steam from the "Show Applications" thingy in the corner. Initially the KSP2 install button was greyed out. In order to make it installable I had to go into the properties of KSP2 and select Compatibility. From there I checked the "Force the use of a specific Steam Play compatibility tool" and I then selected the latest non-experimental version of Proton. That's Proton 8.0-4 at the moment. The game installed fine, but the launcher would crash every time I tried to play it. I added the following to KSP2's launch options within it's properties in order to directly launch the KSP2 game executable. '/home/username/.local/share/Steam/steamapps/common/Proton 8.0'/proton waitforexitandrun '/home/username/.local/share/Steam/steamapps/common/Kerbal Space Program 2/KSP2_x64.exe' #%command% That was enough to get the game running. Beyond that I found that an input issue I ran into on Ubuntu 20.04 persists on Ubuntu 22.04. I reported this in the past here. In order to work around this specific issue I added PROTON_NO_XIM=1 to the beginning of the game's launch options. Here's the resulting launch options: PROTON_NO_XIM=1 '/home/username/.local/share/Steam/steamapps/common/Proton 8.0'/proton waitforexitandrun '/home/username/.local/share/Steam/steamapps/common/Kerbal Space Program 2/KSP2_x64.exe' #%command% I hope this helps my fellow Linux users. Solidarity comrades! My System Specs CPU: AMD Ryzen 5 3400G GPU: Nvidia GeForce GTX 1080 Ti RAM: 16GB DDR4

So that's what that is. I've been wondering.

Fusion?

@The Space Peacock Thanks for listing this one. Sorry about the .mkv files. I didn't realize they were incompatible with the forum. Here's YouTube links of both videos I have that demonstrate this one. SAS Surface/Orbit Auto Switch While Targeting North SAS Surface/Orbit Auto Switch While Targeting Up

Reported Version: v0.1.5 (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 System Spec Description Running the Dawn Engines seems to cause incorrect electric charge drain. This effect seems to be magnified exponentially when time warping. In the video I'm attaching you can see that at 1X time warp the EC drops slightly when I turn the engines on. From 507.5 to 506.7. It holds at this slightly lower level. When I increase the time warp. The amount by which it drops seems to increase exponentially. This prevents time warping above 100X. I would argue that it's incorrect for the EC to drop even slightly when the engines are turned on at 1X time warp. Because the amount of charge consumed is less than the amount generated. Included Attachments: dawn_ec_bug-2023-11-06_18_14.45.mp4

SAS Surface/Orbit Auto Switch While Targeting North

I dug into this some more today and learned that it's not limited to up/radial out. Switching from orbital velocity to surface velocity will cause the surface target button that corresponds to the orbital target button to be selected, but not highlighted.

Reported Version: v0.1.5 (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 Background This is something that frustrated me greatly in KSP1, especially when I was new. It has been brought over to KSP2, and I find myself having to continue to work around it. I reported this in the past but it was archived. I want to try to make a better argument this time. Description SAS automatically switches from surface velocity to orbit velocity when you ascend above a certain altitude. Over Kerbin this altitude is ~36000m above sea level. This number is different when you are above other celestial bodies. It generally seems to be about halfway between sea level and the top of the atmosphere. The biggest problem with this is that SAS will suddenly start aiming the craft in a potentially completely different direction without any warning. If this happens in the middle of a burn, it can have disastrous effects. The reason SAS switches directions is because surface velocity and orbit velocity have completely different target sets. And they each map to a target in the other set. Surface Prograde/Retrogradde <-> Orbital Prograde/Retrogradde (These are usually very close, but can be significantly different.) Surface Up/Down <-> Orbital Radial Out/In (These can be as much as 90 degrees different. Flying straight up.) Surface North/South <-> Orbital Normal/Anti-Normal (Can be as much as 90 degrees different. Polar orbits.) The core issue is that SAS will suddenly start aiming the craft in a potentially completely different direction without any warning. If this happens in the middle of a burn, it can have disastrous effects. Videos: System Specs

Oh good. I often try to entertain with my bug report titles. I'm honestly not sure if it should be merged or not. It's really just a suspicion I have, that it's the same bug. I guess I'd say leave it separate until we know more?

This still exists in 0.1.5.0 @The Space Peacock @Spicat @Anth Can this be moved into the current set of bug reports? Or do I need to open a new one?

This one is very annoying to me. I have to take steps to work around it all the time. @142857 thank you for reporting it. Here's a report I made for it quite a while ago: "Up" no longer selectable once SAS auto switches from surface to orbit velocity. Looks like it's existed at least as far back as 0.1.2 Side Note: I wish I got some sort of notification when my bug reports get archived. I can shed a little more light on what's going on here. This will always happen when SAS auto switches from surface to orbital. That auto switch is usually triggered when your craft goes above a particular altitude. On Kerbin this altitude is 36000m above sea level. I know it happens on the other bodies, but I don't know the altitude for those. I think the number is based on the size of the body or the height of it's atmosphere. If you switch back to surface after it's switched to you to orbital, (but you still have orbital:radial out selected) it actually will have up selected, the button just won't be lit up. It's a visual bug. This is because surface:up maps to orbital:radial out. When the auto switch occurs you'll notice that radial out got selected. But for some reason, when you switch back to surface, up doesn't get highlighted. In order to work around it, I make sure that SAS is set to hold (the padlock; as opposed to any of the specific directions like up, prograde, etc.) when I know the switch is about to happen. So as I'm climbing through Kerbin's atmosphere, I watch for when I get to about 35000m above sea level and then press T twice. That turns SAS off and on again. Which causes it to default to hold. Then when I get above 36000m I switch back to surface and select up again.