DMagic

Gilly is almost too easy to land on with an ion engine. For a real challenge try Ike or Dres. I put together some ion engine landers for most of the moons where it's possible to do so (I still haven't gotten around to Dres though). http://forum.kerbalspaceprogram.com/threads/30329-Ion-Engines-Everywhere-My-Attempt-to-Land-As-Many-Places-As-Possible

Here are some very preliminary results for testing in space as compared to launching from the KSC. I put a small probe into a 300km equatorial orbit around Kerbin then replaced that with a slightly modified version of my test rocket. I pointed the camera away from the planet then launched, I stopped around stage 7. Because the ISPs are higher some of the burn times are longer, but the staging order is still the same. Trying this on my desktop I saw a bit of improvement throughout the test. But this was on a modded install of KSP and some of the graphics settings are a higher than I normally use for testing. I need to more carefully go through this on a clean install to make any definite conclusions. I launched the ground based version of the rocket as I normally do. I also tested it on my Surface Pro 2 (labeled ground-SP/space-SP), this is the weakest computer I have (which, as you can see, isn't too bad for KSP). This test was a little better, in that it was a mostly clean install of KSP and the graphics settings are unchanged from what I used for previous testing. As you can see performance is a little bit better on the early stages but drops off later on, this is strange and might be due to the camera position. I'll need to do further testing on this too to make sure that I have a good comparison. I also need to try some runs with the graphics settings intentionally set too high to see how much of a difference I can find.

This is the problem. 18m/s is very fast and even good rover designs will have issues turning or going over bumps at that speed. Even 11m/s is probably too fast for most rover designs. Using docking controls can help, but going slower will make the biggest difference. Some other design tips are to make the rover wide and long, keep the center of mass low, and make the rover heavy.

The orange arrows symbol means that you are in "damping mode", it doesn't necessarily mean that you are currently giving manual input. On that picture you can see that your pitch and yaw control authorities are maxed out, meaning the plane probably can't maintain control and can't switch back to "locking mode".

Thanks TNM and GROOV3ST3R, I'll add these data sets later today. You're right TNM, the best way to do it would be to start in space. Getting people to edit their persistence file or use hyperedit is probably asking too much. But I could do it myself and just upload a savefile along with the .craft file. I'll think about doing that after they release 0.23 since the performance improvements they are hopefully including will make comparisons with older performance data obsolete anyway. And yes Unfawkable, even if I already have results for your CPU it's still useful to get more. These can really help smooth out differences due to GPU, or other, limitations.

I think you have to use the crew manifest mod to move Kerbals in and out of parts without a hatch.

Yep, that's right. The non-optimal range just means the scan width is low.

Can you send me the .csv file TNM? Even if it isn't a complete run I can still use the first stage numbers for comparison. Did you actually try the rocket at high settings and get those low numbers? Graphics settings can definitely affect performance, but it probably shouldn't be that drastic given your GPU at 1980 * 1080. I know that AMD cards can have some problems with AA settings, so that might drop your FPS. But otherwise the biggest graphics hog is the terrain, specifically the ocean terrain. Tilting the camera up to keep the ground out of view almost entirely eliminates this issue though. Other settings can have an effect too, like texture and rendering settings, especially on lower end or discrete GPUs. But I think most people running on weaker GPUs don't have those settings maxed out anyway, and the problem gets smoothed over a little by having lots of results (though I suspect that, overall, results from the weaker end of the spectrum are a little lower than they would be in a completely CPU bound setting).

That dV number might be wrong, even with all that excess RCS mass it shouldn't be that low. Your staging is setup a little weird, the four radial tanks seem to be decoupled at the same time as the lander engines are ignited, this might be causing Engineer to give you wrong numbers. Just a quick calculation, using 149 tons, 8640L of fuel and an ISP of 800 gives around 8000m/s (and a burn time of over 100 minutes!!), dropping empty tanks would bring that number up even higher. So you should be fine to get to Moho. As for the long burn time and low TWR, just start the burn really early. The dV saving from the Oberth effect around Moho are almost nothing, so don't even worry about where you burn. Just setup a maneuver node for some point before you get too close to Moho and try to burn off most of your excess velocity. And yes, there is a lot of mass in monopropellant and capsules that you could safely get rid of.

Thanks for running this Nao. Can you send me the .csv files so that I can add them to the rest? I've been hoping to get some more Haswell numbers, and yours look very good. Whatever improvements they made to single-threaded performance seems very well suited to KSP, even down to the mobile CPUs. It will be interesting to see how much OCing improves your numbers as I haven't seen anyone get much over 20FPS for the first stage.

They aren't reluctant. Unity does have multicore support and KSP uses it. It's very common for KSP to have around 30-40% CPU usage on a four-core system. It's the old version of PhysX that's limited to a single thread. Just switching out the old version for a newer version of PhysX probably isn't simple, and since most Unity games probably don't have such complex physics it isn't really an issue for the Unity people.

That looks really nice. How big is that part, 1.5m? And textures are only a problem if they are done poorly. You can just cram all of the different textures onto a single image so that you only load one file. As long as that file isn't huge it shouldn't be much of a problem.

I don't think this is actually a thing. Like Eric S said, these are separate issues. Part count related performance is being held back because the physics calculations are all single-threaded. This is because of the old PhysX version that Unity uses, and it has nothing to do with being 64-bit or not.

Go here if you want more info on the SAS system. http://forum.kerbalspaceprogram.com/threads/41941-New-SAS-functionality-and-You%21-0-22-Update The short answer is that, no you don't ever want to use the Inline Advanced Stabilizer. It provides the exact same function as the Inline Reaction Wheel but weighs more. It has no useful purpose. If you have a vessel with only a command chair you can either add a small probe core, or use an IRW, don't use the IAS.

Thanks, I try pretty hard to keep part counts down so that things don't get too slow. Those stations in my Moho mission, for instance, were both around 100 parts. I mostly try to stay under 300 or so parts for all the crafts I have onscreen at once, or for launch. Sometimes I totally blow by that number though. I've been trying recently to use fewer mods, usually just two or three parts mods per mission and then a few plugin mods (engineer, fairings, maneuver node improver). I'm also careful about deleting parts that I don't use, when I install KW or Kosmos I usually end up removing more than half the parts, that really helps keep load times and RAM usage down. And for the most part I always start new saves for different missions, I don't care about having persistent flags, or a bunch of useless probes littering planet surfaces and orbits. This also lets me clear out any old mods that I don't want to use anymore. I don't like to think about it, but that Moho mission took somewhere around 200 hours to complete over the course of about five or six weeks. I didn't play KSP for about two months after that... I think my newer missions take much longer to post though. I'm much more careful about setting up pictures, and making those gifs can take a long time, especially when they need to be cropped or the image needs to be adjusted. Thanks, these kinds of mission reports seem perfectly suited to gifs, even though I generally don't like them. I try to keep their size down and only post about 10 or so per page. I sacrifice some efficiency to get things to look the way that I want, but I think it's worth it. Asparagus launcher designs tend to look kind of ugly, and I think they add a lot of unneeded complexity, too. Getting all of those stages to behave right and not cause instability or crash into something when they decouple can be a lot of trouble. That manned Eeloo craft for instance, 60 tons isn't exactly gigantic, but it's pretty big and by using asparagus staging I would have ended up with a really long, wobbly rocket during part of the launch. My design got around that though, and just dropped the entire booster stage all at the same time so it was never really unstable.

I give rep for just about anything that seems especially helpful or interesting. That could be answering non-obvious questions, making tutorials, making interesting/original mission logs or crafts, making mods, etc... I also give rep for contributions to my own threads. I think it's up to everyone to decide how/why they want to give rep. You can max out for a 24 hour period (I'm not sure how much it takes to max out, I think around 10 to 20 times), and you can't repeatedly give rep to the same person. I guess giving rep for derailing threads or otherwise causing problems isn't a good idea, but otherwise I think it's fine to give rep however you want.

I tested it on a stock install and got around 1650MB RAM used in the VAB (with 8GB total system RAM), without it I get almost exactly the same, about 1620MB. ISA loaded a bunch of high resolution textures for the map files, that's why it could take up so much RAM if you had a lot of planets mapped. This doesn't load the map textures, so RAM usage shouldn't change much with additional maps, which is nice considering that each planet has 24 possible maps.

Thanks for this, I replaced the graphs on the front page with these results. Non-GPU limited results are always preferable, even if the difference is mainly in the later stages of the launch. I guess it makes sense that there are aspects of the CPU beyond clockspeed and IPC that can significantly effect performance. Those dropoffs are pretty common and if you look at frametime graphs they are even more pronounced. There are some examples on the second page of this thread. You can see how uneven KSPs performance is, and it gets much worse at relatively high framerates. But those really slow frames seem consistent throughout the run, I've seen in mentioned before that these slow frames are related to the stuttering sound that you sometimes hear. V-sync can smooth out the extreme variance in frametimes to some degree, but there doesn't seem to be much you can do about those slow frames. It will be interesting to see if the performance improvements they're working on for 0.23 have any effect on this. It's hard to say for sure what kind of performance you should expect. 9 FPS might be a little low for the benchmark numbers you would expect from that CPU, but then AMD CPUs tend to underperform compared to Intel CPUs based on their benchmark numbers. On the other hand, 9 FPS isn't that bad, it's around the same range as most of the Intel Core 2 Quad CPUs. The only CPUs that really break 15 FPS during the early stages are the newer Intel Core parts. Mods can have an effect, anything that changes or increases CPU usage could lower performance, but it's hard to say for sure without comparing it to a stock installation.

You need to rotate the nuclear engines the right way. When you activate them the covering blows off in two directions, so when you have them grouped like this the covering from one engine can slam into another and destroy it. I'm not sure exactly what direction they need to be rotated, just use Q and E or Shift+Q/E to rotate them and keep trying it out until you get them in the right orientation.

This looks like a variation on that "fly to the Mun in 10 seconds" thing someone made a little while ago with a few hundred decouplers. I wholeheartedly approve of such contraptions. Edit: Never mind, I watched that video and now I understand how the cannon works. This is even better than I thought it was.

Another issue that's always asked about whenever these non-direct transfers are brought up is the delta-v lost because you're not taking advantage of the Oberth effect. But that doesn't really matter as much you might think, and it's an especially small effect with Moho because its gravity is so low and because you're already going so fast that fly by your Moho periapsis in about 10 seconds. And the biggest problem with Moho, the reason why some people end up with 5000m/s burns for orbital capture, is that it's hard to get an ideal intercept, one where your solar periapsis just touches Moho's orbit and you intercept at exactly that point. But when you set up the intercept as if you're docking it's easy to do this, so you get a near perfect intercept and a cheap capture burn.

Nice work, it's always interesting to see a big Moho mission. That's true, but it's also satisfying to gratuitously overdo it just because you can. My Moho mission started out as a Mun mission, but then I figured "why not go to Moho instead, no one ever does big Moho missions, how hard can it be..." Yep, that's what I do, if you're really careful with timing you can launch into an inclined orbit around Kerbin to make it a bit cheaper to match Moho's inclination (your Kerbin inclination has to be much bigger than Moho's inclination around the sun). After I get into solar orbit I just treat the Moho intercept like a docking rendezvous. My record was around 4800-4900m/s I think, though that was really because I got a lucky intercept on my first try, no corrections were needed.

20 tons to get to Eeloo and back, nice job. That's a good point about cheap return trips from Eeloo. I realized that too when I was coming back from Eeloo. When you're just slamming into Kerbin's atmosphere it doesn't really matter how good your intercept is, you can just fiddle around with maneuver nodes until you hit Kerbin at some point during its orbit and go.

That's what I was thinking, just another option in the settings window. I don't think it's a big deal, it's just that the yellow text can get a little lost in the slope map or some altitude maps, even with the black border. KSP captures the mouse wheel and mouse clicks even when another window is open on top of it, so it might not be surprising that there isn't an easy way to limit input to a specific window. I think your altitude may be too high. I haven't tried Kerbin, but I scanned Duna in an elliptical orbit and found that the max range was around 750km for the high resolution scanner, and much lower for the others.

This looks very good. Performance is great all around, rendering seems faster, but maybe that's just me, and the issues with overlays are gone. Scanning at different altitudes works well. I like how different scanners are have very different ideal orbits. I would suggest adding something about the effective orbital range of each part to their description though. You might not need to put the ideal altitude, but it would be nice to put something like "SAR functions from ~100km - ~750km." And the variable scan width works well too. I don't know the specific color combinations that cause problems with some people, but since you have options for markers you might also want options for the color of text. Yellow with a black border works well most of the time, but it can get lost in the slope or altitude maps sometimes. It's good to be able to keep the small S.C.A.N. Instruments window open without the small map, but a separate close button for this window would be nice too. The BTDT window is cool, but a little wonky. It's probably my mouse, but sometimes it requires two scrolls to register and sometimes only one. It zooms the camera in and out too; maybe next/previous buttons on the window would help. Those are all minor issues though, this works great.