bigwhitey95

You poor stand-up guy. I did a probably 180km return drive from the Duna ‘point of interest’ to the North Pole and back, just to see what the North Pole looks like as you approach it (was actually pretty cool), and yes literally half of the time spent was on reloading quicksaves and backtracking progress because the rover would just randomly spin out. I landed another rover probably 80km away from a point of interest on Eeloo, and that whole experience with the Duna rover has absolutely discouraged me from trying to reach that point of interest.

Perhaps related but it would be nice if the on-screen indicator of a nearby ship / debris / point of interest can have a max range greater than 50km. I think KSP1 stock had 70km. I especially would have liked this on a recent Tylo landing where I wanted to land near a certain feature and my ship actually traversed about 60km horizontally during its retrograde burn - even if I had started the burn as soon as the on-screen indicator appeared at 50km, I still would have overshot it by 10km.

I support this. And at the very least, launch towers should automatically be recovered as soon as they are outside of physics range. In regard to deleting debris one by one, I don’t even think it should ask you to confirm if you want it deleted; just delete it when the player clicks delete.

I agree with the idea of more planets in the Kerbol system to at least add more novelty and interesting places to go before going interstellar, but I would disagree with the idea of Saturn, Uranus and Neptune analogues for reasons that have been already mentioned. The idea of a Sednoid with an extremely elliptical and somewhat eccentric orbit and an average distance so far out that solar panels would be useless would present challenges with intercepting it and power generation once you are there - I’d like that.

No but there really needs to be. I wish there was a way to just turn this notifications thing off altogether. The ‘lack of stellar exposure’ notifications drive me mad - as if we are being punished for putting satellites into equatorial orbits.

I have found a use for the larger-size, semi-tubular trusses (in the payload parts menu) as a kind of cargo bay for rovers. The rovers don’t strictly need a walled cargo bay or to be put inside their own separate fairing, so it works well. Plus it’s cool to have the rovers attached to the trusses via decouplers on the same stage, and to have the trusses (stacked on top of each other) rotated around their y-axis at equal angles from each other, then stage the decouplers and watch as a swarm of rovers (with detachable retro rockets of course) fan out from the mothership. I have found uses for the smaller, rectangular trusses too. Sometimes they are just good to make a ship that looks slightly cooler, even if it is not the absolutely most efficient design.

The main thing I want to see improved with rover wheels is just expected stability. Even if you add negative camber and positive caster angles to the wheels, sometimes when roving around it’s as if one of the wheels can sometimes clip into the ground mesh and the whole rover then just rapidly spins around (sometimes you can counter this by immediately turning on a reaction wheel and SAS, but it shouldn’t have to come to that). I’m sure we’ve all experienced this multiple times - happens on runways with planes too. I had a rover do perhaps 60km of driving on Duna and I was having to quicksave every 2 minutes just in case my rover randomly flipped out and destroyed itself.

Good note about the Armoury Crate software crashing - I also have an Asus computer and it’s that Asus software which also crashes immediately prior to KSP2 crashing. I have a similar computer except it has an RTX 3070. KSP2 has actually become so bad just in the past day that my computer will immediately crash upon loading into an autosave in the VAB. I don’t know whether it’s the For Science update itself which introduced these issues, or if they already existed but are exacerbated by a comprehensive playthrough of Exploration mode (which is kind of necessary, as opposed to Sandbox mode which has no progression penalty for restarting fresh whenever you want). But I have 300 hours in KSP2 so far and it hasn’t been this bad.

As the title says. I have a 1-year old Windows 11 PC with 16GB of RAM. Since the For Science update I have noticed with increased frequency that KSP2 will crash my entire PC (ie other programs such as Spotify will crash first, then Windows itself hangs, forcing a hard restart). Inspecting task manager immediately before a crash shows KSP2 utilising 90% of available RAM. I am playing on Exploration mode. The crashes happen almost exclusively in the VAB (but I have had it happen once on Duna’s surface). They first started when building larger interplanetary craft with multiple deployable satellites and landers in the VAB. But now I am getting crashes even when assembling a simple craft such as just a recoverable booster - and these crashes happen after only 10 minutes in the VAB. I have already reduced the graphics settings to medium overall with AA turned off. I have deleted debris and unused crafts. I have deleted old workspaces so I only have 8 now. I have also almost-entirely cleared the saves folder (so just a handful of saves). These haven’t had a noticeable impact on frequency of crashes. I haven’t tried restarting a new game as I am still playing through Exploration mode. I don’t think this is a singular identifiable bug so I haven’t posted this in the bugs subforum. Any tips to deal with this which don’t involve starting a game all over again? Thanks!

Not sure if this helps with bug testing or if it’s a different issue, but I independently came across this and noticed the SWERV’s position relative to the craft can change each time you load a save and it loads direct to the craft while it is in flight (ie deep space), regardless of the amount of time in timewarp (ie it’s happened only a few months into a Moho mission, at the mid course correction burn). About 50% of the time the SWERV is positioned correctly, but the rest of the time it is offset from the craft. Sometimes it is offset longitudinally, sometimes it is offset slightly laterally. Every time this happens I load to a save until I get a load where it isn’t offset. Could it be an issue when the craft file transitions from unloaded/timewarp to real time? I wonder if it’s related to the bug where a net torque is applied to a craft the moment it exits timewarp.

Sorry for the late reply, I kind of like that idea a lot actually. Hope the devs implement something like that.

*SOI being sphere of influence, of course. I don’t know if this is a problem only I’m dealing with, or if anyone has suggested this before, but it’s kind of annoying for me (if only a small problem). I have Jeb on a mission from Kerbin to Laythe, using gravity assists at Eve and Kerbin to get a Jool encounter. I also have craft already landed or in orbit around these bodies. When I am zoomed out in map view and I go to right-click on a planet to either focus it or set it as target (if not already focused), the right-click menu that pops up is always for a craft in that SOI, not the planet itself. Eg if Jool is not focused and I right-click on it to set as target (especially while zoomed way out), then even while hovering the cursor as it shows “Jool” under the cursor, the right-click will always open for one of my craft in Jool orbitinstead (ie focus on that craft or set as target). So what I have to do is focus on the craft, zoom all the way into it until I can see Jool itself rather than the icon for it, then right click on Jool to finally set it as target, then zoom all the way out to plan my manoeuvre node. It’s more cumbersome than it should be. I just think that if you’re zoomed out in map view to see ie the whole Kerbol system, then if you right click on any celestial body, it should always prioritise the body itself, not the craft in that system. I don’t see why it should prioritise craft. I hope that makes sense.