Streetwind

Fair assessment. I guess without a structured test, there's just no way of knowing.

That's not entirely correct. Whether cache helps or not depends more on the kind of instructions and data the CPU must process. If your application needs to do the same couple dozen things over and over on very similar data, then both the instructions and the majority of the data can be effectively cached, and every new instruction cycle scores a cache hit. This allows the thread to proceed immediately (for cache latency values of "immediate"). If, however, each new instruction is something unpredicatbly new, and requires large amounts or quasi-random selections of data, then the CPU must wait for a main system memory access - or, if it's really, really unlucky, for a disk access. These things take multiple orders of magnitude longer than reading from cache. While modern CPUs are very proficient at predicting execution order and finding other things to do while they wait for something, that doesn't make the waiting instruction itself finish any faster. And if that instruction happens to be holding a lock on the main thread, then well, the entire main thread is briefly paused while some file is accessed on the disk. Thus, different applications respond differently to large amounts of cache. Those that can't make use of it don't care, and those that can make use of it will absolutely love it and post massive gains up until they wander into diminishing returns. Which, again, vary from application to application. This does not really rely on fully loading all cores. Even a purely single-threaded application running on an 8-core, 16-thread CPU can love cache, or not. In the case of KSP (1 or 2), the big ticket CPU item is physics simulation for the active vessel. If this task specifically loves cache, then the KSP games will run significantly better on X3D CPUs. If this task doesn't love cache, there won't be much of an advantage, even if some other tasks do love cache. I'm not sure we can benchmark this effectively on the current version of KSP2, though. It would likely need to be done by someone who has a system with a massive high-end GPU, and two comparable Ryzen CPUs with and without v-cache (such as a 5800X and a 5800X3D). It might involve loading a vessel somewhere in deep space away from all celestial bodies. If the vessel is bonkers enough, it should generate the CPU load needed - but whether the results would be cleanly reproducable enough for a meaningful benchmark, I can't say.

The best method depends on your goal. Maximizing payload fraction to orbit, minimizing dV cost to orbit, minimizing funds cost to orbit (back in KSP1 where that mattered), or a number of other goals might require different strategies . For example, minimizing dV cost to orbit usually involves extremely high thrust, tipping over really hard really early, and watching your rocket be a fireball all the way to space. Very few people actually play like that, though, not least because that greatly limits you to very small, sleek payloads. When considering the average use case, where a player wants to push a not-ridiculously-shaped but otherwise unspecific payload to orbit in a neat, clean, and efficient manner, without going hard into any particular optimization corner, then you arrive at something like this: your rocket has a TWR of around 1.3 to 1.4 when sitting on the pad; it will begin by ascending straight up for a short distance, until a certain speed is reached; it performs a single pitch maneuver that tilts it a certain amount of degrees over to the east; it activates SAS Hold Prograde; and then it flies completely without the player touching the keyboard. Due to the choice of pitchover speed and magnitude, it will hit 45° towards the horizon at around 10 km in altitude above sea level. It will eventually receive a staging command from the player to drop the spent first stage and light the second. It will continue flying hands-off and full throttle, like it has the entire time, until the target apoapsis altitude has been reached; at which point it will cut the engine and coast to apoapsis for orbital insertion. Optionally, the player can intervene in the flight of the second stage by starting to throttle down at some point to prevent the apoapsis from running away from the rocket. Keeping the apoapsis close to the rocket more efficiently raises the periapsis, and because the rocket is nearly level to the horizon at that point, gravity drag is no longer a factor. However, this should only be done when the apoapsis is already close to leaving the atmosphere, something like 55-60 km up. Otherwise you risk stalling your ascent in the upper atmosphere, which is the opposite of what you want. (This is admittedly a bit advanced.) Here's another thread where I discussed this with someone, and gave him a (different) sample rocket. He actually recorded his two attempts on video, so it may help you see what I mean. He ended up getting an orbit insertion burn of just 150 m/s for a 102 km orbit. Had he gone for 80km, it might have been closer to 100. Not bad for a flight that didn't touch WASD at any point after the initial pitchover, right?

@cocoscacao It's always great to see when players find themselves a reliable method that works for them and they are happy with. And far be it from my place to prescribe anyone how they should play. However, because this subforum is a place where new players come looking for good advice, I feel compelled to reply and point out that this method is not objectively good. It priorizes the wrong things at the wrong time and, for all its manual effort, ends up spending more dV to orbit than a regular, passive gravity turn. Concerning here is primarily your repeated advice to "limit speed". This is bad advice, because aerodynamic drag is a largely negligible part of the cost of reaching orbit on Kerbin, whereas gravity drag is substantial and is incurred in larger amounts the slower and steeper you go. Throttling down is an acceptable response to accidentally launching too steeply, but you should not build it into your standard procedures. Excess speed should be put either into flattening out your trajectory sooner, or into redesigning the rocket to let it carry more fuel/payload on the same set of engines, so it trades the unneeded speed for something more useful. Pushing the apoapsis far away is also not minimizing your circularization burn, because it will result in a long coast phase, during which your altitude will increase and your speed will decrease. Remember, the goal of circularization is to lift the periapsis out of the atmosphere, and therefore, the measure for how large or small your circularization burn is going to be is how high you can get your periapsis before your apoapsis reaches your desired target altitude and you have to cut your engine and coast. And the best place to raise your periapsis is to burn directly on top of the apoapsis - yes, even during a launch. This, of course, would mean that your apoapsis itself won't rise anymore, so in practical application you'll always be pushing your apoapsis ahead of you by at least a minute or so, to ensure you maintain vertical speed until you leave the atmosphere. But trying to intentionally push it away as far as possible actually has the opposite effect that you think it has. I also don't understand how you are first describing pitching over to 45 degrees, and after that, say "point to 60 degrees". The horizon is 0°, so 60° is steeper than 45° - therefore you would be going backwards, pulling the rocket back upright instead of letting it flatten out. Did you by any chance mean 30° instead of 60°?

KSP2 nerfed ion engines from 2 kN vacuum thrust to 0.2 kN vacuum thrust. Relying on them to do more than a few dozen m/s of final orbital insertion is unlikely to succeed. They're really meant for ultra-long burns under timewarp in this iteration of the game. (Which, by the way, isn't properly implemented yet, so their use is very limited at the moment.)

They only thing even vaguely resembling an acceleration gauge in flight right now is the g-force indicator on your crew portraits. And those are not very helpful =/

I have never found Alexmoon's planner to give me a wrong transfer. It has worked precisely and reliably throughout all of KSP1, and also in the two cases I have been using in for KSP2. However, there's one caveat worth knowing: the date format has changed between the games. KSP1 started the game in year 1, day 1, and hence Alexmoon's planner - made for KSP1 - does too. KSP2, meanwhile, starts the game at year 0, day 1. But the position of the planets at epoch is identical. So when you are in for example year 10, day 200 in KSP2, and you want to plan a transfer from Dres to Kerbin, you have to set the earliest departure date in Alexmoon's planner to be year 11, day 200. Because KSP2 is always going to display one year fewer on the savegame clock than KSP1 would have. And that can very easily mean the difference between you getting an output that works, and one that doesn't.

If precision is a problem, remember that you can trade off speed and pitch magnitude. If you pitch over later, when the rocket is going faster, you need a larger pitch. That may be easier to hit consistently than a very gentle one earlier on. So instead of doing 5 degrees shortly after launch, try and see if you can find the speed where 10° will do the trick. 10° is very easy to hit consistently because it's just the innermost circle around the center of the blue hemisphere of the navball. Another thing you can do is build rockets that are partially self-correcting. I did that by accident with this Mun rocket here, where I was trying to go for minimal mass. I couldn't find a good single-engine solution that would push 22-odd tons off the pad in a 1.25m form factor, and there aren't any XS sized SRBs yet, so I ended up sticking a pair of Thuds to the bottom, dialed their throttle in to be just a bit too high, and designed them to be staged off halfway through the first stage burn. Both to reduce the then-unnecessary thrust, and to let a higher-Isp sustainer have the rest of the fuel. What happened was that I suddenly had a rocket where, if I found myself going too shallow, I would just delay dropping the Thuds and let their excess thrust correct the problem. And if I found myself steeper than intended, I could get rid of them earlier and give the rocket more time to fall sideways by itself. You can try it out by downloading the workshop file and dropping it into C:\Users\YourNameHere\AppData\LocalLow\Intercept Games\Kerbal Space Program 2\Saves\SinglePlayer\YourSavegameHere\Workspaces. After launching, start pitching over gently at 50 m/s and keep nudging it until you're at about the 10° ring by the time it hits 100m/s, perhaps just shy. Then turn on SAS Hold Prograde. That should get you a turn where you end up in the neighborhood of 10km by 45°. If you hit that mark, stage the Thuds off when your time to apoapsis hits 50 seconds. If you find yourself shallower, perhaps 9km by 45°, then hang onto them until 55secs to apoapsis. And at 8km at 45°, just keep them until the stage burns out. Conversely, if you end up at 11km by 45°, drop the Thuds by 45sec to apoapsis. Or even earlier for even steeper ascents, at your discretion.

That's because the amount of pitchover you need depends largely on the vehicle itself - how much TWR it has on the pad, how much TWR the second stage offers, and even other factors like the sizing of the first stage and the Isp gap between sea level and vacuum of the first stage engine. Experience can tell you a first guess you can work from, but even after over 1000 hours in KSP1, I still need to test-fly a new rocket a few times before I figure out how it best likes to turn. I have a Minmus rocket that wants to pitch over just a tiny 5 degrees at 60m/s to hit 45 degrees by around 12-13 km of altitude, or it risks being too shallow. I also have a Mun rocket that wouldn't hit 45 degrees until 30km of altitude at that same cautious profile. Your best bet is to always aim to send your rockets to the pad with roughly the same sea level TWR. That will not fully eliminate the variability between designs, but it will minimize it decently. A TWR of 1.3 is a good mark to aim for, but if you prefer it a bit higher, by all means. Just try to be consistent among your designs. SAS Hold Prograde has worked flawlessly for me from day one, by the way. I've encountered a bevvy of bugs all over the place, but never with that.

Keep in mind that VRAM use is currently going up sharply, fuelled by new render engines like UE5, and new technologies like raytracing, and the general shift towards UWQHD and UHD gaming. Hogwarts Legacy won't run well with max settings even on 1080p unless you have at least 12GB VRAM, no matter the power of your GPU. A 3060 non-Ti with its 12GB will run that game better than a more expensive 3060 Ti, or even a 3070, with their 8! And that's not an outlier, but merely one example among a growing series of recent and upcoming PC releases where currently available video cards will run out of VRAM long before they run out of raw rendering power. Nvidia has been sitting on essentially the same VRAM setup for the past five years, with only a few outliers like the aforementioned 3060 12GB, and minor increases here and there. The 4070 series finally got bumped up from 8 to 12 GB, but only because there was a excrementsstorm after Nvidia originally tried to release the card that now became the 4070 Ti under a 4080 name. With 12GB, if you can imagine that. And still, most gaming hardware review outlets agree that in their testing, they found cases where the 4070 Ti already can't use its GPU power because it runs out of VRAM. With today's games. Nevermind the future. And nevermind the 4060 series, where even the Ti variant looks to be getting only 8GB. Like the 3060 Ti before it. And the 2060 "Ti" (okay, "Super") before that. The third generation of xx60 cards in a row with the exact same VRAM setup. What I'm trying to say is, don't expect upcoming games to fit into old VRAM corsets. AMD is somewhat better about it, but Nvidia especially completely dropped the ball while padding its corporate margins by a few more percent through omitting a few extra memory chips. Games going forward are going to need a lot more VRAM than entry level cards will supply. Not just KSP2. Heck, if KSP2 can remain at the current 8GB for 1080p and 10GB for 1440p recommendations by the time it releases in two years or so, it'll be considered downright frugal compared to its contemporaries. And even then, slap another 4 to 6 GB on top for if you want to run any graphics mods. And why should Nvidia care? They do have a 24 GB card for sale if you really want one! Step right up and buy, only two thousand bucks! How nice of all those games coming out to upsell the customer to the highest margin products without Nvidia having to put in any effort whatsoever... Yeah, I'm salty, can you tell? But it's a excrementsty situation no matter how you look at it. The market leader is charging an arm and a leg for cards that won't run the games they promise to run at the fidelity their GPUs could technically run them, because there's no memory to work with. The market runner up is sitting on a single compelling new-generation product, which just so happens to also be the maximum price, maximum margin, luxury halo item in their lineup, plus another card that's intentionally positioned so poorly on the market that its whole purpose is upselling the customer to the aforementioned halo card, and just refuses to release anything else. And the new kid on the block is likely gonna be sitting in the corner sniffing graphics driver glue for another two years before their technically good hardware stops being let down by their garbage software. So, no offense, but hoping your 6GB card is going to carry you much further with new and upcoming games is very, very unrealistic. I really wish it wasn't so (not least because I also still have a 6GB card!), but, nothing we can really do about it. Personally, I'll likely show the GPU makers the middle finger this time around and get a used 3060 12GB for 250€ when I build a new PC in a few months, rather than spend 700+€ on something with the exact same VRAM setup and a GPU that won't be able to flex its muscle. It'll tide me over until, hopefully, both AMD and Nvidia will set their future RX 8xxx and RTX 5xxx series up with significantly more memory. Then I might be willing to buy new again. </rant over, I promise> EDIT: Oh my dog, the profanity filter is amazing XD I'm not even gonna try and fix it, I love it.

You will get >30 FPS in space, with only your craft in view of the camera, and no celestial bodies in sight. You will also get >30 FPS in the VAB. Maybe even >60, but I'm not sure. On the space center screen, and when launching and landing or looking at a celestial body from orbit for any other reason, you'll tank to between 20 and 30 FPS. That's for 1080p. On 720p you might barely approach 30 FPS in some, but not all of those bad situations. Reason is the 6GB VRAM on your video card, and KSP2 using an extremely performance intensive way to render planet surfaces at the moment. This chokes out any video card with 6 GB or lower, especially on 1080p and up, regardless of what graphics settings you choose. I've got a 1060 6GB, same VRAM but slower GPU, and that GPU isn't even being fully loaded because the card is desperately out of memory at all times. Your card has a fair amount more memory bandwidth, which will definitely help alleviate some symptoms, but it won't change the fact that the VRAM is too small for the game to run well. So you can do what I'm doing - plan an upgrade in the next months - or hold off on buying the game until a few more patches have gone down the road. Performance already improved a bit going from initial release to the first patch. Intercept Games are also already trialing a replacement for the planetary surface renderer, but I would be surprised if it came out before summer. Such fundamental revamps take time. Your CPU and memory are fine. Both are within the range of published system specs.

@Nuke The 8-pins have a somewhat different setup than the 6-pins. They load the pins higher and use a second sense pin to keep tolerances tight. The 12VHPWR connector takes this to a whole other level and really pushes the tolerances *hard*. Really, looking at the spec, no one should be surprised that they melted down the moment they were minimally off perfectly seated. I'm honestly not sure I'll ever accept this thing in my case unless it gets revamped at least one more time. A simplified breakdown (the actual spec lists amps, not watts): PCIe x16 mainboard slot: 75W Each 6-pin PCIe power connector: 75W (2 power, 2 ground, 1 auxiliary, 1 empty) Each 8-pin PCIe power connector: 150W (3 power, 3 ground, 2 auxiliary) Each 16-pin 12VHPWR connector: 600W* (6 power, 6 ground, 4 auxiliary) *The 12VHPWR connector usually comes as a 12+4 pin, to give PSU makers a head start with getting them out in time for the first video cards. The 12-pin configuration omits all sense pins that would let the video card communicate with the PSU and negotiate how much power it wants directly. Lacking that capability, max power draw is reduced for safety reasons. Thus, unless both video card and PSU are set up to use all 16 pins on each side, the connector will be limited to 450W max. ...which, as you will notice, is still 50% more current per pin than the 8-pin connector did with two active sense pins!

The 4060 mobile variant is within striking distance of a desktop 3060 Ti. Just about 10% slower. That means the 4060 mobile is above the KSP2 minimum system spec line. It also has the 8 GB VRAM you'll want for what I assume is 1920x1200. If the 3070 mobile is equal or only a little slower than the 4060 mobile, the same statements count for it too, so either is fine. So, I'd say go for either the 3070 mobile or the 4060 mobile, whichever suits you better in terms of price and availability. I wouldn't take a 6GB model. Even disregarding KSP2, VRAM needs of games in general have started going up steeply over the past half year, with things like the first UE5 games hitting the market and such. You can expect this trend to continue.

Sounds like the classic issue with the new 12+4-pin 12VHPWR connector that Nvidia started using with this generation. The way it's built, it's really hard to tell if it's properly seated and locked in. And if it isn't, and you just happen to bend the cable the wrong way, some of the pins no longer contact properly, all the power tries to go across the few remaining contacts, which are not rated for this and melt down, shorting the card and/or PSU. You're not the only one, it happened all over the globe with the launch of the 4000 series cards. Nvidia has tried brushing it off as user error, but behind the scenes there's been a quiet redesign of the ATX v3.0 spec for this connector that makes it much easier to plug in and seat properly... And all this just because Nvidia wanted to avoid having to mount three to four 8-pin connectors on their absurdly unreasonable flagship. (I'm not kidding, that's literally the cited reason for why Nvidia worked with the ATX committee to introduce the new connector: because it allows for higher power ratings without consuming an undue amount of PCB space.) Different sensors are mounted in different parts of the CPU and measure different kinds of temperatures. Don't worry about it, so long as all sensors stay below their individual safety thresholds. Even then, the CPU is supposed to throttle to prevent overheating. You don't have to memorize all the threshold temperatures - typically, whatever monitoring software you use should warn you when they are exceeded.

Nah, this is advice straight out of KSP1. But that doesn't mean that you can't ever have fins on your side boosters. This is KSP, we can build whatever we want I'm just saying, if your side boosters wobble, and you want them to stop, and you have fins on them, try removing them to see if that helps.

System memory is great, 24 GB will easily satisfy KSP2's needs. The CPU is... honestly, ouch. That's a Nehalem based product from 2009. It's from before Intel even started using the "core i" moniker for its mainstream CPUs, meaning it is a solid thirteen generations outdated at this point. You are not merely below the minimum spec with this, you are deep in "I'm amazed the game actually launched" territory. You're lucky the devs aren't targeting any advanced CPU instruction sets (yet). They could well do that, at some point, when they start optimizing in earnest. There are no CPU upgrades for that platform that are worth it anymore. Play with this system as long as you are happy with it (or at least, can bear it), and then, do a completely new build. So yeah, video card. That's the thing you can swap. The platform is going to be a bottleneck, so you don't need to buy anything fancy. The important part is 8 GB VRAM. KSP wants tons of VRAM, and 8 GB is what I'd call the minimum for 1080p. The Nvidia 3050 offers this, and is about twice the performance of your current card. There's also the Radeon 6600 XT or 6650 XT (depending on which happens to be cheaper at the time), which would ordinarily be my recommendation since they often cost only barely more than a 3050 yet yield 40%-50% more FPS than it. However, I'm going to tell you to not take either. Both of them have a half bandwidth PCIe interface to save costs. This isn't an issue on modern mainboards which run PCIe 4.0 or 5.0. Your mainboard, however, is running PCIe 2.0. Even at full bandwidth that'll slightly throttle data throughput to modern GPUs. Halve it, and a VRAM-loving title like KSP2 is not going to be happy. Instead, look for a used RTX 2060 Super 8GB. Make sure it's the "Super" model, and not the regular 2060. That one only has 6GB, which is not enough for KSP at 1080p (trust me, I have a 6GB card, it does not suffice). Where I live, these cards can be found used for significantly less money than a 3050 costs new, despite being around 33% faster. Your system is going to be limiting this video card, preventing it from going as fast as it could... but you still won't get better price/performance out of any other 8GB card, I wager. At least if your area's used prices are anywhere near what they are over here. I could pick up a used 2060 Super for 170€ from a reputable-looking private seller right now, where a brand-new 3050 starts at 270€. A steal, if you ask me. When you do buy a 2060 Super, look at pictures of the card to find out if it has a single 8-pin PCIe connector. If necessary, message the seller and ask. Some third party OC models would have shipped with an 8-pin plus a 6-pin, and your PSU won't be supporting that, so you need a model with the default single connector. As it is, your PSU only comes with two 6-pin connectors, but given this is Seagate - a very good brand - I would be surprised if they didn't include a 2x 6-pin to 1x 8-pin adapter in the box. I hope you still have that box lying around after nearly fourteen years... you'll need it. If you don't, you'll need to buy such an adapter online.

@pandaman Depends entirely on your budget and PSU. A RTX 4070 Ti is suitable, and a worthwhile upgrade, and will last you a good couple of years. It's also very expensive and may not run in your PC, depending on the power supply. The Geforce 1650 runs just off of the PCIe slot it's plugged in, requiring no additional power connectors. That means that it puts zero requirements on your PSU. If you upgrade to almost anything else, you'll run into a situation where you'll need to connect additional power connectors. And if your PSU doesn't have them, the cards won't run. 550W is a good size, and actually quite oversized for your system as-is; it should be able to power a stronger video card with no issues. Keyword being "should". There are $30 bargain bin 550W PSUs that burn down if you ask more than 300W from them. There may also be ultra old PSUs that don't come with the requisite connectors even if the quality is right. So please take a look at your PSU. If you can name the exact model, I can look it up - or, you can simply tell us how many 6pin/6+2pin/8pin power connectors you have available, if any. And then name a budget you're comfortable spending.

Congratulations! Yes, the second flight really nailed it. Exactly 12km by 45°, which is how this rocket likes it. Now you can try and build some rockets of your own with different TWRs, and see if you can figure out how they like to fly. Note that you can vary the speed at which you pitch over and the amount you pitch over. The longer you delay (and the faster you are), the harder you need to turn. For example, this rocket, which wants a very small pitchover maneuver, could have maybe gone to 100 m/s and then made a bigger pitchover which may have been easier to place on the navball. Turning earlier is more efficient, though, so I tend to go for early turns. If you want, you can even have a rocket with a high TWR that is tilted over sideways just slightly in its launch clamps. With the right angle and TWR combination, that'll fly to orbit on its own without any WASD input at all

You can use struts (a part found at the top of the Structural tab) to stabilize the boosters. Attach the strut from the tip of the booster to the core of your rocket. If you attach a SRB to a decoupler near the top of the SRB, that's a very unstable configuration. Have the decoupler halfway up the booster. Or, have it down at the bottom while using a strut to stabilize the top. Additionally, try to avoid control authority on the side boosters. Meaning: if it has a gimbal, turn it off. If you have fins attached, remove them. Attach fins to the core stage if you feel you need some.

The initial pitchover is slightly different from rocket to rocket, depending on its starting TWR and engine selection. Usually, whenever I build something completely new, I do a few test launches and reverts to figure out how it best likes to fly, although experience lets me make educated guesses on where to start. Let me give you a sample rocket for which I know precisely when to pitch how much, so it's easier to replicate and we both talk about the same thing when questions arise. Place the downloaded file at: C:\Users\Your_User_Profile_Here\AppData\LocalLow\Intercept Games\Kerbal Space Program 2\Saves\SinglePlayer\Your_Savegame_Name_Here\Workspaces Then, next time you load this savegame, you should see a new workspace available for loading in the VAB. It might not have a thumbnail, because that might only generate once you have it loaded at least once, I don't know for sure. The rocket was something I designed on a whim to figure out how I could do a crewed Minmus landing and return with the lowest possible mass. Not sure this is the actual lowest possible, but I was fairly pleased with how this one performed. It has a launchpad TWR of 1.265, and additionally, an engine with a fairly small margin between sea level Isp and vacuum Isp. So it only barely has suitable thrust, and doesn't gain much additional thrust as it raises through the atmosphere. Both factors mean that this rocket prefers a somewhat more conservative turn, something like 12km at 45° pitch. Upon launching, wait until your speed is around 60 m/s. Then, using the D key, pitch over five degrees. That's half of the smallest circle on the navball, very gentle. Toggle SAS Hold Prograde, take your hands off the controls, and watch. The next time you should need to touch anything is during stage separation and second stage ignition (spacebar twice). Then, wait and watch some more. As your apoapsis altitude goes past 55km-ish, you can start throttling down. This delays the point at which your apoapsis climbs to its target altitude, and stops the time-to-apoapsis from running away from you; so you burn for longer and closer to apoapsis, which lifts your periapsis more and reduces the final orbit insertion dV. Feel free to go down to something like 20%, so long as your apoapsis altitude still keeps rising reasonably. You do want it to exit the atmosphere before too long, after all. Eventually, your apoapsis will be where you want it (I usually target 80km), so cut the engine and coast. Once time to apoapsis is down to like 15 to 12 seconds, slowly throttle up again. Dragging the throttle with the mouse gives great precision control. You want to find the point at which time to apoapsis stops decreasing, then throttle back again. Slowly let it creep closer to 0 as you watch your periapsis rise up, using throttle control to keep the apoapsis just in front of you until you have a nice circular orbit. And then - congratulations, you flew to orbit with only spacebar and throttle control, plus a single touch of the WASD keys! If you want, you can try and see if you can do the Minmus landing and return. Since you launched into an equatorial orbit with the exercise, you'll want to intercept Minmus at AN/DN and may need to timewarp for Minmus to be in the proper position. There's not enough dV margin for a 6° plane change in low Kerbin orbit.

That's not a bad launch. Especially the second stage flight, that was pretty much perfect. Yes, even though you didn't throttle up - or perhaps because you forgot You still had enough thrust anyway. That you got your periapsis above ground before your apoapsis reached your target altitude is a sign your ascent went really well, especially when time to apoapsis stays below 2 minutes at the same time. You also stayed hands-off, so you get an A+ for the second stage flight. Now, some notes: you said you had about 1.8 TWR on the pad, so you throttled down to two thirds thrust, to get it to 1.2. That that did not work as you perhaps expected, because the flight throttle only controls liquid engines. So the Mammoth throttled down, but the two SRBs didn't. As a result, your rocket probably had around 1.5 to 1.55 liftoff TWR. That's how you survived passing 45° by 8 km altitude. Indeed, you even had to force the rocket to turn, because it would have gone straighter on its own due to its high thrust. If you want to throttle an engine down to avoid excess TWR, I recommend adjusting the engine's thrust output in the VAB instead of using the flight throttle; that way, you can also see the effect of your changes reflected in the engineer's report. (Bonus tip: don't aim for 1.2. Aim for 1.3 instead.) Second note: you didn't, strictly speaking, perform a gravity turn. The term is called that because gravity is what pulls the rocket onto its course, and this happens hands-off - in other words, no steering input required beyond a single initial pitchover. In this video, you actively steered the rocket the entire time, all the way to stage separation. This is not bad, per se; if that works for you, and perhaps you even enjoy the task of manual piloting, then by all means, have at it. I just wanted to point out the distinction. Third note: the wings attached to your SRBs are mounted off-center, and thus unsymmetric I recommend leaving them off entirely; adding control authority to objects mounted on radial decouplers can invite flexing, and when something flexes while producing thrust, you get unstable flight. Your rocket already seems to have plenty of control authority from thrust vectoring alone. Fourth note: stage separation was ugly. The burnout sequence of stages was wrong, and as a result, you nearly had the SRBs impact the engines of the second stage. That definitely needs a redesign! Since you have 1.8 TWR at full throttle, you can easily add another tank to the core stage. This will cause the Mammoth to burn longer, so you can ditch the SRBs while the vessel is still under thrust. (Obviously, ensure that the SRBs detach first in that scenario.) Additionally, slide the SRBs down just a little bit further on the decouplers (and slide the decouplers up as necessary). This changes the point where the decoupling force is applied. If it is applied further up on the SRBs, their noses will tend to push outwards, instead of inwards, making them less dangerous to your rocket. Another option for cases where SRBs and core stage burn out at the same time is to not use radial decouplers at all, and simply attach the SRBs fixed. You leave them behind together with the core stage, If you want, you could pass me the craft file, and tell me the mission requirements. I'll give you a redesigned variant and explain each change and why I made it. If you'd rather tinker yourself based on the recommendations above, that's fine too - it's just an offer.

g0 is called "standard gravity", and is a constant which is defined as ~9.80665 m/s².

Was that a typo? Because unless you have something like a >2.0 TWR on the pad, that's going to fall out of the sky in a hurry. And once atmospheric heating is enabled, that'll get as toasty as a reentry from the Mun. The general advice for rockets with sane TWRs of around 1.3 to 1.4 is to aim for 45 degrees pitch at 10km altitude, erring slightly on the side of going higher. (Because you can correct too high by throttling down, but you cannot correct too low by throttling up, since you're already at max throttle.)

The relationship you're looking for is thrust = Isp * g0 * m, which you can rearrange into m = thrust / (Isp * g0). You can insert sea level thrust and Isp here, or vacuum thrust and Isp; the result will be the same. Just don't mix sea level one with vacuum other. That'll screw it up. The m is the mass flow rate, and should really be an m with a dot above it, but I can't type that with my keyboard, so kindly imagine it that way and call it m(dot) in your mind. Once you have calculated your mass flow rate, you can look up the mass of fuel the engine has to work with, and divide it by the flow rate in order to get the burn time in seconds.

Alt+W/A/S/D/Q/E sets a "trim" along the chosen axis, meaning a constant small input on that axis. Pressing a key multiple times will increase the trim. Useful for a plane that wants to keep its nose up, for instance. Alt+X cancels all trim and returns controls to neutral.