godefroi

Yeah, that's crazy. I'm currently running an i5-2500K, and I don't suffer TOO much for it, so you should be OK.

That's pretty ancient. You can get pretty much the same performance out of, say, an i5-6500 for less money and 33% less power consumption. You also won't be on a 5-year-old motherboard and CPU combo. Not that I'm saying don't do it, just be aware that you're paying as much for that as you would for equivalent-speed newer hardware that has other advantages (the 33% less power consumption is not insignificant, unless you're counting on the computer to heat your house).

Both things exist simultaneously in the same place at the same time, because science.

Quantum superposition.

It'd need to be a big bonus, jets can bring the launch mass down by many tons...

Is "weight of craft at launch" in tons?

Well, there are those that would say, if NASA does it...

So, I was browsing around on /r/space today, and I noticed this picture of Discovery being rotated to the vertical. Notice how NASA has clearly clipped the OMS pods into the Mk 3 body section at the back:

Threads do NOT equal cores. Threads are logical units of execution; one of the operating system's major functions is to schedule these units of execution onto the physical hardware (or cores). The "Thread" in "HyperThread" is misleading; what's actually happening is that the hardware is telling the operating system that there's two cores where there is actually only one. How many threads a piece of software uses is totally orthogonal to how many cores are in use. Depending on what the threads are doing, the OS may very well schedule all the threads onto a single core, of if it wants, it could schedule a single thread on multiple cores (though not more than one at a time). Much work goes into making operating systems smart about how this happens, and it's very advanced stuff. All the number of threads gives you is a general kinda-idea about how many cores MIGHT be fully utilized, if all other conditions were ideal. and the situation is otherwise normal. When a thread is created, the software does NOT specify whether it's an "HT" or "non-HT" thread. The documentation for the function that creates a new thread in Windows is here if you'd like to take a look. Nowhere does it mention HyperThread. I got the number 29 from the Windows task manager. I assure you it's right. If you don't believe me, feel free to use the task manager, Powershell's Get-Process cmdlet, Linux' "top" command, or any other appropriate tool to look for yourself. At any given time, your operating system is managing orders of magnitude more threads than it has cores available to it. This has been true since long before multi-core (or even multi-processor) machines were common. Unless you're older than the average "gamer", I've been writing software for a living since before you were born. I am not guessing at how computers work, nor am I repeating something I read somewhere else.

Nope. They don't. The operating system schedules threads on "HT cores" just like normal cores. Games aren't designed to use "cores" either, only threads. Unless a game set up specific affinity masks for particular threads (and they don't), having more threads than cores will mean that the game (or word processor, or whatever other piece of software) can/will use as many cores as you have. Now, let's see how many threads KSP uses: ah, look, it's 29. Imagine that. That means that KSP could use up to 29 "cores" (whether HT "virtual" cores or "real hardware" cores, doesn't matter). In the real world, however, most of the interesting work is being done by one or two of those threads, so your software won't "fully" utilize more than a couple cores, but that's the nature of the beast; you don't simply "turn on" support for more "cores". All you can do is parallelize the work; spread it across more threads, and let the operating system do what it is designed to do, i.e. schedule those threads on as many cores as it can.

That's possible, but I'd be somewhat surprised if the slowdown was noticeable.

Synthetic does not mean wrong. Benchmarking one game and seeing an improvement does not mean that other games will or will not see an improvement. Also, there's no such thing as "hyperthread" support, where software is concerned. It's a hardware trick that makes a single core look like two cores (but not necessarily perform like two cores, depending on the particular load).

Whether or not Hyperthreading increases performance depends completely on the load. KSP's physics is probably the kind of load that does not benefit, but I haven't run any tests. Remember, if you read it in this thread, and it had any of the words "thread", "core", or "hyperthread", it's probably false.

I'm with @sarbian; practically nothing that has been posted here is accurate or meaningful.

I'll take one of @CliftonM's free tickets.

So I did SCIENCE. I used MechJeb (limit AoA to 5 degrees, no other options enabled), and tested the difference between fins and brakes for a very aerodynamically-unstable rocket. I call it, the PANCAKE ON A STICK. It features crazy TWR (starts at 1.85, ends >8) and bad aerodynamic design. Here are the results: No stabilization (apart from the Mainsail's gimbal): failed to make orbit failed to make orbit Fins (4x AV-R8): made orbit with 957 m/s dV left made orbit with 936 m/s dV left Airbrakes (4, on bottom): failed to make orbit failed to make orbit Airbrakes (4, on top): failed to make orbit failed to make orbit Airbrakes (top+bottom): failed to make orbit failed to make orbit Airbrakes (many airbrakes all over the rocket in various configurations): failed to make orbit Airbrakes + lots of reaction wheels: made orbit with 884 m/s dV left

So, for a rocket which requires no aerodynamic stabilization, airbrakes work as well as fins?

This hasn't been the most efficient way to launch for a long time (since 0.90?) Usually, nowdays, this will result in a flipping rocket. Best case scenario, it's very inefficient. Start your gravity turn at ~1000m. Don't try to accelerate too fast in the lower atmosphere. Shoot for a takeoff TWR of ~1.4-1.6 or so. You should cross the 45 degree mark at somewhere around 18-22km or so. Learn to watch your "time to apoapsis". Keep it at, say, 1 minute or so all the way up. If you start getting closer than 1m, pitch up; if it starts getting way ahead of you, pitch down. Edit: obligatory Manley:

So what you're really asking for is an .MSI? Make one yourself. Or, make a self-extracting .zip file. Life's too short to sweat a couple Steam-related .dll files.

So I'm not sure what you're asking then...?

You already HAVE an alternative to the Steam installation. If you don't want Steam, don't run Steam. If you want your installation to be somewhere else, take the Kerbal Space Program folder and put it somewhere else. You don't need to delete any files or anything like that; just use it as you would use a non-Steam install. Edit to add: if Squad ever goes out of business, or Mexico City gets hit by an asteroid, I'll still have access to my KSP. Also, I never have website issues when I update. Is the Steam life perfect in every way? No, but I wouldn't recommend against buying KSP on Steam.

You suggested a demonstrably worse solution than fins, then got angry when people suggested a solution other than the one you chose. If you didn't want feedback, why post, right? My primary cause of flipping is trying to launch lightweight pancake-shaped payloads on top of toothpick-shaped rockets. I believe that this is even more unrealistic than the tankage setup. I essentially *never* have an issue launching rocket-shaped things, though I usually put fins on the bottom out of habit (I love you, AV-R8). MUCH more draggy than fins, especially when those fins are edge-on to the airflow (as they ought to be if your rocket is headed in the right direction. Indeed, fins are the *perfect* solution, specifically because they only add drag when they need to (i.e. when they're not edge-on to the airflow) and they automatically add more drag when more is needed (the more sideways your rocket goes, the more drag they add).

No (apparently), and yes (in my opinion), in that order. You asked. Indeed. Two big mistakes that I often see are 1) turning too far from prograde too low in the thick atmosphere, and 2) trying to go too fast in the low atmosphere. If your setup is resulting in the shift of your CoM too far back, then the only thing I can think you're doing is stacking lots of short tanks on top of each other and attempting to do orbit all in one stage.

You can copy the Steam version anywhere you like. It's not tied to Steam in any way. I don't even use Steam to launch mine; it's only there to keep one of the copies updated.

You should play the game the way you like it. If that means letting MechJeb fly all your missions on autopilot because you mostly like building rockets and seeing the scenery, then more power to you. If that means using MechJeb for informational displays and never letting it fly a rocket, then that's also great. Your game, your way, that's KSP!