DMagic

Yeah, those multi-couplers are really tricky to use. You can search around the forums, there are a few guides about how to use them with engines and with docking ports, but there are some things they just don't work for. I haven't played around with career mode much, but I think the medium size truss piece is available early on (the rectangular girder thing). It might be a bit ugly, but you can use a stack of those to extend the legs down below the engines.

This probably isn't the right sub-forum for this. But look around for delta-v charts or google interplanetary trip calculators. 2800m/s is nowhere near enough delta-v for Moho. It's barely enough to get you on a course for Moho, but you'll need somewhere between 2000-5000m/s more just to get into orbit around Moho. Then another 1500m/s for landing and taking off, and another 2000m/s for returning to Kerbin. Moho is one of the hardest destinations to reach, so a capsule that was good enough for Eve or Duna won't cut it.

Nope, it's 160km. I put most things above 160km when I'm doing anything more complicated than immediately launching to another planet. The difference between being below 160km and above it is extremely obvious when you're on a relatively weak GPU.

If you want to put landing struts just use I-beams, girders or truss segments to extend the landing legs below the engines. As for the engine cowlings not covering some of the engines, that is because only one of them is actually connected to the decoupler below it. It's a limitation of tri-couplers and how crafts work. You can attach each decoupler directly to the engines to get around this, but you will still have a loose connection to the tri-coupler below it.

I like having nifty looking sensors too, but a lot of real life probes have pretty compact systems. Cassini packs most of its telescopes onto a small part of the craft; the remote sensing pallet in the picture below. Juno packs in a bunch of tiny sensors too (it also comes with Gigantor solar panels). On the other hand, if you want a good model for a high resolution imager, I think the HiRISE camera is good. It's basically just a big telescope, but I think it looks pretty cool. I like this model. Is that an actual texture from the map? That would be awesome if it's possible.

I see, that makes sense. But the batteries aren't really the worst offender when it comes to inflating your part count (except for maybe that big tower-o-batteries on top; the long trusses probably don't alter your mass too much while cutting down on parts), it's the little parts that really add up. For instance, one ring of RCS thrusters is almost always enough for docking, it's not always quite as easy as using multiple rings, but it's not a big difference. And given how many components your final craft has, cutting down on RCS thrusters could really help your part count.

Is this on a rMBP? I don't know how OSX detects applications that need resolution scaling, but in Windows every program has an option to turn off this kind of scaling. I suspect there is something similar for OSX that needs to be changed. That said, I think the GPUs on those laptops might struggle a bit at that resolution.

All of those parts definitely aren't necessary, some of them might be nice to have, but they aren't required. You can always find way to cut down on parts, and every little bit helps.

This one does: http://en.wikipedia.org/wiki/International_Space_Station#Orbit_and_mission_control. Ok, it's not exactly a reaction wheel, but it's the same general idea.

Yep, that'll happen. What's your total part count for the assembled ship? Pretty much anything over 500 parts (regardless of how powerful your computer is) will cause at least a little bit of slow down. If it gets really bad I would recommend going through your designs and try to remove anything unnecessary (excess RCS thrusters, batteries, reaction wheels, or any aesthetic parts). Nevertheless I look forward to seeing how well this works out; I always like to see new designs.

I see it now. Aligning along the normal/antinormal vector lets you point in the same direction relative to the planet during the entire orbit; only your rotational axis will change.

Are you sure this works in a non-equatorial orbit? The maneuver node vectors are aligned relative to your orbit, so the purple, normal/antinormal, vectors are always 90o away from the prograde/retrograde vectors. This means that in an inclined orbit they would point either up or down from the plane of your orbit (which is of course different from the equatorial plane) and therefore not directly north/south. Maybe I'm missing something; I'll have to try this out.

Did you go to the tutorial I linked to? It's in my signature too. I think it explains most of what you need to know, but I'm not going to repost the whole thing here.

The MechJeb Delta-v window is a killer. Closing that one can really improve performance and it's not really necessary during launch.

I think you have to separate career-breaking updates from save-breaking updates. They imply very different things, and it seems to me that career-breaking updates are likely to occur far more often than actual save-breaking updates.

Go here if you want more info about the SAS system. http://forum.kerbalspaceprogram.com/threads/41941-New-SAS-functionality-and-You%21-0-22-Update

I made up an Excel spreadsheet for calculating delta-v and a few other things that engineer can't handle; I always meant to release this somewhere, I just never got around to it. If anyone is interested here's the link: https://skydrive.live.com/redir?resid=2582013B6F75B5F4!1843&authkey=!AFFJzjos_IJw3z4 (let me know if doesn't work). It should be pretty self explanatory, the only values you have to input are along the top, the units used are all indicated, and the important values are in bold (most of the rest are just showing my unit conversions and intermediate steps). Use the total mass (dry mass + fuel mass; shown in the info panel in the map view), and use value for liquid fuel only, not liquid fuel + LOX. You can calculate the average ISP if you have different engine types. You can also get delta-v values for RCS. You can get the amount of fuel needed for a desired delta-v; this and the RCS values are the primary reason I made this. You can also get burn time, burn rate and TWR for a given surface gravity.

I think that any part technically allows this. You just have to manually edit the texture file, this is easiest when the files are in a some normal format like .tga. As for some more user friendly method, I'm not sure. I agree about using the flag though, that should be a relatively simple thing to implement.

At last we come to the final part of our journey to Eeloo. With the return of surface samples from the distant planet our team readies for the last stage of the mission. Due to a series of totally not arbitrary restrictions on mass and life support, this final phase of the mission will require two launches. The first launch will be the Science For Eeloo rocket, which will carry a small ground research facility and a rover. This rocket will use the standard Jool gravity assist to boost its orbit into an Eeloo encounter. The second rocket will carry the crew and will make a direct transfer to Eeloo to save time; it will be able to liftoff while Science For Eeloo is still en route. So, during year 28 (!!!) of our continuing mission to study Eeloo the Science For Eeloo rocket blasts off. It is lifted into orbit by an extended version of the stage-and-a-half design used by the original Discovery Eeloo rocket. Once in orbit the booster rocket separates and deorbits, while the probe continues on. With the protective fairings now separated we can get a closer look at the craft’s components. On top is the science facility, which will land on the surface and serve as the base of operations during the crew’s stay. On the left is the Eeloo rover, which will serve as both a manned and un-manned research platform. The fuel on the right balances out the load and the single NERVA will carry the craft into orbit around Eeloo. With a single burn the craft is able to set up a gravity assist from Jool and, very nearly, an encounter with Eeloo (because of the long initial burn time a few ~10m/s correction burns were required). This is also a relatively short trip, requiring only about three years to catch up with Eeloo. With Science For Eeloo on the way preparations are made for the launch of the crew vessel. Jebediah has been hard at work on this craft, one of his largest creations, and the booster to launch it into orbit. His satisfaction on observing the craft on the launch pad is evident (one guess as to who built the crew transport rover). Bill looks a little terrified, and Bob is less than thrilled about what he calls “the oversized, kraken bait.†In the 31st year of the Discovery Eeloo mission, and with the crew strapped in, the enormous boosters of the Eeloo Ultimate rocket rumble the ground as they ignite. The first stage carries the rocket high into the atmosphere until all five engines give out. With the booster stage separated the orbital insertion motor ignites, making one continuous burn into an 85km orbit. Now in orbit we can get a better look at the craft. It is powered by three main NERVAs which, due to Bob’s un-Kerbal-like fear of radiation, are only allowed for three burns: the initial ejection from Kerbin, the capture burn at Eeloo, and the final burn to come back home. All other burns will be carried out with the small, radial orbital maneuvering engines. For life support the vessel will require one crew container module for every year in space. This limits the craft to two crew containers and a maximum of two years in space due to mass restrictions. Through the window Bob takes one last glance at home. With one long burn from the NERVAs and a few correctional maneuvers the craft sets off. A final, mid-course burn will set up the encounter with Eeloo after a little less than one year in transit. After the mid-course correction Eeloo Ultimate is on course for a rendezvous with Eeloo, while Science For Eeloo begins its initial approach. Once in a low orbit the research station is released and begins its descent. Due to the low TWR one continuous burn is required all the way down. After a rather harrowing impact (three of the legs were broken) the station deploys its antennae and lowers the ladder. Next up the rover descends. This one went a little bit more smoothly, gently lowering the rover to the surface. The landing was off by a few kilometers, but this is a rover after-all, so it drove back to the research station and powered down to await the arrival of the crew. The stack mounted, color-adjustable lights for all of these crafts come from the Stack Inline Light mod from alexustas. A few months later Eeloo Ultimate approaches the planet. Bob gets his first look at the ice-ball outside of his window. After a successful capture burn the crew gets a much closer view of the surface. Oh dear, I think I broke it. To prepare for landing and to save weight for the return journey several components have to be separated then re-docked. One of the crew containers and the shroud are left in orbit while the rest of the ship re-assembles. With the ship put back together Bill and Jeb EVA over to the descent module, which Jeb has christened the Terror Lander. Bill is surprisingly calm as the Terror Lander transitions into initial-descent mode, Jeb on the other hand, is thrilled. With its absurdly high initial TWR of around 18, the Terror Lander has no problem stopping on a dime to come in for a precision landing. With the engines still cooling Bill and Jeb prepare for their first footsteps under the eerie red glow of the landing lights. The crew are thrilled to be back on solid ground after a year cramped up in the ship. The next day they set out on the rover for the highlands surrounding their landing site. Jeb is a little over-eager to get moving, taking advantage of the low surface gravity to pull some stunts. Once they reach some of the white, powder coated ground they stop to take some samples with the rover’s Diggatron. After a long day of rovering around they return to the research station. This newly improved model of the Diggatron also functions as an Injectotron, pumping surface samples into the research station’s sample port for further study. When Jeb learned about the Injectotron he had his suit modified to allow direct injection of the surface samples into his nostrils (little known fact about Kerbals: their nostrils are actually right inside of their eyeballs, accessible through their giant pupils). He remained in a catatonic state for hours afterwards, but declared the experiment “totally worth it.†After a few more weeks on the surface the crew begin their preparations for liftoff. Eeloo Ultimate passes just in front of them after they attain orbit. Unfortunately they came up a little short on fuel, so they have to take turns getting out and pushing to make the final encounter. Bob spots the approaching Terror Lander as the crew EVAs back over to the ship. With the crew back onboard and the launch window approaching, the NERVAs are powered up one last time and the ship blast off for the return trip to Kerbin. After another year in space the ship approaches home. A harrowing aerobraking maneuver puts them into a stable orbit around Kerbin. After adjusting their orbit, the crew prepare for splashdown near the KSC. The engines separate to burn up in the atmosphere, while the crew capsule sails just over the KSC. As the capsule splashes down near the island airfield the crew anxiously climb out to await a pickup. And with that they have officially beaten Eeloo. Sending four rockets to the distant planet, two of which returned, and landing five crafts on the surface, and it only took 33 years.

The results I get for testing under Linux are very bad. I blame this on AMD's terrible Linux drivers, but it could be something else. I've been meaning to test out Ubuntu 13, but I haven't got around to it yet. http://forum.kerbalspaceprogram.com/threads/42877-CPU-Performance-Database?p=694858&viewfull=1#post694858 Maeyanie had much better results, I think using an Nvidia card, so you might also get decent performance. That said, there was essentially no difference between the 32- and 64-bit versions, which isn't surprising. http://forum.kerbalspaceprogram.com/threads/42877-CPU-Performance-Database?p=660134&viewfull=1#post660134 The only way to know for sure is to test it out yourself, but don't expect any part-count related performance increase (KSP already uses multiple cores, it is the physics calculations that are limited to a single thread; Linux does nothing to change this). And because Windows is the primary development focus you are probably more likely to encounter bugs and others issues in the Linux version. If you want any kind of objective comparison you'll have to learn how to use Bugle, the OpenGL debugger. If you aren't familiar with Linux and the command line interface this will not be simple.

You might be able to save some fuel if you can use the atmosphere to bring your Ap back down. There's is probably some critical altitude that you have to achieve to balance the delta-v required for the inclination change with the delta-v required for raising your Ap. But I would imagine that planets with an atmosphere could tilt this trade off in favor of raising your Ap first, rather than trying to do it all in low orbit.

Ok, now I've got it, and it makes sense, too (at least to me). A ship in an equatorial orbit around any planet/moon that is pointed directly north or south (that would be along the N or 180o line, directly between the orange and blue hemispheres of the navball) will stay that way forever. Every planet has their north/south axes aligned along the same plane regardless of their orbital inclination. As for non-equatorial orbits, you are right, you won't stay pointed directly at that point on the navball. However, if you point at the center of the N/180owhen you cross the planet's equator your orientation will oscillate along the N/180o line. The amount of oscillation depends on your inclination. So in a 45o orbit you will move along the N/180o line about half-way up and down the blue and orange hemispheres. So you are technically still pointed directly north/south (with regard to the Kerbal universe) during the entire orbit. The navball moves because your orientation with respect to the planet changes, but your real orientation doesn't change. Therefore this method of fixing the orientation of your docking ports should work regardless of what your inclination is. The navball will move, but your two crafts (one pointed directly north, the other pointed directly south) will remain facing each other even if it takes an entire orbit to dock. So don't listen when someone tells you that you have to be in an equatorial orbit to keep your docking ports aligned. Of course, I could be horribly wrong and maybe you should listen... or just try it out. The part about aligning your craft when you cross the equator is important though. If you try to do it at some other point it will be difficult to line up correctly and your craft probably won't stay oriented.

That is a little weird. If you open FRAPS and go to the FPS tab it should show the benchmark data directory and allow you to change it to something else if creating a folder in the default place is a problem.

The .csv file with the benchmark results should be in C:\FRAPS\Benchmarks. It should be called KSP *time stamp* *benchmark type*, and if you selected more than one benchmark type, like fps and frametime you'll get more than one file.

Can you run my CPU test rocket and send me the results? That's really the best way to see how much or how little performance is impacted by a large craft. Since everyone is running the same rocket and for the most part is CPU limited I can get some mostly objective results for comparison. http://forum.kerbalspaceprogram.com/threads/42877-CPU-Performance-Database