DMagic

Here are some more specific details about the rocket itself. The two pictures below show the various stages and their part counts. The rocket itself is fairly simple, it just has lots of extraneous parts, like the nose cones and parachutes on everything. There is little fuel cross-feeding and no asparagus staging. The lighter radial stages should separate without any issues, and the sepratrons on the heavier boosters should keep them from crashing back into the rocket. The only slightly unstable stages are those where only the central core remains from the lowest stage (stage 11 and 8 in the pictures above). This causes a bit of wobbling, but it shouldn’t last long. There are a lot of RCS thrusters and plenty of mono-fuel, so you can activate those if you run into any issues keeping the rocket straight. The in-game flight time is a little under 4 minutes, while the real time for me is a bit below 5 minutes. Here is a detailed table of the stages, their part count, strut count, the number of engines firing, and the number of sepratrons used: The rocket should be stable, and I’ve launched it in this configuration about 10 times in 0.23. I haven’t had a single failure with the current setup. If you have any issues just try launching again, and if something is repeatedly going wrong I can take a look at it and try to fix it. And just in case anyone was wondering, yes, you can land on the Mun and return.

Have you tried a clean install? If you can't get even the simplest of rockets to fly straight then you may have something else wrong. Deleting and reinstalling KSP is the simplest way to fix things. Have you tried the Kerbal X rocket? It should work fine, if it doesn't then something else is wrong.

Be careful making stations out of parts that have no probe cores or command pods. This seems to cause docking port bugs that will prevent you from undocking. Even if you detach the probe cores after docking it can still cause this problem. There are a ton of threads about stuck docking ports. This one in the tutorial section gives an overview of what I'm talking about and how to fix it (it's complicated to fix so you're better off avoiding the problem in the first place), but my advice is to have probe cores or command pods on all components of your station, and to leave them there. http://forum.kerbalspaceprogram.com/showthread.php/35777-Can-t-Undock-Bug-How-To-Fix

The only GPU heavy aspects of the game, for me at least, are when I'm low to the surface and close to the ocean. As I understand it, the way that oceans are done in KSP can be very taxing for the GPU. But that is rarely an issue. Small crafts aren't very hard on the GPU or the CPU, and large crafts are mostly limited by CPU speed, so it's unlikely that adding another GPU will make much of a difference. I suppose if you play on a 120Hz monitor it could help, but I wouldn't bother otherwise.

It seems that way. Even without a probe core, a detached rocket with a reaction wheel will hold its heading if you leave SAS activated when you decouple. If you turn off SAS before decoupling the detached rocket will start to tumble.

When you lose control and the camera moves up that means your lower stages are breaking off from the rest of your rocket. The camera is focused on the center of mass, so it moves up as you drop the lower stages. But when you get a sudden shift like that, it means something failed, even though the rocket may still look like it's attached. The reason this is happening is that you have too much thrust and your rocket is top heavy. It would probably be better to replace those two radial booster engines with skippers. If you can get off the launch pad then you should have plenty of thrust. You should also try putting a smaller tank above the nuclear rocket. It's doubtful that you would need that much fuel just to get to Eve, and that big tank makes your rocket very top heavy. I would also put some struts between the tank below the nuclear engine and the tank above it. You also have some odd placement of the winglets on the bottom. Instead of attaching two to each outer tank, attach four to the central tank. And those look like they might be the Delta-Deluxe Winglets, don't use those, they are terrible for controlling rockets. Use the AV-R8 winglets.

For me too, I just mean that a lot of the details could be tweaked. The torque from the inline reaction wheels, for instance, seems a little high, maybe that could be reduced and the 2.5m part's torque could be increased. Or a smaller reaction wheel part could be added with less torque. And the varying mass values make no sense, parts with seemingly identical function have different masses, and the biggest part is the lightest.

Supposed to hold a heading, I'm guessing. The stock craft do not work very well and should not be used as a guide for proper design. The Kerbal X works fairly well, but the others are all pretty much junk. The Z-map satellite especially, doesn't work well because of the winglets they used. In fact I would recommend never using the Delta-deluxe winglets for controlling your rockets, I always use the AV-R8's.

Because 0.21.1 was hastily released and there are clearly many aspects of the SAS system and their parts that need to be fixed. The chair doesn't have the SAS module, so you can could conceivably use the avionics package on a small craft with only the chair, and no probe cores or reaction wheels of any kind. It would still be controlling RCS, winglets, or engine gimbaling, so it's not totally useless, just mostly.

They all have exactly the same function. The only difference is the size and mass of each part. Only the avionics package is different as it doesn't have any reaction wheels.

I have some notes about testing conditions that I’ll give here. My data above was collected on a system with these specs: Intel i5 3470 @ 3.5GHz during KSP AMD 7850 2GB 8GB DDR3 Windows 8 x64 Resolution set at 1680*1050 Version Comparison: The first two tests, in orange and gray, are from 0.21 and 0.20; they are almost identical. There is a very slight performance improvement in 0.21, but that is mostly above 60FPS where it doesn't make much of a difference. 0.22 is in brown; I stopped the test a little earlier, but you can see that there is no improvement in performance, and there actually seems to be a slight decrease in framerates. You can see the bump in performance from 0.22 to 0.23, it's not very big here, but it's noticeable and things appear a lot smoother overall, even if the framerate isn't much higher. The two older versions, 0.19 and 0.18, are a different story though. I had to add a few parts (and modify their .cfg files to make them work in the old format) from 0.21 and 0.20 to make sure the rocket worked, but the settings were identical to the previous tests. You can see that there is a huge drop in performance when going back this far. I double checked the settings values and ran the tests a few times, but everything came out the same. I don't remember noticing such a big improvement in performance between 0.19 and 0.20, but it seems obvious here. It could be that the parts I added are affecting something, or possibly the .craft file has some differences that cause problems. View Comparison: I have changed my video card to an AMD 7750 since some of my earlier tests, which is quite a bit weaker than the 7850. In making this change I have noticed a few things about performance and graphics settings. While using the AMD 7850 I tested different view points during take off to measure the effect of rendering the ground and the ocean, which is known to cause performance problems on lower power machines. With the 7850 I noticed little difference in performance regardless of where I was looking. These are the results; terrain is set to "high". The tests were done as follows: Once without moving the camera, just looking straight on from the side the whole time. Once while looking up just enough to keep the ground out of view, but not straight up. Once while looking nearly straight down. And once with a varying view, sometimes looking up, or down, or changing angles. Looking down, or keeping the horizon in frame has an effect on performance but it is slight. These tests were done with a Mechjeb unit installed, which causes a decrease in performance (more about that below), but it seems that the terrain doesn't have too much of an effect when using a moderately powerful GPU. Now compare that with my results using the AMD 7750. Terrain is set to "default" here. V-sync is off, but the frame cap is set to 60FPS. The difference here is obvious: In the lowest performing case, shown in blue, I kept the horizon around the center of the frame for the entire ascent. For the next test, shown in orange, I didn't move the camera at all, it is looking straight on from the side. For the test shown in grey I looked slightly up, just enough to keep the horizon out of frame. In the last test, in green, I used the method described in this thread to alter the ocean terrain detail. Then I kept the horizon in the center of frame, the same as in the first, blue, test. This demonstrates the importance of keeping the horizon out of view during the test, especially if you have a weaker, or integrated, GPU. Changing the ocean terrain setting helps a lot too. Above 160km in altitude the performance hit from the terrain disappears and the frame rate shoots up to its limit. Another interesting observation was the effect that MechJeb can have on performance. I had heard about MJ affecting frame rates before, but I never paid much attention until now. Here are the data for launches with and without MJ: You can see that there is a significant performance hit. I found out that this is due mostly to the Delta-V window being open. Closing that can significantly improve your frame rate, which is something to keep in mind for your own launches. This also demonstrates why I don’t want anyone adding anything to the rocket, just launch it with stock parts. I used MJ to design and test the rocket, and for detailed part counts, but there is no reason to use it during data gathering.

Discussion: A few things are clear from looking at the labeled CPU comparison chart at the top of the second post. Mobile CPUs tend to underperform based on their benchmark scores. This isn't really surprising, these chips have thermal and power constraints that desktop parts don't. That said, high end mobile CPUs perform very well; the i7 3630QM and the i7 4650U (a 15W ultrabook CPU) put up very good numbers, and both are GPU limited for most of the run, indicating that they still have some headroom left. AMD CPUs tend to underperform, every AMD CPU lies below the trendlines. This isn't too surprising really, AMD's selling point recently has generally been price over performance, though I don't have enough AMD results to say much. The Core 2 Quad CPUs line up really well. I have a lot of results from these CPUs and they scale very well with clock speed. The differences between them are fairly minor, different cache size for instance, so it's nice to see that different people's results agree so well. Intel's recent Core series CPUs all tend to perform very well, the i7 920's really outdo themselves. Overclocking produces a definite improvement, but there seems to be a limit to this. An i7 2600K at 4.7GHz performs only slightly better than a 2500K at 4.0GHz. And if you are looking to upgrade, it seems that Haswell CPUs are a good choice. Data Analysis: The CPU comparison plot is based on the Passmark score plot from ThePsuedoMonkey. It compares framerates during the initial stage of the launch to both Passmark and Cinebench 11.5 scores, two benchmarks used to give an estimate of CPU power. Framerates are averaged over the first 100 seconds of flight, or the first 2000 frames if frametimes are used. Data for Passmark scores come primarily from the passmark database. Overclocked values were individually looked up online, and sometimes estimated using results from CPUs with similar overclocked speeds. Data for Cinebench scores comes from several sources including http://www.cbscores.com/index.php?sort=rend&order=desc, the Anandtech database and some of their reviews, other values were looked up individually. Notebook scores are primarily from http://www.notebookcheck.net/Mobile-Processors-Benchmarklist.2436.0.html. The data file can be accessed on Google Docs, or the updated excel file in the post above: https://docs.google.com/file/d/0B3cAprRU0gLiQXdVNkx5UWtYZlk/edit?usp=sharing The data sets below the comparison chart are grouped by processor type. Multiple runs from the same person, using the same settings but at different clockspeeds (or GPU setups in some cases) are denoted with a marker: *, #, $, etc... in the legend. The end points for different runs don't necessarily match up. I recommend stopping once the parts separated in stage 6 fall out of physics range. That occurs about 25 seconds of game-time after igniting stage 5. At this point the part count is very low and the frame rate is generally very high (over 60 FPS in most non-mobile cases). The burn time for stages 5 and 3 are fairly long, about 2:10 each, so it's a little dull to watch those stages burn out. You can continue on until you're out of fuel if you want, but in some cases, as you might notice above, I have cutoff the last stages. I've looked at enough of these graphs to know what stage you're in at any given time. I did a little work on the frametime graphs. You can see the raw data on page 2 for some of these plots. There are a few differences in my version. I changed the graph to show FPS vs. time in seconds to match up with the rest of the results. And I simply removed those very high speed frames that pop up near the end (less than 8ms, or over 125 FPS). I think these are just runt frames, tiny slivers of a frame that get thrown on screen between two larger frames; these would get removed by V-sync, even on a high speed monitor. Here is a good discussion and demonstration of what runt frames are: http://techreport.com/review/24553/inside-the-second-with-nvidia-frame-capture-tools/9. These sometimes occur in multi-GPU setups, but it looks like they might be happening here, too. Detailed frametime analysis requires a much more complicated setup than just using FRAPS (both hardware and software), and that is discussed in the link above, too, so I'm not going to worry too much about those results. Those very slow frames are a different story though, they are real and noticeable as the skips in sound. That is definitely something that needs to be looked at. Here is an example of what I did with the frametime data. The raw data are the two columns on the left, these show the start time for each frame. The rest of the data was calculated using the formulas I printed above each column of values. The time was changed to seconds (this is the x-axis), the frametime for each frame was calculated, in ms, then changed to frame rate. I removed the high speed frames by replacing everything above 120 FPS with a blank cell. Then I calculated a 5 frame moving average (this is the y-axis) to make the plots look a little cleaner. Each set of results totals somewhere around 20000 frames, so there is still a huge number of points on each plot. If anyone sees any problems with this, or if anyone has suggestions for how to show the results let me know.

Results - FPS Charts & Benchmark Comparisons Link to high resolution charts. Link to All-CPU, high resolution chart. To view charts in full resolution click on the icon in the top right corner of the album. Some interesting comparisons between CPU types are shown here: CPU Benchmark comparison and breakdown by CPU family Excel file with all FPS results: https://skydrive.live.com/redir?resid=2582013B6F75B5F4!6735&authkey=!AIOtxM7ZuInE9ZQ&ithint=file%2c.xlsx

Data in the second post | Pre-0.23 data in my blog entry Updates for KSP version 0.23.5 - Works in 0.90 New CPU Rocket available on CurseForge; only run the test with the latest version of the rocket. At some point everyone playing KSP learns that performance drops off significantly with increasing part counts. Whether this is learned through hitting a wall in-game or reading about it online, everyone realizes this eventually. What I want to figure out is how exactly various CPU’s handle crafts with high part counts. I’ve seen lots of vague comments about how such and such CPU performs fine with some arbitrary part count, but what I want is actual data. So I went ahead and made a CPU performance test rocket. Using all stock parts I created a stable, functional, 600-part rocket. It is setup so that performance can be measured at a variety of part count levels throughout the ascent. Not having a stack of CPU's available to test, I need others to download and launch the rocket so that I can collect a large amount of data on CPU performance. This is what I want people to do: Download the rocket from CurseForge. Change two values in the settings menu: Set the physics delta slider all the way to the right; a physics delta-time per frame of 0.03s. Turn off V-sync. Launch the rocket without any additions or modifications in a fresh session of KSP (don't launch or fly anything else before this rocket). Change the camera view to look up; move it enough to keep the horizon out of frame (this avoids most GPU limitations, check the fourth post for more on this), don't go into map view and don't open any menus (ESC, F3). Fly straight up until out of fuel. And this is what I want to collect: .csv file with FRAPS data CPU model CPU clockspeed New Rocket: The new version of my CPU rocket uses tweakable settings to reduce the fuel load during all stages. This greatly shortens the time required to run the test, from about 9 minutes to just under 4 minutes of in-game time. The staging has also been simplified, now the rockets for the next stage fire at the same time as the decouplers and sepratrons from the previous stage, this eliminates all of the double staging events required. Everything seems stable, I haven't had any issues, but let me know if anyone has problems. The fifth post has a more detailed look at the new rocket: http://forum.kerbalspaceprogram.com/threads/42877-CPU-Performance-Database?p=554432&viewfull=1#post554432 A few small, but crucial, tweaks have been made for the 0.23.5 version of the rocket. The new joint system was causing struts to hold onto radially decoupled parts a little bit tighter, resulting in hilarious, but less-than-useful effects. Please download the new version for any testing on KSP V0.23.5. The rocket works ok in KSP V0.24. ------------ For data gathering, Windows users can download and run FRAPS, the simple, free, frame rate monitoring software. FRAPS has a benchmark function that can be run to capture the frame rate during the entire launch (you can also capture frametime data); this data is then exported into a .csv file which can be opened with Excel or any other spreadsheet software. By default the benchmark is started and stopped by pushing F11. A green frame rate counter should flash in one of the corners for a few seconds when the benchmark is started, and a red counter will appear when you stop it. Actually displaying the frame rate on-screen can affect performance, so the counter disappears during benchmarking. By default, results are stored in C:\Fraps\Benchmarks. For OSX I've found a utility for recording framerate, it's fairly simple to use and seems to work ok. You can get it here: http://forums.anandtech.com/showthread.php?t=2255863. Linux users can try BuGLe if you can figure it out. It's not too difficult to use, but it does take some effort. This post has some instructions on how to set it up. As an alternative you can try my CPU logging plugin. It creates a log file in the 'GameData/CPUDatabase' folder with a recording of your framerate every second. You can just submit that text file to me if you want. Do note that the vessel name for the rocket must remain unchanged; it is "CPU Test 600 v23_5" without the quotes. Get the plugin here: http://www./download/ccddbv8t1oupijt/CPUDatabaseLog_v1.1.zip. The source code is on GitHub. ------------ If you don’t know your clockspeed then you probably aren’t overclocking and the CPU model should be enough to figure it out. But, if you want to know the real value you can use CPU-Z, it’s a good tool for this. Don’t trust the speed given by task manager, this can be wrong. Other computer details probably aren’t necessary unless you think they are limiting; having 1GB or less of RAM for instance, or something like an Intel HD3000 GPU. By gathering this data, along with CPU vendor id and clock speed, I hope to create a usable database of CPU performance. This will allow people to estimate how many parts their computer can handle, or to get an idea of which CPU’s perform best and how much overclocking affects performance, or to just be better informed in their bickering. Data is given in the second post; details about how the data are shown and calculated are in the third post; details about testing conditions are in the fourth post; details about the rocket and its stages are in the fifth post. You can PM me or leave a link to your results in this thread. You can download the rocket from CurseForge, or from the alternate, MediaFire link below: http://kerbal.curseforge.com/shareables/220893-cpu-performance-rocket-stock http://www./download/jokas5hd3w9fjts/CPU_Test_600_v23_5.zip

It's not a lack of torque that's preventing the Z-map from responding, it's those Delta-Deluxe Winglets. Remove them or replace them with the AV-R8 Winglets and it works fine. Even taking off the Deltas and moving the up a bit so that you can align them properly (so that two of them are directly above the boosters) seems to make the rocket work better. It's something about the combination of those winglets and their position that doesn't work right. Edit: I tried out a version of the rocket Vanamonde and everyone else was using but switched the canards to the Delta winglets. With all of the torque on it works ok, but if I deactivate the torque from the inline reaction wheels and the command pod I can barely move away from the prograde vector. This does make sense in an atmosphere that the rocket would try to stay pointed in the direction of forward velocity, but if I use the AV-R8 winglets instead I can point in just about any direction, with or without the reaction wheel torque on. I guess the point is that the Delta winglets are terrible for rocket control surfaces and they should probably be removed from the stock Z-map.

The 0.21.1 update was probably a bit hasty and I'm sure some of these things will be cleared up. But for now the only difference between these two parts is the mass. Functionally they are the same. The large 2.5m part also has the same function, just a different mass and size.

There is a line in the part .cfg called: rescaleFactor=1 You can just change that to 0.5 or 2 to get the different sizes. A few other tweaks are necessary to get all three parts working correctly though.

Yeah, but it has the same amount of torque as the 1.25m part. That's why I said it's only useful for looks. They should probably add more torque to it and increase the mass a lot.

They obviously need to sort out the old (and now useless) ASAS parts. The yellow, 1.25m Inline advanced stabilizer and the grey 1.25m inline reaction wheel have exactly the same function but different masses. And the 2.5m ASAS part has the same function too, but is just bigger and somehow lighter. The short answer is that the two old ASAS parts (the yellow 1.25m ring and the grey 2.5m ring) have no purpose other than aesthetics. If you want more torque just use the grey, 1.25m inline reaction wheel.

A rescale of the inline reaction wheel works really great, too. I think that both the 0.625 and 2.5m parts look pretty good.

This is not new, the medium size landing legs have had that wobbling issue since at least 0.20. They wobble even with very light landers. I've lifted heavier loads with the small size landing legs without having this problem. In general though, it's a bad idea to attach landing legs to those small cubic struts like you have in the second picture. Those things have their own issues and probably don't combine well with the already dodgy medium landing legs.

All probes have both the SAS module and the reaction wheel module included. The 0.21.1 update post is worded a little ambiguously about this, but the part .cfg files and the in-game descriptions are clear. Everything has both functions; command pods, probe cores, and all of the reaction wheel/SAS parts in the control parts tab.

My suggestion is for something like this to be implemented. It is a simple rescale of the existing inline reaction wheel. No new parts need to be added, and the two old ASAS parts can be removed. The mass and torque values can be adjusted accordingly.

If anyone is interested I have found that this works very well. It is a rescale of the the inline reaction wheel. Factors of 0.5 and 2.0 work for the 0.625 and 2.5m parts, respectively. I also fiddled a bit with the node size and position, the mass, the torque values and the electrical requirement. I think the best idea is for Squad to implement something like this and just get rid of the old ASAS modules, they are almost entirely redundant now. I can give out the .cfg file to anyone interested, just PM me.

Did someone say big rockets with lots of parts? This works fine, it holds steady going straight up, it can make the gravity turn just fine, and it holds its course. It has just two inline reaction wheels, a command pod, one gimbaling engine and a bunch of winglets.