godefroi

It's not, though, or not exlusively that. The stock bug fix mod had, for a time, a fix that disabled the insta-gimble. It made things worse, not better. I believe it's PID auto-tuning that's off. SmartASS does it, and SmartASS suffers from much less wobble.

Must haves? VOID (best HUD I've yet used; KER's is decent, but VOID's is better). PreciseNode Kerbal Alarm Clock MechJeb (for the advanced transfer window, alt-tabbing out to a browser is a hassle)

I doubt it. The upgrader would've simply overwritten files, it wouldn't have read them and used the values it parsed out of them to rewrite them. And even if it did, why would it have done it differently for this user than it did for everyone else? Pretty sure not. We don't have rights to redistribute those files. If you use Steam, just run a repair, it'll just fix the files that are messed up, without downloading the whole thing. If you don't use Steam, well, why not?

As far as I know, Smart ASS is applying the same inputs that the player does, it's just smarter about when.

Here's what we know: Each thread definitely does not equal one core. Not in the SMT/HyperThread sense, and not in the multithreaded programming sense. Each core *CAN* consist of a number of hardware threads/virtual cores. The processor I'm writing this on, for example, does not (i5-2500K). Each virtual core can handle multiple threads, but only one can actually be active at any given time. Same goes for real cores, if you're not on an SMT-capable processor. KSP is definitely multithreaded. *HOW* multithreaded is a question I can't answer. How many of the 33 threads were doing meaningful work? I don't know, it'd take deeper investigation than I did. The more evenly divided the work is between threads, the more benefit we see from additional cores in our processors. It's not clear to me how much of KSP's time is spent calculating physics. Many people have stated that it's a majority, and it's definitely a possibility. Note that the more time spent in physics, the more the PhysX performance improvements help us. If CPUs exist that present more than two virtual cores per physical core, I'm not aware of them. They certainly could exist, I haven't kept up on this stuff nearly as closely in recent years.

I appreciate that you're trying, but nearly everything you wrote here is factually incorrect. You're confusing multithreading (the programming concept) with "Simultaneous Multi-Threading", or what Intel calls "HyperThread" technology. SMT is the practice of creating "virtual cores" out of a single core, allowing multiple threads to execute at the same time on the same core (sometimes). This works because some CPUs have hardware that sometimes goes unused by a single thread (for example, a CPU might have multiple ALUs per core); and so the CPU can expose multiple virtual cores, and provided two threads don't both need all the resources, they can both execute simultaneously. If they both need something that there's only one of (such as the FPU), then they can't execute simultaneously, and the two "virtual cores" perform just the same as a single core. Multithreading (the programming concept) is the practice of breaking the program into separate "threads" of execution, each of which can be thought of a bit like a separate program. Because your CPU generally spends most of its time waiting for things (reading from disk, writing to disk, reading from the network), it can suspend one thread and execute another, instead of sitting around idle. Generally, threads are not assigned "affinity" (which locks them to a single core), because CPUs and operating systems are pretty good at deciding what to execute, when, and where. Setting affinity usually leads to decreased performance, where CPUs go back to sitting around waiting for non-CPU things to do their thing. KSP right now is multithreaded, and is multithreaded regardless of whether you have one, ten, or a hundred cores, and whether any of those cores use SMT or not. KSP will use any cores that are available to it. Sitting here looking at the KSC, KSP has 33 threads going. Unless you have more than 33 cores, KSP will use up to all your cores simultaneously, if the OS decides that it needs to (i.e., all those 33 threads need to do work at the same time). Most likely, all but a small number of those threads are sitting around doing nearly nothing. - - - Updated - - - As far as I know, that's true with Intel as well, if you're counting "hardware threads" instead of "cores". In Task Manager, look at "cores", not "logical processors". If newer Intel CPUs have multiple FPUs per core, I'm not aware of it. They do have multiple ALUs, but like you said, most of the interesting work being done in KSP is going to need the FPU. Yeah, in the VERY olden days. If you've never used anything but Windows, you're definitely too young to remember life in a single-threaded world. Even the PDP-8 had preemptive multitasking.

Note that what's being shown there (in the task manager) is actually the "working set size", not the "how much ram is in use". The WSS here is the important number, but it's an important distinction.

I've played on Windows for hours (8+) at a time, and never crashed 1.0.2. My current modlist is 27 long, though I don't use a bunch of big parts packs (no B9, no KW). I do turn off the gauges whenever I see them, though.

Not cheating if the contract happens to come up. Cheating if you cancel contracts until it comes up.

Right, I know; the point wasn't to get to orbit, the point was that different rockets would have significantly different "optimum" ascent profiles. There's no one-size-fits-all gravity turn.

Your rocket proved unstable in my testing. Also, I don't believe that putting MJ under the nosecone affects anything; only stack-attached parts are shielded from the airstream, radial-mounted parts have normal drag wherever they are (unless it's in a fairing or cargo bay). Here are my findings (MJ 2.5.0.0-455, with corrective steering, auto-warp enabled; orbit altitude 75km, inclination 0*). My test rocket consists of: Aerodynamic Nose Cone MK1 Lander Can (AR202 MechJeb stuck on the side) FL-T800 FL-T800 (4x AV-R8 winglets even with the bottom edge) LV-T45 Swivel This rocket has, according to KER, 1.76 TWR on the pad, and 3,678 dV. VOID and MJ concur (but I think they're both using the KER code now...). Note that my end dV numbers are all negative. This means that MJ never achieved orbit with this rocket. [table] [tr][td]start alt[/td][td]start vel[/td][td]end alt[/td][td]final angle[/td][td]turn shape[/td][td]end dV[/td][/tr] [tr][td]5[/td][td]75[/td][td]45[/td][td]0[/td][td]70[/td][td]-244.2[/td][/tr] [tr][td]5[/td][td]75[/td][td]45[/td][td]0[/td][td]60[/td][td]-222.5[/td][/tr] [tr][td]5[/td][td]75[/td][td]45[/td][td]0[/td][td]50[/td][td]-217.3[/td][/tr] [tr][td]5[/td][td]75[/td][td]40[/td][td]0[/td][td]50[/td][td]-lots (and lots of shock heating)[/td][/tr] [tr][td]5[/td][td]75[/td][td]50[/td][td]0[/td][td]50[/td][td]-187.5[/td][/tr] [tr][td]5[/td][td]75[/td][td]55[/td][td]0[/td][td]50[/td][td]-177.9[/td][/tr] [tr][td]5[/td][td]75[/td][td]55[/td][td]0[/td][td]40[/td][td]-224.6 (and some shock heating)[/td][/tr] [tr][td]5[/td][td]75[/td][td]55[/td][td]0[/td][td]60[/td][td]-206.9[/td][/tr] [tr][td]5[/td][td]75[/td][td]60[/td][td]0[/td][td]50[/td][td]-178.5[/td][/tr] [tr][td]5[/td][td]75[/td][td]60[/td][td]0[/td][td]60[/td][td]-218.5[/td][/tr] [/table] Note that this is all just golf. There is no globally-optimum ascent profile; otherwise, MJ would just use it and offer no option to edit it. It has a lot to do with TWR, staging, and engines.

It's a kind of nonsense measurement, because it has as much to do with the engines used (and the engines still on the ship) as it does with the ascent profile. While it's meaningful as a sort of "orbit golf," it's not generally useful for comparing ascent profiles across different ships (and different payloads).

I don't mean during ascent, I mean during a burn. Even in space, where aero is not involved, MJ (and RT) are all over the place while executing nodes.

I've got the same symptoms. Not only does MJ find it impossible to hold a heading, so does RemoteTech's flight computer. While it may be better in the atmosphere (I don't think so), it's definitely much worse in space. I ended up disabling it.

Dynamic Deflection was the one, thank you very much!

I thought for sure I saw somewhere a mod that would gradually increase the range of control surfaces (and gimbals) in order to reduce the SAS-fighting that goes on with the new atmo. Now, however, I can't find it. Does anyone know of a mod like this?

Sure, no problem. Easiest bug report ever!

I just went into the VAB, clicked the VOID icon in Blizzy's toolbar, clicked configuration, unchecked "use blizzy's toolbar", and the icon went away, but nothing showed up in the AppLauncher down below. I added a pod, launched, the icon is in blizzy's toolbar. Take the same steps to remove it from the toolbar, and it shows up in the AppLauncher. Recover the vessel, re-ender the VAB, no icon either place. Launch the pod again, the icon is back in blizzy's toolbar.

The plugin is written in Boo, which is a Python-inspired language. If you want to make it usable going forward, I'd port it (or even decompile the code into C#), since there are few Boo programmers, and it might be a dead language. My guess is it's not going to be trivial, since the code that this plugin interacts with has essentially been rewritten from scratch since it last worked.

I'm a user and lover of VOID, but I've noticed one issue in the current (1.0) versions: VOID doesn't seem to respect the setting on whether or not to use Blizzy's toolbar. I'll change it to use the AppLauncher, and then it'll switch itself back. Is this a known issue?

The Shuttle SRBs were VERY heavy. The two SRBs constituted 69% of the shuttle's take-off weight. They also didn't have very good ISP, at 237 (sea level) to 269 (vacuum). The Kickback's ISP is a bit low, but it might not be heavy ENOUGH.

What's your thrust to weight ratio? Keep it to 1.5, that night help.

1.0.1 and 1.0.2 made some significant changes to the heat equations. Might want to update the OP.

The real question is, was this rocket stable in 0.90 with FAR?

Except the fact that there's practically no air up there? What did you want your jet engines to breathe?