Streetwind

Maybe it's simply not supported? But as a workaround, place two groups of dual symmetry parts instead of one group of quad symmetry.

For me, SAS is automatically on when I go to the launchpad. Throttle is up as well - I don't need to press anything other than spacebar. Have you tried various configurations of launch clamps to help with wiggling? Such as one at the bottom and one at the top? Honestly I've not seen much difference? I mean, a lot of first stage engines got buffed, so vessels recreated from KSP1 have more TWR and thus fly differently. Also, my abysmal framerate (video card below minimum specs) adds some challenge. But if I tip the rocket over the right amount at the right time, it gravity turns just fine. And finding when and how much that is is just a question of practice with the vessel in question.

Have you tried a 3.75m second stage? You may not need the performance, but it would let you build a fairing that doesn't need to flare out from the stack.

Correct, it's not in the game yet. As to when it'll be patched in? Nobody knows. It's not an explicitly named roadmap item. It might come this week, or it might come in a year.

Wow, that's hilarious Never would have suspected those.

The simpler and more minimalistic a rocket is, the better it likely performs in the current state of the game. Things can't break if they're not there Regardless, this thread was not meant as a discussion of what doesn't work. We have like two thousand of those threads already. Instead I wanted to point out interesting little tidbits and trends we can already see.

It's definitely not a dV math issue, at least not with the test rockets I've been flying for those observations. I can literally mount a smaller tank than in KSP1 and get into orbit anyways - with an engine that has the same or slightly less Isp (the Reliant). I have, however, noticed some weirdness with dV math in more complex designs. For example, I just tried to do a Mun mission. First stage with a Skipper, second stage with a Poodle, third stage was a lander can with some small tanks and eight Ant engines. The VAB certified me 6650 m/s dV, which would be enough to land on the Mun and return to Kerbin. In practical application, I couldn't even land that without running out of fuel. What went wrong? Well, for starters, the calculator doesn't like more than one engine on a stage. If I attached a single Ant to my lander can, the calculated dV figure was noticeably smaller than with all eight attached, despite this being less mass! Another problem lies in the fuel crossfeed logic being broken. When I launch this rocket, the first stage will drain its own tanks, and the tanks of the lander, but (curiously enough) not the tanks of the second stage. This not only leads to fuel being consumed by a lower Isp engine, reducing available dV below what the calculator said, but additionally, the calculator actually factors in that it can errorneously access tanks it shouldn't be able to. So it gave me a higher dV figure for the first stage. The second stage did not drain any tanks it shouldn't, but I can't disprove the suspicion that it, too, calculated with the wrong amount of fuel. All in all, this rocket probably displayed at least 1000m/s more than it actually had. The reason I had none of these issues with my test rockets likely lies in the fact that they were a single stage with a single engine, thus neatly sidestepping all of the mentioned problems.

So let's talk about the gameplay itself for once, shall we? I've not done a whole lot in KSP2 yet, but I did do a few comparisons to KSP1, just to see how close the two games were, and where they would differ. The primary difference I found is that apparently, the aerodynamics model is noticeably more sensitive when it comes to the shape of parts and the vessel you build. There's a bigger difference between "sleek and pointy" and "blunt and flat" than before. Exhibit A: I am consistently reaching low Kerbin orbit with 3200 m/s dV now, where I needed 3400-3500 in KSP1. Sometimes even a bit less than 3200. The rockets I was testing this with are super simple: mk1 pod with a parachute, fuel tanks, and engine. Nothing attached to the outside. Exhibit B: I tried launching an uncrewed probe. I knew my launch vehicle was passively unstable, as it had no second stage to keep the CoM forward (it is so easy to get into Kerbin orbit single-stage), and a fairing larger than the stack, but I stubbornly tried anyway. After flipping over three times, I gave in to common sense and went back to the VAB, planning to add a second stage. But on a hunch, the first thing I tried was tucking the solar panels just a bit more snugly against the probe, and rebuilding the fairing just a bit more snugly around it. I also made the tip of the fairing more pointy. Fairings currently appear to be massless, so there's no reason to be stingy. Lo and behold - the thing flew without flipping! Just by changing the aerodynamics of the fairing. Exhibit C: In KSP1, I would typically hold on to my fairings until about 45 km. By common wisdom, this was already considered fairly high, and most players would ditch their fairings lower than that. This time in KSP2, I had troubles with fairing separation under thrust (in KSP1 I used to turn down the separation force of fairings to get a smooth detach, here in KSP2 it seems I need to turn it up instead), and so I hung on to my fairing until I had my AP where I wanted and shut down the engine. That was at 55 km altitude. Just coasting like that, my apoapsis altitude changed by maybe one meter per second, dropping due to drag on the vehicle. As soon as I popped the fairings, though? The apoapsis altitude started changing rapidly, maybe as much as 10 meters per second. Not a problem, obviously, as I was rapidly leaving the atmosphere behind, but that is a huge amount of drag for 55km. An order of magnitude drag increase just from popping the fairing around a XS size probe. KSP2 definitely encourages us to encapsulate our payloads, and hang on to our fairings for longer. EDIT: apologies for how this post became a wall of text; I was trying to split it into two posts, but the forum force-merges them every time. The second difference? There were a lot of rocket engine buffs. A few nerfs too, though far fewer and smaller. Overall, engines have gotten better, which probably contributes to how it feels easier to launch now than in KSP1. The Reliant lost 5s of Isp (260s-305s instead of 265s-310s), but got uprated from 240 to 260 kN. Doesn't seem like much, but where a 16 ton vehicle would have a TWR of 1.307 on the pad in KSP1, the same vehicle will have a TWR of 1.412 in KSP2. That's a difference you'll notice in flight. In a sense, the Reliant became the Kodiak from Making History, and that was a no-brainer upgrade. The Swivel got a major buff - and fairly so, I'd say, considering how the Reliant overshadowed it in KSP1. Vacuum Isp and thrust stayed the same, but sea level Isp went from 250s to 280s, and as a result, sea level thrust went from 168 kN to 188 kN. At the same time, its mass dropped from 1.5 tons to 1.4 tons. It's a much better engine now. The Terrier actually received a mild nerf! Only 335s vacuum Isp instead of 345s. This will definitely impact the way we build Mun landers. However, its role as a second stage engine for launches from Kerbin wasn't much affected, because its sea-level Isp went from 85s to 170s. The Terrier will now be more efficient and have better TWR just after stage separation. The Dart got a big swing with the nerfbat. 300s-320s Isp instead of 290s-340s, and maximum thrust dropped from 180 kN to 170 kN. But fear not... even after all that, it still remains one of the best launch engines for S-size stacks in the game. Just shows how OP it used to be in KSP1. The Vector was another nerf candidate: it got downrated from 1000 kN to 850 kN, sea level Isp dropped from 295s to 285s, and everything else stayed the same. Yeah, it's strictly worse now. Yeah, it's still a silly engine for its form factor, and you should have no issues building shuttle replicas. Hey, remember the Thud? Yeah, me neither! In all seriousness, that engine was so underwhelming in KSP1. Now it went from 120 kN max thrust to 140 kN, hopefully helping it find more use. Looking at the XS-sized engines, the allmighty Ant got its vacuum Isp increased from 315s to 330s, though sadly it lost its non-blocky second variant, which I loved... The spider got 25% more thrust with no other changes (2.0 kN -> 2.5 kN), while the Twitch got a little heavier (80kg -> 100kg) and had its Isp changed from 275s-290s to 265s-298s. The Spark lost 5s vacuum Isp but gained 5s sea level Isp (now 270s-315s). Going up in size instead, the Skipper got... nerfed? A little? Max thrust went from 650 kN to 600 kN. But Isp went up... strictly speaking... theoretically... by exactly 2s But hey, at least the Mainsail, which already had too much thrust in KSP1, now has even more thrust! 1600 kN instead of 1500. It lost a lot of Isp though, going from 285s-301s to 265s-307s. Prepare to dump a lot of fuel into this hungry maw. But when you do, it'll go. The Poodle unsurprisingly got the same treatment as the Terrier, meaning: less vacuum Isp (350s -> 340s) but more sea level Isp (90s -> 175s). But unlike the Terrier, it also went down in max thrust significantly, from 250 kN to 215 kN. Fair enough, it used to be on the awkwardly-too-strong side for most landers. This might actually make it easier to use. Another size class up, the Rhino went on a diet: 8 tons instead of 9. In return its maximum thrust dropped from 2000 kN to 1750. The redesign away from orbital use to a sustainer type is felt in the Isp, which changed from 205s-340s to 285s-325s. For orbital work we now have the Labradoodle, which is completely new. The Mammoth is now the Mammoth-II, and looks the part of its namesake with its ginormous trunk errr I mean turbopump exhaust. It got a mild thrust uprating from 4000 kN to 4250 kN, and like the mainsail, lost a good chunk of Isp: 270s-310s instead of 295s-315s. All of the SRBs stayed the same, and I didn't look at the jet engines, as I'm just not a plane type of person. Here is where it gets really interesting though: the high-impulse, alternative-fuel engines. All of them got so much stronger. Just look at the Nerv. Maximum thrust went from 60 kN to 75 kN. Isp went from 185s-800s to 250s-900s. Those are two massive buffs, but it's not the end just yet: in KSP2, all fuel tanks - including hydrogen - got normed to a mass ratio of 9, whereas in KSP1, the plane parts that were so often used with the Nerv due to a lack of dedicated LF-only rocket tanks were more around 8. So not only did the engine get a lot better, the tanks for the engine got better too! Then there's the new nuclear engine, the Swerv. And it's absurd. There were modded engines available for KSP1 that were considered OP, and they were not as OP as this engine is. It is overtuned to such a monstrous degree next to all other engines, there's just no comparison. I reckon this is our preview for what higher tech levels are going to be offering, at a game stage where the Kerbals have colonies all over the system and interstellar technology is close at hand. Let's not forget the Dawn ion drive, either. On the surface, it received a small nerf, in the sense that it needs a bit more energy to run now (10 EC/s instead of 8.74 EC/s). But just like the Nerv is benefitting from better tankage, so is the Dawn. Xenon tanks used to have a mass fraction of 4. Now, just like all other tanks, they're at 9. That means they contain more than two and a half times the amount of xenon for the same dry mass. You might not notice it that much when attaching only a single tank and getting a small few thousand m/s of dV; but it's gonna scale so much higher so much more easily. A single ion stage with 40,000m/s worth of dV would have been borderline impossible in KSP1 even without worrying about how to launch it; now in KSP2, it's not any harder to achieve than making a Terrier stage with 3,100m/s worth of dV. And remember, the perhaps biggest buff to low-TWR engines like the Nerv and Dawn: the ability to time warp during burns. I mean, once that actually works reliably But yeah, get used to the idea of working a lot more with really high dV deep space craft in the future. It's gonna be easier than ever before.

Your CPU is fine. Not gonna be great with high part counts, but it'll do basic gameplay well enough to tide you over until a future upgrade. The GTX 750 Ti is absolutely not okay. You will not enjoy your time playing with that, if it doesn't outright crash on startup. If you must upgrade anything, upgrade that. Aim for a video card with at least 6 GB video memory. That is technically still too little, but if it's all you can afford, you can make do by dropping the render resolution and not looking at the ground as much as possible. If you can, go for something with 8 GB VRAM. (Any video card with this amount of memory will also have sufficient raw performance, so don't worry about the exact model.) If you can get a second 8 GB stick of system memory in there, that'll help too. KSP2 will happily take all of it. Just keep in mind that even if you do all that, you'll be playing with sub-60 FPS in many situations. Looking at celestial bodies from low orbit currently just murders FPS in cold blood. I've seen GTX 4090 users complain about the framerate while looking at Kerbin. That's not the fault of the hardware, that's the fault of the game. It'll get better in time, but right now we're deep in "make do" territory.

No, nothing. KSP2 does not use raytracing. Not sure where OP got the idea. Or maybe they're just asking if the game is using this and worded it poorly.

Do you understand the concept of an early access program? (P.S.: the game is not developed by Squad.)

You can build a SSTO with just six parts. It has become even easier in KSP2 than it was in KSP1, now that it seems like dV to orbit is closer to 3200 than 3400 m/s. Just slap together a mk1 capsule, a parachute, a decoupler, a FLT-400 and a FL-T800 tank, and a Dart aerospike. It'll go to orbit without staging, with fuel to spare. A spaceplane, on the other hand, will need a few more parts. But there's plenty videos out there from content creators who have built some. Matt Lowne slapped one together at the ESA event and went to orbit and back to KSC with it.

There can be multiple limits, which come into play at different points. VRAM is a huge problem as soon as you drop below 8 GB on 1080p or 10GB at 1440p. Performance will degrade hard anytime any part of a celestial body is in view; for my 6GB card, I can go from 60 FPS when viewing my vessel against the backdrop of space, to 10 FPS just by turning the camera so Kerbin is in the frame. Larger VRAM counts do not experience this massive drop. Your card has 16GB VRAM, which is easily enough for 1440p, so you're probably running into a different limit.

There is this spreadsheet - probably as close as you're going to get with polling random community members.

That was the first thing I did. No effect. (And before you ask: no, it isn't forced on in the Nvidia control panel.) I get all sorts of framerates that do not stick to clean multiples of my refresh rate. 23 on the launchpad, 9-11 when looking at Kerbin from space, 48-54 in the VAB. It's not a synchronization issue, it's my card not having enough VRAM.

The GPU is at 100%, according to my monitoring tools. It just isn't doing anything beyond twiddling its thumbs waiting for data to be fetched from system memory and/or disk because its video memory is overflowing. As soon as a less memory intensive scene is presented (i.e. anything without a celestial body in the frame), it starts doing actual work. I just experimentally dropped my render resolution, which usually comes with notable video memory savings. Result: VRAM still full to bursting, which proves that it is definitely way too small. But the GPU is running warmer now even when choked on it, so the problem grew smaller. FPS on space center screen improved from 14 to 22, and from 9 to 11 when looking at Kerbin from orbit. Meanwhile, looking at my craft in space without Kerbin in the picture gets above 60 FPS. Pretty good for a GPU/CPU combo that's below the official minimum spec. Verdict: KSP2, and its celestial bodies in particular, definitely want a good amount of VRAM to render smoothly. Probably at least 8 GB for 1080p and at least 10 GB for 1440p.

I've been experimenting with a ten year old CPU (i5-4670) and a six year old video card (GTX 1060 6GB) which are both below the minimum requirements. To my great surprise, neither the CPU nor the GPU are really under full load. The GPU temperature stays really low regardless of reported load, and the CPU is rarely breaching 50%. My results overall are very similar to those of @BobbyDausus - down to exactly the same 9 FPS when looking at Kerbin from orbit. What is chock full, however, is the video memory. And when I overlcocked that, I saw an immediate FPS improvement. So right now, my hunch is that anything short of 8 GB VRAM will simply choke and drop to single-digit FPS when looking at Kerbin from orbit and such.

I've had multiple issues with alt-tabbing so far. The solution, for now, seems to be "don't alt-tab". You can try setting your game to borderless window instead of fullscreen, that might mitigate it.

Looks like you'll have to re-learn how to properly build things, now that the crutch is gone. That means stuff like: don't connect two XL parts with a small part; connect them with another XL part. If you want a small part in the middle of a large stack (for example a small engine on a large fuel tank), use an engine plate to form an interstage, or use a payload bay of the appropriate size. Additionally, if KSP2's node system is anything like KSP1's (and everything seens so far implies yes), then the shorter a part is, the more it will wobble. Four FL-T200 tanks stacked will have the same length as a single FL-T800 tank, but wobble far, far more. Ergo, use long parts where you can. Finally, struts are a part you can use to stabilize sections that wobble no matter what. Autostrutting will return in a future release, according to the devs. No timeframe has been given.

You select one of your assemblies as the launch assembly. There's a button for it in the same toolbar at the bottom that has the select, move, rotate etc. tools. The selected assembly, marked in green, is the one that will be going to the pad. All other assemblies will not be coming along. If you have three subassemblies and want them all to come to the pad at the same time, you need to combine them into one assembly. The intended use case for having multiple assemblies in the same workspace is, for example: you design a space station and a lifter in the same workspace. You then pull a section off of the station, stick onto the lifter assembly, and launch that into orbit. Then, you pull a different section off of the station, stick that one onto the lifter, and launch that, and so on. I suppose you could launch one assembly, go back to the editor, launch another one on a different launchpad/runway, and rinse, repeat until you have them all out.

The Dres conspiracy continues...

This has me cautiously optimistic. Because I have a 10xx series Nvidia GPU as well, and I'm stuck at 14 FPS on the space center screen too, no matter what I set my graphics settings too. Always 14 FPS. That the graphics settings seem to not influence this, and that other people are in the same boat (and even one who's apparently fine!), gives me the impression that this isn't an inherent problem of the cards being too weak. Rather, I suspect there's software issues at play here. If the cards were too weak, we'd be out of luck - but software issues can be fixed. Crossing my fingers

I'd like to quickly step in here and gently but firmly take you by the shoulders and steer you away from this website. It may look tempting as a quick and easily linkable online resource, but unfortunately it might very well be the least reputable site dedicated to gaming hardware anywhere on the planet. If you'd like to know why, articles and videos from tech enthusiasts tearing Userbenchmark apart are all over the net. Please use literally any other resource to get your benchmark results. Anything but this.

During one of the various interviews posted over the past few days, Nate said something along the lines of "expect the timescale of updates to be weeks, not months". You can take this how you like; personally, I'm expecting on average 2, maybe sometimes 3 patches per month. Always depends what is being worked on and if any critical blockers show up.

The specs on that website do not match the specs released by Intercept Games. Like, not at all. They look closer to KSP1 specs than KSP2. Check the Steam page for the actual, proper system requirements.