DMagic

I actually like this idea, but it would probably be best to wait for Squad to implement tweakable fuel tanks. Then you could add different fuel types with different characteristics and use them in whatever fuel tank you want. I really like these parts, it's great to have more options for small probes and such. I do have one small suggestion though, change the order of the update log on the first page. It's always easier to put the most recent update at the top of the log so that we don't have to scroll down to see what has changed.

It's possible that they are bugged. There is still a lot of weirdness involved with the docking ports and doing things like putting them above a decoupler or saving and loading while docking can cause issues. You can check in the persistence file for the line "state = acquire" if that is present on any of your docking ports then they are probably bugged and won't dock. Change this to "state = ready" and it should be fixed. Just be careful poking around in the persistence file and make backups.

Updated the original post. It should, I hope, provide a clearer and more straightforward explanation of the 0.21 SAS system. I also added details about SAS modes, and RCS changes discussed in C7's blog post from a few weeks ago.

That's interesting. KSP doesn't have very demanding graphics, but there are obviously limits for weaker or integrated GPUs. Terrain settings (and the settings.cfg tweak mentioned before), textures, aerodynamic FX, AA, and render quality are all options to consider when using a low end GPU. It's probably a good idea to move them all down at least 1 notch , and turn off AA, if you get slow performance even with low part counts. It's also interesting how much a of a difference in total run time a small, 1-2 FPS, change makes. That shaved off almost 5 minutes from the time it took to get the same stage during your first run.

This. Regardless of how fast your processor is you will always be able to push performance below 60FPS. Enough parts will bring any CPU to its knees. For laptops there are a few things to keep in mind. One, is that you'll probably have a pretty crappy GPU, at these prices you'll never get anything really powerful. So you should take advantage of the terrain settings tweak described over in this thread: http://forum.kerbalspaceprogram.com/showthread.php/43253-Default-Terrain-Quality-Without-most-of-The-Lag%21. That seems to be the only aspect of KSP that really hits the GPU hard; it's not noticeable on relatively powerful desktop GPUs, but it's pretty obvious on weaker GPUs. And the other thing, is that no mobile CPU will get really good performance with high part-counts. That i5-3320M for instance, is somewhere in the same neighborhood as my i7-4650U (similar turboboost speed, and relatively close performance/clockspeed). And my CPU does alright, but it'll never get 60FPS with anything more than 75 or so parts. I agree with the suggestion to go with dual core over quad core. It won't make a difference in performance, and those high end mobile parts are really expensive, as in $400-$600 just for the CPU. My CPU performance thread doesn't have many results for mobile CPUs (feel free to download my rocket and add your own), but it should give you an idea of what I mean. None of the CPUs that I have data for get much above 20-30FPS, even when down to fewer than 150 parts. Go there for info about this: http://forum.kerbalspaceprogram.com/showthread.php/42877-CPU-Performance-Database

Yes, but the fuel line has to go from the tank to the converter, not the other way around. See here: http://forum.kerbalspaceprogram.com/showthread.php/35664-Kethane-Usage-and-Proper-Fuel-Routing

No purpose, pfft. You just haven't been trying hard enough. I mean, anyone can land on Ike, but doing it with only ion engines, that's a challenge. Also, this, my manned Minmus ion lander: I've got a whole thread full of these: http://forum.kerbalspaceprogram.com/showthread.php/30329-Ion-Engines-Everywhere-My-Attempt-to-Land-As-Many-Places-As-Possible?highlight=engine+landers. Though I never did make one for Dres...

This is great, and helps a lot with relatively weak GPUs. But it should be noted that the settings file has three sections for terrain. Each preset (low, default, and high) has it's own section in the settings file. So if you want to keep terrain on high, you have to scroll down a bit more to get to the "High" preset values. The simplest way is just to change all of the them. Just open the settings.cfg file, push Ctrl+F, and search for ocean. This should bring you to the first ocean terrain setting value, for "kerbinOcean" under the "name = low" list. Just go down the list and change all nine ocean values as described above. Then you should be good regardless of what terrain preset you choose in the KSP, in-game, settings menu.

I made several updates on the first page. Most importantly is a look at the effect of terrain settings on performance with a weak GPU. I recently switched from an AMD 7850 to an AMD 7750 and noticed a significant frame rate hit when looking at the horizon or ocean. This is a well known problem and there is a thread detailing how you can fix this: http://forum.kerbalspaceprogram.com/showthread.php/43253-Default-Terrain-Quality-Without-most-of-The-Lag%21. This basically changes the ocean terrain setting to low, while the actual terrain setting can remain on default or high. I put this plot in the fourth post about testing conditions, but I'll put it here too. This is with the terrain setting on default. You can see that keeping the horizon in view has a huge effect on performance, it basically becomes GPU limited at 20 FPS until you get above 160km in altitude. Leaving the camera pointed to the side (i.e. not touching it once the rocket loads) helps, but there is still a performance hit. The best solution, and the one I made more clearly in the first post, is to tilt the camera up a bit. Just enough to keep the horizon out of view is enough to alleviate the terrain performance hit. The last test, shown in green, was done using the method described in the link above (changing the ocean "minDistance" setting to 3), which helps, but still becomes GPU limited at about 30 FPS when keeping the horizon in frame (this is the worst case scenario). You'll also notice that none of this has an effect on performance during the first stage. That dip in framerate around 60s occurs during the first staging event, when the bottom ring of SRBs are dropped. It's only later on, when more of the terrain becomes visible, that this becomes a problem. My recommendation for testing is to move the camera up a little, enough to keep the horizon out of frame. This is especially important if you have a weak GPU with a relatively powerful CPU. And while your thinking about it, you might as well make that setting file change, it can make a big difference. For high-end GPU's this shouldn't really matter. I never really had a problem with the AMD 7850, which I would consider an upper mid-range GPU.

Yeah a lower orbit is better for interplanetary burns. Another reason to keep it orbiting Kerbin instead of Minmus, even if you refuel from Minmus, is that it's much easier to find windows for transfers to other planets. Being in orbit around Minmus really complicates this and I don't think it's worth the fuel that you could save by doing burns from Minmus.

Yep, you can check for the line "module = AdvSASModule" in the mod part .cfg files if you want. That's what will add the old ASAS function and lock out your controls when active.

Yes it is a bit confusing. I think some of the problem is the terminology everyone still uses. The old ASAS function is gone, and if they would change the name of the 2.5m grey ASAS module, all references to it would be gone too. C7's last blog post clarifies this in the first section: http://forum.kerbalspaceprogram.com/entry.php/740-Updated-Information-on-SAS-in-0-21-1 And to add to the confusion, mod parts can still access the old ASAS function, which I suspect might be happening in your case. If you just add the right line in the .cfg file, you can make your crafts behave in the same way they used to. You're right SAS requires some control function to actually do anything. But SAS will use any and every control method available, adding more control surfaces, or gimbaling engines will just add to the amount of control your craft has. The SAS function and the Reaction Wheel function are controlled by two separate lines in the .cfg file, so they are related, but one does not require the other. The first seven points (there are eight, you have two sixes) you list are all correct and very succinctly summarize the new system. The last point, the addendum, is not totally correct. When turned off SAS doesn't have any effect on manual inputs. You could remove the SAS line from the .cfg file, and your manual inputs would behave just the same, but otherwise you're right. I agree. That is what I tried to do in my tutorial, but it can be tricky to do because so many people still refer to the parts and functions by their old names and by how they used to work. The only difference is the mass. The 0.21.1 update was hastily released, so I expect some of these things to be fixed in the next update or patch, but for now that's the only difference. Edit: Wow, that was a lot of posts between when I started and finished. Most of the in-game description doesn't actually have to be manually changed. Anything thing with the moduleSAS line in the .cfg file will show that in the in-game description, the same for torque values and mass. Yeah, none of the parts under the Control Parts tab can be used as probe bodies/command points. And it's best not to rely on the wiki for any of this information. Those parts especially are in need of an update and the current descriptions don't reflect how they work now.

It could make a little difference or a big difference. It really depends on exactly what two CPUs you are talking about. There have been significant improvements in CPU performance at the same clockspeed over the last several years.

I'm not sure where this idea keeps coming from, but it's wrong. All SAS functionality is the same. Any of the command pod, probe core, inline reaction wheel, inline advanced stabilizer, ASAS module, or avionics package parts can use all control surfaces, gimbals, reaction wheels and RCS. All parts with SAS have this line in their .cfg file: name = ModuleSAS And all parts with torque have these lines in their .cfg file: name = ModuleReactionWheel PitchTorque = 15 YawTorque = 15 RollTorque = 15 RESOURCE { name = ElectricCharge rate = 1.2 } There were some changes in the 0.21.1 update, so things were a bit different before. But with the current update all of the parts I listed above have those two sets of functions in their .cfg files (with the exception of the avionics package, which only has the SAS line). Again, you can just check the SAS tutorial stickied in the tutorials forum for more detail on all of this. If this really is the case then something is wrong. First, check to see if the fins are moving at all, zoom in really close and you should be able to see even small movements. Second, make sure that you are using the right kind of fins; in my experience the Delta-Deluxe winglets are terrible for controlling rockets. You can use the stock Z-map satellite to confirm this. Try launching it as is (it has Delta-Deluxe winglets already) and it should be really hard to control. Now replace those winglets with AV-R8's and it should be much easier (or even just take off the winglets all together). If the standard SAS really isn't controlling these surfaces then you should try a clean reinstall; delete your KSP folder and reinstall everything (make backups of your save folder if you want to keep it). And if the problem still persists then you probably have a bug somewhere and you should report it.

The graph above is framerate results using my rocket in KSP. The numbers after that are Slugy's Passmark scores, but they don't have anything to do with the graph above it. I wouldn't rely only on the Passmark scores when looking for a CPU for KSP, but they do seem to be a decent indicator of what kind of performance you'll get. ThePsuedoMonkey's plot on the first page shows this. Pretty much any desktop i5 or i7 CPU will be pretty good. The Q CPU's (Core 2 Quad) are much older and I wouldn't buy one of those unless you have the right motherboard for it and don't want to upgrade. The 3000 and 4000 series of i5 and i7 (and i3) CPU's should be easy to find at retail prices; getting the right motherboard is another thing to keep in mind. And pretty much any of them should perform ok. The lowest end i3's might not be quite as good though. Mobile CPU's are another story. They use similar model numbers (i5 2467M vs. i5 2500) but don't have anywhere near the performance of a desktop CPU, keep that in mind.

I think he means the Passmark database, which can be a little questionable sometimes (aside from the entire idea of standardized benchmarks being a little iffy). The same chips run by different people can give a surprisingly wide range of results.

From my Curiosity tribute mission:

I thought so too, but I'm not so sure after looking at the numbers from this database: http://www.cpubenchmark.net/singleThread.html The single threaded results are all over the place. The mobile CPU's especially, seem to get scores much higher than you would expect, and close to much more powerful desktop CPUs. And the i7 920 and 980X (basically consumer versions of Xeons) score very low. Your results definitely confirm my suspicions about how a single core CPU would perform. It's a little surprising that it's that much of a difference though. I added your results and superm18's to the front page, and I reorganized the charts a bit.

You stopped one sub-forum too soon. http://forum.kerbalspaceprogram.com/showthread.php/41941-New-SAS-functionality-and-You%21 But in short, all of the probe cores, command pods, and cockpits have the SAS function and provide torque to varying degrees. And all three of the old ASAS/SAS parts in the control parts tab also have the SAS function and provide torque. You can check this in-game or by looking at the part .cfg files. The Inline Reaction Wheel, Inline Advanced Stabilizer, and ASAS Module all provide 20 torque and all have the SAS function. Only the Advanced Avionics Package is different; it only provides the SAS function (and is therefore basically useless; the chair is the only control point that doesn't have SAS). And yes, both of the above posts are wrong in slightly different ways. Check the tutorial for more detail, but I assure you that the parts have the functions that I described. To be fair though, some of this changed with the 0.21.1 patch, and it will probably change again in the next patch or update.

Oooh, I had one of these once. Laythe led me into some kind of spiral-of-death around Jool. This was back in 0.19 during my Jool Moon mission, I have no idea how I made it happen though.

How do you like your Surface Pro? It sounds like they might be getting ready to release the next version (discounts to clear out inventory), and I'm thinking about getting one. That said, the Surface Pro uses a Core i5, which, even in low power forms, is way more powerful than the Atom/Kabini level of CPU in the Xbox One. Obviously there's no good direct comparison, but laptops with these CPUs have been released and single-threaded performance (and performance in general) is much lower than Intel Core CPUs or Trinities: http://anandtech.com/show/6974/amd-kabini-review/5.

Unless there are significant changes to the way physics works in KSP it would never work well on an X1/PS4. Both consoles are very powerful, but their CPU's are not at all suited to this game. They are basically low end mobile/tablet parts (similar to Intel's Atom CPUs). So the single-threaded physics performance would be terrible. And I don't see how altering KSP's physics for the Xbox1 would be any easier than doing it for the PC, so I wouldn't expect this to happen any time soon.

I see now, thanks. I actually tried that probe core, but I was assuming the requirement was just three Kerbals. I'll give it another try later on.

After digging around I finally found this old post I made about dealing with this issue. Nothings really changed since 0.19 regarding this, so everything should still apply. http://forum.kerbalspaceprogram.com/showthread.php/27668-Tricks-hints-and-important-lessons?p=340578#post340578

I'm kind of surprised that the rocket worked as well as it did. The whole thing is appropriately Kerbal. Because the launch clamps are only on one side the rocket leans toward the VAB before launch. And because of my multistage ignition process (the whole thing blows up if I try to ignite everything at once) the rocket just kind of slides sideways when I blow the launch clamps and ignite the SRB's. It only really starts to stabilize once the liquid boosters are ignited. Since there are no struts on the boosters they do that thing where they sort of bend out like they're about to break off, but they settle down pretty quickly. My custom made, Big Inline Reaction Wheel (with 40 torque I think) probably helped stabilize things, too. And because there is no fuel crossfeed the central engine is dropped off very soon after the liquid boosters, so I avoid having to deal with a really long, unstable rocket for very long. Once I got past that stage everything was very stable, and the payload itself is very well strutted down.