DMagic

I think the model numbers could be part of why this might be surprising. An i7 4650U (basically a top-of-the-line ultrabook CPU) sounds like it should be better than an i5 3470. But the two are really no where near each other. Of course, the 3470 is a 77W part while the 4650U is a 15W part, so this is really no surprise. But TDP, and even clockspeed to some extent, are not immediately obvious when looking at just the model number. A good resource for this kind of basic CPU information is Intel's database (this is usually the first result in a Google search for any specific Intel CPU): http://ark.intel.com/ Thanks. And yes, having four or six cores doesn't really have any effect on KSP. Although, I imagine that a single core CPU would do a lot worse than an equivalent dual core CPU, but there aren't too many of those around to test. I put the plot up on the first page with a link back to your post. Some of these CPU's are common enough that it should be easy to find PassMark results at a range of different clockspeeds. It would be best to have the numbers from each user, but scores from other people might at least give us an idea of the range they should be in. I'll try to look into it later today.

This is pretty much the only way to do it, at least that I know of. And yes, it's a huge pain. Though you don't necessarily have to do it from the runway. You can just launch the rover, drive it off the pad, you have to get far away (maybe onto the raised tracks to the VAB now, I'm not sure since they've changed the KSC), they launch the next part and drive the rover back onto the launch pad.

Wow, very cool, thanks Psuedo. The last three on your list are mine by the way (w/AMD 7850 GPU), they are all stock, I'm just reporting the turboboost speed. Passmark has numbers for single threaded benchmarks too. I'm wondering if those match up even better. I'll try to take a look at them later. Edit: The single threaded numbers don't seem to match up very well, the 4650U and 3470 are almost the same, which doesn't seem to reflect KSP performance at all. And I'll add this to the 2nd post, if you don't mind. Well basically, yes, but you can't just compare clockspeed and say one CPU is better than the other. There is a huge range of performance for different CPU's at the same speed. And I'm not sure what you mean by K number. Those are just the CPU model numbers, and K means they are unlocked and can be OC'd. But generally the higher the model number the better.

A high end CPU. Other components can have an effect, but the CPU is by far the most important component, and the one that is most directly affected by part count. The GPU and graphics settings can also affect performance, but that seems to be mostly related to terrain settings, light counts and maybe a few other settings. The actual parts on your crafts aren't too complicated and shouldn't really stress the GPU by themselves. If you want to test this just launch a big ship and point the camera straight up while monitoring GPU usage (MSI Afterburner, or something like it works for this) and compare with GPU usage when looking at the horizon, especially the ocean. That said, it seems from the results that I have, that there isn't much of a difference once you get above 4GHz or so on a decent Intel i5. Just look at the first few graphs in the second post. If you want to OC then one of the K part i5 CPUs would be your best bet (a 3570K, or 4670K). I haven't seen many i7 CPUs, but you'd be better off staying away from them. The Hyperthreading they offer doesn't really affect KSP and the increased cost probably isn't worth it (unless you have some other use for them). You can compare CaptainKorhonen's results with those in the second post and see that there isn't much of an improvement. TL;DR: An Intel i5 CPU - 2500K, 3570K, or 4670K and OC it. A high clockspeed, non-K part if you aren't going to OC. This is, of course, assuming you're talking about a desktop.

If your computer is as old as it sounds, there haven't been many single core CPUs released lately, then you will almost certainly need more than those three things. Like others have said, you'll need a new motherboard, and probably RAM. You should be able to get an upgrade version of W7 or W8, which don't cost much, especially if you can get some kind of deal on them (student discount, work discount, etc...). But still, you're looking at overhauling most of your system, which is hard to do on a $300 budget. As for GPU's, there are a lot of fairly powerful cards for around $150. KSP doesn't tax the GPU much, so you really don't need something very powerful anyway. If and when you do decide on components, you should prioritize the CPU. That is by far the most important component for KSP.

Maybe I'm missing something really dumb, but I don't see any Remote Command SPU in the RemoteTech 2 files. The only parts that I see are the antennae, microsat, and aeroprobe. I know that it's in the 0.5 version, but I can't get the Mk1-2 command pod to act as another control center version 2. I can see that module manager adds the "name = ModuleSPU" line to all of the probe cores, but nothing is being added to the command pods. Is this something yet to be added, or am I just doing something wrong? I've seen the issue brought up a few times in this thread, but I've never really seen an answer, at least not one that made sense to me.

Thanks. Never underestimate the usefulness of a thesaurus in naming your crafts. And yes, bangability is always one of my chief design goals. After posting the thread I realized that the Diggatron is sort of, um, sadly phallic. So I guess a bangability rating is quite appropriate.

I wasn't planning on landing on the Mun and returning, I was just going to test out docking. So I had a pretty sloppy launch and ended up in an elliptical orbit at around 300*150km, with almost full tanks in the lander and orbiter. I didn't think that I would have enough, but I tried the landing anyway. And even though I somehow got into a retrograde orbit around the Mun I just managed to get down and back again. With the lander full, or almost full, of fuel you should have no problem landing and taking off again. At that point it actually requires very little fuel to break Munar orbit and get back to Kerbin, you can even use RCS if you have to.

I always say it like Monday.

Running two copies of could be really useful, I think. Instead of just sitting there watching a 30 min ion engine burn, or waiting for Mapsat to scan, you could start another instance of KSP and tinker around in the VAB. I'm not sure how running two copies with the same save file would work out. But you could easily make something and just import it to your main save.

PhysX does not only run on the GPU. There is a hardware implementation that runs on the GPU and a software implementation that runs on the CPU. You're above statement may reflect that, but it's hard to tell as the sentence seems to be self contradictory. http://physxinfo.com/wiki/Category:PhysX_SDK#Common_delusions But at any rate, the implementation used by Unity does not support GPU PhysX. http://answers.unity3d.com/questions/290454/physx-cpu-consuption-rather-then-gpu.html http://docs.unity3d.com/Documentation/Manual/Physics.html If you are referring to the PhysX indicator that you can turn on in the nVidia control panel (that puts a big PhysX logo on screen), that should indicate whether physics are being run entirely on the CPU or if there is also GPU physics running. But you're right, I haven't tried that out because I don't have an nVidia card. http://physxinfo.com/wiki/PhysX_Visual_Indicator I'm not really sure how Unity uses PhysX without requiring the system software. Some newer versions of PhysX don't require that, but I don't think Unity uses those versions. You aren't the first person to ask that question though, and that might also affect how the PhysX Visual Indicator works, or doesn't work as the case may be. http://stackoverflow.com/questions/7097747/how-does-unity3d-use-physx-without-requiring-the-physx-runtime There is no Half Life engine. There is the Source engine which does use Havok. This is just another physics middleware, owned by Intel, and used by many games. The GPU has nothing to do with Havok (there is also another physics engine that runs on the GPU, Bullet, but that isn't relevant here), and Havok has nothing to do with Unity or KSP. Havok FX was going to be an alternative that could be used by the GPU, but I don't think anyone ever made anything that actually uses it. http://en.wikipedia.org/wiki/Havok_(software)#Other_products That Wikipedia article is actually the first place I've read that says PhysX completely offloads physics calculations to the GPU if hardware acceleration is used. I always thought the GPU did some of the calculations while the CPU does others. In any event that doesn't matter here, since Unity and KSP have no support for hardware PhysX. I'm not sure why this matters here. I know that people got upset about this, and that there have been ways to get around this. As far as I know it's still not possible to run hybrid PhysX, where you have an AMD card for graphics and an nVidia card for PhysX without using the hacks from that link. Unity isn't a mac engine, or a browser engine, it's a multi-platform engine. It works on Windows, OSX, Linux, web browsers, iOS, Android, etc... I think this would be great, too. And it would solve the OP's, and many other people's problems with RAM. But I think the reason for the lack of focus on a 64 bit .exe is that it's a multi-platform engine. ARM has only recently created a 64-bit architecture and I don't think any CPU's have been released using those instructions. So it seems unlikely that the Unity people will put much focus on supporting a feature that many of their platforms can't use, and most of their software doesn't really need anyway.

Oh yeah, sepratrons can really easily blow up a fuel tank if you aren't careful. That's why I usually point them more up than out.

This is a good idea. I'm always having problems trying to fit parachutes on, because there's usually only space for one stack mounted version. And this is another idea that's ripe for stock part duplication, just like the bigger sepratron idea a few threads down (or maybe up by now) the list. It shouldn't be too hard to just create a duplicate of the radial parachute with drogue chute properties. http://forum.kerbalspaceprogram.com/showthread.php/44232-bigger-sepatrons

I tried it out both ways, separating the lander docking port first, or blowing the stack separator, then separating the lander docking port, and both worked for me. Once the lander's port is free you shouldn't have to do anything more with it. The command module has the RCS units so obviously you have to use that to dock; you just have to open the shielded docking port on top and it should work. And just to try it out, I confirmed that you can fly to the Mun, land, take off, rendezvous with the command module, and get back to Kerbin. I didn't fly very efficiently, but even still I had just enough fuel for all of that.

I've been doing this a lot lately to great effect. And with the new part .cfg system it's dead simple to make duplicates of stock parts with tweaked variables that would work perfectly for this kind of thing. It's nice when mod parts are available, but sometimes it's easiest to just change a stock part a little bit to fit exactly what you need, and you don't lose that stock feel, either. I'm surprised I don't see people mention this more. Hmm, maybe a quick tutorial is in order...

Strange, but at the same time totally not strange. Last months National Geographic cover story was about the crazy early solar system. Uranus and Neptune possibly switched places in their orbits causing all sorts of craziness. http://ngm.nationalgeographic.com/2013/07/125-solar-system/image-gallery#/2

And just as important to note, while Jupiter may pull the Sun around, it's pulling the Earth around at the same time. So if Jupiter is on the opposite side of the Sun, it's pulling the Sun away from the Earth's orbit, but it also pulls the Earth towards Jupiter, and therefore, towards the Sun. My guess is that, over the 10 year orbit of Jupiter, there is only a negligible total impact on the distance of the Earth from the Sun. And, as you mention the other planets are scattered all around, pulling the Sun and the Earth this way and that way, making it all the more unlikely that this causes any real, short-term effects on the Earth's climate.

Well that's interesting, I think pretty much everything you just wrote is wrong. Go to the Unity site if you really want to understand why. But in short, Unity uses PhysX, but doesn't support GPU PhysX, it is not a browser engine, and the developers have explicitly stated that they are happy with Unity and that they aren't going to change the engine. As for the original post, it would be nice if Unity's 64 bit .exe worked better, but it is apparently very buggy under Windows and OSX. So until that is improved there is basically nothing that can be done to increase the amount of RAM used. Loading parts only when they are used could help, but that's been discussed a thousand times already, so I'm not expecting that to change.

Thanks Steve, I added this to the older Intel CPU graph. Yours performs similar to the Q6600 at 2.4GHz. That's weird about the docking. I tried this once and it worked ok. My method, I think, was to EVA a Kerbal over, detach the docking port from the adaptor first, then activate the stack separator, open the docking port and dock using the command module. It worked fine for me. However, I have had problems before when detaching a docking port in-flight like this. It seems that it can cause the docking port to get stuck. They behave like you describe when this has happened to me. You can check if this is the case by opening the persistence file and searching for "state = acquire" without the quotes. If you find a docking node with that line you can just change it to "state = ready" and it should fix the problem. I've had this happen many times, but I've never been able to reliably replicate it on a stock install. Hopefully you've stumbled onto a way to make this happen. I'll look into this later and if I can recreate it then I'll submit a bug report. This is one of the docking port bugs that's been giving me problems for a long time, so it would be great if this could help find a solution.

Here's my submission; I call it Indifference, Curiosity's lazier relative. Full mission report here: http://forum.kerbalspaceprogram.com/showthread.php/44140-Indifference-A-Curiosity-First-Anniversary-Tribute

To commemorate the upcoming first anniversary of Curiosity’s landing on Mars I present Indifference. Curiosity’s lazier, older, (balder?) fatter relative. I’ve been waiting for a few more updates before I do more than tinker around here and there in KSP. But seeing as how others have been launching Duna rovers to celebrate Curiosity’s landing I figured I would try something quick and dirty. So I built myself a rover and launcher from scratch using what I call Stock++. The first + is for Engineer, because I’ll be damned if I have to sit around guessing how much delta-v a stage has (or calculate it myself, ha), or constantly play in map mode just to figure out my orbital parameters. The second + is for all of the stock parts that I’ve duplicated, or in some cases triplicated, and tweaked. These include reaction wheels, antennae, rover bodies, and a few others. I altered their parameters accordingly, so none of them are what I would consider cheats, they’re just variations on stock parts. After a few hours building and testing my design the rocket is ready to go. And here it is on the launch pad with the rover, skycrane, and orbital relay perched on top. The rover itself is made up of about 100 parts, with another 150 or so parts for the skycrane and atmospheric entry system, then another 100 or so parts for the launch vehicle (and no struts on that, I'm surprised it didn't fall apart). The auxiliary fuel tank on the launch clamp allows for main engine startup first, followed by SRB ignition and launch clamp separation. Once the tower is cleared the liquid boosters ignite. There is no asparagus staging or fuel cross-feed here, so the main engine cuts out fairly soon after liquid booster separation. The orbital insertion stage worked out nicely, with just enough delta-v to put the rocket in an 80km orbit. Once the Duna transfer window opens the rocket makes one long ejection burn. Only a very small correction burn is required to setup the final encounter. After a long trip the rocket nears Duna, as Ike orbits close by. But now I had a dilemma. The rover is not designed to get into orbit around Duna before landing, it’s on a direct descent path. But I need the orbital relay to get into orbit before the rover begins its landing. And I obviously can’t do both at the same time. So I came up with this. A sepratron powered, spin stabilized, ejection system that boosts the relay ahead of the rover. I wish I had a recording of this, as it worked perfectly. A 5o twist of the sepratrons was enough to spin up the probe, followed by separation of the orbiter and deployment of the solar panels. And best of all, it worked to get the relay there ahead of the rover. Those four sepratrons gave it enough of a boost to get it to Duna with just over three hours to spare. Only a small correction was needed using the probes main engine. After a dip into Duna’s atmosphere the probe settles into a stable 125km, equatorial orbit and deploys its antennae. Back to Indifference now, the transfer stage makes its final burn to setup the approach path, then separates and falls towards the planet’s surface. And the rover prepares for descent. And now the fun part begins. The heat shields protect the vulnerable wheels, while the ablative coating on the exposed sections burns off. After peak heating the parachutes are deployed. There is one regular drogue chute, and four of my custom made, 1/2 scale, Mini-Mk25 chutes, these have about 1/4 of the drag, but fully deploy a little earlier than the full size drogue chute. With the heat shields no longer needed, they begin their two-stage decoupling process. First, the two outer sets are pulled down and out using a single sepratron motor. Then the center shield fires directly down using a pair of sepratrons. With the Mini-Mk25's deployed Indifference begins to lose most of its horizontal velocity over the surface. The main drogue is cut loose before it fully deploys (wouldn't want to make things too easy) as the first stage skycrane prepares for active flight mode. Around 250m above the surface the remaining drogue chutes are cut loose and the skycrane enters fully powered mode. With it's descent velocity slowed to nearly zero, the first stage skycrane separates. A probe core and reaction wheel keep the now departing skycrane stable and a small radial engine pushes it sideways. The second stage skycrane, known informally as Skycrane 8, The Ocho, then powers up to gently lower Indifference to the surface. The Ocho carries Indifference down the rest of the way. Once safely on the ground the reaction wheel stabilized skycrane decouples and lifts off, again, pushed to the side by an auxiliary motor. It appears, unfortunately, that one wheel was slightly damaged in the landing, but thankfully I packed a wheel repair kit, otherwise known as Notepad, with the rover. And for those wondering, I'm not manually taking screenshots during the descent stage. FRAPS has a great function that automatically takes screenshots in intervals as small as one second. You can end up with a ton of pictures if you leave it on for too long (you can set a key to activate and deactivate it), but it works great for these high pressure moments when manually taking screenshots just isn't an option. All systems appear intact, and with the damaged wheel repaired, Indifference deploys its suite of antennae. On the front you can see two steerable, high-gain antennae. On one side is the backup, low-gain antenna. And on the back we have the large mast antenna, a 2X rescale called the Communotron 116. In the picture on the right Indifference tests out its retractable drill known as the Diggatron 16, a 1.5X rescale of the Cummunotron 16 with a toggle deployment option. If you look carefully you can also see my special made, Not-Rockomax Dead Weight modules installed next to each wheel. These bring the center of mass close to the bottom and prevent rollovers. With all systems checking out Indifference sets off to the southeast. Finding a safe spot it powers down for the night. As the sun comes up and Ike looms overhead, Indifference sets off for another long drive. A few samples are taken from some interesting rocks along the way using the Diggatron. That may look like a strut on the lower section of the rotatable drill arm, but it's actually a sample sluice tube that carries material from the drill to the analysis cube, perched on top of the mini rover body section. Well, well, well, what do we have here. Not so lazy after all, it seems. Spotting the mast cam of its apparently overexerted brother, Indifference probes for signs of life. Finding nothing from the old rover, Indifference sets off for destinations unknown.

Since the purpose of sepratrons is to pull spent stages away after decoupling, and since I've used them this way hundreds of times, I would definitely say that you have a bug. And parachutes work the same way, you can see it in that picture, so they don't seem to need that parameter. I've never tried liquid engines this way though. But it seems odd that they wouldn't fire after decoupling as long as you are throttled up. I do see that line Supernovy mentioned in the sep .cfg file, but that seems to be the only part with that line, at least the only one that I could find.

Wow, very nice design. Can you actually land the first stage and put the upper stage into orbit at the same time? I can imagine the upper stage drifting to its apoapsis while you handle the landing; it would be awesome if there were enough time for that.

The Duna rover mast is still in the same place too.

Task manager can be wrong, mine says 3.85GHz when the max turbo is 3.6GHz. CPU-Z gives values that make more sense and should be correct. But if your CPU really is stuck at 0.75GHz that's a problem. Maybe there is some BIOS setting that needs to be changed. It's hard to know for sure what the problem could be.