DMagic

This isn't a universal thing, some computers can handle the graphics of KSP without issues, other times performance is CPU limited and the terrain settings have little effect. The most prominent terrain related performance drop usually occurs around 50-100km while looking at or near the horizon. At lower altitudes there is less terrain visible and above a certain altitude the terrain switches to a lower setting. What is your terrain detail set at? If it's already at default or low then I wouldn't expect much of a performance hit. If you have changed the ocean detail setting then it would have even less of an impact. I'm not sure about the Lenovo, but that Macbook Pro is very powerful. Even the integrated GPU (or the discrete GPU if you have that model) can give pretty good performance, though I'm not sure it could handle running KSP at the native resolution. You should set up some automated response that posts this whenever someone asks about KSP/Unity, or PhysX and being single-threaded. That's a great two-sentence answer, and it's not wrong or misleading. That may be true, but for the results Aramchek was referring to it does seem to make a difference. That person was getting around 10% higher performance by using the 64-bit version. There could be other differences that explain that performance boost, but it's interesting nonetheless.

If performance is fine with smaller crafts then the issue is not likely to be the video card. Crafts themselves don't put too much stress on the GPU, the biggest graphics hog is the terrain system. Most of the time it's easy enough to work around that issue, and in the worst case you can just rotate the camera around to keep the ground out of view. If doing that doesn't make a difference then you probably aren't GPU limited. 330 parts isn't that much, but AMD CPUs do tend to under-perform in KSP, at least relative to their benchmark values. If you haven't already you can try pushing the physics delta time slider all the way to the right in the settings menu. That's the only option that really directly affects CPU limited performance.

I set them at 0.1 sec delay per frame in photoshop, you can put them at 0.0 sec but it doesn't seem to make a difference for the end result. Within photoshop I can see a difference, and for some of them it is an improvement (the base pictures don't look as good though, the large movements between frames gets more distracting at faster transition speeds). But the gif save preview in photoshop is even faster, the screen starts to look warped if you look at it long enough, it's very strange and definitely too fast. Once they are saved I can't see a difference though, the gif playback seems to be dependent on the viewing software, there seems to be some minimum transition speed that makes faster transitions not work (they can be slowed down though). I'll see if I can find a way around that.

That's very cool. I kind of like the idea of having Kerbin orbit Jool. Is it tidally locked, so that Jool always hangs above the KSC? This seems like a good way to re-experience the planets after you've already landed everywhere.

I was trying to figure out a good way to visualize 3D images while looking at some of the pictures from this preliminary Oculus Rift thread when I remembered wiggle gifs. These are fairly simple in concept, you take two or three images from slightly different angles, align them and make a short, repeating gif. The resulting image can give you a pretty good sense of depth. I tried this out with a few recent creations of mine. The best result came from, not surprisingly, the most time-consuming and painstaking method. For this image I cut out the craft from the second frame and overlaid it on the first frame. I used the clone stamp tool to cover up the exposed edges of the craft from the original frame. The fixed background really makes the craft stand out, I think. You can compare this to another example with a moving background. It works ok, but it’s not as good as the first image. This one uses three images (which comes out to four frames in the final gif), this tends to give better results. Making gifs for larger constructions is a bit trickier. For this base I can’t cut out the craft because it’s attached to the ground, trying to separate the base from the ground would just look strange. I also need to be more careful about aligning the frames, it’s important to keep one central element in a fixed position in every frame, even a small change can ruin the effect. Having the craft take up such a large part of the screen also causes issues, the edges of the craft can be a little distracting because they move so much. Sometimes you get a little of that popup book effect, where everything looks strangely flat. You can also see how using only two frames can make things look a little too shaky. And sometimes I can’t really get it to work. This image seems like it should be easy to create some depth, but it doesn’t seem to come out very well. This is the image from the Oculus Rift thread by localSol. I had to align the two images using that thing on the left wing, but I think it works pretty well. Ok maybe this is too much trouble to rise to the level of an amazing discovery, but it is at least a notable discovery.

I made a gif from your images localSol. I had to cutoff the left side and align the image using the left wing. I think it came out fairly well, you can get a little sense of depth.

The protection shouldn't prevent you from entering numbers in the blue boxes. Sometimes you have to click an "enable editing" button or something like that before it will let you do anything (which isn't the same as unlocking the worksheet).

I figured out what happens to Kerbal prisoners:

Have you ever wondered what happens to Kerbal prisoners? They don't seem to have any prisons, or buildings of any sort on the surface. Naturally they have come up with an appropriately Kerbal solution to the problem: the launchable Kerbal prisoner unit. Offenders are loaded into capsules, placed on the launchpad, then pushed out onto a chute leading to the prison cells. The capsules are then blasted away, and the cap is lowered into place. One rather sneaky convict, Lennie Kerman, managed to get onto the top of the prison unit. He won't escape punishment though. While he held on longer than expected, gravity eventually won, ending his poorly thought out escape plan and serving as a reminder to the others about what happens to those who don’t follow the rules. Once in orbit the prisoners are sufficiently terrified. After a few months in interplanetary space they arrive at the prison planet Eve. The high gravity and toxic atmosphere make this a natural choice for where to house undesirables. Eve's dense atmosphere and the prison's high orbital velocity combine to provide a rather interesting atmospheric entry. Remarkably none of the prisoners were incinerated. The final descent was comparatively calm. This also marks, somehow, my first ever landing on the surface of Eve, I think only Dres remains untouched by Kerbal feet. The future looks bleak for these lost souls. Bright lights and a barren landscape crush any thoughts of an escape.

Here is the worksheet that I use. The only values that you need to change are along the top row. For RCS you need to input the total mass, the ISP (I think 260 for RCS), the total amount of mono fuel and the amount of fuel you want to use. That should spit out values for RCS delta-v, fuel flow rate, and burn time (all of the important results are bolded). https://www.dropbox.com/s/at54r4o4g9thvnb/KSP%20math.xlsx

Does Engineer have a performance hit? I know that Mechjeb does, but I've never noticed a difference with Engineer. Does this worksheet have any way to deal with stages? Maybe I missed it, but without that it seems like it would be very tricky to deal with anything beyond a simple, one-stage design. It would require some kind of dummy mass for all but the current stage. I guess it should be ok for landers though.

No, you need an old version of KSP to get the old model. You can download the last version on Steam by accessing the Beta options for KSP. I think you can download old versions through Squad too if you don't use Steam. Or you can just get the old part folder from someone else.

Engineer and MechJeb can easily get stymied by any non-trivial craft. Just a simple Apollo style lander and orbiter can require some guess work because of the docking/redocking involved and the change in mass. They can't handle RCS either, or engines activated out of sequence. This is one of the reasons why I don't like Engineer/Mechjeb (though I still use them), they tend to guide people into the particular craft designs that are well suited to the calculations they are capable of. I also have an Excel sheet which I use primarily for calculating the fuel needed for a certain amount of delta-v, the opposite of what Engineer/MechJeb give you.

The small cubic struts are physics-less too, which can occasionally cause issues. Using them as strut anchors shouldn't be a problem, but connecting other things to them might not be a good idea. There is also a mod that comes with a really great part made specifically to be used as a strut anchor. http://forum.kerbalspaceprogram.com/threads/34664-Large-Structural-Station-Components-20-Compatible-Release-Thread

I've seen it happen after quicksaving and loading while docking. As long as you can find the right docking ports in the persistence file it's a pretty easy fix, make backups though.

What gives you that idea? From the second paragraph of the first post: "At the same time, all data is pulled from the game - "faking it" by just showing you parts of an existing map isn't acceptable."

The reason why you can't maintain a fixed orientation with respect to a planet is that the game doesn't consider or store that information. Your orientation is only considered with respect to the entire Kerbal universe. If you look at the persistence file each vessel has an orientation line that defines which direction you are pointed. With a few exceptions you probably wouldn't want the game to work otherwise. For instance, locking onto a maneuver node and following it during a long burn is much more important than being able to maintain the alignment of a space station. That wouldn't be possible if SAS locked you heading relative to a planet. The only way to maintain a fixed orientation is to point directly north or south. That way your orientation is fixed in two dimensions while it simply rotates around the third dimension (i.e. a docking port will always point directly north or south, but the craft as whole will still rotate). The only way to keep your orientation fixed with respect to a planet (which is not necessarily the same thing as what I described above) is to align along the normal vectors. You can do this by making a maneuver node, pull out one of the purple icons, and align yourself with the blue maneuver node on the navball. If you are in a equatorial orbit this means pointing north/south, but for other inclinations it will be different.

Archimid's pictures look the same, the right image is just horizontally shifted a bit. It's pretty obvious in the IVA view, you can see the same amount of the Kerbal's face in both images. But localSol's image looks correct. It seems to me that the right image is both horizontally shifted and at a little bit of a different angle. I busted out the old stereo-pair viewers and localSol's looks like it has some depth. I could just be fooling myself, but there seems to be something there. My other question/comment is, can you change the resolution, or maybe force some kind of border around the edges? Something so that the UI elements would be forced in from the edges of the screen a little. And also, have you tried making wiggle gifs from the two images. They aren't perfect, but they can at least give an idea of what the images look like without resorting to eye-crossing or stereo viewers (which I assume almost no one actually owns). I'm not sure if the cross-eyed thing will work in any case here. For that the images are supposed to be switched, the right-eye image on the left and vice-versa. You can still see it in stereo without any kind of viewer, you just have to do the far-away focus thing, not the up-close, cross-eye thing.

Thanks, it's definitely my favorite construction. I could probably do without the overly complex, and performance killing, fuel tanker, but I like the base a lot.

I don't expect many Xeons either, but any additions are helpful. And really, I don't think Xeon's are too different from Intel's consumer level chips, so they can still be a useful comparison.

Nice work. How much power do you get from the solar panels that far out? I always use RTGs for Eeloo, though I guess that wouldn't be very practical for kethane mining.

Yes, meeting Moho when it is closest to the sun is the ideal time. The initial burn from Kerbin to Moho will take slightly more delta-v, but the final burn, to orbit Moho, should take much less delte-v. That said, the reason you're getting a really huge orbital injection burn is that you aren't getting an ideal intercept with Moho. Your intercept should occur at your closest approach to the sun, anywhere else means a much bigger orbital injection burn. Don't use delta-v maps for Moho, they assume all kinds of ideal situations which make them basically useless. There are some interplanetary trip calculators that take into account Moho's orbit and will tell you when and in what direction to burn. Another way to reach Moho is to treat it like a docking encounter. Don't bother with waiting for transfer windows or figuring out the ideal burn times. Just burn until your orbit just touches Moho's then make adjustments to set up an encounter, the same way you do with any other orbital rendezvous. It's not quite as efficient as an ideal transfer, but it's much easier and usually ensures a much smaller orbital injection burn.

Ok, I did some more thorough testing on this whole launchpad vs. space thing. I put up four probes, LKO - 300km, HKO - 1000km, LSO - between Moho and Eve, and HSO - between Duna and Dres. Then I replaced all of them with the space version of my rocket. I reinstalled a clean copy of KSP, with no mods or other saves or crafts. I launched each rocket on a fresh session with the camera in the same location for each run. Most of the graphics settings were maxed out. Terrain was on high with the ocean settings tweak. Textures were at half resolution. AA was turned off and the lights and shadows sliders were moved down a few notches. This graph is a little messy, but the first thing to note is that all of the tests have the same initial performance. Performance remains identical throughout the first four stages, but from there it diverges. The Kerbin orbit tests (orange and grey) show a fairly significant drop in performance from this point on, and there is little diffenence between LKO and HKO. The next test, in LSO (yellow), is between in performance, and the last test, in HSO (blue), is almost at the same level as the launchpad test (burn times are longer because of the ISP difference). For the next two tests I put all the settings back on max. AA was set to 2X and I moved the light/shadow sliders back up. The launchpad test (green) was essentially identical to the previous test at slightly lower settings. The HSO test (dark blue) was a little bit slower, maybe 1 to 3 FPS slower towards to the end. I have no idea why testing in space would result in lower performance than on the launchpad, or why being in Kerbin orbit would make it worse, but that seems to be the case, at least for this test. Kerbin and the sun were both out of frame for all of these tests (keeping Kerbin out of frame during the launchpad test definitely does make a difference, but that's not what I'm looking at here), it was just the starry background. The standard surface launch still seems to be a good test. It's important to follow the instructions in the first post, but I think it does a good job of isolating CPU performance.

I guess all that really matters is that it remains visible. I should have room for it in my sig. If I can preempt one question a day from the questions forum I'll consider it a success.

Well, here's my attempt: http://forum.kerbalspaceprogram.com/threads/60074-How-to-Guide-and-Commonly-Asked-Questions-%28And-Answers%21%29 I'm open to suggestions about how to format it or how many questions and answers to include. Those included are something of a first draft, I plan on putting more, but for now I just scanned the first five or so pages of this subforum and added answers to some of the repeatedly asked questions. Feel free to suggest or add more. If it gets stickied that's great, but if it gets a steady stream of replies it should remain visible too. Edit: And it got moved already, which basically makes it redundant.